Kvifor iPhone-appen din ikkje kan slå systemets VPN på eller av

Ein produktleiar ber om ein knapp som slår på selskapets VPN, og førespurnaden høyrest triviell ut. På iOS er dette ikkje ein liten funksjon; han ligg utanfor den offentlege kontrakten, og kvar omveg anten feilar i gjennomgangen eller bryt saman i neste utgåve. Køyr førespurnaden gjennom det plattforma faktisk tillèt, og designet skriv seg stort sett sjølv. Ein app kan eige ein VPN-konfigurasjon og starte han. Ein app kan ikkje nå systembrytaren, kan ikkje lese tilstanden til ein profil han ikkje sjølv har oppretta, og kan ikkje halde ein brukar tilkopla mot hans vilje.

Start med dei tre tinga brukaren meiner

Skil tydingane før du skil API-a. Nokre gonger vil brukaren at tunnelen i appen din skal vere tilkopla, nokre gonger vil ho slå på brytaren i Innstillingar for ein profil nokon andre har installert, og nokre gonger vil ho at telefonen ikkje skal kunne surfe utan tunnelen. Dette svarar til tre ulike mekanismar, og berre den første er open for ein vanleg app.

Den andre tydinga er den som skapar Stack Overflow-spørsmåla, og ho har ikkje noko støtta svar. Brytaren i Innstillingar høyrer til brukaren og, på styrte einingar, profilen. Ingen offentleg API listar opp VPN-konfigurasjonar, rapporterer om systemtunnelen er oppe eller slår han av og på.

Kva ein app faktisk kan opprette

NetworkExtension gir ein app sin eigen konfigurasjon gjennom NEVPNManager. Med Personal VPN-rettigheita og samtykket til brukaren lagrar appen ein konfigurasjon som visest i Innstillingar under sitt eige namn, og han kan starte eller stoppe akkurat den eine tilkoplinga. Det er ei reell, gjennomgåeleg evne, og det er også heile omfanget: leiaren les og skriv berre det han sjølv har oppretta.

Rettigheita er ikkje automatisk. Du ber om ho hos Apple og grunngir kvifor appen i det heile treng ein tunnel, og ein klient med det einaste målet å slå på profilen til nokon andre har ikkje noko godt svar. Pakketunnel-leverandørar følgjer same regel med ein annan klasse: NETunnelProviderManager eig leverandørbaserte konfigurasjonar som appen sjølv har installert. Ingen av vegane når ein profil som MDM har levert.

Samtykke gjeld også ved lagring. Å skrive ein konfigurasjon spør brukaren, og det spørsmålet er ikkje noko ein app kan undertrykkje for enkelheit skuld.

Å lese tilstanden treff same veggen

Status ser venlegare ut enn kontroll og er like lukka. NEVPNStatus rapporterer ugyldig, fråkopla, koplar til, tilkopla, stadfester på nytt eller koplar frå for appen sin eigen konfigurasjon, og det blir fyrt av eit varsel ved kvar endring. Det seier ingenting om ein tunnel installert av ein administrasjonsprofil, og det er nettopp tilstanden ein brukarstøtte vil sjå.

Nettverksbanemåling og grensesnittendringar blir bodne som erstatningar i designgjennomgangar. Dei skildrar bana trafikken til appen tek, som endrar seg av grunnar utan samband med VPN-tilstanden, og å bruke dei som VPN-avlesing gir eit grensesnitt som lyg i begge retningar.

On Demand og Always On er dei verkelege spakane

Dei støtta spakane bur i profilen og ikkje i appen. On Demand-reglar fortel systemet når det skal kople til: ei ordna liste med vilkår og handlingar, vurdert av operativsystemet, ikkje av koden din. Ein regel som koplar til på eit kva som helst grensesnitt skapar ei kjensle av alltid tilkopla utan å gi nokon app kontroll.

Always On VPN er handhevingsmekanismen, og han er knytt til overvaking. På ei overvaka eining installerer MDM ein profil som held tunnelen oppe; på ein personleg telefon utan overvaking gir dei same nøklane ikkje same åtferd. Den asymmetrien er medvite, og ingen kombinasjon av nyttelastnøklar fjernar han. Når kravet verkeleg er at VPN-en må vere på, er kravet eigentleg at eininga må styrast.

Mellom dei to sit den svakare fetteren: ein regel som koplar til att etter at brukaren har kopla frå. Han koplar til att når regelen blir vurdert neste gong, noko som ikkje er det same som straks, og ein brukar som kopla frå med vilje vil merke skillnaden. Design grensesnittet rundt det gapet i staden for å love ein lås.

Lever den støtta vegen

Fire spørsmål avgjer mekanismen før det finst nokon kode: kven som eig eininga, om ho er overvaka, kva klient som avsluttar tunnelen og kvar profilen kjem frå. Viss noko av dette er ukjent, er funksjonsførespurnaden ikkje klar for estimering.

Ein privat API som pirkar i systemets VPN vil bestå ein demo og feile i gjennomgangen, og viss han blir levert på annan måte, bryt han saman i neste iOS-utgåve. Det finst ingen versjon av den handelen som er verd det for éin brytar.

Administrasjonstelemetri er ein eigen kanal: han rapporterer at ein profil er installert og om eininga er i samsvar, noko som er rapportering og ikkje ein kontrollflate per app. Test flyten på ei ekte eining etter kvar oppdatering, fordi den støtta åtferda lever i operativsystemet, og operativsystemet flyttar seg.