<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Управление трафиком и шейпинг трафика</title><link rel="stylesheet" href="html.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="id257527"></a>Управление трафиком и шейпинг трафика</h2></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Arne</span> <span class="surname">Bernin</span></h3></div></div></div><div><p class="copyright">Copyright © 2001-2007 Thomas M. Eastep</p></div><div><p class="copyright">Copyright © 2005 Arne Bernin & Thomas M. Eastep</p></div><div><p class="copyright">Copyright © 2007 Russian Translation: Grigory Mokhin</p></div><div><div class="legalnotice"><a id="id257940"></a><p>Этот документ разрешается копировать, распространять и/или
изменять при выполнении условий лицензии GNU Free Documentation License
версии 1.2 или более поздней, опубликованной Free Software Foundation;
без неизменяемых разделов, без текста на верхней обложке, без текста на
нижней обложке. Копия лицензии приведена по ссылке “<span class="quote"><a class="ulink" href="GnuCopyright.htm" target="_self">GNU Free Documentation
License</a></span>”.</p></div></div><div><p class="pubdate">2008/12/15</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#Intro">Введение</a></span></dt><dt><span class="section"><a href="#LinuxTC">Управление трафиком и шейпинг трафика в Linux</a></span></dt><dt><span class="section"><a href="#Kernel">Конфигурация ядра Linux</a></span></dt><dt><span class="section"><a href="#Shorewall">Включение поддержки TC в Shorewall</a></span></dt><dt><span class="section"><a href="#Builtin">Работа с встроенными функциями управления трафиком и
шейпинга</a></span></dt><dd><dl><dt><span class="section"><a href="#tcdevices">/etc/shorewall/tcdevices</a></span></dt><dt><span class="section"><a href="#tcclasses">/etc/shorewall/tcclasses</a></span></dt><dt><span class="section"><a href="#tcrules">/etc/shorewall/tcrules</a></span></dt><dt><span class="section"><a href="#ppp">Устройства ppp</a></span></dt><dt><span class="section"><a href="#Real">Рабочие примеры</a></span></dt><dd><dl><dt><span class="section"><a href="#Wondershaper">Конфигурация для замены Wondershaper</a></span></dt><dt><span class="section"><a href="#simiple">Простая конфигурация</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a href="#Xen">Замечания для пользователей Xen</a></span></dt><dt><span class="section"><a href="#External">Применение собственных сценариев tc</a></span></dt><dd><dl><dt><span class="section"><a href="#owntcstart">Замена встроенного файла tcstart</a></span></dt><dt><span class="section"><a href="#Start">Управление трафиком, внешнее по отношению к Shorewall</a></span></dt></dl></dd><dt><span class="section"><a href="#Testing">Инструменты тестирования</a></span></dt></dl></div><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>Управление трафиком - это сложная тема, и не следует ожидать от
сообщества Shorewall готовых ответов на возникающие в связи с этим
вопросы. Поэтому, если вам нужны готовые рецепты, как нажать кнопку, чтобы
все заработало само, лучше даже не пытайтесь организовать управление
трафиком с помощью Shorewall. Вас ожидают неприятные разочарования, и вряд
ли кто-либо сможет вам помочь.</p></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Иначе говоря, чтение только документации Shorewall не будет
достаточным для понимания раскрываемых здесь тем.</p><p>Как минимум, потребуется обратиться к следующим дополнительным
источникам:</p><div class="itemizedlist"><ul type="disc"><li><p>LARTC HOWTO: <a class="ulink" href="http://www.lartc.org" target="_self">http://www.lartc.org</a></p></li><li><p>Руководство по HTB: <a class="ulink" href="http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm" target="_self">http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm</a></p></li><li><p>Некоторые документы с сайта <a class="ulink" href="http://www.netfilter.org/documentation/index.html#documentation-howto" target="_self">http://www.netfilter.org/documentation/index.html#documentation-howto</a>.
Рекомендуем ознакомиться с очень хорошим руководством Оскара
Андреассона.</p></li><li><p>Вывод команды <span class="command"><strong>man iptables</strong></span></p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Intro"></a>Введение</h2></div></div></div><p>Начиная с версии 2.5.5 в Shorewall реализована встроенная поддержка
управления трафиком и шейпинга трафика. В более ранних версиях эти
возможности были ограниченными. Можно было использовать собственный
сценарий tcstart (это можно и сейчас), но, за исключением файла tcrules, в
файлах конфигурации Shorewall не была предусмотрена возможность
определения классов и дисциплин очередей.</p><p>До сих пор поддержка управления трафиком является неполной,
например, не поддерживаются все опции (и особенно различные алгоритмы
очередей) из ядра Linux, но для большинства случаев она будет достаточной.
Если у вас уже есть сценарий для управления трафиком, который вы
собираетесь использовать и в будущем, то соответствующие инструкции
приведены по ссылке <a class="link" href="#owntcstart" title="Замена встроенного файла tcstart"> ниже в этом
документе</a>. Для того чтобы это заработало, требуется включить
поддержку управления трафиком в ядре и в Shorewall, как описано
далее.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="LinuxTC"></a>Управление трафиком и шейпинг трафика в Linux</h2></div></div></div><p>В этом разделе кратко описано, как работает управление трафиком в
Linux. Даже если этого должно быть достаточно для настройки управления
трафиком в файлах конфигурации Shorewall, мы очень рекомендуем внимательно
прочитать руководство <a class="ulink" href="http://lartc.org/howto/" target="_self">Linux Advanced
Routing and Shaping HOWTO</a>. Во время написания этого документа
текущей версией была 1.0.0.</p><p>Начиная с версии 2.2, в Linux реализованы полные возможности
управления трафиком. Предусмотрены различные алгоритмы, которые
применяются для приоритизации очередей пакетов, выходящих с интерфейса.
Стандартный алгоритм называется pfifo, и, как следует из самого названия,
это очередь типа первым пришел - первым ушел. Фактически при этом никакого
управления трафиком не происходит, и если какое-то соединение забивает
весь канал, то этот алгоритм не сможет этого предотвратить.</p><p>Для управления трафиком в Shorewall используются два алгоритма, HTB
(иерархический набор маркеров) и SFQ (очередь с равноправным
стохастическим упорядочением). SFQ использует простую схему: отслеживаются
все соединения (tcp или udp), и трафик распределяется между ними. Обычно
это работает хорошо. HTB позволяет определить набор классов, между
которыми распределяется трафик. Для каждого класса можно указать
минимальную и максимальную полосу пропускания, а сами классы упорядочить в
иерархическую структуру, чтобы классы с меньшим приоритетом получали
доступ к каналу только в том случае, если запросы более важных классы
удовлетворены. Встроенные функции управления трафиком в Shorewall
позволяют определить такие классы и указать для них полосу пропускания.
Внутри самих классов используется SFQ, чтобы их различные внутренние
потоки данных обрабатывались как равноправные.</p><p><span class="bold"><strong>Управлять можно только исходящим трафиком.
Причина этого состоит в том, что входящие пакеты уже пришли на сетевую
плату, и нужно решить, что с ними делать</strong></span>. Их можно только
сбросить, но особого смысла в этом не будет, поскольку пакет уже пришёл,
пройдя через узкое место - входящий канал. Следующим узким местом может
быть интерфейс, с которого уходит этот пакет, и именно на нём может
образовываться очередь. Поэтому определение очередей для входящих пакетов
не будет особенно полезным, эти пакеты просто нужно передать как можно
быстрее на исходящий интерфейс.</p><p>Есть одно исключение. Если ограничить входящий трафик значением чуть
меньшим, чем фактическая пропускная способность канала, то будет исключено
образование очередей на другом конце соединения. Это бывает полезно, если
управление потоком на другом конце канала невозможно, а сам он подключен к
сети по более быстрому каналу, например, если вы подключены к провайдеру
по кабельному модему или модему DSL, а маршрутизатор провайдера подключен
к быстрому магистральному каналу. Поэтому, если отбрасывать слишком быстро
приходящие пакеты, то основной протокол сможет это обнаружить и снизить
скорость соединения. В TCP такой механизм встроен, в UDP не встроен, но
протокол, работающий поверх UDP, может иметь такой механизм.</p><p>В таких случаях создание очередей будет иметь неприятные
последствия, если есть пакеты, которые должны проходить в первую очередь,
как, например, VoIP или ssh. Для таких соединений важно, чтобы пакеты
проходили с минимальной задержкой. Для других пакетов, таких как загрузка
по HTTP, задержка на несколько секунд не будет иметь значения.</p><p>Если на другом конце канала образуется очередь, а маршрутизатор не
поддерживает QoS или биты QoS настроены неверно, то пакеты, для которых
важна минимальная задержка, будут ждать в той же очереди, что и менее
важные пакеты загрузки по HTTP, и задержка может быть большой.</p><p>Управление исходящим трафиком достигается посредством распределения
потока пакетов по <em class="firstterm">классам</em>. Класс связан ровно с
одним сетевым интерфейсом и имеет ряд атрибутов:</p><div class="orderedlist"><ol type="1"><li><p>PRIORITY - используется для указания приоритетов классов, к
которым относятся отправляемые пакеты. Приоритет - это число, при этом
1 задаёт наивысший приоритет, 2 - следующий по важности и т.д.</p></li><li><p>RATE - скорость, то есть минимальная гарантированная пропускная
способность, которая должна обеспечиваться для класса, когда
возрастает нагрузка на канал. Классы с более высоким приоритетом
(меньшие значения PRIORITY) обслуживаются даже в том случае, если
заданы другие классы с гарантированной пропускной способностью, но
низшим приоритетом (большие значения PRIORITY).</p></li><li><p>CEIL - ограничение, максимальная полоса пропускания, которая
отводится для класса, когда канал свободен.</p></li><li><p>MARK - метка. В Netfilter предусмотрены способы
<em class="firstterm">маркировки</em> пакетов. Метки пакетов - это числа.
В Shorewall они могут принимать значение от 1 до 255. Метки пакетов
присваиваются различным типам пакетов согласно правилам, заданным в
файле <code class="filename">/etc/shorewall/tcrules</code>.</p></li></ol></div><p>Для каждого интерфейса необходимо задать один класс, который будет
<em class="firstterm">классом по умолчанию</em>. К этому классу будут
относиться непомеченные данные, то есть пакеты, для которых не задана
метка в файле <code class="filename">/etc/shorewall/tcrules</code>.</p><p>Netfilter также поддерживает метки соединений. Метки соединений
можно присвоить соединениям в правилах
<code class="filename">/etc/shorewall/tcrules</code>, можно скопировать метку
пакета в метку соединения (SAVE), или скопировать метку соединения в метку
пакета (RESTORE).</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Kernel"></a>Конфигурация ядра Linux</h2></div></div></div><p>Для работы требуется ядро не ниже 2.4.18. На рисунке показаны опции
ядра, которые необходимо включить. Для встроенной поддержки необходимы
опции HTB scheduler, Ingress scheduler, PRIO pseudoscheduler и SFQ queue.
Прочие планировщики или алгоритмы очередей необязательны.</p><p>Также требуются классификаторы u32 и fw из главного меню Networking
Options (не показаны).</p><p>На следующем рисунке показано, как я настроил QoS у себя в ядре
2.6.13:</p><div align="center"><img src="images/QoS.png" align="middle" /></div><p>Конфигурация ядра изменилась в 2.6.16 -- вот мои
рекомендации.</p><div align="center"><img src="images/traffic_shaping2.6.png" align="middle" /></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Shorewall"></a>Включение поддержки TC в Shorewall</h2></div></div></div><p>Поддержку TC требуется включить независимо от того, применяются ли
встроенные функции или вы используете собственный сценарий tcstart.</p><p>Для включения встроенных функций управления трафиком в Shorewall
выполните следующее:</p><div class="itemizedlist"><ul type="disc"><li><p>Задайте <span class="bold"><strong>TC_ENABLED</strong></span> равным
"Internal" в /etc/shorewall/shorewall.conf. Если TC_ENABLED=Yes, то
Shorewall будет искать внешний файл tcstart (см. <a class="link" href="#tcstart">далее</a>).</p></li><li><p>Если задать параметр <span class="bold"><strong>CLEAR_TC</strong></span> в
/etc/shorewall/shorewall.conf равным Yes, то при запуске, перезапуске
и остановке Shorewall будет сбрасываться текущая конфигурация
управления трафиком. Обычно именно это и требуется при работе с
встроенными функциями, а также с собственным сценарием tcstart.</p></li><li><p>Следующие действия зависят от того, применяются ли встроенные
функции или собственный сценарий. Подробнее это объясняется в
следующих разделах.</p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Builtin"></a>Работа с встроенными функциями управления трафиком и
шейпинга</h2></div></div></div><p>Встроенные в Shorewall функции управления трафиком - это тонкая
оболочка для очереди входящих пакетов (ingress qdisc), HTB и SFQ. Эта
оболочка позволяет выполнить следующие задачи:</p><div class="itemizedlist"><ul type="disc"><li><p>Определить классы HTB в файлах конфигурации Shorewall.</p></li><li><p>Включить загрузку конфигурации управления трафиком вместе с
загрузкой правил фильтрации пакетов и правил для меток.</p></li><li><p>Распределить пакеты по классам HTB согласно значениям
TOS.</p></li><li><p>Отнести исходящие пакеты TCP ACK к классу HTB.</p></li><li><p>Распределить пакеты по классам HTB согласно значениям меток
пакетов.</p></li></ul></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Встроенные в Shorewall функции управления трафиком ограничены
десятью (10) устройствами.</p></div><p>Больше никаких задач встроенные функции управления трафиком не
выполняют. Поэтому, чтобы их использовать, необходимо понимать, как
работает HTB и управление трафиком в Linux, и как работают метки пакетов
Netfilter. За дополнительной информацией обратитесь к ссылкам, приведенным
в начале этого документа.</p><p>Для задания пропускной способности (как устройств, так и классов)
используйте kbit или kbps (для килоБАЙТ в секунду) <span class="bold"><strong>БЕЗ</strong></span> пробела между числом и единицей измерения (то
есть 100kbit <span class="bold"><strong>НО НЕ</strong></span> 100 kbit). Можно также
использовать mbit, mbps или число (означающее байты), но поддерживаются
только целые числа (0.5 использовать <span class="bold"><strong>нельзя</strong></span>).</p><p>Для того чтобы правильно настроить устройства, необходимо выяснить
фактическую пропускную способность канала в обоих направлениях. Это
особенно важно для соединений DSL или любых других, для которых пропускная
способность канала не гарантирована. Не верьте числам, которые называет
провайдер, но сами измерьте реальную скорость канала. В этом могут помочь
различные утилиты в сети, попробуйте поискать "dsl speed test" в google
(для Германии можно использовать <a class="ulink" href="http://www.speedcheck.arcor.de/cgi-bin/speedcheck.cgi" target="_self">arcor speed
check</a>). Найдите тест поближе к себе.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="tcdevices"></a>/etc/shorewall/tcdevices</h3></div></div></div><p>В этом файле можно задать пропускную способность способность
канала для устройств, для которых будет включено управление трафиком.
Это означает, что в этом файле необходимо определить параметры для
устройства, чтобы для него заработало управление трафиком.</p><p>Далее описаны столбцы файла:</p><div class="itemizedlist"><ul type="disc"><li><p>INTERFACE - Имя интерфейса. Интерфейс может быть указан не
более одного раза. Использовать псевдоним интерфейса (например,
eth0:0) здесь нельзя, см. <a class="ulink" href="FAQ.htm#faq18" target="_self">FAQ
#18</a>. Также нельзя использовать символы подстановки,
например, если есть несколько интерфейсов ppp, то все их необходимо
здесь перечислить. В версиях Shorewall до 3.0.8 и 3.2.0 Beta 8,
устройство, имя которого указано в столбце, должно было существовать
в момент запуска, перезапуска или обновления Shorewall. Начиная с
версии 3.0.8 и 3.2.0 Beta 8 Shorewall может определить, существует
ли устройство, и настроит его только в том случае, если оно
существует. Если оно не существует, то будет показано следующее
предупреждение:</p><p><span class="bold"><strong>WARNING: Device <устройство> not
found -- traffic-shaping configuration skipped</strong></span></p></li><li><p>IN-BANDWIDTH - Пропускная способность входящего канала для
этого интерфейса. Обратите внимание, что шейпинг входящего трафика
невозможен, так как пакеты уже пришли. В этом столбце можно задать
максимальную скорость, разрешенную для этого интерфейса, при
превышении которой пакеты будут отбрасываться. Это полезно главным
образом для соединений DSL или кабельных, чтобы избежать очередей в
устройствах провайдера. Если не следует отбрасывать никакие пакеты,
то укажите значение, превышающее фактическую максимальную скорость
канала (в Shorewall начиная с версии 3.2.6 можно также указать
0).</p><p>Для того чтобы определить оптимальное значение, укажите
сначала значение, которое заведомо ниже, чем измеренная скорость
канала (процентов на 20). Далее, в ходе загрузки файлов, измеряйте
время ответа на <span class="emphasis"><em>ping</em></span> между своей системой и
маршрутизатором провайдера и постепенно увеличивайте это значение.
Оптимальным будет значение, при превышении которого время ответа на
<span class="emphasis"><em>ping</em></span> будет резко расти.</p></li><li><p>OUT-BANDWIDTH - Пропускная способность исходящего канала для
этого интерфейса. Это максимальная скорость, с которой может
работать исходящее соединение. В терминах классов tc эта скорость
называется полной (full). Превышающий эту скорость исходящий трафик
будет отбрасываться.</p></li></ul></div><div class="example"><a id="Example0"></a><p class="title"><b>Example 1. </b></p><div class="example-contents"><p>Предположим, что вы работаете с PPP по Ethernet (DSL), а
интерфейс - это ppp0. Устройство имеет исходящую скорость 500 кбит и
входящую - 6000 кбит</p><pre class="programlisting">#INTERFACE IN-BANDWITH OUT-BANDWIDTH
ppp0 6000kbit 500kbit</pre></div></div><br class="example-break" /></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="tcclasses"></a>/etc/shorewall/tcclasses</h3></div></div></div><p>В этом файле можно задать классы, по которым будет распределяться
исходящий трафик.</p><div class="itemizedlist"><ul type="disc"><li><p>INTERFACE - Имя интерфейса. Должно совпадать с именем
интерфейса в файле
<code class="filename">/etc/shorewall/tcdevices</code>.</p></li><li><p>MARK - метка. Должна быть целым числом от 1 до 255. Эти метки
задаются в файле tcrules. Они помечают пакеты, которые тем самым
будут отнесены к определенным здесь классам очередей. Одни и те же
метки могут использоваться для разных интерфейсов.</p></li><li><p>RATE - скорость, то есть минимальная гарантированная
пропускная способность, которая должна обеспечиваться для класса,
когда возрастает нагрузка на канал. Классы с более высоким
приоритетом обслуживаются даже в том случае, если заданы другие
классы с гарантированной пропускной способностью, но низшим
приоритетом. <span class="bold"><strong>Если сумма значений RATE для всех
классов, присвоенных интерфейсу, превышает OUT-BANDWIDTH для
интерфейса, то предел OUT-BANDWIDTH не будет
соблюдаться.</strong></span></p></li><li><p>CEIL - ограничение, максимальная полоса пропускания, которая
отводится для данного класса, когда канал свободен. Это полезно,
если есть трафик, для которого будет выделяться полная скорость
канала, если более важные службы (такие как ssh) не используются.
Значение "full" означает, что максимальная пропускная способность
для класса определяется значением, заданным для интерфейса.</p></li><li><p>PRIORITY - позволяет указать приоритет для класса. Пакеты из
класса с более высоким приоритетом (то есть меньшим значением) будут
обрабатываться раньше, чем пакеты с низшим приоритетом. Здесь можно
просто указать значение метки, если метки присваиваются согласно
приоритетам.</p></li><li><p>OPTIONS - Список параметров через запятую. Возможны следующие
параметры:</p><div class="itemizedlist"><ul type="circle"><li><p>default - класс по умолчанию для интерфейса, к которому
будет отнесен весь трафик, не отнесенный к другим
классам.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Необходимо указать default ровно для <span class="bold"><strong>одного</strong></span> класса для интерфейса.</p></div></li><li><p>tos-<имя-tos> - позволяет указать фильтр для
заданного <имени-tos>, что в свою очередь позволяет
определить значение бит Type Of Service в пакете ip, вследствие
чего пакет будет отнесен к этому классу. Учтите, что этот фильтр
переопределяет все заданные метки, поэтому, если задать фильтр
tos для класса, то все пакеты, имеющие эту метку, войдут в этот
класс независимо от того, какая у них уже есть метка. Возможные
значения этого параметра: tos-minimize-delay (16)
tos-maximize-throughput (8) tos-maximize-reliability (4)
tos-minimize-cost (2) tos-normal-service (0)</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Каждая из этих опций применима только для <span class="bold"><strong>одного</strong></span> класса интерфейса.</p></div></li><li><p>tcp-ack - эта опция создает фильтр tc и класс, в который
помещаются все пакеты tcp ack на этом интерфейсе, размер которых
не превышает 64 байта. Это позволяет ускорить загрузку.
Ограничение размера пакетов ack 64 байтами служит для того,
чтобы исключить из этого класса все приложения (например, p2p),
которые помечают каждый пакет как пакет ack. Этому фильтру
должны соответствовать только пакеты БЕЗ дополнительной
нагрузки, отсюда и ограничение размера. Пакеты большего размера
будут отнесены в другие классы.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Эта опция применима только для одного <span class="bold"><strong>класса</strong></span> интерфейса.</p></div></li></ul></div></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="tcrules"></a>/etc/shorewall/tcrules</h3></div></div></div><p>Классификатор fwmark является удобным средством для классификации
пакетов при управлении трафиком. В файле
“<span class="quote">/etc/shorewall/tcrules</span>” эти метки представлены в виде
таблицы. Глубже познакомиться с маркировкой пакетов в
Netfilter/Shorewall позволяет <a class="ulink" href="PacketMarking.html" target="_self">этот
документ</a>.</p><p>Обычно метка пакета ставится в цепочке PREROUTING перед тем, как
осуществляется замена адресов. При этом невозможно помечать входящие
пакеты согласно их целевому адресу, если применяется SNAT или
Masquerading. Тем не менее, можно осуществлять маркировку пакетов в
цепочке FORWARD, если задать опцию MARK_IN_FORWARD_CHAIN в файле
shorewall.conf.</p><p>Далее описаны столбцы файла:</p><div class="itemizedlist"><ul type="disc"><li><p>MARK или CLASSIFY - MARK задает значение метки, которая
присваивается пакету в случае совпадения с правилом. Она должна быть
целым числом от 1 до 255. Вслед за этим значением может идти
“<span class="quote">:</span>” и одно из значений: “<span class="quote">F</span>”,
“<span class="quote">P</span>” или "T", которые обозначают соответственно
маркировку в цепочках FORWARD, PREROUTING или POSTROUTING. Если эти
дополнительные спецификаторы опущены, то цепочка, в которой
осуществляется маркировка пакетов, определяется следующим
образом:</p><div class="itemizedlist"><ul type="circle"><li><p>Если SOURCE - это
$FW[:<<span class="emphasis"><em>адрес</em></span>>], то правило вставляется
в цепочку OUTPUT.</p></li><li><p>В противном случае цепочка определяется по значению опции
MARK_IN_FORWARD_CHAIN из файла shorewall.conf.</p></li></ul></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Спецификатор "T" был добавлен в Shorewall версии 3.3.6 и
недоступен в более ранних версиях.</p></div><p>Обычно метка присваивается пакету. Если вслед за меткой
указать ":" и "C", то метка будет применяться к соединению. "C"
можно сочетать с "F", "P" или "T", чтобы указать, что соединение
следует пометить в определенной цепочке (например, "CF", "CP",
"CT").</p><p>Предусмотрены также следующие специальные значения:</p><div class="orderedlist"><ol type="a"><li><p><span class="bold"><strong>RESTORE</strong></span>[/<span class="emphasis"><em>маска</em></span>] --
восстановить метку пакета из метки соединения, используя маску,
если она указана. Ядро и iptables должны поддерживать
CONNMARK.</p><p>Как и ранее, можно использовать дополнительные
спецификаторы <span class="bold"><strong>:P</strong></span>, <span class="bold"><strong>:F</strong></span> или <span class="bold"><strong>:T</strong></span>.</p></li><li><p><span class="bold"><strong>SAVE</strong></span>[/<span class="emphasis"><em>маска</em></span>] --
сохранить метку пакета в метке соединения, используя маску, если
она указана. Ядро и iptables должны поддерживать
CONNMARK.</p><p>Как и ранее, можно использовать дополнительные
спецификаторы <span class="bold"><strong>:P</strong></span>, <span class="bold"><strong>:F</strong></span> или <span class="bold"><strong>:T</strong></span>.</p></li><li><p><span class="bold"><strong>CONTINUE</strong></span> - прекратить
обработку дальнейших правил маркировки в таблице.</p><p>Как и ранее, можно использовать дополнительные
спецификаторы <span class="bold"><strong>:P</strong></span>, <span class="bold"><strong>:F</strong></span> или <span class="bold"><strong>:T</strong></span>.</p></li><li><p><span class="bold"><strong>COMMENT</strong></span> (Начиная с
Shorewall версии 3.3.3) -- остальной текст в строке будет
добавлен как комментарий в правила Netfilter, генерируемые по
следующим записям. Комментарий будет выделен символам "/* ...
*/" в выводе команды <span class="command"><strong>shorewall show
mangle</strong></span></p><p>Для того чтобы комментарий не применялся к последующим
строкам, укажите COMMENT в отдельной строке.</p></li></ol></div><p>При работе с CLASSIFY ядро и iptables должны поддерживать
CLASSIFY. В этом случае в столбце будет содержаться классификатор
(classid) в виде <основной>:<дополнительный>, где
<основной> и <дополнительный> должны быть целыми
числами. Он соответствует указанию 'class' в следующих модулях
управления трафиком:</p><table class="simplelist" border="0" summary="Simple list"><tr><td>atm</td></tr><tr><td>cbq</td></tr><tr><td>dsmark</td></tr><tr><td>pfifo_fast</td></tr><tr><td>htb</td></tr><tr><td>prio</td></tr></table><p>В версиях Shorewall до 3.2.3 правила классификации всегда
помещались в цепочку POSTROUTING. Начиная с Shorewall версии 3.2.3
классификация осуществляется в цепочке POSTROUTING, <span class="bold"><strong>кроме тех случаев</strong></span>, когда SOURCE содержит
$FW[:<<span class="emphasis"><em>адрес</em></span>>], для которых классификация
осуществляется в цепочке OUTPUT. При работе со встроенными функциями
управления трафиком класс <основной> - это номер устройства
(первая запись в файле <code class="filename">/etc/shorewall/tcdevices</code>
- это устройство 1, вторая - устройство 2 и т.д.), а класс
<дополнительный> - это значение MARK класса, перед которой
стоит число "1" (для MARK со значением 1 <дополнительный>
класс - это 11, для MARK со значением 22 - <дополнительный>
класс 122, и т.д.).</p></li><li><p>SOURCE - источник пакета. Это может быть разделенный запятыми
список имен интерфейсов, IP-адресов, MAC-адресов и/или подсетей для
пакетов, маршрутизируемых по общему пути. Элементы списка могут
также включать имя интерфейса, к которому прибавлено ":" и адрес
(например, eth1:192.168.1.0/24). Так, все пакеты для соединений,
маскируемых через eth0 с других интерфейсов, можно описать одним
правилом с несколькими критериями SOURCE. Однако соединение, пакеты
которого приходят на eth0 по другому пути, например, из самой
системы файрвола, требуют отдельного правила.</p><p>Поэтому создавайте отдельное правило с $FW для пакетов,
исходящих из системы файрвола. В таком правиле столбец MARK не может
содержать ":P" или ":F", поскольку маркировка пакетов, исходящих из
системы файрвола, всегда осуществляется в цепочке OUTPUT.</p><p>MAC-адреса необходимо предварять символом "~" и использовать
"-" как разделитель.</p><p>Пример: ~00-A0-C9-15-39-78</p></li><li><p>DEST - назначение пакета. Список IP-адресов и/или подсетей,
разделенный запятыми. Если ядро и iptables поддерживают iprange, то
можно также указывать диапазоны IP-адресов. Элементы списка могут
также включать имя интерфейса, к которому прибавлено ":" и адрес
(например, eth1:192.168.1.0/24). Если в столбце MARK указан
спецификатор в виде <основной>:<дополнительный>, то
столбец может также содержать имя интерфейса.</p></li><li><p>PROTO - протокол. Должен быть указан как "tcp", "udp", "icmp",
"ipp2p", "ipp2p:udp", "ipp2p:all", число или "all". Для "ipp2p"
требуется поддержка ipp2p в ядре и iptables.</p></li><li><p>PORT(S) - целевые порты. Список имен портов (из
/etc/services), номеров портов или диапазонов портов, разделенный
запятыми. Если протокол - это "icmp", то столбец считается целевым
типом icmp.</p><p>Если протокол - это ipp2p, то столбец интерпретируется как
опция ipp2p без начального "--" (например, "bit" для bit-torrent).
Если PORT не указан, предполагается "ipp2p".</p><p>Этот поле игнорируется, если PROTOCOL = all, но должно быть
указано, если задано любое из последующих полей. В этом случае
рекомендуется указывать в этом поле "-"</p></li><li><p>CLIENT PORT(S) - необязательные порты, применяемые клиентом.
Если они не указаны, то допускается любой целевой порт. Задается как
список, разделенный запятыми, имен портов, номеров портов или
диапазонов портов.</p></li><li><p>USER/GROUP (Начиная с Shorewall версии 1.4.10) -
Необязательный параметр имени пользователя или группы. Он может
указываться, только если SOURCE - это сама система файрвола. Если
значение поля задано, то правило применяется только в том случае,
если программа, создавшая пакет, работает от имени указанного
пользователя и/или группы. Возможные значения:</p><p>[!][<имя пользователя или номер>]:[<имя группы или
номер>][+<имя программы>]</p><p>Двоеточие указывать необязательно, если задано только имя
пользователя.</p><p>Примеры:</p><pre class="programlisting">joe # программа должна выполняться пользователем joe
:kids # программа выполняется участниками группы 'kids'
!:kids # программа выполняется участниками группы 'kids'
+upnpd # программа upnpd (эта функция была удалена из Netfilter в версии ядра 2.6.14).</pre></li><li><p>TEST - задает тест для проверки существующей метки пакета или
соединения. Правило будет совпадать только в том случае, если тест
возвращает true. Тесты имеют следующий формат:
[!]<значение>[/<маска>][:C]</p><p>Здесь:</p><table class="simplelist" border="0" summary="Simple list"><tr><td>! Обратное соответствие (не равно)</td></tr><tr><td><значение> Значение метки соединения или
пакета.</td></tr><tr><td><маска> Маска, применяемая к метке перед
сравнением</td></tr><tr><td>:C обозначает метку соединения. Если она не указана, то
сравнивается метка пакета.</td></tr></table></li><li><p>LENGTH - длина пакета (необязательный параметр, начиная с
Shorewall версии 3.2.0). Если указано это значение, то сравнивается
длина пакета с указанным значением или диапазоном значений. Диапазон
задается в виде <мин>:<макс>, где можно опустить или
<мин>, или <макс>, но не оба эти параметра. Если опущен
<мин>, то он считается равным 0, если опущен <макс>, то
совпадающим будет любой пакет, длина которого не меньше
<мин>.</p><p>Для этой опции необходима поддержка сравнения длины в
iptables. Если значение не указано или задано как "-", то сравнение
длины не выполняется.</p><p>Примеры: 1024, 64:1500, :100</p></li><li><p>TOS - тип обслуживания (необязательный параметр, начиная с
Shorewall версии 3.2.0 Beta 6). Стандартное имя или число.</p><div class="blockquote"><blockquote class="blockquote"><table class="simplelist" border="0" summary="Simple list"><tr><td>Minimize-Delay (16)</td></tr><tr><td>Maximize-Throughput (8)</td></tr><tr><td>Maximize-Reliability (4)</td></tr><tr><td>Minimize-Cost (2)</td></tr><tr><td>Normal-Service (0)</td></tr></table></blockquote></div></li></ul></div><div class="example"><a id="Example1"></a><p class="title"><b>Example 2. </b></p><div class="example-contents"><p>Все пакеты, приходящие на eth1, должны иметь метку 1. Все
пакеты, приходящие на eth2 и eth3, должны иметь метку 2. Все пакеты,
созданные в системе файрвола, должны иметь метку 3.</p><pre class="programlisting">#MARK SOURCE DESTINATION PROTOCOL PORT(S)
1 eth1 0.0.0.0/0 all
2 eth2 0.0.0.0/0 all
2 eth3 0.0.0.0/0 all
3 $FW 0.0.0.0/0 all</pre></div></div><br class="example-break" /><div class="example"><a id="Example2"></a><p class="title"><b>Example 3. </b></p><div class="example-contents"><p>Все пакеты GRE (протокол 47), не созданные в системе файрвола и
имеющие целевой адрес 155.186.235.151, должны иметь метку 12.</p><pre class="programlisting">#MARK SOURCE DESTINATION PROTOCOL PORT(S)
12 0.0.0.0/0 155.182.235.151 47</pre></div></div><br class="example-break" /><div class="example"><a id="Example3"></a><p class="title"><b>Example 4. </b></p><div class="example-contents"><p>Все пакеты SSH, приходящие с 192.168.1.0/24 и предназначенные
для 155.186.235.151, должны иметь метку 22.</p><pre class="programlisting">#MARK SOURCE DESTINATION PROTOCOL PORT(S)
22 192.168.1.0/24 155.182.235.151 tcp 22</pre></div></div><br class="example-break" /><div class="example"><a id="Example4"></a><p class="title"><b>Example 5. </b></p><div class="example-contents"><p>Все пакеты SSH, проходящие через первое устройство в файле
/etc/shorewall/tcdevices, должны быть отнесены в класс с меткой
10.</p><pre class="programlisting">#MARK SOURCE DESTINATION PROTOCOL PORT(S) CLIENT
# PORT(S)
1:110 0.0.0.0/0 0.0.0.0/0 tcp 22
1:110 0.0.0.0/0 0.0.0.0/0 tcp - 22</pre></div></div><br class="example-break" /><div class="example"><a id="Example5"></a><p class="title"><b>Example 6. </b></p><div class="example-contents"><p>Все пакеты echo ICMP должны иметь метку 1. Весь трафик
протоколов p2p должен иметь метку 4.</p><p>Это чуть более сложный случай. Поскольку модуль ipp2p не в
состоянии распознать все пакеты в соединении как пакеты P2P, то все
соединение помечается как P2P, если совпадение найдено хотя бы для
одного пакета. Предполагается, что метка пакета/соединения 0 означает
неклассифицированные пакеты.</p><pre class="programlisting">#MARK SOURCE DESTINATION PROTOCOL PORT(S) CLIENT USER/ TEST
# PORT(S) GROUP
1 0.0.0.0/0 0.0.0.0/0 icmp echo-request
1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply
RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0
CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0
4 0.0.0.0/0 0.0.0.0/0 ipp2p:all
SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0</pre><p>Последние четыре правила означают следующее:</p><div class="blockquote"><blockquote class="blockquote"><p>"Если пакет не был классифицирован (метка пакета 0), то
скопировать метку соединения в метку пакета. Если метка пакета уже
задана, то никаких действий более не требуется. Если пакет относится
к типу P2P, то задать метку пакета 4. Если метка пакета задана, то
сохранить ее в качестве метки соединения."</p></blockquote></div></div></div><br class="example-break" /></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="ppp"></a>Устройства ppp</h3></div></div></div><p>Если подключение к провайдеру выполняется через ppp/pppoe/pppoa, и
вы используете управление трафиком, то необходимо перезапустить
управление трафиком shorewall. Причина этого состоит в том, что если
соединение ppp перезапускается (обычно это происходит как минимум раз в
день), то все фильтры и qdisc “<span class="quote">tc</span>”, связанные с этим
интерфейсом, будут удалены.</p><p>Самым простым решением будет перезапуск shorewall при повторном
установлении соединения. Для этого добавьте в сценарий
“<span class="quote">/etc/ppp/ip-up.d</span>” следующую строку.</p><pre class="programlisting">#! /bin/sh
/sbin/shorewall refresh</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Real"></a>Рабочие примеры</h3></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="Wondershaper"></a>Конфигурация для замены Wondershaper</h4></div></div></div><p>Встроенные функции управления трафиком позволяют полностью
заменить сценарий wondershaper. Примеры файлов конфигурации приведены
по адресу <a class="ulink" href="http://www1.shorewall.net/pub/shorewall/Samples/tc4shorewall/" target="_self">"http://www1.shorewall.net/pub/shorewall/Samples/tc4shorewall/</a>.
Обратите внимание, что эти примеры необходимо настроить, чтобы они
работали в вашей среде. В них предполагается, что интерфейс соединения
с провайдером - это ppp0 (для DSL), и для другого типа соединения его
необходимо изменить. Также требуется изменить параметры в файле
tcdevices.wondershaper, чтобы они отвечали фактической скорости
канала. Ниже приведены соответствующие строки из файлов конфигурации.
В итоге получается точная замена того, что должен делать wondershaper.
Но вы можете и вносить улучшения...</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="realtcd"></a>Файл tcdevices</h5></div></div></div><pre class="programlisting">#INTERFACE IN-BANDWITH OUT-BANDWIDTH
ppp0 5000kbit 500kbit</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="realtcc"></a>Файл tcclasses</h5></div></div></div><pre class="programlisting">#INTERFACE MARK RATE CEIL PRIORITY OPTIONS
ppp0 1 full full 1 tcp-ack,tos-minimize-delay
ppp0 2 9*full/10 9*full/10 2 default
ppp0 3 8*full/10 8*full/10 2</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="realtcr"></a>Файл tcrules</h5></div></div></div><pre class="programlisting">#MARK SOURCE DEST PROTO PORT(S) CLIENT USER
# PORT(S)
1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-request
1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply
# метка для трафика с низким приоритетом:
# mldonkey
3 0.0.0.0/0 0.0.0.0/0 udp - 4666</pre><p>Wondershaper позволяет определить набор хостов и/или портов,
которым присваивается низкий приоритет. Для этого в tcrules этим
хостам нужно присвоить метку 3 (как это делается в примерах файлов
конфигурации).</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="lowpro"></a>Присвоение низкого приоритета хостам</h5></div></div></div><p>Допустим, что в сценарии wondershaper были следующие параметры
(только в качестве примера):</p><pre class="programlisting">
# Низкий приоритет для исходящего трафика - можно оставить пустым,
# чтобы применять сетевые маски для низкого приоритета
NOPRIOHOSTSRC="192.168.1.128/25 192.168.3.28"
# Низкий приоритет - маска для назначения
NOPRIOHOSTDST=60.0.0.0/24
# Низкий приоритет - порты источника
NOPRIOPORTSRC="6662 6663"
# Низкий приоритет - порты назначения
NOPRIOPORTDST="6662 6663"</pre><p>Эти параметры будут отражены следующим образом в файле
tcrules:</p><pre class="programlisting">3 192.168.1.128/25 0.0.0.0/0 all
3 192.168.3.28 0.0.0.0/0 all
3 0.0.0.0/0 60.0.0.0/24 all
3 0.0.0.0/0 0.0.0.0/0 udp 6662,6663
3 0.0.0.0/0 0.0.0.0/0 udp - 6662,6663
3 0.0.0.0/0 0.0.0.0/0 tcp 6662,6663
3 0.0.0.0/0 0.0.0.0/0 tcp - 6662,6663</pre></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="simiple"></a>Простая конфигурация</h4></div></div></div><p>Ниже приведен простой пример для общего подключения к Интернет с
разных компьютеров. Фактически здесь настроен шейпинг для двух хостов
с IP-адресами 192.168.2.23 и 192.168.2.42</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="simpletcd"></a>Файл tcdevices</h5></div></div></div><pre class="programlisting">#INTERFACE IN-BANDWITH OUT-BANDWIDTH
ppp0 6000kbit 700kbit</pre><p>Канал имеет входящие 6 мбит и исходящие 700 кбит.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="simpletcc"></a>Файл tcclasses</h5></div></div></div><pre class="programlisting">#INTERFACE MARK RATE CEIL PRIORITY OPTIONS
ppp0 1 5*full/10 full 1 tcp-ack,tos-minimize-delay
ppp0 2 3*full/10 9*full/10 2 default
ppp0 3 2*full/10 8*full/10 2</pre><p>Добавляется класс для пакетов tcp ack с высоким приоритетом,
чтобы ускорить загрузку. Следующие два класса совместно используют
большую часть пропускной способности канала для двух хостов, и если
соединение свободно, то всю пропускную способность. Так как хосты
считаются равноправными, они имеют одинаковый приоритет. Последний
класс предназначен для остального трафика.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="simpletcr"></a>Файл tcrules</h5></div></div></div><pre class="programlisting">#MARK SOURCE DEST PROTO PORT(S) CLIENT USER
# PORT(S)
1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-request
1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply
2:F 192.168.2.23 0.0.0.0/0 all
3:F 192.168.2.42 0.0.0.0/0 all</pre><p>Пакеты ping icmp и ответы помечаются отдельно, как относящиеся
к интерактивному классу. Для них метка ставится для обоих
хостов.</p></div></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Xen"></a>Замечания для пользователей Xen</h2></div></div></div><p>Если управление трафиком включено в dom0, но исходящий трафик при
этом шейпится неправильно, то причиной этого может быть "выгрузка
контрольных сумм" (checksum offloading) в ваших domU. Просмотрите вывод
команды "shorewall show tc". Ниже приведен пример:</p><pre class="programlisting">class htb 1:130 parent 1:1 leaf 130: prio 3 quantum 1500 rate 76000bit <span class="bold"><strong>ceil 230000bit</strong></span> burst 1537b/8 mpu 0b overhead 0b cburst 1614b/8 mpu 0b overhead 0b level 0
Sent 559018700 bytes 75324 pkt (dropped 0, overlimits 0 requeues 0)
<span class="bold"><strong>rate 299288bit</strong></span> 3pps backlog 0b 0p requeues 0
lended: 53963 borrowed: 21361 <span class="bold"><strong>giants: 90174</strong></span>
tokens: -26688 ctokens: -14783</pre><p>В приведенном примере легко обнаружить две проблемы:</p><div class="orderedlist"><ol type="1"><li><p>Скорость (299288) заметно превышает установленный предел
(230000).</p></li><li><p>Сообщается о большом числе огромных пакетов (90174).</p></li></ol></div><p>Эта неполадка устраняется выключением "checksum offloading" в domU с
помощью программы <span class="command"><strong>ethtool</strong></span>. За инструкциями обратитесь к
<a class="ulink" href="XenMyWay-Routed.html" target="_self">статье по Xen</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="External"></a>Применение собственных сценариев tc</h2></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="owntcstart"></a>Замена встроенного файла tcstart</h3></div></div></div><p>Если вы предпочитаете сами создать файл запуска tc, просто
поместите его в /etc/shorewall/tcstart.</p><p>В сценарии tcstart вместо вызова программы “<span class="quote">tc</span>”
используйте функцию run_tc из Shorewall, чтобы при ошибке tc остановить
файрвол.</p><div class="orderedlist"><ol type="1"><li><p>Задайте TC_ENABLED=Yes и CLEAR_TC=Yes</p></li><li><p>Укажите сценарий /etc/shorewall/tcstart с правилами управления
трафиком.</p></li><li><p>Укажите также необязательный сценарий /etc/shorewall/tcclear
для остановки управления трафиком. Обычно это не требуется.</p></li><li><p>Если сценарий tcstart применяет классификатор
“<span class="quote">fwmark</span>”, то можно помечать пакеты, используя записи из
/etc/shorewall/tcrules.</p></li></ol></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Start"></a>Управление трафиком, внешнее по отношению к Shorewall</h3></div></div></div><p>Для того чтобы запустить управление трафиком при поднятии сетевых
интерфейсов, необходимо запустить сценарий управления трафиком именно в
этот момент. Это зависит от применяемого дистрибутива и здесь не
описывается. После этого сделайте следующее:</p><div class="orderedlist"><ol type="1"><li><p>Задайте TC_ENABLED=No и CLEAR_TC=No</p></li><li><p>Если сценарий применяет классификатор “<span class="quote">fwmark</span>”,
то можно помечать пакеты, используя записи из
/etc/shorewall/tcrules.</p></li></ol></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Testing"></a>Инструменты тестирования</h2></div></div></div><p>Как минимум один пользователь Shorewall посчитал полезными следующие
инструменты: <a class="ulink" href="http://e2epi.internet2.edu/network-performance-toolkit.html" target="_self">http://e2epi.internet2.edu/network-performance-toolkit.html</a></p></div></div></body></html>
