Preparate un percorso di ripristino seriale prima di modificare la VPN su GCE

Una seconda finestra SSH sulla stessa interfaccia non è un percorso di ripristino. Condivide la rotta, la regola del firewall e il demone che state per modificare, quindi fallisce esattamente nel momento in cui vi serve. Prima di modificare le rotte VPN su una VM Compute Engine, dimostrate tre cose separate: che potete usare la console seriale, che potete leggerne l’output e che il guest vi darà davvero un accesso. I controlli seguenti procedono in quest’ordine, il più economico per primo, così un permesso mancante viene scoperto prima che conti.

Passo 1: confermate il permesso lato cloud

Nominate la VM, il progetto e la zona esatti, poi controllate la policy di accesso seriale approvata dall’organizzazione. L’amministratore ha bisogno del permesso pertinente, e l’accesso seriale interattivo deve essere abilitato per quell’istanza sotto i controlli di progetto e organizzazione in vigore.

Non indebolite una policy dell’organizzazione e non attivate l’accesso alla console per un intero progetto per preparare una sola macchina. Chiedete al proprietario di organizzare il meccanismo consentito prima dell’esperimento, non durante l’interruzione.

Passo 2: dimostrate che potete leggere l’output

Leggere l’output seriale è il controllo più economico, ed esercita il trasporto senza toccare l’accesso del guest:

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

Sostituite gli identificatori e usate la porta consentita. I messaggi di avvio e il chiacchiericcio della console vi dicono che il canale funziona. Non dimostrano che possiate ottenere una shell. Per questo il passo è separato dal successivo.

Passo 3: dimostrate che potete ottenere un accesso interattivo

Il comando di connessione apre una sessione reale, non un’anteprima:

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

Trattatela come una console live. Confermate l’endpoint prima di digitare le credenziali, perché ogni battuta di tasto atterra sull’istanza.

Qui un piano che sembrava completo crolla. Il permesso cloud è un confine e il prompt di accesso di Linux è un altro, e superare il primo non dice nulla sul secondo.

Passo 4: preparate credenziali che il guest accetterà

Le immagini Linux fornite da Google non abilitano per impostazione predefinita l’accesso locale con password. Una sessione seriale può quindi raggiungere un prompt di accesso e fermarsi lì, in attesa di una credenziale che nessuno ha impostato.

Un account di ripristino approvato, o qualunque metodo documentato di accesso guest usato dal vostro deployment, deve esistere ed essere testato. Una chiave SSH che funziona sulla rete non soddisfa automaticamente un prompt di password della console, quindi controllate l’effettiva disposizione di OS Login e delle chiavi invece di supporre che copra questo caso.

Mantenete private le credenziali di ripristino. Una password di root incollata in un esempio pubblico di startup-script è un secondo incidente in attesa di accadere.

Passo 5: registrate il proprietario e il rollback

Prima di cambiare qualsiasi cosa, conservate la configurazione di rete funzionante e annotate chi la gestisce, quale servizio VPN è coinvolto e come si esegue un rollback. Da una sessione funzionante, catturate le rotte, le regole e lo stato del servizio attuali.

È quella registrazione che trasforma un canale di ripristino in una riparazione, perché la console vi dà solo un prompt. Scrivetela prima della modifica, non a memoria dopo. Un rollback copiato da una wiki non è un rollback. È un’ipotesi con un numero di versione.

Passo 6: verificate dopo la modifica

Una sessione SSH esistente può sopravvivere a una policy che blocca quelle nuove, quindi provate con una nuova sessione amministrativa normale. Poi provate separatamente il comportamento VPN che avete modificato.

Tenete aperto il canale di ripristino finché entrambi i controlli non passano, poi chiudetelo secondo la policy di accesso. Se SSH è già perduto e non è stato preparato alcun accesso da console, smettete di trattare l’accesso seriale come rete di sicurezza e avviate il flusso autorizzato di ripristino dell’account o di riparazione dell’istanza. Alzare un’altra VM come jump host non ripara né il percorso del guest né le credenziali mancanti.