Як перевірити, чи справді працює VPN-тунель у Linux

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

Прапорці з'єднання описують пристрій, а не шлях

Перевірка, яку всі копіюють, шукає апаратну адресу з самих нулів. Цей трюк у деяких драйверах відокремлює справжній інтерфейс від заглушки, а в решті нічого не доводить, бо tun-пристрій узагалі не має MAC, який можна повідомити. ip -brief link show tun0 натомість показує прапорці: UP означає, що адміністратор увімкнув пристрій, а LOWER_UP означає, що драйвер вважає з'єднання придатним. Прочитані разом, вони кажуть, що пристрій існує і не вимкнений адміністративно. Жоден із них не каже, що пакету є куди йти.

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

Запитайте, куди піде пакет

Пошук маршруту відповідає на питання, на яке прапорці не здатні. ip route get 10.8.0.1 from 10.8.0.2 називає інтерфейс, адресу джерела й таблицю, яку використовувало б ядро, і саме з цим треба звіряти розділений тунель. Без адреси джерела ви запитуєте про інше, а за маршрутизації за політиками відповідь може відрізнятися залежно від джерела. Це найдешевший чесний тест, бо він звертається до тих самих правил, які використовуватиме ваш трафік.

Для WireGuard додайте рукостискання. wg show друкує позначку часу останнього рукостискання для кожного піра, а позначка, що перестала просуватися, означає, що пір зник, хоч би що казали прапорці інтерфейсу. Налаштований інтерфейс без недавнього рукостискання — одна з найчастіших хибних тривог у саморобному моніторингу.

Таблиця 220 розповідає історію IPsec

strongSwan встановлює маршрути для узгоджених селекторів у таблицю 220, коли встановлення маршрутів увімкнене. ip route list table 220 тому відокремлює узгоджене від маршрутизованого: порожня таблиця поруч із завантаженим з'єднанням означає, що SA IKE і CHILD піднялися, але жоден трафік до них не спрямовується. Перевірте ip xfrm state поруч, бо вона перелічує встановлені асоціації безпеки та їхні кінцеві точки.

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

Стан менеджера і стан демона — це різні списки

NetworkManager перелічує лише свої з'єднання. nmcli -t -f NAME,TYPE connection show --active нічого не повертає для тунелю, запущеного безпосередньо через wg-quick або демоном OpenVPN.

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

Прив'яжіть наступний крок до потрібної йому перевірки

Опитування UDP-порту нічого не доводить про готовність, бо в UDP немає рукостискання і nc -u вдається, щойно пакет виходить. Перевіряйте те, що наступний крок справді споживає: TCP-з'єднання до переспрямованого порту, запит до хоста всередині тунелю, ім'я, що розв'язується лише там. Обмежте очікування тайм-аутом і кількістю спроб і гучно падайте, коли вони вичерпаються.

Гачки кращі за опитування, якщо клієнт їх пропонує. --up і --down скрипти OpenVPN запускаються після зміни стану інтерфейсу, що повністю усуває гонку, але вони працюють із привілеями, які демон зберіг. Якщо OpenVPN опустився до непривілейованого облікового запису через user і group, гачок працює як цей запис. Тоді перезапуск системної служби потребує sudo, що дозволяє саме цю команду. Доручіть повторення менеджеру служб, а не циклу cron: обмежена політика перезапуску з лімітом запусків виявляє зламаний тунель, тоді як безмежний цикл ховає його нескінченно.