0

iptables を有効にして、2.6.16 カーネルで Debian を実行しています。システムはカスタムメイドの HTTP プロキシを実行しており、負荷は軽度です (他のサイトでは同じ負荷で問題なく動作します)。このシステムは、4 つの ISA 2004 マシンのアレイが先行する仮想 IP を持つロード バランサーが先行する 4 つのサーバーで構成されるため、基本的なトポロジは次のようになります。

クライアント -> ISA [1-4] -> ロード バランサー -> 当社のプロキシ [1-4] -> インターネット

ISA が SYN パケットを送信することがありますが、SYN-ACK は送信されていません。3 秒後に再試行し、さらに 6 秒後に 3 回目の試行を行った後、プロキシがダウンしていることを報告し、直接接続に切り替えます。この間、つまりこれら 3 つの SYN の前、間、および後に、同じ ISA からの他の SYN が来て、正常に応答されます。

非常によく似た問題が他の人から報告されています (ただし、解決策はありません)。

すべては、CentOS と呼ばれる Linux のフレーバーから来ています。その特徴は、デフォルトで iptables が有効になっていることです。

http://www.linuxhelpforum.com/showthread.php?t=931912&mode=linear http://www.centos.org/modules/newbb/viewtopic.php?topic_id=16147

ほとんど同じですが、少し異なります: http://www.linuxquestions.org/questions/linux-networking-3/tcp-handshake-fails-synack-ignored-by-system.-637171/

また、関連しているようです： http://groups.google.com/group/comp.os.linux.networking/browse_thread/thread/b1c000e2d65e0034

iptables が原因であると思われますが、追加のフィードバックがあれば歓迎します。

4

2 に答える 2

2

あなたが投稿した最初のリンクに記載されているように、listen 呼び出しの 2 番目のパラメーターを見てください。保留中の (まだ受け入れられていない) 接続の最大数です。listen(2) のマニュアル ページによると、プロトコルが再送信をサポートしている場合 (TCP はサポートしています)、キューがいっぱいになると接続要求が破棄されます (キューに十分なスペースがある場合に接続を作成する再送信を期待します)。 ）。

于 2008-10-19T15:45:06.340 に答える
0

実際、INVALID パケットを破棄するルールを使用していた iptables が犯人であることが判明しました。なぜ iptables がこれらの SYN を無効であると判断したのかはまだわかりません (ドロップの少なくとも 30 分間前に同じ送信元ポートのトラフィックがなかったため、TIME_WAIT は確実ではありません)。

于 2008-10-23T14:07:02.933 に答える