Frage Random TCP RSTs auf bestimmten Websites, was ist los?


Kurzversion: Ein Windows Server 2012-Computer in meinem Netzwerk erhält beim Herstellen einer Verbindung mit bestimmten Websites permanente, aber zeitweise auftretende TCP-RSTs. Weiß nicht woher sie kommen. Schauen Sie sich das Wireshark-Log für meine Analyse und Fragen an.

Lange Version:

Wir betreiben einen Caching-Web-Proxy auf einem unserer Server, um unser kleines Büro zu bedienen. Ein Mitarbeiter berichtete, dass bei der Verbindung mit bestimmten Websites eine Menge von "Verbindungszurücksetzung" oder "Seite kann nicht angezeigt werden" -Fehler angezeigt wird, aber durch die Aktualisierung wird diese normalerweise behoben.

Ich verifizierte das Verhalten des Browsers und dann direkter, indem ich einen nicht-proxisierten Browser auf dem Server selbst versuchte. Pings und Tracerouten zu problematischen Seiten zeigen jedoch keine Probleme, die Probleme scheinen sich auf TCP-Verbindungen zu beschränken.

Ich habe dann ein Skript erstellt, um die betroffenen Seiten zu testen, indem ich ihnen HTTP HEAD-Anfragen direkt über cURL zusende und überprüfe, wie oft sie erfolgreich sind. Ein typischer Test sieht so aus: (Dies ist nicht behoben, läuft direkt auf dem fehlerhaften Server)

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%)

Auf lange Sicht sind nur etwa 60% der Anfragen erfolgreich, die anderen geben nichts zurück, mit einem Fehlercode von: "cURL error (56): Fehler beim Empfang von Daten vom Peer" Das schlechte Verhalten ist konsistent für die Websites, die ich getestet habe (keine Website ist jemals "besser geworden") und es ist ziemlich hartnäckig, ich habe seit einer Woche Fehlerbehebung, und Mitarbeiter berichten, dass das Problem seit Monaten offenbar dort ist.

Ich habe das HEAD-Anforderungsskript auf anderen Computern in unserem Netzwerk getestet: keine Probleme, alle Verbindungen gehen zu allen Sites auf meiner Testliste. Dann habe ich einen Proxy auf meinem persönlichen Desktop eingerichtet, und wenn ich die HEAD-Anfragen vom problematischen Server durchführe, gehen alle Verbindungen durch. Also, was auch immer das Problem ist, es ist sehr spezifisch für diesen Server.

Als nächstes habe ich versucht zu isolieren, welche Websites das Verbindungs-Reset-Verhalten aufweisen:

  • Keine unserer Intranet-Sites (192.168.x.x) löscht Verbindungen.
  • Keine IPv6-Seite, die ich getestet habe, löscht Verbindungen. (Wir sind Dual-Stack)
  • Nur eine kleine Minderheit von Internet-ipv4-Sites gibt Verbindungen ab.
  • Jede Seite, die cloudflare als CDN verwendet (die ich getestet habe), löscht Verbindungen. (aber das Problem scheint nicht ausschließlich für Cloudflare-Sites zu sein)

Dieser Winkel entwickelte sich nicht zu etwas wirklich hilfreichem, also installierte ich als nächstes wireshark, um zu sehen, was los war, als eine Anfrage fehlschlug. Eine fehlgeschlagene HEAD-Anfrage sieht so aus: (größerer Screenshot hier: 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

Die Art, wie ich das hier lese (korrigiere mich, wenn ich falsch liege, das ist nicht wirklich meine Gegend) ist das:

  • Wir öffnen eine TCP-Verbindung zum Webserver
  • Webserver ACKs
  • HTTP HEAD-Anfrage wird gesendet
  • Es gibt ein RST-Paket, das von der Webserver-IP markiert ist und die Verbindung abbricht.
  • Webserver sendet ACK
  • Webserver (versucht) auf HEAD-Anfrage mit gültigen HTTP-Daten zu antworten (Die 951-Byte-Antwort enthält den korrekten HTTP-Header)
  • Der Webserver sendet (mehrere Male über mehrere Sekunden) die gültige HTTP-Antwort erneut, aber er kann nicht erfolgreich sein, da die Verbindung RST war

Wenn also der Webserver eine gültige RST gesendet hat, warum versucht er dann weiter, die Anfrage zu beantworten? Und wenn der Webserver den RST nicht erzeugt hat, was zum Teufel hat er gemacht?

Dinge, die ich versucht habe, die keine Wirkung hatten:

  • Deaktivieren der NIC-Teambildung
  • Ändern des Netzwerkadapters (es ist bekannt, dass der Austausch der NIC funktioniert)
  • Zuweisen einer statischen IP.
  • Deaktivieren von ipv6.
  • Deaktivieren von Jumbo Frames
  • Einen Server direkt in unser Modem einstecken und unsere Switches und Router umgehen.
  • Deaktivieren der Windows-Firewall
  • Zurücksetzen der TCP-Einstellungen über netsh
  • Fast alle anderen Dienste auf dem Server deaktivieren. (Wir benutzen es meistens als Fileserver, aber es gibt Apache und ein paar DB's)
  • Kopf auf den Schreibtisch schlagen (wiederholt)

Ich vermute etwas auf dem Server erzeugt die RST-Pakete, aber für das Leben von mir kann ich es nicht finden. Ich fühle mich, wenn ich wüsste: Warum ist es nur dieser Server? ODER warum nur einige Websites? Es würde viel helfen. Während ich immer noch neugierig bin, neige ich immer dazu, vom Orbit aus zu atmen und neu anzufangen.

Ideen / Vorschläge?

-Vielen Dank


34
2017-11-04 02:24


Ursprung


Welches Betriebssystem führt dieser Caching-Proxy-Server aus? Und was ist die Proxy-Server-Software? - Michael Hampton♦
Auf dem Server läuft Windows Server 2012, der Proxy ist der Squid 3.3.3, der über cygwin läuft; Dies geschieht jedoch bei allen TCP-Verbindungen von der Maschine, nicht nur bei den Verbindungen des Proxy. Das Curl-Testskript ist nicht aufgelöst. - Morty


Antworten:


Ihre Paketerfassung hatte etwas Ungewöhnliches: Die ECN-Bits wurden im ausgehenden SYN-Paket gesetzt.

Explizite Staubenachrichtigung ist eine Erweiterung des IP-Protokolls, die es Hosts ermöglicht, schneller auf Netzwerküberlastungen zu reagieren. Es wurde vor 15 Jahren ins Internet eingeführt, aber es gab ernste Probleme bemerkt, als es zum ersten Mal eingesetzt wurde. Der schwerwiegendste von ihnen war, dass viele Firewalls würden Entweder Pakete fallen lassen oder eine RST zurückgeben wenn ein SYN-Paket mit den gesetzten ECN-Bits empfangen wird.

Aus diesem Grund haben die meisten Betriebssysteme ECN standardmäßig deaktiviert, zumindest für ausgehende Verbindungen. Als ein Ergebnis vermute ich, dass viele Websites (und Firewall-Anbieter!) Einfach nie reparierten ihre Firewalls.

Bis Windows Server 2012 veröffentlicht wurde. Microsoft aktiviert ECN standardmäßig beginnend mit dieser Betriebssystemversion.

Leider hat niemand in letzter Zeit irgendwelche signifikanten Tests der Antworten von Internet-Sites auf ECN durchgeführt, daher ist es schwer abzuschätzen, ob die in den frühen 2000er Jahren aufgetretenen Probleme noch bestehen, aber ich vermute stark, dass dies der Fall ist manchmal, durch solche Ausrüstung.

Nachdem ich ECN auf meinem Desktop aktiviert und dann Wireshark gestartet hatte, war es nur ein paar Sekunden, bis ich ein Beispiel eines Hosts fand, von dem ich eine RST zu einem Paket mit SYN und ECN bekam, obwohl die meisten Hosts gut zu funktionieren scheinen. Vielleicht werde ich selbst das Internet scannen ...

Sie können versuchen, ECN auf Ihrem Server zu deaktivieren, um festzustellen, ob das Problem behoben ist. Dies wird auch dazu führen, dass Sie DCTCP nicht verwenden können, aber in einem kleinen Büro ist es sehr unwahrscheinlich, dass Sie dies tun oder müssen.

netsh int tcp set global ecncapability=disabled

38
2017-11-04 03:17



Danke dir! Nach der Deaktivierung von ECN sehe ich eine 100% ige Erfolgsrate für Verbindungen zu den schwierigsten Websites! Ich werde am Morgen mehr testen müssen, bevor wir unseren Proxy wieder einschalten, aber ich werde weitermachen und dies sowohl als beantwortet als auch als einen weiteren überwältigenden Sieg in Microsoft QA's andauerndem Krieg gegen die Benutzer bezeichnen. - Morty
Um fair zu sein, ich glaube nicht, dass es Microsofts Schuld ist, dass Firewall-Admins Idioten sind. ECN ist sehr schön zu haben, da es sehr hilfreich ist, und es wäre schön, wenn wir alle damit anfangen könnten ... eines Tages. - Michael Hampton♦
Oh, ich frage mich ob diese erklärt die Unmengen von Resets, die ich seit Ewigkeiten von Imgur und Wikia bekomme (passiert mit zwei verschiedenen lokalen ISPs, aber niemals, wenn ich durch ein anderes Land VPN bin, was mich verwirrt) - grawity
ich vermuten (aber offensichtlich nicht beweisen), dass einige der dafür verantwortlichen Maschinen in der defaultfreien Zone lauern. - Michael Hampton♦