Acortar el temporizador DPD no acelera la conmutación por error de VPN

Los túneles caen, la recuperación tarda noventa segundos y el temporizador de par muerto está fijado en diez, así que se culpa al temporizador. Ese razonamiento omite tres etapas que ocurren después de la detección y que normalmente consumen la mayor parte del tiempo. La detección de vitalidad advierte el silencio; después, la selección de par, la autenticación, la instalación de la ruta y la reconexión de la aplicación toman cada una su turno. Acortar la primera etapa no puede acortar las demás, y puede añadir agitación a un sistema que ya estaba luchando.

Cuatro etapas, una de las cuales puede cronometrar

Escriba la recuperación como cuatro eventos con marcas de tiempo. El fallo se vuelve observable: el último tráfico protegido útil y la primera petición fallida. El mecanismo responsable reacciona: detección de vitalidad, un monitor de ruta u otro disparador documentado. La alternativa se vuelve utilizable: selección de par, autenticación, una nueva asociación y una ruta que realmente transporta el tráfico previsto. La aplicación se recupera: una operación nueva tiene éxito y lo que estaba en curso tiene un resultado definido.

Las reglas de vitalidad de IKEv2 describen pruebas sobre el par y sus intercambios, y no dicen nada sobre una base de datos o un servicio de archivos detrás de ese par. Leer un tiempo de espera de vitalidad como una comprobación de salud de todo el camino es el error que inicia la caza del temporizador.

Por qué el temporizador es el número menos interesante

Los valores configurados no son unidades intercambiables. Algunos son intervalos de reintento, otros son límites superiores de un intento y otros se ejecutan al mismo tiempo que los demás. Sumarlos produce un número que parece una predicción y se comporta como un rumor. Lea la documentación del campo que está a punto de tocar y anote cuál de los tres tipos es.

Otras etapas no son temporizadores en absoluto. Un retroceso de reconexión, una solicitud de autenticación interactiva o un cliente que solo reevalúa su configuración al reiniciar pueden dominar cada uno la interrupción mientras todos los temporizadores del protocolo están cómodamente bajos.

Mida la etapa que es realmente lenta

Capture el fallo una vez, con marcas de tiempo en ambos lados, y luego compare los cuatro eventos en lugar de los contadores propios del protocolo. Una ventana de observación bien hecha vale más que un mes de ajustes.

ip -4 route get 203.0.113.10
tcpdump -ni any -c 20 "esp or icmp"

Si el punto final alternativo nunca responde, ningún cambio de temporizador ayuda, porque la inalcanzabilidad no es un problema de detección. Si el nuevo estado de seguridad se forma con rapidez pero la ruta sigue apuntando al camino muerto, el problema es la instalación de la ruta y otro ajuste de vitalidad solo añade agitación.

La alternativa debe estar ya utilizable

Una copia de seguridad definida en una configuración no es una copia de seguridad que funcione. Debe ser alcanzable desde la red actual del cliente, capaz de autenticar la misma identidad y estar autorizada a transportar el mismo tráfico bajo la misma política. Descubra cualquiera de esas tres lagunas durante una interrupción y la discusión del temporizador se vuelve irrelevante. Pruebe la alternativa mientras la primaria está sana, porque es el único momento en que puede leer ambos registros uno al lado del otro.

Aprovisione la alternativa de antemano, pruébela deliberadamente mientras la primaria está sana y registre cuál de las cuatro etapas consume el tiempo. Ese registro es lo que convierte el siguiente cambio en una medición en lugar de una conjetura.

Agitación de retorno y la ruta de gestión

Restaurar la primaria es una decisión aparte. Un retorno agresivo puede interrumpir trabajo que ya se había recuperado en la copia de seguridad, y un camino inestable puede parecer un túnel inestable cuando el fallo real es una ruta que oscila entre dos opciones iguales.

Dos caminos de igual coste sin preferencia son la fuente habitual de la oscilación visible, porque cada monitor reacciona a la elección del otro. Decida qué camino se prefiere en condiciones normales y haga explícita esa preferencia en la configuración en lugar de dejarla al orden de las rutas. Defina de antemano el comportamiento de retorno deseado y quién es su dueño. Conserve la configuración anterior y una ruta de gestión independiente, porque un cambio que elimina su propio acceso durante una interrupción convierte un incidente de red en una visita al sitio.

Luego repita la misma carga de trabajo y compare las mismas cuatro marcas de tiempo. Una recuperación más corta que aún deja a la aplicación esperando la misma ruta o inicio de sesión ausente no es progreso, es un número distinto en el mismo gráfico.