Обсуждение статьи тематического каталога: Шейпер ADSL для домашней сети (shaper traffic adsl bandwidth linux fedora)Ссылка на текст статьи: https://www.opennet.ru/base/net/adsl_shaper.txt.html
Очень хорошая статья - вот только чтобы изменить скрипт под например 10 пользователей надо делать много поправок в нем. ИМХО лучше сделать список пользователей не набором переменных а массивом и засунуть все повторяющиеся действия в циклы. И скрипт короче будет и достаточно будет изменить список пользователей в начале чтобы все заработало. Если вам интересно этим заняться то могу помочь (в меру своих скромных возможностей). Сам такое переделывание не осилю ибо негде тестировать.
Я уже думал над этим. Действительно, получится много короче. Единственно, представленный вариант позволяет легко менять приоритеты и ширину полосы для отдельных пользователей, Ваш вариант тоже должен это уметь. Если возметесь - готов потестить и поделиться впечатлениями.
Если не возражаете я свяжусь в Вми по email указанному в заголовке статьи. Я начал разработку - но есть кое-какие неясности.
Прошу Вашего разрешения для публикации в статье с новым вариантом шейпера Ваших персональных данных.
Не возражаю. Данные см. в письме.
Мне _кажется_ что нужно
Автору ознакомится с
http://gazette.linux.ru.net/rus/articles/index-abs-guide.htmlИ переписать скрипт по уму.
>Мне _кажется_ что нужно
>Автору ознакомится с
>http://gazette.linux.ru.net/rus/articles/index-abs-guide.html
>И переписать скрипт по уму.Спасибо, Александр все сделал :-)
Я конечно хорошо знаком с данным опусом. Им и руководствовался.
Спасибо! Но времени у меня не так уж и много. Это не коммерческая разработка, но она реально работает, и те кто хотят ее использовать, не вникая в тонкости, могут легко это сделать.
Почему-то никто из уважаемых знатоков не выложил даже такого косо-кривой, но реально работающей программы.Что бы не заканчивать на такой минорной ноте, внесу небольшое дополнение.
В цепочку форварда iptables приведенные в статье рекомендации включаются так::limiting - [0:0]
:FORWARD_IN - [0:0]#Личные цепочки
:T10 - [0:0]
:T20 - [0:0]
# и т.д.# Автоматически уменьшать размер передаваемого пакета для ADSL
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu-A FORWARD -o ppp0 -j FORWARD_IN
-A FORWARD -i ppp0 -j FORWARD_OUT# Эта цепочка для блокировки пользователей автоматическими скриптами
# Но можно и руками
-A FORWARD_IN -j limiting# В этих цепочках ограничиваем каждого пользователя отдельно
# Кабинет
-A FORWARD_IN -s 192.168.100.20 -j T20
# Максимум 1 одновременное соединение c одного IP eth0 для smtp
#-A T20 -p tcp -m connlimit -i eth0 --dport smtp -j DROP --syn --connlimit-above 1
# Максимум 105 одновременных соединений c одного IP eth0 (ЛВС)
#-A T20 -p tcp -m connlimit -i eth0 -j DROP --syn --connlimit-above 105
# Защита от пинга смерти
-A T20 -p icmp -m limit --icmp-type echo-request --limit 10/s -j ACCEPT
-A T20 -p icmp --icmp-type echo-request -j DROP
-A T20 -j ACCEPT# И так далее...
> Почему-то никто из уважаемых знатоков не выложил даже такого косо-кривой, но реально работающей программы.зря вы так. такой скрипт существует уже несколько лет и называется он HTB (не путать с телеканалом).
# htb.init v0.8.5
# Copyright (C) 2002-2004 Lubomir Bulej <pallas@kadan.cz>
...
# To get the latest version, check on Freshmeat for actual location:
#
# http://freshmeat.net/projects/htb.initправда по этой ссылке его уже давно нет, но можно у гугла спросить
есть описание даже на этом сайте https://www.opennet.ru/docs/RUS/adv_route_qos/
>зря вы так. такой скрипт существует уже несколько лет и называется он
>HTB (не путать с телеканалом).
># htb.init v0.8.5
> http://freshmeat.net/projects/htb.init
>
>правда по этой ссылке его уже давно нет, но можно у гугла
>спросить
>есть описание даже на этом сайте https://www.opennet.ru/docs/RUS/adv_route_qos/Скрипт я смотрел, давно правда. Но цели у него были другие! Это скрипт для создания HTB шейпера, и он даже работал. Вот только - что именно скормить этому скрипту в качестве исходных данных для меня тогда осталось большой проблемой, а пример был невнятный.
Предложенная мною программа, а тем более ее модернезированный вариант, что сейчас доводится до ума совместно с Александром (см. первые посты) почти не требует специальных знаний и понимания происходящих процессов, она уже настроена как надо, а требуемые места хорошо документированы.
Прошу прощения, нужно убрать # из строчек
#-A T20 -p tcp -m connlimit -i eth0 --dport smtp -j DROP --syn --connlimit-above 1
и #-A T20 -p tcp -m connlimit -i eth0 -j DROP --syn --connlimit-above 105
Так будет абсолютно верно:
-A T20 -p tcp -m connlimit -i eth0 --dport smtp -j DROP --syn --connlimit-above 2
А как проверялась справедливость?
Дисциплина SFQ не позволяет абсолютно справедливо делить канал, она пытается равномерно размазать соединения, а надо, чтобы распределение шло на конкретный айпишник, в независимости от количества соединений.
Это верно! Но Вы говорите об несправедливости внутри одной полосы. А я завожу по полосе на каждого пользователя, обеспечиваю ему гарантированную полосу пропускания и остаток от неиспользованных чужих полос, согласно приоритету пользователя.
А несправедливость между отдельными программами самого клиента меня не беспокоит. Пусть выключает torrent, если хочет поиграть!
Скрипр рабочий
но IMHO шейпить входной трафик - не оправдано
>>>tc qdisc add dev $DEV_OUT handle ffff: ingressPS шейпить входной трафик вообще практически невозможно
На шейпинг входного трафик и не претендую. Эта цепочка только ограничивает скорость поступления SYN пакетов на вход. Если напрягает - можно и отключить. Нам не мешает, но сказать что вижу пользу я тоже не могу, не проверял.
Повесил бы squid на сервак что ли ;)А вообще если касается федоры то я бы сделал через СБКу /etc/sysconfig/cbq/...
>Повесил бы squid на сервак что ли ;)Я использую NAT. Соответственно шейпер работает по всем портам, почти вне зависимости от вида трафика, а не только 80 порт.
>А вообще если касается федоры то я бы сделал через СБКу /etc/sysconfig/cbq/...
Очень поддерживаю! И с удовольствием посмотрю на реально работающий _ВАШ_ вариант шейпера.
> Я использую NAT. Соответственно шейпер работает по всем портам,
> почти вне зависимости от вида трафика, а не только 80 порт.Пусть мне мои домашнии квалифицировано объяснят зачем им инет окромя 80 порта.
( аська в мессагах мало жрет а за фиреваллом все равно файло слать нельзя )> И с удовольствием посмотрю на реально работающий _ВАШ_ вариант шейпера.
был как то лет 5 подобный вопрос. Подумали и сказали что не нужно. А цбку-шку
на серваке-почтовом заюзал по портам ( 110,25) чтобы пересылаемое мыло-файло в 50 мег
не ложило канал !Эту фигню как у тебя лучше не для домашней сети юзать а провам.
>> Я использую NAT. Соответственно шейпер работает по всем портам,
>> почти вне зависимости от вида трафика, а не только 80 порт.
>Пусть мне мои домашнии квалифицировано объяснят зачем им инет окромя 80 порта.
>Эту фигню как у тебя лучше не для домашней сети юзать а провам.Я не говорил, что у меня домашняя сеть на 20 компьютеров :-).
Сеть _домовая_. Это значит, что собрался самый разный народ, для которого http трафик
не единственный, а почта не самое нужное применение инета.
Этот народ почти бесполезно уговаривать проявлять скромность, наоборот все хотят всего и побольше, и что бы никто не мешал.
Но минимальные требования:
- Отсутствие тормозов при WEB серфенге
- Игры в он-лайн (типа Contre-Strike, Warcraft и т.д.) без лагов и с высоким пингом. Причем порты для разных игрушек каждый раз меняются, а разбираться со вкусами молодежи у меня нет ни времени ни желания.
- Скачивание и отдача файлов из/в torrent. Тут, конечно, порты я раздавал сам. Но один раз!
- Возможность (потенциальная) скачивать файлы со скоростью выше гарантированной полосы.
Даже пять машин с такими запросами будут мешать друг-другу, так что шейпер пригодиться не только мини-провайдерам.
Так что наш выбор - NAT, а прокси сервер SQUID для такого разношерсного народа - только лишний тормоз на канале, на экономию трафика всем плевать! (Мне тоже)
Очень актуальная и нужная вещь.
Жду переработанной версии.
>Очень актуальная и нужная вещь.
>Жду переработанной версии.Благодаря самоотверженному труду Александра (alex2ndr) такая версия наконец появилась. Сейчас провожу тестовую проверку (хотя и так видно, что работает нормально, генерируемый пробный скрипт отличается от оригинала только размещением команд, но все же...)
Буду просить администратора ресурса внести изменения в статью, с учетом новой версии.
> start_out(){
> # Старт исходящего интерфейса. Например ppp0.
> #ip link set dev $DEV_OUT qlen $QLEN_OUT mtu $MTU_OUT
> # В оригинале правили MTU. Я не стал - и так все в порядке!Если не секрет, что есть "оригинал"?
Не секрет :-)
[[https://www.opennet.ru/base/net/adsl_qos.txt.html статья Anton Shuko]]
Об этом в начале написано, там и остальные ссылки есть.
Только там немного другой подход.
Я поставил во главу угла раздачу полос пользователям,
а в оригинале - раздавали полосы нужным протоколам и портам.
>Не секрет :-)
>[[https://www.opennet.ru/base/net/adsl_qos.txt.html статья Anton Shuko]]
>Об этом в начале написано, там и остальные ссылки есть.
>Только там немного другой подход.
>Я поставил во главу угла раздачу полос пользователям,
>а в оригинале - раздавали полосы нужным протоколам и портам.И правда.
Плохо читал статью, сорри.Могу порекомендовать выяснить точные значения скоростей, на которых соединился adsl модем.
И выставить RATE_IN и RATE_OUT чуть-чуть меньше реальных скоростей.
При выедании физического канала (входящего и исходящего) пинг все равно резко возрастает, несмотря на политики/приоритеты/шейперы.
А если программно шейпить трафик и не давать ему подойти к физическим границам, вы этого избежите.
Так и есть! Реальная скорость входящего трафика 8000кбит/с, а я выставляю 7000. Т.е. на скачки загрузки я отвожу 1000кбит/с. В оригинале, если Вы обратили внимание, еще больше резервируют. То же самое касается исходящего канала. Но в нем скорость плавает, в зависимости от удачности подключения (я все-таки смотрел, и не раз), поэтому там запас выставлен больше
У Вас там в конце второго варианта почему-то 2 раза exit 0 - уберите один
Понятия не имею, откуда взялся, нажмите на правку - увидете, что там только один! Но на всякий случай вставил перенос строки перед меткой конца блока кода - может в этом дело?
И не у Вас, а у Нас ;-)
Статья - супер!
Спасибо Вам за труд.
У меня как раз аналогичная сеть :) 8/~1 mbps + 22 клиента.
Подредактировал 2й скрипт под себя - все работает отлично!THX
>Статья - супер!
>Спасибо Вам за труд.
>У меня как раз аналогичная сеть :) 8/~1 mbps + 22 клиента.
>Подредактировал 2й скрипт под себя - все работает отлично!Подождите, есть еще и вариант шейпер+фаервол+проброс портов/DNS.
Основанный на варианте 2, он еще и корректно (по списку правил) управляет IPTABLES, обеспечивая высокий уровень защиты и требуемый доступ к серверу, проброс портов (для работы torrent и скачки файлов ICQ), а так же проброс DNS запросов от клиентов к провайдеру на 2 DNS сервера с вероятностью 50% (без использования BIND, что важно для начинающих).
Мы с Александром готовим новую статью, поэтому если есть замечания - особенно по шейперу, очень просим высказываться!
вопрос .
будит ли работать этот шейпер. если в качестве клиента будит выступать та машина где он крутить?
и вообще возможно ли это? поскажите что нужно для етого дописать.
Не совсем понятно, будут ли работать в интернете еще клиенты, кроме Вас.
Ну, положим, будут (ибо если это не так, то Вам и шейпер-то не нужен).
Тогда для них все тривиально - см. статью.
Иное дело Вы. В примере шейпер располагается на исходящих интерфейсах.
Для Вас такой только один - ppp0. Т.е. вы сможете шейпить исходящий трафик. Что бы долго не думать, ваша цепочка - 17 (все остальные пакеты), т.е. назначите для нее скорости и все.
А для входящего трафика шейпера для Вас как будто и не существует. Мало того, Ваша работа в сети (признаюсь, комфортная) будет приводить к сбоям входящего шейпера, т.к. ширина канала от заявленной (например 7000 кбит/с, как в примера) будет скакать например до 9000кбит/с (это если вы заняли 2 мбит/с или даже больше, если аппетиты неумерены). Естественно, что при полной загрузке канала тут же произойдет затор и образуются огромные очереди (причем у провайдера), со всеми вытекающими (в виде лагов и тормозов у всех).
Что же делать?
В таких случаях входящий трафик шейпят на виртуальном интерфейсе, c которого и забирают трафик как сам сервер, так и клиенты, например так делает IMQ.
Но IMQ это отдельная песня, если сделаете работоспособную версию, разрешаю дополнить статью, разумеется после согласования.
сильно не пинаете, я тока разбираюсь в этом
повторю вопрос более корректно.есть машина где крутится шейпер. есть три клиента, два из них безумно юзают торренты, третий неочень активен.Так вот мой вопрос заключался в том смогули я запустить на машине где шейпер к примеру торрент клиент, чтобы шейпер делил соответственно скорость для всех клиентов в том числе и для этой машины?.
Да, сможете запустить.
Но! Представленный в статье шейпер должен быть переписан, что бы входной шейпер (у меня он висит на eth0, смотрящей в локалку) повис на виртуальном интерфейсе, к которому и будет обращаться Ваша машина и все клиенты. Для этого либо используется IMQ, либо собственный виртуальный интерфейс и соответствующая маршрутизация сервера.
Так что, если Вы не очень в этом разбираетесь, то своими силами - вряд ли сможете.
Вообще, в Вашем случае, если конечно используется ADSL, лучше приобрести модем Zyxel P660HT2 EE
со встроенным шейпером (где-то за 48$). Шейпер, конечно, аховый - всего на 9 полос, но для Вас будет в самый раз. И сервант не понадобится, еще и свитч четырехпортовый в одном устройстве. Сам с успехом использовал, но те пользователи, которых пришлось поместить на одну полосу ну оччень возмущались! :-)
>Да, сможете запустить.
>Но! Представленный в статье шейпер должен быть переписан, что бы входной шейпер
>(у меня он висит на eth0, смотрящей в локалку) повис на
>виртуальном интерфейсе, к которому и будет обращаться Ваша машина и все
>клиенты. Для этого либо используется IMQ, либо собственный виртуальный интерфейс и
>соответствующая маршрутизация сервера.Если Ваш вопрос еще терпит, то как раз сейчас мы с Александром изучаем этот вопрос.
Действительно, удобнее всего размещать torrent на сервере.
Так что, надеюсь, через некоторое время будет модификация шейпера, использующая виртуальный интерфейс на входных каналах для ограничения входящего трафика.
терпит.!
спасибо что откликнулись. буду ждать
Мы используем NX Server - решение от No Machine для удаленной одновременной работе на серваке. Возможно ли так же создание двух виртуальных интерфейсов для двух сессий пользователей для справедливого разделение трафа между пользователями? В противном случае получается у одного (торренты на серваке+траф локально) у другого просто траф локально?
Сейчас разбираюсь с вашим скриптом. Потом хочу заняться этой проблемой. Что посоветуете?
Тестил скрипт через прозрачный прокси - работает. Почему то пришлось поднять RATE_OUT=5000 (реальная скорость 590кбит), т.к. отдавало клиенту только 10-20кбит при RATE_OUT=530.
Подскажите, пожалуйста, как включить (после шейпера) NAT для хостов в локалке, что бы были доступны другие сервисы/порты при данных в статье параметрах?
У Вас получился правильный результат.
Если конечно Вы спутали кбит/с и кбайт/с.
Почему я так думаю? Да просто все (что я пользуюсь, точно) программы выдают скорость в кбайтах/с. Торрент, например. Тогда:
Смотрите пример правила для исходящего интерфейса:
tc class add dev $DEV_OUT parent 1:1 classid 1:23 htb rate $[$RATE_OUT/$NNN]kbit ceil $[$RATE_OUT/2]kbit prio 5Команда ceil $[$RATE_OUT/2]kbit даст пользователю только половину от свободной полосы канала. И все! Т.е. с Ваших 590 получем (грубо) 59кБайт/с, делим на 2, получаем 29. Т.е. предел у пользователя 29. Но ведь он не один! Вот и получается, 10-20.
А своей командой RATE_OUT=5000 Вы попросту отключили шейпер, вернее урезали его функцию взаимодействия с провайдером. Ведь нужно не только делить полосу, но и не допустить у провайдера очереди - в этом и есть смысл назначения RATE_OUT ниже реальной пропускной способности. Иначе - тормоза по выходу (а в результате и по входу).
Т.е. хотите отдать весь свободный канал - уберите двойку, но не завышайте скорость!По последнеме вопросу, разжуйте, пожалуйста на конкретном примере с указанием адресов и условий :-)
Я Вас понял. При первых запусках скрипта все было в норме, только после многократных перезапусков (для подбора ширины канала) скорость стала неудовлетворительной, возможно я внес ошибку в скрипт. Меряю вот так http://www.speedtest.net/result/569938750.png
(подключен только один хост, т.е. отдает ~80% свободного канала и половину). На счет тормозов сказать не могу, нагрузка сейчас к удивлению очень мала.
Благодарю за подробный ответ.Отвечу на свой вопрос (tnx bioname), внешний адрес выдается динамический:
sudo iptables -t nat -D POSTROUTING -o ppp0 -j MASQUERADE
sudo iptables -A FORWARD -i eth1 -o ppp0 -j ACCEPT
>я внес ошибку в скрипт. Меряю вот так http://www.speedtest.net/result/569938750.png
>(подключен только один хост, т.е. отдает ~80% свободного канала и половину). На
>счет тормозов сказать не могу, нагрузка сейчас к удивлению очень мала.Попробуйте начать с начала и менять по шагам, с проверкой. По себе знаю - сделаешь два изменения (сразу), потом трудно найти концы.
>Отвечу на свой вопрос (tnx bioname), внешний адрес выдается динамический:
>sudo iptables -t nat -D POSTROUTING -o ppp0 -j MASQUERADE
>sudo iptables -A FORWARD -i eth1 -o ppp0 -j ACCEPTЛадно, вот Вам кусочек нашей следующей статьи:
FirewallStart(){
# Включаем перенаправление пакетов через ядро.
echo 1 > /proc/sys/net/ipv4/ip_forward
# Политики по умолчанию.
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT DROP
#Пробрасываем обращения к DNS провайдеру
# С вероятностью 50% на первый DNS
# Или на второй DNS, если первому не повезло
$IPT -A PREROUTING -t nat -i $DEV_IN -p udp -m udp --dport 53 -m statistic --mode random --probability 0.50 -j DNAT --to-destin
$IPT -A PREROUTING -t nat -i $DEV_IN -p udp -m udp --dport 53 -j DNAT --to-destination $DNS2:53
# Разрешаем вход и выход всем пакетам, связанным с локальным интерфейсом lo
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT
############################################################################
# НАСТРОЙКА СОЕДИНЕНИЙ С СЕРВЕРОМ
############################################################################
# Защита от атак с неправильными пакетами
$IPT -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
$IPT -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
$IPT -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
$IPT -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
$IPT -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
$IPT -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
# Разрешаем пакеты, относящиеся ко всем установленным соединениям
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Разрешаем вход и выход всем пакетам, относящимся к протоколу ICMP
#$IPT -A INPUT -p icmp -j ACCEPT
#$IPT -A OUTPUT -p icmp -j ACCEPT
# !!!!!!!!!! ТОЛЬКО ЕСЛИ ВНУТРЕНЯЯ СЕТЬ ДОВЕРЕННАЯ !!!!!!!!!!!!!
# Разрешаем пакеты, идущие из локальной сети на этот компьютер и
# с этого компа в локальную сеть
$IPT -A INPUT -i $DEV_IN -s $LOCAL_NET -j ACCEPT# Разрешаем соединения в соответствии с IN_ACCESS_LST и OUT_ACCESS_LST
# ................. тут логика разрешения
############################################################################
# НАСТРОЙКА ТРАНЗИТНЫХ СОЕДИНЕНИЙ
############################################################################
# Автоматически уменьшать размер передаваемого пакета. Важно для ADSL.
$IPT -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
# Разрешаем пакеты, относящиеся ко всем установленным соединениям
$IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# Т.е. все что запрошено из интернета пользователем, разрешено к возвращению
# Разрешаем транзитный icmp
$IPT -A FORWARD -p icmp -j ACCEPT
# Т.е. пинги
# Создаем цепочки для сортировки транзитного трафика и направляем его в них
$IPT -N allowip
$IPT -N allowport
$IPT -A FORWARD -s $LOCAL_NET -j allowip
# Разрешаем доступ для клиентов указанных в LOCAL_IPS
# если данная переменная пустая то разрешены все адреса из локальной сети# .............. тут логика допуска
# Но Вам, для простоты:
$IPT -A allowip -s $LOCAL_NET -j allowport# Накладываем ограничения на транзитные соединения – не более CONN_LIM от одного IP
$IPT -A allowport -p tcp -m connlimit --syn --connlimit-above $CONN_LIM -j DROP# Разрешаем транзитные соединения по разрешенным портам
# ............... тут логика разрешения доступа с локальных машин к внешним портам
# Но для Вас можно просто, доступ ко всему:
$IPT -A allowport -j ACCEPT# Тут логика для проброса запросов из инета на внутренние машины:
# Например, для проброса торрента, вставить свои цифры и повторить сколько надо:
$IPT -A FORWARD -i $DEV_OUT -d $ip -p tcp -m tcp --dport $port1 -j ACCEPT
$IPT -A FORWARD -i $DEV_OUT -d $ip -p udp -m udp --dport $port1 -j ACCEPT
# где $ip - ip клиентской машины , $port1 - пробрасываемый порт (вставьте свои строчки# Маркируем syn пакеты
$IPT -A PREROUTING -t mangle -p tcp --syn -j MARK --set-mark 1
# Назначаем одинаковое время жизни для пакетов
$IPT -t mangle -A PREROUTING -i eth0 -j TTL --ttl-set 64
# NAT через динамический IP адрес.
$IPT -t nat -A POSTROUTING -o $DEV_OUT -j MASQUERADEВ принципе - этого достаточно.
>[оверквотинг удален]
>после многократных перезапусков (для подбора ширины канала) скорость стала неудовлетворительной, возможно
>я внес ошибку в скрипт. Меряю вот так http://www.speedtest.net/result/569938750.png
>(подключен только один хост, т.е. отдает ~80% свободного канала и половину). На
>счет тормозов сказать не могу, нагрузка сейчас к удивлению очень мала.
>
>Благодарю за подробный ответ.
>
>Отвечу на свой вопрос (tnx bioname), внешний адрес выдается динамический:
>sudo iptables -t nat -D POSTROUTING -o ppp0 -j MASQUERADE
>sudo iptables -A FORWARD -i eth1 -o ppp0 -j ACCEPTsudo iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
>> Меряю вот так http://www.speedtest.net/result/569938750.pngПо моему, все правильно! Исходящая скорость как раз 50% от исходящего канала - формулу я Вам писал. Ну уберите /2, раз она Вас так смущает из формулы и будет весь канал.
>>Отвечу на свой вопрос (tnx bioname), внешний адрес выдается динамический:
>>sudo iptables -t nat -D POSTROUTING -o ppp0 -j MASQUERADE
>>sudo iptables -A FORWARD -i eth1 -o ppp0 -j ACCEPT
>
>sudo iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE?
Я и так понял, не беспокойтесь.
Возможно это баг системы. Но у меня не работает на 530kbit.
Я понимаю, что в килобайте 8 килобит. Скорость смотрю iptraf.
Скрипт переделывал заново (_xttp://home.ddns.mobi/tmp/adsl_qos.sh).
1. Почему 127.0.0.1 попал в список локальных адресов? Ведь тогда он снижает гарантированную полосу на входящем шейпере. Ну да ладно, допустим хотим шейпить выход самого сервера.
2. LOCAL_IPS=(
[1]="127.0.0.1 2 2 80"
[2]="10.0.1.65 4 1 70"
[3]="10.0.1.71 4 1 50"
[4]="10.0.1.72 5 1 50"
3. RATE_OUT=550
4. Тогда предельная скорость, разрешенная пользователям:
[1]=550*0,8=440 кбит/с
[2]=550*0.7=385 кбит/с
[3]=550*0.5=275 кбит/с
[4]=275 кбит/с
Ну и где Вы видите 530кБит/с?
Или Ваши клиенты вместе с Вами позабивали канал?
Тогда вопрос: а без шейпера, какая скорость? Вы можете ведь четко наблюдать изменение? Сделайте это.
Если в скрипте есть ошибка,ее нужно исправить.
>[оверквотинг удален]
>4. Тогда предельная скорость, разрешенная пользователям:
>[1]=550*0,8=440 кбит/с
>[2]=550*0.7=385 кбит/с
>[3]=550*0.5=275 кбит/с
>[4]=275 кбит/с
>Ну и где Вы видите 530кБит/с?
>Или Ваши клиенты вместе с Вами позабивали канал?
>Тогда вопрос: а без шейпера, какая скорость? Вы можете ведь четко наблюдать
>изменение? Сделайте это.
>Если в скрипте есть ошибка,ее нужно исправить.Вот такая без шейпера(это минимум что показывало)http://www.speedtest.net/result/570047431.png и с шейпером http://www.speedtest.net/result/570321717.png. Запущен этот скрипт http://home.ddns.mobi/tmp/firewall, хотя на сам фаирволл ругается.
>Вот такая без шейпера(это минимум что показывало)http://www.speedtest.net/result/570047431.png и с шейпером http://www.speedtest.net/result/570321717.png. Запущен
>этот скрипт http://home.ddns.mobi/tmp/firewall, хотя на сам фаирволл ругается.1. На рисунках разное время. Поэтому они мало о чем говорят, это должны быть два снимка подрят, с шейпером и без.
2. Не совсем понятно, к какому трафику относится измеренное значение, уточните источник, и тип пакетов.
3. И просто измерьте скорость iptraf, (там где детали Вашего инет интерфейса) для двух вариантов ПОДРЯД, мне так будет понятнее.
Жду результатов.По фаерволу. Ну еще бы ему не ругаться :-)
Этот текст нужно было поместить в функцию, где-то в середине текста, среди других функций:
FirewallStart(){
и т.д.
}
А саму функцию вызывать из:
case "$1" in
start)
FirewallStart
...
stop)
ShaperStopAll
Marking "-D"
FirewallStopСоответственно:
FirewallStop(){
# Выключить перенаправление пакетов через ядро.
echo 0 > /proc/sys/net/ipv4/ip_forward
# Сбрасывем все правила
# Удаляем все цепочки
$IPT -F
$IPT -X
$IPT -t nat -F
$IPT -t nat -X
$IPT -t mangle -F
$IPT -t mangle -X
# Открываем доступ к данному серверу. Доступ в интернет закрыт
# т к отключен NAT и запрещена пересылка пакетов между интерфейсами.
# Доступ из интернета к серверу так же запрещен
# Использовать только для отладки. Не допускается использование в рабочем режиме
$IPT -P INPUT DROP
$IPT -P FORWARD ACCEPT
$IPT -P OUTPUT ACCEPT
# Разрешаем доступ из локальной сети
$IPT -A INPUT -i $DEV_IN -j ACCEPT
############################################################################
}Тоже помещаем в ПЕРЕДНЮЮ часть скрипта (функции описываются ДО вызова)
Только что еще раз проверил работу шейпера, на исходящем канале.
У меня стоит ограничение для моей машины:
/sbin/tc class add dev ppp0 parent 1:1 classid 1:22 htb rate 25kbit ceil 420kbit prio 4
/sbin/tc filter add dev ppp0 parent 1:0 protocol ip prio 22 handle 22 fw flowid 1:22
(Это тестовый режим запуска моего шейпера, когда перед командами стоит echo, попробуйте - может и Вам поможет чем-то)
Т.е. Вы видете - мне ГАРАНТИРОВАНО 25 кбит/с и ПРЕДЕЛЬНАЯ ПОЛОСА 420 кбит/c
Запустил торрент на раздачу со своей машины без ограничения скорости.
Сейчас ночь, и надеюсь мало людей в нашей локалке.
iptraf рассказывает о 65кбайт/с на исходящем интерфейсе, (видимо люди все-таки есть)
торрент крутится около 49 кбайт/с исходящей скорости.
Как Вы видете, это примерно соответствует заданным 420 кбит/с. (Там вроде бы больше чем на 8 нужно умножать - я путаюсь, считается ли служебная информация или нет? Может даже вообще на 10? )
Так что - жду Ваших измерений.
хttp://www.onlinedisk.ru/file/222671/
У меня IPTraf настроен на отображение в kbit/sec.
Измерения проводил с приведенным ранее конфигом (хост 127.0.0.1).
Для честности интерфейс с которого раздается в локальную сеть временно был отключен. Меряю из внешней сети, наверное потому исходящий канал всегда чуть-чуть нагружен.
>хttp://www.onlinedisk.ru/file/222671/Раскрыл. Не понравилось отсутствие внятных подписей (приходится догадываться).
Ну да ладно. Давайте смотреть:
8:41 iptraf_out_full 676кбит/с
8:49 iptraf_in_full 250кбит/с
8:53 shape_in 207кбит/с
8:57 in_out_full 216кбит/с
9:12 shape_out_full 275кбит/с
Как я понял, диаграммы со словом shape соответствуют включению шейпера?
Но простите, что может сказать интервал измерения в десятки минут?
Снимки не обязательны, я Вам верю на слово, но например вот так:
Запустить два терминала, в одном запустить iptaraf, а в другом шейперу делать поочередно:
1. Start
2. Stop
И карандашиком, карандашиком, на бумажку.
Предлагаю забыть про эти результаты.
В скором времени я проведу более точные измерения для получения
внятных результатов.
В общем, проблема заключается в попытке шейпить трафик предназначенный клиенту на сервере. Правила, указанные в скрипте при этом явно не срабатывают. Т.е. для транзитного трафика все в порядке, а местный это отдельный вопрос. Который мы в настоящее время изучаем.
Мы используем NX Server - решение от No Machine для удаленной одновременной работе на серваке. Возможно ли так же создание двух виртуальных интерфейсов для двух сессий пользователей для справедливого разделение трафа между пользователями? В противном случае получается у одного (торренты на серваке+траф локально) у другого просто траф локально?
Сейчас разбираюсь с вашим скриптом. Потом хочу заняться этой проблемой. Что посоветуете? Читал комменты, я так понимаю IMQ?
C imq навскидку сложновато. Там надо ядро и iptables патчить и пересобирать. Но я думаю мы к этому придем (уже в процессе :) ). Насчет вашей ситуации - если я правильно понимаю можно попробовать обойтись параметром Мин_Канала. У того пользователя что локально это будет 2 а у того что есть и сервер и локалка и там и там будет 1. Как вам тут могут помочь виртуальные интерфейсы я не знаю.
Кажется понимаю о чем вы. Написав предыдущий пост я забыл, что то о чем говорил пока находиться в разработке.
Да - в том варианте что сейчас представлен в статье не учитывается трафик на самом сервере - соответственно он может сожрать весь входящий канал и ничего ему не будет. Да - в таком варианте надо использовать какой-то виртуальный интерфейс. Если у вас время терпит то ждите следующую версию - мы работаем над этим.
Да нужно учитывать траф сервера и делить еще его по пользователям сервера )). Я могу подождать (в течение какого времени?), но и сам пока буду разбираться если вы скажете куда копать.
С учетом трафика сервера мы работаем - сейчас как раз пытаемся ввести виртуальные интерфейсы. Трудно сказать сколько времени это займет - наверное не менее недели точно(т к нормально потестировать можно только в выходные а тут еще и ядро пересобирать).Но вот как учитывать трафик между пользователями одного сервера я пока не знаю. Для этого нужен какой-то прикладной посредник - т е что-то что будет разделять их на уровне приложений - tc так делать не умеет и iptables тоже под вопросом. Могу предложить другое решение - раз уж вы используете некоторый виртуальный сервер (я бы сказал скорее не виртуальный а терминальный) то может стоит пойти дальше и дать всем по полноценной виртуальной машине(тот же VmWare или Xen)? Тогда шейпить их будет совсем легко - для шейпера они будут выступать в роли клиентов из локальной сети (виртуальной локальной сети). Если грамотно поиграть с мостом (т е объединить интерфейсы в реальную локалку и виртуальную локалку мостом), то возможно и виртуального интерфейса (imq) не понадобится. Можете поработать в этом направлении.
Заодно и с точки зрения безопасности нормальная виртуальная машина будет правильнее. Сейчас у вас для торентов наверно порты открыты фактически на ваш сервер(т е в цепочках INPUT для iptables). Это есть дырка в безопасности.
>Сейчас у вас для торентов наверно порты открыты фактически на ваш сервер(т
>е в цепочках INPUT для iptables). Это есть дырка в безопасности.С чего бы это?
Разве через порты торрента можно залезть в систему?
Неизвестно можно ли залезть через порты торента в систему. Это зависит от ошибок в реализации торрент-клиента в системе. Если таковые есть то посылкой определенных пакетов можно получить определенные фокусы - от отказа в обслуживании до выполнения произвольного кода с рутовыми привилегиями. Все сетевые сервисы (apache, mysql, bind, ssh-server и тд) регулярно тестируют на такие уязвимости (относительно недавняя история с ошибкой в ssl ключах в debian ) и соответственно регулярно затыкают дыры. А вот кто тестирует торент клиенты и тд - неизвестно - наверно только взломщики :) . Я считаю что если для клиента допустимо держать такие порты - отказ одного клиента не нарушит работы сети. А вот если будет хотя бы отказ в обслуживании у сервера то это будет ой. Конечно вероятность этого не очень высока - но пренебрегать ею тоже не стоит.
Идея с Xen привлекательная (полное разделение), но ресурсов будет много требовать у нас с серваке всего то 512 МБ.
>Идея с Xen привлекательная (полное разделение), но ресурсов будет много требовать у
>нас с серваке всего то 512 МБ.Ну память нынче дешева :) можно еще 512 прикупить. Если такой возможности нету то подумать что и как надо сделать - если сервер используется только в качестве площадки для торентов то подумать о установке минимальной конфигурации линуха + торент-клиент с веб интерфейсом - по моим оценкам в 64 мб уложитесь. Если нужно еще что-то кроме торента то можно поставить Иксы по минимуму - lxde там какое-нить (не спец в этом). Или поставить ХР :) - сожрет 128 мб - но по минимуму будет работать.
Нащет ограничения трафа для пользователей сервака: можно маркировать пакеты по UID, так же маркировать по ИП а затем уже фильтровать в tc? Вариант? Тада и виртуальных сетевых интерфейсов не надо (IMQ).
>Нащет ограничения трафа для пользователей сервака: можно маркировать пакеты по UID, так
>же маркировать по ИП а затем уже фильтровать в tc? Вариант?
>Тада и виртуальных сетевых интерфейсов не надо (IMQ).Отмаркировать пакеты не проблема. Проблема - на чем создать очередь. Если как в статье - на выходах реальных интерфейсов, то получается что пользователь на сервере получит входящий трафик напрямую, т.к. он не будет проходить интерфейс eth0 (с исходящим трафиком на ppp0 все в порядке). Вот если бы можно было завернуть прошедшие от ppp0 на eth0 и обработанные в очереди eth0 пакеты обратно на lo...
>>Нащет ограничения трафа для пользователей сервака: можно маркировать пакеты по UID, так
>>же маркировать по ИП а затем уже фильтровать в tc? Вариант?
>>Тада и виртуальных сетевых интерфейсов не надо (IMQ).
>
>Отмаркировать пакеты не проблема. Проблема - на чем создать очередь. Если как
>в статье - на выходах реальных интерфейсов, то получается что пользователь
>на сервере получит входящий трафик напрямую, т.к. он не будет проходить
> интерфейс eth0 (с исходящим трафиком на ppp0 все в порядке).
>Вот если бы можно было завернуть прошедшие от ppp0 на eth0
>и обработанные в очереди eth0 пакеты обратно на lo...Ага! и для этого вы делаете виртуальный интерфейс?
Еще прочитал в википедии:
"Для того, чтобы использовать очереди на входящий трафик, на ядро были наложены дополнительные патчи. По словам разработчиков, из всех протестированных патчей наиболее результативным показал себя IMQ, который создает hook в iptables-таблице mangle. Однако, IMQ работает только при скоростях не более 10 Мбит, и, чтобы очереди на базе IMQ работали при больших скоростях, необходимо перевести ядро в режим 1000Гц, а netsheduler — в режим отсчета тиков от RTC-таймера вместо jiffies."Возникает вопрос как будет меняться загрузка процессора при приближении к 10 мбит?
>Еще прочитал в википедии:
>"Для того, чтобы использовать очереди на входящий трафик, на ядро были наложены
>дополнительные патчи. По словам разработчиков, из всех протестированных патчей наиболее результативным
>показал себя IMQ, который создает hook в iptables-таблице mangle. Однако, IMQ
>работает только при скоростях не более 10 Мбит, и, чтобы очереди
>на базе IMQ работали при больших скоростях, необходимо перевести ядро в
>режим 1000Гц,
>Возникает вопрос как будет меняться загрузка процессора при приближении к 10 мбит?Не следует так уж безоговорочно верить всему написанному в википедии.
Авторы этого материала забыли упомянуть используемое оборудование.
И потом - 10 мбит/с Вам мало?
>
>Не следует так уж безоговорочно верить всему написанному в википедии.
>Авторы этого материала забыли упомянуть используемое оборудование.
>И потом - 10 мбит/с Вам мало?Нет не мало. Вопрос в загрузке проца: если при таком раскладе - 90% это не хорошо. Увидим.
>Ага! и для этого вы делаете виртуальный интерфейс?Пока только собираемся. На самом деле есть еще одна задача которая его требует - но это потом.
>>Не следует так уж безоговорочно верить всему написанному в википедии.
>>Авторы этого материала забыли упомянуть используемое оборудование.
>>И потом - 10 мбит/с Вам мало?
>
>Нет не мало. Вопрос в загрузке проца: если при таком раскладе -
>90% это не хорошо. Увидим.В той статье ( http://ru.wikipedia.org/wiki/Ideco_ICS ) упоминается о ядре 2.24. Больше никакой информации такого плана я в интернете не нашел. Посмотрим - я собираюсь проверять его на виртуальной сети - там 1 Гб/с
В общем можно ограничить скорость по ип для пользователей на локальном интерфейсе отдельно от ограничения скорости для самого сервака на IMQ.А вот как ограничить суммарную скорость сервака + какой-нить пользователь (это случай когда он используется как терминальный для запуска торрентов и можно маркировать пакеты по UID пользователя) очереди разные для этих интерфейсов... =( ??
>В общем можно ограничить скорость по ип для пользователей на локальном интерфейсе
>отдельно от ограничения скорости для самого сервака на IMQ.
>
>А вот как ограничить суммарную скорость сервака + какой-нить пользователь (это случай
>когда он используется как терминальный для запуска торрентов и можно маркировать
>пакеты по UID пользователя) очереди разные для этих интерфейсов... =( ??
>Почему очереди разные - очереди одни и те же. Просто маркируйте пользователя на серваке и на локальном компе теми же номерами. У нас для идентификации используется ip, поэтому вам придется переписать наш скрипт с использованием ip и UID. Если клиентов мало можно все ручками прописать.
Почему одни и те же? У IMQ своя очередь у интерфейса смотрящего в локальную сеть своя. Или я ошибаюсь?
>Почему одни и те же? У IMQ своя очередь у интерфейса смотрящего
>в локальную сеть своя. Или я ошибаюсь?А это как организуете. Просто если есть imq то нужда организовывать очереди на интерфейсе в локалку отпадает. Пример - раньше вы ставили шейпер исходящего трафика на ppp0 а входящего на eth0. Теперь у вас есть imq - шейпер исходящего трафика вы оставляете на ppp0 а шейпер входящего переносите на imq. Остается по прежнему 2 очереди, только трафик сервера теперь попадает и во входящую (на eth0 он не попадал) - т е на imq вместе с трафиком клиентов.
Классно, получилось ограничить скорость сервака и пользователей сети на IMQ как вы и писали. Это радует. Только опять проблема. Хочу ограничить скорость для пользователя сервака. Если маркировать по uid (-m owner --uid-owner user1) то это будет работать для исходящих пакетов. Как быть с входящими?
Могу предложить теоретическое решение - на практике не проверялось.
Есть такая штука для iptables - цитата из Вики - ...
CONNMARK — устанавливает или изменяет маркировку соединения.
Поддерживает те же опции, что и MARK, а также дополнительные опции --restore-mark
(копирует маркировку соединения в маркировку пакета)
и --save-mark (копирует маркировку пакета в маркировку соединения)...
Т е вы на исходящем интерфейсе мудрите с маркировкой а на входящем восстанавливаете маркировку. Думаю для tcp будет работать. Как быть с udp пока не знаю.Еще вариант - вы жестоко разграничиваете пользователей на сервере по портам и потом маркируете по портам. Тоже не знаю как будет работать - может оказаться что так нельзя сделать.
Вообщем тут большой простор для поиска. Готовых решений у меня нет. Только есть небольшая просьба - если накопаете что либо - сообщите здесь или одному из нас письмом. Спасибо.
1) Борюсь с connmark хочу проверить хватит ли мне ограничения только tcp соединений. В принципе на сервере только торренты юзаются думаю хватит.пишу
iptables -A OUTPUT -t mangle -m owner --uid-owner user1 -j MARK --set-mark 22
iptables -A POSTROUTING -t mangle -j CONNMARK --save-mark
iptables -A INPUT -t mangle -m connmark --mark 22 -j MARK --set-mark 22
и всеравно пакеты попадают в дефолтную очередь а не в указанную фильтром
tc filter add dev $IMQ_IN parent 1:0 prio 5 handle 22 fw flowid 1:222) второе решение это направлять пакеты в NFQUEUE iptables. Писать прогу демон который будет смотреть порты назначения пакетов искать пользователя и ставить метку. Ну а дальше обычный путь в IMQ и т.д. жесть конечно но лучше не нашел пока что ))
О результатах отпишусь.
>[оверквотинг удален]
>пишу
>iptables -A OUTPUT -t mangle -m owner --uid-owner user1 -j MARK --set-mark
>22
>iptables -A POSTROUTING -t mangle -j CONNMARK --save-mark
>iptables -A INPUT -t mangle -m connmark --mark 22 -j MARK --set-mark
>22
>и всеравно пакеты попадают в дефолтную очередь а не в указанную фильтром
>
>tc filter add dev $IMQ_IN parent 1:0 prio 5 handle 22 fw
>flowid 1:22А --restore-mark разве на входе не требуется? Либо я чего-то не понимаю, либо у вас что-то не так.
>2) второе решение это направлять пакеты в NFQUEUE iptables. Писать прогу демон
>который будет смотреть порты назначения пакетов искать пользователя и ставить метку.
>Ну а дальше обычный путь в IMQ и т.д. жесть конечно
>но лучше не нашел пока что ))Ну это для совсем маньяков. Я например на C писать не усмею - только на питоне, но тут ресурсоемкая задача и питон не подойдет. Может такие демоны уже есть и следует их поискать?
>О результатах отпишусь.
Ждемс. Спасибо.
значит заработало с CONNMARK следующим образом надо было добавить protocol ip! чертовщина )
tc filter add dev $IMQ_IN parent 1:0 protocol ip prio 5 handle 22 fw flowid 1:22
и
iptables -A POSTROUTING -t mangle -j CONNMARK --save-mark
заменил на
iptables -A OUTPUT -t mangle -m owner --uid-owner user1 -j CONNMARK --set-mark 22
на всякий случай ;)чего намудрю еще напишу )
Описанным образом мы загнали в шейпер пакеты TCP, единственно принадлежащие соединениям. А вот интересно, UDP пакеты будут промаркированы?
Интересная система. Было бы здорово, если бы список пользователей хранился в отдельном файле. И ещё, как можно организовать работу с несколькими аплинками? Я вижу следующие сложности: несколько аплинков могут иметь разные скорости (можно несколько раз запускать скрипт с разными параметрами), а как быть с интерфейсом смотрящим в сеть (он же один для всех аплинков)? Чувствую и для этого понадобится imq.
Уже над этим думали и даже были варианты.
Например - список пользователей можно легко загрузить из файла, если он (список) имеет ту же структуру что и в скрипте. Чуть похуже, но тоже реализуем парсер файла конфигурации.Вариант с несколькими аплинками тоже прорабатывается, на самом деле ничего сложного в нем нет. Действительно, если рассматривать IMQ проблема снимается на корню, как и шейпирование локального трафика сервера. Но IMQ не у всех есть, а скрипт должен быть, по возможности, универсальным.
Но даже если IMQ нет - ничего страшного. Мы же используем на DEV_IN раздельные классы для интернет и локального трафика? Ну, будем использовать не 2, а три или четыре раздельных класса, что не заимствуют друг у друга скорость. А клиентов отправлять по классам через маркировку в IPTABLES, и кстати, такая же маркировка позволит нам легко выполнять маршрутизацию пакетов по интерфейсам.
Но разумеется, скрипт придется переписать, чем мы и занимаемся в настоящее время.
>Но даже если IMQ нет - ничего страшного. Мы же используем на
>DEV_IN раздельные классы для интернет и локального трафика? Ну, будем использовать
>не 2, а три или четыре раздельных класса, что не заимствуют
>друг у друга скорость. А клиентов отправлять по классам через маркировку
>в IPTABLES, и кстати, такая же маркировка позволит нам легко выполнять
>маршрутизацию пакетов по интерфейсам.Не могли бы Вы опубликовать эту реализацию, хотя бы в сыром виде без оснастки.
С радостью протестирую такой вариант.
Вариант уже готов. Разумеется бета. Но выкладывать пока не будем, а вот если хотите потестить - пишите на мой ящик, перешлю.
>Интересная система. Было бы здорово, если бы список пользователей хранился в отдельном
>файле.Как уже сказал Евгений мы работаем над этим. Вот только честно говоря реализация списка в отдельном файле на bash черевата написанием кучи велосипедов(т е парсера :) ) и тд. Будет трудно разобраться и размер вырастет - неоправданно короче. Я думаю что следующий вариант мы представим на bash и на python. Вариант на python будет работать с отдельным файликом с настройками. Причем я не вижу особых проблем вместо файлика с настройками прикрутить какую-либо СУБД (SQLite, MySQL и тд).
>И ещё, как можно организовать работу с несколькими аплинками? Я
>вижу следующие сложности: несколько аплинков могут иметь разные скорости (можно несколько
>раз запускать скрипт с разными параметрами), а как быть с интерфейсом
>смотрящим в сеть (он же один для всех аплинков)? Чувствую и
>для этого понадобится imq.Сейчас работаем над этим. Imq действительно одно из самых удобных решений проблемы - вот только пересборка ядра многих отпугивает ( даже разработчиков :) ). Да и патч с imq есть не под все ядра(максимум под 2.6.29), что тоже не прибавляет ему популярности. Пытаемся разработать вариант с ifb.
Для насыщения новой версии примерами использования, значительно облегчающими жизнь неопытным пользователям, что затрудняются с описательной частью скрипта, прошу излагать Ваши обстоятельства (сетевые интерфейсы, подсети, установленные на сервере службы или используемые на сервере интернет клиенты, необходимость удаленного доступа и т.д.). Если хотите - пишите лично.
Этот скрипт будет работать на mandrivе?
Linux Mandriva 2009 i586
Заранее благодарен.
>Этот скрипт будет работать на mandrivе?
>Linux Mandriva 2009 i586
>Заранее благодарен.Будет. Данный скрипт не зависит от конкретного дистрибутива. Главное чтобы были все используемые утилиты - ip, tc и iptables.
что то тишина !
проект загнулся?
нет.
Ни в коем случае! В ближайшее время планируется выход следующей статьи, с расширенным вариантом шейпер+фаервол. На баше, и если Александр успеет выгладить баги, на питоне. Функционал, естественно, в рамках необходимых авторам проекта (пока), а также тем добровольцам, что согласились участвовать в тестировании (это в основном про Антона).
классная идея!
Возможно ли вычислять max_rate машине самостоятельно (т.е. скачивание файла с инета), хранить его в качестве переменной?
>классная идея!
>Возможно ли вычислять max_rate машине самостоятельно (т.е. скачивание файла с инета), хранить
>его в качестве переменной?max_rate это максимальная скорость канала?
Мы думали над этим - но это сложная затея. Он разный для разных сегментов интернета в одинаковые промежутки времени. Например можно качать исходники ядра одновременно с разных зеркал - и скорость будет разная. К тому же такой замер занимет определенное время(несколько минут наверно) - поэтому сложно его сделать интерактивным. Пока есть идея просто пинговать ДНС провайдера и вносить изменения в max_rate в соответствии с задержкой. НО пока только на стадии идеи.
А когда выйдет последующая статья?
>А когда выйдет последующая статья?Мы ее пишем - но пока еще не могу назвать конкретных сроков. Уж больно много частных случаев попалось - пытаемся обобщить и упростить.
73: Syntax error: "(" unexpectedругается на эту скобку... что делать?
LOCAL_IPS=(
Кусок скрипта с массивом LOCAL_IPS целиком дайте. Или просто свяжитесь со мной по почте.
Во втором варианте скрипта задаем айпишники клиентовLOCAL_IPS=(
[1]="192.168.100.10 4 1 80"
[2]="192.168.100.20 4 1 70"
[3]="192.168.100.25 4 1 50"
...
...
)при попытке запуска вылетает с ошибкой Syntax error: "(" unexpected
Такое ощущение что где-то скобку забыли(или лишнюю написали) - но это по всему файлу искать надо. Также может быть вы не из под bash это запускаете(например в busybox). Если сами не найдете - присылайте.
Было бы интересно посмотреть на реализацию этого скрипта (да и испытать :)) для схемы:
eth0 смотрит в сеть
eth1 в интернет
стоит VPN сервер (pptpd) к которому подключаются(ppp0, ppp1 и т.д.) из сети и получают интернет через nat
но с учетом того к примеру, что у одного IP максимум входящий/исходящий канал 512/64, а у остальных 8192/1024
>Было бы интересно посмотреть на реализацию этого скрипта (да и испытать :))
>для схемы:
>eth0 смотрит в сеть
>eth1 в интернет
>стоит VPN сервер (pptpd) к которому подключаются(ppp0, ppp1 и т.д.) из сети
>и получают интернет через nat
>но с учетом того к примеру, что у одного IP максимум входящий/исходящий
>канал 512/64, а у остальных 8192/1024Думаю что такое возможно. Даже могу примерно представить схему как это реализуется. Но мы сейчас это реализовать не успеваем - готовим следующую статью.
Если вам хочется такой вариант (получить и испытать) то предлагаю разработать его самолично с нашей помощью. Свяжитесь со мной или Евгением, мы постараемся выдать направление и наброски куда копать. Но саму работу придется осуществлять Вам.
Александр преувеличивает сложность. В новом варианте, что сейчас готовится к публикации, эта задача решается в стандартных настройках. Единственно - ядро должно поддерживать IMQ.
Т.е. входящий трафик шейпится сразу на eth0 (это конечно не так, но для простоты...), а затем раздается клиентам, с необходимыми полосами пропускания. В этом случае все равно, куда идут пакеты - на ETH1 или через ppp*.
>Александр преувеличивает сложность. В новом варианте, что сейчас готовится к публикации, эта
>задача решается в стандартных настройках. Единственно - ядро должно поддерживать IMQ.
>
>Т.е. входящий трафик шейпится сразу на eth0 (это конечно не так, но
>для простоты...), а затем раздается клиентам, с необходимыми полосами пропускания. В
>этом случае все равно, куда идут пакеты - на ETH1 или
>через ppp*.Я предложил вариант направить весь трафик с ppp в ifb и шейпить его там. Решается это скриптом в 3 строки. Мне показалось что скрипт в 3 строки проще чем пересборка ядра и iptables. Но в любом случае запасной вариант с imq есть.
Погорячился я с ifb. Пришли к мнению что сделать такой фокус с помощью ifb не получится - только на imq.
Так как наша разработка уже вырастает за рамки отдельного скрита и появилось много интересующихся, то мы решили куда-нить все это выложить - http://asfs.sourceforge.net/Те кому интересен конкретная ситуация могут посмотреть в git - http://asfs.git.sourceforge.net/git/gitweb.cgi?p=asfs/asfs;a...
Пока обтачиваем то что есть и пишем статью.
Пользуюсь вашим шейпером на домашнм роутере (Ubuntu 9.10) Шейпит 6 человек. Скорость на нашем безлим меняется по времени суток, поэтому лежат несколько копий шейпера(с разными скоростями вход. канала), настроил cron на запуск по времени.
Пожелания на будущее...
1. выдавать icmp и dns максимальный приоритет
2. поскольку у одного клиента м.б. несколько ПК, делать одно ограничение скорости на эту группу ПК, например:
канал 1 мегибит
192.168.1.1 - клиент 1, шейпинг 0,5 мбит
192.168.1.2 - клиент 2 ноутбук
192.168.1.3 - клиент 2 сервер
у 2 и 3 динамический шейпинг в рамках своих 0,5 мегабит (т.е. по 0,25 мегабит) с последующим повышением до 0,5 при отключении клиента 1.Спасибо за ваш труд, у радостью потестим ваши новые версии!
Собственно новая версия на shell почти готова. Осталось ее потестить для функционала, отличного от того что есть у нас(т е в других условиях). Ваши пожелания там в принципе реализованы(1 точно, а о 2-м мы просто не думали - мне кажется с имеющимся функционалом это можно сделать - тестировать надо :) ). Лежит она пока тут -
http://asfs.git.sourceforge.net/git/gitweb.cgi?p=asfs/asfs;a...
Если желаете можете тестировать - если будут какие-то вопросы, проблемы и тд - связывайтесь с нами по почте. К сожаления без статьи которую мы готовим в ней трудно разобраться с налету.
когда ждать релиза?
>когда ждать релиза?Со статьей тормозим. У обоих работа навалилась. Наброски всех частей есть, но их еще нужно объединить в читабельную статью...
Сам скрипт в двух вариациях(python и shell) уже готов.
Python в пакетах можно взять тут -
http://sourceforge.net/projects/asfs/files/
или скачать с git и собрать.
версию на shell лучше брать из git - git://asfs.git.sourceforge.net/gitroot/asfs/asfs
или вот - http://asfs.git.sourceforge.net/git/gitweb.cgi?p=asfs/asfs;a...
значит подождем ман)
>значит подождем ман)Вы не поверите :) Man я тоже написал(правда только для питона). Пока такого содержания.
ASFS(8) ASFS(8)NAME
asfs - program for manage shaper and firewall rules.SYNOPSIS
asfs [-f] [-s] [-l] [-c CFGFILE] [-h] [--version] start|stop|restart|statusDESCRIPTION
This manual page documents briefly the asfs command.asfs is a frontend for tc and iptables. Allows you to customize the configuration of the flow of transit traffic through the editing of configura-
tion files.OPTIONS
These programs follow the usual GNU command line syntax, with long options starting with two dashes (`-'). A summary of options is included
below. For a complete description, see the Info files.-f, --fwonly
Create rules only for firewall (based on iptables). If this option is active, you should not use the -s option.-s, --sponly
Create rules only for shaper (based on tc). But rules for the shaper is used marking means iptables. If this option is active, you should
not use the -f option.-l, --onlylist
All rules will only be printed to standard output. No action will be made.-c CFGFILE, --config=CFGFILE
Path to configuration file. If this option is not specified will be used /etc/asfs/settings.cfg-h, --help
Show summary of options.--version
Show version of program.COMMANDS
start Create rules for action start. For shaper is creating classes, qdisk and filters for interfaces specified in config files. Also is creating
marking means iptables for the distribution of filters. For firewall is creating rules for elements specified in config files.stop Create rules for action stop. For shaper is deleting classes, qdisk and filters for all interfaces. For firewall is deleting all rules
means by iptables.restart
This command perform action stop then action start.status For shaper this command output detailed information about classes, qdisk and filters. For firewall this command output detailed information
about creating rules.
FILES
/etc/asfs/settings.cfg
The main configuration file. You must initially make changes to this file for asfs to work./etc/asfs/tables.cfg
This configuration file contains a table with settings for different types of strips of traffic. The path to the file defined in
/etc/asfs/settings.cfg/etc/asfs/scripts/custom_fw_rules.sh
This script execute after all firewall rules. You may add custom rules in this file. If you want add rules before use -I action.SEE ALSO
tc(8), iptables(8).AUTHOR
Но я понимаю, что вы про статью говорите. Ее пока пишем.
это снова я )) как там дела.?
очень интересно.
тоже с нетерпением жду релиза ;)
кто нибудь пробывал ставить из пакетов подготовленных автором ?
>кто нибудь пробывал ставить из пакетов подготовленных автором ?Есть люди, которые ставили. Вроде работает. Только надо этот пакет самому собирать из репозитория. Та версия(собранный пакет), что лежит на sourceforge немного устарела.
Пишите нам, господа, если что-то не получается. Наброски статьи выложу. Текст написан почти весь, но, увы, рисунки не все. Как-то не доходят руки нарисовать. Если кто возьмется помочь - милости прошу. Евгений начал делать в ms visio, а я с visio не очень... А переделать в dia у меня рука не поднимается. А самому Евгению - некогда.
а что на этих рисунках отображено? что то я не могу представить!
>а что на этих рисунках отображено? что то я не могу представить!
>Много всякого. Статья будет состоять из 2-х частей. Теория, в которой описываются общие аспекты, и которая содержит наибольшее количество рисунков и Практика, которая описывает как работать с новым скриптом шейпера. Практика рисунков не содержит.
Теорию выложил здесь:
http://ubuntologia.ru/forum/viewtopic.php?f=109&t=3324
Отсутствующие рисунки сами увидите. В принципе они рисуются на основе уже нарисованного и исходники есть, но с visio я не очень...
Картинки там теперь почему-то плоховатого качества, но у меня есть все оригиналы нормального качества. Вероятно этот radikal со временем сжимает большие картинки.
>кто нибудь пробывал ставить из пакетов подготовленных автором ?да и получилось:
[root@server Документы]# ./adsl_qos restart
Shaping removed on ppp0/eth0.
Поднимаем шейпер на выходном интерфейсе ppp0
Поднимаем шейпер на входном интерфейсе eth0
Illegal "match"
Что делать?
>>кто нибудь пробывал ставить из пакетов подготовленных автором ?
>
>да и получилось:
>[root@server Документы]# ./adsl_qos restart
>Shaping removed on ppp0/eth0.
> Поднимаем шейпер на выходном интерфейсе ppp0
> Поднимаем шейпер на входном интерфейсе eth0
>Illegal "match"
> Что делать?Правила то применились? Какой дистриб, какая версия баша и тд.? Заполнили настройки верно?
Вы ее из репа взяли или откуда?Как-то было такое, что сыпались похожие ощибки, но вроде все пофиксили. Похоже на опечатку. Тестировать можно так: расставить в коде всякие echo с разными номерами и смотреть после какого вылезает ошибка. У нас мало тестеров, поэтому кое-что может быть не отлажено.
да статейка хорошая . прочел. сохранил.
Но это теория ,а как на счет самой установки на настройки shell скрипта , со всеми последствиями и с вариантом IMQ.?
ой. не сразу догнал!
ждем практику
ребята ! когда ожидать практику !?
>ребята ! когда ожидать практику !?Лето, поэтому нам не до этого - отпуска :)
Сейчас осенью постараемся добить.
есть предложение в секции проброса портов добавить возможность указания IP адреса источника.
Это предлагается сделать для безопасности? Или есть какой-то иной смысл?Если я правильно понял, то что вы предлагаете сделать называется фильтрацией. И ее можно отдельно настроить в таблицах доступа(для последнего скрипта). А добавлять фильтрацию в правила для DNAT не стоит - авторы iptables не рекомендуют.
Я поражен! Спасибо огромное, буду изучать.
Ребята, спасибо за скрипт, но не пойму почему не работает. Нет ошибок, но роутинг не работает. Ось убунту 10.10 server.
eth0 на DHTP он к модему, соединении есть.
eth1 локала. Статика. В чем может быть проблема.
Да, http://sourceforge.net/projects/asfs/files/Debian%20Lenny/ это что за зверь, ваша робота или других людей. Он, как я понял на питоне. Кто-то пробовал.
В общем ситуация такая: сервера нет, но есть Роутер D-Link DIR 320 (Флеш - 4MB, ОЗУ - 32MB(есть возможность расширить до 64) и USB флешка на 4GB) с альтернативной пришивкой от "Олега" на базе Linux, версия 1.9.2.7-d, ядро 2.4.37. Вопрос будет ли данный шейпер работать на нём?
PS: Пробовал запустить, выдаёт ошибку
"/usr/local/sbin/adsl_qos: line 73: syntax error: unexpected "(""