Cloud VPN zu einer GCP-VM: die interne IP verwenden, nicht die NAT-IP

Sobald ein lokales Netzwerk über Cloud VPN eine VPC erreicht, ist das Ziel für einen Compute Engine-Dienst normalerweise die interne Adresse der VM. Die externe IPv4-Adresse ist keine zweite Adresse, die Sie in dieselbe private Route einsetzen können. Die meiste Verwirrung entsteht hier dadurch, dass drei Adressen mit drei Aufgaben als austauschbar behandelt werden; benennen Sie daher zuerst, welche ein bestimmtes Paket verwendet.

Drei Adressen, drei Aufgaben

Benennen Sie alle drei, bevor Sie eine davon debuggen, denn die Antwort entscheidet, welches Objekt Sie als Nächstes prüfen.

Die erste gehört zum Tunnel. Die zweite gehört zu Ihrem Routing- und Firewall-Design. Die dritte gehört zum eingehenden Internetzugriff und wird abgebildet, nicht angehängt. Ein Design, das für eine davon funktioniert, sagt nichts über die anderen beiden aus.

Warum die externe Adresse keine zweite Schnittstelle ist

Der Adressierungsleitfaden ist die maßgebliche Quelle dafür, wie sich interne und externe Erreichbarkeit in Compute Engine unterscheiden. Eine externe IPv4-Adresse in Compute Engine ist eine Eins-zu-eins-Abbildung auf die einzige interne NIC der Instanz, sodass der Gast nie eine zweite Schnittstelle oder eine zweite Adresse auf dieser NIC sieht. Was die VM intern meldet, ist weiterhin eine primäre interne Adresse.

Deshalb sind ein privater Client, der den Verkehr über den Tunnel nach 10.24.1.7 leitet, und ein Client, der die externe Adresse der VM anspricht, auf verschiedenen Pfaden. Eine Firewallregel für die öffentliche Adresse zu öffnen, ändert nichts an der VPC-Route, die den Tunnelverkehr tragen muss, und das Bearbeiten einer Gastroute verschiebt nicht die Abbildung der Plattform. Wählen Sie die Adresse, die Ihre Route benennt, und prüfen Sie dann nur die Objekte, die sie steuern. Diese Disziplin nimmt den meisten Ratespielraum aus diesem Fehlersuche-Pfad.

Den Pfad mit gcloud abgehen

Beginnen Sie bei der Instanz und lesen Sie beide Adressen aus demselben Objekt, damit Sie wissen, von welcher Ihre Dokumentation spricht:

gcloud compute instances describe app-1 --zone=europe-west1-b \
  --format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"

Bestätigen Sie dann das Routing und die Berechtigung, von denen der Pfad tatsächlich abhängt:

gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1

Lesen Sie die angekündigten und gelernten Bereiche des Tunnels, die VPC-Route für das Workload-Subnetz und die Firewallregel, die die lokale Quelle zulässt. Diese drei müssen übereinstimmen, bevor ein Listener auf dem Gast überhaupt relevant ist.

Prüfen Sie dann den Gast: Lauscht der Dienst auf der internen Adresse, und führt sein Rückweg wieder durch die VPC? Ein Listener, der nur an eine öffentliche Adresse gebunden ist, wird diesen Test nicht bestehen, selbst wenn jedes Objekt auf der Cloud-Seite korrekt ist.

Ein öffentliches Präfix ist eine andere Frage

Nichts davon bedeutet, dass jede innerhalb eines VPN transportierte Adresse RFC1918 sein muss. Ein entferntes Netzwerk darf aus dem öffentlichen Raum nummeriert werden, sofern die Plattform das Routing unterstützt und der Betreiber die Adresshoheit hat. Das ist eine normale Designentscheidung.

Das ist nicht dasselbe, als würde man eine gewöhnliche externe NAT-Adresse wie eine weitere interne Subnetzadresse behandeln. Das eine ist ein Präfix, das Sie routen; das andere ist eine Abbildung, die die Plattform auf eingehenden Zugriff anwendet.

Externe IPv6-Adressen und speziell gestaltete Adressierungsanordnungen haben ihre eigene Semantik. Wenn Ihr Plan von einer davon abhängt, lesen Sie die Plattformdokumentation zu dieser Funktion, statt vom IPv4-Fall zu verallgemeinern. Die IPv4-Abbildung ist der Normalfall, nicht der einzige, und die Ausnahmen haben jeweils eigene Regeln.

Überlappende Bereiche sind ein anderes Problem

Überlappende private Bereiche sind ein echter Grund, warum Menschen zur öffentlichen Adresse greifen, und es ist der falsche Hebel. Das Ziel auf die NAT-Adresse der VM zu ändern, löst die Überlappung nicht; es ändert, für welche Adresse das Paket zu sein behauptet, ohne zu definieren, wie der Rückweg funktioniert.

Lösen Sie die Überlappung bewusst: nummerieren Sie neu, verwenden Sie ein unterstütztes Übersetzungsdesign oder routen Sie über ein Netzwerk, in dem die Präfixe nicht kollidieren. Jede dieser Varianten ist ein Design mit einem Verantwortlichen. Die NAT-Adresse ist kein Design.

Dokumentieren Sie die beiden Felder getrennt

Halten Sie den Tunnel-Peer und das Workload-Ziel als zwei getrennte Runbook-Felder fest, jeweils mit der Route und der Firewallregel, die es stützen. Ein IPsec-Tunnel, der hochkommt, sagt nur, dass sich die Peers einig sind; er sagt nichts darüber, unter welcher Adresse der Workload erreichbar ist, und nichts darüber, ob seine private Route vollständig ist.

Verifizieren Sie mit einem echten Client auf der Gegenseite: Namen auflösen, bestätigen, dass er die interne Adresse liefert, verbinden und den Rückverkehr prüfen. Die Compute Engine-Dokumentation zu IP-Adressen ist die Referenz für die oben verwendete Unterscheidung zwischen intern und extern.