Hoe je de VPN- en proxystatus van een beheerde werk-app leest

Een werk-app faalt op een beheerde telefoon, iemand controleert de VPN-schakelaar, ziet dat die aan staat en verklaart het pad gezond. Daar stoppen de meeste van deze diagnoses, en dat is te vroeg: een actief VPN-transport zegt niet dat de verzoeken van deze app het hebben gebruikt, en de proxy die echt geldt kan per app zijn of door een PAC-bestand worden gekozen in plaats van in Instellingen te verschijnen. Begin bij de specifieke app en het profiel die je debugt en lees daarna de eigen kijk van het platform op het pad.

Begin bij de app en het profiel

Een app met een werkbadge draait meestal in een apart profiel met een eigen netwerkbeleid. Een persoonlijke browser op dezelfde telefoon is daar geen bewijs voor, en een resultaat van het apparaat van een collega met een ander beheer ook niet. Noteer bij welk profiel de app hoort voordat je iets leest.

In Instellingen, som de geconfigureerde VPN-vermeldingen op en noteer wie eigenaar is van elk. Bij Samsung-builds verschuiven de menulabels tussen releases, dus beschrijf de vermelding en niet het pad ernaartoe. Een grijze of beheerde vermelding is van degene die het apparaat beheert; hem als experiment uitzetten verandert wat je probeert te meten en kan tegen het beleid ingaan.

Lees de status die het platform rapporteert

Binnen een bestaande activiteit in je supporttooling, op API 23 of later, kan de netwerkstatus worden gelezen zonder een byte te verzenden. De aanroep heeft de normale ACCESS_NETWORK_STATE-manifesttoestemming nodig voor het lezen van mogelijkheden.

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 beantwoordt een smalle vraag. Het actieve netwerk is het standaardnetwerk voor het aanroepende proces op dat moment. De mogelijkheidscontrole vertelt je of dat standaardnetwerk VPN-ondersteund is. De proxy-aanroep rapporteert de effectieve standaard-HTTP-proxy, en het teruggegeven object kan zowel een statische proxy als een PAC-script beschrijven.

Als je de weergave per netwerk nodig hebt in plaats van de standaard, lees dan de linkeigenschappen van hetzelfde netwerk en vergelijk met cm.getLinkProperties(network)?.httpProxy. Een proxy die door apparaatbeheer is geïnstalleerd verschijnt in de standaard-proxy-aanroep en niet in de linkeigenschappen, wat een snelle manier is om een door beleid geleverde proxy te onderscheiden van een die het netwerk heeft gegeven.

Houd de uitvoer in je supportkanaal in plaats van in een openbaar rapport. Proxy-hostnamen, PAC-URL's en interne suffixen onthullen hoe je organisatie verkeer routeert, en geen ervan is nodig om de storing te beschrijven.

Interpreteer elk veld smal

Een null-netwerk of een null-mogelijkheidsobject betekent dat de netwerkstatus van de aanroeper niet beschikbaar was of tijdens het lezen veranderde. Het betekent niet dat er geen VPN is. Behandel het als onbekend en lees opnieuw nadat de app naar de voorgrond is gekomen, niet als een negatief resultaat.

Een VPN-transport is het zwakste van de positieve. Elke app die een VpnService heeft, produceert er een, inclusief een lokale filter-app die je verkeer nooit ergens heen stuurt. Dus een waarde true zegt dat er een VPN-ondersteund standaardnetwerk bestaat, niet dat de uitgang van je organisatie is gebruikt en zeker niet dat er inspectie heeft plaatsgevonden.

Een null-standaardproxy betekent dat deze API geen standaard-HTTP-proxy rapporteert voor de effectieve configuratie. Het sluit heel weinig uit: een app kan zijn eigen SOCKS-instelling meedragen, zijn eigen HTTP-client implementeren of worden gestuurd door een proxy bij de gateway waarvan het apparaat nooit iets leert.

PAC is het geval dat een antwoord met één waarde verslaat. Een script kan de ene bestemming via een proxy routeren en de andere direct versturen, zodat twee verzoeken van dezelfde app binnen een seconde verschillende paden kunnen nemen. En een app die zijn sockets aan een gekozen netwerk bindt, of bindProcessToNetwork aanroept, is helemaal niet verplicht de standaard te volgen.

Wat deze momentopname niet kan vertellen

Dit is geen geschiedenis. Niets hier legt vast welk pad het falende verzoek nam, en een geslaagde lezing na de fout is geen bewijs over de fout. Het is ook geen inventaris: je krijgt het standaardnetwerk van het aanroepende proces, niet een lijst van de privéverbindingen van elke app.

Het zegt ook niets over wat er boven de socket gebeurt. Een TLS-handshake die op een beheerd apparaat mislukt kan een probleem met de vertrouwensopslag zijn, een pinning-afwijking of een naam die de proxy weigert, en geen ervan verschijnt in een connectiviteitslezing.

Daarom tellen de twee helften samen: de momentopname vernauwt waar je moet kijken, en de eigen diagnostiek van de app zegt wat er werkelijk is misgegaan.

Rapporteer het in een vorm die een beheerder kan gebruiken

Geef de getroffen app, het profiel, de tijdstempel en de exacte fase die mislukte: naamresolutie, TCP-verbinding, TLS-handshake of een HTTP-status. Voeg de waarden van de momentopname toe zoals ze zijn gelezen, met nullen als nullen geschreven en niet als geen. Noteer of andere apps in hetzelfde profiel op dezelfde manier falen, wat een app-probleem scheidt van een padprobleem voor het hele profiel.

Stop dan en laat de eigenaar van het pad reageren. Behandel een bedrijfscertificaat, een proxyadres of een VPN-vermelding niet als toestemming om beheer te verwijderen of de goedgekeurde route te omzeilen; dat maakt van een supportcase een beleidsincident.

Het standaard-proxycontract is kort en een keer lezen waard, omdat het precies bepaalt welke proxy de aanroep rapporteert, en elke overdreven lezing van deze momentopname begint met de aanname dat het meer rapporteert.