Votre VPN est connecté. Le tunnel est actif, le client affiche protégé, et votre trafic IPv4 passe bien par lui. Et un site que vous visitez enregistre quand même votre adresse réelle, parce qu'il vous a joint en IPv6.
Il n'y a aucune panne à chercher. Ce sont deux systèmes corrects qui ne s'accordent pas, et ce désaccord est inscrit dans une norme.
Votre système ne dysfonctionne pas, il applique la RFC 6724
Quand une destination est joignable à la fois en IPv4 et en IPv6, il faut bien choisir. Ce qui choisit, c'est la RFC 6724, qui définit une table de politique par défaut pour la sélection d'adresses. Trois de ses lignes comptent ici :
Prefix Precedence Label
::1/128 50 0
::/0 40 1
::ffff:0:0/96 35 4
::/0, c'est l'IPv6 en général. ::ffff:0:0/96, c'est la façon dont les adresses IPv4 sont représentées dans cette table. Quarante l'emporte sur trente-cinq, et la règle de sélection de destination est explicite : si Precedence(DA) > Precedence(DB), alors préférer DA.
La RFC énonce la conséquence en clair plutôt que de vous laisser la déduire : un autre effet de la table de politique par défaut est de préférer la communication en adresses IPv6 à la communication en adresses IPv4, si des adresses source correspondantes sont disponibles.
Pour chaque site en double pile que vous visitez, votre système d'exploitation tend donc d'abord vers l'IPv6. C'est un comportement correct, et il est bien antérieur à votre VPN.
Pourquoi cela devient une fuite
Posez maintenant par-dessus un VPN qui ne transporte que l'IPv4.
Votre machine conserve une adresse IPv6 native fournie par votre opérateur. Le tunnel ne revendique pas le trafic IPv6, donc rien ne l'intercepte. Votre système, appliquant la règle ci-dessus, préfère l'IPv6 pour toute destination qui en propose. Résultat : votre chemin préféré est celui qui contourne le tunnel, et le chemin protégé ne reçoit que ce que l'IPv6 n'a pas pu servir.
Voilà pourquoi la fuite passe si facilement inaperçue. Elle n'a pas l'air d'un dysfonctionnement. Votre VPN affiche connecté parce qu'il l'est. Vos vérifications IPv4 passent parce qu'elles passent réellement. Le trafic qui s'échappe est précisément celui que votre système a jugé le meilleur.
Vérifier, et l'erreur qui rend la vérification inutile
La vérification est simple : VPN connecté, regardez ce qu'un site voit réellement, et lisez spécifiquement la ligne IPv6 plutôt que de jeter un œil à l'IPv4 et passer à autre chose.
Si l'adresse IPv6 affichée appartient à votre connexion plutôt qu'au fournisseur de VPN, l'IPv6 est hors du tunnel. Si aucune adresse IPv6 n'apparaît, soit votre réseau n'en a pas, soit elle est bloquée, et les deux cas sont sains du point de vue des fuites.
Deux choses ruinent cette vérification en pratique :
Tester avant de se connecter. La question n'est pas de quoi vous avez l'air sans protection. C'est ce qui s'échappe pendant que vous vous croyez protégé.
Ne tester qu'une fois. Une configuration qui transporte l'IPv6 aujourd'hui peut cesser de le faire après une reconnexion, un changement de réseau ou un passage du Wi-Fi aux données mobiles, parce que les adresses disponibles changent avec le réseau. Un unique résultat propre prouve que la configuration était correcte sur un réseau, à un instant.
La ligne qui compte, sur WireGuard
WireGuard rend la cause exceptionnellement lisible, parce que le même réglage décide à la fois de ce qui entre et de l'endroit où les choses sortent. Le manuel wg définit AllowedIPs comme une liste d'adresses IP (v4 ou v6) séparées par des virgules, avec masques CIDR, depuis lesquelles le trafic entrant de ce pair est autorisé et vers lesquelles le trafic sortant de ce pair est dirigé, et ajoute que le fourre-tout 0.0.0.0/0 peut être indiqué pour correspondre à toutes les adresses IPv4, et ::/0 pour correspondre à toutes les adresses IPv6.
Lisez cela comme une instruction de routage, car c'est ce que c'est. Un pair configuré avec le seul 0.0.0.0/0 dirige l'IPv4 dans le tunnel et ne dit rien de l'IPv6, qui continue donc d'emprunter la route normale. Ajouter ::/0 y dirige également l'IPv6.
Une condition s'applique : encore faut-il que le tunnel dispose de sa propre adresse IPv6. Si votre fournisseur n'en attribue pas, router ::/0 dans un tunnel sans extrémité IPv6 ne crée pas de connectivité IPv6. C'est à ce moment-là que bloquer l'IPv6 devient le repli honnête, et non un raccourci.
Bloquer l'IPv6 fonctionne, et coûte quelque chose
Désactiver l'IPv6 sur la machine supprime le chemin préféré : tout retombe en IPv4, donc dans le tunnel. C'est efficace, et c'est ce que font plusieurs clients VPN sous l'étiquette protection contre les fuites IPv6.
Le coût est réel malgré tout. Vous perdez l'IPv6 pour tout le reste sur cette machine, y compris sur les réseaux où c'est le seul transport utilisable, et le réglage survit à la raison qui vous l'a fait changer. Six mois plus tard, un problème de connectivité sans rapport devient très difficile à diagnostiquer parce que plus personne ne se souvient que l'IPv6 est coupé.
Router l'IPv6 dans le tunnel conserve la capacité et règle le même problème. Préférez-le chaque fois que votre fournisseur le permet, et traitez le blocage comme le repli pour les cas où il ne le permet pas.
Le kill switch ne couvre pas ce cas
À dire séparément, parce que les deux se confondent dans le même écran de réglages.
Un kill switch guette la chute du tunnel et coupe le trafic quand elle survient. Une fuite IPv6 se produit tunnel actif. Il n'y a aucune chute à détecter, aucun événement de panne, rien à quoi le dispositif puisse réagir. Un kill switch qui fonctionne parfaitement restera là à faire son travail impeccablement pendant que le trafic IPv6 passe devant lui.
Si votre client propose une protection contre les fuites IPv6 comme réglage distinct, c'est un mécanisme différent, et avoir l'un ne vous donne pas l'autre.
En résumé
Une fuite IPv6 n'est pas votre VPN qui casse. C'est la RFC 6724 qui dit à votre système de préférer l'IPv6, un tunnel qui ne transporte que l'IPv4, et la conséquence parfaitement logique de ces deux faits.
Vérifiez VPN connecté, lisez la ligne IPv6, et recommencez après un changement de réseau. Sur WireGuard, AllowedIPs est le réglage qui décide, et ::/0 est ce qui dirige l'IPv6 dans le tunnel. Là où le tunnel n'a pas d'IPv6 propre, bloquer l'IPv6 est un repli légitime, avec un coût qu'il vaut mieux noter quelque part où vous le retrouverez.
La table de politique par défaut, les valeurs de précédence, la règle de sélection de destination et l'énoncé selon lequel la table préfère la communication IPv6 à l'IPv4 proviennent de la RFC 6724. La définition d'AllowedIPs et la notation fourre-tout pour 0.0.0.0/0 et ::/0 proviennent de la page de manuel wg(8). Les deux ont été consultées au moment de la rédaction.
Guides liés
- Audit de sécurité VPN complet - les sept vérifications à faire une fois, dont celle-ci fait partie.
- Le kill switch VPN expliqué - le mécanisme qui traite le cas inverse, quand le tunnel tombe réellement.
Sécurise ta connexion avec NordVPN
Threat Protection bloque traqueurs & malwares · kill switch · 30 jours remboursé
