De ce VM-ul dvs. din GCP nu poate răspunde la pool-ul IPv6 OpenVPN

Clientul dumneavoastră VPN IPv6 ajunge la sarcina de lucru, sarcina răspunde în tunel, iar răspunsul nu sosește niciodată. Primul instinct este să dăm vina pe firewall sau pe tunel, iar de obicei niciunul nu este vinovat. O adresă oferită de OpenVPN este o rețea internă care există doar în interiorul tunelului; Google Cloud nu are habar că fd42:90::/64 ar trebui să stea în spatele unei anumite VM până nu îi spuneți.

Două sisteme separate trebuie să învețe acest fapt, și doar unul dintre ele este OpenVPN. VPC-ul are nevoie de o rută înainte de a putea trimite ceva înapoi, iar VM-ului trebuie să i se permită să redirecționeze ce sosește. Greșiți în oricare dintre cele două jumătăți și simptomul arată identic.

Pool-ul este o rețea internă, nu o subrețea

OpenVPN poate oferi adrese IPv6 dintr-un interval pe care îl alegeți, iar acel interval este o ficțiune asupra căreia cad de acord cele două capete ale tunelului. Nu este o subrețea Google Cloud, nu apare în lista de subrețele a VPC-ului, iar interfața de rețea a VM-ului nu dobândește acele adrese. Prin urmare, o sarcină de lucru care răspunde unui client trimite un pachet către o adresă pe care rețeaua o consideră nerutabilă.

Țineți pool-ul în afara fiecărui interval pe care VPC-ul îl folosește deja. Țineți-l în afara și a intervalelor din spatele celorlalte tuneluri ale dumneavoastră. Suprapunerea transformă o eroare de rutare curată într-una intermitentă care apare doar sub sarcină.

Adresarea locală unică precum fd42:90::/64 este o alegere rezonabilă pentru această rețea internă. Prefixul amintește și că designul este privat prin construcție. Nimic dintr-un pool ULA nu îl face o sursă legitimă pe internetul public.

Dați VPC-ului o destinație și un următor salt

Răspunsul are nevoie de o rută VPC a cărei destinație este pool-ul și al cărei următor salt este VM-ul VPN. Documentația actuală despre rute statice acoperă intervalele de destinație IPv6 și enumeră ce tipuri de următor salt sunt eligibile, așa că verificați forma acceptată pentru topologia dumneavoastră în loc să copiați un exemplu IPv4 mai vechi.

O adresă de următor salt trebuie să fie una care este efectiv atribuită interfeței cloud a instanței. Adresa internă a tunelului VM-ului nu este acea adresă. Folosirea ei totuși produce o rută care se instalează curat și nu se potrivește niciodată cu un pachet. Citiți lista de interfețe înainte de a scrie ruta.

Precedența rutelor contează la fel de mult ca intrarea în sine. Rutele de subrețea sunt mai specifice decât rutele personalizate pe care le adăugați, așa că un pool decupat dintr-un interval de subrețea existent va pierde în fața rutei de subrețea, indiferent cum este scrisă ruta personalizată. Alegeți un pool distinct, apoi confirmați că ruta arată instanța ca următor salt și prefixul de destinație corect:

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

Redirecționarea trebuie activată de două ori

O rută livrează pachetul instanței. Ea nu face instanța dispusă să redirecționeze ceva ce nu îi este adresat, iar acea permisiune există la două niveluri.

Partea de cloud are nevoie de capacitatea de redirecționare a instanței activată; aceasta este setarea care permite unei VM să primească trafic pentru adrese pe care nu le deține și să îl transmită mai departe. Partea de guest are nevoie de propria redirecționare IPv6, deoarece nucleul ia o decizie separată după ce pachetul sosește. Ambele trebuie să fie pornite înainte ca un singur răspuns să traverseze tunelul.

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

Apoi regulile de firewall trebuie să admită intervalul sursă intern în ambele direcții. Google Cloud evaluează pachetul decapsulat, așa că o regulă care acoperă doar subrețeaua VPC-ului aruncă traficul pool-ului după ce tunelul a reușit deja. Adăugați pool-ul ca interval sursă în regula de intrare și verificați că nicio politică de ieșire personalizată nu blochează răspunsul. Regula de permisiune implicită acoperă cazul standard, o regulă de ieșire scrisă manual nu.

Spuneți OpenVPN cine deține ce

OpenVPN redirecționează către un client când știe că acel client deține destinația. Adresele clienților din pool sunt gestionate de directiva de server care definește pool-ul, dar o subrețea din spatele unui client este altă aranjare și necesită o intrare explicită de proprietate pentru acel client.

Confundarea celor două produce un tunel în care ping-urile către server funcționează și nimic din spatele lui. Decideți ce caz construiți, apoi scrieți intrarea corespunzătoare în loc să adăugați o a doua linie push și să sperați.

Țineți ieșirea spre internet în afara acestui design

Accesul privat și accesul la internet sunt planuri separate. Un pool ULA poate ajunge la sarcinile de lucru din VPC prin tunel odată ce rutarea și redirecționarea sunt de acord, iar același pool nu are nicio cale către internetul public prin VPC, deoarece gateway-ul de cloud nu va accepta o sursă de tunel arbitrară ca fiind a sa.

Dacă clienții au nevoie și de ieșire spre internet, planificați un design de adresare și rutare acceptat pentru asta, țineți-l independent de pool-ul privat și testați cele două căi separat. O cale care funcționează nu spune nimic despre cealaltă, iar un design care le confundă eșuează într-un mod care arată ca un tunel stricat.