Diagnostic

Fuites DNS, WebRTC et IPv6 : ce qu'un VPN ou un proxy laisse passer

Un VPN ou un proxy n'est utile que si tout le trafic concerné passe réellement par lui. Or trois mécanismes ordinaires peuvent emprunter un autre chemin, sans message d'erreur ni signe visible : la résolution des noms de domaine, la négociation WebRTC du navigateur, et IPv6. On parle alors de fuite. Revenir au rôle d'un intermédiaire réseau aide à comprendre pourquoi : il ne protège que ce qu'on lui confie, et le système d'exploitation ne lui confie pas toujours tout.

La fuite DNS

Avant de contacter un site, l'appareil demande à un résolveur DNS quelle adresse IP correspond au nom de domaine. Sans VPN, ce résolveur est en général celui du fournisseur d'accès, qui voit donc passer la liste des sites consultés. Avec un VPN, ces questions doivent partir dans le tunnel, vers le résolveur du service VPN. Il y a fuite quand elles continuent de sortir vers le résolveur du fournisseur d'accès, en dehors du tunnel : le VPN masque alors votre adresse aux sites, mais votre fournisseur d'accès connaît toujours la liste des noms que vous visitez.

Le site ne voit que le serveur VPN, mais le fournisseur d'accès reçoit toujours la liste des noms de domaine consultés.

Pourquoi cela arrive

Les causes sont connues. Le logiciel VPN peut ne pas remplacer les serveurs DNS configurés sur la carte réseau physique. Windows, depuis sa version 8, peut envoyer une même requête DNS sur plusieurs interfaces à la fois et retenir la première réponse, ce qui fait sortir des requêtes hors du tunnel si le client VPN ne l'en empêche pas. Un réseau peut aussi intercepter le port 53 et répondre à la place du résolveur demandé. Côté proxy, la cause typique est un client SOCKS5 qui résout les noms localement avant d'envoyer l'adresse IP au proxy ; Firefox, par exemple, propose une option distincte pour confier ces requêtes DNS au proxy SOCKS.

Le DNS chiffré intégré aux navigateurs, dit DNS over HTTPS, n'est pas une fuite au sens strict : la requête passe bien dans le tunnel, mais elle aboutit chez le résolveur choisi par le navigateur plutôt que chez celui du VPN. C'est un choix de confiance à connaître, pas un défaut.

Comment la détecter

Le plus simple est de demander à un serveur DNS particulier de vous dire quel résolveur l'interroge. Le nom whoami.akamai.net répond avec l'adresse IP du résolveur qui lui pose la question, et non avec une adresse de site :

# Windows, VPN actif
nslookup whoami.akamai.net

# macOS et Linux
dig +short whoami.akamai.net

Faites le test sans VPN, puis avec. Si l'adresse renvoyée avec le VPN actif appartient toujours à votre fournisseur d'accès, vos requêtes DNS fuient. Les pages web de test de fuite DNS reposent sur le même principe, en générant des noms aléatoires et en observant quels résolveurs viennent les chercher.

Comment la corriger

Activez la protection contre les fuites DNS du logiciel VPN, si elle ne l'est pas par défaut, et vérifiez que le résolveur affiché est bien celui du service. Avec un proxy SOCKS5, utilisez la résolution distante : l'option correspondante du navigateur, ou la forme socks5h:// dans les outils en ligne de commande. Si le problème persiste, c'est le logiciel qu'il faut changer, pas le réglage.

La fuite WebRTC

WebRTC est la technologie qui permet aux navigateurs de passer des appels audio et vidéo directement entre eux. Pour établir ces liaisons, le navigateur rassemble des « candidats », c'est-à-dire les adresses par lesquelles il peut être joint : son adresse sur le réseau local et son adresse publique, qu'il obtient en interrogeant un serveur STUN. Une page web peut déclencher cette collecte en JavaScript, sans demander l'accès au micro ni à la caméra.

Avec un VPN qui couvre tout l'appareil, la requête STUN passe elle aussi dans le tunnel, et l'adresse publique découverte est celle du serveur VPN : pas de fuite. Le problème apparaît avec un proxy, ou une extension de navigateur présentée comme un VPN. La requête STUN part en UDP, ne passe pas par le proxy HTTP, et révèle votre adresse publique réelle à la page qui l'a provoquée. Quant à l'adresse locale, les principaux navigateurs la remplacent depuis 2019 environ par un nom aléatoire en .local, ce qui a réglé l'essentiel de cette partie du problème.

Comment la détecter et la corriger

Les pages de test WebRTC affichent les candidats que votre navigateur publie : avec l'intermédiaire actif, aucune adresse publique réelle ne doit y figurer. Pour corriger, plusieurs niveaux existent. Dans Firefox, le réglage avancé media.peerconnection.enabled, passé à false, désactive WebRTC. Les navigateurs basés sur Chromium proposent une politique d'administration, WebRtcIPHandling, dont la valeur disable_non_proxied_udp force WebRTC à passer par le proxy ou à s'abstenir. Le Navigateur Tor, lui, désactive WebRTC par défaut. Désactiver WebRTC casse évidemment la visioconférence dans le navigateur : c'est un arbitrage, à faire en connaissance de cause.

La fuite IPv6

Une grande partie des connexions françaises disposent aujourd'hui à la fois d'une adresse IPv4 et d'une adresse IPv6. Un VPN qui ne gère que l'IPv4 et ne bloque pas l'IPv6 laisse les sites accessibles en IPv6 être contactés directement, avec votre adresse IPv6 réelle. Or le début de cette adresse, le préfixe, est attribué par le fournisseur d'accès à votre ligne : il identifie l'abonnement aussi sûrement qu'une adresse IPv4.

Le test consiste à demander son adresse publique dans les deux versions du protocole :

# Windows (curl est fourni depuis Windows 10), macOS et Linux
curl -4 https://icanhazip.com
curl -6 https://icanhazip.com

Avec le VPN actif, la première commande doit renvoyer l'adresse du serveur VPN. La seconde doit renvoyer une adresse IPv6 du VPN, ou échouer. Si elle renvoie votre adresse IPv6 habituelle, il y a fuite. La correction passe par un VPN qui prend en charge l'IPv6, ou au minimum qui le bloque pendant la connexion. Désactiver l'IPv6 sur la carte réseau fonctionne aussi, au prix de quelques effets de bord sur certains services.

La quatrième fuite : la coupure du tunnel

Un tunnel peut tomber : changement de réseau Wi-Fi, mise en veille, serveur saturé. Pendant les secondes nécessaires à la reconnexion, le système reprend sa route normale et le trafic sort en clair, avec votre adresse réelle. C'est le rôle du kill switch de bloquer tout trafic hors du tunnel tant que celui-ci n'est pas rétabli. Pour le vérifier, lancez un ping continu vers un site, coupez le Wi-Fi quelques secondes puis rétablissez-le : avec un kill switch efficace, aucune réponse ne doit revenir tant que le VPN n'est pas reconnecté.

En pratique : le test en cinq minutes

Sans VPN, notez votre adresse IPv4, votre adresse IPv6 et votre résolveur DNS.
Avec le VPN, refaites les trois mesures : l'IPv4 doit être celle du serveur, l'IPv6 absente ou celle du VPN, le résolveur différent de celui du fournisseur d'accès.
Ouvrez une page de test WebRTC : aucune adresse publique réelle ne doit apparaître.
Coupez le Wi-Fi dix secondes, VPN actif : rien ne doit sortir hors du tunnel.
Refaites ces tests après chaque mise à jour du logiciel et sur chaque nouveau réseau.

Ce que ces tests ne disent pas

Un intermédiaire sans fuite reste un intermédiaire : il voit ce que voyait votre fournisseur d'accès, et ces tests ne disent rien de ce qu'il en fait. Ils ne disent rien non plus de l'empreinte de votre navigateur, ni des comptes connectés, qui vous identifient indépendamment de l'adresse IP. Ils vérifient une seule chose, essentielle : que l'outil fait bien ce pour quoi on l'a installé. Pour choisir cet outil, voir VPN ou proxy selon l'usage ; pour les mécanismes de base, le fonctionnement d'un VPN et celui d'un proxy.