6. Netzwerk- und Verbindungsfehler

6.1 Client ohne Netzwerkverbindung – systematische Ende-zu-Ende-Analyse
6.2 Mehrere Clients oder ganzer Standort ohne Netzwerk
6.3 IP-Adresse erreichbar, Name nicht – DNS- und Namensauflösungsfehler
6.4 Host erreichbar, Dienst nicht – Ports, Firewall und Anwendungen systematisch prüfen
6.5 Netzwerk ist langsam – Latenz, Paketverlust und Durchsatz systematisch analysieren
6.6 Fehler tritt nur manchmal auf – sporadische Störungen systematisch erfassen und korrelieren
6.7 Anmeldung an der Domäne geht nicht

6.1 Client ohne Netzwerkverbindung – systematische Ende-zu-Ende-Analyse

Ein Client meldet „Kein Internet“, erreicht keine internen Systeme oder kann einzelne Netzwerkdienste nicht verwenden. Diese Beschreibung benennt zunächst nur das sichtbare Symptom. Sie beweist weder einen Kabeldefekt noch einen Ausfall des Routers oder Internetzugangs.

Die Ursache kann an unterschiedlichen Stellen liegen:

physische Verbindung,
WLAN-Verbindung,
Netzwerkadapter,
VLAN-Zuordnung,
IP-Konfiguration,
DHCP,
ARP beziehungsweise IPv6 Neighbor Discovery,
Standardgateway,
Routing,
DNS,
Firewall,
Proxy,
VPN,
Authentifizierung,
Zielsystem,
Anwendung,
Internetzugang.

Die Fehleranalyse muss deshalb vom betroffenen Client schrittweise bis zum Ziel erfolgen.

1. Lernziele

Nach dieser Seite kannst du:

eine ungenaue Störungsmeldung in ein prüfbares Fehlerbild übersetzen,
den betroffenen Umfang bestimmen,
physische Verbindung und logische Erreichbarkeit unterscheiden,
IPv4- und IPv6-Konfigurationen bewerten,
DHCP-, Gateway-, Routing- und DNS-Probleme auseinanderhalten,
lokale und entfernte Fehler voneinander abgrenzen,
geeignete Vergleichstests durchführen,
typische Fehlinterpretationen vermeiden,
Maßnahmen kontrolliert ausführen,
Ursache, Lösung und Nachprüfung dokumentieren.

2. Ausgangssituation

Ein Benutzer meldet:

„Mein Computer hat kein Netzwerk.“

Diese Aussage lässt entscheidende Fragen offen:

Ist Ethernet oder WLAN betroffen?
Besteht überhaupt eine Verbindung zum lokalen Netzwerk?
Funktioniert nur das Internet nicht?
Sind interne Systeme erreichbar?
Ist nur eine Anwendung betroffen?
Funktionieren Ziele über IP-Adresse, aber nicht über Namen?
Sind weitere Benutzer oder Geräte betroffen?
Trat das Problem plötzlich oder nach einer Änderung auf?
Ist der Fehler dauerhaft oder nur zeitweise vorhanden?
Funktioniert eine andere Netzwerkverbindung?
Ist ein VPN aktiv?
Wird ein Proxy verwendet?
betrifft das Problem IPv4, IPv6 oder beide Protokolle?

Vor technischen Eingriffen muss aus der allgemeinen Meldung ein eindeutig prüfbares Symptom entstehen.

3. Fehlerbild präzisieren

Geeignete Fragen sind:

Welche konkrete Anwendung funktioniert nicht?
Welche Adresse oder welcher Dienst soll erreicht werden?
Welche Fehlermeldung wird angezeigt?
Seit wann besteht der Fehler?
Funktionierte die Verbindung zuvor?
Was wurde unmittelbar vorher verändert?
Sind interne und externe Ziele gleichermaßen betroffen?
Funktioniert der Zugriff über eine IP-Adresse?
Funktioniert der Zugriff über einen DNS-Namen?
Sind andere Geräte am selben Standort betroffen?
Funktioniert der Client über ein anderes Netzwerk?
Tritt der Fehler mit einem anderen Benutzerkonto ebenfalls auf?
Besteht der Fehler nur bei aktivem VPN?
Ist ein bestimmtes WLAN, Kabel, Dock oder VLAN beteiligt?

Beispiel für ein präzisiertes Fehlerbild

Client: Notebook NB-204
Verbindung: Ethernet über USB-C-Dockingstation
Standort: Gebäude B, Raum 204
Beginn: heute nach dem Wechsel des Arbeitsplatzes
Lokale Linkanzeige: aktiv
IPv4-Adresse: 169.254.37.18/16
Standardgateway: nicht vorhanden
Interne und externe Ziele: nicht erreichbar
Weitere Clients an derselben Datendose: ebenfalls ohne DHCP-Adresse
WLAN-Verbindung des Notebooks: funktioniert

Damit ist die Untersuchung wesentlich stärker eingegrenzt als durch die ursprüngliche Aussage „Kein Netzwerk“.

4. Zuerst den Umfang bestimmen

Beobachtung	wahrscheinlicher Untersuchungsbereich
nur eine Anwendung betroffen	Anwendung, Dienst, Port, Proxy, Zertifikat oder Berechtigung
nur ein Ziel betroffen	Zielsystem, Zielnetz, DNS-Eintrag oder Route
nur ein Client betroffen	Client, Adapter, Kabel, Port oder lokale Konfiguration
mehrere Clients an einem Switch betroffen	Switch, Uplink, VLAN, Stromversorgung oder zentrale Dienste
nur ein VLAN betroffen	VLAN-Konfiguration, Trunk, Gateway, DHCP-Relay oder ACL
nur WLAN betroffen	Access Point, Authentifizierung, Funkversorgung oder WLAN-Konfiguration
interne Ziele erreichbar, Internet nicht	Gateway, Firewall, NAT, Proxy oder Provider
Internet erreichbar, interne Ziele nicht	internes Routing, VPN, DNS, Firewall oder Berechtigung
IP-Adressen funktionieren, Namen nicht	DNS-Konfiguration oder Namensauflösung
Namen werden aufgelöst, Verbindung scheitert	Routing, Firewall, Dienst, Port oder Anwendung
nur ein Standort betroffen	Standortanbindung, lokales Gateway, WAN oder Standort-Firewall
alle Systeme betroffen	zentrale Netzwerkkomponente, DNS, DHCP, Firewall, WAN oder Stromversorgung

Der Umfang ist einer der wichtigsten Hinweise auf die Fehlerdomäne. Ein lokaler Eingriff am Client ist nicht sinnvoll, wenn gleichzeitig ein vollständiges VLAN oder ein ganzer Standort betroffen ist.

5. Ausgangszustand sichern

Vor Änderungen sollten mindestens dokumentiert werden:

Datum und Uhrzeit,
betroffener Client,
Benutzerkontext, soweit erforderlich,
Standort,
Anschlussart,
Dockingstation oder Adapter,
Switchport, sofern bekannt,
SSID bei WLAN,
IP-Adressen,
Präfix beziehungsweise Subnetzmaske,
Standardgateway,
DNS-Server,
DHCP-Status,
Routingtabelle,
Proxy- und VPN-Status,
genaue Fehlermeldung,
erreichbare und nicht erreichbare Ziele,
bereits ausgeführte Maßnahmen,
letzte bekannte funktionierende Nutzung,
vorausgegangene Änderungen.

Windows

Get-Date
Get-NetAdapter
Get-NetIPConfiguration
Get-NetIPAddress
Get-NetRoute
Get-DnsClientServerAddress
ipconfig /all
route print

Linux

date
ip link
ip address
ip route
resolvectl status
nmcli device status

macOS

date
networksetup -listallhardwareports
ifconfig
route -n get default
scutil --dns

Je nach Betriebssystem, Version und Netzwerkkonfiguration können einzelne Befehle oder Ausgaben abweichen.

6. Prüfreihenfolge

Fehlerbild präzisieren
→ Umfang bestimmen
→ Ausgangszustand dokumentieren
→ physische Verbindung prüfen
→ Netzwerkadapter prüfen
→ IP-Konfiguration bewerten
→ lokales Protokoll prüfen
→ Standardgateway testen
→ Routing untersuchen
→ DNS getrennt testen
→ Zielport und Dienst prüfen
→ Firewall, Proxy und VPN berücksichtigen
→ kontrollierten Vergleichstest durchführen
→ Maßnahme umsetzen
→ erneut messen
→ Funktion und Nebenwirkungen prüfen
→ Ursache und Lösung dokumentieren

Diese Reihenfolge ist kein starres Schema. Sie verhindert jedoch, dass ohne ausreichende Eingrenzung gleichzeitig Kabel, Einstellungen, Treiber und Netzwerkkomponenten verändert werden.

7. Physische Verbindung prüfen

Bei Ethernet sind zu prüfen:

sitzt das Kabel an beiden Seiten vollständig?
zeigt der Netzwerkadapter einen Link?
zeigt der Switchport einen Link?
ist das Kabel sichtbar beschädigt?
wird eine Dockingstation oder ein USB-Netzwerkadapter verwendet?
wird der richtige Anschluss verwendet?
ist der Switchport aktiviert?
stimmt die ausgehandelte Geschwindigkeit?
steigen Fehler- oder Verwerfungszähler?
befindet sich der Anschluss im erwarteten VLAN?
liefert die Dockingstation zuverlässig Strom?
funktioniert ein geprüftes Vergleichskabel?
funktioniert ein bekanntermaßen geeigneter Vergleichsport?

Windows

Get-NetAdapter
Get-NetAdapterStatistics

Linux

ip -s link
ethtool <schnittstelle>

macOS

ifconfig <schnittstelle>
networksetup -getMedia <netzwerkdienst>

<schnittstelle> muss durch den tatsächlichen Schnittstellennamen ersetzt werden.

Mögliche Beobachtungen

Beobachtung	mögliche Einordnung
kein Link auf beiden Seiten	Kabel, Port, Adapter, Stromversorgung oder deaktivierte Schnittstelle
Link nur mit 100 Mbit/s statt 1 Gbit/s	Adernpaar, Auflegung, Kabelqualität oder Aushandlung
Link wechselt wiederholt	Kontaktproblem, Kabel, Adapter, Dock, Port oder Stromversorgung
hohe CRC- beziehungsweise FCS-Fehler	physische Signalstörung, Kabel, Stecker oder Port
viele Drops ohne physische Fehler	Überlastung, Puffer, QoS oder Systemressourcen
anderer Switchport funktioniert	ursprünglicher Port oder dessen Konfiguration
anderes Kabel funktioniert	ursprüngliches Kabel oder veränderter Steckkontakt verdächtig
direkte Verbindung funktioniert, Dock nicht	Dock, USB-Verbindung, Treiber oder Stromversorgung

Dass der Link aktiv ist, bestätigt nur eine Verbindung auf der Bitübertragungsschicht. Eine richtige IP-Konfiguration, VLAN-Zuordnung oder Ende-zu-Ende-Erreichbarkeit ist damit nicht bewiesen.

8. WLAN-Verbindung prüfen

Bei WLAN sind zusätzlich zu prüfen:

ist WLAN aktiviert?
befindet sich das Gerät im Flugmodus?
ist die richtige SSID ausgewählt?
wurde die Authentifizierung erfolgreich abgeschlossen?
besitzt das Gerät eine IP-Konfiguration?
ist das Signal ausreichend?
ist der Signal-Rausch-Abstand ausreichend?
besteht eine Captive-Portal-Anmeldung?
ist das Gerät im richtigen VLAN?
greift eine Geräte- oder Benutzerzulassung?
besteht eine auffällige Kanalnutzung?
funktioniert derselbe Client an einem anderen Standort?
funktioniert ein Vergleichsclient am betroffenen Standort?
wird zwischen verschiedenen Access Points oder Frequenzbändern gewechselt?

Windows

netsh wlan show interfaces
netsh wlan show networks mode=bssid

Linux mit NetworkManager

nmcli device status
nmcli device wifi list
nmcli connection show --active

macOS

networksetup -getairportnetwork en0
system_profiler SPAirPortDataType

Der tatsächliche Schnittstellenname kann abweichen.

Wichtige Unterscheidung

mit SSID verbunden
≠ erfolgreich authentifiziert
≠ richtige VLAN-Zuordnung
≠ gültige IP-Konfiguration
≠ erreichbares Standardgateway
≠ funktionsfähiger DNS-Dienst
≠ erreichbares Internet

9. Zustand des Netzwerkadapters prüfen

Ein Netzwerkadapter kann vorhanden, aber nicht funktionsfähig sein.

Zu prüfen sind:

Schnittstelle aktiviert oder deaktiviert,
administrativer Zustand,
operativer Zustand,
Treiberstatus,
Firmwarestatus,
Hardwareerkennung,
MAC-Adresse,
Geschwindigkeit und Duplex,
Energieverwaltung,
virtuelle Netzwerkadapter,
VPN-Adapter,
Bridging,
Teaming oder Bonding,
auffällige Fehlerzähler,
wiederholte Trennung und Neuverbindung.

Windows

Get-NetAdapter
Get-NetAdapterAdvancedProperty
Get-NetAdapterPowerManagement
Get-PnpDevice -Class Net

Linux

ip link
ip -s link
lspci -k
lsusb
ethtool <schnittstelle>

macOS

networksetup -listallhardwareports
ifconfig
system_profiler SPNetworkDataType

Ein Treiberupdate oder eine Neuinstallation sollte nicht die erste Maßnahme sein, solange der aktuelle Zustand noch nicht ausreichend dokumentiert und eingegrenzt wurde.

10. IPv4-Konfiguration bewerten

Eine vollständige IPv4-Konfiguration umfasst normalerweise:

IPv4-Adresse,
Subnetzmaske beziehungsweise Präfixlänge,
Standardgateway,
DNS-Server,
gegebenenfalls DHCP-Server,
Lease-Zeiten,
verbindungsspezifisches DNS-Suffix,
zusätzliche statische Routen.

Beispiel

IPv4-Adresse: 192.168.10.24
Präfix: /24
Standardgateway: 192.168.10.1
DNS-Server: 192.168.10.10 und 192.168.10.11
DHCP-Server: 192.168.10.5

Bei /24 gehören beispielsweise 192.168.10.24 und 192.168.10.1 zum selben IPv4-Subnetz.

Typische Auffälligkeiten

Beobachtung	mögliche Ursache
keine IPv4-Adresse	Adapter, DHCP, VLAN oder Konfiguration
Adresse aus `169.254.0.0/16`	keine nutzbare DHCP-Antwort oder bewusst verwendete Link-Local-Adresse
Adresse `0.0.0.0`	Initialisierung oder Adresszuweisung fehlgeschlagen
falsches Subnetz	statische Fehlkonfiguration oder falscher DHCP-Bereich
kein Standardgateway	DHCP-Option fehlt oder statische Konfiguration unvollständig
falscher DNS-Server	DHCP-Option, VPN, manuelle Konfiguration oder Richtlinie
doppelte IP-Adresse	Adresskonflikt
sehr kurze Lease-Zeit	DHCP-Konfiguration oder Sondernetz
mehrere Gateways	mehrdeutiges Routing oder mehrere aktive Adapter
gültige Adresse, Gateway nicht erreichbar	VLAN, Layer 2, Gateway, ARP oder Firewall
Gateway erreichbar, entfernte IP nicht	Routing, Firewall, NAT oder Zielpfad

11. Automatische private IPv4-Adresse richtig einordnen

Erhält ein Windows-Client keine geeignete DHCP-Konfiguration, kann er automatisch eine Adresse aus 169.254.0.0/16 verwenden. Dieser Bereich ist für IPv4 Link-Local-Adressen vorgesehen.

Eine solche Adresse bedeutet nicht automatisch:

dass der DHCP-Server ausgeschaltet ist,
dass das Netzwerkkabel defekt ist,
dass der Switch ausgefallen ist,
dass der Client überhaupt keine Verbindung besitzt.

Mögliche Ursachen sind:

DHCP-Server nicht erreichbar,
DHCP-Dienst ausgefallen,
falsches VLAN,
fehlerhafter DHCP-Relay-Agent,
erschöpfter DHCP-Adressbereich,
DHCP-Antwort durch Sicherheitsfunktion blockiert,
fehlerhafte Portkonfiguration,
beschädigte Verbindung,
Clientfehler,
verzögerte Adressvergabe.

Zu prüfen sind

physischer Link
→ VLAN-Zuordnung
→ DHCP-Anforderung
→ DHCP-Weiterleitung
→ DHCP-Server
→ verfügbarer Adressbereich
→ DHCP-Angebot
→ Clientannahme

12. DHCP systematisch untersuchen

Der vereinfachte IPv4-DHCP-Ablauf wird häufig als DORA bezeichnet:

DHCPDISCOVER
→ DHCPOFFER
→ DHCPREQUEST
→ DHCPACK

Je nach Zustand und Erneuerung eines Leases können andere DHCP-Nachrichten auftreten.

Windows

ipconfig /all
ipconfig /release
ipconfig /renew

Linux mit NetworkManager

nmcli device show
nmcli connection show --active

macOS

ipconfig getpacket <schnittstelle>
networksetup -getinfo <netzwerkdienst>

Eine Lease-Erneuerung verändert den Zustand und sollte nur kontrolliert ausgeführt werden.

Mögliche Fehlerstellen

Phase	mögliche Ursache
Discover verlässt Client nicht	Schnittstelle, Clientdienst, lokale Firewall oder Treiber
Discover erreicht Server nicht	VLAN, Switch, DHCP Snooping, Relay oder Routing
Server sendet kein Offer	Dienst, Bereich, Reservierung, Richtlinie oder Adressmangel
Offer erreicht Client nicht	Relay, VLAN, Sicherheitsfunktion oder Rückweg
Client sendet keinen Request	Clientzustand oder ungeeignetes Angebot
Server sendet kein ACK	Konflikt, Richtlinie, Bereich oder Serverfehler
ACK erreicht Client nicht	Netzwerkpfad oder Sicherheitsfunktion
Adresse vorhanden, Optionen fehlen	DHCP-Optionen oder Gültigkeitsbereich fehlerhaft

Bei DHCP zusätzlich prüfen

ist der richtige DHCP-Bereich aktiv?
sind freie Adressen vorhanden?
bestehen Ausschlüsse oder Reservierungen?
stimmt die Subnetzmaske?
wird das richtige Gateway verteilt?
werden geeignete DNS-Server verteilt?
stimmt der DHCP-Relay-Eintrag?
ist DHCP Snooping korrekt konfiguriert?
existiert ein nicht autorisierter DHCP-Server?
erscheinen Fehler oder Konflikte im DHCP-Protokoll?

13. IPv6 nicht übersehen

Ein Client kann gleichzeitig IPv4 und IPv6 verwenden. Daher können Fehler nur eines Protokollstapels zu scheinbar widersprüchlichen Ergebnissen führen.

Zu prüfen sind:

Link-Local-Adresse,
globale oder lokale IPv6-Adresse,
Präfixlänge,
Standardroute,
Router Advertisement,
DNS-Server,
DHCPv6, sofern eingesetzt,
Duplicate Address Detection,
Neighbor Discovery,
Übergangs- oder Tunnelmechanismen,
IPv6-Firewallregeln.

Windows

Get-NetIPAddress -AddressFamily IPv6
Get-NetRoute -AddressFamily IPv6
ipconfig /all

Linux

ip -6 address
ip -6 route
ip -6 neighbor

macOS

ifconfig
netstat -rn -f inet6

Wichtige Einordnung

Eine Adresse aus fe80::/10 ist eine IPv6-Link-Local-Adresse.
Link-Local-Adressen gelten nur auf dem jeweiligen Link.
Bei der Verwendung einer Link-Local-Adresse kann eine Schnittstellenangabe erforderlich sein.
Ein funktionierendes IPv6 kann einen defekten IPv4-Pfad teilweise verdecken.
Ein fehlerhafter IPv6-Pfad kann Verzögerungen erzeugen, obwohl IPv4 funktioniert.
IPv6 sollte nicht allein zur Fehlerumgehung pauschal deaktiviert werden.

14. Lokalen Protokollstapel prüfen

Vor externen Zielen kann zunächst der lokale TCP/IP-Stapel geprüft werden.

IPv4

127.0.0.1

IPv6

::1

Windows

ping 127.0.0.1
ping ::1

Linux und macOS

ping 127.0.0.1
ping6 ::1

Abhängig vom Betriebssystem kann der IPv6-Befehl auch über ping -6 erfolgen.

Ein erfolgreicher Loopback-Test bestätigt Teile des lokalen Protokollstapels. Er bestätigt nicht:

den Netzwerkadapter,
das Kabel,
die WLAN-Verbindung,
die VLAN-Zuordnung,
das Standardgateway,
den DNS-Dienst,
die Erreichbarkeit anderer Systeme.

15. Eigene Adresse prüfen

Danach kann die eigene zugewiesene Adresse geprüft werden.

Loopback-Adresse
→ eigene IP-Adresse
→ Nachbar im selben Netz
→ Standardgateway
→ entferntes Ziel per IP
→ DNS-Server
→ Ziel per DNS-Namen
→ konkreter Dienst und Port

Auch ein erfolgreicher Ping auf die eigene Adresse bestätigt nicht automatisch, dass Pakete den physischen Netzwerkadapter tatsächlich verlassen.

16. ARP und Neighbor Discovery untersuchen

Für IPv4 wird ARP verwendet, um IPv4-Adressen auf MAC-Adressen im lokalen Netz abzubilden. IPv6 verwendet Neighbor Discovery über ICMPv6.

Windows

arp -a
Get-NetNeighbor

Linux

ip neighbor

macOS

arp -a
ndp -a

Mögliche Zustände

Beobachtung	mögliche Einordnung
Gateway besitzt gültigen Nachbareintrag	lokale Auflösung war grundsätzlich möglich
Eintrag bleibt unvollständig	Gegenstelle antwortet nicht oder Layer-2-Pfad fehlerhaft
MAC-Adresse ändert sich unerwartet	Redundanz, Gatewaywechsel, Fehlkonfiguration oder Sicherheitsproblem
falsche MAC-Adresse	doppelter Adressgebrauch, ARP-Spoofing oder falsche Netzstruktur
viele unvollständige Einträge	Layer-2-, VLAN- oder Erreichbarkeitsproblem
Nachbareintrag vorhanden, Ping scheitert	ICMP kann blockiert sein oder Gegenstelle antwortet nicht

Ein vorhandener ARP- oder Neighbor-Eintrag beweist nicht die vollständige Erreichbarkeit eines Dienstes.

17. Standardgateway prüfen

Das Standardgateway leitet Daten zu Zielen außerhalb des lokalen Netzes weiter.

Zu prüfen sind:

ist ein Gateway eingetragen?
gehört das Gateway zum direkt erreichbaren Netz?
ist eine passende Standardroute vorhanden?
wird die richtige Schnittstelle verwendet?
stimmt die Metrik beziehungsweise Priorität?
ist das Gateway über ARP oder Neighbor Discovery erreichbar?
antwortet es auf zulässige Tests?
betrifft das Problem nur ein VLAN?
ist die Gateway-Schnittstelle aktiv?
bestehen redundante Gateways?
funktionieren Hin- und Rückweg?

Windows

Get-NetRoute -DestinationPrefix "0.0.0.0/0"
Get-NetRoute -AddressFamily IPv6
route print

Linux

ip route
ip -6 route

macOS

route -n get default
netstat -rn

Ein Gateway muss nicht auf ICMP-Echo-Anfragen antworten. Ein fehlgeschlagener Ping allein beweist deshalb keinen Gateway-Ausfall.

18. Lokales und entferntes Ziel unterscheiden

Ob ein Ziel lokal oder entfernt ist, ergibt sich aus:

eigener IP-Adresse,
Präfix beziehungsweise Subnetzmaske,
Zieladresse,
Routingtabelle.

Beispiel

Client: 192.168.10.24/24
Ziel A: 192.168.10.80
Ziel B: 192.168.20.80

Ziel A liegt im selben /24-Netz und wird normalerweise direkt über die lokale Verbindung erreicht.

Ziel B liegt in einem anderen Netz und benötigt eine passende Route, häufig über das Standardgateway.

Eine falsche Subnetzmaske kann dazu führen, dass der Client ein entferntes Ziel fälschlich als lokal behandelt oder ein lokales Ziel unnötig an ein Gateway sendet.

19. Routingtabelle auswerten

Die Routingentscheidung berücksichtigt unter anderem:

Zielpräfix,
Präfixlänge,
Gateway,
Schnittstelle,
Metrik,
Richtlinien,
VPN-Routen,
statische Routen,
mehrere aktive Netzwerkadapter.

Grundsätzlich gewinnt die spezifischste passende Route, also die Route mit dem längsten passenden Präfix.

Beispiel

0.0.0.0/0          über 192.168.10.1
10.0.0.0/8         über VPN
10.20.30.0/24      über 192.168.10.254

Für ein Ziel in 10.20.30.0/24 ist die /24-Route spezifischer als die /8-Route und die Standardroute.

Typische Routingfehler

keine Standardroute,
falsches Gateway,
falsche Präfixlänge,
unerwünschte VPN-Route,
gleiche Netze auf beiden Seiten eines VPN,
mehrere Standardrouten,
ungeeignete Metrik,
fehlende Rückroute,
asymmetrisches Routing,
veraltete statische Route,
falsche Schnittstellenbindung.

20. Erreichbarkeit schrittweise testen

Eine sinnvolle Testfolge lautet:

1. Loopback
2. eigene Adresse
3. Gegenstelle im selben Subnetz
4. Standardgateway
5. entferntes internes Ziel per IP
6. externer Dienst per IP
7. DNS-Server
8. Name eines internen Ziels
9. Name eines externen Ziels
10. konkreter TCP- oder UDP-Dienst

Die Ziele müssen bewusst ausgewählt werden. Eine beliebige öffentliche IP-Adresse oder Website ist nicht automatisch ein geeigneter Referenzpunkt.

Beispielhafte Dokumentation

Test	Ergebnis	Einordnung
Loopback erreichbar	erfolgreich	lokaler Protokollstapel grundsätzlich aktiv
eigene Adresse erreichbar	erfolgreich	lokale Adressbindung vorhanden
Gateway nicht erreichbar	fehlgeschlagen	Layer 2, VLAN, Gateway oder ICMP-Regel untersuchen
internes Ziel per IP erreichbar	erfolgreich	grundlegendes Routing vorhanden
interner Name nicht auflösbar	fehlgeschlagen	DNS gezielt untersuchen
Name wird aufgelöst, Port 443 nicht erreichbar	fehlgeschlagen	Dienst, Firewall, Route oder Zielsystem
Port 443 erreichbar, Browser scheitert	fehlgeschlagen	TLS, Proxy, Anwendung oder Authentifizierung

21. Ping richtig interpretieren

ping verwendet ICMP-Echo-Anfragen und kann Hinweise auf Erreichbarkeit und Laufzeit geben.

Ein erfolgreicher Ping kann bestätigen:

das Ziel beziehungsweise eine antwortende Komponente ist erreichbar,
ein Hin- und Rückweg für diese ICMP-Pakete besteht,
die verwendete Zieladresse war grundsätzlich erreichbar.

Ein erfolgreicher Ping bestätigt nicht:

dass DNS funktioniert,
dass ein bestimmter TCP- oder UDP-Port erreichbar ist,
dass die Anwendung funktioniert,
dass keine Paketverluste bei anderer Last auftreten,
dass der gesamte Pfad fehlerfrei ist,
dass die Antwort tatsächlich vom erwarteten Anwendungsdienst stammt.

Ein fehlgeschlagener Ping beweist nicht automatisch:

dass das Ziel ausgefallen ist,
dass keine Route besteht,
dass eine Firewall vollständig blockiert,
dass das Netzwerk unterbrochen ist.

ICMP kann gefiltert, begrenzt oder vom Ziel nicht beantwortet werden.

22. Pfad mit Traceroute untersuchen

Windows

tracert <ziel>
Test-NetConnection <ziel> -TraceRoute

Linux

traceroute <ziel>
tracepath <ziel>

macOS

traceroute <ziel>

Traceroute-Werkzeuge senden Pakete mit schrittweise erhöhtem Hop Limit beziehungsweise TTL-Wert. Zwischenrouter können daraufhin ICMP-Meldungen zurückgeben.

Grenzen

Router müssen nicht antworten.
Ein Sternchen beweist keinen Ausfall.
Hin- und Rückweg können unterschiedlich sein.
Firewalls können die verwendeten Probe-Pakete filtern.
Load Balancing kann unterschiedliche Pfade anzeigen.
Der letzte sichtbare Hop ist nicht automatisch die Fehlerstelle.
Hohe Antwortzeit eines Zwischenrouters beweist keine Weiterleitungsverzögerung.
Unterschiedliche Implementierungen verwenden unterschiedliche Protokolle.

Entscheidend ist nicht nur, welcher Hop antwortet, sondern ob nachfolgende Hops und der eigentliche Zieldienst erreichbar sind.

23. DNS getrennt von der Netzwerkverbindung prüfen

Wenn ein Ziel per IP-Adresse erreichbar ist, aber nicht über seinen Namen, liegt der Untersuchungsbereich häufig bei der Namensauflösung.

Zu prüfen sind:

konfigurierte DNS-Server,
Erreichbarkeit der DNS-Server,
Suchdomänen,
DNS-Suffix,
Record-Typ,
Name und Schreibweise,
DNS-Cache,
Split-DNS,
VPN-DNS,
Weiterleitungen,
Rekursion,
lokale Hosts-Datei,
DNSSEC, sofern relevant,
Ablaufzeit und Replikation,
Filter- oder Sicherheitsdienst.

Windows

Resolve-DnsName <name>
nslookup <name>
Get-DnsClientServerAddress
Get-DnsClientCache

Linux

resolvectl query <name>
resolvectl status
dig <name>

macOS

scutil --dns
dig <name>
nslookup <name>

Gezielte Abfrage eines bestimmten DNS-Servers

dig @<dns-server> <name>

Mögliche Ergebnisse

Ergebnis	mögliche Einordnung
Name wird korrekt aufgelöst	DNS-Auflösung grundsätzlich erfolgreich
`NXDOMAIN`	Name existiert aus Sicht des antwortenden DNS-Systems nicht
Zeitüberschreitung	DNS-Server, Netzwerkpfad oder Firewall
falsche Adresse	veralteter oder fehlerhafter Eintrag, Cache oder Split-DNS
interner Name nur ohne VPN auflösbar	DNS-Zuweisung oder VPN-Routing untersuchen
externer Name funktioniert, interner nicht	interne Zone, Suchdomäne oder Split-DNS
ein DNS-Server antwortet, der andere nicht	Serverzustand, Pfad oder Konfiguration
AAAA vorhanden, IPv6-Pfad fehlerhaft	IPv6 und Anwendungsauswahl untersuchen

nslookup, dig, Resolve-DnsName und die Namensauflösung einer Anwendung können unterschiedliche Auflösungswege oder Bibliotheken verwenden. Ergebnisse müssen im Kontext des Betriebssystems und der Anwendung bewertet werden.

24. Port und Dienst statt nur Host testen

Ein erreichbarer Host bestätigt nicht, dass der benötigte Dienst erreichbar ist.

Windows

Test-NetConnection <ziel> -Port 443

Linux und macOS

nc -vz <ziel> 443

HTTP beziehungsweise HTTPS

curl -I https://<ziel>
curl -v https://<ziel>

TLS-Verbindung

openssl s_client -connect <ziel>:443 -servername <dns-name>

Die Werkzeuge müssen auf dem jeweiligen System vorhanden sein. Vertrauliche Header, Tokens, Cookies und Zertifikatsdaten dürfen nicht ungeprüft in Tickets oder öffentliche Dokumentationen übernommen werden.

Mögliche Ergebnisse

Ergebnis	mögliche Einordnung
Verbindung hergestellt	TCP-Verbindung zum Port grundsätzlich möglich
Verbindung abgelehnt	Ziel erreichbar, aber Dienst nicht aktiv oder Port geschlossen
Zeitüberschreitung	Filterung, Routing, Zielzustand oder Rückweg
TLS-Fehler	Zertifikat, Protokollversion, SNI, Uhrzeit oder Inspektion
HTTP `401` oder `403`	Dienst erreichbar, Authentifizierung oder Berechtigung erforderlich
HTTP `404`	Webdienst erreichbar, angeforderte Ressource nicht gefunden
HTTP `500`	serverseitiger Anwendungsfehler
Umleitungsschleife	Proxy-, Anwendung-, TLS- oder URL-Konfiguration

25. Lokale Firewall prüfen

Eine lokale Firewall kann eingehenden oder ausgehenden Verkehr abhängig von folgenden Merkmalen filtern:

Quell- und Zieladresse,
Protokoll,
Port,
Netzwerkprofil,
Schnittstelle,
Anwendung,
Benutzer,
Dienst,
Richtung,
Sicherheitsrichtlinie.

Windows

Get-NetFirewallProfile
Get-NetFirewallRule -Enabled True

Linux

Je nach System können unter anderem verwendet werden:

nft list ruleset
iptables -S
ufw status verbose
firewall-cmd --state

macOS

/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
pfctl -s info

Zum Auslesen einzelner Firewallinformationen können erhöhte Rechte erforderlich sein.

Eine Firewall sollte nicht pauschal und dauerhaft deaktiviert werden. Besser ist ein zeitlich begrenzter, dokumentierter Test mit Freigabe oder die gezielte Auswertung von Protokollen und Regeln.

26. Netzwerk-Firewalls und ACLs berücksichtigen

Zwischen Client und Ziel können mehrere Filterinstanzen liegen:

Switch-ACL,
Router-ACL,
VLAN-Firewall,
Host-Firewall,
Standort-Firewall,
Cloud-Firewall,
Security Group,
Web Application Firewall,
Proxy,
VPN-Gateway,
Netzwerkzugangskontrolle.

Zu prüfen sind:

Quelle,
Ziel,
Protokoll,
Quellport,
Zielport,
Richtung,
Zeitstempel,
zustandsbehaftete Sitzung,
NAT-Übersetzung,
passende Regel,
Regelreihenfolge,
Protokolleintrag,
Rückweg.

Eine scheinbar passende Freigaberegel kann wirkungslos sein, wenn:

eine frühere Regel den Verkehr blockiert,
die falsche Zone verwendet wird,
die tatsächliche Quelladresse durch NAT verändert wurde,
die Anwendung einen zusätzlichen Port benötigt,
der Rückweg fehlt,
IPv6 anders behandelt wird als IPv4.

27. Proxy-Konfiguration untersuchen

Ein Proxy kann nur bestimmte Anwendungen oder Protokolle beeinflussen. Deshalb kann beispielsweise ping funktionieren, während der Browser keine Website öffnet.

Zu prüfen sind:

manueller Proxy,
automatisch erkannter Proxy,
PAC-Datei,
systemweiter Proxy,
anwendungseigener Proxy,
Authentifizierung,
Ausnahmeliste,
HTTPS-Inspektion,
Erreichbarkeit des Proxyservers,
Namensauflösung des Proxys,
Zertifikatsvertrauen,
Umgebungsvariablen.

Windows

netsh winhttp show proxy
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings"

Linux und macOS

env | grep -i proxy

macOS zusätzlich

scutil --proxy

Sensible Inhalte aus PAC-Dateien, Proxyadressen oder Zugangsdaten dürfen nicht ungeschützt dokumentiert werden.

28. VPN als eigene Fehlerdomäne behandeln

Ein VPN verändert möglicherweise:

Routingtabelle,
Standardroute,
DNS-Server,
Suchdomänen,
MTU,
Firewallregeln,
Proxykonfiguration,
Quelladresse,
erreichbare Netze.

Vergleichstests

ohne VPN
→ mit VPN
→ internes Ziel
→ externes Ziel
→ Ziel per IP
→ Ziel per Namen
→ Routingtabelle vorher und nachher
→ DNS-Konfiguration vorher und nachher

Typische VPN-Probleme

überlappende lokale und entfernte Netze,
fehlende Route,
falsches Split Tunneling,
gesamter Verkehr unerwartet durch den Tunnel,
interner DNS-Server nicht erreichbar,
MTU- oder Fragmentierungsproblem,
abgelaufenes Zertifikat,
fehlgeschlagene Authentifizierung,
lokale Firewallregel,
instabile Internetverbindung,
fehlerhafter VPN-Adapter.

29. MTU- und Fragmentierungsprobleme

Ein Pfad kann kleine Pakete übertragen, während größere Übertragungen scheitern oder hängen bleiben.

Mögliche Symptome sind:

Ping mit kleinen Paketen funktioniert,
Webseiten laden nur teilweise,
Dateiübertragungen bleiben stehen,
VPN-Verbindungen sind instabil,
TLS-Verbindungen brechen ab,
einzelne Anwendungen funktionieren, andere nicht.

Mögliche Ursachen:

ungeeignete MTU,
VPN-Overhead,
PPPoE-Overhead,
blockierte ICMP-Meldungen für Path MTU Discovery,
Tunnel oder Kapselung,
fehlerhafte Fragmentierungsbehandlung.

Windows – Beispieltest

ping <ziel> -f -l <nutzlastgröße>

Linux – Beispieltest

ping -M do -s <nutzlastgröße> <ziel>

Die geeignete Nutzlastgröße hängt vom Protokoll, Betriebssystem und Pfad ab. Ein einzelner Testwert darf nicht ohne Einordnung als allgemeingültige MTU übernommen werden.

30. Mehrere aktive Netzwerkadapter

Ein Client kann gleichzeitig verbunden sein über:

Ethernet,
WLAN,
Mobilfunk,
VPN,
virtuelle Maschine,
Container-Bridge,
USB-Netzwerkadapter,
Dockingstation,
Host-only-Netz,
virtuelle Switches.

Dadurch können entstehen:

mehrere Standardrouten,
unerwartete Metriken,
falscher DNS-Server,
asymmetrisches Routing,
Namensauflösung über die falsche Schnittstelle,
falsche Quelladresse,
nicht erreichbare lokale Netze,
VPN-Konflikte.

Kontrollierter Test

aktuelle Adapter und Routen dokumentieren.
tatsächlich verwendete Route zum Ziel bestimmen.
nicht benötigte Verbindung nur mit Freigabe vorübergehend trennen.
Test wiederholen.
ursprünglichen Zustand wiederherstellen.
Ursache dauerhaft in der Adapter-, Routing- oder VPN-Konfiguration beheben.

31. Vergleichstests richtig verwenden

Ein guter Vergleichstest verändert nur eine relevante Komponente.

Mögliche Vergleichskomponenten sind:

geprüftes Netzwerkkabel,
anderer Switchport,
andere Datendose,
anderer Netzwerkadapter,
andere Dockingstation,
anderer Client,
anderer Benutzer,
anderes VLAN,
anderes WLAN,
anderes Ziel,
Verbindung ohne VPN,
Verbindung ohne Proxy,
direkte Verbindung statt Dockingstation.

Beispiel

Ursprünglich:
Client A + Dock A + Kabel A + Dose A → Fehler

Vergleich 1:
Client A + Dock A + geprüftes Kabel B + Dose A → Fehler

Vergleich 2:
Client A + Dock B + geprüftes Kabel B + Dose A → funktioniert

Damit wird Dock A zum Hauptverdacht. Vor dem endgültigen Austausch sollte das Ergebnis reproduziert und die übrige Konfiguration verglichen werden.

Wenn bei einem Test gleichzeitig Kabel, Port, Dock und Benutzer gewechselt werden, lässt sich aus dem Erfolg keine einzelne Ursache ableiten.

32. Paketaufzeichnung gezielt einsetzen

Wenn Statusanzeigen und Standardtests keine ausreichende Erklärung liefern, kann eine Paketaufzeichnung zeigen, welche Kommunikation tatsächlich stattfindet.

Geeignete Werkzeuge sind beispielsweise:

Wireshark,
tcpdump,
tshark,
Windows-Paketaufzeichnungswerkzeuge,
Port Mirroring beziehungsweise SPAN,
Capture-Funktionen auf Firewalls, Routern oder Access Points.

Mögliche Fragestellungen

verlässt eine DHCP-Anfrage den Client?
antwortet ein DHCP-Server?
wird eine ARP-Anfrage beantwortet?
erfolgt eine DNS-Anfrage?
welcher DNS-Server antwortet?
wird ein TCP-SYN gesendet?
kommt ein SYN-ACK oder RST zurück?
findet eine TLS-Aushandlung statt?
treten Wiederholungen oder Zeitüberschreitungen auf?
wird ICMP zur Fehleranzeige zurückgesendet?
kommuniziert die Anwendung mit dem erwarteten Ziel?

Beispielhafte Filter

arp
dhcp
dns
icmp
icmpv6
tcp.port == 443
ip.addr == 192.0.2.10

Datenschutz und Sicherheit

Paketaufzeichnungen können enthalten:

IP-Adressen,
Hostnamen,
Benutzernamen,
Sitzungsdaten,
DNS-Anfragen,
unverschlüsselte Inhalte,
Authentifizierungsinformationen,
interne Systemstrukturen.

Aufzeichnungen dürfen nur mit Berechtigung erstellt, auf das erforderliche Zeitfenster begrenzt, sicher gespeichert und kontrolliert weitergegeben werden.

33. Typische TCP-Beobachtungen

Erfolgreicher Verbindungsaufbau

Client → Server: SYN
Server → Client: SYN, ACK
Client → Server: ACK

Port geschlossen

Client → Server: SYN
Server → Client: RST, ACK

Keine sichtbare Antwort

Client → Server: SYN
Client → Server: erneutes SYN
Client → Server: weiteres SYN

Mögliche Ursachen für eine ausbleibende Antwort sind:

Filterung,
Ziel nicht erreichbar,
Rückroute fehlt,
Server antwortet nicht,
Paket erreicht das Ziel nicht,
Antwort erreicht den Client nicht.

Eine Paketaufzeichnung an nur einer Stelle zeigt nicht automatisch, an welcher Stelle des gesamten Pfades das Paket verloren geht.

34. Ereignisprotokolle gemeinsam auswerten

Relevante Quellen können sein:

Client-Ereignisprotokolle,
NetworkManager- oder Systemprotokolle,
DHCP-Serverprotokolle,
DNS-Protokolle,
Switch- und Routerprotokolle,
Firewallprotokolle,
VPN-Protokolle,
Proxyprotokolle,
Access-Point- und Controllerprotokolle,
Authentifizierungsserver,
Zielserverprotokolle,
Monitoringdaten.

Alle Ereignisse sollten anhand eines möglichst genauen Zeitstempels zusammengeführt werden.

Zeitbezug

14:31:02 Client verliert Link
14:31:04 Switchport meldet Down
14:31:09 Switchport meldet Up
14:31:11 DHCP Discover
14:31:11 DHCP Offer
14:31:12 DHCP Request
14:31:12 DHCP ACK
14:31:14 DNS-Anfrage erfolgreich

Diese zeitliche Korrelation liefert stärkere Hinweise als voneinander getrennte Einzelmeldungen.

35. Praxisfall A: Client erhält eine Adresse aus 169.254.0.0/16

Symptom

Link ist aktiv.
Client besitzt 169.254.37.18/16.
Standardgateway fehlt.
interne und externe Ziele sind nicht erreichbar.

Prüfung

Adapterstatus dokumentieren.
Switchport und VLAN bestimmen.
anderes Gerät am selben Anschluss testen.
DHCP-Lease und DHCP-Clientprotokoll prüfen.
DHCP-Ablauf aufzeichnen.
Switch-Sicherheitsfunktionen prüfen.
DHCP-Relay kontrollieren.
DHCP-Bereich und freie Adressen prüfen.
Änderung einzeln durchführen.
neue Adressvergabe und Erreichbarkeit kontrollieren.

Mögliche Ursache

Der Switchport wurde nach einem Arbeitsplatzwechsel dem falschen VLAN zugeordnet. Der DHCP-Broadcast erreicht dadurch nicht den DHCP-Relay des vorgesehenen Clientnetzes.

Nachprüfung

richtige IPv4-Adresse erhalten,
Gateway vorhanden,
geeignete DNS-Server vorhanden,
internes Ziel erreichbar,
externer Dienst erreichbar,
erneute Adressvergabe erfolgreich,
Portkonfiguration dokumentiert.

36. Praxisfall B: IP-Ziele funktionieren, DNS-Namen nicht

Symptom

Standardgateway erreichbar.
internes Ziel über IP-Adresse erreichbar.
Name intranet.example.internal wird nicht aufgelöst.

Prüfung

konfigurierte DNS-Server dokumentieren.
DNS-Server per IP testen.
Namen über jeden DNS-Server einzeln abfragen.
DNS-Suffix und Suchdomäne prüfen.
VPN- und Split-DNS-Konfiguration vergleichen.
DNS-Zone und Resource Record prüfen.
Cache nur bei begründetem Verdacht kontrolliert leeren.
Auflösung und Anwendung erneut testen.

Mögliche Ursache

Nach dem Aufbau des VPN wird weiterhin ein öffentlicher DNS-Server verwendet. Dieser kennt die interne Zone nicht.

Nachprüfung

interner Name wird korrekt aufgelöst,
erwartete IP-Adresse wird geliefert,
Anwendung erreicht das Ziel,
öffentliche Namensauflösung funktioniert weiterhin,
Verhalten nach erneuter VPN-Verbindung bleibt korrekt.

37. Praxisfall C: Website antwortet nicht, Ping funktioniert

Symptom

Zielname wird korrekt aufgelöst.
Ping zum Ziel ist erfolgreich.
HTTPS-Verbindung scheitert.

Prüfung

aufgelöste Zieladresse dokumentieren.
TCP-Port 443 testen.
Pfad zum Ziel untersuchen.
lokale und zentrale Firewallprotokolle prüfen.
Proxykonfiguration prüfen.
TLS-Verbindung untersuchen.
Dienstzustand am Ziel prüfen.
Vergleich von internem und externem Zugriff durchführen.

Mögliche Ergebnisse

Ergebnis	Einordnung
TCP-Port 443 abgelehnt	Host erreichbar, Dienst nicht aktiv oder Port geschlossen
TCP-Verbindung läuft in Timeout	Firewall, Routing oder Rückweg
TLS-Zertifikat abgelaufen	Transport funktioniert, TLS-Vertrauen scheitert
Proxy meldet Zugriff verweigert	Proxyregel oder Berechtigung
HTTP `503`	Webdienst oder nachgelagerter Dienst nicht verfügbar
direkter Zugriff funktioniert, Proxyzugriff nicht	Proxykonfiguration oder Proxyzustand

38. Praxisfall D: Nur über die Dockingstation kein Netzwerk

Symptom

WLAN funktioniert.
integrierter Netzwerkanschluss beziehungsweise anderer Adapter funktioniert.
Ethernet über die Dockingstation fällt wiederholt aus.

Prüfung

Dockmodell und Anschlussart dokumentieren.
Linkstatus und Fehlerzähler prüfen.
Stromversorgung des Docks kontrollieren.
geprüftes Kabel verwenden.
anderen USB-C- beziehungsweise Thunderbolt-Anschluss testen.
Vergleichsdock verwenden.
Treiber- und Firmwarestand nach Herstellerangabe prüfen.
Energiesparverhalten untersuchen.
Ereignisprotokolle zum Zeitpunkt der Trennung auswerten.
Langzeittest nach der Maßnahme durchführen.

Mögliche Ursachen

instabile Stromversorgung,
Dock-Firmware,
Treiber,
USB-Verbindung,
defekter Netzwerkcontroller,
ungeeignetes Kabel,
Energiesparzustand,
thermisches Problem.

39. Praxisfall E: Interne Systeme funktionieren nur ohne VPN

Symptom

ohne VPN sind lokale Systeme erreichbar.
nach dem VPN-Aufbau sind bestimmte lokale Netze nicht erreichbar.
Internetzugriff funktioniert weiterhin.

Prüfung

Routingtabelle vor VPN-Verbindung sichern.
Routingtabelle nach VPN-Verbindung sichern.
DNS-Konfiguration vergleichen.
Zielnetz und lokales Clientnetz vergleichen.
überlappende Präfixe suchen.
verwendete Route zum Ziel bestimmen.
Split-Tunneling-Richtlinie prüfen.
VPN-Firewall- und Zugriffsrichtlinien prüfen.
kontrollierten Test mit geeignetem nicht überlappendem Netz durchführen.
dauerhafte Netz- oder VPN-Konfiguration korrigieren.

Mögliche Ursache

Das lokale Netz und ein entferntes Unternehmensnetz verwenden dasselbe IPv4-Präfix. Der Client kann nicht eindeutig bestimmen, ob das Ziel lokal oder über den VPN-Tunnel erreichbar ist.

40. Ungeeignete Sofortmaßnahmen

Folgende Maßnahmen können Spuren vernichten, neue Fehler erzeugen oder den ursprünglichen Zustand unklar machen:

Client sofort neu starten,
Switchport ohne Dokumentation umkonfigurieren,
Netzwerkadapter zurücksetzen,
alle gespeicherten WLAN-Profile löschen,
DHCP-Adresse mehrfach ungeprüft erneuern,
DNS-Cache ohne vorherige Prüfung leeren,
Firewall vollständig deaktivieren,
IPv6 pauschal abschalten,
VPN-Client neu installieren,
Netzwerkstack zurücksetzen,
Treiber ungeprüft ersetzen,
mehrere Kabel und Ports gleichzeitig wechseln,
statische Adresse als dauerhafte Umgehung eintragen,
Router oder Switch ohne Freigabe neu starten.

Solche Maßnahmen sind nicht grundsätzlich verboten. Sie müssen jedoch begründet, freigegeben, dokumentiert und anschließend vollständig überprüft werden.

41. Häufige Fehlinterpretationen

Aussage	fachliche Einordnung
„Der Link leuchtet, also funktioniert das Netzwerk.“	Ein Link bestätigt keine gültige IP-Konfiguration oder Ende-zu-Ende-Verbindung.
„Der Client hat eine IP-Adresse, also funktioniert DHCP.“	Die Adresse kann statisch, veraltet, link-local oder aus dem falschen Netz sein.
„Das Gateway antwortet nicht auf Ping, also ist es ausgefallen.“	ICMP-Echo kann gefiltert oder deaktiviert sein.
„Ping funktioniert, also liegt es an der Anwendung.“	Der benötigte Dienst, Port, DNS, Proxy oder TLS kann weiterhin fehlerhaft sein.
„Eine Website funktioniert, also funktioniert DNS.“	Die Adresse kann aus einem Cache stammen oder die Anwendung kann einen anderen Resolver verwenden.
„Eine Adresse aus 169.254.0.0/16 beweist einen defekten DHCP-Server.“	VLAN, Relay, Switchport, Client oder Sicherheitsfunktionen können ursächlich sein.
„Traceroute endet an Router X, also ist Router X defekt.“	Router können Antworten filtern, obwohl sie Daten weiterhin übertragen.
„Ohne Firewall funktioniert es, also muss sie dauerhaft deaktiviert bleiben.“	Die konkrete Regel oder Zuordnung muss ermittelt und gezielt korrigiert werden.
„Ein anderes Kabel funktioniert, also ist ausschließlich das ursprüngliche Kabel defekt.“	Auch Kontakte, Position oder mechanische Belastung wurden verändert.
„Nach dem Neustart funktioniert es, also ist der Fehler behoben.“	Ein Neustart kann Symptome beseitigen, ohne die Ursache zu erklären.
„IPv4 funktioniert, also ist die gesamte Netzwerkverbindung in Ordnung.“	Anwendungen können IPv6 bevorzugen oder beide Protokolle verwenden.
„Der Fehler liegt sicher beim Provider.“	Lokale Verbindung, DNS, Routing, Firewall und Zielsystem müssen getrennt geprüft werden.

42. Vollständige Prüfreihenfolge

genaue Anwendung, Zieladresse und Fehlermeldung bestimmen.
Zeitpunkt und letzte bekannte Funktion dokumentieren.
betroffene Benutzer, Clients, Netze und Standorte bestimmen.
Ethernet, WLAN, VPN und Proxy unterscheiden.
Ausgangskonfiguration sichern.
physische Verbindung beziehungsweise WLAN-Zustand prüfen.
Netzwerkadapter und Fehlerzähler untersuchen.
IPv4- und IPv6-Konfiguration bewerten.
DHCP-Zustand prüfen.
lokale Routingtabelle auswerten.
ARP beziehungsweise Neighbor Discovery kontrollieren.
Standardgateway und lokales Netz untersuchen.
entferntes Ziel gezielt per IP-Adresse testen.
DNS-Auflösung separat prüfen.
konkreten Zielport und Dienst testen.
Pfad bei Bedarf mit Traceroute untersuchen.
lokale Firewall, zentrale Firewall und ACLs berücksichtigen.
Proxy- und VPN-Konfiguration vergleichen.
System-, Netzwerk- und Serverprotokolle zeitlich korrelieren.
bei Bedarf eine autorisierte Paketaufzeichnung erstellen.
kontrollierten Vergleichstest mit nur einer Änderung durchführen.
Hypothese anhand der Ergebnisse bestätigen oder verwerfen.
freigegebene Korrektur umsetzen.
ursprünglichen Test wiederholen.
verwandte Funktionen und mögliche Nebenwirkungen prüfen.
Ursache, Maßnahme und Nachweis dokumentieren.

43. Dokumentationsbeispiel

Ticket: INC-20481
Zeitpunkt: 01.08.2026, 09:18 Uhr
Client: NB-204
Standort: Gebäude B, Raum 204
Anschluss: Dockingstation über Ethernet
Symptom: keine internen oder externen Ziele erreichbar

Ausgangszustand:
- physischer Link aktiv
- IPv4-Adresse 169.254.37.18/16
- kein Standardgateway
- kein verwendbarer DNS-Server
- WLAN deaktiviert
- anderer Client an derselben Dose ebenfalls ohne DHCP-Adresse

Hypothese:
Der Switchport befindet sich nach dem Arbeitsplatzwechsel im falschen VLAN.

Prüfung:
- Portbezeichnung mit Dokumentation verglichen
- tatsächliche VLAN-Zuordnung am Switch geprüft
- DHCP-Verkehr im zugewiesenen VLAN kontrolliert
- Port war dem Drucker-VLAN statt dem Client-VLAN zugeordnet

Ursache:
Fehlerhafte VLAN-Zuordnung des Switchports nach einer Portänderung.

Maßnahme:
Switchport nach Freigabe dem vorgesehenen Client-VLAN zugeordnet.

Nachprüfung:
- DHCP-Adresse aus dem vorgesehenen Clientnetz erhalten
- Standardgateway und DNS-Server korrekt
- internes Ziel per IP erreichbar
- interne DNS-Auflösung erfolgreich
- HTTPS-Anwendung erreichbar
- erneute DHCP-Adressvergabe erfolgreich
- Switchport und Dokumentation stimmen überein

Nebenwirkungen:
Keine Auffälligkeiten an benachbarten Ports oder im vorgesehenen VLAN festgestellt.

44. Checkliste Client ohne Netzwerkverbindung

45. Schnellreferenz

Prüfschritt	geeignete Information	typische Auffälligkeit
Umfang	betroffene Clients, Dienste und Standorte	mehrere Geräte oder nur eine Anwendung
Verbindung	Link, SSID, Authentifizierung	Link down oder falsches WLAN
Adapter	Zustand, Treiber, Fehlerzähler	deaktiviert, instabil oder hohe Fehler
IPv4	Adresse, Präfix, Gateway	`169.254.0.0/16`, falsches Netz oder kein Gateway
IPv6	Adresse, Route, Neighbor	nur Link-Local oder fehlende Standardroute
DHCP	Server, Lease, Optionen	kein Offer, falsche Optionen oder erschöpfter Bereich
Layer 2	ARP, Neighbor, VLAN	unvollständiger Eintrag oder falsches VLAN
Routing	Route, Gateway, Metrik	falsche oder fehlende Route
DNS	Server, Antwort, Record	Timeout, `NXDOMAIN` oder falsche Adresse
Transport	Zielport und TCP-Zustand	Timeout, RST oder TLS-Fehler
Firewall	Regel und Protokoll	Blockierung der tatsächlichen Quelle oder Zone
Proxy	PAC, Authentifizierung, Ausnahme	Browser betroffen, andere Tests erfolgreich
VPN	Routen, DNS und MTU	Netzüberlappung oder falsches Split Tunneling
Zielsystem	Dienst und Protokoll	Port geschlossen oder Anwendung fehlerhaft
Nachprüfung	ursprünglicher Test	Symptom beseitigt und keine Nebenwirkungen

Merksatz

„Kein Netzwerk“ ist keine Ursache, sondern eine ungenaue Symptombeschreibung. Eine belastbare Analyse bestimmt zuerst den Umfang und prüft anschließend kontrolliert Verbindung, Adapter, IP-Konfiguration, DHCP, lokales Netz, Gateway, Routing, DNS, Zielport und Anwendung. Jeder erfolgreiche Test bestätigt nur den tatsächlich geprüften Teil des Kommunikationswegs.

Quellen und weiterführende Dokumentation

6.2 Mehrere Clients oder ganzer Standort ohne Netzwerk

Wenn mehrere Clients, eine Abteilung, ein Stockwerk, ein Gebäude oder ein kompletter Standort gleichzeitig keine Netzwerkverbindung besitzen, ist ein unabhängiger Fehler an jedem einzelnen Endgerät unwahrscheinlich. Der gemeinsame Ausfallbereich rückt in den Mittelpunkt.

Mögliche gemeinsame Komponenten sind:

Access Switch,
Switch-Uplink,
VLAN,
WLAN-SSID,
Access Point oder WLAN-Controller,
Standardgateway,
DHCP-Dienst,
DNS-Dienst,
Firewall,
Router,
WAN-Verbindung,
VPN-Tunnel,
Internetanschluss,
Stromversorgung,
zentrale Authentifizierung,
Netzwerkzugangskontrolle,
Providerverbindung,
gemeinsame Konfigurationsänderung.

Das Ziel der Fehleranalyse besteht darin, den kleinsten gemeinsamen Ausfallbereich zu bestimmen und anschließend die darin enthaltenen Komponenten kontrolliert zu prüfen.

Je mehr Systeme gleichzeitig betroffen sind, desto wichtiger ist die Frage, welche technische Komponente oder Abhängigkeit sie gemeinsam verwenden.

1. Mehrere betroffene Clients verändern die Fehlerhypothese

Bei einem einzelnen betroffenen Client sind lokale Ursachen besonders wahrscheinlich:

Netzwerkkabel,
Netzwerkadapter,
Dockingstation,
lokale IP-Konfiguration,
lokaler Treiber,
lokale Firewall,
Betriebssystem,
Benutzerprofil.

Bei mehreren gleichzeitig betroffenen Clients werden gemeinsame Ursachen wahrscheinlicher:

gemeinsamer Switch,
gemeinsamer Uplink,
gemeinsames VLAN,
gemeinsames Gateway,
gemeinsamer DHCP-Server,
gemeinsamer DNS-Server,
gemeinsamer WLAN-Bereich,
gemeinsame Firewall,
gemeinsame Standortanbindung,
gemeinsame Änderung.

Lokale Clienttests bleiben wichtig. Sie dienen nun jedoch vor allem dazu, den gemeinsamen Fehlerumfang zu bestätigen und Unterschiede zwischen funktionierenden und nicht funktionierenden Bereichen zu erkennen.

2. Störungsumfang exakt bestimmen

Die Aussage „Der Standort hat kein Netzwerk“ ist zunächst nur eine ungenaue Symptombeschreibung.

Zu klären sind:

Wie viele Benutzer melden den Fehler?
Wie viele Clients wurden tatsächlich geprüft?
Sind alle Geräte oder nur einzelne Gerätetypen betroffen?
Betrifft der Fehler Ethernet, WLAN oder beide?
Sind Drucker, Telefone, Kameras und andere Netzwerkgeräte betroffen?
Betrifft der Fehler nur einen Raum?
Betrifft er eine Etage?
Betrifft er ein Gebäude?
Betrifft er ein VLAN?
Betrifft er eine bestimmte SSID?
Betrifft er einen kompletten Standort?
Sind weitere Standorte betroffen?
Funktionieren interne Ziele?
Funktioniert das Internet?
Funktioniert die Namensauflösung?
Sind nur einzelne Anwendungen ausgefallen?
Können bestehende Verbindungen weiterarbeiten?
Scheitern nur neue Verbindungen?
Ist der Ausfall vollständig oder treten Paketverluste und Unterbrechungen auf?

Eine belastbare Aussage lautet beispielsweise:

Seit etwa 09:17 Uhr können alle bisher geprüften kabelgebundenen
Clients der dritten Etage weder das Standardgateway noch interne
Dienste erreichen. WLAN-Clients derselben Etage funktionieren.
Andere Etagen sind nicht betroffen.

Diese Beschreibung grenzt den Fehler erheblich stärker ein als „Netzwerk ausgefallen“.

3. Betroffenheitsmatrix erstellen

Eine einfache Matrix hilft, Gemeinsamkeiten zu erkennen.

Bereich	Ethernet	WLAN	interne Dienste	Internet	DNS
Etage 1	funktioniert	funktioniert	funktioniert	funktioniert	funktioniert
Etage 2	funktioniert	funktioniert	funktioniert	funktioniert	funktioniert
Etage 3	ausgefallen	funktioniert	ausgefallen	ausgefallen	nicht sinnvoll prüfbar
Etage 4	funktioniert	funktioniert	funktioniert	funktioniert	funktioniert

Aus diesem Beispiel ergibt sich:

kein standortweiter Ausfall,
kein allgemeiner Internet- oder DNS-Ausfall,
kein vollständiger Ausfall des zentralen Gateways,
wahrscheinlicher Fehler im kabelgebundenen Zugangsnetz der dritten Etage,
möglicher Access-Switch-, Uplink-, VLAN- oder Stromversorgungsfehler.

Eine solche Matrix sollte nicht nur auf Benutzerangaben beruhen. Repräsentative Tests müssen die Angaben bestätigen.

4. Zeitpunkt und zeitlichen Verlauf ermitteln

Zu dokumentieren sind:

erster bekannter Fehlerzeitpunkt,
letzte bekannte fehlerfreie Nutzung,
gleichzeitiger oder schrittweiser Ausfall,
dauerhafter oder sporadischer Fehler,
Zeitpunkt automatischer Monitoringmeldungen,
Zeitpunkt letzter Änderungen,
Zeitpunkt von Strom-, Klima- oder Providerereignissen,
Wiederkehr in bestimmten Zeitabständen,
Abhängigkeit von Last oder Benutzeranzahl.

Mögliche zeitliche Muster

Beobachtung	mögliche Einordnung
alle Clients fallen gleichzeitig aus	gemeinsame zentrale Komponente oder Verbindung
Clients fallen nacheinander aus	DHCP-Leases, instabiler Switch, Schleife, Überlastung oder Stromproblem
nur morgens bei Arbeitsbeginn	DHCP-Bereich, Authentifizierung, WLAN-Kapazität oder Lastproblem
kurze Ausfälle in regelmäßigen Abständen	Redundanzumschaltung, instabiler Link, Routingprozess oder geplante Aufgabe
Fehler direkt nach Änderung	Änderung als starke Hypothese untersuchen
Fehler bei hoher Netzlast	Überlastung, Broadcast-Sturm, fehlerhafter Link oder Kapazitätsgrenze
Fehler nach Stromunterbrechung	Gerät, Netzteil, USV, Startreihenfolge oder nicht gespeicherte Konfiguration

Zeitliche Nähe beweist noch keine Ursache. Sie legt jedoch eine gezielte Prüfreihenfolge nahe.

5. Letzte Änderungen prüfen

Vor einer Änderung am Netzwerk ist zu prüfen, ob kurz vor Beginn der Störung etwas verändert wurde.

Mögliche Änderungen sind:

Switch-Konfiguration,
VLAN-Zuordnung,
Trunk-Konfiguration,
Spanning-Tree-Konfiguration,
Link Aggregation,
Routing,
Firewallregeln,
NAT,
DHCP-Bereich,
DHCP-Relay,
DNS-Konfiguration,
WLAN-Controller,
Access-Point-Firmware,
Netzwerkzugangskontrolle,
Zertifikate,
Provideranschluss,
Verkabelung,
Patchfeld,
Stromversorgung,
Server- oder Netzwerkupdate,
Wartungsarbeiten,
Umzug von Geräten,
Anschluss eines neuen Switches,
Anschluss eines nicht autorisierten Geräts.

Zu jeder Änderung gehören:

genauer Zeitpunkt,
verantwortliche Person oder System,
betroffene Komponenten,
erwartete Wirkung,
dokumentierter Ausgangszustand,
mögliche Rückfallmaßnahme,
tatsächliche Protokolleinträge.

Ein zeitlicher Zusammenhang macht eine Änderung verdächtig, ersetzt aber nicht den technischen Nachweis.

6. Priorität und Auswirkung bewerten

Ein Ausfall mehrerer Clients kann ein Major Incident sein, muss es aber nicht automatisch sein.

Zu bewerten sind:

Anzahl betroffener Benutzer,
betroffene Geschäftsprozesse,
betroffene Standorte,
verfügbare Ausweichmöglichkeiten,
Sicherheitsauswirkungen,
Produktionsstillstand,
Ausfall kritischer Dienste,
vertragliche Verpflichtungen,
erwartete Dauer,
Gefahr einer Ausweitung,
Abhängigkeit externer Kunden oder Partner.

Beispielhafte Einordnung

Situation	mögliche Auswirkung
ein Besprechungsraum ohne Netzwerk	lokal begrenzt
gesamtes Stockwerk ohne Netzwerk	erhebliche Benutzerbeeinträchtigung
Produktionsnetz ausgefallen	geschäftskritisch
Standort ohne WAN, lokale Systeme funktionieren	standortübergreifende Dienste betroffen
DNS unternehmensweit ausgefallen	sehr großer scheinbarer Netzwerkausfall
redundanter Uplink ausgefallen, Verkehr läuft weiter	noch kein Benutzerausfall, aber Redundanz verloren

Die Priorität richtet sich nach Auswirkung und Dringlichkeit, nicht allein nach der Anzahl eingehender Tickets.

7. Kommunikation während einer größeren Störung

Bei einer größeren Störung müssen technische Analyse und Kommunikation parallel organisiert werden.

Sinnvolle Aufgabenverteilung:

technische Koordination,
Prüfung des Zugangsnetzes,
Prüfung zentraler Dienste,
Prüfung von Firewall, WAN und Provider,
Dokumentation der Ereignisse,
Kommunikation mit Benutzern und Verantwortlichen,
Koordination externer Dienstleister.

Eine Statusmeldung sollte enthalten:

Bekannter Umfang:
Kabelgebundene Clients in Gebäude B sind betroffen.
WLAN und andere Gebäude funktionieren.

Beginn:
Etwa 09:17 Uhr.

Aktueller Stand:
Der gemeinsame Uplink des Access-Bereichs wird geprüft.

Nächste Aktualisierung:
10:00 Uhr oder bei einer wesentlichen Änderung.

Nicht bestätigt werden sollten Aussagen wie:

„Der Provider ist schuld.“
„Die Firewall ist abgestürzt.“
„Das Problem ist gleich behoben.“
„Es gehen keine Daten verloren.“

Solche Aussagen dürfen erst erfolgen, wenn belastbare Nachweise vorliegen.

8. Repräsentative Testpunkte auswählen

Nicht jeder einzelne Client muss vollständig untersucht werden. Es werden gezielt Testpunkte ausgewählt.

Geeignete Auswahl:

ein betroffener Client aus jedem gemeldeten Bereich,
ein funktionierender Client aus einem benachbarten Bereich,
ein kabelgebundener und ein drahtloser Client,
ein Client im gleichen VLAN,
ein Client in einem anderen VLAN,
ein infrastrukturelles Gerät im betroffenen Bereich,
ein Test direkt am Access Switch,
ein Test hinter dem vermuteten Uplink,
ein Test am zentralen Standort.

Beispiel

Client A: Etage 3, Switch 3A, VLAN 120 → betroffen
Client B: Etage 3, Switch 3B, VLAN 120 → betroffen
Client C: Etage 3, WLAN, VLAN 220 → funktioniert
Client D: Etage 2, VLAN 120 → funktioniert

Damit liegt der Verdacht nicht automatisch beim gesamten VLAN 120. Wahrscheinlicher ist zunächst eine Komponente, die nur die kabelgebundene Versorgung der dritten Etage betrifft.

9. Gemeinsame Abhängigkeiten abbilden

Für die betroffenen Clients sollte der Kommunikationsweg vereinfacht dargestellt werden.

Clients
→ Access Switch
→ Uplink
→ Distribution Switch
→ VLAN-Gateway
→ Firewall oder Router
→ WAN beziehungsweise Internet
→ Zielsystem

Für WLAN kann der Weg abweichen:

WLAN-Client
→ Access Point
→ Access Switch
→ WLAN-Controller oder lokales Switching
→ VLAN-Gateway
→ Firewall oder Router
→ Zielsystem

Für jeden Abschnitt wird geprüft:

Nutzen alle betroffenen Clients diese Komponente?
Nutzen funktionierende Clients dieselbe Komponente?
Ist die Komponente erreichbar?
Sind Fehler oder Zustandsänderungen protokolliert?
Besteht eine redundante Verbindung?
Arbeitet die Redundanz tatsächlich?
Wurde die Konfiguration verändert?

10. Ausfallbereich durch funktionierende Grenzen bestimmen

Nicht nur fehlgeschlagene Tests sind wichtig. Funktionierende Bereiche bilden Grenzen des Fehlers.

Beispiel

Clients an Switch A → ausgefallen
Clients an Switch B → funktionieren
beide verwenden dasselbe Gateway
beide verwenden dieselben DNS-Server
beide verwenden dieselbe Firewall

Dadurch werden Gateway, DNS und Firewall als alleinige gemeinsame Ursache weniger wahrscheinlich. Der Untersuchungsbereich verschiebt sich zu:

Switch A,
dessen Uplink,
dessen VLAN-Weiterleitung,
dessen Stromversorgung,
dessen lokale Verkabelung.

Ein funktionierender Bereich schließt eine Komponente allerdings nur dann sinnvoll aus, wenn tatsächlich dieselbe Instanz, derselbe Pfad und dieselbe Konfiguration verwendet werden.

11. Stromversorgung und Umgebungsbedingungen prüfen

Ein Netzwerkausfall kann durch einen Strom- oder Umgebungsfehler verursacht werden.

Zu prüfen sind:

besitzt der Netzwerkschrank Strom?
ist die USV aktiv?
bestehen USV-Alarme?
sind Sicherungen ausgelöst?
funktionieren Netzteile und redundante Netzteile?
sind Power Distribution Units aktiv?
ist der Switch vollständig gestartet?
bestehen Temperaturalarme?
funktioniert die Kühlung?
wurden Geräte versehentlich ausgeschaltet?
sind PoE-Verbraucher ausgefallen?
wurde das Strombudget überschritten?
gibt es auffälligen Geruch, Hitze oder Geräusche?

Bei ausgefallener PoE-Versorgung können gleichzeitig betroffen sein:

Access Points,
IP-Telefone,
Kameras,
Zutrittskomponenten,
Sensoren.

Ein aktiver Switch kann weiterhin ein PoE-Problem besitzen. Deshalb müssen Datenverkehr und Stromversorgung getrennt bewertet werden.

12. Physische Infrastruktur prüfen

Bei mehreren betroffenen Clients sind besonders gemeinsame physische Komponenten zu untersuchen:

Access Switch,
Switch-Uplink,
Glasfaserstrecke,
Kupfer-Uplink,
Patchkabel,
Patchfeld,
Transceiver,
Medienkonverter,
Stack-Kabel,
Modul oder Line Card,
Gebäudeverkabelung.

Mögliche Hinweise:

Uplink ohne Link,
Link wechselt zwischen Up und Down,
hohe Anzahl CRC-Fehler,
Eingabefehler,
Verwerfungen,
fehlerhafte Transceiverwerte,
nur eine Richtung funktioniert,
ungewöhnlich niedrige ausgehandelte Geschwindigkeit,
Port befindet sich im Fehlerzustand,
Switch-Mitglied fehlt aus einem Stack,
Line Card ist ausgefallen.

Typische Zähler

Zähler oder Zustand	mögliche Bedeutung
CRC-Fehler	physische Übertragungsfehler, Kabel, Stecker oder Transceiver
Input Errors	unterschiedliche Empfangsfehler
Output Drops	Warteschlange oder Überlastung
Link Flaps	instabile Verbindung oder Komponente
administratively down	Schnittstelle wurde deaktiviert
err-disabled	Schutzfunktion oder erkannter Fehler
keine optische Empfangsleistung	Glasfaser, Transceiver oder Gegenstelle
viele Interface-Resets	instabiler Port, Treiber oder Hardware

Zähler müssen zusammen mit Laufzeit, Verkehrsmenge und Änderungsrate bewertet werden. Ein historischer Fehlerzähler beweist keinen aktuellen Defekt.

13. Access Switch prüfen

Zu einem betroffenen Access Switch sollten mindestens folgende Informationen erhoben werden:

Erreichbarkeit des Managements,
Betriebszeit,
letzter Neustart,
CPU-Auslastung,
Speicherauslastung,
Temperatur,
Netzteilstatus,
Stack-Status,
Uplink-Status,
Fehlerzähler,
VLAN-Zustand,
Spanning-Tree-Zustand,
MAC-Adresstabelle,
Port-Sicherheitszustände,
PoE-Status,
Systemprotokolle,
aktuelle Konfiguration,
letzte Konfigurationsänderung.

Mögliche Befehle hängen von Hersteller und Betriebssystem ab. Bei Cisco-IOS-ähnlichen Systemen können beispielsweise relevant sein:

show interfaces status
show interfaces counters errors
show interfaces <schnittstelle>
show logging
show vlan brief
show interfaces trunk
show spanning-tree
show etherchannel summary
show mac address-table
show power inline
show environment
show switch
show version

Diese Befehle sind Beispiele. Syntax und Verfügbarkeit müssen anhand der Dokumentation des eingesetzten Geräts geprüft werden.

14. Uplink und Trunk untersuchen

Ein Access Switch kann erreichbar sein, während Nutzdaten wegen eines fehlerhaften Uplinks oder Trunks nicht korrekt übertragen werden.

Zu prüfen sind:

physischer Linkstatus,
Geschwindigkeit und Duplex,
erlaubte VLANs,
native beziehungsweise untagged VLAN-Zuordnung,
Trunk-Modus,
VLAN-Pruning,
Gegenstellenkonfiguration,
Fehlerzähler,
Spanning-Tree-Zustand,
Link Aggregation,
Port-Sicherheitsmechanismen,
MTU,
einseitige Konfigurationsänderung.

Typische Fehler

benötigtes VLAN nicht auf dem Trunk erlaubt,
VLAN nur auf einer Seite konfiguriert,
falsches untagged VLAN,
Uplink als Access-Port konfiguriert,
Trunk nach Änderung nicht vollständig übernommen,
Port durch Spanning Tree blockiert,
Mitglied einer Link Aggregation fehlerhaft,
Transceiver oder Faser gestört,
Uplink physisch aktiv, aber Datenverkehr verworfen.

Ein aktiver Link bestätigt weder eine korrekte Trunk-Konfiguration noch die Weiterleitung aller benötigten VLANs.

15. VLAN-Zuordnung prüfen

Wenn nur bestimmte Benutzergruppen oder Netzsegmente betroffen sind, ist die VLAN-Konfiguration ein zentraler Prüfpunkt.

Zu prüfen sind:

existiert das VLAN auf allen notwendigen Switches?
sind Access-Ports dem richtigen VLAN zugeordnet?
wird das VLAN über alle erforderlichen Trunks transportiert?
besitzt das VLAN ein aktives Gateway?
ist DHCP beziehungsweise DHCP-Relay für dieses VLAN erreichbar?
blockieren Sicherheitsfunktionen den Verkehr?
stimmen Voice- und Data-VLAN?
bestehen dynamische VLAN-Zuweisungen?
verwendet die Netzwerkzugangskontrolle das erwartete VLAN?
wurde das VLAN umbenannt, gelöscht oder neu nummeriert?

Mögliche Beobachtungen

Beobachtung	mögliche Einordnung
nur ein VLAN betroffen	VLAN-Pfad, Gateway, DHCP oder Richtlinie
mehrere VLANs desselben Switches betroffen	Switch oder gemeinsamer Uplink
VLAN funktioniert auf anderen Switches	lokaler Trunk oder Access Switch
Clients erhalten Adresse aus falschem Netz	falsche VLAN-Zuordnung oder unerwarteter DHCP-Server
statisch konfigurierte Clients funktionieren, DHCP-Clients nicht	DHCP-Pfad oder DHCP-Dienst
Gateway im VLAN nicht per ARP erreichbar	Layer-2-Pfad, Gateway oder VLAN-Zuordnung

16. Spanning Tree und Netzwerkschleifen

Spanning Tree verhindert Layer-2-Schleifen in redundanten Ethernet-Netzen. Fehlerhafte Verkabelung oder Konfiguration kann dennoch zu einer Schleife oder instabilen Topologie führen.

Mögliche Symptome:

sehr hohe Broadcast-Last,
stark schwankende MAC-Adresstabellen,
MAC-Adressen erscheinen abwechselnd an verschiedenen Ports,
hohe CPU-Auslastung auf Switches,
Paketverluste,
langsame oder vollständig ausfallende Verbindungen,
häufige Topology Changes,
Managementzugriff nur sporadisch möglich,
mehrere Bereiche gleichzeitig betroffen,
Ausfall nach Anschluss eines kleinen Switches oder neuen Kabels.

Zu prüfen sind:

Root Bridge,
blockierende und weiterleitende Ports,
letzte Topology Changes,
Anzahl der Topology Changes,
unerwartete Root-Bridge-Änderung,
BPDU Guard,
Root Guard,
Loop Guard,
PortFast beziehungsweise Edge-Port-Konfiguration,
neu angeschlossene Switches,
doppelte Verkabelung.

Bei Verdacht auf eine Schleife dürfen nicht wahllos Verbindungen getrennt werden. Zuerst müssen Topologie, betroffene Ports und aktuelle Zustände soweit möglich dokumentiert werden.

17. Link Aggregation und LACP prüfen

Mehrere physische Verbindungen können zu einer logischen Verbindung zusammengefasst sein.

Zu prüfen sind:

sind alle erwarteten Mitglieder aktiv?
befinden sich beide Seiten in derselben Aggregation?
stimmen LACP-Modus und Parameter?
verwenden alle Mitglieder identische VLAN- und Trunk-Einstellungen?
bestehen einzelne suspendierte oder nicht gebündelte Ports?
ist die Hash-Verteilung auffällig?
funktionieren bestimmte Verbindungen nur über ein einzelnes fehlerhaftes Mitglied?
ist bei einem Gerätetausch eine alte Konfiguration verblieben?

Mögliche Symptome:

nur einige Verbindungen funktionieren,
bestimmte Quell-Ziel-Kombinationen scheitern,
Paketverluste treten abhängig vom Verkehrsfluss auf,
Durchsatz ist deutlich reduziert,
Redundanz ist verloren,
MAC-Adressen wechseln unerwartet,
ein Mitglied leitet außerhalb des Bündels weiter.

18. Gateway und First-Hop-Redundanz prüfen

Das Gateway eines VLANs kann physisch oder logisch ausgefallen sein.

Zu prüfen sind:

ist die Gateway-Schnittstelle aktiv?
ist die virtuelle Gateway-Adresse vorhanden?
antwortet das Gateway auf ARP beziehungsweise Neighbor Discovery?
besitzen Clients den richtigen Gateway-Eintrag?
ist die Gateway-MAC-Adresse plausibel?
ist die Routingfunktion aktiv?
besteht die verbundene Route?
funktionieren andere VLANs auf demselben Gerät?
bestehen CPU-, Speicher- oder Hardwareprobleme?
funktioniert ein redundantes Gatewaypaar?
stimmen aktive und passive Rollen?
trat ein Rollenwechsel auf?
besteht ein Split-Brain- oder Dual-Active-Zustand?
wird der Rückweg korrekt geroutet?

Bei Redundanzprotokollen wie HSRP oder VRRP muss nicht nur der Gerätezustand, sondern auch die tatsächliche Erreichbarkeit der virtuellen Adresse geprüft werden.

Eine als aktiv gemeldete Redundanzrolle beweist nicht automatisch, dass:

die Datenebene funktioniert,
alle VLANs übertragen werden,
die Upstream-Verbindung erreichbar ist,
der Rückweg vorhanden ist.

19. DHCP bei mehreren betroffenen Clients prüfen

Wenn viele Clients keine verwendbare IP-Konfiguration erhalten, kann eine gemeinsame DHCP-Störung vorliegen.

Mögliche Symptome:

Adressen aus 169.254.0.0/16,
kein Standardgateway,
fehlende DNS-Server,
alte Leases funktionieren noch,
neue Clients erhalten keine Adresse,
Clients erhalten Adressen aus dem falschen Netz,
Fehler beginnt bei hoher Benutzeranzahl,
nur ein bestimmtes VLAN ist betroffen.

Zu prüfen sind:

läuft der DHCP-Dienst?
ist der DHCP-Server erreichbar?
ist der richtige Bereich aktiv?
sind freie Adressen vorhanden?
stimmen Subnetzmaske, Gateway und DNS-Optionen?
funktioniert DHCP-Relay?
ist die Relay-Adresse korrekt?
wird DHCP durch ACLs oder Firewalls blockiert?
besteht DHCP Snooping?
sind vertrauenswürdige Ports korrekt festgelegt?
antwortet ein unerwünschter DHCP-Server?
funktionieren redundante DHCP-Server?
stimmt der Failover-Zustand?
erreichen Discover-Pakete den Server?
erreicht das Offer den Client?

DHCP-Ablauf

Client → DHCP Discover
Server → DHCP Offer
Client → DHCP Request
Server → DHCP Acknowledgement

Mögliche Beobachtungen

Beobachtung	mögliche Einordnung
kein Discover sichtbar	Client, Access-Port, VLAN oder Aufzeichnungsstelle
Discover im VLAN, aber nicht am Server	Relay, Routing, ACL oder VLAN-Pfad
Discover erreicht Server, kein Offer	Dienst, Bereich, Richtlinie oder Adressmangel
Offer verlässt Server, erreicht Client nicht	Rückweg, Relay, Snooping oder Layer 2
falscher Server antwortet	Rogue DHCP oder falscher gemeinsamer Layer-2-Bereich
alte Clients funktionieren, neue nicht	erschöpfter Bereich oder gestörter Vergabeprozess

20. DNS-Ausfall nicht mit vollständigem Netzwerkausfall verwechseln

Ein zentraler DNS-Ausfall kann bei vielen Benutzern den Eindruck erzeugen, das Netzwerk sei vollständig ausgefallen.

Typische Beobachtungen:

Ziele sind per IP-Adresse erreichbar,
Namen können nicht aufgelöst werden,
bereits bestehende Sitzungen funktionieren teilweise weiter,
Anwendungen mit zwischengespeicherten Adressen funktionieren,
Anmeldungen und Active-Directory-Funktionen scheitern,
interne und externe Namen verhalten sich unterschiedlich.

Zu prüfen sind:

Erreichbarkeit der DNS-Server per IP,
DNS-Dienstzustand,
Abfrage eines bekannten internen Namens,
Abfrage eines bekannten externen Namens,
Antwort jedes konfigurierten DNS-Servers,
Rekursion,
Weiterleitungen,
Zonen,
Replikation,
DNSSEC, sofern eingesetzt,
Firewallregeln für UDP und TCP Port 53,
ausgegebene DHCP-DNS-Optionen,
Split-DNS,
Standort- oder VPN-spezifische DNS-Server.

Windows

Resolve-DnsName <name>
Resolve-DnsName <name> -Server <dns-server>
Get-DnsClientServerAddress

Linux und macOS

dig <name>
dig @<dns-server> <name>

Ein DNS-Fehler betrifft die Namensauflösung. Er beweist keinen Ausfall der zugrunde liegenden IP-Verbindung.

21. Netzwerkzugangskontrolle und Authentifizierung

In Unternehmensnetzen kann der Netzwerkzugang von einer Authentifizierung oder Autorisierung abhängen.

Mögliche Komponenten:

IEEE 802.1X,
RADIUS,
Network Access Control,
Zertifikatsdienste,
Geräteidentifikation,
dynamische VLAN-Zuweisung,
Quarantäne-VLAN,
MAC Authentication Bypass,
Port-Security.

Mögliche Symptome:

viele Ports wechseln gleichzeitig in einen nicht autorisierten Zustand,
Clients erhalten ein Quarantäne-VLAN,
kabelgebundene und drahtlose Anmeldungen scheitern,
neue Verbindungen scheitern, bestehende funktionieren,
Fehler beginnt nach Ablauf eines Zertifikats,
RADIUS-Server ist nicht erreichbar,
Uhrzeitabweichungen verhindern die Zertifikatsprüfung,
eine Richtlinienänderung betrifft ganze Gerätegruppen.

Zu prüfen sind:

Status des Authentifizierungsdienstes,
Erreichbarkeit der RADIUS-Server,
Zertifikatsgültigkeit,
Systemzeit,
Richtlinienänderungen,
Switch- und Controllerprotokolle,
Ablehnungsgrund,
zugewiesenes VLAN,
Failover auf einen zweiten Authentifizierungsserver.

22. WLAN als eigene Fehlerdomäne untersuchen

Wenn mehrere WLAN-Clients betroffen sind, müssen Funk-, Zugangs- und zentrale WLAN-Komponenten getrennt geprüft werden.

Zu prüfen sind:

ist die SSID sichtbar?
können Clients sich verbinden?
funktioniert die Authentifizierung?
erhalten sie eine IP-Adresse?
betrifft es einen Access Point oder mehrere?
betrifft es ein Frequenzband?
betrifft es eine SSID?
betrifft es einen Standort?
sind Access Points beim Controller registriert?
besitzen Access Points Strom und Uplink?
ist das vorgesehene VLAN verfügbar?
funktioniert DHCP?
besteht ausreichende Funkabdeckung?
gibt es starke Störungen?
ist die Clientanzahl ungewöhnlich hoch?
funktionieren Roaming und Controller-Kommunikation?
wurde Firmware oder Konfiguration geändert?

Abgrenzung

Beobachtung	mögliche Einordnung
SSID nicht sichtbar	Access Point, Funkmodul, Controller oder SSID-Konfiguration
SSID sichtbar, Anmeldung scheitert	Authentifizierung, Zertifikat, RADIUS oder Kennwort
Anmeldung erfolgreich, keine IP-Adresse	VLAN, DHCP oder Tunnel
IP-Adresse vorhanden, Gateway nicht erreichbar	VLAN-Pfad, Gateway oder Client-Isolation
nur ein Access Point betroffen	AP, Uplink, PoE oder lokale Funkumgebung
alle APs eines Standorts betroffen	Controllerpfad, Standort-Uplink, DHCP oder gemeinsame Konfiguration
nur ein Frequenzband betroffen	Funkkonfiguration, Radarereignis oder Hardware

23. Firewall, ACL und zentrale Sicherheitskomponenten

Ein gemeinsamer Filterfehler kann viele Clients oder ganze Netze betreffen.

Zu prüfen sind:

tatsächliche Quellnetze,
Zielnetze,
Protokolle und Ports,
verwendete Sicherheitszone,
Regelreihenfolge,
Regeländerungen,
NAT,
Sitzungszustände,
Hochverfügbarkeitsstatus,
Routing auf der Firewall,
Schnittstellenstatus,
Ressourcenverbrauch,
Lizenz- oder Zertifikatsstatus,
Protokolle zum Fehlerzeitpunkt,
IPv4- und IPv6-Regeln,
Rückweg.

Mögliche Symptome

Beobachtung	mögliche Einordnung
interne Kommunikation funktioniert, Internet nicht	Firewall, NAT, WAN oder Provider
nur ein VLAN erreicht das Internet nicht	Zone, Regel, NAT oder Route
neue Verbindungen scheitern, bestehende funktionieren	Sitzungsgrenze, Zustandsübergang oder Regeländerung
nur HTTPS scheitert	Filter, Proxy, TLS-Inspektion oder Zertifikat
aktive Firewall meldet fehlerfreien Zustand, Verkehr fällt aus	Datenebene, Route, Schnittstelle oder Clusterzustand
nach Failover tritt Fehler auf	unsynchronisierte Zustände, Route, NAT oder Konfiguration

Eine Firewall sollte während einer größeren Störung nicht pauschal deaktiviert werden. Regeln und Protokolle müssen gezielt untersucht werden.

24. Routing und Rückweg prüfen

Wenn mehrere Netze betroffen sind, ist die Routingstruktur zu untersuchen.

Zu prüfen sind:

verbundene Netze,
statische Routen,
dynamische Routingnachbarschaften,
Standardroute,
spezifische Zielrouten,
Routenauswahl,
Metrik beziehungsweise administrative Distanz,
Policy-based Routing,
VRF,
Route Redistribution,
zusammengefasste Routen,
Rückroute,
asymmetrisches Routing,
kürzlich zurückgezogene Präfixe.

Mögliche Beobachtungen

Gateway ist erreichbar, entfernte Netze nicht.
Einige Zielnetze funktionieren, andere nicht.
Verkehr verlässt den Standort, Antworten kommen nicht zurück.
Nach einem Failover wird ein falscher Pfad gewählt.
Eine spezifische Route fehlt, während die Standardroute besteht.
Ein Standortpräfix wird nicht mehr angekündigt.
Dieselben Adressbereiche werden an mehreren Stellen verwendet.

Ein erfolgreicher Hinweg reicht nicht aus. Ende-zu-Ende-Kommunikation benötigt grundsätzlich auch einen funktionsfähigen Rückweg.

25. WAN- und Standortverbindung prüfen

Wenn lokale Kommunikation funktioniert, aber zentrale Systeme oder andere Standorte nicht erreichbar sind, liegt der Untersuchungsbereich häufig bei der Standortanbindung.

Mögliche Verbindungen:

MPLS,
SD-WAN,
Site-to-Site-VPN,
Standleitung,
Metro Ethernet,
Internet-VPN,
Mobilfunk-Fallback,
direkte Cloud-Verbindung.

Zu prüfen sind:

physischer WAN-Link,
Providerübergabe,
WAN-IP-Konfiguration,
Tunnelzustand,
Routingnachbarschaften,
Latenz,
Paketverlust,
Jitter,
MTU,
Verschlüsselungsstatus,
Zertifikate,
aktive und passive Leitungen,
automatische Umschaltung,
tatsächlicher Datenpfad,
Providerstörungsmeldungen.

Abgrenzung

lokales Gateway erreichbar
→ lokaler Server erreichbar
→ zentraler Server nicht erreichbar
→ Internet erreichbar

Dies spricht eher für:

ausgefallenen Standorttunnel,
fehlende Route,
zentrale Firewallregel,
Rückwegproblem,
Ausfall des zentralen Ziels.

Es spricht nicht für einen vollständigen lokalen Netzwerkausfall.

26. Internet- oder Providerstörung prüfen

Ein Provider sollte erst dann als Ursache benannt werden, wenn der lokale Verantwortungsbereich ausreichend geprüft wurde.

Vor einer Eskalation sollten dokumentiert sein:

Kundennummer oder Anschlusskennung,
betroffener Standort,
Beginn der Störung,
Art des Anschlusses,
Status des Providerübergabegeräts,
physischer Link,
WAN-Adresse,
Erreichbarkeit des nächsten Provider-Hops, sofern testbar,
Paketverlust und Laufzeit,
Verhalten einer Ersatzverbindung,
lokale Router- und Firewallzustände,
bereits durchgeführte Tests,
relevante Protokolle.

Ein fehlgeschlagener Ping auf einen Providerrouter beweist keinen Ausfall, da ICMP gefiltert sein kann.

Eine erfolgreiche Mobilfunk- oder Ersatzverbindung zeigt, dass die Anwendung und das Ziel grundsätzlich funktionieren können. Sie beweist aber nicht allein, an welcher Stelle der ursprüngliche Anschluss fehlerhaft ist.

27. Redundanz und Failover nicht voraussetzen

Vorhandene Redundanz bedeutet nicht automatisch, dass ein Ausfall ohne Unterbrechung abgefangen wird.

Zu prüfen sind:

ist die Ersatzkomponente tatsächlich betriebsbereit?
wird ihr Zustand überwacht?
sind Konfigurationen synchron?
existieren gültige Routen?
funktioniert die Umschaltung?
wird die Datenebene geprüft oder nur der Linkstatus?
bestehen gültige Lizenzen und Zertifikate?
reicht die Kapazität der Ersatzverbindung?
wurde das Failover regelmäßig getestet?
funktioniert auch die Rückschaltung?

Mögliche Fehlerbilder

primäre Verbindung ausgefallen, sekundäre Verbindung übernimmt nicht,
sekundäre Verbindung wird aktiv, besitzt aber keine Route,
Firewallcluster wechselt die Rolle, Upstream-Switch verwendet weiterhin den alten Pfad,
Mobilfunk-Fallback ist aktiv, aber dessen Datenvolumen oder Richtlinie verhindert den Verkehr,
beide redundanten Geräte hängen an derselben ausgefallenen Stromversorgung,
beide Leitungen verwenden denselben physischen Gebäudeeintritt.

Redundanz schützt nur vor Fehlern, die im Entwurf berücksichtigt wurden und deren Umschaltung technisch funktioniert.

28. Broadcast-Sturm und Überlastung

Ein größeres Netz kann durch ungewöhnlich hohe Last stark beeinträchtigt werden.

Mögliche Ursachen:

Layer-2-Schleife,
fehlerhaftes Gerät,
Broadcast-Sturm,
Multicast-Flut,
übermäßige unbekannte Unicasts,
Schadsoftware,
fehlerhafte Netzwerkkarte,
Backup- oder Replikationsverkehr,
Denial-of-Service,
überlasteter Uplink,
ausgeschöpfte Firewall-Sitzungstabelle.

Mögliche Hinweise:

hohe Switch-CPU,
stark erhöhte Broadcast-Zähler,
Managementzugriff instabil,
hohe Portauslastung,
Output Drops,
Paketverlust über viele Clients,
zunehmende Latenz,
MAC-Adresstabelle verändert sich fortlaufend,
Problem verschwindet nach Isolation eines bestimmten Bereichs.

Die verursachende Quelle sollte anhand von:

Interface-Zählern,
Flussdaten,
Switch-Protokollen,
MAC-Adresstabellen,
Port Mirroring,
Paketaufzeichnung,
Monitoringverlauf

eingegrenzt werden.

29. Monitoringdaten auswerten

Monitoring kann zeigen, ob der Fehler lokal, zentral oder schrittweise entstanden ist.

Relevante Messwerte:

Geräteerreichbarkeit,
Interface-Status,
Link Flaps,
Bandbreite,
Paketverlust,
Latenz,
CPU,
Speicher,
Temperatur,
Netzteilstatus,
PoE-Verbrauch,
Routingnachbarschaften,
VPN-Tunnel,
DHCP-Auslastung,
DNS-Antwortzeiten,
Firewall-Sitzungen,
Anzahl verbundener WLAN-Clients,
Access-Point-Zustände.

Beispielhafte Ereignisfolge

09:16:58 Uplink Gi1/0/48 meldet Down
09:16:59 Access Switch wird vom Monitoring nicht mehr erreicht
09:17:03 42 Clients werden als nicht erreichbar gemeldet
09:17:05 Access Points verlieren Controllerverbindung
09:17:21 Uplink meldet kurzzeitig Up
09:17:24 Uplink meldet erneut Down

Diese Reihenfolge spricht stärker für einen instabilen gemeinsamen Uplink als für unabhängige Fehler an 42 Clients.

Monitoring kann jedoch Lücken besitzen:

Messintervall zu groß,
Überwachung nur per ICMP,
Monitoringpfad selbst betroffen,
Gerät antwortet auf Management, leitet aber keine Nutzdaten,
Messung erfolgt von nur einem Standort.

30. Protokolle zeitlich korrelieren

Bei einem größeren Ausfall sollten Protokolle verschiedener Systeme anhand derselben Zeitachse verglichen werden.

Relevante Quellen:

Access Switch,
Distribution- und Core-Switch,
Router,
Firewall,
WLAN-Controller,
Access Points,
DHCP-Server,
DNS-Server,
RADIUS-Server,
VPN-Gateway,
Providergerät,
USV,
Virtualisierungsplattform,
Monitoring,
ausgewählte Clients.

Voraussetzung für eine sinnvolle Korrelation ist eine möglichst genaue Zeitsynchronisation.

Beispiel

09:17:02 Distribution Switch: LACP-Mitglied verloren
09:17:03 Access Switch: Uplink-Protokoll wechselt Zustand
09:17:04 Spanning Tree: Topologieänderung
09:17:07 Monitoring: Access Switch nicht erreichbar
09:17:10 DHCP: Anfragen aus VLAN 120 bleiben aus

Diese Kombination ist aussagekräftiger als ein einzelner Clientfehler.

31. Paketaufzeichnung an geeigneten Punkten

Eine Paketaufzeichnung kann zeigen, bis zu welcher Stelle Verkehr gelangt.

Mögliche Aufzeichnungspunkte:

betroffener Client,
funktionierender Vergleichsclient,
Access-Port,
Switch-Uplink,
VLAN-Gateway,
DHCP-Server,
DNS-Server,
Firewall,
Zielserver,
WAN-Schnittstelle.

Mögliche Fragestellungen:

sendet der Client ARP-Anfragen?
erreicht ARP das Gateway?
antwortet das Gateway?
verlassen DHCP-Discover-Pakete das VLAN?
erreicht das DHCP-Offer den Uplink?
werden DNS-Anfragen gesendet?
antwortet der DNS-Server?
erreicht ein TCP-SYN die Firewall?
verlässt es die WAN-Schnittstelle?
kommt eine Antwort zurück?
treten Wiederholungen auf?
werden ICMP-Fehlermeldungen zurückgesendet?

Beispielhafte Wireshark-Filter

arp
dhcp
dns
icmp
icmpv6
stp
eth.addr == <mac-adresse>
ip.addr == <ip-adresse>
tcp.port == 443

Eine Aufzeichnung an nur einem Punkt zeigt nicht automatisch, an welchem Abschnitt eines längeren Pfades ein Paket verloren geht. Bei komplexen Fehlern können zeitlich abgestimmte Aufzeichnungen an mehreren Stellen erforderlich sein.

Paketaufzeichnungen dürfen nur mit Berechtigung erstellt und müssen geschützt gespeichert werden.

32. Änderungen kontrolliert zurücknehmen

Wenn eine konkrete Änderung als Ursache bestätigt oder sehr stark eingegrenzt wurde, kann eine Rücknahme sinnvoll sein.

Vor dem Rollback sind zu klären:

ist der vorherige Zustand dokumentiert?
ist die alte Konfiguration weiterhin gültig?
wurden seitdem weitere abhängige Änderungen durchgeführt?
bestehen Sicherheitsrisiken durch die Rücknahme?
ist ein Wartungs- oder Freigabeprozess erforderlich?
kann die Rücknahme weitere Bereiche beeinträchtigen?
existiert eine aktuelle Sicherung?
wie wird der Erfolg geprüft?
wie wird bei Misserfolg weiter vorgegangen?

Ein Rollback ist keine beliebige Rückkehr zu einer alten Konfiguration. Es ist eine geplante Änderung mit eigener Risiko- und Nachprüfung.

33. Ungeeignete Sofortmaßnahmen

Bei einem größeren Ausfall können unkoordinierte Eingriffe den Fehler ausweiten oder wichtige Spuren vernichten.

Problematisch sind insbesondere:

alle Switches neu starten,
Firewall neu starten,
Router neu starten,
mehrere Uplinks gleichzeitig trennen,
Spanning Tree deaktivieren,
alle Ports administrativ aktivieren,
VLANs neu anlegen, ohne den Ausgangszustand zu sichern,
Firewall vollständig deaktivieren,
DHCP-Bereiche ungeprüft vergrößern,
Switch-Konfiguration durch eine alte Sicherung überschreiben,
Firmware während der Störung aktualisieren,
Provider ohne lokale Prüfung als Ursache festlegen,
mehrere Teams unabhängig Änderungen durchführen lassen,
Geräte austauschen, bevor Verkabelung und Konfiguration dokumentiert wurden.

Solche Maßnahmen können im Einzelfall notwendig sein. Sie benötigen jedoch:

technische Begründung,
Freigabe,
Koordination,
dokumentierten Ausgangszustand,
Rückfallmöglichkeit,
vollständige Nachprüfung.

34. Praxisfall A: Gesamte Etage ohne kabelgebundenes Netzwerk

Symptom

alle geprüften Ethernet-Clients der dritten Etage sind betroffen,
WLAN funktioniert,
andere Etagen funktionieren,
Clients erhalten keine DHCP-Adresse,
Access Switch ist über eine separate Managementverbindung erreichbar.

Prüfung

betroffene Access-Ports und VLANs dokumentieren.
Uplinkstatus des Etagen-Switches prüfen.
Trunk-Konfiguration beider Seiten vergleichen.
erlaubte VLANs kontrollieren.
Spanning-Tree-Zustand prüfen.
Fehlerzähler des Uplinks auswerten.
MAC-Adresstabelle kontrollieren.
DHCP-Verkehr am Client-VLAN untersuchen.
letzte Konfigurationsänderungen prüfen.
nach einer freigegebenen Korrektur alle betroffenen VLANs testen.

Mögliche Ursache

Bei einer Änderung wurde das Client-VLAN aus der Liste der auf dem Uplink erlaubten VLANs entfernt. Das Management-VLAN blieb verfügbar, weshalb der Switch weiterhin administrierbar war.

Nachprüfung

Clients erhalten Adressen aus dem richtigen Bereich,
Gateway ist erreichbar,
interne DNS-Auflösung funktioniert,
zentrale Anwendungen sind erreichbar,
Internetzugriff funktioniert,
weitere VLANs des Switches funktionieren,
Trunk-Konfiguration beider Seiten ist dokumentiert.

35. Praxisfall B: Ganzer Standort erreicht zentrale Systeme nicht

Symptom

lokale Drucker und lokale Server funktionieren,
das lokale Gateway ist erreichbar,
zentrale Anwendungen sind nicht erreichbar,
andere Standorte funktionieren,
öffentlicher Internetzugriff funktioniert.

Prüfung

lokale Kommunikation bestätigen.
zentrale Ziele per IP testen.
Standorttunnel prüfen.
Routingtabelle kontrollieren.
Ankündigung des Standortpräfixes prüfen.
Rückroute am zentralen Standort untersuchen.
Firewallprotokolle auswerten.
Tunnel- und Routingereignisse zeitlich vergleichen.
redundante Verbindung prüfen.
ursprünglichen Anwendungszugriff nach der Korrektur wiederholen.

Mögliche Ursache

Nach einer Änderung wurde das lokale Standortpräfix nicht mehr über den VPN-Tunnel angekündigt. Der Hinweg zu zentralen Systemen war teilweise vorhanden, die Antworten besaßen jedoch keine passende Rückroute.

Nachprüfung

zentrale IP-Ziele erreichbar,
zentrale DNS-Namen auflösbar,
benötigte Anwendungsports erreichbar,
Hin- und Rückroute vorhanden,
erneuter Tunnelaufbau erfolgreich,
Internetverkehr weiterhin funktionsfähig.

36. Praxisfall C: Neue Clients erhalten kein Netzwerk

Symptom

bereits aktive Clients funktionieren,
neu gestartete oder neu angeschlossene Clients erhalten keine Adresse,
mehrere Bereiche desselben VLANs sind betroffen,
statisch konfigurierte Infrastrukturgeräte bleiben erreichbar.

Prüfung

Adressbereich und freie Leases kontrollieren.
DHCP-Dienstzustand prüfen.
DHCP-Failoverstatus prüfen.
Discover-, Offer-, Request- und ACK-Ablauf aufzeichnen.
DHCP-Relay prüfen.
DHCP-Snooping-Zustand kontrollieren.
Lease-Dauer und Anzahl aktiver Geräte auswerten.
unerwünschte DHCP-Server ausschließen.
freigegebene Korrektur durchführen.
mehrere neue Adressvergaben testen.

Mögliche Ursache

Der DHCP-Bereich besitzt keine freien Adressen mehr. Bestehende Clients können ihre noch gültigen Adressen weiterverwenden, während neue Clients keine Lease erhalten.

Nachprüfung

neue Clients erhalten gültige Adressen,
Gateway- und DNS-Optionen stimmen,
Lease-Erneuerung funktioniert,
Failoverzustand ist fehlerfrei,
Adressauslastung wird überwacht,
Ursache der unerwartet hohen Belegung ist dokumentiert.

37. Praxisfall D: Viele Benutzer melden „kein Internet“

Symptom

Gateway ist erreichbar,
öffentliche IP-Ziele sind erreichbar,
Websites können über Namen nicht geöffnet werden,
interne Anwendungen mit bereits bekannten Adressen funktionieren teilweise.

Prüfung

IP-Verbindung getrennt von DNS testen.
jeden konfigurierten DNS-Server einzeln abfragen.
DNS-Dienstzustand prüfen.
Firewallregeln für DNS kontrollieren.
Weiterleitungen und Rekursion prüfen.
DHCP-DNS-Optionen auswerten.
Serverprotokolle zum Fehlerzeitpunkt prüfen.
internen und externen Namen testen.
DNS-Korrektur durchführen.
ursprüngliche Anwendungen erneut prüfen.

Mögliche Ursache

Der primäre und sekundäre DNS-Dienst waren auf derselben ausgefallenen Virtualisierungsplattform betrieben. Die Clients besaßen weiterhin eine funktionierende IP-Verbindung, konnten jedoch keine Namen auflösen.

Nachprüfung

interne Namen werden korrekt aufgelöst,
externe Namen werden korrekt aufgelöst,
jeder vorgesehene DNS-Server antwortet,
Webanwendungen funktionieren,
Active-Directory-abhängige Dienste funktionieren,
tatsächliche Unabhängigkeit der DNS-Redundanz wird bewertet.

38. Praxisfall E: Standort fällt trotz redundanter WAN-Leitung aus

Symptom

primäre Leitung ist ausgefallen,
sekundäre Leitung wird als aktiv angezeigt,
zentrale Anwendungen und Internet sind trotzdem nicht erreichbar,
lokale Kommunikation funktioniert.

Prüfung

physischen Zustand beider Leitungen prüfen.
aktive Standardroute kontrollieren.
Tunnelzustand der Ersatzleitung prüfen.
NAT und Firewallregeln prüfen.
Routingankündigungen kontrollieren.
DNS-Erreichbarkeit über den Ersatzpfad testen.
MTU und Paketgröße berücksichtigen.
Providerübergaben beider Leitungen vergleichen.
Datenverkehr auf der Ersatzschnittstelle aufzeichnen.
vollständigen Failover- und Rückschalttest planen.

Mögliche Ursache

Die Ersatzleitung war physisch aktiv, besaß jedoch wegen einer fehlenden Standardroute keinen verwendbaren Datenpfad.

Nachprüfung

Internet und zentrale Dienste über Ersatzleitung erreichbar,
Tunnel aktiv,
DNS erreichbar,
benötigte NAT- und Firewallregeln wirksam,
automatisches Failover reproduzierbar,
Rückschaltung kontrolliert,
Monitoring erkennt nicht nur den Link-, sondern auch den Dienstzustand.

39. Häufige Fehlinterpretationen

Aussage	fachliche Einordnung
„Viele Benutzer sind betroffen, also ist der Provider ausgefallen.“	Auch Switch, VLAN, Gateway, DHCP, DNS, Firewall oder Standortanbindung können gemeinsam verantwortlich sein.
„Der Switch ist erreichbar, also funktioniert er.“	Management- und Nutzdatenpfad können getrennt sein.
„Alle Ports zeigen Link, also ist das Netzwerk in Ordnung.“	VLAN, Trunk, Gateway, DHCP und Routing können trotzdem fehlerhaft sein.
„WLAN funktioniert, also kann der Switch nicht betroffen sein.“	WLAN kann einen anderen Access Switch, ein anderes VLAN oder einen anderen Datenpfad verwenden.
„Nur ein VLAN ist ausgefallen, also ist das Gateway defekt.“	Auch Trunk, Relay, ACL oder VLAN-Zuordnung können betroffen sein.
„Alte Clients funktionieren, also funktioniert DHCP.“	Alte Clients können noch gültige Leases verwenden.
„Die redundante Leitung ist aktiv, also funktioniert das Failover.“	Linkstatus bestätigt keinen vollständigen Datenpfad.
„Die Firewall zeigt Grün, also blockiert sie nichts.“	Regeln, NAT, Routing oder Datenebene können trotzdem fehlerhaft sein.
„Nach einem Neustart funktioniert alles, also ist die Ursache behoben.“	Der Neustart kann Zustand und Spuren verändert haben, ohne die Ursache zu erklären.
„Eine hohe CPU-Auslastung beweist einen Angriff.“	Schleifen, Fehler, Monitoring, legitime Last und Kontrollprotokolle sind ebenfalls möglich.
„Der letzte sichtbare Traceroute-Hop ist defekt.“	Router können Antworten filtern und Verkehr trotzdem weiterleiten.
„Zwei Netzteile bedeuten vollständige Redundanz.“	Beide können an derselben Stromquelle oder USV angeschlossen sein.

40. Vollständige Prüfreihenfolge

konkrete Symptome und betroffene Anwendungen erfassen.
Anzahl und Verteilung der betroffenen Clients bestimmen.
Ethernet, WLAN, Telefonie und andere Gerätetypen unterscheiden.
funktionierende Vergleichsbereiche bestimmen.
Beginn, Verlauf und letzte bekannte Funktion dokumentieren.
letzte Änderungen und Wartungsarbeiten prüfen.
geschäftliche Auswirkung und Priorität bewerten.
Zuständigkeiten und Kommunikation koordinieren.
repräsentative betroffene und funktionierende Testpunkte auswählen.
gemeinsame technische Abhängigkeiten abbilden.
Stromversorgung, USV und Umgebung prüfen.
Access Switch und physische Uplinks untersuchen.
Fehlerzähler und Link Flaps auswerten.
Trunk- und VLAN-Konfiguration prüfen.
Spanning Tree und mögliche Schleifen untersuchen.
Link Aggregation und LACP prüfen.
Gateway und First-Hop-Redundanz kontrollieren.
DHCP-Dienst, Bereiche und Relay untersuchen.
DNS getrennt von der IP-Verbindung prüfen.
Netzwerkzugangskontrolle und Authentifizierung berücksichtigen.
bei WLAN-Störungen Access Points und Controller prüfen.
Firewall, ACL, NAT und Sicherheitszonen untersuchen.
Routing einschließlich Rückweg prüfen.
WAN, VPN und Providerübergabe kontrollieren.
tatsächliche Funktion redundanter Pfade prüfen.
Monitoringdaten und Protokolle zeitlich korrelieren.
bei Bedarf autorisierte Paketaufzeichnungen erstellen.
eine konkrete Hypothese formulieren.
Änderung oder Rollback freigeben lassen.
immer nur eine kontrollierbare Änderung durchführen.
ursprüngliches Symptom erneut testen.
weitere VLANs, Standorte und Dienste auf Nebenwirkungen prüfen.
Redundanz und erneuten Verbindungsaufbau testen.
Ursache, Maßnahme, Ergebnis und verbleibendes Risiko dokumentieren.
notwendige Präventionsmaßnahmen festlegen.

41. Dokumentationsbeispiel

Ticket: INC-20614
Beginn: 01.08.2026, etwa 09:17 Uhr
Standort: Gebäude B
Umfang: kabelgebundene Clients der dritten Etage
Nicht betroffen: WLAN, andere Etagen, zentrale Server

Symptom:
Betroffene Clients erhalten keine DHCP-Adresse und können das
Standardgateway nicht erreichen.

Ausgangszustand:
- Access Switch erreichbar
- Clientports physisch aktiv
- WLAN derselben Etage funktioniert
- andere Etagen im gleichen Client-VLAN funktionieren
- Uplink des Access Switches aktiv
- Client-VLAN nicht in der Liste der erlaubten Uplink-VLANs
- Management-VLAN weiterhin erlaubt

Hypothese:
Das Client-VLAN wird am Uplink des Etagen-Switches nicht mehr
transportiert.

Prüfung:
- Trunk-Konfiguration beider Uplink-Seiten verglichen
- Konfigurationsänderung um 09:14 Uhr festgestellt
- Client-VLAN fehlte nur auf der Seite des Access Switches
- DHCP-Discover war am Clientport, aber nicht am Distribution Switch sichtbar

Ursache:
Unvollständige Liste erlaubter VLANs nach einer Uplink-Änderung.

Maßnahme:
Client-VLAN nach Freigabe wieder auf dem Uplink zugelassen.

Nachprüfung:
- mehrere Clients erhalten gültige DHCP-Adressen
- Standardgateway erreichbar
- interne DNS-Auflösung erfolgreich
- zentrale Anwendungen erreichbar
- Internetzugriff funktioniert
- WLAN weiterhin funktionsfähig
- weitere VLANs des Access Switches geprüft
- Konfiguration gespeichert und dokumentiert

Prävention:
- Konfigurationsprüfung für Trunk-Änderungen ergänzen
- VLAN-Erreichbarkeit in das Monitoring aufnehmen
- Peer-Review für Änderungen an produktiven Uplinks einführen

42. Checkliste für mehrere Clients oder einen Standort ohne Netzwerk

43. Schnellreferenz

Fehlerumfang	wahrscheinlicher gemeinsamer Untersuchungsbereich
einzelne Clients an einem Switch	Access-Ports, VLAN, Switch oder Uplink
komplette Etage	Etagen-Switch, Uplink, Strom oder VLAN-Pfad
ein VLAN an mehreren Switches	Gateway, DHCP, VLAN-Trunks, ACL oder Routing
nur neue Clients	DHCP, Authentifizierung oder Adressbereich
nur WLAN-Clients	Access Points, Controller, SSID, RADIUS, VLAN oder DHCP
Ethernet und WLAN eines Standorts	Gateway, Firewall, WAN, zentrale Dienste oder Strom
lokale Systeme funktionieren, zentrale nicht	WAN, VPN, Routing, Firewall oder Rückweg
IP-Ziele funktionieren, Namen nicht	DNS
interne Ziele funktionieren, Internet nicht	Firewall, NAT, WAN oder Provider
alle Standorte betroffen	zentrale Firewall, DNS, Rechenzentrum, Cloud oder zentraler Routingbereich
sporadische Ausfälle vieler Clients	Schleife, instabiler Uplink, Überlastung oder Redundanzproblem
bestehende Sitzungen funktionieren, neue nicht	DHCP, DNS, Authentifizierung, Firewallzustand oder Kapazitätsgrenze

Merksatz

Bei mehreren gleichzeitig betroffenen Clients wird nicht jedes Endgerät einzeln als unabhängiger Fehlerfall behandelt. Entscheidend ist der kleinste gemeinsame Ausfallbereich. Funktionierende Vergleichsbereiche, gemeinsame Abhängigkeiten, Zeitstempel und gezielte Tests führen von der allgemeinen Meldung „Standort ohne Netzwerk“ zu einer überprüfbaren Ursache.

Quellen und weiterführende Dokumentation

6.3 IP-Adresse erreichbar, Name nicht – DNS- und Namensauflösungsfehler

Wenn ein Ziel über seine IP-Adresse erreichbar ist, der Zugriff über den Namen jedoch scheitert, funktioniert die grundlegende IP-Kommunikation wahrscheinlich. Der Fehler liegt dann häufig bei der Namensauflösung, ihrer Konfiguration oder einem davon abhängigen Dienst.

Typische Meldungen sind:

„Die Website ist nicht erreichbar.“
„Der Server wurde nicht gefunden.“
„Der Netzwerkname wurde nicht gefunden.“
„Der Hostname kann nicht aufgelöst werden.“
„Mit der IP-Adresse funktioniert es.“
„Internet geht, aber interne Anwendungen nicht.“
„Einige Namen funktionieren, andere nicht.“

Die Aussage „IP geht, Name geht nicht“ grenzt den Fehlerbereich ein. Sie beweist aber noch nicht, dass ausschließlich der DNS-Server defekt ist.

1. Technischer Zusammenhang

Anwendungen verwenden häufig Namen statt IP-Adressen.

Benutzer oder Anwendung
        ↓
fragt nach server.example.test
        ↓
Namensauflösung
        ↓
liefert eine IP-Adresse
        ↓
Verbindung zur IP-Adresse

Beispiel:

intranet.example.test → 192.0.2.40

Kann der Client 192.0.2.40 erreichen, den Namen intranet.example.test jedoch nicht auflösen, müssen insbesondere folgende Bereiche untersucht werden:

DNS-Konfiguration des Clients,
Erreichbarkeit des DNS-Servers,
DNS-Dienst,
zuständige Zone,
benötigter Resource Record,
Weiterleitung oder Rekursion,
Suchsuffix,
lokale Namensquellen,
Cache,
Firewallregeln für DNS,
DNSSEC,
Split-DNS,
VPN- oder standortspezifische DNS-Konfiguration.

2. Fehlerbild zuerst bestätigen

Die Benutzeraussage muss durch konkrete Tests bestätigt werden.

Zu dokumentieren sind:

exakter Name,
vollständiger Name oder Kurzname,
bekannte Ziel-IP-Adresse,
betroffene Anwendung,
Fehlermeldung,
Zeitpunkt,
betroffener Client,
verwendete Netzwerkverbindung,
verwendeter DNS-Server,
interne oder externe Namensauflösung,
Vergleich mit einem funktionierenden Client.

Beispiel:

Name: fileserver.example.test
IP-Adresse: 192.0.2.40
IP-Adresse erreichbar: ja
Name auflösbar: nein
DNS-Server: 192.0.2.10
Betroffener Client: PC-023
Vergleichsclient: PC-024 funktioniert

Ein Test mit einer IP-Adresse muss denselben Zielsystem- und Netzwerkpfad sinnvoll prüfen. Der Aufruf irgendeiner erreichbaren IP-Adresse ist kein ausreichender Vergleich.

3. IP-Erreichbarkeit und Namensauflösung getrennt prüfen

Zuerst wird geprüft, ob das Ziel grundsätzlich per IP erreichbar ist.

Windows

ping <ip-adresse>
Test-NetConnection <ip-adresse>
Test-NetConnection <ip-adresse> -Port <port>

Linux und macOS

ping <ip-adresse>
traceroute <ip-adresse>
nc -vz <ip-adresse> <port>

Danach wird derselbe Dienst über den Namen getestet.

Windows

ping <name>
Resolve-DnsName <name>
Test-NetConnection <name> -Port <port>

Linux und macOS

ping <name>
dig <name>
host <name>
nslookup <name>

Mögliche Einordnung

Ergebnis	mögliche Einordnung
IP und Name funktionieren	Fehler liegt möglicherweise bei Anwendung, Port, Authentifizierung oder zeitweiligem Zustand
IP funktioniert, Name wird nicht aufgelöst	Namensauflösung untersuchen
Name wird korrekt aufgelöst, Verbindung scheitert	Zieladresse, Port, Firewall, Routing oder Anwendung untersuchen
IP und Name scheitern	grundlegende IP-Verbindung, Routing, Firewall oder Zielsystem untersuchen
Name liefert eine falsche IP-Adresse	DNS-Daten, Cache, Hosts-Datei oder Split-DNS untersuchen
nur der Kurzname scheitert	DNS-Suffix oder Suchliste untersuchen
vollständiger Name und Kurzname scheitern	DNS-Server, Zone, Record oder Transport untersuchen

Eine erfolgreiche Namensauflösung beweist nicht, dass der Zielservice erreichbar ist. Sie bestätigt zunächst nur, dass eine Antwort für den Namen geliefert wurde.

4. Vollständigen Namen verwenden

Bei der Fehlersuche sollte zwischen Kurzname und Fully Qualified Domain Name unterschieden werden.

Beispiel:

Kurzname:
fileserver

Vollständiger Name:
fileserver.example.test

Funktioniert der vollständige Name, der Kurzname jedoch nicht, sind häufig folgende Bereiche betroffen:

DNS-Suffix fehlt,
falsches DNS-Suffix,
falsche Suchreihenfolge,
VPN stellt keine benötigte Suchdomäne bereit,
DHCP verteilt eine falsche Domänenoption,
Kurzname wird über eine andere Auflösungsmethode gesucht,
mehrere gleichnamige Geräte existieren in verschiedenen Domänen.

Windows

ipconfig /all
Get-DnsClientGlobalSetting
Get-DnsClient

Linux

cat /etc/resolv.conf
resolvectl status

macOS

scutil --dns

Zu prüfen sind:

primäres DNS-Suffix,
verbindungsspezifisches DNS-Suffix,
DNS-Suffixsuchliste,
Reihenfolge der Suchdomänen,
aktive Netzwerkschnittstelle,
vom DHCP-Server gelieferte Einstellungen,
vom VPN-Client ergänzte Einstellungen.

5. Konfigurierte DNS-Server prüfen

Ein Client muss die vorgesehenen DNS-Server verwenden.

Windows

ipconfig /all
Get-DnsClientServerAddress

Linux

resolvectl status
cat /etc/resolv.conf
nmcli device show

macOS

scutil --dns
networksetup -getdnsservers <netzwerkdienst>

Zu prüfen sind:

richtige DNS-Serveradressen,
Reihenfolge der DNS-Server,
IPv4- und IPv6-Konfiguration,
statische oder dynamische Konfiguration,
DNS-Angaben aus DHCP,
DNS-Einstellungen des VPN-Clients,
lokale Resolver,
Sicherheitssoftware oder DNS-Filter,
unerwünschte öffentliche DNS-Server.

In einer Active-Directory-Umgebung dürfen Clients für interne AD-Namen normalerweise nicht ausschließlich beliebige öffentliche DNS-Resolver verwenden. Ein öffentlicher Resolver kennt die internen DNS-Zonen nicht.

6. Jeden DNS-Server einzeln abfragen

Sind mehrere DNS-Server eingetragen, muss jeder Server gezielt getestet werden.

Windows

Resolve-DnsName <name> -Server <dns-server-1>
Resolve-DnsName <name> -Server <dns-server-2>

Alternativ:

nslookup <name> <dns-server-1>
nslookup <name> <dns-server-2>

Linux und macOS

dig @<dns-server-1> <name>
dig @<dns-server-2> <name>

Beispielhafte Auswertung

DNS-Server 1	DNS-Server 2	mögliche Einordnung
richtige Antwort	richtige Antwort	DNS-Server grundsätzlich konsistent
richtige Antwort	keine Antwort	zweiter Server, Netzwerkpfad oder Firewall
richtige Antwort	falsche Antwort	abweichende Zone, Replikation oder veraltete Daten
keine Antwort	keine Antwort	Erreichbarkeit, Dienst, Firewall oder Clientkonfiguration
`NXDOMAIN`	richtige Antwort	inkonsistente Zonen oder verschiedene DNS-Sichten
unterschiedliche IP-Adressen	möglicherweise Split-DNS, Replikationsfehler oder abweichende Records

Ein Client wechselt nicht in jedem Fall zum nächsten DNS-Server, nur weil der erste Server eine fachlich falsche Antwort liefert. Eine erhaltene negative oder falsche Antwort ist etwas anderes als ein nicht antwortender Server.

7. Bedeutung häufiger DNS-Ergebnisse

DNS-Abfragen können unterschiedliche Rückmeldungen liefern.

Ergebnis	Bedeutung	möglicher Untersuchungsbereich
`NOERROR` mit Antwort	Name wurde beantwortet	zurückgegebene Daten auf Richtigkeit prüfen
`NOERROR` ohne passende Antwort	Name oder Typ besitzt möglicherweise keinen entsprechenden Record	Record-Typ, Zone oder Alias prüfen
`NXDOMAIN`	angefragter Name existiert aus Sicht des antwortenden Servers nicht	Schreibweise, Zone, Record, Cache oder falscher DNS-Server
`SERVFAIL`	Server konnte die Anfrage nicht erfolgreich bearbeiten	DNSSEC, Delegation, Upstream-Server oder Serverfehler
`REFUSED`	Server verweigert die Anfrage	Richtlinie, Rekursion, ACL oder nicht erlaubter Client
Zeitüberschreitung	keine rechtzeitige DNS-Antwort	Erreichbarkeit, Port 53, Überlastung oder Dienst
falsche IP-Adresse	Antwort vorhanden, aber ungeeignet	Record, Cache, Hosts-Datei, Split-DNS oder Replikation
`CNAME` ohne erreichbares Endziel	Alias vorhanden, Zielname problematisch	CNAME-Kette und Zielzone untersuchen

Die Meldung NXDOMAIN bedeutet nicht automatisch, dass der gesamte DNS-Dienst ausgefallen ist. Der Server hat geantwortet, kennt den angefragten Namen jedoch nicht.

8. Record-Typ gezielt prüfen

DNS enthält verschiedene Resource Records.

Typ	Aufgabe
`A`	Name zu IPv4-Adresse
`AAAA`	Name zu IPv6-Adresse
`CNAME`	Alias auf einen anderen Namen
`PTR`	IP-Adresse zu Name bei Rückwärtsauflösung
`MX`	zuständiger Mailserver
`NS`	autoritativer Nameserver einer Zone
`SOA`	Verwaltungsinformationen einer Zone
`SRV`	Dienst und zuständiger Server
`TXT`	Textinformationen, Prüf- und Richtliniendaten

Windows

Resolve-DnsName <name> -Type A
Resolve-DnsName <name> -Type AAAA
Resolve-DnsName <name> -Type CNAME
Resolve-DnsName <domain> -Type NS
Resolve-DnsName <domain> -Type SOA
Resolve-DnsName <dienstname> -Type SRV

Linux und macOS

dig A <name>
dig AAAA <name>
dig CNAME <name>
dig NS <domain>
dig SOA <domain>
dig SRV <dienstname>

Wenn eine Anwendung einen bestimmten Record-Typ benötigt, reicht die erfolgreiche Abfrage eines anderen Typs nicht aus.

Beispielsweise können Active-Directory-Dienste von SRV-Records abhängig sein. Ein vorhandener A-Record des Domain Controllers beweist nicht, dass alle benötigten SRV-Records korrekt vorhanden sind.

9. DNS-Transport und Port 53 prüfen

DNS verwendet grundsätzlich:

UDP Port 53,
TCP Port 53.

UDP wird häufig für normale Abfragen verwendet. TCP kann unter anderem bei größeren, abgeschnittenen oder bestimmten serverseitigen Übertragungen erforderlich sein.

Zu prüfen sind:

Client erreicht DNS-Server per IP,
UDP Port 53 ist erlaubt,
TCP Port 53 ist erlaubt,
lokale Firewall blockiert nicht,
Netzwerk-Firewall blockiert nicht,
VPN erlaubt DNS-Verkehr,
DNS-Server lauscht auf der vorgesehenen Adresse,
Antwortpakete erreichen den Client,
NAT oder Sicherheitsfilter verändern den Verkehr nicht.

Windows

Test-NetConnection <dns-server> -Port 53

Dieser Test prüft TCP Port 53. Er ersetzt keine Prüfung von UDP-DNS.

Linux und macOS

dig @<dns-server> <name>
dig +tcp @<dns-server> <name>

Mögliche Beobachtungen

Beobachtung	mögliche Einordnung
UDP-Abfrage funktioniert, TCP-Abfrage scheitert	Firewall oder Dienstkonfiguration für TCP 53
kleine Antworten funktionieren, größere nicht	TCP-Fallback, Fragmentierung, EDNS oder MTU
Anfrage verlässt Client, keine Antwort sichtbar	DNS-Server, Rückweg oder Filter
Antwort erreicht Netzwerkschnittstelle, Anwendung erhält sie nicht	lokale Firewall, Resolver oder Sicherheitssoftware
DNS-Server ist per IP erreichbar, Port 53 antwortet nicht	Dienst, Firewall oder falsche Zieladresse

10. Lokalen DNS-Cache prüfen

Clients und Resolver speichern DNS-Antworten für eine bestimmte Zeit. Auch negative Antworten können zwischengespeichert werden.

Mögliche Symptome:

ein Client erhält eine alte Adresse,
andere Clients funktionieren bereits,
nach einer DNS-Änderung bleibt der Fehler bestehen,
der Name funktioniert nach Ablauf einer gewissen Zeit,
eine direkte Abfrage beim DNS-Server ist korrekt, die Anwendung verwendet aber weiterhin eine alte Antwort.

Windows

ipconfig /displaydns
Clear-DnsClientCache

Alternativ:

ipconfig /flushdns

Linux mit systemd-resolved

resolvectl statistics
sudo resolvectl flush-caches

macOS

Die verwendeten Cache-Mechanismen können von der macOS-Version und dem aktiven Resolver abhängen. Vor einer Cache-Bereinigung sollte deshalb zuerst geprüft werden, ob eine direkte DNS-Abfrage bereits die korrekte Antwort liefert.

Das Leeren des Cache ist eine Prüf- oder Korrekturmaßnahme für zwischengespeicherte Daten. Es behebt keine fehlenden Records, falschen Zonen oder nicht erreichbaren DNS-Server.

11. Hosts-Datei berücksichtigen

Vor oder neben DNS können lokale Namensquellen eine Rolle spielen. Eine fehlerhafte Hosts-Datei kann DNS-Ergebnisse überlagern.

Windows

C:\Windows\System32\drivers\etc\hosts

Linux und macOS

/etc/hosts

Zu prüfen sind:

Eintrag für den betroffenen Namen,
veraltete IP-Adresse,
Schreibfehler,
doppelte Einträge,
Einträge durch Softwareverteilung,
Manipulation durch Schadsoftware,
abweichender Eintrag nur auf einzelnen Clients.

Die Hosts-Datei sollte nicht ungeprüft als dauerhafte Ersatzlösung für einen fehlerhaften DNS-Eintrag verwendet werden. Dadurch würde die zentrale Ursache verborgen und eine schwer wartbare Sonderkonfiguration geschaffen.

12. Zuständige Zone und autoritative Server prüfen

Für einen internen Namen muss die zuständige DNS-Zone vorhanden und auf den vorgesehenen Servern verfügbar sein.

Zu prüfen sind:

existiert die Zone?
ist sie geladen?
enthält sie den benötigten Record?
ist der Record aktiviert und korrekt geschrieben?
zeigt der Record auf die richtige Adresse?
besitzt die Zone korrekte NS-Einträge?
ist die Delegation korrekt?
stimmen primäre und sekundäre Kopien überein?
funktioniert die Replikation?
ist die Seriennummer plausibel?
bestehen abgelaufene oder veraltete Zonendaten?
ist eine bedingte Weiterleitung erforderlich?
antwortet der abgefragte Server autoritativ?

Windows-DNS-Server

Get-DnsServerZone
Get-DnsServerResourceRecord -ZoneName <zone>
Get-DnsServerForwarder

Allgemeine Abfragen

dig NS <domain>
dig SOA <domain>
dig +trace <domain>

dig +trace zeigt eine schrittweise Auflösung über die DNS-Hierarchie. Für rein interne Zonen ist dieser Test nicht in derselben Weise geeignet wie für öffentlich delegierte Zonen.

13. Rekursion und Weiterleitungen prüfen

Ein interner DNS-Server kennt nicht automatisch alle externen Namen. Er verwendet je nach Konfiguration:

Rekursion,
Root Hints,
allgemeine Forwarder,
Conditional Forwarder,
Stub-Zonen,
interne Delegationen.

Mögliche Fehlerbilder:

interne Namen funktionieren, externe nicht,
externe Namen funktionieren, eine Partnerdomäne nicht,
nur Namen einer bestimmten internen Zone scheitern,
Abfragen an den internen DNS-Server liefern SERVFAIL,
direkte Abfragen an einen öffentlichen Resolver funktionieren,
ein Forwarder ist nicht erreichbar,
eine bedingte Weiterleitung zeigt auf veraltete Server.

Abgrenzung

Ergebnis	möglicher Bereich
interne und externe Namen scheitern	Client, DNS-Server, Dienst oder Transport
interne Namen funktionieren, externe nicht	Rekursion, Forwarder, Root Hints oder Firewall
externe Namen funktionieren, interne nicht	interne Zone, falscher DNS-Server oder Split-DNS
nur eine Partnerdomäne scheitert	Conditional Forwarder, Delegation oder Partner-DNS
nur einzelne Records fehlen	Zone, Replikation oder Record-Verwaltung

14. Split-DNS berücksichtigen

Bei Split-DNS kann derselbe Name abhängig vom verwendeten DNS-Server oder Standort unterschiedliche Antworten liefern.

Beispiel:

intern:
portal.example.test → 192.0.2.50

extern:
portal.example.test → 198.51.100.50

Zu prüfen sind:

befindet sich der Client intern, extern oder im VPN?
welcher DNS-Server beantwortet die Anfrage?
wird die interne oder externe Zone verwendet?
ist die interne Adresse aus dem aktuellen Netz erreichbar?
wird über das VPN der richtige DNS-Server bereitgestellt?
verwendet der Browser oder die Anwendung einen eigenen DNS-Dienst?
existieren widersprüchliche Records?

Ein korrekt funktionierender öffentlicher DNS-Eintrag beweist nicht, dass der interne Eintrag korrekt ist.

15. VPN und mehrere Netzwerkschnittstellen

VPN-Verbindungen können DNS-Einstellungen gezielt verändern.

Mögliche Fehlerbilder:

interne Namen funktionieren nur mit aktivem VPN,
externe Namen funktionieren, interne nicht,
nach dem Trennen des VPN bleibt eine ungeeignete DNS-Konfiguration aktiv,
der Client fragt den DNS-Server der falschen Schnittstelle,
Split-Tunneling und Split-DNS passen nicht zusammen,
lokale und entfernte Netze verwenden dieselbe Domäne,
mehrere aktive Adapter besitzen widersprüchliche DNS-Suffixe.

Zu prüfen sind:

DNS-Server jeder Schnittstelle,
Schnittstellenmetrik,
DNS-Suffixe,
vom VPN übermittelte Suchdomänen,
Routen zum internen DNS-Server,
Erreichbarkeit des DNS-Servers durch den Tunnel,
Richtlinien des VPN-Clients,
Zustand nach erneutem Verbindungsaufbau.

Windows

Get-NetIPConfiguration
Get-DnsClient
Get-DnsClientServerAddress
Get-NetRoute

Linux

ip address
ip route
resolvectl status

macOS

ifconfig
netstat -rn
scutil --dns

16. IPv4 und IPv6 getrennt betrachten

Ein Name kann sowohl einen A- als auch einen AAAA-Record besitzen.

Mögliche Fehlerbilder:

A-Record ist korrekt, AAAA-Record ist falsch,
Client bevorzugt IPv6, der IPv6-Pfad funktioniert jedoch nicht,
Anwendung erhält nur eine IPv6-Adresse,
DNS funktioniert, aber die zurückgegebene Adressfamilie ist nicht erreichbar,
IPv6-DNS-Server ist eingetragen, aber nicht erreichbar.

Zu prüfen sind:

Resolve-DnsName <name> -Type A
Resolve-DnsName <name> -Type AAAA

dig A <name>
dig AAAA <name>
ping -4 <name>
ping -6 <name>

Das pauschale Deaktivieren von IPv6 ist keine fachgerechte Standardlösung. Zuerst muss bestätigt werden, ob tatsächlich ein fehlerhafter AAAA-Record, IPv6-DNS-Server oder IPv6-Datenpfad vorliegt.

17. DNSSEC prüfen

DNSSEC ermöglicht die Prüfung signierter DNS-Daten. Fehler bei Signaturen oder Vertrauenskette können zu SERVFAIL führen.

Mögliche Ursachen:

abgelaufene Signatur,
fehlerhafter DS-Record,
nicht passende Schlüssel,
unvollständige Vertrauenskette,
falsche Systemzeit,
fehlerhafte Zone nach Schlüsselwechsel,
validierender Resolver verwirft die Antwort.

Linux und macOS mit dig

dig +dnssec <name>
dig +trace <name>

Bei DNSSEC-Problemen sollten geprüft werden:

exakter Antwortcode,
gesetzte DNSSEC-Flags,
Systemzeit,
Signaturgültigkeit,
Delegation,
Verhalten eines validierenden und eines nicht validierenden Resolvers.

DNSSEC darf nicht pauschal deaktiviert werden, ohne den Fehler einzugrenzen und die Sicherheitsauswirkung zu bewerten.

18. Browser und verschlüsseltes DNS

Ein Browser oder eine Sicherheitsanwendung kann einen eigenen DNS-Auflösungsweg verwenden, beispielsweise DNS over HTTPS.

Mögliche Beobachtungen:

Resolve-DnsName oder dig liefert eine richtige Antwort,
nur ein bestimmter Browser verwendet eine falsche oder keine Antwort,
Browser und Betriebssystem zeigen unterschiedliche Ergebnisse,
interne Namen funktionieren in einer Anwendung, im Browser jedoch nicht,
DNS-Filter oder Proxy beeinflusst nur Webverkehr.

Zu prüfen sind:

verwendet die Anwendung den Systemresolver?
ist verschlüsseltes DNS aktiviert?
welcher Resolver wird dabei verwendet?
kann dieser Resolver interne Zonen kennen?
besteht ein Proxy?
besitzt die Anwendung einen eigenen Cache?
greift eine Sicherheitsrichtlinie ein?

Ein funktionierender Kommandozeilentest beweist daher nicht in jedem Fall, dass die betroffene Anwendung denselben Resolver und dieselben DNS-Daten verwendet.

19. mDNS, LLMNR und NetBIOS nicht mit DNS verwechseln

Kurznamen und lokale Gerätenamen können abhängig vom Betriebssystem auch über andere Verfahren aufgelöst werden.

Mögliche Verfahren:

DNS,
lokale Hosts-Datei,
Multicast DNS,
Link-Local Multicast Name Resolution,
NetBIOS Name Service,
anwendungseigene Verzeichnisse.

Wenn ein Kurzname funktioniert, ist damit nicht automatisch bewiesen, dass DNS funktioniert. Der Name könnte über ein anderes Verfahren aufgelöst worden sein.

Für eine eindeutige DNS-Prüfung sollten gezielte Werkzeuge verwendet werden:

Resolve-DnsName <vollständiger-name> -Server <dns-server>

dig @<dns-server> <vollständiger-name>

20. Reverse DNS getrennt prüfen

Die Rückwärtsauflösung ordnet einer IP-Adresse einen Namen zu. Dafür werden PTR-Records verwendet.

Beispiel:

192.0.2.40 → fileserver.example.test

Windows

Resolve-DnsName <ip-adresse> -Type PTR

Linux und macOS

dig -x <ip-adresse>

Eine fehlende Rückwärtsauflösung verhindert nicht grundsätzlich jede Verbindung zur IP-Adresse. Bestimmte Anwendungen, Protokollierungen, Authentifizierungsverfahren oder Sicherheitsprüfungen können jedoch von einem korrekten PTR-Record abhängen.

Vorwärts- und Rückwärtsauflösung sind deshalb getrennt zu prüfen.

21. Active Directory und DNS

Active Directory ist stark von DNS abhängig.

DNS-Fehler können unter anderem beeinträchtigen:

Domänenanmeldung,
Auffinden von Domain Controllern,
Gruppenrichtlinien,
Kerberos,
LDAP,
Replikation,
Datei- und Druckdienste,
Zertifikatsdienste,
Verwaltungswerkzeuge.

Benötigt werden unter anderem SRV-Records.

Beispielhafte Prüfung:

Resolve-DnsName _ldap._tcp.dc._msdcs.<domain> -Type SRV
Resolve-DnsName _kerberos._tcp.<domain> -Type SRV

Zu prüfen sind:

verwendet der Client ausschließlich vorgesehene interne DNS-Server?
sind SRV-Records vorhanden?
sind die eingetragenen Domain Controller erreichbar?
stimmen Systemzeit und Domänenzugehörigkeit?
sind DNS-Zonen zwischen Domain Controllern repliziert?
existieren alte Records nicht mehr vorhandener Systeme?
funktioniert die dynamische DNS-Registrierung?

22. Dynamische DNS-Registrierung

Clients und Server können ihre Records dynamisch registrieren.

Mögliche Fehlerbilder:

neuer Client besitzt noch keinen Record,
Record zeigt auf eine alte Adresse,
DHCP aktualisiert DNS nicht,
Client darf den Record nicht aktualisieren,
alter Record wurde nicht entfernt,
Gerät besitzt mehrere Schnittstellen und registriert eine ungeeignete Adresse,
Replikation verteilt den aktualisierten Record nicht.

Windows-Client

ipconfig /registerdns

Vor der Verwendung ist zu prüfen:

soll der Client den Record selbst registrieren?
übernimmt DHCP die Registrierung?
besitzt der Client eine gültige DNS-Konfiguration?
ist die Zone für dynamische Updates eingerichtet?
bestehen ausreichende Berechtigungen?
existiert bereits ein Record mit abweichendem Besitzer?

ipconfig /registerdns ist keine Lösung für einen falsch eingerichteten DNS-Server oder eine fehlende Zone.

23. Zeitabhängige und sporadische Fehler

Sporadische Namensauflösungsfehler können entstehen durch:

inkonsistente DNS-Server,
fehlerhafte Replikation,
abwechselnd richtige und falsche Antworten,
instabile Netzwerkverbindung,
Paketverlust,
überlasteten DNS-Server,
ablaufende oder erneuerte Cache-Einträge,
DNS-Round-Robin,
einen fehlerhaften Server hinter einem Load Balancer,
unterschiedliche VPN-Zustände,
zeitweise nicht erreichbare Forwarder.

Sinnvoll sind wiederholte, zeitgestempelte Abfragen.

PowerShell

1..10 | ForEach-Object {
    Get-Date
    Resolve-DnsName <name> -Server <dns-server>
    Start-Sleep -Seconds 2
}

Bash

for i in {1..10}; do
    date
    dig @<dns-server> <name>
    sleep 2
done

Zu vergleichen sind:

Antwortcode,
Antwortadresse,
antwortender Server,
TTL,
Laufzeit,
Häufigkeit von Zeitüberschreitungen.

24. Paketaufzeichnung für DNS

Eine Paketaufzeichnung kann zeigen:

ob der Client eine Anfrage sendet,
welchen DNS-Server er verwendet,
welcher Name und Record-Typ angefragt wird,
ob die Anfrage UDP oder TCP verwendet,
ob eine Antwort zurückkommt,
welcher Antwortcode geliefert wird,
ob Wiederholungen auftreten,
ob verschiedene DNS-Server angesprochen werden,
ob die Antwort abgeschnitten ist,
ob der Client die Antwort verwirft.

Wireshark-Filter

dns
udp.port == 53
tcp.port == 53
dns.qry.name == "<name>"
ip.addr == <dns-server>

Typische Beobachtungen

Paketaufzeichnung	mögliche Einordnung
keine DNS-Anfrage	Anwendungscache, Hosts-Datei, anderer Resolver oder Anwendung sendet nicht
Anfrage an falschen Server	Client-, DHCP-, VPN- oder Schnittstellenkonfiguration
Anfrage, keine Antwort	Server, Transport, Firewall oder Rückweg
Antwort `NXDOMAIN`	Server kennt den Namen nicht
Antwort `SERVFAIL`	serverseitige Auflösung, DNSSEC oder Delegation
richtige Antwort, Anwendung scheitert	Cache, Anwendung, Zielservice oder Datenpfad
wiederholte Anfragen an mehrere Server	Antwortausfall oder Zeitüberschreitung
UDP-Antwort abgeschnitten, TCP scheitert	TCP Port 53, Firewall oder MTU

Paketaufzeichnungen dürfen nur mit entsprechender Berechtigung erstellt und müssen geschützt gespeichert werden.

25. Praxisfall A: Nur ein Client kann einen internen Namen nicht auflösen

Symptom

Server ist per IP erreichbar,
vollständiger interner Name funktioniert auf anderen Clients,
nur ein Client ist betroffen,
externe Namen funktionieren.

Prüfung

DNS-Server des betroffenen Clients prüfen.
mit funktionierendem Client vergleichen.
vollständigen Namen gezielt abfragen.
jeden eingetragenen DNS-Server einzeln testen.
DNS-Cache prüfen.
Hosts-Datei kontrollieren.
VPN- und Schnittstellenkonfiguration prüfen.
Paketaufzeichnung bei Bedarf durchführen.

Mögliche Ursache

Der Client verwendet aufgrund einer statischen Alt-Konfiguration einen öffentlichen DNS-Server. Dieser kann die interne Zone nicht auflösen.

Nachprüfung

interner DNS-Server ist eingetragen,
vollständiger Name wird korrekt aufgelöst,
Kurzname funktioniert mit richtigem Suffix,
externe Namen funktionieren weiterhin,
ursprüngliche Anwendung ist erreichbar.

26. Praxisfall B: Interne Namen funktionieren, externe Namen nicht

Symptom

interne Servernamen werden korrekt aufgelöst,
externe Namen liefern SERVFAIL oder Zeitüberschreitungen,
Internetziele sind per IP erreichbar,
mehrere Clients sind betroffen.

Prüfung

DNS-Server direkt abfragen.
interne und externe Namen vergleichen.
allgemeine Forwarder prüfen.
Erreichbarkeit der Forwarder untersuchen.
Rekursion und Root Hints kontrollieren.
Firewallregeln für UDP und TCP Port 53 prüfen.
Serverprotokolle auswerten.
DNSSEC-Fehler ausschließen.

Mögliche Ursache

Der interne DNS-Server kann interne Zonen selbst beantworten. Der konfigurierte Forwarder für externe Namen ist jedoch nicht mehr erreichbar.

Nachprüfung

interne Namen funktionieren,
externe Namen funktionieren,
mehrere externe Domänen wurden geprüft,
UDP- und TCP-Abfragen sind möglich,
redundante Weiterleitung wurde bewertet,
Monitoring erkennt externe Auflösungsfehler.

27. Praxisfall C: Vollständiger Name funktioniert, Kurzname nicht

Symptom

fileserver.example.test → funktioniert
fileserver → funktioniert nicht

Prüfung

DNS-Suffixsuchliste anzeigen.
verbindungsspezifisches Suffix prüfen.
DHCP-Optionen kontrollieren.
VPN-Konfiguration untersuchen.
mit funktionierendem Client vergleichen.
tatsächlich angefragte Namen in einer Paketaufzeichnung prüfen.

Mögliche Ursache

Nach einer DHCP-Änderung wird das interne DNS-Suffix nicht mehr an neue Clients verteilt.

Nachprüfung

vollständiger Name funktioniert,
Kurzname wird um das richtige Suffix ergänzt,
neue DHCP-Lease enthält die vorgesehene Konfiguration,
andere Namensräume funktionieren weiterhin.

28. Praxisfall D: Einige Clients erhalten eine falsche IP-Adresse

Symptom

derselbe Name liefert unterschiedliche Adressen,
ein Teil der Clients erreicht den Dienst,
andere Clients verbinden sich mit einem alten Server,
beide DNS-Server antworten.

Prüfung

beide DNS-Server einzeln abfragen.
Records und TTL vergleichen.
Zone und Replikationszustand prüfen.
Cache auf Clients und Resolvern berücksichtigen.
Hosts-Dateien ausschließen.
Split-DNS-Konfiguration prüfen.
Anwendung nach Korrektur erneut testen.

Mögliche Ursache

Ein DNS-Server besitzt aufgrund einer Replikationsstörung noch einen alten A-Record.

Nachprüfung

alle vorgesehenen DNS-Server liefern dieselbe korrekte Antwort,
Replikation funktioniert,
alte Records sind entfernt,
Clients erreichen den vorgesehenen Dienst,
Ursache der Replikationsstörung ist dokumentiert.

29. Praxisfall E: DNS-Abfrage funktioniert, Browser nicht

Symptom

Systemwerkzeug liefert die richtige Adresse,
nur ein Browser kann den internen Namen nicht öffnen,
andere Anwendungen funktionieren,
der Browser verwendet verschlüsseltes DNS.

Prüfung

Ergebnis des Systemresolvers dokumentieren.
Browser-DNS-Konfiguration prüfen.
verwendeten verschlüsselten Resolver bestimmen.
Browsercache berücksichtigen.
Proxy- und Sicherheitsrichtlinien kontrollieren.
vollständigen Namen im Browser testen.

Mögliche Ursache

Der Browser sendet DNS-over-HTTPS-Abfragen an einen öffentlichen Resolver, der die interne Zone nicht kennt.

Nachprüfung

Browser verwendet die vorgesehene Unternehmensrichtlinie,
interne Namen werden aufgelöst,
externe Namen funktionieren,
System- und Browserauflösung liefern konsistente Ergebnisse.

30. Ungeeignete Sofortmaßnahmen

Problematisch sind insbesondere:

DNS-Server ungeprüft neu starten,
öffentliche DNS-Server dauerhaft auf internen Clients eintragen,
DNSSEC pauschal deaktivieren,
IPv6 pauschal deaktivieren,
Firewall für Port 53 vollständig öffnen,
fehlende Records durch lokale Hosts-Einträge auf vielen Clients ersetzen,
komplette Zonen neu erstellen,
Replikation ohne Sicherung zurücksetzen,
Caches löschen, ohne vorher den Ausgangszustand zu dokumentieren,
mehrere DNS-Server gleichzeitig verändern,
produktive Records ohne Prüfung löschen,
den DNS-Server als Ursache festlegen, obwohl der Name korrekt aufgelöst wird.

Vor Änderungen sind zu sichern beziehungsweise zu dokumentieren:

aktuelle Clientkonfiguration,
verwendete DNS-Server,
Abfrageergebnisse,
zuständige Zone,
vorhandene Records,
TTL,
Replikationszustand,
Weiterleitungen,
Zeitpunkt und Umfang der Störung.

31. Vollständige Prüfreihenfolge

exakten betroffenen Namen erfassen.
Kurzname und vollständigen Namen unterscheiden.
bekannte Ziel-IP-Adresse dokumentieren.
Ziel per IP-Adresse und benötigtem Port prüfen.
denselben Dienst über den Namen testen.
Fehlermeldung und Zeitpunkt dokumentieren.
betroffene und funktionierende Clients vergleichen.
konfigurierte DNS-Server feststellen.
jeden DNS-Server einzeln abfragen.
Antwortcode und zurückgegebene Records bewerten.
A- und AAAA-Records getrennt prüfen.
DNS-Suffix und Suchliste kontrollieren.
lokale Hosts-Datei prüfen.
Cache nur nach Dokumentation berücksichtigen.
Erreichbarkeit des DNS-Servers prüfen.
UDP und TCP Port 53 berücksichtigen.
zuständige Zone und Record untersuchen.
autoritative Server und Delegation prüfen.
Replikation zwischen DNS-Servern kontrollieren.
Rekursion, Forwarder oder Conditional Forwarder untersuchen.
Split-DNS und aktuellen Standort berücksichtigen.
VPN und mehrere Schnittstellen prüfen.
anwendungseigene Resolver oder verschlüsseltes DNS berücksichtigen.
bei Bedarf eine autorisierte Paketaufzeichnung erstellen.
konkrete Hypothese formulieren.
genau eine kontrollierbare Änderung durchführen.
DNS-Abfrage erneut testen.
ursprüngliche Anwendung erneut testen.
interne und externe Namen prüfen.
zweiten DNS-Server und Vergleichsclient prüfen.
Ursache, Maßnahme und Ergebnis dokumentieren.
Monitoring oder Präventionsmaßnahme festlegen.

32. Dokumentationsbeispiel

Ticket: INC-20631
Beginn: 02.08.2026, etwa 10:35 Uhr
Umfang: neu verbundene VPN-Clients
Betroffen: interne Servernamen
Nicht betroffen: externe DNS-Namen und direkte IP-Verbindungen

Symptom:
Der Server fileserver.example.test ist über 192.0.2.40 erreichbar.
Der Name kann auf betroffenen VPN-Clients nicht aufgelöst werden.

Ausgangszustand:
- VPN-Tunnel aktiv
- Route zum internen Server vorhanden
- Server per IP und TCP Port 445 erreichbar
- externe Namen werden aufgelöst
- betroffene Clients verwenden einen öffentlichen DNS-Server
- interne DNS-Server werden vom VPN nicht bereitgestellt
- funktionierende interne Clients verwenden 192.0.2.10 und 192.0.2.11

Hypothese:
Die VPN-Konfiguration übermittelt nicht die für interne Zonen
zuständigen DNS-Server.

Prüfung:
- Resolve-DnsName über Standardkonfiguration liefert NXDOMAIN
- direkte Abfrage an 192.0.2.10 liefert 192.0.2.40
- interne DNS-Server sind durch den Tunnel erreichbar
- VPN-Profil besitzt keine DNS-Serverzuweisung
- Änderung des VPN-Profils zum Fehlerzeitpunkt festgestellt

Ursache:
Bei einer Änderung des VPN-Profils wurden die internen DNS-Server
und die interne Suchdomäne nicht übernommen.

Maßnahme:
Interne DNS-Server und Suchdomäne nach Freigabe wieder in das
VPN-Profil aufgenommen.

Nachprüfung:
- vollständiger interner Name wird korrekt aufgelöst
- Kurzname funktioniert über die vorgesehene Suchdomäne
- Dateidienst ist über den Namen erreichbar
- externe Namensauflösung funktioniert
- erneuter VPN-Verbindungsaufbau erfolgreich
- zweiter DNS-Server geprüft
- mehrere VPN-Clients erfolgreich getestet

Prävention:
- DNS-Funktion in den VPN-Abnahmetest aufnehmen
- interne und externe Testnamen überwachen
- Änderungen an VPN-Profilen durch Peer-Review prüfen

33. Checkliste „Name geht nicht, IP geht“

34. Schnellreferenz

Fehlerbild	wahrscheinlicher Untersuchungsbereich
IP funktioniert, vollständiger Name nicht	DNS-Server, Zone, Record oder DNS-Transport
vollständiger Name funktioniert, Kurzname nicht	DNS-Suffix oder Suchliste
interne Namen funktionieren, externe nicht	Forwarder, Rekursion, Root Hints oder Firewall
externe Namen funktionieren, interne nicht	falscher DNS-Server, interne Zone oder Split-DNS
nur ein Client betroffen	Clientkonfiguration, Cache, Hosts-Datei oder Anwendung
alle Clients betroffen	zentraler DNS-Dienst, Zone, Netzwerkpfad oder Firewall
nur VPN-Clients betroffen	VPN-DNS, Suchdomäne, Route oder Split-DNS
ein DNS-Server liefert falsche Daten	Zone, Replikation oder veralteter Record
`NXDOMAIN`	Name aus Sicht des antwortenden Servers nicht vorhanden
`SERVFAIL`	Serververarbeitung, Delegation, Forwarder oder DNSSEC
Zeitüberschreitung	Erreichbarkeit, Port 53, Überlastung oder Rückweg
richtige IP wird geliefert, Dienst scheitert	kein reiner DNS-Fehler; Port, Firewall, Anwendung oder Zielsystem
A funktioniert, AAAA führt zum Fehler	IPv6-Record oder IPv6-Datenpfad
Kommandozeile funktioniert, Browser nicht	Browsercache, Proxy oder verschlüsseltes DNS
wechselnde Antworten	mehrere DNS-Server, Round-Robin, Split-DNS oder Replikation
Reverse Lookup scheitert	PTR-Record oder Reverse-Lookup-Zone

Merksatz

Wenn die IP-Adresse funktioniert, der Name aber nicht, wird die Namensauflösung gezielt und schichtweise geprüft: verwendeter DNS-Server, vollständiger Name, Antwortcode, Record, Zone, Weiterleitung und tatsächlicher Resolver. Eine erreichbare IP-Adresse grenzt den Fehler ein, beweist aber weder einen DNS-Server-Ausfall noch die Funktionsfähigkeit des angesprochenen Dienstes.

Quellen und weiterführende Dokumentation

6.4 Host erreichbar, Dienst nicht – Ports, Firewall und Anwendungen systematisch prüfen

Ein Zielsystem kann per IP-Adresse erreichbar sein, während der benötigte Dienst trotzdem nicht funktioniert.

Typische Beispiele:

Ping auf den Server funktioniert, die Website öffnet sich jedoch nicht.
Der Servername wird korrekt aufgelöst, eine SSH-Verbindung scheitert aber.
Eine Dateifreigabe ist nicht erreichbar, obwohl der Server antwortet.
Die Anwendung meldet eine Zeitüberschreitung.
Ein TCP-Port ist erreichbar, die Anwendung liefert dennoch einen Fehler.
Der Dienst funktioniert lokal auf dem Server, aber nicht von anderen Geräten.
Einige Clients erreichen den Dienst, andere nicht.
Eine Verbindung funktioniert intern, über VPN oder Internet jedoch nicht.

Die Erreichbarkeit eines Hosts und die Erreichbarkeit eines Dienstes sind getrennte Prüfungen.

Host erreichbar
      ↓
Zielport erreichbar
      ↓
TCP- oder UDP-Kommunikation funktioniert
      ↓
Dienst nimmt Anfragen an
      ↓
Anwendungsprotokoll funktioniert
      ↓
Authentifizierung und Berechtigung funktionieren

Ein erfolgreicher Ping bestätigt deshalb weder einen offenen Port noch einen funktionsfähigen Dienst.

1. Fehlerbild exakt erfassen

Vor der technischen Prüfung müssen die betroffene Verbindung und der erwartete Dienst eindeutig bestimmt werden.

Zu dokumentieren sind:

Quellgerät,
Quell-IP-Adresse,
Zielname,
Ziel-IP-Adresse,
Zielport,
Transportprotokoll TCP oder UDP,
verwendete Anwendung,
Zeitpunkt des Fehlers,
genaue Fehlermeldung,
betroffene Benutzer oder Standorte,
funktionierende Vergleichsverbindungen,
letzte bekannte Funktionsfähigkeit,
kürzlich vorgenommene Änderungen.

Beispiel:

Quelle: Client-17, 192.0.2.117
Ziel: appserver.example.test, 192.0.2.50
Dienst: HTTPS
Transport: TCP
Zielport: 443
Fehler: Verbindung nach etwa 20 Sekunden abgebrochen
Betroffen: Clients im VLAN 30
Nicht betroffen: Clients im VLAN 20

Die Aussage „Der Server geht nicht“ reicht nicht aus. Benötigt wird eine genaue Beschreibung der betroffenen Kommunikationsbeziehung.

2. Host-Erreichbarkeit und Dienst-Erreichbarkeit unterscheiden

Ein Ping verwendet ICMP. Anwendungsdienste verwenden dagegen meistens TCP oder UDP.

Beispiel:

ping appserver.example.test

Ein erfolgreicher Ping kann bestätigen:

Namensauflösung liefert eine Adresse,
ICMP-Anfrage erreicht das Ziel,
ICMP-Antwort gelangt zurück.

Er beweist nicht:

dass TCP Port 443 geöffnet ist,
dass eine Firewall den Anwendungsverkehr erlaubt,
dass der Webserver läuft,
dass TLS funktioniert,
dass die Anwendung eine gültige Antwort liefert,
dass der Benutzer zugriffsberechtigt ist.

Umgekehrt kann ein Dienst funktionieren, obwohl Ping scheitert. ICMP kann gezielt blockiert sein, während der benötigte TCP- oder UDP-Port erlaubt bleibt.

3. Den tatsächlich benötigten Port bestimmen

Vor einem Porttest muss bekannt sein, welchen Zielport und welches Transportprotokoll die Anwendung verwendet.

Beispiele:

Dienst	Transport	typischer Port
HTTP	TCP	80
HTTPS	TCP	443
SSH	TCP	22
RDP	TCP und UDP	3389
SMB	TCP	445
DNS	UDP und TCP	53
SMTP	TCP	25
IMAP mit TLS	TCP	993
PostgreSQL	TCP	5432
MySQL	TCP	3306
LDAP	TCP und teilweise UDP	389
LDAPS	TCP	636
NTP	UDP	123
DHCP	UDP	67 und 68

Diese Ports sind typische Standardwerte. Anwendungen können abweichend konfiguriert sein.

Zu prüfen sind daher:

Herstellerdokumentation,
Serverkonfiguration,
Reverse-Proxy-Konfiguration,
Container-Portzuordnung,
Load-Balancer-Konfiguration,
Firewallregeln,
tatsächlich geöffnete Sockets,
eventuell verwendete dynamische Ports.

Ein Test des falschen Ports liefert keine verwertbare Aussage über den benötigten Dienst.

4. Zieladresse und Zielport gemeinsam prüfen

Ein Port gehört immer zu einer konkreten IP-Adresse und einem Transportprotokoll.

192.0.2.50:443/TCP

Bei mehreren IP-Adressen muss geprüft werden, welche Adresse die Anwendung tatsächlich verwendet.

Mögliche Fehler:

DNS liefert eine alte Adresse,
IPv6 wird gegenüber IPv4 bevorzugt,
der Dienst lauscht nur auf einer bestimmten Schnittstelle,
ein Load Balancer verwendet eine andere Adresse,
NAT leitet auf ein falsches Ziel weiter,
ein Client verwendet einen Proxy,
die Anwendung greift auf einen anderen Hostnamen zurück.

Vor der Bewertung eines Porttests sollten deshalb Zielname und aufgelöste Adressen dokumentiert werden.

Windows

Resolve-DnsName <zielname>

Linux und macOS

dig <zielname>

5. TCP-Port vom Client aus testen

Windows

Test-NetConnection <zielname> -Port <port>

Kurzform:

tnc <zielname> -Port <port>

Beispiel:

Test-NetConnection appserver.example.test -Port 443

Wichtig ist insbesondere:

TcpTestSucceeded : True

oder:

TcpTestSucceeded : False

PowerShell 7

Test-Connection <zielname> -TcpPort <port>

Linux und macOS

nc -vz <zielname> <port>

Beispiel:

nc -vz appserver.example.test 443

Alternativ kann bei bestimmten Diensten ein protokollspezifischer Test sinnvoller sein:

curl -v http://<zielname>:<port>/
curl -vk https://<zielname>:<port>/

Ein erfolgreicher TCP-Porttest bestätigt zunächst nur, dass eine TCP-Verbindung aufgebaut werden konnte. Er beweist nicht, dass die Anwendung fachlich korrekt arbeitet.

6. TCP-Ergebnisse richtig einordnen

Beobachtung	technische Bedeutung	möglicher Untersuchungsbereich
Verbindung erfolgreich	TCP-Verbindungsaufbau abgeschlossen	Anwendung, Protokoll, TLS, Authentifizierung oder Inhalt prüfen
sofort abgelehnt	Ziel oder Zwischenkomponente sendet aktiv eine Ablehnung	kein Listener, falscher Port, Firewall mit Reject oder Dienst beendet
Zeitüberschreitung	keine verwertbare Antwort innerhalb der Wartezeit	Firewall-Drop, Routing, Rückweg, NAT, Zielsystem oder Paketverlust
Verbindung wird sofort zurückgesetzt	TCP-RST beendet die Verbindung	Dienst, Proxy, Firewall, Protokollfehler oder Anwendung
Verbindung beginnt und bleibt hängen	TCP besteht, Anwendung antwortet nicht vollständig	Dienst, Backend, Überlastung, TLS, MTU oder Abhängigkeit
Verbindung funktioniert nur per IP	Namensauflösung, Zertifikat, virtueller Host oder Proxy
Verbindung funktioniert nur per Name	Anwendung benötigt Hostnamen, SNI oder virtuellen Host
Port ist offen, Anwendung meldet Fehler	kein reiner Portfehler	Protokoll, Anwendung, Backend, Authentifizierung oder Berechtigung

Eine Zeitüberschreitung beweist nicht automatisch, dass eine Firewall die Verbindung blockiert. Auch ein fehlender Rückweg, ein falsches NAT-Ziel oder ein nicht reagierendes System kann dasselbe Verhalten verursachen.

7. TCP-Verbindungsaufbau verstehen

Der normale TCP-Verbindungsaufbau verwendet drei Schritte:

Client → Server: SYN
Server → Client: SYN, ACK
Client → Server: ACK

Danach kann die Anwendungsübertragung beginnen.

Mögliche Abweichungen:

Paketfolge	mögliche Einordnung
SYN, SYN/ACK, ACK	TCP-Verbindung wurde aufgebaut
wiederholte SYN-Pakete ohne Antwort	Paketverlust, Firewall-Drop, Routing, Ziel oder Rückweg
SYN, danach RST/ACK	Port geschlossen oder Verbindung aktiv abgelehnt
SYN, SYN/ACK, danach kein ACK	Rückweg zum Client, Client-Firewall oder asymmetrischer Pfad
vollständiger Handshake, danach RST	Anwendung, Proxy oder Protokoll beendet die Verbindung
vollständiger Handshake, keine Nutzdatenantwort	Dienst hängt, Backend wartet oder Anwendungsproblem
wiederholte Übertragungen	Paketverlust, Überlastung, MTU oder instabiler Datenpfad

Diese Unterscheidung ist mit einer Paketaufzeichnung möglich.

8. UDP-Dienste getrennt betrachten

UDP besitzt keinen TCP-Handshake. Deshalb lässt sich ein UDP-Port nicht genauso zuverlässig wie ein TCP-Port mit einem einfachen Verbindungsversuch bewerten.

Beispiel:

nc -vzu <zielname> <port>

Ein solcher Test kann Pakete senden. Eine Erfolgsmeldung beweist jedoch nicht zwingend, dass:

der UDP-Dienst läuft,
das Paket den Server erreicht,
der Dienst die Anfrage verarbeitet,
eine Antwort zurückkommt,
die Anwendung das richtige Protokoll gesendet hat.

Für UDP sollte möglichst ein protokollspezifisches Werkzeug verwendet werden.

Beispiele:

DNS

dig @<dns-server> <name>

NTP

ntpdate -q <ntp-server>

Je nach System können andere Werkzeuge erforderlich sein.

Mögliche UDP-Ergebnisse:

Beobachtung	mögliche Einordnung
gültige Anwendungsantwort	Hin- und Rückweg sowie Dienst grundsätzlich funktionsfähig
ICMP Port Unreachable	am Zielport lauscht wahrscheinlich kein UDP-Dienst
keine Antwort	Dienst antwortet nicht, Firewall, Paketverlust, falsche Anfrage oder Protokollverhalten
Antwort nur bei kleinen Anfragen	Fragmentierung, MTU, EDNS oder Filter
lokal funktioniert, entfernt nicht	Bind-Adresse, Firewall, Routing oder Zugriffsliste

Keine UDP-Antwort ist deshalb weniger eindeutig als eine erfolgreiche oder abgelehnte TCP-Verbindung.

9. Auf dem Server prüfen, ob der Dienst lauscht

Ein Dienst muss einen Socket auf der vorgesehenen Adresse und dem vorgesehenen Port geöffnet haben.

Windows

Get-NetTCPConnection -State Listen
Get-NetTCPConnection -LocalPort <port>
Get-NetUDPEndpoint -LocalPort <port>

Alternativ:

netstat -ano
netstat -ano | findstr :<port>

Die zugehörige Prozess-ID kann geprüft werden mit:

Get-Process -Id <prozess-id>

oder:

tasklist /FI "PID eq <prozess-id>"

Linux

ss -lntp
ss -lntp 'sport = :<port>'
ss -lnup

Alternativ:

sudo lsof -nP -iTCP:<port> -sTCP:LISTEN
sudo lsof -nP -iUDP:<port>

macOS

sudo lsof -nP -iTCP:<port> -sTCP:LISTEN
sudo lsof -nP -iUDP:<port>

Zu prüfen sind:

ist ein Listener vorhanden?
ist es der erwartete Prozess?
verwendet er TCP oder UDP?
lauscht er auf dem erwarteten Port?
lauscht er auf der richtigen IP-Adresse?
verwendet er IPv4, IPv6 oder beides?
läuft möglicherweise ein anderer Prozess auf dem Port?
wurde die Konfiguration nach einer Änderung neu geladen?

10. Bind-Adresse richtig bewerten

Ein Dienst kann auf unterschiedlichen Adressen lauschen.

Beispiele:

127.0.0.1:8080
0.0.0.0:8080
192.0.2.50:8080
[::1]:8080
[::]:8080

Typische Bedeutung:

Bind-Adresse	Bedeutung
`127.0.0.1`	nur lokales IPv4-Loopback
`0.0.0.0`	grundsätzlich alle IPv4-Schnittstellen
konkrete IPv4-Adresse	nur diese IPv4-Adresse
`::1`	nur lokales IPv6-Loopback
`::`	grundsätzlich IPv6 und abhängig vom System eventuell zusätzlich IPv4

Ein Dienst, der ausschließlich auf 127.0.0.1 lauscht, kann lokal funktionieren und von entfernten Clients trotzdem nicht erreichbar sein.

Nach Änderungen an Netzwerkschnittstellen oder IP-Adressen kann ein Dienst weiterhin an eine nicht mehr vorhandene oder falsche Adresse gebunden sein.

11. Dienststatus und Protokolle prüfen

Ein vorhandener Prozess bedeutet nicht automatisch, dass der Dienst betriebsbereit ist.

Windows

Get-Service
Get-Service -Name <dienstname>

Linux mit systemd

systemctl status <dienstname>
journalctl -u <dienstname>

macOS

Je nach Installationsart können launchctl, anwendungseigene Werkzeuge oder Protokolldateien verwendet werden.

Zu prüfen sind:

Dienststatus,
Startzeitpunkt,
wiederholte Neustarts,
Konfigurationsfehler,
fehlende Zertifikate,
belegter Port,
fehlende Berechtigungen,
nicht erreichbare Datenbank,
nicht erreichbarer Verzeichnisdienst,
Speicher- oder Datenträgerprobleme,
abgelaufene Lizenzen,
erschöpfte Verbindungen,
interne Warteschlangen,
Fehler unmittelbar zum Störungszeitpunkt.

Ein Dienst kann als „running“ angezeigt werden und dennoch keine funktionsfähigen Anfragen bearbeiten.

12. Dienst lokal auf dem Server testen

Der lokale Test trennt die Anwendung vom entfernten Netzwerkpfad.

Beispiele:

curl -v http://127.0.0.1:<port>/
curl -vk https://127.0.0.1:<port>/

Oder:

nc -vz 127.0.0.1 <port>
nc -vz <server-ip> <port>

Sinnvolle Vergleichstests:

Verbindung über localhost,
Verbindung über Loopback-Adresse,
Verbindung über die Server-IP,
Verbindung über den vollständigen Namen,
Verbindung von einem Client im selben Netz,
Verbindung aus dem betroffenen Netz.

Ergebnis	mögliche Einordnung
lokal und entfernt scheitern	Dienst, Listener oder lokale Konfiguration
Loopback funktioniert, Server-IP lokal nicht	Bind-Adresse oder lokale Firewall
lokal funktioniert, entfernt nicht	Firewall, Routing, ACL, NAT oder Netzwerkpfad
IP funktioniert, Name nicht	DNS, virtueller Host, SNI oder Zertifikat
Porttest funktioniert, Protokolltest nicht	Anwendung oder Protokoll
ein Netz funktioniert, anderes nicht	Firewallregel, Routing, Segmentierung oder Rückweg

13. Lokale Firewall des Servers prüfen

Auch wenn der Dienst lauscht, kann die lokale Firewall eingehende Verbindungen blockieren.

Zu prüfen sind:

richtige Richtung der Regel,
richtiges Transportprotokoll,
richtiger lokaler Port,
richtige Quellnetze,
richtiges Netzwerkprofil,
richtige Anwendung oder Dienstzuordnung,
IPv4 und IPv6,
aktive Firewallzone,
Priorität und Reihenfolge der Regeln,
protokollierte Ablehnungen,
zentrale Richtlinien.

Windows

Get-NetFirewallProfile
Get-NetFirewallRule -Enabled True
Get-NetFirewallPortFilter
Get-NetFirewallAddressFilter

Eine genauere Zuordnung kann über gemeinsame Filter- und Regelobjekte erforderlich sein.

Linux mit firewalld

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all

Linux mit nftables

sudo nft list ruleset

Linux mit iptables

sudo iptables -L -n -v
sudo ip6tables -L -n -v

Firewallregeln sollten nicht pauschal deaktiviert werden. Eine kontrollierte, auf Quelle, Ziel, Port und Protokoll begrenzte Prüfung ist vorzuziehen.

14. Client-Firewall und Ausgangsregeln

Nicht nur der Server kann Verbindungen blockieren. Auch auf dem Client können ausgehende Regeln, Sicherheitssoftware oder Endpoint-Richtlinien wirken.

Mögliche Ursachen:

ausgehender Zielport gesperrt,
Anwendung darf keine Verbindung herstellen,
Netzwerkprofil wurde geändert,
Sicherheitssoftware blockiert den Prozess,
TLS-Inspection greift ein,
lokale Proxyrichtlinie erzwingt einen anderen Pfad,
Host-Firewall verwirft Rückpakete,
EDR-System beendet die Verbindung.

Wenn andere Anwendungen denselben Zielport erreichen, die betroffene Anwendung aber nicht, sollte zusätzlich eine prozessbezogene Einschränkung untersucht werden.

15. Netzwerk-Firewalls und ACLs

Zwischen Client und Server können mehrere Kontrollstellen liegen:

Client
  ↓
Client-Firewall
  ↓
VLAN- oder Router-ACL
  ↓
zentrale Firewall
  ↓
VPN-Gateway oder NAT
  ↓
Server-Firewall
  ↓
Dienst

Zu prüfen sind:

Quell-IP-Adresse,
Ziel-IP-Adresse,
Zielport,
Transportprotokoll,
Sicherheitszone,
Regelreihenfolge,
Zeitplan der Regel,
Benutzer- oder Anwendungsabhängigkeit,
NAT vor oder nach der Regelprüfung,
Sitzungsstatus,
Trefferzähler,
Protokolleinträge,
Rückweg.

Eine Regel für TCP Port 443 erlaubt nicht automatisch UDP Port 443. Ebenso erlaubt eine Regel für IPv4 nicht zwingend IPv6-Verkehr.

16. Stateful Firewall und Rückverkehr

Stateful Firewalls verfolgen den Zustand einer Verbindung. Bei einer erlaubten ausgehenden TCP-Verbindung wird der passende Rückverkehr normalerweise über den Verbindungszustand zugeordnet.

Fehler können entstehen durch:

asymmetrisches Routing,
Rückpakete passieren eine andere Firewall,
Firewallzustand ist abgelaufen,
NAT-Zuordnung fehlt,
Clusterknoten teilen Zustände nicht korrekt,
Quelladresse wird unerwartet geändert,
Verbindung bleibt länger inaktiv als der Session-Timeout,
Rückverkehr entspricht nicht der gespeicherten Sitzung.

Typisches Symptom:

Client sendet SYN.
Server antwortet mit SYN/ACK.
Client erhält die Antwort nicht.

In diesem Fall ist der Dienst erreichbar, aber der Rückweg oder eine zustandsabhängige Verarbeitung ist gestört.

17. Routing und Rückweg prüfen

Ein erreichbarer Host über ICMP bedeutet nicht, dass jeder Anwendungsverkehr denselben Pfad nimmt oder gleich behandelt wird.

Windows

tracert <ziel>
Test-NetConnection <ziel> -TraceRoute
Get-NetRoute

Linux

traceroute <ziel>
tracepath <ziel>
ip route
ip route get <ziel>

macOS

traceroute <ziel>
netstat -rn
route -n get <ziel>

Zu prüfen sind:

Route vom Client zum Server,
Rückroute vom Server zum Client,
Quell-IP-Auswahl,
mehrere Standardgateways,
Policy-Based Routing,
VPN-Routen,
überlappende Netze,
asymmetrische Wege,
segmentabhängige Firewallregeln.

Die Rückroute muss vom Server oder seinem Gateway zum tatsächlichen Quellnetz führen.

18. NAT und Portweiterleitung

Bei Verbindungen über Netzgrenzen kann NAT die Ziel- oder Quelladresse verändern.

Beispiel:

öffentliche Adresse:
198.51.100.20:443

NAT-Ziel:
192.0.2.50:8443

Zu prüfen sind:

richtige öffentliche Zieladresse,
richtiger externer Port,
richtiges internes Ziel,
richtiger interner Port,
TCP oder UDP,
Quell-NAT,
Rückroute,
Firewallregel passend zur NAT-Verarbeitung,
konkurrierende Portweiterleitung,
Hairpin-NAT bei Zugriff von intern,
Ablauf der NAT-Sitzung.

Ein lokal erreichbarer Dienst beweist nicht, dass die Portweiterleitung korrekt ist.

19. Container und virtuelle Maschinen

Bei containerisierten oder virtualisierten Diensten existieren zusätzliche Netzwerkschichten.

Mögliche Fehler:

Container läuft, Port wurde aber nicht veröffentlicht,
Host-Port zeigt auf den falschen Container-Port,
Dienst lauscht im Container nur auf Loopback,
Container-Netzwerk fehlt,
Firewall auf dem Host blockiert,
Reverse Proxy erreicht den Container nicht,
falscher DNS-Name im internen Netzwerk,
virtuelle Maschine besitzt eine andere IP-Adresse,
Sicherheitsgruppe erlaubt den Port nicht,
Dienst wurde auf einen anderen Host verschoben.

Docker

docker ps
docker port <container>
docker inspect <container>

Beispiel einer Portzuordnung:

0.0.0.0:8443 → Container:443/TCP

Ein Test auf Host-Port 443 wäre in diesem Beispiel ungeeignet, wenn der Dienst ausschließlich über Host-Port 8443 veröffentlicht wurde.

20. Reverse Proxy und Load Balancer

Zwischen Client und Anwendung können Reverse Proxy oder Load Balancer liegen.

Client
  ↓
Reverse Proxy oder Load Balancer
  ↓
Backend-Anwendung

Mögliche Fehlerbilder:

Frontend-Port ist erreichbar, Backend jedoch nicht,
falscher Hostname wird weitergeleitet,
Health Check schlägt fehl,
Backend-Port wurde geändert,
Zertifikat passt nicht,
virtuelle Hostkonfiguration fehlt,
Proxy-Zeitüberschreitung ist zu kurz,
ein einzelner Backend-Server ist fehlerhaft,
Sitzungspersistenz führt zu einem defekten Knoten,
Proxy liefert 502, 503 oder 504.

Typische HTTP-Ergebnisse:

Ergebnis	mögliche Einordnung
`200`	Anfrage grundsätzlich erfolgreich
`301` oder `302`	Weiterleitung prüfen
`400`	Anfrage oder Hostheader ungeeignet
`401`	Authentifizierung erforderlich oder fehlgeschlagen
`403`	Zugriff durch Anwendung oder Richtlinie verweigert
`404`	Pfad, virtueller Host oder Routingregel
`502`	Proxy erhält keine gültige Backend-Antwort
`503`	Dienst oder Backend nicht verfügbar
`504`	Zeitüberschreitung zum Backend

Ein erreichbarer Proxy-Port beweist nicht, dass das Backend funktioniert.

21. TLS und Zertifikate prüfen

Bei verschlüsselten Diensten folgt nach dem TCP-Verbindungsaufbau der TLS-Handshake.

Mögliche Fehler:

Zertifikat abgelaufen,
Zertifikatsname passt nicht zum Hostnamen,
Zertifikatskette unvollständig,
unbekannte Zertifizierungsstelle,
Client- und Serverprotokolle nicht kompatibel,
keine gemeinsame Cipher Suite,
Server Name Indication fehlt oder ist falsch,
Clientzertifikat erforderlich,
TLS-Inspection verändert die Verbindung,
Systemzeit ist falsch.

curl

curl -vk https://<zielname>:<port>/

OpenSSL

openssl s_client -connect <zielname>:<port> -servername <zielname>

Dabei können geprüft werden:

ausgehandeltes TLS-Protokoll,
präsentierte Zertifikatskette,
Zertifikatsname,
Gültigkeitszeitraum,
Serverantwort,
Abbruchstelle.

Die Option -k bei curl überspringt die Zertifikatsprüfung und darf nur zur Eingrenzung verwendet werden. Sie ist keine dauerhafte Lösung für Zertifikatsfehler.

22. Hostname, SNI und virtuelle Hosts

Mehrere Webanwendungen können dieselbe IP-Adresse und denselben Port verwenden. Der richtige Dienst wird dann anhand des Hostnamens ausgewählt.

Beispiel:

portal.example.test → 192.0.2.50
wiki.example.test   → 192.0.2.50

Ein Test ausschließlich gegen die IP-Adresse kann deshalb:

die falsche Website liefern,
einen Zertifikatsfehler erzeugen,
die Standardseite des Proxys anzeigen,
mit einem HTTP-Fehler enden,
den falschen virtuellen Host verwenden.

Geeigneter Test:

curl -vk https://portal.example.test/

Soll eine bestimmte IP-Adresse mit dem korrekten Hostnamen getestet werden:

curl -vk --resolve portal.example.test:443:192.0.2.50 https://portal.example.test/

Damit werden DNS, Ziel-IP, Hostheader und SNI kontrolliert voneinander getrennt.

23. Anwendung und Abhängigkeiten prüfen

Ein Dienst kann den Port öffnen, aber intern von weiteren Komponenten abhängig sein.

Beispiele:

Datenbank,
Verzeichnisdienst,
DNS,
Dateispeicher,
Nachrichtenwarteschlange,
API,
Lizenzserver,
externer Identitätsanbieter,
Zertifikatsdienst,
weiterer Microservice.

Mögliche Symptome:

TCP-Verbindung wird aufgebaut,
Loginseite erscheint,
Anmeldung scheitert,
Anfrage endet mit 500,
Antwort dauert sehr lange,
nur bestimmte Funktionen sind betroffen,
Health Check meldet Fehler,
Dienst startet, wird aber nicht „ready“.

Die Prüfung muss deshalb vom Frontend bis zu den tatsächlich benötigten Abhängigkeiten fortgesetzt werden.

24. Authentifizierung und Berechtigung abgrenzen

Eine erfolgreiche Netzwerkverbindung beweist nicht, dass der Benutzer oder Client den Dienst verwenden darf.

Zu unterscheiden sind:

Zielport nicht erreichbar,
TLS-Verbindung fehlerhaft,
Benutzer nicht authentifiziert,
falsche Anmeldedaten,
Konto gesperrt,
fehlende Gruppenmitgliedschaft,
Zugriff durch Anwendung verweigert,
Zugriff durch Netzwerkregel verweigert,
Kerberos- oder Zertifikatsfehler,
Mandanten- oder Rollenproblem.

Beispiele:

Connection timed out

weist eher auf Transport oder fehlende Antwort hin.

401 Unauthorized

zeigt dagegen, dass eine HTTP-Antwort des Dienstes empfangen wurde und die Untersuchung auf Anwendungsebene fortgesetzt werden muss.

25. IPv4 und IPv6 getrennt prüfen

Ein Dienst kann für IPv4 und IPv6 unterschiedlich erreichbar sein.

Windows

Resolve-DnsName <zielname> -Type A
Resolve-DnsName <zielname> -Type AAAA
Test-NetConnection <ipv4-adresse> -Port <port>
Test-NetConnection <ipv6-adresse> -Port <port>

Linux und macOS

curl -4 -v https://<zielname>/
curl -6 -v https://<zielname>/
nc -4 -vz <zielname> <port>
nc -6 -vz <zielname> <port>

Mögliche Ursachen:

Dienst lauscht nur auf IPv4,
Dienst lauscht nur auf IPv6,
AAAA-Record zeigt auf eine falsche Adresse,
IPv6-Firewallregel fehlt,
IPv6-Rückroute fehlt,
Client bevorzugt einen nicht funktionsfähigen IPv6-Pfad.

IPv6 sollte nicht pauschal deaktiviert werden. Zuerst ist nachzuweisen, welche Adressfamilie den Fehler verursacht.

26. MTU, Fragmentierung und große Datenmengen

Ein TCP-Handshake kann funktionieren, während größere Datenübertragungen scheitern.

Mögliche Symptome:

Porttest erfolgreich,
kleine Anfragen funktionieren,
TLS-Handshake bleibt hängen,
Dateiübertragung bricht ab,
bestimmte Webseiten laden nur teilweise,
Verbindung über VPN scheitert bei größeren Paketen,
wiederholte TCP-Übertragungen treten auf.

Mögliche Ursachen:

ungeeignete MTU,
blockierte ICMP-Meldungen für Path MTU Discovery,
Fragmentierung,
Tunnel-Overhead,
fehlerhafte MSS-Anpassung,
Paketverlust,
Sicherheitskomponente verwirft größere Pakete.

Linux

tracepath <ziel>

Windows

ping <ziel> -f -l <paketgröße>

Der verwendbare Wert hängt von Protokoll-Headern und Datenpfad ab. Ein einzelner Pingwert darf deshalb nicht ungeprüft als endgültige MTU übernommen werden.

27. Proxys und anwendungsspezifische Netzwerkwege

Eine Anwendung kann einen anderen Netzwerkpfad verwenden als ein einfacher Porttest.

Mögliche Unterschiede:

HTTP-Proxy,
SOCKS-Proxy,
automatische Proxykonfiguration,
VPN-Tunnel,
DNS over HTTPS,
anwendungseigener Resolver,
Service Mesh,
TLS-Inspection,
Cloud-Gateway,
Zero-Trust-Zugriff.

Zu prüfen sind:

verwendet die Anwendung einen Proxy?
umgeht das Testwerkzeug den Proxy?
wird der Zielname durch den Proxy aufgelöst?
ist der Proxy selbst erreichbar?
erlaubt der Proxy den Zielport?
existiert eine Ausnahmeliste?
wird die Verbindung durch Benutzer- oder Gerätestatus gesteuert?

Ein erfolgreicher direkter Test beweist nicht, dass der von der Anwendung verwendete Proxyweg funktioniert.

28. Sporadische und lastabhängige Fehler

Nicht jeder Dienstfehler besteht dauerhaft.

Mögliche Ursachen:

Verbindungsgrenze erreicht,
Quellports erschöpft,
überlasteter Server,
Load Balancer verteilt auf einen defekten Knoten,
Firewall-Sitzungstabelle ausgelastet,
Paketverlust,
Dienst startet wiederholt neu,
Datenbankverbindungen erschöpft,
Timeouts zwischen Proxy und Backend,
DNS liefert wechselnde Ziele,
automatische Skalierung reagiert zu langsam.

Windows

Get-NetTCPConnection
Get-Counter '\TCPv4\Connections Established'

Linux

ss -s
ss -ant

Wiederholte Tests sollten mit Zeitstempel durchgeführt werden.

PowerShell

1..10 | ForEach-Object {
    Get-Date
    Test-NetConnection <ziel> -Port <port>
    Start-Sleep -Seconds 2
}

Bash

for i in {1..10}; do
    date
    nc -vz <ziel> <port>
    sleep 2
done

Zu vergleichen sind:

Erfolg oder Fehler,
Antwortzeit,
Zieladresse,
betroffener Backend-Server,
Zeitpunkt,
gleichzeitige Last,
Firewall- und Anwendungsprotokolle.

29. Paketaufzeichnung einsetzen

Eine Paketaufzeichnung kann zeigen:

ob der Client ein SYN sendet,
ob das Ziel mit SYN/ACK oder RST antwortet,
ob Pakete erneut übertragen werden,
ob die Verbindung nach dem Handshake abbricht,
ob TLS beginnt,
ob eine Anwendungsantwort zurückkommt,
ob ICMP-Fehlermeldungen auftreten,
ob IPv4 oder IPv6 verwendet wird,
ob die tatsächliche Zieladresse stimmt,
ob Hin- und Rückweg vollständig sind.

Wireshark-Filter

ip.addr == <ziel-ip>
tcp.port == <port>
udp.port == <port>
tcp.flags.syn == 1
tcp.flags.reset == 1
tcp.analysis.retransmission
icmp
icmpv6
tls
http

Für eine einzelne TCP-Verbindung kann nach Auswahl eines Pakets zusätzlich der zugehörige TCP-Stream gefiltert werden.

Typische Beobachtungen

Paketaufzeichnung	mögliche Einordnung
kein Verbindungsversuch sichtbar	Anwendung, Proxy, Cache oder falsche Schnittstelle
SYN verlässt Client, keine Antwort	Firewall-Drop, Routing, Ziel oder Rückweg
SYN wird mit RST beantwortet	kein Listener oder aktive Ablehnung
SYN/ACK erreicht Client, Client antwortet nicht	Client-Firewall, lokaler Stack oder falscher Zustand
TCP-Handshake vollständig, danach TLS-Fehler	Zertifikat, SNI, Protokoll oder Cipher
TCP-Handshake vollständig, HTTP `401`	Authentifizierung
TCP-Handshake vollständig, HTTP `403`	Berechtigung oder Richtlinie
TCP-Handshake vollständig, HTTP `502`	Proxy- oder Backend-Problem
viele Wiederholungen	Paketverlust, Überlastung, MTU oder Datenpfad
Verbindung wird durch RST beendet	Anwendung, Firewall, Proxy oder Betriebssystem

Paketaufzeichnungen dürfen nur mit entsprechender Berechtigung erstellt und müssen geschützt gespeichert werden.

30. Vergleichstests systematisch verwenden

Vergleichstests helfen, die fehlerhafte Grenze einzugrenzen.

Sinnvolle Vergleiche:

Vergleich	mögliche Erkenntnis
betroffener und funktionierender Client	Clientkonfiguration oder Netzsegment
Zielname und Ziel-IP	DNS, SNI oder virtueller Host
IPv4 und IPv6	Adressfamilie oder Datenpfad
lokaler und entfernter Zugriff	Dienst oder Netzwerk
gleiches VLAN und anderes VLAN	Routing, ACL oder Firewall
internes Netz und VPN	VPN-Regel, Route oder DNS
Frontend und Backend direkt	Proxy oder Load Balancer
erster und zweiter Server	einzelnes Zielsystem oder zentraler Pfad
kleiner und großer Datentransfer	MTU, Paketverlust oder Überlastung
TCP-Porttest und Protokolltest	Transport oder Anwendung

Dabei sollte jeweils nur eine Variable verändert werden.

31. Praxisfall A: Ping funktioniert, HTTPS-Port nicht

Symptom

Server antwortet auf Ping,
Name wird korrekt aufgelöst,
TCP Port 443 läuft in eine Zeitüberschreitung,
andere Server im selben Netz sind erreichbar.

Prüfung

Zieladresse dokumentieren.
TCP Port 443 vom Client testen.
Listener auf dem Server prüfen.
lokalen HTTPS-Test auf dem Server durchführen.
Server-Firewall kontrollieren.
Netzwerk-Firewall und Trefferprotokolle prüfen.
Paketaufzeichnung auf Client und Server vergleichen.

Mögliche Ursache

Der Webserver läuft und lauscht auf Port 443. Nach einer Netzsegmentierung fehlt jedoch die Freigabe vom neuen Client-VLAN zum Server.

Nachprüfung

TCP Port 443 ist aus dem vorgesehenen VLAN erreichbar,
HTTPS liefert eine gültige Antwort,
nicht vorgesehene Quellnetze bleiben gesperrt,
Firewallregel ist dokumentiert,
ursprüngliche Anwendung funktioniert.

32. Praxisfall B: Dienst funktioniert lokal, aber nicht entfernt

Symptom

lokaler Aufruf über localhost funktioniert,
entfernter Porttest wird abgelehnt,
der Prozess läuft,
auf dem Server ist kein allgemeiner Listener sichtbar.

Prüfung

Listener und Bind-Adresse feststellen.
Loopback und Server-IP lokal vergleichen.
Dienstkonfiguration prüfen.
nach einer Änderung den Dienst kontrolliert neu laden.
lokale Firewall berücksichtigen.
entfernten Test wiederholen.

Mögliche Ursache

Der Dienst lauscht ausschließlich auf 127.0.0.1.

Nachprüfung

Dienst lauscht auf der vorgesehenen Serveradresse,
lokaler Zugriff funktioniert,
entfernter Zugriff aus erlaubten Netzen funktioniert,
Firewall begrenzt den Zugriff weiterhin,
keine unnötige öffentliche Freigabe wurde geschaffen.

33. Praxisfall C: Port 443 ist offen, Website liefert 502

Symptom

TCP Port 443 ist erreichbar,
TLS-Verbindung wird aufgebaut,
Reverse Proxy antwortet mit 502 Bad Gateway,
Backend-Anwendung ist nicht direkt erreichbar.

Prüfung

Proxy-Antwort dokumentieren.
Proxy-Protokolle prüfen.
Backend-Ziel und Backend-Port feststellen.
Verbindung vom Proxy zum Backend testen.
Listener der Backend-Anwendung prüfen.
Container- oder Dienststatus kontrollieren.
Namensauflösung innerhalb des Proxy-Netzes prüfen.

Mögliche Ursache

Nach einer Änderung verwendet die Backend-Anwendung einen neuen Port. Die Proxy-Konfiguration zeigt weiterhin auf den alten Port.

Nachprüfung

Proxy erreicht das richtige Backend,
Backend-Health-Check ist erfolgreich,
HTTPS-Aufruf liefert die erwartete Anwendung,
weitere virtuelle Hosts funktionieren,
Konfigurationsänderung ist dokumentiert.

34. Praxisfall D: Einige Clients erreichen den Dienst, andere nicht

Symptom

Clients im VLAN 20 können eine Anwendung öffnen,
Clients im VLAN 30 erhalten eine Zeitüberschreitung,
beide Gruppen lösen denselben Namen zur selben IP-Adresse auf,
der Dienst funktioniert lokal.

Prüfung

Quell-IP-Adressen beider Clients erfassen.
Route und Gateway vergleichen.
Porttest aus beiden Netzen durchführen.
Firewallregeln und Trefferzähler prüfen.
Server-Firewall auf Quellnetzbegrenzungen untersuchen.
Paketaufzeichnung am Server durchführen.

Mögliche Ursache

Die Server-Firewall erlaubt Port 8443 nur aus dem alten VLAN 20.

Nachprüfung

vorgesehene Clients aus VLAN 30 erreichen den Dienst,
VLAN 20 funktioniert weiterhin,
andere Netze bleiben gesperrt,
Quellnetze in der Regel sind korrekt dokumentiert.

35. Praxisfall E: TCP-Verbindung funktioniert, Anmeldung scheitert

Symptom

Zielname wird korrekt aufgelöst,
TCP-Port ist erreichbar,
TLS funktioniert,
Anwendung zeigt eine Anmeldeseite,
Benutzer erhält 401 Unauthorized.

Prüfung

erfolgreichen Transport dokumentieren.
Anwendungsprotokoll und Statuscode auswerten.
Benutzerkonto und Authentifizierungsquelle prüfen.
Uhrzeit, Zertifikate und gegebenenfalls Kerberos berücksichtigen.
funktionierendes Vergleichskonto verwenden.
Anwendungs- und Authentifizierungsprotokolle prüfen.

Mögliche Ursache

Der Benutzer ist nicht mehr Mitglied der für die Anwendung berechtigten Gruppe.

Nachprüfung

Benutzer kann sich nach genehmigter Berechtigungskorrektur anmelden,
TCP- und TLS-Verbindung bleiben unverändert,
Zugriff ist auf vorgesehene Benutzer begrenzt,
Ursache und Berechtigungsänderung sind dokumentiert.

36. Ungeeignete Sofortmaßnahmen

Problematisch sind insbesondere:

Firewall vollständig deaktivieren,
beliebige Ports pauschal freigeben,
einen Dienst ungeprüft neu starten,
Server neu starten, ohne den Zustand zu dokumentieren,
Anwendung als Ursache festlegen, nur weil Ping funktioniert,
Netzwerk als Ursache festlegen, obwohl der Dienst keinen Listener besitzt,
Zertifikatsprüfung dauerhaft deaktivieren,
IPv6 pauschal abschalten,
NAT-Regeln ohne Sicherung verändern,
mehrere Firewalls gleichzeitig ändern,
Sicherheitssoftware ungeprüft entfernen,
Container neu erstellen, ohne Volumes und Konfiguration zu prüfen,
produktive Paketaufzeichnungen ungeschützt speichern,
Testzugänge oder temporäre Freigaben dauerhaft bestehen lassen.

Vor Änderungen sollten dokumentiert werden:

Quell- und Zieladresse,
Zielport und Transportprotokoll,
DNS-Ergebnis,
Porttestergebnis,
Listener,
Dienststatus,
Firewallregeln,
NAT-Regeln,
Routen,
Protokolle,
Paketbeobachtungen,
Zeitpunkt und Umfang der Störung.

37. Vollständige Prüfreihenfolge

betroffene Anwendung und genaue Fehlermeldung erfassen.
Quelle, Zielname und Ziel-IP-Adresse dokumentieren.
benötigten Zielport bestimmen.
TCP oder UDP unterscheiden.
Namensauflösung prüfen.
Host-Erreichbarkeit nur als Teilprüfung verwenden.
Zielport vom betroffenen Client testen.
Ergebnis als Erfolg, Ablehnung, Reset oder Zeitüberschreitung einordnen.
funktionierenden Vergleichsclient prüfen.
IPv4 und IPv6 getrennt betrachten.
auf dem Server den Listener prüfen.
Prozess zum Listener bestimmen.
Bind-Adresse kontrollieren.
Dienststatus und Protokolle auswerten.
Dienst über Loopback lokal testen.
Dienst über die Server-IP lokal testen.
protokollspezifischen Test durchführen.
lokale Server-Firewall prüfen.
Client-Firewall und Sicherheitssoftware berücksichtigen.
Netzwerk-Firewalls und ACLs prüfen.
Route vom Client zum Server untersuchen.
Rückweg vom Server zum Client prüfen.
NAT und Portweiterleitungen berücksichtigen.
VPN- und Segmentierungsregeln prüfen.
Container-, VM- oder Host-Portzuordnungen prüfen.
Reverse Proxy oder Load Balancer untersuchen.
Backend-Verbindungen testen.
TLS, Zertifikat, SNI und Hostnamen prüfen.
Anwendung, Authentifizierung und Berechtigung abgrenzen.
bei sporadischen Fehlern wiederholte Tests durchführen.
bei Bedarf autorisierte Paketaufzeichnung erstellen.
konkrete Hypothese formulieren.
genau eine kontrollierbare Änderung durchführen.
Listener und Dienststatus erneut prüfen.
Porttest wiederholen.
protokollspezifischen Test wiederholen.
ursprüngliche Anwendung erneut testen.
funktionierende und nicht vorgesehene Netze kontrollieren.
temporäre Freigaben entfernen.
Ursache, Maßnahme und Ergebnis dokumentieren.
Monitoring oder Präventionsmaßnahme festlegen.

38. Dokumentationsbeispiel

Ticket: INC-20644
Beginn: 02.08.2026, etwa 14:20 Uhr
Umfang: Clients im VLAN 30
Betroffen: HTTPS-Anwendung auf appserver.example.test
Nicht betroffen: Clients im VLAN 20

Verbindung:
Quelle: 192.0.2.117
Ziel: appserver.example.test
Ziel-IP: 192.0.2.50
Transport: TCP
Zielport: 443

Symptom:
Der Server antwortet auf ICMP.
Die Namensauflösung liefert die korrekte IP-Adresse.
Der HTTPS-Aufruf läuft aus VLAN 30 in eine Zeitüberschreitung.

Ausgangszustand:
- DNS-Auflösung korrekt
- ICMP-Antwort vorhanden
- TCP Port 443 aus VLAN 30 nicht erreichbar
- TCP Port 443 aus VLAN 20 erreichbar
- Webserver lauscht auf 0.0.0.0:443
- lokaler HTTPS-Test auf dem Server erfolgreich
- Server-Firewall erlaubt beide internen Netze
- zentrale Firewall protokolliert verworfene SYN-Pakete aus VLAN 30

Hypothese:
Bei der Einrichtung des neuen VLANs wurde die Freigabe zu TCP Port 443
auf dem Anwendungsserver nicht ergänzt.

Prüfung:
- Quell-IP und Ziel-IP bestätigt
- Route zum Server vorhanden
- Listener und Dienststatus korrekt
- funktionierenden Client aus VLAN 20 verglichen
- Firewallregel enthält nur das Quellnetz von VLAN 20
- keine SYN-Pakete aus VLAN 30 erreichen den Server

Ursache:
Die zentrale Firewallregel erlaubte den HTTPS-Zugriff nur aus VLAN 20.

Maßnahme:
Das freigegebene Quellobjekt wurde nach Genehmigung um das vorgesehene
Clientnetz aus VLAN 30 ergänzt. Ziel und Port blieben unverändert.

Nachprüfung:
- TCP Port 443 aus VLAN 30 erreichbar
- TLS-Handshake erfolgreich
- Anwendung liefert HTTP 200
- Anmeldung funktioniert
- VLAN 20 funktioniert weiterhin
- Zugriff aus nicht freigegebenen Netzen bleibt blockiert
- Firewallprotokoll und Trefferzähler geprüft

Prävention:
- Firewallfreigaben in die VLAN-Abnahme aufnehmen
- automatisierten HTTPS-Health-Check aus beiden Clientnetzen einrichten
- Änderungen an Netzsegmenten mit einer Kommunikationsmatrix prüfen

39. Checkliste „Host erreichbar, Dienst nicht“

40. Schnellreferenz

Fehlerbild	wahrscheinlicher Untersuchungsbereich
Ping funktioniert, TCP-Port nicht	Listener, Firewall, Routing, NAT oder Rückweg
TCP-Verbindung wird sofort abgelehnt	kein Listener, falscher Port oder aktive Ablehnung
TCP-Verbindung läuft in Zeitüberschreitung	Firewall-Drop, Routing, NAT, Rückweg oder Ziel
Port funktioniert lokal, entfernt nicht	Bind-Adresse, Firewall, ACL oder Netzwerkpfad
Loopback funktioniert, Server-IP lokal nicht	Bind-Adresse oder lokale Firewall
Port ist offen, Anwendung antwortet nicht	Dienst, Protokoll, Backend oder Überlastung
TCP funktioniert, TLS scheitert	Zertifikat, SNI, Protokoll oder Cipher
HTTPS liefert `401`	Authentifizierung
HTTPS liefert `403`	Berechtigung oder Richtlinie
HTTPS liefert `502`	Proxy erreicht Backend nicht korrekt
HTTPS liefert `503`	Dienst oder Backend nicht verfügbar
HTTPS liefert `504`	Zeitüberschreitung zwischen Proxy und Backend
nur ein Client betroffen	Client-Firewall, Proxy, Route oder lokale Anwendung
nur ein Netz betroffen	ACL, Firewall, Routing oder Quellnetzregel
nur VPN-Clients betroffen	VPN-Route, VPN-Firewall, MTU oder DNS
intern erreichbar, extern nicht	NAT, Portweiterleitung, externe Firewall oder Provider
extern erreichbar, intern nicht	Hairpin-NAT, Split-DNS oder interne Firewall
IP funktioniert, Hostname nicht	DNS, SNI, virtueller Host oder Zertifikat
IPv4 funktioniert, IPv6 nicht	IPv6-Listener, Firewall, Route oder AAAA-Record
kleine Anfragen funktionieren, große nicht	MTU, Fragmentierung, Paketverlust oder Timeout
Verbindung scheitert sporadisch	Last, Porterschöpfung, defektes Backend oder Paketverlust
UDP-Test bleibt ohne Antwort	Dienst, Firewall, falsche Anfrage oder normales Protokollverhalten
SYN ohne Antwort	Drop, Routing, Ziel oder Rückweg
SYN gefolgt von RST	Port geschlossen oder aktive Ablehnung
Handshake vollständig, danach RST	Anwendung, Proxy, Firewall oder Protokoll
Handshake vollständig, keine Antwort	Dienst hängt, Backend wartet oder Überlastung

Merksatz

Ein erreichbarer Host ist nicht automatisch ein erreichbarer Dienst. Geprüft werden müssen die vollständige Kommunikationsbeziehung aus Quelle, Zieladresse, Transportprotokoll und Zielport sowie anschließend Listener, Firewall, Rückweg und Anwendung. Ein erfolgreicher Porttest beweist den TCP-Verbindungsaufbau, aber noch nicht die Funktionsfähigkeit des Anwendungsprotokolls.

Quellen und weiterführende Dokumentation

6.5 Netzwerk ist langsam – Latenz, Paketverlust und Durchsatz systematisch analysieren

Ein Netzwerk gilt nicht allein deshalb als langsam, weil eine Anwendung verzögert reagiert. Wahrgenommene Langsamkeit kann durch das Netzwerk selbst, den Client, den Server, den Datenträger, eine Anwendung, DNS, einen Proxy, ein VPN, WLAN, Paketverlust oder eine ausgelastete Zwischenkomponente entstehen.

Typische Aussagen wie:

Das Internet ist langsam.
Der Server reagiert träge.
Der Download dauert zu lange.
Die Verbindung hängt immer wieder.
Das WLAN ist schlecht.

sind zunächst nur Symptombeschreibungen. Für eine belastbare Fehleranalyse muss bestimmt werden:

was genau langsam ist,
zwischen welchen Endpunkten gemessen wird,
ob Latenz, Paketverlust, Jitter oder Durchsatz betroffen sind,
ob der Fehler dauerhaft oder sporadisch auftritt,
ob nur ein Client, ein Netzsegment oder alle Benutzer betroffen sind,
ob das Netzwerk oder eine darüberliegende Anwendung begrenzt.

1. Die wichtigsten Messgrößen unterscheiden

Messgröße	Bedeutung	Typische Auswirkung
Latenz	Zeit für die Übertragung zwischen zwei Endpunkten	verzögerte Reaktion, langsamer Sitzungsaufbau
Round-Trip Time	Zeit für Hin- und Rückweg	messbar beispielsweise mit Ping oder TCP-Tests
Paketverlust	Pakete erreichen das Ziel nicht	Wiederholungen, Einbrüche bei TCP, Audio- und Videostörungen
Jitter	Schwankung der Laufzeit	Probleme bei Sprache, Video und Echtzeitanwendungen
Durchsatz	tatsächlich übertragene Datenmenge pro Zeit	langsame Dateiübertragung oder Downloads
Bandbreite	theoretisch oder vertraglich verfügbare Kapazität	stellt nur die mögliche Obergrenze dar
Auslastung	aktuell genutzter Anteil einer Verbindung oder Ressource	Warteschlangen, Verzögerungen und Drops
Retransmission	erneute TCP-Übertragung verlorener oder nicht bestätigter Segmente	geringerer Durchsatz und zusätzliche Verzögerung
Queue	wartende Pakete oder Anfragen	steigende Latenz bei hoher Last
Fehlerrate	fehlerhafte Frames, Pakete oder Übertragungen	Paketverlust, Neuübertragungen und Verbindungsabbrüche

Ein Link mit 1 Gbit/s garantiert keinen Anwendungsdurchsatz von 1 Gbit/s. Protokoll-Overhead, Latenz, TCP-Verhalten, Datenträgerleistung, Verschlüsselung, Gegenstelle und weitere gleichzeitig übertragene Daten reduzieren den praktisch erreichbaren Wert.

2. Langsamkeit exakt beschreiben

Vor jeder technischen Änderung sind folgende Fragen zu beantworten:

Welche Anwendung oder Übertragung ist langsam?
Wie lange dauert der Vorgang normalerweise?
Wie lange dauert er während der Störung?
Seit wann besteht das Problem?
Funktionierte es zuvor nachweislich schneller?
Ist der Fehler dauerhaft, periodisch oder zufällig?
Sind Download, Upload oder beide Richtungen betroffen?
Sind kleine Anfragen oder erst große Übertragungen betroffen?
Tritt die Verzögerung vor dem Verbindungsaufbau oder während der Datenübertragung auf?
Ist nur ein Benutzer betroffen?
Sind mehrere Clients im selben VLAN, WLAN oder Standort betroffen?
Funktioniert ein Vergleichsclient normal?
Ist die Verbindung per Kabel und WLAN gleichermaßen langsam?
Sind interne Ziele, externe Ziele oder beide betroffen?
Ist nur ein bestimmter Server oder sind mehrere Ziele betroffen?
Wird ein VPN, Proxy, Load Balancer oder Sicherheitsgateway verwendet?
Gab es unmittelbar zuvor Änderungen, Updates oder Wartungsarbeiten?
Treten gleichzeitig CPU-, RAM-, Datenträger- oder Anwendungsprobleme auf?

Eine geeignete Ausgangsbeschreibung lautet beispielsweise:

Seit 02.08.2026 gegen 09:20 Uhr erreichen Clients im WLAN VLAN 30
beim Kopieren einer 2-GB-Testdatei zum internen Dateiserver nur noch
etwa 8 bis 15 Mbit/s. Über kabelgebundene Clients im VLAN 20 werden
zum selben Server etwa 700 Mbit/s erreicht. Kleine Webanfragen und
DNS-Auflösungen funktionieren. Betroffen sind mehrere WLAN-Clients.

Diese Beschreibung ist wesentlich aussagekräftiger als:

Das Netzwerk ist langsam.

3. Latenz, Durchsatz und Anwendungsdauer nicht gleichsetzen

Ein Dienst kann sich langsam anfühlen, obwohl der Netzwerkdurchsatz ausreichend ist.

Beispiele:

eine DNS-Abfrage läuft in einen Timeout,
ein TLS-Handshake benötigt mehrere Versuche,
der Server wartet auf eine Datenbank,
der Datenträger des Servers ist ausgelastet,
eine Anwendung führt viele aufeinanderfolgende Anfragen aus,
ein Proxy untersucht den Datenverkehr,
eine Datei wird serverseitig auf Schadsoftware geprüft,
eine Anwendung arbeitet nur mit einer einzelnen TCP-Verbindung,
ein Benutzerprofil oder eine Gruppenrichtlinie verarbeitet viele Dateien,
der Client besitzt eine hohe CPU- oder Datenträgerauslastung.

Umgekehrt kann eine Anwendung zunächst normal reagieren, während größere Übertragungen wegen Paketverlust, MTU-Problemen oder eines ausgelasteten Links einbrechen.

Deshalb sind mindestens zwei Prüfarten notwendig:

kontrollierte Netzwerkmessung,
Test der tatsächlich betroffenen Anwendung.

4. Umfang der Störung durch Vergleichstests eingrenzen

Vergleich	mögliche Erkenntnis
betroffener gegen funktionierenden Client	lokales Problem oder gemeinsamer Infrastrukturfehler
WLAN gegen Kabel	Funkstrecke, Access Point oder WLAN-Konfiguration
internes gegen externes Ziel	LAN, WAN, Provider oder Internetpfad
Ziel im selben VLAN gegen anderes VLAN	lokales Segment oder gerouteter Pfad
ein Server gegen mehrere Server	Zielsystem oder allgemeiner Netzwerkpfad
IP-Adresse gegen Hostname	DNS oder Namensauflösung
ohne VPN gegen mit VPN	Tunnel, MTU, Gateway oder VPN-Routing
ohne Proxy gegen vorgesehener Proxyweg	Proxy oder Sicherheitsprüfung
Download gegen Upload	richtungsabhängiger Engpass
einzelne gegen mehrere TCP-Verbindungen	TCP, Latenz, Lastverteilung oder Serverbegrenzung
kleine gegen große Übertragung	MTU, Paketverlust, Datenträger oder Durchsatz
aktuelle Messung gegen historische Baseline	tatsächliche Abweichung vom Normalzustand

Bei einem Vergleich sollte möglichst nur eine Variable verändert werden.

5. Lokale Clientressourcen ausschließen

Ein langsamer Client kann ein Netzwerkproblem vortäuschen.

Zu prüfen sind:

CPU-Auslastung,
Arbeitsspeicher und Paging,
Datenträgerauslastung und Datenträgerlatenz,
laufende Updates,
Backups und Synchronisationsprogramme,
Virenscanner oder EDR-Prüfungen,
Browser-Erweiterungen,
VPN-Client,
Proxysoftware,
Netzwerkfiltertreiber,
fehlerhafter Netzwerkkartentreiber,
Energiesparmodus,
thermische Begrenzung,
sehr viele parallele Verbindungen,
lokale Anwendung oder lokaler Cache.

Windows

Get-Process | Sort-Object CPU -Descending
Get-Counter '\Processor(_Total)\% Processor Time'
Get-Counter '\Memory\Available MBytes'
Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Transfer'
Get-NetAdapter
Get-NetAdapterStatistics

Linux

top
vmstat 1
free -h
iostat -xz 1
ip -s link

macOS

top
vm_stat
iostat -w 1
netstat -ib

Hohe CPU-, RAM- oder Datenträgerauslastung beweist noch nicht, dass sie die Netzwerkstörung verursacht. Entscheidend ist die zeitliche Übereinstimmung mit der langsamen Übertragung.

6. Verbindungstyp und ausgehandelten Link prüfen

Bei Ethernet sind insbesondere zu prüfen:

Interface aktiv,
ausgehandelte Geschwindigkeit,
Duplexmodus,
automatische Aushandlung,
Kabel und Steckverbindungen,
Switchport,
Dockingstation oder USB-Adapter,
Treiber und Firmware,
Fehlerzähler,
Port-Security,
VLAN-Zuweisung,
Energiesparfunktionen.

Ein Client, der statt mit 1 Gbit/s nur mit 100 Mbit/s verbunden ist, kann beispielsweise durch ein ungeeignetes oder beschädigtes Kabel, eine fehlerhafte Adernpaarverbindung, einen Adapter oder den Switchport begrenzt sein.

Windows

Get-NetAdapter |
    Select-Object Name, InterfaceDescription, Status, LinkSpeed, MacAddress

Weitere Eigenschaften:

Get-NetAdapterAdvancedProperty -Name "<adaptername>"
Get-NetAdapterStatistics -Name "<adaptername>"

Linux

ip link show
ip -s link show
sudo ethtool <interface>
sudo ethtool -S <interface>

macOS

ifconfig <interface>
networksetup -getMedia <netzwerkdienst>
netstat -ib

Auf der Switchseite sind je nach Hersteller insbesondere zu prüfen:

administrativer und operativer Portstatus,
Geschwindigkeit und Duplex,
CRC- oder FCS-Fehler,
Input Errors und Output Errors,
Drops und Discards,
Link-Flaps,
Pause Frames,
Queue Drops,
Portauslastung,
STP-Zustand,
LACP- oder Port-Channel-Zustand.

Geschwindigkeit, Duplex, Jumbo Frames und Offload-Einstellungen dürfen nicht wahllos verändert werden. Unterschiedliche Einstellungen an beiden Linkpartnern können neue Fehler verursachen.

7. Schnittstellenzähler richtig auswerten

Ein einzelner Zählerstand zeigt nicht, wann ein Fehler aufgetreten ist. Zähler müssen vor und während eines kontrollierten Tests verglichen werden.

Beispiel:

Zeitpunkt A:
CRC-Fehler: 12
Drops:      41

Zeitpunkt B nach Test:
CRC-Fehler: 438
Drops:      41

Die steigende Zahl der CRC-Fehler weist auf ein Problem der physischen Übertragung oder des Links hin. Mögliche Ursachen sind:

beschädigtes Kabel,
ungeeignete Verkabelung,
defekter Stecker,
fehlerhafter Switchport,
defekter Netzwerkadapter,
elektromagnetische Störung,
Transceiver- oder Glasfaserproblem.

Steigende Drops bei gleichbleibenden CRC-Werten sprechen eher für:

überfüllte Warteschlange,
zu hohe Auslastung,
Microbursts,
unzureichende Puffer,
QoS- oder Policing-Regel,
überlastete CPU einer Netzwerkkomponente.

Hersteller verwenden unterschiedliche Zählerbezeichnungen. Die genaue Bedeutung muss anhand der Dokumentation des eingesetzten Geräts geprüft werden.

8. Latenz zunächst kontrolliert messen

Windows

ping <ziel>
ping <ziel> -t
Test-Connection <ziel> -Count 20
Test-NetConnection <ziel>

Linux

ping -c 20 <ziel>

macOS

ping -c 20 <ziel>

Sinnvolle Ziele für getrennte Messungen:

eigenes Standardgateway,
Ziel im eigenen VLAN,
Ziel in einem anderen internen VLAN,
interner Server,
VPN-Gateway,
externes Ziel,
tatsächlich betroffener Anwendungsserver.

Beispielhafte Eingrenzung:

Messung	Ergebnis	mögliche Einordnung
Gateway bereits langsam	lokaler Link, WLAN, Client oder erstes Netzsegment
Gateway normal, interner Server langsam	Routing, Firewall, Servernetz oder Server
interne Ziele normal, externe Ziele langsam	WAN, Provider, VPN, Proxy oder externer Pfad
nur ein Ziel langsam	Zielserver, Zielnetz oder spezifischer Pfad
nur unter Last langsam	Queue, Auslastung, Bufferbloat oder Ressourcenengpass

ICMP kann durch Firewalls, Router oder Zielsysteme begrenzt oder niedriger priorisiert werden. Ein verlorenes oder verspätetes Ping-Paket beweist deshalb allein noch keinen Verlust des tatsächlichen Anwendungsverkehrs.

9. Paketverlust korrekt untersuchen

Paketverlust kann auftreten:

zwischen Client und Switch,
auf einer WLAN-Funkstrecke,
auf einem überlasteten Uplink,
in einer Firewall,
an einem Router,
in einem VPN-Tunnel,
auf dem WAN- oder Providerpfad,
auf dem Serverinterface,
innerhalb eines virtualisierten Netzwerks.

Windows

ping <ziel> -n 100
pathping <ziel>

Linux

ping -c 100 <ziel>
mtr <ziel>

macOS

ping -c 100 <ziel>
traceroute <ziel>

Bei pathping, mtr und ähnlichen Werkzeugen darf ein scheinbarer Verlust an einem Zwischenhop nicht automatisch als Fehler dieses Routers bewertet werden. Ein Router kann Antworten auf Diagnosepakete begrenzen, während er Transitverkehr weiterhin normal weiterleitet.

Bedeutsamer ist ein Verlust, wenn:

er ab einem Hop beginnt und an allen folgenden Hops bestehen bleibt,
er gleichzeitig in Ende-zu-Ende-Messungen auftritt,
Interfacezähler oder Paketaufzeichnungen ihn bestätigen,
der tatsächliche Anwendungsverkehr Wiederholungen oder Abbrüche zeigt.

10. Pfad und Richtungsunterschiede untersuchen

Windows

tracert <ziel>
Test-NetConnection <ziel> -TraceRoute
Get-NetRoute

Linux

traceroute <ziel>
tracepath <ziel>
ip route
ip route get <ziel>

macOS

traceroute <ziel>
netstat -rn
route -n get <ziel>

Zu prüfen sind:

Hinweg vom Client zum Ziel,
Rückweg vom Ziel zum Client,
unerwartete Umwege,
VPN-Routen,
Policy-Based Routing,
asymmetrisches Routing,
geänderte Gateways,
überlappende Netze,
unterschiedliche IPv4- und IPv6-Pfade,
Load Balancer oder mehrere Zieladressen.

Ein klassischer Traceroute zeigt normalerweise nur den beobachteten Hinweg. Der Rückweg kann anders verlaufen und muss gegebenenfalls von der Gegenstelle aus untersucht werden.

11. Durchsatz mit einer kontrollierten Gegenstelle messen

Für eine kontrollierte Ende-zu-Ende-Messung kann iperf3 verwendet werden. Dabei werden Client und Server benötigt.

Server starten

iperf3 -s

Clienttest

iperf3 -c <server-ip>

Gegenrichtung testen

iperf3 -c <server-ip> -R

Längerer Test

iperf3 -c <server-ip> -t 30

Mehrere parallele Datenströme

iperf3 -c <server-ip> -P 4

UDP-Test mit kontrollierter Zielrate

iperf3 -c <server-ip> -u -b <rate> -t 30

Dabei sind zu dokumentieren:

Client und Server,
beide IP-Adressen,
Netzpfad,
Datum und Uhrzeit,
TCP oder UDP,
Testdauer,
Anzahl paralleler Datenströme,
Hin- oder Rückrichtung,
gemessener Durchsatz,
gemeldete Wiederholungen,
bei UDP zusätzlich Verlust und Jitter,
gleichzeitige Auslastung anderer Verbindungen.

Wichtige Einschränkungen:

Das Ergebnis gilt nur für den Pfad zwischen den beiden Testendpunkten.
Der iperf3-Server muss autorisiert und kontrolliert betrieben werden.
Ein Test kann produktive Links stark auslasten.
UDP-Tests können bei ungeeigneter Zielrate erhebliche Paketverluste verursachen.
Mehrere parallele Verbindungen können einen höheren Gesamtdurchsatz erreichen als eine einzelne Verbindung.
Ein erfolgreicher iperf3-Test beweist nicht, dass DNS, TLS, Proxy oder Anwendung funktionieren.
Das iperf3-Projekt unterstützt offiziell Linux, FreeBSD und macOS; Windows-Builds stammen häufig aus anderen Quellen und sind nicht Teil der offiziellen Plattformunterstützung des Projekts.

Tests in produktiven Netzen müssen zeitlich, räumlich und in ihrer Bandbreite begrenzt werden.

12. Dateitransfer nicht ungeprüft als Netzwerkbenchmark verwenden

Eine Dateiübertragung misst nicht ausschließlich das Netzwerk. Das Ergebnis kann begrenzt werden durch:

Quelldatenträger,
Zieldatenträger,
Dateisystem,
SMB, NFS, SFTP oder HTTPS,
Verschlüsselung,
Kompression,
Virenscanner,
viele kleine Dateien,
Server-CPU,
Client-CPU,
Berechtigungsprüfung,
Protokollsignierung,
Backup oder Snapshot,
Cache.

Sinnvolle Vergleichstests:

große einzelne Datei gegen viele kleine Dateien,
Speicher-zu-Speicher-Test gegen Datenträgerübertragung,
kontrollierter Netzwerkdurchsatz gegen Anwendungsübertragung,
derselbe Client zu einem anderen Server,
ein anderer Client zum selben Server,
Lesen gegen Schreiben.

Wenn iperf3 einen normalen Netzwerkdurchsatz zeigt, die Dateiübertragung aber langsam bleibt, verschiebt sich die Untersuchung auf Protokoll, Datenträger, Server und Anwendung.

13. WLAN getrennt vom kabelgebundenen Netz prüfen

WLAN ist ein gemeinsam genutztes Funkmedium. Die angezeigte WLAN-Verbindungsrate entspricht nicht dem tatsächlich erreichbaren Nutzdurchsatz.

Zu prüfen sind:

Signalstärke,
Signal-Rausch-Verhältnis,
verwendetes Frequenzband,
Kanal,
Kanalbreite,
Kanalauslastung,
Störungen,
Anzahl gleichzeitig aktiver Clients,
Airtime-Auslastung,
Wiederholungsrate,
Datenrate,
Roaming,
Access-Point-Auslastung,
Uplink des Access Points,
PoE-Versorgung,
Treiber und Firmware,
Entfernung und Hindernisse,
Hidden-Node-Probleme,
Band Steering,
Mindestdatenraten,
WLAN-Sicherheitsverfahren.

Windows

netsh wlan show interfaces
netsh wlan show drivers
netsh wlan show wlanreport

Linux

iw dev
iw dev <interface> link
nmcli device wifi list

macOS

Auf macOS können die WLAN-Diagnose, die Systeminformationen sowie je nach Systemversion verfügbare Diagnosewerkzeuge verwendet werden. Die genaue Bedienung kann sich zwischen macOS-Versionen ändern.

Wichtige Vergleichstests:

betroffener Client am aktuellen Standort,
derselbe Client näher am Access Point,
derselbe Client per Ethernet,
anderer Client am selben Standort,
anderer Access Point oder anderes Frequenzband,
Messung bei geringer und hoher Auslastung.

Wenn der kabelgebundene Test normal und der WLAN-Test langsam ist, liegt die Ursache nicht automatisch am Access Point. Auch Clienttreiber, Funkumgebung, Kanalplanung, Airtime und Roaming müssen geprüft werden.

14. Auslastung, Warteschlangen und Bufferbloat

Ein Link kann unter geringer Last gute Latenzwerte und unter hoher Last starke Verzögerungen zeigen.

Beispiel:

ohne Übertragung:
Round-Trip Time zum Gateway: 2 ms

während eines Uploads:
Round-Trip Time zum Gateway: 180 ms

Mögliche Ursachen:

ausgelasteter Uplink,
zu große Warteschlangen,
fehlende oder ungeeignete QoS-Regeln,
Upload begrenzt Rückverkehr und Bestätigungen,
Firewall oder Router erreicht Leistungsgrenze,
VPN-Gateway ist ausgelastet,
WLAN-Airtime ist erschöpft,
Microbursts füllen einen Puffer,
Policer verwirft Pakete.

Zu vergleichen sind:

Latenz ohne Last,
Latenz während Download,
Latenz während Upload,
Paketverlust,
Interfaceauslastung,
Queue Drops,
CPU der Netzwerkkomponente,
Anzahl aktiver Verbindungen.

Eine hohe nominale Bandbreite verhindert solche Probleme nicht automatisch. Entscheidend sind Engpass, Warteschlangen und Lastverteilung entlang des vollständigen Pfades.

15. Duplex-, Speed- und Aushandlungsfehler

Ein Duplexproblem kann folgende Symptome verursachen:

geringer Durchsatz,
stark schwankende Übertragungsrate,
Framefehler,
Kollisionen oder späte Kollisionen bei älteren Ethernet-Szenarien,
viele Wiederholungen,
gute Werte ohne Last und schlechte Werte unter Last.

Zu prüfen sind beide Linkpartner:

Clientinterface ↔ Switchport
Serverinterface ↔ Switchport
Switch-Uplink ↔ Gegenstelle
Firewallinterface ↔ Switchport

Die Konfiguration muss zusammenpassen. Einseitiges Erzwingen von Geschwindigkeit oder Duplex kann einen Mismatch erzeugen.

Bei modernen Gigabit-Ethernet-Verbindungen wird normalerweise automatische Aushandlung verwendet. Abweichungen dürfen nur entsprechend der Hardware- und Herstelleranforderungen konfiguriert werden.

16. MTU und Fragmentierung prüfen

MTU-Probleme können auftreten, obwohl Ping und kleine Anfragen funktionieren.

Typische Symptome:

kleine Webseiten funktionieren,
größere Antworten bleiben hängen,
Dateiübertragungen brechen ab,
VPN-Verbindungen sind langsam,
TLS-Handshakes scheitern oder verzögern sich,
bestimmte Ziele funktionieren, andere nicht,
viele TCP-Wiederholungen,
Anwendungen warten bis zu einem Timeout.

Windows

ping <ziel> -f -l <paketgröße>

Linux

tracepath <ziel>
ping -M do -s <paketgröße> <ziel>

Die Nutzdatenlänge eines Pingpakets ist nicht mit der vollständigen IP-Paketgröße gleichzusetzen. IP- und ICMP-Header müssen berücksichtigt werden.

Zu prüfen sind:

MTU des Clients,
MTU des Servers,
VLAN- und Tunnel-Overhead,
VPN,
PPPoE,
VXLAN oder andere Kapselung,
Jumbo Frames,
Path MTU Discovery,
blockierte ICMP-Fehlermeldungen,
MSS-Anpassung.

Jumbo Frames dürfen nur verwendet werden, wenn der vollständige vorgesehene Pfad sie unterstützt. Eine Änderung ausschließlich an einem Endgerät ist keine geeignete Lösung.

17. TCP-Wiederholungen und Empfangsfenster untersuchen

TCP passt seine Übertragung an den Zustand des Datenpfades an. Paketverlust, hohe Laufzeit oder ein begrenztes Empfangsfenster können den Durchsatz stark reduzieren.

Mögliche Beobachtungen:

Retransmissions,
Duplicate Acknowledgements,
Out-of-Order-Segmente,
Zero Window,
Window Full,
lange Abstände zwischen Anfrage und Antwort,
wiederholter Verbindungsaufbau,
Reset,
stark unterschiedlicher Durchsatz je Richtung.

Wireshark-Filter

tcp.analysis.retransmission
tcp.analysis.fast_retransmission
tcp.analysis.spurious_retransmission
tcp.analysis.duplicate_ack
tcp.analysis.out_of_order
tcp.analysis.lost_segment
tcp.analysis.window_full
tcp.analysis.zero_window
tcp.analysis.zero_window_probe
tcp.flags.reset == 1

Mögliche Einordnung:

Beobachtung	mögliche Ursache
viele Retransmissions	Paketverlust, Überlastung, physischer Fehler oder Datenpfad
Duplicate ACKs	fehlende oder verspätete Segmente
Out-of-Order	unterschiedliche Pfade, Reordering oder Aufzeichnungsartefakt
Zero Window	Empfänger verarbeitet Daten nicht schnell genug
Window Full	ausgeschöpftes angekündigtes Empfangsfenster
wiederholte RST-Pakete	Anwendung, Firewall, Proxy oder Betriebssystem
lange Zeit bis zum ersten Datenpaket	Anwendung, DNS, TLS, Proxy oder Server
schnelle Pakete, aber lange Anwendungspausen	Anwendung oder Backend statt Transport

Wireshark-Kennzeichnungen beruhen auf der im Mitschnitt sichtbaren Paketreihenfolge. Ein unvollständiger Mitschnitt, Paketverlust bei der Aufzeichnung oder NIC-Offloading kann die Interpretation beeinflussen.

18. Paketaufzeichnung an mehreren Punkten

Wenn die Ursache nicht eindeutig ist, kann eine autorisierte Paketaufzeichnung an mehreren Stellen helfen.

Geeignete Punkte:

betroffener Client,
funktionierender Vergleichsclient,
Server,
vor und hinter einer Firewall,
Switch Mirror Port,
VPN-Endpunkt,
Reverse Proxy,
Load Balancer.

Zu prüfen sind:

Zeit bis zur DNS-Antwort,
Zeit bis zum TCP-Verbindungsaufbau,
Zeit bis zum TLS-Handshake,
Zeit bis zur ersten Anwendungsantwort,
Paketverlust,
Wiederholungen,
Fenstergrößen,
Reset-Pakete,
ICMP-Fehlermeldungen,
verwendete IP-Adresse,
IPv4 oder IPv6,
tatsächlicher Datenpfad.

Ein Mitschnitt nur auf dem Client zeigt nicht sicher, an welcher Zwischenstelle ein Paket verloren ging. Vergleichsmitschnitte an Client und Server können zeigen:

Paket verlässt den Client, erreicht aber den Server nicht.

oder:

Server sendet die Antwort, Client empfängt sie nicht.

Paketaufzeichnungen dürfen nur mit entsprechender Berechtigung erstellt und müssen geschützt gespeichert werden.

19. IPv4 und IPv6 getrennt vergleichen

Ein Client kann IPv6 bevorzugen, obwohl der IPv6-Pfad langsam oder fehlerhaft ist.

Windows

Resolve-DnsName <zielname> -Type A
Resolve-DnsName <zielname> -Type AAAA
Test-Connection <ipv4-adresse>
Test-Connection <ipv6-adresse>

Linux und macOS

ping -4 <zielname>
ping -6 <zielname>
curl -4 -v https://<zielname>/
curl -6 -v https://<zielname>/

Mögliche Ursachen:

unterschiedliche Routen,
falscher AAAA-Record,
IPv6-Firewallregel,
fehlerhafte IPv6-Rückroute,
Tunnel für eine Adressfamilie,
unterschiedliche Proxys oder Gateways,
Dienst antwortet nur über eine Adressfamilie zuverlässig.

IPv6 sollte nicht pauschal deaktiviert werden. Zuerst ist nachzuweisen, welche Adressfamilie betroffen ist.

20. DNS, Proxy, TLS und Anwendungslatenz abgrenzen

DNS-Zeit prüfen

dig <zielname>

Mit curl können einzelne Zeitabschnitte gemessen werden:

curl -sS -o /dev/null \
  -w 'DNS: %{time_namelookup}\nTCP: %{time_connect}\nTLS: %{time_appconnect}\nErstes Byte: %{time_starttransfer}\nGesamt: %{time_total}\n' \
  https://<zielname>/

Bedeutung:

Wert	untersuchter Bereich
`time_namelookup`	Namensauflösung
`time_connect`	Zeit bis zum TCP-Verbindungsaufbau
`time_appconnect`	Zeit bis zum Abschluss von TLS
`time_starttransfer`	Zeit bis zum ersten empfangenen Byte
`time_total`	gesamte Übertragungsdauer

Mögliche Einordnung:

DNS langsam, TCP normal: Resolver oder DNS-Pfad,
TCP-Verbindungsaufbau langsam: Netzwerkpfad, Paketverlust oder Ziel,
TLS langsam: Zertifikatsprüfung, TLS-Inspection oder Server,
erstes Byte langsam: Anwendung, Proxy, Backend oder Datenbank,
erstes Byte schnell, Übertragung langsam: Durchsatz, Paketverlust oder Serverausgabe.

Ein einzelner Messwert reicht nicht aus. Messungen sollten wiederholt und mit einem funktionierenden Vergleich verglichen werden.

21. VPN und Tunnel berücksichtigen

VPN-Verbindungen erzeugen zusätzliche Netzwerkschichten.

Mögliche Ursachen:

Tunnel-Overhead,
ungeeignete MTU,
fehlende MSS-Anpassung,
VPN-Gateway ausgelastet,
Verschlüsselung begrenzt CPU,
Full Tunnel leitet unnötigen Datenverkehr um,
Split-Tunnel-Regel fehlt,
DNS wird über einen entfernten Standort geleitet,
asymmetrisches Routing,
Paketverlust auf dem Transportpfad,
wechselnder Zugang zwischen WLAN und Mobilfunk,
Sicherheitsprüfung im VPN-Gateway.

Sinnvolle Vergleichstests:

ohne VPN zu einem zulässigen Vergleichsziel,
mit VPN zum selben zulässigen Ziel,
internes Ziel über VPN,
externes Ziel bei Full Tunnel,
IPv4 und IPv6,
Download und Upload,
Latenz zum VPN-Gateway und zum Endziel.

Ein langsamer Test über VPN beweist nicht automatisch, dass das VPN-Gateway die Ursache ist. Auch der lokale Internetzugang und der Pfad zum Gateway müssen geprüft werden.

22. Firewalls, Proxys und Sicherheitskomponenten

Sicherheitskomponenten können den Datenverkehr nicht nur erlauben oder blockieren, sondern auch verarbeiten.

Mögliche Einflussfaktoren:

TLS-Inspection,
Virenprüfung,
Intrusion Prevention,
URL-Filter,
Data Loss Prevention,
Proxy-Caching,
Bandbreitenbegrenzung,
QoS- oder Policing-Regel,
hohe Sitzungsanzahl,
ausgelastete CPU,
voller Arbeitsspeicher,
überlastete Protokollierung,
Cluster-Failover,
fehlerhafte Lastverteilung.

Zu prüfen sind:

Interfaceauslastung,
CPU und Arbeitsspeicher,
Sitzungstabelle,
Paket- und Fehlerzähler,
Queue Drops,
aktive Sicherheitsprofile,
Protokolle zum Störungszeitpunkt,
HA-Zustand,
Lizenz- oder Kapazitätsgrenzen,
Unterschiede zwischen untersuchten Anwendungen.

Sicherheitsfunktionen dürfen nicht pauschal deaktiviert werden. Tests müssen genehmigt, zeitlich begrenzt und auf eine konkrete Kommunikationsbeziehung beschränkt sein.

23. Server und Anwendung als Engpass prüfen

Auch bei fehlerfreiem Netzwerk kann der Zielserver den Durchsatz begrenzen.

Zu prüfen sind:

CPU pro Prozess und Thread,
Arbeitsspeicher,
Paging oder Swapping,
Datenträgerlatenz,
I/O-Wait,
Queue Depth,
Netzwerkinterface,
offene Verbindungen,
Connection Pools,
Datenbanklocks,
Anwendungswarteschlangen,
parallele Backups,
Virenscanner,
Snapshots,
Hypervisorauslastung,
Storage-Netzwerk,
Load Balancer,
Backend-Abhängigkeiten.

Typisches Muster:

iperf3 zum Server: normal
Dateiübertragung: langsam
Server-Datenträger: dauerhaft ausgelastet

In diesem Fall ist ein Netzwerkengpass nicht nachgewiesen. Die Untersuchung muss auf Datenträger, Protokoll und Server fortgesetzt werden.

24. Virtualisierung und Container

Zusätzliche Ursachen bei virtuellen Systemen:

virtuelle Netzwerkkarte begrenzt,
vSwitch oder Bridge ausgelastet,
falsches VLAN Tagging,
Host-Uplink überlastet,
NIC Teaming oder Bonding fehlerhaft,
CPU-Steal oder CPU Ready,
Host Memory Pressure,
Storage-Latenz,
Sicherheitsgruppe oder virtuelle Firewall,
Overlay-Netzwerk,
Container-NAT,
Service Mesh,
Reverse Proxy,
Host-Portzuordnung,
fehlerhafte MTU innerhalb des Overlays.

Die Prüfung sollte folgende Ebenen unterscheiden:

Anwendung
↓
Container oder virtuelle Maschine
↓
virtuelles Interface
↓
virtueller Switch oder Bridge
↓
Hostinterface
↓
physischer Switch
↓
weiterer Netzwerkpfad

Ein unauffälliger Zähler innerhalb der virtuellen Maschine schließt Fehler auf dem Host-Uplink nicht aus.

25. Sporadische Langsamkeit erfassen

Bei sporadischen Fehlern reichen manuelle Einzeltests häufig nicht aus.

PowerShell

1..30 | ForEach-Object {
    $time = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    $result = Test-Connection <ziel> -Count 1 -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        Time   = $time
        Status = if ($result) { "Erfolg" } else { "Fehler" }
        RTTms  = if ($result) { $result.Latency } else { $null }
    }
    Start-Sleep -Seconds 10
}

Abhängig von der verwendeten PowerShell-Version können Eigenschaften des zurückgegebenen Objekts abweichen und müssen vor einer automatisierten Auswertung geprüft werden.

Bash

for i in {1..30}; do
    date '+%Y-%m-%d %H:%M:%S'
    ping -c 1 <ziel>
    sleep 10
done

Zusätzlich zu erfassen sind:

Interfacezähler,
Link-Flaps,
Switchportstatus,
WLAN-Roaming,
Kanal- und Airtime-Auslastung,
CPU und RAM,
Datenträgerlatenz,
Firewall-Sitzungsanzahl,
geplante Backups,
Updates,
Scans,
Cronjobs oder Timer,
Providerereignisse,
Temperatur und Stromversorgung.

Alle Systeme müssen möglichst einheitlich synchronisierte Zeit verwenden, damit Ereignisse auf einer gemeinsamen Zeitleiste verglichen werden können.

26. Praxisfall A: Nur ein Client ist langsam

Symptom

ein Client überträgt mit etwa 90 Mbit/s,
andere Clients am selben Switch erreichen wesentlich höhere Werte,
Server und Anwendung sind für andere Benutzer normal,
der betroffene Client zeigt eine Linkgeschwindigkeit von 100 Mbit/s.

Prüfung

Linkgeschwindigkeit dokumentieren.
Netzwerkkartenstatistik prüfen.
Kabel und Switchport kontrollieren.
Client mit bekannt funktionierendem Kabel testen.
denselben Switchport mit einem Vergleichsclient testen.
Treiber und Adapter prüfen.
kontrollierten Durchsatztest wiederholen.

Mögliche Ursache

Das Netzwerkkabel besitzt eine fehlerhafte Adernpaarverbindung. Deshalb wird nur Fast Ethernet statt Gigabit Ethernet ausgehandelt.

Nachprüfung

Link wird mit der vorgesehenen Geschwindigkeit ausgehandelt,
Fehlerzähler steigen nicht,
kontrollierter Durchsatz entspricht wieder der Baseline,
die ursprüngliche Anwendung funktioniert,
Kabel und Ursache sind dokumentiert.

27. Praxisfall B: WLAN langsam, Ethernet normal

Symptom

mehrere WLAN-Clients sind langsam,
kabelgebundene Clients funktionieren,
Latenz zum Gateway steigt unter Last stark,
Access Point und Clients verwenden denselben stark belegten Kanal.

Prüfung

WLAN- und Ethernettest vergleichen.
Signal, Kanal und Kanalauslastung erfassen.
Airtime und Wiederholungsrate am Access Point prüfen.
benachbarte Funknetze berücksichtigen.
Uplink und CPU des Access Points prüfen.
kontrollierte Messung bei geringer Last durchführen.
Kanalplanung entsprechend der vorhandenen Funkumgebung prüfen.

Mögliche Ursache

Der verwendete Kanal ist stark ausgelastet. Mehrere Access Points und fremde WLANs konkurrieren um dieselbe Airtime.

Nachprüfung

vorgesehene Kanalplanung ist umgesetzt,
Wiederholungsrate ist gesunken,
Latenz bleibt auch unter kontrollierter Last stabiler,
Durchsatz hat sich nachweisbar verbessert,
benachbarte Funkzellen funktionieren weiterhin,
Änderung und Messergebnisse sind dokumentiert.

28. Praxisfall C: Download schnell, Upload langsam

Symptom

Downloads erreichen die erwartete Größenordnung,
Uploads brechen stark ein,
bei Uploadlast steigt die Latenz,
andere Anwendungen reagieren währenddessen verzögert.

Prüfung

Download und Upload getrennt messen.
Gegenrichtung mit kontrollierter Messung prüfen.
WAN-Auslastung und Queue beobachten.
Firewall- und Router-CPU prüfen.
Drops und Policing-Zähler kontrollieren.
Providerprofil und vereinbarte Uploadrate prüfen.
VPN- und QoS-Regeln berücksichtigen.

Mögliche Ursache

Der verfügbare Upstream wird vollständig ausgelastet. Eine ungeeignete Warteschlangensteuerung verursacht zusätzliche Latenz.

Nachprüfung

Upload bleibt innerhalb der vorgesehenen Kapazität,
interaktive Anwendungen bleiben unter Last nutzbar,
Queue Drops und Latenz wurden erneut gemessen,
vorgesehene Priorisierung funktioniert,
nicht autorisierte Bandbreitenerweiterungen wurden nicht vorgenommen.

29. Praxisfall D: Netzwerk normal, Anwendung langsam

Symptom

Latenz und Paketverlust sind unauffällig,
kontrollierter Durchsatz ist normal,
nur eine Webanwendung antwortet langsam,
Zeit bis zum ersten Byte ist stark erhöht.

Prüfung

DNS-, TCP-, TLS- und Antwortzeiten getrennt messen.
Anwendung mit anderem Client vergleichen.
Reverse-Proxy-Protokolle prüfen.
Backend-Verbindung testen.
Anwendungs- und Datenbankprotokolle auswerten.
Serverressourcen kontrollieren.
zeitgleiche Jobs oder Locks prüfen.

Mögliche Ursache

Eine Datenbankabfrage wartet auf eine Sperre. Das Netzwerk transportiert die Pakete normal, die Anwendung erzeugt die Antwort jedoch verspätet.

Nachprüfung

Zeit bis zum ersten Byte hat sich normalisiert,
Netzwerkwerte bleiben unverändert,
Datenbank- und Anwendungszustand sind fehlerfrei,
ursprünglicher Geschäftsprozess funktioniert,
Ursache und Maßnahme sind dokumentiert.

30. Praxisfall E: Über VPN funktionieren kleine Anfragen, große Übertragungen brechen ein

Symptom

Anmeldung am VPN funktioniert,
Ping und kleine Webanfragen funktionieren,
größere Dateiübertragungen hängen oder werden sehr langsam,
ohne VPN tritt das Problem nicht auf.

Prüfung

Pfad und Tunnelart dokumentieren.
MTU auf Client, Tunnel und Zielpfad prüfen.
Paketaufzeichnung auf Wiederholungen untersuchen.
ICMP-Fehlermeldungen berücksichtigen.
MSS-Anpassung am Tunnel prüfen.
Upload und Download getrennt testen.
VPN-Gatewayauslastung kontrollieren.

Mögliche Ursache

Durch den Tunnel-Overhead ist die effektive MTU geringer. Notwendige Rückmeldungen für Path MTU Discovery werden auf dem Pfad verworfen.

Nachprüfung

kleine und große Übertragungen funktionieren,
TCP-Wiederholungen sind zurückgegangen,
vorgesehene MTU- beziehungsweise MSS-Konfiguration ist dokumentiert,
andere VPN-Verbindungen wurden kontrolliert,
keine pauschale Deaktivierung von Sicherheitsfunktionen erfolgte.

31. Ungeeignete Sofortmaßnahmen

Problematisch sind insbesondere:

Netzwerkgeräte ohne Dokumentation neu starten,
Kabel, Switchports und Konfiguration gleichzeitig verändern,
Geschwindigkeit oder Duplex nur auf einer Seite erzwingen,
Jumbo Frames versuchsweise aktivieren,
IPv6 pauschal deaktivieren,
Firewalls oder Sicherheitsprüfung vollständig abschalten,
QoS-Regeln ohne Messung verändern,
produktive Links mit unkontrollierten Lasttests auslasten,
UDP-Tests mit beliebiger hoher Zielrate durchführen,
Provider verantwortlich machen, ohne den lokalen Pfad geprüft zu haben,
einen einzelnen Pingverlust als eindeutigen Beweis verwenden,
jeden Verlust an einem Traceroute-Hop als Fehler dieses Routers interpretieren,
eine Dateiübertragung als reinen Netzwerkbenchmark behandeln,
Paketaufzeichnungen ungeschützt speichern,
Netzwerkkartentreiber ungeprüft ersetzen,
Offload- und Empfangseinstellungen wahllos deaktivieren,
Server neu starten, ohne Ressourcen und Protokolle zu sichern.

Vor Änderungen sollten mindestens dokumentiert werden:

Symptom,
betroffene Benutzer und Systeme,
Quelle und Ziel,
Verbindungstyp,
Linkgeschwindigkeit,
DNS-Ergebnis,
Latenz,
Paketverlust,
Durchsatz,
Interfacezähler,
Route,
Serverressourcen,
Zeitpunkt,
Vergleichssystem,
aktuelle Konfiguration.

32. Vollständige Prüfreihenfolge

genaue langsame Funktion benennen.
Soll- und Istwert dokumentieren.
Zeitpunkt, Dauer und Häufigkeit erfassen.
betroffene Benutzer, Clients und Standorte bestimmen.
Quelle, Ziel und Datenrichtung dokumentieren.
funktionierenden Vergleichsclient bestimmen.
WLAN und Ethernet unterscheiden.
internes und externes Ziel vergleichen.
Clientressourcen prüfen.
Interface- und Linkstatus prüfen.
ausgehandelte Geschwindigkeit und Duplex kontrollieren.
Kabel, Adapter und Switchport berücksichtigen.
Interfacezähler vor dem Test erfassen.
Latenz zum Gateway messen.
Latenz zu internen und externen Zielen vergleichen.
Paketverlust Ende zu Ende untersuchen.
Pfad und Route prüfen.
IPv4 und IPv6 getrennt vergleichen.
Interfacezähler nach dem Test erneut erfassen.
Download und Upload getrennt messen.
kontrollierten Durchsatztest verwenden.
einzelne und parallele TCP-Verbindungen vergleichen.
Datenträger und Anwendung vom Netzwerk abgrenzen.
WLAN-Signal, Kanal, Airtime und Wiederholungen prüfen.
Uplinks, Port-Channels und Queue Drops kontrollieren.
Firewall, VPN, Proxy und Sicherheitsprüfung berücksichtigen.
Server-CPU, RAM und Datenträgerlatenz prüfen.
Virtualisierung, vSwitch und Host-Uplink untersuchen.
MTU, Tunnel und Fragmentierung bei passenden Symptomen prüfen.
TCP-Wiederholungen und Fensterverhalten analysieren.
bei Bedarf autorisierte Paketaufzeichnung erstellen.
Beobachtungen auf einer gemeinsamen Zeitleiste korrelieren.
konkrete Hypothese formulieren.
genau eine kontrollierbare Änderung durchführen.
Latenz erneut messen.
Paketverlust erneut prüfen.
Durchsatz erneut messen.
ursprüngliche Anwendung erneut testen.
funktionierende Vergleichssysteme kontrollieren.
temporäre Tests und Freigaben entfernen.
Ursache, Maßnahme und Nachweis dokumentieren.
Monitoring oder Präventionsmaßnahme festlegen.

33. Dokumentationsbeispiel

Ticket: INC-20718
Beginn: 02.08.2026, etwa 09:20 Uhr
Umfang: mehrere WLAN-Clients im VLAN 30
Nicht betroffen: kabelgebundene Clients im VLAN 20
Ziel: interner Dateiserver fileserver.example.test

Symptom:
Dateiübertragungen über WLAN erreichen nur etwa 8 bis 15 Mbit/s.
Kabelgebundene Vergleichsclients erreichen zum selben Server etwa
700 Mbit/s. Kleine Webanfragen und DNS-Auflösungen funktionieren.

Ausgangszustand:
- DNS-Auflösung korrekt
- Server per TCP erreichbar
- Dateiserver für Ethernet-Clients normal
- Serverressourcen unauffällig
- Access-Point-Uplink mit 1 Gbit/s aktiv
- keine steigenden CRC-Fehler am Uplink
- hohe Kanalauslastung im verwendeten Frequenzbereich
- erhöhte WLAN-Wiederholungsrate
- Latenz zum Gateway steigt unter Last deutlich

Hypothese:
Die Funkzelle besitzt zu wenig freie Airtime. Der Datenverkehr wird
wiederholt übertragen und wartet auf den Zugriff auf das Funkmedium.

Prüfung:
- Ethernet und WLAN mit demselben Ziel verglichen
- mehrere WLAN-Clients getestet
- Signalstärke und Kanal erfasst
- Uplink und Server als Engpass ausgeschlossen
- kontrollierter Durchsatztest in beide Richtungen durchgeführt
- Access-Point-Statistiken zum Störungszeitpunkt ausgewertet

Ursache:
Starke Kanalbelegung und überlappende Funkzellen führten zu einer
hohen Wiederholungsrate und geringer nutzbarer Airtime.

Maßnahme:
Die Kanalplanung der betroffenen Funkzellen wurde nach einer
Funkumgebungsanalyse kontrolliert angepasst.

Nachprüfung:
- Latenz zum Gateway unter Last verbessert
- Wiederholungsrate gesunken
- kontrollierter WLAN-Durchsatz deutlich erhöht
- ursprüngliche Dateiübertragung funktioniert
- Ethernet-Clients weiterhin fehlerfrei
- benachbarte Funkzellen kontrolliert

Prävention:
- Kanalauslastung und Wiederholungsrate überwachen
- WLAN-Baseline pro Standort dokumentieren
- Funkumgebung nach größeren Änderungen erneut prüfen

34. Checkliste „Netzwerk ist langsam“

35. Schnellreferenz

Fehlerbild	wahrscheinlicher Untersuchungsbereich
nur ein Client langsam	Client, Kabel, Adapter, Treiber oder Switchport
alle Clients eines Switches langsam	Uplink, Switch, VLAN oder gemeinsame Gegenstelle
nur WLAN langsam	Funkumgebung, Airtime, Kanal, AP oder Client
Ethernet und WLAN langsam	Gateway, Uplink, Firewall, WAN, Server oder Anwendung
nur ein Server langsam	Zielserver, Servernetz, Datenträger oder Anwendung
alle externen Ziele langsam	WAN, Provider, Firewall, Proxy oder VPN
nur Upload langsam	Upstream, Queue, Policing, Provider oder VPN
nur Download langsam	Downstream, Server, TCP, Proxy oder Client
Latenz steigt nur unter Last	Queue, Auslastung, Bufferbloat oder Drops
Ping normal, Dateiübertragung langsam	Durchsatz, Datenträger, Protokoll oder Anwendung
Durchsatztest normal, Anwendung langsam	DNS, TLS, Proxy, Backend, Datenbank oder Server
Link nur mit 100 Mbit/s	Kabel, Adapter, Switchport oder Aushandlung
steigende CRC-/FCS-Fehler	physischer Link, Kabel, Transceiver oder Port
steigende Drops ohne CRC-Fehler	Queue, Überlastung, Policing oder Puffer
viele TCP-Retransmissions	Paketverlust, Überlastung oder Datenpfad
TCP Zero Window	Empfänger verarbeitet Daten zu langsam
kleine Pakete funktionieren, große nicht	MTU, Tunnel oder Fragmentierung
nur über VPN langsam	Tunnel, MTU, Gateway, Verschlüsselung oder Route
nur IPv6 langsam	IPv6-Pfad, Firewall, Route oder Zieladresse
nur IPv4 langsam	IPv4-Pfad, NAT, Firewall oder Route
nur zu bestimmten Zeiten langsam	Last, Backup, Scan, Job, Provider oder Funkumgebung
ein TCP-Stream langsam, mehrere schneller	Latenz, Fenster, Verlust oder Serverbegrenzung
WLAN-Signal gut, Durchsatz schlecht	Kanalauslastung, Airtime, Störung oder Wiederholungen
erstes Byte langsam	Anwendung, Proxy, Backend oder Datenbank
erstes Byte schnell, Download langsam	Durchsatz, Verlust, Serverausgabe oder Client
lokale Ziele schnell, Internet langsam	WAN, Provider, NAT, Firewall oder Proxy
Gateway bereits langsam	lokaler Link, WLAN, Client oder erstes Netzsegment

Merksatz

„Langsam“ ist keine eindeutige Fehlerursache. Eine belastbare Analyse trennt Latenz, Paketverlust, Jitter und Durchsatz, vergleicht funktionierende und betroffene Pfade und prüft anschließend Client, Link, WLAN, Switch, Firewall, WAN, Server und Anwendung. Erst reproduzierbare Messwerte vor und nach einer kontrollierten Änderung belegen eine Verbesserung.

Quellen und weiterführende Dokumentation

6.6 Fehler tritt nur manchmal auf – sporadische Störungen systematisch erfassen und korrelieren

Sporadische Fehler gehören zu den schwierigsten Störungen in der IT-Fehleranalyse. Zum Zeitpunkt der Untersuchung funktioniert das betroffene System häufig wieder normal. Einzelne manuelle Tests liefern dann keine auffälligen Ergebnisse.

Typische Aussagen sind:

„Das passiert nur manchmal.“
„Nach einigen Minuten geht es wieder.“
„Heute Morgen war alles langsam.“
„Die Verbindung bricht unregelmäßig ab.“
„Nach einem Neustart funktioniert es wieder.“
„Der Fehler tritt nur bei bestimmten Benutzern auf.“
„In den Protokollen ist nichts zu sehen.“
„Es passiert meistens nachts oder unter hoher Last.“

Eine belastbare Untersuchung benötigt deshalb:

einen möglichst genauen Fehlerzeitpunkt,
eine reproduzierbare Beschreibung des Symptoms,
kontinuierliche oder ereignisgesteuerte Messungen,
ausreichend lange aufbewahrte Protokolle,
synchronisierte Systemzeiten,
Messdaten vor, während und nach dem Fehler,
eine gemeinsame Zeitleiste aller beteiligten Systeme.

Ein unauffälliger Einzeltest beweist lediglich, dass der Fehler während dieses Tests nicht beobachtet wurde.

1. Was ist ein sporadischer Fehler?

Ein sporadischer Fehler tritt nicht dauerhaft und häufig nicht zuverlässig reproduzierbar auf.

Mögliche Erscheinungsformen:

zufällig wirkende Verbindungsabbrüche,
zeitweise sehr hohe Latenz,
gelegentliche Anmeldefehler,
nur einzelne fehlgeschlagene DNS-Anfragen,
kurzzeitige Serverausfälle,
unregelmäßige WLAN-Unterbrechungen,
vereinzelte Zeitüberschreitungen,
Dienste reagieren vorübergehend nicht,
Dateien können manchmal nicht geöffnet werden,
eine Anwendung verliert gelegentlich ihre Sitzung,
ein Switchport wechselt kurzzeitig den Linkstatus,
ein DHCP-Lease wird gelegentlich nicht erneuert,
Zertifikats- oder Tokenfehler treten nur zu bestimmten Zeiten auf.

Sporadisch bedeutet nicht automatisch zufällig. Häufig besitzt der Fehler ein Muster, das erst durch ausreichend lange Beobachtung sichtbar wird.

2. Typische Ursachen

Mögliche Ursachen sind:

kurzzeitige Link-Unterbrechung,
beschädigtes Kabel oder loser Steckverbinder,
instabile Stromversorgung,
Überhitzung,
WLAN-Interferenz,
Roaming zwischen Access Points,
ausgelasteter Uplink,
Microbursts,
kurzfristig volle Warteschlangen,
DHCP-Lease-Erneuerung,
ablaufender DNS-Cache oder DNS-TTL,
Token- oder Sitzungsablauf,
Idle-Timeout,
VPN-Rekeying,
Zertifikatsablauf oder fehlerhafte Zertifikatsprüfung,
geplantes Backup,
Virenscan,
Snapshot,
Replikation,
Datenbankwartung,
Softwareverteilung,
Update oder Neustart,
Ressourcenerschöpfung,
Speicherleck,
kurzzeitig hohe CPU- oder Datenträgerlast,
begrenzter Connection Pool,
Port- oder Socket-Erschöpfung,
Paketverlust,
Firewall- oder Proxy-Timeout,
Load-Balancer-Health-Check,
Cluster-Failover,
Providerstörung,
Fehler in einem externen Dienst.

3. Auswirkungen bestimmen

Vor der technischen Untersuchung muss der Umfang eingegrenzt werden.

Zu klären ist:

ein Benutzer oder mehrere Benutzer,
ein Client oder mehrere Clients,
ein Standort oder mehrere Standorte,
WLAN oder Ethernet,
ein VLAN oder mehrere VLANs,
ein Server oder mehrere Server,
eine Anwendung oder mehrere Anwendungen,
interne oder externe Ziele,
IPv4 oder IPv6,
mit oder ohne VPN,
nur Upload oder nur Download,
nur ein bestimmter Geschäftsprozess,
nur eine bestimmte Uhrzeit,
nur unter Last,
nur nach längerer Inaktivität,
nur nach Anmeldung, Aufwachen oder Netzwerkwechsel.

Eine Beobachtung wie „Das Netzwerk war kurz weg“ ist noch keine ausreichende Fehlerbeschreibung.

4. Fehlerzeitpunkt exakt erfassen

Der wichtigste Ausgangspunkt ist ein möglichst genauer Zeitstempel.

Ungeeignet:

Der Fehler war heute Morgen.

Besser:

02.08.2026 zwischen 09:14:20 und 09:15:05 Uhr

Noch besser:

02.08.2026, 09:14:37 Uhr:
Beim Öffnen von \\fileserver.example.test\projekte erschien nach etwa
30 Sekunden die Meldung „Der Netzwerkname wurde nicht gefunden“.

09:15:05 Uhr:
Ein erneuter Versuch war erfolgreich.

Zusätzlich zu dokumentieren:

Zeitzone,
Benutzer,
Clientname,
Client-IP,
MAC-Adresse,
Standort,
Verbindungstyp,
Access Point oder Switchport,
Zielname,
Ziel-IP,
Anwendung,
verwendeter Port,
genaue Meldung,
Dauer,
Aktion unmittelbar vor dem Fehler,
Zustand nach dem Fehler.

Screenshots sollten nach Möglichkeit die Uhrzeit enthalten. Andernfalls muss der Zeitpunkt separat dokumentiert werden.

5. Systemzeiten kontrollieren

Daten verschiedener Systeme können nur sinnvoll korreliert werden, wenn ihre Uhren ausreichend genau synchronisiert sind.

Zu prüfen sind:

Uhrzeit,
Datum,
Zeitzone,
konfigurierte Zeitquelle,
Synchronisationsstatus,
Abweichung zur Referenz,
Zeitpunkt der letzten Synchronisation,
Erreichbarkeit der Zeitquelle,
Zeitstatus virtueller Maschinen,
Zeitquelle von Netzwerkgeräten,
Zeitquelle von Containern und Hosts.

Windows

Get-Date
Get-TimeZone
w32tm /query /status
w32tm /query /source
w32tm /query /configuration

Linux

date --iso-8601=seconds
timedatectl status
timedatectl timesync-status

macOS

date
systemsetup -gettimezone
systemsetup -getusingnetworktime
systemsetup -getnetworktimeserver

Ein Zeitunterschied von mehreren Minuten kann dazu führen, dass zusammengehörige Ereignisse in Client-, Server-, Firewall- und Netzwerkprotokollen nicht erkannt werden.

Die Uhrzeit darf nicht unkontrolliert verändert werden. In Domänen, Clustern, Datenbanken und authentifizierten Umgebungen können Zeitsprünge zusätzliche Fehler verursachen.

6. Fehlermeldung vollständig sichern

Zu erfassen sind:

vollständiger Meldungstext,
Fehlercode,
Event-ID,
HTTP-Statuscode,
Anwendungscode,
Quell- und Zielsystem,
betroffene Datei oder Ressource,
Zeitpunkt,
vorherige Benutzeraktion,
Dauer bis zur Meldung,
Verhalten bei Wiederholung.

Beispiel:

Ungeeignet:
„VPN ging nicht.“

Geeignet:
„Am 02.08.2026 um 11:42:18 Uhr brach die bestehende VPN-Verbindung
nach ungefähr 27 Minuten Laufzeit ab. Der Client meldete Fehlercode
809. Der lokale Internetzugang funktionierte währenddessen weiter.
Die erneute VPN-Verbindung war um 11:43:02 Uhr erfolgreich.“

Die originale Meldung darf nicht nur sinngemäß wiedergegeben werden.

7. Muster suchen

Sporadische Fehler sollten nach wiederkehrenden Merkmalen untersucht werden.

Muster	möglicher Untersuchungsbereich
immer zur gleichen Uhrzeit	Backup, Scan, Update, Wartungsjob oder Provider
nach längerer Inaktivität	Idle-Timeout, Energiesparmodus oder Sitzung
nach Ablauf einer festen Dauer	Lease, Token, Session, NAT, Firewall oder VPN-Rekeying
nur unter Last	Ressourcen, Queue, Uplink, Storage oder Connection Pool
nur montags oder nach dem Wochenende	Lease, Kennwort, Zertifikat, Patch oder Neustart
nur bei einem Benutzer	Benutzerprofil, Berechtigung, Token oder Endgerät
nur bei einem Client	Hardware, Treiber, Kabel, WLAN oder lokale Software
nur an einem Standort	WAN, WLAN, Switch, Strom oder Provider
nur bei WLAN	Interferenz, Roaming, Airtime oder Access Point
nur bei VPN	Tunnel, Gateway, MTU, Rekeying oder Route
nach Aufwachen des Clients	Treiber, DHCP, DNS, VPN oder Energiesparmodus
nach Konfigurationsänderung	fehlerhafte Änderung oder Abhängigkeit
alle 30 oder 60 Minuten	geplanter Timer, Lease, Token, Job oder Polling
bei hoher Raumtemperatur	Kühlung, Transceiver, Netzteil oder Hardware
bei Regen oder Wind	Außenleitung, Funkstrecke, Strom oder Providerpfad

Eine zeitliche Übereinstimmung ist zunächst nur eine Korrelation und noch kein Beweis für die Ursache.

8. Kontinuierliche Erreichbarkeitsmessung unter Windows

Ein einfacher protokollierter Test kann prüfen, ob ein Ziel zum Störungszeitpunkt erreichbar war.

$Target = "<ziel>"
$LogFile = ".\availability.csv"

"Time,Target,Status,LatencyMs" | Set-Content -Path $LogFile

while ($true) {
    $Time = Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK"
    $Result = Test-Connection -TargetName $Target -Count 1 -ErrorAction SilentlyContinue

    if ($Result) {
        "$Time,$Target,Success,$($Result.Latency)" |
            Add-Content -Path $LogFile
    }
    else {
        "$Time,$Target,Failure," |
            Add-Content -Path $LogFile
    }

    Start-Sleep -Seconds 5
}

Vor dem Einsatz ist zu prüfen, welche Eigenschaften Test-Connection in der verwendeten PowerShell-Version zurückgibt.

Beenden:

[CTRL] + [C]

Die Messung zeigt nur die ICMP-Erreichbarkeit des gewählten Ziels. Sie beweist nicht, dass DNS, TCP, TLS oder die Anwendung funktioniert haben.

9. Kontinuierliche Erreichbarkeitsmessung unter Linux und macOS

target="<ziel>"
logfile="./availability.log"

while true; do
    printf '%s ' "$(date '+%Y-%m-%dT%H:%M:%S%z')" >> "$logfile"

    if ping -c 1 -W 2 "$target" >> "$logfile" 2>&1; then
        printf 'STATUS=SUCCESS\n' >> "$logfile"
    else
        printf 'STATUS=FAILURE\n' >> "$logfile"
    fi

    sleep 5
done

Je nach Betriebssystem unterscheiden sich die Optionen und die Einheit des Ping-Timeouts. Der konkrete Befehl muss auf dem Zielsystem geprüft werden.

Beenden:

[CTRL] + [C]

Sinnvolle parallele Ziele:

Loopback-Adresse,
eigene IP-Adresse,
Standardgateway,
interner Server,
DNS-Server,
VPN-Gateway,
externes Vergleichsziel,
tatsächlich betroffener Dienst.

Dadurch kann erkannt werden, ab welchem Teil des Pfades der Fehler sichtbar wird.

10. Dienst statt nur Ping überwachen

Wenn die Anwendung einen bestimmten TCP-Port benötigt, sollte zusätzlich dieser Port getestet werden.

Windows

$Target = "<ziel>"
$Port = <port>
$LogFile = ".\tcp-check.csv"

"Time,Target,Port,Success" | Set-Content -Path $LogFile

while ($true) {
    $Time = Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK"
    $Result = Test-NetConnection -ComputerName $Target -Port $Port `
        -InformationLevel Quiet

    "$Time,$Target,$Port,$Result" |
        Add-Content -Path $LogFile

    Start-Sleep -Seconds 10
}

Linux und macOS

while true; do
    timestamp="$(date '+%Y-%m-%dT%H:%M:%S%z')"

    if nc -z -w 3 <ziel> <port>; then
        printf '%s TARGET=%s PORT=%s STATUS=SUCCESS\n' \
            "$timestamp" "<ziel>" "<port>"
    else
        printf '%s TARGET=%s PORT=%s STATUS=FAILURE\n' \
            "$timestamp" "<ziel>" "<port>"
    fi

    sleep 10
done >> tcp-check.log 2>&1

Ein erfolgreicher TCP-Verbindungsaufbau beweist noch nicht, dass Anmeldung, Datenbank, Backend oder vollständiger Geschäftsprozess funktionieren.

11. DNS kontinuierlich prüfen

Sporadische Namensauflösungsfehler können durch einen einzelnen Ping auf eine IP-Adresse übersehen werden.

Windows

$Name = "<zielname>"
$LogFile = ".\dns-check.log"

while ($true) {
    $Time = Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK"
    "===== $Time =====" | Add-Content -Path $LogFile

    Resolve-DnsName -Name $Name -ErrorAction Continue |
        Out-String |
        Add-Content -Path $LogFile

    Start-Sleep -Seconds 30
}

Linux und macOS

while true; do
    printf '===== %s =====\n' "$(date '+%Y-%m-%dT%H:%M:%S%z')"
    dig <zielname>
    sleep 30
done >> dns-check.log 2>&1

Zu vergleichen sind:

Antwortzeit,
verwendeter DNS-Server,
Antwortcode,
A-Record,
AAAA-Record,
CNAME,
TTL,
wechselnde Zieladressen,
Antwort bei Erfolg und Fehler.

Ein absichtlich wechselnder DNS-Eintrag, beispielsweise bei einem Load Balancer, darf nicht automatisch als Fehler bewertet werden.

12. HTTP- und Anwendungszeiten aufzeichnen

Für HTTP- oder HTTPS-Dienste kann curl einzelne Zeitabschnitte protokollieren.

while true; do
    timestamp="$(date '+%Y-%m-%dT%H:%M:%S%z')"

    result="$(curl -sS -o /dev/null \
      --connect-timeout 10 \
      --max-time 30 \
      -w 'code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}' \
      https://<zielname>/ 2>&1)"

    printf '%s %s\n' "$timestamp" "$result"
    sleep 30
done >> http-check.log

Mögliche Einordnung:

Beobachtung	möglicher Bereich
DNS-Zeit erhöht	Resolver oder DNS-Pfad
TCP-Aufbau erhöht	Netzwerkpfad, Paketverlust oder Ziel
TLS-Zeit erhöht	Zertifikatsprüfung, Inspection oder Server
erstes Byte verspätet	Anwendung, Proxy, Backend oder Datenbank
Gesamtzeit erhöht	Übertragung, Durchsatz, Server oder Client
wechselnde Ziel-IP mit Fehler nur bei einer IP	Load Balancer oder einzelner Backend-Pfad
HTTP-Fehlercode	Anwendung, Proxy, Authentifizierung oder Backend

Die Abfrage muss auf einen ungefährlichen und autorisierten Endpunkt begrenzt werden.

13. Interfacezustand und Fehlerzähler regelmäßig erfassen

Sporadische Linkfehler sind häufig nur als kurzzeitiger Statuswechsel oder steigender Fehlerzähler sichtbar.

Windows

$LogFile = ".\adapter-statistics.csv"

while ($true) {
    $Time = Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK"

    Get-NetAdapterStatistics |
        Select-Object @{
            Name = "Time"
            Expression = { $Time }
        }, Name, ReceivedBytes, SentBytes,
           ReceivedUnicastPackets, SentUnicastPackets,
           ReceivedDiscardedPackets, OutboundDiscardedPackets,
           ReceivedPacketErrors, OutboundPacketErrors |
        Export-Csv -Path $LogFile -Append -NoTypeInformation

    Start-Sleep -Seconds 30
}

Linux

while true; do
    printf '===== %s =====\n' "$(date '+%Y-%m-%dT%H:%M:%S%z')"
    ip -s link show dev <interface>
    ethtool <interface>
    ethtool -S <interface>
    sleep 30
done >> interface-check.log 2>&1

macOS

while true; do
    printf '===== %s =====\n' "$(date '+%Y-%m-%dT%H:%M:%S%z')"
    ifconfig <interface>
    netstat -ib
    sleep 30
done >> interface-check.log 2>&1

Zu beobachten sind insbesondere:

Link up/down,
ausgehandelte Geschwindigkeit,
Duplex,
CRC- oder FCS-Fehler,
Eingabe- und Ausgabefehler,
verworfene Pakete,
Queue Drops,
Carrier-Fehler,
Link-Flaps,
neu ausgehandelte Verbindung,
steigende Fehlerdifferenz zwischen zwei Messzeitpunkten.

Absolute Zählerstände reichen nicht aus. Entscheidend ist, ob und wann die Zähler während des Fehlers gestiegen sind.

14. Switchport und Access Point überwachen

Auf der Netzwerkkomponente sollten mindestens geprüft werden:

Portstatus,
letzter Statuswechsel,
Anzahl Link-Flaps,
Speed und Duplex,
CRC-/FCS-Fehler,
Input Errors,
Output Errors,
Discards,
Queue Drops,
Broadcast- und Multicast-Anteil,
PoE-Status,
Temperatur,
Transceiverwerte,
VLAN-Zugehörigkeit,
Spanning-Tree-Ereignisse,
Port-Channel-Status,
MAC-Adresswechsel,
WLAN-An- und Abmeldungen,
Roaming-Ereignisse,
Deauthentication,
Signalstärke,
Wiederholungsrate,
Kanal- und Airtime-Auslastung.

Die Befehle und Zählerbezeichnungen unterscheiden sich je nach Hersteller und Modell. Ihre genaue Bedeutung muss anhand der jeweiligen Herstellerdokumentation geprüft werden.

15. Ereignisprotokolle unter Windows zeitlich eingrenzen

Beispiel für Systemereignisse eines bestimmten Zeitraums:

$Start = Get-Date "2026-08-02 09:10:00"
$End = Get-Date "2026-08-02 09:20:00"

Get-WinEvent -FilterHashtable @{
    LogName   = "System"
    StartTime = $Start
    EndTime   = $End
} |
    Select-Object TimeCreated, Id, LevelDisplayName,
                  ProviderName, Message |
    Sort-Object TimeCreated

Mehrere Protokolle können getrennt untersucht werden:

$Logs = @(
    "System",
    "Application",
    "Microsoft-Windows-DNS-Client/Operational",
    "Microsoft-Windows-WLAN-AutoConfig/Operational"
)

foreach ($Log in $Logs) {
    Get-WinEvent -FilterHashtable @{
        LogName   = $Log
        StartTime = $Start
        EndTime   = $End
    } -ErrorAction SilentlyContinue |
        Select-Object @{
            Name = "Log"
            Expression = { $Log }
        }, TimeCreated, Id, ProviderName, LevelDisplayName, Message
}

Nicht jedes Protokoll ist auf jedem System vorhanden oder aktiviert. Zusätzliche Protokollierung sollte kontrolliert und mit Blick auf Speicherbedarf, Datenschutz und Systemlast aktiviert werden.

16. Protokolle unter Linux zeitlich eingrenzen

journalctl \
  --since "2026-08-02 09:10:00" \
  --until "2026-08-02 09:20:00"

Nur Meldungen eines Dienstes:

journalctl \
  -u <dienst>.service \
  --since "2026-08-02 09:10:00" \
  --until "2026-08-02 09:20:00"

Kernelmeldungen:

journalctl \
  -k \
  --since "2026-08-02 09:10:00" \
  --until "2026-08-02 09:20:00"

Neue Meldungen fortlaufend beobachten:

journalctl -f

Zu berücksichtigen sind:

Zeitzone,
persistente oder flüchtige Speicherung,
Aufbewahrungsdauer,
Rotation,
Rate Limiting,
ausreichender Datenträgerspeicher,
Berechtigungen,
zentrale Weiterleitung.

Ein fehlender Eintrag beweist nicht automatisch, dass kein Fehler aufgetreten ist. Das Ereignis kann außerhalb der Aufbewahrungszeit liegen, in einem anderen Protokoll stehen oder nicht protokolliert worden sein.

17. Protokolle unter macOS zeitlich eingrenzen

log show \
  --start "2026-08-02 09:10:00" \
  --end "2026-08-02 09:20:00" \
  --style syslog

Nach Prozess filtern:

log show \
  --start "2026-08-02 09:10:00" \
  --end "2026-08-02 09:20:00" \
  --predicate 'process == "<prozess>"' \
  --style syslog

Fortlaufende Beobachtung:

log stream --style syslog

Die genaue Syntax und die verfügbaren Protokolldaten können sich zwischen macOS-Versionen unterscheiden.

18. Ringpuffer-Paketmitschnitt mit Dumpcap

Ein Ringpuffer bewahrt nur die letzten Aufzeichnungsdateien auf. Wenn der Fehler auftritt, muss die Aufzeichnung zeitnah gestoppt werden, bevor die relevanten Daten überschrieben werden.

Interfaces anzeigen:

dumpcap -D

Beispiel:

dumpcap \
  -i <interface> \
  -w intermittent.pcapng \
  -b duration:300 \
  -b files:12

Dieses Beispiel:

wechselt alle 300 Sekunden die Datei,
hält maximal 12 Dateien,
überschreibt anschließend die ältesten Dateien,
bewahrt damit ungefähr die letzten 60 Minuten auf.

Alternative Begrenzung nach Dateigröße:

dumpcap \
  -i <interface> \
  -w intermittent.pcapng \
  -b filesize:100000 \
  -b files:10

Hierbei ist filesize in Kilobyte angegeben.

Optionaler Capture-Filter:

dumpcap \
  -i <interface> \
  -f "host <ziel-ip> and port <port>" \
  -w intermittent.pcapng \
  -b duration:300 \
  -b files:12

Capture-Filter und Wireshark-Anzeigefilter besitzen unterschiedliche Syntax. Ein zu enger Filter kann die für die Ursachenanalyse benötigten Pakete ausschließen.

19. Ringpuffer-Paketmitschnitt mit tcpdump

tcpdump \
  -i <interface> \
  -s 0 \
  -G 300 \
  -W 12 \
  -w 'intermittent-%Y%m%d-%H%M%S.pcap'

Möglicher Filter:

tcpdump \
  -i <interface> \
  -s 0 \
  -G 300 \
  -W 12 \
  -w 'intermittent-%Y%m%d-%H%M%S.pcap' \
  'host <ziel-ip> and port <port>'

Die Kombination und genaue Wirkung der Rotationsoptionen kann von der installierten tcpdump-Version abhängen und muss vor dem produktiven Einsatz mit der lokalen Handbuchseite geprüft werden:

man tcpdump

Paketaufzeichnungen können personenbezogene Daten, Anmeldedaten, Sitzungsinformationen und vertrauliche Inhalte enthalten. Sie dürfen nur mit entsprechender Berechtigung erstellt, geschützt gespeichert und nach Abschluss kontrolliert gelöscht werden.

20. Windows-Paketmitschnitt mit Pktmon

Filter anzeigen:

pktmon filter list

Vorhandene Filter entfernen:

pktmon filter remove

Beispiel für eine begrenzte zirkuläre Aufzeichnung:

pktmon start `
  --capture `
  --comp nics `
  --pkt-size 0 `
  --file-name C:\Temp\intermittent.etl `
  --file-size 512 `
  --log-mode circular

Aufzeichnung stoppen:

pktmon stop

In PCAPNG umwandeln:

pktmon etl2pcap `
  C:\Temp\intermittent.etl `
  --out C:\Temp\intermittent.pcapng

Im zirkulären Modus werden bei Erreichen der festgelegten Größe ältere Ereignisse überschrieben. Die Aufzeichnung muss daher nach Auftreten des Fehlers zeitnah gestoppt werden.

Die verfügbaren Optionen unterscheiden sich zwischen Windows-Versionen. Vor dem Einsatz ist die lokale Hilfe zu prüfen:

pktmon start help
pktmon etl2pcap help

21. Monitoringauflösung passend wählen

Ein Monitoringintervall von fünf Minuten kann einen Fehler übersehen, der nur 20 Sekunden dauert.

Beispiel:

09:10:00 Messung erfolgreich
09:12:15 Fehler beginnt
09:12:40 Fehler endet
09:15:00 Messung erfolgreich

Das Monitoring zeigt keinen Ausfall, obwohl der Dienst 25 Sekunden nicht verfügbar war.

Mögliche Maßnahmen:

kürzeres Prüfintervall,
aktiver Diensttest statt nur Ping,
mehrere Messpunkte,
zeitlich begrenzte höhere Auflösung,
Event- oder Trap-Auswertung,
Aufzeichnung von Minimal-, Maximal- und Durchschnittswerten,
Perzentile statt ausschließlich Mittelwerte,
Statuswechsel sofort protokollieren,
Fehlerzähler als Differenz erfassen,
Rohdaten ausreichend lange aufbewahren.

Eine höhere Auflösung erzeugt mehr Last, Daten und Warnmeldungen. Sie sollte gezielt für die betroffene Komponente und einen begrenzten Zeitraum verwendet werden.

22. Welche Messwerte langfristig hilfreich sind

Client

CPU,
RAM,
Datenträgerlatenz,
Netzwerkstatus,
Linkgeschwindigkeit,
WLAN-Signal,
verwendeter Access Point,
DHCP-Lease,
DNS-Server,
VPN-Status,
Ereignisprotokolle.

Switch und Router

Interface up/down,
Fehler und Discards,
Auslastung,
Queue Drops,
Port-Channel-Status,
Routingnachbarn,
CPU,
RAM,
Temperatur,
Stromversorgung.

Firewall und VPN

Sitzungsanzahl,
NAT-Auslastung,
CPU,
RAM,
Paketverlust,
Drops,
Tunnelstatus,
Rekeying,
Failover,
Sicherheitsereignisse.

Server

CPU pro Prozess,
RAM,
Paging oder Swapping,
Datenträgerlatenz,
I/O-Wait,
Netzwerkfehler,
offene Verbindungen,
Queue,
Anwendungsthreads,
Connection Pools,
Datenbanklocks,
Dienstneustarts.

WLAN

Signalstärke,
Signal-Rausch-Verhältnis,
Kanal,
Airtime,
Wiederholungsrate,
Roaming,
Deauthentication,
Access-Point-Auslastung,
Uplinkstatus.

23. Ablaufzeiten und regelmäßige Erneuerungen prüfen

Sporadische Fehler können entstehen, wenn ein regelmäßig erneuerter Zustand abläuft.

Zu prüfen sind:

DHCP-Lease,
DNS-TTL,
ARP- und Neighbor-Cache,
Kerberos-Ticket,
OAuth- oder Anwendungstoken,
Websitzung,
Cookie,
Firewall-Session,
NAT-Zuordnung,
Load-Balancer-Persistenz,
VPN-SA und Rekeying,
Zertifikatsgültigkeit,
CRL- oder OCSP-Erreichbarkeit,
Kennwortablauf,
Maschinenkennwort,
Connection Pool,
Idle-Timeout,
Keepalive,
Lease eines verteilten Locks.

Beispiel:

Fehlerabstand: ungefähr 60 Minuten
Sitzungs-Timeout: 60 Minuten

Diese Übereinstimmung begründet eine Hypothese, beweist sie aber noch nicht. Der tatsächliche Ablauf und die anschließende Erneuerung müssen in Protokollen oder Paketdaten bestätigt werden.

24. Geplante Jobs und Wartungsarbeiten korrelieren

Zu untersuchen sind:

Backuppläne,
Snapshots,
Virenscans,
Patchmanagement,
Softwareverteilung,
Datenbankwartung,
Logrotation,
Replikation,
Synchronisation,
Indexierung,
Cronjobs,
systemd-Timer,
Windows-Aufgabenplanung,
Cloud-Automationen,
Container-Restarts,
Zertifikatserneuerung,
DHCP- oder DNS-Bereinigung,
Reportingjobs,
geplante Providerarbeiten.

Windows

Get-ScheduledTask |
    Select-Object TaskPath, TaskName, State

Letzte und nächste Ausführung:

Get-ScheduledTask |
    Get-ScheduledTaskInfo |
    Select-Object TaskName, LastRunTime, LastTaskResult, NextRunTime

Linux

systemctl list-timers --all

Zusätzlich können je nach System Cron-Konfigurationen und deren Protokolle relevant sein.

Nur autorisierte Konfigurationen dürfen eingesehen werden. Aufgaben sollten nicht allein wegen einer zeitlichen Überschneidung deaktiviert werden.

25. Temperatur, Strom und physische Umgebung berücksichtigen

Kurzzeitige Ausfälle können durch physische Bedingungen verursacht werden.

Zu prüfen sind:

Gerätetemperatur,
Lüfterstatus,
Netzteilstatus,
PoE-Leistung,
USV-Ereignisse,
Spannungsschwankungen,
transceiverbezogene Warnungen,
Tür- oder Racktemperatur,
Kabelbewegung,
Feuchtigkeit,
Außenleitung,
Bauarbeiten,
Funkstörungen,
Neustarts nach Stromverlust.

Typisches Muster:

Hohe Last
→ Temperatur steigt
→ Schnittstelle oder Gerät fällt kurzzeitig aus
→ automatische Wiederherstellung
→ Untersuchung erfolgt später bei normaler Temperatur

Ein Neustart kann Temperatur-, Speicher- und Fehlerzustände zurücksetzen und dadurch wichtige Beweise beseitigen.

26. Änderungen und Deployments berücksichtigen

Zu dokumentieren sind:

Zeitpunkt der Änderung,
betroffene Systeme,
vorherige Version,
neue Version,
geänderte Konfiguration,
verantwortlicher Change,
Rollbackmöglichkeit,
erste beobachtete Störung,
weitere abhängige Systeme.

Mögliche Änderungen:

Treiberupdate,
Firmwareupdate,
Betriebssystemupdate,
Firewallregel,
Routingänderung,
DNS-Änderung,
Zertifikatswechsel,
Anwendungsversion,
Datenbankschema,
Proxykonfiguration,
Load-Balancer-Pool,
VLAN-Änderung,
WLAN-Kanalplanung,
Container-Image,
Ressourcenlimit.

„Seit dem Update“ ist eine wichtige Beobachtung, aber noch kein technischer Nachweis. Die fehlerhafte Version oder Einstellung muss durch Vergleich, Protokoll oder kontrollierten Rollback bestätigt werden.

27. Daten auf einer gemeinsamen Zeitleiste korrelieren

Beispiel:

Uhrzeit	Client	Switch	Firewall	Server
09:14:31	Anwendung startet Anfrage	Port aktiv	Sitzung angelegt	Anfrage empfangen
09:14:34	wartet auf Antwort	Output Drops steigen	Weiterleitung erfolgt	Datenträgerlatenz steigt
09:14:37	Timeout	Port weiterhin aktiv	Sitzung beendet	Anwendung antwortet verspätet
09:15:02	erneuter Versuch	Zähler stabil	neue Sitzung	Antwort normal

Erst durch die gemeinsame Zeitleiste wird sichtbar, dass der Clienttimeout mit der erhöhten Datenträgerlatenz zusammenfällt.

Zu korrelieren sind:

Benutzeraktion,
Clientprotokoll,
DNS-Antwort,
Paketmitschnitt,
Switchport,
Access Point,
Firewall,
VPN-Gateway,
Load Balancer,
Reverse Proxy,
Serverbetriebssystem,
Anwendung,
Datenbank,
Storage,
Hypervisor,
Providerereignis.

Zeitangaben müssen auf dieselbe Zeitzone oder eine eindeutig dokumentierte Referenz umgerechnet werden.

28. Ereignisgesteuerte Datensicherung

Wenn der Benutzer den Fehler bemerkt, sollte ein festgelegtes Verfahren ausgelöst werden.

Beispiel:

1. genaue Uhrzeit notieren;
2. Screenshot erstellen;
3. betroffene Aktion nicht mehrfach unkontrolliert wiederholen;
4. Diagnosemarkierung oder Ticket auslösen;
5. laufenden Ringpuffer zeitnah stoppen;
6. Clientzustand sichern;
7. relevante Server- und Netzwerkprotokolle exportieren;
8. Monitoringdaten für den Zeitraum schützen;
9. Vergleichssystem prüfen;
10. Dateien eindeutig beschriften.

Beispiel für eine Markierungsdatei unter PowerShell:

$Time = Get-Date -Format "yyyy-MM-ddTHH-mm-ss.fffK"
"Fehler durch Benutzer beobachtet: $Time" |
    Set-Content ".\incident-marker-$Time.txt"

Beispiel unter Bash:

timestamp="$(date '+%Y-%m-%dT%H-%M-%S%z')"
printf 'Fehler durch Benutzer beobachtet: %s\n' "$timestamp" \
  > "incident-marker-$timestamp.txt"

Der Marker liefert keine Ursache, erleichtert aber das Auffinden des relevanten Zeitraums.

29. Praxisfall A: Verbindung bricht ungefähr jede Stunde ab

Symptom

eine Webanwendung trennt den Benutzer unregelmäßig,
der Fehler tritt meistens nach längerer Nutzung auf,
Netzwerk und Server bleiben erreichbar,
eine erneute Anmeldung funktioniert sofort.

Prüfung

genaue Sitzungsdauer erfassen.
Browser-, Proxy- und Anwendungsprotokolle vergleichen.
Token- und Sitzungsablauf kontrollieren.
Firewall- und Load-Balancer-Timeout berücksichtigen.
Zeitpunkt der letzten Benutzeraktivität dokumentieren.
Ablauf und Erneuerung im Netzwerk- oder Anwendungsprotokoll prüfen.
funktionierenden Benutzer oder Client vergleichen.

Mögliche Ursache

Die Anwendung erneuert ein ablaufendes Token nicht korrekt. Nach Ablauf wird die nächste Anfrage abgelehnt.

Nachprüfung

Sitzung bleibt über den bisherigen Fehlerzeitpunkt hinaus aktiv,
Token wird ordnungsgemäß erneuert,
keine zusätzlichen Anmeldefehler entstehen,
Firewall und Netzwerk bleiben unverändert unauffällig,
Ursache und Korrektur sind dokumentiert.

30. Praxisfall B: Switchport fällt kurzzeitig aus

Symptom

ein Client verliert gelegentlich für einige Sekunden die Verbindung,
anschließend funktioniert die Verbindung automatisch wieder,
spätere Pingtests sind unauffällig,
andere Clients sind nicht betroffen.

Prüfung

Client- und Switchzeit synchronisieren.
Linkstatus kontinuierlich protokollieren.
Switchportereignisse auswerten.
Fehlerzähler vor und nach dem Ereignis vergleichen.
Kabel und Steckverbindungen kontrollieren.
Energiespar- und Treibereinstellungen berücksichtigen.
kontrollierten Kabel- oder Portvergleich durchführen.

Mögliche Ursache

Eine beschädigte Steckverbindung verursacht kurzzeitige Link-Flaps.

Nachprüfung

keine weiteren Link-Flaps,
Fehlerzähler steigen nicht,
Verbindung bleibt unter kontrollierter Last stabil,
Vergleich über einen ausreichend langen Zeitraum,
getauschte Komponente und Messergebnisse dokumentiert.

31. Praxisfall C: Dienst jeden Morgen kurz langsam

Symptom

die Anwendung ist täglich zwischen 08:00 und 08:10 Uhr langsam,
Netzwerkdurchsatz und Paketverlust sind unauffällig,
Zeit bis zum ersten Byte steigt,
danach normalisiert sich der Dienst.

Prüfung

Anwendungszeiten kontinuierlich erfassen.
Serverressourcen im betroffenen Zeitraum prüfen.
geplante Aufgaben und Backuppläne vergleichen.
Datenträgerlatenz und Datenbanklocks untersuchen.
Proxy- und Anwendungsprotokolle korrelieren.
Zustand außerhalb des Zeitfensters vergleichen.
Job nicht ungeprüft deaktivieren.

Mögliche Ursache

Ein täglicher Datenbankjob erzeugt hohe Datenträgerlast und konkurriert mit den Anwendungsabfragen.

Nachprüfung

Job wird in einem vorgesehenen Wartungsfenster ausgeführt oder kontrolliert angepasst,
Datenträgerlatenz bleibt während der Nutzungszeit normal,
Zeit bis zum ersten Byte ist stabil,
ursprünglicher Geschäftsprozess funktioniert,
Backup- oder Wartungsziel bleibt erfüllt.

32. Praxisfall D: WLAN-Unterbrechung nur beim Standortwechsel

Symptom

Verbindung funktioniert an festen Standorten,
beim Wechsel zwischen zwei Gebäudebereichen entstehen kurze Unterbrechungen,
der Client verbindet sich anschließend automatisch erneut,
Ethernet ist nicht betroffen.

Prüfung

genauen Weg und Zeitpunkt dokumentieren.
verwendeten Access Point vor und nach dem Fehler erfassen.
Roaming- und Deauthentication-Ereignisse prüfen.
Signalstärke und Überlappung untersuchen.
Authentifizierungsdauer berücksichtigen.
Kanal- und Airtime-Auslastung prüfen.
Vergleich mit anderem Client durchführen.

Mögliche Ursache

Der Client hält zu lange an einem schwächer werdenden Access Point fest und wechselt verspätet zur benachbarten Funkzelle.

Nachprüfung

Roaming erfolgt innerhalb des vorgesehenen Bereichs,
Unterbrechungszeit ist reduziert,
andere Clients und Funkzellen funktionieren weiterhin,
Änderungen entsprechen der WLAN-Planung,
Messwerte vor und nach der Änderung sind dokumentiert.

33. Ungeeignete Sofortmaßnahmen

Problematisch sind insbesondere:

Systeme sofort neu starten,
mehrere Komponenten gleichzeitig verändern,
Protokolle erst lange nach dem Fehler prüfen,
Benutzerzeitangaben ungeprüft übernehmen,
einen erfolgreichen Ping als Gegenbeweis verwenden,
Monitoringmittelwerte ohne Rohdaten bewerten,
Protokollierung unbegrenzt aktivieren,
Mitschnitte ohne Größenbegrenzung erstellen,
Capture-Filter zu eng setzen,
alte Ringpufferdateien versehentlich überschreiben,
Firewalls oder Sicherheitsfunktionen pauschal deaktivieren,
geplante Jobs allein wegen zeitlicher Überschneidung abschalten,
Treiber oder Firmware ohne Vergleich austauschen,
Uhren während der Untersuchung manuell verändern,
vertrauliche Protokolle ungeschützt speichern,
einen zeitlichen Zusammenhang sofort als Ursache darstellen,
nur den betroffenen Client untersuchen,
nur Netzwerkdaten betrachten und Server oder Anwendung ignorieren.

34. Vollständige Prüfreihenfolge

Symptom eindeutig beschreiben.
genaue Fehlermeldung sichern.
Beginn und Ende dokumentieren.
Zeitzone erfassen.
Benutzer, Client und Standort bestimmen.
Quelle, Ziel, Port und Anwendung dokumentieren.
betroffene und nicht betroffene Systeme bestimmen.
Häufigkeit und bisherige Zeitpunkte sammeln.
Muster nach Uhrzeit, Dauer und Last suchen.
Systemzeiten aller Beteiligten kontrollieren.
Vergleichssystem festlegen.
geeignete Messintervalle bestimmen.
Gateway und Ziel kontinuierlich prüfen.
betroffenen TCP-Dienst überwachen.
DNS-Antworten protokollieren.
Anwendungszeiten erfassen.
Interfacezustand und Fehlerzähler aufzeichnen.
Switchport oder Access Point überwachen.
Serverressourcen protokollieren.
relevante Ereignisprotokolle sichern.
zentrale Protokollierung und Aufbewahrung prüfen.
bei Bedarf autorisierten Ringpuffer-Mitschnitt starten.
Speicherbedarf und Datenschutz berücksichtigen.
Verfahren zum Markieren des Fehlerzeitpunkts festlegen.
bei Auftreten des Fehlers Ringpuffer sichern.
Daten vor, während und nach dem Ereignis vergleichen.
DHCP-, DNS-, Token-, Sitzungs- und Idle-Zeiten prüfen.
geplante Jobs, Backups, Scans und Updates korrelieren.
Temperatur, Stromversorgung und physische Umgebung berücksichtigen.
Provider- und Wartungsereignisse prüfen.
Änderungen und Deployments berücksichtigen.
gemeinsame Zeitleiste erstellen.
konkrete Hypothese formulieren.
genau eine kontrollierbare Änderung durchführen.
dieselben Messungen weiterlaufen lassen.
ausreichend lange Nachbeobachtung durchführen.
ursprüngliche Funktion erneut prüfen.
Vergleichssysteme kontrollieren.
temporäre Diagnosekonfiguration entfernen.
Ursache, Maßnahme und Nachweis dokumentieren.
dauerhaftes Monitoring oder Prävention festlegen.

35. Dokumentationsbeispiel

Ticket: INC-20804
Zeitraum der Untersuchung: 02.08.2026 bis 05.08.2026
Betroffen: Client-WS-17, Ethernet, Switch SW-F2-03, Port 18
Nicht betroffen: weitere Clients desselben VLANs
Ziel: fileserver.example.test, TCP 445

Symptom:
Der Client verliert ein- bis dreimal täglich für ungefähr 5 bis 15 Sekunden
den Zugriff auf den Dateiserver. Anschließend funktioniert der Zugriff ohne
Benutzeraktion wieder.

Erfasste Fehlerzeitpunkte:
- 02.08.2026, 10:17:42 bis 10:17:51 Uhr
- 03.08.2026, 14:32:08 bis 14:32:19 Uhr
- 05.08.2026, 09:06:14 bis 09:06:23 Uhr

Messungen:
- kontinuierlicher Ping zu Gateway und Dateiserver
- TCP-Prüfung auf Port 445
- Interfacezähler des Clients
- Switchportstatus und Fehlerzähler
- Windows-Systemereignisse
- begrenzter Ringpuffer-Paketmitschnitt
- Serverressourcen und SMB-Protokolle

Beobachtung:
Zum jeweiligen Fehlerzeitpunkt meldete der Switch einen kurzen Linkverlust
an Port 18. Gleichzeitig wechselte das Clientinterface in den Zustand
„Disconnected“. Gateway und Server waren für andere Clients erreichbar.
Am Switchport stiegen zusätzlich die physischen Fehlerzähler.

Hypothese:
Die physische Verbindung zwischen Client und Switch ist instabil.

Kontrollierte Änderung:
Das Patchkabel wurde durch ein geprüftes Kabel ersetzt. Client, Switchport,
Treiber und Serverkonfiguration blieben unverändert.

Nachprüfung:
- sieben Tage kontinuierliche Beobachtung
- keine weiteren Link-Flaps
- keine steigenden physischen Fehlerzähler
- Gateway und Dateiserver durchgehend erreichbar
- ursprünglicher Dateizugriff funktioniert
- andere Systeme unverändert fehlerfrei

Ursache:
Beschädigtes Patchkabel mit sporadischer Unterbrechung.

Prävention:
- Switchport-Flaps zentral überwachen
- steigende physische Fehlerzähler alarmieren
- Fehlerzeitpunkte im Ticket immer sekundengenau dokumentieren

36. Checkliste „Fehler tritt nur manchmal auf“

37. Schnellreferenz

Beobachtung	wahrscheinlicher Untersuchungsbereich
Fehler immer zur gleichen Uhrzeit	Job, Backup, Scan, Update oder Provider
Fehler nach fester Laufzeit	Lease, Token, Session, NAT, Firewall oder VPN
Fehler nach Inaktivität	Idle-Timeout, Energiesparen oder Sitzung
nur ein Client betroffen	Client, Kabel, Treiber, Port oder Benutzerprofil
alle Clients eines Standorts betroffen	Uplink, WAN, Firewall, Strom oder Provider
nur WLAN betroffen	Funkumgebung, Roaming, Airtime oder Access Point
nur beim Standortwechsel	Roaming, Authentifizierung oder Funkabdeckung
nur unter Last	CPU, RAM, Storage, Queue, Uplink oder Pool
nur nachts	Backup, Snapshot, Wartung, Scan oder Replikation
Linkstatus wechselt kurz	Kabel, Port, Netzwerkkarte, Strom oder Treiber
Fehlerzähler steigen	physischer Link, Queue, Überlastung oder Hardware
Netzwerk normal, Anwendung hängt	Anwendung, Backend, Datenbank oder Storage
nur einzelne Ziel-IP fehlerhaft	Load Balancer, Backend oder Zielpfad
nur nach Aufwachen	Treiber, DHCP, DNS, VPN oder Energiesparmodus
nur über VPN	Tunnel, Rekeying, MTU, Gateway oder Route
Fehler verschwindet nach Neustart	Ressourcen, Speicherleck, Zustand oder Dienst
Monitoring zeigt nichts	Intervall zu groß, falscher Test oder fehlende Rohdaten
Logs zeigen nichts	falsches Protokoll, Rotation, Zeitabweichung oder fehlende Erfassung
Paketmitschnitt enthält Ereignis nicht	Filter, falsches Interface oder Überschreibung
zeitlicher Zusammenhang mit Job	mögliche Korrelation, Ursache noch zu beweisen
Problem tritt bei Temperaturanstieg auf	Kühlung, Netzteil, Transceiver oder Hardware
regelmäßige DNS-Fehler	Resolver, TTL, Cache, Netzwerkpfad oder DNS-Server
regelmäßige Abmeldung	Token, Sitzung, Cookie, Proxy oder Load Balancer
kurze Ausfälle ohne Linkverlust	Dienst, Routing, Firewall, Queue oder Server
andere Clients funktionieren	gemeinsamer Server nicht automatisch ausgeschlossen, aber Clientpfad priorisieren

Merksatz

Sporadische Fehler werden selten durch einen einzelnen nachträglichen Test gefunden. Entscheidend sind sekundengenaue Zeitstempel, kontinuierliche Messungen, begrenzte Ringpuffer, ausreichend lange Protokollaufbewahrung und eine gemeinsame Zeitleiste von Client, Netzwerk, Server und Anwendung. Erst wenn Messdaten den Fehler vor, während und nach einer kontrollierten Änderung zeigen, ist die Ursache belastbar nachgewiesen.

Quellen und weiterführende Dokumentation

6.7 Anmeldung an der Domäne geht nicht

Wenn sich ein Benutzer nicht an einer Active-Directory-Domäne anmelden kann, liegt die Ursache nicht automatisch an einem falschen Kennwort.

Eine Domänenanmeldung benötigt mehrere funktionierende Komponenten:

der Client besitzt eine gültige Netzwerkkonfiguration,
der Client verwendet die vorgesehenen internen DNS-Server,
die Active-Directory-Domäne kann über DNS gefunden werden,
ein geeigneter Domain Controller ist erreichbar,
Client und Domain Controller besitzen ausreichend übereinstimmende Systemzeiten,
das Benutzerkonto ist vorhanden und verwendbar,
das Computerkonto und der sichere Kanal zur Domäne funktionieren,
Kerberos oder gegebenenfalls NTLM kann die Anmeldung verarbeiten,
Gruppenrichtlinien und Benutzerprofile verhindern die Anmeldung nicht,
die Domain Controller replizieren die benötigten Informationen ordnungsgemäß.

Die sichtbare Meldung am Client beschreibt häufig nur das Ergebnis. Die eigentliche Ursache kann bei DNS, Uhrzeit, Netzwerk, Benutzerkonto, Computerkonto, Domain Controller, Replikation oder Richtlinien liegen.

1. Typische Fehlermeldungen

Mögliche Meldungen sind:

Der Benutzername oder das Kennwort ist falsch.

Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar.

Die Sicherheitsdatenbank auf dem Server enthält kein Computerkonto für diese Arbeitsstationsvertrauensstellung.

Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.

Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden.

Das referenzierte Konto ist momentan gesperrt und kann nicht für die Anmeldung verwendet werden.

Die Anmeldung ist aufgrund einer Kontoeinschränkung nicht möglich.

Die Anmeldemethode, die Sie verwenden möchten, ist nicht zulässig.

Ihr Konto wurde deaktiviert. Wenden Sie sich an den Systemadministrator.

Das Kennwort des Benutzers muss vor der Anmeldung geändert werden.

Wir können Sie mit diesen Anmeldeinformationen nicht anmelden, weil Ihre Domäne nicht verfügbar ist.

Der genaue deutsche Wortlaut kann sich je nach Windows-Version unterscheiden. Deshalb sollten zusätzlich Fehlercode, Ereignis-ID, Uhrzeit und die englische Originalmeldung dokumentiert werden, wenn sie in einem Protokoll vorhanden ist.

2. Auswirkungen

Mögliche Auswirkungen:

ein einzelner Benutzer kann sich nicht anmelden,
alle Benutzer eines Clients sind betroffen,
mehrere Clients eines Standorts sind betroffen,
neue Benutzer können sich nicht anmelden,
bisher angemeldete Benutzer können sich nur mit zwischengespeicherten Anmeldedaten anmelden,
Gruppenrichtlinien werden nicht verarbeitet,
Netzlaufwerke und Drucker werden nicht verbunden,
Kerberos-Authentifizierung funktioniert nicht,
Dienste mit Domänenkonten starten nicht,
ein Computer verliert seine Vertrauensstellung,
Kennwortänderungen werden nicht überall erkannt,
Anmeldungen funktionieren abhängig vom erreichten Domain Controller,
Remoteanmeldungen funktionieren, lokale Konsolenanmeldungen jedoch nicht oder umgekehrt.

3. Sicherheits- und Betriebswarnung

Bei der Untersuchung dürfen Benutzerkonten, Computerkonten, Domain Controller und Vertrauensstellungen nicht unkontrolliert verändert werden.

Insbesondere sollten nicht vorschnell:

Benutzerkennwörter zurückgesetzt,
Konten entsperrt, ohne die Sperrquelle zu untersuchen,
Computerkonten gelöscht,
Clients aus der Domäne entfernt,
Domain Controller neu gestartet,
DNS-Einträge manuell gelöscht,
Kerberos-Tickets produktiver Sitzungen entfernt,
Gruppenrichtlinien deaktiviert,
Sicherheitsrichtlinien abgeschwächt,
Replikationen erzwungen,
Zeiteinstellungen manuell verändert,
lokale Administratorzugänge neu angelegt,
Protokolle gelöscht werden.

Das Entfernen eines Computers aus der Domäne und das anschließende erneute Hinzufügen ist keine Ursachenanalyse. Dadurch können Beweise verloren gehen und zusätzliche Probleme mit Profilen, Zertifikaten, Gruppenrichtlinien, BitLocker, Softwareverteilung oder Verwaltungsdiensten entstehen.

Korrekturmaßnahmen sind nur mit entsprechender Berechtigung und nach Sicherung der Diagnosedaten durchzuführen.

4. Zuerst den Umfang bestimmen

Die wichtigste erste Frage lautet:

Ist nur ein Benutzer, nur ein Client oder ein größerer Teil der Domäne betroffen?

Beobachtung	zuerst zu untersuchender Bereich
ein Benutzer kann sich an keinem Client anmelden	Benutzerkonto, Kennwort, Sperre, Ablauf, Anmelderechte
ein Benutzer kann sich nur an einem Client nicht anmelden	Client, lokales Profil, Anmeldeformat, Richtlinie, gespeicherte Daten
kein Domänenbenutzer kann sich an einem Client anmelden	DNS, Netzwerk, Uhrzeit, sicherer Kanal, Computerkonto
mehrere Clients eines Standorts sind betroffen	DNS, DHCP, VLAN, Standort-Uplink, Firewall, erreichbarer Domain Controller
alle Benutzer der Domäne sind betroffen	Domain Controller, DNS, Replikation, Zeitdienst, zentrale Infrastruktur
Anmeldung funktioniert offline, aber nicht im Firmennetz	erreichter Domain Controller, Kontostatus, Kennwort, DNS oder sicherer Kanal
Anmeldung funktioniert im Firmennetz, aber nicht über VPN	VPN-Verbindungszeitpunkt, DNS, Routing, Firewall, Gerätezertifikat
alte Anmeldedaten funktionieren offline	zwischengespeicherte Domänenanmeldung
neues Kennwort funktioniert nur an manchen Clients	Replikation, erreichter Domain Controller, gespeicherte Anmeldedaten
lokale Anmeldung funktioniert, Domänenanmeldung nicht	Domänenpfad, Benutzerkonto, DNS, Domain Controller oder Vertrauensstellung
Anmeldung funktioniert mit einem anderen Domänenbenutzer	Benutzerkonto oder benutzerspezifische Richtlinie priorisieren
Anmeldung funktioniert nach Neustart gelegentlich wieder	Netzwerkstart, DNS, Dienstreihenfolge, sicherer Kanal oder erreichter DC

Ein einzelner erfolgreicher Anmeldeversuch mit einem anderen Benutzer beweist nicht, dass die gesamte Domäneninfrastruktur fehlerfrei ist. Der andere Benutzer könnte zwischengespeicherte Anmeldedaten verwenden oder einen anderen Authentifizierungspfad besitzen.

5. Mindestinformationen erfassen

Vor einer Änderung sollten mindestens dokumentiert werden:

Ticket:
Datum und genaue Uhrzeit:
Zeitzone:
Benutzerkonto:
Clientname:
Client-IP:
Standort:
Verbindung: Ethernet / WLAN / VPN
Domäne:
verwendetes Anmeldeformat:
genauer Meldungstext:
Fehlercode:
Anmeldung lokal oder remote:
erstmalige oder wiederkehrende Anmeldung:
anderer Benutzer am selben Client getestet:
derselbe Benutzer an anderem Client getestet:
lokale Anmeldung möglich:
Netzwerk vor der Anmeldung verfügbar:
zuletzt erfolgreiche Anmeldung:
kürzlich geändertes Kennwort:
zuletzt installierte Updates oder Änderungen:

Kennwörter dürfen nicht in das Ticket oder Diagnoseprotokoll geschrieben werden.

6. Lokales Konto und Domänenkonto unterscheiden

Die Eingabe auf dem Anmeldebildschirm kann unterschiedliche Kontotypen ansprechen.

Domänenkonto als UPN

benutzer@ad.example.test

Domänenkonto im älteren Format

EXAMPLE\benutzer

Lokales Konto

.\benutzer

oder:

CLIENT01\benutzer

.\benutzer bezeichnet ein lokales Konto des aktuellen Computers. Es ist keine Domänenanmeldung.

Eine Anmeldung kann fehlschlagen, weil:

versehentlich das lokale Konto ausgewählt wurde,
eine falsche Domäne vorangestellt wurde,
der UPN-Suffix nicht zum Benutzerkonto passt,
ein gleichnamiges lokales Konto existiert,
der zuletzt verwendete Anmeldekontext übernommen wurde,
die Tastaturbelegung auf dem Anmeldebildschirm abweicht.

Vor tieferer Diagnose sollte deshalb feststehen, welches Konto Windows tatsächlich authentifizieren soll.

7. Gesicherte Anmeldung und zwischengespeicherte Anmeldedaten

Windows kann erfolgreiche Domänenanmeldungen zwischenspeichern. Dadurch kann sich ein Benutzer möglicherweise an einem Notebook anmelden, obwohl momentan kein Domain Controller erreichbar ist.

Das bedeutet:

Anmeldung erfolgreich
≠
Domain Controller war erreichbar

Bei einer zwischengespeicherten Anmeldung können anschließend trotzdem ausfallen:

Gruppenrichtlinien,
Netzlaufwerke,
Domänendrucker,
Kerberos-Tickets,
Zugriff auf interne Anwendungen,
Kennwortänderungen,
Anmeldung mit einem erstmals verwendeten Konto.

Typische Hinweise auf eine zwischengespeicherte Anmeldung:

Anmeldung funktioniert ohne Netzwerk,
ein bereits bekannter Benutzer kann sich anmelden,
ein neuer Benutzer kann sich am selben Gerät nicht anmelden,
das neue Kennwort funktioniert nicht, das vorherige jedoch schon,
Domänenressourcen sind nach der Anmeldung nicht erreichbar,
Gruppenrichtlinien werden nicht aktualisiert.

Die Anzahl zwischengespeicherter Anmeldungen wird durch Sicherheitsrichtlinien bestimmt. Diese Einstellung sollte nicht allein zur Fehlerbehebung verändert werden.

8. Netzwerkstatus vor der Anmeldung berücksichtigen

Eine Domänenanmeldung kann erfolgen, bevor WLAN, VPN oder 802.1X vollständig verfügbar ist.

Zu prüfen sind:

ist das Netzwerkkabel angeschlossen,
ist der Switchport aktiv,
ist WLAN bereits am Anmeldebildschirm verbunden,
benötigt das WLAN zuerst eine Benutzeranmeldung,
verwendet der Client Maschinen- oder Benutzerzertifikate,
ist ein Pre-Logon-VPN erforderlich,
startet das VPN erst nach der Windows-Anmeldung,
erhält der Client rechtzeitig eine DHCP-Adresse,
wird ein falsches VLAN zugewiesen,
blockiert Network Access Control den Client,
benötigt der Netzwerkadapter nach dem Start ungewöhnlich lange,
wird durch Fast Startup ein fehlerhafter Netzwerkzustand übernommen.

Nach der Anmeldung kann der aktuelle Zustand geprüft werden:

Get-NetAdapter

Get-NetIPConfiguration

ipconfig /all

Wichtige Angaben:

IPv4-Adresse,
IPv6-Adresse,
Subnetzmaske oder Präfix,
Standardgateway,
DHCP-Server,
DNS-Server,
DNS-Suffix,
Lease-Zeitpunkt,
Adapterstatus,
Name der Verbindung.

Eine Adresse aus 169.254.0.0/16 weist bei IPv4 typischerweise darauf hin, dass keine reguläre DHCP-Konfiguration bezogen wurde. Sie beweist jedoch noch nicht, ob DHCP-Server, Relay, VLAN, Port oder Client die Ursache ist.

9. Erreichbarkeit schrittweise prüfen

Nach einer lokalen oder zwischengespeicherten Anmeldung kann der Netzwerkpfad untersucht werden.

Eigene Netzwerkkonfiguration

ipconfig /all

Standardgateway

Test-Connection -TargetName <gateway> -Count 4

Interner DNS-Server

Test-Connection -TargetName <dns-server> -Count 4

Domain Controller

Test-Connection -TargetName <dc-fqdn> -Count 4

Relevante TCP-Verbindungen

Test-NetConnection -ComputerName <dc-fqdn> -Port 53
Test-NetConnection -ComputerName <dc-fqdn> -Port 88
Test-NetConnection -ComputerName <dc-fqdn> -Port 389
Test-NetConnection -ComputerName <dc-fqdn> -Port 445

Ein erfolgreicher Ping beweist nicht, dass DNS, Kerberos, LDAP, SMB, RPC oder die Anmeldung funktioniert. Umgekehrt kann Ping durch eine Firewall blockiert sein, obwohl die benötigten Dienste erreichbar sind.

Active Directory verwendet mehrere Protokolle und dynamische RPC-Ports. Vier erfolgreiche Porttests ersetzen deshalb keine vollständige Prüfung des Domänenpfades.

10. DNS-Konfiguration des Clients prüfen

Active Directory ist in hohem Maß von DNS abhängig. Ein Domänenclient muss die DNS-Server verwenden, welche die Active-Directory-DNS-Zone und die zugehörigen Dienstressourceneinträge auflösen können.

Prüfen:

Get-DnsClientServerAddress

Get-DnsClientGlobalSetting

Get-DnsClient

Alternativ:

ipconfig /all

Verdächtig sind insbesondere:

ausschließlich ein öffentlicher DNS-Server,
DNS-Server des Internetrouters statt des vorgesehenen AD-DNS,
falsche DNS-Server durch statische Konfiguration,
falsche DNS-Server durch VPN oder DHCP,
unerwarteter DNS-Suffix,
veraltete DNS-Adressen,
nicht erreichbarer bevorzugter DNS-Server,
Split-DNS mit fehlenden internen Einträgen,
unterschiedliche Antworten verschiedener DNS-Server.

Öffentliche Resolver können Internetnamen auflösen, kennen aber normalerweise nicht die internen SRV-Einträge der Active-Directory-Domäne.

Eine funktionierende Auflösung von www.example.com beweist daher nicht, dass Active Directory über DNS gefunden werden kann.

11. DNS-Auflösung der Domäne prüfen

Domänenname auflösen

Resolve-DnsName -Name <ad-domain>

Domain-Controller-Dienst suchen

Resolve-DnsName `
  -Name "_ldap._tcp.dc._msdcs.<ad-domain>" `
  -Type SRV

Kerberos-Dienst suchen

Resolve-DnsName `
  -Name "_kerberos._tcp.<ad-domain>" `
  -Type SRV

Global Catalog suchen

Resolve-DnsName `
  -Name "_ldap._tcp.gc._msdcs.<forest-root-domain>" `
  -Type SRV

Mit nslookup:

nslookup -type=SRV _ldap._tcp.dc._msdcs.<ad-domain>

nslookup -type=SRV _kerberos._tcp.<ad-domain>

Erwartet werden SRV-Antworten mit geeigneten Domain Controllern. Anschließend müssen auch deren Hostnamen auflösbar sein:

Resolve-DnsName -Name <dc-fqdn>

Eine vorhandene SRV-Antwort reicht nicht aus, wenn:

der zurückgegebene Domain Controller nicht erreichbar ist,
sein Hostname auf eine falsche IP-Adresse zeigt,
ein veralteter Domain Controller eingetragen ist,
Firewall oder Routing die benötigten Dienste blockieren,
der Client einem falschen AD-Standort zugeordnet wird.

12. DNS-Cache kontrolliert untersuchen

Cache anzeigen:

ipconfig /displaydns

PowerShell:

Get-DnsClientCache

Der Cache kann Hinweise auf bereits verwendete Einträge liefern.

Erst nach Sicherung der relevanten Informationen kann für einen kontrollierten Vergleich der Clientcache geleert werden:

ipconfig /flushdns

Das Leeren des DNS-Caches ist eine Zustandsänderung. Wenn der Fehler nur sporadisch auftritt, kann dadurch ein wichtiger Hinweis auf einen falschen oder veralteten Eintrag verloren gehen.

Eine erfolgreiche Anmeldung nach dem Leeren beweist noch nicht, welcher DNS-Eintrag fehlerhaft war. Dafür müssen Antworten vor und nach der Änderung verglichen werden.

13. Domain Controller Locator prüfen

Windows verwendet den Domain Controller Locator, um einen geeigneten Domain Controller zu finden.

Domain Controller suchen

nltest /dsgetdc:<ad-domain>

Erzwungene erneute Suche

nltest /dsgetdc:<ad-domain> /force

Domain Controller eines AD-Standorts suchen

nltest /dsgetdc:<ad-domain> /site:<site-name>

Clientstandort anzeigen

nltest /dsgetsite

Liste der Domain Controller

nltest /dclist:<ad-domain>

Die Ausgabe von nltest /dsgetdc kann unter anderem zeigen:

gefundenen Domain Controller,
Adresse,
Domänen-GUID,
AD-Standort,
Eigenschaften wie LDAP, KDC, DNS oder Global Catalog.

Fehler wie:

ERROR_NO_SUCH_DOMAIN

oder:

DsGetDcName failed: Status = 1355

weisen darauf hin, dass kein geeigneter Domain Controller gefunden wurde. Die Ursache kann unter anderem bei DNS, Netzwerk, Firewall, AD-Standort, Dienstregistrierung oder Domain Controller liegen.

14. Verwendeten Anmeldeserver feststellen

Nach einer erfolgreichen Domänenanmeldung:

echo %LOGONSERVER%

PowerShell:

$env:LOGONSERVER

Zusätzlich:

whoami

whoami /user

whoami /groups

Der Wert von LOGONSERVER ist hilfreich, darf aber nicht als vollständiger Nachweis für jeden späteren Authentifizierungsvorgang betrachtet werden. Unterschiedliche Dienste können andere Domain Controller oder Kerberos-Dienstpfade verwenden.

Wenn die Anmeldung nur bei einem bestimmten Domain Controller fehlschlägt, sind besonders zu prüfen:

Replikation,
DNS-Registrierung,
Erreichbarkeit,
Uhrzeit,
SYSVOL und NETLOGON,
Kerberos,
Kontostand auf diesem DC,
AD-Standortzuordnung.

15. Systemzeit und Zeitzone prüfen

Kerberos ist auf ausreichend übereinstimmende Zeit angewiesen. Eine zu große Zeitabweichung kann die Authentifizierung verhindern.

Clientstatus

w32tm /query /status

Konfiguration

w32tm /query /configuration

Zeitquelle

w32tm /query /source

Vergleich mit einem Domain Controller

w32tm /stripchart /computer:<dc-fqdn> /dataonly /samples:10

Windows-Time-Service

Get-Service -Name W32Time

Zusätzlich dokumentieren:

Get-Date

Get-TimeZone

Zu prüfen sind:

Datum,
Uhrzeit,
Zeitzone,
Zeitquelle,
letzte erfolgreiche Synchronisierung,
Erreichbarkeit der Zeitquelle,
Zeithierarchie der Domäne,
Zustand des Windows-Zeitdienstes,
Zeit des Hypervisors bei virtuellen Maschinen.

Die Uhr darf während der Diagnose nicht unkontrolliert manuell verändert werden. Vor einer Korrektur sollten Status und Abweichung dokumentiert werden.

16. Benutzerkonto prüfen

Mit installiertem Active-Directory-PowerShell-Modul und ausreichender Berechtigung:

Get-ADUser -Identity <benutzer> `
  -Properties Enabled, LockedOut, PasswordExpired,
              PasswordLastSet, AccountExpirationDate,
              UserPrincipalName, SamAccountName,
              LastLogonDate, LogonWorkstations

Gezielt formatieren:

Get-ADUser -Identity <benutzer> `
  -Properties Enabled, LockedOut, PasswordExpired,
              PasswordLastSet, AccountExpirationDate,
              UserPrincipalName, LogonWorkstations |
    Select-Object SamAccountName,
                  UserPrincipalName,
                  Enabled,
                  LockedOut,
                  PasswordExpired,
                  PasswordLastSet,
                  AccountExpirationDate,
                  LogonWorkstations

Zu prüfen sind:

Konto vorhanden,
Konto aktiviert,
Konto gesperrt,
Konto abgelaufen,
Kennwort abgelaufen,
Kennwortänderung erforderlich,
korrekter Benutzerprinzipalname,
korrekter Anmeldename,
erlaubte Arbeitsstationen,
erlaubte Anmeldezeiten,
Smartcard- oder Zertifikatsanforderungen,
Mitgliedschaften in relevanten Gruppen,
wirksame Richtlinien und Anmelderechte.

LastLogonDate ist nicht für jede sekundengenaue Untersuchung geeignet. Je nach benötigter Genauigkeit müssen die entsprechenden Attribute und Ereignisprotokolle auf den relevanten Domain Controllern ausgewertet werden.

17. Kontosperre untersuchen

Ein Konto kann durch wiederholte fehlerhafte Anmeldeversuche gesperrt werden.

Mögliche Quellen:

Benutzer gibt mehrfach ein falsches Kennwort ein,
Smartphone verwendet ein altes Kennwort,
gespeicherte Anmeldeinformationen,
getrennte RDP-Sitzung,
Windows-Dienst mit Benutzerkonto,
geplante Aufgabe,
Netzlaufwerk,
Drucker,
VPN-Client,
WLAN-Authentifizierung,
Outlook oder andere Anwendung,
Skript,
Anwendungspool,
zweiter Computer,
Gerät außerhalb des Firmennetzes,
Angriffsversuch.

Kontostatus:

Get-ADUser -Identity <benutzer> -Properties LockedOut |
    Select-Object SamAccountName, LockedOut

Sperrereignisse auf einem Domain Controller:

Get-WinEvent -FilterHashtable @{
    LogName = "Security"
    Id      = 4740
} |
    Select-Object TimeCreated, Id, Message

Ereignis-ID 4740 zeigt eine Kontosperre. Das Ereignis kann Informationen über den aufrufenden Computer enthalten.

Nur das Entsperren des Kontos behebt eine wiederkehrende Sperrquelle nicht. Vor dem Entsperren sollten Zeitpunkt, Domain Controller, aufrufender Computer und vorausgehende Authentifizierungsfehler dokumentiert werden.

18. Kennwortänderung und Replikation berücksichtigen

Nach einer Kennwortänderung können Probleme entstehen, wenn:

ein Client noch das alte Kennwort verwendet,
gespeicherte Anmeldedaten nicht aktualisiert wurden,
ein Gerät dauerhaft alte Zugangsdaten sendet,
Domain Controller nicht ordnungsgemäß replizieren,
ein Standort nur einen fehlerhaften Domain Controller erreicht,
ein Dienstkontokennwort geändert wurde, die Dienstkonfiguration jedoch nicht,
das Benutzerkonto gesperrt wurde,
der Benutzer offline arbeitet und zwischengespeicherte Anmeldedaten verwendet.

Zu erfassen:

Zeitpunkt der Kennwortänderung:
System, an dem das Kennwort geändert wurde:
vermutlich beteiligter Domain Controller:
erstes Auftreten des Fehlers:
funktioniert altes Kennwort offline:
funktioniert neues Kennwort online:
funktioniert Anmeldung an anderem Client:
funktioniert Anmeldung an anderem Standort:

Kennwörter dürfen nicht testweise an mehreren Stellen verteilt oder protokolliert werden.

19. Computerkonto prüfen

Ein Domänencomputer besitzt in Active Directory ein eigenes Computerkonto.

Mit dem Active-Directory-PowerShell-Modul:

Get-ADComputer -Identity <computername> `
  -Properties Enabled, PasswordLastSet, LastLogonDate,
              DistinguishedName, DNSHostName

Formatierte Ausgabe:

Get-ADComputer -Identity <computername> `
  -Properties Enabled, PasswordLastSet, LastLogonDate,
              DistinguishedName, DNSHostName |
    Select-Object Name,
                  DNSHostName,
                  Enabled,
                  PasswordLastSet,
                  LastLogonDate,
                  DistinguishedName

Zu prüfen sind:

Computerkonto vorhanden,
Computerkonto aktiviert,
korrekter Name,
keine unerwarteten doppelten oder alten Objekte,
erwartete Organisationseinheit,
plausibler Zeitpunkt des Maschinenkennworts,
Client wurde nicht aus einem alten Snapshot wiederhergestellt,
Client wurde nicht geklont, ohne korrekt vorbereitet zu werden,
Computerkonto wurde nicht gelöscht und neu erstellt,
Clientname wurde nicht unsachgemäß geändert.

PasswordLastSet allein beweist nicht, dass der sichere Kanal funktioniert. Es ist nur ein Hinweis innerhalb der Gesamtanalyse.

20. Sicheren Kanal prüfen

Der sichere Kanal verbindet einen Domänenmitgliedscomputer mit der Domäne.

PowerShell auf einem Mitgliedscomputer

Test-ComputerSecureChannel -Verbose

Mit ausdrücklich angegebener Domäne:

Test-ComputerSecureChannel `
  -Server <dc-fqdn> `
  -Verbose

NLTEST

nltest /sc_query:<ad-domain>

Zusätzliche Informationen:

nltest /sc_verify:<ad-domain>

Je nach Systemrolle und verwendetem Werkzeug unterscheiden sich Bedeutung und Verhalten einzelner Prüfungen. Test-ComputerSecureChannel ist für Domänenmitgliedscomputer vorgesehen und sollte nicht als allgemeiner Zustandstest eines Domain Controllers verwendet werden.

Ein fehlerhafter sicherer Kanal kann Meldungen verursachen wie:

Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.

Mögliche Ursachen:

Maschinenkennwort stimmt zwischen Client und AD nicht überein,
Client wurde auf einen alten Snapshot zurückgesetzt,
Computerkonto wurde gelöscht oder neu angelegt,
replizierte Kontodaten sind inkonsistent,
Client wurde fehlerhaft geklont,
lange getrenntes oder zurückgesetztes System,
Wiederherstellung aus einem ungeeigneten Image,
DNS oder Netzwerk verhindert die Kontaktaufnahme.

21. Sicheren Kanal nur kontrolliert reparieren

Die folgenden Befehle verändern den Zustand und gehören nicht zur rein lesenden Diagnose.

PowerShell

Test-ComputerSecureChannel `
  -Repair `
  -Credential (Get-Credential) `
  -Verbose

Alternative:

Reset-ComputerMachinePassword `
  -Server <dc-fqdn> `
  -Credential (Get-Credential)

Eine Reparatur sollte nur erfolgen, wenn:

DNS und Netzwerk geprüft wurden,
die Uhrzeit korrekt ist,
das richtige Computerkonto identifiziert wurde,
der Fehler des sicheren Kanals bestätigt wurde,
erforderliche Berechtigungen vorhanden sind,
Auswirkungen und Rückfallmöglichkeit bekannt sind,
Diagnoseinformationen vorher gesichert wurden.

Nach der Reparatur müssen mindestens geprüft werden:

sicherer Kanal,
Neustartanforderung,
Domänenanmeldung,
Gruppenrichtlinien,
Kerberos-Tickets,
Zugriff auf Domänenressourcen,
Verwaltungs- und Sicherheitssoftware,
Ereignisprotokolle.

Das Entfernen und erneute Hinzufügen zur Domäne sollte erst nach nachvollziehbarer Diagnose und gemäß dem betrieblichen Verfahren erfolgen.

22. Kerberos-Tickets prüfen

Aktuelle Tickets des angemeldeten Sicherheitskontexts:

klist

Kerberos-Ticket-Granting-Tickets anzeigen:

klist tgt

Weitere Sitzungsinformationen:

klist sessions

Verfügbarer Domain Controller:

klist query_bind

Je nach Windows-Version und Sicherheitskontext können die verfügbaren Unterbefehle und sichtbaren Tickets variieren. Die lokale Hilfe ist zu prüfen:

klist ?

Zu untersuchen sind:

ist ein TGT vorhanden,
welcher KDC wurde verwendet,
stimmen Client- und Domänenname,
sind Tickets abgelaufen,
treten Kerberos-Fehler in den Ereignisprotokollen auf,
funktioniert DNS für den KDC,
stimmt die Uhrzeit,
ist der verwendete Dienstprinzipalname korrekt,
wird unerwartet NTLM statt Kerberos verwendet.

Tickets kontrolliert entfernen:

klist purge

klist purge verändert den Anmeldezustand der aktuellen Sitzung. Vorher sollten die vorhandenen Tickets dokumentiert werden. Eine erfolgreiche Funktion nach dem Purge beweist ohne Vergleich der vorherigen Tickets nicht automatisch die Ursache.

23. NTLM und Kerberos unterscheiden

Eine Windows-Domäne kann je nach Vorgang Kerberos oder NTLM verwenden.

Vereinfacht:

Bereich	typischer Hinweis
Kerberos-Vorauthentifizierung fehlgeschlagen	Ereignis 4771
Kerberos-TGT angefordert	Ereignis 4768
Kerberos-Dienstticket angefordert	Ereignis 4769
NTLM-Anmeldeinformationen geprüft	Ereignis 4776
Anmeldung auf Zielsystem fehlgeschlagen	Ereignis 4625
Konto gesperrt	Ereignis 4740

Ein Ereignis muss immer zusammen mit Zeitpunkt, Benutzer, Clientadresse, Anmeldetyp, Statuscode, Substatus und beteiligtem System bewertet werden.

24. Ereignis 4625 auswerten

Ereignis-ID 4625 bedeutet, dass eine Kontoanmeldung fehlgeschlagen ist. Es entsteht auf dem System, auf dem der Anmeldeversuch verarbeitet wurde.

Zeitlich begrenzte Abfrage:

$Start = Get-Date "2026-08-02 09:10:00"
$End = Get-Date "2026-08-02 09:20:00"

Get-WinEvent -FilterHashtable @{
    LogName   = "Security"
    Id        = 4625
    StartTime = $Start
    EndTime   = $End
} |
    Select-Object TimeCreated, Id, Message

Wichtige Felder können sein:

Kontoname,
Kontodomäne,
Anmelde-ID,
Anmeldetyp,
Fehlergrund,
Status,
Substatus,
Arbeitsstationsname,
Quellnetzwerkadresse,
Quellport,
Authentifizierungspaket,
beteiligter Prozess.

Häufige Anmeldetypen:

Anmeldetyp	Bedeutung
2	interaktive Anmeldung an der Konsole
3	Netzwerkanmeldung
4	Batch, beispielsweise geplante Aufgabe
5	Dienst
7	Entsperren
8	NetworkCleartext
9	NewCredentials
10	RemoteInteractive, beispielsweise RDP
11	CachedInteractive

Anmeldetyp 11 weist auf eine interaktive Anmeldung mit zwischengespeicherten Domäneninformationen hin. Er bedeutet nicht, dass während der Anmeldung ein Domain Controller erreicht wurde.

Status- und Substatuswerte müssen anhand der Microsoft-Dokumentation und des konkreten Ereignisses interpretiert werden.

25. Relevante Authentifizierungsereignisse

Auf Client, Mitgliedsserver und Domain Controllern können unter anderem relevant sein:

Ereignis-ID	allgemeine Bedeutung
4624	erfolgreiche Anmeldung
4625	fehlgeschlagene Anmeldung
4648	Anmeldung mit ausdrücklich angegebenen Anmeldeinformationen
4672	besondere Rechte wurden einer neuen Anmeldung zugewiesen
4722	Benutzerkonto aktiviert
4725	Benutzerkonto deaktiviert
4726	Benutzerkonto gelöscht
4738	Benutzerkonto geändert
4740	Benutzerkonto gesperrt
4767	Benutzerkonto entsperrt
4768	Kerberos-TGT angefordert
4769	Kerberos-Dienstticket angefordert
4770	Kerberos-Dienstticket erneuert
4771	Kerberos-Vorauthentifizierung fehlgeschlagen
4776	Anmeldeinformationen wurden über NTLM geprüft
5719	kein Domain Controller für eine sichere Sitzung verfügbar
5722	Authentifizierung der Sitzung beziehungsweise des Computerkontos fehlgeschlagen
5805	Sitzung eines Computers konnte nicht authentifiziert werden

Nicht jedes Ereignis ist standardmäßig aktiviert oder auf jedem System vorhanden. Ereignisse können auf unterschiedlichen beteiligten Computern entstehen.

26. Mehrere Ereignisse zeitlich abfragen

$Start = Get-Date "2026-08-02 09:10:00"
$End = Get-Date "2026-08-02 09:20:00"
$Ids = 4624, 4625, 4648, 4740, 4768, 4769, 4771, 4776

Get-WinEvent -FilterHashtable @{
    LogName   = "Security"
    Id        = $Ids
    StartTime = $Start
    EndTime   = $End
} |
    Select-Object TimeCreated, Id, ProviderName,
                  LevelDisplayName, Message |
    Sort-Object TimeCreated

Systemereignisse:

Get-WinEvent -FilterHashtable @{
    LogName   = "System"
    Id        = 5719, 5722, 5805
    StartTime = $Start
    EndTime   = $End
} |
    Select-Object TimeCreated, Id, ProviderName,
                  LevelDisplayName, Message |
    Sort-Object TimeCreated

Für große Protokolle sollte bereits serverseitig mit FilterHashtable nach Zeitraum und Ereignis-ID gefiltert werden.

27. Ereignisprotokolle auf dem Client prüfen

Relevante Protokolle können sein:

Windows-Protokolle → System
Windows-Protokolle → Sicherheit
Windows-Protokolle → Anwendung
Anwendungs- und Dienstprotokolle → Microsoft → Windows → GroupPolicy → Operational
Anwendungs- und Dienstprotokolle → Microsoft → Windows → User Profile Service → Operational
Anwendungs- und Dienstprotokolle → Microsoft → Windows → DNS Client Events
Anwendungs- und Dienstprotokolle → Microsoft → Windows → WLAN-AutoConfig → Operational

Vorhandene Protokolle auflisten:

Get-WinEvent -ListLog * |
    Where-Object {
        $_.LogName -match "GroupPolicy|User Profile|DNS|WLAN|Kerberos|Netlogon"
    } |
    Select-Object LogName, IsEnabled, RecordCount

Nicht jedes Protokoll ist auf jedem System aktiviert. Zusätzliche Protokollierung darf nur kontrolliert unter Berücksichtigung von Speicherbedarf, Datenschutz und Betriebsrichtlinien aktiviert werden.

28. Netlogon-Diagnose berücksichtigen

Der Netlogon-Dienst ist unter anderem an Domain-Controller-Ermittlung und sicherem Kanal beteiligt.

Dienststatus:

Get-Service -Name Netlogon

Ausführliche Dienstinformationen:

sc.exe query netlogon

Netlogon kann ein Diagnoseprotokoll unter folgendem Pfad verwenden:

%windir%\debug\netlogon.log

Erweiterte Netlogon-Protokollierung verändert den Diagnosezustand und kann umfangreiche oder sensible Informationen erzeugen. Sie sollte nur gezielt, zeitlich begrenzt und entsprechend der offiziellen Microsoft-Anleitung aktiviert werden.

Nach Abschluss muss eine zusätzlich aktivierte Diagnoseprotokollierung wieder auf den vorgesehenen Zustand zurückgesetzt werden.

29. Gruppenrichtlinien prüfen

Eine Anmeldung kann technisch erfolgreich sein, während Gruppenrichtlinien, Skripte oder Ressourcenverbindungen fehlschlagen.

Aktuelle Richtlinien aktualisieren:

gpupdate /force

Dieser Befehl ist eine aktive Zustandsänderung und sollte erst nach Sicherung der relevanten Ereignisse verwendet werden.

Resultierende Richtlinien anzeigen:

gpresult /r

Ausführlicher HTML-Bericht:

gpresult /h C:\Temp\gpresult.html

Relevante Fragen:

erreicht der Client SYSVOL und NETLOGON,
werden Benutzer- und Computerrichtlinien angewendet,
blockiert ein Anmelderecht die interaktive Anmeldung,
ist „Lokal anmelden zulassen“ passend konfiguriert,
greift „Lokal anmelden verweigern“,
greift „Anmelden über Remotedesktopdienste zulassen“,
verhindert eine Software Restriction Policy oder AppLocker einen Bestandteil,
hängt ein Anmelde- oder Startskript,
ist ein Netzlaufwerk oder Druckerziel nicht erreichbar,
wartet die Anmeldung auf das Netzwerk,
wurden Richtlinien kürzlich geändert.

Ein lang laufendes Anmeldeskript kann wie eine fehlgeschlagene Anmeldung erscheinen, obwohl die Authentifizierung bereits abgeschlossen wurde.

30. SYSVOL und NETLOGON prüfen

Freigaben eines Domain Controllers anzeigen:

net view \\<dc-fqdn>

SYSVOL testen:

dir \\<dc-fqdn>\SYSVOL

NETLOGON testen:

dir \\<dc-fqdn>\NETLOGON

Wenn diese Pfade nicht erreichbar sind, sind unter anderem zu prüfen:

DNS-Auflösung,
SMB-Erreichbarkeit,
Firewall,
Domain-Controller-Dienstzustand,
SYSVOL-Bereitstellung,
DFS-Replikation,
Netzwerkpfad,
Berechtigungen,
sicherer Kanal.

Ein erfolgreicher Verzeichniszugriff beweist nicht, dass alle Gruppenrichtlinien oder die AD-Replikation fehlerfrei sind.

31. Benutzerprofilfehler von Authentifizierungsfehlern trennen

Der Benutzer kann erfolgreich authentifiziert worden sein, obwohl Windows das Profil nicht laden kann.

Typische Hinweise:

Die Anmeldung des Dienstes "Benutzerprofildienst" ist fehlgeschlagen.

Das Benutzerprofil kann nicht geladen werden.

Sie wurden mit einem temporären Profil angemeldet.

Dann sind besonders zu prüfen:

Ereignisse des User Profile Service,
freier Speicherplatz,
Erreichbarkeit eines servergespeicherten Profils,
Berechtigungen,
beschädigtes lokales Profil,
Profilcontainer,
FSLogix bei entsprechender Umgebung,
Antiviren- oder Sicherheitssoftware,
Datenträgerfehler,
Registry-Profilzuordnung,
gleichzeitige Sitzung oder gesperrte Profildatei.

Ein Profilproblem darf nicht automatisch als fehlerhaftes Benutzerkonto oder fehlerhafte Domänenauthentifizierung behandelt werden.

32. RDP-Anmeldung gesondert untersuchen

Wenn nur die Remotedesktopanmeldung fehlschlägt, zusätzlich prüfen:

RDP-Dienst erreichbar,
TCP-Port erreichbar,
Network Level Authentication,
Benutzer besitzt RDP-Anmelderecht,
Benutzer ist nicht durch eine Richtlinie ausgeschlossen,
Zielsystem kann den Domain Controller erreichen,
Zielsystemzeit stimmt,
Zertifikat oder TLS-Verbindung funktioniert,
CredSSP- oder Sicherheitsrichtlinien sind kompatibel,
keine bereits bestehende oder beschränkte Sitzung,
Anmeldetyp 10 in Ereignis 4625,
Quelladresse und Zielsystem im Ereignis.

Porttest:

Test-NetConnection -ComputerName <zielserver> -Port 3389

Ein erfolgreicher Porttest beweist nur, dass eine TCP-Verbindung hergestellt werden konnte. Er beweist nicht, dass NLA, Authentifizierung, Anmelderechte oder Profilladen funktionieren.

33. Anmeldung über VPN untersuchen

Bei entfernten Clients ist entscheidend, wann das VPN verfügbar wird.

Mögliche Fälle:

Benutzer meldet sich mit zwischengespeicherten Daten an und startet danach das VPN.
Ein gerätebasiertes VPN ist bereits vor der Anmeldung aktiv.
Ein Pre-Logon-VPN wird am Anmeldebildschirm gestartet.
Das VPN benötigt Benutzeranmeldedaten, die erst nach der Windows-Anmeldung verfügbar sind.
Das VPN verteilt falsche DNS-Server oder Routen.
Der VPN-Tunnel erreicht nicht alle benötigten Domain Controller.
MTU-, Firewall- oder Fragmentierungsprobleme stören einzelne Protokolle.
Gerätezertifikat oder Maschinenkonto ist fehlerhaft.

Nach Aufbau des VPN prüfen:

ipconfig /all

Get-DnsClientServerAddress

Get-NetRoute

nltest /dsgetdc:<ad-domain>

w32tm /query /status

Die erfolgreiche Anmeldung am Notebook vor dem VPN beweist nur, dass zwischengespeicherte Anmeldedaten verwendbar waren.

34. Domain Controller diagnostizieren

Auf einem Domain Controller und mit entsprechender Berechtigung:

dcdiag

Ausführliche Ausgabe in eine Datei:

dcdiag /v > C:\Temp\dcdiag.txt

DNS-Prüfung:

dcdiag /test:dns /v

Bestimmten Domain Controller testen:

dcdiag /s:<dc-name> /v

Unternehmensweite Prüfung:

dcdiag /e /v

Die unternehmensweite Prüfung kann umfangreich sein und sollte kontrolliert eingesetzt werden.

Zu untersuchen sind unter anderem:

DNS,
Erreichbarkeit,
Netlogon,
Advertising,
Dienste,
Replikation,
SYSVOL,
Rollen und Verzeichniszustand.

Nicht jede Warnung in dcdiag erklärt automatisch die konkrete Anmeldestörung. Der Zeitpunkt und der betroffene Authentifizierungspfad müssen weiterhin korreliert werden.

35. Active-Directory-Replikation prüfen

Zusammenfassung:

repadmin /replsummary

Eingehende Replikationspartner:

repadmin /showrepl

Alle Domain Controller detailliert:

repadmin /showrepl * /csv

Replikationswarteschlange:

repadmin /queue

Zu prüfen sind:

fehlgeschlagene Replikationen,
Zeitpunkt der letzten erfolgreichen Replikation,
Fehlercode,
betroffene Partition,
nur ein Standort oder ein Domain Controller betroffen,
DNS- oder RPC-Fehler,
Zeitabweichung,
Authentifizierungsfehler,
Netzwerkunterbrechung.

Eine erzwungene Replikation ist eine aktive Änderung und sollte nicht als erster Diagnoseschritt verwendet werden.

Wenn ein Benutzer sein Kennwort geändert hat und die Anmeldung abhängig vom erreichten Domain Controller funktioniert, ist eine Replikationsstörung eine mögliche Hypothese. Sie muss durch Replikationsdaten und den tatsächlich verwendeten Domain Controller bestätigt werden.

36. AD-Standorte und Subnetze berücksichtigen

Der Domain Controller Locator berücksichtigt Active-Directory-Standorte.

Clientstandort:

nltest /dsgetsite

Gefundener Domain Controller:

nltest /dsgetdc:<ad-domain>

Mögliche Fehler:

Clientsubnetz fehlt in Active Directory Sites and Services,
Subnetz ist dem falschen Standort zugeordnet,
lokaler Domain Controller ist nicht erreichbar,
Client verwendet einen entfernten Domain Controller,
DNS liefert veraltete oder ungeeignete Einträge,
Standort-Uplink blockiert benötigte Protokolle,
Anmeldung wird durch hohe Latenz oder Paketverlust verzögert,
nur der Domain Controller eines Standorts besitzt veraltete Daten.

Ein entfernter Domain Controller ist nicht automatisch fehlerhaft. Die Standortzuordnung ist jedoch wichtig für Performance, Verfügbarkeit und Fehlereingrenzung.

37. Firewall und benötigte Dienste berücksichtigen

Active Directory verwendet mehrere Dienste, beispielsweise:

DNS,
Kerberos,
LDAP,
LDAPS bei entsprechender Konfiguration,
SMB,
RPC Endpoint Mapper,
dynamische RPC-Ports,
Global Catalog,
Kerberos-Kennwortänderung,
Zeitdienst.

Einzelne typische Ports:

Dienst	Protokoll/Port
DNS	TCP/UDP 53
Kerberos	TCP/UDP 88
RPC Endpoint Mapper	TCP 135
NetBIOS Name Service	UDP 137
NetBIOS Datagram	UDP 138
NetBIOS Session	TCP 139
LDAP	TCP/UDP 389
SMB	TCP 445
Kerberos-Kennwortänderung	TCP/UDP 464
LDAPS	TCP 636
Global Catalog	TCP 3268
Global Catalog über TLS	TCP 3269
Windows-Zeitdienst	UDP 123
dynamisches RPC	versionsabhängiger TCP-Portbereich

Diese Tabelle ist keine vollständige Firewallfreigabe. Die tatsächlich benötigten Verbindungen hängen von Windows-Version, Topologie, Richtung und Funktion ab.

Firewalls dürfen nicht pauschal deaktiviert werden. Stattdessen sind verworfene Verbindungen, Quell- und Zieladressen, Ports, Richtung und Zeitpunkt zu untersuchen.

38. Paketmitschnitt nur gezielt einsetzen

Wenn DNS, DC Locator, Kerberos oder LDAP weiterhin unklar bleiben, kann ein autorisierter Paketmitschnitt helfen.

Mögliche Protokolle:

dns
kerberos
ldap
tcp.port == 445
tcp.port == 135

Möglicher Wireshark-Anzeigefilter:

dns || kerberos || ldap || tcp.port == 445 || tcp.port == 135

Zu beobachten sind:

DNS-SRV-Abfragen,
zurückgegebene Domain Controller,
fehlgeschlagene Namensauflösung,
Kerberos-AS-REQ und AS-REP,
Kerberos-Fehler,
LDAP-Verbindungsaufbau,
TCP-Retransmissions,
Verbindungszurücksetzungen,
ICMP-Fehler,
stark verzögerte Antworten,
angesprochener Domain Controller,
wechselnde Domain Controller.

Paketmitschnitte können Kontonamen, interne Strukturen, Tickets und andere vertrauliche Daten enthalten. Sie dürfen nur autorisiert, begrenzt, geschützt und kontrolliert ausgewertet werden.

39. Praxisfall A: Nur ein Benutzer kann sich nicht anmelden

Symptom

andere Benutzer können sich am selben Client anmelden,
der Benutzer kann sich auch an einem zweiten Client nicht anmelden,
Meldung weist auf gesperrtes Konto hin.

Prüfung

genaue Uhrzeit dokumentieren,
Benutzerkonto und Sperrstatus prüfen,
Ereignis 4740 auf den Domain Controllern suchen,
aufrufenden Computer ermitteln,
vorausgehende Ereignisse 4771, 4776 oder 4625 korrelieren,
gespeicherte Anmeldedaten, Dienste, Aufgaben, VPN und Mobilgeräte prüfen,
erst danach Konto kontrolliert entsperren,
Ereignisse weiter überwachen.

Mögliche Ursache

Ein geplanter Task auf einem alten Client verwendet weiterhin das vorherige Benutzerkennwort und sperrt das Konto wiederholt.

Nachprüfung

Aufgabe verwendet ein vorgesehenes Dienstkonto oder aktualisierte sichere Konfiguration,
keine weiteren fehlerhaften Anmeldeversuche,
keine neue Kontosperre,
Benutzer kann sich anmelden,
Sperrquelle und Maßnahme sind dokumentiert.

40. Praxisfall B: Kein Benutzer kann sich an einem Client anmelden

Symptom

lokale Anmeldung funktioniert,
Domänenanmeldungen schlagen fehl,
andere Clients funktionieren,
nltest /dsgetdc:<ad-domain> findet keinen Domain Controller.

Prüfung

IP-Konfiguration erfassen,
DNS-Server prüfen,
SRV-Einträge abfragen,
Domain Controller auflösen,
Netzwerkpfad prüfen,
Systemzeit kontrollieren,
sicheren Kanal erst nach Wiederherstellung des Netzwerkpfades testen.

Mögliche Ursache

Der Client verwendet durch eine statische Fehlkonfiguration einen öffentlichen DNS-Server und kann die internen Active-Directory-SRV-Einträge nicht auflösen.

Nachprüfung

Client erhält die vorgesehenen DNS-Server,
SRV-Abfragen funktionieren,
Domain Controller Locator findet einen geeigneten DC,
sicherer Kanal ist intakt,
Domänenanmeldung und Gruppenrichtlinien funktionieren,
Konfigurationsursache ist dokumentiert.

41. Praxisfall C: Vertrauensstellung ist fehlgeschlagen

Symptom

lokale Anmeldung funktioniert,
Domänenanmeldung meldet eine fehlerhafte Vertrauensstellung,
DNS und Domain Controller sind erreichbar,
der Client wurde kürzlich aus einem älteren Snapshot wiederhergestellt.

Prüfung

Client- und Computerkonto eindeutig identifizieren,
DNS und Uhrzeit prüfen,
Computerkonto untersuchen,
sicheren Kanal testen,
Snapshot-Zeitpunkt und Maschinenkennwort berücksichtigen,
Diagnoseereignisse sichern,
sicheren Kanal nach Freigabe kontrolliert reparieren.

Mögliche Ursache

Der Snapshot enthält ein älteres Maschinenkennwort als das Computerkonto in Active Directory.

Nachprüfung

sicherer Kanal funktioniert,
Domänenanmeldung ist möglich,
Gruppenrichtlinien werden verarbeitet,
Kerberos-Tickets werden ausgegeben,
Clientverwaltung funktioniert,
Wiederherstellungsverfahren für Domänencomputer wird angepasst.

42. Praxisfall D: Anmeldung funktioniert nur an einem Standort nicht

Symptom

Benutzer können sich am Hauptstandort anmelden,
an einer Außenstelle schlagen neue Anmeldungen fehl,
bereits bekannte Benutzer kommen teilweise über zwischengespeicherte Daten hinein,
ein lokaler Domain Controller wird über DNS gefunden.

Prüfung

betroffenen AD-Standort und Subnetz prüfen,
gefundenen Domain Controller dokumentieren,
DNS- und Dienstereichbarkeit testen,
dcdiag auf dem lokalen DC auswerten,
repadmin /replsummary und /showrepl prüfen,
Uhrzeit vergleichen,
Kontostand auf beteiligten Domain Controllern vergleichen,
Standort-Uplink und Firewall berücksichtigen.

Mögliche Ursache

Der lokale Domain Controller repliziert Benutzer- und Kennwortänderungen wegen einer gestörten Standortverbindung nicht ordnungsgemäß.

Nachprüfung

Replikation ist fehlerfrei,
Kennwortänderungen stehen an den vorgesehenen Domain Controllern zur Verfügung,
neue Benutzer können sich anmelden,
keine zwischengespeicherte Anmeldung wird fälschlich als Onlineanmeldung bewertet,
Standortverbindung wird überwacht.

43. Praxisfall E: Anmeldung dauert mehrere Minuten

Symptom

Anmeldeinformationen werden akzeptiert,
der Bildschirm bleibt lange bei „Willkommen“ oder „Benutzereinstellungen werden angewendet“,
Benutzerprofil wird schließlich geladen,
andere Standorte sind schneller.

Prüfung

Authentifizierungszeit und Profil-Ladezeit trennen,
Ereignisse von GroupPolicy und User Profile Service prüfen,
gpresult auswerten,
SYSVOL und NETLOGON testen,
Anmelde- und Startskripte untersuchen,
Netzlaufwerke und Druckerverbindungen prüfen,
DNS und verwendeten Domain Controller erfassen,
Serverprofil oder Profilcontainer untersuchen,
Zeitlinie von Anmeldung, Richtlinien und Profilladen erstellen.

Mögliche Ursache

Ein Anmeldeskript wartet auf einen nicht erreichbaren Dateiserver, bis ein Timeout abläuft.

Nachprüfung

Skriptziel ist erreichbar oder kontrolliert entfernt,
Anmeldung erfolgt innerhalb des vorgesehenen Zeitraums,
alle benötigten Richtlinien werden angewendet,
Netzlaufwerke und andere Geschäftsprozesse funktionieren,
Messwerte vor und nach der Änderung sind dokumentiert.

44. Ungeeignete Sofortmaßnahmen

Problematisch sind insbesondere:

Benutzerkennwort sofort zurücksetzen,
Konto nur entsperren und die Sperrquelle ignorieren,
Computerkonto löschen,
Client sofort aus der Domäne entfernen,
Domain Controller neu starten,
DNS-Cache leeren, bevor Einträge dokumentiert wurden,
Kerberos-Tickets löschen, bevor sie geprüft wurden,
Firewall vollständig deaktivieren,
Gruppenrichtlinien pauschal abschalten,
Systemzeit manuell verändern,
mehrere Domain Controller gleichzeitig verändern,
Replikation ungeprüft erzwingen,
DNS-Einträge manuell neu anlegen, ohne die Registrierungsursache zu prüfen,
Benutzerprofil löschen, obwohl die Authentifizierung fehlschlägt,
lokale Administratorrechte unnötig vergeben,
Kennwörter in Tickets oder Skripten speichern,
nur Ping verwenden,
nur den Client untersuchen,
eine zwischengespeicherte Anmeldung als erfolgreiche DC-Anmeldung bewerten,
einen erfolgreichen Test mit anderem Benutzer als Beweis für fehlerfreies AD ansehen.

45. Vollständige Prüfreihenfolge

genauen Meldungstext sichern.
Datum, Uhrzeit und Zeitzone erfassen.
Benutzer, Client und Standort bestimmen.
lokales Konto und Domänenkonto unterscheiden.
verwendetes Anmeldeformat dokumentieren.
prüfen, ob eine zwischengespeicherte Anmeldung möglich war.
feststellen, ob ein Benutzer, ein Client oder mehrere Systeme betroffen sind.
Vergleich mit anderem Benutzer am selben Client durchführen.
Vergleich mit demselben Benutzer an einem anderen Client durchführen.
Netzwerkstatus vor der Anmeldung berücksichtigen.
IP-Konfiguration erfassen.
Gateway und internen DNS-Server prüfen.
konfigurierte DNS-Server und Suffixe kontrollieren.
Active-Directory-SRV-Einträge auflösen.
Hostnamen der Domain Controller auflösen.
Domain Controller Locator prüfen.
AD-Standort des Clients bestimmen.
verwendeten Domain Controller dokumentieren.
Uhrzeit, Zeitzone und Zeitquelle prüfen.
Benutzerkonto auf Aktivierung, Sperre und Ablauf prüfen.
Anmeldezeiten und erlaubte Arbeitsstationen berücksichtigen.
Kennwortänderung und gespeicherte Anmeldedaten prüfen.
Ereignisse 4625, 4740, 4771 und 4776 korrelieren.
bei RDP den Anmeldetyp und das Zielsystem berücksichtigen.
Computerkonto prüfen.
sicheren Kanal diagnostizieren.
Kerberos-Tickets und KDC prüfen.
SYSVOL und NETLOGON testen.
Gruppenrichtlinien und Anmeldeskripte untersuchen.
Profilfehler von Authentifizierungsfehlern trennen.
bei VPN den Pre-Logon-Netzwerkzustand prüfen.
Domain Controller mit dcdiag untersuchen.
Replikation mit repadmin prüfen.
Firewall-, Routing- und Standortpfad berücksichtigen.
Daten aller beteiligten Systeme auf einer Zeitleiste zusammenführen.
konkrete Hypothese formulieren.
genau eine kontrollierbare Änderung durchführen.
dieselben Prüfungen erneut ausführen.
Domänenanmeldung testen.
Gruppenrichtlinien und Domänenressourcen prüfen.
Vergleichsbenutzer und Vergleichsclient testen.
Ereignisprotokolle auf neue Fehler prüfen.
temporäre Diagnosekonfiguration entfernen.
Ursache, Änderung und Nachweis dokumentieren.
Monitoring oder Präventionsmaßnahme festlegen.

46. Dokumentationsbeispiel

Ticket: INC-20831
Zeitraum: 02.08.2026, 08:14 bis 10:42 Uhr
Benutzer: test.user
Client: WS-BER-042
Domäne: ad.example.test
Standort: Berlin
Verbindung: Ethernet

Symptom:
Kein Domänenbenutzer kann sich an WS-BER-042 anmelden. Lokale Anmeldung
ist möglich. Andere Clients desselben Standorts sind nicht betroffen.

Meldung:
„Es sind momentan keine Anmeldeserver zum Verarbeiten der
Anmeldeanforderung verfügbar.“

Vergleich:
- anderer Domänenbenutzer am selben Client: fehlgeschlagen
- betroffener Benutzer an anderem Client: erfolgreich
- lokales Administratorkonto: erfolgreich

Messungen:
- Client besitzt gültige IPv4-Adresse und erreicht das Standardgateway
- interner DNS-Server ist erreichbar
- in der statischen Adapterkonfiguration ist jedoch ein öffentlicher
  DNS-Server eingetragen
- Abfrage von _ldap._tcp.dc._msdcs.ad.example.test schlägt fehl
- nltest /dsgetdc:ad.example.test liefert Fehler 1355
- Clientzeit ist korrekt
- Computerkonto ist vorhanden und aktiviert

Hypothese:
Der Client kann aufgrund der falschen DNS-Konfiguration keine
Active-Directory-Domain-Controller finden.

Kontrollierte Änderung:
Die statische DNS-Konfiguration wurde entsprechend der freigegebenen
Netzwerkdokumentation auf die vorgesehenen internen DNS-Server korrigiert.
Andere Einstellungen blieben unverändert.

Nachprüfung:
- SRV-Abfrage liefert die vorgesehenen Domain Controller
- nltest findet einen Domain Controller des korrekten Standorts
- sicherer Kanal ist intakt
- Domänenanmeldung funktioniert
- Gruppenrichtlinien werden verarbeitet
- SYSVOL und NETLOGON sind erreichbar
- keine neuen Netlogon- oder Anmeldefehler
- Vergleichsbenutzer funktioniert ebenfalls

Ursache:
Falsch statisch eingetragener öffentlicher DNS-Server am Domänenclient.

Prävention:
- DNS-Konfiguration von Domänenclients zentral überwachen
- statische Clientkonfigurationen vermeiden, wenn DHCP vorgesehen ist
- Prüfung der AD-SRV-Auflösung in die Clientdiagnose aufnehmen

47. Checkliste „Anmeldung an der Domäne geht nicht“

48. Schnellreferenz

Beobachtung	wahrscheinlicher Untersuchungsbereich
ein Benutzer überall betroffen	Konto, Kennwort, Sperre, Ablauf oder Anmelderechte
alle Benutzer an einem Client betroffen	DNS, Netzwerk, Uhrzeit, Computerkonto oder sicherer Kanal
mehrere Clients eines Standorts betroffen	Standort-DNS, VLAN, Uplink, Firewall oder lokaler DC
lokale Anmeldung funktioniert	lokales System grundsätzlich zugänglich; Domänenpfad weiter prüfen
alter Benutzer funktioniert offline	wahrscheinlich zwischengespeicherte Anmeldung
neuer Benutzer funktioniert offline nicht	keine zwischengespeicherten Anmeldedaten vorhanden
altes Kennwort funktioniert offline	Cache; keine Bestätigung des aktuellen Domänenkennworts
öffentliches DNS funktioniert, AD nicht	interne AD-DNS-Zone oder SRV-Auflösung
Fehler 1355 bei `nltest`	Domain Controller konnte nicht gefunden werden
Uhrzeit stark abweichend	Kerberos und Zeitdienst
Konto gesperrt	Sperrquelle über 4740 und vorausgehende Fehler suchen
Sperre kehrt sofort zurück	Gerät, Dienst, Aufgabe, VPN oder gespeicherte Daten
Vertrauensstellung fehlgeschlagen	Computerkonto oder sicherer Kanal
Fehler nach Snapshot-Rückkehr	Maschinenkennwort oder Computerzustand
Anmeldung abhängig vom DC	Replikation, DC-Zustand, DNS oder Standort
Anmeldung funktioniert, Profil lädt nicht	User Profile Service, Speicher oder Profilpfad
Anmeldung bleibt bei „Willkommen“ hängen	Gruppenrichtlinie, Skript, Profil oder Ressource
RDP allein betroffen	NLA, RDP-Rechte, Zielsystem oder Anmeldetyp 10
VPN allein betroffen	Pre-Logon-Verbindung, DNS, Routing, Zertifikat oder Tunnel
SYSVOL nicht erreichbar	DNS, SMB, DC, DFS-Replikation oder Firewall
`Test-ComputerSecureChannel` negativ	sicheren Kanal und Voraussetzungen gezielt untersuchen
Ping erfolgreich, Anmeldung fehlschlägt	DNS, Kerberos, LDAP, SMB, RPC, Konto oder Richtlinie
anderes Konto funktioniert	benutzerspezifischen Bereich priorisieren
derselbe Benutzer funktioniert an anderem Client	Client oder clientspezifische Richtlinie priorisieren
keine Ereignisse gefunden	falsches System, falscher Zeitraum, Auditierung oder Rotation
Anmeldung nach DNS-Korrektur möglich	DNS-Ursache durch Vorher-Nachher-Daten bestätigen
Anmeldung nach Neustart möglich	Zustand geändert; Ursache noch nicht bewiesen

Merksatz

Eine Domänenanmeldung ist kein einzelner Vorgang, sondern eine Kette aus Netzwerk, DNS, Domain Controller Locator, Zeit, Benutzerkonto, Computerkonto, sicherem Kanal und Authentifizierungsprotokoll. Die Diagnose beginnt deshalb mit dem genauen Umfang und dem originalen Fehlerzeitpunkt. Erst danach werden Client, DNS, Domain Controller und Ereignisprotokolle auf einer gemeinsamen Zeitleiste geprüft.

Quellen und weiterführende Dokumentation