Anmelden

Netzwerkfehler systematisch analysieren

Lektion 6 von 6

Praxis: Netzwerkfehler vollständig analysieren

Führe einen vollständigen, dokumentierten Diagnoseablauf an einem fiktiven Netzwerkvorfall durch.

Lernziele

Nach Abschluss dieser Lektion kannst du:

  • ein vollständiges Fehlerbild präzisieren
  • Link, IP, Subnetz und Gateway nacheinander belegen
  • DHCP- und DNS-Evidenz unterscheiden
  • Routing und Rückweg berücksichtigen
  • TCP-Endpunkt und Anwendung getrennt testen
  • acht typische Vorfälle der passenden Schicht zuordnen
  • eine Hypothese aus Evidenz ableiten
  • nur eine begründete Änderung vorschlagen
  • den erwarteten Zustand erneut verifizieren
  • Befund, Root Cause und Lösung nachvollziehbar dokumentieren

Fiktive Labortopologie

Firma.test: gesunder Sollpfad

PC01

192.168.10.50/24

Gateway

192.168.10.1

Routerpfad

192.168.10.0/24 ↔ 192.168.20.0/24

Webserver

192.168.20.20 · TCP 80
DNS/DHCP: 192.168.10.10 · portal.firma.test → 192.168.20.20
Clientnetz
192.168.10.0/24 · PC01 192.168.10.50 · Gateway 192.168.10.1
Infrastruktur
192.168.10.10 stellt im Szenario DNS und DHCP bereit.
Servernetz
192.168.20.0/24 · Webserver 192.168.20.20
Namens- und Dienstbaseline
portal.firma.test → 192.168.20.20 · HTTP auf TCP 80 · http://portal.firma.test/

Alle Hostadressen liegen gültig in den jeweiligen /24-Netzen; der Routerpfad verbindet beide Netze.

13 Diagnosephasen

  1. 1.Benutzerbericht lesen
  2. 2.exaktes Symptom definieren
  3. 3.lokales Interface und Konfiguration prüfen
  4. 4.lokales oder entferntes Ziel bestimmen
  5. 5.Gateway und Pfad testen
  6. 6.DHCP-Evidenz untersuchen
  7. 7.DNS untersuchen
  8. 8.Transportendpunkt des Ziels testen
  9. 9.Anwendungsantwort untersuchen
  10. 10.Hypothese bilden
  11. 11.begründete Lösung konzeptionell auswählen
  12. 12.erwartetes Ergebnis verifizieren
  13. 13.vollständig dokumentieren

Acht Vorfälle, acht begründete Einstiege

Vorfall 1

APIPA / DHCP-Pfad

Evidenz: PC01: 169.254.35.44/16, kein Firmengateway; andere Clients haben normale Leases.

Richtung: Link, lokale Konfiguration und DHCP-Bezugspfad untersuchen. Link-Local beweist weder Serverausfall noch Pool-Erschöpfung; keine Zufalls-IP setzen.

Vorfall 2

Falsche DHCP-DNS-Option

Evidenz: PC01: 192.168.10.50/24, GW 192.168.10.1, DNS 192.168.10.99 statt 192.168.10.10; IP-Pfad zum Server funktioniert.

Richtung: DNS-Konfiguration und deren statische/DHCP-Quelle untersuchen, nicht Routing beschuldigen.

Vorfall 3

Falsche DNS-Antwort

Evidenz: portal.firma.test liefert 192.168.20.30 statt dokumentierter 192.168.20.20.

Richtung: DNS ist verfügbar; Record, Resolver, Cache, View und Datenquelle untersuchen. Kein Timeout.

Vorfall 4

Routingfehler

Evidenz: Clientwerte korrekt, Gateway erreichbar, DNS liefert 192.168.20.20, Zielnetz nicht erreichbar.

Richtung: Hin- und Rückroute zwischen 192.168.10.0/24 und 192.168.20.0/24 untersuchen, DNS nicht ändern.

Vorfall 5

Connection refused

Evidenz: DNS korrekt, Routing ausreichend, TCP 80 wird aktiv abgelehnt.

Richtung: Listener, Dienst, Port, Bindung und ablehnende Policy untersuchen; DHCP ist nicht der erste Bereich.

Vorfall 6

HTTP 404

Evidenz: TCP-Verbindung steht; GET /azubi erhält 404 Not Found.

Richtung: Ressource, Pfad und Anwendungsrouting untersuchen. Der Server war ausreichend erreichbar.

Vorfall 7

HTTP 503

Evidenz: TCP-Verbindung steht; Frontend antwortet 503 Service Unavailable.

Richtung: Dienst, Anwendung, Backend, Wartung und Last untersuchen; Client-IP nicht ändern.

Vorfall 8

Intermittenter IP-Konflikt

Evidenz: PC01 fällt zeitweise aus; ARP-/Neighbor-Zuordnung wechselt; weiteres Gerät könnte dieselbe IPv4-Adresse nutzen.

Richtung: Adressverwaltung und Duplicate-IP-Hypothese lesend belegen; keine offensiven ARP-Techniken.

Evidenzmatrix
EvidenzNächste SchichtNoch nicht bewiesen
169.254.x.xDHCP / lokale KonfigurationDHCP-Server selbst ist nicht als tot bewiesen
NXDOMAINDNS-Namespace / DatenRouting ist nicht zwingend gestört
TCP refusedEndpunkt / Listener / DienstDNS ist nicht zwingend gestört
HTTP 404Ressource / AnwendungsroutingHost ist nicht unerreichbar
HTTP 503Dienst / Anwendung / BackendClient-IP ist nicht automatisch falsch

Lesender Werkzeugkasten

Windows

  • ipconfig /all
  • ping
  • arp -a
  • route print
  • tracert
  • nslookup
  • Test-NetConnection
  • netstat -ano
  • curl

Linux

  • ip addr
  • ip route
  • ip neigh
  • ping
  • tracepath / traceroute
  • dig / nslookup / getent
  • ss -ltn
  • curl

Verfügbarkeit und Ausgabe variieren. Kein Werkzeug ist überall Pflicht; für das Basislabor ist keine Erhöhung erforderlich.

Entscheidungsbaum für den Gesamtpfad
  1. Interface / Link gültig?
  2. IP und Maske plausibel?
  3. Lokales Subnetz?
  4. Gateway und Pfad?
  5. DHCP-Konfiguration / Quelle?
  6. DNS-Antwort korrekt?
  7. Zielport erreichbar?
  8. Anwendungsantwort?
  9. Backend / Dienst?
  10. Dokumentieren

Starke vorhandene Evidenz darf einen gezielten Einstieg an einer späteren Schicht begründen. Der Baum ist ein Denkmodell, kein starres Ritual.

Übung

Symptom zur nächsten Untersuchungsschicht zuordnen

Wähle den stärksten nächsten Untersuchungsbereich – nicht eine vorschnelle Grundursache.

Gesamtfall: Schicht für Schicht eingegrenzt

  1. 1.PC01: 192.168.10.50/24, Gateway 192.168.10.1, DNS 192.168.10.10
  2. 2.Gateway ist erreichbar.
  3. 3.portal.firma.test → 192.168.20.20
  4. 4.Route und Rückpfad funktionieren ausreichend.
  5. 5.TCP 80 ist erfolgreich.
  6. 6.HTTP antwortet 503 Service Unavailable.

Wissenscheck

Stärkster nächster Bereich

Wo setzt die weitere Untersuchung nach dieser Evidenz an?

Vorfall dokumentieren

Benutzerbericht
Beobachtetes Symptom
Umfang
Aktuelle Konfiguration
Test
Ergebnis
Interpretation
Hypothese
Nächster Test
Änderung, falls autorisiert
Verifikation
Root Cause
Finale Lösung

Die Vorlage ist nicht persistent. Sie macht sichtbar, welche Aussage beobachtet, abgeleitet, verändert und anschließend bestätigt wurde.

Typische Fehlvorstellungen

Falsch: „Bei Netzwerkfehlern immer zuerst Adapter zurücksetzen.“
Korrektur: Zuerst Symptome und Konfiguration beobachten.
Falsch: „169.254 = DHCP-Server definitiv offline.“
Korrektur: Mehrere lokale und serverseitige Ursachen bleiben offen.
Falsch: „DNS-Antwort vorhanden = DNS-Daten korrekt.“
Korrektur: Erreichbarkeit und Datenrichtigkeit sind getrennt.
Falsch: „Gateway erreichbar = komplette Route funktioniert.“
Korrektur: Weiterer Hin- und Rückweg bleiben ungetestet.
Falsch: „Porttest erfolgreich = Anwendung funktioniert.“
Korrektur: Protokoll, Fachlogik und Backend bleiben offen.
Falsch: „404 = Netzwerkfehler.“
Korrektur: HTTP hat ausreichend funktioniert, um den Status zu liefern.
Falsch: „503 = Client-IP falsch.“
Korrektur: Der Frontend-Dienst meldet fehlende Anwendungsverfügbarkeit.
Falsch: „Nach erfolgreicher Änderung muss nichts dokumentiert werden.“
Korrektur: Verifikation und Dokumentation sichern Wissen und Nachvollziehbarkeit.
Falsch: „Wenn etwas wieder funktioniert, ist Root Cause automatisch bekannt.“
Korrektur: Korrelation und Seiteneffekte müssen durch kontrollierte Tests ausgeschlossen werden.

Befehlssicherheit

A · lesend / diagnostisch
Erforderlich sind nur bekannte Zieltests und Abfragen wie ipconfig /all, ip addr, ip route, nslookup, dig, getent, Test-NetConnection, netstat -ano, ss -ltn und curl.
B · zustandsändernd, nur konzeptionell
Lease Release/Renew, DNS-Flush, Adapterreset, Route oder Konfiguration ändern und Dienstneustart werden nicht ausgeführt.
C · privilegiert/administrativ, nur konzeptionell
DHCP-/DNS-Server, Relay, Firewall, Dienstbindung oder Serveranwendung ändern erfordert Befund, Freigabe und passende Zuständigkeit.

Dein Lernstand

Lektion in Bearbeitung

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