Fuites DNS, IPv6, WebRTC et interrupteur d'arrêt
Un client VPN peut router correctement le trafic principal dans le tunnel et pourtant laisser échapper des informations qui suffisent à révéler qui vous êtes ou ce que vous consultez. Comme l'explique la page d'accueil sur le fonctionnement d'un tunnel, l'étanchéité dépend d'une série de réglages faits au moment de l'établissement. Voici les trois fuites courantes, leur mécanique, et la façon de vérifier.
La fuite DNS
Avant de contacter un site, votre machine traduit son nom en adresse IP via une requête DNS. Cette requête part vers un résolveur : celui de votre fournisseur d'accès par défaut, ou celui poussé par le VPN. Si le client VPN ne force pas le DNS dans le tunnel, la résolution continue de partir vers le résolveur du fournisseur d'accès, avec votre adresse réelle, révélant chaque nom de domaine que vous consultez — même si le trafic web, lui, passe bien par le tunnel.
Plusieurs cas particuliers aggravent le problème. Windows pratique la « résolution de noms multi-réseau intelligente » : il envoie la requête sur toutes les interfaces à la fois et garde la réponse la plus rapide, ce qui fait sortir des requêtes hors tunnel même quand un résolveur VPN est configuré. Certains navigateurs activent le DNS chiffré (DoH) vers leur propre résolveur, court-circuitant le réglage système et donc celui du VPN. Un client sérieux traite ces cas : il redirige de force tout le trafic à destination du port 53 vers le résolveur du tunnel, désactive la résolution multi-réseau, et documente son interaction avec le DoH des navigateurs.
La fuite IPv6
La plupart des machines et des réseaux fonctionnent en double pile : IPv4 et IPv6 en parallèle. Beaucoup de VPN, historiquement, ne géraient que l'IPv4 : ils routaient 0.0.0.0/0 dans le tunnel mais laissaient ::/0 emprunter la connexion physique. Résultat, un site accessible en IPv6 voyait votre adresse IPv6 réelle pendant que votre IPv4 était masquée. Deux réponses correctes existent : router aussi l'IPv6 dans le tunnel — la bonne solution —, ou désactiver complètement l'IPv6 sur la machine tant que le VPN est actif. Laisser une pile non gérée est une fuite garantie sur un réseau IPv6.
La fuite WebRTC
WebRTC est le mécanisme qui permet aux navigateurs les appels audio et vidéo en pair-à-pair. Pour établir ces connexions, il utilise un protocole (ICE) qui interroge des serveurs STUN afin de découvrir toutes les adresses de la machine : adresses locales, et parfois l'adresse publique réelle. Une page web peut lire ces adresses en JavaScript, sans permission, et ainsi contourner le VPN pour un navigateur. Les navigateurs récents atténuent la fuite des adresses locales en les remplaçant par un identifiant mDNS aléatoire, mais la fuite de l'adresse publique via un serveur STUN accessible hors tunnel reste possible selon la configuration. La parade est de désactiver WebRTC ou d'en restreindre le comportement dans les réglages du navigateur ou via une extension, en particulier si le tunnel est divisé.
Les fuites par le trafic de découverte du réseau
Un système d'exploitation émet, en permanence et sans intervention de l'utilisateur, un trafic de fond : détection de portail captif pour savoir s'il faut afficher une page de connexion, résolution de noms locaux par mDNS et LLMNR, annonces de découverte de services, synchronisation de l'horloge. Une partie de ce trafic vise des serveurs de l'éditeur du système ou des adresses de diffusion du réseau local. Si le tunnel est divisé ou mal réglé, ces requêtes sortent avec l'adresse réelle et révèlent au moins la présence de la machine et son type. Un client rigoureux inclut ce trafic dans le tunnel ou le bloque tant que le VPN est actif.
Les applications qui contournent le routage
La table de routage ne s'impose pas à tout le monde. Une application peut délibérément lier ses connexions à une interface précise, ou utiliser sa propre pile réseau. Certains logiciels de visioconférence, de jeu ou de partage de fichiers le font pour optimiser la latence, et se retrouvent alors hors du tunnel même quand celui-ci est complet. Les systèmes mobiles compliquent encore la situation : une application peut demander une exemption de VPN, et le système d'exploitation lui-même route parfois certains services hors du tunnel de l'utilisateur. Vérifier les fuites depuis chaque application sensible, et pas seulement depuis le navigateur, est donc nécessaire.
La fuite au démarrage et à la reconnexion
Entre le moment où la connexion réseau est disponible et celui où le tunnel est établi, il existe une fenêtre de quelques secondes pendant laquelle les applications qui émettent déjà — client de messagerie, synchronisation, navigateur rouvert avec ses onglets — passent en clair. Le même phénomène se produit à chaque perte puis rétablissement du tunnel, fréquent en mobilité. Sans protection, ces fenêtres suffisent à divulguer une adresse ou une requête.
L'interrupteur d'arrêt
L'interrupteur d'arrêt est la contre-mesure de dernier recours : il n'autorise le trafic à sortir que par l'interface du tunnel et bloque tout le reste tant que le tunnel n'est pas établi. Les implémentations varient. Sur Windows, elles s'appuient sur la plateforme de filtrage (WFP) pour poser des règles au niveau du noyau. Sur Linux et macOS, elles utilisent le pare-feu du système (nftables, pf) ou une route par défaut pointant vers un trou noir. On distingue l'interrupteur applicatif, qui ne coupe que si l'application VPN détecte la chute — inefficace si l'application elle-même plante —, et l'interrupteur au niveau système, qui tient même dans ce cas. Un bon client applique aussi ces règles dès le démarrage de la machine, avant que la moindre application ne s'exécute, pour fermer la fenêtre initiale.
La fuite de trafic hors du tunnel sur portail captif
Un cas particulier revient souvent en mobilité : le réseau Wi-Fi d'un hôtel ou d'un aéroport impose une page de connexion avant de laisser passer le trafic. Le client VPN, lui, tente d'établir le tunnel dès que l'interface est active, échoue, et selon son réglage soit bloque tout — l'utilisateur ne peut alors pas atteindre la page de connexion —, soit ouvre une brèche temporaire pour la traverser. Cette brèche, si elle est trop large ou mal refermée, laisse passer du trafic en clair. Les bons clients proposent un mode « portail captif » qui n'autorise que le strict nécessaire à l'authentification, puis rétablit le blocage complet.
Tester son tunnel
Quelques vérifications, à faire une fois le VPN connecté. Comparer son adresse IP publique affichée par un service de vérification, avant et après connexion, en IPv4 et en IPv6. Lancer un test de fuite DNS : les résolveurs listés doivent appartenir au fournisseur du VPN, jamais à votre fournisseur d'accès. Vérifier une fuite WebRTC sur une page dédiée, depuis chaque navigateur utilisé. Sous Linux, dig +short whoami.exemple et un traceroute vers une destination arbitraire montrent par où sort réellement le trafic. Enfin, tester l'interrupteur d'arrêt en coupant volontairement l'interface physique : aucun paquet ne doit passer jusqu'au rétablissement.
Ce qu'il faut retenir
Un tunnel qui « fonctionne » n'est pas forcément étanche : le DNS, l'IPv6 et WebRTC sont trois voies par lesquelles l'adresse ou l'activité peuvent sortir, et il existe une fenêtre de fuite à chaque établissement. Un client correct force le DNS, gère ou désactive l'IPv6, propose un interrupteur d'arrêt au niveau système, et tout cela se vérifie en quelques minutes. La manière dont ces routes sont installées est détaillée sur la page routage d'un client VPN ; ce qui se passe quand le tunnel est activement bloqué, sur la page obfuscation.