Pripravte si sériovú cestu obnovy pred zmenou VPN v GCE

Druhé okno SSH na rovnakom rozhraní nie je cestou obnovy. Zdieľa trasu, pravidlo firewallu aj démona, ktorého sa chystáte zmeniť, takže zlyhá presne v tej chvíli, keď ho potrebujete. Pred úpravou trás VPN na VM v Compute Engine preukážte tri oddelené veci: že smiete používať sériovú konzolu, že viete čítať jej výstup a že hosť vám naozaj dá prihlásenie. Kontroly nižšie idú v tomto poradí, od najlacnejšej, aby sa chýbajúce oprávnenie odhalilo skôr, než bude dôležité.

Krok 1: potvrďte oprávnenie na strane cloudu

Uveďte presnú VM, projekt a zónu, potom skontrolujte organizáciou schválenú politiku sériového prístupu. Administrátor potrebuje príslušné oprávnenie a interaktívny sériový prístup musí byť pre túto inštanciu povolený v rámci platných kontrol projektu a organizácie.

Nezoslabujte politiku organizácie a nezapínajte prístup ku konzole pre celý projekt, aby ste pripravili jeden stroj. Požiadajte vlastníka, aby povolený mechanizmus zariadil pred experimentom, nie počas výpadku.

Krok 2: preukážte, že viete čítať výstup

Čítanie sériového výstupu je najlacnejšia kontrola a precvičuje prenos bez toho, aby sa dotklo prihlásenia hosťa:

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

Nahraďte identifikátory a použite povolený port. Zavádzacie správy a táranie konzoly hovoria, že kanál funguje. Nedokazujú, že získate shell. Preto je tento krok oddelený od nasledujúceho.

Krok 3: preukážte, že získate interaktívne prihlásenie

Príkaz pripojenia otvára skutočnú reláciu, nie náhľad:

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

Berte ju ako živú konzolu. Pred zadaním prihlasovacích údajov potvrďte koncový bod, pretože každý stlač klávesy dopadne na inštanciu.

Tu sa rozpadá plán, ktorý vyzeral úplne. Cloudové oprávnenie je jedna hranica a prihlasovacia výzva Linuxu je druhá, a prekonanie prvej nič nehovorí o druhej.

Krok 4: pripravte prihlasovacie údaje, ktoré hosť prijme

Linuxové obrazy od Google štandardne nepovoľujú miestne prihlásenie heslom. Séria preto môže dôjsť k prihlasovacej výzve a zastaviť sa tam, čakať na údaj, ktorý nikto nenastavil.

Schválený účet obnovy alebo akákoľvek dokumentovaná metóda prihlásenia hosťa, ktorú vaše nasadenie používa, musí existovať a byť otestovaná. Kľúč SSH, ktorý funguje po sieti, automaticky nespĺňa výzvu na heslo konzoly, preto skontrolujte skutočné usporiadanie OS Login a kľúčov, namiesto toho, aby ste predpokladali, že tento prípad pokrýva.

Uchovávajte údaje obnovy v súkromí. Heslo root vložené do verejného príkladu startup-scriptu je druhý incident, ktorý čaká na príležitosť.

Krok 5: zaznamenajte vlastníka a vrátenie zmien

Skôr než čokoľvek zmeníte, zachovajte fungujúcu sieťovú konfiguráciu a zapíšte, kto ju spravuje, ktorá služba VPN je zapojená a ako sa vykonáva vrátenie zmien. Z fungujúcej relácie zachyťte aktuálne trasy, pravidlá a stav služby.

Práve tento záznam mení záchranný kanál na opravu, pretože konzola vám dá len výzvu. Napíšte ho pred zmenou, nie potom po pamäti. Vrátenie zmien odpísané z wiki nie je vrátenie zmien. Je to odhad s číslom verzie.

Krok 6: po zmene overte

Existujúca relácia SSH môže prežiť politiku, ktorá blokuje nové, preto testujte novou bežnou administrátorskou reláciou. Potom oddelene otestujte správanie VPN, ktoré ste zmenili.

Nechajte záchranný kanál otvorený, kým obe kontroly neprejdú, a potom ho podľa politiky prístupu zatvorte. Ak je SSH už stratené a prihlásenie cez konzolu nebolo pripravené, prestaňte brať sériový prístup ako záchrannú sieť a spustite schválený postup obnovy účtu alebo opravy inštancie. Postaviť ďalšiu VM ako jump host neopraví ani cestu hosťa, ani chýbajúce prihlasovacie údaje.