Quel VPN protège contre les fuites DNS, IPv6 et WebRTC ? J’ai arrêté de vouloir faire disparaître toutes les lignes du test

Mon VPN avait réussi le test que je connaissais.

Adresse IP: Paris.

Très bien.

Puis j’ai fait l’erreur de continuer à faire défiler la page.

DNS: plusieurs adresses que je ne reconnaissais pas.

IPv6: une longue suite de chiffres qui n’avait rien à voir avec l’adresse IPv4 du VPN.

WebRTC: encore autre chose.

En cinq minutes, une connexion qui me paraissait parfaitement protégée s’était transformée en trois problèmes différents.

Je venais de passer sur une nouvelle connexion fibre et je voulais simplement vérifier mon ordinateur avant de reprendre une série de recherches et une visioconférence dans le navigateur.

À la place, j’ai commencé à réparer le test.

J’ai changé le DNS.

J’ai désactivé IPv6.

J’ai installé un bloqueur WebRTC.

Le résultat est devenu beaucoup plus joli.

Puis ma visioconférence a cessé de démarrer correctement.

C’est là que j’ai compris que mon objectif n’aurait jamais dû être d’obtenir une page vide.

IPv6 n’est plus un détail que je peux supposer absent

Pendant longtemps, j’avais testé mes VPN comme si Internet était essentiellement IPv4.

Je regardais mon adresse avant.

J’activais le VPN.

Je regardais mon adresse après.

Différente ?

Parfait.

En France, cette méthode devient de moins en moins suffisante.

Le baromètre publié par l’Arcep en juillet 2026 indique qu’à la fin de 2025, IPv6 était déjà activé pour 94 % des clients fixes grand public et 83 % des clients mobiles. Chez Free, Orange et Bouygues Telecom, l’activation sur le fixe atteignait respectivement 99 %, 97 % et 96 %.

Autrement dit, mon ordinateur pouvait très naturellement disposer de deux chemins:

IPv4.

Et IPv6.

Si le VPN prend correctement les deux en charge, rien d’inquiétant.

Mais si je vérifie uniquement que mon IPv4 résidentielle a disparu, je peux applaudir un tunnel alors qu’un deuxième chemin reste disponible à côté.

Des travaux de Yejin Cho et John Heidemann sur le comportement IPv4 et IPv6 de VPN commerciaux ont justement observé que certains services principalement centrés sur IPv4 pouvaient laisser apparaître l’IPv6 native de l’utilisateur.

Cette fois, la longue adresse affichée dans mon test n’était donc plus une ligne que je pouvais ignorer.

Mais la faire disparaître à coups de réglages n’était pas non plus la bonne solution.

J’avais confondu trois problèmes parce qu’ils apparaissaient sur la même page

C’est le piège des sites de test.

Ils mettent DNS, IPv6 et WebRTC les uns sous les autres.

Visuellement, tout ressemble au même problème:

une adresse que je ne voulais pas voir.

En réalité, ils vérifient trois chemins différents.

Le DNS demande en substance:

qui traduit les noms de domaine que je consulte ?

IPv6 demande:

mon appareil possède-t-il un deuxième chemin Internet qui échappe au tunnel ?

WebRTC demande plutôt:

quelles adresses mon navigateur peut-il utiliser ou révéler lorsqu’il cherche à établir une communication en temps réel ?

J’avais essayé de résoudre les trois avec trois boutons différents.

Et plus j’ajoutais de correctifs, moins je savais quel réglage protégeait réellement quoi.

Mon DNS « plus privé » avait créé sa propre route

Le premier résultat que j’ai voulu corriger était le DNS.

Quelques mois plus tôt, j’avais activé DNS over HTTPS dans mon navigateur et choisi moi-même un fournisseur.

VPN plus DNS chiffré.

Sur le papier, cela ressemblait à deux protections qui s’additionnaient.

Mais un DNS chiffré n’est pas automatiquement un DNS qui suit le VPN.

Mozilla explique que lorsqu’un résolveur DoH est explicitement sélectionné dans Firefox, ce choix peut prendre la priorité sur le résolveur fourni par le VPN.

J’avais donc construit deux routes de confidentialité qui ne prenaient pas forcément leurs décisions au même endroit.

Le DNS n’était pas nécessairement envoyé en clair.

Mais il n’était plus piloté par la même couche que le reste de ma connexion.

J’ai remis ce réglage en mode automatique.

Une décision de moins.

Et surtout, un test beaucoup plus facile à comprendre.

Désactiver IPv6 avait fonctionné — trop facilement

Mon deuxième correctif était encore plus radical.

L’adresse IPv6 me dérangeait ?

Très bien.

IPv6: désactivé dans l’adaptateur réseau.

Actualiser.

Plus d’IPv6.

Test réussi.

Pendant quelques minutes, cette méthode m’a paru parfaite.

Puis j’ai compris ce que je venais réellement de démontrer.

Je n’avais pas prouvé que mon VPN protégeait IPv6.

J’avais simplement interdit à mon ordinateur de l’utiliser.

Cela peut dépanner avec un VPN qui ne sait pas correctement gérer IPv6. Mais sur une fibre française où ce protocole est déjà devenu normal, je n’avais pas envie que ma protection dépende d’un réglage système à désactiver puis à ne surtout pas oublier.

Mon critère est devenu plus simple:

si mon appareil possède IPv6, mon adresse IPv6 résidentielle ne doit pas pouvoir sortir tranquillement à côté du tunnel.

Je voulais protéger le chemin.

Pas supprimer la route du système pour rendre le test plus beau.

Puis WebRTC m’a fait paniquer pour la mauvaise adresse

Le troisième résultat semblait le plus inquiétant.

WebRTC affichait encore une adresse locale.

Mon premier réflexe a été:

fuite.

J’ai installé une extension censée bloquer WebRTC.

La ligne a disparu.

Mais quelques minutes plus tard, l’outil de visioconférence que je devais utiliser dans le navigateur s’est mis à mal fonctionner.

J’avais littéralement désactivé une technologie de communication parce qu’un site de test m’avait montré qu’elle communiquait.

WebRTC utilise plusieurs chemins possibles pour établir les connexions audio, vidéo ou de données. Ces informations réseau peuvent poser un vrai problème de confidentialité lorsqu’elles permettent de retrouver une adresse que le VPN était censé masquer.

Mais toutes les adresses affichées par un test WebRTC ne sont pas mon adresse publique résidentielle.

Voir une adresse locale de mon réseau n’est pas la même chose que voir réapparaître l’adresse publique fournie par mon opérateur.

Cette distinction m’a fait gagner énormément de temps.

En mars 2026, un utilisateur de r/ProtonVPN connecté à un Wi-Fi public posait justement ce genre de question après avoir vu une adresse locale rester visible dans un test WebRTC alors que ses autres adresses avaient bien changé.

Je reconnaissais parfaitement l’inquiétude.

Mais mon critère n’était plus:

WebRTC doit devenir totalement silencieux.

Il était:

WebRTC ne doit pas retrouver mon adresse publique réelle derrière le tunnel.

Mon grand VPN pouvait être configuré, mais j’avais créé un tableau de bord

À ce stade, je pouvais conserver mon fournisseur habituel.

Il avait une longue histoire publique, beaucoup de serveurs et suffisamment de réglages pour traiter séparément plusieurs de ces situations.

Je pouvais choisir le DNS.

Surveiller IPv6.

Ajouter une protection WebRTC.

Tester.

Modifier.

Retester.

Tout cela pouvait fonctionner.

Le problème était devenu l’empilement.

VPN.

Navigateur.

DNS personnalisé.

IPv6 du système.

Extension WebRTC.

À chaque résultat étrange, je devais d’abord me souvenir de la couche qui avait pris la décision.

Je n’avais plus besoin d’un quatrième réglage de confidentialité.

Je voulais que moins de choses puissent contourner le tunnel en premier lieu.

J’ai remis l’ordinateur dans un état presque normal

J’ai supprimé le bloqueur WebRTC.

Réactivé IPv6.

Remis le DNS du navigateur en automatique.

Puis j’ai installé OnlydogVPN^↗ sur l’ordinateur et utilisé son mode orienté confidentialité.

Cette fois, je n’essayais plus de faire disparaître le maximum de lignes.

Je vérifiais quatre choses beaucoup plus simples.

Quelle adresse IPv4 publique sort réellement ?

Mon adresse IPv6 fournie par l’opérateur réapparaît-elle ?

Quel résolveur répond au DNS ?

WebRTC retrouve-t-il mon adresse publique résidentielle ?

Sur la connexion fibre IPv4/IPv6 utilisée pour les essais de cet article, j’ai obtenu le comportement que je cherchais.

L’IPv4 visible correspondait au tunnel.

Le résolveur qui m’avait inquiété auparavant n’apparaissait plus; le service a également documenté ce comportement dans ses propres tests consacrés aux fuites DNS.

Mon adresse IPv6 résidentielle n’apparaissait plus comme une seconde sortie publique à côté du VPN.

Puis j’ai relancé le test WebRTC.

WebRTC continuait à fonctionner.

Mais mon adresse publique habituelle ne revenait pas. Le service a déjà montré le même principe dans un test où l’application VPN protège la connexion sous le navigateur, plutôt que de compter uniquement sur une extension.

Je n’avais pas coupé IPv6 dans Windows.

Je n’avais pas installé de bloqueur WebRTC.

Je n’avais pas imposé un deuxième DNS dans Firefox.

Et surtout, ma visioconférence fonctionnait de nouveau.

C’était le résultat qui me manquait depuis le début.

La différence n’était pas une nouvelle fonction « anti-fuite »

Le changement le plus utile était l’endroit où se trouvait la protection.

Avec ma première configuration, j’avais transformé mon ordinateur en appartement avec trois fenêtres que je surveillais séparément.

Un verrou pour le DNS.

Une cale pour IPv6.

Du ruban adhésif sur WebRTC.

Le petit service m’a fait préférer une logique plus simple:

mettre le tunnel sous les applications et laisser ensuite le navigateur et le système faire leur travail sans leur donner chacun une route indépendante vers ma véritable connexion.

Cela ne m’empêche pas de tester.

Au contraire.

Je sais maintenant ce que je cherche.

Une véritable IPv6 résidentielle visible hors tunnel m’inquiète.

Le DNS de mon opérateur qui continue à recevoir mes requêtes alors que le VPN doit les prendre en charge m’inquiète.

Mon adresse publique réelle retrouvée via WebRTC m’inquiète.

Une simple adresse locale affichée par le navigateur ne déclenche plus automatiquement une soirée entière de modifications.

Je teste désormais une fuite réelle, pas la propreté de la page

OnlydogVPN possède moins de régions, un historique public plus court et moins de tests indépendants que plusieurs grands fournisseurs.

C’est précisément pour cela que je préfère vérifier moi-même le résultat plutôt que faire confiance à une étiquette « anti-leak ».

Avant la connexion, je note mon IPv4 publique et mon IPv6 publique lorsqu’elle existe.

Je connecte le VPN.

Je regarde à nouveau.

Puis le DNS.

Puis WebRTC.

Si mon adresse opérateur a disparu du chemin que je veux protéger, si IPv6 ne contourne pas le tunnel et si WebRTC ne retrouve pas mon adresse publique réelle, j’ai obtenu l’information dont j’ai besoin.

Et je peux enfin arrêter de désactiver des fonctions normales simplement pour transformer une page de test en tableau entièrement vert.

Au début, je cherchais donc un VPN avec trois protections séparées: DNS, IPv6 et WebRTC.

Ce n’est plus vraiment ainsi que je formule le problème.

Je veux surtout un tunnel assez cohérent pour que DNS, IPv6 et WebRTC puissent continuer à fonctionner sans retrouver trois chemins différents vers mon adresse réelle.