Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO
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
