Uma rede só IPv6 quebra a VPN antes de o túnel começar

O portátil liga-se a um Wi-Fi de conferência que só distribui IPv6, o cliente VPN gira e falha, e o mesmo perfil tinha funcionado num hotel uma hora antes. Nada mudou nas credenciais. O que mudou é que o cliente agora tem de chegar a um destino IPv4 através de uma rede que só transporta IPv6, e nem todos os clientes sabem como o fazer.

Percorra os mesmos cinco passos que os pacotes percorrem.

Passo 1: observe a consulta de nome

Se o perfil usa um nome de anfitrião, a primeira pergunta é o que devolve o resolvedor. dig AAAA vpn.example.com na rede só IPv6 devolve um registo AAAA real, um sintetizado pelo DNS64 ou nada de todo. Uma resposta sintetizada codifica o destino IPv4 dentro de um prefixo de tradução, e só então um cliente sem destino IPv6 o consegue alcançar. Um perfil com um endereço IPv4 fixo nunca chega aqui, porque não há nenhum nome para sintetizar.

Essa única diferença explica a maioria dos relatórios «funciona lá, falha aqui», e basta um único comando para a ver.

Passo 2: veja que família o cliente pediu

Olhe para o socket em vez da barra de progresso. Um cliente que abre um socket IPv4 para um endereço IPv4 numa ligação só IPv6 não tem onde o enviar, e a falha aparece como um tempo limite em vez de um erro de nome. ss -tanp enquanto o cliente se liga mostra o endereço remoto e a família que tentou. Compare com ip -6 route para confirmar que a rota predefinida é um salto IPv6 real.

A família de endereços na tabela de sockets é o facto. A barra de progresso é um resumo que outra pessoa escreveu.

Passo 3: separe a tradução do túnel

NAT64 e DNS64 são a forma como a rede de acesso chega a destinos IPv4, e não fazem nada pelo túnel depois de ele estar de pé. Um túnel estabelecido sobre um caminho traduzido continua a negociar o seu próprio endereçamento interno, e a cobertura interna IPv4 ou IPv6 é uma questão de política separada. Se o cliente se liga e depois não chega a nada, já passou a tradução e está no encaminhamento, que é outra investigação com outras provas.

A falha da tradução parece nunca ligar. A falha da cobertura interna parece ligar e não chegar a nada.

Passo 4: teste o mesmo perfil noutra rede

Leve o mesmo perfil, versão de cliente e credenciais para uma rede de dupla pilha e repita. Se lá funcionar e falhar no caminho só IPv6, a variável é a rede de acesso e não o perfil. Anote a versão do cliente e o estado da rede no ticket, porque a correção final é uma atualização do cliente ou outro destino.

Um relatório que diz que a VPN está quebrada não é acionável. Um relatório que diz que falha apenas em acesso só IPv6 é um relatório de erro.

Passo 5: corrija o caminho, não as definições de segurança

Todas as reparações tentadoras pioram as coisas. Desativar o IPv6 remove o único caminho que a rede oferece. Apontar o cliente para um resolvedor público quebra a síntese DNS64, porque essa síntese tem de vir do resolvedor atrás do tradutor. Desativar a verificação de certificados dá-lhe uma ligação a algo que não consegue identificar. Nenhuma delas é uma reparação, e duas são regressões de segurança que sobreviverão ao incidente.

As opções reais são um cliente que suporte o modelo de tradução de rede, ou um destino com um endereço IPv6 alcançável. Peça uma das duas.