失敗したTCP接続とRSTパケットの追跡

TCP (Transmission Control Protocol) 接続は、インターネットとネットワーク通信のバックボーンであり、デバイス間でデータが正確かつ確実に送信されることを保証します。

ただし、これらの接続が失敗すると、大きな混乱につながる可能性があります。これらの失敗の主な指標の 1 つは、接続試行が突然終了したことを示す RST (リセット) パケットの存在です。これらの問題を理解してトラブルシューティングすることは、ネットワークの安定性とパフォーマンスを維持するために不可欠です。

TCP接続を理解する

TCP 接続の確立方法 (3 ウェイ ハンドシェイク)

TCP 接続は、3 ウェイ ハンドシェイクと呼ばれるプロセスを通じて確立されます。これには次の 3 つの手順が含まれます。

1. SYN (同期): クライアントは接続を開始するために SYN パケットをサーバーに送信します。
2. SYN-ACK (同期確認): サーバーは SYN-ACK パケットで応答し、クライアントの要求を確認します。
3. ACK (肯定応答): クライアントは ACK パケットをサーバーに送り返し、ハンドシェイクを完了して接続を確立します。

TCP接続失敗の一般的な原因

TCP 接続の失敗は、次のようなさまざまな理由で発生する可能性があります。

• ネットワークの混雑またはハードウェアの障害
• ネットワークデバイスまたはファイアウォールの設定ミス
• アプリケーションレベルのエラーまたは誤った構成
• 特定の種類のトラフィックをブロックするセキュリティポリシー

TCP接続失敗の症状と指標

TCP 接続が失敗した場合の症状には次のようなものがあります。

• 接続を確立または維持できない
• ネットワークパフォーマンスが遅い、または断続的
• 接続リセット (RST) パケット数の増加

RST パケットとは何ですか?

RST パケットは、TCP/IP プロトコル内で接続を突然終了するために使用されます。デバイスが予期しないパケットまたは無効なパケットを受信したときに送信され、現在の接続をリセットする必要があることを示します。

「RST パケットは TCP 接続の突然の終了を知らせるものであり、ネットワークの問題を診断するための重要な指標です。」

RSTパケットが生成されるシナリオ

RST パケットは、次のようないくつかのシナリオで生成されます。

• 閉じたポートのSYNパケットを受信するサーバー
• アプリケーションがクラッシュまたは障害を起こし、RSTパケットが送信される
• セキュリティ対策による意図的な接続終了

正常と異常なRSTパケットの動作の違い

• 通常の動作: RST パケットは、未使用の接続の終了時など、通常のネットワーク操作の一部となる場合があります。
• 異常な動作: RST パケットの頻度が高い場合、ネットワークの誤った構成、セキュリティ攻撃、アプリケーションの障害など、根本的な問題がある可能性があります。

問題の特定: 失敗した TCP 接続と RST パケットを追跡する

LogicMonitorは注意が必要な問題を特定するのに優れていますが、特にネットワークの問題の場合、解決策を正確に把握するのが少し難しい場合があります。 比較的一般的なケースのXNUMXつ–TCP接続の失敗に関するアラート。 最近、ラボ内のサーバーのXNUMXつがこのアラートをトリガーしました。

ホストLabutil01では、異常な数のTCP接続失敗が発生しています。
おそらく着信接続です。
現在、2.01 秒あたり XNUMX 件の接続失敗があり、ホストは警告レベルになっています。
これは 2014-02-26 10:54:50 PST に始まりました。
これは、アプリケーションバックログパラメータが正しくないこと、または
OS TCP リッスン キューの設定が正しくありません。

問題の調査

OK –では、次のステップは何ですか？ 私たちが最初にしたことは、これが最近の変更なのか、それともしばらくの間続いていたのかを確認することでした。 TCP接続のグラフをざっと見ると、これは新しい問題であることがわかります。

グラフの線は、「TCP接続がSYN-SENT状態またはSYN-RCVD状態のいずれかからCLOSED状態に直接遷移した回数とTCPの回数を示していることを（マウスオーバーで）説明しています。接続は、SYN-RCVDからLISTEN状態に直接移行しました。」

OK、それは最善の説明ではないかもしれませんが、基本的には、TCPアプリケーションがSYNを送信して接続を開こうとしましたが、RSTが返されました。 （TCPのすべての複雑さを本当に理解したい場合、そして多くの場合、それらを理解するのは良いことですが、私はお勧めします スティーブンスによるTCP / IPの図解 –オールディーズだがグッディーズ。）

では、どのアプリケーションがRSTを取得したのでしょうか。 この時点で、さまざまなログファイルを調べてみることができます（問題のアプリケーションがこの情報をログに記録し、見たい場所に記録することを期待します）。または、ネットワーク上のRSTを調べることもできます。

このサーバーはLinuxボックスであったため、TCPdumpを使用しますが、Wiresharkを使用してWindowsでも同じことができます。

私が最初に実行したtcpdumpは次のとおりです。

tcpdump -n -v'tcp [tcpflags]＆（tcp-rst）！= 0 '

これは、名前解決なしでTCPdumpを実行するコマンドです（速度が低下する可能性があります）。 詳細出力を使用して、tcp-rstビットが設定されているtcpフラグを持つすべてのパケットを表示します。 （つまり、すべてのTCP RSTパケット。）

そして、これは明らかに私たちに…何も示しませんでした。

[root@labutil01 ~]# tcpdump -n -v 'tcp[tcpflags] & (tcp-rst) != 0' tcpdump: eth0 でリッスン、リンクタイプ EN10MB (イーサネット)、キャプチャ サイズ 65535 バイト 15:08:17.537699 IP (tos 0x0、ttl 64、id 0、オフセット 0、フラグ [DF]、プロト TCP (6)、長さ 40) 10.0.1.141.http > 10.0.1.86.34559: フラグ [R.]、cksum 0x8411 (正しい) )、シーケンス 0

30秒間に2つのパケットが報告され、WebサーバーがRSTを介してこのサーバーからの接続を切断しました（これは有効なことです）。 しかし、XNUMX秒あたりXNUMX回のリセットを探しているので、そうではありませんでした。 では、次にどこを見ればよいのでしょうか。
上記の出力で、tcpdumpがデフォルトのインターフェースeth0でリッスンして実行されたことに注意してください。 このホストに他のネットワークインターフェイスがある場合は、そこでタスクを繰り返して、どのインターフェイスをリッスンするかをtcpdumpに指示することができます。 ただし、このサーバーにはXNUMXつのインターフェイスしかありません。
それとも？
プログラムは通常、すべてのLinux（およびWindows）サーバーが持つループバックポートを介して通信します。 そこで聞いたときに何が起こるか見てみましょう。 -i 国旗…。

[root@labutil01 ~]# tcpdump -ilo -n -v 'tcp[tcpflags] & (tcp-rst) != 0' tcpdump: lo でリッスン、リンクタイプ EN10MB (イーサネット)、キャプチャ サイズ 65535 バイト 15:13 :13.476095 IP (tos 0x0、ttl 64、id 0、オフセット 0、フラグ [DF]、プロト TCP (6)、長さ 40) 127.0.0.1.7211 > 127.0.0.1.41838: フラグ [R.]、cksum 0x57d9 (正しい)、seq 0、ack 2154306035、win 0、length 0 15:13:13.476216 IP (tos 0x0、ttl 64、id 0、offset 0、flags [DF]、proto TCP (6)、length 40) 127.0.0.1.7211。 127.0.0.1.41839 > 0: Flags [R.]、cksum 25x0bc (正しい)、seq 3335718308、ack 0、win 0、length 15 13:14.476576:0 IP (tos 0x64、ttl 0、id 0、オフセット6、フラグ [DF]、プロト TCP (40)、長さ 127.0.0.1.7211) 127.0.0.1.41840 > 0: フラグ [R.]、cksum 171x0a (正しい)、seq 2138200998、ack 0、win 0、長さ15 13:14.476721:0 IP (tos 0x64、ttl 0、id 0、オフセット 6、フラグ [DF]、プロト TCP (40)、長さ 127.0.0.1.7211) 127.0.0.1.41841 > 0: フラグ [R. ]、cksum 5xaec0 (正しい)、seq 1520953540、ack 0、win 0、length XNUMX

ああ…毎秒7211回のリセット。 問題のようです。 一部のプロセスがポートXNUMXでwww.logicmonitor.comに接続しようとしていますが、そのプロセスが実行されていないため、サーバーはRSTを送り返しています。

これは私たちの問題を解決しますか？ そうですね、通常はポート7211でリッスンするアプリケーションが何であるかがわかっていれば、それは可能です。「ああ、ポート7211 –それが何であるかはわかっています！」 または、ポートが443や23などのよく知られたポートです。次に、WebサーバーまたはTelnetサーバーを起動します（または、プロセスがTelnetサーバーに接続しようとするのを停止します）。

問題の解決

この場合、ポート7211がコレクターのコンポーネントによって使用されていることがわかったので、そのコンポーネントのログファイルを調べたところ、テストビルドにライブラリがないため、そのコンポーネントが機能しなくなっていました。 ライブラリをインストールし、コンポーネントを起動すると、RSTとアラートが消えました。

そして、そのポートでリッスンする必要があるプロセスがわからず、RSTを送信している場合はどうでしょうか。 まあ、少なくともあなたはそれが何であるかを知っています 。 そして今、あなたはもう少し知っているすべてのそれらのログファイルを見ることができます–そして何を除外するか。

まとめ

TCP 接続障害と RST パケットを理解してトラブルシューティングすることは、ネットワークの信頼性を維持するために重要です。このケース スタディで概説されている手順に従い、TCPdump や Wireshark などのツールを利用することで、IT 担当者はこれらの問題を効果的に診断して解決できます。

さらなる情報や最新情報については、 Facebook, Twitter, LinkedInご質問がありましたら、お気軽にメールでお問い合わせください。 [メール保護].