Zašto vaša GCP VM ne može odgovoriti na OpenVPN IPv6 pool

Vaš IPv6 VPN klijent dolazi do radnog opterećenja, radno opterećenje odgovara u tunel, a odgovor nikada ne stiže. Prva pomisao je kriviti firewall ili tunel, a obično nijedno od toga nije krivo. Adresa koju dodjeljuje OpenVPN je unutrašnja mreža koja postoji samo unutar tunela; Google Cloud nema pojma da bi fd42:90::/64 trebalo biti iza jedne određene VM sve dok mu vi to ne kažete.

Dva odvojena sistema moraju naučiti tu činjenicu, a samo je jedan od njih OpenVPN. VPC-u treba ruta prije nego što može bilo šta poslati natrag, a VM-u mora biti dopušteno prosljeđivanje onoga što stigne. Pogriješite li bilo koju polovinu, simptom izgleda identično.

Pool je unutrašnja mreža, a ne podmreža

OpenVPN može dodjeljivati IPv6 adrese iz raspona koji odaberete, a taj raspon je fikcija oko koje se dva kraja tunela slažu. On nije Google Cloud podmreža, ne pojavljuje se na popisu VPC podmreža, a mrežno sučelje VM-a ne dobija te adrese. Radno opterećenje koje odgovara klijentu zato šalje paket na adresu koju mrežna infrastruktura smatra nerutabilnom.

Držite pool izvan svakog raspona koji VPC već koristi. Držite ga i izvan raspona iza vaših drugih tunela. Preklapanje pretvara čistu grešku rutiranja u povremenu koja se pojavljuje samo pod opterećenjem.

Jedinstveno lokalno adresiranje poput fd42:90::/64 razuman je izbor za ovu unutrašnju mrežu. Prefiks služi i kao podsjetnik da je dizajn privatan po svojoj prirodi. Ništa u vezi s ULA poolom ne čini ga legalnim izvorom na javnom internetu.

Dajte VPC-u odredište i sljedeći skok

Odgovoru treba VPC ruta čije je odredište pool i čiji je sljedeći skok VPN VM. Aktualna dokumentacija o statičkim rutama pokriva IPv6 odredišne raspone i navodi koji su tipovi sljedećeg skoka prihvatljivi, pa provjerite podržani oblik za svoju topologiju umjesto da kopirate stariji IPv4 primjer.

Adresa sljedećeg skoka mora biti ona koja je stvarno dodijeljena cloud sučelju instance. Unutrašnja adresa tunela VM-a nije ta adresa. Ako je ipak upotrijebite, dobijate rutu koja se čisto instalira i nikada ne odgovara nijednom paketu. Pročitajte popis sučelja prije nego što napišete rutu.

Prioritet rute jednako je važan kao i sam unos. Rute podmreža su specifičnije od prilagođenih ruta koje dodajete, pa će pool izrezan iz postojećeg raspona podmreže izgubiti od rute podmreže bez obzira na to kako je prilagođena ruta napisana. Odaberite poseban pool, zatim potvrdite da ruta prikazuje instancu kao sljedeći skok i ispravan prefiks odredišta:

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

Prosljeđivanje se mora omogućiti dvaput

Ruta dostavlja paket instanci. Ona ne čini instancu voljnom prosljeđivati nešto što nije adresirano na nju, a to dopuštenje postoji na dva sloja.

Cloud strana treba omogućenu mogućnost prosljeđivanja instance; to je postavka koja VM-u dopušta primanje prometa za adrese koje ne posjeduje i njegovo prosljeđivanje. Gostujuća strana treba vlastito IPv6 prosljeđivanje, jer kernel donosi odvojenu odluku nakon što paket stigne. Oboje mora biti uključeno prije nego ijedan odgovor prijeđe tunel.

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

Firewall pravila zatim moraju propuštati unutrašnji raspon izvora u oba smjera. Google Cloud ocjenjuje dekapsulirani paket, pa pravilo koje pokriva samo VPC podmrežu odbacuje promet poola nakon što je tunel već uspio. Dodajte pool kao raspon izvora u ulazno pravilo i provjerite da nijedna prilagođena izlazna politika ne blokira odgovor. Implicitno pravilo dopuštanja pokriva zadani slučaj, rukom napisano izlazno pravilo ne.

Recite OpenVPN-u ko šta posjeduje

OpenVPN prosljeđuje klijentu kada zna da taj klijent posjeduje odredište. Klijentske adrese iz poola obrađuje serverska direktiva koja definira pool, ali podmreža iza klijenta drugačiji je raspored i treba joj izričit unos vlasništva za tog klijenta.

Miješanje to dvoje daje tunel u kojem pingovi prema serveru rade, a ništa iza njega ne. Odlučite koji slučaj gradite, zatim napišite odgovarajući unos umjesto da dodajete drugi push red i nadate se.

Držite internetski izlaz izvan ovog dizajna

Privatni pristup i internetski pristup odvojeni su planovi. ULA pool može dosegnuti VPC radna opterećenja kroz tunel kada se rutiranje i prosljeđivanje usaglase, a taj isti pool nema put do javnog interneta kroz VPC, jer cloud gateway neće prihvatiti proizvoljan izvor tunela kao svoj.

Ako klijentima treba i internetski izlaz, planirajte za to podržan dizajn adresiranja i rutiranja, držite ga neovisnim od privatnog poola i testirajte dva puta odvojeno. Jedan put koji radi ne govori ništa o drugom, a dizajn koji ih spaja pada na način koji izgleda kao pokvaren tunel.