Et ekstra SSH-vindue på samme interface er ikke en gendannelsesvej. Det deler ruten, firewallreglen og den daemon, du er ved at ændre, så det svigter præcis i det øjeblik, du har brug for det. Før du redigerer VPN-ruter på en Compute Engine-VM, skal du bevise tre separate ting: at du må bruge serielkonsollen, at du kan læse dens output, og at gæsten faktisk giver dig et login. Kontrollerne nedenfor kører i den rækkefølge, billigst først, så en manglende tilladelse opdages, før den betyder noget.

Trin 1: bekræft tilladelsen på cloud-siden

Navngiv den præcise VM, projekt og zone, og kontroller derefter organisationens godkendte politik for seriel adgang. Administratoren har brug for den relevante tilladelse, og interaktiv seriel adgang skal være aktiveret for den instans under de projekt- og organisationskontroller, der gælder.

Undlad at svække en organisationspolitik eller slå konsoladgang til for hele projektet for at forberede én maskine. Bed ejeren om at arrangere den tilladte mekanisme før eksperimentet, ikke under afbrydelsen.

Trin 2: bevis, at du kan læse output

Det er den billigste kontrol at læse seriel output, og den øver transporten uden at røre gæstens login:

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

Erstat identifikatorerne, og brug den tilladte port. Opstartsbeskeder og konsolsnak fortæller dig, at kanalen virker. De beviser ikke, at du kan få en shell. Derfor er dette trin adskilt fra det næste.

Trin 3: bevis, at du kan få et interaktivt login

Forbindelseskommandoen åbner en rigtig session, ikke en forhåndsvisning:

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

Behandl den som en levende konsol. Bekræft endepunktet, før du taster legitimationsoplysninger, fordi hvert tastetryk lander på instansen.

Det er her, en plan, der så komplet ud, falder fra hinanden. Cloudtilladelse er én grænse, og Linux-loginprompten er en anden, og at passere den første siger intet om den anden.

Trin 4: forbered legitimationsoplysninger, som gæsten accepterer

Linux-billeder fra Google aktiverer ikke lokalt adgangskodebaseret login som standard. En seriel session kan derfor nå en loginprompt og stoppe der og vente på en legitimationsoplysning, som ingen har angivet.

En godkendt gendannelseskonto, eller hvilken som helst dokumenteret gæsteloginmetode din udrulning bruger, skal findes og være testet. En SSH-nøgle, der virker over netværket, opfylder ikke automatisk en adgangskodeprompt i konsollen, så kontroller den faktiske OS Login- og nøgleordning i stedet for at antage, at den dækker dette tilfælde.

Hold gendannelsesoplysninger private. En root-adgangskode, der er indsat i et offentligt startup-script-eksempel, er en anden hændelse, der venter på at ske.

Trin 5: registrer ejeren og rollback

Før du ændrer noget, skal du bevare den fungerende netværkskonfiguration og skrive ned, hvem der administrerer den, hvilken VPN-tjeneste der er involveret, og hvordan en rollback udføres. Fra en fungerende session skal du registrere de aktuelle ruter, regler og tjenestetilstand.

Det er registreringen, der gør en gendannelseskanal til en reparation, fordi konsollen kun giver dig en prompt. Skriv den før ændringen, ikke senere fra hukommelsen. En rollback kopieret fra en wiki er ikke en rollback. Det er et gæt med et versionsnummer.

Trin 6: verificer efter ændringen

En eksisterende SSH-session kan overleve en politik, der blokerer nye, så test med en frisk normal administrationssession. Test derefter den VPN-adfærd, du ændrede, separat.

Hold gendannelseskanalen åben, indtil begge kontroller består, og luk den derefter i henhold til adgangspolitikken. Hvis SSH allerede er tabt, og der ikke er forberedt et konsollogin, skal du holde op med at behandle seriel adgang som et sikkerhedsnet og starte den autoriserede arbejdsgang for kontogendannelse eller instansreparation. At rejse en ekstra VM som jump host reparerer hverken gæstens vej eller de manglende legitimationsoplysninger.

Relaterede artikler