Délégation de préfixe IPv6 à travers un VPN site à site : liste de contrôle

Monter le tunnel, c'est la moitié facile. J'ai vu une liaison site à site rester établie pendant des jours tandis que chaque hôte du LAN distant ne recevait que du silence, parce que le préfixe délégué derrière cette passerelle était configuré sur une interface mais n'avait jamais été routé vers le tunnel. Les adresses du tunnel répondaient aux pings tout ce temps, et c'est précisément pourquoi personne n'a regardé le préfixe. Voici l'ordre que je vérifie quand un préfixe IPv6 délégué doit traverser un VPN de site : le plan des préfixes, les sélecteurs de trafic, le transfert et le pare-feu, puis le chemin de retour.

Écrivez le plan des préfixes avant de toucher au tunnel

La délégation de préfixe remet un bloc au routeur qui l'a demandé. Elle n'installe pas de route chez le pair, n'étend pas ce bloc sur le lien et ne dit pas à la passerelle distante ce qui se trouve derrière le routeur demandeur. Ces trois choses sont à votre charge, et elles relèvent d'un plan d'adressage avant qu'aucun fichier de configuration ne change.

Pour chaque site, notez le préfixe délégué, le /64 réellement utilisé sur le LAN, les adresses du tunnel et le propriétaire de chaque route. Le fournisseur délègue 2001:db8:a1::/56 au site A, qui sert 2001:db8:a1:10::/64 sur son LAN ; le site B conserve 2001:db8:b2::/64. Si le site A ne sert que ce seul /64, les deux extrémités doivent nommer 2001:db8:a1:10::/64 plutôt que tout le /56.

Deux erreurs reviennent presque à chaque fois. L'une est de traiter le préfixe distant comme s'il était sur le lien, de le pontier ou de le placer sur l'interface du tunnel pour que la passerelle réponde à la sollicitation de voisin pour des hôtes qu'elle ne peut pas atteindre. L'autre est d'annoncer tout le /56 alors qu'un seul /64 est configuré : la table de routage prétend que le bloc est joignable et la plupart des adresses tombent dans un trou noir.

Alignez les sélecteurs de trafic des deux extrémités sur les routes

IKEv2 et WireGuard refusent tous deux le trafic incompatible, assez discrètement pour que le tunnel paraisse encore sain.

Dans strongSwan, les sélecteurs sont explicites. Sur le site A :

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

La conn du site B reflète les deux sous-réseaux. Quand ils divergent, le répondeur rejette la CHILD_SA avec TS_UNACCEPTABLE, si bien que l'SA enfant ne monte jamais alors que l'IKE_SA est montée. Des deux côtés, le sous-réseau configuré doit être égal à ce que le noyau local route vers le tunnel.

WireGuard transporte la même information dans AllowedIPs, avec une nuance : AllowedIPs est un filtre de source à la réception autant qu'une route à l'émission. Si l'entrée de pair du site B pour le site A omet 2001:db8:a1:10::/64, les paquets du site A arrivent sur une poignée de main valide et sont rejetés comme non autorisés. Cela produit le schéma bien connu d'une poignée de main qui se renouvelle sans cesse alors qu'aucune réponse ne sort jamais. Comparez les deux extrémités avec wg show wg0 allowed-ips. Revérifiez cette liste à chaque changement de délégation ; un /64 périmé maintient la session et rend le nouveau préfixe injoignable.

Écartez d'abord le transfert, le pare-feu et la MTU

Avant de lire une autre ligne de journal, confirmez que les passerelles transfèrent réellement. sysctl net.ipv6.conf.all.forwarding doit renvoyer 1 des deux côtés, appliqué aussi aux interfaces du tunnel et du LAN. Un piège vient avec : une fois le transfert activé, une interface avec accept_ra=1 cesse d'accepter les annonces de routeur du fournisseur, si bien que la machine peut perdre sa route par défaut amont tout en routant parfaitement à l'intérieur du tunnel. Réglez accept_ra=2 là où une RA du fournisseur reste nécessaire.

Ensuite, les règles du pare-feu doivent autoriser le préfixe dans les deux sens, et ICMPv6 doit survivre : la découverte de voisins, paquet-trop-gros et destination-injoignable ne sont pas optionnels. Si vous les supprimez, la découverte de MTU du chemin casse et vous obtenez des connexions qui s'ouvrent puis calent à la première grande réponse. Une paire minimale de règles ressemble à ceci :

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

La MTU est derrière cela. Un tunnel réduit la MTU utilisable sous 1500, et IPv6 exige que chaque lien porte au moins 1280. Les petits pings passent, une session SSH se fige sur une grosse rafale, et /proc/net/snmp6 affiche des messages paquet-trop-gros qui ne reviennent jamais. Fixez la MTU du tunnel explicitement, ou limitez le MSS TCP dans la table mangle, et laissez revenir l'ICMPv6 qui signale la MTU plus petite.

Testez le chemin de retour, pas l'adresse du tunnel

La panne qui coûte le plus de temps est le routage unidirectionnel. Chaque passerelle route le préfixe distant vers le tunnel, mais les hôtes répondent par leur propre passerelle par défaut parce que c'est là que vit leur /64. Amener un paquet à destination n'est que la moitié du chemin.

Deux commandes règlent l'essentiel. Sur le site A, ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 montre quelle interface utiliserait une réponse de cette source ; faites le contrôle miroir sur le site B. Générez ensuite du trafic depuis un hôte plutôt que depuis la passerelle et comparez les compteurs des deux côtés.

Si une sollicitation de voisin pour le préfixe distant apparaît sur le tunnel, ce préfixe est sur le lien quelque part où il ne devrait pas être ; corrigez cela avant d'ajuster les routes. Proxy NDP couvre les cas où le pontage est réellement nécessaire, ce n'est pas un substitut à une route.

Prévoyez que le préfixe change sous vos pieds

La délégation de préfixe est un bail entre le routeur délégant et le routeur demandeur, et un renouvellement peut rendre un bloc différent : un /56 différent après une migration de fournisseur, ou un bail plus court que la durée de vie du tunnel. Chaque endroit qui nomme l'ancien préfixe devient périmé d'un coup : routes, sélecteurs, AllowedIPs, règles de pare-feu, enregistrements DNS et toute supervision qui code en dur des adresses littérales. Le flux de messages est dans RFC 8415.

Là où le préfixe est censé bouger, gardez un plan d'adressage interne qui n'en dépend pas et traduisez à la frontière. NPTv6 est l'option sans état et garde la politique interne lisible, mais c'est de la traduction de préfixe, pas une couche magique : les frontières /64 doivent s'aligner, les sommes de contrôle sont ajustées, et les applications qui intègrent des adresses littérales cassent encore. Si vous conservez les adresses du fournisseur de bout en bout, consignez le comportement du bail et une procédure de changement dans le plan d'adressage.

Terminez par un test qui résiste au temps : un hôte autorisé de chaque LAN atteint un service de l'autre LAN, la réponse revient par le tunnel, et la même paire fonctionne encore après un redémarrage du tunnel et un renouvellement de délégation. Si la dernière partie échoue, la conception dépend d'un état qui ne survivra pas à la semaine.