![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
nuclightВ честь 26 годовщины 26 апреля уволился с текущей работы и таки наконец начал проект http://wiki.freebsd.org/IpfwNg — хотя на работе FreeBSD и была основной системой, реальную возможность пилить ядро я так и не получил (хотя тот же NAT64 нам бы понадобился не через полгода, так через год). В ближайшие недели посижу дома и надеюсь сделать хотя бы скелет, который можно будет потом уже в свободное время потихоньку пилить — работы по проекту предстоит очень много.
Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).
Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-05-10 09:53 am (UTC)вряд ли его разработка означает (по крайне мере в обозримом будущем) вынос классического ipfw
no subject
Date: 2012-05-10 10:30 am (UTC)вынос классического ipfw
Date: 2012-05-10 09:28 pm (UTC)no subject
Date: 2012-05-10 09:43 pm (UTC)вот есть ipfw2, который через хуки и с байткодом.
для простого стателесс (ну если полечить пару багов) он многих удоволетворяет.
и новый файрвол, на нетграфе, с блэкджеком, шлюхами, интегрированным натом и исходно state full, с совсем другим синтаксисом. потом, в дальнейшем, если получится можно будет к нему написать ipfw, который будет для скриптов эмулировать синтаксис ipfw. а можно и не писать -- один черт pfil будут оставленны для ipf/pf.
да, краткое размышление говорит о том, что pbr в файрволе не нужен, нужен отдельный модуль в роутинге для pbr, который может использовать информацию о state (flow) из файрвола для роутинга. это архитектурно-идеологически выглядит более правильно.
no subject
Date: 2012-05-11 01:58 am (UTC)+1
> который может использовать информацию о state (flow) из файрвола для роутинга
а это как, в смысле где посмотреть пример реализации? Я к тому, что IP, на уровне которого происходит форвардинг пакетов, у нас всё же stateless протокол.
no subject
Date: 2012-05-11 06:31 am (UTC)да, ipv4 -- state less. но если у нас есть state full файрвол, то для входящего пакета он может навесить mbuf с информацией о flow, которой этот модуль может воспользоваться. вот для сгенеренных на тазике пакетов сложнее -- они сначала на ротинг поступают, а потом уже в файрвол, занчит из этого модуля надо вызывать предварительную обработку пакета из файрвола для классификации и определения flow.
no subject
Date: 2012-05-18 01:17 am (UTC)no subject
Date: 2012-05-18 02:09 pm (UTC)по сегодняшним размышлениям я понял, что flow mark должны быть стэкируемые. например sip:
IP_A-IP_B -- сигнализация, flow1 (две ip атс, которые сигнализацию пускают через себе, а медию -- напрямую).
клиент_1 делает звонок. клиент_2 делает звонок.
на сигнализацию звонка между IP_A и IP_B уже надо по две марки -- flow1:flow2 для клиента1 и flow1:flow3 для клиента2.
когда у них пойдет RTP -- то отслеживать их надо будет независимо.
или вот еще уебище, которое никто сечас кажется неможет нормально натить -- 79xx с SIP-прошивкой -- оно гадит сигнализацией с произвольно порта, а принимать сигнализацию хочет исключительно на 5060. соответсвенно надо проброс SIP делать (если у нас несколько телефонов за nat) анализируя строку вызова (телефонный номер) -- это к твоему предыдущему вопросу про 5 тупле. 5 тупле одинаковые, а разделение должно идти уже по SIP информации
no subject
Date: 2012-05-31 10:00 pm (UTC)В VoIP я дуб, так что пример твой не понял, каким именно образом там бегает. Про строку вызова тоже - там в каждом UDP-пакете соединения этот номер есть, что ли? Или как иначе отслеживать, если потом опять голый 5-tuple останется?
no subject
Date: 2012-06-01 04:27 am (UTC)в каждом пакете сигнализации есть call-id: identificator. он на протяжении вызова не меняется.
кто такие пакеты соединения я не знаю.
есть еще пакеты media, но они сначала описываются в пакете сигнализации с типом sdp.
в медиа его нет, разумеется
no subject
Date: 2012-05-18 01:14 am (UTC)no subject
Date: 2012-05-18 02:56 pm (UTC)но синтаксис у них -- бюэ
no subject
Date: 2012-05-29 11:32 pm (UTC)no subject
Date: 2012-05-30 02:02 am (UTC)no subject
Date: 2012-05-31 11:21 pm (UTC)http://habrahabr.ru/post/49137/
http://habrahabr.ru/post/55132/
Там, конечно, лишнего хватает, вот статья с чисто экстрактом правил по теме:
http://habrahabr.ru/post/117620/
И объяснением, что:
Почти такие же наши tag, причем вызванные тем, что у них порядок прохождения пакета по стеку жестко фиксирован.
Я надеюсь с помощью ruletable на месте вызова ip rule + возможности setfib в файрволе - делать их в динамических правилах - сделать так, что у нас эта задача будет конфигурироваться проще.
no subject
Date: 2012-05-18 01:24 am (UTC)Нет, я буду реформировать имеющийся (и кроме того, так вероятность приема в базу нужных изменений в стеке куда выше).
> да, краткое размышление говорит о том, что pbr в файрволе не нужен, нужен отдельный модуль в роутинге для pbr, который может использовать информацию о state (flow) из файрвола для роутинга. это архитектурно-идеологически выглядит более правильно.
А с точки зрения интерфейса юзера это как должно выглядеть? У меня из примеров перед глазами только iproute2 с CONNMARK
no subject
Date: 2012-05-18 02:55 pm (UTC)существующий править бесполезно.
не понял цимуса
ну скажем так
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'
как-то так, очень грубо.
no subject
Date: 2012-05-31 10:16 pm (UTC)Я так не считаю, и это один из центральных моментов моего проекта. Я буду править существующий.
>"С таким подходом это тебе на 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
Date: 2012-06-01 04:35 am (UTC)что я, как пользователь, получу в результате?
он будет быстрее? удобнее его настраивать будет?
будет поддерживаться много протоколов?
короче, какие конкурентные преимущества?
нет?
ну или я не понял.
ну вот потому никто и не хочет.
ты, кстати, рискуешь получить тоже самое.
не понимаю вопроса