Cloud Run al loka VPN: agordo de rekta VPC-eliro

Cloud VPN-tunelo ne metas Cloud Run en la reton. Ligu la servon al la ĝusta subreto, enkursigu ĝian fontan intervalon, kaj poste testu tiun revizion.

La tunelo funkcias, VM atingas la lokan servilon, kaj la Cloud Run-servo tempolimas sur la sama gastiganto. Tio estas la normala komenca punkto por ĉi tiu tasko, kaj la tunelo malofte estas tio, kio misas. Cloud Run-revizio ne sidejas en via VPC defaŭlte, kaj unufoje kiam ĝi faras, ĝi uzas siajn proprajn fontajn adresojn anstataŭ la VM-subreto, kiun vi jam enkursigis. La sekva runlibro ligas la servon, enkursigas ĝian realan fontan intervalon kaj poste pruvas la vojon de la revizio, kiu servis la peton. Plenumu ĝin en tiu ordo, ĉar preterlasi la unuan paŝon estas la kialo, ke tiom multaj el ĉi tiuj kazoj finiĝas per VPN-ŝanĝo, kiu riparas nenion.

Ligu la revizion antaŭ ol sencimigi la tunelon

Cloud Run subtenas rektan VPC-eliron, kiu metas la trafikon de la servo sur subreton en via VPC sen Serverless VPC Access-konektilo. Por ekzistanta servo la ĝisdatigo aspektas tiel:

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

Anstataŭigu la lokokupilojn, reviziu kion la deplojo faras al viva trafiko, kaj elektu subreton en la regiono de la servo kun sufiĉa adreskapacito kaj la ĝustaj retaj permesoj.

Elektu la elirmodon, kiu kongruas kun la celo

private-ranges-only sendas la celojn, kiujn ĝi klasifikas kiel privataj, tra la VPC. Tio ne signifas «io ajn atingebla tra la VPN», kaj tiu breĉo aperas, kiam la loka servo situas en intervalo, kiun la agordo ne klasifikas tiel. Se la celo ne estas kovrita, all-traffic estas la alia dokumentita reĝimo, kaj ĝi sendas ĉion tra la VPC, inkluzive la publikajn dependecojn de la servo. Elektu konscie kaj skribu la sekvon en la ŝanĝregistron.

Servo, kiu jam uzas konektilon, bezonas migradon, ne ŝaltilon, do planu ĝin anstataŭ agordi ambaŭ.

Enkursigu la Cloud Run-fonton, ne VM-fonton

Rekta VPC-eliro asignas provizorajn adresojn el la elektita subreto, kaj la loka flanko devas resendi trafikon al tiu intervalo. Revena itinero aŭ fajroŝirma permeso skribita por alia VM-subreto aspektos ĝusta en la diagramo kaj malsukcesos en praktiko. Prenu la CIDR de la subreto el la VPC anstataŭ el la memoro, poste konfirmu, ke la kripta ACL aŭ itinertabelo de la fora aparato enhavas ĝin.

Kun dinamika enkursigado, kontrolu kion Cloud Router efektive anoncas kaj kion la VPC importas, inkluzive ajnan propran anoncan politikon. Itinero, kiu ekzistas en la konzolo sed ne estas elektita por ĉi tiu celo, samas al neniu itinero.

Tri kondiĉoj, kiuj ĉiuj devas validi

Funkcianta vojo bezonas ĉion el la jeno, kaj ĉiu el ili malsukcesas laŭ sia maniero:

  • Itinero en la VPC al la loka prefikso tra la celata Cloud VPN-konekto.
  • Revena itinero loke por la Cloud Run-subreto.
  • Fajroŝirma kaj IPsec-protekta amplekso permesanta la fonton, celon kaj pordon.

Mankanta itinero kutime aspektas kiel tempolimo sen indicoj sur la fora flanko. Problemo pri revena itinero aspektas kiel peto alvenanta kaj respondo malaperanta. Fajroŝirma aŭ selektila problemo povas aspekti kiel rifuzo aŭ kiel silenta forĵeto, laŭ la aparato. Solvi, kiun el la tri vi havas, konsiderinde mallarĝigas la sekvan komandon.

Ne metu unu provizoran Cloud Run-adreson en la permesliston. Uzu la subretan intervalon kaj rajtigan dezajnon taŭgan por la aplikaĵo.

Testu la revizion, kiu servis la peton

Ekzamenu la deplojitajn retagordojn kaj la trafikan disdonon antaŭ ol testi, ĉar ĝisdatigo povas krei novan revizion dum petoj ankoraŭ atingas pli malnovan. Poste plenumu la saman operacion, kiun plenumas la peto de la uzanto, el tiu revizio. Se la celo estas privata gastigantnomo, kontrolu ĝian rezolucion en tiu medio kaj la adreson, kiun ĝi produktis, ĉar la kompania DNS-respondo de via tekkomputilo pruvas nenion pri la nomspaco de la servo. Konservu la TLS-gastigantnoman kontrolon kaj la propran aŭtentikigon de la fora aplikaĵo.

Atendu la dokumentitajn Direct VPC-komencajn konektaj prokrastojn, kaj donu al la kliento strategion de preteco aŭ reprovo anstataŭ diagnozi ĉiun malvarman starton kiel rompitan tunelon.

Malfaro kaj kion ĉi tio ne faras

Por malfari, restarigu la retajn kaj elirajn agordojn de la servo al iliaj antaŭaj valoroj kaj konfirmu, ke la pli frua revizio ankoraŭ servas trafikon. Konservu la gcloud-komandon en la ŝanĝregistro, ĉar la malo de parta ŝanĝo ne estas evidenta post ses semajnoj. Forigi la VPC-ligon resendos la servon al ĝia antaŭa elirvojo, kio eble estas ĝuste tio, kion vi volas dum okazaĵo.

Ĉi tiu dezajno kovras konektojn, kiujn Cloud Run iniciatas, kaj iliajn respondojn. Ĝi ne donas al la loka reto adreseblan ingon ene de la servo, ĉar envena elmeto estas ingress-decida.

Rilataj artikoloj