Unha segunda xanela SSH na mesma interface non é unha vía de recuperación. Comparte a ruta, a regra de firewall e o daemon que está a piques de cambiar, así que falla xusto no momento en que a necesita. Antes de editar rutas VPN nunha VM de Compute Engine, demostre tres cousas por separado: que pode usar a consola serie, que pode ler a súa saída e que o convidado realmente lle dará un inicio de sesión. As comprobacións seguintes van nesa orde, a máis barata primeiro, para que un permiso que falta se descubra antes de que importe.

Paso 1: confirme o permiso do lado da nube

Nomee a VM, o proxecto e a zona exactos, e despois revise a política de acceso serie aprobada pola organización. O administrador necesita o permiso correspondente, e o acceso serie interactivo debe estar habilitado para esa instancia baixo os controis de proxecto e organización vixentes.

Non debilite unha política da organización nin active o acceso á consola para todo un proxecto para preparar unha soa máquina. Pida ao propietario que organice o mecanismo permitido antes do experimento, non durante a interrupción.

Paso 2: demostre que pode ler a saída

Ler a saída serie é a comprobación máis barata, e exercita o transporte sen tocar o inicio de sesión do convidado:

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

Substitúa os identificadores e use o porto permitido. As mensaxes de arranque e a cháchara da consola dinlle que o canal funciona. Non demostran que poida obter un shell. Por iso este paso está separado do seguinte.

Paso 3: demostre que pode obter un inicio de sesión interactivo

O comando de conexión abre unha sesión real, non unha vista previa:

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

Trátea como unha consola en vivo. Confirme o punto final antes de escribir credenciais, porque cada pulsación de tecla aterra na instancia.

Aquí é onde un plan que parecía completo se desfai. O permiso na nube é unha fronteira e o aviso de inicio de sesión de Linux é outra, e pasar a primeira non di nada sobre a segunda.

Paso 4: prepare credenciais que o convidado acepte

As imaxes Linux que proporciona Google non habilitan o inicio de sesión local con contrasinal por defecto. Por iso unha sesión serie pode chegar a un aviso de inicio de sesión e deterse alí, esperando unha credencial que ninguén configurou.

Debe existir e estar probada unha conta de recuperación aprobada, ou calquera método documentado de inicio de sesión do convidado que use o seu despregamento. Unha clave SSH que funciona pola rede non satisfai automaticamente un aviso de contrasinal de consola, así que comprobe a disposición real de OS Login e das claves en lugar de supoñer que cobre este caso.

Manteña privadas as credenciais de recuperación. Un contrasinal de root pegado nun exemplo público de startup-script é un segundo incidente esperando a ocorrer.

Paso 5: rexistre o propietario e a reversión

Antes de cambiar nada, conserve a configuración de rede que funciona e anote quen a xestiona, que servizo VPN interfire e como se realiza unha reversión. Desde unha sesión que funcione, capture as rutas, as regras e o estado do servizo actuais.

Ese rexistro é o que converte unha canle de recuperación nunha reparación, porque a consola só lle dá un aviso. Escríbao antes do cambio, non de memoria despois. Unha reversión copiada dun wiki non é unha reversión. É unha suposición cun número de versión.

Paso 6: verifique despois do cambio

Unha sesión SSH existente pode sobrevivir a unha política que bloquea as novas, así que probe cunha sesión de administración normal nova. Despois probe por separado o comportamento da VPN que cambiou.

Manteña aberta a canle de recuperación ata que pasen ambas as comprobacións, e péchea despois segundo a política de acceso. Se SSH xa se perdeu e non se preparou ningún inicio de sesión por consola, deixe de tratar o acceso serie como unha rede de seguridade e comece o fluxo autorizado de recuperación de conta ou de reparación de instancia. Levantar outra VM como jump host non repara nin a ruta do convidado nin as credenciais que faltan.

Artigos relacionados