Это уже давно не патч, модуль ipset у меня наличествует в дистрибутиве Debian Etch (stable), который часто BSD-шники обвиняют в том, что он устаревает на момент выпуска. Заметьте - это самый консервативный дистрибутив, и даже в нём этот модуль есть!Вот вам "расследование" и доказательство.
Судя по репозиторию исходников netfilter, модуль ipset был добавлен туда 9 февраля 2004 года. Убедитесь сами: http://git.netfilter.org/cgi-bin/gitweb.cgi?p=iptables.git;a...
Впервые он появился в составе iptables версии 1.3.0 от 12 февраля 2005 года, можете посмотреть дату релиза вот здесь: http://git.netfilter.org/cgi-bin/gitweb.cgi?p=iptables.git;a...
В самом консервативном из Linux-дистрибутивов Debian модуль ipset появился в составе пакета iptables версии 1.3.6 (посмотрите тут http://packages.debian.org/search?keywords=iptables&searchon...), это была версия 4.0 выпущенная 08 апреля 2007 (можете посмотреть тут http://www.debian.org/News/2007/20070408).
Debian - самый тормозной дистрибутив из всех Linux'ов, но даже там поддержка модуля ipset на уровне системы, без привлечения сторонних патчей, появилась полтора года назад. Думаю в репозиториях backports или volatile этот модуль появился ещё раньше, мне уже искать лень. Не стоит думаю доказывать, что в остальных дистрибутивах этот модуль в системе появился ещё раньше. Всё вопрос исчерпан.
Прежде чем повторять одну и ту же мантру "ipset не для продакшн" или "костыли в виде патчей", стоит ознакомиться с вопросом.
А вот в *BSD до сих пор несколько PPTP-сессий нельзя установить из-за NAT'а, несмотря на все их три фаерволла. И в stateful режиме фаерволлов не отслеживаются сессии данных активных FTP-клиентов, благодаря чему приходится настраивать ещё и NAT там, где он не нужен.
А уж насчёт стабильности BSD так лучше бы вообще помолчали, там разработчики отвечают только за базовую систему, а дырки в программах из портов их не волнуют. Метод закрытия дырок тоже занятный - берут более свежую версию программы, в которой дыра уже закрыта. В Debian берут ту же версию и закрывают дырку в ней, благодаря чему обновления безопасности происходят совершенно безболезненно, даже в автоматическом режиме без участия сисадмина. Во FreeBSD порт может не скомпилироваться, во время компиляции будет создаваться дополнительная нагрузка на сервер, после установки какое-нибудь мелкое изменение в формате конфига при переходе с одной версии на другую может привести к тому, что обновлённый демон не запустится. Поэтому при обновлении FreeBSD сисадмин должен быть рядом с сервером. А если их двадцать, тридцать и на каждом разные задачи? А если сисадмин уехал в отпуск на месяц, можно ли без участия обновить системы? Нельзя? :-( Что теперь - системы не патчить или обновлять автоматом и молиться, что ни одно обновление не приведёт к неработоспособности сервака?
На йух BSD, им место на маршрутизаторах, только в виде базовой системы, и лучше без портов. И это должны быть единичные маршрутизаторы или абсолютно идентичные, чтоб по rsync все обновлять можно было.
