Kial via VM en GCP ne povas respondi al la IPv6-adresaro de OpenVPN

Via IPv6 VPN-kliento atingas la laborŝarĝon, la laborŝarĝo respondas en la tunelon, kaj la respondo neniam alvenas. La unua instinkto estas kulpigi la fajroŝirmilon aŭ la tunelon, kaj kutime nek unu nek la alia kulpas. Adreso donita de OpenVPN estas interna reto, kiu ekzistas nur ene de la tunelo; Google Cloud tute ne scias, ke fd42:90::/64 devus troviĝi malantaŭ unu aparta VM, ĝis vi diros tion al ĝi.

Du apartaj sistemoj devas lerni tiun fakton, kaj nur unu el ili estas OpenVPN. La VPC bezonas vojon antaŭ ol ĝi povos sendi ion returne, kaj la VM devas rajtas plusendi tion, kio alvenas. Eraru en unu el la du duonoj kaj la simptomo aspektas idente.

La adresaro estas interna reto, ne subreto

OpenVPN povas disdoni IPv6-adresojn el intervalo, kiun vi elektas, kaj tiu intervalo estas fikcio, pri kiu konsentas la du tunelaj finpunktoj. Ĝi ne estas subreto de Google Cloud, ĝi ne aperas en la subreta listo de la VPC, kaj la reta interfaco de la VM ne akiras tiujn adresojn. Laborŝarĝo, kiu respondas al kliento, do sendas paketon al adreso, kiun la fabriko konsideras nerutebla.

Tenu la adresaron ekster ĉiu intervalo, kiun la VPC jam uzas. Tenu ĝin ankaŭ ekster la intervaloj malantaŭ viaj aliaj tuneloj. Trapaso transformas puran enkursigan fiaskon en intermitan, kiu montriĝas nur sub ŝarĝo.

Unika loka adresado kiel fd42:90::/64 estas racia elekto por ĉi tiu interna reto. La prefikso ankaŭ memorigas, ke la dezajno estas privateca laŭ konstruo. Nenio pri ULA-adresaro faras ĝin laŭleĝa fonto en la publika interreto.

Donu al la VPC celon kaj sekvan salteton

La respondo bezonas VPC-vojon, kies celo estas la adresaro kaj kies sekva salteto estas la VPN-VM. La aktuala dokumentaro pri statikaj vojoj kovras IPv6-celintervalojn kaj listigas, kiuj tipoj de sekva salteto estas elekteblaj, do kontrolu la subtenatan formon por via topologio anstataŭ kopii pli malnovan IPv4-ekzemplon.

Adreso de sekva salteto devas esti tiu, kiu estas efektive atribuita al la nuba interfaco de la instanco. La interna tunela adreso de la VM ne estas tiu adreso. Uzi ĝin tamen produktas vojon, kiu instaliĝas pure kaj neniam kongruas kun paketo. Legu la interfacan liston antaŭ ol skribi la vojon.

Vojprecedenco gravas same kiel la enskribo mem. Subretaj vojoj estas pli specifaj ol la propraj vojoj, kiujn vi aldonas, do adresaro eltranĉita el ekzistanta subreta intervalo perdos kontraŭ la subreta vojo, sendepende de tio, kiel la propra vojo estas skribita. Elektu apartan adresaron, poste konfirmu, ke la vojo montras la instancon kiel sekvan salteton kaj la ĝustan celan prefikson:

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

Plusendado devas esti ŝaltita dufoje

Vojo liveras la paketon al la instanco. Ĝi ne igas la instancon volonta plusendi ion, kio ne estas adresita al ĝi, kaj tiu permeso ekzistas je du niveloj.

La nuba flanko bezonas ŝaltitan plusendan kapablon de la instanco; tio estas la agordo, kiu lasas VM-on ricevi trafikon por adresoj, kiujn ĝi ne posedas, kaj transdoni ĝin. La gastiga flanko bezonas sian propran IPv6-plusendadon, ĉar la kerno faras apartan decidon post kiam la paketo alvenas. Ambaŭ devas esti ŝaltitaj antaŭ ol unu sola respondo transiros la tunelon.

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

Poste la fajroŝirmilaj reguloj devas allasi la internan fontintervalon en ambaŭ direktoj. Google Cloud taksas la malenkapsuligitan paketon, do regulo, kiu kovras nur la VPC-subreton, forĵetas la trafikon de la adresaro post kiam la tunelo jam sukcesis. Aldonu la adresaron kiel fontintervalon en la enira regulo, kaj kontrolu, ke neniu propra elira politiko blokas la respondon. La implica permesa regulo kovras la defaŭltan kazon, mane skribita elira regulo ne.

Diru al OpenVPN, kiu posedas kion

OpenVPN plusendas al kliento, kiam ĝi scias, ke tiu kliento posedas la celon. Klientaj adresoj el la adresaro estas traktataj de la servila direktivo, kiu difinas la adresaron, sed subreto malantaŭ kliento estas alia aranĝo kaj bezonas eksplicitan posedan enskribon por tiu kliento.

Konfuzi la du kazojn produktas tunelon, en kiu pingoj al la servilo funkcias kaj nenio malantaŭ ĝi. Decidu, kiun kazon vi konstruas, poste skribu la kongruan enskribon anstataŭ aldoni duan push-linion kaj esperi.

Tenu interretan eliron ekster ĉi tiu dezajno

Privata aliro kaj interreta aliro estas apartaj planoj. ULA-adresaro povas atingi VPC-laborŝarĝojn tra la tunelo, kiam enkursigado kaj plusendado konsentas, kaj tiu sama adresaro havas neniun vojon al la publika interreto tra la VPC, ĉar la nuba enirejo ne akceptos arbitran tunelan fonton kiel sian propran.

Se klientoj ankaŭ bezonas interretan eliron, planu subtenatan adresadan kaj enkursigan dezajnon por ĝi, tenu ĝin sendependa de la privata adresaro, kaj testu la du vojojn aparte. Unu funkcianta vojo diras nenion pri la alia, kaj dezajno, kiu konfuzas ilin, fiaskas tiel, ke ĝi aspektas kiel rompita tunelo.