Prepare una vía de recuperación serie antes de cambiar la VPN en GCE

Una segunda ventana SSH en la misma interfaz no es una vía de recuperación. Comparte la ruta, la regla de firewall y el demonio que está a punto de cambiar, así que falla justo en el momento en que la necesita. Antes de editar rutas VPN en una VM de Compute Engine, demuestre tres cosas por separado: que puede usar la consola serie, que puede leer su salida y que el invitado realmente le dará un inicio de sesión. Las comprobaciones siguientes van en ese orden, la más barata primero, para que un permiso que falta se descubra antes de que importe.

Paso 1: confirme el permiso del lado de la nube

Nombre la VM, el proyecto y la zona exactos, y luego revise la política de acceso serie aprobada por la organización. El administrador necesita el permiso correspondiente, y el acceso serie interactivo debe estar habilitado para esa instancia bajo los controles de proyecto y organización vigentes.

No debilite una política de la organización ni active el acceso a la consola para todo un proyecto con el fin de preparar una sola máquina. Pida al propietario que organice el mecanismo permitido antes del experimento, no durante la interrupción.

Paso 2: demuestre que puede leer la salida

Leer la salida serie es la comprobación más barata, y ejercita el transporte sin tocar el inicio de sesión del invitado:

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

Sustituya los identificadores y use el puerto permitido. Los mensajes de arranque y la cháchara de la consola le dicen que el canal funciona. No demuestran que pueda obtener un shell. Por eso este paso está separado del siguiente.

Paso 3: demuestre que puede obtener un inicio de sesión interactivo

El comando de conexión abre una sesión real, no una vista previa:

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

Trátela como una consola en vivo. Confirme el punto de conexión antes de escribir credenciales, porque cada pulsación de tecla aterriza en la instancia.

Aquí es donde un plan que parecía completo se desmorona. El permiso en la nube es una frontera y el aviso de inicio de sesión de Linux es otra, y pasar la primera no dice nada sobre la segunda.

Paso 4: prepare credenciales que el invitado acepte

Las imágenes de Linux que proporciona Google no habilitan el inicio de sesión local con contraseña de forma predeterminada. Por eso una sesión serie puede llegar a un aviso de inicio de sesión y detenerse ahí, esperando una credencial que nadie configuró.

Debe existir y estar probada una cuenta de recuperación aprobada, o cualquier método documentado de inicio de sesión del invitado que use su despliegue. Una clave SSH que funciona por la red no satisface automáticamente un aviso de contraseña de consola, así que compruebe la disposición real de OS Login y las claves en lugar de suponer que cubre este caso.

Mantenga privadas las credenciales de recuperación. Una contraseña de root pegada en un ejemplo público de startup-script es un segundo incidente esperando a ocurrir.

Paso 5: registre el propietario y la reversión

Antes de cambiar nada, conserve la configuración de red que funciona y anote quién la gestiona, qué servicio VPN interviene y cómo se realiza una reversión. Desde una sesión que funcione, capture las rutas, las reglas y el estado del servicio actuales.

Ese registro es lo que convierte un canal de recuperación en una reparación, porque la consola solo le da un aviso. Escríbalo antes del cambio, no de memoria después. Una reversión copiada de una wiki no es una reversión. Es una suposición con un número de versión.

Paso 6: verifique después del cambio

Una sesión SSH existente puede sobrevivir a una política que bloquea las nuevas, así que pruebe con una sesión de administración normal nueva. Luego pruebe por separado el comportamiento de la VPN que cambió.

Mantenga abierto el canal de recuperación hasta que pasen ambas comprobaciones, y ciérrelo después según la política de acceso. Si SSH ya se ha perdido y no se preparó ningún inicio de sesión por consola, deje de tratar el acceso serie como una red de seguridad y comience el flujo autorizado de recuperación de cuenta o de reparación de instancia. Levantar otra VM como jump host no repara ni la ruta del invitado ni las credenciales que faltan.