OpenVPN досі штовхає старі маршрути? Перевірте, що він завантажив

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

Порівняння нижче йде від процесу назовні, бо лише процес знає, який файл чинний.

Файл, який ви відредагували, і файл, який читає процес

Почніть з unit і командного рядка, який він породив. На хості з systemd systemctl cat openvpn@server друкує рядок ExecStart, а unit екземпляра зазвичай виводить шлях до конфігурації з імені екземпляра, тож демон, запущений як openvpn@office, читає не той файл, що запущений як openvpn@server. Порівняйте це з argv робочого процесу. Інструмент керування конфігурацією додає ще один спосіб втратити зміну: він може записати правильний файл у місце, яке unit ніколи не згадує, і тоді успішне розгортання виглядає як бездіяльність.

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

Що надсилає сервер і що встановлює клієнт

Надісланий маршрут має пройти два фільтри. На сервері він має бути в завантаженій конфігурації, а не в закоментованому блоці чи у файлі, прив'язаному до клієнта, ім'я якого не збігається. На клієнті pull має бути ввімкнений, і жоден pull-filter не повинен відкидати цю опцію. Підключіться з verbosity 4 і прочитайте надіслані опції, про які повідомляє клієнт: якщо маршрут є в цьому списку, сервер зробив свою справу, і встановлювати його не хоче сам клієнт.

Файли, прив'язані до клієнта, — часте джерело плутанини. Файл, названий за common name сертифіката, надсилає опції лише цьому клієнту, і розбіжність в одному символі мовчки зупиняє надсилання, без помилки з обох боків. Сервер записує в журнал common name, який побачив під час підключення, тому порівняйте це значення з іменем файлу, а не з тим, як, на вашу думку, зветься клієнт.

Надісланий префікс і зворотний маршрут — різні проблеми

Клієнт, який свідомо ігнорує redirect-gateway, щоб зберегти свій локальний шлях в інтернет, створює другу, не пов'язану прогалину. Зонди сервера доходять до адреси тунелю, а відповіді так і не приходять, бо відповідь, адресована IP тунелю сервера, маршрутизується через звичайний шлюз за замовчуванням клієнта. Тут винен не надісланий маршрут підмережі; бракує маршруту, який повертає трафік до мережі тунелю сервера назад через тунельний пристрій.

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

Порівняйте таблиці на обох кінцях

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

Тримайте разом три ідентифікатори: шлях до конфігурації, ім'я unit або екземпляра та ідентичність клієнта, з яким ви тестували.

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

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