forum.lissyara.su

Любителям ПФа во FreeBSD на заметку:

А можно вкратце?

Чего вкраце? Там написано, что опенбсдшников не волнует проблема портабильности ПФа, и что оптимизировать его скорость они будут путем более тесной интеграции с другими подсистемами OpenBSD. Сейчас во фришке ПФ и так древний, а после ознакомления с этимим планами появляется предчувствие, что новый ПФ появится еще очень не скоро.

напишите в рассылку бсд что бы убили вообще PF из системы
лучше никакого чем какойто и кривой
и за одно пусть sendmail и bind вычистят

а еще лучще, пусть вообще почистят файло помойку свою

Я б поспорил на эту тему.. ipfw не лучше,имхо.

лучше

Мне не нравится.. Ну,на вкус и цвет...
А чем лучше-то?

Al писал(а):А чем лучше-то?

Работает быстрее и родной (постоянно развивается).

Ну,что можно сделать на нем,чего нельзя сделать на пф? Это я к развитию.
И насчет работает быстрее много споров было.

Al писал(а):Ну,что можно сделать на нем,чего нельзя сделать на пф? Это я к развитию.

Первое что пришло в голову, навскидку, без детального курения man'а: перенаправление на divert socket

Al писал(а):И насчет работает быстрее много споров было.

Опять же, первое что пришло в голову: pf сливает в хлам на многоядерных машинах.

Диверт-сокеты... Ахренеть... Даж и не сразу вспомнил, что это такое..
Если не секрет, хотя б 3 примера, для чего это надо простому админу?
Ну,и подтвердить слова насчет быстродействия хотелось бы. Тем более сливает вхлам. И какой слив в процентах по ппсу?
Не, ну а вдруг штука действительно хорошая...

а зачем простому админу ппс и быстродействие?
чё-то у вас слова с делом расходятсья

времена меняются, сейчас 100мбит НАТить вполне задача для обычного админчика

Al писал(а):Диверт-сокеты... Ахренеть... Даж и не сразу вспомнил, что это такое..
Если не секрет, хотя б 3 примера, для чего это надо простому админу?

Передать трафик внешнему демону. Примеры додумывайте самостоятельно: контроль, учет, нестандартная обработка, в том числе через bpf - чем не задачи для админа?

Al писал(а):Ну,и подтвердить слова насчет быстродействия хотелось бы. Тем более сливает вхлам. И какой слив в процентах по ппсу?
Не, ну а вдруг штука действительно хорошая...

В данный момент под рукой нет железа, на котором можно было бы поставить подобные опыты, так что за результатами в гугл.
На самом деле pf'ом я пользуюсь еще со времен его портирования в 4-ку (тогда еще не в базовую систему, а в дерево портов), периодически (правда очень редко) приходится настраивать его на родном опенке, правда я опенок последний раз щупал года 1.5-2 назад. На домашнем роутере тоже стоит pf - но там старенький pentium2, ни о какой многопроцессорности речи не идет.
Логика правил и организация у pf мне нравится больше чем у ipfw, но глядя правде в глаза - на FreeBSD он по сравнению с ipfw смотрится коряво. При обновлении от версии к версии господа разработчики любят ломать совместимость ABI, что затрудняет портирование - и как было сказано в одном из верхних постов, класть они хотели на удобство портирования за пределы родной ОС; наследием того, что в OpenBSD не шибко хорошо обстоят дела с SMP, является то что распараллеливать процессы он тупо не умеет, данные обрабатываются в один поток, а при достаточно широких каналах и на многоголовых/многоядерных системах это очень сильно сказывается на производительности; pf не умеет фильтровать layer2; еще некоторое время назад была проблема с NAT'ом GRE - не знаю, починили ли это в опенке, но на фре она все еще актуальна; можно перечислять дальше, но для этого нужно лезть в гугл, а мне сейчас откровенно впадлу. И, как уже было сказано, ipfw - родной для FreeBSD, развивается он очень интенсивно, большинство ругани в его адрес откровенно неактуально.

ну скажем 5.x - 6.x ipfw практически не развивался, в 7.x впнули nat через libalias ну и вот сейчас пилят так что треск по исходникам соит

Насчет 5-ки - не скажу, хотя в той ветке страх и жуть что творилось, переход от 4-ки к 6-ке через кровь и порванное мясо. А вот в 6-ке - не согласен. В SMP серьезно продвинулись именно тогда, с тегированием трафика и таблицами, libalias и сделанный на нем ng_nat именно тогда появился - довольно прилично с ним схему работали, кстати говоря, просто netgraph не идеален в плане документированности.

Первый раз слышу про проблемы с натом гре. Работало пару сотен тунелей - ноу проблем.
Ну, фильтрация по макам - это да.... Только не лучше ли маки привязывать в арпе?

Al писал(а):Ну, фильтрация по макам - это да....

Да не нужна она была, она в опёнке в режиме бриджа работает.
Ну да наши привыкли, вот и сделал наш студент в 2008м в рамках проекта Google Summer of Code и это. А вы тут рассуждаете
http://wiki.freebsd.org/GlebKurtsov/Imp ... _filtering

Признаю что у PF есть недостаток перед ipfw в неSMP шности, хорошо что мне это пока фиолетово. В остальном одни преимущества имхо Не зря его портировали во фрю

ipfilter не зря портировали во фрю ;]

Не зря его портировали во фрю

с таким преимуществом, лучше перейти на опенку с нормальным PF
чем юзать кривою имплементацию в бсд

ipfilter не зря портировали во фрю ;]

его никто не портировал
он написан для всех *BSD

Гость писал(а):

Не зря его портировали во фрю

с таким преимуществом, лучше перейти на опенку с нормальным PF
чем юзать кривою имплементацию в бсд

Можно примеры супер кривости в студию ? Нормально работает в обычных ситуациях.

PF написан для openbsd
в freebsd он вставлен костылями

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

ага, просто кинуть исходники ipfilter в /usr/src/sys и он волшебным образом соберется, лечите меня дальше, ок