>>Но хотелось бы мне знать в таком случае, какой магией
>>должен обладать тот же dhclient, чтобы проинформировать окружающих об изменениях в
>>списках? Таблицы в pf — едва ли не самое удобное средство,
>>см. ioctl DIOCADDADDR и иже с ним. Ну и pfctl(8) тоже
>>умеет с ними работать. С anchor'ами аналогично.
>
>Ну так в коде dhclient жестко зашиты три таблицы и DIOCADDADDR, так?
>Именно против чего я и возражаю. Немодульно. Только хотел ткнуть носом, как понял, что и сам дурак: перепутал dhclient с dhcpd. М-да. Отпуск мне явно не на пользу. :) Тем не менее, вот то, о чём я говорю:
DHCPD(8) OpenBSD System Manager's Manual DHCPD(8)
NAME
dhcpd - Dynamic Host Configuration Protocol Server
SYNOPSIS
dhcpd [-dfn] [-A abandoned_ip_table] [-C changed_ip_table] [-c config-
file] [-L leased_ip_table] [-l lease-file] [-Y synctarget] [-y
synclisten] [if0 [... ifN]]
<...>
The options are as follows:
-A abandoned_ip_table
When an address is abandoned for some reason, add it to the pf(4)
table named abandoned_ip_table. This can be used to defend
against machines "camping" on an address without obtaining a
lease. When an address is properly leased, dhcpd will remove the
address from this table.
-C changed_ip_table
When an address is leased to a different hardware address, delete
it from the pf(4) table named changed_ip_table. This feature
complements the overload table in a stateful pf(4) rule. If a
host appears to be misbehaving, it can be quarantined by using
the overload feature. When the address is leased to a different
machine, dhcpd can remove the address from the overload table,
thus allowing a well-behaved machine to reuse the address.
<...>
-L leased_ip_table
When an address is leased dhcpd will insert it into the pf(4)
table named leased_ip_table. Addresses are removed from the
table when the lease expires. Combined with the table of
abandoned addresses, this can help enforce a requirement to use
DHCP on a network, or can place DHCP users in a different class
of service. Users are cautioned against placing much trust in
Ethernet or IP addresses; ifconfig(8) can be used to trivially
change the interface's address, and on a busy DHCP network, IP
addresses will likely be quickly recycled.
Как видите, ничего не зашито, пользуйте что хотите. Или вот другой пример, spamd:
An example pf.conf(5) fragment is given below. In the example, the file
/etc/mail/nospamd contains addresses of hosts who should be passed
directly to the SMTP agent (thus bypassing spamd).
table <spamd-white> persist
table <nospamd> persist file "/etc/mail/nospamd"
pass in on egress proto tcp from any to any port smtp \
rdr-to 127.0.0.1 port spamd
pass in on egress proto tcp from <nospamd> to any port smtp
pass in log on egress proto tcp from <spamd-white> to any port smtp
pass out log on egress proto tcp to any port smtp
Здесь название таблицы <spamd-white> зашито, но кому и когда это мешало — не могу представить, зачем нужно держать два белых списка почтовых серверов для грейлистинга. :)
В любом случае, вероятность конфликтов имён стремится к нулю. А вот числовых идентификаторов — очень даже высока. Да вы и сами знаете. :)
>[оверквотинг удален]
>>>всё конфигурирование выполняется в юзерлэнде. Точно так же их можно будет
>>>использовать в еще какой-нибудь другой, о которой я, автор, понятия не
>>>имел. Unix way.
>>
>>Хм. Пример не совсем удачный, конечно, но, надеюсь, суть я понял. Да,
>>теги снаружи недоступны. Всё остальное, что я перечислял, доступно.
>
>Было бы совсем плохо, коли и якоря и таблицы не были бы
>доступны. Но тегами-то дело не ограничивается. Ведь _вся_ идеология pf -
>закрытая система.
«Огласите весь список, пожалуйста!» ©
>>Можно сделать и теги доступными — опять же, очевидно, это просто
>>никому не было надо.
>
>Ну, я понимаю, что в вашем сообществе серьезных задач просто не возникает,
>потому и не надо было. Но это не оправдание же.
:-P Вот про серьёзные задачи не надо. Какие задачи возникают, такие и решаются, так весь опен-сорс живёт, вообще-то. :)
>[оверквотинг удален]
>>>открытости-то...
>>
>>Повторюсь, pf никогда не позиционировался как отдельный продукт. Он — часть ядра
>>OpenBSD. То, что при этом его можно _относительно_ легко выкусить —
>>целиком и полностью следствие идеологии проекта.
>
>Еще раз повторяю. С _подсистемой_ любой другой. Это не зависит от того,
>портируется он, выкусывается или нет. Вон, ipfw тоже никогда для портирования
>за пределы ядра FreeBSD не позиционировался (недавно нашлись энтузиасты, но это
>другой вопрос) - ничего, всю жизнь открытый.
Что-то я не понял, что вы понимаете под открытостью. Модель «кишки наружу»? Это не открытость, это хреновая абстракция, ведущая к путанице. Впрочем, ipfw в этом плане ещё не так плох. Так что я действительно не понимаю суть данной вашей претензии.
>[оверквотинг удален]
>>>выступил юзерлэнд. А вы предлагаете делать хак на каждый случай.
>>
>>Ни в коей степени не предлагаю. Повторюсь: в Опёнке, родине pf, нет
>>и не планируется других фаерволов.
>
>Видимо, придется еще раз повторить, чтобы дошло. Не с другим _файрволом_, а
>другой _подсистемой_. В примере выше комбинация была не с файрволом, а
>с netgraph. Кроме того, он может взаимодействовать с divert. И с
>dummynet. И с altq. И с любой другой подсистемой, которую завтра
>какой-нибудь доброволец придумает
Про altq я скромно промолчу. Про divert я просто процитирую divert(8) из FreeBSD 8:
BUGS
This is an attempt to provide a clean way for user mode processes to
implement various IP tricks like address translation, but it could be
cleaner, and it is too dependent on ipfw(8).
То есть разработчики FreeBSD сами признают, что _их_ divert реализован не портабельно. «И эти люди запрещают мне ковыряться в носу» © анекдот. К слову, в OpenBSD тоже есть divert, он прекрасно интегрирован с PF — но при этом, насколько помню, код там достаточно прозрачный, чтобы обобщить на что-то ещё. Хотя не уверен, что netgraph есть такой случай, идеология сильно другая. Но уж в этом, простите, не разработчики OpenBSD виноваты. :)
Ну а dummynet, вроде, никуда и не портировали, так что разговор вообще ни о чём получается.
>>Поэтому логично, что какие-то утилиты (тот
>>же dhclient, systat, spamd и так далее) работают с pf через его ioctl.
>
>Нет. Не логично. Логично и unixway-но им было бы всем (ну кроме
>может совсем системных вещей типа systat) работать не через бинарный, а
>через _текстовый_ интерфейс к pfctl. Дабы последний мог меняться более свободно
>и в меньшем числе мест, ежели что.
1. Вы слово «транзакция» знаете? Вы вообще в курсе, что в PF реализованы транзакции (вернее, некое их функциональное подобие, но не суть) для таких операций, как, например, добавление ruleset'ов, оперирование altq и так далее? Как вы средствами текстового интерфейса в рамках одной операции запросите состояние altq, добавите правило в набор и отредактируете таблицу?
2. Смена интерфейса приходит вместе с капитальной сменой ядра (обновление системы). В ходе этой операции обновляются и остальные программы. Как следствие, всё работает. Не ищите проблем там, где их нет. :)
>>И ни я, ни разработчики OpenBSD ни в коей
>>степени не стараются принизить труд тех людей, которые pf портируют.
>
>Вы в соседней ветке (да и тут тоже) утверждали, что pf для
>портирования не предназначен. Может, не стоит сразу на двух стульях сидеть
>и выбрать уж, или помочь этим людям, или сказать "нам на
>ваш труд пофиг, трахайтесь как хотите"?
Да, не предназначен. Но хаять их за то, что они это делают, никто не собирается. Попросят помочь — думаю, даже помогут. Не просят, типа, гордые — ну так простите, бегать и нянчиться тоже никто не будет. Детский сад был в детстве.
>[оверквотинг удален]
>>>
>>>У pf - ни один из этих двух. Это вещь в себе,
>>>не рассчитанная на взаимодействие. Народ ведь не только теги хотел и
>>>netgraph, а и dummynet, и divert, и открытость для чего-нибудь еще.
>>
>>Всё, что вы сказали верно исключительно для тегов. Которые в pf(4) никогда
>>не рассматривались как основной инструмент. Идеология pf(4) изначально не goto-style, в
>>котором метки действительно необходимы.
>
>Ничего не понял. Причем тут goto-style и метки?
Притом, что теги в ipfw-подобных фаерволах несут значительно большую нагрузку. Поэтому там и требуется большая гибкость работы с оными.
> В каких еще местах pf открыт, кроме якорей и таблиц (про это уже слышал)?
man 4 pf :-P. Конкретно: altq, собсно правила, state'ы, статистика по всему вышеперечисленному, ф-ции NAT lookup, управление параметрами (лимиты, интерфейсы для пропуска, TCP-флаги state'ов по умолчанию и т.д.), OS fingerprinting, может, ещё чего пропустил. :) То есть, по сути, всё, что возможно. Ну и pfctl(8) не отстаёт.
> Я выше перечислял ведь, чего хотят.
Угу, возможность свободно манипулировать тегами — как я понял, всё упёрлось в них.
>[оверквотинг удален]
>
>Да, и on - тоже условие, "out on $unlimit_if" эквивалентно "xmit $unlimit_if",
>в чем проблема?
>
>>А route-to — это, скажем так, override таблицы роутинга. То есть
>>вы насильственно отправите пакет не на гейтвей, вычисленного
>>через таблицу роутинга, а туда, куда скажете.
>
>Ну да, то же самое, что делает fwd, в чем разница-то? Где
>это самое различие L2 vs L3?
Да, различия нет, ступил. Вот только:
A fwd rule will not match layer-2 packets (those received on ether_input, ether_output, or bridged).
<...>
To enable fwd a custom kernel needs to be compiled with the option options IPFIREWALL_FORWARD.
Хотя вообще да, давненько я к ipfw не притрагивался.
>[оверквотинг удален]
>># 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);
>
>Эээ. Я правильно понимаю, что у Вас получается куча плоских правил совсем
>без таблиц? Это же ощутимая потеря в производительности при большом числе
>клиентов.
Согласен. Ну так речь-то шла о наличии фичи. :)
>[оверквотинг удален]
>>Этот фиксап может прекрасно делать userland-прокси, создавая по необходимости правила в своих
>>anchor'ах. И это, согласитесь, гораздо секурнее, т.к. в реализации всех этих
>>хитрозадых протоколов ошибиться весьма легко, и ошибка в модуле ядра будет
>>весьма череповата; с тем же conntrack, помнится, был далеко не один
>>прецедент. Посмотрите man по ftp-proxy из Опёнка, наглядная демонстрация
>
>Спасибо, К.О., этот принцип мне известен, именно с ним я и спорю.
>Насколько я помню сообщения, он затыкался уже на сотне с небольшим
>сессий, что ли. И к тому же только для ftp, остальным
>- лапу сосать?
Кому что нужно. Кому-то производительность дороже, кому-то надёжность.
>Что касается, секурности юзерлэнда - ну так напишите модуль ядра секурно, у
>вас же весь проект этому посвящен, нет?
Нет. Проект старается делать безопасно. Безопасно — это сплавлять сложную логику в юзерленд. FUSE тоже не просто так появился, между прочим (который не эмулятор, а ФС в userland).
> В конце концов, во
>фре ранее вообще весь нат в юзерлэнде делался, так это еще
>секурнее ведь - если досят большим количеством соединений, то ядро могло
>бы запаниковать от нехватки ядерной памяти на количество стейтов, юзерлэнду же
>на это пофиг (я слышал о преценеднте с процессом natd в
>400 Мб, ядро бы не выдержало).
Экгхм, а лимит на кол-во стэйтов использовать не судьба??? Заметьте, это будет ещё более живучим решением — как-то будет работать вместо того, чтобы быть полностью прибитым.
> Или вообще взлом, всё ядро
>или один процесс, что секурнее? Почему pf одну часть ната делает
>в ядре, а другую в юзерлэнде, на каком основании проведена такая
>граница?
NAT делается в ядре. ftp-proxy лишь отдаёт команды, базируясь на разборе кривого по современным меркам протокола. Более того, ftp-proxy нужен лишь для активного режима, а также для реверсного проксирования. :)
>>>Файрвол+NAT+шейпер. На дворе 2010 год, а не 1999, сейчас такие нагрузки и необходимость
>>>многоядерных систем для них - это уже не ниша, а норма. А нагрузки, где одного ядра
>>>хватает - уже ниша, пусть пока относительно широкая, но всё более сужающаяся.
>>
>>Мне вот одно интересно, если pf так плох, что ж его портируют-то?
>>:)
>
>Потому что покупаются на простоту решения типовых задач, и на некоторые фичи,
>отсутствующие у конкурентов.
Да-да, особенно последнее — пустяк.
> А чуть в сторону - начинаются стоны.
> Посмотрите, сколько вопросов о том, как во фре включить сразу и ipfw,
>и pf, и в каком порядке пакеты пойдут. Не от хорошей
>жизни же оба сразу заводят.
Понятно, что ситуации разные бывают. Wine тоже не от хорошей жизни появился. ;)
