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 в файрволе!

[kondybas.livejournal.com]

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

[nuclight.livejournal.com]

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

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

[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@

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

[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. В этом случае второй пункт некритичен. На самом деле, если вы планируете регулярно его обновлять и вообще майнтейнить, порт даже лучше - в базу пропихивать изменения тормознее.

[victor-sudakov.livejournal.com]

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

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

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

[sem-lj.livejournal.com]

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

[nuclight.livejournal.com]

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

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

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

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

[dadv.livejournal.com]

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

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

[denis-sotchenko.livejournal.com]

да, плюсую NAT64

а правила скопом загружаются без проблем - ipfw /path/to/rules
причём, в отличие от отдельных вызовов ipfw add, грузятся практически мгновенно.

[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 ничего не умеют, это просто несерьезно.

[kvasdopil.livejournal.com]

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

[nuclight.livejournal.com]

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

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

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

[denis-sotchenko.livejournal.com]

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

[dadv.livejournal.com]

А не хотелось бы тебе для начала поразбираться с жуткими багами в существующем ipfw? Например:

#!/bin/sh

args="add 60001 count ip from any to { "

for i in `jot $1 1`
do
args="${args}127.0.0.$i or "
done
args="${args}127.0.1.1 }";

ipfw delete 60001
echo ipfw $args
ipfw $args

Для i386 запускаем скрипт с аргументом 122, для amd64 с аргументом 121. На 8.3 после этого наблюдаем бинарник /sbin/ipfw в состоянии running, жрущий все такты CPU, не убиваемый через kill -9. Любой последующий запуск ipfw - даже ipfw show - порождает второй такой же процесс. Перезагрузиться нормально такая система уже не в состоянии, только через выход в KDB и reboot там.

[denis-sotchenko.livejournal.com]

а kill -STOP не работает?

[nuclight.livejournal.com]

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

[denis-sotchenko.livejournal.com]

1) По поводу stateful fw: По-моему, вместо генерации динамических правил, возможно, разумнее генерировать таблички.

2) По поводу привязки к интерфейсам…
в таком виде для провайдерского роутера это малоприменимо.
Например, тазик обслуживает 3000 абонентов - создано 3000 вланов. Если делать 3000 "файрвольчиков", будет сильно размываться кэш.
Один большой, возможно, с чуть более сложной логикой, запросто окажется выгоднее.
Если вместо вланов пппое - там интерфейсы и вовсе динамические, не напривязываешься.

А когда на тачке интерфейсов всего несколько - "привязка" делается несколькими skipto.
Итог - та же самая возможность, что со skipto, просто создана новая сущность. Смысл?

[denis-sotchenko.livejournal.com]

И чего не хватает: двухадресных таблиц.
Чтобы можно было, к примеру, индивидуально задать для каждого абонента, куда ему нельзя ходить.

[ra-ga.livejournal.com]

не хватает возможстей ipset.

[toxa.livejournal.com]

Вопрос ко всем: а когда в -current будет pf не из древнего опенка?

[dadv.livejournal.com]

Когда кто-нибудь, кому pf важен, обновит его в current из свежего опенка.

Именно так работает эта система.