iptablesはループバック時にtcp-resetを拒否します
ネットワーク障害が発生した場合にソフトウェアがどのように動作するかを確認しようとしています。そのソフトウェアは、tcp send()とrecv()を使用して通信しています。
以前は、LANネットワーク上の2つの異なるマシンにソフトウェアを配置して、ソフトウェアを通信させていました。したがって、ネットワーク障害をシミュレートするために、以下のルールを使用していました。
Sudo iptables -A INPUT -p tcp -s 10.100.52.234 -j REJECT --reject-with tcp-reset
10.100.52.234がいずれかのシステムのIPであると仮定しましょう。これは一瞬で失敗につながりました。すべてうまくいっています。
現在、ループバックアドレス127.0.0.1を使用して、1台のマシンでこれをシミュレートしようとしています。すべてが前のセットアップと同じように機能していますが、上記のコマンドは機能していません。ネットワーク接続に障害はなく、ソフトウェアがハングするだけです。通信は発生していませんが、失敗することもありません。
コマンドを使用しました
Sudo iptables -A INPUT -p tcp -s 127.0.0.1 -j REJECT --reject-with tcp-reset
そして
Sudo iptables -A INPUT -p tcp -i lo -j REJECT --reject-with tcp-reset
両方とも機能していません。ソフトウェアが失敗するまでには非常に長い時間がかかります。
ループバックアドレスの接続をすぐに失敗させる別の方法はありますか？
私はあなたの結果を再現しました（私のsshdがリッスンしている間に127.0.0.1へのSSH接続を試みました）。ソフトウェアがハングするのは事実です。
ソフトウェアは応答またはエラーメッセージを待っていると思いますが、エラーメッセージは同じルールに該当し、拒否されます。エラーメッセージの連鎖反応があるかどうかはわかりませんが、ここまで調査していません。そもそも間違えるかもしれないので、もっと説明があれば喜んで読んでいきます。
これが私のDebianで機能する解決策です：
127.0.0.2（ ここでの説明 ）に接続し、次のようにルールを作成する必要があります。
Sudo iptables -I INPUT 1 -p tcp -d 127.0.0.2 -j REJECT --reject-with tcp-reset
-I INPUT 1フラグメントに注意してください。これにより、ルールが最初の位置に挿入され、ループバックインターフェイスにすでにあるACCEPTルールよりも優先されます（Debianの場合と同様）。
テストを繰り返しました（SSH接続を試みて、今回は127.0.0.2に）。すぐに失敗しました
Connection refused
エラーメッセージは127.0.0.1宛てであり、拒否ルールに捕らえられず、合格できないため、希望どおりに機能すると思います。