IKEv2: renovación de claves fronte a reautenticación — por que a conexión cae máis tarde

O túnel lévase pola mañá e funciona durante horas. Despois cae, reconéctase tras un reintento e fai o mesmo ao día seguinte. Nada cambiou na rede e ninguén tocou un contrasinal. As sesións que fallan nun límite de renovación normalmente cruzan unha de dúas operacións distintas, e só unha delas volve comprobar as túas credenciais. Ler cal das dúas se disparou é todo o diagnóstico.

Dúas operacións que se parecen desde fóra

A renovación de claves substitúe asociacións de seguridade ou material de claves dentro do intercambio definido polo protocolo. A autenticación non se repite, así que a identidade aceptada ao inicio da sesión simplemente se traslada.

A reautenticación vai máis alá: establece unha relación autenticada nova, o que significa que as credenciais se avalían de novo. Todo o que caducou, foi revogado ou cambiou no directorio faise visible nese momento.

Que substitúe realmente unha renovación de claves

IKEv2 mantén dous tipos de asociación con ciclos de vida separados. A IKE SA protexe a canle de control e as CHILD SA protexen o tráfico real. Renovar unha non é sinónimo de reconectar o cliente.

Esa separación explica un patrón coñecido: o tráfico flúe ben, despois renovase unha CHILD SA e a proposta xa non encaixa porque alguén editou a fase 2 nun lado semanas antes. O cambio quedou alí sen facer dano ata que a renovación o exerceu.

Os desaxustes de duración compórtanse igual. O par que acada primeiro o seu límite inicia o intercambio, e o outro ten que aceptalo.

Que reavalia a reautenticación

Coa reautenticación, o certificado de cliente que era válido ao iniciar sesión pode ter caducado agora. Unha credencial revogada, un contrasinal rotado ou un segundo factor non dispoñible aparecen todos aquí, non no momento da renovación.

Por iso alongar cada duración parece unha solución e non o é. Atrasaches a comprobación en lugar de pasala. A próxima renovación chega co mesmo defecto e unha xanela de interrupción máis curta para decatarse.

Algunhas implementacións solapan o estado vello e o novo durante a reautenticación. Outras producen un oco breve. Por iso, axustes idénticos en dous provedores poden dar experiencias de usuario distintas. Proba o comportamento en lugar de supor que o estándar o dita.

Le as marcas de tempo antes de cambiar nada

Captura o momento do fallo xunto co estado da asociación antes e despois. Se a asociación antiga se substituíu sen un intercambio de autenticación, estabas nun límite de renovación. Se un intercambio AUTH aparece xusto antes do fallo, estabas nunha reautenticación.

strongSwan expono como axustes separados: rekey controla a renovación de claves, reauth controla se ocorre unha autenticación nova, e os valores de marxe deciden con canta antelación ao vencemento comeza cada unha. a documentación sobre a renovación de claves describe a interacción, e paga a pena lela antes de copiar unha duración dunha mensaxe do foro.

Distingue todo isto dunha perda de rede simple. Unha ligazón cortada produce un evento de detección de par morto ou unha tormenta de retransmisións, non un intercambio limpo con propostas coincidentes.

Cambia o que fallou

Un rexeitamento de credenciais necesita que se arranxe o problema de identidade: renova o certificado, restaura a conta, volve inscribir o factor. Un desaxuste de proposta ou de duración necesita comparar os parámetros en ambos os lados.

Estirar as duracións para evitar o síntoma é a única opción que sempre parece que funcionou e nunca funciona.

Proba unha renovación controlada

Forza a renovación en lugar de esperar un día por ela. Despois repítao cunha reautenticación se o despregamento admite unha, e observa ambos os extremos.

Un inicio de sesión inicial correcto non exercita nada disto. O ciclo de vida posterior é onde estes despregamentos se rompen de verdade.