L’accesso a OpenConnect finisce sulla pagina sbagliata? Controlla prima il percorso

Incolli l’indirizzo dall’e-mail di onboarding, il client raggiunge il gateway e il modulo di accesso che appare è il portale generale e non quello partner descritto dall’operatore. Nulla segnala un errore, ed è proprio questo a confondere: il tunnel può persino salire, ma dietro un punto di ingresso sbagliato. Il percorso in quell’URL faceva un lavoro, e ciò che l’ha sostituito ha perso quel lavoro.

Separa due cose che arrivano come un’unica stringa in un ticket: l’indirizzo che raggiunge il servizio e l’input che decide dove inizia l’autenticazione. Riparare il primo ignorando il secondo è il modo in cui un nome host corretto produce comunque un accesso sbagliato.

Cosa invia il client prima che tu veda un modulo

Con un indirizzo come https://vpn.example.net/partners, il primo atto del client è una richiesta HTTPS a quel percorso e non all’host nudo. Ciò che torna è di solito un reindirizzamento al punto di accesso, o il modulo stesso. Un client a cui viene dato solo vpn.example.net parte dalla pagina di atterraggio predefinita che c’è, che può essere un altro portale, un’altra lista di gruppi o una pagina che si aspetta un protocollo del tutto diverso. La differenza è visibile nelle intestazioni di risposta molto prima che venga digitata qualsiasi credenziale.

Per questo una scheda del browser che funziona e un profilo client che fallisce possono nominare lo stesso gateway e comunque non essere d’accordo. Il browser ha seguito il percorso; il profilo non l’ha mai avuto.

Due input che sembrano intercambiabili e non lo sono

OpenConnect espone il percorso HTTPS iniziale come --usergroup, e la pagina del manuale tratta un URL completo che porti quel percorso come la stessa richiesta scritta in altro modo. --authgroup è un’opzione separata: sceglie una voce dall’elenco che il gateway presenta dentro il modulo di accesso. Alcuni protocolli chiamano quella voce gruppo, altri dominio o gateway, ed è esattamente lì che i due parametri si confondono.

Un servizio può legittimamente aver bisogno di entrambi. Il percorso può portarti sul portale giusto mentre il modulo ti chiede ancora di scegliere tra gruppi al suo interno. Dare il nome del portale come nome del gruppo, o il contrario, produce un accesso che sembra accettato e poi non autorizza, perché il valore era sintatticamente valido e semanticamente sbagliato.

Chiedi all’operatore ogni valore su una riga propria: percorso di ingresso, selezione del modulo e se servono entrambi. Non dedurre l’uno dall’altro perché le etichette suonano simili.

Perché tagliare il percorso cambia l’esito

I client che accettano solo host e porta spesso si connettono comunque, quindi il sintomo raramente è un guasto netto. Al suo posto ottieni la pagina di accesso sbagliata, un elenco di gruppi vuoto, un nome di certificato che non corrisponde più a quello pubblicato dall’operatore, o un tunnel che sale senza una rotta verso il servizio che volevi. Ognuno di questi sta su un livello diverso, e nessuno si ripara incollando una stringa più lunga in un campo documentato come nome host. Due di essi sono anche indistinguibili dall’esterno, poiché entrambi arrivano come un modulo di accesso che semplicemente non prosegue.

Sostituire il nome host con un indirizzo IP è un errore separato che spesso viaggia con questo. La selezione del servizio basata sul nome e la validazione del certificato dipendono entrambe dal nome, quindi un indirizzo numerico può trasformare un problema di formato del percorso in un errore TLS.

Gli indirizzi del browser portano anche più dei percorsi. Gli identificatori di sessione, le destinazioni di reindirizzamento, i prefissi di lingua e i parametri temporanei di accesso compaiono tutti nella barra degli indirizzi, e nessuno di essi appartiene a un profilo client salvato.

Conferma il punto di ingresso prima di modificare qualsiasi altra cosa

Leggi le intestazioni del percorso che ti è stato dato. Una richiesta come curl -sS -o /dev/null -D - https://vpn.example.net/partners stampa la riga di stato e qualsiasi intestazione Location senza seguire il reindirizzamento. Un 302 che punta a un punto di accesso con nome conferma che il percorso esiste e mostra dove porta; un 404 significa che l’indirizzo dell’operatore è obsoleto.

Poi riproduci lo stesso punto di ingresso nel client approvato, per esempio openconnect --usergroup=partners vpn.example.net, e osserva quale modulo appare. Se il modulo è corretto e il tunnel fallisce ancora, il percorso non è mai stato il problema e la fermata successiva è la politica o l’instradamento.

Annota nome host, porta, protocollo, percorso di ingresso e selezione del modulo come cinque campi separati nel ticket. Quell’elenco è ciò che permette all’ingegnere successivo di distinguere un server irraggiungibile da un rifiuto TLS, da una selezione rifiutata e da un tunnel salito senza le rotte necessarie.