forum.opennet.ru

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

Оглавление

OpenNews: Новая версия пакетного фильтра для Linux - iptables 1.4.0, opennews (??), 26-Дек-07, (0) [смотреть все]

ключ -table в iptables-restore недавно нужен был, ток подумал и тут новость , valfrom (?), 14:30 , 26-Дек-07, (4)
есть слова с pf не сравнится , V (??), 14:48 , 26-Дек-07, (6) //

Embedded-системы -- вообще беседа отдельная Строго говоря, для них и BSD, и Lin, Andrew Kolchoogin (?), 15:21 , 26-Дек-07, (9)

Спасибо, нормально объяснили По-больше б таких камментов на ОпенНете, fresco (??), 15:29 , 26-Дек-07, (10)
да, спасибо Интересно, почему под Линь только iptables А под бсд столько мног, sHaggY_caT (??), 15:43 , 26-Дек-07, (11)

Это неправда Есть порт IP Filter под Linux Потому, что они изначально н, Andrew Kolchoogin (?), 16:08 , 26-Дек-07, (13)

Это тот, который IP filter - IP chains - IP tables , Ананимуз (?), 16:54 , 26-Дек-07, (17)

Благородный дон не понимает разницы между IP Filter и ipfwadm - , Andrew Kolchoogin (?), 17:10 , 26-Дек-07, (18)

Ааа Это про тот IPFilter, который ipf и пишется слитно , Ананимуз (?), 22:52 , 26-Дек-07, (27)

Благородный дон не потрудится ли посетить http coombs anu edu au avalon и уб, Andrew Kolchoogin (?), 01:30 , 27-Дек-07, (33)

Не совсем понял какое отношение это имеет к вопросу о мне показалось что вы гово, demimurych (?), 15:45 , 26-Дек-07, (12)

Дело в том, что на домашних роутерах стоит одна задача -- удешевления И поэ, Andrew Kolchoogin (?), 16:11 , 26-Дек-07, (14)

Сейчас железки без MMU - скорее экзотика Если лучше, то почему куда ни плюнь в , Аноним (-), 16:27 , 26-Дек-07, (15)

Да ладно уж, экзотика Xscale далеко не везде Я обычно в VXWorks и его д, Andrew Kolchoogin (?), 16:49 , 26-Дек-07, (16)

ну 100kpps вполне реально получить на половине fast ethernet , Аноним (-), 17:29 , 26-Дек-07, (19)

Так сейчас так, втупую, никто не DoS ит микропроцессоры стали достаточно быстры, Andrew Kolchoogin (?), 21:53 , 26-Дек-07, (24)

ага, но остались ОС, в которых нет polling и которым от относительно небольших з, Аноним (-), 10:20 , 27-Дек-07, (48)

Ну, в эпоху PCI Express и даже PCI с Message-signalled Interrupts это уже мало, Andrew Kolchoogin (?), 17:46 , 27-Дек-07, (60)

Ой Шо, таки уже убрали один глобальный лок на весь PF Пока что на тестах файр, nuclight (?), 22:18 , 30-Дек-07, (115)

gt оверквотинг удален Насчет SMP можно медленнее и подробнее Ксеоны 3 4 одн, routerSMP (?), 20:38 , 17-Янв-08, (123)

Прочитал сие и сразу средце екнуло неужели к нам сам Rusty Russell заглянул, ли, Sampan (?), 21:43 , 26-Дек-07, (21)

gt оверквотинг удален Аналог scrub и modulate state у iptables в студию , Andrew Kolchoogin (?), 21:48 , 26-Дек-07, (22)

Скажите, а часто вы на интенсивном трафике пользуетесь scrub state modulation , Дохтур (?), 22:11 , 26-Дек-07, (25)

Стоять Вопрос был в возможностях пакетных фильтров Так что не надо увиливать А, Andrew Kolchoogin (?), 01:28 , 27-Дек-07, (32)

вы же прекрасно понимаете что прямых аналогов нет часть функционала есть в штатн, Аноним (-), 10:42 , 27-Дек-07, (49)

Ну тогда и не надо кричать Надо уметь честно признаваться, что у нас вот э, Andrew Kolchoogin (?), 17:56 , 27-Дек-07, (61)

Ооох заглянем в в man http www freebsd org cgi man cgi query pf conf apropo, Аноним (-), 20:50 , 27-Дек-07, (76)

кесарю кесарево знаете-линюхач snort snortsamМожет см выше, BB (??), 21:01 , 27-Дек-07, (77)
снорт даст куда большую нагрузку на cpu Хотя бы потому что ему придётся слушать, Аноним (-), 21:15 , 27-Дек-07, (83)
Ох, ну ведь можно-же хоть иногда думать на шаг вперед,а не воспринимать все в ло, BB (??), 22:08 , 27-Дек-07, (85)
вы алерты откуда получать будете С сенсоров В любом случае сенсоры должны мони, Дохтур (?), 23:34 , 27-Дек-07, (87)
Он не свобеобразный, а вполне себе обычный язык tcpdump Который уже и так обяза, nuclight (?), 22:29 , 30-Дек-07, (117)

Если фильтровать на уровне ядра через узлы NetGraph а ipfw имеет свои узлы , ск, Кирилл (??), 11:06 , 29-Дек-07, (112)

Кстати, passive os fingerprinting в iptables поддерживается модулем OSF OS fing, Анонимус (?), 00:30 , 28-Дек-07, (89)
Есть патч для ipfw емнип, даже в базе PRов И он и без патча уже может матчить, nuclight (?), 22:20 , 30-Дек-07, (116)

http ozlabs org rusty index cgi 2006 08 15no scrubbing, but we do fragment re, s_dog (??), 01:05 , 27-Дек-07, (31)

Я ж просил аналоги вполне конкретных вещей scrub и modulate state И где он, Andrew Kolchoogin (?), 01:49 , 27-Дек-07, (36)

Вобщем-то, правильно сказали выше Некорректно требовать именно аналога вот этой, Nick (??), 08:55 , 28-Дек-07, (98)

Тоже знаю Ринет и знаю, подтверждаю, что там циски, но фрю там любят Не рекламы, SunTech (?), 18:54 , 27-Дек-07, (72)

gt оверквотинг удален что вы плетёте какие 800 Гб - это 25 Гб в деньповерьт, Redacid (??), 22:13 , 27-Дек-07, (86)

Издеваетесь, коллега - Там только на инфраструктуру MSK-IX гигабит , Andrew Kolchoogin (?), 01:58 , 28-Дек-07, (96)

Вообще-то я имел ввиду ширину внешних каналлов, но не в этом суть Это всего лиш, Redacid (??), 08:03 , 28-Дек-07, (97)

Без обид, но это первый признак непрофессионализма - исходить из личных предпочт, Аноним (-), 11:37 , 28-Дек-07, (103)

Это потрясающе - мало того, что сам нифига не знает, дык ещё и других поучать бе, guest (??), 23:43 , 26-Дек-07, (28)

Ну вот опять Только дин думающий и вменяемый человек на опеннете высказался, ка, klez (??), 23:59 , 26-Дек-07, (29)

Высказался может и правильно да вот только ИМХО не объективно, pavel_simple (ok), 00:09 , 27-Дек-07, (30)

На OpenNet е высказываются почти никогда не объективно объективность _может_ бы, Andrew Kolchoogin (?), 01:52 , 27-Дек-07, (37)

Ну, я человек без комплексов, ФСБ не боюсь, так что подписываюсь везде и всегда , Andrew Kolchoogin (?), 09:25 , 27-Дек-07, (46)

Гражданин, OpenNet -- не место, где показывают свои комплексы Во-первых,, Andrew Kolchoogin (?), 01:47 , 27-Дек-07, (35)

При админе-эникейщике все пофиг - все равно работать не будет Странно, а у меня , Аноним (38), 02:15 , 27-Дек-07, (38)

Безусловно Всё, что один человек сделал, другой завсегда сломать может , Andrew Kolchoogin (?), 09:18 , 27-Дек-07, (42)

em, bge в 6ке или это драйвера, не считается , Аноним (-), 10:46 , 27-Дек-07, (50)

У меня 6 ка с em работает два года, и ничего там не ломается Что я делаю не та, Andrew Kolchoogin (?), 17:57 , 27-Дек-07, (62)

т е то что творилось в freebsd-net freebsd-current перед выпуском 6 2 - это г, Аноним (-), 19:51 , 27-Дек-07, (73)

А, это про импорт и откаты Так это же _перед_ выпуском Вы бы почитали -current , Andrew Kolchoogin (?), 01:53 , 28-Дек-07, (95)

имеется ввиду, что он у вас core router ЗЫ постинги на редкость осмысленные для , V.O. (?), 04:52 , 27-Дек-07, (39)

Не у меня, у tvoe tv Да, MPLS Core сделан на нескольких 7604 х У меня core, Andrew Kolchoogin (?), 09:21 , 27-Дек-07, (43)

Так, теперь ещё и ядро с дистрибутивом путаем вообще красота Ядро и базовые б, гость (?), 12:12 , 27-Дек-07, (53)

Извините, у нас принято говорить про работающую платформу Или ядро Линук, Andrew Kolchoogin (?), 18:27 , 27-Дек-07, (70)

да Андрей, вы же вроде адекватный человек А давайте туда постгрес с 50гиговой , Аноним (-), 20:04 , 27-Дек-07, (74)

Это как сказать, где-то умеет, с использованием мегахаков , а где то нет Есть , BB (??), 20:46 , 27-Дек-07, (75)

насчёт беты вы где прочитали зачем домашнему роутеру принимать fullview ospf с , Аноним (-), 21:06 , 27-Дек-07, (81)

В рассылках, до сих пор существует проблемы которые не позволяют использовать ca, BB (??), 22:01 , 27-Дек-07, (84)
а мы с вами об одном и том же говорим я про http tservice net ru s0mbre old , Дохтур (?), 23:52 , 27-Дек-07, (88)
Да именно, не так пока еще хорошо вылизано как в исходной ОС, второе не понятна , BB (??), 10:33 , 28-Дек-07, (101)
а зачем логика работы разная, функционал - тоже area чаще всего контексте ospf , Аноним (-), 11:41 , 28-Дек-07, (104)
Ну вот об этом и речь, так как сам по себе голый carp не очень-то и нужен, как я, BB (??), 13:28 , 28-Дек-07, (106)
gt оверквотинг удален дык стейты iptables синхронизируются, иначе смысла нет А, Аноним (-), 15:13 , 28-Дек-07, (107)

Я не про IPoATM Я про Ваш предыдущий пост Я писал, что Linux чем-то схо, Andrew Kolchoogin (?), 01:48 , 28-Дек-07, (91)

да, есть такое дело, что что-то ломают никто от этого не застрахован , Аноним (-), 11:46 , 28-Дек-07, (105)

вопрос а соляра 10 в этом смысле лучше быстрее или хуже медленнее Linux или B, V.O. (?), 05:04 , 27-Дек-07, (40)

Сложный вопрос Как маршрутизатор, или как платформа для какого-то сервиса , Andrew Kolchoogin (?), 09:22 , 27-Дек-07, (44)

как генератор помех на канале для тестирования в ims те умный бридж ЗЫ байт на , V.O. (?), 15:08 , 27-Дек-07, (56)

Я бы взял FreeBSD На нём есть dummynet, который, собственно, для такого тестиро, Andrew Kolchoogin (?), 18:14 , 27-Дек-07, (69)

выдержки из man iptables mac --mac-source address Match, Алексей (??), 14:37 , 27-Дек-07, (55)

Вы невнимательно читаете мои комментарии Именно это я и написал Что PF , Andrew Kolchoogin (?), 18:08 , 27-Дек-07, (67)

сеть 22, каждому хосту в ней зарезать полосу в 1Мбит На ipfw есть хоть динамиче, Аноним (-), 21:09 , 27-Дек-07, (82)

А PF вообще полос не режет Но altq спасёт отца русской демократии , Andrew Kolchoogin (?), 01:40 , 28-Дек-07, (90)

altq - часть pf , Аноним (-), 15:14 , 28-Дек-07, (108)

altq не часть pf Просто pf умеет с работать с очередями Но должную функциона, Кирилл (??), 10:59 , 29-Дек-07, (111)

Вы явно подробно с PF не знакомились PF может управлять шейпингом , Кирилл (??), 11:29 , 29-Дек-07, (113)

В PF есть возможно динамически изменять правила через механизм якорей PF вообще, Кирилл (??), 11:32 , 29-Дек-07, (114)

gt оверквотинг удален Знает PF об ethernet Есть там возможность фильтровать п, Кирилл (??), 10:53 , 29-Дек-07, (110)

пакетный фильтр в случае ДоС как раз и спасает,особенно pf с лимитами , Аноним (38), 17:53 , 26-Дек-07, (20) //

Особенно, когда DoS ят Апач, вызывая динамический контент Загрузка проца взлета, Andrew Kolchoogin (?), 21:51 , 26-Дек-07, (23) //

у нормальных людей опач работает бэкэндом А такую паразитную активность весьма , Дохтур (?), 22:17 , 26-Дек-07, (26) //

И что Он от этого как-то сильно меньше CPU Time кушать начинает Exponen, Andrew Kolchoogin (?), 01:37 , 27-Дек-07, (34)

Да с cpu time не проблема Опач обычно в prefork гоняют, так что чаще упираешься, Аноним (-), 10:56 , 27-Дек-07, (51)

Согласен Далеко не всегда В большинстве случаев, с которыми мне прих, Andrew Kolchoogin (?), 18:13 , 27-Дек-07, (68)

Пакетный фильтр вас не спасет при DOS-е службы Уж слишком низкий может оказатьс, Nikolay (??), 05:29 , 27-Дек-07, (41)

index php ещё, как правило, переживаемо А вот index pl может уже на 50 запр, Andrew Kolchoogin (?), 09:23 , 27-Дек-07, (45)

ОФФ Andrew Kolchoogin, респект за грамотную дискуссию Кое-что открыл для себ, Аноним (38), 10:17 , 27-Дек-07, (47)

Андрюша, хватит уже отвешивать себе комплименты с помощью виртуалов - смотреть п, гость (?), 12:16 , 27-Дек-07, (54)

Так и до дурки не далеко гоЗть - хорош трепаться - санитары идут , Ну а по те, Аноним (38), 18:05 , 27-Дек-07, (66)

Не надо наезжать на Perl, ибо связка mod_perl Apache дает очень хорошую произв, Antrew (??), 11:21 , 27-Дек-07, (52)

Упаси меня Ларри наезжать на Perl Просто PHP-интерпретатор легче перлового , Andrew Kolchoogin (?), 18:29 , 27-Дек-07, (71)

впику Вашей нелюбви к Netfilterпроблема DoS на вебсервис и границы синов далеки, Nick (??), 09:36 , 28-Дек-07, (99)

могу ошибаться -- но как мне думается тут и писать ничего не придётсяпроблему мо, pavel_simple (ok), 10:37 , 28-Дек-07, (102)
дописать модуль к тому же apache, чтоб он рулил этой политикой, тогда можно хоть, Аноним (-), 21:42 , 28-Дек-07, (109)

кроме апача источников нагрузки бывает немало, Nick (??), 23:40 , 30-Дек-07, (119)

Ой, и вы ЭТО называете красивым и элегантным решением Это же жуткий костыль Н, nuclight (?), 22:42 , 30-Дек-07, (118)

Угукому следует орагнизовывать схему - тот организовывает схему А кому следует н, Nick (??), 23:57 , 30-Дек-07, (120)

Наш новый гуру нам все объяснил Как же он смог подняться на такие высоты После , KdF (??), 15:17 , 27-Дек-07, (57) //

Извините за оффтоп, но в 1110 такими выпадами похожи на журналиста желтой прес, Аноним (-), 17:36 , 27-Дек-07, (59) //

Да хоть всё сразу Мне приятно ощущать свою уникальность в антиобщественности, Andrew Kolchoogin (?), 18:01 , 27-Дек-07, (64)
Может быть я и есть журналист желтой прессы, откуда вам знать А завтра напишу ст, KdF (??), 21:02 , 27-Дек-07, (78)

Кроме IT, в мире есть ещё много увлекательных наук Химия, например Или математ, Andrew Kolchoogin (?), 18:00 , 27-Дек-07, (63)

KdF, спасибо посмеялся Гугл очень силен Хочется вериться, что Andrew Kolchoog, Mikhail (??), 17:01 , 27-Дек-07, (58) //

Да, Гугль про меня много разного рассказывает Абсолютно Химия и физи, Andrew Kolchoogin (?), 18:03 , 27-Дек-07, (65) //

Замечательная дискуссия Андрей - вопрос, если можно Где учат кошерной работе с, sash (??), 21:03 , 27-Дек-07, (79) //

Да вот, здесь, на OpenNet е Если, конечно, отфильтровывать гон от дискуссий, Andrew Kolchoogin (?), 01:51 , 28-Дек-07, (93)

И еще вопрос Вы действительно где-то используете RSVP , sash (??), 21:05 , 27-Дек-07, (80) //

Нет, конечно , Andrew Kolchoogin (?), 01:51 , 28-Дек-07, (94)

мда, виртуальные интерфейсы по прежнему не поддерживаются , yurii (??), 01:48 , 28-Дек-07, (92) //

пардонпоясните что именно не поддерживается , Nick (??), 09:39 , 28-Дек-07, (100) //

видимо он имел ввиду отсутствие возможности написать iptables -i eth1 1 , я (?), 13:09 , 09-Янв-08, (121) //

а ну так это ж не отдельный интерфейс, и даже не виртуальный это просто labe, Nick (??), 15:54 , 09-Янв-08, (122)

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

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

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

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

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

Часть нити удалена модератором

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

Сообщение от Andrew Kolchoogin (?), 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 (??), 26-Дек-07, 15:29

Спасибо, нормально объяснили. По-больше б таких камментов на ОпенНете

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

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

Сообщение от sHaggY_caT (??), 26-Дек-07, 15:43

да, спасибо...
Интересно, почему под Линь только iptables?
А под бсд столько много фильтров?
Кстати, у Солярки есть API для пакетных фильтров?

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

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

Сообщение от Andrew Kolchoogin (?), 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" +/–

Сообщение от Ананимуз (?), 26-Дек-07, 16:54

> да, спасибо...
> Интересно, почему под Линь только iptables?
> Это неправда. Есть порт IP Filter под Linux.
Это тот, который IP filter -> IP chains -> IP tables?

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

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

Сообщение от Andrew Kolchoogin (?), 26-Дек-07, 17:10

Благородный дон не понимает разницы между IP Filter и ipfwadm?-)

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

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

Сообщение от Ананимуз (?), 26-Дек-07, 22:52

Ааа... Это про тот IPFilter, который ipf и пишется слитно?

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

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

Сообщение от Andrew Kolchoogin (?), 27-Дек-07, 01:30

> Ааа... Это про тот IPFilter, который ipf и пишется слитно?
Благородный дон не потрудится ли посетить http://coombs.anu.edu.au/~avalon/ и убедиться, что "IP Filter" пишется раздельно? Прям первая строчка на странице...

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

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

Сообщение от demimurych (?), 26-Дек-07, 15:45

>> На мини-роутерах (aka домашний D-link) таки рулит бсд, или, линь?
>
>Embedded-системы -- вообще беседа отдельная. Строго говоря, для них и BSD, и
>Linux одинаково плохи.
>Дело в том, что и Linux, и *BSD разрабатывались для машин с
>MMU. Нет, безусловно, и Linux, и BSD _в теории_ могут работать
Не совсем понял какое отношение это имеет к вопросу о
>> На мини-роутерах (aka домашний D-link) таки рулит бсд, или, линь?
мне показалось что вы говорили о задачах где решаются вопросы с сколько нибудь значимым трафиком а не в условиях "доманего" использования. Поправьте меня где я ошибся.

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

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

Сообщение от Andrew Kolchoogin (?), 26-Дек-07, 16:11

> Не совсем понял какое отношение это имеет к вопросу о
>>> На мини-роутерах (aka домашний D-link) таки рулит бсд, или, линь?
> мне показалось что вы говорили о задачах где решаются вопросы с сколько
> нибудь значимым трафиком а не в условиях "доманего" использования. Поправьте меня
> где я ошибся.
    Дело в том, что на домашних роутерах стоит одна задача -- удешевления. И поэтому там ставят настолько слабое железо, насколько это вообще возможно. И при таком раскладе вопрос, так сказать, "профпригодности" данной конкретной операционки выходит на первый план.
    Ситуация примерно такая же, как и со смартфонами -- там ставят настолько слабый микропроцессор, насколько это вообще возможно, иначе не добиться сколь-нибудь разумного мобильного ресурса.
    Никто не хочет заряжать батарею мобилки раз в 8-10 часов.
    Никто не хочет платить за домашний роутер $300. Даже $300. Не говоря уже о большей сумме.

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

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

Сообщение от Аноним (-), 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 ничем не поможет.

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

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

Сообщение от Andrew Kolchoogin (?), 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" +/–

Сообщение от Аноним (-), 26-Дек-07, 17:29

>    Пакетный фильтр в случае DoS не поможет, будь
>он хоть сто раз скалируемый. :)
ну 100kpps вполне реально получить на половине fast ethernet.

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

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

Сообщение от Andrew Kolchoogin (?), 26-Дек-07, 21:53

>>    Пакетный фильтр в случае DoS не поможет, будь
>>он хоть сто раз скалируемый. :)
>
>ну 100kpps вполне реально получить на половине fast ethernet.
Так сейчас так, втупую, никто не DoS'ит: микропроцессоры стали достаточно быстрыми для того, чтобы не заметить какие-то там 100 kpps. Хуже, когда DoS'ят целенаправленно сервис.

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

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

Сообщение от Аноним (-), 27-Дек-07, 10:20

>Так сейчас так, втупую, никто не DoS'ит: микропроцессоры стали достаточно быстрыми для
>того, чтобы не заметить какие-то там 100 kpps. Хуже, когда DoS'ят
>целенаправленно сервис.
ага, но остались ОС, в которых нет polling и которым от относительно небольших значений kpps становится плохо ;)

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

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

Сообщение от Andrew Kolchoogin (?), 27-Дек-07, 17:46

> ага, но остались ОС, в которых нет polling и которым от относительно
> небольших значений kpps становится плохо ;)
Ну, в эпоху PCI Express (и даже PCI с Message-signalled Interrupts) это уже малоактуально. Да и сама идея MSI значительно более, так сказать, "пряма", нежели поллинг.

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

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

Сообщение от nuclight (?), 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, в среднем раза в полтора.

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

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

Сообщение от routerSMP (?), 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

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

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

Сообщение от Sampan (?), 26-Дек-07, 21:43

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

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

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

Сообщение от Andrew Kolchoogin (?), 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" +/–

Сообщение от Дохтур (?), 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 (?), 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" +/–

Сообщение от Аноним (-), 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 (?), 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" +/–

Сообщение от Аноним (-), 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 (??), 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" +/–

Сообщение от Аноним (-), 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 (??), 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-узел, который займется именно этим :)"
А зачем ???, зачем вещать весь груз на одну лошадь ??? Идеология аля мелкософт :(

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

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

Сообщение от Дохтур (?), 27-Дек-07, 23:34

>Ох, ну ведь можно-же хоть иногда думать на шаг вперед,а не воспринимать
>все в лоб !!!
>Написано "нухач снорт" - совсем не трудно догадаться что сие есть отдельная
>машинка которая просто коллектит алерты и рассылает их посредством snortsam на
>пакетные фильтры ???
вы алерты откуда получать будете? С сенсоров? В любом случае сенсоры должны мониторить почти весь проходящий трафик и сравнивать с сигнатурами.
>Почетал, автор жжот, хотя для экспириенса полезно - но существуют другие пути
>решения
какие?

>А зачем ???, зачем вещать весь груз на одну лошадь ??? Идеология
>аля мелкософт :(
а как вы хотите? быстрее всего матчить в ядре.

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

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

Сообщение от nuclight (?), 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 в этом еще гибче.

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

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

Сообщение от Кирилл (??), 29-Дек-07, 11:06

>    Во FreeBSD есть значительно более общий способ исследования
>пакетов -- NetGraph. Но включая его, админ берёт на себя ответственность
>за снижение пакетной производительности маршрутизатора из-за удлинения packet flow path.
Если фильтровать на уровне ядра через узлы NetGraph (а ipfw имеет свои узлы), скорость фильтрации возрастает чуть ли не в десять раз, если сравнивать с реализацией сходной функциональности на Pf на пользовательском уровне. Но идут работы по созданию узла NetGraph для Pf.

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

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

Сообщение от Анонимус (?), 28-Дек-07, 00:30

>А вы говорите о каких-то полухакерских плюшках(passive os fingerprint из той же
>оперы).
Кстати, passive os fingerprinting в iptables поддерживается модулем OSF (OS fingerprint).

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

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

Сообщение от nuclight (?), 30-Дек-07, 22:20

>А вот куда более жизненное DSCP матчить/выставлять - это да, не умеет
>pf.
Есть патч для ipfw (емнип, даже в базе PRов). И он и без патча уже может матчить биты ECN и длину пакета.

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

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

Сообщение от s_dog (??), 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

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

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

Сообщение от Andrew Kolchoogin (?), 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 (??), 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 (?), 27-Дек-07, 18:54

>    Я знаю "Ринет" с 1996 года, на магистрали
>там _всегда_ стояли Циски. Сейчас там шеститонник+7206. А судя по запальчивости
>тона, проблемы, как всегда, на стороне клиента.
Тоже знаю Ринет и знаю, подтверждаю, что там циски, но фрю там любят. Не рекламы ради, но мне нравился Ринет, к сожалению я переехал, и теперь скучаю по нему.

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

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

Сообщение от Redacid (??), 27-Дек-07, 22:13

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

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

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

Сообщение от Andrew Kolchoogin (?), 28-Дек-07, 01:58

> поверьте БСД способна перелопатить гораздо больше
> Вы не думали, что просто их каналы были не такие уж широкие
    Издеваетесь, коллега?-)))
    Там только на инфраструктуру MSK-IX гигабит. :)

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

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

Сообщение от Redacid (??), 28-Дек-07, 08:03

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

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

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

Сообщение от Аноним (-), 28-Дек-07, 11:37

>Ничего
>тут не поделаешь, ну не нравится мне Линух на сервере, ну
>нравится мне БСД, тут дело вкуса каждого.
Без обид, но это первый признак непрофессионализма - исходить из личных предпочтений.
несмотря на то что в данной дискуссии я занимаю сторону iptables, мне нравится pf и его синтаксис.

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

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

Сообщение от guest (??), 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. В маршрутизаторе важно удобство конфигурации и спектр поддерживаемых протоколов плюс безопасность. Производительность по пакетам имеет решающее значение для коммутаторов.

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

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

Сообщение от klez (??), 26-Дек-07, 23:59

Ну вот опять. Только дин думающий и вменяемый человек на опеннете высказался, как пришло двое, с личными комплексами и начали его грязью поливать, параллельно навешивая ярлыки и на своих провайдеров и на имя и фамилию человека, не побоявшегося подписаться.

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

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

Сообщение от pavel_simple (ok), 27-Дек-07, 00:09

Высказался может и правильно да вот только (ИМХО) не объективно

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

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

Сообщение от Andrew Kolchoogin (?), 27-Дек-07, 01:52

> Высказался может и правильно да вот только (ИМХО) не объективно
На OpenNet'е высказываются почти никогда не объективно: объективность _может_ быть достигнута только приведением результатов тестов. А может и _не быть достигнута_ -- постановка экспериментов -- это большое искусство.
На OpenNet'е высказываются, исходя из своего _личного_ опыта. Ну и неких общеизвестных вещей, легко устанавливаемых чтением документации.

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

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

Сообщение от Andrew Kolchoogin (?), 27-Дек-07, 09:25

> на имя и фамилию человека, не побоявшегося подписаться.
Ну, я человек без комплексов, ФСБ не боюсь, так что подписываюсь везде и всегда реальным именем. :) И очень удивлён, что на OpenNet'е это необщепринятая практика. У участников форума схизис (расщепление личности) -- в RL одно, в Интернете -- другое?-)

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

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

Сообщение от Andrew Kolchoogin (?), 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 на пол-Ленинграда держит. ;) Так что Вы сначала какую-нибудь сетку постройте диаметром больше, чем Ваша квартира, а потом судить беритесь.

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

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

Сообщение от Аноним (38), 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 (?), 27-Дек-07, 09:18

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

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

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

Сообщение от Аноним (-), 27-Дек-07, 10:46

>    Опять-таки, по личному опыту: _сеть_ во FreeBSD за
>последние 11 лет не ломали _ни разу_. ATA ломали, USB ломали,
>а вот сеть -- не ломали.
em, bge в 6ке? или "это драйвера, не считается"?

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

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

Сообщение от Andrew Kolchoogin (?), 27-Дек-07, 17:57

> em, bge в 6ке? или "это драйвера, не считается"?
У меня 6'ка с em работает два года, и ничего там не ломается. "Что я делаю не так?"

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

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

Сообщение от Аноним (-), 27-Дек-07, 19:51

>> em, bge в 6ке? или "это драйвера, не считается"?
>У меня 6'ка с em работает два года, и ничего там не
>ломается. "Что я делаю не так?"
т.е. то что творилось в freebsd-net & freebsd-current перед выпуском 6.2 - это галлюцинации?

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

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

Сообщение от Andrew Kolchoogin (?), 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. (?), 27-Дек-07, 04:52

>    7604+куча LAN-карт -- это НЕ коммутатор. Но сетку
>на 10GigE на пол-Ленинграда держит. ;) Так что Вы сначала какую-нибудь
>сетку постройте диаметром больше, чем Ваша квартира, а потом судить беритесь.
>
имеется ввиду, что он у вас core router?
ЗЫ постинги на редкость осмысленные для опеннет, спсб

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

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

Сообщение от Andrew Kolchoogin (?), 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" +/–

Сообщение от гость (?), 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 уровня с поддержкой протоколов маршрутизации.

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

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

Сообщение от Andrew Kolchoogin (?), 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" +/–

Сообщение от Аноним (-), 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 (??), 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" +/–

Сообщение от Аноним (-), 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 (??), 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" +/–

Сообщение от Дохтур (?), 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 (??), 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?
Нет. Выбор того или иного решения должен определяться с точки зрения эффективности данного решения, а не нравицо/не нравицо.

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

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

Сообщение от Аноним (-), 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 упоминается ;)))
>Нет. Выбор того или иного решения должен определяться с точки зрения эффективности
>данного решения, а не нравицо/не нравицо.
всеми руками за.

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

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

Сообщение от BB (??), 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 на каждой.

>
>>Нет. Выбор того или иного решения должен определяться с точки зрения эффективности
>>данного решения, а не нравицо/не нравицо.
>
>всеми руками за.
Во-во поэтому крики что "данная ОС" мегарулез форева режет слух :)

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

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

Сообщение от Аноним (-), 28-Дек-07, 15:13

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

>Во-во поэтому крики что "данная ОС" мегарулез форева режет слух :)
именно.

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

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

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

>> В 2.6 ветке уже починили IP over ATM
>> в недефолтных таблицах роутинга?-)
> ох, опять вы про ipoatm. 2.6 в железках вроде дсл-роутеров скорее исключение
> из правил.
    Я не про IPoATM.
    Я про Ваш предыдущий пост. Я писал, что Linux чем-то схож с Cisco -- игра "найдите ядро с несломанными фичами".
    Вы сказали, что я написал бред.
    Я Вам привёл опровергающий пример.
    Вы отказываетесь от своих слов?

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

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

Сообщение от Аноним (-), 28-Дек-07, 11:46

>    Я про Ваш предыдущий пост. Я писал, что
>Linux чем-то схож с Cisco -- игра "найдите ядро с несломанными
>фичами".
>
>    Вы сказали, что я написал бред.
>
>    Я Вам привёл опровергающий пример.
>
>    Вы отказываетесь от своих слов?
да, есть такое дело, что что-то ломают. никто от этого не застрахован.

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

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

Сообщение от V.O. (?), 27-Дек-07, 05:04

вопрос: а соляра (10) в этом смысле лучше/быстрее или хуже/медленнее Linux или BSD (если использовать SPARC, AMD64) тестировать буду в 08 для 100-150 бит на пакет траффика (ну вы поняли) -- интересно ваше мнение

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

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

Сообщение от Andrew Kolchoogin (?), 27-Дек-07, 09:22

> вопрос: а соляра (10) в этом смысле лучше/быстрее или хуже/медленнее Linux или
> BSD (если использовать SPARC, AMD64) тестировать буду в 08 для 100-150
> бит на пакет траффика (ну вы поняли) -- интересно ваше мнение
Сложный вопрос. Как маршрутизатор, или как платформа для какого-то сервиса?

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

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

Сообщение от V.O. (?), 27-Дек-07, 15:08

как генератор помех на канале для тестирования в ims (те умный бридж)
ЗЫ байт на пакет...

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

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

Сообщение от Andrew Kolchoogin (?), 27-Дек-07, 18:14

> как генератор помех на канале для тестирования в ims (те умный бридж)
> ЗЫ байт на пакет...
Я бы взял FreeBSD. На нём есть dummynet, который, собственно, для такого тестирования и был придуман -- это потом им люди шейпить стали, а Luigi, его автор, сначала называл их извращенцами, а потом смирился со своей участью. ;)

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

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

Сообщение от Алексей (??), 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-).

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

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

Сообщение от Andrew Kolchoogin (?), 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" +/–

Сообщение от Аноним (-), 27-Дек-07, 21:09

>    Безусловно, если нарисовать 10 000 "dummy"-правил фильтрации линейным
>списком, то пакетная производительность, мягко говоря, несколько снизится. ;)
>    А теперь, внимание, вопрос: а зачем так делать?-)
сеть /22, каждому хосту в ней зарезать полосу в 1Мбит.
На ipfw есть хоть динамические правила, а в pf?

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

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

Сообщение от Andrew Kolchoogin (?), 28-Дек-07, 01:40

> сеть /22, каждому хосту в ней зарезать полосу в 1Мбит.
> На ipfw есть хоть динамические правила, а в pf?
А PF вообще полос не режет. Но altq спасёт отца русской демократии. :)

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

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

Сообщение от Аноним (-), 28-Дек-07, 15:14

>> сеть /22, каждому хосту в ней зарезать полосу в 1Мбит.
>> На ipfw есть хоть динамические правила, а в pf?
>
>А PF вообще полос не режет. Но altq спасёт отца русской демократии.
>:)
altq - часть pf ;)

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

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

Сообщение от Кирилл (??), 29-Дек-07, 10:59

>>> сеть /22, каждому хосту в ней зарезать полосу в 1Мбит.
>>> На ipfw есть хоть динамические правила, а в pf?
>>
>>А PF вообще полос не режет. Но altq спасёт отца русской демократии.
>>:)
>
>altq - часть pf ;)
altq не часть pf :) Просто pf умеет с работать с очередями. Но должную функциональность должна реализовывать сетевая карта.

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

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

Сообщение от Кирилл (??), 29-Дек-07, 11:29

>> сеть /22, каждому хосту в ней зарезать полосу в 1Мбит.
>> На ipfw есть хоть динамические правила, а в pf?
>
>А PF вообще полос не режет. Но altq спасёт отца русской демократии.
>:)
Вы явно подробно с PF не знакомились. PF может управлять шейпингом.

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

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

Сообщение от Кирилл (??), 29-Дек-07, 11:32

>>    Безусловно, если нарисовать 10 000 "dummy"-правил фильтрации линейным
>>списком, то пакетная производительность, мягко говоря, несколько снизится. ;)
>>    А теперь, внимание, вопрос: а зачем так делать?-)
>
>сеть /22, каждому хосту в ней зарезать полосу в 1Мбит.
>На ipfw есть хоть динамические правила, а в pf?
В PF есть возможно динамически изменять правила через механизм якорей. PF вообще значительное мощнее, функциональней и несколько быстрее ipfw на пользовательском уровне. На уровне ядра (через NetGraph) ipfw превосходит по производительности Pf на пользовательском уровне в разы.

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

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

Сообщение от Кирилл (??), 29-Дек-07, 10:53

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

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

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

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

Партнёры:

Хостинг:

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

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

6. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"	+/–
Сообщение от V (??), 26-Дек-07, 14:48
есть слова.. с pf не сравнится..
Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"	+/–
	Сообщение от Andrew Kolchoogin (?), 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 (??), 26-Дек-07, 15:29
	Спасибо, нормально объяснили. По-больше б таких камментов на ОпенНете
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	13. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"	+/–
	Сообщение от Andrew Kolchoogin (?), 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"	+/–
	Сообщение от Ананимуз (?), 26-Дек-07, 16:54
	> да, спасибо... > Интересно, почему под Линь только iptables? > Это неправда. Есть порт IP Filter под Linux. Это тот, который IP filter -> IP chains -> IP tables?
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


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


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


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


	15. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"	+/–
	Сообщение от Аноним (-), 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 ничем не поможет.
	Ответить \| Правка \| К родителю #9 \| Наверх \| Cообщить модератору


	16. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"	+/–
	Сообщение от Andrew Kolchoogin (?), 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"	+/–
	Сообщение от Аноним (-), 26-Дек-07, 17:29
	> Пакетный фильтр в случае DoS не поможет, будь >он хоть сто раз скалируемый. :) ну 100kpps вполне реально получить на половине fast ethernet.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


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


	115. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"	+/–
	Сообщение от nuclight (?), 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, в среднем раза в полтора.
	Ответить \| Правка \| К родителю #16 \| Наверх \| Cообщить модератору


	123. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"	+/–
	Сообщение от routerSMP (?), 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
	Ответить \| Правка \| К родителю #15 \| Наверх \| Cообщить модератору


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


	22. "Новая версия пакетного фильтра для Linux - iptables 1.4.0"	+/–
	Сообщение от Andrew Kolchoogin (?), 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"	+/–
	Сообщение от Дохтур (?), 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 (?), 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"	+/–
	Сообщение от Аноним (-), 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 (?), 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"	+/–
	Сообщение от Аноним (-), 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 (??), 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"	+/–
	Сообщение от Аноним (-), 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 (??), 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-узел, который займется именно этим :)" А зачем ???, зачем вещать весь груз на одну лошадь ??? Идеология аля мелкософт :(
	Ответить \| Правка \| К родителю #83 \| Наверх \| Cообщить модератору


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