IpfwNg

[nuclight]

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

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

Comments

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

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

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

[kvasdopil.livejournal.com]

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

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

[dmarck.livejournal.com]

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

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

[kondybas.livejournal.com]

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

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

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

[victor-sudakov.livejournal.com]

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

[kondybas.livejournal.com]

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

[sem-lj.livejournal.com]

для NAT64 libalias бы переписать.
ну и загрузка всех правил скопом must have.

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

умею. но я ел и слаще морковки.

[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/_dyr/]

PF тут оочень в тему, кстати. Так, на всякий случай подсказываю.

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

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

[kvasdopil.livejournal.com]

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

[nuclight.livejournal.com]

2 по ссылке и так есть, просто недоописано еще, а шо конкретно ты имеешь в виду под 1 ? И если с идеологией еще что-то могу нателепатировать, с синтаксисом-то что не так?

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

[nuclight.livejournal.com]

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

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

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

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

[nuclight.livejournal.com]

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

[nuclight.livejournal.com]

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

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

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

[nuclight.livejournal.com]

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

В таких случаях стоит пояснять, что именно подразумевается под "нормальным". Даже вариант ответа "как в pf" требует некоторых уточнений - скажем, я чехарду вокруг scrub/synproxy/и около - не считаю обязательным атрибутом нормального.

> в) ну и вообще гибкости пфа в плане того что может быть произвольная комбинация first-match\last-match, а не всегда first-match как в ipfw, хотя это не настолько принципиально.

Сколько с файрволами работаю, никогда не понимал этого идиотизма с last-match, который становится особенно контринтуитивен в случае произвольных комбинаций с first-match. Можете показать реально работающую конфигурацию, где использование этой фичи упрощает рулесет и/или его понимание? Всегда было интересно посмотреть на выигрыш.

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

1) Должна наличествовать документация, то есть хорошо написанная ман-страница, как и у других модулей
2) Убедиться, что код соответствует style(9) и достаточно современен на вкус коммиттеров (в смысле, не используются ныне считающиеся устаревшими идиомы)
3) После этого патч публикуется в net@ и можно пинать знакомых коммиттеров на его включение.

Альтернативный вариант, как посоветовал коммиттер в соседнем комментарии - оформить порт, как это сделано для ng_ipacct и когда-то было сделано для ng_netflow. В этом случае второй пункт некритичен. На самом деле, если вы планируете регулярно его обновлять и вообще майнтейнить, порт даже лучше - в базу пропихивать изменения тормознее.

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

тут надо очень много излагать, возможно имело бы смысл поговорить (по скайпу к примеру).
значит надо делать хорошо, что бы понравилось. вообще, кмк, фанатов синтаксиса ipfw нет.
есть те, кто говорят "приемлимо".
синтаксис растет из доисторических времен, когда он был простым и логичным. потом его расширяли сохраняя совместимость и получили уродца (ipfw table show или list? а nat? и т.п.).
у ipfw список правил со счетчиками -- они должны исполняться последовательно (что очень не эффективно), ты не можешь провести оптимизацию и проверить пакет сразу по всем правилам

новый файрвол должен быть statefull по умолчанию. таблиц state должно быть несколько в пределах нескольких fib (настраиваемо), т.е. что бы можно было сказать, что пакеты по пути em0/em1 организуют satet, не пересекающеся с пакетами bge0/bge1 (мы не хотим видеть ответ на пакет, отправленный с интерфейса em0 на интерфейсе bge1).

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

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

SIP must have.

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

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

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

[victor-sudakov.livejournal.com]

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

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

"rtable"
Хотя конкретно для вашего случая я бы всё же не использовал несколько таблиц маршрутизации, а пользовался бы именно перекладыванием в нужный интерфейс ("route-to"). По моему опыту роутеры с несколькими FIB весьма глючные :(

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

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

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

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

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

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