Ett extra SSH-fönster på samma gränssnitt är inte en återställningsväg. Det delar rutten, brandväggsregeln och daemonen som du är på väg att ändra, så det misslyckas precis i det ögonblick du behöver det. Innan du redigerar VPN-rutter på en Compute Engine-VM måste du bevisa tre separata saker: att du får använda seriekonsolen, att du kan läsa dess utdata och att gästen verkligen ger dig en inloggning. Kontrollerna nedan går i den ordningen, billigast först, så att en saknad behörighet upptäcks innan den spelar roll.

Steg 1: bekräfta behörigheten på molnsidan

Namnge den exakta VM:en, projektet och zonen och kontrollera sedan organisationens godkända policy för seriell åtkomst. Administratören behöver den relevanta behörigheten, och interaktiv seriell åtkomst måste vara aktiverad för den instansen under de projekt- och organisationskontroller som gäller.

Försvaga inte en organisationspolicy och slå inte på konsolåtkomst för ett helt projekt för att förbereda en maskin. Be ägaren ordna den tillåtna mekanismen före experimentet, inte under avbrottet.

Steg 2: bevisa att du kan läsa utdata

Att läsa seriell utdata är den billigaste kontrollen, och den övar transporten utan att röra gästens inloggning:

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

Byt ut identifierarna och använd den tillåtna porten. Uppstartsmeddelanden och konsolprat visar att kanalen fungerar. De bevisar inte att du kan få ett skal. Därför är det här steget skilt från nästa.

Steg 3: bevisa att du kan få en interaktiv inloggning

Anslutningskommandot öppnar en riktig session, inte en förhandsvisning:

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

Behandla den som en levande konsol. Bekräfta slutpunkten innan du skriver in uppgifter, eftersom varje tangenttryckning landar på instansen.

Det är här en plan som såg komplett ut faller sönder. Molnbehörighet är en gräns och Linux inloggningsprompt är en annan, och att passera den första säger ingenting om den andra.

Steg 4: förbered uppgifter som gästen accepterar

Linux-avbildningar från Google aktiverar inte lokal lösenordsbaserad inloggning som standard. En seriell session kan därför nå en inloggningsprompt och stanna där och vänta på uppgifter som ingen har angett.

Ett godkänt återställningskonto, eller vilken dokumenterad gästinloggningsmetod din distribution än använder, måste finnas och vara testad. En SSH-nyckel som fungerar över nätverket uppfyller inte automatiskt en lösenordsprompt i konsolen, så kontrollera den faktiska OS Login- och nyckelordningen i stället för att anta att den täcker det här fallet.

Håll återställningsuppgifter privata. Ett root-lösenord som klistras in i ett offentligt startup-script-exempel är en andra incident som väntar på att hända.

Steg 5: registrera ägaren och återställningen

Innan du ändrar något, bevara den fungerande nätverkskonfigurationen och skriv ned vem som hanterar den, vilken VPN-tjänst som är inblandad och hur en återställning utförs. Från en fungerande session, fånga de aktuella rutterna, reglerna och tjänstens status.

Det är den registreringen som förvandlar en återställningskanal till en reparation, eftersom konsolen bara ger dig en prompt. Skriv den före ändringen, inte senare ur minnet. En återställning kopierad från en wiki är inte en återställning. Det är en gissning med ett versionsnummer.

Steg 6: verifiera efter ändringen

En befintlig SSH-session kan överleva en policy som blockerar nya, så testa med en färsk normal administrationssession. Testa sedan det ändrade VPN-beteendet separat.

Håll återställningskanalen öppen tills båda kontrollerna passerar, och stäng den sedan enligt åtkomstpolicyn. Om SSH redan är förlorat och ingen konsolinloggning har förberetts, sluta behandla seriell åtkomst som ett skyddsnät och starta det auktoriserade arbetsflödet för kontohantering eller instansreparation. Att resa ytterligare en VM som jump host reparerar varken gästens väg eller de saknade uppgifterna.

Relaterade artiklar