Realice una prueba de fuga de WebRTC: evite las fugas de IP
Un proxy en funcionamiento no protege automáticamente todas las conexiones del navegador. Use una prueba de fugas de WebRTC para verificar el enrutamiento, evitar la exposición inesperada de la IP y mantener su presencia en la web segura y coherente. Esta es una guía completa que muestra cómo hacerlo.
Qué es WebRTC
WebRTC (Web Real-Time Communication) es un estándar abierto que permite a navegadores y aplicaciones intercambiar audio, vídeo y datos en directo sin plugins. Suele usar UDP para comunicaciones de baja latencia, pero también admite TCP y conexiones basadas en relay.
Para establecer conexiones, WebRTC recopila candidatos ICE (Interactive Connectivity Establishment): posibles puntos de red que contienen una dirección, un puerto y un protocolo de transporte. Estos candidatos son el origen de todas las posibles fugas.
Si el descubrimiento usa una ruta sin protección, estos candidatos pueden exponer una IP ajena a la conexión de proxy o VPN prevista.
Por qué los proxies filtran datos a través de WebRTC
Una fuga de WebRTC se produce cuando el descubrimiento de conectividad del navegador expone una dirección que su configuración de enrutamiento debería ocultar. La prueba de fugas de WebRTC le ayuda a detectarlo.
Una página web inicia la recopilación de candidatos WebRTC.
El navegador contacta con un servidor STUN para descubrir su dirección pública.
Si esa conexión evita su proxy, STUN observa la dirección de su ISP.
El navegador puede exponer esa dirección al JavaScript de la página mediante un candidato ICE.
Tenga en cuenta que:
La configuración de proxy del navegador no siempre cubre el tráfico de WebRTC.
Una VPN de túnel completo bien aplicada debería canalizar este tráfico; WebRTC no anula por sí mismo el cifrado de la VPN.
Por qué las fugas de WebRTC pueden delatarle
Una IP pública expuesta puede revelar su proveedor de red y su ubicación aproximada, pero no su nombre ni su dirección exacta. También puede dar lugar a:
Correlación entre sesiones de navegador que de otro modo serían independientes.
Restricciones basadas en la ubicación.
Verificaciones adicionales o revisión de la cuenta.
Son consecuencias posibles, no resultados garantizados. Aun así, conviene ser prudente y realizar pruebas de fugas de WebRTC con regularidad.
Sea prudente y compruebe siempre las fugas de DNS y las de WebRTC. Lea sobre la seguridad de los proxies y de los datos para saber más.
Diferencia entre las fugas de DNS y las de WebRTC
Las fugas de DNS se refieren al camino que siguen las consultas de dominio; las de WebRTC, a las direcciones que expone el descubrimiento de conectividad. Ninguna prueba sustituye a la otra.
Aspecto | Fuga de DNS | Fuga de WebRTC |
Capa y protocolo | Resolución de nombres del sistema o la aplicación; UDP/TCP 53, DoH, DoT | Conectividad del navegador o la aplicación; ICE, STUN, TURN, normalmente UDP |
Información filtrada | Nombres de dominio consultados; el resolvedor ve el origen de la consulta | Direcciones IPv4/IPv6 locales o públicas |
Quién la obtiene | El resolvedor; observadores de la red si el DNS no está cifrado | Scripts de la página, pares o servidores de descubrimiento |
Riesgo principal | Exposición de la actividad de consulta de dominios | Identificación involuntaria de la red y correlación de sesiones |
Alcance | Todo el sistema, una aplicación concreta o un navegador concreto | Navegadores y aplicaciones con WebRTC activado |
Mecanismo desencadenante | Resolución DNS fuera de la ruta protegida prevista | WebRTC recopila candidatos o comprueba la conectividad |
Una prueba de DNS suele identificar resolvedores recursivos, no la IP pública de su dispositivo. Un resolvedor inesperado merece una investigación; su país por sí solo no demuestra que haya una fuga.
Cómo comprobar las fugas de WebRTC
En esencia, una prueba de fugas de WebRTC consiste en comprobar si su IP real aparece en alguno de los candidatos ICE visibles para el navegador. Pueden ayudar servicios como BrowserLeaks, IPLeak o la herramienta oficial de WebRTC, Trickle ICE, en GitHub.
1. Compruebe su IPv4 e IPv6 reales sin proxy/VPN
Cierre las sesiones de trabajo sensibles antes de desactivar la protección.
Abra IPLeak.
Anote su IPv4 pública directa y la IPv6 si hay alguna disponible.
Mantenga en privado estas direcciones de referencia.
«No se detectó IPv6» significa que la prueba no estableció conectividad IPv6, no que IPv6 no pueda llegar a estar disponible.
2. Inicie su red proxy/VPN y vuelva a comprobar su IP
Conecte su VPN o configure su proxy de CyberYozh App en el perfil de navegador o el cliente previsto.
Abra una pestaña de prueba nueva.
Confirme que la IP pública cambió a la salida esperada.
Compruebe IPv4 e IPv6 por separado.
Que cambie la IP de navegación confirma que la ruta de la conexión ha cambiado, pero aun así puede haber fugas de WebRTC.
3. Abra BrowserLeaks, IPLeak o Trickle ICE de WebRTC
Elija una prueba de fugas de WebRTC online:
BrowserLeaks: revise «Your WebRTC IP» y el registro SDP.
IPLeak: use su prueba combinada de fugas de DNS y WebRTC.
Trickle ICE: un ejemplo del proyecto WebRTC; haga clic en «Gather candidates» y revise las columnas de dirección y tipo. Es un ejemplo de diagnóstico, no una certificación de privacidad exhaustiva.
4. Compruebe si su IP física aparece en los resultados
Compare los resultados de la prueba de fugas de WebRTC con su referencia:
Aparece la IP pública directa del ISP: investigue una fuga de IP.
Aparece la salida esperada del proxy/VPN: es coherente con un enrutamiento protegido.
192.168.x.x o 10.x.x.x: información de red privada, no su identidad pública.
Un nombre de host .local: ofuscación de la dirección local, no prueba de que la IP pública esté protegida.
Si no hay candidatos o aparece un error, el resultado no es concluyente. Repita la prueba con otra herramienta tras reconectar. Si ninguna de estas herramientas muestra fugas, está a salvo. Para saber cómo evitar las fugas, siga leyendo.
Cómo evitar las fugas de WebRTC
Desactive WebRTC cuando no sea necesario, o aplique un enrutamiento protegido cuando las llamadas y las aplicaciones en tiempo real deban seguir funcionando. Bloquear el UDP sin proxy ayuda, pero no sustituye a la prueba de fugas de WebRTC para entender qué está pasando.
Descubra cómo evitar que su IP de proxy sea baneada, incluida la prevención de fugas de IP y otros métodos.
En navegadores convencionales
Use la guía de configuración del navegador correspondiente y aplique después el control adecuado:
Firefox de escritorio: about:config → media.peerconnection.enabled → false. Esto desactiva WebRTC.
Chrome: use una extensión de privacidad mantenida que admita disable_non_proxied_udp.
Brave: busque «WebRTC IP Handling Policy» en Ajustes y elija «Disable Non-Proxied UDP».
Microsoft Edge: use una extensión de privacidad de WebRTC compatible o una política administrada; repita la prueba.
Safari: use un enrutamiento VPN forzado a nivel de dispositivo; no se fíe de las antiguas instrucciones del menú experimental.
Opera: seleccione el bloqueo de UDP sin proxy donde esté disponible, o use una extensión compatible y mantenida.
En navegadores antidetect
Siga las instrucciones del navegador antidetect.
Asigne el proxy al perfil y revise después sus ajustes de WebRTC. Elija el modo desactivado si no es necesario; en caso contrario, use la opción de enrutamiento protegido del fabricante.
Etiquetas como «Altered» varían según el producto: que se modifiquen los candidatos mostrados no demuestra por sí solo que el tráfico de red esté protegido.
Pruebe cada perfil después.
En clientes proxy
Siga las instrucciones del cliente proxy. Después:
Importe sus credenciales de CyberYozh.
Active el modo TUN/enrutamiento completo cuando sea compatible.
Verifique la compatibilidad con UDP en el upstream.
Dirija el DNS por la ruta prevista
Desactive el fallback directo no deseado.
El modo de proxy del sistema por sí solo no equivale a un túnel para todo el dispositivo. Después, vuelva a comprobar la configuración real del navegador en busca de fugas de WebRTC.
Configuración del firewall del sistema
Consulte la guía de ajustes del sistema operativo correspondiente.
Use un kill switch de VPN en los ajustes de su Wi-Fi o añada reglas de salida que limiten las aplicaciones protegidas al túnel o al cliente proxy. Cubra tanto IPv4 como IPv6. Así se bloqueará todo el tráfico directo (sin proxy), lo que reduce el riesgo de fugas de WebRTC.
Buenas prácticas para trabajar con fugas de WebRTC
Pruebe el perfil de trabajo exacto, no solo su navegador predeterminado; los permisos del navegador, las extensiones, las asignaciones de proxy y las reglas de enrutamiento pueden diferir de un entorno a otro.
Repita las comprobaciones tras actualizar el navegador, cambiar de cliente, cambiar de red y reconectar; una prueba satisfactoria valida una configuración concreta, no todos los estados futuros posibles.
Verifique el DNS y el IPv6 por separado; desactivar WebRTC no corrige un enrutamiento de resolvedor ajeno al problema ni impide que las conexiones normales eludan su ruta de red protegida.
Pruebe el comportamiento ante fallos antes de trabajar en producción: desconecte el túnel y confirme que las aplicaciones protegidas dejan de conectarse en lugar de recurrir en silencio al acceso directo.
Conserve la funcionalidad necesaria: pruebe las llamadas y el uso compartido de pantalla tras aplicar las restricciones y documente después la configuración que funciona, sin guardar contraseñas de proxy ni compartir públicamente las direcciones de referencia.