Как отличить маршруты, продвигаемые VPN, от статических в Linux

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

Шаг 1: назовите механизм, который устанавливает префиксы

Разные протоколы обеспечивают доступность по-разному, и называть всё это объявлением скрывает различие. Сервер OpenVPN продвигает директиву маршрута по каналу управления, и клиент устанавливает её, если pull-фильтр не блокирует. Конфигурация WireGuard локально перечисляет разрешённые префиксы, которые клиент использует и для маршрутизации криптоключей, и для добавляемых маршрутов. Туннель IPsec согласует селекторы трафика с партнёром, и ядро устанавливает маршруты из этих селекторов.

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

Шаг 2: сравните таблицу в течение одного подключения

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

Снимите её командой ip route show table main > /tmp/route-down.txt, подключитесь и снимите снова. Сделайте то же для ip -6 route, если сайт использует IPv6, потому что отсутствующий префикс там порождает сбои, которые выглядят не связанными с маршрутизацией.

Шаг 3: читайте метрику, а не только наличие

Две записи для одного префикса могут существовать одновременно, и ядро выбирает меньшую метрику. Статический маршрут с метрикой 50 будет по-прежнему побеждать продвинутый маршрут с метрикой 100, хотя видны оба, поэтому «маршрут есть» и «трафик идёт через него» — разные утверждения.

Спросите ядро напрямую командой ip route get 10.20.5.7 и прочитайте интерфейс, который оно сообщает. Если трафик уходит через физический адаптер, пока маршрут туннеля стоит в таблице, это объясняет метрика или длина префикса, а не клиент VPN. Повторите поиск для хоста, о котором вы знаете, что он за туннелем, и для того, о котором знаете, что нет, и разница покажет, работает ли разделение как задумано.

Шаг 4: найдите записи, которые переживают туннель

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

Проверьте постоянную сторону в том месте, которое использует ваш дистрибутив: модуль systemd-networkd, профиль NetworkManager или скрипт в каталоге up клиента. Исправление живой таблицы командой ip route del держится только до следующего подключения. Считайте это удаление проверкой гипотезы, а не ремонтом.

Там, где дальний конец даёт неверное покрытие, поднимите вопрос у оператора, вместо того чтобы фильтровать всё. Отказ от всех продвинутых настроек отбрасывает также DNS и политику раздельного туннеля, от которых зависит профиль.

Шаг 5: подтвердите обратный путь, прежде чем винить клиента

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

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

Шаг 6: проверяйте ресурс, а не ping

Когда выбранный маршрут верен, откройте настоящий ресурс и подтвердите обратный трафик. Ответ ping доказывает путь в одном направлении и ничего о службе, а служба, отвечающая на кэшированное соединение, доказывает ещё меньше.

Затем повторите всю проверку после переподключения. Ценность последовательности в том, что она предсказывает, что сделает следующее подключение, поэтому и сравнение, и метрика принадлежат тикету.