TCP / IPリセット（RST）フラグが送信される原因は何ですか？

私のアプリのTCP / IP接続が10分ごとに（正確には、1〜2秒以内に）中断し続ける理由を理解しようとしています。Wiresharkを実行したところ、10分間何も操作しないと、相手側がリセット（RST）フラグが設定されたパケットを送信していることがわかりました。グーグル検索は私に「リセットフラグはレシーバーが混乱しているので接続を中止したいことを示します」と私に告げますが、それは私が必要とする詳細の少し不足しています。何が原因でしょうか？そして、途中のいくつかのルーターがそれを担当している可能性はありますか、またはこれは常に他のエンドポイントからのものですか？

編集：私のコンピューターと他のエンドポイントの間にルーター（特にLinksys WRT-54G）が設置されています-ルーターの設定で確認すべきことはありますか？

「ルーター」は何かをしている可能性があります-特にNATは、バグに覆われたトラフィックをいじくり回している可能性があります...

デバイスがRSTを送信する1つの理由は、閉じたソケットのパケットの受信に応答することです。

起こり得るあらゆる不正行為は、TCPの開始以来見られており、あらゆる種類の人々がRSTを挿入してトラフィックをブロックしようとしている可能性があるため、確固たる一般的な答えを出すのは困難です。（たとえば、いくつかの「国のファイアウォール」はこのように機能します。）

ピアでもパケットスニファ（Wiresharkなど）を実行して、RSTを送信しているのがピアであるか、途中で誰かであるかを確認します。

この問題のトラブルシューティングにかなりの時間を費やしました。提案された解決策はどれも機能しませんでした。私たちのシステム管理者が誤って、同じグループに属しているが同じネットワーク上にある2つの無関係なサーバーに同じ静的IPを割り当てていることがわかりました。最終結果は、断続的に切断されたvnc接続、Webページを取得するために数回更新する必要があったブラウザー、その他の奇妙なものでした。

RSTは、最後のACKを送信する側であるため、アクティブクローズを行う側によって送信されます。したがって、誤った状態でパッシブクローズを実行する側からFINを受信した場合、エラーが発生したことを相手側に示すRSTパケットを送信します。

一部のファイアウォールは、接続がx分間アイドル状態の場合にそれを行います。一部のISPは、さまざまな理由でルーターを設定するように設定しています。

この時代には、その状態を適切に処理する（必要に応じて再確立する）必要があります。

NATを実行しているルーター、特にリソースが少ないローエンドルーターがある場合、最も古いTCPセッションが最初にエージングされます。これを行うにRSTは、パケットにフラグを設定し、受信ステーションに接続を（非常に不規則に）閉じるように効果的に指示します。これは、リソースを節約するために行われます。

注意すべきことの1つは、多くのLinux netfilterファイアウォールが正しく構成されていないことです。

次のようなものがあれば：

-A転送-m状態--state関連、確立-j ACCEPT

-A転送-p tcp -j REJECT --reject-with tcp-reset

パケットの並べ替えを行うと、ファイアウォールがパケットを無効と見なし、リセットを生成して、正常な接続を切断する可能性があります。

並べ替えは、ワイヤレスネットワークで特に発生する可能性があります。

これは代わりに：

-A転送-m状態--state関連、確立-j ACCEPT

-A転送-m状態--state無効-jドロップ

-A転送-p tcp -j REJECT --reject-with tcp-reset

基本的にはいつでも：

... -m state --state RELATED、ESTABLISHED -j ACCEPT

直後に続く必要があります：

... -m state --state INVALID -j DROP

パケットをドロップしてから、プロトコルを中断させる可能性のあるTCPリセットを生成することをお勧めします。リセットは、送信するのに間違いない場合に適しています。これにより、タイムアウトが解消されます。しかし、それらが無効である可能性がある場合は、この種の痛みを引き起こす可能性があります。

これは、ネットワークにRSTをTCP接続に送信する別のプロセスがあるためです。

通常、RSTは次の場合に送信されます

• SO_LINGERオプションを使用したソケットが有効な場合、プロセスはソケットを閉じます
• ソケットを閉じずにプロセスが終了すると、OSはリソースのクリーンアップを実行しています。

あなたの場合、プロセスが接続（IP +ポート）を接続していて、接続を確立した後もRSTを送信し続けるようです。