Aplicación VPN o IKEv2 integrado en iPhone: cómo elegir
Una aplicación VPN para iPhone y el cliente IKEv2 integrado resuelven problemas distintos. Compare primero compatibilidad de protocolos, autenticación, control del dispositivo y recuperación.
La semana pasada un compañero me tendió su iPhone con dos entradas VPN en Ajustes: una dejada por una aplicación de proveedor y otra de un perfil IKEv2 copiado de una página de soporte. No son versiones rivales de lo mismo. Una aplicación de proveedor es un contenedor que puede llevar su propio código de túnel, mientras que el cliente integrado de Apple es un cliente IKEv2, configurado a mano o mediante un perfil. El protocolo, el manejo de credenciales, el control del dispositivo y la recuperación deciden la elección.
La aplicación y el cliente nativo están en capas distintas
El cliente VPN integrado de Apple es, en la práctica, un cliente IKEv2. El formulario manual todavía incluye la opción obsoleta de L2TP sobre IPsec y las opciones de Cisco IPsec, pero no hay ningún campo de transporte de proveedor ni dónde pegar una configuración de OpenVPN o WireGuard. O rellena un formulario en Ajustes > General > VPN & Gestión del dispositivo, o importa un perfil con una carga VPN; la superficie es una dirección de servidor, dos identidades, un método de autenticación y reglas opcionales bajo demanda.
Una aplicación de proveedor trabaja una capa por encima. Incluye un proveedor de túnel de paquetes de Network Extension, así que el código del protocolo y la lógica de enrutamiento viven en la aplicación y iOS solo deja pasar paquetes. Algunas aplicaciones implementan WireGuard o OpenVPN, otras un transporte ofuscado propio, y unas pocas solo instalan un perfil IKEv2 y manejan el cliente nativo tras una pantalla más agradable. Ese último grupo es la razón de que aplicación frente a perfil sea a veces una falsa elección.
La consecuencia es práctica: un archivo .ovpn o de WireGuard no sustituye esos campos, porque el handshake es otro protocolo.
Lea la carga antes de comparar funciones
Cuando el perfil es IKEv2, las claves de la carga explican más fallos que cualquier comparación de funciones. La referencia de ajustes de IKEv2 de Apple documenta cada clave; una carga recortada se ve así:
<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 concentran casi todo el peso del diagnóstico. RemoteIdentifier es el nombre que el cliente espera que presente el servidor, así que una pasarela detrás de NAT o un balanceador cuyo certificado nombra el grupo en lugar de la dirección falla aunque la dirección sea correcta. LocalIdentifier es quién cree el servidor que es usted, y con autenticación por certificado debe coincidir con la identidad asociada a su cuenta. ServerCertificateIssuerCommonName fija la CA emisora, así que un perfil puede fallar el día que se reemite el certificado, sin ningún mensaje de error que mencione certificados.
Si AuthenticationMethod es SharedSecret, el servidor hace autenticación de usuario EAP y el secreto que le dieron es en realidad una credencial de cuenta. Eso importa cuando un proveedor envía dos documentos, uno para usuario y contraseña y otro para un certificado, y solo uno coincide con lo que importó.
Lo que la aplicación puede hacer y el cliente nativo no
La elección de protocolo es la ventaja obvia. Si su servidor habla WireGuard u OpenVPN, una aplicación es el único cliente de iOS que puede usarlo, y editar el formulario nativo no lo negociará. Una aplicación también puede implementar túnel dividido por destino o por aplicación, su propio manejo de DNS, un bloqueo tipo kill switch, selección de servidor y reconexión ajustada a su propia red.
El coste es software que usted no auditó, ejecutándose con los privilegios de una extensión de red. La calidad varía más de lo que sugieren las fichas de la tienda: una aplicación se reconecta limpiamente mientras otra filtra durante unos segundos tras un cambio de red, y un kill switch dentro de la aplicación es una función de esa aplicación, no de iOS. En un dispositivo gestionado, consulte primero la lista aprobada.
Lo que el perfil IKEv2 nativo hace bien
Menos piezas móviles es todo el argumento. El cliente IKEv2 y su pila IPsec vienen con el sistema, así que no hay extensión que se caiga, ni proceso por aplicación que mantener vivo, ni ciclo de actualizaciones de terceros entre usted y un túnel que funciona. Un perfil también se puede bloquear: en un dispositivo supervisado el usuario no puede quitar lo que instaló la gestión, y Always On VPN, que se reconecta en cualquier red sin interruptor de usuario, solo existe en esa forma supervisada y gestionada por perfil.
Lo que la vía nativa no le da es flexibilidad. No hay VPN por aplicación sin aplicaciones gestionadas, ni kill switch para el usuario, ni un transporte que parezca HTTPS en una red que bloquea IPsec. En redes de hotel que descartan UDP 500 y 4500, el IKEv2 nativo no tiene alternativa.
Una tabla de decisión que resuelve la mayoría de los casos
En la práctica, la pregunta del protocolo decide la mayoría de los casos antes de que las funciones 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 |
Dos filas merecen un segundo vistazo. Un requisito por aplicación en un teléfono personal es el caso que la gente malinterpreta: el ajuste existe en iOS pero lo controla la gestión, así que un dispositivo no gestionado no lo ofrecerá. Una red bloqueada no es motivo para desconfiar de IKEv2; es la razón por la que existe la aplicación del proveedor.
Verifique la elección con una prueba
Pruebe los modos de fallo, no el botón de conexión. Conéctese una vez, confirme que aparece el indicador de VPN, luego abra una página que devuelva su dirección pública y compárela con la anterior. Pase de Wi-Fi a datos móviles sin tocar la VPN y observe si se reconecta, después lleve el teléfono por el modo avión. Reinicie y vea si el túnel vuelve solo: un perfil con OnDemandEnabled debería hacerlo, mientras que muchas aplicaciones necesitan que las abran primero.
Cuando no vuelve, separe el fallo según si existe algún túnel. Sin indicador de VPN, el túnel nunca se levantó: o el handshake falló en RemoteIdentifier, en la CA fijada o en una credencial, o la conexión nunca se intentó porque la regla bajo demanda no coincidía y ninguna aplicación la inició. Un indicador con tráfico fallido significa enrutamiento, DNS o política del servidor, y reinstalar el cliente no toca nada de eso.
Una lista corta para dejar el dispositivo explicable a la siguiente persona:
- una entrada VPN, no dos;
- el perfil o la aplicación con el nombre del servidor al que se conecta;
- los valores de identidad anotados donde pueda encontrarlos.
Empiece por la fila del protocolo en la tabla, y deténgase ahí si responde a la pregunta.