Раздельное туннелирование на Android: как настроить и не словить DNS leak

 Split tunneling на Android нужен в тот момент, когда полный VPN начинает мешать. Банк не любит «чужой» IP, медиаплеер теряет локальную сеть, рабочий клиент должен видеть корпоративные подсети, а остальным программам VPN вообще не нужен. В такой схеме часть приложений идет через туннель, часть работает напрямую через обычный интернет.

Главная ошибка в том, что люди смешивают три разные вещи. Первая вещь, какие приложения могут пользоваться VPN. Вторая, какие подсети и адреса вообще уходят в туннель. Третья, какой DNS реально обслуживает запросы. Пока три слоя не разложили по местам, split tunneling кажется «сломавшимся», хотя проблема обычно в маршрутах или резолвере, а не в самом VPN.

Материал описывает сетевую маршрутизацию и диагностику Android. Используйте VPN и split tunneling законно и ответственно, с учетом правил вашей страны, оператора и сервиса. Для России отдельные сценарии обхода ограничений могут нарушать требования регулятора и условия доступа. Не применяйте настройки для обхода блокировок, сокрытия противоправной активности или доступа к запрещенным ресурсам.

Что такое раздельное туннелирование и зачем он нужен на телефоне

Если коротко, раздельное туннелированиеелит трафик на две части. Одна часть уходит через VPN, другая идет напрямую. На телефоне такой режим полезен чаще, чем на ноутбуке, потому что мобильные приложения сильно завязаны на регион, локальную сеть, пуши, геолокацию и быстрые переключения между Wi-Fi и LTE.

Нормальные сценарии у split tunneling вполне бытовые. Через VPN можно пустить рабочий мессенджер, браузер или корпоративный клиент, а банк, такси, стриминг и устройства умного дома оставить снаружи. Второй частый сценарий, VPN нужен только для доступа к частным подсетям компании, а обычный интернет должен идти напрямую, без лишней задержки и без расхода батареи.

Нативная поддержка split tunneling в Android 10+ и где начинается путаница

Фраза «в Android 10+ split tunneling настраивается в системных VPN-настройках» верна только наполовину. В самом Android механизм есть давно: в API Android предусмотрены списки разрешенных и запрещенных приложений, маршруты, исключения маршрутов и DNS-серверы. Но обычный пользователь чаще управляет split tunneling не в голом меню Android, а внутри конкретного VPN-клиента.

Системный экран VPN в Android дает базовые вещи: подключение, удаление профиля, иногда Always-on. В справке Google отдельно видно важный нюанс: если VPN поднят через приложение, при редактировании настроек Android часто просто открывает само приложение. То есть системный экран не превращает любой VPN в универсальный per-app редактор.

Еще один нюанс. Для обычного пользователя per-app split tunneling и режим «блокировать все без VPN» дружат не всегда. Логика проста: вы просите часть программ идти мимо туннеля, а потом включаете жесткий запрет на любой не-VPN трафик. На части устройств и клиентов такой режим ведет себя ожидаемо, на части ломает обходные приложения. Проверять нужно руками именно на вашей связке Android, оболочки и VPN-клиента.

Как думать о настройке правильно: per-app и per-IP решают разные задачи

Per-app отвечает на вопрос «какое приложение может использовать VPN». Per-IP отвечает на вопрос «какие адреса и сети вообще доступны через туннель». Эти режимы можно комбинировать, и именно здесь многие путаются.

Пример. В WireGuard вы оставили полный маршрут 0.0.0.0/0 и ::/0, но в списке приложений выбрали «только Telegram и браузер». Результат простой: только Telegram и браузер уходят в VPN, все остальные программы идут напрямую. Другой пример: вы задали в конфиге только корпоративные подсети, а в списке приложений отметили рабочий клиент. Тогда рабочий клиент пойдет через VPN лишь к этим подсетям, а весь остальной трафик клиента останется обычным.

Отсюда главный практический вывод. Если приложение нужно пустить через VPN целиком, работайте списком приложений. Если нужен доступ только к определенным внутренним сетям, работайте маршрутами. Если хотите одновременно выбрать и приложение, и конкретные подсети, совмещайте оба слоя. Если хотите правило вида «этот же браузер к одному домену через VPN, а к другому напрямую», штатный Android без сложных обходных конструкций такого почти не дает.

Пошаговая настройка split tunneling в WireGuard для Android

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

1. Установите WireGuard и импортируйте туннель по QR-коду или из файла.
2. Откройте туннель и нажмите на редактирование.
3. В разделе интерфейса найдите фильтр приложений. В актуальных версиях обычно доступны три режима: все приложения, только выбранные, исключить выбранные.
4. Если хотите пустить через VPN только пару программ, выбирайте режим «только выбранные» и отмечайте нужные приложения.
5. Если хотите, чтобы через VPN шло все, кроме банка или локального медиаплеера, выбирайте исключение и отмечайте лишние приложения.
6. Сохраните профиль и включите туннель.

Теперь про маршруты. В WireGuard за них отвечает поле AllowedIPs. Полный туннель выглядит так:

[Interface]
 Address = 10.0.0.2/32
 DNS = 10.0.0.53
 
 [Peer]
 AllowedIPs = 0.0.0.0/0, ::/0
 Endpoint = vpn.example.com:51820

Частичный туннель к внутренним сетям выглядит так:

[Interface]
 Address = 10.0.0.2/32
 DNS = 10.0.0.53
 
 [Peer]
 AllowedIPs = 10.10.0.0/16, 192.168.50.0/24
 Endpoint = vpn.example.com:51820

Логика здесь такая. Поле AllowedIPs не выбирает приложения. Поле AllowedIPs выбирает сети, доступные через туннель. Если рядом включен режим «только выбранные приложения», в VPN пойдут только отмеченные программы и только к тем сетям, которые перечислены в AllowedIPs.

Пошаговая настройка split tunneling в OpenVPN for Android

Здесь сразу полезное уточнение. Для per-app split tunneling на Android обычно используют именно OpenVPN for Android от Arne Schwabe, а не OpenVPN Connect. У первого клиента такой сценарий развит заметно лучше и привычнее для ручной настройки.

1. Установите OpenVPN for Android и импортируйте профиль .ovpn.
2. Откройте профиль на редактирование.
3. Найдите вкладку Allowed Apps или раздел со списком приложений.
4. Выберите один из двух режимов: использовать VPN для всех приложений, кроме выбранных, или использовать VPN только для выбранных.
5. Отметьте нужные приложения, сохраните профиль и подключитесь.

С маршрутами у OpenVPN отдельная история. Per-app список в клиенте и IP-маршруты в профиле живут независимо. Если сервер или профиль пушит полный туннель через redirect-gateway, выбранные приложения будут уходить в VPN целиком. Если профиль работает в частичном режиме, клиент увидит только те сети, которые вы явно оставили в маршрутах.

Классический пример частичного режима на стороне клиента выглядит так:

route-nopull
 route 10.10.0.0 255.255.0.0 vpn_gateway
 route 192.168.50.0 255.255.255.0 vpn_gateway

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

Что Android умеет без root, а где начинаются жесткие ограничения

Без root Android дает довольно много, но не все. Можно выбрать приложения, которые идут через VPN. Можно пустить через туннель только нужные подсети. Можно исключить отдельные сети. Можно задать DNS со стороны VPN-клиента. На этом комфортный слой заканчивается.

Проще говоря, Android без root отлично подходит для правила «эти приложения через VPN, эти нет» и для правила «в туннель только такие подсети». Но Android без root плохо подходит для ювелирной политики уровня «этот же процесс к одному домену через VPN, к другому без VPN, DNS при этом всегда идет строго так, а не иначе».

DNS leak при частичном туннеле: почему возникает и почему его недооценивают

DNS leak в split tunneling пугает не зря. Внешний IP у приложения может выглядеть «правильным», а запросы имен при этом уйдут не туда, куда вы рассчитывали. Android сам по себе позволяет VPN-клиенту задать DNS, но в документации прямо сказано, что если DNS не задан, система использует DNS серверы сети по умолчанию. Уже одного этого хватает, чтобы частичный туннель вел себя не так, как ожидает пользователь.

Есть и более неприятный уровень. В 2024 году Mullvad публично разбирал реальные сценарии, где Android допускал утечки DNS даже при включенном жестком режиме VPN. Мораль простая: надпись «VPN включен» еще не гарантирует, что каждый DNS-запрос остался внутри нужного контура.

На практике leak чаще всего рождается из четырех причин. Первая, в профиле VPN вообще не задан DNS. Вторая, DNS задан, но резолвер недостижим через те маршруты, которые вы оставили в частичном туннеле. Третья, системный Private DNS живет по своей логике и ломает ваши ожидания. Четвертая, вы тестируете не то приложение. Проверили браузер, который специально оставили вне VPN, увидели «утечку» и решили, что туннель не работает, хотя по факту браузер именно так и должен ходить.

Как снизить риск DNS leak и не обмануть самого себя тестами

Первое правило простое. Если вам нужна не гибкость, а максимальная предсказуемость, выбирайте полный туннель. Split tunneling почти всегда удобнее, но почти всегда сложнее для проверки.

Второе правило, задавайте DNS явно. Для WireGuard лучше использовать DNS, который точно достижим внутри туннеля. Для OpenVPN проверьте, какие DNS серверы реально пушит профиль и не ломает ли частичная маршрутизация путь к ним.

Третье правило, тестируйте два разных приложения. Одно приложение должно быть внутри VPN, второе снаружи. Для каждого смотрите отдельно внешний IP и отдельно резолвер. Оценка только по «какой у меня IP» слишком грубая и часто ничего не говорит о DNS.

Четвертое правило, прогоните проверку после переключения Wi-Fi на мобильную сеть, после сна устройства и после переподключения VPN. Именно на переходах между сетями и пересборке туннеля всплывают ошибки, которых не видно на спокойном статичном соединении.

Когда split tunneling на Android действительно полезен, а когда лучше не трогать

Split tunneling оправдан, когда есть ясная задача. Например, нужен доступ к рабочим подсетям, но не нужен полный VPN для всего телефона. Или локальный медиасервер, телевизор, принтер и Android Auto должны видеть домашнюю сеть, а браузер и рабочий клиент надо держать в туннеле. В таких случаях режим экономит нервы и часто работает лучше полного VPN.

Но если цель звучит как «хочу, чтобы телефон вел себя сложно и умно, а я потом забуду, где что проходит», лучше остановиться. Чем больше исключений, тем труднее искать причину поломки. Если у вас уже были проблемы с пушами, VoIP, банковскими приложениями, Smart TV и локальными устройствами, не начинайте с десяти правил сразу. Соберите минимальную схему, проверьте, потом добавляйте исключения по одному.

Практический вывод по split tunneling на Android

Split tunneling на Android работает нормально, если помнить простую модель. Список приложений отвечает за то, кто может использовать VPN. Маршруты отвечают за то, какие сети доступны через туннель. DNS отвечает за то, как приложения находят адреса. Ошибка почти всегда сидит в одном из трех слоев, а не в абстрактном «Android что-то сломал».

Для WireGuard схема обычно проще и нагляднее. Для OpenVPN for Android гибкости хватает, но нужно внимательнее смотреть на маршруты и поведение импортированного профиля. Без root Android уверенно закрывает бытовой сценарий per-app split tunneling, но не дает тонкой доменной магии и не обещает безупречный split DNS во всех случаях.

Если нужна предсказуемость, берите полный туннель. Если нужна гибкость, split tunneling на Android вполне рабочий, но только после нормальной проверки на вашем устройстве.