Reclau, reconnexió o reautenticació: què necessites?

Una sessió que fa hores que funciona no mantindrà les mateixes claus per sempre, i això és per disseny. Tres esdeveniments diferents es descriuen com a rotació de claus: material de sessió nou sota una associació existent, una reconstrucció completa de la connexió i una repetició de la comprovació d’identitat. Cadascun té un desencadenant diferent, un cost diferent i una signatura de fallada diferent. Si tries el que no toca, la solució o no fa res o tira el túnel a terra sense motiu.

La decisió depèn de quina capa ha caducat realment.

Tres operacions que s’anomenen rotació

Un reclau crea claus de trànsit noves dins de la relació de control existent, fent servir el mecanisme que defineix el protocol. IKEv2 ho fa amb una associació de seguretat filla nova, TLS 1.3 amb un missatge d’actualització de clau i WireGuard amb un handshake nou quan s’assoleixen els seus límits de temps o de missatges. Les adreces del túnel i la identitat autenticada es queden on eren.

Una reconnexió descarta la connexió i la torna a construir des del principi, cosa que repeteix l’assignació d’adreces, la instal·lació d’encaminaments i qualsevol negociació que hagués fet el primer intent.

La reautenticació repeteix la mateixa prova d’identitat, que pot implicar una credencial, un certificat o un segon factor. Pot passar amb reconnexió o sense, segons el producte.

Què nota l’usuari en la renovació

Un reclau hauria de ser gairebé invisible. Els identificadors d’associació canvien, els comptadors es poden reiniciar i les aplicacions conserven els seus sockets; una pausa breu en una direcció és normal durant l’intercanvi. Veure un identificador nou en un llistat d’estat no és prova d’una avaria. La línia de registre que segueix l’intercanvi és el que et diu si ha acabat.

Una caiguda real en la renovació assenyala un punt concret. Una discrepància de proposta, una credencial caducada o un canvi de camí produeixen cadascun una línia de registre diferent, i només un d’ells es corregeix ajustant les durades.

On divergeixen les tres a la pràctica

Si l’únic que ha caducat és el material de clau, reclau. Si l’adreça del parell, la ruta o l’enllaç NAT han canviat i els paquets ja no arriben, reconnecta. Si l’organització exigeix una comprovació periòdica d’identitat, això és reautenticació i cap ajust de durades no la substitueix.

Els valors per defecte del protocol solen codificar la resposta correcta. WireGuard reclava després d’un llindar de temps i de volum de dades sense cap acció de l’usuari; les durades d’IKEv2 es negocien per a cada associació filla; els túnels basats en TLS roten claus dins de la sessió existent. Apujar les durades per evitar un error recurrent ajorna la fallada i allarga l’exposició si una clau queda compromesa.

Un advertiment és important per a sessions llargues: la freqüència per si sola no crea secret de reenviament. La propietat depèn de com es relacionen les claus de sessió amb els secrets de llarg termini i de si les claus antigues es destrueixen, cosa que és una qüestió de disseny i implementació, no un paràmetre.

Tria els valors per defecte i després registra l’etapa

Mantén els valors per defecte del proveïdor tret que un requisit documentat digui el contrari, i canvia les durades als dos parells si les canvies. Després registra a quina etapa ha arribat cada esdeveniment, perquè la propera ocurrència es pugui comprovar contra el mateix punt del handshake.

swanctl --list-sas
ip xfrm state | grep -E 'proto|replay-window'
wg show
journalctl -u strongswan --since '1 hour ago' | grep -i -E 'rekey|rekeyed|child'

Després d’una correcció, fes una renovació controlada i envia trànsit d’aplicació nou per l’associació nova. Un túnel que es declara establert però no reenvia res és la fallada que aquesta comprovació existeix per atrapar.