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

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

"OpenNews: Улучшенное конфигурирование ipfw"		+/–
Сообщение от opennews (??) on 26-Июн-08, 17:08
В статье (http://kes.net.ua/softdev/advanced_firewall.html) рассказано как упростить настройку межсетевого экрана на базе ipfw. Затронуты темы настройки пайпов и очередей. URL: http://kes.net.ua/softdev/advanced_firewall.html Новость: http://www.opennet.me/opennews/art.shtml?num=16676
Высказать мнение | Ответить | Правка | Cообщить модератору

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

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

1. "Улучшенное конфигурирование ipfw"		+/–
Сообщение от Аноним (??) on 26-Июн-08, 17:08
Упростить настройку ipfw очень просто... достаточно всего лишь заменить его pf %)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от parad (??) on 26-Июн-08, 17:28
	>Упростить настройку ipfw очень просто... достаточно всего лишь заменить его pf %) сам больше 2х лет использовал pf, пока не столкнулся с проблемой динамического создания и удаления очередей, фильтрации по маске пакета, удобного интерфейса для редактирования правил из скриптов и тд, чего нет в pf. pf больше подходит для простых правил, поэтому и кажется что он проще...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Осторожный on 26-Июн-08, 21:51
	>>Упростить настройку ipfw очень просто... достаточно всего лишь заменить его pf %) > >сам больше 2х лет использовал pf, пока не столкнулся с проблемой динамического >создания и удаления очередей, фильтрации по маске пакета, удобного интерфейса для >редактирования правил из скриптов и тд, чего нет в pf. >pf больше подходит для простых правил, поэтому и кажется что он проще... Фильтрация по маске пакета - это что ? Удобный интерфейс для редактирования правил из скриптов - что именно не так в pf ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от parad (??) on 26-Июн-08, 22:23
	> Фильтрация по маске пакета - это что ? Это я сканкретизировал часть задачи, которую недавно приходилось решать, - а именно перенаправление пакетов в диверт сокет, с последующим анализм в своей софтине. В общем диверта в pf нет. > Удобный интерфейс для редактирования правил из скриптов - что именно не так в pf ? Сможете проще для pf придумать?: #!/usr/bin/perl system ("ipfw add ..."); или #!/bin/sh ipfw add ...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Осторожный on 27-Июн-08, 00:27
	>> Фильтрация по маске пакета - это что ? > >Это я сканкретизировал часть задачи, которую недавно приходилось решать, - а именно >перенаправление пакетов в диверт сокет, с последующим анализм в своей софтине. >В общем диверта в pf нет. нет >[оверквотинг удален] > >Сможете проще для pf придумать?: > >#!/usr/bin/perl >system ("ipfw add ..."); > >или > >#!/bin/sh >ipfw add ... Ха! А что именно нужно сделать-то ? Какая стоит конкретная задача ? В pf есть анхоры 1) модифицируем anchor.conf 2) pfctl -a myanchor -f anchor.conf Или же вообще можно ограничится модификацией таблиц pfctl -t mytable -T add 1.2.3.4
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от parad (??) on 27-Июн-08, 09:41
	>А что именно нужно сделать-то ? Какая стоит конкретная задача ? >В pf есть анхоры >1) модифицируем anchor.conf >2) pfctl -a myanchor -f anchor.conf > >Или же вообще можно ограничится модификацией таблиц >pfctl -t mytable -T add 1.2.3.4 Я и говорю - pf лучше подойдет для простых правил. ))) В том, что вы написали сразу виден недостаток: 1) Для того, чтобы добавлять правила в якорь - необходимо этот якорь создать, а это править файл руками. Если подцеплять все правила от разных пользователей на один (ранее созданный) якорь - со временем невозможно будет разгребсти этот мусор. 2) Ок, а с шейпером как поступить, для него якорей не насоздаешь?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	33. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Осторожный on 27-Июн-08, 23:50
	Ну почему для простых-то ? Хоть в pf, хоть в ipfw написать можно ЛЮБЫЕ правила ! Вопрос в том, где проще будет скрипт для управления. Но пока неизвестно какую задачу решает скрипт спорить можно бесконечно. Вот если будет конкретная задача - там можно предметно говорить. Я не вижу проблем - скрипт можно сделать для ipfw и для pf. 1) Якорь создается один раз в файле pf.conf Потом все нужные правила добавляются в этот один якорь. Правила записанные в якорь храним в файле myrule.conf Правим скриптом файл, потом перегружаем якорь. Можно без якоря - править файл pf.conf Но скорее все этого не нужно. Я понимаю, что в ipfw подкупает наличие номеров. Можно вставлять куда угодно что угодно. Насчет мусора - а что если в ipfw добавлять правила, то со временем мусор там не образуется ? Следить надо в любом случаа за тем что добавляется и для чего, а также процедуру удаления предусмотреть. Какая конкретная задача решается ? Или это большой секрет ? 2) С шейпером не знаю как, ибо в pf с ним не работал :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Осторожный on 27-Июн-08, 00:34
	> Это я сканкретизировал часть задачи, которую недавно приходилось решать, - а именно перенаправление пакетов в диверт сокет, с последующим анализм в своей софтине. В общем диверта в pf нет. Вообще divert был придуман в FreeBSD чтобы как-то сделать natd И является скорее затычкой, чем полезной вещью: например в частности из-за того что пакеты из kernel-space передаются в user-level-space и обратно. Какой именно анализ выполняется в свой софтине ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от parad (??) on 27-Июн-08, 09:22
	> Какой именно анализ выполняется в свой софтине ? Защита от рассылки спама из клиентских сетей - проверяет, чтобы все smtp подключения были с авторизацией, иначе - дропает.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от lithium (ok) on 27-Июн-08, 10:29
	если не секрет, можно узнать как Вы это делаете?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от parad (??) on 27-Июн-08, 15:08
	>если не секрет, можно узнать как Вы это делаете? не секрет: при подключении на 25 порт подключения заварачиваются на divert сокет демона, который в свою очередь сам конектится к данному серваку (информаци об ip извлекается из заголовка пакета), выполняя роль прозрачной прокси. дальше тупо парсится smtp протокол и если до отправки пользователем команды data не была пройдена аутентификация - связь с сервером рвется, а клиенту иметируется сообщение об ошибке.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	32. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Осторожный on 27-Июн-08, 23:39
	Я делаю проще и тупее 1) 25 порт наружу запрещен (только mailserver может слать почту на 25-ый порт) 2) А клиенты шлют на smtps или submission    Или еще лучше - через mailserver, который еще и проверит почту 3) В вашем случае клиент не сможет сделать START TLS на 25 порту Это как-то обрабатывается ? 4) Если уже клиент может слать почту с помощью SMTP AUTH на удаленный сервер то кто ему мешает сделать это через SSL ? 5) И потом давать клиенту слать ключ открытым текстом - явно ведет к нарушению security. У меня postfix настроен так, что фича SMTP AUTH работает ТОЛЬКО если соединение ведется через SSL ! Обычный SMTP не сможет сделать SMTP AUTH.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	34. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от parad (??) on 28-Июн-08, 13:38
	так сделано у 90% провайдеров. START TLS приравнивается к прохождению аутентификации, а другие порты никак не обрабатываются, метод аутентификации выбирает сам клиент - клиенту, в случае, если у него ноутбук нет необходимости постоянно перепрописывать сервера. за год работы ниодной жалобы от клиентов и на abuse@, - а все потому-что нет спамботов поддерживающих ssl. >5) И потом давать клиенту слать ключ открытым текстом - явно ведет к нарушению security. >У меня postfix настроен так, что фича SMTP AUTH работает ТОЛЬКО если соединение ведется >через SSL ! >Обычный SMTP не сможет сделать SMTP AUTH. Тут вы, скорее всего, недоконца сами понимаете о чем говорите.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Осторожный on 28-Июн-08, 17:29
	>[оверквотинг удален] >другие порты никак не обрабатываются, метод аутентификации выбирает сам клиент - >клиенту, в случае, если у него ноутбук нет необходимости постоянно перепрописывать >сервера. за год работы ниодной жалобы от клиентов и на abuse@, >- а все потому-что нет спамботов поддерживающих ssl. > >>5) И потом давать клиенту слать ключ открытым текстом - явно ведет к нарушению security. >>У меня postfix настроен так, что фича SMTP AUTH работает ТОЛЬКО если соединение ведется >через SSL ! >>Обычный SMTP не сможет сделать SMTP AUTH. > >Тут вы, скорее всего, недоконца сами понимаете о чем говорите.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	36. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Осторожный on 28-Июн-08, 17:33
	>>5) И потом давать клиенту слать ключ открытым текстом - явно ведет к нарушению security. >>У меня postfix настроен так, что фича SMTP AUTH работает ТОЛЬКО если соединение ведется >через SSL ! >>Обычный SMTP не сможет сделать SMTP AUTH. > >Тут вы, скорее всего, недоконца сами понимаете о чем говорите. 1) SMTP AUTH шлет пароль открытым текстом. Это опасно. Насчет этого надеюсь вопросов нет ? :) 2) man posfix # When TLS encryption is optional in the Postfix SMTP server, # do not announce or accept SASL authentication over unencrypted connections. # smtpd_tls_auth_only = yes Клиент подключается к серверу и делает EHLO/HELO. В ответ получает список фич сервера. Если соединение ведется без SSL, то сервер не сообщает что есть SMTP AUTH. Если соединение ведется через SSL, то сервер сообщает что есть SMTP AUTH. И чего я тут не понимаю ? ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Улучшенное конфигурирование ipfw"		+/–
Сообщение от Dima (??) on 26-Июн-08, 17:27
А что то поумнее сказать? :-)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от trey on 26-Июн-08, 17:33
	>А что то поумнее сказать? :-) к вам это тоже относится... и ко мне относится... в общем стена там <---- пошли...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Улучшенное конфигурирование ipfw"		+/–
Сообщение от rage (??) on 26-Июн-08, 17:56
в статье анахронизмы вперемешку с откровенными ошибками. >Некоторые могут возразить что мол мы не можем контролировать входящий поток. >Я отвечу что можем! Наверное Вы просто ребята не читали работу протокола TCP/IP. это вообще шедевр. >То что можно сделать, так это перенаправлять входящий трафик клиентам по очереди, таким образом разделив канал поровну между ними. Также можно ограничить потребление некоторым клиентом не более K% трафика. браво. а повесить шейпер исходящего трафика на интерсфейс, смотрящий в сторону клиента никак? Да и использовать natd - бред.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от nuclight (ok) on 03-Июл-08, 22:08
	>в статье анахронизмы вперемешку с откровенными ошибками. > >>Некоторые могут возразить что мол мы не можем контролировать входящий поток. >>Я отвечу что можем! Наверное Вы просто ребята не читали работу протокола TCP/IP. > >это вообще шедевр. Криво выражено, но по сути верно. Вешать шейпинг на вход - полностью логически эквивалентно поставить перед входом еще один роутер, на исходе которого к нам шейпить. Да, это никак не повлияет на забитость канала теми пакетами, которые уже пришли (особенно если флуд какой). Но в случае конкнетно tcp, составляющего обычно бОльшую часть трафика - скорость выровняется спустя некоторое время, по подстройке отправителя к скорости возвращаемых ACK'ов. >>То что можно сделать, так это перенаправлять входящий трафик клиентам по очереди, таким образом разделив канал поровну между ними. Также можно ограничить потребление некоторым клиентом не более K% трафика. > >браво. а повесить шейпер исходящего трафика на интерсфейс, смотрящий в сторону клиента >никак? Это чисто на того клиента. Пример же приводился и для случая, если софтины-клиенты есть и на самом роутере (а почему бы им не взяться, скажем, на домашнем сервере, выполняющем заодно и роль софт-роутера?), для которых исходящего трафика никакого вовсе не будет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Улучшенное конфигурирование ipfw"		+/–
Сообщение от drTr0jan on 26-Июн-08, 18:04
Единственное, что не смог сделать с natd - keep-state правило.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от nuclight (ok) on 03-Июл-08, 22:01
	>Единственное, что не смог сделать с natd - keep-state правило. http://nuclight.livejournal.com/124348.html (http://www.opennet.me/opennews/art.shtml?num=16080)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Улучшенное конфигурирование ipfw"		+/–
Сообщение от Аноним (??) on 26-Июн-08, 18:57
до кучи http://michurin.com.ru/bsd-ipfw.shtml рассказ для тех, кто не знает, что такое ipfw, но хочет начать его использовать сразу после прочтения статьи
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Улучшенное конфигурирование ipfw"		+/–
Сообщение от Sem (ok) on 26-Июн-08, 18:57
Блин, режет глаз слово "ложить". И опечатки. И вообще... Вся тема про недостаток ALTQ мягко говоря спорная. Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических целях. И фраза про разделение входящего канала поровну - технически не грамотная. Можно создать иллюзию придерживая часть трафика, но к каналу это не имеет отношения.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Andrew Kolchoogin on 26-Июн-08, 20:21
	> Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических > целях.     _Шейпить_ входящий трафик _нельзя_. Его можно только _резать_.     Это "альфа" и "омега" всего управления трафиком в TCP/IP-сетях. Распоряжаться можно только _своей_ жо... ой, то есть, управлять можно только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_. Да хоть весь вход пакетным фильтром в /dev/null сливайте -- да пожалуйста, хоть сто раз. Канал у вас по входу как на полке был, так на полке и останется  (это я в вашу сторону "ping -f" пустил :).     Да, можно влиять на вход, шейпя исход: TCP -- протокол с подтверждением приема, PUSH'и не будут идти со скоростью, превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить.     И до тех пор, пока такие вот безграмотные статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали по объявлениям".     :-\
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Sem (ok) on 26-Июн-08, 20:42
	>> Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических >> целях. > >    _Шейпить_ входящий трафик _нельзя_. Его можно только _резать_. Под входящим тут имеется в виду не тот трафик, который идет в интерфейс, а тот, который пришел, но еще не передан на обработку. Почему его "_нельзя_" зашейпить? Можно. Только криво это и с трудом можно придумать этому оправдание. О чем и речь.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Andrew Kolchoogin on 26-Июн-08, 22:31
	> Под входящим тут имеется в виду не тот трафик, который идет в > интерфейс, а тот, который пришел, но еще не передан на обработку. > Почему его "_нельзя_" зашейпить?     Потому что. Его можно только заполисить. Не передать на дальнейшую обработку, если он транзитный. Но _каналам_ твоим от этого ни горячо, ни холодно. > Можно.     Нельзя. > Только криво это и с трудом можно придумать этому оправдание. О чем и речь.     Речь о безграмотности автора статьи. :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Осторожный on 26-Июн-08, 21:57
	>> Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических >> целях. > >    _Шейпить_ входящий трафик _нельзя_. Его можно только _резать_. входящий траффик можно шейпить, если он уже пришел, он еще не отдан далее на обработку - например в локальную сеть > > >    Это "альфа" и "омега" всего управления трафиком в >TCP/IP-сетях. Распоряжаться можно только _своей_ жо... ой, то есть, управлять можно >только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_. >Да хоть весь вход пакетным фильтром в /dev/null сливайте -- да >пожалуйста, хоть сто раз. Канал у вас по входу как на >полке был, так на полке и останется  (это я в >вашу сторону "ping -f" пустил :). тем не менее твои входящие ping можно ограничить по скорости - с какой скоростью они будут попадать на мой интерфейс >[оверквотинг удален] >    Да, можно влиять на вход, шейпя исход: TCP >-- протокол с подтверждением приема, PUSH'и не будут идти со скоростью, >превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить. > > >    И до тех пор, пока такие вот безграмотные >статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали >по объявлениям". > >    :-\ ха-ха
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Andrew Kolchoogin on 26-Июн-08, 22:29
	> тем не менее твои входящие ping можно ограничить по скорости > - с какой скоростью они будут попадать на мой интерфейс     Нет. (C) Фарид Вагапов, если тут еще хоть кто-то помнит, кто это такой.     Я зуб даю с пломбой, что мои пинги будут попадать на твой интерфейс ровно с той скоростью, с которой я их посылаю. Не быстрее, и не медленнее.     Это они в твой TCP/IP-стек могут не попадать. Но _каналу_ от этого легче не станет. Dixi.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Осторожный on 27-Июн-08, 00:43
	>> тем не менее твои входящие ping можно ограничить по скорости >> - с какой скоростью они будут попадать на мой интерфейс > >    Нет. (C) Фарид Вагапов, если тут еще хоть >кто-то помнит, кто это такой. > >    Я зуб даю с пломбой, что мои пинги >будут попадать на твой интерфейс ровно с той скоростью, с которой >я их посылаю. Не быстрее, и не медленнее. Вот зуб не надо. По дороге между источником ping-ом и firewall многое может случиться - например их может drop-нуть или задержать проходящий роутер. > >    Это они в твой TCP/IP-стек могут не попадать. >Но _каналу_ от этого легче не станет. Dixi. Каналу легче не станет, но про канал речи и не было вовсе.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Andrew Kolchoogin on 27-Июн-08, 10:17
	>> Я зуб даю с пломбой, что мои пинги >> будут попадать на твой интерфейс ровно с той скоростью, с которой >> я их посылаю. Не быстрее, и не медленнее. > Вот зуб не надо. > По дороге между источником ping-ом и firewall многое может случиться > - например их может drop-нуть или задержать проходящий роутер. Угу, или не справиться мой TCP/IP-стек посылать пакеты с такой скоростью, чтобы выложить _мой_ канал на полку. :) Разумеется, имелся в виду ping flood с directly-connected router'а.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	39. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от mFF on 04-Июл-08, 11:49
	>тем не менее твои входящие ping можно ограничить по скорости >- с какой скоростью они будут попадать на мой интерфейс > Бгы гы Ограничивать можно только то что УЖЕ пришло. Ограничивать "скорость попадания на твой интерфейс" можно только на вышестоящем роутере. Почитал бы ты что-нибудь о защите от DDOS-атак что ли.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от migosm on 26-Июн-08, 22:20
	>[оверквотинг удален] >    Да, можно влиять на вход, шейпя исход: TCP >-- протокол с подтверждением приема, PUSH'и не будут идти со скоростью, >превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить. > > >    И до тех пор, пока такие вот безграмотные >статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали >по объявлениям". > >    :-\ Андрей прав. Все нижепишущие прочтите разницу между Policing и Shaping.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Sem (??) on 27-Июн-08, 11:54
	>[оверквотинг удален] >>превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить. >> >> >>    И до тех пор, пока такие вот безграмотные >>статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали >>по объявлениям". >> >>    :-\ > >Андрей прав. Все нижепишущие прочтите разницу между Policing и Shaping. Ну послал, так послал! :) Но раз не указал, куда идти, то иду куда могу и читаю: "More specifically, traffic shaping is any action on a set of packets (often called a stream or a flow) which imposes additional delay on those packets such that they conform to some predetermined constraint (a contract or traffic profile)." "Traffic policing is the distinct but related practice of packet dropping and packet marking."
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	41. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Eugen Konkov on 09-Май-09, 01:46
	> управлять можно >только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_. >Под входящим тут имеется в виду не тот трафик, который идет в интерфейс, а тот, который >пришел, но еще не передан на обработку. Почему его "_нельзя_" зашейпить? Можно. Только >криво это и с трудом можно придумать этому оправдание. О чем и речь. Речь идёт о проходящем трафике, который пришел на интерфейс, и в скором времени уйдет через какой-то другой интерфейс. В 99% случаев говоря "хочу зашейпить вход" кому-то, имеют ввиду "проходящий трафик" мимо роутера. т.е. зашейпить вход клиенту - это означает зашейпить на выходе из роутера или на входе в роутер. ipfw может шейпить этот трафик без проблем, а ALTQ только на выходе. ситуация есть LAN 192.168.1.0/24, 192.168.2.0/24 которые доступны через rl1 и rl2 роутера. На роутере запущен OSPF и трафик к этим сетям динамически уходит через rl1 или через rl2 в зависимости он загрузки каналов или друхих прочих факторов, которые нам не известны. ipfw легко можно зашейпить трафик к этим сетям собирая пакеты на входе в роутер (rl0): ipfw pipe 1 config bw 512Kbit/s mask dst-ip 0xffffff00 ipfw add 1 pipe 1 all from any to 192.168.1.0/24 in recv rl0 ipfw add 1 pipe 1 all from any to 192.168.2.0/24 in recv rl0 И нас не заботит через какой интерфейс/интерфейсы пойдет пакет дальше. Реализовать в ALTQ такое невозможно, т.к. на rl2 и rl1 это две разные очереди. И они никак!!! с друг другом "общаться" не смогут. Поэтому если трафик к LAN's будет уходить через rl1 со скорость 128Кбит, то мы не как не сможем зашейпить его на rl2 на скорость 384Кбит/с. А так как трафик будет распределятся между двумя каналами каким-то случайным образом, то я вообще не представляю как можно сделать такое с помощью ALTQ. В догонку: http://www.nabble.com/altq-td18171872.html#a23453905
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Улучшенное конфигурирование ipfw"		+/–
Сообщение от z1nkum (ok) on 26-Июн-08, 19:06
тяжко-то как живётся юзверям: bw 8Kbytes
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Улучшенное конфигурирование ipfw"		+/–
Сообщение от grayich (??) on 26-Июн-08, 19:34
все это хорошо, только нарезать четко(плавно) каналы не говоря уже о распределении не получается. Если у когото получилось, то скорее всего человек проверял на искуственном тесте и все, а реально не использовал.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "Улучшенное конфигурирование ipfw"		+/–
Сообщение от Myc (??) on 26-Июн-08, 22:32
>Например если на интерфейсе висит сеть 192.168.0.0/24, то дропаем всё, что не с этой сети: >ipfw add 11101 deny all from not 192.168.0.0/24 to any in recv rl0 Мдя, бывает. У ipfw уже кучу лет есть ряд полезных фич типа verrevpath, versrcreach, antispoof.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	22. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Andrew Kolchoogin on 27-Июн-08, 00:35
	> У ipfw уже кучу лет есть ряд полезных фич типа verrevpath, versrcreach, antispoof. Лучший способ убить border router: router>en Password: router#conf t router(config)#int <имя внешнего интерфейса> router(config-if)#ip verify unicast reverse-path :))) verrevpath -- зло. :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	25. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Аноним (??) on 27-Июн-08, 09:16
	Аргументы и факты? Cisco давно рекомендует использовать эту фичу и выполняется она в CEF.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Улучшенное конфигурирование ipfw"		+/–
	Сообщение от Осторожный on 27-Июн-08, 00:49
	В результате дропаются DHCP-запросы которые идут с адреса 0.0.0.0 to 255.255.255.255 Еще можно следить за адресами, куда идут пакеты Скажем пакеты из локальной сети 192.168.0.0/24 на адреса 10.0.0.0/8 тоже можно drop-ать ( если у вас нет локальной сети 10.0.0.0/8 )
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Индекс форумов | Темы | Пред. тема | След. тема