лучше сначала обсудить семантику, чтоб предметнее, на каких угодно примерах псевдокода, конкретный синтаксис можно обсуждать потом. Я, собсно, это хотел сказать прошлым комментом

а, ок. я просто хотел сказать что это момент важный и он может иметь не только косметическое значение.

Кстати, расскажи чем. Оно C-style а-ля Juniper-like или nginx-like, что уже есть шаг вперед от традиционных файрволов.

у меня возникает ощущение, что я программирую. а я не хочу программировать файрвол, я его хочу конфигурировать. но это так, скорее вкусовщина, хотя в случае ipfw (номера строк! бэйсик! фу!)/pf именно она и роялит. в nftables злоупотребление фигурными скобками. из скриптов конфиг будет неудобно менять. когда правило бьется на несколько строк -- трудно грепом искать. из командной строки поправить на лету одно правило -- тоже тяжело и неудобно.

в джунипере, кстати, вообще мозг выносят -- конфиг у тебя задается в одном стиле (а-ля cisco+dlink) а выводят -- в другом, со скобочками.

Если первый блин комом, ошибки-то можно и учесть.

это слишком большой прыжок в сторону

Я либо этот синтаксис не понимаю, либо какой смысл лепить в начало разрешение всего всем, оно ж остальные правила отменит.

в этом и суть -- временная отмена всех/части правил не стирая оных. и не сбрасывая статистики по ним. применяют при отладке, когда например не понятно -- то ли приложение дурит, то ли файрвол, то ли ты что-то перепутал -- отключим файрвол и посмотрим будет ли вообще работать.

Собсно, ты, я так понимаю, спец по цискам. Меня интересует, какой там packet flow в плане имениея нескольких аклей сразу, и т.п., ну по типу как я для ipfw в свое время рисовал. Поскольку multiple rulesets в ipfw изначально цискофилы и хотели.

либо я твоего вопроса не понял, либо ты плохо сформулировал. но что я помню о хотенияих а-ля циско было стремеление к следующему (освременненая ситиуация с откидыванием исторических, устаревших вариантов):

есть именованные наборы правил, ака aclи. у них, кстати, можно посмотреть счетчики, построчно.
есть конфигурация интерфейса, в которой описывается его параметры. среди прочих параметров есть два относящихся к вопросу: acl для входящих пакетов и acl для исходящих пакетов (имена). причем для каждого протокола задается отдельно.

транзитный пакет сначала получает по лбу in acl на входящем интерфейсе, потом out acl на исходящем.

почему хотели: удобно написать acl, например, для входящих пакетов с офиса (много строк), а потом по одной строке указывая просто его имя приенять на интерфейсе. тоже самое для пакетов с интернета. дополнительно указываем ограничивающие правила для dmz.

с нетграфом это у тебя получится само, иначе сделать трудно.

но это ты не видел просьб о несколько более другой технологии, перенесенной на роутеры с pix/asa:
у нас есть несколько зон (inside, dmz, outside). у зон есть уровень безопасности (0 совсем плохо, интернет; 100 -- локалка, 50 -- dmz). есть преконфигуренное поведение[*]: из зоны с большим уровнем безопасности можно без ограничений идти в меньшую. при этом образуется state для получения ответов, разумеется. наоборот -- запрещено. интерфейсу назначается принадлежность к какой-либо зоне. после этого файрвол (как устройство) готово функционировать, конфигурация очень лаконична и покрывает 95% потребностей. оставшиеся 5% исключений описываются дополнительными правилами, типа из outside на dmz host A можно ходить на порт 80. из inside на dmz port 23 ходить нельзя. и т.п. таких правил достаточно мало, поскольку умолчание [*] очень разумно.

ну еще у кошкастых есть несколько особенностей, которые наверное не имеет смысла реализовывать:

пакет, сформированный на роутере под acl не попадает вообще.
пакет, адресованный процессору роутера (не путать просто с фабрикой на каталистах, к примеру) попадает под еще один acl. ну и т.п.