>[оверквотинг удален]
> gets expanded to:
> block out on fxp0 from 192.168.0.1 to any
> block out on fxp0 from 10.5.32.6 to any
> очевидно, что:
> block out on fxp0 from { 192.168.0.1, 10.5.32.6
> } to { 192.168.0.2, 10.5.32.4 }
> будет развёрнуто в 4 правила. если там будет список портов(например, 10шт), то
> правил будет 40.
> хосты можно засунуть в таблицы, а вот с портами - такое не
> получится. как и не получится, если надо хранить ip:port в таблице. Гм. Не путайте сокращённую запись правил с самими правилами. Сам pf(4) знать не знает ни о каких фигурных скобках, это всё на совести pfctl(8). ;) Ну да не суть.
Насчёт портов - увы, замечание верное. Правда, отчасти спасает тот вышеописанный оптимизатор, но не в ситуации, когда отличия только по номеру порта.
Кстати, вы на интересную идею натолкнули, сделать skip steps ещё и на совпадения, а не только на различия, плюс запоминать, по какой причине был сделан пропуск и опустить лишние проверки...
> плюс, таблицы в pf хранятся в radix tree и 65к хостов будут
> занимать уже прилично памяти.
Отнюдь. Для элементов дерева, точнее даже для записей каждого вида, используется свой собственный пул, поэтому фрагментация памяти отсутствует. 65 тыщ элементов выразится примерно в 12 мегабайт памяти, плюс примерно 8 килобайт накладных расходов в пуле. Много?
>> У PF в OpenBSD затык в совсем другом месте - ядро ОС
>> работает на одном физическом процессоре (ядре). Подвижки в решении этой проблемы
>> пока что идут, увы, "за сценой".
> думаю, glebius раньше доведёт до ума:
> http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/0066...
> PF в freebsd теперь будет свой.
Только это будет уже не OpenBSD'шный PF. Например, в FreeBSD в целях той самой параллелизации перешли от дерева к хеш-таблицам для таблиц адресов, забыв (или забив на) тот факт, что хеш-таблицы более уязвимы к атакам. Честно скажу, что детально сорцы PF во фряхе не изучал, но сомневаюсь, что там используется качественная (плохо предсказуемая) хеш-функция (типа SHA1), так как она будет, очевидно, достаточно сильно нагружать ЦП. Впрочем, оно понятно, что идеального решения нет.
> в netbsd - NPF.
С PF он имеет мало общего "внутри", но выглядит вкусно. Жаль только, что выглядит давно, а поюзать в деле пока никак. :(
