Cloud SQL private IP über VPN: die Route, die niemand exportiert

Viele Teams glauben, Cloud SQL private IP funktioniere nur innerhalb der VPC, und dieser Glaube hält sich, weil der Fehler wie ein Datenbankproblem aussieht. Google dokumentiert den Zugriff aus Netzen, die über Cloud VPN oder Cloud Interconnect verbunden sind. Diese Netze brauchen keine besondere Datenbankfunktion, sondern zwei Routenaustausche, die man leicht halb konfiguriert zurücklässt. Der Tunnel kommt hoch, die Compute-Instanzen antworten, und die Datenbankverbindung läuft in einen Timeout — genau die Kombination, die Leute in die falsche Konsole schickt.

Mythos: private IP heißt privat für die VPC

Private Service Access ist ein VPC-Peering zwischen Ihrem Netz und einem Produzentennetz, das Google gehört. Der zugewiesene Bereich für den Dienst liegt auf der Produzentenseite, und die Instanzadresse liegt darin. Wegen dieses Peerings kann eine Datenbank in Ihrem Projekt auf einer Adresse sitzen, zu der Ihre VPC routet, ohne dass ein explizites Subnetz von Ihnen sie enthält.

Weil es ein Peering ist, hat es auch Peering-Verhalten, einschließlich des Teils, in dem benutzerdefinierte Routen nicht automatisch übertragen werden.

Mythos: ein funktionierender Tunnel trägt die Datenbankroute mit sich

Zwei Bereiche müssen die Reise überstehen. Der erste ist das Client-Präfix: Ihr lokales Netz muss dem Cloud Router mit konkreten Präfixen bekannt sein, denn eine Standardroute kann den Import nicht liefern, den das Produzentennetz für den Rückweg braucht. Der zweite ist der zugewiesene Dienstbereich, den die externe Seite lernen muss, damit ihre Pakete zur Datenbank ein Ziel haben. Das sind verschiedene Routen, die an verschiedenen Grenzen gepflegt werden, und eine zu reparieren lässt die andere kaputt.

Auf Google-Seite heißt das, Export custom routes auf den betreffenden Peering-Verbindungen zu aktivieren und den zugewiesenen Dienstbereich zu den vom Cloud Router angekündigten Routen für den Tunnel hinzuzufügen.

Behalten Sie die Ankündigungen, die bereits da sind. Das Hinzufügen des Dienstbereichs sollte die VPC-Routen nicht entfernen, die dieselbe BGP-Sitzung für anderen Verkehr trägt, und ein komplett ersetzter Ankündigungssatz ist ein zweiter Ausfall, der sich hinter dem ersten versteckt. Prüfen Sie auch die effektiven Routen auf dem externen Gerät, denn das VPN-Gateway oder ein anderes Subnetz zu erreichen beweist nur Transport.

Mythos: der Cloud SQL Auth Proxy löst das Netzproblem

The Auth Proxy bietet unterstützte Authentifizierung und verschlüsselten Transport zwischen Ihrer Anwendung und der Instanz. Er erzeugt keine Route. Ein Proxy auf einem Host ohne Weg ins private Netz scheitert genau wie eine direkte Verbindung, und seine Logs sind weniger hilfreich bei der Frage nach dem Warum. Den Proxy auf einen Host zu verschieben, der Konnektivität hat, ändert, welches Teilstück des Weges funktionieren muss, und das ist eine echte Designentscheidung statt eines Workarounds.

Was er nicht tut, ist einem getrennten Laptop den Zugriff auf eine nur private Instanz zu ermöglichen.

Mythos: Private Service Connect folgt denselben Regeln

Private Service Connect nutzt einen Endpunkt in Ihrem eigenen Subnetz und eine DNS-Regelung, die Sie kontrollieren, sodass die Route dorthin eine gewöhnliche Route zu einer Adresse ist, die Sie besitzen. Peering-Exporteinstellungen gelten für dieses Design nicht, und Peering-Änderungen in eine PSC-Bereitstellung zu kopieren fügt Risiko hinzu, ohne Erreichbarkeit hinzuzufügen.

Beide geben Ihnen eine private Adresse; die Ähnlichkeit endet dort.

Testen Sie den Weg in der richtigen Reihenfolge

Testen Sie vom externen Client zuerst den TCP-Endpunkt der Datenbank. Ein abgeschlossener TCP-Handshake bedeutet, dass Routing, Firewall und Listener vorhanden sind, und der nächste Test ist eine erlaubte authentifizierte Operation. Eine Authentifizierungsablehnung ist an diesem Punkt tatsächlich eine gute Nachricht, weil sie beweist, dass ein Datenbank-Listener geantwortet hat. Ein ICMP-Timeout sagt fast nichts über Datenbankzugriff aus, da viele Wege es verwerfen und TCP trotzdem weiterleiten.

Wenn Ihre Client-Bereiche außerhalb von RFC 1918 liegen, prüfen Sie die zusätzlichen Anforderungen an Routenexport und Netzautorisierung, bevor Sie schließen, dass das Design nicht unterstützt wird.

Halten Sie vier Objekte zur Verbindung fest: das externe Präfix, den zugewiesenen Dienstbereich, die beteiligten Peering-Verbindungen und den Router, der die Ankündigungen macht. Diese vier erklären den gesamten privaten Weg und ersetzen das Ammenmärchen, Cloud SQL brauche entweder immer einen Proxy oder sei überhaupt nicht über ein VPN erreichbar.