>> allow forward from any to $ipDmzServer in-if $ifWan out-if $ifDMZ proto tcp dport https
>
>iptables -I FORWARD -s 0/0 -d $ipDmzServer -i $ifWan -o $ifDMS -p
>tcp --destination-port https -j ACCEPT
>
>И где разница, кроме того что синтаксис другой ... Я бы не делал акцент на синтаксисе. В данном случае ее действительно практически нет. На страничке проекта альтернативный синтаксис даже не вынесен в "возможности" (features), поскольку это далеко не главное.
Рассмотрите эту строчку в контексте с другими, ведь правил на фаере как правило больше одного. А теперь представте что правил там несколько тысяч. Или десятков тысяч. Желание сгруппировать их, снабдить комментариями, или хотя-бы просто сократить объем анализируемой при просмотре информации возникнет очень быстро. И группировка, скорее всего, будет производиться по влиянию правил на доступность конкретных сетевых приложений. Вот мы уже вплотную подошли к сервис-ориентированности.
Расширим рамки - вы в организации не единственный сисадмин, и у вас далеко не один сервер/маршрутизатор. По мере развития все равно или поздно разрабатывают свои внутренние стандарты, или, если им повезет, следуют ранее принятым - как оформлять комментарии, как группировать правила, какие правила использовать в той или иной ситуации, какие использовать переменные, где инициализировать их значения и т.п. И теперь вы уже не вольный художник с гибким и мощным инструментом, вы заложник стандартов. И что-бы им следовать и не ошибаться, вы сами-же начнете разрабатывать макросы или функции, заменяющие одинаковые последовательности команд одним вызовом и сводящие к минимуму объем набиваемого текста. Вы вплотную подошли к упрощению синтаксиса.
Возмем штатную рабочую ситуацию - необходимо изменить настройки фаервола на маршрутизаторе. В простейшем случае (а именно так поступает большинство) вы находите в своем скрипте с последовательностью команд iptables нужные комменты, добавляете или модифицируете правила, и перезапускаете скрипт. Сброс цепочек, применение полиси, пошли добавляться правила... Через некоторое время пакеты снова забегали. Никто из работающих через маршрутизатор практически ничего и не заметил. Ну, тормознул браузер. Ну, аська переконнектилась. Хотя, если вы ошиблись, и скрипт не отработал сразу без ошибок, времени потребуется немного больше и кое-кто может занервничать... А теперь вспомним что правил много (очень много!), а клиентов, работающих через маршрутизатор, ненамногим меньше. И они очень нетерпеливые. И в случае перебоя со связью на вас обрушивается шквал телефонных звонков, потому что вы еще и служба поддержки к тому-же. Через пару промахов вас вызовет к себе ваш руководитель и вставит чопик. Который ему достанется от его руководителя. И что-бы этого избежать в будущем вы задумаетесь - как быстро и аккуратно вносить точечные изменения в работающий фаер, минимизируя последствия (читай - простой) от допущенной ошибки (а человеческий фактор еще никто не отменял). При достаточно серъезном подходе к должностным обязанностям вы быстро обрастете своими-же "обертками".
Предполагаю, что все создатели каких-либо "оберток" начинали с этого-же. Не от праздного любобытства разрабатывались упомянутые здесь shorewall'ы и ufw'ы. Все от нужды... :)
