Miért nem tud egy alkalmazás bekapcsolni egy mentett VPN-profilt Androidon vagy iOS-en

Két nagyon különböző feladat kerül a programozható VPN neve alá, és ezek közül csak az egyik érhető el egy hétköznapi alkalmazás számára bármelyik mobilos platformon. Az első egy olyan profil bekapcsolása, amelyet a felhasználó már mentett; a második egy alagút építése a saját folyamatán belül. Az Android a másodikat a VpnService segítségével adja, az iOS pedig a másodikat a Network Extension jogosultságon keresztül, míg az első a rendszernél, az eszköz tulajdonosánál vagy egy MDM-kiszolgálónál marad. Annak kiderítése, melyikre van valójában szüksége, általában kisebbé teszi a projektet.

Két feladat, egy néven

Egy mentett profil aktiválása azt jelenti, hogy szólunk egy létező alagútnak, hogy jöjjön fel: egy gazdagép, egy hitelesítő adat, egy protokoll, minden már beállítva valahol, ahol a felhasználó láthatja. Alagút építése azt jelenti, hogy a kódja birtokolja az interfészt, a csomaghurkot és a protokollt. A termék hátralékában hasonlónak tűnnek, és szinte semmilyen implementációt nem osztanak meg.

Egyik mobilos platform sem teszi elérhetővé az elsőt SDK-alkalmazás számára. Az a kapcsolat, amely anélkül jelenik meg, hogy a felhasználó bármit tenne, nem különböztethető meg a kártevőktől, ezért mindkét rendszer beleegyezési kaput tesz minden forgalmat vivő alkalmazás elé.

Android: beleegyezési kapu, és semmilyen profil-API

VpnService az Android 4.0 óta létezik, és lehetővé teszi, hogy egy alkalmazás tun interfészt hozzon létre, majd csomagokat olvasson és írjon. A szolgáltatást BIND_VPN_SERVICE segítségével kell deklarálni, és a VpnService.prepare() hozza létre azt a rendszerpárbeszédet, amely engedélyt kér a felhasználótól. A platform mintája, a ToyVpn, a szándékolt forma legvilágosabb megfogalmazása: a kódja birtokolja az interfészt és mindent, ami rajta átfolyik.

Amit nem tesz meg, az az, hogy bejegyzést adjon a rendszer VPN-beállítások képernyőjéhez. Erre nincs nyilvános API, és a Beállítások alkalmazás olyan tárolóban tartja a profiljait, amelyet egy hétköznapi alkalmazás nem ér el. A rejtett osztályok hívása egy normál alkalmazásból olyan profilokat hoz létre, amelyeket a rendszer soha nem listáz, ezért az a kód, amely egy buildben működni látszott, a következőben csendesen leáll.

A kezelt útvonal külön áll. Egy eszköz- vagy profiltulajdonos mindig bekapcsolt VPN-csomagot jelölhet ki az eszközszabályzat API-jain keresztül, és egy vállalati eszköz olyan profilt küldhet, amelyet a felhasználó utána jóváhagy. Ez eszközkezelési jogosultság, nem olyan engedély, amelyet az alkalmazás telepítéskor kér. Ha az ügyfele szervezet, ezt az útvonalat kell tervezni; ha az ügyfele egy ember, aki áruházból telepít, ez egyáltalán nem elérhető.

iOS: a jogosultság a határ

Az iOS ugyanezt a munkát másképp osztja fel. Egy VPN-kliens csomagalagút-szolgáltatót vagy alkalmazásproxy-t valósít meg a Network Extension keretrendszerben, és a megfelelő jogosultságot a fejlesztői fióknak meg kell adni. Személyes VPN-konfiguráció a NEVPNManager segítségével létezik az egyszerűbb esetre, és továbbra is ugyanabban az engedélymodellben fut. Az Apple a teljes felületet a Network Extension-referenciában dokumentálja, amelyet érdemes elolvasni, mielőtt a munka terjedelmét meghatározza.

Nincs támogatott mód a VPN-beállítások képernyő megnyitására, a felhasználó mentett konfigurációinak olvasására vagy azok egyikének indítására. Amit egy kliens tehet, az az, hogy elküld egy konfigurációs profilt, amelyet a felhasználó telepít, majd az így létrejött alagutat hétköznapi hálózati hívásokon keresztül használja. Az alkalmazásonkénti alagutazást egy MDM-kiszolgáló osztja ki igény szerinti szabállyal, nem az alkalmazás választja futásidőben.

Egy nagy szállító VPN-kliense nem bizonyíték arra, hogy a fiókja ugyanezt tudja küldeni. Ezeket a jogosultságokat fejlesztői fiókonként kérik és vizsgálják, így az ütemezési kockázat az Apple-nél van, nem a sprinttervében.

Az asztali rendszer messzebbre ér, de a tulajdon változatlan

A Windows a megengedő eset. A Add-VpnConnection telefonkönyv-bejegyzést hoz létre egy emelt PowerShell-munkamenetből, és a rasdial csatlakoztatja vagy bontja azt egy szkriptből. Egy alkalmazás egy szállító kliensét is vezérelheti a dokumentált parancssorán keresztül. A profil létrehozása továbbra is adminisztratív művelet, mert a bejegyzés gépszintű tárolóban él.

A macOS ugyanígy viselkedik más eszközökkel. A scutil --nc start és a stop már létező szolgáltatásokon dolgozik, míg egy létrehozása rendszergazdai feladat. A folyamat birtoklása egy laptopon nem tesz a konfiguráció tulajdonosává.

Mit építsen helyette

Ha a valódi követelmény az, hogy az alkalmazása elérjen egy belső API-t, akkor a felhasználó által már futtatott alagút elég. Küldjön normál HTTPS-kéréseket, hagyja a rendszert az útvonal kiválasztásában, és hagyjon fel az alagút irányításának kísérletével. Ha a követelmény az, hogy csak az alkalmazása forgalma használja az alagutat, kérjen alkalmazásonkénti VPN-t a kezelési csatornán keresztül, vagy zárja le a TLS-t az alkalmazáson belül egy olyan szolgáltatás felé, amely az nélkül is elérhető.

A rejtett API-k nem olyan rövidítés, amelyet érdemes választani. Kiadások között változnak, elbuknak az alkalmazás-ellenőrzésen, és az általuk okozott hibák annak, aki örökli a kódot, hétköznapi hálózati hibáknak tűnnek. Az összehasonlítás nem Android kontra iOS; az alagút birtoklása kontra a platform megkérése, hogy irányítsa a forgalmat, és csak az első az, amit Önnek kell felépítenie.