Unregelmäßige Internetstörung: Bestimmte Bilder und JS werden nicht geladen


11

Zum ersten Mal auf ServerFault, und ich habe ein schönes kleines Rätsel.

Seit einigen Monaten haben wir Probleme mit unserer Internetverbindung.

Umgebung:

Servers: 2 Terminal Servers as an RDSFarm running Windows Server 2008 R2
Browser: Internet Explorer 9
Test/debug browser: Chrome
AntiVirus: Avast 7.0.1455

Problem:

In unregelmäßigen Abständen lehnen Websites das Laden ab und geben einen Fehler aus, der besagt, dass auf die Seite nicht zugegriffen werden konnte oder einige Bilder nicht vollständig geladen wurden. Nach der Überprüfung können mehrere .js-Dateien nicht geladen werden.

Geben Sie hier die Bildbeschreibung ein

Ergebnisse & Was wir versucht haben:

Erster Eindruck:

Wenn ich in diesem Intervall Chrome verwende, gibt die Site nach einigen Aktualisierungen einen net :: Error 101 oder Error 103 zurück. In anderen Fällen sind mehrere Bilder nicht sichtbar, wenn der Fehler nicht angezeigt wird, und es wird ein X-Bild angezeigt. IE sagt nur, dass die Seite nicht angezeigt werden kann.

Geben Sie hier die Bildbeschreibung ein

Verwenden der Chrome Developer Tools:

In der Konsole wird angezeigt, dass mehrere Ressourcen nicht verfügbar sind. Wenn ich jedoch mit der rechten Maustaste auf die fehlenden Bilder klicke und "Bild anzeigen" auswähle, werden sie angezeigt. Wenn ich die Bilder über eine direkte URL öffne, werden sie auch angezeigt.

Geben Sie hier die Bildbeschreibung ein

Prüfung über Chrome Developer Tools:

Ich habe eine Prüfung auf einer Seite durchgeführt, die sich im fehlerhaften Zustand befand, und festgestellt, dass einige .js-Dateien nicht zusammen mit einigen .png-, .jpg- und .gif-Dateien geladen wurden. Für Chrome und IE werden unterschiedliche Bilder geladen.

Geben Sie hier die Bildbeschreibung ein Geben Sie hier die Bildbeschreibung ein

Verschleierte JS-Dateien & Avast:

Nachdem ich das überprüft hatte, stellte ich fest, dass die meisten dieser .js-Dateien verschleierte JS-Dateien sind, und da wir Avast 7.0.1455 ausführen, habe ich mich gefragt, ob das Web Shield die Dinge nicht durcheinander gebracht hat.

Andererseits passiert es nur auf dem ersten TS, nicht auf dem zweiten.

Also habe ich WebShield für einen Tag ausgeschaltet und nachgesehen, ob sich etwas verbessert hat. Es war nicht so. Zurück zum ersten Platz.

Kein Cache-Ablauf für Dateien:

Einige dieser Dateien, die nicht geladen werden, haben keinen Cache-Ablauf.

Caching:

Einer unserer Sysadmins hat vor einiger Zeit die IE-Cache-Größe auf 10 MB geändert, was meiner Meinung nach die Ursache des Problems gewesen sein könnte. Er hat es wieder auf 65 MB geändert, aber die Leute haben immer noch Probleme mit ihren Bildern. Es passiert auch immer noch auf 1 TS und auch in Chrome. Ich glaube also nicht, dass die Gruppenrichtlinie vorschreibt, dass der Cache Chrome beeinflusst, oder?

Geben Sie hier die Bildbeschreibung ein

Netzwerkproblem: Ich dachte auch, dass es sich möglicherweise um ein Netzwerk- oder Routingproblem handelt, aber beide TS-Server befinden sich auf derselben Netzwerkkarte, und der andere funktioniert einwandfrei.

Hilfe!

Wenn jemand Tipps hat, wo er nach Problemen suchen kann, oder weitere Informationen benötigt, helfen Sie mir bitte. Das stört mich jetzt seit mehreren Wochen.

BEARBEITEN & AKTUALISIEREN

Das Problem besteht weiterhin und nur auf unseren 2 Terminalservern.

Folgendes haben ich und ein Kollege bisher getan:

  • Schalten Sie das Antivirus für einen Tag auf einem Server aus, um festzustellen, ob dies nicht geschehen ist. Problem trat immer noch auf.

  • MTU-Größe überprüft Dies
    ist die Standardeinstellung (der genaue Wert wurde vergessen: P). Es ist immer noch ein Problem aufgetreten.

  • Installierte Windows-Updates, IE10- Problem immer noch aufgetreten.

  • Überprüft, ob Proxies vorhanden sind.
    Der AV setzt einen Proxy als sogenanntes WebShield ein. Wir haben den Dienst und das Programm für einen Tag auf einem Server deaktiviert. Problem trat immer noch auf.

  • Installierte das NIC-Team neu, als es durcheinander kam. (Außerdem wurden die NIC-Treiber neu installiert.) Das Problem trat weiterhin auf.

  • Überprüfte Gruppenrichtlinien Anscheinend gab es auf beiden Terminalservern eine lokale Computerrichtlinie, die den Einstellungsmodus im IE aktivierte und einige seltsame Anpassungen vorgenommen hatte. Deaktiviert das und ... Problem immer noch aufgetreten.

Es ist jetzt sogar so weit gegangen, dass Leute Probleme beim Hoch- und Herunterladen von Dateien von SharePoint haben und viele Websites, die wir verwenden, aus diesem Grund nicht funktionieren.

Ahnungen

Dies hat entweder mit dem WebShield zu tun, das die Verbindung unterbricht, wenn es etwas Besonderes findet, aber es sollte nicht passieren, wenn der AV ausgeschaltet ist.

Es könnte sein, dass Weiterleitungen irgendwie durcheinander sind oder dass etwas mit dem Cache zu tun hat. Seltsamerweise tritt das gleiche Problem sowohl in Chrome als auch in IE9 und IE10 auf.

Wenn jemand irgendwelche Ideen hat, wäre es sehr dankbar.

Vielen Dank an HopelessN00b für die Hilfe!

AKTUALISIEREN:

In der Ereignisanzeige werden folgende Fehler auf einem unserer ursprünglichen TS angezeigt:

Error: (04/04/2013 08:44:42 AM) (Source: Application Error) (User: )
Description: Faulting application name: iexplore.exe, version: 9.0.8112.16470, time stamp: 0x510c8801
Faulting module name: MSHTML.dll, version: 9.0.8112.16470, time stamp: 0x510c9046
Exception code: 0xc0000005
Fault offset: 0x002d0174
Faulting process id: 0x21728
Faulting application start time: 0xiexplore.exe0
Faulting application path: iexplore.exe1
Faulting module path: iexplore.exe2
Report Id: iexplore.exe3

Und manchmal taucht dies auf, aber anscheinend liegt das daran, dass einige WYSE-Terminals zu alt sind (hoffentlich bald durch Raspberry Pi ersetzt).

Error: (04/04/2013 11:21:46 AM) (Source: TermDD) (User: )
Description: The Terminal Server security layer detected an error in the protocol stream and has disconnected the client.
Client IP: [IP REDACTED].

Hoffe das hilft.


1
Es erinnert mich an Probleme, die wir aus einer völlig anderen Perspektive gesehen haben. Im Grunde hatte es mit der MTU-Konfiguration zu tun, irgendwo wurde die Paketkapselung nicht berücksichtigt, und die fragmentierten Pakete wurden nicht richtig zusammengesetzt, also etwas Größeres als ein einzelnes Paket würde einfach nicht geladen. Wenn die Seite https wäre, würde überhaupt nichts geladen werden.
NickW

1
Kein Problem, ich würde versuchen, es irgendwo zwischen dem TS und den Maschinen auszuführen, auf denen die Probleme auftreten. Möglicherweise könnte Ihr Netzwerk-Typ den Port spiegeln, an dem der TS angeschlossen ist (oder den Computer, von dem aus Sie testen), sodass Sie einen Computer mit Wireshark dort anbringen können, um den Datenverkehr zu sehen.
NickW

1
Ja, das sollte nicht viel Problem verursachen.
NickW

1
Übrigens, Sie haben sich so etwas wie dieses Recht angesehen: community.spiceworks.com/topic/…
NickW

4
Es gibt zwei Dinge, die ich versuchen würde, wenn dies passiert. Wenn es sich nur um die Domäne und JS handelt, überprüfen Sie die Routen zu den Servern, auf denen sie sich befinden (Pathping ist dort ziemlich ordentlich). Wenn es sich nur um einige Elemente handelt, lohnt es sich herauszufinden, was das Gemeinsame ist und warum sie fehlschlagen. Es gibt auch eine geringe Wahrscheinlichkeit, dass es sich um eine ISP-Fehlkonfiguration handelt - mein Heim-ISP hat dies getan, und es war ein völliger Schmerz im Arsch, sie aufzuspüren, und sie wurde eines Tages völlig zufällig behoben
Journeyman Geek

Antworten:


0

Versuchen Sie es, ohne die Netzwerkkarten zu verkleben. Richten Sie nur eine Netzwerkkarte ein und prüfen Sie, ob die Dinge noch funktionieren. Für den Fall, dass sichergestellt ist, dass Ihre Switch-Port-Konfiguration und die Teaming-Konfiguration übereinstimmen.


Mir scheint, dies sollte eher ein Kommentar als eine Antwort sein. Gute Idee. Ich habe eine fehlerhafte NIC-Team-Ursache gesehen, viele seltsame Probleme in meiner Zeit.
HopelessN00b

Bei der Neuinstallation des NIC-Teams haben wir versucht, ohne Team auf nur einer NIC zu laufen. Hat auch nicht funktioniert.
Blaa

0

Um das Problem ohne genaue Fehlermeldung zu diagnostizieren, müssen Sie Folgendes ausführen:

  • tcpdump auf der Client-Seite (Wireshark hat eine schöne Anzeige)
  • tcpdump auf der Serverseite (siehe, was der Server tatsächlich sendet).
  • Warten Sie, bis das Problem auftritt
  • Untersuchen Sie die Pakete und stellen Sie fest, wo die Kommunikation unterbrochen wird. Wenn Sie Hilfe beim Untersuchen des Trace benötigen, schreiben Sie ihn in eine Datei.

Ich vermute, Sie werden eine unbeantwortete DNS-Abfrage finden. Wenn Ihr ISP Ihren Datenverkehr über einen Proxy filtert, sollten Sie in der Lage sein, Spuren davon im Datenverkehr zu finden, insbesondere indem Sie die serverseitige Erfassung mit der clientseitigen Erfassung vergleichen.

Wenn es ein Problem mit der Netzwerkqualität gibt, können Sie es möglicherweise mit Traceroute einfacher beobachten. Wenn der Netzwerkspeicherauszug anzeigt, dass die Kommunikation reibungslos verlief, der Browser die bereitgestellten Daten jedoch nicht anzeigen kann, liegt Ihr Problem bei Desktop-Funnies auf dem Terminalserver.

Sie sollten die Paketerfassung auf dem Terminalserver ausführen, der die Browserverbindung herstellt, die nicht funktioniert.


0

Die Probleme wurden vom ISP "gelöst". Alle Bilder und JS und dergleichen erscheinen jetzt für eine gute Woche normal. Die eine externe Site, die nicht erreichbar ist, wurde vom ISP durch Platzieren eines Proxys zwischen allen aufgelöst.

Leider bleibt der genaue Grund, warum oder wie dies geschehen war, immer noch ein Rätsel, aber es ist sicher, dass etwas, das mein ISP geändert hat, den Trick getan hat.

Vielen Dank für die Unterstützung, und obwohl viele Antworten sehr nützlich waren, kann ich keine davon als die richtige auswählen, daher meine eigene.

Nochmals vielen Dank für all Ihre Zeit und Mühe, und ich hoffe, dass niemand sonst mit einer solchen Fremdheit im Netzwerk fertig werden muss.


1
Ich hatte gehofft, eines Tages so etwas zu sehen!
NickW
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.