App Engine erreicht Ihre VPN-Datenbank: Was übereinstimmen muss

Die Behauptung, App Engine Standard könne eine private Datenbank nicht über Cloud VPN erreichen, stammt aus einer früheren Generation der Plattform. Standard-Instanzen erhalten keine VPC-native Adresse wie einige andere Laufzeitumgebungen, können aber Egress über einen Serverless VPC Access-Connector senden, der in Ihrem Netzwerk liegt. Sobald dieser Pfad existiert, sehen Cloud VPN und die entfernte Firewall den Connector-Traffic wie jede andere Quelle. Was scheitert, ist selten die Fähigkeit selbst. Es ist eine von drei Einstellungen, die nie abgestimmt wurden.

Woher die alte Antwort kam

Bevor es Connectoren gab, war die praktische Antwort tatsächlich, dass Standard nur mit öffentlichen Endpunkten sprechen konnte, und Teams wechselten zu einer Proxy-VM oder einer anderen Laufzeitumgebung, um das zu umgehen. Die Plattform änderte sich, das Gerücht nicht. Viele Online-Ratschläge spiegeln noch die Ära wider, in der es überhaupt keine Egress-Option gab.

Die Korrektur ist enger, als sie klingt. Standard kann das private Netzwerk erreichen, aber nur über eine unterstützte Egress-Integration und nur für die Ziele, die diese Integration tatsächlich erfasst.

Wählen Sie zuerst den Egress-Pfad

Ein Connector, der am Dienst hängt, bringt dessen Traffic in die VPC. Die Connector-Dokumentation listet die regionale Voraussetzung und die Egress-Einstellungen auf; der Connector muss in der Region des Dienstes existieren und von der bereitstellenden Identität nutzbar sein.

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

private-ranges-only schickt private Ziele in die VPC und lässt alles andere auf dem normalen Internetpfad, was eine Datenbankverbindung normalerweise braucht. all-traffic drückt ausgehenden Traffic breit durch die VPC, sodass gewöhnliche Internetaufrufe auch die NAT- und Firewall-Haltung der VPC erben.

Eine lokale Bearbeitung der Datei ändert nichts, bis Sie bereitstellen. Eine laufende Version behält die Konfiguration, mit der sie erstellt wurde.

Die Quelladresse ist der Connector, nicht Ihr Laptop

Hier geht die meiste Debugging-Zeit hin. Das entfernte VPN-Gateway und die Datenbank-Firewall müssen den zugewiesenen Bereich des Connectors innerhalb der VPC zulassen, nicht Ihre Büroadresse und nicht die öffentliche Egress-Adresse des Dienstes. Suchen Sie diesen Bereich in der Konsole, bevor Sie eine einzige Regel schreiben.

Zwei weitere Stellen müssen übereinstimmen. Die VPC-Routentabelle braucht eine Route zum entfernten Datenbanknetzwerk, und die Gegenseite braucht eine Rückroute für den Connector-Bereich. Wenn der Tunnel Traffic-Selectors verwendet, bestätigen Sie, dass der Connector-Bereich innerhalb des ausgehandelten Bereichs liegt. Eine Route, die nur in Richtung entfernt-zu-lokal existiert, ist ein häufiges Versäumnis, und sie lässt Pings durch, ohne jemals einen TCP-Handshake abzuschließen.

Ein Tunnel, der nur ein VM-Subnetz zulässt, verwirft Connector-Pakete ohne brauchbare Fehlermeldung, weshalb der Datenbank-Timeout wie ein Anmeldedatenproblem aussieht.

DNS nimmt einen anderen Weg

Ein privater Datenbank-Hostname muss innerhalb des Netzwerks aufgelöst werden, das der Connector erreicht, über Cloud DNS-Peering oder eine Weiterleitungszone, die die VPC nutzen kann. Ihn auf Ihrer Workstation aufzulösen beweist nichts über den bereitgestellten Dienst, denn Ihr Laptop verwendet diesen Resolver nicht.

Löst der Name sich aus der VPC heraus zu einer öffentlichen Adresse auf, debuggen Sie gleich die falsche Firewall.

URL Fetch nutzt den Connector nicht

Die Egress-Einstellung deckt die normalen ausgehenden Sockets der Laufzeitumgebung ab, und der alte URL Fetch-Dienst gehört nicht zu diesem Pfad. Eine über urlfetch gestellte Anfrage ignoriert den Connector, egal was die Konfiguration sagt. Wenn der fehlschlagende Aufruf in einer älteren Bibliothek steckt, die noch URL Fetch verwendet, besteht die Lösung darin, diesen Aufruf auf den Standard-HTTP-Client zu verschieben.

Bei einem Datenbanktreiber ist das selten das Problem, aber es ist der klassische Grund, warum ein Endpunkt funktioniert und ein anderer nicht, und zwar aus demselben Dienst.

Prüfen Sie mit einer einzigen engen Abfrage

Stellen Sie bereit und führen Sie dann eine einzelne erlaubte Datenbankoperation aus der bereitgestellten Version aus, während Sie die Gegenseite beobachten. Die von der Datenbank oder dem VPN-Gateway protokollierte Quelladresse sollte die des Connectors sein. Ist sie es nicht, hat die Anfrage die VPC nie betreten, und keine Tunnelkonfiguration behebt das. Vergleichen Sie sie mit dem Bereich, den Sie in der Konsole nachgeschlagen haben; eine Abweichung bedeutet meist, dass ein zweiter Connector die Version bedient.

Eine erfolgreiche Abfrage von einer VM innerhalb der VPC belegt, dass die Route existiert. Sie belegt nicht, dass der Dienst sie gewählt hat.