Какой компонент на самом деле владеет лимитом маршрутов OpenVPN?
Лимит маршрутов может принадлежать движку OpenVPN, плагину NetworkManager или серверу. Назовите владельца, прежде чем править профиль или поднимать число.
Профиль с двумястами маршрутов работает на одной машине и устанавливает сорок на другой. Движок, интеграция, которая его запускает, и сервер, который его питает, имеют свой голос, и каждый может остановить список в разных точках. Прочтение сбоя как одного лимита уводит вас к не тому файлу. Механизм имеет три этапа, и остановившийся этап оставляет видимые следы, когда вы знаете, что искать.
Три этапа, три разных лимита
Сначала движок разбирает параметр и решает, понимает ли его эта версия. Затем интеграция устанавливает то, что сообщает движок, и её собственный код может ограничить или преобразовать список. Наконец сервер решает, сколько маршрутов он отдаст данному субъекту, прежде чем какой-либо клиентский этап что-то увидит. Три этапа, три потолка, и лишь один из них — число в профиле.
Подъём одного потолка ничего не даёт остальным. Отклонённый отправленный маршрут может быть решением политики на сервере, пересечением, которое разрешил клиент, или лимитом установщика, отбросившим излишек. Каждый из этих случаев лечится по-своему.
Разделите эти три до любых измерений. Ошибка разборщика называет токен, лимит установщика оставляет короткую таблицу маршрутов, а решение политики не оставляет вообще ничего. Следы подскажут, какой этап проверять первым.
| Stage | Who decides | What you can see |
|---|---|---|
| Parse | Client engine | An error naming the option |
| Install | Activation owner | A route count below the pushed count |
| Offer | Server policy | A route absent from the pushed list |
Разборщик говорит первым
Неизвестный параметр падает громко и рано, а текст ошибки называет токен. Это самый простой для распознавания этап: сравните точное сообщение с установленной версией движка, ведь параметр, добавленный в одном выпуске, неизвестен в предыдущем. Профиль, скопированный из более нового развёртывания, — обычный источник этого расхождения. Разборщик никогда не игнорирует молча директиву, которую не узнаёт.
Принятый параметр ничего не говорит о результате. Разбор проходит, а список всё равно может быть урезан установщиком или вовсе не предложен сервером. Считайте чистый разбор разрешением продолжать, а не доказательством.
Запишите строку версии из бинарника, который действительно работал, а не из представления менеджера пакетов о том, что установлено. Эти двое расходятся чаще, чем ожидается.
У установщика свой потолок
Компонент, владеющий активацией, может быть плагином NetworkManager, а не бинарником движка, и он может навязать свой собственный лимит ещё до появления любого туннеля. Его редактор может показывать поле, которое работающий движок никогда не читает, или читать поле, которое редактор не показывает. Обе ситуации снаружи выглядят как ошибка клиента. Ни одну не исправляет правка профиля.
Считайте то, что пришло, а не то, что было настроено. Команда ip route show dev tun0 перечисляет установленные маршруты, и сравнение этого числа с отправленным списком отделяет отброшенный маршрут от того, который никогда не отправлялся. Число, совпадающее с отправкой, возвращает подозрение серверу.
Обёртка-скрипт вокруг бинарника движка, чтобы выжать большее число, затуманивает обновления и превращает откат в догадку. Она также скрывает настоящий лимит от каждого, кто прочтёт конфигурацию следующим.
Сервер решает, что вам предложили
Политика для каждого клиента может уменьшить список до передачи. Файл, специфичный для клиента, может добавить маршруты для одного субъекта, или групповая политика может их опустить, и клиент не может отличить отфильтрованный маршрут от того, который никогда не определялся. Именно эта неоднозначность и делает запись сервера важной. Запрашивайте фактический список отправки для этого субъекта, а не шаблон.
Сравните запись сервера с полученным списком. Разрыв между ними — это слой политики, и обычно он меньше, чем подсказывает профиль.
Когда проект это позволяет, объединяйте смежные сети и удаляйте устаревшие записи. Меньше и крупнее маршрутов решают больше случаев, чем более высокий потолок.
Измените число в правильном месте
Используйте документированную настройку компонента, который действительно владеет лимитом. Если поля нет в плагине, проверьте, не старше ли плагин этой возможности или не владеет ли маршрутами другая основа. Затем запишите версии движка, плагина и сервера рядом с выбранным значением. Следующее обновление снова открывает вопрос, и именно заметка делает его решаемым.
Перепроверяйте после любого обновления любого из трёх. Лимит, поднятый в правильном месте, всё равно сдвигается, когда меняется компонент, который его применяет. Запись версий — единственное, что делает этот сдвиг предсказуемым.