Como testar IPv6 através de uma VPN com o seu próprio recurso

Uma página pública de verificação de IP responde a uma pergunta, e normalmente não à que fez. Diz-lhe o endereço de saída que a página observou; não diz se a rota IPv6 pelo túnel funciona, se o anfitrião preferiu IPv6 ou recuou, nem se uma aplicação excluída seguiu outro caminho. Um recurso autorizado que controla responde corretamente à pergunta mais estreita, porque vê as duas pontas. O guia abaixo trata de chegar a uma conclusão que possa defender, não de obter um resultado verde.

Passo 1: diga qual rota IPv6 está a testar

Diga-o numa frase. Um pedido ao próprio endereço IPv6 do servidor do túnel testa o túnel; um pedido a um anfitrião além da saída testa a saída IPv6 da saída; um pedido a um endereço IPv6 privado testa uma rota interna.

São três afirmações diferentes e um único pedido bem-sucedido não as pode sustentar todas. Escolha a que importa para a decisão que tem à frente e registe-a antes de executar seja o que for. Se a preocupação é se o IPv6 se escapa em torno do túnel, a pergunta é sobre a seleção de rota do anfitrião, não sobre a alcançabilidade da saída. Se a preocupação é se o lado remoto consegue chegar a um serviço interno, a saída é irrelevante.

Passo 2: confirme que o anfitrião seleciona essa rota

ip -6 route get 2001:db8:1::10 imprime a rota, o endereço de origem e a interface que o núcleo usaria, e é desse facto que depende o resto do teste.

Existir uma interface não é o mesmo que ser selecionada. Os anfitriões de pilha dupla têm uma tabela de precedência, e /etc/gai.conf no Linux pode mudar qual família ganha para um nome que resolve para ambas.

Passo 3: use um destino e um nome legítimos

Se está a testar HTTPS, use o nome de anfitrião para o qual o certificado foi emitido e mantenha a verificação ativa; passar para um endereço literal para o teste passar desativa exatamente a verificação que prova que chegou ao anfitrião pretendido. Um serviço de diagnóstico que controla, a responder num nome conhecido com um certificado válido, é o alvo mais limpo. Também lhe dá uma linha de registo do lado do servidor para correlacionar, o que um verificador de terceiros nunca dará.

Execute o pedido numa forma que mostre o endereço usado: curl -6 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://test6.example.net/. A opção -6 força a família, e é assim que separa IPv6 não funciona de IPv6 não foi preferido.

Para uma verificação pura de alcançabilidade onde o ICMPv6 é permitido, ping -6 -c 3 2001:db8:1::10 é suficiente. Prova o caminho e nada acima dele.

Passo 4: correlacione as duas pontas

Quando tem acesso às duas pontas, execute tcpdump -ni any ip6 and host 2001:db8:1::10 no cliente e o equivalente no recurso, com marcas temporais, e confirme que o mesmo fluxo aparece nas duas. É isso que transforma um resultado plausível em prova: a visão do cliente sozinha não distingue uma resposta do recurso de uma resposta de algo pelo meio. Mantenha a captura estreita a um único destino para que a saída continue legível e a sessão não relacionada de ninguém não acabe no ficheiro.

Repita o teste após uma reconexão se a preocupação é se a política sobrevive a um reinício. O estado de rota e de firewall aplicado uma vez na ligação pode diferir do estado reaplicado, e a diferença só aparece na segunda ligação.

Teste o caso de falha em separado se precisar dele. Um túnel que bloqueia IPv6 quando cai e um que o deixa escapar são desenhos diferentes, e só um deles pode ser verificado com um pedido bem-sucedido.

Passo 5: registe o que o teste não provou

O quinto passo é registar o que o teste não provou, e é a parte que costuma ser omitida. Um teste bem-sucedido a um ponto final privado não prova a saída IPv6 pública, não prova o comportamento do DNS e não cobre as aplicações que excluiu do túnel. Cada uma dessas precisa do seu próprio destino e da sua própria observação. Uma nota que diga que o IPv6 funciona após um pedido a um anfitrião não é um achado; é uma suposição com marca temporal.

O registo que vale a pena guardar é curto: o destino, o nome, o endereço de origem que o anfitrião escolheu, o endereço remoto observado e a hora. RFC 7359 discute como testar que uma rota IPv6 relevante é realmente utilizável, e é a norma a que este guia se aproxima com ferramentas mais simples. Se a conclusão precisa de um verificador público para ser verdadeira, o teste não era suficientemente específico.