Перевірка відновлення VPN-сервера після перезавантаження: що перевірити першим

Перезавантажте сервер, поки ніхто не увійшов, потім підключіться з мережі, яку ви не контролюєте. Цей єдиний тест відповідає, чи справжнє відновлення, бо тунель, який працює лише після того, як хтось вручну виконає команду, — це не відновлення, а ремонт. Більшість перевірок зупиняються зарано: служба виглядає активною, інтерфейс піднімається, а сторінка все одно не завантажується. Розрив майже завжди в стійкості частин навколо тунелю, а не в самій команді тунелю.

Чотири власники, чотири різні тести

Перед перезавантаженням назвіть те, що має повернути тунель. Тест, який ви запускаєте, і виправлення, яке застосовуєте, обидва залежать від цієї відповіді, і є чотири звичайні власники: unit systemd для служби VPN, unit екземпляра wg-quick для інтерфейсу WireGuard, runtime контейнерів або профіль менеджера мережі. Якщо ви не можете назвати власника, зупиніться і знайдіть його, бо тест перезавантаження без очікуваного шляху запуску лише каже, що щось сталося.

Кожен власник тримає свою конфігурацію в іншому місці. Сервер OpenVPN під керуванням systemd читає конфігурацію під час запуску, тому виконується те, що є у файлі на момент завантаження. Інтерфейс wg-quick бере адреси, маршрути й DNS з того самого файлу, а отже, інтерфейс, піднятий вручну з оболонки і так і не ввімкнений як unit, не повернеться. Контейнер повертає свою точку входу, але не зміни firewall хоста, якщо ті не живуть поза контейнером.

Спочатку базовий стан, інакше результат нічого не значить

Зафіксуйте робочий стан, поки він працює: адреси на тунелі, маршрути для клієнтської підмережі, правила NAT або пересилання, слухаючий сокет і sysctl пересилання. ip addr show wg0, ip route, nft list ruleset або iptables-save, ss -lunp і sysctl net.ipv4.ip_forward достатні на більшості хостів.

Запишіть, як служба налаштована на запуск, а не лише те, що вона працює. systemctl is-enabled wg-quick@wg0 і systemctl is-active wg-quick@wg0 відповідають на різні питання, і під час завантаження важливий саме ввімкнений стан, як описано в systemctl(1). Для OpenVPN перевірте, який шаблон використовує хост, оскільки openvpn@server і openvpn-server@server — різні unit із різними типовими значеннями.

Виконайте перезавантаження і прочитайте першу невдачу

Перезавантажте навмисно, у вибране вами вікно, з відкритою консоллю або позасмуговим шляхом. Спостерігайте за порядком подій, а не за кінцевим станом: хост доступний, unit активовано, інтерфейс присутній, маршрути встановлено, правила firewall присутні, слухач прив'язано, клієнта прийнято. Перший крок, який не відбувся, і є знахідка; усе після нього — шум.

Служба може бути активною, поки тунель непридатний, і це найчастіший хибний успіх. Запуск може завершитися до того, як мережа буде онлайн, якщо unit чекає лише на network.target замість network-online.target. Файли, на які є посилання, як-от сертифікати, ключі або CRL, можуть бути нечитабельними в цей момент, бо монтування або шлях до секретів ще не готовий. Жодна з двох проблем не видна в systemctl status, доки ви не прочитаєте журнал unit.

Тестуйте ззовні хоста. Клієнт у тій самій LAN може досягти успіху маршрутом, який жоден віддалений клієнт ніколи не використав би, а SSH-сесія до машини нічого не доводить про тунель. Підключіться, розв'яжіть внутрішнє ім'я, дістаньтеся приватного ресурсу, потім підключіться ще раз, щоб підтвердити, що стан відкликання та ключі все ще діють.

Три умови, які визначають ваше виправлення

Якщо тунель повертається, але клієнти нічого не досягають, збій у маршрутизації або стійкості NAT. Якщо клієнти навіть не можуть завершити рукостискання, збій в інтерфейсі або матеріалі автентифікації. Якщо служба ніколи не запускається, збій у файлі unit або його залежностях. Ці три гілки ведуть до різних виправлень, тому сліпе перезавантаження без базового стану коштує більше часу, ніж економить.

Вносьте виправлення там, де налаштування є власністю. Помістіть пересилання в sysctl drop-in, помістіть правила NAT у набір правил, що завантажується під час завантаження, увімкніть unit замість його запуску і тримайте секрети на шляху, який існує до запуску unit. Додавання паузи до unit приховує залежність замість того, щоб її оголосити.

Запишіть результат у runbook

Запишіть, що повернулося само, що вам довелося запустити і скільки тривав розрив. Включіть точні команди, якими ви перевіряли, щоб наступна людина повторила тест, а не вигадувала новий. Якщо якийсь крок вимагав ручної команди, ця команда належить конфігурації, а не runbook як постійний крок.

Потім заплануйте наступний тест після наступної зміни мережевого стеку хоста, а не на календарну дату через шість місяців. Режим збою, від якого ви захищаєтеся, — це тимчасова команда, яка здавалася постійною, і вони з'являються саме тоді, коли хтось редагує правила firewall або переносить службу в новий unit.