Cloud Run na plaaslike VPN: opstelling van Direct VPC-uitgang

Die tonnel is op, ’n VM bereik die plaaslike bediener, en die Cloud Run-diens keer op dieselfde gasheer uit op ’n time-out. Dit is die normale beginpunt vir hierdie taak, en die tonnel is selde die fout. ’n Cloud Run-weergawe sit nie by verstek in jou VPC nie, en sodra dit wel daar is, gebruik dit sy eie bronadresse eerder as die VM-subnet wat jy reeds gerouteer het. Die runbook hieronder koppel die diens, roetebepaal sy werklike bronreeks en bewys dan die pad vanaf die weergawe wat die versoek bedien het. Voer dit in daardie volgorde uit, want om die eerste stap oor te slaan is hoekom so baie van hierdie gevalle eindig in ’n VPN-verandering wat niks regmaak nie.

Koppel die weergawe voordat jy die tonnel ontfout

Cloud Run ondersteun Direct VPC-uitgang, wat die diens se verkeer op ’n subnet in jou VPC plaas sonder ’n Serverless VPC Access-konnektor. Vir ’n bestaande diens lyk die opdatering so:

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

Vervang die plekhouers, hersien wat die ontplooiing aan lewendige verkeer doen, en kies ’n subnet in die diens se streek met genoeg adreskapasiteit en die regte netwerkmagtigings.

Kies die uitgangmodus wat by die bestemming pas

private-ranges-only stuur die bestemmings wat dit as privaat klassifiseer deur die VPC. Dit beteken nie “enigiets wat oor die VPN bereikbaar is” nie, en daardie gaping verskyn wanneer die plaaslike diens in ’n reeks sit wat die instelling nie so klassifiseer nie. As die bestemming nie gedek is nie, is all-traffic die ander gedokumenteerde modus, en dit stuur alles deur die VPC, insluitend die diens se openbare afhanklikhede. Kies doelbewus en skryf die gevolg in die veranderingsrekord.

’n Diens wat reeds ’n konnektor gebruik, is ’n migrasie eerder as ’n skakelaar, so beplan dit eerder as om albei te konfigureer.

Roetebepaal die Cloud Run-bron, nie ’n VM-bron nie

Direct VPC-uitgang ken kortstondige adresse uit die gekose subnet toe, en die plaaslike kant moet verkeer na daardie reeks terugstuur. ’n Terugroete of firewall-toelating wat vir ’n ander VM-subnet geskryf is, sal in die diagram korrek lyk en in die praktyk misluk. Neem die subnet-CIDR uit die VPC eerder as uit jou geheue, en bevestig dan dat die afgeleë toestel se crypto-ACL of roetebestand dit insluit.

Met dinamiese roetering, verifieer wat Cloud Router werklik adverteer en wat die VPC invoer, insluitend enige pasgemaakte advertensiebeleid. ’n Roete wat in die konsole bestaan maar nie vir hierdie bestemming gekies is nie, is dieselfde as geen roete nie.

Drie voorwaardes wat almal moet geld

’n Werkende pad het al die volgende nodig, en elkeen faal op sy eie manier:

• ’n Roete in die VPC na die plaaslike voorvoegsel deur die beoogde Cloud VPN-verbinding.
• ’n Omgekeerde roete plaaslik vir die Cloud Run-subnet.
• Firewall- en IPsec-beskermingsomvang wat die bron, bestemming en poort toelaat.

’n Ontbrekende roete lyk gewoonlik soos ’n time-out sonder enige bewyse aan die afgeleë kant. ’n Probleem met die omgekeerde roete lyk soos ’n versoek wat aankom en ’n antwoord wat verdwyn. ’n Firewall- of keurderprobleem kan soos ’n weiering of ’n stil wegval lyk, afhangend van die toestel. Om uit te werk watter van die drie jy het, vernou die volgende opdrag aansienlik.

Moenie ’n enkele tydelike Cloud Run-adres op die toelatingslys sit nie. Gebruik die subnetreeks en ’n magtigingsontwerp wat by die toepassing pas.

Toets die weergawe wat die versoek bedien het

Inspekteer die ontplooide netwerkinstellings en die verkeerstoewysing voordat jy toets, want ’n opdatering kan ’n nuwe weergawe skep terwyl versoeke steeds ’n ouer een bereik. Voer dan dieselfde bewerking uit wat die gebruiker se versoek uitvoer, vanaf daardie weergawe. As die bestemming ’n privaat gasheernaam is, kontroleer die oplossing daarvan in daardie omgewing en die adres wat dit opgelewer het, want jou skootrekenaar se korporatiewe DNS-antwoord bewys niks oor die diens se naamruimte nie. Hou TLS-gasheernaamverifikasie en die afgeleë toepassing se eie verifikasie in plek.

Verwag die gedokumenteerde Direct VPC-vertragings by verbinding tydens opstart, en gee die kliënt ’n gereedheids- of herprobeerstrategie eerder as om elke koue start as ’n stukkende tonnel te diagnoseer.

Terugrol en wat dit nie doen nie

Om terug te rol, herstel die diens se netwerk- en uitganginstellings na hul vorige waardes en bevestig dat die vroeër weergawe steeds verkeer bedien. Hou die gcloud-opdrag in die veranderingsrekord, want die omgekeerde van ’n gedeeltelike verandering is ses weke later nie vanselfsprekend nie. Om die VPC-koppeling te verwyder, laat die diens terugkeer na sy vorige uitgangspad, wat dalk presies is wat jy tydens ’n voorval wil hê.

Hierdie ontwerp dek verbindings wat Cloud Run begin en hul antwoorde. Dit gee nie die plaaslike netwerk ’n adresseerbare socket binne die diens nie, want inkomende blootstelling is ’n ingress-besluit.