IKEv2 non è un solo scambio: IKE SA, autenticazione, poi CHILD SA

Potresti pensare che una connessione IKEv2 sia un solo scambio che termina con il tuo traffico cifrato. Sono almeno due, e il primo non autentica nessuno. I peer iniziano con messaggi di controllo, concordano i parametri crittografici, dimostrano l'identità e solo dopo negoziano lo stato che trasporta i pacchetti applicativi. Quest'ordine spiega la discrepanza che le persone segnalano continuamente: il gateway risponde, il client dice connesso, e l'applicazione privata va comunque in timeout. Ecco cosa fa davvero ogni fase, e cosa deve essere vero dopo.

Il mito: se il gateway risponde, sei connesso

Una risposta al primo messaggio dimostra che l'endpoint è raggiungibile e disposto a parlare. Non dimostra che un account sia stato accettato, che una catena di certificati sia stata validata o che qualche criterio sui dati sia stato installato.

Quei guasti arrivano più tardi e producono sintomi diversi. Il rifiuto di un certificato o un errore EAP arriva dopo che il primo scambio è già riuscito, ed è per questo che un ping verso UDP 500 e un'icona verde nel client dicono così poco.

IKE_SA_INIT: concordare parametri, non identità

Il primo scambio trasporta le proposte per l'associazione di sicurezza IKE: algoritmi di cifratura e integrità, una funzione pseudocasuale e un gruppo Diffie-Hellman. I peer scambiano anche nonce, e ciascun lato deriva il materiale di chiave per l'IKE SA dal segreto condiviso che quei valori producono. Nulla in questo scambio stabilisce chi sia l'altra parte. Stabilisce che entrambi i lati possono calcolare le stesse chiavi e che concordano su una proposta. Un risponditore a cui non piace nessuna proposta rifiuta qui lo scambio, ed è per questo che un disallineamento di versione o di algoritmo sembra un server spento.

L'IKE SA creato a questo punto protegge tutti gli scambi di gestione successivi. È il suo compito, ed è un compito diverso dal proteggere i tuoi pacchetti.

IKE_AUTH: dimostrare l'identità, poi costruire il primo CHILD SA

Il secondo scambio trasporta l'identità. Con i certificati, ogni peer firma con la propria chiave privata e presenta una catena che l'altro deve validare; con EAP, il risponditore sfida l'iniziatore tramite il metodo scelto. È qui che un nome di server sbagliato, un certificato scaduto o una password rifiutata emergono finalmente.

Normalmente IKE_AUTH negozia anche il primo CHILD SA, quindi la protezione dei dati viene concordata nello stesso andata e ritorno. L'iniziatore propone i selettori di traffico, il risponditore li restringe o li rifiuta, e le chiavi del percorso dati derivano dall'IKE SA. Questo significa che un solo scambio può fallire in due punti molto diversi: l'identità o il criterio. Leggi il payload di notifica o l'errore invece del guasto generico di negoziazione, perché la correzione per uno è un certificato e per l'altro è un disallineamento di sottorete.

Due SA, due compiti

Tenerli separati spiega due comportamenti che sembrano bug. Un tunnel può apparire stabilito mentre un rinnovo di chiavi fallisce in background, e un CHILD SA può essere sostituito senza che il client perda la connessione.

Su strongSwan, il riferimento di configurazione IKEv2 e swanctl --list-sas mostrano entrambi i livelli, e ip xfrm state più ip xfrm policy mostrano cosa ha realmente installato il kernel. Confrontare queste due viste è il modo più rapido per vedere se la negoziazione è finita o lo è solo sembrata. Se il demone elenca un CHILD SA per cui il kernel non ha stato, l'installazione è fallita in silenzio. Se il kernel mantiene uno stato che il demone non conosce, stai guardando un residuo di un tentativo precedente.

Cosa deve restare vero dopo che il tunnel è su

I selettori di traffico definiscono quali indirizzi sono coperti. Se il client propone una sottorete e il server ne aspetta un'altra, il CHILD SA si installa ma non trasporta nulla di utile, e l'errore appare come un problema di routing anziché di negoziazione. Poi lo stack locale deve collaborare: inoltro abilitato dove l'host instrada, rotte che puntano al tunnel, regole del firewall che consentono i pacchetti decapsulati e un resolver interno se sono coinvolti nomi privati. Ognuno di questi fallisce separatamente e nessuno si risolve riavviando il demone IKE.

Tieni visibile il registro mentre diagnostichi: lo scambio iniziale, poi la validazione dell'identità, poi l'autenticazione utente dove si applica, poi l'installazione del CHILD e infine il traffico applicativo. La fase che si ferma è quella da correggere, e un guasto di routing successivo non è mai un motivo per allentare i controlli di identità già superati.