Les fuites VPN expliquées : fuites DNS, WebRTC et IPv6 (et comment les tester pour de vrai)

Votre application VPN affiche Connecté. Ce simple mot a des allures de garantie, mais il signifie seulement que votre appareil a établi un tunnel chiffré vers le serveur VPN. Il ne dit rien sur le fait que chaque élément de trafic identifiant emprunte réellement ce tunnel. Trois défaillances courantes — les fuites DNS, les fuites WebRTC et les fuites IPv6 — peuvent chacune exposer votre véritable adresse IP ou votre activité de navigation pendant que l'application reste là, à afficher une rassurante coche verte.

Ce guide fait trois choses que les pages mono-fuite et « achetez-ce-VPN » ne font jamais. D'abord, il explique le mécanisme réel derrière chaque fuite pour que vous compreniez pourquoi un VPN connecté peut malgré tout vous trahir. Ensuite, il vous accompagne pas à pas dans un auto-test à l'aide d'outils gratuits et indépendants pour lesquels vous n'avez aucun fournisseur à croire sur parole. Enfin, il vous donne les correctifs exacts par système d'exploitation, par navigateur et par routeur — ainsi que la discipline de re-test qui confirme que le correctif a tenu. Aucun argumentaire de marque, aucun lien d'affiliation, juste la mécanique.

Ce qu'est réellement une fuite VPN

Une fuite, c'est tout trafic censé transiter par le tunnel chiffré mais qui passe à la place par votre connexion Internet ordinaire, révélant des informations que le VPN était censé masquer. Les trois fuites de ce guide exposent deux choses différentes. Une fuite DNS révèle les sites web que vous consultez à votre FAI (ou à quiconque exploite le résolveur que vous utilisez par accident). Une fuite WebRTC et une fuite IPv6 peuvent révéler votre véritable adresse IP — votre emplacement et votre identité réels en ligne — directement aux sites que vous visitez.

La chose la plus importante à comprendre d'emblée : il s'agit de problèmes distincts, aux causes distinctes et aux correctifs distincts. Les concurrents passent cela sous silence parce que c'est gênant pour un récit commercial en un clic, mais c'est tout l'enjeu. Vous pouvez colmater une fuite DNS et continuer à divulguer votre IP via WebRTC. Vous pouvez durcir WebRTC dans votre navigateur et continuer à fuir via IPv6. Refermer l'une ne vous apprend rien sur les deux autres. C'est pourquoi un vrai test de fuite vérifie les trois, à chaque fois.

Comment se produit chaque fuite (le mécanisme)

Fuites DNS : des requêtes qui s'échappent du tunnel

Avant que votre appareil ne charge example.com, il demande à un résolveur DNS de traduire ce nom en adresse IP. Lorsque le VPN est configuré correctement, cette requête DNS voyage à l'intérieur du tunnel vers un résolveur contrôlé par le VPN. Une fuite DNS survient lorsque la requête part plutôt vers le résolveur de votre FAI (ou un résolveur imposé par votre routeur) via la connexion ouverte. Même si le contenu de la page circule peut-être toujours par le tunnel, la requête elle-même révèle chaque domaine que vous visitez à un tiers — et le relie à votre véritable IP.

Les coupables habituels sont un système d'exploitation qui ignore les paramètres DNS du VPN, un résolveur codé en dur (comme un 8.8.8.8 ou un 1.1.1.1 défini manuellement) qui contourne le tunnel, ou des règles de tunnel divisé qui font transiter le DNS hors du VPN. Sous Windows en particulier, une fonctionnalité appelée résolution de noms multi-réseaux intelligente (smart multi-homed name resolution) peut émettre des requêtes DNS sur toutes les interfaces réseau à la fois et retenir celle qui répond en premier — souvent celle de votre FAI.

Fuites WebRTC : le navigateur qui livre votre IP

WebRTC (Web Real-Time Communication) est la technologie de navigateur derrière les appels vidéo intégrés à la page, le chat vocal et le transfert de fichiers en pair-à-pair. Pour relier deux pairs directement, WebRTC doit découvrir les propres adresses IP de l'appareil. Il le fait au moyen de serveurs STUN, qui renvoient au navigateur l'IP publique qu'ils voient, et il énumère également les adresses du réseau local. Une page web peut lire ces candidats ICE via une API JavaScript — sans la moindre demande d'autorisation et sans que vous ayez à cliquer sur quoi que ce soit.

Voici le piège qui rend WebRTC dangereux même avec un VPN fonctionnel : cette découverte peut se produire en dehors du chemin de proxy que votre navigateur utilise pour les chargements de page ordinaires. La page peut finir par voir l'IP publique que votre système d'exploitation considère comme réelle, qui peut être votre véritable adresse plutôt que celle du VPN. Une fuite WebRTC est un problème de navigateur. Elle n'est corrigée ni par les paramètres DNS de votre VPN ni par son kill switch, ce qui explique précisément pourquoi les gens qui ont réglé leur fuite DNS sont stupéfaits de voir leur IP toujours affichée.

Fuites IPv6 : du trafic sur une route que le tunnel n'a jamais tracée

De nombreux tunnels VPN ne transportent que le trafic IPv4. Si votre FAI et votre réseau domestique fournissent aussi une connectivité IPv6 — de plus en plus la norme par défaut — alors toute requête vers une destination compatible IPv6 peut emprunter votre connexion IPv6 native, entièrement à l'extérieur du tunnel IPv4 uniquement. Le site web voit votre véritable adresse IPv6. Le VPN n'a jamais touché ce trafic et souvent ne l'a même jamais remarqué, parce qu'il ne surveillait que le côté IPv4.

C'est pourquoi une fuite IPv6 est si discrètement répandue : rien ne casse, rien ne paraît anormal et le VPN signale une réussite. Le correctif consiste soit à désactiver l'IPv6 sur l'appareil ou le réseau, soit à utiliser un VPN qui tunnelise explicitement l'IPv6 ou le bloque pendant la connexion. Espérer que votre fournisseur s'en charge en silence n'est pas une stratégie — vous le testez.

Lancer le test : outils gratuits et comment les lire

Utilisez des outils indépendants et tiers plutôt que la page « votre IP est masquée » que vous montre votre fournisseur VPN — un fournisseur a tout intérêt à annoncer une réussite. Effectuez chaque test avec le VPN connecté, dans le même navigateur et sur le même appareil que vous utilisez réellement. Comme point de référence, il vaut la peine de les lancer d'abord une fois avec le VPN éteint pour savoir à quoi ressemblent votre véritable IP et votre FAI ; activez ensuite le VPN et confirmez que ces valeurs disparaissent.

Étape 1 — Test de fuite DNS

Ouvrez dnsleaktest.com et lancez le test étendu (Extended test). Il charge une série de noms d'hôtes uniques et indique quels serveurs DNS les ont résolus. Un résultat propre affiche des résolveurs appartenant à votre fournisseur VPN (ou un résolveur respectueux de la vie privée que le VPN utilise), et surtout ne mentionne pas le nom de votre FAI ni votre pays d'origine si vous vous êtes connecté à un serveur ailleurs. Un résultat qui fuit affiche le résolveur de votre FAI, ou des serveurs situés à votre véritable emplacement auxquels vous ne vous attendiez pas. ipleak.net affiche les mêmes informations DNS aux côtés de votre IP, ce qui est pratique pour un recoupement.

Étape 2 — Test de fuite WebRTC

Ouvrez browserleaks.com/webrtc. Examinez l'adresse IP publique (Public IP Address) qu'il découvre via WebRTC. Un résultat propre n'affiche aucune IP publique, ou uniquement l'IP du serveur VPN. Un résultat qui fuit affiche votre véritable IP publique dans la section WebRTC alors même que l'en-tête de la page (qui utilise une requête HTTP normale) affiche l'IP du VPN — cette incohérence est la signature classique d'une fuite WebRTC. Les adresses locales dans les plages 10.x, 172.16–31.x, 192.168.x ou les noms mDNS .local sont en général inoffensives ; le véritable danger, c'est l'apparition de votre authentique IP publique.

Étape 3 — Test IPv6 et test d'IP global

Ouvrez ipleak.net. Il affiche votre adresse IPv4, toute adresse IPv6 ainsi que vos serveurs DNS sur une seule page. Un résultat propre n'affiche que l'IP du VPN (correspondant au pays que vous avez choisi) et soit aucune adresse IPv6, soit une IPv6 qui appartient elle aussi au VPN. Un résultat qui fuit affiche une adresse IPv6 provenant de votre FAI, ou un couple IPv4/IPv6 pointant vers deux emplacements différents. Si vous voyez une véritable IPv6 aux côtés d'une IPv4 du VPN, c'est un cas d'école de fuite IPv6.

Un VPN qui masque votre IPv4 mais expose votre IPv6 ne vous a pas à moitié protégé — pour tout site sensible à l'IPv6, vous n'utilisez tout simplement aucun VPN.

Les correctifs exacts, par OS, navigateur et routeur

Corriger les fuites DNS

• Dans l'application VPN : activez toute option « Utiliser uniquement le DNS du VPN », « Protection contre les fuites DNS » ou « bloquer le DNS hors VPN ». De nombreuses applications l'activent par défaut, mais les configurations OpenVPN/WireGuard tierces ne le font souvent pas.

• Windows : désactivez la résolution de noms multi-réseaux intelligente (smart multi-homed name resolution), qui disperse le DNS sur toutes les interfaces. Sous Windows Pro, vous pouvez régler la stratégie de groupe « Désactiver la résolution de noms multi-réseaux intelligente » sur Activée ; sinon, privilégiez un client VPN qui définit le DNS et bloque les autres résolveurs. Retirez de vos adaptateurs tout DNS public configuré manuellement (8.8.8.8, 1.1.1.1) pendant les tests.

• macOS / Linux : assurez-vous qu'aucun résolveur n'est codé en dur dans les paramètres réseau ou dans /etc/resolv.conf qui contournerait le tunnel ; laissez le client VPN gérer le DNS. Sous Linux avec systemd-resolved, vérifiez que le VPN définit une route de domaine afin que les requêtes aillent vers son résolveur.

• Routeur : si vous exécutez le VPN sur le routeur, réglez le DNS du routeur sur le résolveur du VPN et désactivez tout DNS attribué par le FAI. Désactivez aussi les fonctions du routeur qui interceptent ou redirigent le DNS (certains réglages de « contrôle parental » ou de « protection contre le DNS rebinding »).

Corriger les fuites WebRTC (navigateur uniquement)

• Firefox : tapez about:config dans la barre d'adresse, acceptez l'avertissement, recherchez media.peerconnection.enabled et réglez-le sur false. Cela désactive entièrement WebRTC. Si vous avez besoin de WebRTC pour les appels, laissez-le activé mais appuyez-vous sur un VPN/une extension qui masque l'IP découverte, puis refaites le test.

• Chrome / Edge : il n'existe aucun interrupteur intégré pour désactiver complètement WebRTC. Sachez que l'ancienne option d'uBlock Origin « Empêcher WebRTC de divulguer les adresses IP locales » a été retirée de l'extension de bureau dès 2021, et que, même lorsqu'elle existait, elle ne masquait que les adresses locales/LAN — elle n'a jamais empêché la divulgation de l'IP publique qui vous expose réellement, elle n'a donc jamais été le correctif que l'on imaginait. Chromium moderne obscurcit déjà les IP locales à l'aide du mDNS (vous pouvez le confirmer via le drapeau « Anonymize local IPs exposed by WebRTC » dans chrome://flags). Pour contrôler l'exposition de l'IP publique, utilisez une extension dédiée au contrôle de WebRTC puis vérifiez avec un test de fuite, car les extensions diffèrent dans la complétude avec laquelle elles bloquent cette divulgation.

• Safari : l'exposition WebRTC est plus limitée par défaut, mais testez quand même. Vous pouvez la désactiver via les fonctionnalités expérimentales/WebRTC du menu Développement si vous n'en avez pas besoin.

• Mise au point : désactiver WebRTC peut casser Google Meet, Discord dans le navigateur, Jitsi et autres outils similaires. Si vous en avez besoin, la voie pratique est un navigateur/une extension qui ne livre que l'IP du VPN plutôt que de supprimer WebRTC purement et simplement — confirmé par un nouveau test.

Corriger les fuites IPv6

• Meilleure option : utilisez un VPN qui propose explicitement une protection contre les fuites IPv6 (il bloque ou tunnelise l'IPv6 pendant la connexion). Activez ce réglage et refaites le test.

• Windows : désactivez l'IPv6 sur l'adaptateur actif (Propriétés de l'adaptateur réseau, décochez Protocole Internet version 6), ou utilisez le blocage IPv6 du VPN. Réactivez-le lorsque vous cessez d'utiliser un VPN incapable de le gérer.

• macOS : dans Réglages Système, réglez l'option Configurer IPv6 du service réseau sur Lien-local uniquement (ou Désactivé en ligne de commande) si votre VPN ne peut pas le tunneliser.

• Linux : désactivez l'IPv6 par interface ou à l'échelle du système via sysctl (par exemple net.ipv6.conf.all.disable_ipv6=1) si le tunnel est en IPv4 uniquement.

• Routeur : si vous exécutez le VPN au niveau du routeur, désactivez l'IPv6/WAN IPv6 du routeur afin qu'aucun appareil du réseau ne puisse fuir par cette voie. C'est le correctif le plus propre pour tout un foyer.

Pourquoi un VPN « connecté » fuit malgré tout

Même après avoir réussi les trois tests une fois, la protection n'est pas permanente — c'est un état qui peut se rompre en silence. Voici les moments où un VPN « connecté » se met discrètement à fuir :

• Changements de réseau : passer du Wi-Fi à l'Ethernet, changer de point d'accès, ou votre téléphone qui bascule entre Wi-Fi et données cellulaires peut momentanément router le trafic hors du tunnel avant que le VPN ne rétablisse ses règles.

• Veille et réveil : quand un ordinateur portable sort de veille, le réseau revient souvent avant que le VPN ne se reconnecte. Pendant quelques secondes, le trafic emprunte la connexion nue — assez longtemps pour que des applications en arrière-plan « téléphonent » avec votre véritable IP.

• Reconnexions et coupures : chaque fois que le tunnel tombe et se rétablit, il existe une fenêtre où le trafic peut s'échapper, à moins qu'un kill switch ne le bloque.

• Portails captifs : les Wi-Fi d'hôtels, d'aéroports et de cafés exigent que vous chargiez une page de connexion avant que l'Internet ne fonctionne. Cette page se charge hors du VPN par conception, et certaines configurations restent vulnérables jusqu'à ce que vous vous reconnectiez manuellement.

• Tunnel divisé (split tunneling) : si vous avez exclu certaines applications — ou le DNS — du VPN, ces exclusions sont des fuites par configuration. Vérifiez bien que le DNS ne figure pas discrètement dans la liste de « contournement ».

• Retour de l'IPv6 : une mise à jour de l'OS ou une réinitialisation réseau peut réactiver silencieusement l'IPv6 que vous aviez précédemment désactivé, rouvrant cette voie sans avertissement.

Kill switches et réglages anti-fuite — et comment ils échouent en silence

Un kill switch est un filet de sécurité pour le problème de coupure-reconnexion : lorsque le tunnel tombe, il bloque tout le trafic Internet jusqu'au retour du VPN, de sorte que rien ne s'échappe dans l'intervalle. La protection anti-fuite intégrée (protection contre les fuites DNS, blocage IPv6, fonctions de verrouillage réseau) impose que le DNS et l'IPv6 n'empruntent jamais que le tunnel. Activez les deux — ils couvrent les fenêtres de défaillance que vous ne pouvez pas surveiller manuellement.

Mais comprenez bien leurs modes de défaillance silencieuse. Un kill switch n'agit que lorsque l'application détecte que le tunnel est tombé ; si le tunnel est techniquement actif mais que le DNS ou l'IPv6 fuit autour de lui, le kill switch ne voit aucun problème et ne fait rien. Les kill switches au niveau de l'application ne protègent que le trafic de l'application VPN elle-même, pas l'ensemble du système. Certains kill switches ne s'enclenchent pas pendant la fenêtre de veille/réveil ni avant la connexion au démarrage. Et un kill switch « de type pare-feu » qui bloque entièrement le trafic à l'arrêt peut être confondu avec une panne d'Internet, ce qui pousse les gens à le désactiver. La leçon : un kill switch réduit le risque, il ne remplace pas le test. La seule preuve que vos réglages fonctionnent, c'est un test réussi.

Résultat bénin vs. véritable faille de confidentialité

Toute entrée inhabituelle sur une page de test de fuite n'est pas une catastrophe. Savoir faire la différence vous évite de courir après des fantômes — ou d'ignorer une véritable exposition.

• Bénin : WebRTC n'affichant que des adresses locales/privées (10.x, 172.16–31.x, 192.168.x) ou un nom d'hôte mDNS .local. Celles-ci ne vous identifient pas auprès d'un site web.

• Bénin : des résolveurs DNS appartenant à votre fournisseur VPN ou à un résolveur respectueux de la vie privée qu'il utilise, même s'ils se trouvent dans une autre ville que votre serveur VPN — les fournisseurs exploitent des flottes de résolveurs.

• Bénin : aucune adresse IPv6 du tout lorsque vous avez désactivé l'IPv6. C'est l'objectif, pas un échec.

• Véritable faille : tout test affichant votre véritable IP publique (IPv4 ou IPv6), votre véritable ville/FAI, ou votre pays d'origine alors que vous vous êtes délibérément connecté ailleurs.

• Véritable faille : des résultats DNS nommant votre FAI réel, ou une IPv4 et une IPv6 qui se résolvent vers deux emplacements différents.

• Véritable faille : l'en-tête de la page affichant l'IP du VPN tandis que la section WebRTC affiche votre véritable IP — cette incohérence est la fuite.

Règle générale : une IP publique ou le nom de votre FAI apparaissant là où ils ne devraient pas est une véritable faille. Les adresses privées/locales et les résolveurs appartenant au fournisseur ne sont que du bruit.

La discipline de re-test : l'habitude qui vous protège vraiment

Un test de fuite est un instantané, pas un certificat. Parce que l'état protecteur se rompt aux changements de réseau, aux veilles, aux reconnexions et aux portails captifs, le test n'a de valeur que pour les conditions dans lesquelles vous l'avez réalisé. Prenez l'habitude :

1. Refaites le test après chaque correctif — modifiez un seul réglage, puis confirmez que cette fuite précise est refermée avant de passer à la suite. Corriger les trois d'un coup et ne tester qu'une fois masque le changement qui a fonctionné.

2. Refaites le test après chaque changement de réseau — nouveau Wi-Fi, passage aux données cellulaires, branchement d'un câble Ethernet, ou après une connexion à un portail captif.

3. Refaites le test après un réveil de veille et après une reconnexion du VPN, car ce sont les fenêtres les plus à risque.

4. Refaites le test après les mises à jour de l'OS et des applications, qui peuvent réactiver discrètement l'IPv6 ou réinitialiser le comportement DNS.

5. Lancez les trois tests ensemble à chaque fois — DNS, WebRTC et IPv6 sont indépendants, et un résultat propre sur l'un ne vous dit rien sur les autres.

À retenir en pratique

« Connecté » est un point de départ, pas une preuve de confidentialité. Testez les trois fuites avec des outils indépendants — dnsleaktest.com pour le DNS, browserleaks.com/webrtc pour WebRTC, et ipleak.net pour l'IPv6 et votre IP globale. Traitez-les comme des problèmes distincts : forcez le DNS du VPN au niveau de l'OS ou du routeur, neutralisez WebRTC dans le navigateur, et bloquez ou tunnelisez l'IPv6. Activez votre kill switch et la protection anti-fuite intégrée pour les failles que vous ne pouvez pas surveiller, mais ne leur faites jamais confiance aveuglément. Refaites ensuite le test après chaque correctif et chaque changement de réseau. Dix minutes de test vous en apprennent davantage sur votre exposition réelle que n'importe quelle page marketing de fournisseur.

Questions fréquentes

Qu'est-ce qu'un test de fuite VPN et comment en réaliser un ?

Un test de fuite VPN vérifie si du trafic s'échappe de votre tunnel chiffré et expose votre véritable adresse IP ou vos requêtes DNS pendant que le VPN est connecté. Pour en effectuer un, connectez votre VPN, puis visitez des outils indépendants comme dnsleaktest.com, browserleaks.com/webrtc et ipleak.net. Si l'un d'eux affiche votre véritable IP publique, votre FAI ou votre emplacement d'origine, vous avez une fuite.

Comment fonctionne un test de fuite DNS et qu'est-ce qui compte comme réussite ?

Un test de fuite DNS charge des noms d'hôtes uniques et indique quels serveurs DNS les ont résolus. Vous réussissez si les résolveurs appartiennent à votre fournisseur VPN et que votre propre FAI n'est pas listé. Vous échouez si le résolveur de votre FAI apparaît ou si les serveurs se trouvent à votre véritable emplacement alors que vous vous êtes connecté ailleurs.

Comment corriger une fuite DNS ?

Activez d'abord la « protection contre les fuites DNS » ou « utiliser uniquement le DNS du VPN » dans votre application VPN. Sous Windows, désactivez aussi la résolution de noms multi-réseaux intelligente et retirez de votre adaptateur tout DNS public défini manuellement comme 8.8.8.8. Sur un routeur exécutant le VPN, pointez le DNS du routeur vers le résolveur du VPN et désactivez le DNS attribué par le FAI, puis refaites le test.

Qu'est-ce qu'une fuite WebRTC et mon VPN l'empêche-t-il ?

Une fuite WebRTC se produit lorsque la fonction de communication en temps réel de votre navigateur découvre et expose votre véritable adresse IP à une page web, même avec le VPN connecté. La plupart des VPN ne l'empêchent pas car il s'agit d'un comportement du navigateur, pas du réseau. Corrigez-la dans Firefox en réglant media.peerconnection.enabled sur false dans about:config. Chrome et Edge n'ont aucun interrupteur intégré pour désactiver WebRTC : utilisez donc une extension dédiée au contrôle de WebRTC et refaites le test — ne comptez pas sur l'ancienne option d'IP locale d'uBlock Origin, qui a été retirée de l'extension de bureau et n'a de toute façon jamais bloqué l'exposition de l'IP publique.

Qu'est-ce qu'une fuite IPv6 et comment l'éviter sur mon VPN ?

Une fuite IPv6 se produit lorsque votre tunnel VPN en IPv4 uniquement ignore le trafic IPv6, le laissant transiter par votre connexion FAI et exposer votre véritable adresse IPv6. Évitez-la en activant la protection contre les fuites IPv6 dans votre VPN, ou en désactivant l'IPv6 sur votre appareil ou votre routeur. Après avoir modifié le réglage, confirmez sur ipleak.net qu'aucune adresse IPv6 du FAI n'apparaît.

Un kill switch empêche-t-il les fuites DNS et WebRTC ?

Pas de façon fiable. Un kill switch ne bloque le trafic que lorsqu'il détecte que le tunnel est tombé, il ne fait donc rien contre les fuites DNS ou WebRTC qui surviennent pendant que le tunnel est encore actif. Vous avez besoin d'une protection contre les fuites DNS distincte et d'un durcissement WebRTC côté navigateur, le kill switch servant de filet de sécurité pour les reconnexions et les coupures.

À quelle fréquence dois-je lancer un test de fuite VPN ?

Testez après chaque changement de configuration, et refaites le test après chaque changement de réseau, cycle de veille/réveil, reconnexion du VPN, connexion à un portail captif et mise à jour majeure de l'OS ou des applications. Chacun de ces moments peut rouvrir une fuite en silence. Lancez toujours les trois tests ensemble, car DNS, WebRTC et IPv6 sont des problèmes indépendants.