Cloud Run til lokal VPN: sette opp Direct VPC-utgang

Tunnelen er oppe, en VM når den lokale serveren, og Cloud Run-tjenesten får tidsavbrudd på samme vert. Det er det normale utgangspunktet for denne oppgaven, og tunnelen er sjelden det som er galt. En Cloud Run-revisjon ligger ikke i VPC-en din som standard, og når den gjør det, bruker den egne kildeadresser i stedet for VM-subnettet du allerede har rutet. Runbooken nedenfor kobler til tjenesten, ruter det faktiske kildespekteret og beviser deretter veien fra revisjonen som betjente forespørselen. Kjør den i den rekkefølgen, fordi det å hoppe over det første trinnet er grunnen til at så mange av disse sakene ender i en VPN-endring som ikke retter noe.

Koble til revisjonen før du feilsøker tunnelen

Cloud Run støtter Direct VPC-utgang, som setter tjenestens trafikk på et subnett i VPC-en din uten en Serverless VPC Access-kobling. For en eksisterende tjeneste ser oppdateringen slik ut:

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

Erstatt plassholderne, gjennomgå hva utrullingen gjør med livetrafikk, og velg et subnett i tjenestens region med nok adressekapasitet og de riktige nettverkstillatelsene.

Velg utgangsmodusen som passer til destinasjonen

private-ranges-only sender destinasjonene den klassifiserer som private gjennom VPC-en. Det betyr ikke «alt som kan nås over VPN-en», og det gapet vises når den lokale tjenesten ligger i et område som innstillingen ikke klassifiserer slik. Hvis destinasjonen ikke er dekket, er all-traffic den andre dokumenterte modusen, og den sender alt gjennom VPC-en, inkludert tjenestens offentlige avhengigheter. Velg bevisst og skriv konsekvensen i endringsloggen.

En tjeneste som allerede bruker en kobling trenger en migrering, ikke en bryter, så planlegg den i stedet for å konfigurere begge.

Rut Cloud Run-kilden, ikke en VM-kilde

Direct VPC-utgang tildeler midlertidige adresser fra det valgte subnettet, og den lokale siden må returnere trafikk til det området. En returrute eller brannmur-tillatelse skrevet for et annet VM-subnett vil se riktig ut på diagrammet og feile i praksis. Ta subnettets CIDR fra VPC-en og ikke fra hukommelsen, og bekreft deretter at den eksterne enhetens crypto-ACL eller rutetabell inkluderer det.

Med dynamisk ruting, verifiser hva Cloud Router faktisk annonserer og hva VPC-en importerer, inkludert enhver egendefinert annonseringspolicy. En rute som finnes i konsollen, men som ikke er valgt for denne destinasjonen, er det samme som ingen rute.

Tre betingelser som alle må være oppfylt

En fungerende vei trenger alt av følgende, og hver av dem feiler på sin egen måte:

• En rute i VPC-en mot det lokale prefikset gjennom den tiltenkte Cloud VPN-tilkoblingen.
• En returrute lokalt for Cloud Run-subnettet.
• Brannmur- og IPsec-beskyttelsesområde som tillater kilden, destinasjonen og porten.

En manglende rute ser vanligvis ut som en tidsavbrudd uten bevis på den eksterne siden. Et returruteproblem ser ut som en forespørsel som kommer og et svar som forsvinner. Et brannmur- eller selektorproblem kan se ut som en avvisning eller som et stille dropp, avhengig av enheten. Å finne ut hvilken av de tre du har, snevrer inn neste kommando betydelig.

Ikke sett en enkelt midlertidig Cloud Run-adresse på tillatelseslisten. Bruk subnettområdet og et autorisasjonsdesign som passer applikasjonen.

Test revisjonen som betjente forespørselen

Undersøk de utrullede nettverksinnstillingene og trafikkfordelingen før du tester, fordi en oppdatering kan opprette en ny revisjon mens forespørsler fortsatt når en eldre. Utfør deretter den samme operasjonen som brukerens forespørsel utfører, fra den revisjonen. Hvis destinasjonen er et privat vertsnavn, sjekk oppslaget i det miljøet og adressen det ga, fordi bedriftens DNS-svar fra laptopen din ikke beviser noe om tjenestens navnerom. Behold TLS-vertsnavnverifisering og den eksterne applikasjonens egen autentisering.

Forvent de dokumenterte Direct VPC-forsinkelsene ved oppstartstilkobling, og gi klienten en beredskaps- eller gjenforsøksstrategi i stedet for å diagnostisere hver kaldstart som en ødelagt tunnel.

Tilbakerulling og hva dette ikke gjør

For å rulle tilbake, sett tjenestens nettverks- og utgangsinnstillinger tilbake til de forrige verdiene og bekreft at den tidligere revisjonen fortsatt betjener trafikk. Behold gcloud-kommandoen i endringsloggen, fordi det motsatte av en delvis endring ikke er åpenbart seks uker senere. Å fjerne VPC-tilkoblingen returnerer tjenesten til dens forrige utgangsvei, noe som kan være akkurat det du vil under en hendelse.

Dette designet dekker tilkoblinger som Cloud Run starter, og svarene deres. Det gir ikke det lokale nettverket en adresserbar socket inne i tjenesten, fordi eksponering innover er en ingress-beslutning.