Tu VPN está conectada. El túnel está activo, el cliente dice protegido, y tu tráfico IPv4 pasa realmente por él. Y un sitio que visitas registra igualmente tu dirección real, porque te alcanzó por IPv6.
Aquí no hay ningún fallo que encontrar. Son dos sistemas correctos que no se ponen de acuerdo, y ese desacuerdo está escrito en una norma.
Tu sistema no se comporta mal, está aplicando la RFC 6724
Cuando un destino es accesible tanto por IPv4 como por IPv6, algo tiene que elegir. Ese algo es la RFC 6724, que define una tabla de política por defecto para la selección de direcciones. Tres de sus filas importan aquí:
Prefix Precedence Label
::1/128 50 0
::/0 40 1
::ffff:0:0/96 35 4
::/0 es IPv6 en general. ::ffff:0:0/96 es la forma en que las direcciones IPv4 se representan en esa tabla. Cuarenta gana a treinta y cinco, y la regla de selección de destino es explícita: si Precedence(DA) > Precedence(DB), entonces se prefiere DA.
La RFC enuncia la consecuencia en lenguaje llano en lugar de dejar que la deduzcas: otro efecto de la tabla de política por defecto es preferir la comunicación con direcciones IPv6 a la comunicación con direcciones IPv4, si hay direcciones de origen correspondientes disponibles.
Así que para cada sitio de doble pila que visitas, tu sistema operativo tira primero de IPv6. Es un comportamiento correcto, y es muy anterior a tu VPN.
Por qué eso se convierte en una fuga
Pon ahora encima una VPN que solo transporta IPv4.
Tu máquina conserva una dirección IPv6 nativa de tu operador. El túnel no reclama el tráfico IPv6, así que nada lo intercepta. Tu sistema, siguiendo la regla anterior, prefiere IPv6 para cualquier destino que lo ofrezca. El resultado es que tu ruta preferida es la que rodea el túnel, y la ruta protegida solo recibe lo que IPv6 no pudo servir.
Por eso la fuga pasa tan fácilmente inadvertida. No parece una avería. Tu VPN informa de conectado porque lo está. Tus comprobaciones IPv4 pasan porque pasan de verdad. El tráfico que se escapa es precisamente el que tu sistema juzgó mejor.
Comprobar, y el error que vuelve inútil la comprobación
La comprobación es sencilla: con la VPN conectada, mira qué ve realmente un sitio, y lee específicamente la línea IPv6 en lugar de echar un vistazo a la IPv4 y seguir adelante.
Si la dirección IPv6 mostrada pertenece a tu conexión en lugar de al proveedor de VPN, IPv6 está fuera del túnel. Si no aparece ninguna dirección IPv6, o tu red no la tiene o está bloqueada, y ambos casos son sanos desde el punto de vista de las fugas.
Dos cosas arruinan esta comprobación en la práctica:
Probar antes de conectarse. La pregunta no es qué aspecto tienes sin protección. Es qué se escapa mientras te crees protegido.
Probar una sola vez. Una configuración que hoy transporta IPv6 puede dejar de hacerlo tras una reconexión, un cambio de red o el paso de wifi a datos móviles, porque las direcciones disponibles cambian con la red. Un único resultado limpio demuestra que la configuración era correcta en una red y en un momento.
La línea que decide, en WireGuard
WireGuard hace la causa especialmente legible, porque el mismo ajuste decide a la vez qué entra y hacia dónde salen las cosas. El manual de wg define AllowedIPs como una lista de direcciones IP (v4 o v6) separadas por comas, con máscaras CIDR, desde las cuales se permite el tráfico entrante de este par y hacia las cuales se dirige el tráfico saliente de este par, y añade que el comodín 0.0.0.0/0 puede especificarse para todas las direcciones IPv4, y ::/0 para todas las direcciones IPv6.
Léelo como una instrucción de enrutamiento, porque es lo que es. Un par configurado solo con 0.0.0.0/0 dirige IPv4 al túnel y no dice nada de IPv6, que sigue usando la ruta normal. Añadir ::/0 dirige también IPv6 hacia él.
Se aplica una condición: el túnel necesita una dirección IPv6 propia para que esto sirva. Si tu proveedor no asigna ninguna, enrutar ::/0 a un túnel sin extremo IPv6 no crea conectividad IPv6. Es entonces cuando bloquear IPv6 pasa a ser el repliegue honesto y no un atajo.
Bloquear IPv6 funciona, y cuesta algo
Desactivar IPv6 en la máquina elimina la ruta preferida, así que todo cae en IPv4 y entra en el túnel. Es eficaz, y es lo que hacen varios clientes VPN bajo la etiqueta protección contra fugas IPv6.
El coste es real de todos modos. Pierdes IPv6 para todo lo demás en esa máquina, incluidas las redes donde es el único transporte utilizable, y el ajuste sobrevive al motivo que te llevó a cambiarlo. Seis meses después, un problema de conectividad sin relación se vuelve muy difícil de diagnosticar porque ya nadie recuerda que IPv6 estaba apagado.
Enrutar IPv6 por el túnel conserva la capacidad y resuelve el mismo problema. Prefiérelo siempre que tu proveedor lo permita, y trata el bloqueo como el repliegue para cuando no lo permita.
El kill switch no cubre esto
Conviene decirlo aparte, porque ambos se confunden en la misma pantalla de ajustes.
Un kill switch vigila que el túnel caiga y corta el tráfico cuando ocurre. Una fuga IPv6 sucede con el túnel activo. No hay caída que detectar, ni evento de fallo, ni nada a lo que el interruptor pueda reaccionar. Un kill switch que funciona a la perfección se quedará ahí haciendo su trabajo impecablemente mientras el tráfico IPv6 pasa por delante.
Si tu cliente ofrece protección contra fugas IPv6 como interruptor aparte, es un mecanismo distinto, y tener uno no te da el otro.
En resumen
Una fuga IPv6 no es tu VPN estropeándose. Es la RFC 6724 diciéndole a tu sistema que prefiera IPv6, un túnel que solo transporta IPv4, y la consecuencia perfectamente lógica de esos dos hechos.
Comprueba con la VPN conectada, lee la línea IPv6 y repítelo tras cambiar de red. En WireGuard, AllowedIPs es el ajuste que decide, y ::/0 es lo que dirige IPv6 al túnel. Donde el túnel no tenga IPv6 propio, bloquear IPv6 es un repliegue legítimo, con un coste que conviene anotar en algún sitio donde vayas a encontrarlo.
La tabla de política por defecto, los valores de precedencia, la regla de selección de destino y el enunciado de que la tabla prefiere la comunicación IPv6 a la IPv4 proceden de la RFC 6724. La definición de AllowedIPs y la notación comodín para 0.0.0.0/0 y ::/0 proceden de la página de manual wg(8). Ambas se consultaron en el momento de la redacción.
Guías relacionadas
- Auditoría de seguridad VPN completa - las siete comprobaciones que merece la pena hacer una vez, y esta es una de ellas.
- El kill switch de VPN explicado - el mecanismo que atiende el caso inverso, cuando el túnel cae de verdad.
Asegura tu conexión con NordVPN
Threat Protection bloquea rastreadores y malware · kill switch · 30 días de garantía
