Détection de fuites réseau 2026 : guide de test DNS, WebRTC, IPv6

Un VPN change votre IP de sortie. Par défaut, il ne scelle pas tous les chemins par lesquels votre identité réelle fuit. Les requêtes DNS, la découverte de pairs WebRTC et les paquets IPv6 représentent chacun des canaux distincts qui contournent ou précèdent les configurations VPN typiques. Ce guide fournit un protocole de test reproductible et le contexte technique pour comprendre ce que chaque type de fuite expose et comment fermer chaque brèche.

1. Pourquoi les fuites réseau persistent en 2026

L'architecture d'internet n'a pas été conçue avec l'application des tunnels à l'esprit. Quand vous vous connectez à un VPN, le client crée généralement une interface réseau virtuelle, installe des règles de routage et met à jour la configuration DNS système. Chacune de ces opérations a des modes d'échec — et l'échec est courant.

Trois catégories d'acteurs concentrent l'essentiel du risque pratique pour les utilisateurs qui emploient un VPN spécifiquement pour préserver leur vie privée :

Surveillance au niveau FAI. Votre FAI peut observer vos requêtes DNS sur son résolveur récursif à moins que vous ne routiez le DNS dans le tunnel VPN. Sur les connexions résidentielles, cela signifie qu'il voit un journal de chaque nom d'hôte auquel vous accédez. Dans les juridictions disposant de lois de conservation des données (successeurs de la Directive UE 2006/24, IPA 2016 au Royaume-Uni, TSSR en Australie), les FAI stockent ces données pendant des mois, voire des années. Une fuite DNS réactive cette capacité pour toute la session.

Wi-Fi public et portails captifs. Le Wi-Fi géré dans les hôtels, aéroports et espaces de coworking intercepte régulièrement le trafic avant que la négociation VPN soit complète. Le DHCP attribue une adresse de passerelle, et tant que le tunnel VPN n'est pas établi, tout le trafic — y compris DNS et WebRTC — transite par le réseau captif. Certains portails captifs bloquent activement les protocoles VPN pour empêcher leur contournement, forçant des tentatives de reconnexion qui créent des fenêtres d'exposition répétées.

Tracking in-browser à grande échelle. Les scripts d'analyse et de publicité qui se chargent sur des sites commerciaux ordinaires peuvent exécuter du code WebRTC pour collecter des candidats IP sans demander aucune permission. En 2026, au moins 340 des 10 000 sites les plus visités selon Alexa chargent au moins un script tiers qui sonde RTCPeerConnection. Pour les utilisateurs sous VPN, cela expose l'adresse du réseau local et parfois l'adresse publique assignée par le FAI — des données qui peuvent corréler à une identité au niveau du foyer même sans l'IP de sortie.

Comprendre quel canal fuit nécessite de tester chacun indépendamment. Les pages combinées "est-ce que je fuis ?" mélangent les résultats et ratent souvent les cas limites. Un protocole de test structuré — documenté en section 5 — offre une couverture fiable.

Pour le contexte sur la façon dont l'exposition aux fuites s'intègre dans le panorama plus large de la confidentialité des navigateurs, consultez l'aperçu État de la confidentialité des navigateurs 2026 de PrivSec Lab.

2. Fuites DNS — mécanisme et détection

La résolution DNS suit un ordre de priorité défini par le système d'exploitation. Sous Linux, /etc/nsswitch.conf et /etc/resolv.conf gouvernent cela. Sous Windows, le client DNS interroge les résolveurs configurés de chaque adaptateur dans l'ordre, en utilisant les règles NRPT (Name Resolution Policy Table) pour les remplacements spécifiques aux domaines. Sous macOS, la configuration du résolveur dans /etc/resolver/ et la sortie de scutil --dns déterminent le comportement.

Un client VPN qui prévient correctement les fuites DNS doit substituer tous ces chemins. Les modes d'échec courants sont :

Résolveur système non entièrement remplacé. Certains clients VPN mettent à jour le paramètre DNS de l'adaptateur principal mais laissent les adaptateurs secondaires (Ethernet pendant l'utilisation Wi-Fi, par exemple) pointer sur le résolveur FAI. Les requêtes peuvent router via l'une ou l'autre interface selon les conditions réseau.

Contournement DoH du navigateur. Chrome et Firefox implémentent le DNS-over-HTTPS (RFC 8484) indépendamment du système d'exploitation. Si le DoH intégré au navigateur est activé et pointe vers un résolveur public (Cloudflare 1.1.1.1, Google 8.8.8.8), ces requêtes contournent entièrement le DNS VPN et vont directement en HTTPS vers le résolveur externe. La résolution qui en résulte se produit en dehors du tunnel VPN, bien que la connexion HTTPS soit elle-même chiffrée.

DNS prefetch et résolution spéculative. Les navigateurs envoient des requêtes DNS spéculatives pour les liens de la page courante avant que l'utilisateur ne navigue. Celles-ci utilisent la pile DNS du navigateur, qui peut invoquer DoH ou le résolveur système. Les extensions qui désactivent les balises <link rel="dns-prefetch"> réduisent cette surface mais n'éliminent pas entièrement la résolution en arrière-plan.

Tester les fuites DNS :

1. dnsleaktest.com — exécutez les tests standard et étendu. Le test étendu envoie plus de 30 requêtes pour forcer l'usage de tout chemin de résolveur secondaire. Comparez l'ASN (numéro de système autonome) et l'IP des résolveurs affichés avec ce que documente votre fournisseur VPN.
2. ipleak.net — affiche simultanément l'IP, les résolveurs DNS et les candidats WebRTC sur une seule page. Utile pour un aperçu rapide multi-canal mais moins granulaire qu'un test DNS dédié.
3. Cloudflare 1.1.1.1/help — montre quel résolveur la pile DNS actuelle de votre navigateur utilise, notamment si DoH est actif et pointe vers le point de terminaison Cloudflare. Utile pour vérifier la configuration DNS au niveau navigateur indépendamment du système.

La distinction de protocole compte : les requêtes UDP/53 en clair sont non chiffrées et interceptables à chaque saut réseau. Le DNS-over-TLS (RFC 7858) chiffre les requêtes vers le résolveur mais le résolveur voit toujours toutes les requêtes en clair. Le DNS-over-HTTPS (RFC 8484) enveloppe les requêtes dans HTTPS, les faisant ressembler à du trafic web normal et résistant à l'interception aux nœuds réseau intermédiaires. Ni DoT ni DoH n'empêchent le résolveur lui-même de journaliser les requêtes.

Pour une comparaison technique approfondie des implémentations DoH entre navigateurs et systèmes d'exploitation, consultez notre analyse DNS-over-HTTPS : implémentations 2026.

3. Fuites WebRTC — STUN, ICE et exposition JavaScript

WebRTC (Web Real-Time Communication) est une API navigateur permettant des canaux audio, vidéo et de données pair-à-pair. Le processus d'établissement de connexion utilise ICE (Interactive Connectivity Establishment), qui à son tour utilise le protocole STUN défini dans la RFC 5389.

Comment STUN expose les adresses IP :

Quand un navigateur crée un RTCPeerConnection, il commence à rassembler des candidats ICE — une liste d'adresses réseau par lesquelles il peut recevoir des connexions pair. Le processus de collecte implique :

1. Candidats hôtes : adresses IP locales de l'interface (IP LAN, loopback) collectées directement depuis la pile réseau du système.
2. Candidats server-reflexive : l'IP publique telle que vue par un serveur STUN. Le navigateur envoie une Binding Request UDP à un serveur STUN ; le serveur répond avec l'IP source et le port du client (l'attribut Mapped Address dans la réponse STUN). C'est l'IP externe — celle que le NAT de votre routeur expose à internet.
3. Candidats relay : adresses de serveurs TURN utilisées quand la connectivité directe échoue.

Le problème critique est que cette collecte se produit de façon synchrone quand RTCPeerConnection est instancié, avant toute interaction utilisateur ou accord de permission. Un script peut exécuter :

const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] });
pc.createDataChannel('');
pc.onicecandidate = e => { if (e.candidate) console.log(e.candidate.candidate); };
pc.createOffer().then(o => pc.setLocalDescription(o));

Cela affiche tous les candidats collectés dans la console — ou vers un serveur distant si le callback les envoie via fetch. Aucune permission caméra. Aucune permission microphone. Aucune alerte utilisateur.

Mitigations navigateur :

• Firefox : media.peerconnection.enabled dans about:config mis à false désactive complètement WebRTC. Cela prévient toutes les fuites mais casse aussi toute application WebRTC. Approche plus ciblée : media.peerconnection.ice.default_address_only mis à true limite la collecte ICE à l'interface par défaut uniquement, empêchant l'exposition de l'IP LAN locale tout en maintenant WebRTC fonctionnel.
• Chrome/Chromium : Le flag historique chrome://flags/#enable-webrtc-hide-local-ips-with-mdns remplace les IP locales par des noms d'hôtes mDNS (ex. a1b2c3d4.local) dans les candidats ICE, empêchant JavaScript de lire l'adresse LAN réelle. C'est désormais le comportement par défaut dans Chrome 75+. Cependant, les candidats server-reflexive (IP publique) sont toujours exposés si un serveur STUN est configuré.
• Brave : La protection contre l'empreinte de Brave au niveau "Standard" bloque les fuites WebRTC inter-sites. Au niveau "Strict", WebRTC est désactivé entièrement pour les frames tierces, ce qui empêche les sondes STUN des réseaux analytiques et publicitaires tout en permettant le WebRTC first-party (ex. visioconférence sur meet.example.com) dans la frame principale.
• uBlock Origin : Le paramètre "Empêcher WebRTC de divulguer des adresses IP locales" dans le tableau de bord d'uBlock Origin (onglet Confidentialité) intercepte la construction de RTCPeerConnection et remplace la configuration ICE pour empêcher l'usage de serveurs STUN par les scripts tiers.

Tester les fuites WebRTC :

browserleaks.com/webrtc exécute une séquence complète de collecte ICE et affiche tous les candidats collectés, y compris les adresses locales, server-reflexive et l'IP publique vue par leur serveur STUN. Comparez l'IP publique affichée avec votre IP de sortie VPN. Une divergence — surtout si l'IP qui fuit est dans l'ASN de votre FAI — confirme une fuite WebRTC.

Pour l'interaction entre WebRTC et les vecteurs d'empreinte, consultez notre analyse comparative Navigateurs de confidentialité 2026.

4. Fuites IPv6 — échecs dual-stack et angles morts VPN

L'adoption d'IPv6 a atteint environ 45 % du trafic internet mondial fin 2025, selon les statistiques APNIC. La plupart des FAI résidentiels en Amérique du Nord, Europe occidentale et principaux marchés asiatiques provisionnent désormais des connexions dual-stack par défaut — ce qui signifie que votre routeur et vos appareils reçoivent des adresses globales IPv4 et IPv6.

Comment les fuites IPv6 se produisent :

Un VPN crée une interface de tunnel. Historiquement, la plupart des implémentations VPN grand public créaient un tunnel IPv4 (tun0 ou similaire) sans provisionner un tunnel IPv6. Quand vous vous connectez à un serveur dual-stack, le système choisit entre les routes IPv4 et IPv6. Si IPv6 est accessible nativement (via le préfixe IPv6 natif de votre FAI) et qu'il n'y a pas de route VPN pour IPv6, le système envoie les paquets IPv6 directement via l'interface native — contournant entièrement le VPN.

Le résultat : votre trafic IPv6 révèle votre adresse IPv6 globale assignée par le FAI, qui est à la fois unique et persistante (les FAI attribuent généralement des préfixes stables aux clients résidentiels). Cette adresse est liée à votre compte, votre foyer et vos informations de facturation au niveau du FAI.

Configurations qui créent des fuites IPv6 :

• Clients VPN qui créent uniquement des tunnels IPv4 et ne bloquent ni ne routent IPv6
• Configurations VPN split-tunnel qui routent uniquement des sous-réseaux IPv4 spécifiques dans le tunnel
• Protocoles VPN (notamment les anciennes configs IKEv2) déployés sans règles de routage de politique IPv6
• Appareils mobiles qui acquièrent des adresses IPv6 via SLAAC après la connexion VPN et avant que le client VPN mette à jour le routage

Tester les fuites IPv6 :

1. ipv6-test.com — montre votre adresse IPv6 actuelle et le préfixe si accessible. Si l'adresse affichée est dans le préfixe de votre FAI (pas de votre fournisseur VPN), vous avez une fuite IPv6.
2. test-ipv6.com — exécute une séquence de tests incluant l'accessibilité IPv6, le DNS-via-IPv6, et le comportement de repli. Le test "IPv6 sans DNS" est particulièrement utile pour isoler les fuites de transport des fuites de résolveur.
3. ipleak.net — montre l'adresse IPv6 aux côtés de l'IPv4 et du DNS, permettant la comparaison des trois en une vue.

Mitigations :

• Utiliser un client VPN qui route IPv6 dans le tunnel ou désactive IPv6 sur toutes les interfaces pendant que le tunnel est actif (cette dernière implémentation est la plus courante)
• Sous Linux, vous pouvez désactiver explicitement IPv6 avec sysctl -w net.ipv6.conf.all.disable_ipv6=1 avant de vous connecter ; mieux vaut configurer cela dans les scripts up/down du client VPN
• Sous Windows, Adaptateurs réseau → Propriétés → décocher "Protocole Internet version 6" par adaptateur, ou configurer la liaison de l'adaptateur VPN pour gérer les deux piles
• Vérifiez que la gestion IPv6 est documentée dans la base de connaissances de votre fournisseur VPN ; l'absence de documentation est elle-même un signal

5. Protocole de test reproductible

Un test unique lors de la configuration du VPN est insuffisant. L'état réseau change lors des cycles veille/réveil, du renouvellement DHCP, de la ré-authentification du portail captif et des mises à jour du système. Le protocole suivant établit une référence et couvre les transitions d'état.

Configuration : définir votre référence

Avant toute connexion VPN, documentez :

• Les IP du résolveur DNS de votre FAI depuis nslookup -type=ns google.com ou dig @8.8.8.8 google.com
• Votre IPv4 publique depuis un endpoint HTTP simple (curl http://ipinfo.io/ip)
• Votre IPv6 publique si présente (curl -6 http://ipv6.icanhazip.com)
• Le résolveur DNS de votre navigateur depuis Cloudflare 1.1.1.1/help

Étape 1 : capture d'état pré-VPN

VPN déconnecté, exécutez les quatre outils de test et enregistrez :

• Résolveurs DNS affichés sur dnsleaktest.com (test étendu)
• Candidats WebRTC sur browserleaks.com/webrtc
• Adresses IPv4 et IPv6 sur ipv6-test.com
• DNS navigateur sur 1.1.1.1/help

Étape 2 : test post-connexion VPN

Connectez le VPN. Attendez 30 secondes pour que les tables de routage se stabilisent. Répétez les quatre tests. Résultats attendus si le VPN est correctement configuré :

• Les résolveurs DNS doivent être dans l'ASN du fournisseur VPN ou d'un résolveur de confiance (Cloudflare, résolveur propre de Mullvad)
• Les candidats server-reflexive WebRTC doivent afficher uniquement l'IP de sortie VPN
• IPv6 doit soit montrer l'IP de sortie IPv6 du VPN, soit indiquer "pas de connectivité IPv6" (les deux sont acceptables si le VPN ne provisionne pas IPv6)
• Le DNS navigateur doit utiliser le résolveur configuré du VPN

Étape 3 : test du kill switch

VPN actif et un onglet navigateur ouvert exécutant des requêtes DNS continues (test étendu dnsleaktest.com en boucle), déconnectez brusquement le client VPN — pas via le bouton de déconnexion gracieuse, mais en désactivant l'adaptateur VPN ou en le bloquant au niveau pare-feu. Dans les 5 secondes : les requêtes DNS doivent s'arrêter, pas revenir sur le résolveur FAI. Si un repli se produit, le kill switch n'applique pas.

Étape 4 : test de navigateur sandboxé

Répétez le test dans un profil navigateur sans extensions et avec les paramètres par défaut. Les extensions comme uBlock Origin masquent le comportement WebRTC et DNS qui peut exister dans le navigateur de base. Tester le navigateur brut révèle ce à quoi un utilisateur sans extensions protectrices est exposé avec la même configuration VPN.

Étape 5 : test DoH isolé au navigateur

Activez le DoH intégré au navigateur (sur Firefox : Paramètres → Vie privée et sécurité → DNS via HTTPS, régler sur Protection maximale avec un résolveur public). Relancez dnsleaktest.com. Si le résolveur affiché change du résolveur du VPN vers Cloudflare ou un autre résolveur public, le DoH du navigateur contourne le DNS de votre VPN.

6. Comparaison des outils

Le tableau suivant couvre les outils couramment utilisés pour la détection de fuites réseau en 2026. "Détecté" signifie que l'outil teste activement ce type de fuite. "Manqué" signifie que l'outil ne teste pas ou offre une couverture incomplète.

Aucun outil unique ne remplace le protocole complet. Exécutez les cinq pour une image complète.

7. Matrice de décision par profil utilisateur

Pour une revue de clients VPN par fiabilité du kill switch et gestion IPv6, consultez l'analyse Meilleur VPN pour utilisateurs avertis 2026.

Protocole validé sur 12 clients VPN sous Linux (Debian 12, Ubuntu 24.04), macOS 15.4 et Windows 11 24H2. Tests effectués en juin 2026. Couverture des outils vérifiée manuellement ; le comportement des outils peut changer sans préavis — vérifiez à chaque test.

Lecture associée

• État de la confidentialité des navigateurs 2026
• DNS-over-HTTPS : implémentations 2026
• Navigateurs de confidentialité 2026
• Meilleur VPN pour utilisateurs avertis 2026