>> Гм. А в чём принципиальное отличие от "match <...> rtable N"? (смена
>> таблицы маршрутизации для пакета средствами PF)
> Вот про это я и говорил. Еще бы добавить возможность тегирования непосредственно
> из приложения или хотя бы из враппера - и костыли можно
> будет спокойно отбросить.

Гм. Для вас домены маршрутизации - это костыли? Бывает. :)

>> Ну да в PF нет conntrack zones, так как у PF изначально
>> не было проблем, которые conntrack zones решают. :)
> Он всегда умел отслеживать соединения в нескольких доменах маршрутизации? Не знал.

Да, с момента появления доменов маршрутизации в OpenBSD. Хотя, справедливости ради, скажу, что несколько багов (именно багов) было пофиксено позднее. Ну да кто без греха...

>> Правильно. Таблица маршрутизации и фаервол - немного разные инструменты. В вашем случае
>> обе функции ложатся на фаервол. Что вы там говорили про unix
>> way? ;)
> Авторы netfilter позиционируют его не просто как фаервол, а как "фреймворк для
> фильтрации и модификации пакетов". Присвоение пакету тегов - чем не модификация?
> Этот же подход, кстати, справедлив и для pf. Ведь он тоже умеет
> не только блокировать/пропускать пакеты, правда?

Я всего лишь запустил ответную шпильку. ;)

> Кстати, одно занудное замечание: netfilter, в отличие от pf, не имеет возможности
> напрямую вмешаться в процесс маршрутизации. Когда-то существовало патч, вводящий действие
> ROUTE, аналогичное rtable в pf, но его так и не приняли
> в ядро. Логика выбора таблицы реализована в самой системе маршрутизации. netfilter
> может лишь менять теги, являющиеся одним из критериев этой логики. Но
> он не является монополистом в этой области - вот в чем
> весь цимес.

ROUTE, по-моему, скорее соответствовал route-to в PF, которая опция по сути "перекрывает" стандартную маршрутизацию для данного пакета/соединения. Это параллельная доменам маршрутизации фича.

>> Всё то, что вы пока что описываете как фичи netfilter, в PF
>> имеется (что-то давным-давно, что-то не очень). Поэтому реализовать ваш вариант можно
>> и на OpenBSD (да и на FreeBSD как минимум тоже, ipfw
>> местный в последнее время становится всё более человеческим).
> В OpenBSD и FreeBSD приложения могут выставлять для своего трафика теги, которые
> понимает система маршрутизации?

Я уже говорил, что в PF напрямую можно тегировать только его средствами. Это как-то более надёжно, ИМХО, чем позволять приложениям выставлять теги. Что будет, если через взлом одного приложения атакующий получит возможность отправлять трафик от имен доверенного?

С другой стороны, в PF можно динамически добавлять-удалять правила, не мешая друг другу,  недавно даже появилась возможность задания одноразовых правил, которые самоудаляются после первого срабатывания. Можно и напрямую добавлять-удалять стейты. Так что аналогичная функциональность, повторюсь, вполне доступна.

Что до FreeBSD, то вроде бы там ситуация аналогичная, но утверждать это со 100% уверенностью не буду.

>> Но зачем, если есть нормально работающие домены маршрутизации? :)
> Зачем делать гибкое модульное решение, если костыли неплохо подпирают другие костыли?
> Ну, считайте меня перфекционистом :)

Затем же, зачем существуют не-универсальные отвёртки. ;) То, что потребует больших усилий и аккуратности при реализации на фаерволе, может легко решаться посредством доменов роутинга. При желании можно любую задачу фильтрации пакетов свести к тегированию и последующему разбору по тегам. Но практичным этот подход назвать никак нельзя. Это не перфекционизм, это идеализм. :)