Por que a túa VM de GCP non pode responder ao pool IPv6 de OpenVPN

O teu cliente VPN IPv6 chega á carga de traballo, a carga responde cara ao túnel e a resposta nunca chega. O instinto é culpar a devasa ou o túnel, e normalmente ningún dos dous ten a culpa. Un enderezo que entrega OpenVPN é unha rede interna que só existe dentro do túnel; Google Cloud non ten nin idea de que fd42:90::/64 debería estar detrás dunha VM concreta ata que llo digas.

Dous sistemas separados teñen que aprender ese feito, e só un deles é OpenVPN. A VPC necesita unha ruta antes de poder enviar nada de volta, e á VM débeselle permitir reenviar o que chega. Se fallas en calquera das dúas metades, o síntoma parece idéntico.

O pool é unha rede interna, non unha subrede

OpenVPN pode entregar enderezos IPv6 dun rango que escollas, e ese rango é unha ficción coa que coinciden os dous extremos do túnel. Non é unha subrede de Google Cloud, non aparece na lista de subredes da VPC e a interface de rede da VM non adquire eses enderezos. Por iso, unha carga que responde a un cliente envía un paquete a un enderezo que a rede considera non encamiñable.

Mantén o pool fóra de todos os rangos que a VPC xa use. Mantéño tamén fóra dos rangos que hai detrás dos teus outros túneles. O solapamento converte un fallo limpo de encamiñamento nun intermitente que só aparece baixo carga.

O enderezo local único como fd42:90::/64 é unha opción razoable para esta rede interna. O prefixo tamén recorda que o deseño é privado por construción. Nada dun pool ULA o converte nunha fonte lexítima na internet pública.

Dalle á VPC un destino e un seguinte salto

A resposta necesita unha ruta da VPC cuxo destino sexa o pool e cuxo seguinte salto sexa a VM de VPN. A documentación actual de rutas estáticas cobre rangos de destino IPv6 e indica que tipos de seguinte salto son elixibles, así que verifica a forma admitida para a túa topoloxía en lugar de copiar un exemplo IPv4 antigo.

Un enderezo de seguinte salto ten que ser un que estea asignado realmente á interface cloud da instancia. O enderezo interno do túnel da VM non é ese enderezo. Usalo de todos os xeitos produce unha ruta que se instala limpiamente e nunca coincide cun paquete. Le a lista de interfaces antes de escribir a ruta.

A precedencia das rutas importa tanto como a entrada en si. As rutas de subrede son máis específicas que as rutas personalizadas que engades, así que un pool recortado dun rango de subrede existente perderá contra a ruta de subrede, sen importar como estea escrita a ruta personalizada. Escolle un pool distinto e despois confirma que a ruta mostra a instancia como seguinte salto e o prefixo de destino correcto:

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 reenvío debe activarse dúas veces

Unha ruta entrega o paquete á instancia. Non fai que a instancia estea disposta a reenviar algo que non vai dirixido a ela, e ese permiso existe en dúas capas.

O lado do cloud necesita a capacidade de reenvío da instancia activada, que é o axuste que permite a unha VM recibir tráfico para enderezos que non posúe e pasalo. O lado convidado necesita o seu propio reenvío IPv6, porque o kernel aplica unha decisión aparte despois de que chegue o paquete. Ambos deben estar activados antes de que unha soa resposta cruce o túnel.

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

Despois, as regras de devasa teñen que admitir o rango de orixe interno en ambas direccións. Google Cloud avalía o paquete desencapsulado, así que unha regra que só cobre a subrede da VPC descarta o tráfico do pool despois de que o túnel xa tivese éxito. Engade o pool como rango de orixe na regra de entrada e comproba que ningunha política de saída personalizada bloquee a resposta. A regra de permiso implícita cobre o caso por defecto, unha regra de saída escrita a man non.

Dille a OpenVPN quen posúe que

OpenVPN reenvía a un cliente cando sabe que ese cliente posúe o destino. Os enderezos de cliente do pool xestiónaos a directiva de servidor que define o pool, pero unha subrede detrás dun cliente é outra disposición e necesita unha entrada de propiedade explícita para ese cliente.

Confundir as dúas cousas produce un túnel no que os pings ao servidor funcionan e nada do que hai detrás. Decide que caso estás a construír e despois escribe a entrada correspondente en lugar de engadir unha segunda liña push e confiar na sorte.

Mantén a saída a internet fóra deste deseño

O acceso privado e o acceso a internet son plans separados. Un pool ULA pode chegar ás cargas de traballo da VPC polo túnel unha vez que o encamiñamento e o reenvío coinciden, e ese mesmo pool non ten camiño cara á internet pública a través da VPC, porque a pasarela do cloud non aceptará unha fonte de túnel arbitraria como propia.

Se os clientes tamén necesitan saída a internet, planifica un deseño de enderezo e encamiñamento compatible para iso, mantéño independente do pool privado e proba os dous camiños por separado. Un camiño que funciona non di nada sobre o outro, e un deseño que os confunde falla dun xeito que parece un túnel roto.