Маршрут есть, но трафик идёт иначе: проверяем ip rule и отдельные таблицы

В таблице маршрутов указан правильный шлюз. Однако запрос приложения уходит через VPN, а ручная проверка от другого источника работает. Такая ситуация часто возникает, когда рассматривают только основную таблицу. Linux умеет выбирать таблицу по источнику, метке пакета и другим условиям. Поэтому один адрес назначения не всегда означает один путь.

Начните с правил, а не с нового маршрута

ip rule show
ip route show table main
ip route show table all

У правил есть числовой приоритет: меньшее значение рассматривается раньше. Действие lookup отправляет поиск в определённую таблицу. Например, правило для источника 10.40.0.0/24 может выбрать таблицу 100 раньше, чем управление дойдёт до main. Добавление маршрута в main тогда не изменит результат.

Не считайте любое раннее правило окончательным запретом остальных таблиц. Обычный поиск может продолжиться, если таблица не дала подходящий маршрут. Поэтому требуется читать и условие правила, и содержимое таблицы. Особое внимание уделите default route: он подходит почти любому назначению и способен завершить поиск там, где вы ожидали переход к следующему правилу.

Воспроизведите условия приложения

ip route show table 100
ip route get 192.0.2.45 from 10.40.0.12
ip route get 192.0.2.45 from 10.40.0.12 mark 0x10

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

Представим, что без метки выбран интерфейс eth0, а с меткой — tun0. Это полезное различие только после подтверждения метки у проблемного трафика. Иначе вы исследуете путь, которым приложение никогда не пользуется. Если важен источник, повторите сравнение с адресом, который реально привязан к сокету приложения.

Полезный результат — короткая причинная цепочка: соединение имеет источник 10.40.0.12, правило с приоритетом 1000 отправляет его в таблицу 100, её default route ведёт через VPN. По такой записи уже понятно, какой элемент политики обсуждать. Фраза «маршрутизация сломалась» этого не даёт.

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

Если VPN должен обслуживать только определённые сети, проверьте его маршруты и селекторы. Если отдельный источник предназначен для отдельного провайдера, проверьте обратный путь и правила на соседнем оборудовании. Не удаляйте все ip rule: среди них могут быть правила локальных адресов и политики других служб.

Изменения удобно сначала описать в виде ожидаемого поиска для двух назначений: проблемного API и контрольного внутреннего сервиса. После согласованного применения повторите route get для обоих. Так вы проверяете не только исправленный случай, но и смысл оставшейся политики.

Локальные команды показывают текущее состояние ядра. Конфигурация VPN или сетевого менеджера может восстановить прежние правила при переподключении. Закреплять исправление нужно в том компоненте, который управляет правилами, после чего проверить повторное подключение на стенде.

Хотите уверенно объяснять такие расхождения? Откройте программу курса Linux и Bash для DevOps-инженеров. Его практика сетевой диагностики и сопровождения учебного сервиса помогает связывать проверку команды с причиной недоступности, прежде чем менять рабочую конфигурацию.

Ещё по теме

• CLOSE_WAIT растёт: почему перезапуск сети не закрывает сокеты приложения
• dig находит адрес, приложение нет: сравниваем DNS и системное разрешение имён