Cloud Run uz vietējo VPN: tiešas VPC izejas iestatīšana

Cloud VPN tunelis neieliek Cloud Run tīklā. Pievienojiet pakalpojumu pareizajai apakštīklam, maršrutējiet tā avota diapazonu un pēc tam pārbaudiet šo versiju.

Tunelis darbojas, VM sasniedz vietējo serveri, bet Cloud Run pakalpojums tajā pašā resursdatorā nokavējas. Tas ir parastais šī uzdevuma sākumpunkts, un tunelis reti ir vainīgais. Cloud Run versija pēc noklusējuma neatrodas jūsu VPC, un, kad tā atrodas, tā izmanto savas avota adreses, nevis VM apakštīklu, kuru jūs jau maršrutējāt. Zemāk esošā runbook pievieno pakalpojumu, maršrutē tā faktisko avota diapazonu un pēc tam pierāda ceļu no versijas, kas apkalpoja pieprasījumu. Izpildiet to šādā secībā, jo pirmā soļa izlaišana ir iemesls, kāpēc tik daudzi šādi gadījumi beidzas ar VPN izmaiņām, kas neko nelabo.

Pievienojiet versiju pirms tuneļa atkļūdošanas

Cloud Run atbalsta tiešu VPC izeju, kas novieto pakalpojuma trafiku apakštīklā jūsu VPC bez Serverless VPC Access savienotāja. Esošam pakalpojumam atjauninājums izskatās šādi:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

Aizstājiet vietturus, pārskatiet, ko izvietošana dara ar dzīvo trafiku, un izvēlieties apakštīklu pakalpojuma reģionā ar pietiekamu adrešu ietilpību un pareizām tīkla atļaujām.

Izvēlieties galamērķim atbilstošu izejas režīmu

private-ranges-only sūta galamērķus, ko klasificē kā privātus, caur VPC. Tas nenozīmē «visu, kas sasniedzams caur VPN», un šī plaisa parādās, kad vietējais pakalpojums atrodas diapazonā, ko iestatījums tā neklasificē. Ja galamērķis nav ietverts, all-traffic ir otrs dokumentētais režīms, un tas sūta visu caur VPC, tostarp pakalpojuma publiskās atkarības. Izvēlieties apzināti un ierakstiet sekas izmaiņu reģistrā.

Pakalpojumam, kas jau izmanto savienotāju, nepieciešama migrācija, nevis slēdzis, tāpēc plānojiet to, nevis konfigurējiet abus.

Maršrutējiet Cloud Run avotu, nevis VM avotu

Tiešā VPC izeja piešķir īslaicīgas adreses no izvēlētā apakštīkla, un vietējai pusei trafiks jāatgriež šajā diapazonā. Atgriešanās maršruts vai ugunsmūra atļauja, kas rakstīta citam VM apakštīklam, diagrammā izskatīsies pareizi un praksē neizdosies. Ņemiet apakštīkla CIDR no VPC, nevis no atmiņas, pēc tam pārliecinieties, ka attālās ierīces kripto ACL vai maršrutēšanas tabula to ietver.

Ar dinamisko maršrutēšanu pārbaudiet, ko Cloud Router faktiski reklamē un ko VPC importē, tostarp jebkuru pielāgotu reklamēšanas politiku. Maršruts, kas pastāv konsolē, bet nav atlasīts šim galamērķim, ir tas pats, kas nav maršruta.

Trīs nosacījumi, kuriem visiem jāizpildās

Darbojošam ceļam nepieciešams viss turpmākais, un katrs no tiem neizdodas savā veidā:

  • Maršruts VPC virzienā uz vietējo prefiksu caur paredzēto Cloud VPN savienojumu.
  • Atgriešanās maršruts vietējā pusē Cloud Run apakštīklam.
  • Ugunsmūra un IPsec aizsardzības apjoms, kas atļauj avotu, galamērķi un portu.

Trūkstošs maršruts parasti izskatās kā taimauta beigas bez pierādījumiem attālajā pusē. Atgriešanās maršruta problēma izskatās kā pienākošs pieprasījums un pazūdoša atbilde. Ugunsmūra vai selektora problēma var izskatīties kā atteikums vai klusa nomešana atkarībā no ierīces. Noskaidrošana, kurš no trim ir jūsu gadījumā, ievērojami sašaurina nākamo komandu.

Neievietojiet vienu īslaicīgu Cloud Run adresi atļauto sarakstā. Izmantojiet apakštīkla diapazonu un lietojumprogrammai atbilstošu autorizācijas dizainu.

Pārbaudiet versiju, kas apkalpoja pieprasījumu

Pirms pārbaudes apskatiet izvietotos tīkla iestatījumus un trafika sadalījumu, jo atjauninājums var izveidot jaunu versiju, kamēr pieprasījumi vēl sasniedz vecāku. Pēc tam veiciet to pašu darbību, ko veic lietotāja pieprasījums, no šīs versijas. Ja galamērķis ir privāts resursdatora nosaukums, pārbaudiet tā atrisinājumu šajā vidē un iegūto adresi, jo jūsu klēpjdatora uzņēmuma DNS atbilde neko nepierāda par pakalpojuma vārdu telpu. Saglabājiet TLS resursdatora nosaukuma pārbaudi un attālās lietojumprogrammas autentifikāciju.

Gaidiet dokumentētos Direct VPC palaišanas savienojuma aizturi un dodiet klientam gatavības vai atkārtota mēģinājuma stratēģiju, nevis diagnosticējiet katru auksto startu kā salauztu tuneli.

Atritināšana un ko tas nedara

Lai atritinātu, atjaunojiet pakalpojuma tīkla un izejas iestatījumus to iepriekšējās vērtībās un pārliecinieties, ka iepriekšējā versija joprojām apkalpo trafiku. Saglabājiet gcloud komandu izmaiņu reģistrā, jo daļēju izmaiņu pretējais pēc sešām nedēļām nav acīmredzams. VPC pievienojuma noņemšana atgriež pakalpojumu tā iepriekšējā izejas ceļā, kas incidenta laikā var būt tieši tas, ko vēlaties.

Šis dizains aptver savienojumus, ko Cloud Run uzsāk, un to atbildes. Tas vietējam tīklam nedod adresējamu ligzdu pakalpojuma iekšienē, jo ienākošā atklāšana ir ingress lēmums.

Saistītie raksti