Paruoškite serijinį atkūrimo kelią prieš GCE VPN pakeitimą

Antras SSH langas tame pačiame sąsajoje nėra atkūrimo kelias. Jis dalijasi maršrutu, ugniasienės taisykle ir demonu, kurį ketinate keisti, todėl sugenda būtent tuo momentu, kai jo prireikia. Prieš redaguodami VPN maršrutus Compute Engine VM, įrodykite tris atskirus dalykus: kad galite naudotis serijine konsole, kad galite skaityti jos išvestį ir kad svečias tikrai duos jums prisijungimą. Toliau pateikti patikrinimai atliekami ta tvarka, pigiausias pirmiausia, kad trūkstamas leidimas būtų aptiktas anksčiau, nei taps svarbus.

1 žingsnis: patvirtinkite debesijos pusės leidimą

Nurodykite tikslų VM, projektą ir zoną, tada patikrinkite organizacijos patvirtintą serijinės prieigos politiką. Administratoriui reikia atitinkamo leidimo, o interaktyvi serijinė prieiga turi būti įjungta tam egzemplioriui pagal galiojančią projekto ir organizacijos kontrolę.

Nesilpninkite organizacijos politikos ir neįjunkite konsolės prieigos visam projektui, kad paruoštumėte vieną mašiną. Paprašykite savininko sutvarkyti leidžiamą mechanizmą prieš eksperimentą, o ne jo sutrikimo metu.

2 žingsnis: įrodykite, kad galite skaityti išvestį

Serijinės išvesties skaitymas yra pigiausias patikrinimas, ir jis išbando transportą neliesdamas svečio prisijungimo:

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

Pakeiskite identifikatorius ir naudokite leidžiamą prievadą. Paleidimo pranešimai ir konsolės šneka rodo, kad kanalas veikia. Jie neįrodo, kad galite gauti shell. Todėl šis žingsnis atskirtas nuo kito.

3 žingsnis: įrodykite, kad galite gauti interaktyvų prisijungimą

Prisijungimo komanda atidaro tikrą sesiją, o ne peržiūrą:

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

Elkitės su ja kaip su gyva konsole. Patvirtinkite galinį tašką prieš įvesdami prisijungimo duomenis, nes kiekvienas klavišo paspaudimas nukrenta ant egzemplioriaus.

Čia subyra planas, kuris atrodė išsamus. Debesijos leidimas yra viena riba, o Linux prisijungimo užklausa yra kita, ir pirmosios perėjimas nieko nesako apie antrąją.

4 žingsnis: paruoškite prisijungimo duomenis, kuriuos svečias priims

Google teikiami Linux atvaizdžiai pagal nutylėjimą neįjungia vietinio prisijungimo slaptažodžiu. Todėl serijinė sesija gali pasiekti prisijungimo užklausą ir ten sustoti, laukdama duomenų, kurių niekas nenustatė.

Patvirtinta atkūrimo paskyra arba bet koks dokumentuotas svečio prisijungimo metodas, kurį naudoja jūsų diegimas, turi egzistuoti ir būti išbandytas. SSH raktas, veikiantis tinkle, automatiškai netenkina konsolės slaptažodžio užklausos, todėl patikrinkite tikrąją OS Login ir raktų tvarką, o ne manykite, kad ji apima šį atvejį.

Saugokite atkūrimo duomenis privačiai. Į viešą startup-script pavyzdį įklijuotas root slaptažodis yra antras incidentas, laukiantis įvykio.

5 žingsnis: užregistruokite savininką ir atšaukimą

Prieš ką nors keisdami, išsaugokite veikiančią tinklo konfigūraciją ir užrašykite, kas ją valdo, kuri VPN paslauga dalyvauja ir kaip atliekamas atšaukimas. Iš veikiančios sesijos užfiksuokite dabartinius maršrutus, taisykles ir paslaugos būseną.

Būtent šis įrašas paverčia atkūrimo kanalą taisymu, nes konsolė duoda tik užklausą. Užrašykite jį prieš pakeitimą, o ne po jo iš atminties. Iš wiki nukopijuotas atšaukimas nėra atšaukimas. Tai spėjimas su versijos numeriu.

6 žingsnis: patikrinkite po pakeitimo

Esama SSH sesija gali išgyventi politiką, kuri blokuoja naujas, todėl testuokite nauja įprasta administravimo sesija. Tada atskirai išbandykite pakeistą VPN elgseną.

Laikykite atkūrimo kanalą atvirą, kol abu patikrinimai praeis, ir tada uždarykite jį pagal prieigos politiką. Jei SSH jau prarastas ir konsolės prisijungimas nebuvo paruoštas, nustokite laikyti serijinę prieigą saugos tinklu ir pradėkite leidžiamą paskyros atkūrimo ar egzemplioriaus taisymo eigą. Kitos VM kaip jump host pastatymas nesutvarko nei svečio kelio, nei trūkstamų prisijungimo duomenų.