Fuites DNS et IP : qu'est-ce que c'est et comment les détecter
Vous avez activé le tunnel, le voyant passe au vert — et le test affiche pourtant votre fournisseur d'accès et votre ville. C'est ainsi que se manifestent les fuites DNS, IP et WebRTC : le canal est chiffré, mais certaines requêtes s'échappent directement et vous trahissent.
Un tunnel chiffre tout ce qui y circule, mais ne garantit pas de lui-même que l'intégralité de votre trafic y passe. Certaines requêtes peuvent s'échapper directement, en contournant le canal protégé — et ce sont précisément elles qui vous trahissent : votre fournisseur d'accès, votre ville, et parfois votre adresse IP réelle. Voici les trois failles les plus courantes et un moyen de vérifier chacune d'elles en cinq minutes.
Trois types de fuites, en termes simples
Avant de vérifier quoi que ce soit, il est utile de savoir ce que l'on recherche réellement. Il existe trois types de fuites, avec des mécanismes différents :
- Fuite DNS. Chaque fois que vous ouvrez un site, votre appareil demande à un serveur DNS quelle IP correspond au nom de domaine. Si cette requête part vers le serveur de votre fournisseur d'accès au lieu de passer par le tunnel, le fournisseur voit la liste des sites que vous visitez — même si le trafic lui-même est chiffré.
- Fuite IP. Un site ou un service détecte votre adresse réelle au lieu de celle du serveur VPN. Votre IP permet de déduire facilement votre fournisseur et votre localisation approximative.
- Fuite WebRTC. La technologie d'appels vidéo intégrée aux navigateurs peut découvrir directement vos adresses IP locale et publique, en contournant les réglages de proxy et de tunnel.
Pourquoi le DNS vous trahit le plus souvent
Le DNS est le carnet d'adresses d'internet : il traduit des noms lisibles comme example.com en IP numériques. Le problème est que les requêtes DNS classiques circulent en texte clair et sont souvent dirigées vers un serveur défini dans les paramètres réseau ou attribué par le fournisseur. Même avec un tunnel actif, le système peut, par habitude, interroger « son » propre DNS — et la liste de vos domaines devient alors visible côté réseau.
La correction au niveau du protocole consiste à chiffrer les requêtes DNS elles-mêmes. La norme RFC 8484 décrit le DNS over HTTPS (DoH) : la requête est encapsulée dans une connexion HTTPS classique, ce qui la rend indissociable des autres trafics web et protégée contre toute altération. Selon la documentation de Cloudflare, une telle requête circule sur le port 443 — le même que celui des sites ordinaires —, ce qui la rend difficile à isoler dans le flux global. Nous avons détaillé ce que le chiffrement apporte de manière générale dans notre article sur les bases du chiffrement, et en quoi changer de DNS diffère fondamentalement d'un VPN dans VPN, proxy et DNS : quelle différence.
Fuites IP et les subtilités de WebRTC
Une fuite IP « classique » est simple à comprendre : si un site voit l'adresse du serveur VPN au lieu de la vôtre, tout va bien. WebRTC se comporte de façon beaucoup plus retorse. C'est une technologie de navigateur destinée aux appels et au transfert direct de fichiers entre appareils ; pour établir une connexion directe, elle doit connaître les adresses réelles des deux parties.
Pour cela, WebRTC contacte ce qu'on appelle des serveurs STUN. Comme l'explique la documentation WebRTC de MDN, un serveur STUN renvoie un candidat « server reflexive » — essentiellement votre adresse IP publique telle qu'elle est vue depuis l'extérieur de votre réseau domestique. Le navigateur reçoit cette adresse et peut la transmettre à la page web via JavaScript, même si tout le reste du trafic passe par le tunnel. C'est pourquoi un test affiche parfois deux adresses à la fois : la « bonne », issue du VPN, et la vraie, issue de WebRTC.
Comment se vérifier soi-même en cinq minutes
Il s'agit d'un contrôle plus poussé que la vérification de base — si vous n'avez pas encore confirmé que le tunnel est bien connecté, commencez par comment vérifier que votre VPN fonctionne. À partir de là, plus précisément sur les fuites :
- Notez votre adresse sans le tunnel. Désactivez le VPN, ouvrez un service « mon IP » quelconque, et notez l'adresse et le fournisseur — c'est votre point de référence.
- Activez le tunnel et actualisez la page. L'IP devrait changer pour celle et le pays du serveur VPN. Si elle reste identique, c'est une fuite IP.
- Vérifiez le DNS. Ouvrez un site de test de fuite DNS. Le nom de votre fournisseur d'accès habituel ne doit apparaître dans aucun serveur listé.
- Vérifiez WebRTC. Cherchez un test de fuite WebRTC en ligne. S'il affiche votre IP publique de l'étape un, il y a une fuite.
- Répétez sur un autre réseau. C'est particulièrement important dans les cafés et les aéroports — nous avons abordé les risques du Wi-Fi ouvert dans la sécurité des réseaux publics.
Que faire, et comment un tunnel correctement conçu aide
Un bon client comble ces failles par lui-même, sans exiger de réglages manuels de votre part. Points à vérifier :
- DNS à l'intérieur du tunnel. Toutes les requêtes DNS doivent passer par le même canal chiffré vers le serveur DNS du VPN, pas vers celui du fournisseur.
- Kill switch. Si la connexion se coupe, le trafic ne doit pas s'échapper directement avant que le canal ne soit rétabli.
- Contrôle de WebRTC. Dans un navigateur, la fuite se comble par un réglage ou une extension qui empêche les pages de demander les adresses locales.
HamikVPN chiffre l'intégralité du trafic et fait transiter les requêtes DNS par ce même canal protégé, si bien que les noms de sites ne fuient pas vers des serveurs DNS extérieurs et que votre IP réelle reste masquée aux ressources que vous visitez. Si des tests continuent d'afficher des fuites de façon répétée alors que le client est actif, c'est un signal d'alarme — nous avons détaillé ce qu'il faut surveiller d'autre dans les signes d'un VPN peu fiable.