Kāpēc jūsu GCP VM nevar atbildēt uz OpenVPN IPv6 pūlu

Jūsu IPv6 VPN klients sasniedz darba slodzi, darba slodze atbild tunelī, un atbilde nekad nepienāk. Pirmais instinkts ir vainot ugunsmūri vai tuneli, un parasti neviens no tiem nav vainīgs. Adrese, ko piešķir OpenVPN, ir iekšējs tīkls, kas pastāv tikai tuneļa iekšienē; Google Cloud nav ne jausmas, ka fd42:90::/64 ir jāatrodas aiz vienas konkrētas VM, līdz jūs tam to pasakāt.

Šis fakts ir jāiemācās divām atsevišķām sistēmām, un tikai viena no tām ir OpenVPN. VPC ir vajadzīgs maršruts, pirms tas var kaut ko sūtīt atpakaļ, un VM ir jāatļauj pāradresēt to, kas pienāk. Kļūdieties jebkurā pusē, un simptoms izskatīsies identiski.

Pūls ir iekšējs tīkls, nevis apakštīkls

OpenVPN var piešķirt IPv6 adreses no jūsu izvēlēta diapazona, un šis diapazons ir izdomājums, par ko vienojas abi tuneļa gali. Tas nav Google Cloud apakštīkls, tas neparādās VPC apakštīklu sarakstā, un VM tīkla saskarne nesaņem šīs adreses. Tāpēc darba slodze, kas atbild klientam, sūta paketi uz adresi, ko tīkls uzskata par nemaršrutējamu.

Turiet pūlu ārpus katra diapazona, ko VPC jau izmanto. Turiet to arī ārpus diapazoniem aiz jūsu citiem tuneļiem. Pārklāšanās tīru maršrutēšanas kļūdu pārvērš periodiskā, kas parādās tikai noslodzes laikā.

Unikāla lokālā adresācija, piemēram, fd42:90::/64, ir saprātīga izvēle šim iekšējam tīklam. Prefikss arī atgādina, ka dizains pēc būtības ir privāts. Nekas ULA pūlā nepadara to par likumīgu avotu publiskajā internetā.

Dodiet VPC galamērķi un nākamo lēcienu

Atbildei ir vajadzīgs VPC maršruts, kura galamērķis ir pūls un kura nākamais lēciens ir VPN VM. Pašreizējā statisko maršrutu dokumentācija aptver IPv6 galamērķa diapazonus un uzskaita, kuri nākamā lēciena veidi ir piemēroti, tāpēc pārbaudiet atbalstīto formu savai topoloģijai, nevis kopējiet vecāku IPv4 piemēru.

Nākamā lēciena adresei jābūt tai, kas faktiski piešķirta instanču mākoņa saskarnei. VM iekšējā tuneļa adrese nav šī adrese. Tomēr to izmantojot, tiek iegūts maršruts, kas instalējas tīri un nekad nesakrīt ar paketi. Izlasiet saskarņu sarakstu pirms maršruta rakstīšanas.

Maršruta prioritāte ir tikpat svarīga kā pats ieraksts. Apakštīkla maršruti ir konkrētāki par jūsu pievienotajiem pielāgotajiem maršrutiem, tāpēc pūls, kas izgriezts no esoša apakštīkla diapazona, zaudēs apakštīkla maršrutam neatkarīgi no tā, kā pielāgotais maršruts ir uzrakstīts. Izvēlieties atsevišķu pūlu, pēc tam apstipriniet, ka maršruts rāda instanci kā nākamo lēcienu un pareizo galamērķa prefiksu:

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

Pāradresēšana ir jāiespējo divreiz

Maršruts piegādā paketi instancei. Tas nepadara instanci gatavu pāradresēt kaut ko, kas tai nav adresēts, un šī atļauja pastāv divos līmeņos.

Mākoņa pusei ir vajadzīga iespējota instances pāradresēšanas spēja; tas ir iestatījums, kas ļauj VM saņemt trafiku adresēm, kas tam nepieder, un to pārsūtīt. Viesa pusei ir vajadzīga sava IPv6 pāradresēšana, jo kodols pēc paketes pienākšanas pieņem atsevišķu lēmumu. Abiem jābūt ieslēgtiem, pirms viena atbilde šķērso tuneli.

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

Pēc tam ugunsmūra noteikumiem ir jāatļauj iekšējais avota diapazons abos virzienos. Google Cloud novērtē atkapsulēto paketi, tāpēc noteikums, kas aptver tikai VPC apakštīklu, izmet pūla trafiku pēc tam, kad tunelis jau ir izdevies. Pievienojiet pūlu kā avota diapazonu ienākošā trafika noteikumam un pārbaudiet, vai neviena pielāgota izejošā trafika politika nebloķē atbildi. Netiešais atļaujas noteikums aptver noklusējuma gadījumu, ar roku rakstīts izejošā trafika noteikums ne.

Pastāstiet OpenVPN, kam kas pieder

OpenVPN pāradresē klientam, kad zina, ka šis klients pārvalda galamērķi. Klientu adreses no pūla apstrādā servera direktīva, kas definē pūlu, bet apakštīkls aiz klienta ir cita kārtība un tam vajadzīgs skaidrs īpašumtiesību ieraksts šim klientam.

Abu sajaukšana rada tuneli, kurā ping uz serveri strādā, bet nekas aiz tā ne. Izlemiet, kuru gadījumu veidojat, pēc tam ierakstiet atbilstošo ierakstu, nevis pievienojiet otru push rindu un ceriet.

Turiet interneta izeju ārpus šī dizaina

Privātā piekļuve un interneta piekļuve ir atsevišķi plāni. ULA pūls var sasniegt VPC darba slodzes caur tuneli, kad maršrutēšana un pāradresēšana sakrīt, un tam pašam pūlam nav ceļa uz publisko internetu caur VPC, jo mākoņa vārteja nepieņems patvaļīgu tuneļa avotu kā savu.

Ja klientiem ir vajadzīga arī interneta izeja, plānojiet tam atbalstītu adresācijas un maršrutēšanas dizainu, turiet to neatkarīgu no privātā pūla un testējiet abus ceļus atsevišķi. Viens strādājošs ceļš neko nepasaka par otru, un dizains, kas tos sajauc, cieš neveiksmi tā, ka izskatās pēc salauzta tuneļa.