OpenVPN o IKEv2: cuatro comprobaciones antes de elegir un protocolo

La elección entre OpenVPN e IKEv2 suele plantearse como una cuestión de protocolo, y ese enfoque desperdicia la decisión. Lo que la decide es si su servidor y sus dispositivos admiten el mismo perfil completo, y si ese perfil sobrevive a la forma en que se mueve entre redes. Las dos pilas no se traducen la una en la otra: un archivo OVPN no es un perfil IKEv2 con otra sintaxis. Cuatro comprobaciones, hechas en orden, responden la pregunta más rápido que cualquier tabla de funciones.

Un cliente que falta termina la discusión

Windows y macOS incluyen un cliente IKEv2, así que un perfil IKEv2 no cuesta nada extra desplegarlo allí y hereda las opciones de aprovisionamiento que el sistema operativo ya expone. OpenVPN en las mismas máquinas significa un cliente de terceros que instalar, actualizar y mantener, y ese cliente tiene que aceptar cada opción que use el perfil. Cuente las plataformas que debe cubrir antes de comparar cualquier otra cosa, porque una plataforma sin cliente funcional no es ningún punto de comparación.

En Windows, un comando enumera los perfiles que ya existen y muestra de qué tipo es cada uno. El nombre que imprime es el nombre que usan las comprobaciones posteriores.

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

La indicación de instalar un cliente es la respuesta real para la columna de OpenVPN en esas plataformas, y es una tarea de despliegue y no una limitación del protocolo. Ninguna de las dos disposiciones elimina las comprobaciones de confianza, la verificación de identidad ni el mantenimiento. Pregunte cómo se distribuyen los perfiles, cómo se renuevan las credenciales y cómo se retira un dispositivo perdido antes de comprometerse. Una instalación sencilla todavía puede esconder un proceso de recuperación que nadie quiere ejecutar el fin de semana.

La movilidad es un ajuste conjunto, no una promesa del protocolo

IKEv2 puede usar MOBIKE cuando ambos extremos lo admiten y lo activan, lo que permite a un cliente mantener su túnel mientras cambia su dirección. RFC 4555 define la extensión, y la formulación condicional importa: un servidor que ignora la capacidad vuelve a negociar en su lugar. El resultado puede parecer idéntico en una transferencia de archivos y muy distinto en una llamada en vivo.

Pruebe la transición que de verdad le importa, con algo en marcha que pueda observar. Mantenga ping -t <internal-host> funcionando en Windows, o el simple ping en otros sistemas, luego cambie de Wi-Fi a móvil y observe si hay huecos. Un fallo de MOBIKE aparece en el registro del cliente como una reautenticación completa en lugar de una actualización silenciosa de la dirección. Lo que mide es si el túnel sobrevive al cambio, no si el protocolo anuncia compatibilidad.

Los clientes de OpenVPN se reconectan según el comportamiento de su plataforma y los temporizadores del perfil, así que la misma prueba puede producir una interrupción de forma distinta. Compare el evento que importa a sus usuarios, no la etiqueta del protocolo.

Las credenciales pertenecen al servicio, no a la pila

Los certificados y otras formas de inicio de sesión pertenecen al servicio que termina la conexión. Una petición de contraseña en un cliente no dice nada sobre la compatibilidad con otro, y un perfil que funciona contra otra puerta de enlace no dice nada sobre esta. Mantenga intactas las reglas de identidad del servidor mientras compara las dos pilas. Cambiar de protocolo antes de haber identificado el fallo suele producir un segundo perfil incompatible.

Inspeccione la credencial que presentará el cliente antes de culpar a cualquiera de los dos protocolos, porque un certificado caducado o mal emitido falla igual en ambos. La salida siguiente muestra el sujeto, el emisor y las fechas de validez sin leer la clave privada.

openssl x509 -in client.crt -noout -subject -issuer -dates

Para una conexión de empresa, use el método que publica la empresa y deje de tratar la comparación como un experimento. Si compara las dos por su cuenta, primero compruebe si ambas opciones terminan en una sola puerta de enlace, porque ese único detalle decide cuánto de su resultado trata del protocolo. Un rechazo que nombra la credencial es un problema de credenciales, y ningún cambio de protocolo lo reparará.

Compruebe qué enruta realmente el túnel

Tras conectar, confirme que la ruta que necesita existe y que los nombres se resuelven. Un perfil que existe para recursos internos puede dejar la navegación normal por la ruta local por diseño, y eso es una decisión de política y no una avería. Lo importante es si los destinos que usa su equipo son alcanzables a través del túnel.

Dos comandos cubren la ruta y la consulta de nombres en Windows. Los equivalentes en Linux son ip route show default y resolvectl query <internal-host>.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

Un túnel que sube y no enruta nada útil es un resultado habitual cuando un perfil se copió entre servicios, y una prueba de conectividad genérica no lo mostrará porque la interfaz está activa. Pruebe el recurso que sus usuarios abren primero, no una dirección pública que cualquier ruta puede alcanzar. Si el nombre se resuelve a una dirección pública mientras la ruta apunta dentro del túnel, la respuesta DNS y la ruta pertenecen a decisiones distintas y ambas deben corregirse.

Sopese el mantenimiento después de las comprobaciones

Ninguno de los dos protocolos es más mantenible en abstracto. El mantenimiento depende de quién opera la puerta de enlace, de cómo llegan los perfiles a los dispositivos y de la rapidez con que un dispositivo perdido pierde el acceso. Un cliente de extremo sencillo puede estar delante de un servidor más difícil de operar, y lo contrario también ocurre. Pregunte cuál de los dos puede su equipo mantener funcionando después de que se vaya la persona que lo construyó.

Elija la conexión compatible que cubra el trabajo y luego pruébela contra el acceso que realmente necesita en lugar de contra una lista de funciones. Anote en qué puerta de enlace termina cada opción, porque dos puertas distintas hacen que la comparación sea tanto de rutas como de protocolos. Repita las cuatro comprobaciones en el dispositivo que de verdad llevará, y quédese con el perfil que pase en él.