Перейти к содержимому
Калькуляторы

Не пролазят большие пакеты

Добрый всем день!

 

Имеем странную ситуацию, вдруг кто сталкивался. Клиент подключается по 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 байт.

 

Может кто сталкивался с подобной проблемой?

Изменено пользователем Bat

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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 такое помогает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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 хотя бы.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Непонятно. Как-то само по себе заработало....

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Может сетевуха гнать.

У меня на одной работе один комп подключённый к локалке пускал в себя по удалённому рабочему столу, инет вроде тоже работал, а вот скачать файл с шары/на шару, или по фтп - фиг.

Вылечилось отключеним всех аппаратных фич в настройках сетевухи (расчёты контрольной суммы и прочее), сетевуха была скорее всего реалтек впаяная, возможно марвелл.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мда.. Дошло, почему TCPMSS не помогло - вы же пингом (icmp) проверяете! А правило в iptables для TCP только действует.

Сорри, за невнимательность..

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.