>[оверквотинг удален]
>>доверить управление машине (автоматизировать).
>>Когда мы делали ipfw tag/tagged, мы честно
>>хотели сделать их совместимыми с pf tag/tagged. Не получилось - потому
>>что внутреннее представление в ядре - уже не строка, а число,
>>и оно может меняться при каждой перекомпиляции рулесета.
>
>Правильно, это именование — для юзерленда. Например, dhclient(8) умеет заполнять три таблицы,
>которые можно использовать в наборе правил, или ещё где-то. Да и
>мониторить человеческие названия таблиц как-то проще, чем пустые номера. Так что
>мимо кассы.

То есть в коде dhclient(8) специально сделано сопряжение с pf, чтобы можно было использовать с ним, я правильно понимаю? И любой произвольный софт надо будет подпиливать? Именно против этого я и возражаю, см. ниже пример.

>Можно поподробнее, что не получается автоматизировать?

Ну вот пример решения задачи, в том числе с расчетом на которую (на подобные) создавались теги в ipfw: http://www.freebsd.org/cgi/man.cgi?query=ng_tag#EXAMPLES

Здесь видно, что они используются в совсем другой подсистеме ядра как есть, и их не надо дергать по отдельности друг от друга - всё конфигурирование выполняется в юзерлэнде. Точно так же их можно будет использовать в еще какой-нибудь другой, о которой я, автор, понятия не имел. Unix way.

>Если вы делаете что-то в ядре, то это совсем другой разговор. И
>да, согласен, pf никогда не делался с целью быть совместимым с
>ipfw. Так ведь это и фаерволы изначально разные по сути; хорька
>с крокодилом скрещивать занятие изначально бесполезное. :)

Нет, не с ipfw, а "с любой другой подсистемой". Открытое API. По иронии судьбы, в названии системы есть слово Open, а вот реальной открытости-то...

>>В результате их
>>нельзя использовать в конфигурировании другой подсистемы ядра (нужнее всего в netgraph).
>>То есть pf - это вещь в себе. Не unix way,
>>с чем-то еще его подружить - почти нереально.
>
>Эм, а что мешает, коли уж речь о ковырянии в ядре, на
>релоад рулесета навесить хук, обновляющий номера тегов; или, скажем, добавить подсчёт
>ссылок. В самом pf(4) это несколько строчек всего.

Вы понимаете, что такое Unix way? Это принципы "каждая программа делает только одну вещь, и делает её хорошо" и "средства сопряжения программ друг с другом". Например, когда вы пишете grep | sort | wc, вы не правите код каждой из них, а _комбинируете_. И пример выше с тегами ipfw - я просто скомбинировал, в роли "шелла" выступил юзерлэнд. А вы предлагаете делать хак на каждый случай.

Правильная реализация именованности для человека - это:
1) либо имена присутствуют только в обвязке для человека (макросы, например), и юзерлэндный скрипт может получить доступ к номерам, буде необходима автоматизация/сопряжение,
2) либо имена присутствуют во всем интерфейсе, и в ядре тоже, и есть API для их манипуляции, позволяющий автоматизацию.

У pf - ни один из этих двух. Это вещь в себе, не рассчитанная на взаимодействие. Народ ведь не только теги хотел и netgraph, а и dummynet, и divert, и открытость для чего-нибудь еще.

>[оверквотинг удален]
>Различие называется 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)

Гм, простите, а в чем здесь различие L2 vs L3, и чем это отличается от
ipfw add fwd $limit_gw xmit $unlimit_if dst-port 22,53
?

>А ещё pf умеет перебрасывать пакеты между доменами роутинга… Ой, я и
>забыл, во фряхе ж их нет. :-P
>
>>BTW, умеет ли pf аналог fwd tablearg ?
>
>Это уже обсуждалось. Не умеет, хотя при желании это легко скриптуется благодаря
>тем же anchor'ам.

Зато fwd tablearg есть, да и setfib уже тоже :) Кстати, Вы не нарисуете этот самый скрипт-аналог для fwd tablearg? Я что-то не совсем улавливаю, как, да и народу пригодится, думаю.

>>>аналог "keep state (max-src-conn-rate 10/5 overload flush <bruteforcers>)" — тогда его тоже можно будет воспринимать всерьёз, да? Это я так, лишь что первое на ум пришло упомянул.
>>
>>А толку с всего этого, если pf NAT не умеет фиксап протоколов
>>на L7,
>
>pf не пытается делать чужую работу. L5-L7 — по определению для специализированных
>приложений. Вы ещё SOAP предложите в ядре разбирать.

А зачем Вы передергиваете? Разве SOAP открывает вторичные коннекты ипередает в своем теле IP-адреса?

Работа эта не является чужой. Без фиксапа у клиента не работают нормально FTP/IRC DCC/PPTP, и фревые наты их умеют, как самые часто используемые. Линуксовый conntrack - еще и разные другие умеет, более редкие.

>>если сам он не масштабируется с ростом числа процессоров
>
>Вы производительность pf с ipfw измеряли? На нормальном, рабочем ruleset'е.
>
>>и на определенной нагрузке просто затыкается?.. Узкая ниша?..
>
>На какой загрузке у вас затыкается pf (не OpenBSD)?

Лично я pf не использую. Где-то в сети пролетало. Народ сообщал, что pf действительно затыкается там, где ipfw/libalias еще живет (и вообще от ipfw нагрузка меньше). Начиная от 300 тысяч стейтов, кажется.

>Узкой нишей я бы его не торопился называть. Скорее уж фаервол (в смысле программно-аппаратный
>комплекс целиком), которому одного ядра не хватает, есть нишевая система. :-P

Файрвол+NAT+шейпер. На дворе 2010 год, а не 1999, сейчас такие нагрузки и необходимость многоядерных систем для них - это уже не ниша, а норма. А нагрузки, где одного ядра хватает - уже ниша, пусть пока относительно широкая, но всё более сужающаяся.