Désactiver IPv6 pour corriger une fuite VPN ? Décidez plutôt la politique

Une adresse de la plage IPv6 apparaît sur une page de test, le tunnel ne la transporte manifestement pas, et le conseil le plus populaire d'internet est de désactiver IPv6 partout. Cette commande fait effectivement taire le panneau. Elle supprime aussi un protocole dont le réseau d'accès peut dépendre, et elle vous laisse sans idée si l'adresse était une vraie fuite, une adresse d'interface link-local ou un résolveur qui fait son travail. Trois conditions décident du bon contrôle, et une seule mène au blocage.

Identifiez ce que l'outil a réellement mesuré

La fausse alerte la plus courante est une adresse link-local, qui commence par fe80: et existe sur toute interface compatible IPv6, que la machine atteigne internet en IPv6 ou non. Elle apparaît dans les listes d'interfaces et dans certains diagnostics d'applications, et elle ne dit rien du chemin de votre trafic.

La deuxième fausse alerte est une adresse locale unique dans fc00::/7, qui est une plage privée utilisée à l'intérieur d'un réseau. Un outil qui imprime toutes les adresses de l'hôte la listera volontiers à côté de la publique. Qui lit vite appelle cela une fuite, puis passe une heure sur un problème qui n'existe pas.

La troisième n'est pas du tout une fausse alerte. Une adresse globale qui atteint internet hors du tunnel est la vraie fuite, et elle mérite d'être mesurée avant de décider quoi que ce soit :

ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co

Si la première commande imprime une adresse globale et que la troisième renvoie une adresse IPv6 publique qui n'est pas celle du tunnel, vous avez un vrai chemin hors du tunnel. Si la première n'imprime que des entrées link-local, il n'y a jamais eu de fuite à corriger.

Trois conditions décident du contrôle

La décision n'est pas « IPv6 bon » ou « IPv6 mauvais ». Elle consiste à savoir dans laquelle de trois situations vous êtes, et chacune a une bonne réponse différente avec un coût différent si vous vous trompez.

La première ligne est ce que les gens veulent dire d'habitude, et elle est légitime. Un client dont la sortie ne prend pas en charge IPv6 ne devrait pas laisser sortir en silence le trafic IPv6 natif de l'hôte, car c'est la fuite documentée en double pile. Le but est de la bloquer comme politique déclarée, pas de désactiver un protocole au niveau du noyau. Le résultat visible est identique et un seul des deux peut être audité plus tard.

La troisième ligne est là où le conseil général devient activement nuisible. Les opérateurs mobiles et certaines connexions domestiques exploitent des réseaux IPv6-only avec traduction pour les destinations IPv4. Retirez IPv6 là-bas et vous retirez le seul transport que le réseau propose, ce qui produit une panne bien pire que celle que vous déboguiez.

Si la sortie n'a pas d'IPv6, bloquez-le exprès

Préférez le mécanisme propre au client, car il s'applique exactement tant que le tunnel est actif et se retire quand il tombe. OpenVPN dispose d'une option pour cela, et iptables a une règle équivalente pour les autres clients :

block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachable

La directive appartient au profil ; la règle appartient à un pare-feu que vous pouvez auditer et retirer. Les deux échouent en fermé, ce que vous voulez, et les deux sont visibles dans un diff de configuration, ce qu'un sysctl du noyau enterré dans un script de démarrage n'est pas.

Notez pourquoi elle est là. Une règle de blocage sans commentaire sera retirée par la personne suivante qui a besoin d'IPv6 pour autre chose, et la fuite reviendra discrètement.

Si la sortie transporte IPv6, routez-le et testez les deux familles

Transporter IPv6 est la meilleure réponse quand le serveur le prend en charge, et ce n'est pas beaucoup plus difficile. L'exigence est que l'interface du tunnel ait une adresse dans cette famille et que la route par défaut correspondante pointe vers le tunnel plutôt que hors de l'interface physique :

ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.co

La recherche de route est le test décisif : si elle nomme l'interface du tunnel, le trafic IPv6 est transporté. Les deux appels curl confirment ensuite ce que voit chaque famille, et les comparer est la façon de prouver que les deux chemins sortent désormais par la même sortie.

Ne vous arrêtez pas à une connexion réussie. Reconnectez le tunnel et vérifiez à nouveau, car une route IPv6 poussée peut se perdre au rétablissement si le serveur ne l'envoie que dans la configuration initiale. Vérifiez ensuite une destination exclue, car les règles de tunnel divisé sont là où les deux familles divergent le plus souvent.

Si le réseau d'accès est uniquement IPv6, laissez-le tranquille

Certains réseaux ne fournissent qu'IPv6 et attendent que l'appareil atteigne les services IPv4 via un mécanisme de traduction côté opérateur. Désactiver IPv6 sur une telle machine n'est pas une amélioration de sécurité ; cela retire la seule route vers quoi que ce soit. C'est une panne auto-infligée au service d'un résultat de test dont personne n'avait besoin.

Le symptôme de cette erreur est distinctif et désagréable : le tunnel semble s'établir, la résolution de noms fonctionne, et rien ne se charge. Si vous voyez cela après un changement IPv6, restaurez le réglage immédiatement et poursuivez le diagnostic ailleurs.

Quoi que vous choisissiez, gardez la décision explicite dans le profil ou le pare-feu, liez-la à ce que la sortie prend réellement en charge, et notez le comportement de double pile que décrit la discussion sur la double pile du RFC 7359 . Un blocage déclaré est une politique. Un protocole désactivé est un contournement que personne ne peut auditer, et depuis la page de test, ils se ressemblent.