Anmelden

Netzwerkfehler systematisch analysieren

Lektion 1 von 6

Systematisch statt raten: Die Troubleshooting-Methode

Definiere Fehlerbilder präzise, sammle Evidenz und prüfe testbare Hypothesen kontrolliert.

Lernziele

Nach Abschluss dieser Lektion kannst du:

  • ein Problem präzise formulieren
  • Benutzerbeschreibung und beobachtete Fakten trennen
  • Umfang, Häufigkeit und letzte Änderungen erfassen
  • eine Known-Good-Baseline vergleichen
  • eine testbare Hypothese bilden
  • jeweils eine begründete Änderung durchführen
  • Lösung durch erneuten Test verifizieren
  • Diagnose und Ergebnis dokumentieren
  • Bestätigungsfehler und zufälliges Trial-and-Error vermeiden

Symptom ist nicht Ursache

„Internet geht nicht.“ ist ein Benutzerbericht und zunächst nur eine Symptombeschreibung. Dahinter können getrenntes WLAN, eine unpassende IP-Adresse, ein fehlendes Default Gateway, ein DNS-Problem, nur eine ausgefallene Website, ein Proxy-/Dienstproblem oder eine reine Browserstörung stehen.

Übersetze einen Bericht nie direkt in eine Grundursache. Formuliere stattdessen eine überprüfbare Beobachtung, zum Beispiel: „PC01 ist per WLAN verbunden; nslookup portal.firma.test liefert einen Timeout, ein bekannter IP-Endpunkt ist jedoch erreichbar.“

Umfang und Reproduzierbarkeit

  • Ein Benutzer oder viele?
  • Ein Gerät oder viele?
  • Eine Anwendung oder alle?
  • Ein Hostname oder jeder Name?
  • Nur das lokale Netz oder auch entfernte Ziele?
  • Kabel oder WLAN – und das richtige Netz/SSID?
  • Ständig oder zeitweise?
  • Seit wann?
  • Was wurde zuletzt geändert?

Diese Fragen grenzen den Fehlerraum ein. Ein reproduzierbares Fehlerbild lässt sich gezielt testen; bei sporadischen Fehlern werden Zeitpunkt, Häufigkeit und Begleitumstände besonders wichtig.

Known Good ist Vergleich, keine Kopiervorlage

Der betroffene PC nutzt 192.168.10.50/24, ein funktionierender Nachbar 192.168.10.60/24. Vergleiche IP, Maske, Gateway, DNS, Netz/VLAN, DHCP oder statische Konfiguration sowie Routen.

Die Baseline liefert Evidenz über erwarteten Zustand. Sie erlaubt nicht, fremde IP- oder DNS-Werte blind zu kopieren: Geräte können bewusst andere Rollen, Reservierungen oder Routen besitzen.

Annahme oder Evidenz?

Annahme

„DNS ist kaputt.“

Beobachtung

nslookup server.firma.test liefert einen Timeout.

Annahme

„Das Gateway ist kaputt.“

Beobachtung

Der Client erreicht einen bekannten Same-Subnet-Peer, aber nicht die erwartete Gateway-Adresse.

Annahme

„Der Server ist down.“

Beobachtung

DNS löst auf und der Pfad ist plausibel, aber der TCP-Endpunkt lehnt die Verbindung ab.

Auch Evidenz bestimmt nicht automatisch eine einzige Ursache. Sie grenzt den nächsten sinnvollen Untersuchungsbereich ein.

Die evidenzbasierte Methode

  1. 1. Beobachten
  2. 2. Problem präzise definieren
  3. 3. Evidenz sammeln
  4. 4. betroffene Schicht eingrenzen
  5. 5. testbare Hypothese bilden
  6. 6. Hypothese testen
  7. 7. nur begründet ändern
  8. 8. erneut verifizieren
  9. 9. Befund und Ergebnis dokumentieren

Eine Hypothese muss durch einen erwartbaren Test bestätigt oder widerlegt werden können. Suche auch nach Beobachtungen, die deiner Vermutung widersprechen – das reduziert Confirmation Bias.

Vom Bericht zur belegten Lösung
  1. Problem gemeldet
  2. Umfang eingrenzen
  3. Aktuelle Konfiguration
  4. Lokale Verbindung
  5. Gateway und Routing
  6. Unterstützende Dienste
  7. Zieldienst und Anwendung
  8. Hypothese
  9. Kontrollierte Aktion
  10. Erneut testen und dokumentieren

Der Ablauf ist ein praktisches Denkmodell, keine starre OSI-Prüfliste. Beobachtungen können einen gezielten Sprung zur wahrscheinlich betroffenen Schicht begründen.

Schichtweise denken, nicht starr auswendig lernen

  1. Physical/Link
  2. lokale Schnittstelle und Konfiguration
  3. lokales Subnetz
  4. Gateway und Routing
  5. DHCP, DNS und unterstützende Dienste
  6. Transport und Dienstport
  7. Anwendung

Dieses Modell hilft bei der Auswahl des nächsten Tests. Es ist keine Behauptung, jeder reale Vorfall müsse streng und vollständig von oben nach unten abgearbeitet werden.

Werkzeuge passend zur Frage wählen

Windows

  • ipconfig /all
  • ping
  • tracert
  • route print
  • nslookup
  • Test-NetConnection

Linux

  • ip addr
  • ip route
  • ping
  • traceroute oder tracepath
  • getent, nslookup oder dig
  • ss
  • curl

Ping ist kein universeller Gesundheitstest

Wissenscheck

Erster sinnvoller Schritt

Ein Benutzer sagt: „Der Server geht nicht.“ Was ist die beste erste Reaktion?

Vier Änderungen, keine klare Erkenntnis

Du änderst gleichzeitig IP, DNS, Gateway und Firewall; danach verschwindet das Symptom. Das ist schlechte Diagnose: Du weißt nicht, welche Änderung relevant war, ob die Hypothese stimmte oder welche unnötigen Abweichungen und Sicherheitsrisiken entstanden sind.

Besser: Beobachtung → Hypothese → eine kontrollierte, autorisierte Änderung → gleicher Retest → Dokumentation.

Praxis: Vage Berichte präzisieren

Formuliere für jeden Bericht testbare Fragen: „Internet geht nicht“, „Server nicht erreichbar“, „Drucker geht nicht“, „Website lädt nicht“ und „Netzlaufwerk weg“.

Beispiel Website: Löst der Name auf? Funktioniert eine andere Website? Ist der Ziel-IP-/Dienstpfad erreichbar? Kommt eine HTTP-Antwort? Betrifft es einen Browser oder mehrere Clients?

Typische Fehlvorstellungen

Falsch: „Der Benutzer sagt DNS ist kaputt, also beginne ich bei DNS.“
Korrektur: Der Bericht ist eine Hypothese; Umfang und technische Evidenz bestimmen den Einstieg.
Falsch: „Ping funktioniert = Netzwerk komplett okay.“
Korrektur: ICMP-Erfolg prüft weder DNS noch Port oder Anwendung.
Falsch: „Ping funktioniert nicht = Gerät definitiv offline.“
Korrektur: ICMP kann gefiltert sein oder anders behandelt werden.
Falsch: „Viele Änderungen gleichzeitig sparen Zeit.“
Korrektur: Sie verhindern eine eindeutige Zuordnung von Ursache und Wirkung.
Falsch: „Neustart ist eine Diagnose.“
Korrektur: Ein Neustart kann Zustand verändern, erklärt aber allein keine Grundursache.
Falsch: „Wenn es nach einer Änderung funktioniert, war die Vermutung automatisch korrekt.“
Korrektur: Korrelation, Seiteneffekte und mehrere gleichzeitige Änderungen müssen ausgeschlossen werden.

Dein Lernstand

Lektion in Bearbeitung

Das Öffnen startet die Lektion. Als erledigt zählt sie erst nach deiner ausdrücklichen Bestätigung.