Por que unha app non pode activar un perfil VPN gardado en Android ou iOS

Dous traballos moi distintos arquívanse baixo o nome de VPN programática, e só un deles está dispoñible para unha app corrente en calquera das dúas plataformas móbiles. O primeiro é activar un perfil que o usuario xa gardou; o segundo é construír un túnel dentro do teu propio proceso. Android dache o segundo mediante VpnService e iOS dache o segundo mediante o dereito de Network Extension, mentres que o primeiro queda co sistema, cun propietario do dispositivo ou cun servidor MDM. Descubrir cal necesitas de verdade adoita facer o proxecto máis pequeno.

Dous traballos que comparten nome

Activar un perfil gardado significa dicirlle a un túnel existente que suba: un host, unha credencial, un protocolo, todo xa configurado nalgún lugar que o usuario pode ver. Construír un túnel significa que o teu código posúe a interface, o bucle de paquetes e o protocolo. Parecen similares nun backlog de produto e case non comparten implementación.

Ningunha das dúas plataformas móbiles expón o primeiro a unha app SDK. Unha conexión que aparece sen que o usuario faga nada é indistinguible do malware, así que ambos os sistemas poñen unha porta de consentimento diante de calquera app que transporte tráfico.

Android: unha porta de consentimento e ningunha API de perfís

VpnService existe desde Android 4.0 e permite que unha app cree unha interface tun e despois lea e escriba paquetes. O servizo debe declararse con BIND_VPN_SERVICE, e VpnService.prepare() produce o diálogo do sistema que lle pide ao usuario que o permita. O exemplo da plataforma, ToyVpn, é a declaración máis clara da forma prevista: o teu código posúe a interface e todo o que flúe por ela.

O que non fai é engadir unha entrada á pantalla de axustes de VPN do sistema. Non hai API pública para iso, e a app Axustes garda os seus perfís nun almacén ao que unha app corrente non chega. As chamadas ás clases ocultas desde unha aplicación normal producen perfís que o sistema nunca lista, por iso o código que parecía funcionar nunha compilación deixa de funcionar en silencio na seguinte.

A vía xestionada é separada. Un propietario do dispositivo ou do perfil pode designar un paquete de VPN sempre activo mediante as API de política do dispositivo, e unha ferramenta empresarial pode enviar un perfil que o usuario despois aproba. Iso é autoridade de xestión do dispositivo, non un permiso que unha app solicite ao instalarse. Se o teu cliente é unha organización, esta é a vía para a que hai que planificar; se o teu cliente é unha persoa que instala desde unha tenda, non está dispoñible en absoluto.

iOS: o dereito é a fronteira

iOS divide o mesmo traballo doutra maneira. Un cliente VPN implementa un provedor de túnel de paquetes ou un proxy de app dentro do marco Network Extension, e o dereito correspondente debe concederse á conta de desenvolvedor. Unha configuración de VPN persoal mediante NEVPNManager existe para o caso máis simple, e segue executándose dentro do mesmo modelo de permisos. Apple documenta toda a superficie na referencia de Network Extension, que paga a pena ler antes de delimitar o traballo.

Non hai forma soportada de abrir a pantalla de axustes de VPN, ler as configuracións gardadas do usuario ou iniciar unha delas. O que un cliente pode facer é enviar un perfil de configuración para que o usuario o instale, e despois usar o túnel resultante mediante chamadas de rede correntes. O túnel por app asígnao un servidor MDM mediante unha regra a demanda, non o selecciona a app en tempo de execución.

Un cliente VPN dun provedor grande non é proba de que a túa conta poida enviar o mesmo. Eses dereitos solicítanse por conta de desenvolvedor e revísanse, así que o risco de calendario recae en Apple, non no teu plan de sprint.

O escritorio chega máis lonxe, pero a propiedade non cambia

Windows é o caso permisivo. Add-VpnConnection crea unha entrada de axenda telefónica desde unha sesión de PowerShell elevada, e rasdial conéctaa ou desconéctaa desde un script. Unha app tamén pode dirixir un cliente de provedor mediante a súa liña de comandos documentada. Crear o perfil segue sendo unha acción administrativa, porque a entrada vive nun almacén de toda a máquina.

macOS compórtase igual con outras ferramentas. scutil --nc start e stop operan sobre servizos que xa existen, mentres que crear un é unha tarefa de administración do sistema. Posuír o proceso nun portátil non te converte en propietario da configuración.

Que construír no seu lugar

Se o requisito real é que a túa app chegue a unha API interna, o túnel que o usuario xa executa abonda. Fai peticións HTTPS normais, deixa que o sistema escolla o camiño, e deixa de tentar controlar o túnel. Se o requisito é que só o tráfico da túa app use o túnel, pide VPN por app pola canle de xestión, ou remata TLS dentro da app contra un servizo accesible sen el.

As API ocultas non son un atallo que pague a pena. Cambian entre versións, fallan a revisión de apps, e os fallos que producen parécenlle a quen herda o código fallos de rede correntes. A comparación non é Android contra iOS; é posuír un túnel contra pedirlle á plataforma que encamiñe o tráfico, e só a primeira é túa para construír.