>[оверквотинг удален]
>>>мимо кассы.
>>
>>То есть в коде dhclient(8) специально сделано сопряжение с pf, чтобы можно
>>было использовать с ним, я правильно понимаю? И любой произвольный софт
>>надо будет подпиливать? Именно против этого я и возражаю, см. ниже
>>пример.
>
>Чтобы использовать ту или иную фичу, так или иначе надо что-то где-то
>подпиливать. :) Либо эта фича — суть некий side-effect, прозрачный для
>программы. Вовсе нет. Вы же не подпиливаете код grep и awk в пайплайне grep string file | awk -f some_rewriting | anotherfilter
>Но хотелось бы мне знать в таком случае, какой магией
>должен обладать тот же dhclient, чтобы проинформировать окружающих об изменениях в
>списках? Таблицы в pf — едва ли не самое удобное средство,
>см. ioctl DIOCADDADDR и иже с ним. Ну и pfctl(8) тоже
>умеет с ними работать. С anchor'ами аналогично.
Ну так в коде dhclient жестко зашиты три таблицы и DIOCADDADDR, так? Именно против чего я и возражаю. Немодульно.
>[оверквотинг удален]
>>(на подобные) создавались теги в ipfw: http://www.freebsd.org/cgi/man.cgi?query=ng_tag#EXAMPLES
>>
>>Здесь видно, что они используются в совсем другой подсистеме ядра как есть,
>>и их не надо дергать по отдельности друг от друга -
>>всё конфигурирование выполняется в юзерлэнде. Точно так же их можно будет
>>использовать в еще какой-нибудь другой, о которой я, автор, понятия не
>>имел. Unix way.
>
>Хм. Пример не совсем удачный, конечно, но, надеюсь, суть я понял. Да,
>теги снаружи недоступны. Всё остальное, что я перечислял, доступно.
Было бы совсем плохо, коли и якоря и таблицы не были бы доступны. Но тегами-то дело не ограничивается. Ведь _вся_ идеология pf - закрытая система.
>Можно сделать и теги доступными — опять же, очевидно, это просто
>никому не было надо.
Ну, я понимаю, что в вашем сообществе серьезных задач просто не возникает, потому и не надо было. Но это не оправдание же.
>>Нет, не с ipfw, а "с любой другой подсистемой". Открытое API. По
>>иронии судьбы, в названии системы есть слово Open, а вот реальной
>>открытости-то...
>
>Повторюсь, pf никогда не позиционировался как отдельный продукт. Он — часть ядра
>OpenBSD. То, что при этом его можно _относительно_ легко выкусить —
>целиком и полностью следствие идеологии проекта.
Еще раз повторяю. С _подсистемой_ любой другой. Это не зависит от того, портируется он, выкусывается или нет. Вон, ipfw тоже никогда для портирования за пределы ядра FreeBSD не позиционировался (недавно нашлись энтузиасты, но это другой вопрос) - ничего, всю жизнь открытый.
>>Вы понимаете, что такое Unix way? Это принципы "каждая программа делает только
>>одну вещь, и делает её хорошо" и "средства сопряжения программ друг
>>с другом". Например, когда вы пишете grep | sort | wc,
>>вы не правите код каждой из них, а _комбинируете_. И пример
>>выше с тегами ipfw - я просто скомбинировал, в роли "шелла"
>>выступил юзерлэнд. А вы предлагаете делать хак на каждый случай.
>
>Ни в коей степени не предлагаю. Повторюсь: в Опёнке, родине pf, нет
>и не планируется других фаерволов.
Видимо, придется еще раз повторить, чтобы дошло. Не с другим _файрволом_, а другой _подсистемой_. В примере выше комбинация была не с файрволом, а с netgraph. Кроме того, он может взаимодействовать с divert. И с dummynet. И с altq. И с любой другой подсистемой, которую завтра какой-нибудь доброволец придумает
>Поэтому логично, что какие-то утилиты (тот
>же dhclient, systat, spamd и так далее) работают с pf через его ioctl.
Нет. Не логично. Логично и unixway-но им было бы всем (ну кроме может совсем системных вещей типа systat) работать не через бинарный, а через _текстовый_ интерфейс к pfctl. Дабы последний мог меняться более свободно и в меньшем числе мест, ежели что.
>И ни я, ни разработчики OpenBSD ни в коей
>степени не стараются принизить труд тех людей, которые pf портируют.
Вы в соседней ветке (да и тут тоже) утверждали, что pf для портирования не предназначен. Может, не стоит сразу на двух стульях сидеть и выбрать уж, или помочь этим людям, или сказать "нам на ваш труд пофиг, трахайтесь как хотите"?
>[оверквотинг удален]
>>2) либо имена присутствуют во всем интерфейсе, и в ядре тоже, и
>>есть API для их манипуляции, позволяющий автоматизацию.
>>
>>У pf - ни один из этих двух. Это вещь в себе,
>>не рассчитанная на взаимодействие. Народ ведь не только теги хотел и
>>netgraph, а и dummynet, и divert, и открытость для чего-нибудь еще.
>
>Всё, что вы сказали верно исключительно для тегов. Которые в pf(4) никогда
>не рассматривались как основной инструмент. Идеология pf(4) изначально не goto-style, в
>котором метки действительно необходимы.
Ничего не понял. Причем тут goto-style и метки? В каких еще местах pf открыт, кроме якорей и таблиц (про это уже слышал)? Я выше перечислял ведь, чего хотят.
>>>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
>>?
>
>xmit — это условие.
Да, и on - тоже условие, "out on $unlimit_if" эквивалентно "xmit $unlimit_if", в чем проблема?
>А route-to — это, скажем так, override таблицы роутинга. То есть
>вы насильственно отправите пакет не на гейтвей, вычисленного
>через таблицу роутинга, а туда, куда скажете.
Ну да, то же самое, что делает fwd, в чем разница-то? Где это самое различие L2 vs L3?
>В примере подразумевалось, что
>default gateway == $unlimit_gw. Давайте я распишу заново, подробнее:
Ну да, это всё понятно, я именно для этого случая и писал.
>[оверквотинг удален]
>unlimit_gw=1.1.1.1
>limit_if=2.2.2.2
>limit_gw=2.2.2.1
>
># собсно правила
>pass out on $unlimit_if
> nat-to ($unlimit_if:0)
>pass out on $unlimit_if to port { domain, ssh } \
> nat-to ($limit_if:0) \
> route-to ($limit_if $limit_gw)
Ах, у Вас еще нат. Ну, тогда придется чуть-чуть усложнить правила (переменные такие же, как у вас, точнее, я _if и _ip разделю), но суть fwd ведь от этого не меняется:
ipfw nat 1 config ip $unlimit_ip
ipfw nat 2 config ip $limit_ip
ipfw add nat 2 out xmit $unlimit_if dst-port 22,53
ipfw add fwd $limit_gw out xmit $unlimit_if src-ip $limit_ip
ipfw add nat 1 out xmit $unlimit_if
ipfw add pass src-ip $unlimit_ip
>[оверквотинг удален]
>На сам скрипт ушло минут десять где-то, включая исправление ошибок компиляции.
>Писать собственно релоадер было лениво, это несколько строк на шелле, а
>сама идея, думаю, ясна. :)
>
># cat /etc/clients/list
>Vasya 10.1.1.10 1000Kb
>Petya 10.1.1.11 3000Kb
><...>
> push(@queues, 'queue '.$name.' bandwidth '.$bw);
> push(@rules, 'pass out on $clients_if from '.$addr.' queue '.$name);
Эээ. Я правильно понимаю, что у Вас получается куча плоских правил совсем без таблиц? Это же ощутимая потеря в производительности при большом числе клиентов.
>[оверквотинг удален]
>>
>>Работа эта не является чужой. Без фиксапа у клиента не работают нормально
>>FTP/IRC DCC/PPTP, и фревые наты их умеют, как самые часто используемые.
>>Линуксовый conntrack - еще и разные другие умеет, более редкие.
>
>Этот фиксап может прекрасно делать userland-прокси, создавая по необходимости правила в своих
>anchor'ах. И это, согласитесь, гораздо секурнее, т.к. в реализации всех этих
>хитрозадых протоколов ошибиться весьма легко, и ошибка в модуле ядра будет
>весьма череповата; с тем же conntrack, помнится, был далеко не один
>прецедент. Посмотрите man по ftp-proxy из Опёнка, наглядная демонстрация
Спасибо, К.О., этот принцип мне известен, именно с ним я и спорю. Насколько я помню сообщения, он затыкался уже на сотне с небольшим сессий, что ли. И к тому же только для ftp, остальным - лапу сосать?
Что касается, секурности юзерлэнда - ну так напишите модуль ядра секурно, у вас же весь проект этому посвящен, нет? В конце концов, во фре ранее вообще весь нат в юзерлэнде делался, так это еще секурнее ведь - если досят большим количеством соединений, то ядро могло бы запаниковать от нехватки ядерной памяти на количество стейтов, юзерлэнду же на это пофиг (я слышал о преценеднте с процессом natd в 400 Мб, ядро бы не выдержало). Или вообще взлом, всё ядро или один процесс, что секурнее? Почему pf одну часть ната делает в ядре, а другую в юзерлэнде, на каком основании проведена такая граница?
>>Файрвол+NAT+шейпер. На дворе 2010 год, а не 1999, сейчас такие нагрузки и необходимость
>>многоядерных систем для них - это уже не ниша, а норма. А нагрузки, где одного ядра
>>хватает - уже ниша, пусть пока относительно широкая, но всё более сужающаяся.
>
>Мне вот одно интересно, если pf так плох, что ж его портируют-то?
>:)
Потому что покупаются на простоту решения типовых задач, и на некоторые фичи, отсутствующие у конкурентов. А чуть в сторону - начинаются стоны. Посмотрите, сколько вопросов о том, как во фре включить сразу и ipfw, и pf, и в каком порядке пакеты пойдут. Не от хорошей жизни же оба сразу заводят.
