Le trafic IPv6 hors du VPN : trouver la route qui fuit

Deux pages de test se contredisent : l’une rapporte l’adresse du fournisseur à travers le tunnel, la seconde rapporte votre préfixe domestique, et la conclusion évidente est que le VPN fuit. Cette conclusion saute une étape, car les deux rapports ont exercé deux décisions de routage différentes et une seule devait entrer dans le tunnel. L’écart est généralement réel, et c’est un problème de couverture, non un tunnel cassé. Trois questions le règlent : quel flux est réellement sorti, quelle route le noyau a choisie pour lui, et quel comportement le client visait.

Travaillez dans cet ordre. Y répondre dans le désordre produit une longue discussion sur la question de savoir si le client est défectueux, alors que la vraie réponse est qu’aucune route IPv6 n’a jamais été installée.

Quel flux est réellement sorti, et par quelle carte réseau

Commencez par un test qui nomme la famille utilisée, puis notez l’application, le réseau d’accès, le profil en vigueur et si la connexion propose IPv6 du tout. Ces quatre faits rendent deux exécutions comparables, et le quatrième est celui qu’on oublie : un réseau sans préfixe v6 ne peut pas fuiter de v6, et un réseau qui en ajoute un plus tard change la réponse.

Envoyez une requête par famille plutôt que de charger une page et d’en lire le résultat. Une seule page peut mélanger des ressources v6 et v4, un processus en arrière-plan peut se comporter autrement que l’onglet devant vous, et une réponse en cache peut survivre au changement de réseau que vous cherchez à tester. Fixez la destination testée et notez-la, pour qu’une exécution répétée mesure la même chose.

Lire la route que le noyau a choisie

La table de routage répond à la question que le navigateur ne peut pas traiter. Demandez au système où irait une destination précise, et incluez les règles de politique autant que la route par défaut visible, car l’une comme l’autre peut la supplanter :

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

Un préfixe plus spécifique est la raison habituelle pour laquelle une destination reste hors du tunnel alors que tout le reste y demeure, et une règle de politique peut faire de même avec une priorité supérieure à celle de toute route. Lisez aussi la métrique, car deux entrées pour le même préfixe se départagent par la métrique et non par leur ordre à l’écran. Sous Windows, la liste équivalente est Get-NetRoute -AddressFamily IPv6, triée par métrique pour correspondre à l’ordre de décision. Une règle qui semble correcte dans la table peut encore perdre contre une règle de politique au numéro plus bas, et c’est pourquoi la liste des règles va de pair avec celle des routes.

D’où vient la politique IPv6 du client

Un client peut être conçu pour faire passer le v6 par le tunnel, pour le refuser ou pour autoriser une exception nommée, et ces trois intentions donnent trois résultats corrects différents. Lisez le profil et la documentation du client avant de qualifier une observation de fuite, car un client qui bloque le v6 alors que le système d’exploitation envoie encore la découverte de voisins sur le lien physique se comporte comme prévu.

Une application délibérément exclue du tunnel est un cas différent d’une famille que le tunnel n’a jamais transportée. Le premier est une décision sur un programme, le second est un trou de couverture, et la réparation diffère en conséquence. Lisez la liste des programmes exclus du client avant de chercher une route qui n’aurait jamais dû exister.

Observation étroite, quand la table contredit

Quand la recherche de route est ambiguë, une observation d’interface sur l’hôte peut trancher, mais seulement si elle vise la question. Le trafic vers le point de terminaison du VPN traversera la carte physique par conception ; ce qui compte, c’est de savoir si le flux applicatif, adressé tout ailleurs, y apparaît aussi. Filtrez la capture sur la destination testée plutôt que de tout collecter.

Une capture large expose bien plus de trafic personnel que la seule question ne l’exige. Elle répond aussi moins clairement, car le flux qui vous intéresse arrive enfoui dans un flot de connexions sans rapport. Filtrez sur la destination testée, arrêtez après une poignée de paquets et supprimez la capture.

Trois façons de combler l’écart

Faites passer la famille par le tunnel, bloquez-la dans le client quand le tunnel ne peut pas la transporter, ou consignez une exception délibérée avec un responsable et une date de révision. Chacune se défend, et la seule chose qui ne se défend pas est de laisser le choix implicite, car un choix implicite est exactement ce qu’est la fuite. Si le tunnel n’a aucune sortie v6, refuser le v6 dans le client est à la fois honnête et vérifiable. Ce qui compte, c’est que le choix soit écrit là où la personne suivante le trouvera, et non déduit du comportement six mois plus tard.

Répétez le contrôle après une reconnexion et après un changement de réseau, car une route installée pour le lien précédent peut survivre au changement. Consignez ensuite la destination, la route retenue, la politique du client et la famille utilisée par le test, afin que la personne suivante lise une décision au lieu de la redériver. RFC 7359 documente la fuite en double pile comme un problème de conception et non comme un bug, et c’est la référence à citer quand quelqu’un affirme qu’un tunnel v4 qui fonctionne couvre tout.