Por que o app do seu iPhone não pode ativar nem desativar a VPN do sistema

Um gerente de produto pede um botão que ligue a VPN da empresa, e o pedido parece trivial. No iOS isso não é um recurso pequeno; fica fora do contrato público, e cada contorno ou falha na revisão ou quebra na próxima versão. Passe o pedido pelo que a plataforma realmente permite, e o design praticamente se escreve sozinho. Um app pode possuir uma configuração de VPN e iniciá-la. Um app não consegue alcançar o interruptor do sistema, não consegue ler o estado de um perfil que não criou e não consegue manter um usuário conectado contra a vontade dele.

Comece pelas três coisas que o usuário quer dizer

Separe os significados antes de separar as APIs. Às vezes o usuário quer o túnel do seu app conectado, às vezes quer virar o interruptor em Ajustes para um perfil que outra pessoa instalou, e às vezes quer que o telefone não consiga navegar sem o túnel. Isso corresponde a três mecanismos diferentes, e só o primeiro está aberto a um app comum.

O segundo significado é o que gera as perguntas do Stack Overflow, e não tem resposta suportada. O interruptor em Ajustes pertence ao usuário e, em dispositivos gerenciados, ao perfil. Nenhuma API pública enumera configurações de VPN, informa se o túnel do sistema está ativo nem o alterna.

O que um app realmente pode criar

NetworkExtension dá a um app uma configuração própria por meio de NEVPNManager. Com o direito Personal VPN e o consentimento do usuário, o app salva uma configuração que aparece em Ajustes com o próprio nome, e pode iniciar ou parar essa única conexão. É uma capacidade real e revisável, e é também todo o escopo: o gerenciador só lê e escreve o que criou.

O direito não é automático. Você o pede à Apple e justifica por que o app precisa de um túnel, e um cliente cujo único objetivo é ligar o perfil de outra pessoa não tem boa resposta. Provedores de túneis de pacote seguem a mesma regra com outra classe: NETunnelProviderManager possui configurações baseadas em provedor que o próprio app instalou. Nenhum dos dois caminhos alcança um perfil entregue pelo MDM.

O consentimento também vale no momento de salvar. Escrever uma configuração pergunta ao usuário, e essa pergunta não é algo que um app possa suprimir por conveniência.

Ler o estado esbarra na mesma parede

O estado parece mais amigável que o controle e é igualmente fechado. NEVPNStatus informa inválido, desconectado, conectando, conectado, reafirmando ou desconectando para a configuração do próprio app, e uma notificação dispara a cada mudança. Não diz nada sobre um túnel instalado por um perfil de gerenciamento, e é justamente esse estado que o suporte quer ver.

O monitoramento do caminho de rede e as mudanças de interface são oferecidos como substitutos nas revisões de design. Descrevem o caminho que o tráfego do app percorre, que muda por motivos alheios ao estado da VPN, e usá-los como leitura de VPN dá uma interface que mente nas duas direções.

On Demand e Always On são as alavancas reais

As alavancas suportadas vivem no perfil e não no app. As regras On Demand dizem ao sistema quando conectar: uma lista ordenada de condições com ações, avaliada pelo sistema operacional, não pelo seu código. Uma regra que conecta em qualquer interface cria uma sensação de conexão permanente sem dar nenhum controle ao app.

Always On VPN é o mecanismo de imposição, e está atrelado à supervisão. Num dispositivo supervisionado, o MDM instala um perfil que mantém o túnel ativo; num telefone pessoal não supervisionado as mesmas chaves não produzem o mesmo comportamento. Essa assimetria é deliberada, e nenhuma combinação de chaves de carga útil a elimina. Quando o requisito é mesmo que a VPN precise estar ligada, o requisito é na verdade que o dispositivo precise ser gerenciado.

Entre as duas fica o primo mais fraco: uma regra que reconecta depois que o usuário desconecta. Ela reconecta quando a regra é avaliada da próxima vez, o que não é o mesmo que imediatamente, e um usuário que desconectou de propósito vai notar a diferença. Projete a interface em torno dessa lacuna em vez de prometer um cadeado.

Entregue o caminho suportado

Quatro perguntas definem o mecanismo antes de existir código: quem é dono do dispositivo, se ele é supervisionado, qual cliente encerra o túnel e de onde vem o perfil. Se alguma dessas for desconhecida, o pedido de recurso não está pronto para estimativa.

Uma API privada que mexe na VPN do sistema passa numa demonstração e reprova na revisão, e se for entregue por outro caminho quebra na próxima versão do iOS. Não existe versão dessa troca que valha a pena por um interruptor.

A telemetria de gerenciamento é um canal à parte: informa que um perfil está instalado e se o dispositivo está em conformidade, o que é relatório e não uma superfície de controle por app. Teste o fluxo num dispositivo real depois de cada atualização, porque o comportamento suportado vive no sistema operacional e o sistema operacional se move.