Lorsque vous ouvrez la page de vérification d'IP et que l'adresse affichée correspond à la sortie attendue, il est tentant de croire que tous les réglages sont effectifs. En réalité, cela indique seulement que cette requête web a utilisé cette adresse. La résolution DNS, la communication WebRTC et les requêtes IPv6 n'empruntent pas nécessairement le même chemin.
Pour déterminer s'il y a une fuite d'IP ou de DNS, l'essentiel n'est pas « combien d'adresses apparaissent sur la page », mais de savoir si des informations ou du trafic sortent du chemin que vous souhaitez protéger. La présence d'une adresse interne, d'un DNS public ou d'un nom de région différent de la sortie ne suffit pas à conclure à une fuite.
Cet article est utile pour vérifier vos propres appareils, navigateurs et paramètres réseau. Les résultats des tests ne reflètent que l'environnement observable à un instant donné et ne doivent pas être interprétés comme une garantie de confidentialité pour toutes les applications de l'appareil.
Déterminez d'abord le trafic que vous souhaitez protéger
Avant de commencer les tests, répondez à une question simple : avez-vous configuré un proxy navigateur, un proxy système ou un VPN qui prend en charge le routage réseau ?
Leur couverture peut varier. Une extension de navigateur ne gère pas nécessairement les autres applications ; un proxy système ne garantit pas que tous les protocoles respectent les paramètres du proxy. Selon l'implémentation et la configuration, un VPN peut couvrir ou non l'IPv6, le DNS et le trafic séparé.
Si vous avez volontairement autorisé une application à se connecter directement, le fait qu'elle utilise la sortie d'origine n'est pas forcément un dysfonctionnement. Mais si vous attendez que « tout le trafic sortant utilise la sortie spécifiée », le même phénomène mérite une enquête plus approfondie.
Il est conseillé de conserver une base de référence : l'IPv4 publique, l'IPv6 et le résolveur observable par les tests DNS lorsque la configuration cible est désactivée. Cette base sert à comparer avant/après et n'a pas besoin d'être publiée ; en particulier sur un réseau d'entreprise, évitez d'exposer des adresses internes ou des captures d'écran de configuration.
WebRTC : distinguez d'abord les adresses candidates avant de juger si la sortie est exposée
WebRTC permet au navigateur d'effectuer des communications audio/vidéo et de données en temps réel. Pour établir une connexion, il collecte les chemins réseau potentiellement disponibles, appelés candidats ICE.
La documentation MDN sur les types de candidats distingue les types host, srflx, prflx et relay, entre autres. Pour un utilisateur ordinaire, le plus important est de distinguer les informations d'interface locale, les informations observées après traduction d'adresse et les adresses des serveurs relais. L'exposition des candidats à la page web dépend aussi de la politique de confidentialité WebRTC du navigateur.
Résultat du test | Interprétation plus raisonnable |
|---|---|
192.168.x.x, 10.x.x.x et autres adresses IPv4 privées | Peut refléter des informations du réseau local, mais ne suffit pas à conclure à une fuite de la sortie publique |
Noms .local | Peut résulter du traitement de confidentialité du navigateur pour les candidats locaux, et ne correspond pas à l'IP publique réelle |
Adresse publique identique à la sortie attendue | Cohérente avec le test en cours, mais ne garantit pas que tout le trafic a été vérifié |
Adresse publique confirmée comme appartenant au réseau d'origine | Si elle aurait dû être protégée, c'est un signal d'exposition qui mérite une vérification approfondie |
Adresse de relais TURN | Indique que le candidat correspondant passe par un relais, mais ne prouve pas directement l'adresse publique d'origine de l'utilisateur |
L'exposition de l'adresse du réseau d'origine par WebRTC n'est pas une simple hypothèse. La norme RFC 8828 traite de l'exposition des informations IP dans les cas de VPN fractionné, d'interfaces réseau multiples et de proxys applicatifs. Cependant, le comportement réel varie selon l'implémentation du navigateur, les autorisations et les politiques réseau ; on ne peut pas transposer directement les conclusions d'un test effectué sur un ancien navigateur à tous les appareils.
Dans la détection Test de fuite WebRTC, si vous voyez une adresse publique qui ne correspond pas aux attentes, comparez d'abord avec la référence, puis vérifiez à quel réseau elle appartient. Ne concluez pas uniquement sur la base de « une seconde adresse s'affiche » et n'assimilez pas non plus « aucun candidat collecté » à une sécurité absolue — une communication bloquée ou un test inachevé peut aussi produire un résultat vide.
DNS : que signifie voir le résolveur de votre opérateur ?
Avant qu'un navigateur accède à un nom de domaine, il doit généralement obtenir l'adresse correspondante. La fuite DNS consiste à vérifier si cette étape est exécutée conformément à la politique de résolution prévue et si une partie qui ne devrait pas avoir accès aux informations de requête a pu y accéder.
Les tests de fuite DNS courants font demander au navigateur un ensemble de domaines de test, puis observent la source des requêtes du côté du DNS faisant autorité. Ce que la page affiche est généralement la sortie de la chaîne de résolution récursive, et non une lecture directe de la configuration DNS de votre appareil.
Cela signifie qu'après avoir détecté une adresse DNS, vous ne pouvez pas immédiatement conclure que « le serveur DNS local est celui-ci ». Le transfert récursif, les services de résolution publics et les déploiements Anycast peuvent tous rendre le résultat plus complexe que l'interface des paramètres système.
Ne vous fiez surtout pas au seul nom de pays : la localisation par base de données de la sortie DNS diffère de celle de la sortie web et ne suffit pas à prouver à elle seule une fuite. Vous devez vérifier davantage l'opérateur du résolveur, le mode de routage du service et la conformité à vos objectifs de configuration.
Si vous prévoyez d'utiliser uniquement le chemin de résolution spécifié par le VPN, mais que le test observe en continu la sortie de résolution de l'opérateur du réseau d'origine, c'est un signal à investiguer. Si vous avez activement configuré un DNS public, sa détection n'est pas nécessairement une anomalie.
Vous pouvez utiliser la Test de fuite DNS pour comparer avant et après. Lorsque plusieurs résolveurs apparaissent, vérifiez en priorité s'il existe des relations de remplacement ou d'utilisation conjointe entre le « DNS sécurisé » du navigateur, le DNS du système d'exploitation, le DNS du VPN et les paramètres de split tunneling.
Activer DoH, est-ce que cela empêche les fuites ?
DoH résout le problème du chiffrement du transport des requêtes DNS, mais ne résout pas automatiquement tous les problèmes de routage et de confiance. La documentation de Cloudflare présente la manière d'encapsuler les requêtes DNS dans HTTPS, mais « transport chiffré » ne signifie pas « la requête passe certainement par votre VPN spécifié ».
Le service de résolution traite toujours vos requêtes. Certains déploiements peuvent également utiliser EDNS Client Subnet, transmettant des informations de préfixe réseau client dans les requêtes récursives ; ce mécanisme et son impact sur la vie privée sont décrits dans la RFC 7871. Lorsqu'un test DNS ordinaire ne fournit pas explicitement ce résultat, ne supposez pas qu'il a déjà vérifié ECS.
IPv6 : une sortie IPv4 correcte ne signifie pas que l'autre famille d'adresses l'est aussi
De nombreux réseaux fournissent à la fois IPv4 et IPv6. Si un proxy ou un VPN ne traite que l'IPv4 tandis que l'appareil peut encore utiliser directement l'IPv6 via le réseau d'origine, les services cibles compatibles IPv6 peuvent observer un autre chemin de sortie.
Cependant, « les adresses IPv4 et IPv6 diffèrent » est en soi un phénomène normal. Elles appartiennent à des systèmes d'adressage différents, et on ne peut pas juger de l'efficacité de la protection en comparant la similarité textuelle des adresses.
Ce qu'il faut comparer, c'est : l'appartenance réseau des deux protocoles, la conformité du routage réel aux attentes, et si l'IPv6 pointe toujours vers le réseau d'origine. Le changement des adresses temporaires IPv6 n'indique pas non plus automatiquement une fuite.
Dans la Vérification de l’environnement du navigateur, consultez séparément les informations IPv4 et IPv6 disponibles. Si le test IPv6 est inachevé, on ne peut que le marquer comme non confirmé ; ce n'est pas la même conclusion que « IPv6 indisponible confirmé ».
Un ordre de dépannage reproductible
1. Comparer avant et après sur le même appareil et dans le même navigateur
Notez les informations de sortie lorsque la configuration cible n'est pas activée, puis activez la configuration et refaites le test. Pendant le test, évitez de changer simultanément de Wi-Fi, de proxy de navigateur et de DNS, sinon il sera difficile de déterminer quelle étape a provoqué le changement.
2. Vérifier séparément page web, WebRTC, DNS et IPv6
Enregistrez séparément les quatre groupes de résultats : sortie publique observée par la page web, candidats WebRTC, source des requêtes DNS, accessibilité et sortie IPv6. N'utilisez pas l'état vert d'un élément pour remplacer les autres.
3. Localiser les paramètres en fonction du chemin anormal
Si WebRTC expose l'adresse publique du réseau d'origine, vérifiez la couverture du proxy, la politique WebRTC et si le VPN utilise le split tunneling. Si le DNS ne correspond pas aux attentes, vérifiez les paramètres de résolution du navigateur et du système, ainsi que le comportement de restauration DNS après déconnexion du VPN. Si l'IPv6 passe toujours par le réseau d'origine, vérifiez la prise en charge de l'IPv6 par le VPN et le routage associé.
Ne modifiez qu'une seule option pertinente à la fois, puis refaites le test. Lorsque vous devez traiter un problème métier à long terme, conserver l'heure, l'état de configuration et le résumé des résultats est généralement plus utile qu'une simple capture d'« avertissement rouge » pour le diagnostic.
4. Vérifier le comportement après reconnexion
La reconnexion réseau, le réveil de l'appareil après mise en veille et la reconnexion VPN peuvent tous modifier le chemin. Si les conditions le permettent, vérifiez à nouveau après ces scénarios d'utilisation normale. Un test réussi ne prouve que la conformité du comportement observé à ce moment-là et ne remplace pas la vérification ultérieure de la stabilité.
Il n'est pas recommandé de tout désactiver d'emblée
Désactiver directement WebRTC peut affecter les appels et les réunions dans le navigateur ; désactiver directement IPv6 peut également masquer des problèmes de configuration. La décision doit dépendre de vos besoins réels et de la perte de fonctionnalité acceptable, et non simplement de la volonté de faire afficher moins de lignes sur la page de détection.
Une approche plus prudente consiste à clarifier d'abord le périmètre de protection, puis à corriger le routage, la résolution ou les paramètres du navigateur correspondants. Les appareils d'entreprise doivent également suivre les politiques de l'administrateur et ne doivent pas contourner par eux-mêmes les configurations réseau et de sécurité établies.
Une fenêtre de navigation privée peut-elle empêcher ces fuites ?
Ne considérez pas le mode navigation privée comme un tunnel réseau. Il modifie principalement la gestion des données de session locales telles que l'historique et les cookies, mais il ne prend pas en charge le DNS, le WebRTC ou le routage IPv6.
Si l'adresse IP d'origine n'est pas détectée, cela signifie-t-il que vous êtes totalement anonyme ?
Non. Le chemin IP n'est qu'un aspect de la vie privée. La connexion à un compte, les cookies, l'empreinte du navigateur et les informations soumises activement peuvent permettre à un service de vous identifier ou d'associer une visite.
Après avoir effectué ces vérifications, la conclusion raisonnable devrait être : « Dans les conditions de configuration et de test actuelles, les chemins réseau observés sont conformes aux attentes. » C'est plus précis que de dire « zéro fuite, anonymat total » sans préciser le champ d'application, et cela guide mieux l'utilisation ultérieure.
Scénario de répartition du trafic : comment interpréter quatre résultats différents sur un même appareil
Supposons que vous ayez configuré une répartition par domaine, ou que vous utilisiez simultanément un VPN et une connexion directe locale. Lors d'un test, la sortie HTTP affiche l'adresse du nœud proxy A, le test DNS affiche l'adresse du serveur récursif B, les candidats WebRTC incluent l'adresse publique du réseau d'origine C et une adresse TURN D, et l'IPv6 utilise toujours la ligne de l'opérateur. Ces résultats peuvent être interprétés à tort comme « quatre fuites ». En réalité, ils correspondent simplement à des chemins différents. L'important n'est pas le nombre d'adresses IP, mais la conformité de ces chemins avec vos attentes.
Dans cet exemple, si vous souhaitez que seul le trafic HTTP des pages web passe par le proxy, la sortie A peut être conforme à la configuration ; il faut vérifier séparément si le DNS doit être direct. Si l'adresse publique C du réseau d'origine apparaît dans les candidats WebRTC lisibles par la page, cela indique que la page a pu connaître C lors de ce test, sans attendre que la connexion média l'utilise réellement pour considérer cela comme une exposition. La question de savoir si cela constitue une fuite non conforme dépend de votre exigence de masquer cette adresse à la page.
Les candidats mDNS méritent une attention particulière. Les navigateurs utilisent souvent des noms .local générés aléatoirement pour représenter les interfaces réseau locales, évitant ainsi d'exposer directement les informations réelles du réseau local. Voir une entrée comme « 2f8c…local » sur une page de test WebRTC doit être compris comme un traitement de confidentialité pour les candidats locaux, et non comme votre adresse IP publique ou votre nom d'hôte. Le considérer comme une preuve de fuite est une méprise courante. Si une adresse publique du réseau d'origine est également présente, et que l'application devrait être protégée par le tunnel, c'est alors un signal d'exposition qui mérite une vérification approfondie.
L'IPv6 doit également être consignée séparément. Si la sortie IPv4 passe par le proxy A, mais que l'IPv6 utilise toujours la liaison directe de l'opérateur, les sites cibles compatibles double pile peuvent observer votre adresse d'opérateur via IPv6, simultanément ou en priorité. Cela ne résulte pas nécessairement d'une erreur de configuration du proxy ; de nombreux clients utilisant une répartition CIDR ou ne prenant en charge que l'IPv4 ne gèrent pas le routage IPv6 par défaut. Dans ce cas, ne concluez pas hâtivement à une « fuite IPv6 » ; vérifiez d'abord si le VPN ou le proxy prétend couvrir l'IPv6, puis examinez si une route par défaut IPv6 locale pointe vers le tunnel.
Les différences de serveurs récursifs DNS peuvent être évaluées à l'aide des informations ASN et RDAP. Si l'adresse B appartient à un service de résolution public que vous avez désigné, c'est normal même si elle diffère de la sortie HTTP ; si elle appartient à l'opérateur du réseau d'origine et que vous vouliez que le trafic de résolution passe par le tunnel, c'est alors une anomalie à examiner. Les services de résolution déployés en Anycast peuvent afficher différents nœuds selon les régions ; on ne peut pas conclure que le DNS est direct uniquement sur la base d'un changement de localisation géographique. Il faut prêter attention au nom de l'opérateur, à l'attribution ASN, et vérifier si le domaine de test observe des sources de requêtes non conformes du côté faisant autorité.
Face à ces sorties multiples, la première chose à faire n'est pas de désactiver des fonctions, mais de noter vos attentes. Quelles applications doivent passer par le proxy, lesquelles doivent être directes ; qui doit gérer le DNS ; si l'IPv6 doit être couverte par le tunnel ou autorisée en direct ; si le WebRTC est autorisé à collecter des candidats locaux lors de la connexion VPN. Après une mesure, comparez avec la référence. Si un élément ne correspond pas aux attentes, revenez aux paramètres spécifiques et ajustez-les un par un. Ne modifiez qu'une variable à la fois, par exemple changez d'abord le DNS, puis refaites le test, pour déterminer quelle règle a causé la différence.
Mesures répétées et récupération après déconnexion : rendre les résultats de test vérifiables à nouveau
Un test réussi ne montre que l'environnement de ce moment-là était conforme aux attentes. La reconnexion VPN, le réveil du système, les changements de permissions du navigateur peuvent modifier les chemins. Il est conseillé de répéter les mesures après des scénarios d'utilisation normaux : déconnectez puis reconnectez le VPN, après la mise en veille et le réveil, après le basculement entre Wi-Fi et réseau mobile, vérifiez respectivement la sortie HTTP, la source DNS, les candidats WebRTC et l'état IPv6. La stabilité de ces quatre résultats est plus instructive qu'un unique feu vert.
À chaque mesure, ne modifiez qu'une seule variable. Par exemple, si aujourd'hui vous ne changez que les paramètres liés au WebRTC, gardez les paramètres DNS et VPN inchangés ; demain, si vous ne changez que l'IPv6, refaites tous les quatre tests. Si vous ajustez simultanément le « DNS sécurisé » du navigateur, la répartition du proxy et le commutateur IPv6 du système, en cas de comportement intermittent, il sera difficile de retracer la cause. Noter l'heure, l'état de la configuration et un résumé des résultats est plus utile pour la maintenance à long terme qu'une capture d'écran d'avertissement rouge.
Les permissions du navigateur influencent directement les candidats WebRTC. Si un site n'a pas la permission d'accéder au microphone ou à la caméra, le navigateur peut ne pas collecter les candidats des interfaces locales ; une fois l'autorisation accordée pour l'audio/vidéo, la collecte peut s'étendre. Par conséquent, testez WebRTC avant et après l'octroi des permissions pour observer les changements de la liste des candidats. Ne concluez pas qu'il n'existe pas de voie d'exposition WebRTC simplement parce que la page n'a pas de candidats lorsque la permission n'est pas accordée ; c'est confondre « non mesuré » avec « protégé ». De même, une fenêtre de navigation privée ne modifie pas le routage réseau et ne peut pas être considérée comme une mesure anti-fuite.
L'IPv6 doit être gérée explicitement selon les besoins : si une protection double pile complète est requise, choisissez et configurez un tunnel prenant en charge l'IPv6, vérifiez le routage réel et le pare-feu ; si le produit ne prend en charge que l'IPv4, confirmez sa politique de blocage ou de contournement pour l'IPv6. Ajouter simplement une route par défaut ne garantit pas que toutes les applications et les états de déconnexion soient protégés. Désactiver globalement l'IPv6 peut aussi affecter la compatibilité ; il faut d'abord comprendre les capacités du client et conserver une configuration réversible, puis vérifier séparément les états normal, de reconnexion et de déconnexion.
La validation de la récupération après déconnexion doit inclure la politique de « kill switch ». Si un VPN prétend bloquer tout trafic sortant après une déconnexion, testez si les requêtes DNS échouent également lors d'une interruption réseau, au lieu de retomber sur le résolveur du réseau d'origine. Certaines implémentations ne coupent que le TCP IPv4, mais laissent l'IPv6 ou le DNS continuer sur la ligne d'origine ; cette « protection partielle » laisse une fenêtre d'observation. Vous pouvez le confirmer en déclenchant séparément des événements de déconnexion et en observant le comportement des requêtes HTTP, DNS et IPv6.
Un « non-trouvé » dans les résultats de test ne signifie pas « sûr ». Si l'IPv6 affiche une connexion impossible parce que le réseau ne la prend pas en charge, cela doit être marqué comme « non confirmé », et non interprété comme « aucune fuite IPv6 confirmée ». Un chemin ne peut être considéré comme validé que si le test a été émis et que le résultat est conforme aux attentes. Chaque mesure doit indiquer les conditions de test, telles que la version du navigateur, le mode proxy, le protocole VPN et l'environnement réseau, pour permettre une reproduction ultérieure.
Dans des environnements plus complexes, comme le CGNAT qui peut modifier la correspondance entre la sortie publique et l'adresse interne, vous pouvez consulter Trouver son IP publique et vérifier la présence de CGNAT pour comprendre la hiérarchie NAT ; certains outils de détection de sécurité signalent à tort des phénomènes normaux comme caractéristiques de VPN ou de proxy, consultez IP détectée comme VPN ou proxy : vérifier un faux positif pour mieux interpréter les résultats. En combinant ces ressources, vous réduisez les erreurs de jugement dues au type d'adresse ou à la logique de détection.
Enfin, rassemblez les résultats du diagnostic dans un dossier de validation : le chemin attendu est-il clair, chaque type de trafic se comporte-t-il comme prévu dans les trois états (normal, reconnexion, déconnexion), et les anomalies ont-elles été attribuées à des réglages précis. La conclusion ainsi obtenue — « dans les conditions et la portée de test actuelles, les chemins réseau observés sont conformes aux attentes » — a plus de valeur que n'importe quel indicateur vert ponctuel.
