Retransmisiones TCP frente a descartes de repetición IPsec: lea cada capa

Tres herramientas distintas informan de tres duplicados distintos, y solo uno de ellos es un evento de red sobre el que puede actuar. Una retransmisión TCP es un emisor que vuelve a enviar un rango, un ACK duplicado es un receptor que repite una confirmación, y un descarte de repetición ESP es una asociación de seguridad que rechaza un número de secuencia que ya ha aceptado. Ninguno de los tres implica a los otros. Lea cada contador en la capa que lo produce antes de unirlos en una historia.

Tres contadores que nunca miden el mismo evento

La anotación de retransmisión TCP significa que el emisor ha vuelto a poner un rango de secuencia en el cable. La pérdida es una de las razones de ello, y la captura que tiene puede simplemente carecer del paquete original o de la confirmación que explicaría el momento. Un ACK duplicado es el receptor repitiendo una confirmación acumulativa según las reglas de recuperación de TCP, lo que no es ni una escritura duplicada de la aplicación ni una segunda copia de los datos.

ESP trabaja en su propio espacio de secuencia. Cada asociación de seguridad numera los paquetes que envía, y el receptor mantiene una ventana de números que ya ha aceptado, así que un paquete ESP que llega dos veces se descarta solo por esas reglas. Por eso un segmento TCP retransmitido viaja en un paquete ESP nuevo con un número de secuencia nuevo, lo que es el comportamiento correcto en ambas capas. Los mismos bytes pueden parecer nuevos en un contador y viejos en otro, y ninguna de las dos capas miente.

Qué puede ver el analizador y qué no

Empiece por el vocabulario del analizador, porque los nombres de los filtros describen observaciones y no el interior de los extremos. Contar con los mismos nombres que usa la herramienta le mantiene honesto sobre lo que se midió realmente. Un recuento de una captura incompleta es un recuento de lo que sobrevivió, no de lo que ocurrió en el cable.

tshark -r trace.pcap -Y "tcp.analysis.retransmission" | wc -l
tshark -r trace.pcap -Y "tcp.analysis.duplicate_ack" | wc -l

Lea la información de experto junto a esos números, porque los avisos de suma de comprobación y de orden cambian cuánto peso merecen. Un rastro fusionado de dos sensores puede mostrar una trama dos veces, y contar ambas copias inventa un evento de recuperación que nunca ocurrió.

Los contadores ESP viven en el estado del núcleo

Los números de secuencia ESP pertenecen a la asociación de seguridad, no al flujo TCP, así que la puerta de enlace es el lugar donde preguntar. El listado de estado informa contadores de paquetes y errores por asociación que ninguna captura puede reconstruir.

ip -s xfrm state
tshark -r trace.pcap -Y "esp" -T fields -e esp.seq | head

RFC 4303 define el número de secuencia y la ventana antirrepetición que lo consume, y por eso el contador sube incluso cuando nada va mal. Los números de secuencia externos monótonos sin una anomalía TCP correspondiente apuntan a otro emisor o a una ruta duplicada más que a una tormenta de retransmisiones. Una captura externa de un túnel cifrado suele ocultar los números de secuencia TCP internos, así que no puede demostrar qué hizo la pila interna. Capture dentro del túnel solo donde la política lo permita, y nunca desactive la antirrepetición para silenciar un aviso no relacionado.

Donde el punto de observación cambia la respuesta

Antes de escalar, anote cómo se tomó la captura: la interfaz, si el proceso de captura informó de pérdidas y si las marcas de tiempo son comparables entre sensores. Un punto de observación no puede ver ambos extremos de una ruta, así que cualquier afirmación sobre el comportamiento del receptor es una inferencia y no una medición. Un rastro tomado en la puerta de enlace y un rastro tomado en el host discreparán sobre el orden bajo carga, y esa discrepancia suele pertenecer a la captura y no al túnel. Correlacionar dos vistas es lo que convierte un recuento en evidencia.

Use un flujo de aplicación permitido y anote los contadores de los extremos junto a los recuentos de la captura en el mismo momento. Si los números discrepan, confíe en la capa que posee el evento y trate la otra como un artefacto de observación hasta que se demuestre lo contrario. Esa regla resuelve la mayoría de estos casos sin tocar la configuración del túnel.

Leer los números en el orden correcto

Empiece por la capa donde se hizo la pregunta: un aviso TCP se responde con una captura TCP, y un descarte ESP se responde con los contadores de la asociación de seguridad en la puerta de enlace. Solo entonces pregunte si las dos vistas describen el mismo paquete. Una conclusión que necesita ambas capas debería nombrar ambas, porque una afirmación sobre el túnel basada solo en una anotación TCP es una conjetura.

Anote la capa, el contador y el punto de observación de cada hallazgo, y el siguiente lector no fusionará tres eventos en una falla imaginaria. Escale con esos tres campos y la corrección suele seguir del primero.