21 votes

Conseils sur la migration d'IPv4 vers IPv6

Je travaille actuellement à l'ajout de capacités IPv6 à notre réseau, et j'ai quelques questions sur ce qui est considéré comme la meilleure pratique en 2020 pour convertir certains des concepts IPv4 auxquels nous sommes habitués dans le monde IPv6.

Dans la configuration actuelle, le FAI nous attribue un /64 et le routeur annonce ce préfixe pour que les clients puissent le configurer eux-mêmes en utilisant SLAAC. Cela semble fonctionner correctement et, pour autant que je sache, tout le monde a un accès Internet IPv6.

Cependant, nous aimons pouvoir interroger les choses par nom et je ne suis pas sûr de la meilleure pratique pour fournir des enregistrements AAAA aux clients.

Ce que j'ai fait, c'est déployer le DHCPv6 avec état sur l'instance dnsmasq qui exécute notre DHCPv4 et lui dire de distribuer des ULA à partir d'une certaine plage qui fournit naturellement des enregistrements AAAA pour toute personne qui demande une adresse. Cela semble également fonctionner correctement, mais je sais qu'il y a une certaine aversion pour le DHCPv6 avec état. Cela m'aide également à consolider l'affectation des serveurs que nous avons sur des IP statiques exactement comme je le fais pour DHCPv4, ces serveurs, pour diverses raisons, doivent être accessibles à une adresse IP fixe et nous aimerions que cela continue à être le cas pour IPv6.

La seule autre façon à laquelle je pense pour faire les enregistrements AAAA est d'envoyer à la machine dnsmasq le préfixe RA du routeur via unicast et d'utiliser ensuite la machine dnsmasq pour annoncer le préfixe GUA pour slaac en utilisant la fonction ra-names option. Pour autant que je sache, cela ne résoudra pas le problème de l'attribution d'adresses statiques et je ne suis pas sûr de sa fiabilité. Existe-t-il un meilleur moyen de gérer les enregistrements AAAA internes que les ULA avec le DHCPv6 avec état ?

Enfin, comme les choses commencent à fonctionner, nous envisageons maintenant la migration de nos services publics vers IPv6. Je crois comprendre que cela nécessiterait un GUA fixe pour les serveurs afin de fournir des enregistrements AAAA publics. Je ne sais pas comment y parvenir en utilisant SLAAC à partir du routeur de périphérie, à moins qu'il n'existe une sorte d'équivalent DNS dynamique. Puis-je à nouveau utiliser DHCPv6 ou une autre méthode d'attribution manuelle pour choisir les IP dans le préfixe qui nous a été attribué ? J'ai hésité à le faire parce que je pensais que cela pourrait entrer en collision avec une adresse SLAAC et je ne suis pas sûr de ce qui se passe en cas de collision. J'ai également la possibilité de demander au FAI une adresse /48, Dois-je faire cela et annoncer un seul /64 pour les clients locaux pour obtenir la connectivité et un /64 différent pour les serveurs statiques ? Cela me semble excessif, nous sommes déjà loin de remplir le seul /64, mais c'est peut-être mon esprit IPv4 qui me perturbe.

18voto

John Mahowald Points 28597

Cela me semble exagéré, nous sommes déjà loin d'être remplis l'unique /64, mais c'est peut-être mon esprit IPv4 qui me perturbe.

Arrêtez de compter les hôtes, c'est la pensée IPv4. Les sous-réseaux ont une taille unique, énorme. Un /64 peut adresser tous les périphériques IP jamais fabriqués avec beaucoup de place en réserve.

Pourtant, l'espace d'adressage est encore plus grand, de sorte qu'un seul site peut facilement demander un /48. 64 mille /64, 4 chiffres hexadécimaux, à distribuer selon le plan d'adressage souhaité.

Pour le /48, qu'est-ce que je dois faire exactement avec lui.

Tout ce que vous voulez ! Soyez généreux et prévoyez la croissance. Donnez des /64 à chaque sous-réseau, à chaque VLAN, à chaque SSID wifi, à chaque zone de sécurité, aux VPN d'accès à distance et aux nuages, à chaque hôte de conteneur, aux /64 "tous zéros" pour les adresses de service statiques de vanité, etc.

Agréger si possible, pour éviter la fragmentation. Ainsi, déléguez peut-être les /60 ou /56 aux réseaux internes comme votre serveur DHCP, le pool statique attribué manuellement, le contrôleur wifi ou le système d'orchestration des conteneurs. Et des environnements de test pour tout ce qui précède.

Il n'est pas nécessaire qu'il soit dynamique comme le DHCP-PD, surtout pas si vous avez un préfixe statique de votre ISP. Mais suivez les choses d'une manière ou d'une autre, dans un système IPAM.

Ou il y a une résolution gracieuse si elle trouve un conflit ?

Les nœuds IPv6 sont censés faire détection des doublons d'adresses sur toutes les adresses unicast, sans état, DHCPv6, manuel, ou autre. La norme est de s'arrêter sur les doublons plutôt que de causer des problèmes difficiles à diagnostiquer. Les adresses générées aléatoirement dans un /64 ont une très faible probabilité de conflits.

ULA

L'ULA est pas de Adressage Internet. Comme ils ne sont pas accessibles à l'échelle mondiale, la politique standard de sélection des adresses par défaut leur accorde une priorité inférieure à celle de l'IPv4. Voir rfc6724. En tant que tel, vous voudrez des adresses routables au niveau mondial (non ULA) sur les hôtes qui se connectent à l'Internet IPv6.

une sorte d'équivalent de DNS dynamique.

Oui, le DNS est nécessaire. Les noms sont plus faciles à comprendre pour les humains que les IP.

Oui, la connaissance de l'IP est généralement un choix entre le serveur DHCPv6 ayant l'état, et un nœud SLAAC étant configuré avec un client DNS dynamique. Drapeaux d'annonce de routeur A et M dire au client qu'il est avec ou sans état.

Les hôtes joints à AD DS sont assez simples, on s'attend à ce qu'ils s'ajoutent eux-mêmes au DNS.

Ou peut-être, configurer les interfaces du serveur avec des adresses sans état, mais avec des adresses non aléatoires basées sur EUI-64. Vous pouvez alors calculer l'adresse à l'avance en vous basant sur l'adresse MAC, et la placer dans le DNS.

Et peut-être que tous les appareils n'ont pas besoin d'être en DNS. Si des appareils Android personnels sont autorisés à accéder à l'Internet pour les invités, ils n'utilisent pas DHCPv6. S'ils ne sont pas gérés par un MDM, vous ne connaîtrez pas leurs IP.

9voto

Sander Steffann Points 7432

Premièrement : obtenir ce /48. Pour des raisons de sécurité et de facilité de gestion, il est bon de ne pas tout mettre dans un seul domaine de diffusion (VLAN).

Deuxièmement : pour les serveurs, il suffit de configurer les adresses de manière statique. Vous pouvez utiliser SLAAC, DHCPv6 et des adresses statiques sur le même réseau si vous le souhaitez.

Il n'est pas très courant de mettre les adresses IPv6 des postes de travail dans le DNS, mais il existe des cas d'utilisation où cela peut être utile. Pour une entreprise disposant d'adresses stables, je déconseille l'utilisation de ULA.

Ce que je ferais dans votre situation, c'est de laisser le SLAAC activé pour que les utilisateurs puissent obtenir des adresses privées, etc. Ajoutez un serveur DHCPv6 sur le côté qui donne des adresses fixes et les place dans le DNS si vous en avez besoin. Activez également le drapeau M dans les annonces de routeur pour que les clients sachent qu'un serveur DHCPv6 est présent.

Et comme l'IPv6 utilise des adresses globales pour tout, assurez-vous que vous disposez d'une sécurité réseau adéquate, comme un pare-feu.

4voto

Kevin Keane Points 840

J'ai également la possibilité de demander un /48 au FAI. et annoncer un seul /64 pour que les clients locaux obtiennent une connectivité et un /64 différent pour les serveurs statiques ?

Demandez absolument à votre FAI un /48. Vous ne pouvez pas faire un sous-réseau /64 sans casser toutes sortes de choses (y compris SLAAC).

Votre idée de placer les serveurs et les clients locaux sur un réseau différent est également une très bonne idée (même en IPv4). Bien sûr, il arrive que l'infrastructure réseau ne permette pas de le faire (il faut soit un câblage séparé, soit une capacité VLAN), mais puisque vous posez la question, je suppose que ce n'est pas un problème pour vous.

La ségrégation de votre réseau vous permet de mettre un pare-feu entre eux. Étant donné qu'en IPv6, tout est une adresse IP publique, il est beaucoup plus essentiel qu'en IPv4 que vous ajustiez soigneusement votre pare-feu ; il est beaucoup trop facile de laisser accidentellement des systèmes directement sur Internet ; c'est l'une des principales faiblesses d'IPv6. Si vous séparez votre réseau, une telle erreur sur un réseau n'exposera pas automatiquement l'autre.

De même, si vous séparez les réseaux, vous pouvez, si cela est judicieux, mettre en œuvre une approche de confiance zéro sur le réseau côté serveur (ce qui peut réduire la nécessité d'un pare-feu à cet endroit), sans avoir à faire la même chose sur le réseau interne.

Vous pouvez aussi faire migrer vos serveurs et conserver les postes de travail sur un réseau uniquement IPv4 ; cela réduit votre charge de travail, prend en charge les anciens appareils qui ne prennent pas en charge IPv6 et présente un certain nombre d'autres avantages (bien que certains défenseurs d'IPv6 s'y opposent).

En résumé, si votre infrastructure le permet, il faut absolument séparer votre réseau. Il y a beaucoup d'avantages et aucun inconvénient réel.

Pour ce qui est de votre deuxième question, il semble que vous travaillez sur un réseau d'entreprise de taille raisonnable. Je vous recommande vivement de mettre en œuvre une solution IPAM, au lieu d'essayer de la déployer vous-même.

La réponse générale à votre situation est exactement celle que vous avez suggérée : DHCPv6 avec état et mise à jour automatique d'un serveur DNS. La plupart des solutions IPAM se composent essentiellement de ces deux technologies, ainsi que d'un frontal de gestion.

Modifié pour ajouter : juste pour être complet, bien que ce ne soit probablement pas une bonne solution pour vous, vous pouvez également utiliser mdns (alias bonjour ou zeroconf) pour la résolution de noms.

Le support est quelque peu irrégulier. Apple le prend généralement en charge, Windows 10 le prend partiellement en charge, mais vous devez manipuler le registre pour le faire fonctionner pour les applications Windows traditionnelles, et je n'ai pas été en mesure de le faire fonctionner du tout sur Android.

Bien entendu, mdns ne répondrait pas non plus à votre question concernant la mise à jour du serveur DNS externe.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X