Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO

Допустим, что у нас есть два клиента, которые арендуют некоторую долю нашего канала под http, ftp и потоковое audio. Первый клиент арендует полосу в 2 Мбита, второй – 5 Мбит. Для начала назначим нашим клиентам виртуальные IP-адреса на нашем сервере:

# ip address add 188.177.166.1 dev eth0

# ip address add 188.177.166.2 dev eth0

Решение проблемы о том, как назначить правильные IP-адреса различным службам, оставляем за вами. Практически все популярные демоны поддерживают такую возможность.

Присоединяем CBQ qdisc к eth0:

# tc qdisc add dev eth0 root handle 1: cbq bandwidth 10Mbit cell 8 avpkt 1000 \

mpu 64

Создаем классы клиентов:

# tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 10Mbit rate \

2MBit avpkt 1000 prio 5 bounded isolated allot 1514 weight 1 maxburst 21

# tc class add dev eth0 parent 1:0 classid 1:2 cbq bandwidth 10Mbit rate \

5Mbit avpkt 1000 prio 5 bounded isolated allot 1514 weight 1 maxburst 21

И добавляем фильтры к классам:

##FIXME: Для чего нужна первая строка, что она делает? Каково назначение "делителя" (divisor)?:

##FIXME: Делитель имеет отношение к хеш-таблице и номеру пула

## (bucket) – ahu

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

# tc filter add dev eth0 parent 1:0 prio 5 u32 match ip src 188.177.166.1

flowid 1:1

# tc filter add dev eth0 parent 1:0 prio 5 u32 match ip src 188.177.166.2

flowid 1:2

FIXME: Почему нет token bucket filter?

Пример взят из документации к iproute, написанной Алексеем и адаптирован для совместной работы с netfilter. Если этот пример заинтересует вас, измените числовые значения на наиболее подходящие для вашей системы.

Этот сценарий был написан для защиты отдельного хоста, а не сети. Учитывайте это обстоятельство.

Для его работы желательно иметь самую последнюю версию iproute2.

#! /bin/sh –x

#

# демонстрация возможностей по управлению входящим (ingress) трафиком

# здесь приводится пример ограничения пропускной способности для входящих SYN-пакетов

# Может оказаться полезным для защиты от TCP-SYN атак.

# #пути к различным утилитам; #укажите правильные значения.

#

TC=/sbin/tc

IP=/sbin/ip

IPTABLES=/sbin/iptables

INDEV=eth2

#

# пометить все SYN-пакеты, пришедшие через $INDEV, числом 1

############################################################

$iptables –A PREROUTING –i $INDEV –t mangle –p tcp –syn \

–j MARK –set-mark 1

############################################################

#

# установить ingress qdisc на входящий интерфейс

############################################################

$TC qdisc add dev $INDEV handle ffff: ingress

############################################################

#

#

# SYN-пакет имеет размер 40 байт (320 бит), отсюда – три пакета

# имеют размер 960 бит (примерно 1 Кбит); ограничим скорость поступления

# 3-мя пакетами в секунду ( точнее – 1 Кбит/сек )

############################################################

$TC filter add dev

$INDEV parent ffff: protocol ip prio 50 handle 1 fw \

police rate 1kbit burst 40 mtu 9k drop flowid :1

############################################################

# echo "– qdisc parameters Ingress –"

$TC qdisc ls dev $INDEV

echo "– Class parameters Ingress –"

$TC class ls dev $INDEV

echo "– filter parameters Ingress –"

$TC filter ls dev $INDEV parent ffff:

#Удаление ingress qdisc

#$TC qdisc del $INDEV ingress

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

Основная задача – настроить фильтры таким образом, чтобы пакеты, с исходящими адресами, не принадлежащими вашей сети, не смогли бы покинуть ее. Это предотвратит возможность отправки всякой "гадости" в Интернет.

Прежде, чем приступить к делу, нарисуем схему подключения локальной сети к Интернет:

[Интернет] ------ [Linux router] --- [Офис]

eth1 eth0

Зададим начальные условия:

# tc qdisc add dev eth0 root handle 10: cbq bandwidth 10Mbit avpkt 1000

# tc class add dev eth0 parent 10:0 classid 10:1 cbq bandwidth 10Mbit rate \

10Mbit allot 1514 prio 5 maxburst 20 avpkt 1000

Если у вас более высокоскоростное подключение — измените эти цифры соответствующим образом. Теперь необходимо определиться с "шириной" канала для ICMP-трафика. Чтобы найти типовое значение для вашей сети, можно воспользоваться утилитой tcpdump, запустив ее с перенаправлением вывода в файл. Затем, с помощью этого файла, вы сможете подсчитать количество ICMP-пакетов, отправляемых вашей сетью в единицу времени.

Если вариант подсчета экспериментальным путем вам не подходит, попробуйте ограничиться 10% общей пропускной способности. Построим наш класс:

# tc class add dev eth0 parent 10:1 classid 10:100 cbq bandwidth 10Mbit rate \

100Kbit allot 1514 weight 800Kbit prio 5 maxburst 20 avpkt 250 \

bounded

Он ограничивает пропускную способность канала величиной 100 Кбит/сек. А теперь подключим к нему фильтр для ICMP-пакетов:

# tc filter add dev eth0 parent 10:0 protocol ip prio 100 u32 match ip protocol 1 0xFF flowid 10:100

Если канал практически полностью забит отправляемыми/получаемыми данными, то работа через telnetили sshстановится практически невозможной. Как было бы здорово, если бы интерактивный трафик не блокировался другими пакетами. Linux поможет вам в этом!

Как и прежде, необходимо настроить обслуживание трафика на обоих концах канала. Наилучший вариант — когда с обоих концов установлена операционная система Linux, однако UNIX тоже может выполнять управление приоритетами трафика.

Стандартный планировщик pfifo_fast имеет три различных "полосы". В первую очередь обслуживается полоса 0, а затем полосы 1 и 2. Поэтому, необходимо весь интерактивный трафик отправить в полосу 0!

Отталкиваясь от "Ipchais HOWTO" (уже довольно устаревшего):

В IP-заголовке имеется 4 редко используемых бита — TOS (Type of Service — Тип Обслуживания). Они задают способ обслуживания пакета: "Minimum Delay" (минимальная задержка), "Maximum Throughput" (максимальная пропускная способность), "Maximum Reliability" (максимальная надежность) и "Minimum Cost" (минимальная стоимость канала). Причем одновременно может быть установлен только один из этих битов. Роб ван Ньюкерк (Rob van Nieuwkerk), автор кода ipchains TOS-mangling, дает следующее пояснение:

Наиболее важным для меня, является флаг "Minimum Delay" (минимальная задержка). Я включаю его в пакетах интерактивного трафика на моем роутере, работающем под управлением Linux. Я подключен к сети через модем 33.6. Linux "раскидывает" пакеты по 3-м очередям. Таким образом я получаю вполне приемлемую скорость обслуживания интерактивного трафика при большой загрузке канала.

Как правило, флаг "Minimum Delay" устанавливается в пакетах для telnetи ftp-control, а в пакетах ftp-data– "maximum throughput". Делается это следующим образом: