Cloud Run drejt VPN lokale: konfigurimi i daljes direkte VPC

Tuneli është aktiv, një VM arrin serverin lokal dhe shërbimi Cloud Run skadon në të njëjtin host. Kjo është pika normale e nisjes për këtë detyrë, dhe tuneli rrallë është ajo që nuk shkon. Një revizion Cloud Run nuk qëndron në VPC-në tuaj si parazgjedhje, dhe kur qëndron, përdor adresat e veta burimore në vend të nënrrjetës VM që keni drejtuar tashmë. Runbook-u më poshtë lidh shërbimin, drejton intervalin e tij real burimor dhe më pas vërteton rrugën nga revizioni që shërbeu kërkesën. Ekzekutojeni në atë rend, sepse anashkalimi i hapit të parë është arsyeja pse kaq shumë prej këtyre rasteve përfundojnë me një ndryshim VPN që nuk rregullon asgjë.

Lidhni revizionin përpara se të korrigjoni tunelin

Cloud Run mbështet daljen direkte VPC, e cila vendos trafikun e shërbimit në një nënrrjetë në VPC-në tuaj pa një lidhës Serverless VPC Access. Për një shërbim ekzistues përditësimi duket kështu:

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

Zëvendësoni mbajtësit e vendit, shqyrtoni çfarë bën vendosja me trafikun e drejtpërdrejtë dhe zgjidhni një nënrrjetë në rajonin e shërbimit me kapacitet të mjaftueshëm adresash dhe lejet e duhura të rrjetit.

Zgjidhni mënyrën e daljes që përputhet me destinacionin

private-ranges-only dërgon destinacionet që i klasifikon si private përmes VPC-së. Kjo nuk do të thotë «çdo gjë e arritshme përmes VPN-së», dhe ai boshllëk shfaqet kur shërbimi lokal ndodhet në një interval që cilësimi nuk e klasifikon kështu. Nëse destinacioni nuk është i mbuluar, atëherë all-traffic është mënyra tjetër e dokumentuar, dhe dërgon gjithçka përmes VPC-së, përfshirë varësitë publike të shërbimit. Zgjidhni me vetëdije dhe shkruani pasojën në regjistrin e ndryshimeve.

Një shërbim që tashmë përdor një lidhës kërkon migrim, jo një çelës, prandaj planifikojeni në vend që të konfiguroni të dyja.

Drejtoni burimin Cloud Run, jo burimin e VM-së

Dalja direkte VPC ndan adresa të përkohshme nga nënrrjeta e zgjedhur, dhe ana lokale duhet t'i kthejë trafikun në atë interval. Një rrugë kthimi ose një leje firewalls e shkruar për një nënrrjetë tjetër VM do të duket e saktë në diagram dhe do të dështojë në praktikë. Merrni CIDR-in e nënrrjetës nga VPC-ja dhe jo nga kujtesa, më pas konfirmoni që ACL-ja kriptografike ose tabela e rrugëzimit e pajisjes së largët e përfshin atë.

Me rrugëzim dinamik, verifikoni çfarë reklamon në të vërtetë Cloud Router dhe çfarë importon VPC-ja, përfshirë çdo politikë reklamimi të personalizuar. Një rrugë që ekziston në konsolë por nuk është zgjedhur për këtë destinacion është e njëjtë me mungesën e rrugës.

Tre kushte që duhet të plotësohen të gjitha

Një rrugë funksionale kërkon gjithçka më poshtë, dhe secila dështon në mënyrën e vet:

• Një rrugë në VPC drejt prefiksit lokal përmes lidhjes Cloud VPN të synuar.
• Një rrugë e kundërt në anën lokale për nënrrjetën Cloud Run.
• Një shtrirje mbrojtjeje firewalls dhe IPsec që lejon burimin, destinacionin dhe portën.

Një rrugë që mungon zakonisht duket si skadim kohe pa asnjë provë në anën e largët. Një problem me rrugën e kundërt duket si një kërkesë që mbërrin dhe një përgjigje që zhduket. Një problem firewalls ose përzgjedhësi mund të duket si refuzim ose si hedhje e qetë, në varësi të pajisjes. Të kuptuarit se cila nga të treja është rasti juaj e ngushton ndjeshëm komandën tjetër.

Mos vendosni një adresë të vetme të përkohshme Cloud Run në listën e lejuar. Përdorni intervalin e nënrrjetës dhe një dizajn autorizimi që i përshtatet aplikacionit.

Testoni revizionin që shërbeu kërkesën

Inspektoni cilësimet e rrjetit të vendosura dhe shpërndarjen e trafikut përpara testimit, sepse një përditësim mund të krijojë një revizion të ri, ndërsa kërkesat ende arrijnë në një më të vjetër. Më pas kryeni të njëjtin veprim që kryen kërkesa e përdoruesit, nga ai revizion. Nëse destinacioni është një emër hosti privat, kontrolloni zgjidhjen e tij në atë mjedis dhe adresën që prodhoi, sepse përgjigja e DNS-së korporative nga laptopi juaj nuk provon asgjë për hapësirën e emrave të shërbimit. Mbani verifikimin e emrit të hostit TLS dhe vërtetimin e vetë aplikacionit të largët.

Prisni vonesat e dokumentuara të lidhjes në nisje të Direct VPC, dhe jepini klientit një strategji gatishmërie ose ripërpjekjeje në vend që të diagnostikoni çdo nisje të ftohtë si tunel të prishur.

Kthimi prapa dhe çfarë nuk bën kjo

Për t'u kthyer prapa, riktheni cilësimet e rrjetit dhe të daljes së shërbimit në vlerat e tyre të mëparshme dhe konfirmoni që revizioni i mëparshëm shërben ende trafik. Ruani komandën gcloud në regjistrin e ndryshimeve, sepse e kundërta e një ndryshimi të pjesshëm nuk është e dukshme gjashtë javë më vonë. Heqja e lidhjes me VPC-në e kthen shërbimin në rrugën e tij të mëparshme të daljes, e cila mund të jetë pikërisht ajo që dëshironi gjatë një incidenti.

Ky dizajn mbulon lidhjet që Cloud Run nis dhe përgjigjet e tyre. Ai nuk i jep rrjetit lokal një socket të adresueshëm brenda shërbimit, sepse ekspozimi nga brenda është një vendim ingress.