App Engine kan nå VPN-databasen din: hva som må stemme

Påstanden om at App Engine Standard ikke kan nå en privat database over Cloud VPN, er en rest fra en tidligere generasjon av plattformen. Standard-instanser får ikke en VPC-nativ adresse slik noen andre kjøretidsmiljøer gjør, men de kan sende egress gjennom en Serverless VPC Access-kobling som ligger i nettverket ditt. Når den veien først finnes, ser Cloud VPN og den eksterne brannmuren koblingens trafikk som enhver annen kilde. Det som feiler, er sjelden selve evnen. Det er én av tre innstillinger som aldri ble justert.

Hvor det gamle svaret kom fra

Før koblinger fantes, var det praktiske svaret faktisk at Standard bare kunne snakke med offentlige endepunkter, og team flyttet til en proxy-VM eller et annet kjøretidsmiljø for å omgå det. Plattformen endret seg, folkloren ikke. Mye rådgivning på nettet gjenspeiler fortsatt epoken da det ikke fantes noen egress-mulighet i det hele tatt.

Korreksjonen er smalere enn den høres ut. Standard kan nå det private nettverket, men bare gjennom en støttet egress-integrasjon, og bare for destinasjonene den integrasjonen faktisk fanger.

Velg egress-veien først

En kobling som er knyttet til tjenesten, er det som bringer trafikken inn i VPC-en. Dokumentasjonen for koblingen lister opp det regionale forutsetningskravet og egress-innstillingene; koblingen må finnes i tjenestens region og kunne brukes av identiteten som distribuerer.

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

private-ranges-only sender private destinasjoner inn i VPC-en og lar alt annet bli på den normale internettveien, som vanligvis er det en databaseforbindelse trenger. all-traffic presser utgående trafikk bredt gjennom VPC-en, så vanlige internettkall arver også VPC-ens NAT- og brannmurposisjon.

Redigering av filen lokalt endrer ingenting før du distribuerer. En kjørende versjon beholder konfigurasjonen den ble opprettet med.

Kildeadressen er koblingen, ikke laptopen din

Det er her mesteparten av feilsøkingstiden går. Den eksterne VPN-gatewayen og brannmuren til databasen må tillate området som er tildelt koblingen inne i VPC-en, ikke kontoradressen din og ikke tjenestens offentlige egress-adresse. Slå opp området i konsollen før du skriver én eneste regel.

To andre steder må stemme. VPC-rutetabellen trenger en rute til det eksterne databasenettverket, og den eksterne siden trenger en returrute for koblingens område. Hvis tunnelen bruker trafikkvelgere, bekreft at koblingens område ligger innenfor det forhandlede omfanget. En rute som bare finnes i retningen fra ekstern til lokal, er en vanlig feil, og den slipper ping gjennom uten noensinne å fullføre et TCP-håndtrykk.

En tunnel som bare tillater et VM-subnett, vil droppe koblingens pakker uten en nyttig feilmelding, og derfor ser databasens tidsavbrudd ut som et legitimasjonsproblem.

DNS reiser en annen vei

Et privat databasevertsnavn må løses innenfor nettverket koblingen når, gjennom Cloud DNS-peering eller en videresendingssone som VPC-en kan bruke. Å løse det på arbeidsstasjonen din beviser ingenting om den distribuerte tjenesten, fordi laptopen din ikke bruker den oppløseren.

Hvis navnet løses til en offentlig adresse fra innsiden av VPC-en, er du i ferd med å feilsøke feil brannmur.

URL Fetch bruker ikke koblingen

Egress-innstillingen dekker kjøretidsmiljøets normale utgående sockets, og den eldre URL Fetch-tjenesten er ikke en del av den veien. En forespørsel som sendes via urlfetch, ignorerer koblingen uansett hva konfigurasjonen sier. Når det feilende kallet ligger i et eldre bibliotek som fortsatt bruker URL Fetch, er løsningen å flytte kallet til den standard HTTP-klienten.

For en databasedriver er dette sjelden problemet, men det er den klassiske grunnen til at ett endepunkt virker og et annet ikke fra samme tjeneste.

Verifiser med én smal spørring

Distribuer, og kjør deretter én tillatt databaseoperasjon fra den distribuerte versjonen mens du overvåker den eksterne siden. Kildeadressen som logges av databasen eller VPN-gatewayen, bør være koblingens. Hvis ikke, kom forespørselen aldri inn i VPC-en, og ingen tunnelkonfigurasjon retter det. Sammenlign den med området du slo opp i konsollen; et avvik betyr vanligvis at en andre kobling betjener versjonen.

En vellykket spørring fra en VM inne i VPC-en fastslår at ruten finnes. Den fastslår ikke at tjenesten valgte den.