tc+iptables+squid (трафик сквида не режется)

[falcol]

Здравствуйте. Есть сервер Linux Mandriva 2010. Он раздает инет абонентам. В iptables цепочки INPUT и FORWARD по умолчанию DROP. подсеть клиентов 192.168.0.0/16
iptable -A POSTROUTING -o eth0 -s 192.168.0.0/16 -j SNAT --to-source внеший_ip - это нат
iptables -A FORWARD -s 192.168.0.0/16 -j ACCEPT это открывает доступ к инету от пользователя.
iptables -A FORWARD -d UserIP -j ACCEPT это открывает доступ к инету к пользователю.
iptables -t mangle -A FORWARD -d UserIP -j MARK --set-mark User_ID это маркирует пакеты идущие к пользователю
iptables -t mangle -A FORWARD -s UserIP -j MARK --set-mark User_ID то же только от него
tc filter add dev eth1 parent 1: protocol ip handle User_ID prio 3 fw classid 1:User_ID это фильтр на входящий траффик
tc filter add dev eth0 parent 1: protocol ip handle User_ID prio 3 fw classid 1:User_ID это на исходящий
tc class add dev eth1 parent 1:User_ID classid 1:User_ID htb rate 130kbit ceil 150kbit этот класс режет на 128 кбит входящий
tc class add dev eth0 parent 1:User_ID classid 1:User_ID htb rate 130kbit ceil 150kbit это класс режет на 128 исходящий
Есть еще конечно корневые дисциплины, привязанные к интерфейсам, но я думаю их смысла нет тут писать.
В обе стороны траффик режется... но когда включаю сквид - трафик через сквид начинает гнать на всю... я пробовал в PREROUTING mangle добавлять метку - не помогает. Я так понимаю трафик режется тот который идет мимо сервера. Но как резать который идет от сервера к абоненту и обратно.

Сквид сейчас в режиме transparent на порту 3128
Добавляя правило iptables -A PREROUTING -p tcp --dport 80 -s 192.168.0.0/32 -j REDIRECT --to-port 3128 Траффик начинает летать без ограничения,также как и если без правила в настройках браузера прописать прокси.

Теперь собственно вопрос.
Как со всем этим безобразием сделать, чтобы траффик идущий через сквид тоже резался.
Спасибо!

[liaonau]

Но как резать который идет от сервера к абоненту и обратно.
Сквид сейчас в режиме transparent на порту 3128

Трафик со сквида в интернет и обратно, с сервера — это не FORWARD а INPUT и OUTPUT. OUTPUT можно шейпить легко, а для INPUT надо петля imq или, что легче — есть в ванильном ядре, ifb.

[liaonau]

Правда ifb работает до netfilter и на него придется завернуть весь входящий трафик.

[kisil]

А обрезать трафик который идёт через сквид самим сквидом не пробовали?
Delay pools кажысь так называетса директива которая даёт возможность резать скорость Сквидом. Это в его конфиге поищите, там точно есть

[falcol]

Трафик со сквида в интернет и обратно, с сервера — это не FORWARD а INPUT и OUTPUT. OUTPUT можно шейпить легко, а для INPUT надо петля imq или, что легче — есть в ванильном ядре, ifb.

Спасибо, буду пробовать ОУТПУТ

А обрезать трафик который идёт через сквид самим сквидом не пробовали?
Delay pools кажысь так называетса директива которая даёт возможность резать скорость Сквидом. Это в его конфиге поищите, там точно есть

Резать сквидом - это не то, нужно динамически добавлять и удалять правила!

ПС
Вот опять не пишит английскими. нажимаю на клавиатуре английские буквы на английской раскладке,печатаются вот как слово ОУТПУТ. вместо OUTPUT Почему-то на этом форуме всегда так. Будто какой-то транслятор работает.

[falcol]

iptables -t mangle -A OUTPUT -d UserIP -j MARK --set-mark User_ID
ура, входящий заработал, а вот исходящий ни в цепочке инпут не режется ни в оутпут

[Alex2ndr]

Вы пытаетесь скрестить ужа с ежом. Вам не хватает колючей проволоки?

На вашем пути есть пара проблемм:

1. На линуксе нельзя шейпить входящий на интерфейс трафик(т е идущий через ingress очередь). Можно только исходящий с интерфейса( т е тот, что идет через egress). Поэтому, чтобы шейпить входящий трафик сервера(а т к весь трафик предназначен проксе, то он весь трафик сервера) нужно извращаться - перенаправлять входящий трафик на интерфейс в исходящий трафик другого интерфейса(виртуального). В этом вам поможет IFB - поищите на форуме, я уже кому-то делатьно описывал как это делается.

2. Т к весь трафик через проксю выглядит трафиком сервера, то вы не сможете его шейпить по пользователям - только целиком( т е одной полосой). Вы это осознаете? Если ваш шейпер распределяет по типа трафика(например VOIP приоритетнее веба, а тот в свою очередь приоритетней торрента), то думаю проблемм не возникнет. А вот если вы распределяете поровну между пользователями... тогда имхо вам придется отказаться либо от прокси, либо от шейпера.

[alex_suse]

2. Т к весь трафик через проксю выглядит трафиком сервера, то вы не сможете его шейпить по пользователям - только целиком( т е одной полосой). Вы это осознаете? Если ваш шейпер распределяет по типа трафика(например VOIP приоритетнее веба, а тот в свою очередь приоритетней торрента), то думаю проблемм не возникнет. А вот если вы распределяете поровну между пользователями... тогда имхо вам придется отказаться либо от прокси, либо от шейпера.

Это смотря какая задача стоит.
Ежели урезать клиентов на интернетовском канале, тогда да, трафик там общий. Если же в принципе хочется урезать пользователя, то, когда прокси отдает пакеты клиенту тут его и можно порезать.

[falcol]

2. Т к весь трафик через проксю выглядит трафиком сервера, то вы не сможете его шейпить по пользователям - только целиком( т е одной полосой). Вы это осознаете? Если ваш шейпер распределяет по типа трафика(например VOIP приоритетнее веба, а тот в свою очередь приоритетней торрента), то думаю проблемм не возникнет. А вот если вы распределяете поровну между пользователями... тогда имхо вам придется отказаться либо от прокси, либо от шейпера.

Это смотря какая задача стоит.
Ежели урезать клиентов на интернетовском канале, тогда да, трафик там общий. Если же в принципе хочется урезать пользователя, то, когда прокси отдает пакеты клиенту тут его и можно порезать.

Нам нужно "впринципи урезать пользователя". Но как я понял так не получится, т.к. шейпер может резать входящий траффик на интерфейсе... т.е. у меня то что идет от пользователя режется на интерфейсе который смотрит на пользователя,а тот траффик который идет к пользователю режется на интерфейсе который смотрит в интернет. Таким образом для шейпера в обоих случаях получается что он режет входящий траффик.
Кстати, а нельзя ли на локальном интерфейсе так резать?

[Alex2ndr]

Если же в принципе хочется урезать пользователя, то, когда прокси отдает пакеты клиенту тут его и можно порезать.

Такое возможно - тут вы правы. Но вот нужно ли?

Рассмотрим эту ситуацию подробнее. Прежде всего - что нужно от шейпера - регулировка КАНАЛА В ИНТЕРНЕТ. Чтобы никто не сожрал больше чем нужно. Вася качает 10гиг, Петя - 1мб. Понятно что нужно шейпить, чтобы Вася не борзел. Но посмотрим как же работает предложенная схема:
1. От Васи и Пети поступает запрос к проксе на получение файла/странички. По пути к проксе эти запросы пошейпятся и дойдут до прокси справедливо.
2. Прокся получает запросы от пользователей и пересылает их в интернет. Но теперь по этим запросам нельзя сказать чьи они, т к они идут с source addr = адрес внешнего интерфейса прокси. После этого происходит получение файлика на 10Гб и на 1мб, но разделить этот процесс тоже не получится, т к эти файлики пока едут проксе. Таким образом внешний канал в инет используется совсем не справедливо.
3. Закачав к себе в кэш нужные странички прокся начинает отдавать их пользователям. На данном этапе снова подключается шейпер, но он фактически регулирует не скорость интернет канала а скорость канала в локальную сеть. Скорость инета регулировать поздно.

И зачем такое нужно? Только если скорость локалки меньше скорости внешнего канала...

[Alex2ndr]

Нам нужно "впринципи урезать пользователя".

Тогда забудьте о проксе.

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

Все наоборот. В классическом случае трафик которые идет от пользователя в интернет режется на внешнем интерфейсе. А трафик который идет из инета к пользователю - на внутреннем(локальном) интерфейсе. Таким образом в обоих случаях он режет ИСХОДЯЩИЙ трафик. Поэтому вы и можете зашейпить трафик сервера в интернет - он выходит через тот же внешний интерфейс, где идет трафик пользователей и где стоит шейпер. Но обратный трафик - из интернета к серверу - вы зашейпить не можете, т к шейпер для него стоит на локальном интерфейсе, а туда трафик сервера никак не попадает.
Но это если не использовать хаков типа IFB и IMQ.

[falcol]

Нам нужно "впринципи урезать пользователя".

Тогда забудьте о проксе.

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

Все наоборот. В классическом случае трафик которые идет от пользователя в интернет режется на внешнем интерфейсе. А трафик который идет из инета к пользователю - на внутреннем(локальном) интерфейсе. Таким образом в обоих случаях он режет ИСХОДЯЩИЙ трафик. Поэтому вы и можете зашейпить трафик сервера в интернет - он выходит через тот же внешний интерфейс, где идет трафик пользователей и где стоит шейпер. Но обратный трафик - из интернета к серверу - вы зашейпить не можете, т к шейпер для него стоит на локальном интерфейсе, а туда трафик сервера никак не попадает.
Но это если не использовать хаков типа IFB и IMQ.

А, ну да, перепутал))

[alex_suse]

Если же в принципе хочется урезать пользователя, то, когда прокси отдает пакеты клиенту тут его и можно порезать.

Такое возможно - тут вы правы. Но вот нужно ли?

Рассмотрим эту ситуацию подробнее. Прежде всего - что нужно от шейпера - регулировка КАНАЛА В ИНТЕРНЕТ. Чтобы никто не сожрал больше чем нужно. Вася качает 10гиг, Петя - 1мб. Понятно что нужно шейпить, чтобы Вася не борзел. Но посмотрим как же работает предложенная схема:
1. От Васи и Пети поступает запрос к проксе на получение файла/странички. По пути к проксе эти запросы пошейпятся и дойдут до прокси справедливо.
2. Прокся получает запросы от пользователей и пересылает их в интернет. Но теперь по этим запросам нельзя сказать чьи они, т к они идут с source addr = адрес внешнего интерфейса прокси. После этого происходит получение файлика на 10Гб и на 1мб, но разделить этот процесс тоже не получится, т к эти файлики пока едут проксе. Таким образом внешний канал в инет используется совсем не справедливо.
3. Закачав к себе в кэш нужные странички прокся начинает отдавать их пользователям. На данном этапе снова подключается шейпер, но он фактически регулирует не скорость интернет канала а скорость канала в локальную сеть. Скорость инета регулировать поздно.

И зачем такое нужно? Только если скорость локалки меньше скорости внешнего канала...

Это понятно, что канал интернета мы не отрегулируем по клиенту.
Это ограничение работы клиента на сообразительность Если он увидит, что его 10Гб файл будет заливаться со скоростью 100Кб он наверное откажется от такого решения Хотя понятно, что не факт.
Или это можно использовать как временное ограничение, допустим если пользователь привысил некий порог в сутки, то зарезать скорость до неприличной.