Detección de fugas de red 2026: guía de pruebas DNS, WebRTC, IPv6

Una VPN cambia tu IP de salida. Por defecto, no sella todos los caminos por los que tu identidad real puede filtrarse. Las consultas DNS, el descubrimiento de pares WebRTC y los paquetes IPv6 representan cada uno canales distintos que eluden o preceden las configuraciones VPN típicas. Esta guía proporciona un protocolo de prueba reproducible y el contexto técnico para entender qué expone cada tipo de fuga y cómo cerrar cada brecha.

1. Por qué persisten las fugas de red en 2026

La arquitectura de internet no fue diseñada pensando en la aplicación de túneles. Cuando te conectas a una VPN, el cliente generalmente crea una interfaz de red virtual, instala reglas de enrutamiento y actualiza la configuración DNS del sistema. Cada una de estas operaciones tiene modos de fallo, y el fallo es habitual.

Tres categorías de actores concentran la mayor parte del riesgo práctico para los usuarios que emplean una VPN específicamente para preservar su privacidad:

Vigilancia a nivel ISP. Tu ISP puede observar tus consultas DNS en su resolver recursivo a menos que enrutes el DNS dentro del túnel VPN. En conexiones residenciales, esto significa que ve un registro de cada nombre de host al que accedes. En jurisdicciones con leyes de retención de datos (sucesores de la Directiva UE 2006/24, IPA 2016 en el Reino Unido, TSSR en Australia), los ISP almacenan estos datos durante meses o años. Una fuga DNS reactiva esta capacidad para toda la sesión.

Wi-Fi público y portales cautivos. El Wi-Fi gestionado en hoteles, aeropuertos y espacios de coworking regularmente intercepta el tráfico antes de que la negociación VPN se complete. DHCP asigna una dirección de puerta de enlace, y hasta que el túnel VPN esté activo, todo el tráfico — incluyendo DNS y WebRTC — fluye por la red cautiva. Algunos portales cautivos bloquean activamente los protocolos VPN para evitar su elusión, forzando intentos de reconexión que crean ventanas de exposición repetidas.

Rastreo en navegador a escala. Los scripts de análisis y publicidad que se cargan en sitios web comerciales ordinarios pueden ejecutar código WebRTC para recopilar candidatos IP sin solicitar ningún permiso. En 2026, al menos 340 de los 10.000 sitios más visitados según Alexa cargan al menos un script de terceros que sondea RTCPeerConnection. Para los usuarios con VPN, esto expone la dirección de la red local y a veces la dirección pública asignada por el ISP — datos que pueden correlacionarse con una identidad a nivel del hogar incluso sin la IP de salida.

Entender qué canal tiene fugas requiere probar cada uno independientemente. Las páginas combinadas de "¿tengo fugas?" mezclan resultados y frecuentemente pasan por alto casos límite. Un protocolo de prueba estructurado — documentado en la sección 5 — proporciona una cobertura fiable.

Para el contexto sobre cómo la exposición a fugas encaja en el panorama más amplio de privacidad del navegador, consulta el resumen Estado de privacidad de los navegadores 2026 de PrivSec Lab.

2. Fugas DNS — mecanismo y detección

La resolución DNS sigue un orden de prioridad definido por el sistema operativo. En Linux, /etc/nsswitch.conf y /etc/resolv.conf lo gobiernan. En Windows, el cliente DNS consulta los resolvers configurados de cada adaptador en orden, usando reglas NRPT (Name Resolution Policy Table) para anulaciones específicas de dominio. En macOS, la configuración del resolver en /etc/resolver/ y la salida de scutil --dns determinan el comportamiento.

Un cliente VPN que previene correctamente las fugas DNS debe anular todos estos caminos. Los modos de fallo comunes son:

Resolver del sistema no reemplazado completamente. Algunos clientes VPN actualizan la configuración DNS del adaptador principal pero dejan los adaptadores secundarios (Ethernet mientras se usa Wi-Fi, por ejemplo) apuntando al resolver del ISP. Las consultas pueden enrutarse por cualquiera de las interfaces según las condiciones de red.

Bypass DoH del navegador. Chrome y Firefox implementan DNS-over-HTTPS (RFC 8484) independientemente del sistema operativo. Si el DoH integrado del navegador está habilitado y apunta a un resolver público (Cloudflare 1.1.1.1, Google 8.8.8.8), esas consultas eluden completamente el DNS de la VPN y van directamente por HTTPS al resolver externo. La resolución resultante ocurre fuera del túnel VPN, aunque la propia conexión HTTPS esté cifrada.

DNS prefetch y resolución especulativa. Los navegadores envían consultas DNS especulativas para los enlaces de la página actual antes de que el usuario navegue. Estas usan la pila DNS del navegador, que puede invocar DoH o el resolver del sistema. Las extensiones que deshabilitan las etiquetas <link rel="dns-prefetch"> reducen esta superficie pero no eliminan completamente la resolución en segundo plano.

Cómo probar fugas DNS:

1. dnsleaktest.com — ejecuta las pruebas estándar y extendida. La prueba extendida envía más de 30 consultas para forzar el uso de cualquier ruta de resolver secundaria. Compara el ASN (número de sistema autónomo) y la IP de los resolvers mostrados con lo que documenta tu proveedor VPN.
2. ipleak.net — muestra simultáneamente la IP, los resolvers DNS y los candidatos WebRTC en una sola página. Útil para un vistazo rápido multicanal pero menos granular que una prueba DNS dedicada.
3. Cloudflare 1.1.1.1/help — muestra qué resolver usa actualmente la pila DNS de tu navegador, incluyendo si DoH está activo y apuntando al endpoint de Cloudflare. Útil para verificar la configuración DNS a nivel de navegador independientemente del sistema operativo.

La distinción de protocolo importa: las consultas UDP/53 en texto plano no están cifradas y son interceptables en cualquier salto de red. DNS-over-TLS (RFC 7858) cifra las consultas hacia el resolver pero este aún ve todas las consultas en texto plano. DNS-over-HTTPS (RFC 8484) envuelve las consultas en HTTPS, haciéndolas parecer tráfico web normal y resistiendo la interceptación en nodos de red intermedios. Ni DoT ni DoH impiden que el propio resolver registre las consultas.

Para una comparación técnica profunda de las implementaciones DoH entre navegadores y sistemas operativos, consulta nuestro análisis DNS sobre HTTPS: implementaciones 2026.

3. Fugas WebRTC — STUN, ICE y exposición JavaScript

WebRTC (Web Real-Time Communication) es una API del navegador que habilita canales de audio, vídeo y datos entre pares. El proceso de establecimiento de conexión usa ICE (Interactive Connectivity Establishment), que a su vez usa el protocolo STUN definido en la RFC 5389.

Cómo STUN expone las direcciones IP:

Cuando un navegador crea un RTCPeerConnection, comienza a recopilar candidatos ICE — una lista de direcciones de red a través de las cuales puede recibir conexiones de pares. El proceso de recopilación implica:

1. Candidatos host: direcciones IP de la interfaz local (IPs de LAN, loopback) recopiladas directamente de la pila de red del sistema.
2. Candidatos server-reflexive: la IP pública tal como la ve un servidor STUN. El navegador envía una Binding Request UDP a un servidor STUN; el servidor responde con la IP de origen y el puerto del cliente (el atributo Mapped Address en la respuesta STUN). Esta es la IP externa — la que expone el NAT de tu router a internet.
3. Candidatos relay: direcciones de servidores TURN usadas cuando la conectividad directa falla.

El problema crítico es que esta recopilación ocurre de forma síncrona cuando se instancia RTCPeerConnection, antes de cualquier interacción del usuario o concesión de permisos. Un script puede ejecutar:

const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] });
pc.createDataChannel('');
pc.onicecandidate = e => { if (e.candidate) console.log(e.candidate.candidate); };
pc.createOffer().then(o => pc.setLocalDescription(o));

Esto muestra todos los candidatos recopilados en la consola — o los envía a un servidor remoto si el callback los transmite mediante fetch. Sin permiso de cámara. Sin permiso de micrófono. Sin alerta al usuario.

Mitigaciones del navegador:

• Firefox: media.peerconnection.enabled en about:config establecido en false deshabilita completamente WebRTC. Esto previene todas las fugas pero también rompe cualquier aplicación WebRTC. Enfoque más específico: media.peerconnection.ice.default_address_only establecido en true restringe la recopilación ICE solo a la interfaz predeterminada, evitando la exposición de la IP LAN local mientras mantiene WebRTC funcional.
• Chrome/Chromium: El flag legacy chrome://flags/#enable-webrtc-hide-local-ips-with-mdns reemplaza las IPs locales con nombres de host mDNS (ej. a1b2c3d4.local) en los candidatos ICE, impidiendo que JavaScript lea la dirección LAN real. Este es ahora el comportamiento predeterminado en Chrome 75+. Sin embargo, los candidatos server-reflexive (IP pública) aún se exponen si hay un servidor STUN configurado.
• Brave: La protección contra huellas digitales de Brave al nivel "Estándar" bloquea las fugas WebRTC entre sitios. Al nivel "Estricto", WebRTC se deshabilita completamente para los frames de terceros, lo que evita las sondas STUN de redes analíticas y publicitarias mientras permite el WebRTC de primer nivel (ej. videoconferencia en meet.example.com) en el frame principal.
• uBlock Origin: El ajuste "Evitar que WebRTC filtre direcciones IP locales" en el panel de control de uBlock Origin (pestaña Privacidad) intercepta la construcción de RTCPeerConnection y anula la configuración ICE para evitar el uso de servidores STUN por parte de scripts de terceros.

Cómo probar fugas WebRTC:

browserleaks.com/webrtc ejecuta una secuencia completa de recopilación ICE y muestra todos los candidatos recopilados, incluyendo direcciones locales, server-reflexive y la IP pública vista por su servidor STUN. Compara la IP pública mostrada con tu IP de salida VPN. Una discrepancia — especialmente si la IP filtrada está en el ASN de tu ISP — confirma una fuga WebRTC.

Para la interacción entre WebRTC y los vectores de huella digital, consulta nuestro análisis comparativo Navegadores de privacidad 2026.

4. Fugas IPv6 — fallos dual-stack y puntos ciegos de VPN

La adopción de IPv6 alcanzó aproximadamente el 45% del tráfico de internet global a finales de 2025, según estadísticas de APNIC. La mayoría de los ISP residenciales en América del Norte, Europa Occidental y los principales mercados asiáticos ahora aprovisionan conexiones dual-stack por defecto — lo que significa que tu router y dispositivos reciben direcciones globales IPv4 e IPv6.

Cómo ocurren las fugas IPv6:

Una VPN crea una interfaz de túnel. Históricamente, la mayoría de las implementaciones VPN para consumidores creaban un túnel IPv4 (tun0 o similar) sin aprovisionar un túnel IPv6. Cuando te conectas a un servidor dual-stack, el sistema operativo elige entre rutas IPv4 e IPv6. Si IPv6 es accesible de forma nativa (a través del prefijo IPv6 nativo de tu ISP) y no hay ruta VPN para IPv6, el sistema envía paquetes IPv6 directamente a través de la interfaz nativa — eludiendo completamente la VPN.

El resultado: tu tráfico IPv6 revela tu dirección IPv6 global asignada por el ISP, que es única y persistente (los ISP generalmente asignan prefijos estables a los clientes residenciales). Esta dirección está vinculada a tu cuenta, tu hogar y tu información de facturación a nivel del ISP.

Configuraciones que crean fugas IPv6:

• Clientes VPN que solo crean túneles IPv4 y no bloquean ni enrutan IPv6
• Configuraciones VPN split-tunnel que enrutan solo subredes IPv4 específicas por el túnel
• Protocolos VPN (especialmente configuraciones antiguas de IKEv2) implementados sin reglas de enrutamiento de política IPv6
• Dispositivos móviles que adquieren direcciones IPv6 vía SLAAC después de la conexión VPN y antes de que el cliente VPN actualice el enrutamiento

Cómo probar fugas IPv6:

1. ipv6-test.com — muestra tu dirección IPv6 actual y el prefijo si es accesible. Si la dirección mostrada está en el prefijo de tu ISP (no de tu proveedor VPN), tienes una fuga IPv6.
2. test-ipv6.com — ejecuta una secuencia de pruebas incluyendo accesibilidad IPv6, DNS-via-IPv6 y comportamiento de replegamiento. La prueba "IPv6 sin DNS" es particularmente útil para aislar fugas de transporte de fugas del resolver.
3. ipleak.net — muestra la dirección IPv6 junto a la IPv4 y el DNS, permitiendo la comparación de los tres en una vista.

Mitigaciones:

• Usar un cliente VPN que enrute IPv6 dentro del túnel o deshabilite IPv6 en todas las interfaces mientras el túnel está activo (esta última es la implementación más común)
• En Linux, puedes deshabilitar explícitamente IPv6 con sysctl -w net.ipv6.conf.all.disable_ipv6=1 antes de conectar; mejor configurar esto en los scripts up/down del cliente VPN
• En Windows, Adaptadores de red → Propiedades → desmarcar "Protocolo de Internet versión 6" por adaptador, o configurar el enlace del adaptador VPN para manejar ambas pilas
• Verifica que el manejo de IPv6 esté documentado en la base de conocimiento de tu proveedor VPN; la ausencia de documentación es en sí misma una señal

5. Protocolo de prueba reproducible

Una sola prueba en la configuración de la VPN es insuficiente. El estado de red cambia en ciclos de suspensión/reanudación, renovación DHCP, re-autenticación del portal cautivo y actualizaciones del sistema operativo. El siguiente protocolo establece una referencia y cubre las transiciones de estado.

Configuración: definir tu referencia

Antes de cualquier conexión VPN, documenta:

• Las IPs del resolver DNS de tu ISP con nslookup -type=ns google.com o dig @8.8.8.8 google.com
• Tu IPv4 pública desde un endpoint HTTP simple (curl http://ipinfo.io/ip)
• Tu IPv6 pública si está presente (curl -6 http://ipv6.icanhazip.com)
• El resolver DNS de tu navegador desde Cloudflare 1.1.1.1/help

Paso 1: instantánea pre-VPN

Con la VPN desconectada, ejecuta las cuatro herramientas de prueba y registra:

• Resolvers DNS mostrados en dnsleaktest.com (prueba extendida)
• Candidatos WebRTC en browserleaks.com/webrtc
• Direcciones IPv4 e IPv6 en ipv6-test.com
• DNS del navegador en 1.1.1.1/help

Paso 2: prueba post-conexión VPN

Conecta la VPN. Espera 30 segundos para que las tablas de enrutamiento se estabilicen. Repite las cuatro pruebas. Resultados esperados si la VPN está correctamente configurada:

• Los resolvers DNS deben estar en el ASN del proveedor VPN o en un resolver de confianza (Cloudflare, resolver propio de Mullvad)
• Los candidatos server-reflexive de WebRTC deben mostrar solo la IP de salida VPN
• IPv6 debe mostrar la IP de salida IPv6 de la VPN o indicar "sin conectividad IPv6" (ambos son aceptables si la VPN no aprovisiona IPv6)
• El DNS del navegador debe usar el resolver configurado de la VPN

Paso 3: prueba del kill switch

Con la VPN activa y una pestaña del navegador abierta ejecutando consultas DNS continuas (prueba extendida de dnsleaktest.com en bucle), desconecta abruptamente el cliente VPN — no mediante el botón de desconexión gradual, sino deshabilitando el adaptador VPN o bloqueándolo a nivel de firewall. En 5 segundos: las consultas DNS deben detenerse, no regresar al resolver del ISP. Si ocurre replegamiento, el kill switch no está siendo efectivo.

Paso 4: prueba con navegador en sandbox

Repite la prueba en un perfil de navegador sin extensiones y con la configuración predeterminada. Las extensiones como uBlock Origin enmascaran el comportamiento WebRTC y DNS que puede existir en el navegador base. Probar el navegador en bruto revela a qué está expuesto un usuario sin extensiones protectoras con la misma configuración VPN.

Paso 5: prueba DoH aislada del navegador

Habilita el DoH integrado del navegador (en Firefox: Configuración → Privacidad y seguridad → DNS sobre HTTPS, establecer en Protección máxima con un resolver público). Vuelve a ejecutar dnsleaktest.com. Si el resolver mostrado cambia del resolver de la VPN a Cloudflare u otro resolver público, el DoH del navegador está eludiendo el DNS de tu VPN.

6. Comparación de herramientas

La siguiente tabla cubre las herramientas comúnmente usadas para la detección de fugas de red en 2026. "Detectado" significa que la herramienta prueba activamente ese tipo de fuga. "Perdido" significa que la herramienta no prueba o da cobertura incompleta.

Ninguna herramienta reemplaza el protocolo completo. Ejecuta las cinco para obtener una imagen completa.

7. Matriz de decisión por perfil de usuario

Para una revisión de clientes VPN por fiabilidad del kill switch y gestión de IPv6, consulta el análisis Mejor VPN para usuarios con conocimientos técnicos 2026.

Protocolo validado en 12 clientes VPN en Linux (Debian 12, Ubuntu 24.04), macOS 15.4 y Windows 11 24H2. Pruebas realizadas en junio de 2026. Cobertura de herramientas verificada manualmente; el comportamiento de las herramientas puede cambiar sin previo aviso — verifica en el momento de la prueba.

Lectura relacionada

• Estado de privacidad de los navegadores 2026
• DNS sobre HTTPS: implementaciones 2026
• Navegadores de privacidad 2026
• Mejor VPN para usuarios con conocimientos técnicos 2026