VPN для приложений на управляемых iPhone: что маршрутизируется, а что нет
Туннель на уровне приложения следует за управляемым приложением, а не за телефоном. Проверьте привязку профиля, управляемую копию, правила по требованию и потоки, выходящие из приложения.
VPN для приложений на iPhone — не переключатель для всего телефона. Это связь одного управляемого приложения с одним профилем VPN, создаваемая при развёртывании приложения, а трафик всего остального сохраняет прежний маршрут. Поэтому один и тот же телефон ведёт себя непоследовательно: рабочее приложение открывает приватную страницу, а Safari не достигает того же хоста, либо туннель вообще не поднимается, и приложение сообщает о тайм-ауте, похожем на неверные учётные данные. Проверки идут от самой широкой причины вниз, поэтому остановитесь на первой неудачной.
Сначала проверьте профиль и запись приложения
Связь живёт в двух объектах, а не в одном. Профиль VPN определяет туннель: тип, сервер, аутентификацию, DNS и идентификатор пакета провайдера при использовании нестандартного клиента. Запись приложения указывает на этот профиль, и большинство консолей управления предлагают это как опцию для приложения в конфигурации приложения, под именем, близким к Per-App VPN. Профиль, на который не указывает ни одно приложение, ничего не маршрутизирует для приложения; он ведёт себя как обычный туннель, который кто-то должен запустить вручную.
Прочитайте оба объекта до того, как трогать телефон. Убедитесь, что конфигурация приложения указывает на проверяемый профиль, а не на его старую копию, потому что дублирующиеся профили с почти одинаковыми именами часто встречаются после миграции, и приложение охотно указывает на отозванный. Затем убедитесь, что конфигурация дошла до устройства: Настройки, Основные, VPN и управление устройством должны показывать её как установленный профиль. Список VPN там — не проверка. У службы для приложений обычно нет ручного переключателя, поэтому корректно развёрнутая конфигурация может никогда не появиться среди VPN, которые можно запустить. Отсутствие видно в записи приложения и в том, поднимается ли туннель при первом запросе приложения.
Одно условие объясняет многие обращения: эта модель требует, чтобы приложение пришло через управление. Копия, установленная сбоку или купленная лично, не получает связь, даже если её идентификатор пакета совпадает. Руководство Apple по развёртыванию VPN описывает модель профиля, стоящую за этим (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
Убедитесь, что установленное приложение — управляемая копия
Связь следует за установленным управляемым приложением. Если кто-то переустановил его из App Store с личным Apple ID, заменил переподписанной корпоративной сборкой или устройство зарегистрировали заново, и приложение вернулось другим каналом, туннель может остаться внизу, пока само приложение выглядит совершенно нормально.
Проверяйте сравнением, а не одним наблюдением. В инвентаре управления приложение должно отображаться как управляемое для этого устройства с сопоставлением VPN в записи. На телефоне туннель должен подниматься при запуске приложения и выходе его первого запроса, а не только когда кто-то запускает отдельную ручную конфигурацию в Настройках. Если запуск приложения ничего не меняет, а эта ручная конфигурация меняет, приложение вообще не привязано к туннелю для приложения.
Обновления важны: отправленное через управление сохраняет сопоставление, а переустановка, начатая пользователем, может его потерять. Если жалоба датируется обновлением, проверьте запись приложения до сети.
Проверьте, что туннель может взять
Туннель для приложения выбирается по исходному приложению, поэтому маршрут телефона по умолчанию по-прежнему принадлежит Wi-Fi или сотовой сети. OverridePrimary — ключ, который это меняет. Когда профиль задаёт его, туннель ведёт себя как полный туннель, и каждое приложение его наследует, поэтому всё, что идёт через VPN, становится вопросом профиля, а не сбоем приложения.
Правила по требованию определяют устойчивость. OnDemandEnabled и его набор правил возвращают туннель, когда приложение отправляет трафик, переживают переключение с Wi-Fi на сотовую сеть или роняют его, когда приложение уходит в фон. Развёртывание, которое подключается и затем тихо умирает, обычно имеет правило, подходящее только к пробе, которая никогда не срабатывает, пока приложение неактивно.
Затем прочитайте сторону маршрутов честно. Если профиль провайдера или поставщика даёт список включения, туннель, несущий только 10.20.0.0/16, не понесёт службу в 10.30.0.0/16; это список делает свою работу, а не сбой для приложения. Встроенный профиль iOS не имеет списка включения. Без него разделение следует значениям провайдера по умолчанию и IncludeAllNetworks, а не скрытому списку.
Проверьте приложение, затем проверьте, что из него выходит
Проверяйте по имени, а не только по адресу. Разрешение внутреннего хоста внутри управляемого приложения доказывает, что и DNS прошёл через туннель, потому что профиль определяет, какой резолвер отвечает и какие домены поиска применяются. Маршрутизация может быть идеальной, пока поиск имени терпит неудачу, и оба симптома указывают на разные настройки.
Затем проверьте границу с обеих сторон. Личное приложение или Safari должны достигать обычной публичной страницы и сообщать адрес оператора или домашний, а управляемое приложение достигает приватной службы. Если оба сообщают один и тот же публичный адрес, туннель больше не для приложения, что бы ни утверждала запись приложения.
Потоки, выходящие из приложения, создают запутанные обращения. Ссылка, открывающаяся в Safari, документ, переданный через лист общего доступа, или вход SSO, переходящий в браузер, покидают процесс приложения и вместе с ним туннель. Вход, показанный внутри приложения, обычно приписывается приложению, поэтому встроенный вход может сработать там, где тот же URL не работает в Safari; проверьте это, а не предполагайте. Когда поставщик идентичности доступен только через туннель, держите вход внутри приложения или добавьте домен поставщика в домены Safari профиля, чтобы соответствующий трафик Safari перехватывался.
Соотнесите симптом со слоем
Форма сбоя подсказывает, какую проверку повторить.
| What you see | Where the repair is |
|---|---|
| Tunnel never appears when the app opens | App-to-payload association, or the app is not the managed copy |
| Tunnel connects, internal name resolves, connection times out | Provider or vendor include list missing the subnet, or a far-side firewall |
| Tunnel connects, internal name fails to resolve | DNS servers or search domains in the payload |
| Every app uses the tunnel | OverridePrimary set, or a full-tunnel payload reused |
| Worked until an update, broken since | Association lost on reinstall, or the payload was replaced |
За средними строками стоят две детали: туннель для приложения может быть здоровым и всё же пропускать подсеть, которой нет ни в одном списке провайдера, а управляемый телефон может хранить более одной конфигурации VPN, поэтому убедитесь, к какой привязано приложение, вместо того чтобы считать, что это та, которую вы читаете.
Исправляйте в таком порядке: направьте запись приложения на действующий профиль, переустановите приложение через управление, убедитесь, что туннель поднимается при первом запросе приложения, затем повторите проверки имени и границы. Если первый запрос вообще не может запустить туннель, остановитесь и проверьте сторону провайдера, потому что нестандартному клиенту нужен существующий Network Extension и идентификатор, соответствующий установленному приложению.
Верните три факта вместо снимка экрана: на какой профиль указывает запись приложения, показывают ли Настройки его как установленный профиль и каким был неудачный запрос — имя, адрес или передача в браузер. Эти три ответа отделяют ошибку развёртывания от ошибки маршрутизации, и следующий человек может действовать, не повторяя диагностику.