web-dev-qa-db-ja.com

ランダムTCP特定のWebサイトでのRSTです。どうなっているのですか？

ショートバージョン：ネットワーク上の1つのWindows Server 2012マシンが永続的になりますが断続的ですTCP特定のWebサイトに接続するときにRSTが発生します。それらがどこから来ているのかはわかりません。私の分析についてはWiresharkログを確認してください＆質問。

ロングバージョン：

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

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

次に、影響を受けるサイトをHTTP HEADリクエストをcURL経由で直接送信し、それらが成功する頻度を確認することで、スクリプトを作成しました。典型的なテストは次のようになります。悪いサーバー）

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）：ピアからデータを受信するときにエラーが発生しました」不正な動作はWebサイトで一貫していますテスト（どのサイトも「改善された」ことはありません）とそれは非常に永続的です、私は今1週間トラブルシューティングしており、同僚は問題が数か月の間そこにあったと報告します。

HEADリクエストスクリプトをネットワーク上の他のマシンでテストしました。問題ありません。すべての接続がテストリストのすべてのサイトに到達します。次に、個人用デスクトップにプロキシを設定し、 HEADリクエストを問題のあるサーバーから実行すると、すべての接続が通過します。問題が何であれ、このサーバーに固有のものです。

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

  • 私たちのイントラネットサイト（192.168.x.x）はどれも接続を落としません。
  • テストしたどのipv6サイトも接続を切断しません。 （私たちはデュアルスタックです）
  • ごく少数のインターネットipv4サイトのみが接続をドロップします。
  • Cloudflareを（私がテストした）CDNとして使用するすべてのサイトは、接続をドロップします。 （しかし、問題は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接続を開きます
  • webサーバーACK
  • HTTP HEADリクエストが送信されます
  • WebサーバーIPからのマークが付けられた、接続を強制終了するRSTパケットがあります。
  • ウェブサーバーがACKを送信
  • HEADリクエストに有効なHTTPデータで応答するWebサーバー（試行）（951バイトの応答には正しいHTTPヘッダーが含まれています）
  • Webサーバーは有効なHTTP応答を（数秒に数回）再送信しますが、接続がRSTであるため成功しません

それで、Webサーバーが有効なRSTを送信した場合、なぜ要求を満たそうとし続けるのですか？ WebサーバーがRSTを生成しなかった場合、一体何をしたのでしょうか。

私が試したものは効果がありませんでした：

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

何か疑わしいサーバー上がRSTパケットを生成しているようですが、私の人生ではそれを見つけることができません。私は知っているような気がします：なぜこれだけのサーバーなのですか？ ORなぜ一部のWebサイトだけなのですか？それは大いに役立ちます。私はまだ興味があるのですが、軌道から核攻撃して最初からやり直す傾向があります。

アイデア/提案？

-ありがとう

networkingwindows-server-2012tcp
34
Morty

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

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

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

Windows Server 2012がリリースされるまで。 MicrosoftenabledECN by default このオペレーティングシステムのバージョン以降。

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

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

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

netsh int tcp set global ecncapability=disabled
39
Michael Hampton