A munkaalkalmazás VPN-t kér? Először ezt a három réteget nézze meg

Az üzenet azt mondja, hogy az alkalmazásnak VPN kell, de az alkalmazás általában tünetet jelent, nem pedig megnevezi azt, ami blokkolta. Három különböző felelős állíthatja elő ezt a mondatot: a privát szolgáltatás, amellyel az alkalmazás beszél, az alkalmazás saját szabályzatkódja és az eszközkezelési réteg, amely a munkaprofilt vezérli. Hogy melyikük kérdez, megváltoztatja, mit kell tennie, és a háromból csak egy javul meg egy alagút csatlakoztatásával. A felelős előzetes megtalálása megkíméli egy olyan kliens újratelepítésétől, amely soha nem volt a probléma.

Mit tud maga az alkalmazás ellenőrizni

Mielőtt rejtett platformszabályt feltételezne, ne feledje, hogy egy közönséges alkalmazás látja, aktív-e egy VPN-transzport. A ConnectivityManager jelenti a TRANSPORT_VPN-t hordozó hálózatokat, és a NET_CAPABILITY_NOT_VPN hiánya minden hívónak megmondja, hogy a jelenlegi útvonal alagúton halad. Az a fejlesztő, aki meg akarja tagadni az alagúton kívüli futást, nyilvános API-kkal és mindenféle vállalati eszköz nélkül megteheti.

Amit az alkalmazás így nem lát, az az, hogy kinek a VPN-je. Egy transzportjelző azt mondja, hogy létezik alagút, nem azt, hogy ott végződik, ahol a szervezete várja.

A szolgáltatás útvonala: privát nevek és címek

Az üzenet leggyakoribb őszinte változata egyáltalán nem szabályzatellenőrzés. Az alkalmazás egy belső gazdagépnevet old fel, például egy wikit vagy egy API-végpontot, amely csak a vállalati DNS-nézetben létezik, és a keresés még azelőtt meghiúsul, hogy bármilyen szabályzatkód futna. Az alagút állhat és általános internethatást továbbíthat, miközben a megosztott DNS azt a nevet olyan feloldóhoz küldi, amely soha nem hallott róla.

A tünetek itt szűkek. Egy gazdagép meghiúsul, az alkalmazás többi hálózati hívása működik, és a hiba névkeresés közben jelenik meg, nem indításkor. A belső tanúsítványok második hiba módot adnak hozzá, mert a szervezet CA-jához rögzített alkalmazás elutasít egy nyilvános tanúsítványt akkor is, amikor a csomagok folynak.

Egy véletlenszerű kereskedelmi VPN csatlakoztatása ebből semmit nem javít meg. Megváltoztatja a kilépési címét, és a belső nevet ugyanolyan feloldhatatlanul hagyja.

Az alkalmazásszabályzat rétege

Az alkalmazás saját kaput is hordozhat. A felügyelt konfigurációk lehetővé teszik, hogy a szervezet olyan kulcs-érték párokat toljön, amelyeket az alkalmazás deklarál, és az alkalmazás ezeket a RestrictionManageren keresztül olvassa. Egy kulcs, például egy kötelező profilmév vagy az engedélyezett hálózatok listája teljesen a fejlesztő tervezése, amely az alkalmazáskódban érvényesül azzal a hibaszöveggel, amelyet az a kód választ.

Ez a réteg az, ahol a megfogalmazás általában elárulja. Ha az üzenet azonnal indításkor, bármilyen hálózati hívás előtt megjelenik, és szabályzatot, profilt vagy rendszergazdát említ, valószínűleg alkalmazáslogikát lát, nem egy eldobott csomagot.

Ugyanazt a korlátozást személyes eszközön olvasni zsákutca. A nem felügyelt eszközökön nincs olvasható korlátozás, ezért az alkalmazás visszaesik arra az alapértékre, amellyel épült.

A platform rétege: mindig bekapcsolt és zárolás

Az eszközkezelés olyan kényszerítést ad hozzá, amelyet az alkalmazás nem tud felülírni. Az eszközszabályzat-vezérlő meghívhatja a setAlwaysOnVpnPackage-et a munkaprofilhoz, opcionálisan engedélyezett zárolással, és amint a zárolás be van kapcsolva, a platform megtagadja az olyan forgalmat, amely nem ezen a csomagon keresztül megy. A blokkolás rendszerállapotként látszik, nem alkalmazáshibaként: a profil többi alkalmazása is abbahagyja a hálózat elérését.

A hatókör számít. Az always-on VPN felhasználónként van beállítva, ezért egy munkaprofil-csomag nem fedi le a személyes profilját, és egy személyes VPN nem elégíti ki a munkaprofil-csomagot. Két profil, két független hálózati szabályzat, egy eszköz.

Ez az egyetlen réteg is, ahol egy nem kapcsolódó VPN nem segíthet, mert a szabályzat egy konkrét csomagot nevez meg.

A három megkülönböztetése

Menjen végig a jeleken sorrendben, és álljon meg az elsőnél, amely illik. Ha egy gazdagépnév meghiúsul, miközben minden más feloldódik, az a szolgáltatás útvonalára utal. Az azonnali elutasítás indításkor, szabályzati megfogalmazással, az alkalmazáslogikára utal. Ha egy egész profil elveszíti a kapcsolatot minden alkalommal, amikor a jóváhagyott kliens lecsatlakozik, az a zárolásra utal. És az az alkalmazás, amely bármilyen alagutat elfogad, a transzportjelzőt ellenőrzi, nem a szervezete identitását.

Hasznos bizonyítékok: a pontos szöveg és annak időzítése, hogy a profil többi alkalmazásának van-e még kapcsolata, hogy a privát név feloldódik-e a jóváhagyott alagúton belül, és hogy az eszköz mutat-e munkajelvényt a megnyitott alkalmazáshoz.

Mit írjon a támogatási kérésbe

Egy kérés, amely megnevezi a réteget, első próbálkozásra helyesen irányítódik. Valami ilyesmi: a munkaprofil alkalmazása megnyílik, az erőforráslista meghiúsul a jóváhagyott VPN csatlakozása után, a privát név feloldása meghiúsul az engedélyezett diagnosztikában, és a profil többi alkalmazása tovább működik. Ez útvonal- vagy feloldóproblémaként olvasható, és kihagyja a fiók-visszaállítási hurkot.

Ha a jóváhagyott VPN teljesen hiányzik, a támogatott út a regisztráció vagy az újratelepítés a rendszergazdáján keresztül. A kezelési profil eltávolítása, egy nem kapcsolódó kliens telepítése vagy a hálózati állapot hamisítása megváltoztatja a biztonsági elrendezést ahelyett, hogy helyreállítaná.

Kezdje a réteggel, ne a klienssel. A fenti három jel rendszerint egyetlen ülésben eldönti.