O tráfego IPv6 que escapa à VPN: encontrar a rota que vaza

Duas páginas de teste discordam: uma relata o endereço do fornecedor através do túnel, a segunda relata o seu prefixo doméstico, e a conclusão óbvia é que a VPN vaza. Essa conclusão salta uma etapa, porque os dois relatórios exercitaram duas decisões de encaminhamento diferentes e só uma delas devia entrar no túnel. A falha costuma ser real, e é um problema de cobertura e não um túnel quebrado. Três perguntas resolvem-no: que fluxo saiu de facto, que rota o núcleo escolheu para ele e que comportamento o cliente pretendia.

Trabalhe nessa ordem. Responder fora de ordem produz uma longa discussão sobre se o cliente está avariado, quando a resposta real é que nunca foi instalada uma rota IPv6.

Que fluxo saiu de facto, e em que adaptador

Comece com um teste que nomeie a família usada, e depois anote a aplicação, a rede de acesso, o perfil em vigor e se a ligação oferece sequer IPv6. Esses quatro factos são o que torna duas execuções comparáveis, e o quarto é o que as pessoas esquecem: uma rede sem prefixo v6 não pode vazar v6, e uma rede que acrescente um mais tarde muda a resposta.

Envie um pedido por família em vez de carregar uma página e ler o seu resultado. Uma só página pode misturar recursos v6 e v4, um processo em segundo plano pode comportar-se de forma diferente do separador à sua frente, e uma resposta em cache pode sobreviver à mudança de rede que está a tentar testar. Fixe o destino que testa e anote-o, para que uma execução repetida meça o mesmo.

Ler a rota que o núcleo escolheu

A tabela de rotas responde à pergunta que o navegador não consegue. Pergunte ao sistema para onde iria um destino concreto, e inclua tanto as regras de política como a rota predefinida visível, porque qualquer uma delas a pode sobrepor:

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

Um prefixo mais específico é a razão habitual para um destino ficar fora do túnel enquanto tudo o resto fica dentro, e uma regra de política pode fazer o mesmo com prioridade mais alta do que qualquer rota. Leia também a métrica, porque duas entradas para o mesmo prefixo resolvem-se pela métrica e não pela sua ordem no ecrã. No Windows a lista equivalente é Get-NetRoute -AddressFamily IPv6, ordenada por métrica para corresponder à ordem de decisão. Uma regra que parece correta na tabela pode ainda perder para uma regra de política com número mais baixo, e é por isso que a lista de regras pertence ao mesmo fôlego que a lista de rotas.

De onde vem a política IPv6 do cliente

Um cliente pode ser construído para levar o v6 pelo túnel, para o recusar ou para permitir uma exceção nomeada, e essas três intenções dão três resultados corretos diferentes. Leia o perfil e a documentação do próprio cliente antes de chamar fuga a uma observação, porque um cliente que bloqueia o v6 enquanto o sistema operativo ainda envia descoberta de vizinhos na ligação física comporta-se como foi concebido.

Uma aplicação deliberadamente excluída do túnel é um caso diferente de uma família que o túnel nunca transportou. A primeira é uma decisão sobre um programa, a segunda é uma falha de cobertura, e a reparação difere em conformidade. Leia a lista de programas excluídos do cliente antes de procurar uma rota que nunca deveria ter existido.

Observação estreita, quando a tabela discorda

Quando a pesquisa de rota é ambígua, uma observação de interface no anfitrião pode resolvê-la, mas só se estiver apontada à pergunta. O tráfego para o próprio ponto final da VPN atravessará o adaptador físico por conceção; o que importa é se o fluxo da aplicação, endereçado a um sítio completamente diferente, também aparece ali. Filtre a captura para o destino que está a testar em vez de recolher tudo.

Uma captura ampla expõe muito mais tráfego pessoal do que a única pergunta exige. Também responde com menos clareza, porque o fluxo que lhe interessa chega enterrado num caudal de ligações não relacionadas. Filtre para o destino testado, pare após alguns pacotes e apague a captura.

Três formas de fechar a falha

Leve a família pelo túnel, bloqueie-a no cliente quando o túnel não a conseguir transportar, ou registe uma exceção deliberada com um responsável e uma data de revisão. Qualquer uma é defensável, e a única coisa indefensável é deixar a escolha implícita, porque uma escolha implícita é exatamente o que a fuga é. Se o túnel não tiver saída v6 nenhuma, recusar v6 no cliente é simultaneamente honesto e testável. O que importa é que a escolha fique escrita onde a pessoa seguinte a encontre, e não inferida do comportamento seis meses depois.

Repita a verificação após uma reconexão e após mudar entre redes, porque uma rota instalada para a ligação anterior pode sobreviver à mudança. Depois anote o destino, a rota selecionada, a política do cliente e a família usada no teste, para que a pessoa seguinte leia uma decisão em vez de a deduzir outra vez. RFC 7359 documenta a fuga de dupla pilha como um problema de conceção e não como um erro, e é a referência a citar quando alguém afirma que um túnel v4 a funcionar cobre tudo.