Perché l’accesso a openfortivpn fallisce quando incolli l’URL del portale

L’errore sembra un problema di credenziali: openfortivpn chiede la password, la invia e il gateway risponde con un rifiuto o con un reindirizzamento alla pagina di accesso. Gli utenti allora ridigitano la password, provano il nome account qualificato dal dominio e alla fine incollano l’URL del portale nel campo host. È proprio quest’ultima mossa che trasforma un piccolo errore di configurazione in un errore confuso.

Un indirizzo del portale Fortinet come https://vpn.example.com/ext trasporta più informazioni insieme, e solo alcune appartengono al client VPN.

L’endpoint e il realm sono input separati

openfortivpn si aspetta un endpoint nella forma host o host:port, più un account e, dove il deployment ne usa uno, un valore realm. Il realm dice al gateway quale politica di autenticazione applicare prima di valutare l’account. È un campo separato, non un suffisso che il client estrae da un URL.

Per un deployment il cui operatore conferma che il realm è ext, una chiamata non segreta ha questo aspetto: openfortivpn vpn.example.com:443 --username=alice --realm=ext. Gli stessi valori vanno nel file di configurazione come voci host, port, username e realm. Lascia la password fuori da entrambe le forme e lascia che il client la chieda, così non finisce nella cronologia della shell né in un file leggibile da tutti. Un secondo tentativo mentre il primo client tiene ancora il tunnel fallirà per un motivo che non ha nulla a che vedere con il realm.

Il manuale di openfortivpn elenca entrambe le opzioni, quindi l’ortografia esatta è facile da confermare prima di chiamare il supporto. Non può dirti, però, quale realm è configurato sul tuo gateway.

Un segmento di percorso non è automaticamente un realm

Gli URL del portale raccolgono ogni genere di cose dopo il nome host: un’applicazione di accesso, un selettore di lingua, una destinazione di reindirizzamento, un identificatore di sessione. Tagliare l’ultimo segmento di percorso e chiamarlo realm funziona abbastanza spesso da essere pericoloso. Chiedi all’operatore il valore configurato o leggilo dal profilo che distribuisce la tua organizzazione.

Un realm non è nemmeno la stessa cosa di un suffisso di dominio sul nome utente o della regione in cui si trova il gateway. Alcuni deployment vogliono alice, altri vogliono alice@corp, e il realm decide quale dei due il gateway accetterà. Cambiare il formato dell’account per compensare un realm sbagliato di solito produce un secondo rifiuto, meno informativo.

Non correggere un errore di realm cambiando l’host

Sostituire il nome host con un indirizzo IP sembra togliere uno strato, e rompe più di quanto ripari. La validazione del nome TLS confronta il certificato con il nome usato dal client, e un indirizzo IP compare raramente nei nomi alternativi del soggetto di un certificato. L’indicazione del nome del server cambia con l’indirizzo, quindi un gateway che ospita più portali su un indirizzo può rispondere con quello sbagliato. Mantieni intatti il nome host e la configurazione di fiducia mentre correggi il parametro di autenticazione.

Se il certificato non è attendibile nel tuo ambiente, correggi l’archivio di fiducia o fissa deliberatamente il certificato atteso. Disattivare la verifica per aggirare un errore di realm scambia un problema di accesso con un rischio di intercettazione silenziosa.

Distingui un accesso rifiutato da un tunnel non riuscito

Gli errori di autenticazione e gli errori del tunnel arrivano in momenti diversi, e i messaggi sono diversi. Un errore di risoluzione del nome avviene prima di qualsiasi handshake TLS. Un rifiuto TLS avviene prima che vengano inviate le credenziali. Un rifiuto di realm o di account torna come risposta a livello HTTP dal portale. Solo dopo queste fasi inizia la negoziazione PPP, e solo allora compaiono problemi di routing e DNS.

Un realm corretto non crea una route mancante e non fa funzionare un metodo di accesso non supportato. Se il portale insiste su un flusso basato sul browser, usa il percorso supportato dal client per quel flusso invece di ripetere uno scambio di password e sperare che la sessione coincida.

Conserva i valori dove il prossimo avvio li troverà

Una volta che una connessione riesce, scrivi gateway, porta, account e realm nel profilo gestito invece che in un alias della shell. I profili conservati in un repository o in un sistema di gestione della configurazione impediscono al prossimo avvio di prendere silenziosamente il realm di un altro profilo.

Prova di nuovo una connessione dall’inizio alla fine e conferma sia la politica applicata sia l’accesso a una risorsa che ti serve davvero. Il successo dell’autenticazione è l’inizio di quel controllo, non la fine.