Как уже говорилось в разделе Классовые дисциплины обработки очередей, для того, чтобы определить в какую из подочередей направить пакет, используются фильтры-классификаторы.

Ниже приводится неполный список доступных классификаторов:

fw

Решение принимается на основе маркера пакета, установленного брандмауэром (например — iptables). Наиболее простой классификатор, который можно рекомендовать в том случае, если вам не хочется изучать синтаксис tc. За дополнительной информацией обращайтесь к главе 9.

u32

Решение принимается на основе значений полей в заголовке пакета (например, исходящий IP-адрес и т.п.).

route

Решение принимается на основе маршрута, по которому движется пакет.

rsvp, rsvp6

Маршрутизация пакетов производится на базе RSVP. Применимо только в том случае, если управление сетью полностью находится в ваших руках. В Интернет RSVP не поддерживается.

tcindex

Используется в DSMARK qdisc, см. соответствующий раздел.

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

Классификаторы, как правило, принимают некоторое количество аргументов. Перечислим их здесь, для удобства.

protocol

Протокол, принимаемый классификатором. Как правило вы будете принимать только IP-трафик.

parent

Существующий класс, к которому должен быть присоединен данный классификатор.

prio

Приоритет классификатора. Чем меньше число — тем выше приоритет.

handle

Назначение и смысл аргумента зависит от контекста использования.

Во всех следующих разделах мы будем исходить из условия, что формируется трафик, идущий к хосту HostA, что корневой класс сконфигурирован как 1:, а класс, которому посылается выбранный трафик – как 1:1.

Фильтр U32 наиболее гибкий из доступных в текущей конфигурации. Он целиком основан на хеш-таблицах, которые повышают устойчивость фильтра при значительном количестве правил фильтрации.

В простейшем виде, фильтр U32 — это набор записей, каждая из которых состоит из двух полей: селектора и действия. Селекторы, описанные ниже, проверяют обрабатываемый IP-пакет до тех пор, пока не будет встречено первое совпадение, после чего выполняется соответствующее селектору действие. Самый простой тип действия — перенаправление пакета в определенный класс.

Для конфигурирования фильтра используется команда tc filter, состоящая из трех частей: определение фильтра, селектор и действие. Определение фильтра может быть записано как:

tc filter add dev IF [ protocol PROTO ]

                     [ (preference|priority) PRIO ]

                     [ parent CBQ ]

Поле protocol описывает обслуживаемый протокол. Здесь мы будем обсуждать исключительно протокол IP. Поле preference (в качестве синонима можно использовать priority) описывает приоритет определяемого фильтра, что позволяет задавать несколько фильтров (списков правил) с различными приоритетами. Вообще, правила обслуживаются в порядке добавления в список, в случае с приоритетами — первыми обслуживаются правила, имеющие наивысший приоритет (чем меньше число, тем выше приоритет). Поле parent определяет вершину дерева CBQ (например 10:1), к которой должен быть присоединен данный фильтр.

Описаные выше опции применимы ко всем фильтрам, а не только к U32.

Селектор U32 содержит определение шаблона, который будет сопоставляться с обрабатываемым пакетом. Если быть более точным, он определяет — какие биты в заголовке пакета будут проверяться и не более того, но, не смотря на свою простоту, это очень мощный и гибкий метод. Рассмотрим примеры, взятые из реально работающего и достаточно сложного фильтра:

# tc filter add dev eth0 protocol ip parent 1:0 pref 10 u32 \

 match u32 00100000 00ff0000 at 0 flowid 1:10

Оставим пока первую строку в покое, эти параметры описывают хеш-таблицы фильтра, и сконцентрируем свое внимание на строке селектора, которая содержит ключевое слово match. Этот селектор будет отбирать пакеты, в IP-заголовках которых второй байт будет содержать число 0x10 (0010). Как вы уже наверняка догадались, 00ff — это маска, которая точно определяет проверяемые биты. Ключевое слово at означает, что поиск совпадения должен начинаться с указанного смещения (в байтах), в данном случае — с начала пакета. Переведя все это, на человеческий язык, можно сказать, что пакет будет соответствовать селектору, если в его поле TOS (Type of Service) будет установлен бит Minimize-Delay (минимальная задержка). Проанализируем еще одно правило:

# tc filter add dev eth0 protocol ip parent 1:0 pref 10 u32 \

 match u32 00000016 0000ffff at nexthdr+0 flowid 1:10

Параметр nexthdr означает переход к следующему заголовку в IP-пакете, т.е. к заголовку протокола более высокого уровня. Опять же, в данной ситуации поиск будет вестись с начала заголовка. Анализу будет подвергнуто второе 32-х битное слово в заголовке. В протоколах TCP и UDP это поле содержит порт назначения. Число записывается в формате big-endian, т.е. первым указывается старший байт. Таким образом мы получаем номер порта назначения — 0x0016, или 22 (в десятичной форме). В случае протокола TCP, этот порт соответствует службе SSH. Надеюсь вы понимаете, что данное соответствие бессмысленно обсуждать вне контекста применения, поэтому отложим эту дискуссию на более позднее время.

Уловив все, что говорилось выше, вы без труда поймете смысл следующего селектора: match c0a80100 ffffff00 at 16. Данный селектор будет пытаться найти 3-х байтовую последовательность в IP-заголовке, начиная с 17-го байта, отсчитываемого от начала заголовка, что соответствует любому адресу назначения в сети 192.168.1.0/24.

Селекторы общего назначения задают шаблон, маску и смещение. Используя эти селекторы вы сможете выполнять проверку практически любого, отдельно взятого бита в заголовке IP (или протокола более высокого уровня). При написании и чтении они более сложны, чем селекторы специального назначения, которые будут обсуждаться в следующем разделе. Синтаксис селекторов общего назначения:

match [ u32 | u16 | u8 ] PATTERN MASK [ at OFFSET | nexthdr+OFFSET]

Ключевое слово u32, или u16, или u8 указывает длину шаблона в битах. PATTERN и MASK в обязательном порядке должны иметь длину, указанную в предыдущем ключевом слове. Параметр OFFSET задает смещение от начала заголовка в байтах. Если присутствует ключевое слово nexthdr+, то смещение начинает отсчитываться от начала заголовка протокола более высокого уровня.

Приведем несколько примеров:

Этим селектором будут отобраны пакеты, у которых "время жизни" (поле TTL) равно 64. Поле TTL находится в 9-м (в 8-м, если считать с нуля) байте IP-заголовка.

# tc filter add dev ppp14 parent 1:0 prio 10 u32 \

 match u8 64 0xff at 8 \

 flowid 1:4

Следующие селекторы отберут TCP-пакеты, в которых установлен бит ACK:

# tc filter add dev ppp14 parent 1:0 prio 10 u32 \

 match ip protocol 6 0xff \

 match u8 0x10 0xff at nexthdr+13 \

 flowid 1:3

Отбор ACK-пакетов, длина которых меньше 64 байт:

## отбор ack-пакетов более сложным способом,

## IP protocol 6,

## Длина IP-заголовка 0x5 (32-х битных слов),

## Общая длина 0x34 (ACK + 12 байт опций TCP)

## TCP ACK (бит 5, смещение 33)

# tc filter add dev ppp14 parent 1:0 protocol ip prio 10 u32 \

            match ip protocol 6 0xff \

            match u8 0x05 0x0f at 0 \

            match u16 0x0000 0xffc0 at 2 \

            match u8 0x10 0xff at 33 \

            flowid 1:3

Это правило отберет пакеты TCP, с установленным битом ACK, и не несущие в себе данных. Это яркий пример использования двух селекторов. Конечный результат будет получен логическим умножением (операция "И") результатов каждого из селекторов. Если вы посмотрите на диаграмму TCP-заголовка, то увидите, что флаг ACK — это младший бит старшей тетрады (0x10) 14-го байта в TCP-заголовке (at nexthdr+13). Что касается второго селектора, то если бы мы хотели усложнить себе жизнь, можно было бы записать match u8 0x06 0xff at 9, вместо специального селектора protocol tcp (здесь число 6 — это номер протокола TCP), в 10-м байте IP-заголовка. С другой стороны, в этом примере мы не использовали специальный селектор, для отбора по биту ACK, просто потому, что такого селектора не существует.

Фильтр, приведенный ниже, является модификацией предыдущего примера. На этот раз не производится проверка длины IP-заголовка. Вы спросите — почему? Потому, что фильтр, приведенный выше, работает только на 32-х битных системах.

tc filter add dev ppp14 parent 1:0 protocol ip prio 10 u32 \

 match ip protocol 6 0xff \

 match u8 0x10 0xff at nexthdr+13 \

 match u16 0x0000 0xffc0 at 2 \

 flowid 1:3

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

FIXME: таблица находится в отдельном файле selector.html.

FIXME: Она по-прежнему остается на польском языке :-(

FIXME: надо перевести в формат sgml.

Несколько примеров:

# tc filter add dev ppp0 parent 1:0 prio 10 u32 \

 match ip tos 0x10 0xff \

 flowid 1:4

FIXME: шаблон tcp dport, в примере ниже, не работает.

Правило выше отберет пакеты, в которых поле TOS имеет значение 0x10. Поле TOS — это второй байт в IP-заголовке, причем это однобайтовое поле (8 бит). Таким образом, эквивалентный селектор можно было бы записать как: match u8 0x10 0xff at 1. Это наталкивает на мысль, что селекторы специального назначения, внутри фильтров U32, преобразуются в селекторы общего назначения и в таком виде сохраняются в памяти ядра. Отсюда следует другое заключение — селекторы tcp и udp суть есть одно и то же. По этой причине вы не сможете использовать единичный селектор match tcp dport 53 0xffff, для отбора TCP-пакетов, направляющихся на 53-й порт. Этим селектором будут отобраны как TCP-пакеты, так и UDP-пакеты. Вы обязательно должны добавлять селектор типа протокола:

# tc filter add dev ppp0 parent 1:0 prio 10 u32 \

 match tcp dport 53 0xffff \

 match ip protocol 0x6 0xff \

 flowid 1:2

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

# tc filter add dev eth1 parent 1:0 protocol ip prio 100 route

В данном случае, к узлу 1:0 добавлен классификатор с приоритетом 100. Когда пакет достигнет этого узла (поскольку он является корневым, то это произойдет немедленно), то классификатор проанализирует таблицу маршрутизации. Если совпадение будет подтверждено, то пакет будет передан данному классу с приоритетом, равным 100. Однако, для того, чтобы все это заработало, необходимо добавить соответствующую запись в таблицу маршрутизации:

Тут вся хитрость состоит в том, чтобы определить некую 'область' (realm), основываясь на адресе отправителя или получателя. Примерно таким образом:

# ip route add Host/Network via Gateway dev Device realm RealmNumber

Для примера зададим номер 'области', равным 10, для нашей сети 192.168.10.0.

 # ip route add 192.168.10.0/24 via 192.168.10.1 dev eth1 realm 10

В фильтрах, основанных на классификаторе route, мы можем использовать номер 'области' (realm) для представления сетей или отдельных узлов сети.

# tc filter add dev eth1 parent 1:0 protocol ip prio 100 \

 route to 10 classid 1:10

Под действие данного правила попадут пакеты, направляющиеся в сеть 192.168.10.0

Фильтры данного типа можно строить и на основе адреса отправителя. Рассмотрим пример, когда к маршрутизатору, под управлением Linux, через интерфейс eth2 подключена сеть.

# ip route add 192.168.2.0/24 dev eth2 realm 2

# tc filter add dev eth1 parent 1:0 protocol ip prio 100 \

 route from 2 classid 1:2

Этот фильтр говорит о том, что пакеты из подсети 192.168.2.0 (область 2) будут отнесены к идентификатору класса 1:2.

Более сложные системы управления трафиком можно строить на основе фильтров, которые зависят от пропускной способности и загруженности канала. Вы можете объявить фильтр, который не будет срабатывать, если загрузка канала превысила некоторую величину или наоборот, срабатывать только в том случае, если пропускная способность превысила заданное значение.

Так, если вы решили ограничить 5 Мбитный канал величиной в 4 Мбит/сек, вы можете вообще прекратить прием пакетов, если загруженность канала превысит 4 Мбит/сек, либо отбросить 1 Мбит/сек, а 4 Мбит/сек передать заданному классу.

При превышении заданного порога вы можете отбрасывать "лишние" пакеты, переклассифицировать их или передать другим фильтрам.

Существует две основных возможности ограничения. Если вы собрали ядро с "функциями оценки" (estimators), то оно сможет более или менее точно измерять объем трафика, переданного тому или иному фильтру. Устройство функции оценки достаточно несложное — 25 раз в секунду подсчитывается объем переданных данных, на основе которого вычисляется загруженность канала.

Другой способ — Token Bucket Filter, который реализуется в пределах вашего фильтра. Это типичный шейпер, который может использоваться, если вам нужно просто ограничить полосу пропускания по какому-нибудь критерию.

Тут все очень просто и имеется всего один параметр: avrate. Либо объем трафика остается ниже avrate и фильтр классифицирует его как сконфигурированный classid, либо, в случае превышения заданной границы, выполняется указанное действие, которое по-умолчанию выполняет переклассификацию.

Для оценки загруженности канала, ядро использует экспоненциальное взвешенное смещенное среднее значение, которое менее чувствительно к коротким пикам.

Используются следующие параметры:

• burst/buffer/maxburst

• mtu/minburst

• mpu

• rate

Которые ведут себя идентично описанным в разделе Token Bucket Filter. Обратите внимание, если вы установите mtu слишком низким, то входящий трафик будет подавлен, в то время как исходящий TBF qdisc передаст с более низкой скоростью.

Еще одно важное отличие такого фильтра – он может только либо пропустить пакет, либо отбросить. Он не может задержать пакет на какое-то время.

Если правило "решит", что произошло превышение заданного предела, то оно выполнит соответствующее действие. Имеются четыре вида действий:

continue

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

drop

Очень жестокое действие, которое просто отказывает "в праве на жизнь" трафику, объем которого превысил заданную величину. Часто используется во входных фильтрах и имеет ограниченное применение. Например, представим, что имеется сервер имен, который не в состоянии работать при нагрузке выше чем 5Мбит/сек, в этом случае можно построить входной фильтр, который ограничит входящий трафик для нашего сервера.

Pass/OK

Пропустить трафик. Может использоваться для того, чтобы отключить сложный фильтр, оставив его на месте.

reclassify

Действие, заданное по-умолчанию. Наиболее часто сводится к переклассификации в Best Effort (в данном контексте фразу "Best Effort" следует понимать как — "лучшее из оставшегося". прим. перев. )

Единственный, известный нам, реальный пример приведен в разделе Защита от SYN flood.

Ограничение входящего icmp-трафика до 2 Кбит. При превышении предела — пакеты отбросить.

tc filter add dev $DEV parent ffff: \

 protocol ip prio 20 \

 u32 match ip protocol 1 0xff \

 police rate 2kbit buffer 10k drop \

 flowid :1

Ограничить размер пакетов (т.е. все пакеты, имеющие размер более чем 84 байта, будут сброшены)

tc filter add dev $DEV parent ffff: \

 protocol ip prio 20 \

 u32 match tos 0 0 \

 police mtu 84 drop \

 flowid :1

Этот метод может использоваться для полного подавления icmp-трафика:

tc filter add dev $DEV parent ffff: \

 protocol ip prio 20 \

 u32 match ip protocol 1 0xff \

 police mtu 1 drop \

 flowid :1

Фактически означает: "отбросить все icmp-пакеты, размер которых превышает 1 байт". Чисто теоретически, пакеты могут иметь размер в 1 байт, но на практике вы с ними никогда не встретитесь.

Если у вас возникла потребность в большом количестве правил, например, когда у вас много клиентов, причем все имеют различные спецификации QoS (от англ. Quality of Service — Качество Обслуживания), то может сложиться ситуация, когда ядро будет тратить недопустимо большое количество времени на поиск подходящего правила в наборе.

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

Поиск шел бы гораздо быстрее, если бы было 256 цепочек, по четыре правила в каждой, при условии, что вы сможете направить пакет в нужную цепочку.

В этом случае вам поможет хеширование. Представим, что у нас имеется сеть из 1024 компьютеров, с IP-адресами от 1.2.0.0 до 1.2.3.255, причем каждый компьютер может быть отнесен к одному из 3-х предопределенных классов качества обслуживания, например 'lite', 'regular' и 'premium'. Решение "в лоб" дает 1024 правила:

# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \

 1.2.0.0 classid 1:1

# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \

 1.2.0.1 classid 1:1

…

# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \

 1.2.3.254 classid 1:3

# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \

 1.2.3.255 classid 1:2

Чтобы уменьшить число проверок, можно использовать последний байт IP-адреса в качестве хеш-ключа. В результате получается 256 таблиц, первая из которых:

# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \

 1.2.0.0 classid 1:1

# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \

 1.2.1.0 classid 1:1

# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \

 1.2.2.0 classid 1:3

# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \

 1.2.3.0 classid 1:2

Следующая:

# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \

 1.2.0.1 classid 1:1

…

Таким образом каждый пакет должен пройти не более 4-х проверок.

Реальная конфигурация намного сложнее, но она стоит того. Первым создается корневой фильтр, а затем — таблица на 256 записей:

# tc filter add dev eth1 parent 1:0 prio 5 protocol ip u32

# tc filter add dev eth1 parent 1:0 prio 5 handle 2: protocol ip u32 divisor 256

После этого добавляются правила в созданные таблицы:

# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 2:7b: \

 match ip src 1.2.0.123 flowid 1:1

# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 2:7b: \

 match ip src 1.2.1.123 flowid 1:2

# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 2:7b: \

 match ip src 1.2.3.123 flowid 1:3

# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 2:7b: \

 match ip src 1.2.4.123 flowid 1:2

Это записи в таблице с номером 123, которые выполняют проверку на принадлежность адресам 1.2.0.123, 1.2.1.123, 1.2.2.123, 1.2.3.123, и в случае совпадения передают пакеты в классы 1:1, 1:2, 1:3 и 1:2 соответственно. Обратите внимание на то, как задается номер таблицы, шестнадцатеричное число 0x7b соответствует числу 123, в десятичном представлении.

И наконец создается хеш-фильтр, который перенаправит трафик в нужную таблицу:

# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 800:: \

 match ip src 1.2.0.0/16 \

 hashkey mask 0x000000ff at 12 \

 link 2:

А теперь поясним некоторые моменты. Заданной по-умолчанию хеш-таблице присвоен идентификатор 800:: и вся фильтрация начинается отсюда. Затем выбирается IP-адрес отправителя, который находится в 12, 13, 14 и 15 байтах в IP-заголовке и указывается, что нас интересует только последний байт. После чего трафик передается в хеш-таблицу 2:, которая была создана ранее.

Все это выглядит довольно сложным, но действительно работает и дает ошеломляющую производительность. Обратите внимание, этот пример может быть оптимизирован еще больше и сведен к идеальному случаю, когда каждая цепочка содержит 1 фильтр!

Дело в том, что в ядре Linux, модель маршрутизации и адресации IPv4 (замечательные особенности которой описывает этот HOWTO) строилась на основе Базы Политик Маршрутизации (RPDB — Routing Policy Database). К сожалению, модель IPv6 в Linux была реализована совершенно иным образом. Хотя они используют совместно некоторые средства, но основа основ — RPDB, не принимает участия в адресации и маршрутизации IPv6.

Надеюсь, что такое положение дел наверняка изменится, надо только подождать.

FIXME: : Ждем ваших замечаний и предложений по этому поводу, может кто-то работает над этим?

ip6tables имеет возможность пометить пакеты:

# ip6tables –A PREROUTING –i eth0 –t mangle –p tcp –j MARK –mark 1

Но тем не менее, это крайне слабое утешение, поскольку пакет пройдет мимо RPDB.

Для передачи по сетям IPv4, трафик IPv6 обычно инкапсулируется в SIT–туннель. За дополнительной информацией по созданию такого рода туннелей, обращайтесь к разделу Тоннелирование IPv6. Это позволяет выполнять фильтрацию IPv4-пакетов, которые, в качестве полезной нагрузки, несут пакеты IPv6.

Следующий фильтр отберет все пакеты IPv6, инкапсулированные в IPv4:

# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \

 match ip protocol 41 0xff flowid 42:42

Продолжим в том же духе. Предположим, что пакеты IPv6 передаются по сети IPv4, и не имеют набора опций. Тогда, для обнаружения пакетов ICMPv6 можно использовать следующий фильтр. 0x3a (58) — Next-Header для ICMPv6.

# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \

 match ip protocol 41 0xff \

 match u8 0x05 0x0f at 0 \

 match u8 0x3a 0xff at 26 \

 flowid 42:42

Фильтрация по адресу получателя потребует от нас дополнительных усилий. Например, следующий фильтр отбирает пакеты с адресом получателя 3ffe:202c:ffff:32:230:4fff:fe08:358d:

# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \

 match ip protocol 41 0xff \

 match u8 0x05 0x0f at 0 \

 match u8 0x3f 0xff at 44 \

 match u8 0xfe 0xff at 45 \

 match u8 0x20 0xff at 46 \

 match u8 0x2c 0xff at 47 \

 match u8 0xff 0xff at 48 \

 match u8 0xff 0xff at 49 \

 match u8 0x00 0xff at 50 \

 match u8 0x32 0xff at 51 \

 match u8 0x02 0xff at 52 \

 match u8 0x30 0xff at 53 \

 match u8 0x4f 0xff at 54 \

 match u8 0xff 0xff at 55 \

 match u8 0xfe 0xff at 56 \

 match u8 0x08 0xff at 57 \

 match u8 0x35 0xff at 58 \

 match u8 0x8d 0xff at 59 \

 flowid 10:13

Эту же методику можно использовать для отбора по адресу подсети, например 2001:

# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \

 match ip protocol 41 0xff \

 match u8 0x05 0x0f at 0 \

 match u8 0x20 0xff at 28 \

 match u8 0x01 0xff at 29 \

 flowid 10:13