iptables DROPターゲットを使用すると、ソケットCLOSE_WAITが完了しませんか？
ハッカー/スパマーが頻繁に使用する特定のIPブロックをブロックするための簡単なルールがいくつかあります。例：
iptables -A INPUT -s 173.208.250.0/24 -j DROP
しかし、Apacheが数日後にハングし、netstatの出力に多くのCLOSE_WAITが表示されて消えることがないことに気づきました。
# netstat -atlpn
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 1 0 ::ffff:10.0.0.107:80 ::ffff:173.208.250.123.50813 CLOSE_WAIT 29125/httpd
これは、ルールでDROPターゲットを指定したことが原因である可能性がありますか？代わりにREJECTを使用する必要がありますか？
これは、ルールでDROPターゲットを指定したことが原因でしょうか？
番号。
代わりにREJECTを使用する必要がありますか？
番号。
INPUTチェーンのそのルールのDROPターゲットは、Apacheが最初のSYNパケットまたはその送信元アドレスを持つパケットをまったく認識しないことを意味します。接続を確立しないと、CLOSE_WAIT状態になることはありません。状態図を参照してください ウィキペディアから 以下：
ご覧のとおり、CLOSE_WAITは、確立されたセッションの後でのみ発生し、クライアントがセッションの終了を開始した場合にのみサーバー上で発生します。キープアライブを使用すると、クライアントまたはサーバーの1つがタイムアウトに達し、セッションをアクティブに閉じるまで、セッションは開いたままになります。
サーバーがこのタイムアウトに達してセッションを閉じるのは一般的であり、サーバーはTIME_WAIT状態で多くの接続を使用することになります。デフォルトでは2分間この状態になりますが、問題が発生することはめったにありません。 TIME_WAIT接続（Linuxの場合）はIPとポートの組み合わせを拘束しますが、TIME_WAIT状態で約30,000の接続が確立されるまで、それらが不足することはありません。
ルールの送信元アドレス範囲が、例のCLOSE_WAIT状態のIPアドレスと一致しません。
REJECTは、接続をすぐに閉じることができるために何らかの理由で接続を受け入れることができない場合に礼儀正しい人々に使用するのは礼儀正しいですが、ハッカー/スパマーの場合は礼儀正しい必要はありません。設定したタイムアウトを待つようにします。
では、何がCLOSE_WAIT状態で接続を引き起こす可能性がありますか？クライアントはFINを送信し、サーバーはFIN/ACKで応答して、最後のACKを待ちます。その最後のACKを受信しなかった場合は、Apacheの再起動など、他の何かが発生するまでそこに留まります。
他のコード（ハードウェアファイアウォールなど）での接続状態の追跡が不適切な場合、クライアント側での問題と同様に、これが発生する可能性があります。何があなたの特定の問題を引き起こしているのかわかりませんでした。