Per què un túnel IPsec carregat canvia claus abans d’hora: límits de temps i de volum

Aproximadament cada cinquanta minuts, un túnel en un enllaç carregat cau durant uns segons, i el primer sospitós és el rellotge. Les associacions poden acabar per un límit de temps o per un recompte de bytes, i quina frontera arribi primer és la que les jubila. En un enllaç que porta trànsit real, un límit de volum es pot activar molt abans que s’acabi l’hora configurada. Així doncs, «massa aviat» és una afirmació sobre el rellotge, no sobre l’associació.

Compteu el que compta l’associació, no la interfície

El total de bytes d’una interfície, el cabal combinat d’un tauler i el comptador propi de l’associació són tres números separats, i només un d’ells es compara amb el límit. Registreu les associacions d’entrada i de sortida per separat amb els seus identificadors, perquè un canvi de clau que toca una direcció surti com un esdeveniment direccional en lloc d’un misteri. El comptador de l’associació també torna a començar en el canvi de clau, i per això un total pres de la interfície creix mentre el valor que importa es reinicia.

Val la pena fer l’aritmètica una vegada perquè l’ordre de magnitud deixi de semblar arbitrari. Un pressupost comptat d’un gibibyte esgotat a un ritme constant de 128 mebibytes per minut s’exhaureix en vuit minuts, i això és una conversió d’unitats, no un mesurament del vostre túnel. Si la xifra resultant queda molt per sota del límit de temps, el volum és el mecanisme i cap vigilància del rellotge explicarà l’interval. Si queda molt per sobre, el límit de bytes no és el vostre disparador i la recerca pertany a un altre lloc.

Els llindars suau i dur són dos esdeveniments diferents

Un llindar suau demana una substitució molt abans que el límit dur acabi l’associació, i les implementacions hi afegeixen els seus propis marges i aleatorització a sobre del que hàgiu configurat. Per això l’interval observat gairebé mai no és un nombre rodó. L’arquitectura IPsec descriu vides útils expressades en temps i recomptes de bytes amb els dos tipus de llindar, i mana la caducitat més primerenca. Tracteu una vida útil impresa com un calendari i us equivocareu per la mida del marge.

Llegiu la política efectiva de l’estat en execució en lloc d’inferir-la d’un número en un fitxer, perquè el marge pertany a la implementació, no a la vostra intenció. Resistiu la temptació d’estirar els límits cap al màxim per silenciar el símptoma: un túnel que canvia claus segons el calendari es comporta tal com està dissenyat, i una vida útil més llarga només ajorna l’esdeveniment tot mantenint una clau compromesa utilitzable més temps. Quan la substitució mateixa falla, el límit és el missatger i no la culpa.

Llegiu la vida útil efectiva de l’estat en execució

A strongSwan, swanctl --list-sas imprimeix el resum de l’associació amb els temps de canvi de clau i de vida, de manera que el valor que el dimoni vol aplicar es veu sense endevinar. En un amfitrió Linux sense vista del dimoni, ip xfrm state informa dels límits suaus i durs de bytes i paquets configurats al costat dels comptadors actuals. Aquestes dues lectures responen preguntes diferents i totes dues val la pena guardar-les al tiquet.

swanctl --list-sas
ip -s xfrm state

Compareu el llindar suau imprès amb l’interval que heu mesurat, perquè una substitució que comença amb un marge per sota del límit dur és normal i una que no comença mai no ho és. Si el dimoni mostra una vida útil i l’estat del nucli en mostra una altra, esteu mirant dues capes que no es posen d’acord, i això mateix és la troballa.

Vigileu l’intercanvi que substitueix la SA

Manteniu les tres renovacions separades, perquè fallen de maneres diferents: un canvi de clau d’IKE SA construeix una nova associació de control, un canvi de clau de CHILD SA substitueix l’associació de dades, i la reautenticació repeteix l’intercanvi d’identitat. A IKEv2 cada parell decideix les seves pròpies vides útils en lloc de negociar un valor compartit, així que un intercanvi que no heu iniciat és normal. Una discrepància de perfect forward secrecy és una causa freqüent que una child SA nova mori just a l’interval de canvi de clau, i es presenta exactament com una fallada de temporitzador fins que algú llegeix la proposta.

Compareu l’associació antiga amb la seva successora i amb l’intercanvi que la va produir. Un identificador que desapareix és una substitució rutinària; una proposta rebutjada, una resposta absent o l’absència d’un estat successor utilitzable és un esdeveniment diferent amb un propietari diferent. Preserveu aquesta evidència abans de canviar res, perquè les notes específiques de la versió, la proposta del parell i les vides útils negociades són el que fa llegible el cas una setmana després, quan els registres ja s’han rotat.

Demostreu la renovació en lloc d’amagar-la

Accepteu el desplegament passant per una renovació que heu planificat i no per una que us passa a sobre. Forceu un sol canvi de clau dins d’una finestra de manteniment, i després confirmeu que totes dues direccions porten dades i que el resultat de l’aplicació no ha canviat, no només que l’indicador del túnel és verd. Registreu quin límit s’ha activat i quin intercanvi hi ha intervingut.

Una conclusió d’aquesta forma sobreviu a l’escrutini, mentre que un valor de temporitzador canviat que va fer semblar tranquil·la la connexió durant una tarda no hi sobreviu. Si només s’ha mogut el temporitzador, l’evidència s’ha mogut amb ell.