Как да четем състоянието на VPN и прокси за управлявано работно приложение

Работно приложение се проваля на управляван телефон, някой проверява превключвателя за VPN, вижда го включен и обявява пътя за здрав. Тук спират повечето от тези диагностики и това е твърде рано: активен VPN транспорт не означава, че заявките на това приложение са минали през него, а проксито, което действително се прилага, може да е за отделно приложение или избрано от PAC файл, вместо да е показано в Настройки. Започнете от конкретното приложение и профил, които отстранявате, после прочетете собствения изглед на платформата към пътя.

Започнете от приложението и неговия профил

Приложение с работна значка обикновено работи в отделен профил със своя мрежова политика. Личният браузър на същия телефон не е доказателство за него, нито резултат от устройството на колега с различно управление. Отбележете към кой профил принадлежи приложението, преди да прочетете каквото и да е.

В Настройки избройте конфигурираните записи за VPN и отбележете кой притежава всеки. При изданията на Samsung етикетите на менюто се местят между версиите, затова описвайте записа, а не пътя до него. Сив или управляван запис принадлежи на този, който администрира устройството; изключването му като експеримент променя това, което се опитвате да измерите, и може да е срещу политиката.

Прочетете състоянието, което платформата докладва

Вътре в съществуваща активност в инструментите ви за поддръжка, на API 23 или по-късно, състоянието на мрежата може да се прочете, без да се изпрати байт. Извикването изисква обичайното разрешение в манифеста ACCESS_NETWORK_STATE за четене на възможностите.

val cm = getSystemService(android.net.ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val caps = network?.let { cm.getNetworkCapabilities(it) }
val hasVpn = caps?.hasTransport(android.net.NetworkCapabilities.TRANSPORT_VPN)
val proxy = cm.defaultProxy

Всяка стойност отговаря на тесен въпрос. Активната мрежа е мрежата по подразбиране за извикващия процес в този момент. Проверката на възможностите ви казва дали тази мрежа по подразбиране е с VPN. Извикването на проксито съобщава действителното HTTP прокси по подразбиране и върнатият обект може да описва или статично прокси, или PAC скрипт.

Ако ви трябва изгледът за отделна мрежа вместо този по подразбиране, прочетете свойствата на връзката на същата мрежа и сравнете с cm.getLinkProperties(network)?.httpProxy. Прокси, инсталирано от управлението на устройството, се показва в извикването на проксито по подразбиране и не се показва в свойствата на връзката, което е бърз начин да различите прокси, предоставено от политика, от такова, което мрежата е дала.

Пазете изхода в канала си за поддръжка, а не в публичен доклад. Имената на прокси хостове, адресите PAC и вътрешните суфикси разкриват как организацията ви насочва трафика и нито едно от тях не е нужно, за да се опише повредата.

Тълкувайте всяко поле тясно

Нулева мрежа или нулев обект за възможности означава, че състоянието на мрежата на извикващия е било недостъпно или се е променило по време на четенето. Това не означава, че няма VPN. Отнасяйте се към него като към неизвестно и прочетете отново, след като приложението е на преден план, а не като към отрицателен резултат.

VPN транспортът е най-слабото от положителните. Всяко приложение, което държи VpnService, създава такъв, включително локално приложение за филтриране, което никога не изпраща трафика ви никъде. Затова стойност true казва, че съществува мрежа по подразбиране с VPN, а не че е използван изходът на организацията ви и със сигурност не че е имало инспекция.

Нулево прокси по подразбиране означава, че този API не докладва HTTP прокси по подразбиране за действителната конфигурация. То изключва много малко: приложението може да носи своя настройка SOCKS, да реализира свой HTTP клиент или да бъде насочвано от прокси на шлюза, за което устройството никога не научава.

PAC е случаят, който побеждава отговора с една стойност. Скриптът може да насочи една дестинация през прокси и да изпрати друга директно, така че две заявки от едно и също приложение в рамките на секунда може да поемат различни пътища. А приложение, което обвързва сокетите си с избрана мрежа или извиква bindProcessToNetwork, изобщо не е длъжно да следва стойността по подразбиране.

Какво не може да ви каже тази снимка

Тя не е история. Тук нищо не записва кой път е поела заявката, която се проваля, и успешно четене след провала не е доказателство за провала. Тя също не е инвентар: получавате мрежата по подразбиране на извикващия процес, а не списък с частните връзки на всяко приложение.

Тя не казва нищо и за това, което се случва над сокета. TLS ръкостискане, което се проваля на управлявано устройство, може да е проблем със хранилището за доверие, несъответствие при закрепването или име, което проксито отказва, и нито едно от тях не се появява в четене на свързаността.

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

Докладвайте го във форма, която администраторът може да използва

Дайте засегнатото приложение, профила, времевата марка и точния етап, който се е провалил: разрешаване на име, TCP връзка, TLS ръкостискане или HTTP статус. Добавете стойностите от снимката така, както са прочетени, с нулеви стойности, записани като нулеви, а не като нищо. Отбележете дали други приложения в същия профил се провалят по същия начин, което отделя проблем в приложението от проблем в пътя за целия профил.

После спрете и оставете собственика на пътя да отговори. Не приемайте корпоративен сертификат, адрес на прокси или запис за VPN като разрешение да премахнете управлението или да заобиколите одобрения маршрут; това превръща случай за поддръжка в инцидент по политиката.

Договорът за проксито по подразбиране е кратък и си струва едно четене, защото определя точно кое прокси докладва извикването, и всяко прекалено четене на тази снимка започва с допускането, че тя докладва повече.