Sådan læser du VPN- og proxy-tilstanden for en administreret arbejdsapp

En arbejdsapp fejler på en administreret telefon, nogen tjekker VPN-kontakten, ser at den er tændt, og erklærer ruten sund. Det er her de fleste af disse diagnoser stopper, og det er for tidligt: en aktiv VPN-transport siger ikke, at denne apps anmodninger brugte den, og den proxy, der faktisk gælder, kan være per app eller valgt af en PAC-fil i stedet for at vises i Indstillinger. Begynd med den konkrete app og profil, du fejlretter, og læs derefter platformens eget syn på ruten.

Begynd med appen og dens profil

En app med arbejdsmærke kører normalt i en separat profil med sin egen netværkspolitik. En personlig browser på samme telefon er ikke bevis for den, og det er et resultat fra en kollegas enhed med anden administration heller ikke. Bemærk, hvilken profil appen hører til, før du læser noget.

I Indstillinger skal du liste de konfigurerede VPN-poster og bemærke, hvem der ejer hver. På Samsung-builds flytter menuetiketterne sig mellem versioner, så beskriv posten i stedet for vejen til den. En grå eller administreret post tilhører den, der administrerer enheden; at slå den fra som eksperiment ændrer det, du prøver at måle, og kan være imod politikken.

Læs den tilstand, platformen rapporterer

Inde i en eksisterende aktivitet i dit supportværktøj, på API 23 eller nyere, kan netværkstilstanden læses uden at sende en byte. Kaldet kræver den normale ACCESS_NETWORK_STATE-manifesttilladelse til kapacitetslæsningen.

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 værdi besvarer et snævert spørgsmål. Det aktive netværk er standardnetværket for den kaldende proces på det tidspunkt. Kapacitetstjekket fortæller, om dette standardnetværk er VPN-understøttet. Proxy-kaldet rapporterer den effektive standard-HTTP-proxy, og det returnerede objekt kan beskrive enten en statisk proxy eller et PAC-script.

Hvis du har brug for visningen per netværk i stedet for standarden, skal du læse linkegenskaberne for det samme netværk og sammenligne med cm.getLinkProperties(network)?.httpProxy. En proxy installeret af enhedsstyringen vises i standard-proxy-kaldet og ikke i linkegenskaberne, hvilket er en hurtig måde at skelne en politikleveret proxy fra en, som netværket udleverede.

Hold outputtet i din supportkanal i stedet for i en offentlig rapport. Proxy-værtsnavne, PAC-URL'er og interne suffikser afslører, hvordan din organisation dirigerer trafik, og ingen af dem er nødvendige for at beskrive fejlen.

Fortolk hvert felt snævert

Et nul-netværk eller et nul-kapacitetsobjekt betyder, at den kaldendes netværkstilstand var utilgængelig eller ændrede sig under læsningen. Det betyder ikke, at der ikke er nogen VPN. Behandl det som ukendt, og læs igen, efter at appen er kommet i forgrunden, i stedet for som et negativt resultat.

En VPN-transport er den svageste af de positive. Enhver app, der holder en VpnService, producerer en, inklusive en lokal filtreringsapp, der aldrig sender din trafik nogen steder. Så en sand værdi siger, at der findes et VPN-understøttet standardnetværk, ikke at din organisations udgang blev brugt, og bestemt ikke at der skete inspektion.

En nul-standardproxy betyder, at denne API ikke rapporterer nogen standard-HTTP-proxy for den effektive konfiguration. Den udelukker meget lidt: en app kan have sin egen SOCKS-indstilling, implementere sin egen HTTP-klient eller styres af en proxy ved gatewayen, som enheden aldrig får kendskab til.

PAC er det tilfælde, der besejrer et enkeltværdi-svar. Et script kan rute én destination gennem en proxy og sende en anden direkte, så to anmodninger fra den samme app inden for et sekund kan tage forskellige veje. Og en app, der binder sine sockets til et valgt netværk eller kalder bindProcessToNetwork, er slet ikke forpligtet til at følge standarden.

Hvad dette øjebliksbillede ikke kan fortælle dig

Det er ikke en historik. Intet her registrerer, hvilken vej den fejlende anmodning tog, og en vellykket læsning efter fejlen er ikke bevis om fejlen. Det er heller ikke en fortegnelse: du får den kaldende proces' standardnetværk, ikke en liste over hver apps private forbindelser.

Det siger heller intet om, hvad der sker over socketen. Et TLS-håndtryk, der fejler på en administreret enhed, kan være et problem med tillidslageret, en pinning-uoverensstemmelse eller et navn, som proxyen afviser, og ingen af dem vises i en forbindelseslæsning.

Det er derfor, de to halvdele betyder noget sammen: øjebliksbilledet indsnævrer, hvor man skal kigge, og appens egen diagnostik siger, hvad der faktisk fejlede.

Rapportér det i en form, en administrator kan bruge

Angiv den berørte app, profilen, tidsstemplet og det præcise trin, der fejlede: navneopløsning, TCP-forbindelse, TLS-håndtryk eller en HTTP-status. Tilføj øjebliksbilledets værdier, som de blev læst, med nuller skrevet som nuller i stedet for som ingen. Bemærk, om andre apps i samme profil fejler på samme måde, hvilket adskiller et app-problem fra et profilomfattende rute-problem.

Stop derefter, og lad rutenes ejer svare. Behandl ikke et virksomhedscertifikat, en proxyadresse eller en VPN-post som tilladelse til at fjerne administration eller omgå den godkendte rute; det gør en supportsag til en politikhændelse.

Standard-proxy-kontrakten er kort og værd at læse én gang, fordi den definerer præcis, hvilken proxy kaldet rapporterer, og enhver overfortolkning af dette øjebliksbillede begynder med at antage, at det rapporterer mere.