13.01.12 | Autor / Redakteur: Jasper Bongertz / Andreas Donner
Arbeiten Server, Clients und Apps scheinbar fehlerfrei, wird häufig das Netzwerk für dennoch auftretende Probleme verantwortlich gemacht. Doch diese Einschätzung ist meist falsch! Wie Wireshark dabei helfen kann, die wahre Ursache der Probleme zu ermitteln, zeigt dieser Beitrag.
Bei der Netzwerkanalyse sucht man oft nach Problemen im Netz, weil alle anderen Beteiligten – wie z.B. Clients, Server oder Applikationen – scheinbar ohne Befund sind. Tatsächlich ist aber nur ein sehr geringer Anteil der dem Netzwerk angelasteten Probleme auch ein echtes Netzwerkproblem.
Viel häufiger kommen sich Anwendungen, nachlässige Entwickler und schlechtes Infrastrukturdesign in die Quere. Ein großer Teil dieser Effekte lässt sich auf Basis einer Messung mit Wireshark gezielt identifizieren, damit die Verantwortlichen sie beheben können.
Einen typischen Problemfall aus der Praxis sehen wir uns jetzt einmal näher an, wobei die Messdaten für den Artikel anonymisiert wurden, insbesondere natürlich die IP-Adressen.
Am Anfang jeder Analyse steht eine Fehlerbeschreibung oder ein Ticket im Helpdesk. Empfehlenswert ist es, sich die Problematik vor der aufwendigen Messung und Analyse erst einmal „live und in Farbe“ demonstrieren zu lassen, um einen persönlichen Eindruck von dem Vorfall zu bekommen.
In unserem Fall meldet der Anwender, dass er problemlos auf verschiedensten Webseiten surfen kann. Nur auf eine bestimmte geschäftskritische Webanwendung bekommt er keinen Zugriff. Die entsprechende Seite lässt sich aus dem Büro nicht öffnen, während es von zu Hause problemlos funktioniert. Ein grob vereinfachtes Netzwerkdiagramm zu dieser Situation zeigt Abbildung 1.
Eine Aufzeichnung der Kommunikation mit Wireshark liefert eine kurze Serie von Paketen, die deutlich auf Probleme hinweist (siehe Abbildung 2).
Ganz offensichtlich versucht der Client mit der IP-Adresse 192.168.1.1, den Server zunächst auf Port 80 zu erreichen, und erhält in Paket 7 den Hinweis, dass der Dienst auf einem anderen Port zu finden ist. Direkt danach startet die nächste Verbindung auf Port 443, was der Standardport für eine per SSL verschlüsselte HTTP-Sitzung ist.
Es folgt der typische SSL-Handshake mit „Client Hello“ in Paket 11, doch der Server bleibt plötzlich stumm – obwohl wir aus den vorherigen Paketen wissen, dass er erreichbar ist und auf dem Port auch ein Dienst arbeitet.
In Paket 13 folgt eine Retransmission des „Client Hello“, aber wiederum scheint es Probleme zu geben, und die Verbindung wird schließlich in Paket 16 per FIN-Paket beendet.
Um das Problem jetzt näher eingrenzen zu können, ist eine zweite „Sicht“ auf die Pakete erforderlich. Als Messpunkt wurde dazu das externe Interface der Firewall gewählt, also die Stelle, an der das Paket das Unternehmen verlässt bzw. an der die eingehenden Pakete aus dem Internet als Erstes eintreffen. Der Seitenaufruf wurde exakt wie zuvor wiederholt und der gesamte Vorgang aufgezeichnet.
Nach dem Filtern aller Verbindungen zu der bekannten Server-IP mit Hilfe des Filters „ip.addr==217.1.1.1“ waren direkt zwei Verbindungen zu sehen, die zu unserer internen Messung passten.
Eine davon war die bereits bekannte Umleitungsverbindung auf Port 80 und die zweite entsprechend die Verbindung auf Port 443. Diese wurde nun über den Verbindungsfilter „(ip.addr==62.1.1.1 and ip.addr ==217.1.1.1) and (tcp.port==31617 and tcp.port==443)“ isoliert.
Abbildung 3 zeigt, dass der Client wie bekannt seine Verbindung aufbaut und sein „Client Hello“ rausschickt. Erstaunlicherweise sehen wir nun auf der externen Seite der Firewall auch den Server mit einem passenden „Server Hello“ antworten – dieses Paket haben wir beim Anwender aber nie erhalten.
Den passenden Grund liefert uns Paket 259: eine „ICMP Destination unreachable“-Meldung vom Typ „Fragmentation needed“, und zwar von der externen IP unserer Firewall an den fremden Server (siehe dazu auch Abbildung 4).
Eine solche Nachricht meldet dem Absender, dass er ein zu großes Paket geschickt hat, mit der Aufforderung, es neu zu senden, aber in kleineren „Happen“. In diesem Fall sollte das Paket die Gesamtlänge von 1.300 Bytes einhalten („MTU of next hop: 1300“, Abbildung 4).
Wie in der Paketliste in Abbildung 3 deutlich zu sehen ist, reagiert der Server jedoch nicht richtig: Er probiert mehrfach, das zu große Paket zuzustellen (z.B. in Paket 324 und 439).
Client und Server können nur mit kleinen Paketen kommunizieren, was ein typischer Indikator für ein MTU-Problem ist. Hierbei zeigt sich dann auch das gern genommene „Ping geht, alles okay“ als trügerisch: Typische Ping-Pakete haben eine Größe von 64 Bytes und würden hier problemlos durchgehen – trotzdem gibt es Probleme, sobald Pakete über 1.300 Bytes ankommen.
Die Frage ist nun, warum es nur Ärger mit diesem einen Server gibt, alle anderen Seiten aber funktionieren? Im Grunde genommen ist dies ganz einfach zu beantworten. Die anderen Server reagieren auf die „Paket zu groß“-Meldung korrekt und senden die Daten erneut in passenden Häppchen.
Vermutlich klappt dies im Problemfall deswegen nicht, weil eine Firewall vor dem Server das ICMP-Paket blockt und der Server so gar nicht bemerken kann, dass er zu große Pakete sendet.
Im vorliegenden Fall wurde das Problem durch einen Umbau der lokalen Strukturen mit Anhebung der MTU auf die üblichen 1.500 Bytes gelöst, und prompt funktionierte auch der Aufruf der gewünschten Webseite problemlos.
Wer sich intensiv mit Wireshark und Netzwerkanalyse auseinandersetzen will, ist in den Wireshark-Kursen von Fast Lane gut aufgehoben. .
Jasper Bongertz ist Senior Consultant und Instructor bei Fast Lane.
Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 31200040)
