Dividir o seu /64 não encaminha IPv6 para os clientes VPN

O cliente mostra um endereço IPv6 global, o handshake foi concluído e nada volta da internet. A configuração do pool parece correta porque está correta; o endereço é válido e o túnel o transporta. O que falha é a entrega, e a entrega depende de uma decisão tomada acima do servidor VPN que nenhuma configuração do lado do cliente pode influenciar.

O mito: uma parte do seu /64 já é alcançável

A história é atraente: o servidor tem um /64 público, corte-o ao meio, entregue a outra metade ao pool VPN, e esses clientes estão agora na internet. Dividir o prefixo realmente aloca endereços sem colisões. Mas não muda como a rede upstream decide para onde deve ir um pacote destinado a um desses endereços.

IPv6 não tem uma camada de tradução padrão na qual se apoiar, por isso o caminho de retorno tem de existir como encaminhamento ou como entrega ao nível do enlace. Um pacote endereçado ao endereço de túnel de um cliente chega ao router upstream, e esse router toma uma decisão de encaminhamento a partir da sua própria tabela. Se a tabela aponta para o enlace físico, o pacote vai para lá, independentemente do que acredita o seu servidor VPN.

Essa é toda a falha: a direção de ida funciona porque o seu servidor a envia, e a direção de volta morre a um salto de distância porque o upstream nunca soube que o cliente existe.

O que a entrega no enlace realmente exige

Quando o upstream considera que todo o /64 está no enlace físico, resolve cada endereço de destino com descoberta de vizinhos. Envia uma solicitação nesse enlace e espera que o proprietário do endereço responda. Um cliente VPN atrás de um túnel não está nesse enlace e não pode responder, por isso a solicitação fica sem resposta e o pacote é descartado.

Recortar um /65 não muda essa expectativa. O upstream continua a tratar o intervalo como estando no enlace, porque a única coisa que o faria mudar de ideias é uma rota ou um proxy que responda em nome do cliente. Nenhum dos dois aparece porque editou uma configuração de VPN. É precisamente essa lacuna que explica por que um pool pode funcionar perfeitamente entre os seus próprios clientes e mesmo assim ser inalcançável a partir de qualquer outro lugar.

A descoberta de vizinhos por proxy é o mecanismo que pode ligar os dois mundos. O gateway responde às solicitações para os endereços de cliente específicos que possui e encaminha o tráfego para o túnel. Funciona, e tem de ser limitado exatamente a esses endereços com um ciclo de vida que siga o pool, porque responder por um endereço que já não serve transforma o tráfego de outra pessoa num buraco negro. Alguns upstreams não aceitarão respostas de proxy que não esperavam, por isso este desenho também precisa do acordo do fornecedor.

O que a entrega encaminhada exige

O desenho mais limpo é uma atribuição que o upstream encaminhe realmente para o seu gateway. Pode ser um prefixo delegado ou uma rota estática para um bloco mais pequeno, e o requisito é o mesmo nos dois casos: a tabela do upstream tem de apontar para o seu servidor para o intervalo de clientes. Então o tráfego de retorno chega ao gateway e o gateway encaminha-o para o túnel.

A entrega encaminhada elimina completamente a questão da descoberta de vizinhos, e é por isso que vale a pena pedi-la ao fornecedor antes de construir algo engenhoso. Peça a rota por escrito e confirme que o próximo salto é o endereço que o upstream consegue realmente alcançar.

Ambos os desenhos continuam a precisar do encaminhamento IPv6 ativado no gateway e de regras de firewall que permitam o fluxo encaminhado em ambos os sentidos. A entrega é um pré-requisito, não um substituto, para o resto do caminho. Uma rota funcional com o encaminhamento desativado produz exatamente o mesmo silêncio que uma rota ausente, por isso verifique ambas antes de redesenhar o que quer que seja.

Duas rotas independentes para acertar

O prefixo do pool e a rota padrão do próprio cliente são configurações separadas, e confundi-las produz conectividade parcial que parece um túnel quebrado. O pool diz ao servidor quais endereços atribuir. As rotas do cliente decidem para que destinos o cliente envia tráfego para o túnel.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

O prefixo acima é espaço de documentação, e o redirecionamento aplica-se apenas a IPv6, que é exatamente o que uma implementação de pilha dupla muitas vezes quer enquanto a entrega IPv6 ainda está a ser corrigida. Um redirecionamento IPv4 não estabelece cobertura IPv6, e nenhuma das configurações implica a outra.

Mantenha o tráfego de controlo de que o IPv6 depende a funcionar sob qualquer política que aplique. As mensagens Packet Too Big são a vítima clássica de uma firewall que só permite TCP e UDP, e descartá-las produz ligações que se estabelecem e depois bloqueiam em transferências maiores.

Os anúncios de router são a terceira peça móvel. Se o gateway começar a anunciar no enlace ascendente, pode mudar o que clientes e vizinhos acreditam sobre prefixos no enlace, o que pode desfazer silenciosamente o desenho que acabou de documentar.

Registe o desenho para que uma reconstrução o reproduza

Anote três objetos separadamente: a atribuição do cliente, a rota de destino do cliente e o método de entrega do upstream para a atribuição. Um leitor que tenha os três pode reconstruir a implementação; um leitor que tenha apenas a configuração do pool reproduzirá o bug original.

Depois teste explicitamente a direção de retorno, com um pacote que tenha de voltar de fora. O manual do openvpn(8) cobre as opções server-ipv6 e redirect, e a confirmação de encaminhamento do seu fornecedor cobre a metade que o manual não consegue.