Per què la teva app d’iPhone no pot activar ni desactivar la VPN del sistema

Un cap de producte demana un botó que encengui la VPN de l’empresa, i la petició sona trivial. A l’iOS no és una funció petita; queda fora del contracte públic, i qualsevol solució alternativa o fracassa a la revisió o es trenca a la versió següent. Passa la petició pel que la plataforma permet de veritat i el disseny gairebé s’escriu sol. Una app pot tenir una configuració de VPN i engegar-la. Una app no pot arribar a l’interruptor del sistema, no pot llegir l’estat d’un perfil que no ha creat i no pot mantenir un usuari connectat contra la seva voluntat.

Comença per les tres coses que vol dir l’usuari

Separa els significats abans de separar les API. De vegades l’usuari vol que el túnel de la teva app estigui connectat, de vegades vol que l’interruptor d’Ajustos s’activi per a un perfil que ha instal·lat una altra persona, i de vegades vol que el telèfon no pugui navegar sense el túnel. Això correspon a tres mecanismes diferents, i només el primer és obert a una app corrent.

El segon significat és el que genera les preguntes de Stack Overflow, i no té cap resposta suportada. L’interruptor d’Ajustos és de l’usuari i, als dispositius gestionats, del perfil. Cap API pública enumera configuracions de VPN, informa si el túnel del sistema està aixecat ni el commuta.

Què pot crear realment una app

NetworkExtension dona a una app una configuració pròpia mitjançant NEVPNManager. Amb el dret Personal VPN i el consentiment de l’usuari, l’app desa una configuració que apareix a Ajustos amb el seu propi nom, i pot engegar o aturar aquella única connexió. És una capacitat real i revisable, i també és tot l’abast: el gestor només llegeix i escriu el que ha creat.

El dret no és automàtic. El demanes a Apple i justifiques per què l’app necessita un túnel, i un client l’únic objectiu del qual és encendre el perfil d’una altra persona no té bona resposta. Els proveïdors de túnels de paquets segueixen la mateixa regla amb una classe diferent: NETunnelProviderManager posseeix configuracions basades en proveïdor que la mateixa app ha instal·lat. Cap dels dos camins arriba a un perfil lliurat per l’MDM.

El consentiment també s’aplica en el moment de desar. Escriure una configuració demana confirmació a l’usuari, i aquesta petició no és una cosa que una app pugui suprimir per comoditat.

Llegir l’estat xoca amb la mateixa paret

L’estat sembla més amable que el control i és igual de tancat. NEVPNStatus informa de no vàlid, desconnectat, connectant, connectat, reafirmant o desconnectant per a la configuració pròpia de l’app, i s’envia una notificació a cada canvi. No diu res d’un túnel instal·lat per un perfil de gestió, que és l’estat que un servei d’ajuda vol veure de veritat.

El monitoratge del camí de xarxa i els canvis d’interfície s’ofereixen com a substituts a les revisions de disseny. Descriuen el camí que segueix el trànsit de l’app, que canvia per motius aliens a l’estat de la VPN, i fer-los servir com a indicador de VPN dona una interfície que menteix en totes dues direccions.

On Demand i Always On són les palanques reals

Les palanques suportades viuen al perfil i no a l’app. Les regles On Demand diuen al sistema quan ha de connectar: una llista ordenada de condicions amb accions, avaluada pel sistema operatiu i no pel teu codi. Una regla que connecta a qualsevol interfície crea una sensació de connexió permanent sense donar cap control a l’app.

Always On VPN és el mecanisme d’aplicació forçosa, i va lligat a la supervisió. En un dispositiu supervisat, l’MDM instal·la un perfil que manté el túnel aixecat; en un telèfon personal no supervisat les mateixes claus no produeixen el mateix comportament. Aquesta asimetria és deliberada, i cap combinació de claus de càrrega útil no l’elimina. Quan el requisit és de veritat que la VPN ha d’estar encesa, el requisit és en realitat que el dispositiu ha d’estar gestionat.

Entremig hi ha el cosí més feble: una regla que reconnecta després que l’usuari es desconnecti. Reconnecta quan la regla es torna a avaluar, cosa que no és el mateix que immediatament, i un usuari que s’ha desconnectat a posta notarà la diferència. Dissenya la interfície al voltant d’aquest buit en lloc de prometre un pany.

Publica el camí suportat

Quatre preguntes fixen el mecanisme abans que existeixi cap codi: qui té el dispositiu, si està supervisat, quin client acaba el túnel i d’on ve el perfil. Si una d’aquestes coses és desconeguda, la petició de funcionalitat no està a punt per estimar.

Una API privada que toqui la VPN del sistema passarà una demo i suspendrà la revisió, i si s’envia per una altra via es trenca a la versió següent d’iOS. No hi ha cap versió d’aquest intercanvi que valgui la pena per un interruptor.

La telemetria de gestió és un canal a part: informa que un perfil està instal·lat i si el dispositiu és conforme, cosa que és informar i no una superfície de control per app. Prova el flux en un dispositiu real després de cada actualització, perquè el comportament suportat viu al sistema operatiu i el sistema operatiu es mou.