Zergatik zure iPhone aplikazioak ezin duen sistemako VPN-a piztu edo itzali

Produktu kudeatzaile batek enpresako VPN-a pizten duen botoi bat eskatzen du, eta eskaera hutsala dirudi. iOS-en ez da funtzio txiki bat; kontratu publikoaren kanpoan dago, eta saihesbide bakoitzak edo berrikuspena gainditzen du edo hurrengo bertsioan hausten da. Eraman eskaera plataformak benetan uzten duenaren bidez, eta diseinuak bere burua idazten du hein handi batean. Aplikazio batek VPN konfigurazioa izan dezake eta hura abiarazi. Aplikazio batek sistemako etengailua ez du ukitzerik, ez du berak sortu ez duen profil baten egoera irakurtzerik, eta ezin du erabiltzaile bat bere borondatearen aurka konektatuta eduki.

Hasi erabiltzaileak esan nahi dituen hiru gauzekin

Bereizi esanahiak APIak bereizi baino lehen. Batzuetan erabiltzaileak nahi du zure aplikazioaren tunela konektatuta egotea, batzuetan nahi du Ezarpenetako etengailua beste norbaitek instalatutako profil baterako piztea, eta batzuetan nahi du telefonoak ezin izatea tunelik gabe nabigatu. Horiek hiru mekanismo desberdini dagozkie, eta lehenengoa bakarrik dago aplikazio arrunt baten eskura.

Bigarren esanahia da Stack Overflow-eko galderak sortzen dituena, eta ez du erantzun onarturik. Ezarpenetako etengailua erabiltzailearena da eta, kudeatutako gailuetan, profilarena. API publiko batek ere ez ditu VPN konfigurazioak zerrendatzen, ez du sistemako tunela martxan dagoen jakinarazten, ez eta aldatzen.

Zer sor dezakeen aplikazio batek benetan

NetworkExtension-ek aplikazio bati bere konfigurazioa ematen dio NEVPNManager bidez. Personal VPN eskubidearekin eta erabiltzailearen baimenarekin, aplikazioak Ezarpenetan bere izenarekin agertzen den konfigurazio bat gordetzen du, eta konexio bakarra abiarazi edo gelditu dezake. Gaitasun erreala eta berrikusgarria da, eta gainera esparru osoa da: kudeatzaileak berak sortutakoa baino ez du irakurtzen eta idazten.

Eskubidea ez da automatikoa. Apple-ri eskatzen diozu eta aplikazioak zergatik behar duen tunel bat justifikatzen duzu, eta helburu bakarra beste norbaiten profila piztea duen bezeroak ez du erantzun onik. Pakete-tunel hornitzaileek arau bera jarraitzen dute beste klase batekin: NETunnelProviderManager aplikazioak berak instalatutako hornitzailean oinarritutako konfigurazioen jabe da. Bi bideetako batek ere ez du MDM-k emandako profil bat lortzen.

Baimena gordetzeko unean ere aplikatzen da. Konfigurazio bat idazteak erabiltzaileari galdetzen dio, eta galdera hori ez da aplikazio batek erosotasunerako isil dezakeen zerbait.

Egoera irakurtzeak horma berarekin egiten du topo

Egoerak kontrolak baino atseginago dirudi eta ez da gutxiago itxia. NEVPNStatus baliogabea, deskonektatuta, konektatzen, konektatuta, berresten edo deskonektatzen jakinarazten du aplikazioaren konfigurazio propioarentzat, eta aldaketa bakoitzean jakinarazpen bat pizten da. Kudeaketa-profilek instalatutako tunelaz ez du ezer esaten, eta hori da laguntza-zerbitzu batek ikusi nahi duen egoera.

Sare-bidearen monitorizazioa eta interfaze-aldaketak ordezko gisa eskaintzen dira diseinu-berrikuspenetan. Aplikazioaren trafikoak egiten duen bidea deskribatzen dute, eta bide hori VPN-aren egoerarekin zerikusirik ez duten arrazoiengatik aldatzen da, eta VPN-irakurketa gisa erabiltzeak bi noranzkoetan gezurra esaten duen interfazea ematen du.

On Demand eta Always On dira benetako palankak

Onartutako palankak profilean bizi dira, ez aplikazioan. On Demand arauek sistemari esaten diote noiz konektatu: baldintza eta ekintzen zerrenda ordenatua, sistema eragileak ebaluatua, ez zure kodeak. Edozein interfazetan konektatzen duen arau batek beti-konektatuta sentipena sortzen du, aplikazio bati kontrolik eman gabe.

Always On VPN da betearazpen-mekanismoa, eta gainbegiratzeari lotuta dago. Gainbegiratutako gailu batean, MDM-k tunela martxan mantentzen duen profil bat instalatzen du; gainbegiratu gabeko telefono pertsonalean gako berberek ez dute jokabide bera sortzen. Asimetria hori nahita egindakoa da, eta karga-gakoen konbinazio batek ere ez du kentzen. Betekizuna benetan VPN-a piztuta egon behar izatea denean, betebeharra gailua kudeatuta egon behar izatea da.

Bien artean lehengusu ahulagoa dago: erabiltzailea deskonektatu ondoren berriro konektatzen duen araua. Araua hurrengoan ebaluatzean konektatzen da, eta hori ez da berehalakoa, eta nahita deskonektatu duen erabiltzaileak aldea nabarituko du. Diseinatu interfazea hutsune horren inguruan, sarrailu bat agindu beharrean.

Bidali onartutako bidea

Lau galderak mekanismoa erabakitzen dute kodea existitu aurretik: nor da gailuaren jabea, gainbegiratuta dagoen, zein bezerok amaitzen duen tunela eta nondik datorren profila. Horietako bat ezezaguna bada, funtzio-eskaera ez dago estimaziorako prest.

Sistemako VPN-a ukitzen duen API pribatuak demo bat gaindituko du eta berrikuspena huts egingo du, eta beste bide batetik bidaltzen bada hurrengo iOS bertsioan hautsiko da. Ez da aldaketa horren bertsio baliotsurik etengailu batengatik.

Kudeaketaren telemetria kanal bereizia da: profil bat instalatuta dagoela eta gailua ados dagoen jakinarazten du, eta hori txostena da, ez aplikazio bakoitzeko kontrol-azalera. Probatu fluxua gailu erreal batean eguneratze bakoitzaren ondoren, onartutako jokabidea sistema eragilean bizi baita eta sistema eragilea mugitzen baita.