форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"OpenNews: Новая версия пакетного фильтра для Linux - iptable..."

Сообщение от opennews (??) on 26-Дек-07, 14:19

Вышел (http://netfilter.org/news.html#2007-12-22) iptables 1.4.0 (http://netfilter.org/projects/iptables/downloads.html#iptabl...), спустя почти 3 года с момента выхода первого релиза ветки 1.3.x. В iptables 1.4 проведена существенная работа по улучшению поддержки IPv6,  исправлено большое число ошибок. Кроме того, можно отметить появление базовой реализация инфраструктуры xtables, возможность восстановления состояний отдельных таблиц в iptables-restore (ключ -table), проведение работы по оптимизации производительности операций сортировки цепочек. URL: http://marc.info/?l=netfilter&m=119833164027492&w=2 Новость: http://www.opennet.dev/opennews/art.shtml?num=13448

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

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

4. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"

Сообщение от valfrom on 26-Дек-07, 14:30

ключ -table в iptables-restore недавно нужен был, ток подумал и тут новость :)

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

6. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"

Сообщение от V (??) on 26-Дек-07, 14:48

есть слова.. с pf не сравнится..

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

	9. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 26-Дек-07, 15:21
	> На мини-роутерах (aka домашний D-link) таки рулит бсд, или, линь? Embedded-системы -- вообще беседа отдельная. Строго говоря, для них и BSD, и Linux одинаково плохи. Дело в том, что и Linux, и *BSD разрабатывались для машин с MMU. Нет, безусловно, и Linux, и BSD _в теории_ могут работать и без MMU (ну, не будет вам fork()'a, перебьётесь парой vfork()/exec(), никуда не денетесь). Но делают они это крайне хреново: надо algorithmic base менять. И в ядре, и в User Land'е. Linux, как роутер, безусловно плох. Впрочем, *BSD ненамного лучше. Лучше. Но ненамного. Скажем так, если десять лет назад, увидев роутер на Линуксе, имело смысл немедленно оный Линукс снести, и поставить *BSD, то теперь это неактуально: да, будет чуть лучше, но овчинка выделки не стоит. IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables. Слишком много точек входа в ядро, код перегружен и глючит. Да, PF умеет фильтровать только IP-пакеты. Про Ethernet он ничего не знает, по MAC-адресу им не зафильтруешь. Ну и пёс с ним. Зато у PF есть таблицы. _Нормальные_ таблицы, обновляемые из User Land на лету, и поиск по которым осуществляется по RADIX Tree, а не по линейному списку. PF умеет якоря (anchors), и несколько программ, модифицирующих правила пакетного фильтра, _никогда_ не подерутся. Но пакетный фильтр -- это не то, за что идёт борьба на роутере. На роутере идёт борьба за пакетную производительность. А она достигается использованием либо ASIC'ов, либо NPU. Period.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от fresco (??) on 26-Дек-07, 15:29
	Спасибо, нормально объяснили. По-больше б таких камментов на ОпенНете
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от sHaggY_caT (??) on 26-Дек-07, 15:43
	да, спасибо... Интересно, почему под Линь только iptables? А под бсд столько много фильтров? Кстати, у Солярки есть API для пакетных фильтров?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 26-Дек-07, 16:08
	> да, спасибо... > Интересно, почему под Линь только iptables?     Это неправда. Есть порт IP Filter под Linux. > А под бсд столько много фильтров?     Потому, что они изначально не договорились, но обмениваются кодом.     Изначально был IP Firewall под BSDi. По его образу и подобию был сделан ipfw для FreeBSD. А для NetBSD Darren Reed (кстати, соавтор RFC на IRC :) написал IP Filter.     Потом IP Filter был спортирован под FreeBSD и OpenBSD. Потом Reed поменял лицензию, и Тео де Раадт, который, как обычно, хотел быть святее Папы Римского, вынес IP Filter из дерева исходников. А другой человек написал взамен PF. > Кстати, у Солярки есть API для пакетных фильтров?     Нет. Но есть порт IP Filter для Solaris.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Ананимуз on 26-Дек-07, 16:54
	> да, спасибо... > Интересно, почему под Линь только iptables? > Это неправда. Есть порт IP Filter под Linux. Это тот, который IP filter -> IP chains -> IP tables?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 26-Дек-07, 17:10
	Благородный дон не понимает разницы между IP Filter и ipfwadm?-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Ананимуз on 26-Дек-07, 22:52
	Ааа... Это про тот IPFilter, который ipf и пишется слитно?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	33. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 01:30
	> Ааа... Это про тот IPFilter, который ipf и пишется слитно? Благородный дон не потрудится ли посетить http://coombs.anu.edu.au/~avalon/ и убедиться, что "IP Filter" пишется раздельно? Прям первая строчка на странице...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от demimurych on 26-Дек-07, 15:45
	>> На мини-роутерах (aka домашний D-link) таки рулит бсд, или, линь? > >Embedded-системы -- вообще беседа отдельная. Строго говоря, для них и BSD, и >Linux одинаково плохи. >Дело в том, что и Linux, и *BSD разрабатывались для машин с >MMU. Нет, безусловно, и Linux, и BSD _в теории_ могут работать Не совсем понял какое отношение это имеет к вопросу о >> На мини-роутерах (aka домашний D-link) таки рулит бсд, или, линь? мне показалось что вы говорили о задачах где решаются вопросы с сколько нибудь значимым трафиком а не в условиях "доманего" использования. Поправьте меня где я ошибся.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 26-Дек-07, 16:11
	> Не совсем понял какое отношение это имеет к вопросу о >>> На мини-роутерах (aka домашний D-link) таки рулит бсд, или, линь? > мне показалось что вы говорили о задачах где решаются вопросы с сколько > нибудь значимым трафиком а не в условиях "доманего" использования. Поправьте меня > где я ошибся.     Дело в том, что на домашних роутерах стоит одна задача -- удешевления. И поэтому там ставят настолько слабое железо, насколько это вообще возможно. И при таком раскладе вопрос, так сказать, "профпригодности" данной конкретной операционки выходит на первый план.     Ситуация примерно такая же, как и со смартфонами -- там ставят настолько слабый микропроцессор, насколько это вообще возможно, иначе не добиться сколь-нибудь разумного мобильного ресурса.     Никто не хочет заряжать батарею мобилки раз в 8-10 часов.     Никто не хочет платить за домашний роутер $300. Даже $300. Не говоря уже о большей сумме.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 26-Дек-07, 16:27
	>Embedded-системы -- вообще беседа отдельная. Строго говоря, для них и BSD, и >Linux одинаково плохи. >Дело в том, что и Linux, и *BSD разрабатывались для машин с >MMU. Нет, безусловно, и Linux, и BSD _в теории_ могут работать >и без MMU (ну, не будет вам fork()'a, перебьётесь парой vfork()/exec(), >никуда не денетесь). Но делают они это крайне хреново: надо algorithmic >base менять. И в ядре, и в User Land'е. Сейчас железки без MMU - скорее экзотика. >Linux, как роутер, безусловно плох. Впрочем, *BSD ненамного лучше. Лучше. Но ненамного. Если лучше, то почему куда ни плюнь в классе adsl роутеров/модемов & AP - попадёшь в linux? >IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables. >Слишком много точек входа в ядро, код перегружен и глючит. Самый ужас - это conntrack. Сам netfilter умеет скалиться на SMP, чего не умеет PF. Да, сейчас и одноядерные процессоры весьма быстры, но когда у вас 4 гигабитных сетевухи и 2 ядра... хм, пакетный фильтр, болтающийся на одном cpu в случае DoS ничем не поможет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 26-Дек-07, 16:49
	> Сейчас железки без MMU - скорее экзотика.     Да ладно уж, экзотика. Xscale далеко не везде. >> Linux, как роутер, безусловно плох. Впрочем, *BSD ненамного лучше. Лучше. Но ненамного. > Если лучше, то почему куда ни плюнь в классе adsl роутеров/модемов & > AP - попадёшь в linux?     Я обычно в VXWorks и его дериваты попадаю. Не туда плюю?-) >> IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables. >> Слишком много точек входа в ядро, код перегружен и глючит. > Самый ужас - это conntrack. Сам netfilter умеет скалиться на SMP, чего > не умеет PF.     PF _отлично_ скалируется на SMP. Настолько отлично, насколько отлично на SMP скалируется TCP/IP-стек вообще. С этим, правда, проблемы почти везде. :( Но во FreeBSD уже давно есть netisr, где всё хорошо. Пока речь не идёт о fragmentation/reassembly. :) >Да, сейчас и одноядерные процессоры весьма быстры, но когда у вас 4 >гигабитных сетевухи и 2 ядра... хм, пакетный фильтр, болтающийся на одном >cpu в случае DoS ничем не поможет.     Пакетный фильтр в случае DoS не поможет, будь он хоть сто раз скалируемый. :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 26-Дек-07, 17:29
	>    Пакетный фильтр в случае DoS не поможет, будь >он хоть сто раз скалируемый. :) ну 100kpps вполне реально получить на половине fast ethernet.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 26-Дек-07, 21:53
	>>    Пакетный фильтр в случае DoS не поможет, будь >>он хоть сто раз скалируемый. :) > >ну 100kpps вполне реально получить на половине fast ethernet. Так сейчас так, втупую, никто не DoS'ит: микропроцессоры стали достаточно быстрыми для того, чтобы не заметить какие-то там 100 kpps. Хуже, когда DoS'ят целенаправленно сервис.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	48. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 27-Дек-07, 10:20
	>Так сейчас так, втупую, никто не DoS'ит: микропроцессоры стали достаточно быстрыми для >того, чтобы не заметить какие-то там 100 kpps. Хуже, когда DoS'ят >целенаправленно сервис. ага, но остались ОС, в которых нет polling и которым от относительно небольших значений kpps становится плохо ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	60. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 17:46
	> ага, но остались ОС, в которых нет polling и которым от относительно > небольших значений kpps становится плохо ;) Ну, в эпоху PCI Express (и даже PCI с Message-signalled Interrupts) это уже малоактуально. Да и сама идея MSI значительно более, так сказать, "пряма", нежели поллинг.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	115. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от nuclight on 30-Дек-07, 22:18
	>>> IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables. >>> Слишком много точек входа в ядро, код перегружен и глючит. >> Самый ужас - это conntrack. Сам netfilter умеет скалиться на SMP, чего >> не умеет PF. > >    PF _отлично_ скалируется на SMP. Настолько отлично, насколько >отлично на SMP скалируется TCP/IP-стек вообще. С этим, правда, проблемы почти >везде. :( Но во FreeBSD уже давно есть netisr, где всё >хорошо. Пока речь не идёт о fragmentation/reassembly. :) Ой. Шо, таки уже убрали один глобальный лок на весь PF ? Пока что на тестах файрволовна6-ке ipfw опережал в скорости pf, в среднем раза в полтора.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	123. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от routerSMP on 17-Янв-08, 20:38
	>[оверквотинг удален] >AP - попадёшь в linux? > >>IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables. >>Слишком много точек входа в ядро, код перегружен и глючит. > >Самый ужас - это conntrack. Сам netfilter умеет скалиться на SMP, чего >не умеет PF. >Да, сейчас и одноядерные процессоры весьма быстры, но когда у вас 4 >гигабитных сетевухи и 2 ядра... хм, пакетный фильтр, болтающийся на одном >cpu в случае DoS ничем не поможет. Насчет SMP можно медленнее и подробнее ?  Ксеоны 3.4 однако : router:/# LANG=C mpstat -P ALL 10 3 Linux 2.6.23.14 (router)  01/17/08 19:20:49     CPU   %user   %nice %system %iowait    %irq   %soft   %idle    intr/s 19:20:59     all    0.02    0.74    0.12    0.17    0.05   24.67   74.22    321.10 19:20:59       0    0.00    0.00    0.00    0.00    0.20   99.80    0.00    321.10 19:20:59       1    0.00    0.80    0.20    0.10    0.00    0.10  101.10      0.00 19:20:59       2    0.10    1.30    0.20    0.40    0.00    0.00   98.10      0.00 19:20:59       3    0.00    1.00    0.20    0.10    0.00    0.00  101.00      0.00 19:20:59     CPU   %user   %nice %system %iowait    %irq   %soft   %idle    intr/s 19:21:09     all    0.02    1.25    0.37    0.05    0.05   24.64   73.62    361.90 19:21:09       0    0.00    0.00    0.00    0.00    0.20   99.80    0.00    361.90 19:21:09       1    0.00    2.00    0.30    0.10    0.00    0.00  103.40      0.00 19:21:09       2    0.00    1.30    0.80    0.10    0.00    0.20   97.60      0.00 19:21:09       3    0.10    1.70    0.40    0.00    0.00    0.10   98.50      0.00 19:21:09     CPU   %user   %nice %system %iowait    %irq   %soft   %idle    intr/s 19:21:19     all    0.02    0.90    0.17    0.15    0.02   24.41   74.32    385.50 19:21:19       0    0.00    0.00    0.00    0.00    0.10   99.90    0.00    385.50 19:21:19       1    0.00    2.00    0.20    0.40    0.00    0.00  104.60      0.00 19:21:19       2    0.00    1.10    0.20    0.20    0.00    0.00   98.50      0.00 19:21:19       3    0.10    0.60    0.20    0.00    0.00    0.10  101.00      0.00 Average:     CPU   %user   %nice %system %iowait    %irq   %soft   %idle    intr/s Average:     all    0.02    0.97    0.22    0.12    0.04   24.57   74.05    356.17 Average:       0    0.00    0.00    0.00    0.00    0.17   99.83    0.00    356.17 Average:       1    0.00    1.60    0.23    0.20    0.00    0.03  103.03      0.00 Average:       2    0.03    1.23    0.40    0.23    0.00    0.07   98.07      0.00 Average:       3    0.07    1.10    0.27    0.03    0.00    0.07  100.17      0.00
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Sampan on 26-Дек-07, 21:43
	>Linux, как роутер, безусловно плох. Впрочем, *BSD ненамного лучше. Лучше. Но ненамного. >Скажем так, если десять лет назад, увидев роутер на Линуксе, имело >смысл немедленно оный Линукс снести, и поставить *BSD..... Прочитал сие и сразу средце екнуло: неужели к нам сам Rusty Russell заглянул, либо, на худой конец, Алексей Кузнецов. Ан нет! Andrew Kolchoogin вынес свой окончательный вердикт и расставил все точки. Финал. Занавес. Аплодисменты. Мое мнение. По функционалу BSD с PF отдыхает против связки iptables+iproute2 (в умелых руках, конечно). Всякие кивки про лучшую производительность BSD на 4 гигабитных сетевухах - бред. Нормальные провайдеры (и крупные сети) на нагруженных каналах используют магистральные маршрутизаторы. И только в России остаются уроды, ставящие на шлюзы транспортной сети BSDовые рутеры. Одного такого знаю - Ринет. Как же их колбасит при суммарном транзитном трафике 500 - 800 Гб в месяц! Я недавно от этого кошмара отключился - не нарадуюсь. (Да и Ринету на 100 Гб в месяц легче стало :-))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	22. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 26-Дек-07, 21:48
	>[оверквотинг удален] >>Скажем так, если десять лет назад, увидев роутер на Линуксе, имело >>смысл немедленно оный Линукс снести, и поставить *BSD..... > >Прочитал сие и сразу средце екнуло: неужели к нам сам Rusty Russell >заглянул, либо, на худой конец, Алексей Кузнецов. Ан нет! Andrew Kolchoogin >вынес свой окончательный вердикт и расставил все точки. Финал. Занавес. Аплодисменты. > > >Мое мнение. По функционалу BSD с PF отдыхает против связки iptables+iproute2 (в >умелых руках, конечно).     Аналог scrub и modulate state у iptables в студию. > Всякие кивки про лучшую производительность BSD на 4 >гигабитных сетевухах - бред. Нормальные провайдеры (и крупные сети) на нагруженных >каналах используют магистральные маршрутизаторы. И только в России остаются уроды, ставящие >на шлюзы транспортной сети BSDовые рутеры. Одного такого знаю - Ринет. >Как же их колбасит при суммарном транзитном трафике 500 - 800 >Гб в месяц! Я недавно от этого кошмара отключился - не >нарадуюсь. (Да и Ринету на 100 Гб в месяц легче стало >:-))     Я знаю "Ринет" с 1996 года, на магистрали там _всегда_ стояли Циски. Сейчас там шеститонник+7206. А судя по запальчивости тона, проблемы, как всегда, на стороне клиента.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	25. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Дохтур on 26-Дек-07, 22:11
	> Аналог scrub и modulate state у iptables в >студию. Скажите, а часто вы на интенсивном трафике пользуетесь scrub & state modulation? Да и пересборка пакетов - вещь затратная как по памяти, так и по cpu. А вот куда более жизненное DSCP матчить/выставлять - это да, не умеет pf. Как и не умеет от SCTP, который во всю уже используется вменяемыми людьми. И ECN не умеет, и по длине пакета матчить не может... А вы говорите о каких-то полухакерских плюшках(passive os fingerprint из той же оперы). >    Я знаю "Ринет" с 1996 года, на магистрали >там _всегда_ стояли Циски. Сейчас там шеститонник+7206. А судя по запальчивости >тона, проблемы, как всегда, на стороне клиента. 7206 - откровенное г-но.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	32. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 01:28
	> Скажите, а часто вы на интенсивном трафике пользуетесь scrub & state modulation? > Да и пересборка пакетов - вещь затратная как по памяти, так и по cpu. Стоять. Вопрос был в возможностях пакетных фильтров. Так что не надо увиливать. Аналоги в студию. > А вот куда более жизненное DSCP матчить/выставлять - это да, не умеет pf. Матчить умеет ALTQ, коему это, вообще говоря, и надо делать. А _выставлять_ DiffServ CodePoint пакетный фильтр вообще не должен, он _не_ генерирует TCP/IP-траффик. > Как и не умеет от SCTP, который во всю уже используется вменяемыми людьми. PF разрабатывается совместно с TCP/IP-стеком *BSD. А у *BSD с SCTP пока не всё ладно, что уж тут поделать. Только вот насчёт "вовсю" -- это явный перегиб. ;) > И ECN не умеет, и по длине пакета матчить не может... ECN тоже поддерживается в ALTQ, пакетному фильтру он плоскопараллелен. А за длину пакета -- не менее "полухакерская штучка" (C). > 7206 - откровенное г-но. Аминь! (C)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	49. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 27-Дек-07, 10:42
	>Стоять. Вопрос был в возможностях пакетных фильтров. >Так что не надо увиливать. Аналоги в студию. вы же прекрасно понимаете что прямых аналогов нет. часть функционала есть в штатных модулях iptables. Тупо сравнивать "а у нас есть вот эта мегакрутая фича, а у вас нет" - это не путь к конструктиву :))) Чего стоят модули string, connbytes, u32. Кстати, а для чего вам state modulation? >Матчить умеет ALTQ, коему это, вообще говоря, и надо делать. А _выставлять_ >DiffServ CodePoint пакетный фильтр вообще не должен, он _не_ генерирует TCP/IP-траффик. Дал мне один isp впн для объединения регионов и спрашивает: "Вы сами трафик красить будете?" >PF разрабатывается совместно с TCP/IP-стеком *BSD. А у *BSD с SCTP пока >не всё ладно, что уж тут поделать. Только вот насчёт "вовсю" >-- это явный перегиб. ;) SCTP используется везде где есть sigtran(т.е. это его часть ;))). Так что используют весьма активно(та же cisco). >ECN тоже поддерживается в ALTQ, пакетному фильтру он плоскопараллелен. А за длину >пакета -- не менее "полухакерская штучка" (C). ну почему же. зафильтровать skype/voip/syn-флуд и вообще как доп. проверка. PS: а вот интересно, почему не обратили внимание на такую вещь: pf - это пакетный фильтр, а iptables - это скорее язык программирования правил фильтрации(переходы, возвраты, проверки условий, итп).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	61. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 17:56
	>> Стоять. Вопрос был в возможностях пакетных фильтров. >> Так что не надо увиливать. Аналоги в студию. > вы же прекрасно понимаете что прямых аналогов нет.     Ну тогда и не надо кричать. Надо уметь честно признаваться, что "у нас вот этого вот нет, и это плохо". > часть функционала есть в штатных модулях iptables. Тупо сравнивать "а у нас > есть вот эта мегакрутая фича, а у вас нет" - это > не путь к конструктиву :)))     Это и есть путь к конструктиву, если фича _действительно_ мегакрутая, а не чушь типа сравнения длин пакетов. > Чего стоят модули string, connbytes, u32.     Во FreeBSD есть значительно более общий способ исследования пакетов -- NetGraph. Но включая его, админ берёт на себя ответственность за снижение пакетной производительности маршрутизатора из-за удлинения packet flow path.     А вот в пакетный фильтр вставлять "тяжёлые" фичи, на мой взгляд, конечно -- совершенно не нужно. > Кстати, а для чего вам state modulation?     Для защиты хостов за пакетным фильтром от SYN-based атак. А для чего вообще нужен пакетный фильтр, как не для защиты хостов за ним?-) >> Матчить умеет ALTQ, коему это, вообще говоря, и надо делать. А _выставлять_ >> DiffServ CodePoint пакетный фильтр вообще не должен, он _не_ генерирует TCP/IP-траффик. > Дал мне один isp впн для объединения регионов и спрашивает: "Вы сами > трафик красить будете?"     Правильно! Вот пусть какой-нибудь Asterisk и красит свой голосовой траффик! Он же его генерирует -- а пакетный фильтр-то тут при чём?! >> PF разрабатывается совместно с TCP/IP-стеком *BSD. А у *BSD с SCTP пока >> не всё ладно, что уж тут поделать. Только вот насчёт "вовсю" >> -- это явный перегиб. ;) > SCTP используется везде где есть sigtran(т.е. это его часть ;))). > Так что используют весьма активно(та же cisco).     Какие Юниксовые распространённые серверные приложения поддерживают SCTP? >> ECN тоже поддерживается в ALTQ, пакетному фильтру он плоскопараллелен. А за длину >> пакета -- не менее "полухакерская штучка" (C). > ну почему же. зафильтровать skype/voip/syn-флуд и вообще как доп. проверка.     SYN-флуд фильтруется PF'ным synproxy. Длины пакетов тут ни при чём.     А L7-filtering, опять-таки, IMHO, конечно, слишком "тяжёл" для того, чтобы его включать в пакетный фильтр, да и малопригоден в случае, например, смены протокола. Ядро хачить каждый раз?     Надо фильтрануть/зашейпить Skype/пиринговые сети -- NetGraph вам в руки, только вот зачем?.. > PS: а вот интересно, почему не обратили внимание на такую вещь: pf > - это пакетный фильтр, а iptables - это скорее язык программирования > правил фильтрации(переходы, возвраты, проверки условий, итп).     Что называется английским словом "overbloated". :)     И вызывает сложности в отладке.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	76. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 27-Дек-07, 20:50
	>    Ну тогда и не надо кричать. Надо уметь >честно признаваться, что "у нас вот этого вот нет, и это >плохо". Ооох... заглянем в в man: http://www.freebsd.org/cgi/man.cgi?query=pf.conf&apropos=0&s... no-df - есть. min-ttl - есть max-mss - есть random-id - нет(реально, зачем оно надо?) fragment reassemble            Using scrub rules, fragments can be reassembled by normalization.            In this case, fragments are buffered until they form a complete            packet, and only the completed packet is passed on to the filter.            The advantage is that filter rules have to deal only with complete            packets, and can ignore fragments.  The drawback of caching frag-            ments is the additional memory cost.  But the full reassembly            method is the only method that currently works with NAT.  This is            the default behavior of a scrub rule if no fragmentation modifier            is supplied. - потенциальный DoS на память. Опять же, зачем это? fragment crop - опять же, зачем? (плюс fragment crop reassembly mechanism does not yet work with NAT.) reassemble tcp - всё это есть в iptables. >    Это и есть путь к конструктиву, если фича >_действительно_ мегакрутая, а не чушь типа сравнения длин пакетов. не сравнения, а матчинга по длине пакета. >    Во FreeBSD есть значительно более общий способ исследования >пакетов -- NetGraph. Но включая его, админ берёт на себя ответственность >за снижение пакетной производительности маршрутизатора из-за удлинения packet flow path. ага-ага. И эротические экзерцисы с ng_bpf и её своеобразным языком? Опять же, поиск по маске вы так не сделаете. >    А вот в пакетный фильтр вставлять "тяжёлые" фичи, >на мой взгляд, конечно -- совершенно не нужно. iptables - модульный, в отличие от pf. И кстати, как по-другому эти "тяжелые" фичи реализовать? btw, написание модулей для iptables весьма просто + внятная документация. >Для защиты хостов за пакетным фильтром от SYN-based >атак. А для чего вообще нужен пакетный фильтр, как не для >защиты хостов за ним?-) да ну? злоумышленник начнёт бомбить пакетами по 64к мелкими фрагментами и хосту с pf станет плоха. И state modulation - это костыль против ОС с плохой генерацией ISN, а не средство защиты от SYN-flood. >    Правильно! Вот пусть какой-нибудь Asterisk и красит свой >голосовой траффик! Он же его генерирует -- а пакетный фильтр-то тут >при чём?! ага-ага. Только когда у вас 50-60 sip-устройств проще покрасить на шлюзе. Тем более это куда более правильно с точки зрения безопасности, т.к. в противном случае _любой_ источник bulk-трафика может поставить раком voip, покрасив свой трафик как ему вздумается. ы? > Какие Юниксовые распространённые серверные приложения поддерживают SCTP? cisco pgw-2200. И кстати, причём тут софт? pf стоит на роутере, а за роутером может быть целый зоопарк устройств. >SYN-флуд фильтруется PF'ным synproxy. Длины пакетов тут ни >при чём. ок, закройте pf'ом skype, не тронув dns & rtp. > А L7-filtering, опять-таки, IMHO, конечно, слишком "тяжёл" для >того, чтобы его включать в пакетный фильтр, да и малопригоден в >случае, например, смены протокола. Ядро хачить каждый раз? Вот для этого и нужен анализ по длине пакета и модули, которые вам кажутся ненужными. На примере того же skype: Сначала отбираем udp пакеты + опр. длины. А потом уже отправляем на L7-filter. pf так может? >Надо фильтрануть/зашейпить Skype/пиринговые сети -- NetGraph вам в >руки, только вот зачем?.. зачем? Чтобы несколько десятков юзеров не уложили всё торрентами, чтобы фильтровать нежелательный skype etc. А с netgraph ещё помучиться придётся. >> PS: а вот интересно, почему не обратили внимание на такую вещь: pf >> - это пакетный фильтр, а iptables - это скорее язык программирования >> правил фильтрации(переходы, возвраты, проверки условий, итп). >    Что называется английским словом "overbloated". :) >    И вызывает сложности в отладке. в чём сложности? каждый модуль можно отлаживать отдельно, логика iptables весьма прозрачна, traffic path в картинках есть, производить действия над пакетом можно в любой момент. Хоть до nat, хоть после.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	77. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от BB (??) on 27-Дек-07, 21:01
	>>SYN-флуд фильтруется PF'ным synproxy. Длины пакетов тут ни >>при чём. > >ок, закройте pf'ом skype, не тронув dns & rtp. кесарю кесарево знаете-ли нюхач snort + snortsam >Вот для этого и нужен анализ по длине пакета и модули, которые >вам кажутся ненужными. >На примере того же skype: >Сначала отбираем udp пакеты + опр. длины. А потом уже отправляем на >L7-filter. >pf так может? Может см. выше
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	83. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 27-Дек-07, 21:15
	>кесарю кесарево знаете-ли >нюхач snort + snortsam снорт даст куда большую нагрузку на cpu. Хотя бы потому что ему придётся слушать весь трафик(я уж не говорю о копировании данных в юзерланд). >>Вот для этого и нужен анализ по длине пакета и модули, которые >>вам кажутся ненужными. >>На примере того же skype: >>Сначала отбираем udp пакеты + опр. длины. А потом уже отправляем на >>L7-filter. >>pf так может? >Может см. выше ООх... http://nuclight.livejournal.com/122098.html "Стоит заметить, что не всякий L7 filtering может быть сделан с помощью ng_bpf - поскольку в этом ассемблере запрещены условные переходы назад и таким образом циклы, нельзя организовать, например, поиск фиксированной подстроки по заранее неизвестному (и никак не вычисляемому из других данных) смещению в пакете (то, что делает iptables -m string) - думается, в будущем будет написан netgraph-узел, который займется именно этим :)"
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	85. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от BB (??) on 27-Дек-07, 22:08
	>>кесарю кесарево знаете-ли >>нюхач snort + snortsam > >снорт даст куда большую нагрузку на cpu. Хотя бы потому что ему >придётся слушать весь трафик(я уж не говорю о копировании данных в >юзерланд). Ох, ну ведь можно-же хоть иногда думать на шаг вперед,а не воспринимать все в лоб !!! Написано "нухач снорт" - совсем не трудно догадаться что сие есть отдельная машинка которая просто коллектит алерты и рассылает их посредством snortsam на пакетные фильтры ??? >>>Вот для этого и нужен анализ по длине пакета и модули, которые >>>вам кажутся ненужными. >>>На примере того же skype: >>>Сначала отбираем udp пакеты + опр. длины. А потом уже отправляем на >>>L7-filter. >>>pf так может? >>Может см. выше > >ООх... http://nuclight.livejournal.com/122098.html Почетал, автор жжот, хотя для экспириенса полезно - но существуют другие пути решения > >"Стоит заметить, что не всякий L7 filtering может быть сделан с помощью >ng_bpf - поскольку в этом ассемблере запрещены условные переходы назад и >таким образом циклы, нельзя организовать, например, поиск фиксированной подстроки по заранее >неизвестному (и никак не вычисляемому из других данных) смещению в пакете >(то, что делает iptables -m string) - думается, в будущем будет >написан netgraph-узел, который займется именно этим :)" А зачем ???, зачем вещать весь груз на одну лошадь ??? Идеология аля мелкософт :(
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	87. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Дохтур on 27-Дек-07, 23:34
	>Ох, ну ведь можно-же хоть иногда думать на шаг вперед,а не воспринимать >все в лоб !!! >Написано "нухач снорт" - совсем не трудно догадаться что сие есть отдельная >машинка которая просто коллектит алерты и рассылает их посредством snortsam на >пакетные фильтры ??? вы алерты откуда получать будете? С сенсоров? В любом случае сенсоры должны мониторить почти весь проходящий трафик и сравнивать с сигнатурами. >Почетал, автор жжот, хотя для экспириенса полезно - но существуют другие пути >решения какие? >А зачем ???, зачем вещать весь груз на одну лошадь ??? Идеология >аля мелкософт :( а как вы хотите? быстрее всего матчить в ядре.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	117. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от nuclight on 30-Дек-07, 22:29
	>ага-ага. И эротические экзерцисы с ng_bpf и её своеобразным языком? >Опять же, поиск по маске вы так не сделаете. Он не свобеобразный, а вполне себе обычный язык tcpdump. Который уже и так обязан знать любой сетевой админ. Так что новый язык учит не придется. >ага-ага. Только когда у вас 50-60 sip-устройств проще покрасить на шлюзе. >Тем более это куда более правильно с точки зрения безопасности, т.к. в >противном случае >_любой_ источник bulk-трафика может поставить раком voip, покрасив свой трафик как ему >вздумается. ы? См. в другом комменте - к ipfw есть патч для dscp. >Вот для этого и нужен анализ по длине пакета и модули, которые >вам кажутся ненужными. >На примере того же skype: >Сначала отбираем udp пакеты + опр. длины. А потом уже отправляем на >L7-filter. >pf так может? ipfw может. Пример в man ng_tag так и делает - сначала выбирается нужная длина пакета. >А с netgraph ещё помучиться придётся. Не более, чем с модулями к iptables. >traffic path в картинках есть, производить действия над пакетом можно в >любой момент. Хоть до nat, хоть после. ipfw в этом еще гибче.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	112. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Кирилл (??) on 29-Дек-07, 11:06
	>    Во FreeBSD есть значительно более общий способ исследования >пакетов -- NetGraph. Но включая его, админ берёт на себя ответственность >за снижение пакетной производительности маршрутизатора из-за удлинения packet flow path. Если фильтровать на уровне ядра через узлы NetGraph (а ipfw имеет свои узлы), скорость фильтрации возрастает чуть ли не в десять раз, если сравнивать с реализацией сходной функциональности на Pf на пользовательском уровне. Но идут работы по созданию узла NetGraph для Pf.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	89. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Анонимус on 28-Дек-07, 00:30
	>А вы говорите о каких-то полухакерских плюшках(passive os fingerprint из той же >оперы). Кстати, passive os fingerprinting в iptables поддерживается модулем OSF (OS fingerprint).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	116. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от nuclight on 30-Дек-07, 22:20
	>А вот куда более жизненное DSCP матчить/выставлять - это да, не умеет >pf. Есть патч для ipfw (емнип, даже в базе PRов). И он и без патча уже может матчить биты ECN и длину пакета.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от s_dog (??) on 27-Дек-07, 01:05
	>    Аналог scrub и modulate state у iptables в >студию. http://ozlabs.org/~rusty/index.cgi/2006/08/15 no scrubbing, but we do fragment reassembly because we use "-m state" and NAT, either of which requires connection tracking
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	36. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 01:49
	>>    Аналог scrub и modulate state у iptables в >>студию. > >http://ozlabs.org/~rusty/index.cgi/2006/08/15 > >no scrubbing, but we do fragment reassembly because we use "-m state" >and NAT, either of which requires connection tracking Я ж просил аналоги вполне конкретных вещей: "scrub" и "modulate state". И где они там?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	98. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Nick (??) on 28-Дек-07, 08:55
	>Я ж просил аналоги вполне конкретных вещей: "scrub" и "modulate state". И >где они там? Вобщем-то, правильно сказали выше. Некорректно требовать именно "аналога вот этой фишки". Нужно рассматривать проблему, которая решается (или пытается быть решенной) этой фишкой - и уж сравнивать аналоги схем решения. scrub: А аналоги проверки валидности TCP пакета и его пересборка в iptables есть: -m state --state INVALID -j DROP           - неправильные TCP флаги идут фтопку а пересборка и так производится коннтреком. Нужно просто загрузить его модуль (или же он собран статикой) и все. Даже никаких правил не надо :) modulate state: iptables таким не занимается, в нем такого нет. И проблему нужно решать на корню: в ОСе, которая генерит плохие TCP seq ids.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	72. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от SunTech on 27-Дек-07, 18:54
	>    Я знаю "Ринет" с 1996 года, на магистрали >там _всегда_ стояли Циски. Сейчас там шеститонник+7206. А судя по запальчивости >тона, проблемы, как всегда, на стороне клиента. Тоже знаю Ринет и знаю, подтверждаю, что там циски, но фрю там любят. Не рекламы ради, но мне нравился Ринет, к сожалению я переехал, и теперь скучаю по нему.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	86. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Redacid (??) on 27-Дек-07, 22:13
	>[оверквотинг удален] > >Мое мнение. По функционалу BSD с PF отдыхает против связки iptables+iproute2 (в >умелых руках, конечно). Всякие кивки про лучшую производительность BSD на 4 >гигабитных сетевухах - бред. Нормальные провайдеры (и крупные сети) на нагруженных >каналах используют магистральные маршрутизаторы. И только в России остаются уроды, ставящие >на шлюзы транспортной сети BSDовые рутеры. Одного такого знаю - Ринет. >Как же их колбасит при суммарном транзитном трафике 500 - 800 >Гб в месяц! Я недавно от этого кошмара отключился - не >нарадуюсь. (Да и Ринету на 100 Гб в месяц легче стало >:-)) что вы плетёте??? какие 800 Гб - это 25 Гб в день поверьте БСД способна перелопатить гораздо больше Вы не думали, что просто их каналы были не такие уж широкие
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	96. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 28-Дек-07, 01:58
	> поверьте БСД способна перелопатить гораздо больше > Вы не думали, что просто их каналы были не такие уж широкие     Издеваетесь, коллега?-)))     Там только на инфраструктуру MSK-IX гигабит. :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	97. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Redacid (??) on 28-Дек-07, 08:03
	> Издеваетесь, коллега?-))) > Там только на инфраструктуру MSK-IX гигабит. :) Вообще-то я имел ввиду ширину внешних каналлов, но не в этом суть. Это всего лишь предположение, я не знаком с данным ИСП так-как проживаю в другом городе, более того - в другой стране. Исходя из Ваших слов могу предположить, что это довольно крупный провайдер и цифра в 800 Гб/мес просто смешная (мой домашний роутер/сервер отдаёт в Мир по 500 Гб/мес и это не считая трафика внутри страны, который во много раз больше). ПС: Ко всем - Как надоели уже эти холивары, может хватит поносить системы которые вы не используете по тем или иным причинам. Ничего тут не поделаешь, ну не нравится мне Линух на сервере, ну нравится мне БСД, тут дело вкуса каждого. Ведь было время когда людей объединяла общая идея и небыло никакой разницы какую систему он использовал. Хочешь что-то изменить? - начни с себя.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	103. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 28-Дек-07, 11:37
	>Ничего >тут не поделаешь, ну не нравится мне Линух на сервере, ну >нравится мне БСД, тут дело вкуса каждого. Без обид, но это первый признак непрофессионализма - исходить из личных предпочтений. несмотря на то что в данной дискуссии я занимаю сторону iptables, мне нравится pf и его синтаксис.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от guest (??) on 26-Дек-07, 23:43
	Это потрясающе - мало того, что сам нифига не знает, дык ещё и других поучать берётся! >Дело в том, что и Linux, и *BSD разрабатывались для машин с >MMU. Нет, безусловно, и Linux, и BSD _в теории_ могут работать >и без MMU (ну, не будет вам fork()'a, перебьётесь парой vfork()/exec(), >никуда не денетесь). Но делают они это крайне хреново: надо algorithmic >base менять. И в ядре, и в User Land'е. Дело в том, что менять нужно то, что по недоразумению ты считаешь своим мозгом - оно явно не работает вообще. А вот Linux отлично работает без MMU: http://www.uclinux.org/ >Linux, как роутер, безусловно плох. Впрочем, *BSD ненамного лучше. Лучше. Но ненамного. Бред. Linux как маршрутизатор - хорошо, как мультисервисный маршрутизатор - великолепен, бздя - терпимо. >Скажем так, если десять лет назад, увидев роутер на Линуксе, имело >смысл немедленно оный Линукс снести, и поставить *BSD, то теперь это >неактуально: да, будет чуть лучше, но овчинка выделки не стоит. Вменяемые люди делают с точностью до наоборот - ставят открытую прошивку с Linux: dd-wrt к примеру: http://www.dd-wrt.com/ >IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables. >Слишком много точек входа в ядро, код перегружен и глючит. Во истину идиот - что именно "глючит" помимо твоих перегревшихся от безуспешных попыток думать мозгов? Багрепорт сделал? >Да, PF умеет фильтровать только IP-пакеты. Про Ethernet он ничего не знает, >по MAC-адресу им не зафильтруешь. Ну и пёс с ним. Зато у PF есть таблицы. "Пёс" с недоумками, рассуждающими о том с чем они знакомы весьма поверхностно. > _Нормальные_ таблицы, обновляемые из User Land на >лету, и поиск по которым осуществляется по RADIX Tree, а не по линейному списку. Таблицы там вполне нормальные, обновляю я их как раз из пространства пользователя, а как именно они сортируются мне до лампочки - главное что это происходит быстро. > PF умеет якоря (anchors), и несколько программ, модифицирующих >правила пакетного фильтра, _никогда_ не подерутся. За каким упырём нескольким программам модифицировать правила МСЭ одновременно?! >Но пакетный фильтр -- это не то, за что идёт борьба на >роутере. На роутере идёт борьба за пакетную производительность. А она достигается >использованием либо ASIC'ов, либо NPU. Period. Idiot. В маршрутизаторе важно удобство конфигурации и спектр поддерживаемых протоколов плюс безопасность. Производительность по пакетам имеет решающее значение для коммутаторов.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от klez (??) on 26-Дек-07, 23:59
	Ну вот опять. Только дин думающий и вменяемый человек на опеннете высказался, как пришло двое, с личными комплексами и начали его грязью поливать, параллельно навешивая ярлыки и на своих провайдеров и на имя и фамилию человека, не побоявшегося подписаться.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от pavel_simple (ok) on 27-Дек-07, 00:09
	Высказался может и правильно да вот только (ИМХО) не объективно
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 01:52
	> Высказался может и правильно да вот только (ИМХО) не объективно На OpenNet'е высказываются почти никогда не объективно: объективность _может_ быть достигнута только приведением результатов тестов. А может и _не быть достигнута_ -- постановка экспериментов -- это большое искусство. На OpenNet'е высказываются, исходя из своего _личного_ опыта. Ну и неких общеизвестных вещей, легко устанавливаемых чтением документации.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	46. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 09:25
	> на имя и фамилию человека, не побоявшегося подписаться. Ну, я человек без комплексов, ФСБ не боюсь, так что подписываюсь везде и всегда реальным именем. :) И очень удивлён, что на OpenNet'е это необщепринятая практика. У участников форума схизис (расщепление личности) -- в RL одно, в Интернете -- другое?-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 01:47
	> Это потрясающе - мало того, что сам нифига не знает, дык ещё > и других поучать берётся!     Гражданин, OpenNet -- не место, где показывают свои комплексы. > Дело в том, что менять нужно то, что по недоразумению ты считаешь > своим мозгом - оно явно не работает вообще. А вот Linux > отлично работает без MMU: http://www.uclinux.org/     Во-первых, я, видимо, по недоразумению считаю то, чем Вы смотрите в монитор, глазами. Я писал, что Linux и *BSD _могут_ работать без MMU. Но делают это _плохо_. Рекомендую читать всё, и внимательно. А почему плохо -- да потому, что весь User Land работает на модели fork(). Ну, написан он так был 30 лет назад. >> Linux, как роутер, безусловно плох. Впрочем, *BSD ненамного лучше. Лучше. Но ненамного. > Бред. Linux как маршрутизатор - хорошо, как мультисервисный маршрутизатор - великолепен, > бздя - терпимо.     Это частное, ничем не подкреплённое мнение, такое же, как и моё высказывание.     Но я не позволяю себе давать оценок типа "бред". Хотите полемики? Либо пишите IMHO, либо тесты в студию. >> Скажем так, если десять лет назад, увидев роутер на Линуксе, имело >> смысл немедленно оный Линукс снести, и поставить *BSD, то теперь это >> неактуально: да, будет чуть лучше, но овчинка выделки не стоит. > Вменяемые люди делают с точностью до наоборот - ставят открытую прошивку с > Linux: dd-wrt к примеру: http://www.dd-wrt.com/     Вменяемые люди понимают отличие домашней радиобалалайки от роутера. >> IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables. >> Слишком много точек входа в ядро, код перегружен и глючит. > Во истину идиот - что именно "глючит" помимо твоих перегревшихся от безуспешных > попыток думать мозгов? Багрепорт сделал?     О да, делали. :))) Одно чинят, другое ломают. :))) Есть такая наука у Линуксоидов и Цисководов: подберите Линуксовое ядро/версию Cisco IOS, в котором не сломан нужный вам набор фич. ;))) >> Да, PF умеет фильтровать только IP-пакеты. Про Ethernet он ничего не знает, >> по MAC-адресу им не зафильтруешь. Ну и пёс с ним. Зато у PF есть таблицы. > "Пёс" с недоумками, рассуждающими о том с чем они знакомы весьма поверхностно.     Да-да-да, вот из-за таких вот недоумков, как Вы, почтенный, OpenNet превращается в LOR, ибо предмет Вы знаете, прямо скажем, не очень. ;) >> _Нормальные_ таблицы, обновляемые из User Land на >> лету, и поиск по которым осуществляется по RADIX Tree, а не по линейному списку. > Таблицы там вполне нормальные, обновляю я их как раз из пространства пользователя, > а как именно они сортируются мне до лампочки - главное что > это происходит быстро.     Я сейчас от смеха лопну. Вы, правда, не понимаете разницы между O(n) и O(log(n))?-) И почему это критично на обработке TCP/IP-траффика?-) >> PF умеет якоря (anchors), и несколько программ, модифицирующих >> правила пакетного фильтра, _никогда_ не подерутся. > За каким упырём нескольким программам модифицировать правила МСЭ одновременно?!     Что значит "за каким"? ftpsesame+обработчик UPnP на клиентском роутере. Вот и одновременно. Вы что, никогда клиентских роутеров не делали, да? >> Но пакетный фильтр -- это не то, за что идёт борьба на >> роутере. На роутере идёт борьба за пакетную производительность. А она достигается >> использованием либо ASIC'ов, либо NPU. Period. > Idiot. В маршрутизаторе важно удобство конфигурации и спектр поддерживаемых > протоколов плюс безопасность. > Производительность по пакетам имеет решающее значение для коммутаторов.     Всё понятно. Аминь!     7604+куча LAN-карт -- это НЕ коммутатор. Но сетку на 10GigE на пол-Ленинграда держит. ;) Так что Вы сначала какую-нибудь сетку постройте диаметром больше, чем Ваша квартира, а потом судить беритесь.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 27-Дек-07, 02:15
	>>> Linux, как роутер, безусловно плох. Впрочем, *BSD ненамного лучше. Лучше. Но ненамного. >> Бред. Linux как маршрутизатор - хорошо, как мультисервисный маршрутизатор - великолепен, >> бздя - терпимо. > >    Это частное, ничем не подкреплённое мнение, такое же, >как и моё высказывание. > >    Но я не позволяю себе давать оценок типа >"бред". Хотите полемики? Либо пишите IMHO, либо тесты в студию. При админе-эникейщике все пофиг - все равно работать не будет. >>> Скажем так, если десять лет назад, увидев роутер на Линуксе, имело >>> смысл немедленно оный Линукс снести, и поставить *BSD, то теперь это >>> неактуально: да, будет чуть лучше, но овчинка выделки не стоит. Странно, а у меня выходит наоборот - ну не знаю я *BSD до такой степени, в результате под пингвином у меня работает надежнее чем под фряхой или опенком. >    Вменяемые люди понимают отличие домашней радиобалалайки от роутера. А еще есть маньяки, которые домой для личного пользования цисковские роутеры ставят.... >>> IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables. >>> Слишком много точек входа в ядро, код перегружен и глючит. >> Во истину идиот - что именно "глючит" помимо твоих перегревшихся от безуспешных >> попыток думать мозгов? Багрепорт сделал? > >    О да, делали. :))) Одно чинят, другое ломают. >:))) Есть такая наука у Линуксоидов и Цисководов: подберите Линуксовое ядро/версию >Cisco IOS, в котором не сломан нужный вам набор фич. ;))) По личному опыту: у BSD-шников не лучше. Иначе только в винде - там за админа все дяди из МС решают. >>> Да, PF умеет фильтровать только IP-пакеты. Про Ethernet он ничего не знает, >>> по MAC-адресу им не зафильтруешь. Ну и пёс с ним. Зато у PF есть таблицы. >> "Пёс" с недоумками, рассуждающими о том с чем они знакомы весьма поверхностно. > >    Да-да-да, вот из-за таких вот недоумков, как Вы, >почтенный, OpenNet превращается в LOR, ибо предмет Вы знаете, прямо скажем, >не очень. ;) Он не умеет по маку фильтровать? Хоть и действует только в рамках одной сетки, но полезно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	42. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 09:18
	> При админе-эникейщике все пофиг - все равно работать не будет.     Безусловно. Всё, что один человек сделал, другой завсегда сломать может. :)     Но это отдельная и, прямо скажем, весьма и весьма болезненная тема -- тема нехватки квалифицированных кадров. Правда, она не совсем для OpenNet'а. IMHO, конечно. :) > Странно, а у меня выходит наоборот - ну не знаю я *BSD > до такой степени, в результате под пингвином у меня работает надежнее > чем под фряхой или опенком.     Безусловно, знание есть вещь великая. Меня по-детски смешат высказывания на форумах, где люди мучаются с установкой FreeBSD на ноутбуки. Два ноута было -- на обоих Фря стояла, и не жужжала. ;) И сейчас я пишу с ноута из-под Фри. ;) >> Вменяемые люди понимают отличие домашней радиобалалайки от роутера. > А еще есть маньяки, которые домой для личного пользования цисковские роутеры ставят....     Сложный вопрос. Их последняя 18'я серия, рассчитанная на MetroEthernet, стоит нормальных денег. >> :))) Есть такая наука у Линуксоидов и Цисководов: подберите Линуксовое ядро/версию >> Cisco IOS, в котором не сломан нужный вам набор фич. ;))) > По личному опыту: у BSD-шников не лучше. Иначе только в винде - > там за админа все дяди из МС решают.     Опять-таки, по личному опыту: _сеть_ во FreeBSD за последние 11 лет не ломали _ни разу_. ATA ломали, USB ломали, а вот сеть -- не ломали. > Он не умеет по маку фильтровать? Хоть и действует только в рамках > одной сетки, но полезно.     Нет, не умеет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	50. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 27-Дек-07, 10:46
	>    Опять-таки, по личному опыту: _сеть_ во FreeBSD за >последние 11 лет не ломали _ни разу_. ATA ломали, USB ломали, >а вот сеть -- не ломали. em, bge в 6ке? или "это драйвера, не считается"?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	62. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 17:57
	> em, bge в 6ке? или "это драйвера, не считается"? У меня 6'ка с em работает два года, и ничего там не ломается. "Что я делаю не так?"
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	73. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 27-Дек-07, 19:51
	>> em, bge в 6ке? или "это драйвера, не считается"? >У меня 6'ка с em работает два года, и ничего там не >ломается. "Что я делаю не так?" т.е. то что творилось в freebsd-net & freebsd-current перед выпуском 6.2 - это галлюцинации?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	95. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 28-Дек-07, 01:53
	>>> em, bge в 6ке? или "это драйвера, не считается"? >> У меня 6'ка с em работает два года, и ничего там не ломается. "Что я делаю не так?" > т.е. то что творилось в freebsd-net & freebsd-current перед выпуском 6.2 - > это галлюцинации? А, это про импорт и откаты? Так это же _перед_ выпуском! Вы бы почитали -current в момент строительства пятёрки... ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	39. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от V.O. on 27-Дек-07, 04:52
	>    7604+куча LAN-карт -- это НЕ коммутатор. Но сетку >на 10GigE на пол-Ленинграда держит. ;) Так что Вы сначала какую-нибудь >сетку постройте диаметром больше, чем Ваша квартира, а потом судить беритесь. > имеется ввиду, что он у вас core router? ЗЫ постинги на редкость осмысленные для опеннет, спсб
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	43. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 09:21
	>> 7604+куча LAN-карт -- это НЕ коммутатор. Но сетку >> на 10GigE на пол-Ленинграда держит. ;) Так что Вы сначала какую-нибудь >> сетку постройте диаметром больше, чем Ваша квартира, а потом судить беритесь. > имеется ввиду, что он у вас core router?     Не у меня, у tvoe.tv. Да, MPLS Core сделан на нескольких 7604'х. У меня core сделан на двух Cisco Catalyst 6506, но у меня L3 Switching, для энтерпрайзных сетей MPLS нужен редко. > ЗЫ постинги на редкость осмысленные для опеннет, спсб     :) Спасибо за комплимент.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	53. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от гость on 27-Дек-07, 12:12
	>А почему плохо -- да потому, что весь User >Land работает на модели fork(). Ну, написан он так был 30 >лет назад. Так, теперь ещё и ядро с дистрибутивом путаем... вообще красота! Ядро и базовые библиотеки отлично работают без MMU - см. приведённую ссылку. Дистрибутивы, рассчитанные на работу без MMU соответственно имеют отлично работающий userland - где надо - пересобрано, где надо - переписано. И в качестве лекарства от прогрессирующего маразма - не могло пользовательское окружение линукса быть написано 30 лет назад - тогда линукса ещё просто не было! >    Вменяемые люди понимают отличие домашней радиобалалайки от роутера. ну давай, докажи мне что точка доступа с dd-wrt это не роутер. клоун, блин! >:))) Есть такая наука у Линуксоидов и Цисководов: подберите Линуксовое ядро/версию >Cisco IOS, в котором не сломан нужный вам набор фич. ;))) с сиькой это известная история, а про линукс - снова брехня! не утомился врать-то? >    Я сейчас от смеха лопну. Вы, правда, не >понимаете разницы между O(n) и O(log(n))?-) И почему это критично на >обработке TCP/IP-траффика?-) Единственное чего я не понимаю - это какое отношение имеет генерируемый тобой бред к действительности? Покажи мне тест, где iptables сливает pf с соотношением n\log n при нагрузке в n пакетов в секунду. >    Что значит "за каким"? ftpsesame+обработчик UPnP на клиентском >роутере. Вот и одновременно. Вы что, никогда клиентских роутеров не делали, да? ни сезам ни упнп не использовал ни разу - и всё отлично работает и все довольны. по существу сказать нечего, да? >    7604+куча LAN-карт -- это НЕ коммутатор. Но сетку >на 10GigE на пол-Ленинграда держит. ;) Так что Вы сначала какую-нибудь >сетку постройте диаметром больше, чем Ваша квартира, а потом судить беритесь. Я работал с сетями городского масштаба, поэтому прекрасно осведомлён, что 7600 это ровно то же самое, что 6500 у сиськи. До недавнего времени там даже софт без проблем ставился между сериями: аппаратно они абсолютно одинаковы. Так что это именно коммутатор. Хороший коммутатор 3 уровня с поддержкой протоколов маршрутизации.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	70. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 18:27
	>> А почему плохо -- да потому, что весь User >> Land работает на модели fork(). Ну, написан он так был 30 >> лет назад. > Так, теперь ещё и ядро с дистрибутивом путаем... вообще красота!     Извините, у нас принято говорить про работающую платформу.     Или ядро Линукса уже научилось грузиться непосредственно из BIOS'а?     Или grub/lilo стали частью ядра?     Так что отделять ядро от базовых библиотек/утилит -- это дурь красноглазых линуксоидов-дистростроителей. > Ядро и базовые библиотеки отлично работают без MMU - см. приведённую ссылку.     _Далеко_ не отлично. У меня почему-то Apache 1.3 в этом окружении без кучи мегапатчей не работает. БА-А-А-АГА!!! > Дистрибутивы, рассчитанные на работу без MMU соответственно имеют отлично > работающий userland - где надо - пересобрано, где надо - переписано.     Прелесть Юникса в том, что можно взять софт и собрать его, не переписывая под каждую платформу. Так вот, MMU-less Linux и NetBSD -- это некое странное поделие, претендующее на почти-POSIX-совместимость (нет fork() -- POSIX Incompatible, period.), которое делают исключительно для того, чтобы показать, что "и так мы тоже можем". > И в качестве лекарства от прогрессирующего маразма - не могло пользовательское окружение > линукса быть написано 30 лет назад - тогда линукса ещё просто не было!     Во-первых, аккуратнее с тоном. У меня тоже есть масса соображений по поводу Вашего умственного уровня.     Во-вторых, можно написать что-то и год назад. Но написано это будет по образу и подобию того, что было 20-25-30 лет назад, ибо POSIX. >> Вменяемые люди понимают отличие домашней радиобалалайки от роутера. > ну давай, докажи мне что точка доступа с dd-wrt это не роутер.     Он умеет BGP? OSPF? Policy-based routing? CARP?     Радиобалалайка это для дома, а не роутер. >> :))) Есть такая наука у Линуксоидов и Цисководов: подберите Линуксовое ядро/версию >> Cisco IOS, в котором не сломан нужный вам набор фич. ;))) > с сиькой это известная история, а про линукс - снова брехня!     -- Но нет таких языков, в котором двойное утверждение обозначало бы отрицание...     -- Да ладно, профессор!     В 2.6 ветке уже починили IP over ATM в недефолтных таблицах роутинга?-)     А зависание atmarpd? > не утомился врать-то?     Это просто кто-то тут не в курсе, что бывает не только Fast Ethernet. :) >> Я сейчас от смеха лопну. Вы, правда, не понимаете разницы между O(n) и O(log(n))?-) >> И почему это критично на обработке TCP/IP-траффика?-) > Единственное чего я не понимаю - это какое отношение имеет генерируемый тобой > бред к действительности? Покажи мне тест, где iptables сливает pf с > соотношением n\log n при нагрузке в n пакетов в секунду.     Результаты или модель теста? >> Что значит "за каким"? ftpsesame+обработчик UPnP на клиентском >> роутере. Вот и одновременно. Вы что, никогда клиентских роутеров не делали, да? > ни сезам ни упнп не использовал ни разу - и всё отлично > работает и все довольны.     Да? Не жалуются, почему файлы по аське не ходят?     Ну тогда Вам повезло. Для Москвы и Ленинграда такой уровень сервиса уже не прокатывает, где из-за NAT'а прямые соединения не работают. > по существу сказать нечего, да?     Это Вам по существу сказать нечего. Весь ваш бред сводится к следующему: "Я не делал вот этого, этого и этого -- и у меня всё работает!"     А ещё можно просто всё выключить и уйти бухать. >> 7604+куча LAN-карт -- это НЕ коммутатор. Но сетку >> на 10GigE на пол-Ленинграда держит. ;) Так что Вы сначала какую-нибудь >> сетку постройте диаметром больше, чем Ваша квартира, а потом судить беритесь. > Я работал с сетями городского масштаба, поэтому прекрасно осведомлён, что 7600 это > ровно то же самое, что 6500 у сиськи.     Оп-па... А мужики-то и не знают... > До недавнего времени там даже софт без проблем ставился между сериями: аппаратно > они абсолютно одинаковы. Так что это именно коммутатор. Хороший коммутатор 3 уровня с > поддержкой протоколов маршрутизации.     Аминь! (C)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	74. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 27-Дек-07, 20:04
	>>> А почему плохо -- да потому, что весь User >>> Land работает на модели fork(). Ну, написан он так был 30 >>> лет назад. >    Или ядро Линукса уже научилось грузиться непосредственно из >BIOS'а? да. >    _Далеко_ не отлично. У меня почему-то Apache 1.3 >в этом окружении без кучи мегапатчей не работает. БА-А-А-АГА!!! Андрей, вы же вроде адекватный человек... А давайте туда постгрес с 50гиговой базой впендюрим? Или jvm... (из той же серии, что и ваш вопрос). >    Прелесть Юникса в том, что можно взять софт >и собрать его, не переписывая под каждую платформу. Так вот, MMU-less >Linux и NetBSD -- это некое странное поделие, претендующее на почти-POSIX-совместимость >(нет fork() -- POSIX Incompatible, period.), которое делают исключительно для того, >чтобы показать, что "и так мы тоже можем". оно там работает и вполне успешно. Написание своего - куда более затратно. >    Он умеет BGP? OSPF? Policy-based routing? CARP? да. и carp в linux ядерный, и стейты все сохраняются. >    В 2.6 ветке уже починили IP over ATM >в недефолтных таблицах роутинга?-) ох, опять вы про ipoatm. 2.6 в железках вроде дсл-роутеров скорее исключение из правил. >    Это просто кто-то тут не в курсе, что >бывает не только Fast Ethernet. :) ага. а много ли pf знает о чём-то, отличном от ip/tcp/udp/icmp? > Да? Не жалуются, почему файлы по аське не >ходят? >Ну тогда Вам повезло. Для Москвы и Ленинграда >такой уровень сервиса уже не прокатывает, где из-за NAT'а прямые соединения >не работают. pf & active ftp, pf & sip, pf & dcc в irc, pf & pptp?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	75. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от BB (??) on 27-Дек-07, 20:46
	>>    Или ядро Линукса уже научилось грузиться непосредственно из >>BIOS'а? > >да. Это как сказать, где-то умеет, с использованием "мегахаков", а где то нет. Есть openbios построенный на linux ядре, но грузицо он не везде и не всегда. ИМХО сей проект пока что глубокой преальфе, и говорить что оно работает еще рано, можно сказать "потенциально может" но не более .... > >да. и carp в linux ядерный, и стейты все сохраняются. Пока carp в глубокой бетте, bgp-fullview домашния радоибалалайка не потянет по причине отсутсвия нормального проца и достаточного кол-ва мозгов, с ospf тоже самое   >ага. а много ли pf знает о чём-то, отличном от ip/tcp/udp/icmp? А оно ему надо ? Зато про то что он знает он знает на очень приличном уровне - уровне комерческих решений, а это совсем не мало !!! > >pf & active ftp, pf & sip, pf & dcc в irc, >pf & pptp? ftp-proxy, pptp-proxy, sip-proxy, про dcc не знаю поэтому ничего сказать не могу, но имхо bi-nat это вполне может решить :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	81. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 27-Дек-07, 21:06
	>Пока carp в глубокой бетте, bgp-fullview домашния радоибалалайка не потянет по причине >отсутсвия нормального проца и достаточного кол-ва мозгов, с ospf тоже самое насчёт беты: вы где прочитали? зачем домашнему роутеру принимать fullview? ospf с небольшим числом роутеров и достаточно стабильной сети вполне потянет. >>ага. а много ли pf знает о чём-то, отличном от ip/tcp/udp/icmp? >А оно ему надо ? >Зато про то что он знает он знает на очень приличном уровне >- уровне комерческих решений, а это совсем не мало !!! мда, как обычно "это нам не надо". Типичный openbsd-way: виртуализация несекурна - это нам не надо. HT несекурно, это нам не надо. Многоядерные процессоры несекурны - это нам не надо. Подключение по ethernet несекурно  - могут трафик слушать. может и его того, а? >ftp-proxy, pptp-proxy, sip-proxy, про dcc не знаю поэтому ничего сказать не могу, >но имхо bi-nat это вполне может решить :) так и думал что будет юзерспейсовые костыли. 50-60 человек активно качающих по ftp и ftp-proxy "уложит" роутер. Насчёт pptp-proxy: "The proper way of forwarding PPTP is to use native kernel NAT, but it isn't always easy, feasible or even implemented properly. pptpproxy was written for these situations." А binat вам не поможет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	84. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от BB (??) on 27-Дек-07, 22:01
	>>Пока carp в глубокой бетте, bgp-fullview домашния радоибалалайка не потянет по причине >>отсутсвия нормального проца и достаточного кол-ва мозгов, с ospf тоже самое > >насчёт беты: вы где прочитали? В рассылках, до сих пор существует проблемы которые не позволяют использовать carp и ucarp в решениях выше класса "на поигратцо", следовательно , бетта :) > >зачем домашнему роутеру принимать fullview? >ospf с небольшим числом роутеров и достаточно стабильной сети вполне потянет. А потому как использование bgp без анализа fullview практически бессмысленно. Насчет ospf примерно тоже - немного легче, но похоже. >>>ага. а много ли pf знает о чём-то, отличном от ip/tcp/udp/icmp? >>А оно ему надо ? >>Зато про то что он знает он знает на очень приличном уровне >>- уровне комерческих решений, а это совсем не мало !!! > >мда, как обычно "это нам не надо". >Типичный openbsd-way: виртуализация несекурна - это нам не надо. HT несекурно, это >нам не надо. Многоядерные процессоры несекурны - это нам не надо. я-же говорил что кесарю кесарево, нужно просто уметь находить оптимальные решения, для каких-то вещей наиболее оптимальные выход это применения проприетарной системы на кучу килобаксов, для другого наоборот. В этом-то все и дело, а зацикливацо на одном варианте - есть путь ущербный и неправильный. ИМХО. > >Подключение по ethernet несекурно  - могут трафик слушать. может и его >того, а? см. выше > >>ftp-proxy, pptp-proxy, sip-proxy, про dcc не знаю поэтому ничего сказать не могу, >>но имхо bi-nat это вполне может решить :) > >так и думал что будет юзерспейсовые костыли. >50-60 человек активно качающих по ftp и ftp-proxy "уложит" роутер. Нет (с) >Насчёт pptp-proxy: >"The proper way of forwarding PPTP is to use native kernel NAT, >but it isn't always easy, feasible or even implemented properly. pptpproxy >was written for these situations." Абсолютно правильно бекоз pptp таже самая отрыжка прошлого как и ipx/spx, appletalk, но сохранять возможность использования пока еще надо. По крайней мере с l2tp таких проблем  не возникает :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	88. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Дохтур on 27-Дек-07, 23:52
	>В рассылках, до сих пор существует проблемы которые не позволяют использовать carp >и ucarp в решениях выше класса "на поигратцо", следовательно , бетта >:) а мы с вами об одном и том же говорим? я про http://tservice.net.ru/~s0mbre/old/?section=projects&item=carp >А потому как использование bgp без анализа fullview практически бессмысленно. Насчет ospf >примерно тоже - немного легче, но похоже. ну взять сеточку из одной area, 20-30 роутеров, трафик - макс. 5-6мбит. и чего тут не хватит? >я-же говорил что кесарю кесарево, нужно просто уметь находить оптимальные решения, для >каких-то вещей наиболее оптимальные выход это применения проприетарной системы на кучу >килобаксов, для другого наоборот. В этом-то все и дело, а зацикливацо >на одном варианте - есть путь ущербный и неправильный. ИМХО. а не проще тогда забыть о fw ОС общего назначения и поставить pix/netscreen/checkpoint? И вообще не заморачиваться с pf/ipfw/etc?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	101. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от BB (??) on 28-Дек-07, 10:33
	>а мы с вами об одном и том же говорим? >я про http://tservice.net.ru/~s0mbre/old/?section=projects&item=carp Да именно, не так пока еще хорошо вылизано как в исходной ОС, второе не понятна почему похерена совмесимость. It is based on OpenBSD CARP protocol but is not compatible with it since OpenBSD implementation does not contain protection against repeated message sending attack. >ну взять сеточку из одной area, 20-30 роутеров, трафик - макс. 5-6мбит. > >и чего тут не хватит? Мы про bgp или ospf ?:) > >а не проще тогда забыть о fw ОС общего назначения и поставить >pix/netscreen/checkpoint? >И вообще не заморачиваться с pf/ipfw/etc? Нет. Выбор того или иного решения должен определяться с точки зрения эффективности данного решения, а не нравицо/не нравицо.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	104. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 28-Дек-07, 11:41
	>Да именно, не так пока еще хорошо вылизано как в исходной ОС, >второе не понятна почему похерена совмесимость. >It is based on OpenBSD CARP protocol but is not compatible with >it since OpenBSD implementation does not contain protection against repeated message >sending attack. а зачем? логика работы разная, функционал - тоже. >>ну взять сеточку из одной area, 20-30 роутеров, трафик - макс. 5-6мбит. >>и чего тут не хватит? >Мы про bgp или ospf ?:) area чаще всего контексте ospf упоминается ;))) >Нет. Выбор того или иного решения должен определяться с точки зрения эффективности >данного решения, а не нравицо/не нравицо. всеми руками за.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	106. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от BB (??) on 28-Дек-07, 13:28
	>>It is based on OpenBSD CARP protocol but is not compatible with >>it since OpenBSD implementation does not contain protection against repeated message >>sending attack. > >а зачем? логика работы разная, функционал - тоже. Ну вот об этом и речь, так как сам по себе голый carp не очень-то и нужен, как я уже говорил "на поиграцо", а вот когда к нему могут привязыватся и синхронизороваться такие вещи как fw states, ipsec SA и пр. вот тогда это уже что-то серьезное получается :) >area чаще всего контексте ospf упоминается ;))) В контексте opennet приходится переспришивать уж не обижайтесь :) Я могу потдтвердить или опровергнуть потянут или нет эти балалайки такую нагрузку, но сомнения гложут. Даже если просто посчитать 6 балалаек в одной area это получается 6*(6-1)/2=30 LS на каждой. > >>Нет. Выбор того или иного решения должен определяться с точки зрения эффективности >>данного решения, а не нравицо/не нравицо. > >всеми руками за. Во-во поэтому крики что "данная ОС" мегарулез форева режет слух :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	107. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 28-Дек-07, 15:13
	>[оверквотинг удален] >>>it since OpenBSD implementation does not contain protection against repeated message >>>sending attack. >> >>а зачем? логика работы разная, функционал - тоже. > >Ну вот об этом и речь, так как сам по себе голый >carp не очень-то и нужен, как я уже говорил "на поиграцо", >а вот когда к нему могут привязыватся и синхронизороваться такие вещи >как fw states, ipsec SA и пр. вот тогда это уже >что-то серьезное получается :) дык стейты iptables синхронизируются, иначе смысла нет. Аффтар просто написал что "с pf оно несовместимо". >Во-во поэтому крики что "данная ОС" мегарулез форева режет слух :) именно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	91. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 28-Дек-07, 01:48
	>> В 2.6 ветке уже починили IP over ATM >> в недефолтных таблицах роутинга?-) > ох, опять вы про ipoatm. 2.6 в железках вроде дсл-роутеров скорее исключение > из правил.     Я не про IPoATM.     Я про Ваш предыдущий пост. Я писал, что Linux чем-то схож с Cisco -- игра "найдите ядро с несломанными фичами".     Вы сказали, что я написал бред.     Я Вам привёл опровергающий пример.     Вы отказываетесь от своих слов?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	105. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 28-Дек-07, 11:46
	>    Я про Ваш предыдущий пост. Я писал, что >Linux чем-то схож с Cisco -- игра "найдите ядро с несломанными >фичами". > >    Вы сказали, что я написал бред. > >    Я Вам привёл опровергающий пример. > >    Вы отказываетесь от своих слов? да, есть такое дело, что что-то ломают. никто от этого не застрахован.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	40. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от V.O. on 27-Дек-07, 05:04
	вопрос: а соляра (10) в этом смысле лучше/быстрее или хуже/медленнее Linux или BSD (если использовать SPARC, AMD64) тестировать буду в 08 для 100-150 бит на пакет траффика (ну вы поняли) -- интересно ваше мнение
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	44. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 09:22
	> вопрос: а соляра (10) в этом смысле лучше/быстрее или хуже/медленнее Linux или > BSD (если использовать SPARC, AMD64) тестировать буду в 08 для 100-150 > бит на пакет траффика (ну вы поняли) -- интересно ваше мнение Сложный вопрос. Как маршрутизатор, или как платформа для какого-то сервиса?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	56. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от V.O. on 27-Дек-07, 15:08
	как генератор помех на канале для тестирования в ims (те умный бридж) ЗЫ байт на пакет...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	69. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 18:14
	> как генератор помех на канале для тестирования в ims (те умный бридж) > ЗЫ байт на пакет... Я бы взял FreeBSD. На нём есть dummynet, который, собственно, для такого тестирования и был придуман -- это потом им люди шейпить стали, а Luigi, его автор, сначала называл их извращенцами, а потом смирился со своей участью. ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	55. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Алексей (??) on 27-Дек-07, 14:37
	>IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables. >Слишком много точек входа в ядро, код перегружен и глючит. >Да, PF умеет фильтровать только IP-пакеты. Про Ethernet он ничего не знает, >по MAC-адресу им не зафильтруешь. Ну и пёс с ним. Зато выдержки из man iptables    mac        --mac-source [!] address               Match   source   MAC   address.    It   must   be  of  the  form               XX:XX:XX:XX:XX:XX.  Note that this only makes sense for  packets               coming from an Ethernet device and entering the PREROUTING, FOR-               WARD or INPUT chains. >у PF есть таблицы. _Нормальные_ таблицы, обновляемые из User Land на >лету, и поиск по которым осуществляется по RADIX Tree, а не >по линейному списку. PF умеет якоря (anchors), и несколько программ, модифицирующих >правила пакетного фильтра, _никогда_ не подерутся. Так же неверная информация. Не стоит забывать, что дропать покеты с бОльшей производительностью можно с помощью iproute >Но пакетный фильтр -- это не то, за что идёт борьба на >роутере. На роутере идёт борьба за пакетную производительность. А она достигается >использованием либо ASIC'ов, либо NPU. Period. Т е вы утверждаете что пакетный фильтр слабо влияет на "пакетную производительность"? Это мягко говоря неверно 8-).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	67. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 18:08
	> выдержки из man iptables     Вы невнимательно читаете мои комментарии.     Именно это я и написал. Что PF _не_ знает ничего про L2, а NetFilter знает.     В любом случае, спасибо за документальное подтверждение моих слов. ;) > Так же неверная информация.     В смысле? У PF нет таблиц?-) pf.conf(5) Вас в этом легко разубедит. ;) > Не стоит забывать, что дропать покеты с бОльшей производительностью можно с помощью > iproute     Зачем их дропать? Задача маршрутизатора -- их не дропать. ;) >> Но пакетный фильтр -- это не то, за что идёт борьба на >> роутере. На роутере идёт борьба за пакетную производительность. А она достигается >> использованием либо ASIC'ов, либо NPU. Period. > Т е вы утверждаете что пакетный фильтр слабо влияет на "пакетную производительность"? > Это мягко говоря неверно 8-).     Как ни странно, слабо.     При правильной его настройке, конечно. Если использовать таблицы вместо линейного списка правил, использовать state filtering и ещё несколько техник, то слабо.     Безусловно, если нарисовать 10 000 "dummy"-правил фильтрации линейным списком, то пакетная производительность, мягко говоря, несколько снизится. ;)     А теперь, внимание, вопрос: а зачем так делать?-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	82. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 27-Дек-07, 21:09
	>    Безусловно, если нарисовать 10 000 "dummy"-правил фильтрации линейным >списком, то пакетная производительность, мягко говоря, несколько снизится. ;) >    А теперь, внимание, вопрос: а зачем так делать?-) сеть /22, каждому хосту в ней зарезать полосу в 1Мбит. На ipfw есть хоть динамические правила, а в pf?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	90. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 28-Дек-07, 01:40
	> сеть /22, каждому хосту в ней зарезать полосу в 1Мбит. > На ipfw есть хоть динамические правила, а в pf? А PF вообще полос не режет. Но altq спасёт отца русской демократии. :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	108. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 28-Дек-07, 15:14
	>> сеть /22, каждому хосту в ней зарезать полосу в 1Мбит. >> На ipfw есть хоть динамические правила, а в pf? > >А PF вообще полос не режет. Но altq спасёт отца русской демократии. >:) altq - часть pf ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	111. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Кирилл (??) on 29-Дек-07, 10:59
	>>> сеть /22, каждому хосту в ней зарезать полосу в 1Мбит. >>> На ipfw есть хоть динамические правила, а в pf? >> >>А PF вообще полос не режет. Но altq спасёт отца русской демократии. >>:) > >altq - часть pf ;) altq не часть pf :) Просто pf умеет с работать с очередями. Но должную функциональность должна реализовывать сетевая карта.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	113. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Кирилл (??) on 29-Дек-07, 11:29
	>> сеть /22, каждому хосту в ней зарезать полосу в 1Мбит. >> На ipfw есть хоть динамические правила, а в pf? > >А PF вообще полос не режет. Но altq спасёт отца русской демократии. >:) Вы явно подробно с PF не знакомились. PF может управлять шейпингом.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	114. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Кирилл (??) on 29-Дек-07, 11:32
	>>    Безусловно, если нарисовать 10 000 "dummy"-правил фильтрации линейным >>списком, то пакетная производительность, мягко говоря, несколько снизится. ;) >>    А теперь, внимание, вопрос: а зачем так делать?-) > >сеть /22, каждому хосту в ней зарезать полосу в 1Мбит. >На ipfw есть хоть динамические правила, а в pf? В PF есть возможно динамически изменять правила через механизм якорей. PF вообще значительное мощнее, функциональней и несколько быстрее ipfw на пользовательском уровне. На уровне ядра (через NetGraph) ipfw превосходит по производительности Pf на пользовательском уровне в разы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	110. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Кирилл (??) on 29-Дек-07, 10:53
	>[оверквотинг удален] >Слишком много точек входа в ядро, код перегружен и глючит. >Да, PF умеет фильтровать только IP-пакеты. Про Ethernet он ничего не знает, >по MAC-адресу им не зафильтруешь. Ну и пёс с ним. Зато >у PF есть таблицы. _Нормальные_ таблицы, обновляемые из User Land на >лету, и поиск по которым осуществляется по RADIX Tree, а не >по линейному списку. PF умеет якоря (anchors), и несколько программ, модифицирующих >правила пакетного фильтра, _никогда_ не подерутся. >Но пакетный фильтр -- это не то, за что идёт борьба на >роутере. На роутере идёт борьба за пакетную производительность. А она достигается >использованием либо ASIC'ов, либо NPU. Period. Знает PF об ethernet. Есть там возможность фильтровать по мас-адресам на основе политик. Возможно немного вас не допонял. Я о том?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

20. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"

Сообщение от Аноним on 26-Дек-07, 17:53

пакетный фильтр в случае ДоС как раз и спасает, особенно pf с лимитами

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

	23. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 26-Дек-07, 21:51
	>пакетный фильтр в случае ДоС как раз и спасает, >особенно pf с лимитами Особенно, когда DoS'ят Апач, вызывая динамический контент. Загрузка проца взлетает до 50-60, а лимиты всё ещё не исчерпаны. Ибо NAT'ы везде, и "задвигать" их сильно вниз некошерно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Дохтур on 26-Дек-07, 22:17
	>Особенно, когда DoS'ят Апач, вызывая динамический контент. у нормальных людей опач работает бэкэндом. А такую паразитную активность весьма просто пресечь, ограничив число входящих SYN в ед. времени экспоненциально. Чуть более сложные меры вообще исключат подобный сценарий, оставив только возможность полностью забить канал входящим трафиком(но от этого никто не застрахован).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	34. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 01:37
	>>Особенно, когда DoS'ят Апач, вызывая динамический контент. > у нормальных людей опач работает бэкэндом.     И что? Он от этого как-то сильно меньше CPU Time кушать начинает? > А такую паразитную активность весьма просто пресечь, ограничив число входящих SYN > в ед. времени экспоненциально.     Exponential Backoff в данном случае совершенно бесполезен, так как это лишь _одна из возможных реакций_ на активность с некоторого IP-адреса. Тупой сброс соединений -- это, если хотите, EB после предельного перехода. :)     Ну и что? Всё равно микропроцессор на Apache просядет. Как не выкручивайся. Потому, что не за'backoff'ить каждый конкретный IP без риска за'backoff'ить огромную сеть за NAT'ом.     А вот разговоры в ключе "ну и сами виноваты, пусть меняют провайдера" я считаю тупиковыми. > Чуть более сложные меры вообще исключат подобный сценарий, оставив только > возможность полностью забить канал входящим трафиком(но от этого никто не застрахован).     Почему, можно попытаться прогнуть апстрима на RSVP. :)))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	51. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 27-Дек-07, 10:56
	>    И что? Он от этого как-то сильно меньше >CPU Time кушать начинает? Да с cpu time не проблема. Опач обычно в prefork гоняют, так что чаще упираешься в пямять. Да и кеширование на фронтенде решает ;)) >    Ну и что? Всё равно микропроцессор на Apache >просядет. Как не выкручивайся. Потому, что не за'backoff'ить каждый конкретный IP >без риска за'backoff'ить огромную сеть за NAT'ом. Имхо, слабый DoS должен никак не сказываться на работе сервиса. А что-то более заметное будет иметь вполне очевидный профиль. И, кстати, борьба с DoS - это всегда компромисс и риск false positives. >    А вот разговоры в ключе "ну и сами >виноваты, пусть меняют провайдера" я считаю тупиковыми. +1 PS: спасибо за адекватную и достаточно сдержанную дискуссию.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	68. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 18:13
	>> И что? Он от этого как-то сильно меньше CPU Time кушать начинает? > Да с cpu time не проблема. Опач обычно в prefork гоняют, так > что чаще упираешься в пямять.     Согласен. > Да и кеширование на фронтенде решает ;))     Далеко не всегда.     В большинстве случаев, с которыми мне приходилось встречаться, Web-код написан, прямо скажем, не очень хорошо. Не сказать жёстче: руки бы повырывать. ;) И "агрессивное" кэширование приводит к появлению stale pages. А "кооперативное" кэширование на фронтэнде при помощи какого-нибудь memcached ещё в Web-код встраивать надо, а в плохой код его встроить просто невозможно. > Имхо, слабый DoS должен никак не сказываться на работе сервиса. А что-то > более заметное будет иметь вполне очевидный профиль. И, кстати, борьба с > DoS - это всегда компромисс и риск false positives.     Равно, как и борьба со спамом. Подписываюсь под каждым словом.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	41. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Nikolay (??) on 27-Дек-07, 05:29
	Пакетный фильтр вас не спасет при DOS-е службы. Уж слишком низкий может оказаться порог для дос аткаки. Обычный index.php какого-нибудь треклятого форумного движка может быть целеноправленно атакован сравнительно небольшим количеством запросом и ваш фильтр даже не сможет выделить эти аномалии из фона, а апач будет буксовать глотая последние мегабайты свопа.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	45. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 09:23
	> Обычный index.php какого-нибудь треклятого форумного движка     index.php ещё, как правило, переживаемо. А вот index.pl может уже на 50 запросах/сек ТА-А-А-АК раскорячить Apache... :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	47. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 27-Дек-07, 10:17
	ОФФ: Andrew Kolchoogin, респект за грамотную дискуссию. Кое-что "открыл" для себя, что следовало бы знать уже лет 8 как, чьорт побьери. Век живи - век учись! :-) Побольше бы таких участников конференций. Может, и с квалификацией кадров получше стало бы? :-) PS Просьба не обращать внимания на профессиональных флеймогонов - это единственное, что они знают толком.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	54. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от гость on 27-Дек-07, 12:16
	>ОФФ: Andrew Kolchoogin, респект за грамотную дискуссию. Кое-что "открыл" для себя, что >следовало бы знать уже лет 8 как, чьорт побьери. Век живи >- век учись! :-) >Побольше бы таких участников конференций. Может, и с квалификацией кадров получше стало >бы? :-) >PS Просьба не обращать внимания на профессиональных флеймогонов - это единственное, что >они знают толком. Андрюша, хватит уже отвешивать себе комплименты с помощью виртуалов - смотреть противно! Так и до дурки не далеко...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	66. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 27-Дек-07, 18:05
	>Андрюша, хватит уже отвешивать себе комплименты с помощью виртуалов - смотреть противно! Так и до дурки не далеко... гоЗть - хорош трепаться - санитары идут! ,) Ну а по теме - молодец Андрей. А ты - ламо ,) Причем знаешь об этом от того и сопли-слюни агресивность ,)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	52. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Antrew (??) on 27-Дек-07, 11:21
	>> Обычный index.php какого-нибудь треклятого форумного движка > >    index.php ещё, как правило, переживаемо. А вот index.pl >может уже на 50 запросах/сек ТА-А-А-АК раскорячить Apache... :) Не надо наезжать на Perl, ибо связка mod_perl + Apache дает очень хорошую производительность.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	71. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 18:29
	> Не надо наезжать на Perl, ибо связка mod_perl + Apache дает очень > хорошую производительность.     Упаси меня Ларри наезжать на Perl. Просто PHP-интерпретатор легче перлового.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	99. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Nick (??) on 28-Дек-07, 09:36
	впику Вашей нелюбви к Netfilter проблема: DoS на вебсервис и границы синов далеки до реакции, а апач, как выше выразилиьсь, доедает своп... Что делать BSD админу - неизвестно. А вот в Линухе проблема имеет вид даже некоторого решения. Пишеться модуль, который в зависимости от нагрузки на CPU и/или винта и/или память, принимает или дропает пакет, собирается для текущего ядра и загружается в него. Аналогичный модуль-собрат пишется и для user-level iptables тулзы. Все границы/лимиты задаются параметрами этого user-level модуля из команды iptables. Зависимость на род нагрузки исчезает. Это может быть сколь угодно плохой и неоптимальный пользовательский код. В результате: можно вести разговор о дропе новых соединений, если загрузка системы и/или этих 3-х подсистем выше заданной. А также, совмещать эти лимиты с другими сетевыми ограничениями. На практике получается более чем красивое и элегантное решение. Например: в зависимости от нагрузки (уровни нагрузки: 5-10, 10-20, 20-30...) регулируется количество одновременных коннектов из /24 сетки (например: 50, 30, 10...). И даже глубина битности измеряемых сетей: /24, /25, /26.... В результате имеем более равномерное распределение мощностей системы между клиентами в условиях DoS'a. Чем бы порадовал PF?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	102. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от pavel_simple (ok) on 28-Дек-07, 10:37
	могу ошибаться -- но как мне думается тут и писать ничего не придётся проблему можно будет решить например так несколько recent (в зависимости от нагрузки) соответственным образом помечают пакет (-j MARK) а потом в зависимости от марки используем limit
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	109. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 28-Дек-07, 21:42
	дописать модуль к тому же apache, чтоб он рулил этой политикой, тогда можно хоть электрическим реле провода размыкать. это ниразу не дело ядра.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	119. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Nick (??) on 30-Дек-07, 23:40
	кроме апача источников нагрузки бывает немало
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	118. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от nuclight on 30-Дек-07, 22:42
	Ой, и вы ЭТО называете красивым и элегантным решением?! Это же жуткий костыль. Начать с того, что следует организовывать вообще схему фронтенд/бэкенд (необязательно на одной машине). Если уж у вас такие DoS'ы, с которыми справляется ядро. Далее, писать модуль ядра для отслеживания загрузки чего-то в юзерлэнде - это криво. Такие вещи следует в юзерлэнде же и отрабатывать, выдавая команду файрволу, который, кстати, может находиться на другой машине, равно как и анализатор (на сервере же только датчики). В ядре отслеживать, что конкретно не нравится процессу - слишком сложно. Наконец, когда решением предлагается _написать_ модуль ядра (!) - тут уже лицемерно говорить, что в одной ОСи это можно сделать, в другой нет - специалист, на такое способный, сделает для любой, средства есть. Другое дело, что это может быть невозможно даже при наличии специалиста - например, когда ДДОСили bash.org.ru, они не имели возможность поменять на машине netfilter на nf-hipac - тупо из-за VDS (решили доморощенным аналогом). Да, хостер был плохой (потом сменили), да, отслеживание и перекрытие DoS'ов вообще задача хостера, ну вот такие были условия, что поделать... Отсюда, кстати, видно, что предложенный к написанию модуль тем более хуже - сыграет на руку DDoS'у, дропая, возможно, вполне легитимные коннекты - не те критерии ибо.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	120. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Nick (??) on 30-Дек-07, 23:57
	>Ой, и вы ЭТО называете красивым и элегантным решением?! Угу >Это же жуткий >костыль. Начать с того, что следует организовывать вообще схему фронтенд/бэкенд (необязательно >на одной машине). Если уж у вас такие DoS'ы, с которыми >справляется ядро. кому следует орагнизовывать схему - тот организовывает схему. А кому следует не принимать новый запрос в систему если загрузка выше нормы - тот не принимает запрос. >Далее, писать модуль ядра для отслеживания загрузки чего-то в юзерлэнде - это >криво. загрузка системы пока что понятие одно на систему. А не на ядро или на юзерлевел. "загрузки чего-то в юзерлэнде" звучит неразумно. >Такие вещи следует в юзерлэнде же и отрабатывать, вообще неразумно. Управлять user-level'ом из него же - ненадежно. >выдавая команду файрволу, который, кстати, может находиться на другой машине, равно как и >анализатор (на сервере же только датчики). о какой команде ФАЕРВОЛУ идет речь? Мне кажеться Вы не уловили суть в принципе... >В ядре отслеживать, что конкретно >не нравится процессу - слишком сложно. :)) улыбнуло. Вообще-то это и есть задача ядра: отслеживать все что кому нравится и что нет. Наиболее эффективно управлять как минимум траффиком и процессами - из ядра. >Наконец, когда решением предлагается _написать_ модуль ядра (!) - тут уже лицемерно >говорить, что в одной ОСи это можно сделать, в другой нет предполагается отсутствие даунтайма на загрузкку нового ядра. Netfiler модуль вставляется находу. Если PF умеет это же - тогда все описанное может и он. Собственно, в этом был вопрос. >- специалист, на такое способный, сделает для любой, средства есть. неспециалист сидит дома или учится >Другое дело, что это может быть невозможно даже при наличии специалиста - >например, когда ДДОСили bash.org.ru, они не имели возможность поменять на машине >netfilter на nf-hipac - тупо из-за VDS (решили доморощенным аналогом). >Да, хостер был плохой (потом сменили), да, отслеживание и перекрытие DoS'ов вообще задача хостера дык, под такой проект, ессьно, нужен лишь выделенный сервер с возможностью менять в системе по желанию что угодно. >Отсюда, кстати, видно, что предложенный к написанию модуль тем более хуже - >сыграет на руку DDoS'у, дропая, возможно, вполне легитимные коннекты - не >те критерии ибо. расширьте сознание. Предлагаемый модуль НЕ дропает ничего. Он умеет отслеживать загрузку. И именно в связке с другими методами ограничения дает неплохие результаты.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

57. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"

Сообщение от KdF (??) on 27-Дек-07, 15:17

Наш новый гуру нам все объяснил! Как же он смог подняться на такие высоты? После небольшого поиска все встало на свои места: http://www.behigh.org/drugs/substances/parkopan/overview.html Видим ниже Andrew Kolchoogin 2:5020/118.22 Thu 06 Apr 95 19:54 Это давно, всерьез и похоже навсегда.

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

	59. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Аноним on 27-Дек-07, 17:36
	Извините за оффтоп, но ві такими выпадами похожи на журналиста желтой прессы, который вместо веских аргументов кричит "Ба, да он же пидар (наркоман, алкоголик, нужное подчеркнуть)".))))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	64. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 18:01
	> Извините за оффтоп, но ві такими выпадами похожи на журналиста желтой прессы, > который вместо веских аргументов кричит "Ба, да он же пидар (наркоман, > алкоголик, нужное подчеркнуть)".)))) Да хоть всё сразу. :) Мне приятно ощущать свою уникальность в антиобщественности. Только вот какая незадача: гугл индексирует и этот сайт, и этот форум. И когда-нибудь кто-нибудь попытается поискать опусы этих граждан, и что он найдёт?-) Не рой другому яму -- пусть сам роет. ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	78. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от KdF (??) on 27-Дек-07, 21:02
	Может быть я и есть журналист желтой прессы, откуда вам знать? А завтра напишу статью "Сисадмины-наркоманы идут на город" или "Величие и позор русской школы системного администрирования". Что касается непосредственно темы, то я это просто ради интереса посмотрел, чтобы понимать, с кем имею дело, когда хотел вступить в дискуссию по вопросу. Учитывая безапелляционный тон и однобокую аргументацию данного участника дискуссии желание вступать  в нее пропало, да тем и лучше, ибо в споре, как известно, никакой истины нет, а есть только ересь и отстаивание собственных заведомо верных точек зрения. Ну а запостил я так, шутки ради, очень уж смешным мне это показалось.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	63. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 18:00
	> Видим ниже > Andrew Kolchoogin 2:5020/118.22 Thu 06 Apr 95 19:54 > > Это давно, всерьез и похоже навсегда. Кроме IT, в мире есть ещё много увлекательных наук. Химия, например. Или математика. А с компактными (то есть, с замкнутыми и ограниченными) людьми на OpenNet'е мне встречаться крайне странно. ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

58. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"

Сообщение от Mikhail (??) on 27-Дек-07, 17:01

KdF, спасибо посмеялся. Гугл очень силен =) Хочется вериться, что Andrew Kolchoogin все таки находиться в трезвом уме по понедельникам. Andrew Kolchoogin, спасибо за комментарии.

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

	65. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 27-Дек-07, 18:03
	> KdF, спасибо посмеялся. Гугл очень силен =)     Да, Гугль про меня много разного рассказывает. :) > Хочется вериться, что Andrew Kolchoogin все таки находиться в трезвом уме по > понедельникам.     Абсолютно. Химия и физиология психотомиметиков перестала меня интересовать примерно лет восемь назад.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	79. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от sash (??) on 27-Дек-07, 21:03
	Замечательная дискуссия. Андрей - вопрос, если можно: "Где учат" кошерной работе с пакетными фильтрами? На самом деле интересует "идеология". Ответ может выглядеть так: средства отладки такие-то, best-practice вот такая-то и т.д. Почитав Ваши посты про ускорение работы ПФ узнал несколько новых подходов в написанию правил, очень забавно. :) Система может получиться очень красивой.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	93. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 28-Дек-07, 01:51
	> Андрей - вопрос, если можно: > > "Где учат" кошерной работе с пакетными фильтрами? На самом деле интересует "идеология".     Да вот, здесь, на OpenNet'е. Если, конечно, отфильтровывать гон от дискуссий. > Ответ может выглядеть так: средства отладки такие-то, best-practice вот такая-то и т.д.     Если бы всё было так просто... ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	80. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от sash (??) on 27-Дек-07, 21:05
	И еще вопрос: Вы действительно где-то используете RSVP?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	94. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"
	Сообщение от Andrew Kolchoogin on 28-Дек-07, 01:51
	> Вы действительно где-то используете RSVP?     Нет, конечно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

92. "OpenNews: Новая версия пакетного фильтра для Linux - iptable..."

Сообщение от yurii (??) on 28-Дек-07, 01:48

мда, виртуальные интерфейсы по прежнему не поддерживаются.

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

	100. "OpenNews: Новая версия пакетного фильтра для Linux - iptable..."
	Сообщение от Nick (??) on 28-Дек-07, 09:39
	>мда, виртуальные интерфейсы по прежнему не поддерживаются. пардон поясните что именно не поддерживается?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	121. "OpenNews: Новая версия пакетного фильтра для Linux - iptable..."
	Сообщение от я on 09-Янв-08, 13:09
	видимо он имел ввиду отсутствие возможности написать iptables ... -i eth1:1 ...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	122. "OpenNews: Новая версия пакетного фильтра для Linux - iptable..."
	Сообщение от Nick (??) on 09-Янв-08, 15:54
	>видимо он имел ввиду отсутствие возможности написать iptables ... -i eth1:1 ... а... ну так это ж не отдельный интерфейс, и даже не виртуальный :) это просто label для алиаса, не более. За сим -i eth1 == -i eth1:500
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]