Шейпинг трафика

Charg

Работает у меня какое-то время шейпинг трафика, настроенный с помощью советов из этой темы.
И вот сегодня мне понадобилось запустить еще один шейпер, т.е. буквально трём айпишникам обрезать канал вообще до мизера.
Создал еще один Alias в закладке Firewall, вписал туда эти 3 айпишника.
Создал точно такое же правило (Floating rules), как уже работающее, за той лишь разницей что там выбраны другие лимитеры и название алиаса естественно нужное, всё остальное то же самое. Для верности даже поместил его выше в списке, чтоб его приоритет был самым высоким (вторым по списку правилом идет то что на скриншоте). Сделал reset states, смотрю на traffic graph и вижу что правило не работает - те айпи которые я вроде как ограничил стабильно что-то качают со скоростью 5-10 мбит (хотя я им до 800кбит ограничивал).
Один конкретный юзер качает что-то торрентом, я это на 100% знаю, и в принципе мог бы спуститься этажом ниже и дать по шапке, но мне нужно победить проблему в целом, а не наказать конкретного юзера.

Что я не так делаю?

werter

1. Почему на правиле стоит Quick ? Или больше никаких др. на LAN-интерфейсе нет ?
2. Почему только in и только для LAN интерфейса ?

Charg

1. Почему на правиле стоит Quick ? Или больше никаких др. на LAN-интерфейсе нет ?

Конкретно на лан интерфейсе есть одно правило "разрешить всё"
Которое создано ещё моим предшественником и я его не трогал из соображений "работает - не лезь". А оба правила для шейпинга, которые я создавал - floating.
По поводу галки Quick - честно говоря на неё я даже не глянул когда создавал второе правило, а первое правило работало с ней.
В любом случае, эта галка ведь определяет только "когда применяется правило", судя по её описанию, а я в любом случае вручную делал reload rules и reset states перед тем как проверять их работоспособность, так что не думаю что она тут сыграла какую-то роль. Но теста ради сейчас попробую создать новое правило без этой галки.

2. Почему только in

Потому что плавающим правилам нельзя задавать direction: any, выдает вот такую ошибку:

The following input errors were detected:

You can not use limiters in Floating rules without choosing a direction.

и только для LAN интерфейса ?

Я пробовал оба варианта с уже работающим правилом - оно не работает если выбирать WAN интерфейс, поэтому и выбран LAN (так работает). Вот я и оставил всё как есть.

werter

Я вот и сам пытаюсь разобраться именно с floating rules. С правилами просто на интерфейсах и так понятно.

Ув. rubic, pigbrother , может подскажите как быть с лимитером на плавающих правилах ? Заранее благодарен.

pigbrother

Увы, с переходом на быстрый интернет все ранние попытки внедрения\использования шейпера оказались невостребованными. Поэтому мой опыт до-Ethernet интернета не представляет никакой ценности да и, честно говоря, плотно забыт.

Charg

Но теста ради сейчас попробую создать новое правило без этой галки.

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

pigbrother

Добавлю неплохой, вроде, мануал:

Flexible vs. Fixed Limiters & Troubleshooting with pfSense 2.2.x
https://www.reddit.com/r/PFSENSE/comments/3e67dk/flexible_vs_fixed_limiters_troubleshooting_with/
Сам не пробовал, как писал - нет необходимости с переходом на Ethernet.

PbIXTOP

С шейпером обычно проблем не имел.
Во Floating обычно не использовал - сразу вешал на LAN интерфейсе + обратный на WAN на всякий случай (использовались частично реальные IP).
Если в системе используется прокси, возможно трафик идет через него.
Еще как вариант может пробиваться каким-нибудь способом ipv6 трафик.

werter

Коллеги, и все же.
Оч. бы хотелось пример настроек limiter-а именно во Floating rules.
Реальный. Живой.

Спасибо большое заранее.

PbIXTOP

@werter:

Коллеги, и все же.
Оч. бы хотелось пример настроек limiter-а именно во Floating rules.
Реальный. Живой.

Спасибо большое заранее.

Так и не понял в чем может быть проблема применения limiter в Floating.
Главное правильно выбрать направление - обычно in. Выбрать правильно лимитеры для In/Out - обычно это source/destination.
Без опции quick правила pass не тестировал ни разу (поскольку "Default block all" - рисковать не люблю, хотя оно вроде одним из первых идет).
Предпочитаю все-таки выставлять c limiter правила на самих интерфейсах - нагляднее контролировать доступ в сети.

dvserg

@PbIXTOP:

@werter:

Коллеги, и все же.
Оч. бы хотелось пример настроек limiter-а именно во Floating rules.
Реальный. Живой.

Спасибо большое заранее.

Так и не понял в чем может быть проблема применения limiter в Floating.
Главное правильно выбрать направление - обычно in. Выбрать правильно лимитеры для In/Out - обычно это source/destination.
Без опции quick правила pass не тестировал ни разу (поскольку "Default block all" - рисковать не люблю, хотя оно вроде одним из первых идет).
Предпочитаю все-таки выставлять c limiter правила на самих интерфейсах - нагляднее контролировать доступ в сети.

На сколько я понимаю, в FLoating для шейпера правила делаются БЕЗ опции Quick. Правила должны быть разрешающими. Задача этих правил не ограничивать/фильтровать пакеты, а переместить их в нужную очередь. Фильтрация идёт далее в правилах (обычно на интерфейсах).

werter

@PbIXTOP:

@werter:

Коллеги, и все же.
Оч. бы хотелось пример настроек limiter-а именно во Floating rules.
Реальный. Живой.

Спасибо большое заранее.

Так и не понял в чем может быть проблема применения limiter в Floating.
Главное правильно выбрать направление - обычно in. Выбрать правильно лимитеры для In/Out - обычно это source/destination.
Без опции quick правила pass не тестировал ни разу (поскольку "Default block all" - рисковать не люблю, хотя оно вроде одним из первых идет).
Предпочитаю все-таки выставлять c limiter правила на самих интерфейсах - нагляднее контролировать доступ в сети.

Доброе.
Вы настройте на floating. Выложите скрины. А после и поговорим.

PbIXTOP

@dvserg:

@PbIXTOP:

@werter:

Коллеги, и все же.
Оч. бы хотелось пример настроек limiter-а именно во Floating rules.
Реальный. Живой.

Спасибо большое заранее.

Так и не понял в чем может быть проблема применения limiter в Floating.
Главное правильно выбрать направление - обычно in. Выбрать правильно лимитеры для In/Out - обычно это source/destination.
Без опции quick правила pass не тестировал ни разу (поскольку "Default block all" - рисковать не люблю, хотя оно вроде одним из первых идет).
Предпочитаю все-таки выставлять c limiter правила на самих интерфейсах - нагляднее контролировать доступ в сети.

На сколько я понимаю, в FLoating для шейпера правила делаются БЕЗ опции Quick. Правила должны быть разрешающими. Задача этих правил не ограничивать/фильтровать пакеты, а переместить их в нужную очередь. Фильтрация идёт далее в правилах (обычно на интерфейсах).

Вы как обычно не правы, и почему все не могут понять логику работы quick, pass-match и limiter-Queue
Limitter работает на основе ipfw, Queue — на pf.
Пришлось тестировать.
Сделал скриншоты
И теперь по порядку как тестировал.
Все тесты проводил на pfSense 2.2.6.
Создал два лимитера для входящего и исходящего трафика.
Первый тест в правиле было выбрано как на картинке Pass и Quick — скорость ограничивалась согласно правилам.
Вторым тестом провел только выбрав Pass и отключив Quick — и естественно правило ограничения не сработало.
И вдруг я решил может стоит попробовать Match — ведь именно такие правила создает Queue Wizard в pfSense.
Результат оказался вполне ожидаем — limiter работает вне зависимости от положения quick, вернее если б было несколько подходящих правил match quick имел бы смысл. При использовании match обычные разрешающие-запрещающие правила на интерфейсах полностью отрабатывают.

Из выводов: match — это просто правило маркировки пакетов-соединений. Во floating обычные правила разрешения-запрета без quick практически не имеют смысла, если есть интерфесные правила перекрывающие их.

Кстати решил проверить за одно еще и совместимость limiter и squid-transparent — к сожалению ни в одном режиме веб трафик не был пропущен.

rules.png_thumb

limiter_DST.png_thumb

limiter_SRC.png_thumb

pass_quick.png_thumb

pass.png_thumb

werter

2 PbIXTOP
Спасибо за работу и скрины.

Но, так как Вы выбрали при создании очередей source\destination, то шейпер получается нединамическим - просто каждому ip нарезано будет по 1Мбит\с . Независимо от того, свободен канал или занят.
А весь смысл в том, чтобы динамически отдавать пол-лям канал. Т.е. один человек - весь канал ему, два - пополами т.д.

P.s. И для чистоты эксперимента лучше создайте очереди с разным лимитом - 1 и 2 Мбит\с , например.

P.p.s. Начало что-то проясняться. Благодаря ув. PbIXTOP, к-ый натолкнул на мысль, получилось вот что.

И никаких галок на quick не надо.
Таким обр., мы нарезаем скорость динамически всем и при этом у нас работают дальнейшие правила на интерфейсах.

![pfSense_ Firewall_ Rules_ Edit.png](/public/imported_attachments/1/pfSense_ Firewall_ Rules_ Edit.png)
![pfSense_ Firewall_ Rules_ Edit.png_thumb](/public/imported_attachments/1/pfSense_ Firewall_ Rules_ Edit.png_thumb)

pigbrother

Таким обр., мы нарезаем скорость динамически всем

На скриншоте правило применяется к одному IP. Так и надо?

PbIXTOP

@werter:

2 PbIXTOP
Спасибо за работу и скрины.

Но, так как Вы выбрали при создании очередей source\destination, то шейпер получается нединамическим - просто каждому ip нарезано будет по 1Мбит\с . Независимо от того, свободен канал или занят.
А весь смысл в том, чтобы динамически отдавать пол-лям канал. Т.е. один человек - весь канал ему, два - пополами т.д.

P.s. И для чистоты эксперимента лучше создайте очереди с разным лимитом - 1 и 2 Мбит\с , например.

P.p.s. Начало что-то проясняться. Благодаря ув. PbIXTOP, к-ый натолкнул на мысль, получилось вот что.

И никаких галок на quick не надо.
Таким обр., мы нарезаем скорость динамически всем и при этом у нас работают дальнейшие правила на интерфейсах.

Деление трафика на пополам через лимитер скорее всего не получиться, он ведь работает отдельно от pf. Равномерно распределять скорость можно пробовать через очереди. Пару раз пытались запустить, но как-то не зашло. Просто вынесли мозг понятиями и ограничениями.

PbIXTOP

@pigbrother:

Таким обр., мы нарезаем скорость динамически всем

На скриншоте правило применяется к одному IP. Так и надо?

Один IP из локальной сети был просто выбран для его выделения от остального трафика.
Если вы хотите ограничивать общую скорость, а не индивидуальную, то необходимо в масках лимитера проставлять нули.
У меня например есть правило ограничивающее скорость до всяких видео сервисов.
Да и дополнительно конечный список назначения прописан в Squid, Bypass destination. Так-как Squid у меня используется transparent режиме.

rules_slow.png_thumb

limiter_slow.png_thumb

werter

@pigbrother:

Таким обр., мы нарезаем скорость динамически всем

На скриншоте правило применяется к одному IP. Так и надо?

На себе проверял. Работает и с подсетью.

werter

@PbIXTOP:

Деление трафика на пополам через лимитер скорее всего не получиться, он ведь работает отдельно от pf. Равномерно распределять скорость можно пробовать через очереди. Пару раз пытались запустить, но как-то не зашло. Просто вынесли мозг понятиями и ограничениями.

Получится. Рисуйте верное правило и все получится.
И да, на скрине у Вас интерфейсное правило, а не плавающее - не то пальто.

P.s. Со сквидом , конечно, не работает. В прозрачном режиме он перехватывает всё, что идет во вне на 80-ый порт tcp. Он сам себе хозяин, т.с.

PbIXTOP

@werter:

Получится. Рисуйте верное правило и все получится.
И да, на скрине у Вас интерфейсное правило, а не плавающее - не то пальто.

На самом деле небольшая разница интерфейсное или нет — все равно limiter=ipfw. И проблема в том что равномерно разделить канал между двумя пользователями он не сможет, поскольку работает обычный fifo буфер - соответственно кто больше посылает тот и получает больший приоритет.