web-dev-qa-db-ja.com

tcとiptablesを使用したLinuxルーターのShapeDropbox

LAN上の別のマシンがDropboxにアップロードしていて、インターネット接続のアップロード帯域幅を飽和させています。それが起こったとき、8.8.8.8へのpingは3000-6000msかかります。ドロップボックスが私のpingを8.8.8.8にアップロードしていないときは45ミリ秒です。

LinuxルーターのDropboxとの間で転送されるトラフィックの速度を落とし、優先順位を下げようとしています。

私は2つのわずかに異なるガイドを試しましたが、どちらも成功していません。混乱を招く要因の1つは、Dropboxのトラフィックが1〜2分ごとに速くなったり遅くなったりするように見えることだと思います。 Dropboxのアップロードを実行しているマシンにアクセスできないため、トラフィックが数分間高く、次に数秒間低く、振動している理由がわかりません。多分それは多くのファイルをアップロードしていて、各ファイルの間に一時停止があります。

オンラインの3つのわずかに異なるガイドに基づいて3回試行しました。

1:30が最も優先度の低いトラフィッククラスであると理解しています。これがDropboxに求めているものです。

更新：これを少し調整して、自分のコンピューターから実行したダウンロードを作成しました。律速は期待通りに機能しました。ただし、アップロードをテストする必要があります。

試行1

#!/bin/bash
tc qdisc add dev br0 root handle 1:0 htb default 1
tc class add dev br0 parent 1:0 classid 1:30 htb rate 64kbps ceil 128kbps prio 0
tc filter add dev br0 parent 1:0 prio 0 protocol ip handle 30 fw flowid 1:30
iptables -I FORWARD -t mangle -s 162.125.0.0/16,199.47.216.0/22,108.160.160.0/20,205.189.0.0/24,64.124.102.192/29,209.99.70.0/24,45.58.64.0/20,208.185.144.160/27 -j MARK --set-mark 30
iptables -I FORWARD -t mangle -d 162.125.0.0/16,199.47.216.0/22,108.160.160.0/20,205.189.0.0/24,64.124.102.192/29,209.99.70.0/24,45.58.64.0/20,208.185.144.160/27 -j MARK --set-mark 30

iptables-save -c関連するトラフィックがマークされていることを示します

[145:212599] -A FORWARD -d 162.125.0.0/16 -j MARK --set-xmark 0x1e/0xffffffff
[72:2880] -A FORWARD -s 162.125.0.0/16 -j MARK --set-xmark 0x1e/0xffffffff

試行2

#!/bin/bash
#tc qdisc add dev br0 root handle 1: htb
#tc class add dev br0 parent 1: classid 1:30 htb rate 32kbps ceil 64kbps
#tc filter add dev br0 parent 1: prio 0 protocol ip handle 30 fw flowid 1:30
#iptables -I FORWARD -t mangle -s 162.125.0.0/16,199.47.216.0/22,108.160.160.0/20,205.189.0.0/24,64.124.102.192/29,209.99.70.0/24,45.58.64.0/20,208.185.144.160/27 -j MARK --set-mark 30
#iptables -I FORWARD -t mangle -d 162.125.0.0/16,199.47.216.0/22,108.160.160.0/20,205.189.0.0/24,64.124.102.192/29,209.99.70.0/24,45.58.64.0/20,208.185.144.160/27 -j MARK --set-mark 30

試行3

tc qdisc add dev br0 root handle 1: htb default 1
#Second add a class (bucket) with bandwidth restrictions
tc class add dev br0 parent 1: classid 1:30 htb rate 512kbit
#Then add a filter to force packets through the class
tc filter add dev br0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:30
iptables -I FORWARD -t mangle -s 162.125.0.0/16,199.47.216.0/22,108.160.160.0/20,205.189.0.0/24,64.124.102.192/29,209.99.70.0/24,45.58.64.0/20,208.185.144.160/27 -j MARK --set-mark 0x1
iptables -I FORWARD -t mangle -d 162.125.0.0/16,199.47.216.0/22,108.160.160.0/20,205.189.0.0/24,64.124.102.192/29,209.99.70.0/24,45.58.64.0/20,208.185.144.160/27 -j MARK --set-mark 0x1
traffic-shapingqostchtb
1
Josh

トラフィックのダウンロード側で機能するようになった場合は、構成は適切です。トラフィックシェーピングは、出力トラフィックに対してのみ機能します。これは、シェーピングがインターフェイスの送信バッファを制御し、受信側（入力トラフィック）に影響を与えないためです。

考えられる解決策は2つあります。1つは [〜＃〜] ifb [〜＃〜] （リンクされた投稿に記載）を使用するか、別のインターフェイスで出力シェーピングを構成する（クライアントに面していない） ）。 2番目のポイントを明確にするには：

Clients <=> (download limit) [Server] (upload limit) <=> [Edge router]

図のように、さまざまなインターフェイスにダウンロードとアップロードの制限を適用して、「サーバー」のトラフィックを形成します。アップロードされたデータは、クライアントの2番目のインターフェース（非対面）への出力トラフィックです。

同様の投稿は次のとおりです： post1 、および post2 。

1
Khaled