Hoe om die VPN- en proxystatus van 'n beheerde werkprogram te lees

'n Werkprogram faal op 'n beheerde telefoon, iemand kyk na die VPN-kies, sien dit is aan, en verklaar die pad gesond. Dit is waar die meeste van hierdie diagnoses stop, en dit is te vroeg: 'n aktiewe VPN-vervoer sê nie dat hierdie program se versoeke dit gebruik het nie, en die proxy wat werklik geld, kan per program geld of deur 'n PAC-lêer gekeur word eerder as om in Instellings te verskyn. Begin by die spesifieke program en profiel wat jy foutsoek, en lees dan die platform se eie siening van die pad.

Begin by die program en sy profiel

'n Werkprogram met 'n werkkenteken loop gewoonlik in 'n aparte profiel met sy eie netwerkbeleid. 'n Persoonlike blaaier op dieselfde telefoon is nie bewyse daarvoor nie, en 'n resultaat van 'n kollega se toestel met ander beheer is dit ook nie. Merk aan watter profiel die program hoort voordat jy enigiets lees.

In Instellings, lys die ingestelde VPN-inskrywings en merk op wie elkeen besit. Op Samsung-weergawes verskuif die menu-etikette tussen uitgawes, so beskryf die inskrywing eerder as die pad daarheen. 'n Gry of beheerde inskrywing hoort aan wie ook al die toestel administreer; om dit as eksperiment uit te skakel verander die ding wat jy probeer meet en kan teen die beleid wees.

Lees die toestand wat die platform rapporteer

Binne 'n bestaande aktiwiteit in jou ondersteuningsinstrumente, op API 23 of later, kan die netwerktoestand gelees word sonder om 'n greep te stuur. Die opruf het die normale ACCESS_NETWORK_STATE manifest-toestemming nodig vir die vermoëlees.

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

Elke waarde beantwoord 'n nou vraag. Die aktiewe netwerk is die standaardnetwerk vir die oprufproses op daardie oomblik. Die vermoëtoets vertel jou of daardie standaardnetwerk op VPN steun. Die proxy-opruf rapporteer die effektiewe standaard-HTTP-proxy, en 'n teruggestuurde objek kan óf 'n statiese proxy óf 'n PAC-skrip beskryf.

Indien jy die siening per netwerk eerder as die standaard nodig het, lees die koppel-eienskappe van dieselfde netwerk en vergelyk met cm.getLinkProperties(network)?.httpProxy. 'n Proxy wat deur toestelbeheer geïnstalleer is, verskyn in die standaard-proxy-opruf en nie in die koppel-eienskappe nie, wat 'n vinnige manier is om 'n beleidsgelewerde proxy van een wat die netwerk uitgedeel het, te onderskei.

Hou die uitset in jou ondersteuningskanaal eerder as in 'n openbare rapport. Proxy-gastename, PAC-URL'e en interne agtervoegsels verraai hoe jou organisasie verkeer roetebeneem, en nie een van hulle is nodig om die fout te beskryf nie.

Vertolk elke veld eng

'n Nulnetwerk of 'n nul-vermoëobjek beteken die oprufproses se netwerktoestand was onbeskikbaar of het gedurende die lees verander. Dit beteken nie daar is geen VPN nie. Behandel dit as onbekend en lees weer nadat die program in die voorgrond geplaas is, eerder as as 'n negatiewe resultaat.

'n VPN-vervoer is die swakste van die positiewe aanduidinge. Enige program met 'n VpnService produseer een, insluitend 'n plaaslike filtreerprogram wat jou verkeer nêrens heen stuur nie. Dus 'n ware waarde sê 'n VPN-ondersteunde standaardnetwerk bestaan, nie dat jou organisasie se uitgang gebruik was nie, en beslist nie dat inspeksie plaasgevind het nie.

'n Nul-standaardproxy beteken dat hierdie API geen standaard-HTTP-proxy vir die effektiewe konfigurasie rapporteer nie. Dit sluit baie min uit: 'n program kan sy eie SOCKS-instelling dra, sy eie HTTP-kliënt implementeer, of deur 'n proxy aan die gateway gestuur word wat die toestel nooit leer ken nie.

PAC is die geval wat 'n eenwaarde-antwoord verslaan. 'n Skrip kan een bestemming deur 'n proxy roetebeneem en 'n ander direk stuur, so twee versoeke van dieselfde program binne 'n sekonde kan verskillende paaie neem. En 'n program wat sy sokette aan 'n gekeurde netwerk bind, of bindProcessToNetwork opruf, is glad nie verplig om die standaard te volg nie.

Wat hierdie momentopname jou nie kan sê nie

Dit is nie 'n geskiedenis nie. Niks hier leg vas watter pad die foutende versoek geneem het nie, en 'n suksesvolle lees na die fout is nie bewyse oor die fout nie. Dit is ook nie 'n inventaris nie: jy kry die oprufproses se standaardnetwerk, nie 'n lys van elke program se privaat verbindings nie.

Dit sê ook niks oor wat bo die soket gebeur nie. 'n TLS-handdruk wat op 'n beheerde toestel faal, kan 'n trust-store-probleem, 'n pinning-mismatch of 'n naam wat die proxy weier, wees, en nie een van dié verskyn in 'n verbindinglees nie.

Dit is waarom die twee helftes saam saak maak: die momentopname vernou waar om te kyk, en die program se eie diagnostiek sê wat werklik gefaal het.

Rapporteer dit in 'n vorm wat 'n administrateur kan gebruik

Gee die betrokke program, die profiel, die tydstempel en die presiese stap wat gefaal het: naamresolusie, TCP-verbinding, TLS-handdruk of 'n HTTP-status. Voeg die momentopname-waardes by soos hulle gelees was, met nulle as nulle geskryf en nie as 'n woord soos geen nie. Merk of ander programme in dieselfde profiel op dieselfde manier faal, wat 'n programprobleem van 'n profielbrede padprobleem skei.

Stop dan en laat die eienaar van die pad antwoord. Behandel nie 'n korporatiewe sertifikaat, 'n proxy-adres of 'n VPN-inskrywing as toestemming om beheer te verwyder of die goedgekeurde roete te omseil nie; dit omskep 'n ondersteuningsaak in 'n beleidsinsident.

Die standaard-proxy-kontrak is kort en werd om een keer te lees, want dit bepaal presies watter proxy die opruf rapporteer, en elke oormoedige lesing van hierdie momentopname begin met die aanname dat dit meer rapporteer.