![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
IpfwNg
В честь 26 годовщины 26 апреля уволился с текущей работы и таки наконец начал проект http://wiki.freebsd.org/IpfwNg — хотя на работе FreeBSD и была основной системой, реальную возможность пилить ядро я так и не получил (хотя тот же NAT64 нам бы понадобился не через полгода, так через год). В ближайшие недели посижу дома и надеюсь сделать хотя бы скелет, который можно будет потом уже в свободное время потихоньку пилить — работы по проекту предстоит очень много.
Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).
Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).
no subject
А про синтаксис - автоматически однозначно оптимизировать можно только линейный набор правил. Но линейный набор правил не годится для очень многих практических задач.
no subject
собственно для файрвольных правил это тоже может работать (хоть и не всегда и вообще предмет для дискурсии).
шлюз, кстати, не конкретный -- бывает и в интерфейс (даже езернетовский и я этим пользовался) и бывает несколько шлюзов.
пфф. основная проблема к производительности файрволов -- то, что они медленно отрабатывают тысячу другую правил. которые скорее будут типа
permit from {список} to host dst-port 443
deny from any to host dst-port 443
и так для 100500 разных хостов и портов, а вовсе не цепочкой из 100500 дивертов и нетграфов. т.е. они тоже могут встретиться, но их не будет 100500 последовательных и это никак не мешает 100500 линейных обрабатывать паралельно. но более другой синтаксис мог бы эту задачу облегчить и/или избавить от глупых ошибок типа
permit 10.0.0.0/8 to host
deny 10.0.1.0/24 to host
второе правило никогда не сработает.
no subject
no subject
не вижу в этом ничего плохого.
сколько в реальной жизни последовательных divert/netgraph (даже если их много -- скорее всего в реальности для каждого пакета должен выполняться один-два хука)?
это уже не будет основным тормозом.
no subject
я не готов зарубаться. на 9 слайде я нихера не понял, 99 страничный документ еще не изучал. почитаю. мне, вероятно, это будет полезно. а может нет.
меня смущают интервалы. они в принципе не работают с дырявыми масками, что ли?
routing radix tree с ними работает. ему можно сунуть синтетический IPSRC_IPDST с рваной маской и оно не подавится. с другой стороны они (я так понимаю) говорят что пусть у нас это будет два измерения -- SRC и DST. ну, наверное вариант. адекватность результата -- несколько другой вопрос и у меня пока нет четкого понимания в этом вопросе. и что будет лучше. надо думать. и опять же -- дырявые маски.
no subject
Про детали, но не настолько конкретные, а про взаимодействие.
я не готов зарубаться. на 9 слайде я нихера не понял, 99 страничный документ еще не изучал. почитаю. мне, вероятно, это будет полезно. а может нет.
Из него нужного всего ничего, а больше половины посвящено описанию устройства netfilter и того, как они героически с ним боролись. Тоже местами интересно, и мне на весь пролистать хватило час или два. Тебе нужно будет куда меньше - нужный кусок просто добавляет к девятому слайду децл текста, описывая принцип.
> меня смущают интервалы. они в принципе не работают с дырявыми масками, что ли?
У них одно правило - это более элементарный объект и гораздо более дешевый, чем обычное правило. То есть если ты пишешь маску 0xffffff0f, это эквивалентно 15 правилам с адресами .15, .31, .49 и т.д. - они у них очень дешевые. Собственно их коммерческий спонсор и решает проблему менеджмента такого невъебенного числа правил - у тебя в интерфейсе может быть дырявая маска, а в бэкенде 15 правил.
> routing radix tree с ними работает
А чо, до сих пор работает? По-моему выпилили же. И в ipfw table ты их заюзать не можешь, а это апгрейднутый table просто. Практическая применимость дырявых, кстати, сомнительна.
no subject
у меня сейчас есть вялотекущая халтурка, связанная с фильтрацией потока, так что надо мне больше и читать я буду внимательно. мне не понятны и принципы, по которым надо расставлять приоритеты дабы получить логичное поведение. ну и насколько все сложно будет, т.е. алгоритмическая сложность раскладывания масок в диапазоны плюс понятийная сложность на организацию приоритетов для логичного поведения.
я примерно так и догадался. безусловная рулезность такого подхода мне не очевидна. по крайне мере пока.
нет. по крайне мере осенью в current еще жило. и до сих пор может роутить OSI. да, несмотря на отсутвие кода поддержки OSI во FreeBSD если этому радикстри подсунуть OSIшный адрес -- он сделает верный лукап. принципиально там (в лукапе по дереву) ничего с bsd reno не менялось
это не имеет значения, в обычном-то правиле можно, а говорим мы про обычные правила.
во-первых вони будет...
во-вторых смотри шире: правило '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'. ну и какая после этого принципиальная разница в каком именно месте у тебя дыра, если она все равно есть?
no subject
Аа, вон ты о чем. Да, красивая идея. Но здесь, однако, возникают вопросы:
1) Как оно работает в случае нескольких таких с дырками? В случае префиксов всё просто и однозначно. Я в алгоритм радикса не вникал на таком уровне, чтобы понимать работу дырок.
2) Насколько быстро оно будет работать? Радикс побитовый, и я подозреваю, что на строках в сотни бит оно будет тормозить - O(log2 N) уже немаленький станет.
> я примерно так и догадался. безусловная рулезность такого подхода мне не очевидна. по крайне мере пока.
А у нас есть выбор? Эта штука, по крайней мере, проверена и работает, из альтернатив разве что предложенный тобой выше радикс. Я как-то пробовал посмотреть на проблему матчинга пакета с точки зрения выборки в SQL, но ту математику ниасилил.
>мне не понятны и принципы, по которым надо расставлять приоритеты дабы получить логичное поведение.
Это-то как раз просто и интуитивно понятно. Правила идут последовательно, кто первое совпало, того и тапки. Как ранний ipfw1, еще без всяких skipto и дивертов.
> нет. по крайне мере осенью в current еще жило. и до сих пор может роутить OSI. да, несмотря на отсутвие кода поддержки OSI во FreeBSD если этому радикстри подсунуть OSIшный адрес -- он сделает верный лукап. принципиально там (в лукапе по дереву) ничего с bsd reno не менялось
Ну да, можно, я знаю. Вон
> это не имеет значения, в обычном-то правиле можно, а говорим мы про обычные правила.
> во-первых вони будет...
>ну и насколько все сложно будет, т.е. алгоритмическая сложность раскладывания масок в диапазоны плюс понятийная сложность на организацию приоритетов для логичного поведения.
Мнээ... Ну это если конвертер из существующих правил в это писать. Мне такая задача не очень улыбается. Но тут, судя по комментам, userbase готова к введению расширенных таблиц. А когда это новый синтаксис - никто вонять не будет, что там примитивные правила, и дырки не поддерживаются. Т.е. останутся обычные правила, а новые будут примерно так:
ipfw add 30 allow ruletable(wan_rules)
ipfw ruletable wan_rules add tablearg 100 from 1.2.3..0/24 to 5.6.7.8 src-port 1234 dst-port 80 ipttl 9-255 ...
т.е. внутренний синтаксис в стиле ipfw1, примитивный как в nf-hipac. А в основном ipfw - вызовы ruletable, netgraph, divert и пр., которые не соптимизировать, и обычные правила, если нужны.
Более того, мне тут щас в голову пришла идея - один из ruletable вызывается в ip_forward() примерно так:
if (M_FIB(mbuf) == 0) setfib mbuf, ruletable(ip_rule);А-ля в iproute2. Тогда решается проблема того, что классификация для PBR идентична задаче файрвола и неплохо бы в том же синтаксисе, но иметь его нужно отдельно. Парсер будет тот же в ipfw, не придется учить отдельный синтаксис.
no subject
он исходно с дырками. он даже не знает где адрес начинается, для него это просто дырка от начала пакета
у него сложность log2 от количества правил. и нет, строки как строки через него гонять неправильно. строги надо через регэкспы гонять. но до строк имеет смысл поставить радикс.
выбор есть всегда. и радикс для IP адресов я на днях попробую (по халтуре заказчик созрел на попробовать этот вариант, последовательное сравнение правил по скорости не устраивает).
это медленно. на приличном количестве правил ты даже гигабит не обработаешь. а сечас надо обрабатывать 10 и смотреть на 40. иначе -- просто потрать энергию на девушек.
это без поллитры не грокнуть. и потом на живой системе не посмотреть нормально, что бы сразу разобраться.