Резервная копия VPN-сервера: определите, что должно восстанавливаться

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

Начните с цели пересборки

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

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

Идентичность — это то, что нельзя создать заново

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

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

Снимите состояние в один момент

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

wg showconf wg0 > /srv/backup/wg0.runtime.conf
sqlite3 /var/lib/vpn/admin.db ".backup '/srv/backup/admin.db'"
cp -a /etc/wireguard /srv/backup/etc-wireguard
sha256sum /srv/backup/*.conf > /srv/backup/MANIFEST

Первая команда печатает работающий интерфейс обратно как конфигурацию, и это самый быстрый способ зафиксировать пиров, добавленных вручную, а не инструментом управления; это руководство wg(8) документирует. Строка sqlite — образец для базы управления: команда резервного копирования создаёт согласованную копию, пока пишущий продолжает работать. Копия каталога сохраняет права, и это важно, потому что те ключевые файлы может читать только root. Манифест — это то, что позволяет отличить полный архив от усечённого.

Сделайте восстановление возможным, а затем проверьте его

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

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