Jak číst stav VPN a proxy u spravované pracovní aplikace

Pracovní aplikace selže na spravovaném telefonu, někdo zkontroluje přepínač VPN, vidí ho zapnutý a prohlásí cestu za zdravou. Tady většina těchto diagnostik končí, a to je příliš brzy: aktivní VPN transport neříká, že přes něj šly požadavky této aplikace, a proxy, která skutečně platí, může být pro jednotlivou aplikaci nebo zvolená souborem PAC, místo aby byla vidět v Nastavení. Začněte u konkrétní aplikace a profilu, které ladíte, a potom si přečtěte vlastní pohled platformy na cestu.

Začněte u aplikace a jejího profilu

Aplikace s pracovním odznakem obvykle běží ve zvláštním profilu s vlastní síťovou politikou. Osobní prohlížeč na stejném telefonu pro ni není důkazem, stejně jako není výsledek z kolegova zařízení s jinou správou. Než cokoli přečtete, poznamenejte si, do kterého profilu aplikace patří.

V Nastavení vypište nakonfigurované položky VPN a poznamenejte, komu každá patří. V sestaveních Samsungu se popisky nabídek mezi verzemi posouvají, proto popište položku, ne cestu k ní. Zešedlá nebo spravovaná položka patří tomu, kdo zařízení spravuje; vypnutí jako experiment mění to, co se snažíte změřit, a může být proti politice.

Přečtěte stav, který platforma hlásí

Uvnitř existující aktivity ve vašich podpůrných nástrojích, na API 23 nebo novějším, lze stav sítě přečíst, aniž by se odeslal bajt. Volání potřebuje běžné oprávnění manifestu ACCESS_NETWORK_STATE pro čtení schopností.

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

Každá hodnota odpovídá na úzkou otázku. Aktivní síť je výchozí síť volajícího procesu v daném okamžiku. Kontrola schopností říká, zda je tato výchozí síť podložená VPN. Volání proxy hlásí účinnou výchozí HTTP proxy a vrácený objekt může popisovat buď statickou proxy, nebo skript PAC.

Pokud potřebujete pohled po jednotlivých sítích místo výchozího, přečtěte vlastnosti spoje stejné sítě a porovnejte s cm.getLinkProperties(network)?.httpProxy. Proxy nainstalovaná správou zařízení se objeví ve volání výchozí proxy a ne ve vlastnostech spoje, což je rychlý způsob, jak rozlišit proxy danou politikou od proxy přidělené sítí.

Výstup uchovejte ve svém podpůrném kanálu, ne ve veřejné zprávě. Názvy proxy hostitelů, adresy PAC a interní přípony prozrazují, jak vaše organizace směruje provoz, a nic z toho není k popsání selhání potřeba.

Vykládejte každé pole úzce

Nulová síť nebo nulový objekt schopností znamená, že stav sítě volajícího nebyl dostupný nebo se během čtení změnil. To neznamená, že VPN není. Berte to jako neznámé a přečtěte znovu poté, co se aplikace dostala do popředí, ne jako negativní výsledek.

VPN transport je nejslabší z pozitiv. Každá aplikace, která drží VpnService, nějaký vytvoří, včetně místní filtrovací aplikace, která váš provoz nikam neposílá. Takže hodnota true říká, že existuje výchozí síť podložená VPN, ne že byl použit výstup vaší organizace a rozhodně ne že proběhla inspekce.

Nulová výchozí proxy znamená, že toto API nehlásí žádnou výchozí HTTP proxy pro účinnou konfiguraci. Vylučuje velmi málo: aplikace může mít vlastní nastavení SOCKS, implementovat vlastní HTTP klient, nebo být řízena proxy na bráně, o které se zařízení nikdy nedozví.

PAC je případ, který poráží odpověď s jednou hodnotou. Skript může jednu destinaci směrovat přes proxy a jinou poslat přímo, takže dva požadavky stejné aplikace během sekundy mohou jít různými cestami. A aplikace, která svá soketová spojení váže na zvolenou síť nebo volá bindProcessToNetwork, nemá povinnost následovat výchozí hodnotu vůbec.

Co vám tento snímek nemůže říct

Není to historie. Nic zde nezaznamenává, kterou cestou se vydal selhávající požadavek, a úspěšné čtení po selhání není důkazem o selhání. Není to ani inventář: dostanete výchozí síť volajícího procesu, ne seznam soukromých spojení každé aplikace.

Nic neříká ani o tom, co se děje nad soketem. TLS handshake, který na spravovaném zařízení selže, může být problém úložiště důvěry, neshoda pinningu nebo jméno, které proxy odmítá, a nic z toho se ve čtení konektivity neobjeví.

Proto platí obě poloviny společně: snímek zužuje, kam se dívat, a vlastní diagnostika aplikace říká, co skutečně selhalo.

Hlaste to ve formě, kterou správce může použít

Uveďte postiženou aplikaci, profil, časové razítko a přesnou fázi, která selhala: překlad názvů, spojení TCP, TLS handshake nebo stav HTTP. Přidejte hodnoty snímku tak, jak byly přečteny, s nulami zapsanými jako nuly, ne jako slovo nic. Poznamenejte, zda další aplikace ve stejném profilu selhávají stejně, což odděluje problém aplikace od problému cesty v celém profilu.

Potom přestaňte a nechte majitele cesty odpovědět. Neberte podnikový certifikát, adresu proxy ani položku VPN jako svolení odebrat správu nebo obejít schválenou trasu; to mění případ podpory v incident politiky.

smlouva o výchozí proxy je krátká a stojí za jedno přečtení, protože přesně určuje, kterou proxy volání hlásí, a každé přehnané čtení tohoto snímku začíná předpokladem, že hlásí víc.