Prečo vaša VM v GCP nemôže odpovedať na IPv6 pool OpenVPN

Váš IPv6 VPN klient dosiahne pracovné zaťaženie, pracovné zaťaženie odpovedá do tunela a odpoveď nikdy nedorazí. Prvý inštinkt je viniť firewall alebo tunel, a zvyčajne nie je vinné ani jedno. Adresa, ktorú prideľuje OpenVPN, je vnútorná sieť, ktorá existuje len vnútri tunela; Google Cloud netuší, že fd42:90::/64 má byť za jednou konkrétnou VM, kým mu to nepoviete.

Túto skutočnosť sa musia naučiť dva oddelené systémy a len jeden z nich je OpenVPN. VPC potrebuje trasu, aby mohlo niečo poslať späť, a VM musí mať povolené preposielať to, čo prichádza. Pomýlite sa v ktorejkoľvek polovici a príznak vyzerá rovnako.

Pool je vnútorná sieť, nie podsieť

OpenVPN môže prideľovať adresy IPv6 z rozsahu, ktorý si vyberiete, a tento rozsah je fikcia, na ktorej sa zhodnú oba konce tunela. Nie je to podsieť Google Cloud, neobjavuje sa v zozname podsietí VPC a sieťové rozhranie VM tieto adresy nezíska. Preto pracovné zaťaženie, ktoré odpovedá klientovi, posiela paket na adresu, ktorú sieť považuje za nesmerovateľnú.

Držte pool mimo každého rozsahu, ktorý VPC už používa. Držte ho aj mimo rozsahov za vašimi ďalšími tunelmi. Prekrytie mení čisté zlyhanie smerovania na občasné, ktoré sa prejaví len pod záťažou.

Unikátne lokálne adresovanie ako fd42:90::/64 je pre túto vnútornú sieť rozumná voľba. Prefix tiež pripomína, že návrh je od základu privátny. Nič na poole ULA z neho nerobí legitímny zdroj na verejnom internete.

Dajte VPC cieľ a ďalší skok

Odpoveď potrebuje trasu VPC, ktorej cieľom je pool a ktorej ďalším skokom je VM s VPN. Aktuálna dokumentácia statických trás pokrýva cieľové rozsahy IPv6 a uvádza, ktoré typy ďalšieho skoku sú prípustné, takže si overte podporovanú podobu pre svoju topológiu, namiesto kopírovania staršieho príkladu IPv4.

Adresa ďalšieho skoku musí byť tá, ktorá je skutočne pridelená cloudovému rozhraniu inštancie. Vnútorná adresa tunela VM touto adresou nie je. Keď ju napriek tomu použijete, vznikne trasa, ktorá sa čisto nainštaluje a nikdy nezodpovedá žiadnemu paketu. Prečítajte si zoznam rozhraní, kým trasu napíšete.

Priorita trasy je rovnako dôležitá ako samotný záznam. Trasy podsietí sú konkrétnejšie než vlastné trasy, ktoré pridáte, takže pool vyrezaný z existujúceho rozsahu podsiete prehrá s trasou podsiete bez ohľadu na to, ako je vlastná trasa napísaná. Vyberte samostatný pool a potom potvrďte, že trasa zobrazuje inštanciu ako ďalší skok a správny cieľový prefix:

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

Preposielanie treba povoliť dvakrát

Trasa doručí paket inštancii. Neurobí však inštanciu ochotnou preposielať niečo, čo jej nie je adresované, a toto oprávnenie existuje v dvoch vrstvách.

Cloudová strana potrebuje zapnutú schopnosť preposielania inštancie; je to nastavenie, ktoré nechá VM prijímať prevádzku pre adresy, ktoré nevlastní, a odovzdávať ju ďalej. Hosťovská strana potrebuje svoje vlastné preposielanie IPv6, pretože jadro po doručení paketu rozhoduje samostatne. Obe musia byť zapnuté, kým jedna odpoveď prejde tunelom.

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

Potom musia pravidlá firewallu prepustiť vnútorný rozsah zdroja v oboch smeroch. Google Cloud vyhodnocuje dekapsulovaný paket, takže pravidlo, ktoré pokrýva len podsieť VPC, zahodí prevádzku poolu po tom, ako tunel už uspel. Pridajte pool ako rozsah zdroja do ingress pravidla a skontrolujte, že odpoveď neblokuje žiadna vlastná egress politika. Implicitné pravidlo povolenia pokrýva predvolený prípad, ručne napísané egress pravidlo nie.

Povedzte OpenVPN, kto čo vlastní

OpenVPN preposiela klientovi, keď vie, že tento klient vlastní cieľ. Klientske adresy z poolu obsluhuje direktíva servera, ktorá pool definuje, ale podsieť za klientom je iné usporiadanie a potrebuje pre tohto klienta výslovný záznam vlastníctva.

Zámena oboch vytvorí tunel, kde pingy na server fungujú a nič za ním nie. Rozhodnite, ktorý prípad staviate, a potom napíšte zodpovedajúci záznam, namiesto pridania druhého riadku push a dúfania.

Držte internetový výstup mimo tento návrh

Privátny prístup a prístup na internet sú oddelené plány. Pool ULA môže dosiahnuť pracovné zaťaženia VPC cez tunel, keď sa smerovanie a preposielanie zhodnú, a ten istý pool nemá cestu na verejný internet cez VPC, pretože cloudová brána neprijme ľubovoľný zdroj tunela ako svoj.

Ak klienti potrebujú aj internetový výstup, naplánujte preň podporovaný návrh adresovania a smerovania, držte ho nezávislý od privátneho poolu a testujte obe cesty oddelene. Jedna funkčná cesta nič nehovorí o druhej a návrh, ktorý ich zleje, zlyhá spôsobom, ktorý vyzerá ako pokazený tunel.