Если говорить честно с первой строки, iPhone не дает обычному стороннему VPN из App Store нормальный per-app split tunneling в духе «вот этот мессенджер идет через туннель, а браузер идет напрямую». На iOS такая модель в пользовательском сегменте почти закрыта. Apple оставила разработчикам не универсальный конструктор маршрутов, а сильно ограниченный набор механизмов, который по-настоящему раскрывается в корпоративной среде.
Дисклеймер. Материал носит технический и обзорный характер. Любые настройки VPN, прокси, маршрутизации и корпоративного управления нужно применять законно, ответственно и в соответствии с правилами вашей страны, работодателя и используемых сервисов. Не используйте описанные подходы для обхода блокировок, нарушения политик доступа, сокрытия противоправной активности или несанкционированного перехвата трафика.
Отсюда и главный вывод, который многим не нравится. На iOS раздельное туннелирование существует, но живет не там, где его ищут обычные пользователи. Реальная рабочая схема лежит в зоне MDM, управляемых приложений и специальных профилей. Для личного iPhone без корпоративного управления остается либо полный туннель, либо компромиссы, которые внешне похожи на split tunneling, но по факту им не являются.
Поддерживает ли iOS per-app раздельное туннелирование для сторонних VPN
Для массового сценария ответ ближе к «нет». Apple в своей документации прямо пишет, что per-app VPN на iOS работает для приложений, которыми управляет сервис управления устройствами. Ключевая фраза тут не «VPN», а именно «управляет». Без MDM связка разваливается.
Именно поэтому многие VPN-клиенты на iPhone предлагают красивые переключатели, но не могут честно дать тот же уровень контроля, который пользователь видит на Windows или Android. На настольной системе можно руками править маршруты, исключать подсети, прикручивать правила на процессы и проверять поведение через таблицу маршрутизации. На iPhone такого слоя управления у пользователя нет.
Технически на iOS есть Network Extension, есть packet tunnel, есть app proxy, есть on-demand логика. Но наличие API еще не означает, что любой клиент из App Store может показать экран «выбери любые приложения и отправь их в туннель». В экосистеме Apple такие возможности привязаны к модели доверенного управления устройством, а не к свободной пользовательской настройке.
Почему Apple фактически запрещает такой контроль
Apple не формулирует позицию в лоб фразой «мы запрещаем split tunneling ради N причин», но архитектура платформы говорит сама за себя. iOS построена как закрытая система, где маршрутизация, межпроцессное взаимодействие и сетевые привилегии жестко дозируются. Для Apple безопаснее и проще поддерживать модель, в которой приложение не получает слишком много власти над чужим трафиком и системной сетью.
У такого подхода есть несколько практических причин. Первая причина связана с безопасностью. Как только сторонний VPN получает удобный и массовый per-app контроль, появляется большой простор для злоупотреблений, скрытой фильтрации, выборочного перехвата и труднообъяснимых сетевых сбоев. Вторая причина связана с приватностью и поддержкой. Если пользователь не понимает, какой трафик ушел в туннель, а какой нет, виноватым все равно окажется iPhone. Третья причина связана с энергопотреблением и стабильностью. Чем больше гибких правил на уровне приложений, доменов и потоков, тем сложнее системе гарантировать предсказуемое поведение.
С точки зрения Apple ответ выглядит так: хотите тонкую маршрутизацию, идите в управляемую корпоративную модель. Хотите обычный пользовательский VPN, получайте более грубый режим работы и меньше рычагов.
Что Apple все-таки разрешает через Network Extension
Полезно отделять мифы от реальности. Apple не запрещает вообще все. Apple разрешает строить VPN и прокси-решения через Network Extension, но задает жесткие рамки, где и как такие механизмы можно применять.
На практике у разработчика есть несколько уровней возможностей. Можно поднять packet tunnel и управлять тем, какой сетевой трафик уйдет в туннель на уровне маршрутов и логики самого провайдера. Можно использовать app proxy для проксирования отдельных сетевых потоков. Можно включать VPN по правилам on-demand. Можно работать с управляемым per-app VPN, когда устройство и приложения находятся под контролем MDM.
Но тут есть важная граница. Обычному пользователю iPhone Apple не дает универсальный редактор правил «по приложениям». Самый интересный слой начинается там, где появляется AppLayerVPN и корпоративный профиль. В настройках AppLayerVPN Apple перечисляет associated domains, excluded domains, Safari domains и on-demand matching. Звучит многообещающе, но по смыслу речь идет уже не о свободной пользовательской функции, а о централизованно развернутой корпоративной политике.
Именно поэтому фраза «на iOS можно сделать per-domain обход через NEAppProxyProvider» требует поправки. Формально инструменты для доменных и апп-уровневых сценариев есть. Практически на iPhone нормальная эксплуатация такой схемы почти всегда упирается в MDM, управляемые приложения и корпоративный контур.
Per-domain на iOS: где работает, а где начинается самообман
Здесь чаще всего возникает путаница. Некоторые материалы создают ощущение, будто на iPhone можно взять любой VPN-клиент, добавить список доменов и получить аккуратное раздельное туннелирование. Для массового сценария такая картина неверна.
Что реально можно сделать в корпоративной схеме:
- привязать VPN к управляемым приложениям
- задать домены, которые будут запускать VPN в Safari
- описать associated domains для связанных приложений и сервисов
- добавить excluded domains и on-demand логику
Что обычно нельзя получить на личном iPhone без MDM:
- свободный выбор любых приложений из системы для отправки в туннель
- ручную таблицу исключений по процессам как на Windows
- полноценный пользовательский per-app split tunneling для любого стороннего VPN
- предсказуемую системную маршрутизацию с полным контролем на уровне устройства
Отдельно надо понимать границы доменных правил. Даже в управляемой схеме домен не равен «всему сервису». Современные приложения ходят к десяткам хостов, сторонним SDK, CDN, телеметрии и вспомогательным API. Стоит пропустить один узел, и «раздельное туннелирование по домену» превращается в нестабильный набор исключений.
Почему MDM для бизнеса остается единственным реальным вариантом
Если компании действительно нужен сценарий «рабочее приложение идет через защищенный туннель, личный трафик пользователя не трогаем», iOS предлагает почти единственный зрелый путь. Нужно управляемое устройство или хотя бы управляемые приложения, профиль per-app VPN и MDM-платформа, которая умеет все развернуть и сопровождать.
Именно поэтому в реальной жизни всплывают Jamf, Cisco Meraki и другие UEM/MDM-системы. У того же Jamf per-app VPN описан как режим для managed devices, где администратор задает source applications и Safari domains. Cisco Meraki решает ту же задачу через управление профилями, приложениями и политиками.
Для бизнеса такой путь неудобен, дорог и требует дисциплины, зато работает в рамках модели Apple. Для частного пользователя такой путь обычно избыточен, а иногда просто недоступен.
Сравнение вариантов: что можно получить на iPhone на самом деле
| Сценарий | Что умеет | Главное ограничение |
|---|---|---|
| Обычный VPN из App Store | Полный туннель, on-demand, иногда частичная логика внутри клиента | Нет честного универсального per-app контроля для любых сторонних приложений |
| Network Extension без MDM | Кастомная сетевая логика провайдера | На iOS быстро упирается в системные рамки и отсутствие управляемой привязки к нужным приложениям |
| AppLayerVPN и App Proxy с MDM | Per-app, Safari domains, associated domains, on-demand, excluded domains | Нужны корпоративные профили, управляемые приложения и администрирование |
| Jamf или Meraki | Нормальное развертывание per-app VPN для бизнеса | Стоимость, сложность сопровождения, корпоративный контур |
Что делать обычному пользователю, если нужен split tunneling на iPhone
Сначала полезно убрать лишние ожидания. Если задача звучит как «хочу на личном iPhone выбрать пару обычных приложений и гонять только их через сторонний VPN», iOS для такой задачи плохая платформа. Вариантов немного.
Первый вариант самый скучный, но самый честный. Использовать полный туннель и не делать вид, что на iPhone есть такой же контроль, как на настольной системе. Второй вариант связан с веб-доступом и отдельными доменными сценариями, но там быстро всплывают ограничения Safari, приложений и фоновых запросов. Третий вариант по-настоящему рабочий, но уже корпоративный: MDM, managed apps, per-app VPN и администратор, который держит конфигурацию под контролем.
Если же контроль над трафиком нужен именно вам, а не компании, проще признать ограничение платформы и перенести задачу на Windows, macOS или Android. На этих системах прозрачнее видны маршруты, исключения, DNS-поведение и фактический путь трафика.
Главный практический вывод простой. На iOS не стоит искать «секретный переключатель», который внезапно откроет честное раздельное туннелирование для любого VPN. В пользовательском сегменте такого переключателя почти нет. Рабочая глубина начинается только там, где появляется MDM.
Почему фраза «iOS — черный ящик» тут не преувеличение
В контексте сетевой маршрутизации эта формулировка довольно точная. На iPhone пользователь не видит привычную таблицу маршрутов, не может свободно навешивать правила на процессы, не получает удобный контроль над DNS на уровне отдельных приложений и не может нормально проверить половину внутренних решений платформы. Даже когда VPN вроде бы работает, понять реальную картину бывает трудно без корпоративной инфраструктуры и глубокого тестирования.
Для кого-то такой дизайн удобен. Меньше ручных настроек, меньше способов сломать сеть, меньше случайных дыр. Но если вы хотите инженерный контроль, iOS быстро начинает раздражать. Система дает ровно столько свободы, сколько Apple считает безопасным и обслуживаемым, а не столько, сколько хотелось бы администратору или продвинутому пользователю.
Вывод: что делать с раздельным туннелированием на iPhone в 2026 году
Если нужен короткий и честный ответ, он выглядит так. Для обычного пользователя iPhone полноценное per-app раздельное туннелирование в сторонних VPN практически недоступно. Через Network Extension можно построить многое, но не в той свободной форме, к которой привыкли на других платформах. Реальный рабочий путь лежит через корпоративные профили, MDM, managed apps и per-app VPN.
Поэтому выбор простой. Либо принимаете модель Apple и живете с полным туннелем и минимумом контроля, либо переводите задачу в корпоративный контур, где Jamf, Meraki и AppLayerVPN действительно решают проблему. Во всех остальных случаях iOS остается черным ящиком с красивым интерфейсом и очень скупым доступом к внутренней маршрутизации.
FAQ
Можно ли на личном iPhone выбрать любые приложения и пустить только их через VPN?
В нормальном пользовательском сценарии почти нет. Для iOS такой режим обычно требует MDM и управляемых приложений.
Правда ли, что NEAppProxyProvider решает проблему?
Не для массового сценария сам по себе. API существует, но на iPhone реальная эксплуатация обычно упирается в корпоративную схему с AppLayerVPN и MDM.
Можно ли сделать split tunneling по доменам?
Частично да, но в управляемом контуре и с оговорками. Есть Safari domains, associated domains и excluded domains, но такой подход не равен универсальному системному контролю.
Что выбрать бизнесу?
MDM-платформу, которая умеет per-app VPN, управляемые приложения и нормальное сопровождение профилей. На практике чаще смотрят в сторону Jamf, Cisco Meraki и близких по классу решений.
На какой платформе проще добиться честного контроля?
На Windows, macOS и Android. Там обычно проще управлять маршрутами, проверять DNS и наблюдать реальное поведение трафика.
