Préparez un chemin de récupération série avant de modifier le VPN sur GCE

Une seconde fenêtre SSH sur la même interface n’est pas un chemin de récupération. Elle partage la route, la règle de pare-feu et le démon que vous êtes sur le point de modifier, elle échoue donc exactement au moment où vous en avez besoin. Avant de modifier des routes VPN sur une VM Compute Engine, prouvez trois choses distinctes : que vous pouvez utiliser la console série, que vous pouvez lire sa sortie et que l’invité vous donnera réellement un identifiant. Les vérifications ci-dessous s’enchaînent dans cet ordre, la moins chère d’abord, afin qu’une autorisation manquante soit découverte avant d’avoir de l’importance.

Étape 1 : confirmez l’autorisation côté cloud

Nommez la VM, le projet et la zone exacts, puis vérifiez la politique d’accès série approuvée par l’organisation. L’administrateur a besoin de l’autorisation correspondante, et l’accès série interactif doit être activé pour cette instance dans le cadre des contrôles de projet et d’organisation en vigueur.

N’affaiblissez pas une politique d’organisation et n’activez pas l’accès console pour tout un projet afin de préparer une seule machine. Demandez au propriétaire d’organiser le mécanisme autorisé avant l’expérience, pas pendant la panne.

Étape 2 : prouvez que vous pouvez lire la sortie

Lire la sortie série est la vérification la moins chère, et elle exerce le transport sans toucher à l’identifiant de l’invité :

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

Remplacez les identifiants et utilisez le port autorisé. Les messages de démarrage et le bavardage de la console vous indiquent que le canal fonctionne. Ils ne prouvent pas que vous pouvez obtenir un shell. C’est pourquoi cette étape est distincte de la suivante.

Étape 3 : prouvez que vous pouvez obtenir un identifiant interactif

La commande de connexion ouvre une vraie session, pas un aperçu :

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

Traitez-la comme une console en direct. Confirmez le point de terminaison avant de saisir des identifiants, car chaque frappe atterrit sur l’instance.

C’est ici qu’un plan qui semblait complet s’effondre. L’autorisation cloud est une frontière et l’invite de connexion Linux en est une autre, et franchir la première ne dit rien de la seconde.

Étape 4 : préparez des identifiants que l’invité acceptera

Les images Linux fournies par Google n’activent pas par défaut la connexion locale par mot de passe. Une session série peut donc atteindre une invite de connexion et s’y arrêter, en attente d’un identifiant que personne n’a défini.

Un compte de récupération approuvé, ou toute méthode documentée de connexion invité utilisée par votre déploiement, doit exister et être testé. Une clé SSH qui fonctionne sur le réseau ne satisfait pas automatiquement une invite de mot de passe de console, alors vérifiez la disposition réelle d’OS Login et des clés plutôt que de supposer qu’elle couvre ce cas.

Gardez les identifiants de récupération privés. Un mot de passe root collé dans un exemple public de startup-script est un second incident qui attend de se produire.

Étape 5 : consignez le propriétaire et le retour arrière

Avant de changer quoi que ce soit, conservez la configuration réseau qui fonctionne et notez qui la gère, quel service VPN est concerné et comment un retour arrière est effectué. Depuis une session qui fonctionne, capturez les routes, les règles et l’état du service actuels.

C’est cette consignation qui transforme un canal de récupération en réparation, car la console ne vous donne qu’une invite. Écrivez-la avant le changement, pas de mémoire ensuite. Un retour arrière copié depuis un wiki n’est pas un retour arrière. C’est une supposition avec un numéro de version.

Étape 6 : vérifiez après le changement

Une session SSH existante peut survivre à une politique qui bloque les nouvelles, alors testez avec une nouvelle session d’administration normale. Testez ensuite séparément le comportement VPN que vous avez modifié.

Gardez le canal de récupération ouvert jusqu’à ce que les deux vérifications passent, puis fermez-le selon la politique d’accès. Si SSH est déjà perdu et qu’aucune connexion console n’a été préparée, cessez de traiter l’accès série comme un filet de sécurité et lancez le flux autorisé de récupération de compte ou de réparation d’instance. Monter une autre VM comme jump host ne répare ni le chemin de l’invité ni les identifiants manquants.