Maghanda ng Serial na Daan ng Pagbawi Bago Baguhin ang VPN sa GCE

Ang pangalawang SSH window sa parehong interface ay hindi daan ng pagbawi. Ibinabahagi nito ang ruta, ang firewall rule at ang daemon na babaguhin mo, kaya nabigo ito sa eksaktong sandaling kailangan mo ito. Bago i-edit ang mga ruta ng VPN sa isang Compute Engine VM, patunayan ang tatlong magkakaibang bagay: na maaari mong gamitin ang serial console, na mababasa mo ang output nito, at na bibigyan ka talaga ng bisita ng pag-login. Ang mga pagsusuri sa ibaba ay sumusunod sa ganoong pagkakasunod-sunod, pinakamura muna, upang matuklasan ang kulang na pahintulot bago ito maging mahalaga.

Hakbang 1: kumpirmahin ang pahintulot sa panig ng cloud

Pangalanan ang eksaktong VM, proyekto at zone, pagkatapos suriin ang aprubadong patakaran ng serial access ng organisasyon. Kailangan ng administrator ang kaugnay na pahintulot, at ang interactive na serial access ay dapat na paganahin para sa instance na iyon sa ilalim ng mga kontrol ng proyekto at organisasyon na ipinatutupad.

Huwag pahinain ang patakaran ng organisasyon o buksan ang access sa console para sa buong proyekto para maghanda ng isang makina. Hilingin sa may-ari na ayusin ang pinapayagang mekanismo bago ang eksperimento, hindi habang may pagkawala ng serbisyo.

Hakbang 2: patunayang mababasa mo ang output

Ang pagbasa ng serial output ay ang pinakamurang pagsusuri, at sinasanay nito ang transport nang hindi hinahawakan ang pag-login ng bisita:

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

Palitan ang mga identifier at gamitin ang pinapayagang port. Ang mga mensahe sa boot at ang usapan sa console ay nagsasabi na gumagana ang channel. Hindi nila pinapatunayan na makakakuha ka ng shell. Kaya hiwalay ang hakbang na ito sa susunod.

Hakbang 3: patunayang makakakuha ka ng interactive na pag-login

Binubuksan ng command ng koneksyon ang tunay na session, hindi preview:

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

Ituring ito na live na console. Kumpirmahin ang endpoint bago mag-type ng mga kredensyal, dahil bawat pagpindot sa key ay dumarating sa instance.

Dito bumabagsak ang isang planong mukhang kumpleto. Ang pahintulot sa cloud ay isang hangganan at ang prompt ng pag-login ng Linux ay isa pa, at ang pagpasa sa una ay walang sinasabi tungkol sa pangalawa.

Hakbang 4: maghanda ng mga kredensyal na tatanggapin ng bisita

Ang mga Linux image na ibinibigay ng Google ay hindi nagpapagana ng lokal na pag-login gamit ang password bilang default. Kaya ang isang serial session ay maaaring umabot sa prompt ng pag-login at huminto doon, naghihintay ng kredensyal na walang nagtakda.

Dapat mayroon at nasubukan ang isang aprubadong recovery account, o anumang dokumentadong paraan ng pag-login ng bisita na ginagamit ng iyong deployment. Ang SSH key na gumagana sa network ay hindi awtomatikong tumutugon sa prompt ng password ng console, kaya suriin ang aktwal na OS Login at key arrangement sa halip na ipalagay na sakop nito ang kasong ito.

Panatilihing pribado ang mga kredensyal sa pagbawi. Ang root password na naipaste sa isang pampublikong halimbawa ng startup-script ay pangalawang insidente na naghihintay mangyari.

Hakbang 5: itala ang may-ari at ang rollback

Bago baguhin ang anuman, panatilihin ang gumaganang network configuration at isulat kung sino ang namamahala nito, aling serbisyo ng VPN ang sangkot at paano isinasagawa ang rollback. Mula sa gumaganang session, kunin ang kasalukuyang mga ruta, patakaran at estado ng serbisyo.

Ang talaang iyon ang nagpapalit ng daan ng pagbawi tungo sa pagkukumpuni, dahil ang console ay nagbibigay lamang ng prompt. Isulat ito bago ang pagbabago, hindi pagkatapos mula sa memorya. Ang rollback na kinopya mula sa wiki ay hindi rollback. Ito ay hula na may numero ng bersyon.

Hakbang 6: i-verify pagkatapos ng pagbabago

Ang umiiral na SSH session ay maaaring mabuhay sa patakarang humaharang sa mga bago, kaya subukan gamit ang bagong normal na administrative session. Pagkatapos, subukan nang hiwalay ang pag-uugali ng VPN na binago mo.

Panatilihing bukas ang daan ng pagbawi hanggang pumasa ang dalawang pagsusuri, at pagkatapos ay isara ito ayon sa patakaran ng access. Kung nawala na ang SSH at walang nailaan na pag-login sa console, itigil ang pagtrato sa serial access bilang safety net at simulan ang awtorisadong workflow ng pagbawi ng account o pagkukumpuni ng instance. Ang pagtayo ng isa pang VM bilang jump host ay hindi nag-aayos ng daan ng bisita o ng kulang na mga kredensyal.