Маршрути, які проштовхує OpenVPN, не встановлюються: час, права чи політика

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

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

Доведіть, що маршруту немає, а не просто що він зламаний

Почніть із доведення, що маршруту немає, а не що він зламаний. У Linux ip route show dev tun0 перелічує, що клієнт установив на тунельному пристрої. У Windows route print або Get-NetRoute показує те саме в табличному вигляді.

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

Час: додавання виконалося до появи пристрою

Клієнт розбирає PUSH_REPLY сервера після того, як керівний канал піднято і як він налаштував інтерфейс. Лише тоді він торкається таблиці маршрутизації, тим механізмом, який надає платформа. Linux проходить через netlink; Windows використовує API, що потребує підвищеного токена. Скрипт або клієнт, який додає маршрути щойно прочитавши конфігурацію, може виконатися до появи пристрою TUN/TAP, і ядро відхиляє додавання.

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

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

Права: хто може змінювати таблицю

Зміна таблиці маршрутизації Windows потребує підвищеного токена. Графічний інтерфейс, запущений звичайним користувачем, може задати адресу адаптера через службу і все одно не змогти додати маршрут. Тоді журнал показує помилку на кшталт відмови в доступі, а не відсутнє проштовхування.

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

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

Політика: проштовхнуті маршрути можна навмисно відкинути

route-nopull змушує клієнт ігнорувати маршрути, які проштовхує сервер, зокрема проштовхнутий маршрут за замовчуванням, при цьому адреса тунелю все ще приймається. Проштовхнуті параметри DNS і DHCP відкидаються тією самою директивою. Такий клієнт не є несправним; він очікує явних рядків маршрутів у власній конфігурації.

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

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

Порівняйте список проштовхування з таблицею

Після підключення покладіть список проштовхування сервера поруч із таблицею клієнта. У Linux це ip route show dev tun0; у Windows — route print або Get-NetRoute. Якщо маршруту немає, спершу виправте встановлення. Якщо він є, а трафік не проходить, переходьте до політики пересилання та міжмережевого екрана.

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