Test completo de fugas VPN 2026: DNS, WebRTC, IPv6, MTU, kill switch - metodología unificada

Un VPN activo y técnicamente conectado no significa anonimato garantizado. Cinco vectores de fuga distintos pueden comprometer la confidencialidad de una sesión incluso con un túnel VPN aparentemente operativo: DNS (resolución de nombres fuera del túnel), WebRTC (exposición IP vía API navegador), IPv6 (tránsito en claro si no se bloquea), MTU (fragmentación y fuga de fragmentos en claro), kill switch defectuoso (tráfico en claro durante micro-cortes invisibles). Investigaciones independientes constatan regularmente que una parte notable de los setups VPN domésticos presentan al menos una fuga entre estos cinco vectores pese a un cliente VPN mostrando «protegido».

Esta guía consolida la metodología de prueba cubriendo las 5 dimensiones, con dos herramientas CLI open-source que mantenemos (dns-leak-detector-cli y webrtc-leak-detector), comandos shell reproducibles, y umbrales de validación a respetar. Se dirige a usuarios técnicos (admin sys, dev, seguridad) y a autónomos sometidos a RGPD artículo 32 que desean documentar verificación trimestral. Duración total del protocolo: ~30 minutos para setup doméstico estándar.

Por qué el test DNS solo ya no basta en 2026

El test fuga DNS estándar se ha vuelto insuficiente por dos razones técnicas precisas. Primera razón: la generalización de IPv6 entre los ISP europeos. Telefonica, Vodafone, Orange España, MásMóvil, Free, Deutsche Telekom despliegan masivamente IPv6 en sus enlaces fibra desde 2023-2024. En mayo de 2026, ~40 % de las conexiones fibra europeas disponen de stack dual-stack IPv4/IPv6 nativa. Si el cliente VPN no tuneliza explícitamente IPv6 (caso por defecto en algunas versiones OpenVPN sin parametrización específica), el tráfico IPv6 sale por la ruta por defecto ISP - fuga integral de identidad no detectada por test DNS clásico enfocado en IPv4.

Segunda razón: la prevalencia de WebRTC en navegadores modernos. WebRTC (Web Real-Time Communication) está activada por defecto en Chrome, Edge, Firefox, Safari para permitir llamadas vídeo integradas (Google Meet, WhatsApp Web, Microsoft Teams Web). La API RTCPeerConnection enumera los candidatos ICE (Interactive Connectivity Establishment) exponiendo la IP local Y la IP pública del dispositivo. En Chrome y Edge en 2026, aproximadamente 30 % de instalaciones exponen aún una IP local o pública distinta de la del túnel VPN, incluso con VPN activo. Esta fuga es invisible lado usuario (sin indicador navegador) y silenciosa lado VPN (el túnel sigue «conectado»).

A eso se suman las fugas por MTU mal calibrado (fragmentación provocando fugas de fragmentos en claro durante reassembly lado servidor) y los fallos kill switch (micro-cortes del túnel de 1-3 segundos en cambios de red WiFi/4G durante los cuales el tráfico pasa en claro por la ruta ISP por defecto).

Vector 1 - Fuga DNS: método detallado

La fuga DNS se produce cuando el cliente VPN no captura la totalidad de las consultas de resolución de nombres y deja al OS interrogar los resolutores ISP o públicos (8.8.8.8 Google, 1.1.1.1 Cloudflare) en paralelo. Consecuencia: estos resolutores ven pasar todas las consultas (dominios consultados), exponiendo un registro completo de actividad al ISP u operador público.

Test recomendado - dns-leak-detector-cli. Herramienta CLI Node.js que mantenemos en GitHub ricco020/dns-leak-detector-cli. Instalación y ejecución:

npx dns-leak-detector --resolver auto --hostnames 10 --verbose

El script resuelve 10 hostnames distintos (subdominios aleatorios) y analiza los resolutores que han tratado cada consulta lado servidor. Salida esperada: todos los resolutores identificados pertenecen al pool VPN del proveedor utilizado. Salida defectuosa: presencia de resolutores ISP (prefijos ASN conocidos AS3352 Telefonica, AS12479 Orange España, AS12715 Jazztel/MásMóvil) o resolutores públicos no-VPN (8.8.8.8 Google, 9.9.9.9 Quad9, 1.1.1.1 Cloudflare).

Tests web complementarios. dnsleaktest.com (test extended sobre 1000+ resolutores), browserleaks.com/dns. Ventaja: sin instalación. Inconveniente: se apoyan en consulta navegador, pueden enmascarar fugas sistema (OS) fuera del navegador.

Reparación si fuga detectada. En NordVPN: Settings → DNS → Use NordVPN DNS (activado por defecto). En Surfshark: Settings → Advanced → Custom DNS (desactivar, dejar auto). En ExpressVPN: automático. Si fuga persistente tras verificación cliente: comprobar que el OS no tiene resolutor DNS hardcoded (macOS Network Preferences → DNS, Windows Network Settings → Properties → IPv4 → DNS). Para VPN open-source (WireGuard manual), añadir explícitamente la directiva DNS = 10.0.0.1 (IP DNS interna del servidor VPN) en el fichero de configuración.

Vector 2 - Fuga WebRTC: la menos conocida

WebRTC expone vía la API JavaScript RTCPeerConnection.createOffer() el conjunto de candidatos ICE que incluyen: IP local (LAN privada 192.168.x.x, 10.x.x.x, 172.16-31.x.x), IP pública (salida de red vía STUN), a veces IPv6 nativa. Un sitio web malicioso o simplemente curioso puede interrogar estos candidatos en unos milisegundos sin permiso explícito del usuario.

Test recomendado - webrtc-leak-detector. Página HTML standalone ricco020/webrtc-leak-detector. Abrir en el navegador con VPN activo. El script recolecta candidatos ICE y compara con la IP esperada del túnel.

Salida esperada: solo la IP pública del servidor VPN visible. Ninguna IP local expuesta. Ninguna IP pública alternativa.

Salida defectuosa típica: IP pública del túnel + IP local de la LAN privada visible (fuga parcial, identifica la red local pero no el país), o IP pública del túnel + IP pública distinta del ISP (fuga integral, identifica el país real).

Reparación. En NordVPN: Settings → Advanced → activar «Block WebRTC». En Chrome: instalar la extensión WebRTC Control que desactiva los ICE candidates no tunelizados. En Firefox: about:config → media.peerconnection.enabled = false. En Safari: configuración más delicada, normalmente resuelta mediante activación del Block WebRTC lado cliente VPN.

Vector 3 - Fuga IPv6: 40 % de las fibras españolas afectadas

IPv6 es la zona de fuga más subestimada en 2026. Los ISP españoles (Movistar, Vodafone, Orange, MásMóvil) despliegan masivamente el dual-stack IPv4/IPv6 en fibra. Si el cliente VPN tuneliza IPv4 pero deja IPv6 salir por la ruta por defecto, toda petición a un servicio compatible IPv6 (Google, Facebook, Cloudflare, AWS) transita fuera del túnel.

Test directo CLI:

curl -6 https://ipv6.icanhazip.com --max-time 5

Salida esperada: o timeout (IPv6 bloqueado por VPN, configuración segura), o IP IPv6 perteneciente al pool VPN.

Salida defectuosa: IP IPv6 nativa ISP visible. Prefijos típicos: 2a02:9000::/24 Movistar/Vodafone, 2a01:e00::/27 Orange España, 2a02:1210::/26 SFR, 2003:a::/24 Deutsche Telekom.

Reparación. En NordVPN: Settings → Advanced → activar «Block IPv6». En Surfshark: auto por defecto desde v4.x. En ExpressVPN: Settings → Advanced → Block IPv6. Alternativa a nivel OS: Linux sysctl net.ipv6.conf.all.disable_ipv6=1, Windows Disable-NetAdapterBinding -ComponentID ms_tcpip6, macOS vía Network Preferences → desactivar IPv6 en la interfaz.

Vector 4 - MTU mal calibrado: fragmentación y fugas parciales

El MTU (Maximum Transmission Unit) define el tamaño máximo de un paquete IP transmitido sin fragmentación. En Ethernet estándar, MTU = 1500 bytes. Un túnel VPN añade overhead: ~80 bytes para WireGuard, ~28-50 bytes para OpenVPN UDP, hasta 70 para OpenVPN TCP con compresión. MTU efectivo túnel = 1500 - overhead.

Si el OS continúa enviando paquetes de 1500 bytes en un túnel con MTU 1420 efectivo, fragmentación: el paquete se divide en 2 fragmentos, transmitidos separadamente, reensamblados lado servidor destino. Consecuencias: rendimiento degradado (latencia +50-100ms típica), a veces pérdidas (los routers intermedios fragmentan mal IPv6), y según las implementaciones VPN una fuga de fragmentos en claro si el túnel rechaza los paquetes sobredimensionados (raro pero documentado en OpenVPN UDP con compresión activada).

Test directo CLI:

# Linux / macOS
ping -M do -s 1472 example.com

# Windows
ping -f -l 1472 example.com

Interpretación: 1472 bytes de payload + 28 bytes de cabecera ICMP/IP = 1500 total. Si el eco vuelve: MTU 1500 aceptable. Si «message too long»: bajar por escalones de 50 (1422, 1372, 1322...) hasta obtener el eco.

MTU óptimo según protocolo VPN: NordLynx / WireGuard 1420 típico, OpenVPN UDP 1450 típico, OpenVPN TCP 1430 típico, NordWhisper 1420 típico. Configurar este valor manualmente en la interfaz VPN si rendimiento degradado constatado.

Vector 5 - Kill switch defectuoso: micro-cortes invisibles

El kill switch es la última línea de defensa en caso de caída del túnel VPN. Existen dos modos: modo app (bloquea el tráfico de aplicaciones específicas) y modo sistema (bloquea todo el tráfico OS saliente). Solo el modo sistema es lo suficientemente robusto para garantizar la ausencia de fuga durante los micro-cortes de 1-3 segundos invisibles al usuario (cambio de red WiFi, pérdida 4G en metro, transición LTE↔5G).

Test reproducible:

# Terminal 1 - lanzar ping continuo a ipinfo.io
watch -n1 curl -s ipinfo.io | jq .ip

# Terminal 2 - desconectar bruscamente el VPN
sudo killall -9 nordvpn-daemon  # o equivalente según cliente

Salida esperada: el curl del terminal 1 falla inmediatamente con timeout/refused. Sin transición transparente a IP ISP. El kill switch ha funcionado.

Salida defectuosa: el curl continúa devolviendo una IP, pero ya no es la IP VPN - es la IP ISP real. El micro-corte ha dejado pasar el tráfico. Kill switch en modo app únicamente o no activado.

Reparación. En NordVPN: Settings → Kill Switch → activar Kill Switch (system-level) e Internet Kill Switch. En Surfshark: Settings → VPN settings → Kill switch (activado). En ExpressVPN: Network Lock (activado por defecto). Para VPN open-source (WireGuard manual), implementar el kill switch vía reglas iptables/nftables explícitas rechazando todo tráfico saliente no encapsulado wg0.

Documentar para conformidad RGPD artículo 32

Para autónomo o empresa sometido al RGPD, el test trimestral constituye una verificación razonable de la medida técnica VPN según el artículo 32. Documentación recomendada:

• Captura datada del resultado de cada test
• Archivado en vpn-tests/{fecha}/ con hash SHA-256 del fichero
• Línea en el registro de tratamientos: «Verificación trimestral ausencia de fuga VPN - último test DD/MM/AAAA»
• En caso de fuga detectada y corregida: anotar la fuga, la causa, la corrección aplicada y la fecha de retest

Esta documentación se solicita en caso de control AEPD o auditoría RGPD interna. Ver nuestra guía completa RGPD VPN autónomo para el contexto jurídico.

Lo que hay que recordar

Probar un VPN en 2026 ya no es un único check DNS - es una metodología unificada 5 dimensiones (DNS, WebRTC, IPv6, MTU, kill switch) que toma ~30 minutos y puede revelar fugas silenciosas que un test DNS estándar no ve. Herramientas open-source disponibles: dns-leak-detector-cli y webrtc-leak-detector, con comandos shell complementarios para IPv6, MTU y kill switch. Test trimestral obligatorio o en cada cambio de contexto (nuevo ISP, actualización OS, nuevo cliente VPN). Para RGPD artículo 32, documentar cada verificación con captura datada - prueba de diligencia razonable en caso de auditoría.

Disclosure: Eric Gerard es mantenedor de las herramientas open-source dns-leak-detector-cli y webrtc-leak-detector citadas en este artículo. No hay monetización directa de las herramientas - únicamente enlaces de afiliación NordVPN en el contenido editorial. Fuentes técnicas: RFC 4787 NAT behavior, RFC 5245 ICE, WireGuard whitepaper, W3C WebRTC specification.