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

Уговор о подразумеваном проксију је кратак и вреди га једном прочитати, јер тачно одређује који прокси позив пријављује, и свако претерано читање овог снимка почиње претпоставком да пријављује више.