Зниклий маршрут VPN у NetworkManager: політика профілю чи скрипт?

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

Визначте, який власник відповідальний, перш ніж щось писати.

Три власники, один зниклий префікс

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

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

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

Прочитайте профіль, перш ніж щось додавати

Почніть із властивостей збереженого з'єднання. Читайте їх, не вивалюючи секрети, і використовуйте UUID, якщо назва профілю неоднозначна.

nmcli -f vpn.service-type,ipv4.never-default,ipv4.ignore-auto-routes,ipv4.route-table,ipv4.routes connection show office

vpn.service-type повідомляє, який бекенд володіє з'єднанням, і це важливо, бо дані плагіна специфічні для бекенду. Ключ, який приймає один плагін, не є підтримуваною інструкцією для іншого, тому фрагмент, скопійований із документації іншого клієнта, нічого не доводить.

ipv4.ignore-auto-routes і ipv4.never-default відповідають на різні питання. Перший може відхиляти маршрути, які з'єднання інакше взяло б автоматично, а другий керує тим, чи може профіль стати маршрутом за замовчуванням. Профіль, який ігнорує автоматичні маршрути і не покладається ні на що інше, підключиться чисто і майже нічого не встановить.

ip -4 rule show
ip -4 route show table all

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

Чого скрипт виправити не може

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

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

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

Рішення, по порядку

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

Лише коли перша відповідь «так», друга «так», а третя правильна, допоміжний скрипт стає виправданим, і навіть тоді варто спитати, чи підтримує бекенд маршрут нативно. Довідник налаштувань VPN документує service-type і словник даних, специфічний для плагіна, і саме звідти треба починати, перш ніж припускати, що ключ існує.

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