Проблемы с Mtu/mss

[S10]

Имеется шлюз на Endian Firewall Community 2.4.1. MTU внешнего интерфейса 1400, внутреннего - 1500.

iptables 1.4.8, ядро Linux 2.6.32.

Собственно, проблема: некоторые сайты загружаются медленно. Подробнее проблема и метод ее решения описаны здесь.

 

Итак, по-умолчанию в списке правил iptables EFW присутствовало

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

При этом шлюз при загрузке некоторых сайтов посылал ICMP-ответы "Destination Unreachable" в локалку с просьбой установить MSS в 1360.

Я заменил это правило на iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS -–set-mss 1360

Однако, не помогло. Шлюз по-прежнему посылает "Destination Unreachable". Перезапуск iptables и самого шлюза(из-за отключения света) не помогли.

 

Товарищи опытные сетевики, подскажите, куда копать? Баг в iptables?

[oldbay]

куда копать? Баг в iptables?

 

давай попробуем с самого начала

посмотрите в /usr/src/ядро/.config

там есть опции:

CONFIG_NETFILTER_XT_TARGET_TCPMSS и CONFIG_NETFILTER_XT_MATCH_TCPMSS в состоянии =y либо =m ?

 

выложите

sysctl -a | grep ipv4

и

iptables -t mangle -L -v

[S10]

посмотрите в /usr/src/ядро/.config

EFW - это очень куцый линукс. /usr/src там нет, как и многих утилит...

 

sysctl -a | grep ipv4

http://pastebin.com/8N5PtWii

 

iptables -t mangle -L -v

http://pastebin.com/uyQJXJum

[oldbay]

EFW - это очень куцый линукс. /usr/src там нет, как и многих утилит...

этого следовало ожидать ... но и без конфига ядра теперь в принципе понятно что собиралось с нужными опциями(созданные правила работают)

 

sysctl -a | grep ipv4

 

http://pastebin.com/8N5PtWii

 

тут вроде без аномалий

 

iptables -t mangle -L -v

 

http://pastebin.com/uyQJXJum

 

не фига себе как много всего в mangle ,настройки самого дистрибутива?

но одно понятно что пакеты через правило:

211K   10M TCPMSS	 tcp  --  any	any	 anywhere			 anywhere			tcp flags:SYN,RST/SYN TCPMSS set 1360

идут ....

 

еще просьба скинуть не mangle-вский FORWARD

iptables -L FORWARD -v

 

и сторчек 40-50 дампа с интерфейса смотрящего в локалку на момент открытия проблемного сайта на машине в локальной сети(на данной локальной станции лучше всего минимизировать работу сетевых служб и протоколов, а лучше отключить все кроме браузера)

 

tcpdump -i <интерфейс смотрящий в локалку> | grep <ip-шник машины в сети на которой проводится тест>

[S10]

не фига себе как много всего в mangle ,настройки самого дистрибутива?

Угу. Единственное, что я добавлял - правила для исходящего трафика через веб-морду, но они в filter/OUTGOINGFW записываются.

 

iptables -L FORWARD -v

http://pastebin.com/B1q4reyF

 

Ну и вывод tcpdump: http://pastebin.com/NJdqxvaU

 

oldbay

Посоветуйте сразу теоретический материал по iptables для самых маленьких. Я пока плохо понимаю прохождение трафика через цепочки и таблицы данного пакетного фильтра.

[suin]

Вот вы хернёй страдаете внатуре !

У меня VPN-сервер на Дебиане,

iptables там чистый, какой ещё нахер мангл ?!?

Все POLICY по умолчанию ACCEPT, форвардинг вклёчен.

Одно моё правило, которое натит на выходе:

 

iptables -t nat -A POSTROUTING -s 172.16/12 -o eth0 -j SNAT --to-source SERVER_OUT_IP

 

Да, MTU разный на входе (tunX) и на выходе (eth0) , но ядро всё натит само правильно,

не надо ничё манглить руками !

Да ваще линукс - говно !!!

 

зы: вот те материал http://www.opennet.ru/docs/RUS/iptables/

[S10]

Да ваще линукс - говно !!!

Жирно написал человек(?) с красноглазой аватаркой...

[Dut_Norshi]

Собственно, проблема: некоторые сайты загружаются медленно.

Не совпадает с:

1. При открытии страницы загружается заголовок и больше ничего;

2. В таком состоянии страница висит неопределенно долгое время;

 

Может дело в другом?

[S10]

Dut_Norshi

Как раз-таки, совпадает. Заголовок сайта загружен, хром пишет "отправка запроса" и загружает отдельные сайты до минуты.

Сеть близка к той, что в примере, только интерфейсы на шлюзе меняются местами и, соответственно, ICMP от шлюза идет внутрь локальной сети.

На шлюзе загрузка страниц curl'ом довольно шустрая. Из статьи следует, что проблема именно на шлюзе возникает.

[Dut_Norshi]

Интересно, что в статье clamp-mss добавляется в таблицу mangle. Посмотрел у себя на старом маршрутизаторе -- почему-то это правило добавлено в таблицу filter.

Может перенос правила в filter поможет, а может и у меня бесполезно это добавлено? Настраивал сто тыщ лет назад

 

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

[S10]

Dut_Norshi

Добавлял в filter, не помогает. Хотя, пакеты правилом обрабатываются.

Если не ошибаюсь, надо было так:

iptables -t filter -I FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

 

iptables -A FORWARD добавит во все таблицы это правило последним номером. Верно?

[Dut_Norshi]

Dut_Norshi

iptables -A FORWARD добавит во все таблицы это правило последним номером. Верно?

если -t не писать, то по умолчанию операции будут производиться над таблицей filter.

-A добавит в конец цепочки

-I вставит с нужным номером правила

 

Какой-то подземный стук

Может быть тогда вообще попробовать на сетевых интерфейсах установить другой mtu? ifconfig etX mtu xxxx

[suin]

MTU надо руками подправить на сетевой карте потребителя,

то есть того, кто юзает инет через этот ваш горе-роутер.

[S10]

попробовать на сетевых интерфейсах установить другой mtu?

Тоже пробовал, конец немного предсказуем.

[Dut_Norshi]

Надо смотреть...

 

или выкинуть "Endian Firewall Community 2.4.1" и поставить нормальный Debian

[suin]

Debian - реальная сила !

 

Все прочие Линуксы, а Винда тем более - говно !!!!!!

[oldbay]

http://pastebin.com/B1q4reyF

 

как в сказке, чем дальше - тем страшнее...

в iptables-е конечно у вашего маршрутизатора,пардонте, издец какой то творится.....сильно перемудрено.

 

Ну и вывод tcpdump: http://pastebin.com/NJdqxvaU

 

опять не вижу анамальщины .

за те 2 секунды что эти 55 пакетов проскачили .... на каком примерно этапе загрузка была в браузеоре? загрузка не прошла?

 

блин, точно:

Какой-то подземный стук smile.gif

 

В общем, по выводам: мне сильно не нравится те заборы что нагородили в iptables-е вашего маршрутизатора .... глубоко рыть там крайне сложно: висят какие то виртуальные бридж интерфейсы - куча правил как в filter так и в mangle (явно присутсвует "оригинальный" фаерволл, шейпер трафика + еще хрен его знает что ).....еще, слава богу, в nat не заглядывал - там конечно нет форварда, но тоже можно той еще "хрени" начудить

Из выходов вижу такой: взять простую машину - настроить на ней iptables в режиме маршрутизатора по минимуму: разрешить форвардинг и создать правило для маскарада траффика для локальной сети = если действительно имеет место "Path MTU Discovering Black Hole", то ваша проблема снова вылезет:

Заголовок сайта загружен, хром пишет "отправка запроса" и загружает отдельные сайты до минуты.

Сеть близка к той, что в примере, только интерфейсы на шлюзе меняются местами и, соответственно, ICMP от шлюза идет внутрь локальной сети.

На шлюзе загрузка страниц curl'ом довольно шустрая. Из статьи следует, что проблема именно на шлюзе возникает.

но она должна решатся установкой мнинимальной mss в правиле на форвардинге. Тем более это проще отследить на чистой машине чем на сильно замусоренном iptables.

 

Посоветуйте сразу теоретический материал по iptables для самых маленьких. Я пока плохо понимаю прохождение трафика через цепочки и таблицы данного пакетного фильтра.

http://easylinux.ru/node/190/

http://ru.gentoo-wiki.com/wiki/Iptables_%D...%89%D0%B8%D1%85

http://www.opennet.ru/man.shtml?topic=ipta...8&russian=0 - несколько устаревший, но вполне пригоден как справочник

 

по теме Path MTU Discovery Black Hole есть статья на opennet-e: http://www.opennet.ru/base/net/pppoe_mtu.txt.html , как раз по ней когда то делал: обратите внимание что там правило добавлялось в filter(хотя боюсь что вопрос в версии iptables, не исключу того что на свежих версиях только в мангле и работает)

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

но тоже дело было давно, непомню

 

iptables там чистый, какой ещё нахер мангл ?!?

Свинюга - тебе явно не нужно было настраивать на твоем vpn срвере - прохождение пакетов через шейпер типа iproute2 ?

....потому и нет мангла

....или, скорее всего, опять троллишь

[suin]

не мангл, а мангал, на котором жарят свиной шашлык !!!

[Kenyon]

У меня на одной из железок уже года 2 работает такая конструкция для решения аналогичной проблемы.

 

# cat /etc/redhat-release
CentOS release 5.3 (Final)
# iptables -V
iptables v1.3.5

 

 

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

 

tunnel0 - GRE-туннель с MTU 1400

 

Все отлично работает.

[suin]

GRE говённый протокол

[Kenyon]

GRE говённый протокол

 

 

И почему же он плохой?)))

Предложи варианты чем заменить его.

[S10]

Kenyon

По идее, то же правило в mangle должно поменять MSS в SYN-пакетах при прохождении в обе стороны(соответственно, от клиента идет 1460 - шлюз ставит 1360 и пинает пакет дальше; пришел пакет из внешки - поправили опять на 1360 и в локалку кинули). По крайней мере, в локалку пакеты покореженными приходят, как и надо. Попробую завтра с явным указанием интерфейсов..

[suin]

И почему же он плохой?)))

Предложи варианты чем заменить его.

 

У меня один вариант с 2005 года - это OpenVPN.

[Kenyon]

Kenyon

По идее, то же правило в mangle должно поменять MSS в SYN-пакетах при прохождении в обе стороны(соответственно, от клиента идет 1460 - шлюз ставит 1360 и пинает пакет дальше; пришел пакет из внешки - поправили опять на 1360 и в локалку кинули). По крайней мере, в локалку пакеты покореженными приходят, как и надо. Попробую завтра с явным указанием интерфейсов..

 

 

 

Ну я сразу делал с указанием интерфейса. Иные способы даже не пробовал.

У меня на Cisco так:

 

interface Tunnel23
ip address X.X.X.X Y.Y.Y.Y
ip mtu 1400
ip tcp adjust-mss 1360
ip ospf 1 area 0.0.0.0
tunnel source Loopback0
tunnel destination Z.Z.Z.Z
end

 

Поэтому по аналогии сразу к интерфейсу привязывался.

[oldbay]

По идее, то же правило в mangle должно поменять MSS в SYN-пакетах при прохождении в обе стороны(соответственно, от клиента идет 1460 - шлюз ставит 1360 и пинает пакет дальше; пришел пакет из внешки - поправили опять на 1360 и в локалку кинули).

по теории верно, но практика может натыкаться на лес правил в вашем iptables

 

Попробую завтра с явным указанием интерфейсов..

 

скорее всего ничего не даст, так как уже было указано:

TCPMSS tcp -- any any anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS set 1360

с любого интерфейса на любой