![[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-04 09:56 pm (UTC)ну и наконец, если посмотреть на "старшего брата" - Juniper - там правила тоже просматриваются последовательно. и как мне кажется, вполне эффективно :D
no subject
Date: 2012-05-05 07:12 am (UTC)так же, как у джунипера не знаю, а у кошек существует компиляция acl, которая ускоряет обработку длинных списков
no subject
Date: 2012-05-06 08:49 am (UTC)А под ветвлениями я имею в виду условные переходы, которых в таблицах роутинга нет.
В отличие от таблицы роутинга, логика обработки пакета в ipfw не зависима однозначно от содержимого этого пакета.
Может быть задана вероятность, может вернуть тот или иной результат вызванный через divert или netgraph внешний модуль, пакет может быть отброшен/пропущен dummynet'ом.
ipfw фактически является языком программирования.
Компьютеры тоже последовательно просматривают инструкции, и что-то я не слышал про универсальное решение оптимизации кода, которое могло бы свернуть программу в дерево. Оптимизируются только частные случаи.
no subject
Date: 2012-05-06 09:00 am (UTC)ну разумеется нет. и соответсвия нет и однозначности. или по твоему правило "наилучшее совпадение" от нечего делать вводили? и radix tree там очень специальный.
вот в этом и состоит недостаток синтаксиса ipfw -- автоматически оптимизировать обработку части правил можно, но не все, а если хочется все остальное -- то надо либо явно указывать (т.е. менять синтаксис) или применять эвристики (что чревато)
no subject
Date: 2012-05-06 09:52 am (UTC)А про синтаксис - автоматически однозначно оптимизировать можно только линейный набор правил. Но линейный набор правил не годится для очень многих практических задач.
no subject
Date: 2012-05-06 10:51 am (UTC)собственно для файрвольных правил это тоже может работать (хоть и не всегда и вообще предмет для дискурсии).
шлюз, кстати, не конкретный -- бывает и в интерфейс (даже езернетовский и я этим пользовался) и бывает несколько шлюзов.
пфф. основная проблема к производительности файрволов -- то, что они медленно отрабатывают тысячу другую правил. которые скорее будут типа
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
Date: 2012-05-18 01:11 am (UTC)no subject
Date: 2012-05-18 01:57 pm (UTC)не вижу в этом ничего плохого.
сколько в реальной жизни последовательных divert/netgraph (даже если их много -- скорее всего в реальности для каждого пакета должен выполняться один-два хука)?
это уже не будет основным тормозом.
no subject
Date: 2012-05-18 03:05 pm (UTC)я не готов зарубаться. на 9 слайде я нихера не понял, 99 страничный документ еще не изучал. почитаю. мне, вероятно, это будет полезно. а может нет.
меня смущают интервалы. они в принципе не работают с дырявыми масками, что ли?
routing radix tree с ними работает. ему можно сунуть синтетический IPSRC_IPDST с рваной маской и оно не подавится. с другой стороны они (я так понимаю) говорят что пусть у нас это будет два измерения -- SRC и DST. ну, наверное вариант. адекватность результата -- несколько другой вопрос и у меня пока нет четкого понимания в этом вопросе. и что будет лучше. надо думать. и опять же -- дырявые маски.
no subject
Date: 2012-05-25 01:35 am (UTC)Про детали, но не настолько конкретные, а про взаимодействие.
я не готов зарубаться. на 9 слайде я нихера не понял, 99 страничный документ еще не изучал. почитаю. мне, вероятно, это будет полезно. а может нет.
Из него нужного всего ничего, а больше половины посвящено описанию устройства netfilter и того, как они героически с ним боролись. Тоже местами интересно, и мне на весь пролистать хватило час или два. Тебе нужно будет куда меньше - нужный кусок просто добавляет к девятому слайду децл текста, описывая принцип.
> меня смущают интервалы. они в принципе не работают с дырявыми масками, что ли?
У них одно правило - это более элементарный объект и гораздо более дешевый, чем обычное правило. То есть если ты пишешь маску 0xffffff0f, это эквивалентно 15 правилам с адресами .15, .31, .49 и т.д. - они у них очень дешевые. Собственно их коммерческий спонсор и решает проблему менеджмента такого невъебенного числа правил - у тебя в интерфейсе может быть дырявая маска, а в бэкенде 15 правил.
> routing radix tree с ними работает
А чо, до сих пор работает? По-моему выпилили же. И в ipfw table ты их заюзать не можешь, а это апгрейднутый table просто. Практическая применимость дырявых, кстати, сомнительна.
no subject
Date: 2012-05-25 05:19 am (UTC)у меня сейчас есть вялотекущая халтурка, связанная с фильтрацией потока, так что надо мне больше и читать я буду внимательно. мне не понятны и принципы, по которым надо расставлять приоритеты дабы получить логичное поведение. ну и насколько все сложно будет, т.е. алгоритмическая сложность раскладывания масок в диапазоны плюс понятийная сложность на организацию приоритетов для логичного поведения.
я примерно так и догадался. безусловная рулезность такого подхода мне не очевидна. по крайне мере пока.
нет. по крайне мере осенью в 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
Date: 2012-05-31 10:59 pm (UTC)Аа, вон ты о чем. Да, красивая идея. Но здесь, однако, возникают вопросы:
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
Date: 2012-06-01 04:48 am (UTC)он исходно с дырками. он даже не знает где адрес начинается, для него это просто дырка от начала пакета
у него сложность log2 от количества правил. и нет, строки как строки через него гонять неправильно. строги надо через регэкспы гонять. но до строк имеет смысл поставить радикс.
выбор есть всегда. и радикс для IP адресов я на днях попробую (по халтуре заказчик созрел на попробовать этот вариант, последовательное сравнение правил по скорости не устраивает).
это медленно. на приличном количестве правил ты даже гигабит не обработаешь. а сечас надо обрабатывать 10 и смотреть на 40. иначе -- просто потрать энергию на девушек.
это без поллитры не грокнуть. и потом на живой системе не посмотреть нормально, что бы сразу разобраться.
no subject
Date: 2012-05-18 01:09 am (UTC)А это уже не синтаксиса проблема, а семантики - возможностей дохуя. Синтаксис их просто отражает и по большому счету не важен.
no subject
Date: 2012-05-18 01:51 pm (UTC)у функциональных языков обычно синтаксис несколько отличный от процедурных и отражает их идеологию.
т.е. я не говорю, что синтаксис весь нафиг другой должен быть (ну как в примере к nftables -- мне не нравится), но должно быть явное выделение блоков правил, которые проверяются одновременно и как они разделяются всякими divert/netgraph (или вообще просто разделяются, если я хочу вначале влепить permit any any), к примеру.
no subject
Date: 2012-05-28 11:05 pm (UTC)> (ну как в примере к nftables -- мне не нравится)
Кстати, расскажи чем. Оно C-style а-ля Juniper-like или nginx-like, что уже есть шаг вперед от традиционных файрволов. Если первый блин комом, ошибки-то можно и учесть.
> или вообще просто разделяются, если я хочу вначале влепить permit any any
Я либо этот синтаксис не понимаю, либо какой смысл лепить в начало разрешение всего всем, оно ж остальные правила отменит.
Собсно, ты, я так понимаю, спец по цискам. Меня интересует, какой там packet flow в плане имениея нескольких аклей сразу, и т.п., ну по типу как я для ipfw в свое время рисовал. Поскольку multiple rulesets в ipfw изначально цискофилы и хотели.
no subject
Date: 2012-05-29 05:42 am (UTC)а, ок. я просто хотел сказать что это момент важный и он может иметь не только косметическое значение.
у меня возникает ощущение, что я программирую. а я не хочу программировать файрвол, я его хочу конфигурировать. но это так, скорее вкусовщина, хотя в случае ipfw (номера строк! бэйсик! фу!)/pf именно она и роялит. в nftables злоупотребление фигурными скобками. из скриптов конфиг будет неудобно менять. когда правило бьется на несколько строк -- трудно грепом искать. из командной строки поправить на лету одно правило -- тоже тяжело и неудобно.
в джунипере, кстати, вообще мозг выносят -- конфиг у тебя задается в одном стиле (а-ля cisco+dlink) а выводят -- в другом, со скобочками.
это слишком большой прыжок в сторону
в этом и суть -- временная отмена всех/части правил не стирая оных. и не сбрасывая статистики по ним. применяют при отладке, когда например не понятно -- то ли приложение дурит, то ли файрвол, то ли ты что-то перепутал -- отключим файрвол и посмотрим будет ли вообще работать.
либо я твоего вопроса не понял, либо ты плохо сформулировал. но что я помню о хотенияих а-ля циско было стремеление к следующему (освременненая ситиуация с откидыванием исторических, устаревших вариантов):
есть именованные наборы правил, ака aclи. у них, кстати, можно посмотреть счетчики, построчно.
есть конфигурация интерфейса, в которой описывается его параметры. среди прочих параметров есть два относящихся к вопросу: acl для входящих пакетов и acl для исходящих пакетов (имена). причем для каждого протокола задается отдельно.
транзитный пакет сначала получает по лбу in acl на входящем интерфейсе, потом out acl на исходящем.
почему хотели: удобно написать acl, например, для входящих пакетов с офиса (много строк), а потом по одной строке указывая просто его имя приенять на интерфейсе. тоже самое для пакетов с интернета. дополнительно указываем ограничивающие правила для dmz.
с нетграфом это у тебя получится само, иначе сделать трудно.
но это ты не видел просьб о несколько более другой технологии, перенесенной на роутеры с pix/asa:
у нас есть несколько зон (inside, dmz, outside). у зон есть уровень безопасности (0 совсем плохо, интернет; 100 -- локалка, 50 -- dmz). есть преконфигуренное поведение[*]: из зоны с большим уровнем безопасности можно без ограничений идти в меньшую. при этом образуется state для получения ответов, разумеется. наоборот -- запрещено. интерфейсу назначается принадлежность к какой-либо зоне. после этого файрвол (как устройство) готово функционировать, конфигурация очень лаконична и покрывает 95% потребностей. оставшиеся 5% исключений описываются дополнительными правилами, типа из outside на dmz host A можно ходить на порт 80. из inside на dmz port 23 ходить нельзя. и т.п. таких правил достаточно мало, поскольку умолчание [*] очень разумно.
ну еще у кошкастых есть несколько особенностей, которые наверное не имеет смысла реализовывать:
пакет, сформированный на роутере под acl не попадает вообще.
пакет, адресованный процессору роутера (не путать просто с фабрикой на каталистах, к примеру) попадает под еще один acl. ну и т.п.
no subject
Date: 2012-05-29 06:43 am (UTC)no subject
Date: 2012-05-29 07:23 am (UTC)ну и это -- такое поведение не интуитивно, надо изучать документацию.
спасибо, что не надо сдавать экзамен на право допуска к консоли.
претензии не понял.
no subject
Date: 2012-05-29 08:45 am (UTC)no subject
Date: 2012-05-29 11:34 am (UTC)cisco де-факто стала законодателем моды и стандартов.
следовательно все, кто отличаются -- находятся в несколько более неудобном положении.
no subject
Date: 2012-05-29 12:08 pm (UTC)Ну вспомните, как вставить правило в середину ACL, угу.
>cisco де-факто стала законодателем моды и стандартов.
Ну да, конечно. А Windows стал законодателем моды и стандартов в компьютерном мире, так давайте сделаем новый файервол с окошечками и менюшечками.
no subject
Date: 2012-05-29 12:21 pm (UTC)acr-office(config)#do sh ip acce NAT Extended IP access list NAT 10 deny ip 10.200.0.0 0.0.255.255 10.0.0.0 0.255.255.255 (380130 matches) 20 deny ip 10.200.0.0 0.0.255.255 81.211.90.0 0.0.0.255 30 permit ip 10.200.0.0 0.0.255.255 any (25681993 matches) 40 permit ip host 192.168.100.1 any acr-office(config)#25 permit ....а что?
не файрвол, а офис. а так все верно. ну и эта, победила не ibm cua, а ms ui (забыл как у них называется)
no subject
Date: 2012-05-29 12:43 pm (UTC)no subject
Date: 2012-05-29 01:18 pm (UTC)больше 10 лет назад
да.
не возбуждайся. перечитай еще раз. не путай теплое с мягким.