Retroceso de repetición de OpenVPN en el registro: qué no demuestra la línea

La línea dice PID_ERR replay-window backtrack occurred, y todos los resultados de búsqueda lo explican como paquetes descartados y un túnel roto. En la ruta UDP de Community OpenVPN 2.6, ese mensaje se escribe mientras la función de recepción todavía decide qué hacer con el paquete. Registra un nuevo máximo de retroceso y luego la misma función compara la distancia con la ventana y el estado registrado antes de aceptar o rechazar. Leer la etiqueta del registro como el veredicto es el error que esta lista de comprobación existe para evitar.

Parada uno: identifique qué es la línea

Es un diagnóstico sobre la distancia de secuencia, no una decisión sobre una conexión. Aparece en la implementación del ID de paquete en el punto donde se anota un máximo de retroceso recién observado. Ese punto está antes de la rama de aceptar o rechazar, por lo que un paquete que lo provoca todavía puede entregarse.

Confirme qué host la escribió y con qué verbosidad. Un servidor y un cliente pueden emitir mensajes de ID de paquete, y un mensaje de un lado no dice nada sobre el estado de recepción del otro.

Parada dos: encuentre el resultado de ese paquete

Lea las líneas posteriores al diagnóstico en lugar de solo el diagnóstico. La misma función continúa hacia sus comprobaciones de ventana y duplicados, así que el resultado de ese paquete concreto se decide unas instrucciones después y bien puede ser la aceptación. Un extracto de registro que termina en la línea aterradora no le dice nada sobre el resultado. Busque una ventana a su alrededor, no la línea en sí:

journalctl -u openvpn-server@server --since "-10 min" | grep -n -A3 -B3 "backtrack occurred"

Si el registro no muestra ningún rechazo para ese par en ese momento, deje de tratar esta línea como la causa de la caída. Pase a la ruta de la aplicación, que es donde la mayoría de los informes de conectado pero sin tráfico realmente terminan.

Parada tres: decida si la reordenación es real

La reordenación es una propiedad de la ruta, y un diagnóstico es una sola muestra de ella. Busque mensajes repetidos para el mismo par en una ventana corta y compárelos con una captura en ambos extremos antes de concluir que la red reordena con agresividad.

Un puñado de mensajes durante una reconexión no tiene nada de particular. Un flujo continuo junto con tiempos de espera reales de la aplicación merece investigación, y esa combinación es evidencia, no una etiqueta.

Parada cuatro: los parámetros de la ventana y qué no son

replay-window toma un tamaño de secuencia y un valor de tiempo opcional, así que ampliarlo cambia dos tolerancias distintas a la vez. Subir el número admite paquetes más alejados del orden; el valor de tiempo limita cuánto tiempo puede seguir considerándose un paquete. Ampliar es un cambio de política con un coste de seguridad, y no refuerza un cifrado ni desactiva la detección de duplicados. Las dos tolerancias se mueven juntas, lo haya querido o no.

Un paquete autenticado antiguo todavía puede ser una repetición no deseada, por eso el receptor mantiene estas comprobaciones. Aceptar más reordenación significa aceptar más de ese riesgo.

Silenciar la advertencia con mute cambia lo que ve, no lo que hace el demonio. Si el objetivo es un registro más tranquilo durante un evento conocido, es una elección operativa legítima; si el objetivo es reparar un túnel, silenciar oculta la evidencia.

mute 20
replay-window 64 15

Cambiar el transporte exterior a TCP cambia el comportamiento de entrega y recuperación y añade sus propios costes de bloqueo de cabeza de cola. Es una decisión de diseño, no una primera respuesta a una etiqueta del registro. Reinstalar el servidor es peor, porque borra la distinción entre una estadística y la frontera que realmente falló.

Parada cinco: pruebe la ruta que le importa al usuario

Con el túnel conectado, ejecute la prueba propia de la aplicación y lea su ruta seleccionada, su estado de reenvío y su ruta de retorno. Un túnel que transporta paquetes solo en una dirección no produce ningún mensaje de retroceso, y es mucho más común que una reordenación grave.

Anote lo que midió en cada parada. El registro es lo que impide que el siguiente informe vuelva a empezar en la línea aterradora y trabaje hacia fuera desde allí.

La implementación del ID de paquete muestra el orden de la estadística y la decisión, y el manual describe el alcance de secuencia y de tiempo de la ventana. Leer ambas cosas juntas es lo que convierte una línea de registro aterradora en una cantidad conocida. Ninguna de las dos dice nada sobre su ruta concreta, por eso las mediciones anteriores siguen importando.