App Engine kan nå din VPN-database: hvad der skal passe sammen

Påstanden om, at App Engine Standard ikke kan nå en privat database over Cloud VPN, er en rest fra en tidligere generation af platformen. Standard-instanser får ikke en VPC-native adresse som nogle andre runtime-miljøer, men de kan sende egress gennem en Serverless VPC Access-connector, der bor i dit netværk. Når den vej først findes, ser Cloud VPN og den eksterne firewall connectorens trafik som enhver anden kilde. Det, der fejler, er sjældent selve evnen. Det er en af tre indstillinger, der aldrig blev justeret.

Hvor det gamle svar kom fra

Før connectors fandtes, var det praktiske svar faktisk, at Standard kun kunne tale med offentlige endpoints, og teams skiftede til en proxy-VM eller et andet runtime-miljø for at omgå det. Platformen ændrede sig, men folkloren gjorde ikke. Meget rådgivning online afspejler stadig den æra, hvor der slet ikke var nogen egress-mulighed.

Rettelsen er snævrere, end den lyder. Standard kan nå det private netværk, men kun gennem en understøttet egress-integration og kun for de destinationer, som integrationen faktisk fanger.

Vælg egress-vejen først

En connector, der er knyttet til tjenesten, er det, der bringer dens trafik ind i VPC'en. Connectorens dokumentation oplister det regionale forudsætningskrav og egress-indstillingerne; connectoren skal findes i tjenestens region og kunne bruges af den identitet, der udruller.

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

private-ranges-only sender private destinationer ind i VPC'en og lader alt andet blive på den normale internetvej, hvilket normalt er det, en databaseforbindelse har brug for. all-traffic presser udgående trafik bredt gennem VPC'en, så almindelige internetkald arver også VPC'ens NAT- og firewall-position.

Redigering af filen lokalt ændrer intet, før du udruller. En kørende version beholder den konfiguration, den blev oprettet med.

Kildeadressen er connectoren, ikke din laptop

Det er her, det meste af fejlfindingsarbejdet ligger. Den eksterne VPN-gateway og databasens firewall skal tillade den tildelte range for connectoren inde i VPC'en, ikke din kontoradresse og ikke tjenestens offentlige egress-adresse. Slå den range op i konsollen, før du skriver en enkelt regel.

To andre steder skal stemme overens. VPC-routetabellen skal have en rute til det eksterne databasenetværk, og den eksterne side skal have en returrute for connectorens range. Hvis tunnelen bruger trafikvælgere, skal du bekræfte, at connectorens range ligger inden for det forhandlede omfang. En rute, der kun findes i retningen fra ekstern til lokal, er en hyppig fejl, og den slipper pings igennem uden nogensinde at fuldføre et TCP-handshake.

En tunnel, der kun tillader et VM-subnet, vil droppe connectorens pakker uden en brugbar fejlmeddelelse, og derfor ligner databasens timeout et legitimationsproblem.

DNS rejser en anden vej

Et privat databaseværtsnavn skal opløses inde i det netværk, som connectoren når, gennem Cloud DNS-peering eller en videresendelseszone, som VPC'en kan bruge. At opløse det på din arbejdsstation beviser intet om den udrullede tjeneste, fordi din laptop ikke bruger den resolver.

Hvis navnet opløses til en offentlig adresse inde fra VPC'en, er du ved at fejlfinde den forkerte firewall.

URL Fetch bruger ikke connectoren

Egress-indstillingen dækker runtime-miljøets normale udgående sockets, og den ældre URL Fetch-tjeneste er ikke en del af den vej. En anmodning, der udstedes gennem urlfetch, ignorerer connectoren, uanset hvad konfigurationen siger. Når det fejlende kald ligger i et ældre bibliotek, der stadig bruger URL Fetch, er løsningen at flytte det kald til den standard HTTP-klient.

For en databasedriver er det sjældent problemet, men det er den klassiske grund til, at et endpoint virker og et andet ikke fra samme tjeneste.

Verificer med ét smalt query

Udrul, og kør derefter én tilladt databaseoperation fra den udrullede version, mens du overvåger den eksterne side. Den kildeadresse, som databasen eller VPN-gatewayen logger, bør være connectorens. Hvis ikke, kom anmodningen aldrig ind i VPC'en, og ingen mængde tunnelkonfiguration retter det. Sammenlign den med den range, du slog op i konsollen; en afvigelse betyder normalt, at en anden connector betjener versionen.

En vellykket query fra en VM inde i VPC'en fastslår, at ruten findes. Den fastslår ikke, at tjenesten valgte den.