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

Сделайте контрольную точку, которую действительно сможете восстановить

Запишите конфигурацию, которую служба читает при запуске, вместе с версией, которая последней её разобрала. Файл, чисто загружавшийся в прежнем выпуске, после обновления может быть отклонён или молча проигнорирован, поэтому версия относится к той же заметке. Включите материал, на который ссылается конфигурация: закрытые ключи, пути к сертификатам, определения слушателей и записи DNS и межсетевого экрана, которые делают службу доступной. Если для восстановления понадобится файл, который вы не сохранили, контрольная точка неполна.

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

Держите отзывы отдельно от конфигурации

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

Относитесь к состоянию идентичности как к отдельному откату с собственными доказательствами. Файлы отзыва сертификатов, отключение учётных записей и регистрация MFA редко находятся там же, где конфигурация демона, и восстановление конфигурации их не затронет. Сначала проверьте текущее состояние, чтобы знать, что должно выжить. После восстановления убедитесь, что удалённая идентичность по-прежнему не может подключиться.

Доберитесь до хоста, когда туннель отказывает

Откройте путь к машине, не зависящий от изменяемого компонента. Консоль гипервизора, адрес управления на отдельном интерфейсе или последовательная консоль подходят все; сеанс SSH, переносимый через туннель, — нет. Если единственный вход — это VPN, который вы собираетесь перезапустить, неверный маршрут или правило межсетевого экрана лишает вас возможности это исправить. Проверьте альтернативный путь до изменения, а не после. Войдите через него один раз, убедитесь, что sudo работает, и запишите точный адрес, который использовали.

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

Примените одну ревизию и знайте, когда она вступает в силу

Используйте документацию службы по reload или restart и выясните, какие директивы читаются в какой момент. Некоторые значения применяются при reload, другие только когда начинается новый сеанс или процесс, поэтому редактирование файла ничего не доказывает о работающем состоянии. Восстановите одну ревизию вместо смешивания нового файла со старым состоянием выполнения. При сомнении полный перезапуск службы проще обосновать, чем частичный reload.

Проверьте определение юнита перед выбором: systemctl show -p ExecReload openvpn@server сообщает, существует ли вообще хук reload. Затем примените ревизию и прочитайте в журнале первые новые ошибки, прежде чем менять что-либо ещё.

Проверьте, запишите и исследуйте после

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

systemctl status openvpn@server --no-pager
journalctl -u openvpn@server -n 50 --no-pager

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

Похожие статьи