Kvifor GCP-VM-en din ikkje kan svare på OpenVPN IPv6-poolen

IPv6 VPN-klienten din når arbeidslasta, arbeidslasta svarar inn i tunnelen, og svaret kjem aldri fram. Instinktet er å skylde på brannmuren eller tunnelen, og ingen av dei er vanlegvis skuld i det. Ei adresse som blir delt ut av OpenVPN, er eit indre nettverk som berre finst inne i tunnelen; Google Cloud veit ikkje at fd42:90::/64 skal ligge bak ein bestemt VM før du fortel det.

To skilde system må lære denne faktaen, og berre eitt av dei er OpenVPN. VPC-en treng ei rute før han kan sende noko tilbake, og VM-en må få lov til å videresende det som kjem inn. Tek du feil i ein av halvdelane, ser symptomet likt ut.

Poolen er eit indre nettverk, ikkje eit subnett

OpenVPN kan dele ut IPv6-adresser frå eit område du vel, og det området er ein fiksjon dei to tunnelendane er samde om. Det er ikkje eit Google Cloud-subnett, det visest ikkje i subnettlista til VPC-en, og nettverksgrensesnittet til VM-en får ikkje desse adressene. Ei arbeidslast som svarar ein klient, sender difor ein pakke til ei adresse som nettverket reknar som ikkje-rutbar.

Hald poolen utanfor kvart område VPC-en alt brukar. Hald han òg utanfor områda bak dei andre tunnelane dine. Overlapp gjer ein rein rutingsfeil om til ein periodisk ein som berre dukkar opp under belastning.

Unik lokal adressering som fd42:90::/64 er eit rimeleg val for dette indre nettverket. Prefikset minner òg om at designet er privat av natur. Ingenting ved ein ULA-pool gjer han til ein lovleg kjelde på det opne internettet.

Gje VPC-en ein destinasjon og eit neste hopp

Svaret treng ei VPC-rute der destinasjonen er poolen og neste hopp er VPN-VM-en. Gjeldande dokumentasjon for statiske ruter dekkjer IPv6-destinasjonsområde og listar opp kva typar neste hopp som er kvalifiserte, så verifiser den støtta forma for topologien din i staden for å kopiere eit eldre IPv4-døme.

Ei neste-hopp-adresse må vere ei som faktisk er tildelt skygrensesnittet til instansen. Den indre tunneladressa til VM-en er ikkje den adressa. Brukar du ho likevel, får du ei rute som blir installert reint og aldri matchar ein pakke. Les grensesnittlista før du skriv ruta.

Ruteprioritet er like viktig som oppføringa sjølv. Subnett-ruter er meir spesifikke enn dei eigendefinerte rutene du legg til, så ein pool skoren ut av eit eksisterande subnettområde vil tape mot subnett-ruta, same korleis den eigendefinerte ruta er skriven. Vel ein eigen pool, og stadfest deretter at ruta viser instansen som neste hopp og rett destinasjonsprefiks:

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

Videresending må slåast på to gonger

Ei rute leverer pakken til instansen. Ho gjer ikkje instansen viljug til å videresende noko som ikkje er adressert til han, og den løyva finst på to nivå.

Skysida treng at videresendingsevna til instansen er slått på; det er innstillinga som lèt ein VM ta imot trafikk for adresser han ikkje eig og sende han vidare. Gjestesida treng si eiga IPv6-videresending, fordi kjernen tek ei skild avgjerd etter at pakken kjem inn. Begge må vere på før eitt einaste svar kryssar tunnelen.

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

Deretter må brannmurreglane tillate det indre kjeldeområdet i båe retningar. Google Cloud vurderer den avkapsla pakken, så ein regel som berre dekkjer VPC-subnettet slepp pooltrafikken etter at tunnelen alt har lukkast. Legg poolen til som kjeldeområde i inngangsregelen, og kontroller at ingen eigendefinert utgangspolicy blokkerer svaret. Den implisitte løyveregelen dekkjer standardtilfellet, ein handskriven utgangsregel gjer det ikkje.

Fortel OpenVPN kven som eig kva

OpenVPN videresender til ein klient når han veit at klienten eig destinasjonen. Klientadresser frå poolen blir handsama av serverdirektivet som definerer poolen, men eit subnett bak ein klient er ei anna ordning og krev ei eksplisitt eigarskapsoppføring for den klienten.

Blandar du dei to, får du ein tunnel der ping til tenaren verkar og ingenting bak han. Avgjer kva tilfelle du byggjer, og skriv deretter den matchande oppføringa i staden for å leggje til ei ekstra push-linje og håpe.

Hald internett-utgangen utanfor dette designet

Privat tilgang og internettilgang er skilde planar. Ein ULA-pool kan nå VPC-arbeidslaster over tunnelen når ruting og videresending er samde, og den same poolen har ingen veg til det opne internettet gjennom VPC-en, fordi skyporten ikkje vil godta ei vilkårleg tunnelkjelde som si eiga.

Viss klientane òg treng internett-utgang, planlegg eit støtta adresserings- og rutingsdesign for det, hald det uavhengig av den private poolen, og test dei to vegane kvar for seg. Éin fungerande veg seier ingenting om den andre, og eit design som blandar dei saman, feilar på ein måte som ser ut som ein øydelagd tunnel.