Дэвид Гвинн (David Gwynne) сообщил (http://undeadly.org/cgi?action=article&sid=20090619100514) об успешном запуске в промышленной эксплуатации и интеграции в дерево исходных текстов OpenBSD-Current кода pfsync c реализацией "active-active stateful" режима работы пакетного фильтра pf, позволяющего синхронизировать таблицы трекинга состояния соединений для нескольких пакетных фильтров, что, в сочетании с механизмом CARP, может применяться для создания отказоустойчивых и распараллеленных на несколько машин межсетевых экранов.
URL: http://undeadly.org/cgi?action=article&sid=20090619100514
Новость: http://www.opennet.me/opennews/art.shtml?num=22253
OpenBSD Движется к ентерпрайзу))
Что значит OpenBSD? pf движется, он не только в OpenBSD
двигает PF впервую очередь команда openbsd, в той же фряхе pf далеко не первой свежести, можете загадывать когда возможность синхронной работы будет во фряхе.
Весь девелопмент в pf сосредоточен в OpenBSD. На фряху идёт порт уже релизнутого и без добавления фич. pfsync думаю в 8-ку засунут, вещь то крутейшая.
Чего стоим, кого ждём?---
HISTORY
The pfsync device first appeared in OpenBSD 3.3. The pfsync device was
imported to FreeBSD 5.3.FreeBSD 7.2 June 6, 2006 FreeBSD 7.2
---
по-моему оно и раньше там было, но только вроде active passive
iptables вроде тоже мог active passive
Зачем оно надо то?
Нет, с идеологической точки зрения для HA вещь очень полезная, но, вот подумайте, как оно с практической стороны.
Что есть "фаервол"? (не люблю это слово, ну да ладно).
Сие есть машина с железом не очень производительного класса, единственое требование предъявляемое к оному фильтровать или иным образом оперировать с сетевым трафиком, проходящим через него.
Т.е. если речь идет не о каких то load балансерах или свичах выше L3, то для выполнения этих функций даже на GigE сети достаточно железяки (о x86 речь) уровня 500Мгц, от 128Мб оперативы и это даже шикарно, на практике я думаю можно еще умерить аппетиты.Теперь о собственно HA и репликации состояния pf.
Где вы реально это собрались использовать? вернее даже сказать на каком железе.
Лично я не знаю где можно найти стоечные машины такого уровня.
А использовать для этих задач полноценное железо - да бог с вами, кошки дешевле встанут раза в два.
Вот и получается, что формально оно есть, а практически нет подходящего железа, где бы это можно было реально применять. Ну разве что на тестовом стенде поиграться.Единственная надежда, что какая-нибудь китайская конторка начнет производство железа под это дело, но цена конечного продукта будет опять же под вопросом и скорее всего сопоставима с теми же кошаками.
>Зачем оно надо то?...
>Лично я не знаю где можно найти стоечные машины такого уровня.
>А использовать для этих задач полноценное железо - да бог с вами,
>кошки дешевле встанут раза в два.Кошки? За такую цену, что стоит нормальный шлюз с PF уровня L3-L4, можно приобрести лишь кошку-свитч L2 с V-LAN'ами.
>>Зачем оно надо то?
>
>...
>>Лично я не знаю где можно найти стоечные машины такого уровня.
>>А использовать для этих задач полноценное железо - да бог с вами,
>>кошки дешевле встанут раза в два.
>
>Кошки? За такую цену, что стоит нормальный шлюз с PF уровня L3-L4,
>можно приобрести лишь кошку-свитч L2 с V-LAN'ами.Например? (ссылки на железки которые используете)
>Например? (ссылки на железки которые используете)Ищите сами 4-8 портовые гигабитные роутеры.
>>Например? (ссылки на железки которые используете)
>
>Ищите сами 4-8 портовые гигабитные роутеры.Зачем так сразу в кусты то... Вдруг и правда есть.
используем Cisco ASA 5580 в кластерном режиме(как раз load balancing), но можно и более младшие модели так использовать
Asa и pix это вроде и есть на основе линукса, у них и команды немного другие, а у младших asa 5505 роцессор geod от amdepic win короче ;)
>Asa и pix это вроде и есть на основе линукса, у них
>и команды немного другие, а у младших asa 5505 роцессор geod
>от amd
>
>epic win короче ;)"вроде и есть на основе линукса" - нет, дополнительные модули - да
на asa 5505, если не ошибаюсь, celeronно смысл поста был о реально используемых "балансировщиках" файеволов
Э. Как это на таком железе обработать Гигабит (Вы упретесь в PCI значительно раньше). Спор "кошка против NIX" давний, сколько ни пробовал по деньгам таки очень похожие решения, плюсы и минусы - не для здесь спорить.
>(Вы упретесь в PCI значительно раньше)сходи уж в википедию почитай про скорость pci шины, особенно обрати внимание на pci express и на то, что можно два скажем контроллера pci поставить от северного моста
Если Вы найдете Piii500 c экспересом - то используйте.
Шина PCI - классическая - на любом мосту упрется ранее 700Mbit нагрузки в одну сторону.
Вику читать по таким вопросам - как-то не привык.
Успехов в хамстве.
это нужно в первую очередь для IPv6 firewalling
>Теперь о собственно HA и репликации состояния pf.
>Где вы реально это собрались использовать? вернее даже сказать на каком железе.
>
>Лично я не знаю где можно найти стоечные машины такого уровня.
>А использовать для этих задач полноценное железо - да бог с вами,
>кошки дешевле встанут раза в два.
>Вот и получается, что формально оно есть, а практически нет подходящего железа,
>где бы это можно было реально применять. Ну разве что на
>тестовом стенде поиграться.Не понял, в чём у вас проблема-то? Файервол на краю сети, выпускающий клиентов в интернет - классическое приложение, без всяких проблем с "нет подходящего железа".
В linux есть conntrack-tools с active-active mode
http://conntrack-tools.netfilter.org/manual.html#sync-aa
блин хочу pf под линух ...жалко давно хочу:)
>блин хочу pf под линух ...жалко давно хочу:)Все хотят. В других BSD оно есть из-за Netgraph. Вот будет нетграф, будет и пф, и нормальный поптоп, и много других фишек.
Но нетграфа в Линуксе и на горизонте не видно:(
> В других BSD оно есть из-за Netgraph.Save me Trouble!!!
Netgraph -- это FreeBSD-specific. PF никаким образом на Netgraph не завязан.
Вот раньше говорили: "будет Netgraph -- будет счастье". Netgraph есть, а счастья нет... (Ильф и Петров так говорили про радио).Netgraph не панацея от всех проблем и реально необходим только для нестандартных ситуаций, вроде объединения разнородных сетей, где нужны разнообразные инкапсуляции. Для этого он и был задуман. Но современные FreeBSDшники на нем рехнулись: сделали GEOM по аналогии, зачем-то понатащили в ядро подсистемы с перекрывающейся функциональностью: три файрвола, три NAT, несколько реализаций QoS, и пытаются компенсировать их недостатки за счет объединения с помощью Netgraph, вместо того, чтобы довести до ума какую-то одну из них. Вот OpenBSD team пилит один pf и правильно делает. Keep it simple, stupid.
Я фигею ...netgraph - это opensource-разработка, которую вел какой-то университет несколько лет в исследовательских целях.
Реализация была сделана для FreeBSD.
Что предлагается ее теперь викинуть чтобы не было ни одной реализации вообще ?>Сделали GEOM по аналогии.
Допустим сделали по аналогии. И что теперь ?
Я могу сказать, что LVM2 тоже сделали по аналогии с GEOM. Давайте выкинем LVM2 !!!>Зачем-то понатащили в ядро три firewall.
Во-первых ipfw - родной firewall,
во-вторых ipfilter - не родной firewall,
в-третьих pf - firewall из OpenBSD.
Чем тебе лично мешает наличие трех firewall в системе ?
Не нравится - не пользуйся.
Ты предлагаешь викинуть два и оставить только один ?
Те кто пользовался ipfw - продолжают им пользоваться.
ipfilter (ipf) вообще делает отдельный человек, не связанный с FreeBSD.
Например кто-то использует pf в OpenBSD. Он без проблем перейдет на использование pf в FreeBSD. Или ему предлагается изучать ipfw или ipf потому что тебе так хочется ?Сам не будь stupid.
И без веской причины не указывай другим что им делать.
> netgraph - это opensource-разработка, которую вел какой-то университет несколько лет в исследовательских целях.У меня другая информация на это счет: http://citrin.ru/netgraph/
> Допустим сделали по аналогии. И что теперь ?
Я могу сказать, что LVM2 тоже сделали по аналогии с GEOM. Давайте выкинем LVM2 !!!
Прочитайте еще раз, что такое GEOM, и что такое LVM2, хорошо? Я не говорю, что надо что-то выкидывать, речь о том, что не надо создавать overhead ради какой-то общности решения, которая никому на практике не нужна. Пользователи и админы Linux и OpenBSD прекрасно обходятся и без Netgraph.
> Чем тебе лично мешает наличие трех firewall в системе ?
Тем, что один файрвол (ipfw) делает одно, другой (pf) -- другое. При этом их функции в значительной степени пересекаются, что противоречит Unix way, когда каждый инструмент делает что-то свое. В результате, на некоторых конфигурациях приходится юзать оба. С dummynet и ALTQ -- та же история. Итого: чем больше подсистем с разными интерфейсами, тем сложнее админить. Вот люди из Netfilter team увидели, что у них функционал размазан по сотне с чем-то модулей, схватились за голову и стали переделывать. FreeBSD по мере накопления нод для Netgraph предстоит то же самое.
Есть ещё TCP Wrappers. Так что же, и этот слой выкинуть? :))Насчёт того, что функционал у них пересекается, так чедь никто не заставляет пользоваться всеми тремя одновременно!
Выучи один из них и спокойно пользуйся только одним. Чудак-человек, это ж не Linux, где "одни костыли служат подпорками другим, а по-одному не работают".
пипец. у iZEN с linux видимо личные счёты. я бы даже сказал - интимные.
выкинте линуксуляторы для начала, спецы блин.
>выкинте линуксуляторы для начала, спецы блин.Прекратите делать блобы под линух, блин!
точно.
Да да ! Wine еще не забудьте удалить ;)
>Да да ! Wine еще не забудьте удалить ;)Вы уже избавились от OpenSSH?
а Вы его всё ещё gcc компилите? :-D
>Тем, что один файрвол (ipfw) делает одно, другой (pf) -- другое. При этом их функции в значительной степени пересекаются, что противоречит Unix way, когда каждый инструмент делает что-то свое.С твоими рассуждениями можно прийти к тому, что Windows - это unix way, а что одна большая ОС, которая делает свое грязное дело =) Файрвол, типа pf - это комплексное решение которое "юнихвеем" и не пахнет. А netgraph это подсистема с помощью которой можно сделать файрвол, но не только, и бредить по поводу его ненужности бессмысленно. Netgraph -это как pipe в unix, благодаря чему и возможен unix way, и вот как раз ipfw реализованный поверх netgraph будет в полной мере соответсвовать unix way.
> Я не говорю, что надо что-то выкидывать, речь о том, что не надо создавать overhead ради какой-то общности решения, которая никому на практике не нужна.
Это я понимаю про GEOM? Тебе на практике не нужны raid различного уровня, поддержка рзделов их шифрование т. д.?
> Пользователи и админы Linux и OpenBSD прекрасно обходятся и без Netgraph.
Пользователи FreeBSD и Linux прекрасно обходятся и без pf.
Пользователи FreeBSD и Linux прекрасно обходятся и без OpenBSD sensor framework.
Пользователи Solaris прекрасно обходятся без *BSD, Linux и т. д =)
И что из этого всего следует? Да, ровным счётом ничего.
> С твоими рассуждениями можно прийти к тому, что Windows - это unix way, а что одна большая ОС, которая делает свое грязное дело =)В Windows по большей части используется объектно-ориентированный подход. И аналог модулей ядра там тоже есть. Но не бессмысленное размазывание одной функции по куче модулей.
> Netgraph -это как pipe в unix, благодаря чему и возможен unix way, и вот как раз ipfw реализованный поверх netgraph будет в полной мере соответсвовать unix way.
Я не против Netgraph как такового, я против того, чтобы все делать только с его помощью, распыляя элементарные операции по множеству модулей. Из-за этого простые вещи, вроде сбора Netflow средствами ядра, приходится решать довольно странными методами. Вот пример настройки Netflow во FreeBSD: http://tmp.barev.net/htmlart/unix/ngnetflow.html В OpenBSD с недавнего времени аналогичная операция делается значительно проще: поднятием и конфигурацией интерфейса pflowX.
$ sudo ifconfig pflow0 create
$ sudo ifconfig pflow0 flowsrc 10.0.0.200 flowdst 10.0.0.1:1234
$ ifconfig pflow0pass out inet proto tcp keep state (pflow)
Три простых команды, не считая правил для файрвола. Сравните это с тем секасом, который приходится делать во FreeBSD.
>> Netgraph -это как pipe в unix, благодаря чему и возможен unix way, и вот как раз ipfw реализованный поверх netgraph будет в полной мере соответсвовать unix way.
>Я не против Netgraph как такового, я против того, чтобы все делать только с его помощью, распыляя элементарные операции по множеству модулей. Из-за этого простые вещи, вроде сбора Netflow средствами ядра, приходится решать довольно странными методами. Вот пример настройки Netflow во FreeBSD: http://tmp.barev.net/htmlart/unix/ngnetflow.html В OpenBSD с недавнего времени аналогичная операция делается значительно проще: поднятием и конфигурацией интерфейса pflowX.Для начала посмотрите на дату ссылки. С тех пор все значительно упростилось.
>
> $ sudo ifconfig pflow0 create
> $ sudo ifconfig pflow0 flowsrc 10.0.0.200 flowdst 10.0.0.1:1234
> $ ifconfig pflow0
>
> pass out inet proto tcp keep state (pflow)
>
> Три простых команды, не считая правил для файрвола. Сравните это с тем секасом, который приходится делать во FreeBSD.Бред полный.
Хотите простую утилитку для этого - напишите. Просто большинству удобнее написать простенький shell-скрипт, чем дописывать никому не нужный функцианал в ifconfig.Netgraph - это аналог SRV-шных streams-ов.
GEOM и Netgraph - хороший фреймворк для написания подсистем ядра и не более того.Никто же не жалуется что большинство систем *BSD написано с использованием инфраструктуры сокетов. Сокеты тоже хороший фреймворк.
> Для начала посмотрите на дату ссылки. С тех пор все значительно упростилось.Ну тогда давайте без пустого теоретизирования. Расскажите или напишите статью, как собирать Netflow с сетевого интерфейса с помощью Netgraph более простым способом, чем описано в данной статье.
> Хотите простую утилитку для этого - напишите. Просто большинству удобнее написать простенький shell-скрипт, чем дописывать никому не нужный функцианал в ifconfig.
Большинству удобнее вообще никаких скриптов не писать, а прочитать руководство и настроить. В маршрутизаторах Juniper при наличии той же FreeBSD почему-то не нужно на каждый чих писать скрипты, достаточно ввести несколько команд и сохранить конфигурацию. Разработчикам, видимо, лень один раз написать пару десятков строк на C, чтобы все остальные потом не писали сотни строк на shell. Простеньким предлагаемый shell-скрипт будет для одного интерфейса. А если нужно считать не весь трафик, а только с определенных IP (из таблицы в ipfw или pf)? И снимать трафик не с одного интерфейса, а с трех. Это будет далеко не простенький шелл-скрипт, нужно перелопатить всю топологию нод и связей. Вот тут Netgraph и покажет свою избыточную сложность. При этом в OpenBSD или Linux задача сведется к изменениям в правилах файрвола.
> GEOM и Netgraph - хороший фреймворк для написания подсистем ядра и не более того.
Netgraph неудобен для решения простых задач из-за того, что функционал слишком размазан по отдельным нодам. При этом необходимо все время конфигурировать связи между нодами, хотя в абсолютном большинстве практических применений связи будут одними и теми же. Яркие примеры -- mpd и тот же сбор Netflow. Городить в ядре гибкость и создавать лишний overhead ради решения одной-двух нестандартных задач -- это неверный подход.
> Никто же не жалуется что большинство систем *BSD написано с использованием инфраструктуры сокетов. Сокеты тоже хороший фреймворк.
Хороший-то хороший, но сокеты были введены в связи с отсутствием поддержки сети в Unix. Как показано в Plan 9, они избыточны, и можно все свести к чтению-записи файлов.
>> Для начала посмотрите на дату ссылки. С тех пор все значительно упростилось.
> Ну тогда давайте без пустого теоретизирования. Расскажите или напишите статью, как собирать Netflow с сетевого интерфейса с помощью Netgraph более простым способом, чем описано в данной статье.Далеко ходить не будем
http://www.slashtmp.ru/2009/05/06/tag-ng_netflow/
http://www.slashtmp.ru/htmlart/unix/pres-ngnetflow.xml#23
http://www.slashtmp.ru/htmlart/unix/pres-ngnetflow.xml#24>> Хотите простую утилитку для этого - напишите. Просто большинству удобнее написать простенький shell-скрипт, чем дописывать никому не нужный функцианал в ifconfig.
> Большинству удобнее вообще никаких скриптов не писать, а прочитать руководство и настроить. В маршрутизаторах Juniper при наличии той же FreeBSD почему-то не нужно на каждый чих писать скрипты, достаточно ввести несколько команд и сохранить конфигурацию. Разработчикам, видимо, лень один раз написать пару десятков строк на C, чтобы все остальные потом не писали сотни строк на shell. Простеньким предлагаемый shell-скрипт будет для одного интерфейса. А если нужно считать не весь трафик, а только с определенных IP (из таблицы в ipfw или pf)? И снимать трафик не с одного интерфейса, а с трех. Это будет далеко не простенький шелл-скрипт, нужно перелопатить всю топологию нод и связей. Вот тут Netgraph и покажет свою избыточную сложность. При этом в OpenBSD или Linux задача сведется к изменениям в правилах файрвола.Собсно кто мешает использовать ng_ipfw+ng_netflow
>> GEOM и Netgraph - хороший фреймворк для написания подсистем ядра и не более того.
> Netgraph неудобен для решения простых задач из-за того, что функционал слишком размазан по отдельным нодам. При этом необходимо все время конфигурировать связи между нодами, хотя в абсолютном большинстве практических применений связи будут одними и теми же. Яркие примеры -- mpd и тот же сбор Netflow. Городить в ядре гибкость и создавать лишний overhead ради решения одной-двух нестандартных задач -- это неверный подход.Еще раз отмечу, netgraph - это фреймворк. К сожалению он пока еще не велик, ибо большая часть написана для того же mpd.
> Никто же не жалуется что большинство систем *BSD написано с использованием инфраструктуры сокетов. Сокеты тоже хороший фреймворк.
> Хороший-то хороший, но сокеты были введены в связи с отсутствием поддержки сети в Unix. Как показано в Plan 9, они избыточны, и можно все свести к чтению-записи файлов.Возможно. Можно ведь и перевести все на ioctl как в линуксе. Но в обозримом будущем никто не будет этим заниматься. Но, ИМХО, интерфейс сокетов значительно удобнее интерфейса VFS.
> Хороший-то хороший, но сокеты были введены в связи с отсутствием поддержки сети в Unix. > Как показано в Plan 9, они избыточны, и можно все свести к чтению-записи файлов.Сокеты в *BSD являются файлами, прикинь?! И ты можешь работать с ними как с файлами (read/write) прикинь?! А еще ты можешь заюзать пару функций (send/recv/shutdown), которые могут тебе помочь в некоторых специфичных случаях прикинь?! Так что, может сокеты не являются файлами? ..или с ними нельзя работать как с файлами? ..или может вы укажете несколько избыточных функций для работы с ними? ..или хотя бы обьясните в чем же является их избыточность?
>>понатащили в ядро подсистемы с перекрывающейся функциональностью: три файрвола, три NATа еще там поддержка нескольких файловых систем есть, представляете? Вот где уж точно перекрываются функции! А PF в ядре нет по-умолчанию :)
PF поставляется как модуль ядра FreeBSD GENERIC. Но его можно вкомпилировать в ядро.
>>>понатащили в ядро подсистемы с перекрывающейся функциональностью: три файрвола, три NAT
>
>а еще там поддержка нескольких файловых систем есть, представляете? Вот где уж
>точно перекрываются функции! А PF в ядре нет по-умолчанию :)Вообще говоря, пока что полноценно поддерживается только одна, не считая "сетевых ФС". Это не аргумент. Вы еще про два транспортных протокола забыли: TCP и UDP. Три файрвола, делающих примерно одно и то же, но с разным синтаксисом правил и разными ограничениями -- это странно. Три неполноценных реализации QoS (dummynet, ALTQ и ng_car) -- тоже.
И чё ты так переживаешь то тау? Если оно такое плохое - зачем юзаешь? Ответ прост - да всё у них нормально и с фаерволами и с остальным. Или давай Линкс ругать что слишком много FS поддерживает вместо одной - правильной! :)Меня лично не напрягает когда есть выбор из нескольких хороших вещей, меня напрягают совки которые всё запрешаютЪ и не-пущаютЪ ... :-р
В NetBSD и OpenBSD никакого нетграфа нет... :)А мне pf не нужен в linux. Что в нём такого волшебного? Многие FreeBSD-шники используют до сих пор ipfw и не собираются переходить на что-то другое...
>А мне pf не нужен в linux. Что в нём такого волшебного?
>Многие FreeBSD-шники используют до сих пор ipfw и не собираются переходить
>на что-то другое...Волшебного? Да просто тысячи правил IPTABLES на PF можно переписать в сотню и держать их все в голове благодаря высокоуровневому языку описания (DSL-подобный синтаксис).
>А мне pf не нужен в linux. Что в нём такого волшебного?
>Многие FreeBSD-шники используют до сих пор ipfw и не собираются переходить
>на что-то другое...
>>Волшебного? Да просто тысячи правил IPTABLES на PF можно переписать в сотню и держать их >>все в голове благодаря высокоуровневому языку описания (DSL-подобный синтаксис).Согласен! PF намного лучше iptables
ну и что. мне вот и iptables хватает.
Вы ещё в крестовый поход соберитесь. и лозунг - "наш брандмауэра единственно верный! смерть неверным брандмауэрам!"
и возглавить вас есть кому. айзен - бздишное сердце.
>Согласен! PF намного лучше iptablesНетфильтер намного мощнее. Не умеете пользоваться, сидите с PF. Рядом вон новость про то что ipfw портировали в linux. Вообще смех на палочке, а ведь найдутся желающие этим пользоваться. Ну и ладно...
>Нетфильтер намного мощнее. Не умеете пользоваться, сидите с PF. Рядом вон новость
>про то что ipfw портировали в linux. Вообще смех на палочке,
>а ведь найдутся желающие этим пользоваться. Ну и ладно...А некоторые велосипедами пользуются! :) Вот смех, ведь есть автомобили... :) А еще пешком некоторые любят ходить :) ЛОЛ :)
"Волшебного? Да просто тысячи правил IPTABLES на PF можно переписать в сотню и держать их все в голове благодаря высокоуровневому языку описания (DSL-подобный синтаксис)."Это что за задача, где надо как минимум 100 правил для pf и 1000 для netfilter? :-D
>"Волшебного? Да просто тысячи правил IPTABLES на PF можно переписать в сотню
>и держать их все в голове благодаря высокоуровневому языку описания (DSL-подобный
>синтаксис)."
>
>Это что за задача, где надо как минимум 100 правил для pf
>и 1000 для netfilter? :-DТакая, например: http://www.lissyara.su/?id=1833
>>
>>Это что за задача, где надо как минимум 100 правил для pf
>>и 1000 для netfilter? :-D
>
>Такая, например: http://www.lissyara.su/?id=1833Вы же не знаете, как конфигурируется QoS в Linux. О чем тогда можно с вами говорить? Очереди и полосы пропускания конфигурируются с помощью tc, трафик классифицируется там же (http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm). Таблица для брутфорсеров ssh формируется с помощью модулей ipset и hashlimit. Синтаксис правил будет сложнее, чем в pf, но их будет явно не в 10 раз больше.
Если вам на офис из 4-х компьютеров надо 1000 правил нетфильтра, то медицина, увы, бессильна!!! :-D
это нужно в первую очередь для IPv6 firewalling