Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO Страница 20

12.3.2. Действия в случае превышения ограничения.

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

continue

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

drop

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

Pass/OK

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

reclassify

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

12.3.3. Примеры.

Единственный, известный нам, реальный пример приведен в разделе Защита от 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 байт, но на практике вы с ними никогда не встретитесь.

12.4. Хеш-фильтры.

Если у вас возникла потребность в большом количестве правил, например, когда у вас много клиентов, причем все имеют различные спецификации 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 фильтр!

12.5. Фильтрация трафика IPv6.

12.5.1. Почему не работают tc-фильтры в IPv6?

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

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

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

12.5.2. Маркировка пакетов IPv6 средствами ip6tables.

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

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

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

12.5.3. Использование селектора u32 для пакетов IPv6.

Для передачи по сетям 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 \