Skip to content

Test de Fugas WebRTC

En el navegador · consultas a APIs públicas
Última verificación junio 2026 — corre en tu navegador

Test de Fugas WebRTC — Candidatos ICE, Ofuscación mDNS y Detección de Bypass VPN

Las conexiones WebRTC peer se establecen vía ICE (Interactive Connectivity Establishment, RFC 8445 Keränen, Holmberg y Rosenberg, julio 2018), que recopila cuatro tipos de candidatos y los comparte en ofertas SDP: host (IPs de interfaz visibles al SO — incluyendo rangos privados RFC 1918), server-reflexive o srflx (IP pública descubierta consultando un servidor STUN), peer-reflexive (descubierto durante chequeos de conectividad) y relay (asignado por TURN). Incluso con una VPN activa, el navegador puede descubrir y exponer IPs fuera del túnel si la VPN no enlaza el tráfico WebRTC a la interfaz del túnel. Chrome 76+ (por defecto agosto 2019, tras fase experimental Chrome 73 marzo 2019), Firefox 75+ (abril 2020 para ofuscación saliente; Firefox 68 julio 2019 solo añadió manejo de candidatos entrantes) y Safari iOS 12.2+ (marzo 2019) ofuscan los candidatos host con nombres .local mDNS según el trabajo IETF draft-ietf-mmusic-mdns-ice-candidates — UUIDs aleatorios que solo resuelven en la subred local vía mDNS (RFC 6762). Esta herramienta crea una RTCPeerConnection real (W3C WebRTC 1.0), enumera los candidatos ICE como el navegador los expondría en una oferta SDP real, y clasifica cada tipo de candidato para que veas exactamente lo que un peer remoto aprendería sobre tu red.

Relacionado:

Privacidad del Navegador Comprueba la configuración de privacidad, protección contra rastreo y exposición de huella digital Cuál Es Mi IP Consulta tu dirección IP pública, ubicación, ISP y detalles de red Conversor de IP Convierte direcciones IP entre decimal, binario, hexadecimal y octal Test de Fugas WebRTC Comprueba si WebRTC está filtrando tu dirección IP real Búsqueda DNS Consulta registros DNS de cualquier dominio — A, AAAA, MX, CNAME, TXT, NS, SOA Auth de Email Verifica registros SPF, DKIM y DMARC de cualquier dominio

Cómo ejecutar un test de fuga WebRTC

  1. Abre el test en tu navegador — dispara un intercambio real de recopilación de candidatos ICE contra un servidor STUN (sin captura de medios).
  2. Revisa la lista de candidatos: cada entrada muestra tipo (host/srflx/relay), familia IP (4/6) y valor. Las IPs públicas de srflx que no coinciden con tu nodo de salida VPN indican una fuga.
  3. Cambia el estado de conexión VPN y re-ejecuta — los candidatos host deberían cambiar solo a la IP de interfaz del túnel VPN; srflx debería coincidir con la IP pública del exit VPN.
  4. Si tu IP real sigue apareciendo: enlaza WebRTC a una interfaz específica (Firefox `media.peerconnection.ice.default_address_only=true`), o desactiva WebRTC del todo (Firefox `media.peerconnection.enabled=false`).

Casos de uso comunes

  • Validar que una configuración VPN nueva no filtra candidatos host o srflx fuera del túnel — crítico antes de unirse a una videollamada sensible.
  • Confirmar que la ofuscación host mDNS de Chrome 76+ está activa (los candidatos host deberían aparecer como nombres .local, no IPs LAN literales).
  • Auditar un perfil de navegador corporativo por fugas WebRTC antes de desplegarlo a periodistas, activistas o personal remoto en campo.
  • Diagnosticar por qué fallan las sesiones WebRTC peer-to-peer detrás de un NAT estricto — los candidatos relay indican que se necesita fallback TURN.

Preguntas frecuentes

¿Por qué WebRTC filtra mi IP real incluso detrás de una VPN?

ICE (RFC 8445 Keränen/Holmberg/Rosenberg, julio 2018) recopila candidatos de cada interfaz disponible y consulta STUN sobre UDP. Si la VPN no enlaza el tráfico WebRTC a la interfaz del túnel, STUN puede tomar un camino directo, exponiendo la IP pública real. Los candidatos host exponen IPs LAN a menos que estén ofuscados por mDNS.

¿Qué son los candidatos host mDNS y cómo protegen la privacidad?

Chrome 76+ (por defecto agosto 2019), Firefox 75+ (abril 2020 saliente; FF68 julio 2019 solo entrantes), Safari iOS 12.2+ reemplazan IPs host literales (192.168.1.42) con nombres mDNS UUID.local aleatorios según IETF draft-ietf-mmusic-mdns-ice-candidates. Solo resuelve en subred local vía mDNS RFC 6762. Limitación: solo ofusca candidatos host — srflx (IP pública STUN) sigue filtrándose.

¿Cómo desactivo realmente las fugas de IP WebRTC?

Tres opciones: (1) Desactivar del todo — Firefox media.peerconnection.enabled=false, Chromium necesita extensión uBlock Origin. (2) Enlazar a una interfaz — Firefox media.peerconnection.ice.default_address_only=true; algunas VPNs (Mullvad, ProtonVPN) proveen kill switches WebRTC. (3) Kill switch UDP a nivel de sistema en config del cliente VPN.

¿Se guarda el resultado del test en algún sitio?

No. RTCPeerConnection corre localmente en el navegador, los candidatos ICE renderizan de forma síncrona, no se envían datos al servidor, conexión desmontada inmediatamente. Modelo de consentimiento de la WebRTC Security Architecture (RFC 8827 Rescorla, enero 2021) nunca disparado — no se pide acceso a micrófono o cámara.

¿Por qué el test puede mostrar resultados distintos en ejecuciones diferentes?

Tres fuentes de variabilidad: (1) Cambios en interfaz de red (conectar/desconectar VPN, cambio Wi-Fi↔Ethernet, renovación DHCP) cambian candidatos host. (2) Throttling del servidor STUN en hora pico reduce candidatos srflx. (3) Estado de despliegue mDNS — navegadores antiguos (pre-Chrome 76, pre-FF75) muestran IPs literales en vez de nombres .local.

Cómo funcionan las fugas WebRTC — y por qué mDNS solo resuelve parte del problema

Cuando un sitio web llama a `new RTCPeerConnection()` y dispara la recopilación ICE, el navegador se enlaza a todas las interfaces de red disponibles (Wi-Fi, Ethernet, móvil, túnel VPN) y consulta servidores STUN desde cada una. Los cuatro tipos de candidatos definidos en RFC 8445 revelan progresivamente menos sobre la red: los candidatos host listan las IPs literales que el SO ve para cada interfaz; los candidatos srflx muestran la IP pública que cada interfaz presenta al servidor STUN (que puede diferir de la IP host si hay NAT); los candidatos prflx emergen durante chequeos de conectividad; los candidatos relay enrutan a través de TURN sin IP origen visible. La fuga ocurre porque: (1) STUN es UDP, y muchos clientes VPN solo fuerzan TCP por el túnel; (2) los candidatos host exponen IPs privadas RFC 1918 que revelan topología LAN; (3) los candidatos srflx exponen la IP pública de cualquier interfaz que pueda alcanzar STUN, incluyendo la interfaz ISP sin cifrar. El trabajo de Ofuscación mDNS (Borst, Fablet, Uberti y Wang, borrador IETF) reemplaza IPs host literales (192.168.1.42) con nombres .local aleatorios que solo resuelven en la misma subred — pero los candidatos srflx siguen sin verse afectados, así que una consulta STUN que evita la VPN sigue filtrando la IP pública real. La WebRTC Security Architecture (RFC 8827 Rescorla, enero 2021) define el modelo de consentimiento — esta herramienta nunca pide acceso a medios, solo el subconjunto de connectivity-establishment de la API.

  • Enumeración de candidatos ICE según RFC 8445 (tipos host, srflx, prflx, relay)
  • Detección de candidatos IPv4 e IPv6 por separado
  • Clasificación IP pública vs privada (rangos RFC 1918 + RFC 4193 + RFC 6598)
  • Detección de ofuscación mDNS host (Chrome 76+ / Firefox 75+ / Safari iOS 12.2+)
  • Test de alcance STUN (sondea STUN de Google y devuelve la respuesta)
  • Ejecutable por sesión (cambios tras conectar/desconectar VPN visibles inmediatamente)

Gratis. Sin registro. Las tools de navegador (subred, JWT, fuerza de contraseña) corren localmente; las de consulta usan APIs públicas (Cloudflare DoH, RDAP, registros de certs). Detalle por herramienta en /es/methodology/.

Fuentes (7)
  • Alvestrand, H. (2021). Overview: Real-Time Protocols for Browser-Based Applications. RFC 8825, IETF (January 2021 — WebRTC suite overview).
  • Uberti, J., Jennings, C., & Rescorla, E. (Eds.) (2021). JavaScript Session Establishment Protocol (JSEP). RFC 8829, IETF (January 2021 — SDP offer/answer model used by WebRTC).
  • Keränen, A., Holmberg, C., & Rosenberg, J. (2018). Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal. RFC 8445, IETF (July 2018 — Internet Standards Track; obsoletes RFC 5245; defines host/srflx/prflx/relay candidate types).
  • Rescorla, E. (2021). WebRTC Security Architecture. RFC 8827, IETF (January 2021 — companion to RFC 8826 threat model).
  • Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., & Lear, E. (1996). Address Allocation for Private Internets. RFC 1918, IETF (private IPv4 ranges 10/8, 172.16/12, 192.168/16).
  • Borst, J. de, Fablet, Y., Uberti, J., & Wang, Q. (2020). Using Multicast DNS to Protect Privacy When Exposing ICE Candidates. IETF draft-ietf-mmusic-mdns-ice-candidates; default in Chrome 76 (August 2019, after experimental Chrome 73 March 2019), Firefox 75 (April 2020 for outgoing obfuscation; Firefox 68 July 2019 added incoming-candidate handling only), and Safari iOS 12.2+ (March 2019); obfuscates host candidate IPs via .local mDNS hostnames.
  • Cheshire, S., & Krochmal, M. (2013). Multicast DNS. RFC 6762, IETF (February 2013 — link-local name resolution used for .local hostnames).

Son los RFCs del IETF, las publicaciones del NIST y los estándares del W3C que la herramienta implementa o consulta. Localízalos en el IETF Datatracker (datatracker.ietf.org) o en el organismo correspondiente.

Por ·