Где должен находиться маршрут в OpenVPN: у клиента или у сервера?
Голый маршрут в конфигурации сервера меняет сервер, а не клиента. Выберите клиентский файл, глобальный push или push для одного клиента и проверьте, что дошло.
Вы добавляете route 10.60.0.0 255.255.255.0 в конфигурацию сервера, перезапускаете, снова подключаете ноутбук, а подсеть по-прежнему недоступна с этого ноутбука. Строка была принята, служба запустилась чисто, и в журнале ничего не выглядит неправильно. Произошло то, что маршрут был установлен на машине, которую вы редактировали: шлюз теперь считает, что может достичь этого префикса, а клиенту ничего не сообщили. Всё дело в размещении, и есть четыре места, где одна и та же строка может жить.
Четыре места и кто получает каждое
Маршрут можно добавить собственной конфигурацией клиента, предложить каждому клиенту через глобальный push, предложить одному клиенту через файл для конкретного клиента или записать в собственный контекст маршрутизации сервера.
Эти четыре случая используют почти идентичный синтаксис и дают совершенно разные результаты. Первые три влияют на то, что клиент отправляет в туннель; четвёртый влияет на то, как сервер достигает сети, что полезно, когда самому серверу нужен путь, и вредно, когда его путают с раздачей.
Решите, какой из четырёх вам нужен, прежде чем писать строку, затем подтвердите получателя.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
Почему голый серверный маршрут удивляет людей
Конфигурация сервера — первое место, куда смотрят администраторы, и директива маршрута там читается как утверждение о сети VPN. Это не так. OpenVPN рассматривает её как локальную установку маршрута на машине, где работает демон, — ровно такое же изменение, которое вы сделали бы с помощью ip route и потом забыли.
Раздача требует, чтобы маршрут был отправлен через push, а push требует, чтобы клиент его забрал. Клиент, запущенный с отключёнными полученными опциями, полностью игнорирует предложение. Проверьте оба конца этого рукопожатия, прежде чем переписывать серверный файл, потому что журнал сервера не пожалуется: с его стороны предложение было отправлено. Принятый маршрут также вступает в силу только при следующем подключении и никогда в сеансе, в котором вы уже находитесь.
Как только вы увидите две операции как отдельные, сбой перестаёт быть загадочным: сервер достигает префикса, клиент нет, и оба утверждения верны одновременно.
Файлы для отдельных клиентов и идентичность, которой они соответствуют
Файл для конкретного клиента называется по идентичности, которую сервер аутентифицировал, а по умолчанию это общее имя сертификата. Дружественное имя подключения в настольном клиенте не является этим значением, и несовпадение создаёт файл, который никогда не читается.
Проверьте каталог, который сервер действительно использует, затем подтвердите, что имя файла точно соответствует аутентифицированной идентичности, включая регистр букв.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Внутри этого файла маршрут всё равно нужно отправить через push, потому что контекст для отдельного клиента — это набор опций, применяемых к сеансу этого клиента, а не локальная таблица маршрутизации. Голый маршрут там имеет ту же проблему, что и голый маршрут в глобальном файле.
Собственный файл клиента и инструмент, который им владеет
Маршрут, помещённый в конфигурацию клиента, устанавливается при подключении этого клиента и удаляется при отключении, что является правильным жизненным циклом для статического назначения.
Если профилем владеет сетевой менеджер, он может один раз импортировать эти опции, а затем хранить собственную копию. Правка загруженного файла позже ничего не меняет, и это частая причина фразы "маршрут есть, но не применяется".
Проверьте активный профиль, а не файл, который вы скачали, и проверьте импортированные настройки, которые показывает менеджер. Затем подключитесь и спросите систему, какой путь использует конкретный адрес, вместо того чтобы предполагать, что туннель победил, потому что маршрут был в текстовом файле.
Проверьте на клиенте, затем проверьте обратный путь
Спросите собственную таблицу маршрутизации клиента о назначении, а не таблицу сервера. Поиска одного хоста внутри префикса достаточно, чтобы показать интерфейс и следующий переход, которые будут использованы.
ip route get 10.60.0.10Если поиск указывает на туннель, раздача сработала, и оставшаяся проблема в другом месте. Если он указывает на шлюз по умолчанию, маршрут не был установлен, был отфильтрован опцией на стороне клиента или принадлежит профилю, который клиент не использует.
Предположите, что раздача сработала, а ничего не отвечает: тогда проверьте пересылку на шлюзе, обратный маршрут противоположной стороны и любой межсетевой экран между ними. Маршрут выбирает путь, он не даёт доступ.