Fugas de IPv6 y VPN en 2026: cómo cerrar todas las brechas sin perder velocidad

Por qué las fugas de IPv6 afectan la anonimidad justo ahora

Qué es el tráfico IPv6 y por qué a veces el VPN no lo cubre

IPv6 hace tiempo que no es teoría. En 2026, su adopción global supera el 44-48% del tráfico, y en varios países las redes móviles ya funcionan con modelo IPv6-only usando NAT64 y DNS64. Suena bien en papel, pero hay un detalle: muchos escenarios VPN están diseñados históricamente para IPv4 y simplemente ignoran IPv6 si no activas explícitamente su soporte. Así, algunas aplicaciones siguen comunicándose por IPv6 fuera del túnel, como si no hubiese VPN. Silenciosamente, sin errores visibles. Eso es una fuga pura.

Un ejemplo sencillo. Activás tu VPN, ves la nueva dirección IPv4 del proveedor, te relajas y abres el navegador. El sitio solicita un registro AAAA y conecta por IPv6 directamente a través de tu ISP. Tu IP real queda expuesta, las cookies están intactas y tú piensas que estás protegido. En otra pestaña, WebRTC envía una solicitud STUN y revela tu IPv6 global. Los gráficos parecen bien, pero en realidad tu privacidad no existe. Frustrante, ¿verdad?

Dónde se generan las fugas: dual-stack, Happy Eyeballs, QUIC y WebRTC

Hay varias causas. El stack de red en 2026 usa mucho la estrategia Happy Eyeballs: el cliente prueba IPv4 y IPv6 en paralelo, y gana el que responde más rápido. Si tu VPN sólo protege IPv4, gana el acceso directo por IPv6. Otro punto es que las apps modernas usan HTTP/3 sobre QUIC que corre sobre UDP, y varios clientes VPN filtran mal el tráfico UDP saliente con destinos ::/0 si los filtros están mal configurados. Y la cereza del pastel: WebRTC. Aun sin hacer videollamadas, el navegador puede hacer intercambios STUN y mostrar tu IPv6 real.

Un detalle con DNS. Cuando el sistema o navegador usan DNS cifrado, como DoH o DoQ, pueden enviar consultas AAAA saltándose la configuración del VPN o del resolutor del sistema. La respuesta DNS señala al navegador la dirección IPv6 y la conexión se establece directa. No es magia, es cómo prioriza el transporte. Además, apps UWP y PWA a veces tienen su propio stack de red que no sigue completamente las políticas globales del cliente VPN. Al final creerás que todo está en el túnel, pero algunos paquetes se escapan.

Riesgos de las fugas: desanonimización, geolocalización, vigilancia y bloqueos

Una fuga de IPv6 es preocupante por varias razones. Primero, conecta tus acciones instantáneamente con el espacio de dirección de tu proveedor, que implica ubicación, jurisdicción y posibles logs. Segundo, rastreadores y redes publicitarias no son tontos: si ven un IPv6 constante, enlazan sesiones y dispositivos aunque cambie el IPv4 del VPN. Tercero, bloqueos corporativos o gubernamentales a veces aplican sobre IPv6, y acabas en filtros justos cuando deberías pasar desapercibido.

Finalmente, el problema estructural del NAT. En IPv4, el NAT te oculta tras una IP compartida, mientras que IPv6 fue diseñado sin NAT. Muchas redes domésticas reciben prefijos /56 o /64 y cada equipo tiene una IP globalmente enrutable. Sí, hay direcciones temporales y privacidad según RFC, pero si el tráfico elude el VPN, expones tu identificador global. No es un desastre total, pero sí un resquicio que hay que cerrar ya.

Bloquear o tunelizar IPv6: eligiendo estrategia

Dos caminos: apagar IPv6 o llevarlo por el VPN

Hay dos estrategias básicas contra fugas. La primera, más sencilla, es desactivar IPv6 completamente en los interfaces o en el kernel y dejar sólo IPv4 por el VPN. Funciona confiable y rápido, pero tiene sus contras: algunas webs y redes móviles en 2026 esperan IPv6 y pueden degradarse; además algunas apps requieren QUIC sobre IPv6. La segunda es más elegante: activar soporte IPv6 real dentro del túnel. Ahí tienes una IP IPv6 del servidor VPN, rutas ::/0 dentro del túnel y reglas estrictas de firewall afuera.

¿Cuál elegir? Si sólo quieres eliminar el riesgo en escritorio sin perder funcionalidad, desactiva IPv6 temporalmente. Si buscas máxima compatibilidad, es mejor que tu VPN transporte ambos protocolos. Es más complejo, requiere soporte del proveedor, pero evitarás problemas futuros con servicios y redes. Eso sí, tomar medias tintas como bloquear algunos prefijos sólo da una falsa sensación de seguridad.

Mecanismos técnicos: firewall, policy routing y blackhole

Cuando bloqueas IPv6 localmente, hay varios métodos fiables. El más básico es deshabilitar el stack en el sistema. El segundo, usar firewall para dropear todo el tráfico inet6 saliente en interfaces físicas salvo el VPN. El tercero, crear ruta por defecto ::/0 a blackhole para que todo paquete IPv6 se pierda si no hay túnel activo. Algunas veces se usa policy-based routing: marcar paquetes con tags y dirigirlos sólo al interfaz VPN, descartando el resto.

Si tunelizas IPv6, las reglas son espejadas. Añades rutas ::/0 al interfaz del túnel, recibes IPv6 del proveedor VPN y bloqueas con firewall cualquier inet6 saliente fuera de ese interfaz. En WireGuard se configuran AllowedIPs como 0.0.0.0/0, ::/0 y regla killswitch. En OpenVPN, tun-ipv6 y redirect-gateway ipv6. No olvides DNS: el resolutor debe entregar registros AAAA y enviar consultas DNS por el túnel, o el tráfico escapes otra vez.

Rendimiento y sobrecarga

En velocidad, bloquear IPv6 correctamente casi no cuesta nada, sobre todo si lo haces a nivel de kernel y tablas de rutas. Tunelizar IPv6 tiene la misma sobrecarga que IPv4, usualmente un 3-7% extra de CPU para cifrado y procesamiento, más en chips ARM antiguos. En 2026, WireGuard en escritorio y routers con offload funciona muy rápido, así que la «pérdida de velocidad» es más un mito que un problema real.

Hay un detalle con tiempos de conexión. Si configuraste mal Happy Eyeballs, el cliente puede intentar IPv6 fuera del túnel y esperar el timeout mientras el firewall dropea el paquete. Esto causa demoras de algunos segundos al abrir sitios. La solución es enrutar correctamente ::/0 por el túnel o poner blackhole, y no confiar sólo en una regla bloqueadora aislada en alguna app. Así la conexión o va bien, o no va, sin colgados.

Windows 10, 11 y 12: protección práctica contra fugas de IPv6

Desactivar IPv6 rápidamente: interfaz gráfica y PowerShell

En Windows puedes desactivar IPv6 de dos formas. La más sencilla: Red e Internet, Cambiar opciones del adaptador, propiedades del interfaz, desmarcar Internet Protocol Version 6. Funciona pero no siempre afecta interfaces túnel o virtuales. Más fiable es el flag DisabledComponents en el registro, aunque Microsoft recomienda cautela en 2026. Lo mejor es usar PowerShell y netsh para evitar medias tintas.

Comandos rápidos. PowerShell como administrador: Disable-NetAdapterBinding -Name "Ethernet" -ComponentID ms_tcpip6. Repite para Wi-Fi. O globalmente: netsh interface ipv6 set teredo disabled, netsh interface ipv6 set privacy state=enabled y si quieres radicalmente, Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" -Name DisabledComponents -Type DWord -Value 0xff. Tras reiniciar IPv6 queda off. Pero no exageres: si tu VPN soporta IPv6, mejor configura rutas y firewall.

Filtrado con Windows Defender Firewall y WFP

Para no depender de casillas, crea reglas estrictas en el firewall. Windows Defender Firewall permite definir reglas de salida que bloquean todo TCP y UDP para perfiles Private y Public en familia IPv6, excepto en el interfaz VPN. No es obvio en interfaz gráfica, pero con netsh se hace así: netsh advfirewall firewall add rule name="Block IPv6 out" dir=out action=block protocol=any profile=any interfacetype=any remoteip=any localip=any edge=yes. Luego crea regla que permita el interfaz VPN con direcciones ::/0. Aplica en orden: primero deny all, después allow para VPN.

Para precisión total usa políticas WFP con clientes especializados o políticas de grupo. Filtran en nivel de drivers y bloquean IPv6 antes de que salga del stack. En WireGuard verifica que AllowedIPs incluya ::/0 y que el modo killswitch esté activo para bloquear todo tráfico fuera del túnel. En OpenVPN usa block-ipv6 si tu proveedor no soporta IPv6, o tun-ipv6 y redirect-gateway ipv6 si sí.

DNS y modos Always-on VPN

Un detalle común que rompe todo es el DNS. Windows 11 trae DoH nativo y algunas builds en 2025-2026 prueban DoQ. Asegúrate que el DNS cifrado pase por VPN. Chequea Encrypted DNS en configuración de red, elige proveedor en la lista o activa 'Automático por red actual' si tu cliente VPN provee resolutor propio. Si no, las consultas AAAA saldrán fuera del túnel y aparecerás directo por IPv6.

Otra buena práctica es activar Always-on. En Windows se logra tanto por configuración del cliente VPN como por políticas MDM en empresas. Siempre activa kill switch. Sin él, al reconectarse o en suspensión, el sistema vuelve al IPv6 directo y algunas consultas se escapan. Es como dejar la ventana abierta en invierno: la casa está caliente pero sientes el frío de inmediato.

macOS e iOS: cuidado con PF y perfiles

Desactivar IPv6 y elegir interfaz

macOS cuida bien las redes, pero por defecto usa IPv6. Un paso básico es: networksetup -setv6off Wi-Fi y repetir para Ethernet. Esto apaga IPv6 en servicio específico sin romper todo el stack. Para reactivarlo usa -setv6automatic. En iOS no hay botón para desactivar IPv6, el sistema decide solo. Por eso, si quieres seguridad total, opta por tunelizar IPv6 en el adaptador VPN y no por prohibirlo en la plataforma.

Si el proveedor VPN soporta IPv6, asegúrate que el interfaz utun tenga dirección del proveedor y ruta ::/0. Muchos clientes WireGuard en macOS e iOS desde 2025 agregan AllowedIPs ::/0 correctamente y respetan killswitch. Revisa prioridad de servicios con networksetup -listnetworkserviceorder y pon VPN arriba de Wi-Fi y Ethernet para evitar líos del sistema.

PF: reglas simples drop inet6

Para control estricto activa PF. En /etc/pf.conf añade líneas como block out on en0 inet6 all y block out on en1 inet6 all, permitiendo pass out on utun0 inet6 from any to any. Carga reglas con sudo pfctl -f /etc/pf.conf y habilita PF con sudo pfctl -e. Así aseguras que IPv6 no salga fuera del túnel. En desktop es un práctico equilibrio: no rompes el stack completo pero pones una puerta de hierro donde importa.

Recuerda que macOS usa servicios Apple como iCloud Private Relay, Handoff, AirDrop. Private Relay puede usar mecanismos propios para cifrar tráfico. Si quieres control total, desactívalo, o la detección de fugas será más difícil. No porque sea malo, sino porque mezcla canales. Primero logra estabilidad en VPN, luego activa extras y vuelve a probar.

DNS y cifrado: DoH, DoQ y resolutores

Safari y sistema en 2026 soportan DNS cifrado. Eso quiere decir que tu resolutor puede usar DoH o DoQ directamente si el perfil lo indica. Con perfiles corporativos o personalizados revisa qué resolutores hay en cada servicio de red. Si DoH corre en Wi-Fi y el cliente VPN no lo intercepta, tendrás AAAA fuera del túnel.

La regla es simple: el resolutor debe funcionar dentro del túnel. O bloqueas todas las conexiones DNS fuera de la VPN, o configuras el cliente para que publique el resolutor del sistema y Safari lo use. Parece tedioso, pero cuando ves una pequeña fuga en modo suspensión, entiendes por qué insistimos tanto en el DNS.

Linux: sysctl, nftables y WireGuard inteligente

Desactivación global y selectiva de IPv6

En Linux la forma más directa es sysctl. Crea /etc/sysctl.d/99-noipv6.conf con net.ipv6.conf.all.disable_ipv6=1 y net.ipv6.conf.default.disable_ipv6=1, luego ejecuta sysctl -p. Así apagas IPv6 en todas partes. Si quieres granularidad, desactiva solo en interfaces físicas con net.ipv6.conf.eth0.disable_ipv6=1 y deja activo en tun0 o wg0 para mantener túnel funcionando. A veces se usa ipv6.disable=1 en GRUB, pero es un martillo: bueno para servidores, menos para laptops.

Para control fino sirve ruta blackhole: ip -6 route add blackhole ::/0 metric 1000. Corta cualquier IPv6 saliente a menos que exista ruta más prioritaria en el túnel. Es mejor que confiar en una regla firewall única y funciona bien con policy routing. Si usas NetworkManager, guarda métricas y evita que añada rutas IPv6 automáticas en interfaces físicas.

nftables: reglas rígidas

nftables permite bloquear fugas con elegancia. Ejemplo: table inet filter { chain output { type filter hook output priority 0; policy accept; oifname "wg0" accept; ip6 daddr ::/0 drop; } }. Lógica simple: permite todo en wg0, bloquea cualquier otro IPv6 saliente. Similar en input si no esperas entrantes. Si tunelizas IPv6 cambia política por defecto a drop, permite en wg0 IPv4 e IPv6 con inspección conntrack para no romper respuestas.

WireGuard sigue siendo el rey de la velocidad en 2026. En config cliente pon AllowedIPs = 0.0.0.0/0, ::/0 para túnel completo. Añade Table = off y PolicyRouting para control manual. No olvides PersistentKeepalive, especialmente en redes móviles IPv6-only con NAT64, para evitar que el túnel se duerma. Y recuerda reglas oifname en nftables como killswitch. Para OpenVPN revisa tun-ipv6, redirect-gateway ipv6, route-nopull y push selectivo si tu proveedor entrega rutas personalizadas.

DNS: systemd-resolved, resolvconf y proxy DoH

En distros modernas domina systemd-resolved. Asegura que wg0 registre DNS con resolvectl dns wg0 10.8.0.1 y que las dominios estén bien configurados. Mejor apagar automágico en interfaces físicas con ignore-auto-dns yes en NetworkManager y configurar resolutor manualmente. Sino, consultas AAAA pueden ir al DNS de tu ISP e indicar al navegador un IPv6 directo.

Si quieres cifrar DNS, levanta proxy local DoH o DoQ dentro del túnel: cloudflared, dnsproxy, dnscrypt-proxy. Crucial que salgan hacia upstreams por wg0, si no se escapan. Chequeo simple: curl -6 https://tu-dns y tcpdump -i eth0 no debería mostrar paquetes DNS a puertos 853 o 443 fuera del túnel.

Android: redes IPv6-only y Always-on VPN

VPN siempre activo y túnel completo

Android lleva años funcionando cómodo en redes IPv6-only. Eso significa que sin un VPN correcto tu tráfico saldrá por IPv6 vía NAT64 y no quieres fugas. Activa Always-on VPN y opción Bloquear conexiones sin VPN. Es un killswitch integrado que corta todo si el túnel cae. El cliente WireGuard en Android soporta AllowedIPs ::/0 y 0.0.0.0/0, hazlo túnel completo, no dividido.

Algunas apps usan DNS propio o QUIC, verifica que el VPN tenga bloqueo de LAN local y filtro IPv6. En Android 13-15 el DNS privado está activo por defecto. Configúralo para usar una dirección sólo accesible por túnel o déjalo en Automático si el VPN maneja el resolutor. Si no, consultas AAAA van directo y tiras tu privacidad de un clic.

ADB, OEM y trucos extra

No hay opción estándar para apagar IPv6 en Android. Teóricamente puedes usar ADB y cambiar sysctl en dispositivos rooteados, como net.ipv6.conf.all.disable_ipv6=1. Pero en 2026 es poco común: mejor hacer túnel con IPv6 y reglas estrictas en el cliente. Algunos firmwares OEM meten optimizaciones que retrasan el tráfico antes del VPN. Por eso Always-on y bloqueo sin VPN son imprescindibles.

Checa WebRTC en navegadores móviles. En configuración desactiva mDNS y candidatos directos si existe opción, o usa extensiones donde se soporten. Son pasos pequeños, pero quitan otra fuga visible de IPv6. Y siempre prueba tanto Wi-Fi como LTE o 5G. Muchas veces en casa todo bien, pero al salir aparece fuga por red móvil.

DNS privado y QUIC

Android ama la velocidad e incluye QUIC siempre que puede, especialmente en servicios Google y mensajería. Si tu firewall o cliente VPN no controla UDP, las fugas ocurren en silencio. Configura en el cliente la prohibición de UDP saliente fuera del túnel, menos el DNS local dentro de VPN. Para DNS privado usa un nombre que se resuelva sólo por el túnel; así evitas conexiones directas. Sí, requiere algo de trabajo, pero vale la pena.

Routers: OpenWrt, MikroTik y Ubiquiti

OpenWrt: RA, DHCPv6 y routing político

En OpenWrt, las fugas suelen venir de anuncios RA y DHCPv6. Si no quieres IPv6 hacia afuera, desactiva envío RA en LAN, bloquea prefijo del proveedor y dropea ip6 en firewall. Fácil. Pero mejor aún: usa VPN que gestione IPv4 e IPv6 y asigne direcciones por DHCPv6-PD desde la pool del proveedor VPN. Así los navegadores no adivinan y Happy Eyeballs funciona a tu favor.

En política: instala paquetes policy-based routing, marca tráfico LAN y envíalo solo por VPN. Añade blackhole ::/0 en tabla principal para evitar salidas sin túnel. Para WireGuard en OpenWrt pon AllowedIPs ::/0 y option route_allowed_ips 1. En comentarios de firewall deja notas para que entiendas la configuración pasado un mes. Documentar el config es tu mejor aliado.

MikroTik RouterOS v7: configuración fina de IPv6

En MikroTik IPv6 tiene stack propio. Antes muchos borraban paquete ipv6, pero en v7 es exceso. Configura firewall con chain=forward family=ipv6 action=drop, exceptuando interfaces WireGuard o IPsec usados. Pon ruta ::/0 al interfaz VPN y alta métrica para externas. En mangle marca paquetes salientes LAN y envíalos a tabla policy routing con ruta única vía VPN.

No olvides ND y RA. Apaga anuncios en LAN si no provees direcciones desde VPN. Si lo haces, verifica que el prefijo venga de proveedor VPN y que se anuncie bien. Esto ayuda a olvidar la palabra «fuga». Y activa fasttrack con cuidado: puede saltarse reglas si no excluyes interfaz WireGuard.

Ubiquiti: EdgeRouter y UniFi

En EdgeRouter la lógica es similar: configura firewall IPv6, bloquea tráfico saliente WAN, permite túnel. En tabla de rutas pon ::/0 vía interfaz VPN. En UniFi UX agrega reglas a nivel de redes y clientes. Revisa cómo el controlador distribuye DNS: puede dar resolutores externos. Cámbialos por internos vía VPN o monta resolutor local que se conecte por túnel.

Pon a prueba bien redes Wi-Fi para invitados. Ahí suelen activar aislamiento de clientes y DNS propios que evaden políticas globales. Un checkbox olvidado y los móviles invitados iluminan su IPv6 fuera del VPN. No dejes que la casualidad te gane.

Pruebas: cómo asegurarte de que no hay fugas

Chequeo en navegador: direcciones, WebRTC y extensiones

Empieza fácil. Busca «qué IP tengo» y mira qué direcciones ve la página: IPv4 del VPN y sin IPv6 directo. Abre herramientas de desarrollo y checa los logs de red. Si ves consultas AAAA a resolutores fuera del túnel, hay problema. Prueba WebRTC en páginas específicas, te mostrará candidatos locales y globales. Si el global IPv6 es de tu proveedor, tu configuración está incompleta.

Desactiva en navegador el cambio automático a DoH si no lo tienes dirigido por VPN. En Chrome, Secure DNS debe apuntar a resolutor accesible por túnel. En Firefox usa modo que siga ajustes del sistema o define uno propio. Sí, es molesto. Pero si haces una lista de verificación una vez, luego la haces en cinco minutos.

CLI: curl, dig, ping6 y tcpdump

En terminal todo es transparente. Ejecuta curl -4 https://example.test y curl -6 https://example.test. El primero debe pasar por VPN, el segundo o pasa por VPN o falla si bloqueas IPv6. Usa dig AAAA dominio y observa qué resolutor responde. traceroute -6 dirección muestra si la ruta sale directo. tcpdump -i interfaz ip6 te alerta de tráfico IPv6. Si ves paquetes en eth0 fuera del túnel, hay fuga. Ajusta reglas y repite.

En Windows usa Test-NetConnection -ComputerName dominio -TraceRoute -InformationLevel Detailed y netsh trace start capture=yes report=no. En macOS revisa nettop -m tcp y logs del filtro de paquetes. En Android sin root es más complejo, pero compara capturas de apps de test y estadísticas del cliente VPN. No esperes una bala de plata, busca constancia, así el resultado es predecible.

Automatización y alertas

Si la seguridad es clave, automatiza. En Linux un script corre cada cinco minutos curl -6 a host de control por túnel y verifica respuesta y interfaz. Otro escucha tcpdump en interfaz física y lanza alerta si detecta IPv6. En Windows un script PowerShell revisa ruta ::/0 y reglas firewall. No es ciencia espacial, es simple monitoreo de "luces de tablero". Y sí, salva cuando alguien actualiza drivers y borra tu configuración.

En empresas organiza auditorías regulares. Cada trimestre ejecuta pruebas en laptops, teléfonos y routers. Actualizaciones de sistema y cliente VPN pueden romper todo: llega una función DoQ y voilà, AAAA afuera del túnel. Lista de chequeo rutinaria siempre es más barata que un incidente. Economía sencilla.

Casos 2024-2026: experiencia sin relleno

Portátil corporativo y túnel dividido

La empresa permite sólo apps de negocios por VPN y todo el resto directo. En teoría lógico, en práctica Teams y Zoom usaron QUIC sobre IPv6 y parte del tráfico salió fuera del túnel. IPs externas aparecieron en logs de socios. La solución fue pasar a túnel completo, activar IPv6, añadir regla en Firewall Windows bloqueando IPv6 fuera del VPN, y deshabilitar QUIC forzado en videollamadas. Resultado: misma velocidad, sin fugas, usuarios ni se dieron cuenta.

Lección clara. El split-tunnel en 2026 demanda catálogo preciso de dominios, protocolos y transportes. Si tu equipo no puede mantener ese zoológico, mejor túnel completo y enrutar bien. Aburrido pero efectivo. Y menos estrés.

Router del proveedor y teléfonos Wi-Fi en casa

Escenario común: el proveedor entrega router con RA y DHCPv6 activados, el usuario pone cliente VPN en laptop, pero teléfonos por Wi-Fi siguen por IPv6 directo. Resultado: comportamiento dispar y publicidad basada en geolocalización inesperada. Solución: en router apaga RA en LAN, configura OpenWrt con WireGuard y DHCPv6-PD del túnel, bloquea ip6 en red guest y en la principal permite solo por VPN. Así todos los dispositivos tienen política única y las fugas quedan atrás.

Importante: los teléfonos no siempre respetan resolutor del sistema si activas DNS privado. Ajusta el DNS privado al nombre accesible sólo por VPN y revisa AAAA desde ahí. Así evitarás adivinar quién y por dónde se conecta de noche.

Red móvil IPv6-only y NAT64

El operador migró usuarios a IPv6-only con NAT64. Un usuario activó VPN sin soporte IPv6, y notó que apps fallaban y tráfico se escapaba. La solución fue activar IPv6 en VPN, permitir ::/0 en WireGuard, confirmar que el resolutor entrega A y AAAA, y si es necesario usar DNS64 dentro del túnel. También activaron PersistentKeepalive para evitar suspensiones del túnel. Resultado: todos los servicios funcionan, sin fugas y con latencias estables.

Conclusión: la era de "apagamos IPv6 y listo" en móviles termina. Hay que convivir con IPv6, pero bajo tus reglas, via VPN y con normas claras.

Listas de verificación y mejores prácticas 2026

De prohibir a gestionar IPv6

Paso 1: si entras en pánico, apaga IPv6 en interfaces físicas temporalmente. Paso 2: elige proveedor VPN con soporte IPv6 y túnel completo. Paso 3: cambia estrategia, activa IPv6 en túnel y bloquea fuera. Paso 4: ordena el DNS: solo resolutor por VPN, cifrado opcional pero recomendable. Paso 5: haz pruebas en navegador, CLI y tcpdump. Y por último, documenta todo para no reinventar la rueda mañana.

Este camino es sencillo y seguro. Empiezas con interruptor grueso y acabas con red controlada que convive con el futuro. Sí, lleva uno o dos días, pero luego duermes tranquilo sin perseguir «pérdidas de velocidad» o «cuelgues aleatorios».

Elegir proveedor y cliente VPN

En 2026 los mínimos son: soporte IPv6 en túnel, WireGuard con killswitch, publicación DNS correcta, opción de forzar DoH y DoQ por VPN, reglas avanzadas para bloquear salidas por interfaz. Que tenga auditorías y políticas transparentes suma mucho. Si el proveedor dice «IPv6 pronto» desde hace tres años, busca otro. El mundo avanza y IPv6 es medio de transporte, no lujo.

El cliente debe prohibir tráfico fuera del túnel, poner rutas ::/0, gestionar prioridades, mostrar interfaces y logs claros del tráfico. Prueba fácil: apaga internet y observa si cliente se queda sin conexión o manda algo afuera. Si empieza a enviar paquetes, no es cliente confiable.

Monitoreo y auditorías periódicas

Lo ideal es convertir la comprobación de fugas en rutina. Scripts, reportes y alertas. Cada trimestre chequeo completo. Tras grandes actualizaciones prueba rápida. En routers, revisa rutas y reglas. En navegadores, control de perfiles. Suena aburrido, pero es como el cinturón de seguridad: molesta al principio, luego salva vidas. Y no es exageración.

No olvides capacitar usuarios. Un par de diapositivas sobre cómo debería verse un IP normal en pruebas, cómo chequear WebRTC y a quién pedir ayuda si algo falla. Diles que DNS privado sin VPN no es privacidad. La gente entiende, solo necesitan las herramientas adecuadas.

Errores comunes y cómo evitarlos

Apagar IPv6 «en general» y romper servicios

Desactivar IPv6 a nivel kernel a veces rompe portales corporativos, CDN nuevos y apps móviles. No te sorprendas. Si puedes, avanza a modelo «IPv6 solo dentro del VPN». Así mantienes compatibilidad y evitas fugas. Si desactivas globalmente, guarda backups y plan de reversión. Mejor ser cauteloso de día que héroe a medianoche.

Otro error: olvidarse del router. Apagas IPv6 en laptop pero TV y teléfono iluminan la IP global via Wi-Fi. Al final el tracking sigue funcionando. Aplica política única en casa u oficina. Es disciplina que paga dividendos.

Fugas de DNS por DoH y DoQ

El navegador activa DoH a un resolutor público y todo tu plan se viene abajo. Revisa configuración: DNS seguro debe estar bajo control. En Windows y Android pon el proveedor en sistema o desactiva forzado automático si no pasa por túnel. En macOS verifica que el perfil de red apunte resolutores dentro del VPN. Si no puedes, levanta proxy DoH local en túnel.

Otro tema: resolutores paralelos. El sistema puede tener varias IP y las apps usan distintas. Solución: un punto único, resolutor local en sistema que salga por VPN. Así no sufres caos de configuraciones heterogéneas.

Problemas con rutas ::/0 en WireGuard

A veces pones AllowedIPs ::/0 pero el tráfico sigue filtrándose. Revisa que no tengas Table = off sin policy routing configurado. Si está así, las rutas no se aplican. También revisa prioridades de métricas. Si la física es más baja, el sistema la prefiere. Sube métrica física o baja la del wg0. Y activa reglas nftables que droppeen IPv6 fuera del wg0. Esa es tu última defensa.

También vimos casos de blackhole ::/0 en tabla incorrecta. Comando acierta pero efecto no. Aprende a leer ip -6 rule y ip -6 route show table all. Una mirada y entiendes. Es como mirar el tablero: velocidad, revoluciones y gasolina están, puedes andar.

FAQ: directo y claro

¿Es necesario apagar IPv6 completamente para evitar fugas?

No siempre. Lo más seguro y moderno es tunelizar IPv6 dentro del VPN y bloquearlo fuera. Apagar completo sirve como medida temporal si tienes prisa o tu VPN no soporta IPv6. Pero en 2026 cada vez más servicios quieren IPv6, mejor que seas amigo, no enemigo.

Si temes complicaciones, empieza simple: apaga IPv6 en interfaces físicas, prueba, luego actívalo dentro del túnel. Conforme ganes confianza, pasa a modelo gestionado. Es evolución, no salto al vacío.

¿Cómo saber si mi IPv6 se está filtrando ahora?

Haz dos pasos. En navegador mira si el sitio ve tu IPv6 y si coincide con la IP del VPN. En terminal corre curl -6 a un recurso conocido y revisa ruta con ip -6 route get dirección. Si sale por interfaz físico, hay fuga. También corre tcpdump en interfaz físico y espera cualquier paquete IPv6 — indicador claro.

No olvides WebRTC. Revisa candidatos en test de navegador o ajustes. Si aparece IPv6 global del proveedor, configuración incompleta. Corrige firewall y DNS.

Mi proveedor VPN no soporta IPv6. ¿Qué hacer?

Tres opciones. Desactiva IPv6 en dispositivos temporalmente. Crea reglas firewall estrictas que dropeen IPv6 fuera del túnel. Y considera cambiar a proveedor que entregue IPv6 en túnel. En 2026 es higiene básica, sobre todo en redes móviles y nuevos servicios multimedia.

Si cambiar no es opción, mantén lista de chequeo y automatización. Scripts que detecten IPv6 en interfaz física y alertas. Que el sistema avise si algo falla. Es pequeño pero real compromiso.

¿El bloqueo de IPv6 afecta la velocidad?

Si sólo dropeas IPv6 fuera del túnel o lo mandas a blackhole, el impacto es mínimo. Problemas surgen si generas timeouts: el cliente intenta IPv6, paquete se pierde y espera antes de cambiar a IPv4. Se arregla con rutas ::/0 correctas por túnel o blackhole con métrica adecuada.

Tunelizar IPv6 consume lo mismo que IPv4, especialmente en WireGuard. En CPUs modernos la diferencia es estadística. Más importante es la estabilidad de rutas y cero «parpadeos».

¿Hay que desactivar DoH y DoQ para seguridad?

No hace falta desactivar DNS cifrado si puedes forzarlo a pasar por VPN. Mejor cifrar que no. El problema no es DoH o DoQ, sino que a veces van fuera del túnel. La regla es que el resolutor esté dentro y cualquier intento fuera se bloquee. Eso no se discute.

Si no puedes configurarlo ahora, desactiva DoH en navegador hasta asegurarte que pasa sólo por VPN. Luego vuelve a activarlo y tendrás privacidad y orden.

¿Qué hacer con WebRTC si usas videollamadas diarias?

Desactivar WebRTC no es opción si llamas a diario. La solución: que WebRTC dé candidatos sólo dentro del túnel. Con IPv6 en VPN usará dirección del túnel y no tu global. Además bloquea candidatos locales directos si no afecta funcionalidades.

En empresa monta TURN servers sólo accesibles por VPN y asegura que clientes no puedan atravesar UDP desde afuera. Es política más estricta, pero elimina fugas y sorpresas.

¿Por qué es problemático el "split-tunnel" en 2026?

No es malo en sí, pero exige disciplina y vigilancia. Cuando parte del internet va directo y parte por VPN tienes un rompecabezas de dominios, protocolos y puertos. Suma IPv6, QUIC y DoH, y tendrás un sistema donde la fuga es estadística inevitable.

Si no tienes equipo para mantener reglas y monitorear, mejor túnel completo con excepciones listadas. Aburrido, pero seguro. Al final importa el resultado, no la poesía de las reglas.