ESUna Fuga de WebRTC ocurre cuando un navegador expone información de dirección de red que esperaba que ocultara una VPN, un proxy o una configuración de privacidad. El ejemplo más claro es la IP pública de su ISP que aparece en lugar de la IP VPN o proxy que planeaba usar.
WebRTC en sí no es una característica dañina. Admite videollamadas, chat de voz, uso compartido de pantalla y datos en tiempo real en el navegador. El problema de privacidad surge de la forma en que busca una ruta de red que funcione.
En términos simples, una Fuga de WebRTC significa que el navegador revela una dirección inesperada mientras prepara una conexión en tiempo real.
¿Qué es una Fuga de WebRTC?
La palabra fuga necesita contexto. Un sitio web normalmente ve la IP pública utilizada para cargar la página. Una prueba WebRTC también puede mostrar esa misma dirección. Si ambos resultados apuntan a la VPN o proxy que seleccionó, es posible que no haya ninguna fuga.
El problema comienza cuando WebRTC revela una dirección fuera de esa ruta esperada. Es posible que vea la IP de la VPN en una verificación de IP normal y luego encuentre la IP de su ISP local en el resultado de WebRTC. También puede encontrar una dirección IPv6 expuesta que la primera prueba omitió.
No trato cada línea de un verificador de fugas como una falla. Busco una dirección que la configuración actual debía ocultar.
Cuando la exposición a la propiedad intelectual se convierte en una fuga
Supongamos que su dirección ISP normal está en Londres. Te conectas a un proxy en Nueva York. Un verificador de IP estándar ahora muestra el proxy de Nueva York. Esa parte funciona como se esperaba.
Luego ejecuta una prueba WebRTC. Si también muestra la dirección de Nueva York, las señales de la red están de acuerdo. Si también muestra la dirección original del ISP de Londres, el navegador ha expuesto una ruta inesperada.
La misma lógica se aplica a una VPN. También se aplica a IPv6. Una ruta IPv4 protegida no ayuda mucho si una dirección IPv6 separada todavía apunta a la red original.
Por qué WebRTC necesita direcciones de red
La comunicación en tiempo real necesita una ruta entre dos puntos finales. Ese camino puede ser directo. Puede pasar a través de un dispositivo NAT. Es posible que necesite un relé cuando no se pueda establecer una conexión directa.
WebRTC recopila posibles rutas para poder elegir una que funcione. Esto ayuda a que las llamadas comiencen más rápido y reduce la demora. También significa que una aplicación web puede aprender más sobre la red que a través de una solicitud de página normal.
Este proceso es independiente del acceso a la cámara y al micrófono. Una página puede crear una conexión entre pares o un canal de datos y comenzar a recopilar candidatos para la conexión. El acceso a dispositivos multimedia aún necesita el permiso correspondiente del navegador.
¿Cómo ocurre una Fuga de WebRTC?
El proceso comienza con RTCPeerConnection. Una aplicación web crea este objeto cuando necesita una conexión en tiempo real. Luego, el navegador utiliza el Establecimiento de conectividad interactiva, generalmente llamado ICE, para recopilar posibles candidatos de conexión.
Esos candidatos describen formas en que podría funcionar la conexión. La aplicación web puede leer la información del candidato y compartirla con el lado remoto a través de su sistema de señalización.
Si el navegador incluye una dirección de ISP que debería haber permanecido detrás de una VPN o un proxy, es posible que la aplicación la vea. Esto puede suceder con un túnel dividido, una interfaz de red adicional, una ruta IPv6 desprotegida o un proxy de navegador que aún permite que WebRTC se conecte fuera de la ruta esperada.
Reunión de candidatos de ICE
El flujo tiene cinco pasos:
- Una página crea
RTCPeerConnection. - El agente de ICE verifica las rutas de conexión disponibles.
- El navegador recopila candidatos de retransmisión de host, derivados de STUN o TURN.
- La aplicación recibe los candidatos que se le permite ver.
- ICE prueba los pares candidatos y selecciona una ruta de trabajo.
ICE no es un servidor. Es el proceso utilizado para buscar y probar opciones de conexión. STUN y TURN apoyan ese proceso de diferentes maneras.
Candidatos anfitriones, STUN y TURN
Cada tipo de candidato revela una parte diferente de la conexión.
| Tipo de candidato | de donde viene | Lo que puede revelar |
|---|---|---|
| Anfitrión | Una interfaz de red local | Una IP local o un nombre mDNS |
| Reflexivo del servidor | Un discurso público aprendido a través de STUN | La IP pública utilizada para llegar al servidor STUN |
| Relé | Una dirección proporcionada por un servidor TURN | La dirección del servidor de retransmisión en lugar de una dirección de punto final directo |
Un relé TURN puede mantener las direcciones de los puntos finales directos alejadas del par remoto. También agrega otro servidor a la ruta. Esto puede aumentar el retraso, el costo del ancho de banda y la dependencia operativa del relé.
Cuando una VPN o un proxy exponen una ruta inesperada
Las VPN y los servidores proxy no deben considerarse la misma herramienta. Una VPN de túnel completo puede enrutar un amplio tráfico de dispositivos y utilizar reglas de firewall para detener el tráfico fuera del túnel. Una VPN de túnel dividido permite que el tráfico seleccionado utilice otra ruta.
Un proxy de navegador a menudo maneja solicitudes web para un navegador o perfil. Es posible que no controle todas las rutas WebRTC. SOCKS5 puede admitir UDP, pero el enrutamiento WebRTC real aún depende del navegador y su configuración.
Proxies, VPN y navegadores antidetección controlan diferentes capas. Un proxy enruta el tráfico seleccionado. Una VPN puede gestionar un túnel cifrado más amplio. Un Navegador antidetección administra los perfiles del navegador y las señales del lado del navegador. Uno no reemplaza automáticamente a los demás.
¿Qué información puede exponer WebRTC?
La mayoría de las páginas de prueba muestran más de un campo. Las etiquetas pueden parecer alarmantes, especialmente cuando las direcciones locales y públicas aparecen juntas. Es útil juzgar cada tipo por sí solo.
Direcciones IP públicas
Una IP pública es visible en Internet. Puede indicar un ISP, un ASN, una ubicación amplia y el tipo de red en uso.
Cuando una VPN o un proxy están activos, la advertencia más importante es la aparición de la IP pública del ISP de referencia. Puede ser una dirección IPv4, una dirección IPv6 o ambas.
Una Dirección IP normalmente no revela una dirección particular exacta por sí sola. Sigue siendo información de red útil. También puede entrar en conflicto con la ubicación y el proveedor que se muestran en la IP de salida esperada.
Direcciones IP locales y nombres mDNS
Las direcciones locales suelen comenzar con rangos como 192.168 o 10. Estas direcciones se reutilizan en muchas redes privadas. Una IP local suele ser menos reveladora que una dirección de ISP pública.
Esto no significa que la información local carezca de sentido. Puede revelar parte del diseño de una red. Una combinación estable de interfaces locales también puede agregar otra señal cuando se comparan sesiones.
Los navegadores modernos a menudo ocultan una dirección de host local detrás de un nombre mDNS .local aleatorio. Ver ese nombre no significa que la IP pública de su ISP se haya filtrado. Significa que el navegador evita la exposición directa de la dirección local. Tampoco elimina todas las señales WebRTC posibles.
IPv6 y múltiples interfaces de red
Mucha gente comprueba IPv4 y se queda ahí. Eso es fácil de entender. IPv4 sigue siendo la dirección que la mayoría de los usuarios reconocen.
IPv6 necesita su propio control. Una VPN puede manejar IPv4 correctamente mientras que otra configuración deja IPv6 visible. Wi-Fi, Ethernet, adaptadores virtuales e interfaces VPN también pueden crear varios candidatos.
Los resultados varían según el navegador, el sistema operativo, la red y la política de privacidad. Una prueba en vivo de la configuración que utiliza le brinda más información que una lista general de navegadores.
Cómo probar una Fuga de WebRTC
Una prueba limpia comienza con una línea de base. Sin él, es posible que vea varias direcciones y no tenga una forma confiable de saber cuál pertenece a la conexión original.
Prueba de Fuga de WebRTC paso a paso
- Desconecta la VPN o el proxy.
- Registre las direcciones IPv4 e IPv6 públicas actuales.
- Cierra la página de prueba.
- Conecte la VPN o el proxy, o inicie el perfil del navegador que desea verificar.
- Utilice un verificador de IP normal para confirmar la IP de salida esperada.
- Abra un verificador específico de WebRTC.
- Compare los resultados públicos, locales, mDNS, IPv6 y de retransmisión con la línea de base.
- Cambie la configuración relevante y pruebe nuevamente si aparece la dirección ISP original.
Los controles del navegador cambian con el tiempo. Una Fuga de WebRTC cuidadosa importa más que una lista antigua de configuraciones supuestamente seguras.
Cómo leer los resultados de la prueba
| Resultado de la prueba | Interpretación general |
|---|---|
| La IP pública de WebRTC coincide con la VPN o la IP del proxy | El resultado suele seguir la ruta esperada. |
| Aparece la IP pública del ISP de referencia | Hay una Fuga de WebRTC importante |
Aparece un nombre .local aleatorio | La dirección del host local se oculta a través de mDNS |
| Sólo aparece una dirección de relé TURN | La conexión está utilizando un candidato de retransmisión. |
| WebRTC no está disponible | WebRTC está deshabilitado o restringido, por lo que las funciones relacionadas pueden fallar |
Una prueba de BrowserLeaks de MoreLogin comprobó la IP, WebRTC, la zona horaria, el idioma, Canvas, WebGL y las fuentes en el mismo perfil.
Fue una prueba en una configuración. No debe leerse como una promesa para cada versión de navegador, dispositivo, proxy o perfil.
Por qué un resultado marcado en verde no es una garantía permanente
Un resultado marcado en verde resulta tranquilizador. Todavía no lo trataría como un certificado que nunca caduca.
Pruebe nuevamente después de cualquier cambio que pueda afectar el navegador o la red:
- Una actualización del navegador
- Un nuevo servidor VPN o proxy
- Un cambio de extensión
- Una nueva red
- IPv6 estando habilitado
- Un nuevo perfil de navegador
- Una política WebRTC diferente
Una prueba de fugas es una instantánea de un navegador, una red y una configuración. Eso es suficiente para tomar una decisión útil. No es una garantía de privacidad permanente.
Cómo prevenir o reparar una Fuga de WebRTC
No existe una solución única que se adapte a todos los navegadores y a todos los flujos de trabajo. La elección correcta depende de si las funciones WebRTC deben permanecer disponibles.
Utilice una VPN con protección contra fugas probada
Una VPN a nivel de sistema puede proteger el tráfico WebRTC mediante reglas de enrutamiento y firewall. Compruebe si el túnel dividido está activo. Verifique IPv6 también. Luego ejecute la prueba en lugar de confiar en el estado de conexión en la aplicación.
La marca de VPN importa menos que el resultado observado en el dispositivo y navegador que realmente utilizas.
Restrinja el tráfico no proxy o utilice WebRTC de solo retransmisión
Otra opción es impedir que WebRTC utilice una ruta fuera del proxy. Algunos controles bloquean UDP no proxy. Otros fuerzan el tráfico a través del proxy configurado.
Si UDP no puede usar esa ruta, WebRTC puede recurrir a TCP o TURN. También puede fallar. El resultado depende de la implementación.
WebRTC de solo retransmisión utiliza candidatos TURN. Puede mantener a los candidatos directos alejados del par remoto mientras mantiene la comunicación en tiempo real. La compensación es una mayor latencia, más tráfico de retransmisión y una mayor dependencia de la disponibilidad de TURN.
Cambiar la configuración del navegador o usar una extensión
Firefox ofrece preferencias avanzadas que pueden limitar o deshabilitar WebRTC. Los navegadores basados en Chromium a menudo dependen de extensiones, políticas empresariales o controles de red a nivel del navegador.
Las extensiones pueden ayudar. Ellos también necesitan cuidados. Una extensión desactualizada puede dejar de funcionar después de una actualización del navegador. Puede solicitar permisos amplios. También puede comportarse de manera diferente según las versiones del navegador.
Si usa una, elija una fuente mantenida y pruebe el resultado nuevamente. El icono en la barra de herramientas no es la evidencia. El resultado de la red es.
Utilice controles WebRTC por perfil
Las configuraciones globales se vuelven incómodas cuando varios perfiles usan diferentes servidores proxy o ubicaciones de red. Cada perfil necesita una asignación de proxy clara y una política WebRTC que se ajuste a la tarea.
Un perfil no está listo sólo porque su proxy se conecta. Una vez que configurar servidores proxy en MoreLogin, confirme la IP visible y ejecute una verificación WebRTC por separado.
MoreLogin documentación API del perfil del navegador enumera Privacidad, Reemplazo, Real, Deshabilitado y Reenvío como opciones WebRTC por perfil. No explica completamente cómo cada modo maneja los candidatos de host, STUN, TURN, UDP, IPv4 e IPv6.
La etiqueta de modo por sí sola no es suficiente. Verifique el comportamiento seleccionado en la versión actual del producto.
¿Debería desactivar WebRTC?
Deshabilitar WebRTC puede cerrar esta ruta de exposición de direcciones. También es la opción que más probablemente afecte las funciones normales del navegador.
Lo que evita deshabilitar WebRTC
Cuando RTCPeerConnection no está disponible, una página no puede usar esa API para reunir los mismos candidatos de conexión. Esto puede evitar una fuga de IP basada en WebRTC.
No detiene las fugas de DNS. No oculta la huella digital del navegador. No elimina cookies ni datos de cuenta.
¿Qué puede dejar de funcionar?
Los sitios pueden perder funciones que dependen de WebRTC, que incluyen:
- Videollamadas desde navegador
- chat de voz
- Compartir pantalla
- Transferencia de archivos de igual a igual
- Widgets de colaboración y soporte en tiempo real
Algunos servicios pueden ofrecer otra ruta. Otros pueden fallar o perder calidad.
Deshabilitar, restringir o retransmitir
| Método | Funcionalidad WebRTC | control de privacidad | Principal compensación |
|---|---|---|---|
| Desactivar | Generalmente no disponible | Fuerte contra esta vía de fuga | Compatibilidad más baja |
| Restringir o forzar el proxy | A menudo permanece disponible | Depende de la implementación | Necesita una configuración cuidadosa y una nueva prueba. |
| Sólo retransmisión | Permanece disponible a través de TURN | Evita candidatos directos | Agrega latencia, costo y dependencia de retransmisión |
Deshabilite WebRTC cuando el perfil no necesite comunicación en tiempo real. Restringirlo o retransmitirlo cuando la función deba permanecer disponible y se pueda verificar la ruta de la red.
Fuga de WebRTC frente a fuga de DNS
Las filtraciones de WebRTC y DNS son fáciles de confundir porque ambas pueden debilitar la configuración de privacidad. Exponen información diferente.
| Fuga de WebRTC | fuga de DNS |
|---|---|
| Expone direcciones de red inesperadas a través de candidatos de ICE | Envía consultas de DNS a un solucionador inesperado |
| Comprobado con una prueba específica de WebRTC | Comprobado con una Prueba de fuga de DNS |
| Se corrigió a través de la política WebRTC, enrutamiento, proxy, control UDP o TURN. | Se corrigió a través de configuración de enrutamiento DNS, resolución y VPN. |
Ambas cosas pueden suceder al mismo tiempo. Arreglar uno no prueba que el otro haya desaparecido.
Fugas de WebRTC y perfiles de navegador aislados
La identidad de la red y la identidad del navegador se encuentran en diferentes capas. Esta distinción adquiere importancia cuando los perfiles se reutilizan con el tiempo.
Un proxy o VPN controla la ruta de la red. Una política WebRTC controla cómo se exponen o retransmiten los candidatos de conexión. Un perfil de navegador contiene cookies, almacenamiento local, configuraciones del navegador y otras señales.
La información WebRTC puede formar parte de una huella digital del navegador más amplia, junto con la versión del navegador, la zona horaria, las fuentes, la salida de Canvas y el comportamiento de WebGL.
Mantenga consistentes las señales de red de cada perfil
Antes de utilizar un perfil, verifique las partes que deben coincidir:
- La IP pública de proxy o VPN esperada
- La IP pública de WebRTC
- Exposición a IPv6
- Comportamiento de IP local o mDNS
- Zona horaria y geolocalización
- Idioma del navegador
La coherencia no hace que un perfil sea invisible. Reduce los desajustes evitables y facilita el diagnóstico de los problemas.
Verifique el perfil antes de realizar trabajos importantes.
Es tentador detenerse cuando la verificación normal de IP parece correcta. Encontrar una fuga días después es frustrante y más difícil de desenredar.
En MoreLogin, un perfil de navegador de múltiples cuentas mantiene la configuración del proxy, la configuración de WebRTC, las cookies, el almacenamiento y otras señales del navegador en un entorno reutilizable. Eso hace que la configuración sea más fácil de revisar. El resultado aún depende de la configuración, la red y el proxy seleccionados.
Pruebe un nuevo perfil antes de usarlo. Pruebe nuevamente cuando cambie el proxy, la versión del navegador o la política WebRTC.
Conclusiones clave
- Una Fuga de WebRTC es una exposición inesperada de una dirección de red, no la aparición de ninguna IP en una prueba.
- ICE puede recopilar candidatos de retransmisión de host, derivados de STUN y TURN.
- Una prueba útil compara la IP básica del ISP con el resultado de la VPN, el proxy o el perfil.
- La desactivación, restricción, proxy y WebRTC de solo retransmisión tienen diferentes compensaciones en materia de privacidad y compatibilidad.
Preguntas frecuentes sobre Fuga de WebRTC
¿WebRTC siempre filtra su Dirección IP real?
No. El resultado depende del navegador, la red, la ruta VPN o proxy, la configuración de IPv6 y la política WebRTC. Una configuración enrutada correctamente puede mostrar solo la VPN o la IP del proxy. Una configuración de solo retransmisión puede mostrar una dirección TURN.
¿Puede WebRTC omitir una VPN o un proxy?
Puede exponer una dirección adicional cuando al navegador se le permite utilizar otra ruta de red. Un túnel dividido, una ruta IPv6 desprotegida o un proxy de navegador que no controla el tráfico WebRTC pueden contribuir a este resultado.
¿Es una Dirección IP local una Fuga de WebRTC?
Es la exposición de información de la red local. Suele ser menos directo que revelar la IP pública de un ISP. Su valor depende de la dirección, su estabilidad, las otras interfaces presentes y la forma en que se combina la información.
¿Qué significa una dirección .local en una prueba WebRTC?
Una dirección aleatoria .local suele ser un nombre de host mDNS. Los navegadores modernos lo utilizan para evitar mostrar directamente la IP del host local. Esto no significa que se haya filtrado la IP pública del ISP.
¿Puede un sitio web verificar WebRTC sin el permiso de la cámara?
Una página puede crear una conexión entre pares o un canal de datos y desencadenar la recopilación de candidatos de ICE. El acceso a la cámara y al micrófono aún requiere el permiso de medios correspondiente.
¿Desactivar WebRTC dañará los sitios web?
Puede afectar las videollamadas, el chat de voz, el uso compartido de pantalla, la transferencia de archivos y otras funciones en tiempo real. Algunos sitios pueden ofrecer una alternativa. Otros pueden perder la función o trabajar con calidad reducida.
¿Con qué frecuencia debo realizar pruebas para detectar fugas de WebRTC?
Pruebe después de cambiar el navegador, VPN, proxy, extensión, red, configuración de IPv6, perfil del navegador o política WebRTC. Una nueva prueba rápida puede detectar una ruta que cambió sin una advertencia obvia.
Mantenga organizadas las configuraciones de WebRTC y Proxy
La protección WebRTC funciona mejor cuando se trata como parte de toda la configuración del perfil. El proxy, la IP visible, la ruta IPv6, la zona horaria, el idioma y la política WebRTC deberían tener sentido juntos.
Pruebe MoreLogin gratis para crear perfiles de navegador reutilizables, configurar la red y el navegador por separado y verificar cada entorno antes de usarlo.
