Připravte si sériovou cestu obnovy před změnou VPN v GCE

Druhé okno SSH na stejném rozhraní není cestou obnovy. Sdílí trasu, pravidlo firewallu i démona, který se chystáte změnit, takže selže přesně ve chvíli, kdy je potřebujete. Než upravíte trasy VPN na VM v Compute Engine, prokažte tři oddělené věci: že smíte použít sériovou konzoli, že umíte číst její výstup a že host vám skutečně dá přihlášení. Kontroly níže jdou v tomto pořadí, od nejlevnější, aby se chybějící oprávnění odhalilo dřív, než bude vadit.

Krok 1: potvrďte oprávnění na straně cloudu

Uveďte přesnou VM, projekt a zónu, potom zkontrolujte organizací schválenou zásadu sériového přístupu. Administrátor potřebuje příslušné oprávnění a interaktivní sériový přístup musí být pro tuto instanci povolen v rámci platných kontrol projektu a organizace.

Nezeslabujte zásadu organizace a nezapínejte přístup ke konzoli pro celý projekt, abyste připravili jeden stroj. Požádejte vlastníka, aby povolený mechanismus zařídil před experimentem, ne během výpadku.

Krok 2: prokažte, že umíte číst výstup

Čtení sériového výstupu je nejlevnější kontrola a procvičí přenos, aniž by se dotklo přihlášení hosta:

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

Nahraďte identifikátory a použijte povolený port. Zaváděcí zprávy a žvatlání konzole říkají, že kanál funguje. Nedokazují, že získáte shell. Proto je tento krok oddělený od dalšího.

Krok 3: prokažte, že získáte interaktivní přihlášení

Příkaz pro připojení otevírá skutečnou relaci, ne náhled:

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

Berte ji jako živou konzoli. Před zadáním přihlašovacích údajů potvrďte koncový bod, protože každý stisk klávesy dopadne na instanci.

Tady se plán, který vypadal úplně, rozpadá. Cloudové oprávnění je jedna hranice a přihlašovací výzva Linuxu je druhá, a překonání první nic neříká o druhé.

Krok 4: připravte přihlašovací údaje, které host přijme

Linuxové obrazy od Google ve výchozím nastavení nepovolují místní přihlášení heslem. Sériová relace proto může dojít k přihlašovací výzvě a zastavit se tam, čekat na údaj, který nikdo nenastavil.

Schválený účet pro obnovu, nebo jakákoli dokumentovaná metoda přihlášení hosta, kterou vaše nasazení používá, musí existovat a být otestována. Klíč SSH, který funguje po síti, automaticky nesplní výzvu k heslu konzole, takže zkontrolujte skutečné uspořádání OS Login a klíčů, místo abyste předpokládali, že tento případ pokrývá.

Uchovávejte údaje pro obnovu v soukromí. Heslo root vložené do veřejného příkladu startup-scriptu je druhý incident, který čeká na příležitost.

Krok 5: zaznamenejte vlastníka a vrácení změn

Než cokoli změníte, zachovejte fungující síťovou konfiguraci a zapište, kdo ji spravuje, která služba VPN je zapojená a jak se provádí vrácení změn. Z fungující relace zachyťte aktuální trasy, pravidla a stav služby.

Právě tento záznam mění záchranný kanál v opravu, protože konzole vám dá jen výzvu. Zapište ho před změnou, ne potom po paměti. Vrácení změn opsané z wiki není vrácení změn. Je to odhad s číslem verze.

Krok 6: po změně ověřte

Existující relace SSH může přežít zásadu, která blokuje nové, takže testujte novou běžnou administrátorskou relací. Pak odděleně otestujte chování VPN, které jste změnili.

Nechte záchranný kanál otevřený, dokud obě kontroly neprojdou, a potom ho podle zásady přístupu zavřete. Pokud je SSH už ztracené a přihlášení přes konzoli nebylo připraveno, přestaňte brát sériový přístup jako záchrannou síť a spusťte schválený postup obnovy účtu nebo opravy instance. Postavit další VM jako jump host neopraví ani cestu hosta, ani chybějící údaje.