Ubuntu Server +Iptables +squid +htb разрывается коннект у клиентов.

[Mielofon]

Добрый день.

Я совсем недавно решился перевести раздачу интернета на Linux сервер.

Поставил настроил:

Код: [Выделить]

# cat /etc/issue
Ubuntu 10.10 \n \l
# uname -a
Linux router.office.sprut.ru 2.6.35-28-server #49-Ubuntu SMP Tue Mar 1 14:55:37 UTC 2011 x86_64 GNU/Linux
# cat /proc/version
Linux version 2.6.35-28-server (buildd@allspice) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) ) #49-Ubuntu SMP Tue Mar 1 14:55:37 UTC 2011

Машин у меня в локалке 30. ADSL 7MBit/1MBit

настроил Squid, transparent HTTP-proxy, часть пользователей пустил через NAT (MASQUERADE). Скриптами htb-gen и htb-init сделал шейпер, что бы дать больше воздуху тем кому нужнее.

И всё даже работает. Вроде. Но часто наступают такие моменты что связь не держится нифига. Т.е. у всей сетки хором (может конечно и не совсем синхронно, но то что у всех точно) падает связь. ICQ, Jabber, Skype начинают пересоединятся. Они конечно пересоединяются и когда это пару раз за день, то и не заметят. Но когда начинается болтанка как например сегодня, то пользователи жить не дают, потому что у них морская болезнь уже от того что ICQ/Jabber/Skype туда сюда юолтаются :-(

Ну вот теперь вот вопрос должен быть: как добится что бы не было разрывов, но я хоть и новичок в Linux, но понимаю, что информации дал 0 для размышления. И главная то моя проблема - я не знаю что давать :-) Настройки squid.conf, /etc/iptables.up.rules, tc qdisc show кинуть можно, но букв там много а вникать подробно вряд ли кто будет.

Подскажите мне просто что делать и как искать узкое место или ошибку. Ну вот идут разрывы (хотя после обеда успокоилось, возможно net.netfilter.nf_conntrack_tcp_loose = 0 помогло). Куда смотреть и кого подозревать?

Например:

Код: [Выделить]

# conntrack -C
1536
# conntrack -S
entries                 1497
searched                12948168
found                   128924159
new                     8298250
invalid                 389864
ignore                  11816430
delete                  5978031
delete_list             5399467
insert                  7720032
insert_failed           14
drop                    0
early_drop              0
icmp_error              125119
expect_new              0
expect_create           0
expect_delete           0
search_restart          0

Если это плохо, то что плохо? 1536 это много? До обеда было около 3000 (munin всё записал). Это много? И если много то как сделать что бы было меньше или что бы при такой цифре работало бы. Да банально: conntrack -L выдаёт портянку, а мне бы сгруппировать по локальным адресам - что бы было видно от кого много соединений прёт. Есть какой нибудь инструмент который позволит это сделать?

[podkovyrsty]

-j LOG в iptables на пакеты установки соединения, и парсить потом это дело.
Либо конфигурируйте мунин для более детальной информации.
Либо возьмите fprobe и какой-нить анализатор netflow.

[AnrDaemon]

А вам не приходит в голову, что DSL линия может сбоить?

[podkovyrsty]

Может статься, что канал в ту сторону забивается.
Или, как вариант, DSL-шлюз флашит сессии при достижении лимита некоторого.

[Mielofon]

-j LOG в iptables на пакеты установки соединения, и парсить потом это дело.
Либо конфигурируйте мунин для более детальной информации.
Либо возьмите fprobe и какой-нить анализатор netflow.

В логах Iptables не уверен, что что то увижу. Это ж всё равно что снифером смотреть. Ну был разрыв - а кто виноват то?

Насчет fprobe и netflow новые для меня слова - пошел искать.
Пользователь решил продолжить мысль 03 Мая 2011, 16:08:21:

А вам не приходит в голову, что DSL линия может сбоить?

Ну я согласен, что линия может сбоить. Как бы мне в этом убедится то?

Пользователь решил продолжить мысль 03 Мая 2011, 16:10:42:

Может статься, что канал в ту сторону забивается.
Или, как вариант, DSL-шлюз флашит сессии при достижении лимита некоторого.

Канал не забивается. Во всяком случае по munin когда разрывы происходят канал забит не под завязку - вполне свободный.
Когда рвёт - то рвёт не новые соединения, а все. Так что если насчет лимита, то при упоре в него обрыв глобальный. Странно это.

[censor]

линк к провайдеру поднимается на мопеде или шлюзом pppoe соединение стартует?

[AnrDaemon]

fprobe позволит посчитать пакеты, но не увидеть, что вообще творится.

[Zhmak]

trafshow позволяет за потоками следить. одно время крутился на работе для отлова качков.

Если модем роутером настроен, то стоит попробовать переключить его в бридж и поднять соединение на сервере.
Пользователь решил продолжить мысль 03 Мая 2011, 23:29:40:Кстати, nfsen в сочетании с fprobe наглядно показывает активность сети на протяжении времени.

[Mielofon]

линк к провайдеру поднимается на мопеде или шлюзом pppoe соединение стартует?

На роутере. Но не PPPoE. У нас  MAC Encapsulation Routing (MER). Т.е. на роутере выставлен внешний IP.

В выходные если удастся попробую перевести на Bridge, а IP выставлять уже на Linux-е.

[Mielofon]

линк к провайдеру поднимается на мопеде или шлюзом pppoe соединение стартует?

Неделя как модем в режиме бриджа и можно считать "полёт нормальный".   Спасибо за совет. Да и проще стало с прокидыванием портов.
Таких катастрофических вылетов, что бы раз в пять минут и нельзя нормально по Skype поговорить и файл залить на ftp, уже нет.
Было пару раз, но выглядят иначе - пересоединяется дольше. Но это пару раз было, так что пока можно считать, что показалось.

Меня теперь другой немного беспокоит вопрос:


вот это вот Established растёт постоянно и неуклонно.
Заметил когда 12го перезагрузил комп и оно началось с нуля.

Если бы оно колебалось равномерно я бы понял. Если бы после перезагрузки через некоторое время вернулось к прежнему значению я бы понял. А так выходит накапливается мусор, который перезагрузкой сбросился.

Что это может быть и как бы их сбросить без перезагрузки?

[podkovyrsty]

Зомби сессии это (:
У вас торрент какой-то на раздачах?

[Mielofon]

Зомби сессии это (:
У вас торрент какой-то на раздачах?

Да. Есть.
А как обрубать их? Они же точно бесполезные?

[podkovyrsty]

А зачем? (:
Для обрубания вам надо сбросить состояние демона обслущивающего стек на клиентской стороне.
Тобишь подключение перезапустить.