![[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
> я предлагаю фрэймворк. т.е. когда действительно то, что получится может никак не быть предусмотренно проектировщиком файрвола.
Это, конечно, интересно, но здесь громадная проблема - производительность. Когда там 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ов
Вот без примеров непонятно, что ты имеешь в виду. То есть, для конструктивного продолжения нужно на чем-то предметном обсуждать, а не в общем. Ну как, воскресенье прошло, начеркал?..
no subject
возможно да. возможно нет. я пока не вижу принципиальных проблем реализации 5-тупле в виде абстракции с той же производительностью (ну почти той же). в конце концов 5-тупле -- это 3 поля фиксированной длинны по фиксированному смещению + 2 поля фиксированной длинны по чуть менее произвольному смещению. 5 операций косвенности условно говоря. скорее всего на общем фоне разницы не будет. с FSM не так очевидно. но почему бы FSM в виде талицы должна быть существнно медленнее FSM на switch?
ну и кроме того, FPGA ты не обгонишь, а скрость кодирования поддержки новых протоколов и расширения -- она не менее важна, а скорее и более. в конце концов более двух десяток в тазик нынче не актуально, а 24 ядра на это хватит (если десток не две, то их скорее всего надо уже двадцать четыре, а столько в тазик не запихаешь да и память и pci-e сдохнет).
а у кого что, у кого сколько?
10гбит на одном ядре невозможно и не нужно. отключение чего в iptables?
и да, statefull производительность будет просаживать. безусловно. независимо от реализации. это надо понимать и на это надо идти. просто надо либо отключать state либо в таких случая предлагать использовать обычный ipfw, почему нет? как stateless от вполне употребимый, поскольку работает в контексте прерывания драйвера -- по ядрам раскладывается сам. в конце концов от Cat6500 на 10G/40G никто умных acl не ждет -- они там простые, которые в FPGA реализованны.
в листе дерева можно хранить ссылку на строку, из которой этот лист образовался и показывать именно ее. gdb ведь не занимается декомпиляцией до си при пошаговой отладке.
да, делать надо так, что бы 80% обычных пользователей было понятно, сложности от них были спрятанны, задачи решались бы легко. смысла делать еще одну простую поделку я не вижу. потребности в еще одном обычном
стиральном порошкефайрволе, но в нетграфе -- нет. файрвол нужен хороший и в котором добавление поддержки еще одного протокола не выливается в месяц работы. если трудоемкость будет высокая, но профит очевидный -- трудовые ресурсы как-то найти будет можно. но это потом.no subject
На эту тему был какой-то прогресс у imax: http://blog.imax.in.ua/2012/02/userfw-freebsd.html
no subject
no subject
no subject
описание протоколов должно быть декларативное, общее, что бы можно было все свести воедино и построить оптимальное дерево разбора.
и это, состояний и потоков у него так же нет.
no subject
no subject
тех, которые в понятии statefull.
no subject
а! вот про это я и твержу тебе! с псевдокодом и инструкциями работать уже поздно, работать надо сразу с правилами. потому что правила в дерево свернуть реально, а псевдокод -- уже заипешься. потому и говорю, что термин алгоритмическая оптимизация тут неверный, тут не оптимизация псевдокода идет.
а построение дерева из правил -- да, реально. и как мне кажется даже не очень сложно, даже с учетом абстракций. т.е. да, первоначальный кусок будет довольно трудоемкий, но зато потом все будет на несколько порядков быстрее и легче.
да нет, вроде ничего особо сложного нет. тем более докторской, ведь аналитически исследовать не требуется. а если посмотреть на текущий код raidix tree для роутинга (в которм закодированны комманды посмотреть бит по смещению x и которе реально ничего не знает про протокол, который роутит, там даже таблицы виртуальных методов нет на момент роутинг лукапа) то в общем-то это уже и так почти готовое "по произвольному набору полей". ну и вот hipac -- на самом деле о том же самом, то что там нет произвольного набора -- это проблема фронтенда, сам-то механизм именно что по произвольному набору работает. т.е. надо различать проблемы собственно лукапа и построения дерева для работы этого лукапа. ну со строками отдельный момент, их надо вторым эшелоном пускать, видимо.
no subject
попробую пробиться через жжшечку. много не успел, в купе попался спиногрых сверактивный -- мозг вынесен нах.
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 порождать)
Пример языка
А вот то, что уровнем выше, и что ты проповедовал как замену хелперам, то более значимо повлияет на архитектуру, покажи лучше это.
no subject
так же мне не очевидно, почему следует ip поддерживать базово, в смысле чем он отличается от pppoe, gre, ipip... ну и будет ли выйгрыш в скорости, поскольку при базовом разборе ip его разбирают целиком, а при таком варианте разбор возможно будет происходить только частично и только когда надо. в смысле этакие ленивые вычисления. это может довольно сильно усложнить "компилятор" (а может и нет), но вряд ли скажется на эффективности обработки. и мне кажется, что можно с нуля вот так все описать.
да, при этом потребуются некоторые примитивы: преобразование в текстовый вид и обратно 8/16/32 битных чисел, ipv4/6 (а при добавлении протоколов дополнительные примитивые -- asn1 для h.323, побайтовое-через-запятую представление для ftp -- это надо будет делать модулями с реализацией на си); для отслеживания сесиий -- хэши и деревья от комбинаций битовых полей, для nat -- мапинг битовых полей одной размерности в другую.
я напишу пример для sip, но не сегодня -- я его на память не помню и надо будет rfc в очередной раз освежать в памяти.
no subject
вот как-то так
я синтаксисом не доволен, но хоть как-то так.
no subject
ах да. я совсем забыл сказать-уточнить.
дерево (radix tree роутинга, условно говоря) используется для выбора правил, с которым собственно и идет сравнение. т.е. в дереве в узлах указывается какой бит следует анализировать, приходим к узлу в котором реальное правило (типа смещение в пакете, длинна, маска, образец). если правило под пакет не подошло -- дерево используется для выбора альтернативного, более общего правила.
т.е. деревом анализируются отдельные биты, что бы выбрать конкретное правило для полного сопоставления с пакетом. поэтому на этапе работы с пакетом код файрвола может не заморачиваться детальными знаниями о протокле -- его интересуют только смещения и цепочки битов. а весь анализ был проведен в userland когда формировалось дерево и по описанию протокола формировались смещения битовых цепочек для анализа. разумеется из этих цепочек самих по себе правила не востановить, то вместе с ними можно хранить исходное, текстовое представление этих правил.