Qu'est-ce que mon IP fuit ? Explication des fuites WebRTC, DNS et IPv6

Changer l'adresse qu'un site web voit est la partie facile. La partie difficile est de s'assurer que rien d'autre sur votre machine ne révèle discrètement l'adresse que vous essayiez de cacher. Trois canaux le font le plus souvent, et les trois contournent le proxy ou VPN car ils utilisent un chemin de code différent à l'intérieur de votre système d'exploitation ou de votre navigateur par rapport aux requêtes web ordinaires. Si vous ne testez qu'avec une page "quelle est mon IP" et qu'elle montre l'adresse de sortie, vous avez vérifié la porte d'entrée pendant que trois portes latérales restent ouvertes.

Les trois fuites classiques sont WebRTC, DNS et IPv6. Chacune a une cause différente et une solution différente. Comprendre le mécanisme est important, car un interrupteur de "protection contre les fuites" que vous ne pouvez pas vérifier n'est qu'une promesse.

WebRTC est la technologie de navigateur derrière les appels vidéo en page. Pour connecter deux pairs directement, il doit connaître vos adresses IP candidates, donc il demande à un serveur STUN de les obtenir — et il le fait depuis l'intérieur du navigateur en utilisant UDP, souvent en contournant complètement le proxy. Un script sur n'importe quelle page peut lire ces candidats via l'API RTCPeerConnection sans autorisation, et parmi eux peuvent se trouver votre véritable IP locale et publique.

Les proxies SOCKS5 et HTTP définis au niveau de l'application ne capturent pas ce trafic, c'est pourquoi un navigateur proxy peut toujours fuir. Solutions : désactivez WebRTC là où vous n'en avez pas besoin (dans Firefox, définissez media.peerconnection.enabled sur false ; dans Chromium, utilisez une extension qui force l'UDP proxyé ou désactive l'ICE non proxyé), ou exécutez le navigateur à l'intérieur d'un VPN à tunnel complet afin que même l'UDP de WebRTC passe par le tunnel. Les navigateurs modernes masquent également l'adresse locale derrière un nom d'hôte mDNS .local, ce qui aide mais ne couvre pas toujours le candidat public.

Une fuite DNS se produit lorsque votre appareil résout les noms d'hôtes via le résolveur de votre FAI au lieu de passer par le tunnel. La page se charge via le proxy, mais la recherche qui a transformé example.com en une adresse IP est allée à votre fournisseur — donc votre FAI voit toujours chaque domaine que vous visitez. Avec les proxies, le remède est socks5h:// au lieu de socks5://, ce qui demande au proxy de résoudre à distance ; avec un VPN, le DNS doit être intégré dans le tunnel. Superposer DNS sur HTTPS ou DNS sur TLS le renforce encore.

Une fuite IPv6 est le piège moderne : votre tunnel transporte l'IPv4, mais votre système d'exploitation a toujours une connectivité IPv6 native, donc tout site capable d'IPv6 est atteint directement, exposant votre véritable adresse v6. Soit désactivez l'IPv6 pendant la connexion, soit utilisez un VPN qui route également l'IPv6. Consultez notre guide de test de fuite DNS et proxies IPv6 pour les détails.

Ne jamais supposer ; vérifier. Utilisez les outils de confidentialité s4m et un point de terminaison d'écho d'en-tête pour confirmer ce qu'une destination reçoit réellement, et effectuez un test de fuite WebRTC/DNS/IPv6 dédié avec votre proxy ou VPN actif. Faites-le une fois pour un profil de navigateur et à nouveau chaque fois que vous changez de réseau. Pour des expériences rapides, la liste de proxy gratuite est suffisante, mais rappelez-vous qu'un proxy HTTP ou SOCKS nu ne protège que le trafic qui le traverse — WebRTC et IPv6 sont exactement les parties qui ne le font pas. Lorsque l'étanchéité des fuites dans chaque application est plus importante que le contrôle par application, un VPN en tunnel complet est la réponse la plus complète, et un proxy authentifié avec socks5h gère la moitié DNS proprement.