NiTr0 Опубликовано 10 декабря, 2015 · Жалоба А вот перенаправление - уже как по мне лишнее в модуле полисера. Я предлагал чуть выше маркировать пакеты, обработанные/не обработанные полисером... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
enots Опубликовано 10 декабря, 2015 · Жалоба А вот перенаправление - уже как по мне лишнее в модуле полисера. Я предлагал чуть выше маркировать пакеты, обработанные/не обработанные полисером... Как по мне, маркировка не очень удобна. Проше все сделать через внешнее правило (которое сейчас в большенстве случаев "-j DROP"), т.е. оторвать алгоритм ratelimit от внешнего и использовать внутренний не явный drop. Такое поведение для полисера будет легко понять. Внешнее-же правило сделать зависимым от "IP вошел в сет или нет" и можно будет применять -j DROP или -j REROUTE, etc. Правда это не позволит делать странные ratelimit типа когда overlimit пакеты не дропаем, а отправляем куда-то еще. Но честно говоря это уже экзотика и я слабо представляю кому она может потребоваться ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bomberman Опубликовано 10 декабря, 2015 · Жалоба Зачем из модуля полисера делать ещё что то? Так гляди и до БРАС-а доростёт. Пусть это просто будет хороший полисер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
boco Опубликовано 10 декабря, 2015 · Жалоба Зачем из модуля полисера делать ещё что то? +1 так-то и ограничение ппс просто идея "на подумать" была. можно отдельный модуль для этого сделать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bomberman Опубликовано 10 декабря, 2015 (изменено) · Жалоба так-то и ограничение ппс просто идея "на подумать" была. можно отдельный модуль для этого сделать. Плодить сущьности тоже не стоит. Считаю это возможным как расширение ф-ционала, но из раздела "хочух". Изменено 10 декабря, 2015 пользователем bomberman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 10 декабря, 2015 · Жалоба wed Изменение dst_ip сделать трудно, так как это фактически потребует NAT. А nat правила ставятся не в forward и видят не все пакеты. Изменение nexthop, по идее, можно сделать через правила -j ROUTE. Но для этого надо реализовать более гибкий матчинг у ratelimit, чем сейчас. То есть надо, чтоб была возможность дропать overlimit пакеты прямо внутри ratelimit (через hotdop), а наружу матчились пакеты которых _нет_ в указанном set. (Сейчас матчатся overlimit пакеты, которые надо дропать.) Это реализовать не сложно. Сложно придумать интерфейс, чтоб это было максимально понятно людям. Пока я не смог такое придумать как можно было бы _понятно_ конфигурить все 4 варианта (пакеты ниже лимита, выше лимита (overlimit), попадающие в set, не попадающие в set.) boco Можете привести пример какие бы вы хотели ставить значения pps? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adamanov Опубликовано 15 декабря, 2015 · Жалоба aabc Можно параллельно встроеному сету ratelimit, создавать обычный ipset для матчинга списка адресов в других таблицах, хоть в nat для редиректов, хоть в raw для контраков. Вопрос в том насколько сложно создавать и поддерживать этот сет, в актуальном состоянии, при помощи ratelimit или всетаки делать это скриптами?! А если поизвращаться можно и счетчики через ipset организовать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 16 декабря, 2015 · Жалоба А если поизвращаться можно и счетчики через ipset организовать. Каким образом? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 16 декабря, 2015 · Жалоба Счетчики в ipset - было бы не плохо. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stasn1 Опубликовано 16 декабря, 2015 (изменено) · Жалоба А если поизвращаться можно и счетчики через 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. Изменено 16 декабря, 2015 пользователем stasn1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 17 декабря, 2015 · Жалоба Добрый день. А насколько сложно прикрутить какой-нибудь идентификатор к правилу со скоростью? У меня биллинг ЮТМ5 выгружает частенько вперемешку данные по IP и скоростям. Зацепиться можно за номер сервисной связки, сейчас нак и делаю через ipfw tablearg. Но в случае ipt-ratelimit придется писать дастаточно сложную обвязку анализатор. Если бы было возможно использовать что-то вроде номера строки и привязывать его к той же сервисной связке - то можно было бы значительно улучшить функционал интерфейса. И конечно же не хватает масок. Юрий. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stasn1 Опубликовано 17 декабря, 2015 (изменено) · Жалоба Добрый день. А насколько сложно прикрутить какой-нибудь идентификатор к правилу со скоростью? У меня биллинг ЮТМ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. Изменено 17 декабря, 2015 пользователем stasn1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 17 декабря, 2015 (изменено) · Жалоба Как вариант - м.б. Но по опыту при большой нагрузке каждое лишнее правило для трафика это очень нехорошо. Хотелось бы максимально оптимизировать, но пока что как это сделать красиво - не придумал. Но в любом случае - спасибо за такой чудесный модуль. Изменено 17 декабря, 2015 пользователем Hawk128 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
boco Опубликовано 18 декабря, 2015 · Жалоба Можете привести пример какие бы вы хотели ставить значения pps? эмпирически подбирал бы =) например: мы знаем средний размер пакета (700 байт). тогда я беру значение в 2-3 раза ниже, скажем 256 байт и считаю, сколько таких пакетов влезет в полосу, отведенную клиенту. для 10 мбит это примерно 5 тысяч пакетов. вот до этого значения и ограничивал бы. возможно, я ошибаюсь в своих рассуждениях. буду рад возражениям. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stasn1 Опубликовано 18 декабря, 2015 (изменено) · Жалоба Как вариант - м.б. Но по опыту при большой нагрузке каждое лишнее правило для трафика это очень нехорошо. Хотелось бы максимально оптимизировать, но пока что как это сделать красиво - не придумал. Но в любом случае - спасибо за такой чудесный модуль. Почему же лишнее?! В моем случае при использовании шейпера на tc qdisc фильтр просто перемещается из tc filter в ipset/iptables. Даже, наверное, учитывая то, что в один qdisc может залетать несколько ip/net (т.е. нужно было несколько фильтров), то и некая оптимизация что ли получается. Да и проще само по себе так, по-моему. Я для собственных нужд только что добился нужного функционала от ipt_ratelimit при помощи грязного хака и пары костылей, заменив полстрочки в исходниках. Проверил - раскидывает по правилам по номеру сервисной связки. ) Изменено 18 декабря, 2015 пользователем stasn1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bomberman Опубликовано 18 декабря, 2015 · Жалоба Я для собственных нужд только что добился нужного функционала от ipt_ratelimit при помощи грязного хака и пары костылей, заменив полстрочки в исходниках. Проверил - раскидывает по правилам по номеру сервисной связки. ) А поделиться с народом, одновременно обсудив с разработчиком? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stasn1 Опубликовано 18 декабря, 2015 · Жалоба А поделиться с народом, одновременно обсудив с разработчиком? Говорю же: грязный хак. ) - addr = ip_hdr(skb)->daddr; + addr = skb->priority; Оба - целые 32битные числа. Дальше сервисная связка, например, a027 соответствует у меня qdisc 10:a027. Путем нехитрых манипуляций она превращается в ip-адрес 39.160.16.0 (я прямо в селекте из базы конвертирую). Ну а дальше этот адрес добавляю в правило. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adamanov Опубликовано 18 декабря, 2015 · Жалоба А если поизвращаться можно и счетчики через 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 )) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 18 декабря, 2015 · Жалоба А если поизвращаться можно и счетчики через 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 )) )) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bomberman Опубликовано 21 декабря, 2015 · Жалоба )) Я так пологаю "коммит" принемается? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adamanov Опубликовано 27 декабря, 2015 · Жалоба Этот коммит обязан быть первым в наступающем году!) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SyJet Опубликовано 29 декабря, 2015 · Жалоба А интересно, модуль можно с nDPI скрестить и приобрести зимовать траф по классам по абененту? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 30 декабря, 2015 · Жалоба nDPI скоро дропнет либо уже дропнул поддержку для работы в контексте ядра, там сильно иная архитектура, чтобы тащить в ядро. Скорее грамотнее было бы сделать что-то легкое для классификации, вся мощь nDPI не нужна явно, ведь все хотят классификатор торрентов :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SyJet Опубликовано 30 декабря, 2015 · Жалоба nDPI скоро дропнет либо уже дропнул поддержку для работы в контексте ядра, там сильно иная архитектура, чтобы тащить в ядро. Скорее грамотнее было бы сделать что-то легкое для классификации, вся мощь nDPI не нужна явно, ведь все хотят классификатор торрентов :) Я хочу голос+видео+http+https+свои классы по dst. А все остальное по остаточной пускать:) Хотя вполне вполне реально было бы давать уже меченый траф, а модуль бы на основе меток рулил бып риорететом в полкн :) Тоже ничего было бы решение Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 30 декабря, 2015 · Жалоба Чисто в теории, имхо, рулеж на базе меток - более верный и гибкий вариант. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...