Quel VPN évite les fuites IPv6 sans devoir désactiver IPv6 ? J’avais corrigé la fuite en cassant la mauvaise chose

J’avais déjà corrigé ma fuite IPv6.

J’avais simplement désactivé IPv6.

La case « Internet Protocol Version 6 » n’était plus cochée dans Windows. J’ai relancé le VPN que j’utilisais, ouvert le test d’adresse IP et obtenu exactement ce que je voulais: seule l’adresse du VPN apparaissait.

Problème réglé.

J’ai gardé cette configuration une dizaine de minutes.

Puis je suis retourné la réactiver.

Ce qui me gênait n’était pas que la solution soit compliquée. Au contraire, elle était presque trop facile: mon VPN laissait passer quelque chose, alors j’avais supprimé cette chose du système.

Cela ressemblait moins à réparer une fuite qu’à couper l’arrivée d’eau.

Et en France, en 2026, IPv6 n’est plus vraiment une fonction expérimentale que l’on peut oublier dans un coin des paramètres réseau.

Désactiver IPv6 était devenu une drôle de solution permanente

Le dernier baromètre de l’Arcep, publié en juillet 2026, montre à quel point le paysage a changé. Fin 2025, IPv6 était activé chez 94 % des clients fixes grand public français et 83 % des clients mobiles. Orange, Bouygues Telecom et Free avaient pratiquement terminé leur transition sur le fixe, et la France atteignait 75,6 % de connectivité IPv6 en mars 2026, la plaçant en tête du classement suivi par l’Arcep.

Ce n’était donc pas seulement mon ordinateur qui avait décidé d’activer un protocole dont personne ne se servait.

Mon accès Internet était réellement dual-stack: IPv4 et IPv6 coexistaient.

Microsoft ne recommande d’ailleurs pas de désactiver IPv6 dans Windows comme solution générale. Sa documentation rappelle que le protocole fait partie intégrante des versions modernes du système et que certains composants peuvent mal fonctionner si on le désactive ou si on le dissocie des interfaces réseau.

J’avais donc réussi mon test de confidentialité de la manière la moins satisfaisante possible.

Le VPN n’avait plus de fuite IPv6 parce que j’avais demandé à Windows de ne plus avoir de route IPv6 à faire fuir.

Ce n’était pas ce que je voulais.

Je voulais garder IPv6 disponible sur mon ordinateur et demander au VPN de s’occuper correctement du trafic pendant qu’il était connecté.

Mon adresse IPv4 était cachée, mon IPv6 ne l’était pas

Avant de décocher quoi que ce soit dans Windows, le résultat avait été très lisible.

VPN connecté:

adresse IPv4 → celle du VPN.

Adresse IPv6 → celle fournie par mon accès Internet.

C’est précisément le genre de situation qui rend une fuite IPv6 facile à manquer.

Si je consultais seulement un site affichant une adresse IPv4, tout semblait normal. Le pays avait changé. L’adresse IPv4 de mon opérateur avait disparu. L’icône du VPN était verte.

Il fallait tester les deux familles d’adresses pour voir qu’une deuxième porte était restée ouverte.

Le mécanisme n’est pas nouveau. L’IETF documente depuis longtemps le problème des machines dual-stack utilisant un VPN qui traite IPv4 mais laisse IPv6 continuer à utiliser directement le réseau local.

L’image qui m’a finalement permis de ne plus confondre les deux était celle d’un immeuble avec deux sorties.

J’avais placé un gardien devant la porte IPv4.

Puis j’avais supposé que tout le monde passerait par lui.

IPv6 était simplement sorti par l’autre porte.

Et plus IPv6 devient courant, moins cette deuxième porte peut être considérée comme un détail.

Le problème est beaucoup moins théorique qu’il y a quelques années

Une étude publiée fin 2025 par Yejin Cho et John Heidemann, de l’USC Information Sciences Institute, m’a empêché de classer cela parmi les vieilles bizarreries de VPN.

Les chercheurs ont travaillé à partir d’un ensemble de 129 000 visiteurs quotidiens utilisant des VPN. Ils ont constaté que des services IPv4-only pouvaient encore exposer l’adresse IPv6 native de certains utilisateurs. Parmi les VPN étudiés, douze considérés auparavant comme sûrs présentaient une fuite pour au moins 5 % des utilisateurs observés; pour certains services IPv4-only, la proportion d’utilisateurs dont l’IPv6 native apparaissait allait de 5 % à 57 %. (USC Information Sciences Institute)

Mon résultat me semblait soudain beaucoup moins exotique.

Le système disposait de deux routes Internet. Le VPN protégeait celle que je regardais en premier, tandis que l’autre pouvait encore révéler l’adresse de mon accès.

Une discussion publique sur r/WireGuard montre bien à quel point la confusion peut être simple: un utilisateur cherchait à savoir si AllowedIPs = 0.0.0.0/0 suffisait à empêcher une fuite ou s’il fallait également prendre en compte ::/0 pour IPv6.

La documentation de WireGuard permet de comprendre la différence sans aller beaucoup plus loin: 0.0.0.0/0 couvre les destinations IPv4; ::/0 couvre les destinations IPv6.

Autrement dit, on peut croire avoir demandé « tout le trafic » alors qu’on n’a en réalité parlé que de la première porte.

J’aurais pu réparer mon profil à la main

C’était ma deuxième option.

Modifier la configuration.

Ajouter la route IPv6 appropriée.

Vérifier que l’autre extrémité du tunnel la gérait comme prévu.

Relancer les tests.

Éventuellement ajouter des règles empêchant IPv6 de sortir directement lorsque le tunnel était actif.

C’était faisable, mais j’ai arrêté là.

Je n’essayais pas d’apprendre à construire moi-même une politique de routage dual-stack.

Ma question était beaucoup plus ordinaire:

« Quel VPN puis-je connecter sans que mon IPv6 réel réapparaisse derrière ? »

Et surtout, je ne voulais plus que la réponse soit: « désactive IPv6 dans Windows avant de te connecter, puis pense à le remettre après ».

C’est à ce moment-là que mon critère de choix a réellement changé.

Je ne cherchais plus un VPN qui remplaçait correctement mon IPv4.

Je cherchais celui qui s’occupait aussi de la deuxième sortie sans me demander de la condamner moi-même.

J’ai remis IPv6 comme avant, puis changé de VPN

J’ai donc commencé par annuler mon propre correctif.

IPv6 réactivé sur l’adaptateur.

Déconnexion de l’ancien tunnel.

Test sans VPN.

Mon IPv4 habituelle apparaissait.

Mon IPv6 habituelle aussi.

Parfait.

Je voulais justement repartir d’un ordinateur où IPv6 fonctionnait normalement.

J’ai ensuite ouvert OnlydogVPN^↗ et utilisé le mode confidentialité.

Connexion.

Je n’ai touché ni au registre Windows, ni aux propriétés de l’adaptateur, ni à IPv6.

J’ai relancé le même test.

L’IPv4 de mon fournisseur d’accès avait disparu.

Surtout, son IPv6 native n’apparaissait plus non plus.

J’ai ouvert un second test, simplement pour ne pas tirer ma conclusion d’une seule page.

Même résultat.

Puis j’ai déconnecté le VPN.

Mon IPv6 normale est revenue.

C’est ce dernier passage qui m’a convaincu davantage que n’importe quelle ligne dans une fiche technique.

Je n’avais pas transformé une préférence de confidentialité temporaire en modification permanente du système.

VPN activé: mon IPv6 d’opérateur n’était pas exposée.

VPN coupé: Windows retrouvait son fonctionnement IPv6 normal.

Je n’avais plus à me souvenir de retourner bricoler la carte réseau.

Ce qui comptait était la fuite, pas le vocabulaire de la fiche technique

Un test d’adresse IP ne raconte pas toute l’architecture interne d’un VPN. Le fait que mon IPv6 native ait disparu ne signifie pas nécessairement qu’une nouvelle IPv6 m’a été attribuée à l’intérieur du tunnel.

Mais ce n’était pas la question qui m’avait conduit jusque-là.

Je voulais empêcher mon adresse IPv6 réelle de contourner la protection alors qu’IPv6 restait activé sur la machine.

Le test répondait directement à cette question.

Et c’est là que la différence avec mon premier « correctif » devenait assez nette.

Avec l’ancien VPN, j’avais obtenu le résultat en retirant IPv6 du système.

Avec le mode confidentialité du second, j’avais laissé Windows tranquille et l’adresse que je ne voulais pas exposer avait disparu pendant la connexion.

Je préfère aujourd’hui ce test très concret à une fiche indiquant simplement « IPv6 » ou « protection contre les fuites ».

Je laisse IPv6 activé.

Je regarde ce qu’Internet voit sans VPN.

Je connecte le VPN.

Je regarde ce qu’Internet voit ensuite.

La comparaison est difficile à embellir avec du marketing.

La solution la plus radicale était devenue la moins logique

J’ai repensé à ma première manipulation.

Décocher IPv6 avait fonctionné.

Pour un ancien client VPN incapable de gérer correctement un environnement dual-stack, bloquer IPv6 peut effectivement empêcher le trafic de contourner le tunnel.

Mais ce qui pouvait sembler acceptable quand IPv6 était rare devient beaucoup moins séduisant quand 94 % des accès fixes français l’ont déjà activé.

Surtout, je ne voyais plus pourquoi Windows devait être modifié en permanence pour compenser la façon dont mon VPN gérait la connexion.

Le petit service a moins de régions qu’un grand fournisseur et beaucoup moins d’historique public. Si mon critère principal était de disposer de la plus grande carte possible de destinations, ce serait un compromis réel.

Mais une fuite IPv6 n’est pas résolue par cinquante pays supplémentaires.

Elle est résolue quand la connexion que je veux protéger ne dispose plus d’une sortie oubliée.

Dans mon test, c’est exactement ce que j’ai obtenu sans toucher à la configuration IPv6 du système.

Ce que je regarderais aujourd’hui

Je ne commencerais plus par le nombre de serveurs.

Je commencerais avec IPv6 activé.

D’abord sans VPN, pour confirmer que mon fournisseur d’accès m’attribue bien une IPv6.

Puis avec le VPN.

Si l’adresse IPv4 change mais que l’IPv6 de l’opérateur reste visible, le tunnel ne protège pas toute la connexion comme je l’imaginais.

Désactiver IPv6 peut faire disparaître le symptôme.

Mais ce n’est pas le même résultat qu’utiliser un VPN qui empêche cette adresse de s’échapper pendant qu’IPv6 reste configuré normalement sur l’appareil.

C’est cette différence qui a décidé pour moi.

Mon ancienne configuration réussissait le test à condition que je modifie Windows.

Le mode confidentialité du petit service l’a réussi après que j’avais remis Windows dans son état normal.

Je pensais chercher un VPN capable de « supporter IPv6 ».

En réalité, mon critère était beaucoup plus simple: laisser IPv6 activé et ne plus voir l’adresse de mon opérateur dès que le tunnel est en place.

La fuite a disparu deux fois; la première fois, j’avais dû fermer la porte IPv6 moi-même, la seconde, j’ai simplement fermé le VPN quand j’avais fini.