Рабочее приложение требует VPN? Сначала проверьте эти три слоя
Рабочее приложение, требующее VPN, может сбоить из-за приватного имени, политики приложения или управляемой блокировки. Определите ответственного, прежде чем подключаться заново.
В сообщении сказано, что приложению нужен VPN, но обычно приложение сообщает о симптоме, а не называет то, что его заблокировало. Такую фразу могут породить три разных ответственных: частная служба, с которой общается приложение, собственный код политики приложения и уровень управления устройством, который контролирует рабочий профиль. То, кто именно спрашивает, меняет ваши действия, и только один из трёх исправляется подключением туннеля. Поиск ответственного сразу избавляет вас от переустановки клиента, который никогда не был проблемой.
Что приложение может проверить само
Прежде чем предполагать скрытое правило платформы, вспомните, что обычное приложение может видеть, активен ли транспорт VPN. ConnectivityManager сообщает о сетях с TRANSPORT_VPN, а отсутствие NET_CAPABILITY_NOT_VPN говорит любому вызывающему, что текущий путь идёт через туннель. Разработчик, который хочет отказываться работать вне туннеля, может сделать это с помощью публичных API и вообще без корпоративных инструментов.
Чего приложение так не видит, это чей VPN. Флаг транспорта говорит, что туннель существует, а не что он заканчивается там, где ожидает ваша организация.
Путь службы: частные имена и адреса
Самая частая честная версия сообщения вовсе не проверка политики. Приложение разрешает внутреннее имя хоста, например вики или конечную точку API, которая существует только внутри корпоративного представления DNS, и поиск не удаётся ещё до запуска любого кода политики. Туннель может быть поднят и пропускать общий интернет-трафик, пока разделённый DNS отправляет это имя резолверу, который о нём никогда не слышал.
Симптомы здесь узкие. Один хост не работает, остальные сетевые вызовы приложения проходят, и сбой проявляется при поиске имени, а не при запуске. Внутренние сертификаты добавляют второй режим отказа: приложение, закреплённое за CA организации, отклоняет публичный сертификат, даже когда пакеты идут.
Подключение случайного коммерческого VPN ничего из этого не исправляет. Оно меняет ваш адрес выхода и оставляет внутреннее имя таким же неразрешимым.
Уровень политики приложения
Приложение может нести и собственные ворота. Управляемые конфигурации позволяют организации передавать пары ключ-значение, которые приложение объявляет, и приложение читает их через RestrictionManager. Ключ вроде обязательного имени профиля или списка разрешённых сетей это целиком замысел разработчика, применяемый в коде приложения с тем текстом ошибки, который выберет этот код.
Именно на этом уровне формулировка обычно себя выдаёт. Если сообщение появляется сразу при запуске, до любого сетевого вызова, и упоминает политику, профиль или администратора, вы, скорее всего, смотрите на логику приложения, а не на потерянный пакет.
Читать то же ограничение на личном устройстве это тупик. У неуправляемых устройств нет ограничений для чтения, поэтому приложение возвращается к значению по умолчанию, с которым было собрано.
Уровень платформы: постоянное подключение и блокировка
Управление устройством добавляет принуждение, которое приложение не может обойти. Контроллер политики устройства может вызвать setAlwaysOnVpnPackage для рабочего профиля, при желании с включённой блокировкой, и как только блокировка включена, платформа отклоняет трафик, не идущий через этот пакет. Блокировка видна как системное состояние, а не как ошибка приложения: остальные приложения профиля тоже перестают достигать сети.
Область действия важна. VPN «всегда включён» настраивается для каждого пользователя, поэтому пакет рабочего профиля не покрывает ваш личный профиль, а личный VPN не удовлетворяет пакет рабочего профиля. Два профиля, две независимые сетевые политики, одно устройство.
Это также единственный уровень, где посторонний VPN не может помочь, потому что политика называет один конкретный пакет.
Как различить три
Пройдите по признакам по порядку и остановитесь на первом подходящем. Если одно имя хоста не работает, а всё остальное разрешается, это указывает на путь службы. Немедленный отказ при запуске с формулировкой политики указывает на логику приложения. Если весь профиль теряет связь всякий раз, когда отключается одобренный клиент, это указывает на блокировку. А приложение, которое принимает любой туннель, проверяет флаг транспорта, а не идентичность вашей организации.
Полезные доказательства: точный текст и его время, есть ли ещё связь у других приложений того же профиля, разрешается ли приватное имя внутри одобренного туннеля и показывает ли устройство рабочий значок для открытого вами приложения.
Что указать в запросе в поддержку
Запрос, в котором назван уровень, направляется правильно с первой попытки. Примерно так: приложение рабочего профиля открывается, список ресурсов не работает после подключения одобренного VPN, разрешение приватного имени не работает в разрешённой диагностике, а другие приложения профиля продолжают работать. Это читается как проблема маршрута или резолвера и позволяет пропустить цикл сброса учётной записи.
Если одобренный VPN вообще отсутствует, поддерживаемый путь это регистрация или повторное развёртывание через вашего администратора. Удаление профиля управления, установка постороннего клиента или подделка состояния сети меняет схему безопасности, а не восстанавливает её.
Начните с уровня, а не с клиента. Три признака выше обычно решают вопрос за одну сессию.