Prepare um caminho de recuperação série antes de alterar a VPN no GCE

Uma segunda janela SSH na mesma interface não é um caminho de recuperação. Ela compartilha a rota, a regra de firewall e o daemon que está prestes a alterar, por isso falha exatamente no momento em que precisa dela. Antes de editar rotas VPN numa VM do Compute Engine, prove três coisas separadas: que pode usar a consola série, que consegue ler a sua saída e que o convidado realmente lhe dará um login. As verificações abaixo seguem essa ordem, a mais barata primeiro, para que uma permissão em falta seja descoberta antes de importar.

Passo 1: confirme a permissão do lado da nuvem

Indique a VM, o projeto e a zona exatos, e depois verifique a política de acesso série aprovada pela organização. O administrador precisa da permissão correspondente, e o acesso série interativo tem de estar ativado para essa instância sob os controlos de projeto e organização em vigor.

Não enfraqueça uma política da organização nem ative o acesso à consola para todo um projeto para preparar uma única máquina. Peça ao proprietário que organize o mecanismo permitido antes da experiência, não durante a interrupção.

Passo 2: prove que consegue ler a saída

Ler a saída série é a verificação mais barata, e exercita o transporte sem tocar no login do convidado:

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

Substitua os identificadores e use a porta permitida. As mensagens de arranque e a conversa da consola dizem-lhe que o canal funciona. Não provam que consegue obter uma shell. É por isso que este passo está separado do seguinte.

Passo 3: prove que consegue obter um login interativo

O comando de ligação abre uma sessão real, não uma pré-visualização:

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

Trate-a como uma consola em direto. Confirme o endpoint antes de escrever credenciais, porque cada tecla aterra na instância.

É aqui que um plano que parecia completo se desfaz. A permissão na nuvem é uma fronteira e o pedido de login do Linux é outra, e passar a primeira não diz nada sobre a segunda.

Passo 4: prepare credenciais que o convidado aceite

As imagens Linux fornecidas pela Google não ativam por predefinição o login local com palavra-passe. Uma sessão série pode, por isso, chegar a um pedido de login e parar ali, à espera de uma credencial que ninguém definiu.

Tem de existir e ser testada uma conta de recuperação aprovada, ou qualquer método documentado de login do convidado usado pela sua implementação. Uma chave SSH que funciona pela rede não satisfaz automaticamente um pedido de palavra-passe da consola, por isso verifique a disposição real do OS Login e das chaves em vez de assumir que cobre este caso.

Mantenha as credenciais de recuperação privadas. Uma palavra-passe de root colada num exemplo público de startup-script é um segundo incidente à espera de acontecer.

Passo 5: registe o proprietário e a reversão

Antes de alterar seja o que for, preserve a configuração de rede que funciona e anote quem a gere, que serviço VPN está envolvido e como é feita uma reversão. A partir de uma sessão funcional, capture as rotas, as regras e o estado do serviço atuais.

É esse registo que transforma um canal de recuperação numa reparação, porque a consola só lhe dá um pedido. Escreva-o antes da alteração, não de memória depois. Uma reversão copiada de uma wiki não é uma reversão. É um palpite com um número de versão.

Passo 6: verifique após a alteração

Uma sessão SSH existente pode sobreviver a uma política que bloqueia as novas, por isso teste com uma sessão de administração normal nova. Depois teste o comportamento da VPN que alterou, separadamente.

Mantenha o canal de recuperação aberto até ambas as verificações passarem, e feche-o depois segundo a política de acesso. Se o SSH já se perdeu e não foi preparado nenhum login por consola, deixe de tratar o acesso série como rede de segurança e inicie o fluxo autorizado de recuperação de conta ou de reparação de instância. Levantar outra VM como jump host não repara nem o caminho do convidado nem as credenciais em falta.