Pritunl: состояние управления против сгенерированного профиля

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

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

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

Копия конфигурации хоста столь же частична. /etc/pritunl.conf содержит настройки уровня хоста, включая способ добраться до базы данных, и не содержит сами объекты VPN.

Чем владеет база данных и чем владеет хост

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

Хост вносит меньший, но непереносимый набор значений. Одно из них — /var/lib/pritunl/pritunl.uuid, идентичность этого конкретного узла.

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

Сделайте согласованный дамп, а не копию каталога

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

mongodump --uri="mongodb://127.0.0.1:27017/pritunl" --out=/var/backups/pritunl/db
sudo tar czf /var/backups/pritunl/host.tgz /etc/pritunl.conf /var/lib/pritunl/pritunl.uuid

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

Потренируйтесь восстанавливать, пока это не понадобилось

Резервная копия, которую никто не восстанавливал, — это гипотеза. Постройте службу в изолированной сети, восстановите дамп и верните файлы хоста на место:

mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /

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

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