Автоматичні оновлення VPN-сервера потребують перевіреного шляху відновлення
Оновлення може перезапустити саме ту службу, через яку ви потрапляєте на сервер. Порівняйте зовнішню консоль із планом відновлення лише через тунель, перш ніж автоматизувати.
Автоматичні оновлення — розумна політика для сервера, до якого ви добираєтеся через його власний VPN, і водночас це єдина точка відмови, яку ви створюєте собі самі. Операція пакета перезапускає службу, тунель падає, і адміністративний шлях, яким ви користувалися, зникає разом із ним. Існують дві моделі відновлення, і вибір між ними залежить від однієї умови: чи маєте ви шлях входу, який не проходить через те, що оновлюється.
Дві моделі відновлення, одна вирішальна умова
Перша модель довіряє оновленню і припускає, що після нього ви зможете підключитися знову. Вона працює, коли VPN є одним із кількох способів дістатися до хоста і коли збій тунелю не позбавляє вас можливості його діагностувати. Друга модель заздалегідь розміщує незалежний шлях, зазвичай консоль хостинг-провайдера, і розглядає тунель як те, що обслуговування найімовірніше зламає. Обидві моделі можна захистити, і лише одна з них потребує роботи заздалегідь.
Вирішальну умову легко вимовити і легко пропустити. Якщо кожен адміністративний шлях до машини йде через службу, яка оновлюється, у вас немає жодної моделі відновлення, лише сподівання. Скажіть це вголос на розгляді зміни.
Перевірка цієї умови займає десять хвилин і має відбутися до першого автоматичного оновлення, а не під час інциденту. Відкрийте консоль, поки все працює, переконайтеся, що облікові дані чинні, і закрийте її знову. Переконайтеся, що консоль відкривається на тому хості, про який ви думаєте. Потім переконайтеся, що вхід, який ви справді використовували б о 3 годині ночі, досі працює.
Остання частина важливіша, ніж здається. Обліковий запис консолі, пароль якого змінили пів року тому і жодного разу не перевіряли, — це не шлях відновлення; це документ, що описує такий шлях.
Що резервна копія не відновлює
Архів конфігурації — це запис файлів, а оновлення змінює більше, ніж файли. Стан пакетів, модулі ядра, увімкнені посилання юнітів і правила брандмауера, застосовані окремим інструментом, живуть поза каталогом конфігурації, і відновлення, яке їх ігнорує, дає машину, що виглядає налаштованою і не пересилає трафік.
| What changed | Restored by a configuration backup | Needs its own action |
|---|---|---|
| Service unit or startup ordering | Partly, if the unit file was included | Package state and enabled links |
| Kernel module or interface support | No | Kernel or module rollback, or a boot-time decision |
| Peer or device authorization | Only if the backup predates the revocation | A deliberate decision about which peers return |
| Firewall rules applied outside the config | Only if they were captured | Replaying and verifying each rule |
Авторизація заслуговує на окремий рядок. Копія, знята до видалення скомпрометованого пристрою, радо поверне доступ цьому пристрою. Повернення до неї під час збою — це спосіб перетворити один інцидент на два, і рішення про відновлення має ухвалюватися щодо пірів так само явно, як щодо файлів.
Механізм відкату теж важливий. Копіювання старого виконуваного файлу поверх керованого пакетом не є підтримуваним скасуванням зміни пакета і залишає базу пакетів описувати стан, якому файлова система не відповідає. Використовуйте власний шлях зниження версії менеджера пакетів або знімок, який пропонує провайдер. Зниження, яке фіксує база пакетів, можна повторити.
Ніщо з цього не говорить проти резервних копій. Це говорить за те, щоб знати, який шар покриває кожен артефакт, бо режим відмови часткового відновлення заплутаніший за початковий збій. Запишіть шар поруч із кожною копією в runbook.
Контрольна точка, оновлення, потім перевірка ззовні
Зафіксуйте стан до зміни у формі, яку потім можна порівняти: встановлені версії, задіяні юніти служб, слухаючі сокети й поточний список пірів. Чотири команди покривають більшу частину цього на хості Linux.
systemctl list-units --type=service | grep -E 'openvpn|wg-quick'
ss -lunp | grep -E ':51820|:1194'
journalctl -u wg-quick@wg0 --since '-10 min'Перша показує, які юніти існують і чи працюють вони, друга підтверджує, що слухач справді прив’язаний, а третя дає вам власний звіт служби про останні хвилини. Жодна з них не доводить, що клієнт може підключитися, тому наступний крок відбувається поза хостом. Збережіть ці показання як базу для порівняння.
Перевірте з мережі, яка не використовує тунель: автентифікуйте одного дозволеного клієнта, розв’яжіть ім’я і досягніть одного потрібного застосунку. Локальний рядок стану про те, що інтерфейс піднято, — це твердження про інтерфейс, а не про маршрутизацію, ключі чи політику, що допускає піра.
Потім навмисно перевірте шлях перепідключення. Перезапустіть службу один раз і переконайтеся, що тунель повертається без ручного втручання, бо служба, яка правильно запускається лише під час завантаження, — це служба, яка здивує вас у найгірший момент.
Коли це не спрацює, використайте перевірений шлях
Послідовність відновлення не блищить і працює: дістаньтеся хоста незалежним шляхом, прочитайте власні журнали служби і відновіть конкретну контрольну точку, що відповідає збою. Змінюйте по одній речі за спробу, щоб наступне читання журналу щось означало.
Опирайтеся бажанню зробити кілька незафіксованих змін, щоб повернути зв’язність. Машину, полагоджену п’ятьма одночасними правками, потім неможливо пояснити, і наступне оновлення поверне ту з них, яка справді тримала навантаження.
Потім вирішіть постійну політику з доказами. Якщо оновлення виявило залежність, яку ніхто не задокументував, виправлення — це документація і тест, а не вимкнення оновлень. Якщо воно виявило службу, яка не може чисто перезапуститися, виправлення в юніті, а не в розкладі.
Порівняння розв’язується чисто, щойно умову названо. Незалежний шлях робить автоматичні оновлення керованим ризиком. Його відсутність робить ту саму політику плановим збоєм із невідомим часом відновлення, і жодна кількість автоматизації не змінює цю арифметику.