IKEv2: renovació de claus enfront de reautenticació — per què la connexió cau més tard

El túnel puja al matí i funciona durant hores. Després cau, es reconnecta després d’un reintent i fa el mateix l’endemà. No ha canviat res a la xarxa i ningú no ha tocat cap contrasenya. Les sessions que fallen en una frontera de renovació normalment creuen una de dues operacions diferents, i només una d’elles torna a comprovar les vostres credencials. Llegir quina de les dues ha actuat és tot el diagnòstic.

Dues operacions que des de fora semblen iguals

La renovació de claus substitueix associacions de seguretat o material de claus dins de l’intercanvi definit pel protocol. L’autenticació no es repeteix, així que la identitat acceptada a l’inici de la sessió simplement es trasllada.

La reautenticació va més enllà: estableix una relació autenticada nova, cosa que vol dir que les credencials es tornen a avaluar. Tot el que ha caducat, s’ha revocat o s’ha canviat al directori es fa visible en aquell moment.

Què substitueix realment una renovació de claus

IKEv2 manté dos tipus d’associació amb cicles de vida separats. L’IKE SA protegeix el canal de control, i les CHILD SA protegeixen el trànsit real. Renovar una no és sinònim de reconnectar el client.

Aquesta separació explica un patró familiar: el trànsit va bé, després es renova una CHILD SA i la proposta ja no encaixa perquè algú va editar la fase 2 en un costat setmanes abans. El canvi va quedar allà sense fer mal fins que la renovació el va exercir.

Els desajustos de durada es comporten igual. El peer que arriba primer al seu límit inicia l’intercanvi, i l’altre l’ha d’acceptar.

Què reavalua la reautenticació

Amb la reautenticació, el certificat de client que era vàlid a l’inici de sessió pot haver caducat ara. Una credencial revocada, una contrasenya rotada o un segon factor no disponible apareixen aquí, no en el moment de la renovació.

Per això allargar cada durada sembla una solució i no ho és. Heu ajornat la comprovació en lloc de passar-la. La propera renovació arriba amb el mateix defecte i una finestra d’interrupció més curta per adonar-se’n.

Algunes implementacions solapen l’estat vell i el nou durant la reautenticació. Altres produeixen un buit breu. Per tant, paràmetres idèntics en dos proveïdors poden donar experiències d’usuari diferents. Proveu el comportament en lloc de suposar que l’estàndard ho dicta.

Llegeix les marques de temps abans de canviar res

Captureu el moment de la fallada juntament amb l’estat de l’associació abans i després. Si l’associació antiga es va substituir sense un intercanvi d’autenticació, éreu en una frontera de renovació. Si un intercanvi AUTH apareix just abans de la fallada, éreu en una reautenticació.

strongSwan ho exposa com a paràmetres separats: rekey controla la renovació de claus, reauth controla si es fa una autenticació nova, i els valors margin decideixen amb quanta antelació respecte del venciment comença cadascun. la documentació sobre la renovació de claus descriu la interacció, i val la pena llegir-la abans de copiar una durada d’un missatge del fòrum.

Distingiu tot això d’una pèrdua de xarxa simple. Un enllaç trencat produeix un esdeveniment de detecció de peer mort o una tempesta de retransmissions, no un intercanvi net amb propostes coincidents.

Canvieu allò que ha fallat

Un rebuig de credencials necessita arreglar el problema d’identitat: renoveu el certificat, restaureu el compte, torneu a inscriure el factor. Un desajust de proposta o de durada necessita comparar els paràmetres a banda i banda.

Allargar les durades per evitar el símptoma és l’única opció que sempre sembla que ha funcionat i mai no funciona.

Proveu una renovació controlada

Forceu la renovació en lloc d’esperar un dia per ella. Després repetiu-ho amb una reautenticació si el desplegament en suporta una, i observeu tots dos extrems.

Un inici de sessió inicial correcte no exercita res d’això. El cicle de vida posterior és on aquests desplegaments es trenquen de debò.