nftables

Принципиально поменялся только синтаксис.

Есть реальная польза от интеграции ipset, добавлении maps и dictionaries

сомнительная польза от интеграции с ebtables

Поменялось внутреннее устройство ( якобы должно быть быстрее )

Якобы разрешено несколько action - вроде полезного LOG & DROP или MARK & ACCEPT

Правила все равно _нужно_ проходить по очереди, иначе будет крайне сложно понять/описать действия фильтра.

Жаль, что нет анонимных цепочек типа

ip proto tcp {
  ip daddr x.x.x.x dport 80 drop;
  ip daddr y.y.y.y dport 8080 accept;
  ....
}

PS им все это еще пилить и пилить.

Правила все равно _нужно_ проходить по очереди, иначе будет крайне сложно понять/описать действия фильтра.

Нет, если бы каждому пакету соответствовало в итоге 1 правило, этого бы можно было избежать.

Наверняка сюда нужно призвать любителей всяких функциональных языков программирования, чтобы они рассказали, как это легко сделать их любимом <название языка>.

ты когда-нибудь ковырялся в libpcap ?

Одна из интересных и полезных вещей в ней - оптимизатор.

Запустив tcpdump c ключиком -d -O и без '-O' интересно сравнить результат. Если бы аналогичные оптимизации были бы возможны в nftables на уровне цепочки, то это дало существенное ускорение обработки пакетов (ну а дальше и до jit-компиляции не далеко). Но тогда нужно где-то хранить исходные правила, чтоб в них что-то можно было добавлять/удалять.

Только есть и другая проблема - как отлаживать вложные наборы правил. Сейчас все просто - включил TRACE и понял, где собака зарыта, а как быть с трассировкой такой «оптимизированной» цепочки ?

А на счет языков - да хоть на m4 делай генератор правил :)

Странно, что еще никто не сделал транслятор правил цепочки iptables в LSF/BPF :)

Написал цепочку правил, скомпилировал, получил одно офигенное правило. Жаль, что в BPF нет action, только фильтр.