Porque uma app não consegue ativar um perfil VPN guardado no Android ou no iOS

Dois trabalhos muito diferentes são arquivados sob o nome de VPN programática, e só um deles está disponível para uma app comum em qualquer das duas plataformas móveis. O primeiro é ativar um perfil que o utilizador já guardou; o segundo é construir um túnel dentro do seu próprio processo. O Android dá-lhe o segundo através de VpnService e o iOS dá-lhe o segundo através do direito Network Extension, enquanto o primeiro fica com o sistema, um proprietário do dispositivo ou um servidor MDM. Descobrir de qual precisa realmente costuma tornar o projeto mais pequeno.

Dois trabalhos que partilham um nome

Ativar um perfil guardado significa dizer a um túnel existente para subir: um anfitrião, uma credencial, um protocolo, tudo já configurado num local que o utilizador pode ver. Construir um túnel significa que o seu código é dono da interface, do ciclo de pacotes e do protocolo. Parecem-se num backlog de produto e quase não partilham implementação.

Nenhuma das duas plataformas móveis expõe o primeiro a uma app SDK. Uma ligação que aparece sem o utilizador fazer nada é indistinguível de software malicioso, por isso ambos os sistemas colocam um portão de consentimento à frente de qualquer app que transporte tráfego.

Android: um portão de consentimento e nenhuma API de perfis

VpnService existe desde o Android 4.0 e permite que uma app crie uma interface tun e depois leia e escreva pacotes. O serviço tem de ser declarado com BIND_VPN_SERVICE, e VpnService.prepare() produz a caixa de diálogo do sistema que pede ao utilizador que o permita. O exemplo da plataforma, ToyVpn, é a declaração mais clara da forma pretendida: o seu código é dono da interface e de tudo o que flui através dela.

O que não faz é acrescentar uma entrada ao ecrã de definições de VPN do sistema. Não existe API pública para isso, e a app Definições guarda os seus perfis num armazém a que uma app comum não chega. As chamadas às classes ocultas a partir de uma aplicação normal produzem perfis que o sistema nunca lista, e é por isso que o código que parecia funcionar numa compilação deixa de funcionar em silêncio na seguinte.

A via gerida é separada. Um proprietário do dispositivo ou do perfil pode designar um pacote de VPN sempre ativo através das APIs de política do dispositivo, e uma ferramenta empresarial pode enviar um perfil que o utilizador depois aprova. Isso é autoridade de gestão do dispositivo, não uma permissão que uma app pede na instalação. Se o seu cliente é uma organização, é esta a via para a qual deve planear; se o seu cliente é uma pessoa que instala a partir de uma loja, não está disponível de todo.

iOS: o direito é a fronteira

O iOS divide o mesmo trabalho de forma diferente. Um cliente VPN implementa um fornecedor de túnel de pacotes ou um proxy de app no âmbito da framework Network Extension, e o direito correspondente tem de ser concedido à conta de programador. Uma configuração de VPN pessoal através de NEVPNManager existe para o caso mais simples, e continua a correr no mesmo modelo de permissões. A Apple documenta toda a superfície na referência Network Extension, que vale a pena ler antes de delimitar o trabalho.

Não há forma suportada de abrir o ecrã de definições de VPN, ler as configurações guardadas do utilizador ou iniciar uma delas. O que um cliente pode fazer é enviar um perfil de configuração para o utilizador instalar, e depois usar o túnel resultante através de chamadas de rede comuns. O túnel por app é atribuído por um servidor MDM através de uma regra a pedido, não é escolhido pela app em tempo de execução.

Um cliente VPN de um grande fornecedor não é prova de que a sua conta possa enviar o mesmo. Esses direitos são pedidos por conta de programador e revistos, por isso o risco de calendário recai na Apple, não no seu plano de sprint.

O ambiente de trabalho chega mais longe, mas a propriedade não muda

O Windows é o caso permissivo. Add-VpnConnection cria uma entrada de livro de telefone a partir de uma sessão PowerShell elevada, e rasdial liga-a ou desliga-a a partir de um script. Uma app também pode conduzir um cliente de fornecedor através da sua linha de comandos documentada. Criar o perfil continua a ser uma ação administrativa, porque a entrada vive num armazém de toda a máquina.

O macOS comporta-se da mesma forma com outras ferramentas. scutil --nc start e stop operam sobre serviços que já existem, enquanto criar um é uma tarefa de administração do sistema. Possuir o processo num portátil não o torna proprietário da configuração.

O que construir em vez disso

Se o requisito real é que a sua app chegue a uma API interna, o túnel que o utilizador já executa é suficiente. Faça pedidos HTTPS normais, deixe o sistema escolher o caminho, e pare de tentar controlar o túnel. Se o requisito é que só o tráfego da sua app use o túnel, peça VPN por app através do canal de gestão, ou termine TLS dentro da app contra um serviço acessível sem ele.

As API ocultas não são um atalho que valha a pena. Mudam entre versões, falham a revisão de apps, e as falhas que produzem parecem a quem herda o código falhas de rede comuns. A comparação não é Android contra iOS; é possuir um túnel contra pedir à plataforma que encaminhe tráfego, e só a primeira é sua para construir.