Hvorfor din iPhone-app ikke kan tænde eller slukke for systemets VPN

En produktchef beder om en knap, der tænder virksomhedens VPN, og anmodningen lyder triviel. På iOS er det ikke en lille funktion; den ligger uden for den offentlige kontrakt, og enhver omvej fejler enten i anmeldelsen eller brækker i næste udgivelse. Kør anmodningen gennem det, platformen faktisk tillader, og designet skriver stort set sig selv. En app kan eje en VPN-konfiguration og starte den. En app kan ikke nå systemets kontakt, kan ikke læse tilstanden af en profil, den ikke selv har oprettet, og kan ikke holde en bruger forbundet mod dennes vilje.

Start med de tre ting, brugeren mener

Adskil betydningerne, før du adskiller API'erne. Nogle gange vil brugeren have din apps tunnel forbundet, nogle gange vil de have kontakten i Indstillinger slået til for en profil, en anden har installeret, og nogle gange vil de have telefonen til ikke at kunne browse uden tunnelen. Det svarer til tre forskellige mekanismer, og kun den første er åben for en almindelig app.

Den anden betydning er den, der skaber Stack Overflow-spørgsmålene, og den har intet understøttet svar. Kontakten i Indstillinger tilhører brugeren og, på administrerede enheder, profilen. Ingen offentlig API opregner VPN-konfigurationer, rapporterer om systemets tunnel er oppe eller slår den til.

Hvad en app faktisk kan oprette

NetworkExtension giver en app en konfiguration af dens egen gennem NEVPNManager. Med Personal VPN-rettigheden og brugerens samtykke gemmer appen en konfiguration, der vises i Indstillinger under dens eget navn, og den kan starte eller stoppe netop den forbindelse. Det er en reel, anmeldelsesdygtig evne, og det er også hele omfanget: manageren læser og skriver kun det, den selv har oprettet.

Rettigheden er ikke automatisk. Du anmoder om den hos Apple og begrunder, hvorfor appen overhovedet har brug for en tunnel, og en klient, hvis eneste mål er at tænde en andens profil, har ikke noget godt svar. Pakketunneludbydere følger samme regel med en anden klasse: NETunnelProviderManager ejer udbyderbaserede konfigurationer, som appen selv har installeret. Ingen af vejene når en profil, som MDM har leveret.

Samtykke gælder også på gemningstidspunktet. At skrive en konfiguration spørger brugeren, og den forespørgsel er ikke noget, en app må undertrykke for nemheds skyld.

At læse tilstanden rammer den samme mur

Status ser venligere ud end kontrol og er lige så lukket. NEVPNStatus rapporterer ugyldig, afbrudt, forbinder, forbundet, genbekræfter eller afbryder for appens egen konfiguration, og der udløses en notifikation ved hver ændring. Den siger intet om en tunnel installeret af en administrationsprofil, og det er netop den tilstand, en servicedesk vil se.

Netværksstimonitorering og interfaceændringer tilbydes som erstatninger under designgennemgange. De beskriver den vej, appens trafik tager, som ændrer sig af grunde uden forbindelse til VPN-tilstanden, og at bruge dem som VPN-aflæsning giver en brugerflade, der lyver i begge retninger.

On Demand og Always On er de rigtige håndtag

De understøttede håndtag bor i profilen frem for i appen. On Demand-regler fortæller systemet, hvornår der skal forbindes: en ordnet liste af betingelser med handlinger, vurderet af operativsystemet, ikke af din kode. En regel, der forbinder på ethvert interface, skaber en følelse af altid-forbundet uden at give nogen app kontrol.

Always On VPN er håndhævelsesmekanismen, og den er bundet til overvågning. På en overvåget enhed installerer MDM en profil, der holder tunnelen oppe; på en personlig telefon uden overvågning giver de samme nøgler ikke samme adfærd. Den asymmetri er bevidst, og ingen kombination af nyttelastsnøgler fjerner den. Når kravet virkelig er, at VPN skal være tændt, er kravet i virkeligheden, at enheden skal administreres.

Mellem de to sidder den svagere fætter: en regel, der genopretter forbindelsen, efter brugeren har afbrudt. Den genopretter, når reglen næste gang vurderes, hvilket ikke er det samme som øjeblikkeligt, og en bruger, der afbrød med vilje, vil bemærke forskellen. Design brugerfladen omkring det hul i stedet for at love en lås.

Udgiv den understøttede vej

Fire spørgsmål afgør mekanismen, før der findes nogen kode: hvem ejer enheden, om den er overvåget, hvilken klient der afslutter tunnelen, og hvor profilen kommer fra. Hvis noget af det er ukendt, er funktionsanmodningen ikke klar til estimering.

En privat API, der piller ved systemets VPN, består en demo og fejler i anmeldelsen, og hvis den udgives ad andre veje, brækker den i næste iOS-udgivelse. Der findes ingen version af den handel, der er værd at gøre for en kontakt.

Administrationstelemetri er en separat kanal: den rapporterer, at en profil er installeret, og om enheden er compliant, hvilket er rapportering og ikke en kontrolflade per app. Test flowet på en rigtig enhed efter hver opdatering, fordi den understøttede adfærd bor i OS'et, og OS'et bevæger sig.