Како да го читате статусот на 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 запис како дозвола да се отстрани управувањето или да се заобиколи одобрената рута; тоа го претвора случајот за поддршка во инцидент со политика.

Договорот за стандардно прокси е краток и вреди едно читање, бидејќи точно одредува кое прокси го пријавува повикот, и секое претерано читање на оваа снимка започнува со претпоставката дека пријавува повеќе.