> хм.. по идее эта переменная ни на что не влияет, кроме как
> на пайпы dummynet и узлы ng_ipfw Эта переменная влияет на правила nat так же как и на правила dummynet.
И эти правила с переменной sysctl net.inet.ip.fw.one_pass=1 работать у вас не будут, хотя вы сказали, что "проверено".
> возможно я и сам тумана напустил в комментах в своём примере ))
Что есть, то есть. И еще вы ни разу не разбирались в том, о чем писал я.
> в данном листинге в конфигурации nat отсутствует deny_in
> это принципиально, в противном случае не будет работать секция для входящего трафика
> (не редиректа, он будет продолжать работать, как верно было подмечено выше)
Секция для входящего трафика будет работать с параметром deny_in, если к конфигурации nat добавить параметр "redirect_port tcp 1.2.3.4:22 22 redirect_port tcp 1.2.3.4:80 80" и т.д...
> если хочется сохранить deny_in то нужно секцию правил для входящего трафика (700-703)
> разместить выше правила 300 для nat входящих пакетов
> например под номерами 250-253
.. и не нужно будет портить структуру конфига
> ограничение скорости лучше реализовать после того как будут отфильтрованы ненужные пакеты,
> а уж потом нарезать полосы пропускания у оставшихся
Ограничение скорости можно даже организовать в обе стороны. Структура конфига об этом "кричит".
> можешь поиграться с net.inet.ip.fw.one_pass повключть и повыключать его прямо из листинга,
> после сброса правил,
> но повторюсь, без пайпов это ни на что не влияет
Правила эти будут работать при условии, что переменная sysctl net.inet.ip.fw.one_pass=0.
В оригинальном примере правил из хэндбука об этом ничего не говорится, т.к. там используется демон natd и не используется dummynet (который, к слову сказать, как и "ipfw nat", работает в ядре), а sysctl net.inet.ip.fw.one_pass дефолтно равна 1.
