IpfwNg

[nuclight]

В честь 26 годовщины 26 апреля уволился с текущей работы и таки наконец начал проект http://wiki.freebsd.org/IpfwNg - хотя на работе FreeBSD и была основной системой, реальную возможность пилить ядро я так и не получил (хотя тот же NAT64 нам бы понадобился не через полгода, так через год

Comments

[_slw]

1. уход от ipfw синтаксиса и идеологии.
2. интеграция и совмещение с nat.

1+2. скорее ближе к asa, но идти надо еще дальше. у asa nat и acl все же не одно и то же.
4. наконец-то поддержка ftp в файрволе!

[kondybas]

1. Это уже будет не ипфв. Лично меня устраивает его идеология, а синтакс и подавно.
2. Зачем совмещать концептуально разные вещи?
1+2 вам надо - идите.
4. Существует масса протоколов и сервисов. Это что, все их "поддерживать в файрволле"? Гггггг.....

[_slw]

1. а) пох б) давно требуется что-то лучшее
2. затем что это удобно. затем что это близкие вещи. затем, что один без другого -- калека на костылях.
4. да, поддерживать.

[kondybas]

"Вы просто не умеете их готовить" (с)

[kvasdopil]

Нам для нашего проекта в ipfw очень не хватает
а) нормального stateful-фильтра
б) аналога route-to\reply-to из pf
в) ну и вообще гибкости пфа в плане того что может быть произвольная комбинация first-match\last-match, а не всегда first-match как в ipfw, хотя это не настолько принципиально.
В результате приходится использовать связку pf\ipfw и ловить кучу граблей в некоторых случаях.

Кстати, может быть вопрос не совсем по адресу: мы тут запилили ядерный netgraph модуль для layer-7 фильтрации и думаем его предложить для внесения в head. Что для этого надо сделать?

[dmarck]

для начала, я так думаю, опубликовать патч в -net@

или подготовить порт

[nuclight]

> а) нормального stateful-фильтра

[victor_sudakov]

Как бы еще ipfw setfib доделать до такого состояния, чтобы можно было трафик локально запущенного приложения отправлять в разные fib. Например входящие запросы к squid и ответы на них обрабатывать в одном fib, а исходящие запросы и ответы на них - в другом. Чтобы не каждое приложение дорабатывать на предмет поддержки SO_SETFIB на сокетах, а иметь какое-то универсальное решение.

[victor_sudakov]

А где в pf работа именно с fib, т.е. с несколькими таблицами маршрутов (а не аналог "ipfw fwd")?

[nuclight]

> ну и загрузка всех правил скопом must have.

Да, разумеется. Хотя технически это скорее будет загрузка кусками в некий буфер в ядре и потом его атомарная активация.

> для NAT64 libalias бы переписать.

А вот это нафиг не надо и вредно, libalias пора закопать (вот в треде ниже мнение Глеба приводят, конкретно к этой теме я согласен). Чтобы там такое сделать, нужно столько переделать, что проще переписать. К тому же дает знать о себе наследие ориентированности на юзерленд и архитектурная ошибка в виде мешания partially specified links (для редиректов и проч.) в общую кучу с обычными соединениями, из-за чего нельзя применить более эффективную хэш-функцию, и (в том числе поэтому) вообще параллелить его - та еще проблема...

[dadv]

http://nuclight.livejournal.com/130012.html?thread=815836#t815836

[dadv]

> ну и загрузка всех правил скопом must have.

Есть давным давно, ещё в 4.x было. ipfw sets.

[_slw]

кмк как stateful все три текущих файрвола сосут полностью. они же выше tcp ничего не умеют, это просто несерьезно.

[nuclight]

А что именно они должны уметь? Ты имеешь в виду обычный трекинг FTP data, IRC DCC, PPTP GRE, или мне надо срочно на что-то еще более хитрое в архитектуре заложиться?

[_slw]

у меня нет готового архитектурного решения.
но это должно быть расширяемо, модульно (с какими-то хуками), расширяемо в бинарном виде, идеально в виде описания нового протокола/расширения на DSL и трансляции в аналог какого-то DFA.
т.е. расширение должно быть не на си писанно. а после подгрузки в файрвол -- правятся внутренние таблицы (не в хуки вставляются в цепочку, а хуки говорят на каком уровне вставляться в какие таблицы. а далее в "таблицы" (которые могут на самом деле быть radix tree) вносятся исправления).
информация, которая добавляется может быть номером порта, сигнатурой по смещению, регэкспом (для расширения sipа, там же куча RFC, например с dual video отдельные пляски)

SIP must have.