Bereid een seriële herstelroute voor voordat je een GCE-VPN wijzigt

Een tweede SSH-venster op dezelfde interface is geen herstelroute. Het deelt de route, de firewallregel en de daemon die je op het punt staat te wijzigen, dus het faalt precies op het moment dat je het nodig hebt. Voordat je VPN-routes op een Compute Engine-VM wijzigt, bewijs je drie afzonderlijke dingen: dat je de seriële console mag gebruiken, dat je de uitvoer ervan kunt lezen en dat de gast je echt een login geeft. De controles hieronder lopen in die volgorde, de goedkoopste eerst, zodat een ontbrekende machtiging wordt ontdekt voordat die ertoe doet.

Stap 1: bevestig de machtiging aan de cloudkant

Noem de exacte VM, het project en de zone en controleer vervolgens het door de organisatie goedgekeurde beleid voor seriële toegang. De beheerder heeft de relevante machtiging nodig, en interactieve seriële toegang moet zijn ingeschakeld voor die instantie onder de geldende project- en organisatiecontroles.

Verzwak geen organisatiebeleid en schakel geen consoletoggang voor een heel project in om één machine voor te bereiden. Laat de eigenaar het toegestane mechanisme vóór het experiment regelen, niet tijdens de storing.

Stap 2: bewijs dat je de uitvoer kunt lezen

Seriële uitvoer lezen is de goedkoopste controle, en het oefent het transport zonder de gastlogin aan te raken:

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

Vervang de identificaties en gebruik de toegestane poort. Opstartberichten en consolegepraat vertellen je dat het kanaal werkt. Ze bewijzen niet dat je een shell kunt krijgen. Daarom staat deze stap los van de volgende.

Stap 3: bewijs dat je een interactieve login kunt krijgen

Het verbindingscommando opent een echte sessie, geen voorbeeld:

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

Behandel het als een live console. Bevestig het eindpunt voordat je inloggegevens typt, want elke toetsaanslag landt op de instantie.

Hier valt een plan dat compleet leek uit elkaar. Cloudmachtiging is één grens en de Linux-loginprompt is een andere, en de eerste passeren zegt niets over de tweede.

Stap 4: bereid inloggegevens voor die de gast accepteert

Linux-images van Google schakelen standaard geen lokale aanmelding met wachtwoord in. Een seriële sessie kan dus een loginprompt bereiken en daar stoppen, wachtend op inloggegevens die niemand heeft ingesteld.

Een goedgekeurd herstelaccount, of welke gedocumenteerde gastloginmethode je implementatie ook gebruikt, moet bestaan en getest zijn. Een SSH-sleutel die via het netwerk werkt, voldoet niet automatisch aan een wachtwoordprompt van de console, dus controleer de feitelijke OS Login- en sleutelregeling in plaats van aan te nemen dat die dit geval dekt.

Houd herstelgegevens privé. Een root-wachtwoord dat in een openbaar startup-script-voorbeeld wordt geplakt, is een tweede incident dat staat te wachten om te gebeuren.

Stap 5: leg de eigenaar en de rollback vast

Bewaar voordat je iets wijzigt de werkende netwerkconfiguratie en schrijf op wie die beheert, welke VPN-dienst betrokken is en hoe een rollback wordt uitgevoerd. Leg vanuit een werkende sessie de huidige routes, regels en servicestatus vast.

Juist die vastlegging maakt van een herstelkanaal een reparatie, want de console geeft je alleen een prompt. Schrijf het vóór de wijziging, niet achteraf uit het geheugen. Een rollback die uit een wiki is gekopieerd is geen rollback. Het is een gok met een versienummer.

Stap 6: verifieer na de wijziging

Een bestaande SSH-sessie kan een beleid overleven dat nieuwe blokkeert, dus test met een nieuwe normale beheersessie. Test daarna het gewijzigde VPN-gedrag apart.

Houd het herstelkanaal open tot beide controles slagen, en sluit het daarna volgens het toegangsbeleid. Als SSH al verloren is en er geen consolelogin is voorbereid, stop dan met seriële toegang als vangnet te behandelen en start de geautoriseerde werkstroom voor accountherstel of instantieherstel. Een extra VM als jump host optuigen repareert noch het pad van de gast noch de ontbrekende inloggegevens.