Робочий застосунок вимагає VPN? Спершу перевірте ці три шари

Повідомлення каже, що застосунку потрібен VPN, але зазвичай застосунок повідомляє про симптом, а не називає те, що його заблокувало. Таку фразу можуть породити три різні відповідальні: приватна служба, з якою спілкується застосунок, власний код політики застосунку та рівень керування пристроєм, який контролює робочий профіль. Те, хто саме питає, змінює ваші дії, і лише один із трьох виправляється підключенням тунелю. Пошук відповідального одразу позбавляє вас перевстановлення клієнта, який ніколи не був проблемою.

Що застосунок може перевірити сам

Перш ніж припускати приховане правило платформи, згадайте, що звичайний застосунок може бачити, чи активний транспорт VPN. ConnectivityManager повідомляє про мережі з TRANSPORT_VPN, а відсутність NET_CAPABILITY_NOT_VPN каже будь-якому викликачу, що поточний шлях іде через тунель. Розробник, який хоче відмовлятися працювати поза тунелем, може зробити це за допомогою публічних API і взагалі без корпоративних інструментів.

Чого застосунок так не бачить, це чий VPN. Прапор транспорту каже, що тунель існує, а не що він закінчується там, де очікує ваша організація.

Шлях служби: приватні імена та адреси

Найпоширеніша чесна версія повідомлення зовсім не перевірка політики. Застосунок розв’язує внутрішнє ім’я хоста, наприклад вікі або кінцеву точку API, яка існує лише в корпоративному поданні DNS, і пошук не вдається ще до запуску будь-якого коду політики. Тунель може бути піднятий і пропускати загальний інтернет-трафік, поки розділений DNS надсилає це ім’я розв’язувачу, який про нього ніколи не чув.

Симптоми тут вузькі. Один хост не працює, решта мережевих викликів застосунку проходять, і збій проявляється під час пошуку імені, а не під час запуску. Внутрішні сертифікати додають другий режим відмови, бо застосунок, закріплений за CA організації, відхиляє публічний сертифікат, навіть коли пакети йдуть.

Підключення випадкового комерційного VPN нічого з цього не виправляє. Воно змінює вашу адресу виходу і залишає внутрішнє ім’я таким самим невирішуваним.

Рівень політики застосунку

Застосунок може мати й власну браму. Керовані конфігурації дозволяють організації надсилати пари ключ-значення, які застосунок оголошує, і застосунок читає їх через RestrictionManager. Ключ на зразок обов’язкового імені профілю або списку дозволених мереж це цілком задум розробника, що застосовується в коді застосунку з тим текстом помилки, який обере цей код.

Саме на цьому рівні формулювання зазвичай себе видає. Якщо повідомлення з’являється одразу під час запуску, до будь-якого мережевого виклику, і згадує політику, профіль або адміністратора, ви, найімовірніше, дивитеся на логіку застосунку, а не на втрачений пакет.

Читати те саме обмеження на особистому пристрої це глухий кут. У некерованих пристроїв немає обмежень для читання, тому застосунок повертається до значення за замовчуванням, з яким був зібраний.

Рівень платформи: постійне підключення та блокування

Керування пристроєм додає примус, який застосунок не може обійти. Контролер політики пристрою може викликати setAlwaysOnVpnPackage для робочого профілю, за бажанням з увімкненим блокуванням, і щойно блокування ввімкнено, платформа відхиляє трафік, що не йде через цей пакет. Блокування видно як системний стан, а не як помилка застосунку: інші застосунки профілю теж перестають діставатися мережі.

Обсяг важливий. VPN «завжди ввімкнено» налаштовується для кожного користувача, тож пакет робочого профілю не покриває ваш особистий профіль, а особистий VPN не задовольняє пакет робочого профілю. Два профілі, дві незалежні мережеві політики, один пристрій.

Це також єдиний рівень, де сторонній VPN не може допомогти, бо політика називає один конкретний пакет.

Як розрізнити три

Пройдіть ознаки по черзі й зупиніться на першій, що підходить. Якщо одне ім’я хоста не працює, а все інше розв’язується, це вказує на шлях служби. Негайна відмова під час запуску з формулюванням політики вказує на логіку застосунку. Якщо весь профіль втрачає зв’язок щоразу, коли відключається схвалений клієнт, це вказує на блокування. А застосунок, який приймає будь-який тунель, перевіряє прапор транспорту, а не ідентичність вашої організації.

Корисні докази: точний текст і його час, чи ще мають зв’язок інші застосунки того самого профілю, чи розв’язується приватне ім’я всередині схваленого тунелю і чи показує пристрій робочий значок для відкритого вами застосунку.

Що вказати в запиті до підтримки

Запит, у якому названо рівень, скеровується правильно з першої спроби. Приблизно так: застосунок робочого профілю відкривається, список ресурсів не працює після підключення схваленого VPN, розв’язання приватного імені не працює в дозволеній діагностиці, а інші застосунки профілю продовжують працювати. Це читається як проблема маршруту або розв’язувача і дає змогу оминути цикл скидання облікового запису.

Якщо схваленого VPN взагалі немає, підтримуваний шлях це реєстрація або повторне розгортання через вашого адміністратора. Видалення профілю керування, встановлення стороннього клієнта або підробка стану мережі змінює схему безпеки, а не відновлює її.

Почніть із рівня, а не з клієнта. Три ознаки вище зазвичай вирішують це за одну сесію.