Как ограничить скорость, отдельным зарвавшимся IP, с помошью TC

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

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

anc Вы не поняли, хотелось бы ограничить скорость клиенту в моей сети на сервере (роутере) много лет назад я это делал, убей не помню какие инструменты использовал

Вы же вроде ссылки привели, я их внимательно не читал, но наискосок похоже на правду.

Ох и витиеватый вы anc, понять иногда сложно, мне. Правда что?

Это не возможно средствами TC? Все это делается для того чтоб рулить исходящим трафиком? Все раздают «Кино»

Тогда вопрос, как провайдер мне зарезает скорость? И как я, в качестве провайдера, могу зарезать скорость своему клиенту в своей локальной сети?

Тогда вопрос, как провайдер мне зарезает скорость?

Мануал версия лайт: «а как робит dos”? Искренне надеюсь, что такая аналогия понятна.

«а как робит dos”?

DOS давно не робит.

4.2

И CP/M такой молодой..

Еще один ребусмен, что сие цифры и буквы значат? Не эту Ось я уже не застал.

Вот схема прохождения трафика

Входящий трафик - это трафик который приходит на интерфейс и который обрабатывается в ingres qdisc.

Входящий трафик можно шейпить либо через ifb интерфейс средствами tc, либо через imq средствами iptables+tc (но требуется патчить ядро)

Шейпить входящий трафик для клиентов без nat просто - через ifb интерфейс.

Шейпить входящий трафик для клиентов за nat-ом - очень не простая задача, т.к. информация о реальном адресе клиента есть в conntrack, который работает позже чем обработка ingres. IМHO возможно только с помощью imq

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

Это пункт правил, если ты не знал :)

FeeeDOS до сих пор используется для прошивкок разной фирмвари.

Качальщики - это кто? Процессы, контейнеры (netns), виртуалки?

От этого сильно зависит что делать.

Качальщики - это кто? Процессы, контейнеры (netns), виртуалки?

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

FeeeDOS до сих пор используется для прошивкок разной фирмвари.

Точно, но я уже давно не пользовался.

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

Если ты им отдаёшь трафик, значит это исходящий трафик, а его шейпить просто.

Первый пример очень специфический - маркировка в prerouting по --sport. Нафига это нужно - непонятно.

Если там использовать "-d", то работать не будет, т.к. mangle/prerouting до nat (смотри схему). Это можно сделать в mangle/forward или mangle/postrouting, т.к. эти данные будут использоваться в egress qdisc.

Использовать iptables нужно только в том случае, когда трабуется ограничивать с точностью порта/протокола.

Если просто для ip, то достаточно средств tc/filter.

Если просто для ip, то достаточно средств tc/filter

Только для IP, есть какой то пример более менее простой, я уже понял, что не осилю я мануал по TC, старый/тупой…. если только где то кто то разжевал.

Извините может не в тему.

Я лет 20 назад делал такое … но на : /etc/sysconfig/cbq пример там же … и вроде не сложно было.

Я лет 20 назад делал такое …

:-)))) да я вот тоже лет 20 назад делал, не помню даже на чем, хорошая память у вас, спасибо гляну.

Нет в Федорке у меня такого пакета, а статьи по настройке и ведут к 2003 году :)))

Тут сорри, но у меня в CentOS 7x это есть …

uname -r 3.10.0-1160.92.1.el7.x86_64

P.S. обычно у Шапки адекватные доки, вот может поможет : https://access.redhat.com/documentation/ru-ru/red_hat_enterprise_linux/9/html/configuring_and_managing_networking/linux-traffic-control_configuring-and-managing-networking

ничего, вантузятники до сих пор живут со слешем не в ту сторону и главное богомерзкими дисками Цэ Дэ ПТНХ.

ну не от того что он ДОС а для прямого доступа к железу. Но таки да, используется конечно.

Если просто для ip, то достаточно средств tc/filter.

А вот это не то ли, что я хочу? https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.ratelimit.single.html

Если речь не про dos, а именно про трафик, то ограничить можно, пусть и с оговорками. См. lartc

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

Но пакеты таки пришли.

пусть и с оговорками

Вот именно, «с оговорками».

Но скорость таки установилась на желаемом уровне

Смотри чуть дальше первого впечатления

Приблизительно «на желаемом».

Именно. А ты говорил - «невозможно». Понятно, что это не твоя тема, но зачем уверенно говорить глупости?

А ты говорил - «невозможно».

Потому что невозможно. Я могу лить поток udp и мне плевать принял клиент или нет, лить я продолжу.

Можешь. Но скорость передачи данных по этому потоку в итоге не превысит установленного лимита

Современные приложения, использующие udp, тоже так или иначе контролируют переданные данные и, сюрприз, тоже не будут тупо слать наудачу и снизят скорость

Вот! Зависит уже от приложения, но не от роутера.

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

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

Схемка:
сервер -> роутер -> клиент
1. Cервер льет тупой поток без подтверждения со скоростью 20/Mbit
2. На роутере мы режем клиенту скорость до 10/Mbit
Вопрос: Сервер от этого перестал лить со скоростью 20/Mbit ?

Ты пытаешься говорить про dos (про который я сразу сказал - не сработает) и про какие-то вырожденные случаи отправки данных без вообще проверки получения. В реальной жизни так не бывает

И в любом случае, клиент в такой схеме получит именно установленный лимит 10 мбит/с, что и требовалось

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

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

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

Ещё раз: хватит. Ты несешь бред на тему, в которй слабо разбираешься

Вам принесли 1Кг картошки, вы говорите мне не нужно 1Кг картошки, но вам их УЖЕ принесли.

Иди и носи картошку. На это твоих знаний хватит

Если речь не про dos, а именно про трафик, то ограничить можно, пусть и с оговорками. См. lartc

Вы про это? https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.ratelimit.single.html Попробовал, вроде скорость и снижает, но что то как то никакими 512 кбит и не пахнет. 191 Mbits/sec было, а стало 23.7 Mbits/sec (на 22 порту щупаю iperf)

Я тут мимокрокодил: https://github.com/aabc/ipt-ratelimit
Всё хочу попробовать, но руки не доходят.

Что то написано вроде и под Centos 7 работать должно (у меня шляпа 34) но ничего не нашел.

Только цеплять эти правила нужно к ingress https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.adv-qdisc.ingress.html

Как цеплять я так и не допру никак и примеров никаких не нашел. Спасибо

там прямо написано:

Attach it like this

Если ограничить Исходящий трафик то входящий сам ограничится. Компы в локалке просто Не отвечают!

там прямо написано:

:)) нет ну я не настолько туп чтоб скопипастить не смог, но одной этой команды мало, надо еще что то писать, а вот тут я баран бараном. Нашел какие то примеры но тольку, очень мало. Понимающим просьба не смеяться, я никак не могу вьехать в этот TC увы

tc qdisc add dev eth1 root
tc qdisc add dev eth1 ingress

tc qdisc add dev eth1 root handle 1: cbq avpkt 1000 bandwidth 100mbit
tc class add dev eth1 parent 1: classid 1:1 cbq rate 512kbit allot 1500 prio 5 bounded isolated
tc filter add dev eth1 parent 1: protocol ip prio 16 u32 match ip dst 172.16.1.150 flowid 1:1