Comment tester l’IPv6 à travers un VPN avec votre propre ressource

Une page publique de vérification d’IP répond à une question, et généralement pas à celle que vous avez posée. Elle indique l’adresse de sortie que la page a observée ; elle ne dit pas si la route IPv6 à travers le tunnel fonctionne, si l’hôte a préféré IPv6 ou s’est rabattu, ni si une application exclue a pris un autre chemin. Une ressource autorisée que vous contrôlez répond correctement à la question plus étroite, parce que vous voyez les deux extrémités. Le mode opératoire ci-dessous porte sur l’obtention d’une conclusion défendable, pas sur l’obtention d’un résultat vert.

Étape 1 : précisez quelle route IPv6 vous testez

Dites-le en une phrase. Une requête vers l’adresse IPv6 du serveur du tunnel teste le tunnel ; une requête vers un hôte au-delà de la sortie teste la sortie IPv6 de la sortie ; une requête vers une adresse IPv6 privée teste une route interne.

Ce sont trois affirmations différentes et une seule requête réussie ne peut pas les étayer toutes. Choisissez celle qui compte pour la décision qui vous attend et notez-la avant de lancer quoi que ce soit. Si la préoccupation est de savoir si IPv6 fuit autour du tunnel, la question porte sur la sélection de route de l’hôte, pas sur l’accessibilité de la sortie. Si la préoccupation est de savoir si le côté distant peut atteindre un service interne, la sortie n’a pas d’importance.

Étape 2 : confirmez que l’hôte sélectionne cette route

ip -6 route get 2001:db8:1::10 affiche la route, l’adresse source et l’interface que le noyau utiliserait, et c’est ce fait dont dépend le reste du test.

Qu’une interface existe n’est pas la même chose qu’elle soit sélectionnée. Les hôtes à double pile ont une table de précédence, et /etc/gai.conf sous Linux peut changer quelle famille gagne pour un nom qui résout vers les deux.

Étape 3 : utilisez une destination et un nom légitimes

Si vous testez HTTPS, utilisez le nom d’hôte pour lequel le certificat a été émis et gardez la vérification active ; passer à une adresse littérale pour faire réussir le test désactive précisément le contrôle qui prouve que vous avez atteint l’hôte prévu. Un service de diagnostic que vous contrôlez, qui répond sur un nom connu avec un certificat valide, est la cible la plus propre. Il vous donne aussi une ligne de journal côté serveur avec laquelle corréler, ce qu’un vérificateur tiers ne fera jamais.

Lancez la requête sous une forme qui montre l’adresse utilisée : curl -6 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://test6.example.net/. L’option -6 force la famille, et c’est ainsi que vous séparez IPv6 ne fonctionne pas de IPv6 n’a pas été préféré.

Pour un simple contrôle d’accessibilité où ICMPv6 est autorisé, ping -6 -c 3 2001:db8:1::10 suffit. Il prouve le chemin et rien au-dessus.

Étape 4 : corrélez les deux extrémités

Lorsque vous avez accès aux deux extrémités, lancez tcpdump -ni any ip6 and host 2001:db8:1::10 sur le client et l’équivalent sur la ressource, avec des horodatages, et confirmez que le même flux apparaît des deux côtés. C’est ce qui transforme un résultat plausible en preuve : la vue du client seule ne peut pas distinguer une réponse de la ressource d’une réponse de quelque chose entre les deux. Gardez la capture étroite sur la seule destination afin que la sortie reste lisible et que la session sans rapport de quiconque ne finisse pas dans le fichier.

Répétez le test après une reconnexion si la préoccupation est de savoir si la politique survit à un redémarrage. L’état de route et de pare-feu appliqué une fois à la connexion peut différer de l’état réappliqué, et la différence n’apparaît qu’à la seconde connexion.

Testez le cas d’échec séparément si vous en avez besoin. Un tunnel qui bloque IPv6 quand il tombe et un autre qui le laisse fuir sont des conceptions différentes, et une seule des deux peut être vérifiée par une requête réussie.

Étape 5 : notez ce que le test n’a pas prouvé

La cinquième étape consiste à noter ce que le test n’a pas prouvé, et c’est la partie que l’on oublie. Un test réussi vers un point de terminaison privé ne prouve pas la sortie IPv6 publique, ne prouve pas le comportement DNS et ne couvre pas les applications que vous avez exclues du tunnel. Chacun de ces points demande sa propre destination et sa propre observation. Une note disant qu’IPv6 fonctionne après une requête vers un hôte n’est pas un constat ; c’est une supposition avec un horodatage.

L’enregistrement qui vaut la peine d’être conservé est court : la destination, le nom, l’adresse source choisie par l’hôte, l’adresse distante observée et l’heure. RFC 7359 explique comment vérifier qu’une route IPv6 pertinente est réellement utilisable, et c’est la norme que ce mode opératoire approche avec des outils plus simples. Si la conclusion a besoin d’un vérificateur public pour être vraie, le test n’était pas assez précis.