LinuxForum.Fans
Тема

вопрос по HTB (tc)

Автор: Merzley 16 сообщений 2992 просмотров
#304449

Доброго времени суток. Не знаю, как кратко задать вопрос, поэтому сначала обрисую ситуацию.
Есть компьютер, подключенный к интернету через интерфейс ppp0(4Mbit). Интерфейс eth0(100MBit) смотрит в локальную сеть. С NAT проблем не было, все работает. Но один из пользователей в локалке сидит в онлайн игрушке, и если кто-то забивает канал, то он жалуется, что играть невозможно. Нашел выход в управлении трафиком через HTB, который настраивал через htb.init. Конфиги htb.init:

"/etc/htb/eth0"
DEFAULT=0
R2Q=10

"/etc/htb/eth0-2.root"
RATE=128Kbit
CEIL=4Mbit

"/etc/htb/eth0-2.game"
RATE=64Kbit
CEIL=128Kbit
LEAF=sfq
MARK=101

Для работы HTB промаркировал трафик:
sudo iptables -t mangle -A FORWARD -d 192.168.0.0/24 -p tcp --sport 29000 -j MARK --set-mark 101

При попытке забить канал с компьютера в локалке - все работает, т.е. игрушке отдаются гарантированные 64 Кбит. Но трафик с компьютера, который раздает интернет не учитывается HTB и, соответственно, профита нет. Собственно вопрос: что можно сделать, чтобы HTB учитывал трафик с главного компьютера? Или может есть какое лучшее решение? Заранее спасибо.

P.S. Буду рад также советам по тому, что можно почитать в этой области.

#304454
"Merzley" написал:
P.S. Буду рад также советам по тому, что можно почитать в этой области.

Squid не то?
P.S. А что такое НТВ?

#304458
"stalker_tk" написал:
Squid не то?

Сейчас посмотрю. Раньше с управлением трафиком не работал, поэтому начал копать в сторону того, что первым в поиске попалось.

"stalker_tk" написал:
P.S. А что такое НТВ?

Очередь HTB (Hierarchy Token Bucket - иерархический буфер токенов) реализует мощную иерархию классов с упором на согласование с существующей практикой. HTB обеспечивает гарантированную полосу пропускания для классов, также позволяет устанавливать верхние пределы межклассового разделения очереди. Содержит объекты ограничения, базирующиеся на TBF, и может устанавливать приоритеты для классов. (С)http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=tc

Я так понял, что это шейпер, встроенный в ядро и настраивающийся с помощью стандартной утилиты tс.
htb.init - более высокоуровневая надстройка.

#304461
"stalker_tk" написал:
Squid не то?

Squid (англ. squid — «кальмар») — программный пакет, реализующий функцию кэширующего прокси-сервера для протоколов HTTP, FTP, Gopher и (в случае соответствующих настроек) HTTPS. (C)http://ru.wikipedia.org/wiki/Squid

Выходит, что Squid - прокси сервер, да еще и работающий с прикладными протоколами. Не то. Web трафик мне трогать не надо. Мне нужно регулировать скорость на уровне TCP, чтобы трафику приходящему на TCP порт 29000 выделить гарантированный канал.

Если я не прав, и при помощи Squid можно этого добиться - прошу простить невежду и поправить. А пока пойду поподробнее покурю маны по Squid.

#304463
"Merzley" написал:
Очередь HTB (Hierarchy Token Bucket - иерархический буфер токенов) реализует мощную иерархию классов с упором на согласование с существующей практикой. HTB обеспечивает гарантированную полосу пропускания для классов, также позволяет устанавливать верхние пределы межклассового разделения очереди. Содержит объекты ограничения, базирующиеся на TBF, и может устанавливать приоритеты для классов. (С)http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=tc

Я так понял, что это шейпер, встроенный в ядро и настраивающийся с помощью стандартной утилиты tс.
htb.init - более высокоуровневая надстройка

Спасибо буду знать

#304464

squid минус с работой с https (443).
Ограничение траффика (HTB) поищите на данном форуме, много тем было с примерами.

#304475
"Kettler" написал:
squid минус с работой с https (443).

В смысле... недружит? У меня проблем нет, правда у меня прокси прозрачный.

#304479
"Kettler" написал:
Ограничение траффика (HTB) поищите на данном форуме, много тем было с примерами.

Везде, где искал, пишут, что адекватно шейпить входящий трафик нельзя. Это вполне логично, т.к. трафик уже пришел и замедлить его можно только отбросом уже пришедших пакетов, что выглядит по меньшей мере странно. Но мне как раз это и надо. Может все-таки есть какие-то обходные пути? Или стоит оставить эту затею и поставить на виртуалку еще одну систему и сделать ее маршрутизатором?

#304641

Так. Я что непонял. Вам нужно ограничить трафик который уже идёт от клиента к вашему шлюзу. Верно???

#304725
"Merzley" написал:
При попытке забить канал с компьютера в локалке - все работает, т.е. игрушке отдаются гарантированные 64 Кбит. Но трафик с компьютера, который раздает интернет не учитывается HTB и, соответственно, профита нет. Собственно вопрос: что можно сделать, чтобы HTB учитывал трафик с главного компьютера? Или может есть какое лучшее решение? Заранее спасибо.

Исходя из этого сделаю предположение, это не шлюз в его понимании, а шлюз + на этом компе еще и работают, те надо и ему траффик резать...тогда FORWARD надо на PREROUTING поменять.

#304727
Merzley написал:
[quote="Kettler"]Ограничение траффика (HTB) поищите на данном форуме, много тем было с примерами.

Везде, где искал, пишут, что адекватно шейпить входящий трафик нельзя. Это вполне логично, т.к. трафик уже пришел и замедлить его можно только отбросом уже пришедших пакетов, что выглядит по меньшей мере странно. Но мне как раз это и надо. Может все-таки есть какие-то обходные пути? Или стоит оставить эту затею и поставить на виртуалку еще одну систему и сделать ее маршрутизатором?[/quote]

С идеологической точки зрения нельзя, но технически можно ограничить скорость входящего трафика . Реализуется с помощью псевдо-интерфейса ifb (для tcp).

#304969
"zenon" написал:
Исходя из этого сделаю предположение, это не шлюз в его понимании, а шлюз + на этом компе еще и работают, те надо и ему траффик резать...

Точно так. У меня только мобильный интернет, а роутера с поддержкой USB модемов в наличии нету. Поэтому раздавать интернет своим домашним приходится через свой рабочий компьютер.

"Macumazan" написал:
С идеологической точки зрения нельзя, но технически можно ограничить скорость входящего трафика . Реализуется с помощью псевдо-интерфейса ifb (для tcp).

Спасибо за направление. Сейчас посмотрю, что это такое.

Пока обошелся тем, что на виртуалке запустил систему исключительно в качестве шлюза. Лишние 150Мб памяти не сильно напрягают да и экспериментировать удобнее. Но все-таки хочется понять, можно ли сделать по-человечески. Исключительно спортивный интерес. Буду дальше копать.

#304972

Да, еще:

"zenon" написал:
тогда FORWARD надо на PREROUTING поменять.

Не поможет. Т.к. HTB пихает в очередь только трафик, являющийся исходящим для какого-либо интерфейса. А в моем случае одна часть входящего трафика с ppp0 потом становится исходящей на eth0 (Как раз FORWARD. Этот трафик вполне нормально шейпится), а другая часть оседает на localhost и не становится исходящей ни для какого интерфейса. Вот как эту вторую часть шейпить я в толк и не возьму.

#305556
stalker_tk написал:
[quote="Kettler"]squid минус с работой с https (443).

В смысле... недружит? У меня проблем нет, правда у меня прокси прозрачный.[/quote]
не завернуть 443 на прокси.

#305558
Merzley написал:
[quote="Kettler"]Ограничение траффика (HTB) поищите на данном форуме, много тем было с примерами.

Везде, где искал, пишут, что адекватно шейпить входящий трафик нельзя. Это вполне логично, т.к. трафик уже пришел и замедлить его можно только отбросом уже пришедших пакетов, что выглядит по меньшей мере странно. Но мне как раз это и надо. Может все-таки есть какие-то обходные пути? Или стоит оставить эту затею и поставить на виртуалку еще одну систему и сделать ее маршрутизатором?[/quote]
я режу на eth0 (локалка) и ppp0 (vpn).

#305592
Kettler написал:
[quote=stalker_tk][quote="Kettler"]squid минус с работой с https (443).

В смысле... недружит? У меня проблем нет, правда у меня прокси прозрачный.[/quote]
не завернуть 443 на прокси.[/quote]
Можно попробовать поставить на сквиде свои сертификаты + залить в браузер сквидовский сертификат, часть сайтов (не самая лучшая) работать будут.

Merzley написал:
[quote="Kettler"]Ограничение траффика (HTB) поищите на данном форуме, много тем было с примерами.

Везде, где искал, пишут, что адекватно шейпить входящий трафик нельзя. Это вполне логично, т.к. трафик уже пришел и замедлить его можно только отбросом уже пришедших пакетов, что выглядит по меньшей мере странно. Но мне как раз это и надо. Может все-таки есть какие-то обходные пути? Или стоит оставить эту затею и поставить на виртуалку еще одну систему и сделать ее маршрутизатором?[/quote]
Никакой проблемы с перегрузкой канала на шейпинге не замечал, эксперементировал на торренте.

Войдите или зарегистрируйтесь, чтобы ответить.