Test de fuite IP et DNS : Vérifiez la sécurité de votre réseau

De nombreux utilisateurs pensent que l'achat d'un "proxy résidentiel" suffit à se faire passer pour un internaute domestique ordinaire. Cependant, les moteurs modernes de détection des risques ne se fient plus uniquement aux étiquettes statiques des bases GeoIP (comme IP2Location ou MaxMind). Même lorsqu'une IP de sortie est classée comme résidentielle/FAI, la passerelle proxy intermédiaire s'exécute presque toujours sur un serveur Linux dans le cloud, ce qui génère des contradictions manifestes entre les couches : Premièrement, la signature de la pile TCP : le serveur de sortie émet la séquence d'options standard de Linux (MSS, SACK_PERM, TS, NOP, WS) lors du handshake SYN initial plutôt que l'ordre propre à Windows ou Apple. Deuxièmement, la discordance du MTU de chemin : une connexion résidentielle PPPoE présente typiquement un MTU de 1492 (les réseaux mobiles entre 1400 et 1430), tandis qu'Ethernet en centre de données est à 1500 (MSS=1460). Lorsqu'un système anti-fraude détecte une IP résidentielle associée à un MTU de centre de données et une pile Linux, il classe la connexion comme un proxy automatisé.

💡 Testez votre connexion avec notre Test d'anonymat de proxy pour vérifier où votre session TCP se termine.

Il n'existe aucun lien physique fixe entre une adresse IP et une position géographique réelle. Les résultats dépendent de la base de données commerciale GeoIP utilisée et de sa fréquence de mise à jour : Premièrement, les sources de données et modèles de mesure varient : les fournisseurs (comme MaxMind, IP2Location ou DB-IP) analysent les annonces BGP, les registres whois et les temps de latence avec des pondérations et des cycles de rafraîchissement allant de quelques jours à plusieurs mois. Deuxièmement, le routage Anycast et les réseaux CDN : des acteurs comme Cloudflare annoncent un même bloc d'adresses IP depuis des centaines de centres de données mondiaux, dirigeant automatiquement la requête vers le point de présence le plus proche. Troisièmement, les réaffectations internationales d'adresses IP : lorsqu'un hébergeur transfère un bloc d'IP enregistré dans un pays vers des serveurs situés dans un autre, les bases obsolètes continuent de rapporter l'ancienne localisation. Notre outil combine des vérifications multi-bases avec une multilateration de délai RTT à la vitesse de la lumière pour authentifier les zones physiques réelles.

Un score de fraude d'IP (ou score de risque) est un indice numérique (généralement compris entre 0 et 100) utilisé par les moteurs de sécurité pour évaluer la probabilité qu'une connexion provienne d'une activité automatisée ou dissimulée. Les principaux facteurs d'évaluation comprennent : Premièrement, la réputation historique et les listes de blocage : si l'IP a été récemment impliquée dans des attaques de type credential stuffing, du web scraping massif, du spam ou des scans de vulnérabilités. Deuxièmement, le type d'ASN et l'infrastructure : les réseaux de centres de données (hébergement) et de proxys publics présentent un risque de base bien plus élevé que les accès résidentiels ou mobiles. Troisièmement, la cohérence multipoint et protocolaire : la détection d'exits divergents en double pile IPv4/IPv6, le décalage géographique du résolveur DNS ou l'exposition de l'IP locale via WebRTC.

💡 Utilisez notre Test de Split Tunneling pour détecter les fuites de routage susceptibles d'augmenter votre score de risque.

Même avec un VPN ou un proxy activé, votre véritable identité peut s'échapper via des canaux secondaires : Premièrement, les fuites DNS : lorsque le navigateur effectue une résolution de nom de domaine, si le client proxy ne capture pas les requêtes au niveau du système d'exploitation, les requêtes partent en clair vers le serveur DNS de votre FAI local, révélant ainsi les sites consultés et votre véritable position géographique. Deuxièmement, les fuites WebRTC : WebRTC est une technologie de communication multimédia en temps réel intégrée aux navigateurs qui, lors de l'établissement de liaisons peer-to-peer (P2P), contourne les couches proxy HTTP/SOCKS pour envoyer directement des paquets STUN en UDP, exposant vos adresses IP locale et publique réelles. Notre page d'accueil analyse vos sorties DNS et l'état de WebRTC en temps réel.

💡 Pour inspecter les fuites matérielles et multimédias, consultez le Test d'empreinte du navigateur.

Le panneau de pile réseau de la page d'accueil exécute trois sondes associées en parallèle : une interroge un domaine avec uniquement des enregistrements A (iptestv4.myipdns.com), une autre un domaine avec uniquement des enregistrements AAAA (iptestv6.myipdns.com), et la troisième un domaine double pile comportant les deux familles d'enregistrements. Les deux premières sont obligatoires : chaque nom d'hôte ne résolvant qu'une seule famille d'adresses, votre système n'a pas le choix, ce qui permet de mesurer indépendamment vos sorties réelles en IPv4 et en IPv6. La troisième sonde n'impose rien ; elle observe au contraire quelle famille d'adresses votre système a lui-même sélectionnée, ce qu'affiche la colonne « Protocole préféré » : ce résultat découle de la politique de sélection d'adresses du système d'exploitation et du navigateur (Happy Eyeballs, RFC 8305 : lorsque les deux piles sont joignables, IPv6 est tenté en premier, IPv4 servant de repli), sans intervention de notre part. Aligner ces trois mesures est primordial car de nombreux clients proxy et VPN ne prennent en charge que l'IPv4 : si votre sortie IPv4 relève de l'ASN du proxy tandis que votre sortie IPv6 demeure celle de votre FAI résidentiel, et que le protocole préféré indique IPv6, lors de l'accès à des sites double pile, la majeure partie de votre trafic n'emprunte absolument pas le tunnel — c'est le cas le plus fréquent de « VPN actif mais identité réelle exposée », sans qu'aucune erreur ne soit signalée.

⚠ Nous pouvons uniquement vous indiquer si vos sorties des deux familles se situent sur des réseaux distincts ; nous ne pouvons pas déterminer la configuration requise pour votre logiciel proxy. Inversement, une sortie IPv6 affichée comme indisponible n'équivaut pas à une garantie de sécurité : votre réseau peut simplement ne pas disposer d'IPv6, ou le proxy peut avoir désactivé intégralement l'IPv6 — ce dernier cas constituant souvent la bonne pratique.

Nous ne lisons pas les paramètres de votre système local : les navigateurs en sont incapables, et toute page prétendant lire votre configuration DNS locale ne fait que deviner. La méthode réelle consiste à procéder au test inverse : notre site héberge son propre serveur DNS faisant autorité et génère lors de chaque test un sous-domaine aléatoire temporaire (de type k3f9x2ab.leakv4.myipdns.com) que votre navigateur doit résoudre. Ce nom n'apparaît qu'une seule fois dans le monde et n'existe dans aucune mémoire cache ; votre chaîne de résolution récursive doit par conséquent remonter jusqu'à notre serveur faisant autorité ; nous consignons l'entité qui émet la requête et transmettons cette adresse à la page. Ainsi, la colonne « Sortie DNS » indique l'adresse réseau de sortie réelle de votre résolveur récursif, et non l'adresse saisie dans vos paramètres système : si vous configurez 8.8.8.8, l'émetteur qui nous interrogera sera une machine spécifique de ce cluster, éventuellement située dans un autre pays ; les grands résolveurs publics utilisant l'anycast et des grappes de serveurs, l'apparition de plusieurs adresses différentes au cours d'un même test est tout à fait normale. Le véritable critère n'est pas la concordance des adresses, mais : si cette sortie appartient au réseau de votre propre fournisseur d'accès à Internet alors que votre IP de navigation transite par le proxy, cela prouve que les requêtes DNS n'ont pas suivi le tunnel.

⚠ Ce procédé permet uniquement de constater qui a interrogé notre propre serveur faisant autorité ; nous ne voyons pas et ne pouvons techniquement pas voir les autres domaines consultés. Il comporte en outre une limite connue : si votre proxy prend également en charge le DNS, nous observerons le résolveur du fournisseur de proxy — confirmant l'absence de fuite vers votre FAI local, mais vos requêtes demeurent visibles pour votre fournisseur de proxy ; c'est une question distincte que notre outil ne mesure pas.

Grâce à WebRTC, des sondes individuelles sont transmises à plusieurs serveurs STUN afin de collecter les candidats srflx renvoyés — soit l'adresse IP publique et le port observés par le serveur distant après traduction NAT. Le critère déterminant est unique : les candidats sont regroupés selon l'IP publique attribuée ; si deux ports distincts ou davantage apparaissent sous la même IP, la connexion est classée en NAT symétrique (attribution d'un nouveau port externe pour chaque nouvelle destination) ; dans le cas contraire, elle est classée en NAT à cône (association constante d'un même port interne au même port public externe). Ce regroupement préalable avant comparaison des ports est délibéré : dans un environnement de proxy à routage fractionné, différents serveurs STUN peuvent emprunter des sorties distinctes, provoquant des divergences de ports ; toutefois, cela découle de différences d'acheminement et non du comportement du NAT — sans regroupement, ces configurations seraient systématiquement qualifiées de symétriques. L'état « Inconnu » s'explique par deux causes : d'abord, l'absence de tout candidat srflx dans le délai d'attente de 4 secondes (WebRTC désactivé dans le navigateur, bloqué par des extensions ou filtrage UDP sortant) ; ensuite, la réception d'un unique candidat dont l'IP publique ne correspond pas à l'IP d'entrée sur notre site, rendant impossible la distinction entre déduplication du navigateur et routage fractionné ; nous préférons alors indiquer inconnu.

⚠ Précision transparente : nous distinguons uniquement les catégories NAT à cône et symétrique, sans sous-classification en cône intégral, restreint ou restreint aux ports. La classification à quatre états de la RFC 3489 impose de contrôler les combinaisons de ports sources et de destinations via des sondes itératives, or WebRTC dans le navigateur n'offre aucun contrôle de ce niveau ; les outils Web qui prétendent afficher l'une des quatre catégories ne font généralement que renommer ces deux observations.

Une analyse sur la page d'accueil comprend plusieurs groupes de requêtes : connexion à plusieurs sous-domaines de ce site pour recueillir les empreintes de pile de protocoles sur IPv4, IPv6 et différentes versions de HTTP ; interrogation de plusieurs services de recherche d'IP tiers et WebRTC afin de déterminer si différentes cibles observent la même sortie ; résolution de sous-domaines aléatoires pour identifier qui résout votre DNS ; envoi de sondes vers nos nœuds situés dans d'autres régions pour une vérification croisée depuis plusieurs emplacements ; et mesure de latence vers plusieurs sites populaires.

⚠ L'inconvénient est la connexion à un certain nombre de domaines lors du chargement, que les bloqueurs de publicité ou les extensions de confidentialité strictes interceptent parfois. La ligne concernée affiche un point gris et reste dans un état indéterminé, sans que nous ne complétions avec d'autres résultats.