Два VPN на iPhone одновременно: какой из них несёт ваш трафик?

Два приложения VPN оба показывают Connected, и предполагается, что трафик теперь идёт через оба, одно внутри другого. Обычно это не так. В iOS есть определённая модель сосуществования, и это не цепочка. Один класс конфигурации ограничен одним включённым экземпляром, другой может работать рядом, а приоритет маршрутов решает конфликты. Два включённых переключателя — не два прыжка. Модель документирована, то есть путь можно предсказать, а не угадывать по значкам.

Миф: два подключённых VPN — это цепочка

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

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

Документированная модель за этим мифом

NETunnelProviderManager от Apple описывает обычные корпоративные конфигурации VPN и утверждает, что одновременно можно включить только одну такого типа. Тот же справочник позволяет Personal VPN оставаться включённым и подключённым рядом и даёт корпоративным маршрутам приоритет там, где они пересекаются.

Здесь Personal VPN — это термин API для встроенной реализации IPsec или IKEv2, управляемой через NEVPNManager. NETunnelProviderManager — это модель поставщика туннеля. Потребительское приложение может использовать модель поставщика, поэтому название продукта со словом personal его не классифицирует.

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

Миф: личный VPN получает трафик просмотра

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

Управляемые конфигурации для отдельных приложений имеют свою область. Не переносите правило уровня устройства на каждое управляемое развёртывание.

Запишите два потока до теста: частное имя и диапазон рабочей службы, а также новый запрос публичного просмотра. Оба законны, и им нужны разные проверки.

Приоритет маршрутов с рабочим профилем разделённого туннеля

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

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

Запишите два потока и проверьте каждый

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

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