Редактирование: UNИX, весна 2009, 09 лекция (от 22 апреля)

Фактически, третью лекцию лектор пересказывает pf howto. В книге всё понятно, и её рекомендуется читать всем, даже если не собираетесь пользоваться pf.

Поверхностность обманчива: pf устроен так, чтобы облегчить работу пользователю, и если заглянуть внутрь простого правила в pf, то на самом деле оно раскрывается в довольно сложный набор, и тенденция в том. Недавно на опеннете была информационка, что отменили scrub (пересборка пакетов). Основная задача scrub — заменить кривые пакеты на опенбсдишные. Отменили потому, что он теперь включен по умолчанию.

Это всё дует в одну и то же дудку: инструмент должен ориентироваться на пользовательские задачи, а не плясать вокруг структуры ip-трафика.

Что такое якорь: как было сказано в прошлый раз, это похоже на пользовательскую цепочку в iptables: это свод правил, существующих в дополнение к основному своду правил pf, и может быть оттуда вызван. Смысл состоит не только в том, чтобы уменьшить количество видимых правил в одном фрагменте кода настр. pf, хотя и это тоже: можно представить некий набор правил, предназначенных для одной цели, и логично их оформить в виде якоря. Но главное достоинство якоря в том, что правила, которые лежат в якоре, не находятся в основном своде правил фаерволла, и есть гибкий механизм эти правила менять. Якорь нужен для того, чтобы там помещать правила, которые часто меняются. Меняются в связи с состоянием системы, в связи с тем, что залогинился пользователь, в связи со злобными действиями отдельных ip. Также, как это работает с таблицами, поскольку, этот свод правил в отдельной памяти и обрабатывается отдельно, то есть надежда, что блокировки у него не будет вообще, кроме как в случае, когда его содержимое потребовалось в момент его изменения.

Относительно того, что это такое, зачем это нужно. Какие они бывают: в прошлый раз лектор говорил, что в якорь можно складывать фильтр. правила и nat/binat/redirect, что в основном чаще всего используются правила типа filter. Тут мы приходим к ещё одному забавному свойству: поскольку якорь — штука, которую можно менять по ходу, то если где-то в тексте написано anchor goodguys, то в этом месте происходит нечто среднее между подстановкой и переходом. Это не макросы, подстанавливается оно в момент выполнения. Соответственно, как только модифицируется якорь, поведение pf меняется. Как это менять из us:

Якоря могут быть вложенные. Зачем это делать: чтобы не модифицировать содержимое одного подъякоря для модификации другого. Можно например взять и включить все подъякори якоря без рек. обхода:

И если в этот момент не идёт трафик, соответствующий данному фильтру, то не будет никакой потери произв.

Далее в документации следуют утверждения, когда могут быть макросы, когда нет. Поскольку макросы раскрываются compiletime, то их надо описывать там же, где и сам якорь.

Возвращаемся к трафик шейпингу. В след раз можно поговорить, как это делается в линуксе, но то, как это сделано pf, настолько просто, что непонятно, почему все этого боятся.

Все пакеты, которые ходят через tcp/ip стек, находятся в очереди. Просто очередь имеет самый простой алгоритм, фифо.

Делать планирование входящих пакетов глупо, поэтому в pf такой возм. нет.

* Самый нерекомендуемый. В pf их два, они просто соответствуют двум диссертациям, соответственно на эту темы, одна из них — priority queueing, вторая — class-based queueing. В pf class-based тоже имеет свои приоритеты, поэтому первым ползоваться необязательно. С другой стороны, первый быстрее и более правильно работающий. Приоритезация: о чём вообще речь. Есть пресловутый интерфейс, из которого вылазят пакеты. Вы организуете несколько очередей fifo, в зависимости от того, как устроен фильтр, пакет попадает в соответствующую очередь и по разным правилам отп. Приоритетная организация очередей построена очень просто: Вы указываете пропускную способность очереди целиком. ... Как это делается в настройках: Идея следу.: вы должны объявить о том

altq on fxp0 bv 2mb queue {std_out, dns_out}

Что означает более высокий приоритет? Если идёт dns-запрос, то он вылезет первым, и если другие пакет ждут своей очереди, то они ещё подождут.

Почему лектор про это рассказал, но не рекомендовал пользоваться приоритетными очередями? Если вы впихнули в очередь с высоким приоритетом пост. трафик, то можете сделать всем хуже.

Как этого избежать? Достаточно просто, если не будете пользоваться приоритетными очередями, а таким способом орг. очередей, когда приоритет наводится не в рамках всего трафика, а в рамках конкурирующих потоков. То есть если бы была возможность делать дерево, то там вполне можно устроить приоритеты.

altq on fxp0 cbq pw 2Mb queue {std, ssh, ftp}

borrow — то самое, о чём говорили в начале: ftp дали гарантированную скорость передачи, и если никто больше не занимает канал, то использует свободную пропускную способность.

Таким образом, мы получаем достаточно неплохое описание очереди, осталось только написать что-нибудь типа

Что лектору не нравится: непонятно, в какую из подочередей упадёт поток. У pf есть замечательное свойство: можно указать несколько очередей:

Если так пишете, то будет приниматься во внимание ToS и содержимое спец. флагов TCP типа SYN, ACK. ACK и ToS "low delay" будет попадать во вторую очередь, все остальные — в первую.

Всё остальное примерно понятно. Лектор обращает внимание, что это действует для исходящего трафика.

Redirect — в зависимости от того, на какой порт пришли, перенаправить трафик.