Wêrom't jo GCP-VM net antwurdzje kin op 'e OpenVPN IPv6-pool

Jo IPv6 VPN-klant berikt de wurklast, de wurklast antwurdet yn ’e tunnel, en it antwurd komt nea oan. De earste ympuls is de firewall of de tunnel de skuld jaan, en gjin fan beide is meastentiids skuldich. In adres dat troch OpenVPN útjûn wurdt, is in yntern netwurk dat allinnich binnen de tunnel bestiet; Google Cloud wit net dat fd42:90::/64 efter ien beskate VM heart te lizzen oant jo it har fertelle.

Twa aparte systemen moatte dat feit leare, en mar ien fan har is OpenVPN. De VPC hat in route nedich foar’t er eat weromstjoere kin, en de VM moat tastien wurde troch te stjoeren wat oankomt. Krij jo ien fan ’e beide helten ferkeard, dan liket it symptoom itselde.

De pool is in yntern netwurk, gjin subnet

OpenVPN kin IPv6-adressen útjaan út in berik dat jo kieze, en dat berik is in fiksje dêr’t de twa tunneleinen it oer iens binne. It is gjin Google Cloud-subnet, it stiet net yn ’e VPC-subnetlist, en de netwurkynterface fan ’e VM krijt dy adressen net. In wurklast dy’t in klant antwurdet, stjoert dêrom in pakket nei in adres dat it netwurk as net-rûtber beskôget.

Hâld de pool bûten elk berik dat de VPC al brûkt. Hâld him ek bûten de beriken efter jo oare tunnels. Oerlaap makket fan in skjinne rûtfout ien dy’t tuskentroch optreedt en allinnich ûnder lêst te sjen is.

Unike lokale adressearring lykas fd42:90::/64 is in ridlike kar foar dit ynterne netwurk. It foarheaksel tsjinnet ek as herinnering dat it ûntwerp fan natuere privee is. Neat oan in ULA-pool makket him in legale boarne op it iepenbiere ynternet.

Jou de VPC in bestimming en in folgjende hop

It antwurd hat in VPC-route nedich wêrfan de bestimming de pool is en wêrfan de folgjende hop de VPN-VM is. De hjoeddeiske dokumintaasje oer statyske routes beslacht IPv6-bestimmingsberiken en listet op hokker folgjende-hop-typen yn oanmerking komme, dus kontrolearje de stipe foarm foar jo topology ynstee fan in âlder IPv4-foarbyld te kopiearjen.

In folgjende-hop-adres moat ien wêze dy’t echt oan ’e cloud-ynterface fan ’e ynstânsje tawiisd is. It ynterne tunneladres fan ’e VM is dat adres net. It dochs brûke leveret in route op dy’t skjin ynstallearret en nea in pakket matcht. Lês de ynterfacelist foar’t jo de route skriuwe.

Rûtprioriteit is like wichtich as de yngong sels. Subnetroutes binne spesifiker as de oanpaste routes dy’t jo tafoegje, dus in pool dy’t út in besteand subnetberik snien is, ferliest fan ’e subnetroute, hoe’t de oanpaste route ek skreaun is. Kies in aparte pool en befêstigje dan dat de route de ynstânsje as folgjende hop en it krekte bestimmingsfoarheaksel toant:

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

Trochstjoeren moat twa kear oansetten wurde

In route leveret it pakket by de ynstânsje. It makket de ynstânsje net ree om eat troch te stjoeren dat net oan him rjochte is, en dy tastimming bestiet op twa lagen.

De cloudkant hat de trochstjoerkapasiteit fan ’e ynstânsje oansetten nedich; dat is de ynstelling dy’t in VM tastiet ferkear foar adressen dy’t er net besit te ûntfangen en troch te jaan. De gastkant hat syn eigen IPv6-trochstjoeren nedich, om’t de kernel nei oankomst fan it pakket in aparte beslissing nimt. Beide moatte oan wêze foar’t ien inkeld antwurd de tunnel oerstekt.

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

Firewallregels moatte dan it ynterne boarneberik yn beide rjochtingen talitte. Google Cloud beoardielet it ûntkapsele pakket, dus in regel dy’t allinnich it VPC-subnet beslacht, smyt it poelferkear fuort neidat de tunnel al slagge is. Foegje de pool as boarneberik ta oan ’e yngongsregel en kontrolearje dat gjin oanpast útfierbelied it antwurd blokkearret. De ymplisite tastienregel beslacht it standertgefal, in hânskreaune útfierregel net.

Fertel OpenVPN wa’t wat besit

OpenVPN stjoert troch nei in klant as er wit dat dy klant de bestimming besit. Klantadressen út ’e pool wurde behannele troch de serverrjochtline dy’t de pool definiearret, mar in subnet efter in klant is in oare opstelling en hat in eksplisite eigendomsyngong foar dy klant nedich.

De beide trochinoar helje jout in tunnel wêryn ping nei de server wurket en neat efter him. Beslis hokker gefal jo bouwe, en skriuw dan de byhearrende yngong ynstee fan in twadde push-rige ta te foegjen en te hoopjen.

Hâld ynternetútfier bûten dit ûntwerp

Privee tagong en ynternettagong binne aparte plannen. In ULA-pool kin VPC-wurklasten oer de tunnel berikke as rûtering en trochstjoeren iens binne, en deselde pool hat gjin paad nei it iepenbiere ynternet fia de VPC, om’t de cloudgateway in willekeurige tunnelboarne net as syn eigen akseptearret.

As klanten ek ynternetútfier nedich hawwe, plan dan in stipe adressearrings- en rûteringsûntwerp dêrfoar, hâld it ûnôfhinklik fan ’e privee pool en test de twa paden apart. Ien wurkjend paad seit neat oer it oare, en in ûntwerp dat se trochinoar hellet, mislearret op in manier dy’t as in brutsen tunnel liket.