App Engine kan nå din VPN-databas: vad som måste stämma

Påståendet att App Engine Standard inte kan nå en privat databas via Cloud VPN är en rest från en tidigare generation av plattformen. Standard-instanser får inte en VPC-nativ adress som vissa andra körmiljöer, men de kan skicka egress genom en Serverless VPC Access-anslutning som finns i ditt nätverk. När den vägen väl finns ser Cloud VPN och den externa brandväggen anslutningens trafik som vilken annan källa som helst. Det som misslyckas är sällan själva förmågan. Det är en av tre inställningar som aldrig justerades.

Var det gamla svaret kom ifrån

Innan anslutningar fanns var det praktiska svaret verkligen att Standard bara kunde prata med offentliga slutpunkter, och team flyttade till en proxy-VM eller en annan körmiljö för att kringgå det. Plattformen ändrades, folkloren inte. Mycket rådgivning online speglar fortfarande epoken då det inte fanns någon egress-möjlighet alls.

Korrigeringen är smalare än den låter. Standard kan nå det privata nätverket, men bara genom en stödd egress-integration, och bara för de destinationer som integrationen faktiskt fångar.

Välj egress-vägen först

En anslutning som är kopplad till tjänsten är det som för in dess trafik i VPC:n. Dokumentationen för anslutningen listar det regionala förutsättningskravet och egress-inställningarna; anslutningen måste finnas i tjänstens region och kunna användas av identiteten som distribuerar.

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

private-ranges-only skickar privata destinationer in i VPC:n och lämnar allt annat på den normala internetvägen, vilket vanligtvis är vad en databasanslutning behöver. all-traffic pressar utgående trafik brett genom VPC:n, så vanliga internetanrop ärver också VPC:ns NAT- och brandväggsposition.

Att redigera filen lokalt ändrar ingenting förrän du distribuerar. En körande version behåller konfigurationen den skapades med.

Källadressen är anslutningen, inte din laptop

Det är här större delen av felsökningstiden går. Den externa VPN-gatewayen och databasens brandvägg måste tillåta det område som tilldelats anslutningen inne i VPC:n, inte din kontorsadress och inte tjänstens offentliga egress-adress. Slå upp området i konsolen innan du skriver en enda regel.

Ytterligare två ställen måste stämma. VPC:ns routingtabell behöver en rutt till det externa databasnätverket, och den externa sidan behöver en returrutt för anslutningens område. Om tunneln använder trafikväljare, bekräfta att anslutningens område ligger inom det förhandlade omfånget. En rutt som bara finns i riktningen från extern till lokal är ett vanligt förbiseende, och den släpper igenom ping utan att någonsin slutföra ett TCP-handskak.

En tunnel som bara tillåter ett VM-subnät kommer att tappa anslutningens paket utan ett användbart felmeddelande, och det är därför databasens timeout ser ut som ett inloggningsproblem.

DNS reser en annan väg

Ett privat databasvärdnamn måste lösas upp inom nätverket som anslutningen når, via Cloud DNS-peering eller en vidarebefordranszon som VPC:n kan använda. Att lösa upp det på din arbetsstation bevisar ingenting om den distribuerade tjänsten, eftersom din laptop inte använder den resolver.

Om namnet löses upp till en offentlig adress inifrån VPC:n är du på väg att felsöka fel brandvägg.

URL Fetch använder inte anslutningen

Egress-inställningen täcker körmiljöns normala utgående sockets, och den äldre URL Fetch-tjänsten är inte en del av den vägen. En begäran som skickas via urlfetch ignorerar anslutningen oavsett vad konfigurationen säger. När det misslyckade anropet ligger i ett äldre bibliotek som fortfarande använder URL Fetch, är lösningen att flytta anropet till den vanliga HTTP-klienten.

För en databasdrivrutin är detta sällan problemet, men det är det klassiska skälet till att en slutpunkt fungerar och en annan inte från samma tjänst.

Verifiera med en enda snäv fråga

Distribuera och kör sedan en enda tillåten databasoperation från den distribuerade versionen medan du övervakar den externa sidan. Källadressen som loggas av databasen eller VPN-gatewayen bör vara anslutningens. Om den inte är det kom begäran aldrig in i VPC:n och ingen tunnelkonfiguration rättar det. Jämför den med området du slog upp i konsolen; en avvikelse betyder oftast att en andra anslutning betjänar versionen.

En lyckad fråga från en VM inne i VPC:n fastställer att rutten finns. Den fastställer inte att tjänsten valde den.