Linux iptables / conntrackパフォーマンスの問題

ラボで4台のマシンを使用したテスト設定があります。

• 2つの古いP4マシン（t1、t2）
• 1 Xeon 5420 DP 2.5 GHz 8 GB RAM（t3）Intel e1000
• 1 Xeon 5420 DP 2.5 GHz 8 GB RAM（t4）Intel e1000

過去数か月間に多数のシンフラッド攻撃に襲われて以来、Linuxファイアウォールのパフォーマンスをテストしました。すべてのマシンでUbuntu 12.04 64ビットが実行されます。t1、t2、t3は1GB / sスイッチを介して相互接続され、t4は追加のインターフェイスを介してt3に接続されます。したがって、t3はファイアウォールをシミュレートし、t4はターゲット、t1、t2は攻撃者にパケットストームを生成します（192.168.4.199はt4）。

hping3 -I eth1 --rand-source --syn --flood 192.168.4.199 -p 80

t4は、ゲートウェイとの混同、t4のパフォーマンスの問題などを回避するために、すべての着信パケットをドロップします。iptrafでパケット統計を監視します。ファイアウォール（t3）を次のように構成しました。

• ストック3.2.0-31-generic＃50-Ubuntu SMPカーネル
• rhash_entries = 33554432（カーネルパラメータとして）

• 次のようにsysctl：

  net.ipv4.ip_forward = 1
  net.ipv4.route.gc_elasticity = 2
  net.ipv4.route.gc_timeout = 1
  net.ipv4.route.gc_interval = 5
  net.ipv4.route.gc_min_interval_ms = 500
  net.ipv4.route.gc_thresh = 2000000
  net.ipv4.route.max_size = 20000000
  

（t1 + t2ができるだけ多くのパケットを送信しているときに、t3を実行し続けるために多くの調整を行いました）。

この取り組みの結果は少し変わっています。

• t1 + t2は、それぞれ約200kパケット/秒を送信します。最良の場合のt4は合計で200kであるため、パケットの半分が失われます。
• パケットが流れているにもかかわらず、t3はコンソールではほとんど使用できません（多数のsoft-irq）
• ルートキャッシュのガベージコレクターは、予測可能な状態に近くなく、デフォルト設定では、ごく少数のパケット/秒（<50kパケット/秒）に圧倒されます。
• ステートフルiptablesルールをアクティブ化すると、t4に到達するパケットレートが約100kパケット/秒に低下し、実質的に75％を超えるパケットが失われます

そしてこれ-これが私の主な関心事です-2台の古いP4マシンができるだけ多くのパケットを送信することで-これは、ネット上のほぼ全員がこれに対応できることを意味します。

だからここに私の質問があります：設定または私のテスト設定でいくつかのインポートとポイントを見落としましたか？特にsmpシステムでファイアウォールシステムを構築するための代替手段はありますか？

ルーティングキャッシュがなくなったカーネル3.6以上に移行します。それはあなたの問題の一部を解決するはずです。

T3でのロギングの設定はどうですか？ドロップされたすべてのパケットがログに記録されている場合は、ディスクI / Oが原因である可能性があります。

これはテスト環境なので、T3ログをオフにしてテストを試すことができます。