Фильтр, который сразу отправляет пакет в 12:2, мог бы быть сразу присоединен к 1:1, но в этом случае пакет минует дополнительные проверки, которые могли бы быть сделаны в 12:.
Вы не можете выполнять фильтрацию в обратном порядке, только вниз! Кроме того, все фильтры в HTB должны присоединяться к корню!
Повторюсь еще раз. Пакеты могут фильтроваться (классифицироваться) только в направлении сверху-вниз.
9.6.1. Ряд простых примеров фильтрации.
Для начала продемонстрируем самый обычный случай, который, к счастью, достаточно прост. Допустим, что у нас имеется дисциплина PRIO, с дескриптором 10:, которая содержит три класса и нам нужно весь трафик, отправляемый на 22 порт и с 80 порта, отдать в самую высокоприоритетную полосу, тогда набор фильтров мог бы выглядеть так:
# tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \
ip dport 22 0xffff flowid 10:1
# tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \
ip sport 80 0xffff flowid 10:1
# tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2
О чем говорят эти строки? Они говорят: "Присоединить к eth0, к узлу 10:, фильтр u32, с приоритетом 1, который отбирает пакеты, направляемые на порт 22, и передает их в полосу 10:1". Аналогичное высказывание делается относительно пакетов, отправленных с порта 80. И последняя строка говорит о том, что весь неклассифицированный трафик должен отправляться в полосу 10:2.
Вы обязательно должны указывать имя сетевого интерфейса, поскольку каждый из них имеет свое уникальное пространство имен дескрипторов.
Отбор пакетов по IP-адресам выполняется аналогичным образом:
# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 \
match ip dst 4.3.2.1/32 flowid 10:1
# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 \
match ip src 1.2.3.4/32 flowid 10:1
# tc filter add dev eth0 protocol ip parent 10: prio 2 \
flowid 10:2
В этой конфигурации весь трафик, идущий на хост 4.3.2.1 и с хоста 1.2.3.4, ставится в очередь с наивысшим приоритетом.
Допускается смешивать проверку IP-адреса и номера порта:
# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 match ip src 4.3.2.1/32 \
match ip sport 80 0xffff flowid 10:1
9.6.2. Наиболее употребимые способы фильтрации.
В большинстве случаев, команды фильтрации начинаются так:
# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ..
Это так называемый селектор u32, который может выполнять отбор пакетов по любой его части.
По IP-адресу
По исходящему адресу: match ip src 1.2.3.0/24, по адресу назначения: match ip dst 4.3.2.0/24. Чтобы отобрать пакеты, отправляемые с/на единственный узел сети нужно указать сетевую маску /32 или вообще опустить ее.
По номеру порта
Исходящий порт: match ip sport 80 0xffff, порт назначения: match ip dport 80 0xffff.
По типу протокола, из семейства IP (tcp, udp, icmp, gre, ipsec)
Номера протоколов вы найдете у себя, в файле /etc/protocols . Например, отбор ICMP-пакетов (номер протокола icmp – 1) можно выполнить командой match ip protocol 1 0xff.
По метке пакета
Пакеты могут маркироваться либо средствами ipchains, либо средствами iptables. Это бывает полезно, например, для наложения ограничений на трафик, который следует с интерфейса eth1 на интерфейс eth0:
# tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 6 fw flowid 1:1
Обратите внимание — этот фильтр не является селектором u32!
Установить метку можно следующим образом:
# iptables –A PREROUTING –t mangle –i eth0 –j MARK -–set-mark 6 В
данном случае число 6 выбрано произвольным образом.
Если вы не хотите с головой погружаться в синтаксис tc, тогда просто пользуйтесь возможностями iptablesи запомните принцип отбора по метке.
По полю TOS
Отбор трафика с минимальной задержкой:
# tc filter add dev ppp0 parent 1:0 protocol ip prio 10 u32 \
match ip tos 0x10 0xff \
flowid 1:4
Дополнительные сведения о фильтрации трафика вы найдете в главе Расширенная фильтрация.
9.7. Intermediate queueing device.
Устройство IMQ не является дисциплиной обработки очереди, но тесно с ними связано. В Linux, дисциплины обработки очередей присоединяются к сетевым устройствам и все, что помещается в очередь устройства, попадает сначала в очередь дисциплины обработки очереди. Из-за этого подхода существуют два ограничения:
1. Ограничение пропускной способности полноценно работает только для исходящего трафика (дисциплина обработки входящего трафика существует, но ее возможности мизерны по сравнению с полноклассовыми дисциплинами).
2. Дисциплина обработки очереди обслуживает трафик только для одного интерфейса, нет никакой возможности задать глобальные ограничения.
Читать дальше