IpfwNg

[nuclight]

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

Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).

Comments

[http://users.livejournal.com/_dyr/]

ipfwsync, наконец-то!
Недавно переписывался с Глебом Смирновом (glebius). Если интересно, то он считает, что ipfw как stateful файервол существенно уступает pf (над которым он как раз сейчас усиленно работает), и libalias-based NAT (ipfw nat, ng_nat, не говоря уж о natd) это вообще тупиковая ветвь развития.


Мне как провайдеру в ipfw не хватает адекватного перекладывания в нужный интерфейс (ну что это за ерунда, делать fwd, но уже после routing decision?!), синхронизации states между нодами (да-да, именно поэтому я так обрадовался планам на ipfwsync) и Carrier Grade NAT (гигабиты NATa леххко).

[http://users.livejournal.com/_slw/]

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

[nuclight.livejournal.com]

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

[http://users.livejournal.com/_slw/]

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

SIP must have.

хелперы отслеживания вторичных соединений

[nuclight.livejournal.com]

Я вообще-то сначала понял иначе - что в основе кроме обычного 5-tuple (src/dst addr/port proto) должно быть нечто еще. А ты про способ реализации модулей, которые собственно будут отслеживать данные. Но тоже интересная идея. Пока что это напоминает BPF (а регэкспы в ядро тащить довольно накладно, кстати).

> SIP must have.

Ну ты же понимаешь, что в одиночку я это ниасилю (тем более я никогда не имел дела с SIP). Моя задача - сделать фреймворк,

[kvasdopil.livejournal.com]

А что за работа над pf идёт, если не секрет?

[http://users.livejournal.com/_dyr/]

Сейчас я занимаюсь увеличением производительности pf, как минимум
сделать в нём fine grained locking. Процесс идёт в этой ветке:
http://svnweb.freebsd.org/base/projects/pf/head/

[http://users.livejournal.com/_dyr/]

И ещё:
"

У меня сейчас задача довести до ума pf в рамках FreeBSD. В нём есть
масса неправильностей, которые связаны с быстрым портингом. Стояла
задача портировать минимальной ценой, то есть с минимальным вмешательством
в код, а ведь FreeBSD и OpenBSD значительно отличаются, многие места
требуют значительного вмешательства, для того, чтобы было сделано правильно.
Ну и самое главное - нам нужна многотредовость и сейчас её нет. Хочу
всё это довести до ума, и только потом что-то добавлять новое.

"

[nuclight.livejournal.com]

Ну, да, правда я сказал бы, что пилить для этого pf - тактическое решение, а не стратегическое. Ибо вменяемость апстрима оставляет желать лучшего.

Насчет ipfwsync - ну это когда еще будет... Я затрудняюсь сказать, сколько времени потребует проект, как минимум несколько месяцев _фулл-тайма_ (т.е. реально куда больше, потому что на попозже мне таки надо будет на работу устроиться), и для ipfwsync будет заложена возможность, а реализовано может будет уже после интеграции в базу.

И вопрос как провайдеру, насчет fwd: а на линуксовый iproute2 смотрели? Там выбор таблицы маршрутизации сделан несколько человечнее и похоже на ipfw синтаксисом даже (наш соотечественник делал). Оно, конечно, дублирует функционал iptables, но на эти проблемы нам плевать, можем сделать как хотим. Вопрос, что именно/как оттуда стоит брать, с точки зрения пользователя?

[http://users.livejournal.com/_slw/]

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

но это такая задача, которая на данный момент везде решается криво и есть ли для нее хорошее решение -- не ясно

[nuclight.livejournal.com]

Вопрос надо ставить так: что полезного мы можем оттуда взять - сейчас у нас это сделано хуже. По крайней мере, синтаксис там не птичий.

[http://users.livejournal.com/_slw/]

семантика -- недокументированная.
синтаксисис -- мало ушел от птичьего.
а, не, вру -- натурально птичий, это же iproute. я в нем permit any any не осилил по ману, пришлось в гугл за примером лезть.

[ra-ga.livejournal.com]

>я полгода назад для частной задачи имел секас с iproute2.
>могу сказать, что человечного там при выборе таблицы маршрутизации довольно мало.

а в чём проблема?


root@laptus:~# ip rule help
Usage: ip rule [ list | add | del | flush ] SELECTOR ACTION
SELECTOR := [ not ] [ from PREFIX ] [ to PREFIX ] [ tos TOS ] [ fwmark FWMARK[/MASK] ]
[ iif STRING ] [ oif STRING ] [ pref NUMBER ]
ACTION := [ table TABLE_ID ]
[ prohibit | reject | unreachable ]
[ realms [SRCREALM/]DSTREALM ]
[ goto NUMBER ]
TABLE_ID := [ local | main | default | NUMBER ]

вполне human readable.

>но это такая задача, которая на данный момент везде решается криво и есть ли для нее хорошее решение -- не ясно

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

[http://users.livejournal.com/_slw/]

там проблемы на уровне смысла были.
например, нигде не было описанно что стадия PREROUTING (кажется) влияет на возможность bind сокета к локальному адресу и на arp кажется тоже. это осенью было -- вспоминать лень.

[http://users.livejournal.com/_dyr/]

Ну, да, правда я сказал бы, что пилить для этого pf - тактическое решение, а не стратегическое. Ибо вменяемость апстрима оставляет желать лучшего.
Ну вот Глеб, насколько я понимаю, и хочет своё запилить, без апстрима ;)

Насчет ipfwsync - ну это когда еще будет...
Я постараюсь уговорить руководство на денежный грант по ipfwsync. Если что, найдётся банковский счёт и юридическое лицо (хотя бы в виде ИП)?

И вопрос как провайдеру, насчет fwd: а на линуксовый iproute2 смотрели?
Нет, не смотрел. Смотрели у Линукса только iptables, и пытался продраться сквозь дебри синтаксиса tc (увы, не смог). NAT у него, конечно, отличнейший.

[dadv.livejournal.com]

/me перечислял "грант" на счет glebius@ без юрлица - получал на себя "премию" и со своей карты кидал ему перевод :-)

[http://users.livejournal.com/_dyr/]

Моей организации, боюсь, так будет даже сложнее. Как же, выдать мне премию, бухгалтерия сбесится %)

[sem-lj.livejournal.com]

У нас есть самописная разработка ipfwsync. Она даже работает.
Если есть желание, я могу дать адрес автора, возможно удастся уговорить его выложить его куда нибудь.

[nuclight.livejournal.com]

Если я правильно помню, ваша разработка не покрывает самое интересное - NAT. А только лишь динамические правила.

[nuclight.livejournal.com]

> Ну вот Глеб, насколько я понимаю, и хочет своё запилить, без апстрима ;)

Дурная это работа, как по мне. Там кроме SMP еще куча проблем, а синхронизироваться с апстримом ведь всё равно придется.

> Я постараюсь уговорить руководство на денежный грант по ipfwsync. Если что, найдётся банковский счёт и юридическое лицо (хотя бы в виде ИП)?

Увы, юридического лица не найдется. Да и до обеспечения возможности ipfwsync еще куча работы - хочется ведь полноценный ipfwsync (ввиду несовместимости между разными версиями мне кажется что полезность pfsync немного страдает).

> только iptables, и пытался продраться сквозь дебри синтаксиса tc (увы, не смог).

Что ж всё места-то такие... У него команда ip(8) единственная, где синтаксис человеческий, в отличие и от iptables и от tc.

[ra-ga.livejournal.com]

>Оно, конечно, дублирует функционал iptables

а в каком месте? могу только вспомнить stateless nat

[nuclight.livejournal.com]

В том, что селектор - это натуральное подмножество возможностей файрвола, причем еще и в синтаксисе, похожем на ipfw. Настолько натуральное, что во BSD-файрволах оно в них самих и было сделано. Другое дело, что ведет к некоторой мешанине, но когда для одной задачи возможностей селектора ip rule хватает, а для другой приходится подключать MARK в файрволе - это идеологическое дублирование и костыльность видно очень хорошо.

[denis-sotchenko.livejournal.com]

Каким образом можно так кардинально ускорить NAT, чтобы гигабиты были леххко?

[http://users.livejournal.com/_dyr/]

Да вообще-то ровным счётом ничего кардинально не надо, у меня на однопоточном PF NAT спокойно гигабит жуёт.

[denis-sotchenko.livejournal.com]

А какая на том же трафике производительность у ipfw nat?