S10 Опубликовано 31 июля, 2012 Жалоба Share Опубликовано 31 июля, 2012 Имеется шлюз на 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? Ссылка на комментарий Поделиться на другие сайты More sharing options...
oldbay Опубликовано 31 июля, 2012 Жалоба Share Опубликовано 31 июля, 2012 куда копать? Баг в 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 Ссылка на комментарий Поделиться на другие сайты More sharing options...
S10 Опубликовано 31 июля, 2012 Автор Жалоба Share Опубликовано 31 июля, 2012 посмотрите в /usr/src/ядро/.config EFW - это очень куцый линукс. /usr/src там нет, как и многих утилит... sysctl -a | grep ipv4 http://pastebin.com/8N5PtWii iptables -t mangle -L -v http://pastebin.com/uyQJXJum Ссылка на комментарий Поделиться на другие сайты More sharing options...
oldbay Опубликовано 31 июля, 2012 Жалоба Share Опубликовано 31 июля, 2012 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-шник машины в сети на которой проводится тест> Ссылка на комментарий Поделиться на другие сайты More sharing options...
S10 Опубликовано 1 августа, 2012 Автор Жалоба Share Опубликовано 1 августа, 2012 не фига себе как много всего в mangle ,настройки самого дистрибутива? Угу. Единственное, что я добавлял - правила для исходящего трафика через веб-морду, но они в filter/OUTGOINGFW записываются. iptables -L FORWARD -v http://pastebin.com/B1q4reyF Ну и вывод tcpdump: http://pastebin.com/NJdqxvaU oldbay Посоветуйте сразу теоретический материал по iptables для самых маленьких. Я пока плохо понимаю прохождение трафика через цепочки и таблицы данного пакетного фильтра. Ссылка на комментарий Поделиться на другие сайты More sharing options...
suin Опубликовано 1 августа, 2012 Жалоба Share Опубликовано 1 августа, 2012 Вот вы хернёй страдаете внатуре ! У меня 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/ Ссылка на комментарий Поделиться на другие сайты More sharing options...
S10 Опубликовано 1 августа, 2012 Автор Жалоба Share Опубликовано 1 августа, 2012 Да ваще линукс - говно !!! Жирно написал человек(?) с красноглазой аватаркой... Ссылка на комментарий Поделиться на другие сайты More sharing options...
Dut_Norshi Опубликовано 1 августа, 2012 Жалоба Share Опубликовано 1 августа, 2012 Собственно, проблема: некоторые сайты загружаются медленно. Не совпадает с: 1. При открытии страницы загружается заголовок и больше ничего; 2. В таком состоянии страница висит неопределенно долгое время; Может дело в другом? Ссылка на комментарий Поделиться на другие сайты More sharing options...
S10 Опубликовано 1 августа, 2012 Автор Жалоба Share Опубликовано 1 августа, 2012 Dut_Norshi Как раз-таки, совпадает. Заголовок сайта загружен, хром пишет "отправка запроса" и загружает отдельные сайты до минуты. Сеть близка к той, что в примере, только интерфейсы на шлюзе меняются местами и, соответственно, ICMP от шлюза идет внутрь локальной сети. На шлюзе загрузка страниц curl'ом довольно шустрая. Из статьи следует, что проблема именно на шлюзе возникает. Ссылка на комментарий Поделиться на другие сайты More sharing options...
Dut_Norshi Опубликовано 1 августа, 2012 Жалоба Share Опубликовано 1 августа, 2012 Интересно, что в статье clamp-mss добавляется в таблицу mangle. Посмотрел у себя на старом маршрутизаторе -- почему-то это правило добавлено в таблицу filter. Может перенос правила в filter поможет, а может и у меня бесполезно это добавлено? Настраивал сто тыщ лет назад iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu Ссылка на комментарий Поделиться на другие сайты More sharing options...
S10 Опубликовано 1 августа, 2012 Автор Жалоба Share Опубликовано 1 августа, 2012 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 добавит во все таблицы это правило последним номером. Верно? Ссылка на комментарий Поделиться на другие сайты More sharing options...
Dut_Norshi Опубликовано 1 августа, 2012 Жалоба Share Опубликовано 1 августа, 2012 Dut_Norshi iptables -A FORWARD добавит во все таблицы это правило последним номером. Верно? если -t не писать, то по умолчанию операции будут производиться над таблицей filter. -A добавит в конец цепочки -I вставит с нужным номером правила Какой-то подземный стук Может быть тогда вообще попробовать на сетевых интерфейсах установить другой mtu? ifconfig etX mtu xxxx Ссылка на комментарий Поделиться на другие сайты More sharing options...
suin Опубликовано 1 августа, 2012 Жалоба Share Опубликовано 1 августа, 2012 MTU надо руками подправить на сетевой карте потребителя, то есть того, кто юзает инет через этот ваш горе-роутер. Ссылка на комментарий Поделиться на другие сайты More sharing options...
S10 Опубликовано 1 августа, 2012 Автор Жалоба Share Опубликовано 1 августа, 2012 попробовать на сетевых интерфейсах установить другой mtu? Тоже пробовал, конец немного предсказуем. Ссылка на комментарий Поделиться на другие сайты More sharing options...
Dut_Norshi Опубликовано 1 августа, 2012 Жалоба Share Опубликовано 1 августа, 2012 Надо смотреть... или выкинуть "Endian Firewall Community 2.4.1" и поставить нормальный Debian Ссылка на комментарий Поделиться на другие сайты More sharing options...
suin Опубликовано 1 августа, 2012 Жалоба Share Опубликовано 1 августа, 2012 Debian - реальная сила ! Все прочие Линуксы, а Винда тем более - говно !!!!!! Ссылка на комментарий Поделиться на другие сайты More sharing options...
oldbay Опубликовано 1 августа, 2012 Жалоба Share Опубликовано 1 августа, 2012 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 ? ....потому и нет мангла ....или, скорее всего, опять троллишь Ссылка на комментарий Поделиться на другие сайты More sharing options...
suin Опубликовано 1 августа, 2012 Жалоба Share Опубликовано 1 августа, 2012 не мангл, а мангал, на котором жарят свиной шашлык !!! Ссылка на комментарий Поделиться на другие сайты More sharing options...
Kenyon Опубликовано 2 августа, 2012 Жалоба Share Опубликовано 2 августа, 2012 У меня на одной из железок уже года 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 Все отлично работает. Ссылка на комментарий Поделиться на другие сайты More sharing options...
suin Опубликовано 2 августа, 2012 Жалоба Share Опубликовано 2 августа, 2012 GRE говённый протокол Ссылка на комментарий Поделиться на другие сайты More sharing options...
Kenyon Опубликовано 2 августа, 2012 Жалоба Share Опубликовано 2 августа, 2012 GRE говённый протокол И почему же он плохой?))) Предложи варианты чем заменить его. Ссылка на комментарий Поделиться на другие сайты More sharing options...
S10 Опубликовано 2 августа, 2012 Автор Жалоба Share Опубликовано 2 августа, 2012 Kenyon По идее, то же правило в mangle должно поменять MSS в SYN-пакетах при прохождении в обе стороны(соответственно, от клиента идет 1460 - шлюз ставит 1360 и пинает пакет дальше; пришел пакет из внешки - поправили опять на 1360 и в локалку кинули). По крайней мере, в локалку пакеты покореженными приходят, как и надо. Попробую завтра с явным указанием интерфейсов.. Ссылка на комментарий Поделиться на другие сайты More sharing options...
suin Опубликовано 2 августа, 2012 Жалоба Share Опубликовано 2 августа, 2012 И почему же он плохой?))) Предложи варианты чем заменить его. У меня один вариант с 2005 года - это OpenVPN. Ссылка на комментарий Поделиться на другие сайты More sharing options...
Kenyon Опубликовано 2 августа, 2012 Жалоба Share Опубликовано 2 августа, 2012 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 Поэтому по аналогии сразу к интерфейсу привязывался. Ссылка на комментарий Поделиться на другие сайты More sharing options...
oldbay Опубликовано 2 августа, 2012 Жалоба Share Опубликовано 2 августа, 2012 По идее, то же правило в mangle должно поменять MSS в SYN-пакетах при прохождении в обе стороны(соответственно, от клиента идет 1460 - шлюз ставит 1360 и пинает пакет дальше; пришел пакет из внешки - поправили опять на 1360 и в локалку кинули). по теории верно, но практика может натыкаться на лес правил в вашем iptables Попробую завтра с явным указанием интерфейсов.. скорее всего ничего не даст, так как уже было указано: TCPMSS tcp -- any any anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS set 1360 с любого интерфейса на любой Ссылка на комментарий Поделиться на другие сайты More sharing options...
Рекомендуемые сообщения
Заархивировано
Эта тема находится в архиве и закрыта для дальнейших ответов.