Bereiten Sie vor einer GCE-VPN-Änderung einen seriellen Rettungsweg vor

Ein zweites SSH-Fenster auf derselben Schnittstelle ist kein Rettungsweg. Es teilt sich die Route, die Firewallregel und den Daemon, den Sie gleich ändern, und fällt daher genau in dem Moment aus, in dem Sie es brauchen. Bevor Sie VPN-Routen auf einer Compute Engine-VM bearbeiten, belegen Sie drei getrennte Dinge: dass Sie die serielle Konsole nutzen dürfen, dass Sie deren Ausgabe lesen können und dass der Gast Ihnen tatsächlich einen Login gibt. Die folgenden Prüfungen laufen in dieser Reihenfolge, die billigste zuerst, damit eine fehlende Berechtigung entdeckt wird, bevor sie zählt.

Schritt 1: Bestätigen Sie die Berechtigung auf der Cloud-Seite

Benennen Sie die genaue VM, das Projekt und die Zone, und prüfen Sie dann die von der Organisation genehmigte Richtlinie für seriellen Zugriff. Der Administrator benötigt die entsprechende Berechtigung, und interaktiver serieller Zugriff muss für diese Instanz unter den geltenden Projekt- und Organisationskontrollen aktiviert sein.

Schwächen Sie keine Organisationsrichtlinie und schalten Sie den Konsolenzugriff nicht für ein ganzes Projekt ein, um eine Maschine vorzubereiten. Lassen Sie den Eigentümer den erlaubten Mechanismus vor dem Experiment vereinbaren, nicht während der Störung.

Schritt 2: Belegen Sie, dass Sie die Ausgabe lesen können

Das Lesen der seriellen Ausgabe ist die billigste Prüfung, und sie übt den Transport, ohne den Login des Gastes anzutasten:

gcloud compute instances get-serial-port-output VM_NAME \
    --project PROJECT_ID --zone ZONE --port 1

Ersetzen Sie die Bezeichner und verwenden Sie den erlaubten Port. Startmeldungen und Konsolengeplauder zeigen, dass der Kanal funktioniert. Sie belegen nicht, dass Sie eine Shell bekommen. Deshalb ist dieser Schritt vom nächsten getrennt.

Schritt 3: Belegen Sie, dass Sie einen interaktiven Login bekommen

Der Verbindungsbefehl öffnet eine echte Sitzung, keine Vorschau:

gcloud compute connect-to-serial-port VM_NAME \
    --project PROJECT_ID --zone ZONE --port 1

Behandeln Sie ihn als Live-Konsole. Bestätigen Sie den Endpunkt, bevor Sie Anmeldedaten eingeben, denn jeder Tastendruck landet auf der Instanz.

Hier zerfällt ein Plan, der vollständig aussah. Cloud-Berechtigung ist eine Grenze und die Linux-Login-Aufforderung eine andere, und die erste zu passieren sagt nichts über die zweite.

Schritt 4: Bereiten Sie Anmeldedaten vor, die der Gast akzeptiert

Von Google bereitgestellte Linux-Images aktivieren standardmäßig keine lokale passwortbasierte Anmeldung. Eine serielle Sitzung kann daher eine Login-Aufforderung erreichen und dort stehen bleiben, während sie auf Anmeldedaten wartet, die niemand gesetzt hat.

Ein genehmigtes Wiederherstellungskonto oder welche dokumentierte Gast-Login-Methode Ihre Bereitstellung auch nutzt, muss existieren und getestet sein. Ein SSH-Schlüssel, der über das Netzwerk funktioniert, erfüllt nicht automatisch eine Konsolen-Passwortaufforderung, prüfen Sie also die tatsächliche OS-Login- und Schlüsselregelung, statt anzunehmen, dass sie diesen Fall abdeckt.

Halten Sie Wiederherstellungs-Anmeldedaten privat. Ein root-Passwort, das in ein öffentliches startup-script-Beispiel eingefügt wird, ist ein zweiter Vorfall, der darauf wartet zu passieren.

Schritt 5: Halten Sie Eigentümer und Rollback fest

Bevor Sie etwas ändern, bewahren Sie die funktionierende Netzwerkkonfiguration auf und notieren Sie, wer sie verwaltet, welcher VPN-Dienst beteiligt ist und wie ein Rollback durchgeführt wird. Erfassen Sie aus einer funktionierenden Sitzung die aktuellen Routen, Regeln und den Dienststatus.

Genau dieser Eintrag macht aus einem Rettungskanal eine Reparatur, denn die Konsole verschafft Ihnen nur eine Eingabeaufforderung. Schreiben Sie ihn vor der Änderung, nicht danach aus dem Gedächtnis. Ein aus einem Wiki kopiertes Rollback ist kein Rollback. Es ist eine Vermutung mit Versionsnummer.

Schritt 6: Prüfen Sie nach der Änderung

Eine bestehende SSH-Sitzung kann eine Richtlinie überleben, die neue blockiert, testen Sie also mit einer frischen normalen Administrationssitzung. Testen Sie dann das geänderte VPN-Verhalten separat.

Halten Sie den Rettungskanal offen, bis beide Prüfungen bestehen, und schließen Sie ihn danach gemäß der Zugriffsrichtlinie. Wenn SSH bereits verloren ist und kein Konsolen-Login vorbereitet wurde, hören Sie auf, seriellen Zugriff als Sicherheitsnetz zu behandeln, und starten Sie den autorisierten Workflow zur Kontowiederherstellung oder Instanzreparatur. Eine weitere VM als Jump Host aufzusetzen repariert weder den Gastpfad noch die fehlenden Anmeldedaten.