IKEv2: rinnovo delle chiavi contro riautenticazione — perché la connessione cade più tardi

Il tunnel sale la mattina e funziona per ore. Poi cade, si riconnette dopo un tentativo e fa la stessa cosa il giorno dopo. Nulla è cambiato sulla rete e nessuno ha toccato una password. Le sessioni che falliscono a un confine di rinnovo attraversano di solito una di due operazioni diverse, e solo una di esse ricontrolla le tue credenziali. Leggere quale delle due è scattata è tutta la diagnosi.

Due operazioni che dall’esterno sembrano simili

Il rinnovo delle chiavi sostituisce le associazioni di sicurezza o il materiale delle chiavi nello scambio definito dal protocollo. L’autenticazione non viene ripetuta, quindi l’identità accettata all’inizio della sessione viene semplicemente trasportata avanti.

La riautenticazione va oltre: stabilisce una nuova relazione autenticata, il che significa che le credenziali vengono valutate di nuovo. Tutto ciò che è scaduto, è stato revocato o è cambiato nella directory diventa visibile in quel momento.

Cosa sostituisce davvero un rinnovo delle chiavi

IKEv2 mantiene due tipi di associazione con cicli di vita separati. L’IKE SA protegge il canale di controllo e le CHILD SA proteggono il traffico reale. Rinnovarne una non è sinonimo di riconnettere il client.

Questa separazione spiega uno schema familiare: il traffico scorre bene, poi una CHILD SA viene rinnovata e la proposta non corrisponde più perché qualcuno ha modificato la fase 2 su un lato settimane prima. Il cambiamento è rimasto lì innocuo finché il rinnovo non lo ha esercitato.

I disallineamenti di durata si comportano allo stesso modo. Il peer che raggiunge per primo il suo limite avvia lo scambio, e l’altro deve accettarlo.

Cosa rivaluta la riautenticazione

Con la riautenticazione, il certificato client valido al login può ora essere scaduto. Una credenziale revocata, una password ruotata o un secondo fattore non disponibile emergono tutti qui, non al momento del rinnovo.

Ecco perché allungare ogni durata sembra una correzione e non lo è. Hai rinviato il controllo invece di superarlo. Il prossimo rinnovo arriva con lo stesso difetto e una finestra di interruzione più breve per notarlo.

Alcune implementazioni sovrappongono stato vecchio e nuovo durante la riautenticazione. Altre producono un breve vuoto. Perciò impostazioni identiche su due fornitori possono dare esperienze utente diverse. Verifica il comportamento invece di supporre che lo standard lo imponga.

Leggi i timestamp prima di cambiare qualcosa

Cattura il momento del guasto insieme allo stato dell’associazione prima e dopo. Se la vecchia associazione è stata sostituita senza uno scambio di autenticazione, eri a un confine di rinnovo. Se uno scambio AUTH compare subito prima del guasto, eri a una riautenticazione.

strongSwan espone questo come impostazioni separate: rekey controlla il rinnovo delle chiavi, reauth controlla se avviene una nuova autenticazione, e i valori margin decidono con quanto anticipo rispetto alla scadenza ciascuna inizia. la documentazione sul rinnovo delle chiavi descrive l’interazione, e vale la pena leggerla prima di copiare una durata da un messaggio del forum.

Distingui tutto questo da una semplice perdita di rete. Un collegamento interrotto produce un evento di rilevamento peer morto o una tempesta di ritrasmissioni, non uno scambio pulito con proposte corrispondenti.

Cambia ciò che è fallito

Un rifiuto delle credenziali richiede che si risolva il problema di identità: rinnova il certificato, ripristina l’account, registra di nuovo il fattore. Un disallineamento di proposta o durata richiede il confronto dei parametri su entrambi i lati.

Allungare le durate per evitare il sintomo è l’unica opzione che sembra sempre aver funzionato e non funziona mai.

Prova un rinnovo controllato

Forza il rinnovo invece di aspettare un giorno. Poi ripeti con una riautenticazione se il deployment ne supporta una, e osserva entrambe le estremità.

Un login iniziale riuscito non esercita nulla di tutto questo. Il ciclo di vita successivo è dove questi deployment si rompono davvero.