Por que sua VM do GCP não consegue responder ao pool IPv6 do OpenVPN

Seu cliente VPN IPv6 alcança a carga de trabalho, a carga responde para dentro do túnel, e a resposta nunca chega. O instinto é culpar o firewall ou o túnel, e normalmente nenhum dos dois tem culpa. Um endereço entregue pelo OpenVPN é uma rede interna que existe apenas dentro do túnel; o Google Cloud não faz ideia de que fd42:90::/64 deveria estar atrás de uma VM específica até você avisar.

Dois sistemas separados precisam aprender esse fato, e apenas um deles é o OpenVPN. A VPC precisa de uma rota antes de poder enviar algo de volta, e a VM deve ter permissão para encaminhar o que chega. Erre em qualquer uma das metades e o sintoma parece idêntico.

O pool é uma rede interna, não uma sub-rede

O OpenVPN pode distribuir endereços IPv6 de um intervalo que você escolhe, e esse intervalo é uma ficção com a qual as duas pontas do túnel concordam. Ele não é uma sub-rede do Google Cloud, não aparece na lista de sub-redes da VPC, e a interface de rede da VM não adquire esses endereços. Uma carga que responde a um cliente, portanto, envia um pacote para um endereço que a rede considera não roteável.

Mantenha o pool fora de todo intervalo que a VPC já usa. Mantenha-o também fora dos intervalos atrás dos seus outros túneis. A sobreposição transforma uma falha de roteamento limpa em uma intermitente que só aparece sob carga.

Endereçamento local exclusivo como fd42:90::/64 é uma escolha razoável para esta rede interna. O prefixo também lembra que o design é privado por construção. Nada em um pool ULA o torna uma fonte legítima na internet pública.

Dê à VPC um destino e um próximo salto

A resposta precisa de uma rota VPC cujo destino seja o pool e cujo próximo salto seja a VM de VPN. A documentação atual de rotas estáticas cobre faixas de destino IPv6 e lista quais tipos de próximo salto são elegíveis, então verifique a forma suportada para sua topologia em vez de copiar um exemplo IPv4 mais antigo.

Um endereço de próximo salto precisa ser um que esteja realmente atribuído à interface de nuvem da instância. O endereço interno do túnel da VM não é esse endereço. Usá-lo mesmo assim produz uma rota que se instala limpa e nunca corresponde a um pacote. Leia a lista de interfaces antes de escrever a rota.

A precedência de rotas importa tanto quanto a entrada em si. As rotas de sub-rede são mais específicas do que as rotas personalizadas que você adiciona, então um pool recortado de um intervalo de sub-rede existente perderá para a rota de sub-rede, não importa como a rota personalizada esteja escrita. Escolha um pool distinto e depois confirme que a rota mostra a instância como próximo salto e o prefixo de destino correto:

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

O encaminhamento precisa ser habilitado duas vezes

Uma rota entrega o pacote à instância. Ela não torna a instância disposta a encaminhar algo que não é endereçado a ela, e essa permissão existe em duas camadas.

O lado da nuvem precisa da capacidade de encaminhamento da instância habilitada; é a configuração que permite a uma VM receber tráfego para endereços que não possui e repassá-lo. O lado convidado precisa do próprio encaminhamento IPv6, porque o kernel toma uma decisão separada depois que o pacote chega. Os dois precisam estar ativos antes de uma única resposta cruzar o túnel.

sysctl -w net.ipv6.conf.all.forwarding=1

Depois, as regras de firewall precisam admitir o intervalo de origem interno nos dois sentidos. O Google Cloud avalia o pacote desencapsulado, então uma regra que cobre apenas a sub-rede da VPC descarta o tráfego do pool depois que o túnel já teve sucesso. Adicione o pool como intervalo de origem na regra de entrada e verifique que nenhuma política de saída personalizada bloqueia a resposta. A regra de permissão implícita cobre o caso padrão, uma regra de saída escrita à mão não.

Diga ao OpenVPN quem possui o quê

O OpenVPN encaminha para um cliente quando sabe que aquele cliente possui o destino. Os endereços de cliente do pool são tratados pela diretiva de servidor que define o pool, mas uma sub-rede atrás de um cliente é outro arranjo e precisa de uma entrada de propriedade explícita para esse cliente.

Confundir os dois produz um túnel em que os pings ao servidor funcionam e nada atrás dele. Decida qual caso você está construindo e depois escreva a entrada correspondente em vez de adicionar uma segunda linha push e torcer.

Mantenha a saída para a internet fora deste design

Acesso privado e acesso à internet são planos separados. Um pool ULA pode alcançar as cargas de trabalho da VPC pelo túnel uma vez que roteamento e encaminhamento concordem, e esse mesmo pool não tem caminho para a internet pública através da VPC, porque o gateway da nuvem não aceitará uma origem de túnel arbitrária como sua.

Se os clientes também precisam de saída para a internet, planeje um design de endereçamento e roteamento suportado para isso, mantenha-o independente do pool privado e teste os dois caminhos separadamente. Um caminho que funciona não diz nada sobre o outro, e um design que os confunde falha de um modo que parece um túnel quebrado.