две трубы

[baton4eg]

Добрый день, необходимо реализовать следующее:
1. Если юзер идёт на порт 80 (tcp) он попадает в таблицу 1 (вход) и 2 (исход).
2. Если юзер идёт на всё остальное, то попадает в таблицы 3 (вход) и 4 (исход)
3. Как то это всё загнать под крышку, чтобы канал не сжирался.

Пример. Имеем макс. канал для юзера 1 мегабит, юзер запустил торрент, попал в таблицу 3,4, и пайп у него пусть 512Кбит. Дальше он запустил скачку по http, попал он в таблицы 1,2, пайп 1 мегабит, и система поняла что эти 2 действия юзера в ОДНОЙ ОБЩЕЙ ТРУБЕ и ПРОССУМИРОВАВ его действия ограничила его в 1 Мегабит.
P.S На практике у меня получилось добавится только суммирование 2 таблиц, т.е юзеру ушло 1,5 Мегабит, т.е торрент+web запускается, ограничивается, но вот паралельно, в разных трубах, а надо как то в одной общей, запихать 2 трубы. Идея я думаю понятно, спасибо.

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[baton4eg]

нет никакой реализации данный задачи?

[terminus]

На ipfw не очень удобно такое делать (практически нииизя).
А очереди + пайпы не подойдут? Пайп жестко ограничивает в 1м, а очереди регулируют приеоритеты в зависимости от типа трафика?

[baton4eg]

придётся наверно с очередями поиграть, что получится выложу

[baton4eg]

чего то не пойму как очереди внедрить для данной схемы =(
Пайп ограничивает, а вот очереди от типа трафика не пойму куда кинуть.. т.е есть очередь для http, вес 10, и есть очередь для всего остального, вес 5 к примеру.. Дальше не пойму в какую сторону рулить.. По идеи, если бы у нас был бы один большой пайп(Весь канал инета к примеру 100Мегабит), в котором сидели бы его дети (1,2.3 Мегабита) тогда можно было на основе этого пайпа сделать очереди для http и другого с приоритетами.. Пока я завис, может кто поможет.. reset не предлагать

[hizel]

one_pass и гениальная идея о том что трафик можно проганять через несколько труб последовательно

[baton4eg]

пробовал, делал 2 трубы, например 400+600 Кбит, ставил one_pass, как в одну трубу залетело, во вторую не хочет



я тут пытаюсь на шейпере реализовать

немного ipfw:

Код: Выделить всё

#Сам пайп
${fw} pipe 1000 config bw 2000Kbit/s mask src-ip 0xffffffff
${fw} pipe 1001 config bw 1000Kbit/s mask dst-ip 0xffffffff
# IN
${fw} add 1203 pass ip from any to any out via em0
${fw} add 1204 pipe tablearg ip from "table(50)" to any in via em1
${fw} add 1205 pass ip from "table(50)" to any in via em1
# OUT
${fw} add 1203 pass ip from any to any in via em0
${fw} add 1204 pipe tablearg ip from any to "table(51)" out via em1
${fw} add 1205 pass ip from any to "table(51)" out via em1

Соответственно много пайпов, юзер загоняется в 2 таблицы

[baton4eg]

Соответственно много пайпов, юзер загоняется в 2 таблицы

Задача чтоб всегда был в приоритете http в своей трубе, ну и в самой общей трубе (т.е весь инет трафик)
Сейчас веду график по протоколам, TCP,80,UDP, замечаю что порой UDP превосходит 80, т.е юезеры запускают торренты, канал забивается, а серфинг подтупливает. Хочу сделать как канал забился, торрентеры или те кто не юзает http, немного двинулись..

По сути всё с шейпера через defaultgate идёт на нате, была мысль бросить шейпер и на нате поднять правила приоритезации, логично или нет? или можно на шейпере сделать?

[baton4eg]

one_pass и гениальная идея о том что трафик можно проганять через несколько труб последовательно

делал 2 таблицы, в которые загонял юзера в одну с одним пайпом, в другую таблицу с другим. включил one_pass=0, В теории должно было произойти суммирование, например пайп 1 = 400Кбит, а пайп 2=600, т.е должен был получить на выходе 1000Кбит, верно?

[hizel]

я практик

[FreeBSP]

думается мне что трубы проходятся по очереди и на выходе из последней трубы задержка будет суммироваться, а скорость будет равна наименьшему ограничению в серии труб
* естественно если one_pass в нуле

[baton4eg]

вот, так оно и показало на практике, а по словам hizel я понял что должно было выйти со всех правил сумма ограничений в серии труб

[FreeBSP]

логически прикинь
серия труб(водопроводных) разного диаметра и длины. в итоге время прохождения будет смуммарной длиной всех труб, а скорость будет зависеть от диаметра самой узкой трубы(при грубом приближении )