Шейпинг трафика
-
Увы, с переходом на быстрый интернет все ранние попытки внедрения\использования шейпера оказались невостребованными. Поэтому мой опыт до-Ethernet интернета не представляет никакой ценности да и, честно говоря, плотно забыт.
-
Но теста ради сейчас попробую создать новое правило без этой галки.
Попробовал создать новое правило без галки Quick, в старом правиле тоже убрал - не работает новое правило (а первое работает), юзеры качают себе без каких-либо ограничений.
-
Добавлю неплохой, вроде, мануал:
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. -
С шейпером обычно проблем не имел.
Во Floating обычно не использовал - сразу вешал на LAN интерфейсе + обратный на WAN на всякий случай (использовались частично реальные IP).
Если в системе используется прокси, возможно трафик идет через него.
Еще как вариант может пробиваться каким-нибудь способом ipv6 трафик. -
Коллеги, и все же.
Оч. бы хотелось пример настроек limiter-а именно во Floating rules.
Реальный. Живой.Спасибо большое заранее.
-
Коллеги, и все же.
Оч. бы хотелось пример настроек limiter-а именно во Floating rules.
Реальный. Живой.Спасибо большое заранее.
Так и не понял в чем может быть проблема применения limiter в Floating.
Главное правильно выбрать направление - обычно in. Выбрать правильно лимитеры для In/Out - обычно это source/destination.
Без опции quick правила pass не тестировал ни разу (поскольку "Default block all" - рисковать не люблю, хотя оно вроде одним из первых идет).
Предпочитаю все-таки выставлять c limiter правила на самих интерфейсах - нагляднее контролировать доступ в сети. -
Коллеги, и все же.
Оч. бы хотелось пример настроек limiter-а именно во Floating rules.
Реальный. Живой.Спасибо большое заранее.
Так и не понял в чем может быть проблема применения limiter в Floating.
Главное правильно выбрать направление - обычно in. Выбрать правильно лимитеры для In/Out - обычно это source/destination.
Без опции quick правила pass не тестировал ни разу (поскольку "Default block all" - рисковать не люблю, хотя оно вроде одним из первых идет).
Предпочитаю все-таки выставлять c limiter правила на самих интерфейсах - нагляднее контролировать доступ в сети.На сколько я понимаю, в FLoating для шейпера правила делаются БЕЗ опции Quick. Правила должны быть разрешающими. Задача этих правил не ограничивать/фильтровать пакеты, а переместить их в нужную очередь. Фильтрация идёт далее в правилах (обычно на интерфейсах).
-
Коллеги, и все же.
Оч. бы хотелось пример настроек limiter-а именно во Floating rules.
Реальный. Живой.Спасибо большое заранее.
Так и не понял в чем может быть проблема применения limiter в Floating.
Главное правильно выбрать направление - обычно in. Выбрать правильно лимитеры для In/Out - обычно это source/destination.
Без опции quick правила pass не тестировал ни разу (поскольку "Default block all" - рисковать не люблю, хотя оно вроде одним из первых идет).
Предпочитаю все-таки выставлять c limiter правила на самих интерфейсах - нагляднее контролировать доступ в сети.Доброе.
Вы настройте на floating. Выложите скрины. А после и поговорим. -
Коллеги, и все же.
Оч. бы хотелось пример настроек 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 — к сожалению ни в одном режиме веб трафик не был пропущен.
-
2 PbIXTOP
Спасибо за работу и скрины.Но, так как Вы выбрали при создании очередей source\destination, то шейпер получается нединамическим - просто каждому ip нарезано будет по 1Мбит\с . Независимо от того, свободен канал или занят.
А весь смысл в том, чтобы динамически отдавать пол-лям канал. Т.е. один человек - весь канал ему, два - пополами т.д.P.s. И для чистоты эксперимента лучше создайте очереди с разным лимитом - 1 и 2 Мбит\с , например.
P.p.s. Начало что-то проясняться. Благодаря ув. PbIXTOP, к-ый натолкнул на мысль, получилось вот что.
И никаких галок на quick не надо.
Таким обр., мы нарезаем скорость динамически всем и при этом у нас работают дальнейшие правила на интерфейсах.
 -
Таким обр., мы нарезаем скорость динамически всем
На скриншоте правило применяется к одному IP. Так и надо?
-
2 PbIXTOP
Спасибо за работу и скрины.Но, так как Вы выбрали при создании очередей source\destination, то шейпер получается нединамическим - просто каждому ip нарезано будет по 1Мбит\с . Независимо от того, свободен канал или занят.
А весь смысл в том, чтобы динамически отдавать пол-лям канал. Т.е. один человек - весь канал ему, два - пополами т.д.P.s. И для чистоты эксперимента лучше создайте очереди с разным лимитом - 1 и 2 Мбит\с , например.
P.p.s. Начало что-то проясняться. Благодаря ув. PbIXTOP, к-ый натолкнул на мысль, получилось вот что.
И никаких галок на quick не надо.
Таким обр., мы нарезаем скорость динамически всем и при этом у нас работают дальнейшие правила на интерфейсах.Деление трафика на пополам через лимитер скорее всего не получиться, он ведь работает отдельно от pf. Равномерно распределять скорость можно пробовать через очереди. Пару раз пытались запустить, но как-то не зашло. Просто вынесли мозг понятиями и ограничениями.
-
Таким обр., мы нарезаем скорость динамически всем
На скриншоте правило применяется к одному IP. Так и надо?
Один IP из локальной сети был просто выбран для его выделения от остального трафика.
Если вы хотите ограничивать общую скорость, а не индивидуальную, то необходимо в масках лимитера проставлять нули.
У меня например есть правило ограничивающее скорость до всяких видео сервисов.
Да и дополнительно конечный список назначения прописан в Squid, Bypass destination. Так-как Squid у меня используется transparent режиме.
-
Таким обр., мы нарезаем скорость динамически всем
На скриншоте правило применяется к одному IP. Так и надо?
На себе проверял. Работает и с подсетью.
-
Деление трафика на пополам через лимитер скорее всего не получиться, он ведь работает отдельно от pf. Равномерно распределять скорость можно пробовать через очереди. Пару раз пытались запустить, но как-то не зашло. Просто вынесли мозг понятиями и ограничениями.
Получится. Рисуйте верное правило и все получится.
И да, на скрине у Вас интерфейсное правило, а не плавающее - не то пальто.P.s. Со сквидом , конечно, не работает. В прозрачном режиме он перехватывает всё, что идет во вне на 80-ый порт tcp. Он сам себе хозяин, т.с.
-
Получится. Рисуйте верное правило и все получится.
И да, на скрине у Вас интерфейсное правило, а не плавающее - не то пальто.На самом деле небольшая разница интерфейсное или нет — все равно limiter=ipfw. И проблема в том что равномерно разделить канал между двумя пользователями он не сможет, поскольку работает обычный fifo буфер - соответственно кто больше посылает тот и получает больший приоритет.
-
Есть еще такой вариант
http://www.gridstorm.net/pfsense-traffic-limiting-fair-share/2 PbIXTOP
https://doc.pfsense.org/index.php/Limiters
limiter=dummynet
-
Есть еще такой вариант
http://www.gridstorm.net/pfsense-traffic-limiting-fair-share/2 PbIXTOP
https://doc.pfsense.org/index.php/Limiters
limiter=dummynet
По статье не понятно лимитеры создаются с какой маской? Тестировать к сожалению такую схему уже не смогу, отсутствует второй компьютер. Было интересно узнать — выдавит ли торрент трафик обычную закачку.
Ну а по dummynet думаю стоит пройти на страницу man'a.
Кстати причина не любви флоатинг правил для limiter, это как раз невозможность работать с NAT.
-
2 PbIXTOP
http://www.cs.unc.edu/~jeffay/dirt/FAQ/dummynet.backup.html
Повторюсь. Согласно оф. документации на его основе и работает limiter - https://doc.pfsense.org/index.php/Limiters