Por qué tu túnel IPsec funciona hasta la primera renovación de clave de CHILD SA

El túnel se levantó, el ping respondió y todos dieron el visto bueno. Cuatro horas después la sesión cae, los pares registran un error de propuesta o de intercambio de claves, y la primera suposición es que algo cambió en la red. Nada cambió. Un túnel que transporta tráfico ha demostrado que los dos pares coinciden en cómo autenticarse y cómo proteger la primera asociación hija, y no ha demostrado nada sobre el intercambio de claves que exigirán en la renovación. El desajuste está en el hueco entre esos dos eventos.

Conectado no significa que la configuración de PFS coincida

Con IKEv2, la primera asociación hija se crea durante el intercambio de autenticación, y sus claves se derivan del material que la asociación IKE ya produjo. Para esa hija no ocurre un intercambio Diffie-Hellman aparte, así que una política que lo exija en la renovación no se pone a prueba en el levantamiento.

La renovación es otro intercambio. Cuando se renueva la clave de una asociación hija, los pares pueden realizar un intercambio de claves nuevo con el grupo que nombran sus propuestas, y ese es el primer momento en que se comparan los ajustes del grupo. Por eso dos pares que no coinciden pueden autenticarse, instalar una asociación hija y pasar tráfico, y después fallar en la renovación.

Dónde se esconde el desajuste en la cadena de la propuesta

En strongSwan el grupo se añade a la propuesta hija, y por eso una cadena como aes256gcm16-prfsha256-ecp256 parece una elección de cifrado pero también arrastra un requisito de intercambio de claves. Un par que solo ofrece aes256gcm16-prfsha256 no tiene ese requisito, y las dos listas coinciden en el cifrado pero discrepan en el intercambio.

Lee la propuesta hija y la propuesta IKE como listas separadas. Un grupo que aparece en la lista IKE no dice nada sobre la lista hija, y editar una mientras se lee la otra es la forma habitual de que esto se escape.

Lee el fallo, no el archivo que editaste

Encuentra el notify que terminó el intercambio. Una renovación de clave hija que devuelve «ninguna propuesta aceptable» apunta a las listas de propuestas; una solicitud de renovación que nunca recibe respuesta apunta al camino o a un par que dejó de escuchar. Esos dos necesitan correcciones distintas, y la redacción de la línea de registro los separa.

Confirma la configuración en ejecución y no la del disco. Un archivo guardado pero no cargado, o una conexión releída desde otro include, producirán un desajuste que ninguna cantidad de edición del archivo visible puede arreglar.

Tres eventos a los que todos llaman renovación de clave

La renovación de clave de la asociación IKE, la reautenticación IKE y la renovación de clave de la asociación hija son operaciones separadas con reglas de propuesta separadas. Un fallo informado en una de ellas no dice nada directamente sobre las otras, y un registro que las mezcla se lee como una única avería recurrente cuando son tres.

Fíjate en qué evento nombra el par y luego revisa las propuestas solo para ese evento. Cambia una lista, recarga y fuerza el mismo evento otra vez. Si el registro nombra una reautenticación, la propuesta IKE es la que hay que leer. Si nombra una renovación de clave hija, la propuesta hija lleva el grupo que importa.

Desactivar la renovación no es una solución

Poner el tiempo de renovación de clave a cero suprime el intercambio que falla, y el túnel sobrevive hasta que se desmonta o el par se reinicia. Lo que has comprado es una clave más duradera y un desajuste que te volverá a encontrar durante una migración, una auditoría o una actualización del proveedor. Lo mismo vale para vidas útiles estiradas mucho más allá de la política que espera el otro lado.

Alinea las propuestas. Elige un grupo que implementen ambos pares, ponlo en la propuesta hija en los dos extremos y mantén la política de renovación dentro del rango que la organización realmente requiere.

Demuéstralo con el intercambio que falló

Acorta el tiempo de renovación de clave hija en una ventana de mantenimiento para que el evento llegue en minutos en lugar de horas, o dispara una renovación manual. Después vigila una renovación correcta y confirma que el tráfico sigue pasando por ella, porque un nuevo handshake que instala una asociación hija pero deja caer el flujo de la aplicación es otro defecto.

Después restaura la vida útil normal y conserva los dos registros de eventos, el fallido y el correcto. La prueba que quieres es que la conexión sobreviva a su propio ciclo de vida, no que haya sobrevivido a un ping.