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

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

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

+1

 

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

Share this post


Link to post
Share on other sites

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

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

Edited by bomberman

Share this post


Link to post
Share on other sites

wed

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

 

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

 

boco

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

Share this post


Link to post
Share on other sites

aabc

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

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

Share this post


Link to post
Share on other sites

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

 

 

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

Share this post


Link to post
Share on other sites

А если поизвращаться можно и счетчики через 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.

Edited by stasn1

Share this post


Link to post
Share on other sites

Добрый день.

 

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

 

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

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

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

 

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

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

 

Юрий.

Share this post


Link to post
Share on other sites

Добрый день.

 

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

 

У меня биллинг ЮТМ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.

Edited by stasn1

Share this post


Link to post
Share on other sites

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

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

 

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

Edited by Hawk128

Share this post


Link to post
Share on other sites

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

 

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

 

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

 

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

Edited by stasn1

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

 

- addr = ip_hdr(skb)->daddr;

+ addr = skb->priority;

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

 

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

Share this post


Link to post
Share on other sites

А если поизвращаться можно и счетчики через 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 ))

Share this post


Link to post
Share on other sites

А если поизвращаться можно и счетчики через 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 ))

 

))

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

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