IKEv1 con XAuth e OTP: cosa chiede ciascun prompt
Una PSK di gruppo, uno scambio XAuth utente e una sfida OTP sono tre input diversi. Abbina ogni prompt al suo proprietario prima di installare un altro client.
IKEv1 con PSK, XAuth e OTP non chiede un’unica password complicata. Sovrappone una chiave condivisa tra i peer, uno scambio utente e un secondo fattore di cui il backend decide come richiederlo. Ogni livello ha il proprio proprietario e il proprio messaggio di errore. Confonderli porta le persone a reinserire un codice monouso in un campo che memorizza un segreto di gruppo.
Abbina ogni prompt al livello che lo richiede prima di installare un altro client o reimpostare una credenziale.
Tre segreti, tre proprietari
La chiave pre-condivisa appartiene alla relazione tra peer ed è configurata una volta da chi gestisce entrambe le estremità. La credenziale utente appartiene al backend di autenticazione ed è convalidata a ogni accesso. Il secondo fattore appartiene a un sistema di token la cui risposta cambia a ogni tentativo. Nessuno sostituisce l’altro, e un’installazione che li tratta come un’unica password fallisce sul livello che nessuno ha documentato.
Annota tre colonne: proprietario, durata e il messaggio di errore che ciascuno produce. Quella tabella è lo strumento diagnostico, non i nomi dei campi del client.
| Layer | Owner | Lifetime |
|---|---|---|
| Pre-shared key | Peer configuration | Until operators change it |
| XAuth credential | Authentication backend | Per session, per policy |
| One-time code | Token system | Single use |
PSK: del peer, non della persona
In questa disposizione legacy la chiave pre-condivisa autentica la coppia di gateway, quindi l’accesso dell’utente non la sostituisce mai. È anche il valore più spesso sbagliato in un modo che produce un errore di negoziazione generico invece di un prompt. Quando il tunnel fallisce prima che compaia un prompt utente, i sospetti sono la chiave o le proposte.
Una credenziale utente non può riparare un fallimento della prima fase. Ruotarla spreca l’unica credenziale che puoi ruotare in sicurezza e rafforza la teoria sbagliata.
XAuth: lo scambio utente legacy
XAuth aggiunge uno scambio di autenticazione utente sopra l’autenticazione peer di IKEv1, e il gateway decide quale backend lo convalida. A seconda di quel backend, lo scambio può accettare una password di directory, una credenziale RADIUS o una risposta token. La parola XAuth nomina il trasporto dello scambio, non il tipo di credenziale.
Controlla a quale backend punta il profilo del gateway. Questo dice cosa verrà chiesto all’utente e cosa cambia davvero un reset della password, e nessuna delle due cose è visibile in un profilo client.
OTP: qualunque cosa chieda il backend
Alcune installazioni chiedono un codice monouso separato dopo la password, altre definiscono un formato di input combinato con un separatore documentato. Entrambi esistono, e il profilo davanti a te decide quale. Inventare una concatenazione perché ha funzionato in un altro sito è il modo più comune per bruciare un token di registrazione. Solo la documentazione del gateway lo stabilisce.
Usa il formato documentato con un client in grado di completare lo scambio che il gateway offre.
Dove morde il confine del client
Fortinet documenta che FortiClient 7.4.4 e versioni successive non supportano più IKEv1 per le VPN IPsec, il che è un confine di prodotto e versione e non una rimozione universale, come registra la nota di compatibilità di FortiClient. Neanche gli altri client sono intercambiabili: OpenConnect e openfortivpn parlano protocolli gateway specifici, non profili IKEv1 arbitrari. Controlla singolarmente versione IKE, modalità PSK, supporto XAuth e modello di interazione del client installato. Un client che si connette con un metodo diverso non ha dimostrato il requisito originale.
IKEv1 è deprecato, quindi un nuovo roll-out costruito su un vecchio client non supportato è una soluzione di breve durata. Chiedi al proprietario del gateway un percorso di migrazione supportato, incluso come verrà gestito lì il secondo fattore.
Diagnosticare senza disattivare il fattore
Separa le fasi nel log: negoziazione dei peer, scambio utente, esito del secondo fattore, poi assegnazione di indirizzi e rotte. Registra il componente e la fase invece di provare il codice in ogni campo. Disattivare il fattore perché un test passi produce un tunnel che non dimostra nulla sull’installazione.
Conserva i segreti di registrazione e la chiave condivisa in uno storage protetto secondo il processo dell’organizzazione. Un codice monouso in un file permanente è un fattore che ha smesso di esserlo.