>[оверквотинг удален]
>>
>>Правильно, это именование — для юзерленда. Например, dhclient(8) умеет заполнять три таблицы,
>>которые можно использовать в наборе правил, или ещё где-то. Да и
>>мониторить человеческие названия таблиц как-то проще, чем пустые номера. Так что
>>мимо кассы.
>
>То есть в коде dhclient(8) специально сделано сопряжение с pf, чтобы можно
>было использовать с ним, я правильно понимаю? И любой произвольный софт
>надо будет подпиливать? Именно против этого я и возражаю, см. ниже
>пример. Чтобы использовать ту или иную фичу, так или иначе надо что-то где-то подпиливать. :) Либо эта фича — суть некий side-effect, прозрачный для программы. Но хотелось бы мне знать в таком случае, какой магией должен обладать тот же dhclient, чтобы проинформировать окружающих об изменениях в списках? Таблицы в pf — едва ли не самое удобное средство, см. ioctl DIOCADDADDR и иже с ним. Ну и pfctl(8) тоже умеет с ними работать. С anchor'ами аналогично.
>>Можно поподробнее, что не получается автоматизировать?
>
>Ну вот пример решения задачи, в том числе с расчетом на которую
>(на подобные) создавались теги в ipfw: http://www.freebsd.org/cgi/man.cgi?query=ng_tag#EXAMPLES
>
>Здесь видно, что они используются в совсем другой подсистеме ядра как есть,
>и их не надо дергать по отдельности друг от друга -
>всё конфигурирование выполняется в юзерлэнде. Точно так же их можно будет
>использовать в еще какой-нибудь другой, о которой я, автор, понятия не
>имел. Unix way.
Хм. Пример не совсем удачный, конечно, но, надеюсь, суть я понял. Да, теги снаружи недоступны. Всё остальное, что я перечислял, доступно. Можно сделать и теги доступными — опять же, очевидно, это просто никому не было надо.
>>Если вы делаете что-то в ядре, то это совсем другой разговор. И
>>да, согласен, pf никогда не делался с целью быть совместимым с
>>ipfw. Так ведь это и фаерволы изначально разные по сути; хорька
>>с крокодилом скрещивать занятие изначально бесполезное. :)
>
>Нет, не с ipfw, а "с любой другой подсистемой". Открытое API. По
>иронии судьбы, в названии системы есть слово Open, а вот реальной
>открытости-то...
Повторюсь, pf никогда не позиционировался как отдельный продукт. Он — часть ядра OpenBSD. То, что при этом его можно _относительно_ легко выкусить — целиком и полностью следствие идеологии проекта.
>[оверквотинг удален]
>>Эм, а что мешает, коли уж речь о ковырянии в ядре, на
>>релоад рулесета навесить хук, обновляющий номера тегов; или, скажем, добавить подсчёт
>>ссылок. В самом pf(4) это несколько строчек всего.
>
>Вы понимаете, что такое Unix way? Это принципы "каждая программа делает только
>одну вещь, и делает её хорошо" и "средства сопряжения программ друг
>с другом". Например, когда вы пишете grep | sort | wc,
>вы не правите код каждой из них, а _комбинируете_. И пример
>выше с тегами ipfw - я просто скомбинировал, в роли "шелла"
>выступил юзерлэнд. А вы предлагаете делать хак на каждый случай.
Ни в коей степени не предлагаю. Повторюсь: в Опёнке, родине pf, нет и не планируется других фаерволов. Поэтому логично, что какие-то утилиты (тот же dhclient, systat, spamd и так далее) работают с pf через его ioctl. И ни я, ни разработчики OpenBSD ни в коей степени не стараются принизить труд тех людей, которые pf портируют.
>Правильная реализация именованности для человека - это:
>1) либо имена присутствуют только в обвязке для человека (макросы, например), и
>юзерлэндный скрипт может получить доступ к номерам, буде необходима автоматизация/сопряжение,
>2) либо имена присутствуют во всем интерфейсе, и в ядре тоже, и
>есть API для их манипуляции, позволяющий автоматизацию.
>
>У pf - ни один из этих двух. Это вещь в себе,
>не рассчитанная на взаимодействие. Народ ведь не только теги хотел и
>netgraph, а и dummynet, и divert, и открытость для чего-нибудь еще.
Всё, что вы сказали верно исключительно для тегов. Которые в pf(4) никогда не рассматривались как основной инструмент. Идеология pf(4) изначально не goto-style, в котором метки действительно необходимы.
>[оверквотинг удален]
>>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
>?
xmit — это условие. А route-to — это, скажем так, override таблицы роутинга. То есть вы насильственно отправите пакет не на гейтвей, вычисленного через таблицу роутинга, а туда, куда скажете. В примере подразумевалось, что default gateway == $unlimit_gw. Давайте я распишу заново, подробнее:
Интерфейс em0: 1.1.1.2/30, за ним живёт шлюз анлимного провайдера 1.1.1.1
Интерфейс em1: 2.2.2.2/30, за ним живёт шлюз лимитного провайдера 2.2.2.1
В таблице роутинга шлюзом по умолчанию ставим 1.1.1.1.
В pf.conf:
# макросы
unlimit_if=1.1.1.2
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)
>>>BTW, умеет ли pf аналог fwd tablearg ?
>>
>>Это уже обсуждалось. Не умеет, хотя при желании это легко скриптуется благодаря
>>тем же anchor'ам.
>
>Зато fwd tablearg есть, да и setfib уже тоже :) Кстати, Вы
>не нарисуете этот самый скрипт-аналог для fwd tablearg? Я что-то не
>совсем улавливаю, как, да и народу пригодится, думаю.
Ну, для описанной мне ранее ситуации, с многоэтажным altq (необходимость tablearg для других команд в pf я пока не увидел), получается что-то вроде такого. Я взял для наглядности самый простой случай — данные в простом файле, так как откуда брать данные клиентов, понятно, дело десятое. На сам скрипт ушло минут десять где-то, включая исправление ошибок компиляции. Писать собственно релоадер было лениво, это несколько строк на шелле, а сама идея, думаю, ясна. :)
=====================================================
# cat /etc/pf.conf
<...>
include "pf.conf.client-queues"
altq on $clients_if cbq bandwidth 950Mb queue clients
<...>
anchor client-rules
load anchor client-rules from "/etc/pf.conf.client-rules"
# cat /etc/clients/list
Vasya 10.1.1.10 1000Kb
Petya 10.1.1.11 3000Kb
<...>
# cat /site/sbin/upd-clients-queues
#!/usr/bin/perl
use strict;
use feature "switch";
$\ = "\n";
sub usage() {
print STDERR "usage: ".basename($0)." source queues rules";
exit 1;
}
sub bad_source($) {
print STDERR "Bad source line: ".$_[0];
exit 1;
}
usage if $#ARGV != 3;
open(SOURCE, '<', $ARGV[0]) or die "Cannot open source file $ARGV[0]";
my (@qnames, @queues, @rules);
my ($addr, $bw, $l, $name);
my $sumBandwith = 0;
while (<SOURCE>) {
chomp;
next if /^([\s]*#|[\s]*)$/;
($name, $addr, $bw) = split /\t/;
bad_source $_
if (length($name) == 0 or length($addr) == 0 or length($bw) == 0);
$l = $_;
given ($bw) {
when (/^[0-9]+b?$/) { }
when (/^[0-9]+Kb$/) { $bw *= 1000; }
when (/^[0-9]+Mb$/) { $bw *= 1000000; }
when (/^[0-9]+Gb$/) { $bw *= 1000000000; }
default { bad_source $l; }
}
$sumBandwith += $bw;
$name = 'client_'.$name;
push(@qnames, $name);
push(@queues, 'queue '.$name.' bandwidth '.$bw);
push(@rules, 'pass out on $clients_if from '.$addr.' queue '.$name);
}
close SOURCE;
exit 0 unless @qnames;
open(QUEUES, '>', $ARGV[1]) or die "Cannot open queues file $ARGV[1]";
print QUEUES "queue clients {\n\t".join("\n\t", @qnames)."\n}";
@qnames = ();
foreach $l (@queues) {
print QUEUES $l;
}
close QUEUES;
@queues = ();
open(RULES, '>', $ARGV[2]) or die "Cannot open rules file $ARGV[2]";
foreach $l (@rules) {
print RULES $l;
}
close RULES;
exit 0;
=====================================================
>[оверквотинг удален]
>>
>>pf не пытается делать чужую работу. L5-L7 — по определению для специализированных
>>приложений. Вы ещё SOAP предложите в ядре разбирать.
>
>А зачем Вы передергиваете? Разве SOAP открывает вторичные коннекты ипередает в своем
>теле IP-адреса?
>
>Работа эта не является чужой. Без фиксапа у клиента не работают нормально
>FTP/IRC DCC/PPTP, и фревые наты их умеют, как самые часто используемые.
>Линуксовый conntrack - еще и разные другие умеет, более редкие.
Этот фиксап может прекрасно делать userland-прокси, создавая по необходимости правила в своих anchor'ах. И это, согласитесь, гораздо секурнее, т.к. в реализации всех этих хитрозадых протоколов ошибиться весьма легко, и ошибка в модуле ядра будет весьма череповата; с тем же conntrack, помнится, был далеко не один прецедент. Посмотрите man по ftp-proxy из Опёнка, наглядная демонстрация принципа: http://www.openbsd.org/cgi-bin/man.cgi?query=ftp-proxy&sekti... .
>Лично я pf не использую. Где-то в сети пролетало. Народ сообщал, что pf действительно
>затыкается там, где ipfw/libalias еще живет (и вообще от ipfw нагрузка меньше). Начиная
>от 300 тысяч стейтов, кажется.
>
>>Узкой нишей я бы его не торопился называть. Скорее уж фаервол (в смысле программно-аппаратный
>>комплекс целиком), которому одного ядра не хватает, есть нишевая система. :-P
>
>Файрвол+NAT+шейпер. На дворе 2010 год, а не 1999, сейчас такие нагрузки и необходимость
>многоядерных систем для них - это уже не ниша, а норма. А нагрузки, где одного ядра
>хватает - уже ниша, пусть пока относительно широкая, но всё более сужающаяся.
Мне вот одно интересно, если pf так плох, что ж его портируют-то? :)
