Filtraciones WebRTC, explicadas

Te conectas a tu VPN. La barra de estado dice que estás protegido. Cargas un sitio web. El sitio web silenciosamente le pide a tu navegador su dirección IP real — no la IP de la VPN, la real que tu ISP te asignó. Tu navegador la entrega. No ves un prompt, no ves una advertencia, y la VPN está haciendo exactamente lo que prometió.

Esto es una filtración WebRTC. Es culpa del navegador, no de la VPN. Y funciona en cada navegador moderno a menos que la apagues. (Para su modo de falla hermano — donde el mismo tipo de canal lateral te revela vía IPv6 — mira qué es una filtración IPv6.)

Qué es WebRTC realmente

WebRTC (Web Real-Time Communication) es la API del navegador que potencia las llamadas de voz y video en el navegador. Google Meet, canales de voz de Discord, huddles de Slack, Whereby, las partes en navegador de Zoom — todos usan WebRTC. También se usa para transferencias directas de archivos, compartir pantalla y los botones de click-to-call en páginas de soporte al cliente.

Para que las conexiones peer-to-peer funcionen, el navegador necesita conocer tu IP pública. Así es como el otro lado te alcanza. WebRTC maneja esto con un servidor STUN: el navegador le pregunta a un servidor STUN público "¿desde qué dirección estoy viniendo?" El servidor STUN responde con cualquier IP que vea. El navegador cachea eso y lo ofrece a cualquier página que pregunte vía la API WebRTC.

La arquitectura tenía sentido en 2011 cuando WebRTC fue diseñado. Peer-to-peer sensible a latencia era el caso de uso. Privacidad de sitios web arbitrarios no estaba en el tablero de diseño.

Por qué una VPN no lo arregla

La VPN tunelea tu tráfico de red. El intercambio STUN de WebRTC opera por encima de eso, pero la respuesta que el navegador cachea es tu IP real, no la del túnel, en dos casos:

Caso 1: STUN se consultó antes de que la VPN se conectara. El navegador aprendió tu IP real al inicio o en una red anterior. Cacheada. La página le pide a WebRTC las IP y obtiene el valor real cacheado.

Caso 2: La VPN no tunelea UDP al servidor STUN. Algunos setups de VPN tienen casos límite de routing. El paquete STUN escapa del túnel.

Aún con una VPN bien tuneleada, el caché STUN a nivel del navegador es la superficie de ataque. Las páginas no necesitan consultar STUN ellas mismas; sólo le piden a WebRTC las IP que el navegador ya conoce.

Expuesto vs filtrando

La terminología importa porque la respuesta difiere.

Expuesto. No estás en una VPN, visitas una página, la página ve tu IP real. Este es el comportamiento esperado. No es una filtración; es internet funcionando como fue diseñado.

Filtración. SÍ estás en una VPN, la página debería ver sólo la IP de la VPN, pero WebRTC entrega tu IP real de todos modos. Esto es una filtración. La privacidad que pensabas que tenías está rota.

La herramienta de test de filtración WebRTC de Fexyn te muestra en qué caso estás. Con la VPN conectada, la IP pública mostrada debería ser la del servidor Fexyn. Si es tu IP real de casa, estás filtrando.

Lo que un atacante ve de una filtración

Las mismas cosas que verían sin VPN:

Tu dirección IP pública real
Geolocalización gruesa (a nivel de ciudad usualmente, a veces a nivel de barrio para ISP residenciales)
Tu ISP
Un identificador persistente que pueden correlacionar con otras visitas y otros sitios

Peor que sin VPN: la filtración les da tanto tu IP real como tu IP VPN. Pueden correlacionarlas entre sesiones, construir un perfil que te sigue tengas o no la VPN encendida, y usar la IP VPN misma como fingerprint.

Para modelos de amenaza donde la geolocalización importa (periodistas, activistas, cualquiera escondiéndose de un acosador, cualquiera usando una VPN para evitar tracking específico de jurisdicción) una filtración WebRTC deshace la protección silenciosamente.

Soluciones por navegador

La solución vive en el navegador, no en la VPN. Cada navegador maneja WebRTC de manera distinta.

Firefox — desactivación completa

La opción más limpia. Firefox te deja desactivar WebRTC por completo:

Abre una nueva pestaña y navega a about:config. Acepta el prompt de advertencia.
Busca media.peerconnection.enabled.
Ponlo en false.
Reinicia Firefox.

Costo: las videollamadas en cualquier app web dejan de funcionar. Huddles de Slack, Google Meet, voz de Discord en navegador — todas muertas hasta que lo vuelvas a prender. Para la mayoría de usuarios enfocados en privacidad esto es aceptable; las llamadas pasan en la app dedicada.

Brave — toggle integrado

Brave envía un setting enfocado en privacidad:

Abre brave://settings.
Busca "WebRTC".
Pon "WebRTC IP Handling Policy" en Disable non-proxied UDP.

Este es el setting más fuerte que no rompe WebRTC por completo. Las llamadas siguen funcionando; el tráfico STUN está restringido a la ruta del proxy. Para usuarios de Brave en una VPN, este es el setting correcto.

Chrome y Edge — extensión requerida

Ni Chrome ni Edge tienen un toggle de WebRTC integrado en la UI de configuración. Necesitas una extensión. Instala una de:

uBlock Origin con el filtro "Prevent WebRTC from leaking local IP addresses" activado. uBlock Origin es el bloqueador de ads correcto de todas formas; esto es un extra gratis.
WebRTC Network Limiter (publicado por Google directamente). De propósito único, restringe WebRTC a la ruta del proxy.

Evita extensiones aleatorias de una estrella de "WebRTC fix" en la Chrome Web Store. La categoría atrae extensiones de baja calidad y ocasionalmente maliciosas. Quédate con uBlock Origin o la publicada por Google.

Safari

Safari implementa WebRTC pero no expone un toggle. Si estás en Safari y te importan las filtraciones WebRTC, cambia a Brave (basado en Webkit, tiene el toggle) o Firefox (basado en Gecko, desactivación completa).

Cómo lo maneja Fexyn

Fexyn no intenta hacer monkey-patching a tu navegador. El comportamiento de WebRTC del navegador es del lado del navegador y fuera del alcance de lo que una VPN puede o debe sobreescribir.

Lo que hace Fexyn:

Tunelea todo el tráfico UDP, incluido STUN, cuando el protocolo lo permite. WireGuard tunelea todo por defecto. Las configuraciones de VLESS Reality y OpenVPN tunelean UDP por la misma ruta.
Recomienda settings específicos del navegador en la página de soporte.
Provee la herramienta de test de filtración para que puedas verificar tu combinación específica de navegador/setting.

La combinación — tunelear STUN a través de la VPN, más WebRTC del lado del navegador desactivado o restringido — cierra la filtración.

Re-testea después de aplicar la solución

Después de cambiar settings del navegador, reinicia el navegador y corre el test de nuevo en fexyn.com/tools/webrtc-leak-test. La IP pública mostrada debería coincidir con el servidor Fexyn. La IP local o debería estar vacía o debería mostrar sólo la dirección del adaptador del túnel VPN.

Si todavía ves tu IP pública real, el cambio no tomó efecto. Verifica que:

El navegador realmente se reinició (cerrar pestañas no es suficiente; cierra la aplicación)
Para Brave, el setting es "Disable non-proxied UDP", no "Disable non-proxied UDP and force proxy"
Para Chrome/Edge, la extensión está activada, no sólo instalada

Lo que WebRTC no es una filtración sobre

Las filtraciones WebRTC son específicamente sobre tu IP siendo expuesta vía la API del navegador. No:

Afectan apps no-navegador. Una app de escritorio nativa en una VPN no tiene este problema.
Afectan apps móviles que usan su propia red. Las apps iOS/Android que no embeben un webview generalmente no exponen la IP de la VPN vía WebRTC.
Indican que el túnel VPN mismo está roto. El túnel está bien; el navegador está ofreciendo información por encima de la capa del túnel.

Relacionado

Prueba Fexyn gratis 7 días. El túnel hace su parte; las soluciones del navegador son un setting de una sola vez.