Cloud Run patungong on-premises VPN: pag-set up ng Direct VPC egress

Buhay ang tunnel, naaabot ng VM ang on-premises server, ngunit nag-time out ang serbisyo ng Cloud Run sa parehong host. Ito ang normal na simula para sa gawaing ito, at bihirang ang tunnel ang problema. Ang revision ng Cloud Run ay wala sa iyong VPC bilang default, at kapag nandoon na, gumagamit ito ng sarili nitong source address sa halip na ang subnet ng VM na na-route mo na. Ang runbook sa ibaba ay nagkokonekta ng serbisyo, nagro-route ng aktwal nitong source range, at pagkatapos ay pinapatunayan ang landas mula sa revision na naglingkod sa kahilingan. Patakbuhin ito sa ganoong pagkakasunod-sunod, dahil ang paglaktaw sa unang hakbang ang dahilan kung bakit marami sa mga kasong ito ay nauuwi sa pagbabago ng VPN na walang naayos.

Ikonekta ang revision bago i-debug ang tunnel

Sinusuportahan ng Cloud Run ang Direct VPC egress, na naglalagay sa trapiko ng serbisyo sa isang subnet sa iyong VPC nang walang connector ng Serverless VPC Access. Para sa umiiral na serbisyo, ganito ang hitsura ng update:

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

Palitan ang mga placeholder, suriin kung ano ang ginagawa ng deployment sa live na trapiko, at pumili ng subnet sa rehiyon ng serbisyo na may sapat na kapasidad ng address at tamang pahintulot sa network.

Piliin ang egress mode na tumutugma sa destinasyon

private-ranges-only nagpapadala ng mga destinasyong inuuri nitong pribado sa pamamagitan ng VPC. Hindi ito nangangahulugang «anumang maabot sa pamamagitan ng VPN», at lumilitaw ang puwang na iyon kapag ang on-premises na serbisyo ay nasa range na hindi inuuri ng setting sa ganoong paraan. Kung hindi saklaw ang destinasyon, all-traffic ang iba pang dokumentadong mode, at ipinapadala nito ang lahat sa pamamagitan ng VPC, kabilang ang mga pampublikong dependency ng serbisyo. Pumili nang sinasadya at isulat ang kahihinatnan sa talaan ng pagbabago.

Ang serbisyong gumagamit na ng connector ay nangangailangan ng migration, hindi switch, kaya planuhin ito sa halip na i-configure ang pareho.

I-route ang pinagmulan ng Cloud Run, hindi ang pinagmulan ng VM

Ang Direct VPC egress ay naglalaan ng pansamantalang address mula sa napiling subnet, at ang on-premises na panig ay dapat magbalik ng trapiko sa range na iyon. Ang return route o pahintulot ng firewall na isinulat para sa ibang subnet ng VM ay magmumukhang tama sa diagram at mabibigo sa praktika. Kunin ang CIDR ng subnet mula sa VPC at hindi sa memorya, pagkatapos ay kumpirmahin na kasama ito sa crypto ACL o routing table ng malayong device.

Sa dynamic na routing, i-verify kung ano ang aktwal na inaanunsyo ng Cloud Router at kung ano ang ini-import ng VPC, kabilang ang anumang custom na patakaran sa pag-anunsyo. Ang ruta na umiiral sa console ngunit hindi napili para sa destinasyong ito ay kapareho ng walang ruta.

Tatlong kondisyon na dapat matugunan lahat

Ang gumaganang landas ay nangangailangan ng lahat ng sumusunod, at bawat isa ay nabibigo sa sarili nitong paraan:

• Isang ruta sa VPC patungo sa on-premises prefix sa pamamagitan ng inilaan na koneksyon ng Cloud VPN.
• Isang reverse route sa on-premises para sa subnet ng Cloud Run.
• Saklaw ng proteksyon ng firewall at IPsec na pinapayagan ang pinagmulan, destinasyon at port.

Ang nawawalang ruta ay karaniwang mukhang timeout na walang ebidensya sa malayong panig. Ang problema sa reverse route ay mukhang kahilingang dumarating at sagot na nawawala. Ang problema sa firewall o selector ay maaaring mukhang pagtanggi o tahimik na pag-drop, depende sa device. Ang pag-alam kung alin sa tatlo ang mayroon ka ay lubos na nagpapaliit sa susunod na command.

Huwag maglagay ng iisang pansamantalang address ng Cloud Run sa allowlist. Gamitin ang range ng subnet at isang disenyo ng awtorisasyon na nababagay sa application.

Subukan ang revision na naglingkod sa kahilingan

Suriin ang naka-deploy na mga setting ng network at ang paglalaan ng trapiko bago mag-test, dahil ang isang update ay maaaring gumawa ng bagong revision habang ang mga kahilingan ay umaabot pa rin sa mas luma. Pagkatapos ay gawin ang parehong operasyon na ginagawa ng kahilingan ng user, mula sa revision na iyon. Kung ang destinasyon ay pribadong hostname, tingnan ang resolution nito sa environment na iyon at ang address na ginawa nito, dahil ang sagot ng corporate DNS mula sa iyong laptop ay walang pinapatunayan tungkol sa namespace ng serbisyo. Panatilihin ang TLS hostname verification at ang sariling authentication ng malayong application.

Asahan ang mga dokumentadong pagkaantala ng koneksyon sa pagsisimula ng Direct VPC, at bigyan ang client ng estratehiya sa pagiging handa o muling pagsubok sa halip na i-diagnose ang bawat cold start bilang sirang tunnel.

Rollback at ano ang hindi ginagawa nito

Upang mag-rollback, ibalik ang mga setting ng network at egress ng serbisyo sa dating mga halaga at kumpirmahin na ang naunang revision ay naglilingkod pa rin ng trapiko. Itago ang gcloud command sa talaan ng pagbabago, dahil ang kabaligtaran ng bahagyang pagbabago ay hindi halata pagkalipas ng anim na linggo. Ang pag-alis ng VPC attachment ay nagbabalik sa serbisyo sa dating egress path nito, na maaaring eksaktong kailangan mo sa panahon ng insidente.

Saklaw ng disenyong ito ang mga koneksyong sinisimulan ng Cloud Run at ang mga sagot nito. Hindi nito binibigyan ang on-premises network ng addressable socket sa loob ng serbisyo, dahil ang paglantad papasok ay desisyon sa ingress.