O inicio de sesión de OpenConnect cae na páxina equivocada? Comproba primeiro a ruta

Pegas o enderezo do correo de incorporación, o cliente chega á pasarela e o formulario de inicio de sesión que aparece é o portal xeral e non o do socio que describiu o operador. Nada dá erro, e iso é xusto o que confunde: o túnel pode mesmo levantarse, só que detrás dun punto de entrada equivocado. A ruta desa URL facía traballo, e o que a substituíu perdeu ese traballo.

Separa dúas cousas que chegan como unha soa cadea nun ticket: o enderezo que chega ao servizo e a entrada que decide onde comeza a autenticación. Reparar a primeira ignorando a segunda é como un nome de host correcto aínda produce o inicio de sesión equivocado.

Que envía o cliente antes de que vexas un formulario

Cun enderezo como https://vpn.example.net/partners, o primeiro acto do cliente é unha petición HTTPS a esa ruta e non ao host espido. O que volve adoita ser unha redirección ao punto de inicio de sesión, ou o formulario mesmo. Un cliente ao que só se lle dá vpn.example.net comeza na páxina de aterraxe predeterminada que haxa, que pode ser outro portal, outra lista de grupos ou unha páxina que espera un protocolo completamente distinto. A diferenza vese nas cabeceiras de resposta moito antes de que se escriba ningunha credencial.

Por iso unha lapela do navegador que funciona e un perfil de cliente que falla poden nomear a mesma pasarela e aínda así non coincidir. O navegador seguiu a ruta; o perfil nunca a tivo.

Dúas entradas que parecen intercambiables e non o son

OpenConnect expón a ruta HTTPS inicial como --usergroup, e a páxina do manual trata unha URL completa que leve esa ruta como a mesma petición escrita doutra forma. --authgroup é unha opción aparte: escolle unha entrada da lista que a pasarela presenta dentro do formulario de inicio de sesión. Algúns protocolos chaman a esa entrada grupo, outros dominio ou pasarela, e é exactamente aí onde se confunden os dous parámetros.

Un servizo pode necesitar lexitimamente ambos. A ruta pode levarte ao portal correcto mentres o formulario aínda che pide escoller entre grupos dentro del. Dar o nome do portal como nome do grupo, ou ao revés, produce un inicio de sesión que parece aceptado e logo non autoriza, porque o valor era sintacticamente válido e semanticamente incorrecto.

Pide ao operador cada valor na súa propia liña: ruta de entrada, selección do formulario e se fan falta ambos. Non deduzas un do outro porque as etiquetas soan parecidas.

Por que recortar a ruta cambia o resultado

Os clientes que só aceptan host e porto a miúdo conéctanse igualmente, así que o síntoma raramente é un fallo duro. No seu lugar obtén a páxina de inicio de sesión equivocada, unha lista de grupos baleira, un nome de certificado que xa non coincide co que publicou o operador, ou un túnel que se levanta sen ruta cara ao servizo que querías. Cada un deles está nunha capa distinta, e ningún se repara pegando unha cadea máis longa nun campo documentado como nome de host. Dous deles tamén son indistinguibles desde fóra, xa que ambos chegan como un formulario de inicio de sesión que simplemente non continúa.

Substituír o nome de host por un enderezo IP é un erro aparte que a miúdo viaxa con este. A selección de servizo baseada no nome e a validación do certificado dependen ambas do nome, así que un enderezo numérico pode converter un problema de formato de ruta nun erro TLS.

Os enderezos do navegador tamén levan máis que rutas. Os identificadores de sesión, os destinos de redirección, os prefixos de idioma e os parámetros temporais de inicio de sesión aparecen todos na barra de enderezos, e ningún deles pertence a un perfil de cliente gardado.

Confirma o punto de entrada antes de editar calquera outra cousa

Le as cabeceiras da ruta que che deron. Unha petición como curl -sS -o /dev/null -D - https://vpn.example.net/partners imprime a liña de estado e calquera cabeceira Location sen seguir a redirección. Un 302 que apunta a un punto de inicio de sesión con nome confirma que a ruta existe e mostra a onde vai; un 404 significa que o enderezo do operador está obsoleto.

Despois reproduce o mesmo punto de entrada no cliente aprobado, por exemplo openconnect --usergroup=partners vpn.example.net, e observa que formulario aparece. Se o formulario é correcto e o túnel segue fallando, a ruta nunca foi o problema e a seguinte parada é a política ou o encamiñamento.

Anota o nome de host, o porto, o protocolo, a ruta de entrada e a selección do formulario como cinco campos separados no ticket. Esa lista é o que permite ao seguinte enxeñeiro distinguir un servidor inalcanzable dun rexeitamento TLS, dunha selección rexeitada e dun túnel que se levantou sen as rutas que necesitaba.