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

Снаружи они выглядят одинаково и требуют разных исправлений. Читайте журнал клиента в том месте, где принимается решение о маршруте.

Докажите, что маршрута нет, а не просто что он сломан

Начните с доказательства того, что маршрута нет, а не что он сломан. В 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. Если маршрута нет, сначала исправьте установку. Если он есть, а трафик не идёт, переходите к политике пересылки и межсетевого экрана.

Запишите версию клиента, учётную запись, под которой он работает, и то, основан ли он на службе. Эти три факта скажут следующему человеку, какие причины исключены.

Похожие статьи