Pripremite serijski put oporavka prije promjene VPN-a na GCE

Drugi SSH prozor na istom sučelju nije put oporavka. Dijeli rutu, pravilo vatrozida i demona koji ćete promijeniti, pa zataji točno u trenutku kada vam treba. Prije uređivanja VPN ruta na VM-u u Compute Engineu dokažite tri odvojene stvari: da smijete koristiti serijsku konzolu, da možete čitati njezin izlaz i da će vam gost doista dati prijavu. Provjere u nastavku idu tim redom, najjeftinija prva, kako bi se dopuštenje koje nedostaje otkrilo prije nego što postane važno.

Korak 1: potvrdite dopuštenje na strani oblaka

Navedite točan VM, projekt i zonu, zatim provjerite politiku serijskog pristupa koju je organizacija odobrila. Administrator treba odgovarajuće dopuštenje, a interaktivni serijski pristup mora biti omogućen za tu instancu pod važećim kontrolama projekta i organizacije.

Ne slabite organizacijsku politiku i ne uključujte pristup konzoli za cijeli projekt da biste pripremili jedan stroj. Zamolite vlasnika da dopušteni mehanizam dogovori prije pokusa, a ne tijekom ispada.

Korak 2: dokažite da možete čitati izlaz

Čitanje serijskog izlaza najjeftinija je provjera i uvježbava prijenos bez diranja prijave gosta:

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

Zamijenite identifikatore i koristite dopušteni port. Poruke pokretanja i brbljanje konzole govore da kanal radi. One ne dokazuju da možete dobiti shell. Zato je ovaj korak odvojen od sljedećeg.

Korak 3: dokažite da možete dobiti interaktivnu prijavu

Naredba za povezivanje otvara pravu sesiju, a ne pregled:

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

Tretirajte je kao živu konzolu. Potvrdite krajnju točku prije upisivanja vjerodajnica jer svaki pritisak tipke pada na instancu.

Tu se plan koji je izgledao potpun raspada. Dopuštenje u oblaku jedna je granica, a Linuxov upit za prijavu druga, i prolazak prve ne govori ništa o drugoj.

Korak 4: pripremite vjerodajnice koje će gost prihvatiti

Linux slike koje daje Google prema zadanim postavkama ne omogućuju lokalnu prijavu lozinkom. Serijska sesija stoga može doći do upita za prijavu i ondje stati, čekajući vjerodajnicu koju nitko nije postavio.

Odobreni račun za oporavak ili bilo koja dokumentirana metoda prijave gosta koju vaša implementacija koristi mora postojati i biti isprobana. SSH ključ koji radi preko mreže ne zadovoljava automatski upit za lozinku konzole, pa provjerite stvarni raspored OS Logina i ključeva umjesto da pretpostavite da pokriva taj slučaj.

Čuvajte vjerodajnice za oporavak privatnima. root lozinka zalijepljena u javni primjer startup-scripta drugi je incident koji čeka da se dogodi.

Korak 5: zabilježite vlasnika i vraćanje

Prije bilo kakve promjene sačuvajte radnu mrežnu konfiguraciju i zapišite tko njome upravlja, koja je VPN usluga uključena i kako se izvodi vraćanje. Iz radne sesije zabilježite trenutne rute, pravila i stanje usluge.

Taj zapis pretvara kanal oporavka u popravak jer vam konzola daje samo upit. Napišite ga prije promjene, a ne poslije po sjećanju. Vraćanje kopirano s wikija nije vraćanje. To je nagađanje s brojem verzije.

Korak 6: provjerite nakon promjene

Postojeća SSH sesija može preživjeti politiku koja blokira nove, pa testirajte svježom uobičajenom administratorskom sesijom. Zatim odvojeno testirajte ponašanje VPN-a koje ste promijenili.

Držite kanal oporavka otvorenim dok obje provjere ne prođu, a zatim ga zatvorite u skladu s politikom pristupa. Ako je SSH već izgubljen i prijava preko konzole nije pripremljena, prestanite serijski pristup smatrati sigurnosnom mrežom i pokrenite ovlašteni tijek oporavka računa ili popravka instance. Postavljanje još jednog VM-a kao jump hosta ne popravlja ni put gosta ni vjerodajnice koje nedostaju.