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 или экземпляра и идентичность клиента, с которым вы тестировали.

Эти три превращают следующий случай в пятиминутную проверку вместо нового расследования, и именно они нужны коллеге, когда туннель становится чужой проблемой.

Проблема с маршрутом, которая переживает перезапуск, часто вовсе не проблема маршрутизации; неисправность находится выше таблицы, которую вы постоянно читаете.