Valmistage GCE VPN muudatuse eel ette seeriapõhine taastetee

Teine SSH-aken samal liidesel ei ole taastetee. See jagab marsruuti, tulemüürireeglit ja deemonit, mida kavatsete muuta, mistõttu see ebaõnnestub täpselt sel hetkel, kui seda vajate. Enne VPN-marsruutide muutmist Compute Engine'i VM-is tõestage kolme eraldi asja: et tohin kasutada seeriakonsooli, et suudan selle väljundit lugeda ja et külaline annab teile tõesti sisselogimise. Allpool olevad kontrollid kulgevad selles järjekorras, odavaim enne, et puuduv õigus avastataks enne, kui see loeb.

Samm 1: kinnitage pilvepoolne õigus

Nimetage täpne VM, projekt ja tsoon, seejärel kontrollige organisatsiooni kinnitatud seeriajuurdepääsu poliitikat. Administraatoril on vaja asjakohast õigust ja interaktiivne seeriajuurdepääs peab selle eksemplari jaoks olema lubatud kehtivate projekti- ja organisatsioonikontrollide all.

Ärge nõrgendage organisatsiooni poliitikat ega lülitage konsoolijuurdepääsu sisse terve projekti ulatuses, et ühte masinat ette valmistada. Paluge omanikul lubatud mehhanism enne katset korraldada, mitte katkestuse ajal.

Samm 2: tõestage, et suudate väljundit lugeda

Seeriaväljundi lugemine on odavaim kontroll ja see harjutab transporti külalise sisselogimist puutumata:

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

Asendage identifikaatorid ja kasutage lubatud porti. Alglaadimisteated ja konsooli jutuvada näitavad, et kanal töötab. Need ei tõesta, et saate shelli. Seetõttu on see samm järgmisest eraldi.

Samm 3: tõestage, et saate interaktiivse sisselogimise

Ühenduskäsk avab tõelise sessiooni, mitte eelvaate:

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

Käsitlege seda elava konsoolina. Kinnitage lõpp-punkt enne mandaatide sisestamist, sest iga klahvivajutus maandub eksemplaril.

Siin laguneb plaan, mis tundus täielik. Pilveõigus on üks piir ja Linuxi sisselogimisküsimus on teine, ning esimese läbimine ei ütle teise kohta midagi.

Samm 4: valmistage ette mandaadid, mida külaline aktsepteerib

Google'i pakutavad Linuxi kujutised ei luba vaikimisi kohalikku paroolipõhist sisselogimist. Seetõttu võib seeriasessioon jõuda sisselogimisküsimuseni ja sinna peatuda, oodates mandaati, mida keegi ei seadnud.

Kinnitatud taastekonto või mis tahes dokumenteeritud külalise sisselogimismeetod, mida teie juurutus kasutab, peab olemas olema ja testitud. Võrgus toimiv SSH-võti ei vasta automaatselt konsooli parooliküsimusele, seega kontrollige tegelikku OS Logini ja võtmete korraldust, selle asemel et eeldada, et see juhtum on kaetud.

Hoidke taastemandaadid privaatsena. Avalikku startup-scripti näidissse kleebitud root-parool on teine juhtum, mis ootab juhtumist.

Samm 5: registreerige omanik ja tagasipööramine

Enne millegi muutmist säilitage töötav võrgukonfiguratsioon ja kirjutage üles, kes seda haldab, milline VPN-teenus on kaasatud ja kuidas tagasipööramine toimub. Töötavast sessioonist jäädvustage praegused marsruudid, reeglid ja teenuse olek.

Just see kirje muudab taasteteekonna paranduseks, sest konsool annab teile ainult küsimuse. Kirjutage see enne muudatust, mitte hiljem mälu järgi. Wikipediast kopeeritud tagasipööramine ei ole tagasipööramine. See on oletus koos versiooninumbriga.

Samm 6: kontrollige pärast muudatust

Olemasolev SSH-sessioon võib üle elada poliitika, mis blokeerib uusi, seega testige värske tavalise haldussessiooniga. Seejärel testige eraldi VPN-i käitumist, mida muutsite.

Hoidke taasteteekond avatuna, kuni mõlemad kontrollid läbivad, ja sulgege see seejärel juurdepääsupoliitika kohaselt. Kui SSH on juba kadunud ja konsooli sisselogimist ei ole ette valmistatud, lõpetage seeriajuurdepääsu pidamine turvavõrguks ja alustage volitatud konto taastamise või eksemplari parandamise töövoogu. Teise VM-i püstitamine hüppemajutajana ei paranda ei külalise teed ega puuduvaid mandaate.