IP-Weiterleitung auf einem bestehenden GCE-VPN-Gateway aktivieren

Die VM wurde ohne IP-Weiterleitung erstellt, sie führt die VPN-Software bereits aus, und der Instinkt ist, sie mit gesetztem Flag aus der Vorlage neu aufzubauen. Dieser Neuaufbau ist unnötig. Compute Engine stellt canIpForward als aktualisierbare Eigenschaft bereit, und der dokumentierte Aktualisierungspfad wendet sie mit einem Refresh statt mit einem Neustart an. Was das Flag tatsächlich steuert, ist eng: Ohne es verwirft die Plattform Pakete, die an der Instanz ankommen, aber nicht an die eigene Adresse der Instanz adressiert sind. Ein Gateway, das den Verkehr anderer Maschinen weiterleitet, tut genau das, also muss das Flag an sein. Alles danach ist Gastkonfiguration und Routing, was das Flag nicht berührt.

Was das Flag erlaubt und was nicht

Bei deaktivierter Weiterleitung behandelt die Plattform die Instanz als Endpunkt. Pakete, deren Ziel die eigene Adresse der Instanz ist, werden zugestellt; Pakete, die die Instanz im Namen anderer weitergeben soll, nicht.

Bei aktivierter Weiterleitung darf die Instanz als nächster Hop für eine VPC-Route fungieren, und das ist die Rolle, die eine VPN-Appliance braucht. Das Flag sagt nichts über Firewalls, Gastrouting, Tunnelkonfiguration oder Rückwege aus, und ein true-Wert auf einem defekten Gateway ist immer noch ein defektes Gateway.

Die aktuelle Eigenschaft auslesen

Prüfen Sie die Einstellung, bevor Sie etwas ändern, mit einem rein lesenden describe gegen die vorgesehene Instanz, das Projekt und die Zone:

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

Ein false-Wert ist nur relevant, wenn diese VM als nächster Hop dienen soll. Ist das der Fall, muss der restliche Pfad trotzdem separat geprüft werden, denn die Eigenschaft ist eine Zeile in einer längeren Kette.

Die bestehende Instanz aktualisieren

Googles Verfahren zur Aktualisierung von Instanzeigenschaften exportiert die aktuelle Ressource, ändert die Eigenschaft und übermittelt das Ergebnis. Das ist ein anderer Ablauf als das Flag --can-ip-forward zur Erstellungszeit, und es ist der, der auf einer laufenden VM funktioniert.

Exportieren Sie zuerst die Definition in eine lokale Datei und bewahren Sie eine unveränderte Kopie zum Vergleich auf:

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

Setzen Sie in dieser exportierten Datei die Eigenschaft und ändern Sie nichts anderes:

canIpForward: true

Behalten Sie die gesamte Ressource samt ihrem Fingerabdruck. Die Datei durch ein einzeiliges YAML-Dokument zu ersetzen oder unzusammenhängende Änderungen an Maschinentyp, Datenträger oder Schnittstelle in dieselbe Übermittlung zu packen, ist der Weg, auf dem eine Eigenschaftsänderung zum Ausfall wird.

Bitten Sie den Aktualisierungsmechanismus, die Datei zu validieren und zu melden, was sie erfordern würde, bevor eine wirksame Änderung zulässig ist:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

Dieser Validierungslauf aktiviert die Weiterleitung nicht. Lesen Sie die Antwort auf ungültige Eigenschaften und auf die Aktion, die laut Antwort nötig ist. Für diese isolierte Änderung ist die dokumentierte Aktion REFRESH. Verlangt das Ergebnis einen Neustart, enthält die Datei mehr als die Eigenschaft, die Sie ändern wollten, also prüfen Sie sie, statt den Neustart zu gewähren.

Wenden Sie die geprüfte Datei mit der Refresh-Grenze an:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

Prüfen Sie, ob der Vorgang abgeschlossen ist, und führen Sie den describe-Befehl erneut aus. Stimmt der Fingerabdruck nicht mehr, hat jemand anderes die Instanz während Ihrer Bearbeitung geändert, also exportieren Sie eine frische Kopie und prüfen Sie die Änderung erneut, statt Ihre veraltete Datei durchzudrücken.

Der Gast muss das Paket weiterhin routen

Eine Cloud-Berechtigung macht die Appliance nicht zum Router. Bestätigen Sie, dass eine VPC-Route diese VM als nächsten Hop für das Zielpräfix auswählt und dass der Gast mit aktivierter eigener Weiterleitungsrichtlinie zwischen dem Tunnel und der richtigen Schnittstelle routet.

Die Firewall-Richtlinie muss sowohl den inneren Fluss als auch den äußeren Listener zulassen. Nur den VPN-Port zu öffnen beschreibt den verschlüsselten Transport und sagt nichts über den Anwendungsaustausch darin aus.

Schließlich braucht das Ziel einen Rückweg zum Client-Pool, oder das Design muss Quellen bewusst übersetzen. Sieht das Ziel übersetzten Verkehr, prüfen Sie die übersetzte Quelle; bewahrt das Design den Pool, prüfen Sie diesen Pool in der Rückroute und den Zugriffsregeln. NAT hinzuzufügen, bevor Sie entscheiden, welches Design Sie wollen, verdeckt eine fehlende Route und ändert die Richtlinie, die das Ziel sieht.

Auf einem Linux-Gateway gehört die Kernel-Weiterleitung zur Gastkonfiguration. Eine pfSense-Appliance hat ihr eigenes Äquivalent, und einen Linux-sysctl-Befehl hineinzukopieren ist nicht der passende Schritt.

Vom Client aus prüfen, der Zugriff braucht

Testen Sie von einem VPN-Client zu einem Zieldienst, nicht vom Gateway selbst. Eine auf dem Gateway aufgebaute Verbindung nutzt eine andere Quelle und übt die gerade aktivierten Weiterleitungsregeln nie aus.

Halten Sie die Eigenschaft in dem fest, was die Appliance verwaltet. Eine manuell korrigierte VM funktioniert bis zu ihrem nächsten Ersatz, der die ursprüngliche Einstellung still wieder einführt, und dieser Fehler wird wie eine Regression in der VPN-Software aussehen.

Reihenfolge der Arbeit: Eigenschaft lesen, exportieren und eine Zeile bearbeiten, mit NO_EFFECT validieren, mit REFRESH anwenden, bestätigen, dass der Gast weiterleitet, dann von einem Client testen.