Votre VPN transporte-t-il IPv6, ou ne fait-il qu’atteindre le serveur ?

Un test de fuite IPv4 seul revient propre, un test IPv6 affiche votre adresse de domicile, et le tunnel est nominalement connecté. Cette combinaison est courante sur les réseaux double pile, parce que le VPN a changé le chemin d’une famille et a laissé l’autre tranquille. Le tunnel extérieur et le trafic qu’il contient sont deux décisions d’adressage distinctes. Tester l’une ne dit rien de l’autre.

Vérifiez à la fois ce que le client rapporte et quelle famille la requête a réellement utilisée, car un nom d’hôte peut renvoyer les deux types de réponse.

Deux familles, deux chemins différents

Le système d’exploitation tient une table de routage par famille d’adresses. Installer une route par défaut pour IPv4 n’en installe pas une pour IPv6, et un point de terminaison de tunnel joignable en IPv4 ne dit rien sur l’entrée du trafic IPv6 dans celui-ci. Quand aucune route par défaut IPv6 n’existe à travers le tunnel, l’hôte utilise le chemin IPv6 dont il dispose, souvent la liaison physique. Du point de vue de l’application, la connexion est simplement directe.

Un nom d’hôte qui renvoie à la fois des enregistrements A et AAAA rend cela plus difficile à voir, car les applications peuvent essayer les familles dans des ordres différents. Une requête qui réussit ne prouve pas quel chemin elle a pris. Utilisez un test qui nomme la famille qu’il a exercée.

Atteindre le serveur n’est pas transporter le trafic

Les fournisseurs emploient l’expression prise en charge d’IPv6 pour plusieurs capacités différentes. Le point de terminaison peut accepter une connexion en IPv6 alors que le tunnel ne transporte encore qu’IPv4. Le tunnel peut transporter des paquets internes IPv6 alors que le transport extérieur reste en IPv4. Ou le client peut bloquer entièrement IPv6 pour que rien ne s’échappe hors du tunnel. Ce sont trois comportements distincts, et une page qui dit seulement IPv6 pris en charge ne les distingue pas.

Demandez lequel la conception exige. Un réseau qui doit atteindre des services uniquement IPv6 a besoin de transport. Un réseau qui doit empêcher le trafic IPv6 direct a besoin d’un blocage ou d’un transport complet, pas d’une étiquette sur une page marketing.

Décidez entre transporter et bloquer

Transporter signifie que le tunnel possède une adresse IPv6, une route par défaut à l’intérieur et une politique autorisant le trafic aux deux extrémités. Bloquer signifie que le client empêche délibérément IPv6 de sortir hors du tunnel, ce qui est sûr et inutile pour atteindre des destinations IPv6. Les deux sont légitimes ; aucun n’est un défaut que vous pouvez supposer. Choisissez d’abord l’exigence, puis vérifiez que le client l’implémente réellement.

Un réseau invité en IPv4 seul ne peut pas exercer un chemin IPv6, donc un test effectué là-bas ne dit rien du réseau domestique où les deux familles existent. Testez là où la famille concernée est réellement proposée.

Le coupe-circuit a besoin de la même couverture

Un coupe-circuit qui ne couvre qu’IPv4 laisse l’autre famille libre de sortir directement, ce qui est exactement la fuite qu’il devait empêcher. Examinez ses règles pour les deux familles et pour les moments de transition, pendant que le tunnel monte ou descend. Désactiver IPv6 à l’échelle du système n’est pas un substitut : cela peut casser des services sans rapport et cache un problème de politique client derrière un changement à l’échelle de la machine.

Gardez le DNS séparé de tout cela. Le DNS concerne qui répond à la requête et comment la requête voyage ; la connexion applicative qui suit a son propre chemin. L’une peut être correcte alors que l’autre ne l’est pas, et les diagnostiquer ensemble produit des conclusions confuses.

Notez quelle famille chaque test a exercée et quelle capacité le client revendique. Cette paire de faits répond à la question à laquelle une étiquette de support ne répondra jamais.