EMZETT.
Login

Problemdiagnose (Netzwerk)

Kurz: Das systematische Eingrenzen und Identifizieren der Ursache eines Netzwerkproblems — üblicherweise Schicht für Schicht, orientiert am OSI-Modell.

Genauer: Typisches Vorgehen: erst physische Verbindung prüfen (Kabel/WLAN, Schicht 1), dann Erreichbarkeit testen (Ping, Schicht 3), dann Portverfügbarkeit (Port, Schicht 4), dann die eigentliche Anwendung. Tools wie traceroute, nslookup oder Wireshark helfen, den Fehler einer bestimmten Schicht zuzuordnen statt planlos zu raten.

Im Detail

Ein systematischer Diagnose-Ablauf, Schicht für Schicht:

1. Physical (Schicht 1):    Kabel eingesteckt? Link-LED an? WLAN-Signal vorhanden?
2. Data Link (Schicht 2):   arp -a  (kennt das Gerät seine Nachbarn?)
3. Network (Schicht 3):     ping <ziel>  (ist das Ziel grundsätzlich erreichbar?)
4. Transport (Schicht 4):   telnet <ziel> <port>  (ist der Port offen?)
5. Application (Schicht 7): curl -v <url>  (antwortet die Anwendung korrekt?)

Der Trick an diesem Vorgehen: Sobald ein Schritt fehlschlägt, weiß man sofort, auf welcher Ebene das Problem liegt, statt wahllos alles Mögliche zu testen. traceroute/tracert zeigt zusätzlich jeden einzelnen Router-Hop auf dem Weg zum Ziel an und macht sichtbar, WO genau eine Verbindung ins Stocken gerät. nslookup/dig prüft gezielt, ob ein DNS-Problem vorliegt (löst der Name überhaupt korrekt auf?), bevor man tiefer in der Verbindung selbst sucht. Wireshark erlaubt schließlich, den kompletten Datenverkehr mitzuschneiden und jedes einzelne Paket im Detail zu inspizieren, wenn die einfacheren Tools keine eindeutige Antwort liefern.

Typische Fehlerbilder und ihre Ursachen

Bestimmte Symptome deuten erfahrungsgemäß auf bestimmte Schichten hin: Kein Link-Licht am Netzwerkadapter oder komplett fehlende WLAN-Netze deuten fast immer auf Schicht 1 (Kabel/Hardware). “Destination Host Unreachable” bei einem Ping deutet auf ein Routing-Problem (Schicht 3) — entweder existiert keine Route zum Ziel, oder ein Router unterwegs verwirft das Paket. “Connection Refused” bedeutet, dass das Zielgerät zwar erreichbar ist, aber kein Dienst auf dem angefragten Port lauscht (Schicht 4) — anders als ein Timeout, der oft auf eine Firewall hindeutet, die die Anfrage stillschweigend verwirft, statt sie aktiv abzulehnen.

Top-Down versus Bottom-Up

Die oben gezeigte Reihenfolge (von Schicht 1 nach oben) heißt “Bottom-Up”-Diagnose und eignet sich gut, wenn man nichts über die wahrscheinliche Ursache weiß. Erfahrene Techniker arbeiten oft “Top-Down” oder “Divide-and-Conquer”: Sie beginnen mit einem Test in der Mitte des Stapels (z. B. direkt einem Ping) und entscheiden je nach Ergebnis, ob sie tiefer (Richtung Hardware) oder höher (Richtung Anwendung) weitersuchen — spart Zeit, wenn man aufgrund der Symptome schon eine Vermutung hat, wo das Problem wahrscheinlich liegt.

Siehe auch: Ping, Wireshark, OSI-Modell