La detección de par muerto de IKEv2 no prueba su aplicación

La comprobación de vitalidad de IKEv2 plantea una pregunta: sigue respondiendo el otro par en la relación de control protegida. No mide si una aplicación interna está sana, si existe una ruta detrás de la puerta de enlace ni si navegar parece rápido. La comprobación puede pasar mientras todo lo útil detrás del túnel falla.

Lea los dos tipos de evidencia por separado antes de cambiar un temporizador.

Qué pregunta realmente la comprobación de vitalidad

Un intercambio de vitalidad se envía dentro de la asociación de seguridad IKE establecida y espera una respuesta dentro de una ventana configurada. El éxito significa que la implementación de IKE del par sigue ahí y sigue dispuesta a hablar. No dice nada sobre las asociaciones de seguridad hijas que transportan tráfico, nada sobre el enrutamiento más allá de la puerta de enlace y nada sobre el servicio por el que abrió el túnel. Son tres preguntas separadas con tres modos de fallo separados.

Esa distinción decide dónde mirar cuando una sesión se queda callada. Un par que sigue respondiendo mientras una ruta de datos está rota apunta a política, enrutamiento o un servicio posterior. Un par que deja de responder apunta a alcanzabilidad o al estado propio del extremo lejano.

Lea las asociaciones de seguridad antes del navegador

El estado de control y el estado de datos se listan por separado en cuanto se pregunta al demonio, y los contadores dicen si se intentó algo. Una asociación hija que nunca se instaló no se parece en nada a una que se instaló y luego dejó de pasar paquetes, aunque ambas producen la misma queja del usuario.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

Anote los nombres de estado literalmente en el ticket, junto con los contadores en el momento de la queja. Una descripción como túnel caído oculta cuál de las dos asociaciones terminó, y normalmente ese es el único dato que vale la pena tener.

Un fallo de ruta parece exactamente un par muerto

La puerta de enlace puede responder a los intercambios de control mientras un servidor privado está desconectado, falta una ruta reenviada o la resolución de nombres interna falla por completo. Desde el cliente, todo eso se presenta como una sesión activa y un destino que no lo está. Compruebe la ruta de vuelta con el mismo cuidado que la de ida, porque el enrutamiento asimétrico en el extremo lejano produce silencio solo en una dirección.

Pruebe la aplicación prevista directamente y nombre la dirección que intentó, en lugar de probar si el túnel está levantado. Un ping a la puerta de enlace demuestra que la puerta responde; nunca demostró que la aplicación lo hiciera. Registre la dirección exacta que intentó la aplicación. Esa cadena acota la búsqueda más adelante, y es el único dato que el ticket suele omitir.

Mantenga los temporizadores fuera del diagnóstico

Acortar un intervalo de detección no es un cambio de rendimiento y no añade capacidad. Con pérdida de paquetes cambia la rapidez con que se reconoce un fallo, lo que puede hacer que un síntoma parezca distinto sin mejorar nada. Registre primero la hora real del fallo y luego decida si la tolerancia es incorrecta para el enlace que realmente tiene.

Las actualizaciones de mapeo NAT pertenecen a la misma categoría. Mantienen utilizable una ruta traducida y no son evidencia de que la aplicación remota funcione.

Una política de recuperación completa dice qué debe hacer el cliente cuando se declara muerto un par: reiniciar, cerrar o esperar, y qué puede hacer el resto del tráfico mientras ocurre. Sin eso, el mismo incidente se vuelve a diagnosticar desde cero cada trimestre.