IpfwNg

[nuclight]

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

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

Comments

[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 не работает?

[dadv.livejournal.com]

Не пробовал и в данный момент попробовать не могу, но мне не надо -STOP. Мне надо -KILL, а точнее чтобы и KILL не требовался:-)

[nuclight.livejournal.com]

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

[dadv.livejournal.com]

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

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

Есть хоть одна причина, чтобы не использовать таблицы в таких случаях?
P.S. Переписать автогенерацию, кстати, обычно существенно проще. ;)

[dadv.livejournal.com]

Переписать автогенерацию может быть не проще, если написано три года назад тем, кто уже уволился и всё just works. Так бывает, более того - это идеал, который надо всячески поддерживать и к которому стремиться :-)

> Есть хоть одна причина, чтобы не использовать таблицы в таких случаях?

or-блоки работают не только для IP-адресов. Вот реальный код, сгенерированный простеньким враппером на шелле:

nat 123 ip from any to any src-ip 192.168.0.0/24 { proto gre or proto esp or proto ah } out xmit fxp2
nat 123 ip from any to any src-ip 192.168.0.0/24 proto tcp { dst-port 53,80,20,21,22,25,110,123,443,500,587,993,1325,1723,2068 or dst-port 2802,3306,3389,4430,4500,5190,5999,6502,8000,8001,8080,38197 or dst-port 55555,49152-65535 } out xmit fxp2

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

>Переписать автогенерацию может быть не проще, если написано три года назад тем, кто уже уволился и всё just works. Так бывает, более того - это идеал, который надо всячески поддерживать и к которому стремиться :-)

Если скрипт автогенерации нельзя быстро/легко переписать на изменившийся синтаксис, то обычно это говорит, что всё очень, очень далеко от идеала. ;)

>or-блоки работают не только для IP-адресов. Вот реальный код, сгенерированный простеньким враппером на шелле

Ладно proto, но вот перечисление портов списком уже давным-давно просится быть вынесенными в таблицы, и соответствующие feature requests в PR висят.

[dadv.livejournal.com]

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

Можно, но некому. И не нужно.

> Ладно proto, но вот перечисление портов списком уже давным-давно просится быть вынесенными в таблицы, и соответствующие feature requests в PR висят.

Не понимаю, чем плохи or-blocks. Имена интерфейсов (разнородных) тоже хорошо в них указывать, да что угодно.
Плох парсер - переписать парсер, но синтаксис ломать "просто так" нельзя.

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

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

[dadv.livejournal.com]

Тебе не нравятся - ты не используй.

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

то же самое можно сказать и в твоем случае про новый файрвол.
вряд ли его разработка означает (по крайне мере в обозримом будущем) вынос классического ipfw

[dadv.livejournal.com]

Дай бог, если так.

вынос классического ipfw

[nuclight.livejournal.com]

Я бы предпочел именно вынос, причем поскорее. Точнее, взаимную несовместимость, или один, или другой. Совместимость гораздо удобнее тянуть на уровне оберток командной строки, чем поддерживать весь хлам кривых решений в потрохах.

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

по-моему оптимально независимое существование.
вот есть ipfw2, который через хуки и с байткодом.
для простого стателесс (ну если полечить пару багов) он многих удоволетворяет.
и новый файрвол, на нетграфе, с блэкджеком, шлюхами, интегрированным натом и исходно state full, с совсем другим синтаксисом. потом, в дальнейшем, если получится можно будет к нему написать ipfw, который будет для скриптов эмулировать синтаксис ipfw. а можно и не писать -- один черт pfil будут оставленны для ipf/pf.

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

[victor-sudakov.livejournal.com]

> pbr в файрволе не нужен, нужен отдельный модуль в роутинге для pbr,

+1

> который может использовать информацию о state (flow) из файрвола для роутинга

а это как, в смысле где посмотреть пример реализации? Я к тому, что IP, на уровне которого происходит форвардинг пакетов, у нас всё же stateless протокол.

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

нигде, это надо делать.
да, ipv4 -- state less. но если у нас есть state full файрвол, то для входящего пакета он может навесить mbuf с информацией о flow, которой этот модуль может воспользоваться. вот для сгенеренных на тазике пакетов сложнее -- они сначала на ротинг поступают, а потом уже в файрвол, занчит из этого модуля надо вызывать предварительную обработку пакета из файрвола для классификации и определения flow.

[nuclight.livejournal.com]

мнээ... похоже ты всё-таки плохо с линуксом знаком - у них это есть, см. CONNMARK (и да, первым на локальных out делается connection tracking, потом пересчитывается роутинг, если нужно)

[nuclight.livejournal.com]

Ну в линуксе с iproute2 нечто подобное. Можно посмотреть на их CONNMARK.

[ra-ga.livejournal.com]

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

[nuclight.livejournal.com]

Э, не, это точно не ко мне. В таком разрезе получится новый файрвол, а не правка существующего, и тогда это будет просто еще один новый никому не нужный файрвол. С таким подходом это тебе на http://userfw.net - чувак пишет вещь, на мой взгляд, мертворожденную.

Нет, я буду реформировать имеющийся (и кроме того, так вероятность приема в базу нужных изменений в стеке куда выше).

> да, краткое размышление говорит о том, что pbr в файрволе не нужен, нужен отдельный модуль в роутинге для pbr, который может использовать информацию о state (flow) из файрвола для роутинга. это архитектурно-идеологически выглядит более правильно.

А с точки зрения интерфейса юзера это как должно выглядеть? У меня из примеров перед глазами только iproute2 с CONNMARK

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

Э, не, это точно не ко мне. В таком разрезе получится новый файрвол, а не правка существующего

существующий править бесполезно.

С таким подходом это тебе на http://userfw.net - чувак пишет вещь, на мой взгляд, мертворожденную.

не понял цимуса

А с точки зрения интерфейса юзера это как должно выглядеть? У меня из примеров перед глазами только iproute2 с CONNMARK

ну скажем так

mark 'bge0' from any to any recv bge0

и в модуле pbr

route mark 'bge0' 1.2.3.4

предполагается, что все statefull, специально указывать что надо поддерживать state и flow не требуется и для всякого последующего файрвольного правила типа

allow from any to me port 69

будет созданно state с mark 'bge0' и для всех пакетов flow, попадающего под этот state будет повешен mark 'bge0'

как-то так, очень грубо.

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

Достойный ответ.

[nuclight.livejournal.com]

А зачем ты варишься в своем соку? Я в вики описал, что именно предлагается закопать, а что оставить, и сослался на именно это в предыдущем комменте. Даже не буду остальное комментировать, просто отошлю туда.

[dadv.livejournal.com]

Ну, там написано "its buggy and should die". Как будто новый код заведомо будет без багов.

"Все они хирурги и костоправы, нет среди них ни одного терапевта." (c)