特定のWebサイトでランダムなTCP RSTが発生していますが、どうなっていますか?


34

短いバージョン:特定のWebサイトに接続すると、ネットワーク上の1台のWindows Server 2012マシンが持続的だが断続的なTCP RSTを取得します。ダンノはどこから来たのか。私の分析と質問については、wiresharkログをご覧ください。

ロングバージョン:

サーバーの1つでキャッシングWebプロキシを実行して、小規模オフィスにサービスを提供します。同僚から、特定のサイトへの接続時に「接続のリセット」または「ページを表示できません」というエラーが大量に発生することが報告されましたが、通常は更新すると修正されます。

ブラウザーの動作を確認し、サーバー自体でプロキシ化されていないブラウザーを試して、さらに直接確認しました。しかし、厄介なサイトへのpingとtracerouteで問題が発生することはありません。問題はtcp接続に限定されているようです。

次に、cURLを介してHTTP HEADリクエストを直接送信し、成功する頻度を確認することにより、影響を受けるサイトをテストするスクリプトを作成しました。典型的なテストは次のようになります:(これはプロキシされておらず、不良サーバーで直接実行されています)

C:\sdk\Apache24\htdocs>php rhTest.php
Sending HTTP HEAD requests to "http://www.washingtonpost.com/":
20:21:42: Length: 0     Response Code: NULL (0%)
20:22:02: Length: 0     Response Code: NULL (0%)
20:22:22: Length: 0     Response Code: NULL (0%)
20:22:42: Length: 0     Response Code: NULL (0%)
20:23:02: Length: 3173  Response Code: HTTP/1.1 302 Moved Temporarily (20%)
20:23:22: Length: 3174  Response Code: HTTP/1.1 302 Moved Temporarily (33.33%)
20:23:43: Length: 0     Response Code: NULL (28.57%)
20:24:03: Length: 3171  Response Code: HTTP/1.1 302 Moved Temporarily (37.5%)
20:24:23: Length: 3173  Response Code: HTTP/1.1 302 Moved Temporarily (44.44%)
20:24:43: Length: 3172  Response Code: HTTP/1.1 302 Moved Temporarily (50%)
20:25:03: Length: 0     Response Code: NULL (45.45%)

長期的には、リクエストの約60%のみが成功し、残りは「cURLエラー(56):ピアからデータを受信するときに失敗します」というカールエラーコードで何も返されません。テスト(どのサイトも「良くなった」ことはありません)とそれは非常に永続的であり、私は今1週間トラブルシューティングを行ってきました。

ネットワーク上の他のマシンでHEADリクエストスクリプトをテストしました。問題はありません。すべての接続はテストリストのすべてのサイトを経由します。次に、パーソナルデスクトップにプロキシを設定し、問題のあるサーバーからHEADリクエストを実行すると、すべての接続が通過します。したがって、問題が何であれ、それはこのサーバーに非常に固有のものです。

次に、どのWebサイトが接続リセット動作を示すかを分離しようとしました。

  • イントラネットサイト(192.168.xx)のいずれも接続を切断しません。
  • 私がテストしたipv6サイトは接続をドロップしません。(私たちはデュアルスタックです)
  • インターネットipv4サイトのごく一部のみが接続を切断します。
  • (テストした)CDNとしてcloudflareを使用するすべてのサイトは、接続をドロップします。(ただし、この問題はcloudflareサイトに限ったものではないようです)

この角度は本当に役立つものには発展していませんでした。次に、wiresharkをインストールして、リクエストが失敗したときに何が起こっているかを調べました。失敗したHEADリクエストは次のようになります:(大きなスクリーンショットはこちら:http : //imgur.com/TNfRUtX

127 48.709776000    192.168.1.142   192.33.31.56    TCP 66  52667 > http [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=8960 WS=256 SACK_PERM=1
128 48.728207000    192.33.31.56    192.168.1.142   TCP 66  http > 52667 [SYN, ACK, ECN] Seq=0 Ack=1 Win=42340 Len=0 MSS=1460 SACK_PERM=1 WS=128
129 48.728255000    192.168.1.142   192.33.31.56    TCP 54  52667 > http [ACK] Seq=1 Ack=1 Win=65536 Len=0
130 48.739371000    192.168.1.142   192.33.31.56    HTTP    234 HEAD / HTTP/1.1 
131 48.740917000    192.33.31.56    192.168.1.142   TCP 60  http > 52667 [RST] Seq=1 Win=0 Len=0
132 48.757766000    192.33.31.56    192.168.1.142   TCP 60  http > 52667 [ACK] Seq=1 Ack=181 Win=42240 Len=0
133 48.770314000    192.33.31.56    192.168.1.142   TCP 951 [TCP segment of a reassembled PDU]
134 48.807831000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
135 48.859592000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
138 49.400675000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
139 50.121655000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
141 51.564009000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
143 54.452561000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897

私がこれを読んでいる方法(私が間違っている場合、私を修正してください、これは本当に私の地域ではありません)は:

  • WebサーバーへのTCP接続を開きます
  • ウェブサーバーACK
  • HTTP HEADリクエストが送信されました
  • WebサーバーIPからのマークが付いたRSTパケットがあり、接続を切断します。
  • WebサーバーがACKを送信
  • 有効なHTTPデータでHEADリクエストに応答するWebサーバー(試行)(951バイトの応答には正しいHTTPヘッダーが含まれています)
  • Webサーバーは有効なHTTP応答を(数秒で数回)再送しますが、接続がRSTであるため成功しません

Webサーバーが有効なRSTを送信したのに、なぜ要求を満たそうとするのですか?そして、ウェブサーバーがRSTを生成しなかった場合、一体何をしましたか?

私が試したが効果がないもの:

  • NICチーミングを無効にする
  • ネットワークアダプターの交換(交換用NICが機能していることがわかっていた)
  • 静的IPを割り当てます。
  • ipv6を無効にします。
  • ジャンボフレームを無効にします。
  • ある晩サーバーをモデムに直接接続し、スイッチとルーターをバイパスします。
  • Windowsファイアウォールをオフにします。
  • netshを介したTCP設定のリセット
  • サーバー上の実質的に他のすべてのサービスを無効にします。(主にファイルサーバーとして使用しますが、ApacheといくつかのDBがあります)
  • 机の上の頭を叩く(繰り返し)

サーバー上の何かがRSTパケットを生成しているのではないかと疑っていますが、私の人生ではそれを見つけることができません。私が知っていたように感じる:なぜそれだけでこのサーバーですか?または、なぜいくつかのウェブサイトだけですか?それは大いに役立つでしょう。私はまだ好奇心が強いのですが、軌道からやり直してやり直そうとする傾向が強まっています。

アイデア/提案?

-ありがとう


このキャッシュプロキシサーバーはどのオペレーティングシステムを実行しますか?プロキシサーバーソフトウェアとは何ですか?
マイケルハンプトン

1
サーバーはWindows Server 2012を実行しており、プロキシはcygwinを介して実行されているsquid 3.3.3です。しかし、これは、プロキシの接続だけでなく、マシンからのすべてのTCP接続に起こります。curlテストスクリプトはプロキシされていません。
モーティ14年

回答:


38

パケットキャプチャに異常がありました。発信SYNパケットでECNビットが設定されました。

明示的な輻輳通知は、ホストがネットワーク輻輳により迅速に反応できるようにするIPプロトコルの拡張機能です。15年前にインターネットに初めて導入されましたが、最初の展開時に重大な問題が指摘されていました。最も深刻なのは、多くのファイアウォールが、ECNビットが設定されたSYNパケットを受信すると、パケットをドロップするか、RSTを返すことでした。

その結果、ほとんどのオペレーティングシステムは、少なくとも発信接続に関して、デフォルトでECNを無効にしました。その結果、多くのサイト(およびファイアウォールベンダー!)が単にファイアウォールを修正したことはないと思われます。

Windows Server 2012がリリースされるまで。Microsoftは、このオペレーティングシステムバージョンからECNをデフォルトで有効にしました

残念ながら、最近の記憶では誰もインターネットサイトのECNへの応答の重要なテストを行っていないため、2000年代初期に見られた問題がまだ存在するかどうかを判断することは困難ですが、少なくとも、あなたのトラフィックは、時々、そのような機器を通過します。

デスクトップでECNを有効にしてからWiresharkを起動した後、SYNとECNが設定されたパケットにRSTを取得したホストの例を見つけるのはほんの数秒でしたが、ほとんどのホストは正常に動作しているようです。たぶん私は自分でインターネットをスキャンします...

サーバーでECNを無効にして、問題が解決するかどうかを確認できます。また、これによりDCTCPを使用できなくなりますが、小規模なオフィスでは、使用している必要はほとんどありません。

netsh int tcp set global ecncapability=disabled

4
ありがとうございました!ECNを無効にした後、最も厄介なサイトへの接続の成功率は100%です。プロキシを再び有効にする前に、午前中にさらにテストする必要がありますが、これを回答し、Microsoft QAのユーザーに対する継続的な戦争でのもう1つの大勝利としてマークします。
モーティ14年

9
公平を期すために、ファイアウォール管理者の中には馬鹿者がいるのはマイクロソフトのせいではないと思います。ECNは非常に便利で、非常に役立ちます。いつか私たち全員が使い始めることができれば嬉しいです。
マイケルハンプトン

場合ああ、私は疑問に思う、これは私が(二つの異なるローカルのISPで発生し、決して私を混乱させる別の国、経由VPN'd)年齢のためにImgurやウィキアから取得してきたリセットのトンを説明
grawity

私は、これに関与するマシンのいくつかがデフォルトフリーゾーンに潜んでいると疑っています(明らかに証明できません)。
マイケルハンプトン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.