>>И на закуску: когда в ipfw появятся именованные таблицы, отдельные (также именованные и вложенные) блоки правил,
>
>Именованность - вредна. Так, как она сделана в pf, она не позволяет
>доверить управление машине (автоматизировать).Можно поподробнее, что не получается автоматизировать?
>Когда мы делали ipfw tag/tagged, мы честно
>хотели сделать их совместимыми с pf tag/tagged. Не получилось - потому
>что внутреннее представление в ядре - уже не строка, а число,
>и оно может меняться при каждой перекомпиляции рулесета.
Правильно, это именование — для юзерленда. Например, dhclient(8) умеет заполнять три таблицы, которые можно использовать в наборе правил, или ещё где-то. Да и мониторить человеческие названия таблиц как-то проще, чем пустые номера. Так что мимо кассы.
Если вы делаете что-то в ядре, то это совсем другой разговор. И да, согласен, pf никогда не делался с целью быть совместимым с ipfw. Так ведь это и фаерволы изначально разные по сути; хорька с крокодилом скрещивать занятие изначально бесполезное. :)
>В результате их
>нельзя использовать в конфигурировании другой подсистемы ядра (нужнее всего в netgraph).
>То есть pf - это вещь в себе. Не unix way,
>с чем-то еще его подружить - почти нереально.
Эм, а что мешает, коли уж речь о ковырянии в ядре, на релоад рулесета навесить хук, обновляющий номера тегов; или, скажем, добавить подсчёт ссылок. В самом pf(4) это несколько строчек всего.
>>умение роутить (не форвардить, а именно роутить) пакеты
>
>А это зачем? И в чем именно, кстати, отличие? :)
Различие называется L2 vs. L3.
Например, у вас два канала: быстрый лимитный и медленный безлимитный. По быстрому пускаете SSH, DNS, ещё что-нибудь; по медленному — всё остальное:
unlimit_if=1.1.1.2
limit_if=2.2.2.2
limit_gw=2.2.2.1
match out on $unlimit_if to port { domain, ssh } route-to ($limit_if $limit_gw)
Или, скажем, чтобы траффик извне, приходящий на некий интерфейс, уходил обратно на него, а не на шлюз по умолчанию:
pass in on $extra_if to ($extra_if) port { $extra_ports } reply-to ($extra_if $extra_gw)
А ещё pf умеет перебрасывать пакеты между доменами роутинга… Ой, я и забыл, во фряхе ж их нет. :-P
>BTW, умеет ли pf аналог fwd tablearg ?
Это уже обсуждалось. Не умеет, хотя при желании это легко скриптуется благодаря тем же anchor'ам.
>>аналог "keep state (max-src-conn-rate 10/5 overload flush <bruteforcers>)" — тогда его тоже можно будет воспринимать всерьёз, да? Это я так, лишь что первое на ум пришло упомянул.
>
>А толку с всего этого, если pf NAT не умеет фиксап протоколов
>на L7,
pf не пытается делать чужую работу. L5-L7 — по определению для специализированных приложений. Вы ещё SOAP предложите в ядре разбирать.
>если сам он не масштабируется с ростом числа процессоров
Вы производительность pf с ipfw измеряли? На нормальном, рабочем ruleset'е.
>и на определенной нагрузке просто затыкается?.. Узкая ниша?..
На какой загрузке у вас затыкается pf (не OpenBSD)? Узкой нишей я бы его не торопился называть. Скорее уж фаервол (в смысле программно-аппаратный комплекс целиком), которому одного ядра не хватает, есть нишевая система. :-P
