Waarom jou iPhone-app die stelsel-VPN nie aan of af kan skakel nie

’n Produkbestuurder vra vir ’n knoppie wat die maatskappy se VPN aanskakel, en die versoek klink eenvoudig. Op iOS is dit nie ’n klein funksie nie; dit val buite die publieke kontrak, en elke omweg misluk óf die keuring óf die volgende weergawe. Loop die versoek deur wat die platform werklik toelaat, en die ontwerp skryf homself grotendeels. ’n App kan ’n VPN-konfigurasie besit en dit begin. ’n App nie die stelselskakelaar kan bereik nie, nie die toestand van ’n profiel wat dit nie geskep het kan lees nie, en nie ’n gebruiker teen sy wil verbind kan hou nie.

Begin by die drie dinge wat die gebruiker bedoel

Skei die betekenisse voordat jy die API’s skei. Soms wil die gebruiker hê jou app se tonnel moet verbind wees, soms wil hulle die skakelaar in Instellings omdraai vir ’n profiel wat iemand anders geïnstalleer het, en soms wil hulle hê die foon moet nie kan blaai sonder die tonnel nie. Dié drie val op drie verskillende meganismes, en net die eerste is oop vir ’n gewone app.

Die tweede betekenis is wat die Stack Overflow-vrae oplewer, en dit het geen ondersteunde antwoord nie. Die skakelaar in Instellings behoort aan die gebruiker en, op bestuurde toestelle, aan die profiel. Geen publieke API lys VPN-konfigurasies, rapporteer of die stelseltonnel op is, of draai dit om nie.

Wat ’n app werklik kan skep

NetworkExtension gee ’n app ’n eie konfigurasie deur NEVPNManager. Met die Personal VPN-geregtheid en die gebruiker se toestemming stoor die app ’n konfigurasie wat onder sy eie naam in Instellings verskyn, en dit kan daardie een verbinding begin of stop. Dit is ’n werklike, keuringsvatbare vermoë, en dit is ook die hele omvang: die bestuurder lees en skryf net wat dit geskep het.

Die geregtigheid is nie outomaties nie. Jy vra dit by Apple aan en regverdig waarom die app hoegenaamd ’n tonnel nodig het, en ’n kliënt wie se enigste doel is om iemand anders se profiel aan te skakel, het geen goeie antwoord nie. Pakkettonnelverskaffers volg dieselfde reël met ’n ander klas: NETunnelProviderManager besit verskaffergebaseerde konfigurasies wat die app self geïnstalleer het. Nie een van die twee paaie bereik ’n profiel wat MDM afgelewer het nie.

Toestemming geld ook op die oomblik van stoor. Wanneer ’n konfigurasie geskryf word, word die gebruiker gevra, en die versoek is nie iets wat ’n app vir gerief mag onderdruk nie.

Om die toestand te lees, loop teen dieselfde muur vas

Status lyk vriendeliker as beheer en is ewe geslote. NEVPNStatus rapporteer ongeldig, ontkoppel, verbind, gekoppel, herbevestig of ontkoppel vir die app se eie konfigurasie, en ’n kennisgewing vuur by elke verandering. Dit sê niks oor ’n tonnel wat deur ’n bestuursprofiel geïnstalleer is nie, en dit is juis die toestand wat ’n hulpdesk wil sien.

Netwerkpadmonitering en koppelvlakveranderinge word tydens ontwerphersienings as plaasvervangers aangebied. Hulle beskryf die pad wat die app se verkeer volg, wat verander om redes wat niks met die VPN-toestand te doen het nie, en om dit as ’n VPN-aanduiding te gebruik, lewer ’n koppelvlak wat in beide rigtings lieg.

On Demand en Always On is die werklike hefbome

Die ondersteunde hefbome woon in die profiel eerder as in die app. On Demand-reëls sê vir die stelsel wanneer om te verbind: ’n geordende lys voorwaardes met aksies, wat deur die bedryfstelsel geëvalueer word, nie deur jou kode nie. ’n Reël wat op enige koppelvlak verbind, skep ’n altyd-verbind-gevoel sonder om enige app beheer te gee.

Always On VPN is die afdwingmeganisme, en dit is aan toesig gekoppel. Op ’n toestel onder toesig installeer MDM ’n profiel wat die tonnel op hou; op ’n persoonlike foon sonder toesig lewer dieselfde sleutels nie dieselfde gedrag nie. Daardie asimmetrie is doelbewus, en geen kombinasie van vragting-sleutels verwyder dit nie. Wanneer die vereiste werklik is dat die VPN aan moet wees, is die vereiste eintlik dat die toestel bestuur moet word.

Tussen die twee sit die swakker neef: ’n reël wat weer verbind nadat die gebruiker ontkoppel het. Dit verbind weer wanneer die reël volgende geëvalueer word, wat nie dieselfde as onmiddellik is nie, en ’n gebruiker wat doelbewus ontkoppel het, sal die verskil opmerk. Ontwerp die koppelvlak rondom daardie gaping in plaas daarvan om ’n slot te belowe.

Lever die ondersteunde pad

Vier vrae beslis die meganisme voordat enige kode bestaan: wie besit die toestel, of dit onder toesig is, watter kliënt die tonnel beëindig, en waar die profiel vandaan kom. As enige van dié onbekend is, is die kenmerkversoek nie gereed vir beraming nie.

’n Privaat API wat die stelsel-VPN peuter, sal ’n demo slaag en die keuring misluk, en as dit op ’n ander manier verskeep word, breek dit by die volgende iOS-weergawe. Daar is geen weergawe van daardie ruil wat vir ’n skakelaar die moeite werd is nie.

Bestuurstelemetrie is ’n aparte kanaal: dit rapporteer dat ’n profiel geïnstalleer is en of die toestel voldoen, wat verslagdoening is eerder as ’n beheeroppervlak per app. Toets die vloei op ’n werklike toestel na elke opdatering, want die ondersteunde gedrag woon in die bedryfstelsel en die bedryfstelsel beweeg.