Разработчики Netfilter предоставили замену iptables

> правила повторяются в разных вариациях, недокументированы и разбросаны
если действительно так запущено - то проще заново переписать с нуля по полученным ЦУ . 1-2 часа max.

> Посмотри на синтаксис PF из BSD и поймите что такое читаемые правила!
ну да, scrub in all - образец читаемости.
а чтобы понять что такое pass quick - надо хотя бы общее представление о TCP иметь. а если уже имеешь это - то пофигу - какой fw.
на самом деле pf неявно предполагает очень хорошее знание английского,
чему доказательство разница между целями all и any.
в iptables такой проблемы нет - там достаточно знать формальные правила.

Не ясно как можно сравнивать tc и iptables.

iptables одномерная статическая структура.

tc двумерная - F.статическая_структура(время).

Далее вопрос синтаксиса входных правил, это вообще-то для эстетов. Главное в этих системах содержится внутри, где никаких текстовых описаний нет. Так вот, мы заинтересованы чтобы наши входные описания эквивалентно преобразовывались в максимально эффективный внутренний код, который позволит с минимальными накладными расходами реализовать то поведение системы, которое нам нужно. Для достижения этой цели нам предлагается навести красоту не только во внутренней структуре, но и в интерфейсе к ней и во входном синтаксисе. Ну что же, похвальное решение, подождём - поглядим.

Хотя не видно особых препятстствий к сохранению исходной формы синтаксиса с одновременной сменой всех потрошков системы.

Проблема IPTables не в синтаксисе - он, конечно, непривычен фанатам pf'а, но это не значит, что он плохой, я, например, прекрасно читаю эти правила и пишу их тоже нараз, хотя мне вот уже 3 года не приходилось какой-то большой и сложный фаерволл настраивать. У IPTables проблема заключается в том, что это до сих пор не более, чем тупой пакетный фильтр на основе статических правил. Какое-то время в IPTables быд превосходный conditional matching, когда-то активно использовался модуль strings для контекстной фильтрации содержимого пакетов, а осталось нам из всего этого великолепия... только Transparent Proxy и ULOGD фактически. И те в любой момент могут посчитать "deprecated" или ещё что-нить в таком духе. Netfilter, к сожалению, создаёт группа недалёких людей, которые просто не понимают разницу между пакетным фильтром и фаерволлом, а потому выкидывают из iptables всё, что не относится к пакетной фильтрации по заголовкам непосредственно.

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

Похоже на очередной блестящий фантик с которым увеличатся и безтого неповоротливые дистрибутивы.

Как я понимаю, код не увеличивается - собрал правила и используй.

Ну вот зачем создавать велосипед. Лучше бы нормальный, полноценный конфигуратор сделали к обыкновенному iptables. Тогда уже разницы нет в сложности кода, если фронтэнд нормальный

> модуль strings
а что случилось с ним?

Кому интересно, можете посмотреть на проект etcnet (etcnet.org), мало того, что там собраны в одном месте почти все "ручки" для управления сетью в Linux в удобном виде (всё на базе iproute2), так я там еще в своё время сделал поддержку iptables/ip6tables/ebtables, с простой, но эффективной группировкой правил по таблицам, а далее по цепочкам внутри них. И еще ради перфекционизма сделал некое подобие ipfw синтаксиса (сделано банальной заменой английских слов на опции *tables :)
Так же там есть и удобная поддержка/настройка QoS ( на базе tc, естественно)
http://www.altlinux.org/Etcnet
http://www.altlinux.org/Etcnet/firewall
http://www.altlinux.org/Etcnet/qos

>Лучше бы нормальный, полноценный конфигуратор сделали к обыкновенному iptables.
>Лучше бы нормальный, полноценный конфигуратор сделали к обыкновенному iptables.
Ёппонский городовой, а ferm - это и есть фронтенд с похожим синтаксисом, генерирующем конфиг для iptables, причем изменения в ядреной таблице сохраняет через iptables-restore.

cat /usr/share/doc/ferm/examples/workstation.ferm
# -*- shell-script -*-
#
# Ferm example script
#
# Firewall configuration for a workstation which accepts remote ssh login.
#
# Author: Max Kellermann <max@duempel.org>
#

table filter {
chain INPUT {
policy DROP;

# connection tracking
mod state state INVALID DROP;
mod state state (ESTABLISHED RELATED) ACCEPT;

# allow local connections
interface lo ACCEPT;

# respond to ping
proto icmp icmp-type echo-request ACCEPT;

# allow SSH connections
proto tcp dport ssh ACCEPT;

# ident connections are also allowed
proto tcp dport auth ACCEPT;

# the rest is dropped by the above policy
}

# outgoing connections are not limited
chain OUTPUT policy ACCEPT;

# this is not a router
chain FORWARD policy DROP;


ferm -nl /usr/share/doc/ferm/examples/workstation.ferm

# Generated by ferm 2.0.3 on Mon Mar 23 15:08:11 2009
*filter
:FORWARD DROP [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT --match state --state INVALID --jump DROP
-A INPUT --match state --state ESTABLISHED,RELATED --jump ACCEPT
-A INPUT --in-interface lo --jump ACCEPT
-A INPUT --protocol icmp --icmp-type echo-request --jump ACCEPT
-A INPUT --protocol tcp --dport ssh --jump ACCEPT
-A INPUT --protocol tcp --dport auth --jump ACCEPT
COMMIT

> модуль strings
>а что случилось с ним?
А что может произойти со стрингами? Вышли за пределы, порвались нафиг :-)

> table <admin_hosts> { 172.23.1.1, 192.168.0.0/24}
> pass in on any proto {tcp, udp} from <admin_hosts> to port {http, https, ssh, domain}

Это не совсем то что в оригинале

pass in on any proto tcp from <admin_hosts> to any port { http, https, ssh }
pass in on any proto udp from <admin_hosts> to any port domain

и тоже по-дурацки скопировал on any.
я уже лавал тут правильный вариант