S
SwD
Guest
Итак, имеем следующую картину...
Удалённая точка, подключенная через нормального провайдера (например Крымтел, Свифт-трейс), пробует простроить openvpn-туннель на УТ-интерфейс в моей головной конторе. Это проходит без проблем, и туннель стоит... Однако стоит подать на него плотную нагрузку (ну, например, uucp/rsync/плотный ping), как тут же туннелю становится плохо... Вдумчивое втыкание в tcpdump показало, что падение туннеля вызвано дропом больших (т.е. фрагментированных) пакетов. Тупое уменьшение MTU на интерфейсе удалённой точки проблему решило, равно как и более элегантное iptables -A OUTPUT -o eth1 -p tcp -d 82.207.xxx.xxx --tcp-flag SYN,RST SYN -m tcpmss --mss 1420:1500 -j TCPMSS --set-mss 1420 .
Но...
1. Наблюдал ли кто аналогичные проблемы с дропом пакетов на неУТ/УТ-коннектах?
2. Прав ли я, предполагая, что проблемы вызваны некорректной работой pmtud в недрах УТшной сетки (например какой-то шлюз зафильтровал напрочь icmp и/или тупо передаёт лишь первую часть фрагментированного пакета, дропая оставшиеся, что приводит к невозможности собрать такой пакет в финальной точке)? Косвенно это подтверждается тем, что при коннекте не на УТ никаких плясок с MTU/MSS производить не надо.
3. Как, собственно, корректно вычислить MTU в данном случае? Ибо реально я скорее с потолка взял 1460 в описанном случае (вернее потихоньку уменьшал изначальные 1500).
Удалённая точка, подключенная через нормального провайдера (например Крымтел, Свифт-трейс), пробует простроить openvpn-туннель на УТ-интерфейс в моей головной конторе. Это проходит без проблем, и туннель стоит... Однако стоит подать на него плотную нагрузку (ну, например, uucp/rsync/плотный ping), как тут же туннелю становится плохо... Вдумчивое втыкание в tcpdump показало, что падение туннеля вызвано дропом больших (т.е. фрагментированных) пакетов. Тупое уменьшение MTU на интерфейсе удалённой точки проблему решило, равно как и более элегантное iptables -A OUTPUT -o eth1 -p tcp -d 82.207.xxx.xxx --tcp-flag SYN,RST SYN -m tcpmss --mss 1420:1500 -j TCPMSS --set-mss 1420 .
Но...
1. Наблюдал ли кто аналогичные проблемы с дропом пакетов на неУТ/УТ-коннектах?
2. Прав ли я, предполагая, что проблемы вызваны некорректной работой pmtud в недрах УТшной сетки (например какой-то шлюз зафильтровал напрочь icmp и/или тупо передаёт лишь первую часть фрагментированного пакета, дропая оставшиеся, что приводит к невозможности собрать такой пакет в финальной точке)? Косвенно это подтверждается тем, что при коннекте не на УТ никаких плясок с MTU/MSS производить не надо.
3. Как, собственно, корректно вычислить MTU в данном случае? Ибо реально я скорее с потолка взял 1460 в описанном случае (вернее потихоньку уменьшал изначальные 1500).