# Windows Network Diagnostics: Methodische Fehlersuche

TL;DR / Management Summary Netzwerkprobleme sind oft zeitkritisch und komplex. Wir nutzen einen methodischen Layer-für-Layer Ansatz (OSI-Modell). Senior Admins verlassen sich nicht auf den “Netzwerk-Problembehandlung” Wizard, sondern nutzen die Power von PowerShell (Test-NetConnection), Netsh Tracing und PktMon, um Paketverluste und Latenzen präzise zu isolieren.

# 1. Einführung & Das OSI-Workflow

Vom Kabel zur Applikation.

1. Physical (Layer 1): ipconfig /all. Steht das Interface auf “Connected”?
2. Network (Layer 3): ping und tracert. Erreiche ich das Gateway und das Ziel?
3. Transport (Layer 4): Test-NetConnection -Port. Ist der TCP-Port offen?
4. Application (Layer 7): curl / Invoke-WebRequest. Antwortet der Webdienst?

# 2. Die Standard-Tools (Evolution)

Altbewährtes vs. Moderne.

# Ping & PathPing

ping prüft Latenz, pathping zeigt über 10 Minuten, an welchem Router im Internet die Pakete verloren gehen.

pathping 8.8.8.8

# PowerShell: Test-NetConnection (TNC)

Der Allrounder für Admins. Ersetzt ping, telnet und tracert in einem Befehl.

# TCP Port 443 prüfen und Route anzeigen
tnc 10.0.0.50 -Port 443 -InformationLevel Detailed

# 3. Deep Dive: Netsh Tracing

Capturing ohne Wireshark.

Wenn Sie Pakete mitschneiden müssen, aber kein Tool installieren dürfen:

# Startet einen systemweiten Trace inklusive Treiber-Events
netsh trace start scenario=NetConnection capture=yes report=yes persistent=no

# Stoppen und Report generieren
netsh trace stop

Das Ergebnis ist eine .etl Datei, die Sie mit dem Microsoft Message Analyzer oder (nach Konvertierung) mit Wireshark öffnen können.

# 4. Day-2 Operations: DNS-Forensik

Es ist immer DNS.

# DNS-Cache und Resolver-Analyse

# Lokalen Cache anzeigen
Get-DnsClientCache

# DNS-Abfrage explizit über einen Server erzwingen (Bypass Cache)
Resolve-DnsName -Name google.de -Server 1.1.1.1

# 5. Troubleshooting & “War Stories”

Wenn die Verbindung ‘wackelt’.

# Top 3 Fehlerbilder

1. Symptom: “DNS Server nicht antwortet”.

   • Ursache: UDP Port 53 ist durch eine lokale Firewall oder ein Security-Tool blockiert.
   • Lösung: tnc <DNS-IP> -CommonTCPPort HTTP testen (um generelle IP-Connectivity zu prüfen) und Firewall-Logs (Artikel 429) checken.

2. Symptom: Hohe Latenz nur bei Akkubetrieb.

   • Ursache: Power-Management der WLAN-Karte (Artikel 437/449).
   • Lösung: “Höchstleistung” im Energiesparplan für den WLAN-Adapter erzwingen.

3. Symptom: VPN-Client verbindet, aber Outlook geht nicht.

   • Analyse: MTU-Problem (Pakete > 1400 Bytes werden gedroppt).
   • Fix: netsh interface ipv4 set subinterface "VPN" mtu=1300.

# “War Story”: Der “Double-Gateway” Teufel

Ein Server war über RDP extrem langsam. ping zeigte 1ms, aber der Login dauerte 2 Minuten. Die Entdeckung: route print zeigte zwei Default Gateways mit identischer Metrik. Ein Gateway führte ins Leere. Windows versuchte abwechselnd, Pakete über beide Wege zu schicken. Lösung: Manuelle Metrik für das Interface setzen (Set-NetIPInterface -InterfaceAlias "LAN" -InterfaceMetric 10). Lehre: Traue niemals der “Automatischen Metrik” in komplexen Multi-Homed Systemen.

# 6. Monitoring & Alerting

Netzwerk-Health tracken.

# Blackbox-Exporter

Nutzen Sie den Prometheus Blackbox-Exporter, um von einem zentralen Punkt aus die Erreichbarkeit Ihrer Clients via ICMP/TCP zu messen.

• KPI: Packet Loss % und Jitter.

# 7. Fazit & Empfehlung

Netzwerk-Diagnose erfordert Ruhe und Methode.

• Empfehlung: Nutzen Sie PktMon (Artikel 433) für moderne Windows 10/11 Systeme. Es ist performanter und bietet tiefere Einblicke als das alte netsh trace.
• Wichtig: Prüfen Sie immer die Systemzeit (NTP, Artikel 317). Falsche Zeit führt zu Fehlern in SSL/TLS-Handshakes und VPN-Verbindungen.

# Anhang: Cheatsheet

# Referenzen

• Microsoft Learn: Troubleshooting Network Connections
• Test-NetConnection Documentation
• Wireshark Wiki: Capturing on Windows