nuclight | IpfwNg

Entry tags:

IpfwNg

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

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

Threaded | Top-Level Comments Only

я не знаю что ты имеешь ввиду под отслеживать, но в любом случае отслеживать маршрутизацию я не говорил

да, будут разделения на блоки.
не вижу в этом ничего плохого.
сколько в реальной жизни последовательных divert/netgraph (даже если их много -- скорее всего в реальности для каждого пакета должен выполняться один-два хука)?
это уже не будет основным тормозом.

Бля.
Ещё раз, чётко ответьте, что вы хотите делать с помощью firewall для [некорректной работы] динамической маршрутизации.

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

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

э, какой еще некорректной? я где сказал слово некорректная?

ну что тут сложного. есть у нас bge0 с серверами. 10.1.2.0/24. там сервер 10.1.2.3. у клиентов (bge2) с ним сессии.

нехороший редиска с сети подключенной к bge1 анонсит 10.1.2.3/32. никакие rpf не запретят ходить пакетам с bge1 с src 10.1.2.3. и трафик имеющихся сессий клиентов с bge2 попрет на этот подложный сервер. так вот, состояния сессиий этого не должны допускать (если админу это надо, конечно). т.е. состоянии сессии привязанно к паре интерфейсов (bge0-bge2) в нашем случае. и для bge2-bge1 у нас такой сессии нет, пакет сессии не соответсвует, он должен быть дропнут а в логах сообщение о событии "пакет вне сессии".

А чего заранее ограничиваться? И не cisco, а вообще. В идеале хочется, чтобы все задачи можно было решать.

нахуй? в cisco policy-map используется и для фильтрации bgp маршрутов и не помню для чего еще. зачем тебе это?
там это совершенно перегруженная и недокументированная комманда/модуль.

Ээ, падажжы. Это ж fwd 127.0.0.1,3128 который? Там nat не нужен и даже близко не стоит. Даже в иптаблесах он емнип делается в таблице nat, но не самим натом.

я про мнесто в синтаксисе. что это надо отделять от просто pbr. что это на самом деле не pbr.

А теперь обьясните, чем для данного случая вас не устраивает имеющийся механизм ipfw verrevpath и, шире, RPF check?

На всякий случай напомню:

     verrevpath
	     For incoming packets, a routing table lookup is done on the
	     packet's source address.  If the interface on which the packet
	     entered the system matches the outgoing interface for the route,
	     the packet matches.  If the interfaces do not match up, the
	     packet does not match.  All outgoing packets or packets with no
	     incoming interface match.

	     The name and functionality of the option is intentionally similar
	     to the Cisco IOS command:

		   ip verify unicast reverse-path

	     This option can be used to make anti-spoofing rules to reject all
	     packets with source addresses not from this interface.  See also
	     the option antispoof.

Edited 2012-05-18 14:32 (UTC)

потому что он просто не работает тут.
не согласен? покажи как он тут сработает.

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

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

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

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

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

потому что он тут просто не сработает
не согласен? покажи как сработает.

ты это уже проконкретные детали реализации спрашиваешь?
я не готов зарубаться. на 9 слайде я нихера не понял, 99 страничный документ еще не изучал. почитаю. мне, вероятно, это будет полезно. а может нет.
меня смущают интервалы. они в принципе не работают с дырявыми масками, что ли?
routing radix tree с ними работает. ему можно сунуть синтетический IPSRC_IPDST с рваной маской и оно не подавится. с другой стороны они (я так понимаю) говорят что пусть у нас это будет два измерения -- SRC и DST. ну, наверное вариант. адекватность результата -- несколько другой вопрос и у меня пока нет четкого понимания в этом вопросе. и что будет лучше. надо думать. и опять же -- дырявые маски.

Вопрос ко всем: а когда в -current будет pf не из древнего опенка?

Когда кто-нибудь, кому pf важен, обновит его в current из свежего опенка.

Именно так работает эта система.

> вот тут да -- 5 тупле в пролете. и не на 5 тупле ориентироваться, мне кажется можно вообще не завязываться напрямую на IP.
> я предлагаю фрэймворк. т.е. когда действительно то, что получится может никак не быть предусмотренно проектировщиком файрвола.

Это, конечно, интересно, но здесь громадная проблема - производительность. Когда там 5-tuple и FSM того же TCP сразу захаркожены на Си - производительность приличная. Как только мы вводим этот уровень абстракции - она сразу падает, возможно весьма значительно. Тут вон производительность pf и libalias даже на одном ядре сравнивали - заметно отличается, при том что оба на сях. Потому что куча всякого роляет типа кэшей процессора и др. (там RB-дерево vs хэш).

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

> нет, алгоритмическая -- плохое слово. алгоритм не оптимизируется, он относительно стандартный. паралельное -- тоже плохое слово, согласен.

Алгоритмическая значит - оптимизируется заменой алгоритма с тупого на умный.

> не понимаю, какая декомпиляция. и мне не видно чего бы тут "операции" были сущестенно мельче.

А ты в tcpdump -d хотя б погляди, на какой-нибудь аналог правила ipfw. Да, некоторые опкоды оттранслируются один в один. Но другие - разъедутся в десятки. Декомпиляция - возможность из опкодов собрать обратно исходник для операции листинга (ipfw show, iptables -L), так, чтобы исходник не хранить - мало ли его кто потёр или изменил или он там нечитаем (случаи разные бывают, по идее в файрвол должно быть можно вкурить по выводу листинга из ядра, на что Корчмарь и ругался, что у ipfw это сложнее).

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

Было б оно совсем кривое, оно б не выжило. Да и у нас проблема выжить, и если это мало кто осилит - значит не годится. К тому же не забывай про правило 80/20 и что оно пока делается в одиночку, и даже мной отнюдь не всё время даже без работы (на халтурках подрабатывать приходится) - если сильно уж навернуть, можно ниасилить.

> я понял, но смысл именно в том, что не было исполнения виртуальной машиной. т.е. что бы делалось одно-несколько деревьев по которым делался бы анализ. да, потом, некторые операции будут выполняться, в этом смысле наверное виртуальная машина и bpf. но в этом смысле и ipfw сейчас -- bpf.

Кхе. А ты думаешь это реально? Я что-то не встречал алгоритмов перевода из псевдокода инструкций в дерево. Рассматривавшийся пример hipac - он по фиксированному набору чисел делает, никакого произвольного набора полей, а тем более строк или даже регэксопв для SIP, там и близко нет. Такая тема тянет на докторскую, пожалуй =) Сочинить такое своё я пожалуй точно ниасилю.

> backreferences пожалуй не нужен. вот что точно нужно -- эффективное определение какая альтернатива сработала (в pcre после срабатывания (GET|PUT|POST) надо еще отдельный анализ устраивать кто из трех сработал. ну и аналогично, если мы пять правил в одно через "или" объеденили -- как узнать какое сработало? в pcre неудобно.

> нет, по крайне мере не совсем. я предлагаю на псевдоязыке описывать только протокол. а правила фильтрации -- боле-менее обычным образом, но описание на псевдоязыке дают возможность в правилах фильтрации использовать параметры описанных протоколов.

> попробую. в воскресенье на поезде ехать -- как раз буду бумагу чирикать. это, вероятно, будет чем-то похоже на описание MIBов

Вот без примеров непонятно, что ты имеешь в виду. То есть, для конструктивного продолжения нужно на чем-то предметном обсуждать, а не в общем. Ну как, воскресенье прошло, начеркал?..

> ты это уже проконкретные детали реализации спрашиваешь?

Про детали, но не настолько конкретные, а про взаимодействие.

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

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

> меня смущают интервалы. они в принципе не работают с дырявыми масками, что ли?

У них одно правило - это более элементарный объект и гораздо более дешевый, чем обычное правило. То есть если ты пишешь маску 0xffffff0f, это эквивалентно 15 правилам с адресами .15, .31, .49 и т.д. - они у них очень дешевые. Собственно их коммерческий спонсор и решает проблему менеджмента такого невъебенного числа правил - у тебя в интерфейсе может быть дырявая маска, а в бэкенде 15 правил.

> routing radix tree с ними работает

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

Нащот всего коммента разом - я только из ветки ответивших людей понял, что на самом деле потребность не в нескольких таблицах состояний, а в фиксировании исходный интерфейсов в стейте с отсеканием при не тех (опционально с воплями). Рисовать на компе - это тот еще пиздец, совсем не реалтаймовый. Скайпы и прочее - пардон, _мне_ аудио-режим неудобен. Разговаривать в реале и на бумажке при этом чёркать - это да, это может быть продуктивно. Написать несколько экранов текста в оффлайне с картинками - это тоже продуктивно. Всё остальное - варьируется, и поскольку реализовывать мне - причем мне за это не платят - то и выбирать мне. Если хочешь что-то донести, то уж будь добр, приложи к тому усилия - от тебя их и так на порядки меньше требуется, чем от меня. А пока что меня несколько раздражает даже корявое оформление комментариев - больших букв в предложениях нет, цитаты не отделены, приходится тратить лишнее время и напрягать глаза, чтобы распарсить и поскипать ненужное.

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

фактически для реализации этого и надо несколько пространств стейтов. поскольку, например, адрес A в двух разных FIB может являться разным адресом. ну в двух разных VIRTNET -- просто однозначно. но (я про это не писал, но это есть следствие того, за что я агитирую) -- должен ли файрвол [транзитный] для своей работы иметь в ядре сконфигурированные сущности (протоколы, virtnetы), по которым работает? я считаю -- нет, не обязательно. т.е. например фильтрацию в vlan можно устраивать не создавая интерфейс vlan в ядре.

Скайпы и прочее - пардон, _мне_ аудио-режим неудобен. Разговаривать в реале и на бумажке при этом чёркать - это да, это может быть продуктивно. Написать несколько экранов текста в оффлайне с картинками - это тоже продуктивно.

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

А пока что меня несколько раздражает даже корявое оформление комментариев - больших букв в предложениях нет, цитаты не отделены, приходится тратить лишнее время и напрягать глаза, чтобы распарсить и поскипать ненужное.

скажем спасибо жж. на почту твои каменты тоже приходят в несколько странном виде. в вебинтерфейсе с цитатами понятнее. хорошо хоть лимит на объем камента подняли, с четыремя килобайами вообще ничего длинного не изложить было.

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

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

У них одно правило - это более элементарный объект и гораздо более дешевый, чем обычное правило. То есть если ты пишешь маску 0xffffff0f, это эквивалентно 15 правилам с адресами .15, .31, .49 и т.д. - они у них очень дешевые. Собственно их коммерческий спонсор и решает проблему менеджмента такого невъебенного числа правил - у тебя в интерфейсе может быть дырявая маска, а в бэкенде 15 правил.

я примерно так и догадался. безусловная рулезность такого подхода мне не очевидна. по крайне мере пока.

А чо, до сих пор работает? По-моему выпилили же.

нет. по крайне мере осенью в current еще жило. и до сих пор может роутить OSI. да, несмотря на отсутвие кода поддержки OSI во FreeBSD если этому радикстри подсунуть OSIшный адрес -- он сделает верный лукап. принципиально там (в лукапе по дереву) ничего с bsd reno не менялось

И в ipfw table ты их заюзать не можешь, а это апгрейднутый table просто.

это не имеет значения, в обычном-то правиле можно, а говорим мы про обычные правила.

Практическая применимость дырявых, кстати, сомнительна.

во-первых вони будет...
во-вторых смотри шире: правило 'permit from 10/8 to 192.168/16' суть правило для синтетического адреса 'permit IPSRC_IPDST 10.0.0.0.192.168.0.0 wildcards 0.255.255.255.0.0.255.255'. ну и какая после этого принципиальная разница в каком именно месте у тебя дыра, если она все равно есть?

Это, конечно, интересно, но здесь громадная проблема - производительность. Когда там 5-tuple и FSM того же TCP сразу захаркожены на Си - производительность приличная. Как только мы вводим этот уровень абстракции - она сразу падает, возможно весьма значительно.

возможно да. возможно нет. я пока не вижу принципиальных проблем реализации 5-тупле в виде абстракции с той же производительностью (ну почти той же). в конце концов 5-тупле -- это 3 поля фиксированной длинны по фиксированному смещению + 2 поля фиксированной длинны по чуть менее произвольному смещению. 5 операций косвенности условно говоря. скорее всего на общем фоне разницы не будет. с FSM не так очевидно. но почему бы FSM в виде талицы должна быть существнно медленнее FSM на switch?

ну и кроме того, FPGA ты не обгонишь, а скрость кодирования поддержки новых протоколов и расширения -- она не менее важна, а скорее и более. в конце концов более двух десяток в тазик нынче не актуально, а 24 ядра на это хватит (если десток не две, то их скорее всего надо уже двадцать четыре, а столько в тазик не запихаешь да и память и pci-e сдохнет).

Тут вон производительность pf и libalias даже на одном ядре сравнивали - заметно отличается, при том что оба на сях. Потому что куча всякого роляет типа кэшей процессора и др. (там RB-дерево vs хэш).

а у кого что, у кого сколько?

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

10гбит на одном ядре невозможно и не нужно. отключение чего в iptables?
и да, statefull производительность будет просаживать. безусловно. независимо от реализации. это надо понимать и на это надо идти. просто надо либо отключать state либо в таких случая предлагать использовать обычный ipfw, почему нет? как stateless от вполне употребимый, поскольку работает в контексте прерывания драйвера -- по ядрам раскладывается сам. в конце концов от Cat6500 на 10G/40G никто умных acl не ждет -- они там простые, которые в FPGA реализованны.

А ты в tcpdump -d хотя б погляди, на какой-нибудь аналог правила ipfw. Да, некоторые опкоды оттранслируются один в один. Но другие - разъедутся в десятки. Декомпиляция - возможность из опкодов собрать обратно исходник для операции листинга (ipfw show, iptables -L), так, чтобы исходник не хранить - мало ли его кто потёр или изменил или он там нечитаем (случаи разные бывают, по идее в файрвол должно быть можно вкурить по выводу листинга из ядра, на что Корчмарь и ругался, что у ipfw это сложнее).

в листе дерева можно хранить ссылку на строку, из которой этот лист образовался и показывать именно ее. gdb ведь не занимается декомпиляцией до си при пошаговой отладке.

Было б оно совсем кривое, оно б не выжило. Да и у нас проблема выжить, и если это мало кто осилит - значит не годится. К тому же не забывай про правило 80/20 и что оно пока делается в одиночку, и даже мной отнюдь не всё время даже без работы (на халтурках подрабатывать приходится) - если сильно уж навернуть, можно ниасилить.

да, делать надо так, что бы 80% обычных пользователей было понятно, сложности от них были спрятанны, задачи решались бы легко. смысла делать еще одну простую поделку я не вижу. потребности в еще одном обычном ~~стиральном порошке~~ файрволе, но в нетграфе -- нет. файрвол нужен хороший и в котором добавление поддержки еще одного протокола не выливается в месяц работы. если трудоемкость будет высокая, но профит очевидный -- трудовые ресурсы как-то найти будет можно. но это потом.

в камент бладж не влазит

Кхе. А ты думаешь это реально? Я что-то не встречал алгоритмов перевода из псевдокода инструкций в дерево.

а! вот про это я и твержу тебе! с псевдокодом и инструкциями работать уже поздно, работать надо сразу с правилами. потому что правила в дерево свернуть реально, а псевдокод -- уже заипешься. потому и говорю, что термин алгоритмическая оптимизация тут неверный, тут не оптимизация псевдокода идет.

а построение дерева из правил -- да, реально. и как мне кажется даже не очень сложно, даже с учетом абстракций. т.е. да, первоначальный кусок будет довольно трудоемкий, но зато потом все будет на несколько порядков быстрее и легче.

никакого произвольного набора полей, а тем более строк или даже регэксопв для SIP, там и близко нет. Такая тема тянет на докторскую, пожалуй =) Сочинить такое своё я пожалуй точно ниасилю.

да нет, вроде ничего особо сложного нет. тем более докторской, ведь аналитически исследовать не требуется. а если посмотреть на текущий код raidix tree для роутинга (в которм закодированны комманды посмотреть бит по смещению x и которе реально ничего не знает про протокол, который роутит, там даже таблицы виртуальных методов нет на момент роутинг лукапа) то в общем-то это уже и так почти готовое "по произвольному набору полей". ну и вот hipac -- на самом деле о том же самом, то что там нет произвольного набора -- это проблема фронтенда, сам-то механизм именно что по произвольному набору работает. т.е. надо различать проблемы собственно лукапа и построения дерева для работы этого лукапа. ну со строками отдельный момент, их надо вторым эшелоном пускать, видимо.

Вот без примеров непонятно, что ты имеешь в виду. То есть, для конструктивного продолжения нужно на чем-то предметном обсуждать, а не в общем. Ну как, воскресенье прошло, начеркал?..

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

DEF Eth :=
     dst_mac := octets(6) format eth_addr
     src_mac := octets(6) format eth_addr
     ethtype := uint16 byteorder MSB format hex

DEF Eth := -- 802.1q
     dst_mac := octets(6) format eth_addr
     src_mac := octets(6) format eth_addr
     tpid := uint16 byteorder MSB format hex eq 8100
     tci := uint16 byteorder MSB is
        vid := uint:12
        cfi := uint:1
        pcp := uint:3;
     ethtype := uint16 byteorder MSB format hex

DEF IPoEth :=
     Eth(ethtype eq 0800)
     IP_hdr

DEF IP_hdr (size = ihl*4) :=
     octet is
        ihl := uint:4
        ver := uint:4 eq 4;
     tos := uint8;
     total := uint16 byteorder msb
     id := uint16 byteorder msb
     uint16 byteorder msb is
         frag_offset := uint:13
         flags := uint:3 is
            mf := uint:1
            df := uint:1
     ttl := uint8
     proto := uint8
     hdr_csum := uint16 byteorder msb
     ip_src := octets(4) format ipv4
     ip_dst := octets(4) format ipv4
     options := fill IP_options

DEF UDPoIP :=
     IP_hdr(proto eq 17)
     UDP_hdr

DEF UDP_hdr :=
     sport := uint16 byteorder msb
     dport := uint16 byteorder msb
     len := uint16 byteorder msb
     udpcsum := uint16 byteorder msb format hex

получилось не очень хорошо, но в первом приближении так. не описана фрагментация, но мне кажется с этим можно справиться (надо ввести понятие stream и написать как ip фрагменты складываются в stream, который суть ip пакет размером более mtu. поскольку файрволу не надо терминировать в терминах ядра на себе протоколы, то такой путь вроде как возможен и нормален. ну и udp после этого будет не стекированным над ip заголовком, а внутри ip stream. а tcp будет свой stream порождать)

> файрвол нужен хороший и в котором добавление поддержки еще одного протокола не выливается в месяц работы.

На эту тему был какой-то прогресс у imax: http://blog.imax.in.ua/2012/02/userfw-freebsd.html

разумеется нет. если кодить разбор протокола на си --- месяц работы будет полюбому

Субмодули на любом языке описания протокола для модуля, который будет парсить язык и делать таблички :-)

Threaded | Top-Level Comments Only

Page 6 of 8

IpfwNg

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

Способ коммуникации лучше тот, который удобен мне, а не

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject