L’inici de sessió d’OpenConnect cau a la pàgina equivocada? Comprova primer el camí

Enganxes l’adreça del correu d’incorporació, el client arriba a la passarel·la i el formulari d’inici de sessió que apareix és el portal general i no el del soci que va descriure l’operador. No hi ha cap error, i això és justament el que confon: el túnel pot fins i tot aixecar-se, només que darrere d’un punt d’entrada equivocat. El camí d’aquella URL feia feina, i el que el va substituir va deixar de fer-la.

Separa dues coses que arriben com una sola cadena en un tiquet: l’adreça que arriba al servei i l’entrada que decideix on comença l’autenticació. Reparar la primera ignorant la segona és com un nom d’amfitrió correcte encara produeix un inici de sessió equivocat.

Què envia el client abans que vegis un formulari

Amb una adreça com https://vpn.example.net/partners, el primer acte del client és una petició HTTPS a aquell camí i no a l’amfitrió nu. El que torna sol ser una redirecció al punt d’inici de sessió, o el formulari mateix. Un client que només rep vpn.example.net comença a la pàgina d’aterratge per defecte que hi hagi, que pot ser un altre portal, una altra llista de grups o una pàgina que espera un protocol completament diferent. La diferència és visible a les capçaleres de resposta molt abans que s’escrigui cap credencial.

Per això una pestanya del navegador que funciona i un perfil de client que falla poden anomenar la mateixa passarel·la i tot i així no coincidir. El navegador va seguir el camí; el perfil no el tenia mai.

Dues entrades que semblen intercanviables i no ho són

OpenConnect exposa el camí HTTPS inicial com a --usergroup, i la pàgina del manual tracta un URL complet que porti aquell camí com la mateixa petició escrita d’una altra manera. --authgroup és una opció separada: tria una entrada de la llista que la passarel·la presenta dins del formulari d’inici de sessió. Alguns protocols anomenen aquesta entrada grup, d’altres domini o passarel·la, i és exactament aquí on els dos paràmetres es confonen.

Un servei pot necessitar legítimament tots dos. El camí et pot portar al portal correcte mentre el formulari encara et demana de triar entre grups dins seu. Donar el nom del portal com a nom del grup, o a l’inrevés, produeix un inici de sessió que sembla acceptat i després no autoritza, perquè el valor era sintàcticament vàlid i semànticament incorrecte.

Demana a l’operador cada valor en una línia pròpia: camí d’entrada, selecció del formulari i si calen tots dos. No dedueixis l’un de l’altre perquè les etiquetes sonen semblants.

Per què retallar el camí canvia el resultat

Els clients que només accepten amfitrió i port sovint es connecten igualment, així que el símptoma poques vegades és una fallada dura. En lloc d’això obtens la pàgina d’inici de sessió equivocada, una llista de grups buida, un nom de certificat que ja no coincideix amb el que va publicar l’operador, o un túnel que s’aixeca sense ruta cap al servei que volies. Cadascun d’aquests se situa en una capa diferent, i cap no es repara enganxant una cadena més llarga en un camp documentat com a nom d’amfitrió. Dos d’ells també són indistingibles des de fora, perquè tots dos arriben com un formulari d’inici de sessió que simplement no continua.

Substituir el nom d’amfitrió per una adreça IP és un error separat que sovint viatja amb aquest. La selecció de servei basada en el nom i la validació del certificat depenen totes dues del nom, així que una adreça numèrica pot convertir un problema de format de camí en un error TLS.

Les adreces del navegador també porten més que camins. Els identificadors de sessió, les destinacions de redirecció, els prefixos d’idioma i els paràmetres temporals d’inici de sessió apareixen tots a la barra d’adreces, i cap d’ells no pertany a un perfil de client desat.

Confirma el punt d’entrada abans d’editar res més

Llegeix les capçaleres del camí que t’han donat. Una petició com curl -sS -o /dev/null -D - https://vpn.example.net/partners imprimeix la línia d’estat i qualsevol capçalera Location sense seguir la redirecció. Un 302 que apunta a un punt d’inici de sessió amb nom confirma que el camí existeix i mostra on va; un 404 vol dir que l’adreça de l’operador és obsoleta.

Després reprodueix el mateix punt d’entrada al client aprovat, per exemple openconnect --usergroup=partners vpn.example.net, i mira quin formulari apareix. Si el formulari és correcte i el túnel encara falla, el camí mai no va ser el problema i la següent parada és la política o l’encaminament.

Anota el nom d’amfitrió, el port, el protocol, el camí d’entrada i la selecció del formulari com a cinc camps separats al tiquet. Aquesta llista és el que permet al proper enginyer distingir un servidor inabastable d’un rebuig TLS, d’una selecció refusada i d’un túnel que es va aixecar sense les rutes que necessitava.