Метрика маршрута VPN изменилась после подключения: что это значит
Меньшая метрика лишь разрешает ничью между одинаково конкретными маршрутами. Прочитайте правило политики, префикс и host-маршрут конечной точки, прежде чем менять любой номер маршрута VPN.
Вы подключаете VPN, запускаете route print, и маршрут по умолчанию теперь несёт гораздо меньшую метрику, чем раньше. Естественный вывод — VPN занял маршрут по умолчанию, потому что его номер меньше. Иногда так и произошло. Часто метрика вовсе не решающий фактор, и её правка ничего не меняет, потому что выбор был сделан раньше — длиной префикса или правилом политики.
Симптом реален: трафик, который раньше уходил через адаптер Wi-Fi, теперь уходит через туннель, или наоборот. Метрика — один вход в поиск, который выполняется в фиксированном порядке, и именно этот порядок нужно прочитать, прежде чем трогать число.
С чем на самом деле соревнуется число
Первое сравнение — конкретность, а не предпочтение. Маршрут для 10.20.0.0/16 побеждает 10.0.0.0/8, и оба побеждают 0.0.0.0/0, что бы ни говорили их метрики. VPN, который устанавливает маршрут по умолчанию с самой низкой метрикой на машине, всё равно проигрывает любому более конкретному маршруту, совпадающему с назначением, включая host-маршрут, который клиент ставит для своего сервера.
Поэтому снижение метрики маршрута по умолчанию не может загнать непосредственно подключённую подсеть в туннель. Если вы хотите эту подсеть внутри VPN, добавьте маршрут для префикса или выберите таблицу туннеля правилом политики. Метрика — не тот рычаг для этой задачи.
| Check in this order | Question | Where you read it |
|---|---|---|
| 1. Policy and table | Which routing table does this traffic use? | ip rule, client profile |
| 2. Prefix length | Which matching route is most specific? | route print, ip route |
| 3. Metric | Which of the equally specific routes is preferred? | route print, ip route |
| 4. Interface state | Is the chosen next hop reachable? | adapter status, link state |
Linux выбирает таблицу раньше метрики
В Linux ядро сначала обращается к базе политик. ip rule перечисляет правила и таблицы, которые они выбирают, а ip route get 203.0.113.10 сообщает таблицу, маршрут и адрес источника, которые ядро реально использовало бы для этого назначения. Метрика внутри таблицы 100 никогда не соревнуется с маршрутом в главной таблице, потому что правило выбрало таблицу раньше, чем сравнивалась хоть одна метрика.
Поэтому маршрут может выглядеть правильным в ip route show table all и всё равно не нести трафик. Прочитайте правило, которое совпало, затем таблицу, которую оно выбрало, затем сравните маршруты внутри неё. Если выбрана не та таблица, никакая правка метрики в другой таблице не поможет.
Windows объединяет две метрики
В Windows нет базы политик по умолчанию, но он объединяет метрику маршрута с метрикой интерфейса, а автоматическая метрика интерфейса может меняться со скоростью канала и состоянием адаптера. Поэтому один и тот же маршрут может вести себя иначе после появления док-станции или виртуального адаптера. Find-NetRoute -RemoteIPAddress 203.0.113.10 сообщает выбранный адрес источника, следующий переход и интерфейс, что ближе к реальному решению, чем сырая таблица.
Читайте значения маршрута и интерфейса вместе. Повышение метрики интерфейса может сдвинуть трафик без изменения ни одной записи маршрута, а клиент VPN, владеющий своими маршрутами, переустановит их при переподключении и отбросит вашу правку.
Держите конечную точку туннеля вне туннеля
Каждому туннелю нужен путь к своему серверу, который не идёт через туннель. Клиенты устанавливают host-маршрут для конечной точки через физический шлюз, и этот маршрут должен оставаться конкретнее маршрута по умолчанию, который добавляет клиент. Удалите его или дайте туннелю выиграть поиск для этого адреса, и инкапсулированные пакеты попытаются войти в туннель, который должны построить. Соединение падает или зацикливается.
Проверяйте этот host-маршрут до и после любой правки метрики: он должен указывать на физический следующий переход и выживать после переподключения. Если клиент им владеет, меняйте профиль или управляемую конфигурацию, а не значение времени выполнения, которое будет перезаписано.
Проверьте оба семейства адресов и контекст приложения
IPv4 и IPv6 — отдельные решения с отдельными таблицами. VPN может нести IPv4, пока IPv6 продолжает использовать локальный маршрутизатор, и правка метрики в одном семействе ничего не говорит о другом. Проверьте оба, затем проверьте контекст приложения. Процесс, привязанный к интерфейсу, пространство имён контейнера или VPN для отдельного приложения могут видеть другую таблицу, чем ваша оболочка.
Проверяйте инструментом, который сообщает решение для реального назначения, а не полным списком таблицы. Если выбранный маршрут — тот, что задуман дизайном, остановитесь. Метрика, которая не является наименьшим числом на экране, не является дефектом, и принуждение сделать её наименьшей может сломать путь конечной точки, от которого зависит туннель.