Desactivar IPv6 para arranxar unha fuga de VPN? Mellor decidide a política
Un enderezo link-local non é unha fuga e unha ruta global IPv6 tampouco. Escollede primeiro entre bloquear, transportar e deixar en paz.
Un enderezo do rango IPv6 aparece nunha páxina de proba, o túnel claramente non o transporta, e o consello máis popular de internet é desactivar IPv6 en todas partes. Ese comando si cala o panel. Tamén elimina un protocolo do que pode depender a rede de acceso, e déixavos sen idea de se o enderezo era unha fuga real, un enderezo de interface link-local ou un resolvedor facendo o seu traballo. Tres condicións deciden o control correcto, e só unha leva a bloquear.
Identificade que mediu realmente a ferramenta
A falsa alarma máis común é un enderezo link-local, que comeza por fe80: e existe en toda interface compatible con IPv6 tanto se a máquina chega a internet por IPv6 como se non. Aparece en listaxes de interfaces e nalgúns diagnósticos de aplicacións, e non di nada sobre a ruta do voso tráfico.
A segunda falsa alarma é un enderezo local único dentro de fc00::/7, que é un rango privado usado dentro dunha rede. Unha ferramenta que imprima todos os enderezos do equipo listarao encantada xunto ao público. Quen le deprisa chámao fuga e logo pasa unha hora nun problema que non existe.
A terceira non é ningunha falsa alarma. Un enderezo global que chega a internet fóra do túnel é a fuga real, e paga a pena medila antes de decidir nada:
ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.coSe o primeiro comando imprime un enderezo global e o terceiro devolve un enderezo IPv6 público que non é o do túnel, tedes unha ruta real fóra do túnel. Se o primeiro non imprime máis que entradas link-local, nunca houbo fuga que arranxar.
Tres condicións deciden o control
A decisión non é "IPv6 bo" ou "IPv6 malo". É en cal de tres situacións estades, e cada unha ten unha resposta correcta distinta cun custo distinto se errades.
| 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 |
A primeira fila é o que a xente adoita querer dicir, e é lexítima. Un cliente cuxa saída non admite IPv6 non debería deixar saír en silencio o tráfico IPv6 nativo do equipo, porque esa é a fuga documentada de dobre pila. A cuestión é bloquearlo como política declarada, non desactivar un protocolo no núcleo. O resultado visible é idéntico e só un dos dous se pode revisar despois.
A terceira fila é onde o consello xeral se volve activamente prexudicial. Os operadores móbiles e algunhas conexións domésticas operan redes IPv6-only con tradución para destinos IPv4. Quitade IPv6 alí e quitades o único transporte que ofrece a rede, o que produce unha caída moito peor ca a que estabades depurando.
Se a saída non ten IPv6, bloqueádeo a propósito
Preferide o mecanismo do propio cliente, porque se aplica exactamente mentres o túnel está activo e revértese cando cae. OpenVPN ten unha opción para isto, e iptables ten unha regra equivalente para outros clientes:
block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachableA directiva pertence ao perfil; a regra pertence a un cortafuegos que podedes revisar e quitar. Ambas fallan pechadas, que é o que queredes, e ambas se ven nun diff de configuración, cousa que un sysctl do núcleo enterrado nun script de arranque non fai.
Anotade por que está aí. Unha regra de bloqueo sen comentario quitaa a seguinte persoa que necesite IPv6 para algo non relacionado, e entón a fuga volve en silencio.
Se a saída transporta IPv6, encamiñádeo e probade ambas familias
Transportar IPv6 é a resposta mellor cando o servidor o admite, e non é moito máis difícil. O requisito é que a interface do túnel teña un enderezo nesa familia e que a ruta por defecto apunte cara ao túnel e non cara á interface 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.coA consulta de ruta é a proba decisiva: se nomea a interface do túnel, o tráfico IPv6 estase a transportar. As dúas chamadas a curl confirman despois que ve cada familia, e comparalas é como se demostra que ambos camiños saen xa pola mesma saída.
Non vos detidades nunha conexión correcta. Reconectade o túnel e comprobade de novo, porque unha ruta IPv6 empurrada pode perderse ao restablecerse se o servidor só a envía na configuración inicial. Despois comprobade un destino excluído, porque as regras de túnel dividido son onde as dúas familias máis a miúdo discrepan.
Se a rede de acceso é só IPv6, deixádea en paz
Algunhas redes só ofrecen IPv6 e esperan que o dispositivo chegue a servizos IPv4 mediante un mecanismo de tradución no lado do operador. Desactivar IPv6 nunha máquina así non é unha mellora de seguridade; elimina a única ruta cara a calquera cousa. É unha caída autoinxerida ao servizo dun resultado de proba que ninguén necesitaba.
O síntoma de equivocarse aquí é inconfundible e desagradable: o túnel parece establecerse, a resolución de nomes funciona e non carga nada. Se o vedes tras un cambio de IPv6, restaurade o axuste de inmediato e seguíde o diagnóstico noutro sitio.
Escollades o que escollades, mantede a decisión explícita no perfil ou no cortafuegos, atádea ao que a saída realmente admite e anotade o comportamento de dobre pila que describe o debate sobre dobre pila do RFC 7359 . Un bloqueo declarado é unha política. Un protocolo desactivado é un apaño que ninguén pode auditar, e desde a páxina de proba parecen idénticos.