Pretigu serian restarigan vojon antaŭ ŝanĝo de VPN en GCE

Dua SSH-fenestro sur la sama interfaco ne estas restariga vojo. Ĝi dividas la itineron, la fajroŝirmilon kaj la demonon, kiun vi baldaŭ ŝanĝos, do ĝi paneas ĝuste en la momento, kiam vi bezonas ĝin. Antaŭ redakti VPN-itinerojn sur Compute Engine VM, pruvu tri apartajn aferojn: ke vi rajtas uzi la serian konzolon, ke vi povas legi ĝian eligon, kaj ke la gasto efektive donos al vi saluton. La subaj kontroloj iras laŭ tiu ordo, la plej malmultekosta unue, por ke mankanta permeso malkovriĝu antaŭ ol ĝi gravas.

Paŝo 1: konfirmu la permeson ĉe la nuba flanko

Nomu la precizan VM, projekton kaj zonon, poste kontrolu la aprobitan serian alirpolitikon de la organizo. La administranto bezonas la koncernan permeson, kaj interaga seria aliro devas esti ŝaltita por tiu instanco sub la validaj projekta kaj organizaj kontroloj.

Ne malfortigu organizan politikon nek ŝaltu konzolan aliron por tuta projekto por pretigi unu maŝinon. Petu la posedanton aranĝi la permesitan mekanismon antaŭ la eksperimento, ne dum la interrompo.

Paŝo 2: pruvu, ke vi povas legi eligon

Legi serian eligon estas la plej malmultekosta kontrolo, kaj ĝi ekzercas la transporton sen tuŝi la gastan saluton:

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

Anstataŭigu la identigilojn kaj uzu la permesitan pordon. Startaj mesaĝoj kaj konzola babilegado montras, ke la kanalo funkcias. Ili ne pruvas, ke vi povas akiri shell. Tial ĉi tiu paŝo estas aparta de la sekva.

Paŝo 3: pruvu, ke vi povas akiri interagan saluton

La konekta komando malfermas realan sesion, ne antaŭrigardon:

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

Traktu ĝin kiel vivan konzolon. Konfirmu la finpunkton antaŭ ol tajpi identigilojn, ĉar ĉiu klavopremo surteriĝas sur la instancon.

Ĉi tie plano, kiu ŝajnis kompleta, disfalas. Nuba permeso estas unu limo kaj la Linux-saluta prompto estas alia, kaj trapasi la unuan diras nenion pri la dua.

Paŝo 4: pretigu identigilojn, kiujn la gasto akceptos

Linux-bildoj provizitaj de Google ne ebligas lokan pasvortan saluton defaŭlte. Sekve seria sesio povas atingi salutan prompton kaj halti tie, atendante identigilon, kiun neniu agordis.

Aprobita restariga konto, aŭ kiu ajn dokumentita gasta saluta metodo, kiun via deplojo uzas, devas ekzisti kaj esti testita. SSH-ŝlosilo, kiu funkcias tra la reto, ne aŭtomate plenumas konzolan pasvortan prompton, do kontrolu la faktan OS Login kaj ŝlosilan aranĝon anstataŭ supozi, ke ĝi kovras ĉi tiun kazon.

Tenu restarigajn identigilojn privataj. root-pasvorto algluita en publikan startup-script-ekzemplon estas dua incidento atendanta okazi.

Paŝo 5: registru la posedanton kaj la malfaron

Antaŭ ol ŝanĝi ion ajn, konservu la funkciantan retan agordon kaj notu, kiu administras ĝin, kiu VPN-servo estas implikita kaj kiel okazas malfaro. El funkcianta sesio, kaptu la nunajn itinerojn, regulojn kaj servostaton.

Ĝuste tiu noto transformas restarigan kanalon en riparon, ĉar la konzolo donas al vi nur prompton. Skribu ĝin antaŭ la ŝanĝo, ne poste el memoro. Malfaro kopiita el vikio ne estas malfaro. Ĝi estas konjekto kun versia numero.

Paŝo 6: kontrolu post la ŝanĝo

Ekzistanta SSH-sesio povas postvivi politikon, kiu blokas novajn, do testu per freŝa normala administra sesio. Poste testu la VPN-konduton, kiun vi ŝanĝis, aparte.

Tenu la restarigan kanalon malfermita ĝis ambaŭ kontroloj pasas, kaj poste fermu ĝin laŭ la alirpolitiko. Se SSH jam perdiĝis kaj neniu konzola saluto estis preparita, ĉesu trakti serian aliron kiel sekurecan reton kaj komencu la rajtigitan laborfluon por konta restarigo aŭ instanca riparo. Starigi alian VM kiel saltan gastiganton riparas nek la gastan vojon nek la mankantajn identigilojn.