Решено: Повысить приоритет исходящего от роутера в Инет трафика.. (опять не понимаю к какому интерфейсу прицепить цейпер)

[gard]

Здравствуйте!
Вот только на меня сегодня снизошло озарение (спасибо этому форуму), как при дальнейшем решении задачи я опять оказался в тупике. Повторяюсь..

Моя схема:
ADSL Inet (DynamicIP) Modem --- eth0(192.168.0.1) --- Ubuntu --- eth1(192.168.1.1) --- LAN (1921.68.1.0/24).

При соединении по pppoe у меня появляется интерфейс ppp0. И опять повторяюсь (к чему я пришел)..

То есть через ppp0 я могу ограничить:
- исходящую от меня в Интернет tc qdisc add dev ppp0 root handle 1:
- обрезать входящую ко мне из интернета (просто DROP policer) tc qdisc add dev ppp0 ingress handle ffff:

А через eth1 я могу ограничить:
- исходящую от меня в локальную сеть tc qdisc add dev eth1 root handle 1:

Начал обдумывать схему приоритизации трафика и уперся в стену. Для того, чтобы при максимально загруженном пользователями (пользователи в локальной сети) канале иметь доступ к серверу по SSH, я решил расставить метки в iptables на пакеты идущие на 22 порт и с 22 порта. То есть я помечаю их MARK например единицей в цепочках OUTPUT и PREROUTING (либо же INPUT). Скорость пакетов, которые идут от роутера (от него самого и от пользователей локальной сети.. все верно?) в Интернет я регулировать могу:

- исходящую от меня в Интернет tc qdisc add dev ppp0 root handle 1

А вот как отрегулировать скорость пакетов, идущих на роутер из Интернета? Я ограничиваю только пользователей локальной сети через eth1:

А через eth1 я могу ограничить:
- исходящую от меня в локальную сеть tc qdisc add dev eth1 root handle 1:

Получается, что "перескочив" роутер, я уже дальше ограничиваю _исходящую_ скорость от моей eth1 в локальную сеть. К какому же интерфейсу, какого типа дисциплину подключать (root, ingress)? Может подцеплять к той же eth1? Тогда какой фильтра добавить?

[danger08]

А вот как отрегулировать скорость пакетов, идущих на роутер из Интернета?

То, что для самого роутера, маркировать нужно по INPUT. Пакеты, ранее маркированные в PREROUTING, будут просто перемаркированы, транзитные пакеты это не затронет. Только проверьте, что после маркировки по PREROUTING прохождение пакетов по mangle продолжается (нет возврата после маркировки по PREROUTING).

Если вы имеете в виду, ограничивать входящий на роутер транзитный трафик - так его ограничивайте на eth1, уже для пользователей. Какая разница, если транзитные данные уже пришли на eth0, какой смысл тормозить их движение к eth1?

Получается, что "перескочив" роутер, я уже дальше ограничиваю _исходящую_ скорость от моей eth1 в локальную сеть. К какому же интерфейсу, какого типа дисциплину подключать (root, ingress)? Может подцеплять к той же eth1? Тогда какой фильтра добавить?

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

[gard]

А ну то есть, если например был маркированный пакет важного трафика, то просто ограничить пользователей, чтобы они не занимали ВЕСЬ канал? Я просто читаю, что по сути промаркированный важный трафик, например SSH нужно направлять в высокоприоритетный класс (скоростной), но как в данном случае, если я произвожу шейпинг на eth1?

То есть объясню по другому: в манах пишут например, что для выскокоприоритетного трафика (SSH например), маркированного в INPUT создается фильтр, который смотрит эти метки и направляет трафик в высокоприоритетный класс, а трафик обычного приоритета (HTTP, пользовательский) другим фильтром отправляется в нормальноприоритетный класс, потом еще есть классы, не важно сколько их.. я не пойму другое, к какому же интерфейсу подцеплять корневую дисциплину, которая могла бы шейпить трафик и для роутера и для клиентов локальной сети? Если это eth1, то на нее же пакеты попадают уже после принятия решения о маршрутизации по цепочке FORWARD, пакеты предназначенные роутеру через eth1 ведь не проходят? Если не eth1, то что же?

[danger08]

То есть объясню по другому: в манах пишут например, что для выскокоприоритетного трафика (SSH например), маркированного в INPUT создается фильтр, который смотрит эти метки и направляет трафик в высокоприоритетный класс, а трафик обычного приоритета (HTTP, пользовательский) другим фильтром отправляется в нормальноприоритетный класс,

Транзитный трафик просто не попадет в INPUT, и соответственно не перемаркируется. Через INPUT проходят только пакеты, предназначенные самому роутеру.

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

Давайте рассмотрим это более подробно:

а) Для самого роутера: входящий к роутеру (исходящий от провайдера к роутеру, как к клиенту) вы не сможете шейпить классами. Это не имеет смысла. Почему так, я думаю понятно: невозможно "заказать" прову при передаче данных, чтоб входящие на 22/tcp порт данные к роутеру шли по 128кбит(например), а входящие на 80/tcp порт к роутеру шли по 256кбит. Эти данные просто придут от провайдера к вам на роутер в общем порядке, и все Шейпинг может сделать у себя провайдер, чтоб вам данные по порту 22/tcp отдавались со 128кбит, а на 80/tcp с 256кбит. Сами вы здесь ничего изменить не можете, когда активируется правило шейпинга, данные уже у вас - они пришли.

б) Исходящие от роутера - вешается на интерфейс, к которому вы подключены к провайдеру (eth0, вроде). Маркировать пакеты именно от роутера (не транзитные от клиентов) можно по mangle в OUTPUT. Заметьте, если маркировать в mangle POSTROUTING, то будут маркироваться все пакеты на исходящем интерфейсе - и транзитные, и сгенерированные локально.

в) Входящие к клиентам вешаются на интерфейс локальной сети (eth1), здесь лучше всего маркировать, вроде, в mangle POSTROUTING (не исключены и другие варианты). С шейпингом здесь, я думаю, все понятно.

г) Исходящие от клиентов (и только от них, т.е. транзитный трафик) можно по mangle в PREROUTING или FORWARD. Классы шейпера при этом вешаются на на интерфейс, к которому вы подключены к провайдеру.

[gard]

Ну все, щас понял, сегодня еще перечитал кое что, тут Вы ответили. Скоро доделаю шейпер и покажу, правильно так то вроде пока делаю.
*****************
Вот читаю это: http://www.opennet.ru/docs/RUS/LARTC/LARTC...l.gz#x2755_html и делаю аналогично, там говорится о том, чтобы ограничивать исходящий от роутера трафик, дабы не создавать очередей в модеме. Трафик идет в интернет, фильтры работают по меткам, вот только метит он пакеты в цепочке PREROUTING.. Это как так?!? Разве не в OUTPUT/FORWARD или не в POSTROUTING?

[danger08]

Ну все, щас понял, сегодня еще перечитал кое что, тут Вы ответили. Скоро доделаю шейпер и покажу, правильно так то вроде пока делаю.
*****************
Вот читаю это: http://www.opennet.ru/docs/RUS/LARTC/LARTC...l.gz#x2755_html и делаю аналогично, там говорится о том, чтобы ограничивать исходящий от роутера трафик, дабы не создавать очередей в модеме. Трафик идет в интернет, фильтры работают по меткам, вот только метит он пакеты в цепочке PREROUTING.. Это как так?!? Разве не в OUTPUT/FORWARD или не в POSTROUTING?

Наверное, вы пропустили кое-что в статье, почитайте внимательно:

classid 1:12 htb rate 20kbit ceil ${CEIL}kbit prio 2

В этот класс помещаются пакеты, с установленным битом Maximize-Throughput в поле TOS, а так же иной трафик, который генерируется локальными процессами на маршрутизаторе, отправляемый в Интернет. Таким образом, все последующие классы будут иметь дело только с перенаправляемым трафиком.

немного ниже

Устанавим фильтры, которые будут выполнять классификацию пакетов, основываясь на метках iptables. Мне нравятся iptables за их чрезвычайную гибкость и за возможность подсчитывать количество пакетов, пропущенных тем или иным правилом. Добавим в сценарий следующие строки:

tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10
tc filter add dev eth0 parent 1:0 protocol ip prio 2 handle 2 fw classid 1:11
tc filter add dev eth0 parent 1:0 protocol ip prio 3 handle 3 fw classid 1:12
tc filter add dev eth0 parent 1:0 protocol ip prio 4 handle 4 fw classid 1:13
tc filter add dev eth0 parent 1:0 protocol ip prio 5 handle 5 fw classid 1:14
tc filter add dev eth0 parent 1:0 protocol ip prio 6 handle 6 fw classid 1:15

и еще ниже:

Нелишним будет добавить те же правила в цепочку OUTPUT, заменив имя цепочки PREROUTING на OUTPUT (s/PREROUTING/OUTPUT/). Тогда трафик, сгенерированный локальными процессами на маршрутизаторе, также будет классифицирован по категориям. Но, в отличие от вышеприведенных правил, в цепочке OUTPUT, я устанавливаю метку -j MARK --set-mark 0x3, таким образом трафик от маршрутизатора получает более высокий приоритет.

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

[gard]

В том и дело, что я то именно так понял. Поэтому не понимаю, зачем в статье автор исходящий трафик метит в PREROUTING. А как идет транзитный трафик из сети? Он разве попадает в PREROUTING??? Я то всегда думал, что он идет в FORWARD, затем в POSTROUTING. У себя сделал так: в iptables добавляю

Код: Выделить всё

$IPTABLES -t mangle -A OUTPUT -p tcp --sport 22 -j MARK --set-mark 0x1
$IPTABLES -t mangle -A OUTPUT -p ALL -j MARK --set-mark 0x3

Потом еще

Код: Выделить всё

$IPTABLES -t mangle -A POSTROUTING -p udp --dport 53 -j MARK --set-mark 0x1
#icmp маркировать не буду (задам явно протоколом в фильтре)
#$IPTABLES -t mangle -A POSTROUTING -p icmp -j MARK --set-mark 0x1
$IPTABLES -t mangle -A POSTROUTING -m tos --tos Minimize-Delay -j MARK --set-mark 0x2
$IPTABLES -t mangle -A POSTROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j MARK --set-mark 0x2
$IPTABLES -t mangle -A POSTROUTING -p tcp --sport 80 --dport 80 -j MARK --set-mark 0x2
$IPTABLES -t mangle -A POSTROUTING -m tos --tos Minimize-Cost -j MARK --set-mark 0x4
$IPTABLES -t mangle -A POSTROUTING -m tos --tos Maximize-Throughput -j MARK --set-mark 0x5

Далее у меня другой скрипт - шейпера. Посмотрите если несложно, правильно ли я сделал блок с ограничением исходящей скорости

Код: Выделить всё

#!/bin/bash
##########################################################################
DOWNLINK=896
UPLINK=512
EXT_DEV="ppp0"
IN_DEV="eth1"
LAN_IP_RANGE="192.168.1.0/24"
ALL_IP_RANGE="0.0.0.0/0"

##########################################################################
tc qdisc del dev $EXT_DEV root        2> /dev/null > /dev/null
tc qdisc del dev $EXT_DEV ingress     2> /dev/null > /dev/null
tc qdisc del dev $IN_DEV root        2> /dev/null > /dev/null
tc qdisc del dev $IN_DEV ingress     2> /dev/null > /dev/null

##########################################################################
#Входящий трафик - необходимо несколько уменьшить поступающий из интернета
#трафик в скорости, это предотвратит задержку пакетов в очереди у провайдера
#присоединяю входной ограничитель
tc qdisc add dev $EXT_DEV handle ffff: ingress
#и сбразываю все сподряд на черезчур большой входящей скорости скорости
tc filter add dev $EXT_DEV parent ffff: protocol ip prio 50 u32 match ip src $ALL_IP_RANGE flowid :1 police rate ${DOWNLINK}kbit burst 10k mpu 0 action drop/continue

##########################################################################
#Исходящий трафик тоже нужно ограничить, чтобы не создавать очередей в
#ADSL модеме (то есть мы создаем очереди у себя, до передачи пакетов модему)
#Установка корневой HTB, трафик по умолчанию идет в 1:20
tc qdisc add dev $EXT_DEV root handle 1: htb default 14
#Общий класс с полной шириной канала и 5 классов приоритизации
tc class add dev $EXT_DEV parent 1: classid 1:1 htb     rate ${UPLINK}kbit         ceil ${UPLINK}kbit
tc class add dev $EXT_DEV parent 1:1 classid 1:10 htb     rate ${UPLINK}kbit         ceil ${UPLINK}kbit      prio 0
tc class add dev $EXT_DEV parent 1:1 classid 1:11 htb     rate $[9*$UPLINK/10]kbit     ceil ${UPLINK}kbit      prio 1
tc class add dev $EXT_DEV parent 1:1 classid 1:12 htb     rate $[7*$UPLINK/10]kbit     ceil ${UPLINK}kbit     prio 2
tc class add dev $EXT_DEV parent 1:1 classid 1:13 htb     rate $[5*$UPLINK/10]kbit     ceil $[7*$UPLINK/10]kbit prio 3
tc class add dev $EXT_DEV parent 1:1 classid 1:14 htb     rate $[3*$UPLINK/10]kbit     ceil $[5*$UPLINK/10]kbit prio 4
tc class add dev $EXT_DEV parent 1:1 classid 1:15 htb     rate $[1*$UPLINK/10]kbit     ceil $[3*$UPLINK/10]kbit prio 5
#получают дисциплину Stochastic Fairness:
tc qdisc add dev $EXT_DEV parent 1:12 handle 120: sfq perturb 10
tc qdisc add dev $EXT_DEV parent 1:13 handle 130: sfq perturb 10
tc qdisc add dev $EXT_DEV parent 1:14 handle 140: sfq perturb 10
tc qdisc add dev $EXT_DEV parent 1:15 handle 150: sfq perturb 10

tc filter add dev $EXT_DEV parent 1: protocol ip prio 1 u32 match ip protocol 1 0xff flowid 1:10
tc filter add dev $EXT_DEV parent 1: protocol ip prio 2 handle 1 fw classid 1:10
tc filter add dev $EXT_DEV parent 1: protocol ip prio 3 handle 2 fw classid 1:11
tc filter add dev $EXT_DEV parent 1: protocol ip prio 4 handle 3 fw classid 1:12
tc filter add dev $EXT_DEV parent 1: protocol ip prio 6 handle 4 fw classid 1:13
tc filter add dev $EXT_DEV parent 1: protocol ip prio 7 handle 5 fw classid 1:14
tc filter add dev $EXT_DEV parent 1: protocol ip prio 9 handle 6 fw classid 1:15
#Для ноутбука
tc filter add dev $EXT_DEV parent 1: protocol ip prio 5 u32 match ip src 192.168.1.2 flowid 1:12
#Для всей локальной сетки
tc filter add dev $EXT_DEV parent 1: protocol ip prio 8 u32 match ip src $LAN_IP_RANGE flowid 1:14

##########################################################################
#Ограничение скорости для локальной сети
#Обрезаю исходящую от меня в локальную сеть скорость
tc qdisc add dev $IN_DEV root handle 1: htb default 12
tc class add dev $IN_DEV parent 1: classid 1:1 htb rate ${DOWNLINK}kbit ceil ${DOWNLINK}kbit
tc class add dev $IN_DEV parent 1:1 classid 1:11 htb rate 256kbit ceil 256kbit
tc class add dev $IN_DEV parent 1:1 classid 1:12 htb rate $[5*$DOWNLINK/10]kbit ceil ${DOWNLINK}kbit
tc qdisc add dev $IN_DEV parent 1:11 handle 11: sfq perturb 10
tc qdisc add dev $IN_DEV parent 1:12 handle 12: sfq perturb 10
tc filter add dev $IN_DEV parent 1:0 protocol ip prio 1 u32 match ip dst $LAN_IP_RANGE flowid 1:11

В блоке локальной сети 256 написано, потому что человек явно попросил, это пока временно.

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

[danger08]

В том и дело, что я то именно так понял. Поэтому не понимаю, зачем в статье автор исходящий трафик метит в PREROUTING. А как идет транзитный трафик из сети? Он разве попадает в PREROUTING??? Я то всегда думал, что он идет в FORWARD, затем в POSTROUTING.

Все в той же статье, посмотрите 15.10.2. Классификация пакетов, порядок прохождения пакетов.

Если фильтрам не задавать приоритеты,

Обычно, если используют приоритеты, то ставят их уже везде.
Иначе запутаетесь, что куда ушло; особенно если со временем добавлять новые правила.

Что дает установка приоритетов на фильтры, то что все пакеты обязаны пройти всю цепочку фильтров и уже потом решается их судьба или же просто фильтр с prio 1 будет применен к пакету раньше чем фильтр с prio 2 вне зависимости в каком порядке они были записаны?

Все решается значением приоритета, порядок в каком записаны правила (раньше/позже) значения не имеет. А если приоритеты одинаковы, тогда видимо да - порядок имеет значение.

[gard]

А для приоритетов на классы не ругается если пару=тройку одинаковых, а для фильтров вот ругается. Спасибо, сегодня еще доделаю. И все равно .. если пакет идет из локальной сети, то собственно как он может пройти PREROUTING... хотя, если учесть что для ЛЮБЫХ откуда угодно идущих пакетов роутер принимает решение о маршрутизации после PREROUTING, то выходит, что они туда попадают..
хмм...
Вы открыли мне глаза, значит они таки ВСЕ эти пакеты идут через PREROUTING, я с ходу то подумал "а как же DNAT" , но потом понял, то DNAT в моем случае применяется только к пакетам, идущим В локаьную сеть (-d $LAN_IP_RANGE -i $INET_IFACE ), то есть обратно правилу:
$IPTABLES -t nat -A POSTROUTING -s $LAN_IP_RANGE -o $INET_IFACE -j MASQUERADE

т.о. пакеты идущие в Инет из локальной сети: PREROUTING - FORWARD - POSTROUTING
пакеты от самого роутера: OUTPUT - POSTROUTING

Эти выводы сделал, внимательнее прочитав http://www.opennet.ru/docs/RUS/iptables/#DNATTARGET - когда пакет идет из локальной сети.

Я правильно предполагаю? А утилита tc iproute2 "обрабатывает" пакеты (шейпит) пока они идут по цепочкам? Если так, то умнее и вправду писать PREROUTING для мдущих из локальной сети и OUTPUT для идущих от роутера. Потому как если поставить метку в POSTROUTING, то после прохождения этой цепочки метка теряется? Еща раз: спасибо за терпение.

[danger08]

И все равно .. если пакет идет из локальной сети, то собственно как он может пройти PREROUTING... хотя, если учесть что для ЛЮБЫХ откуда угодно идущих пакетов роутер принимает решение о маршрутизации после PREROUTING, то выходит, что они туда попадают..

Я же говорю, смотрите в той статье раздел Классификация пакетов, там все расписано - какой трафик какие цепочки проходит (очень понятная схемка).
Потом еще, в той статье, что вы указали, есть последовательность прохождения пакетов по цепочкам, в зависимости от типа трафика.

значит они таки ВСЕ эти пакеты идут через PREROUTING, я с ходу то подумал "а как же DNAT" , но потом понял, то DNAT в моем случае применяется только к пакетам, идущим В локаьную сеть

В соответствии с вашим NAT-правилом.

(-d $LAN_IP_RANGE -i $INET_IFACE ), то есть обратно правилу:
$IPTABLES -t nat -A POSTROUTING -s $LAN_IP_RANGE -o $INET_IFACE -j MASQUERADE

Скажем так, это не совсем обратное правило (и DNAT/SNAT вовсе не антиподы), просто в данном случае так выглядит

т.о. пакеты идущие в Инет из локальной сети: PREROUTING - FORWARD - POSTROUTING
пакеты от самого роутера: OUTPUT - POSTROUTING

Да (более подробно, смотрите в схемах прохождения пакета по цепочкам - двух вышеприведенных статей хватает).

Я правильно предполагаю? А утилита tc iproute2 "обрабатывает" пакеты (шейпит) пока они идут по цепочкам? Если так, то умнее и вправду писать PREROUTING для мдущих из локальной сети и OUTPUT для идущих от роутера. Потому как если поставить метку в POSTROUTING, то после прохождения этой цепочки метка теряется?

По идее, шейпинг применяется при физическом выходе "на интерфейс", когда в дело вступают правила шейпера на интерфейсе.
при прохождении пакетов по цепочкам (пока нет выхода наружу) правила шейпера "спят" - к ним еще не поступило данных на обработку.

Маркировки по PREROUTING / OUTPUT разносятся с той целью, чтобы разделить маркировку локального и транзитного трафика (потому, что локальный на PREROUTING не идет, а транзитный через OUTPUT не проходит). Если разницы нет, кто генерировал трафик - сам роутер или транзит - то можно маркировать в POSTROUTING - там будет маркирован трафик всех видов.

Насчет того, что "маркировка теряется": пакет может иметь только одну маркировку, и при повторном маркировании метка пакета просто перезаписывается новой.

[gard]

Ну все, я полностью счастлив, все понятно объяснили, Спасибо большое! Все таки возможности Линукса по части управления трафиком воистину впечатляют. А я поставлю MARK [SOLVED] на тему. =)