> Гм. А в чём принципиальное отличие от "match <...> rtable N"? (смена
> таблицы маршрутизации для пакета средствами PF)Вот про это я и говорил. Еще бы добавить возможность тегирования непосредственно из приложения или хотя бы из враппера - и костыли можно будет спокойно отбросить.
> Ну да в PF нет conntrack zones, так как у PF изначально
> не было проблем, которые conntrack zones решают. :)
Он всегда умел отслеживать соединения в нескольких доменах маршрутизации? Не знал.
> Правильно. Таблица маршрутизации и фаервол - немного разные инструменты. В вашем случае
> обе функции ложатся на фаервол. Что вы там говорили про unix
> way? ;)
Авторы netfilter позиционируют его не просто как фаервол, а как "фреймворк для фильтрации и модификации пакетов". Присвоение пакету тегов - чем не модификация?
Этот же подход, кстати, справедлив и для pf. Ведь он тоже умеет не только блокировать/пропускать пакеты, правда?
Кстати, одно занудное замечание: netfilter, в отличие от pf, не имеет возможности напрямую вмешаться в процесс маршрутизации. Когда-то существовало патч, вводящий действие ROUTE, аналогичное rtable в pf, но его так и не приняли в ядро. Логика выбора таблицы реализована в самой системе маршрутизации. netfilter может лишь менять теги, являющиеся одним из критериев этой логики. Но он не является монополистом в этой области - вот в чем весь цимес.
> Всё то, что вы пока что описываете как фичи netfilter, в PF
> имеется (что-то давным-давно, что-то не очень). Поэтому реализовать ваш вариант можно
> и на OpenBSD (да и на FreeBSD как минимум тоже, ipfw
> местный в последнее время становится всё более человеческим).
В OpenBSD и FreeBSD приложения могут выставлять для своего трафика теги, которые понимает система маршрутизации?
> Но зачем, если есть нормально работающие домены маршрутизации? :)
Зачем делать гибкое модульное решение, если костыли неплохо подпирают другие костыли?
Ну, считайте меня перфекционистом :)
