|
|
|
|
|
6.27, parad (??), 09:41, 27/06/2008 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
>А что именно нужно сделать-то ? Какая стоит конкретная задача ?
>В pf есть анхоры
>1) модифицируем anchor.conf
>2) pfctl -a myanchor -f anchor.conf
>
>Или же вообще можно ограничится модификацией таблиц
>pfctl -t mytable -T add 1.2.3.4
Я и говорю - pf лучше подойдет для простых правил. )))
В том, что вы написали сразу виден недостаток:
1) Для того, чтобы добавлять правила в якорь - необходимо этот якорь создать, а это править файл руками. Если подцеплять все правила от разных пользователей на один (ранее созданный) якорь - со временем невозможно будет разгребсти этот мусор.
2) Ок, а с шейпером как поступить, для него якорей не насоздаешь?
| |
|
7.33, Осторожный (?), 23:50, 27/06/2008 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
Ну почему для простых-то ?
Хоть в pf, хоть в ipfw написать можно ЛЮБЫЕ правила !
Вопрос в том, где проще будет скрипт для управления.
Но пока неизвестно какую задачу решает скрипт спорить можно бесконечно.
Вот если будет конкретная задача - там можно предметно говорить.
Я не вижу проблем - скрипт можно сделать для ipfw и для pf.
1)
Якорь создается один раз в файле pf.conf
Потом все нужные правила добавляются в этот один якорь.
Правила записанные в якорь храним в файле myrule.conf
Правим скриптом файл, потом перегружаем якорь.
Можно без якоря - править файл pf.conf
Но скорее все этого не нужно.
Я понимаю, что в ipfw подкупает наличие номеров.
Можно вставлять куда угодно что угодно.
Насчет мусора - а что если в ipfw добавлять правила, то со временем мусор там не образуется ? Следить надо в любом случаа за тем что добавляется и для чего,
а также процедуру удаления предусмотреть.
Какая конкретная задача решается ?
Или это большой секрет ?
2)
С шейпером не знаю как, ибо в pf с ним не работал :)
| |
|
|
|
|
|
|
|
2.38, nuclight (ok), 22:08, 03/07/2008 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
>в статье анахронизмы вперемешку с откровенными ошибками.
>
>>Некоторые могут возразить что мол мы не можем контролировать входящий поток.
>>Я отвечу что можем! Наверное Вы просто ребята не читали работу протокола TCP/IP.
>
>это вообще шедевр.
Криво выражено, но по сути верно. Вешать шейпинг на вход - полностью логически эквивалентно поставить перед входом еще один роутер, на исходе которого к нам шейпить. Да, это никак не повлияет на забитость канала теми пакетами, которые уже пришли (особенно если флуд какой). Но в случае конкнетно tcp, составляющего обычно бОльшую часть трафика - скорость выровняется спустя некоторое время, по подстройке отправителя к скорости возвращаемых ACK'ов.
>>То что можно сделать, так это перенаправлять входящий трафик клиентам по очереди, таким образом разделив канал поровну между ними. Также можно ограничить потребление некоторым клиентом не более K% трафика.
>
>браво. а повесить шейпер исходящего трафика на интерсфейс, смотрящий в сторону клиента
>никак?
Это чисто на того клиента. Пример же приводился и для случая, если софтины-клиенты есть и на самом роутере (а почему бы им не взяться, скажем, на домашнем сервере, выполняющем заодно и роль софт-роутера?), для которых исходящего трафика никакого вовсе не будет.
| |
|
|
2.11, Andrew Kolchoogin (?), 20:21, 26/06/2008 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
> Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических
> целях.
_Шейпить_ входящий трафик _нельзя_. Его можно только _резать_.
Это "альфа" и "омега" всего управления трафиком в TCP/IP-сетях. Распоряжаться можно только _своей_ жо... ой, то есть, управлять можно только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_. Да хоть весь вход пакетным фильтром в /dev/null сливайте -- да пожалуйста, хоть сто раз. Канал у вас по входу как на полке был, так на полке и останется (это я в вашу сторону "ping -f" пустил :).
Да, можно влиять на вход, шейпя исход: TCP -- протокол с подтверждением приема, PUSH'и не будут идти со скоростью, превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить.
И до тех пор, пока такие вот безграмотные статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали по объявлениям".
:-\
| |
|
3.14, Осторожный (?), 21:57, 26/06/2008 [^] [^^] [^^^] [ответить] [↓] [↑] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
>> Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических
>> целях.
>
> _Шейпить_ входящий трафик _нельзя_. Его можно только _резать_.
входящий траффик можно шейпить, если он уже пришел, он еще не отдан далее на обработку
- например в локальную сеть
>
>
> Это "альфа" и "омега" всего управления трафиком в
>TCP/IP-сетях. Распоряжаться можно только _своей_ жо... ой, то есть, управлять можно
>только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_.
>Да хоть весь вход пакетным фильтром в /dev/null сливайте -- да
>пожалуйста, хоть сто раз. Канал у вас по входу как на
>полке был, так на полке и останется (это я в
>вашу сторону "ping -f" пустил :).
тем не менее твои входящие ping можно ограничить по скорости
- с какой скоростью они будут попадать на мой интерфейс
>[оверквотинг удален]
> Да, можно влиять на вход, шейпя исход: TCP
>-- протокол с подтверждением приема, PUSH'и не будут идти со скоростью,
>превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить.
>
>
> И до тех пор, пока такие вот безграмотные
>статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали
>по объявлениям".
>
> :-\
ха-ха
| |
|
|
5.23, Осторожный (?), 00:43, 27/06/2008 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
>> тем не менее твои входящие ping можно ограничить по скорости
>> - с какой скоростью они будут попадать на мой интерфейс
>
> Нет. (C) Фарид Вагапов, если тут еще хоть
>кто-то помнит, кто это такой.
>
> Я зуб даю с пломбой, что мои пинги
>будут попадать на твой интерфейс ровно с той скоростью, с которой
>я их посылаю. Не быстрее, и не медленнее.
Вот зуб не надо.
По дороге между источником ping-ом и firewall многое может случиться
- например их может drop-нуть или задержать проходящий роутер.
>
> Это они в твой TCP/IP-стек могут не попадать.
>Но _каналу_ от этого легче не станет. Dixi.
Каналу легче не станет, но про канал речи и не было вовсе.
| |
|
|
|
4.30, Sem (??), 11:54, 27/06/2008 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
>[оверквотинг удален]
>>превышающей скорость 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."
| |
|
3.41, Eugen Konkov (?), 01:46, 09/05/2009 [^] [^^] [^^^] [ответить] [↑] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
> управлять можно
>только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_.
>Под входящим тут имеется в виду не тот трафик, который идет в интерфейс, а тот, который >пришел, но еще не передан на обработку. Почему его "_нельзя_" зашейпить? Можно. Только >криво это и с трудом можно придумать этому оправдание. О чем и речь.
Речь идёт о проходящем трафике, который пришел на интерфейс, и в скором времени уйдет через какой-то другой интерфейс.
В 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
| |
|
|
|