Cloud Run zu lokalem VPN: Direct VPC-Egress einrichten

Ein Cloud VPN-Tunnel bringt Cloud Run nicht ins Netz. Binden Sie den Dienst an das richtige Subnetz, routen Sie seinen Quellbereich und testen Sie dann diese Revision.

Der Tunnel steht, eine VM erreicht den lokalen Server, und der Cloud Run-Dienst läuft auf demselben Host in eine Zeitüberschreitung. Das ist der normale Ausgangspunkt für diese Aufgabe, und der Tunnel ist selten das Problem. Eine Cloud Run-Revision sitzt standardmäßig nicht in Ihrer VPC, und sobald sie es tut, verwendet sie eigene Quelladressen statt des VM-Subnetzes, das Sie bereits geroutet haben. Das folgende Runbook bindet den Dienst an, routet seinen tatsächlichen Quellbereich und weist dann den Pfad von der Revision nach, die die Anforderung bedient hat. Führen Sie es in dieser Reihenfolge aus, denn das Überspringen des ersten Schritts ist der Grund, warum so viele dieser Fälle mit einer VPN-Änderung enden, die nichts behebt.

Binden Sie die Revision an, bevor Sie den Tunnel debuggen

Cloud Run unterstützt Direct VPC-Egress, wodurch der Datenverkehr des Dienstes ohne einen Serverless VPC Access-Connector in einem Subnetz Ihrer VPC landet. Für einen bestehenden Dienst sieht die Aktualisierung so aus:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

Ersetzen Sie die Platzhalter, prüfen Sie, was das Deployment am Live-Verkehr ändert, und wählen Sie ein Subnetz in der Region des Dienstes mit ausreichender Adresskapazität und den richtigen Netzwerkberechtigungen.

Wählen Sie den Egress-Modus, der zum Ziel passt

private-ranges-only leitet die Ziele, die er als privat einstuft, durch die VPC. Das heißt nicht „alles, was über das VPN erreichbar ist“, und diese Lücke zeigt sich, wenn der lokale Dienst in einem Bereich liegt, den die Einstellung nicht so einstuft. Ist das Ziel nicht abgedeckt, ist all-traffic der andere dokumentierte Modus, und er leitet alles durch die VPC, einschließlich der öffentlichen Abhängigkeiten des Dienstes. Wählen Sie bewusst und schreiben Sie die Folge in den Änderungsdatensatz.

Ein Dienst, der bereits einen Connector verwendet, braucht eine Migration statt eines Umschalters, planen Sie sie also, statt beides zu konfigurieren.

Routen Sie die Cloud Run-Quelle, nicht eine VM-Quelle

Direct VPC-Egress vergibt temporäre Adressen aus dem ausgewählten Subnetz, und die lokale Seite muss den Verkehr in diesen Bereich zurückleiten. Eine Rückroute oder Firewall-Freigabe, die für ein anderes VM-Subnetz geschrieben wurde, sieht im Diagramm korrekt aus und scheitert in der Praxis. Nehmen Sie das Subnetz-CIDR aus der VPC und nicht aus dem Gedächtnis, und bestätigen Sie dann, dass die Crypto-ACL oder Routentabelle des entfernten Geräts es enthält.

Prüfen Sie bei dynamischem Routing, was der Cloud Router tatsächlich annonciert und was die VPC importiert, einschließlich einer benutzerdefinierten Annoncierungsrichtlinie. Eine Route, die in der Konsole existiert, aber für dieses Ziel nicht ausgewählt ist, ist dasselbe wie keine Route.

Drei Bedingungen, die alle gelten müssen

Ein funktionierender Pfad braucht alles Folgende, und jede Bedingung scheitert auf ihre eigene Weise:

  • Eine Route in der VPC zum lokalen Präfix über die vorgesehene Cloud VPN-Verbindung.
  • Eine Rückroute lokal für das Cloud Run-Subnetz.
  • Ein Firewall- und IPsec-Schutzbereich, der Quelle, Ziel und Port zulässt.

Eine fehlende Route sieht normalerweise wie eine Zeitüberschreitung ohne Belege auf der Gegenseite aus. Ein Problem mit der Rückroute sieht wie eine ankommende Anforderung und eine verschwindende Antwort aus. Ein Firewall- oder Selektorproblem kann je nach Gerät wie eine Ablehnung oder wie ein stiller Verlust aussehen. Wenn Sie herausfinden, welches der drei Sie haben, grenzt das den nächsten Befehl erheblich ein.

Setzen Sie keine einzelne temporäre Cloud Run-Adresse auf die Positivliste. Verwenden Sie den Subnetzbereich und ein Autorisierungsdesign, das zur Anwendung passt.

Testen Sie die Revision, die die Anforderung bedient hat

Prüfen Sie die bereitgestellten Netzwerkeinstellungen und die Verkehrsverteilung, bevor Sie testen, denn eine Aktualisierung kann eine neue Revision erzeugen, während Anforderungen noch eine ältere erreichen. Führen Sie dann dieselbe Operation, die die Anforderung des Benutzers ausführt, von dieser Revision aus. Wenn das Ziel ein privater Hostname ist, prüfen Sie dessen Auflösung in dieser Umgebung und die daraus entstandene Adresse, denn die Unternehmens-DNS-Antwort Ihres Laptops beweist nichts über den Namensraum des Dienstes. Behalten Sie die TLS-Hostnamenprüfung und die eigene Authentifizierung der entfernten Anwendung bei.

Rechnen Sie mit den dokumentierten Verbindungsverzögerungen beim Start von Direct VPC und geben Sie dem Client eine Bereitschafts- oder Wiederholungsstrategie, statt jeden Kaltstart als defekten Tunnel zu diagnostizieren.

Rollback und was das hier nicht leistet

Um zurückzurollen, setzen Sie die Netzwerk- und Egress-Einstellungen des Dienstes auf ihre vorherigen Werte zurück und bestätigen Sie, dass die frühere Revision noch Verkehr bedient. Behalten Sie den gcloud-Befehl im Änderungsdatensatz, denn die Umkehrung einer teilweisen Änderung ist sechs Wochen später nicht offensichtlich. Das Entfernen der VPC-Bindung bringt den Dienst auf seinen vorherigen Egress-Pfad zurück, was während eines Vorfalls genau das sein kann, was Sie wollen.

Dieses Design deckt Verbindungen ab, die Cloud Run initiiert, und deren Antworten. Es gibt dem lokalen Netzwerk keinen adressierbaren Socket innerhalb des Dienstes, denn die Exposition nach innen ist eine Ingress-Entscheidung.

Ähnliche Artikel