Hogyan olvassuk egy felügyelt munkaalkalmazás VPN- és proxyállapotát

Egy munkaalkalmazás elakad egy felügyelt telefonon, valaki megnézi a VPN-kapcsolót, látja, hogy be van kapcsolva, és egészségesnek nyilvánítja az útvonalat. Itt áll meg ezeknek a diagnózisoknak a nagy része, és ez túl korai: egy aktív VPN-transzport nem mondja meg, hogy ennek az alkalmazásnak a kérései használták-e, és a ténylegesen érvényes proxy lehet alkalmazásonkénti, vagy egy PAC-fájl választhatja ki a Beállításokban való megjelenés helyett. Kezdje azzal a konkrét alkalmazással és profillal, amelyet vizsgál, majd olvassa el a platform saját nézetét az útvonalról.

Kezdje az alkalmazással és a profiljával

A munkajelvényes alkalmazás általában külön profilban fut, saját hálózati szabályzattal. Ugyanazon a telefonon egy személyes böngésző nem bizonyíték rá, és egy más kezelésű kolléga eszközének eredménye sem az. Jegyezze fel, melyik profilhoz tartozik az alkalmazás, mielőtt bármit olvas.

A Beállításokban listázza a beállított VPN-bejegyzéseket, és jegyezze fel, ki melyiket birtokolja. A Samsung-kiadásokban a menücímkék verziók között mozognak, ezért a bejegyzést írja le, ne a hozzá vezető utat. A szürke vagy felügyelt bejegyzés azt illeti, aki az eszközt adminisztrálja; kísérletként való kikapcsolása megváltoztatja azt, amit mérni próbál, és szabályzatba ütközhet.

Olvassa el az állapotot, amelyet a platform jelent

A támogató eszközeiben létező tevékenységen belül, API 23 vagy újabb szinten, a hálózati állapot egyetlen bájt elküldése nélkül olvasható. A hívásnak a szokásos ACCESS_NETWORK_STATE manifestengedélyre van szüksége a képességek olvasásához.

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

Minden érték egy szűk kérdésre válaszol. Az aktív hálózat a hívó folyamat alapértelmezett hálózata abban a pillanatban. A képességellenőrzés megmondja, hogy az az alapértelmezett hálózat VPN-alapú-e. A proxyhívás a tényleges alapértelmezett HTTP-proxyt jelenti, és a visszakapott objektum statikus proxyt vagy PAC-szkriptet írhat le.

Ha az alapértelmezett helyett hálózatonkénti nézetre van szüksége, olvassa el ugyanazon hálózat kapcsolattulajdonságait, és hasonlítsa össze a cm.getLinkProperties(network)?.httpProxy értékkel. Az eszközkezelés által telepített proxy az alapértelmezett proxyhívásban jelenik meg, a kapcsolattulajdonságokban nem, ami gyors módja annak, hogy megkülönböztesse a szabályzat által adott proxyt a hálózat által adottól.

Tartsa a kimenetet a támogatási csatornájában, ne nyilvános jelentésben. A proxy-gépnevek, a PAC URL-ek és a belső utótagok elárulják, hogyan irányítja a szervezete a forgalmat, és egyik sem szükséges a hiba leírásához.

Értelmezze minden mezőt szűken

A null hálózat vagy null képességobjektum azt jelenti, hogy a hívó hálózati állapota nem volt elérhető, vagy az olvasás közben megváltozott. Ez nem jelenti azt, hogy nincs VPN. Kezelje ismeretlenként, és olvassa újra, miután az alkalmazás előtérbe került, ne negatív eredményként.

A VPN-transzport a pozitívumok közül a leggyengébb. Minden alkalmazás, amely VpnService tart, létrehoz egyet, beleértve egy helyi szűrőalkalmazást is, amely soha nem küldi sehová a forgalmát. Tehát a true érték azt mondja, hogy létezik VPN-alapú alapértelmezett hálózat, nem azt, hogy a szervezet kimenete volt használva, és biztosan nem azt, hogy vizsgálat történt.

A null alapértelmezett proxy azt jelenti, hogy ez az API nem jelent alapértelmezett HTTP-proxyt a tényleges konfigurációhoz. Nagyon keveset zár ki: az alkalmazás hordozhat saját SOCKS-beállítást, saját HTTP-klienst valósíthat meg, vagy olyan átjárón lévő proxy irányíthatja, amelyről az eszköz soha nem szerez tudomást.

A PAC az az eset, amely legyőzi az egyértékű választ. Egy szkript az egyik célállomást proxyn keresztül irányíthatja, a másikat közvetlenül küldheti, így ugyanazon alkalmazás két kérése egy másodpercen belül különböző útvonalakat vehet. És az az alkalmazás, amely a socketjeit egy kiválasztott hálózathoz köti, vagy bindProcessToNetwork-et hív, egyáltalán nem köteles követni az alapértelmezettet.

Amit ez a pillanatkép nem tud megmondani

Ez nem történet. Itt semmi nem rögzíti, melyik útvonalat vette a meghiúsuló kérés, és a hiba utáni sikeres olvasás nem bizonyíték a hibáról. Ez nem leltár sem: a hívó folyamat alapértelmezett hálózatát kapja, nem az egyes alkalmazások privát kapcsolatainak listáját.

Arról sem mond semmit, ami a socket felett történik. A felügyelt eszközön meghiúsuló TLS-kézfogás lehet bizalmi tároló problémája, rögzítési eltérés vagy olyan név, amelyet a proxy elutasít, és egyik sem jelenik meg a kapcsolódásolvasásban.

Ezért számít a két fél együtt: a pillanatkép szűkíti, hova nézzen, és az alkalmazás saját diagnosztikája mondja meg, mi hiúsult meg valójában.

Jelentse olyan formában, amelyet egy adminisztrátor használni tud

Adja meg az érintett alkalmazást, a profilt, az időbélyeget és a pontosan meghiúsult szakaszt: névfeloldás, TCP-kapcsolat, TLS-kézfogás vagy HTTP-állapot. Adja hozzá a pillanatkép értékeit úgy, ahogy olvasta őket, a nullákat nullaként írva, nem pedig szóként, hogy nincs. Jegyezze fel, hogy ugyanazon profil más alkalmazásai ugyanígy hiúsulnak-e meg, ami elválasztja az alkalmazás problémáját a profil szintű útvonalproblémától.

Aztán álljon meg, és hagyja, hogy az útvonal tulajdonosa válaszoljon. Ne tekintse a vállalati tanúsítványt, a proxycímet vagy a VPN-bejegyzést engedélynek a felügyelet eltávolítására vagy a jóváhagyott útvonal megkerülésére; ez támogatási esetet alakít szabályzati incidensté.

Az alapértelmezett proxy szerződése rövid, és megér egy olvasást, mert pontosan meghatározza, melyik proxyt jelenti a hívás, és ennek a pillanatképnek minden túlolvasása azzal a feltevéssel kezdődik, hogy többet jelent.