Автоматические обновления VPN-сервера требуют проверенного пути восстановления

Автоматические обновления — разумная политика для сервера, до которого вы добираетесь через его собственный VPN, и одновременно единственная точка отказа, которую вы создаёте себе сами. Операция пакета перезапускает службу, туннель падает, и административный путь, которым вы пользовались, исчезает вместе с ним. Существуют две модели восстановления, и выбор между ними зависит от одного условия: есть ли у вас путь входа, который не проходит через то, что обновляется.

Две модели восстановления, одно решающее условие

Первая модель доверяет обновлению и предполагает, что после него вы сможете подключиться снова. Она работает, когда VPN — один из нескольких способов добраться до хоста и когда сбой туннеля не лишает вас возможности его диагностировать. Вторая модель заранее размещает независимый путь, обычно консоль хостинг-провайдера, и рассматривает туннель как то, что обслуживание сломает с наибольшей вероятностью. Обе модели защитимы, и только одна из них требует работы заранее.

Решающее условие легко произнести и легко пропустить. Если каждый административный путь к машине идёт через обновляемую службу, у вас нет никакой модели восстановления, только ожидание. Скажите это вслух на разборе изменения.

Проверка этого условия занимает десять минут и должна произойти до первого автоматического обновления, а не во время инцидента. Откройте консоль, пока всё работает, убедитесь, что учётные данные действуют, и закройте её снова. Убедитесь, что консоль открывается на том хосте, о котором вы думаете. Затем убедитесь, что вход, который вы действительно использовали бы в 3 часа ночи, всё ещё работает.

Последняя часть важнее, чем кажется. Учётная запись консоли, пароль которой сменили полгода назад и ни разу не проверяли, — это не путь восстановления; это документ, описывающий такой путь.

Что резервная копия не восстанавливает

Архив конфигурации — это запись файлов, а обновление меняет больше, чем файлы. Состояние пакетов, модули ядра, включённые ссылки юнитов и правила брандмауэра, применённые отдельным инструментом, живут вне каталога конфигурации, и восстановление, которое их игнорирует, даёт машину, которая выглядит настроенной и не пересылает трафик.

Авторизация заслуживает отдельной строки. Копия, снятая до удаления скомпрометированного устройства, с удовольствием вернёт доступ этому устройству. Возврат к ней во время сбоя — это способ превратить один инцидент в два, и решение о восстановлении должно приниматься о пирах так же явно, как о файлах.

Механизм отката тоже важен. Копирование старого исполняемого файла поверх управляемого пакетом не является поддерживаемым обращением изменения пакета и оставляет базу пакетов описывать состояние, которому файловая система не соответствует. Используйте собственный путь понижения версии менеджера пакетов или снимок, который предлагает провайдер. Понижение, которое фиксирует база пакетов, можно повторить.

Ничто из этого не говорит против резервных копий. Это говорит за то, чтобы знать, какой слой покрывает каждый артефакт, потому что режим отказа частичного восстановления запутаннее исходного сбоя. Запишите слой рядом с каждой копией в runbook.

Контрольная точка, обновление, затем проверка снаружи

Зафиксируйте состояние до изменения в форме, которую потом можно сравнить: установленные версии, задействованные юниты служб, слушающие сокеты и текущий список пиров. Четыре команды покрывают большую часть этого на хосте Linux.

systemctl list-units --type=service | grep -E 'openvpn|wg-quick'
ss -lunp | grep -E ':51820|:1194'
journalctl -u wg-quick@wg0 --since '-10 min'

Первая показывает, какие юниты существуют и работают ли они, вторая подтверждает, что слушатель действительно привязан, а третья даёт вам собственный отчёт службы о последних минутах. Ни одна из них не доказывает, что клиент может подключиться, поэтому следующий шаг делается вне хоста. Сохраните эти показания как базу для сравнения.

Проверьте из сети, которая не использует туннель: аутентифицируйте одного разрешённого клиента, разрешите имя и достигните одного нужного приложения. Локальная строка состояния о том, что интерфейс поднят, — это утверждение об интерфейсе, а не о маршрутизации, ключах или политике, допускающей пира.

Затем намеренно проверьте путь переподключения. Перезапустите службу один раз и убедитесь, что туннель возвращается без ручного вмешательства, потому что служба, которая правильно запускается только при загрузке, — это служба, которая удивит вас в худший момент.

Когда это не сработает, используйте проверенный путь

Последовательность восстановления не блещет и работает: доберитесь до хоста независимым путём, прочитайте собственные журналы службы и восстановите конкретную контрольную точку, соответствующую сбою. Меняйте по одной вещи за попытку, чтобы следующее чтение журнала что-то значило.

Сопротивляйтесь желанию сделать несколько незафиксированных изменений, чтобы вернуть связность. Машину, починенную пятью одновременными правками, потом невозможно объяснить, и следующее обновление вернёт ту из них, которая действительно держала нагрузку.

Затем решите постоянную политику с доказательствами. Если обновление выявило зависимость, которую никто не задокументировал, исправление — это документация и тест, а не отключение обновлений. Если оно выявило службу, которая не может чисто перезапуститься, исправление в юните, а не в расписании.

Сравнение разрешается чисто, как только условие названо. Независимый путь делает автоматические обновления управляемым риском. Его отсутствие делает ту же политику плановым сбоем с неизвестным временем восстановления, и никакое количество автоматизации не меняет эту арифметику.