Hvorfor GCP-VM-en din ikke kan svare på OpenVPN IPv6-poolen

IPv6 VPN-klienten din når arbeidslasten, arbeidslasten svarer inn i tunnelen, og svaret kommer aldri frem. Instinktet er å skylde på brannmuren eller tunnelen, og ingen av dem er vanligvis skyld i det. En adresse som deles ut av OpenVPN, er et indre nettverk som bare finnes inne i tunnelen; Google Cloud aner ikke at fd42:90::/64 skal ligge bak en bestemt VM før du forteller det.

To separate systemer må lære dette faktum, og bare ett av dem er OpenVPN. VPC-en trenger en rute før den kan sende noe tilbake, og VM-en må få lov til å videresende det som kommer inn. Tar du feil i én av halvdelene, ser symptomet identisk ut.

Poolen er et indre nettverk, ikke et subnett

OpenVPN kan dele ut IPv6-adresser fra et område du velger, og det området er en fiksjon de to tunnelendene er enige om. Det er ikke et Google Cloud-subnett, det vises ikke i VPC-ens subnettliste, og nettverksgrensesnittet til VM-en får ikke disse adressene. En arbeidslast som svarer en klient, sender derfor en pakke til en adresse som nettverket anser som ikke-rutbar.

Hold poolen utenfor hvert område VPC-en allerede bruker. Hold den også utenfor områdene bak de andre tunnelene dine. Overlapp gjør en ren rutingfeil om til en periodisk en som bare dukker opp under belastning.

Unik lokal adressering som fd42:90::/64 er et rimelig valg for dette indre nettverket. Prefikset minner også om at designet er privat av natur. Ingenting ved en ULA-pool gjør den til en lovlig kilde på det åpne internettet.

Gi VPC-en en destinasjon og et neste hopp

Svaret trenger en VPC-rute der destinasjonen er poolen og neste hopp er VPN-VM-en. Gjeldende dokumentasjon for statiske ruter dekker IPv6-destinasjonsområder og lister opp hvilke typer neste hopp som er kvalifiserte, så verifiser den støttede formen for topologien din i stedet for å kopiere et eldre IPv4-eksempel.

En neste-hopp-adresse må være en som faktisk er tildelt skygrensesnittet til instansen. Den indre tunneladressen til VM-en er ikke den adressen. Bruker du den likevel, får du en rute som installeres rent og aldri matcher en pakke. Les grensesnittlisten før du skriver ruten.

Ruteprioritet er like viktig som oppføringen selv. Subnett-ruter er mer spesifikke enn de egendefinerte rutene du legger til, så en pool skåret ut av et eksisterende subnettområde vil tape mot subnett-ruten, uansett hvordan den egendefinerte ruten er skrevet. Velg en egen pool, og bekreft deretter at ruten viser instansen som neste hopp og riktig 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å aktiveres to ganger

En rute leverer pakken til instansen. Den gjør ikke instansen villig til å videresende noe som ikke er adressert til den, og den tillatelsen finnes på to nivåer.

Skysiden trenger at instansens videresendingsevne er aktivert; det er innstillingen som lar en VM motta trafikk for adresser den ikke eier og sende den videre. Gjestesiden trenger sin egen IPv6-videresending, fordi kjernen tar en separat avgjørelse etter at pakken ankommer. Begge må være på før et eneste svar krysser tunnelen.

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

Deretter må brannmurreglene tillate det indre kildeområdet i begge retninger. Google Cloud vurderer den avkapslede pakken, så en regel som bare dekker VPC-subnettet slipper pooltrafikken etter at tunnelen allerede har lykkes. Legg poolen til som kildeområde i inngangsregelen, og kontroller at ingen egendefinert utgangspolicy blokkerer svaret. Den implisitte tillatelsesregelen dekker standardtilfellet, en håndskrevet utgangsregel gjør det ikke.

Fortell OpenVPN hvem som eier hva

OpenVPN videresender til en klient når den vet at klienten eier destinasjonen. Klientadresser fra poolen håndteres av serverdirektivet som definerer poolen, men et subnett bak en klient er en annen ordning og krever en eksplisitt eierskapsoppføring for den klienten.

Forveksler du de to, får du en tunnel der ping til serveren virker og ingenting bak den. Bestem hvilket tilfelle du bygger, og skriv deretter den matchende oppføringen i stedet for å legge til en ekstra push-linje og håpe.

Hold internett-utgangen utenfor dette designet

Privat tilgang og internettilgang er separate planer. En ULA-pool kan nå VPC-arbeidslaster over tunnelen når ruting og videresending er enige, og den samme poolen har ingen vei til det åpne internettet gjennom VPC-en, fordi skygatewayen ikke vil godta en vilkårlig tunnelkilde som sin egen.

Hvis klientene også trenger internett-utgang, planlegg et støttet adresserings- og rutingsdesign for det, hold det uavhengig av den private poolen, og test de to veiene hver for seg. Én fungerende vei sier ingenting om den andre, og et design som blander dem sammen, feiler på en måte som ser ut som en ødelagt tunnel.