Test fuite VPN complet 2026 : DNS, WebRTC, IPv6, MTU, kill switch - méthodologie unifiée

Un VPN actif et techniquement connecté ne signifie pas anonymat garanti. Cinq vecteurs de fuite distincts peuvent compromettre la confidentialité d'une session même avec un tunnel VPN apparemment opérationnel : DNS (résolution de noms hors tunnel), WebRTC (exposition de l'IP par API navigateur), IPv6 (transit en clair si non bloqué), MTU (fragmentation et fuites de fragments en clair), kill switch défaillant (trafic en clair lors des micro-coupures invisibles). Des recherches indépendantes constatent régulièrement qu'une part notable des setups VPN domestiques présentent au moins une fuite parmi ces cinq vecteurs malgré un client VPN affichant « protégé ».

Ce guide consolide la méthodologie de test couvrant les 5 dimensions, avec deux outils CLI open-source que nous maintenons (dns-leak-detector-cli et webrtc-leak-detector), des commandes shell reproductibles, et les seuils de validation à respecter. Il s'adresse aux utilisateurs techniques (admin sys, dev, sécurité) et aux freelances soumis à RGPD article 32 souhaitant documenter une vérification trimestrielle. Durée totale du protocole : ~30 minutes pour un setup domestique standard.

Pourquoi le test DNS seul ne suffit plus en 2026

Le test fuite DNS standard est devenu insuffisant pour deux raisons techniques précises. Première raison : la généralisation d'IPv6 chez les FAI européens. Free, Orange, SFR, Bouygues, Movistar, Vodafone, Deutsche Telekom déploient massivement IPv6 sur leurs liens fibre depuis 2023-2024. En mai 2026, ~40 % des connexions fibre françaises et allemandes disposent d'une stack dual-stack IPv4/IPv6 native. Si le client VPN ne tunnelise pas explicitement IPv6 (cas par défaut sur certaines versions OpenVPN sans paramétrage spécifique), le trafic IPv6 sort par la route par défaut FAI - fuite intégrale d'identité non détectée par un test DNS classique focalisé sur IPv4.

Seconde raison : la prévalence de WebRTC dans les navigateurs modernes. WebRTC (Web Real-Time Communication) est activée par défaut dans Chrome, Edge, Firefox, Safari pour permettre les appels vidéo intégrés (Google Meet, WhatsApp Web, Microsoft Teams Web). L'API RTCPeerConnection énumère les candidats ICE (Interactive Connectivity Establishment) en exposant l'IP locale ET l'IP publique de l'appareil. Sur Chrome et Edge en 2026, environ 30 % des installations exposent encore une IP locale ou publique distincte de celle du tunnel VPN, même avec VPN actif. Cette fuite est invisible côté utilisateur (aucun indicateur navigateur) et silencieuse côté VPN (le tunnel reste « connecté »).

À cela s'ajoutent les fuites par MTU mal calibré (fragmentation provoquant des fuites de fragments en clair lors de la reassembly côté serveur) et les défaillances kill switch (micro-coupures du tunnel de 1-3 secondes lors de changement de réseau WiFi/4G, durant lesquelles le trafic passe en clair par la route FAI par défaut).

Vecteur 1 - Fuite DNS : méthode détaillée

La fuite DNS survient quand le client VPN ne capture pas l'intégralité des requêtes de résolution de noms et laisse l'OS interroger les résolveurs FAI ou public (8.8.8.8 Google, 1.1.1.1 Cloudflare) en parallèle. Conséquence : ces résolveurs voient passer toutes les requêtes (domaines consultés), exposant un journal complet d'activité au FAI ou à l'opérateur public.

Test recommandé - dns-leak-detector-cli. Outil CLI Node.js que nous maintenons sur GitHub ricco020/dns-leak-detector-cli. Installation et exécution :

npx dns-leak-detector --resolver auto --hostnames 10 --verbose

Le script résout 10 hostnames distincts (subdomains aléatoires) et analyse les résolveurs ayant traité chaque requête côté serveur. Sortie attendue : tous les résolveurs identifiés appartiennent au pool VPN du fournisseur utilisé. Sortie défaillante : présence de résolveurs FAI (préfixes ASN connus AS3215 Orange, AS12322 Free, AS3209 Telefonica, AS3320 Deutsche Telekom) ou résolveurs publics non-VPN (8.8.8.8 Google, 9.9.9.9 Quad9, 1.1.1.1 Cloudflare).

Tests web complémentaires. dnsleaktest.com (test extended à 1000+ résolveurs), browserleaks.com/dns. Avantage : pas d'installation. Inconvénient : reposent sur la consultation par navigateur, peuvent masquer des fuites système (OS) hors navigateur.

Réparation si fuite détectée. Dans les paramètres NordVPN : Settings → DNS → Use NordVPN DNS (activé par défaut). Dans Surfshark : Settings → Advanced → Custom DNS (désactiver, laisser auto). Dans ExpressVPN : automatique. Si fuite persistante après vérification client : vérifier que l'OS n'a pas un résolveur DNS hardcodé (macOS Network Preferences → DNS, Windows Network Settings → Properties → IPv4 → DNS). Pour les VPN open-source (WireGuard manuel), ajouter explicitement la directive DNS = 10.0.0.1 (IP DNS interne du serveur VPN) dans le fichier de config.

Vecteur 2 - Fuite WebRTC : la moins connue

WebRTC expose via l'API JavaScript RTCPeerConnection.createOffer() l'ensemble des candidats ICE qui incluent : IP locale (LAN privé 192.168.x.x, 10.x.x.x, 172.16-31.x.x), IP publique (sortie réseau via STUN), parfois IPv6 native. Un site web malveillant ou simplement curieux peut interroger ces candidats en quelques millisecondes sans permission utilisateur explicite.

Test recommandé - webrtc-leak-detector. Page HTML standalone ricco020/webrtc-leak-detector. Ouvrir dans le navigateur avec VPN actif. Le script collecte les candidats ICE et compare avec l'IP attendue du tunnel.

Sortie attendue : seule l'IP publique du serveur VPN visible. Aucune IP locale exposée. Aucune IP publique alternative.

Sortie défaillante typique : IP publique du tunnel + IP locale du LAN privé visible (fuite partielle, identifie le réseau local mais pas le pays), ou IP publique du tunnel + IP publique distincte du FAI (fuite intégrale, identifie le pays réel).

Réparation. Dans NordVPN : Settings → Advanced → activer « Block WebRTC ». Dans Chrome : installer l'extension WebRTC Control qui désactive les ICE candidates non tunnelisés. Dans Firefox : about:config → media.peerconnection.enabled = false. Sur Safari : configuration plus délicate, généralement résolue par activation du Block WebRTC côté client VPN.

Vecteur 3 - Fuite IPv6 : 40 % des fibres françaises concernées

IPv6 est la zone de fuite la plus sous-estimée en 2026. Les FAI européens (Free, Orange, SFR, Telefonica, Deutsche Telekom) déploient massivement le dual-stack IPv4/IPv6 sur fibre. Si le client VPN tunnelise IPv4 mais laisse IPv6 sortir par la route par défaut, toute requête à un service compatible IPv6 (Google, Facebook, Cloudflare, AWS) transite hors tunnel.

Test direct CLI :

curl -6 https://ipv6.icanhazip.com --max-time 5

Sortie attendue : soit timeout (IPv6 bloqué par VPN, configuration sûre), soit IP IPv6 appartenant au pool VPN (vérifier que le préfixe correspond bien aux préfixes NordVPN / Surfshark / ExpressVPN).

Sortie défaillante : IP IPv6 native FAI visible. Préfixes typiques à reconnaître : 2a01:e00::/27 Orange, 2a01:e35::/32 Free, 2a02:1210::/26 SFR, 2a02:560::/29 Bouygues, 2a02:9000::/24 Vodafone, 2a02:8071::/29 Telefonica, 2003:a::/24 Deutsche Telekom.

Réparation. Dans NordVPN : Settings → Advanced → activer « Block IPv6 ». Dans Surfshark : auto par défaut depuis v4.x. Dans ExpressVPN : Settings → Advanced → Block IPv6. Alternative au niveau OS : sur Linux sysctl net.ipv6.conf.all.disable_ipv6=1, sur Windows Disable-NetAdapterBinding -ComponentID ms_tcpip6, sur macOS via Network Preferences → désactiver IPv6 sur l'interface.

Vecteur 4 - MTU mal calibré : fragmentation et fuites partielles

Le MTU (Maximum Transmission Unit) définit la taille maximale d'un paquet IP transmis sans fragmentation. Sur Ethernet standard, MTU = 1500 octets. Un tunnel VPN ajoute un overhead : ~80 octets pour WireGuard, ~28-50 octets pour OpenVPN UDP, jusqu'à 70 pour OpenVPN TCP avec compression. MTU effectif tunnel = 1500 - overhead.

Si l'OS continue d'envoyer des paquets 1500 octets sur un tunnel à MTU 1420 effectif, fragmentation : le paquet est découpé en 2 fragments, transmis séparément, reassemblé côté serveur destination. Conséquences : performance dégradée (latence +50-100ms typique), parfois pertes (les routeurs intermédiaires fragmentent mal IPv6), et selon les implémentations VPN une fuite de fragments en clair si le tunnel rejette les paquets surdimensionnés (rare mais documenté sur OpenVPN UDP avec compression activée).

Test direct CLI :

# Linux / macOS
ping -M do -s 1472 example.com

# Windows
ping -f -l 1472 example.com

Interprétation : 1472 octets de payload + 28 octets d'en-tête ICMP/IP = 1500 octets total. Si l'écho revient : MTU 1500 acceptable. Si « message too long » : descendre par paliers de 50 (1422, 1372, 1322...) jusqu'à obtenir l'écho.

MTU optimal selon protocole VPN : NordLynx / WireGuard 1420 typique, OpenVPN UDP 1450 typique, OpenVPN TCP 1430 typique, NordWhisper 1420 typique. Configurer cette valeur manuellement sur l'interface VPN si performance dégradée constatée.

Vecteur 5 - Kill switch défaillant : micro-coupures invisibles

Le kill switch est la dernière ligne de défense en cas de chute du tunnel VPN. Deux modes existent : mode app (bloque le trafic d'applications spécifiques) et mode système (bloque tout le trafic OS sortant). Seul le mode système est suffisamment robuste pour garantir l'absence de fuite lors des micro-coupures de 1-3 secondes invisibles à l'utilisateur (changement de réseau WiFi, perte 4G en métro, transition LTE↔5G).

Test reproductible :

# Terminal 1 - lancer un ping continu vers ipinfo.io
watch -n1 curl -s ipinfo.io | jq .ip

# Terminal 2 - déconnecter le VPN brutalement
sudo killall -9 nordvpn-daemon  # ou équivalent selon client

Sortie attendue : le curl du terminal 1 échoue immédiatement avec timeout/refused. Pas de bascule transparente vers IP FAI. Le kill switch a fonctionné.

Sortie défaillante : le curl continue de retourner une IP, mais ce n'est plus l'IP VPN - c'est l'IP FAI réelle. La micro-coupure a laissé passer le trafic. Kill switch en mode app uniquement ou non activé.

Réparation. Dans NordVPN : Settings → Kill Switch → activer Kill Switch (system-level) et Internet Kill Switch. Dans Surfshark : Settings → VPN settings → Kill switch (activé). Dans ExpressVPN : Network Lock (activé par défaut). Pour les VPN open-source (WireGuard manuel), implémenter le kill switch via règles iptables/nftables explicites refusant tout trafic sortant non encapsulé wg0.

Documenter pour conformité RGPD article 32

Pour un freelance ou une entreprise soumise au RGPD, le test trimestriel constitue une vérification raisonnable de la mesure technique VPN au sens de l'article 32. Documentation recommandée :

• Capture d'écran datée du résultat de chaque test
• Archivage dans vpn-tests/{date}/ avec hash SHA-256 du fichier
• Ligne dans le registre des traitements : « Vérification trimestrielle absence de fuite VPN - dernier test JJ/MM/AAAA »
• En cas de fuite détectée et corrigée : noter la fuite, la cause, la correction appliquée et la date de retest

Cette documentation est demandée en cas de contrôle CNIL ou d'audit RGPD interne. Voir notre guide complet RGPD VPN freelance pour le contexte juridique.

Ce qu'il faut retenir

Tester un VPN en 2026 n'est plus un single check DNS - c'est une méthodologie unifiée 5 dimensions (DNS, WebRTC, IPv6, MTU, kill switch) qui prend ~30 minutes et peut révéler des fuites silencieuses qu'un test DNS standard ne voit pas. Outils open-source disponibles : dns-leak-detector-cli et webrtc-leak-detector, avec commandes shell complémentaires pour IPv6, MTU et kill switch. Test trimestriel obligatoire ou à chaque changement de contexte (nouveau FAI, mise à jour OS, nouveau client VPN). Pour RGPD article 32, documenter chaque vérification avec capture datée - preuve de diligence raisonnable en cas d'audit.

Disclosure : Eric Gerard est mainteneur des outils open-source dns-leak-detector-cli et webrtc-leak-detector cités dans cet article. Pas de monétisation directe des outils - uniquement liens d'affiliation NordVPN dans le contenu éditorial. Sources techniques : RFC 4787 NAT behavior, RFC 5245 ICE, WireGuard whitepaper, W3C WebRTC specification.