Per què la vostra VM de GCP no pot respondre al pool IPv6 d’OpenVPN

El vostre client VPN IPv6 arriba a la càrrega de treball, la càrrega respon dins del túnel i la resposta no arriba mai. L’instint és culpar el tallafocs o el túnel, i normalment cap dels dos no en té la culpa. Una adreça lliurada per OpenVPN és una xarxa interna que només existeix dins del túnel; Google Cloud no té ni idea que fd42:90::/64 hauria de viure darrere d’una VM concreta fins que no li ho digueu.

Dos sistemes separats han d’aprendre aquest fet, i només un d’ells és OpenVPN. La VPC necessita una ruta abans de poder enviar res de tornada, i la VM ha de tenir permís per reenviar el que arriba. Si us equivoqueu en qualsevol de les dues meitats, el símptoma sembla idèntic.

El pool és una xarxa interna, no una subxarxa

OpenVPN pot lliurar adreces IPv6 d’un rang que trieu, i aquest rang és una ficció amb què coincideixen els dos extrems del túnel. No és una subxarxa de Google Cloud, no apareix a la llista de subxarxes de la VPC, i la interfície de xarxa de la VM no adquireix aquestes adreces. Per tant, una càrrega que respon a un client envia un paquet a una adreça que la xarxa considera no encaminable.

Manteniu el pool fora de cada rang que la VPC ja utilitzi. Manteniu-lo també fora dels rangs que hi ha darrere dels vostres altres túnels. El solapament converteix un error d’encaminament net en un d’intermitent que només apareix sota càrrega.

L’adreçament local únic com fd42:90::/64 és una opció raonable per a aquesta xarxa interna. El prefix també recorda que el disseny és privat per construcció. Res d’un pool ULA no el converteix en una font legítima a internet públic.

Doneu a la VPC una destinació i un salt següent

La resposta necessita una ruta de la VPC la destinació de la qual sigui el pool i el salt següent de la qual sigui la VM de VPN. La documentació actual de rutes estàtiques cobreix rangs de destinació IPv6 i indica quins tipus de salt següent són elegibles, així que verifiqueu la forma suportada per a la vostra topologia en lloc de copiar un exemple IPv4 antic.

Una adreça de salt següent ha de ser una que estigui assignada realment a la interfície cloud de la instància. L’adreça interna del túnel de la VM no és aquesta adreça. Fer-la servir igualment produeix una ruta que s’instal·la netament i no coincideix mai amb cap paquet. Llegiu la llista d’interfícies abans d’escriure la ruta.

La precedència de les rutes importa tant com l’entrada mateixa. Les rutes de subxarxa són més específiques que les rutes personalitzades que afegiu, així que un pool retallat d’un rang de subxarxa existent perdrà contra la ruta de subxarxa, no importa com s’escrigui la ruta personalitzada. Trieu un pool diferent i després confirmeu que la ruta mostra la instància com a salt següent i el prefix de destinació correcte:

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

El reenviament s’ha d’activar dues vegades

Una ruta lliura el paquet a la instància. No fa que la instància estigui disposada a reenviar una cosa que no va adreçada a ella, i aquest permís existeix a dos nivells.

El costat cloud necessita la capacitat de reenviament de la instància activada, que és el paràmetre que permet a una VM rebre trànsit per a adreces que no posseeix i passar-lo. El costat hoste necessita el seu propi reenviament IPv6, perquè el nucli aplica una decisió separada després que arribi el paquet. Tots dos han d’estar activats abans que una sola resposta creui el túnel.

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

Les regles de tallafocs han d’admetre després el rang d’origen intern en les dues direccions. Google Cloud avalua el paquet desencapsulat, així que una regla que només cobreix la subxarxa de la VPC descarta el trànsit del pool després que el túnel ja hagi tingut èxit. Afegiu el pool com a rang d’origen a la regla d’entrada i comproveu que cap política de sortida personalitzada bloqui la resposta. La regla de permís implícita cobreix el cas per defecte, una regla de sortida escrita a mà no.

Digueu a OpenVPN qui posseeix què

OpenVPN reenvia a un client quan sap que aquest client posseeix la destinació. Les adreces de client del pool les gestiona la directiva de servidor que defineix el pool, però una subxarxa darrere d’un client és una disposició diferent i necessita una entrada de propietat explícita per a aquest client.

Confondre les dues coses produeix un túnel on els pings al servidor funcionen i res del que hi ha darrere no. Decidiu quin cas esteu construint i després escriviu l’entrada corresponent en lloc d’afegir una segona línia push i esperar que funcioni.

Manteniu la sortida a internet fora d’aquest disseny

L’accés privat i l’accés a internet són plans separats. Un pool ULA pot arribar a les càrregues de treball de la VPC pel túnel un cop l’encaminament i el reenviament coincideixen, i aquest mateix pool no té camí cap a internet públic a través de la VPC, perquè la passarel·la cloud no acceptarà una font de túnel arbitrària com a pròpia.

Si els clients també necessiten sortida a internet, planifiqueu un disseny d’adreçament i encaminament suportat per a això, manteniu-lo independent del pool privat i proveu els dos camins per separat. Un camí que funciona no us diu res sobre l’altre, i un disseny que els confon falla d’una manera que sembla un túnel trencat.