> во-вторых смотри шире: правило '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'. ну и какая после этого принципиальная разница в каком именно месте у тебя дыра, если она все равно есть?
Аа, вон ты о чем. Да, красивая идея. Но здесь, однако, возникают вопросы: 1) Как оно работает в случае нескольких таких с дырками? В случае префиксов всё просто и однозначно. Я в алгоритм радикса не вникал на таком уровне, чтобы понимать работу дырок. 2) Насколько быстро оно будет работать? Радикс побитовый, и я подозреваю, что на строках в сотни бит оно будет тормозить - O(log2 N) уже немаленький станет.
> я примерно так и догадался. безусловная рулезность такого подхода мне не очевидна. по крайне мере пока.
А у нас есть выбор? Эта штука, по крайней мере, проверена и работает, из альтернатив разве что предложенный тобой выше радикс. Я как-то пробовал посмотреть на проблему матчинга пакета с точки зрения выборки в SQL, но ту математику ниасилил.
>мне не понятны и принципы, по которым надо расставлять приоритеты дабы получить логичное поведение.
Это-то как раз просто и интуитивно понятно. Правила идут последовательно, кто первое совпало, того и тапки. Как ранний ipfw1, еще без всяких skipto и дивертов.
> нет. по крайне мере осенью в current еще жило. и до сих пор может роутить OSI. да, несмотря на отсутвие кода поддержки OSI во FreeBSD если этому радикстри подсунуть OSIшный адрес -- он сделает верный лукап. принципиально там (в лукапе по дереву) ничего с bsd reno не менялось
Ну да, можно, я знаю. Вон birdofluck поддержку строк (имен интерфейсов) и IPv6 в таблицах сделал, как раз потому что алгоритму пох.
> это не имеет значения, в обычном-то правиле можно, а говорим мы про обычные правила. > во-первых вони будет... >ну и насколько все сложно будет, т.е. алгоритмическая сложность раскладывания масок в диапазоны плюс понятийная сложность на организацию приоритетов для логичного поведения.
Мнээ... Ну это если конвертер из существующих правил в это писать. Мне такая задача не очень улыбается. Но тут, судя по комментам, userbase готова к введению расширенных таблиц. А когда это новый синтаксис - никто вонять не будет, что там примитивные правила, и дырки не поддерживаются. Т.е. останутся обычные правила, а новые будут примерно так:
т.е. внутренний синтаксис в стиле ipfw1, примитивный как в nf-hipac. А в основном ipfw - вызовы ruletable, netgraph, divert и пр., которые не соптимизировать, и обычные правила, если нужны.
Более того, мне тут щас в голову пришла идея - один из ruletable вызывается в ip_forward() примерно так:
if (M_FIB(mbuf) == 0)
setfib mbuf, ruletable(ip_rule);
А-ля в iproute2. Тогда решается проблема того, что классификация для PBR идентична задаче файрвола и неплохо бы в том же синтаксисе, но иметь его нужно отдельно. Парсер будет тот же в ipfw, не придется учить отдельный синтаксис.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
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, не придется учить отдельный синтаксис.