¿Desactivar IPv6 para arreglar una fuga de VPN? Mejor decida la política
Una dirección link-local no es una fuga y una ruta global IPv6 tampoco. Elija primero entre bloquear, transportar y dejar en paz.
Una dirección del rango IPv6 aparece en una página de prueba, el túnel claramente no la transporta, y el consejo más popular de internet es desactivar IPv6 en todas partes. Ese comando sí calla el panel. También elimina un protocolo del que puede depender la red de acceso, y le deja sin idea de si la dirección era una fuga real, una dirección de interfaz link-local o un resolutor haciendo su trabajo. Tres condiciones deciden el control correcto, y solo una lleva a bloquear.
Identifique qué midió realmente la herramienta
La falsa alarma más común es una dirección link-local, que empieza por fe80: y existe en toda interfaz compatible con IPv6 tanto si la máquina alcanza internet por IPv6 como si no. Aparece en listados de interfaces y en algunos diagnósticos de aplicaciones, y no dice nada sobre la ruta de su tráfico.
La segunda falsa alarma es una dirección local única dentro de fc00::/7, que es un rango privado usado dentro de una red. Una herramienta que imprima todas las direcciones del equipo la listará encantada junto a la pública. Quien lee deprisa lo llama fuga y luego pasa una hora en un problema que no existe.
La tercera no es ninguna falsa alarma. Una dirección global que llega a internet fuera del túnel es la fuga real, y vale la pena medirla antes de decidir nada:
ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.coSi el primer comando imprime una dirección global y el tercero devuelve una dirección IPv6 pública que no es la del túnel, tiene una ruta real fuera del túnel. Si el primero no imprime más que entradas link-local, nunca hubo fuga que arreglar.
Tres condiciones deciden el control
La decisión no es "IPv6 bueno" o "IPv6 malo". Es en cuál de tres situaciones está, y cada una tiene una respuesta correcta distinta con un coste distinto si se equivoca.
| Situation | Correct control | Cost if you disable IPv6 instead |
|---|---|---|
| Exit has no IPv6, host does | Block IPv6 deliberately in the tunnel policy | Same visible result, no documentation of intent |
| Exit carries IPv6, host leaks | Route IPv6 into the tunnel and verify | You lose IPv6 reachability entirely |
| Access network is IPv6-only | Change nothing; use the tunnel's IPv6 | Machine loses connectivity completely |
La primera fila es lo que la gente suele querer decir, y es legítima. Un cliente cuya salida no admite IPv6 no debería dejar salir en silencio el tráfico IPv6 nativo del equipo, porque esa es la fuga documentada de pila doble. La cuestión es bloquearlo como política declarada, no desactivar un protocolo en el núcleo. El resultado visible es idéntico y solo uno de los dos puede revisarse después.
La tercera fila es donde el consejo general se vuelve activamente dañino. Los operadores móviles y algunas conexiones domésticas operan redes IPv6-only con traducción para destinos IPv4. Quite IPv6 allí y quitará el único transporte que ofrece la red, lo que produce una caída mucho peor que la que estaba depurando.
Si la salida no tiene IPv6, bloquéelo a propósito
Prefiera el mecanismo del propio cliente, porque se aplica exactamente mientras el túnel está activo y se revierte cuando cae. OpenVPN tiene una opción para esto, e iptables tiene una regla equivalente para otros clientes:
block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachableLa directiva pertenece al perfil; la regla pertenece a un cortafuegos que puede revisar y quitar. Ambas fallan cerradas, que es lo que quiere, y ambas se ven en un diff de configuración, cosa que un sysctl del núcleo enterrado en un script de arranque no hace.
Anote por qué está ahí. Una regla de bloqueo sin comentario la quita la siguiente persona que necesite IPv6 para algo no relacionado, y entonces la fuga vuelve en silencio.
Si la salida transporta IPv6, encamínelo y pruebe ambas familias
Transportar IPv6 es la respuesta mejor cuando el servidor lo admite, y no es mucho más difícil. El requisito es que la interfaz del túnel tenga una dirección en esa familia y que la ruta por defecto apunte hacia el túnel y no hacia la interfaz física:
ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.coLa consulta de ruta es la prueba decisiva: si nombra la interfaz del túnel, el tráfico IPv6 se está transportando. Las dos llamadas a curl confirman después qué ve cada familia, y compararlas es como se demuestra que ambos caminos salen ya por la misma salida.
No se detenga en una conexión correcta. Reconecte el túnel y compruebe de nuevo, porque una ruta IPv6 empujada puede perderse al restablecerse si el servidor solo la envía en la configuración inicial. Luego compruebe un destino excluido, porque las reglas de túnel dividido son donde las dos familias más a menudo discrepan.
Si la red de acceso es solo IPv6, déjela en paz
Algunas redes solo ofrecen IPv6 y esperan que el dispositivo llegue a servicios IPv4 mediante un mecanismo de traducción en el lado del operador. Desactivar IPv6 en una máquina así no es una mejora de seguridad; elimina la única ruta hacia cualquier cosa. Es una caída autoinfligida al servicio de un resultado de prueba que nadie necesitaba.
El síntoma de equivocarse aquí es inconfundible y desagradable: el túnel parece establecerse, la resolución de nombres funciona y no carga nada. Si lo ve tras un cambio de IPv6, restaure el ajuste de inmediato y siga el diagnóstico en otro sitio.
Elija lo que elija, mantenga la decisión explícita en el perfil o el cortafuegos, átela a lo que la salida realmente admite y anote el comportamiento de pila doble que describe el debate sobre pila doble del RFC 7359 . Un bloqueo declarado es una política. Un protocolo desactivado es un apaño que nadie puede auditar, y desde la página de prueba parecen idénticos.