Pse aplikacioni juaj i iPhone nuk mund ta ndezë ose fikë VPN-në e sistemit

Një menaxher produkti kërkon një buton që ndez VPN-në e kompanisë, dhe kërkesa tingëllon e parëndësishme. Në iOS kjo nuk është funksion i vogël; qëndron jashtë kontratës publike, dhe çdo shmangie ose dështon në rishikim ose thyhet në publikimin tjetër. Kaloje kërkesën përmes asaj që platforma lejon vërtet, dhe dizajni kryesisht shkruhet vetë. Një aplikacion mund të zotërojë një konfigurim VPN dhe ta nisë atë. Një aplikacion nuk mund të arrijë çelësin e sistemit, nuk mund të lexojë gjendjen e një profili që nuk e ka krijuar vetë, dhe nuk mund ta mbajë një përdorues të lidhur kundër vullnetit të tij.

Filloni nga tri gjërat që ka parasysh përdoruesi

Ndani kuptimet përpara se të ndani API-të. Ndonjëherë përdoruesi dëshiron që tuneli i aplikacionit tuaj të jetë i lidhur, ndonjëherë dëshiron të ndezë çelësin në Cilësimet për një profil të instaluar nga dikush tjetër, dhe ndonjëherë dëshiron që telefoni të mos mund të shfletojë pa tunelin. Këto korrespondojnë me tre mekanizma të ndryshëm, dhe vetëm i pari është i hapur për një aplikacion të zakonshëm.

Kuptimi i dytë është ai që prodhon pyetjet e Stack Overflow, dhe nuk ka përgjigje të mbështetur. Çelësi në Cilësimet i takon përdoruesit dhe, në pajisjet e menaxhuara, profilit. Asnjë API publik nuk rendit konfigurimet e VPN-së, nuk raporton nëse tuneli i sistemit është lart dhe nuk e ndërron atë.

Çfarë mund të krijojë vërtet një aplikacion

NetworkExtension i jep një aplikacioni konfigurimin e vet përmes NEVPNManager. Me të drejtën Personal VPN dhe pëlqimin e përdoruesit, aplikacioni ruan një konfigurim që shfaqet në Cilësimet nën emrin e vet, dhe mund ta nisë ose ta ndalojë atë lidhje të vetme. Kjo është një aftësi e vërtetë dhe e rishikueshme, dhe është gjithashtu i gjithë shtrirja: menaxheri lexon dhe shkruan vetëm atë që ka krijuar.

E drejta nuk është automatike. E kërkoni nga Apple dhe arsyetoni pse aplikacionit i duhet fare një tunel, dhe një klient qëllimi i vetëm i të cilit është të ndezë profilin e dikujt tjetër nuk ka përgjigje të mirë. Ofruesit e tuneleve me paketa ndjekin të njëjtin rregull me një klasë tjetër: NETunnelProviderManager zotëron konfigurime të bazuara te ofruesi që vetë aplikacioni ka instaluar. Asnjëra rrugë nuk arrin një profil të dorëzuar nga MDM.

Pëlqimi zbatohet edhe në momentin e ruajtjes. Shkrimi i një konfigurimi pyet përdoruesin, dhe kjo pyetje nuk është diçka që aplikacioni mund ta shtypë për lehtësi.

Leximi i gjendjes përplaset me të njëjtin mur

Statusi duket më miqësor se kontrolli dhe është po aq i mbyllur. NEVPNStatus raporton i pavlefshëm, i shkëputur, duke u lidhur, i lidhur, duke rikonfirmuar ose duke u shkëputur për konfigurimin e vetë aplikacionit, dhe në çdo ndryshim lëshohet një njoftim. Nuk thotë asgjë për një tunel të instaluar nga një profil menaxhimi, dhe pikërisht ai është gjendja që tavolina e ndihmës dëshiron të shohë.

Monitorimi i rrugës së rrjetit dhe ndryshimet e ndërfaqes ofrohen si zëvendësime në rishikimet e dizajnit. Ato përshkruajnë rrugën që ndjek trafiku i aplikacionit, e cila ndryshon për arsye të palidhura me gjendjen e VPN-së, dhe përdorimi i tyre si lexim VPN jep një ndërfaqe që gënjen në të dy drejtimet.

On Demand dhe Always On janë levat e vërteta

Levat e mbështetura jetojnë në profil, jo në aplikacion. Rregullat On Demand i thonë sistemit kur të lidhet: një listë e renditur kushtesh me veprime, e vlerësuar nga sistemi operativ, jo nga kodi juaj. Një rregull që lidhet në çdo ndërfaqe krijon ndjesinë e lidhjes së përhershme pa i dhënë asnjë kontroll aplikacionit.

Always On VPN është mekanizmi i detyrimit, dhe është i lidhur me mbikëqyrjen. Në një pajisje të mbikëqyrur, MDM instalon një profil që e mban tunelin lart; në një telefon personal të pambikëqyrur të njëjtat çelësa nuk prodhojnë të njëjtin sjellje. Kjo asimetri është e qëllimshme, dhe asnjë kombinim çelësash ngarkese nuk e heq atë. Kur kërkesa është vërtet që VPN-ja duhet të jetë e ndezur, kërkesa është në fakt që pajisja duhet të menaxhohet.

Midis të dyjave rri kushëriri më i dobët: një rregull që rilidhet pasi përdoruesi shkëputet. Rilidhet kur rregulli vlerësohet herën tjetër, gjë që nuk është e njëjtë me menjëherë, dhe një përdorues që u shkëput me qëllim do ta vërë re ndryshimin. Dizajno ndërfaqen rreth atij boshllëku në vend që të premtosh një bravë.

Dërgo rrugën e mbështetur

Katër pyetje e vendosin mekanizmin para se të ekzistojë ndonjë kod: kujt i përket pajisja, a është nën mbikëqyrje, cili klient e përfundon tunelin dhe nga vjen profili. Nëse ndonjëra prej tyre është e panjohur, kërkesa për veçori nuk është gati për vlerësim.

Një API private që futet në VPN-në e sistemit do të kalojë një demonstrim dhe do të dështojë në rishikim, dhe nëse dërgohet në një mënyrë tjetër thyhet në publikimin tjetër të iOS. Nuk ka version të këtij shkëmbimi që ia vlen për një çelës.

Telemetria e menaxhimit është kanal më vete: raporton se një profil është instaluar dhe nëse pajisja është në përputhje, gjë që është raportim dhe jo një sipërfaqe kontrolli për çdo aplikacion. Testoje rrjedhën në një pajisje reale pas çdo përditësimi, sepse sjellja e mbështetur jeton në sistemin operativ dhe sistemi operativ lëviz.