Una fuga de DNS se produce cuando tu dispositivo envía las consultas de nombres de dominio fuera del túnel de tu VPN, normalmente al resolutor de tu proveedor de internet, de modo que este sigue pudiendo ver qué sitios visitas. Una fuga de WebRTC es un problema relacionado del navegador, en el que una página web puede descubrir tu dirección IP real aunque tu VPN o tu proxy estén activos.
Ambas fugas son silenciosas: la VPN indica «conectado» y los sitios web ven la IP de la VPN en el tráfico normal. Esta guía explica por qué se produce cada una, cómo comprobarla y cómo solucionarla, junto con la fuga de IPv6, muy relacionada.
Qué es una fuga de DNS
Antes de que tu navegador pueda conectarse a www.example.com, tiene que preguntar a un resolutor DNS cuál es la dirección IP del sitio. Esa pregunta, y su respuesta, revelan qué sitio estás a punto de visitar. Si no conoces bien el proceso de consulta, nuestra guía sobre cómo funciona el DNS lo explica paso a paso.
Una VPN bien configurada envía las consultas DNS por el túnel a un resolutor gestionado por el proveedor de la VPN o a uno que hayas elegido tú. Cuando eso falla y las consultas van directamente al resolutor de tu proveedor de internet, tienes una fuga de DNS. El sitio web sigue viendo la IP de la VPN, pero tu proveedor de internet tiene una lista de todos los dominios que has consultado, con la hora de cada uno.
Causas habituales de las fugas de DNS
- El sistema operativo sigue usando el resolutor anterior. El cliente de la VPN no consigue sustituir la configuración DNS del sistema, o el servidor DNS de otro adaptador de red tiene mayor prioridad.
- Consultas en paralelo en Windows. Windows puede enviar una consulta a los servidores DNS de varias interfaces de red a la vez y usar la respuesta más rápida, por lo que el resolutor del proveedor de internet ve la consulta aunque también la vea el de la VPN.
- DNS por IPv6. La VPN gestiona el DNS por IPv4, pero el sistema también tiene un resolutor IPv6 procedente del router, que se usa fuera del túnel.
- Túnel dividido (split tunnelling). Las aplicaciones excluidas de la VPN resuelven los nombres con el resolutor normal, por diseño.
- Ajustes DNS manuales en el dispositivo o en el router que anulan lo que establece la VPN.
Cómo comprobar si hay una fuga de DNS
Las pruebas específicas de fugas de DNS funcionan haciendo que tu navegador consulte varios subdominios aleatorios y únicos de un dominio cuyo servidor autoritativo controla quien hace la prueba. El servidor autoritativo registra qué direcciones IP de resolutores han preguntado por esos nombres. Si alguna pertenece a tu proveedor de internet y no al de tu VPN, tienes una fuga.
Puedes hacer una versión rápida desde un terminal. Akamai mantiene un nombre especial que responde con la dirección IP del resolutor que preguntó por él:
dig +short whoami.akamai.net
nslookup whoami.akamai.net
Ejecútalo con la VPN conectada y pega la IP devuelta en nuestra herramienta Buscar ASN. Si la red pertenece a tu proveedor de internet, tu DNS tiene una fuga. Comprueba también qué resolutores tiene configurados tu sistema:
- Windows:
ipconfig /ally mira «Servidores DNS» en cada adaptador. - macOS:
scutil --dns - Linux con systemd-resolved:
resolvectl status
Cómo solucionar una fuga de DNS
- Activa la opción de protección contra fugas de DNS del cliente de la VPN, si la tiene. La mayoría de los clientes actuales fuerzan todo el DNS por el túnel y bloquean el puerto 53 hacia otros servidores.
- Elimina los servidores DNS configurados manualmente en el adaptador de red o configúralos con el resolutor de la VPN.
- Si la VPN no admite IPv6, desactiva IPv6 en el adaptador o activa la protección contra fugas de IPv6 del cliente.
- Activa el kill switch para que nada, DNS incluido, salga del dispositivo mientras el túnel se reconecta.
- Vuelve a comprobarlo tras cada cambio, y de nuevo después de conectarte a otra red Wi-Fi.
Qué es una fuga de WebRTC
WebRTC es la tecnología del navegador que hay detrás de las videollamadas y las transferencias de archivos entre iguales (peer-to-peer). Para conectar directamente dos navegadores, tiene que encontrar todas las direcciones en las que cada uno podría ser localizable. Lo hace mediante ICE (Interactive Connectivity Establishment), que reúne una lista de candidatos:
| Tipo de candidato | De dónde procede | Ejemplo |
|---|---|---|
| Host | Las propias interfaces de red del dispositivo | 192.168.1.23 o un nombre mDNS |
| Server reflexive (srflx) | Un servidor STUN indica la IP pública y el puerto desde los que vio llegar la petición | 203.0.113.50 |
| Relay | Un servidor TURN que reenvía el contenido multimedia cuando falla la vía directa | La IP del servidor TURN |
Cualquier página web puede iniciar este proceso con unas pocas líneas de JavaScript, sin pedir permiso, y leer los candidatos. La fuga se produce cuando la petición STUN sale de tu dispositivo fuera de la VPN o del proxy. Es habitual con las extensiones de proxy del navegador y los proxies SOCKS, que enrutan las peticiones web pero no el tráfico UDP de WebRTC, y con el túnel dividido. Entonces el candidato server reflexive contiene tu IP pública real.
Ofuscación mDNS de las direcciones locales
Los candidatos host solían exponer direcciones privadas de la red local como 192.168.1.23, lo que ayudaba a identificar a los usuarios por la huella digital del navegador (fingerprinting). Las versiones actuales de Chrome, Firefox, Safari y Edge las sustituyen por nombres aleatorios como 3f1c2a9e-7b4d-4c1e-9a52-6d8e0f1b2c3a.local, que se resuelven mediante DNS multicast solo en la red local. Los navegadores normalmente solo revelan las direcciones locales reales después de que se conceda a una página acceso a la cámara o al micrófono.
Cómo comprobar y solucionar las fugas de WebRTC
Ejecuta nuestro Test de fugas WebRTC con tu VPN o proxy activos. Muestra todos los candidatos que expone tu navegador. Si alguna dirección pública coincide con la que tienes con la VPN apagada, hay una fuga. Para solucionarlo:
- Usa una VPN de túnel completo en lugar de un proxy solo para el navegador. Cuando todo el tráfico UDP pasa por el túnel, el servidor STUN ve la IP de la VPN.
- Firefox: abre
about:configy establecemedia.peerconnection.enabledenfalse. Esto desactiva WebRTC por completo, así que las videollamadas en el navegador dejan de funcionar. - Navegadores basados en Chromium: no hay un ajuste sencillo para el usuario, pero la política empresarial
WebRtcIPHandling(por ejemplodisable_non_proxied_udp) o una extensión de confianza pueden restringir qué interfaces usa WebRTC.
Fugas de IPv6
Muchas redes dan ahora a los dispositivos una dirección IPv4 y otra IPv6. Si tu VPN solo crea un túnel IPv4, el sistema operativo sigue teniendo una ruta IPv6 operativa a través de tu proveedor de internet. Los sitios que admiten IPv6 la prefieren, así que ven tu dirección IPv6 real y globalmente única, que suele identificar más que una dirección IPv4 compartida detrás de NAT.
Haz la prueba con la VPN conectada usando nuestro Test de IPv6. Lo que quieres ver es que no hay conectividad IPv6 o que la dirección IPv6 pertenece al proveedor de la VPN. Una dirección del rango de tu propio proveedor de internet significa que hay una fuga; soluciónala activando la compatibilidad con IPv6 o la protección contra fugas del cliente, o desactivando IPv6 en el adaptador de red mientras uses la VPN.
Preguntas frecuentes
¿Puede mi proveedor de internet ver lo que navego si tengo una fuga de DNS?
Puede ver los nombres de dominio que consultas, no las páginas ni el contenido. El tráfico en sí sigue pasando por la VPN, así que tu proveedor de internet no puede ver lo que haces en cada sitio.
¿Importan las fugas de DNS si no uso una VPN?
El término solo se aplica cuando esperas que el DNS vaya a otro sitio. Sin VPN, normalmente se usa de todos modos el resolutor de tu proveedor de internet. Puedes cambiar a un servicio de DNS cifrado para que tu proveedor no vea las consultas.
¿Es seguro desactivar WebRTC?
Sí, no estropeará la navegación normal, pero las videollamadas en el navegador, el uso compartido de pantalla y algunos sitios para compartir archivos dejarán de funcionar hasta que lo vuelvas a activar.
¿Por qué el test de WebRTC muestra una dirección .local?
Es la protección mDNS del navegador funcionando como debe. El nombre aleatorio .local oculta tu IP privada de la red local al sitio web.