Стежте за VPN на маршрутизаторі, не довіряючи одному індикатору стану

Сторінка стану каже «підключено», індикатор зелений, а офіс не може дістатися до файлового сервера. Один із цих фактів — про тунель, інший — про шлях через нього. Спостерігати за обома — це різниця між оповіщенням, за яким можна діяти, і тим, яке ви навчилися ігнорувати.

П'ять перевірок, по порядку, від партнера назовні.

Перевірка 1: стан партнера або асоціації

Кожен протокол показує власний стан. WireGuard показує останнє рукостискання й лічильники передавання для кожного партнера через wg show. OpenVPN записує стан сеансу у свій файл стану або інтерфейс керування, а IPsec показує асоціації безпеки за допомогою інструментів на кшталт ipsec statusall. Пастка — читати мітку часу як вирок: простоюючий партнер WireGuard, якому нічого надіслати, не виконає рукостискання недавно, і це не збій.

Порівняйте мітку часу з очікуваним трафіком і налаштуваннями keepalive, перш ніж когось викликати.

Перевірка 2: вибраний маршрут

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

Ця перевірка ловить збій, якого індикатор стану ніколи не показує.

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

Перевірка 3: дозволений шлях застосунку

Перевірте щось репрезентативне для фактичної вимоги. Ping від маршрутизатора виходить з його власної адреси й політики, які можуть відрізнятися від пересиланого трафіку LAN, а багато хостів обмежують ICMP. Якщо вимога — приватна служба, перевіряйте цю службу на її реальному порту.

Тримайте обсяг перевірки скромним. Спостережний цикл не повинен ставати трафіком, який він вимірює.

Перевірка 4: що змінилося і коли

Пов'яжіть зміни WAN, оновлення ключів, відкликання маршрутів і збої застосунків на одній шкалі часу. Відрізняйте збій тунелю від резервного маршруту, який тихо відновлює звичайний доступ до інтернету, бо обидва дають однакові скарги користувачів і протилежні діагнози. Помилки часового поясу перевернуть порядок, тому нормалізуйте перед порівнянням. Саме шкала часу перетворює чотири перевірки на причину.

Зберігайте журнали для переходів, а не для корисного навантаження.

Перевірка 5: оповіщення має назвати межу

Оповіщення «VPN впав» у половині випадків відправляє людину не туди. Оповіщення «рукостискання партнера застаріло на дванадцять хвилин», «маршрут до 10.20.0.0/16 відсутній» або «перевірка порту 445 не вдається» вказує на конкретну перевірку.

Ведіть операційні лічильники, а не переглядайте корисні навантаження. Лічильники відповідають на питання спостереження, не збираючи вміст, який вам не потрібен.

І нехай політика перемикання вирішує, що буде далі. Спостереження має визначити, яка межа відмовила, а не дозволяти широкий обхід щоразу, коли перевірка не вдається. Посібник OpenVPN 2.6 описує файл стану та інтерфейс керування, які роблять першу перевірку скриптованою.