Прикладная дебианавтика

19.10.2007

Есть vpn-сервер. К vpn подключается несколько клиентов. Подключения в течение рабочего времени висят практически постоянно. На том же самом канале, к которому подцеплен vpn-сервер висит десяток пользователей. Всё бы ничего, но один из этих пользователей иногда делает рассылки на несколько сотен адресов (он не спамер, адреса получены вполне легально из опросников клиентов). Мзт-сервер так же является маршрутизатором (что логично) и почтовым сервером (что не очень логично, но так уж получилось). Для пользователя отправка происходит в один момент. Но после этого вся ширина канала забивается smtp-соединениями. Это почтовый сервер спешит доставить почту. Разумеется, по vpn пользователи работать какое-то время не могут.

Было решено, что соединениям по vpn нужно отдать приоритет. Способов сделать это существует несолько, но т.к. я давным-давно нашел для себя прекрасный продукт под названием Shorewall, то эту задачу я стал решать через него. Обзор Shorewall я здесь делать не буду. Только похвастаюсь, что до того, как он появился я использовал для конфигурации iptables самописные скрипты созданные по идеологии схожей с Shorewall’овской. Ну и разумеется попроще они были, без всяких продвинутых фишек типа traffic control. Для тех кто с этим замечательным инструментом не знаком, но интересуется вот здесь есть статья по простенькой настройке Shorewall для раздачи интернета в локалку.

На сайте Shorewall есть прекрасная статья о контроле траффика на русском языке (в переводе Григория Мохина). Здесь я опишу свою конкретную конфигурацию.

Версия Shorewall

Упомянутый сервер работает под управлением Debian 3.1, в репозитариях которого присутствует Shorewall версии 2.2.3. Версия старая. Для других нужд мне когда-то пришлось её апгрейдить из репозитария backports.org. Сделать это несложно:

$ wget http://backports.org/debian/pool/main/s/shorewall/shorewall_3.2.6-2~bpo.1_all.deb
$ sudo dpkg -i shorewall_3.2.6-2~bpo.1_all.deb

Насколько меня не подводит склероз, никаких дополнительных зависимостей отсутствующих в 3.1 оно не имеет.

Конфигурация ядра

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

Файлы конфигурации Shorewall

Не вдаваясь в детали технологии traffic shaping, нужно сделать следующее:

1. Определить интерфейс для управления и его скорость.
2. Задать правила классификации трафика.
3. Задать ограничения скорости для каждого из классов трафика.

1. Определение интерфейса и скорости

На самом деле канал как бы и не очень узкий. Наш прекрасный провайдер по ADSL обещает скорость до 8 мегабит. Но провайдер со своей стороны разделяет эти 8 в пропорции 10:1 (10 частей на приём, 1 часть на отдачу). С учётом того, что реальная скорость так высоко никогда не поднимается, на этой конкретной линии экспериментальным путём было определено, что реальная ширина канала составляет примерно 6000kbit на приём и 600kbit на отдачу.

В файле /etc/shorewall/tcdevices:

#INTERFACE      IN-BANDWITH     OUT-BANDWIDTH
ppp0            6000kbit        600kbit
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

2. Правила классификации трафика

Файл /etc/shorewall/tcrules:

#MARK SOURCE    DEST        PROTO PORT(S)
1     $FW       xx.xx.xx.xx all
1     $FW       xx.xx.xx.xx all
1     $FW       xx.xx.xx.xx all
1     $FW       xx.xx.xx.xx all
1     $FW       xx.xx.xx.xx all
1     0.0.0.0/0 0.0.0.0/0   udp   openvpn
2     0.0.0.0/0 0.0.0.0/0   tcp   smtp,ssmtp,submission
3     $FW       0.0.0.0/0   tcp   http,https,8000,8080
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

Первый класс мы присваиваем трафику идущему на сервера удалённых офисов (реальные адреса я заменил иксами), а так же всему трафику с порта openvpn на любой хост. Сервера сюда добавлены, т.к. кроме vpn-трафика там может быть другой трафик, не менее важный (например ssh =).

Второй класс присваиваем smtp-трафику и его вариантам. Причём как входящему, так и исходящему.

Третий класс трафику по http и https.

3. Ограничения скорости

Файл /etc/shorewall/tcclasses:

#INTERFACE      MARK    RATE    CEIL    PRIORITY        OPTIONS
ppp0            1       full/2  full    1
ppp0            2       full/8  full/4  4
ppp0            3       full/8  full/2  3
ppp0            255     full/8  full    2               default
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

• full - это полная ширина канала, заданная ранее; соответственно full/2 - половина ширины
• колонка RATE - минимальная ширина канала для класса
• колонка CEIL - максимальная ширина канала для класса
• колонка PRORITY - приоритетность класса (чем меньше значение, тем выше приоритет класса)

Последней строчкой задано правило для всего трафика, не попавшего под классификацию.

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