Planifier IPv6 pour un concentrateur WireGuard à deux sites : préfixe, pairs, routes

Deux LAN, un concentrateur WireGuard et un plan d’adressage IPv6 qui doit répondre à trois questions distinctes : quel préfixe, quelle adresse appartient à chaque routeur et quel pair possède quel sous-réseau. Une erreur sur l’une d’elles produit un tunnel qui fait la poignée de main et ne route rien. Le plan ci-dessous déroule une conception privée à deux sites dans cet ordre. Il ne fournit délibérément pas d’accès à Internet en IPv6.

Décidez à quoi sert le préfixe

Un préfixe local unique issu de fd00::/8 est le choix naturel lorsque l’objectif est une joignabilité privée entre sites. Il reste stable quel que soit le fournisseur qui dessert chaque emplacement et n’est pas annoncé dans la table de routage globale, donc il ne peut pas faire fuiter votre numérotation interne sur Internet.

La même propriété est la limite. Une ULA n’offre aucun chemin de retour public, car aucun fournisseur en amont ne sait la router vers votre passerelle. Si l’exigence inclut une sortie Internet en IPv6, il vous faut une allocation d’un fournisseur qui la route vers vous, et c’est une décision de conception distincte avec sa propre taille de préfixe.

Ne supposez pas que chaque déploiement a besoin d’un /48. RFC 6177 s’est éloigné d’une taille unique obligatoire pour le site final, et la bonne taille suit le nombre de réseaux que vous exploiterez. Générez l’ULA avec la procédure RFC 4193 plutôt que d’inventer un préfixe qu’une autre organisation pourrait aussi utiliser. Écrivez le résultat dans le plan d’adressage avant de configurer le moindre appareil, car un préfixe que personne n’a noté est un préfixe que quelqu’un réutilisera.

Découpez le préfixe en rôles

L’exemple ci-dessous utilise fd7c:2e91:4a00::/48, et le tableau est organisé selon l’endroit où chaque bloc est écrit, non selon le site. Traitez les valeurs comme un exemple et générez les vôtres avant de déployer quoi que ce soit.

Les blocs LAN sont des /64 parce que le SLAAC ordinaire attend un identifiant d’interface de 64 bits. Découper un LAN en un bloc plus petit brise cette hypothèse sur la plupart des hôtes, et le coût opérationnel ne vaut pas l’économie d’adresses dans un plan privé. Les deux blocs LAN viennent du milieu du /48, laissant la plage basse libre pour des sites ultérieurs.

Les adresses de tunnel sont un réservoir administratif, pas un réseau sur le lien. Chaque interface en reçoit une seule /128, de sorte qu’aucun hôte ne suppose un sous-réseau partagé sur le tunnel et que la découverte de voisins ne tourne pas là où elle n’est pas nécessaire. Gardez les rôles disjoints et consignez-les dans le plan d’adressage de l’organisation pour qu’un site ultérieur ne réutilise pas un bloc.

Donnez à chaque routeur une adresse de tunnel

Attribuez une /128 par routeur et conservez les clés et les points de terminaison existants du concentrateur qui fonctionne. Les trois valeurs ci-dessous ne diffèrent que par la partie hôte.

Hub:    Address = fd7c:2e91:4a00:ff00::1/128
Site A: Address = fd7c:2e91:4a00:ff00::2/128
Site B: Address = fd7c:2e91:4a00:ff00::3/128

Cette /128 décrit l’adresse unique attribuée à cette interface. Elle ne dit rien du nombre de destinations que le pair peut router, car la joignabilité s’exprime dans AllowedIPs et non dans le préfixe de l’interface.

Chaque routeur de site a aussi besoin d’une adresse dans son bloc LAN et d’un moyen de la diffuser, généralement des annonces de routeur pour le SLAAC. WireGuard n’envoie pas ces annonces à votre place et ne relie pas les deux LAN. Le routeur de site est un routeur dans les deux sens.

Placez la propriété du sous-réseau dans AllowedIPs

L’entrée de pair du concentrateur pour le site A possède l’adresse de tunnel de A et le LAN de A, et cette paire constitue toute la déclaration de propriété. Rien d’autre dans cette section de pair n’a besoin de décrire le site.

AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64

L’entrée de pair du site B possède la paire correspondante, et la symétrie compte ici plus que la concision. Lisez les deux lignes ensemble et la répartition de propriété devient visible d’un coup d’œil.

AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64

Ce sont deux sections de pair distinctes, pas deux listes qui se disputent un seul pair. WireGuard utilise AllowedIPs dans les deux sens : il choisit le pair pour une destination sortante et rejette un paquet entrant dont la source ne correspond pas à la plage attribuée au pair qui l’a déchiffré. Donner tout le /48 aux deux pairs désactiverait cette seconde vérification et brouillerait quel site possède quel bloc. C’est cette distinction qui rend une mauvaise adresse source visible au lieu de l’accepter en silence.

Chaque site n’a besoin que des destinations joignables via son pair concentrateur : le site A liste l’adresse du concentrateur, l’adresse de tunnel du site B et le LAN de B, et le site B liste l’ensemble réciproque. Les listes sont asymétriques à dessein, car chaque routeur voit un côté différent de la topologie. Écrivez les deux depuis le plan d’adressage et non depuis la configuration de l’autre site, car c’est ainsi qu’une plage obsolète survit à une renumérotation.

Avec wg-quick, ces plages créent aussi des routes. Avec systemd-networkd ou une configuration manuelle, ajoutez vous-même les routes équivalentes ; sinon le tunnel transporte des paquets que le noyau n’y envoie jamais.

Terminez le transfert et testez les deux sens

Activez le transfert IPv6 sur le concentrateur et sur les deux routeurs de site, et autorisez les services inter-sites requis dans la politique de transfert. Gardez les messages ICMPv6 Packet Too Big utilisables, car les supprimer casse la découverte du MTU de chemin et provoque des blocages de gros transferts qui ressemblent à des défauts applicatifs. Un concentrateur qui transfère sans l’autorisation du pare-feu supprime le paquet entre le routage et le tunnel. Ce mode de défaillance mérite d’être connu, car le tunnel reste actif et seuls certains flux meurent.

sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1

Testez depuis un hôte du site A vers un hôte du site B, puis dans le sens inverse. Un ping vers l’adresse de tunnel du concentrateur n’exerce que le premier saut et réussira même lorsque les routes LAN sont fausses. Le flux d’hôte à hôte est celui qui prouve le plan.

La connexion WireGuard externe peut passer par IPv4 tandis que le trafic interne est en IPv6, et cette indépendance est utile pendant une migration. Si une sortie IPv6 globale est ajoutée plus tard, révisez l’allocation du fournisseur, la sélection d’adresse source et le routage de retour comme une nouvelle étape de conception ; le plan privé ci-dessus reste valable pour le trafic entre sites.