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

ipt-ratelimit трафик полисинг в iptables

А вот перенаправление - уже как по мне лишнее в модуле полисера.

Я предлагал чуть выше маркировать пакеты, обработанные/не обработанные полисером...

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


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

А вот перенаправление - уже как по мне лишнее в модуле полисера.

Я предлагал чуть выше маркировать пакеты, обработанные/не обработанные полисером...

 

Как по мне, маркировка не очень удобна.

Проше все сделать через внешнее правило (которое сейчас в большенстве случаев "-j DROP"), т.е. оторвать алгоритм ratelimit от внешнего и использовать внутренний не явный drop. Такое поведение для полисера будет легко понять.

Внешнее-же правило сделать зависимым от "IP вошел в сет или нет" и можно будет применять -j DROP или -j REROUTE, etc.

Правда это не позволит делать странные ratelimit типа когда overlimit пакеты не дропаем, а отправляем куда-то еще. Но честно говоря это уже экзотика и я слабо представляю кому она может потребоваться )

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


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

Зачем из модуля полисера делать ещё что то? Так гляди и до БРАС-а доростёт.

Пусть это просто будет хороший полисер.

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


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

Зачем из модуля полисера делать ещё что то?

+1

 

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

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


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

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

Плодить сущьности тоже не стоит. Считаю это возможным как расширение ф-ционала, но из раздела "хочух".

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

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


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

wed

Изменение dst_ip сделать трудно, так как это фактически потребует NAT. А nat правила ставятся не в forward и видят не все пакеты.

 

Изменение nexthop, по идее, можно сделать через правила -j ROUTE. Но для этого надо реализовать более гибкий матчинг у ratelimit, чем сейчас. То есть надо, чтоб была возможность дропать overlimit пакеты прямо внутри ratelimit (через hotdop), а наружу матчились пакеты которых _нет_ в указанном set. (Сейчас матчатся overlimit пакеты, которые надо дропать.) Это реализовать не сложно. Сложно придумать интерфейс, чтоб это было максимально понятно людям. Пока я не смог такое придумать как можно было бы _понятно_ конфигурить все 4 варианта (пакеты ниже лимита, выше лимита (overlimit), попадающие в set, не попадающие в set.)

 

boco

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

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


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

aabc

Можно параллельно встроеному сету ratelimit, создавать обычный ipset для матчинга списка адресов в других таблицах, хоть в nat для редиректов, хоть в raw для контраков. Вопрос в том насколько сложно создавать и поддерживать этот сет, в актуальном состоянии, при помощи ratelimit или всетаки делать это скриптами?!

А если поизвращаться можно и счетчики через ipset организовать.

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


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

А если поизвращаться можно и счетчики через ipset организовать.

 

 

Каким образом?

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


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

А если поизвращаться можно и счетчики через ipset организовать.

 

 

Каким образом?

 

Мне, например, сразу представилась следующая схема:

Сейчас я для шейпера на tc через -j SET --map-set anyname dst --map-prio (или map-mark) некой группе адресов, сетей назначаю сразу номер класса в шейпере, несколько разных адресов могут иметь одинаковый номер класса, так как принадлежат одной и той же услуге. Что избавляет от необходимости использовать потом "tc filter".

В моем случае было бы идеально сделать возможность задавать полосы в xt_ratelimit не только по списку одиночных ip-адресов (или подсетей когда реализуются префиксы), но и по номеру в skb->priority (и skb->mark). А то сейчас мало того что приходится каждую подсеть парсить в список отдельных адресов, так еще если у клиента несколько таких сетей-адресов, то и склеивать потом в кучу все это.

Например, можно сделать пару доп.режимов кроме mode dst,src - mode prio & mark. А в /proc кроме(или вместо) адресов - prio:MIN (или MAJ+MIN) или mark:XXXX.

 

Это бы позволило при желании вынести логику раскидывания по полосам за пределы xt_ratelimit, и уже извращаться там как душа пожелает: различать, например, не только адреса, но и протоколы, порты, да что угодно, вешая метки через CLASSIFY и MARK.

 

Плюс в таком режиме и самому модулю, наверное, проще будет: не нужно сначала парсить адреса в правиле, загонять в хэш, а потом по хэшу сверять пролетащие пакеты. Тут просто по сути номер правила сравнивается с определенным полем в skb.

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

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


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

Добрый день.

 

А насколько сложно прикрутить какой-нибудь идентификатор к правилу со скоростью?

 

У меня биллинг ЮТМ5 выгружает частенько вперемешку данные по IP и скоростям.

Зацепиться можно за номер сервисной связки, сейчас нак и делаю через ipfw tablearg.

Но в случае ipt-ratelimit придется писать дастаточно сложную обвязку анализатор.

 

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

И конечно же не хватает масок.

 

Юрий.

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


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

Добрый день.

 

А насколько сложно прикрутить какой-нибудь идентификатор к правилу со скоростью?

 

У меня биллинг ЮТМ5 выгружает частенько вперемешку данные по IP и скоростям.

Зацепиться можно за номер сервисной связки, сейчас нак и делаю через ipfw tablearg.

Но в случае ipt-ratelimit придется писать дастаточно сложную обвязку анализатор.

 

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

И конечно же не хватает масок.

 

Юрий.

 

 

У меня аналогичная ситуация, возможное универсальное решение описал выше. В моем случае это "ipset add clients 1.1.1.0/30 skbprio 10:b552", где $b552 - это и есть номер сервисной связки. И таких элементов в ipset с одинаковым номером может быть несколько. Потом этот номер копируется в поле skb->priority по "iptables ... -j SET --map-set clients dst --map-prio" и как результат сразу летит в нужный класс шейпера без какого-либо фильтра в нем.

 

Было бы идеально если бы появилась такая возможность сразу по skb->priority заруливать трафик в нужное правило и в ipt-ratelimit.

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

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


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

Как вариант - м.б. Но по опыту при большой нагрузке каждое лишнее правило для трафика это очень нехорошо.

Хотелось бы максимально оптимизировать, но пока что как это сделать красиво - не придумал.

 

Но в любом случае - спасибо за такой чудесный модуль.

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

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


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

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

эмпирически подбирал бы =)

 

например: мы знаем средний размер пакета (700 байт). тогда я беру значение в 2-3 раза ниже, скажем 256 байт и считаю, сколько таких пакетов влезет в полосу, отведенную клиенту. для 10 мбит это примерно 5 тысяч пакетов. вот до этого значения и ограничивал бы.

 

возможно, я ошибаюсь в своих рассуждениях. буду рад возражениям.

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


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

Как вариант - м.б. Но по опыту при большой нагрузке каждое лишнее правило для трафика это очень нехорошо.

Хотелось бы максимально оптимизировать, но пока что как это сделать красиво - не придумал.

 

Но в любом случае - спасибо за такой чудесный модуль.

 

Почему же лишнее?! В моем случае при использовании шейпера на tc qdisc фильтр просто перемещается из tc filter в ipset/iptables. Даже, наверное, учитывая то, что в один qdisc может залетать несколько ip/net (т.е. нужно было несколько фильтров), то и некая оптимизация что ли получается. Да и проще само по себе так, по-моему.

 

Я для собственных нужд только что добился нужного функционала от ipt_ratelimit при помощи грязного хака и пары костылей, заменив полстрочки в исходниках. Проверил - раскидывает по правилам по номеру сервисной связки. )

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

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


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

Я для собственных нужд только что добился нужного функционала от ipt_ratelimit при помощи грязного хака и пары костылей, заменив полстрочки в исходниках. Проверил - раскидывает по правилам по номеру сервисной связки. )

А поделиться с народом, одновременно обсудив с разработчиком?

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


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

А поделиться с народом, одновременно обсудив с разработчиком?

 

Говорю же: грязный хак. )

 

- addr = ip_hdr(skb)->daddr;

+ addr = skb->priority;

Оба - целые 32битные числа.

 

Дальше сервисная связка, например, a027 соответствует у меня qdisc 10:a027. Путем нехитрых манипуляций она превращается в ip-адрес 39.160.16.0 (я прямо в селекте из базы конвертирую). Ну а дальше этот адрес добавляю в правило.

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


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

А если поизвращаться можно и счетчики через ipset организовать.

 

 

Каким образом?

 

ipset create foo hash:ip counters

for i in `cut -d" " -f 1 /proc/net/ipt_ratelimit/in` ; do ipset add foo $i ; done ))

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


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

А если поизвращаться можно и счетчики через ipset организовать.

 

 

Каким образом?

 

ipset create foo hash:ip counters

for i in `cut -d" " -f 1 /proc/net/ipt_ratelimit/in` ; do ipset add foo $i ; done ))

 

))

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


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

))

Я так пологаю "коммит" принемается? :)

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


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

Этот коммит обязан быть первым в наступающем году!)

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


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

А интересно, модуль можно с nDPI скрестить и приобрести зимовать траф по классам по абененту?

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


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

nDPI скоро дропнет либо уже дропнул поддержку для работы в контексте ядра, там сильно иная архитектура, чтобы тащить в ядро. Скорее грамотнее было бы сделать что-то легкое для классификации, вся мощь nDPI не нужна явно, ведь все хотят классификатор торрентов :)

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


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

nDPI скоро дропнет либо уже дропнул поддержку для работы в контексте ядра, там сильно иная архитектура, чтобы тащить в ядро. Скорее грамотнее было бы сделать что-то легкое для классификации, вся мощь nDPI не нужна явно, ведь все хотят классификатор торрентов :)

Я хочу голос+видео+http+https+свои классы по dst. А все остальное по остаточной пускать:)

Хотя вполне вполне реально было бы давать уже меченый траф, а модуль бы на основе меток рулил бып риорететом в полкн :) Тоже ничего было бы решение

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


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

Чисто в теории, имхо, рулеж на базе меток - более верный и гибкий вариант.

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


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

Join the conversation

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

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

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

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

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

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

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