Conectar una VPN no convierte automáticamente al navegador en una caja negra. WebRTC, la tecnología que permite llamadas, videoconferencias y comunicaciones en tiempo real directamente desde la web, necesita conocer rutas de red para conectar dos extremos. Ese proceso puede proporcionar a una aplicación web más información sobre la red del usuario que una petición HTTP convencional.
Eso no significa que WebRTC sea inseguro ni que todas las VPN “tengan fugas”. Significa algo más preciso: la privacidad depende de cómo el navegador gestione los candidatos ICE, de la configuración del sistema, del tipo de VPN y de si el tráfico se enruta de forma completa o dividida.
1. Qué es WebRTC
WebRTC —Web Real-Time Communication— es un conjunto de APIs y protocolos que permite a los navegadores establecer comunicaciones de audio, vídeo y datos en tiempo real. Es la base de muchas videollamadas, reuniones online, soporte remoto, juegos y aplicaciones colaborativas.
Una de sus grandes ventajas es que puede intentar establecer conexiones directas entre los participantes. Para hacerlo necesita descubrir cómo llegar desde un dispositivo hasta el otro a través de interfaces locales, routers, NAT, firewalls y, cuando sea necesario, servidores intermedios.
2. ICE: la pieza que busca el camino
WebRTC utiliza ICE (Interactive Connectivity Establishment) para recopilar posibles rutas de conexión. Cada una se representa mediante un candidato ICE. Entre los tipos habituales están host, srflx (server reflexive), prflx y relay.
Un candidato puede contener información de direccionamiento, transporte y puerto. Esa información es necesaria para probar rutas y seleccionar una conexión viable, pero también explica por qué WebRTC ha sido históricamente relevante desde el punto de vista de la privacidad.
3. STUN: ¿qué dirección ve Internet?
STUN ayuda al cliente a conocer la dirección y el puerto que resultan visibles desde el exterior al atravesar NAT. Simplificando: el navegador consulta un servidor STUN y obtiene información que permite construir un candidato alcanzable.
Esto es útil para intentar una comunicación directa. Sin embargo, la dirección obtenida puede aportar información adicional sobre la conectividad del usuario. El RFC 8828 de la IETF reconoce expresamente que WebRTC puede permitir a una aplicación conocer más direcciones que las visibles mediante HTTP convencional.
4. TURN: cuando la conexión directa no funciona —o no interesa
TURN funciona como relé. En lugar de comunicar directamente los extremos, el tráfico pasa por un servidor TURN. Esto añade infraestructura y puede aumentar consumo de ancho de banda o latencia, pero también permite funcionar detrás de NAT y firewalls complejos.
Desde la perspectiva de privacidad, una aplicación puede configurar WebRTC con una política relay para utilizar únicamente candidatos retransmitidos. MDN señala que esta configuración evita incluir candidatos host y otros candidatos no relay, reduciendo la exposición de la dirección del usuario frente al otro extremo.
5. Entonces, ¿WebRTC puede revelar mi IP real?
Puede revelar información de red que el usuario no esperaba exponer, pero la respuesta depende de la configuración. No es correcto afirmar que WebRTC siempre atraviesa una VPN o que siempre revela la IP del proveedor de Internet.
El estándar de manejo de direcciones IP de WebRTC indica que el tráfico debe seguir normalmente las reglas de enrutamiento del sistema. Con una VPN correctamente configurada y un navegador moderno, el comportamiento puede ser muy diferente al de las antiguas demostraciones de “WebRTC leak”.
Existe, no obstante, un escenario especialmente importante: una VPN con split tunneling o múltiples interfaces disponibles. El RFC 8828 describe que, si la VPN y el sistema permiten enrutar por varias interfaces, WebRTC puede llegar a descubrir tanto la dirección pública asociada a la VPN como la dirección pública del ISP utilizada fuera del túnel.
6. Las direcciones privadas también importan
Direcciones como 192.168.x.x, 10.x.x.x o 172.16.x.x–172.31.x.x no identifican directamente una ubicación en Internet, pero pueden aportar información sobre la topología de la red y aumentar la superficie de fingerprinting.
La IETF advierte de que las direcciones privadas pueden ayudar a correlacionar contextos de navegación o revelar características de una red interna. Por ese motivo, los navegadores modernos han incorporado mecanismos para reducir su exposición.
7. mDNS cambió el panorama de las antiguas “WebRTC leaks”
Una mitigación utilizada por navegadores modernos consiste en ocultar determinadas direcciones locales mediante nombres mDNS generados dinámicamente en los candidatos ICE. En vez de entregar directamente una IP privada al JavaScript de una página, puede aparecer un nombre local opaco.
Esto reduce una de las fugas clásicas asociadas a WebRTC. Por eso muchas guías antiguas que muestran automáticamente la IP privada del equipo ya no representan fielmente el comportamiento de todos los navegadores actuales.
8. WebRTC no es el único problema de privacidad
Incluso si una prueba WebRTC no revela una dirección inesperada, una VPN no equivale a anonimato. Un sitio puede observar o inferir otras señales: cookies, almacenamiento local, sesión iniciada, características del navegador, resolución de pantalla, idioma, zona horaria, cabeceras, comportamiento y diferentes elementos utilizados para fingerprinting.
La privacidad real debe analizarse como un conjunto de capas. Ocultar la IP pública es importante, pero no elimina por sí sola todos los identificadores.
9. Cómo comprobar tu exposición de forma responsable
- Realiza una prueba sin VPN y anota qué direcciones públicas aparecen.
- Activa la VPN y repite la prueba en las mismas condiciones.
- Comprueba si aparece la IP pública del ISP cuando esperabas que todo el tráfico utilizara el túnel.
- Revisa si la VPN utiliza túnel completo o split tunneling.
- Compara varios navegadores, porque sus políticas de privacidad WebRTC pueden diferir.
- Repite después de actualizar navegador, cliente VPN o sistema operativo.
Una prueba aislada debe interpretarse con cuidado: ver una dirección privada, una dirección mDNS, la IP del servidor VPN o una dirección de relay no significa lo mismo.
10. Qué puede hacer un usuario
- Mantener navegador y cliente VPN actualizados.
- Elegir una VPN que gestione correctamente WebRTC y IPv6.
- Evitar split tunneling cuando el objetivo sea que todo el tráfico utilice el túnel.
- Comprobar periódicamente DNS, IPv4, IPv6 y WebRTC tras cambios de configuración.
- Revisar los controles de privacidad WebRTC disponibles en el navegador.
- No instalar extensiones de privacidad indiscriminadamente: una extensión añade código con permisos dentro del navegador y también puede aumentar la superficie de riesgo.
11. Qué puede hacer un desarrollador WebRTC
Si una aplicación necesita maximizar privacidad frente al peer remoto, puede valorar el uso de TURN y iceTransportPolicy: "relay". El coste es que todo el tráfico WebRTC pasa por el relé, aumentando recursos y pudiendo afectar a rendimiento.
También conviene recopilar únicamente la información necesaria, documentar el tratamiento de datos de red y probar el comportamiento en distintas combinaciones de navegador, sistema operativo, IPv4/IPv6, NAT y VPN.
12. Un ejemplo conceptual de candidatos ICE
Un candidato host representa una dirección directa del extremo. Un candidato srflx suele derivarse mediante STUN y representa una dirección observada a través de NAT. Un candidato relay corresponde a una dirección proporcionada por TURN. ICE prueba candidatos y selecciona una ruta viable de acuerdo con sus prioridades y comprobaciones de conectividad.
Comprender esta diferencia evita interpretar cualquier dirección mostrada por una herramienta de prueba como una “fuga de IP”. Lo importante es identificar qué tipo de candidato es, qué interfaz lo originó y si contradice la política de privacidad que esperábamos.
13. VPN conectada no significa anonimato
Una VPN modifica una parte muy importante del modelo de exposición: la ruta de red y la dirección pública visible para determinados destinos. Pero no elimina automáticamente la identidad de una sesión web ni neutraliza todas las técnicas de correlación.
Si entras en una cuenta personal, mantienes cookies persistentes o presentas un fingerprint reconocible, cambiar la IP no convierte esa actividad en anónima. WebRTC es solo una pieza dentro de ese escenario.
14. Conclusión
WebRTC es una tecnología legítima y extremadamente útil. El riesgo aparece cuando desconocemos qué información necesita intercambiar para construir una conexión y asumimos que el icono de una VPN garantiza por sí solo privacidad absoluta.
La estrategia correcta no consiste necesariamente en desactivar WebRTC. Consiste en comprender ICE, STUN y TURN, mantener software actualizado, configurar correctamente la VPN, comprobar qué rutas utiliza realmente el sistema y decidir cuánto rendimiento estamos dispuestos a intercambiar por una política de red más restrictiva.
Principio Bussio28Team: privacidad no significa confiar en que una herramienta está funcionando. Significa comprobar qué información sale realmente de tu equipo y entender por qué.