Lo scambio IKEv2 funziona, poi l’autenticazione fallisce: dove cercare

Un client che riceve una risposta IKEv2 ha dimostrato che il gateway è raggiungibile, che entrambe le parti possono negoziare una proposta e che lo scambio di chiavi iniziale è terminato. Non ha dimostrato che qualcuno sia autenticato. Lo scambio successivo trasporta identità, certificati o EAP, ed è lì che la connessione di solito si ferma. Leggere quale di questi controlli è fallito è l’intera diagnosi, e il messaggio di errore da solo raramente lo dice.

Controllo 1: leggete la fase, non il messaggio

Un rifiuto può venire da tre punti: il client che rifiuta l’identità del server, il gateway che rifiuta la prova del client e un servizio di autenticazione esterno che rifiuta l’account.

Ognuno produce una riga di log diversa su una macchina diversa, e ognuno ha una correzione diversa. Un rifiuto del certificato del server lato client è un problema di fiducia o di denominazione sul client; un rifiuto del certificato del client lato gateway è un problema di fiducia sul gateway; un errore EAP è un problema di account o di backend. Il messaggio che vedete è di solito il riassunto del client di uno di questi, ed è per questo che il log del gateway conta quanto quello del client.

Controllo 2: quale identità è stata verificata

Un client può rifiutare il certificato del server o l’identità attesa prima che venga offerta qualsiasi credenziale utente, e un indirizzo del server funzionante non sostituisce quel controllo. L’identificatore atteso dal client deve corrispondere a ciò che presenta il gateway, il che è un fatto di configurazione e non di rete.

In termini strongSwan è rightid sul client e l’identità del gateway stesso dall’altro lato, e una discrepanza fallisce prima ancora che si parli di EAP.

Il gateway, separatamente, può rifiutare il certificato del client, la sua prova di chiave o l’autenticazione dell’account, e questi tre non sono intercambiabili. Reimpostare la password di un utente non rinnova un certificato del dispositivo, e reinstallare un certificato del dispositivo non corregge un’identità del server sbagliata. Per gli errori di certificato, controllate prima l’orologio, poi la catena di fiducia, poi l’identificatore atteso; un client il cui orologio è sfasato di qualche minuto fallisce un controllo di validità che sembra un errore di fiducia. swanctl --list-certs su entrambe le estremità mostra ciò che ciascuna parte possiede davvero.

Controllo 3: se EAP è in gioco

Il client e il server devono concordare un metodo supportato, e il backend deve accettare l’identità fornita.

Un nome utente può richiedere un suffisso di dominio o un formato di account specifico imposto dalla distribuzione, e il formato è documentato e non indovinabile. Fornire i campi documentati dall’operatore è più veloce che provare varianti, ed evita un secondo problema: tentativi ripetuti possono attivare un blocco dell’account, che poi nasconde la fase originale dietro un nuovo errore. Se il metodo è EAP-MSCHAPv2 contro una directory, l’errore può appartenere alla directory e non alla VPN.

Non testate i problemi di identità disattivando i controlli di identità. Questo trasforma un errore diagnosticabile in uno non diagnosticabile e lascia la connessione più debole di prima.

Controllo 4: cosa succede dopo un accesso riuscito

Una volta completato IKE_AUTH, la negoziazione CHILD_SA decide quali selettori di traffico vengono installati, ed è lì che una connessione può riuscire e comunque non far passare nulla.

Un accesso appena funzionante rivela spesso un problema di selettore o di rotta che prima era nascosto dietro l’errore di autenticazione. Se il tunnel sale e un’applicazione non raggiunge ancora la sua destinazione, guardate i selettori e le rotte negoziati invece dell’identità. Cambiare le impostazioni di identità a quel punto punta alla fase sbagliata e di solito rompe un accesso funzionante. Confermate con swanctl --list-sas, che mostra i figli e i loro selettori separatamente dall’IKE SA.

Controllo 5: cosa consegnare al supporto

Una cronologia ripulita e il rifiuto preciso valgono più di un’esportazione diagnostica completa, e l’esportazione può contenere chiavi private o credenziali che non dovreste condividere.

Annotate l’ora con il fuso orario, le versioni di client e gateway, il metodo, la stringa di identità offerta invece della password e la fase esatta che l’ha rifiutata. La documentazione di configurazione IKEv2 di strongSwan descrive le impostazioni di identità ed EAP che determinano questi esiti, ed è il riferimento da leggere prima di cambiare un campo. Poi cambiate una sola cosa e riprovate una connessione nuova, perché una sessione in cache vi parlerà della vecchia configurazione.