Az Android IKEv2 VPN-profiljai felhasználónként, nem eszközönként léteznek

A beépített VPN kifejezés az Androidon két, egymástól független dolgot takar: a platform által az Ön nevében futtatott protokollmegvalósítást, és a gyártó által megjeleníteni döntött beállítási formát. Ezek nem ugyanaz az objektum, és egyik sem garantálja, hogy az alagút ahhoz a felhasználóhoz tartozik, akinek az alkalmazásainak szüksége van rá. A létrehozás egy adott felhasználóban, adott hívó csomaggal történik, és minden további örökli ezt a kontextust. Olvassa el a tulajdonosi láncot a beállítások képernyő előtt.

Mit épít Önnek a platform

Az Android 11 óta a platform a VPN létrehozását a VpnManager révén teszi elérhetővé. Egy jóváhagyott alkalmazás IKEv2-profilt ír le, és a platform maga végzi az IPsec és IKE cserét, így az alkalmazás soha nem nyúl a csomagokhoz. Ez a lényegi különbség a saját VPN-alkalmazáshoz képest, amely a VpnService-et valósítja meg, és a saját folyamatában építi az alagutat.

val profile = Ikev2VpnProfile.Builder(serverAddress, identity)
    .setAuthUsernamePassword(user, secret, rootCa)
    .build()
getSystemService(VpnManager::class.java).provisionVpnProfile(profile)

A fenti hívás a forma vázlata, nem másolható blokk: az építőnek több hitelesítési változata van, ezek API-szintenként különböznek, és a profil a kiszolgáló tanúsítványának bizalmi anyagát is hordozza. A tulajdonjog kérdésében a lényeg szűkebb a szintaxisnál.

Ebből a tervből két tulajdonság következik. A profil adat, ezért egy rendszergazda létrehozhatja a kézi begépelés helyett. És az alagút a platform hálózata, ezért az alkalmazások VPN-átvitelű hálózatként látják, nem egy másik alkalmazás foglalataként.

A tulajdonos a felhasználó, aztán a csomag

Az Android többfelhasználós működése valódi elkülönítés, nem címke. A munkaprofil külön felhasználó a saját telepített csomagjaival, alkalmazásadataival, kulcstárával és bizalmi horgonyaival. Ugyanaz a termék mindkét helyen két példány különböző felhasználó-azonosítóval, akkor is, ha az ikonok és a terméknevek azonosak.

A létrehozás az adott felhasználóban a hívó csomaghoz rögzül. Így a személyes profilban futó létrehozó alkalmazás személyes alagutat hoz létre, a munkaprofil munkás alkalmazásai pedig semmit nem látnak belőle. Fordítva is igaz, ezért a munkaprofil alagútja láthatatlan a személyes alkalmazásoknak, hacsak kifejezett szabályzat nem mond mást.

Az eszközszabályzat-vezérlő létrehozhat egy felügyelt profil nevében, ami megmagyarázza azt a bejegyzést, amelyre senki nem emlékszik az irodában. Ha telefont auditál, valószínűleg ő a szürke profil tulajdonosa, és nem az Ön dolga kísérletként törölni.

Három kapu, mielőtt egy csomag elindul

Az első kapu a felhatalmazás: a vezetésnek egyáltalán engedélyeznie kell a VPN-t, és néhány telepítés a típust is korlátozza a létezés mellett. A második az identitás: az ügyféltanúsítványnak vagy a hitelesítő adatoknak abban a felhasználóban kell elérhetőknek lenniük, aki a profil tulajdonosa, mert a személyes kulcstárba importált tanúsítvány nem látható a munkaprofilnak.

A harmadik a beleegyezés és a szabályzat. A felhasználó általában az első használatkor jóváhagyja a kapcsolatot, és a rendszergazda emellett mindig bekapcsoltként rögzítheti, opcionálisan zárral, hogy a forgalom ne hagyhassa el az alagutat. Ezek a beállítások döntik el, mi történik az alagút leállásakor, és a felhasználók éppen ezt veszik észre.

A hatókör az a pont, ahol a három találkozik. A profil határozza meg az átjárót és az identitást, míg a szabályzatréteg dönti el, mely alkalmazások használhatják az alagutat, és hogy a forgalom kényszerítve halad-e át rajta. Ezért két azonos átjárócímű telefon nagyon eltérően viselkedhet.

Miért nem fedi le a személyes kapcsolat a munkás alkalmazásokat

A munkás alkalmazás forgalma a munkafelhasználóban keletkezik, és az alkalmazandó hálózati szabályzat az abban a felhasználóban érvényes. A személyes profilban létrehozott alagút nem viszi azt, bármilyen egészségesnek tűnik is a jelző. Ez az egyetlen tény magyarázza a legtöbb olyan jelentést, amelyben a felhasználó esküszik, hogy a VPN kapcsolódik, és egy adott alkalmazás mégsem ér el belső szolgáltatást.

A névfeloldás ugyanezt a határt követi. A privát DNS-utótagok és a bizalmi horgonyok felhasználónként értendők, ezért egy belső gazdanév, amely a személyes profilban feloldódik, a munkaprofilban meghiúsulhat, akár látszólag egyenértékű alagúttal is, mert a feloldó szabályzata és a CA-tár különböző objektumok.

Valódi regisztráción ellenőrizze, ne laboratóriumi telefonon

Az eszközön először azonosítsa a bejegyzés tulajdonosát: melyik felhasználó, melyik csomag, és hogy a profil a platform létrehozójától vagy saját VPN-szolgáltatást megvalósító alkalmazástól származik-e. Ezután erősítse meg, hogy a profil által várt identitás valóban jelen van-e az adott felhasználó kulcstárában.

A teljes életciklust tesztelje, ne csak a kapcsolódást. Jelentkezzen be, nyissa ki a hitelesítőadat-tárat, hagyja a munkaproflt estére szünetelni, majd hozza vissza, és ellenőrizze, hogy az alagút kézi koppintás nélkül visszatér-e. A munkaidő után kikapcsoló munkaprofil magával viszi az alagutat, és ez várt viselkedés, nem hiba, feltéve, hogy a várt elérhetetlen állapot le van írva.

Végül tesztelje magát a munkás alkalmazást egy ismert belső végpont ellenében, és hasonlítsa össze a személyes profil eredményével. A kettő eltérhet; aminek nem szabad eltérnie, az a tulajdonjogi modell. Ha az alagút a rossz felhasználóhoz tartozik, a tanúsítványok újrakibocsátása nem javítja meg.

Ne erőltesse a dolgot rejtett beállítási tevékenységek indításával egy menü felfedéséhez, és ne másoljon privát kulcsokat profilok között, hogy kapcsolat jelenjen meg. A VpnManager-referencia dokumentálja, mit hozhat létre a hívó; ha a jóváhagyott útvonal nem tartalmazza az Ön esetét, az a rendszergazda döntése, nem beállítási probléma.