Miért nem tudja az iPhone-alkalmazásod be- vagy kikapcsolni a rendszer VPN-jét

Egy termékmenedzser olyan gombot kér, amely bekapcsolja a vállalati VPN-t, és a kérés triviálisnak hangzik. iOS-en ez nem kis funkció; a nyilvános szerződésen kívül áll, és minden megkerülő megoldás vagy elbukik a felülvizsgálaton, vagy eltörik a következő kiadásban. Vezesd át a kérést azon, amit a platform valóban engedélyez, és a design nagyrészt magától megíródik. Egy alkalmazás birtokolhat VPN-konfigurációt és elindíthatja. Egy alkalmazás nem érheti el a rendszer kapcsolóját, nem tudja kiolvasni egy általa nem létrehozott profil állapotát, és nem tud egy felhasználót akarata ellenére kapcsolatban tartani.

Kezdd azzal a három dologgal, amire a felhasználó gondol

Válaszd szét a jelentéseket, mielőtt szétválasztod az API-kat. Néha a felhasználó azt akarja, hogy az alkalmazásod alagútja kapcsolódjon, néha azt, hogy a Beállítások kapcsolója átbillenjen egy másvalaki által telepített profilhoz, és néha azt, hogy a telefon alagút nélkül ne tudjon böngészni. Ezek három különböző mechanizmusnak felelnek meg, és csak az első nyitott egy hétköznapi alkalmazás előtt.

A második jelentés az, amely a Stack Overflow kérdéseit szüli, és nincs rá támogatott válasz. A Beállítások kapcsolója a felhasználóé, felügyelt eszközökön pedig a profité. Egyetlen nyilvános API sem sorolja fel a VPN-konfigurációkat, nem jelenti, hogy a rendszer alagútja fent van-e, és nem billenti át.

Mit tud valójában létrehozni egy alkalmazás

A NetworkExtension saját konfigurációt ad az alkalmazásnak NEVPNManager révén. A Personal VPN jogosultsággal és a felhasználó beleegyezésével az alkalmazás ment egy konfigurációt, amely a saját neve alatt jelenik meg a Beállításokban, és el tudja indítani vagy le tudja állítani azt az egy kapcsolatot. Ez valódi, felülvizsgálható képesség, és egyben a teljes hatókör: a kezelő csak azt olvassa és írja, amit maga létrehozott.

A jogosultság nem automatikus. Az Apple-től kéred, és megindoklod, miért van egyáltalán szüksége az alkalmazásnak alagútra, és egy ügyfélnek, amelynek egyetlen célja más profiljának bekapcsolása, nincs jó válasza. A csomagalagút-szolgáltatók ugyanezt a szabályt követik más osztállyal: a NETunnelProviderManager birtokolja a szolgáltatóalapú konfigurációkat, amelyeket az alkalmazás maga telepített. Egyik útvonal sem ér el egy MDM által szállított profilt.

A beleegyezés mentéskor is érvényes. Egy konfiguráció írása kérdezni fogja a felhasználót, és ez a kérés nem olyasmi, amit egy alkalmazás kényelemből elnyomhat.

Az állapot kiolvasása ugyanabba a falba ütközik

Az állapot barátságosabbnak tűnik az irányításnál, és ugyanolyan zárt. A NEVPNStatus érvénytelen, bontott, csatlakozó, csatlakozott, újraérvényesítő vagy bontó állapotot jelent az alkalmazás saját konfigurációjára, és minden változásnál értesítés indul. Semmit sem mond a felügyeleti profil által telepített alagútról, pedig az az állapot, amelyet egy ügyfélszolgálat látni szeretne.

A hálózati útvonal figyelését és az interfészváltozásokat tervezési felülvizsgálatokon helyettesítőként ajánlják. Leírják az útvonalat, amelyen az alkalmazás forgalma halad, ez pedig a VPN állapotától független okokból változik, és VPN-kijelzésként használva olyan felületet ad, amely mindkét irányban hazudik.

Az On Demand és az Always On az igazi karok

A támogatott karok a profilban élnek, nem az alkalmazásban. Az On Demand szabályok megmondják a rendszernek, mikor kapcsolódjon: feltételek és műveletek rendezett listája, amelyet az operációs rendszer értékel ki, nem a kódod. Egy szabály, amely bármely interfészen kapcsolódik, állandó kapcsolódás érzetét kelti anélkül, hogy bármely alkalmazásnak irányítást adna.

Az Always On VPN a kikényszerítés mechanizmusa, és felügyelethez kötődik. Felügyelt eszközön az MDM olyan profilt telepít, amely fent tartja az alagutat; nem felügyelt személyes telefonon ugyanazok a kulcsok nem ugyanazt a viselkedést adják. Ez az aszimmetria szándékos, és a hasznos teher kulcsainak semmilyen kombinációja nem szünteti meg. Amikor a követelmény valóban az, hogy a VPN-nek bekapcsolva kell lennie, a követelmény valójában az, hogy az eszközt kezelni kell.

A kettő között ül a gyengébb unokatestvér: egy szabály, amely újracsatlakozik, miután a felhasználó bontott. Akkor csatlakozik újra, amikor a szabályt legközelebb kiértékelik, ami nem ugyanaz, mint azonnal, és a felhasználó, aki szándékosan bontott, észre fogja venni a különbséget. A felületet e rés köré tervezd, ahelyett hogy zárat ígérnél.

Szállítsd a támogatott utat

Négy kérdés dönti el a mechanizmust, mielőtt bármilyen kód létezik: kié az eszköz, felügyelt-e, melyik kliens zárja le az alagutat, és honnan jön a profil. Ha ezek bármelyike ismeretlen, a funkciókérés nem becsülhető meg.

Egy privát API, amely a rendszer VPN-jében turkál, átmegy egy demón és elbukik a felülvizsgálaton, és ha más úton szállítják, eltörik a következő iOS-kiadásban. Ennek a cserének nincs olyan változata, amely egy kapcsolóért megérné.

A felügyeleti telemetria külön csatorna: jelenti, hogy telepítve van egy profil, és hogy az eszköz megfelel-e, ami jelentés, nem pedig alkalmazásonkénti irányítási felület. Minden frissítés után teszteld a folyamatot valódi eszközön, mert a támogatott viselkedés az operációs rendszerben él, az operációs rendszer pedig mozog.