3.0 Netzwerkfehler systematisch eingrenzen

Nach diesem Kapitel soll eine Netzwerkstörung strukturiert folgenden Bereichen zugeordnet werden können:

• physische Verbindung,
• Netzwerkschnittstelle und Treiber,
• VLAN und Layer-2-Kommunikation,
• IP-Konfiguration und Subnetz,
• DHCP,
• ARP beziehungsweise IPv6 Neighbor Discovery,
• Routing und Standardgateway,
• DNS und Namensauflösung,
• TCP- und UDP-Ports,
• Firewall und Paketfilter,
• NAT und Portweiterleitung,
• Proxy und Reverse Proxy,
• VPN und Tunnel,
• WLAN,
• Netzwerkperformance,
• Paketverlust und Wiederholungen,
• MTU und Fragmentierung,
• interne oder externe Zielsysteme.

Das Ziel ist nicht nur, die Verbindung wiederherzustellen, sondern die tatsächliche Ursache nachvollziehbar zu bestimmen und zu dokumentieren.

Beispiele

[RO] Get-NetIPConfiguration

Der Befehl zeigt die vorhandene Windows-Netzwerkkonfiguration an.

[TEST] ping -c 4 192.0.2.1

Der Befehl sendet aktiv ICMP-Echo-Anfragen.

[PRIV][CHANGE][DISRUPT] Restart-NetAdapter -Name 'Ethernet'

Dieser Befehl startet den Netzwerkadapter neu und unterbricht dabei bestehende Verbindungen. Er darf nicht als erster Diagnoseschritt verwendet werden.

Vor der technischen Analyse sollte der erwartete Kommunikationsweg gezeichnet werden.

Beispiel: Zugriff auf eine interne Anwendung

Client
  → Netzwerkschnittstelle
    → Access Switch
      → VLAN
        → Standardgateway
          → Firewall
            → Reverse Proxy
              → Anwendungsserver
                → Datenbankserver

Beispiel: Internetzugriff

Client
  → Switch oder Access Point
    → lokales Gateway
      → Firewall
        → NAT
          → Internetprovider
            → externes Zielsystem

Beispiel: VPN-Zugriff

Client
  → lokales Netzwerk
    → Internet
      → VPN-Gateway
        → VPN-Tunnel
          → interne Firewall
            → Zielserver

Jede Verbindung besteht aus mehreren möglichen Fehlerstellen. Der Kommunikationsweg verhindert, dass Komponenten untersucht werden, die an der Verbindung überhaupt nicht beteiligt sind.

Die Untersuchung sollte vom Allgemeinen zum Spezifischen erfolgen.

Beispiel

Unzureichende Fehlerbeschreibung:
„Das Netzwerk funktioniert nicht.“

Bessere Fehlerbeschreibung:
„CLIENT-023 kann seit 09:42 Uhr den internen Webserver
app.example.intern nicht über TCP 443 erreichen. Andere interne Server
sind erreichbar. Weitere Clients im selben VLAN sind nicht betroffen.“

Die zweite Beschreibung grenzt die Störung bereits deutlich ein:

• ein Client betroffen,
• ein bestimmtes Ziel betroffen,
• ein bestimmter Dienst betroffen,
• andere Ziele funktionieren,
• der Fehler besitzt einen bekannten Startzeitpunkt.

Diese Reihenfolge darf an das konkrete Fehlerbild angepasst werden. Wenn beispielsweise bereits eine falsche IP-Adresse sichtbar ist, muss nicht zuerst ein entfernter Anwendungsserver untersucht werden.

Wichtiger Hinweis

Das OSI-Modell ist ein Denk- und Strukturierungsmodell. Reale Protokolle und Anwendungen lassen sich nicht immer vollständig einer einzigen Schicht zuordnen.

Praktische Reihenfolge

Link vorhanden?
  ↓
gültige IP-Konfiguration?
  ↓
lokales Gateway erreichbar?
  ↓
Route zum Ziel vorhanden?
  ↓
Name korrekt aufgelöst?
  ↓
Port erreichbar?
  ↓
Anwendungsprotokoll funktioniert?

Bottom-up

Die Untersuchung beginnt auf der untersten Ebene:

Kabel → Link → VLAN → IP → Route → Port → Anwendung

Geeignet bei:

• vollständig fehlender Verbindung,
• unbekannter Fehlerstelle,
• neu aufgebauter Infrastruktur,
• physischen oder lokalen Auffälligkeiten.

Top-down

Die Untersuchung beginnt bei der Anwendung:

Anwendung → Port → DNS → Route → IP → Link

Geeignet bei:

• klarer Anwendungsfehlermeldung,
• nur einem betroffenen Dienst,
• ansonsten funktionierendem Netzwerk,
• bekanntem HTTP-, TLS- oder Authentifizierungsfehler.

Divide-and-Conquer

Die Untersuchung beginnt an einer sinnvollen mittleren Stelle:

Kann der Client das Standardgateway erreichen?

• Wenn nein: Fehler wahrscheinlich lokal oder im lokalen Netz.
• Wenn ja: Untersuchung in Richtung Routing, Firewall und Zielsystem fortsetzen.

Diese Methode ist oft besonders effizient, wenn der Kommunikationsweg bekannt ist.

Ein Vergleich ist besonders aussagekräftig, wenn dabei nur ein relevanter Faktor verändert wird.

Die Platzhalter GATEWAY und ZIEL müssen durch vorher eindeutig bestimmte Adressen oder Namen ersetzt werden.

Jeder Test beantwortet nur eine begrenzte technische Frage. Die Aussage darf nicht weiter ausgedehnt werden, als das Testergebnis tatsächlich belegt.

Hilfreiche Eingrenzungsfragen

Funktioniert derselbe Zugriff von einem anderen Client?

Kann der betroffene Client ein anderes Ziel erreichen?

Funktioniert der Zugriff über die IP-Adresse?

Ist nur ein Port oder sind alle Dienste des Zielsystems betroffen?

Tritt der Fehler per LAN und WLAN auf?

Tritt der Fehler nur bei aktivem VPN auf?

• Änderung einer IP-Adresse oder eines Subnetzes,
• neuer DHCP-Bereich,
• geänderte DNS-Server,
• neue Firewall- oder ACL-Regel,
• VLAN-Änderung am Switchport,
• Firmware- oder Treiberupdate,
• neues Zertifikat,
• Proxyänderung,
• VPN-Client-Update,
• Änderung an NAT oder Portweiterleitung,
• Routingänderung,
• Wechsel des Internetproviders,
• neue Sicherheitssoftware,
• Änderung an Load Balancer oder Reverse Proxy,
• Server- oder Containerupdate,
• Änderung von MTU oder Tunnelkonfiguration,
• Ablauf eines Zertifikats oder Kennworts,
• Wartungsarbeiten am Switch, Router oder Access Point.

Die zeitliche Nähe einer Änderung ist ein wichtiger Hinweis, aber noch kein Beweis für die Ursache.

Vor einer Änderung sollten der Ausgangszustand, die Hypothese, die erwartete Wirkung und der Rückweg dokumentiert werden.

Ungeeignete Vermutung

„Bestimmt ist die Firewall schuld.“

Prüfbare Hypothese

Der Client erreicht das Zielsystem auf ICMP-Ebene, aber der TCP-Verbindungsaufbau
zu Port 443 erhält keine Antwort. Andere Clients im selben VLAN können den Port
erreichen. Deshalb wird eine clientbezogene Filterung oder ein Rückwegproblem
vermutet.

Dazugehörige Prüfungen

1. Quell-IP des betroffenen Clients bestätigen.
2. TCP-Porttest mit Zeitstempel durchführen.
3. Host-Firewall und Sicherheitssoftware prüfen.
4. Firewall-Logs nach Quell- und Zieladresse durchsuchen.
5. Paketmitschnitt am Client und gegebenenfalls am Ziel vergleichen.
6. Funktionierenden Referenzclient gegenüberstellen.

Eine Hypothese muss durch Beobachtungen begründet und durch einen konkreten Test widerlegbar sein.

Ticketnummer:
Meldende Person:
Betroffener Benutzer:
Betroffenes Endgerät:
Standort:
Verbindungsart: LAN / WLAN / VPN / Mobilfunk
Fehlerbeginn:
Zeitzone:
Letzter funktionierender Zeitpunkt:
Fehler reproduzierbar: Ja / Nein
Exakte Fehlermeldung:

Quellhostname:
Quell-IP:
Quell-MAC:
Quell-VLAN:
Quellgateway:
Verwendete DNS-Server:

Zielhostname:
Ziel-IP:
Zielport:
Transportprotokoll:
Anwendungsprotokoll:

Betroffene Benutzer oder Geräte:
Funktionierende Vergleichssysteme:
Weiterhin funktionierende Verbindungen:
Kürzliche Änderungen:

Erwarteter Kommunikationsweg:
1.
2.
3.
4.

Bisherige Prüfungen:
- 
- 
- 

Bisherige Änderungen:
- 
- 
- 

Arbeitshypothese:
Nächster Prüfschritt:
Rückweg bei Änderung:

Eine Eskalation ist sinnvoll oder erforderlich, wenn:

• mehrere Benutzer oder Standorte betroffen sind,
• ein geschäftskritischer Dienst ausgefallen ist,
• ein Sicherheitsvorfall vermutet wird,
• unautorisierte Netzwerkänderungen erkennbar sind,
• Administratorrechte oder Zuständigkeiten fehlen,
• eine Änderung an produktiver Kerninfrastruktur erforderlich wird,
• Provider- oder Herstellerunterstützung benötigt wird,
• redundante Systeme ebenfalls ausfallen,
• die vereinbarte Bearbeitungszeit überschritten wird,
• Paketmitschnitte sensible Daten enthalten,
• Datenverlust oder Manipulation möglich ist.

Eine gute Eskalation enthält:

• klare Fehlerbeschreibung,
• Auswirkung und Priorität,
• betroffene Systeme,
• Beginn und Zeitzone,
• erwarteten Kommunikationsweg,
• bereits durchgeführte Prüfungen,
• Messergebnisse und Logauszüge,
• ausgeschlossene Ursachen,
• aktuelle Hypothese,
• konkrete Frage an die nächste Stelle,
• sichere Kontakt- und Übergabemöglichkeit.

1. Wer ist betroffen?
2. Was genau funktioniert nicht?
3. Was funktioniert weiterhin?
4. Seit wann besteht der Fehler?
5. Was wurde vorher geändert?
6. Welcher Kommunikationsweg wird erwartet?
7. Besteht ein Link?
8. Ist die IP-Konfiguration gültig?
9. Ist das Gateway erreichbar?
10. Existiert eine Route?
11. Funktioniert die Namensauflösung?
12. Ist der Zielport erreichbar?
13. Antwortet die Anwendung?
14. Wo befindet sich der erste belegte Fehler?
15. Welche Messung bestätigt die Ursache?

Kurzform

Umfang → Link → IP → Gateway → Route → DNS → Port → Anwendung

Microsoft

• Grundlagen von TCP/IP
• Get-NetAdapter
• Get-NetIPConfiguration
• Get-NetRoute
• Get-NetNeighbor
• Test-NetConnection
• Resolve-DnsName

Linux

• ip-address – Linux Manual Page
• ip-link – Linux Manual Page
• ip-route – Linux Manual Page
• ip-neighbour – Linux Manual Page
• ss – Linux Manual Page

Apple

• Lokale Befehlsreferenzen: man ifconfig, man route, man netstat, man arp, man ping und man traceroute
• Apple Platform Deployment – Network Services

Wireshark und tcpdump

• Wireshark User’s Guide
• Wireshark Display Filter Reference
• tcpdump Manual Page
• pcap-filter Manual Page

Die genaue Befehlssyntax und die verfügbaren Optionen können von Betriebssystem- und Werkzeugversion abhängen. Vor Änderungen an produktiven Systemen muss zusätzlich die lokale Dokumentation geprüft werden.