===
В марте, помнится, я написал в ipfw@ предложения по архитектурным улучшениям ipfw, как кандидат на GSoC 2008. Никто не отреагировал (многабукаф, фигли). Дальше, в конце мая в RU.UNIX.BSD разгорелся спор - народ хотел изменения "как Cisco ACLs, но лучше", однако конкретики не было, хотя со временем что-то уже вырисовалось, я поглядел на идеи для будущего из перевода рассказа о Netgraph и набросал примерный вариант, как это могло бы выглядеть. И что же? Тут же дискуссия заглохла. Стало понятно, что выносить такие вещи на публику не имеет смысла - как только доходит до дела, любители почесать языком тут же исчезают. С другой стороны, каждый раз пересказывать сначала идеи тем индивидам, которые заинтересованы и могут сделать, долго, поэтому я решил расписать это и сделать доступным на вебе, чтоб не потерялось. А может, со временем и поможет найти тех, кто заинтересован и либо сможет сделать, либо обсудить изменения планов, исходя из практических потребностей.

Пара слов во введение.

Текст не для новичков, предполагается, что есть знакомство с нетграфом на базовом уровне как пользователя, с ipfw на продвинутом уровне, а также некоторое представление о программировании и устройстве Unix внутри.

Итак, прежде всего: ipfw далеко не совершенен, его надо достаточно сильно изменить. Будем сравнивать с pf и iptables, когда потребуется.

Что вообще нужно от хорошей системы? Три вещи: расширяемость, мощность фич и удобство использования. Пользователей прежде всего привлекает третье - тот же pf, несмотря на кучу недостатков, имеет удобный синтаксис, с низким порогом вхождения. С другой стороны, ipfw и netgraph, неся в себе принципы unix way (комбинирование сложной системы из простых строительных блоков, каждая из которых хорошо выполняет свою узкую задачу), в принципе позволяют сделать очень много. Только для этого придется затратить много времени на изучение и конфигурирование. Почему так происходит? Потому что pf ориентирован на человека, простого пользователя, а ipfw/netgraph - в большей степени на машину, на как просто мышление программиста, так и возможность управления автоматически из другой программы. Отсюда, например, проистекает использование в ipfw номеров, а в pf - имен, везде где только можно.

Что лучше, первое или второе? А ни то, ни другое. Лучше и то, и другое сразу. Хорошая система должна предоставлять как удобство для новичка (простые вещи - понятны и просты же), так и оставлять возможность для профессионала залезть в потроха и сделать руками то, что он хочет, а обычный интерфейс не позволяет, и при этом не мешать ему в этом - если система навязывает единый стиль действий "как для новичка", она будет мешать.

Положительный пример: netgraph мощен, но если большинству пользователей предложить на нем что-то сделать, они скажут "ой, он же сложный, ужос-ужос, не хочу и не буду лезть у меня нет времени учить еще одну технологию" (стандартная отмазка, на самом деле они просто не хотят напрягать мозг ;)). Однако был написан mpd, который работает на нетграфе, сам его конфигурирует, а пользователю предоставляет достаточно простой и удобный интерфейс. И mpd пользуется популярностью.

Отрицательный пример: внутренняя организация pf. Это "вещь в себе", замкнутая система, совершенно не рассчитанная на внешнее вмешательство. Один из примеров. Там можно навешивать на пакет теги по именам. Удобно? Удобно. Вот только внутри эти имена компилируются в номера, которые, естественно, непредсказуемы заранее (поправили конфиг и все сдвинулось). Пользователю об этом знать незачем, правда? А вот попытка "скрестить" pf с чем-нибудь снаружи окончится неудачей, потому что внешняя сущность не имеет доступа к этим самым номерам. Поэтому, когда мы делали теги в ipfw, мы сделали их несовместимыми с pf, номерами. Номер навешивается пользователем и неизменен (понижение удобства незначительно, всегда можно назначить номер в переменной shell-скрипта), это позволяет повесить его и в нетграфе и использовать все возможности последнего, что и было применено для фильтрации по содержимому пакета с помощью ng_tag(4).

Вывод: pf лечить нет смысла, он портируется из OpenBSD, и это лишняя головная боль портерам, которой у них и так хватает. А вот к родному ipfw можно и нужно приделать удобные пользователю shortcuts для типичных операций, при этом не отменяя внутренней расширяемости, позволяющей знающему залезть в потроха и сделать что-то непредусмотренное стандартными шаблонами.

Чего нам не хватает.

Как очевидно из вышесказанного, удобства для простого пользователя нам прежде всего не хватает. Но, как это ни парадоксально, фич и расширяемости - тоже. Несмотря на то, что можно написать моудль нетграфа для нужной задачи, с ipfw он будет интегрирован довольно слабо. Например, с той же фильтрацией по содержимому пакета - вот поймали мы байты, а дальше что? Этот пакет никак не связан со всеми остальными в том же соединении. А нам, допустим, надо его засунуть в трубу (зашейпить). И как? И всё, труба (пардон за каламбур). Да, можно на этот пакет создать динамическое правило, тогда все последующие начнут лететь в трубу. Но вот механизм динамических правил в ipfw таков, что соединение-то перехватывается в середине, не с первоначального SYN - а значит, думают динамические правила, это какой-то неправильный пакет, нет такого соединения. Его щас с той стороны по RST отфутболят. Поэтому мы правило-то создадим, для этого самого RST, но на 1 секунду (настраивается в sysctl). В результате, если соединение быстрое, пакеты летают чаще раза в секунду, правило будет сохраняться. Как только задержка - всё, нету шейпинга уже...

И это еще ладно, хоть как-то работать будет. Мы, может, хотим в нетграф на детектирование отправлять только первые N пакетов/килобайт соединения (чтоб процессор зря не грузить). А никак.

=== todo
http://vitus-wagner.livejournal.com/321586.html
pf: block in on $my_ext proto tcp from any !$allowed to any port 80 - ошибка в синтаксисе, неправильно !$allowed
надо понимать что перечисления в pf это всего лишь упрощения для записи правил в конфигах, но при загрузке они разворачиваются в несколько правил. Поэтому практически всегда перечисление с отрицанием даст тебе совершенно не то, что ты хотел. А вот таблица она всегда целостна, как один элемент

ngmatch-in ngmatch-out
osfp - больше одного хука
dlopen() для конфигурирующих модулей ipfw в юзерлэнде
хуки на динамических правилах (2 очереди, на смену стейта и каждый пакет) - можно сделать принудительный TTL, AUDIT, м.б. ipfwsync
сделать подробный экран для показа одного динамического правила по addr/id со всеми полями
обновление регистрами записи в таблице - время срабатывания
ipfw add 1000 fwd $natgw ip from 10.0.0.0/8 to not directly-connected
http://www.etinc.com/index.php?page=bwcompare.htm суппорт в dynrules для шейпинга через tcp window
===

Этот недописанный пост изначально неспешно готовился как памятка на будущее для узкого круга лиц о том, какие изменения в ipfw хотелось бы видеть и хотелось бы сделать. Однако идеей заинтересовались во FreeBSD Foundation и согласились спонсировать разработку этих идей - правда, всё никак не сделают официальный анонс (ну и я сильно подробно не публиковал пока поэтому). Организаторам RootConf 2009 предлагаемые идеи понравились тоже, посему официально сообщаю - я буду рассказывать об этом на оной конференции, проходящей в Москве 13-14 апреля сего года. На странице http://www.rootconf.ru/papers2009/12352.html доступны тезисы, там же, как обещают, будут позже выложены и презентация с видеозаписью доклада. Данный же пост, возможно, будет позднее дописан (или написан новый) с более подробной информацией о работе - ваши комментарии и пожелания по улучшению ipfw, впрочем, можете писать уже сейчас ;)

У меня, правда, есть еще одна проблема - негде остановиться в Москве в ночь с 12 на 15 апреля :) Никто не хочет впустить? :)