Приложение привязано к интерфейсу? Его путь через VPN не по умолчанию

Одно приложение на машине выходит через VPN, другое — нет, и оба пользователя клянутся, что ничего не меняли. Разница часто в решении о привязке, которое принимает само приложение: сокет, привязанный к устройству, исходный адрес, выбранный до соединения, или пространство имён с собственной таблицей маршрутизации. Каждое из них меняет то, какой путь действует, и ни одно не видно в обычной проверке IP в браузере.

Три разные привязки, три разных эффекта

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

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

Определите, что приложение действительно задаёт

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

В Linux у параметров сокета вроде SO_BINDTODEVICE есть документированный охват и требования к правам, и непривилегированный процесс может вообще не суметь их задать. Это ограничение — полезная подсказка: если параметр нельзя применить, приложение, вероятно, не является источником различия.

Маршрутизация по политике читает источник

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

Воспроизведите поиск с тем же семейством адресов, источником и пространством имён, которые использует приложение. Обычный поиск маршрута из оболочки в пространстве имён хоста отвечает на другой вопрос, и это несовпадение — самая частая причина того, что рабочий маршрут выглядит сломанным.

Разделённый туннель и вспомогательные процессы

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

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

Проверьте собственный путь приложения

Запускайте новый запрос из приложения после каждого изменения. Браузер, показывающий нужный вам выход, не является равнозначным доказательством для другой программы, привязанной к другому интерфейсу, а кэшированные соединения могут долго использовать старый путь после изменения настройки. Закройте старую сессию, прежде чем судить о новом правиле. Иначе проверка измеряет прошлое.

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