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

От переводчика (А.К.): SLA (от англ. Service Level Agreement) означает "Соглашение об Уровне Обслуживания" – основной документ, регламентирующий взаимоотношения между ИТ-компанией и заказчиком.

Сделать это можно несколькими способами. Прежде всего следует упомянуть, что Apache поддерживает подобную функциональность в виде модулей, но мы продемонстрируем как добиться этого средствами операционной системы. Эти строки взяты из примера, представленного Джамалом Хади (Jamal Hadi).

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

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

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

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

[Интернет] ---<E3, T3...>--- [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". Делается это следующим образом:

# iptables –A PREROUTING –t mangle –p tcp –sport telnet \

 -j TOS –set-tos Minimize-Delay

# iptables –A PREROUTING –t mangle –p tcp –sport ftp \

 -j TOS –set-tos Minimize-Delay

# iptables –A PREROUTING –t mangle –p tcp –sport ftp-data \

 -j TOS –set-tos Maximize-Throughput

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

# iptables –A OUTPUT –t mangle –p tcp –dport telnet \

 -j TOS –set-tos Minimize-Delay

# iptables –A OUTPUT –t mangle –p tcp –dport ftp \

 -j TOS –set-tos Minimize-Delay

# iptables –A OUTPUT –t mangle –p tcp –dport ftp-data \

 -j TOS –set-tos Maximize-Throughput

Этот раздел написал Рэм Нарул (Ram Narula), из "Internet for Education" (Таиланд).

Прозрачное проксирование — это обычное перенаправление серверу squid трафика, отправляемого на порт 80 (web).

Существует 3 общеизвестных способа такого перенаправления:

Вы можете настроить шлюз таким образом, что он будет перенапрвлять все пакеты, адресованные на порт 80, сереверу squid

НО

Это увеличит нагрузку на шлюз. Кроме того, некоторые коммерческие роутеры не поддерживают такую возможность.

Свичи выполняют такое перенаправление без особых проблем.

НО

Стоимость этого оборудования очень высока и может быть сопоставима с ценой связки "обычный роутер" + "Linux-сервер"

Вы можете отправить ВЕСЬ трафик через кэш-сервер.

НО

Это довольно рисковано, поскольку squid довольно значительно нагружает CPU, что может привести к снижению производительности сети. Кроме того, squid может "рухнуть" и тогда никто из сети не сможет выйти в Интернет.

Эта методика предполагает установку меток на пакеты, с портом назначения равным числу 80, и дальнейшая маршрутизация помеченных пакетов, с помощью iproute2, на squid.

|----------------|

|   Реализация   |

|----------------|

Используемые адреса

10.0.0.1 naret (NetFilter)

10.0.0.2 silom (Squid)

10.0.0.3 donmuang (Router, соединенный с Интернет)

10.0.0.4 kaosarn (некий сервер в сети)

10.0.0.5 RAS

10.0.0.0/24 main network

10.0.0.0/19 total network

|---------------|

|Структура сети |

|---------------|

Internet

|

donmuang

|

------------hub/switch----------

|        |             |       |

naret   silom        kaosarn  RAS etc. 

Прежде всего — весь трафик должен идти через naret, для этого на всех компьютерах пропишем его в качестве шлюза по-умолчанию. Исключение составляет silom, для которого шлюз по-умолчанию — donmuang (в противном случае web-трафик зациклится).

(на всех компьютерах в моей сети был прописан шлюз по-умолчанию – 10.0.0.1, который ранее принадлежал donmuang , поэтому я изменил IP-адрес у donmuang на 10.0.0.3, а серверу naret присвоил адрес 10.0.0.1)

 Настройте прокси-сервер squid на silom. Убедитесь, что он поддерживает прозрачное проксирование. Обычно прокси-серверу, для приема запросов от пользователей, назначают порт 3128, поэтому весь трафик, отправляемый на порт 80 будет перенаправлен на порт 3128. С помощью ipchains это делают следующие правила:

silom# ipchains –N allow1

silom# ipchains –A allow1 –p TCP –s 10.0.0.0/19 –d 0/0 80 –j REDIRECT 3128

silom# ipchains –I input –j allow1

iptables:

silom# iptables –t nat –A PREROUTING –i eth0 –p tcp –dport 80 –j REDIRECT –to-port 3128

За информацией по настройке сервера squid, обращайтесь на http://squid.nlanr.net/.

Убедитесь, что на этом сервере разрешен форвардинг, и заданный по умолчанию шлюз для него — donmuang (НЕ naret !).

1. Пометить пакеты, с портом назначения 80, числовой меткой 2.

naret# iptables –A PREROUTING –i eth0 –t mangle –p tcp –dport 80 \

 –j MARK –set-mark 2

2. Настроить маршрутизацию так, чтобы помеченные пакеты отправлялись на silom.

naret# echo 202 www.out >> /etc/iproute2/rt_tables

naret# ip rule add fwmark 2 table www.out

naret# ip route add default via 10.0.0.2 dev eth0 table www.out

naret# ip route flush cache

Если donmuang и naret находятся в одной подсети, то naret не должен выдавать ICMP-сообщения о перенаправлении. Запрет можно наложить так:

naret# echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

naret# echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects

naret# echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects

На этом настройку можно считать завершенной. Проверим конфигурацию

Для naret:

naret# iptables -t mangle -L

Chain PREROUTING (policy ACCEPT)

target     prot opt source               destination        

MARK       tcp  --  anywhere             anywhere           tcp dpt:www MARK set 0x2

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination        

naret# ip rule ls

0:      from all lookup local

32765:  from all fwmark        2 lookup www.out

32766:  from all lookup main

32767:  from all lookup default

naret# ip route list table www.out

default via 203.114.224.8 dev eth0

naret# ip route  

10.0.0.1 dev eth0  scope link

10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.1

127.0.0.0/8 dev lo  scope link

default via 10.0.0.3 dev eth0

|-------|

|-КОНЕЦ-|

|-------|

|-----------------------------------------|

|         Схема движения пакетов          |

|-----------------------------------------|

ИНТЕРНЕТ

/\

||

\/

---------------------donmuang------------------------

/\                                      /\         ||

||                                      ||         ||

||                                      \/         ||

naret                                  silom       ||

*destination port 80 ================>(cache)      ||

/\                                      ||         ||

||                                      \/         \/

\\===================================kaosarn, RAS, и пр. 

Обратите внимание, в данном случае сеть получилась асимметричной, т.е. добавился один лишний переход для исходящих пакетов.

Ниже приводится путь, проделываемый пакетами в/из Интернет для компьютера kaosarn.

Для web/http трафика:

kaosarn http request->naret->silom->donmuang->internet

http replies from Internet->donmuang->silom->kaosarn

Для прочего трафика:

kaosarn outgoing data->naret->donmuang->internet

incoming data from Internet->donmuang->kaosarn

Общеизвестно, что скорость передачи данных возрастает с увеличением размера пакета. Это вполне естесственно, ведь для каждого пакета в потоке принимается решение о выборе маршрута. К примеру, файл, размером в 1 мегабайт, будет передан быстрее, если он будет разбит на 700 пакетов (при максимальном размере пакета), а не на 4000.

Однако, не все сегменты Интернет могут передавать пакеты, с максимальной полезной нагрузкой в 1460 байт. Поэтому необходимо найти такой размер, который будет максимально возможным для заданного маршрута.

Процесс поиска такого размера называется 'Path MTU Discovery' (Поиск Максимального Размера Пакета для выбранного Пути), где MTU означает 'Maximum Transfer Unit' (Максимальный Размер Блока передачи данных).

Когда на маршрутизатор поступает пакет, который не может быть передан по выбранному маршруту целиком (без фрагментации) И у него установлен флаг "Don't Fragment" (Не фрагментировать), то в ответ отправляется ICMP-сообщение о том, что пакет был сброшен из-за невозможности "протолкнуть" его по выбранному маршруту. Компьютер, выполнивший посылку, начинает последовательно уменьшать размер пакетов до тех пор, пока они не смогут быть переданы по выбранному маршруту.

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

В результате таких действий процесс поиска оптимального размера пакета работает все хуже и хуже, а на некоторых маршрутизаторах вообще не работает, что в свою очередь порождает сеансы TCP/IP с весьма странным поведением, которые "умирают" спустя некоторое время.

Хотя у меня нет никаких доказательств, но я знаю по крайней мере два сайта, с которыми наблюдается подобная проблема и перед обоими стоит Alteon Acedirectors — возможно кто-то имеет более богатый опыт и сможет подсказать как и почему это происходит.

Если вы столкнетесь с подобной проблемой, то можно посоветовать отключить 'Path MTU Discovery' и установить MTU вручную. Koos van den Hout пишет:

У меня возникла следующая проблема: для арендованного мною канала, работающего через ppp, на скорости 33.6К, я установил величину MTU/MRU, равную 296. Это дает мне достаточно приемлемое время отклика.

Со моей стороны установлен роутер (с маскарадингом), работающий под управлением Linux.

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

После этого возникла масса проблем с авторизацией в irc. В процессе длительных поисков я установил, что само соединение проходит и даже показывается системой как 'connected', но я не получал motd от irc (motd — от англ. Message of The Day, которое демонстрируется после успешной авторизации, прим. перев.). Кроме того, помятуя о проблеме, связанной с MTU, я определил, что проблема исчезала только в том случае, когда MTU устанавливался равным 296. А так как серверы irc блокируют весь трафик, который напрямую не связан с их работой, то в числе блокируемых оказался и ICMP.

Мне удалось убедить администратора WEB-сервера в истинных причинах возникновения проблем, но администратор IRC-сервера отказался устранять их.

Таким образом, передо мной встала необходимость уменьшить MTU для внешнего трафика и оставить нормальное значение для локального.

Решение:

ip route add default via 10.0.0.1 mtu 296

(10.0.0.1 — шлюз по умолчанию, внутренний адрес маршрутизатора с маскарадингом)

Вообще, можно запретить 'PMTU Discovery' путем настройки специфических маршрутов. Например, если проблемы наблюдаются только с определенной подсетью, то это должно помочь:

ip route add 195.96.96.0/24 via 10.0.0.1 mtu 1000

Как уже говорилось выше, Path MTU Discovery не работает в Интернет должным образом. Если вам известны факты существования сегментов в вашей сети, где размер MTU ограничен, то вы уже не можете полагаться на безотказную работу Path MTU Discovery.

Однако, помимо MTU, есть еще один способ ограничения размера пакета — это, так называемый MSS (Maximum Segment Size — Максимальный Размер Сегмента). MSS — это поле в заголовке TCP-пакета SYN.

С недавних пор, ядра Linux и некоторые драйверы PPPoE, стали поддерживать такую особенность, как 'clamp the MSS' (ограничение размера MSS).

В этом есть свои плюсы и минусы. С одной стороны, устанавливая MSS, вы недвусмысленно извещаете удаленную сторону о том, что размер пакета не должен превышать заданную величину. Причем для этого не требуется передачи ICMP-сообщений.

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

Чтобы иметь возможность манипулировать размером сегмента, у вас должны быть установлены iptables, не ниже 1.2.1a и ядро linux, не ниже 2.4.3. Основная команда iptables:

# iptables –A FORWARD –p tcp –tcp-flags SYN,RST SYN –j TCPMSS –clamp-mss-to-pmtu

Она рассчитает правильный MSS для вашего соединения. Если вы достаточно уверены в себе и в своих знаниях, можете попробовать нечто подобное:

# iptables –A FORWARD –p tcp –tcp-flags SYN,RST SYN –j TCPMSS –set-mss 128

Это правило устанавливает MSS равным 128. Очень полезно, если вы наблюдаете разрывы при передаче голосовых данных, когда поток небольших пакетов VoIP прерывается "огромными" http-пакетами.

Note

Этот сценарий претерпел существенные изменения. Ранее он предназначался только для Linux-клиентов в вашей сети! Теперь же он может влиять на Windows и Mac машины

При разработке сценария преследовались следующие цели:

Обеспечить низкую задержку для интерактивного трафика.

Это означает, что перекачка больших объемов данных не должна отрицательно сказываться на работе через ssh или telnet. Это очень важно, поскольку в период интерактивного взаимодействия с удаленной системой даже незначительные задержки, скажем в 200 мсек, вызывают у пользователя чувство раздражения.

Обеспечить приемлемую скорость web-серфинга

Даже учитывая тот факт, что http-трафик сам по себе является довольно объемным, он не должен подвергаться значительным задержкам.

Обеспечить достаточно высокую скорость передачи больших объемов данных.

Довольно часто возникает ситуация, когда исходящий трафик практически полностью блокирует входящий.

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

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

Поставщикам услуг Интернет хорошо известно, что пользователей в основном интересует скорость, с которой они могут получать данные. Но помимо пропускной способности канала, на скорость скачивания очень сильно влияют факты потери пакетов. Увеличение очередей способствует уменьшению потерь, что в свою очередь приводит к увеличению скорости скачивания. Поэтому поставщики услуг, как правило, создают очереди очень большого объема.

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

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

Итак, что же дальше? Поскольку мы лишены возможности управлять этими очередями, то напрашивается очевидное решение — они должны быть перемещены на наш Linux-маршрутизатор. К счастью это возможно. Для этого необходимо:

Ограничить скорость исходящего трафика.

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

Ограничить скорость входящего трафика.

Это немного сложнее, поскольку действительно отсутствует возможность влияния на скорость поступления данных. Тем не менее, можно попробовать сбрасывать пакеты, если скорость поступления слишком высока, это заставит TCP/IP снизить скорость передачи до желаемого уровня. Поскольку в данном вопросе чрезмерное усердие может только навредить, то необходимо предусмотреть величину возможного превышения на коротких отрезках времени.

При выполнении этих условий, входящая очередь будет ликвидирована полностью (за исключением коротких пиков), и появляется возможность управления исходящей очередью, используя всю мощь, которую предоставляет операционная система Linux.

После этого остается обеспечить первоочередную передачу интерактивного трафика. А для того, чтобы входящий трафик не блокировался исходящим, необходимо так же обеспечить первоочередную передачу ACK-пакетов. При наличии объемного трафика в обоих направлениях, возникают значительные задержки, поэтому входящие ACK-пакеты не должны проигрывать в конкурентной борьбе с исходящим трафиком.

После выполнения необходимых настроек, мы получили следующие результаты на ADSL соединении в Нидерландах:

Базовое время ожидания отклика:

туда-обратно мин/ср/макс = 14.4/17.1/21.7 мсек

Во время скачивания, без формирователя трафика:

туда-обратно мин/ср/макс = 560.9/573.6/586.4 мсек

Во время отправки большого объема, без формирователя трафика:

туда-обратно мин/ср/макс = 2041.4/2332.1/2427.6 мсек

С формирователем трафика, при отправке большого файла на скорости 220 Кбит/сек:

round-trip min/avg/max = 15.7/51.8/79.9 мсек

С формирователем трафика, при скачивании на скорости 850 Кбит/сек:

туда-обратно мин/ср/макс = 20.4/46.9/74.0 мсек

При наличии исходящего трафика, скорость входящего достигает ~80% от максимально возможного значения. Скорость исходящего трафика колеблется около 90%. При этом время ожидания подскакивает до 850 мсек, причина пока не выяснена.

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

Ниже приводятся две версии сценария формирователя трафика. Одна версия построена на базе HTB, разработанной Девиком (Devik), другая -- на базе CBQ, которая, в отличие от HTB, включена в состав ядра Linux. Оба сценария проверены и дают прекрасные результаты.

Может работать практически с любой версией ядра. В данной реализации, внутри CBQ qdisc размещаются две SFQ (Stochastic Fairness Queues), что даст возможность равноправного сосуществования нескольких потоков данных.

Входящий трафик формируется с помощью tc-фильтров, содержащих Token Bucket Filter.

Вы можете улучшить сценарий за счет добавления ключевых слов bounded в строках, начинающихся со слов tc class add .. classid 1:20. Если вы предполагаете уменьшать MTU, не забудьте уменьшить и значения allot и avpkt!

#!/bin/bash

# Формирователь трафика для домашнего соединения с Интернет

#

#

# Установите следующие параметры так, чтобы они были немного меньше фактических

# Единицы измерения -- килобиты

DOWNLINK=800

UPLINK=220

DEV=ppp0

# очистка входящей и исходящей qdisc

tc qdisc del dev $DEV root 2> /dev/null > /dev/null

tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null

###### исходящий трафик

# установка корневой CBQ

tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit

# ограничить общую исходящую скорость величиной $UPLINK -- это предотвратит

# появление огромных очередей в DSL модеме,

# которые отрицательно сказываются на величине задержки:

# базовый класс

tc class add dev $DEV parent 1: classid 1:1 cbq rate ${UPLINK}kbit \

 allot 1500 prio 5 bounded isolated

# высокоприоритетный (интерактивный) класс 1:10:

tc class add dev $DEV parent 1:1 classid 1:10 cbq rate ${UPLINK}kbit \

 allot 1600 prio 1 avpkt 1000

# класс по-умолчанию 1:20 -- получает немного меньший объем трафика

# и имеет более низкий приоритет:

tc class add dev $DEV parent 1:1 classid 1:20 cbq rate $[9*$UPLINK/10]kbit \

 allot 1600 prio 2 avpkt 1000

# оба получают дисциплину Stochastic Fairness:

tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10

tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10

# определения фильтров

# TOS = Minimum-Delay (ssh, НО НЕ scp) -- в 1:10:

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

 match ip tos 0x10 0xff flowid 1:10

# ICMP (ip protocol 1) -- в интерактивный класс 1:10

# так мы сможем удивить своих друзей:

tc filter add dev $DEV parent 1:0 protocol ip prio 11 u32 \

 match ip protocol 1 0xff flowid 1:10

# Поднять скорость входящего трафика, при наличии исходящего -- передать ACK-пакеты

# в интерактивный класс:

tc filter add dev $DEV parent 1: protocol ip prio 12 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:10

# остальной трафик не является интерактивным поэтому передаем его в 1:20

tc filter add dev $DEV parent 1: protocol ip prio 13 u32 \

 match ip dst 0.0.0.0/0 flowid 1:20

########## входящий трафик #############

# необходимо несколько уменьшить скорость поступления входящего трафика,

# это предотвратит задержку пакетов в очередях у поставщика услуг.

# Поставщики имеют обыкновение увеличивать размеры очередей,

# поэтому, экспериментальным путем подберите требуемые значения,

# при которых скачивание будет происходить с максимальной скоростью.

#

# присоединить входной ограничитель:

tc qdisc add dev $DEV handle ffff: ingress

# сбрасывать все подряд (0.0.0.0/0), что приходит со слишком большой скоростью.

tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \

 0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

Если вы собираетесь использовать этот сценарий совместно с ppp — скопируйте его в /etc/ppp/ip-up.d.

Если последние две строки в сценарии порождают сообщения об ошибке — обновите версию tc!

Следующий вариант сценария достигает поставленных целей за счет использования замечательных особенностей HTB (см. раздел Hierarchical Token Bucket). Требует наложения "заплаты" на ядро!

#!/bin/bash

# Формирователь трафика для домашнего соединения с Интернет

#

#

# Установите следующие параметры так, чтобы они были немного меньше фактических

# Единицы измерения -- килобиты

DOWNLINK=800

UPLINK=220

DEV=ppp0

# очистка входящей и исходящей qdisc

tc qdisc del dev $DEV root    2> /dev/null > /dev/null

tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null

###### исходящий трафик

# установка корневой HTB, отправить трафик по-умолчанию в 1:20:

tc qdisc add dev $DEV root handle 1: htb default 20

# ограничить общую исходящую скорость величиной $UPLINK -- это предотвратит

# появление огромных очередей в DSL модеме,

# которые отрицательно сказываются на величине задержки:

tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6k

# высокоприоритетный (интерактивный) класс 1:10:

tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \

   burst 6k prio 1

# класс по-умолчанию 1:20 -- получает немного меньший объем трафика

# и имеет более низкий приоритет:

tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[9*$UPLINK/10]kbit \

   burst 6k prio 2

# оба получают дисциплину Stochastic Fairness:

tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10

tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10

# TOS = Minimum-Delay (ssh, НО НЕ scp) -- в 1:10:

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

      match ip tos 0x10 0xff  flowid 1:10

# ICMP (ip protocol 1) -- в интерактивный класс 1:10

# так мы сможем удивить своих друзей:

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

match ip protocol 1 0xff flowid 1:10

# Поднять скорость входящего трафика, при наличии исходящего -- передать ACK-пакеты

# в интерактивный класс:

tc filter add dev $DEV parent 1: 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:10

# остальной трафик не является интерактивным поэтому он попадает в 1:20

########## входящий трафик #############

# необходимо несколько уменьшить скорость поступления входящего трафика,

# это предотвратит задержку пакетов в очередях у поставщика услуг.

# Поставщики имеют обыкновение увеличивать размеры очередей,

# поэтому, экспериментальным путем подберите требуемые значения,

# при которых скачивание будет происходить с максимальной скоростью.

#

# присоединить входной ограничитель:

tc qdisc add dev $DEV handle ffff: ingress

# сбрасывать все подряд (0.0.0.0/0), что приходит со слишком большой скоростью.

tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \

   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

Если вы собираетесь использовать этот сценарий совместно с ppp — скопируйте его в /etc/ppp/ip-up.d.

Если последние две строки в сценарии порождают сообщения об ошибке — обновите версию tc!

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

Эти три строки сделают все что вам нужно:

tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit

tc class add dev $DEV parent 1: classid 1:1 cbq rate 512kbit \

 allot 1500 prio 5 bounded isolated

tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \

 match ip dst 195.96.96.97 flowid 1:1

Первая строка — назначает базовую дисциплину на заданный интерфейс и сообщает ядру, что пропускная способность интерфейса составляет 10 Мбит/сек. Если вы установите неверное значение, то особого вреда не будет, однако, всегда стремитесь устанавливать верные значения, это повысит точность вычислений.

Вторая строка создает класс с полосой пропускания 512 Кбит/сек. Подробное описание CBQ содержит раздел Дисциплины обработки очередей для управления пропускной способностью.

Последняя строка говорит о том, какой трафик должен формироваться классом, определенным выше. Трафик, не подпадающий под заданное в фильтре условие, НЕ ОГРАНИЧИВАЕТСЯ! Более сложные примеры назначения условий (подсети, порт отправителя, порт адресата), вы найдете в разделе Наиболее употребимые способы фильтрации.

Если вы внесли какие-либо изменения в сценарий и желаете перезапустить его — предварительно запустите команду tc qdisc del dev $DEV root, чтобы очистить существующую конфигурацию.

Сценарий может быть немного улучшен, за счет добавления в конец дополнительной строки tc qdisc add dev $DEV parent 1:1 sfq perturb 10. За подробным описанием обращайтесь к разделу Stochastic Fairness Queueing.

Меня зовут Педро Ларрой (Pedro Larroy) <piotr%member.fsf.org>. Здесь я расскажу об общих принципах настройки соединения локальной сети, в которой имеется большое число пользователей, к Интернет через маршрутизатор, работающий под управлением Linux. Маршрутизатор имеет реальный IP-адрес и производит Трансляцию Сетевых Адресов (NAT). Я живу в университетском общежитии, где проложена локальная сеть на 198 пользователей. Эта сеть соединена с Интернет через маршрутизатор, который я администрирую. Пользователи очень интенсивно работают в пиринговых сетях, что требует соответствующего управления трафиком. Надеюсь, что этот пример будет интересен читателям lartc.

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

Ядро Linux 2.4.18 или выше

На ядро нужно наложить заплату, для поддержки HTB.

iproute

Убедитесь, что tc поддерживает htb. Скомпилированная версия распространяется вместе с HTB.

iptables

Для начала создадим несколько дисциплин (qdiscs), которые будут обслуживать трафик. Первой создается htb qdisc с 6-ю классами и различными приоритетами. Каждому классу назначена определенная пропускная способность, но при этом они могут задействовать неиспользуемую пропускную способность, если она не занята другими классами. Напомню, что классы с более высоким приоритетом (т.е. с более низким числом prio) будут получать "излишек" канала первыми. Подключение к Интернет осуществляется через модем ADSL, с пропускной способностью для входящего трафика 2 Мбит/сек, исходящего – 300 Кбит/сек. Я ограничиваю исходящую пропускную способность величиной в 240 Кбит/сек по той простой причине, что это максимальное значение, при котором время ожидания отклика остается минимальным. Величина этот параметра может быть определена экспериментально, путем наблюдения за изменением времени отклика при изменении величины пропускной способности.

Для начала, присвойте переменной CEIL величину, составляющую 75% от общей пропускной способности для исходящего трафика. Там, где я использую eth0 — назначьте свой интерфейс, который "смотрит" в Интернет. Сценарий (на языке командной оболочки), выполняющий настройку, начинается со следующих строк:

CEIL=240

tc qdisc add dev eth0 root handle 1: htb default 15

tc class add dev eth0 parent 1: classid 1:1 htb rate ${CEIL}kbit ceil ${CEIL}kbit

tc class add dev eth0 parent 1:1 classid 1:10 htb rate 80kbit ceil 80kbit prio 0

tc class add dev eth0 parent 1:1 classid 1:11 htb rate 80kbit ceil ${CEIL}kbit prio 1

tc class add dev eth0 parent 1:1 classid 1:12 htb rate 20kbit ceil ${CEIL}kbit prio 2

tc class add dev eth0 parent 1:1 classid 1:13 htb rate 20kbit ceil ${CEIL}kbit prio 2

tc class add dev eth0 parent 1:1 classid 1:14 htb rate 10kbit ceil ${CEIL}kbit prio 3

tc class add dev eth0 parent 1:1 classid 1:15 htb rate 30kbit ceil ${CEIL}kbit prio 3

tc qdisc add dev eth0 parent 1:12 handle 120: sfq perturb 10

tc qdisc add dev eth0 parent 1:13 handle 130: sfq perturb 10

tc qdisc add dev eth0 parent 1:14 handle 140: sfq perturb 10

tc qdisc add dev eth0 parent 1:15 handle 150: sfq perturb 10

Эти строки создают одноярусное дерево HTB:

+---------+

| root 1: |

+---------+

     |

+---------------------------------------+

| class 1:1                             |

+---------------------------------------+

  |      |      |      |      |      |     

+----+ +----+ +----+ +----+ +----+ +----+

|1:10| |1:11| |1:12| |1:13| |1:14| |1:15|

+----+ +----+ +----+ +----+ +----+ +----+

classid 1:10 htb rate 80kbit ceil 80kbit prio 0

Это класс с наивысшим приоритетом. Пакеты, попадающие в этот класс, будут иметь самую низкую задержку и получат избыток канала в первую очередь. Сюда будет направляться интерактивный трафик: ssh, telnet, dns, quake3, irc, а так же пакеты с установленным флагом SYN.

classid 1:11 htb rate 80kbit ceil ${CEIL}kbit prio 1

Это первый класс, через который будет проходить довольно объемный трафик. В моем случае – это трафик от локального WEB-сервера и запросы к внешним WEB-серверам, исходящий порт 80 и порт назначения 80, соответственно.

classid 1:12 htb rate 20kbit ceil ${CEIL}kbit prio 2

В этот класс помещаются пакеты, с установленным битом Maximize-Throughput в поле TOS, а так же иной трафик, который генерируется локальными процессами на маршрутизаторе, отправляемый в Интернет. Таким образом, все последующие классы будут иметь дело только с перенаправляемым трафиком.

classid 1:13 htb rate 20kbit ceil ${CEIL}kbit prio 2

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

classid 1:14 htb rate 10kbit ceil ${CEIL}kbit prio 3

Этот класс обслуживает почтовый трафик (SMTP, pop3…) и пакеты, с установленным битом Minimize-Cost в поле TOS.

classid 1:15 htb rate 30kbit ceil ${CEIL}kbit prio 3

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

Мы создали различные классы обработки трафика, но классификация пока отсутствует, поэтому, к настоящему моменту, весь трафик пойдет через класс 1:15 (который назначен классом по умолчанию: tc qdisc add dev eth0 root handle 1: htb default 15). Теперь самое главное — нужно распределить трафик по имеющимся классам.

Устанавим фильтры, которые будут выполнять классификацию пакетов, основываясь на метках iptables. Мне нравятся iptables за их чрезвычайную гибкость и за возможность подсчитывать количество пакетов, пропущенных тем или иным правилом. Добавим в сценарий следующие строки:

tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10

tc filter add dev eth0 parent 1:0 protocol ip prio 2 handle 2 fw classid 1:11

tc filter add dev eth0 parent 1:0 protocol ip prio 3 handle 3 fw classid 1:12

tc filter add dev eth0 parent 1:0 protocol ip prio 4 handle 4 fw classid 1:13

tc filter add dev eth0 parent 1:0 protocol ip prio 5 handle 5 fw classid 1:14

tc filter add dev eth0 parent 1:0 protocol ip prio 6 handle 6 fw classid 1:15

Здесь задаются соответствия между специфическими значениями FWMARK (handle x fw) и классами (classid x:x). Теперь рассмотрим процесс установки меток на пакеты.

Для начала необходимо разобраться с тем, как движутся пакеты через iptables:

        +------------+   принятие     +---------+               +-------------+

Вход ---| PREROUTING |--- решения о --| FORWARD |-------+-------| POSTROUTING |- Выход

        +------------+  маршрутизации +---------+       |       +-------------+   

                             |                          |

                        +-------+                    +--------+  

                        | INPUT |-Локальные процессы-| OUTPUT |

                        +-------+                    +--------+  

Далее я буду исходить из предположения, что всем таблицам назначена политика по-умолчанию -P ACCEPT. Наша локальная сеть относится к классу b, с адресами 172.17.0.0/16. Реальный IP-адрес — 212.170.21.172

Добавим правило iptables, которое будет выполнять snat, что позволит пользователям локальной сети общаться с внешним миром, и разрешим форвардинг пакетов:

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables –t nat –A POSTROUTING –s 172.17.0.0/255.255.0.0 –o eth0 –j SNAT –to-source 212.170.21.172

Проверим, что пакеты уходят через класс 1:15:

tc –s class show dev eth0

Добавим в цепочку PREROUTING, таблицы mangle, правила для установки меток на пакеты:

iptables –t mangle –A PREROUTING –p icmp –j MARK –set-mark 0x1

iptables –t mangle –A PREROUTING –p icmp –j RETURN

Теперь вы должны наблюдать увеличение значения счетчика пакетов в классе 1:10, при попытке ping-ануть из локальной сети какой-нибудь сайт в Интернете.

tc-s класс показывают dev eth0

Действие -j RETURN предотвращает движение пакетов по всем правилам. Поэтому все ICMP-пакеты будут проходить только это правило. Добавим еще ряд правил, которые будут изменять биты в поле TOS:

iptables –t mangle –A PREROUTING –m tos –tos Minimize-Delay –j MARK –set-mark 0x1

iptables –t mangle –A PREROUTING –m tos –tos Minimize-Delay –j RETURN

iptables –t mangle –A PREROUTING –m tos –tos Minimize-Cost –j MARK –set-mark 0x5

iptables –t mangle –A PREROUTING –m tos –tos Minimize-Cost –j RETURN

iptables –t mangle –A PREROUTING –m tos –tos Maximize-Throughput –j MARK –set-mark 0x6

iptables –t mangle –A PREROUTING –m tos –tos Maximize-Throughput –j RETURN

Поднимем приоритет для ssh-пакетов:

iptables –t mangle –A PREROUTING –p tcp –m tcp –sport 22 –j MARK –set-mark 0x1

iptables –t mangle –A PREROUTING –p tcp –m tcp –sport 22 –j RETURN

а так же для пакетов, с которых начинается TCP-соединение, т.е. SYN-пакетов:

iptables –t mangle –I PREROUTING –p tcp –m tcp –tcp-flags SYN,RST,ACK SYN –j MARK –set-mark 0x1

iptables –t mangle –I PREROUTING –p tcp –m tcp –tcp-flags SYN,RST,ACK SYN –j RETURN

И так далее. После того, как в цепочку PREROUTING, таблицы mangle, будут внесены все необходимые правила, закончим ее правилом:

iptables –t mangle –A PREROUTING –j MARK –set-mark 0x6

Это заключительное правило отправит оставшиеся немаркированные пакеты в класс 1:15. Фактически, это правило можно опустить, так как класс 1:15 был задан по-умолчанию, но тем не менее, я оставляю его, чтобы сохранить единство настроек и кроме того, иногда бывает полезно увидеть счетчик пакетов для этого правила.

Нелишним будет добавить те же правила в цепочку OUTPUT, заменив имя цепочки PREROUTING на OUTPUT (s/PREROUTING/OUTPUT/). Тогда трафик, сгенерированный локальными процессами на маршрутизаторе, также будет классифицирован по категориям. Но, в отличие от вышеприведенных правил, в цепочке OUTPUT, я устанавливаю метку -j MARK –set-mark 0x3, таким образом трафик от маршрутизатора получает более высокий приоритет.

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

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

tc qdisc add dev eth0 parent 1:13 handle 130: sfq perturb 10

tc qdisc add dev eth0 parent 1:14 handle 140: sfq perturb 10

tc qdisc add dev eth0 parent 1:15 handle 150: sfq perturb 10

Уверен, что можно найти множество способов, чтобы произвести настройку маршрутизатора во время загрузки. Для себя я создал скрипт /etc/init.d/packetfilter, который принимает команды [start | stop | stop-tables | start-tables | reload-tables]. Он конфигурирует дисциплины (qdiscs) и загружает необходимые модули ядра. Этот же сценарий загружает правила iptables из файла /etc/network/iptables-rules, которые предварительно могут быть сохранены утилитой iptables-save и восстановлены — iptables-restore.