я бегу 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
Но, похоже, это не решает проблему.
Как я могу отладить, где именно проблема, и понять, как ее решить?
Вы уверены, что разрешаете сообщения ICMP типа 3 с кодом 4 (т.е. требуется фрагментация) от вашего шлюза к обеим конечным точкам? И действительно ли конечные точки их получают?
Начиная с Windows 95 практически все операционные системы использовали Path MTU Discovery. На практике это означает, что они будут отправлять все свои TCP-пакеты с установленным флагом «Не фрагментировать». Если пакет оказывается больше, чем MTU некоторого перехода в маршруте пакета, маршрутизатор, столкнувшийся с проблемой, должен отправить ICMP-сообщение «Требуется фрагментация» обратно отправителю. Из этого сообщения отправитель будет знать точный MTU на этом переходе и будет знать, что нужно соответствующим образом изменить размер пакетов. В результате конечные точки будут определять размер своих пакетов, так что маршрутизатору вообще не нужно будет их фрагментировать. Это улучшает производительность.
Но если кто-то блокирует сообщения ICMP «Требуется фрагментация», механизм определения MTU пути не будет работать. Поскольку получатель никогда не получает пакет, размер которого превышает MTU определенного перехода на маршруте пакета, получатель никогда не подтверждает его. Как только отправитель увидит, что пакет не был подтвержден, он повторно отправит этот пакет - и, поскольку он не знает, что нужно уменьшить MTU для этого конкретного соединения, он повторно отправит пакет в точности так, как он был: с тем же MTU, который был слишком большой для одного прыжка. Так что повторная отправка в этом случае не поможет.