Découper votre /64 n'achemine pas IPv6 vers les clients VPN

Le client affiche une adresse IPv6 globale, la poignée de main est terminée, et rien ne revient d'Internet. Le réglage du pool semble correct parce qu'il l'est ; l'adresse est valide et le tunnel la transporte. Ce qui échoue, c'est la livraison, et la livraison dépend d'une décision prise en amont du serveur VPN qu'aucune configuration côté client ne peut influencer.

Le mythe : une partie de votre /64 est déjà joignable

L'histoire est séduisante : le serveur dispose d'un /64 public, coupez-le en deux, donnez l'autre moitié au pool VPN, et ces clients sont maintenant sur Internet. Découper le préfixe alloue bien des adresses sans collision. Cela ne change pas la façon dont le réseau amont décide où doit aller un paquet destiné à l'une de ces adresses.

IPv6 n'a pas de couche de traduction par défaut sur laquelle s'appuyer, donc le chemin de retour doit exister sous forme de routage ou de livraison au niveau du lien. Un paquet adressé à l'adresse de tunnel d'un client arrive au routeur amont, et ce routeur prend une décision de transfert à partir de sa propre table. Si la table pointe vers le lien physique, le paquet y va, quoi que croie votre serveur VPN.

C'est toute la panne : la direction aller fonctionne parce que votre serveur l'envoie, et la direction retour meurt à un saut de distance parce que l'amont n'a jamais appris que le client existe.

Ce qu'exige réellement la livraison sur le lien

Lorsque l'amont considère que tout le /64 se trouve sur le lien physique, il résout chaque adresse de destination par découverte de voisins. Il envoie une sollicitation sur ce lien et attend que le propriétaire de l'adresse réponde. Un client VPN derrière un tunnel n'est pas sur ce lien et ne peut pas répondre, donc la sollicitation reste sans réponse et le paquet est abandonné.

Découper un /65 ne change pas cette attente. L'amont traite toujours la plage comme étant sur le lien, car la seule chose qui le ferait changer d'avis est une route ou un proxy qui répond au nom du client. Ni l'un ni l'autre n'apparaît parce que vous avez modifié une configuration VPN. C'est précisément cet écart qui explique qu'un pool puisse fonctionner parfaitement entre ses propres clients et rester injoignable depuis partout ailleurs.

La découverte de voisins par proxy est le mécanisme capable de relier les deux mondes. La passerelle répond aux sollicitations pour les adresses de client précises qu'elle possède et achemine le trafic dans le tunnel. Cela fonctionne, et cela doit être limité exactement à ces adresses avec un cycle de vie qui suit le pool, car répondre pour une adresse que vous ne servez plus transforme le trafic de quelqu'un d'autre en trou noir. Certains amonts n'accepteront pas de réponses proxy qu'ils n'attendaient pas, donc cette conception nécessite aussi l'accord du fournisseur.

Ce qu'exige la livraison routée

La conception la plus propre est une allocation que l'amont route réellement vers votre passerelle. Cela peut être un préfixe délégué ou une route statique pour un bloc plus petit, et l'exigence est la même dans les deux cas : la table de l'amont doit pointer vers votre serveur pour la plage de clients. Alors le trafic de retour arrive à la passerelle et la passerelle le transmet dans le tunnel.

La livraison routée élimine entièrement la question de la découverte de voisins, et c'est pourquoi il vaut la peine de la demander au fournisseur avant de construire quoi que ce soit d'astucieux. Demandez la route par écrit et confirmez que le prochain saut est l'adresse que l'amont peut réellement atteindre.

Les deux conceptions ont encore besoin du transfert IPv6 activé sur la passerelle et de règles de pare-feu qui autorisent le flux transféré dans les deux directions. La livraison est un préalable, pas un substitut, pour le reste du chemin. Une route fonctionnelle avec le transfert désactivé produit exactement le même silence qu'une route absente, donc vérifiez les deux avant de revoir quoi que ce soit.

Deux routes indépendantes à réussir

Le préfixe du pool et la route par défaut du client sont des réglages distincts, et les confondre produit une connectivité partielle qui ressemble à un tunnel cassé. Le pool indique au serveur quelles adresses distribuer. Les routes du client décident vers quelles destinations le client envoie du trafic dans le tunnel, si tant est qu'il en envoie.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

Le préfixe ci-dessus est un espace de documentation, et la redirection ne s'applique qu'à IPv6, ce qui est exactement ce qu'un déploiement double pile souhaite souvent tant que la livraison IPv6 est encore en cours de correction. Une redirection IPv4 n'établit pas de couverture IPv6, et aucun des deux réglages n'implique l'autre.

Maintenez le trafic de contrôle dont IPv6 dépend en état de fonctionner, quelle que soit la politique que vous appliquez. Les messages Packet Too Big sont la victime classique d'un pare-feu qui n'autorise que TCP et UDP, et les supprimer produit des connexions qui s'établissent puis calent sur les transferts plus volumineux.

Les annonces de routeur sont la troisième pièce mobile. Si la passerelle commence à annoncer sur le lien montant, cela peut changer ce que les clients et les voisins croient au sujet des préfixes sur le lien, ce qui peut discrètement annuler la conception que vous venez de documenter.

Consignez la conception pour qu'une reconstruction la reproduise

Notez trois objets séparément : l'allocation du client, la route de destination du client et la méthode de livraison de l'allocation par l'amont. Un lecteur qui a les trois peut reconstruire le déploiement ; un lecteur qui n'a que le réglage du pool reproduira le bug d'origine.

Testez ensuite explicitement la direction retour, avec un paquet qui doit revenir de l'extérieur. Le manuel d'openvpn(8) couvre les options server-ipv6 et redirect, et la confirmation de routage de votre fournisseur couvre la moitié que le manuel ne peut pas.