Traffic Sharper (Voip, Squid, etc)
-
Пытаюсь разобраться с сабжем.
имеется 1 сеть LAN и 1 интернет WAN (скриншоты ниже)
В настройках шарпера поставил по дефолту P2P (чтобы все левые пакеты кидались именно туда)Возникли следующие вопросы:
1. по умолчанию через мастер создаются правила только для выходного интерфейса WAN.
Соответственно для телефонии Asterisk следует прописать правила не только на выход WAN, но и на вход WAN + вх/выход LAN ?
потому как иначе , при звонках извне или изнутри то на WAN то на LAN Queryes пакеты бросяются в P2P.кстати, чтобы торренты не опазнавались как VOIP, пришлось прописать бан торрентов в Layer 7 и добавить в плавающее PASS правило (вторая строчка на скриншоте). Теперь торрент верно падают в P2P
2. т.к. установлен Squid, верно ли прописано первое правило во Floating Rules?
3. стоит ли так же добавлять новые Floating Rules для пингов, DNS запросов и прочего , или хватит правил только для для выходного WAN, которые поставились по умолчанию?
-
2. т.к. установлен Squid, верно ли прописано первое правило во Floating Rules?
ИМХО, первое правило - лишнее. У вас уже есть правило ,касающееся HTTP (80\tcp). И по аналогии, я бы добавил правило и с HTTPS (443\tcp).
Плюс, если вам важен ping , то в числе первых правил начиная снизу , нужно правило, касающееся ICMP.3. стоит ли так же добавлять новые Floating Rules для пингов, DNS запросов и прочего , или хватит правил только для для выходного WAN, которые поставились по умолчанию?
Стоит , однозначно для DNS, ICMP уж точно.
Соответственно для телефонии Asterisk следует прописать правила не только на выход WAN, но и на вход WAN + вх/выход LAN ?
потому как иначе , при звонках извне или изнутри то на WAN то на LAN Queryes пакеты бросяются в P2P.В визарде шейпера точно есть настройки для Voip. И даже с гарантированной скоростью приема-передачи.
Правила в шейпере работают снизу вверх , т.е. снизу самые приоритетные.
P.s. Шейпер в pf работает только для внешнего интерфейса . Правила на LAN (qInternet) - это входящий в WAN трафик, правила на WAN - уходящий из WAN во вне (от клиентов из LAN). Почитайте - http://pfsensesetup.com/pfsense-traffic-shaping-part-one/ , http://pfsensesetup.com/traffic-shaping-rules-in-pfsense-2-1/
P.p.s. После отработки визарда создается много правил - оставьте только нужные вам. Остальные - отключите\удалите. И всегда после изменений в шейпере делайте Reset states!
-
3. стоит ли так же добавлять новые Floating Rules для пингов, DNS запросов и прочего , или хватит правил только для для выходного WAN, которые поставились по умолчанию?
Стоит , однозначно для DNS, ICMP уж точно.
так достаточно одного правила (я указал в ниже скриншоте) для ICMP для WAN интерфейса? или нужен такой же для LAN?
Соответственно для телефонии Asterisk следует прописать правила не только на выход WAN, но и на вход WAN + вх/выход LAN ?
потому как иначе , при звонках извне или изнутри то на WAN то на LAN Queryes пакеты бросяются в P2P.В визарде шейпера точно есть настройки для Voip. И даже с гарантированной скоростью приема-передачи.
мастер создает два правила с WAN интерфейсами с destination по портам 5060-5069, 10000-20000
я специально смотрел Status->Queries при звонках и траффик обрабатывался как VOIP и в LAN и в WAN только, когда я прописал дополнительные 3 правила, которые прописаны на вышестоящем скриншоте.Правила в шейпере работают снизу вверх , т.е. снизу самые приоритетные.
странно. а вот тут http://forum.pfsense.org/index.php/topic,33870.msg175827.html#msg175827 написано наоборот
"Правила FloatingRules
Списки FloatingRules так же просматриваются сверху вниз, пока не будет достигнут конец списка или просмотр не будет прерван на подходящем правиле с опцией Quick. При встрече подходящих правил без опции Quick будет применено каждое из них и просмотр будет продолжен дальше до конца списка. Здесь без использования опции Quick сначала следует располагать более общие правила, а затем уже более конкретные."P.s. Шейпер в pf работает только для внешнего интерфейса . Правила на LAN (qInternet) - это входящий в WAN трафик, правила на WAN - уходящий из WAN во вне (от клиентов из LAN). Почитайте - http://pfsensesetup.com/pfsense-traffic-shaping-part-one/ , http://pfsensesetup.com/traffic-shaping-rules-in-pfsense-2-1/
т.е. все правила во Floating Rules должны относится только к WAN интерфейсу?
-
Правила в шейпере работают снизу вверх , т.е. снизу самые приоритетные.
странно. а вот тут http://forum.pfsense.org/index.php/topic,33870.msg175827.html#msg175827 написано наоборот
"Правила FloatingRules
Списки FloatingRules так же просматриваются сверху вниз, пока не будет достигнут конец списка или просмотр не будет прерван на подходящем правиле с опцией Quick. При встрече подходящих правил без опции Quick будет применено каждое из них и просмотр будет продолжен дальше до конца списка. Здесь без использования опции Quick сначала следует располагать более общие правила, а затем уже более конкретные."В Floating Rules без опции Quick применяется самое последнее подходящее. Возможно это имелось ввиду "снизу вверх". Просмотр любых правил в pfSense однозначно идет сверху вниз.
P.s. Шейпер в pf работает только для внешнего интерфейса . Правила на LAN (qInternet) - это входящий в WAN трафик, правила на WAN - уходящий из WAN во вне (от клиентов из LAN). Почитайте - http://pfsensesetup.com/pfsense-traffic-shaping-part-one/ , http://pfsensesetup.com/traffic-shaping-rules-in-pfsense-2-1/
т.е. все правила во Floating Rules должны относится только к WAN интерфейсу?
Нет, это не совсем так.
Шейпер работает только на отправляемый с интерфейса трафик. И это физически правильно. Невозможно задержать уже полученный трафик. Можно задержать только отправку трафика. В pfSense шейпится трафик исходящий с интерфейсов наружу.
То есть на WAN регулируется отправляемый в интернет трафик, а на LAN получаемый пользователями трафик из интернет.Вот к примеру:
1. Браузер отправляет запрос на WWW сервер. Запрос на скорости 100 Мбит получается интерфейсом LAN, так же быстро передаётся на интерфейс WAN. На интерфейсе WAN запрос попадает в некоторую очередь и ждет своего момента отправления. ЭТО исходящий трафик от пользователя в интернет.
2. Сервер WWW в интернете получив запрос отправляет ответ. Ответ приходит на WAN pfSense со скоростью ADSL соединения 8 Мегабит. Получив пакет интерфейс WAN быстро передает его интерфейсу LAN, где пакет помещается в очередь и ожидает своего момента отправления локальному пользователю. ЭТО входящий трафик из интернета к локальному пользователю.При настройке очередей лучше всего использовать процентные соотношения от вышестоящей очереди. Это позволит очень гибко управлять настройками (например будет просто поменять настройку скорости внешнего подключения).
И Floating Rules по умолчанию не привязаны к какому либо интерфейсу (хотя опция есть).
-
В Floating Rules без опции Quick применяется самое последнее подходящее. Возможно это имелось ввиду "снизу вверх". Просмотр любых правил в pfSense однозначно идет сверху вниз.
соответственно, если в самом верху будет стоять правило, допустим, на 80 порт без Quick - с очередью qACK/qOthersDefault, а ещё ниже такое же правило но с очередью qACK/qOthersHigh - то в итоге будет использоваться второе правило. А если стоит Quick, то первое?
опять же Layer7 в Floation Rules можно использовать только с опцией Action - Pass(вместо Match). т.е. в первом правиле на 80 порт я поставил Pass c layer7 по httpaudio/httpvideo (чтобы именно этим потоковым пакетам выдавалась очередь qACK/qOthersLow) а как раз второе правило срабатывало по остальному.
Шейпер работает только на отправляемый с интерфейса трафик. И это физически правильно. Невозможно задержать уже полученный трафик. Можно задержать только отправку трафика. В pfSense шейпится трафик исходящий с интерфейсов наружу.
То есть на WAN регулируется отправляемый в интернет трафик, а на LAN получаемый пользователями трафик из интернет.Вот к примеру:
1. Браузер отправляет запрос на WWW сервер. Запрос на скорости 100 Мбит получается интерфейсом LAN, так же быстро передаётся на интерфейс WAN. На интерфейсе WAN запрос попадает в некоторую очередь и ждет своего момента отправления. ЭТО исходящий трафик от пользователя в интернет.
2. Сервер WWW в интернете получив запрос отправляет ответ. Ответ приходит на WAN pfSense со скоростью ADSL соединения 8 Мегабит. Получив пакет интерфейс WAN быстро передает его интерфейсу LAN, где пакет помещается в очередь и ожидает своего момента отправления локальному пользователю. ЭТО входящий трафик из интернета к локальному пользователю.т.е. в случае с тем же 80-м портом или ICMP, должны быть правила и для WAN интерфейса и для LAN?
И Floating Rules по умолчанию не привязаны к какому либо интерфейсу (хотя опция есть).
сам визард делает все правила привязанные именно к WAN интерфейсу, который нельзя потом отменить, а только поменять на LAN.
Т.е. после создания через визард и редактирования правил, насколько я понимаю, их надо тупо копировать и менять интерфейсы с WAN на LAN?
или возможны ещё заморочки со сменой портов в случае LAN интерфейса с Destanation на Source? -
сам визард делает все правила привязанные именно к WAN интерфейсу, который нельзя потом отменить, а только поменять на LAN.
Т.е. после создания через визард и редактирования правил, насколько я понимаю, их надо тупо копировать и менять интерфейсы с WAN на LAN?Очереди после визарда нужно тупо копировать на нужные интерфейсы. Если на интерфейсе нет очереди с нужным именем, то нет и шейпинга на этом интерфейсе для трафика, загоняемого в данную очередь.
-
2 dvserg
Спасибо за науку.P.s. Могли бы вы выложить скрин со своими правилами Floating rules, т.с. для полного понимания. Заранее благодарен.
P.p.s. Гляньте свои ЛС (если еще не смотрели со вчерашнего дня)
-
2 dvserg
Спасибо за науку.P.s. Могли бы вы выложить скрин со своими правилами Floating rules, т.с. для полного понимания. Заранее благодарен.
Присоединяюсь к просьбе :)
-
подымаю тему с целью узнать как всё таки лучше сделать правило на 10000-20000 порты (RTP VOIP протокол), чтобы под него не попадал торрентовый траффик?
я пока решил проблемму с помощью создания Layer 7 правила для bittorrent протокола (block) и добавления его в Floating Rules с опцией PASS для данных портов - но при этом учитывая что Pfsensу приходится теперь просматривать заголовок кажого пакета, его производительность оч сильно снизилась….
при этом торрент траффик, идущий по любым другим портам должен идти в соответствии с другим правилом...., т.е. не блокироваться как в случае с 10000-20000
-
Спасибо Всем, Отличная статья для понимания всего происходящего с шейпингом.
-
ipfw-classifyd reloading сам по себе в любое время
Mar 30 17:23:21 ipfw-classifyd: Reloading config…
Mar 30 17:23:21 ipfw-classifyd: Reloading config...
Mar 30 17:23:21 ipfw-classifyd: Loaded Protocol: bittorrent (rule action block)
Mar 30 17:23:21 ipfw-classifyd: Loaded Protocol: sip (rule altq)
Mar 30 17:23:21 ipfw-classifyd: Loaded Protocol: skypeout (rule altq)
Mar 30 17:23:21 ipfw-classifyd: Loaded Protocol: skypetoskype (rule altq)Mar 30 17:23:51 ipfw-classifyd: Reloading config...
Mar 30 17:23:51 ipfw-classifyd: Reloading config...
Mar 30 17:23:51 ipfw-classifyd: Loaded Protocol: bittorrent (rule action block)
Mar 30 17:23:51 ipfw-classifyd: Loaded Protocol: sip (rule altq)
Mar 30 17:23:51 ipfw-classifyd: Loaded Protocol: skypeout (rule altq)
Mar 30 17:23:51 ipfw-classifyd: Loaded Protocol: skypetoskype (rule altq)При этом стало все очевидно почему такиой большой Ping и обрывается канал
https://forum.pfsense.org/index.php?topic=73950.0
Может у кого такжеДля чего нужна это синхронизация, и нужна ли вообще так часто, каким образом исправить. Layer7 при этом необхдим. Он работает в Floating
