nuclearcat Опубликовано 9 сентября, 2008 · Жалоба У меня не загнулся ни разу, хотя вешал на хосты где нагрузка уже была на пределе Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 24 января, 2009 · Жалоба Вопрос по теме. А вобще contrack много ресурсов кушает? Есть ли смысл вобще его не использовать например для транзитного трафика (на определеныне сети)? Ната нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 24 января, 2009 · Жалоба Наличие conntrack значительно влияет при высоких Kpps. Он достаточно сильно тормозит... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
desperado Опубликовано 14 октября, 2009 (изменено) · Жалоба сорри что старую тему поднимаю, но может кому пригодится. случайно наткнулся. может оно и не по RFC, но кроме прочего один из вариантов # 1. ни на что не влияет кроме размера таблицы conntrack. можно ставить смело. echo "14400" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established # 2. почти ни на что не влияет, но таблица за час как новая. можно юзать если хочется сэкономить ресурсы на conntrack малой кровью. echo "3600" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established # 3. брутальный вариант. большая часть сервисов работает, таблицу засрать очень сложно. можно юзать на время поимки флудера если зятянулось. echo "300" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established соответственно или прописать в sysctl.conf или выполнять при каждой загрузке. ну и сессии сбросить если неохота ждать 5 дней. не панацея, но помогает заметно. если у вас не жопорез, то остальные таймауты тоже можно порезать в 4-8 раз, но не меньше 10 сек. на современных каналах дефолтные таймауты не актульны. Изменено 14 октября, 2009 пользователем desperado Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
КузярБ Опубликовано 15 октября, 2009 · Жалоба Это все мертвому припарки, какой производительности можно ожидать, когда (см.выше) net.netfilter.nf_conntrack_count = 1529805net.netfilter.nf_conntrack_buckets = 16384 Читаем тут http://www.wallfire.org/misc/netfilter_conntrack_perf.txtTo access a conntrack entry corresponding to a packet, the kernel has to:... - iterate over the linked list of conntrack entries to find the good one. This is a more costly operation, depending on the size of the list (and on the position of the wanted conntrack entry in the list). ... When the limit is reached (the total number of conntrack entries being stored has reached CONNTRACK_MAX), each list will contain ideally (in the optimal case) about CONNTRACK_MAX/HASHSIZE entries. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
desperado Опубликовано 15 октября, 2009 (изменено) · Жалоба я просто к тому, что даже если никто не флудит, в таблице обычно 99% записей уже никому нафиг не нужны и только ресурсы жрут, а какой-то кретин решил что их надо там 5 дней держать. conntrack_max в данном случае явно какое-то нездоровое. при tcp_timeout_established=14400 кило активных юзеров отъедают от силы несколько десятков кило сессий, т.е. дефолтных 65536 хватает с запасом. ну пусть даже будет 100кило сессий на 1 кило юзеров. тогда получается, что там более 15 кило юзеров и если это кабельный интернет, то одной машины банально по полосе не хватит. можно к стати количество сессий на юзера ограничить порядка 1-10кило. это обычно снимает проблему в принципе. но это еще ресурсы. но никогда не сталкивался с ситуацией чтоб конекшен трекер был узким местом. обычно pps или bps ЗЫ я такие вещи предпочитаю по mrtg смотреть. Изменено 15 октября, 2009 пользователем desperado Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
КузярБ Опубликовано 17 октября, 2009 · Жалоба # 1. ни на что не влияет кроме размера таблицы conntrack. можно ставить смело.echo "14400" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established Попробовал этот вариант - похоже работает. Но на этом подопытном компе собирается за 4 часапо 600к записей, так что надо копать дальше - вставлять NOTRACK где можно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 7 января, 2010 · Жалоба Тоже планирую использовать на NAT-шлюзе NOTRACK для клиентов с публичными IP, но перед этим хочу посоветоваться :) track() { iptables -t raw -A PREROUTING -s $1 -j ACCEPT iptables -t raw -A PREROUTING -d $1 -j ACCEPT } track 10.0.0.0/8 track 172.16.0.0/12 track 192.168.0.0/16 ip addr list | grep ' inet ' | while read xx ip yy; do track $ip; done iptables -t raw -A PREROUTING -j NOTRACK Кроме линейного списка, который надо заменить на ipset, есть ли в такой схеме ошибки и недостатки? Вопрос №2: насколько сильно NOTRACK уменьшит загрузку процессора? iptstate говорит, что всего в conntrack сейчас 16k записей, из них около половины принадлежат публичникам. Шлюз пропускает через себя примерно 300mbps и 50kpps в каждую сторону, два ядра загружены по 35%. net.ipv4.netfilter.ip_conntrack_count = 139902, net.ipv4.netfilter.ip_conntrack_max = 1048576, /sys/module/nf_conntrack/parameters/hashsize = 1048576. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 8 января, 2010 · Жалоба попробуйте со следующими параметрами прокатиться: net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_keepalive_time = 60 net.ipv4.tcp_keepalive_intvl = 10 net.ipv4.tcp_keepalive_probes = 5 net.ipv4.tcp_fin_timeout = 30 net.ipv4.tcp_window_scaling = 0 net.ipv4.tcp_sack = 0 net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 30 net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 30 net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 120 net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 30 net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 60 net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 30 net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 30 net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 30 какие то в итоге можно будет и подрегулировать по необходимости. при таком раскладе без notrack'а и с большим запасом памяти (>2Gb) нат прекрасно переваривает потоки под гигабит (правда на четырехядерном xeon'е, на двухядерке попробовать нет возможности). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Алексей Андриянов Опубликовано 8 января, 2010 · Жалоба Вопрос №2: насколько сильно NOTRACK уменьшит загрузку процессора? У меня на 100Мбитах трафика использование NOTRACK (под который подпадало около 20), не дало сколько-нибудь заметного снижения загрузки CPU, зато ipset-nethash, которым я классифицировал такой трафик в raw-таблице, кушал около 6% по данным утилиты perf. Так что я отказался от использования NOTRACK. попробуйте со следующими параметрами прокатиться: net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 30 Я правильно понимаю, что при этом у абонентов tcp-сессии рвутся каждые 30 секунд? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 8 января, 2010 · Жалоба Я правильно понимаю, что при этом у абонентов tcp-сессии рвутся каждые 30 секунд?с этим параметром при желании можно поиграться. но откровенно говоря - на практике вполне живучий параметр. достаточно просто разобрать что к чему. основная масса трафика у вас что? если торрент и прочий файлообмен, потоковое видео (йотуб например), сетевые игры - все прекрасно успевает пролететь в этот интервал (если только у вас трасса не через 25 хопов с задержкой по 100мс между каждым узлом). с другой стороны - именно торренты при увеличении значения этого параметра дают приличную нагрузку (точнее кол-во "отслеживаемых" соединений растет в геометрической прогрессии). а если уж ddos атака... цифры в приведенном мной примере - используются в продакшне. даже скрин мртг в атаче прикладываю ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 8 января, 2010 · Жалоба Алексей Андриянов, нет. В случае отсутствия активности более 30 секунд, запись о соединении будет просто удалена из таблицы conntrack. Сама TCP-сессия не разорвется. Если активность возобновится - запись вернется. Единственная проблема в том, что при таком раскладе поломается работа stateful firewall (-m state) - некоторые пакеты в уже установленной сессии могут быть помечены как NEW, хотя таковыми не являются. Впрочем, если вы не обрабатываете в правилах conntrack states, то ничего страшного. Правда 30 секунд это совсем уж мало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 8 января, 2010 · Жалоба Да, конечно еще NAT при таком раскладе будет ломаться, если неактивность заначенной сессии > 30 секунд. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Алексей Андриянов Опубликовано 8 января, 2010 (изменено) · Жалоба Алексей Андриянов, нет. В случае отсутствия активности более 30 секунд, запись о соединении будет просто удалена из таблицы conntrack. Сама TCP-сессия не разорвется. Если активность возобновится - запись вернется. Что-то я сомневаюсь, что запись вернется. Если первым после удаления записи пришел пакет от outside-хоста, откуда conntrack узнает, на какой inside-хост:порт его отправить? Если же первым пришел пакет от inside-хоста, откуда conntrack узнает, с какого outside-local порта его отправить? То есть, вместо старой записи, конечно, возникнет новая, но номер порта сменится, а значит, соединение разорвется. Да и darkagent это подтверждает, но говорит, что это не страшно и все "успевает пролезть". Где я не прав? Изменено 8 января, 2010 пользователем Алексей Андриянов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Алексей Андриянов Опубликовано 8 января, 2010 · Жалоба основная масса трафика у вас что? если торрент и прочий файлообмен, потоковое видео (йотуб например), сетевые игры - все прекрасно успевает пролететь в этот интервал (если только у вас трасса не через 25 хопов с задержкой по 100мс между каждым узлом). Здесь вообще не согласен. Задержка при прохождении пакета не имеет ничего общего с временем жизни сессии, т.к. сессия состоит не из одного пакета, и может длиться очень долго (telnet, ssh, rdp, например). Да и закачка больших файлов с http-серверов, не поддерживающих докачку, может длиться часами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 8 января, 2010 (изменено) · Жалоба а вы сперва попробуйте. дор-блю тоже выглядит неаппетитно, однако это деликатес (и очень даже вкусный). нужен ли вам connection tracking если вы никаких доп.преобразований трафика не проводите? жить все будет прекрасно, только система не будет так долго "помнить" об этих соединениях. как я уже сказал - решение используется вживую (би-нат, для home-ix/svao-ix пирингов). Изменено 8 января, 2010 пользователем darkagent Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 15 мая, 2010 (изменено) · Жалоба а вы сперва попробуйте. дор-блю тоже выглядит неаппетитно, однако это деликатес (и очень даже вкусный).нужен ли вам connection tracking если вы никаких доп.преобразований трафика не проводите? жить все будет прекрасно, только система не будет так долго "помнить" об этих соединениях. как я уже сказал - решение используется вживую (би-нат, для home-ix/svao-ix пирингов). А не расскажете, на каком железе (мать/проц/сетевые) и ОС это решение крутится?В данный момент озадачен подбором решения под очень схожую задачу, и так как явно "не велосипед", хотелось бы поучиться на чужих достижениях/ошибках. ;) P.S. попробуйте со следующими параметрами прокатиться: net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_keepalive_time = 60 net.ipv4.tcp_keepalive_intvl = 10 net.ipv4.tcp_keepalive_probes = 5 net.ipv4.tcp_fin_timeout = 30 net.ipv4.tcp_window_scaling = 0 net.ipv4.tcp_sack = 0 net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 30 net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 30 net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 120 net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 30 net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 60 net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 30 net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 30 net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 30 Попробовал, прокатился... Увы, ssh и icq отваливаются только в путь... :( Изменено 19 мая, 2010 пользователем AlKov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
matwey Опубликовано 23 ноября, 2012 · Жалоба Я ищу своих флудильщиков с помощью такого скрипта - поиск флудильщиков и зомбимашин Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Prihod Опубликовано 29 сентября, 2016 · Жалоба Я ищу своих флудильщиков с помощью такого скрипта - поиск флудильщиков и зомбимашин А потом что с ними делаете? У себя при анализе таблицы нашел более 300 тыс. строк ESTABLISHED, но UNREPLIED с одного ip. Поставил ему limit -A FORWARD -s 192.168.0.190/32 -p tcp --syn -m multiport ! --port 80, 443 -m connlimit --connlimit-above 200 -j DROP и очистил табличку: conntrack -D | grep ESTABLISHED | grep UNREPLIED На какое время решило проблему, потом опять начало забивать таблицу Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myth Опубликовано 29 сентября, 2016 · Жалоба А потом что с ними делаете? Мы - отключаем. Просто выкидывает с 691 ошибкой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...