Zakaj vaš VM v GCP ne more odgovoriti na bazen IPv6 OpenVPN

Vaš odjemalec VPN IPv6 doseže delovno obremenitev, delovna obremenitev odgovori v tunel, odgovor pa nikoli ne prispe. Prvi instinkt je kriviti požarni zid ali tunel, in običajno ni kriv nobeden od njiju. Naslov, ki ga dodeli OpenVPN, je notranje omrežje, ki obstaja le znotraj tunela; Google Cloud sploh ne ve, da bi moral biti fd42:90::/64 za eno določeno VM, dokler mu tega ne poveste.

To dejstvo se morata naučiti dva ločena sistema, in le eden od njiju je OpenVPN. VPC potrebuje pot, preden lahko karkoli pošlje nazaj, VM pa mora imeti dovoljenje za posredovanje tega, kar prispe. Zmotite se v kateri koli polovici in simptom je videti enak.

Bazen je notranje omrežje, ne podomrežje

OpenVPN lahko dodeljuje naslove IPv6 iz obsega, ki ga izberete, in ta obseg je fikcija, s katero se strinjata oba konca tunela. Ni podomrežje Google Cloud, ne pojavi se na seznamu podomrežij VPC in omrežni vmesnik VM teh naslovov ne dobi. Delovna obremenitev, ki odgovori odjemalcu, zato pošlje paket na naslov, ki ga omrežje šteje za neusmerljivega.

Držite bazen zunaj vsakega obsega, ki ga VPC že uporablja. Držite ga tudi zunaj obsegov za vašimi drugimi tuneli. Prekrivanje spremeni čisto napako usmerjanja v občasno, ki se pokaže le pod obremenitvijo.

Edinstveno lokalno naslavljanje, kot je fd42:90::/64, je razumna izbira za to notranje omrežje. Predpona tudi spomni, da je zasnova po naravi zasebna. Nič v bazenu ULA ga ne naredi zakonitega vira v javnem internetu.

Dajte VPC cilj in naslednji skok

Odgovor potrebuje pot VPC, katere cilj je bazen in katere naslednji skok je VM VPN. Trenutna dokumentacija o statičnih poteh pokriva ciljne obsege IPv6 in navaja, katere vrste naslednjega skoka so dovoljene, zato preverite podprto obliko za svojo topologijo, namesto da kopirate starejši primer IPv4.

Naslov naslednjega skoka mora biti tisti, ki je dejansko dodeljen oblačnemu vmesniku instance. Notranji naslov tunela VM ni ta naslov. Če ga vseeno uporabite, dobite pot, ki se namesti čisto in se nikoli ne ujema s paketom. Pred pisanjem poti preberite seznam vmesnikov.

Prednost poti je enako pomembna kot sam vnos. Poti podomrežij so bolj specifične od poti po meri, ki jih dodate, zato bo bazen, izrezan iz obstoječega obsega podomrežja, izgubil proti poti podomrežja, ne glede na to, kako je pot po meri napisana. Izberite ločen bazen in nato potrdite, da pot prikazuje instanco kot naslednji skok in pravilno ciljno predpono:

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

Posredovanje je treba omogočiti dvakrat

Pot dostavi paket instanci. Ne naredi instance pripravljene posredovati nečesa, kar ji ni naslovljeno, in to dovoljenje obstaja na dveh ravneh.

Oblačna stran potrebuje omogočeno zmožnost posredovanja instance; to je nastavitev, ki VM omogoča sprejemanje prometa za naslove, ki jih ne poseduje, in njegovo posredovanje. Gostujoča stran potrebuje lastno posredovanje IPv6, ker jedro po prihodu paketa sprejme ločeno odločitev. Oba morata biti vključena, preden en sam odgovor prečka tunel.

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

Nato morajo pravila požarnega zidu prepustiti notranji obseg vira v obe smeri. Google Cloud ocenjuje dekapsuliran paket, zato pravilo, ki pokriva le podomrežje VPC, zavrže promet bazena po tem, ko je tunel že uspel. Dodajte bazen kot obseg vira v vhodno pravilo in preverite, da nobena politika izhoda po meri ne blokira odgovora. Implicitno pravilo dovoljenja pokriva privzeti primer, ročno napisano pravilo izhoda pa ne.

Povejte OpenVPN, kdo kaj ima

OpenVPN posreduje odjemalcu, ko ve, da ta odjemalec ima cilj. Naslove odjemalcev iz bazena obravnava direktiva strežnika, ki definira bazen, vendar je podomrežje za odjemalcem drugačna ureditev in potrebuje izrecen vnos lastništva za tega odjemalca.

Zamenjava obeh ustvari tunel, v katerem pingi na strežnik delujejo, nič za njim pa ne. Odločite se, kateri primer gradite, in nato napišite ustrezen vnos, namesto da dodate drugo vrstico push in upate.

Držite internetni izhod zunaj te zasnove

Zasebni dostop in dostop do interneta sta ločena načrta. Bazen ULA lahko doseže delovne obremenitve VPC prek tunela, ko se usmerjanje in posredovanje ujameta, in isti bazen nima poti v javni internet prek VPC, ker oblačni prehod ne bo sprejel poljubnega vira tunela kot svojega.

Če odjemalci potrebujejo tudi internetni izhod, načrtujte zanj podprto zasnovo naslavljanja in usmerjanja, držite jo neodvisno od zasebnega bazena in preizkusite obe poti ločeno. Ena delujoča pot ne pove nič o drugi, zasnova, ki ju zameša, pa odpove tako, da je videti kot pokvarjen tunel.