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

Din IPv6 VPN-klient når arbejdsbyrden, arbejdsbyrden svarer ind i tunnelen, og svaret ankommer aldrig. Instinktet er at give firewallen eller tunnelen skylden, og ingen af dem er normalt skyld i det. En adresse, der uddeles af OpenVPN, er et indre netværk, som kun findes inde i tunnelen; Google Cloud aner ikke, at fd42:90::/64 skal ligge bag en bestemt VM, før du fortæller det.

To separate systemer skal lære den kendsgerning, og kun det ene af dem er OpenVPN. VPC’en har brug for en rute, før den kan sende noget tilbage, og VM’en skal have tilladelse til at videresende det, der ankommer. Tager du fejl i den ene halvdel, ser symptomet identisk ud.

Puljen er et indre netværk, ikke et subnet

OpenVPN kan uddele IPv6-adresser fra et interval, du vælger, og det interval er en fiktion, som de to tunnelendepunkter er enige om. Det er ikke et Google Cloud-subnet, det optræder ikke på VPC’ens subnetliste, og VM’ens netværksgrænseflade får ikke de adresser. En arbejdsbyrde, der svarer en klient, sender derfor en pakke til en adresse, som fabricen anser for ikke-rutbar.

Hold puljen uden for hvert interval, som VPC’en allerede bruger. Hold den også uden for intervallerne bag dine andre tunneler. Overlap gør en ren routingfejl til en periodisk en, som kun viser sig under belastning.

Unik lokal adressering som fd42:90::/64 er et rimeligt valg til dette indre netværk. Præfikset minder også om, at designet er privat af natur. Intet ved en ULA-pulje gør den til en lovlig kilde på det offentlige internet.

Giv VPC’en en destination og et næste hop

Svaret har brug for en VPC-rute, hvis destination er puljen, og hvis næste hop er VPN-VM’en. Den aktuelle dokumentation for statiske ruter dækker IPv6-destinationsintervaller og angiver, hvilke typer næste hop der er kvalificerede, så verificér den understøttede form til din topologi i stedet for at kopiere et ældre IPv4-eksempel.

En næste-hop-adresse skal være en, der faktisk er tildelt instansens cloud-grænseflade. VM’ens indre tunneladresse er ikke den adresse. Bruger du den alligevel, får du en rute, der installeres rent og aldrig matcher en pakke. Læs grænsefladelisten, før du skriver ruten.

Ruteprioritet betyder lige så meget som selve posten. Subnetruter er mere specifikke end de brugerdefinerede ruter, du tilføjer, så en pulje skåret ud af et eksisterende subnetinterval taber til subnetruten, uanset hvordan den brugerdefinerede rute er skrevet. Vælg en adskilt pulje, og bekræft derefter, at ruten viser instansen som næste hop og det korrekte destinationspræfiks:

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

Videresendelse skal slås til to gange

En rute leverer pakken til instansen. Den gør ikke instansen villig til at videresende noget, der ikke er adresseret til den, og den tilladelse findes på to lag.

Cloudsiden har brug for, at instansens videresendelsesevne er slået til; det er den indstilling, der lader en VM modtage trafik til adresser, den ikke ejer, og sende den videre. Gæstesiden har brug for sin egen IPv6-videresendelse, fordi kernen træffer en separat beslutning, efter pakken ankommer. Begge skal være slået til, før et eneste svar krydser tunnelen.

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

Derefter skal firewallregler tillade det indre kildeinterval i begge retninger. Google Cloud vurderer den afkapslede pakke, så en regel, der kun dækker VPC-subnettet, dropper puljens trafik, efter tunnelen allerede er lykkedes. Tilføj puljen som kildeinterval i ingressreglen, og kontrollér, at ingen brugerdefineret egress-politik blokerer svaret. Den implicitte tilladelsesregel dækker standardtilfældet, en håndskrevet egress-regel gør ikke.

Fortæl OpenVPN, hvem der ejer hvad

OpenVPN videresender til en klient, når den ved, at klienten ejer destinationen. Klientadresser fra puljen håndteres af det serverdirektiv, der definerer puljen, men et subnet bag en klient er en anden opsætning og kræver en udtrykkelig ejerskabspost for den klient.

Forveksler man de to, får man en tunnel, hvor ping til serveren virker, og intet bag den gør. Beslut, hvilket tilfælde du bygger, og skriv så den matchende post i stedet for at tilføje en ekstra push-linje og håbe.

Hold internettrafik uden for dette design

Privat adgang og internetadgang er separate planer. En ULA-pulje kan nå VPC-arbejdsbyrder over tunnelen, når routing og videresendelse er enige, og den samme pulje har ingen vej til det offentlige internet gennem VPC’en, fordi cloud-gatewayen ikke accepterer en vilkårlig tunnelkilde som sin egen.

Hvis klienterne også har brug for internetadgang, så planlæg et understøttet adresserings- og routingdesign til det, hold det uafhængigt af den private pulje, og test de to veje hver for sig. En fungerende vej siger intet om den anden, og et design, der blander dem sammen, fejler på en måde, der ligner en brudt tunnel.