Пропавший маршрут 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 и словарь данных, специфичный для плагина, и именно оттуда нужно начинать, прежде чем предполагать, что ключ существует.

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