Korleis lese VPN- og proxy-tilstanden for ein administrert arbeidsapp

Ein arbeidsapp feilar på ein administrert telefon, nokon sjekkar VPN-brytaren, ser at han er på og erklærer vegen sunn. Det er her dei fleste av desse diagnosane stoppar, og det er for tidleg: ein aktiv VPN-transport seier ikkje at førespurnadene til denne appen brukte han, og proxyen som faktisk gjeld kan vere per app eller vald av ei PAC-fil i staden for å visast i Innstillingar. Start med den konkrete appen og profilen du feilsøkjer, og les deretter det eigne synet til plattforma på vegen.

Start med appen og profilen hans

Ein app med arbeidsmerke køyrer vanlegvis i ein eigen profil med si eiga nettverkspolicy. Ein personleg nettlesar på same telefon er ikkje bevis for han, og det er heller ikkje eit resultat frå eininga til ein kollega med anna administrasjon. Noter kva profil appen høyrer til før du les noko.

I Innstillingar, list opp dei konfigurerte VPN-oppføringane og noter kven som eig kvar. På Samsung-bygg flyttar menyetiketane seg mellom versjonar, så skildre oppføringa i staden for vegen til ho. Ei grå eller administrert oppføring høyrer til den som administrerer eininga; å slå ho av som eit eksperiment endrar det du prøver å måle og kan vere i strid med policyen.

Les tilstanden plattforma rapporterer

Inne i ein eksisterande aktivitet i støtteverktøya dine, på API 23 eller nyare, kan nettverkstilstanden lesast utan å sende ein einaste byte. Kallet treng den vanlege ACCESS_NETWORK_STATE-manifestløyva for kapasitetslesinga.

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

Kvar verdi svarar på eit smalt spørsmål. Det aktive nettverket er standardnettverket for den kallande prosessen i det augneblinken. Kapasitetssjekken fortel deg om det standardnettverket er VPN-støtta. Proxykallet rapporterer den effektive standard-HTTP-proxyen, og objektet som blir returnert kan skildre anten ein statisk proxy eller eit PAC-skript.

Viss du treng visinga per nettverk i staden for standarden, les lenkjeegenskapane til same nettverk og samanlikn med cm.getLinkProperties(network)?.httpProxy. Ein proxy installert av eininga si administrasjon viser seg i standard-proxykallet og ikkje i lenkjeegenskapane, noko som er ein rask måte å skilje ein proxy gitt av policyen frå ein nettverket delte ut.

Hald utdata i støttekanalen din i staden for i ein offentleg rapport. Proxy-vertsnamn, PAC-URL-ar og interne suffiks avslører korleis organisasjonen din rutar trafikk, og ingen av dei trengst for å skildre feilen.

Tolk kvart felt smalt

Eit nullnettverk eller eit nullkapasitetsobjekt betyr at nettverkstilstanden til den kallande parten ikkje var tilgjengeleg eller endra seg under lesinga. Det betyr ikkje at det ikkje finst VPN. Handsame det som ukjent og les på nytt etter at appen har kome i framgrunnen, ikkje som eit negativt resultat.

Ein VPN-transport er det svakaste av dei positive. Kvar app som held ein VpnService produserer ein, inkludert ein lokal filtreringsapp som aldri sender trafikken din nokon stad. Så ein sann verdi seier at det finst eit VPN-støtta standardnettverk, ikkje at utgangen til organisasjonen vart brukt og absolutt ikkje at inspeksjon fann stad.

Ein null standardproxy betyr at denne API-en ikkje rapporterer nokon standard-HTTP-proxy for den effektive konfigurasjonen. Han utelukkar svært lite: ein app kan ha si eiga SOCKS-innstilling, implementere sin eigen HTTP-klient eller styrast av ein proxy ved gatewayen som eininga aldri får vite om.

PAC er tilfellet som slår eit eittverdi-svar. Eit skript kan rute ein destinasjon gjennom ein proxy og sende ein annan direkte, så to førespurnader frå same app innan eitt sekund kan ta ulike vegan. Og ein app som bind sokkane sine til eit valt nettverk, eller kallar bindProcessToNetwork, er slett ikkje forplikta til å følgje standarden.

Kva dette augeblinksbiletet ikkje kan fortelje deg

Dette er ikkje ei historie. Ingenting her registrerer kva veg den feilande førespurnaden tok, og ei vellukka lesing etter feilen er ikkje bevis om feilen. Det er heller ikkje ei oversikt: du får standardnettverket til den kallande prosessen, ikkje ei liste over dei private sambanda til kvar app.

Det seier heller ingenting om kva som skjer over sokkelen. Eit TLS-handtrykk som feilar på ei administrert eining kan vere eit problem med tillitslageret, eit pinning-avvik eller eit namn som proxyen avviser, og ingen av dei viser seg i ei tilkoplingslesing.

Derfor tel dei to halvdelane saman: augeblinksbiletet snevrar inn kvar ein skal sjå, og eigen diagnostikk i appen seier kva som faktisk feila.

Rapporter det i ei form ein administrator kan bruke

Oppgi den råka appen, profilen, tidsstempelet og det nøyaktige trinnet som feila: namneoppslag, TCP-tilkopling, TLS-handtrykk eller ein HTTP-status. Legg til verdiane frå augeblinksbiletet slik dei vart lesne, med nullar skrivne som nullar og ikkje som ingen. Noter om andre appar i same profil feilar på same måte, noko som skil eit app-problem frå eit profilomfattande vegproblem.

Stopp deretter og la eigaren av vegen svare. Ikkje handsame eit verksemdssertifikat, ei proxyadresse eller ei VPN-oppføring som løyve til å fjerne administrasjon eller omgå den godkjende ruta; det gjer ei støttesak til ei policyhending.

Standard-proxy-kontrakten er kort og verdt å lese éin gong, fordi han definerer nøyaktig kva proxy kallet rapporterer, og kvar overlesing av dette augeblinksbiletet byrjar med å anta at det rapporterer meir.