Jump to content
Калькуляторы

Бордер на Linux Кто-то флудит :(

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

может оно и не по 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 сек. на современных каналах дефолтные таймауты не актульны.

 

 

Edited by desperado

Share this post


Link to post
Share on other sites

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

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.

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

ЗЫ

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

Edited by desperado

Share this post


Link to post
Share on other sites
# 1. ни на что не влияет кроме размера таблицы conntrack. можно ставить смело.

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

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

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

 

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites
Вопрос №2: насколько сильно NOTRACK уменьшит загрузку процессора?

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

 

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

 

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

 

 

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 30

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

 

Share this post


Link to post
Share on other sites
Я правильно понимаю, что при этом у абонентов tcp-сессии рвутся каждые 30 секунд?
с этим параметром при желании можно поиграться. но откровенно говоря - на практике вполне живучий параметр. достаточно просто разобрать что к чему.

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

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

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

 

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

 

natin_day.png

Share this post


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

Share this post


Link to post
Share on other sites

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

Share this post


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

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

 

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

 

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

 

Где я не прав?

Edited by Алексей Андриянов

Share this post


Link to post
Share on other sites
основная масса трафика у вас что?

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

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

Share this post


Link to post
Share on other sites

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

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

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

Edited by darkagent

Share this post


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

нужен ли вам 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 отваливаются только в путь... :(

 

 

Edited by AlKov

Share this post


Link to post
Share on other sites

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

 

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

 

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this