Pregătiți o cale de recuperare serială înainte de a schimba VPN-ul pe GCE
Schimbarea rutelor VPN pe un VM Compute Engine vă poate bloca afară. Dovediți permisiunea în cloud, ieșirea serială și o autentificare de oaspete înainte de a atinge rutele.
O a doua fereastră SSH pe aceeași interfață nu este o cale de recuperare. Ea partajează ruta, regula de firewall și demonul pe care urmează să îl schimbați, așa că eșuează exact în momentul în care aveți nevoie de ea. Înainte de a edita rute VPN pe un VM Compute Engine, dovediți trei lucruri separate: că puteți folosi consola serială, că îi puteți citi ieșirea și că oaspetele vă va da într-adevăr o autentificare. Verificările de mai jos merg în această ordine, cea mai ieftină prima, astfel încât o permisiune lipsă să fie descoperită înainte de a conta.
Pasul 1: confirmați permisiunea din partea cloud-ului
Nomiți VM-ul, proiectul și zona exacte, apoi verificați politica de acces serial aprobată de organizație. Administratorul are nevoie de permisiunea relevantă, iar accesul serial interactiv trebuie să fie activat pentru acea instanță sub controalele de proiect și organizație în vigoare.
Nu slăbiți o politică a organizației și nu activați accesul la consolă pentru un întreg proiect ca să pregătiți o singură mașină. Rugați proprietarul să aranjeze mecanismul permis înainte de experiment, nu în timpul întreruperii.
Pasul 2: dovediți că puteți citi ieșirea
Citirea ieșirii seriale este cea mai ieftină verificare și exersează transportul fără a atinge autentificarea oaspetelui:
gcloud compute instances get-serial-port-output VM_NAME \
--project PROJECT_ID --zone ZONE --port 1
Înlocuiți identificatorii și folosiți portul permis. Mesajele de pornire și vorbăria consolei vă spun că canalul funcționează. Ele nu dovedesc că puteți obține un shell. De aceea acest pas este separat de următorul.
Pasul 3: dovediți că puteți obține o autentificare interactivă
Comanda de conectare deschide o sesiune reală, nu o previzualizare:
gcloud compute connect-to-serial-port VM_NAME \
--project PROJECT_ID --zone ZONE --port 1
Tratați-o ca pe o consolă live. Confirmați punctul final înainte de a tasta acreditări, pentru că fiecare apăsare de tastă ajunge pe instanță.
Aici se destramă un plan care părea complet. Permisiunea în cloud este o graniță, iar promptul de autentificare Linux este alta, iar trecerea primei nu spune nimic despre a doua.
Pasul 4: pregătiți acreditări pe care oaspetele le va accepta
Imaginile Linux oferite de Google nu activează implicit autentificarea locală cu parolă. O sesiune serială poate astfel ajunge la un prompt de autentificare și se oprește acolo, așteptând o acreditare pe care nimeni nu a setat-o.
Trebuie să existe și să fie testat un cont de recuperare aprobat, sau orice metodă documentată de autentificare a oaspetelui folosită de implementarea dumneavoastră. O cheie SSH care funcționează în rețea nu satisface automat un prompt de parolă al consolei, așa că verificați aranjamentul real OS Login și al cheilor în loc să presupuneți că acoperă acest caz.
Păstrați private acreditările de recuperare. O parolă root lipită într-un exemplu public de startup-script este un al doilea incident care așteaptă să se întâmple.
Pasul 5: înregistrați proprietarul și revenirea
Înainte de a schimba ceva, păstrați configurația de rețea funcțională și notați cine o administrează, ce serviciu VPN este implicat și cum se face o revenire. Dintr-o sesiune funcțională, capturați rutele, regulile și starea serviciului actuale.
Această înregistrare transformă un canal de recuperare într-o reparație, pentru că consola vă dă doar un prompt. Scrieți-o înainte de schimbare, nu după aceea din memorie. O revenire copiată dintr-un wiki nu este o revenire. Este o presupunere cu un număr de versiune.
Pasul 6: verificați după schimbare
O sesiune SSH existentă poate supraviețui unei politici care le blochează pe cele noi, așa că testați cu o sesiune administrativă normală nouă. Apoi testați separat comportamentul VPN pe care l-ați schimbat.
Țineți canalul de recuperare deschis până când trec ambele verificări, apoi închideți-l conform politicii de acces. Dacă SSH este deja pierdut și nu s-a pregătit nicio autentificare prin consolă, opriți tratarea accesului serial ca plasă de siguranță și începeți fluxul autorizat de recuperare a contului sau de reparare a instanței. Ridicarea unui alt VM ca jump host nu repară nici calea oaspetelui, nici acreditările lipsă.