Доброго времени суток. Не знаю, как кратко задать вопрос, поэтому сначала обрисую ситуацию.
Есть компьютер, подключенный к интернету через интерфейс 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. Буду рад также советам по тому, что можно почитать в этой области.
вопрос по HTB (tc)
P.S. Буду рад также советам по тому, что можно почитать в этой области.
Squid не то?
P.S. А что такое НТВ?
Squid не то?
Сейчас посмотрю. Раньше с управлением трафиком не работал, поэтому начал копать в сторону того, что первым в поиске попалось.
P.S. А что такое НТВ?
Очередь HTB (Hierarchy Token Bucket - иерархический буфер токенов) реализует мощную иерархию классов с упором на согласование с существующей практикой. HTB обеспечивает гарантированную полосу пропускания для классов, также позволяет устанавливать верхние пределы межклассового разделения очереди. Содержит объекты ограничения, базирующиеся на TBF, и может устанавливать приоритеты для классов. (С)http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=tc
Я так понял, что это шейпер, встроенный в ядро и настраивающийся с помощью стандартной утилиты tс.
htb.init - более высокоуровневая надстройка.
Squid не то?
Squid (англ. squid — «кальмар») — программный пакет, реализующий функцию кэширующего прокси-сервера для протоколов HTTP, FTP, Gopher и (в случае соответствующих настроек) HTTPS. (C)http://ru.wikipedia.org/wiki/Squid
Выходит, что Squid - прокси сервер, да еще и работающий с прикладными протоколами. Не то. Web трафик мне трогать не надо. Мне нужно регулировать скорость на уровне TCP, чтобы трафику приходящему на TCP порт 29000 выделить гарантированный канал.
Если я не прав, и при помощи Squid можно этого добиться - прошу простить невежду и поправить. А пока пойду поподробнее покурю маны по Squid.
Очередь HTB (Hierarchy Token Bucket - иерархический буфер токенов) реализует мощную иерархию классов с упором на согласование с существующей практикой. HTB обеспечивает гарантированную полосу пропускания для классов, также позволяет устанавливать верхние пределы межклассового разделения очереди. Содержит объекты ограничения, базирующиеся на TBF, и может устанавливать приоритеты для классов. (С)http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=tc
Я так понял, что это шейпер, встроенный в ядро и настраивающийся с помощью стандартной утилиты tс.
htb.init - более высокоуровневая надстройка
Спасибо буду знать
squid минус с работой с https (443).
Ограничение траффика (HTB) поищите на данном форуме, много тем было с примерами.
squid минус с работой с https (443).
В смысле... недружит? У меня проблем нет, правда у меня прокси прозрачный.
Ограничение траффика (HTB) поищите на данном форуме, много тем было с примерами.
Везде, где искал, пишут, что адекватно шейпить входящий трафик нельзя. Это вполне логично, т.к. трафик уже пришел и замедлить его можно только отбросом уже пришедших пакетов, что выглядит по меньшей мере странно. Но мне как раз это и надо. Может все-таки есть какие-то обходные пути? Или стоит оставить эту затею и поставить на виртуалку еще одну систему и сделать ее маршрутизатором?
Так. Я что непонял. Вам нужно ограничить трафик который уже идёт от клиента к вашему шлюзу. Верно???
При попытке забить канал с компьютера в локалке - все работает, т.е. игрушке отдаются гарантированные 64 Кбит. Но трафик с компьютера, который раздает интернет не учитывается HTB и, соответственно, профита нет. Собственно вопрос: что можно сделать, чтобы HTB учитывал трафик с главного компьютера? Или может есть какое лучшее решение? Заранее спасибо.
Исходя из этого сделаю предположение, это не шлюз в его понимании, а шлюз + на этом компе еще и работают, те надо и ему траффик резать...тогда FORWARD надо на PREROUTING поменять.
[quote="Kettler"]Ограничение траффика (HTB) поищите на данном форуме, много тем было с примерами.
Везде, где искал, пишут, что адекватно шейпить входящий трафик нельзя. Это вполне логично, т.к. трафик уже пришел и замедлить его можно только отбросом уже пришедших пакетов, что выглядит по меньшей мере странно. Но мне как раз это и надо. Может все-таки есть какие-то обходные пути? Или стоит оставить эту затею и поставить на виртуалку еще одну систему и сделать ее маршрутизатором?[/quote]
С идеологической точки зрения нельзя, но технически можно ограничить скорость входящего трафика . Реализуется с помощью псевдо-интерфейса ifb (для tcp).
Исходя из этого сделаю предположение, это не шлюз в его понимании, а шлюз + на этом компе еще и работают, те надо и ему траффик резать...
Точно так. У меня только мобильный интернет, а роутера с поддержкой USB модемов в наличии нету. Поэтому раздавать интернет своим домашним приходится через свой рабочий компьютер.
С идеологической точки зрения нельзя, но технически можно ограничить скорость входящего трафика . Реализуется с помощью псевдо-интерфейса ifb (для tcp).
Спасибо за направление. Сейчас посмотрю, что это такое.
Пока обошелся тем, что на виртуалке запустил систему исключительно в качестве шлюза. Лишние 150Мб памяти не сильно напрягают да и экспериментировать удобнее. Но все-таки хочется понять, можно ли сделать по-человечески. Исключительно спортивный интерес. Буду дальше копать.
Да, еще:
тогда FORWARD надо на PREROUTING поменять.
Не поможет. Т.к. HTB пихает в очередь только трафик, являющийся исходящим для какого-либо интерфейса. А в моем случае одна часть входящего трафика с ppp0 потом становится исходящей на eth0 (Как раз FORWARD. Этот трафик вполне нормально шейпится), а другая часть оседает на localhost и не становится исходящей ни для какого интерфейса. Вот как эту вторую часть шейпить я в толк и не возьму.
[quote="Kettler"]squid минус с работой с https (443).
В смысле... недружит? У меня проблем нет, правда у меня прокси прозрачный.[/quote]
не завернуть 443 на прокси.
[quote="Kettler"]Ограничение траффика (HTB) поищите на данном форуме, много тем было с примерами.
Везде, где искал, пишут, что адекватно шейпить входящий трафик нельзя. Это вполне логично, т.к. трафик уже пришел и замедлить его можно только отбросом уже пришедших пакетов, что выглядит по меньшей мере странно. Но мне как раз это и надо. Может все-таки есть какие-то обходные пути? Или стоит оставить эту затею и поставить на виртуалку еще одну систему и сделать ее маршрутизатором?[/quote]
я режу на eth0 (локалка) и ppp0 (vpn).
[quote=stalker_tk][quote="Kettler"]squid минус с работой с https (443).
В смысле... недружит? У меня проблем нет, правда у меня прокси прозрачный.[/quote]
не завернуть 443 на прокси.[/quote]
Можно попробовать поставить на сквиде свои сертификаты + залить в браузер сквидовский сертификат, часть сайтов (не самая лучшая) работать будут.
[quote="Kettler"]Ограничение траффика (HTB) поищите на данном форуме, много тем было с примерами.
Везде, где искал, пишут, что адекватно шейпить входящий трафик нельзя. Это вполне логично, т.к. трафик уже пришел и замедлить его можно только отбросом уже пришедших пакетов, что выглядит по меньшей мере странно. Но мне как раз это и надо. Может все-таки есть какие-то обходные пути? Или стоит оставить эту затею и поставить на виртуалку еще одну систему и сделать ее маршрутизатором?[/quote]
Никакой проблемы с перегрузкой канала на шейпинге не замечал, эксперементировал на торренте.