VPN de pilha dupla: o cliente escolhe a família de endereços, não você

O túnel está de pé, os sites IPv4 carregam e um nome de host expira. A conclusão imediata é que a VPN está quebrada ou que as credenciais estão erradas, e normalmente nenhuma das duas é verdadeira. O nome retornou tanto um endereço IPv4 quanto um IPv6, a aplicação escolheu um, e apenas um desses candidatos tinha um caminho funcional. Foi o cliente que tomou a decisão de seleção; o túnel simplesmente não cobria o que ele selecionou.

Escolher não é prometer cobertura

A seleção de endereço padrão, descrita na RFC 6724, decide qual par de origem e destino um host prefere quando há vários disponíveis. O Happy Eyeballs acrescenta uma estratégia de conexão por cima: inicia tentativas nas duas famílias e mantém a que responder primeiro, para que o usuário não espere uma família quebrada expirar.

Nenhum dos dois mecanismos cria uma rota. Se o seu túnel transporta apenas IPv4, um candidato AAAA ainda é um destino legítimo que o cliente pode tentar, e a falha aparece como carregamento lento e não como erro, porque o navegador recuou. O usuário relata um site lento, não quebrado, e o chamado de suporte herda essa vagueza. Reproduza o caso com uma família fixa e o relatório fica específico.

É esse recuo que torna o sintoma inconsistente entre aplicações. Um navegador esconde o atraso; um cliente de linha de comando com uma família fixa mostra a falha real imediatamente.

Descubra qual família o pedido realmente usou

Comece pelo nome, não pelo túnel. Consulte os dois tipos de registro e anote o que voltou:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

Se o pedido v4 tiver sucesso e o v6 falhar, você reproduziu o problema numa forma que pode depurar. Se ambos funcionarem a partir do shell e o navegador continuar falhando, examine o resolvedor da própria aplicação ou uma resposta em cache antes de tocar no túnel.

Guarde a família e o destino nas suas notas. Um chamado que diz que o site não carrega pela VPN não pode ser verificado por ninguém, enquanto um chamado que diz que AAAA falha e A funciona aponta para uma rota específica.

Verifique a rota para essa família

Para a família que falha, pergunte ao kernel qual caminho ele usaria e compare-o com os endereços configurados do túnel. No Linux, ip -6 route get para o destino mostra a interface e a origem que seriam escolhidas.

Depois verifique o próprio túnel. Os pares do WireGuard carregam uma lista de IPs permitidos, e uma entrada para 0.0.0.0/0 não diz nada sobre IPv6. Se a lista do par não tiver prefixo IPv6, o cliente não tem motivo para enviar tráfego AAAA para dentro do túnel, e o pacote sai pelo que o host faria de outra forma.

As regras de firewall e a política NAT merecem a mesma verificação por família. Uma regra escrita para IPv4 não cobre IPv6 em nenhuma plataforma, e essa é a razão mais comum de uma família funcionar e a outra não.

Não desative o IPv6 para simplificar a captura de tela

Desativar o IPv6 em todo o sistema fará o sintoma desaparecer e deixará você sem diagnóstico. Também quebra qualquer destino que seja apenas IPv6, e esconde o mesmo bug para a próxima aplicação. Se uma máquina realmente não deveria usar IPv6, isso é uma política deliberada com um proprietário e um teste. Desativá-lo durante um incidente não é nem uma coisa nem outra.

Decida o que o cliente deve fazer com a família e configure isso explicitamente: leve-a pelo túnel, ou bloqueie-a de uma forma suportada para que a seleção nunca ofereça um candidato inalcançável. Ambos são projetos legítimos. Uma desativação global não é nenhum dos dois, porque não é projeto nenhum.

O que colocar no chamado

Anote quatro coisas: o nome de host, a família que falhou, a rota que o kernel escolheu e o resultado de um pedido específico da família. Esse conjunto basta para outra pessoa reproduzir a falha sem adivinhar qual dos dois caminhos você quis dizer.

As regras de seleção de endereços da RFC 6724 explicam por que o cliente preferiu o candidato que preferiu, e a RFC 8305 explica o comportamento de corrida que escondeu o atraso. Nenhuma das duas vai rotear um pacote por você, e essa é a parte que o túnel precisa fazer.