>[оверквотинг удален]
>> Вот если убрать правило 110, то весь исходящий траф будет
>> порезан правилом 1999, который для правила 1000 режет все пакеты которые
>> не имели тега recv для интерфейсов инет и лан.
> Да, верно, но только потому, что нет других правил между 110 и
> 1000. Если бы были - о то оба нужны.
> Напоминание по поводу NAT: для маршрутизатора в NAT нужно заворачивать весь трафик
> - входящий, понятно, и так весь, но ошибочно делают NAT только
> исходящего трафика других компов, а исходящий самого шлюза не делают, и
> потом удивляются разным глюкам.
> ipfw - это как ассемблер, too easy to shoot the leg. А можно мне пояснить немного один момент. В русских мануалах по ipfw где разбирают схему прохождения пакета структура такая, что пакет дойдя до правила заворачивания в nat и пройдя процедуру маскирования (например для исходящих) вновь возвращается в скажем так в функцию ip_out и снова пробегает по цепочке правил для исходящих пакетов. Но опция
# lan in
$fwcmd 4000 allow all from any to any // lan in
# inet out
$fwcmd 5000 nat 1 all from any to any // inet out
$fwcmd 5010 allow all from any to any // inet out
$ lan out
$fwcmd 6000 allow all from any to any // lan out
Правильно ли я понимаю, что правило 4000 на которое сбрасывает keepto с правила 1010 отфильтровавшее весь вошедший локальный трафик его же и полностью разрешает, после чего весь этот трафик заворачивает в нат правилом 5000, после использования которого снова проходит по всей цепочке ipfw для out, но благодаря опции one_pass он эту цепочку минует и сразу попадает на выход. Вот не могу понять, если опция не выставлена, что помешает пакету при повторном прохождении цепочки снова не попасть в правило которое заворачивает исходящие пакеты в NAT, и не получить петлю.
Правило 5010 разрешает весь маскированный трафик на выход. И вот тут насколько я понимаю и появляется смысл отсутствия keep-state. По сути мы выпускаем на out все, без какой либо фильтрации, но благодаря отсутствию keep-state, все равно весь входящий трафик мы режем на правилах ин, и даже если скажем кто-то из юзеров попытается сделать что-то не хорошее, то в плане исх трафика он сможет отправить любой запрос, но вот ответ от нежелательных источников будет порезан на входе, и получится что-то типа черной дыры, он вроде кричит, а ответа не приходит. А если бы я использовал Keep-state для исходящих правил, и где-то ошибся, то выпустив по правило все разрешено, я по сути мог бы получить "дыру", пользователь сделал какое-то не хорошее дейсвие, о котором я мог не подумать, и это действие подпало бы под keep-state и не подверглось бы фильтрации на входящих.
--------------
upd
Правильно ли я понимаю, что по логике, в вышеприведенном листинге правил фильтрация по сути осуществляется на входе?
Просто в вин я привык что прописываем умолчальное правило deny all from all to all и уже пляшут от него, разрешено то, что явно разрешено, все остальное запрещено. А согласно листингу свыше, мы разрешаем исходящее вообще все, но получить ответ можно лишь по избранному. Несколько не привычный метод фильтрации для меня.
