Nuclear Lightning&#39;s Track

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

From:

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

From:

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

From:

Переписать автогенерацию может быть не проще, если написано три года назад тем, кто уже уволился и всё 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

From:

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

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

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

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

From:

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

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

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

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

From:

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

From:

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

From:

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

From:

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

From:

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

From:

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

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

From:

victor-sudakov.livejournal.com

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

+1

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

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

From:

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

From:

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

(no subject)

From:

http://users.livejournal.com/_slw/ - Date: 2012-05-18 02:09 pm (UTC) - Expand

(no subject)

From:

nuclight.livejournal.com - Date: 2012-05-31 10:00 pm (UTC) - Expand

(no subject)

From:

http://users.livejournal.com/_slw/ - Date: 2012-06-01 04:27 am (UTC) - Expand

From:

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

From:

ну понятно что идеологически что-то иное трудно придумать.
но синтаксис у них -- бюэ

From:

ra-ga.livejournal.com

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

From:

victor-sudakov.livejournal.com

Примерно понял. Нечто подобное наверное можно изобразить и на нынешнем ipfw с помощью tag и setfib, но опять же это только низкоуровневый инструмент в руках. Осмелюсь заметить, что usability у такого способа низкая.

(no subject)

From:

nuclight.livejournal.com - Date: 2012-05-31 11:21 pm (UTC) - Expand

From:

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

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

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

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

From:

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

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

С таким подходом это тебе на 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'

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

From:

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

Я так не считаю, и это один из центральных моментов моего проекта. Я буду править существующий.

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

Ну или вот http://blog.imax.in.ua/2012/02/userfw-freebsd.html почитай - чувак загорелся сделать новый файрвол. И делает. Даже код есть и как-то работает. По внутренней структуре (коя ему больше интересна) оно очень похоже на iptables, и в общем-то вполне годно и неплохо. Вот только нахуй никому не нужно, пара человек всего заинтересовалась за полгода. Он постоянно пристает в IRC к девелоперам, что на #freebsd, что на канале коммиттеров, "давайте пилить userfw". Но никто не хочет. Догадаешься, почему так?

> mark 'bge0' from any to any recv bge0

Как-то внутренняя работа всех этих конструкций не очень ясна. В iptables хотя бы явные копирования из тега пакета в тег flow...

(no subject)

From:

http://users.livejournal.com/_slw/ - Date: 2012-06-01 04:35 am (UTC) - Expand

From:

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

From:

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

From: