Por qué el cifrado por sí solo no detiene un paquete reenviado

Los paquetes protegidos no caducan criptográficamente, así que uno que era válido hace cinco minutos sigue siendo válido ahora, porque el cifrado y la protección de integridad no dicen nada sobre cuándo se produjeron los bytes. Un atacante que puede capturar y reenviar tráfico no necesita romper el cifrado. Por eso cada protocolo de túnel serio lleva estado de secuencia junto a sus claves.

El mecanismo es pequeño, y sus modos de fallo se confunden fácilmente con la pérdida de paquetes.

El texto cifrado válido no es texto cifrado fresco

La autenticación responde a una pregunta: si estos bytes llegaron sin modificar de alguien que posee la clave. No responde si es la primera vez que el receptor los ve. Un paquete reenviado supera perfectamente la primera prueba, y por eso exactamente la comprobación de integridad sola no puede detener un reenvío y el protocolo necesita una segunda regla sobre la aceptación. Un receptor que solo autentica no tiene defensa contra un atacante que tiene una grabación.

Esa regla es barata de implementar y barata de enunciar: acepta un paquete protegido dado una vez, bajo una clave dada. Todo lo demás en este terreno se deriva de cómo la implementación rastrea esa única vez.

Leer un descarte por reenvío como un fallo de descifrado te lleva al subsistema completamente equivocado.

Un número de secuencia y una ventana

IPsec ESP lleva un número de secuencia y el receptor mantiene una ventana deslizante de valores aceptados recientemente, mientras la especificación de ESP describe el tamaño de ventana predeterminado y la opción de ampliarlo. WireGuard toma otra ruta con un contador por clave y una comprobación explícita contra él. Ninguno de los dos diseños supone que los paquetes lleguen en orden, porque las redes reales los reordenan. Ambos toleran el reordenamiento, y ninguno tolera la repetición.

La ventana es lo que hace posible esa tolerancia. Un paquete ligeramente por detrás del valor más alto visto todavía puede aceptarse si no se ha aceptado antes; uno muy por detrás, o uno cuya casilla ya está marcada, se descarta. Aumenta la ventana y tolerarás más reordenamiento a costa de más estado por asociación.

Los contadores de diagnóstico te muestran en qué caso estás. Los descartes por reenvío incrementan un contador específico en lugar de un error genérico, y leer ese contador es la primera observación útil.

nstat -az | grep -i XfrmIn
ip -s xfrm state | head -n 30
wg show wg0 transfer

El estado pertenece a la clave, no al host

El estado del contador está ligado a una asociación de seguridad o a una época de clave, así que una renovación de clave crea un contexto nuevo y su propio espacio de secuencia. Borrar un contador sin sustituir la clave, o reutilizar una asociación tras un reinicio manual, rompe la suposición de la que depende la ventana del receptor. Por eso existe la renovación de claves impulsada por el protocolo en lugar de un botón de reinicio visible para el operador.

Cuando un túnel se comporta mal tras una intervención manual, pregunta si la intervención tocó el estado de secuencia. Una configuración que parece idéntica puede comportarse distinto porque el estado que heredó no es el estado que espera.

Diagnostica la causa antes de desactivar nada

La pérdida, el reordenamiento, el tráfico duplicado y un defecto de implementación se manifiestan todos como retransmisiones, y solo uno es un problema de reenvío. Desactivar la comprobación para silenciar el ruido elimina la propiedad en la que confiabas y hace más difícil encontrar la causa original, porque ahora las retransmisiones no tienen ninguna explicación.

Captura pruebas limitadas: identificadores de asociación, números de secuencia y contadores, sin las cargas útiles. Eso basta para distinguir un duplicado de una llegada reordenada, y no convierte tu archivo de diagnóstico en una copia del tráfico del usuario.

Qué no promete la comprobación

La protección contra reenvíos es una propiedad del procesamiento de paquetes dentro de un protocolo. No significa que el operador no guarde registros, que un sitio web no pueda reconocer una cuenta o que una sesión sea anónima. Son cuestiones separadas sobre sistemas separados, y un diseño sólido contra reenvíos no responde a ninguna de ellas.

El software mantenido con ajustes compatibles es el control práctico del que dispone un usuario. El protocolo se encarga del paquete; todo lo demás sigue siendo una decisión operativa.