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 /

Потім перевірте об’єкти, а не процес: увійдіть, підтвердьте, що організації та користувачі присутні, і запустіть одного тестового клієнта проти визначення сервера, яке ви впізнаєте. Не дозволяйте відновленому хосту оголошувати виробничу кінцеву точку або приймати реальні з’єднання, доки адреси та ідентичності не стануть навмисними. Тут же ви виявите, що архіву потрібні облікові дані, які жили лише на зламаній машині, тому зберігайте облікові дані для відновлення в незалежному місці. Відновлення, яке залежить від хоста, який ви щойно втратили, — не план відновлення.

Нарешті, пам’ятайте, що старий знімок відновлює старі рішення. Якщо адміністратор вимкнув ідентичність після зняття дампу, відновлення знову вмикає її. Звіряння після відновлення належить процедурі, а не запізнілій думці.