Sagatavojiet seriālo atkopšanas ceļu pirms GCE VPN maiņas

Otrs SSH logs tajā pašā saskarnē nav atkopšanas ceļš. Tas koplieto maršrutu, ugunsmūra noteikumu un dēmonu, ko gatavojaties mainīt, tāpēc tas neizdodas tieši tajā brīdī, kad tas jums ir vajadzīgs. Pirms rediģējat VPN maršrutus Compute Engine VM, pierādiet trīs atsevišķas lietas: ka drīkstat izmantot seriālo konsoli, ka varat nolasīt tās izvadi un ka viesis jums tiešām dos pieteikšanos. Tālāk minētās pārbaudes notiek šajā secībā, lētākā vispirms, lai trūkstošā atļauja tiktu atklāta pirms tā kļūst svarīga.

1. solis: apstipriniet mākoņa puses atļauju

Nosauciet precīzu VM, projektu un zonu, pēc tam pārbaudiet organizācijas apstiprināto seriālās piekļuves politiku. Administratoram ir vajadzīga attiecīgā atļauja, un interaktīvā seriālā piekļuve ir jābūt iespējotai šai instancei saskaņā ar spēkā esošajām projekta un organizācijas kontrolēm.

Nevājiniet organizācijas politiku un neieslēdziet konsoles piekļuvi visam projektam, lai sagatavotu vienu mašīnu. Lūdziet īpašniekam sakārtot atļauto mehānismu pirms eksperimenta, nevis tā pārtraukuma laikā.

2. solis: pierādiet, ka varat nolasīt izvadi

Seriālās izvades nolasīšana ir lētākā pārbaude, un tā trenē transportu, neaiztiekot viesa pieteikšanos:

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

Aizstājiet identifikatorus un izmantojiet atļauto portu. Sāknēšanas ziņojumi un konsoles pļāpāšana parāda, ka kanāls darbojas. Tie nepierāda, ka varat iegūt shell. Tāpēc šis solis ir atdalīts no nākamā.

3. solis: pierādiet, ka varat iegūt interaktīvu pieteikšanos

Savienojuma komanda atver īstu sesiju, nevis priekšskatījumu:

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

Uztveriet to kā dzīvu konsoli. Apstipriniet galapunktu pirms akreditācijas datu ievadīšanas, jo katrs taustiņa nospiedums nonāk uz instances.

Šeit sabrūk plāns, kas izskatījās pilnīgs. Mākoņa atļauja ir viena robeža, un Linux pieteikšanās uzvedne ir otra, un pirmās pāreja neko nepasaka par otro.

4. solis: sagatavojiet akreditācijas datus, ko viesis pieņems

Google nodrošinātie Linux attēli pēc noklusējuma neiespējo vietējo pieteikšanos ar paroli. Tāpēc seriālā sesija var sasniegt pieteikšanās uzvedni un tur apstāties, gaidot akreditācijas datus, ko neviens nav iestatījis.

Apstiprinātam atkopšanas kontam vai jebkurai dokumentētai viesa pieteikšanās metodei, ko izmanto jūsu izvietojums, ir jāpastāv un jābūt pārbaudītai. SSH atslēga, kas darbojas tīklā, automātiski neapmierina konsoles paroles uzvedni, tāpēc pārbaudiet faktisko OS Login un atslēgu izkārtojumu, nevis pieņemiet, ka tas aptver šo gadījumu.

Glabājiet atkopšanas akreditācijas datus privāti. Publiskā startup-script piemērā ielīmēta root parole ir otrs incidents, kas gaida notikšanu.

5. solis: reģistrējiet īpašnieku un atriti

Pirms kaut ko maināt, saglabājiet strādājošo tīkla konfigurāciju un pierakstiet, kas to pārvalda, kura VPN pakalpojums ir iesaistīts un kā tiek veikta atritināšana. No strādājošas sesijas ierakstiet pašreizējos maršrutus, noteikumus un pakalpojuma stāvokli.

Tieši šis ieraksts pārvērš atkopšanas kanālu remontā, jo konsolē jums dod tikai uzvedni. Rakstiet to pirms izmaiņām, nevis pēc tam no atmiņas. No wiki nokopēta atritināšana nav atritināšana. Tas ir minējums ar versijas numuru.

6. solis: pārbaudiet pēc izmaiņām

Esošā SSH sesija var pārdzīvot politiku, kas bloķē jaunas, tāpēc testējiet ar svaigu parastu administrēšanas sesiju. Pēc tam atsevišķi pārbaudiet mainīto VPN uzvedību.

Turiet atkopšanas kanālu atvērtu, līdz abas pārbaudes iztur, un pēc tam aizveriet to saskaņā ar piekļuves politiku. Ja SSH jau ir zaudēts un konsoles pieteikšanās nav sagatavota, pārtrauciet uzskatīt seriālo piekļuvi par drošības tīklu un sāciet atļauto konta atkopšanas vai instances remonta darbplūsmu. Citas VM kā jump host uzstādīšana nesalabo ne viesa ceļu, ne trūkstošos akreditācijas datus.