Un proxy puede cubrir el tráfico HTTP mientras WebRTC intercambia direcciones candidatas mediante STUN/ICE sobre UDP. Este artículo explica cuándo pueden exponerse direcciones locales y privadas y cómo mantener coherentes la salida de red y el entorno del navegador.
Ya has configurado el proxy y una página de consulta de IP muestra la región y el proveedor esperados. La identidad de red parece estar en orden. Sin embargo, al abrir una prueba de fugas, la sección de WebRTC aparece en rojo y muestra la dirección de tu conexión real con el proveedor de Internet.
No hace falta cambiar de proxy de inmediato. En la mayoría de los casos, el problema no está en la calidad del proxy, sino en tráfico que queda fuera de su alcance.
El proxy gestiona HTTP, mientras WebRTC toma otra ruta
Un proxy trabaja en la capa de red. Ya sea una extensión del navegador o un túnel a nivel del sistema, procesa solicitudes HTTP/HTTPS y envía ese tráfico a través de la salida del proxy.
WebRTC funciona de otra manera. Es una capacidad de comunicación en tiempo real integrada en el navegador. Para que las llamadas de audio y vídeo y las transferencias P2P encuentren una ruta adecuada, puede enviar consultas STUN a servidores externos, en esencia preguntando «¿qué dirección ves de mí?», y después organizar las respuestas como candidatos ICE para la página web. Estas consultas usan UDP, un canal independiente del túnel HTTP.
Así aparece la discrepancia: las solicitudes web salen por el proxy, mientras el navegador también puede informar de una dirección local. Suponer que configurar un proxy equivale a dejar completamente limpia la identidad de red es el punto de partida más habitual de este problema.
No solo puede exponerse la IP pública
Los candidatos ICE suelen incluir dos tipos de direcciones. Una es la dirección pública, es decir, la salida de tu proveedor de Internet real. La otra es una dirección local, por ejemplo una dirección privada que empieza por 192.168, y en ocasiones también una dirección de un adaptador de red virtual.
Una dirección de red privada, por sí sola, no demuestra gran cosa: prácticamente cualquier ordenador tiene una. Pero puede ser lo bastante estable como para que la repetición de candidatos coincidentes entre varias cuentas proporcione a una plataforma otra señal para asociarlas con el mismo dispositivo. La dirección pública es más directa: apunta al proveedor real y a una zona geográfica aproximada. El nivel de precisión depende de la plataforma, pero la idea es clara: cuanto más auténtica sea la dirección, más sencilla resulta la asociación.
¿Cuándo puede leerla realmente un sitio web?
No todos los sitios intentan hacerlo. El intercambio de direcciones requiere que la página cree activamente un objeto RTCPeerConnection, algo que las páginas de contenido ordinarias normalmente no necesitan.
Suelen hacerlo varios tipos de servicios: sitios que necesitan comunicación en tiempo real, como videoconferencias, atención al cliente en línea y algunas páginas de streaming; sitios cuyo negocio depende en gran medida de la publicidad o de la prevención del fraude; y plataformas con sistemas de control de riesgo más completos. La lectura ocurre fuera de lo que se ve en la interfaz y, una vez recopilados los datos, normalmente no se te informa de cómo se utilizarán.
También existe un caso que no depende del sitio web. Durante el breve intervalo en que el proxy se reconecta o cambia de nodo, una solicitud STUN del navegador puede terminar saliendo por la red local. La ventana es corta, pero basta para que se registre una observación.
Tres situaciones comunes en las que falla
Los proxies en forma de extensión del navegador suelen tomar el control únicamente de las solicitudes HTTP/HTTPS. UDP queda fuera de su alcance, y marcar una opción «global» en la interfaz no cambia ese hecho.
Un proxy global a nivel del sistema parece más completo porque cubre el tráfico de todo el dispositivo. Sin embargo, la recopilación de direcciones candidatas puede vincularse directamente a una interfaz de red local y saltarse la tabla de enrutamiento del sistema, dejando una brecha en el túnel en ese punto.
El tercer problema no es puramente técnico, sino de evolución de los controles. Los sistemas de riesgo han ido incorporando las direcciones WebRTC como una de varias señales para relacionar cuentas. Datos que antes no se medían o se ignoraban ahora pueden entrar en la evaluación.
El objetivo es que la salida sea coherente, no solo desactivar una opción
Hay varias estrategias generales. Si un flujo de trabajo no necesita en absoluto comunicación en tiempo real, desactivar WebRTC es la opción más simple, con el coste de perder también funciones como las videollamadas o la atención al cliente en línea.
Si esas funciones deben mantenerse, una práctica habitual es hacer que la dirección devuelta en la capa WebRTC sea coherente con la salida del proxy. Una opción más robusta es reenviar también las solicitudes STUN por el canal del proxy, de modo que la interfaz no exponga la dirección local. Si se necesita P2P o videollamadas, todo el tráfico UDP debe pasar por el proxy, no solo la capa HTTP.
Un error frecuente es pensar que desactivar WebRTC por sí solo deja limpio el entorno. Lo importante es que sean coherentes entre sí la salida de red, la resolución DNS, la pertenencia de la IP y el ASN, la zona horaria y el idioma, y las características del dispositivo. Cualquier desajuste puede generar una señal anómala; WebRTC es simplemente uno de los elementos que más fácilmente se pasan por alto.
La verificación es sencilla. Haz una prueba después de cambiar de nodo y otra antes de utilizar el entorno con normalidad: abre una prueba de fugas y comprueba si la sección WebRTC muestra la salida del proxy, una dirección local o la dirección pública real. Una consulta de IP convencional no revela este dato.
Las soluciones de aislamiento a nivel del motor del navegador pueden definir una política de direcciones WebRTC independiente para cada entorno y vincularla a la salida de red de ese entorno. PurpleMark ofrece este tipo de capacidad. Si varios entornos comparten una sola salida o sus políticas de direcciones no son coherentes, el valor del aislamiento se reduce considerablemente.
Esta es únicamente una explicación técnica. Utiliza las herramientas correspondientes respetando las reglas de la plataforma y la legislación local.
