Une adresse IPv6 globale ne signifie pas que le trafic contourne le tunnel

Une page de test signale une adresse IPv6 globale et la conclusion saute aussitôt à un trafic qui contourne le VPN. Cette conclusion exige deux faits que la page n’a jamais montrés : quelle application a fait la requête, et quelle route le noyau a choisie pour elle. La portée d’une adresse décrit jusqu’où cette adresse peut être routée. Elle ne dit rien de l’endroit où ce paquet précis est allé.

La portée et le rôle sont deux questions différentes, avec des preuves différentes.

La portée répond qui peut la router, pas qui le fait

Les adresses unicast globales sont en principe routables sur l’internet public, les adresses locales uniques sont destinées à la topologie interne, et les adresses locales de lien n’existent que sur un seul lien. Ce sont des propriétés du bloc d’adresses. Qu’un paquet vers une destination donnée sorte par le tunnel, ce sont la table de routage et la politique attachée à l’interface qui le décident, et les deux peuvent pointer dans n’importe quel sens.

Une adresse peut avoir une portée globale et être tout de même transportée dans un tunnel, parce que le tunnel est un chemin et non un plan d’adressage.

Lisez toutes les adresses de l’interface, pas le test web

La sortie de l’interface affiche plusieurs adresses à la fois : l’adresse extérieure sur le lien physique, l’adresse du tunnel et une adresse locale de lien par interface. Le test web ne montre que l’adresse source d’une requête. Commencez par ip -6 addr show et notez quelle interface possède chaque adresse et quelle longueur de préfixe elle porte, puis demandez quelle interface la requête a réellement utilisée.

Comparez cela avec ip -6 route get 2606:4700::1111, qui affiche l’interface et la source que le noyau choisirait pour une destination.

Comment un préfixe global se retrouve à l’intérieur d’un tunnel

Deux conceptions produisent une adresse globale sur une interface de tunnel. Le fournisseur peut déléguer un préfixe routé vers le client à travers le tunnel, ce qui rend l’adresse globale alors que le chemin reste le tunnel. Ou bien le client conserve son adresse globale d’origine et le tunnel la transporte comme trafic interne pendant que l’en-tête extérieur fait le travail. Aucune des deux conceptions n’exige de traduction, et la confusion commence là où les habitudes d’IPv4 NAT sont prises pour une exigence d’IPv6.

Demandez à l’administrateur laquelle des deux s’applique. La réponse détermine ce qu’un serveur d’en face voit comme votre source.

Pourquoi une adresse d’apparence privée n’est pas un signal de confiance

Une adresse locale unique dit que l’opérateur la destine au routage interne, et rien de plus. Elle ne prouve pas que l’appareil est administré, que le logiciel est fiable ou que le trafic est chiffré. À l’inverse, une adresse globale ne prouve pas que le trafic a échappé au tunnel, et c’est précisément cette supposition que tout cet article existe pour démonter.

Jugez la confiance sur la politique, l’authentification et le chiffrement. L’apparence d’une adresse est une heuristique faible qui échoue dans les deux sens.

Testez la route et la politique comme deux questions

D’abord la route : exécutez curl -6 https://ifconfig.me à travers le tunnel puis à travers l’interface physique, et comparez les réponses. Ensuite la politique : confirmez quel préfixe le tunnel transporte réellement et si l’autre côté a une route de retour pour celui-ci. Une requête réussie vers un site public ne prouve ni l’un ni l’autre, car cette destination est joignable depuis n’importe où. Utilisez une destination interne pour le test de politique.

Notez l’adresse source que chaque chemin a produite. C’est la preuve dont une affirmation de contournement a réellement besoin.