Slik leser du VPN- og proxy-tilstanden for en administrert arbeidsapp

En arbeidsapp feiler på en administrert telefon, noen sjekker VPN-bryteren, ser at den er på og erklærer banen sunn. Det er her de fleste av disse diagnosene stopper, og det er for tidlig: en aktiv VPN-transport sier ikke at denne appens forespørsler brukte den, og proxyen som faktisk gjelder kan være per app eller valgt av en PAC-fil i stedet for å vises i Innstillinger. Start med den konkrete appen og profilen du feilsøker, og les deretter plattformens eget syn på banen.

Start med appen og profilen dens

En app med arbeidsmerke kjører vanligvis i en egen profil med sin egen nettverkspolicy. En personlig nettleser på samme telefon er ikke bevis for den, og det er heller ikke et resultat fra en kollegas enhet med annen administrasjon. Noter hvilken profil appen hører til før du leser noe.

I Innstillinger, list opp de konfigurerte VPN-oppføringene og noter hvem som eier hver. På Samsung-bygg flytter menyetikettene seg mellom versjoner, så beskriv oppføringen i stedet for veien til den. En grå eller administrert oppføring tilhører den som administrerer enheten; å slå den av som et eksperiment endrer det du prøver å måle og kan være i strid med policyen.

Les tilstanden plattformen rapporterer

Inne i en eksisterende aktivitet i støtteverktøyene dine, på API 23 eller nyere, kan nettverkstilstanden leses uten å sende en eneste byte. Kallet trenger den vanlige ACCESS_NETWORK_STATE-manifesttillatelsen for kapasitetslesingen.

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

Hver verdi svarer på et smalt spørsmål. Det aktive nettverket er standardnettverket for den kallende prosessen i det øyeblikket. Kapasitetssjekken forteller deg om det standardnettverket er VPN-støttet. Proxykallet rapporterer den effektive standard-HTTP-proxyen, og objektet som returneres kan beskrive enten en statisk proxy eller et PAC-skript.

Hvis du trenger visningen per nettverk i stedet for standarden, les linkegenskapene til samme nettverk og sammenlign med cm.getLinkProperties(network)?.httpProxy. En proxy installert av enhetsadministrasjonen vises i standard-proxykallet og ikke i linkegenskapene, noe som er en rask måte å skille en proxy gitt av policyen fra en nettverket delte ut.

Hold utdataene i støttekanalen din i stedet for i en offentlig rapport. Proxy-vertsnavn, PAC-URL-er og interne suffikser avslører hvordan organisasjonen din ruter trafikk, og ingen av dem trengs for å beskrive feilen.

Tolk hvert felt smalt

Et nullnettverk eller et nullkapasitetsobjekt betyr at den kallende partens nettverkstilstand ikke var tilgjengelig eller endret seg under lesingen. Det betyr ikke at det ikke finnes VPN. Behandle det som ukjent og les på nytt etter at appen har kommet i forgrunnen, ikke som et negativt resultat.

En VPN-transport er det svakeste av de positive. Enhver app som holder en VpnService produserer en, inkludert en lokal filtreringsapp som aldri sender trafikken din noe sted. Så en sann verdi sier at det finnes et VPN-støttet standardnettverk, ikke at organisasjonens utgang ble brukt og absolutt ikke at inspeksjon fant sted.

En null standardproxy betyr at denne API-en ikke rapporterer noen standard-HTTP-proxy for den effektive konfigurasjonen. Den utelukker svært lite: en app kan ha sin egen SOCKS-innstilling, implementere sin egen HTTP-klient eller styres av en proxy ved gatewayen som enheten aldri får vite om.

PAC er tilfellet som slår et enkeltverdi-svar. Et skript kan rute én destinasjon gjennom en proxy og sende en annen direkte, så to forespørsler fra samme app innen ett sekund kan ta ulike veier. Og en app som binder socketene sine til et valgt nettverk, eller kaller bindProcessToNetwork, er slett ikke forpliktet til å følge standarden.

Hva dette øyeblikksbildet ikke kan fortelle deg

Dette er ikke en historie. Ingenting her registrerer hvilken vei den feilende forespørselen tok, og en vellykket lesing etter feilen er ikke bevis om feilen. Det er heller ikke en oversikt: du får standardnettverket til den kallende prosessen, ikke en liste over hver apps private forbindelser.

Det sier heller ingenting om hva som skjer over socketen. En TLS-håndtrykk som feiler på en administrert enhet kan være et problem med tillitslageret, et pinning-avvik eller et navn som proxyen avviser, og ingen av dem vises i en tilkoblingslesing.

Derfor teller de to halvdelene sammen: øyeblikksbildet snevrer inn hvor man skal se, og appens egen diagnostikk sier hva som faktisk feilet.

Rapporter det i en form en administrator kan bruke

Oppgi den berørte appen, profilen, tidsstempelet og det nøyaktige trinnet som feilet: navneoppslag, TCP-tilkobling, TLS-håndtrykk eller en HTTP-status. Legg til øyeblikksbildets verdier slik de ble lest, med nuller skrevet som nuller og ikke som ingen. Noter om andre apper i samme profil feiler på samme måte, noe som skiller et app-problem fra et profilomfattende baneproblem.

Stopp deretter og la eieren av banen svare. Ikke behandle et bedriftssertifikat, en proxyadresse eller en VPN-oppføring som tillatelse til å fjerne administrasjon eller omgå den godkjente ruten; det gjør en støttesak til en policyhendelse.

Standard-proxy-kontrakten er kort og verdt å lese én gang, fordi den definerer nøyaktig hvilken proxy kallet rapporterer, og enhver overlesing av dette øyeblikksbildet begynner med å anta at det rapporterer mer.