これらはどのようなtcアクションですか？
トラフィック制御アクション（以下、単に「アクション」と呼びます）は、トラフィック制御サブシステムのフィルターの拡張機能です。 これらの拡張機能は、最も単純なドロップパケットからトラフィック自体の変更まで、さまざまなニーズに必要です。 アクションは別のフィルターに付加されるため、選択したトラフィックでのみ操作が実行されるため、柔軟性が向上します。 さらに、パイプを介してアクションのチェーン全体を構築できます（コンソールでデータをパイプライン化するなど）。 操作は、着信トラフィックと発信トラフィックの両方で実行できます。
まず、インターフェイスにクラスまたはクラスレスの規律を追加する必要があります。アクション付きのフィルターは既に追加されています。 着信トラフィックをモックしたい場合は、着信規律を追加する必要があります。 その際立った特徴は、そのハンドルが常に「ffff：」であり、常にクラスレスであることです。
当然、適切なモジュールをカーネルに含める必要があります。 それらは、ネットワーキングサポート-ネットワーキングオプション-QoSおよび/または公平なキューイングブランチにあります。 使用するアクションに含まれるアクションオプションとモジュールが必要です。 ディストリビューションカーネルでは、通常、すべてがすでに含まれています。
アクションを使用する最も簡単な例
フィルタの構築を簡素化するために、ラベルを使用して操作するトラフィックを選択します。 この方法は、発信トラフィックにのみ適しています。 なぜそう Linuxネットワークスタック上のパッケージパスを示すこの写真を見てみましょう。 ご覧のように、入ってくるパッケージの規律と分類はnetfiterフックよりもはるかに早く行われるため、パッケージを先にマークする場所がありません。 この場合、分類のために、たとえばU32を使用して、他の基準に従ってフィルターを構築するのが理にかなっています。 この問題を回避する別の方法は、トラフィックを別のインターフェイスにリダイレクトすることです。
アクションを適用する最も単純な例を見てみましょう。 確かに、多くの人がすでに彼に会っています。 いわゆるポリサーを使用して、特定のタイプのトラフィックの帯域幅制限について説明します。 ポリサーは、現在のバケットのアルゴリズムに従って機能します（このアルゴリズムについては、 WikipediaまたはTanenbaumで読むことができます）。
IPアドレス192.168.10.3からアドレス192.168.10.5へのtcpプロトコルの着信トラフィックの速度を制限するとします。 これは次のように実行できます。
# # tc qdisc add \ dev eth0 \ ingress # # tcp # 192.168.10.3/32 # 192.168.10.5/32 tc filter add \ dev eth0 \ parent ffff: \ pref 10 \ protocol ip \ handle ::1 \ u32 \ match ip protocol 6 0xff \ match ip src 192.168.10.3/32 \ match ip dst 192.168.10.5/32 \ action police \ rate 2Mbit burst 200K exceed-conform drop
最後の2行は、私たちにとって最大の関心事です（他の行が明確でない場合は、U32フィルターについてLARTCを読んでください）。
- アクションポリス-フィルタトラフィックがポリサーによって処理されることを示します。 次に、ポリサーオプションがあります。
- レート2Mビットバースト200K-帯域幅を2メガビット/秒に設定します。 「バースト200K」は、ポリサーの正しい動作に必要なパラメーターの1つです。 他のパラメーターもありますが、それらは考慮しません。
- 超過適合ドロップ-「バケットのエッジをオーバーフロー」するパケットに対するアクションを定義します。この場合、それらは破棄されます。 2メガビットバンドに分割されるパケットはスキップされます。
たとえば、両方のマシンでiperfを実行し、速度を測定します。 すべてが正しく行われた場合、192.168.10.3から192.168.10.5までの速度は2メガビットの領域になります（これは、テストデータ以外のノード間で何も送信されない場合です）。 統計では、フィルターを通過したデータの量、機能した回数、スキップおよびドロップされたパケットの数などを確認できます。
~$ iperf -s -p 10500 ------------------------------------------------------------ Server listening on TCP port 10500 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 4] local 192.168.10.5 port 10500 connected \ with 192.168.10.3 port 59154 [ ID] Interval Transfer Bandwidth [ 4] 0.0-11.2 sec 2.73 MBytes 2.04 Mbits/sec ~$ tc -s -pf ls dev eth0 parent ffff: filter protocol ip pref 10 u32 filter protocol ip pref 10 u32 fh 800: ht divisor 1 filter protocol ip pref 10 u32 fh 800::1 \ order 1 key ht 800 bkt 0 terminal flowid ??? \ (rule hit 2251145 success 4589) match IP src 91.193.236.62/32 (success 5843 ) match IP dst 91.193.236.44/32 (success 4608 ) match IP protocol 6 (success 4589 ) action order 1: police 0x1e rate 2000Kbit burst 200Kb mtu 2Kb \ action drop overhead 0b ref 1 bind 1 Action statistics: Sent 6870220 bytes 4589 pkt (dropped 761, overlimits 761 requeues 0) backlog 0b 0p requeues 0
他のアクションも同様に使用されます。 各アクションについて、パラメーターに関する小さなヘルプを呼び出すことができます。 たとえば、同じポリサーの場合、これは次のコマンドで実行できます。
tc filter add \ dev eth0 \ parent ffff: \ u32 \ match u32 0 0 \ action police \ help Usage: ... police rate BPS burst BYTES[/BYTES] [ mtu BYTES[/BYTES] ] [ peakrate BPS ] [ avrate BPS ] [ overhead BYTES ] [ linklayer TYPE ] [ ACTIONTERM ] Old Syntax ACTIONTERM := action <EXCEEDACT>[/NOTEXCEEDACT] New Syntax ACTIONTERM := conform-exceed <EXCEEDACT>[/NOTEXCEEDACT] Where: *EXCEEDACT := pipe | ok | reclassify | drop | continue Where: pipe is only valid for new syntax
他のアクションのヒントを得るには、「ポリス」ではなく単に名前を示します。
アクションの短いリスト
現在、次のアクションがカーネルに含まれています。
- police-前述のように、速度制限のためにポリサーの機能を実装します。
- gact-汎用アクション-パッケージのスキップ、ドロップ、再分類などを可能にします。 このアクションを使用して、ファイアウォールの外観を実装できます。
- mirred-この拡張機能を使用すると、パケットを他のネットワークインターフェイスにミラーリングまたはリダイレクトできます。 着信トラフィックを平滑化（シェーピング）するために、IFBインターフェースと組み合わせて広く使用されています。
- ipt-iptablesターゲット-マーキングなどのiptablesアクションをパッケージに適用できます。 この場合、フィルターがイングレスディシプリンにアタッチされている場合、これはマングルプレルーティングチェーンのアクションにほぼ対応します。
- nat-ステートレスnat-ステートレスネットワークアドレス変換を実装します。 つまり ヘッダーのIPアドレスを別のものに変更するだけです。
- pedit-パケット編集-その助けを借りて、パケット内の個々のビットとバイトを変更することが可能です。 そのアプリケーションの例は後ほどです。
- skbedit-パッケージが保存されているsk_buf構造体のフィールドを変更できます。 主に優先度を変更するために使用されます。
- csum-チェックサム更新-チェックサムを再計算し、パケットヘッダーの値を更新します。 通常、peditで使用されます。
アクションの連鎖
アクションは個別に適用することも、一緒に適用してチェーンを形成することもできます。 これはすべて、あるプログラムの出力が別のプログラムの入力に送られる場合のコンソールでのデータのパイプライン化に似ています。 アクションはまったく同じです。 たとえば、パッケージヘッダーの一部のフィールドを変更してみてください。 その後、チェックサムを再カウントして更新する必要があります。 このために、peditとcsumは一緒に連鎖されます。 わかりやすくするために、結果のパケットをifb0インターフェイスにミラーリングし、tcpdumpで確認します。
tc filter add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ handle ::1 \ u32 \ match ip protocol 6 0xff \ match ip src 10.10.20.119/32 \ match ip dst 10.10.20.254/32 \ match u16 10500 0xffff at 22 \ action pedit \ munge offset 22 u16 set 11500 \ pipe \ action csum \ tcp \ pipe \ action mirred \ egress mirror dev ifb0
チームはかなり威圧的に見えます。 開始に精通しています-送信元および宛先アドレス、プロトコル、ポート番号（プロトコルtcp、ip src 10.10.20.119、ip dst 10.10.20.254、tcp dport 10500）で必要なパッケージを選択するためにフィルターを追加します。 ただし、分類する代わりに、パケットの内容（「アクションpedit」パラメーター）を変更します。これは、ipパケットの先頭から22バイトのオフセットにある単一のワードです。 ヘッダーの形式を見ると、このフィールドはtcpの受信ポート番号に対応しています。 それを上書きして、11500に設定します（ "munge offset 22 u16 set 11500"）。 ただし、フィールドを変更すると、ヘッダーのチェックサムが変更されます。 再計算するには、「パイプ」パラメーターを使用してパケットをcsumアクションにリダイレクトします。 Csumはtcpヘッダーのチェックサムを再カウントし、pipeパラメーターも使用して、mirredアクションにパケットをルーティングします。 「ミラーリング」アクションの結果、送信されたパケットのコピーがifb0インターフェイスに届きます。
ifb0インターフェイスでtcpdumpを実行するだけでなく、統計を分析して、すべてがどのように機能するかを確認しましょう。
# ~$ tc -s -pf ls dev eth0 filter parent 1: protocol ip pref 10 u32 filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 10 u32 fh 800::1 order 1 key ht 800 bkt 0 terminal flowid ??? (rule hit 102554 success 0) match IP protocol 6 (success 102517 ) match IP src 10.10.20.119/32 (success 0 ) match IP dst 10.10.20.254/32 (success 0 ) match dport 10500 (success 0 ) action order 1: pedit action pipe keys 1 index 66 ref 1 bind 1 installed 132 sec used 132 sec key #0 at 20: val 00002cec mask ffff0000 Action statistics: Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 action order 2: csum (tp) action pipe index 29 ref 1 bind 1 installed 132 sec used 132 sec Action statistics: Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 action order 3: mirred (Egress Mirror to device ifb0) pipe index 79 ref 1 bind 1 installed 132 sec used 132 sec Action statistics: Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 # tcp 10.10.20.254:10500 ~$ telnet 10.10.20.254 10500 # , # ifb0 ~$ tcpdump -nvvi ifb0 tcpdump: WARNING: ifb0: no IPv4 address assigned tcpdump: listening on ifb0, link-type EN10MB (Ethernet), capture size 65535 bytes ... 00:46:11.080234 IP (tos 0x10, ttl 64, id 46378, offset 0, flags [DF], proto TCP (6), length 60) 10.10.20.119.36342 > 10.10.20.254.11500: Flags [S], cksum 0x2001 (correct), seq 1542179969, win 14600, options [mss 1460,sackOK,TS val 1417050539 ecr 0,nop,wscale 4], length 0 ... # ~$ tc -s -pf ls dev eth0 filter parent 1: protocol ip pref 10 u32 filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 10 u32 fh 800::1 order 1 key ht 800 bkt 0 terminal flowid ??? (rule hit 580151 success 12) match IP protocol 6 (success 579716 ) match IP src 10.10.20.119/32 (success 12 ) match IP dst 10.10.20.254/32 (success 12 ) match dport 10500 (success 12 ) action order 1: pedit action pipe keys 1 index 66 ref 1 bind 1 installed 747 sec used 454 sec key #0 at 20: val 00002cec mask ffff0000 Action statistics: Sent 888 bytes 12 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 action order 2: csum (tdp) action pipe index 29 ref 1 bind 1 installed 747 sec used 454 sec Action statistics: Sent 888 bytes 12 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 action order 3: mirred (Egress Mirror to device ifb0) pipe index 79 ref 1 bind 1 installed 747 sec used 454 sec Action statistics: Sent 888 bytes 12 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0
基本的に、アクションの適用について伝えたかったのはこれだけです。
便利なリンク
LARTC -Linuxの高度なルーティングとトラフィック制御。
ifbとmirredアクションの使用例 。