Per què una app no pot activar un perfil VPN desat a Android o iOS

Dues feines molt diferents s’agrupen sota el nom de VPN programàtic, i només una d’elles està disponible per a una app corrent en qualsevol de les dues plataformes mòbils. La primera és activar un perfil que l’usuari ja ha desat; la segona és construir un túnel dins del teu propi procés. Android et dona la segona mitjançant VpnService i iOS et dona la segona mitjançant el dret de Network Extension, mentre que la primera queda amb el sistema, un propietari del dispositiu o un servidor MDM. Esbrinar quina necessites realment sol fer el projecte més petit.

Dues feines que comparteixen nom

Activar un perfil desat vol dir dir a un túnel existent que s’aixequi: un amfitrió, una credencial, un protocol, tot ja configurat en algun lloc que l’usuari pot veure. Construir un túnel vol dir que el teu codi posseeix la interfície, el bucle de paquets i el protocol. S’assemblen en un backlog de producte i gairebé no comparteixen implementació.

Cap de les dues plataformes mòbils exposa la primera a una app SDK. Una connexió que apareix sense que l’usuari faci res és indistingible de programari maliciós, així que tots dos sistemes posen una porta de consentiment davant de qualsevol app que transporti trànsit.

Android: una porta de consentiment i cap API de perfils

VpnService existeix des d’Android 4.0 i permet que una app creï una interfície tun i després llegeixi i escrigui paquets. El servei s’ha de declarar amb BIND_VPN_SERVICE, i VpnService.prepare() produeix el diàleg del sistema que demana a l’usuari que ho permeti. L’exemple de la plataforma, ToyVpn, és la declaració més clara de la forma prevista: el teu codi posseeix la interfície i tot el que hi passa.

El que no fa és afegir una entrada a la pantalla de configuració de VPN del sistema. No hi ha cap API pública per a això, i l’app Configuració guarda els seus perfils en un magatzem on una app corrent no pot arribar. Les crides a les classes ocultes des d’una aplicació normal produeixen perfils que el sistema mai no llista, i per això el codi que semblava funcionar en una compilació deixa de funcionar en silenci en la següent.

La via gestionada és separada. Un propietari del dispositiu o del perfil pot designar un paquet de VPN sempre actiu mitjançant les API de política del dispositiu, i una eina empresarial pot enviar un perfil que l’usuari després aprova. Això és autoritat de gestió del dispositiu, no un permís que una app demani en instal·lar-se. Si el teu client és una organització, aquesta és la via per a la qual has de planificar; si el teu client és una persona que instal·la des d’una botiga, no està disponible de cap manera.

iOS: el dret és la frontera

iOS divideix la mateixa feina d’una altra manera. Un client VPN implementa un proveïdor de túnel de paquets o un proxy d’app dins del marc Network Extension, i el dret corresponent s’ha de concedir al compte de desenvolupador. Una configuració de VPN personal mitjançant NEVPNManager existeix per al cas més simple, i encara s’executa dins del mateix model de permisos. Apple documenta tota la superfície a la referència de Network Extension, que val la pena llegir abans d’abastar la feina.

No hi ha cap manera suportada d’obrir la pantalla de configuració de VPN, llegir les configuracions desades de l’usuari o iniciar-ne una. El que un client pot fer és enviar un perfil de configuració perquè l’usuari l’instal·li, i després utilitzar el túnel resultant mitjançant crides de xarxa corrents. El túnel per app l’assigna un servidor MDM mitjançant una regla a demanda, no el selecciona l’app en temps d’execució.

Un client VPN d’un proveïdor gran no és prova que el teu compte pugui enviar el mateix. Aquests drets es demanen per compte de desenvolupador i es revisen, així que el risc de calendari recau en Apple, no en el teu pla d’sprint.

L’escriptori arriba més lluny, però la propietat no canvia

Windows és el cas permissiu. Add-VpnConnection crea una entrada de llibreta telefònica des d’una sessió de PowerShell elevada, i rasdial la connecta o la desconnecta des d’un script. Una app també pot conduir un client de proveïdor mitjançant la seva línia d’ordres documentada. Crear el perfil continua sent una acció administrativa, perquè l’entrada viu en un magatzem de tota la màquina.

macOS es comporta igual amb eines diferents. scutil --nc start i stop operen sobre serveis que ja existeixen, mentre que crear-ne un és una tasca d’administració del sistema. Posseir el procés en un portàtil no et converteix en propietari de la configuració.

Què construir en lloc d’això

Si el requisit real és que la teva app arribi a una API interna, el túnel que l’usuari ja executa és suficient. Fes peticions HTTPS normals, deixa que el sistema triï el camí, i deixa d’intentar controlar el túnel. Si el requisit és que només el trànsit de la teva app utilitzi el túnel, demana VPN per app pel canal de gestió, o acaba TLS dins de l’app contra un servei accessible sense túnel.

Les API ocultes no són una drecera que valgui la pena. Canvien entre versions, fallen la revisió d’apps, i les fallades que produeixen semblen a qui hereta el codi fallades de xarxa corrents. La comparació no és Android contra iOS; és posseir un túnel contra demanar a la plataforma que encamini el trànsit, i només la primera és teva per construir.