rawソケットの仕組みを学ぶ方法として、TCP宛先ポートに基づいてパケットをドロップするダミーのファイアウォールをプログラミングしました。これは動作していますが、問題は、タイムアウトに達するまでかなりの時間クライアントが再試行することです。TCP RSTパケットは接続タイムアウトを短縮できますか？
回答が得られない可能性があるので、おそらくクライアントが長く再試行するのかどうか疑問に思っていました。その場合、ファイアウォールがクライアントからのTCP SYNCメッセージにTCP RSTと返信する場合に役立ちますか？そうでない場合は、クライアントが再試行を停止するように強制する方法がありますか？（Linuxのタイムアウト時間を短縮しないで、パケットを特定の回答を得てクライアントを停止させます）
あなたのファイアウォールは、ホストOS上でポートが閉じられているのと同じケースと考えることができます。ホストOSのTCP/IPスタックは何をしますか？
RFC 793は（オリジナルのTCP RFC）この場合について言って以下た：
接続（CLOSED）が存在しない場合、リセットは別のリセットを除くすべての受信セグメントに応答し 送られます。 では、存在しない接続にアドレス指定されたSYNはこの手段で拒否されます。
TCP RFCを読み、TCP RSTパケットがこの場合の要件に準拠していることを確認する必要があります。不正なRSTはクライアントによって無視されます。
RFC 1122は、コード2-4を含むICMP Destination Unreachableが接続を中止する必要があることを示しています。コード2-4
これらはハードエラー条件があるので、TCPはSHOULD、 - 接続を中止するために
宛先到達不能にならない（MUST NOT）としては0、1、および5が表示されているので、コードを注意することが重要です接続を中止します。
問題は、チェックサムにエラーがあったためにTCP RSTが正しく作成されなかったことでした –
ファイアウォールが正しく動作しています。攻撃者に情報を開示しないという情報セキュリティの基本原則です。 RSTを送信すると、ホストが存在することが明らかになります。
15〜20年前にファイアウォールが発生しましたが、ぼやけていました。最近、彼らはあなたのように振る舞います。ただパケットを落として、何も返答しません。
クライアントがレスポンスがない場合は、数回リトライするのが普通ですが、コメントで言われていたこととは逆に、クライアントは「接続が拒否されました」とすぐに断念します。 RST。応答がまったくない場合にのみ再試行します。
パケットに応答すると、クライアントにファイアウォールが存在することがわかります。このため、ファイアウォールはしばしば応答しないように設定されています。 –
わかりましたが、私はちょうどTCPについてもっと学びたいと思っていました。私はRSTメッセージを送り返しているが、何も起こっていないので、間違って構築されているか、これがTCPの通常の動作であるかどうかはわかりません。 –
私はクライアントに 'RST' 。 「RST」は、会話中の予期しないメッセージを示す。クライアントは新しい会話を開始しようとしているので、多くのクライアントが再試行すると思います。ほとんどの場合、送信したいのは、[ICMPの宛先到達不能パケット]（https：// en。wikipedia.org/wiki/ICMP_Destination_Unreachable）。 –