Cloud Run til lokal VPN: opsætning af Direct VPC-udgang

Tunnelen er oppe, en VM når den lokale server, og Cloud Run-tjenesten får timeout på den samme vært. Det er det normale udgangspunkt for denne opgave, og tunnelen er sjældent det, der er galt. En Cloud Run-revision ligger ikke i din VPC som standard, og når den gør, bruger den sine egne kildeadresser i stedet for det VM-undernet, du allerede har rutet. Runbooken nedenfor tilknytter tjenesten, ruter dens faktiske kildeområde og beviser derefter vejen fra den revision, der betjente anmodningen. Kør den i den rækkefølge, fordi det at springe det første trin over er grunden til, at så mange af disse sager ender i en VPN-ændring, der ikke retter noget.

Tilknyt revisionen, før du fejlfinder tunnelen

Cloud Run understøtter Direct VPC-udgang, som sætter tjenestens trafik på et undernet i din VPC uden en Serverless VPC Access-connector. For en eksisterende tjeneste ser opdateringen sådan ud:

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

Erstat pladsholderne, gennemgå hvad udrulningen gør ved live-trafik, og vælg et undernet i tjenestens region med tilstrækkelig adressekapacitet og de rigtige netværkstilladelser.

Vælg den udgangstilstand, der passer til destinationen

private-ranges-only sender de destinationer, den klassificerer som private, gennem VPC'en. Det betyder ikke »alt, hvad der kan nås over VPN'en«, og det gab viser sig, når den lokale tjeneste ligger i et område, som indstillingen ikke klassificerer på den måde. Hvis destinationen ikke er dækket, er all-traffic den anden dokumenterede tilstand, og den sender alt gennem VPC'en, inklusive tjenestens offentlige afhængigheder. Vælg bevidst, og skriv konsekvensen i ændringsloggen.

En tjeneste, der allerede bruger en connector, kræver en migrering og ikke en kontakt, så planlæg den i stedet for at konfigurere begge.

Rut Cloud Run-kilden, ikke en VM-kilde

Direct VPC-udgang tildeler midlertidige adresser fra det valgte undernet, og den lokale side skal returnere trafik til det område. En returrute eller firewall-tilladelse skrevet til et andet VM-undernet vil se korrekt ud på diagrammet og fejle i praksis. Tag undernettets CIDR fra VPC'en i stedet for fra hukommelsen, og bekræft derefter, at den eksterne enheds crypto-ACL eller rutetabel indeholder det.

Med dynamisk routing skal du kontrollere, hvad Cloud Router faktisk annoncerer, og hvad VPC'en importerer, inklusive enhver brugerdefineret annonceringspolitik. En rute, der findes i konsollen, men ikke er valgt til denne destination, er det samme som ingen rute.

Tre betingelser, der alle skal være opfyldt

En fungerende vej kræver alt det følgende, og hver af dem fejler på sin egen måde:

• En rute i VPC'en mod det lokale præfiks gennem den tilsigtede Cloud VPN-forbindelse.
• En returrute lokalt for Cloud Run-undernettet.
• Firewall- og IPsec-beskyttelsesområde, der tillader kilden, destinationen og porten.

En manglende rute ser normalt ud som en timeout uden beviser på den eksterne side. Et problem med returruten ser ud som en anmodning, der ankommer, og et svar, der forsvinder. Et firewall- eller selektorproblem kan se ud som en afvisning eller som et stille drop, afhængigt af enheden. At finde ud af, hvilken af de tre du har, indsnævrer den næste kommando betydeligt.

Sæt ikke en enkelt midlertidig Cloud Run-adresse på tilladelseslisten. Brug undernetsområdet og et autorisationsdesign, der passer til applikationen.

Test den revision, der betjente anmodningen

Undersøg de udrullede netværksindstillinger og trafikfordelingen, før du tester, fordi en opdatering kan oprette en ny revision, mens anmodninger stadig når en ældre. Udfør derefter den samme handling, som brugerens anmodning udfører, fra den revision. Hvis destinationen er et privat værtsnavn, skal du kontrollere dets opløsning i det miljø og den adresse, det gav, fordi din laptops virksomheds-DNS-svar ikke beviser noget om tjenestens navneområde. Behold TLS-værtsnavneverifikation og den eksterne applikations egen godkendelse.

Forvent de dokumenterede Direct VPC-opstartsforsinkelser, og giv klienten en paratheds- eller genforsøgsstrategi i stedet for at diagnosticere hver kold start som en brudt tunnel.

Tilbagerulning og hvad dette ikke gør

For at rulle tilbage skal du gendanne tjenestens netværks- og udgangsindstillinger til deres tidligere værdier og bekræfte, at den tidligere revision stadig betjener trafik. Behold gcloud-kommandoen i ændringsloggen, fordi det omvendte af en delvis ændring ikke er indlysende seks uger senere. Fjernelse af VPC-tilknytningen returnerer tjenesten til dens tidligere udgangsvej, hvilket måske er præcis det, du ønsker under en hændelse.

Dette design dækker forbindelser, som Cloud Run initierer, og deres svar. Det giver ikke det lokale netværk en adresserbar socket inde i tjenesten, fordi eksponering indad er en ingress-beslutning.