Подготовьте путь аварийного восстановления через последовательную консоль до смены VPN в GCE
Смена VPN-маршрутов на ВМ Compute Engine может заблокировать вам доступ. Докажите разрешение в облаке, последовательный вывод и вход гостя, прежде чем трогать маршруты.
Второе окно 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 не исправит ни путь гостя, ни недостающие учётные данные.