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

ipfw limit ограничим юзера

Столкнулся тут с проблемкой:

Периодически, раз в пять минут загрузка swi1:net подскакивала за 90%, сервер начинал пинговаться по 200мс.

Freebsd6.4, mpd4.4, ng_nat, ng_car, em без поллинга.

 

Расследование выявило, что от одного из юзеров в этот момент приходило по 10-20тысяч udp пакетов.

Юзер заявил, что у него свежепоставленная винда, kis2010 и bitcomet включен был.

 

ну и ng_nat весь процессор видимо на себя и перетягивал ;)

 

Пока поставил лично на этого юзера вот такую конструкцию

allow udp from 192.168.123.123 to any via ng* limit src-addr 50

 

Подумываю о подобной вещи для всей сети 192.168.0.0/16 ;)

У кого-нить подобные лимиты стоят уже в боевом режиме ? и какие именно цифирки ограничений ? ;)

Edited by LuckySB

Share this post


Link to post
Share on other sites

Данное правило вас вообще не спасёт от такого флуда, поскольку у всех этих udp-пакетов будут одни и те же src-addr, в данном примере - '192.168.123.123', меняйте на src-port.

 

P.S. Таких ограничений у нас нет, хотя, пожалуй, можно было бы.

Share this post


Link to post
Share on other sites

где-то проскакивало в рассылке от разработчиков ipfw что в коде подправить, чтоб pps можно было ограничить.

 

не представляю, правда, сколько подобное ресурсов сожрёт....

 

сейчас на pf стоит ограничение сессий до 300 кажется по портам кроме 80, 21...

Edited by kapa

Share this post


Link to post
Share on other sites
Данное правило вас вообще не спасёт от такого флуда, поскольку у всех этих udp-пакетов будут одни и те же src-addr, в данном примере - '192.168.123.123', меняйте на src-port.
Гм. вообще-то спасает.

Вот только что отключил его и сразу начались проблемы. как токо 123 клиент выдает 10000 udp, swi1:net уходит в 96%, выжирая одно ядро полностью.

как токо правило добавляешь - сразу все опять хорошо )))

 

Мне, если вы не поняли, надо ограничить количество udp пакетов с каждого адреса.

а src-port тут воообще не причем.

 

где-то проскакивало в рассылке от разработчиков ipfw что в коде подправить, чтоб pps можно было ограничить.
угу. в 2004 году проскакивало. Почему то не закоммитили )

Вставлять в боевой рутер экспериментальные фичи я не хочу.

Share this post


Link to post
Share on other sites
Данное правило вас вообще не спасёт от такого флуда, поскольку у всех этих udp-пакетов будут одни и те же src-addr, в данном примере - '192.168.123.123', меняйте на src-port.
Гм. вообще-то спасает.

Вот только что отключил его и сразу начались проблемы. как токо 123 клиент выдает 10000 udp, swi1:net уходит в 96%, выжирая одно ядро полностью.

как токо правило добавляешь - сразу все опять хорошо )))

 

Мне, если вы не поняли, надо ограничить количество udp пакетов с каждого адреса.

а src-port тут воообще не причем.

А почему не использовать dummynet?! количество слотов в пайпе как раз и ограничивают pps. У нас например все клиенты загоняются в персональные пайпы и проблем с таким флудом нет.

Share this post


Link to post
Share on other sites
А почему не использовать dummynet?! количество слотов в пайпе как раз и ограничивают pps. У нас например все клиенты загоняются в персональные пайпы и проблем с таким флудом нет.
у нас в пайпы запихиваются таблицы абонентов, но, по идее, это не должно менять суть...

не поделитесь своими значениями pps для разных скоростей?

Share this post


Link to post
Share on other sites
А почему не использовать dummynet?! количество слотов в пайпе как раз и ограничивают pps. У нас например все клиенты загоняются в персональные пайпы и проблем с таким флудом нет.
у нас в пайпы запихиваются таблицы абонентов, но, по идее, это не должно менять суть...

не поделитесь своими значениями pps для разных скоростей?

 

bw 128Kbit/s queue 16

bw 256Kbit/s queue 32

bw 512Kbit/s queue 50

bw 1024Kbit/s queue 100

bw 2048Kbit/s queue 100

и тд queue 100. Проблем и жалоб не замечали. Eсли у вас много "заразных" абонентов, то можно попробовать уменьшить кол-во слотов, иначе вместо swi1:net в 100ню будет уходить dummynet (хотя все зависит от вашей конфигурации, ipfw в частности).

 

Share this post


Link to post
Share on other sites

bw 2048Kbit/s queue 100

Если queue 100 - это 100 pps, то в данной конфигурации максимальная скорость 100*1500*8= 1200 кбит

Share this post


Link to post
Share on other sites
Если queue 100 - это 100 pps, то в данной конфигурации максимальная скорость 100*1500*8= 1200 кбит

queue 100 это очередь на 100 пакетов. Если pipe не успевает пропихнуть пакеты быстрее, чем они приходят после наполнения очереди пакеты дропаются. Например на скорости мегабит и пакете 100 байтов, получаем примерно 1000 ппс которые пропустит пайп, все остальное после наполнения очереди в /dev/null. Пакеты из очереди берутся с частотой kern.hz (по умолчанию 1000), если клиент резко стартанул, например 200 пакетов за 1 мс припустой очереди, первый пакет проскочит через трубу - он вписывается в скорость - 1 мбит это 100 байт за мс, со 2 по 102 лягут в очередь, с 103 по 200 будут дропнуты. При этом каждую милисекунду из очереди будет забраться 1 пакет. Не забываем про то, что трафик теоретический 100байтными паетами и очередь может быть не только wfq а еще и red и gred, вообщем в реальной жизни оно позабористее, но труба все считает в байтах, поэтому ппс зависит от размера пакета и я не знаю как регулировать именно ппс на фре. Гуру, поправьте, если я не прав.

Share this post


Link to post
Share on other sites
Гм. вообще-то спасает.
М-м-м, да, виноват, был неправ.
limit {src-addr | src-port | dst-addr | dst-port} N

The firewall will only allow N connections with the same set of

parameters as specified in the rule. One or more of source and

destination addresses and ports can be specified. Currently,

only IPv4 flows are supported.

 

Share this post


Link to post
Share on other sites
Пакеты из очереди берутся с частотой kern.hz (по умолчанию 1000), если клиент резко стартанул, например 200 пакетов за 1 мс припустой очереди,
Уже загрузка от клиента колоссальная получается ;)

200 тысяч пакетов в секунду...

В моем случае клиент выдавал udp по 133 байта пачками по 10000 штук за 3-5 секунд, а скорость у него 3мегабита.

Чтобы ограничить клиента хотя бы в 1000pps надо ставить queue 30 ;( что приводит ко всяким лагам и скачкам скорости...

 

В моем случае я ограничил его на отправку 50 udp в течении 10 секунд.

Неужели никто не сталкивался с подобными проблемами ?

Share this post


Link to post
Share on other sites
Неужели никто не сталкивался с подобными проблемами ?
сталкивались.

копайте дальше, эксперементируйте, да разберётесь.

Edited by Giga-Byte

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