Времена узких интернет-каналов постепенно уходят в прошлое, но формировать сетевой трафик иногда все же необходимо.
В Linux для этого существуют соответствующие механизмы ядра и утилиты для управления механизмами.
Весь этот бизнес довольно сложен; обычно требуется не один день, чтобы понять формирование.
Хотя в простых случаях можно накопить тк заклинания из статей или найти скрипт, генерирующий эти заклинания.
Мне, как любознательному человеку, всегда было интересно, можно ли облегчить процесс настройки шейпинга для небольших сетей? Можно ли хотя бы примерно обнаружить важный трафик и отделить его от неважно без DPI и анализа сигнатур? Можно ли формировать трафик в любом направлении, не создавая псевдоинтерфейсы и не добавляя модули в ядро? И вот, немного подумав и погуглив, я решил написать простой шейпер в пользовательском пространстве.
Попытаться ответить на вопросы с помощью эксперимента.
Результат эксперимента был примерно таким: github.com/vmxdev/damper Это работает примерно так: При запуске создаются два потока программы.
В первом NFQUEUE перехватывает пакеты, они анализируются, каждому пакету присваивается «вес» (или приоритет) и сохраняется в приоритетной очереди.
Когда очередь заполнена, пакеты с низким приоритетом заменяются пакетами с высоким приоритетом.
Другой поток выбирает пакеты с наибольшим весом и помечает их для отправки.
Отправка происходит с ограниченной скоростью, поэтому собственно и происходит формирование.
Небольшой экскурс о механизме NFQUEUE
Этот механизм позволяет копировать сетевые пакеты в пространство пользователя для обработки.Приложение, прослушивающее соответствующую очередь, должно вынести вердикт по пакету (пропустить или отбросить).
Кроме того, допускаются изменения в упаковке.
Этот механизм используется IDS/IPS, например Snort или Suricata. Пакеты помечаются для обработки в iptables, целевой NFQUEUE. То есть мы можем выбрать любое направление (входящий трафик, исходящий трафик, транзит или, скажем, UDP с порта 666 на порт 13) и отправить его в шейпер.
Там пакеты будут проанализированы, возможно, переупорядочены, и в случае превышения лимита пакеты с самым низким приоритетом будут отброшены.
Первые рабочие версии шейпера захватывали пакеты, помещали их в очередь, а затем повторно вводили в необработанный сокет. На StackOverflow и некоторых других статьях пишут, что это единственный способ задержать пакеты перед пересылкой.
Конструкция сработала, но товарищ Вел объяснил, где можно задержать пакет прямо в NFQUEUE, упростили настройку шейпера.
Модули
Поскольку формирователь экспериментальный, я сделал его «модульным», а не монолитным.Каждый модуль рассчитывает вес посылки по разным критериям.
Из коробки имеется 4 модуля, но вы легко можете написать еще несколько.
Модули можно использовать вместе или по отдельности.
Модули:
- запретить_большие_потоки — подавляет большие потоки.
Чем больше байт передается между двумя IP-адресами, тем меньшим становится «вес» пакета.
То есть вероятность того, что пакет из большого тяжелого сеанса будет отброшен, увеличивается.
Информация хранится в кольцевом буфере, поэтому время от времени происходит амнистия (количество отслеживаемых сессий задается в конфиге), треды заменяются на более свежие
- отметка — вес упаковок устанавливается по марке.
iptables устанавливает бренд по некоторым критериям; для этих пакетов будет применен коэффициент, указанный в конфиге.
Вы можете вручную повысить или понизить приоритет некоторого отмеченного трафика.
- энтропия — вес рассчитывается в зависимости от энтропии (точнее, меры энтропии Шеннона) потока.
Поток идентифицируется номером протокола и адресами участников.
Для TCP/UDP также учитываются порты источника и назначения.
Чем выше энтропия, тем меньше вес.
Те.
мультимедийный, зашифрованный и сжатый трафик с большей вероятностью будет отброшен, чем другой трафик.
- И очень примитивный рандомный модуль — он просто добавляет случайности в процесс отбрасывания и переупорядочения пакетов (если использовать только этот модуль, то получится классический RED).
Получен полученный вес.
Статистика и графики
Шейпер умеет вести статистику и строить графики.В реальной жизни это выглядит так: dumper.xenoeye.com .
Зеленый — сколько байт/пакетов было пропущено, красный — сколько отброшено.
Диаграмму можно масштабировать/прокручивать.
Второй график (включается директивой «wchart yes» в конфигурации) показывает средние веса пакетов в секунду, нормализованные и с разбивкой по модулям.
Демо работает на не очень быстрых ARM (Scaleway bare metal, 32-bit ARMv7), иногда может немного подвисать.
Отладка
Модули Inhibit_big_flows и entropy имеют режим отладки, который включается в конфиге.В этом режиме модули сбрасывают текущие потоки с весами каждые N секунд. Кроме того, есть режим без ограничения скорости («ограничение нет» в конфиге).
В этом режиме все пакеты пропускаются (без анализа в модулях), но можно вести статистику прошлых пакетов/байт, помедитировать на графике загрузки канала, например.
Результаты
Шейпер оказался довольно простым (ну, на мой избитый взгляд).Для использования нужно выбрать направление формирования, добавить правило iptables, выставить в конфиге нужную скорость и запустить.
Тяжелые и высокоэнтропийные сессии выявляются и понижаются приоритеты, но чудес не бывает: если канал очень узкий, комфортного серфинга не получится.
На высоких скоростях и с большим количеством пользователей не тестировал, но на десятках мегабит и с несколькими пользователями субъективно получается лучше, чем без шейпера.
Хоть и нагружает ЦП, но это связано не только с использованием NFQUEUE, но и из-за общей корявости кода (и немного от особенностей clock_nanosleep()), его можно оптимизировать и оптимизировать.
Это, конечно, лишь доказательство концепций; код местами хаотичен и практически не доработан.
Если у кого-то есть мысли, пожелания или предложения по этому поводу, было бы интересно прочитать.
Теги: #Сетевые технологии #Системное администрирование #Конфигурация Linux #shaper #linux shaper #shaper #shaper в Linux
-
Вы Неправильно Пишете Животных
19 Oct, 24
