VPN por aplicativo em apps iPhone gerenciados: o que é roteado e o que não é
Um túnel por aplicativo segue o app gerenciado, não o telefone. Verifique a associação do payload, a cópia gerenciada, as regras sob demanda e os fluxos que saem do app.
VPN por aplicativo no iPhone não é um interruptor para o telefone inteiro. É uma associação entre um app gerenciado e um payload VPN, criada quando o app é implantado, e o tráfego de todo o resto mantém a rota que tinha antes. Por isso o mesmo telefone se comporta de forma inconsistente: o app de trabalho abre uma página privada enquanto o Safari não alcança o mesmo host, ou o túnel nunca sobe e o app relata um tempo limite que parece credencial errada. As verificações vão da causa mais ampla para baixo, então pare na primeira que falhar.
Verifique primeiro o payload e o registro do app
A associação vive em dois objetos, não em um. O payload VPN define o túnel: tipo, servidor, autenticação, DNS e o identificador de pacote do provedor quando um cliente personalizado é usado. O registro do app aponta para esse payload, e a maioria dos consoles de gerenciamento oferece isso como opção por aplicativo na configuração do app, com um nome próximo de Per-App VPN. Um payload para o qual nenhum app aponta não roteia nada por aplicativo; ele se comporta como um túnel comum que alguém precisa iniciar manualmente.
Leia os dois objetos antes de tocar no telefone. Confirme que a configuração do app aponta para o payload que você está testando e não para uma cópia antiga, porque payloads duplicados com nomes quase iguais são comuns após migração e o app aponta alegremente para o retirado. Depois confirme que a configuração chegou ao dispositivo: Ajustes, Geral, VPN e Gerenciamento do Dispositivo devem mostrá-la como perfil instalado. A lista de VPN ali não é o teste. Um serviço por aplicativo normalmente não tem interruptor manual, então uma configuração implantada corretamente pode nunca aparecer entre as VPNs que podem ser iniciadas. A ausência aparece no registro do app e em se o túnel sobe na primeira requisição do app.
Uma condição explica muitos tickets: este modelo exige que o app chegue pela gestão. Uma cópia instalada por fora ou comprada pessoalmente não recebe a associação, mesmo quando o identificador de pacote corresponde. O guia de implantação de VPN da Apple descreve o modelo de payload por trás disso (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
Confirme que o app instalado é a cópia gerenciada
A associação segue o app instalado e gerenciado. Se alguém o reinstalou pela App Store com um Apple ID pessoal, substituiu por uma build corporativa reassinada, ou o dispositivo foi registrado novamente e o app voltou por outro canal, o túnel pode ficar em baixo enquanto o app em si parece perfeitamente normal.
Teste por comparação, não com uma única observação. No inventário de gestão, o app deve aparecer como gerenciado para aquele dispositivo com o mapeamento de VPN no registro. No telefone, o túnel deve subir quando o app é iniciado e sua primeira requisição sai, não apenas quando alguém inicia uma configuração manual separada em Ajustes. Se iniciar o app não muda nada e essa configuração manual muda, o app não está ligado a um túnel por aplicativo de jeito nenhum.
Atualizações importam: a enviada pela gestão mantém o mapeamento, enquanto uma reinstalação iniciada pelo usuário pode perdê-lo. Quando o relato data de uma atualização, verifique o registro do app antes da rede.
Verifique o que o túnel pode levar
Um túnel por aplicativo é escolhido pelo app de origem, então a rota padrão do telefone ainda pertence ao Wi-Fi ou à rede celular. OverridePrimary é a chave que muda isso. Quando um perfil a define, o túnel se comporta como um túnel completo e todo app o herda, então tudo que passa pela VPN vira questão de perfil e não falha do app.
As regras sob demanda decidem a persistência. OnDemandEnabled e seu conjunto de regras trazem o túnel de volta quando o app envia tráfego, sobrevivem à troca de Wi-Fi para celular ou derrubam quando o app vai para o segundo plano. Uma implantação que conecta e depois morre em silêncio normalmente tem uma regra que só corresponde a uma sondagem que nunca dispara enquanto o app está ocioso.
Depois leia o lado das rotas com honestidade. Se o perfil do provedor ou do fornecedor fornece uma lista de inclusão, um túnel que carrega apenas 10.20.0.0/16 não carregará serviço em 10.30.0.0/16; é a lista fazendo seu trabalho, não uma falha por aplicativo. O payload iOS integrado não tem lista de inclusão. Sem ela, a divisão segue os padrões do provedor e o IncludeAllNetworks, não uma lista escondida.
Teste o app, depois teste o que sai dele
Teste com nome, não apenas com endereço. Resolver um host interno dentro do app gerenciado prova que o DNS também passou pelo túnel, porque o payload decide qual resolvedor responde e quais domínios de busca valem. O roteamento pode estar perfeito enquanto a busca de nome falha, e os dois sintomas apontam para configurações diferentes.
Depois teste a fronteira dos dois lados. Um app pessoal ou o Safari deve alcançar uma página pública comum e relatar o endereço da operadora ou de casa, enquanto o app gerenciado alcança o serviço privado. Se ambos relatarem o mesmo endereço público, o túnel não é mais por aplicativo, diga o que disser o registro do app.
Os fluxos que saem do app criam tickets confusos. Um link que abre no Safari, um documento passado pela folha de compartilhamento ou um login SSO que muda para um navegador deixam o processo do app e o túnel junto com ele. Um login mostrado dentro do app é normalmente atribuído ao app, então um login embutido pode funcionar onde a mesma URL falha no Safari; verifique isso em vez de presumir. Quando o provedor de identidade só é acessível pelo túnel, mantenha o login dentro do app ou adicione o domínio do provedor aos domínios Safari do payload para que o tráfego Safari correspondente seja capturado.
Combine o sintoma com a camada
A forma da falha diz qual verificação repetir.
| What you see | Where the repair is |
|---|---|
| Tunnel never appears when the app opens | App-to-payload association, or the app is not the managed copy |
| Tunnel connects, internal name resolves, connection times out | Provider or vendor include list missing the subnet, or a far-side firewall |
| Tunnel connects, internal name fails to resolve | DNS servers or search domains in the payload |
| Every app uses the tunnel | OverridePrimary set, or a full-tunnel payload reused |
| Worked until an update, broken since | Association lost on reinstall, or the payload was replaced |
Atrás das linhas do meio estão dois detalhes: um túnel por aplicativo pode estar saudável e ainda perder uma sub-rede que nenhuma lista de provedor inclui, e um telefone gerenciado pode manter mais de uma configuração de VPN, então confirme a qual o app está vinculado em vez de supor que é a que você está lendo.
Corrija nesta ordem: aponte o registro do app para o payload ativo, reinstale o app pela gestão, confirme que o túnel sobe na primeira requisição do app e repita os testes de nome e fronteira. Se a primeira requisição não consegue iniciar túnel nenhum, pare e verifique o lado do provedor, porque um cliente personalizado precisa de Network Extension presente e de um identificador que corresponda ao app instalado.
Devolva três fatos em vez de uma captura de tela: para qual payload o registro do app aponta, se Ajustes o mostra como perfil instalado e qual foi a requisição que falhou — um nome, um endereço ou uma transferência para o navegador. Essas três respostas separam erro de implantação de erro de roteamento, e a próxima pessoa pode agir sem repetir o diagnóstico.