Perché il tuo tunnel IPsec funziona fino al primo rinnovo di chiave CHILD SA

Il tunnel è salito, il ping ha risposto e tutti hanno firmato. Quattro ore dopo la sessione cade, i peer registrano un errore di proposta o di scambio chiavi, e il primo sospetto è che qualcosa sia cambiato sulla rete. Nulla è cambiato. Un tunnel che trasporta traffico ha dimostrato che i due peer concordano su come autenticarsi e su come proteggere la prima associazione figlia, e non ha dimostrato nulla sullo scambio di chiavi che esigeranno al rinnovo. Il disallineamento sta nel vuoto tra questi due eventi.

Connesso non significa che le impostazioni PFS coincidano

Con IKEv2, la prima associazione figlia viene creata durante lo scambio di autenticazione, e le sue chiavi derivano da materiale che l’associazione IKE ha già prodotto. Per quella figlia non avviene uno scambio Diffie-Hellman separato, quindi una politica che lo richiede al rinnovo non viene messa alla prova al sollevamento.

Il rinnovo è un altro scambio. Quando la chiave di un’associazione figlia viene rinnovata, i peer possono eseguire un nuovo scambio di chiavi con il gruppo indicato nelle loro proposte, e quello è il primo momento in cui le impostazioni del gruppo vengono confrontate. Perciò due peer in disaccordo possono autenticarsi, installare un’associazione figlia e far passare traffico, e poi fallire al rinnovo.

Dove si nasconde il disallineamento nella stringa della proposta

In strongSwan il gruppo viene aggiunto alla proposta figlia, ed è per questo che una stringa come aes256gcm16-prfsha256-ecp256 sembra una scelta di cifratura ma porta anche un requisito di scambio chiavi. Un peer che offre solo aes256gcm16-prfsha256 non ha tale requisito, e i due elenchi si intersecano sulla cifratura mentre divergono sullo scambio.

Leggi la proposta figlia e la proposta IKE come elenchi separati. Un gruppo che compare nell’elenco IKE non dice nulla sull’elenco figlio, e modificare uno mentre si legge l’altro è il modo abituale in cui questo sfugge.

Leggi il guasto, non il file che hai modificato

Trova il notify che ha terminato lo scambio. Un rinnovo di chiave figlia che restituisce «nessuna proposta accettabile» punta agli elenchi delle proposte; una richiesta di rinnovo che non riceve mai risposta punta al percorso o a un peer che ha smesso di ascoltare. Questi due richiedono correzioni diverse, e la formulazione della riga di log li separa.

Conferma la configurazione in esecuzione, non quella su disco. Un file salvato ma non caricato, o una connessione riletta da un altro include, produrranno un disallineamento che nessuna modifica del file visibile può correggere.

Tre eventi che tutti chiamano rinnovo di chiave

Il rinnovo della chiave dell’associazione IKE, la riautenticazione IKE e il rinnovo della chiave dell’associazione figlia sono operazioni separate con regole di proposta separate. Un guasto segnalato su una di esse non dice nulla di diretto sulle altre, e un log che le mescola si legge come un’unica anomalia ricorrente quando sono tre.

Nota quale evento nomina il peer, poi controlla le proposte solo per quell’evento. Cambia un elenco, ricarica e forza di nuovo lo stesso evento. Se il log nomina una riautenticazione, la proposta IKE è quella da leggere. Se nomina un rinnovo di chiave figlia, la proposta figlia porta il gruppo che conta.

Disattivare il rinnovo non è una correzione

Impostare a zero il tempo di rinnovo sopprime lo scambio che fallisce, e il tunnel sopravvive finché non viene smontato o il peer si riavvia. Quello che hai comprato è una chiave più longeva e un disallineamento che ti ritroverai durante una migrazione, un audit o un aggiornamento del fornitore. Lo stesso vale per durate allungate ben oltre la politica che l’altra parte si aspetta.

Allinea invece le proposte. Scegli un gruppo che entrambi i peer implementano, mettilo nella proposta figlia su entrambe le estremità, e tieni la politica di rinnovo dentro l’intervallo che l’organizzazione richiede davvero.

Provalo con lo scambio che è fallito

Accorcia il tempo di rinnovo della chiave figlia in una finestra di manutenzione così che l’evento arrivi in minuti invece che in ore, oppure avvia un rinnovo manuale. Poi osserva un rinnovo riuscito e conferma che il traffico continua a passare, perché un nuovo handshake che installa un’associazione figlia ma fa cadere il flusso dell’applicazione è un difetto diverso.

Dopo ripristina la durata normale e conserva entrambe le registrazioni degli eventi, quella fallita e quella riuscita. La prova che vuoi è che la connessione sopravviva al proprio ciclo di vita, non che abbia superato un ping.