Убил выходные, но так и не получилось.
Решил разобраться с pf, т.к. появилась необходимость в использовании altq.
Сразу, знание ipfw, сыграло злую шутку из-за включенного по умолчанию keep state во всех правилах pf. В слествии этого не работают все примеры нарытые в инете. Быстрое курение манов по pf не спасло. Более тщательное курение манов дало заветный ключ no state (который не описывается отдельно в опциях управления состоянием и только один раз упоминается в тексте и при беглом просмотре просто не заметен) и то, что при входящем пакете, если для него есть запись в таблице состоаний, то он сразу пропускается минуя все правила. Т.е. по-умолчанию если клиент инициализирует соединение, то пакет попадает под правило:
pass in on $int_if from $net to any
Делается запись в таблице состояний и теперь даже исходящий в локалку трафик будет идти через это правило, т.е. на правиле:
pass out on $int_if from any to $net
будет 0.
Такой вариант не дает возможность резать исходящий к клиенту трафик с помощью altq.
Использование no state дало контроль над исходящими пакетами внутреннего интерфеса и применения к нему altq.
Всё заработало, причем довольно хорошо.
Радость от работы закончиласть когда редиректом завернул весь http трафик на squid. Опять таки в манах есть упоминание того, что nat, binat и rdr также содержат keep state по-умолчанию. Т.е. опять получется так, что при редиректе на squid делается запись в таблицу состояния и весть траф от прокси идет чере входящее правило на внутреннем интерфейсе. И вот тут засада: в rdr нету опций отключения keep state.
Ну вот собственно и вопрос: как сделать редирект на прокси и при этом получить контроль над выходящим трафиком с внутреннего интерфейса?
Т.е. вы хотите сказать что altq не пашет с keep state?
>Т.е. вы хотите сказать что altq не пашет с keep state?Ну, глобально, работает, но не так как надо.
Как я говорил, при наличии keep state на внутреннем интерфейсе, получается так, что входящий и исходящий трафик от/к клиенту проходит через одно правило. И при включении altq на внутреннем интерфейсе получается так, что весь трафик проходит через queue, а нам надо только исходящий к клиенту трафик направить в эту очередь.
Конечно, в большинстве случаев, это не так страшно, но если есть 2 канала наружу и исходящая скорость одного больше входящей другого, то тут будет засада.