¿El inicio de sesión de OpenConnect cae en la página equivocada? Comprueba primero la ruta

Pegas la dirección del correo de incorporación, el cliente llega a la puerta de enlace y el formulario de inicio de sesión que aparece es el portal general y no el del socio que describió el operador. Nada da error, y eso es justo lo que confunde: el túnel puede incluso levantarse, solo que detrás de un punto de entrada equivocado. La ruta de esa URL hacía trabajo, y lo que la sustituyó perdió ese trabajo.

Separa dos cosas que llegan como una sola cadena en un ticket: la dirección que alcanza el servicio y la entrada que decide dónde empieza la autenticación. Reparar la primera ignorando la segunda es como un nombre de host correcto sigue produciendo el inicio de sesión equivocado.

Qué envía el cliente antes de que veas un formulario

Con una dirección como https://vpn.example.net/partners, el primer acto del cliente es una petición HTTPS a esa ruta y no al host desnudo. Lo que vuelve suele ser una redirección al punto de inicio de sesión, o el formulario mismo. Un cliente al que solo se le da vpn.example.net empieza en la página de aterrizaje predeterminada que haya, que puede ser otro portal, otra lista de grupos o una página que espera un protocolo completamente distinto. La diferencia se ve en las cabeceras de respuesta mucho antes de que se escriba ninguna credencial.

Por eso una pestaña de navegador que funciona y un perfil de cliente que falla pueden nombrar la misma puerta de enlace y aun así no coincidir. El navegador siguió la ruta; el perfil nunca la tuvo.

Dos entradas que parecen intercambiables y no lo son

OpenConnect expone la ruta HTTPS inicial como --usergroup, y la página del manual trata una URL completa que lleve esa ruta como la misma petición escrita de otra forma. --authgroup es una opción aparte: elige una entrada de la lista que la puerta de enlace presenta dentro del formulario de inicio de sesión. Algunos protocolos llaman a esa entrada grupo, otros dominio o puerta de enlace, y es exactamente ahí donde se confunden los dos parámetros.

Un servicio puede necesitar legítimamente ambos. La ruta puede llevarte al portal correcto mientras el formulario todavía te pide elegir entre grupos dentro de él. Dar el nombre del portal como nombre del grupo, o al revés, produce un inicio de sesión que parece aceptado y luego no autoriza, porque el valor era sintácticamente válido y semánticamente incorrecto.

Pide al operador cada valor en su propia línea: ruta de entrada, selección del formulario y si hacen falta ambos. No deduzcas uno del otro porque las etiquetas suenan parecidas.

Por qué recortar la ruta cambia el resultado

Los clientes que solo aceptan host y puerto a menudo se conectan igualmente, así que el síntoma rara vez es un fallo duro. En su lugar obtienes la página de inicio de sesión equivocada, una lista de grupos vacía, un nombre de certificado que ya no coincide con lo que publicó el operador, o un túnel que se levanta sin ruta hacia el servicio que querías. Cada uno de ellos está en una capa distinta, y ninguno se repara pegando una cadena más larga en un campo documentado como nombre de host. Dos de ellos también son indistinguibles desde fuera, ya que ambos llegan como un formulario de inicio de sesión que simplemente no continúa.

Sustituir el nombre de host por una dirección IP es un error aparte que a menudo viaja con este. La selección de servicio basada en el nombre y la validación del certificado dependen ambas del nombre, así que una dirección numérica puede convertir un problema de formato de ruta en un error TLS.

Las direcciones del navegador también llevan más que rutas. Los identificadores de sesión, los destinos de redirección, los prefijos de idioma y los parámetros temporales de inicio de sesión aparecen todos en la barra de direcciones, y ninguno de ellos pertenece a un perfil de cliente guardado.

Confirma el punto de entrada antes de editar cualquier otra cosa

Lee las cabeceras de la ruta que te han dado. Una petición como curl -sS -o /dev/null -D - https://vpn.example.net/partners imprime la línea de estado y cualquier cabecera Location sin seguir la redirección. Un 302 que apunta a un punto de inicio de sesión con nombre confirma que la ruta existe y muestra adónde va; un 404 significa que la dirección del operador está obsoleta.

Después reproduce el mismo punto de entrada en el cliente aprobado, por ejemplo openconnect --usergroup=partners vpn.example.net, y observa qué formulario aparece. Si el formulario es correcto y el túnel sigue fallando, la ruta nunca fue el problema y la siguiente parada es la política o el enrutamiento.

Anota el nombre de host, el puerto, el protocolo, la ruta de entrada y la selección del formulario como cinco campos separados en el ticket. Esa lista es lo que permite al siguiente ingeniero distinguir un servidor inalcanzable de un rechazo TLS, de una selección rechazada y de un túnel que se levantó sin las rutas que necesitaba.