[nuclearcat]

У меня не загнулся ни разу, хотя вешал на хосты где нагрузка уже была на пределе

 

[SokolovS]

Вопрос по теме. А вобще contrack много ресурсов кушает? Есть ли смысл вобще его не использовать например для транзитного трафика (на определеныне сети)? Ната нет.

[nuclearcat]

Наличие conntrack значительно влияет при высоких Kpps. Он достаточно сильно тормозит...

[desperado]

сорри что старую тему поднимаю, но может кому пригодится. случайно наткнулся.

 

может оно и не по 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

[КузярБ]

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

net.netfilter.nf_conntrack_count = 1529805

net.netfilter.nf_conntrack_buckets = 16384

Читаем тут http://www.wallfire.org/misc/netfilter_conntrack_perf.txt

To 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.

[desperado]

я просто к тому, что даже если никто не флудит, в таблице обычно 99% записей уже никому нафиг не нужны и только ресурсы жрут, а какой-то кретин решил что их надо там 5 дней держать.

 

conntrack_max в данном случае явно какое-то нездоровое. при tcp_timeout_established=14400 кило активных юзеров отъедают от силы несколько десятков кило сессий, т.е. дефолтных 65536 хватает с запасом. ну пусть даже будет 100кило сессий на 1 кило юзеров. тогда получается, что там более 15 кило юзеров и если это кабельный интернет, то одной машины банально по полосе не хватит.

 

можно к стати количество сессий на юзера ограничить порядка 1-10кило. это обычно снимает проблему в принципе. но это еще ресурсы. но никогда не сталкивался с ситуацией чтоб конекшен трекер был узким местом. обычно pps или bps

 

ЗЫ

я такие вещи предпочитаю по mrtg смотреть.

Изменено 15 октября, 2009 пользователем desperado

[КузярБ]

# 1. ни на что не влияет кроме размера таблицы conntrack. можно ставить смело.

echo "14400" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established

Попробовал этот вариант - похоже работает. Но на этом подопытном компе собирается за 4 часа

по 600к записей, так что надо копать дальше - вставлять NOTRACK где можно.

 

[Ilya Evseev]

Тоже планирую использовать на 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.

 

[darkagent]

попробуйте со следующими параметрами прокатиться:

 

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'е, на двухядерке попробовать нет возможности).

[Алексей Андриянов]

Вопрос №2: насколько сильно NOTRACK уменьшит загрузку процессора?

У меня на 100Мбитах трафика использование NOTRACK (под который подпадало около 20), не дало сколько-нибудь заметного снижения загрузки CPU, зато ipset-nethash, которым я классифицировал такой трафик в raw-таблице, кушал около 6% по данным утилиты perf.

 

Так что я отказался от использования NOTRACK.

 

попробуйте со следующими параметрами прокатиться:

 

 

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 30

Я правильно понимаю, что при этом у абонентов tcp-сессии рвутся каждые 30 секунд?

 

[darkagent]

Я правильно понимаю, что при этом у абонентов tcp-сессии рвутся каждые 30 секунд?

с этим параметром при желании можно поиграться. но откровенно говоря - на практике вполне живучий параметр. достаточно просто разобрать что к чему.

основная масса трафика у вас что?

если торрент и прочий файлообмен, потоковое видео (йотуб например), сетевые игры - все прекрасно успевает пролететь в этот интервал (если только у вас трасса не через 25 хопов с задержкой по 100мс между каждым узлом).

с другой стороны - именно торренты при увеличении значения этого параметра дают приличную нагрузку (точнее кол-во "отслеживаемых" соединений растет в геометрической прогрессии). а если уж ddos атака...

 

цифры в приведенном мной примере - используются в продакшне. даже скрин мртг в атаче прикладываю ;)

 

[Умник]

Алексей Андриянов, нет. В случае отсутствия активности более 30 секунд, запись о соединении будет просто удалена из таблицы conntrack. Сама TCP-сессия не разорвется. Если активность возобновится - запись вернется. Единственная проблема в том, что при таком раскладе поломается работа stateful firewall (-m state) - некоторые пакеты в уже установленной сессии могут быть помечены как NEW, хотя таковыми не являются. Впрочем, если вы не обрабатываете в правилах conntrack states, то ничего страшного. Правда 30 секунд это совсем уж мало.

[Умник]

Да, конечно еще NAT при таком раскладе будет ломаться, если неактивность заначенной сессии > 30 секунд.

[Алексей Андриянов]

Алексей Андриянов, нет. В случае отсутствия активности более 30 секунд, запись о соединении будет просто удалена из таблицы conntrack. Сама TCP-сессия не разорвется. Если активность возобновится - запись вернется.

Что-то я сомневаюсь, что запись вернется. Если первым после удаления записи пришел пакет от outside-хоста, откуда conntrack узнает, на какой inside-хост:порт его отправить?

 

Если же первым пришел пакет от inside-хоста, откуда conntrack узнает, с какого outside-local порта его отправить?

 

То есть, вместо старой записи, конечно, возникнет новая, но номер порта сменится, а значит, соединение разорвется. Да и darkagent это подтверждает, но говорит, что это не страшно и все "успевает пролезть".

 

Где я не прав?

Изменено 8 января, 2010 пользователем Алексей Андриянов

[Алексей Андриянов]

основная масса трафика у вас что?

если торрент и прочий файлообмен, потоковое видео (йотуб например), сетевые игры - все прекрасно успевает пролететь в этот интервал (если только у вас трасса не через 25 хопов с задержкой по 100мс между каждым узлом).

Здесь вообще не согласен. Задержка при прохождении пакета не имеет ничего общего с временем жизни сессии, т.к. сессия состоит не из одного пакета, и может длиться очень долго (telnet, ssh, rdp, например). Да и закачка больших файлов с http-серверов, не поддерживающих докачку, может длиться часами.

[darkagent]

а вы сперва попробуйте. дор-блю тоже выглядит неаппетитно, однако это деликатес (и очень даже вкусный).

нужен ли вам connection tracking если вы никаких доп.преобразований трафика не проводите? жить все будет прекрасно, только система не будет так долго "помнить" об этих соединениях.

как я уже сказал - решение используется вживую (би-нат, для home-ix/svao-ix пирингов).

Изменено 8 января, 2010 пользователем darkagent

[AlKov]

а вы сперва попробуйте. дор-блю тоже выглядит неаппетитно, однако это деликатес (и очень даже вкусный).

нужен ли вам 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

[matwey]

Я ищу своих флудильщиков с помощью такого скрипта - поиск флудильщиков и зомбимашин

[Prihod]

Я ищу своих флудильщиков с помощью такого скрипта - поиск флудильщиков и зомбимашин

 

А потом что с ними делаете?

 

У себя при анализе таблицы нашел более 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

На какое время решило проблему, потом опять начало забивать таблицу

[myth]

А потом что с ними делаете?

 

Мы - отключаем. Просто выкидывает с 691 ошибкой.