Проблемы с повторной передачей TCP, дубликатами и т. Д. В CentOS Linux

Я использую шлюз Vyatta с CentOS Linux позади и IPSec туннель впереди.

Попытка отобразить мои настройки:

PARTNER-NETWORK <--- IPSec (GRE, MTU 1420) ---> VYATTA (TUNNEL, MTU 1420 <> eth0, MTU 1500) <---> CentOS (eth0, MTU 1500) <---> internet (eth0, MTU 1500)

Я вижу много повторных передач TCP, дубликатов и т.д. из-за разного MTU / MSS - трудно отлаживать: (

Я пытался добавить следующее на моем CentOS:

iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Но, похоже, это не решает проблему.

Как я могу отладить где проблема именно в том, и есть идеи, как решить эту проблему?

1
задан 10 April 2018 в 12:02
1 ответ

Вы уверены, что разрешаете передачу сообщений ICMP типа 3 с кодом 4 (т.е. фрагментация необходима) от вашего шлюза на обе конечные точки? И действительно ли конечные точки получают их?

Начиная с Windows 95, практически все операционные системы используют Path MTU Discovery. На практике это означает, что они будут посылать все свои TCP пакеты с установленным флагом Don't Fragment. Если пакет оказывается больше, чем MTU какого-то прыжка в маршруте пакета, маршрутизатор, сталкивающийся с проблемой, должен отправить отправителю ICMP сообщение "Fragmentgment Needed" (Нужна фрагментация). Из этого сообщения отправитель будет знать точный MTU этого прыжка и будет знать, как изменить размер пакетов соответственно. В результате, конечные точки будут изменять размер своих пакетов таким образом, чтобы ни один маршрутизатор не нуждался в их фрагментации. Это улучшает производительность.

Но если кто-то блокирует ICMP сообщения "Fragmententation Needed", механизм Path MTU Discovery не будет работать. Так как получатель никогда не получит пакет, который был больше, чем MTU конкретного прыжка по маршруту прохождения пакета, получатель никогда не признает его. Как только отправитель увидит, что пакет не был подтвержден, он повторно отправит этот пакет - и так как он не имеет понятия, что MTU должен быть сокращен для данного конкретного соединения, он повторно отправит пакет точно так же, как он был: с тем же самым MTU, который был слишком большим для одного прыжка. Так что повторная отправка не поможет в этом случае.

.
1
ответ дан 3 December 2019 в 23:18

Теги

Похожие вопросы