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

Сделала ограничение на скорость закачки по 443 порту с помощью iptables. Политика по умолчанию на все цепочки — ДРОП.
«Прореживаю» входящие пакеты, исходящие пускаю без ограничений — их мало, не мешают.

/sbin/iptables -A FORWARD -p tcp —sport 443 -m state —state ESTABLISHED \
-m limit —limit 100/minute —limit-burst 50 -j ACCEPT
/sbin/iptables -A FORWARD -p tcp —sport 443 -m state —state RELATED\
-m limit —limit 100/minute —limit-burst 50 -j ACCEPT

/sbin/iptables -A FORWARD -s «$clinet»0/24 -p tcp —dport 443 -j ACCEPT #без ограничений
/sbin/iptables -A FORWARD -p tcp —sport 443 -j DROP #бью, чтобы логи не засоряли

По идее что должно быть: видя потери пакетов, передающая сторона должна сжимать окно — замедлять скорость передачи, пока не установится равновесие и потери не минимизируются (медленный старт).

Смотрю, сколько пакетов (и мегабайт) дропается и пропускается. Примерно поровну! Равновесие почему-то не устанавливается, передающая сторона ничего и не думает замедлять. Это подтверждается и моими счетчиками скорости (и через iptables и через tc) — когда качают через 443 порт, дебет с кредитом не сходится, а так — все нормально.

Где тот медленный старт?! Ведь эти пакеты, предназначенные на убой, забивают нам канал, которого и без того не хватает.
Неужели это нормально?

Поскольку такой мехаизм используется во всех ограничителях тарфика, что же, добрая половина трафика в сети цеелнаправленно бьется, только никто этого не видит? Или это просто кривая реализация ТСП на каком-то конкретном сервере? Или я нерационально подобрала параметры ограничения (в особенности —limit-burst)?

Источник

IPtables как ограничить скорость

Есть несколько машин, которые ходят через нат с помощью такого правила
-A POSTROUTING -s 10.10.10.10 -d ! 111.111.111.26/255.255.255.240 -o eth0 -j SNAT —to-source 111.111.111.27
нужно ограничить скорость для этой машины.
Думаю, что нужно использовать критерий limit, но как, не понимаю 🙁
Если кто знает — подскажите пожалуйста.

Re: IPtables как ограничить скорость

Спасибо, и что? каким образом туда конкретный IP пристроить?

Re: IPtables как ограничить скорость

совершенно правильно понимаешь,
очень просто делается
. -m limit —limit число_пакетов_в_секунду . —jump чего делать
tc в твоем случае применять нет никакой необходимости, т.к.
iptables вполне нормально будет резать трафик по tbf.

Re: IPtables как ограничить скорость

Что то я не совсем понял, как ты собираешся по числу пакетов определить скорость ? Это первое, и каким образом оно будет трафик резать, причем там tbf ?

покажи пример, ато больше на ересь похоже..

Re: IPtables как ограничить скорость

как обычно — скорость = число_пакетов * AVG pkt size
а трафик будет резаться откидыванием пакетов. tbf это
метод, при помощи которого модуль limit регулирует скорость.

про ересь не заикайся даже, лучше rtfm:

iptables —append FORWARD -p icmp -m limit —limit 100 —jump ACCEPT

Re: IPtables как ограничить скорость

нууу. не путайте firewall и qos 🙂

limit просто отбрасывает «лишние» пакеты
tbf же их задерживает в буффере и отбрасывает только когда буффер заполняется.

Re: IPtables как ограничить скорость

есть одно «но» , отмечу что это мое мнение , основанное на моем понимании передачи пакетов в сети езернет . Значит так — если вы ограничите скорость , теблями , т.е. колво пакетов , допустим в 10 пакетов в секунду максимум , то предположим в идеале размер пакета 1500 байт то максимальная скорость будет 1500*10=15000 , тобишь примерно 15 кб , но , ситуации разные бывают , пакеты не всегда 1500 , они могут быть и меньше при большой нагрузке , то.е. например 1000 , уже бует 10 кб в сек ( это я как мог дословно объяснил ). Так что если вы хотите ограничит скорость — ограничивайте используя например скрипты htb.init или cbq.init , что бы не мучится с самостоятельным прописыванием правил . На если вам именно пакеты в сек — используйте иптеблес .

Почему я это тут сказал — из работы . Вывод этот сделан на основе показаний например iptraf . Т.е. если клиенту стоит 8 кб в сек , то имея у себя вирусную активность у него не 5 пакетов в секунду максимум как могло бы быть предположено а все 50-100 . И он еще позвонит и спросит — «хули у меня нэт тормазит !?» .

Поэтому те кто предлагает резать СКОРОСТЬ используя limit , т.е. резав пакеты — ОШИБАЕТСЯ , в идеале надо резать скорость клиенту используя tc , т.е. скрипты всякие , такие как htb.init , если клиентов дофига то проще скрипт заюзать . И ТАК ЖЕ надо зарезать максимальное количество (. ) пакетов используя ресурсы теблей . Мы пока не сделали этого , но пока оптимальный вариант — 20-30 пакетов в секунду для скорости 256 кбит .
Кстати это достаточно серьезно — клиенты-юзвери с достаточно прямолинейной логикой , если в флашгете написано что чем больше одновременных закачек ставить тем больше производительность канала и больший кпд и большая скорость . Он и ставит 100 одновременных сессий на скорости 256 кбит . Ну все зашибись — скорость у него 32 кб , по нашим графикам нагрузки канала . А вот пакетов у него больше 40-50 , при этом у него наблюдаются страшные тормаза с нэтом , закачка с ошибками и он еще и звонит и тоже спрашивает — что там за фигня у вас с нэтом , все качается с ошибками , так что лучше ему зарезать что бы ниче не качалось выше нормы =)

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

Источник

Traffic shaping using iptables and tc

Limiting outbound network bandwidth per client IP-address

Last month I received an automated alert indicating excessive bandwidth usage, usually a sign of trouble. When this happens, you should follow a standard incident procedure, trying to isolate the source of the traffic before shutting it down. The cause of this incident was not what I expected however. requiring a different kind of mitigation than a simple blockade.

Excessive bandwidth alert

When you manage servers you’ll notice that internet traffic usually occurs in predictable patterns. Just like real traffic on roads, there are regular times when it is busy and quite.

The predictable pattern makes it possible to detect anomalies automatically. Just like a traffic jam on a highway at an unusual time can be the result of an accident, unexpected swings in internet traffic can be an indicator for an incident in cyberspace.

Isolating the source

The first thing you should do is to find the source of the problem. Do this by analysing the anomaly by:

Determine if the extra traffic is inbound or outbound (up or download?)
Determine the associated source and target IP addresses (what server is affected? Where is the traffic going to or coming from?)
Determine the kind of traffic (email, web or something else?)

To do this you should inspect traffic charts, they usually indicate distinct input/output. Then you should try to find the affected IP addresses. This might involve looking at more (individual server) charts and statistics inside switches, routers and servers. Then look at CPU usage and log files to determine what application is affected, like mail or web. The larger the anomaly is, the easier it is to find.

You may be tempted to kill the anomaly once you have found it, immediately stopping the associated traffic. But you should really keep it alive (at least a little longer) to learn as much as you can from it.

Use a tool like iftop to see a realtime overview of bandwidth usage per connected IP-address. It is very useful to get a grasp of what’s going on, especially in combination with log files (linking IP-address to individual accounts).

Unusual cause

The server that produced the excessive bandwidth usage was a mail server. Often they are targeted by hackers to turn them into a spam relay server. This can happen in various ways, usually by the spammers capturing a valid login. This results in lots of outbound traffic as the spammers will push out many emails. If a spam run happens on your sever, you probably see this in the logs as spam messages frequently bounce, causing the mail queues to fill up quickly. It gets messy quickly, but on this server there was no such mess — just a lot of unusual bandwidth usage.

Mail (and spam) is sent using the SMTP protocol, but traffic on this server’s SMTP port was very normal. This was very unusual as it meant that the excessive traffic came from something else. But what? After analysing various logfiles on the mail server I determined that the offending protocol was IMAP. Somehow a client connected to the mail server using IMAP was causing excessive amounts of network traffic. IMAP is a protocol that is used to read email, not to send it, making IMAP related anomalies very rare.

By analysing the mail server’s log, I found the specific user that caused the traffic. I contacted the customer to ask if he noticed anything weird on his end. Not surprisingly, he noticed that his computer felt a little sluggish lately.

Microsoft Outlook synchronisation loop

After some trial and error by phone, we determined that something caused Microsoft Outlook to keep synchronising IMAP folders in a loop. This caused his computer to download the entire contents of his mailbox over and over again! As his mailbox was over 40 gigabyte in size, this caused the substantial traffic. Apparently this is caused by a bug in Microsoft Outlook, unfortunately there is no easy fix for it.

Mitigating by traffic shaping

I faced the difficult decision to either block the (normal, legitimate, paying) customer or to allow the excessive traffic to continue (incurring serious costs to the network provider). Blocking legitimate users that operate their business using email is a very bad idea, but allowing excessive traffic to continue is bad too. Luckily I found an alternative way to reduce the excessive traffic while still allowing the customer access to his mail (using his trusted, but flawed Outlook app).

Traffic Shaping

As a bandwidth management technique you can use traffic shaping to delay some (or all) data packets to bring them into compliance with a desired traffic profile. If applied, you are — quite literally — shaping the traffic graphs, hence the name.

This technique is not without controversy as it is quite the opposite of the often hailed «net neutrality» principle. With traffic shaping you can intentionally block or slow down (or charge extra money) for specific types of traffic. By principle I am against anything that hurts net neutrality, but for this particular situation I had no feasible alternative. I needed to seriously slow down email traffic for this particular customer, reducing the amount of bandwidth while continuing to provide access to his account.

Implementing traffic shaping

To shape traffic you need to do two things:

mark traffic: You only want to affect particular network traffic, in this case IMAP access for a given client. Other traffic should be unaffected. This is done by marking packets that match particular characteristics, such as client IP or port numbers
enforce shape policy: Using traffic control tools like ‘tc’ you then enforce the shaping policy on the marked traffic. There are different ways to do this, but a common one is to work with so-called «Hierarchy Token Buckets» or HTB’s.

Hierarchy Token Buckets (HTB’s)

In principle a token bucket is similar to the principle of limiting the amount of passengers in a train ride by only distributing a fixed number of available tokens. When passengers (or data packets) enter the train (or network) they take a token. When they disembark (or reach their destination) the token is returned. Using the token bucket principle you can control the amount of concurrent traffic in a system.

You can implement this principle using the network tools «tc» (for traffic control) in combination with «iptables». You can use a script to set the rules for marking and enforcing. You can find various samples online, I used this one by Julien Vehent.

Conclusion

Sometimes network anomalies are not what you expect them to be, therefore you should always take the time to investigate them! Blindly blocking traffic is blunt, sometimes you need to refine your methods to mitigate problems.

Applying unorthodox filtering techniques is not something that I like, but sometimes they are the only means to an end. Know what you’re doing and why you’re doing it is very important!

Did you enjoy this post?

If you found this content useful,
consider showing your appreciation
by buying me a coffee ❤️😋:

Источник