Perché un tunnel IPsec trafficato rinnova le chiavi presto: limiti di tempo e di volume

All’incirca ogni cinquanta minuti, un tunnel su un collegamento trafficato cade per qualche secondo, e il primo sospetto è l’orologio. Le associazioni possono terminare su un limite di tempo o su un conteggio di byte, e qualunque confine arrivi prima è quello che le manda in pensione. Su un collegamento che trasporta traffico reale, un limite di volume può scattare molto prima che l’ora configurata sia finita. Quindi «troppo presto» è un’affermazione sull’orologio, non sull’associazione.

Contate ciò che conta l’associazione, non l’interfaccia

Il totale di byte di un’interfaccia, la portata combinata di una dashboard e il contatore proprio dell’associazione sono tre numeri separati, e solo uno di essi viene confrontato con il limite. Registrate le associazioni in ingresso e in uscita separatamente con i loro identificatori, così un cambio di chiavi che tocca una direzione appare come un evento direzionale invece che come un mistero. Anche il contatore dell’associazione riparte al cambio di chiavi, per questo un totale preso dall’interfaccia cresce mentre il valore che conta viene azzerato.

Vale la pena fare il calcolo una volta perché l’ordine di grandezza smetta di sembrare arbitrario. Un budget conteggiato di un gibibyte esaurito a un ritmo costante di 128 mebibyte al minuto si consuma in otto minuti, e questa è una conversione di unità, non una misura del vostro tunnel. Se la cifra risultante si colloca molto sotto il limite di tempo, il volume è il meccanismo e nessuna osservazione dell’orologio spiegherà l’intervallo. Se si colloca molto sopra, il limite di byte non è il vostro innesco e la ricerca appartiene altrove.

Le soglie morbida e rigida sono due eventi diversi

Una soglia morbida chiede una sostituzione molto prima che il limite rigido termini l’associazione, e le implementazioni aggiungono i propri margini e la propria casualità sopra ciò che avete configurato. Per questo l’intervallo osservato quasi mai è un numero tondo. L’architettura IPsec descrive durate espresse in tempo e conteggi di byte con i due tipi di soglia, e prevale la scadenza più precoce. Se trattate una durata stampata come un calendario, sbaglierete della misura del margine.

Leggete la politica effettiva dallo stato in esecuzione invece di dedurla da un numero in un file, perché il margine appartiene all’implementazione, non alla vostra intenzione. Resistete alla tentazione di allungare i limiti verso il loro massimo per zittire il sintomo: un tunnel che rinnova le chiavi secondo il calendario si comporta come progettato, e una durata più lunga rinvia solo l’evento mantenendo una chiave compromessa utilizzabile più a lungo. Quando la sostituzione stessa fallisce, il limite è il messaggero e non la colpa.

Leggete la durata effettiva dallo stato in esecuzione

Su strongSwan, swanctl --list-sas stampa il riepilogo dell’associazione con i tempi di cambio chiavi e di vita, così il valore che il demone intende imporre è visibile senza indovinare. Su un host Linux senza vista del demone, ip xfrm state riporta i limiti morbidi e rigidi di byte e pacchetti configurati accanto ai contatori attuali. Quelle due letture rispondono a domande diverse ed entrambe meritano di restare nel ticket.

swanctl --list-sas
ip -s xfrm state

Confrontate la soglia morbida stampata con l’intervallo misurato, perché una sostituzione che inizia con un margine sotto il limite rigido è normale e una che non inizia mai non lo è. Se il demone mostra una durata e lo stato del kernel ne mostra un’altra, state guardando due strati che non concordano, e questo è già di per sé il risultato.

Osservate lo scambio che sostituisce la SA

Tenete i tre rinnovi separati, perché falliscono in modi diversi: un cambio di chiavi di IKE SA costruisce una nuova associazione di controllo, un cambio di chiavi di CHILD SA sostituisce l’associazione dati, e la riautenticazione ripete lo scambio di identità. In IKEv2 ogni peer decide le proprie durate invece di negoziare un unico valore condiviso, quindi uno scambio che non avete avviato è normale. Una discrepanza di perfect forward secrecy è una causa frequente della morte di una nuova child SA proprio all’intervallo di cambio chiavi, e si presenta esattamente come un guasto del timer finché qualcuno non legge la proposta.

Confrontate la vecchia associazione con la sua successore e con lo scambio che l’ha prodotta. Un identificatore che scompare è una sostituzione di routine; una proposta rifiutata, una risposta mancante o l’assenza di uno stato successore utilizzabile è un evento diverso con un altro proprietario. Preservate quella prova prima di cambiare qualsiasi cosa, perché le note specifiche della versione, la proposta del peer e le durate negoziate sono ciò che rende leggibile il caso una settimana dopo, quando i log sono già ruotati.

Dimostrate il rinnovo invece di nasconderlo

Accettate la distribuzione passando per un rinnovo che avete pianificato e non per uno che vi capita. Forzate un singolo cambio di chiavi dentro una finestra di manutenzione, poi confermate che entrambe le direzioni trasportano dati e che il risultato dell’applicazione è invariato, non solo che l’indicatore del tunnel è verde. Annotate quale limite è scattato e quale scambio è stato coinvolto.

Una conclusione di quella forma regge l’esame, mentre un valore del timer modificato che ha fatto sembrare tranquilla la connessione per un pomeriggio no. Se si è mosso solo il timer, le prove si sono mosse con esso.