Много читал, но никак не пойму пару принципиальных моментов в работе PF:1. Если PF фильтрует только исходящий трафик, то почему в официальных примерах фигурируют строки типа "pass in", заворачивающие в очереди входящий трафик?
2. Как вообще понимать привязку очередей к конкретному интерфейсу, если в тех же примерах встречаются строки направления трафика одного интерфейса в очереди другого, чего он там будет ждать? Получается, что это не очередь интерфейса, а просто — очередь вообще. Тогда при чём тут интерфейс?
3. Не совсем понимаю следующие строки для дочерних очередей:
queue q1 bandwidth 50% priority 1 cbq(borrow red)
queue q2 bandwidth 50% priority 2 cbq(borrow red)
Кстати, без bandwidth эти строки не работают в FreeBSD (дают ошибку, и аналогичные официальные примеры — тоже). В такой записи непонятно, как это будет работать: то ли очередь q2, как имеющая более высокий приоритет, займёт хоть весь канал (тогда какой смысл в bandwidth?). То ли ей не дадут больше 50%, тогда какой смысл в priority?4. Режим ECN включает в себя RED или не совсем? В случае перегрузки он будет посылать только уведомления, или, если эти уведомления не помогают, начнёт отбрасывать пакеты? Если второе, то ECN выглядит предпочтительнее RED во всех случаях. Но во всех примерах почему-то используется RED. Может, на то есть причины?
Заранее спасибо за ответы!
>Много читал, но никак не пойму пару принципиальных моментов в работе PF:
>
>
>1. Если PF фильтрует только исходящий трафик, то почему в официальных примерах
>фигурируют строки типа "pass in", заворачивающие в очереди входящий трафик?
С чего Вы это взяли???
>
>2. Как вообще понимать привязку очередей к конкретному интерфейсу, если в тех
>же примерах встречаются строки направления трафика одного интерфейса в очереди другого,
>чего он там будет ждать? Получается, что это не очередь интерфейса,
>а просто — очередь вообще. Тогда при чём тут интерфейс?
Потому что пакеты идут через все интерфейсы.
>
>3. Не совсем понимаю следующие строки для дочерних очередей:
>queue q1 bandwidth 50% priority 1 cbq(borrow red)
>queue q2 bandwidth 50% priority 2 cbq(borrow red)
>Кстати, без bandwidth эти строки не работают в FreeBSD (дают ошибку, и
>аналогичные официальные примеры — тоже). В такой записи непонятно, как это
>будет работать: то ли очередь q2, как имеющая более высокий приоритет,
>займёт хоть весь канал (тогда какой смысл в bandwidth?). То ли
>ей не дадут больше 50%, тогда какой смысл в priority?
>
>4. Режим ECN включает в себя RED или не совсем? В случае
>перегрузки он будет посылать только уведомления, или, если эти уведомления не
>помогают, начнёт отбрасывать пакеты? Если второе, то ECN выглядит предпочтительнее RED
>во всех случаях. Но во всех примерах почему-то используется RED. Может,
>на то есть причины?
>
>Заранее спасибо за ответы!
Что-то не то Вы читали.
Почитайте вот это http://home.nuug.no/~peter/pf/en/.
>Что-то не то Вы читали.
>Почитайте вот это http://home.nuug.no/~peter/pf/en/.Почитал. Там лишь один из примеров немного относится к моему 1-му вопросу. В том плане, что там входящий трафик интерфейса направляется в очередь. Т.е. можно предположить, что фраза, неоднократно произносимая разными людьми в том числе и на этом форуме, о том, что ALTQ работает только с исходящими пакетами — неверна. Как и первое предложение из man: "The ALTQ framework provides several disciplines for queuing outgoing network packets." Странно всё это...
Ничего, касающегося остальных вопросов, в той статье не нашёл.
>>Что-то не то Вы читали.
>>Почитайте вот это http://home.nuug.no/~peter/pf/en/.
>
>Почитал. Там лишь один из примеров немного относится к моему 1-му вопросу.
>В том плане, что там входящий трафик интерфейса направляется в очередь.
>Т.е. можно предположить, что фраза, неоднократно произносимая разными людьми в том
>числе и на этом форуме, о том, что ALTQ работает только
>с исходящими пакетами — неверна. Как и первое предложение из man:
>"The ALTQ framework provides several disciplines for queuing outgoing network packets."
>Странно всё это...
>Ничего, касающегося остальных вопросов, в той статье не нашёл.там кругом keep-state.
если на in разрешен трафик, то надо записать стейт с очередью.
если входящий будет без keep-state, то стейт запишется правилом на out, что не совсем правильно
если входящий будет с keep-state но без очереди, то ответ так и останется без очереди.
>там кругом keep-state.
>если на in разрешен трафик, то надо записать стейт с очередью.
>если входящий будет без keep-state, то стейт запишется правилом на out, что
>не совсем правильно
>если входящий будет с keep-state но без очереди, то ответ так и
>останется без очереди.Ммм. Можно поподробнее про эти варианты, а то я не понял "стейт" :/
Как понимал, keep state открывает и ответное правило, т.е. и на вход и на выход. В очередь встанет соотв. правилу ИСХОДЯЩИЕ пакеты на том интерфейсе на котором очередь задана. Так же ?
И если так вопрос - раз получается при keep state два правила с одной очередью, то тогда в обе стороны не "пошейперишь" ?P.S. НЕ поможет ли кто с реальным примером (конфиг) решения такого куска задачи :
Все юзеры ходят через NAt. IP_Юзер_А надо при доступе на port 80 дать исходящие и входящие 22%, а IP_Юзер_Б на порт 80 входящего 44% и исходящего 10%.
Проблема тут у меня в Nat :( ? Не было бы его ... а так на ext_if IP_Юзер_А уже нет, NAt подменил IP. К чему б привязатся ?P.P.S. А пока что мало всё таки документации с нашими реальными примерами из жизни. Всё что ни искал - аналоги и переводы PF FAQ ...
>P.P.S. А пока что мало всё таки документации с нашими реальными примерами
>из жизни. Всё что ни искал - аналоги и переводы PF
>FAQ ...
>
Тут смотрели - http://lists.freebsd.org/mailman/listinfo/freebsd-pf.
>>там кругом keep-state.
>>если на in разрешен трафик, то надо записать стейт с очередью.
>>если входящий будет без keep-state, то стейт запишется правилом на out, что
>>не совсем правильно
>>если входящий будет с keep-state но без очереди, то ответ так и
>>останется без очереди.
>
>Ммм. Можно поподробнее про эти варианты, а то я не понял "стейт"
>:/
>Как понимал, keep state открывает и ответное правило, т.е. и на вход
>и на выход. В очередь встанет соотв. правилу ИСХОДЯЩИЕ пакеты на
>том интерфейсе на котором очередь задана. Так же ?
>И если так вопрос - раз получается при keep state два правила
>с одной очередью, то тогда в обе стороны не "пошейперишь" ?
>
>
>P.S. НЕ поможет ли кто с реальным примером (конфиг) решения такого куска
>задачи :
>
>Все юзеры ходят через NAt. IP_Юзер_А надо при доступе на port 80
>дать исходящие и входящие 22%, а IP_Юзер_Б на порт 80 входящего
>44% и исходящего 10%.
>Проблема тут у меня в Nat :( ? Не было бы его
>... а так на ext_if IP_Юзер_А уже нет, NAt подменил IP.
>К чему б привязатся ?
>Сложно, как-то все :). Низнаю, сам бы такого сразу не делал, посмотри в нат опцию тег, а потом в правилах на аут теггед добавлять в разны очереди, может и заработает, пробуй...
>P.P.S. А пока что мало всё таки документации с нашими реальными примерами
>из жизни. Всё что ни искал - аналоги и переводы PF
>FAQ ...
>
Тому и много переводов, что читать надо очень внимательно и каждое слово, в мане очень уж концентрированая информация, и каждый пункт проверять сразу как оно в деле работает.. :)
>Сложно, как-то все :). Низнаю, сам бы такого сразу не делал, посмотри
>в нат опцию тег, а потом в правилах на аут теггед
>добавлять в разны очереди, может и заработает, пробуй...Tag не катит в принципе. Правила с tag и tagged требуют keep state, которое создаёт обратное разрешающее правило (выполняемое вперёд других) для ответного трафика, НЕ привязанного ни к какой очереди, а потому ничем не ограниченного.
Так что для фильтрации в двух направлениях tag и tagged не подходят.
>>Сложно, как-то все :). Низнаю, сам бы такого сразу не делал, посмотри
>>в нат опцию тег, а потом в правилах на аут теггед
>>добавлять в разны очереди, может и заработает, пробуй...
>
>Tag не катит в принципе. Правила с tag и tagged требуют keep
>state, которое создаёт обратное разрешающее правило (выполняемое вперёд других) для ответного
>трафика, НЕ привязанного ни к какой очереди, а потому ничем не
>ограниченного.
>Так что для фильтрации в двух направлениях tag и tagged не подходят.
>особенно, если учесть, что нат - ето уже keep state, хотя могло б и работать, в man authpf похожий пример есть.
nat on rl0 from 192.168.4.0/24 to 172.16.2.34 tag NATTED -> 172.16.2.21
pass out log quick on rl0 tagged NATTED keep statepyvo# pfctl -vss
No ALTQ support in kernel
ALTQ related functions disabled
self tcp 192.168.4.198:36315 -> 172.16.2.21:64655 -> 172.16.2.34:80 FIN_WAIT_2:FIN_WAIT_2
[3158812003 + 16940] wscale 4 [1401457460 + 6880] wscale 0
age 00:00:15, expires in 00:01:21, 6:5 pkts, 324:496 bytes, rule 1
>особенно, если учесть, что нат - ето уже keep state,
Он внутри машины, поэтому его state файрвола не касается. ;)>хотя могло б и работать, в man authpf похожий пример есть.
>nat on rl0 from 192.168.4.0/24 to 172.16.2.34 tag NATTED -> 172.16.2.21
>pass out log quick on rl0 tagged NATTED keep state
Зачем в NAT делать tag не совсем понятно. Но суть не меняется: можно на внутреннем интерфейсе на входящие от пользователя пакеты ставить tag и различать их на внешнем по этому tag'у, направляя в соответствующие очереди пользователей и ограничивая исходящую скорость:pass in quick on $int_if from $user1 to any tag U1 keep state
pass out quick on $ext_if inet proto {tcp udp icmp} tagged U1 keep state queue q1Оба правила требуют keep statе, которые создают разрешающие правила для ответного трафика без привязки к очереди, скорость которого не ограничивается. И сделать с этим, по-видимому, ничего нельзя, поскольку эти правила имеют приоритет над всеми остальными.
>>там кругом keep-state.
>>если на in разрешен трафик, то надо записать стейт с очередью.
>>если входящий будет без keep-state, то стейт запишется правилом на out, что
>>не совсем правильно
>>если входящий будет с keep-state но без очереди, то ответ так и
>>останется без очереди.
>
>Ммм. Можно поподробнее про эти варианты, а то я не понял "стейт"
>:/
>Как понимал, keep state открывает и ответное правило, т.е. и на вход
>и на выход. В очередь встанет соотв. правилу ИСХОДЯЩИЕ пакеты на
>том интерфейсе на котором очередь задана. Так же ?
>И если так вопрос - раз получается при keep state два правила
>с одной очередью, то тогда в обе стороны не "пошейперишь" ?
>
>
>P.S. НЕ поможет ли кто с реальным примером (конфиг) решения такого куска
>задачи :
>
>Все юзеры ходят через NAt. IP_Юзер_А надо при доступе на port 80
>дать исходящие и входящие 22%, а IP_Юзер_Б на порт 80 входящего
>44% и исходящего 10%.
>Проблема тут у меня в Nat :( ? Не было бы его
>... а так на ext_if IP_Юзер_А уже нет, NAt подменил IP.
>К чему б привязатся ?
>
>P.P.S. А пока что мало всё таки документации с нашими реальными примерами
>из жизни. Всё что ни искал - аналоги и переводы PF
>FAQ ...
>
В результате недели поисков я нашёл лишь два способа делать NAT и шейпинг в ДВУХ направлениях на одной машине:1. Делать NAT пользователя на конкретный диапазон портов. Тогда на внешнем интерфейсе трафик с этих портов можно заворачивать в очередь пользователя. Входящий трафик шейпится на внутреннем интерфейсе обычным образом. Именно таким образом сейчас работает шлюз у меня. Есть одно неудобство — icmp. Как я понял, он вообще не привязан к портам и NAT, тем не менее, NAT его отправляет всегда на чёрт знает какой порт (так это выглядит в таблице NAT). Соответственно, для него нужно делать отдельные правила NAT, отдельную очередь и этот трафик (точнее — исходящую в инет его часть) привязать к очереди пользователя нельзя.
Подробнее способ NAT'а по портам описан в книге Building Firewalls With OpenBSD And PF, 2nd Edition, рекомендованной на сайте OpenBSD, и которую можно найти в сети без проблем. Если нужно, вечером могу привести свой конфиг.2. Второй способ опиан тут: http://freebsd.so14k.com/pf+nat+altq.shtml
В одном компе — 4 сетевые карты: две работают как мост, две оставшиеся — как шлюз с NAT. На мосту осуществляется фильтрация и шейпинг, на шлюзе — только NAT. Соответственно, две карты этого компа соединены патчкордом. Представляете внешний вид? ;) Идиотизм полнейший, но — работает.
Есть подозрение, что через ipfw и pipes двунаправленный шейпинг и NAT на одной машине делаются без проблем. Самому интересно: так ли это?P.S. Ещё обнаружил, что режиме CBQ не работает borrow на FreeBSD. Не знаю, связано ли это с оборудованием, но такая проблема встречается не только у меня, причём давно уже, и люди говорили, что это, должно быть, баг. И до сих пор не пофиксили...
Выход — использовать HFSC. В принципе, он по всем статьям переплёвывает CBQ, не знаю только, как по производительности. Думаю, что PF и ALTQ перенести на FreeBSD именно из-за HFSC (его кругом хвалят), поэтому на баги CBQ всем плевать и их не фиксят. Раз так, то нужно пользоваться HFSC.
>В результате недели поисков я нашёл лишь два способа делать NAT и
>шейпинг в ДВУХ направлениях на одной машине:
>
>1. Делать NAT пользователя на конкретный диапазон портов. Тогда на внешнем интерфейсе
>трафик с этих портов можно заворачивать в очередь пользователя. Входящий трафик
>шейпится на внутреннем интерфейсе обычным образом. Именно таким образом сейчас работает
>шлюз у меня. Есть одно неудобство — icmp. Как я понял,
>он вообще не привязан к портам и NAT, тем не менее,
>NAT его отправляет всегда на чёрт знает какой порт (так это
>выглядит в таблице NAT). Соответственно, для него нужно делать отдельные правила
>NAT, отдельную очередь и этот трафик (точнее — исходящую в
>инет его часть) привязать к очереди пользователя нельзя.
>Подробнее способ NAT'а по портам описан в книге Building Firewalls With OpenBSD
>And PF, 2nd Edition, рекомендованной на сайте OpenBSD, и которую можно
>найти в сети без проблем. Если нужно, вечером могу привести свой
>конфиг.
>
>2. Второй способ опиан тут: http://freebsd.so14k.com/pf+nat+altq.shtml
>В одном компе — 4 сетевые карты: две работают как мост, две
>оставшиеся — как шлюз с NAT. На мосту осуществляется фильтрация и
>шейпинг, на шлюзе — только NAT. Соответственно, две карты этого компа
>соединены патчкордом. Представляете внешний вид? ;) Идиотизм полнейший, но — работает.
>
А чего ж ему не работать то, но не идиотизмом от этого он не становится :)
>P.S. Ещё обнаружил, что режиме CBQ не работает borrow на FreeBSD. Не
>знаю, связано ли это с оборудованием, но такая проблема встречается не
>только у меня, причём давно уже, и люди говорили, что это,
>должно быть, баг. И до сих пор не пофиксили...
У меня работает, причём двухуровневый. Если родительская очередь не полностью загружена забирает у неё излишки и в свою очередь та родительская берёт у своего родителя таким же макаром.
Может твоя сетевушка не полность ALTQ поддериживает ? Там от железа сильно зависит, есть список поддерживаемого оборудования, всё что не в нём с ALTQ не заработает :(
>Выход — использовать HFSC. В принципе, он по всем статьям переплёвывает CBQ,
>не знаю только, как по производительности. Думаю, что PF и ALTQ
>перенести на FreeBSD именно из-за HFSC (его кругом хвалят), поэтому на
>баги CBQ всем плевать и их не фиксят. Раз так, то
>нужно пользоваться HFSC.
Есть ссылки про него и конкретные примеры, желательно по русски почитать ?
>Может твоя сетевушка не полность ALTQ поддериживает ? Там от железа сильно
>зависит, есть список поддерживаемого оборудования, всё что не в нём с
>ALTQ не заработает :(
Я тоже думал на сетевые карты, поэтому купил две Intel PILA 8460B (Intel® 82559) PRO/100+ PCI manageble 10/100 OEM. Вроде очень известная сетевая карта и поддерживается FreeBSD. Но — вот облом — аппаратная проверка контрольных сумм вроде бы не работает. Во всяком случае автоматом она не включилась, а строка "ifconfig fxp0 rxcsum txcsum" пишет ошибку...>>Выход — использовать HFSC. В принципе, он по всем статьям переплёвывает CBQ,
>>не знаю только, как по производительности. Думаю, что PF и ALTQ
>>перенести на FreeBSD именно из-за HFSC (его кругом хвалят), поэтому на
>>баги CBQ всем плевать и их не фиксят. Раз так, то
>>нужно пользоваться HFSC.
>Есть ссылки про него и конкретные примеры, желательно по русски почитать ?Тут конкретный пример, где заменили CBQ очереди на HFSC: http://lists.freebsd.org/pipermail/freebsd-pf/2006-March/001... из-за того, что в CBQ не работал borrow. Кстати, эта ссылка находится первой в гугле по словам "CBQ borrow".
Ещё много полезного есть в той книге (её единственную официально рекомендуют на сайте OpenBSD, что о многом говорит), там же есть примеры одинаковых очередей, написанных с CBQ и HFSC. Найти её можно на torrentspy.com.
Ничего более подробного по HFSC я пока не видел. Есть какие-то тексты на русском, которые по сути — переводы английской документации на русский, поэтому понимания они не добавляют.
>>Может твоя сетевушка не полность ALTQ поддериживает ? Там от железа сильно
>>зависит, есть список поддерживаемого оборудования, всё что не в нём с
>>ALTQ не заработает :(
>Я тоже думал на сетевые карты, поэтому купил две Intel PILA 8460B
>(Intel® 82559) PRO/100+ PCI manageble 10/100 OEM. Вроде очень известная сетевая
>карта и поддерживается FreeBSD.
Да то что она поддерживается FreeBSD это самом собой, самое начальное и незначительное, если таковым можно считать будет сеть работать или нет :)
А по ДАННОМУ ВОПРОСУ я писал поддерживается ли она ALTQ! У неё отдельный список поддерживаемого оборудования, причём гораздо менее общирный чем у FreeBSD.
>А по ДАННОМУ ВОПРОСУ я писал поддерживается ли она ALTQ! У неё
>отдельный список поддерживаемого оборудования, причём гораздо менее общирный чем у FreeBSD.
>
Да, драйвер fxp поддердивается ALTQ (внизу страницы): http://www.freebsd.org/cgi/man.cgi?query=altq&apropos=0&sekt...Прочитал заодно про включение аппаратного расчёта контрольных сумм на сетевой карте:
rxcsum, txcsum
If the driver supports user-configurable checksum offloading,
enable receive (or transmit) checksum offloading on the inter-
face. Some drivers may not be able to enable these flags inde-
pendently of each other, so setting one may also set the other.
The driver will offload as much checksum work as it can reliably
support, the exact level of offloading varies between drivers.
Может, у меня эта поддержка включена по умолчанию и просто не user-configurable, а всегда включена? Иначе непонятно, почему она не включается...
Опс, не сразу заметил другие ответы:
>>1. Если PF фильтрует только исходящий трафик, то почему в официальных примерах
>>фигурируют строки типа "pass in", заворачивающие в очереди входящий трафик?
>С чего Вы это взяли???
На всякий случай: я под "фильтрует" имел ввиду очереди ALTQ. Везде пишут, что принятый на интерфейс пакет уже нельзя поставить в очередь на приём, т.к. он принят (и с этим трудно спорить ;). Об этом же пишут в man: The ALTQ framework provides several disciplines for queuing outgoing net work packets. При этом я в примерах встречаю строки типа "pass in ... queue ...", которые противоречат этим описаниям, т.к. ставят в очередь входящие пакеты, которые "уже приняты".>>2. Как вообще понимать привязку очередей к конкретному интерфейсу, если в тех
>>же примерах встречаются строки направления трафика одного интерфейса в очереди другого,
>>чего он там будет ждать? Получается, что это не очередь интерфейса,
>>а просто — очередь вообще. Тогда при чём тут интерфейс?
>Потому что пакеты идут через все интерфейсы.
Всё равно непонятно. Если они идут через все интерфейсы, какая разница, на каком интерфейсе организовывать очередь? В чём вообще тогда смысл привязки очереди к интерфейсу? Получается, что это просто некая абстрактная очередь, организованная хоть на отключённом интерфейсе, хоть вообще не на интерфейсе, в которую пакеты могут направляться с любых интерфейсов подождать своей очереди и отправиться дальше по маршруту с какого угодно интерфейса. Так?
Отвечу сам себе на некоторые вопросы, вдруг кому пригодится ;)>1. Если PF фильтрует только исходящий трафик, то почему в официальных примерах
>фигурируют строки типа "pass in", заворачивающие в очереди входящий трафик?
>2. Как вообще понимать привязку очередей к конкретному интерфейсу, если в тех
>же примерах встречаются строки направления трафика одного интерфейса в очереди другого,
>чего он там будет ждать? Получается, что это не очередь интерфейса,
>а просто — очередь вообще. Тогда при чём тут интерфейс?
Да, PF ставит в очереди только исходящие пакеты, поэтому работать будут только правила pass out и pass in вообще лишены смысла за одним лишь важным исключением: если известно, что пакет пойдёт через другой интерфейс, то можно входящий пакет на первом интерфейсе направить пакет в очередь второго: "pass in ... queue ...". Тогда пакет, достигнув второго интерфейса, попадёт в его исходящую очередь. Об этом написано в описаниях PF и указано, что всё это важно для мостов (bridge). Думаю, для них это исключение специально и сделали, поскольку оно позволяет огранизовать шейпинг трафика в двух направлениях.
Важное замечание: это НЕ будет работать в случае шлюза с NAT. Потому что NAT меняет порты, в результате чего идентифицировать изменённый пакет на внешнем интерфейсе становится невозможно.>3. Не совсем понимаю следующие строки для дочерних очередей:
>queue q1 bandwidth 50% priority 1 cbq(borrow red)
>queue q2 bandwidth 50% priority 2 cbq(borrow red)
>Кстати, без bandwidth эти строки не работают в FreeBSD (дают ошибку, и
>аналогичные официальные примеры — тоже). В такой записи непонятно, как это
>будет работать: то ли очередь q2, как имеющая более высокий приоритет,
>займёт хоть весь канал (тогда какой смысл в bandwidth?). То ли
>ей не дадут больше 50%, тогда какой смысл в priority?
Это я и сейчас смутно понимаю, поскольку borrow в CBQ у меня не работает (и не только у меня). Возможно, каждая из очередей займёт 50%, но в случае появления дополнительной пропускной способности у родительской очереди, очередь с большим приоритетом заберёт её себе.>4. Режим ECN включает в себя RED или не совсем? В случае
>перегрузки он будет посылать только уведомления, или, если эти уведомления не
>помогают, начнёт отбрасывать пакеты? Если второе, то ECN выглядит предпочтительнее RED
>во всех случаях. Но во всех примерах почему-то используется RED. Может,
>на то есть причины?
ECN — вещь дополнительная к RED, если посмотреть правило с ECN, то оно ракрывается pfctrl как RED ECN. Т.е. и RED, и ECN одновременно. Далее ясности нет, но можно предположить, что ECN будет те пакеты, которые RED хотел бы выкинуть, оставлять в очереди и вместо этого высылать предложения снизить скорость. Или другой вариант, который мне кажется более вероятным: ECN сработает чуть раньше RED. Т.е. попытается предотвратить ситуацию, когда RED выкинет пакет. Если так, то вреда от ECN никакого, кроме, может, потребления ресурсов.
Вопрос про очереди - просматривая их статус видны такие показатели -
DROP_P DROP_B QLEN BORR SUSP
Что такое SUSP и из за чего они "замораживаются" ?
>Вопрос про очереди - просматривая их статус видны такие показатели -
>DROP_P DROP_B QLEN BORR SUSP
>Что такое SUSP и из за чего они "замораживаются" ?
А как просматриваются очереди? У меня в freebsd многие вызовы статистики через pfctl не выводят вообще никакого результата (ошибки тоже не дают).
Оказывается, есть простой способ сделать шейпинг в двух направлениях с NAT (спасибо, на другом форуме подсказали). В официальном примере этот важный момент описан одной строчкой между делом и больше нигде не встречается: Note that even though the queue keyword is being used on a rule filtering incoming traffic, the goal is to specify a queue for the corresponding outgoing traffic; the above rule does not queue incoming packets. Суть в том, что в pass in можнно писать queue, ссылаясь на очередь того же самого интерфейса. При этом в очередь будет поставлен ответный трафик через этот интерфейс.В результате правила для каждого пользователя выглядят примерно так:
pass in quick on $int_if from $user1 to any tag U1 queue q1_in keep state
pass out quick on $ext_if from $ext_if to any tagged Q1 queue q1_ex keep stateВсё это работает через NAT! В первом правиле шейпится входящий к пользователю из инета ответный трафик, который направляется в очередь q1_in на внутреннем интерфейсе. Кроме того, в этом же правиле всем входящим от пользователя пакетам присваевается метка U1. Во втором — шейпится исходящий, который распознаётся по метке и направляется в очередь q1_ex на внешнем интерфейсе.
>Оказывается, есть простой способ сделать шейпинг в двух направлениях с NAT (спасибо,
>на другом форуме подсказали)..
&
>>Проблема тут у меня в Nat :( ? Не было бы его
>>... а так на ext_if IP_Юзер_А уже нет, NAt подменил IP.
>К чему б привязатся ?
>>
>Сложно, как-то все :). Низнаю, сам бы такого сразу не делал, посмотри в нат опцию тег, а >потом в правилах на аут теггед добавлять в разны очереди, может и заработает, пробуй...Подсказали то как раз тут :) На bsdportal ты просто конфиг готовый чей то увидел.
>pass in quick on $int_if from $user1 to any tag U1 queue
>q1_in keep state
>pass out quick on $ext_if from $ext_if to any tagged Q1 queue
>q1_ex keep state
>
>Всё это работает через NAT! В первом правиле шейпится входящий к пользователю
>из инета ответный трафик, который направляется в очередь q1_in на внутреннем
>интерфейсе.Не так всё однозначно, это частный случай, а что б понять где именно в очередь станет и станет ли вообще, надо не только правила фильтров, но и очереди настройки смотерь в конфиге ;)
>Не так всё однозначно, это частный случай, а что б понять где
>именно в очередь станет и станет ли вообще, надо не только
>правила фильтров, но и очереди настройки смотерь в конфиге ;)Так я написал словами, на каких интерфейсах какие очереди.