Aplicativo VPN ou IKEv2 integrado no iPhone: como escolher
Um aplicativo VPN para iPhone e o cliente IKEv2 integrado resolvem problemas diferentes. Compare primeiro suporte a protocolos, autenticação, controle do aparelho e recuperação.
Na semana passada, um colega me entregou o iPhone dele com duas entradas de VPN nos Ajustes: uma deixada por um aplicativo de provedor, outra de um perfil IKEv2 copiado de uma página de suporte. Não são versões concorrentes da mesma coisa. Um aplicativo de provedor é um contêiner que pode trazer o próprio código de túnel, enquanto o cliente integrado da Apple é um cliente IKEv2, configurado à mão ou por um perfil. Protocolo, tratamento de credenciais, controle do aparelho e recuperação decidem a escolha.
O aplicativo e o cliente nativo ficam em camadas diferentes
O cliente VPN integrado da Apple é, na prática, um cliente IKEv2. O formulário manual ainda lista a opção obsoleta de L2TP sobre IPsec e as opções Cisco IPsec, mas não há campo de transporte de fornecedor nem onde colar uma configuração OpenVPN ou WireGuard. Ou você preenche um formulário em Ajustes > Geral > VPN & Gerenciamento do Dispositivo, ou importa um perfil com um payload de VPN; a superfície é um endereço de servidor, duas identidades, um método de autenticação e regras opcionais sob demanda.
Um aplicativo de provedor trabalha uma camada acima. Ele inclui um provedor de túnel de pacotes da Network Extension, então o código do protocolo e a lógica de roteamento ficam no aplicativo e o iOS apenas repassa pacotes. Alguns aplicativos implementam WireGuard ou OpenVPN, outros um transporte ofuscado próprio, e alguns apenas instalam um perfil IKEv2 e controlam o cliente nativo por trás de uma tela mais agradável. É esse último grupo que às vezes torna falsa a escolha entre aplicativo e perfil.
A consequência é prática: um arquivo .ovpn ou WireGuard não substitui esses campos, porque o handshake é outro protocolo.
Leia o payload antes de comparar recursos
Quando o perfil é IKEv2, as chaves do payload explicam mais falhas do que qualquer comparação de recursos. A referência de ajustes do IKEv2 da Apple documenta cada chave; um payload resumido se parece com isto:
<key>VPNType</key><string>IKEv2</string>
<key>RemoteAddress</key><string>vpn.example.net</string>
<key>RemoteIdentifier</key><string>vpn.example.net</string>
<key>LocalIdentifier</key><string>[email protected]</string>
<key>AuthenticationMethod</key><string>Certificate</string>
<key>ServerCertificateIssuerCommonName</key><string>Example Issuing CA</string>Três campos concentram a maior parte do peso do diagnóstico. RemoteIdentifier é o nome que o cliente espera que o servidor apresente, então um gateway atrás de NAT ou um balanceador cujo certificado nomeia o pool em vez do endereço falha embora o endereço esteja certo. LocalIdentifier é quem o servidor acha que você é, e com autenticação por certificado precisa corresponder à identidade mapeada para sua conta. ServerCertificateIssuerCommonName fixa a CA emissora, então um perfil pode falhar no dia em que o certificado é reemitido, sem nenhuma mensagem de erro mencionando certificados.
Se AuthenticationMethod for SharedSecret, o servidor está fazendo autenticação de usuário EAP e o segredo que lhe deram é na verdade uma credencial de conta. Isso importa quando um provedor envia dois documentos, um para nome de usuário e senha e outro para um certificado, e apenas um corresponde ao que você importou.
O que o aplicativo pode fazer e o cliente nativo não
A escolha do protocolo é a vantagem óbvia. Se o seu servidor fala WireGuard ou OpenVPN, um aplicativo é o único cliente iOS capaz de usá-lo, e editar o formulário nativo não vai negociá-lo. Um aplicativo também pode implementar túnel dividido por destino ou por aplicativo, tratamento próprio de DNS, um bloqueio no estilo kill switch, seleção de servidor e reconexão ajustada à própria rede.
O custo é software que você não auditou, rodando com os privilégios de uma network extension. A qualidade varia mais do que as fichas da loja sugerem: um aplicativo se reconecta limpo enquanto outro vaza por alguns segundos após uma troca de rede, e um kill switch dentro do aplicativo é um recurso desse aplicativo, não do iOS. Em um aparelho gerenciado, confira primeiro a lista aprovada.
O que o perfil IKEv2 nativo acerta
Menos peças móveis é o argumento inteiro. O cliente IKEv2 e sua pilha IPsec vêm com o sistema, então não há extensão que caia, nem processo por aplicativo para manter vivo, nem ciclo de atualizações de terceiros entre você e um túnel funcionando. Um perfil também pode ser bloqueado: em um aparelho supervisionado o usuário não consegue remover o que a gestão instalou, e o Always On VPN, que se reconecta em qualquer rede sem chave do usuário, só existe nessa forma supervisionada e gerenciada por perfil.
O que o caminho nativo não oferece é flexibilidade. Não existe VPN por aplicativo sem aplicativos gerenciados, nem kill switch para o usuário, nem transporte que pareça HTTPS em uma rede que bloqueia IPsec. Em redes de hotel que descartam UDP 500 e 4500, o IKEv2 nativo não tem alternativa.
Uma tabela de decisão que resolve a maioria dos casos
Na prática, a questão do protocolo decide a maioria dos casos antes de os recursos importarem.
| What you were given | Device situation | What to use |
|---|---|---|
| An .ovpn or WireGuard config | Personal phone | Provider app; the native form cannot load it |
| IKEv2 host plus CA name | Personal or managed | Profile, or the app's own IKEv2 mode |
| IKEv2 with username and secret | Personal phone | Either; the profile is simpler if you never switch servers |
| A management-installed profile | Supervised, MDM | Native client; do not add a second app entry |
| A per-app tunnelling requirement | Personal phone | App, or accept a full tunnel; iOS cannot split by app without management |
| IPsec blocked on your main network | Any | App with a transport that survives the block |
Duas linhas merecem uma segunda olhada. Um requisito por aplicativo em um telefone pessoal é o caso que as pessoas interpretam mal: o ajuste existe no iOS mas é comandado pela gestão, então um aparelho não gerenciado não vai oferecê-lo. Uma rede bloqueada não é motivo para desconfiar do IKEv2; é o motivo pelo qual o aplicativo do provedor existe.
Verifique a escolha com um teste
Teste os modos de falha, não o botão de conectar. Conecte uma vez, confirme que o indicador de VPN aparece, depois abra uma página que devolva o seu endereço público e compare com o anterior. Passe do Wi-Fi para os dados móveis sem tocar na VPN e observe uma reconexão, depois leve o telefone pelo modo avião. Reinicie e veja se o túnel volta sozinho: um perfil com OnDemandEnabled deveria, enquanto muitos aplicativos precisam ser abertos primeiro.
Quando ele não volta, separe a falha conforme exista ou não um túnel. Nenhum indicador de VPN significa que o túnel nunca subiu: ou o handshake falhou em RemoteIdentifier, na CA fixada ou em uma credencial, ou a conexão nunca foi tentada porque a regra sob demanda não correspondia e nenhum aplicativo a iniciou. Um indicador com tráfego falhando significa roteamento, DNS ou política no servidor, e reinstalar o cliente não toca em nada disso.
Uma lista curta para deixar o aparelho explicável para a próxima pessoa:
- uma entrada de VPN, não duas;
- o perfil ou aplicativo batizado com o nome do servidor a que se conecta;
- os valores de identidade anotados onde você possa encontrá-los.
Comece pela linha do protocolo na tabela, e pare aí se ela responder à pergunta.