IPv6 através de um servidor VPN IPv4 ainda exige uma saída IPv6

O túnel sobe, o cliente recebe um endereço IPv6 do pool e, mesmo assim, cada destino IPv6 expira. Dentro do túnel não há nada quebrado: o IPv6 viaja perfeitamente dentro do transporte IPv4, e isso nunca foi a parte difícil. O endereço que você entregou é uma promessa que o servidor não consegue cumprir, porque a saída não tem nenhum upstream IPv6 para onde enviá-lo. O conserto pertence à saída, não ao perfil do cliente.

O sintoma: um endereço e nenhum caminho

Uma verificação do lado do cliente mostra um endereço IPv6 de aparência global no dispositivo de túnel e uma rota que aponta para dentro dele, e é por isso que isso é lido erroneamente como um bug do cliente. O tráfego entra no túnel, o servidor o desencapsula, e então o pacote aterrissa num host cuja tabela de roteamento não tem nenhuma rota padrão IPv6 para um lugar real. Dependendo da pilha, você obtém inalcançabilidade imediata ou um descarte silencioso, e em ambos os casos o cliente vê um tempo limite que parece idêntico a um firewall.

Leia a própria tabela de roteamento do servidor antes de tocar no cliente, porque é ali que mora a metade que falta do caminho. Um servidor com uma única rota padrão IPv4 já lhe deu a resposta.

Siga o pacote depois da desencapsulação

Dentro do túnel o pacote é IPv6 comum e sua origem é o endereço do cliente. O servidor remove a encapsulação de transporte e então segura um pacote IPv6 nativo que precisa ser encaminhado para o próximo salto IPv6. Uma rota padrão IPv4 não consegue carregá-lo, e traduzi-lo para IPv4 é outra função que ninguém implantou. Essa é toda a falha, e ela não tem nada a ver com o fato de o ouvinte de VPN ter respondido ou não por IPv4.

A mecânica de encapsulamento de IPv6 sobre IPv4 está descrita na RFC 4213, e o detalhe importante ali é que as extremidades ainda precisam de conectividade IPv6 real do outro lado do túnel. Embrulhar um cabeçalho não faz aparecer um upstream.

Duas camadas de túnel, duas verificações independentes

Verifique cada camada separadamente, porque um túnel externo que funciona esconde um interno quebrado. Verifique o caminho externo com um ping IPv4 do cliente para o servidor e confirme a porta que você usa. Depois verifique o caminho interno no servidor, onde ip -6 route deve mostrar uma rota padrão ou uma rota específica aprendida de um upstream real, e ip -6 addr deve mostrar um prefixo de origem que o upstream aceite. Qualquer coisa a menos que isso é decoração na interface.

Um endereço único-local, ou um prefixo de aparência global para o qual nada roteia de volta, aparecerá felizmente numa interface e não irá a lugar nenhum. A alcançabilidade pública é concedida pelo upstream, não pela forma do endereço.

O mesmo vale no cliente: ip -6 route get 2001:4860:4860::8888 deveria nomear o dispositivo de túnel, e se nomear o físico, o cliente não está usando a VPN para IPv6 de jeito nenhum.

Prefixo de origem, tamanho e ICMPv6

Pergunte ao upstream quais prefixos de origem ele aceitará para encaminhamento, e use um deles para o pool de clientes. Um provedor que lhe dá um /64 para a interface do próprio servidor não necessariamente roteia para você um segundo /64 ou um bloco maior, e a diferença é uma tarde de depuração que um ticket de suporte resolve com uma pergunta. Pergunte por escrito e guarde a resposta junto da configuração.

Orce a encapsulação extra que sua pilha realmente usa, e mantenha o ICMPv6 funcionando, incluindo o Packet Too Big. Um segundo cabeçalho reduz a carga útil, então um caminho que responde a pings pequenos ainda pode falhar numa transferência de arquivo, e um firewall que descarta todo o ICMPv6 transforma um problema de tamanho recuperável num buraco negro. Teste uma transferência grande antes de anunciar o serviço.

O que é um problema completamente diferente

Alcançar uma aplicação apenas IPv4 a partir de um cliente apenas IPv6 é tradução, não tunelamento, e precisa de algo como uma implantação deliberada de NAT64. O destino não vai entender um cabeçalho de túnel extra só porque você adicionou um. Os serviços de transição históricos merecem o mesmo cuidado: a RFC 7526 descontinuou o modelo de relay anycast 6to4, então um tutorial escrito em torno dele descreve algo que já não tem um relay público mantido.

Se o servidor não tem nenhum upstream IPv6 utilizável, as escolhas são um upstream suportado, uma saída diferente ou uma decisão documentada de que o IPv6 fica fora do túnel. O que não é aceitável é dizer aos clientes que existe um serviço IPv6 enquanto a conexão IPv6 comum deles contorna a VPN em silêncio.