O DS-Lite bloqueia o alojamento IPv4 de entrada, não a VPN de saída

O DS-Lite é uma forma de dar a um cliente conectividade IPv4 através de uma rede de acesso que só transporta IPv6. O router doméstico não tem um endereço IPv4 público dedicado próprio, e esse único facto convence as pessoas de que uma VPN IPv4 não pode funcionar a partir dessa ligação. Em saída, normalmente funciona bem. A ligação é traduzida pelo fornecedor, e o extremo remoto vê um cliente IPv4 comum. O que se parte é a direção oposta: alojar algo que espera IPv4 de entrada não solicitado. A distinção está em qual extremo inicia a conversa.

Que extremo inicia a ligação

Um cliente que inicia uma ligação cria estado de tradução à medida que avança. O tradutor do fornecedor vê o primeiro pacote, atribui um mapeamento e reencaminha-o. O tráfego de retorno corresponde a esse mapeamento porque o mapeamento já existe.

Um servidor que espera ligações não tem esse estado para criar. Alguém de fora tem de chegar a um endereço e uma porta que o fornecedor não aceitou mapear, e isso é um pedido completamente diferente.

Siga um pedido de saída

A arquitetura em RFC 6333 nomeia ambos os extremos. O elemento do lado do cliente é o B4, que encapsula IPv4 em IPv6. O elemento do lado do fornecedor é o AFTR, que realiza a tradução de endereços e reencaminha o pacote como IPv4.

Client's IPv4 VPN packet
  → Customer B4
  → IPv4 carried over the provider's IPv6 network
  → AFTR address translation
  → IPv4 VPN server

O servidor VPN recebe uma ligação IPv4 normal a partir do endereço traduzido do fornecedor. Não precisa de um modo DS-Lite, de uma porta especial nem de saber que a rede de acesso do cliente é apenas IPv6. É esta a parte que as pessoas perdem: o extremo remoto não consegue notá-lo.

A configuração do próprio cliente é igualmente comum. Precisa de um caminho IPv4 funcional até ao servidor, que o B4 e o AFTR fornecem, e precisa de que o nome do anfitrião do servidor se resolva num endereço IPv4.

Porque o alojamento de entrada é o caso que falha

Executar um servidor VPN IPv4 em casa é o desenho que colide com o endereçamento partilhado do fornecedor. O tradutor do fornecedor é dono do endereço público e da tabela de mapeamentos, e não tem motivo para criar um mapeamento de entrada permanente para um único assinante.

Uma regra de reencaminhamento de portas no router doméstico não consegue configurar o AFTR. A regra é real e correta no dispositivo local, e não altera nada a montante, e é por isso que o sintoma parece um problema de firewall que não passa.

É também aqui que a tradução ao nível do operador difere de um único endereço público: mesmo um reencaminhamento local correto pode aterrar num endereço que muitos assinantes partilham.

Diagnostique antes de mudar o plano de acesso

Confirme primeiro o modo aprovisionado. A pilha dupla nativa, o DS-Lite e uma rede apenas IPv6 que usa outro mecanismo de tradução são três disposições diferentes, e os nomes comerciais do fornecedor nem sempre coincidem com o técnico.

Depois estabeleça quatro observações para uma falha de saída. O cliente resolve o nome do anfitrião da VPN num destino IPv4? A conectividade IPv4 simples funciona, em vez de um pedido do navegador que talvez tenha usado IPv6 em silêncio? Que transporte e porta tenta o cliente, e os registos do ponto final veem essa tentativa? A falha ocorre durante a troca inicial, após um período de inatividade ou apenas em transferências maiores?

Essas quatro respostas apontam para filtragem, expiração do estado de tradução, um ponto final errado ou o tratamento do tamanho dos pacotes. Nenhuma delas se estabelece por ver DS-Lite na página da conta.

Leia com atenção as mudanças do fornecedor

Uma mudança de conta pode coincidir com uma ligação funcional enquanto altera várias propriedades ao mesmo tempo. Anote qual propriedade mudou, porque um novo nome de pacote não é uma explicação técnica.

A instrução para ativar a pilha dupla é ambígua até alguém confirmar o que o fornecedor aprovisiona de facto. Tratá-la como um requisito universal para clientes VPN IPv4 transforma uma suposição em política.

Se o requisito real for o alojamento IPv4 de entrada, discuta com o fornecedor uma disposição de entrada suportada, endereçamento nativo ou outro desenho de acesso. Se o requisito for um portátil que chega a um servidor remoto, pergunte antes por esse fluxo de saída exato. Ordem de trabalho: nomeie a direção, confirme o modo aprovisionado, teste IPv4 simples e um transporte, e só mude o plano de acesso se a direção realmente o exigir.