strongSwan se queda caído tras reiniciar el peer: recupera un túnel

La puerta de enlace remota se reinicia, vuelve en menos de un minuto y el demonio strongSwan local sigue ejecutándose con el túnel aún caído. Una tarea de cron que busca ESTABLISHED y reinicia el demonio acabará tapando eso, y también interrumpirá todos los túneles no relacionados de la máquina mientras quizá se pierde el que falló. La recuperación pertenece a la conexión que tiene que volver, expresada en ajustes que sobreviven a una recarga. Este runbook lo prepara para una sola conexión y demuestra el resultado por nombre.

Retira el reinicio global, conserva sus pruebas

Un reinicio del demonio tiene dos defectos concretos: destruye el estado de cada conexión y no te dice nada sobre qué evento falló en realidad. El texto de estado que buscaste pudo venir de otra conexión, mientras que el child necesario quedó inactivo porque nada lo activó.

Lee las conexiones cargadas y las asociaciones activas antes de cambiar nada, para tener una imagen previa con la que comparar cuando el peer vuelva.

swanctl --list-conns
swanctl --list-sas

Pon la iniciación y los reintentos en la conexión que vuelve

En un despliegue con swanctl.conf estos ajustes viven a nivel de conexión y de child, no en una política global. El fragmento de abajo es un ejemplo del lado del iniciador que da por hecho que las propuestas, la autenticación y los selectores ya son correctos.

connections {
    branch {
        keyingtries = 0
        dpd_delay = 30s
        children {
            private-lan {
                start_action = trap|start
                dpd_action = restart
            }
        }
    }
}

start_action decide qué ocurre al cargar el child: start inicia de inmediato, mientras que trap instala una política que dispara la iniciación cuando aparece tráfico coincidente. Escribir trap|start requiere strongSwan 5.9.6 o posterior, así que comprueba la versión antes de copiar la línea. dpd_action=restart pide una negociación nueva en cuanto el peer se declara muerto, y keyingtries=0 a nivel de conexión permite más intentos hasta el éxito o un error permanente. Con IKEv2, dpd_timeout no tiene ningún efecto, porque la retransmisión ordinaria decide cuándo el peer no responde.

El retardo de ese ejemplo es un punto de partida y no un plazo universal. Elígelo según cuánto tarda el reinicio del peer y cuánta retransmisión estás dispuesto a aguantar.

Sabe de qué evento te recuperas

Tres fallos parecen idénticos en un panel y necesitan ajustes distintos. Una conexión inicial que nunca subió es un problema de configuración o de accesibilidad. Un peer que dejó de responder es el caso DPD. Un child que el peer cerró explícitamente es un evento de política con su propio close_action, que el DPD nunca observa. Leer el registro alrededor del corte te dice cuál de los tres tienes, y la respuesta cambia la solución.

No añadas reinicio agresivo a una conexión que los operadores cierran a propósito para mantenimiento, o el túnel reaparecerá en mitad de la ventana. Para diseños bajo demanda basta un trap conservado, porque el tráfico coincidente restablece el child sin ningún temporizador.

Verifica por nombre, no por el estado del demonio

Lee la conexión y su child por nombre mientras el peer sigue caído, y luego otra vez cuando vuelve; la diferencia entre esas dos salidas es la prueba.

swanctl --initiate --child private-lan
swanctl --terminate --ike branch

Después confirma el servicio y no la asociación. Una asociación de seguridad child nueva más una petición correcta al destino privado que hay detrás son el par de hechos que importa, y un demonio en marcha con un túnel no relacionado sano no demuestra ninguno de los dos.

Si el child nunca inicia, comprueba que el tráfico de prueba coincida exactamente con los selectores configurados, incluidos protocolo y puerto. Si inicia y falla, lee el error de autenticación o de propuesta en lugar de esconderlo tras un bucle sin fin, porque keyingtries=0 repetirá un rechazo permanente para siempre.

Carga el cambio en una ventana y vuelve a probar

Recargar es más seguro que reiniciar el demonio, y aun así no es gratis: sustituir o descargar un child puede cerrar una asociación iniciada o tirar su trap.

Carga durante una ventana de mantenimiento, conserva el archivo anterior y confirma que la conexión aparece con los ajustes que querías y no con los predeterminados.

swanctl --load-conns
swanctl --list-conns

Revierte restaurando el archivo anterior y cargándolo de nuevo, y después repite los mismos dos comandos. Un túnel que solo vuelve tras reiniciar el demonio no está reparado, está reiniciado.