Linux ограничение скорости интернета

Обновлено: 05.07.2024

Этот мануал поможет вам легко ограничить пропускную способность сети и сформировать сетевой трафик в Unix-подобных операционных системах.

Ограничивая использование полосы пропускания сети, вы можете сэкономить ненужное потребление трафика приложениями, такими как менеджеры пакетов (pacman, yum, apt), веб-браузеры, торрент-клиенты, диспетчеры загрузки и т. д.

И предотвратить злоупотребление полосой пропускания одним или несколькими пользователями в сети.

Для решения этого вопроса мы будем использовать утилиту командной строки Wondershaper.

Поверьте мне, это не так сложно, как вы думаете.

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

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

Другими словами, Wondershaper ограничит пропускную способность сети только в вашей локальной системе, а не в других системах в сети.

Эта утилита в основном предназначена для ограничения пропускной способности одного или нескольких сетевых адаптеров в локальной системе.

Надеюсь, ты понял.

Он ограничивает команду tc iproute на пропускную способность, но значительно упрощает ее работу.

Установка Wondershaper

Перейдите в каталог wondershaper и установите его как показано ниже:

И запустите следующую команду, чтобы автоматически запускать службу wondershaper при каждой перезагрузке

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

Wondershaper доступен в AUR, поэтому вы можете установить его в Arch-based системах, используя вспомогательные программы AUR, такие как Yay.

На Debian, Ubuntu, Linux Mint:

В RHEL, CentOS, включите репозиторий EPEL и установите wondershaper, как показано ниже:

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

Использование

Сначала найдите имя сетевого интерфейса.

Вот несколько распространенных способов найти информацию о сетевой карте.

Когда вы найдете имя сетевой карты, вы можете ограничить скорость полосы пропускания, как показано ниже:

Например, если имя вашей сетевой карты enp0s8 и вы хотите ограничить пропускную способность до 1024 Кбит / с для скачивания и 512 кбит / с для загрузки, команда будет следующая:

Чтобы снять ограничения с сетевого адаптера, просто выполните:

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

Если вы установили Wondershaper путем клонирования репозитория GitHub, в каталоге /etc/conf.d/ существует конфиг с именем wondershaper.conf.

Убедитесь, что вы установили скорость загрузки или скачивания, изменив соответствующие значения (имя сетевой карты, скорость загрузки / выгрузки) в этом файле.

Разделение, ограничение и управление трафиком - актуальная и сложная задача,
которую обычно возлагают на дорогостоящее специальное сетевое оборудование. Но
решить ее можно и с помощью подсистемы Linux-ядра Traffic Control, не
уступающей по возможностям Cisco IOS.

Допустим, существует офис некой компании X, и в нем числится около ста
сотрудников, каждый из которых может выходить в интернет через шлюз. Скорость
внешнего канала составляет 100 Мбит. Системный администратор справился с
настройкой шлюза в силу своих способностей – что и посчитал достаточным для
правильного функционирования сети. К чему это привело? К увольнению
недальновидного (или ленивого) админа.

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

Краткий сценарий

Решение проблемы: разделение канала между сотрудниками с ограничением
скорости! Сеть будет функционировать на "5+", если каждый сотрудник получит в
распоряжение отдельный канал, скорость которого будет составлять 1 Мбит. Тогда
отдельно взятый интернет-пользователь не сможет занять больше причитающейся ему
доли и отобрать часть канала у других. С точки зрения компании, это еще и
отличный способ экономии (после разделения канала оказывается, что его суммарная
пропускная способность даже излишне высока) и ведения статистики по трафику для
отдельно взятого сотрудника.

Обычно для разделения канала с ограничением скорости используются возможности
операционной системы IOS, на которой функционирует сетевое оборудование Cisco
(дешевые решения от других производителей, таких, как Dlink, Trendnet и Netgear,
вообще не обладают такой возможностью). Однако особой необходимости тратить
баснословные суммы на аппаратные шлюзы от Cisco нет. Ядро Linux уже более пяти
лет как содержит в себе код сложной и весьма функциональной подсистемы
управления трафиком Traffic Control, которая по некоторым параметрам даже
обходит IOS.

Подсистема Traffic Control

Подсистема Traffic Control поддерживает множество методов
классификации, приоритезации, разделения и ограничения трафика (как исходящего,
так и входящего). Она очень гибка в настройке, но сложна в понимании. Поэтому мы
уделим значительную часть статьи теоретическому материалу и лишь затем приступим
к решению задачи с помощью HTB – одной из наиболее гибких и популярных дисциплин
Traffic Control.

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

Shaping. Шейпинг - ограничение трафика, задержка пакетов с
целью создания желаемой скорости передачи. Может использоваться не только для
"сужения" исходящего канала, но и для сглаживания бросков во время пиковых
нагрузок.
Scheduling. Планирование – упорядочивание типов трафика в
канале. Позволяет избегать задержек для критичных типов трафика (QoS).
Policing. Политика входящего трафика. Позволяет ограничить
входящий трафик путем уничтожения превысивших лимит пакетов. Помогает бороться
с DDoS.

Отметим, что ограничение без потерь возможно только в отношении исходящего
трафика. Стек протоколов TCP/IP не предусматривает возможности заставить
удаленную сторону слать пакеты медленнее (и это правильно).

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

Дисциплина обработки пакетов (qdisc) - очередь пакетов и
закрепленный за ней алгоритм обработки.
Класс (class) - логический контейнер, который может
содержать несколько подклассов или дисциплину.
Фильтр (filter) - механизм классификации трафика.

В простейшем варианте путь пакета от приложения до удаленного конца
соединения выглядит так. Приложение генерирует (пользуясь услугами библиотек и
ядра) сетевой пакет и отдает его ядру, которое помещает пакет в очередь FIFO
(первым пришел, первым ушел). Драйвер сетевой карты время от времени обращается
к специальному алгоритму ядра, который извлекает из очереди пакет и отдает его
драйверу. Далее пакет уходит к адресату. Все просто.

Linux действует таким же образом. Но формат представления очереди и алгоритм
ее обработки, в совокупности называемые дисциплиной обработки пакетов, в нем
заменяемы! По умолчанию используется дисциплина pfifo_fast, реализующая очередь
FIFO. Пользуясь утилитой tc, администратор может заменить ее на другую
дисциплину, которая будет переупорядочивать пакеты (планирование), задерживать
их на определенное время (шейпинг) или выполнять другие действия.

Дисциплины классов

Traffic Control не был бы столь гибким, если бы не позволял разбивать
трафик на классы с помощью классовой дисциплины и набора ее подклассов.
Схематически классовая дисциплина очень похожа на файловую систему, c тем лишь
исключением, что ее корень или классы (каталоги) могут содержать либо дисциплину
(файл), либо подклассы (подкаталоги). Одно из двух. Классовые дисциплины и
классы предназначены для построения дерева выбора. Сначала весь трафик
разбивается на несколько общих классов (например, трафик до Отдела-1, трафик до
специализированных внутренних серверов и т.д.), а затем каждый из них
разбивается на несколько подклассов (например, трафик до DNS-сервера Отдела-1),
за которыми уже могут быть закреплены дисциплины.

Чтобы управлять тем, дисциплиной какого класса будет обработан определенный
тип трафика, классовые дисциплины позволяют подключать к себе фильтры. Это дает
возможность "завернуть" определенный трафик в один из ее подклассов. Фильтры
используют классификаторы для идентификации пакетов нужного типа и как бы
говорят ядру: "Этот вид трафика должен обрабатываться с помощью дисциплины вот
этого класса". Существует несколько разных классификаторов. Самыми популярными
являются u32 и fw. Первый позволяет выделять пакеты по исходящим адресам и
адресам назначения, портам, парам "хост:порт", типам протокола и типу сервиса.
Второй классифицирует пакеты путем чтения маркировок, записанных брандмауэром
iptables/netfilter (цель MARK).

За каждым сетевым интерфейсом должны быть закреплены две особые дисциплины:
корневая дисциплина (root qdisc) и входящая дисциплина (ingress qdisc). В первую
помещается весь исходящий трафик (по умолчанию используется дисциплина
pfifo_fast). Во вторую - входящий.

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

Утилита tc

Для конфигурирования подсистемы управления трафиком предназначена утилита tc
из пакета iproute2. Она принимает набор команд в качестве аргументов, с помощью
которых можно создавать классы, привязывать к ним дисциплины и добавлять
фильтры. Синтаксис ее похож на синтаксис команды ipfw из операционной системы
FreeBSD, так что знакомые с ним быстро освоятся.

Для примера рассмотрим простейший вариант использования:

Эта команда устанавливает ограничение для всего исходящего трафика в 256
Кбит/с. Разберем подробнее все аргументы tc:

qdisc add - добавляем новую дисциплину (для удаления используй del).
dev eth0 - указываем устройство, к которому будет привязана дисциплина.
root - наша дисциплина корневая (будет обрабатываться весь трафик).
tbf - имя дисциплины.
rate 256kbit latency 50ms burst 1540 - параметры, специфичные для данной
дисциплины: rate - ограничение скорости, latency - максимальный "возраст"
пакета в очереди, burst - размер буфера.

Проще говоря, команда подключает дисциплину tbf в качестве корневой на
интерфейсе eth0 и задает ей несколько параметров. Token Bucket Filter (TBF) -
это бесклассовая дисциплина, которая передает поступающие пакеты с заданной
скоростью.

Способ указания скоростей и других величин в утилите tc несколько отличается
от общепринятого, поэтому следующую табличку придется запомнить:

Формат указания скорости в утилите tc

mbps = 1024 kbps = 1024 * 1024 bps => Байт/с
mbit = 1024 kbit => Кбит/с
mb = 1024 kb = 1024 * 1024 b => Байт

Заменить стандартную корневую дисциплину на любую бесклассовую совсем
несложно, но на таком коне далеко не уедешь. Для создания разветвленной системы
управления трафиком нужны классовые дисциплины, классы, фильтры и целое дерево
дисциплин. Чтобы настроить все это, может понадобиться не один десяток команд.
Мы рассмотрим несколько вводных примеров, перед тем как перейти к обсуждению
дисциплины HTB.

Пример дерева дисциплин

Подключим дисциплину prio в качестве корневой и назначим ей имя (дескриптор)
"1:0":

Результат этой команды: дисциплина prio, подключенная в качестве корня, и три
класса (1:1, 1:2 и 1:3) внутри нее, к каждому из которых подключена дисциплина
FIFO.

Мы вольны заменить любую из дисциплин, подключенных к классам, чем и
воспользуемся для подключения дисциплины sfq с дескриптором "10:0" к классу
"1:1":

Это обеспечит справедливое разделение канала между интерактивными
приложениями (они имеют наивысший приоритет). Чтобы остальные приложения, такие
как менеджеры закачек и torrent-клиенты (которые обычно шлют пакеты с меньшим
приоритетом в поле TOS), не мешали интерактивным, ограничим для них скорость:

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

Теперь сделаем так, чтобы весь SSH-трафик имел наивысший приоритет. Для этого
закрепим за корневой дисциплиной prio фильтр, который будет перенаправлять
пакеты с портом назначения 22 в дисциплину класса "1:1".

Рассмотрим подробнее механизм подключения фильтров.

filter add - Добавляем фильтр.
dev eth0 - Указываем устройство.
parent 1:0 - Дескриптор родителя.
protocol ip - Протокол, с которым будет работать фильтр.
prio 1 - Присваиваем классифицированному трафику приоритет 1 (наивысший).
u32 - Используемый классификатор.
match ip dport 22 0xffff - Параметры классификатора. В данном случае
указание отбирать пакеты с портом назначения 22.
flowid 1:1 - Отфильтрованные пакеты должны иметь класс "1:1" и
обрабатываться с помощью его дисциплины.

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

Классовая дисциплина HTB

Еще в первый релиз системы Traffic Control была включена классовая
дисциплина CBQ (Class-Based Queue), предназначенная для реализации сложных
систем управления и ограничения трафика. CBQ завоевала большую популярность
благодаря своей гибкости, но была очень сложна, запутана и обладала рядом
ограничений (тут и необходимость заранее указывать максимальную пропускную
способность канала, и неэффективный алгоритм шейпинга).

Поэтому в скором времени появилась более эффективная и простая в
использовании альтернатива под названием HTB (Hierarchical Token
Bucket). Классовая дисциплина HTB предназначена для разделения полосы
пропускания между различными видами трафика, каждому из которых может быть
предоставлена полоса гарантированной ширины. Она не обладает гибкостью CBQ, но
гораздо более проста в настройке и лишена ее недостатков. Именно на HTB сегодня
принято строить сложные и эффективные системы ограничения трафика.

Рассмотрим применение HTB на примере, представленном в начале статьи, но
более усложненном. Допустим, у нас есть шлюз на Linux, интерфейс eth1 которого
смотрит наружу, а eth0 - во внутреннюю сеть. Ширина канала - 100 Мбит. Задача:
разделить канал между сотрудниками компании так, чтобы директор и сотрудники
IT-отдела могли выходить в интернет без скоростных ограничений, маркетологи
получили ограничение в 2 Мбит/c каждый, менеджеры - 1 Мбит/c, секретари - 512
Кбит/c, а все остальные - 256 Кбит/c.

Есть два варианта решения. Первый: составить огромную таблицу IP-адресов и
создать специальные правила ограничений для каждого адреса (с точки зрения
системы HTB это будет выглядеть как огромный набор классов и фильтров, по одному
на каждый адрес). Второй: разбить всех потребителей канала на мета-группы,
каждую из которых выделить в отдельную подсеть (директор и IT-отдел -
172.16.1.0, маркетологи - 172.16.2.0, менеджеры - 172.16.3.0, секретари -
172.16.4.0, остальные - 172.16.5.0). Для каждой подсети назначить суммарное для
всех ее членов ограничение со справедливым разделением канала.

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

Для начала создадим работоспособную систему, основанную только на втором
варианте решения задачи. Подключим дисциплину HTB в качестве корневой:

Опция "default 15" говорит о том, что весь неклассифицированный фильтрами
трафик должен быть обработан с помощью дисциплин класса "1:15". Создадим
корневой класс, под который будет попадать весь трафик (это нужно для реализации
заимствования):

Создадим в нем пять подклассов для пяти наших подсетей. Директору и IT-отделу
выделим 30-мегабитный канал с возможностью его расширения (заимствования) вплоть
до 100 Мбит в случаях, когда остальные каналы не заняты:

Для маркетологов выделим 20-мегабитный канал:

Менеджерам – 10 Мбит/с:

Секретарям – 5 Мбит/с:

И – 40 Мбит/с на всех остальных:

По умолчанию к вновь созданным классам подключены дисциплины, реализующие
очередь FIFO. Это нам не подходит. Чтобы канал равномерно распределялся между
всеми участниками подсети, мы должны подключить к ним дисциплину sfq:

Теперь подключим фильтры, которые будут классифицировать трафик:

Для "всех остальных" фильтр не нужен, потому как мы уже указали дефолтовый
класс неклассифицированного трафика.

Все, система будет работать, но не обеспечит жесткого ограничения для каждого
пользователя (если, например, в определенный момент времени интернетом будет
пользоваться только один менеджер, ему достанутся все 10 Мбит, отведенные для
всех менеджеров). Жесткое ограничение можно реализовать, если вместо дисциплин
подключить к классам другие классы HTB, по одному на каждого пользователя, и
создать соответствующие фильтры.

Для примера, установим ограничение в 256 Кбит/с для пользователя,
находящегося в подсети "все остальные". Сначала добавим к "классу-подсети" новый
"класс-пользователь":

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

В данной статье хочу рассказать, как я строил систему ограничения входящего и исходящего трафика в Linux.
Как и учет трафика, ограничение полосы пропускания в сети является очень важной задачей, хотя первое с каждым годом всё быстрее отходит на второй план, шейпинг трафика остается необходимой задачей каждого системного/сетевого администратора.

Какие есть способы ограничения трафика?

Для того, чтобы ответить на этот вопрос нужно определиться для чего этот трафик ограничивать вообще.
Взяв за основу мою сеть из, примерно, 50 рабочих мест, которые выходят в интернет через шлюз, под управлением ОС Ubuntu и некоторые из пользователей пользуются локальными ресурсами на этом сервере по протоколу SMB.
Моя цель ограничить пользователям скорость передачи данных в Интернет со справедливым разделением полосы пропускания между ними.

Исходя из моих задач, для ограничения полосы пропускания можно использовать следующие методы:
1. Ограничение с помощью прокси-сервера Squid.
Данный метод позволяет довольно гибко контролировать весь www,ftp трафик пользователей с возможностью гибкого ограничения скорости пропускания.
2. Использование traffic control из iproute2.
Очень гибкий и оптимальный метод ограничения трафика, но не предоставляющий контроля над WWW трафиком, как в предыдущем методе.
3. Конечно возможно ограничить скорость путём использования модуля –m limit для iptables – но считаю это неприемлемым.

В общем я решил остановиться на методе ограничения трафика с помощью пакета iproute2.

Что, где и как?

Как уже упоминал, я использую сервер: OS Ubuntu 10.04, ядро 2.6.32-30. В сервере 3 интерфейса: eth0 – внутренняя сеть, eth1 — провайдер 1, eth2 – провайдер 2.

Задача: ограничить скорость входящего и исходящего трафика пользователей с приоритезацией трафика по классам, исходя из некоторых условий. Локальный трафик не ограничивать.

Немного теории

Естественно, что при отсутствии системы ограничения трафика этот пользователь займёт весь канал и остальным пользователям не будет предоставлена нормальная скорость работы с Интернет. Но мы не может ограничить скорость отправки данных пользователем на внешнем интерфейсе сервера, т.к. для доступа пользователей в Интернет используется NAT, а, учитывая, что шейпинг трафика выполняется после преобразования адресов, то на внешнем интерфейсе сервера уже не будет пакетов с внутренними адресами сети.

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

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

Исходя из вышеизложенного, я ограничивал входящий к пользователю трафик на интерфейсе внутренней сети — eth0, а исходящий от пользователя трафик – на виртуальном интерфейсе ifb0.

Для того чтобы во время занятия пользователем всей полосы пропускания, ограниченной ему на шлюзе, для скачивания какого-нибудь большого объема данных и при этом мог нормально пользоваться ssh и чтобы у него работал ping – я использовал приоритезацию трафика.

icmp
udp,ssh
tcp sport 80
остальной неклассифицированный трафик

Дисциплины, классы, фильтры

Как уже было мной отмечено, входящий к пользователям трафик будет ограничиваться на интерфейсе eth0, а исходящий от пользователей – на виртуальном интерфейсе ifb0.

Для инициализации интерфейса ifb0 нужно сначала загрузить модуль управления интерфейсом:
/sbin/modprobe ifb
После успешной загрузки модуля нужно включить интерфейс:
/sbin/ip link set dev ifb0 up
Затем, после того, как интерфейс будет поднят, нужно организовать переадресацию всего исходящего трафика от пользователей на этот интерфейс:
/sbin/tc qdisc add dev eth0 ingress
/sbin/tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0
Теперь можно смело начинать строить классы и фильтры для входящего к пользователям трафика на интерфейсе eth0, а исходящего – на интерфейсе ifb0.

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

Ограничиваем входящий к пользователям трафик

Все манипуляции с трафиком будем проводить на интерфейсе eth0.

Для начала создадим корневой обработчик очереди на интерфейсе:
/sbin/tc qdisc add dev eth0 root handle 1: htb default 900

Тем самым мы привязали корневой обработчик очереди к интерфейсу eth0, присвоили ему номер 1: и указали на использование планировщика HTB с отправкой всего неклассифицированного трафика в класс с номером 900.

Затем создадим дочерний класс 1:1 с шириной канала, равной скорости интерфейса:
/sbin/tc class add dev eth0 parent 1: classid 1:1 htb rate 100Mbit burst 15k
Все последующие классы будут подклассами только что созданного нами класса. Это дает нам более точную приоритезацию и обработку скорости потока данных.

Создадим класс для локального трафика, адресом назначения или исходным адресом которого будет являться внутренний адрес сервера. Это нужно для удобства пользования ресурсами сервера, такими как SSH, SMB, FTP, WWW и так далее. Скорость, описанная классом – 50Mbit, но в случае, если скорость потока родительского класса не меньше 100Mbit, то разрешаем использовать 80Mbit, в качестве максимальной скорости передачи данных.
/sbin/tc class add dev eth0 parent 1:1 classid 1:10 htb rate 50Mbit ceil 80Mbit burst 15k

Далее создаем класс, скорость которого будет равно ширине полосы пропускания, которую нам предоставляет провайдер. В моем случае – это 15Mbit.
/sbin/tc class add dev eth0 parent 1:1 classid 1:100 htb rate 15Mbit burst 15k

Даже если провайдер предоставляет большую скорость, к примеру 18Mbit, я рекомендую снижать эту скорость для шейпера на 1-2 Mbit для более «мягкого» ограничения трафика.
Далее создадим класс, в который будут отправляться все пакеты данных, которые не попадут ни в один из созданных ранее классов.
/sbin/tc class add dev eth0 parent 1:1 classid 1:900 htb rate 56Kbit ceil 128Kbit

Для каждого пользователя я создавал отдельный подкласс, с выделенной полосой пропускания, а затем создавал подклассы этого класса для приоритезации трафика:
/sbin/tc class add dev eth0 parent 1:100 classid 1:101 htb rate 4Mbit ceil 6Mbit

Данной командой мы указали на создание класса с номером 1:101, который является подклассом класса с номером 1:100 и указали пропускную способность класса в 4Mbit, а в случае свободной полосу пропускания у родительского класса, разрешить максимальное прохождение данных по классу на скорости 6Mbit.

После создания классов пришло время создания фильтров, которые будут классифицировать трафик по определенным критериям.

Есть несколько способов классифицировать трафик.
Самые удобные из них – это u32 классификаторы, позволяющие классифицировать пакеты исходя из адреса назначения или отправителя, используемого протокола, номера порта и так далее, и классификаторы на основе меток iptables. Для использования последних необходимо сначала маркировать пакеты при помощи iptables в цепочке PREROUTING, на основе каких-либо условий, а затем при помощи tc направлять пакеты с соответствующей меткой в нужные классы.

Я предпочел использовать u32 классификатор.

Присваиваем icmp-трафику самый низкий приоритет и отправляем его в класс 1:102
/sbin/tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.10.78 \
match ip protocol 1 0xff flowid 1:102

UDP и SSH трафик отправляем в класс 1:103
/sbin/tc filter add dev eth0 protocol ip parent 1:0 prio 2 u32 match ip dst 192.168.10.78 \
match ip protocol 17 0xff flowid 1:103
/sbin/tc filter add dev eth0 protocol ip parent 1:0 prio 2 u32 match ip dst 192.168.10.78 \
match ip protocol 6 0xff match ip sport 22 0xffff flowid 1:103

WWW-трафик, пришедший с tcp-порта 80 отправляем в класс 1:104
/sbin/tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 match ip dst 192.168.10.78 \
match ip protocol 6 0xff match ip sport 80 0xffff flowid 1:104

Трафик, не соответствующий ни одному из условий отправляем в класс 1:105
/sbin/tc filter add dev eth0 protocol ip parent 1:0 prio 4 u32 match ip dst 192.168.10.78 flowid 1:105

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

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

Для ограничения исходящего от пользователей трафика выполняются такие же действия как и для входящего, только в ход идет виртуальный интерфейс ifb0. Также нужно изменить назначение следования трафика: вместо dst 192.168.10.78 – нужно указать src 192.168.10.78 соответственно.

Автоматизация и принцип работы скриптов

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

Файл представляет из себя поля, разделенный знаком табуляции либо пробелом со следующими значениями:
CLIENT – Имя пользователя. Нужно для удобства предоставления данных
IP – адрес пользователя в сети
DOWN – скорость потока данных к пользователю
CEIL – максимальная скорость входящего трафика к пользователю при доступности данной полосы у родительского класса
UP — скорость потока данных от пользователя
CEIL – то же, что и у CEIL для входящего трафика к пользователю
PROVIDER – какой из провайдеров используется для обслуживания запросов пользователя (при наличии нескольких)
ID – номер класса для пользователя. Подробнее о номерах классов ниже.
Также я использую несколько bash-скриптов.

TC="/sbin/tc"
DEV_P1_DOWN="eth0"
DEV_P1_UP="ifb0"

Далее код, который подгружается:

Классы

И фильтры:

Данные скрипты нужно положить в один каталог, Выполнить:

chmod +x ./rc.shape

Я описал один из методов ограничения трафика. Утилита tc – очень мощная вещь в вопросах об ограничениях трафика. Рекомендую ознакомиться с документом: LARTC-HOWTO для более глубокого изучения данного вопроса.

Как в Линуксе уменьшить скорость выхода (загрузки и отдача) в Интернет для отдельного IP ?

Если не ошибаюсь, это называется шейпинг

Читай про утилиту tc.

Скорость не уменьшает

Вот пример (там правда не по IP а по марке которая ставится через iptable).

Насколько я помню корневым правилом (1:1) резать канал нельзя, оно просто опысывает максимальную скорость на интерфейсе. Потом уже можно ее разделять по калсcам + нужно продекларировать очередь для класса на котором есть ограничение

Сделал как в вашем примере, но скорость осталась прежней:

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

tc class add dev $DEV parent 1: classid 1:50 htb rate 512Kbit prio 5 burst 1400

tc filter add dev $DEV parent 1: protocol ip prio 5 u32 match ip dst 192.168.1.136 flowid 1:1

tc qdisc add dev $DEV parent 1: sfq perturb 60

Может есть варианты через iptables урезать скорость для 192.168.1.136 по IP или MAC ?

192.168.1.136 стоит за NAT

Написать юнит для systemd?

А как замеряешь?

на роутере нет systemd

У вас чтото совсем не то написано

Вот это строчку:

tc class add dev $DEV parent 1: classid 1:1 htb rate 100Mbit prio 0

Удалять нельзя, это ROOT шейпера от которого нарезаются каналы

и wlan0 - это должен быть локальный интерфейс (WiFi)

zaz ★★★★ ( 28.12.17 21:25:33 )
Последнее исправление: zaz 28.12.17 21:26:52 (всего исправлений: 2)

Проверь лучше iperf-ом, у этих онлайн-измерителей свои приколы (яндекс как-то недавно заявлял, что скорость в районе 70, при том что подключение было через спутник и максимум, который можно было достичь — 2,6)

Пкетный фильтр FreeBSD ipfw и система ограничения пропускной способности dummynet были успешно портированы в Linux.

Установить IPFW на Linux и настройте PIPE

Теперь ограничение работает. СПАСИБО!

Ограничение скорости загрузки:

(для блокировки по MAC: tc filter add dev wlan0 parent 1: protocol ip prio 1 u32 match ether dst 6c:4e:36:68:a7:55 flowid 1:50)

Ограничение скорости отдачи:

(для блокировки по MAC: tc filter add dev ifb0 parent 1: protocol ip prio 1 u32 match ether src 6c:4e:36:68:a7:55 flowid 1:50)

Поставить еще squid. У него есть все средства для борьбы с наглыми узерами. Даже ограничение количества сессий.

Пример ограничения скорости в предыдущем моем посте не работает. Вот рабочий пример:

tc qdisc add dev wlan0 handle ffff: ingress tc filter add dev wlan0 parent ffff: protocol ip prio 50 u32 match ether src 00:1B:77:40:99:E2 police rate 2Mbit burst 12k drop flowid :1

Читайте также: