Ein nicht ganz alltäglicher Kundeneinsatz: Kunde beklagt, er hätte Zugangsprobleme im Netz und teilweise unheimlich hohe Latenzen bis überhaupt eine Seite aufgebaut wird – teilweise schlägt auch der Seitenaufbau komplett fehl. Insgesamt problematisch: Das Problem ist nicht 100% reproduzierbar – es tritt immer wieder mal auf – meist mehrmals täglich, aber ohne erkennbaren Zusammenhang. Alles sehr neblig und diffus …
Der Kunde verwendet einen internen Nameserver – erster Verdacht: Da läuft was schief und die Kiste macht irgendwas was die Verzögerungen auslöst… Test mit dem eigenen Rechner, sowohl über das WLAN des Kunden, als auch über das Kabel: der Server antwortet und das sogar ziemlich pronto.
Zweiter Anlauf: Analyse des DHCP-Eintrags: da steht noch ein providerspezifischer DNS-Server drin, Eintrag mal deaktiviert, vielleicht stimmt die Adresse ja nicht mehr. Weiterhin keine Besserung und am Testrechner lief alles ohne Probleme – zudem beschränkte sich das Problem auf eine ausgewählte Menge Rechner, zwischen denen aber erst mal kein logischer Zusammenhang herzustellen war…
Also eine eingehende Analyse und somit das Ohr rauf auf die Netzwerkschiene: Einfach mal zuhören was im Netzwerk so läuft. Dort ist es vergleichsweise ruhig – von den gelegentlichen Abrufen von e-mails und den Broadcasts der Windows-Kisten über deren Shares ist alles normal. Auch die Anfragen an den Server finden sich wieder. Auffallend: Die Antworten des Servers kommen innerhalb nur weniger Millisekunden, die erlebte Wartezeit bis überhaupt eine Verbindung aufgebaut wird sind aber typischerweise mehr als 5 Sekunden … irgendwas stimmt also doch nicht.
Nachdem der Server nun wirklich aller Schuld entlastet ist, gehts mit der Fehlersuche auf dem Client weiter: Nach dem Leeren des DNS-Cache lässt sich der Fehler schön beobachten. Am Server verfolge ich parallel die Netzwerkaktivität – da muss das Paket ja irgendwann zwangsläufig vorbei kommen … WireShark bzw. tcpdump wird es nicht entgehen. Erstmal wird bestätigt: Den Server trifft keine Schuld – denn beim Absenden eines Lookup-Befehls vergehen erst etliche Sekunden bis überhaupt was an den Server geschickt wird, der dann auch zügig antwortet.
Auf dem Rechner selbst: Keine auffälligen Programme, keine erkannte Malware, einfach nichts. Auch die Analyse und das Abstellen einiger Zusatzfunktionen im IP-Stack bringen keine Verbesserung – ein wenig Ratlosigkeit macht sich beim Admin breit… Auch das Beenden aller nicht systemwichtigen Prozesse ändert nichts an der Situation. Der Prozess Monitor für Windows bringt schließlich einen vielversprechenden Ansatz – mit ihm lassen sich die Systemaktivitäten etwas genauer analysieren – es zeigt sich, dass der Rechner relativ lange auf der hosts-Datei herumnudelt – diese wird normalerweise verwendet, wenn man keinen DNS Server im internen Netz hat – sozusagen ein Mini-DNS für ganz arme oder ganz spezielle Fälle.
Bereits auffällig: Die Datei ist für eine Konfigurationsdatei reichlich dick – etwas mehr als 400kB – reiner Text …
Der Texteditor erhärtet den Verdacht: Spybot Search and Destroy – eigentlich ein sehr praktisches Tool zur Malware Erkennung hat die Datei mit ettlichen Einträgen aufgefüllt, so wird effektiv verhindert, dass der Rechner überhaupt auf irgendwelche Domains mit bekannter Schadsoftware zugreifen kann. Nur in diesem Fall ist es einfach etwas zuviel des Guten – denn der Rechner analysiert jedesmal erst diese Datei bevor er sich ins Netzwerk wendet … und je nachdem ob die gerade im Cache liegt oder erst von Platte gelesen und analysiert werden muss gibt es doch eine merkliche Latenz … Schmeißt man die Einträge raus (oder verschiebt die Datei einfach – dabei aufpassen, dass Spybot es nicht als Angriff wertet und sie stillschweigend wieder herstellt), ist die Reaktion plötzlich wie erwartet – alles läuft einfach so zügig wie man es erwartet.
Also ggf. mal einen Blick in diese Datei werfen … manchmal fallen einem doch wirklich Backsteine aus dem Anfang der Netzwerkzeit wirklich auf die Füße.