Раздельное туннелирование по приложению или по адресу назначения: что выбрать

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

Два правила действуют на разных уровнях

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

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

Правила приложений подходят мобильным клиентам и управляемым агентам

Android показывает выбор напрямую: VpnService.Builder.addAllowedApplication() и addDisallowedApplication() принимают имена пакетов и применяют решение для каждого UID, как описано в руководстве разработчика VPN для Android. В iOS есть аналог через правила VPN для отдельных приложений на основе идентификаторов пакетов, обычно доставляемые профилем MDM, а не набранные вручную.

Настольные клиенты это слабое место. Большинство клиентов VPN для Windows и macOS маршрутизируют по адресу назначения и вообще не предлагают выбор по процессу, потому что драйвер туннеля видит пакеты, а не процессы. Если ваш план зависит от туннелирования одного приложения на ноутбуке, проверьте реальные возможности клиента, прежде чем строить вокруг этого; возможно, вы выбираете между списком адресов и второй машиной.

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

Правила адреса назначения подходят спискам подсетей и доступности сайтов

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

OpenVPN приходит в ту же точку через продвигаемую таблицу маршрутов. route-nopull не даёт серверу диктовать маршруты, после чего клиентский route 10.20.0.0 255.255.0.0 vpn_gateway покрывает ровно офисный префикс. IPv6 это отдельное утверждение в каждом из этих клиентов, и забыть его самый распространённый способ утечки вокруг правильно выглядящего разделения IPv4.

Имя узла это не маршрут. Если профиль предлагает поле домена, относитесь к нему как к имени, которое клиент разрешает один раз, а не как к постоянному диапазону адресов; сети доставки содержимого и балансировщики нагрузки завтра выдадут другие адреса.

Где ломаются обе модели: помощники, общие службы, резолверы

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

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

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

Порядок действий: выбрать, применить, проверить

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

Примените самую узкую форму, которую можете выразить, затем проверьте, спросив таблицу маршрутизации, а не значок состояния клиента:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

Первые две строки называют интерфейс, который использовал бы реальный адрес назначения; wg show печатает настроенный список префиксов; в Windows Find-NetRoute отвечает на тот же вопрос, на который ответит стек при отправке пакета. Если интерфейс это туннель, правило совпало.

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