Aplicación VPN ou IKEv2 integrado no iPhone: como escoller
Unha aplicación VPN para iPhone e o cliente IKEv2 integrado resolven problemas diferentes. Compare primeiro o soporte de protocolos, a autenticación, o control do dispositivo e a recuperación.
A semana pasada un compañeiro pasoume o seu iPhone con dúas entradas VPN nos Axustes: unha deixáraa unha aplicación de provedor, a outra viña dun perfil IKEv2 pegado dunha páxina de soporte. Non son versións competidoras do mesmo. Unha aplicación de provedor é un contedor que pode levar o seu propio código de túnel, mentres que o cliente integrado de Apple é un cliente IKEv2, configurado a man ou mediante un perfil. O protocolo, o tratamento de credenciais, o control do dispositivo e a recuperación deciden a escolla.
A aplicación e o cliente nativo están en capas distintas
O cliente VPN integrado de Apple é, na práctica, un cliente IKEv2. O formulario manual aínda lista L2TP sobre IPsec e as opcións Cisco IPsec, xa obsoletas, pero non hai ningún campo de transporte do provedor nin lugar onde pegar unha configuración OpenVPN ou WireGuard. Ou enche un formulario en Axustes > Xeral > VPN & Xestión do dispositivo, ou importa un perfil cunha carga VPN; a superficie é un enderezo de servidor, dúas identidades, un método de autenticación e regras opcionais baixo demanda.
Unha aplicación de provedor traballa un nivel por riba. Inclúe un provedor de túnel de paquetes de Network Extension, así que o código do protocolo e a lóxica de encamiñamento viven na aplicación e o iOS só deixa pasar paquetes. Algunhas aplicacións implementan WireGuard ou OpenVPN, outras un transporte ofuscado propio, e unhas poucas só instalan un perfil IKEv2 e controlan o cliente nativo tras unha pantalla máis agradable. Este último grupo é a razón de que aplicación fronte a perfil sexa ás veces unha falsa escolla.
A consecuencia é práctica: un ficheiro .ovpn ou WireGuard non substitúe eses campos, porque o aperto de mans é outro protocolo.
Lea a carga antes de comparar funcións
Cando o perfil é IKEv2, as claves da carga explican máis fallos que calquera comparación de funcións. A referencia de configuración de IKEv2 de Apple documenta cada clave; unha carga recortada ten este aspecto:
<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>Tres campos levan a maior parte do peso diagnóstico. RemoteIdentifier é o nome que o cliente espera do servidor, así que unha pasarela detrás de NAT ou un balanceador cuxo certificado nomea o conxunto en lugar do enderezo falla aínda que o enderezo sexa correcto. LocalIdentifier é a identidade que o servidor cre que é vostede, e coa autenticación por certificado debe coincidir coa identidade asociada á súa conta. ServerCertificateIssuerCommonName fixa a autoridade de certificación emisora, así que un perfil pode fallar o día que se reemite o certificado, sen que ningunha mensaxe de erro mencione certificados.
Se AuthenticationMethod vale SharedSecret, o servidor fai autenticación de usuario EAP e o segredo que lle deron é en realidade unha credencial de conta. Isto importa cando un provedor envía dous documentos, un para o nome de usuario e o contrasinal e outro para un certificado, e só un coincide co que importou.
Que pode facer a aplicación que o cliente nativo non pode
A escolla de protocolo é a vantaxe evidente. Se o seu servidor fala WireGuard ou OpenVPN, unha aplicación é o único cliente iOS que o pode usar, e editar o formulario nativo non o negociará. Unha aplicación tamén pode implementar túnel dividido por destino ou por aplicación, a súa propia xestión de DNS, un bloqueo ao estilo de kill switch, selección de servidor e reconexión axustada á súa propia rede.
O prezo é software que non auditou, executándose cos privilexios dunha extensión de rede. A calidade varía máis do que suxiren as fichas da tenda: unha aplicación reconéctase limpiamente mentres outra verte durante uns segundos tras un cambio de rede, e un kill switch dentro da aplicación é unha función desa aplicación, non do iOS. Nun dispositivo xestionado, consulte primeiro a lista aprobada.
Que fai ben o perfil IKEv2 integrado
Menos pezas móbiles é todo o argumento. O cliente IKEv2 e a súa pila IPsec veñen co sistema, así que non hai extensión que poida caer, nin proceso por aplicación que manter vivo, nin ciclo de actualizacións de terceiros entre vostede e un túnel que funciona. Un perfil tamén se pode bloquear: nun dispositivo supervisado o usuario non pode quitar o que instalou a xestión, e Always On VPN, que se reconecta en calquera rede sen interruptor de usuario, só existe nesa forma supervisada e xestionada por perfil.
O que o camiño integrado non dá é flexibilidade. Non hai VPN por aplicación sen aplicacións xestionadas, nin kill switch para o usuario, nin un transporte que pareza HTTPS nunha rede que bloquea IPsec. En redes de hotel que descartan UDP 500 e 4500, o IKEv2 integrado non ten alternativa.
Unha táboa de decisión que resolve a maioría dos casos
Na práctica, a pregunta do protocolo decide a maioría dos casos antes de que as funcións importen.
| 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 |
Dúas filas merecen unha segunda ollada. O requisito por aplicación nun teléfono persoal é o caso que a xente le mal: a configuración existe no iOS pero xestiónaa a xestión, así que un dispositivo non xestionado non a ofrecerá. Unha rede bloqueada non é motivo para desconfiar do IKEv2; é a razón pola que existe a aplicación do provedor.
Verifique a escolla cunha proba
Probe os modos de fallo, non o botón de conexión. Conéctese unha vez, confirme que aparece o indicador de VPN, despois abra unha páxina que devolva o seu enderezo público e compárea co anterior. Pase do Wi-Fi aos datos móbiles sen tocar a VPN e observe se se reconecta, despois pase o teléfono polo modo avión. Reinicie e vexa se o túnel volve só: un perfil con OnDemandEnabled debería facelo, mentres que moitas aplicacións hai que abrirlas primeiro.
Cando non volve, separe o fallo segundo se existe algún túnel. Sen indicador de VPN, o túnel nunca se levantou: ou o aperto de mans fallou en RemoteIdentifier, na autoridade de certificación fixada ou nunha credencial, ou a conexión nunca se tentou porque a regra baixo demanda non coincidía e ningunha aplicación a iniciou. Un indicador con tráfico que falla significa encamiñamento, DNS ou política do servidor, e reinstalar o cliente non toca nada diso.
Unha lista curta para deixar o dispositivo explicable á persoa seguinte:
- unha entrada VPN, non dúas;
- o perfil ou a aplicación co nome do servidor ao que se conecta;
- os valores de identidade escritos onde os poida atopar.
Comece pola fila do protocolo na táboa, e párase aí se responde á pregunta.