Підготуйте шлях аварійного відновлення через послідовну консоль до зміни VPN у GCE

Друге вікно SSH на тому самому інтерфейсі — не шлях відновлення. Воно використовує той самий маршрут, правило брандмауера й демон, які ви збираєтеся змінити, тому відмовляє саме в той момент, коли потрібне. Перш ніж редагувати VPN-маршрути на ВМ Compute Engine, доведіть три окремі речі: що вам дозволено користуватися послідовною консоллю, що ви можете читати її вивід і що гість справді дасть вам вхід. Перевірки нижче йдуть у цьому порядку, від найдешевшої, щоб відсутній дозвіл виявився до того, як стане важливим.

Крок 1: підтвердьте дозвіл з боку хмари

Укажіть точну ВМ, проєкт і зону, потім перевірте затверджену організацією політику послідовного доступу. Адміністратору потрібен відповідний дозвіл, а інтерактивний послідовний доступ має бути ввімкнений для цього екземпляра в межах чинних контролів проєкту й організації.

Не послаблюйте політику організації й не вмикайте доступ до консолі для всього проєкту, щоб підготувати одну машину. Попросіть власника влаштувати дозволений механізм до експерименту, а не під час збою.

Крок 2: доведіть, що можете читати вивід

Читання послідовного виводу — найдешевша перевірка, і вона тренує транспорт, не торкаючись входу гостя:

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

Замініть ідентифікатори й використайте дозволений порт. Повідомлення завантаження й балачки консолі кажуть, що канал працює. Вони не доводять, що ви отримаєте оболонку. Тому цей крок окремий від наступного.

Крок 3: доведіть, що можете отримати інтерактивний вхід

Команда підключення відкриває справжню сесію, а не попередній перегляд:

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

Ставтеся до неї як до живої консолі. Підтвердьте кінцеву точку, перш ніж вводити облікові дані, бо кожне натискання клавіші потрапляє на екземпляр.

Саме тут план, що здавався повним, розсипається. Дозвіл у хмарі — одна межа, а запрошення входу Linux — інша, і проходження першої нічого не говорить про другу.

Крок 4: підготуйте облікові дані, які прийме гість

Образи Linux від Google за замовчуванням не вмикають локальний вхід за паролем. Тому послідовна сесія може дійти до запрошення входу й зупинитися там, чекаючи облікових даних, які ніхто не задав.

Затверджений обліковий запис відновлення або будь-який задокументований метод входу гостя, який використовує ваше розгортання, мають існувати й бути перевіреними. Ключ SSH, що працює мережею, не задовольняє автоматично запит пароля консолі, тому перевірте фактичну схему OS Login і ключів, а не припускайте, що вона покриває цей випадок.

Тримайте облікові дані відновлення приватними. Пароль root, вставлений у публічний приклад startup-script, — другий інцидент, що чекає свого часу.

Крок 5: запишіть власника й відкат

Перш ніж щось змінювати, збережіть робочу мережеву конфігурацію й запишіть, хто нею керує, яка служба VPN задіяна та як виконується відкат. З робочої сесії зафіксуйте поточні маршрути, правила й стан служби.

Саме цей запис перетворює канал відновлення на ремонт, бо консоль дає лише запрошення. Напишіть його до зміни, а не потім з пам’яті. Відкат, скопійований з вікі, — не відкат. Це здогад із номером версії.

Крок 6: перевірте після зміни

Наявна сесія SSH може пережити політику, що блокує нові, тому перевіряйте свіжою звичайною адміністративною сесією. Потім окремо перевірте змінену поведінку VPN.

Тримайте канал відновлення відкритим, доки обидві перевірки не пройдуть, а потім закрийте його згідно з політикою доступу. Якщо SSH уже втрачено й вхід через консоль не підготовлено, перестаньте вважати послідовний доступ страховкою й почніть дозволений процес відновлення облікового запису або ремонту екземпляра. Підняття ще однієї ВМ як jump host не виправить ні шлях гостя, ні відсутні облікові дані.