Несколько вопросов по ipfw + kernel nat

[suspender]

one_pass = 0 (вообще где то читал, что в 8.1 one_pass всегда 0)

1. Почему может не работать конструкция :

Код: Выделить всё

ipfw add nat 1 ip from $lan to any out via $if_ext
ipfw add nat 1 ip from any to $ip_ext in via $if_ext

Вариации с xmit, recv тоже не пахают. Приходится пользоваться конструкцией

Код: Выделить всё

ipfw add nat 1 ip from any to any via $if_ext

Соответственно, nat приходится конфигать с deny_in. И вот тут след вопрос.
2. ЧТо происходит с пакетом попавшим в nat с deny_in извне ? Он блокируется наглухо ? или тупо nat с ним ничего не делает и он идёт дальше по правилам ? (кажется мне что наглухо блокируется, если в таблице ната нет соответствующей записи).
Далее, как разделить траффик инициированный самим шлюзом от трафика лок сети ? (ну то есть не отправлять в нат, то, что не должно туда итти ?). У меня пока мысль использовать что то типа

Код: Выделить всё

ipfw add check-state
ipfw add allow ip from me to any out xmit $if_ext setup keep-state

Как теперь сделать, чтобы трафик вышедший из nata, уже замаскараденный не попадал под это правило ?
Есть ли в ipfw конструкция чтобы проверить, что у пакета нет заданного тага ? чтобы можно было сделать а ля :

Код: Выделить всё

...
ipfw add tag THIS_IS_FOR_NAT ip from $lan to any 
....
ipfw add allow ip from me to any out xmit $if_ext <<NOT_TAGGED THIS_IS_FOR_NAT>> setup keep-state

Или тупо не бабахать мозг и убрать deny_in ?

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[suspender]

Хмм
меня проглючило, показалось что не работает сквид, из за того что отрубается deny_in натом. Но он по ходу дела всё таки работает, хотя непонятно почему.
Или все исходящие соединения тоже попадают в nat, и приходя обратно - не рубятся им, потому что в nat есть запись ?

тогда такой вопрос : Стоит ли городить огород, чтобы в нат шёл только тот траффик, который должен итти. Или нет ничего страшного чтобы через nat шёл весь траффик ?

[suspender]

И в догонку вопрос
Есть ли в ipfw аналог pf-ского reply-to ? Или для nginx, openvpn ,... (всего что должно слушать сразу много инетов) придётся запускать по второму экземпляру с другим setfib ?

[hizel]

1. имеют значение все правила, оба варианта правил могут работать
2. блокирует входящие соединения из вне, которых нет в таблице трансляции этого nat-а
man ipfw, tagged

[suspender]

man ipfw, tagged

Это то я покурил.

To check for previously applied tags, use the tagged rule option.

А что делать, если мне нужно To check that concrete tag was _not_ applied ?

Код: Выделить всё

... tagged !mytag ...

?

[hizel]

курите выше

RULE OPTIONS (MATCH PATTERNS)
Additional match patterns can be used within rules. Zero or more of
these so-called options can be present in a rule, optionally prefixed by
the not operand, and possibly grouped into or-blocks.

[suspender]

Спасибо
Просто чтение манов меня вводит в депрессию, поэтому стараюсь их читать по диагонали выясняю детали в инете
Плохое качество, согласен. Буду над собой работать.

[kosmos-irk]

Есть вопрос по ipfw nat:
Имею FreeBSD 8.2-STABLE #0

Код: Выделить всё

cat /etc/sysctl.conf
net.inet.ip.fw.one_pass=0

заворачиваю трафик в nat двумя правилами:

Код: Выделить всё

04000 nat 1 ip from any to ${ext_ip} in recv ng0
09000 nat 1 ip from any to any out xmit ng0

Код: Выделить всё

sysctl -a | grep ip.fw.one_pass
net.inet.ip.fw.one_pass: 0

Вопрос: конструкция с правилами такого вида прекрасно работает при установленном переметре net.inet.ip.fw.one_pass=0, после перезагрзуки системы этот параметр отаётся равным 0, но Ipfw ведёт себя так, будто net.inet.ip.fw.one_pass=1, до тех пор пока не сделаешь /etc/rc.d/ipfw restart

Есть предположения?

[hizel]

<телепат>
см. kldstat до и после ipfw restart
</телепат>