Hvers vegna GCP-VM-inn þinn getur ekki svarað OpenVPN IPv6-safninu

IPv6 VPN-biðlarinn þinn nær í vinnuálagið, vinnuálagið svarar inn í göngin og svarið kemur aldrei. Fyrsta eðlishvötin er að kenna eldveggnum eða göngunum um, og hvorugt er venjulega sek um það. Heimilisfang sem OpenVPN úthlutar er innra net sem er aðeins til inni í göngunum; Google Cloud hefur ekki hugmynd um að fd42:90::/64 eigi að vera bak við eitt tiltekið VM fyrr en þú segir því það.

Tvö aðskilin kerfi verða að læra þessa staðreynd, og aðeins annað þeirra er OpenVPN. VPC-ið þarf leið áður en það getur sent eitthvað til baka, og VM-inu verður að vera heimilað að senda áfram það sem berst. Farðu rangt í öðrum hvorum helmingnum og einkennin líta eins út.

Safnið er innra net, ekki undirnet

OpenVPN getur úthlutað IPv6-heimilisföngum úr sviði sem þú velur, og það svið er skáldskapur sem tveir endar ganganna samþykkja. Það er ekki Google Cloud undirnet, það birtist ekki í undirnetslista VPC-sins, og netkort VM-sins fær ekki þessi heimilisföng. Þess vegna sendir vinnuálag sem svarar biðlara pakka á heimilisfang sem netið telur óleiðanlegt.

Haltu safninu utan við hvert svið sem VPC-ið notar þegar. Haltu því líka utan við sviðin bak við önnur göngin þín. Skörun breytir hreinni leiðarvillu í slitrótta villu sem kemur aðeins fram undir álagi.

Einstakt staðbundið heimilisföng eins og fd42:90::/64 er hæfilegur valkostur fyrir þetta innra net. Forskeytið minnir líka á að hönnunin er einkaaðili í eðli sínu. Ekkert við ULA-safn gerir það að lögmætri uppsprettu á opinberu internetinu.

Gefðu VPC-inu áfangastað og næsta hopp

Svarið þarf VPC-leið þar sem áfangastaðurinn er safnið og næsta hopp er VPN-VM-ið. Núverandi skjöl um kyrrstæðar leiðir ná yfir IPv6-áfangastaðasvið og telja upp hvaða tegundir næsta hopps koma til greina, svo staðfestu studda mynd fyrir topólógíuna þína í stað þess að afrita eldra IPv4-dæmi.

Heimilisfang næsta hopps verður að vera eitt sem er í raun úthlutað til skýjaviðmóts tilviksins. Innra gönguheimilisfang VM-sins er ekki það heimilisfang. Að nota það samt framleiðir leið sem setur sig hreint og passar aldrei við pakka. Lestu viðmótslistann áður en þú skrifar leiðina.

Forgangur leiðar skiptir jafn miklu og færslan sjálf. Undirnetsleiðir eru nákvæmari en sérsniðnu leiðirnar sem þú bætir við, svo safn sem er skorið úr núverandi undirnetssviði tapar gegn undirnetsleiðinni, sama hvernig sérsniðna leiðin er skrifuð. Veldu aðskilið safn og staðfestu síðan að leiðin sýni tilvikið sem næsta hopp og rétta áfangastaðarforskeytið:

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

Virkja verður áfram sendingu tvisvar

Leið skilar pakkanum til tilviksins. Hún gerir tilvikið ekki fús til að senda áfram eitthvað sem er ekki beint að því, og það leyfi er til á tveimur lögum.

Skýjahliðin þarf að hafa kveikt á áfram sendingargetu tilviksins; það er stillingin sem leyfir VM-i að taka við umferð fyrir heimilisföng sem það á ekki og senda hana áfram. Gestahliðin þarf sína eigin IPv6-áfram sendingu, því kjarninn tekur aðra ákvörðun eftir að pakkinn berst. Bæði verða að vera kveikt áður en eitt svar fer í gegnum göngin.

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

Þá verða eldveggjareglur að hleypa innra uppsprettusviðinu í báðar áttir. Google Cloud metur afhjúpaða pakkann, svo regla sem nær aðeins yfir undirnet VPC-sins sleppir umferð safnsins eftir að göngin hafa þegar heppnast. Bættu safninu við sem uppsprettusviði í inngangsreglunni og athugaðu að engin sérsniðin útgangsstefna hindri svarið. Óbeina heimildarreglan nær yfir sjálfgefna tilfellið, handskrifuð útgangsregla ekki.

Segðu OpenVPN hver á hvað

OpenVPN sendir áfram til biðlara þegar það veit að sá biðlari á áfangastaðinn. Biðlaraheimilisföng úr safninu eru meðhöndluð af þjónarleiðbeiningunni sem skilgreinir safnið, en undirnet bak við biðlara er önnur uppsetning og þarf skýra eignarfærslu fyrir þann biðlara.

Að rugla þessu tvennu framleiðir göng þar sem ping til þjónsins virka og ekkert bak við hann. Ákveddu hvaða tilfelli þú ert að byggja og skrifaðu síðan samsvarandi færslu í stað þess að bæta við annarri push-línu og vona.

Haltu internetútganginum utan við þessa hönnun

Einkaaðgangur og internet-aðgangur eru aðskilin áætlanir. ULA-safn getur náð í VPC-vinnuálag í gegnum göngin þegar leiðsögn og áfram sending eru sammála, og sama safnið hefur enga leið á opinbera internetið í gegnum VPC-ið, því skýjahliðið samþykkir ekki handahófskennda gönguuppsprettu sem sína eigin.

Ef biðlarar þurfa líka internetútgang, skipuleggðu studda heimilisföngs- og leiðsagnarhönnun fyrir það, haltu henni óháðri einkasafninu og prófaðu leiðirnar tvær aðskildar. Ein virk leið segir ekkert um hina, og hönnun sem blandar þeim saman mistekst á þann hátt að það lítur út eins og brotin göng.