IpfwNg

[nuclight]

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

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

Comments

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

И ещё:
"

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

"

[victor-sudakov.livejournal.com]

А для локально запущенных приложений pf rtable разве работает? А то в pf.conf(5) написано "Only effective before the route lookup happened, i.e. when filtering inbound." В такой позе и "ipfw setfib" работает.

А перекладыванием я сейчас как раз и пользуюсь, только ipfw fwd, а не pf. Но вот появилась новая фича с этими fib, захотелось попробовать.

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

Для локальных не знаю.
ipfw fwd не работает же - он изменяет лишь ip, но кладёт в тот же интерфейс (в отличии от удобного route-to в pf):

pass out quick route-to ($ext_if_1 $ext_gw_1) from $nat_1 to any allow-opts no state
pass out quick route-to ($ext_if_2 $ext_gw_2) from $nat_2 to any allow-opts no state

[victor-sudakov.livejournal.com]

> ipfw fwd не работает же - он изменяет лишь ip, но кладёт в тот же интерфейс

Как это не работает? "If ipaddr is not a local address, then the port number (if specified) is ignored, and the packet will be forwarded to the remote address, using the route as found in the local routing table for that IP."

А как бы на ipfw fwd делали policy routing, если бы клал только в тот же интерфейс? Или я Вас не понял?

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

А вот фиг. Навскидку: kern/129036 (http://www.freebsd.org/cgi/query-pr.cgi?pr=129036&cat=kern), kern/122963 (http://www.freebsd.org/cgi/query-pr.cgi?pr=122963&cat=kern)

[dadv.livejournal.com]

Он кладет в нужный интерфейс, там есть лишь проблема с тем, что переписывание имени исходящего интерфейса в атрибутах пакета не происходит и ipfw продолжает "видеть" имя старого исходящего интерфейса. Но роутинг будет выполнен корректно на указанных next-hop всё равно.

[dadv.livejournal.com]

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

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

[dadv.livejournal.com]

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

[dadv.livejournal.com]

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

[sem-lj.livejournal.com]

Это не то. Я про типа такого: ipfw -f

[dadv.livejournal.com]

И это есть.

[sem-lj.livejournal.com]

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

[sem-lj.livejournal.com]

Я смотрю на какой то другой ipfw?
Вообще-то sets - это альтернативные наборы правил, которые можно *включать* и *отключать* по желанию.
Но загрузка в них происходит все так-же - по одному правилу.

Такая загрузка - это ужасно не удобно.

[dadv.livejournal.com]

> Я смотрю на какой то другой ipfw?

Просто надо внимательно читать man ipfw.

ipfw [-cfnNqS] [-p preproc [preproc-flags]] pathname
...
     To ease configuration, rules can be put into a file which is processed
     using ipfw as shown in the last synopsis line.  An absolute pathname must
     be used.  The file will be read line by line and applied as arguments to
     the ipfw utility.

[sem-lj.livejournal.com]

Это я читал. Это издевательство, которое ничем не лучше шел скрипта со строчками ipfw add ...

Попытаюсь быть экстрасенсом: ты предлагаешь это загружать в некий сет и при успехе делать swap с активным?

А почему эту возможность не добавить нативно? Что бы ipfw загружал правила в память, репортил ошибки, либо, если их нет, загружал опкоды уже в ядро?

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

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

[dadv.livejournal.com]

> Это я читал. Это издевательство, которое ничем не лучше шел скрипта со строчками ipfw add ...

Тогда я не понял, что должно быть твоём "ipfw -f file"

> Попытаюсь быть экстрасенсом: ты предлагаешь это загружать в некий сет и при успехе делать swap с активным?

Разве это не очевидно?

> А почему эту возможность не добавить нативно? Что бы ipfw загружал правила в память, репортил ошибки, либо, если их нет, загружал опкоды уже в ядро?

Не вижу разницы с существующим сейчас функционалом: в файл пишем команды добавления в set 1, затем swap.

[dadv.livejournal.com]

Бухгалтерия не решает, кому давать премию, кому не давать, это не её компетенция.

[sem-lj.livejournal.com]

Ну в принципе, можно и левое ухо чесать правой ногой. Цель будет достигнута.

[dadv.livejournal.com]

Ничего хитровывернутого в описанной процедуре нет, всё весьма прямолинейно. В своём враппере над ipfw я вовсю использовал именно эту процедуру ещё на 4.11.

[sem-lj.livejournal.com]

Ключевое выражение "в своем враппере". Хорошо бы, что бы это было у всех.

[dadv.livejournal.com]

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

[actika.livejournal.com]

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

Если вам так мила идеалогия IPTABLES поставьте себе линукс. Ненужно тянуть эту безумную модель в freebsd.

>у ipfw список правил со счетчиками -- они должны исполняться последовательно (что очень не эффективно)
На удафф в нетленки :-))

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

iptables родился в твоем безумном мозгу

[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 там.