Førebu ein seriell gjenopprettingsveg før du endrar VPN på GCE

Eit ekstra SSH-vindauge på same grensesnitt er ikkje ein gjenopprettingsveg. Det deler ruta, brannmurregelen og daemonen du er i ferd med å endre, så det sviktar nøyaktig i det augneblinket du treng det. Før du redigerer VPN-ruter på ein Compute Engine-VM, må du prove tre separate ting: at du kan bruke seriekonsollen, at du kan lese utdataa frå han, og at gjesten faktisk gir deg ei innlogging. Kontrollane nedanfor går i den rekkjefølgja, billegast først, slik at ei manglande løyve vert oppdaga før det betyr noko.

Steg 1: stadfest løyvet på skysida

Namngje den nøyaktige VM-en, prosjektet og sona, og kontroller deretter organisasjonen sin godkjende policy for seriell tilgang. Administratoren treng den relevante løyva, og interaktiv seriell tilgang må vere slått på for den instansen under prosjekt- og organisasjonskontrollane som gjeld.

Ikkje svekk ein organisasjonspolicy eller slå på konsolltilgang for eit heilt prosjekt for å førebu éin maskin. Be eigaren ordne den tillatne mekanismen før eksperimentet, ikkje under avbrotet.

Steg 2: prov at du kan lese utdata

Å lese serielle utdata er den billegaste kontrollen, og han øvar transporten utan å røre gjestelogginga:

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

Erstatt identifikatorane og bruk den tillatne porten. Oppstartsmeldingar og konsollprat fortel deg at kanalen verkar. Dei provar ikkje at du kan få eit shell. Derfor er dette steget skilt frå det neste.

Steg 3: prov at du kan få ei interaktiv innlogging

Tilkoplingskommandoen opnar ein ekte sesjon, ikkje ein førehandsvising:

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

Behandle han som ein levande konsoll. Stadfest endepunktet før du skriv inn påloggingsdata, fordi kvart tastetrykk landar på instansen.

Det er her ein plan som såg komplett ut, fell frå kvarandre. Skytilgang er éi grense og Linux-innloggingsprompten er ei anna, og å passere den første seier ingenting om den andre.

Steg 4: førebu påloggingsdata som gjesten godtek

Linux-avbilete frå Google slår ikkje på lokal passordbasert innlogging som standard. Ein seriell sesjon kan derfor nå ein innloggingsprompt og stoppe der, og vente på påloggingsdata som ingen har sett.

Ein godkjend gjenopprettingskonto, eller kva som helst dokumentert gjesteloggingmetode distribusjonen din brukar, må finnast og vere testa. Ein SSH-nøkkel som verkar over nettverket oppfyller ikkje automatisk ein passordprompt i konsollen, så kontroller den faktiske OS Login- og nøkkelordninga i staden for å anta at ho dekkjer dette tilfellet.

Hald gjenopprettingsopplysningar private. Eit root-passord limt inn i eit offentleg startup-script-døme er ei andre hending som ventar på å skje.

Steg 5: registrer eigaren og tilbakerullinga

Før du endrar noko, ta vare på den fungerande nettverkskonfigurasjonen og skriv ned kven som administrerer han, kva VPN-teneste som er involvert og korleis ei tilbakerulling vert utført. Frå ein fungerande sesjon, ta vare på gjeldande ruter, reglar og tenestetilstand.

Det er registreringa som gjer ein gjenopprettingskanal til ein reparasjon, fordi konsollen berre gir deg ein prompt. Skriv ho før endringa, ikkje seinare frå minnet. Ei tilbakerulling kopiert frå ein wiki er ikkje ei tilbakerulling. Det er ei gjetting med eit versjonsnummer.

Steg 6: verifiser etter endringa

Ein eksisterande SSH-sesjon kan overleve ein policy som blokkerer nye, så test med ein fersk normal administrasjonssesjon. Test deretter VPN-åtferda du endra, separat.

Hald gjenopprettingskanalen open til begge kontrollane består, og lukk han deretter i samsvar med tilgangspolicyen. Viss SSH alt er tapt og inga konsollinnlogging er førebudd, slutt å behandle seriell tilgang som eit sikkerheitsnett og start den autoriserte arbeidsflyten for kontogjenoppretting eller instansreparasjon. Å reise ein ekstra VM som jump host reparerer verken vegen til gjesten eller dei manglande påloggingsdataa.