|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Master Yoda 2:5020/400 26 Oct 2002 05:47:27
To : Andy Gorev
Subject : Re: shaper for incoming traffic
--------------------------------------------------------------------------------
Andy Gorev <gorev@avilink.net> пишет в
сообщении:apc9e6$v43$1737@www.fido-online.com...
> IT> iptables -t mangle -N cutter
> IT> iptables -t manlge -A cutter -m width -p TCP -j TCPWIN --set-win 100
> IT> iptables -t manlge -A cutter -j RETURN
>
> IT> iptables -t mangle -A INPUT -j cutter
> IT> iptables -t mangle -A OUTPUT -j cutter
> А что мешает делать например так?
> iptables -t mangle -A FORWARD -m width --bytes 33600 -p TCP -i eth0 -j
TCPWIN
> --set-win 100
> iptables -t mangle -A FORWARD -m width --bytes 19200 -p TCP -o eth1 -j
TCPWIN
> --set-win 50
> Или то-же самое в PREROUTING/POSTROUTING
> И разве нужно создавать целую таблицу для таргета TCPWIN с RETURN из нее
после
> обработки?
>
> Rgrds, Gorev
Мешает то, что нужно считывать траффик, идущий в одну сторону, а изменять
совсем другие пакеты. Лично я не вижу способа сделать это, не передав
параметр из одного правила в другое.
Давайте рассмотрим ваши правила на простом примере - кто-то из локальной
сетки скачивает БОЛЬШОЙ файл:
Допустим, певроначальная скорость = 51000 байт/с. Пройдя через первое
правило - пакеты будут иметь окно 100; пройдя через второе правило - эти же
пакеты будут иметь окно 50 (интересно, зачем дважы изменять один пакет,
когда можно изменить один раз?).
Компьютер из локальной сети получает пакеты с окном 50. Этого значения
вполне достаточно, чтобы послать подтверждение на получение данных. Причем в
этих же пакетах подтверждения он может указать окно хоть 15000 - твой
файерволл это никак не обрабатывает.
А вот правила, предложенные Ilya Teterin будут работать, хотя и ограничат
траффик в обе стороны, что может потребоваться, например, для ограничения
нагрузки на общий канал из локальной сетки.
З.Ы. пока писал все это - возник вопрос к проффам:
"А не приведет ли такое искусственное уменьшение TCPWIN к более
интенсивному обмену пакетами меньшего размера? И не составит ли такой <более
интенсивный обмен пакетами> в некоторых случаях тот же траффик, который был
бы составлен без воздействия на TCPWIN ?" ???
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
