Firwat Ären GCP-VM net op den OpenVPN IPv6-Pool äntweren kann

Ären IPv6 VPN-Client erreecht d’Aarbechtslaascht, d’Aarbechtslaascht äntwert an den Tunnel, an d’Äntwert kënnt ni un. Den éischten Instinkt ass d’Firewall oder den Tunnel ze beschëllegen, an normalerweis ass keent vun deenen zwee schëlleg. Eng Adress, déi vum OpenVPN ausgëtt, ass en internen Netz, dat nëmmen am Tunnel existéiert; Google Cloud huet keng Ahnung, datt fd42:90::/64 hannert enger bestëmmter VM soll sinn, bis Dir et him sot.

Zwee getrennte Systemer mussen dës Tatsaach léieren, an nëmmen ee vun hinne ass OpenVPN. Den VPC brauch eng Route, ier en eppes zréckschécke kann, an dem VM muss erlaabt ginn, weiderzeleeden, wat ukënnt. Vergeet Dir eng vun den zwou Halschenten, gesäit de Symptom identesch aus.

De Pool ass en internen Netz, keen Subnet

OpenVPN ka IPv6-Adressen aus engem Beräich ausginn, deen Dir wielt, an dee Beräich ass eng Fiktioun, iwwer déi sech déi zwou Tunnelenner eeneg sinn. Et ass kee Google Cloud-Subnet, et erschéngt net an der VPC-Subnetlëscht, an d’Netzwierkinterfacë vum VM kritt déi Adressen net. Eng Aarbechtslaascht, déi engem Client äntwert, schéckt dofir e Paket un eng Adress, déi den Netz als net-routbar ugesäit.

Halt de Pool aus all Beräich eraus, deen den VPC scho benotzt. Halt en och aus de Beräicher hannert Ären aneren Tunnelen eraus. Iwwerlappung mécht aus engem propperen Routingfehler een, deen nëmmen ënner Laascht optrëtt.

Eenzegaarteg lokal Adresséierung wéi fd42:90::/64 ass eng raisonnabel Wiel fir dësen internen Netz. De Prefix erënnert och drun, datt den Design vun Natur aus privat ass. Näischt un engem ULA-Pool mécht en zu enger legitimer Quell am ëffentlechen Internet.

Gitt dem VPC en Zil an en nächsten Hop

D’Äntwert brauch eng VPC-Route, där hiert Zil de Pool ass an där hiren nächsten Hop de VPN-VM ass. Déi aktuell Dokumentatioun iwwer statesch Routen deckt IPv6-Zilberäicher of a lëscht op, wéi eng nächst-Hop-Typen zoulässeg sinn, also iwwerpréift déi ënnerstëtzt Form fir Är Topologie, amplaz vun engem eelere IPv4-Beispill ze kopéieren.

Eng Adress vum nächsten Hop muss eng sinn, déi tatsächlech der Cloud-Interfacë vun der Instanz zougewisen ass. Déi intern Tunneladress vum VM ass déi Adress net. Se trotzdeem ze benotzen ergëtt eng Route, déi sech propper installéiert an ni mat engem Paket iwwerenee kënnt. Liest d’Interfacelëscht, ier Dir d’Route schreift.

D’Prioritéit vun der Route ass esou wichteg wéi den Aschreiwung selwer. Subnetrouten si méi spezifesch wéi déi personaliséiert Routen, déi Dir bäisetzt, also verléiert e Pool, deen aus engem existéierende Subnetberäich erausgeschnidden ass, géint d’Subnetroute, egal wéi d’personalisiert Route geschriwwen ass. Wielt en aparte Pool, a bestätegt dann, datt d’Route d’Instanz als nächsten Hop an de richtege Zilprefix weist:

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

Weiderleede muss zweemol aktivéiert ginn

Eng Route liwwert de Paket un d’Instanz. Se mécht d’Instanz awer net bereet, eppes weiderzeleeden, dat net un si adresséiert ass, an déi Erlaabnes existéiert op zwou Schichten.

D’Cloudsäit brauch d’Weiderleedungsfähegkeet vun der Instanz aktivéiert; dat ass d’Astellung, déi engem VM erlaabt, Traffic fir Adressen ze kréien, déi et net besëtzt, an en weiderzeginn. D’Gastsäit brauch hir eege IPv6-Weiderleedung, well de Kernel no der Ukunft vum Paket eng separat Entscheedung trëfft. Béid musse un sinn, ier eng eenzeg Äntwert den Tunnel iwwerquiert.

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

Dunn mussen d’Firewallregelen de internen Quellberäich a béide Richtungen zouloossen. Google Cloud evaluéiert de Paket nom Decapsuléieren, also eng Regel, déi nëmmen den VPC-Subnet deckt, verwerft den Traffic vum Pool, nodeems den Tunnel schonn erfollegräich war. Füügt de Pool als Quellberäich an d’Ingress-Regel bäi, a kontrolléiert, datt keng personaliséiert Egress-Politik d’Äntwert blockéiert. Déi implizit Erlaabnesregel deckt de Standardfall, eng handgeschriwwen Egress-Regel net.

Sot dem OpenVPN, wien wat besëtzt

OpenVPN leet un e Client weider, wann en weess, datt dee Client d’Zil besëtzt. Clientadressen aus dem Pool ginn duerch d’Serverdirektiv geréiert, déi de Pool definéiert, awer en Subnet hannert engem Client ass eng aner Opstellung a brauch eng explizit Besëtznotiz fir dee Client.

Déi zwee ze verwiesselen ergëtt en Tunnel, an deem Ping un de Server funktionéiert an näischt hannert him. Entscheet, wéi ee Fall Dir baut, a schreift dann den entspriechende Aschreiwung, amplaz eng zweet push-Zeil bäizesetzen an ze hoffen.

Halt den Internet-Egress aus dësem Design eraus

Private Zougang an Internetzougang sinn getrennt Pläng. En ULA-Pool kann VPC-Aarbechtslaaschte iwwer den Tunnel erreechen, wann Routing a Weiderleedung eens sinn, an dee selwechte Pool huet kee Wee zum ëffentlechen Internet iwwer den VPC, well d’Cloud-Gateway eng arbiträr Tunnelquell net als seng eegen acceptéiert.

Wann d’Cliente och Internet-Egress brauchen, plangt dofir en ënnerstëtzten Adresséierungs- a Routingdesign, haalt en onofhängeg vum private Pool a test d’zwee Weeër getrennt. Ee funktionéierende Wee seet näischt iwwer deen aneren, an en Design, deen déi zwee vermëscht, feelt op eng Manéier, déi wéi en brokene Tunnel ausgesäit.