Zufällige TCP-RSTs auf bestimmten Websites, was ist los?

Kurzversion: Ein Windows Server 2012-Computer in meinem Netzwerk erhält dauerhafte, aber zeitweise auftretende TCP-RSTs, wenn eine Verbindung zu bestimmten Websites hergestellt wird. Keine Ahnung, woher sie kommen. Sehen Sie sich das Wireshark-Protokoll für meine Analysen und Fragen an.

Lange Version:

Wir betreiben einen Caching-Web-Proxy auf einem unserer Server, um unser kleines Büro zu bedienen. Ein Mitarbeiter meldete, dass beim Herstellen einer Verbindung zu bestimmten Websites viele Fehler beim Zurücksetzen der Verbindung oder beim Anzeigen der Seite nicht angezeigt werden. Durch diese Aktualisierung wird der Fehler jedoch in der Regel behoben.

Ich habe das Browserverhalten überprüft und dann direkter, indem ich einen nicht-Proxy-Browser auf dem Server selbst ausprobiert habe. Aber Pings und Traceroutes zu problematischen Sites zeigen keine Probleme, die Probleme schienen sich auf TCP-Verbindungen zu beschränken.

Ich habe dann ein Skript erstellt, um die betroffenen Sites zu testen, indem ich ihnen HTTP-HEAD-Anforderungen direkt über cURL schickte und überprüfte, wie oft sie erfolgreich waren. Ein typischer Test sieht folgendermaßen aus: (Dieser Test ist nicht überarbeitet und wird direkt auf dem fehlerhaften Server ausgeführt.)

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

Langfristig sind nur etwa 60% der Anfragen erfolgreich, der Rest gibt nichts zurück, mit einem Curl-Fehlercode von: "cURL-Fehler (56): Fehler beim Empfangen von Daten vom Peer". Das schlechte Verhalten ist für die Websites I konsistent Test (keine Website wurde jemals "besser") und es ist ziemlich hartnäckig. Ich habe seit einer Woche eine Fehlerbehebung durchgeführt, und Mitarbeiter berichten, dass das Problem anscheinend schon seit Monaten besteht.

Ich habe das HEAD-Anforderungsskript auf anderen Computern in unserem Netzwerk getestet: Keine Probleme, alle Verbindungen werden zu allen Sites auf meiner Testliste durchlaufen. Dann richte ich auf meinem persönlichen Desktop einen Proxy ein, und wenn ich die HEAD-Anforderungen vom problematischen Server durchführe, werden alle Verbindungen hergestellt. Was auch immer das Problem ist, es ist sehr spezifisch für diesen Server.

Als nächstes habe ich versucht herauszufinden, auf welchen Websites das Verhalten beim Zurücksetzen der Verbindung auftritt:

• Keine unserer Intranetsites (192.168.xx) unterbricht Verbindungen.
• Keine IPv6-Site, auf der ich Drop-Verbindungen getestet habe. (Wir sind Dual-Stack)
• Nur eine kleine Minderheit von Internet-IPv4-Sites unterbricht Verbindungen.
• Jede Site, die Cloudflare als CDN verwendet (die ich getestet habe), unterbricht Verbindungen. (aber das Problem scheint nicht ausschließlich für Cloudflare-Sites zu sein)

Dieser Winkel entwickelte sich nicht zu etwas wirklich Nützlichem. Als nächstes installierte ich wireshark, um zu sehen, was los war, wenn eine Anfrage fehlschlug. Eine fehlgeschlagene HEAD-Anfrage sieht folgendermaßen 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 und Weise, wie ich das lese (korrigiere mich, wenn ich mich irre, das ist nicht wirklich meine Gegend), ist folgende:

• Wir öffnen eine TCP-Verbindung zum Webserver
• Webserver ACK's
• HTTP-HEAD-Anforderung wird gesendet
• Es gibt ein RST-Paket, das als von der Webserver-IP markiert ist und die Verbindung beendet.
• Webserver sendet ACK
• Webserver (versucht), auf HEAD-Anfrage mit gültigen HTTP-Daten zu antworten (Die 951-Byte-Antwort enthält den richtigen HTTP-Header)
• Der Webserver überträgt die gültige HTTP-Antwort erneut (mehrmals über mehrere Sekunden), kann jedoch keinen Erfolg erzielen, da die Verbindung über RST hergestellt wurde

Also, wenn der Webserver eine gültige RST gesendet hat, warum versucht er immer wieder, die Anforderung zu erfüllen? Und wenn der Webserver die RST nicht generiert hat, was zum Teufel hat das getan?

Dinge, die ich ausprobiert habe und die keine Wirkung hatten:

• NIC-Teaming deaktivieren
• Auswechseln des Netzwerkadapters (Ersatz-NIC funktionierte bekanntermaßen)
• Zuweisen einer statischen IP.
• Ipv6 deaktivieren.
• Jumbo Frames deaktivieren.
• Schließen Sie den Server eines Nachts direkt an unser Modem an und umgehen Sie dabei unsere Switches und Router.
• Windows Firewall ausschalten.
• Zurücksetzen der TCP-Einstellungen über Netsh
• Deaktivieren Sie praktisch jeden anderen Dienst auf dem Server. (Wir benutzen es meistens als Dateiserver, aber es gibt Apache & ein paar DBs)
• Kopf auf Schreibtisch schlagen (mehrmals)

Ich vermute, dass etwas auf dem Server die RST-Pakete generiert, aber für das Leben von mir kann ich es nicht finden. Ich fühle mich wie wenn ich wüsste: Warum ist es nur dieser Server? ODER warum nur einige Websites? es würde sehr helfen. Während ich noch neugierig bin, neige ich immer mehr dazu, aus dem Orbit auszubrechen und von vorne zu beginnen.

Ideen / Vorschläge?

-Vielen Dank

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

Explizite Überlastungsbenachrichtigung ist eine Erweiterung des IP-Protokolls, mit der Hosts schneller auf Überlastungen des Netzwerks reagieren können. Es wurde vor 15 Jahren zum ersten Mal im Internet eingeführt, es wurden jedoch schwerwiegende Probleme festgestellt, als es zum ersten Mal bereitgestellt wurde. Am schwerwiegendsten war, dass viele Firewalls beim Empfang eines SYN-Pakets mit gesetzten ECN-Bits entweder Pakete verwerfen oder ein RST zurückgeben .

Infolgedessen haben die meisten Betriebssysteme ECN standardmäßig deaktiviert, zumindest für ausgehende Verbindungen. Daher vermute ich, dass viele Websites (und Firewall-Anbieter!) Ihre Firewalls einfach nie repariert haben .

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

Leider hat in letzter Zeit noch niemand die Reaktionen von Internetseiten auf ECN ausführlich getestet. Es ist daher schwer einzuschätzen, ob die Probleme aus den frühen 2000er Jahren noch bestehen, aber ich vermute, dass dies der Fall ist und zumindest Ihr Datenverkehr manchmal durchlaufen solche Geräte.

Nachdem ich ECN auf meinem Desktop aktiviert und Wireshark dann gestartet hatte, dauerte es nur ein paar Sekunden, bis ich ein Beispiel für einen Host entdeckte, von dem ich eine RST für ein Paket mit SYN und ECN erhielt, obwohl die meisten Hosts gut zu funktionieren scheinen. Vielleicht gehe ich selbst ins Internet ...

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

netsh int tcp set global ecncapability=disabled