Fugas de VPN explicadas: fugas de DNS, WebRTC e IPv6 (y cómo probarlas de verdad)

Tu aplicación de VPN dice Conectado. Esa sola palabra parece una garantía, pero solo significa que tu dispositivo ha establecido un túnel cifrado hacia el servidor de la VPN. No dice nada sobre si cada fragmento de tráfico identificable está usando realmente ese túnel. Tres fallos habituales — fugas de DNS, fugas de WebRTC y fugas de IPv6 — pueden exponer cada uno tu dirección IP real o tu actividad de navegación mientras la aplicación permanece ahí mostrando una tranquilizadora marca verde.

Esta guía hace tres cosas que las páginas de una sola fuga, del tipo "compra-esta-VPN", nunca hacen. Primero, explica el mecanismo real detrás de cada fuga para que entiendas por qué una VPN conectada todavía puede traicionarte. Segundo, te guía a través de una autoevaluación usando herramientas gratuitas e independientes en las que no tienes que confiar a ningún proveedor. Tercero, te da las soluciones exactas por sistema operativo, navegador y router — y la disciplina de volver a probar que confirma que la solución se mantuvo. Sin promoción de marcas, sin enlaces de afiliados, solo la mecánica.

Qué es realmente una fuga de VPN

Una fuga es cualquier tráfico que debería viajar a través del túnel cifrado pero que en su lugar sale por tu conexión normal a internet, revelando información que se suponía que la VPN debía ocultar. Las tres fugas de esta guía exponen dos cosas distintas. Una fuga de DNS revela los sitios web que consultas a tu ISP (o a quien gestione el resolver que estás usando por accidente). Una fuga de WebRTC y una fuga de IPv6 pueden revelar tu dirección IP real — tu ubicación e identidad reales en línea — directamente a los sitios web que visitas.

Lo más importante que hay que entender desde el principio: se trata de problemas separados con causas separadas y soluciones separadas. Los competidores lo entierran porque es incómodo para un relato de venta de un solo clic, pero ese es el quid de la cuestión. Puedes tapar una fuga de DNS y aun así filtrar tu IP por WebRTC. Puedes blindar WebRTC en tu navegador y aun así filtrarla por IPv6. Cerrar una no te dice nada sobre las otras dos. Por eso un test de fugas de verdad comprueba las tres, siempre.

Cómo ocurre cada fuga (el mecanismo)

Fugas de DNS: consultas que escapan del túnel

Antes de que tu dispositivo cargue example.com, le pide a un resolver DNS que traduzca ese nombre en una dirección IP. Cuando la VPN está configurada correctamente, esa consulta DNS viaja dentro del túnel hacia un resolver que la VPN controla. Una fuga de DNS ocurre cuando la consulta va en su lugar al resolver de tu ISP (o a un resolver impuesto por tu router) por la conexión abierta. Aunque el contenido de la página todavía pueda fluir por el túnel, la consulta en sí revela cada dominio que visitas a un tercero — y lo vincula a tu IP real.

Los culpables habituales son un sistema operativo que ignora la configuración de DNS de la VPN, un resolver codificado a mano (como un 8.8.8.8 o un 1.1.1.1 fijados manualmente) que esquiva el túnel, o reglas de túnel dividido que enrutan el DNS fuera de la VPN. En Windows en particular, una función llamada resolución de nombres multi-conexión inteligente puede lanzar consultas DNS por todas las interfaces de red a la vez y usar la que responda primero — con frecuencia la de tu ISP.

Fugas de WebRTC: el navegador entregando tu IP

WebRTC (Web Real-Time Communication) es la tecnología del navegador que hay detrás de las videollamadas dentro de la página, el chat de voz y la transferencia de archivos entre pares. Para conectar a dos pares directamente, WebRTC necesita descubrir las propias direcciones IP del dispositivo. Lo hace con servidores STUN, que responden al navegador con la IP pública que ven, y además enumera las direcciones de la red local. Una página web puede leer estos candidatos ICE mediante una API de JavaScript — sin ninguna solicitud de permiso y sin que hagas clic en nada.

Aquí está el detalle que hace peligroso a WebRTC incluso con una VPN funcionando: este descubrimiento puede ocurrir fuera de la ruta del proxy que tu navegador usa para las cargas de página normales. La página puede acabar viendo la IP pública que tu sistema operativo considera real, que puede ser tu dirección verdadera en lugar de la de la VPN. Una fuga de WebRTC es un problema del navegador. No se soluciona con la configuración de DNS de tu VPN ni con su kill switch, que es exactamente por lo que quienes solucionaron su fuga de DNS se quedan atónitos al descubrir que su IP sigue apareciendo.

Fugas de IPv6: tráfico por un camino que el túnel nunca pavimentó

Muchos túneles de VPN transportan únicamente tráfico IPv4. Si tu ISP y tu red doméstica también ofrecen conectividad IPv6 — cada vez más la opción por defecto — entonces cualquier petición a un destino con IPv6 puede viajar por tu conexión IPv6 nativa, completamente fuera del túnel que solo maneja IPv4. El sitio web ve tu dirección IPv6 real. La VPN nunca tocó ese tráfico y a menudo ni siquiera se enteró, porque solo estaba vigilando el lado IPv4.

Por eso una fuga de IPv6 es tan silenciosamente común: nada se rompe, nada parece estar mal y la VPN informa de éxito. La solución es desactivar IPv6 en el dispositivo o la red, o usar una VPN que tunelice IPv6 explícitamente o lo bloquee mientras está conectada. Esperar que tu proveedor se ocupe de ello en silencio no es una estrategia — lo compruebas.

Haz el test: herramientas gratuitas y cómo leerlas

Usa herramientas independientes de terceros en lugar de la página de "tu IP está oculta" que te muestra tu proveedor de VPN — un proveedor tiene todos los incentivos para informar de éxito. Haz cada prueba con la VPN conectada, en el mismo navegador y en el mismo dispositivo que usas de verdad. Como base de referencia, conviene ejecutarlas una vez con la VPN apagada primero para saber cómo se ven tu IP y tu ISP reales; luego enciende la VPN y confirma que esos valores desaparecen.

Paso 1 — Test de fugas de DNS

Abre dnsleaktest.com y ejecuta el test extendido (Extended test). Carga una serie de nombres de host únicos e informa de qué servidores DNS los resolvieron. Un resultado limpio muestra resolvers que pertenecen a tu proveedor de VPN (o a un resolver de privacidad que la VPN utiliza), y, crucialmente, no incluye el nombre de tu ISP ni tu país de origen si te conectaste a un servidor en otro lugar. Un resultado con fuga muestra el resolver de tu ISP, o servidores en tu ubicación real que no esperabas. ipleak.net muestra la misma información de DNS junto a tu IP, lo cual resulta útil para contrastar.

Paso 2 — Test de fugas de WebRTC

Abre browserleaks.com/webrtc. Fíjate en la Dirección IP pública (Public IP Address) que descubre mediante WebRTC. Un resultado limpio muestra o bien ninguna IP pública, o bien solo la IP del servidor de la VPN. Un resultado con fuga muestra tu IP pública real en la sección de WebRTC aunque el encabezado de la página (que usa una petición HTTP normal) muestre la IP de la VPN — esa discrepancia es la firma clásica de una fuga de WebRTC. Las direcciones locales en los rangos 10.x, 172.16–31.x, 192.168.x o las de mDNS .local son por lo general inofensivas; el verdadero peligro es que aparezca tu auténtica IP pública.

Paso 3 — Test de IPv6 y de IP general

Abre ipleak.net. Muestra tu dirección IPv4, cualquier dirección IPv6 y tus servidores DNS en una sola página. Un resultado limpio muestra solo la IP de la VPN (acorde con el país que elegiste) y, o bien ninguna dirección IPv6, o bien una IPv6 que también pertenece a la VPN. Un resultado con fuga muestra una dirección IPv6 de tu ISP, o un par IPv4/IPv6 que apunta a dos ubicaciones diferentes. Si ves una IPv6 real junto a una IPv4 de la VPN, eso es una fuga de IPv6 de manual.

Una VPN que oculta tu IPv4 pero expone tu IPv6 no te ha protegido a medias — para cualquier sitio consciente de IPv6, sencillamente no estás usando una VPN en absoluto.

Las soluciones exactas, por SO, navegador y router

Solucionar fugas de DNS

• En la aplicación de la VPN: activa cualquier opción de "Usar solo el DNS de la VPN", "Protección contra fugas de DNS" o "Bloquear DNS ajeno a la VPN". Muchas aplicaciones la traen activada por defecto, pero las configuraciones de OpenVPN/WireGuard de terceros a menudo no.

• Windows: desactiva la resolución de nombres multi-conexión inteligente, que dispersa el DNS entre interfaces. En Windows Pro puedes poner la directiva de grupo "Desactivar resolución de nombres multi-conexión inteligente" en Habilitada; de lo contrario, prefiere un cliente de VPN que fije el DNS y bloquee otros resolvers. Elimina cualquier DNS público configurado a mano (8.8.8.8, 1.1.1.1) de tus adaptadores mientras haces las pruebas.

• macOS / Linux: asegúrate de que no haya ningún resolver codificado en la configuración de red o en /etc/resolv.conf que esquive el túnel; deja que el cliente de la VPN gestione el DNS. En Linux con systemd-resolved, confirma que la VPN establece una ruta de dominio para que las consultas vayan a su resolver.

• Router: si ejecutas la VPN en el router, configura el DNS del router con el resolver de la VPN y desactiva cualquier DNS asignado por el ISP. Desactiva también las funciones del router que interceptan o redirigen el DNS (algunos ajustes de "control parental" o de "protección contra rebind de DNS").

Solucionar fugas de WebRTC (solo en el navegador)

• Firefox: escribe about:config en la barra de direcciones, acepta la advertencia, busca media.peerconnection.enabled y ponlo en false. Esto desactiva WebRTC por completo. Si necesitas WebRTC para llamadas, déjalo activado pero apóyate en una VPN/extensión que enmascare la IP descubierta, y vuelve a probar.

• Chrome / Edge: no hay ningún interruptor integrado para desactivar WebRTC por completo. Ten en cuenta que la antigua opción de uBlock Origin "Evitar que WebRTC filtre direcciones IP locales" se eliminó de la extensión de escritorio allá por 2021, y aun cuando existía solo enmascaraba las direcciones locales/LAN — nunca impidió la divulgación de la IP pública que es la que realmente te expone, así que nunca fue la solución que la gente suponía. Chromium moderno ya ofusca las IP locales usando mDNS (puedes confirmar el indicador "Anonymize local IPs exposed by WebRTC" en chrome://flags). Para controlar la exposición de la IP pública, usa una extensión dedicada de control de WebRTC y luego verifícalo en un test de fugas, ya que las extensiones varían en lo completamente que lo bloquean.

• Safari: la exposición de WebRTC es más limitada por defecto, pero aun así haz la prueba. Puedes desactivarlo mediante las funciones experimentales/de WebRTC del menú Desarrollo si no lo necesitas.

• Comprobación de realidad: desactivar WebRTC puede romper Google Meet, Discord en el navegador, Jitsi y herramientas similares. Si las necesitas, el camino práctico es un navegador/extensión que entregue solo la IP de la VPN en lugar de matar WebRTC del todo — confirmado volviendo a probar.

Solucionar fugas de IPv6

• Mejor opción: usa una VPN que ofrezca explícitamente protección contra fugas de IPv6 (bloquea o tuneliza IPv6 mientras está conectada). Activa ese ajuste y vuelve a probar.

• Windows: desactiva IPv6 en el adaptador activo (Propiedades del adaptador de red, desmarca Protocolo de Internet versión 6), o usa el bloqueo de IPv6 de la VPN. Vuelve a activarlo cuando dejes de usar una VPN que no pueda manejarlo.

• macOS: en Configuración del Sistema, pon la opción Configurar IPv6 del servicio de red en Solo de enlace local (o en Desactivado desde la línea de comandos) si tu VPN no puede tunelizarlo.

• Linux: desactiva IPv6 por interfaz o en todo el sistema mediante sysctl (por ejemplo net.ipv6.conf.all.disable_ipv6=1) si el túnel solo maneja IPv4.

• Router: si ejecutas la VPN en el router, desactiva el IPv6/WAN IPv6 del router para que ningún dispositivo de la red pueda filtrar por ahí. Esta es la solución más limpia para todo un hogar.

Por qué una VPN "conectada" sigue filtrando

Incluso después de haber pasado las tres pruebas una vez, la protección no es permanente — es un estado que puede romperse en silencio. Estos son los momentos en los que una VPN "conectada" empieza a filtrar sin avisar:

• Cambios de red: pasar de Wi-Fi a Ethernet, cambiar de punto de acceso o que tu teléfono alterne entre Wi-Fi y datos móviles puede enrutar tráfico fuera del túnel por un instante, antes de que la VPN restablezca sus reglas.

• Suspensión y reactivación: cuando un portátil sale de la suspensión, la red a menudo vuelve antes de que la VPN se reconecte. Durante unos segundos, el tráfico usa la conexión desnuda — el tiempo suficiente para que las aplicaciones en segundo plano "llamen a casa" con tu IP real.

• Reconexiones y caídas: cada vez que el túnel se cae y vuelve a marcar, hay una ventana en la que el tráfico puede escapar a menos que un kill switch lo bloquee.

• Portales cautivos: el Wi-Fi de hoteles, aeropuertos y cafeterías te exige cargar una página de inicio de sesión antes de que internet funcione. Esa página se carga fuera de la VPN por diseño, y algunas configuraciones siguen filtrando hasta que te reconectas manualmente después.

• Túnel dividido: si has excluido ciertas aplicaciones — o el DNS — de la VPN, esas exclusiones son fugas por configuración. Verifica dos veces que el DNS no esté en la lista de "omisión" sin que te des cuenta.

• El regreso de IPv6: una actualización del SO o un reinicio de red puede reactivar en silencio el IPv6 que habías desactivado, reabriendo ese camino sin avisar.

Kill switches y ajustes de protección contra fugas — y cómo fallan en silencio

Un kill switch es una red de seguridad para el problema de caída y reconexión: cuando el túnel se cae, bloquea todo el tráfico de internet hasta que la VPN vuelve, de modo que nada escapa en ese hueco. La protección integrada contra fugas (protección contra fugas de DNS, bloqueo de IPv6, funciones de "bloqueo de red") obliga a que el DNS y el IPv6 usen únicamente el túnel. Activa ambos — se ocupan de las ventanas de fallo que no puedes vigilar manualmente.

Pero comprende sus modos de fallo silencioso. Un kill switch solo actúa cuando la aplicación detecta que el túnel está caído; si el túnel está técnicamente en pie pero el DNS o el IPv6 se filtran a su alrededor, el kill switch no ve ningún problema y no hace nada. Los kill switches a nivel de aplicación solo protegen el tráfico de la propia aplicación de la VPN, no el del sistema entero. Algunos kill switches no se activan durante la ventana de suspensión/reactivación ni antes del inicio de sesión al arrancar. Y un kill switch de "estilo cortafuegos" que bloquea todo el tráfico cuando está apagado puede confundirse con una caída de internet, lo que tienta a la gente a desactivarlo. La lección: un kill switch reduce el riesgo, no reemplaza las pruebas. La única prueba de que tus ajustes funcionan es un test que se supera.

Resultado inofensivo frente a fallo real de privacidad

No toda entrada desconocida en una página de test de fugas es un desastre. Saber distinguir la diferencia te evita perseguir fantasmas — o ignorar una exposición real.

• Inofensivo: WebRTC mostrando solo direcciones locales/privadas (10.x, 172.16–31.x, 192.168.x) o un nombre de host mDNS .local. Estas no te identifican ante un sitio web.

• Inofensivo: resolvers DNS que pertenecen a tu proveedor de VPN o a un resolver de privacidad que utiliza, aunque estén en una ciudad distinta de la de tu servidor VPN — los proveedores operan flotas de resolvers.

• Inofensivo: ninguna dirección IPv6 en absoluto cuando has desactivado IPv6. Eso es el objetivo, no un fallo.

• Fallo real: cualquier prueba que muestre tu IP pública real (IPv4 o IPv6), tu ciudad/ISP reales o tu país de origen cuando te conectaste deliberadamente a otro lugar.

• Fallo real: resultados de DNS que nombran a tu ISP real, o una IPv4 y una IPv6 que se resuelven en dos ubicaciones diferentes.

• Fallo real: el encabezado de la página mostrando la IP de la VPN mientras la sección de WebRTC muestra la tuya real — la discrepancia es la fuga.

Regla práctica: una IP pública o el nombre de tu ISP apareciendo donde no deberían es un fallo real. Las direcciones privadas/locales y los resolvers propiedad del proveedor son ruido.

Disciplina de volver a probar: el hábito que de verdad te protege

Un test de fugas es una instantánea, no un certificado. Como el estado protector se rompe en los cambios de red, las suspensiones, las reconexiones y los portales cautivos, la prueba solo es significativa para las condiciones bajo las que la hiciste. Crea el hábito:

1. Vuelve a probar después de cada solución — cambia un ajuste y luego confirma que esa fuga concreta está cerrada antes de seguir. Arreglar las tres a la vez y probar una sola vez oculta qué cambio funcionó.

2. Vuelve a probar después de cada cambio de red — nuevo Wi-Fi, cambio a datos móviles, conectar Ethernet, o tras un inicio de sesión en un portal cautivo.

3. Vuelve a probar después de salir de la suspensión y después de una reconexión de la VPN, ya que esas son las ventanas de mayor riesgo.

4. Vuelve a probar después de las actualizaciones del SO y de las aplicaciones, que pueden reactivar IPv6 en silencio o restablecer el comportamiento del DNS.

5. Ejecuta las tres pruebas juntas cada vez — DNS, WebRTC e IPv6 son independientes, y un resultado limpio en una no te dice nada sobre las otras.

Conclusión práctica

"Conectado" es un punto de partida, no una prueba de privacidad. Comprueba las tres fugas con herramientas independientes — dnsleaktest.com para el DNS, browserleaks.com/webrtc para WebRTC e ipleak.net para IPv6 y tu IP general. Trátalas como problemas separados: fuerza el DNS de la VPN en el SO o el router, neutraliza WebRTC en el navegador y bloquea o tuneliza IPv6. Activa tu kill switch y la protección integrada contra fugas para los huecos que no puedes vigilar, pero nunca confíes en ellos a ciegas. Luego vuelve a probar después de cada solución y de cada cambio de red. Diez minutos de pruebas te dicen más sobre tu exposición real que cualquier página de marketing de un proveedor.

Preguntas frecuentes

¿Qué es un test de fugas de VPN y cómo hago uno?

Un test de fugas de VPN comprueba si algún tráfico está escapando de tu túnel cifrado y exponiendo tu dirección IP real o tus consultas de DNS mientras la VPN está conectada. Haz uno conectando tu VPN y visitando luego herramientas independientes como dnsleaktest.com, browserleaks.com/webrtc e ipleak.net. Si alguna de ellas muestra tu IP pública real, tu ISP o tu ubicación de origen, tienes una fuga.

¿Cómo funciona un test de fugas de DNS y qué cuenta como aprobado?

Un test de fugas de DNS carga nombres de host únicos e informa de qué servidores DNS los resolvieron. Apruebas si los resolvers pertenecen a tu proveedor de VPN y tu propio ISP no aparece en la lista. Suspendes si aparece el resolver de tu ISP o si los servidores están en tu ubicación real cuando te conectaste a otro sitio.

¿Cómo soluciono una fuga de DNS?

Primero activa la "protección contra fugas de DNS" o "usar solo el DNS de la VPN" en tu aplicación de VPN. En Windows, desactiva además la resolución de nombres multi-conexión inteligente y elimina cualquier DNS público fijado a mano como 8.8.8.8 de tu adaptador. En un router que ejecuta la VPN, apunta el DNS del router al resolver de la VPN y desactiva el DNS asignado por el ISP, y luego vuelve a probar.

¿Qué es una fuga de WebRTC y la detiene mi VPN?

Una fuga de WebRTC es cuando la función de comunicación en tiempo real de tu navegador descubre y expone tu dirección IP real a una página web, incluso con la VPN conectada. La mayoría de las VPN no la detienen porque es un comportamiento del navegador, no de la red. Soluciónala en Firefox poniendo media.peerconnection.enabled en false en about:config. Chrome y Edge no tienen ningún interruptor integrado para desactivar WebRTC, así que usa una extensión dedicada de control de WebRTC y vuelve a probar — no confíes en la antigua opción de IP local de uBlock Origin, que se eliminó de la extensión de escritorio y, de todos modos, nunca bloqueó la exposición de la IP pública.

¿Qué es una fuga de IPv6 y cómo la evito en mi VPN?

Una fuga de IPv6 ocurre cuando tu túnel de VPN, que solo maneja IPv4, ignora el tráfico IPv6 y le permite viajar por tu conexión del ISP y exponer tu dirección IPv6 real. Evítala activando la protección contra fugas de IPv6 en tu VPN, o desactivando IPv6 en tu dispositivo o router. Tras cambiar el ajuste, confirma en ipleak.net que no aparece ninguna dirección IPv6 del ISP.

¿Un kill switch evita las fugas de DNS y WebRTC?

No de forma fiable. Un kill switch solo bloquea el tráfico cuando detecta que el túnel se ha caído, así que no hace nada ante las fugas de DNS o WebRTC que ocurren mientras el túnel sigue en pie. Necesitas una protección contra fugas de DNS independiente y un blindaje de WebRTC del lado del navegador, con el kill switch como respaldo para las reconexiones y las caídas.

¿Con qué frecuencia debo hacer un test de fugas de VPN?

Haz una prueba después de cada cambio de configuración, y vuelve a probar después de cada cambio de red, ciclo de suspensión/reactivación, reconexión de la VPN, inicio de sesión en un portal cautivo y actualización importante del SO o de las aplicaciones. Cada uno de esos momentos puede reabrir una fuga en silencio. Ejecuta siempre las tres pruebas juntas, ya que DNS, WebRTC e IPv6 son problemas independientes.