☰

Telnetが存在しないポートを直接拒否せずにタイムアウトするのはなぜですか？

tag-icon • tag-icon telnet tcp-ip
Telnetが存在しないポートを直接拒否せずにタイムアウトするのはなぜですか？ 
telnet 8.8.8.8 8888

見せる

頑張って...

もともとこれは完全に拒否されると予想していました。

背景：NGINXリバースプロキシサーバーがある場合は、バックエンドがないかどうかを直接検出するので、これは非常に良いです。

答え1

リモートエンドが再送信する内容によって異なります。

どのプロセスもリッスンしていないポートの場合、リモートエンドはリセット（RST）ビットが設定されたパケットを送信し、これによりクライアントに「接続が拒否されました」エラーが発生します。もう1つの可能性は、iptables -j REJECTLinuxからデフォルトで送信されるようなICMP「ポートに接続できません」というメッセージです。これにより、「接続が拒否されました」も発生します。

一方、リモコンが再送信した場合何もないすると、クライアントは問題が何であるかを知ることができず、再試行するか、長時間待つことができます。

iptablesLinuxの例：

# iptables -I 入力 -p tcp --dport 3001 -j 拒否
# iptables -I 入力 -p tcp --dport 3002 -j 削除

$NC -v 127.0.0.1 3000
nc：127.0.0.1ポート3000への接続に失敗しました（tcp）：接続が拒否されました。

$NC -v 127.0.0.1 3001
nc：127.0.0.1ポート3001（tcp）への接続に失敗しました：接続が拒否されました。

$NC -v 127.0.0.1 3002
（待つ…）

したがって、バックエンドがダウンしていることを確認するには、誰かがエラーを再送信する必要があります。もちろん、ホスト全体がダウンしている場合はこれを行うのが難しくなる可能性があるため、より短いタイムアウトをスケジュールする必要があるかもしれません。

答え2

TCPスタックは、一連の規則（おそらくファイアウォールレベルで）に基づいて接続に応答する方法を決定します。接続パケット（SYN）を拒否できますが、削除することもできます。たとえば、ポートスキャンのために削除するのは妥当です。

関連情報