Fuga de DNS en VPN: cómo comprobar y solucionar

Has activado la VPN, pero el proveedor aún ve que accedes a YouTube o Instagram. Suena como paranoia — hasta que lo compruebas. La fuga de DNS es una de las razones más comunes por las que la VPN protege menos de lo que parece. Si te enfrentas a un funcionamiento inestable de los sitios bloqueados o simplemente quieres asegurarte de la seguridad —Fuga de DNS en VPN: solución esta problema existe, y es más simple de lo que piensas.

Qué es una fuga de DNS y por qué es peligrosa precisamente en Rusia

DNS es la guía telefónica de Internet. Cuando escribes instagram.com, tu dispositivo primero pregunta al servidor DNS: "¿cuál es la IP de este dominio?". Solo después se establece la conexión. El problema es que la VPN cifra la conexión en sí, pero la consulta DNS puede irse por fuera del túnel — directamente al servidor de tu proveedor.

Resultado: el contenido está cifrado, pero el hecho de que accediste al dominio telegram.org o youtube.com no lo está.

Cómo funcionan las consultas DNS con la VPN activada

En ideal, todo se ve así: dispositivo → túnel VPN cifrado → servidor DNS del proveedor de VPN → sitio. La consulta pasa a través del túnel, el proveedor en Rusia solo ve el flujo cifrado en la IP del servidor VPN y nada más.

Pero si algo sale mal — el sistema operativo envía la consulta DNS directamente, antes de que el túnel tenga tiempo de interceptarla. O paralelamente al túnel. Eso es lo que se llama fuga.

Por qué DPI y el proveedor ven dominios incluso a través de VPN

Los proveedores rusos utilizan activamente DPI (Inspección Profunda de Paquetes) — una tecnología de inspección profunda de paquetes. Los TSPU, que Roskomnadzor obligó a instalar a los proveedores, analizan el tráfico precisamente a nivel de consultas DNS entre otras cosas.

Si tu consulta DNS se envía en texto claro al servidor del proveedor, el sistema DPI ve el dominio. Luego — bloqueo o throttling, esa desaceleración de YouTube, por la cual muchos instalan VPN. Se convierte en un círculo vicioso: hay VPN, pero la desaceleración no desaparece.

Qué riesgos presenta la fuga de DNS al eludir bloqueos del RKN

El proveedor recibe una lista de dominios a los que accedes. Esto es suficiente para aplicar un bloqueo incluso con la VPN activa. El tráfico en sí está cifrado — no saben qué exactamente estabas viendo en YouTube, pero saben que estuviste allí, y pueden desacelerar o bloquear la conexión a nivel de respuesta DNS.

Para aquellos que utilizan VPN precisamente para eludir bloqueos de Instagram, Facebook, TikTok, Twitter/X o Telegram — la fuga de DNS prácticamente anula la protección.

Cómo comprobar la fuga de DNS en un minuto

La comprobación toma literalmente un minuto. Activa la VPN, abre el navegador y sigue las instrucciones a continuación. No se necesitan conocimientos especiales.

Prueba en dnsleaktest.com y browserleaks.com

La forma más sencilla es ir adnsleaktest.com con la conexión VPN activa. El sitio muestra qué servidores DNS están procesando tus consultas en este momento. Funciona de manera similarbrowserleaks.com/dns — allí hay un poco más de detalles sobre la configuración del navegador.

Otra opción esipleak.net. Muestra de inmediato la dirección IP, DNS y WebRTC en una sola página, lo que es conveniente para una verificación rápida y completa.

Cuál es la diferencia entre la prueba Standard y la Extended

En dnsleaktest.com hay dos botones: Prueba estándar y Prueba extendida. La estándar hace alrededor de 6 consultas, la extendida — 36. La diferencia es importante: en la prueba estándar algunas fugas no se manifiestan, porque el sistema operativo tiene tiempo de almacenar en caché las consultas o el balanceador las envía accidentalmente a través del túnel.

Siempre ejecuta la prueba extendida. Toma unos 20 segundos, pero el resultado es confiable.

Cómo leer el resultado: qué IP y países deberían estar

Después de la prueba verás una lista de servidores DNS con direcciones IP y geolocalización. Si te conectaste a un servidor VPN en Alemania — en la lista deberían estar los servidores DNS alemanes o neutrales de tu proveedor de VPN.

Si en la lista aparece una IP rusa o un servidor con el nombre de tu proveedor (por ejemplo, dns.mts.ru o algo similar en geolocalización) — tienes una fuga. Esto es una confirmación directa de que las consultas DNS están saliendo por fuera del túnel.

Comprobación adicional de fuga de WebRTC

WebRTC es una historia aparte. Navegadores como Chrome y Firefox lo utilizan para videollamadas, y puede revelar tu IP real incluso con la VPN activa. Se puede comprobar enbrowserleaks.com/webrtc.

Si ves tu IP rusa real junto a la IP de VPN, debes desactivar WebRTC en el navegador. En Firefox, esto se hace a través de about:config → media.peerconnection.enabled → false. En Chrome, es más fácil instalar la extensión uBlock Origin con la opción de bloqueo de WebRTC activada.

Cómo solucionar la fuga de DNS en diferentes dispositivos

No hay una solución universal: cada plataforma tiene su propia especificidad. A continuación, pasos concretos para cada dispositivo.

Windows: configuración del adaptador y parámetro Block outside DNS

En Windows, el problema a menudo está relacionado con que el sistema sigue enviando solicitudes DNS a través del adaptador de red físico junto con la VPN. Hay dos soluciones.

Primera — si tienes un cliente OpenVPN, añade la línea al archivo de configuraciónblock-outside-dns. Esto cierra el DNS fuera del túnel a nivel de Windows Filtering Platform. Funciona de manera confiable, comprobado.

Segunda — configurar manualmente el DNS en la configuración del adaptador VPN: Panel de control → Conexiones de red → adaptador VPN → Propiedades → IPv4 → ingresar el DNS del proveedor de VPN (generalmente indicado en la documentación). Además, en la configuración de los otros adaptadores (Wi-Fi, Ethernet), elimina el DNS automático para que el sistema no se dirija a ellos en caso de fallo del túnel.

Kill switch — obligatorio. La mayoría de los clientes VPN normales (Mullvad, ProtonVPN, NvoVPN) lo tienen en la configuración. Sin él, ante una breve interrupción de la VPN, el sistema cambia instantáneamente a la conexión directa, y el DNS se envía al proveedor.

Android: DNS privado y comportamiento de diferentes aplicaciones VPN

Android 9+ añadió la función del sistema DNS privado (DNS-over-TLS). Suena como una protección, pero precisamente eso a menudo causa fugas. El DNS privado funciona a nivel del sistema y puede eludir el túnel VPN.

Verifica: Configuración → Red → Avanzado → DNS privado. Si está configurado como "Automático" o se ha ingresado una dirección externa, esto es una fuga potencial con la VPN activa. Al usar una aplicación VPN con su propio resolutor DNS (como la mayoría de los clientes normales), es mejor cambiar el DNS privado a "Desactivado" o "Off".

Adicionalmente: algunas aplicaciones de Android como Psiphon o clientes proxy simples solo proxyan el tráfico HTTP, pero no el DNS. El resultado es una fuga clásica. Usa un cliente VPN completo con el modo "Todo el tráfico".

iPhone/iOS: características de los perfiles y iCloud Private Relay

En iOS, la VPN generalmente se configura a través de perfiles (.mobileconfig) o mediante clientes integrados. La mayoría de las aplicaciones VPN decentes en iOS manejan el DNS correctamente: lo tunelizan a través de su servidor.

Pero hay un matiz:iCloud Private Relay. Si tienes una suscripción a iCloud+, es posible que Private Relay esté activado, y procesará el DNS independientemente de la VPN. Cuando ambos funcionan simultáneamente, los resultados de la prueba de DNS se vuelven impredecibles: ves servidores de Apple y servidores de VPN.

Solución: al usar VPN, desactiva iCloud Private Relay. Configuración → [tu Apple ID] → iCloud → Private Relay → desactivar. Resuelven tareas similares, pero interfieren entre sí.

macOS: configuración manual de DNS y verificación

En macOS, el DNS se configura por separado para cada interfaz de red. Si la VPN crea una interfaz virtual (utun0 y similares), debes asegurarte de que el DNS del sistema para Wi-Fi y Ethernet no lo sobrescriba.

Configuración del sistema → Red → seleccionar Wi-Fi → Avanzado → DNS. Si allí están configurados los servidores del proveedor, reemplázalos por el DNS de tu servicio VPN o déjalos temporalmente vacíos con la VPN activa. Después de los cambios, reinicia la VPN y repite la prueba en dnsleaktest.com.

Router y Smart TV/Apple TV: DNS a nivel de red

Smart TV, Apple TV, PlayStation, Xbox: no tienen sus propios clientes VPN. No puedes instalar una aplicación en un televisor Samsung. La única forma de proteger estos dispositivos es configurar la VPN y el DNS a nivel del router.

En routers con firmware OpenWRT, DD-WRT o Keenetic (popular en Rusia), puedes levantar un cliente VPN directamente en el router e indicar el DNS del proveedor de VPN en la configuración del servidor DHCP. Entonces, todos los dispositivos en la red, incluidos televisores y consolas, utilizan automáticamente el DNS protegido.

Un matiz importante: si tienes NAT doble (por ejemplo, router del proveedor + tu router), el DNS configurado en el router del proveedor puede anular tus configuraciones. Asegúrate de que tu router esté funcionando en modo router y no en puente, y que sea él quien distribuye DHCP a los dispositivos de la red.

Dependencia de la fuga del protocolo: WireGuard, OpenVPN, IKEv2, VLESS

El protocolo importa, y no todos manejan el DNS de la misma manera. Vamos a desglosarlo honestamente, sin marketing.

Por qué WireGuard y OpenVPN se comportan de manera diferente

OpenVPN con la configuración correcta (parámetroblock-outside-dns en Windows, opción redirect-gateway def1 en el archivo de configuración) tuneliza todo el tráfico, incluido el DNS. Opción comprobada, funciona de manera predecible.

WireGuard es un poco diferente en arquitectura: no soporta block-outside-dns de forma nativa. Pero la mayoría de los clientes de WireGuard (Mullvad App, WireGuard oficial para Windows) implementan esta protección a nivel de aplicación. En el archivo de configuración de WireGuard hay un parámetroDNS = en la sección [Interface] — si está configurado, el cliente utiliza el DNS especificado y bloquea el del sistema. Si no está configurado, la fuga es casi garantizada.

IKEv2 normaliza el túnel DNS al usar clientes nativos en Windows y iOS. En Android es un poco más complicado — depende de la implementación.

Shadowsocks y VLESS/XRay: DNS fuera del túnel principal

Aquí es donde la mayoría de los artículos guardan silencio. Shadowsocks y VLESS/XRay son protocolos de proxy, no VPN completas. Funcionan muy bien para eludir DPI y bloqueos de Roskomnadzor, especialmente en combinación con ofuscación. Pero por defecto, proxyan el tráfico de aplicaciones (TCP/UDP), y las consultas DNS van directamente a través del resolutor del sistema.

Si usas clientes como v2rayN, Nekobox o sing-box con VLESS/XRay, necesitas configurar las reglas DNS por separado. En sing-box esto se hace en la sección dns de la configuración: especificas el servidor (por ejemplo, 1.1.1.1 a través de proxy) y las reglas de enrutamiento DNS. Sin esto, hay una fuga clásica, incluso si todo el tráfico HTTP pasa a través del proxy.

Amnezia y ofuscación: en qué influye en el contexto de DNS

AmneziaVPN y otras herramientas de ofuscación (obfs4, Cloak, GoodbyeDPI) ocultan la firma del tráfico VPN del DPI. Esto ayuda a eludir el bloqueo del propio protocolo VPN, pero no resuelve el problema de la fuga de DNS.

Amnezia se construye sobre WireGuard u OpenVPN — por lo tanto, todo lo dicho sobre estos protocolos es aplicable aquí también. La ofuscación funciona a nivel de transporte, DNS es una capa separada. Si el protocolo base está configurado correctamente, DNS irá a través del túnel. Si no, irá por fuera, y la ofuscación no ayudará en nada.

Qué elegir si la protección contra fugas es importante

Para la máxima protección DNS — protocolos VPN clásicos con un cliente correctamente configurado. WireGuard con DNS especificado en la configuración o OpenVPN con block-outside-dns — ambos funcionan bien. Algunos servicios, incluyendo NvoVPN, proporcionan su propio DNS dentro del túnel, lo que elimina la necesidad de configurarlo manualmente.

Si usas VLESS/XRay, no olvides configurar el enrutamiento DNS en sing-box o v2ray. No es complicado, pero requiere un paso adicional en la configuración.

Qué NO funciona y errores comunes

A lo largo de los años se han acumulado varios mitos persistentes. Esto es lo que realmente no funciona — y por qué.

Cambiar DNS a 8.8.8.8 no cierra la fuga

Este es, quizás, el consejo más común en Internet. "Configura Google DNS 8.8.8.8 o Cloudflare 1.1.1.1 — y no habrá fugas". Esto es incorrecto.

Cambiar el servidor DNS solo cambiaa quién se envía tu consulta. Pero si la consulta se envía fuera del túnel, aún pasa a través de la red del proveedor en texto claro, y el DPI la ve. Simplemente cambiaste el destinatario de dns.provider.ru a 8.8.8.8, pero la ruta sigue pasando por el proveedor. Esto no es una solución.

Extensiones de navegador en lugar de VPN del sistema

Extensiones como "VPN para Chrome" o "Proxy para Firefox" solo protegen el tráfico del propio navegador. Las consultas DNS del sistema, las consultas de otras aplicaciones, mensajeros — todo esto va por fuera. La extensión da una falsa sensación de protección.

Lo mismo ocurre con los bloqueadores de WebRTC — solo cierran una fuga específica en el navegador, pero no afectan el DNS del sistema.

Kill switch desactivado y caídas de conexión

El kill switch no es una función opcional. Es un elemento crítico de protección. Ante una breve caída de la VPN (cambio de red, señal Wi-Fi inestable, cambio de IP), el sistema operativo cambia instantáneamente a una conexión directa. La consulta DNS se envía al proveedor — y ahí está, la fuga está registrada.

La caída puede durar de 2 a 3 segundos. Suficiente para que la consulta DNS para el sitio que se está abriendo se envíe directamente. Si tu cliente tiene un kill switch, actívalo. Si el cliente no proporciona un kill switch, busca otro. Así es como se vela fuga de DNS de VPN: solución a nivel de configuración.

Y otra situación subestimada: un filtro DNS corporativo o control parental configurado en el dispositivo. Estas herramientas a menudo redefinen el DNS del sistema y funcionan independientemente de la VPN. Si hay un perfil MDM o una aplicación de control parental con su propio DNS en el dispositivo, interceptará las consultas independientemente de la configuración de la VPN.

Si has entendido la configuración, has ejecutado la prueba extendida y te has asegurado de que los servidores DNS pertenecen a tu proveedor de VPN y no a un operador ruso —la fuga de DNS de VPN: solución encontrada y el problema cerrado. Verifica esto periódicamente, especialmente después de actualizar aplicaciones o el sistema.