Activer IPv6 sans surprendre un seul serveur

La raison pour laquelle beaucoup de réseaux de production tournent encore uniquement en IPv4 n'est pas technique. C'est la peur : qu'activer IPv6 change quelque chose sur des serveurs que personne n'a regardés depuis des années, ou ouvre une porte que chaque liste d'accès IPv4 avait soigneusement fermée. Les deux peurs sont raisonnables, et les deux s'évitent avec le bon ordre de travail. Voici l'ordre que nous utilisons.

Les deux vrais risques

Les serveurs se configurent tout seuls. La plupart des systèmes d'exploitation acceptent les router advertisements par défaut. À l'instant où une passerelle sur un VLAN commence à annoncer un préfixe, chaque hôte de ce VLAN peut s'attribuer une adresse IPv6, installer une route par défaut, et se mettre à préférer IPv6 pour tout ce qui se résout en enregistrement AAAA. Personne n'a modifié ces serveurs, et pourtant leur comportement a changé.

La politique de sécurité est par protocole. Une liste d'accès IPv4 ne fait rien pour IPv6. Des interfaces de gestion verrouillées en IPv4 peuvent être grandes ouvertes en IPv6 le jour où un équipement reçoit une adresse globale. C'est le risque qui mord en silence, parce que rien n'est cassé. C'est simplement exposé.

Étape un : un plan d'adressage que vous ne regretterez pas

Avant de configurer quoi que ce soit, découpez l'allocation sur le papier. Un plan qui nous a bien servi :

• Un bloc public pour la production des clients.
• Un bloc public pour la plateforme et les services internes qui doivent être joignables.
• Un bloc strictement interne, enregistré auprès du RIR mais jamais annoncé, pour la gestion et l'infrastructure qui ne doivent jamais être routables sur l'internet.
• À l'intérieur de chaque bloc, reflétez le plan IPv4 là où vous le pouvez. Si le VLAN 210 porte 192.0.2.0/26 en IPv4, donnez-lui un /64 évident et dérivable en IPv6. Les ingénieurs doivent pouvoir déduire le jumeau IPv6 d'un hôte sans le chercher.

Utilisez un /64 pour chaque segment LAN, et un /127 pour les liens point à point. Réservez un bloc entier pour les loopbacks, pour que les identités des routeurs soient faciles à reconnaître dans les traceroutes et les logs. Décidez tôt comment les hôtes obtiennent leurs adresses : l'attribution statique pour les serveurs garde les adresses prévisibles pour les règles de firewall et le reverse DNS, tandis que l'autoconfiguration sans état convient mieux aux réseaux de clients qu'aux réseaux de serveurs.

Étape deux : la parité de sécurité avant la joignabilité

Verrouillez les portes avant d'ouvrir la rue. Sur chaque équipement, avant que le routage IPv6 ne l'atteigne depuis l'extérieur :

• Les listes d'accès de gestion pour SSH, SNMP, les API et les interfaces web existent pour IPv6 et refusent l'internet, à l'image des listes IPv4.
• Un filtrage anti-spoof est appliqué à IPv6 sur chaque interface exposée à l'internet, par vérification unicast reverse path ou par filtres de source explicites.
• Le control plane policing couvre ICMPv6 et le neighbour discovery, pour que l'équipement reste administrable sous un flood, sans bloquer le trafic de neighbour discovery dont IPv6 a besoin pour fonctionner tout court. ICMPv6 n'est pas optionnel en IPv6 comme certains traitent ICMP en IPv4 : les messages packet-too-big sont le mécanisme même du path MTU discovery.
• Les zones de reverse DNS pour le nouvel espace sont déléguées et remplies, pour que les vérifications de messagerie et de conformité n'échouent pas la première fois qu'un hôte parle IPv6.

Étape trois : du edge vers le cœur, un équipement à la fois

Ajoutez des address families IPv6 aux sessions BGP existantes avec les transitaires et les peers plutôt que d'en construire de nouvelles, et travaillez vers l'intérieur : les routeurs de bordure, puis les liens vers le fabric, puis le routage interne du fabric. Changez un équipement à la fois, et prenez un instantané de l'état de chaque session de routage avant et après chaque étape pour voir d'un coup d'œil que rien d'autre n'a bougé :

show bgp all summary | utility egrep "Neighbor|Estab|Idle|Active"

Sauvegardé avant et après chaque changement, un simple diff de cette sortie est le test de régression le plus rapide que vous écrirez jamais.

Étape quatre : des passerelles silencieuses

Configurez maintenant les passerelles IPv6 là où vivent déjà les passerelles IPv4, sur les mêmes VLAN et les mêmes leaves, mais avec les router advertisements supprimés :

interface Vlan210
  ipv6 address 2001:db8:210::1/64
  ipv6 nd suppress-ra

Rien ne change pour les serveurs existants, parce que personne ne leur annonce de préfixe. Les hôtes obtiennent IPv6 quand vous le décidez, soit avec une adresse et une passerelle statiques dans leur propre configuration, soit en activant les annonces sur un VLAN où chaque hôte est connu et prêt. Sur Linux, vérifiez ce qu'un hôte fera avant de basculer quoi que ce soit :

sysctl net.ipv6.conf.all.accept_ra net.ipv6.conf.eth0.accept_ra
ip -6 addr show; ip -6 route show

Étape cinq : testez de l'extérieur, sur les deux protocoles

La vue depuis l'intérieur d'un réseau le flatte. Une fois un bloc annoncé, scannez chaque adresse de chaque équipement depuis un point d'observation externe, en IPv4 comme en IPv6, et confirmez qu'aucun port de gestion, de supervision ou de routage ne répond depuis l'internet. Faites ensuite le test positif : atteignez un vrai hôte en IPv6 depuis plusieurs pays sans perte, et confirmez que son enregistrement AAAA, son enregistrement inverse et son certificat TLS fonctionnent tous en IPv6 exactement comme en IPv4. Un service qui se résout en IPv6 mais ne répond pas est pire qu'un service sans IPv6 du tout, parce que les clients l'essaieront en premier et attendront. Des outils comme nmap depuis un hôte extérieur, et des réseaux de mesure mondiaux comme RIPE Atlas, rendent les deux vérifications faciles.

nmap -6 -Pn -p 22,161,179,443,830 2001:db8:210::1

Votre propre checklist

• Existe-t-il un plan IPv6 écrit qui reflète votre plan IPv4 ?
• Chaque restriction de gestion IPv4 a-t-elle son jumeau IPv6 ?
• Le filtrage anti-spoof est-il appliqué à IPv6 sur les interfaces exposées à l'internet ?
• Les router advertisements sont-ils supprimés jusqu'à ce que vous choisissiez de les activer ?
• Vos zones inverses IPv6 existent-elles et se résolvent-elles ?
• Avez-vous scanné votre propre espace IPv6 depuis l'extérieur ?

IPv6 est natif sur tous nos sites, Athènes, Amsterdam et Toronto, et a été déployé dans cet ordre. Si vous voulez IPv6 sur votre plateforme sans surprises, nous serons heureux de vous aider.

CTA

Parler à un ingénieur

Related

Sur le même sujet : IPv6, natif et en dual-stack · Comment nous changeons les choses : la discipline de changement réseau · DNS autoritaire et reverse DNS, exploités comme une infrastructure