TCP / IPリセット（RST）フラグが送信される原因は何ですか？
アプリのTCP/IP接続が10分ごとに（正確には1〜2秒以内に）中断し続ける理由を把握しようとしています。 Wiresharkを実行したところ、10分間何も操作しないと、相手側がリセット（RST）フラグが設定されたパケットを送信していることがわかりました。グーグル検索では、「RESETフラグはレシーバーが混乱しているため接続を中止したいことを意味します」と表示されますが、それは私が必要とする詳細には少し足りません。これは何が原因ですか？そして、途中のいくつかのルーターがそれを担当する可能性はありますか、これは常に他のエンドポイントから来るのでしょうか？
編集：コンピューターと他のエンドポイントの間にルーター（具体的にはLinksys WRT-54G）があります-ルーターの設定で探すべきものはありますか？
「ルーター」は何でもできます-特にNATには、トラフィックにバグを乗せた大量の混乱が含まれる可能性があります...
デバイスがRSTを送信する理由の1つは、閉じられたソケットのパケットを受信したことです。
堅実ではあるが一般的な答えを出すのは困難です。考えられるすべての倒錯は、開始以来TCPでアクセスされており、あらゆる種類の人々がトラフィックをブロックするためにRSTを挿入している可能性があります。 （たとえば、いくつかの「国のファイアウォール」はこのように機能します。）
ピアでもパケットスニファー（Wiresharkなど）を実行して、RSTを送信しているのがピアであるか、中間の誰かであるかを確認します。
この問題のトラブルシューティングにかなりの時間を費やしました。提案されたソリューションはどれも機能しませんでした。システム管理者が誤って、同じ静的IPを異なるグループに属しているが同じネットワーク上にある2つの無関係なサーバーに割り当てていることが判明しました。最終結果は、断続的にvnc接続が切断され、ブラウザがWebページを取得するために数回更新する必要があり、その他の奇妙なものでした。
一部のファイアウォールは、接続がx分間アイドル状態になっている場合にこれを行います。一部のISPは、さまざまな理由からルーターを設定します。
この時代には、その状態を適切に処理する（必要に応じて再確立する）必要があります。
NATを実行しているルーター、特にリソースの少ないローエンドのルーターがある場合、最も古いTCPセッションを最初にエージングします。これを行うには、パケットにRSTフラグを設定します。これは、受信ステーションに（非常に不自然に）接続を閉じるように指示します。これは、リソースを節約するために行われます。
RSTは、最後のACKを送信する側であるため、アクティブクローズを実行する側から送信されます。そのため、間違った状態でパッシブクローズを行う側からFINを受信すると、エラーが発生したことを相手側に示すRSTパケットを送信します。
知っておくべきことの1つは、多くのLinux netfilterファイアウォールが誤って構成されていることです。
次のようなものがある場合：
-A前方-m状態--state関連、確立済み-j ACCEPT
-A FORWARD -p tcp -j REJECT --reject-with tcp-reset
パケットの順序を変更すると、ファイアウォールがパケットを無効と見なし、リセットを生成して、正常な接続を切断する可能性があります。
並べ替えは、特にワイヤレスネットワークで発生する可能性があります。
代わりに次のようにする必要があります。
-A前方-m状態--state関連、確立済み-j ACCEPT
-A前方-m状態--state無効-jドロップ
-A FORWARD -p tcp -j REJECT --reject-with tcp-reset
基本的にはいつでも：
... -m state --state RELATED、ESTABLISHED -j ACCEPT
すぐに続く必要があります：
... -m state --state INVALID -j DROP
パケットをドロップしてから、tcpリセットを中断する可能性のあるプロトコルを生成することをお勧めします。リセットは、送信するのに間違いなく正しいものである場合に優れています...これによりタイムアウトが解消されるためです。しかし、それらが無効である可能性があれば、この種の痛みを引き起こす可能性があります。