web-dev-qa-db-ja.com

Iptables、NAT：複数のIPを使用することにより、IPあたりのリクエストの最大数の制限を回避します

私のネットワークには、ファイアウォールを越えたサーバーに向けてhttpリクエストを行わなければならないマシンがあります。

このマシンのIPアドレス（ファイアウォールの向こう側から見た場合）は、約5つのアドレスのプールから選択できます。

すべてのIPは、1日あたり最大数のリクエストを実行できます。その後は、翌日まで再度使用することはできません。1日の制限がない限り、2つのリクエスト間の時間間隔は関係ありません。到達。

クライアントマシンから、それらの間の時間間隔を気にせずにhttp要求を行うことができるように、ファイアウォールのルーティングテーブルを構成したいと思います。私の唯一の懸念は、1日の合計制限（つまり、ipsの数* ipあたりの最大リクエスト数）です。

私は次のようなことを試しました：

iptables -m hashlimit -m tcp -A POSTROUTING --syn --hashlimit-name x --hashlimit <MAX REQUESTS>/day -p tcp -s <CLIENT IP> -d <SERVER IP> --dports 80 --to-source <ONE OF THE IPs TO CHOOSE FROM>

そして、5つのIPすべてに対してそのコマンドを繰り返しました（それ以上の接続試行をドロップする最終ルールを使用）。

しかし、この構成では、リクエストをバーストで実行することはできません。たとえば、MAX_REQUESTSが9000の場合、ハッシュ制限モジュールは平均を処理し、パケット数が指定された平均を超えるとすぐにルールの一致を停止するため、最初の2分間で9000要求を行うことはできません。したがって、この構成では、そのipを9.6秒ごとに1回だけ使用できます（= 86400/9000）。必要なものではありません。

だから私は、リクエストをバーストで実行し、1日の制限内にとどまることができる可能性のあるiptablesルール（または他の何か）についての提案を求めています。

御時間ありがとうございます

シルヴィオ

EDIT：--hashlimit-burst Nを使用しようとしましたが、このパラメーターは最初のNパケットの許容値のみを挿入します。つまり、平均に関係なくルールに一致するNパケットを追加し、その後は通常の条件が適用されます。繰り返しますが、私が望むものではありません。

[〜＃〜] update [〜＃〜]：私が使用している現在の候補iptableコマンドは

iptables -m hashlimit -m multiport -m tcp -A POSTROUTING -t nat --syn --hashlimit-name NAME --hashlimit MAX_REQUEST/day -p tcp -s SOURCE_IP -d DESTINATION_IP --dports 80 -j SNAT --to-source ONE_OF_THE IPs

それでも上記の問題があります（パケットをバーストで送信できません）。

iptablesnatconnections
1
Silvio Donnini

厳密に制御するために、次のようなことを試してみます。

iptables -t nat -A POSTROUTING -s INT_SRC -d EXT_SERVICE --syn --limit MAXREQ/day -j SNAT --to-source EXT_IP1
...

（それなら、あなたがすでに試したことだと思います：p）

使用はどうですか：

iptables -t nat -A POSTROUTING -s INT_SRC -d EXT_SERVICE --syn -j SNAT --to-source EXT_IP_RANGE

どうやらそのバリアントは単純なラウンドロビンアルゴリズムを使用しているようです-私はそれを試してみます。私はあなたの外部IPが単一の範囲にあることを願っています:)

それ以上のリクエストを自分で失敗させることはできませんか？あなたが非常に特定の要件を持っていることを考えると、私はおそらく：

  • ルールに--logを追加します
  • その日に行われたサービス接続の数を追跡し、そのサービスへの接続をさらにドロップするルールをFORWARDに挿入するデーモンを作成します。
  • デーモンにそのルール（存在する場合）を深夜に削除させ、接続カウントをリセットさせます

あなたがやりたいことを正確に処理するためにすでに存在するものは何もないようです。

2
MikeyB