Qu'est-ce qu'une fuite WebRTC ?
WebRTC est la fonction de communication en temps réel intégrée au navigateur, utilisée pour la visioconférence, les appels vocaux, le transfert de fichiers P2P, etc. Pour établir une connexion pair à pair, le navigateur découvre, via un serveur STUN, l'adresse sous laquelle il apparaît côté Internet. Ce sondage passe généralement par UDP, et les proxys HTTP / SOCKS ordinaires ne prennent pas forcément en charge l'UDP.
Si la requête STUN contourne le proxy et part directement du réseau local, un script de la page peut obtenir votre IP publique réelle. Ce processus ne requiert généralement aucune autorisation d'accès à la caméra ou au micro et ne déclenche aucune demande de confirmation supplémentaire ; c'est pourquoi on l'utilise couramment pour vérifier si un proxy couvre réellement le trafic de communication en temps réel.
Comment cet outil détecte les fuites
La page lance des sondages WebRTC auprès de plusieurs serveurs STUN, recueille les adresses publiques renvoyées et les compare à l'IP de sortie HTTP. Si l'adresse renvoyée correspond à la sortie actuelle, le chemin UDP est probablement pris en charge par le proxy ; si c'est une adresse de votre opérateur local, cela mérite un examen approfondi.
- Vérifier si l'UDP passe par la sortie du proxy
- Détecter si IPv4 et IPv6 présentent chacun une fuite
- Observer si différentes cibles STUN relèvent de règles de routage différentes
Le rôle de STUN et d'UDP
UDP est un protocole de transport sans connexion, couramment utilisé pour la voix, la vidéo, les jeux et la communication en temps réel. Le rôle de STUN est simple : vous envoyez un paquet UDP au serveur, qui vous indique l'IP source qu'il a vue. WebRTC s'appuie sur ce résultat pour négocier la connexion ; l'adresse vue par STUN est donc l'élément déterminant pour juger d'une fuite.
Comment interpréter les résultats
Aucune fuite détectéeL'IP publique renvoyée par WebRTC correspond à la sortie actuelle de votre proxy (pour IPv6, le même /64). Si aucune IP publique n'est renvoyée, le test n'a simplement pas obtenu de réponse ; ce n'est pas une preuve de sécurité.
Fuite suspectéeWebRTC a renvoyé une autre IP publique, dont la localisation, l'opérateur ou l'ASN désigne votre véritable réseau local.
Routage par règles normalPlusieurs serveurs STUN ont renvoyé des sorties de proxy différentes, mais ces sorties correspondent au routage ou aux règles que vous avez configurés.
Que faire en cas de fuite
- Passez votre client proxy en mode TUN pour que l'UDP de WebRTC passe aussi par la sortie du proxy.
- Chrome / Edge : réglez la stratégie d'entreprise <code>WebRtcIPHandling</code> = <code>disable_non_proxied_udp</code> ; Firefox : activez <code>media.peerconnection.ice.proxy_only_if_behind_proxy</code> dans <code>about:config</code>. Ne supprimez pas complètement WebRTC : un navigateur sans WebRTC est lui-même identifiable.
- Brave : dans Paramètres > Confidentialité et sécurité, réglez la gestion des IP WebRTC sur « Disable non-proxied UDP ».
- Si vous avez besoin de visioconférence ou d'appels vocaux, corrigez d'abord les règles de routage UDP / STUN dans votre client proxy.
Plusieurs IP de sortie ne signifient pas forcément une fuite
Si vous avez configuré un routage par règles, différents serveurs STUN peuvent passer par différents nœuds — par exemple le STUN de Google via une sortie aux États-Unis, celui de Cloudflare via une sortie à Hong Kong. Ce n'est pas forcément dangereux ; l'essentiel est que cela corresponde à la conception de vos règles. Ce qui doit vraiment vous alerter, c'est que toutes les adresses WebRTC pointent vers votre localisation physique ou votre FAI local.
Les fuites DNS comptent tout autant
Une fuite WebRTC expose « votre IP réelle » ; une fuite DNS expose « les domaines que vous avez interrogés ». Si les requêtes DNS ne passent pas par le proxy, votre opérateur local ou le résolveur amont peut toujours voir les sites que vous visitez.
Le test de fuite DNS de cette page repose sur une vraie sonde : CleanIP.io exploite un NS faisant autorité dans l'Utah, aux États-Unis (ns1), et un autre à Los Angeles, aux États-Unis (ns2), qui servent la zone dp.cleanip.io. À chaque test, le navigateur résout 8 sous-domaines <uuid>.dp.cleanip.io indépendants ; ces requêtes passent par le résolveur local (stub resolver) de votre système -> FAI / VPN / résolveur récursif public, pour aboutir à notre NS faisant autorité, qui enregistre l'IP du résolveur à l'origine de la requête et (le cas échéant) l'EDNS Client Subnet, puis vous les renvoie pour comparaison.
Concentrez-vous sur deux signaux : ① sous-réseau ECS — si le résolveur récursif a transmis votre sous-réseau client (fréquent avec Google 8.8.8.8), ce sous-réseau révèle sans ambiguïté votre identité de client ; ② pays du résolveur — l'anycast transfrontalier des résolveurs récursifs publics (1.1.1.1 / 8.8.8.8) est normal ; ce qui compte, c'est de savoir si, alors que vous pensez votre VPN actif, la localisation du résolveur correspond au pays de votre sortie HTTP.
Pourquoi le mode proxy et le mode TUN donnent des résultats différents
Les proxys HTTP / SOCKS ne gèrent généralement que le TCP ; l'UDP nécessaire à STUN peut donc ne pas partir, et la page peut afficher « aucune fuite ». Cela ne veut pas dire que l'UDP passe de manière sûre par le proxy, mais seulement qu'il n'a jamais atteint le serveur STUN. Le mode TUN intercepte à la fois TCP et UDP sur l'adaptateur réseau virtuel ; il reflète donc mieux le véritable chemin de sortie UDP.
ModeSTUN UDPSignification
Proxy HTTP / SOCKSEnvoi parfois impossible« Aucune fuite » peut simplement signifier que l'UDP est bloqué
TUN / adaptateur virtuelEnvoi effectifMieux adapté pour vérifier la sortie UDP et les règles de routage