Перейти к содержимому
Калькуляторы

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 ;)

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

Изменено пользователем LuckySB

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Изменено пользователем kapa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А почему не использовать 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 в частности).

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

bw 2048Kbit/s queue 100

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если 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, вообщем в реальной жизни оно позабористее, но труба все считает в байтах, поэтому ппс зависит от размера пакета и я не знаю как регулировать именно ппс на фре. Гуру, поправьте, если я не прав.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Гм. вообще-то спасает.
М-м-м, да, виноват, был неправ.
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.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем Giga-Byte

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.