¿Qué es una fuga de WebRTC?
WebRTC es la capacidad de comunicación en tiempo real integrada en el navegador, que se usa para videoconferencias, llamadas de voz, transferencia de archivos P2P y escenarios similares. Para establecer una conexión peer-to-peer, el navegador descubre su propia dirección pública a través de un servidor STUN. Este sondeo suele usar UDP, y los proxies HTTP / SOCKS comunes no siempre interceptan UDP.
Si la solicitud STUN esquiva el proxy y sale directamente desde la red local, un script de la página podría obtener tu IP pública real. Este proceso no suele requerir permiso de cámara ni de micrófono, ni muestra ninguna confirmación adicional; por eso se usa a menudo para comprobar si un proxy cubre de verdad el tráfico de comunicación en tiempo real.
Cómo lo detecta esta herramienta
La página intenta sondeos WebRTC contra varios servidores STUN, recopila las direcciones públicas devueltas y las compara con la IP de salida HTTP. Si la dirección devuelta coincide con la salida actual, es probable que el proxy gestione la ruta UDP; si devuelve una dirección de tu operador local, conviene investigarlo.
- Verificar si UDP pasa por la salida del proxy
- Detectar si IPv4 / IPv6 tienen fugas por separado
- Observar si distintos destinos STUN activan reglas de enrutamiento diferentes
El papel de STUN y UDP
UDP es un protocolo de transporte sin conexión que se usa habitualmente para voz, video, juegos y comunicación en tiempo real. La función de STUN es sencilla: envías un paquete UDP al servidor y el servidor te dice la IP de origen que vio. WebRTC depende de este resultado para negociar la conexión, así que la dirección que ve STUN es la prueba clave para determinar si hay una fuga.
Cómo interpretar los resultados
No se detectaron fugasLa IP pública que devuelve WebRTC coincide con tu salida actual del proxy (en IPv6, el mismo /64). Si no se devuelve ninguna IP pública, la prueba simplemente no obtuvo respuesta; eso no demuestra que no haya riesgo.
Posible fugaWebRTC devolvió una IP pública diferente, y su ubicación, operador o ASN apuntan a tu red local real.
Enrutamiento dividido normalVarios servidores STUN devolvieron salidas de proxy distintas, pero coinciden con el enrutamiento o las reglas que configuraste.
Qué hacer si encuentras una fuga
- Cambia tu cliente proxy al modo TUN para que el UDP de WebRTC también pase por la salida del proxy.
- Chrome / Edge: establece la política empresarial <code>WebRtcIPHandling</code> = <code>disable_non_proxied_udp</code>; Firefox: activa <code>media.peerconnection.ice.proxy_only_if_behind_proxy</code> en <code>about:config</code>. No elimines WebRTC por completo, porque un navegador sin WebRTC ya es identificable por sí mismo.
- Brave: establece la política de gestión de IP de WebRTC en "Deshabilitar UDP sin proxy".
- Si necesitas videoconferencias o llamadas de voz, corrige primero las reglas de enrutamiento de UDP / STUN en tu cliente proxy.
Varias IP de salida no siempre indican una fuga
Si configuraste enrutamiento dividido, distintos servidores STUN pueden salir por nodos diferentes; por ejemplo, el STUN de Google por una salida en EE. UU. y el STUN de Cloudflare por una salida en Hong Kong. Esto no es necesariamente peligroso; lo importante es si coincide con el diseño de tus reglas. Lo que de verdad debes vigilar es que todas las direcciones WebRTC apunten a tu ubicación física o a tu ISP local.
Las fugas de DNS importan igual
Una fuga de WebRTC expone "tu IP real"; una fuga de DNS expone "qué dominios has consultado". Si las solicitudes DNS no pasan por el proxy, tu operador local o el resolutor upstream pueden seguir viendo qué sitios has visitado.
La detección de fugas de DNS de esta página usa una sonda real: CleanIP.io opera un NS autoritativo en Utah, EE. UU. (ns1) y otro en Los Ángeles, EE. UU. (ns2), que sirven la zona dp.cleanip.io. Cada detección resuelve 8 subdominios <uuid>.dp.cleanip.io independientes; estas consultas pasan por el resolutor stub de tu sistema -> ISP / VPN / resolutor recursivo público y llegan finalmente a nuestro NS autoritativo, que registra la IP del resolutor que consulta y (si existe) la subred del cliente (EDNS Client Subnet), y luego te lo devuelve para compararla.
Fíjate en dos señales: ① subred ECS: si el resolutor recursivo reenvió la subred de tu cliente (habitual con Google 8.8.8.8), esa subred es una prueba concluyente de tu identidad como cliente; ② país del resolutor: que los resolutores recursivos públicos (1.1.1.1 / 8.8.8.8) usen anycast entre países es normal; lo importante es si, cuando crees que tienes la VPN activada, la ubicación del resolutor coincide con el país de tu salida HTTP.
Por qué el modo proxy y el modo TUN dan resultados distintos
Los proxies HTTP / SOCKS normalmente solo gestionan TCP, así que el UDP que necesita STUN puede no llegar a enviarse y la página puede mostrar "sin fugas". Esto no significa que UDP pase por el proxy de forma segura; solo significa que UDP nunca llegó al servidor STUN. El modo TUN intercepta tanto TCP como UDP en el adaptador de red virtual, por lo que refleja mejor la ruta real de salida de UDP.
ModoSTUN UDPSignificado del resultado
Proxy HTTP / SOCKSPuede no enviarse"Sin fugas" puede significar solo que UDP estaba bloqueado
TUN / adaptador virtualSe envía realmenteMás adecuado para verificar la salida UDP y las reglas de enrutamiento