IPv6 à travers un serveur VPN IPv4 exige toujours une sortie IPv6

Le tunnel monte, le client reçoit une adresse IPv6 depuis le pool, et pourtant chaque destination IPv6 expire. Rien n’est cassé dans le tunnel : IPv6 circule parfaitement bien dans le transport IPv4, et ce n’était jamais la partie difficile. L’adresse que vous avez distribuée est une promesse que le serveur ne peut pas tenir, car la sortie n’a aucun upstream IPv6 où l’envoyer. La réparation se fait à la sortie, pas dans le profil du client.

Le symptôme : une adresse et aucun chemin

Une vérification côté client montre une adresse IPv6 d’apparence globale sur l’appareil de tunnel et une route qui pointe dedans, ce qui explique pourquoi cela est lu à tort comme un bogue client. Le trafic entre dans le tunnel, le serveur le désencapsule, puis le paquet atterrit sur un hôte dont la table de routage n’a aucune route par défaut IPv6 vers un endroit réel. Selon la pile, vous obtenez une inaccessibilité immédiate ou une chute silencieuse, et dans les deux cas le client voit un délai d’attente qui ressemble à s’y méprendre à un pare-feu.

Lisez la table de routage du serveur lui-même avant de toucher au client, car c’est là que vit la moitié manquante du chemin. Un serveur avec une seule route par défaut IPv4 vous a déjà donné la réponse.

Suivez le paquet après la désencapsulation

À l’intérieur du tunnel, le paquet est de l’IPv6 ordinaire et l’adresse du client en est la source. Le serveur retire l’encapsulation de transport et tient alors un paquet IPv6 natif qui doit être transmis à un prochain saut IPv6. Une route par défaut IPv4 ne peut pas le porter, et le traduire en IPv4 est une autre fonction que personne n’a déployée. C’est toute la panne, et cela n’a rien à voir avec le fait que l’écouteur VPN ait répondu ou non via IPv4.

La mécanique d’encapsulation d’IPv6 sur IPv4 est décrite dans la RFC 4213, et le détail important y est que les extrémités ont toujours besoin d’une véritable connectivité IPv6 de l’autre côté du tunnel. Emballer un en-tête ne fait pas apparaître un upstream.

Deux couches de tunnel, deux vérifications indépendantes

Vérifiez chaque couche séparément, car un tunnel externe qui fonctionne masque un tunnel interne cassé. Vérifiez le chemin externe avec un ping IPv4 du client vers le serveur et confirmez le port que vous utilisez. Puis vérifiez le chemin interne sur le serveur, où ip -6 route doit afficher une route par défaut ou une route précise apprise d’un véritable upstream, et ip -6 addr doit afficher un préfixe source que l’upstream accepte. Tout ce qui est moins que cela est de la décoration sur l’interface.

Une adresse unique-locale, ou un préfixe d’apparence globale vers lequel rien ne route en retour, apparaîtra volontiers sur une interface et n’ira nulle part. La joignabilité publique est accordée par l’upstream, pas par la forme de l’adresse.

Il en va de même chez le client : ip -6 route get 2001:4860:4860::8888 devrait nommer l’appareil de tunnel, et s’il nomme l’appareil physique, le client n’utilise pas du tout le VPN pour IPv6.

Préfixe source, taille et ICMPv6

Demandez à l’upstream quels préfixes source il acceptera pour le transfert, et utilisez l’un d’eux pour le pool client. Un fournisseur qui vous donne un /64 pour l’interface du serveur lui-même ne vous route pas forcément un second /64 ni un bloc plus grand, et la différence est un après-midi de débogage qu’un ticket de support règle en une question. Demandez-le par écrit et conservez la réponse avec la configuration.

Prévoyez l’encapsulation supplémentaire que votre pile utilise réellement, et maintenez ICMPv6 fonctionnel, y compris Packet Too Big. Un second en-tête réduit la charge utile, si bien qu’un chemin qui répond à de petits pings peut encore échouer lors d’un transfert de fichier, et un pare-feu qui jette tout ICMPv6 transforme un problème de taille récupérable en trou noir. Testez un gros transfert avant d’annoncer le service.

Ce qui est un problème entièrement différent

Atteindre une application uniquement IPv4 depuis un client uniquement IPv6 est de la traduction, pas du tunneling, et nécessite quelque chose comme un déploiement délibéré de NAT64. La destination ne comprendra pas un en-tête de tunnel supplémentaire simplement parce que vous en avez ajouté un. Les services de transition historiques méritent le même soin : la RFC 7526 a déprécié le modèle de relais anycast 6to4, donc un tutoriel écrit autour de lui décrit quelque chose qui n’a plus de relais public maintenu.

Si le serveur n’a aucun upstream IPv6 utilisable, les choix sont un upstream pris en charge, une autre sortie ou une décision documentée que IPv6 reste hors du tunnel. Ce qui n’est pas acceptable, c’est de dire aux clients qu’un service IPv6 existe alors que leur connexion IPv6 ordinaire contourne discrètement le VPN.