forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Раздел полезных советов: Порядок прохождения пакетов в пакетных фильтрах FreeBSD, auto_tips (?), 07-Июл-07, (0) [смотреть все]

вот неудобно, однако, хочется чтоб порядок прохождения на вход и на выход были о, SunTech (?), 16:14 , 07-Июл-07, (1) //

Так и есть на самом деле Регистрация хуков от пакетных фильтров происходит след, butcher (ok), 12:54 , 23-Июл-07, (3)
Это неудобство объясняется очень просто нет у фри нормального файрвола и нормал, www2 (??), 17:38 , 12-Окт-07, (4) //

И с которым граблей , Аноним (5), 14:38 , 25-Май-08, (5) //

Нисколько Со времени, прошедшего с того коммента, успел на практике настроить не, www2 (??), 15:47 , 25-Май-08, (6)

Ну так остановитесь на каком-нибудь одном и его пользуйте Одного PF недостато, ASh (??), 00:34 , 26-Май-08, (7)

Я остановился на iptables - , www2 (??), 06:57 , 26-Май-08, (8)

Птичий синтаксис нагляднее Не поверю Новичка ipfw можно научить за час-полтора, nuclight (ok), 21:24 , 27-Май-08, (9)

Новичка iptables можно научить за то-же время и на таком-же уровне При этом я н, www2 (??), 17:21 , 28-Май-08, (10)

Ещё могу добавить что из Linux ов я не считаю технологичными 1 Slackware - отсу, www2 (??), 17:47 , 28-Май-08, (11)
Разумеется, о владении в совершенстве никто не говорил Да без проблем Простите, , nuclight (ok), 19:55 , 28-Май-08, (12)

Эта уникальная заметка вышла слишком поздно для меня 20 мая 2008 - чуть больше , www2 (??), 21:36 , 28-Май-08, (13)

Вы делаете некорректное сравнение Во первых, схема прохождения пакетов через ip, nuclight (ok), 23:30 , 07-Июн-08, (14)

Но при этом вся таблица правил свалена в кучу и будет просматриваться для проход, www2 (??), 21:43 , 08-Июн-08, (15)

Оффтопик Ещё раз обозначу почему я так люблю употреблять слово технологичность , www2 (??), 22:15 , 08-Июн-08, (16)

Это все мишура То, что кому-то там легче сложнее читать - лишь его проблемы На , Avgoor (?), 18:44 , 24-Июн-08, (17)
Ну да, я вот о Вас забочусь, хочу чтобы Вам не достались такие же через заднее м, www2 (??), 07:38 , 25-Июн-08, (18)

в линухе фаервол не такой уж мощный - ему очень нехватает таблиц с 1000 правил , redixin (?), 01:44 , 24-Сен-08, (19) //

Название iptables ни о чём не говорит Нечего не зеркало пенять коли рожа то ест, www2 (??), 07:54 , 24-Сен-08, (20)

вот именно что название, название новое а внутри все теже ipchains Не знаете р, redixin (?), 16:15 , 25-Сен-08, (21)

Погуглил, нашёл вот такой интересный тест http bulk fefe de scalability Правда, www2 (??), 10:43 , 28-Сен-08, (22)

говорит 404 ipset это и есть тот самый левый патч который страшно ставить в про, redixin (?), 13:34 , 24-Окт-08, (23)

Это уже давно не патч, модуль ipset у меня наличествует в дистрибутиве Debian Et, www2 (??), 15:09 , 24-Окт-08, (24)

http w3dev org ua debian-guaranteed-entropy jpgоккто повторял я разок сказал,, redixin (?), 23:33 , 16-Апр-09, (25)

Уступает в чём Пассивные соединения работают отменно это когда клиент сам устан, www2 (??), 08:12 , 17-Апр-09, (26)

в ipfw есть tablearg очень очень приятная вещь в ipfw есть простые шустрые шейп, redixin (?), 10:52 , 17-Апр-09, (27)

ipsetПро imq первый раз слышу Не пробовали tc Не костыль, а штатная очень гибк, www2 (??), 14:32 , 17-Апр-09, (28)
в ipset нет tableargs, погуглитеtc привязывается к интерфейсу, а если у меня куч, redixin (?), 15:14 , 17-Апр-09, (29)
Погуглил Отвечу Вашими словами Фраза в духе названных мной фряшников-фанатиков , www2 (??), 15:52 , 17-Апр-09, (30)
я гдето выше говорил о шейперахвообщето FreeBSD работает на ARM - пара минут на, redixin (?), 16:00 , 17-Апр-09, (31)

По опыту использованиюна выходе ipfw ipfilter , viper (??), 09:20 , 09-Июл-07, (2)
а меня втыкает pf, который умеет и натить аж 2-мя способами у каждого по 2-ва мо, unknownDaemon (?), 22:55 , 11-Июн-10, (32)
Получается, что если пакет прошёл один файервол, он не проходит остальные Так , skeletor (ok), 22:06 , 18-Окт-10, (33) //

Нет, пакет должен получить одобрение от всех фаерволлов Если пакет прошёл через, www2 (??), 09:23 , 19-Окт-10, (34)

Сообщения [Сортировка по времени | RSS]

19. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD" +/–

Сообщение от redixin (?), 24-Сен-08, 01:44

в линухе фаервол не такой уж мощный - ему очень нехватает таблиц. с 1000 правил и 800 полос в шейпере на 10000 пакетов/сек становится на колени очень мощный писюк, в тоже время на фре с таблицами тоже самое просто летает, и не мудрено - таблицы это вам не цепочки правил

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

20. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD" +/–

Сообщение от www2 (??), 24-Сен-08, 07:54

>в линухе фаервол не такой уж мощный - ему очень нехватает таблиц.
Название iptables ни о чём не говорит?
>с 1000 правил и 800 полос в шейпере на 10000 пакетов/сек
>становится на колени очень мощный писюк,
Нечего не зеркало пенять коли рожа (то есть руки) крива.
Вы это флейма ради или Вы всё-таки представляете разницу между средствами управления трафиком во FreeBSD и Linux?
>в тоже время на фре
>с таблицами тоже самое просто летает, и не мудрено - таблицы
>это вам не цепочки правил
Очень глубокомысленный вывод. Ценю. "Таблицы" звучит круче чем "Цепочки".

Ответить | Правка | Наверх | Cообщить модератору

21. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD" +/–

Сообщение от redixin (?), 25-Сен-08, 16:15

> Название iptables ни о чём не говорит?
вот именно что название, название новое а внутри все теже ipchains =)
Не знаете разницы между таблицами и цепочками? слышали про быстрый поиск с хеш-таблицами? нет? погуглите.
Время поиска по цепочке правил линейно зависит от количества правил. Поиск же по хеш таблице практически не зависит от количества записей в таблице. Вот цитата с букваря по pf "a table is ideal for holding a large group of addresses as the lookup time on a table holding 50,000 addresses is only slightly more than for one holding 50 addresses"
>Нечего не зеркало пенять коли рожа (то есть руки) крива.
А как иначе разруливать ситуацию когда есть 600 адресов которые нужно дропнуть, и 400 адресов которые нужно натить, причем эти адреса постоянно добавляются/удаляются?
в случае с pf мы добавляем 2 правила:
block from <drops> to any
nat from <nats> to any
Начинку таблиц без проблем можно менять на лету. Время поиска по такой таблице очень и очень маленькое.
В случае с линухом мы вынуждены держать 1000 правил, поиск по 1000 правил идет настолько долго что ksoftirqd вылазит вверх (это симптом, никогда такого не видели?) и машина просто не вылазит из прерываний. LA растер вверх а количество успешно прошедших пакетов - вниз.
Есть патч для linux который добавляет такой функционал, но не очень хочется приключений связанных с глюками third level патча.
> Очень глубокомысленный вывод. Ценю. "Таблицы" звучит круче чем "Цепочки".
Не просто звучит, но и работает =) Простой линейный поиск гораздо медленеей поиска по self-ballancing binary tree (хотя я не уверен что в pf именно такое дерево, лень в исходники лезть)

Ответить | Правка | Наверх | Cообщить модератору

22. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD" +/–

Сообщение от www2 (??), 28-Сен-08, 10:43

>Не знаете разницы между таблицами и цепочками? слышали про быстрый поиск с
>хеш-таблицами? нет? погуглите.
Погуглил, нашёл вот такой интересный тест:
http://bulk.fefe.de/scalability/
Правда он к обсуждаемому вопросу не имеет отношения...
>Время поиска по цепочке правил линейно зависит от количества правил. Поиск же
>по хеш таблице практически не зависит от количества записей в таблице.
>Вот цитата с букваря по pf "a table is ideal for
>holding a large group of addresses as the lookup time on
>a table holding 50,000 addresses is only slightly more than for
>one holding 50 addresses"
Аналогом таблиц pf в iptables является модуль ipset. Поиск же по спискам правил точно так же линеен.
В Linux эмпирическим путём обнаружилась интересная особенность - кэширование совпадений для правил, правда не нашёл прямых упоминаний об этом от разработчиков netfilter. В цепочках iptables долго идёт только первый поиск. Если приходит пакет с такими же атрибутами, что и уже проверенный, для этого пакета правило определяется из кэша: http://www.protocols.ru/Papers/iptables-test.shtml
>>Нечего не зеркало пенять коли рожа (то есть руки) крива.
>А как иначе разруливать ситуацию когда есть 600 адресов которые нужно дропнуть,
>и 400 адресов которые нужно натить, причем эти адреса постоянно добавляются/удаляются?
>в случае с pf мы добавляем 2 правила:
>block from <drops> to any
>nat from <nats> to any
В случае с iptables точно так же, почитайте man:
http://ipset.netfilter.org/ipset.man.html
>Начинку таблиц без проблем можно менять на лету. Время поиска по такой
>таблице очень и очень маленькое.
>В случае с линухом мы вынуждены держать 1000 правил, поиск по 1000
>правил идет настолько долго что ksoftirqd вылазит вверх (это симптом, никогда
>такого не видели?) и машина просто не вылазит из прерываний. LA
>растер вверх а количество успешно прошедших пакетов - вниз.
Я же говорю - руки кривые.
>Есть патч для linux который добавляет такой функционал, но не очень хочется
>приключений связанных с глюками third level патча.
Каждый сильно востребованный патч со временем попадёт в upstream.
>> Очень глубокомысленный вывод. Ценю. "Таблицы" звучит круче чем "Цепочки".
>Не просто звучит, но и работает =) Простой линейный поиск гораздо медленеей
>поиска по self-ballancing binary tree (хотя я не уверен что в
>pf именно такое дерево, лень в исходники лезть)
Ну и iptables тоже не просто звучит, но и работает =)

Ответить | Правка | Наверх | Cообщить модератору

23. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD" +/–

Сообщение от redixin (?), 24-Окт-08, 13:34

>Погуглил, нашёл вот такой интересный тест:
>http://bulk.fefe.de/scalability/
>Правда он к обсуждаемому вопросу не имеет отношения...
>
говорит 404..
>Аналогом таблиц pf в iptables является модуль ipset. Поиск же по спискам
>правил точно так же линеен.
>
ipset это и есть тот самый левый патч который страшно ставить в продакшн.. приключений както не хочется..
>В Linux эмпирическим путём обнаружилась интересная особенность - кэширование совпадений для правил,
>правда не нашёл прямых упоминаний об этом от разработчиков netfilter. В
>цепочках iptables долго идёт только первый поиск. Если приходит пакет с
>такими же атрибутами, что и уже проверенный, для этого пакета правило
>определяется из кэша: http://www.protocols.ru/Papers/iptables-test.shtml
"В завершении я хочу привести результаты теста на реально используемом шлюзе с достаточно высоким уровнем трафика (на момент тестирования исходящий трафик составлял около 2 Мбит/с)."
ой я вас умоляю не смешите мне тапочки этими двумя мегабитами. кеширование это костыли которые дают прирост только в синтетике
>В случае с iptables точно так же, почитайте man:
>http://ipset.netfilter.org/ipset.man.html
>
все тот же стремный левый патч
>>Начинку таблиц без проблем можно менять на лету. Время поиска по такой
>>таблице очень и очень маленькое.
>>В случае с линухом мы вынуждены держать 1000 правил, поиск по 1000
>>правил идет настолько долго что ksoftirqd вылазит вверх (это симптом, никогда
>>такого не видели?) и машина просто не вылазит из прерываний. LA
>>растер вверх а количество успешно прошедших пакетов - вниз.
>
>Я же говорю - руки кривые.
>
удивительный коментарий, и чего я вам доказываю?
>>Есть патч для linux который добавляет такой функционал, но не очень хочется
>>приключений связанных с глюками third level патча.
>
>Каждый сильно востребованный патч со временем попадёт в upstream.
>
этот востребованный патч уже давно есть в *BSD, а в линухе от него кернел паники бывают
>>> Очень глубокомысленный вывод. Ценю. "Таблицы" звучит круче чем "Цепочки".
>>Не просто звучит, но и работает =) Простой линейный поиск гораздо медленеей
>>поиска по self-ballancing binary tree (хотя я не уверен что в
>>pf именно такое дерево, лень в исходники лезть)
>
>Ну и iptables тоже не просто звучит, но и работает =)
ага, работает и ядро до полусмерти зашугивает... подождем когда его вылижут, а пока его даже на тестовую железку ставить страшно

Ответить | Правка | Наверх | Cообщить модератору

24. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD" +/–

Сообщение от www2 (??), 24-Окт-08, 15:09

Это уже давно не патч, модуль 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 все обновлять можно было.

Ответить | Правка | Наверх | Cообщить модератору

25. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD" +/–

Сообщение от redixin (?), 16-Апр-09, 23:33

>Это уже давно не патч, модуль ipset у меня наличествует в дистрибутиве
>Debian Etch (stable), который часто BSD-шники обвиняют в том, что он
>устаревает на момент выпуска. Заметьте - это самый консервативный дистрибутив, и
>даже в нём этот модуль есть!
>
http://w3dev.org.ua/debian-guaranteed-entropy.jpg
ок
>Прежде чем повторять одну и ту же мантру "ipset не для продакшн"
>или "костыли в виде патчей", стоит ознакомиться с вопросом.
кто повторял? я разок сказал, а вы тут про дебиан 3 абзаца мантр =)
дело даже не в том что ipset это костыль который стремаются
добавлять в основную ветку, а в том что iptables даже вместе с
ipset уступают и ipfw и pf.
>
>А вот в *BSD до сих пор несколько PPTP-сессий нельзя установить из-за
>NAT'а, несмотря на все их три фаерволла. И в stateful режиме
>фаерволлов не отслеживаются сессии данных активных FTP-клиентов, благодаря чему приходится настраивать
>ещё и NAT там, где он не нужен.
насчет pptp не тестил, но FTP работает отменно, враки это всё
>А уж насчёт стабильности BSD так лучше бы вообще помолчали, там разработчики
>отвечают только за базовую систему, а дырки в программах из портов
>их не волнуют. Метод закрытия дырок тоже занятный - берут более
>свежую версию программы, в которой дыра уже закрыта. В Debian берут
>ту же версию и закрывают дырку в ней, благодаря чему обновления
>безопасности происходят совершенно безболезненно, даже в автоматическом режиме без участия сисадмина.
ну вы поняли лол
http://w3dev.org.ua/debian-guaranteed-entropy.jpg
>Во FreeBSD порт может не скомпилироваться, во время компиляции будет создаваться
>дополнительная нагрузка на сервер, после установки какое-нибудь мелкое изменение в формате
>конфига при переходе с одной версии на другую может привести к
>тому, что обновлённый демон не запустится. Поэтому при обновлении FreeBSD сисадмин
>должен быть рядом с сервером. А если их двадцать, тридцать и
>на каждом разные задачи? А если сисадмин уехал в отпуск на
>месяц, можно ли без участия обновить системы? Нельзя? :-( Что теперь
>- системы не патчить или обновлять автоматом и молиться, что ни
>одно обновление не приведёт к неработоспособности сервака?
>
чего это вдрук оно приведет к неработоспособности?
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/up...
ок

>На йух BSD, им место на маршрутизаторах, только в виде базовой системы,
>и лучше без портов. И это должны быть единичные маршрутизаторы или
>абсолютно идентичные, чтоб по rsync все обновлять можно было.
обновлять, строить кластеры, идентичные, не идентичные, можно всё
это не проблема. но и речь не об этом
откуда такая ненависть к BSD?

Ответить | Правка | Наверх | Cообщить модератору

26. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD" +/–

Сообщение от www2 (??), 17-Апр-09, 08:12

>дело даже не в том что ipset это костыль который стремаются
>добавлять в основную ветку, а в том что iptables даже вместе с
>ipset уступают и ipfw и pf.
Уступает в чём?
>>А вот в *BSD до сих пор несколько PPTP-сессий нельзя установить из-за
>>NAT'а, несмотря на все их три фаерволла. И в stateful режиме
>>фаерволлов не отслеживаются сессии данных активных FTP-клиентов, благодаря чему приходится настраивать
>>ещё и NAT там, где он не нужен.
>
>насчет pptp не тестил, но FTP работает отменно, враки это всё
Пассивные соединения работают отменно (это когда клиент сам устанавливает два соединения с FTP-сервером), а активные нет (когда клиент устанавливает управляющее соединение, а сервер подключается к клиенту для передачи данных).
>чего это вдрук оно приведет к неработоспособности?
>
>http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/up...
>ок
Посмотрел. Это читать при каждом обновлении каждого сервера? То есть появилась дырка, нужно обновить 50 серваков. Я буду шаманить с бубном перед каждым серваком? Да я пока закончу, новые дырки появятся.
Особенно хорош вот этот ЛОЛ:
># portupgrade -af
На каждом сервере.
>откуда такая ненависть к BSD?
Как таковой ненависти к BSD нет. Я постоянно использую FreeBSD. Особенно мне нравится VPN-сервер mpd. Мне нравится маленький размер NetBSD. Мне нравится концепция ядра DragonFly BSD.
В BSD мне не нравятся:
1. неудобство пакетной системы (каждый раз пытаясь обновить или установить программу в FreeBSD вспоминаю насколько легко и быстро я то же самое сделал бы в Debian),
2. неразвитость ядра (те небольшие, на первый взгляд, недостатки иногда могут становиться принципиальными недостатками. Например, те же несколько PPTP-соединений через NAT были для меня просто до жути необходимы, причём срочно. Мне пришлось испытать ОЧЕНЬ сильную головную боль из-за этого),
3. фанатики с одним-двумя серверам, блещущие знаниями хэндбука, которые говорят МНЕ, что недостатков, которые Я прочувствовал на СВОЕЙ шкуре, нет. Это, знаете ли, несколько оскорбляет.

Ответить | Правка | Наверх | Cообщить модератору

27. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD" +/–

Сообщение от redixin (?), 17-Апр-09, 10:52

>>дело даже не в том что ipset это костыль который стремаются
>>добавлять в основную ветку, а в том что iptables даже вместе с
>>ipset уступают и ipfw и pf.
>
>Уступает в чём?
>
в ipfw есть tablearg (очень очень приятная вещь)
в ipfw есть простые шустрые шейпера (pipes)(в линухе
чтобы получить такой функционал приходится юзать костыль imq
который кроме всего прочего дико тормозит)
это то изза чего я кое-где пересел на FreeBSD, не удивлюсь если
есть еще
>># portupgrade -af
>
>На каждом сервере.
>
а дебиан чудесным образом сам запустит все на всех серверах? лол
>
>В BSD мне не нравятся:
>1. неудобство пакетной системы (каждый раз пытаясь обновить или установить программу в
>FreeBSD вспоминаю насколько легко и быстро я то же самое сделал
>бы в Debian)
да ну прям таки сделать cd ..... && make install прямо таки головная боль
>2. неразвитость ядра (те небольшие, на первый взгляд, недостатки иногда могут становиться
>принципиальными недостатками.
неразвитость ядра???77 там три пакетных фильтра, и на SMP оно уделывает всех.
это неразвитость? чего вам там нехватает? jfs? лол
>Например, те же несколько PPTP-соединений через NAT были для
>меня просто до жути необходимы, причём срочно.
> Мне пришлось испытать ОЧЕНЬ
>сильную головную боль из-за этого)
так вот откуда ненависть =)
>3. фанатики с одним-двумя серверам, блещущие знаниями хэндбука
лол кто ето?
> которые говорят МНЕ, что недостатков, которые Я прочувствовал на
> СВОЕЙ шкуре, нет. Это, знаете ли, несколько оскорбляет.
недостатки есть, но позвольте напомнить что речь идет о пакетных фильтрах
в FreeBSD и Linux, а не о крутости менеджера пакетов в Debian/GNU

Ответить | Правка | Наверх | Cообщить модератору

28. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD" +/–

Сообщение от www2 (??), 17-Апр-09, 14:32

>>>дело даже не в том что ipset это костыль который стремаются
>>>добавлять в основную ветку, а в том что iptables даже вместе с
>>>ipset уступают и ipfw и pf.
>>
>>Уступает в чём?
>>
>
>в ipfw есть tablearg (очень очень приятная вещь)
ipset
>в ipfw есть простые шустрые шейпера (pipes)(в линухе
>чтобы получить такой функционал приходится юзать костыль imq
>который кроме всего прочего дико тормозит)
Про imq первый раз слышу. Не пробовали tc? Не костыль, а штатная очень гибкая система приоритезации, формирования и ограничения трафика.
>это то изза чего я кое-где пересел на FreeBSD, не удивлюсь если
>есть еще
Ответы выше.
>>># portupgrade -af
>>
>>На каждом сервере.
>>
>
>а дебиан чудесным образом сам запустит все на всех серверах? лол
Нет. Он просто не будет компилировать. А ещё он (если это стабильная ветка) не будет чинить то, что не сломалось - обновит только дырявые пакеты их патчеными версиями.
>>В BSD мне не нравятся:
>>1. неудобство пакетной системы (каждый раз пытаясь обновить или установить программу в
>>FreeBSD вспоминаю насколько легко и быстро я то же самое сделал
>>бы в Debian)
>
>да ну прям таки сделать cd ..... && make install прямо таки
>головная боль
Читаем http://www.lissyara.su/?id=1153
Видим:
>Ага. libtool в двух экземплярах... Либо чё-то глюкануло, либо так и задумано, ввиду того >что не все приложения переваривают новые версии зависмостей, а хотят чё-то старое. >Попробуем пофиксить БД:
>/usr/home/lissyara/>pkgdb -F
>Прервал - куча ошибок из-за одного отсутствующего порта. Значит пойдём правильным путём, >- доставим зависисмось, которую он хочет:
>/usr/home/lissyara/>cd /usr/ports/misc/ldconfig_compat
Вот мои главные претензии. В 60% случаев невозможно собрать что-нибудь, не споткнувшись на каком-нибудь глюке парочку-другую раз.
И ещё мне не нравится, что я не могу собрать по команде make package определённый пакет, если в системе уже установлен другой пакет или пакеты других версий, от которых зависит собираемый пакет. То есть практически всегда такая ситуация: здесь играем, здесь не играем, здесь пятно от рыбы... Ну некогда мне заниматься обходом граблей и сооружением костылей, лучше я возьму предсказуемую систему.
>>2. неразвитость ядра (те небольшие, на первый взгляд, недостатки иногда могут становиться
>>принципиальными недостатками.
>
>неразвитость ядра???77 там три пакетных фильтра, и на SMP оно уделывает всех.
Три пакетных фильтра - это да, это серьёзно. Можно зафильтроваться по самое нихочу. Лучше брать качеством, а не количеством.
Кого SMP уделывает, простите? Может Solaris? В Linux поддержка SMP появилась гораздо раньше. Вот у Мэта Диллона свой взгляд на SMP и уделыванием он занимается довольно серьёзно. В NetBSD SMP Эндрю Доран занимается хоть и поздно, зато планомерно и качественно: http://www.netbsd.org/~ad/smp/tasks.html В общем, пустой трёп.
>это неразвитость? чего вам там нехватает? jfs? лол
Аналога OpenVZ, UML, Xen dom0 (хотя уже утрачивает актуальность), ядра на ARM-процессорах. В том числе, да, и XFS и ReiserFS в режиме записи. Не хватает аналога LVM. Нет аналога LTSP для FreeBSD, хотя безусловно, всё то же самое можно сделать и самому.
>>Например, те же несколько PPTP-соединений через NAT были для
>>меня просто до жути необходимы, причём срочно.
>> Мне пришлось испытать ОЧЕНЬ
>>сильную головную боль из-за этого)
>
>так вот откуда ненависть =)
Ещё раз говорю, ненависти нет. Просто я научился грамотнее тратить своё время.
>>3. фанатики с одним-двумя серверам, блещущие знаниями хэндбука
>
>лол кто ето?
Ну, может быть к этой категории относитесь и Вы. Есть ещё Lissyara, Федорчук, iZen. Ещё мне нравится коронная фраза приверженцев FreeBSD и Gentoo "Ну, компьютеры сейчас мощные.", когда я говорю о том, что компиляция портов или портежей отнимает ресурсы системы и занимает немалое время.
>> которые говорят МНЕ, что недостатков, которые Я прочувствовал на
>> СВОЕЙ шкуре, нет. Это, знаете ли, несколько оскорбляет.
>недостатки есть, но позвольте напомнить что речь идет о пакетных фильтрах
>в FreeBSD и Linux, а не о крутости менеджера пакетов в Debian/GNU
Грамотно брошенная в это раздел форума фраза "с которым граблей" была не моя. До этой фразы я был BSD'шником. Когда ответил на неё, уже хорошо познакомился с Debian и понял сколько времени и нервов я потерял (во многом) зря, отстаивая преимущества FreeBSD. Вы тоже начали ещё одну ветку, забросив фразу "в линухе фаервол не такой уж мощный".

Ответить | Правка | Наверх | Cообщить модератору

29. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD" +/–

Сообщение от redixin (?), 17-Апр-09, 15:14

>>
>>в ipfw есть tablearg (очень очень приятная вещь)
>
>ipset
>
в ipset нет tableargs, погуглите
>>в ipfw есть простые шустрые шейпера (pipes)(в линухе
>>чтобы получить такой функционал приходится юзать костыль imq
>>который кроме всего прочего дико тормозит)
>
>Про imq первый раз слышу. Не пробовали tc? Не костыль, а штатная
>очень гибкая система приоритезации, формирования и ограничения трафика.
>
tc привязывается к интерфейсу, а если у меня куча интерфейсов и трафик
по ним гуляет? приходится юзать IMQ, это виртуальный интерфейс
сделан специально для таких и подобных целей. tc+imq жутко тормозит.
на том же железе ipfw2 + tableargs + pipes удалось выжать почти в
десять раз больше (100килопакетов на фре против 12 на линухе)

>Ответы выше.
ок
>[оверквотинг удален]
>Вот мои главные претензии. В 60% случаев невозможно собрать что-нибудь, не споткнувшись
>на каком-нибудь глюке парочку-другую раз.
>
>И ещё мне не нравится, что я не могу собрать по команде
>make package определённый пакет, если в системе уже установлен другой пакет
>или пакеты других версий, от которых зависит собираемый пакет. То есть
>практически всегда такая ситуация: здесь играем, здесь не играем, здесь пятно
>от рыбы... Ну некогда мне заниматься обходом граблей и сооружением костылей,
>лучше я возьму предсказуемую систему.
>
это все ок, но ведь речь о пакетных фильтрах лол
>Три пакетных фильтра - это да, это серьёзно. Можно зафильтроваться по самое
>нихочу. Лучше брать качеством, а не количеством.
>
iptables качеством уделывает только Outpost лол

>Кого SMP уделывает, простите? Может Solaris? В Linux поддержка SMP появилась гораздо
>раньше.
наличие поддержки и ее качество -- вещи разные, есть
много бенчмарков где видно насколько все плохо с SMP в Linux

>Аналога OpenVZ, UML, Xen dom0 (хотя уже утрачивает актуальность), ядра на ARM-процессорах.
>В том числе, да, и XFS и ReiserFS в режиме записи.
>Не хватает аналога LVM. Нет аналога LTSP для FreeBSD, хотя безусловно,
>всё то же самое можно сделать и самому.
>
лол зачем всё это? во фре уже теперь есть zfs
(хотя говаривают что в линухе недавно появилась поддержка
btrfs ок)
ядра на ARM процессорах? это чтобы ОСь можно было на пылесосе запустить?
но зачем?
>Ну, может быть к этой категории относитесь и Вы. Есть ещё Lissyara,
>Федорчук, iZen. Ещё мне нравится коронная фраза приверженцев FreeBSD и Gentoo
>"Ну, компьютеры сейчас мощные.", когда я говорю о том, что компиляция
>портов или портежей отнимает ресурсы системы и занимает немалое время.
она занимает немалое время если собирать KDE4, но вы ведь на серверах
не пользуетесь кедами? =)
собрать nginx, питон да postgres -- пара минут делов, зато оптимизации,
все дела.. как известно у гентушников даже скорость света на 6% выше =))
где вы видели сервер на котором установлено 300 пакетов которые будут
2е суток компилироваться? развечто "сервер сегмента говносети" лол
обычно сервер выполняет конкретные фунции, на нем кроме ядра и баша
установлена еще пара софтин и ВСЁ.
>Грамотно брошенная в это раздел форума фраза "с которым граблей" была не
>моя. До этой фразы я был BSD'шником. Когда ответил на неё,
>уже хорошо познакомился с Debian и понял сколько времени и нервов
>я потерял (во многом) зря, отстаивая преимущества FreeBSD. Вы тоже начали
>ещё одну ветку, забросив фразу "в линухе фаервол не такой уж
>мощный".
дык, ветка то о порядке прохождения пакетов в pf, никто вас сюда не звал
со своим линухом

Ответить | Правка | Наверх | Cообщить модератору

30. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD" +/–

Сообщение от www2 (??), 17-Апр-09, 15:52

>в ipset нет tableargs, погуглите
Погуглил. Отвечу Вашими словами:
>лол зачем всё это?
Фраза в духе названных мной фряшников-фанатиков: "Во FreeBSD всё есть. А если чего и нет, то значит оно не нужно." Я думаю Вы уже поняли, что объяснять Вам, занимающему такую позицию, зачем всё это нужно, мне не особо хочется, да и не имеет смысла.
>собрать nginx, питон да postgres -- пара минут делов, зато оптимизации,
все дела.. как известно у гентушников даже скорость света на 6% выше =))
Затраты и выгода несоизмеримы. Слышал о домохозяйках, которые поедут в другую часть города, ради того, чтобы купить один-единственный пакет молока на рубль дешевле, потратив при этом двадцать рублей на транспорт.
>обычно сервер выполняет конкретные фунции, на нем кроме ядра и баша установлена еще пара софтин и ВСЁ.
Конкретные функции - терминальный сервер X. У Вас все пользователи дружно логинятся по ssh и лабают документы в latex'е?
>где вы видели сервер на котором установлено 300 пакетов которые будут 2е суток компилироваться? развечто "сервер сегмента говносети" лол
Ну как раз фанатики таким и занимаются. Почему бы не настроить терминальный сервер X вместе со всеми KDE, OpenOffice и прочей лабудой на основе FreeBSD, собрав всё из портов? Чтобы на 6% быстрее работало? Как ни странно, такие люди есть.
>дык, ветка то о порядке прохождения пакетов в pf,
Не о порядке прохождения пакетов в pf, а о порядке прохождения пакетов через фаерволлы (ipf, ipfw и pf).
>никто вас сюда не звал со своим линухом
Собственно Вы и позвали фразой "в линухе фаервол не такой уж мощный". Продолжать беседу считаю бессмысленным, поскольку кроме очередного холивара, ожидать от Вас нечего.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

31. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD" +/–

Сообщение от redixin (?), 17-Апр-09, 16:00

>>в ipset нет tableargs, погуглите
>
>Погуглил. Отвечу Вашими словами:
>
>>лол зачем всё это?
>
я гдето выше говорил о шейперах
>Фраза в духе названных мной фряшников-фанатиков: "Во FreeBSD всё есть. А если
>чего и нет, то значит оно не нужно." Я думаю Вы
>уже поняли, что объяснять Вам, занимающему такую позицию, зачем всё это
>нужно, мне не особо хочется, да и не имеет смысла.
>
вообщето FreeBSD работает на ARM ;-)
>
>Затраты и выгода несоизмеримы. Слышал о домохозяйках, которые поедут в другую часть
>города, ради того, чтобы купить один-единственный пакет молока на рубль дешевле,
>потратив при этом двадцать рублей на транспорт.
>
пара минут на компиляцию это затраты? затраты это лишние
доли секунд на каждый проходящий пакет
>Конкретные функции - терминальный сервер X. У Вас все пользователи дружно логинятся
>по ssh и лабают документы в latex'е?
>
дык для X линух получше будет, это известно всем
(только причем тут фаерволы лол)
>Не о порядке прохождения пакетов в pf, а о порядке прохождения пакетов
>через фаерволлы (ipf, ipfw и pf).
вот именно лол
>>никто вас сюда не звал со своим линухом
>
>Собственно Вы и позвали фразой "в линухе фаервол не такой уж мощный".
эта фраза была ответом если вы не заметили =)
>Продолжать беседу считаю бессмысленным, поскольку кроме очередного холивара, ожидать от Вас
>нечего.
отлично, переходим на личности лол
я бы сказал что ничего кроме холивара не стоит ожидать от ветки про
пакетные фильтры в FreeBSD в которую втулился очередной красноглазый
линуксоид с криками про мощный линуксовый фаервол

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	19. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD"	+/–
	Сообщение от redixin (?), 24-Сен-08, 01:44
	в линухе фаервол не такой уж мощный - ему очень нехватает таблиц. с 1000 правил и 800 полос в шейпере на 10000 пакетов/сек становится на колени очень мощный писюк, в тоже время на фре с таблицами тоже самое просто летает, и не мудрено - таблицы это вам не цепочки правил
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	20. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD"	+/–
	Сообщение от www2 (??), 24-Сен-08, 07:54
	>в линухе фаервол не такой уж мощный - ему очень нехватает таблиц. Название iptables ни о чём не говорит? >с 1000 правил и 800 полос в шейпере на 10000 пакетов/сек >становится на колени очень мощный писюк, Нечего не зеркало пенять коли рожа (то есть руки) крива. Вы это флейма ради или Вы всё-таки представляете разницу между средствами управления трафиком во FreeBSD и Linux? >в тоже время на фре >с таблицами тоже самое просто летает, и не мудрено - таблицы >это вам не цепочки правил Очень глубокомысленный вывод. Ценю. "Таблицы" звучит круче чем "Цепочки".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD"	+/–
	Сообщение от redixin (?), 25-Сен-08, 16:15
	> Название iptables ни о чём не говорит? вот именно что название, название новое а внутри все теже ipchains =) Не знаете разницы между таблицами и цепочками? слышали про быстрый поиск с хеш-таблицами? нет? погуглите. Время поиска по цепочке правил линейно зависит от количества правил. Поиск же по хеш таблице практически не зависит от количества записей в таблице. Вот цитата с букваря по pf "a table is ideal for holding a large group of addresses as the lookup time on a table holding 50,000 addresses is only slightly more than for one holding 50 addresses" >Нечего не зеркало пенять коли рожа (то есть руки) крива. А как иначе разруливать ситуацию когда есть 600 адресов которые нужно дропнуть, и 400 адресов которые нужно натить, причем эти адреса постоянно добавляются/удаляются? в случае с pf мы добавляем 2 правила: block from <drops> to any nat from <nats> to any Начинку таблиц без проблем можно менять на лету. Время поиска по такой таблице очень и очень маленькое. В случае с линухом мы вынуждены держать 1000 правил, поиск по 1000 правил идет настолько долго что ksoftirqd вылазит вверх (это симптом, никогда такого не видели?) и машина просто не вылазит из прерываний. LA растер вверх а количество успешно прошедших пакетов - вниз. Есть патч для linux который добавляет такой функционал, но не очень хочется приключений связанных с глюками third level патча. > Очень глубокомысленный вывод. Ценю. "Таблицы" звучит круче чем "Цепочки". Не просто звучит, но и работает =) Простой линейный поиск гораздо медленеей поиска по self-ballancing binary tree (хотя я не уверен что в pf именно такое дерево, лень в исходники лезть)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	22. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD"	+/–
	Сообщение от www2 (??), 28-Сен-08, 10:43
	>Не знаете разницы между таблицами и цепочками? слышали про быстрый поиск с >хеш-таблицами? нет? погуглите. Погуглил, нашёл вот такой интересный тест: http://bulk.fefe.de/scalability/ Правда он к обсуждаемому вопросу не имеет отношения... >Время поиска по цепочке правил линейно зависит от количества правил. Поиск же >по хеш таблице практически не зависит от количества записей в таблице. >Вот цитата с букваря по pf "a table is ideal for >holding a large group of addresses as the lookup time on >a table holding 50,000 addresses is only slightly more than for >one holding 50 addresses" Аналогом таблиц pf в iptables является модуль ipset. Поиск же по спискам правил точно так же линеен. В Linux эмпирическим путём обнаружилась интересная особенность - кэширование совпадений для правил, правда не нашёл прямых упоминаний об этом от разработчиков netfilter. В цепочках iptables долго идёт только первый поиск. Если приходит пакет с такими же атрибутами, что и уже проверенный, для этого пакета правило определяется из кэша: http://www.protocols.ru/Papers/iptables-test.shtml >>Нечего не зеркало пенять коли рожа (то есть руки) крива. >А как иначе разруливать ситуацию когда есть 600 адресов которые нужно дропнуть, >и 400 адресов которые нужно натить, причем эти адреса постоянно добавляются/удаляются? >в случае с pf мы добавляем 2 правила: >block from <drops> to any >nat from <nats> to any В случае с iptables точно так же, почитайте man: http://ipset.netfilter.org/ipset.man.html >Начинку таблиц без проблем можно менять на лету. Время поиска по такой >таблице очень и очень маленькое. >В случае с линухом мы вынуждены держать 1000 правил, поиск по 1000 >правил идет настолько долго что ksoftirqd вылазит вверх (это симптом, никогда >такого не видели?) и машина просто не вылазит из прерываний. LA >растер вверх а количество успешно прошедших пакетов - вниз. Я же говорю - руки кривые. >Есть патч для linux который добавляет такой функционал, но не очень хочется >приключений связанных с глюками third level патча. Каждый сильно востребованный патч со временем попадёт в upstream. >> Очень глубокомысленный вывод. Ценю. "Таблицы" звучит круче чем "Цепочки". >Не просто звучит, но и работает =) Простой линейный поиск гораздо медленеей >поиска по self-ballancing binary tree (хотя я не уверен что в >pf именно такое дерево, лень в исходники лезть) Ну и iptables тоже не просто звучит, но и работает =)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD"	+/–
	Сообщение от redixin (?), 24-Окт-08, 13:34
	>Погуглил, нашёл вот такой интересный тест: >http://bulk.fefe.de/scalability/ >Правда он к обсуждаемому вопросу не имеет отношения... > говорит 404.. >Аналогом таблиц pf в iptables является модуль ipset. Поиск же по спискам >правил точно так же линеен. > ipset это и есть тот самый левый патч который страшно ставить в продакшн.. приключений както не хочется.. >В Linux эмпирическим путём обнаружилась интересная особенность - кэширование совпадений для правил, >правда не нашёл прямых упоминаний об этом от разработчиков netfilter. В >цепочках iptables долго идёт только первый поиск. Если приходит пакет с >такими же атрибутами, что и уже проверенный, для этого пакета правило >определяется из кэша: http://www.protocols.ru/Papers/iptables-test.shtml "В завершении я хочу привести результаты теста на реально используемом шлюзе с достаточно высоким уровнем трафика (на момент тестирования исходящий трафик составлял около 2 Мбит/с)." ой я вас умоляю не смешите мне тапочки этими двумя мегабитами. кеширование это костыли которые дают прирост только в синтетике >В случае с iptables точно так же, почитайте man: >http://ipset.netfilter.org/ipset.man.html > все тот же стремный левый патч >>Начинку таблиц без проблем можно менять на лету. Время поиска по такой >>таблице очень и очень маленькое. >>В случае с линухом мы вынуждены держать 1000 правил, поиск по 1000 >>правил идет настолько долго что ksoftirqd вылазит вверх (это симптом, никогда >>такого не видели?) и машина просто не вылазит из прерываний. LA >>растер вверх а количество успешно прошедших пакетов - вниз. > >Я же говорю - руки кривые. > удивительный коментарий, и чего я вам доказываю? >>Есть патч для linux который добавляет такой функционал, но не очень хочется >>приключений связанных с глюками third level патча. > >Каждый сильно востребованный патч со временем попадёт в upstream. > этот востребованный патч уже давно есть в *BSD, а в линухе от него кернел паники бывают >>> Очень глубокомысленный вывод. Ценю. "Таблицы" звучит круче чем "Цепочки". >>Не просто звучит, но и работает =) Простой линейный поиск гораздо медленеей >>поиска по self-ballancing binary tree (хотя я не уверен что в >>pf именно такое дерево, лень в исходники лезть) > >Ну и iptables тоже не просто звучит, но и работает =) ага, работает и ядро до полусмерти зашугивает... подождем когда его вылижут, а пока его даже на тестовую железку ставить страшно
	Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD"	+/–
	Сообщение от www2 (??), 24-Окт-08, 15:09
	Это уже давно не патч, модуль 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 все обновлять можно было.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD"	+/–
	Сообщение от redixin (?), 16-Апр-09, 23:33
	>Это уже давно не патч, модуль ipset у меня наличествует в дистрибутиве >Debian Etch (stable), который часто BSD-шники обвиняют в том, что он >устаревает на момент выпуска. Заметьте - это самый консервативный дистрибутив, и >даже в нём этот модуль есть! > http://w3dev.org.ua/debian-guaranteed-entropy.jpg ок >Прежде чем повторять одну и ту же мантру "ipset не для продакшн" >или "костыли в виде патчей", стоит ознакомиться с вопросом. кто повторял? я разок сказал, а вы тут про дебиан 3 абзаца мантр =) дело даже не в том что ipset это костыль который стремаются добавлять в основную ветку, а в том что iptables даже вместе с ipset уступают и ipfw и pf. > >А вот в *BSD до сих пор несколько PPTP-сессий нельзя установить из-за >NAT'а, несмотря на все их три фаерволла. И в stateful режиме >фаерволлов не отслеживаются сессии данных активных FTP-клиентов, благодаря чему приходится настраивать >ещё и NAT там, где он не нужен. насчет pptp не тестил, но FTP работает отменно, враки это всё >А уж насчёт стабильности BSD так лучше бы вообще помолчали, там разработчики >отвечают только за базовую систему, а дырки в программах из портов >их не волнуют. Метод закрытия дырок тоже занятный - берут более >свежую версию программы, в которой дыра уже закрыта. В Debian берут >ту же версию и закрывают дырку в ней, благодаря чему обновления >безопасности происходят совершенно безболезненно, даже в автоматическом режиме без участия сисадмина. ну вы поняли лол http://w3dev.org.ua/debian-guaranteed-entropy.jpg >Во FreeBSD порт может не скомпилироваться, во время компиляции будет создаваться >дополнительная нагрузка на сервер, после установки какое-нибудь мелкое изменение в формате >конфига при переходе с одной версии на другую может привести к >тому, что обновлённый демон не запустится. Поэтому при обновлении FreeBSD сисадмин >должен быть рядом с сервером. А если их двадцать, тридцать и >на каждом разные задачи? А если сисадмин уехал в отпуск на >месяц, можно ли без участия обновить системы? Нельзя? :-( Что теперь >- системы не патчить или обновлять автоматом и молиться, что ни >одно обновление не приведёт к неработоспособности сервака? > чего это вдрук оно приведет к неработоспособности? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/up... ок >На йух BSD, им место на маршрутизаторах, только в виде базовой системы, >и лучше без портов. И это должны быть единичные маршрутизаторы или >абсолютно идентичные, чтоб по rsync все обновлять можно было. обновлять, строить кластеры, идентичные, не идентичные, можно всё это не проблема. но и речь не об этом откуда такая ненависть к BSD?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD"	+/–
	Сообщение от www2 (??), 17-Апр-09, 08:12
	>дело даже не в том что ipset это костыль который стремаются >добавлять в основную ветку, а в том что iptables даже вместе с >ipset уступают и ipfw и pf. Уступает в чём? >>А вот в *BSD до сих пор несколько PPTP-сессий нельзя установить из-за >>NAT'а, несмотря на все их три фаерволла. И в stateful режиме >>фаерволлов не отслеживаются сессии данных активных FTP-клиентов, благодаря чему приходится настраивать >>ещё и NAT там, где он не нужен. > >насчет pptp не тестил, но FTP работает отменно, враки это всё Пассивные соединения работают отменно (это когда клиент сам устанавливает два соединения с FTP-сервером), а активные нет (когда клиент устанавливает управляющее соединение, а сервер подключается к клиенту для передачи данных). >чего это вдрук оно приведет к неработоспособности? > >http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/up... >ок Посмотрел. Это читать при каждом обновлении каждого сервера? То есть появилась дырка, нужно обновить 50 серваков. Я буду шаманить с бубном перед каждым серваком? Да я пока закончу, новые дырки появятся. Особенно хорош вот этот ЛОЛ: ># portupgrade -af На каждом сервере. >откуда такая ненависть к BSD? Как таковой ненависти к BSD нет. Я постоянно использую FreeBSD. Особенно мне нравится VPN-сервер mpd. Мне нравится маленький размер NetBSD. Мне нравится концепция ядра DragonFly BSD. В BSD мне не нравятся: 1. неудобство пакетной системы (каждый раз пытаясь обновить или установить программу в FreeBSD вспоминаю насколько легко и быстро я то же самое сделал бы в Debian), 2. неразвитость ядра (те небольшие, на первый взгляд, недостатки иногда могут становиться принципиальными недостатками. Например, те же несколько PPTP-соединений через NAT были для меня просто до жути необходимы, причём срочно. Мне пришлось испытать ОЧЕНЬ сильную головную боль из-за этого), 3. фанатики с одним-двумя серверам, блещущие знаниями хэндбука, которые говорят МНЕ, что недостатков, которые Я прочувствовал на СВОЕЙ шкуре, нет. Это, знаете ли, несколько оскорбляет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	27. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD"	+/–
	Сообщение от redixin (?), 17-Апр-09, 10:52
	>>дело даже не в том что ipset это костыль который стремаются >>добавлять в основную ветку, а в том что iptables даже вместе с >>ipset уступают и ipfw и pf. > >Уступает в чём? > в ipfw есть tablearg (очень очень приятная вещь) в ipfw есть простые шустрые шейпера (pipes)(в линухе чтобы получить такой функционал приходится юзать костыль imq который кроме всего прочего дико тормозит) это то изза чего я кое-где пересел на FreeBSD, не удивлюсь если есть еще >># portupgrade -af > >На каждом сервере. > а дебиан чудесным образом сам запустит все на всех серверах? лол > >В BSD мне не нравятся: >1. неудобство пакетной системы (каждый раз пытаясь обновить или установить программу в >FreeBSD вспоминаю насколько легко и быстро я то же самое сделал >бы в Debian) да ну прям таки сделать cd ..... && make install прямо таки головная боль >2. неразвитость ядра (те небольшие, на первый взгляд, недостатки иногда могут становиться >принципиальными недостатками. неразвитость ядра???77 там три пакетных фильтра, и на SMP оно уделывает всех. это неразвитость? чего вам там нехватает? jfs? лол >Например, те же несколько PPTP-соединений через NAT были для >меня просто до жути необходимы, причём срочно. > Мне пришлось испытать ОЧЕНЬ >сильную головную боль из-за этого) так вот откуда ненависть =) >3. фанатики с одним-двумя серверам, блещущие знаниями хэндбука лол кто ето? > которые говорят МНЕ, что недостатков, которые Я прочувствовал на > СВОЕЙ шкуре, нет. Это, знаете ли, несколько оскорбляет. недостатки есть, но позвольте напомнить что речь идет о пакетных фильтрах в FreeBSD и Linux, а не о крутости менеджера пакетов в Debian/GNU
	Ответить \| Правка \| Наверх \| Cообщить модератору


	28. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD"	+/–
	Сообщение от www2 (??), 17-Апр-09, 14:32
	>>>дело даже не в том что ipset это костыль который стремаются >>>добавлять в основную ветку, а в том что iptables даже вместе с >>>ipset уступают и ipfw и pf. >> >>Уступает в чём? >> > >в ipfw есть tablearg (очень очень приятная вещь) ipset >в ipfw есть простые шустрые шейпера (pipes)(в линухе >чтобы получить такой функционал приходится юзать костыль imq >который кроме всего прочего дико тормозит) Про imq первый раз слышу. Не пробовали tc? Не костыль, а штатная очень гибкая система приоритезации, формирования и ограничения трафика. >это то изза чего я кое-где пересел на FreeBSD, не удивлюсь если >есть еще Ответы выше. >>># portupgrade -af >> >>На каждом сервере. >> > >а дебиан чудесным образом сам запустит все на всех серверах? лол Нет. Он просто не будет компилировать. А ещё он (если это стабильная ветка) не будет чинить то, что не сломалось - обновит только дырявые пакеты их патчеными версиями. >>В BSD мне не нравятся: >>1. неудобство пакетной системы (каждый раз пытаясь обновить или установить программу в >>FreeBSD вспоминаю насколько легко и быстро я то же самое сделал >>бы в Debian) > >да ну прям таки сделать cd ..... && make install прямо таки >головная боль Читаем http://www.lissyara.su/?id=1153 Видим: >Ага. libtool в двух экземплярах... Либо чё-то глюкануло, либо так и задумано, ввиду того >что не все приложения переваривают новые версии зависмостей, а хотят чё-то старое. >Попробуем пофиксить БД: >/usr/home/lissyara/>pkgdb -F >Прервал - куча ошибок из-за одного отсутствующего порта. Значит пойдём правильным путём, >- доставим зависисмось, которую он хочет: >/usr/home/lissyara/>cd /usr/ports/misc/ldconfig_compat Вот мои главные претензии. В 60% случаев невозможно собрать что-нибудь, не споткнувшись на каком-нибудь глюке парочку-другую раз. И ещё мне не нравится, что я не могу собрать по команде make package определённый пакет, если в системе уже установлен другой пакет или пакеты других версий, от которых зависит собираемый пакет. То есть практически всегда такая ситуация: здесь играем, здесь не играем, здесь пятно от рыбы... Ну некогда мне заниматься обходом граблей и сооружением костылей, лучше я возьму предсказуемую систему. >>2. неразвитость ядра (те небольшие, на первый взгляд, недостатки иногда могут становиться >>принципиальными недостатками. > >неразвитость ядра???77 там три пакетных фильтра, и на SMP оно уделывает всех. Три пакетных фильтра - это да, это серьёзно. Можно зафильтроваться по самое нихочу. Лучше брать качеством, а не количеством. Кого SMP уделывает, простите? Может Solaris? В Linux поддержка SMP появилась гораздо раньше. Вот у Мэта Диллона свой взгляд на SMP и уделыванием он занимается довольно серьёзно. В NetBSD SMP Эндрю Доран занимается хоть и поздно, зато планомерно и качественно: http://www.netbsd.org/~ad/smp/tasks.html В общем, пустой трёп. >это неразвитость? чего вам там нехватает? jfs? лол Аналога OpenVZ, UML, Xen dom0 (хотя уже утрачивает актуальность), ядра на ARM-процессорах. В том числе, да, и XFS и ReiserFS в режиме записи. Не хватает аналога LVM. Нет аналога LTSP для FreeBSD, хотя безусловно, всё то же самое можно сделать и самому. >>Например, те же несколько PPTP-соединений через NAT были для >>меня просто до жути необходимы, причём срочно. >> Мне пришлось испытать ОЧЕНЬ >>сильную головную боль из-за этого) > >так вот откуда ненависть =) Ещё раз говорю, ненависти нет. Просто я научился грамотнее тратить своё время. >>3. фанатики с одним-двумя серверам, блещущие знаниями хэндбука > >лол кто ето? Ну, может быть к этой категории относитесь и Вы. Есть ещё Lissyara, Федорчук, iZen. Ещё мне нравится коронная фраза приверженцев FreeBSD и Gentoo "Ну, компьютеры сейчас мощные.", когда я говорю о том, что компиляция портов или портежей отнимает ресурсы системы и занимает немалое время. >> которые говорят МНЕ, что недостатков, которые Я прочувствовал на >> СВОЕЙ шкуре, нет. Это, знаете ли, несколько оскорбляет. >недостатки есть, но позвольте напомнить что речь идет о пакетных фильтрах >в FreeBSD и Linux, а не о крутости менеджера пакетов в Debian/GNU Грамотно брошенная в это раздел форума фраза "с которым граблей" была не моя. До этой фразы я был BSD'шником. Когда ответил на неё, уже хорошо познакомился с Debian и понял сколько времени и нервов я потерял (во многом) зря, отстаивая преимущества FreeBSD. Вы тоже начали ещё одну ветку, забросив фразу "в линухе фаервол не такой уж мощный".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD"	+/–
	Сообщение от redixin (?), 17-Апр-09, 15:14
	>> >>в ipfw есть tablearg (очень очень приятная вещь) > >ipset > в ipset нет tableargs, погуглите >>в ipfw есть простые шустрые шейпера (pipes)(в линухе >>чтобы получить такой функционал приходится юзать костыль imq >>который кроме всего прочего дико тормозит) > >Про imq первый раз слышу. Не пробовали tc? Не костыль, а штатная >очень гибкая система приоритезации, формирования и ограничения трафика. > tc привязывается к интерфейсу, а если у меня куча интерфейсов и трафик по ним гуляет? приходится юзать IMQ, это виртуальный интерфейс сделан специально для таких и подобных целей. tc+imq жутко тормозит. на том же железе ipfw2 + tableargs + pipes удалось выжать почти в десять раз больше (100килопакетов на фре против 12 на линухе) >Ответы выше. ок >[оверквотинг удален] >Вот мои главные претензии. В 60% случаев невозможно собрать что-нибудь, не споткнувшись >на каком-нибудь глюке парочку-другую раз. > >И ещё мне не нравится, что я не могу собрать по команде >make package определённый пакет, если в системе уже установлен другой пакет >или пакеты других версий, от которых зависит собираемый пакет. То есть >практически всегда такая ситуация: здесь играем, здесь не играем, здесь пятно >от рыбы... Ну некогда мне заниматься обходом граблей и сооружением костылей, >лучше я возьму предсказуемую систему. > это все ок, но ведь речь о пакетных фильтрах лол >Три пакетных фильтра - это да, это серьёзно. Можно зафильтроваться по самое >нихочу. Лучше брать качеством, а не количеством. > iptables качеством уделывает только Outpost лол >Кого SMP уделывает, простите? Может Solaris? В Linux поддержка SMP появилась гораздо >раньше. наличие поддержки и ее качество -- вещи разные, есть много бенчмарков где видно насколько все плохо с SMP в Linux >Аналога OpenVZ, UML, Xen dom0 (хотя уже утрачивает актуальность), ядра на ARM-процессорах. >В том числе, да, и XFS и ReiserFS в режиме записи. >Не хватает аналога LVM. Нет аналога LTSP для FreeBSD, хотя безусловно, >всё то же самое можно сделать и самому. > лол зачем всё это? во фре уже теперь есть zfs (хотя говаривают что в линухе недавно появилась поддержка btrfs ок) ядра на ARM процессорах? это чтобы ОСь можно было на пылесосе запустить? но зачем? >Ну, может быть к этой категории относитесь и Вы. Есть ещё Lissyara, >Федорчук, iZen. Ещё мне нравится коронная фраза приверженцев FreeBSD и Gentoo >"Ну, компьютеры сейчас мощные.", когда я говорю о том, что компиляция >портов или портежей отнимает ресурсы системы и занимает немалое время. она занимает немалое время если собирать KDE4, но вы ведь на серверах не пользуетесь кедами? =) собрать nginx, питон да postgres -- пара минут делов, зато оптимизации, все дела.. как известно у гентушников даже скорость света на 6% выше =)) где вы видели сервер на котором установлено 300 пакетов которые будут 2е суток компилироваться? развечто "сервер сегмента говносети" лол обычно сервер выполняет конкретные фунции, на нем кроме ядра и баша установлена еще пара софтин и ВСЁ. >Грамотно брошенная в это раздел форума фраза "с которым граблей" была не >моя. До этой фразы я был BSD'шником. Когда ответил на неё, >уже хорошо познакомился с Debian и понял сколько времени и нервов >я потерял (во многом) зря, отстаивая преимущества FreeBSD. Вы тоже начали >ещё одну ветку, забросив фразу "в линухе фаервол не такой уж >мощный". дык, ветка то о порядке прохождения пакетов в pf, никто вас сюда не звал со своим линухом
	Ответить \| Правка \| Наверх \| Cообщить модератору


	30. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD"	+/–
	Сообщение от www2 (??), 17-Апр-09, 15:52
	>в ipset нет tableargs, погуглите Погуглил. Отвечу Вашими словами: >лол зачем всё это? Фраза в духе названных мной фряшников-фанатиков: "Во FreeBSD всё есть. А если чего и нет, то значит оно не нужно." Я думаю Вы уже поняли, что объяснять Вам, занимающему такую позицию, зачем всё это нужно, мне не особо хочется, да и не имеет смысла. >собрать nginx, питон да postgres -- пара минут делов, зато оптимизации, все дела.. как известно у гентушников даже скорость света на 6% выше =)) Затраты и выгода несоизмеримы. Слышал о домохозяйках, которые поедут в другую часть города, ради того, чтобы купить один-единственный пакет молока на рубль дешевле, потратив при этом двадцать рублей на транспорт. >обычно сервер выполняет конкретные фунции, на нем кроме ядра и баша установлена еще пара софтин и ВСЁ. Конкретные функции - терминальный сервер X. У Вас все пользователи дружно логинятся по ssh и лабают документы в latex'е? >где вы видели сервер на котором установлено 300 пакетов которые будут 2е суток компилироваться? развечто "сервер сегмента говносети" лол Ну как раз фанатики таким и занимаются. Почему бы не настроить терминальный сервер X вместе со всеми KDE, OpenOffice и прочей лабудой на основе FreeBSD, собрав всё из портов? Чтобы на 6% быстрее работало? Как ни странно, такие люди есть. >дык, ветка то о порядке прохождения пакетов в pf, Не о порядке прохождения пакетов в pf, а о порядке прохождения пакетов через фаерволлы (ipf, ipfw и pf). >никто вас сюда не звал со своим линухом Собственно Вы и позвали фразой "в линухе фаервол не такой уж мощный". Продолжать беседу считаю бессмысленным, поскольку кроме очередного холивара, ожидать от Вас нечего.
	Ответить \| Правка \| К родителю #29 \| Наверх \| Cообщить модератору


	31. "Порядок прохождения пакетов в пакетных фильтрах FreeBSD"	+/–
	Сообщение от redixin (?), 17-Апр-09, 16:00
	>>в ipset нет tableargs, погуглите > >Погуглил. Отвечу Вашими словами: > >>лол зачем всё это? > я гдето выше говорил о шейперах >Фраза в духе названных мной фряшников-фанатиков: "Во FreeBSD всё есть. А если >чего и нет, то значит оно не нужно." Я думаю Вы >уже поняли, что объяснять Вам, занимающему такую позицию, зачем всё это >нужно, мне не особо хочется, да и не имеет смысла. > вообщето FreeBSD работает на ARM ;-) > >Затраты и выгода несоизмеримы. Слышал о домохозяйках, которые поедут в другую часть >города, ради того, чтобы купить один-единственный пакет молока на рубль дешевле, >потратив при этом двадцать рублей на транспорт. > пара минут на компиляцию это затраты? затраты это лишние доли секунд на каждый проходящий пакет >Конкретные функции - терминальный сервер X. У Вас все пользователи дружно логинятся >по ssh и лабают документы в latex'е? > дык для X линух получше будет, это известно всем (только причем тут фаерволы лол) >Не о порядке прохождения пакетов в pf, а о порядке прохождения пакетов >через фаерволлы (ipf, ipfw и pf). вот именно лол >>никто вас сюда не звал со своим линухом > >Собственно Вы и позвали фразой "в линухе фаервол не такой уж мощный". эта фраза была ответом если вы не заметили =) >Продолжать беседу считаю бессмысленным, поскольку кроме очередного холивара, ожидать от Вас >нечего. отлично, переходим на личности лол я бы сказал что ничего кроме холивара не стоит ожидать от ветки про пакетные фильтры в FreeBSD в которую втулился очередной красноглазый линуксоид с криками про мощный линуксовый фаервол
	Ответить \| Правка \| К родителю #30 \| Наверх \| Cообщить модератору