Le glossaire VPN définit une fuite DNS comme une situation où votre trafic passe par le tunnel VPN, mais où la résolution des noms de domaine continue de transiter par un autre chemin. Cette page détaille comment ce type de fuite se produit réellement, en quoi une fuite WebRTC est un problème distinct mais tout aussi important, et surtout comment vérifier vous-même, en quelques minutes, si votre connexion en est victime.
Ce qui se passe techniquement lors d'une fuite DNS
Chaque fois que votre appareil doit contacter un site web, il envoie d'abord une requête DNS pour traduire le nom de domaine en adresse IP. Sur une connexion sans VPN, cette requête part vers le résolveur configuré par votre fournisseur d'accès à Internet. Lorsqu'un VPN fonctionne correctement, il doit rediriger cette requête vers son propre résolveur, à travers le tunnel chiffré, au même titre que le reste du trafic.
Une fuite DNS survient lorsque le système d'exploitation continue d'envoyer une partie de ces requêtes au résolveur habituel, en dehors du tunnel, malgré la connexion VPN active. Cela peut se produire parce que le système interroge plusieurs résolveurs en parallèle pour accélérer la navigation, parce que la configuration réseau du routeur reste prioritaire pour ce type de requête, ou parce que l'application VPN ne force pas explicitement le routage DNS au niveau système. Le résultat concret est que votre fournisseur d'accès peut connaître la liste des domaines que vous consultez, même si le contenu de vos échanges reste chiffré.
Un problème distinct : la fuite WebRTC
WebRTC (Web Real-Time Communication) est une technologie intégrée par défaut dans la plupart des navigateurs modernes, conçue pour permettre des communications audio, vidéo et de partage de données en temps réel directement entre deux navigateurs, sans passer par un serveur intermédiaire. Elle sert notamment aux services de visioconférence.
Pour établir une connexion directe, WebRTC utilise un mécanisme appelé ICE (Interactive Connectivity Establishment), qui collecte plusieurs adresses réseau candidates : l'adresse locale de l'appareil, mais aussi son adresse IP publique, obtenue via des serveurs STUN. Cette collecte se fait au niveau du navigateur, indépendamment du tunnel VPN. Un site web, ou simplement un script publicitaire, peut déclencher cette négociation en arrière-plan et récupérer votre adresse IP publique réelle, même si votre trafic HTTP classique passe bien par le VPN. Un VPN irréprochable sur le plan du chiffrement peut donc laisser fuiter votre IP réelle par ce canal si aucune protection spécifique n'est activée.
Pourquoi ces deux fuites échappent souvent à toute détection
Ce qui rend ces deux mécanismes particulièrement problématiques, c'est qu'ils ne déclenchent aucune alerte dans l'interface de l'application VPN. Aucun message d'erreur, aucune icône rouge ne signale qu'une requête DNS ou qu'une négociation WebRTC vient de contourner le tunnel. L'utilisateur voit un statut "connecté" et n'a aucune raison de suspecter quoi que ce soit tant qu'il n'a pas procédé à une vérification technique active.
Protocole de détection, étape par étape
La vérification ne demande pas de compétences réseau avancées. Avant toute chose, relevez votre adresse IP publique et le résolveur DNS utilisé sans VPN activé, en utilisant n'importe quel service en ligne de vérification d'adresse IP et de test de fuite DNS. Notez ces deux informations comme référence.
Activez ensuite votre VPN, connectez-vous à un serveur, et effectuez à nouveau les deux mêmes vérifications. L'adresse IP publique doit avoir changé et correspondre à celle du serveur VPN choisi. Le résolveur DNS affiché doit correspondre à celui du fournisseur VPN, jamais à celui de votre fournisseur d'accès habituel. Si le résolveur reste identique à celui relevé avant connexion, une fuite DNS est confirmée.
Pour la fuite WebRTC, la méthode est différente : recherchez un test de fuite WebRTC en ligne, qui déclenchera lui-même une négociation ICE dans votre navigateur et affichera les adresses IP détectées. Si une adresse différente de celle attribuée par votre VPN apparaît dans les résultats, votre navigateur expose votre IP réelle malgré le tunnel actif.
Ces deux vérifications doivent être répétées régulièrement, pas seulement une fois à l'installation : une mise à jour du système d'exploitation, un changement de routeur ou une mise à jour de l'application VPN ou du navigateur peuvent modifier ce comportement sans avertissement.
Corriger une fuite DNS
Si une fuite DNS est confirmée, plusieurs pistes existent. Vérifiez d'abord dans les paramètres de votre application VPN si une option de "protection contre les fuites DNS" ou de "DNS forcé" existe et est activée : de nombreux clients l'incluent mais ne l'activent pas toujours par défaut. Si votre système d'exploitation permet de configurer manuellement un résolveur DNS, assurez-vous qu'aucun résolveur tiers n'est configuré en dehors de celui poussé par le VPN au moment de la connexion. Sur certains systèmes, désactiver la résolution DNS parallèle multi-résolveur (une fonctionnalité d'accélération présente sur certains navigateurs et systèmes récents) élimine également ce type de fuite.
Corriger une fuite WebRTC
Deux approches permettent de traiter une fuite WebRTC. La première consiste à désactiver complètement WebRTC dans les paramètres avancés du navigateur, ce qui élimine le risque mais désactive aussi les fonctionnalités de visioconférence natives au navigateur. La seconde, plus pratique au quotidien, consiste à utiliser une extension de navigateur dédiée au blocage spécifique des fuites WebRTC, qui bloque la négociation ICE non désirée sans désactiver la technologie dans son ensemble. Certaines applications VPN intègrent également une protection WebRTC directement au niveau système, ce qui évite d'avoir à configurer chaque navigateur individuellement.
Le cas particulier d'un VPN installé sur un routeur
Installer un VPN directement sur un routeur domestique, plutôt que sur chaque appareil individuellement, complique le diagnostic. Un routeur mal configuré peut continuer à utiliser son propre résolveur DNS pour certains appareils du réseau local pendant que d'autres passent correctement par le tunnel, ce qui crée une situation hétérogène difficile à repérer sans tester chaque appareil séparément. Il est donc recommandé, dans ce cas, de répéter le protocole de détection décrit plus haut sur chaque appareil connecté au réseau, plutôt que de considérer qu'une vérification unique suffit pour l'ensemble du foyer.
Sur mobile, une vigilance particulière
Sur smartphone, les fuites DNS et WebRTC obéissent aux mêmes mécanismes que sur ordinateur, mais avec une variable supplémentaire : le changement fréquent de réseau entre Wi-Fi et données cellulaires. Cette transition force souvent le tunnel VPN à se reconstruire, et selon l'implémentation du client, une brève fenêtre peut s'ouvrir pendant laquelle le résolveur DNS repasse temporairement par celui du réseau local avant que le nouveau tunnel ne soit pleinement établi. Il est donc utile de répéter le test de fuite DNS après un changement de réseau, pas seulement juste après l'activation initiale du VPN.
Le lien avec le kill switch
Ces deux fuites sont indépendantes du kill switch de votre VPN : un kill switch répond à la question "que se passe-t-il si le tunnel tombe complètement", tandis qu'une fuite DNS ou WebRTC se produit alors même que le tunnel reste actif et fonctionnel. Un VPN peut donc disposer d'un excellent kill switch tout en laissant fuiter votre résolveur DNS ou votre IP réelle par WebRTC, ce qui illustre pourquoi ces deux protections doivent être évaluées et testées séparément plutôt que d'être supposées couvertes l'une par l'autre.
Ce qu'il faut retenir
Un statut "connecté" dans une application VPN n'est pas une preuve d'étanchéité complète du trafic. Les fuites DNS et WebRTC touchent deux couches différentes du système (la résolution de noms d'un côté, l'API temps réel du navigateur de l'autre), et aucune des deux n'est visible sans un test actif. Intégrer ces deux vérifications à une routine régulière, plutôt qu'à un contrôle unique fait au moment de l'installation, est ce qui distingue une utilisation réellement sécurisée d'une simple impression de sécurité.