Работното приложение изисква 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 липсва напълно, поддържаният път е записване или повторно осигуряване чрез вашия администратор. Премахването на профила за управление, инсталирането на несвързан клиент или фалшифицирането на мрежовото състояние променя схемата за сигурност, вместо да я възстанови.
Започнете със слоя, не с клиента. Трите подписа по-горе обикновено решават въпроса в една сесия.