![[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-18 02:18 am (UTC)Не. Я тебя сначала понял так, что ключом для flow является не 5-tuple, а что-то больше, например, в рамках одного tcp-соединения по итогам разбора могут быть несколько flow созданы. Чему и удивился. Но всё-таки ты предлагаешь тот же самый обычный трекинг (FTP DATA, IRC DCC, PPTP GRE, SIP и др.), который везде есть, просто под оригинальным соусом.
> потому что в регэкспах для проверки на соответвие используется подходящая структура. (регэкспы, как регэкспы именно (но не pcre -- неудобная она) тащить придется, именно для всяких sip. скорее всего. и мне они не кажутся очень накладными в этом месте).
Я понял, это лучше называть алгоритмической оптимизацией. Конкретно про регэкспы - чисто имплементации регэкспов в ядро портировать напряжно, ну смотря что от них нужно, конечно - существуют достаточно простые реализации регэкспов, причем без непредсказуемых задержек скорости, за счет того, что в них backreferences (\1, \2) нельзя. Кажется яндекс такую реализацию публиковал.
> только декларативное описание позволяет эффективно оптимизировать и выполнять "паралельную" проверку всех загруженных протоколов, особенно тех, у которых порты плавают. нет, тут не bpf, bpf слишком близко к тьюринг полному языку стоит если не тьюринг-полный. тут проще что-то.
Всё-таик её лучше алгоритмической оптимизацией называть, а не параллельной, потому что параллельность в ядре на уровне обработки разных пакетов, а не применения к одному пакету 100500 проверок разом.
Что касается BPF - он здесь упоминался как идея, а не как реальный bpf, ессно. Что транслируется в нечто, что потом сравнительно простой виртуальной машиной в ядре и исполняется.
>т.е. для модуля (UDP) должно говориться, например, что если в ip-пакете по смещению "протокол" 6 -- это наше, udp. и дальше алгоритм трансляции описывается по смещению порта два байта запомнить, заменить на доступные, поправить CRC. (UDP тут для примера, но возможно что его так и надо делать, как частный случай, а не как специальный модуль трансляции UDP. с TCP сложнее, сходу не вижу насколько геморно всякие SYN/ACK/FIN так описывать, но FSM все же правильнее именно тут описывать)
То, что ты описываешь, называется nftables, см. http://www.opennet.ru/opennews/art.shtml?num=20843 - и это как раз подход, взятый из BPF и такой, как ты описываешь, то есть там просто в итоге в ядре операции над байтами пакета по смещениям, как и в BPF. Только вот сдохла эта разработка =)
Проблема с этим подходом (если забыть про проблемы декомпиляции) - ядром выполняется интерпретация, а интерпретация - это накладно. Чем больше и крупнее операции, написанные на чистом Си, тем эти куски быстрее работают - поэтому в BPF-подобном ipfw2 и применяются сравнительно "крупные" операции над пакетом, типа "проверить src по radix-таблице".
> это ориентир. т.е. если эта цель не берется или берется слишком кривыми средствами -- значит решение выбранно неправильное.
Я пока что собирался делать а-ля conntrack в линуксах, то есть набор хуков и функций фреймворка - если это сильно криво, то почему у них есть столько модулей, а вот ихний же nftables таки загнулся? ;)
> мне кажется, что при правильной реализации фрэймворуа NAT и statefull трансляция SIP (в простейшем случае) реализуется довольно простым декларативным описанием с применением регэкспов (да, они полюбому нужны).
А ты сможешь такое декларативное описание набросать на псевдокоде? А то для меня пока что это всё выглядит как сказочный лес, нечто зыбкое и туманное.
no subject
Date: 2012-05-18 07:34 am (UTC)разумеется, теоретически может больше, но мне сейчас ни одного протокола в голову не приходит.
а, нет, пришло.
фильтрация внутри GRE. не того, GRE, который у нас на tun принимается, а транзитного.
вот тут да -- 5 тупле в пролете. и не на 5 тупле ориентироваться, мне кажется можно вообще не завязываться напрямую на IP.
я предлагаю фрэймворк. т.е. когда действительно то, что получится может никак не быть предусмотренно проектировщиком файрвола.
нет, алгоритмическая -- плохое слово. алгоритм не оптимизируется, он относительно стандартный. паралельное -- тоже плохое слово, согласен. backreferences пожалуй не нужен. вот что точно нужно -- эффективное определение какая альтернатива сработала (в pcre после срабатывания (GET|PUT|POST) надо еще отдельный анализ устраивать кто из трех сработал. ну и аналогично, если мы пять правил в одно через "или" объеденили -- как узнать какое сработало? в pcre неудобно.
я понял, но смысл именно в том, что не было исполнения виртуальной машиной. т.е. что бы делалось одно-несколько деревьев по которым делался бы анализ. да, потом, некторые операции будут выполняться, в этом смысле наверное виртуальная машина и bpf. но в этом смысле и ipfw сейчас -- bpf.
нет, по крайне мере не совсем. я предлагаю на псевдоязыке описывать только протокол. а правила фильтрации -- боле-менее обычным образом, но описание на псевдоязыке дают возможность в правилах фильтрации использовать параметры описанных протоколов.
не понимаю, какая декомпиляция. и мне не видно чего бы тут "операции" были сущестенно мельче.
потому что выживает всегда самое кривое! вот хоть архитектуру PC взять. да кто их знает, не понравились мантэйнеру дистрибутива, не получили юзербазы и потеряли интерфейс. или слишком сложное сделали. или синтаксис правил фильтрации неудобный получился.
попробую. в воскресенье на поезде ехать -- как раз буду бумагу чирикать. это, вероятно, будет чем-то похоже на описание MIBов
no subject
Date: 2012-05-25 01:10 am (UTC)> я предлагаю фрэймворк. т.е. когда действительно то, что получится может никак не быть предусмотренно проектировщиком файрвола.
Это, конечно, интересно, но здесь громадная проблема - производительность. Когда там 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
Date: 2012-05-25 06:17 am (UTC)возможно да. возможно нет. я пока не вижу принципиальных проблем реализации 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
Date: 2012-05-25 07:48 am (UTC)На эту тему был какой-то прогресс у imax: http://blog.imax.in.ua/2012/02/userfw-freebsd.html
no subject
Date: 2012-05-25 08:05 am (UTC)no subject
Date: 2012-05-25 08:09 am (UTC)no subject
Date: 2012-05-25 08:15 am (UTC)описание протоколов должно быть декларативное, общее, что бы можно было все свести воедино и построить оптимальное дерево разбора.
и это, состояний и потоков у него так же нет.
no subject
Date: 2012-05-31 11:07 pm (UTC)no subject
Date: 2012-06-01 04:37 am (UTC)тех, которые в понятии statefull.
no subject
Date: 2012-05-25 06:18 am (UTC)а! вот про это я и твержу тебе! с псевдокодом и инструкциями работать уже поздно, работать надо сразу с правилами. потому что правила в дерево свернуть реально, а псевдокод -- уже заипешься. потому и говорю, что термин алгоритмическая оптимизация тут неверный, тут не оптимизация псевдокода идет.
а построение дерева из правил -- да, реально. и как мне кажется даже не очень сложно, даже с учетом абстракций. т.е. да, первоначальный кусок будет довольно трудоемкий, но зато потом все будет на несколько порядков быстрее и легче.
да нет, вроде ничего особо сложного нет. тем более докторской, ведь аналитически исследовать не требуется. а если посмотреть на текущий код raidix tree для роутинга (в которм закодированны комманды посмотреть бит по смещению x и которе реально ничего не знает про протокол, который роутит, там даже таблицы виртуальных методов нет на момент роутинг лукапа) то в общем-то это уже и так почти готовое "по произвольному набору полей". ну и вот hipac -- на самом деле о том же самом, то что там нет произвольного набора -- это проблема фронтенда, сам-то механизм именно что по произвольному набору работает. т.е. надо различать проблемы собственно лукапа и построения дерева для работы этого лукапа. ну со строками отдельный момент, их надо вторым эшелоном пускать, видимо.
no subject
Date: 2012-05-25 07:13 am (UTC)попробую пробиться через жжшечку. много не успел, в купе попался спиногрых сверактивный -- мозг вынесен нах.
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 порождать)
Пример языка
Date: 2012-05-28 08:07 pm (UTC)А вот то, что уровнем выше, и что ты проповедовал как замену хелперам, то более значимо повлияет на архитектуру, покажи лучше это.
no subject
Date: 2012-05-28 08:37 pm (UTC)так же мне не очевидно, почему следует ip поддерживать базово, в смысле чем он отличается от pppoe, gre, ipip... ну и будет ли выйгрыш в скорости, поскольку при базовом разборе ip его разбирают целиком, а при таком варианте разбор возможно будет происходить только частично и только когда надо. в смысле этакие ленивые вычисления. это может довольно сильно усложнить "компилятор" (а может и нет), но вряд ли скажется на эффективности обработки. и мне кажется, что можно с нуля вот так все описать.
да, при этом потребуются некоторые примитивы: преобразование в текстовый вид и обратно 8/16/32 битных чисел, ipv4/6 (а при добавлении протоколов дополнительные примитивые -- asn1 для h.323, побайтовое-через-запятую представление для ftp -- это надо будет делать модулями с реализацией на си); для отслеживания сесиий -- хэши и деревья от комбинаций битовых полей, для nat -- мапинг битовых полей одной размерности в другую.
я напишу пример для sip, но не сегодня -- я его на память не помню и надо будет rfc в очередной раз освежать в памяти.
no subject
Date: 2012-05-29 05:48 pm (UTC)вот как-то так
я синтаксисом не доволен, но хоть как-то так.
no subject
Date: 2012-05-25 12:41 pm (UTC)ах да. я совсем забыл сказать-уточнить.
дерево (radix tree роутинга, условно говоря) используется для выбора правил, с которым собственно и идет сравнение. т.е. в дереве в узлах указывается какой бит следует анализировать, приходим к узлу в котором реальное правило (типа смещение в пакете, длинна, маска, образец). если правило под пакет не подошло -- дерево используется для выбора альтернативного, более общего правила.
т.е. деревом анализируются отдельные биты, что бы выбрать конкретное правило для полного сопоставления с пакетом. поэтому на этапе работы с пакетом код файрвола может не заморачиваться детальными знаниями о протокле -- его интересуют только смещения и цепочки битов. а весь анализ был проведен в userland когда формировалось дерево и по описанию протокола формировались смещения битовых цепочек для анализа. разумеется из этих цепочек самих по себе правила не востановить, то вместе с ними можно хранить исходное, текстовое представление этих правил.
no subject
Date: 2012-05-25 08:45 pm (UTC)AFAIK, nftables начинался как альтернативный путь имевшихся на тот момент проблем в netfilter/iptables.
в первую очередь, из-за проблем с расширением всего этого хозяйства(например, чтобы добавить модуль нужно было патчить ядро и iptables). плюс, слить iptables/ip6tables/ebtables/arptables в единое целое.
потом появился xtables и на проект забили.
no subject
Date: 2012-05-31 11:10 pm (UTC)