Резервна копія 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 і зовнішній каталог можуть кожен потребувати свого кроку відновлення. Успішне копіювання файлів не доводить, що служба повернеться; єдиний доказ, який рахується, — перебудована кінцева точка, що проходить той самий приймальний тест, що й оригінал.