Повторные передачи TCP против отбрасываний повторов IPsec: читайте каждый уровень

Три разных инструмента сообщают о трёх разных дубликатах, и только один из них — сетевое событие, на которое можно повлиять. Повторная передача TCP — это отправитель, заново отправляющий диапазон, дублированный ACK — это получатель, повторяющий подтверждение, а отбрасывание повтора ESP — это ассоциация безопасности, отвергающая номер последовательности, который она уже приняла. Ни одно из трёх не подразумевает остальные. Читайте каждый счётчик на том уровне, который его создаёт, прежде чем связывать их в одну историю.

Три счётчика, которые никогда не измеряют одно и то же событие

Пометка повторной передачи TCP означает, что отправитель снова поместил диапазон последовательности в сеть. Потеря — одна из причин этого, и в имеющейся у вас записи может просто не быть исходного пакета или подтверждения, которое объяснило бы время. Дублированный ACK — это получатель, повторяющий кумулятивное подтверждение по правилам восстановления TCP, что не является ни дублированной записью приложения, ни второй копией данных.

ESP работает в собственном пространстве последовательностей. Каждая ассоциация безопасности нумерует отправляемые пакеты, а получатель хранит окно уже принятых номеров, поэтому ESP-пакет, пришедший дважды, отбрасывается только на этом основании. Поэтому повторно отправленный сегмент TCP путешествует в новом ESP-пакете с новым номером последовательности, что является правильным поведением на обоих уровнях. Одни и те же байты могут выглядеть новыми в одном счётчике и старыми в другом, и ни один из уровней не лжёт.

Что анализатор может и чего не может видеть

Начните со словаря анализатора, потому что имена фильтров описывают наблюдения, а не внутреннее устройство конечных точек. Подсчёт теми же именами, которые использует инструмент, сохраняет честность в отношении того, что действительно измерено. Счёт из неполной записи — это счёт того, что выжило, а не того, что произошло на линии.

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

Читайте экспертную информацию рядом с этими числами, потому что предупреждения о контрольной сумме и порядке меняют то, сколько веса они заслуживают. Объединённый след с двух датчиков может показать один кадр дважды, а подсчёт обеих копий изобретает событие восстановления, которого никогда не было.

Счётчики ESP живут в состоянии ядра

Номера последовательности ESP принадлежат ассоциации безопасности, а не потоку TCP, поэтому шлюз — это место, где нужно спрашивать. Список состояний сообщает счётчики пакетов и ошибок по каждой ассоциации, которые не может восстановить ни одна запись.

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

RFC 4303 определяет номер последовательности и окно защиты от повторов, которое его расходует, поэтому счётчик растёт даже тогда, когда всё в порядке. Монотонные внешние номера последовательности без соответствующей аномалии TCP указывают на другого отправителя или дублированный путь, а не на бурю повторных передач. Внешняя запись зашифрованного туннеля обычно скрывает внутренние номера последовательности TCP, поэтому не может доказать, что сделал внутренний стек. Записывайте внутри туннеля только там, где это разрешено политикой, и никогда не отключайте защиту от повторов, чтобы заглушить несвязанное предупреждение.

Где точка наблюдения меняет ответ

Прежде чем эскалировать, запишите, как была сделана запись: интерфейс, сообщал ли процесс записи о потерях и сопоставимы ли метки времени между датчиками. Одна точка наблюдения не может видеть оба конца пути, поэтому любое утверждение о поведении получателя — это вывод, а не измерение. След, снятый на шлюзе, и след, снятый на хосте, будут расходиться в порядке под нагрузкой, и это расхождение обычно принадлежит записи, а не туннелю. Сопоставление двух представлений — это то, что превращает счёт в доказательство.

Используйте один разрешённый поток приложения и запишите счётчики конечных точек рядом с числами записи в один и тот же момент. Если числа расходятся, доверяйте уровню, которому принадлежит событие, а другой считайте артефактом наблюдения, пока не доказано обратное. Это правило решает большинство таких случаев, не касаясь конфигурации туннеля.

Чтение чисел в правильном порядке

Начните с уровня, на котором задан вопрос: на предупреждение TCP отвечают из записи TCP, а на отбрасывание ESP — из счётчиков ассоциации безопасности на шлюзе. Только затем спрашивайте, описывают ли два представления один и тот же пакет. Вывод, которому нужны оба уровня, должен называть оба, потому что утверждение о туннеле, опирающееся только на пометку TCP, — это догадка.

Записывайте уровень, счётчик и точку наблюдения для каждой находки, и следующий читатель не сольёт три события в одну воображаемую неисправность. Эскалируйте с этими тремя полями, и исправление обычно следует из первого.