Hvorfor iPhone-appen din ikke kan slå systemets VPN på eller av

En produktleder ber om en knapp som slår på selskapets VPN, og forespørselen høres triviell ut. På iOS er dette ikke en liten funksjon; den ligger utenfor den offentlige kontrakten, og hver omvei enten feiler i gjennomgangen eller bryter sammen i neste utgivelse. Kjør forespørselen gjennom det plattformen faktisk tillater, og designet skriver seg stort sett selv. En app kan eie en VPN-konfigurasjon og starte den. En app kan ikke nå systemets bryter, kan ikke lese tilstanden til en profil den ikke har opprettet, og kan ikke holde en bruker tilkoblet mot dennes vilje.

Start med de tre tingene brukeren mener

Skill betydningene før du skiller API-ene. Noen ganger vil brukeren at tunnelen i appen din skal være tilkoblet, noen ganger vil hun slå på bryteren i Innstillinger for en profil noen andre har installert, og noen ganger vil hun at telefonen ikke skal kunne surfe uten tunnelen. Dette svarer til tre forskjellige mekanismer, og bare den første er åpen for en vanlig app.

Den andre betydningen er den som skaper Stack Overflow-spørsmålene, og den har ikke noe støttet svar. Bryteren i Innstillinger tilhører brukeren og, på administrerte enheter, profilen. Ingen offentlig API lister opp VPN-konfigurasjoner, rapporterer om systemtunnelen er oppe eller slår den av og på.

Hva en app faktisk kan opprette

NetworkExtension gir en app sin egen konfigurasjon gjennom NEVPNManager. Med Personal VPN-rettigheten og brukerens samtykke lagrer appen en konfigurasjon som vises i Innstillinger under sitt eget navn, og den kan starte eller stoppe akkurat den ene tilkoblingen. Det er en reell, gjennomgåelig evne, og det er også hele omfanget: lederen leser og skriver bare det den selv har opprettet.

Rettigheten er ikke automatisk. Du ber om den hos Apple og begrunner hvorfor appen i det hele tatt trenger en tunnel, og en klient hvis eneste mål er å slå på noen andres profil har ikke noe godt svar. Pakketunnel-leverandører følger samme regel med en annen klasse: NETunnelProviderManager eier leverandørbaserte konfigurasjoner som appen selv har installert. Ingen av veiene når en profil som MDM har levert.

Samtykke gjelder også ved lagring. Å skrive en konfigurasjon spør brukeren, og det spørsmålet er ikke noe en app kan undertrykke for enkelhets skyld.

Å lese tilstanden treffer samme vegg

Status ser vennligere ut enn kontroll og er like lukket. NEVPNStatus rapporterer ugyldig, frakoblet, kobler til, tilkoblet, bekrefter på nytt eller kobler fra for appens egen konfigurasjon, og det fyres et varsel ved hver endring. Det sier ingenting om en tunnel installert av en administrasjonsprofil, og det er nettopp tilstanden en brukerstøtte vil se.

Nettverksbanemåling og grensesnittendringer tilbys som erstatninger i designgjennomganger. De beskriver banen appens trafikk tar, som endres av grunner uten forbindelse til VPN-tilstanden, og å bruke dem som VPN-avlesning gir et grensesnitt som lyver i begge retninger.

On Demand og Always On er de virkelige spakene

De støttede spakene bor i profilen og ikke i appen. On Demand-regler forteller systemet når det skal koble til: en ordnet liste med betingelser og handlinger, vurdert av operativsystemet, ikke av koden din. En regel som kobler til på et hvilket som helst grensesnitt skaper en følelse av alltid tilkoblet uten å gi noen app kontroll.

Always On VPN er håndhevingsmekanismen, og den er knyttet til overvåking. På en overvåket enhet installerer MDM en profil som holder tunnelen oppe; på en personlig telefon uten overvåking gir de samme nøklene ikke samme atferd. Den asymmetrien er bevisst, og ingen kombinasjon av nyttelastnøkler fjerner den. Når kravet virkelig er at VPN-en må være på, er kravet egentlig at enheten må administreres.

Mellom de to sitter den svakere fetteren: en regel som kobler til igjen etter at brukeren har koblet fra. Den kobler til igjen når regelen vurderes neste gang, noe som ikke er det samme som umiddelbart, og en bruker som koblet fra med vilje vil merke forskjellen. Design grensesnittet rundt det gapet i stedet for å love en lås.

Lever den støttede veien

Fire spørsmål avgjør mekanismen før det finnes noen kode: hvem som eier enheten, om den er overvåket, hvilken klient som avslutter tunnelen og hvor profilen kommer fra. Hvis noe av dette er ukjent, er funksjonsforespørselen ikke klar for estimering.

En privat API som pirker i systemets VPN vil bestå en demo og feile i gjennomgangen, og hvis den leveres på annen måte, bryter den sammen i neste iOS-utgivelse. Det finnes ingen versjon av den handelen som er verdt det for én bryter.

Administrasjonstelemetri er en egen kanal: den rapporterer at en profil er installert og om enheten er i samsvar, noe som er rapportering og ikke en kontrollflate per app. Test flyten på en ekte enhet etter hver oppdatering, fordi den støttede atferden lever i operativsystemet, og operativsystemet beveger seg.