Så läser du VPN- och proxy-status för en hanterad arbetsapp

En arbetsapp misslyckas på en hanterad telefon, någon kontrollerar VPN-brytaren, ser att den är på och förklarar vägen frisk. Det är här de flesta av dessa diagnoser stannar, och det är för tidigt: en aktiv VPN-transport säger inte att den här appens förfrågningar använde den, och proxyn som faktiskt gäller kan vara per app eller väljas av en PAC-fil i stället för att visas i Inställningar. Börja med den specifika appen och profilen du felsöker och läs sedan plattformens egen syn på vägen.

Börja med appen och dess profil

En app med arbetsmärke körs vanligtvis i en separat profil med sin egen nätverkspolicy. En personlig webbläsare på samma telefon är inte bevis för den, och det är inte heller ett resultat från en kollegas enhet med annan hantering. Notera vilken profil appen hör till innan du läser något.

I Inställningar, lista de konfigurerade VPN-posterna och notera vem som äger varje. På Samsung-byggen flyttar menyetiketterna mellan versioner, så beskriv posten i stället för vägen till den. En grå eller hanterad post tillhör den som administrerar enheten; att stänga av den som ett experiment ändrar det du försöker mäta och kan strida mot policyn.

Läs tillståndet som plattformen rapporterar

Inne i en befintlig aktivitet i dina supportverktyg, på API 23 eller senare, kan nätverkstillståndet läsas utan att skicka en enda byte. Anropet behöver det vanliga ACCESS_NETWORK_STATE-manifesttillståndet för 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

Varje värde svarar på en smal fråga. Det aktiva nätverket är standardnätverket för den anropande processen i det ögonblicket. Kapacitetskontrollen berättar om det standardnätverket är VPN-stött. Proxyanropet rapporterar den effektiva standard-HTTP-proxyn, och objektet som returneras kan beskriva antingen en statisk proxy eller ett PAC-skript.

Om du behöver vyn per nätverk i stället för standard, läs länkegenskaperna för samma nätverk och jämför med cm.getLinkProperties(network)?.httpProxy. En proxy som installeras av enhetshanteringen visas i standardproxyanropet och inte i länkegenskaperna, vilket är ett snabbt sätt att skilja en proxy från policyn från en som nätverket tilldelade.

Håll utdata i din supportkanal i stället för i en offentlig rapport. Proxyvärdnamn, PAC-URL:er och interna suffix avslöjar hur din organisation dirigerar trafik, och ingen av dem behövs för att beskriva felet.

Tolka varje fält snävt

Ett nollnätverk eller ett nollkapacitetsobjekt betyder att den anropande partens nätverkstillstånd inte var tillgängligt eller ändrades under läsningen. Det betyder inte att det inte finns någon VPN. Behandla det som okänt och läs igen efter att appen har kommit i förgrunden, inte som ett negativt resultat.

En VPN-transport är den svagaste av de positiva. Varje app som håller en VpnService producerar en, inklusive en lokal filtreringsapp som aldrig skickar din trafik någonstans. Så ett sant värde säger att ett VPN-stött standardnätverk finns, inte att organisationens utgång användes och absolut inte att inspektion ägde rum.

En nollstandardproxy betyder att detta API inte rapporterar någon standard-HTTP-proxy för den effektiva konfigurationen. Det utesluter mycket lite: en app kan bära sin egen SOCKS-inställning, implementera sin egen HTTP-klient eller styras av en proxy vid gatewayen som enheten aldrig får kännedom om.

PAC är fallet som besegrar ett svar med ett enda värde. Ett skript kan dirigera en destination via en proxy och skicka en annan direkt, så två förfrågningar från samma app inom en sekund kan ta olika vägar. Och en app som binder sina sockets till ett valt nätverk, eller anropar bindProcessToNetwork, är inte alls skyldig att följa standarden.

Vad denna ögonblicksbild inte kan berätta

Detta är inte en historik. Ingenting här registrerar vilken väg den misslyckade förfrågan tog, och en lyckad läsning efter felet är inte bevis om felet. Det är inte heller en inventering: du får standardnätverket för den anropande processen, inte en lista över varje apps privata anslutningar.

Det säger inte heller något om vad som händer ovanför socketen. En TLS-handskakning som misslyckas på en hanterad enhet kan vara ett problem med förtroendelagret, en pinning-avvikelse eller ett namn som proxyn avvisar, och ingen av dem visas i en anslutningsläsning.

Därför räknas de två halvorna tillsammans: ögonblicksbilden snävar in var man ska titta, och appens egen diagnostik säger vad som faktiskt misslyckades.

Rapportera det i en form en administratör kan använda

Ange den berörda appen, profilen, tidsstämpeln och det exakta steget som misslyckades: namnmatchning, TCP-anslutning, TLS-handskakning eller en HTTP-status. Lägg till ögonblicksbildens värden så som de lästes, med nollor skrivna som nollor och inte som ingen. Notera om andra appar i samma profil misslyckas på samma sätt, vilket skiljer ett app-problem från ett profilomfattande vägproblem.

Stanna sedan och låt ägaren av vägen svara. Behandla inte ett företagscertifikat, en proxyadress eller en VPN-post som tillstånd att ta bort hanteringen eller kringgå den godkända rutten; det gör ett supportärende till en policyincident.

Standardproxyavtalet är kort och värt att läsa en gång, eftersom det definierar exakt vilken proxy anropet rapporterar, och varje överläsning av denna ögonblicksbild börjar med antagandet att den rapporterar mer.