Метрика маршрута OpenVPN: почему выбранный маршрут всё равно проигрывает

Вы добавили метрику к маршруту в профиле, переподключились, а трафик всё равно уходит через не тот интерфейс. Число здесь редко бывает причиной. Метрика лишь упорядочивает кандидатов, которые операционная система и так сравнивает, а более конкретный префикс или более ранняя таблица политик решает ещё до того, как метрика будет прочитана.

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

Читайте строку маршрута в порядке полей

Клиент Community OpenVPN 2.6 принимает четыре поля в строке route для IPv4: сеть, маску, шлюз и необязательную метрику. На месте шлюза ставится специальное ключевое слово vpn_gateway. Оно означает следующий узел со стороны VPN для этого подключения, а не номер таблицы маршрутизации и не ваш физический роутер. Если это упустить, остаток строки читается с неверным представлением о том, что она делает. Справочник по сетевым опциям описывает все четыре поля.

Для частного назначения строка может выглядеть так:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

Явное 30 применяется к этому маршруту, а 50 остаётся значением по умолчанию для всех остальных маршрутов профиля, где число не указано. Чтения строки слева направо достаточно, чтобы понять, какое значение где действует.

route-metric — это значение по умолчанию, а не ранг

route-metric задаёт запасное значение для маршрутов, у которых нет собственного числа. Она не поднимает маршрут выше других и не переупорядочивает маршруты, установленные с явными метриками.

Эта разница важна, когда профиль смешивает обе формы. Одна строка route-metric в начале выглядит авторитетно и легко обвинить её, тогда как маршрут, который реально несёт трафик, может иметь свою метрику тремя строками ниже.

Если вы хотите, чтобы один маршрут предпочитал определённый путь, поставьте число на этот маршрут. Если вам нужно единое значение по умолчанию для сгенерированного профиля, используйте route-metric и не трогайте отдельные строки. Смешивать одно и другое без причины — так у профиля и появляется маршрут, который никто не может объяснить.

Посмотрите, что установил клиент

После завершения переподключения спрашивайте ядро, а не профиль.

ip route show перечисляет маршруты, добавленные клиентом, а ip route get 172.20.5.10 отвечает на более полезный вопрос: какой маршрут это назначение реально использует и с какого адреса-источника. Если назначения нет в таблице, значит клиент его не установил.

Локальная директива, push от сервера или другой менеджер сети может добавить или удалить тот же префикс, и побеждает тот, кто записал последним. Держите маршрут до конечной точки в поле зрения, пока работаете, потому что соединению нужен путь к удалённому серверу, не проходящий через туннель, который оно строит.

Почему меньшая метрика всё равно проигрывает

Метрики сравнивают маршруты до одного и того же назначения. Они не делают широкий префикс более конкретным. Когда задействован redirect-gateway def1, клиент устанавливает 0.0.0.0/1 и 128.0.0.0/1, и эти два префикса покрывают всё пространство IPv4 более конкретно, чем 0.0.0.0/0. Метрика 1 на маршруте по умолчанию их не обходит.

Та же логика применима к любой перекрывающейся паре. /24 выигрывает у /16 для адреса внутри него независимо от прикреплённых чисел, потому что поиск сначала выбирает самое конкретное совпадение и только потом сравнивает метрики между равными.

Именно эта часть выглядит как ошибка метрики, но ею не является. Проверьте длину префикса у обоих кандидатов, прежде чем менять какое-либо число.

Правила политик выполняются раньше таблицы

В Linux ip rule решает, какая таблица маршрутизации будет использована. Правила вычисляются в порядке приоритета, поэтому более ранняя таблица может вернуть маршрут прежде, чем основная таблица будет прочитана. Метрика внутри main не может обойти совпадение в таблице, которую запросили первой.

Используйте ip rule show, а затем запросите конкретную таблицу, например ip route show table 100, чтобы увидеть, что вернуло бы это правило. Если правило добавил VPN-клиент или среда выполнения контейнеров, ответ может быть там, а не в таблице, которую вы читали. Адрес-источник тоже важен: правило может совпадать по источнику и разрешать одно и то же назначение по-разному для трафика туннеля и трафика локальной сети.

Проверяйте назначение, а не рейтинг

Тест, который заканчивает спор, — это один запрос к узлу внутри нужной подсети плюс проверка адреса-источника, который выбрало ядро. Если эта пара совпадает с замыслом, метрика делает свою работу, даже когда список не выглядит как аккуратный рейтинг.

Оставьте IPv6 и DNS вне этой проверки. Они настраиваются другими директивами и разрешаются другими механизмами, а работающий маршрут IPv4 не говорит ни о том, ни о другом. Меняйте по одному слою за раз и повторяйте запрос.