Por qué falla el inicio de sesión de openfortivpn al pegar la URL del portal

El fallo parece un problema de credenciales: openfortivpn pide la contraseña, la envía y la puerta de enlace responde con un rechazo o con una redirección de vuelta a la página de inicio de sesión. Entonces los usuarios vuelven a escribir la contraseña, prueban el nombre de cuenta cualificado por dominio y acaban pegando la URL del portal del navegador en el campo de host. Ese último movimiento es el que convierte un pequeño error de configuración en uno confuso.

Una dirección de portal de Fortinet como https://vpn.example.com/ext lleva varias piezas de información a la vez, y solo algunas pertenecen al cliente VPN.

El punto final y el realm son entradas separadas

openfortivpn espera un punto final en forma de host o host:port, además de una cuenta y, cuando el despliegue usa una, un valor de realm. El realm dice a la puerta de enlace qué política de autenticación aplicar antes de evaluar la cuenta. Es un campo separado, no un sufijo que el cliente extraiga de una URL.

Para un despliegue cuyo operador confirma que el realm es ext, una invocación no secreta tiene este aspecto: openfortivpn vpn.example.com:443 --username=alice --realm=ext. Los mismos valores van en el archivo de configuración como entradas host, port, username y realm. Deja la contraseña fuera de ambas formas y deja que el cliente la pida, para que no acabe en el historial del shell ni en un archivo legible por todos. Un segundo intento mientras el primer cliente aún mantiene el túnel fallará por un motivo que no tiene nada que ver con el realm.

El manual de openfortivpn enumera ambas opciones, así que la ortografía exacta es fácil de confirmar antes de llamar al soporte. No puede decirte, sin embargo, qué realm tiene configurado tu puerta de enlace.

Un segmento de ruta no es automáticamente un realm

Las URL de portal reúnen todo tipo de cosas después del nombre de host: una aplicación de inicio de sesión, un selector de idioma, un destino de redirección, un identificador de sesión. Cortar el último segmento de ruta y llamarlo realm funciona con la suficiente frecuencia como para ser peligroso. Pregunta al operador por el valor configurado o léelo del perfil que distribuye tu organización.

Un realm tampoco es lo mismo que un sufijo de dominio en el nombre de usuario o que la región en la que se encuentra la puerta de enlace. Algunos despliegues quieren alice, otros quieren alice@corp, y el realm decide cuál de ellos aceptará la puerta de enlace. Cambiar el formato de la cuenta para compensar un realm incorrecto suele producir un segundo rechazo, menos informativo.

No arregles un error de realm cambiando el host

Cambiar el nombre de host por una dirección IP parece quitar una capa, y rompe más de lo que arregla. La validación del nombre TLS compara el certificado con el nombre que usó el cliente, y una dirección IP rara vez aparece en los nombres alternativos del sujeto de un certificado. La indicación del nombre del servidor cambia con la dirección, así que una puerta de enlace que aloja varios portales en una dirección puede responder con el equivocado. Mantén intactos el nombre de host y la configuración de confianza mientras corriges el parámetro de autenticación.

Si el certificado no es de confianza en tu entorno, arregla el almacén de confianza o fija deliberadamente el certificado esperado. Desactivar la verificación para sortear un error de realm cambia un problema de inicio de sesión por un riesgo de interceptación silenciosa.

Separa un inicio de sesión rechazado de un túnel fallido

Los fallos de autenticación y los fallos de túnel llegan en momentos distintos, y los mensajes son diferentes. Un error de resolución de nombres ocurre antes de cualquier handshake TLS. Un rechazo TLS ocurre antes de que se envíen las credenciales. Un rechazo de realm o de cuenta vuelve como una respuesta a nivel HTTP del portal. Solo después de esas etapas empieza la negociación PPP, y solo entonces aparecen problemas de enrutamiento y DNS.

Un realm correcto no crea una ruta que falta ni hace que funcione un método de inicio de sesión no compatible. Si el portal insiste en un flujo basado en navegador, usa la ruta compatible del cliente para ese flujo en lugar de repetir un intercambio de contraseña y esperar que la sesión coincida.

Guarda los valores donde los encontrará el próximo arranque

Cuando una conexión funcione, escribe la puerta de enlace, el puerto, la cuenta y el realm en el perfil gestionado en lugar de en un alias del shell. Los perfiles guardados en un repositorio o en un sistema de gestión de configuración evitan que el próximo arranque recoja en silencio el realm de otro perfil.

Vuelve a probar una conexión de principio a fin y confirma tanto la política aplicada como el acceso a un recurso que realmente necesites. Que la autenticación funcione es el principio de esa comprobación, no el final.