Cloud Run till lokal VPN: ställa in Direct VPC-utgående

En Cloud VPN-tunnel sätter inte Cloud Run på nätverket. Anslut tjänsten till rätt subnät, routa dess källintervall och testa sedan den revisionen.

Tunneln är uppe, en VM når den lokala servern och Cloud Run-tjänsten får tidsgräns på samma värd. Det är den normala utgångspunkten för den här uppgiften, och tunneln är sällan det som är fel. En Cloud Run-revision ligger inte i din VPC som standard, och när den gör det använder den egna källadresser i stället för det VM-subnät du redan har routat. Runbooken nedan ansluter tjänsten, routar dess faktiska källintervall och bevisar sedan vägen från revisionen som betjänade begäran. Kör den i den ordningen, eftersom att hoppa över första steget är anledningen till att så många av dessa ärenden slutar i en VPN-ändring som inte åtgärdar något.

Anslut revisionen innan du felsöker tunneln

Cloud Run stöder Direct VPC-utgående, som placerar tjänstens trafik på ett subnät i din VPC utan en Serverless VPC Access-anslutning. För en befintlig tjänst ser uppdateringen ut så här:

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

Byt ut platshållarna, granska vad distributionen gör med livedtrafiken och välj ett subnät i tjänstens region med tillräcklig adresskapacitet och rätt nätverksbehörigheter.

Välj det utgående läge som passar målet

private-ranges-only skickar de mål som den klassar som privata via VPC:n. Det betyder inte «allt som går att nå via VPN», och den luckan visar sig när den lokala tjänsten ligger i ett intervall som inställningen inte klassar så. Om målet inte täcks är all-traffic det andra dokumenterade läget, och det skickar allt via VPC:n, inklusive tjänstens offentliga beroenden. Välj medvetet och skriv konsekvensen i ändringsloggen.

En tjänst som redan använder en anslutning kräver en migrering, inte en strömbrytare, så planera den i stället för att konfigurera båda.

Routa Cloud Run-källan, inte en VM-källa

Direct VPC-utgående tilldelar tillfälliga adresser från det valda subnätet, och den lokala sidan måste returnera trafik till det intervallet. En returrutt eller brandväggstillåtelse skriven för ett annat VM-subnät ser korrekt ut i diagrammet och misslyckas i praktiken. Ta subnätets CIDR från VPC:n och inte från minnet, och bekräfta sedan att den externa enhetens krypto-ACL eller routingtabell innehåller det.

Med dynamisk routning, verifiera vad Cloud Router faktiskt annonserar och vad VPC:n importerar, inklusive all anpassad annonseringspolicy. En rutt som finns i konsolen men inte är vald för det här målet är detsamma som ingen rutt.

Tre villkor som alla måste gälla

En fungerande väg kräver allt följande, och var och en misslyckas på sitt eget sätt:

  • En rutt i VPC:n mot det lokala prefixet via den avsedda Cloud VPN-anslutningen.
  • En returrutt lokalt för Cloud Run-subnätet.
  • Ett brandväggs- och IPsec-skyddsområde som tillåter källan, målet och porten.

En saknad rutt ser vanligtvis ut som en tidsgräns utan bevis på den externa sidan. Ett returruttsproblem ser ut som en begäran som kommer och ett svar som försvinner. Ett brandväggs- eller väljarproblem kan se ut som en avvisning eller som ett tyst tapp, beroende på enheten. Att avgöra vilken av de tre du har begränsar nästa kommando avsevärt.

Sätt inte en enda tillfällig Cloud Run-adress på tillåtelselistan. Använd subnätets intervall och en auktoriseringsdesign som passar applikationen.

Testa revisionen som betjänade begäran

Inspektera de distribuerade nätverksinställningarna och trafikfördelningen innan du testar, eftersom en uppdatering kan skapa en ny revision medan begäranden fortfarande når en äldre. Utför sedan samma operation som användarens begäran utför, från den revisionen. Om målet är ett privat värdnamn, kontrollera dess uppslagning i den miljön och adressen den gav, eftersom företagets DNS-svar från din laptop inte bevisar något om tjänstens namnrymd. Behåll TLS-värdnamnsverifiering och den externa applikationens egen autentisering.

Räkna med de dokumenterade Direct VPC-fördröjningarna vid startanslutning, och ge klienten en beredskaps- eller återförsöksstrategi i stället för att diagnostisera varje kallstart som en trasig tunnel.

Återställning och vad detta inte gör

För att återställa, sätt tillbaka tjänstens nätverks- och utgående inställningar till sina tidigare värden och bekräfta att den tidigare revisionen fortfarande betjänar trafik. Behåll gcloud-kommandot i ändringsloggen, eftersom motsatsen till en partiell ändring inte är självklar sex veckor senare. Att ta bort VPC-anslutningen för tjänsten tillbaka till dess tidigare utgående väg, vilket kan vara precis vad du vill under en incident.

Den här designen täcker anslutningar som Cloud Run initierar och deras svar. Den ger inte det lokala nätverket en adresserbar socket inuti tjänsten, eftersom exponering inåt är ett ingress-beslut.

Relaterade artiklar