IpfwNg

[nuclight]

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

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

Comments

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

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

[nuclight.livejournal.com]

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

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

я никогда не выдавал себя за знатока линуха.

по сегодняшним размышлениям я понял, что 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 информации

[nuclight.livejournal.com]

32 байта для flow mark хватит? =) Я именно столько планирую отвести в dynrule под регистры, держи в них себе данных сколько хошь. Цифра из расчета держать 1 IPv6-адрес + что-нибудь еще полезное + ровный размер.

В VoIP я дуб, так что пример твой не понял, каким именно образом там бегает. Про строку вызова тоже - там в каждом UDP-пакете соединения этот номер есть, что ли? Или как иначе отслеживать, если потом опять голый 5-tuple останется?

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

мало. это всего 8 раз по 32 бита. 32 бита надо на одну flow mark, значит у нас может быть стек только из 8 меток. мало

в каждом пакете сигнализации есть call-id: identificator. он на протяжении вызова не меняется.
кто такие пакеты соединения я не знаю.
есть еще пакеты media, но они сначала описываются в пакете сигнализации с типом sdp.
в медиа его нет, разумеется