Desativar IPv6 para corrigir um vazamento de VPN? Decida a política primeiro
Um endereço link-local não é vazamento, e uma rota IPv6 global também não. Escolha primeiro entre bloquear, transportar e deixar em paz.
Um endereço da faixa IPv6 aparece numa página de teste, o túnel claramente não o transporta, e o conselho mais popular da internet é desativar IPv6 em todo lugar. Esse comando realmente cala o painel. Também remove um protocolo de que a rede de acesso pode depender, e deixa você sem ideia se o endereço era um vazamento real, um endereço de interface link-local ou um resolvedor fazendo o seu trabalho. Três condições decidem o controlo correto, e só uma delas leva ao bloqueio.
Identifique o que a ferramenta realmente mediu
O falso alarme mais comum é um endereço link-local, que começa por fe80: e existe em todas as interfaces compatíveis com IPv6, quer a máquina chegue à internet por IPv6 ou não. Aparece em listagens de interfaces e em alguns diagnósticos de aplicações, e não diz nada sobre o caminho do seu tráfego.
O segundo falso alarme é um endereço local único em fc00::/7, que é uma faixa privada usada dentro de uma rede. Uma ferramenta que imprima todos os endereços do equipamento vai listá-lo com prazer ao lado do público. Quem lê depressa chama-lhe vazamento e depois passa uma hora num problema que não existe.
O terceiro não é falso alarme nenhum. Um endereço global que chega à internet fora do túnel é o vazamento real, e vale a pena medi-lo antes de decidir qualquer coisa:
ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.coSe o primeiro comando imprimir um endereço global e o terceiro devolver um endereço IPv6 público que não é o do túnel, tem um caminho real fora do túnel. Se o primeiro não imprimir nada além de entradas link-local, nunca houve vazamento para corrigir.
Três condições decidem o controlo
A decisão não é "IPv6 bom" ou "IPv6 mau". É em qual de três situações está, e cada uma tem uma resposta correta diferente com um custo diferente se errar.
| 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 linha é o que as pessoas costumam querer dizer, e é legítima. Um cliente cuja saída não suporta IPv6 não deve deixar sair em silêncio o tráfego IPv6 nativo do equipamento, porque esse é o vazamento documentado de pilha dupla. O ponto é bloqueá-lo como política declarada, não desativar um protocolo no kernel. O resultado visível é idêntico e só um dos dois pode ser revisto mais tarde.
A terceira linha é onde o conselho geral se torna ativamente prejudicial. Os operadores móveis e algumas ligações domésticas operam redes IPv6-only com tradução para destinos IPv4. Retire IPv6 ali e retira o único transporte que a rede oferece, o que produz uma falha muito pior do que aquela que estava a depurar.
Se a saída não tiver IPv6, bloqueie-a de propósito
Prefira o mecanismo do próprio cliente, porque se aplica exatamente enquanto o túnel está ativo e reverte quando cai. OpenVPN tem uma opção para isto, e o iptables tem uma regra equivalente para outros clientes:
block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachableA diretiva pertence ao perfil; a regra pertence a uma firewall que pode rever e remover. Ambas falham fechadas, que é o que quer, e ambas são visíveis num diff de configuração, o que um sysctl do kernel enterrado num script de arranque não é.
Registe por que motivo está ali. Uma regra de bloqueio sem comentário é removida pela pessoa seguinte que precisar de IPv6 para outra coisa, e então o vazamento volta em silêncio.
Se a saída transportar IPv6, encaminhe-o e teste as duas famílias
Transportar IPv6 é a melhor resposta quando o servidor o suporta, e não é muito mais difícil. O requisito é que a interface do túnel tenha um endereço nessa família e que a rota predefinida aponte para dentro do túnel e não para fora da 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 rota é o teste decisivo: se nomear a interface do túnel, o tráfego IPv6 está a ser transportado. As duas chamadas curl confirmam depois o que cada família vê, e compará-las é a forma de provar que os dois caminhos saem agora pela mesma saída.
Não pare numa ligação bem-sucedida. Reconecte o túnel e verifique de novo, porque uma rota IPv6 empurrada pode perder-se ao restabelecer se o servidor só a enviar na configuração inicial. Depois verifique um destino excluído, porque as regras de túnel dividido são onde as duas famílias mais divergem.
Se a rede de acesso for só IPv6, deixe-a em paz
Algumas redes só fornecem IPv6 e esperam que o dispositivo chegue aos serviços IPv4 através de um mecanismo de tradução do lado do operador. Desativar IPv6 numa máquina dessas não é uma melhoria de segurança; remove a única rota para o que quer que seja. É uma falha autoinfligida ao serviço de um resultado de teste de que ninguém precisava.
O sintoma de errar aqui é inconfundível e desagradável: o túnel parece estabelecer-se, a resolução de nomes funciona e nada carrega. Se vir isso depois de uma alteração de IPv6, restaure a definição de imediato e continue o diagnóstico noutro sítio.
Escolha o que escolher, mantenha a decisão explícita no perfil ou na firewall, ligue-a ao que a saída realmente suporta, e anote o comportamento de pilha dupla que descreve a discussão sobre pilha dupla do RFC 7359 . Um bloqueio declarado é uma política. Um protocolo desativado é um contorno que ninguém pode auditar, e a partir da página de teste parecem idênticos.