[Dyr]

Не могу не отметить, что ваше "непоказывание" цифр трафика на графиках и неопубликование правил файервола (в которых вроде как и оказалась проблема) является глубоко бессмысленным и даже глупым поведением.

[nuclearcat]

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

[Dyr]

 

 

Да конечно, "нашёл":

 

Похоже "главного врага" я так и не нашел.. После оптимизации снова получил "выброс" исходящего трафа и соотв. загрузку CPU.

 

Тот самый случай, когда "security via obscurity" только мешает.

 

 

[AlKov]

Если заоптимизировали проц, уже не надо.

По поводу мониторинга аплинка, можно написать по идее минимальную программку, которая будет поллить интерфейс, и когда загрузка превысит номинальную - дампить хотя бы хеадеры траффика. Как доеду на работу - попробую сделать, но не обещаю.

Буду весьма признателен! И заодно сразу поблагодарю за помощь в решении существенной части проблемы!

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

Просто мне элементарно стыдно за тот бардак, который я там развел за 6 лет постоянного "дописывания" новых правил, без удаления ненужных.. :)

Сначала "причешу" все. После этого, возможно и потребуется помощь коллег.

По поводу скрывания трафика - ну есть небольшая паранойя, сохранившаяся с времен "далекой юности". :) По большому счету, это все равно не имеет отношения к обсуждаемому. Да и тот, кому надо, поймет это без "картинок". ;)

 

P.S. Кстати, один вопрос по оптимизации iptables уже готов задать сейчас - имеет ли значение "расположение" в цепочке (номер) вот такого правила:

iptables -A FORWARD -p ALL -m state --state ESTABLISHED,RELATED -j ACCEPT

Сейчас я перенес его в самый "верх" - сразу после "iptables -A FORWARD -j NETFLOW", которое стоИт первым. В принципе, нетфлоу скорее всего уберу совсем, т.к. собираю его на NAS-ах. Здесь добавил временно только для локализации проблемы.

Изменено 5 марта, 2012 пользователем AlKov

[nuclearcat]

Все зависит от остальных правил. Любые правила которые разрешают побольше траффика (чтоб не бежало дальше по цепочке) - хорошо.

[Ilya Evseev]

iptables -A FORWARD -p ALL -m state --state ESTABLISHED,RELATED -j ACCEPT

Любые правила которые разрешают побольше траффика (чтоб не бежало дальше по цепочке) - хорошо.

1) "-m state" уязвим для synflood?

2) что происходит быстрее - поиск в hashtree для stateful-соединений,

или разрешение используемых сервисов через tcp/udp multiport без проверки new/established/related?

[nuclearcat]

Для synflood вообще все сложно. Одно - если он направлен на эту машину, другое, если нет

Боюсь если он к вам приедет на машину с conntrack - она сложится очень быстро, могу подсказать, как симулировать synflood и проверить. Дело в том, что conntrack по умолчанию подхватывает незнакомые соединения. Чтобы незнакомые стейты отшибались, поставьте /proc/sys/net/netfilter/nf_conntrack_tcp_loose в 0, теоретически это заменит вышеуказанное правило.

 

Скриптик который скажем сдампит траффик посмотрите на http://www.nuclearcat.com/hog_solve.sh

[AlKov]

Скриптик который скажем сдампит траффик посмотрите на http://www.nuclearcat.com/hog_solve.sh

Спасибо! "Пристроил" его в свой скриптик, который по snmp раз в минуту снимает счетчик ifHCOutOctets с порта аплинка.

При out > 200М запускается ваш скрипт. Ну и при окончании проблемы, киляю процесс вашего скрипта.

Жду результат..