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

Выполнено портирование ipfw и dummynet для Linux, opennews (??), 22-Июн-09, (0) [смотреть все] +1 а зачем им делать нечего , Аноним (-), 23:07 , 22-Июн-09, (1) –2 // Затем, что ipfw - мощнейший инструмент хотя его гибкость вызывает сложность в п, Дмитрий Ю. Карпов (?), 23:11 , 22-Июн-09, (3) –1   // iptables -j QUEUE или NFQUEUEЭто, конечно, не отменяет преимуществ ipfw, про, FrBrGeorge (ok), 00:29 , 23-Июн-09, (9) +5   Вы с айпитаблесами не попутали Они могут почти все, но синтаксис чем-то напомина, User294 (ok), 06:57 , 23-Июн-09, (26)   // Синтаксис может быть и не очень приятен, зато семантика гораздо лучше, чем у ipf, www2 (??), 07:10 , 23-Июн-09, (30) –1   Ну, привыкнуть можно А если влом - ну так можно скопипастить или генератором , User294 (ok), 07:43 , 23-Июн-09, (39) –2   У User294 очередлой линупсячий понос наступил Пример из жизни - Изобразите на , _umka_ (??), 08:09 , 23-Июн-09, (42) –1   Добавляем правила огранечения по меткам Далее средствами iptables ставим эти ме, sauron (ok), 08:20 , 23-Июн-09, (45) +1   ipfw add pipe tablearg all from table 1 to anyи илиipfw pipe 1 config mask , nuclight (??), 08:48 , 23-Июн-09, (51) +1   А теперь вложенные хеш-фильтры И да еще как мне там дисциплины крутить Использ, sauron (ok), 14:09 , 23-Июн-09, (114) +2   tc qdisc add dev eth1 root handle 1 htb default 10 tc c, zmc (?), 08:58 , 23-Июн-09, (55) +1   Как только велосипед сможет покрыть возможности и комфорт автомобиля, тогда и по, www2 (??), 12:36 , 23-Июн-09, (104) +2   можешь как-то аргументировать , leshiy.by (?), 00:07 , 25-Июн-09, (233) +1   Больше функций - больше рычагов управления ими Примеры мотоцикл - легковой авт, www2 (??), 06:56 , 25-Июн-09, (236)   летать на автомобиле сложнее чем на самолёте, любитель метафор , leshiy.by (?), 18:14 , 25-Июн-09, (245) +1   Про айпитаблесы он все правильно говорит Геморройны в управлении Но умеют дофига, User294 (??), 23:41 , 25-Июн-09, (252) –1   Я не совсем понимаю как вы предлагаете сравнивать пакетый фильтр с связкой пакет, _umka_ (??), 08:01 , 23-Июн-09, (41) –3   Уважаемый _umka_, мне кажется вы че то напутали, шейпинг имеет смысл только на и, zmc (?), 08:15 , 23-Июн-09, (44) +2   Еще один, не знающий, как работает TCP Ситуация домашний сервер, который NAT д, nuclight (??), 09:15 , 23-Июн-09, (61) +1   Будьте любезны не тыкать мне Правила хорошего тона в общении еще не кто не отме, zmc (?), 09:28 , 23-Июн-09, (65) +1   Я вам пока еще не тыкал, и вообще веду себя более корректно, чем ваш уровень зна, nuclight (??), 09:49 , 23-Июн-09, (75)   согласена то некоторые тут уверяют, что шейпить входящий траффик нельзя , Осторожный (ok), 14:46 , 23-Июн-09, (115)   Ну зашейпил ты входящий канал, а там 99 флуда Буфер переполнился, полезные пак, www2 (??), 14:55 , 23-Июн-09, (118)   Что есть флуд на входящем канале - конкретнее Телепат Кто тебе сказал, что не б, Осторожный (ok), 15:09 , 23-Июн-09, (120)   как пример выше - фикция виртуальный роутер - уже внутри сети с таким же успех, vitek (??), 15:20 , 23-Июн-09, (123)   Ну например у тебя NAT-роутер Изнутри наружу установлено несколько соединений , www2 (??), 16:00 , 23-Июн-09, (129)   Эмммм А ты firewall nat вообще настраивал хоть раз в жизни Потому как если наст, Осторожный (ok), 21:54 , 23-Июн-09, (156)   Да что вы говорите А я всю жизнь думал что сначала вам по вашему каналу пакеты в, User294 (??), 22:43 , 23-Июн-09, (171) –1   Какие пакетики на закрытый TCP-порт Да еще чтобы траффика было много Если это , Осторожный (ok), 08:25 , 24-Июн-09, (183) +1   Обычные С технической точки зрения - всем глубоко похрену что там шлется в вашу , User294 (??), 18:04 , 24-Июн-09, (224) –1   Всё-таки вам очень тяжело объяснить очевидное Хорошо, попробуем описать ситуацию, www2 (??), 07:22 , 24-Июн-09, (178) –1   Да, действительно, очень тяжело объяснять очевидное, когда собеседник имеет очен, nuclight (??), 12:50 , 24-Июн-09, (192) +1   Как же он рассортирует пакеты по выходным буферам, если решение о том, по какому, www2 (??), 12:58 , 24-Июн-09, (194)   Уважаемый www2, можно я обьясню DВидите ли в чем дело, просто nuclight уже осоз, zmc (?), 13:37 , 24-Июн-09, (202)   дык и нельзя объем входящего трафика всё равно этим не ограничешь сколько из вн, vitek (??), 15:12 , 23-Июн-09, (122) –1   Картина маслом я шлю вам SYN пакеты или какие угодо иные пакеты долетающие до , User294 (??), 17:50 , 23-Июн-09, (146) –1   Мде Благородный дон, если бы весь трафик состоял из атак то может быть ты бы и, Одмин (?), 18:45 , 23-Июн-09, (147) +1   больша часть трафа - http и иже с ним толку что он tcp соединение устанавлива, vitek (??), 19:03 , 23-Июн-09, (149) –1   Действительно, прекращайте С понятием slow start в tcp вы явно не знаком, nuclight (??), 12:53 , 24-Июн-09, (193) +1   когда ж ты угомонишься то ну пролетел ты, с кем не бывает -D, vitek (??), 14:52 , 24-Июн-09, (214)   Есть одна проблема - все это допускает что все ремотные юзеры белые, пушистые и , User294 (??), 18:20 , 24-Июн-09, (226) –1   Проблем нет ровно до тех пор пока удача улыбается вам лицом А если повернетс, User294 (??), 22:12 , 23-Июн-09, (162) –1   И пров тоже не поможет потомукак его канал тоже флудом забит , Хм... (?), 21:24 , 24-Июн-09, (229) +1   Забить прововские каналы флудом труднее чем одну тощую соску Которую обычно и хо, User294 (??), 23:39 , 25-Июн-09, (251)   А я что где-то говорил, что нельзя за-DDOS-ить роутер , Осторожный (ok), 21:58 , 23-Июн-09, (158)   Это строго говоря не ддос сие не обязано быть распределенной атакой, ни даже sy, User294 (??), 22:20 , 23-Июн-09, (167)   Вот только блаародный дон упускает несколько моментов 1 В природе есть не то, User294 (ok), 14:54 , 23-Июн-09, (117)   Ну и Протоколы приложения, которым не пофиг, организуют свои собственные мех, nuclight (??), 13:28 , 24-Июн-09, (198)   Допустим есть VoIP Как правило - UDP Ему не пофиг латентность и потери пакетов И, User294 (ok), 15:21 , 24-Июн-09, (217)   Блин модераторы зачем пост зарезали там не так много матов было - Для особо упр, zmc (?), 18:45 , 23-Июн-09, (148) +1   Ну не понимает чувак что в общем случае ремота не обязана быть кооперативной и и, User294 (??), 22:56 , 23-Июн-09, (172) +1   Ага, то есть вы предлагаете шейпить ответные ACK и от клиента к отправителю Заг, nuclight (??), 13:17 , 24-Июн-09, (196) +1   Я конечно не такой умный как Но вот в связке iptables iproute tc , у меня бо, zmc (?), 14:17 , 24-Июн-09, (210) –1   Единственный способ контролировать вход это грамотно резать выход, а TCP сам вы, Gra2k (?), 07:45 , 25-Июн-09, (239) +1   А что вас поразило, то, что мы косвено можем контролировать вход балансируя выхо, zmc (?), 09:07 , 25-Июн-09, (240) –1   Вы уж тогда определитесь косвенно или единственный способ В любой книге написан, Gra2k (?), 20:17 , 25-Июн-09, (246) +1   Это вы о чем, мы с вами говорим совершенно о разных вещах, не поленитесь перечет, zmc (?), 04:08 , 26-Июн-09, (253) –1   Перестаньте гнать пургу и ознакомьтесь со схемой iptables Ознакомьтесь с поняти, www2 (??), 12:31 , 23-Июн-09, (103) –1   Причем здесь iptables, mangle, OUTPUT, FORWARD Речь идет про ipfw С ipfw сделаю, Fantomas (??), 16:40 , 23-Июн-09, (136)   обратно отправишь типа - никого нет дома, заберите назад -Dв любом случае, пр, vitek (??), 17:04 , 23-Июн-09, (143) –1   Пожалуется в ООН наверное - вон та нехорошая ремота наплевала на мои тщетные по, User294 (??), 22:29 , 23-Июн-09, (170) –1   Если машина - только роутер, и всё - то да Но ipfw может защищать и регулировать, Freebsdun (?), 23:24 , 24-Окт-10, (262)   Шейпер можно ставить только на исходящий трафик Любые вещи мы повесили фильтр н, sauron (ok), 08:22 , 23-Июн-09, (46) –1   Бред Шейпер нужен там, где необходимо резать канал на полосы пропускания с соотв, iZEN (ok), 08:58 , 23-Июн-09, (56) +1   Блин да скоко вам обьеснять мы можем контролировать шейпером тока НАШ ИСХОДЯЩИЙ , zmc (?), 09:14 , 23-Июн-09, (60) +2   Типичное заблуждение, входящий TCP трафик очень хорошо шейпится за счет удержива, Аноним (-), 09:26 , 23-Июн-09, (64) +2   А как это сделать с помощью tc и pipe в dummynet , zmc (?), 09:30 , 23-Июн-09, (68) –1   При условии что ремота - кооперативна, а не просто срет в ваш адрес пакетами, по, User294 (ok), 15:09 , 23-Июн-09, (121) –1   т е другими словами, тотже эффект - шейпим исходящий трафик для внутренней сети, vitek (??), 15:36 , 23-Июн-09, (124) –1   А если он шакал, не дал админу пароль на торрент , Fantomas (??), 16:52 , 23-Июн-09, (141) –1   хреновый админ тогда однако у Вас же в бзде дерэйс есть там даже пароли на ssh , vitek (??), 19:07 , 23-Июн-09, (150) –1   Элементарно Режешь сразу после ната , Fantomas (??), 16:49 , 23-Июн-09, (139) –1   Ха-ха, вы снаала получаете пакеты а потом можете их прибить, отполисовать и проч, User294 (??), 18:57 , 24-Июн-09, (227) –1   Поясняю в случае исходящего трафика у вас есть бак с краниками и соотвественно в, sauron (ok), 14:05 , 23-Июн-09, (113) –1   Ну что же, если вы использовали такую аналогию, то сами подставились, я не винов, nuclight (??), 13:01 , 24-Июн-09, (195) +2   Аналогия не верна и всё дальнейшее - чушь Это ещё могло бы подойти для описания, www2 (??), 13:25 , 24-Июн-09, (197) –1   И что характерно у этих упёртых получается Как ни странно входящие шейперы раб, Аноним (-), 16:02 , 25-Июн-09, (244) +1   Вы забыли одну вещь Краник 1 находится у провайдера, а не у вас крутить вы его , sauron (ok), 13:42 , 24-Июн-09, (204) –1   Да-дад, идите учите Ситуация наоборот верна, любой исходящий можно заменить в, nuclight (??), 09:22 , 23-Июн-09, (63) +1   gt оверквотинг удален На самом деле Вы сами предложили написать тоже самое, н, KO (?), 09:30 , 23-Июн-09, (67) –1   Например, tablearg, несколько разных тегов на пакете одновременно, OR-блоки внут, nuclight (??), 08:46 , 23-Июн-09, (50) +1   А что есть IPT http en wikipedia org wiki IPT, Осторожный (ok), 14:49 , 23-Июн-09, (116) +1   Навскидку только ipfw, как просили - Таблицы адресов а не таблицы правил с ч, Spase (?), 09:09 , 23-Июн-09, (59) +1   Ну, вообще-то оно нынче уже умеет указывать номер правила в подцепочке -I, --ins, nuclight (??), 09:29 , 23-Июн-09, (66)   Таблицы адресов присутствуют уже с полгода Этого не помню, возможно и нет Весьма, KO (?), 09:38 , 23-Июн-09, (70) –1   А чем таблицы адресов отличаются от ipset , piavlo (?), 10:20 , 23-Июн-09, (80)   Отсутствием tablearg Опять же, не исключаю, что уже сделали Правда, с трудом п, Spase (?), 11:08 , 23-Июн-09, (88)   skipДа, видимо, отстал от жизни , Spase (?), 11:12 , 23-Июн-09, (89) –1   Это не то Во-первых, не может быть нескольких правил под одним и тем же номером, Spase (?), 11:28 , 23-Июн-09, (92)   Вы сам его привели iptables iproute2 tc вместо 1го файла с приятным и понятным, Ыку (?), 11:43 , 23-Июн-09, (94) +1   Ясно, преимуществ нет , www2 (??), 12:40 , 23-Июн-09, (105)   нужное дело делают это не зоопарк, а расширение возможностей выбор каждый сдел, div (??), 23:12 , 22-Июн-09, (4) +2 Лучшеб IMQ уже в ядро внесли совместными усилиями А так без IMQ согласен вещь о, chuvy (??), 13:23 , 25-Июн-09, (241) +1 Лучше бы PF портировали , kukulkan (??), 23:22 , 22-Июн-09, (5) +2 // что это мешает сделать лично вам , div (??), 23:29 , 22-Июн-09, (6) +3 // он занят писательством комментариев, Dan (??), 00:53 , 23-Июн-09, (13) +3 ipfw проще в настройке, например, минимальный файрволл настраивается в четыре на, Ilya Evseev (?), 23:49 , 22-Июн-09, (7) +2 // Забавно А если iptables этого не умеет, то почему жк он так называется - , Ivan (??), 00:07 , 23-Июн-09, (8) –1 // Потому что он умеет работать с таблицами правил, FrBrGeorge (ok), 00:29 , 23-Июн-09, (10) +2 // да куча уже упрощающих настройщиков для iptables в бубунте вот ufw типа ufw , vitek (??), 00:49 , 23-Июн-09, (12) +2 По недоразумению В линуксе вообще многое называется не так, как в точности след, nuclight (??), 09:09 , 23-Июн-09, (57) +1 // Вообще-то проще его поставить руками , KO (?), 09:43 , 23-Июн-09, (71) –1 Более того http packages ubuntu com search keywords ipsetставится apt-get-ом , KO (?), 09:46 , 23-Июн-09, (74) –1 Ну вот поинтересуйтесь у них, почему у них такой возможности не было, хотя они о, nuclight (??), 09:55 , 23-Июн-09, (77) +1 Радиус кривизны рук наверное большой был, вот и решили не искать лёгких путей , www2 (??), 12:56 , 23-Июн-09, (109) –1 ага, тут выше приводят ссылку по ссылке эмулируют хеш лол вот у них спросите по, eye (?), 11:02 , 23-Июн-09, (86) +1 gt оверквотинг удален Это уже отдаёт самоцелью Даже теоретически не могу пред, www2 (??), 12:55 , 23-Июн-09, (108) –1 gt оверквотинг удален Как раз-таки наоборот Линейная последовательность прави, nuclight (??), 13:47 , 24-Июн-09, (206) +1 Не согласен В iptables не бывает переходов на правило с произвольным номером, т, www2 (??), 14:14 , 24-Июн-09, (209) –1 ну вообще-то ещё есть man iptables -g, --goto chain , vitek (??), 14:49 , 24-Июн-09, (212) –1 1 iptables -P INPUT DROP2 iptables -A INPUT -i lo -j ACCEPT 3 iptables -A INP, poige (ok), 07:20 , 23-Июн-09, (33) –1 // Хотел запостить то же самое , www2 (??), 07:23 , 23-Июн-09, (35) –1 // И echo bingo-bingo тоже -D, poige (ok), 08:29 , 23-Июн-09, (47) –1 Нет, тут я признаю ваше авторство echo bingo-bingo с poige, www2 (??), 12:47 , 23-Июн-09, (106) –1 Поржал, спасибо - , poige (ok), 12:52 , 23-Июн-09, (107) –1 Вы считаете, что это более читаемо, чем приведённый выше пример , none (??), 11:28 , 23-Июн-09, (91) +1 // Вы правда хотите услышать поговорку про то, что мешает плохому танцору, ещё раз , poige (ok), 12:14 , 23-Июн-09, (100) –1 А в чём сакральный смысл этого набора правил Разве не достаточно просто не запу, Дмитрий Ю. Карпов (?), 16:33 , 24-Июн-09, (219) –1 Отличная новость Долгоя этого момента ждал Шейпить в 10 раз проще станет , pipboy_13 (?), 00:40 , 23-Июн-09, (11) // Забыл съесть сникерса Кому оно было надо - уже давно шейпили Не, если у кого рад, User294 (ok), 06:59 , 23-Июн-09, (27) –1 // Я как раз ищу решения для шейпинга, может подскажите http www opennet ru open, TrueHead (ok), 07:28 , 23-Июн-09, (37) +1 УРАААААА ждем теперь PF вот его то особо не хватает , bmnbmn (?), 00:59 , 23-Июн-09, (14) // да сносите вы нафиг свой Linux, сетапте опенка и будет вам еще много много счаст, cyberpokemonus (?), 01:05 , 23-Июн-09, (15) –3 // не ради холивора будет сказано, но как поддерживать то его поставил убунту - вс, bmnbmn (?), 01:32 , 23-Июн-09, (16) +2 // Не вижу смысла в шейпинге на воркстейшене - нет проблем с флешплеером Сама сис, yason (?), 02:24 , 23-Июн-09, (20) –1 Интересная логика А что, в OpenBSD какие-то крутые технологии энергосбережени, User294 (ok), 07:04 , 23-Июн-09, (28) –1 Логика простая - мы, вроде, про серверное применение говорили Нет Но вы подумай, yason (?), 10:26 , 23-Июн-09, (83) +1 Как фанат фанату Или все-таки каждый пользует то, что ему больше нравится и , EVS21 (??), 11:40 , 24-Июн-09, (186) Дебианщики и убунтуйцы это достаточно хитро разруливают До обновления версии сис, User294 (ok), 07:29 , 23-Июн-09, (38) –1 Про убунту не знаю, зато скажу про дебиан Бога ради, даже не пытайтесь рассчиты, www2 (??), 12:21 , 23-Июн-09, (102) –1 Ослиное упрямство не делает чести людям ИМХО Я бы предпочел если бы вместо ослин, User294 (??), 23:15 , 23-Июн-09, (173) –1 А кто будет определять степень и грань разумности Не получится ли так, что кажд, www2 (??), 07:10 , 24-Июн-09, (177) –1 Вы бы предпочли, чтобы с вашей точки зрения упрямство было бы ну и т д Стра, EVS21 (??), 11:44 , 24-Июн-09, (188) fixed, www2 (??), 12:43 , 24-Июн-09, (191) –1 Да, а в итоге все порой приходит к пичканию всех древним софтом for no reasons П, User294 (ok), 14:25 , 24-Июн-09, (211) –1 У nginx вообще до недавних пор стабильных версий не было А это значит, что наря, www2 (??), 14:51 , 24-Июн-09, (213) –1 Вот это - хорошо сказано И именно в этом плане дебиан хорошая система Иногда Да , User294 (??), 23:08 , 25-Июн-09, (248) –1 Если _обычно_ - это уже не подходит На брудершафт не пили, но Вы вызываете у ме, www2 (??), 08:15 , 26-Июн-09, (254) –1 Т е предполагается что для майнтайнера включить мозг при пересборке пакета и пр, User294 (ok), 17:55 , 26-Июн-09, (255) –1 Предполагается что пользователи Debian должны быть на 100 уверены, что изменени, www2 (??), 17:25 , 27-Июн-09, (257) Ну и сколько всего серверов И что нибудь посерьёзней чем почта и proxy есть VPN, Brain (??), 07:45 , 23-Июн-09, (40) А что вы понимаете под посерьёзней У меня всё это для работы стоит 3 сервера , yason (?), 10:35 , 23-Июн-09, (85) OMG Я нашел человека который шейпит на десктопе Или Вам на сервере нужен флешь, тигар (ok), 11:07 , 23-Июн-09, (87) –1 Пипец Во фре порты обновляются можно сказать мнгоновенно Недавно вышел clamav , chuvy (??), 13:40 , 25-Июн-09, (242) Это ж от конкретного ментейнера зависит а не от системы , Аноним (-), 22:16 , 25-Июн-09, (247) +2 Наверное Марта очень красивая, раз смогла возбудить, тфу, побудить Луиджи Риццо , RapteR (ok), 04:11 , 23-Июн-09, (23) +3 М-да Вот что значит, выдернутая из контекста новость Марта провела работу по, northbear (??), 07:05 , 23-Июн-09, (29) +1 // Стоит сторонний софт, который по ssh работает только с ipfw Фряху держали тольк, ImSolo (?), 08:09 , 23-Июн-09, (43) –1 // А что вам мешало создать bash-скрипт sbin ipfw, который быэлементарно синтаксис, morten (?), 08:48 , 23-Июн-09, (52) +1 // Фигня вопрос Тогда может полный синтаксис ipfw сделаешь Там вообще одна полезна, Осторожный (ok), 16:32 , 23-Июн-09, (132) +1 man ipset google linux ipset , poige (ok), 10:01 , 23-Июн-09, (79) –1 // этот способ абсолютно не годится ipset везде надо вручную вкомпиливать в ядро , charon (ok), 11:39 , 23-Июн-09, (93) +1 // Если Вы обновляете ядро на всех доступных машинах почти каждый месяц - Вам дей, Sergey Lychko (?), 11:55 , 23-Июн-09, (97) –1 я обновляю ядро по мере появления критичных ошибок безопасности И такое бывает , charon (ok), 12:02 , 23-Июн-09, (98) +1 Ну, я бы сильно удивился, если бы на Linux е не было вообще никакого аналога Кс, northbear (??), 16:00 , 23-Июн-09, (130) +1 лучше-бы под винду портанули, whip (?), 08:42 , 23-Июн-09, (48) –2 // ipfw под винду УЖЕ НЕСКОЛЬКО ЛЕТ как есть, morten (?), 08:48 , 23-Июн-09, (53) +2 с 2004 года есть http wipfw sourceforge net http sourceforge net project sho, hhg (ok), 10:32 , 23-Июн-09, (84) +1 // 1 Под Windows есть2 но только для до Windows XP включительно на Vista не рабо, Минас (ok), 03:58 , 27-Июн-09, (256) +1 А как на счет совместимости лицензий , sergey (??), 13:40 , 23-Июн-09, (110) // А что с ними Лицензия BSD позволяет брать код и выпускать его под любой лицензи, www2 (??), 13:49 , 23-Июн-09, (111) –1 // Лицензия BSD позволяет брать код, но лицензия на это код остается BSD GPL щики в, oops (?), 07:24 , 24-Июн-09, (179) +1 // Ну-ка ну-ка, попросите у мицросовт BSD-шный сетевой стек из винды Или BSD-код J, www2 (??), 07:40 , 24-Июн-09, (182) –1 Не путаем теплое с мягким Я не говорю про дележку Мой код остается МОИМ куда б, oops (?), 11:43 , 24-Июн-09, (187) +1 И о чём спор Вернитесь по ветке выше к самому первому вопросу А как на счет с, www2 (??), 12:38 , 24-Июн-09, (190) –1 давайте вернемся это в корне неверно , oops (?), 15:13 , 24-Июн-09, (215) +1 зато в хоме отлично отрабатывает , vitek (??), 18:58 , 24-Июн-09, (228) –1 Один раз вы уже попробовали http www opennet ru opennews art shtml num 11844, oops (?), 05:41 , 25-Июн-09, (235) +1 Это называется Тео развонялся Он начал требовать изменения в коде драйвера ath5, www2 (??), 07:31 , 25-Июн-09, (237) +1 Походу кому-то не нравятся последствия выбора лицензии А чем они думали выбирая , User294 (??), 23:37 , 25-Июн-09, (250) Ну да, под почти любой Ограничений в BSDL немного Поэтому можно переиначить си, User294 (??), 23:34 , 25-Июн-09, (249) Вопрос уважаемым знатокам Поставил себе на убунту ipfwнастроил раздачу инета чер, solarw (?), 15:00 , 23-Июн-09, (119) // Если я правильно протелепатировал, в модуле_ipfw по умолчанию deny from any to , Дмитрий Ю. Карпов (?), 16:55 , 24-Июн-09, (220) // ipfw nat смотрите, chuvy (??), 13:54 , 25-Июн-09, (243) +1 Некоторые так возмущаются о портирование будто вас призвали портировать а вы не , Аноним (-), 16:01 , 23-Июн-09, (131) по шейпу вход трафика есть IMQhttp www linuximq net usage html, Аноним (-), 16:46 , 23-Июн-09, (137) вот такое напишите на iptables ipfw add 1 prob 0 01 deny icmp from any to me re, Илья (??), 21:04 , 23-Июн-09, (152) // Вот такое напишите на ipfw2 http www netfilter org projects patch-o-matic pom, poige (ok), 21:25 , 23-Июн-09, (153) Илья мне кажется вы плохо знаете ipfw Обьясню почему Чисто со стороны логики ес, zmc (?), 07:31 , 24-Июн-09, (180) // Так не покатит -- Can t use -i with POSTROUTING но это можно обойти при помощ, poige (ok), 12:03 , 24-Июн-09, (189) у iptables к сожалению нет понятия me , этого наиболее жаль с вероятностями и , Илья (??), 13:33 , 24-Июн-09, (199) Илья я конечно может многово не знаю, но мне вот на вскидку трудно найти примене, zmc (?), 07:35 , 24-Июн-09, (181) // хотя бы аналог me покажите в iptables, Илья (??), 13:34 , 24-Июн-09, (200) // Я не знаю, кто такой me , но цепочки INPUT и OUTPUT - не оно , Andrey Mitrofanov (?), 13:37 , 24-Июн-09, (201) Да без БЭ - -m addrtype --dst-type LOCAL Если вы не осилили man iptables то это , zmc (?), 13:50 , 24-Июн-09, (207) –1 насколько я помню в линуксе собирались переписать iptables ради человеческого си, safron (?), 17:18 , 24-Июн-09, (222) // google ru nftables рассказал бы Вам, что http www netfilter org news html , Andrey Mitrofanov (?), 18:06 , 24-Июн-09, (225) http www rootconf ru papers2009 12352 htmlИнтересная инфа по ipfwДумаю ng пока, tor (??), 10:09 , 30-Июн-09, (259) // Чего ждать-то Каких-то абстрактных вкусностей Линуксоиды решают конкретные прак, www2 (??), 12:48 , 30-Июн-09, (260) Вопрос к знатокам ipfw Можно ли в нем реализовать нечто подобное IPTABLES -A , danmer (ok), 08:57 , 04-Июл-09, (261) 1,5,7,11,14,23,29,48,110,119,131,137,152,222,259,261

Сообщения

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

	3. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от Дмитрий Ю. Карпов (?), 22-Июн-09, 23:11
	Затем, что ipfw - мощнейший инструмент (хотя его гибкость вызывает сложность в понимании и использовании). Например, один divert очень ценен, т.к. позволяет обработку пакетов в user-space.
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Выполнено портирование ipfw и dummynet для Linux"	+5 +/–
	Сообщение от FrBrGeorge (ok), 23-Июн-09, 00:29
	> Например, один divert очень ценен, т.к. позволяет обработку пакетов в user-space. iptables ... -j QUEUE или NFQUEUE Это, конечно, не отменяет преимуществ ipfw, просто для справки :)
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от User294 (ok), 23-Июн-09, 06:57
	> Затем, что ipfw - мощнейший инструмент Вы с айпитаблесами не попутали?Они могут почти все, но синтаксис чем-то напоминает язык программирования брэйнфак :)
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	30. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от www2 (??), 23-Июн-09, 07:10
	>Вы с айпитаблесами не попутали?Они могут почти все, но синтаксис чем-то напоминает язык программирования брэйнфак :) Синтаксис может быть и не очень приятен, зато семантика гораздо лучше, чем у ipfw. И вообще, может быть кто-нибудь назовёт те преимущества ipfw, которые не умеет iptables+iproute2+tc?
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Выполнено портирование ipfw и dummynet для Linux"	–2 +/–
	Сообщение от User294 (ok), 23-Июн-09, 07:43
	>Синтаксис может быть и не очень приятен, зато семантика гораздо лучше, чем >у ipfw. Ну, привыкнуть можно.А если влом - ну так можно скопипастить :) или генератором правил, блин, сгенерить.Не понимаю я их проблем (кроме нежелания осваивать тулзень). >И вообще, может быть кто-нибудь назовёт те преимущества ipfw, которые не умеет >iptables+iproute2+tc? Я что-то не думаю что они это осилят... впрочем ждемс.Так как любопытно.Не, не то чтобы я супер-спец по айпитаблесам, но что им + упомянутой связкой можно изобразить - я как минимум видел в роутерных прошивках.Вполне себе прилично получается вроде - я вот так сходу не смог придумать чего бы мне захотелось но не изображалось бы данной связкой :).Может у бздунов больше фантазии?
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от _umka_ (??), 23-Июн-09, 08:09
	> >Я что-то не думаю что они это осилят... впрочем ждемс.Так как любопытно.Не, >не то чтобы я супер-спец по айпитаблесам, но что им + >упомянутой связкой можно изобразить - я как минимум видел в роутерных >прошивках.Вполне себе прилично получается вроде - я вот так сходу не >смог придумать чего бы мне захотелось но не изображалось бы данной >связкой :).Может у бздунов больше фантазии? У User294 очередлой линупсячий понос наступил... Пример из жизни - Изобразите на iptables + tc аналог правил: ipfw pipe 2000 config bw 5000Kbit/s queue 10Kbytes ipfw pipe 2001 config bw 5000Kbit/s queue 10Kbytes ipfw add 2000 pipe 2000 ip from any to any in via vlan99 ipfw add 2001 pipe 2001 ip from any to any out via vlan99 особое внимание обращаю на то что тут используется ограничение _входящего_ трафика с привязкой к vlan. Оцените количество правил которое вам потребуется для реализации тойже функциональности в tc, в связке tc + iptables? как только уложитесь в 4 читаемых правила, а не 10-12 - покажите результат.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от sauron (ok), 23-Июн-09, 08:20
	Добавляем правила огранечения по меткам. Далее средствами iptables ставим эти метки. А теперь покажите мне в ipfw организовать хеш-фильтры https://www.opennet.ru/docs/RUS/LARTC/x1661.html
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от nuclight (??), 23-Июн-09, 08:48
	>Добавляем правила огранечения по меткам. Далее средствами iptables ставим эти метки. >А теперь покажите мне в ipfw организовать хеш-фильтры https://www.opennet.ru/docs/RUS/LARTC/x1661.html ipfw add pipe tablearg all from table(1) to any и/или ipfw pipe 1 config ... mask 0x00000fff (динамические пайпы)
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Выполнено портирование ipfw и dummynet для Linux"	+2 +/–
	Сообщение от sauron (ok), 23-Июн-09, 14:09
	>ipfw add pipe tablearg all from table(1) to any > > >ipfw pipe 1 config ... mask 0x00000fff (динамические пайпы) А теперь вложенные хеш-фильтры. И да еще как мне там дисциплины крутить? Использовать altq? :]
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от zmc (?), 23-Июн-09, 08:58
	>Пример из жизни - Изобразите на iptables + tc аналог правил: >ipfw pipe 2000 config bw 5000Kbit/s queue 10Kbytes >ipfw pipe 2001 config bw 5000Kbit/s queue 10Kbytes >ipfw add 2000 pipe 2000 ip from any to any in via vlan99 >ipfw add 2001 pipe 2001 ip from any to any out via vlan99 tc qdisc add dev eth1 root handle 1: htb default 10                         tc class add dev eth1 parent 1: classid 1:10 htb rate 5mbit burst 15k       tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10                 tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 1 fw flowid 1:10 iptables -A PREROUTING -t mangle -i eth1 -j MARK --set-mark 1               >особое внимание обращаю на то что тут используется ограничение _входящего_ трафика ... Про входящий трафик вам уже все разеснили
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	104. "Выполнено портирование ipfw и dummynet для Linux"	+2 +/–
	Сообщение от www2 (??), 23-Июн-09, 12:36
	>как только уложитесь в 4 читаемых правила, а не 10-12 - покажите >результат. Как только велосипед сможет покрыть возможности и комфорт автомобиля, тогда и покажем как с помощью tc можно в то же количество строк можно описать то, что умеет делать dummynet. Более богатые функции предполагают более трудное их использование.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	233. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от leshiy.by (?), 25-Июн-09, 00:07
	>> Более богатые функции предполагают более трудное их использование. можешь как-то аргументировать?
	Ответить | Правка | Наверх | Cообщить модератору

	236. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от www2 (??), 25-Июн-09, 06:56
	>>> Более богатые функции предполагают более трудное их использование. > >можешь как-то аргументировать? Больше функций - больше рычагов управления ими. Примеры: мотоцикл - легковой автомобиль - самолёт - вертолёт, лопата - экскаватор, музыкальный проигрыватель - пульт ди-джея радиостанции - синтезатор - компьютер. Я думал не нужно объяснять очевидное. Или ты из тех, кто считает компьютер бытовым прибором вроде пылесоса? Или ты пилотируешь Боинг имея водительские права категории B?
	Ответить | Правка | Наверх | Cообщить модератору

	245. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от leshiy.by (?), 25-Июн-09, 18:14
	>>>> Более богатые функции предполагают более трудное их использование. >> >>можешь как-то аргументировать? > >Больше функций - больше рычагов управления ими. Примеры: мотоцикл - легковой автомобиль >- самолёт - вертолёт, лопата - экскаватор, музыкальный проигрыватель - пульт >ди-джея радиостанции - синтезатор - компьютер. Я думал не нужно объяснять >очевидное. Или ты из тех, кто считает компьютер бытовым прибором вроде >пылесоса? Или ты пилотируешь Боинг имея водительские права категории B? летать на автомобиле сложнее чем на самолёте, любитель метафор :)
	Ответить | Правка | Наверх | Cообщить модератору

	252. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от User294 (??), 25-Июн-09, 23:41
	>летать на автомобиле сложнее чем на самолёте, любитель метафор :) Про айпитаблесы он все правильно говорит.Геморройны в управлении.Но умеют дофига всего.И - да, управлять автомобилем труднее чем велосипедом.Для езды на велике не надо экзамены сдавать - сел и поехал.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Выполнено портирование ipfw и dummynet для Linux"	–3 +/–
	Сообщение от _umka_ (??), 23-Июн-09, 08:01
	Я не совсем понимаю как вы предлагаете сравнивать пакетый фильтр с связкой пакетный фильтр + управление роутингом + шейпер ? Странное сравние - теплого с мягким. Может вы перепутали и имели ввиду ipfw+dummynet с iptables+tc? Так опять же не коректное сравние. tc хоть и умеет разные дисциплины обслуживания у шейпера - но работает только для исходящего трафика (не надо мне рассказывать о ingress фильтрах - которые делаются через задний проход). В этом ключе iptables+tc - правильнее сравнивать с ipfw + altq (да да, dummynet это не единственный шейпер с которым в связке может использоваться ipfw). Но судя по всему вы не разбираетесь в вопросе - поэтому приводить вам аргументы не стоит. Разбиритесь сначала что вы хотите сравнить - а потом поговорим.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	44. "Выполнено портирование ipfw и dummynet для Linux"	+2 +/–
	Сообщение от zmc (?), 23-Июн-09, 08:15
	>tc хоть и умеет разные дисциплины обслуживания у шейпера - но работает только для исходящего >трафика (не надо мне рассказывать о ingress фильтрах - которые делаются через задний проход). Уважаемый _umka_, мне кажется вы че то напутали, шейпинг имеет смысл только на исходящем трафике и безразници где это в фряшном dummynet или линуксовый iproute. Да да именно для вас tc входит в состав пакета iproute.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от nuclight (??), 23-Июн-09, 09:15
	>>tc хоть и умеет разные дисциплины обслуживания у шейпера - но работает только для исходящего >>трафика (не надо мне рассказывать о ingress фильтрах - которые делаются через задний проход). > >Уважаемый _umka_, мне кажется вы че то напутали, шейпинг имеет смысл только >на исходящем трафике и безразници где это в фряшном dummynet или >линуксовый iproute. Еще один, не знающий, как работает TCP. Ситуация: домашний сервер, который NAT для еще двух машин. Нужно распределить поток так, чтобы сервер не отжирал бесконтрольно полосу, не оставляя ничего домашним машинам, и чтоб они его и друг друга тоже. Как? С только исходящими фильтрами - это невозможно, сервер будет неучтен. Но вполне очевидно, что входящий шейпер на входе внешнего интерфейса сервера эквивалентен конфигурации, когда перед сервером включается еще один роутер, на котором конфигурируется исходящий шейпер в сторону сервера.   >Да да именно для вас tc входит в состав пакета iproute. Представьте себе, он в курсе, и даже знает, как он устроен внутри :)
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от zmc (?), 23-Июн-09, 09:28
	>Еще один, не знающий, как работает TCP. Будьте любезны не тыкать мне. Правила хорошего тона в общении еще не кто не отменял. Как работает TCP я и без вас знаю >Как? С только исходящими фильтрами - >это невозможно, сервер будет неучтен. И после этого вы меня будете учить :-) >Но вполне очевидно, что входящий шейпер >на входе внешнего интерфейса сервера эквивалентен конфигурации, когда перед сервером включается >еще один роутер, на котором конфигурируется исходящий шейпер в сторону сервера. ВОТ ЭТО УЖ ВООБЩЕ НИ КАК НЕ ОЧЕВИДНО - про входящий трафик я уже писал ниже. Единственный способ контролировать вход это грамотно резать выход, а TCP сам выровняет.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от nuclight (??), 23-Июн-09, 09:49
	>>Еще один, не знающий, как работает TCP. > >Будьте любезны не тыкать мне. Правила хорошего тона в общении еще не >кто не отменял. Я вам пока еще не тыкал, и вообще веду себя более корректно, чем ваш уровень знаний этого заслуживает. >Как работает TCP я и без вас знаю Что, правда? И про SACK, и про congestion control знаете? И как работают алгоритмы RED/GRED, тоже знаете? А ведь там та же основа. >>Как? С только исходящими фильтрами - >>это невозможно, сервер будет неучтен. > >И после этого вы меня будете учить :-) ОК, расскажите же мне, как пошейпить пришедший самому серверу (т.е. его собственный IP) на eth0 входящий трафик, если исходящие фильтры висят только на смотрящем во внутреннюю сеть к клиентам eth1 ? А на сервере запущен торрент-клиент, который хорошо так кушает канал, если не пошейпить :) >>Но вполне очевидно, что входящий шейпер >>на входе внешнего интерфейса сервера эквивалентен конфигурации, когда перед сервером включается >>еще один роутер, на котором конфигурируется исходящий шейпер в сторону сервера. > >ВОТ ЭТО УЖ ВООБЩЕ НИ КАК НЕ ОЧЕВИДНО - про входящий трафик >я уже писал ниже. Бред вы писали. Я щас вам эту очевидную схемку нарисую, раз уж сами не можете додуматься, пусть у сервера адрес 1.2.3.4: [канал к провайдеру]-----[eth0]-----[сам сервер]----[eth1]-----[внутренние машины] Здесь входящий трафик, который и надо шейпить, идет слева направо, с исходящими фильтрами возможно шейпить лишь на eth1, но там не будет трафика, предназначенного к 1.2.3.4, только к внутренним. А на eth0 идет сумма трафика, для 1.2.3.4 и для внутренних машин, вот его-то в целом и надо балансировать. И вот та самая ОЧЕВИДНАЯ замена: [провайдер]--[eth0]--[другой роутер]--[eth1]--[eth0]--[сам сервер]--[eth1]-[внутренние машины] Видно, что если поставить ПЕРЕД сервером еще один роутер, исходящие фильтры на eth1 этого другого роутера будут ПЕРЕД eth0 нашего качающего сервера, и будут включать в себя ВЕСЬ трафик, потому что этот виртуальный роутер не будет иметь трафика, предназначенного для себя. И теперь, очевидно то, что эти две схемы ЭКВИВАЛЕНТНЫ тому, чтобы повесить входящие шейпящие фильтры на eth0 сервера, т.е. в направлении слева направо, т.е. просто вклиниться в этот поток внутри eth0 - ибо зачем нам ставить еще один роутер для такой простой задачи, dummynet ведь умеет. Я достаточно понятно разжевал? >Единственный способ контролировать вход это грамотно резать выход, а TCP сам выровняет. Ну да. Но TCP абсолютно пофиг, где именно его резать, ему важно лишь направление. По схеме выше видно, что случаи эквивалентны, он выровняет и в случае резки на входе того роутера.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от Осторожный (ok), 23-Июн-09, 14:46
	>И теперь, очевидно то, что эти две схемы ЭКВИВАЛЕНТНЫ тому, чтобы повесить >входящие шейпящие фильтры на eth0 сервера, т.е. в направлении слева направо, >т.е. просто вклиниться в этот поток внутри eth0 - ибо зачем >нам ставить еще один роутер для такой простой задачи, dummynet ведь >умеет. согласен а то некоторые тут уверяют, что шейпить входящий траффик нельзя :)
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от www2 (??), 23-Июн-09, 14:55
	>согласен >а то некоторые тут уверяют, что шейпить входящий траффик нельзя :) Ну зашейпил ты входящий канал, а там 99% флуда. Буфер переполнился, полезные пакеты потерялись. Что дальше? А если будешь шейпить исходящий трафик, то сначала ты отфильтруешь флуд, а потом уже положишь в буфер и будешь потихоньку отдавать полезную информацию.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от Осторожный (ok), 23-Июн-09, 15:09
	>>согласен >>а то некоторые тут уверяют, что шейпить входящий траффик нельзя :) > >Ну зашейпил ты входящий канал, а там 99% флуда. Буфер переполнился, полезные >пакеты потерялись. Что дальше? Что есть флуд на входящем канале - конкретнее. > >А если будешь шейпить исходящий трафик, то сначала ты отфильтруешь флуд, а >потом уже положишь в буфер и будешь потихоньку отдавать полезную информацию. Телепат ? Кто тебе сказал, что не буду шейпить в обе стороны ? Еще как буду.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от vitek (??), 23-Июн-09, 15:20
	>Кто тебе сказал, что не буду шейпить в обе стороны ? как? пример выше - фикция. виртуальный роутер - уже внутри сети. с таким же успехом шейпится исходящий трафик для внутренних машин. только лишняя нагрузка на роутер. поставьте там хоть 1000 машин - это никак не повлияет на тот единственный входящий интерфейс. а там пришло 10 пакетов - обработай, 100 - тоже обработай, 1000 - тоже,... система перестала справляться. :-D
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от www2 (??), 23-Июн-09, 16:00
	>>>согласен >>>а то некоторые тут уверяют, что шейпить входящий траффик нельзя :) >> >>Ну зашейпил ты входящий канал, а там 99% флуда. Буфер переполнился, полезные >>пакеты потерялись. Что дальше? > >Что есть флуд на входящем канале - конкретнее. Ну например у тебя NAT-роутер. Изнутри наружу установлено несколько соединений. А тут бац - и кто-то снаружи заливает на 25 закрытый на NAT-шлюзе TCP-порт кучу говна. Это говно переполняет входной буффер и в результате в общей массе говна начинают растворяться полезные пакеты, связанные с сессиями, установленными изнутри. >>А если будешь шейпить исходящий трафик, то сначала ты отфильтруешь флуд, а >>потом уже положишь в буфер и будешь потихоньку отдавать полезную информацию. > >Телепат ? >Кто тебе сказал, что не буду шейпить в обе стороны ? >Еще как буду. Смысл не в этом, а в том что у тебя во входном буфере флуд будет вытеснять полезные пакеты. А если ты будешь шейпить только на исходящем интерфейсе, то в буфер отдачи попадёт только полезная информация, а говно зарежется фаерволлом ещё до попадания в буфер.
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от Осторожный (ok), 23-Июн-09, 21:54
	>>Что есть флуд на входящем канале - конкретнее. > >Ну например у тебя NAT-роутер. Изнутри наружу установлено несколько соединений. А тут >бац - и кто-то снаружи заливает на 25 закрытый на NAT-шлюзе >TCP-порт кучу говна. Это говно переполняет входной буффер и в результате >в общей массе говна начинают растворяться полезные пакеты, связанные с сессиями, >установленными изнутри. Эмммм. А ты firewall/nat вообще настраивал хоть раз в жизни ? Потому как если настраивал, тогда бы знал что залить на закрытый TCP-порт кучу не получится. Вообщем даже если нет никакого firewall, то тоже не получится :) Можно за-DDOS-ить роутер. Но если тебя начнут DDOS-ить, то никакой шейпер тебе не поможет. >>Телепат ? >>Кто тебе сказал, что не буду шейпить в обе стороны ? >>Еще как буду. > >Смысл не в этом, а в том что у тебя во входном >буфере флуд будет вытеснять полезные пакеты. А если ты будешь шейпить >только на исходящем интерфейсе, то в буфер отдачи попадёт только полезная >информация, а говно зарежется фаерволлом ещё до попадания в буфер. Ты то ли прикалываешься, то ли просто не знаешь о чем говоришь. Ну с чего ты взял, что у меня только шейпер и нет firewall ? Сначала firewall отбросит весь мусор. Потом что останется, пойдет через один или несколько шейперов.
	Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

	171. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от User294 (??), 23-Июн-09, 22:43
	>Потому как если настраивал, тогда бы знал что залить на закрытый TCP-порт >кучу не получится. Да что вы говорите?А я всю жизнь думал что сначала вам по вашему каналу пакеты все-таки прилетят.А потом вы сможете их грохнуть на вашем файрволе если вдруг захотите, на основании каких-вам-там-удобно критериев.Как и отполисовать при передаче дальше, если вам это надо.Проблемка у вас будет ровно одна - эти пакетики канал идущий к вам уже заняли под себя на некое время.Потенциально обломав или затормозив например прохождение более полезных пакетов, если вдруг этого добра приехало слишком много.
	Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

	183. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от Осторожный (ok), 24-Июн-09, 08:25
	Какие пакетики на закрытый TCP-порт ? Да еще чтобы траффика было много ? Если это не DDOS-атака, то пакеты прилетят только SYN, а они мелкие и канал забить ими очень трудно. Если SYN-пакетов много, то это уже DDOS-атака и вообще ничего не поможет.
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

	224. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от User294 (??), 24-Июн-09, 18:04
	>Какие пакетики на закрытый TCP-порт ? Обычные.С технической точки зрения - всем глубоко похрену что там шлется в вашу сторону.Поэтому - в вашу сторону можно выстрелить как бы любые пакеты, включая любой набор пактов из протокола TCP и они до вас долетят.И в принципе ну никто не обязывает ремоту с ножом к горлу выплевывать эти пакеты в вас по общепринятым правилам - можно в вас кидать что угодно.Можно даже в правила RFC впихнуться если слать SYN пакеты оптом, допустим(хотя можно и любые иные).О том что это были пакеты на порт который у вас порт закрыт (или что эти пакеты не соответствуют установленной TCP сессии) знает только стек протоколов вашей операционки (ну или там ваш файрвол, etc).И вот когда оно выгребет эти пакетики из канала (канал ессно будет озадачен передачей этих пакетов энное время) - стэк протоколов сможет увидеть что да, пакет был на закрытый порт(или вообще не соответствует никакой TCP сессии), прибить гада!Ну и далее - или нифига (можно тихо убить пакет на закрытый порт файрволом) или отлуп RST пакетом (стандартное дефолтное действо) для информирования ремоты о этом факте или там еще чего (практикуются враки файрволом по ICMP о недоступности хоста, сети, ... например).Проблема при этом ровно одна - если пакеты вам шлют, вы их будете получать.И тощую соску от прова до вас они собой займут.Плевав на вашу недо-полисовку.А после прохождения по медленной соске вы их конечно же сможете разгрести, понять что это было на закрытый порт и даже если хотите - прибить, да.А вам от этого станет легче?Канал то уже был ими засран ими некое время а трафф мог вылезти за рамки желаемой полисовки:P.Возможно - в ущерб более полезным входящим пакетам если такого хлама - много.На полисовку оно покладет с прибором - пришлют не "сколько вы просили" а "столько сколько захотели" и вы с этой вашей недо-полисовкой ничего с этим поделать не сможете.Т.е. полисовка по сути идет лесом. >Да еще чтобы траффика было много ? Элементарно, Ватсон.Просто тупо шлем вам пакеты до упора.Наплевав на ваши RST пакеты (а также молчанку, враки файрвола что хост или сеть недоступна и прочая).И вы их будете получать.И выгребать.И, черт возьми, сколько пошлют и сколько из этого пролезет - столько и выгребете.А у вас варианты есть?Вы, конечно, можете потом убить гумно.А толку то?Ну да, ваша 100 мбит локалка будет чистой.Зато 10Мбит соска в интернет будет засрана пакетами.Много ли вы выиграли сэкономив в 100 мбит локалке 10Мбит?Да нихрена вы не выиграли - проблемы (например, барахловая работа VoIP и прочая) у вас будут от забитости вашей соски в интернет, а вовсе не... :) >Если это не DDOS-атака, то пакеты прилетят только SYN, а они мелкие В общем случае можно слать в вас любые пакеты.Можно и крупные.Или много мелких.То что они на закрытый порт или не соответствуют никакой TCP сессии - только вы и ваше добро и знаете.И то - только *после* того как вы их получите.Да, можно из мстительно прибить.А толку?Свое место в тощем канале они уже заняли.Возможно вместо более ценных входящих пакетов (e.g. VoIP).И фиг вы чего с этим сделаете, мистер тормоз.Вот пров может подыграть, отполисовав со своей стороны трафф до пихания в вашу узкую соску и даже приоретизировав некие пакеты в ущерб иным пакетам.Вот только для прова это будет полисовка *исходящего* траффика в вашу сторону.Прикиньте? :).С вашей стороны вы не сможете настолько же гарантированно и полноценно изобразить шейпинг и приоретизацию того что валится на вход, как максимум только некий эрзац с вагоном допущений и ничего не гарантирующий по большому счету. >и канал забить ими очень трудно. Не вижу проблем.В конечном итоге - можно слать любые пакеты.Все-равно о том что они были на закрытый порт или не соответствовали никакой TCP сессии знаете только вы.И то - вы узнаете это только после :))) того как они заняли собой вашу тощую соску :) >Если SYN-пакетов много, то это уже DDOS-атака DDoS подразумевает распределенную атаку.В данном случае никакой распределенности нафиг не надо.Надо всего-то не сильно тощий канал который сможет в сумме выбить траффик в вашем канале за пределы вашей желаемой полисовки.После чего скорее всего начнутся потери входящих пакетов, рост латентности и прочая радость.И как бы если пров не подыграет - пакеты, допустим, VoIP будут теряться наравне с пакетами флуда.И если меня без вопросов устроит что вы отбросили 50% флуда, вас очень врядли устроит что заодно отбросилось и 50% VoIP пакетов летящих к вам.Провадет со своей стороны мог бы подыграть отполисовав трафф до пихания в вашу соску - у него каналов больше и забить из намного труднее чем одну хилую соску к клиенту.Для прова это как раз и будет полисовка *исходящего* (в вашу сторону) траффа из его сравнительно быстрой сети в сравнительно медленный канал.Так же как вы можете полисовать обратный траффик.И вот такая полисовка - относительно честная.В том плане что как максимум можно закосить под иной тип пакетов.Но если накладывается допустим некий лимит на общий бандвиз траффа, этот лимит обойти не выйдет. >и вообще ничего не поможет. Ну вообще-то полисовка траффика провом до некоторой степени могла бы помочь.Например, те же VoIP пакеты пров может пихать в вашу соску первым делом а остальное - как выйдет.При необходимости отбрасывая лишки, etc.Да, это возможно вызовет некоторые трудности для конектящихся к вашему серверу клиентов.Но тем не менее, ему и так и сяк попа а вот критичный сервис который более приоритетный (e.g. VoIP) при этом выживет и будет работать даже, если отполисовать правильно и каналов провайдера хватило(а у него они как правило намного толще и их больше). ЗЫ вроде бы все в пределах обычной человечьей логики и понимания того как летают пакеты и где узкие места. ЗЗЫ а вы что, никогда не видели например утилитки генераторов пакетов которые просто шлют то что им сказали слать, глубоко наплевав на любые ответы ремоты?Тоже мне, сетевики фиговы :D
	Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

	178. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от www2 (??), 24-Июн-09, 07:22
	Всё-таки вам очень тяжело объяснить очевидное. Хорошо, попробуем описать ситуацию вот так. Есть внешний толстый канал в 100 мегабит/с. Есть 1000 клиентов, каждый может принимать со скоростью 100 килобит/с. Представим что у роутера на входе стоит буфер в 10 мегабайт. Представим что клиенты слушают радио или гоняют у себя IP-телефонию. И тут кто-то резко вливает в канал 10 мегабайт мусора, адресованному одному из клиентов. Входной буфер на роутере переполнился и все дальнейшие пакеты будут отбрасываться, не смотря на то, что они адресованы и другим клиентам тоже. Что будет делать роутер? Медленно отдавать эти 10 мегабайт одному клиенту со скоростью 100 килобит/с. Входной буфер роутера будет опустошаться в течение (1000000*8/100000=) 800 секунд. В это время все остальные клиенты встанут колом, поскольку входной буфер роутера всё это время будет медленно-медленно опустошаться, а новые пакеты для остальных клиентов принимать практически не будут. Теперь, если у вас есть немного логики, представьте если роутер будет заниматься шейпингом на исходящих интерфейсах. Эти 10 влитых неизвестно кем мегабайт попадут в буфер отдачи только одного из клиентов, пострадает только он, остальные после небольшого лага будут продолжать нормально работать. Ситуация хоть немножко прояснилась?
	Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

	192. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от nuclight (??), 24-Июн-09, 12:50
	Да, действительно, очень тяжело объяснять очевидное, когда собеседник имеет очень бредовые представления о работе роутеров и шейперов. Вот эта ваша ситуация: один входной буфер на 10 Мегабайт и несколько выходных, по буферу на каждого клиента - не имеет НИКАКОГО отношения к реальности. Входной буфер маршрутизатора обычно имеет емкость в несколько десятков пакетов (на фре по умолчанию net.inet.ip.intr_queue_maxlen=50), сетевуха тоже много их держать не может, т.е. по факту он принимает их со скоростью среды. Любые буфера бОльших размеров появляются, только если вы вводите шейпер. Однако цель шейпера - как раз избежать ситуации "один забил всех", поэтому, если мы вешаем по буферу на клиента, шейпер тут же их сортирует, в какой отправить, в результате избыток пакетов того клиента просто будет дропнут, как только не влезет в его буфер, буфера остальных - не пострадают. Еще раз, другими словами: описанного вами входного большого буфера НЕ СУЩЕСТВУЕТ, и если мы вешаем шейпер на вход, в данном случае dummynet в ipfw, он их тут же на входе ровно точно так же рассортирует по буферам клиентов, все счастливы.
	Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

	194. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от www2 (??), 24-Июн-09, 12:58
	>Еще раз, другими словами: описанного вами входного большого буфера НЕ СУЩЕСТВУЕТ, и >если мы вешаем шейпер на вход, в данном случае dummynet в >ipfw, он их тут же на входе ровно точно так же >рассортирует по буферам клиентов, все счастливы. Как же он рассортирует пакеты по выходным буферам, если решение о том, по какому маршруту пойдёт пакет, ещё не принято? А если он всё-таки рассортирует, то вы не находите что это уже не входной буфер, а выходные? Тогда объясните мне в чём отличие таких входных буферов в ipfw от выходных буферов в tc? В чём тогда вообще соль так рьяно отстаиваемого подхода на шейпинге пакетов на входе?
	Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

	202. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от zmc (?), 24-Июн-09, 13:37
	>Тогда объясните мне в чём отличие таких входных буферов в ipfw от >выходных буферов в tc? В чём тогда вообще соль так рьяно >отстаиваемого подхода на шейпинге пакетов на входе? Уважаемый www2, можно я обьясню :D Видите ли в чем дело, просто nuclight уже осознал что был не прав. А заевить это общественности после своих надменных постов слабо. Вот он бошку и дурит всем, своими постами.
	Ответить | Правка | К родителю #194 | Наверх | Cообщить модератору

	122. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от vitek (??), 23-Июн-09, 15:12
	дык и нельзя. объем входящего трафика всё равно этим не ограничешь. сколько из вне пришло, столько пришло. вывалели из вне 100Mb/s пакетов, так вывалили - разгребай дальше сам. :-D хоть 20 виртуальных роутеров эмулируй. это внутреннее дело внутренней сети с внутренними виртуальными роутерами. но хоть как-то рулить (нагрузку уже внутри своей сети) этот способ подходит. будет работать до тех пор, пока входящий трафик не будет стремиться к 100% нагрузки входящего интерфейса. а дальше - резкое увеличение нагрузки на эти "роутеры", потери пакетов и т.д. другой вопрос - а напуркуа ограничивать что-либо, если нагрузка позволяет? в 21 веке унлим всё-таки! :-D
	Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

	146. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от User294 (??), 23-Июн-09, 17:50
	>а то некоторые тут уверяют, что шейпить входящий траффик нельзя :) Картина маслом: я шлю вам SYN пакеты (или какие угодо иные пакеты долетающие до вас, не принципиально) на всю толщину вашего канала.На ваши потуги изобразить что-то там средствами TCP - кладу хрен.Внимание, вопрос: много ли будет толку с вашего недо-шейпинга?Канал у вас засрется, мои пакеты будут валиться вам на вход по сравнительно узкому каналу без какой-либо приоретизации - наравне с полезными для вас, сильно уронив их скорость доставки и, возможно, вызвав солидные потери.Это не шейпинг, это так, эрзац.
	Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

	147. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от Одмин (?), 23-Июн-09, 18:45
	Мде... Благородный дон, если бы весь трафик состоял из атак то может быть ты бы и был прав, а когда бОлшая часть трафа составляют tcp-сессии то проблем нет. Когда у тебя весь канал забит флудом то тебе не то что шейпер не поможет, тебе ничего не поможет кроме как помощь провайдера. И не надо говорить что шейпить tcp-трафик невозможно только потому что ты это не осилил. Прекращай свои интелектуальные способности на весь инет демонстрировать.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от vitek (??), 23-Июн-09, 19:03
	больша часть "трафа" - http и иже с ним. толку что он tcp. соединение устанавливается и рвётся. в любом случае, всё что Вы можете - это пропускать его в локалку или нет (в этот момент он уже припёрся и находиться в буфере), а также пропускать ответ или нет, или медленно пропускать. входящий же пакеты сваляться к Вам на той скоросте передающей среды - см. "Физический уровень" http://ru.wikipedia.org/wiki/%D0%A1%D0%B... >И не надо говорить что шейпить tcp-трафик невозможно только потому что ты это не осилил. входящий, багородный дон, входящий. речь только о нём. кстати, очень заметно, кто ниасилил. >Прекращай свои интелектуальные способности на весь инет демонстрировать. вот именно.
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от nuclight (??), 24-Июн-09, 12:53
	>больша часть "трафа" - http и иже с ним. >толку что он tcp. соединение устанавливается и рвётся. [...] >>Прекращай свои интелектуальные способности на весь инет демонстрировать. > >вот именно. Действительно, прекращайте. С понятием "slow start" в tcp вы явно не знакомы, если, по вашему, быстро закрываемые сессии невозможно шейпить. Ну-ну. Сходите, что ли, Стивенса почитайте, хотя бы.
	Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

	214. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от vitek (??), 24-Июн-09, 14:52
	когда ж ты угомонишься то? ну пролетел ты, с кем не бывает? :-D
	Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

	226. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от User294 (??), 24-Июн-09, 18:20
	>Действительно, прекращайте. С понятием "slow start" в tcp вы явно не знакомы, Есть одна проблема - все это допускает что все ремотные юзеры белые, пушистые и делают ровно то что вы им скажете.Т.е. все это очень эфемерно и негарантированно.Работает только с конкретными типами траффика, просто обходится и нифига по большому счету не гарантирует.Т.е. завалить вам допустим работу VoIP невзирая на якобы шейпинг и якобы приоретизацию - не вопрос.Т.е. честной полисовки на вход с приемной стороны тощей соски в общем то не получается.Получается некое подобие как максимум.Без реальных гарантий качества сервиса и с рядом ограничений и допушений.
	Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

	162. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от User294 (??), 23-Июн-09, 22:12
	>Благородный дон, если бы весь трафик состоял из атак то может быть ты бы и был прав, а >когда бОлшая часть трафа составляют tcp-сессии то проблем нет. Проблем нет ... ровно до тех пор пока удача улыбается вам лицом.А если повернется попой (траффик окажется "не тот" или кто-то будет гавнюком и не будет с той стороны провода кооперативен с вашими потугами что-то этакое изобразить) - проблемы у вас будут.Посему это именно недо-шейпинг.Шейпинг исходящего траффа в узкий канал дает кой-какие гарантии и приоритеты там не липовые а реальные - наиболее приоритетные пакеты первыми полетят в медленный канал, остальные подождут, а при нужде и выкинутся в нужном количестве.Сие позволяет достичь какой-то предсказуемости и гарантий и там пофиг - UDP, TCP, ICMP или что там еще - не принципиально.В отличие от довольно халтурных потуг что-то там поиметь довольно левыми методами  требущие весьма вольных допущений о природе траффа и кооперативности ремотных систем насчет потуг это регулировать.Эрзац - получается.А вот честно и гарантированно как с исходящим - фиг!Только если кто-то с другой стороны канала зашейпит и отполисует ДО впихивания это в медленный канал к вам.А после - уже поздно что-то там полисовать в общем случае. >Когда у тебя весь канал забит флудом то тебе не то что шейпер не поможет, >тебе ничего не поможет кроме как помощь провайдера. У провайдера как правило суммарная емкость каналов на порядки превышает скорость типового канала до пользователя.Посему грамотный шейпинг и полисовка с той стороны канала может в принципе решить эту проблему - путем отстрела или придерживания "неправильных" пакетов в пользу "правильных".Чем собственно и занимаются при шейпинге и полисовке траффа по нормальному.При этом в нормальном исполнении (2 железки с обоих сторон медленного канала честно шейпят и полисуют свое исходящее направление) все будет так как надо.С какими-никакими предсказуемыми параметрами и возможностью что-то гарантировать и реально доставить одни пакеты, частично пожертвовав другими.С одной стороны - не получится нормально.Получится эрзац который никому ничего не гарантирует по большому счету.И если в вас прилетит 5 мегов левых пакетов в 20 мбит канал - может так получиться что вы пару секунд будете левак выгребать а только потом "приоритетные" VoIP пакетики получите.А вот реальное время ждать вас разумеется при этом не станет. > И не надо говорить что шейпить tcp-трафик невозможно только потому что ты это не осилил. Ха-ха, мне нравится такая аргументация :).Ну, знаете, если я пришлю вам эн мегабит SYN пакетов (или любых иных пакетов протокола TCP) - это тоже с формальной точки зрения TCP траффик.А вот отполисовать его вы обломаетесь если я буду некооперативен на этот счет и положу на ваши потуги болт.А, собственно, что мне запретит просто кидать в вашу сторону пакеты?Отказаться от их получения вы в общем случае не сможете.Канал оно займет точно так же как и любой иной траффик, не факт что менее приоритетно чем нужные вам пакеты(если пров не подыграет с его стороны).Полисовка получается весьма лажовая.А теперь вы пробуете сделать то же самое с честной полисовкой исходящего траффа и понимаете разницу :).При этом более приоритетные пакеты (например VoIP) будут отправлены раньше.А общая скорость потока может быть реально огранчена - отбросом "лишнего", если его продолжают валить быстрее чем разрешено :) > Прекращай свои интелектуальные способности на весь инет демонстрировать. Так это... а конструктивные аргументы будут? :D
	Ответить | Правка | Наверх | Cообщить модератору

	229. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от Хм... (?), 24-Июн-09, 21:24
	>Мде... > >Благородный дон, если бы весь трафик состоял из атак то может быть >ты бы и был прав, а когда бОлшая часть трафа составляют >tcp-сессии то проблем нет. > >Когда у тебя весь канал забит флудом то тебе не то что >шейпер не поможет, тебе ничего не поможет кроме как помощь провайдера. И пров тоже не поможет :) потомукак его канал тоже флудом забит :)
	Ответить | Правка | Наверх | Cообщить модератору

	251. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от User294 (??), 25-Июн-09, 23:39
	>И пров тоже не поможет :) потомукак его канал тоже флудом забит >:) Забить прововские каналы флудом труднее чем одну тощую соску.Которую обычно и хотят отполисовать потому что в нее то все и упирается.
	Ответить | Правка | К родителю #229 | Наверх | Cообщить модератору

	158. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от Осторожный (ok), 23-Июн-09, 21:58
	А я что где-то говорил, что нельзя за-DDOS-ить роутер ?
	Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

	167. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от User294 (??), 23-Июн-09, 22:20
	>А я что где-то говорил, что нельзя за-DDOS-ить роутер ? Это строго говоря не ддос (сие не обязано быть распределенной атакой, ни даже syn-пакетами), просто кому-то достаточно проявить некооперативность насчет ваших потуг, наплевав на ваши попытки уменьшить скорость потока такими методами.При этом поток вылезет за заданные рамки и вы тем более не можете контролировать - чего вам нужнее а что можно отбрость.Так что в случае чего - voip и прочая будут терять пакеты точно так же как и остальное.Если пров не поможет полисовкой со своей стороны канала.Это не DDoS.Это элементаное покладание на лажовую полисовку которая зависит от кооперативности ремоты на этот счет.И вылезти за заданные вами пределы по зубам даже единичной ремоте если у нее канал толстый.И какой толк от задачи пределов если они только в идеальных условиях работают? Попадается некооперативная ремота - полисовка идет лесом.С честной полисовкой (исходящий трафф в узкий канал) сие проблемой как бы не является (более приоритетные пакеты все-равно пролетят раньше а остальное - как получится, отбрасываясь по мере необходимости и общая скорость потока может оставаться не выше заданной, с некими гарантиями на этот счет, которые не идут лесом и при потугах флудерасов и прочая).
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от User294 (ok), 23-Июн-09, 14:54
	>Ну да. Но TCP абсолютно пофиг, где именно его резать, ему важно >лишь направление. Вот только блаародный дон упускает несколько моментов... 1) В природе есть не только TCP. 2) Предполагается что ремота кооперативна и соблюдает правила игры.Что как-то не гарантированно.Мало чтоли ли malicious фруктов на свете и прочих неожиданностей? 3) По большому счету от ВАС нихрена не зависит в каком порядке в вашу сторону выдавит пакеты провайдер в вашу соску (как максимум, можно например договориться с провайдером насчет приоретизации определенного траффа в вашу сторону, etc).Поэтому ситуация когда вам пришлют сначала 5 мегов гумна а только потом VoIP пакеты которые вы так ждали - вашим шейпингом не исключается нифига.С соответствующими последствиями для латентности VoIP, разумеется.Т.к. сначала вы будете получать по тощей соске 5 мегов гумна а только потом - "приоритетные" с вашей точки зрения пакеты.При том соска обычно сильно тоньше чем LAN и время профуканное на вот это будет на порядки больше чем время которое вы там выиграете отприоретизировав пакеты выплюнутые в сторону LAN. Итого?Идея шейпить траффик на вход может и красива.Но достаточно своеобразно работает в типовой ситуации, когда на вход относительно тощая (по сравнению с скоростью LAN) соска вносящая основные задержки, а после шейпящего девайса - скоростная LAN.Шейпить пакеты на прием было бы намного эффективнее в совсем другом месте.Как правило нихрена вам не подконтрольном - с другой стороны соски, только это уже на совести провайдера, а вы по этому поводу сделать в общем то мало что можете.Разве что с провайдером договориться.А то что с той стороны канала соблюдают правила игры - не гарантированно.Могут например начать вдувать вам N мегабит syn-пакетов в одностороннем порядке.Не ожидая от вас ответ.И толку от вашего шейпинга при этом?Вот шейпинг и правильная приоретизация с другой стороны тощей соски могла бы иной раз и поменять картину, да (если каналов провайдера хватит а вашей тощей соски уже нет).Только это не с вашей стороны тощей соски рулится...
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	198. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от nuclight (??), 24-Июн-09, 13:28
	>>Ну да. Но TCP абсолютно пофиг, где именно его резать, ему важно >>лишь направление. > >Вот только блаародный дон упускает несколько моментов... >1) В природе есть не только TCP. Ну и? :) Протоколы/приложения, которым не пофиг, организуют свои собственные механизмы congestion control. А которые нет, тех либо мало в общей доле, либо для них организуются специальные политики шейпинга. >2) Предполагается что ремота кооперативна и соблюдает правила игры.Что как-то не гарантированно.Мало >чтоли ли malicious фруктов на свете и прочих неожиданностей? Ыыы. Идите-ка почитайте RFC. Если ремота не будет в таких вопросах кооперативна, у неё просто самой ничего не будет работать. Если же идут атаки - это вообще совершенно отдельный случай, который в этом разговоре - как собаке пятая нога. >3) По большому счету от ВАС нихрена не зависит в каком порядке Я не стал этот бред цитировать, уже разобрал его в комменте про буфер размером в 10 мегабайт. >Итого?Идея шейпить траффик на вход может и красива.Но достаточно своеобразно работает в >типовой ситуации, когда на вход относительно тощая (по сравнению с скоростью Очень странно, почему же у меня всё прекрасно работает? :) >А  то что с той стороны канала соблюдают правила игры - не >гарантированно.Могут например начать вдувать вам N мегабит syn-пакетов в одностороннем порядке.Не >ожидая от вас ответ.И толку от вашего шейпинга при этом?Вот шейпинг Молодой человек, вы путаете две совершенно разные ситуации - шейпинг, рассчитанный на _нормальную_ работу, и DoS/DDoS-атаку. Если вам полностью засрали входящий канал - вам ТОЧНО ТАК ЖЕ не поможет и шейпинг на исходящем интерфейсе. А весь разговор ведётся как раз про разницу входящего и исходящего.
	Ответить | Правка | Наверх | Cообщить модератору

	217. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от User294 (ok), 24-Июн-09, 15:21
	>Ну и? :) Протоколы/приложения, которым не пофиг, организуют свои собственные >механизмы congestion control. Допустим есть VoIP.Как правило - UDP.Ему не пофиг латентность и потери пакетов.И его логично приоретизировать.На исходящее - фигня вопрос.А вот на вход с вашим недо-шейпингом ничего не выйдет. >А которые нет, тех либо мало в общей доле, Зато важные штуки бывают, типа VoIP например. > либо для них организуются специальные политики шейпинга. А зашейпьте-ка с вашей стороны банальный ping -f присланый снаружи в ваш тощий канал?Вот и посмотрим как ваш кульный шейпер на вход отработает, хе-хе ;).Что?Он будет выгребать столько сколько отправят или сколько пропихает канал?И даже возможно полезные пакеты (e.g. VoIP) просрутся или задержатся?Ну так какой же это тогда шейпинг и полисовка?Это так, фигня какая-то :) >Ыыы. Идите-ка почитайте RFC. Если ремота не будет в таких вопросах кооперативна, >у неё просто самой ничего не будет работать. И что?А кто сказал что ремоту это вообще смущает?Если ремота скажем поставила цель испортить вам компот - это ремоте похрену.А интернет как бы уже давно не детская площадка для игры в песочек, там и поднасрать могут запросто.А также возможны разные веселые методы покладания на вашу недо-полисовку.Например, завернуть все TCP конекции в openvpn гуляющий по UDP.Далее ваша полисовка на вход немножко отправится лесом т.к. с точки зрения полисовщика будут удп-пакеты, которым не больно то окна потвикаешь и SACKов у них как бы нет, а то что там внутрях - кто ж его знает? :).С честной полисовкой так не катит.Как максимум можно проапгрейдить свой класс траффика.Но, например, вылезти за глобальный лимит скорости шейпера - проблематично.Посему нормальный шейпинг - именно вот так.На *исходящее* направление. А так - допустим я хочу вам завалить VoIP.И введу ping -f на своей машине с толстым каналом.Вас устроит что у вас начнут гробиться VoIP пакеты в пользу бесполезного ICMP флуда оптом который займет канал на равных с VoIP если с той стороны канала не подыграют?Ну и були толку с вашей "полисовки" если она от одной команды выходит за лимиты и начинают теряться полезные пакеты? >Если же идут атаки Это не атаки.А просто целенаправленное забивание на халтурно сделаную полисовку работающую с левыми допущениями. См. например пример с openvpn - так можно некисло проапгрейдить себе скорость скачки у таких тупорылых полисовщиков которые с чего-то вдруг возомнили что можно нормально шейпить скорость с приемного конца медленной соски :) >- это вообще совершенно отдельный случай, который в этом разговоре >- как собаке пятая нога. Ну я вам вон выше нарисовал менее атакерский случай - просто апгрейд скорости скачки путем юзания openvpn до своего хоста например :).При этом даже не требуется класть хрен на RFC, если уж вас это так смущает :).По сути - это просто нахальный абузеж вашей халтуры в полисовке.Называть это атаками - жирновато.Любой дятел с ping -f и более толстым чем у вас каналом - хакиръ чтоли?!Ха-ха-ха, ну тогда в мире миллионы "хакеров" :) >Очень странно, почему же у меня всё прекрасно работает? :) ИМХО по одной причине - работает ровно до тех пор пока эту полисовку не попытаются обойти а траффик соответствует тому что ожидается.Т.е. профиль траффа соответствует тому что вы ожидаете и никто не пытается испортить вам компот.А для серьезных и ответственных применений, как то например корпоративщикам VoIP приоретизировать - вот так вота опаньки будет.Для локалки в сельпо - сойдет и так, в допущении что все вокруг идиоты а вы один такой умный а потому никто и никогда не будет абузить вашу халтуру в полисовке. И кстати нарваться на атаку - говно вопрос.Это не вы там торрент упоминали?Ну так вот, JFYI есть вагон фирм которые торренты и прочих очень не любят.Поэтому встречаются очень разные выкрутасы.Отдельные уроды узрев вас с вашим торентом шлют в вашу сторону все что угодно в надежде создать проблемы.Встречал и несколько случаев откровенного наглого флуда в мою сторону.Пару раз умудрялись в хлам засрать 10Мбит канал в интернет например (я это пролечивал сменой айпи, у прова каналы толстые... :D). >Молодой человек, вы путаете две совершенно разные ситуации - шейпинг, рассчитанный на >_нормальную_ работу, и DoS/DDoS-атаку. Нет, я просто различаю *нормальный* шейпинг, который не вылезет за глобальные лимиты даже при наглежке и попытках выкрутасов равно как будет честно пытаться пихать более приоритетные пакеты нежели менее приоритетные и всякую халтуру которая работает только если ей подыгрывают с другой стороны, с вагоном оговорок и допущений, и которая легко вылезает за заданные лимиты как только траффик становится "не тот" и которая не может честно приоретизировать важные пакеты при нужде частично отбросив менее важные. >Если вам полностью засрали входящий канал - вам ТОЧНО ТАК ЖЕ >не поможет и шейпинг на исходящем интерфейсе. А вот и нет.В типичном случае суммарная мощность каналов провайдера на несколько порядков больше чем тощая соска идущая от провайдера к клиенту.Поэтому если железка со стороны провайдера применит шейпинг и полисовку ее исходящего интерфейса (который с той стороны медленного канала с которого вы данные выгребаете) - все будет оки-доки.Грубо говоря, допустим у прова несколько 1Гбит каналов, засрать их нелегко.К вам соска 10 Мбит.Вам шлют вам 20 мбит флуда.Канал 10 мбит очевидно сам по себе засрется в хлам.А вот если железка у прова первыми выдавит в канал VoIP пакеты а остальное - как получится - VoIP будет без проблем летать и дальше.А остальное (включая и флуд) - как получится, ну не влезет половина флуда в канал и отправится прововской железкой в /dev/null, и чего? Ну и некоторые иные критичные типы траффика можно точно так же выделить.Равно как и более жестко заполисовать некие типы флуда.Скажем на случай козлов с ping -f можно (ессно с провайдерской стороны медленной соски) нарулить политику которая ограничивает скорость ICMP пакетов, а что сверх того - в трэш.В итоге если некто на 50 мбит канале введет в вашу сторону ping -f а у прова на железке полися что в вашу сторону не более 1 Мбит ICMP а остальное в треш - в вашем канале будет 1Мбит ICMP.Еще 49Мбит отлетят в /dev/null.Если это был все тот же 10Мбит канал, у вас останется 9Мбит свободного бандвиза и никаких проблем как бы не будет :).Единственная "проблема" что пров спускает 49 Мбит траффа вникуда.До тех пор пока его каналы не переполнены - это всем похрену. >А весь разговор ведётся как раз про разницу входящего и исходящего. Ну так разница в полисовке входящего и исходящего - есть.Исходящий можно честно и жестко полисовать без вольных допущений.Входящий - черта с два пополисуешь по нормальному с приемной стороны медленной соски.С прововской стороны - да, можно.Но это, пардон, провайдер может сделать с его стороны соски.А вовсе не вы... и для него это будет опять же честный шейпинг ИСХОДЯЩИХ (в вашу сторону) пакетов. Если кто настолько дуб и еще не понял - IP так устроен что пытается доставить все пакеты которые в вас кидают вам.Сие не было сделано в рассчете на malicious use или полисовку.И нынче данное свойство немного икается, потому что не все в мире белые и пушистые а стандартных методов отказаться от получения траффика "от вон той ремоты" в IP попросту нет.Так что если кто-то вам шлет 100 мбит говна и никто (типа провайдера с более толстыми каналами) вам не поможет в фильтровке и полисовке (а по дефолту все обычно именно так) - вы будете выгребать 100 Мбит говна.Или сколько там из этого осилите :)
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от zmc (?), 23-Июн-09, 18:45
	Блин модераторы зачем пост зарезали там не так много матов было :-) Для особо упрямых и непонятливых типа nuclight'ов, _umka_'ов, а так же осторожных и иже с ними. >ОК, расскажите же мне, как пошейпить пришедший самому серверу (т.е. его собственный IP) на >eth0 входящий трафик, если исходящие фильтры висят только на смотрящем во внутреннюю сеть к >клиентам eth1 ? А на сервере запущен торрент-клиент, который хорошо так кушает канал, если не >пошейпить :) 1. Повешать фильтр на eth0 на исходящие из LAN сегмента 2. Фильтр на тот же eth0 от самого сервера 3. Убить торрент клиент на сервере А TCP по скорости сам все подгонит >[оверквотинг удален] >[провайдер]--[eth0]--[другой роутер]--[eth1]--[eth0]--[сам сервер]--[eth1]-[внутренние машины] > >Видно, что если поставить ПЕРЕД сервером еще один роутер, исходящие фильтры на eth1 этого >другого роутера будут ПЕРЕД eth0 нашего качающего сервера, и будут включать в себя ВЕСЬ >трафик, потому что этот виртуальный роутер не будет иметь трафика, предназначенного для себя. > >И теперь, очевидно то, что эти две схемы ЭКВИВАЛЕНТНЫ тому, чтобы повесить входящие шейпящие >фильтры на eth0 сервера, т.е. в направлении слева направо, т.е. просто вклиниться в этот поток >внутри eth0 - ибо зачем нам ставить еще один роутер для такой простой задачи, dummynet ведь >умеет. Единственное чего вы добьетесь если поставите фильтр на входящий с eth0, так это балансировку сегмента - [eth1]-----[внутренние машины], но ни как не - [канал к провайдеру]-----[eth0]. Если пров послал тебе в общей сложности 3 Мбайта в секунду, то ты эти 3 мега и получешь на своей сетевке, то есть канал свой ты на это количество трафика в еденицу времени уже забил и ни чего ты с этим уже не зделаешь. Люди ну подумайте головой как вы можете огроничивать то что от вас не зависит. nuclight вот ты вот рисуешся знаниями SACK, congestion control, RED/GRED, а в этом вопросе палишся же.
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	172. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от User294 (??), 23-Июн-09, 22:56
	>nuclight вот ты вот рисуешся знаниями SACK, congestion control, RED/GRED, а в >этом вопросе палишся же. Ну не понимает чувак что в общем случае ремота не обязана быть кооперативной и играть строго по придуманным правилам.А итог?Простой и всем известный ping -f с достаточно толстого канала (достаточного для забития канала недругу) скорее всего банально похоронит VoIP у додиков с такой "полисовкой" - приведя к большим потерям и задержкам входящих VoIP пакетов.Гули толку с такой недоношенной "полисовки", если любой дятел может на нее положить 1 командой болт?Вот если пров начнет полисовать *исходящие* (в медленный канал юзера) пакеты ICMP допустим по правилу "не более 20 кбит а остальное в треш" - канал у юзера забьется лишь на 20 кбит.А остальное отлетит в /dev/null и не будет представлять для юзера да и всех остальных никаких проблем до тех пор пока намного более мощные каналы прова способны справиться с данной нагрузкой (зафлудить провайдера - более другая задача чем зафлудить додика на тощем канале, а?).
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от nuclight (??), 24-Июн-09, 13:17
	>1. Повешать фильтр на eth0 на исходящие из LAN сегмента >2. Фильтр на тот же eth0 от самого сервера Ага, то есть вы предлагаете шейпить ответные ACK'и от клиента к отправителю. Загвоздка в том, что вы не сможете описать все такие ситуации в терминах просто шейпинга трафика - бывают ретрансмиты, количество ответного трафика от приложения клиента тоже непредсказуемо, и т.д. Этот вариант в теории рабочий, но на практике будет работать плохо. Шейпинг прямого трафика гораздо адекватнее. >3. Убить торрент клиент на сервере То есть, вы расписываетесь в том, что не сможете справиться с такой ситуацией лишь исходящими филтрами :) Что и требовалось показать. >А TCP по скорости сам все подгонит Он это и при входящем шейпинге подгонит точно так же. >>[провайдер]--[eth0]--[другой роутер]--[eth1]--[eth0]--[сам сервер]--[eth1]-[внутренние машины] >> >Единственное чего вы добьетесь если поставите фильтр на входящий с eth0, так >это балансировку сегмента - [eth1]-----[внутренние машины], но ни как не - >[канал к провайдеру]-----[eth0]. Ваша проблема в том, что вы мыслите не в тех терминах. Мы балансируем сегмент [сам сервер]--[eth1]--[внутренние машины], а не сегмент [сам сервер]--[eth1]-[внутренние машины], который только и можно зашейпить исходящими. А на сегмент [канал к провайдеру]-----[eth0] мы не влияем, повлиять не можем, но это и не надо - он эквивалентен участку [аплинк провайдера]--[провайдер], на который нам тоже наплевать. >Если пров послал тебе в общей сложности 3 Мбайта в секунду, то >ты эти 3 мега и получешь на своей сетевке, то есть >канал свой ты на это количество трафика в еденицу времени уже >забил и ни чего ты с этим уже не зделаешь. Ну и что? Головой-то думать кто будет? Шейпинг, в отличие от полисинга, оперирует не только текущим моментом, когда оно пришло, и ничего не сделаешь - но и будущим. На которое уже можно повлиять. >Люди ну подумайте головой как вы можете огроничивать то что от вас >не зависит. Ага-ага. По этим словам, шейпинг вообще невозможен - как мы можем повлиять на то, с какой скоростью сервер где-то в инете отдает клиенту трафик, он же от нас не зависит! >nuclight вот ты вот рисуешся знаниями SACK, congestion control, RED/GRED, а в >этом вопросе палишся же. Это просто у вас в голове каша, и как оно всё работает, в полную картину не укладывается. Проблема-то не у меня - у меня вон шейпинг входящих прекрасно работает :)
	Ответить | Правка | К родителю #148 | Наверх | Cообщить модератору

	210. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от zmc (?), 24-Июн-09, 14:17
	>Загвоздка в том, что вы не сможете описать все такие ситуации >в терминах просто шейпинга трафика - бывают ретрансмиты, количество ответного трафика >от приложения клиента тоже непредсказуемо, и т.д. Этот вариант в теории >рабочий, но на практике будет работать плохо. Шейпинг прямого трафика гораздо >адекватнее. Я конечно не такой умный как .... Но вот в связке iptables+iproute(tc), у меня больше шансов чем ... >То есть, вы расписываетесь в том, что не сможете справиться с такой >ситуацией лишь исходящими филтрами :) Что и требовалось показать. Вот после этого я уж не сколько не удивлюсь, если вдруг вы окажетесь латентным виндузятником, который в добавок еще и сидит под рутом. Торрент клиент на сервере - не нужно оно там. >Ваша проблема в том, что вы мыслите не в тех терминах. Мы >балансируем сегмент [сам сервер]--[eth1]--[внутренние машины], а не сегмент [сам сервер]--[eth1]-[внутренние машины], >который только и можно зашейпить исходящими. А на сегмент [канал к >провайдеру]-----[eth0] мы не влияем, повлиять не можем, но это и не >надо - он эквивалентен участку [аплинк провайдера]--[провайдер], на который нам тоже >наплевать. Бред, слов нет. >Ну и что? Головой-то думать кто будет? Шейпинг, в отличие от полисинга, >оперирует не только текущим моментом, когда оно пришло, и ничего не >сделаешь - но и будущим. На которое уже можно повлиять. Чего чего, сами то поняли че сказали это вы в сетевом  контексте эту охинею несете, ужас. >Это просто у вас в голове каша, и как оно всё работает, >в полную картину не укладывается. Проблема-то не у меня - у >меня вон шейпинг входящих прекрасно работает :) А позвольте узнать на выходе то же шейпите?
	Ответить | Правка | Наверх | Cообщить модератору

	239. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от Gra2k (?), 25-Июн-09, 07:45
	"Единственный способ контролировать вход это грамотно резать выход, а TCP сам выровняет." чушь какая, где вы этому начитались? Советую книгу протокол TCP/IP for Linux.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	240. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от zmc (?), 25-Июн-09, 09:07
	>чушь какая, где вы этому начитались? Советую книгу протокол TCP/IP for >Linux. А что вас поразило, то, что мы косвено можем контролировать вход балансируя выход или то, что "TCP сам выровняет". А литературу мне советовать не нужно, был тут один уже начитаный. Возмите лубую угодную вам техническую литературу по TCP/IP стеку и укажите мне где сказано обратное(страница, параграф) Если это будет авторитетный источник, я с радостью с вами соглашусь чесслово.
	Ответить | Правка | Наверх | Cообщить модератору

	246. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от Gra2k (?), 25-Июн-09, 20:17
	Вы уж тогда определитесь косвенно или единственный способ. В любой книге написано, если вы намекаете на то что без запроса нет и ответа, то могу привести несколько примеров, начиная с впн клиентов, кончая почтовиком. Когда выход ну ни как на вход не влияет, а наоборот. Или вот например отшейпите вы выход пакетики от пользователя на запрос фаила все равно пройдут рано или поздно, входящий вы не контролируете следовательно канал в итоге ляжет при совершенно ни каком исходящем трафике. Собственно к этому и относилось мое "Чушь какая", куча ситуация когда выход не повлияет на вход. Да и в ТСП не предусмотрено "сам выравняет" , посему и рекомендую, лучшую на мой взгляд, книгу по этому протоколу, написана легко, понятно, с примерами, и сразу кучу вещей становяться понятными и прозрачными, даже если вы спец по сетевым протоколам все равно рекомендую, есть на русском языке.
	Ответить | Правка | Наверх | Cообщить модератору

	253. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от zmc (?), 26-Июн-09, 04:08
	>если вы намекаете на то что без запроса нет и ответа, >то могу привести несколько примеров, начиная с впн клиентов, кончая почтовиком. Это вы о чем, мы с вами говорим совершенно о разных вещах, не поленитесь перечетайте еще раз топик. >Да и в ТСП не предусмотрено >"сам выравняет" , посему и рекомендую, лучшую на мой взгляд, книгу Я бы вам посоветовал перечитать рекоминдованную вами книгу еще раз да повнимательней. Вы меня конечно извените за прямоту, но я просил афторитетный источник коим вы не являетесь.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от www2 (??), 23-Июн-09, 12:31
	>Еще один, не знающий, как работает TCP. Ситуация: домашний сервер, который NAT >для еще двух машин. Нужно распределить поток так, чтобы сервер не >отжирал бесконтрольно полосу, не оставляя ничего домашним машинам, и чтоб они >его и друг друга тоже. Как? С только исходящими фильтрами - >это невозможно Перестаньте гнать пургу и ознакомьтесь со схемой iptables. Ознакомьтесь с понятием mangle на цепочках OUTPUT и FORWARD. Даже если на сервере настроен NAT (а точнее PAT), цепочки mangle работают с пакетами ДО того, как они попадут в NAT. Итог - трафик сервера можно обрабатывать наравне с трафиком от клиентов и никто никому мешать не будет. >сервер будет неучтен. Но вполне очевидно, что входящий шейпер >на входе внешнего интерфейса сервера эквивалентен конфигурации, когда перед сервером включается >еще один роутер, на котором конфигурируется исходящий шейпер в сторону сервера. Проблема в том, что при попадании трафика на входной интерфейс ты не сможешь отрезать оттуда заведомо бесполезные пакеты и не можешь сказать заранее по какому каналу они пойдёт дальше (если это роутер), а соответственно, не можешь сделать вывод до какой скорости какие пакеты урезать.
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	136. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от Fantomas (??), 23-Июн-09, 16:40
	>Перестаньте гнать пургу и ознакомьтесь со схемой iptables. Ознакомьтесь с понятием mangle >на цепочках OUTPUT и FORWARD. Даже если на сервере настроен NAT >(а точнее PAT), цепочки mangle работают с пакетами ДО того, как >они попадут в NAT. Итог - трафик сервера можно обрабатывать наравне >с трафиком от клиентов и никто никому мешать не будет. > Причем здесь  iptables, mangle, OUTPUT, FORWARD? Речь идет про ipfw. >Проблема в том, что при попадании трафика на входной интерфейс ты не >сможешь отрезать оттуда заведомо бесполезные пакеты и не можешь сказать заранее >по какому каналу они пойдёт дальше (если это роутер), а соответственно, >не можешь сделать вывод до какой скорости какие пакеты урезать. С ipfw сделаю это элементарно! :-)))
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от vitek (??), 23-Июн-09, 17:04
	>>Проблема в том, что при попадании трафика на входной интерфейс ты не сможешь отрезать оттуда заведомо бесполезные пакеты и не можешь сказать заранее по какому каналу они пойдёт дальше (если это роутер), а соответственно, не можешь сделать вывод до какой скорости какие пакеты урезать. >С ipfw сделаю это элементарно! :-)) обратно отправишь? типа - никого нет дома, заберите назад? :-D в любом случае, примешь, обработаешь, сделаешь вывод - что с ними делать дальше (дроп, режект, форвард,....) - и уже потом допать, режектить, раздавать кому и с какой скоростью.
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от User294 (??), 23-Июн-09, 22:29
	>обратно отправишь? типа - никого нет дома, заберите назад? :-D Пожалуется в ООН наверное - "вон та нехорошая ремота наплевала на мои тщетные потуги снизить скорость траффика от нее, поэтому моя полисовка траффика пошла лесом и вышла за заданные лимиты!"
	Ответить | Правка | Наверх | Cообщить модератору

	262. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от Freebsdun (?), 24-Окт-10, 23:24
	>>tc хоть и умеет разные дисциплины обслуживания у шейпера - но работает только для исходящего >>трафика (не надо мне рассказывать о ingress фильтрах - которые делаются через задний проход). > Уважаемый _umka_, мне кажется вы че то напутали, шейпинг имеет смысл только > на исходящем трафике и безразници где это в фряшном dummynet или > линуксовый iproute. > Да да именно для вас tc входит в состав пакета iproute. Если машина - только роутер, и всё - то да. Но ipfw может защищать и регулировать саму машину. Например, на ваш сервер нападают DDOS-атакой TCP-SYN на 22й порт. Машина в трауре, и Вы даже ничего не можете с эти сделать, т.к. Ваши попытки попасть на 22й порт пропадают в туче аналогичных. шейпинг входящего дает нам решение: ipfw pipe 99 config delay 1000 queue 1 mask src-ip 0xFFFFFFFF buckets 1024 ipfw add 100 pipe 99 tcp from any to me 22 setup В результате до обработки доберется не более 1 TCP-SYN пакета от каждого атакующего в секунду, и чтобы завалить ваш сервер понадобится не один, а тысяча атакующих.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	46. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от sauron (ok), 23-Июн-09, 08:22
	>tc хоть и умеет разные дисциплины обслуживания у шейпера - но работает >только для исходящего трафика (не надо мне рассказывать о ingress фильтрах >- которые делаются через задний проход). Шейпер можно ставить только на исходящий трафик. Любые вещи мы повесили фильтр на входящий трафик эмулируются через добавление фильтра на тот интерфейс который является исходящим. Учите теорию.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	56. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от iZEN (ok), 23-Июн-09, 08:58
	>Шейпер можно ставить только на исходящий трафик. Бред. Шейпер нужен там, где необходимо резать канал на полосы пропускания с соответствующей политикой занятия полос: пользователи либо равномерно делят всю полосу пропускания канала, либо каждый имеют фиксированные полосы пропускания от общей полосы канала.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Выполнено портирование ipfw и dummynet для Linux"	+2 +/–
	Сообщение от zmc (?), 23-Июн-09, 09:14
	>Бред. >Шейпер нужен там, где необходимо резать канал на полосы пропускания с соответствующей >политикой занятия полос: пользователи либо равномерно делят всю полосу пропускания канала, >либо каждый имеют фиксированные полосы пропускания от общей полосы канала. Блин да скоко вам обьеснять мы можем контролировать шейпером тока НАШ ИСХОДЯЩИЙ трафик и не как ни входящий, при любых условиях. Представь ты поставил pipe на вход с сетевухи и, что - порежешь ты его тока после того как карточка получит свои N байт трафика, а эти N байт уже забили твою полосу на N kbit/s. Блин где вас тока берут с умкой.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Выполнено портирование ipfw и dummynet для Linux"	+2 +/–
	Сообщение от Аноним (-), 23-Июн-09, 09:26
	>Блин да скоко вам обьеснять мы можем контролировать шейпером тока НАШ ИСХОДЯЩИЙ >трафик и не как ни входящий, при любых условиях. Представь ты >поставил pipe на вход с сетевухи и, что - порежешь ты >его тока после того как карточка получит свои N байт трафика, >а эти N байт уже забили твою полосу на N kbit/s. Типичное заблуждение, входящий TCP трафик очень хорошо шейпится за счет удерживания ACK пакетов и манипулирования размером окна. UDP действительно не порежешь.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от zmc (?), 23-Июн-09, 09:30
	>>Блин да скоко вам обьеснять мы можем контролировать шейпером тока НАШ ИСХОДЯЩИЙ >>трафик и не как ни входящий, при любых условиях. Представь ты >>поставил pipe на вход с сетевухи и, что - порежешь ты >>его тока после того как карточка получит свои N байт трафика, >>а эти N байт уже забили твою полосу на N kbit/s. > >Типичное заблуждение, входящий TCP трафик очень хорошо шейпится за счет удерживания ACK >пакетов и манипулирования размером окна. UDP действительно не порежешь. А как это сделать с помощью tc и pipe в dummynet?
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от User294 (ok), 23-Июн-09, 15:09
	>Типичное заблуждение, входящий TCP трафик очень хорошо шейпится за счет удерживания ACK >пакетов и манипулирования размером окна. При условии что ремота - кооперативна, а не просто срет в ваш адрес пакетами, поклав болт на эти ваши потуги :).Что довольно-таки вольное и мягкое ограничение.Да, оно работает до некоторой степени.Но в конечном итоге - ГАРАНТИЙ как бы ноль.Реально эффективно воздействовать на это может провайдер, шейпя с своей стороны канала исходящий (в вашу сторону) траффик.При этом можно честно приоретизнуть пакеты.В отличие от ваших полудохлых и читерских потуг это делать.Т.е. нормальный подход - если есть сравнительно тощий канал являющийся узким местом и быстрые сети с обоих его сторон (наиболее типовая ситуация ИМХО) - надо с обоих сторон шейпить исходящий трафф.Шейпить входящий ... "поздно пить боржоми когда почки отказали".Вы его уже получили пардон, а значит свое место в узком канале оно уже съело.И пофиг, зашейпите вы это дальше или нет.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	124. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от vitek (??), 23-Июн-09, 15:36
	>Типичное заблуждение, входящий TCP трафик очень хорошо шейпится за счет удерживания ACK пакетов и манипулирования размером окна. UDP действительно не порежешь. т.е. другими словами, тотже эффект - шейпим исходящий трафик для внутренней сети и исходящий же для внешней. :-D угу. притормозить это дело слегка могём. любым способом. держим в буферах на сколько хватит. и принимаем всё новые и новые соединения. :-D я всегда как-то (по простоте душевной, не иначе) думал, что управление трафиком, балансировка - нужны прежде всего для нагруженных сетей. а ограничевать просто так, назлу мерзкому юзверю... мне не понять. :-D
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	141. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от Fantomas (??), 23-Июн-09, 16:52
	>я всегда как-то (по простоте душевной, не иначе) думал, что управление трафиком, >балансировка - нужны прежде всего для нагруженных сетей. >а ограничевать просто так, назлу мерзкому юзверю... мне не понять. :-D А если он шакал, не дал админу пароль на торрент?
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от vitek (??), 23-Июн-09, 19:07
	хреновый админ тогда однако. у Вас же в бзде дерэйс есть. там даже пароли на ssh ловить можно. http://www.sunhelp.ru/archives/92-DTrace_vhodJawie_ssh_toZhe... или я ещё нету?
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от Fantomas (??), 23-Июн-09, 16:49
	>Блин да скоко вам обьеснять мы можем контролировать шейпером тока НАШ ИСХОДЯЩИЙ >трафик и не как ни входящий, при любых условиях. Представь ты >поставил pipe на вход с сетевухи и, что - порежешь ты >его тока после того как карточка получит свои N байт трафика, >а эти N байт уже забили твою полосу на N kbit/s. > >Блин где вас тока берут с умкой. Элементарно! Режешь сразу после ната.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	227. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от User294 (??), 24-Июн-09, 18:57
	>Элементарно! Режешь сразу после ната. Ха-ха, вы снаала получаете пакеты а потом можете их прибить, отполисовать и прочая.Вот только если проблема была в том что входящего направления канала не хватает и хочется полисовать и приоретизировать его - толку с всего этого ровно ноль.Пакеты уже прилетели и уже заняли на некое время канал под себя - в общем случае уже поздно что-то по этому поводу делать :D
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от sauron (ok), 23-Июн-09, 14:05
	Поясняю в случае исходящего трафика у вас есть бак с краниками и соотвественно вы можете крутить с какой скоростью из него льется. В случае входящего трафика бак с краниками находится на другой стороне. С какой скоростью вам их отправили с той скоростью вы их и получите. Для регулировки входящего трафика для клиента используется бак с краниками на том интерфейсе который является входящим для клиента и исходящим для вас. Учите матчать.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	195. "Выполнено портирование ipfw и dummynet для Linux"	+2 +/–
	Сообщение от nuclight (??), 24-Июн-09, 13:01
	Ну что же, если вы использовали такую аналогию, то сами подставились, я не виноват :) буду разжевывать и бить в ней же :) --[бак провайдера]---[краник1]---[бак роутера]--[краник2]--[бак клиента] Представили систему баков и краников, да? Так вот, если провайдер шейпит на исходе своего бака, он подкручивает краник1, если мы на своем исходе, мы крутим краник2, но если мы на своем входе - видно, что краник1 находится на той же самой трубе между провайдером и нами, она едина! И если мы будем шейпить на входе у себя, мы крутим кран на той же трубе, где находится краник1, не имеет значения, в каком месте трубы между двумя баками находится кран - труба без разрывов, вода несжимаема. Да, эта аналогия не вполне точна по отношению к сетям, но вы, во-первых, сами с ней подставились (так что возражения не принимаются), во-вторых, мысль об эквивалентности шейпа на входящем нас и исходящем аплинка хорошо показывает.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от www2 (??), 24-Июн-09, 13:25
	>Ну что же, если вы использовали такую аналогию, то сами подставились, я >не виноват :) буду разжевывать и бить в ней же :) Аналогия не верна и всё дальнейшее - чушь. Это ещё могло бы подойти для описания управления потоком трафика в сети Frame Relay, где приёмник и передатчик могут говорить друг другу о своей максимальной скорости приёма данных. Но для IP-сетей это в общем случае не верно. В IP-сетях роутер не может подкручивать краник провайдера, а потому использование шейпинга на входном потоке данных - чушь, которая нужна лишь упёртым "ценителям" ipfw и dummynet.
	Ответить | Правка | Наверх | Cообщить модератору

	244. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от Аноним (-), 25-Июн-09, 16:02
	>В IP-сетях роутер не может подкручивать краник провайдера, а потому использование >шейпинга на входном потоке данных - чушь, которая нужна лишь упёртым >"ценителям" ipfw и dummynet. И что характерно у этих упёртых получается. Как ни странно входящие шейперы работают даже на Чукотке при морозе. Да, они не помогут при перегрузке канала. Да есть ещё нюансы. Но в целом работают и гораздо эффективнее чем мифическое придерживание ACKов. Если бы принимающая сторона никак не могла влиять на скорость передающей, то любой ответ сервера с широким каналом ложил бы сети конечных провайдеров.
	Ответить | Правка | Наверх | Cообщить модератору

	204. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от sauron (ok), 24-Июн-09, 13:42
	>на своем входе - видно, что краник1 находится на той же >самой трубе между провайдером и нами, она едина! И если мы >будем шейпить на входе у себя, мы крутим кран на той >же трубе, где находится краник1, не имеет значения, в каком месте >трубы между двумя баками находится кран - труба без разрывов, вода >несжимаема. Вы забыли одну вещь. Краник 1 находится у провайдера, а не у вас крутить вы его не можете. Вы можете крутить только второй краник. >Да, эта аналогия не вполне точна по отношению к сетям, но вы, >во-первых, сами с ней подставились (так что возражения не принимаются), во-вторых, >мысль об эквивалентности шейпа на входящем нас и исходящем аплинка хорошо >показывает. Для IP сетей у вас должно быть две трубы одна на прием вторая на отдачу. На той трубе что на отдачу кран вы можете крутить, а на той что получаете нет.
	Ответить | Правка | К родителю #195 | Наверх | Cообщить модератору

	63. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от nuclight (??), 23-Июн-09, 09:22
	>Шейпер можно ставить только на исходящий трафик. Любые вещи мы повесили фильтр >на входящий трафик эмулируются через добавление фильтра на тот интерфейс который >является исходящим. >Учите теорию. Да-дад, идите учите :) Ситуация наоборот верна, любой исходящий можно заменить входящим трафиком, а описаннное выше нет - ибо между входящим и исходящим интерфейсами есть вычет трафика, предназначенного самому роутящему хосту. См. https://www.opennet.ru/openforum/vsluhforumID3/56111.html#61
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	67. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от KO (?), 23-Июн-09, 09:30
	>[оверквотинг удален] >не коректное сравние. >tc хоть и умеет разные дисциплины обслуживания у шейпера - но работает >только для исходящего трафика (не надо мне рассказывать о ingress фильтрах >- которые делаются через задний проход). >В этом ключе iptables+tc - правильнее сравнивать с ipfw + altq (да >да, dummynet это не единственный шейпер с которым в связке может >использоваться ipfw). >Но судя по всему вы не разбираетесь в вопросе - поэтому приводить >вам аргументы не стоит. >Разбиритесь сначала что вы хотите сравнить - а потом поговорим. На самом деле Вы сами предложили написать "тоже самое, но на связке ipt+tc"(c) Вам написали. А теперь вы что-то вопите про то что "как можно сравнивать". Это выглядит, как минимум, смешно. Потому как складывается впечатление очередного религиозного бзди-фанатика. Или очень толстого тролля. Или связки бзди-фан+ толстый толль.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	50. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от nuclight (??), 23-Июн-09, 08:46
	Например, tablearg, несколько разных тегов на пакете одновременно, OR-блоки внутри одного правила. Да, чего нет в ipfw, что есть в ipt, можете мне не рассказывать, я с обоими знаком.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	116. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от Осторожный (ok), 23-Июн-09, 14:49
	>Например, tablearg, несколько разных тегов на пакете одновременно, OR-блоки внутри одного правила. > > >Да, чего нет в ipfw, что есть в ipt, можете мне не >рассказывать, я с обоими знаком. А что есть IPT ? http://en.wikipedia.org/wiki/IPT
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от Spase (?), 23-Июн-09, 09:09
	>И вообще, может быть кто-нибудь назовёт те преимущества ipfw, которые не умеет >iptables+iproute2+tc? Навскидку (только ipfw, как просили): - Таблицы адресов (а не таблицы правил) с чудным дополнением в виде tablearg; - ruleset-ы (которые включаются/выключаются атомарной операцией); - прямое добавление/удаление правил (попробуйте в iptables вставить/удалить правило в произвольное место цепочки, а не строго в начало/конец, и проделать это несколько раз) - из последнего вытекает skipto; - Логарифмическая зависимость времени добавления правила от числа правил (против экспонециальной у iptables). Хотя было очень давно, и сейчас, возможно, с этим дела обстоят лучше. На 3-м Debian-е при примерно 20000 правил добавление следующего занимало 15 секунд при загрузке машины в ~50 попугаев. Такое количество правил потребовалось сугубо из-за отсутствия таблиц адресов; - Указание вероятности срабатывания правила (хотя, может, уже тоже научились => под вопросом).
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	66. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от nuclight (??), 23-Июн-09, 09:29
	>- прямое добавление/удаление правил (попробуйте в iptables вставить/удалить правило в произвольное место >цепочки, а не строго в начало/конец, и проделать это несколько раз) Ну, вообще-то оно нынче уже умеет указывать номер правила в подцепочке: -I, --insert chain [rulenum] rule-specification >- из последнего вытекает skipto; >- Логарифмическая зависимость времени добавления правила от числа правил (против экспонециальной у >iptables). Хотя было очень давно, и сейчас, возможно, с этим дела >обстоят лучше. На 3-м Debian-е при примерно 20000 правил добавление следующего >занимало 15 секунд при загрузке машины в ~50 попугаев. Такое количество >правил потребовалось сугубо из-за отсутствия таблиц адресов; Ну, вообще-то она линейная, логарифмическая - это для адреса в таблице. А что, в линуксах когда-то оно было именно экспоненциальным, даже не квадратичным? Ужос, это ж как так надо код писать... линейным было бы вполне естественно сразу.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от KO (?), 23-Июн-09, 09:38
	>>И вообще, может быть кто-нибудь назовёт те преимущества ipfw, которые не умеет >>iptables+iproute2+tc? > >Навскидку (только ipfw, как просили): > >- Таблицы адресов (а не таблицы правил) с чудным дополнением в виде >tablearg; Таблицы адресов присутствуют уже с полгода. >- ruleset-ы (которые включаются/выключаются атомарной операцией); Этого не помню, возможно и нет. >- прямое добавление/удаление правил (попробуйте в iptables вставить/удалить правило в произвольное место >цепочки, а не строго в начало/конец, и проделать это несколько раз) Весьма и весьма давно, года эдак 4 назад как минимум умеем: -I, --insert chain [rulenum] rule-specification > >- из последнего вытекает skipto; >- Логарифмическая зависимость времени добавления правила от числа правил (против экспонециальной у iptables). Хотя было очень давно, и сейчас, возможно, с этим дела >обстоят лучше. На 3-м Debian-е при примерно 20000 правил добавление следующего >занимало 15 секунд при загрузке машины в ~50 попугаев. Такое количество >правил потребовалось сугубо из-за отсутствия таблиц адресов; >- Указание вероятности срабатывания правила (хотя, может, уже тоже научились => под вопросом). Давным-давно есть. Из всего этого напрашивается вывод что Вы не очень хорошо знаете ipt, хотя и не страдаете болезнью господ Умки с иЗеном.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	80. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от piavlo (?), 23-Июн-09, 10:20
	>>- Таблицы адресов (а не таблицы правил) с чудным дополнением в виде >>tablearg; > >Таблицы адресов присутствуют уже с полгода. А чем таблицы адресов отличаются от ipset?
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от Spase (?), 23-Июн-09, 11:08
	>>>- Таблицы адресов (а не таблицы правил) с чудным дополнением в виде >>>tablearg; >> >>Таблицы адресов присутствуют уже с полгода. > > А чем таблицы адресов отличаются от ipset? Отсутствием tablearg. Опять же, не исключаю, что уже сделали. Правда, с трудом представляю себе, как аналог tablearg уживется с синтаксисом iptables.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Выполнено портирование ipfw и dummynet для Linux"	–1 +/–
	Сообщение от Spase (?), 23-Июн-09, 11:12
	>Таблицы адресов присутствуют уже с полгода. ...skip >Из всего этого напрашивается вывод что Вы не очень хорошо знаете ipt, >хотя и не страдаете болезнью господ Умки с иЗеном. Да, видимо, отстал от жизни.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	92. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от Spase (?), 23-Июн-09, 11:28
	>>- прямое добавление/удаление правил (попробуйте в iptables вставить/удалить правило в произвольное место >>цепочки, а не строго в начало/конец, и проделать это несколько раз) > >Весьма и весьма давно, года эдак 4 назад как минимум умеем: >-I, --insert chain [rulenum] rule-specification Это не то. Во-первых, не может быть нескольких правил под одним и тем же номером (хотя, в теории, при такой необходимости их можно вынести в отдельную цепочку). Во-вторых, добавление правила сдвигает всю нумерацию. >> >>- из последнего вытекает skipto; ...аналогов которого я так же не наблюдаю.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	94. "Выполнено портирование ipfw и dummynet для Linux"	+1 +/–
	Сообщение от Ыку (?), 23-Июн-09, 11:43
	>И вообще, может быть кто-нибудь назовёт те преимущества ipfw, которые не умеет >iptables+iproute2+tc? Вы сам его привели "iptables+iproute2+tc" вместо 1го файла с приятным и понятным синтаксисом
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	105. "Выполнено портирование ipfw и dummynet для Linux"	+/–
	Сообщение от www2 (??), 23-Июн-09, 12:40
	>Вы сам его привели "iptables+iproute2+tc" вместо 1го файла с приятным и понятным >синтаксисом Ясно, преимуществ нет.
	Ответить | Правка | Наверх | Cообщить модератору

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

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