Bat Posted December 4, 2008 Posted December 4, 2008 (edited) Добрый всем день! Имеем странную ситуацию, вдруг кто сталкивался. Клиент подключается по pppoe к серверу на Линукс. Клиент получает реальный IP. В качестве шлюза (удаленной стороны) в PPP-интерфейсе у него нереальный IP - 10.0.0.1. MTU на интерфейсе 1480 Пингаем удаленный хост. Пакеты до 2012 байт пролазят и все работает. Пакеты с размером начиная с 2013 не пролазят. На PPP-интрфейсе это выглядит так когад пролазят (2012 байт): 11:24:56.456632 XXX.XXX.XXX.16 > XXX.XXX.XXX.132: icmp: echo request (frag 45570:1376@0+) 11:24:56.456756 XXX.XXX.XXX.16 > XXX.XXX.XXX.132: (frag 45570:644@1376) 11:24:56.461829 XXX.XXX.XXX.132 > XXX.XXX.XXX.16: icmp: echo reply (frag 3448:1376@0+) 11:24:56.461847 XXX.XXX.XXX.132 > XXX.XXX.XXX.16: (frag 3448:644@1376) когда не пролазят (2013 байт): 11:22:28.711361 XXX.XXX.XXX.16 > XXX.XXX.XXX.132: icmp: echo request (frag 44429:1376@0+) 11:22:28.711365 XXX.XXX.XXX.16 > XXX.XXX.XXX.132: (frag 44429:645@1376) 11:22:34.211984 XXX.XXX.XXX.16 > XXX.XXX.XXX.132: icmp: echo request (frag 44432:1376@0+) 11:22:34.211988 XXX.XXX.XXX.16 > XXX.XXX.XXX.132: (frag 44432:645@1376) При этом на внешнем интерфейсе eth в случае когда пакеты пролазят - tcpdump трафик этот видит. Когда не пролазят - трафика нет совсем. Т.е. пакеты от юзера приходят на ppp-интерфейс, но почему=то дальше не уходят через интерфейс eth0. Где-то между ними дропаются. Если пинг инициирует удаленная сторона, то картина следующая. Пакет приходит на eth интерфейс, далее проходит в ppp-интерфейс, далее удаленная сторона генерирует ответ, этот ответ приходит обратно на ppp-интерфейс, но опять же в интерфейсе eth он не появляется. Вот так это выглядит, Когда пакет пролазит (2012 байт) На внешнем интерфейсе eth: 11:57:36.040580 XXX.XXX.XXX.9 > XXX.XXX.XXX.16: icmp: echo request (frag 15703:1480@0+) 11:57:36.041855 XXX.XXX.XXX.9 > XXX.XXX.XXX.16: (frag 15703:540@1480) 11:57:36.047831 XXX.XXX.XXX.16 > XXX.XXX.XXX.9: icmp: echo reply (frag 2228:1448@0+) 11:57:36.047838 XXX.XXX.XXX.16 > XXX.XXX.XXX.9: (frag 2228:572@1448) На интерйесе ppp: 11:57:06.647893 XXX.XXX.XXX.9 > XXX.XXX.XXX.16: icmp: echo request (frag 15702:1456@0+) 11:57:06.647913 XXX.XXX.XXX.9 > XXX.XXX.XXX.16: (frag 15702:564@1456) 11:57:06.653489 XXX.XXX.XXX.16 > XXX.XXX.XXX.9: icmp: echo reply (frag 2192:1376@0+) 11:57:06.653496 XXX.XXX.XXX.16 > XXX.XXX.XXX.9: (frag 2192:644@1376) Когда пакет НЕ пролазит (2013 байт) На внешнем интерфейсе eth: 11:55:59.309480 XXX.XXX.XXX.9 > XXX.XXX.XXX.16: icmp: echo request (frag 15638:1480@0+) 11:55:59.310738 XXX.XXX.XXX.9 > XXX.XXX.XXX.16: (frag 15638:541@1480) 11:56:00.309553 XXX.XXX.XXX.9 > XXX.XXX.XXX.16: icmp: echo request (frag 15639:1480@0+) 11:56:00.310677 XXX.XXX.XXX.9 > XXX.XXX.XXX.16: (frag 15639:541@1480) На интерйесе ppp: 11:56:17.323926 XXX.XXX.XXX.9 > XXX.XXX.XXX.16: icmp: echo request (frag 15656:1456@0+) 11:56:17.323950 XXX.XXX.XXX.9 > XXX.XXX.XXX.16: (frag 15656:565@1456) 11:56:17.329173 XXX.XXX.XXX.16 > XXX.XXX.XXX.9: icmp: echo reply (frag 2036:1376@0+) 11:56:17.329177 XXX.XXX.XXX.16 > XXX.XXX.XXX.9: (frag 2036:645@1376) Еще что интересно. Если клиент получает нереальный IP и сидит за НАТом этого же сервера, то у него все работают и ходят гораздо большие пакеты, проверяли вплоть до 30000 байт. Может кто сталкивался с подобной проблемой? Edited December 4, 2008 by Bat Вставить ник Quote
AlKov Posted December 4, 2008 Posted December 4, 2008 MTU?? Попробуйте в iptables iptables -A FORWARD -p tcp -s $LAN_IPP_RANGE --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu $LAN_IPP_RANGE - это та подсеть, из которой юзверь получает IP. Не знаю, как с pppoe (не юзал), на pptp такое помогает. Вставить ник Quote
Bat Posted December 4, 2008 Author Posted December 4, 2008 MTU??Попробуйте в iptables iptables -A FORWARD -p tcp -s $LAN_IPP_RANGE --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu $LAN_IPP_RANGE - это та подсеть, из которой юзверь получает IP. Не знаю, как с pppoe (не юзал), на pptp такое помогает. Не помогло :(Пакеты ходят, но не работает 108 6912 TCPMSS tcp -- * * ХХХ.XXX.XXX.16 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU Вставить ник Quote
AlKov Posted December 4, 2008 Posted December 4, 2008 MTU??Попробуйте в iptables iptables -A FORWARD -p tcp -s $LAN_IPP_RANGE --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu $LAN_IPP_RANGE - это та подсеть, из которой юзверь получает IP. Не знаю, как с pppoe (не юзал), на pptp такое помогает. Не помогло :(Пакеты ходят, но не работает 108 6912 TCPMSS tcp -- * * ХХХ.XXX.XXX.16 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU Фаервол? Может он дропает/режектит большие пакеты именно в этой подсети (где реал IP). Ну типа защиты от SYN флуда, DDoS и т.п. Вы же, как я понял, "длинным" пингом проверяете. Попробуйте временно разрешить все для одного IP хотя бы. Вставить ник Quote
Bat Posted December 4, 2008 Author Posted December 4, 2008 Непонятно. Как-то само по себе заработало.... Вставить ник Quote
Ivan_83 Posted December 4, 2008 Posted December 4, 2008 Может сетевуха гнать. У меня на одной работе один комп подключённый к локалке пускал в себя по удалённому рабочему столу, инет вроде тоже работал, а вот скачать файл с шары/на шару, или по фтп - фиг. Вылечилось отключеним всех аппаратных фич в настройках сетевухи (расчёты контрольной суммы и прочее), сетевуха была скорее всего реалтек впаяная, возможно марвелл. Вставить ник Quote
AlKov Posted December 4, 2008 Posted December 4, 2008 Мда.. Дошло, почему TCPMSS не помогло - вы же пингом (icmp) проверяете! А правило в iptables для TCP только действует. Сорри, за невнимательность.. Вставить ник Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.