7. Schnelle Entscheidungsbäume

7.1 Ein Client hat kein Netzwerk

Wenn nur ein einzelner Client keine Netzwerkverbindung besitzt, sollte die Fehlersuche schnell feststellen, auf welcher Ebene die Verbindung unterbrochen ist:

  1. Netzwerkadapter,
  2. physische oder drahtlose Verbindung,
  3. IP-Konfiguration,
  4. lokales Netzwerk,
  5. Routing,
  6. DNS,
  7. Zielsystem oder Anwendung.

Dieser Entscheidungsbaum dient der schnellen Eingrenzung. Die ausführliche Ende-zu-Ende-Analyse befindet sich auf der Seite 6.1 Client ohne Netzwerkverbindung – systematische Ende-zu-Ende-Analyse.

1. Störungsumfang bestimmen

Zuerst prüfen:

Beobachtung Nächster Untersuchungsbereich
nur ein Client betroffen Client, Anschluss, Kabel, WLAN oder lokale Konfiguration
mehrere Clients betroffen Switch, Access Point, VLAN, DHCP, Gateway oder Standortverbindung
nur eine Anwendung betroffen Anwendung, Proxy, Dienst, Port oder Zertifikat
IP-Ziele erreichbar, Namen nicht DNS
interne Ziele erreichbar, Internet nicht Gateway, Firewall, Proxy oder Internetübergang
Internet erreichbar, interne Ziele nicht Routing, VPN, interne DNS-Zone oder Zugriffskontrolle
Ethernet betroffen, WLAN funktioniert Kabel, Switchport, Ethernetadapter oder VLAN
WLAN betroffen, Ethernet funktioniert WLAN-Profil, Authentifizierung, Signal oder Access Point
beide Verbindungsarten betroffen Clientkonfiguration, VPN, Firewall, Routing oder Betriebssystem

Wenn mehrere Clients betroffen sind, zum Entscheidungsbaum für Standort- oder Bereichsstörungen wechseln.

2. Besteht eine Verbindung zum Netzwerkmedium?

Ethernet

Prüfen:

Adapterstatus anzeigen:

Get-NetAdapter

Nur physische Adapter anzeigen:

Get-NetAdapter -Physical

Ausführliche Adapterinformationen:

Get-NetAdapter | Format-List Name, InterfaceDescription, Status, LinkSpeed, MacAddress

Entscheidung

WLAN

WLAN-Schnittstelle und Verbindungszustand anzeigen:

netsh wlan show interfaces

Sichtbare WLAN-Netze anzeigen:

netsh wlan show networks

Gespeicherte WLAN-Profile anzeigen:

netsh wlan show profiles

Prüfen:

Entscheidung

Ein angezeigter WLAN-Status „Verbunden“ bestätigt noch keine funktionierende IP-Verbindung.

3. Besitzt der Client eine gültige IP-Konfiguration?

Vollständige Konfiguration erfassen:

ipconfig /all

Alternativ mit PowerShell:

Get-NetIPConfiguration

Zu dokumentieren sind:

Entscheidungsbaum zur IPv4-Adresse

Besitzt der aktive Adapter eine IPv4-Adresse?
|
+-- Nein
|   |
|   +-- DHCP vorgesehen?
|       |
|       +-- Ja  -> DHCP-Client, VLAN, Switchport, Access Point,
|       |          DHCP-Server und DHCP-Relay prüfen
|       |
|       +-- Nein -> statische Konfiguration mit Netzwerkplan vergleichen
|
+-- Ja
    |
    +-- Adresse beginnt mit 169.254?
    |   |
    |   +-- Ja  -> keine verwendbare DHCP-Konfiguration erhalten
    |              DHCP-Pfad untersuchen
    |
    +-- Adresse 0.0.0.0 oder unvollständig?
    |   |
    |   +-- Ja  -> Adapter-, DHCP- oder Konfigurationsfehler
    |
    +-- Adresse aus erwartetem Subnetz?
        |
        +-- Nein -> falsches VLAN, falscher DHCP-Bereich,
        |          statische Fehlkonfiguration oder fremdes Netz
        |
        +-- Ja  -> Gateway und lokale Erreichbarkeit prüfen

Eine Adresse aus 169.254.0.0/16 ist eine automatisch vergebene Link-Local-Adresse. Sie zeigt typischerweise, dass der Client keine verwendbare IPv4-Konfiguration per DHCP erhalten hat. Sie beweist allein jedoch noch nicht, ob DHCP-Server, Relay, VLAN, Kabel, WLAN oder der lokale Client die Ursache ist.

4. DHCP-Pfad prüfen

Wenn DHCP vorgesehen ist, zunächst den bestehenden Zustand dokumentieren.

DHCP-Clientdienst prüfen:

Get-Service -Name Dhcp

Adapterkonfiguration prüfen:

Get-NetIPInterface

Mögliche Ursachen:

Erst nach Erfassung der ursprünglichen Konfiguration kann eine neue Anforderung kontrolliert ausgelöst werden:

ipconfig /release

ipconfig /renew

ipconfig /release und ipconfig /renew verändern den aktuellen Netzwerkzustand. Sie sollten nicht vor der Dokumentation der vorhandenen Adresse, Lease-Daten und Fehlersituation ausgeführt werden.

Ergebnis bewerten

Bei weiterhin unklaren DHCP-Problemen kann ein autorisierter Paketmitschnitt zeigen, ob der DORA-Ablauf vollständig ist:

  1. DHCP Discover,
  2. DHCP Offer,
  3. DHCP Request,
  4. DHCP Acknowledge.

5. Lokalen TCP/IP-Stack prüfen

Loopback-Adresse testen:

ping 127.0.0.1

Eigene IPv4-Adresse testen:

ping <eigene-ip-adresse>

Entscheidung

Ein erfolgreicher Loopback-Test bestätigt nur die lokale TCP/IP-Verarbeitung. Er beweist keine Verbindung zum Switch, WLAN, Gateway oder Internet.

6. Standardgateway vorhanden und erreichbar?

Gateway aus der Konfiguration übernehmen:

ipconfig

Routingtabelle anzeigen:

route print

Alternativ:

Get-NetRoute

Gateway testen:

ping <gateway-ip>

Zusätzliche Verbindungsinformationen:

Test-NetConnection -ComputerName <gateway-ip> -InformationLevel Detailed

Nachbartabelle anzeigen:

arp -a

Oder mit PowerShell:

Get-NetNeighbor

Entscheidungsbaum

Ist ein Standardgateway eingetragen?
|
+-- Nein
|   |
|   +-- Nur lokales Subnetz erforderlich?
|   |   |
|   |   +-- Ja  -> lokale Ziele weiterprüfen
|   |   +-- Nein -> DHCP-Option oder statische Konfiguration korrigieren
|   |
+-- Ja
    |
    +-- Gateway im passenden lokalen Subnetz?
        |
        +-- Nein -> IP-Adresse, Maske und Gateway sind inkonsistent
        |
        +-- Ja
            |
            +-- Gateway erreichbar?
                |
                +-- Ja  -> Routing außerhalb des lokalen Netzes prüfen
                |
                +-- Nein -> VLAN, Switchport, WLAN, ARP,
                           lokale Firewall oder Gateway untersuchen

Wenn der Gateway-Ping scheitert, kann das Gateway ICMP blockieren. Deshalb zusätzlich prüfen:

Ein fehlgeschlagener Ping allein beweist nicht, dass das Gateway ausgefallen ist.

7. Ist ein anderes Ziel im lokalen Subnetz erreichbar?

Vergleichsziel im gleichen Subnetz testen:

ping <lokales-vergleichsziel>

Gezielten Dienst prüfen:

Test-NetConnection -ComputerName <lokales-vergleichsziel> -Port <port>

Entscheidung

8. Funktioniert die Verbindung zu einer externen IP-Adresse?

Ein freigegebenes bekanntes IP-Ziel verwenden:

ping <bekannte-ip-adresse>

Pfad untersuchen:

tracert <bekannte-ip-adresse>

PowerShell-Diagnose:

Test-NetConnection -ComputerName <bekannte-ip-adresse> -InformationLevel Detailed

Entscheidung

Ein erfolgreicher Ping zu einer externen Adresse beweist nicht, dass DNS oder der benötigte Anwendungsdienst funktioniert.

9. Funktioniert die Namensauflösung?

Konfigurierte DNS-Server prüfen:

ipconfig /all

Namensauflösung testen:

nslookup <zielname>

Mit PowerShell:

Resolve-DnsName <zielname>

Erreichbarkeit eines DNS-Servers prüfen:

Test-NetConnection -ComputerName <dns-server> -Port 53

TCP-Port 53 allein genügt nicht für eine vollständige DNS-Prüfung, da DNS abhängig von Anfrage und Umgebung sowohl UDP als auch TCP verwenden kann.

Entscheidungsbaum

Ist eine bekannte IP-Adresse erreichbar?
|
+-- Nein -> noch kein reines DNS-Problem;
|          Netzwerkpfad und Routing weiterprüfen
|
+-- Ja
    |
    +-- Kann ein Name aufgelöst werden?
        |
        +-- Ja  -> Zielanwendung oder Zielport prüfen
        |
        +-- Nein
            |
            +-- DNS-Server eingetragen?
            |   |
            |   +-- Nein -> DHCP- oder statische DNS-Konfiguration prüfen
            |
            +-- DNS-Server erreichbar?
            |   |
            |   +-- Nein -> Routing, VLAN, VPN oder Firewall prüfen
            |
            +-- DNS-Server antwortet, liefert aber keinen passenden Eintrag?
                |
                +-- DNS-Zone, Eintrag, Weiterleitung, Suchsuffix
                    und verwendeten Namen prüfen

DNS-Cache anzeigen:

ipconfig /displaydns

Der DNS-Cache sollte vor einer Löschung dokumentiert werden. Eine sofortige Leerung kann diagnostisch wichtige Einträge und Unterschiede beseitigen.

Erst nach der Beweissicherung und wenn dies zur Hypothese passt:

ipconfig /flushdns

10. Funktioniert nur die Anwendung nicht?

Wenn IP-Verbindung und Namensauflösung funktionieren, den tatsächlich benötigten Dienst prüfen.

Porttest:

Test-NetConnection -ComputerName <zielname> -Port <port>

Beispiele:

Test-NetConnection -ComputerName <zielname> -Port 443

Test-NetConnection -ComputerName <zielname> -Port 445

Test-NetConnection -ComputerName <zielname> -Port 3389

Zusätzlich prüfen:

Proxykonfiguration anzeigen:

netsh winhttp show proxy

Benutzerbezogene Proxy- und Anwendungseinstellungen können davon abweichen. Eine erfolgreiche TCP-Verbindung beweist außerdem nicht, dass TLS, Authentifizierung oder die Anwendung selbst funktionieren.

11. Beeinflusst ein VPN oder virtueller Adapter die Verbindung?

Adapter anzeigen:

Get-NetAdapter

IP-Konfiguration anzeigen:

Get-NetIPConfiguration

Routingtabelle prüfen:

route print

DNS-Server je Schnittstelle anzeigen:

Get-DnsClientServerAddress

Zu prüfen sind:

Vergleichstest

Wenn betrieblich zulässig, den Zustand dokumentieren und anschließend prüfen, ob das Problem nur mit aktivem VPN auftritt.

VPN- oder Sicherheitssoftware darf nicht pauschal deinstalliert oder dauerhaft deaktiviert werden.

12. Lokale Firewall und Sicherheitssoftware berücksichtigen

Firewallprofile anzeigen:

Get-NetFirewallProfile

Aktive Verbindungen und lauschende Ports:

Get-NetTCPConnection

Zu prüfen sind:

Die Firewall oder Sicherheitssoftware darf nicht pauschal deaktiviert werden. Stattdessen sind Protokolle, verworfene Verbindungen, Zieladresse, Zielport, Richtung und Zeitpunkt auszuwerten.

13. Vergleichstests durchführen

Geeignete Vergleichstests:

Test Aussage
anderer Client am selben Anschluss funktioniert ursprünglichen Client priorisieren
anderer Client am selben Anschluss funktioniert ebenfalls nicht Anschluss, VLAN oder Netzwerkpfad priorisieren
betroffener Client funktioniert an anderem Anschluss ursprünglichen Anschluss oder dessen Konfiguration prüfen
betroffener Client funktioniert über WLAN Ethernetpfad priorisieren
betroffener Client funktioniert über Ethernet WLANpfad priorisieren
gleiche IP-Konfiguration wie Vergleichsclient, aber keine Verbindung Adapter, Route, Firewall, VPN oder Adresskonflikt prüfen
nur ein Benutzer betroffen Benutzerprofil, Proxy, Zertifikat oder Richtlinie prüfen
alle Benutzer am Client betroffen Computer-, Adapter- oder Systemkonfiguration priorisieren

Beim Anschlusswechsel ist darauf zu achten, dass der Vergleichsport zum selben vorgesehenen Netz und VLAN gehört. Sonst entsteht kein aussagekräftiger Vergleich.

14. Möglichen IP-Adresskonflikt prüfen

Hinweise auf einen Adresskonflikt:

Nachbartabelle prüfen:

arp -a

Eigene MAC-Adresse erfassen:

Get-NetAdapter | Format-Table Name, MacAddress, Status

Prüfen:

Die ARP-Tabelle sollte vor dem Löschen dokumentiert werden.

15. Ereignisprotokolle prüfen

Relevante Protokolle können sich befinden unter:

Ereignisanzeige
└─ Anwendungs- und Dienstprotokolle
   └─ Microsoft
      └─ Windows
         ├─ DHCP-Client
         ├─ DNS-Client
         ├─ NetworkProfile
         ├─ NlaSvc
         ├─ TCPIP
         └─ WLAN-AutoConfig

PowerShell-Beispiel für Systemereignisse:

Get-WinEvent -LogName System -MaxEvents 200 |
    Where-Object {
        $_.ProviderName -match 'Tcpip|Dhcp|DNS|WLAN|NlaSvc'
    } |
    Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message

Zu korrelieren sind:

Ein einzelnes älteres Ereignis beweist nicht die Ursache der aktuellen Störung. Zeitpunkt, Adapter und Fehlerbild müssen zusammenpassen.

16. Treiber und Hardware erst nach der Netzwerkanalyse prüfen

Treiber- oder Hardwareprobleme sind besonders wahrscheinlich, wenn:

Vor Änderungen dokumentieren:

Adapterinformationen:

Get-NetAdapter |
    Format-List Name, InterfaceDescription, DriverInformation, Status, LinkSpeed

Ein Treiber sollte nicht allein deshalb neu installiert werden, weil keine Netzwerkverbindung besteht. Zuerst muss geklärt werden, ob der Fehler tatsächlich am Clientadapter liegt.

17. Paketmitschnitt nur bei weiterhin unklarer Ursache

Ein autorisierter Paketmitschnitt kann prüfen, ob der Client Pakete sendet und Antworten erhält.

Typische Filter:

arp

dhcp

dns

icmp

Kombinierter Wireshark-Anzeigefilter:

arp || dhcp || dns || icmp

Zu beobachten sind:

Paketmitschnitte können interne Adressen, Namen, Benutzerinformationen und andere vertrauliche Daten enthalten. Sie dürfen nur autorisiert, zeitlich begrenzt und geschützt erstellt werden.

18. Schneller Hauptentscheidungsbaum

START: Ein Client hat kein Netzwerk
|
+-- Sind weitere Clients betroffen?
|   |
|   +-- Ja  -> Bereichs-, Switch-, WLAN-, VLAN-, DHCP- oder Gatewayfehler
|   |          untersuchen; anderen Entscheidungsbaum verwenden
|   |
|   +-- Nein -> am einzelnen Client fortfahren
|
+-- Ist der aktive Netzwerkadapter vorhanden und aktiviert?
|   |
|   +-- Nein -> Adapter, Treiber, Hardware und Gerätestatus prüfen
|   |
|   +-- Ja
|
+-- Besteht Ethernet-Link oder WLAN-Verbindung?
|   |
|   +-- Nein -> Kabel, Dose, Port, SSID, Signal oder Authentifizierung
|   |          prüfen
|   |
|   +-- Ja
|
+-- Besitzt der Client eine gültige IP-Adresse?
|   |
|   +-- Nein oder 169.254.x.x
|   |          -> DHCP, VLAN, Relay, Port oder statische Konfiguration
|   |             prüfen
|   |
|   +-- Ja
|
+-- Ist ein korrektes Standardgateway vorhanden?
|   |
|   +-- Nein -> DHCP-Option oder statische Konfiguration prüfen
|   |
|   +-- Ja
|
+-- Ist das Gateway erreichbar?
|   |
|   +-- Nein -> Subnetzmaske, ARP, VLAN, Switchport, WLAN,
|   |          NAC oder lokales Netz prüfen
|   |
|   +-- Ja
|
+-- Ist eine freigegebene externe IP-Adresse erreichbar?
|   |
|   +-- Nein -> Routing, Firewall, VPN, NAT oder Internetübergang
|   |          prüfen
|   |
|   +-- Ja
|
+-- Kann der Zielname aufgelöst werden?
|   |
|   +-- Nein -> DNS-Server, DNS-Erreichbarkeit, Suffix und Eintrag
|   |          prüfen
|   |
|   +-- Ja
|
+-- Ist der benötigte Zielport erreichbar?
    |
    +-- Nein -> Zielservice, Firewall, Proxy oder Routing prüfen
    |
    +-- Ja  -> Anwendung, TLS, Authentifizierung oder Berechtigung prüfen

19. Beispiel für eine schnelle Diagnose

Symptom

Ein Arbeitsplatz-PC meldet „Kein Internet“. Andere Clients im Büro funktionieren.

Prüfung

Get-NetAdapter

Ergebnis:

Name      Status        LinkSpeed
Ethernet  Up            1 Gbps

IP-Konfiguration:

ipconfig /all

Ergebnis:

IPv4-Adresse: 169.254.38.17
Subnetzmaske: 255.255.0.0
Standardgateway:
DHCP aktiviert: Ja

Bewertung

Vergleichstest

Ein anderes Gerät wird kontrolliert am selben Anschluss geprüft und erhält ebenfalls keine DHCP-Adresse.

Nächster Untersuchungsbereich

Festgestellte Ursache

Der Switchport wurde versehentlich einem nicht vorgesehenen VLAN zugeordnet.

Nachprüfung

20. Ungeeignete Sofortmaßnahmen

Nicht als erste Maßnahme verwenden:

Solche Maßnahmen verändern den Zustand, beseitigen Beweise oder erzeugen zusätzliche Fehler.

21. Vollständige Schnellprüfreihenfolge

  1. genaue Fehlermeldung und Uhrzeit erfassen.
  2. feststellen, ob nur ein Client betroffen ist.
  3. Ethernet, WLAN, VPN und betroffene Ziele unterscheiden.
  4. Vergleichsclient prüfen.
  5. Adapterstatus erfassen.
  6. physischen Link oder WLAN-Verbindung prüfen.
  7. ipconfig /all dokumentieren.
  8. IP-Adresse und Subnetz prüfen.
  9. bei 169.254.x.x den DHCP-Pfad untersuchen.
  10. Standardgateway prüfen.
  11. Routingtabelle erfassen.
  12. eigenes TCP/IP über Loopback testen.
  13. lokales Vergleichsziel testen.
  14. Gateway testen.
  15. externe IP-Verbindung testen.
  16. Pfad bei Bedarf mit tracert untersuchen.
  17. DNS-Server und Namensauflösung prüfen.
  18. benötigten Zielport testen.
  19. Proxy, VPN und virtuelle Adapter berücksichtigen.
  20. Firewall- und Sicherheitsprotokolle prüfen.
  21. Ereignisse mit dem Fehlerzeitpunkt korrelieren.
  22. genau eine Hypothese formulieren.
  23. genau eine kontrollierte Änderung durchführen.
  24. dieselben Tests erneut ausführen.
  25. interne und externe Ziele prüfen.
  26. Namensauflösung prüfen.
  27. benötigte Anwendungen testen.
  28. Vergleichsclient oder Vergleichsanschluss erneut testen.
  29. temporäre Diagnosekonfiguration entfernen.
  30. Ursache, Maßnahme und Nachweis dokumentieren.

22. Checkliste „Ein Client hat kein Netzwerk“

23. Schnellreferenz

Ergebnis Nächster Schritt
Adapter fehlt Hardware, Treiber oder Geräteerkennung prüfen
Adapter deaktiviert Ursache der Deaktivierung klären
Ethernet Disconnected Kabel, Dose, Patchung und Switchport prüfen
WLAN nicht verbunden SSID, Signal, Profil und Authentifizierung prüfen
Adresse 169.254.x.x DHCP-Pfad und VLAN untersuchen
falsches Subnetz VLAN, DHCP-Bereich oder statische Adresse prüfen
kein Gateway DHCP-Option oder statische Konfiguration prüfen
Gateway nicht erreichbar Layer 2, ARP, VLAN, Subnetzmaske oder NAC prüfen
Gateway erreichbar, externe IP nicht Routing, Firewall, VPN oder Internetübergang prüfen
externe IP erreichbar, Name nicht DNS prüfen
Name auflösbar, Port nicht erreichbar Dienst, Firewall oder Zielsystem prüfen
Port erreichbar, Anwendung scheitert TLS, Authentifizierung, Proxy oder Anwendung prüfen
nur mit VPN gestört VPN-Routen, DNS und Filter prüfen
nur ein Benutzer betroffen Benutzerprofil, Proxy, Zertifikat oder Richtlinie prüfen
anderer Client am Port ebenfalls gestört Port, VLAN oder Netzwerkpfad prüfen
Client funktioniert an anderem Port ursprünglichen Anschluss prüfen
Problem nach Neustart verschwunden Ursache weiterhin nicht bewiesen; Ereignisse auswerten
Verbindung nach mehreren Änderungen funktioniert keine eindeutige Ursachenbestätigung möglich

Merksatz

Beginne nicht mit dem Internet, sondern am betroffenen Client: Adapter, Link, IP-Adresse, Gateway, externe IP, DNS und Zielport. Jeder erfolgreiche Test bestätigt nur die bis dahin geprüfte Ebene – nicht die gesamte Netzwerkverbindung.

Quellen und weiterführende Dokumentation

7.2 Mehrere Clients haben kein Netzwerk

Sind mehrere Clients gleichzeitig betroffen, liegt die Ursache meist nicht an jedem einzelnen Endgerät. Gemeinsam genutzte Komponenten und Dienste müssen deshalb zuerst untersucht werden:

Dieser Entscheidungsbaum dient der schnellen Eingrenzung. Die ausführliche Analyse befindet sich auf der Seite 6.2 Mehrere Clients oder ganzer Standort ohne Netzwerk.

1. Betroffenen Bereich bestimmen

Zuerst feststellen, welche Gemeinsamkeit die betroffenen Clients besitzen.

Betroffene Systeme Wahrscheinlicher gemeinsamer Bereich
Clients an einer Netzwerkdose Dose, Kabel, Patchung oder einzelner Switchport
Clients an einem Switch Switch, Uplink, Stromversorgung oder Switchkonfiguration
Clients in einem VLAN VLAN, DHCP-Bereich, Gateway, ACL oder Routing
Clients an einem Access Point Access Point, Uplink, Stromversorgung oder Funkzelle
Clients einer SSID WLAN-Konfiguration, Authentifizierung, RADIUS oder VLAN-Zuweisung
Clients eines Stockwerks Etagenverteiler, Access-Switch oder Uplink
Clients eines Gebäudes Gebäudeverteiler, Firewall, Gateway oder WAN-Verbindung
nur kabelgebundene Clients Switching, Patchung, VLAN oder Ethernet-Uplink
nur WLAN-Clients Access Points, Controller, SSID, RADIUS oder Funknetz
alle Clients eines Standorts Core-Switch, Firewall, Router, WAN, DHCP, DNS oder Stromversorgung
nur interne Dienste betroffen internes Routing, VPN, Firewall, DNS oder Servernetz
nur Internet betroffen Internetrouter, Firewall, NAT, Proxy oder Provider
nur Namen funktionieren nicht DNS-Dienst oder DNS-Erreichbarkeit
nur eine Anwendung betroffen Zielsystem, Dienst, Port, Proxy oder Zertifikat

2. Schneller Hauptentscheidungsbaum

START: Mehrere Clients haben kein Netzwerk
|
+-- Sind wirklich mehrere Clients betroffen?
|   |
|   +-- Nein -> Entscheidungsbaum 7.1 verwenden
|   |
|   +-- Ja
|
+-- Haben die betroffenen Clients eine erkennbare Gemeinsamkeit?
|   |
|   +-- gleicher Switch
|   |      -> Switchstatus, Ports, Uplink und Stromversorgung prüfen
|   |
|   +-- gleiches VLAN
|   |      -> VLAN, Gateway, DHCP, ACL und Routing prüfen
|   |
|   +-- gleicher Access Point oder gleiche SSID
|   |      -> AP, Controller, Authentifizierung und VLAN-Zuweisung prüfen
|   |
|   +-- gleicher Standort
|          -> Core, Firewall, Router, WAN und zentrale Dienste prüfen
|
+-- Besteht bei den Clients ein physischer Link oder eine WLAN-Verbindung?
|   |
|   +-- Nein -> gemeinsame Netzwerkkomponente, Uplink oder Stromversorgung
|   |          untersuchen
|   |
|   +-- Ja
|
+-- Erhalten die Clients gültige IP-Adressen?
|   |
|   +-- Nein oder 169.254.x.x
|   |          -> DHCP, Relay, VLAN, Trunk oder DHCP-Bereich prüfen
|   |
|   +-- Ja
|
+-- Ist das lokale Standardgateway erreichbar?
|   |
|   +-- Nein -> VLAN, Switch-Uplink, Gateway, ARP, STP oder Firewall prüfen
|   |
|   +-- Ja
|
+-- Ist eine externe IP-Adresse erreichbar?
|   |
|   +-- Nein -> Routing, Firewall, NAT, WAN oder Provider prüfen
|   |
|   +-- Ja
|
+-- Funktioniert die Namensauflösung?
|   |
|   +-- Nein -> DNS-Server, DNS-Erreichbarkeit und DNS-Dienst prüfen
|   |
|   +-- Ja
|
+-- Ist nur ein bestimmter Dienst nicht erreichbar?
    |
    +-- Ja  -> Zielsystem, Port, Firewall, Proxy oder Anwendung prüfen
    |
    +-- Nein -> genaue Gemeinsamkeit der betroffenen Verbindungen ermitteln

3. Störungsumfang mit Vergleichstests eingrenzen

Geeignete Vergleichsclients auswählen:

Auf jedem Vergleichsclient möglichst dieselben Prüfungen durchführen:

ipconfig /all

ping <gateway-ip>

ping <freigegebene-externe-ip>

nslookup <zielname>

Test-NetConnection -ComputerName <zielname> -Port <port>

Bewertung

Ergebnis Eingrenzung
alle Clients an einem Switch betroffen Switch oder Uplink priorisieren
mehrere Switches im selben VLAN betroffen VLAN, Gateway oder zentrale Dienste priorisieren
nur ein VLAN betroffen VLAN-spezifische Konfiguration prüfen
alle VLANs betroffen Core, Firewall, Router oder gemeinsame Uplinks prüfen
nur WLAN betroffen WLAN-Infrastruktur priorisieren
Ethernet und WLAN betroffen gemeinsame Dienste oder zentrale Infrastruktur prüfen
externe IP funktioniert, Namen nicht DNS priorisieren
Gateway erreichbar, externe Ziele nicht Routing, Firewall, NAT oder WAN priorisieren
nur ein Ziel nicht erreichbar Zielsystem oder Zielpfad priorisieren

Die Tests müssen unter möglichst gleichen Bedingungen erfolgen. Unterschiedliche VLANs, Berechtigungen oder Netzwerkwege können sonst zu falschen Schlussfolgerungen führen.

4. Besteht noch eine Verbindung zum Netzwerk?

Auf mehreren betroffenen Clients den Adapterstatus prüfen:

Get-NetAdapter

Vollständige IP-Konfiguration anzeigen:

ipconfig /all

Entscheidung

Bei einem räumlich begrenzten Ausfall prüfen:

Die genauen Befehle hängen vom Hersteller und Betriebssystem des Switches ab. Typische Informationen sind:

Entscheidungsbaum

Sind die betroffenen Clients an demselben Switch angeschlossen?
|
+-- Nein
|   -> gemeinsame übergeordnete Komponente suchen
|
+-- Ja
    |
    +-- Ist der Switch erreichbar und betriebsbereit?
        |
        +-- Nein
        |   -> Stromversorgung, Managementzugriff und Hardware prüfen
        |
        +-- Ja
            |
            +-- Ist der Uplink aktiv?
                |
                +-- Nein
                |   -> Kabel, Transceiver, Gegenstelle und Portstatus prüfen
                |
                +-- Ja
                    |
                    +-- Werden die erforderlichen VLANs transportiert?
                        |
                        +-- Nein -> Trunk- und VLAN-Konfiguration prüfen
                        |
                        +-- Ja  -> Gateway, DHCP und Routing prüfen

Ein Switch darf nicht als erste Maßnahme neu gestartet werden. Dadurch gehen möglicherweise Protokolle, Tabellen und der ursprüngliche Fehlerzustand verloren.

6. Prüfen, ob nur ein VLAN betroffen ist

Hinweise auf einen VLAN-Fehler:

Zu prüfen sind:

Entscheidung

7. DHCP-Störung erkennen

Auf mehreren betroffenen Clients prüfen:

ipconfig /all

Typische Hinweise auf einen gemeinsamen DHCP-Fehler:

Schneller DHCP-Entscheidungsbaum

Erhalten mehrere Clients keine gültige Adresse?
|
+-- Nein
|   -> Gateway, Routing, DNS oder Anwendung prüfen
|
+-- Ja
    |
    +-- Sind alle DHCP-Subnetze betroffen?
        |
        +-- Ja
        |   -> DHCP-Dienst, Server, Failover und zentrale Erreichbarkeit prüfen
        |
        +-- Nein
            |
            +-- Nur ein DHCP-Bereich betroffen?
                |
                +-- Ja
                |   -> Bereich, freie Leases, Optionen und Ausschlüsse prüfen
                |
                +-- Nein
                    -> VLAN, Trunk und DHCP-Relay prüfen

Auf einem autorisierten Windows-DHCP-Server können unter anderem folgende Prüfungen verwendet werden:

Get-Service -Name DHCPServer

Get-DhcpServerv4Scope

Get-DhcpServerv4ScopeStatistics

Get-DhcpServerv4Binding

Get-DhcpServerv4Failover

Zu prüfen sind:

Ein autorisierter Paketmitschnitt kann zeigen, an welcher Stelle der DORA-Ablauf endet:

  1. DHCP Discover,
  2. DHCP Offer,
  3. DHCP Request,
  4. DHCP Acknowledge.

8. Bestehende und neue Clients vergleichen

Dieser Vergleich ist bei DHCP-Störungen besonders aussagekräftig.

Beobachtung Mögliche Erklärung
bestehende Clients funktionieren, neue nicht DHCP-Bereich ausgeschöpft oder DHCP-Dienst gestört
Clients funktionieren bis zum Ablauf des Leases Lease-Erneuerung oder DHCP-Erreichbarkeit gestört
Clients mit statischer IP funktionieren DHCP-Pfad priorisieren
statische und dynamische Clients funktionieren nicht Gateway, VLAN, Switch oder Routing priorisieren
nur Clients eines Subnetzes betroffen DHCP-Bereich, Relay oder VLAN prüfen
Clients erhalten unterschiedliche falsche Adressen fremden DHCP-Server oder falsche VLAN-Zuweisung prüfen

Eine frei gewählte statische IP-Adresse sollte nicht unkontrolliert vergeben werden. Sie kann einen Adresskonflikt verursachen und den ursprünglichen Fehler verdecken.

9. Standardgateway prüfen

Auf mehreren Clients das konfigurierte Gateway feststellen:

ipconfig

Gateway testen:

ping <gateway-ip>

Routingtabelle anzeigen:

route print

Alternativ:

Get-NetRoute

Nachbartabelle prüfen:

Get-NetNeighbor

Entscheidung

Ein fehlgeschlagener Ping allein beweist keinen Ausfall des Gateways.

10. Routing, Firewall und Internetübergang prüfen

Wenn das Gateway erreichbar ist, eine freigegebene externe IP-Adresse testen:

ping <freigegebene-externe-ip>

Pfad anzeigen:

tracert <freigegebene-externe-ip>

PowerShell-Test:

Test-NetConnection -ComputerName <freigegebene-externe-ip> -InformationLevel Detailed

Entscheidungsbaum

Ist das lokale Gateway erreichbar?
|
+-- Nein
|   -> lokales VLAN, Switching und Gateway prüfen
|
+-- Ja
    |
    +-- Ist eine externe IP-Adresse erreichbar?
        |
        +-- Ja
        |   -> DNS und Zielanwendung prüfen
        |
        +-- Nein
            |
            +-- Sind interne geroutete Netze erreichbar?
                |
                +-- Ja
                |   -> Firewall, NAT, WAN oder Provider prüfen
                |
                +-- Nein
                    -> internes Routing, Core oder Firewall prüfen

Zu prüfen sind:

11. DNS als gemeinsame Ursache erkennen

Wenn IP-Adressen erreichbar sind, Namen jedoch auf mehreren Clients nicht funktionieren:

nslookup <zielname>

Resolve-DnsName <zielname>

Konfigurierte DNS-Server anzeigen:

Get-DnsClientServerAddress

DNS-Port prüfen:

Test-NetConnection -ComputerName <dns-server> -Port 53

Ein erfolgreicher TCP-Test auf Port 53 ist kein vollständiger DNS-Funktionstest, da DNS abhängig von Anfrage und Umgebung UDP oder TCP verwenden kann.

Entscheidung

DNS-Caches sollten nicht gleichzeitig auf allen Clients gelöscht werden. Zuerst muss geprüft werden, ob tatsächlich ein veralteter Cache-Eintrag vorliegt.

12. WLAN-Ausfall mehrerer Clients

Sind mehrere WLAN-Clients betroffen, zunächst unterscheiden:

Sind alle WLAN-Clients betroffen?
|
+-- Nein
|   |
|   +-- nur ein Access Point
|   |      -> AP, Uplink, Stromversorgung und Funkzelle prüfen
|   |
|   +-- nur eine SSID
|          -> SSID, Authentifizierung, RADIUS und VLAN prüfen
|
+-- Ja
    |
    +-- Ethernet funktioniert?
        |
        +-- Ja
        |   -> WLAN-Controller, zentrale AP-Verwaltung,
        |      RADIUS oder WLAN-Infrastruktur prüfen
        |
        +-- Nein
            -> gemeinsame Switching-, Routing- oder Dienstestörung prüfen

Zusätzlich prüfen:

Wenn Clients mit dem WLAN verbunden sind, aber keine IP-Adresse erhalten, liegt nicht automatisch ein Funkproblem vor. Dann sind insbesondere VLAN und DHCP zu prüfen.

13. Redundanz- und Hochverfügbarkeitsfehler berücksichtigen

Eine vorhandene Redundanz garantiert nicht, dass die Umschaltung funktioniert hat.

Zu prüfen sind:

Mögliche Fehlerbilder:

14. Änderungen und Zeitpunkte korrelieren

Vor Maßnahmen prüfen:

Die zeitliche Nähe einer Änderung ist ein Hinweis, aber noch kein Beweis. Die vermutete Ursache muss durch passende Messwerte, Protokolle oder einen kontrollierten Rückbau bestätigt werden.

15. Beispiel für eine schnelle Diagnose

Symptom

Alle Clients eines Stockwerks melden seit 10:15 Uhr keine Netzwerkverbindung. Andere Stockwerke funktionieren.

Erste Eingrenzung

Clientprüfung

ipconfig /all

Ergebnis auf mehreren Clients:

IPv4-Adresse: 169.254.x.x
Standardgateway:
DHCP aktiviert: Ja

Bewertung

Infrastrukturprüfung

Festgestellte Ursache

Ein defekter Transceiver hat den Uplink des Etagen-Switches unterbrochen.

Kontrollierte Maßnahme

Der defekte Transceiver wurde nach Freigabe durch ein geprüftes Ersatzgerät ersetzt.

Nachprüfung

16. Ungeeignete Sofortmaßnahmen

Nicht als erste Maßnahme verwenden:

Solche Maßnahmen können den Fehler vergrößern, Diagnoseinformationen vernichten oder weitere Netzwerkbereiche beeinträchtigen.

17. Vollständige Schnellprüfreihenfolge

  1. genaue Fehlermeldung und Beginn erfassen.
  2. Anzahl und Standort der betroffenen Clients bestimmen.
  3. funktionierende Vergleichsclients suchen.
  4. gemeinsame Switches, VLANs, Access Points oder Dienste ermitteln.
  5. Ethernet und WLAN getrennt vergleichen.
  6. Adapter- und Linkstatus mehrerer Clients prüfen.
  7. IP-Konfiguration mehrerer Clients vergleichen.
  8. auf 169.254.x.x, falsche Subnetze oder fehlende Gateways achten.
  9. DHCP-Dienst, Bereich und Relay prüfen.
  10. Gateway jedes betroffenen VLANs testen.
  11. lokales Vergleichsziel testen.
  12. externe IP-Adresse testen.
  13. DNS-Auflösung getrennt prüfen.
  14. benötigten Zielport prüfen.
  15. Switchstatus und Uplinks untersuchen.
  16. VLAN- und Trunk-Konfiguration prüfen.
  17. Spanning Tree und Portschutz berücksichtigen.
  18. Firewall, NAT und Routing prüfen.
  19. WAN- und Standortverbindungen prüfen.
  20. Redundanz- und Failoverstatus prüfen.
  21. Ereignisse mit dem Fehlerbeginn korrelieren.
  22. letzte Änderungen ermitteln.
  23. eine gemeinsame Ursache als Hypothese formulieren.
  24. genau eine kontrollierte Maßnahme durchführen.
  25. dieselben Tests nach der Änderung wiederholen.
  26. alle zuvor betroffenen Bereiche testen.
  27. Überwachung und Protokolle kontrollieren.
  28. temporäre Diagnoseänderungen entfernen.
  29. Ursache, Maßnahme und Nachweis dokumentieren.

18. Checkliste „Mehrere Clients haben kein Netzwerk“

19. Schnellreferenz

Ergebnis Nächster Schritt
nur ein Client betroffen Entscheidungsbaum 7.1 verwenden
alle Clients eines Switches betroffen Switch, Stromversorgung und Uplink prüfen
nur ein VLAN betroffen VLAN, Gateway, DHCP, ACL und Trunk prüfen
nur ein Access Point betroffen AP, PoE, Uplink und Funkzelle prüfen
nur eine SSID betroffen SSID, RADIUS, Zertifikate und VLAN-Zuweisung prüfen
alle WLAN-Clients betroffen Controller, RADIUS oder zentrale WLAN-Infrastruktur prüfen
Ethernet und WLAN betroffen gemeinsame Switching-, Routing- oder Dienstekomponente prüfen
mehrere Clients mit 169.254.x.x DHCP-Pfad prüfen
bestehende Clients funktionieren, neue nicht DHCP-Bereich oder DHCP-Dienst prüfen
falsches Subnetz wird vergeben VLAN, DHCP-Relay oder fremden DHCP-Server prüfen
Gateway eines VLANs nicht erreichbar SVI, VLAN, Trunk oder Firewall prüfen
Gateway erreichbar, externe IP nicht Routing, NAT, Firewall oder WAN prüfen
externe IP erreichbar, Name nicht DNS prüfen
nur ein Dienst betroffen Zielsystem, Port, Firewall oder Proxy prüfen
gesamter Standort betroffen Core, Firewall, Router, WAN oder Stromversorgung prüfen
Ausfall nach Änderung Änderung mit Protokollen und Vergleichstest überprüfen
Fehler nach Neustart verschwunden Ursache nicht bewiesen; Protokolle weiter auswerten

Merksatz

Je mehr Clients gleichzeitig betroffen sind, desto wichtiger ist ihre gemeinsame Abhängigkeit. Suche zuerst nach dem gemeinsamen Switch, VLAN, Access Point, Gateway oder zentralen Dienst – nicht nach identischen Einzeldefekten an allen Endgeräten.

Quellen und weiterführende Dokumentation

7.3 „Name geht nicht, IP geht“

Ist ein Ziel über seine IP-Adresse erreichbar, aber nicht über seinen Namen, liegt der Fehler wahrscheinlich im Bereich der Namensauflösung.

Beispiel:

ping 192.0.2.25

funktioniert, aber:

ping server01.example.local

scheitert.

Damit ist jedoch noch nicht automatisch bewiesen, dass ausschließlich der DNS-Server fehlerhaft ist. Auch folgende Ursachen sind möglich:

Dieser Entscheidungsbaum dient der schnellen Eingrenzung. Die ausführliche DNS-Analyse befindet sich im Netzwerk- und Verbindungsfehler-Kapitel.

1. Zuerst die Ausgangslage bestätigen

Zunächst prüfen, ob die Verbindung zur Ziel-IP tatsächlich funktioniert.

Test-NetConnection -ComputerName <ziel-ip> -InformationLevel Detailed

Für einen konkreten Dienst:

Test-NetConnection -ComputerName <ziel-ip> -Port <port>

Danach denselben Test mit dem Namen durchführen:

Test-NetConnection -ComputerName <zielname> -Port <port>

Bewertung

Ergebnis Bedeutung
IP und Name funktionieren DNS-Fehler aktuell nicht reproduzierbar
IP funktioniert, Name wird nicht aufgelöst DNS-Pfad untersuchen
Name wird aufgelöst, aber Verbindung scheitert Dienst, Port, Firewall, Routing oder falsche Zieladresse prüfen
IP und Name scheitern nicht nur DNS untersuchen; Netzwerkpfad oder Zielsystem prüfen
Kurzname scheitert, FQDN funktioniert DNS-Suffix oder Suchliste prüfen
FQDN scheitert ebenfalls DNS-Server, Zone, Eintrag oder Weiterleitung prüfen
Name liefert falsche IP-Adresse Record, Cache, Replikation oder Split-DNS prüfen
nur einzelne Anwendungen scheitern Anwendungscache, Proxy, DoH oder anwendungseigene Namensauflösung prüfen

Ein erfolgreicher Ping auf die IP-Adresse bestätigt nicht, dass der benötigte Dienst erreichbar ist. Deshalb sollte nach Möglichkeit derselbe Zielport einmal über die IP-Adresse und einmal über den Namen getestet werden.

2. Schneller Hauptentscheidungsbaum

START: Name geht nicht, IP geht
|
+-- Ist die Ziel-IP über den benötigten Port erreichbar?
|   |
|   +-- Nein -> Dienst, Firewall, Routing oder Zielsystem prüfen
|   |
|   +-- Ja
|
+-- Wurde der richtige Zielname verwendet?
|   |
|   +-- Unklar -> Schreibweise, Domäne und erwarteten FQDN prüfen
|   |
|   +-- Ja
|
+-- Funktioniert der vollständige FQDN?
|   |
|   +-- Ja, aber Kurzname nicht
|   |          -> DNS-Suffix und Suchliste prüfen
|   |
|   +-- Nein
|
+-- Sind die vorgesehenen DNS-Server eingetragen und erreichbar?
|   |
|   +-- Nein -> DHCP, Adapter, VPN, Routing oder Firewall prüfen
|   |
|   +-- Ja
|
+-- Antworten alle eingetragenen DNS-Server gleich?
|   |
|   +-- Nein -> Zone, Record, Replikation oder Serverzustand prüfen
|   |
|   +-- Ja
|
+-- Liefert die Abfrage einen passenden A- oder AAAA-Eintrag?
|   |
|   +-- Nein -> Zone, Record, Forwarder oder Delegation prüfen
|   |
|   +-- Ja
|
+-- Ist die zurückgegebene IP-Adresse korrekt und erreichbar?
|   |
|   +-- Nein -> falschen oder veralteten Record beziehungsweise Cache prüfen
|   |
|   +-- Ja
|
+-- Funktioniert die Anwendung trotzdem nicht?
    |
    +-- Ja  -> Anwendungscache, Proxy, TLS, VPN, NRPT,
    |          DoH oder Hosts-Datei prüfen
    |
    +-- Nein -> DNS-Auflösung funktioniert

3. Den verwendeten Namen genau dokumentieren

Vor weiteren Tests erfassen:

Beispiele:

server01
server01.example.local
portal.example.com
files.example.local

Ein Kurzname wie server01 ist nicht dasselbe wie der vollständige Name:

server01.example.local

Der Kurzname kann nur funktionieren, wenn der Client ihn mithilfe eines DNS-Suffixes zu einem vollständigen Namen ergänzt oder ein anderes vorgesehenes Namensauflösungsverfahren verwendet.

4. DNS-Konfiguration des Clients prüfen

Vollständige Netzwerkkonfiguration anzeigen:

ipconfig /all

Gezielt die konfigurierten DNS-Server anzeigen:

Get-DnsClientServerAddress

Nur IPv4-DNS-Server:

Get-DnsClientServerAddress -AddressFamily IPv4

DNS-Clientkonfiguration der Adapter anzeigen:

Get-DnsClient

Globale DNS-Einstellungen und Suffixsuchliste anzeigen:

Get-DnsClientGlobalSetting

Zu prüfen sind:

Typische Fehlerbilder

Beobachtung Mögliche Ursache
DNS-Serverfeld ist leer fehlerhafte DHCP-Option oder statische Konfiguration
falscher interner DNS-Server DHCP-, Adapter- oder VPN-Konfiguration
öffentlicher DNS-Server am Domänenclient interne Namen können nicht aufgelöst werden
alter DNS-Server eingetragen veraltete statische Konfiguration
VPN-DNS nur bei bestehender Verbindung erreichbar VPN-Verbindung oder Routing fehlt
mehrere Adapter besitzen unterschiedliche DNS-Server falscher Adapter oder unerwarteter DNS-Pfad
IPv6-DNS verweist auf einen anderen Server unterschiedliche Antwortwege möglich
nur ein Client betroffen lokale Konfiguration, Cache, hosts, VPN oder Richtlinie prüfen
mehrere Clients betroffen DHCP-Option, DNS-Dienst, Zone, Replikation oder Netzwerkpfad prüfen

Die DNS-Server eines Unternehmensclients dürfen nicht versuchsweise durch öffentliche DNS-Server ersetzt werden. Dadurch können interne Namen, Active Directory und unternehmensinterne Dienste zusätzlich gestört werden.

5. DNS-Server auf Erreichbarkeit prüfen

Zuerst die IP-Erreichbarkeit des vorgesehenen DNS-Servers prüfen:

ping <dns-server-ip>

Ein fehlgeschlagener Ping beweist keinen Ausfall, da ICMP blockiert sein kann.

TCP-Port 53 prüfen:

Test-NetConnection -ComputerName <dns-server-ip> -Port 53

Wichtig

Dieser Befehl testet nur TCP-Port 53. Klassische DNS-Abfragen verwenden häufig zunächst UDP-Port 53. Größere Antworten, Zonentransfers und bestimmte weitere Fälle können TCP verwenden.

Ein erfolgreicher TCP-Test bestätigt deshalb nicht vollständig:

Die eigentliche DNS-Funktion muss mit einer DNS-Abfrage geprüft werden.

6. Den Namen gezielt abfragen

Standardabfrage mit dem aktuell verwendeten DNS-Pfad:

Resolve-DnsName <zielname>

Beispiel:

Resolve-DnsName server01.example.local

Gezielt einen bestimmten DNS-Server abfragen:

Resolve-DnsName <zielname> -Server <dns-server-ip>

Alternativ:

nslookup <zielname>

Bestimmten DNS-Server abfragen:

nslookup <zielname> <dns-server-ip>

Zu dokumentieren sind:

nslookup und Resolve-DnsName sind wichtige Diagnosetests. Sie bilden jedoch nicht in jedem Fall exakt denselben Auflösungsweg ab, den eine konkrete Anwendung verwendet. Anwendungen können beispielsweise eigene Caches, Browser-DoH, Proxyauflösung oder andere Bibliotheken benutzen.

7. Jeden konfigurierten DNS-Server einzeln testen

Sind mehrere DNS-Server eingetragen, muss jeder einzeln abgefragt werden.

Beispiel:

Resolve-DnsName server01.example.local -Server 192.0.2.10

Resolve-DnsName server01.example.local -Server 192.0.2.11

Bewertung

DNS-Server 1 DNS-Server 2 Mögliche Ursache
richtige Antwort richtige Antwort Serverantworten sind konsistent
richtige Antwort keine Antwort zweiter Server, Dienst oder Netzwerkpfad gestört
richtige Antwort falsche IP Replikations-, Zonen- oder Recordproblem
Record vorhanden NXDOMAIN Zone oder Record fehlt auf einem Server
beide keine Antwort gemeinsame Erreichbarkeit, Firewall oder Dienst prüfen
beide NXDOMAIN Name, Zone, Delegation oder Forwarder prüfen
unterschiedliche TTL kann durch unterschiedliche Cachezustände entstehen
unterschiedliche Record-Sätze Replikation, Split-DNS oder Lastverteilung prüfen

Wenn nur einer von mehreren DNS-Servern fehlerhaft antwortet, kann das Problem scheinbar zufällig auftreten. Abhängig vom verwendeten Server funktioniert die Namensauflösung dann zeitweise oder nur auf bestimmten Clients.

8. FQDN und Kurzname vergleichen

Vollständigen Namen testen:

Resolve-DnsName server01.example.local

Kurznamen testen:

Resolve-DnsName server01

Entscheidung

Funktioniert der FQDN?
|
+-- Nein
|   -> DNS-Server, Zone, Record, Weiterleitung oder Delegation prüfen
|
+-- Ja
    |
    +-- Funktioniert auch der Kurzname?
        |
        +-- Ja  -> Suffixauflösung funktioniert
        |
        +-- Nein
            -> DNS-Suffix und Suchliste prüfen

DNS-Clientinformationen anzeigen:

Get-DnsClient

Globale Suffixsuchliste anzeigen:

Get-DnsClientGlobalSetting

In ipconfig /all insbesondere prüfen:

Primäres DNS-Suffix
Verbindungsspezifisches DNS-Suffix
DNS-Suffixsuchliste

Mögliche Ursachen bei „FQDN geht, Kurzname geht nicht“

Für Diagnose und Dokumentation ist der FQDN grundsätzlich aussagekräftiger als ein Kurzname.

9. A- und AAAA-Einträge getrennt prüfen

IPv4-Eintrag abfragen:

Resolve-DnsName <zielname> -Type A

IPv6-Eintrag abfragen:

Resolve-DnsName <zielname> -Type AAAA

Mit nslookup:

nslookup -type=A <zielname>

nslookup -type=AAAA <zielname>

Bewertung

Ergebnis Mögliche Ursache
richtiger A-Eintrag, kein AAAA-Eintrag nur IPv4 vorgesehen; nicht automatisch ein Fehler
richtiger AAAA-Eintrag, kein A-Eintrag nur IPv6 vorgesehen; Umgebung prüfen
A-Eintrag zeigt auf alte IP veralteter Record oder Cache
AAAA-Eintrag zeigt auf nicht erreichbares Ziel veralteter IPv6-Record oder fehlerhafter IPv6-Pfad
mehrere A- oder AAAA-Einträge Lastverteilung oder mehrere Zielsysteme möglich
nur eine der gelieferten Adressen funktioniert einzelnen Record und Zielpfad prüfen
CNAME verweist auf nicht auflösbaren Namen Ziel des CNAME prüfen
NXDOMAIN Name oder Zone existiert laut befragtem Server nicht
SERVFAIL Server konnte die Anfrage nicht korrekt verarbeiten

Wenn ein Name mehrere Adressen liefert, müssen alle zurückgegebenen Ziele berücksichtigt werden. Ein einzelner funktionierender Record beweist nicht, dass jeder mögliche Verbindungsversuch erfolgreich ist.

10. Zurückgegebene IP-Adresse überprüfen

Nach erfolgreicher Auflösung prüfen, ob die Antwort dem erwarteten Ziel entspricht.

Resolve-DnsName <zielname>

Danach den benötigten Port an der gelieferten Adresse testen:

Test-NetConnection -ComputerName <zurückgegebene-ip> -Port <port>

Zu klären sind:

Wichtig

„Der Name wird aufgelöst“ bedeutet nur, dass eine DNS-Antwort vorliegt. Die Antwort kann trotzdem falsch, veraltet oder für den aktuellen Netzwerkstandort ungeeignet sein.

11. DNS-Clientcache untersuchen

Cacheeinträge anzeigen:

ipconfig /displaydns

Alternativ:

Get-DnsClientCache

Gezielt nach einem Namen suchen:

Get-DnsClientCache | Where-Object Entry -Like "*<zielname>*"

Zu prüfen sind:

Vergleich

Resolve-DnsName <zielname>

und anschließend gezielt:

Resolve-DnsName <zielname> -Server <dns-server-ip>

Unterscheiden sich Cache und direkte Serverantwort, kann ein veralteter Cacheeintrag vorliegen.

Cache erst nach der Dokumentation leeren:

Clear-DnsClientCache

Alternativ:

ipconfig /flushdns

Danach denselben Test erneut durchführen:

Resolve-DnsName <zielname>

Negativer Cache

Auch eine zuvor fehlgeschlagene Namensauflösung kann zwischengespeichert werden. Wurde der DNS-Eintrag erst danach angelegt, kann der Client bis zum Ablauf des negativen Cacheeintrags weiterhin melden, dass der Name nicht existiert.

Das Leeren des Caches ist nur dann ein aussagekräftiger Test, wenn vorher und nachher dieselbe Abfrage dokumentiert wird.

12. hosts-Datei prüfen

Unter Windows befindet sich die Datei hier:

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

Inhalt mit PowerShell anzeigen:

Get-Content "$env:SystemRoot\System32\drivers\etc\hosts"

Relevante aktive Zeilen anzeigen:

Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" |
    Where-Object { $_ -notmatch '^\s*#' -and $_ -notmatch '^\s*$' }

Mögliche Fehler:

Beispiel eines problematischen Eintrags:

192.0.2.40 server01.example.local

Wenn der Server inzwischen die Adresse 192.0.2.50 verwendet, kann der Client trotz korrektem DNS-Eintrag weiterhin das alte Ziel verwenden.

Ein Eintrag darf erst nach Sicherung und Freigabe kontrolliert geändert oder entfernt werden. Nicht jede Anwendung verwendet zwingend den identischen Windows-Auflösungsweg.

13. Zone und Resource Record auf dem DNS-Server prüfen

Auf einem autorisierten Windows-DNS-Server können die vorhandenen Zonen angezeigt werden:

Get-DnsServerZone

Bestimmte Zone prüfen:

Get-DnsServerZone -Name "<zone>"

Resource Record suchen:

Get-DnsServerResourceRecord -ZoneName "<zone>" -Name "<hostname>"

A- und AAAA-Records der Zone anzeigen:

Get-DnsServerResourceRecord -ZoneName "<zone>" -RRType A

Get-DnsServerResourceRecord -ZoneName "<zone>" -RRType AAAA

Zu prüfen sind:

Beispiel

Der Client fragt ab:

server01.example.local

Dafür müssen mindestens folgende Bestandteile stimmen:

Zone: example.local
Name: server01
Typ: A oder AAAA
Wert: vorgesehene IP-Adresse

Ein korrekt aussehender Record auf einem DNS-Server genügt nicht, wenn Clients auch andere DNS-Server verwenden.

14. TTL und veraltete Antworten berücksichtigen

Die TTL bestimmt, wie lange ein Resolver einen DNS-Record zwischenspeichern darf.

TTL mit PowerShell prüfen:

Resolve-DnsName <zielname>

Ausführlich mit nslookup:

nslookup -debug <zielname>

Mögliche Situation:

  1. ein Record zeigte auf eine alte IP-Adresse,
  2. der Record wurde auf dem DNS-Server korrigiert,
  3. ein Client oder zwischengeschalteter Resolver besitzt noch die alte Antwort,
  4. der Client verwendet diese bis zum Ablauf der TTL weiter.

Zu berücksichtigen sind:

Eine kurze TTL löst keine falsche Zonen- oder Replikationskonfiguration. Eine lange TTL ist ebenfalls nicht automatisch fehlerhaft, verlängert aber die mögliche Nutzungsdauer eines veralteten Cacheeintrags.

15. Zonenreplikation prüfen

Bei Active-Directory-integrierten Zonen prüfen:

Zone auf mehreren Servern gezielt vergleichen:

Get-DnsServerResourceRecord `
    -ComputerName <dns-server-1> `
    -ZoneName "<zone>" `
    -Name "<hostname>"

Get-DnsServerResourceRecord `
    -ComputerName <dns-server-2> `
    -ZoneName "<zone>" `
    -Name "<hostname>"

Hinweise auf ein Replikationsproblem

Die Zone oder der Record sollte nicht einfach auf jedem Server manuell nachgebaut werden. Zuerst muss geklärt werden, warum die vorgesehene Replikation nicht funktioniert.

16. Forwarder und Conditional Forwarder prüfen

Forwarder auf einem Windows-DNS-Server anzeigen:

Get-DnsServerForwarder

Conditional Forwarder anzeigen:

Get-DnsServerZone |
    Where-Object ZoneType -EQ "Forwarder"

Details einer Weiterleitungszone prüfen:

Get-DnsServerConditionalForwarderZone -Name "<zone>"

Zu prüfen sind:

Gezielte Prüfung des Zielservers:

Resolve-DnsName <zielname> -Server <forwarder-ip>

Entscheidung

Betrifft der Fehler nur Namen einer bestimmten Domäne?
|
+-- Nein
|   -> allgemeinen DNS-Dienst und Clientpfad prüfen
|
+-- Ja
    |
    +-- Ist der lokale DNS-Server für die Zone autoritativ?
        |
        +-- Ja  -> Zone, Record und Replikation prüfen
        |
        +-- Nein
            |
            +-- Existiert ein Conditional Forwarder oder eine Delegation?
                |
                +-- Nein -> vorgesehene Namensarchitektur prüfen
                |
                +-- Ja  -> Zielserver, Erreichbarkeit und Antwort prüfen

17. Delegation prüfen

Bei einer delegierten untergeordneten Zone müssen die übergeordnete Zone und die zuständigen Nameserver korrekt auf die untergeordnete Zone verweisen.

Nameserver abfragen:

Resolve-DnsName <untergeordnete-zone> -Type NS

SOA-Eintrag prüfen:

Resolve-DnsName <untergeordnete-zone> -Type SOA

Zu prüfen sind:

Typisches Fehlerbild

host.abteilung.example.local

Die Zone:

abteilung.example.local

wurde auf separate DNS-Server delegiert. Die übergeordnete Zone kennt jedoch einen alten Nameserver. Dadurch funktioniert die übrige Domäne, während nur Namen unterhalb der delegierten Zone scheitern.

18. UDP und TCP auf Port 53 unterscheiden

DNS verwendet sowohl UDP als auch TCP.

Typische Gründe für TCP-Nutzung:

Nur TCP testen:

Test-NetConnection -ComputerName <dns-server-ip> -Port 53

Eine tatsächliche DNS-Abfrage ausführen:

Resolve-DnsName <zielname> -Server <dns-server-ip>

Abfrage ausdrücklich über TCP erzwingen:

Resolve-DnsName <zielname> -Server <dns-server-ip> -TcpOnly

Bewertung

Normale Abfrage Abfrage mit -TcpOnly Mögliche Eingrenzung
funktioniert funktioniert UDP und TCP wahrscheinlich nutzbar
scheitert funktioniert UDP 53 oder UDP-Antwortpfad untersuchen
funktioniert scheitert TCP 53 untersuchen
beide scheitern DNS-Dienst, Erreichbarkeit, Firewall oder Name prüfen
kleine Antworten funktionieren, große nicht Fragmentierung, MTU, EDNS oder TCP-Fallback prüfen

Firewallregeln dürfen nicht pauschal deaktiviert werden. Stattdessen sind erlaubte und blockierte DNS-Verbindungen gezielt anhand von Quelle, Ziel, Protokoll und Port zu prüfen.

19. Split-DNS berücksichtigen

Bei Split-DNS liefert derselbe Name abhängig vom verwendeten DNS-System unterschiedliche Antworten.

Beispiel:

portal.example.com

Intern:

10.10.20.25

Extern:

198.51.100.25

Vergleichsabfragen:

Resolve-DnsName portal.example.com -Server <interner-dns-server>

Resolve-DnsName portal.example.com -Server <vorgesehener-externer-dns-server>

Zu prüfen sind:

Typisches Fehlerbild

Die interne Zone example.com existiert, enthält aber keinen Record für portal. Der interne DNS-Server fragt deshalb möglicherweise nicht extern weiter, sondern beantwortet die Anfrage aus seiner eigenen autoritativen Zone mit einem negativen Ergebnis.

20. VPN, NRPT und DNS-Routing prüfen

VPN-Clients können abhängig von ihrer Konfiguration:

DNS-Konfiguration vor und nach der VPN-Verbindung vergleichen:

Get-DnsClientServerAddress

Get-DnsClientGlobalSetting

NRPT-Regeln anzeigen:

Get-DnsClientNrptPolicy

Zusätzlich, abhängig von der Windows-Version:

Get-DnsClientNrptRule

Zu prüfen sind:

Vergleich

Zustand Ergebnis Eingrenzung
ohne VPN fehlerhaft, mit VPN erfolgreich interner DNS nur über VPN vorgesehen
ohne VPN erfolgreich, mit VPN fehlerhaft VPN-DNS, NRPT oder Tunnelrouting prüfen
nur interne Namen fehlerhaft internen DNS-Pfad und Suffix prüfen
interne und externe Namen fehlerhaft VPN-DNS-Konfiguration oder allgemeine Erreichbarkeit prüfen
FQDN funktioniert, Kurzname nicht Suffixänderung durch VPN prüfen

21. DNS over HTTPS berücksichtigen

Bei DNS over HTTPS, kurz DoH, werden DNS-Abfragen verschlüsselt über HTTPS übertragen. Dadurch kann eine Anwendung oder der Windows-DNS-Client einen anderen DNS-Pfad verwenden als bei klassischem DNS über Port 53.

Windows-Konfiguration unterstützter DoH-Server anzeigen:

Get-DnsClientDohServerAddress

Zu prüfen sind:

Typische Hinweise

Beobachtung Mögliche Ursache
Resolve-DnsName funktioniert, Browser nicht Browsercache, Browser-DoH, Proxy oder Anwendung prüfen
Browser funktioniert, andere Anwendungen nicht Browser verwendet möglicherweise eigenen Resolver oder DoH
interne Namen nur im Browser fehlerhaft Browser-DoH umgeht möglicherweise internen DNS
klassischer DNS-Port 53 blockiert, DoH funktioniert unterschiedliche DNS-Pfade
Fehler nur nach Aktivierung von sicherem DNS DoH-Konfiguration oder verwendeten Resolver prüfen

DoH sollte nicht ungeprüft deaktiviert oder umkonfiguriert werden. Zuerst ist festzustellen, welcher Auflösungsweg tatsächlich vorgesehen ist.

22. DNS-Servercache berücksichtigen

Auch ein DNS-Server kann veraltete positive oder negative Antworten zwischenspeichern.

Cacheeinträge eines autorisierten Windows-DNS-Servers anzeigen:

Show-DnsServerCache

Gezielt sollte geprüft werden:

Beispiel:

Resolve-DnsName <zielname> -Server <lokaler-dns-server>

Resolve-DnsName <zielname> -Server <autoritativ-dns-server>

Der Servercache darf nicht als erste Maßnahme vollständig geleert werden. Vorher müssen betroffene Einträge, TTL, Serverantworten und Zeitpunkt dokumentiert werden.

23. CNAME-Ketten vollständig prüfen

CNAME-Abfrage:

Resolve-DnsName <zielname> -Type CNAME

Normale Abfrage:

Resolve-DnsName <zielname>

Beispiel:

portal.example.local
    CNAME -> webfarm.example.local
    A     -> 192.0.2.80

Zu prüfen sind:

Ein vorhandener CNAME genügt nicht. Die gesamte Kette bis zum abschließenden A- oder AAAA-Record muss funktionieren.

24. DNS-Antwortcodes richtig bewerten

Antwort Bedeutung Nächster Schritt
NOERROR mit Antwort Abfrage wurde erfolgreich beantwortet Record und Adresse prüfen
NOERROR ohne gesuchten Record Name kann existieren, aber der angefragte Typ fehlt Record-Typ und Zonendaten prüfen
NXDOMAIN der abgefragte Name existiert laut antwortendem Server nicht Schreibweise, Zone, Record, Cache und Replikation prüfen
SERVFAIL Server konnte die Anfrage nicht erfolgreich verarbeiten DNSSEC, Weiterleitung, Delegation, Serverprotokolle oder Erreichbarkeit prüfen
REFUSED Server lehnt die Anfrage ab Richtlinie, Rekursion, ACL oder Serverrolle prüfen
Zeitüberschreitung keine rechtzeitige Antwort Dienst, Netzwerkpfad, Firewall, UDP/TCP oder Auslastung prüfen

Ein NXDOMAIN ist eine DNS-Antwort und nicht dasselbe wie eine Zeitüberschreitung. Bei NXDOMAIN hat ein DNS-Server geantwortet, konnte den Namen jedoch in seinem Auflösungspfad nicht als vorhanden bestätigen.

25. Anwendungen getrennt vom DNS-System testen

Wenn Befehlszeilentests funktionieren, die Anwendung jedoch weiterhin scheitert, prüfen:

Vergleichstests

Resolve-DnsName <zielname>

Test-NetConnection -ComputerName <zielname> -Port <port>

Test-NetConnection -ComputerName <aufgelöste-ip> -Port <port>

Wenn diese Tests erfolgreich sind, muss der konkrete Auflösungs- und Verbindungsweg der Anwendung untersucht werden.

26. Beispiel für eine schnelle Diagnose

Symptom

Ein Benutzer kann den internen Fileserver über seine IP-Adresse erreichen:

\\192.0.2.25\Freigabe

Der Zugriff über den Namen scheitert:

\\fileserver.example.local\Freigabe

IP-Prüfung

Test-NetConnection -ComputerName 192.0.2.25 -Port 445

Ergebnis:

TcpTestSucceeded : True

Namensprüfung

Resolve-DnsName fileserver.example.local

Ergebnis:

Name       : fileserver.example.local
Type       : A
IPAddress  : 192.0.2.20

Bewertung

Vergleich der DNS-Server

Resolve-DnsName fileserver.example.local -Server 192.0.2.10

Ergebnis:

IPAddress : 192.0.2.25

Resolve-DnsName fileserver.example.local -Server 192.0.2.11

Ergebnis:

IPAddress : 192.0.2.20

Festgestellte Ursache

Der aktualisierte A-Record wurde aufgrund einer gestörten Active-Directory-Replikation noch nicht auf den zweiten DNS-Server übertragen.

Kontrollierte Maßnahme

Nachprüfung

Resolve-DnsName fileserver.example.local -Server 192.0.2.10

Resolve-DnsName fileserver.example.local -Server 192.0.2.11

Beide Server liefern:

IPAddress : 192.0.2.25

Zusätzlich:

Test-NetConnection -ComputerName fileserver.example.local -Port 445

Ergebnis:

TcpTestSucceeded : True

Die Freigabe funktioniert anschließend wieder über den vorgesehenen Namen.

27. Ungeeignete Sofortmaßnahmen

Nicht als erste Maßnahme verwenden:

Solche Maßnahmen können den ursprünglichen Zustand verändern, Beweise beseitigen oder zusätzliche Fehler in Active Directory, VPN und internen Anwendungen verursachen.

28. Vollständige Schnellprüfreihenfolge

  1. genaue Fehlermeldung und Uhrzeit erfassen.
  2. verwendeten Namen exakt dokumentieren.
  3. erwartete Ziel-IP und Zielport feststellen.
  4. Zielport über die IP-Adresse prüfen.
  5. Zielport über den Namen prüfen.
  6. FQDN und Kurzname getrennt testen.
  7. aktive Netzwerkadapter ermitteln.
  8. konfigurierte DNS-Server dokumentieren.
  9. DNS-Suffix und Suchliste prüfen.
  10. VPN und virtuelle Adapter berücksichtigen.
  11. jeden eingetragenen DNS-Server einzeln abfragen.
  12. Antworten und TTL miteinander vergleichen.
  13. A- und AAAA-Records getrennt prüfen.
  14. CNAME-Kette untersuchen.
  15. zurückgegebene IP-Adressen einzeln testen.
  16. Clientcache anzeigen und dokumentieren.
  17. negative Cacheeinträge berücksichtigen.
  18. hosts-Datei kontrollieren.
  19. Zone und Resource Record auf dem DNS-Server prüfen.
  20. Record auf allen zuständigen DNS-Servern vergleichen.
  21. Zonen- oder AD-Replikation untersuchen.
  22. Forwarder und Conditional Forwarder prüfen.
  23. Delegation und Nameserver prüfen.
  24. UDP und TCP 53 unterscheiden.
  25. Split-DNS berücksichtigen.
  26. VPN-Routing, DNS-Zuweisung und NRPT prüfen.
  27. DoH und anwendungseigene Resolver berücksichtigen.
  28. genau eine Hypothese formulieren.
  29. genau eine kontrollierte Maßnahme durchführen.
  30. dieselben Abfragen erneut ausführen.
  31. jeden vorgesehenen DNS-Server erneut testen.
  32. den benötigten Dienst über den Namen prüfen.
  33. Vergleichsclient oder Vergleichsstandort testen.
  34. temporäre Diagnoseänderungen entfernen.
  35. Ursache, Maßnahme und Nachweis dokumentieren.

29. Checkliste „Name geht nicht, IP geht“

30. Schnellreferenz

Ergebnis Nächster Schritt
IP und Zielport funktionieren, Name nicht DNS-Pfad untersuchen
IP funktioniert, Zielport nicht Dienst oder Firewall prüfen
FQDN funktioniert, Kurzname nicht DNS-Suffix und Suchliste prüfen
kein DNS-Server eingetragen DHCP- oder Adapterkonfiguration prüfen
falscher DNS-Server eingetragen vorgesehene Clientkonfiguration prüfen
DNS-Server nicht erreichbar Routing, VPN, Firewall oder Server prüfen
ein DNS-Server antwortet, ein anderer nicht zweiten Server oder Netzwerkpfad prüfen
DNS-Server liefern unterschiedliche IPs Record, Replikation oder Split-DNS prüfen
A korrekt, AAAA falsch IPv6-Record und IPv6-Pfad prüfen
AAAA korrekt, A falsch IPv4-Record und IPv4-Pfad prüfen
Name liefert alte IP Record, TTL und Cache prüfen
direkte Serverabfrage korrekt, Clientantwort falsch Clientcache, hosts oder Resolverpfad prüfen
NXDOMAIN Name, Zone, Record, Replikation oder Weiterleitung prüfen
SERVFAIL Server, DNSSEC, Forwarder oder Delegation prüfen
FQDN in bestimmter Domäne scheitert Conditional Forwarder oder Delegation prüfen
nur intern fehlerhaft interne Zone, Split-DNS oder internen Resolver prüfen
nur extern fehlerhaft Forwarder, Rekursion oder externen DNS-Pfad prüfen
nur mit VPN fehlerhaft VPN-DNS, NRPT, Suffix oder Routing prüfen
nur ohne VPN fehlerhaft interner DNS möglicherweise nur über VPN erreichbar
PowerShell funktioniert, Browser nicht Browsercache, DoH, Proxy oder Anwendung prüfen
normale Abfrage scheitert, -TcpOnly funktioniert UDP 53 oder UDP-Antwortpfad prüfen
TCP-Abfrage scheitert TCP 53, Firewall oder DNS-Dienst prüfen
CNAME vorhanden, Ziel nicht auflösbar vollständige CNAME-Kette prüfen
Fehler nur auf einem Client Cache, hosts, Adapter, VPN oder DoH prüfen
Fehler auf mehreren Clients DNS-Dienst, DHCP-Option, Zone oder Replikation prüfen

Merksatz

Wenn die IP-Adresse funktioniert, der Name aber nicht, wird von unten nach oben geprüft: richtiger Name, FQDN, Client-DNS, einzelner DNS-Server, A und AAAA, Cache, Zone, Record, Replikation und Weiterleitung. Eine DNS-Antwort ist erst dann brauchbar, wenn sie vom vorgesehenen Server kommt und auf das richtige erreichbare Ziel verweist.

Quellen und weiterführende Dokumentation

7.4 VLAN- und Switching-Fehleranalyse

Ein Client besitzt eine gültige IP-Konfiguration, kann aber bestimmte Geräte, Server oder Netze nicht erreichen. Andere Clients am gleichen Standort funktionieren möglicherweise problemlos. In solchen Fällen kann die Ursache auf der Sicherungsschicht liegen:

Die Diagnose muss vom betroffenen Endgerät über jeden beteiligten Switch bis zum Gateway beziehungsweise Zielsystem erfolgen.

Ein Symptom ist noch keine Ursache. Ein erreichbarer Switch beweist nicht, dass das betroffene VLAN auf dem vollständigen Datenpfad korrekt transportiert wird.

1. Typische Fehlerbilder

Beobachtung Mögliche Ursache
nur ein Client ist betroffen Access-Port, Kabel, Netzwerkkarte, VLAN-Zuordnung oder Port-Security
alle Clients an einem Switch sind betroffen Uplink, Trunk, EtherChannel, STP oder Switchausfall
nur ein VLAN ist betroffen VLAN fehlt, Trunk-Liste, SVI, Gateway oder STP-Instanz
Clients im gleichen VLAN kommunizieren nicht falsches VLAN, Port-Isolation, Private VLAN, ACL oder lokale Firewall
lokale Geräte sind erreichbar, Gateway nicht Uplink, Trunk, SVI oder Gateway
Gateway erreichbar, andere VLANs nicht Routing, ACL oder Firewall statt reines Layer-2-Problem
Fehler tritt nur an einem Standort auf lokaler Switch, Trunk, Standort-Uplink oder VLAN-Bereitstellung
Fehler tritt nur an einem Port auf Portkonfiguration, Kabel, Port-Security oder Hardware
Verbindung funktioniert nach Umstecken unterschiedliche VLAN- oder Portkonfiguration
Verbindung fällt wiederholt kurz aus Link-Flapping, STP-Änderungen, EtherChannel oder Hardware
IP-Telefon funktioniert, angeschlossener PC nicht Voice-VLAN korrekt, Data-VLAN oder Trunk zum Telefon fehlerhaft
DHCP funktioniert nicht, statische IP teilweise schon DHCP-Relay, DHCP-Serverpfad oder falsches VLAN
MAC-Adresse erscheint ständig an anderen Ports Schleife, falsch verbundene Switches oder MAC-Flapping

2. Sollzustand vor der Diagnose feststellen

Vor der Fehlersuche muss bekannt sein, wie der Port und der Datenpfad vorgesehen sind.

Zu dokumentieren sind:

Beispiel:

Client:              client01
MAC-Adresse:         00:11:22:33:44:55
Switch:              access-sw01
Port:                GigabitEthernet1/0/12
Access-VLAN:         20
IP-Netz:             192.0.2.0/24
Gateway:             192.0.2.1
Uplink:               GigabitEthernet1/0/48
Trunk-VLANs:          10,20,30
Distribution-Switch: dist-sw01
SVI:                  Vlan20

Ohne diesen Sollzustand lässt sich eine vorhandene Konfiguration nicht zuverlässig als richtig oder falsch bewerten.

3. Umfang der Störung bestimmen

Zuerst prüfen:

Vergleichstests

Vergleich Aussage
anderer Client am gleichen Port grenzt Client und Port gegeneinander ab
gleicher Client an bekannt funktionierendem Port prüft Client gegen Switchport
anderer Client im gleichen VLAN prüft Umfang innerhalb des VLANs
Client in anderem VLAN am gleichen Switch grenzt VLAN gegen allgemeinen Switchfehler ab
gleiches VLAN an anderem Switch grenzt lokalen Switch oder Uplink ein
Gateway desselben VLANs prüft den Layer-2-Pfad bis zum Gateway
Ziel im gleichen Subnetz prüft lokale Layer-2-Kommunikation
Ziel in anderem Subnetz bezieht zusätzlich Routing und Firewall ein

Ein Gerät darf nur kontrolliert umgesteckt werden. Vorher müssen ursprünglicher Port, VLAN-Zuordnung und Konfiguration dokumentiert werden.

4. Clientkonfiguration prüfen

Unter Windows:

ipconfig /all

Get-NetAdapter

Get-NetIPConfiguration

Get-NetIPAddress

Get-NetRoute -AddressFamily IPv4

Unter Linux:

ip address show

ip route show

Unter macOS:

ifconfig

route -n get default

Zu prüfen sind:

Eine gültig aussehende IP-Adresse beweist nicht, dass der Client am richtigen VLAN angeschlossen ist. In verschiedenen VLANs können ähnliche oder versehentlich überlappende Adressbereiche vorkommen.

5. Physische Verbindung und Portstatus prüfen

Am Client prüfen:

Get-NetAdapter |
    Format-Table Name, InterfaceDescription, Status, LinkSpeed, MacAddress

Auf einem Cisco-IOS-/IOS-XE-Switch beispielsweise:

show interfaces status

Gezielten Port prüfen:

show interfaces GigabitEthernet1/0/12

Kurze Fehlerübersicht:

show interfaces counters errors

Zu prüfen sind:

Typische Bewertungen

Status oder Zähler Mögliche Ursache
notconnect kein Link, Kabel, Client oder Gegenstelle
disabled Port administrativ deaktiviert
err-disabled Schutzfunktion oder erkannter Fehler
viele CRC-Fehler Kabel, Stecker, Transceiver, Duplex oder physische Störung
viele Input Errors physischer Fehler, Überlastung oder fehlerhafte Frames
viele Output Drops Überlastung oder Warteschlange
Geschwindigkeit unerwartet niedrig Kabel, Aushandlung oder Gegenstelle
Link wechselt ständig Kabel, Netzwerkkarte, Transceiver, Energieversorgung oder Port

Zähler sollten zuerst dokumentiert und danach über einen festgelegten Zeitraum erneut abgelesen werden. Ein hoher historischer Wert allein beweist keinen aktuell fortbestehenden Fehler.

6. Nachbarschaft und tatsächlichen Port ermitteln

Cisco Discovery Protocol:

show cdp neighbors

Details:

show cdp neighbors detail

show lldp neighbors

Details:

show lldp neighbors detail

Zu prüfen sind:

CDP oder LLDP kann deaktiviert sein. Ein fehlender Nachbar beweist deshalb nicht, dass keine Verbindung besteht.

7. VLAN-Zuordnung des Access-Ports prüfen

VLAN-Übersicht:

show vlan brief

Portbezogene Switchportinformationen:

show interfaces GigabitEthernet1/0/12 switchport

Relevante Portkonfiguration:

show running-config interface GigabitEthernet1/0/12

Zu prüfen sind:

Beispiel eines vorgesehenen Access-Ports:

interface GigabitEthernet1/0/12
 switchport mode access
 switchport access vlan 20

Mögliche Fehler

switchport access vlan 10

obwohl der Client VLAN 20 verwenden soll.

Oder der Port arbeitet unerwartet als Trunk:

switchport mode trunk

Eine Konfigurationszeile allein reicht nicht zur Bewertung. Administrative und operative Zustände müssen miteinander verglichen werden.

8. Existenz und Status des VLANs prüfen

show vlan brief

Gezielt:

show vlan id 20

Zu prüfen sind:

Wichtig

Ein Access-Port kann auf ein VLAN verweisen, das auf dem Switch nicht ordnungsgemäß vorhanden oder aktiv ist. Ebenso beweist die Existenz des VLANs auf einem Access-Switch nicht, dass es auf allen weiteren Switches des Pfades verfügbar ist.

VLANs dürfen nicht vorschnell neu angelegt werden. Zuerst muss geklärt werden, ob das VLAN absichtlich entfernt wurde oder über ein vorgesehenes Verwaltungsverfahren bereitgestellt werden soll.

9. MAC-Adresse des Clients ermitteln

Unter Windows:

Get-NetAdapter |
    Format-Table Name, MacAddress, Status

Unter Linux:

Unter macOS:

ifconfig

Die MAC-Adresse muss dem tatsächlich verwendeten physischen Adapter zugeordnet werden. WLAN-, Ethernet-, Docking-, VPN- und virtuelle Adapter besitzen unterschiedliche MAC-Adressen.

Beispiel:

00-11-22-33-44-55

Auf Cisco-Switches wird sie normalerweise ohne Trennzeichen oder mit Punktgruppen gesucht:

0011.2233.4455

10. MAC-Adress-Tabelle prüfen

Gesamte Tabelle:

show mac address-table

Bestimmte MAC-Adresse suchen:

show mac address-table address 0011.2233.4455

MAC-Adressen eines VLANs:

show mac address-table vlan 20

MAC-Adressen eines Ports:

show mac address-table interface GigabitEthernet1/0/12

Zu prüfen sind:

Bewertung

Beobachtung Mögliche Ursache
MAC am richtigen Access-Port und VLAN lokaler Layer-2-Eingang grundsätzlich erkannt
MAC im falschen VLAN falsche Access-, Voice- oder Tagging-Konfiguration
MAC auf falschem Port falsche Dokumentation, Verkabelung oder Schleife
MAC nur am Uplink Client befindet sich hinter einem anderen Gerät
MAC fehlt Client sendet nicht, falscher Port, Linkproblem oder Filterung
MAC wechselt zwischen Ports Schleife, doppelte Verbindung oder MAC-Flapping
sehr viele MAC-Adressen am Clientport möglicherweise weiterer Switch oder Bridge angeschlossen

Die MAC-Adresse muss auf jedem Switch entlang des Pfades verfolgt werden. Auf einem Access-Switch sollte sie am Clientport erscheinen, auf nachgelagerten Switches am jeweiligen Uplink in Richtung des Clients.

11. Layer-2-Pfad anhand der MAC-Adresse verfolgen

Beispiel:

Client
  |
  | Gi1/0/12, VLAN 20
  |
Access-Switch
  |
  | Gi1/0/48, Trunk
  |
Distribution-Switch
  |
  | Port-Channel1, Trunk
  |
Gateway-SVI Vlan20

Prüfung auf dem Access-Switch:

show mac address-table address 0011.2233.4455

Erwartung:

VLAN 20 -> GigabitEthernet1/0/12

Prüfung auf dem Distribution-Switch:

show mac address-table address 0011.2233.4455

Erwartung:

VLAN 20 -> GigabitEthernet1/0/48

oder:

VLAN 20 -> Port-channel1

Verschwindet die MAC-Adresse an einem Übergang, sind insbesondere zu prüfen:

12. Trunkstatus prüfen

Trunkübersicht:

show interfaces trunk

Gezielten Port prüfen:

show interfaces GigabitEthernet1/0/48 switchport

Konfiguration anzeigen:

show running-config interface GigabitEthernet1/0/48

Zu prüfen sind:

Beispiel:

interface GigabitEthernet1/0/48
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,30

Wenn VLAN 20 benötigt wird, muss es auf jedem Trunk des vollständigen Pfades zugelassen und aktiv sein.

13. Allowed-VLAN-Liste auf jedem Trunk vergleichen

show interfaces trunk

Beispiel eines Fehlers:

Access-Switch:
Allowed VLANs: 10,20,30

Distribution-Switch:
Allowed VLANs: 10,30

VLAN 20 ist nur auf einer Seite zugelassen. Geräte in VLAN 10 und VLAN 30 funktionieren, während VLAN 20 den Trunk nicht vollständig passieren kann.

Typische Ursachen

Eine Allowed-VLAN-Liste darf nicht pauschal auf „alle VLANs“ erweitert werden. Dadurch können Segmentierung, Sicherheit und vorgesehene Netzgrenzen verändert werden.

14. Native VLAN prüfen

Auf beiden Seiten des Trunks:

show interfaces trunk

show interfaces <trunk-port> switchport

Beispiel eines Mismatch:

Switch A: Native VLAN 999
Switch B: Native VLAN 1

Mögliche Auswirkungen:

Native VLANs müssen entsprechend der vorgesehenen Architektur auf beiden Seiten übereinstimmen. Ein Mismatch darf nicht dadurch „gelöst“ werden, dass wahllos VLAN 1 verwendet wird.

15. Access-Port und Trunk nicht verwechseln

Access-Port

Trunk-Port

Typische Fehlkonfigurationen

Seite A Seite B Mögliche Folge
Access VLAN 20 Access VLAN 20 korrekt für eine einfache Verbindung im selben VLAN
Trunk Trunk korrekt, wenn VLANs und Native VLAN übereinstimmen
Access Trunk VLAN-Mismatch und unerwartete Zuordnung
Access VLAN 10 Access VLAN 20 ungetaggter Verkehr wird verschiedenen VLANs zugeordnet
Trunk mit VLAN 20 Trunk ohne VLAN 20 VLAN 20 kann den Pfad nicht vollständig nutzen
Trunk Native 999 Trunk Native 1 Native-VLAN-Mismatch

16. Clientseitiges VLAN-Tagging berücksichtigen

Ein normaler Arbeitsplatzclient sendet an einem Access-Port gewöhnlich keine VLAN-Tags. VLAN-Tagging am Client kann jedoch vorkommen bei:

Zu prüfen sind:

Beispiel eines Fehlers:

Server-NIC taggt VLAN 20
Switchport ist Access-Port in VLAN 20

Abhängig von Gerät und Konfiguration kann der getaggte Frame verworfen oder unerwartet verarbeitet werden.

17. Voice-VLAN und IP-Telefone prüfen

Beispiel:

interface GigabitEthernet1/0/12
 switchport mode access
 switchport access vlan 20
 switchport voice vlan 30

Dabei kann gelten:

PC-Daten:       VLAN 20
Telefonverkehr: VLAN 30

Zu prüfen sind:

Dass das Telefon funktioniert, beweist nicht, dass auch das Data-VLAN korrekt eingerichtet ist.

18. ARP beziehungsweise Neighbor Cache prüfen

Unter Windows:

Get-NetNeighbor

arp -a

Unter Linux:

ip neighbor show

Unter macOS:

arp -a

Zu prüfen sind:

Bewertung

Beobachtung Mögliche Eingrenzung
Gateway-Eintrag ist erreichbar Layer-2-Kommunikation zum Gateway grundsätzlich möglich
Gateway bleibt Incomplete ARP-Anfrage oder Antwort erreicht das Ziel nicht
falsche Gateway-MAC falsches Gerät, doppelte IP, Fehlkonfiguration oder Angriff
lokales Ziel im gleichen VLAN nicht auflösbar Layer-2-Pfad, Zielgerät oder lokale Firewall prüfen
Gateway erreichbar, anderes Subnetz nicht Routing, ACL oder Firewall untersuchen

ARP darf erst nach Dokumentation kontrolliert geleert werden. Ein Cache-Reset beseitigt sonst möglicherweise relevante Hinweise.

19. Gateway-SVI prüfen

Auf einem Layer-3-Switch beispielsweise:

show ip interface brief

Gezielt:

show interfaces Vlan20

Konfiguration:

show running-config interface Vlan20

ARP-Tabelle:

show ip arp

Zu prüfen sind:

Typisches Fehlerbild

Vlan20 is administratively up, line protocol is down

Mögliche Ursache:

Ein erreichbares SVI in einem anderen VLAN beweist nicht, dass das SVI des betroffenen VLANs funktioniert.

20. Kommunikation innerhalb und außerhalb des VLANs trennen

Vom Client aus nacheinander prüfen:

  1. eigene IP-Konfiguration,
  2. Ziel im gleichen VLAN,
  3. Standardgateway,
  4. Ziel in einem anderen internen VLAN,
  5. externes Ziel.

Windows:

Test-NetConnection -ComputerName <ziel-im-gleichen-vlan>

Test-NetConnection -ComputerName <gateway-ip>

Test-NetConnection -ComputerName <ziel-in-anderem-vlan> -Port <port>

Bewertung

Gleiches VLAN Gateway Anderes VLAN Eingrenzung
fehlerhaft fehlerhaft fehlerhaft Access-VLAN, Layer-2-Pfad oder Client prüfen
erfolgreich fehlerhaft fehlerhaft Gateway-SVI, Trunk oder Gateway prüfen
erfolgreich erfolgreich fehlerhaft Routing, ACL oder Firewall prüfen
erfolgreich erfolgreich erfolgreich konkrete Anwendung oder Zielport prüfen

Ping kann durch eine Firewall blockiert werden. Für die Prüfung eines Dienstes ist zusätzlich der tatsächlich benötigte TCP- oder UDP-Port zu berücksichtigen.

21. Spanning-Tree-Zustand prüfen

Übersicht:

show spanning-tree

Bestimmtes VLAN:

show spanning-tree vlan 20

Bestimmten Port:

show spanning-tree interface GigabitEthernet1/0/48 detail

Zu prüfen sind:

Ein durch Spanning Tree blockierter redundanter Port ist nicht automatisch fehlerhaft. Die Blockierung kann notwendig sein, um eine Layer-2-Schleife zu verhindern.

Problematisch ist beispielsweise:

22. Spanning-Tree-Änderungen und Schleifen untersuchen

show spanning-tree detail

Zusätzlich Systemprotokoll prüfen:

show logging

Hinweise auf mögliche Schleifen:

Die physische Schleife darf nicht durch dauerhaftes Deaktivieren von Spanning Tree „behoben“ werden. Dadurch kann die Störung massiv verschärft werden.

23. MAC-Flapping prüfen

Protokolle untersuchen:

show logging

MAC-Adresse gezielt suchen:

show mac address-table address <mac-adresse>

Wiederholt prüfen, ob der Port wechselt.

Beispiel:

VLAN 20, MAC 0011.2233.4455:
Gi1/0/47 -> Gi1/0/48 -> Gi1/0/47

Mögliche Ursachen:

Ein MAC-Wechsel ist nicht immer ein Fehler. Bei Clustern oder Redundanzmechanismen kann eine virtuelle MAC kontrolliert den Port wechseln. Häufigkeit, Zeitpunkt und vorgesehene Architektur müssen berücksichtigt werden.

24. EtherChannel beziehungsweise Port-Channel prüfen

Übersicht:

show etherchannel summary

Port-Channel prüfen:

show interfaces Port-channel1

Trunkstatus:

show interfaces trunk

Konfiguration der Mitglieder vergleichen:

show running-config interface GigabitEthernet1/0/47

show running-config interface GigabitEthernet1/0/48

Zu prüfen sind:

Typische Fehler

25. Port-Security prüfen

Auf Cisco-Switches beispielsweise:

show port-security

Gezielter Port:

show port-security interface GigabitEthernet1/0/12

Portstatus:

show interfaces status err-disabled

Zu prüfen sind:

Typisches Fehlerbild

Ein Arbeitsplatz wird von einem PC auf eine Dockingstation umgestellt. Dadurch erscheint eine neue MAC-Adresse. Wenn nur eine bestimmte MAC zugelassen ist, kann der Port den Verkehr verwerfen oder in einen Fehlerzustand wechseln.

Port-Security darf nicht pauschal deaktiviert werden. Zuerst sind vorgesehene Sicherheitsrichtlinie, erlaubte Geräte und tatsächlich erkannte MAC-Adressen zu prüfen.

26. Weitere Schutzfunktionen berücksichtigen

Abhängig von der Umgebung können unter anderem beteiligt sein:

Mögliche Prüfungen auf Cisco-Geräten:

show authentication sessions

show dot1x all

show ip dhcp snooping

show ip arp inspection

show interfaces status err-disabled

show logging

Die tatsächlich verfügbaren Befehle hängen von Plattform und Softwareversion ab.

Typische Fehlerbilder

Beobachtung Mögliche Funktion
Port erhält nach Anmeldung anderes VLAN 802.1X oder dynamische VLAN-Zuweisung
DHCP-Antworten werden verworfen DHCP Snooping
ARP-Pakete werden verworfen Dynamic ARP Inspection
Port nach Anschluss eines Switches deaktiviert BPDU Guard
Datenverkehr oberhalb eines Grenzwerts verworfen Storm Control
Clients im gleichen VLAN sehen sich nicht Port-Isolation oder Private VLAN
nur autorisierte MAC funktioniert Port-Security oder NAC

27. err-disabled-Ursache untersuchen

show interfaces status err-disabled

show errdisable recovery

show logging

Je nach Plattform können Ursachen sein:

Der Port darf nicht einfach wieder aktiviert werden, ohne die Ursache zu beseitigen. Andernfalls tritt der Fehler erneut auf oder eine Schleife wird wieder in Betrieb genommen.

Kontrollierte Wiederaktivierung erst nach Ursachenklärung:

interface <port>
 shutdown
 no shutdown

Dieser Eingriff verändert den Zustand und unterbricht die Verbindung. Er darf nur autorisiert und nach Sicherung der Diagnoseinformationen erfolgen.

28. Paketmitschnitt für VLAN-Tags verwenden

Ein Paketmitschnitt kann zeigen:

Wireshark-Anzeigefilter für VLAN-Verkehr:

vlan

Bestimmte VLAN-ID:

vlan.id == 20

ARP:

arp

DHCP:

dhcp

LLDP:

lldp

STP:

stp

Wichtig

Ein Endgerät an einem normalen Access-Port sieht üblicherweise keine IEEE-802.1Q-Tags für sein Access-VLAN. Der Switch fügt die VLAN-Zuordnung intern hinzu beziehungsweise entfernt das Tag am Access-Port.

Für eine aussagekräftige Analyse auf einem Switch kann ein kontrolliert konfigurierter Mirror- oder SPAN-Port erforderlich sein. Mitschnitte dürfen nur autorisiert erfolgen und können vertrauliche Daten, Adressen, Namen und Anmeldeinformationen enthalten.

Netzwerkkarten und Treiber können VLAN-Tags vor der Übergabe an die Aufzeichnungssoftware verarbeiten. Das Fehlen eines sichtbaren Tags beweist daher nicht in jedem Mitschnitt, dass auf dem beobachteten Netzwerkpfad kein Tag verwendet wurde.

29. Beispiel für eine systematische Diagnose

Symptom

Ein Client erhält keine Verbindung zu internen Diensten. Andere Clients am gleichen Switch funktionieren.

Sollzustand

Clientport:    GigabitEthernet1/0/12
Access-VLAN:   20
Gateway:       192.0.2.1
Uplink:        GigabitEthernet1/0/48

Clientprüfung

ipconfig /all

Ergebnis:

IPv4-Adresse: 192.0.2.45
Gateway:      192.0.2.1

Portprüfung

show interfaces GigabitEthernet1/0/12 switchport

Ergebnis:

Operational Mode: static access
Access Mode VLAN: 20

MAC-Prüfung

show mac address-table address 0011.2233.4455

Ergebnis:

VLAN 20    0011.2233.4455    DYNAMIC    Gi1/0/12

Der Client wird am richtigen lokalen Port und im richtigen VLAN gelernt.

Trunkprüfung

show interfaces trunk

Ergebnis am Access-Switch:

Port Gi1/0/48
Allowed VLANs: 10,20,30

Ergebnis am Distribution-Switch:

Port Gi1/0/48
Allowed VLANs: 10,30

Festgestellte Ursache

VLAN 20 war auf der Distribution-Seite des Trunks nicht zugelassen. Dadurch wurde die Client-MAC am Access-Switch gelernt, der Datenverkehr erreichte jedoch nicht das Gateway.

Kontrollierte Maßnahme

Nach Prüfung des Sollzustands und Sicherung der Konfiguration wurde VLAN 20 auf der fehlenden Trunkseite ergänzt.

Nachprüfung

Auf beiden Switches:

show interfaces trunk

Ergebnis:

Allowed VLANs: 10,20,30

MAC-Adresse auf dem Distribution-Switch:

show mac address-table address 0011.2233.4455

Ergebnis:

VLAN 20    0011.2233.4455    DYNAMIC    Gi1/0/48

Clienttest:

Test-NetConnection -ComputerName 192.0.2.1

Der Client erreicht anschließend das Gateway und die vorgesehenen Dienste.

30. Beispiel „Port sieht korrekt aus, Client ist trotzdem im falschen VLAN“

Symptom

Der Client ist an Port GigabitEthernet1/0/12 dokumentiert. Die Prüfung dieses Ports zeigt das richtige VLAN. Der Client erhält trotzdem eine Adresse aus einem anderen Subnetz.

Prüfung der MAC-Adresse

show mac address-table address 0011.2233.4455

Ergebnis:

VLAN 30    0011.2233.4455    DYNAMIC    Gi1/0/18

Festgestellte Ursache

Der Client war physisch an Port GigabitEthernet1/0/18 angeschlossen. Die Dokumentation war veraltet. Port 18 gehörte zu VLAN 30.

Lehre

Nicht nur den dokumentierten Port prüfen. Der tatsächliche Port muss anhand von MAC-Adresse, LLDP/CDP, Verkabelung oder Portstatus bestätigt werden.

31. Ungeeignete Sofortmaßnahmen

Nicht als erste Maßnahme verwenden:

Solche Maßnahmen können Diagnoseinformationen beseitigen, Sicherheitsgrenzen verändern oder eine Layer-2-Schleife verursachen.

32. Vollständige Schnellprüfreihenfolge

  1. genaue Störung, Zeitpunkt und Auswirkung dokumentieren.
  2. feststellen, ob ein oder mehrere Clients betroffen sind.
  3. vorgesehenes VLAN, Subnetz und Gateway ermitteln.
  4. tatsächliche Client-MAC-Adresse feststellen.
  5. tatsächlichen Switch und Port ermitteln.
  6. physischen Linkstatus prüfen.
  7. Fehlerzähler dokumentieren.
  8. Portmodus prüfen.
  9. Access- und Voice-VLAN prüfen.
  10. Existenz und Status des VLANs prüfen.
  11. Client-MAC in der MAC-Tabelle suchen.
  12. MAC-Adresse über alle beteiligten Switches verfolgen.
  13. jeden Uplink und Trunk ermitteln.
  14. operativen Trunkstatus prüfen.
  15. Allowed-VLAN-Listen auf beiden Seiten vergleichen.
  16. Native VLAN auf beiden Seiten vergleichen.
  17. VLAN-Existenz auf jedem Switch prüfen.
  18. Spanning-Tree-Zustand für das betroffene VLAN prüfen.
  19. blockierte oder inkonsistente Ports untersuchen.
  20. Topology Changes und MAC-Flapping prüfen.
  21. EtherChannel und seine Mitglieder prüfen.
  22. Port-Security und err-disabled prüfen.
  23. 802.1X, NAC und dynamische VLAN-Zuweisung berücksichtigen.
  24. DHCP Snooping, ARP Inspection und IP Source Guard prüfen.
  25. Gateway-SVI und dessen Status prüfen.
  26. ARP- beziehungsweise Neighbor-Einträge untersuchen.
  27. Kommunikation im gleichen VLAN testen.
  28. Gateway separat testen.
  29. Inter-VLAN-Kommunikation separat testen.
  30. bei Bedarf autorisierten Paketmitschnitt durchführen.
  31. genau eine Hypothese formulieren.
  32. genau eine kontrollierte Maßnahme durchführen.
  33. Port-, VLAN-, Trunk-, STP- und MAC-Zustand erneut prüfen.
  34. Clientverbindung und benötigten Dienst erneut testen.
  35. Ursache, Änderung und Nachweis dokumentieren.

33. Checkliste VLAN und Switching

34. Schnellreferenz

Ergebnis Nächster Schritt
Port ist notconnect Kabel, Client, Transceiver und Gegenstelle prüfen
Port ist err-disabled genaue Schutz- oder Fehlerursache ermitteln
viele neue CRC-Fehler physischen Pfad und Aushandlung prüfen
Client erhält falsches Subnetz Access-VLAN, dynamische VLAN-Zuweisung und DHCP prüfen
MAC fehlt vollständig tatsächlichen Port, Clientübertragung und Link prüfen
MAC erscheint im falschen VLAN Access-, Voice- oder Client-Tagging prüfen
MAC erscheint am falschen Port Verkabelung, Dokumentation oder Schleife prüfen
MAC wechselt zwischen Ports Schleife, Teaming, Cluster oder EtherChannel prüfen
VLAN fehlt auf einem Switch vorgesehene VLAN-Bereitstellung prüfen
VLAN fehlt in Allowed-Liste Trunkkonfiguration auf beiden Seiten vergleichen
Native VLAN unterscheidet sich Mismatch kontrolliert korrigieren
Trunk nur auf einer Seite aktiv Portmodus und Aushandlung prüfen
nur ein VLAN über Trunk gestört VLAN-Existenz, Allowed-Liste und STP prüfen
alle VLANs über Uplink gestört Link, Trunk, EtherChannel und Hardware prüfen
STP blockiert redundanten Port prüfen, ob Blockierung vorgesehen ist
STP meldet PVID-Inkonsistenz Native VLAN und Portmodi vergleichen
viele Topology Changes Schleife, instabilen Link oder Root-Wechsel suchen
gleicher VLAN-Verkehr funktioniert Layer-2-Pfad grundsätzlich vorhanden
Gateway nicht per ARP erreichbar VLAN-Pfad, Trunk und SVI prüfen
Gateway erreichbar, andere VLANs nicht Routing, ACL oder Firewall prüfen
Telefon funktioniert, PC nicht Data-VLAN und PC-Port des Telefons prüfen
PC funktioniert, Telefon nicht Voice-VLAN, LLDP/CDP und Voice-DHCP prüfen
nur ein EtherChannel-Mitglied aktiv LACP und Mitgliedskonfiguration vergleichen
Paketmitschnitt zeigt falsche VLAN-ID Taggingquelle und Portmodus prüfen
Paketmitschnitt zeigt am Access-Port kein Tag kann bei einem Access-Port normal sein

Merksatz

Bei VLAN- und Switching-Fehlern wird der Datenpfad nicht erraten, sondern anhand von Portstatus, VLAN-Zuordnung, MAC-Adresse, Trunk, Spanning Tree und Gateway Schritt für Schritt verfolgt. Ein VLAN funktioniert erst dann, wenn es auf jedem beteiligten Switch vorhanden, auf jedem Trunk zugelassen und über einen freigegebenen Layer-2-Pfad bis zum vorgesehenen Gateway transportiert wird.

Quellen und weiterführende Dokumentation

7.5 Netzwerk ist langsam

Ein langsames Netzwerk liegt vor, wenn benötigte Daten oder Anwendungen zwar grundsätzlich erreichbar sind, die tatsächliche Leistung jedoch deutlich unter dem vorgesehenen oder bisher üblichen Niveau liegt.

„Langsam“ ist zunächst nur eine subjektive Wahrnehmung. Für eine belastbare Diagnose muss das Verhalten durch Messwerte wie Antwortzeit, Paketverlust, Jitter, Durchsatz, Fehlerzähler oder Serverauslastung beschrieben werden.

Kurzbeschreibung

Die Ursache kann auf unterschiedlichen Ebenen liegen:

Ein erfolgreicher Ping beweist lediglich eine grundsätzliche IP-Erreichbarkeit. Er beweist weder einen ausreichenden Datendurchsatz noch eine fehlerfreie Anwendung oder einen leistungsfähigen Server.

Typische Symptome

Mögliche Auswirkungen

Sicherheits- und Betriebswarnung

Leistungsprüfungen können selbst erhebliche Netzlast verursachen. Insbesondere iperf3, große Dateiübertragungen, parallele Verbindungen und UDP-Tests dürfen nur kontrolliert und autorisiert eingesetzt werden.

Vor Veränderungen müssen dokumentiert werden:

Nicht mehrere Einstellungen gleichzeitig verändern. Sonst lässt sich nicht mehr eindeutig feststellen, welche Änderung das Ergebnis beeinflusst hat.

1. Die Aussage „langsam“ messbar machen

Zuerst muss das genaue Verhalten beschrieben werden.

Zu klären sind:

Ungeeignete Beschreibung

Das Netzwerk ist langsam.

Geeignete Beschreibung

Dateiübertragungen vom Client 192.0.2.45 zum Server 192.0.2.80
erreichen seit 14:00 Uhr nur noch etwa 35 Mbit/s.

Bisheriger Vergleichswert: ungefähr 850 Mbit/s
Clientanschluss: 1 Gbit/s Ethernet
Andere Clients: nicht betroffen
Ping zum Server: durchschnittlich 1 ms

Erst die zweite Beschreibung ermöglicht eine gezielte Eingrenzung.

2. Umfang der Störung bestimmen

Beobachtung Wahrscheinlicher Prüfbereich
nur ein Client betroffen Client, Netzwerkkarte, Kabel, Switchport oder lokale Software
alle Clients eines Switches betroffen Uplink, Switch, VLAN, Spanning Tree oder Überlastung
nur WLAN-Clients betroffen Funkversorgung, Kanalbelegung, SNR, Access Point oder WLAN-Uplink
alle Clients eines Standorts betroffen Standort-Uplink, Firewall, Router oder WAN
nur ein Zielserver betroffen Server, Anwendung, Storage oder Serveranschluss
nur externe Ziele betroffen Internetanschluss, WAN, Firewall, Proxy oder Provider
nur VPN-Verkehr betroffen VPN-Gateway, Verschlüsselungsleistung, MTU oder Tunnelpfad
nur zu bestimmten Uhrzeiten Backup, Synchronisation, Scan, Update oder planmäßige Last
nur Upload langsam asymmetrische Auslastung, Rückweg, Duplex, Provider oder Traffic Shaping
nur große Übertragungen langsam Paketverlust, TCP, MTU, Storage oder Überlastung

Zum Vergleich möglichst denselben Vorgang durchführen:

Dabei darf keine Sicherheitskontrolle umgangen werden.

3. Sollleistung richtig bestimmen

Die angezeigte Verbindungsgeschwindigkeit ist nicht mit dem nutzbaren Anwendungsdurchsatz gleichzusetzen.

Linkgeschwindigkeit ≠ tatsächlicher Datendurchsatz

Bei einer Ethernet-Verbindung mit 1 Gbit/s ist der nutzbare Durchsatz aufgrund von Protokoll- und Verwaltungsdaten geringer. Zusätzlich können beteiligt sein:

Auch Einheiten müssen unterschieden werden:

1 Byte = 8 Bit

Beispiel:

100 MB/s × 8 = 800 Mbit/s

Eine Anwendung, die 100 MB/s anzeigt, überträgt somit ungefähr 800 Mbit/s, bevor zusätzlicher Protokolloverhead berücksichtigt wird.

4. Client und verwendeten Netzwerkadapter prüfen

Unter Windows:

Get-NetAdapter |
    Format-Table Name, InterfaceDescription, Status, LinkSpeed, MacAddress

Ausführliche IP-Konfiguration:

Get-NetIPConfiguration

Aktive IP-Adressen:

Get-NetIPAddress

Unter Linux:

ip address show

Unter macOS:

ifconfig

Zu prüfen sind:

Ein Client kann gleichzeitig mehrere aktive Adapter besitzen. Der tatsächlich verwendete Pfad muss anhand von Routingtabelle, Quelladresse und Schnittstelle bestätigt werden.

Unter Windows:

Get-NetRoute -AddressFamily IPv4 |
    Sort-Object RouteMetric |
    Format-Table DestinationPrefix, NextHop, InterfaceAlias, RouteMetric

5. Linkgeschwindigkeit und Duplex prüfen

Unter Windows:

Get-NetAdapter |
    Format-Table Name, Status, LinkSpeed

Auf Cisco-IOS-/IOS-XE-Switches beispielsweise:

show interfaces status

Gezielter Port:

show interfaces GigabitEthernet1/0/12

Zu prüfen sind:

Typisches Fehlerbild

Erwartet: 1 Gbit/s Full Duplex
Tatsächlich: 100 Mbit/s

Mögliche Ursachen:

Bei einem Duplex-Mismatch können extrem niedrige Leistung, Verbindungsunterbrechungen und Fehlerzähler auftreten.

Geschwindigkeit und Duplex dürfen nicht nur auf einer Seite verändert werden. Beide Seiten müssen kompatibel konfiguriert sein. Normalerweise wird die automatische Aushandlung verwendet, sofern Geräte- und Betriebsvorgaben nichts anderes verlangen.

6. Fehler- und Verwerfungszähler prüfen

Unter Windows:

Get-NetAdapterStatistics

Alle verfügbaren Werte eines Adapters:

Get-NetAdapterStatistics -Name "Ethernet" |
    Format-List *

Unter Linux:

ip -s link show

Alternativ, sofern vorhanden:

ethtool -S <interface>

Auf Cisco-Switches:

show interfaces GigabitEthernet1/0/12

Kurze Fehlerübersicht:

show interfaces counters errors

Zu prüfen sind:

Bewertung

Zähler Mögliche Ursache
zunehmende CRC-/FCS-Fehler Kabel, Stecker, Transceiver oder physische Störung
Late Collisions möglicher Duplex-Mismatch
Input Discards Überlastung, Puffer oder Filterung
Output Drops Ausgangswarteschlange oder überlasteter Folgelink
Interface Resets instabiler Link, Treiber oder Hardware
Runts oder Giants fehlerhafte Frames, MTU oder physische Störung
keine Fehler, aber geringe Leistung Auslastung, TCP, Server, Storage oder Anwendung prüfen

Zähler zuerst dokumentieren und später erneut ablesen.

Ausgangswert: 12 CRC-Fehler
Nach 10 Minuten: 12 CRC-Fehler

Der Wert ist historisch vorhanden, steigt während des Tests jedoch nicht.

Ausgangswert: 12 CRC-Fehler
Nach 10 Minuten: 4.850 CRC-Fehler

Der Fehler besteht weiterhin und muss untersucht werden.

7. Latenz, Schwankung und Paketverlust messen

Windows:

ping <ziel-ip> -n 20

Mit festgelegter Paketgröße:

ping <ziel-ip> -n 20 -l 1400

Linux:

ping -c 20 <ziel-ip>

macOS:

ping -c 20 <ziel-ip>

Zu dokumentieren sind:

Beispiel

Minimum:      1 ms
Maximum:     85 ms
Durchschnitt: 4 ms
Paketverlust: 0 %

Der Durchschnitt wirkt niedrig, einzelne starke Ausschläge können für Sprache, Video oder interaktive Anwendungen dennoch relevant sein.

Wichtig

Ein Ping verwendet ICMP. Netzwerkgeräte können ICMP:

Paketverlust oder hohe Antwortzeiten an einem einzelnen Zwischenrouter beweisen daher noch keine Störung des weitergeleiteten Nutzverkehrs.

8. Stufenweise unterschiedliche Ziele testen

Die Messung sollte vom nahen zum entfernten Ziel erfolgen:

  1. eigenes TCP/IP-System,
  2. Standardgateway,
  3. Ziel im gleichen VLAN,
  4. Ziel in einem anderen internen VLAN,
  5. interner Server,
  6. externes Ziel.

Beispiel:

ping <gateway-ip> -n 20

ping <lokaler-server> -n 20

ping <entfernter-server> -n 20

Bewertung

Gateway Lokaler Server Entferntes Ziel Eingrenzung
langsam langsam langsam Client, Zugang, Switchport oder lokales Netz
schnell langsam langsam interner Pfad ab Gateway oder Servernetz
schnell schnell langsam WAN, Internet, VPN oder entfernter Standort
überall schnell Anwendung langsam Anwendung oder Server genauer prüfen

Verglichen werden müssen Messungen vom selben Client und möglichst zum selben Zeitpunkt.

9. Netzwerkpfad ermitteln

Unter Windows:

tracert -d <ziel-ip>

pathping -n <ziel-ip>

PowerShell:

Test-NetConnection -ComputerName <ziel> -TraceRoute

Unter Linux:

traceroute -n <ziel-ip>

Alternativ, sofern vorhanden:

mtr -n <ziel-ip>

Unter macOS:

traceroute -n <ziel-ip>

pathping kombiniert eine Pfadermittlung mit wiederholten ICMP-Messungen. Die Ausführung benötigt einige Zeit.

Zu prüfen sind:

Vorsicht bei der Bewertung

Wenn ein Zwischenrouter ICMP nicht beantwortet, nachfolgende Ziele aber normal erreichbar sind, ist der Zwischenrouter nicht automatisch ausgefallen. Für die Eingrenzung ist entscheidend, ob sich die Verschlechterung bis zum Ziel fortsetzt.

10. Tatsächlichen Durchsatz mit iperf3 messen

iperf3 misst die erreichbare Netzwerkleistung zwischen einem Server und einem Client. Dadurch lässt sich der reine Netzwerkpfad besser von Dateiablage, Anwendung und Datenträger trennen.

Auf einem autorisierten Testsystem:

iperf3 -s

Auf dem Client:

iperf3 -c <server-ip>

Längere Messung:

iperf3 -c <server-ip> -t 30

Umgekehrte Richtung:

iperf3 -c <server-ip> -R

Mehrere parallele Datenströme:

iperf3 -c <server-ip> -P 4

Bidirektionaler Test, sofern von der verwendeten Version unterstützt:

iperf3 -c <server-ip> --bidir

UDP-Test nur mit kontrollierter Bandbreite:

iperf3 -c <server-ip> -u -b 100M -t 20

Wichtige Werte

Bewertung

Ergebnis Eingrenzung
iperf3 schnell, Dateiübertragung langsam Serverdienst, Protokoll oder Storage prüfen
iperf3 ebenfalls langsam Netzwerkpfad, Client oder Gegenstelle prüfen
normale Richtung schnell, -R langsam richtungsabhängige Störung untersuchen
ein Datenstrom langsam, mehrere schnell Latenz, TCP-Fenster oder einzelne Flussbegrenzung prüfen
UDP zeigt Verlust oder hohen Jitter Überlastung, WLAN oder Warteschlangen untersuchen

Mehrere parallele Datenströme können Engpässe verdecken oder zusätzliche Last erzeugen. Sie ersetzen nicht den normalen Einzelstromtest.

Die ESnet-Dokumentation unterstützt iperf3 offiziell hauptsächlich unter Linux, FreeBSD und macOS. Unter Windows verwendete Builds können von Drittanbietern stammen und müssen gesondert bewertet werden.

11. Messung innerhalb einzelner Segmente durchführen

Der End-to-End-Pfad sollte in Abschnitte unterteilt werden.

Client
  |
Access-Switch
  |
Distribution-Switch
  |
Firewall oder Router
  |
WAN oder Internet
  |
Zielserver

Mögliche Vergleichsmessungen:

Client -> lokaler Testserver
Client -> Server im anderen VLAN
Client -> Server hinter der Firewall
Client -> Server am entfernten Standort

Beispiel

Testpfad Ergebnis
Client → lokaler Server 940 Mbit/s
Client → anderes VLAN 925 Mbit/s
Client → Server hinter Firewall 180 Mbit/s
Client → entfernter Standort 175 Mbit/s

Die deutliche Abweichung beginnt im Beispiel am Pfad über die Firewall. Dort sind anschließend Schnittstellen, CPU, Sicherheitsinspektion, VPN und Bandbreitenbegrenzungen zu untersuchen.

12. Switchports und Uplinks vergleichen

Auf Cisco-Switches beispielsweise:

show interfaces status

show interfaces counters errors

show interfaces GigabitEthernet1/0/12

show interfaces GigabitEthernet1/0/48

Zu prüfen sind:

Beispiel

48 Clients mit jeweils 1-Gbit/s-Port
teilen sich einen einzelnen 1-Gbit/s-Uplink.

Nicht alle Clients übertragen dauerhaft mit voller Geschwindigkeit. Bei gleichzeitiger hoher Nutzung kann der Uplink jedoch zum Engpass werden.

Ein schneller Access-Port garantiert deshalb keine entsprechend schnelle End-to-End-Verbindung.

13. Auslastung und Warteschlangen prüfen

Ein ausgelasteter Link kann folgende Auswirkungen haben:

Zu prüfen sind:

Eine niedrige Durchschnittsauslastung schließt kurzzeitige Überlastung nicht aus. Sekunden- oder Minutenmittelwerte können kurze Spitzen verdecken.

14. Ethernet und WLAN getrennt vergleichen

Wenn ein betroffener Client WLAN verwendet, sollte – sofern vorgesehen und möglich – eine Vergleichsmessung über Ethernet durchgeführt werden.

Ethernet WLAN Eingrenzung
schnell langsam Funkstrecke, Access Point oder WLAN-Konfiguration
langsam langsam gemeinsamer Pfad, Client, Server oder Anwendung
nur ein WLAN-Client langsam andere WLAN-Clients schnell Client, Treiber, Frequenzband oder Standort
alle Clients eines Access Points langsam andere APs schnell Access Point, Funkkanal oder AP-Uplink

Die reine WLAN-Verbindungsrate ist nicht der tatsächlich nutzbare Durchsatz. WLAN verwendet ein gemeinsam genutztes Funkmedium und enthält zusätzlichen Verwaltungsaufwand.

15. WLAN-Signal und Signal-Rausch-Abstand prüfen

Unter Windows:

netsh wlan show interfaces

Unter macOS können abhängig von Version und verfügbaren Werkzeugen die WLAN-Diagnose oder Systeminformationen verwendet werden.

Zu prüfen sind:

Wichtig

Ein starkes Signal allein beweist keine gute WLAN-Leistung. Auch bei guter Signalstärke können folgende Probleme bestehen:

16. WLAN-Kanalauslastung und Airtime prüfen

WLAN-Clients teilen sich die verfügbare Sendezeit eines Funkkanals. Ein einzelner langsamer oder weit entfernter Client kann für die gleiche Datenmenge mehr Airtime benötigen als ein Client mit hoher Datenrate.

Zu prüfen sind:

Ein breiterer Kanal erhöht nicht automatisch die Leistung. In einer dicht belegten Umgebung kann eine größere Kanalbreite zusätzliche Überschneidungen und Störungen verursachen.

17. Firewall, Router, VPN und Proxy prüfen

Wenn die Leistung erst beim Überschreiten eines bestimmten Netzsegments einbricht, sind beteiligte Netzwerkdienste zu untersuchen.

Zu prüfen sind:

Vergleich

Interner Test ohne Firewallpfad: 930 Mbit/s
Test über Firewall:              210 Mbit/s

Dieses Ergebnis weist auf den zusätzlichen Pfad als Prüfbereich hin, beweist aber noch nicht, welche einzelne Funktion die Begrenzung verursacht.

Sicherheitsfunktionen dürfen nicht unkontrolliert deaktiviert werden. Stattdessen sind vorhandene Statistiken, Protokolle, Regelzähler und Herstellerdiagnosen zu verwenden.

18. VPN-Leistung untersuchen

Bei langsamen VPN-Verbindungen zusätzlich prüfen:

Ein Full-Tunnel kann auch allgemeinen Internetverkehr durch das Unternehmensnetz führen. Dadurch können VPN-Gateway und Standortanbindung zusätzlich belastet werden.

19. MTU und Fragmentierung prüfen

Eine fehlerhafte MTU kann dazu führen, dass kleine Pakete funktionieren, während größere Übertragungen langsam sind oder abbrechen.

Windows-Test mit gesetztem „Don’t Fragment“-Bit:

ping <ziel-ip> -f -l 1472

Bei IPv4 entsprechen 1472 Byte Nutzdaten zusammen mit 20 Byte IPv4-Header und 8 Byte ICMP-Header insgesamt 1500 Byte.

Wenn das Paket zu groß ist, die Größe schrittweise reduzieren:

ping <ziel-ip> -f -l 1400

Linux:

ping -M do -s 1472 <ziel-ip>

Zu prüfen sind:

Wichtig

Ein erfolgreicher Ping mit kleinen Paketen schließt ein MTU-Problem nicht aus.

Die maximal nutzbare Größe darf nicht aus einem einzelnen Test verallgemeinert werden. IPv4, IPv6, Tunnel und verwendete Protokolle besitzen unterschiedliche Header und Anforderungen.

20. TCP-Wiederholungen und Empfangsfenster analysieren

Paketverlust führt bei TCP normalerweise zu erneuten Übertragungen. Dadurch sinkt der nutzbare Durchsatz, obwohl die Verbindung nicht vollständig ausfällt.

Wireshark-Anzeigefilter:

tcp.analysis.retransmission

Weitere mögliche Wiederholungen:

tcp.analysis.fast_retransmission

tcp.analysis.spurious_retransmission

Verloren vermutete Segmente:

tcp.analysis.lost_segment

Empfangsfenster vollständig belegt:

tcp.analysis.window_full

Empfänger meldet ein Empfangsfenster von null:

tcp.analysis.zero_window

Alle TCP-Analysehinweise:

tcp.analysis.flags

Zu prüfen sind:

Bewertung

Beobachtung Mögliche Ursache
viele Retransmissions Paketverlust, Überlastung, WLAN oder fehlerhafter Pfad
Zero Window vom Server Server oder Anwendung verarbeitet Daten nicht schnell genug
Zero Window vom Client Client oder Anwendung nimmt Daten nicht schnell genug ab
Window Full Sender erreicht das angekündigte Empfangsfenster
viele Out-of-Order-Pakete parallele Pfade, Paketverlust oder Mitschnittposition
TCP Reset Anwendung, Firewall oder Gegenstelle beendet Verbindung

Wireshark-Analysekennzeichnungen beruhen auf dem beobachteten Mitschnitt. Fehlende Pakete können auch durch die Mitschnittposition, Capture Drops oder Offloading entstehen.

21. Paketmitschnitt kontrolliert durchführen

Ein Paketmitschnitt kann zeigen:

Beispielhafte Wireshark-Filter:

ip.addr == <client-ip> && ip.addr == <server-ip>

Nur TCP-Verkehr zwischen zwei Systemen:

tcp && ip.addr == <client-ip> && ip.addr == <server-ip>

TCP-Analysehinweise:

tcp.analysis.flags

ICMP-Fehlermeldungen:

icmp

DNS:

dns

HTTP-Antwortzeiten müssen im Kontext der Anwendung bewertet werden. Bei verschlüsseltem HTTPS-Verkehr sind Anwendungsinhalte ohne vorgesehene Entschlüsselungsmöglichkeiten nicht sichtbar.

Mitschnitte dürfen nur autorisiert erfolgen. Sie können vertrauliche Inhalte, Adressen, Namen, Sitzungsinformationen oder Anmeldedaten enthalten.

22. Netzwerk und Anwendung voneinander trennen

Ein schneller Netzwerktest beweist nicht, dass die Anwendung schnell arbeitet.

Mögliche zusätzliche Verzögerungen:

Vergleich

Ping zum Server:             1 ms
iperf3 zum Server:         930 Mbit/s
Dateiübertragung:           35 MB/s
Anwendung reagiert:         nach 8 Sekunden

Das Netzwerk erreicht in diesem Beispiel grundsätzlich einen hohen Durchsatz. Deshalb müssen anschließend Dateiablage, Serverressourcen und Anwendung untersucht werden.

23. Serverressourcen prüfen

Unter Windows beispielsweise:

Get-Counter '\Processor(_Total)\% Processor Time'

Get-Counter '\Memory\Available MBytes'

Netzwerkadapterstatistik:

Get-NetAdapterStatistics

Aktuelle TCP-Verbindungen:

Get-NetTCPConnection

Unter Linux:

top

free -h

vmstat 1

iostat -xz 1

ss -s

Zu prüfen sind:

Eine niedrige CPU-Auslastung schließt einen Serverengpass nicht aus. Eine Anwendung kann durch einen einzelnen Thread, Storage, Sperren, Datenbankabfragen oder externe Abhängigkeiten begrenzt sein.

24. Storage-Leistung von Netzwerkleistung unterscheiden

Dateiübertragungen werden mindestens durch folgende Komponenten begrenzt:

Clientdatenträger
    ↓
Clientnetzwerk
    ↓
Netzwerkpfad
    ↓
Servernetzwerk
    ↓
Serverdatenträger

Der langsamste beteiligte Abschnitt bestimmt die erreichbare Gesamtleistung.

Vergleichsmöglichkeiten

Ein schneller iperf3-Test und eine langsame Dateiübertragung sprechen dafür, dass nicht allein der Netzwerkpfad begrenzt.

Unkontrollierte Datenträger-Benchmarks dürfen auf Produktivsystemen nicht durchgeführt werden. Sie können erhebliche Last erzeugen und verfügbare Speicherkapazität beeinflussen.

25. Zeitabhängige Last untersuchen

Wenn die Störung nur zu bestimmten Zeiten auftritt, prüfen:

Erforderlich ist eine zeitliche Korrelation:

14:00 Uhr: Backup startet
14:02 Uhr: Uplink erreicht 98 % Auslastung
14:03 Uhr: Output Drops steigen
14:04 Uhr: Benutzer melden langsame Dateiübertragungen
15:00 Uhr: Backup endet
15:02 Uhr: Durchsatz normalisiert sich

Eine zeitliche Übereinstimmung ist ein starker Hinweis, aber noch kein vollständiger Ursachennachweis. Die beteiligten Messwerte müssen gemeinsam bewertet werden.

26. Baseline und Vergleichswerte verwenden

Eine Baseline beschreibt den normalen Zustand eines Systems.

Sinnvolle Vergleichswerte:

Beispiel

Messwert Normalzustand Störungszeit
RTT zum Server 1–2 ms 25–180 ms
Paketverlust 0 % 3 %
TCP-Durchsatz 920 Mbit/s 85 Mbit/s
Uplink-Auslastung 20–40 % 98 %
Output Drops 0/s 2.500/s

Ohne Vergleichswert ist schwer zu beurteilen, ob ein Messwert tatsächlich ungewöhnlich ist.

27. Beispiel für eine systematische Diagnose

Symptom

Mehrere Benutzer melden langsame Zugriffe auf einen Dateiserver.

Sollzustand

Clientanschlüsse: 1 Gbit/s
Switch-Uplink:    10 Gbit/s
Serveranschluss:  10 Gbit/s
Normaler TCP-Test: ungefähr 900 Mbit/s je Client

Clienttest

ping 192.0.2.80 -n 20

Ergebnis:

Durchschnitt: 2 ms
Paketverlust: 0 %

Durchsatztest

iperf3 -c 192.0.2.80 -t 30

Ergebnis:

Durchschnittlicher Durchsatz: 92 Mbit/s
Retransmissions: erhöht

Clientport

show interfaces GigabitEthernet1/0/12

Ergebnis:

Full-duplex, 1000 Mb/s
Keine zunehmenden CRC-Fehler

Uplinkprüfung

show interfaces TenGigabitEthernet1/1/1

Ergebnis:

Auslastung: 99 %
Output Drops steigen

Zeitlicher Vergleich

Auslastungsbeginn:  14:00 Uhr
Backupbeginn:       14:00 Uhr
Benutzermeldungen:  ab 14:05 Uhr

Festgestellte Ursache

Ein neu eingerichteter Backupauftrag belegte während der Geschäftszeit nahezu die gesamte verfügbare Uplinkkapazität. Dadurch entstanden Warteschlangen, Drops und TCP-Wiederholungen.

Kontrollierte Maßnahme

Der Backupzeitplan und die vorgesehene Bandbreitensteuerung wurden nach betrieblicher Freigabe angepasst.

Rollback

Falls die Änderung unerwartete Auswirkungen verursacht:

Verifikation

iperf3 -c 192.0.2.80 -t 30

Ergebnis:

Durchschnittlicher Durchsatz: 928 Mbit/s
Retransmissions: keine auffällige Zunahme

Zusätzlich:

28. Beispiel „Netzwerk schnell, Server langsam“

Symptom

Der Zugriff auf eine Datenbankanwendung benötigt mehrere Sekunden.

Netzwerkprüfung

Ping:                 1 ms
Paketverlust:         0 %
iperf3:             935 Mbit/s
Interfacefehler:      keine Zunahme

Serverprüfung

Storage-Latenz: stark erhöht
Datenträgerwarteschlange: stark erhöht
Start eines Sicherungsauftrags: gleicher Zeitpunkt wie Störung

Festgestellte Ursache

Der Netzwerkpfad funktionierte normal. Die Anwendung wartete auf den stark ausgelasteten Serverdatenträger.

Lehre

Eine langsame Netzwerkanwendung ist nicht automatisch ein langsames Netzwerk. Netzwerk, Anwendung und Serverressourcen müssen getrennt gemessen werden.

29. Ungeeignete Sofortmaßnahmen

Nicht als erste Maßnahme verwenden:

Solche Maßnahmen können Diagnoseinformationen beseitigen, Sicherheitsgrenzen verändern oder zusätzliche Störungen erzeugen.

30. Vollständige Schnellprüfreihenfolge

  1. genaue Anwendung und Benutzeraktion ermitteln.
  2. erwartete und tatsächliche Leistung dokumentieren.
  3. Beginn, Dauer und zeitliches Muster bestimmen.
  4. feststellen, ob ein oder mehrere Benutzer betroffen sind.
  5. WLAN und Ethernet getrennt betrachten.
  6. lokales und entferntes Ziel vergleichen.
  7. Upload und Download getrennt prüfen.
  8. tatsächlich verwendeten Netzwerkadapter feststellen.
  9. Linkgeschwindigkeit und Duplex prüfen.
  10. Fehler- und Verwerfungszähler dokumentieren.
  11. Gateway, lokales Ziel und entferntes Ziel anpingen.
  12. Latenz, Schwankung und Paketverlust vergleichen.
  13. tatsächlichen Netzwerkpfad ermitteln.
  14. Durchsatz mit einem autorisierten Testsystem messen.
  15. beide Übertragungsrichtungen prüfen.
  16. Netzwerkpfad in einzelne Segmente unterteilen.
  17. Access-Port, Uplink und Serverport prüfen.
  18. Auslastung und Warteschlangen untersuchen.
  19. WLAN-Signal, SNR, Kanal und Airtime prüfen.
  20. Firewall, Router, Proxy und VPN untersuchen.
  21. MTU und mögliche Fragmentierungsprobleme prüfen.
  22. TCP-Wiederholungen und Empfangsfenster untersuchen.
  23. Anwendung und Netzwerk getrennt testen.
  24. CPU, Arbeitsspeicher und Storage des Servers prüfen.
  25. geplante Backups, Scans und Synchronisationen berücksichtigen.
  26. Messwerte mit einer Baseline vergleichen.
  27. genau eine Hypothese formulieren.
  28. genau eine kontrollierte Änderung durchführen.
  29. ursprüngliche Messungen wiederholen.
  30. Nebenwirkungen und Sicherheitsfunktionen prüfen.
  31. temporäre Diagnoseänderungen entfernen.
  32. Ursache, Maßnahme, Rollback und Nachweis dokumentieren.

31. Checkliste „Netzwerk ist langsam“

32. Schnellreferenz

Ergebnis Nächster Schritt
nur ein Client langsam Client, Kabel, Treiber und Switchport prüfen
alle Clients langsam gemeinsamen Uplink, Firewall, WAN oder Server prüfen
Ethernet schnell, WLAN langsam Funkstrecke, SNR, Kanal und Airtime prüfen
Gateway bereits langsam lokalen Zugang und Clientpfad prüfen
Gateway schnell, entferntes Ziel langsam Routing-, WAN-, VPN- oder Internetpfad prüfen
Link nur mit 100 Mbit/s aktiv Kabel, Aushandlung, Dock und Port prüfen
zunehmende CRC-Fehler physischen Übertragungsweg prüfen
Output Drops steigen nachgelagerten Engpass oder Warteschlange prüfen
hohe Latenz ohne Paketverlust Auslastung, Warteschlangen oder entfernten Pfad prüfen
Paketverlust steigt unter Last Überlastung, WLAN oder physische Fehler prüfen
iperf3 schnell, Datei langsam Anwendung, Dateidienst und Storage prüfen
iperf3 ebenfalls langsam Netzwerkpfad, Client und Gegenstelle prüfen
nur eine Richtung langsam richtungsabhängige Auslastung und Rückweg prüfen
viele TCP-Retransmissions Verlustursache entlang des Pfades suchen
TCP Zero Window vom Server Server oder Anwendung verarbeitet Daten zu langsam
kleine Pakete funktionieren, große nicht MTU und Fragmentierung prüfen
nur VPN langsam Tunnelpfad, MTU und VPN-Gateway prüfen
nur zu bestimmten Zeiten langsam geplante Last und historische Messwerte vergleichen
Server-Storage stark ausgelastet Server- und Speicherproblem statt Netzwerkfehler prüfen
öffentlicher Speedtest langsam Ergebnis durch internen Referenztest eingrenzen
Zwischenhop antwortet nicht prüfen, ob nachfolgende Hops und Ziel betroffen sind
WLAN-Signal stark, Leistung schlecht SNR, Störungen, Airtime und Kanalauslastung prüfen

Merksatz

Ein langsames Netzwerk wird nicht durch Gefühl diagnostiziert. Zuerst werden Umfang, Richtung, Latenz, Paketverlust und Durchsatz gemessen. Danach wird der Pfad segmentweise untersucht und eindeutig zwischen Client, WLAN, Netzwerk, Firewall, VPN, Server, Storage und Anwendung getrennt.

Quellen und weiterführende Dokumentation

7.6 Fehler tritt nur manchmal auf

Sporadische Fehler treten unregelmäßig auf und sind bei einer direkten Prüfung häufig nicht mehr vorhanden. Beispiele sind kurze Verbindungsabbrüche, gelegentliche Anmeldefehler, zeitweise langsame Anwendungen oder Dienste, die sich scheinbar ohne Eingriff wieder stabilisieren.

Die besondere Schwierigkeit besteht darin, dass der Systemzustand während der Störung meistens nicht direkt beobachtet wird. Deshalb müssen Diagnoseinformationen bereits vor dem nächsten Auftreten gesammelt werden.

Sporadischer Fehler
        ↓
genauen Zeitpunkt erfassen
        ↓
Messwerte und Protokolle sichern
        ↓
wiederkehrendes Muster erkennen
        ↓
gemeinsame Ursache eingrenzen

1. Typische Symptome

2. Mögliche Auswirkungen

Ein sporadischer Fehler ist nicht automatisch harmlos. Kurze Unterbrechungen können besonders bei Datenbanken, Transaktionen, Authentifizierungen, Telefonie, VPN-Verbindungen und Schreibvorgängen erhebliche Auswirkungen haben.

3. Sicherheits- und Betriebshinweis

Dauerüberwachung, Protokollierung und Paketmitschnitte dürfen nur autorisiert durchgeführt werden.

Dabei können verarbeitet werden:

Vor einer erweiterten Protokollierung sind deshalb zu klären:

Protokollierung darf nicht unbegrenzt und ohne festgelegten Zweck aktiviert bleiben.

4. Fehler nicht vorschnell als „nicht reproduzierbar“ schließen

Wenn ein Fehler bei der Prüfung nicht mehr vorhanden ist, bedeutet dies nur:

Der Fehler ist im aktuellen Moment nicht sichtbar.

Es bedeutet nicht:

Der Fehler hat nicht stattgefunden.

Ein sporadischer Fehler kann zwischen zwei Prüfungen auftreten und wieder verschwinden. Deshalb müssen folgende Informationen gesammelt werden:

5. Exakten Zeitpunkt erfassen

Die wichtigste Angabe ist ein möglichst genauer Zeitstempel.

Ungeeignet:

Der Fehler war heute Nachmittag.

Besser:

02.08.2026, ungefähr 14:17 Uhr

Optimal:

02.08.2026, 14:17:32 bis 14:17:47 Uhr

Zusätzlich dokumentieren:

Benutzer:       Max Mustermann
Client:         NB-023
IP-Adresse:     192.0.2.45
Anwendung:      ERP-Client
Zielserver:     ERP-SRV-01
Aktion:         Auftrag speichern
Fehlermeldung:  Verbindung zum Server unterbrochen
Beginn:         14:17:32 Uhr
Ende:           14:17:47 Uhr

Je genauer der Zeitpunkt bekannt ist, desto gezielter können Ereignisprotokolle, Monitoringdaten und Paketmitschnitte ausgewertet werden.

6. Zeitsynchronisation prüfen

Protokolle verschiedener Systeme lassen sich nur zuverlässig vergleichen, wenn deren Uhren korrekt synchronisiert sind.

Zu prüfen sind:

Unter Windows:

w32tm /query /status

Konfigurierte Zeitquelle:

w32tm /query /source

Unter Linux:

timedatectl status

Bei chrony, sofern eingesetzt:

chronyc tracking

chronyc sources

Beispiel

Client:      14:17:32 Uhr
Server:      14:15:21 Uhr
Firewall:    12:17:30 UTC

Ohne Berücksichtigung von Zeitabweichung und Zeitzone könnten zusammengehörige Ereignisse fälschlich als getrennte Vorfälle bewertet werden.

Die Systemzeit darf nicht unkontrolliert auf Produktivsystemen geändert werden. Zeitänderungen können Protokolle, Zertifikate, Authentifizierung, Datenbanken und verteilte Systeme beeinflussen.

7. Häufigkeit und Muster bestimmen

Zu klären ist, ob der Fehler:

auftritt.

Beispielhafte Fehlerliste

Datum Uhrzeit Dauer Benutzer System Beobachtung
30.07.2026 14:17 15 s Max Mustermann NB-023 ERP-Verbindung getrennt
31.07.2026 14:16 18 s Max Mustermann NB-023 ERP-Verbindung getrennt
01.08.2026 14:18 12 s mehrere verschiedene Dateiserver kurz nicht erreichbar
02.08.2026 14:17 15 s mehrere verschiedene ERP und Dateiserver betroffen

Das wiederkehrende Zeitfenster deutet auf einen geplanten oder regelmäßig ausgelösten Prozess hin.

8. Umfang des Fehlers bestimmen

Folgende Fragen helfen bei der Eingrenzung:

  1. Ist nur ein Benutzer betroffen?
  2. Sind mehrere Benutzer betroffen?
  3. Sind alle Benutzer eines Standorts betroffen?
  4. Ist nur eine Anwendung betroffen?
  5. Sind mehrere Dienste gleichzeitig betroffen?
  6. Ist nur ein Client betroffen?
  7. Sind alle Geräte an einem Switch betroffen?
  8. Sind ausschließlich WLAN-Clients betroffen?
  9. Sind nur VPN-Verbindungen betroffen?
  10. Ist nur eine Übertragungsrichtung betroffen?
  11. Ist nur ein bestimmter Server betroffen?
  12. Sind interne und externe Ziele betroffen?

Bewertung

Beobachtung Möglicher Prüfbereich
nur ein Benutzer Benutzerprofil, Sitzung oder Berechtigung
nur ein Client Client, Treiber, Kabel, WLAN oder lokale Software
mehrere Clients am gleichen Switch Switch, Uplink oder Stromversorgung
alle WLAN-Clients eines Access Points Access Point, Funkkanal oder AP-Uplink
mehrere Dienste auf einem Server Server, Betriebssystem oder gemeinsame Ressource
mehrere Systeme gleichzeitig Netzwerk, DNS, Authentifizierung, Storage oder Infrastruktur
nur VPN-Benutzer Internetzugang, Tunnel, Gateway, MTU oder Sitzungszeit
alle Standorte gleichzeitig zentrales System, Provider oder übergreifender Dienst

9. Fehler automatisiert erfassen

Ein sporadischer Fehler sollte möglichst durch wiederholte Messungen sichtbar gemacht werden.

Geeignete Messwerte sind beispielsweise:

Die Messung muss einen Zeitstempel enthalten.

Grundprinzip

Zeitstempel + Messwert + Ziel + Ergebnis

Beispiel:

2026-08-02 14:17:30 | ERP-SRV-01 | Ping 1 ms | TCP 443 erreichbar
2026-08-02 14:17:35 | ERP-SRV-01 | Zeitüberschreitung
2026-08-02 14:17:40 | ERP-SRV-01 | Zeitüberschreitung
2026-08-02 14:17:45 | ERP-SRV-01 | Ping 2 ms | TCP 443 erreichbar

10. Kontinuierliche Erreichbarkeit unter Windows prüfen

Ein dauerhafter Ping kann kurzfristige Unterbrechungen sichtbar machen:

ping <ziel-ip> -t

Der Test wird mit Strg + C beendet.

Aussagekräftiger ist eine protokollierte PowerShell-Messung mit Zeitstempel:

while ($true) {
    $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    $result = Test-Connection -ComputerName "<ziel-ip>" -Count 1 -Quiet
    "$timestamp | <ziel-ip> | Erreichbar: $result" |
        Out-File -FilePath ".\erreichbarkeit.log" -Append
    Start-Sleep -Seconds 5
}

TCP-Port wiederholt prüfen:

while ($true) {
    $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    $result = Test-NetConnection -ComputerName "<server>" -Port 443
    "$timestamp | TCP 443: $($result.TcpTestSucceeded)" |
        Out-File -FilePath ".\tcp-443.log" -Append
    Start-Sleep -Seconds 5
}

Wichtig

11. Kontinuierliche Erreichbarkeit unter Linux oder macOS prüfen

Linux:

ping <ziel-ip>

macOS:

ping <ziel-ip>

Mit Zeitstempeln unter Linux, sofern ping diese Option unterstützt:

ping -D <ziel-ip>

Alternativ kann eine kontrollierte Schleife verwendet werden:

while true; do
    timestamp=$(date '+%Y-%m-%d %H:%M:%S')
    if ping -c 1 -W 2 <ziel-ip> >/dev/null 2>&1; then
        echo "$timestamp | <ziel-ip> | erreichbar"
    else
        echo "$timestamp | <ziel-ip> | nicht erreichbar"
    fi
    sleep 5
done

Da sich Optionen von ping zwischen Linux und macOS unterscheiden können, müssen die Parameter des verwendeten Systems geprüft werden:

man ping

12. Mehrere Messpunkte gleichzeitig verwenden

Eine einzelne Zielmessung zeigt nicht, an welcher Stelle der Fehler auftritt. Deshalb sollten mehrere Punkte parallel überwacht werden.

Client
  |
Standardgateway
  |
interner Server
  |
externer Dienst

Beispiel:

14:17:35 | Gateway erreichbar
14:17:35 | interner Server nicht erreichbar
14:17:35 | externer Dienst nicht erreichbar

Mögliche Eingrenzung:

Clientzugang funktioniert.
Die Störung beginnt hinter dem Gateway oder auf einem gemeinsamen Folgepfad.

Anderes Beispiel:

14:17:35 | Gateway nicht erreichbar
14:17:35 | interner Server nicht erreichbar
14:17:35 | externer Dienst nicht erreichbar

Mögliche Eingrenzung:

Client, lokaler Zugang, WLAN, Switchport oder lokales Netzwerk prüfen.

Vergleichstabelle

Gateway Interner Server Externes Ziel Eingrenzung
nicht erreichbar nicht erreichbar nicht erreichbar Client oder lokaler Zugang
erreichbar nicht erreichbar erreichbar interner Pfad oder Server
erreichbar erreichbar nicht erreichbar Internet-, Provider- oder externer Pfad
überall erreichbar Anwendung fehlerhaft Anwendung, Dienst oder Sitzung
mehrere Ziele gleichzeitig langsam gemeinsamer Netzwerkpfad oder Infrastruktur

13. Windows-Ereignisprotokolle zeitlich filtern

Ereignisse eines bestimmten Zeitraums anzeigen:

Get-WinEvent -FilterHashtable @{
    LogName   = "System"
    StartTime = [datetime]"2026-08-02 14:15:00"
    EndTime   = [datetime]"2026-08-02 14:20:00"
} |
    Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message

Anwendungsprotokoll:

Get-WinEvent -FilterHashtable @{
    LogName   = "Application"
    StartTime = [datetime]"2026-08-02 14:15:00"
    EndTime   = [datetime]"2026-08-02 14:20:00"
} |
    Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message

Fehler und Warnungen aus dem Systemprotokoll:

Get-WinEvent -FilterHashtable @{
    LogName   = "System"
    Level     = 2, 3
    StartTime = (Get-Date).AddHours(-4)
} |
    Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message

Zu prüfen sind unter anderem:

Ein zeitgleiches Ereignis ist zunächst eine Korrelation. Erst weitere Messungen zeigen, ob es tatsächlich die Ursache des Fehlers ist.

14. Linux-Protokolle zeitlich filtern

Systemprotokoll eines genauen Zeitfensters:

journalctl \
    --since "2026-08-02 14:15:00" \
    --until "2026-08-02 14:20:00"

Nur Meldungen eines bestimmten Dienstes:

journalctl \
    -u <dienstname> \
    --since "2026-08-02 14:15:00" \
    --until "2026-08-02 14:20:00"

Kernelmeldungen:

journalctl \
    -k \
    --since "2026-08-02 14:15:00" \
    --until "2026-08-02 14:20:00"

Nur Warnungen und schwerwiegendere Meldungen:

journalctl -p warning \
    --since "2026-08-02 14:15:00" \
    --until "2026-08-02 14:20:00"

Live verfolgen:

journalctl -f

Zu prüfen sind:

Ob ältere Meldungen verfügbar sind, hängt von der Konfiguration und Aufbewahrung des Journals ab.

15. Protokolle zentral zusammenführen

Wenn mehrere Systeme beteiligt sind, reichen lokale Protokolle häufig nicht aus.

Mögliche Quellen:

Vorteile einer zentralen Protokollierung:

Dabei müssen Zeitsynchronisation, Zugriffsschutz, Speicherbedarf und Datenschutz berücksichtigt werden.

16. Auflösung des Monitorings erhöhen

Ein Fünf-Minuten-Mittelwert kann einen Fehler von zehn Sekunden vollständig verdecken.

Beispiel

Messintervall: 5 Minuten
Störung:       10 Sekunden
Linklast:      während der Störung 100 %
Mittelwert:    nur 8 %

Der Mittelwert wirkt unauffällig, obwohl kurzzeitig eine vollständige Überlastung bestand.

Zu prüfen sind:

Mögliche Anpassung:

Vorher: Messung alle 5 Minuten
Temporär: Messung alle 10 Sekunden

Eine höhere Auflösung erzeugt mehr Last und benötigt mehr Speicher. Sie sollte kontrolliert, zeitlich begrenzt und auf die erforderlichen Messwerte beschränkt werden.

17. Ringpuffer-Paketmitschnitt verwenden

Wenn ein Netzwerkfehler nur selten auftritt, kann ein begrenzter Ringpuffer-Mitschnitt die Pakete vor und während des Fehlers erhalten.

Verfügbare Schnittstellen anzeigen:

dumpcap -D

Beispiel für einen Ringpuffer:

dumpcap \
    -i 1 \
    -b duration:300 \
    -b files:12 \
    -w sporadischer-fehler.pcapng

Bedeutung:

-i 1              Schnittstelle 1
-b duration:300   alle 300 Sekunden neue Datei
-b files:12       höchstens 12 Ringpufferdateien
-w                Ausgabedatei

Damit werden ungefähr die letzten 60 Minuten vorgehalten:

12 Dateien × 5 Minuten = 60 Minuten

Mitschnitt auf einen bestimmten Host begrenzen:

dumpcap \
    -i 1 \
    -f "host 192.0.2.45" \
    -b duration:300 \
    -b files:12 \
    -w sporadischer-fehler.pcapng

Wichtig

Ein Paketmitschnitt auf dem Client sieht nicht automatisch den gesamten Netzwerkverkehr. Für andere Segmente kann ein autorisierter Mirror- beziehungsweise SPAN-Port erforderlich sein.

18. Interface-Flapping untersuchen

Interface-Flapping bedeutet, dass eine Netzwerkschnittstelle wiederholt zwischen aktiv und inaktiv wechselt.

Typisches Muster:

14:17:31 Interface down
14:17:34 Interface up
14:18:02 Interface down
14:18:05 Interface up

Unter Windows:

Get-NetAdapter |
    Format-Table Name, Status, LinkSpeed, InterfaceDescription

Statistiken:

Get-NetAdapterStatistics

Unter Linux:

ip -s link show

Kernelmeldungen zum Netzwerk:

journalctl -k |
    grep -Ei "link.*(up|down)|carrier|network"

Auf Cisco-IOS-/IOS-XE-Switches beispielsweise:

show logging

show interfaces status

show interfaces <interface>

Zu prüfen sind:

19. Fehlerzähler als Verlauf beobachten

Ein einzelner Zählerstand zeigt nicht, wann ein Fehler entstanden ist. Deshalb müssen Ausgangswert und späterer Wert verglichen werden.

Beispiel ohne aktuelle Zunahme

14:00 Uhr: 25 CRC-Fehler
15:00 Uhr: 25 CRC-Fehler

Der Zähler enthält historische Fehler, steigt im Beobachtungszeitraum jedoch nicht.

Beispiel mit sporadischer Zunahme

14:00 Uhr: 25 CRC-Fehler
14:16 Uhr: 25 CRC-Fehler
14:18 Uhr: 4.260 CRC-Fehler
14:20 Uhr: 4.260 CRC-Fehler

Die Fehler entstehen in einem kurzen Zeitfenster und korrelieren möglicherweise mit der gemeldeten Störung.

Zu beobachten sind:

Fehlerzähler sollten erst nach der Dokumentation und nur nach betrieblicher Freigabe zurückgesetzt werden.

20. DHCP-Lease und Adresskonflikte prüfen

Ein Fehler kann beim Erneuern einer DHCP-Lease oder durch eine doppelt verwendete IP-Adresse auftreten.

Unter Windows:

ipconfig /all

Zu prüfen sind:

Unter Linux, abhängig vom verwendeten Netzwerkdienst:

journalctl |
    grep -Ei "dhcp|lease"

Mögliche Hinweise:

Fehler tritt regelmäßig bei Lease-Erneuerung auf.
Client erhält kurzzeitig keine gültige Adresse.
Zwei Geräte verwenden dieselbe statische IP-Adresse.
DHCP-Server sind nicht einheitlich konfiguriert.

Eine zeitliche Übereinstimmung zwischen Lease-Erneuerung und Fehler ist ein Hinweis, aber noch kein Beweis für die Ursache.

21. DNS-TTL und DNS-Auflösung prüfen

Ein sporadischer Fehler kann auftreten, wenn zwischengespeicherte DNS-Einträge ablaufen und anschließend eine fehlerhafte oder langsame Auflösung erfolgt.

Unter Windows:

Resolve-DnsName <hostname>

DNS-Cache anzeigen:

ipconfig /displaydns

Unter Linux oder macOS, sofern dig vorhanden ist:

dig <hostname>

Wiederholte Abfrage:

dig <hostname> +noall +answer

Zu prüfen sind:

Beispiel

DNS-Antwort 1: 192.0.2.80 – Dienst funktioniert
DNS-Antwort 2: 192.0.2.81 – Dienst nicht erreichbar

In diesem Fall kann der Fehler nur bei Auswahl einer bestimmten Zieladresse auftreten.

DNS-Caches dürfen nicht pauschal gelöscht werden, bevor der aktuelle Zustand dokumentiert wurde. Dadurch könnten wichtige Diagnoseinformationen verloren gehen.

22. Sitzungen, Token und Timeouts berücksichtigen

Viele sporadische Fehler treten nach einer bestimmten Zeitspanne auf.

Mögliche Zeitgrenzen:

Beispiel

Anmeldung:             08:00 Uhr
Fehler:                16:00 Uhr
Zeit bis zum Fehler:   8 Stunden

Tritt der Fehler regelmäßig nach fast derselben Sitzungsdauer auf, sind zeitbasierte Gültigkeiten und Timeouts zu prüfen.

Zu dokumentieren sind:

Ein erneutes Anmelden kann den Fehler vorübergehend beseitigen, beweist aber noch nicht, welche Komponente die Sitzung beendet hat.

23. Zertifikats- und Gültigkeitszeiträume prüfen

Zertifikatsprobleme können nur einzelne Systeme, Dienste oder Verbindungswege betreffen.

Mit OpenSSL, sofern verfügbar:

openssl s_client \
    -connect <server>:443 \
    -servername <hostname>

Nur Zertifikatsdaten ausgeben:

openssl s_client \
    -connect <server>:443 \
    -servername <hostname> \
    </dev/null 2>/dev/null |
    openssl x509 -noout -subject -issuer -dates

Zu prüfen sind:

Beispiel

Load-Balancer-Knoten 1: gültiges Zertifikat
Load-Balancer-Knoten 2: abgelaufenes Zertifikat

Der Fehler erscheint dadurch möglicherweise nur bei Verbindungen, die auf den zweiten Knoten verteilt werden.

24. Geplante Aufgaben und Timer prüfen

Regelmäßig auftretende Fehler können mit zeitgesteuerten Prozessen zusammenhängen.

Unter Windows:

Get-ScheduledTask |
    Select-Object TaskName, TaskPath, State

Weitere Informationen:

Get-ScheduledTask |
    Get-ScheduledTaskInfo |
    Select-Object TaskName, LastRunTime, LastTaskResult, NextRunTime

Unter Linux mit systemd:

systemctl list-timers --all

Cron-Einträge müssen entsprechend der verwendeten Distribution und betrieblichen Berechtigung geprüft werden.

Mögliche zeitgesteuerte Auslöser:

25. Backups, Scans und Updates zeitlich vergleichen

Beispiel

02:00:00 Backup startet
02:00:12 Storage-Latenz steigt
02:00:18 Datenbankantwortzeit steigt
02:00:25 Anwendung meldet Timeout
02:20:00 Backup endet
02:20:15 Storage-Latenz normalisiert sich

Diese Ereignisse bilden eine plausible Kette:

Backup
   ↓
hohe Storage-Last
   ↓
langsame Datenbank
   ↓
Anwendungs-Timeout

Die zeitliche Korrelation ist stark, muss aber durch Messwerte bestätigt werden.

Zu vergleichen sind:

Produktive Sicherungen oder Sicherheitsprüfungen dürfen nicht ohne Freigabe deaktiviert werden. Eine kontrollierte Zeitplanänderung ist häufig sicherer als das vollständige Abschalten.

26. Temperatur und Stromversorgung berücksichtigen

Sporadische Hardwarefehler können durch Umwelt- oder Strombedingungen ausgelöst werden.

Zu prüfen sind:

Typisches Muster:

Temperatur steigt
        ↓
Gerät reduziert Leistung oder schaltet Komponente ab
        ↓
Dienst oder Verbindung fällt kurzzeitig aus
        ↓
Temperatur sinkt
        ↓
System funktioniert wieder

Hardwaregrenzwerte und Diagnosebefehle sind hersteller- und modellspezifisch und müssen anhand der offiziellen Gerätedokumentation geprüft werden.

27. WLAN-Störungen untersuchen

Kurzzeitige WLAN-Probleme können durch wechselnde Funkbedingungen entstehen.

Zu prüfen sind:

Unter Windows:

netsh wlan show interfaces

Bericht zur WLAN-Nutzung:

netsh wlan show wlanreport

Der erzeugte Bericht enthält Informationen zu WLAN-Sitzungen und Verbindungsereignissen. Speicherort und Zugriff müssen auf dem jeweiligen System geprüft werden.

Vergleich

Ethernet WLAN Eingrenzung
stabil sporadische Ausfälle Funkstrecke, Roaming oder Access Point
beide gleichzeitig gestört gemeinsamer Pfad oder Zielsystem
nur ein WLAN-Client betroffen Client, Treiber, Standort oder Frequenzband
alle Clients eines AP betroffen Access Point, Funkkanal, PoE oder Uplink

28. Provider- und WAN-Störungen berücksichtigen

Wenn nur externe oder standortübergreifende Verbindungen betroffen sind, müssen auch WAN- und Providerpfade untersucht werden.

Zu prüfen sind:

Ein einzelner öffentlicher Speedtest reicht nicht aus. Benötigt werden wiederholte und möglichst vergleichbare Messungen zu internen und externen Referenzzielen.

29. Mehrere Systeme auf einer gemeinsamen Zeitleiste korrelieren

Die wichtigste Methode bei sporadischen Fehlern ist eine gemeinsame Ereigniszeitleiste.

Beispiel

Zeit Client Switch Firewall Server Anwendung
14:17:30 normal normal normal normal normal
14:17:32 Verbindung hängt Uplink-Drops steigen Sitzungen normal Anfragen warten Timeout beginnt
14:17:35 Ziel nicht erreichbar Uplink 100 % Paketverluste keine neuen Anfragen Fehlermeldung
14:17:42 Verbindung wieder da Drops sinken normal Anfragen treffen ein Wiederherstellung
14:18:00 normal normal normal normal normal

Die gemeinsame Zeitleiste zeigt, welche Veränderung zuerst auftrat.

Ein Anwendungsfehler am Ende der Kette ist in diesem Beispiel nicht automatisch die ursprüngliche Ursache.

30. Reihenfolge von Ursache und Folge beachten

Gleichzeitig protokollierte Fehler können unterschiedliche Rollen besitzen.

Beispiel

14:17:32 Switchport verliert Link
14:17:33 Client verliert Netzwerk
14:17:34 DNS-Abfrage schlägt fehl
14:17:35 Anwendung meldet Serverfehler

Mögliche Reihenfolge:

Switchportproblem
      ↓
Netzwerkverlust
      ↓
DNS-Fehler
      ↓
Anwendungsfehler

Der DNS-Fehler und der Anwendungsfehler sind hier wahrscheinlich Folgen des vorherigen Linkverlusts.

Deshalb ist zu fragen:

31. Kontrollierte Reproduktion versuchen

Wenn ein Muster erkannt wurde, kann eine kontrollierte Reproduktion möglich sein.

Beispiele:

Dabei gelten folgende Regeln:

  1. nur autorisierte Tests durchführen,
  2. Ausgangszustand dokumentieren,
  3. erwartete Beobachtung festlegen,
  4. nur einen Einflussfaktor verändern,
  5. Messwerte während des Tests erfassen,
  6. Test bei unerwarteten Auswirkungen abbrechen,
  7. ursprünglichen Zustand wiederherstellen,
  8. Ergebnis dokumentieren.

Ein produktiver Fehler darf nicht absichtlich durch riskante Last, Stromunterbrechung, Sicherheitsdeaktivierung oder unkontrollierte Netzwerkänderung provoziert werden.

32. Hypothese messbar formulieren

Ungeeignet:

Vielleicht ist das Netzwerk schuld.

Besser:

Wenn der Fehler auftritt, verliert der Client vermutlich kurzzeitig
die Verbindung zum Standardgateway.

Prüfung:

Client → Gateway kontinuierlich messen
Client → Server kontinuierlich messen
Client- und Switchportprotokolle vergleichen

Noch genauer:

Wenn NB-023 den Fehler erneut zeigt, muss innerhalb desselben
Zeitfensters entweder ein Link-Down-Ereignis am Client oder am
Switchport Gi1/0/12 sichtbar sein.

Eine gute Hypothese enthält:

33. Genau eine kontrollierte Änderung durchführen

Nach ausreichender Eingrenzung wird nur eine Änderung vorgenommen.

Mögliche kontrollierte Änderungen:

Nicht mehrere Änderungen gleichzeitig durchführen.

Ungeeignet:

Kabel, Switchport, Treiber und DNS gleichzeitig ändern

Danach wäre nicht mehr feststellbar, welche Änderung wirksam war.

34. Rollback festlegen

Vor der Änderung dokumentieren:

Beispiel

Änderung:
Backupstart von 14:00 Uhr auf 22:00 Uhr verschieben.

Rollback:
Ursprünglichen Startzeitpunkt 14:00 Uhr wiederherstellen.

Abbruchkriterium:
Sicherung startet nicht oder überschneidet sich mit einem anderen Auftrag.

35. Verifikation über ausreichend lange Zeit durchführen

Bei einem sporadischen Fehler reicht ein einzelner erfolgreicher Test nicht aus.

Beispiel

Fehler trat bisher ungefähr einmal täglich auf.
Nach der Änderung war das System 15 Minuten stabil.

Dieses Ergebnis ist noch kein ausreichender Nachweis.

Besser:

Beobachtungszeitraum vor Änderung: 7 Tage
Fehlerhäufigkeit vorher:           1 bis 3 Ereignisse pro Tag
Beobachtungszeitraum nach Änderung: 7 Tage
Fehlerhäufigkeit nachher:          0 Ereignisse

Zusätzlich prüfen:

36. Beispiel für eine systematische Diagnose

Symptom

Mehrere Benutzer melden an Werktagen gegen 14:17 Uhr kurze Verbindungsabbrüche zu verschiedenen internen Diensten.

Erste Beobachtung

Dauer:              10 bis 20 Sekunden
Betroffene Clients: mehrere
Betroffene Dienste: ERP, Dateiserver und Intranet
Gateway:            während der Störung erreichbar
Interne Server:     während der Störung teilweise nicht erreichbar

Kontinuierliche Messung

14:17:30 Gateway:       1 ms
14:17:30 Dateiserver:   2 ms
14:17:35 Gateway:       1 ms
14:17:35 Dateiserver:   Zeitüberschreitung
14:17:40 Gateway:       1 ms
14:17:40 Dateiserver:   Zeitüberschreitung
14:17:45 Gateway:       1 ms
14:17:45 Dateiserver:   2 ms

Switch-Monitoring

14:17:33 Server-Uplink erreicht 100 % Auslastung
14:17:34 Output Drops steigen
14:17:44 Auslastung sinkt
14:17:45 Output Drops steigen nicht weiter

Zeitgesteuerte Aufgaben

14:17:30 Replikationsauftrag startet
14:17:45 Replikationsauftrag beendet

Hypothese

Der Replikationsauftrag überlastet kurzzeitig den gemeinsamen Server-Uplink. Die entstehenden Warteschlangen und Drops verursachen Paketverlust und Anwendungsabbrüche.

Kontrollierte Maßnahme

Nach betrieblicher Freigabe wird der Replikationsauftrag in ein geeignetes Zeitfenster verschoben und mit der vorgesehenen Bandbreitensteuerung versehen.

Rollback

Ursprünglichen Zeitplan und ursprüngliche Bandbreitenrichtlinie wiederherstellen.

Verifikation

Beobachtungszeitraum: 7 Tage
Unterbrechungen:      keine
Output Drops:         keine neue Zunahme
Anwendungsfehler:     keine
Replikation:          weiterhin erfolgreich

Festgestellte Ursache

Ein regelmäßig gestarteter Replikationsauftrag erzeugte eine kurzzeitige Überlastung des gemeinsamen Uplinks.

37. Beispiel „Fehler nach acht Stunden“

Symptom

Ein Benutzer wird fast täglich am Nachmittag aus einer Anwendung abgemeldet.

Zeitvergleich

Anmeldung:       08:05 Uhr
Fehler:          16:05 Uhr
Sitzungsdauer:   8 Stunden

Weitere Tage:

Anmeldung 07:58 Uhr → Fehler 15:58 Uhr
Anmeldung 08:12 Uhr → Fehler 16:12 Uhr
Anmeldung 08:03 Uhr → Fehler 16:03 Uhr

Das Problem tritt nicht zu einer festen Uhrzeit, sondern nach einer festen Sitzungsdauer auf.

Prüfbereich

Festgestellte Ursache

Die Anwendung erneuerte ein nach acht Stunden ablaufendes Token nicht korrekt.

Lehre

Feste Uhrzeit und feste Laufzeit müssen unterschieden werden.

38. Beispiel „sporadischer Fehler durch einen Serverknoten“

Symptom

Eine Webanwendung funktioniert meistens, zeigt aber gelegentlich einen TLS- oder Serverfehler.

Aufbau

Client
  |
Load Balancer
  |
  +-- Webserver 1
  +-- Webserver 2
  +-- Webserver 3

Beobachtung

Zielknoten Ergebnis
Webserver 1 funktioniert
Webserver 2 funktioniert
Webserver 3 Fehler
Zugriff über Load Balancer nur gelegentlich Fehler

Festgestellte Ursache

Nur Webserver 3 besitzt eine fehlerhafte Konfiguration. Der Fehler tritt deshalb nur auf, wenn der Load Balancer eine Anfrage diesem Knoten zuweist.

Lehre

Bei verteilten Systemen müssen alle Knoten einzeln verglichen werden.

39. Ungeeignete Sofortmaßnahmen

Nicht als erste Maßnahme verwenden:

Solche Maßnahmen können Beweise vernichten, neue Störungen verursachen oder Sicherheits- und Betriebsvorgaben verletzen.

40. Vollständige Prüfreihenfolge

  1. genaue Fehlermeldung und Benutzeraktion erfassen.
  2. exakten Zeitpunkt und Dauer dokumentieren.
  3. betroffenen Benutzer, Client und Standort bestimmen.
  4. betroffene Anwendung und Zielsysteme erfassen.
  5. prüfen, ob ein oder mehrere Benutzer betroffen sind.
  6. feste Uhrzeit von fester Laufzeit unterscheiden.
  7. Häufigkeit und wiederkehrendes Muster bestimmen.
  8. Zeitsynchronisation aller beteiligten Systeme prüfen.
  9. Monitoring- und Protokollaufbewahrung prüfen.
  10. kontinuierliche Messung mit Zeitstempeln einrichten.
  11. Gateway, internes Ziel und externes Ziel vergleichen.
  12. TCP-Port und Anwendungsantwort getrennt prüfen.
  13. Windows- oder Linux-Protokolle zeitlich filtern.
  14. Client-, Netzwerk- und Serverprotokolle vergleichen.
  15. Monitoringauflösung kontrolliert erhöhen.
  16. Schnittstellenstatus und Link-Flaps beobachten.
  17. Fehler- und Verwerfungszähler als Verlauf erfassen.
  18. WLAN-Ereignisse, Roaming und Retry-Rate prüfen.
  19. DHCP-Lease und mögliche Adresskonflikte untersuchen.
  20. DNS-Auflösung, TTL und unterschiedliche Antworten prüfen.
  21. Sitzungslaufzeiten, Token und Timeouts vergleichen.
  22. Zertifikatslaufzeiten und Serverknoten prüfen.
  23. geplante Aufgaben, Timer und Cronjobs untersuchen.
  24. Backups, Scans, Updates und Replikationen vergleichen.
  25. CPU, Arbeitsspeicher, Storage und Netzwerk überwachen.
  26. Temperatur, Stromversorgung und PoE berücksichtigen.
  27. WAN-, Provider- und VPN-Ereignisse prüfen.
  28. bei Bedarf autorisierten Ringpuffer-Mitschnitt einrichten.
  29. alle Ereignisse auf einer gemeinsamen Zeitleiste darstellen.
  30. zuerst auftretendes Ereignis von Folgefehlern unterscheiden.
  31. genau eine messbare Hypothese formulieren.
  32. kontrollierte Reproduktion planen.
  33. Ausgangszustand und Rollback dokumentieren.
  34. genau eine freigegebene Änderung durchführen.
  35. ursprüngliche Messungen wiederholen.
  36. ausreichend langen Beobachtungszeitraum einhalten.
  37. Nebenwirkungen und Sicherheitsfunktionen kontrollieren.
  38. temporäre Diagnosemaßnahmen entfernen.
  39. Ursache, Maßnahme, Rollback und Nachweis dokumentieren.

41. Checkliste „Fehler tritt nur manchmal auf“

42. Schnellreferenz

Beobachtung Nächster Prüfbereich
Fehler immer zur gleichen Uhrzeit geplante Aufgaben, Backups, Scans oder Updates
Fehler immer nach gleicher Laufzeit Sitzung, Token, Lease, Timeout oder Zertifikat
nur ein Client betroffen Client, Treiber, Kabel, WLAN oder lokale Software
mehrere Clients gleichzeitig betroffen gemeinsame Infrastruktur oder zentraler Dienst
Gateway ebenfalls nicht erreichbar Clientzugang, WLAN, Switchport oder lokales Netz
Gateway erreichbar, Server nicht interner Folgepfad, Servernetz oder Server
nur Anwendung fehlerhaft Dienst, Sitzung, Datenbank oder Anwendung
nur ein Serverknoten fehlerhaft Konfiguration dieses Knotens
Link-Up-/Link-Down-Ereignisse Kabel, Port, Transceiver, Treiber oder Stromversorgung
CRC-Fehler steigen kurzzeitig physischer Übertragungsweg
Output Drops steigen kurzzeitig Auslastung oder nachgelagerter Engpass
Fehler während Backup Netzwerk-, CPU- oder Storage-Auslastung vergleichen
Fehler beim DNS-TTL-Ablauf DNS-Server, Cache und Zieladressen vergleichen
Fehler bei DHCP-Erneuerung DHCP-Server, Lease und Adresskonflikte
Fehler nur im WLAN Funkstrecke, Roaming, Kanal, Airtime oder Access Point
Fehler nur über VPN Tunnel, Gateway, Timeout, MTU oder Internetpfad
Fehler bei hoher Temperatur Kühlung, Lüfter oder Hardware
Monitoring zeigt nichts Messintervall und Aggregation prüfen
Neustart beseitigt Fehler vorübergehend Zustand vor dem Neustart vollständig erfassen
Ereignisse verschiedener Systeme passen nicht Uhrzeit, Zeitzone und NTP prüfen
Fehler nicht direkt reproduzierbar kontinuierliche Messung und Ringpuffer einsetzen

Merksatz

Bei einem sporadischen Fehler ist der genaue Zeitpunkt der wichtigste Ausgangspunkt. Messungen und Protokolle müssen bereits vor dem nächsten Auftreten bereitstehen. Erst durch Zeitstempel, wiederkehrende Muster und eine gemeinsame Ereigniszeitleiste lassen sich Ursache und Folge zuverlässig voneinander unterscheiden.

Quellen und weiterführende Dokumentation

7.7 Netzwerk oder Anwendung ist langsam

1. Ziel dieser Seite

Die Meldung „Das Netzwerk ist langsam“ beschreibt zunächst nur die Wahrnehmung des Benutzers. Die tatsächliche Ursache kann unter anderem im Client, im Netzwerk, auf dem Server, im Storage, in der Datenbank oder in der Anwendung liegen.

Diese Seite zeigt, wie ein Leistungsproblem systematisch eingegrenzt wird.

Ziel ist die Unterscheidung zwischen:

2. „Langsam“ messbar beschreiben

Ungeeignet:

Das Netzwerk ist langsam.

Besser:

Das Öffnen einer 20-MB-Datei vom Dateiserver dauert seit 09:30 Uhr
ungefähr 45 Sekunden. Normalerweise dauert es weniger als 5 Sekunden.
Betroffen sind drei Benutzer im zweiten Obergeschoss.
Internetseiten und das Standardgateway reagieren normal.

Zu erfassen sind:

Beispiel

Merkmal Beobachtung
Aktion Öffnen einer Datei vom Dateiserver
Dateigröße 20 MB
Normalzustand 3 bis 5 Sekunden
aktueller Zustand 40 bis 50 Sekunden
Beginn seit ungefähr 09:30 Uhr
Betroffene drei Benutzer
Standort zweites Obergeschoss
Verbindung WLAN
Internet normal
Gateway normal erreichbar
Dateiserver hohe Antwortzeit

Erst durch einen solchen Vergleich wird aus einer subjektiven Meldung ein messbares Problem.

3. Wichtige Leistungsbegriffe unterscheiden

Begriff Bedeutung
Latenz Zeit, die ein Datenpaket oder eine Anfrage bis zur Antwort benötigt
Paketverlust Anteil der Pakete, die ihr Ziel nicht erreichen
Bandbreite theoretisch oder technisch verfügbare Übertragungskapazität
Durchsatz tatsächlich übertragene Datenmenge pro Zeiteinheit
Jitter Schwankung der Laufzeit aufeinanderfolgender Pakete
Antwortzeit gesamte Dauer einer Anfrage aus Benutzersicht
IOPS Anzahl der Ein- und Ausgabeoperationen eines Speichers pro Sekunde
Storage-Latenz Wartezeit einer Speicheroperation
CPU-Auslastung Anteil der aktuell verwendeten Prozessorleistung
Arbeitsspeicherauslastung Belegung des physischen Arbeitsspeichers
Warteschlange Anforderungen, die auf Verarbeitung oder Übertragung warten
Retransmission erneute Übertragung verlorener oder nicht bestätigter TCP-Daten
Applikationslatenz Zeit, welche die Anwendung für die Verarbeitung benötigt

Eine schnelle Netzwerkverbindung garantiert keinen hohen Anwendungsdurchsatz.

Beispiel

Verbindungsgeschwindigkeit: 1 Gbit/s
tatsächlicher Dateidurchsatz: 8 Mbit/s

Die angezeigte Verbindungsgeschwindigkeit beschreibt nur die ausgehandelte Verbindung. Sie beweist nicht, dass die gesamte Strecke oder das Zielsystem diese Datenrate bereitstellen kann.

4. Mögliche Ursachenbereiche

Benutzeraktion
      ↓
Client
      ↓
lokale Verbindung
      ↓
Switch, WLAN oder VPN
      ↓
Routing, Firewall oder WAN
      ↓
Server
      ↓
Anwendung
      ↓
Datenbank oder Storage

Eine Verzögerung kann an jeder Stelle dieser Kette entstehen.

Client

Netzwerk

Server

Anwendung und Datenbank

5. Zuerst den Umfang bestimmen

Zu klären ist:

  1. Ist nur ein Benutzer betroffen?
  2. Sind mehrere Benutzer betroffen?
  3. Ist nur ein Standort betroffen?
  4. Sind nur WLAN-Benutzer betroffen?
  5. Sind auch kabelgebundene Clients betroffen?
  6. Ist nur eine Anwendung langsam?
  7. Sind mehrere Dienste desselben Servers betroffen?
  8. Sind interne und externe Ziele betroffen?
  9. Tritt das Problem zu einer bestimmten Uhrzeit auf?
  10. Tritt es nur bei einer bestimmten Datenmenge auf?

Schnelle Eingrenzung

Beobachtung Wahrscheinlicher Prüfbereich
nur ein Client betroffen Client, Treiber, Kabel, WLAN oder lokale Software
mehrere Clients gleichzeitig betroffen gemeinsame Infrastruktur oder zentraler Dienst
nur ein Standort betroffen Standortanbindung, Switch, WLAN oder WAN
nur WLAN betroffen Funkstrecke, Access Point, Kanal oder Roaming
LAN und WLAN betroffen gemeinsamer Netzwerkpfad, Server oder Anwendung
nur eine Anwendung betroffen Anwendung, Datenbank, API oder Sitzung
mehrere Dienste eines Servers betroffen Server, Betriebssystem, Storage oder Hypervisor
alle internen Dienste langsam Netzwerk, DNS, Firewall oder zentrale Infrastruktur
nur Internet langsam WAN, Provider, Proxy oder externe Ziele
nur große Dateien langsam Durchsatz, Paketverlust, Storage oder Übertragungsweg
kleine Anfragen bereits langsam Latenz, DNS, Anwendung oder Datenbank

6. Vergleich mit einer funktionierenden Referenz

Ein Vergleichssystem sollte möglichst ähnlich sein:

Beispiel

Prüfung betroffener Client Vergleichsclient
Gateway-Latenz 2 ms 2 ms
Server-Latenz 3 ms 3 ms
Dateiübertragung 4 MB/s 85 MB/s
CPU-Auslastung 15 % 20 %
Datenträgerauslastung 100 % 8 %

In diesem Beispiel ist der Netzwerkpfad zunächst unauffällig. Die lokale Datenträgerauslastung des betroffenen Clients ist dagegen auffällig.

7. Baseline festlegen

Ein Messwert ist nur aussagekräftig, wenn bekannt ist, welcher Wert normalerweise erreicht wird.

Beispiel

Normale Antwortzeit:       200 bis 400 ms
Aktuelle Antwortzeit:      4 bis 8 Sekunden
Normale Dateiübertragung:  80 bis 95 MB/s
Aktuelle Übertragung:      5 bis 12 MB/s
Normale Storage-Latenz:    2 bis 8 ms
Aktuelle Storage-Latenz:   80 bis 250 ms

Mögliche Baselines:

Messungen sollten möglichst unter vergleichbaren Bedingungen erfolgen.

8. Lokalen Client prüfen

Unter Windows:

Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 10 Name, CPU, WorkingSet

Netzwerkadapter anzeigen:

Get-NetAdapter |
    Format-Table Name, Status, LinkSpeed, InterfaceDescription

Adapterstatistiken:

Get-NetAdapterStatistics

Aktuelle IP-Konfiguration:

ipconfig /all

Unter Linux:

top

Alternativ, sofern installiert:

htop

Arbeitsspeicher:

free -h

Datenträgerbelegung:

df -h

Netzwerkschnittstellen:

Statistiken:

ip -s link show

Zu prüfen sind:

Ein ausgelasteter Client kann eine langsame Anwendung verursachen, obwohl Netzwerk und Server ordnungsgemäß arbeiten.

9. Latenz und Paketverlust messen

Unter Windows:

ping -t <ziel>

Beispiel:

ping -t 192.0.2.10

Unter Linux oder macOS:

ping <ziel>

Es sollten mehrere Ziele verglichen werden:

Client → Standardgateway
Client → interner Server
Client → externes Referenzziel

Auswertung

Gateway interner Server externes Ziel Mögliche Eingrenzung
langsam langsam langsam Clientzugang oder lokales Netzwerk
normal langsam normal interner Pfad oder Servernetz
normal normal langsam WAN, Provider oder externer Pfad
normal normal normal Anwendung, Port, Serverprozess oder Datenbank
Paketverlust Paketverlust Paketverlust lokale Verbindung oder gemeinsamer Uplink

Ping prüft ICMP-Erreichbarkeit. Eine normale Ping-Antwort beweist nicht, dass die Anwendung schnell arbeitet.

10. Netzwerkpfad untersuchen

Unter Windows:

tracert <ziel>

Unter Linux:

traceroute <ziel>

Unter macOS:

traceroute <ziel>

Falls vorhanden, kann eine fortlaufende Pfadanalyse durchgeführt werden:

mtr <ziel>

Zu prüfen sind:

Ein Router muss ICMP-Antworten nicht mit derselben Priorität wie weitergeleiteten Verkehr behandeln. Ein auffälliger Zwischenknoten allein beweist deshalb noch keinen Fehler. Entscheidend ist, ob die Beeinträchtigung auch an nachfolgenden Zielen sichtbar bleibt.

11. TCP-Port getrennt prüfen

Unter Windows:

Test-NetConnection <server> -Port <port>

Beispiel:

Test-NetConnection fileserver.example.local -Port 445

Weitere Beispiele:

Test-NetConnection webserver.example.local -Port 443

Test-NetConnection dbserver.example.local -Port 1433

Unter Linux oder macOS, sofern Netcat vorhanden ist:

nc -vz <server> <port>

Beispiel:

nc -vz webserver.example.local 443

Damit wird geprüft, ob der TCP-Verbindungsaufbau möglich ist. Die tatsächliche Antwortzeit der Anwendung wird dadurch noch nicht vollständig gemessen.

12. Anwendungsantwort mit curl messen

Gesamte Antwortzeit:

curl \
    -o /dev/null \
    -s \
    -w "DNS: %{time_namelookup}\nTCP: %{time_connect}\nTLS: %{time_appconnect}\nErstes Byte: %{time_starttransfer}\nGesamt: %{time_total}\n" \
    https://example.com/

Beispielausgabe:

DNS:         0.012
TCP:         0.028
TLS:         0.071
Erstes Byte: 3.842
Gesamt:      3.901

Interpretation:

Vergleich

DNS:         0,012 Sekunden
TCP:         0,028 Sekunden
TLS:         0,071 Sekunden
Erstes Byte: 3,842 Sekunden

Das Netzwerk baut die Verbindung schnell auf. Die lange Wartezeit bis zum ersten Byte weist eher auf die Verarbeitung im Zielsystem hin.

13. DNS-Antwortzeit prüfen

Unter Windows:

Measure-Command {
    Resolve-DnsName <hostname>
}

Einzelne DNS-Abfrage:

Resolve-DnsName <hostname>

Unter Linux oder macOS, sofern dig vorhanden ist:

dig <hostname>

Kurze Ausgabe:

dig <hostname> +stats

Zu prüfen sind:

Beispiel

Aufruf über IP-Adresse:  0,4 Sekunden
Aufruf über Hostnamen:   5,2 Sekunden

Dieser Unterschied weist auf die Namensauflösung hin. Er beweist noch nicht, welcher DNS-Server oder welche DNS-Konfiguration die Verzögerung verursacht.

14. Durchsatz messen

Für eine kontrollierte Netzwerkmessung kann iperf3 verwendet werden. Dafür wird auf einem autorisierten Zielsystem ein iperf3-Server benötigt.

Server:

iperf3 -s

Client:

iperf3 -c <server-ip>

Messung in Gegenrichtung:

iperf3 -c <server-ip> -R

Mehrere parallele Verbindungen:

iperf3 -c <server-ip> -P 4

UDP-Tests dürfen nur kontrolliert und mit begrenzter Bandbreite durchgeführt werden:

iperf3 -c <server-ip> -u -b 10M

Zu vergleichen sind:

Wichtig

Ein unkontrollierter Durchsatztest kann produktive Verbindungen beeinträchtigen. Zielsystem, Testdauer und erzeugte Last müssen abgestimmt sein.

15. Dateitransfer richtig bewerten

Ein Dateitransfer misst nicht ausschließlich das Netzwerk.

Beteiligt sind:

Quelldatenträger
      ↓
Quellsystem
      ↓
Netzwerk
      ↓
Zielsystem
      ↓
Zieldatenträger

Mögliche Begrenzungen:

Beispiel

Eine Datei mit 10 GB:          80 MB/s
100.000 sehr kleine Dateien:    8 MB/s

Viele kleine Dateien erzeugen wesentlich mehr Verwaltungs- und Speicheroperationen. Die niedrigere Übertragungsrate beweist deshalb nicht automatisch ein Netzwerkproblem.

16. Interface-Fehler und Drops prüfen

Unter Windows:

Get-NetAdapterStatistics

Unter Linux:

ip -s link show

Auf einem verwalteten Switch müssen die herstellerspezifischen Diagnosebefehle verwendet werden.

Zu beobachten sind:

Zähler müssen als Verlauf betrachtet werden.

Beispiel

09:00 Uhr:  15 CRC-Fehler
09:30 Uhr:  15 CRC-Fehler
10:00 Uhr:  15 CRC-Fehler

Der Zähler steigt nicht. Die Fehler können aus einem früheren Zeitraum stammen.

09:00 Uhr:    15 CRC-Fehler
09:30 Uhr:   280 CRC-Fehler
10:00 Uhr: 4.500 CRC-Fehler

Der Zähler nimmt aktuell zu und weist auf ein Problem des physischen Übertragungswegs hin.

17. Duplex und Verbindungsgeschwindigkeit prüfen

Mögliche Symptome:

Zu prüfen sind:

Geschwindigkeit und Duplex dürfen nicht wahllos fest eingestellt werden. Beide Seiten müssen zusammenpassen und die Änderung muss dokumentiert sowie freigegeben sein.

18. WLAN-Leistung untersuchen

Bei WLAN-Verbindungen sind zusätzlich zu betrachten:

Unter Windows:

netsh wlan show interfaces

WLAN-Bericht:

netsh wlan show wlanreport

Wichtiger Vergleich:

Test LAN WLAN Eingrenzung
Anwendung schnell langsam WLAN oder Access Point
Anwendung langsam langsam gemeinsamer Pfad, Server oder Anwendung
nur ein WLAN-Client langsam – betroffen Client, Treiber, Standort oder Funkband
alle Clients eines AP langsam – betroffen Access Point, Kanal, Uplink oder PoE

Ein hoher angezeigter WLAN-Verbindungswert entspricht nicht automatisch dem tatsächlichen Nutzdurchsatz.

19. VPN-Verbindung untersuchen

Mögliche Ursachen:

Zu vergleichen sind:

ohne VPN → internes Testziel, sofern autorisiert erreichbar
mit VPN  → internes Testziel
mit VPN  → Standardgateway des lokalen Netzes
mit VPN  → VPN-Gateway

Außerdem sollte geprüft werden:

VPN- oder Sicherheitsfunktionen dürfen nicht zur Diagnose umgangen werden.

20. Serverressourcen prüfen

Wichtige Messwerte:

Unter Linux:

uptime

free -h

df -h

top

Falls installiert:

vmstat 1

iostat -xz 1

Unter Windows können Task-Manager, Ressourcenmonitor, Leistungsüberwachung und PowerShell verwendet werden.

Beispiel für Prozesse mit hoher CPU-Zeit:

Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 10 Name, CPU, WorkingSet

Ein einzelner aktueller Messwert reicht bei sporadischen Problemen nicht aus. Die Werte müssen während der tatsächlichen Verzögerung aufgezeichnet werden.

21. CPU-Auslastung richtig interpretieren

Eine hohe CPU-Auslastung kann auf einen Engpass hinweisen, muss aber im Zusammenhang betrachtet werden.

Zu prüfen sind:

Beispiel

Gesamtauslastung: 35 %
Anwendungsprozess: ein Prozesskern dauerhaft bei 100 %

Eine nicht ausreichend parallelisierte Anwendung kann bereits durch einen vollständig ausgelasteten Kern begrenzt werden, obwohl die Gesamtauslastung unauffällig wirkt.

22. Arbeitsspeicher und Paging prüfen

Hohe Speicherbelegung allein beweist keinen Fehler. Betriebssysteme nutzen freien Arbeitsspeicher häufig als Cache.

Wichtiger sind:

Typische Wirkung

Arbeitsspeicher reicht nicht aus
            ↓
Auslagerung auf Datenträger
            ↓
Storage-Latenz steigt
            ↓
Anwendung reagiert langsam

Deshalb müssen Arbeitsspeicher- und Storage-Messwerte gemeinsam betrachtet werden.

23. Storage-Latenz untersuchen

Eine hohe Datenträgerauslastung bedeutet nicht automatisch einen hohen Datendurchsatz. Viele kleine oder zufällige Operationen können einen Datenträger vollständig auslasten.

Zu prüfen sind:

Beispiel

Netzwerkauslastung:  12 %
CPU-Auslastung:      30 %
Storage-Latenz:     180 ms
Anwendungsantwort:    8 s

Die niedrige Netzwerkauslastung spricht gegen einen reinen Bandbreitenengpass. Die hohe Storage-Latenz ist dagegen auffällig.

Hersteller- und betriebssystemspezifische Grenzwerte müssen anhand der jeweiligen Dokumentation und des normalen Betriebszustands bewertet werden.

24. Datenbank als Ursache untersuchen

Mögliche Ursachen:

Zu vergleichen sind:

Beispiel

TCP-Verbindung zum Webserver:      20 ms
Antwort des Webservers:             6 s
Datenbankabfrage:                 5,7 s

Das Netzwerk ist in diesem Beispiel nicht der größte Zeitanteil. Die Datenbankabfrage bestimmt nahezu die gesamte Antwortzeit.

Produktive Abfragen dürfen nicht unkontrolliert wiederholt oder verändert werden. Datenbankdiagnosen müssen mit den vorgesehenen Werkzeugen und Berechtigungen erfolgen.

25. Anwendungs- und API-Abhängigkeiten prüfen

Eine Anwendung kann von mehreren Diensten abhängig sein:

Client
  ↓
Webanwendung
  ↓
Authentifizierungsdienst
  ↓
API
  ↓
Datenbank
  ↓
Storage

Zu prüfen sind:

Beispiel

Anwendung selbst:          100 ms
externe API:             4.800 ms
Gesamtantwort:           5.100 ms

Aus Benutzersicht ist die Anwendung langsam. Die eigentliche Verzögerung entsteht jedoch bei einer externen API.

26. Load Balancer und mehrere Serverknoten prüfen

Bei verteilten Anwendungen kann nur ein einzelner Knoten langsam sein.

Beispiel

Zielknoten Antwortzeit
Webserver 1 250 ms
Webserver 2 230 ms
Webserver 3 8.400 ms
Zugriff über Load Balancer wechselnd zwischen schnell und langsam

Mögliche Ursachen des einzelnen Knotens:

Alle Knoten müssen einzeln verglichen werden. Ein gelegentlich langsamer Zugriff über den Load Balancer kann entstehen, wenn nur ein Teil der Anfragen an den fehlerhaften Knoten gelangt.

27. Zeitgesteuerte Last berücksichtigen

Leistungsprobleme können regelmäßig mit anderen Prozessen zusammenfallen:

Beispiel

02:00:00 Backup startet
02:00:12 Storage-Latenz steigt
02:00:18 Datenbankabfragen werden langsamer
02:00:25 Anwendung überschreitet Zeitlimit
02:20:00 Backup endet
02:20:15 Storage-Latenz normalisiert sich

Eine gemeinsame Zeitleiste zeigt die mögliche Abhängigkeit.

Der zeitliche Zusammenhang ist ein Hinweis. Die Ursache muss durch Messwerte und gegebenenfalls eine kontrollierte Änderung bestätigt werden.

28. Paketmitschnitt gezielt einsetzen

Ein Paketmitschnitt kann unter anderem zeigen:

Beispiel mit dumpcap:

dumpcap \
    -i 1 \
    -f "host 192.0.2.45" \
    -b duration:300 \
    -b files:12 \
    -w langsame-anwendung.pcapng

Dabei gelten folgende Regeln:

Ein Mitschnitt auf dem Client zeigt nicht automatisch alle Pakete anderer Systeme oder Netzwerksegmente.

29. TCP-Retransmissions bewerten

TCP überträgt verlorene Daten erneut. Viele erneute Übertragungen können den Durchsatz erheblich reduzieren.

Mögliche Ursachen:

Vereinfachtes Beispiel

Datenpaket wird gesendet
        ↓
Paket geht verloren
        ↓
Bestätigung bleibt aus
        ↓
TCP wartet
        ↓
Daten werden erneut übertragen

Die Bandbreite kann technisch hoch sein, während der tatsächlich nutzbare Durchsatz durch Paketverlust stark sinkt.

30. Ursache und Wartezeit trennen

Eine langsame Anwendung kann in verschiedene Zeitanteile zerlegt werden.

Beispiel

Verarbeitungsschritt Dauer
DNS-Auflösung 20 ms
TCP-Verbindungsaufbau 25 ms
TLS-Verbindungsaufbau 70 ms
Webserververarbeitung 180 ms
Datenbankabfrage 4.800 ms
Übertragung der Antwort 90 ms
Gesamtdauer 5.185 ms

Die Datenbankabfrage beansprucht den größten Teil der Gesamtdauer.

Dadurch kann die Diagnose auf den Bereich mit dem größten Zeitanteil konzentriert werden.

31. Mehrere Systeme auf einer Zeitleiste vergleichen

Zeit Client Netzwerk Server Storage Anwendung
09:59:50 normal normal normal 4 ms 300 ms
10:00:00 Anfrage startet normal CPU 40 % 8 ms 400 ms
10:00:05 wartet normal CPU 45 % 170 ms 5 s
10:00:10 wartet normal CPU 48 % 240 ms 10 s
10:00:15 Antwort normal CPU 42 % 12 ms normal

In diesem Beispiel steigen die Netzwerklatenz und CPU-Auslastung nicht auffällig. Die Storage-Latenz steigt dagegen zeitgleich mit der langsamen Anwendung.

32. Hypothese messbar formulieren

Ungeeignet:

Der Server ist wahrscheinlich überlastet.

Besser:

Wenn die Anwendung erneut länger als fünf Sekunden benötigt,
steigt vermutlich gleichzeitig die Storage-Latenz des Datenbankservers
auf mehr als 100 ms.

Prüfung:

Anwendungsantwortzeit messen
Storage-Latenz aufzeichnen
Datenbankwartezeiten erfassen
Zeitstempel vergleichen

Eine gute Hypothese enthält:

33. Kontrollierte Änderung durchführen

Erst nach ausreichender Eingrenzung wird genau eine Änderung vorgenommen.

Mögliche Änderungen:

Ungeeignet:

Treiber aktualisieren, Kabel ersetzen, DNS ändern und Server neu starten.

Wenn mehrere Änderungen gleichzeitig durchgeführt werden, kann die wirksame Maßnahme nicht mehr eindeutig bestimmt werden.

34. Rollback festlegen

Vor jeder Änderung dokumentieren:

Beispiel

Änderung:
Fehlerhaften Webserver 3 kontrolliert aus dem Load Balancer nehmen.

Erwartung:
Die wechselnden Antwortzeiten verschwinden.

Rollback:
Webserver 3 mit der ursprünglichen Gewichtung wieder aufnehmen.

Abbruchkriterium:
Verbleibende Knoten überschreiten die zulässige Auslastung.

35. Verifikation

Nach der Änderung müssen dieselben Messungen wie vorher wiederholt werden.

Zu prüfen sind:

Beispiel

Vorher:
Antwortzeit:       6 bis 12 Sekunden
Storage-Latenz:   120 bis 260 ms
Fehlerhäufigkeit:  20 bis 30 Ereignisse pro Stunde

Nachher:
Antwortzeit:       250 bis 400 ms
Storage-Latenz:    3 bis 8 ms
Fehlerhäufigkeit:  0 Ereignisse in 48 Stunden

Ein einzelner erfolgreicher Test reicht nicht aus, wenn das Problem vorher nur gelegentlich auftrat.

36. Beispiel „Netzwerk angeblich langsam“

Symptom

Mehrere Benutzer melden, dass das Öffnen von Kundendatensätzen am Vormittag mehrere Sekunden dauert.

Erste Messungen

Gateway-Latenz:             1 ms
Webserver-Latenz:           2 ms
Paketverlust:               0 %
TCP-Verbindungsaufbau:     20 ms
Zeit bis zum ersten Byte:   7 s

Servermessungen

CPU-Auslastung:            35 %
Arbeitsspeicher:           unauffällig
Netzwerkauslastung:        10 %
Storage-Latenz:             6 ms

Datenbankmessung

Abfragedauer:              6,7 s
Warteursache:              Datenbanksperre

Festgestellte Ursache

Ein zeitgleich laufender Import hielt eine Datenbanksperre. Netzwerk und Webserver waren nicht die Ursache.

Kontrollierte Maßnahme

Der Importprozess wurde nach Prüfung so angepasst, dass die Sperre kürzer gehalten wird.

Verifikation

Antwortzeit:              300 bis 450 ms
Paketverlust:             weiterhin 0 %
Datenbanksperren:         keine auffällige Wartezeit
Import:                   weiterhin erfolgreich

37. Beispiel „Dateiserver ist langsam“

Symptom

Ein Benutzer erreicht beim Kopieren großer Dateien nur ungefähr 8 MB/s.

Vergleich

Messung betroffener Client Referenzclient
Verbindung 1 Gbit/s 1 Gbit/s
Ping zum Server 2 ms 2 ms
iperf3 920 Mbit/s 925 Mbit/s
Dateiübertragung 8 MB/s 90 MB/s
lokale Datenträgerauslastung 100 % 15 %

Festgestellte Ursache

Der lokale Zieldatenträger des betroffenen Clients war der Engpass. Die Netzwerkverbindung erreichte im kontrollierten Durchsatztest einen normalen Wert.

Lehre

Ein langsamer Dateitransfer ist nicht automatisch ein langsames Netzwerk.

38. Beispiel „WLAN ist langsam“

Symptom

Benutzer in einem Besprechungsraum melden am Nachmittag langsame Anwendungen und Videokonferenzen.

Vergleich

LAN:                         normal
WLAN außerhalb des Raums:    normal
WLAN im Besprechungsraum:    langsam

Messwerte

Signalstärke:                ausreichend
Kanalauslastung:             sehr hoch
Retry-Rate:                  stark erhöht
aktive Clients:              42
AP-Uplink:                   unauffällig

Festgestellte Ursache

Der Funkkanal war stark ausgelastet. Viele erneute Übertragungen reduzierten den tatsächlichen Durchsatz.

Kontrollierte Maßnahme

Die Funkplanung wurde anhand der vorgesehenen WLAN-Managementfunktionen angepasst.

Verifikation

Retry-Rate:                  deutlich reduziert
Anwendungsantwortzeit:       normal
Videokonferenzen:            stabil

39. Ungeeignete Sofortmaßnahmen

Nicht als erste Maßnahme verwenden:

Solche Maßnahmen können Beweise vernichten, neue Fehler verursachen oder die eigentliche Ursache verdecken.

40. Vollständige Prüfreihenfolge

  1. genaue Benutzeraktion erfassen.
  2. erwartete und tatsächliche Dauer dokumentieren.
  3. Startzeitpunkt, Häufigkeit und Dauer bestimmen.
  4. betroffene Benutzer, Clients und Standorte erfassen.
  5. LAN, WLAN und VPN unterscheiden.
  6. einzelne Anwendung und allgemeines Systemverhalten vergleichen.
  7. betroffenen Client mit Referenzclient vergleichen.
  8. normalen Leistungsbereich als Baseline bestimmen.
  9. lokale CPU-, Speicher- und Datenträgerauslastung prüfen.
  10. Verbindungsgeschwindigkeit und Adapterstatus prüfen.
  11. Gateway, internes Ziel und externes Ziel messen.
  12. Latenz und Paketverlust getrennt betrachten.
  13. Netzwerkpfad untersuchen.
  14. TCP-Port prüfen.
  15. DNS-Antwortzeit messen.
  16. Anwendungsantwort in einzelne Zeitanteile zerlegen.
  17. kontrollierten Durchsatztest durchführen.
  18. Interface-Fehler, Drops und Retransmissions prüfen.
  19. WLAN-Auslastung und Retry-Rate berücksichtigen.
  20. VPN-Pfad und VPN-Gateway prüfen.
  21. Server-CPU und Arbeitsspeicher überwachen.
  22. Paging, Swapping und Ressourcenlimits prüfen.
  23. Storage-Latenz und Warteschlangen untersuchen.
  24. Datenbankabfragen, Sperren und Verbindungen prüfen.
  25. APIs und externe Abhängigkeiten untersuchen.
  26. alle Serverknoten einzeln vergleichen.
  27. geplante Aufgaben und Hintergrundprozesse prüfen.
  28. Messwerte auf einer gemeinsamen Zeitleiste darstellen.
  29. größten Zeitanteil bestimmen.
  30. Ursache und Folge unterscheiden.
  31. genau eine messbare Hypothese formulieren.
  32. Ausgangszustand und Rollback dokumentieren.
  33. genau eine freigegebene Änderung durchführen.
  34. ursprüngliche Messung wiederholen.
  35. ausreichend lange Verifikation durchführen.
  36. Nebenwirkungen kontrollieren.
  37. temporäre Diagnosemaßnahmen entfernen.
  38. Ursache, Maßnahme und Nachweis dokumentieren.

41. Checkliste „Netzwerk oder Anwendung ist langsam“

42. Schnellreferenz

Beobachtung Nächster Prüfbereich
nur ein Client langsam Client, Treiber, Datenträger oder lokale Software
alle Clients langsam gemeinsame Infrastruktur, Server oder Anwendung
Gateway bereits langsam lokaler Zugang, WLAN, Kabel oder Switch
Gateway normal, Server langsam interner Pfad, Servernetz oder Server
Ping normal, Anwendung langsam Anwendung, Datenbank, API oder Storage
DNS langsam DNS-Server, Weiterleitung oder Namensauflösung
TCP-Aufbau langsam Netzwerkpfad, Firewall oder Zielsystem
erstes Byte langsam Server, Anwendung oder Datenbank
Download nach erstem Byte langsam Durchsatz, Paketverlust oder Datenmenge
iperf3 schnell, Dateiübertragung langsam Datenträger, Dateisystem, Virenscanner oder Protokoll
CRC-/FCS-Fehler steigen Kabel, Stecker, Port oder Transceiver
Output Drops steigen Auslastung oder nachgelagerter Engpass
nur WLAN langsam Funkkanal, Retry-Rate, Roaming oder Access Point
nur VPN langsam Internetpfad, VPN-Gateway, MTU oder Verschlüsselung
nur ein Serverknoten langsam Konfiguration oder Ressource dieses Knotens
CPU dauerhaft hoch Prozess, Last oder unzureichende Rechenleistung
CPU unauffällig, Storage-Latenz hoch Storage, Backup, Snapshot oder Datenträger
Speicherdruck und Paging Arbeitsspeicher, Prozess oder Ressourcenlimit
Anwendung während Backup langsam Storage-, Netzwerk- und CPU-Auslastung vergleichen
Fehler nur bei großen Datenmengen Durchsatz, Paketverlust, Storage oder Zeitlimit
Fehler nur bei vielen kleinen Dateien IOPS, Dateisystem und Virenscanner
Monitoring zeigt nichts Messintervall, Maximum und kurzfristige Spitzen prüfen

Merksatz

„Langsam“ ist zunächst nur ein Symptom. Erst durch den Vergleich von Latenz, Paketverlust, Durchsatz, Anwendungsantwortzeit, Serverressourcen, Storage und Datenbankwartezeiten lässt sich bestimmen, an welcher Stelle die tatsächliche Verzögerung entsteht.

Quellen und weiterführende Dokumentation

7.8 Server ist langsam

Ziel dieser Seite

Diese Seite beschreibt die systematische Fehleranalyse, wenn ein Server oder ein darauf bereitgestellter Dienst ungewöhnlich langsam reagiert.

Dabei muss zwischen verschiedenen Ursachen unterschieden werden:

„Der Server ist langsam“ ist lediglich eine Symptombeschreibung. Erst durch Messwerte lässt sich bestimmen, welche Ressource oder Abhängigkeit den Engpass verursacht.

1. Problem exakt beschreiben

Vor der technischen Analyse müssen Soll- und Istzustand dokumentiert werden.

Angabe Beispiel
betroffener Server SRV-APP01
betroffener Dienst interne Webanwendung
Symptom Seitenaufbau dauert 15 Sekunden
Normalzustand unter 2 Sekunden
Beginn 02.08.2026, etwa 09:15 Uhr
Umfang alle Benutzer
Häufigkeit zeitweise
letzter funktionierender Zustand vor dem nächtlichen Backup
letzte Änderung Anwendungsupdate
Vergleichssystem SRV-APP02 reagiert normal

Zu klären ist:

Die Aussage „der Server ist langsam“ reicht für eine gezielte Fehleranalyse nicht aus.

2. Server-, Anwendungs- und Netzwerkproblem unterscheiden

Ein langsamer Dienst beweist nicht automatisch, dass der Server selbst überlastet ist.

Client
  ↓
DNS
  ↓
Netzwerk
  ↓
Firewall oder Proxy
  ↓
Webserver
  ↓
Anwendung
  ↓
Datenbank
  ↓
Storage

Jede dieser Komponenten kann die beobachtete Verzögerung verursachen.

Beobachtung Wahrscheinlicher Prüfbereich
lokale Bedienung ebenfalls langsam Serverressourcen oder Betriebssystem
nur entfernte Zugriffe langsam Netzwerk, VPN, Firewall oder Proxy
nur eine Anwendung langsam Anwendung, Datenbank oder Abhängigkeit
alle Dienste langsam CPU, RAM, Storage, Hypervisor oder Netzwerk
nur bestimmte Abfragen langsam Datenbank, Sperren oder fehlende Indizes
nur zu festen Uhrzeiten langsam Backup, Scan, Wartung oder geplanter Job
nur eine VM betroffen VM-Konfiguration oder Gastbetriebssystem
mehrere VMs auf demselben Host betroffen Hypervisor oder gemeinsames Storage
Ping normal, Anwendung langsam Dienst, TLS, Authentifizierung oder Backend
Ping langsam oder instabil Netzwerkpfad oder Serverüberlastung
Zugriff per IP schnell, per Name langsam DNS-Auflösung
Anmeldung langsam, Dienste danach normal Authentifizierung, GPO, Profil oder DNS

3. Auswirkungen und Priorität bestimmen

Vor der tieferen Analyse muss die betriebliche Auswirkung bewertet werden.

Zu klären ist:

Beispiel:

Kriterium Bewertung
Auswirkung alle Mitarbeiter können nur verzögert arbeiten
Dringlichkeit hoch
Priorität hoch
Ersatzlösung zweiter Anwendungsserver vorhanden
Datenverlust derzeit nicht erkennbar
Eskalation Anwendungs- und Infrastrukturteam informieren

Eine hohe Auslastung ist nicht automatisch ein kritischer Vorfall. Entscheidend ist, ob der vereinbarte Dienst beeinträchtigt wird.

4. Ausgangszustand sichern

Vor einem Neustart oder einer Konfigurationsänderung sollten flüchtige Informationen gesichert werden:

Ein Neustart kann das Symptom vorübergehend beseitigen, vernichtet aber möglicherweise den für die Ursachenanalyse benötigten Zustand.

Vor einer Maßnahme sollte daher mindestens dokumentiert werden:

Zeitpunkt:
betroffener Dienst:
gemessene Antwortzeit:
CPU:
RAM:
Datenträger:
Netzwerk:
auffälliger Prozess:
auffälliges Ereignis:
laufender Hintergrundjob:
letzte Änderung:

5. Sichere Schnellprüfung

Die erste Prüfung sollte möglichst nur lesend erfolgen.

  1. Zeitpunkt und Umfang der Störung bestimmen.
  2. CPU, RAM, Datenträger und Netzwerk gleichzeitig betrachten.
  3. Prozesse mit ungewöhnlicher Ressourcennutzung ermitteln.
  4. Backups, Virenscans, Snapshots und Wartungsjobs prüfen.
  5. Betriebssystem-, Anwendungs- und Hypervisorlogs zeitlich vergleichen.
  6. Antwortzeit vom Client und direkt auf dem Server messen.
  7. Mit einem funktionierenden Vergleichssystem vergleichen.
  8. Erst danach eine kontrollierte Maßnahme auswählen.

Windows:

Get-Date

Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 10 Name, Id, CPU, WorkingSet64

Linux:

date
uptime
top

Diese Momentaufnahmen reichen noch nicht für eine vollständige Bewertung. Kurze Spitzen oder zeitweise auftretende Fehler können dabei unentdeckt bleiben.

6. CPU-Auslastung untersuchen

Eine hohe CPU-Auslastung kann durch einen einzelnen Prozess, mehrere konkurrierende Prozesse oder eine zu geringe bereitgestellte Rechenleistung verursacht werden.

Zu prüfen sind:

Windows:

Get-Counter '\Processor(_Total)\% Processor Time'

Prozesse nach gesamter CPU-Zeit sortieren:

Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 15 Name, Id, CPU, Threads

Aktuelle Prozessorauslastung über CIM:

Get-CimInstance Win32_Processor |
    Select-Object Name, LoadPercentage

Linux:

top

Mit installiertem Paket sysstat:

pidstat 1

Auslastung pro logischer CPU:

mpstat -P ALL 1
Befund Mögliche Bedeutung
ein Prozess belegt dauerhaft einen Kern Single-Thread-Engpass oder Endlosschleife
alle Kerne dauerhaft stark ausgelastet CPU-Sättigung
hohe Systemzeit Kernel, Treiber, Netzwerk oder I/O prüfen
viele Interrupts Netzwerk- oder Hardwareproblem möglich
CPU im Gast niedrig, Anwendung trotzdem langsam Storage, Netzwerk, Sperren oder Hypervisor prüfen
mehrere VMs gleichzeitig langsam Hostüberlastung oder CPU-Scheduling prüfen
kurze regelmäßige Spitzen geplanter Job, Scan oder Monitoring
Prozess-CPU steigt ständig fehlerhafte Anwendung oder unpassende Last

Eine Gesamtauslastung von beispielsweise 25 Prozent schließt einen CPU-Engpass nicht aus. Auf einem System mit vier logischen Prozessoren kann ein einzelner vollständig ausgelasteter Thread ungefähr 25 Prozent Gesamtauslastung verursachen.

7. Arbeitsspeicher untersuchen

Ein hoher belegter Arbeitsspeicher ist nicht automatisch ein Fehler. Betriebssysteme verwenden verfügbaren Speicher beispielsweise für Caches.

Entscheidend sind:

Windows:

Get-CimInstance Win32_OperatingSystem |
    Select-Object TotalVisibleMemorySize,
                  FreePhysicalMemory

Prozesse nach Arbeitsspeicher sortieren:

Get-Process |
    Sort-Object WorkingSet64 -Descending |
    Select-Object -First 15 Name,
                            Id,
                            WorkingSet64,
                            PagedMemorySize64

Leistungsindikatoren abfragen:

Get-Counter `
    '\Memory\Available MBytes',
    '\Memory\Pages/sec'

Linux:

free -h

Ausführlichere Anzeige:

vmstat 1

Prozesse nach Speichernutzung sortieren:

ps aux --sort=-%mem | head
Befund Mögliche Bedeutung
wenig freier Speicher, aber keine Auslagerung nicht zwingend problematisch
dauerhaft starke Paging- oder Swap-Aktivität Arbeitsspeicherengpass
ein Prozess wächst kontinuierlich mögliches Speicherleck
Anwendung erreicht festgelegtes Limit Container-, VM- oder Prozesslimit prüfen
Server wird nach längerer Laufzeit langsamer Speicherleck oder zunehmender Cache möglich
OOM-Ereignis unter Linux Speicher war erschöpft
hoher Commit-Wert unter Windows zugesicherter virtueller Speicher prüfen

Nur den belegten Arbeitsspeicher zu betrachten, reicht nicht aus. Besonders Paging, Swap und die zeitliche Entwicklung sind entscheidend.

8. Datenträger und Storage untersuchen

Ein langsamer Datenträger kann den gesamten Server ausbremsen, obwohl CPU und Arbeitsspeicher unauffällig erscheinen.

Zu prüfen sind:

Windows-Leistungsindikatoren:

Get-Counter `
    '\PhysicalDisk(_Total)\Avg. Disk sec/Read',
    '\PhysicalDisk(_Total)\Avg. Disk sec/Write',
    '\PhysicalDisk(_Total)\Current Disk Queue Length',
    '\PhysicalDisk(_Total)\Disk Reads/sec',
    '\PhysicalDisk(_Total)\Disk Writes/sec'

Freien Speicherplatz prüfen:

Get-Volume |
    Select-Object DriveLetter,
                  FileSystemLabel,
                  FileSystem,
                  Size,
                  SizeRemaining

Linux:

df -h

Blockgeräte anzeigen:

lsblk

I/O-Auslastung mit installiertem sysstat:

iostat -xz 1

Prozesse mit I/O-Aktivität:

pidstat -d 1
Befund Mögliche Bedeutung
hohe Latenz bei geringer Datenrate langsames oder blockiertes Storage
Warteschlange wächst dauerhaft Datenträger kann Anfragen nicht schnell genug verarbeiten
freier Speicherplatz nahezu erschöpft Dateisystem, Datenbank oder Anwendung beeinträchtigt
mehrere VMs gleichzeitig betroffen gemeinsames Storage prüfen
Problem während eines Backups konkurrierende I/O-Last
hohe I/O-Wartezeit unter Linux Prozesse warten auf Storage
RAID degradiert Leistung und Ausfallsicherheit reduziert
Snapshot wächst stark zusätzliche Storage-Belastung möglich

Allgemeine Grenzwerte dürfen nur als Orientierung verwendet werden. Ob eine Latenz problematisch ist, hängt vom Speichermedium, der Anwendung und den vereinbarten Leistungswerten ab.

9. Netzwerk untersuchen

Ein Netzwerkproblem kann aus Benutzersicht wie ein langsamer Server wirken.

Zu prüfen sind:

Windows:

Test-Connection SRV-APP01 -Count 10

TCP-Port prüfen:

Test-NetConnection SRV-APP01 -Port 443

Netzwerkadapter anzeigen:

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

Adapterstatistiken:

Get-NetAdapterStatistics

Aktive TCP-Verbindungen:

Get-NetTCPConnection |
    Group-Object State |
    Sort-Object Count -Descending

Linux:

ping -c 10 srv-app01

Route untersuchen:

traceroute srv-app01

Socketübersicht:

ss -s

Interfaceinformationen:

ip -s link

DNS-Auflösung prüfen:

dig srv-app01.example.local
Befund Mögliche Bedeutung
Paketverlust Überlastung, fehlerhafter Link oder Routingproblem
schwankende Latenz Überlastung oder instabiler Netzwerkpfad
Zugriff per IP schnell, per Name langsam DNS prüfen
nur VPN-Benutzer betroffen VPN-Gateway, Tunnel oder Internetverbindung
Fehlerzähler steigen Kabel, Port, Treiber oder Netzwerkkarte
Anwendung lokal schnell, entfernt langsam Netzwerkpfad, Proxy oder Firewall
nur große Übertragungen problematisch MTU, Bandbreite oder Paketverlust prüfen
viele Verbindungen im Wartezustand Anwendung, Netzwerk oder Porterschöpfung

Ein erfolgreicher Ping beweist nur eingeschränkt die Funktionsfähigkeit. Er prüft nicht automatisch den eigentlichen Anwendungsport oder die Antwortzeit des Dienstes.

10. DNS untersuchen

Langsame oder fehlerhafte Namensauflösung kann viele Serverdienste beeinträchtigen.

Typische Auswirkungen:

Windows:

Resolve-DnsName SRV-DB01

Konfigurierte DNS-Server:

Get-DnsClientServerAddress

DNS-Zwischenspeicher:

Get-DnsClientCache

Linux:

resolvectl status

Namensauflösung messen:

time getent hosts srv-db01.example.local

Mit dig:

dig srv-db01.example.local

Zu prüfen sind:

11. Prozesse und Dienste untersuchen

Nicht jede hohe Ressourcennutzung ist die Ursache. Der auffällige Prozess kann selbst nur auf eine andere Komponente warten.

Windows-Dienste:

Get-Service |
    Where-Object Status -eq 'Running'

Automatisch startende, aber nicht laufende Dienste:

Get-CimInstance Win32_Service |
    Where-Object {
        $_.StartMode -eq 'Auto' -and
        $_.State -ne 'Running'
    } |
    Select-Object Name, DisplayName, State, StartMode

Linux-Dienste:

systemctl --failed

Status eines Dienstes:

systemctl status nginx

Zu prüfen sind:

Ein Dienstneustart sollte erst erfolgen, nachdem relevante Messwerte und Protokolle gesichert wurden.

12. Anwendung untersuchen

Wenn nur eine Anwendung langsam ist, muss deren interner Ablauf betrachtet werden.

Mögliche Ursachen:

Zu prüfen sind:

Beispielhafte Abgrenzung:

Startseite schnell
Suchfunktion langsam
        ↓
Suchfunktion getrennt untersuchen
        ↓
Anwendungslog und Datenbankabfrage vergleichen

Nicht sofort den gesamten Server neu starten, wenn nur ein einzelner Anwendungsbereich betroffen ist.

13. Datenbank untersuchen

Datenbanken können trotz geringer CPU-Auslastung langsam reagieren.

Mögliche Ursachen:

Zu prüfen sind:

Beispielhafte Ursache-Wirkungs-Kette:

lange Datenbankabfrage
        ↓
Anwendungs-Worker wartet
        ↓
Verbindungspool wird belegt
        ↓
weitere Benutzer müssen warten
        ↓
Anwendung erscheint vollständig langsam

Änderungen an Indizes, Abfragen oder Datenbankparametern sollten nur nach Sicherung und Abstimmung mit der verantwortlichen Stelle erfolgen.

14. Hintergrundjobs prüfen

Regelmäßig auftretende Leistungseinbrüche sprechen häufig für geplante Prozesse.

Typische Verursacher:

Windows – geplante Aufgaben:

Get-ScheduledTask |
    Where-Object State -eq 'Running'

Linux – systemd-Timer:

systemctl list-timers

Cron-Konfiguration prüfen:

crontab -l

Zu vergleichen sind:

Eine zeitliche Übereinstimmung ist ein Hinweis, aber noch kein vollständiger Ursachennachweis.

15. Protokolle zeitlich vergleichen

Protokolle müssen mit dem dokumentierten Störungszeitpunkt abgeglichen werden.

Windows-Systemereignisse:

Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    StartTime = (Get-Date).AddHours(-2)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  Message

Windows-Anwendungsereignisse:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Application'
    StartTime = (Get-Date).AddHours(-2)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  Message

Linux:

journalctl --since "2 hours ago"

Fehler mit hoher Priorität:

journalctl -p err --since "2 hours ago"

Kernelmeldungen:

journalctl -k --since "2 hours ago"

Zu suchen sind:

Ein einzelner protokollierter Fehler beweist nicht automatisch die Ursache. Zeitliche Übereinstimmung, technische Wirkung und Reproduzierbarkeit müssen zusammenpassen.

16. Virtuelle Maschinen untersuchen

Bei einer virtuellen Maschine müssen Gast und Hypervisor getrennt betrachtet werden.

Im Gast zu prüfen:

Auf dem Hypervisor zu prüfen:

Typische Konstellation:

VM zeigt geringe CPU-Auslastung
        ↓
Anwendung ist trotzdem langsam
        ↓
Hypervisor prüfen
        ↓
VM erhält CPU-Zeit verzögert

Mehr virtuelle CPUs verbessern die Leistung nicht automatisch. Zu viele vCPUs können das Scheduling erschweren und die Wartezeit erhöhen.

17. Container untersuchen

Bei Containern müssen zusätzlich Limits und der Hostzustand berücksichtigt werden.

Zu prüfen sind:

Docker:

docker stats

Laufende Container:

docker ps

Containerzustand:

docker inspect CONTAINERNAME

Protokollausgabe:

docker logs --since 2h CONTAINERNAME

Ressourcenlimits anzeigen:

docker inspect CONTAINERNAME \
    --format 'Memory={{.HostConfig.Memory}} NanoCPUs={{.HostConfig.NanoCpus}}'

Ein Container kann langsam sein, obwohl der Host noch freie Ressourcen besitzt, wenn für den Container selbst ein niedriges Limit festgelegt wurde.

18. Externe Abhängigkeiten prüfen

Eine Anwendung kann auf andere Systeme warten, obwohl der eigene Server unauffällig ist.

Mögliche Abhängigkeiten:

Zu prüfen sind:

Beispiel:

Webserver reagiert lokal schnell
        ↓
Anmeldung dauert 20 Sekunden
        ↓
Anwendung wartet auf Verzeichnisdienst
        ↓
DNS- oder LDAP-Verbindung untersuchen

19. Hardwarezustand prüfen

Bei physischen Servern müssen auch Hardwareprobleme berücksichtigt werden.

Mögliche Ursachen:

Zu prüfen sind:

Linux – vorhandene Hardwarewarnungen:

dmesg --level=err,warn

SMART-Werte dürfen nur mit passenden Werkzeugen und unter Berücksichtigung des verwendeten Controllers geprüft werden.

20. Letzte Änderungen untersuchen

Leistungsprobleme treten häufig nach einer Veränderung auf.

Mögliche Änderungen:

Zu dokumentieren sind:

Änderung Zeitpunkt Verantwortlich Mögliche Auswirkung
Anwendungsupdate 08:30 Uhr Anwendungsteam neue Abfrage oder Fehler
Backupzeit geändert 09:00 Uhr Betriebsteam höhere Storage-Last
neue VM gestartet 09:10 Uhr Virtualisierungsteam Hostressourcen
GPO geändert Vortag Administration Dienst- oder Sicherheitseinstellung

Die zeitliche Nähe einer Änderung zum Fehler ist ein wichtiges Indiz, aber kein alleiniger Beweis.

21. Baseline und Vergleichswerte verwenden

Ohne Vergleichswerte lässt sich schwer beurteilen, ob ein Messwert ungewöhnlich ist.

Eine Baseline kann enthalten:

Beispiel:

Messwert Normalzustand Störungszeitpunkt
Antwortzeit 1,5 s 15 s
CPU 35 % 42 %
verfügbarer RAM 8 GB 7,5 GB
Storage-Latenz 4 ms 85 ms
aktive Benutzer 120 125

In diesem Beispiel spricht der Vergleich stärker für ein Storage-Problem als für CPU-, RAM- oder Benutzerlast.

22. Korrelation und Ursache unterscheiden

Zwei gleichzeitig auftretende Ereignisse müssen nicht ursächlich zusammenhängen.

Beispiel:

CPU-Auslastung steigt
Anwendung wird langsam

Mögliche Interpretationen:

  1. Die hohe CPU-Auslastung verursacht die Verzögerung.
  2. Die langsame externe Abhängigkeit führt zu zusätzlichen Wiederholungen und erhöht dadurch die CPU-Auslastung.
  3. Ein dritter Prozess verursacht gleichzeitig beide Effekte.
  4. Die CPU-Auslastung ist normal und nicht relevant.

Ein Ursachennachweis wird stärker, wenn:

23. Kontrollierte Maßnahmen durchführen

Nach der Analyse sollte genau eine passende Maßnahme durchgeführt werden.

Mögliche Maßnahmen:

Vor jeder Maßnahme:

Danach:

24. Warum ein Neustart nicht die erste Maßnahme sein sollte

Ein Neustart kann:

Er kann aber auch:

Ein Neustart ist daher keine vollständige Ursachenanalyse.

Falls ein Neustart erforderlich ist, sollten vorher mindestens folgende Informationen gesichert werden:

25. Nachkontrolle

Nach einer Maßnahme muss nicht nur die Ressourcenauslastung, sondern auch die eigentliche Funktion geprüft werden.

Zu kontrollieren sind:

Beispiel:

Vorher:
Antwortzeit 15 Sekunden
Storage-Latenz 85 ms

Maßnahme:
konkurrierenden Backupjob beendet

Nachher:
Antwortzeit 1,7 Sekunden
Storage-Latenz 5 ms

Erst der Vergleich vor und nach der Maßnahme zeigt, ob die vermutete Ursache tatsächlich zum Problem beigetragen hat.

26. Dokumentation

Die Abschlussdokumentation sollte enthalten:

Beispiel:

Symptom:
Webanwendung benötigte statt 1–2 Sekunden etwa 15 Sekunden.

Ursache:
Der gleichzeitig laufende Backupjob verursachte eine hohe
Latenz auf dem gemeinsam genutzten Storage.

Maßnahme:
Backupjob kontrolliert beendet und Zeitplan angepasst.

Ergebnis:
Antwortzeit wieder unter 2 Sekunden.
Storage-Latenz wieder im üblichen Bereich.

Vorbeugung:
Monitoring für Storage-Latenz eingerichtet und Backupfenster geändert.

27. Entscheidungsbaum

Server oder Dienst langsam
        ↓
Ist der gesamte Server betroffen?
        ├── Ja
        │   ↓
        │   CPU, RAM, Storage, Netzwerk und Hypervisor prüfen
        │
        └── Nein
            ↓
        Nur eine Anwendung betroffen?
                ├── Ja
                │   ↓
                │   Anwendung, Datenbank und Abhängigkeiten prüfen
                │
                └── Nein
                    ↓
                Gemeinsame Komponente der betroffenen Dienste suchen

Erweiterte Eingrenzung:

Problem nur aus der Ferne?
        ├── Ja → Netzwerk, DNS, VPN, Firewall oder Proxy
        └── Nein
             ↓
Problem nur zu festen Zeiten?
        ├── Ja → Backup, Scan, Wartung oder geplanter Job
        └── Nein
             ↓
Mehrere VMs auf einem Host betroffen?
        ├── Ja → Hypervisor und gemeinsames Storage
        └── Nein → Gastbetriebssystem und Anwendung

28. Häufige Fehlerbilder

Fehlerbild Wahrscheinlicher Prüfbereich
Server reagiert nach Neustart wieder schnell Speicherleck, blockierter Prozess oder wartende Ressource
Problem kehrt regelmäßig zurück Ursache wurde nicht behoben oder geplanter Job
CPU dauerhaft hoch Prozess, Thread, Malware, Scan oder zu geringe Leistung
CPU niedrig, Server trotzdem langsam Storage, Netzwerk, Locks oder externe Abhängigkeit
RAM nahezu vollständig belegt Paging und Speicherdruck prüfen
Swap-Nutzung steigt dauerhaft Arbeitsspeicherengpass
Datenträger dauerhaft ausgelastet Backup, Datenbank, Scan oder langsames Storage
nur Datenbankfunktionen langsam Abfragen, Locks, Indizes oder Storage
nur Anmeldung langsam DNS, Verzeichnisdienst, GPO oder Benutzerprofil
nur Webzugriff langsam Webserver, TLS, Proxy, Anwendung oder Datenbank
nur bestimmte Uhrzeit betroffen geplanter Job oder Lastspitze
mehrere VMs betroffen Host, Netzwerk oder gemeinsames Storage
nur eine VM betroffen Gastbetriebssystem, Limits oder VM-Konfiguration
Zugriff per IP schnell DNS-Auflösung prüfen
lokal schnell, entfernt langsam Netzwerkpfad prüfen
Anwendung wartet auf Timeout externe Abhängigkeit untersuchen
Leistung nimmt über Tage ab Speicherleck, Datenwachstum oder Warteschlange

29. Typische Prüfungsfragen

Warum ist die Aussage „der Server ist langsam“ für die Fehleranalyse nicht ausreichend?

Antwort anzeigen

Die Aussage beschreibt nur ein allgemeines Symptom. Es fehlen unter anderem der betroffene Dienst, die gemessene Antwortzeit, der Normalzustand, der Zeitpunkt, der Umfang und mögliche Änderungen.

Warum beweist eine hohe CPU-Auslastung noch nicht die Fehlerursache?

Antwort anzeigen

Die Auslastung kann für die vorhandene Arbeitslast normal sein oder erst als Folge eines anderen Problems entstehen. Für einen Ursachennachweis müssen zeitlicher Zusammenhang, technische Wirkung und das Ergebnis einer kontrollierten Maßnahme geprüft werden.

Warum kann ein Server trotz niedriger CPU-Auslastung langsam sein?

Antwort anzeigen

Prozesse können auf Storage, Netzwerk, Datenbanksperren, externe Dienste oder andere Ressourcen warten. Während dieser Wartezeit wird nur wenig CPU-Leistung benötigt.

Warum ist vollständig belegter Arbeitsspeicher nicht automatisch ein Fehler?

Antwort anzeigen

Betriebssysteme verwenden freien Arbeitsspeicher unter anderem für Caches. Entscheidend sind Speicherdruck, Paging beziehungsweise Swapping und die zeitliche Entwicklung.

Warum sollten vor einem Neustart Messwerte gesichert werden?

Antwort anzeigen

Ein Neustart beendet Prozesse, leert Warteschlangen und verändert den Systemzustand. Dadurch können wichtige Hinweise auf die eigentliche Ursache verloren gehen.

Was bedeutet eine hohe Datenträgerlatenz?

Antwort anzeigen

Lese- oder Schreibanforderungen benötigen ungewöhnlich lange. Anwendungen können dadurch warten, obwohl CPU und Arbeitsspeicher unauffällig sind.

Warum reicht ein erfolgreicher Ping nicht als Nachweis für einen funktionierenden Dienst?

Antwort anzeigen

Ping prüft ICMP-Erreichbarkeit. Der eigentliche Anwendungsport, die Authentifizierung, die Verarbeitung im Dienst und dessen Backend werden dadurch nicht geprüft.

Warum müssen bei einer VM auch Hypervisorwerte geprüft werden?

Antwort anzeigen

Der Gast kann nur die ihm bereitgestellten Ressourcen sehen. Wartezeiten, Überbelegung oder Storage-Probleme auf dem Host sind im Gast möglicherweise nicht eindeutig erkennbar.

Warum sollte nach einer Maßnahme erneut gemessen werden?

Antwort anzeigen

Nur der Vergleich von Sollwert, Ausgangswert und neuem Messwert zeigt, ob die Maßnahme das eigentliche Problem behoben hat.

30. Prüfungsfallen

31. Checkliste „Server ist langsam“

32. Schnellreferenz

Beobachtung Nächster Prüfbereich
gesamte Maschine langsam CPU, RAM, Storage, Hypervisor
nur eine Anwendung langsam Anwendung, Datenbank, Abhängigkeiten
CPU dauerhaft hoch Prozess- und Threadauslastung
nur ein Kern ausgelastet Single-Thread-Engpass
CPU niedrig, Antwortzeit hoch Storage, Netzwerk, Locks
starke Paging-Aktivität Arbeitsspeicher
hohe I/O-Wartezeit Datenträger oder Storage
wenig freier Speicherplatz Dateisystem und Datenwachstum
lokale Nutzung schnell Netzwerk, DNS, Proxy oder Firewall
Zugriff per IP schnell DNS
Paketverlust vorhanden Netzwerkpfad
nur bestimmte Uhrzeit betroffen geplante Aufgaben
Problem während Backup Storage- und Netzwerkbelastung
mehrere VMs betroffen Hypervisor und gemeinsames Storage
nur eine VM betroffen Gast, Limits und virtuelle Hardware
Container wird gedrosselt CPU- und Speicherlimit
bestimmte Datenbankabfrage langsam Locks, Indizes und Ausführungsplan
Anmeldung langsam DNS, AD, GPO oder Profil
Anwendung wartet auf Timeout externe Abhängigkeit
nach Neustart vorübergehend schnell Speicherleck, Warteschlange oder blockierter Prozess
Hardwarewarnung vorhanden Herstellerdiagnose und Austauschplanung

Merksatz

Ein langsamer Server wird nicht durch Vermutungen, sondern durch Eingrenzung und Messwerte untersucht. Entscheidend ist, ob CPU, Arbeitsspeicher, Storage, Netzwerk, Anwendung, Datenbank, Hypervisor oder eine externe Abhängigkeit den tatsächlichen Engpass verursacht. Vor einer Änderung wird der Ausgangszustand gesichert, anschließend wird genau eine kontrollierte Maßnahme durchgeführt und ihre Wirkung erneut gemessen.

Quellen und weiterführende Dokumentation

7.9 Ping funktioniert, Anwendung nicht

Ein Server antwortet auf einen Ping, die eigentliche Anwendung ist jedoch nicht erreichbar oder funktioniert nicht vollständig.

Dieses Fehlerbild entsteht häufig, weil ein erfolgreicher Ping fälschlicherweise als Nachweis für die Funktionsfähigkeit des gesamten Dienstes interpretiert wird. Ping prüft jedoch nur einen begrenzten Teil der Kommunikationskette.

7.9.1 Typisches Fehlerbild

Mögliche Meldungen und Beobachtungen:

Die Diagnose muss deshalb über ICMP hinausgehen und den tatsächlichen Anwendungsweg prüfen.

7.9.2 Diagnoseziel

Ziel ist es, eindeutig festzustellen:

Ein möglicher Fehlerbereich darf erst dann als Ursache gelten, wenn er durch ein reproduzierbares Prüfergebnis, ein Protokoll oder einen Paketmitschnitt bestätigt wurde.

7.9.3 Kommunikationskette der Anwendung

Eine typische Anwendungsverbindung kann mehrere voneinander unabhängige Prüfebenen enthalten:

  1. Anwendungskonfiguration
  2. Namensauflösung
  3. Auswahl von IPv4 oder IPv6
  4. lokales Routing
  5. VPN oder Proxy
  6. Clientfirewall
  7. Netzwerkfirewall oder ACL
  8. NAT oder Portweiterleitung
  9. Load Balancer oder Reverse Proxy
  10. TCP- oder UDP-Kommunikation
  11. TLS-Handshake
  12. Anwendungsprotokoll
  13. Authentifizierung
  14. Autorisierung
  15. Backenddienste
  16. vollständiger Benutzerablauf

Ein Fehler auf einer späteren Ebene kann auftreten, obwohl alle vorherigen Ebenen funktionieren.

Beispiele:

7.9.4 Was Ping tatsächlich prüft

Ping verwendet normalerweise ICMP-Echo-Anfragen und ICMP-Echo-Antworten.

Ein erfolgreicher Ping bestätigt für den konkreten Testzeitpunkt grundsätzlich:

Ping kann zusätzlich Hinweise liefern auf:

Das antwortende System muss jedoch nicht zwingend der erwartete Anwendungsserver sein. Bei virtuellen IP-Adressen, Load Balancern, Firewalls oder falsch aufgelösten Namen kann ein anderes System antworten.

7.9.5 Was Ping nicht beweist

Ein erfolgreicher Ping beweist nicht:

Ebenso beweist ein fehlgeschlagener Ping nicht automatisch, dass der Server oder die Anwendung ausgefallen ist. ICMP kann absichtlich blockiert, begrenzt oder niedriger priorisiert werden, während der eigentliche Anwendungsdienst weiterhin erreichbar ist.

7.9.6 Fehlerumfang bestimmen

Vor technischen Änderungen muss der Umfang des Fehlers festgestellt werden.

Zu prüfen sind:

Geeignete Vergleichstests:

Vergleich Mögliche Eingrenzung
gleicher Benutzer an anderem Client clientbezogener Fehler
anderer Benutzer am gleichen Client benutzerbezogener Fehler
gleicher Client in anderem Netz Netzwerkpfad oder standortbezogene Regel
Zugriff mit und ohne VPN VPN-Route, DNS, Proxy, Firewall oder MTU
IPv4 und IPv6 getrennt adressfamilienbezogener Fehler
direkter Anwendungstest und Zugriff über Proxy Proxy- oder Reverse-Proxy-Fehler
lokaler Test auf dem Server und entfernter Test Dienstfehler oder externer Netzwerkpfad
einfacher Endpunkt und vollständiger Benutzerablauf Backend- oder Anwendungsfehler

Kreuztests dürfen nur kontrolliert durchgeführt werden. Produktive Zugangsdaten oder vertrauliche Daten dürfen nicht ungeschützt in Diagnoseausgaben übernommen werden.

7.9.7 Ausgangszustand sichern

Vor einem Neustart oder einer Konfigurationsänderung sollten mindestens folgende Informationen gesichert werden:

Ein vorschneller Neustart kann flüchtige Hinweise beseitigen, beispielsweise:

Änderungen dürfen erst nach Sicherung des Ausgangszustands erfolgen.

7.9.8 Tatsächliches Ziel der Anwendung bestimmen

Vor jedem Port- oder Protokolltest muss geklärt werden, welches Ziel die Anwendung wirklich anspricht.

Zu erfassen sind:

Anwendung:
Benutzerfunktion:
Servername:
Vollständiger DNS-Name:
Verwendete IP-Adresse:
IPv4 oder IPv6:
Transportprotokoll:
Port:
Anwendungsprotokoll:
URL oder Ressourcenpfad:
Proxy:
VPN:
Load Balancer oder Reverse Proxy:
Fehlerzeitpunkt:

Die Anwendungskonfiguration kann vom vermuteten Standard abweichen.

Mögliche Einflussquellen:

Besonders wichtig:

Die im Fehlerzeitpunkt verwendete Zieladresse sollte aus der Anwendung, einem Verbindungsprotokoll oder einem Paketmitschnitt bestätigt werden.

7.9.9 Namensauflösung prüfen

Windows:

Resolve-DnsName -Name <Servername> -Type A
Resolve-DnsName -Name <Servername> -Type AAAA

Linux:

getent ahosts <Servername>
dig <Servername> A
dig <Servername> AAAA

macOS:

dscacheutil -q host -a name <Servername>
dig <Servername> A
dig <Servername> AAAA

Zu vergleichen sind:

Ein erfolgreicher Ping auf einen Namen beweist nur, dass für diesen Ping-Aufruf eine Namensauflösung möglich war. Die Antwort kann aus DNS, einer Hosts-Datei oder einem anderen lokalen Namensauflösungsverfahren stammen.

DNS-Caches sollten nicht als erste Maßnahme gelöscht werden. Zuerst muss dokumentiert werden, welche Adresse aktuell verwendet wird und warum sie falsch sein könnte.

7.9.10 TCP-Port gezielt prüfen

Windows:

Test-NetConnection `
  -ComputerName <Servername> `
  -Port <Port> `
  -InformationLevel Detailed

Wichtige Felder:

ComputerName
RemoteAddress
RemotePort
InterfaceAlias
SourceAddress
TcpTestSucceeded

Linux und macOS:

nc -vz <Servername> <Port>

Ein erfolgreicher TCP-Test beweist:

Er beweist nicht:

7.9.11 TCP-Fehler richtig interpretieren

Ergebnis Bedeutung Nächster Nachweis
TcpTestSucceeded : True TCP-Verbindungsaufbau war möglich Anwendungsprotokoll und TLS prüfen
Connection refused Ziel oder zwischengeschaltetes System hat die Verbindung aktiv abgelehnt Listener, Port und Serverprotokoll prüfen
Verbindungs-Timeout Keine rechtzeitige TCP-Antwort Firewall, Rückweg, Routing, Überlastung oder falsche Adresse untersuchen
Name nicht gefunden Zielname konnte nicht aufgelöst werden Namensauflösung prüfen
Verbindung wird sofort getrennt Dienst lehnt Sitzung ab oder falsches Protokoll wird verwendet Dienst- und Anwendungsprotokoll prüfen
Verbindung beginnt, bleibt dann hängen Anwendung, TLS, Backend, Paketverlust oder Pfad-MTU möglich Protokolle und Paketverlauf untersuchen

Ein Timeout beweist nicht automatisch eine Firewallblockierung. Auch ein falscher Rückweg, ein überlasteter Dienst, ein fehlerhafter Load Balancer oder eine falsche IP-Adresse können zu einem Timeout führen.

7.9.12 Anwendungsprotokoll statt nur Port prüfen

Der Test muss zum tatsächlichen Dienst passen.

Dienst Geeigneter Funktionstest
HTTP oder HTTPS curl -v mit vollständiger URL
SSH ssh -vvv <Benutzer>@<Servername>
DNS Resolve-DnsName oder dig gegen den vorgesehenen DNS-Server
SMB Zugriff auf die konkrete Freigabe testen
RDP kontrollierter Verbindungsversuch mit dem RDP-Client
Datenbank nativen Datenbankclient mit einer sicheren Leseabfrage verwenden
API vorgesehenen Endpunkt, Methode, Header und Authentifizierung prüfen
herstellerspezifischer Dienst Diagnoseclient oder dokumentierten Protokolltest des Herstellers verwenden

Ein erfolgreicher Test auf TCP 3389 beweist beispielsweise nur, dass der Port erreichbar ist. Er beweist noch keine funktionierende RDP-Anmeldung oder Sitzung.

curl ist für HTTP-, HTTPS- und weitere von curl unterstützte Protokolle geeignet. Ein beliebiger TCP-Dienst darf nicht automatisch mit einer HTTP-Anfrage getestet werden.

7.9.13 HTTP und HTTPS prüfen

curl -v --connect-timeout 5 \
  "https://<Servername>:<Port>/<Pfad>"

Die Ausgabe wird schrittweise ausgewertet:

  1. Welche IP-Adresse wird verwendet?
  2. Wird eine TCP-Verbindung aufgebaut?
  3. Beginnt der TLS-Handshake?
  4. Welches Zertifikat wird präsentiert?
  5. Wird die Zertifikatsprüfung erfolgreich abgeschlossen?
  6. Welche HTTP-Anfrage wird gesendet?
  7. Welcher HTTP-Statuscode wird empfangen?
  8. Erfolgt eine Umleitung?
  9. Antwortet ein Reverse Proxy oder der erwartete Anwendungsserver?
  10. Wird eine Anwendungsfehlermeldung zurückgegeben?

Wichtige HTTP-Ergebnisse:

Status Einordnung
2xx Anfrage wurde auf HTTP-Ebene erfolgreich verarbeitet
3xx Umleitung; Ziel im Location-Header prüfen
401 Anwendung erreicht, Authentifizierung erforderlich oder fehlgeschlagen
403 Anwendung erreicht, Zugriff wird verweigert
404 Dienst antwortet, angeforderter Pfad oder virtuelle Zuordnung fehlt
407 Proxy verlangt eine Authentifizierung
5xx Server, Gateway oder Backend meldet einen Fehler

Auch eine gültige HTTP-Fehlerantwort beweist, dass bereits mehrere Prüfebenen erfolgreich durchlaufen wurden. Sie beweist jedoch nicht, dass die benötigte Benutzerfunktion arbeitet.

7.9.14 Bestimmte IP-Adresse mit richtigem Hostnamen testen

Bei HTTPS sollte nicht einfach die IP-Adresse in die URL eingesetzt werden. Dadurch können sich SNI, Host-Header und Zertifikatsprüfung verändern.

Mit curl kann ein Servername kontrolliert einer bestimmten Adresse zugeordnet werden:

curl -v \
  --resolve <Servername>:<Port>:<IP-Adresse> \
  "https://<Servername>:<Port>/<Pfad>"

Damit bleiben der Servername in der URL, der HTTP-Host und die TLS-SNI-Angabe erhalten, während die Verbindung gezielt zur angegebenen IP-Adresse aufgebaut wird.

Dieser Test ist hilfreich bei:

Das Ergebnis gilt nur für die getestete Kombination aus Name, Adresse, Port und Pfad.

7.9.15 TLS kurz prüfen

Für HTTPS oder andere TLS-Dienste:

openssl s_client \
  -connect <Servername>:<Port> \
  -servername <Servername> \
  -verify_hostname <Servername> \
  -verify_return_error

Zu prüfen sind:

Die Vertrauensstellung von OpenSSL kann sich vom Zertifikatsspeicher der eigentlichen Anwendung unterscheiden. Ein erfolgreicher OpenSSL-Test beweist deshalb nicht automatisch, dass jeder Client dem Zertifikat vertraut.

Zertifikatsprüfungen dürfen nicht dauerhaft mit Optionen wie -k oder --insecure umgangen werden. Die ausführliche TLS-Diagnose erfolgt auf Seite 7.14.

7.9.16 Proxy und anwendungsspezifischen Verbindungsweg prüfen

Eine Anwendung kann einen Proxy verwenden, obwohl ein direkter Porttest erfolgreich ist. Umgekehrt kann ein direkter Test scheitern, während der Zugriff ausschließlich über einen Proxy vorgesehen ist.

Windows – WinHTTP-Konfiguration:

netsh winhttp show proxy

Umgebungsvariablen in PowerShell:

Get-ChildItem Env: |
  Where-Object Name -Match '^(HTTP|HTTPS|NO)_PROXY$'

Linux:

env | grep -iE '^(http|https|no)_proxy='

macOS:

scutil --proxy

env | grep -iE '^(http|https|no)_proxy='

Zusätzlich zu prüfen:

netsh winhttp show proxy zeigt nur die WinHTTP-Konfiguration. Daraus darf nicht automatisch auf die Konfiguration jedes Browsers oder jeder Anwendung geschlossen werden.

7.9.17 Listener auf dem Server prüfen

Wenn der TCP-Port von außen nicht erreichbar ist, muss geprüft werden, ob der Dienst auf dem Server tatsächlich lauscht.

Windows:

Get-NetTCPConnection `
  -LocalPort <Port> `
  -State Listen |
  Select-Object LocalAddress, LocalPort, State, OwningProcess

Zugehörigen Prozess prüfen:

Get-Process -Id <PID>

Linux:

sudo ss -lntp

macOS:

sudo lsof -nP \
  -iTCP:<Port> \
  -sTCP:LISTEN

Zu prüfen sind:

Typische Bindungsbefunde:

Bindungsadresse Bedeutung
127.0.0.1 nur lokale IPv4-Verbindungen
::1 nur lokale IPv6-Verbindungen
konkrete Serveradresse nur über diese Adresse beziehungsweise Schnittstelle
0.0.0.0 alle lokalen IPv4-Adressen
[::] alle lokalen IPv6-Adressen; zusätzliches IPv4-Verhalten ist systemabhängig

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

7.9.18 Lokalen und entfernten Zugriff vergleichen

Auf dem Server kann zunächst ein lokaler Anwendungstest durchgeführt werden:

curl -v \
  "http://127.0.0.1:<Port>/<Pfad>"

Bei einem namensabhängigen HTTPS-Dienst:

curl -v \
  --resolve <Servername>:<Port>:127.0.0.1 \
  "https://<Servername>:<Port>/<Pfad>"

Der lokale Test muss an die tatsächliche Listeneradresse angepasst werden. Ein Dienst, der nur an eine bestimmte Serveradresse gebunden ist, muss über diese Adresse geprüft werden.

Lokaler Test Entfernter Test Wahrscheinlicher Bereich
schlägt fehl schlägt fehl Dienst, Listener, Konfiguration oder Backend
funktioniert TCP-Port schlägt fehl Listenerbindung, Hostfirewall oder Netzwerkpfad
funktioniert TCP-Port funktioniert, Protokoll schlägt fehl TLS, Reverse Proxy, virtueller Host oder Anwendung
funktioniert curl vom Client funktioniert Problem im eigentlichen Client oder Benutzerkontext
funktioniert nur über Loopback entfernt nicht erreichbar falsche Listenerbindung wahrscheinlich
funktioniert über eine Serveradresse über andere Adresse nicht Schnittstelle, Routing, DNS oder Firewallregel

Ein lokaler Erfolg beweist nicht, dass die vollständige externe Zugriffskette funktioniert.

7.9.19 Firewall, ACL, NAT und Load Balancer prüfen

ICMP und Anwendungsverkehr können durch unterschiedliche Regeln behandelt werden.

Zu prüfen sind:

Mögliche Konstellationen:

Firewalls dürfen nicht pauschal deaktiviert werden. Stattdessen müssen Protokoll, Quelladresse, Zieladresse, Port, Richtung und Treffer der konkreten Regel geprüft werden.

7.9.20 Authentifizierung und Autorisierung abgrenzen

Wenn eine Anwendung eine Anmeldemaske, einen HTTP-Statuscode oder eine konkrete Berechtigungsfehlermeldung zurückgibt, wurde die Anwendungsebene bereits erreicht.

Zu unterscheiden sind:

Geeignete Kreuztests:

Test Erkenntnis
anderer Benutzer am selben Client benutzerbezogener Fehler möglich
gleicher Benutzer an anderem Client clientbezogener Fehler möglich
kontrolliertes Testkonto Konto- oder Rechteproblem eingrenzen
anonymer oder öffentlicher Endpunkt Netzwerk und Anwendung ohne Benutzeranmeldung prüfen
lokales Anwendungskonto Abhängigkeit vom Verzeichnisdienst untersuchen

Kontosperren und produktive Benutzerkonten müssen berücksichtigt werden. Die Domänenanmeldung wird ausführlich auf Seite 7.10 behandelt.

7.9.21 Anwendungsabhängigkeiten untersuchen

Ein erreichbarer Frontend-Port bedeutet nicht, dass alle Backenddienste funktionieren.

Mögliche Abhängigkeiten:

Typische Befunde:

Anwendungs-, Proxy- und Backendprotokolle müssen anhand des gleichen Fehlerzeitpunkts korreliert werden.

Container-Neustartschleifen werden auf Seite 7.12 und volle Datenträger auf Seite 7.13 ausführlich behandelt.

7.9.22 UDP-Dienste korrekt prüfen

UDP besitzt keinen TCP-ähnlichen Verbindungsaufbau. Ein allgemeiner UDP-Porttest kann daher nicht sicher beweisen, dass der Dienst funktioniert.

Für UDP muss eine gültige Anfrage des tatsächlichen Anwendungsprotokolls gesendet und die Antwort geprüft werden.

DNS-Test unter Windows:

Resolve-DnsName `
  -Name <Abzufragender-Name> `
  -Server <DNS-Server>

DNS-Test unter Linux oder macOS:

dig @<DNS-Server> <Abzufragender-Name> A

Ein fehlender UDP-Fehler beweist nicht, dass:

Bei UDP-Diensten sind Anwendungsprotokoll, Serverprotokoll und gegebenenfalls ein kontrollierter Paketmitschnitt besonders wichtig.

7.9.23 IPv4 und IPv6 getrennt prüfen

Ein Name kann gleichzeitig A- und AAAA-Einträge besitzen. Ping und Anwendung können unterschiedliche Adressfamilien auswählen.

Mit curl getrennt testen:

curl -4 -v \
  "https://<Servername>:<Port>/<Pfad>"

curl -6 -v \
  "https://<Servername>:<Port>/<Pfad>"

Zu prüfen sind:

Wenn ausschließlich IPv6 fehlschlägt, muss der IPv6-Pfad oder der AAAA-Eintrag korrigiert werden. IPv6 sollte nicht ohne Ursachenanalyse dauerhaft deaktiviert werden.

7.9.24 Paketgröße und Übertragungsverhalten berücksichtigen

Ein kleiner ICMP-Ping kann funktionieren, während größere Anwendungsdaten hängen bleiben.

Mögliche Ursachen:

Typische Hinweise:

Ein erfolgreicher Standard-Ping darf deshalb nicht als vollständiger Nachweis eines fehlerfreien Datenpfads verwendet werden.

7.9.25 Paketmitschnitt kontrolliert einsetzen

Linux oder macOS:

sudo tcpdump -ni <Interface> \
  host <IP-Adresse> and port <Port>

Alternativ kann Wireshark mit einem passenden Erfassungsfilter verwendet werden.

Typische Beobachtungen:

Beobachtung Einordnung
wiederholte SYN-Pakete ohne Antwort keine TCP-Antwort; Pfad, Regel oder Ziel prüfen
SYN wird mit RST beantwortet Port geschlossen oder Verbindung aktiv abgelehnt
SYN, SYN-ACK und ACK sichtbar TCP-Verbindung wurde aufgebaut
TCP-Verbindung wird danach sofort geschlossen Dienst oder Protokoll lehnt Verbindung ab
TLS ClientHello ohne passende Fortsetzung TLS-Pfad, Server oder Inspektion prüfen
TLS-Alert konkrete TLS-Ursache auswerten
viele Wiederholungen Paketverlust, Überlastung oder fehlerhafter Pfad möglich
Antwort verlässt den Server, erreicht Client aber nicht Rückweg oder zwischengeschaltete Regel prüfen

Ein Paketmitschnitt beweist nur, was an der jeweiligen Erfassungsstelle sichtbar ist. Bei komplexen Pfaden können Mitschnitte auf Client, Server und einem zwischengeschalteten System erforderlich sein.

Paketmitschnitte dürfen nur mit entsprechender Berechtigung erstellt und müssen datenschutzgerecht gespeichert werden.

7.9.26 Systematischer Diagnoseablauf

  1. Fehler aufnehmen
    Anwendung, Benutzer, Client, Zeitpunkt, Meldung und ursprüngliche Benutzerfunktion dokumentieren.

  2. Umfang bestimmen
    Einen Benutzer, einen Client, ein Netz oder alle Benutzer unterscheiden.

  3. Exaktes Ziel bestimmen
    Servername, Adresse, Port, Protokoll, Pfad und Verbindungsweg erfassen.

  4. Namensauflösung prüfen
    A- und AAAA-Antworten sowie tatsächlich verwendete Adresse vergleichen.

  5. Ping korrekt bewerten
    Nur ICMP-Erreichbarkeit als bestätigt betrachten.

  6. Transportprotokoll bestimmen
    TCP und UDP unterscheiden.

  7. TCP-Port oder UDP-Anwendung prüfen
    Einen zum tatsächlichen Protokoll passenden Test verwenden.

  8. Listener kontrollieren
    Port, Prozess und Bindungsadresse auf dem Server prüfen.

  9. Lokalen Anwendungstest durchführen
    Dienst auf dem Server über den vorgesehenen Namen, Port und Pfad testen.

  10. Externen Anwendungstest durchführen
    Denselben Dienst vom betroffenen Client aus prüfen.

  11. TLS untersuchen
    SNI, Zertifikat, Vertrauenskette und Protokollkompatibilität prüfen.

  12. Proxy und VPN berücksichtigen
    Tatsächlichen Verbindungsweg der Anwendung nachvollziehen.

  13. Anwendungsantwort auswerten
    Statuscode, Protokollmeldung, Umleitung oder Authentifizierungsfehler bestimmen.

  14. Abhängigkeiten prüfen
    Datenbank, Identitätsdienst, API, Speicher oder andere Backends untersuchen.

  15. Protokolle korrelieren
    Client-, Server-, Proxy- und Anwendungsprotokolle auf denselben Zeitraum begrenzen.

  16. Bei Bedarf Paketverlauf erfassen
    SYN, RST, TLS-Alert, Wiederholungen und Rückweg untersuchen.

  17. Hypothese formulieren
    Erwartetes Prüfergebnis und möglichen Gegenbeweis festlegen.

  18. Eine kontrollierte Änderung durchführen
    Risiko, Rückweg und Erfolgskriterium dokumentieren.

  19. Vollständige Funktion prüfen
    Nicht nur Ping oder Port, sondern den ursprünglichen Benutzerablauf testen.

  20. Nachkontrolle durchführen
    Protokolle, Überwachung und andere Benutzerfunktionen prüfen.

7.9.27 Befundmatrix

Befund Mögliche Erklärung Nächster Nachweis
Ping auf IP funktioniert, Name nicht Namensauflösungsproblem A-, AAAA-, Hosts- und Resolverdaten prüfen
Ping auf Name verwendet falsche Adresse veralteter oder falscher Namenseintrag autoritative und clientseitige Antwort vergleichen
Ping funktioniert, TCP-Port hat Timeout Portverkehr wird verworfen oder Antwort fehlt Firewall, Routing und Paketverlauf prüfen
Ping funktioniert, TCP-Port wird abgelehnt kein Listener oder aktive Ablehnung Listener und Prozess auf dem Server prüfen
TCP-Port funktioniert, Verbindung wird sofort geschlossen falsches Protokoll oder Dienst lehnt Sitzung ab Dienstprotokoll und Serverlogs prüfen
TCP funktioniert, TLS schlägt fehl Zertifikat, SNI, TLS-Version oder Inspektion curl -v oder openssl s_client auswerten
TLS funktioniert, HTTP 401 Authentifizierung erforderlich oder fehlerhaft Benutzer-, Token- oder Identitätsanbieter prüfen
TLS funktioniert, HTTP 403 fehlende Autorisierung oder Richtlinie Rollen und Zugriffsrichtlinie prüfen
HTTP 404 falscher Pfad oder virtuelle Zuordnung URL, Host-Header und Proxyroute prüfen
HTTP 407 Proxy-Authentifizierung erforderlich Proxyweg und Benutzerkontext prüfen
HTTP 502 Gateway erreicht Backend nicht korrekt Reverse-Proxy- und Backendprotokolle prüfen
HTTP 503 Dienst vorübergehend nicht verfügbar Healthcheck, Kapazität und Abhängigkeiten prüfen
lokal funktioniert, entfernt nicht Bindung, Hostfirewall oder Netzwerkpfad Listeneradresse und Regeln vergleichen
curl funktioniert, Anwendung nicht anwendungsspezifische Konfiguration Proxy, Cache, Zertifikatsspeicher und Benutzerkontext prüfen
nur ein Client betroffen lokaler Clientfehler anderen Client und gleichen Benutzer testen
nur ein Benutzer betroffen Konto, Profil, Rechte oder Sitzung anderes Konto am gleichen Client testen
nur über VPN betroffen Route, DNS, MTU oder VPN-Regel mit und ohne VPN vergleichen
nur IPv6 betroffen AAAA-, IPv6-Routing- oder Firewallfehler curl -4 und curl -6 vergleichen
kleine Anfragen funktionieren MTU, Paketverlust oder Kapazität möglich Paketverlauf und größere Übertragung prüfen
Port erreichbar, Geschäftsprozess scheitert Backend oder Anwendungslogik fehlerhaft vollständigen Ablauf und Abhängigkeiten prüfen

7.9.28 Mögliche Ursachen und erforderliche Nachweise

Mögliche Ursache Erforderlicher Nachweis
falscher Port Anwendungskonfiguration und tatsächlicher Listener zeigen unterschiedliche Ports
Dienst gestoppt kein Listener vorhanden und Dienststatus beziehungsweise Logs bestätigen den Ausfall
falsche Listenerbindung Dienst lauscht nur auf Loopback oder einer anderen Adresse
Hostfirewall blockiert Port konkrete Regel oder Protokoll zeigt den verworfenen Verbindungsversuch
Netzwerkfirewall oder ACL Trefferprotokoll oder beidseitiger Paketmitschnitt bestätigt die Unterbrechung
falscher DNS-Eintrag Anwendung verwendet eine nachweislich falsche oder veraltete Adresse
fehlerhafter IPv6-Pfad IPv6-Test scheitert reproduzierbar, IPv4-Test funktioniert
Proxyfehler Anwendung verwendet einen fehlerhaften Proxyweg, während direkter Test anders reagiert
Reverse-Proxy-Fehler Proxy antwortet, passende Route oder gesundes Backend fehlt
Load-Balancer-Fehler virtuelle Adresse ist erreichbar, aber Healthcheck oder Backendzustand ist fehlerhaft
TLS-Fehler TLS-Ausgabe zeigt Zertifikats-, SNI- oder Protokollproblem
fehlende Authentifizierung Anwendung antwortet mit konkretem Anmelde- oder Tokenfehler
fehlende Autorisierung Anmeldung funktioniert, Ressourcenzugriff wird nachvollziehbar verweigert
ausgefallene Backendabhängigkeit Frontend antwortet, Serverlogs belegen den Fehler der Abhängigkeit
Ressourcenengpass Fehler korreliert mit CPU, Speicher, Worker-, Verbindungs- oder Datenträgerengpass
Path-MTU- oder Paketverlustproblem Verbindung beginnt, größere Übertragung scheitert und Paketverlauf bestätigt Wiederholungen oder Größenproblem
clientseitiger Anwendungsfehler gleicher Benutzer und Dienst funktionieren mit einem anderen Client
benutzerbezogener Fehler anderer Benutzer arbeitet am gleichen Client erfolgreich

7.9.29 Kontrollierte Maßnahmen, Risiko und Rückweg

Maßnahme Risiko Rückweg
falschen Servernamen oder Port korrigieren Verbindung erreicht anderes Ziel ursprüngliche Konfiguration wiederherstellen
gestoppten Dienst kontrolliert starten Dienst kann erneut fehlschlagen oder Last erzeugen Dienstzustand und Starttyp dokumentieren
Listenerbindung korrigieren Dienst wird auf zusätzlichen Netzen erreichbar vorherige Bindung wiederherstellen
minimale Firewallfreigabe ergänzen zusätzliche Erreichbarkeit konkrete Regel entfernen oder deaktivieren
falschen DNS-Eintrag korrigieren Clients wechseln auf neues Ziel vorherigen Wert und TTL dokumentieren
Reverse-Proxy-Route korrigieren andere Anwendungen können betroffen sein vorherige Proxykonfiguration zurückspielen
fehlerhaftes Backend aus dem Load Balancer nehmen geringere Kapazität Backend nach erfolgreicher Prüfung wieder aufnehmen
Proxykonfiguration korrigieren anderer Netzwerkpfad wird verwendet ursprüngliche Proxywerte wiederherstellen
Zertifikatskette korrigieren TLS-Dienst muss eventuell neu geladen werden vorherige Zertifikatskonfiguration sichern
Anwendungscache kontrolliert leeren Sitzungs- oder Anmeldedaten können verloren gehen Benutzer informieren und Ausgangszustand dokumentieren
Backenddienst wiederherstellen abhängige Anwendungen können beeinflusst werden dienstspezifischen Wiederherstellungsplan verwenden
Ressource freigeben oder Kapazität erhöhen Lastverteilung kann sich ändern vorherige Kapazitäts- oder Ressourcenwerte sichern

Pro Maßnahme sollte möglichst nur eine relevante Variable verändert werden.

7.9.30 Verifikation

Nach einer Maßnahme müssen mindestens folgende Prüfungen erfolgen:

Ein erfolgreicher Ping oder Porttest allein ist keine ausreichende Verifikation.

7.9.31 Präventionsmaßnahmen

7.9.32 Typische Fehler bei der Diagnose

7.9.33 Typische Prüfungsfragen

Warum beweist ein erfolgreicher Ping keine funktionierende Anwendung?

Ping prüft ICMP-Echo-Kommunikation. Die Anwendung kann einen anderen Transportweg, einen bestimmten TCP- oder UDP-Port, TLS, Authentifizierung und weitere Backenddienste benötigen.

Welcher Test sollte nach einem erfolgreichen Ping durchgeführt werden?

Zuerst müssen Zielname, Protokoll und Port der Anwendung bestimmt werden. Anschließend wird der konkrete TCP-Port oder das tatsächliche UDP-Anwendungsprotokoll geprüft.

Was bedeutet „Connection refused“?

Die TCP-Verbindung wurde aktiv abgelehnt. Häufig fehlt ein Listener auf dem Zielport oder eine Komponente lehnt die Verbindung gezielt ab. Der genaue Absender der Ablehnung muss bei Bedarf mit Protokollen oder einem Paketmitschnitt bestimmt werden.

Was bedeutet ein TCP-Timeout?

Der Verbindungsaufbau wurde nicht rechtzeitig abgeschlossen. Mögliche Ursachen sind eine verwerfende Firewallregel, ein falscher Netzwerkpfad, ein fehlender Rückweg, Überlastung oder eine falsche Zieladresse.

Warum sollte ein HTTPS-Dienst nicht nur über seine IP-Adresse getestet werden?

Virtuelle Hosts, TLS-SNI und Zertifikatsprüfung verwenden den Servernamen. Ein Aufruf über die IP-Adresse kann deshalb einen anderen Dienst oder ein anderes Zertifikat erreichen.

Was beweist ein erfolgreicher TCP-Porttest?

Er beweist, dass zum Testzeitpunkt eine TCP-Verbindung zur geprüften Adresse und zum geprüften Port aufgebaut werden konnte. Die Funktion des Anwendungsprotokolls ist damit noch nicht bewiesen.

Was bedeutet ein HTTP-Statuscode 401 oder 403 für die Netzwerkdiagnose?

Die Anwendung wurde erreicht und hat auf HTTP-Ebene geantwortet. Der Fehler liegt anschließend wahrscheinlich bei Authentifizierung, Autorisierung oder einer Anwendungsrichtlinie.

Warum ist ein allgemeiner UDP-Porttest nicht eindeutig?

UDP besitzt keinen verbindlichen Verbindungsaufbau. Ohne gültige Anwendungsanfrage und auswertbare Antwort lässt sich die Dienstfunktion nicht sicher bestätigen.

Was bedeutet es, wenn die Anwendung lokal auf dem Server funktioniert, vom Client aber nicht?

Der Dienst selbst arbeitet grundsätzlich. Danach müssen Listenerbindung, Hostfirewall, Netzwerkpfad, Proxy, Load Balancer und externe Namensauflösung geprüft werden.

Warum kann curl funktionieren, obwohl die eigentliche Anwendung fehlschlägt?

Die Anwendung kann einen anderen Proxy, Zertifikatsspeicher, DNS-Cache, Benutzerkontext, Authentifizierungsmechanismus oder zusätzliche Protokollfunktionen verwenden.

Warum reicht ein erfolgreicher Healthcheck nicht immer aus?

Ein Healthcheck kann nur einen einfachen Endpunkt prüfen. Datenbankzugriff, Anmeldung oder der eigentliche Geschäftsprozess können trotzdem fehlschlagen.

7.9.34 Checkliste

7.9.35 Schnellreferenz

Aufgabe Windows Linux macOS
Ping ping <Server> ping -c 4 <Server> ping -c 4 <Server>
Namensauflösung Resolve-DnsName <Server> getent ahosts <Server> dscacheutil -q host -a name <Server>
A-Eintrag Resolve-DnsName <Server> -Type A dig <Server> A dig <Server> A
AAAA-Eintrag Resolve-DnsName <Server> -Type AAAA dig <Server> AAAA dig <Server> AAAA
TCP-Port Test-NetConnection <Server> -Port <Port> nc -vz <Server> <Port> nc -vz <Server> <Port>
HTTP oder HTTPS curl.exe -v <URL> curl -v <URL> curl -v <URL>
IPv4 mit curl curl.exe -4 -v <URL> curl -4 -v <URL> curl -4 -v <URL>
IPv6 mit curl curl.exe -6 -v <URL> curl -6 -v <URL> curl -6 -v <URL>
bestimmte Ziel-IP curl.exe --resolve <Name>:<Port>:<IP> <URL> curl --resolve <Name>:<Port>:<IP> <URL> curl --resolve <Name>:<Port>:<IP> <URL>
Listener Get-NetTCPConnection -State Listen sudo ss -lntp sudo lsof -nP -iTCP -sTCP:LISTEN
WinHTTP-Proxy netsh winhttp show proxy nicht zutreffend nicht zutreffend
Systemproxy Anwendungseinstellungen prüfen Anwendung und Umgebungsvariablen prüfen scutil --proxy
TLS openssl s_client bei installierter OpenSSL-Version openssl s_client openssl s_client
Paketmitschnitt Wireshark oder freigegebenes Windows-Werkzeug tcpdump oder Wireshark tcpdump oder Wireshark

7.9.36 Quellen

Standards und RFCs

Offizielle Hersteller- und Projektdokumentation

Lokale Befehlsreferenzen

Die genaue Syntax kann von Betriebssystem und installierter Version abhängen. Maßgeblich ist die lokale Befehlsreferenz:

man ping
man nc
man curl
man ss
man lsof
man tcpdump
man dscacheutil
man scutil

Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.

7.10 Anmeldung an der Domäne funktioniert nicht

7.10.1 Ausgangssituation

Ein Benutzer kann sich an einem Windows-Computer nicht mit seinem Domänenkonto anmelden.

Mögliche Meldungen sind beispielsweise:

Der Benutzername oder das Kennwort ist falsch.

Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar.

Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.

Wir können Sie mit diesen Anmeldeinformationen nicht anmelden, weil Ihre Domäne nicht verfügbar ist.

Der Sicherheitsdatenbank auf dem Server ist kein Computerkonto für diese Arbeitsstationsvertrauensstellung zugeordnet.

Der Benutzerprofildienst konnte die Anmeldung nicht durchführen.

Diese Meldungen beschreiben unterschiedliche Fehlerbereiche. Eine fehlgeschlagene Domänenanmeldung darf deshalb nicht automatisch auf ein falsches Kennwort reduziert werden.

7.10.2 Ziel der Diagnose

Die Diagnose soll eindeutig bestimmen, ob der Fehler verursacht wird durch:

Erst nach dem Nachweis der Ursache wird eine kontrollierte Maßnahme durchgeführt.

7.10.3 Geltungsbereich und Abgrenzung

Diese Seite behandelt hauptsächlich die Anmeldung eines Domänenbenutzers an einem Computer, der Mitglied einer lokalen Active-Directory-Domäne mit Active Directory Domain Services ist.

Davon zu unterscheiden sind:

Konto- oder Geräteart Kennzeichnung beziehungsweise Beispiel
lokales Konto .\MaxMustermann oder <Computername>\MaxMustermann
Active-Directory-Domänenkonto <NETBIOS-Domäne>\MaxMustermann
Active-Directory-UPN max.mustermann@<DNS-Domäne>
Microsoft-Entra-Konto häufig ebenfalls UPN-Format, aber cloudbasierte Identität
Microsoft-Konto persönliche Microsoft-Identität
Smartcard-Anmeldung zertifikatsbasierte Anmeldung
Windows Hello for Business schlüssel- oder zertifikatsbasierte Anmeldung
Remotedesktop-Anmeldung Anmeldung erfolgt am entfernten Zielsystem
Dienst- oder Aufgabenanmeldung nicht interaktiver Anmeldetyp

Ein Benutzername im Format benutzer@domäne beweist allein nicht, ob ein lokales Active Directory, Microsoft Entra ID oder ein anderer Identitätsanbieter verwendet wird.

Microsoft-Entra-Anmeldefehler, MFA und Conditional Access benötigen teilweise andere Diagnoseverfahren. Sie dürfen nicht mit einer klassischen AD-Domänenanmeldung gleichgesetzt werden.

7.10.4 Technischer Anmeldeweg

Eine normale Online-Domänenanmeldung benötigt mehrere funktionierende Ebenen:

  1. Der Benutzer wählt den richtigen Anmeldeanbieter.
  2. Windows ordnet den eingegebenen Namen dem vorgesehenen Konto zu.
  3. Der Computer besitzt eine geeignete Netzwerkverbindung.
  4. Der Client verwendet die vorgesehenen DNS-Server.
  5. DNS liefert die erforderlichen Domänen- und Dienstinformationen.
  6. DC Locator ermittelt einen geeigneten Domänencontroller.
  7. Die benötigten Netzwerkprotokolle erreichen den Domänencontroller.
  8. Client und Domänencontroller besitzen ausreichend synchronisierte Uhrzeiten.
  9. Der Computer besitzt eine gültige Vertrauensbeziehung zur Domäne.
  10. Kerberos, NTLM oder das vorgesehene zertifikatsbasierte Verfahren beginnt.
  11. Der Domänencontroller prüft das Benutzerkonto und die Anmeldeinformationen.
  12. Kontorichtlinien und Anmelderechte werden ausgewertet.
  13. Windows erzeugt die Anmeldesitzung und das Zugriffstoken.
  14. Benutzerprofil, Gruppenrichtlinien und Anmeldeskripte werden verarbeitet.
  15. Der Desktop beziehungsweise die vorgesehene Sitzung wird bereitgestellt.

Der sichtbare Fehler kann an jeder dieser Ebenen entstehen.

7.10.5 Zuerst die genaue Fehlerphase bestimmen

Fehlerphase Typische Beobachtung Wahrscheinlicher Bereich
vor Eingabe der Anmeldedaten Netzwerk- oder Anmeldeoption fehlt Client, Treiber, VPN oder Anmeldeanbieter
unmittelbar nach Eingabe Kennwort- oder Kontofehler Identität, Kennwort, Sperre oder Kontorichtlinie
längere Wartezeit vor Fehlermeldung kein DC, DNS, Netzwerk oder Timeout Infrastruktur und Erreichbarkeit
Meldung über Vertrauensstellung Computerkonto oder sicherer Kanal Computervertrauen
Anmeldung funktioniert offline, aber nicht online Cache oder unterschiedlicher DC-Zustand DNS, DC, Kennwort oder Replikation
Anmeldung wird akzeptiert, Desktop erscheint nicht Profil, Richtlinie, Skript oder Ressource Phase nach der Authentifizierung
temporäres Profil wird geladen Benutzerprofilproblem Profilpfad, Datenträger oder Profildienst
nur RDP schlägt fehl RDP, NLA, Anmelderecht oder Zielsystem entfernter Computer
PIN schlägt fehl, Kennwort funktioniert Windows Hello oder PIN-Anbieter Hello-Schlüssel, TPM oder Richtlinie
Smartcard schlägt fehl, Kennwort funktioniert Zertifikat oder PKI Smartcard, Zertifikatskette, KDC-Zertifikat oder Sperrprüfung

Eine erfolgreiche Kennwortprüfung bedeutet noch nicht, dass Benutzerprofil, Gruppenrichtlinien und Desktop erfolgreich geladen werden.

7.10.6 Beweise vor Änderungen sichern

Vor einem Neustart, einer Kennwortzurücksetzung, dem Entsperren eines Kontos oder einer Reparatur des sicheren Kanals sollten mindestens folgende Informationen gesichert werden:

Kennwörter, PINs, private Schlüssel, Wiederherstellungsschlüssel und vollständige Anmeldetoken dürfen nicht dokumentiert oder weitergegeben werden.

Wiederholte unkontrollierte Anmeldeversuche müssen vermieden werden, weil dadurch das Konto gesperrt werden kann.

7.10.7 Umfang des Fehlers bestimmen

Geeignete Kreuztests:

Vergleich Erkenntnis
gleicher Benutzer an anderem Domänencomputer benutzer- oder computerbezogenen Fehler unterscheiden
anderer Domänenbenutzer am gleichen Computer Benutzerkonto und Computerzustand unterscheiden
gleiches Konto mit und ohne VPN VPN-, DNS- oder Routingabhängigkeit erkennen
gleiches Konto an Konsole und per RDP lokale und entfernte Anmeldung unterscheiden
Kennwort statt PIN Windows-Hello-Fehler abgrenzen
Kennwort statt Smartcard Zertifikats- oder Smartcardfehler abgrenzen
lokales Administratorkonto Zugriff für die Clientdiagnose ermöglichen
Test gegen anderen Standort oder anderen DC standort- oder DC-bezogenen Fehler erkennen

Auswertung:

Ergebnis Wahrscheinlicher Bereich
nur ein Benutzer betroffen Benutzerkonto, Kennwort, Sperre oder Benutzerprofil
alle Benutzer an einem Computer betroffen Client, DNS, Netzwerk, Zeit oder sicherer Kanal
viele Computer betroffen DNS, DC, Netzwerk, Zeitdienst, Replikation oder zentrale Richtlinie
nur ein Standort betroffen Standortnetz, VPN, DNS, Firewall oder Standortzuordnung
nur ein Domänencontroller betroffen DC-Dienst, DNS-Registrierung, Replikation oder Zeit
nur neue Kennwörter betroffen Kennwortcache, Replikation oder gespeicherte alte Anmeldedaten
Authentifizierung funktioniert, Desktop nicht Profil, Gruppenrichtlinie, Skript oder Ressource

Ein Testkonto darf nur nach den organisatorischen Sicherheitsvorgaben verwendet werden.

7.10.8 Richtige Identität und Anmeldeoption prüfen

Am Anmeldebildschirm muss geprüft werden:

Beispiele:

<NETBIOS-Domäne>\MaxMustermann

max.mustermann@<DNS-Domäne>

.\MaxMustermann

Bedeutung:

NETBIOS-Domänenname und DNS-Domänenname müssen nicht identisch sein.

Ein lokaler Anmeldeerfolg beweist weder eine funktionierende Domänenverbindung noch ein gültiges Domänenkonto.

7.10.9 Bestehende Sitzung und Identität prüfen

Wenn noch eine bestehende Sitzung verfügbar ist:

whoami
whoami /user
whoami /fqdn
whoami /groups

In PowerShell:

$env:USERDOMAIN
$env:USERDNSDOMAIN
$env:LOGONSERVER

Wichtige Einschränkungen:

7.10.10 Domänenmitgliedschaft des Computers prüfen

Mit einem autorisierten lokalen Konto oder einer noch verfügbaren Administrationssitzung:

Get-CimInstance Win32_ComputerSystem |
  Select-Object Name, PartOfDomain, Domain, Workgroup

Erwartet wird:

PartOfDomain : True
Domain       : <DNS-Domäne>

Zusätzlich:

systeminfo

Relevante Felder sind:

Domäne
Anmeldeserver

Zu prüfen sind:

PartOfDomain : True beweist nur die lokale Mitgliedschaftskonfiguration. Es beweist nicht, dass der sichere Kanal aktuell funktioniert.

7.10.11 Online-Anmeldung und zwischengespeicherte Domänenanmeldung unterscheiden

Windows kann Informationen früherer Domänenanmeldungen lokal zwischenspeichern. Dadurch kann sich ein Benutzer unter bestimmten Voraussetzungen anmelden, obwohl kein Domänencontroller erreichbar ist.

Eine zwischengespeicherte Anmeldung beweist nicht:

Wurde das Kennwort an einem anderen Computer geändert, kann ein offline verwendeter Client weiterhin den früher zwischengespeicherten Kennwortnachweis erwarten. Erst eine erfolgreiche Online-Anmeldung kann den lokalen Anmeldecache aktualisieren.

Die Anzahl zwischengespeicherter eindeutiger Benutzer wird durch die Sicherheitsrichtlinie bestimmt:

Computerkonfiguration
└── Windows-Einstellungen
    └── Sicherheitseinstellungen
        └── Lokale Richtlinien
            └── Sicherheitsoptionen
                └── Interaktive Anmeldung:
                   Anzahl zwischenzuspeichernder vorheriger Anmeldungen

Der genaue Wert ist eine Sicherheitsentscheidung der Organisation. Er darf nicht nur zur Fehlerumgehung verändert werden.

Typische Unterscheidung:

Verhalten Einordnung
Anmeldung ohne Netzwerk funktioniert Cache-Anmeldung möglich
Anmeldung mit Netzwerk schlägt fehl Online-Authentifizierung oder anderer DC-Zustand fehlerhaft
altes Kennwort funktioniert offline lokaler Cache kann noch den alten Nachweis enthalten
neues Kennwort funktioniert online DC kennt das neue Kennwort
neues Kennwort funktioniert an einem Gerät, an anderem nicht Cache, DC-Auswahl oder Replikation prüfen
noch nie auf diesem Computer angemeldeter Benutzer kann offline nicht anmelden kein passender lokaler Anmeldecache vorhanden

7.10.12 Netzwerkzustand des Clients prüfen

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

Get-NetIPConfiguration

ipconfig /all

Zu dokumentieren sind:

Ein Ping zum Gateway oder zu einem DC ist nur ein Teilnachweis. Die Domänenanmeldung benötigt DNS, DC Locator und mehrere Anwendungsprotokolle.

Bei einer Anmeldung außerhalb des Unternehmensnetzes ist zu prüfen, ob eine Anmeldung vor dem Windows-Desktop überhaupt eine VPN-Verbindung herstellen kann. Ein VPN, das erst nach der Benutzeranmeldung startet, kann keine erstmalige Online-Domänenanmeldung ermöglichen.

7.10.13 DNS-Konfiguration prüfen

Active Directory ist auf DNS-basierte Diensterkennung angewiesen. Der Client sollte die für die AD-Domäne vorgesehenen DNS-Server verwenden.

DNS-Server anzeigen:

Get-DnsClientServerAddress |
  Select-Object InterfaceAlias, AddressFamily, ServerAddresses

Domänenname prüfen:

Resolve-DnsName -Name <DNS-Domäne> -Type A

Domänencontroller-Dienst prüfen:

Resolve-DnsName `
  -Name _ldap._tcp.dc._msdcs.<DNS-Domäne> `
  -Type SRV

Kerberos-Dienst prüfen:

Resolve-DnsName `
  -Name _kerberos._tcp.<DNS-Domäne> `
  -Type SRV

Einen bestimmten DNS-Server verwenden:

Resolve-DnsName `
  -Name _ldap._tcp.dc._msdcs.<DNS-Domäne> `
  -Type SRV `
  -Server <DNS-Server>

Zu prüfen sind:

Öffentliche Resolver kennen die internen Active-Directory-Dienstinformationen normalerweise nicht. Ein zusätzlich eingetragener öffentlicher DNS-Server ist kein zuverlässiger Ersatz für den vorgesehenen AD-DNS-Server.

DNS-Caches sollten nicht sofort gelöscht werden. Zuerst müssen aktuelle Antworten, DNS-Server und die verwendete Zieladresse dokumentiert werden.

7.10.14 Domänencontroller-Ermittlung prüfen

Windows verwendet DC Locator und den Netlogon-Dienst, um über DNS-SRV-Einträge einen geeigneten Domänencontroller zu finden.

nltest /dsgetdc:<DNS-Domäne>

Erneute DNS-basierte Ermittlung ohne den bisherigen DC-Cache:

nltest /dsgetdc:<DNS-Domäne> /force

Nur einen beschreibbaren DC anfordern:

nltest /dsgetdc:<DNS-Domäne> /writable /force

Lokalen AD-Standort anzeigen:

nltest /dsgetsite

Bekannte Domänencontroller auflisten:

nltest /dclist:<DNS-Domäne>

In der Ausgabe von nltest /dsgetdc sind unter anderem wichtig:

DC
Address
Domain Name
Forest Name
Dc Site Name
Our Site Name
Flags

Auswertung:

Ergebnis Bedeutung
geeigneter DC wird gefunden DC Locator war für diesen Versuch erfolgreich
ERROR_NO_SUCH_DOMAIN Domäne oder DC konnte nicht gefunden werden
falscher Standort Subnetz- oder Standortzuordnung prüfen
alter DC wird geliefert DNS-Registrierung und AD-Metadaten prüfen
nur ein entfernter DC wird gefunden lokaler DC, Standort oder DNS möglicherweise fehlerhaft
DC wird gefunden, Anmeldung scheitert trotzdem Erreichbarkeit, Zeit, Konto, sicherer Kanal und Protokoll prüfen

Ein erfolgreiches nltest /dsgetdc beweist nicht, dass alle für die Anmeldung benötigten Protokolle funktionieren.

7.10.15 Erreichbarkeit der benötigten Dienste prüfen

Grundlegende TCP-Tests:

Test-NetConnection -ComputerName <DC-FQDN> -Port 53
Test-NetConnection -ComputerName <DC-FQDN> -Port 88
Test-NetConnection -ComputerName <DC-FQDN> -Port 135
Test-NetConnection -ComputerName <DC-FQDN> -Port 389
Test-NetConnection -ComputerName <DC-FQDN> -Port 445

Je nach Funktion zusätzlich:

Test-NetConnection -ComputerName <DC-FQDN> -Port 464
Test-NetConnection -ComputerName <DC-FQDN> -Port 3268
Test-NetConnection -ComputerName <DC-FQDN> -Port 636
Test-NetConnection -ComputerName <DC-FQDN> -Port 3269

Wichtige AD-Protokolle:

Dienst Protokoll und Port Bedeutung
DNS TCP/UDP 53 Namens- und Dienstauflösung
Kerberos TCP/UDP 88 Kerberos-Authentifizierung
Windows-Zeit UDP 123 Zeitsynchronisation
RPC Endpoint Mapper TCP 135 RPC-Endpunktermittlung
LDAP TCP 389 Verzeichniszugriff
DC Locator UDP 389 DC-Ermittlung
SMB TCP 445 Netlogon, SYSVOL und Gruppenrichtlinien
Kerberos-Kennwortdienst TCP/UDP 464 Kennwortänderungen
Global Catalog TCP 3268 gesamtstrukturweite Abfragen
LDAPS TCP 636 LDAP über TLS, sofern verwendet
Global Catalog über TLS TCP 3269 GC über TLS, sofern verwendet
dynamische RPC-Ports üblicherweise TCP 49152–65535 bei modernen Windows-Versionen ausgehandelte RPC-Verbindungen

Wichtige Einschränkungen:

Firewalls dürfen nicht pauschal deaktiviert werden. Die konkrete Regel muss anhand von Quelle, Ziel, Protokoll, Port, Richtung und Zeitstempel geprüft werden.

7.10.16 Zeit und Zeitsynchronisation prüfen

Kerberos benötigt ausreichend synchronisierte Uhrzeiten. Die standardmäßige maximale Kerberos-Zeitabweichung beträgt in vielen AD-Umgebungen fünf Minuten, kann aber durch Richtlinien verändert werden.

Clientstatus:

w32tm /query /status
w32tm /query /source
w32tm /query /configuration

Zeitabweichung zu einem DC beobachten:

w32tm /stripchart /computer:<DC-FQDN> /dataonly /samples:5

Zusätzlich zu prüfen:

Get-Service W32Time

Zu vergleichen sind:

Eine richtige Bildschirmanzeige allein beweist keine korrekte Zeitkonfiguration. Zeitzone, UTC-Zeit, Zeitquelle und tatsächliche Abweichung müssen getrennt betrachtet werden.

Eine Resynchronisation ist eine Änderung und sollte erst nach Dokumentation der bisherigen Quelle und Abweichung erfolgen:

w32tm /resync /rediscover

Danach müssen Quelle, Status und Abweichung erneut geprüft werden.

7.10.17 Benutzerkonto prüfen

Mit dem ActiveDirectory-PowerShell-Modul und ausreichender Leseberechtigung:

Get-ADUser `
  -Identity "<Benutzername>" `
  -Properties Enabled,
              LockedOut,
              PasswordExpired,
              AccountExpirationDate,
              PasswordLastSet,
              LastBadPasswordAttempt,
              BadLogonCount,
              LogonWorkstations |
  Select-Object SamAccountName,
                UserPrincipalName,
                Enabled,
                LockedOut,
                PasswordExpired,
                AccountExpirationDate,
                PasswordLastSet,
                LastBadPasswordAttempt,
                BadLogonCount,
                LogonWorkstations

Ergebnisbezogene Kennwortrichtlinie prüfen:

Get-ADUserResultantPasswordPolicy `
  -Identity "<Benutzername>"

Gezielte Suchbefehle:

Search-ADAccount -LockedOut -UsersOnly
Search-ADAccount -AccountDisabled -UsersOnly
Search-ADAccount -AccountExpired -UsersOnly
Search-ADAccount -PasswordExpired -UsersOnly

Alternativ mit integrierten Werkzeugen:

net user <Benutzername> /domain

Zu prüfen sind:

BadLogonCount, LastBadPasswordAttempt und ähnliche Werte können DC-abhängig sein. Sie dürfen nicht ohne Berücksichtigung des abgefragten Domänencontrollers und der Replikation interpretiert werden.

Ein Konto sollte nicht vorsorglich entsperrt oder dessen Kennwort zurückgesetzt werden, bevor die Quelle fehlerhafter Anmeldeversuche untersucht wurde. Gespeicherte alte Kennwörter in Diensten, Aufgaben, Mobilgeräten oder Anwendungen können das Konto sofort erneut sperren.

7.10.18 Kennwortfehler systematisch abgrenzen

Mögliche Ursachen trotz scheinbar richtiger Eingabe:

Ein administratives Zurücksetzen des Kennworts kann Auswirkungen auf verschlüsselte benutzerbezogene Daten, gespeicherte Anmeldeinformationen und Zertifikatsschlüssel besitzen. Es muss nach dem vorgesehenen Identitäts- und Wiederherstellungsverfahren erfolgen.

7.10.19 Sicheren Kanal des Computers prüfen

Domänencomputer und Domäne besitzen eine Vertrauensbeziehung auf Grundlage des Computerkontos und eines Computerkennworts. Stimmen der lokale und der in Active Directory gespeicherte Zustand nicht mehr überein, kann der sichere Kanal fehlschlagen.

Typische Meldung:

Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.

Nur prüfen:

powershell

Test-ComputerSecureChannel -Verbose


Erwartetes Ergebnis:

```text
True

Ein bestimmter DC kann für den Test angegeben werden:

Test-ComputerSecureChannel `
  -Server "<DC-FQDN>" `
  -Verbose

Status des zuletzt verwendeten Netlogon-Kanals anzeigen:

nltest /sc_query:<DNS-Domäne>

Wichtige Einschränkungen:

Mögliche Ursachen eines defekten sicheren Kanals:

Ein defekter sicherer Kanal ist ein konkreter Befund. Der Computer sollte nicht vorsorglich aus der Domäne entfernt werden.

7.10.20 Kerberos und NTLM unterscheiden

Windows verwendet häufig das Aushandlungspaket Negotiate. Dieses wählt nach Möglichkeit Kerberos und kann unter bestimmten Bedingungen NTLM verwenden.

Kerberos benötigt unter anderem:

NTLM benötigt ebenfalls einen erreichbaren zuständigen Authentifizierungsserver und darf nicht als automatische oder dauerhafte Lösung für Kerberos-Probleme betrachtet werden.

Ein erfolgreicher NTLM-Versuch beweist nicht, dass Kerberos funktioniert. Ein Fehlschlag bei Kerberos darf nicht ungeprüft durch Lockerung der Sicherheitsrichtlinien oder dauerhafte Aktivierung veralteter Verfahren umgangen werden.

7.10.21 Kerberos-Tickets prüfen

In einer bestehenden Domänensitzung:

klist

TGT anzeigen:

klist tgt

Alle Tickets der aktuellen Sitzung anzeigen:

klist tickets

Zu prüfen sind:

klist purge löscht Kerberos-Tickets der angegebenen Anmeldesitzung und ist daher keine rein lesende Diagnose:

klist purge

Mögliche Auswirkungen:

Tickets sollten deshalb zuerst dokumentiert und nur im Rahmen eines kontrollierten Tests gelöscht werden.

Eine fehlgeschlagene interaktive Anmeldung besitzt möglicherweise noch keine normale Benutzersitzung, in der klist ausgeführt werden kann. In diesem Fall sind die Ereignisse auf dem Domänencontroller besonders wichtig.

7.10.22 Relevante Ereignisprotokolle

Ereignisse müssen anhand des gleichen Benutzer-, Computer- und Fehlerzeitpunkts korreliert werden.

Auf dem betroffenen Client:

Auf dem beteiligten Domänencontroller:

Beispiel für Clientereignisse der letzten zwei Stunden:

Get-WinEvent -FilterHashtable @{
  LogName   = 'System'
  StartTime = (Get-Date).AddHours(-2)
} |
  Where-Object {
    $_.ProviderName -match 'NETLOGON|W32Time|DNS|Lsa'
  } |
  Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message

Fehlgeschlagene Anmeldungen auf einem System:

Get-WinEvent -FilterHashtable @{
  LogName   = 'Security'
  Id        = 4625
  StartTime = (Get-Date).AddHours(-2)
} |
  Select-Object TimeCreated, Id, Message

Relevante Ereignisse:

Ereignis-ID Typische Bedeutung Typischer Ort
4624 erfolgreiche Anmeldung System, auf dem die Anmeldung erfolgte
4625 fehlgeschlagene Anmeldung System, auf dem die Anmeldung versucht wurde
4740 Benutzerkonto wurde gesperrt zuständiges System beziehungsweise DC
4767 Benutzerkonto wurde entsperrt Domänencontroller
4768 Kerberos-TGT wurde angefordert Domänencontroller
4769 Kerberos-Dienstticket wurde angefordert Domänencontroller
4771 Kerberos-Vorauthentifizierung fehlgeschlagen Domänencontroller
4776 NTLM-Anmeldeinformationen wurden geprüft für Domänenkonten auf dem zuständigen DC
3210 Netlogon konnte Computer nicht beim DC authentifizieren Mitgliedscomputer
5719 kein Domänencontroller für sichere Sitzung verfügbar Mitgliedscomputer
1053 oder 1055 Gruppenrichtlinienverarbeitung mit Domänen- oder DC-Problem Mitgliedscomputer

Die Ereignisse erscheinen nur, wenn die entsprechenden Überwachungsrichtlinien und Protokollkanäle aktiviert sind. Das Fehlen eines Ereignisses beweist deshalb nicht, dass kein Versuch stattgefunden hat.

7.10.23 Ereignis 4625 auswerten

Bei Ereignis 4625 sind besonders wichtig:

Account Name
Account Domain
Failure Reason
Status
Sub Status
Logon Type
Logon Process
Authentication Package
Workstation Name
Source Network Address
Caller Process Name

Wichtige Anmeldetypen:

Logon Type Bedeutung
2 interaktive lokale Anmeldung
3 Netzwerkanmeldung
4 Batch beziehungsweise geplante Aufgabe
5 Dienstanmeldung
7 Entsperren
10 Remotedesktop beziehungsweise RemoteInteractive
11 zwischengespeicherte interaktive Anmeldung

Häufige Status- oder Substatuswerte:

Code Bedeutung Nächster Nachweis
0xC000005E keine Anmeldeserver verfügbar DNS, DC Locator, Netzwerk und DC-Zustand prüfen
0xC0000064 Benutzerkonto nicht gefunden Benutzername, Domäne und Kontobestand prüfen
0xC000006A falsches Kennwort Eingabe, Kennwortänderung und gespeicherte Kennwörter prüfen
0xC000006D allgemeiner Fehler bei Benutzername oder Authentifizierungsdaten Status, Substatus und Authentifizierungspaket korrelieren
0xC000006F Anmeldung außerhalb erlaubter Zeiten Anmeldezeiten prüfen
0xC0000070 Anmeldung von nicht erlaubter Arbeitsstation Arbeitsstationsbeschränkung prüfen
0xC0000071 Kennwort abgelaufen Kennwortstatus und Änderungsweg prüfen
0xC0000072 Konto deaktiviert Kontostatus und Änderungshistorie prüfen
0xC000015B erforderlicher Anmeldetyp nicht gewährt Benutzerrechte und Richtlinien prüfen
0xC0000192 Netlogon-Dienst ist nicht gestartet Dienstzustand und Systemereignisse prüfen
0xC0000193 Konto abgelaufen Ablaufdatum des Kontos prüfen
0xC0000234 Konto gesperrt Ereignis 4740 und Quelle der Fehlversuche untersuchen
0xC0000413 Authentifizierungsfirewall verhindert Anmeldung Authentifizierungsrichtlinie und zulässige Systeme prüfen

Status und Substatus müssen gemeinsam ausgewertet werden. Der sichtbare Meldungstext am Anmeldebildschirm kann absichtlich weniger genau sein als das Sicherheitsereignis.

7.10.24 Kerberos-Ereignisse auswerten

Ereignis 4768 zeigt die Anforderung eines Kerberos-TGT. Ereignis 4771 zeigt eine fehlgeschlagene Kerberos-Vorauthentifizierung.

Häufige Kerberos-Fehlercodes:

Code Kerberos-Bezeichnung Einordnung
0x6 KDC_ERR_C_PRINCIPAL_UNKNOWN Benutzerprinzipal nicht in Kerberos-Datenbank gefunden
0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN angeforderter Dienstprinzipal nicht gefunden
0x8 KDC_ERR_PRINCIPAL_NOT_UNIQUE Prinzipal nicht eindeutig
0xC KDC_ERR_POLICY KDC-Richtlinie lehnt Anfrage ab
0xE KDC_ERR_ETYPE_NOSUPP keine gemeinsame unterstützte Verschlüsselungsart
0x10 KDC_ERR_PADATA_TYPE_NOSUPP Vorauthentifizierungstyp nicht unterstützt; bei Smartcard auch Zertifikatsproblem möglich
0x12 KDC_ERR_CLIENT_REVOKED Anmeldeinformationen des Clients wurden widerrufen
0x17 KDC_ERR_KEY_EXPIRED Kennwort abgelaufen
0x18 KDC_ERR_PREAUTH_FAILED Vorauthentifizierung ungültig; häufig falsches Kennwort
0x19 KDC_ERR_PREAUTH_REQUIRED zusätzliche Vorauthentifizierung erforderlich; nicht automatisch ein Fehler
0x1D KDC_ERR_SVC_UNAVAILABLE Kerberos-Dienst nicht verfügbar
0x20 KRB_AP_ERR_TKT_EXPIRED Ticket abgelaufen
0x25 KRB_AP_ERR_SKEW Zeitabweichung zu groß
0x34 KRB_ERR_RESPONSE_TOO_BIG Antwort zu groß für UDP; erneuter Versuch über TCP erforderlich

Ein einzelner Kerberos-Fehlercode muss mit Benutzer, Clientadresse, DC, Zeitstempel und nachfolgendem Erfolg oder Fehlschlag korreliert werden.

Der Code 0x19 kann Teil eines normalen Kerberos-Ablaufs sein und darf nicht allein als Störung gewertet werden.

7.10.25 Kontosperren bis zur Quelle verfolgen

Bei einer Sperre muss nicht nur das Konto entsperrt, sondern die Quelle der wiederholten falschen Kennwörter bestimmt werden.

Zu untersuchen sind:

Eine Kontosperre kann durch einen Hintergrundprozess entstehen, obwohl der Benutzer sein aktuelles Kennwort am Anmeldebildschirm richtig eingibt.

7.10.26 Active-Directory-Replikation prüfen

Wenn Anmeldungen abhängig vom verwendeten Domänencontroller unterschiedlich reagieren, müssen Replikation und DC-Zustand geprüft werden.

Auf einem autorisierten Administrationssystem oder Domänencontroller:

repadmin /replsummary

repadmin /showrepl

Gesamtstrukturweite Übersicht:

repadmin /showrepl * /csv

Grundlegender DC-Test:

dcdiag /v

DNS-Test für einen bestimmten DC:

dcdiag /test:DNS /v /s:<DC-Name>

Zu prüfen sind:

Mögliche Symptome eines Replikationsfehlers:

Eine erzwungene Replikation ist keine erste Diagnosemaßnahme. Zuerst müssen Richtung, Fehlercode, Ursache und Replikationspartner bestimmt werden.

7.10.27 Standort, VPN und RODC berücksichtigen

AD-Standorte beeinflussen die Auswahl eines Domänencontrollers.

Clientstandort anzeigen:

nltest /dsgetsite

Zu prüfen sind:

Ein RODC kann nur solche Anmeldungen lokal verarbeiten, für die die erforderlichen Anmeldeinformationen entsprechend der Kennwortreplikationsrichtlinie verfügbar sind oder ein beschreibbarer DC erreicht werden kann.

7.10.28 RDP- und NLA-Anmeldungen abgrenzen

Bei Remotedesktop erfolgt die Anmeldung am entfernten Computer. Entscheidend sind daher DNS, Netzwerk, Zeit, Domänenverbindung, sicherer Kanal und Anmelderechte des Zielsystems.

Zu prüfen sind:

Ein erfolgreicher Domänenlogin am lokalen Notebook beweist nicht, dass der entfernte Server die Domäne erreichen oder den Benutzer anmelden kann.

NLA sollte nicht dauerhaft deaktiviert werden, nur um einen Authentifizierungsfehler zu umgehen.

7.10.29 Smartcard und Windows Hello for Business abgrenzen

Wenn Kennwortanmeldung funktioniert, aber Smartcard oder Windows Hello fehlschlägt, ist die normale Kennwortprüfung wahrscheinlich nicht die Hauptursache.

Bei Smartcard-Anmeldung zu prüfen:

Bei Windows Hello for Business zu prüfen:

Eine PIN ist nicht das Domänenkennwort. Ein PIN-Fehler beweist deshalb nicht, dass das AD-Kennwort falsch ist.

7.10.30 Authentifizierung, Sitzung und Benutzerprofil unterscheiden

Nach erfolgreicher Authentifizierung können weitere Fehler auftreten:

Typische Unterscheidung:

Beobachtung Einordnung
Ereignis 4624 vorhanden, danach Profilfehler Authentifizierung war wahrscheinlich erfolgreich
Desktop erscheint nach langer Wartezeit Gruppenrichtlinie, Skript oder Ressource prüfen
temporäres Profil Benutzerprofil und Datenträger prüfen
nur ein Benutzerprofil betroffen lokales oder servergespeichertes Profil möglich
Anmeldung anderer Benutzer funktioniert allgemeine DC-Erreichbarkeit wahrscheinlich vorhanden
Anmeldung im abgesicherten Diagnosekontext funktioniert nachgelagerte Erweiterung, Richtlinie oder Dienst möglich

Gruppenrichtlinienstatus in einer bestehenden Sitzung:

gpresult /r

Computerrichtlinien:

gpresult /r /scope computer

Benutzerrichtlinien:

gpresult /r /scope user

gpupdate /force ist keine reine Diagnose. Der Befehl kann neue Richtlinien anwenden und den Ausgangszustand verändern.

7.10.31 Systematischer Diagnoseablauf

  1. Fehlermeldung aufnehmen
    Exakten Wortlaut, Benutzer, Computer, Uhrzeit und Anmeldeart dokumentieren.

  2. Anmeldephase bestimmen
    Identität, Authentifizierung, Sitzung oder Profil unterscheiden.

  3. Umfang bestimmen
    Einen Benutzer, einen Computer, einen Standort oder die gesamte Domäne unterscheiden.

  4. Anmeldeanbieter kontrollieren
    Kennwort, PIN, Smartcard, lokales Konto und Domänenkonto unterscheiden.

  5. Namensformat prüfen
    UPN und DOMÄNE\Benutzer kontrolliert vergleichen.

  6. Domänenmitgliedschaft prüfen
    Lokale Mitgliedschaft und erwartete Domäne bestätigen.

  7. Online- und Cache-Anmeldung unterscheiden
    Feststellen, ob ein DC tatsächlich beteiligt war.

  8. Netzwerkzustand prüfen
    Schnittstelle, Adresse, Gateway, VPN und DNS-Server dokumentieren.

  9. DNS-SRV-Einträge prüfen
    LDAP- und Kerberos-Diensteinträge auflösen.

  10. Domänencontroller ermitteln
    nltest /dsgetdc und Standortinformationen auswerten.

  11. DC-Erreichbarkeit prüfen
    DNS, Kerberos, LDAP, SMB, RPC und benötigte Zusatzdienste untersuchen.

  12. Zeit prüfen
    Zeitquelle, Status und Abweichung zum DC bestimmen.

  13. Benutzerkonto prüfen
    Existenz, UPN, Aktivierung, Sperre, Ablauf und Kennwortstatus auswerten.

  14. Sicheren Kanal prüfen
    Ausschließlich mit lesenden Tests beginnen.

  15. Authentifizierungsverfahren bestimmen
    Kerberos, NTLM, Smartcard oder Windows Hello unterscheiden.

  16. Ereignisse korrelieren
    Client- und DC-Ereignisse auf denselben Versuch begrenzen.

  17. Fehlercode auswerten
    Status, Substatus, Kerberos-Code und Anmeldetyp bestimmen.

  18. Replikation prüfen
    Besonders bei DC- oder Standortabhängigkeit.

  19. Nachgelagerte Anmeldung prüfen
    Profil, Gruppenrichtlinie, Skript und Ressourcen untersuchen.

  20. Hypothese formulieren
    Erwarteten Befund und möglichen Gegenbeweis festlegen.

  21. Eine kontrollierte Maßnahme durchführen
    Risiko, Berechtigung, Rückweg und Erfolgskriterium dokumentieren.

  22. Online-Domänenanmeldung verifizieren
    Nicht nur Cache- oder lokale Anmeldung testen.

  23. Vollständige Benutzerfunktion prüfen
    Desktop, Gruppenrichtlinien und benötigte Ressourcen kontrollieren.

  24. Nachkontrolle durchführen
    Ereignisse, Replikation und weitere Benutzer beziehungsweise Systeme prüfen.

7.10.32 Befundmatrix

Befund Mögliche Erklärung Nächster Nachweis
lokales Konto funktioniert, Domänenkonto nicht Domänenweg oder Domänenkonto fehlerhaft DNS, DC Locator, Konto und sicheren Kanal prüfen
anderer Benutzer funktioniert am gleichen Computer benutzerbezogener Fehler Kontostatus, Kennwort und Profil prüfen
gleicher Benutzer funktioniert an anderem Computer clientbezogener Fehler DNS, Zeit, sicherer Kanal und Profil prüfen
Anmeldung funktioniert nur offline Cache-Anmeldung Onlineweg zum DC prüfen
altes Kennwort funktioniert offline alter lokaler Anmeldecache Onlineanmeldung mit aktuellem Kennwort prüfen
nltest /dsgetdc findet keinen DC DNS, Netzwerk oder Netlogon SRV-Einträge, DNS-Server und Dienst prüfen
DC wird gefunden, Ports schlagen fehl Firewall, Routing oder DC-Dienst Regeln und beidseitige Protokolle prüfen
Ereignis 0xC000005E keine Anmeldeserver verfügbar DNS, DC Locator und Netzwerk prüfen
Ereignis 0xC0000064 Benutzer nicht gefunden Identität und Kontobestand prüfen
Ereignis 0xC000006A falsches Kennwort Kennwort, Cache und gespeicherte Daten prüfen
Ereignis 0xC0000234 Konto gesperrt Ereignis 4740 und Sperrquelle prüfen
Kerberos 0x18 Vorauthentifizierung fehlgeschlagen Kennwort und zugehörigen Versuch prüfen
Kerberos 0x25 Zeitabweichung zu groß Zeitquelle und Abweichung prüfen
sicherer Kanal liefert False Computervertrauen fehlerhaft DNS, Zeit, Computerkonto und Replikation prüfen
Vertrauensfehler nur bei einem Computer Computerkennwort oder Computerkonto sicheren Kanal kontrolliert reparieren
Anmeldung funktioniert abhängig vom DC Replikations- oder DC-Fehler DC-Ereignisse und repadmin auswerten
Kennwort funktioniert, PIN nicht Windows-Hello-Problem Hello-, TPM- und Richtlinienzustand prüfen
Kennwort funktioniert, Smartcard nicht PKI- oder Zertifikatsproblem Zertifikate, KDC und Sperrprüfung untersuchen
Ereignis 4624 vorhanden, Desktop fehlt Authentifizierung erfolgreich, Folgephase fehlerhaft Profil, GPO und Skripte prüfen
nur RDP schlägt fehl RDP-Recht, NLA oder Zielsystem Logon Type 10 und Zielsystem prüfen
Konto wird sofort erneut gesperrt gespeichertes altes Kennwort Quellcomputer und Hintergrundprozesse ermitteln

7.10.33 Ursachen und erforderliche Nachweise

Mögliche Ursache Erforderlicher Nachweis
falsches Namensformat Anmeldung richtet sich nachweislich an falsche Domäne oder lokales Konto
falsches Kennwort Ereigniscode und kontrollierter Identitätsabgleich bestätigen die Ursache
Konto gesperrt AD-Kontostatus und Ereignis gesper 4740 bestätigen die Sperre
Konto deaktiviert Enabled : False oder entsprechendes Änderungsereignis
Konto abgelaufen Ablaufdatum liegt in der Vergangenheit
Kennwort abgelaufen PasswordExpired oder Kerberos-Code 0x17
falscher DNS-Server Client verwendet nicht den vorgesehenen AD-DNS-Server
fehlender SRV-Eintrag autorisierte DNS-Abfrage liefert den benötigten Eintrag nicht
falscher DC-Eintrag SRV- oder A/AAAA-Eintrag verweist auf falschen oder alten DC
DC nicht erreichbar protokollspezifischer Test und Netzwerkprotokoll bestätigen Unterbrechung
falscher AD-Standort nltest /dsgetsite und Subnetzkonfiguration stimmen nicht überein
VPN vor Anmeldung fehlt Onlineweg zum DC ist am Anmeldebildschirm nicht vorhanden
Zeitabweichung w32tm oder Kerberos-Code 0x25 bestätigt die Abweichung
defekter sicherer Kanal Test-ComputerSecureChannel meldet reproduzierbar False
Computerkonto fehlt AD-Abfrage bestätigt fehlendes oder falsches Computerkonto
doppelter Computername zwei Systeme verwenden nachweislich dieselbe Computeridentität
AD-Replikationsfehler repadmin oder DC-Protokolle zeigen fehlgeschlagene Replikation
Kerberos-Verschlüsselungsproblem Kerberos-Code und Kontokonfiguration bestätigen fehlende gemeinsame Verschlüsselungsart
Smartcard-Zertifikatsproblem Zertifikatsprüfung oder PKINIT-Ereignis bestätigt Ursache
fehlendes Anmelderecht Ereignis 0xC000015B und wirksame Richtlinie stimmen überein
Profilfehler erfolgreiche Authentifizierung und Profildienstereignis liegen nacheinander vor
Gruppenrichtlinienfehler GroupPolicy-Protokoll zeigt konkrete fehlgeschlagene Richtlinienverarbeitung
gespeichertes altes Kennwort Ereignisse zeigen wiederholte Fehlversuche von bestimmtem Gerät oder Prozess

7.10.34 Kontrollierte Maßnahmen, Risiko und Rückweg

Maßnahme Risiko Rückweg beziehungsweise Kontrolle
richtigen Benutzer oder richtige Domäne auswählen gering ursprüngliche Eingabe dokumentieren
Tastaturlayout korrigieren Fehleingabe bleibt möglich kontrollierte Testeingabe ohne Kennwortprotokollierung
Netzwerk oder Voranmelde-VPN wiederherstellen anderer Netzwerkweg wird aktiv vorherigen Netzwerkzustand dokumentieren
DNS-Konfiguration korrigieren andere Namensauflösung kann beeinflusst werden bisherige DNS-Werte sichern
falschen SRV- oder Hosteintrag korrigieren viele Clients können betroffen sein bisherigen Wert und TTL dokumentieren
Windows-Zeit kontrolliert synchronisieren Zeitsprung kann Dienste beeinflussen alte Quelle und Abweichung sichern
Konto nach Ursachenprüfung entsperren erneute sofortige Sperre möglich Sperrquelle vorher ermitteln
Kennwort nach Identitätsprüfung zurücksetzen gespeicherte Daten oder Schlüssel können betroffen sein vorgesehenes Identitätsverfahren verwenden
sicheren Kanal reparieren Computervertrauen wird verändert verwendeten DC und Ausgangsbefund dokumentieren
Computerkennwort zurücksetzen Vertrauensbeziehung kann bei Fehler weiter ausfallen lokale Administrationsmöglichkeit sicherstellen
Computer neu in Domäne aufnehmen Neustarts, Profilzuordnung und Verwaltungszustand können betroffen sein nur als letzte Maßnahme mit Wiederaufnahmeplan
AD-Replikationsfehler beheben domänenweite Auswirkungen möglich DC-spezifischen Änderungsplan verwenden
GPO korrigieren viele Benutzer oder Computer betroffen Version, Sicherung und Zielbereich dokumentieren
beschädigtes Profil reparieren Benutzerdaten können verloren gehen Profil und Daten nach Vorgabe sichern
gespeicherte alte Anmeldeinformation aktualisieren Anwendung oder Dienst kann ausfallen betroffene Abhängigkeit vorher bestimmen

Pro Diagnoseversuch sollte möglichst nur eine relevante Variable verändert werden.

7.10.35 Sicheren Kanal kontrolliert reparieren

Eine Reparatur ist nur gerechtfertigt, wenn:

Reparatur mit PowerShell:

$Credential = Get-Credential "<NETBIOS-Domäne>\<Administrationskonto>"

Test-ComputerSecureChannel `
  -Repair `
  -Server "<DC-FQDN>" `
  -Credential $Credential `
  -Verbose

Alternativ kann das lokale Computerkennwort kontrolliert zurückgesetzt werden:

$Credential = Get-Credential "<NETBIOS-Domäne>\<Administrationskonto>"

Reset-ComputerMachinePassword `
  -Server "<DC-FQDN>" `
  -Credential $Credential

Danach:

Test-ComputerSecureChannel `
  -Server "<DC-FQDN>" `
  -Verbose

Anschließend sind je nach Verfahren ein Neustart und eine erneute Online-Domänenanmeldung erforderlich.

Wichtig:

7.10.36 Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Eine erfolgreiche lokale oder zwischengespeicherte Anmeldung ist keine ausreichende Verifikation einer reparierten Domänenanmeldung.

7.10.37 Präventionsmaßnahmen

7.10.38 Typische Fehler bei der Diagnose

7.10.39 Typische Prüfungsfragen

Warum kann eine Domänenanmeldung trotz richtiger Anmeldedaten fehlschlagen?

Die Anmeldung benötigt neben gültigen Anmeldedaten unter anderem Netzwerk, DNS, einen erreichbaren Domänencontroller, ausreichende Zeitsynchronisation, ein gültiges Benutzerkonto und eine funktionierende Computervertrauensstellung.

Warum ist DNS für eine Active-Directory-Anmeldung erforderlich?

Der Client ermittelt Domänencontroller und Kerberos-Dienste über DNS-SRV-Einträge. Eine einfache Auflösung des Domänennamens reicht dafür nicht aus.

Was bedeutet die Meldung, dass keine Anmeldeserver verfügbar sind?

Der Client konnte keinen geeigneten Domänencontroller für die Anmeldeanforderung verwenden. Danach müssen DNS, DC Locator, Netzwerk, benötigte Dienste und der Zustand der Domänencontroller geprüft werden.

Was ist eine zwischengespeicherte Domänenanmeldung?

Windows verwendet lokal gespeicherte Informationen einer früheren erfolgreichen Domänenanmeldung, wenn kein Domänencontroller erreichbar ist. Dabei findet keine vollständige aktuelle Onlineprüfung des Domänenkontos statt.

Was beweist eine erfolgreiche Cache-Anmeldung nicht?

Sie beweist weder die Erreichbarkeit eines Domänencontrollers noch den aktuellen Konto-, Kennwort-, Gruppen- oder Sperrstatus.

Warum kann nach einer Kennwortänderung offline noch das alte Kennwort funktionieren?

Der lokale Computer kann noch den Nachweis der früheren erfolgreichen Domänenanmeldung gespeichert haben. Der Cache wird erst durch eine geeignete erfolgreiche Online-Anmeldung aktualisiert.

Welche Bedeutung besitzt die Uhrzeit bei Kerberos?

Kerberos verwendet Zeitstempel zum Schutz gegen Wiederholungsangriffe. Eine zu große Zeitabweichung zwischen Client und Domänencontroller kann die Authentifizierung verhindern.

Was bedeutet ein Kerberos-Fehler 0x18?

Die Kerberos-Vorauthentifizierungsinformationen waren ungültig. Häufig wurde ein falsches Kennwort verwendet. Der konkrete Versuch muss mit Benutzer, Client und Zeitpunkt korreliert werden.

Was bedeutet Ereignis 4625?

Auf dem protokollierenden System ist eine Anmeldung fehlgeschlagen. Status, Substatus, Anmeldetyp, Konto, Quelladresse und Authentifizierungspaket müssen gemeinsam ausgewertet werden.

Was bedeutet Ereignis 4740?

Ein Benutzerkonto wurde gesperrt. Das Ereignis sollte verwendet werden, um Zeitpunkt und auslösenden Computer beziehungsweise Anmeldeweg zu bestimmen.

Was ist der sichere Kanal eines Domänencomputers?

Es ist die durch das Computerkonto und sein Kennwort abgesicherte Vertrauensbeziehung zwischen Domänenmitglied und Domäne.

Wie wird der sichere Kanal zunächst geprüft?

Auf einem Mitgliedscomputer mit:

Test-ComputerSecureChannel -Verbose

Der Test sollte zuerst ohne -Repair ausgeführt werden.

Warum ist nltest /sc_verify kein rein lesender Test?

Wenn der sichere Kanal nicht funktioniert, kann der Befehl den bestehenden Kanal entfernen und neu aufbauen.

Warum sollte ein Computer nicht sofort aus der Domäne entfernt werden?

DNS-, Netzwerk-, Zeit- oder Replikationsfehler können die eigentliche Ursache sein. Eine erneute Domänenaufnahme verändert den Systemzustand, benötigt Neustarts und kann weitere Verwaltungs- oder Profilprobleme verursachen.

Warum kann die Anmeldung über einen DC funktionieren und über einen anderen fehlschlagen?

Benutzer-, Kennwort- oder Computerkontoänderungen können wegen eines Replikationsfehlers nicht auf allen Domänencontrollern den gleichen Stand besitzen.

Warum kann die Kennwortanmeldung funktionieren, während die PIN fehlschlägt?

Die Windows-Hello-PIN verwendet einen gerätegebundenen Schlüssel und ist nicht identisch mit dem Domänenkennwort.

Warum kann Ereignis 4624 vorhanden sein, obwohl der Benutzer keinen Desktop erhält?

Die Authentifizierung und Sitzungserstellung können erfolgreich gewesen sein, während Benutzerprofil, Gruppenrichtlinie, Anmeldeskript oder eine benötigte Ressource anschließend fehlschlagen.

7.10.40 Checkliste

7.10.41 Schnellreferenz

Aufgabe Befehl
aktuelle Identität whoami
Benutzer-SID whoami /user
vollständige Domänenidentität whoami /fqdn
Gruppen der Sitzung whoami /groups
Domänenmitgliedschaft Get-CimInstance Win32_ComputerSystem
Netzwerkkonfiguration ipconfig /all
DNS-Server Get-DnsClientServerAddress
LDAP-SRV-Eintrag Resolve-DnsName _ldap._tcp.dc._msdcs.<Domäne> -Type SRV
Kerberos-SRV-Eintrag Resolve-DnsName _kerberos._tcp.<Domäne> -Type SRV
DC ermitteln nltest /dsgetdc:<Domäne>
DC neu ermitteln nltest /dsgetdc:<Domäne> /force
AD-Standort nltest /dsgetsite
DC-Liste nltest /dclist:<Domäne>
DNS-TCP-Test Test-NetConnection <DC> -Port 53
Kerberos-TCP-Test Test-NetConnection <DC> -Port 88
LDAP-TCP-Test Test-NetConnection <DC> -Port 389
SMB-TCP-Test Test-NetConnection <DC> -Port 445
RPC Endpoint Mapper Test-NetConnection <DC> -Port 135
Zeitstatus w32tm /query /status
Zeitquelle w32tm /query /source
Zeitvergleich w32tm /stripchart /computer:<DC> /dataonly /samples:5
Benutzerkonto Get-ADUser <Benutzer> -Properties *
gesperrte Konten Search-ADAccount -LockedOut -UsersOnly
sicherer Kanal, nur Test Test-ComputerSecureChannel -Verbose
letzter Netlogon-Kanalstatus nltest /sc_query:<Domäne>
Kerberos-Tickets klist tickets
Kerberos-TGT klist tgt
Anmeldefehler Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625}
DC-Gesundheit dcdiag /v
DC-DNS-Test dcdiag /test:DNS /v
Replikationsübersicht repadmin /replsummary
Replikationsdetails repadmin /showrepl
Gruppenrichtlinienergebnis gpresult /r

Ändernde Befehle, die nicht als erste Diagnose verwendet werden dürfen:

Test-ComputerSecureChannel -Repair
Reset-ComputerMachinePassword
nltest /sc_verify
nltest /sc_reset
nltest /sc_change_pwd
klist purge
w32tm /resync
gpupdate /force

7.10.42 Quellen

Offizielle Microsoft-Dokumentation

Standards

Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.

7.11 DNS-Leistung und fehlerhafte Reverse-Lookups

Kurz erklärt

Eine DNS-Abfrage kann grundsätzlich funktionieren und trotzdem langsam sein. Ebenso beweist ein fehlender Reverse-Lookup nicht automatisch, dass die normale Namensauflösung gestört ist.

Für eine saubere Diagnose müssen Abfragerichtung, verwendeter DNS-Server, Antwortcode, Antwortzeit, Cachezustand, Rekursion, Weiterleitung, Transportweg und Zonenverantwortung getrennt untersucht werden.

7.11.1 Ziel der Diagnose

Bei DNS-Leistungsproblemen müssen folgende Fragen beantwortet werden:

Ziel ist nicht nur eine erfolgreiche Einzelabfrage, sondern eine reproduzierbare und ausreichend schnelle Namensauflösung über den vorgesehenen DNS-Pfad.

7.11.2 Typische Störungsbilder

7.11.3 Vorwärts- und Rückwärtsauflösung unterscheiden

Abfragerichtung Eingabe Gesuchter Datensatz Ergebnis
Vorwärtsauflösung IPv4 Hostname A IPv4-Adresse
Vorwärtsauflösung IPv6 Hostname AAAA IPv6-Adresse
Rückwärtsauflösung IPv4 IPv4-Adresse PTR unter in-addr.arpa Hostname
Rückwärtsauflösung IPv6 IPv6-Adresse PTR unter ip6.arpa Hostname

Beispiel:

host25.example.test → 192.0.2.25

Dies ist eine Vorwärtsauflösung über einen A-Eintrag.

192.0.2.25 → host25.example.test

Dies ist eine Rückwärtsauflösung über einen PTR-Eintrag.

A-, AAAA- und PTR-Einträge sind getrennte DNS-Datensätze in unterschiedlichen Zonen. Ein vorhandener A- oder AAAA-Eintrag erzeugt deshalb nicht automatisch einen PTR-Eintrag, sofern kein entsprechend konfigurierter Aktualisierungsprozess vorhanden ist.

7.11.4 Aufbau einer IPv4-Rückwärtsauflösung

Für IPv4 werden die Oktette der Adresse umgekehrt und mit in-addr.arpa ergänzt.

Beispiel:

192.0.2.25

Daraus entsteht der Abfragename:

25.2.0.192.in-addr.arpa.

Der zugehörige PTR-Eintrag kann auf folgenden Namen zeigen:

host25.example.test.

Für das Netz 192.0.2.0/24 lautet die typische Reverse-Lookup-Zone:

2.0.192.in-addr.arpa

Der Knoten für die Adresse 192.0.2.25 lautet innerhalb dieser Zone:

25

Bei Adressbereichen, die nicht an einer Oktettgrenze delegiert werden, kann eine klassenlose Delegation nach RFC 2317 erforderlich sein. Der Zonenaufbau darf dann nicht allein aus der Subnetzmaske abgeleitet werden, sondern muss mit der tatsächlichen Delegation des Adressbereichs übereinstimmen.

7.11.5 Aufbau einer IPv6-Rückwärtsauflösung

IPv6-Rückwärtsauflösungen verwenden die Zone ip6.arpa.

Dabei wird:

  1. die IPv6-Adresse vollständig ausgeschrieben;
  2. jede Hexadezimalstelle einzeln betrachtet;
  3. die Reihenfolge aller Hexadezimalstellen umgekehrt;
  4. zwischen jeder Stelle ein Punkt eingefügt;
  5. ip6.arpa angehängt.

Die Delegation erfolgt auf Basis einzelner Hexadezimalstellen, sogenannter Nibbles. Eine IPv6-Reverse-Zone muss deshalb anhand des tatsächlich delegierten IPv6-Präfixes erstellt werden.

IPv6-Reverse-Namen dürfen nicht durch einfaches Umkehren der durch Doppelpunkte getrennten Adressblöcke gebildet werden.

7.11.6 Bedeutung eines fehlenden Reverse-Lookups

Ein fehlender PTR-Eintrag bedeutet zunächst nur, dass für die IP-Adresse kein entsprechender Name über Reverse-DNS ermittelt werden konnte.

Das beweist nicht automatisch:

Reverse-Lookups werden unter anderem verwendet von:

Eine Anwendung kann bei einem fehlenden PTR-Eintrag ohne Verzögerung weiterarbeiten. Eine deutliche Verzögerung entsteht eher dann, wenn die Reverse-Abfrage nicht eindeutig negativ beantwortet wird, sondern in Timeouts, fehlerhaften Delegationen oder nicht erreichbaren DNS-Servern endet.

7.11.7 nslookup zeigt den DNS-Server als „Unknown“

Eine typische Ausgabe kann folgendermaßen aussehen:

Server:  UnKnown
Address: 192.0.2.53

Das bedeutet häufig, dass für die IP-Adresse des verwendeten DNS-Servers kein auflösbarer PTR-Eintrag vorhanden ist.

Diese Meldung beweist nicht, dass der DNS-Server keine anderen Anfragen beantworten kann.

Zur Abgrenzung müssen kontrollierte Abfragen durchgeführt werden:

nslookup host25.example.test 192.0.2.53

nslookup 192.0.2.25 192.0.2.53

PTR des DNS-Servers selbst prüfen:

nslookup 192.0.2.53 192.0.2.53

Wenn die erste Abfrage erfolgreich ist, funktioniert die getestete Vorwärtsauflösung trotz der Anzeige Unknown. Der fehlende PTR-Eintrag des DNS-Servers bleibt dennoch ein zu prüfender Konfigurationsbefund.

7.11.8 DNS-Antworten richtig einordnen

Ergebnis Bedeutung Einordnung
NOERROR mit Antwort Abfrage wurde erfolgreich beantwortet Datensatz und Inhalt prüfen
NOERROR ohne gesuchten Datensatz Name kann existieren, der angefragte Datensatztyp fehlt häufig als NODATA bezeichnet
NXDOMAIN abgefragter DNS-Name existiert laut DNS-Antwort nicht Zone, Name und negative Zwischenspeicherung prüfen
SERVFAIL Server konnte keine verwertbare Antwort erzeugen Weiterleitung, Delegation, DNSSEC und Serverprotokolle prüfen
REFUSED Server lehnt die Abfrage aufgrund seiner Konfiguration oder Richtlinie ab Rekursion, ACL, Richtlinie und Abfragequelle prüfen
FORMERR DNS-Nachricht konnte nicht korrekt verarbeitet werden Client, Server, Netzwerkgerät und Paketformat prüfen
Timeout innerhalb der Wartezeit kam keine verwertbare Antwort Netzwerk, Transport, Serverlast und nachgelagerte Server prüfen
Antwort mit TC UDP-Antwort wurde abgeschnitten erneuter Versuch über TCP erforderlich
falsche Adresse oder falscher PTR DNS antwortet, aber mit unerwarteten Daten Zone, Replikation, Cache und Datensatz prüfen

Ein Timeout ist kein DNS-Antwortcode. Er bedeutet, dass der Client innerhalb seiner Wartezeit keine verwendbare DNS-Antwort erhalten hat.

7.11.9 Ausgangszustand dokumentieren

Vor Änderungen sind mindestens folgende Informationen zu erfassen:

DNS-Caches dürfen nicht gelöscht werden, bevor der ursprüngliche Cachezustand und die fehlerhafte Antwort dokumentiert wurden.

7.11.10 Verwendete DNS-Konfiguration prüfen

Windows

ipconfig /all

Get-DnsClientServerAddress

Get-DnsClient

Linux

cat /etc/resolv.conf

Bei Systemen mit systemd-resolved zusätzlich:

resolvectl status

macOS

scutil --dns

Zu prüfen sind:

Die Datei /etc/resolv.conf kann bei dynamisch verwalteten Linux-Systemen nur auf einen lokalen Stub-Resolver verweisen. Bei systemd-resolved muss deshalb zusätzlich dessen tatsächliche Schnittstellenkonfiguration geprüft werden.

7.11.11 Lokale Namensquellen und Resolverpfad berücksichtigen

Eine Anwendung muss nicht zwingend direkt den konfigurierten DNS-Server abfragen. Je nach Betriebssystem und Anwendung können vorher oder zusätzlich verwendet werden:

Hosts-Dateien:

Betriebssystem Pfad
Windows C:\Windows\System32\drivers\etc\hosts
Linux /etc/hosts
macOS /etc/hosts

Eine erfolgreiche Anwendungssuche beweist nicht, dass DNS verwendet wurde. Umgekehrt beweist eine erfolgreiche direkte DNS-Abfrage nicht, dass die Anwendung denselben Resolverpfad benutzt.

7.11.12 Split-DNS, VPN und NRPT prüfen

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

Beispiel:

app.example.test → interne IP über Unternehmens-DNS
app.example.test → öffentliche IP über öffentlichen DNS

Unter Windows können VPN-Profile über die Name Resolution Policy Table festlegen, welche Namensräume an bestimmte DNS-Server gesendet werden.

Wirksame NRPT-Richtlinien anzeigen:

Get-DnsClientNrptPolicy

Konfigurierte NRPT-Regeln anzeigen:

Get-DnsClientNrptRule

Zu prüfen sind:

nslookup verwendet für solche Tests nicht zwingend denselben Windows-Resolverpfad wie Anwendungen, die die Windows-DNS-API und NRPT nutzen. Für die Prüfung von NRPT sollte deshalb zusätzlich Resolve-DnsName verwendet werden.

7.11.13 Verschlüsseltes DNS mit DoH und DoT abgrenzen

DNS over HTTPS und DNS over TLS verändern den Transportweg der DNS-Abfrage.

Dadurch können klassische Tests über UDP- oder TCP-Port 53 erfolgreich sein, obwohl der verschlüsselte DNS-Pfad fehlschlägt – oder umgekehrt.

Windows-DNS-Clientzustand anzeigen:

netsh dnsclient show state

Globale Einstellungen anzeigen:

netsh dnsclient show global

Konfigurierte verschlüsselte DNS-Server anzeigen:

netsh dnsclient show encryption

Zu prüfen sind:

Für die DNS-Serverrolle unterstützt Microsoft DoH ab Windows Server 2025 mit dem in der Microsoft-Bereitstellungsdokumentation genannten Sicherheitsupdate KB5094125 vom Juni 2026 oder einem späteren Update.

Serverkonfiguration auf einem unterstützten System anzeigen:

Get-DnsServerEncryptionProtocol

DoH schützt den Transport zwischen DoH-Client und DNS-Server. Nachgelagerte Abfragen an Forwarder oder autoritative DNS-Server, Zonentransfers und dynamische Updates werden dadurch nicht automatisch verschlüsselt.

DoH und DNSSEC erfüllen unterschiedliche Aufgaben:

7.11.14 Vorwärtsauflösung gezielt testen

Windows PowerShell

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

AAAA-Eintrag:

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type AAAA `
  -Server "192.0.2.53" `
  -DnsOnly

Windows Eingabeaufforderung

nslookup host25.example.test 192.0.2.53

Linux und macOS

dig @192.0.2.53 host25.example.test A

dig @192.0.2.53 host25.example.test AAAA

Entscheidend ist, den DNS-Server ausdrücklich anzugeben. Andernfalls können unterschiedliche Resolver, VPN-Regeln oder Cachezustände zu nicht vergleichbaren Ergebnissen führen.

7.11.15 Rückwärtsauflösung gezielt testen

Windows PowerShell

Resolve-DnsName `
  -Name "192.0.2.25" `
  -Type PTR `
  -Server "192.0.2.53" `
  -DnsOnly

Windows Eingabeaufforderung

nslookup 192.0.2.25 192.0.2.53

Linux und macOS

dig @192.0.2.53 -x 192.0.2.25

Kompakte Ausgabe mit Antwort und Statistik:

dig @192.0.2.53 -x 192.0.2.25 +noall +answer +comments +stats

Direkte Abfrage des vollständigen Reverse-Namens:

dig @192.0.2.53 25.2.0.192.in-addr.arpa PTR

Zu dokumentieren sind:

7.11.16 A-, AAAA-, CNAME-, PTR- und SRV-Probleme abgrenzen

Datensatz Aufgabe Typischer Fehler
A Name zu IPv4-Adresse falsche oder veraltete IPv4-Adresse
AAAA Name zu IPv6-Adresse falsche oder nicht erreichbare IPv6-Adresse
CNAME Alias zu anderem DNS-Namen fehlerhaftes Ziel oder lange Alias-Kette
PTR IP-Adresse zu Name fehlender, falscher oder veralteter Reverse-Eintrag
SRV Dienst zu Zielhost und Port falsches Ziel, falscher Port oder fehlender Zielhost

CNAME prüfen:

Resolve-DnsName `
  -Name "alias.example.test" `
  -Type CNAME `
  -Server "192.0.2.53" `
  -DnsOnly

SRV prüfen:

Resolve-DnsName `
  -Name "_service._tcp.example.test" `
  -Type SRV `
  -Server "192.0.2.53" `
  -DnsOnly

Mit dig:

dig @192.0.2.53 alias.example.test CNAME

dig @192.0.2.53 _service._tcp.example.test SRV

Bei CNAME- und SRV-Datensätzen muss zusätzlich geprüft werden, ob der zurückgegebene Zielname über A oder AAAA auflösbar und anschließend über den angegebenen Dienstport erreichbar ist.

Ein erfolgreicher SRV-Lookup beweist nicht, dass der veröffentlichte Dienst erreichbar ist.

7.11.17 Antwortzeit reproduzierbar messen

Ein einzelner Messwert reicht nicht aus. Mindestens folgende Fälle müssen getrennt betrachtet werden:

Linux und macOS

dig zeigt die DNS-Abfragezeit als Query time an:

dig @192.0.2.53 host25.example.test A +stats

TCP erzwingen:

dig @192.0.2.53 host25.example.test A +tcp +stats

Windows PowerShell

Measure-Command {
    Resolve-DnsName `
      -Name "host25.example.test" `
      -Type A `
      -Server "192.0.2.53" `
      -DnsOnly
}

TCP erzwingen:

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly `
  -TcpOnly

Measure-Command misst den gesamten PowerShell-Befehlsablauf und nicht ausschließlich die reine DNS-Übertragungszeit. Die Werte eignen sich deshalb vor allem zum kontrollierten Vergleich unter denselben Bedingungen.

7.11.18 Kalte und zwischengespeicherte Abfragen unterscheiden

Eine erste rekursive Abfrage kann langsamer sein, weil der DNS-Server weitere Server kontaktieren muss. Eine Wiederholung kann aus einem Cache beantwortet werden.

Beobachtung Mögliche Einordnung
erste Abfrage langsam, Wiederholung schnell Server-, Client- oder Anwendungscache wirkt
jede Abfrage langsam Netzwerk, Serverlast, Weiterleitung oder autoritativen Pfad prüfen
nur nicht vorhandene Namen langsam negative Antworten, fehlerhafte Delegation oder Timeoutpfad prüfen
nur externe Namen langsam Rekursion, Forwarder oder Internetpfad prüfen
nur interne Namen langsam interne Zone, Delegation, AD-Replikation oder Standort prüfen
nur Reverse-Lookups langsam Reverse-Zone, Delegation und PTR-Pfad prüfen
autoritativer Server schnell, rekursiver Server langsam Rekursion, Cache oder Forwarder prüfen
UDP langsam oder fehlerhaft, TCP erfolgreich Firewall, Fragmentierung, EDNS oder Netzwerkpfad prüfen

Ein schneller Cachetreffer beweist nicht, dass der vollständige rekursive beziehungsweise autoritative Pfad funktioniert.

7.11.19 Windows-DNS-Clientcache prüfen

Cacheinhalt anzeigen:

ipconfig /displaydns

Alternativ:

Get-DnsClientCache

Zu prüfen sind:

Cache löschen:

Clear-DnsClientCache

Alternativ:

ipconfig /flushdns

Das Löschen des Clientcaches verändert den Ausgangszustand. Es darf erst nach Dokumentation und nur als kontrollierter Vergleich erfolgen.

7.11.20 TTL und negative Zwischenspeicherung berücksichtigen

Die TTL bestimmt, wie lange ein Datensatz zwischengespeichert werden darf.

Eine sehr niedrige TTL kann:

Eine sehr hohe TTL kann:

Auch negative Antworten werden zwischengespeichert. Deshalb kann ein Name nach dem nachträglichen Anlegen des Datensatzes zunächst weiterhin als nicht vorhanden erscheinen.

Zu prüfen sind:

Caches dürfen nicht routinemäßig geleert werden, um eine falsche TTL- oder Zonenplanung dauerhaft zu umgehen.

7.11.21 DNS über UDP und TCP abgrenzen

Klassische DNS-Abfragen verwenden häufig UDP-Port 53. TCP-Port 53 wird unter anderem benötigt:

Windows-TCP-Test:

Test-NetConnection "192.0.2.53" -Port 53

Dieser Befehl prüft ausschließlich TCP. Er beweist nicht, dass UDP-Port 53 funktioniert.

Ein echter UDP-DNS-Test erfolgt durch eine normale DNS-Abfrage:

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

Vergleich über TCP:

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly `
  -TcpOnly

Wenn UDP-Abfragen scheitern und TCP-Abfragen funktionieren, sind unter anderem Firewallregeln, Paketverlust, Fragmentierung, EDNS-Verarbeitung, MTU und zwischengeschaltete Netzwerkgeräte zu prüfen.

7.11.22 EDNS, MTU, Fragmentierung und DNSSEC prüfen

EDNS ermöglicht unter anderem größere DNS-Antworten über UDP. Auf Netzwerkpfaden mit ungeeigneter MTU oder fehlerhafter Fragmentbehandlung können deshalb kleine Abfragen funktionieren, während größere Antworten ausfallen.

Typische Hinweise:

DNSSEC-Daten anfordern:

Resolve-DnsName `
  -Name "example.com" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly `
  -DnssecOk

Mit dig:

dig @192.0.2.53 example.com A +dnssec

Vergleich über TCP:

dig @192.0.2.53 example.com A +dnssec +tcp

EDNS testweise unterdrücken:

dig @192.0.2.53 example.com A +noedns

Zu beachten ist:

7.11.23 Autoritative Antwort, Rekursion und Weiterleitung unterscheiden

Ein DNS-Server kann eine Antwort liefern:

Für eine saubere Diagnose sind mindestens drei Ebenen zu vergleichen:

  1. Abfrage über den vom Client verwendeten DNS-Server;
  2. Abfrage über einen alternativen vorgesehenen DNS-Server;
  3. Abfrage über den autoritativen DNS-Server der betroffenen Zone.

Wenn der autoritative Server schnell und korrekt antwortet, der rekursive Server jedoch langsam ist, liegt die Ursache wahrscheinlich bei Rekursion, Cache, Weiterleitung oder Delegationspfad.

7.11.24 Delegation der Reverse-Zone prüfen

Für eine Rückwärtsauflösung muss die DNS-Hierarchie auf den zuständigen autoritativen Server verweisen.

Linux und macOS

dig -x 192.0.2.25 +trace

Zuständige Nameserver der Reverse-Zone prüfen:

dig 2.0.192.in-addr.arpa NS

Zu prüfen sind:

Eine lokal erstellte Reverse-Zone ersetzt bei öffentlichen Adressen nicht die Delegation durch den Eigentümer beziehungsweise Provider des IP-Adressbereichs.

7.11.25 Private und öffentliche Reverse-Zonen unterscheiden

Private IP-Adressen

Für interne private Netze kann die Organisation die Reverse-Zonen auf ihren internen DNS-Servern verwalten.

Zu prüfen sind:

Öffentliche IP-Adressen

Der PTR-Eintrag einer öffentlichen IP-Adresse wird normalerweise durch den Betreiber verwaltet, dem der entsprechende Adressbereich delegiert wurde.

Ein PTR-Eintrag für eine öffentliche IP-Adresse kann daher nicht allein dadurch veröffentlicht werden, dass in der normalen Forward-Zone der eigenen Domain ein Datensatz angelegt wird.

Zu klären sind:

7.11.26 Vorwärts- und Rückwärtskonsistenz prüfen

Beispiel für einen konsistenten Zustand:

host25.example.test. A 192.0.2.25

25.2.0.192.in-addr.arpa. PTR host25.example.test.

Anschließend wird der PTR-Zielname wieder vorwärts aufgelöst:

host25.example.test. A 192.0.2.25

Prüfschritte:

  1. IP-Adresse rückwärts auflösen.
  2. PTR-Zielnamen dokumentieren.
  3. PTR-Zielnamen über A und AAAA auflösen.
  4. Prüfen, ob die ursprüngliche IP-Adresse in den Ergebnissen enthalten ist.
  5. Alle beteiligten autoritativen DNS-Server vergleichen.

Mögliche Befunde:

Befund Einordnung
kein PTR vorhanden Reverse-Eintrag fehlt oder Zone ist nicht erreichbar
PTR zeigt auf alten Hostnamen veralteter Datensatz
PTR-Zielname existiert nicht unvollständige DNS-Konfiguration
PTR-Zielname zeigt auf andere IP Vorwärts- und Rückwärtsdaten stimmen nicht überein
mehrere PTR-Einträge technisch möglich, kann Anwendungen jedoch unterschiedlich beeinflussen
mehrere A- oder AAAA-Adressen kann bei Clustern, Load Balancing oder Mehrfachanbindung vorgesehen sein
verschiedene DNS-Server liefern verschiedene PTR-Werte Replikation, Zonentransfer oder uneinheitliche Konfiguration prüfen

Eine Vorwärts-Rückwärts-Konsistenz ist nicht für jede DNS-Anwendung zwingend vorgeschrieben. Bestimmte Mail-, Sicherheits- oder Identitätsprüfungen können sie jedoch voraussetzen.

7.11.27 Windows-DNS-Serverdienst und Zonen prüfen

Auf dem DNS-Server:

Get-Service -Name DNS

Zonen anzeigen:

Get-DnsServerZone

Nur Reverse-Lookup-Zonen:

Get-DnsServerZone |
    Where-Object { $_.IsReverseLookupZone }

Zustand einer bestimmten Zone:

Get-DnsServerZone `
  -Name "2.0.192.in-addr.arpa"

Zu prüfen sind:

Ein laufender DNS-Dienst beweist nicht, dass eine bestimmte Zone korrekt geladen oder erreichbar ist.

7.11.28 PTR-Datensätze auf dem Windows-DNS-Server prüfen

Alle PTR-Einträge einer Zone:

Get-DnsServerResourceRecord `
  -ZoneName "2.0.192.in-addr.arpa" `
  -RRType PTR

Bestimmten Eintrag prüfen:

Get-DnsServerResourceRecord `
  -ZoneName "2.0.192.in-addr.arpa" `
  -Name "25" `
  -RRType PTR

Von einem bestimmten DNS-Server lesen:

Get-DnsServerResourceRecord `
  -ComputerName "dns01.example.test" `
  -ZoneName "2.0.192.in-addr.arpa" `
  -Name "25" `
  -RRType PTR

Zu vergleichen sind:

Ein fehlender beziehungsweise als statisch dargestellter Zeitstempel kann auf einen statisch angelegten Datensatz hinweisen. Solche Datensätze werden nicht wie dynamisch gealterte Datensätze behandelt.

7.11.29 Rekursion, Forwarder und Cache des Windows-DNS-Servers prüfen

Allgemeine Forwarder:

Get-DnsServerForwarder

Rekursionseinstellungen:

Get-DnsServerRecursion

Root Hints:

Get-DnsServerRootHint

Cacheeinstellungen:

Get-DnsServerCache

Zu prüfen sind:

Nicht erreichbare Forwarder können Verzögerungen verursachen, bevor ein weiterer Forwarder oder ein alternativer Auflösungspfad verwendet wird.

7.11.30 DNS-Serverstatistiken auswerten

Aggregierte Statistiken:

Get-DnsServerStatistics

Statistiken einer bestimmten Zone:

Get-DnsServerStatistics `
  -ZoneName "2.0.192.in-addr.arpa"

Die genaue Struktur der Ausgabe hängt von der Windows-Server-Version ab. Zu untersuchen sind unter anderem:

Statistiken dürfen nicht ohne vorherige Sicherung des Ausgangswerts zurückgesetzt werden.

Das Cmdlet kann bei zonenbezogener Verwendung mit -Clear Zähler verändern. Diese Option ist deshalb keine rein lesende Diagnosemaßnahme.

7.11.31 Leistungsindikatoren überwachen

Verfügbare DNS-Leistungsindikatoren anzeigen:

Get-Counter -ListSet DNS

Beispiel für empfangene DNS-Abfragen und gesendete Antworten:

Get-Counter `
  '\DNS\Total Query Received/sec',
  '\DNS\Total Response Sent/sec' `
  -SampleInterval 2 `
  -MaxSamples 10

DNS-Prozess überwachen:

Get-Counter `
  '\Process(dns)\% Processor Time',
  '\Process(dns)\Working Set' `
  -SampleInterval 2 `
  -MaxSamples 10

Die Namen der Leistungsindikatoren können auf lokalisierten Windows-Systemen abweichen. Deshalb sollte zuerst Get-Counter -ListSet DNS verwendet werden.

Zu korrelieren sind:

Eine hohe Anzahl von Abfragen ist allein kein Fehler. Entscheidend sind Baseline, Hardware, Abfrageart, Cachetreffer, Rekursion, Fehlerquote und Antwortzeit.

7.11.32 Protokollierung kontrolliert einsetzen

Windows DNS Server stellt unter anderem folgende Ereignisprotokolle bereit:

Applications and Services Logs
└─ Microsoft
   └─ Windows
      └─ DNS-Server
         ├─ Audit
         └─ Analytical

Das Audit-Protokoll erfasst administrative und sicherheitsrelevante DNS-Vorgänge. Das analytische Protokoll kann detaillierte Abfrageinformationen liefern, ist jedoch standardmäßig nicht aktiviert.

Zu beachten ist:

Microsoft weist darauf hin, dass analytische DNS-Protokollierung bei sehr hohen Abfrageraten messbare Leistungseinflüsse verursachen kann. Deshalb muss sie mit den Leistungswerten des Servers korreliert werden.

7.11.33 Netzwerkaufzeichnung gezielt verwenden

Wenn DNS-Abfragen weiterhin unklar bleiben, kann eine zeitlich und inhaltlich begrenzte Netzwerkaufzeichnung erforderlich sein.

Zu prüfen sind:

DNS-Pakete können interne Hostnamen, Dienstnamen und andere schützenswerte Informationen enthalten. Aufzeichnungen müssen deshalb nach Sicherheits- und Datenschutzvorgaben behandelt werden.

7.11.34 Dynamische DNS-Aktualisierung prüfen

Windows-Clients können ihre DNS-Namen dynamisch registrieren:

Register-DnsClient

Alternativ:

ipconfig /registerdns

Diese Befehle lösen eine dynamische Aktualisierung aus und verändern damit möglicherweise den DNS-Zustand. Vorher sind vorhandene Datensätze, Zeitstempel und Ereignisse zu dokumentieren.

Zu prüfen sind:

Das wiederholte Ausführen von Register-DnsClient behebt keine fehlende Reverse-Zone, falsche Berechtigungen oder fehlerhafte DHCP-DNS-Einstellungen.

7.11.35 DHCP und PTR-Registrierung prüfen

Bei dynamisch vergebenen IP-Adressen kann der DHCP-Server DNS-Einträge im Auftrag des Clients aktualisieren.

Zu untersuchen sind:

Mögliche Fehlerbilder:

7.11.36 Aging und Scavenging berücksichtigen

Aging und Scavenging können veraltete dynamische DNS-Datensätze entfernen. Die Funktion beinhaltet Löschvorgänge und muss deshalb kontrolliert geplant werden.

Zu prüfen sind:

Scavenging sollte nicht spontan aktiviert oder manuell erzwungen werden, nur weil einzelne PTR-Einträge veraltet sind. Eine falsche Konfiguration kann gültige DNS-Datensätze löschen.

7.11.37 Active-Directory-integrierte DNS-Zonen prüfen

Bei AD-integrierten Zonen können unterschiedliche Antworten auf Replikationsprobleme hinweisen.

DNS-Test für einen Domänencontroller:

dcdiag /test:DNS /v /s:<DC-Name>

Replikationsübersicht:

repadmin /replsummary

Replikationsdetails:

repadmin /showrepl

Zu prüfen sind:

Eine erzwungene Replikation ist keine erste Diagnosemaßnahme. Zuerst müssen Richtung, Partner, Fehlercode und Ursache bestimmt werden.

7.11.38 Systematischer Diagnoseablauf

  1. Störungsbild dokumentieren
    Client, Anwendung, Name oder IP-Adresse, Uhrzeit und genaue Verzögerung erfassen.

  2. Abfragerichtung bestimmen
    Vorwärtsauflösung, Rückwärtsauflösung oder beide unterscheiden.

  3. Umfang bestimmen
    Einzelner Client, Anwendung, Standort, Zone oder alle Systeme unterscheiden.

  4. Resolverpfad erfassen
    DNS-Server, VPN, Suchsuffixe, Hosts-Datei, NRPT, DoH, DoT und lokale Resolver prüfen.

  5. Abfrage reproduzieren
    Den vorgesehenen DNS-Server ausdrücklich angeben.

  6. Antwortcode dokumentieren
    NOERROR, NXDOMAIN, SERVFAIL, REFUSED oder Timeout unterscheiden.

  7. Antwortzeit messen
    Erste und wiederholte Abfrage getrennt messen.

  8. Vorwärts- und Reverse-Abfrage vergleichen
    A beziehungsweise AAAA und PTR unabhängig testen.

  9. Alternativen DNS-Server testen
    Unterschiedliche Serverantworten dokumentieren.

  10. UDP und TCP vergleichen
    Transportabhängige Fehler abgrenzen.

  11. DoH oder DoT abgrenzen
    Verschlüsselten und klassischen DNS-Pfad getrennt prüfen.

  12. Autoritativen Server bestimmen
    Delegation und zuständige Zone prüfen.

  13. Direkte autoritative Abfrage durchführen
    Rekursion und Forwarder vom Zonenzustand trennen.

  14. PTR-Datensatz prüfen
    Zielname, TTL, Zeitstempel und Eigentümer auswerten.

  15. Vorwärts-Rückwärts-Konsistenz prüfen
    PTR-Zielnamen erneut über A und AAAA auflösen.

  16. Weitere Datensatztypen prüfen
    CNAME- oder SRV-Abhängigkeiten berücksichtigen.

  17. Cachezustand prüfen
    Client-, Server- und Anwendungscache unterscheiden.

  18. Forwarder und Rekursion prüfen
    Besonders bei langsamen externen oder bedingt weitergeleiteten Zonen.

  19. EDNS, MTU und DNSSEC prüfen
    Wenn kleine Antworten funktionieren und größere Antworten ausfallen.

  20. Serverleistung prüfen
    Abfragerate, CPU, Speicher, Fehler und Timeouts korrelieren.

  21. Dynamische Aktualisierung prüfen
    Client, DHCP, Berechtigungen und Zonenrichtlinie untersuchen.

  22. Aging und Scavenging prüfen
    Veraltete oder unerwartet gelöschte Datensätze abgrenzen.

  23. AD-Replikation prüfen
    Wenn DNS-Server unterschiedliche Antworten liefern.

  24. Hypothese formulieren
    Erwarteten Befund und möglichen Gegenbeweis festlegen.

  25. Eine kontrollierte Maßnahme durchführen
    Risiko, Rückweg und Erfolgskriterium dokumentieren.

  26. Erneut unter denselben Bedingungen messen
    Antwort, Code und Zeit mit dem Ausgangswert vergleichen.

  27. Gesamten DNS-Pfad verifizieren
    Client, rekursiven Server, autoritativen Server und Anwendung prüfen.

  28. Präventionsmaßnahme dokumentieren
    Ursache und dauerhafte Verbesserung festhalten.

7.11.39 Befundmatrix

Befund Mögliche Erklärung Nächster Nachweis
nslookup zeigt Unknown, andere Abfragen funktionieren PTR des DNS-Servers fehlt DNS-Server-IP rückwärts abfragen
Vorwärtsauflösung funktioniert, Reverse nicht PTR oder Reverse-Zone fehlt PTR-Abfrage und Zonenprüfung
Reverse-Abfrage endet sofort mit NXDOMAIN Name oder Zone meldet Nichtvorhandensein Autorität und SOA der Antwort prüfen
Reverse-Abfrage läuft in Timeout Server, Delegation oder Netzwerkpfad antwortet nicht autoritative Server und Paketpfad prüfen
PTR zeigt auf alten Hostnamen veralteter statischer oder dynamischer Eintrag Lease, Zeitstempel und Datensatzeigentümer prüfen
PTR-Zielname besitzt keinen A-/AAAA-Eintrag unvollständige DNS-Konfiguration Zielnamen vorwärts auflösen
PTR-Zielname zeigt auf andere IP Vorwärts-Rückwärts-Abweichung vorgesehene Mehrfachadressierung prüfen
erste Abfrage langsam, zweite schnell Cacheeffekt kalte und warme Messung vergleichen
jede externe Abfrage langsam Forwarder oder Rekursion direkte Abfragen gegen Forwarder und Autorität
nur interne Zone langsam interne Delegation oder AD-DNS autoritative interne Server vergleichen
nur ein DNS-Server liefert falsche Antwort lokaler Cache, Zone oder Replikation Server direkt vergleichen
UDP fehlerhaft, TCP erfolgreich Firewall, EDNS, Fragmentierung oder MTU Transportvergleich und Netzwerkaufzeichnung
SERVFAIL nur bei signierter Zone DNSSEC-Validierung oder Delegation Validierungskette und Serverereignisse prüfen
REFUSED Rekursion oder Richtlinie verweigert Abfrage Serverrichtlinie und Quellnetz prüfen
A-Eintrag vorhanden, PTR fehlt Reverse-Zone oder Updatepfad fehlt DHCP-, Client- und Zonenupdate prüfen
PTR wird nach IP-Wechsel nicht entfernt Aging, Scavenging oder DHCP-Bereinigung Leaseablauf, Zeitstempel und Zonenalterung
unterschiedliche Antworten je DC AD-Replikation oder uneinheitliche Zone repadmin, dcdiag und direkte Abfragen
Auflösung über IP schnell, über Namen langsam DNS oder nachgelagerte Namensprüfung direkte DNS-Zeit und Anwendungspfad vergleichen
öffentliche IP besitzt keinen PTR Provider hat keinen Reverse-Eintrag gesetzt Betreiber des IP-Präfixes ermitteln
neuer Datensatz bleibt zunächst unsichtbar positiver oder negativer Cache TTL und Cacheebenen prüfen
nslookup und Anwendung liefern verschiedene Ergebnisse NRPT, DoH oder anwendungseigener Resolver tatsächlichen Resolverpfad bestimmen
nur große Antworten schlagen fehl EDNS-, MTU- oder Fragmentierungsproblem UDP/TCP und Antwortgrößen vergleichen
SRV wird gefunden, Dienst funktioniert nicht Zielhost, Port oder Dienst fehlerhaft SRV-Ziel und Dienstport prüfen
CNAME wird aufgelöst, Zielname jedoch nicht fehlerhaftes Aliasziel CNAME-Kette vollständig prüfen
klassisches DNS funktioniert, DoH nicht Zertifikat, HTTPS-Port oder DoH-Endpunkt DoH-Zustand und TLS-Verbindung prüfen

7.11.40 Ursachen und erforderliche Nachweise

Mögliche Ursache Erforderlicher Nachweis
falscher DNS-Server Clientkonfiguration und direkte Abfragen bestätigen abweichenden Resolver
falsches DNS-Suffix Resolverkonfiguration zeigt unerwartete Suchdomäne
Hosts-Datei überschreibt DNS lokaler Eintrag liefert abweichende Zuordnung
anwendungseigener DNS-Cache Anwendung liefert trotz korrektem Systemtest alten Wert
NRPT-Fehler wirksame Richtlinie leitet den Namensraum an falschen Resolver
fehlerhafter Split-DNS-Pfad interne und externe Resolver liefern unbeabsichtigt verschiedene Antworten
DoH- oder DoT-Fehler verschlüsselter Pfad scheitert bei funktionierendem klassischem DNS
fehlende Reverse-Zone zuständiger DNS-Server besitzt oder erreicht die Zone nicht
fehlender PTR-Eintrag autoritative PTR-Abfrage liefert keinen Datensatz
falscher PTR-Eintrag autoritative Antwort enthält unerwarteten Zielnamen
fehlerhafte Delegation übergeordnete Zone verweist auf falsche oder nicht erreichbare Server
fehlerhafte RFC-2317-Konfiguration CNAME- und Zonendelegation des Teilnetzes sind unvollständig
fehlerhafte IPv6-Reverse-Zone Nibble-Zone stimmt nicht mit dem delegierten Präfix überein
nicht erreichbarer Forwarder direkte Abfrage zum Forwarder scheitert reproduzierbar
langsamer autoritativer Server direkte autoritative Abfrage zeigt erhöhte Antwortzeit
UDP-Blockierung UDP-DNS scheitert, TCP-DNS funktioniert
TCP-Blockierung abgeschnittene UDP-Antwort kann nicht über TCP wiederholt werden
Paketverlust Aufzeichnung zeigt Wiederholungen oder fehlende Antworten
MTU- oder Fragmentierungsproblem große UDP-Antworten scheitern, TCP funktioniert
DNS-Serverüberlastung erhöhte Antwortzeit korreliert mit Abfragerate und Ressourcenlast
ungeeignete TTL Datensatz- und Cachewerte bestätigen zu kurze oder zu lange Speicherung
negativer Cache zuvor negative Antwort bleibt bis zum Ablauf wirksam
falscher CNAME Alias verweist auf fehlenden oder falschen Zielnamen
falscher SRV-Eintrag Dienstziel, Port, Priorität oder Gewicht sind unzutreffend
DHCP aktualisiert PTR nicht DHCP-Ereignis oder Konfiguration bestätigt fehlgeschlagene Aktualisierung
fehlende Updateberechtigung DNS- oder DHCP-Protokoll zeigt Zugriffsfehler
veralteter statischer PTR statischer Datensatz enthält alten Namen
fehlerhaftes Scavenging Konfiguration oder Ereignisse bestätigen unerwartete Löschung
AD-Replikationsproblem DNS-Server liefern unterschiedliche autoritative Daten und repadmin meldet Fehler
DNSSEC-Validierungsfehler SERVFAIL und Validierungsdaten bestätigen fehlerhafte Vertrauenskette
öffentlicher PTR nicht delegiert Provider beziehungsweise Präfixbetreiber bestätigt fehlende Reverse-Konfiguration

7.11.41 Kontrollierte Maßnahmen, Risiko und Rückweg

Maßnahme Risiko Rückweg beziehungsweise Kontrolle
vorgesehenen DNS-Server konfigurieren andere Namensräume können beeinflusst werden bisherige DNS-Werte dokumentieren
falsches DNS-Suffix korrigieren Suchverhalten verändert sich ursprüngliche Suffixliste sichern
fehlerhaften Hosts-Eintrag entfernen Anwendung verliert lokale Sonderzuordnung Datei und ursprünglichen Eintrag sichern
NRPT-Regel korrigieren VPN-Namensauflösung kann ausfallen bisherige Regel und Zielserver sichern
DoH- oder DoT-Konfiguration korrigieren Transport und Fallbackverhalten ändern sich bisherigen Verschlüsselungszustand dokumentieren
fehlende Reverse-Zone anlegen falscher Adressbereich kann überschrieben werden Netz-ID und Zuständigkeit vorher bestätigen
PTR-Eintrag anlegen falscher Name wird veröffentlicht IP, FQDN und Forward-Eintrag vorher prüfen
veralteten PTR korrigieren bestehende Abhängigkeiten können betroffen sein alten Wert und Eigentümer dokumentieren
Forwarder korrigieren externe und interne Auflösung kann beeinflusst werden bisherige Forwarderliste sichern
Delegation korrigieren gesamter Reverse-Bereich kann betroffen sein bisherige NS- und CNAME-Daten sichern
dynamische Updates korrigieren viele Clients können Datensätze verändern Zonenrichtlinie und Berechtigungen dokumentieren
Clientregistrierung auslösen mehrere A- oder PTR-Einträge können entstehen vorhandene Einträge vorher erfassen
Clientcache kontrolliert löschen ursprünglicher Cachebefund geht verloren Cacheinhalt vorher dokumentieren
DNS-Servercache löschen viele Abfragen müssen erneut rekursiv aufgelöst werden nur gezielt und mit Lastkontrolle
TTL ändern Cacheverhalten vieler Resolver ändert sich bisherigen Wert und Änderungszeit sichern
Aging oder Scavenging anpassen gültige Datensätze können gelöscht werden Zonenexport und Änderungsplan vorsehen
AD-Replikationsfehler beheben mehrere DNS- und AD-Daten können betroffen sein DC-spezifischen Wiederherstellungsplan verwenden
analytische Protokollierung aktivieren Leistung und Datenschutz können betroffen sein Zeitfenster, Speicherlimit und Abschaltung festlegen

Pro Diagnoseversuch sollte möglichst nur eine relevante Variable verändert werden.

7.11.42 Beispiel: Reverse-Zone und PTR-Eintrag anlegen

Die folgenden Befehle sind verändernde Administrationsmaßnahmen und dürfen erst nach Prüfung von Netzbereich, Zonenverantwortung, Replikationsbereich und bestehender Konfiguration ausgeführt werden.

AD-integrierte IPv4-Reverse-Zone für das Dokumentationsnetz 192.0.2.0/24:

Add-DnsServerPrimaryZone `
  -NetworkID "192.0.2.0/24" `
  -ReplicationScope "Forest"

PTR-Eintrag für 192.0.2.25:

Add-DnsServerResourceRecordPtr `
  -Name "25" `
  -ZoneName "2.0.192.in-addr.arpa" `
  -PtrDomainName "host25.example.test."

Danach kontrollieren:

Get-DnsServerResourceRecord `
  -ZoneName "2.0.192.in-addr.arpa" `
  -Name "25" `
  -RRType PTR

Resolve-DnsName `
  -Name "192.0.2.25" `
  -Type PTR `
  -Server "192.0.2.53" `
  -DnsOnly

Zusätzlich muss der PTR-Zielname vorwärts geprüft werden:

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

Die Beispieladressen und Namen dienen ausschließlich der Dokumentation und müssen durch die tatsächlich autorisierten Werte ersetzt werden.

7.11.43 Verifikation

Nach einer Maßnahme sind mindestens folgende Punkte zu prüfen:

Eine einzelne erfolgreiche Cacheabfrage ist keine ausreichende Verifikation des vollständigen DNS-Pfads.

7.11.44 Präventionsmaßnahmen

7.11.45 Typische Fehler bei der Diagnose

7.11.46 Checkliste

7.11.47 Schnellreferenz

Aufgabe Befehl
Windows-Netzwerk- und DNS-Konfiguration ipconfig /all
Windows-DNS-Serveradressen Get-DnsClientServerAddress
Windows-DNS-Clientzustand Get-DnsClient
Linux-Resolverzustand resolvectl status
macOS-Resolverzustand scutil --dns
wirksame NRPT-Richtlinie Get-DnsClientNrptPolicy
konfigurierte NRPT-Regeln Get-DnsClientNrptRule
DoH-/DoT-Clientzustand netsh dnsclient show state
verschlüsselte DNS-Server netsh dnsclient show encryption
Vorwärtsauflösung IPv4 Resolve-DnsName <Name> -Type A -Server <DNS-IP> -DnsOnly
Vorwärtsauflösung IPv6 Resolve-DnsName <Name> -Type AAAA -Server <DNS-IP> -DnsOnly
Rückwärtsauflösung Resolve-DnsName <IP> -Type PTR -Server <DNS-IP> -DnsOnly
Rückwärtsauflösung mit dig dig @<DNS-IP> -x <IP>
CNAME prüfen Resolve-DnsName <Name> -Type CNAME -Server <DNS-IP> -DnsOnly
SRV prüfen Resolve-DnsName <SRV-Name> -Type SRV -Server <DNS-IP> -DnsOnly
TCP-DNS-Abfrage Resolve-DnsName <Name> -Server <DNS-IP> -TcpOnly -DnsOnly
TCP-Port 53 prüfen Test-NetConnection <DNS-IP> -Port 53
DNSSEC-Daten anfordern Resolve-DnsName <Name> -Server <DNS-IP> -DnssecOk
Clientcache anzeigen Get-DnsClientCache
Clientcache löschen Clear-DnsClientCache
DNS-Serverdienst Get-Service DNS
DNS-Zonen Get-DnsServerZone
PTR-Einträge Get-DnsServerResourceRecord -ZoneName <Zone> -RRType PTR
Forwarder Get-DnsServerForwarder
Rekursion Get-DnsServerRecursion
Cacheeinstellungen Get-DnsServerCache
Serverstatistiken Get-DnsServerStatistics
Leistungsindikatoren Get-Counter -ListSet DNS
DoH-Serverkonfiguration Get-DnsServerEncryptionProtocol
Clientregistrierung Register-DnsClient
AD-DNS-Test dcdiag /test:DNS /v
AD-Replikation repadmin /replsummary

Ändernde Befehle, die nicht als erste Diagnose verwendet werden dürfen:

Clear-DnsClientCache
Clear-DnsServerCache
Register-DnsClient
ipconfig /flushdns
ipconfig /registerdns
Add-DnsServerPrimaryZone
Add-DnsServerResourceRecordPtr
Set-DnsServerForwarder
Set-DnsServerRecursion
Set-DnsServerCache
Set-DnsServerZoneAging
Start-DnsServerScavenging
Set-DnsServerEncryptionProtocol
Remove-DnsServerResourceRecord

7.11.48 Quellen

Offizielle Microsoft-Dokumentation

Standards

Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.

7.12 Systematischer DNS-Diagnoseablauf

Kurz erklärt

DNS-Störungen dürfen nicht durch wahlloses Leeren von Caches, Ändern von DNS-Servern oder Neuerstellen von Einträgen diagnostiziert werden.

Der sichere Ablauf beginnt beim exakten Fehlerbild und verfolgt die Namensauflösung schrittweise vom Client über den verwendeten Resolver, den Transportweg und rekursive DNS-Server bis zum autoritativen Server und den tatsächlichen Zonendaten.

7.12.1 Ziel des Diagnoseablaufs

Der Diagnoseablauf soll eindeutig bestimmen:

DNS-Diagnose bedeutet nicht nur, irgendeine erfolgreiche Antwort zu erhalten. Die Antwort muss vom vorgesehenen DNS-Pfad stammen, fachlich korrekt sein und innerhalb einer angemessenen Zeit eintreffen.

7.12.2 Grundregeln

  1. Zuerst beobachten und dokumentieren.
  2. Den exakten Namen und Datensatztyp verwenden.
  3. Clientverhalten und direkte DNS-Abfrage unterscheiden.
  4. Den tatsächlich verwendeten DNS-Server bestimmen.
  5. Antwortcode und Antwortinhalt getrennt bewerten.
  6. Positive, negative und ausgebliebene Antworten unterscheiden.
  7. Cache-, rekursive und autoritative Antworten trennen.
  8. UDP, TCP, DoH und DoT nicht gleichsetzen.
  9. Pro Versuch nur eine relevante Variable verändern.
  10. Vor jeder Änderung Risiko und Rückweg dokumentieren.
  11. Nach der Maßnahme denselben Test wiederholen.
  12. Erst nach technischer Verifikation den Vorgang abschließen.

Folgende Maßnahmen sind keine geeigneten ersten Diagnoseschritte:

7.12.3 Fehleraufnahme

Vor dem ersten Test sind mindestens folgende Angaben zu erfassen:

Angabe Beispiel
Zeitpunkt 2026-08-02 14:35:20
Client client25.example.test
Benutzer beziehungsweise Dienst betroffene Sitzung oder Dienstkonto
Anwendung Browser, RDP, Mail, Dateifreigabe, AD-Anmeldung
eingegebener Name app.example.test
erwarteter FQDN app.example.test.
erwarteter Datensatztyp A, AAAA, CNAME, PTR, SRV, MX oder TXT
erwartetes Ergebnis vorgesehene IP-Adresse oder Zielname
tatsächliches Ergebnis Fehlertext oder falsche Antwort
verwendetes Netzwerk LAN, WLAN, VPN oder Mobilfunk
Quell-IP-Adresse aktive Clientadresse
konfigurierte DNS-Server Reihenfolge und Schnittstelle
Fehlerumfang einzelner Client, Standort, Zone oder alle Systeme
letzte Änderung DNS, DHCP, VPN, Firewall, Server, Zertifikat oder Netzwerk

Kennwörter, Zugangsdaten und unnötige personenbezogene Daten dürfen nicht in die Fehlerdokumentation übernommen werden.

7.12.4 Störung einordnen

Fehlerklasse Typisches Symptom
vollständiger Ausfall keine DNS-Abfrage funktioniert
namensbezogener Fehler nur ein bestimmter Name schlägt fehl
zonenbezogener Fehler alle Namen einer Zone schlagen fehl
datensatzbezogener Fehler A funktioniert, SRV oder PTR jedoch nicht
resolverbezogener Fehler nur ein bestimmter DNS-Server liefert Fehler
clientbezogener Fehler derselbe Name funktioniert an anderen Clients
anwendungsbezogener Fehler direkte DNS-Abfrage funktioniert, Anwendung nicht
standortbezogener Fehler Fehler tritt nur in einem Netz oder VPN auf
zeitabhängiger Fehler Fehler tritt nur zeitweise auf
leistungsbezogener Fehler Antwort ist korrekt, aber zu langsam
datenbezogener Fehler DNS liefert eine falsche oder veraltete Antwort
transportbezogener Fehler UDP, TCP, DoH oder DoT verhalten sich unterschiedlich
validierungsbezogener Fehler DNSSEC führt zu SERVFAIL oder Validierungsfehler
reversebezogener Fehler IP-Adresse lässt sich nicht korrekt in einen Namen auflösen

Diese Einordnung bestimmt, welche Vergleichstests aussagekräftig sind.

7.12.5 Geeignete Testdaten festlegen

Für reproduzierbare Tests müssen folgende Werte feststehen:

Ein kurzer Name wie:

server01

ist für eine eindeutige DNS-Diagnose ungeeignet, solange nicht feststeht, welches DNS-Suffix ergänzt wird.

Besser:

server01.example.test.

Der abschließende Punkt kennzeichnet einen vollständig qualifizierten absoluten DNS-Namen. Viele Werkzeuge funktionieren auch ohne diesen Punkt, können dann jedoch abhängig von Suchsuffixen zusätzliche Namen prüfen.

7.12.6 DNS-Auflösung als Kette betrachten

Eine Namensauflösung kann folgende Stationen durchlaufen:

Station Aufgabe
Anwendung fordert eine Namensauflösung an oder verwendet eigenen Resolver
lokale Namensquelle Hosts-Datei oder anwendungseigener Cache
Betriebssystemresolver wertet Cache, Suffixe, Richtlinien und DNS-Server aus
lokaler Stub-Resolver nimmt Anfragen lokal entgegen und leitet sie weiter
VPN-, Container- oder Sicherheitsresolver beeinflusst den Abfrageweg
rekursiver DNS-Server beschafft die vollständige Antwort für den Client
Forwarder übernimmt weitergeleitete Anfragen
DNS-Hierarchie verweist schrittweise auf zuständige Server
autoritativer DNS-Server liefert die maßgeblichen Zonendaten
Cache auf dem Rückweg speichert positive oder negative Antworten

Die Diagnose folgt dieser Kette vom Client in Richtung autoritativer Datenquelle.

7.12.7 Umfang der Störung bestimmen

Kontrollierte Vergleiche:

Vergleich Aussage
gleicher Name, anderer Client clientbezogenen Fehler prüfen
gleicher Client, anderer Name namens- oder zonenbezogenen Fehler prüfen
gleicher Name, anderer DNS-Server resolverbezogenen Fehler prüfen
gleiche Abfrage, direkt gegen autoritativen Server Rekursion und Autorität trennen
gleiche Abfrage mit und ohne VPN VPN-, NRPT- oder Split-DNS-Fehler prüfen
gleiche Abfrage über UDP und TCP Transportfehler prüfen
direkte DNS-Abfrage und Anwendung DNS- und Anwendungsfehler trennen
Vorwärts- und Rückwärtsauflösung A/AAAA und PTR getrennt prüfen
erste und wiederholte Abfrage Cachewirkung prüfen
interner und externer Name interne Zone und Rekursion trennen

Erst nach diesen Vergleichen sollte eine konkrete Ursache angenommen werden.

7.12.8 Clientidentität und Netzwerkzustand prüfen

Windows

Get-NetIPConfiguration

ipconfig /all

Linux

ip address

ip route

macOS

ifconfig

route -n get default

Zu prüfen sind:

Eine vorhandene IP-Adresse beweist nicht, dass der vorgesehene DNS-Server erreichbar ist.

7.12.9 DNS-Server und Resolverkonfiguration ermitteln

Windows

Get-DnsClientServerAddress

Get-DnsClient

Linux

cat /etc/resolv.conf

Bei systemd-resolved:

resolvectl status

macOS

scutil --dns

Zu prüfen sind:

/etc/resolv.conf kann lediglich auf einen lokalen Stub-Resolver verweisen. In diesem Fall müssen die tatsächlichen Upstream-DNS-Server über den zuständigen Resolverdienst ermittelt werden.

7.12.10 Interne Clients und öffentliche DNS-Server

Domänenmitglieder und interne Clients müssen für interne Namensräume die vorgesehenen internen DNS-Server verwenden.

Das Eintragen eines öffentlichen DNS-Servers wie eines Resolverdienstes im Internet kann:

Ein öffentlicher DNS-Server darf deshalb nicht als pauschale Reparatur für einen internen DNS-Fehler eingetragen werden.

7.12.11 Hosts-Datei und lokale Namensquellen prüfen

Hosts-Dateien:

Betriebssystem Pfad
Windows C:\Windows\System32\drivers\etc\hosts
Linux /etc/hosts
macOS /etc/hosts

Zu prüfen sind:

Eine direkte Abfrage mit ausdrücklich angegebenem DNS-Server kann erfolgreich sein, während eine Anwendung wegen eines falschen lokalen Eintrags eine andere Adresse verwendet.

7.12.12 Kurznamen und DNS-Suffixe prüfen

Wenn ein Benutzer nur folgenden Namen verwendet:

server01

kann der Resolver abhängig von seiner Suchliste nacheinander verschiedene Namen bilden:

server01.example.test
server01.branch.example.test
server01.other.example.test

Windows-Konfiguration prüfen:

Get-DnsClient

Linux mit systemd-resolved:

resolvectl status

macOS:

scutil --dns

Mögliche Fehler:

Für die technische Diagnose sollte zuerst der vollständige FQDN verwendet werden.

7.12.13 Tatsächlichen Windows-Resolverpfad bestimmen

Unter Windows können NRPT, VPN-Richtlinien und verschlüsseltes DNS den Abfrageweg verändern.

Wirksame NRPT-Richtlinien:

Get-DnsClientNrptPolicy

Konfigurierte NRPT-Regeln:

Get-DnsClientNrptRule

DNS-Clientzustand:

netsh dnsclient show state

Globale verschlüsselte DNS-Einstellungen:

netsh dnsclient show global

Konfigurierte DoH- oder DoT-Endpunkte:

netsh dnsclient show encryption

Wichtig:

Deshalb müssen Systemauflösung und direkte Serverabfrage getrennt getestet werden.

7.12.14 Anwendung und DNS voneinander abgrenzen

Folgende Ergebnisse sind getrennt zu prüfen:

  1. Kann die Ziel-IP-Adresse direkt erreicht werden?
  2. Liefert eine direkte DNS-Abfrage die erwartete Adresse?
  3. Liefert der normale Betriebssystemresolver dieselbe Adresse?
  4. Verwendet die Anwendung dieselbe Adresse?
  5. Ist der eigentliche Dienst auf der Zieladresse erreichbar?

Beispiel:

Resolve-DnsName "app.example.test"

Direkte Abfrage gegen einen bestimmten DNS-Server:

Resolve-DnsName `
  -Name "app.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

Wenn DNS die richtige IP-Adresse liefert, die Anwendung aber weiterhin fehlschlägt, müssen unter anderem Anwendungscache, Proxy, TLS-Zertifikat, Dienstport und Anwendungsrichtlinien geprüft werden.

Ein erfolgreicher DNS-Test beweist nicht, dass der Zielservice funktioniert.

7.12.15 Direkte DNS-Abfragen durchführen

Windows PowerShell

Resolve-DnsName `
  -Name "app.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

Windows Eingabeaufforderung

nslookup app.example.test 192.0.2.53

Linux und macOS

dig @192.0.2.53 app.example.test A

Bei jedem Test sind zu dokumentieren:

7.12.16 Datensatztypen gezielt prüfen

Aufgabe Datensatz
IPv4-Adresse ermitteln A
IPv6-Adresse ermitteln AAAA
Alias verfolgen CNAME
Mailserver ermitteln MX
Dienst und Port ermitteln SRV
IP-Adresse rückwärts auflösen PTR
Zonenautorität prüfen SOA
autoritative Server ermitteln NS
Richtlinien- oder Verifikationstext prüfen TXT
DNSSEC-Schlüssel prüfen DNSKEY
Delegationssignatur prüfen DS

Beispiele:

Resolve-DnsName "app.example.test" -Type A

Resolve-DnsName "alias.example.test" -Type CNAME

Resolve-DnsName "_service._tcp.example.test" -Type SRV

Resolve-DnsName "example.test" -Type SOA

Resolve-DnsName "example.test" -Type NS

Bei CNAME, MX und SRV muss zusätzlich geprüft werden, ob der zurückgegebene Zielname über A oder AAAA auflösbar ist.

7.12.17 DNS-Antwortcodes auswerten

Ergebnis Bedeutung Nächster Schritt
NOERROR mit Antwort Abfrage erfolgreich Inhalt, TTL und Quelle prüfen
NOERROR ohne gesuchten Datensatz Name kann existieren, Datensatztyp fehlt anderen Datensatztyp und SOA prüfen
NXDOMAIN abgefragter Name existiert laut Antwort nicht Name, Zone, Autorität und negativen Cache prüfen
SERVFAIL Server konnte keine verwertbare Antwort erzeugen Delegation, DNSSEC, Forwarder und Serverprotokolle prüfen
REFUSED Server verweigert die Abfrage ACL, Rekursion, Richtlinie und Quellnetz prüfen
FORMERR DNS-Nachricht wurde als fehlerhaft bewertet Client, Server und Netzwerkgerät prüfen
NOTIMP angeforderte Funktion wird nicht unterstützt Abfragefunktion und Serverfähigkeit prüfen
Timeout keine verwertbare Antwort innerhalb der Wartezeit Netzwerk, Transport und Serververfügbarkeit prüfen
TC gesetzt UDP-Antwort wurde abgeschnitten erneuten Versuch über TCP prüfen

Wichtige Unterscheidungen:

7.12.18 Antwortflags berücksichtigen

Typische DNS-Flags:

Flag Bedeutung
AA Antwort ist für die beantwortete Zone autoritativ
RD Client hat Rekursion angefordert
RA Server bietet Rekursion an
TC Antwort wurde abgeschnitten
AD Resolver kennzeichnet Daten als DNSSEC-validiert
CD Client fordert an, Validierungsfehler nicht als Sperre zu verwenden

Ein gesetztes AD-Flag muss im Zusammenhang mit dem verwendeten validierenden Resolver bewertet werden. Das bloße Anfordern von DNSSEC-Daten beweist keine erfolgreiche Validierung.

7.12.19 Antwortzeit messen

Windows

Measure-Command {
    Resolve-DnsName `
      -Name "app.example.test" `
      -Type A `
      -Server "192.0.2.53" `
      -DnsOnly
}

Linux und macOS

dig @192.0.2.53 app.example.test A +stats

Zu vergleichen sind:

Measure-Command enthält auch den PowerShell-Befehlsaufwand. Es eignet sich deshalb vor allem für Vergleiche unter denselben Bedingungen.

7.12.20 Cachezustand prüfen

Windows-Clientcache

Get-DnsClientCache

Alternativ:

ipconfig /displaydns

Linux mit systemd-resolved

resolvectl statistics

Windows-DNS-Servercacheeinstellungen

Get-DnsServerCache

Get-DnsServerCache zeigt Cacheeinstellungen des Windows-DNS-Servers und nicht einfach eine vollständige Liste aller zwischengespeicherten Antworten.

Zu prüfen sind:

Cachelöschung verändert Beweisdaten und darf erst nach der Dokumentation als kontrollierter Vergleich erfolgen.

7.12.21 Positive und negative Zwischenspeicherung unterscheiden

Positive Antworten können A-, AAAA-, CNAME-, PTR- oder andere Datensätze zwischenspeichern.

Negative Zwischenspeicherung kann unter anderem betreffen:

Mögliche Folge:

  1. Ein Name wird abgefragt und liefert NXDOMAIN.
  2. Der fehlende Datensatz wird anschließend angelegt.
  3. Der Client oder rekursive Resolver liefert zunächst weiterhin die gespeicherte negative Antwort.
  4. Erst nach Ablauf oder kontrollierter Löschung des Cacheeintrags wird der neue Datensatz sichtbar.

Deshalb müssen SOA-Daten, negative TTL und alle beteiligten Cacheebenen berücksichtigt werden.

7.12.22 DNS-Server vergleichen

Eine identische Abfrage muss gezielt an jeden vorgesehenen DNS-Server gesendet werden.

Windows

Resolve-DnsName `
  -Name "app.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

Resolve-DnsName `
  -Name "app.example.test" `
  -Type A `
  -Server "192.0.2.54" `
  -DnsOnly

Linux und macOS

dig @192.0.2.53 app.example.test A

dig @192.0.2.54 app.example.test A

Zu vergleichen sind:

Unterschiedliche Antworten können auf Cache-, Zonen-, Replikations-, Zonentransfer- oder Konfigurationsprobleme hinweisen.

7.12.23 UDP und TCP prüfen

Klassische DNS-Abfragen verwenden häufig UDP-Port 53. TCP-Port 53 wird unter anderem benötigt:

TCP-Erreichbarkeit unter Windows:

Test-NetConnection "192.0.2.53" -Port 53

Dieser Befehl prüft nur TCP.

Normale DNS-Abfrage:

Resolve-DnsName `
  -Name "app.example.test" `
  -Server "192.0.2.53" `
  -DnsOnly

TCP erzwingen:

Resolve-DnsName `
  -Name "app.example.test" `
  -Server "192.0.2.53" `
  -DnsOnly `
  -TcpOnly

Mit dig:

dig @192.0.2.53 app.example.test A

dig @192.0.2.53 app.example.test A +tcp

Wenn UDP fehlschlägt und TCP funktioniert, sind Firewall, Paketverlust, EDNS, MTU und Fragmentierung zu prüfen.

7.12.24 EDNS, MTU und Fragmentierung prüfen

Hinweise auf ein Größen- oder Transportproblem:

Vergleich:

dig @192.0.2.53 example.com A +dnssec

dig @192.0.2.53 example.com A +dnssec +tcp

Test ohne EDNS:

dig @192.0.2.53 example.com A +noedns

Das testweise Unterdrücken von EDNS dient nur der Eingrenzung. EDNS darf nicht dauerhaft deaktiviert werden, um einen fehlerhaften Netzwerkpfad zu verdecken.

7.12.25 Verschlüsseltes DNS prüfen

DNS over HTTPS und DNS over TLS verändern den Transportweg.

Zu prüfen sind:

Windows-Zustand:

netsh dnsclient show state

netsh dnsclient show encryption

Bei verschlüsseltem DNS kann eine klassische Paketaufzeichnung den DNS-Inhalt nicht ohne zusätzliche, autorisierte Entschlüsselungsinformationen anzeigen.

Ein erfolgreicher Test gegen UDP- oder TCP-Port 53 beweist nicht, dass ein DoH- oder DoT-Endpunkt funktioniert.

7.12.26 Rekursiven und autoritativen DNS-Server unterscheiden

Ein rekursiver DNS-Server beschafft die Antwort im Auftrag des Clients.

Ein autoritativer DNS-Server verwaltet die maßgeblichen Daten einer Zone.

Diagnosevergleich:

  1. Client fragt vorgesehenen rekursiven DNS-Server.
  2. Rekursiver Server liefert Fehler oder langsame Antwort.
  3. Autoritativer DNS-Server wird direkt abgefragt.
  4. Ergebnisse werden verglichen.

Wenn der autoritative Server korrekt und schnell antwortet, liegt die Ursache wahrscheinlich bei:

Wenn bereits der autoritative Server falsche Daten liefert, sind Zone, Datensatz, Delegation und Replikation zu prüfen.

7.12.27 SOA-, NS- und Delegationsdaten prüfen

SOA prüfen:

Resolve-DnsName `
  -Name "example.test" `
  -Type SOA `
  -Server "192.0.2.53" `
  -DnsOnly

NS prüfen:

Resolve-DnsName `
  -Name "example.test" `
  -Type NS `
  -Server "192.0.2.53" `
  -DnsOnly

Mit dig:

dig @192.0.2.53 example.test SOA

dig @192.0.2.53 example.test NS

Öffentliche Delegationskette verfolgen:

dig app.example.test A +trace

Zu prüfen sind:

dig +trace folgt der öffentlichen DNS-Hierarchie. Interne Split-DNS-Zonen, bedingte Forwarder und private Namensräume müssen über den internen DNS-Pfad geprüft werden.

7.12.28 Forwarder, bedingte Forwarder und Rekursion prüfen

Auf einem Windows-DNS-Server:

Get-DnsServerForwarder

Get-DnsServerRecursion

Get-DnsServerRootHint

Zonen und bedingte Weiterleitungen:

Get-DnsServerZone

Zu prüfen sind:

Ein nicht erreichbarer erster Forwarder kann Verzögerungen verursachen, bevor ein weiterer Auflösungspfad verwendet wird.

7.12.29 Reverse-Lookups prüfen

Windows

Resolve-DnsName `
  -Name "192.0.2.25" `
  -Type PTR `
  -Server "192.0.2.53" `
  -DnsOnly

Linux und macOS

dig @192.0.2.53 -x 192.0.2.25

Danach muss der PTR-Zielname wieder vorwärts geprüft werden:

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

Zu prüfen sind:

Ein fehlender PTR-Eintrag beweist keinen vollständigen DNS-Ausfall.

7.12.30 DNSSEC systematisch abgrenzen

DNSSEC-Daten anfordern:

Resolve-DnsName `
  -Name "example.com" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly `
  -DnssecOk

Mit dig:

dig @192.0.2.53 example.com A +dnssec

Zu prüfen sind:

-DnssecOk und +dnssec fordern DNSSEC-bezogene Daten an. Diese Optionen beweisen allein keine erfolgreiche Validierung.

nslookup ist nicht für eine vollständige DNSSEC-Diagnose geeignet.

7.12.31 Windows-DNS-Serverzustand prüfen

Dienststatus:

Get-Service -Name DNS

Zonen:

Get-DnsServerZone

Bestimmte Zone:

Get-DnsServerZone `
  -Name "example.test"

Datensätze:

Get-DnsServerResourceRecord `
  -ZoneName "example.test"

Serverstatistiken:

Get-DnsServerStatistics

Verfügbare Leistungsindikatoren:

Get-Counter -ListSet DNS

Zu prüfen sind:

Ein laufender DNS-Dienst beweist nicht, dass eine bestimmte Zone korrekt geladen oder repliziert wurde.

7.12.32 Active-Directory-DNS prüfen

LDAP-SRV-Einträge:

Resolve-DnsName `
  -Name "_ldap._tcp.dc._msdcs.<AD-DNS-Domäne>" `
  -Type SRV

Kerberos-SRV-Einträge:

Resolve-DnsName `
  -Name "_kerberos._tcp.<AD-DNS-Domäne>" `
  -Type SRV

DNS-Test eines Domänencontrollers:

dcdiag /test:DNS /v /s:<DC-Name>

Replikationsübersicht:

repadmin /replsummary

Replikationsdetails:

repadmin /showrepl

Zu prüfen sind:

Eine manuelle Neuerstellung von SRV-Einträgen ist keine erste Maßnahme. Zuerst müssen Registrierung, Netlogon, Zone, Berechtigungen und Replikation geprüft werden.

7.12.33 Dynamische Updates und DHCP prüfen

Vor einer erneuten Registrierung sind vorhandene Datensätze, Zeitstempel und Ereignisse zu dokumentieren.

Verändernde Clientregistrierung:

Register-DnsClient

Alternativ:

ipconfig /registerdns

Zu prüfen sind:

Das wiederholte Registrieren behebt keine fehlende Zone, falsche Berechtigung oder fehlerhafte DHCP-DNS-Konfiguration.

7.12.34 Aging und Scavenging prüfen

Zu prüfen sind:

Scavenging beinhaltet Löschvorgänge und darf nicht spontan aktiviert oder erzwungen werden, um einzelne veraltete Einträge zu beseitigen.

7.12.35 Ereignisse und Protokolle auswerten

Vorhandene DNS-Protokolle unter Windows anzeigen:

Get-WinEvent -ListLog "*DNS*"

Mögliche Bereiche:

Zu korrelieren sind:

Analytische DNS-Protokollierung muss gezielt und zeitlich begrenzt aktiviert werden. Sie kann bei hohen Abfrageraten die Leistung beeinflussen und enthält schützenswerte interne Namensinformationen.

7.12.36 Netzwerkaufzeichnung gezielt einsetzen

Eine Netzwerkaufzeichnung ist sinnvoll, wenn unklar bleibt:

Bei DoH und DoT ist der DNS-Inhalt verschlüsselt. Sichtbar bleiben unter anderem Zieladresse, Port, TLS-Verbindung und Zeitverhalten, nicht jedoch ohne Weiteres der eigentliche DNS-Nachrichteninhalt.

Aufzeichnungen müssen auf die betroffenen Systeme, Namen und Zeiträume begrenzt sowie geschützt gespeichert werden.

7.12.37 Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Der erste konfigurierte DNS-Forwarder ist nicht erreichbar und verursacht die Verzögerung.

Erwarteter Befund:
Direkte Abfragen gegen den ersten Forwarder laufen in einen Timeout.
Direkte Abfragen gegen den zweiten Forwarder funktionieren sofort.

Gegenbeweis:
Der erste Forwarder antwortet unter denselben Bedingungen schnell und korrekt.

Eine belastbare Hypothese enthält:

Erst danach sollte eine Änderung vorgenommen werden.

7.12.38 Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko
DNS-Serveradresse korrigieren falscher Resolver nachgewiesen andere Namensräume können beeinflusst werden
Suffix oder NRPT-Regel korrigieren falscher Abfrageweg nachgewiesen VPN- und Split-DNS-Verhalten ändert sich
DNS-Datensatz korrigieren autoritative Daten sind nachweislich falsch Anwendungen können auf neues Ziel wechseln
PTR-Eintrag korrigieren falscher Reverse-Eintrag bestätigt Protokoll- oder Sicherheitszuordnung ändert sich
Forwarder korrigieren nicht erreichbarer oder falscher Forwarder bestätigt externe oder interne Rekursion betroffen
Delegation korrigieren falsche NS- oder Glue-Daten bestätigt gesamte Zone kann betroffen sein
dynamische Updates korrigieren Updatefehler und Berechtigung nachgewiesen viele Clients können Einträge verändern
Cache kontrolliert löschen falscher Cacheeintrag dokumentiert Beweisdaten gehen verloren
DNSSEC-Konfiguration korrigieren Validierungsfehler nachgewiesen Vertrauenskette und Sicherheit betroffen
Aging oder Scavenging anpassen Fehlkonfiguration nachgewiesen gültige Datensätze können gelöscht werden
Replikationsfehler beheben AD-Replikationsfehler bestätigt mehrere Verzeichnisdaten betroffen

Vor der Maßnahme sind zu dokumentieren:

7.12.39 Vollständiger Diagnoseablauf

  1. Exakte Fehlermeldung aufnehmen
    Wortlaut, Anwendung, Benutzer, Client und Uhrzeit dokumentieren.

  2. Betroffenen Namen bestimmen
    Kurzname, FQDN oder IP-Adresse unterscheiden.

  3. Erwarteten Datensatztyp bestimmen
    A, AAAA, CNAME, PTR, SRV, MX, TXT, NS oder SOA festlegen.

  4. Erwartetes Ergebnis dokumentieren
    Vorgesehene IP-Adresse, Zielname oder Dienstinformation festhalten.

  5. Umfang bestimmen
    Einzelnen Client, Standort, DNS-Server, Namen, Zone oder alle Systeme unterscheiden.

  6. Anwendung und DNS abgrenzen
    Direkte IP-Verbindung, Systemresolver und Anwendung getrennt prüfen.

  7. Netzwerkzustand erfassen
    Schnittstelle, Adresse, Gateway, VPN und Routing dokumentieren.

  8. Konfigurierte DNS-Server erfassen
    DNS-Server pro Schnittstelle und Reihenfolge bestimmen.

  9. Suffixe und lokale Namensquellen prüfen
    Suchliste, Hosts-Datei und Anwendungscache berücksichtigen.

  10. Resolverrichtlinien prüfen
    NRPT, Split-DNS, Container-DNS und Sicherheitsresolver berücksichtigen.

  11. Verschlüsselten DNS-Pfad bestimmen
    Klassisches DNS, DoH und DoT unterscheiden.

  12. Normale Systemauflösung testen
    Prüfen, welches Ergebnis die Anwendung grundsätzlich erhalten kann.

  13. Direkte Abfrage durchführen
    Vorgesehenen DNS-Server und Datensatztyp ausdrücklich angeben.

  14. Antwortcode auswerten
    NOERROR, NXDOMAIN, SERVFAIL, REFUSED oder Timeout unterscheiden.

  15. Antwortinhalt auswerten
    Wert, TTL, CNAME-Kette und Flags prüfen.

  16. Antwortzeit messen
    Erste und wiederholte Abfrage vergleichen.

  17. Alternativen DNS-Server prüfen
    Unterschiede zwischen vorgesehenen Resolvern dokumentieren.

  18. Cachezustand prüfen
    Positive und negative Einträge auf allen relevanten Ebenen berücksichtigen.

  19. UDP und TCP vergleichen
    Transportabhängige Fehler bestimmen.

  20. EDNS, MTU und Fragmentierung prüfen
    Besonders bei großen Antworten oder VPN-Verbindungen.

  21. Rekursiven und autoritativen Server unterscheiden
    Abfrageweg in einzelne Ebenen zerlegen.

  22. SOA, NS und Delegation prüfen
    Zuständigkeit und Zonengrenze bestätigen.

  23. Autoritative Server direkt vergleichen
    Datensatz, TTL, Seriennummer und Antwortcode auswerten.

  24. Forwarder und Rekursion prüfen
    Erreichbarkeit, Richtlinien und Timeoutpfad untersuchen.

  25. DNSSEC prüfen
    Signaturen, DS, DNSKEY, Trust Anchor und Validierungsfehler berücksichtigen.

  26. Reverse-Lookup prüfen
    PTR, Reverse-Zone, Delegation und Vorwärtskonsistenz auswerten.

  27. DNS-Serverzustand prüfen
    Dienst, Zonen, Statistiken, Last und Ereignisse untersuchen.

  28. AD-DNS und Replikation prüfen
    Wenn AD-integrierte Zonen oder SRV-Einträge beteiligt sind.

  29. Dynamische Updates und DHCP prüfen
    Registrierung, Eigentümer, Berechtigungen und Leasezustand auswerten.

  30. Aging und Scavenging prüfen
    Bei veralteten oder unerwartet fehlenden Einträgen.

  31. Protokolle korrelieren
    Client, DNS-Server, DHCP und Anwendung auf denselben Versuch begrenzen.

  32. Bei Bedarf Netzwerkaufzeichnung durchführen
    Nur zeitlich und technisch begrenzt.

  33. Hypothese und Gegenbeweis formulieren
    Ursache vor der Änderung messbar beschreiben.

  34. Eine kontrollierte Maßnahme ausführen
    Risiko, Rückweg und Erfolgskriterium beachten.

  35. Identischen Test wiederholen
    Antwortcode, Wert und Zeit mit dem Ausgangszustand vergleichen.

  36. Alternativen Pfad erneut prüfen
    Weitere Clients, Resolver oder autoritative Server kontrollieren.

  37. Anwendung verifizieren
    Nicht nur das Diagnosewerkzeug testen.

  38. Temporäre Änderungen zurücknehmen
    Logging, Testregeln und Ausnahmen entfernen.

  39. Ursache dokumentieren
    Technischen Nachweis und betroffenen Pfad festhalten.

  40. Prävention festlegen
    Monitoring, Standardisierung oder Konfigurationsverbesserung umsetzen.

7.12.40 Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
IP-Verbindung funktioniert, Name nicht DNS oder lokaler Resolverpfad direkte A-/AAAA-Abfrage
direkter DNS-Test funktioniert, Anwendung nicht Anwendungscache, Proxy oder eigener Resolver Anwendungsresolver und Zieladresse prüfen
nur Kurzname schlägt fehl Suffix- oder Suchlistenproblem FQDN und Suffixkonfiguration vergleichen
nur ein Client betroffen lokale Konfiguration, Cache oder Hosts-Datei anderen Client und direkte Serverabfrage vergleichen
nur ein DNS-Server betroffen Zone, Cache, Dienst oder Replikation DNS-Server direkt vergleichen
ganze Zone liefert NXDOMAIN falscher Resolver oder fehlende Delegation SOA, NS und autoritative Server prüfen
NOERROR, aber keine A-Antwort Name vorhanden, Datensatztyp fehlt CNAME, AAAA und SOA prüfen
SERVFAIL Rekursion, DNSSEC oder Serverfehler autoritative Abfrage und Protokolle
REFUSED Richtlinie, ACL oder deaktivierte Rekursion Serverkonfiguration und Quellnetz prüfen
Timeout fehlende Antwort Transport, Netzwerk und Serverlast prüfen
UDP schlägt fehl, TCP funktioniert Firewall, MTU, Fragmentierung oder EDNS Netzwerkaufzeichnung und große Antwort prüfen
erste Abfrage langsam, zweite schnell Cacheeffekt kalte und warme Abfrage vergleichen
externe Namen langsam Forwarder oder Rekursion Forwarder direkt prüfen
interne Namen langsam interne Delegation, Forwarder oder AD-DNS interne autoritative Server prüfen
mit VPN falsche Antwort NRPT oder Split-DNS Resolver vor und nach VPN vergleichen
Browser und System liefern verschiedene Antworten Browser-DoH oder Anwendungscache Browserresolver und Systemresolver vergleichen
PTR fehlt, A funktioniert Reverse-Zone oder PTR fehlt Reverse-Delegation prüfen
unterschiedliche Antworten je DC AD-Replikation repadmin und direkte DNS-Abfragen
nur große Antworten scheitern EDNS-, MTU- oder Fragmentierungsproblem UDP/TCP-Vergleich
nur signierte Zonen scheitern DNSSEC-Validierungsfehler DS-, DNSKEY- und EDE-Auswertung
neuer Datensatz bleibt unsichtbar positiver oder negativer Cache TTL und Cacheebenen prüfen
SRV vorhanden, Dienst nicht erreichbar Zielhost, Port oder Dienst fehlerhaft SRV-Ziel und Dienstport prüfen

7.12.41 Typische Diagnosefehler

7.12.42 Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Eine einzelne erfolgreiche Cacheabfrage ist keine ausreichende Verifikation.

7.12.43 Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Zeitpunkt:
<Datum und Uhrzeit>

Betroffener Client:
<Hostname und IP-Adresse>

Betroffene Anwendung:
<Anwendung oder Dienst>

Abfragename:
<FQDN oder IP-Adresse>

Datensatztyp:
<A, AAAA, CNAME, PTR, SRV, MX, TXT, NS oder SOA>

Erwartetes Ergebnis:
<Sollwert>

Tatsächliches Ergebnis:
<Istwert, Antwortcode und Antwortzeit>

Verwendeter Resolver:
<DNS-Server und Schnittstelle>

Resolverpfad:
<klassisches DNS, NRPT, VPN, DoH, DoT oder Anwendungsresolver>

Vergleichstests:
<anderer Client, DNS-Server, Transport oder autoritativer Server>

Nachgewiesene Ursache:
<technischer Befund>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

Durchgeführte Maßnahme:
<genau eine kontrollierte Änderung>

Risiko und Rückweg:
<Beschreibung>

Verifikation:
<identischer Test, Anwendungstest und weitere Systeme>

Präventionsmaßnahme:
<Monitoring, Standardisierung oder Konfigurationsänderung>

7.12.44 Checkliste

7.12.45 Schnellreferenz

Aufgabe Befehl
Windows-Netzwerkkonfiguration Get-NetIPConfiguration
vollständige Windows-IP-Konfiguration ipconfig /all
Windows-DNS-Serveradressen Get-DnsClientServerAddress
Windows-DNS-Clientkonfiguration Get-DnsClient
Linux-Resolverzustand resolvectl status
macOS-Resolverzustand scutil --dns
wirksame NRPT-Richtlinie Get-DnsClientNrptPolicy
konfigurierte NRPT-Regeln Get-DnsClientNrptRule
verschlüsselter DNS-Clientzustand netsh dnsclient show state
verschlüsselte DNS-Endpunkte netsh dnsclient show encryption
Systemauflösung unter Windows Resolve-DnsName <Name>
direkte A-Abfrage Resolve-DnsName <Name> -Type A -Server <DNS-IP> -DnsOnly
direkte AAAA-Abfrage Resolve-DnsName <Name> -Type AAAA -Server <DNS-IP> -DnsOnly
CNAME prüfen Resolve-DnsName <Name> -Type CNAME -Server <DNS-IP> -DnsOnly
SRV prüfen Resolve-DnsName <SRV-Name> -Type SRV -Server <DNS-IP> -DnsOnly
PTR prüfen Resolve-DnsName <IP> -Type PTR -Server <DNS-IP> -DnsOnly
SOA prüfen Resolve-DnsName <Zone> -Type SOA -Server <DNS-IP> -DnsOnly
NS prüfen Resolve-DnsName <Zone> -Type NS -Server <DNS-IP> -DnsOnly
direkte Abfrage mit dig dig @<DNS-IP> <Name> <Typ>
Reverse-Abfrage mit dig dig @<DNS-IP> -x <IP>
öffentliche Delegation verfolgen dig <Name> <Typ> +trace
TCP-DNS unter Windows Resolve-DnsName <Name> -Server <DNS-IP> -DnsOnly -TcpOnly
TCP-DNS mit dig dig @<DNS-IP> <Name> <Typ> +tcp
DNSSEC-Daten anfordern dig @<DNS-IP> <Name> <Typ> +dnssec
Windows-Clientcache Get-DnsClientCache
Windows-DNS-Dienst Get-Service DNS
Windows-DNS-Zonen Get-DnsServerZone
Windows-DNS-Datensätze Get-DnsServerResourceRecord -ZoneName <Zone>
Windows-DNS-Forwarder Get-DnsServerForwarder
Windows-DNS-Rekursion Get-DnsServerRecursion
Windows-DNS-Statistiken Get-DnsServerStatistics
DNS-Leistungsindikatoren Get-Counter -ListSet DNS
vorhandene Windows-DNS-Protokolle Get-WinEvent -ListLog "*DNS*"
AD-DNS-Test dcdiag /test:DNS /v /s:<DC-Name>
AD-Replikationsübersicht repadmin /replsummary
AD-Replikationsdetails repadmin /showrepl

Ändernde Befehle, die nicht als erste Diagnose verwendet werden dürfen:

Clear-DnsClientCache
Clear-DnsServerCache
Register-DnsClient
ipconfig /flushdns
ipconfig /registerdns
Set-DnsClientServerAddress
Set-DnsServerForwarder
Set-DnsServerRecursion
Set-DnsServerCache
Set-DnsServerZoneAging
Start-DnsServerScavenging
Add-DnsServerPrimaryZone
Add-DnsServerResourceRecord
Remove-DnsServerResourceRecord
Restart-Service DNS

7.12.46 Quellen

Offizielle Microsoft-Dokumentation

Offizielle Projektdokumentation

Standards

Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.

7.13 Datenträger oder Dateisystem ist voll

7.13.1 Ziel dieser Seite

Diese Seite beschreibt die systematische Diagnose, wenn ein System, Datenträger, Volume, Dateisystem, Speicherpool, Container oder eine Anwendung keinen weiteren Speicherplatz verwenden kann.

Ziele der Diagnose:

Ein gemeldetes „Dateisystem voll“ bedeutet nicht zwangsläufig, dass die physische Festplatte vollständig belegt ist.

7.13.2 Sicherheitskennzeichnungen

Kennzeichnung Bedeutung
LESEND erfasst ausschließlich Zustände und Messwerte
LASTERZEUGEND kann CPU, Arbeitsspeicher oder Datenträger-I/O deutlich belasten
ÄNDERND verändert Konfigurationen oder Systemzustände
LÖSCHEND entfernt Daten und kann Informationen unwiederbringlich zerstören
AUSFALLRISIKO kann Dienste, Dateisysteme oder ganze Systeme unterbrechen

Grundregeln:

7.13.3 Mögliche Fehlerklassen

Fehlerklasse Beschreibung Typischer Nachweis
Datenblöcke voll nutzbare Speicherkapazität ist erschöpft df, Get-Volume, diskutil info
Inodes erschöpft zu viele Dateien, obwohl noch Datenblöcke frei sind df -i
Benutzer- oder Gruppenquota erreicht einzelner Benutzer oder Dienst darf nichts mehr speichern quota, FSRM, Dateisystemquota
Projekt- oder Verzeichnisquota erreicht bestimmter Pfad besitzt ein eigenes Limit XFS-Projektquota, FSRM
Anwendungsquota erreicht Anwendung begrenzt Speicher unabhängig vom Dateisystem Anwendungskonfiguration und Protokolle
Snapshot-Speicher voll Snapshots oder Shadow Copies belegen den freien Bereich VSS-, APFS-, Btrfs- oder ZFS-Auswertung
Thin Pool voll zugrunde liegender Thin-Provisioning-Pool besitzt keinen freien Platz LVM-, SAN- oder Hypervisoranzeige
Thin-Pool-Metadaten voll Verwaltungsbereich des Thin Pools ist erschöpft lvs mit metadata_percent
Container-Layer voll beschreibbare Container-Schicht oder Containerhost ist voll Docker- oder Runtime-Auswertung
Kubernetes-Ephemeralspeicher voll Node oder Pod überschreitet Ephemeral-Storage-Grenzen DiskPressure, Eviction-Ereignisse
Dateisystem schreibgeschützt Dateisystem wurde wegen Fehlern nur lesbar eingebunden Mountoptionen, Kernel- und Systemprotokolle
Physischer Datenträgerfehler Schreibvorgänge scheitern durch Hardware- oder I/O-Fehler SMART, Ereignisse, Kernelmeldungen
Gelöschte Datei noch geöffnet Verzeichniseintrag ist gelöscht, Prozess hält Datei weiterhin geöffnet lsof +L1
Reservierter Speicher freier Bereich steht normalen Benutzern nicht zur Verfügung Dateisystem- und Reservierungsdaten
Versteckte Daten unter Mountpoint Dateien liegen unterhalb eines später darüber eingebundenen Dateisystems Mountstruktur und Wartungsprüfung
Kapazität des Backends voll lokaler Client zeigt nur einen vorgelagerten NAS-, SAN- oder Cloudspeicher Backend-, Pool- und Quotaauswertung

7.13.4 Typische Symptome und Fehlermeldungen

Mögliche Symptome:

Typische Meldungen:

No space left on device
ENOSPC
Disk full
There is not enough space on the disk
Not enough disk space
Quota exceeded
EDQUOT
Read-only file system
EROFS
I/O error
DiskPressure
Evicted
ephemeral-storage
Thin pool is full
Metadata space exhausted

No space left on device kann sowohl auf erschöpfte Datenblöcke als auch auf erschöpfte Inodes oder interne Dateisystemreserven hinweisen.

Quota exceeded betrifft dagegen gewöhnlich ein festgelegtes Speicherlimit und nicht zwingend das gesamte Dateisystem.

7.13.5 Sofortmaßnahmen ohne unkontrolliertes Löschen

  1. Exakte Fehlermeldung und Uhrzeit erfassen.
  2. Betroffenen Host, Dienst, Benutzer, Container und Pfad bestimmen.
  3. Kritikalität und Auswirkung bewerten.
  4. Aktuelle Kapazität, Inodes, Quotas und Speicherpools dokumentieren.
  5. Schreibintensive Prozesse und aktuelle Wachstumsrate identifizieren.
  6. Bei akutem Wachstum eine kontrollierte Drosselung oder Beendigung des verursachenden Dienstes prüfen.
  7. Keine unnötigen Neustarts durchführen.
  8. Keine Protokolle, Datenbanken oder Container-Volumes spontan löschen.
  9. Nur eindeutig entbehrliche und freigegebene Daten kontrolliert entfernen.
  10. Nach jeder Maßnahme denselben Speichertest wiederholen.

Ein Neustart kann die Situation verschärfen, wenn ein Dienst beim Start temporären Speicher benötigt oder eine Datenbank wegen fehlenden Speicherplatzes keine Wiederherstellung durchführen kann.

7.13.6 Speicherpfad vollständig abbilden

Der sichtbare Pfad kann mehrere Speicherebenen durchlaufen:

Anwendung
→ Anwendungspfad
→ Container oder virtuelle Maschine
→ Mountpoint oder Laufwerksbuchstabe
→ Dateisystem
→ Partition oder logisches Volume
→ Thin Pool, RAID oder Storage Pool
→ physischer Datenträger, NAS oder SAN

Jede Ebene kann ein eigenes Limit besitzen.

Beispiel:

Anwendung schreibt nach /var/lib/app
→ Docker-Bind-Mount
→ /srv/containers/app
→ ext4-Dateisystem
→ LVM Logical Volume
→ LVM Thin Pool
→ RAID-Verbund
→ physische SSDs

Freier Speicher auf einer Ebene beweist nicht, dass alle anderen Ebenen ebenfalls freien Speicher besitzen.

7.13.7 Grundfragen der Diagnose

Zu klären sind:

7.13.8 Windows – Volumeauslastung erfassen

LESEND

Get-Volume |
  Select-Object `
    DriveLetter,
    FileSystemLabel,
    FileSystem,
    HealthStatus,
    OperationalStatus,
    @{
      Name = "SizeGiB"
      Expression = {
        [math]::Round($_.Size / 1GB, 2)
      }
    },
    @{
      Name = "FreeGiB"
      Expression = {
        [math]::Round($_.SizeRemaining / 1GB, 2)
      }
    },
    @{
      Name = "FreePercent"
      Expression = {
        if ($_.Size -gt 0) {
          [math]::Round(
            100 * $_.SizeRemaining / $_.Size,
            1
          )
        }
      }
    }

Dateisystemlaufwerke der aktuellen PowerShell-Sitzung:

Get-PSDrive `
  -PSProvider FileSystem

Lokale logische Laufwerke:

Get-CimInstance `
  -ClassName Win32_LogicalDisk `
  -Filter "DriveType=3" |
  Select-Object `
    DeviceID,
    VolumeName,
    FileSystem,
    Size,
    FreeSpace

Get-PSDrive kann auch eingebundene Dateisystemlaufwerke anzeigen. Bei Netzwerkfreigaben können Quotas oder serverseitige Einschränkungen dazu führen, dass die gemeldete Verfügbarkeit nicht der gesamten Backendkapazität entspricht.

7.13.9 Windows – Datenträger, Partition und Volume zuordnen

LESEND

Get-Disk |
  Select-Object `
    Number,
    FriendlyName,
    PartitionStyle,
    OperationalStatus,
    HealthStatus,
    Size

Get-Partition |
  Select-Object `
    DiskNumber,
    PartitionNumber,
    DriveLetter,
    Type,
    Size

Get-Partition |
  Get-Volume |
  Select-Object `
    DriveLetter,
    FileSystemLabel,
    FileSystem,
    Size,
    SizeRemaining

Von Speicherverwaltungsanbietern gemeldete physische Datenträger:

Get-PhysicalDisk |
  Select-Object `
    FriendlyName,
    MediaType,
    OperationalStatus,
    HealthStatus,
    Size

Zu beachten:

7.13.10 Windows – große Verzeichnisse und Dateien eingrenzen

Eine rekursive Suche kann auf großen Dateisystemen erhebliche I/O-Last verursachen. Der Suchpfad muss deshalb möglichst eng begrenzt werden.

LESEND, LASTERZEUGEND

Größe der direkten Unterverzeichnisse eines bekannten Pfades:

$ScanRoot = "C:\Data"

Get-ChildItem `
  -LiteralPath $ScanRoot `
  -Directory `
  -Force `
  -ErrorAction SilentlyContinue |
ForEach-Object {
  $Measurement = Get-ChildItem `
    -LiteralPath $_.FullName `
    -File `
    -Force `
    -Recurse `
    -ErrorAction SilentlyContinue |
  Measure-Object `
    -Property Length `
    -Sum

  [pscustomobject]@{
    Path = $_.FullName
    SizeGiB = [math]::Round(
      $Measurement.Sum / 1GB,
      2
    )
  }
} |
Sort-Object `
  -Property SizeGiB `
  -Descending

Größte Dateien unter einem begrenzten Pfad:

Get-ChildItem `
  -LiteralPath "C:\Data" `
  -File `
  -Force `
  -Recurse `
  -ErrorAction SilentlyContinue |
Sort-Object `
  -Property Length `
  -Descending |
Select-Object `
  -First 20 `
  FullName,
  Length,
  LastWriteTime

Einschränkungen:

7.13.11 Windows – versteckte und reservierte Speicherverbraucher prüfen

VSS und Shadow Copies

LESEND

vssadmin list shadowstorage

vssadmin list shadows

Zu prüfen sind:

Shadow Copies dürfen nicht spontan gelöscht oder verkleinert werden. Sie können für Wiederherstellungen, offene Backups oder andere Dienste benötigt werden.

Windows-Komponentenspeicher analysieren

LESEND, LASTERZEUGEND

Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore

Die im Explorer angezeigte Größe von WinSxS darf nicht durch manuelles Löschen von Dateien korrigiert werden. Hardlinks können die scheinbare Verzeichnisgröße beeinflussen.

Systemdateien und weitere Bereiche

Zu prüfen sind:

Diese Dateien dürfen nicht allein aufgrund ihrer Größe entfernt werden.

7.13.12 Windows – Quotas prüfen

NTFS-Quota

LESEND, administrative Berechtigung erforderlich

fsutil quota query C:

File Server Resource Manager

Get-FsrmQuota |
  Select-Object `
    Path,
    Size,
    Usage,
    SoftLimit,
    Status,
    Template

Das FSRM-Modul ist nur vorhanden, wenn die entsprechende Windows-Server-Rolle beziehungsweise Verwaltungsfunktion installiert ist.

Zu unterscheiden sind:

Wenn nur ein Benutzer oder ein bestimmtes Verzeichnis betroffen ist, muss zuerst die wirksame Quota geprüft werden.

7.13.13 Windows – Storageereignisse auswerten

LESEND

Get-WinEvent `
  -FilterHashtable @{
    LogName = "System"
    StartTime = (Get-Date).AddHours(-6)
  } |
Where-Object {
  $_.ProviderName -in @(
    "disk",
    "Ntfs",
    "ReFS",
    "volsnap",
    "storport"
  )
} |
Select-Object `
  TimeCreated,
  ProviderName,
  Id,
  LevelDisplayName,
  Message

Zu korrelieren sind:

Ein Volume kann gleichzeitig nahezu voll und technisch fehlerhaft sein. Die Freigabe von Speicher behebt dann nicht zwangsläufig die eigentliche Ursache.

7.13.14 Linux – Dateisystembelegung erfassen

LESEND

df -hT

Wichtige Felder:

Feld Bedeutung
Filesystem zugrunde liegendes Gerät oder logischer Speicher
Type Dateisystemtyp
Size Gesamtkapazität
Used belegter Speicher
Avail verfügbarer Speicher
Use% prozentuale Auslastung
Mounted on Mountpoint

Bestimmten Pfad prüfen:

df -hT /var/lib/app

Exakte Blockwerte:

df -B1 /var/lib/app

df wertet das Dateisystem aus, in dem der angegebene Pfad liegt. Das ist zuverlässiger, als den Mountpoint nur anhand einer angenommenen Verzeichnisstruktur zu erraten.

7.13.15 Linux – Inodes prüfen

LESEND

df -i

Bestimmten Pfad prüfen:

df -i /var/lib/app

Eine mögliche Einordnung:

Blockbelegung Inodebelegung Einordnung
hoch normal große Dateien oder große Datenmengen
normal hoch sehr viele kleine Dateien
hoch hoch Kombination aus Datenmenge und Dateianzahl
normal normal Quota, Reservierung, anderer Mountpoint oder anderer Fehler

Bei erschöpften Inodes können keine neuen Dateien angelegt werden, obwohl noch Datenblöcke frei sind.

Typische Verursacher:

7.13.16 Linux – Mounts und Speichergeräte zuordnen

LESEND

findmnt

Gezielte Ausgabe:

findmnt \
  -o TARGET,SOURCE,FSTYPE,OPTIONS

Bestimmten Pfad zuordnen:

findmnt \
  --target /var/lib/app

Blockgeräte:

lsblk \
  -o NAME,TYPE,FSTYPE,SIZE,FSAVAIL,FSUSE%,MOUNTPOINTS

Zu prüfen sind:

Wenn ein vorgesehenes Dateisystem nicht eingebunden ist, kann eine Anwendung unbemerkt in das darunterliegende Root-Dateisystem schreiben.

7.13.17 Linux – große Verzeichnisse und Dateien finden

Die Suche sollte auf das betroffene Dateisystem begrenzt werden.

LESEND, LASTERZEUGEND

Direkte Unterverzeichnisse:

du \
  -x \
  -h \
  --max-depth=1 \
  /var |
sort -h

Zusammenfassung eines bestimmten Pfades:

du \
  -x \
  -s \
  -h \
  /var/lib/app

Größte Dateien mit GNU find:

find \
  /var/lib/app \
  -xdev \
  -type f \
  -printf '%s\t%p\n' |
sort -nr |
head -n 20

Wichtige Optionen:

Option Bedeutung
-x bei du bleibt im selben Dateisystem
-xdev bei find überschreitet keine Dateisystemgrenze
--max-depth=1 wertet nur die direkte Verzeichnisebene aus
-type f beschränkt die Suche auf reguläre Dateien

Die Option -printf ist eine GNU-find-Funktion und steht nicht auf jedem Unix-System zur Verfügung.

7.13.18 Unterschied zwischen df und du untersuchen

df und du messen unterschiedliche Dinge:

Wenn df eine hohe Belegung zeigt, du aber deutlich weniger Daten findet, sind insbesondere zu prüfen:

Sparse Files vergleichen:

du -h /pfad/datei

du \
  -h \
  --apparent-size \
  /pfad/datei

Die scheinbare Dateigröße kann größer als der tatsächlich belegte Speicher sein.

7.13.19 Gelöschte, aber weiterhin geöffnete Dateien prüfen

Unter Unix-ähnlichen Systemen wird der belegte Speicher einer gelöschten Datei erst freigegeben, wenn kein Prozess mehr einen offenen Dateideskriptor auf sie hält.

LESEND

sudo lsof +L1

Zu prüfen sind:

Ein Neustart des gesamten Systems ist nicht die erste Maßnahme. Wenn die Ursache bestätigt ist, sollte der betroffene Dienst kontrolliert neu geladen oder neu gestartet werden. Dabei sind Auswirkung und Wiederanlaufbedingungen zu prüfen.

7.13.20 Linux – Journald und Protokollwachstum prüfen

Aktuelle Journalbelegung:

LESEND

journalctl --disk-usage

Journaldateien und Protokollverzeichnisse:

du \
  -x \
  -h \
  --max-depth=1 \
  /var/log |
sort -h

Logrotate-Konfiguration im Debugmodus prüfen:

sudo logrotate \
  -d \
  /etc/logrotate.conf

logrotate -d führt keine Rotation aus, zeigt aber die geplante Verarbeitung.

Zu prüfen sind:

Das Löschen eines Protokolls behebt nicht den Prozess, der es unkontrolliert erzeugt.

7.13.21 Linux – Benutzer-, Gruppen- und Projektquotas prüfen

Quota des aktuellen Benutzers:

LESEND

quota -s

Quotaübersicht vorhandener quota-fähiger Dateisysteme:

sudo repquota -a

XFS-Quotaauswertung:

sudo xfs_quota \
  -x \
  -c 'report -h' \
  /mountpoint

Zu unterscheiden sind:

Eine noch laufende Grace Period kann erklären, warum Schreiben zunächst möglich war und später ohne sichtbare Änderung der Gesamtkapazität fehlschlägt.

7.13.22 LVM und Thin Provisioning prüfen

LESEND

sudo pvs

sudo vgs

sudo lvs \
  -a \
  -o lv_name,vg_name,lv_size,pool_lv,origin,data_percent,metadata_percent

Besonders kritisch sind:

Ein Thin Pool kann voll sein, obwohl ein Gastbetriebssystem oder Logical Volume scheinbar noch freien logischen Speicher anzeigt.

Das Erweitern eines Speichers muss in der richtigen Reihenfolge erfolgen:

Backend oder physischer Datenträger
→ Partition oder PV
→ Volume Group oder Pool
→ Logical Volume
→ Dateisystem
→ Anwendung

Nicht jede Ebene ist in jeder Architektur vorhanden.

7.13.23 Btrfs und ZFS prüfen

Btrfs

LESEND

sudo btrfs filesystem usage -T /mountpoint

sudo btrfs subvolume list /mountpoint

Zu prüfen sind:

Bei Btrfs können Daten- und Metadatenbereiche unterschiedlich ausgelastet sein. Eine einfache df-Ausgabe reicht deshalb nicht immer für die vollständige Einordnung.

ZFS

zpool list

zfs list -o space

Snapshots:

zfs list \
  -t snapshot \
  -o name,used,refer,creation

Zu prüfen sind:

Snapshots und Copy-on-Write-Daten können Speicher belegen, obwohl aktuelle Dateien bereits gelöscht wurden.

7.13.24 macOS – Speicherzustand prüfen

LESEND

df -h

Bestimmten Pfad prüfen:

df -h /System/Volumes/Data

Datenträger und Partitionen:

diskutil list

Informationen zum Startvolume:

diskutil info /

APFS-Struktur:

diskutil apfs list

APFS-Snapshots:

diskutil apfs listSnapshots /

Lokale Time-Machine-Snapshots:

tmutil listlocalsnapshots /

Große Verzeichnisse unterhalb des Datenvolumes:

LESEND, LASTERZEUGEND

sudo du \
  -x \
  -h \
  -d 1 \
  /System/Volumes/Data \
  2>/dev/null |
sort -h

Gelöschte, noch geöffnete Dateien:

sudo lsof +L1

Bei APFS teilen sich mehrere Volumes den freien Speicher eines gemeinsamen Containers. Daher müssen Volume, Container, Quotas, Reservierungen und Snapshots gemeinsam betrachtet werden.

Die macOS-Anzeige „verfügbar“ kann zusätzlich löschbaren Speicher enthalten. Dieser ist nicht mit unmittelbar freiem Speicher in jeder konkreten Betriebssituation gleichzusetzen.

7.13.25 Docker – Speicherverbrauch prüfen

Docker-Root-Verzeichnis:

LESEND

docker info \
  --format '{{.DockerRootDir}}'

Docker-Speicherübersicht:

docker system df

Detaillierte Übersicht:

docker system df -v

Containergrößen:

docker ps \
  -a \
  --size

Volumes:

docker volume ls

Logpfade der Container:

docker ps -aq |
xargs -r docker inspect \
  --format '{{.Name}} {{.LogPath}}'

Mounts eines bestimmten Containers:

docker inspect \
  --format '{{json .Mounts}}' \
  <Containername>

Zu prüfen sind:

Nicht zulässig als spontane Diagnosemaßnahme:

docker system prune -a --volumes

Dieser Befehl kann gestoppte Container, ungenutzte Images, Netzwerke, Build-Cache und anonyme Volumes entfernen. Vor einer Bereinigung müssen alle betroffenen Objekte einzeln geprüft werden.

Das manuelle Löschen innerhalb von /var/lib/docker kann die Docker-Metadaten und Containerdaten beschädigen.

7.13.26 Kubernetes – Ephemeral Storage und DiskPressure prüfen

Nodezustand:

LESEND

kubectl get nodes

Bestimmten Node untersuchen:

kubectl describe node <Node>

Zu prüfen sind insbesondere:

DiskPressure
NodeHasDiskPressure
ephemeral-storage
imagefs.available
imagefs.inodesFree
nodefs.available
nodefs.inodesFree

Ereignisse:

kubectl get events \
  --all-namespaces \
  --sort-by=.metadata.creationTimestamp

Betroffenen Pod untersuchen:

kubectl describe pod \
  <Pod> \
  -n <Namespace>

Persistente Volumes:

kubectl get pvc \
  --all-namespaces

Die angezeigte PVC-Kapazität ist nicht automatisch der aktuell freie Speicher innerhalb des eingebundenen Dateisystems.

Lokaler Ephemeral Storage kann unter anderem umfassen:

Bei Node-Druck kann der Kubelet Pods beenden, um Ressourcen zurückzugewinnen. Das Löschen einzelner Pods behebt die Ursache nicht, wenn Logs, Images oder Anwendungen sofort erneut denselben Speicherverbrauch erzeugen.

7.13.27 Anwendungen und Dienste als Verursacher prüfen

Häufige Speicherverbraucher:

Bereich Mögliche Ursache
Protokolle fehlende Rotation, Debugmodus, Fehlerschleife
Datenbank Transaktionslog, WAL, Temp-Bereich, Replikationsverzug
Backup fehlende Retention, doppelte Sicherungen, abgebrochene Jobs
Container unbeschränkte Logs, alte Images, beschreibbare Layer
Monitoring hochauflösende Metriken, zu lange Aufbewahrung
Mail Queue, Anhänge, Quarantäne
Druck blockierte Spooldateien
Anwendung Cache, Sitzungen, Uploads, Exporte
Betriebssystem Updates, Dumps, temporäre Dateien
Entwicklung Build-Artefakte, Paketcache, Testdaten
Virtualisierung Snapshots, virtuelle Festplatten, Replikation
Dateidienst Benutzerdateien, Papierkorb, Versionierung
Security EDR-Quarantäne, Scanprotokolle, Forensikdaten

Zu prüfen sind:

7.13.28 Netzwerkfreigaben, NAS und SAN prüfen

Bei SMB, NFS, iSCSI, Fibre Channel oder Cloudspeicher müssen Client und Backend getrennt geprüft werden.

Zu erfassen sind:

Mögliche Sonderfälle:

Herstellerspezifische Lösch-, Snapshot- und Poolbefehle dürfen erst nach Prüfung der jeweiligen Dokumentation verwendet werden.

7.13.29 Schreibgeschütztes Dateisystem und Hardwarefehler abgrenzen

Linux-Mountstatus:

LESEND

findmnt \
  -o TARGET,SOURCE,FSTYPE,OPTIONS

Aktuelle Kernelmeldungen:

sudo dmesg \
  --ctime |
grep -Ei \
  'error|i/o|filesystem|read-only|corrupt|nvme|ata|scsi|ext4|xfs|btrfs'

Systemprotokolle:

journalctl \
  -k \
  --since "-2 hours"

Falls smartctl installiert und für das Gerät geeignet ist:

sudo smartctl \
  -a \
  /dev/<Gerät>

macOS-Verifikation:

diskutil verifyVolume /

Ein Dateisystem kann wegen erkannter Fehler auf read-only wechseln. In diesem Fall ist das Löschen von Dateien weder möglich noch die richtige Erstmaßnahme.

Offline-Dateisystemprüfungen wie fsck dürfen nicht ungeprüft auf einem produktiv eingebundenen Dateisystem ausgeführt werden.

Wenn ein Datenträger einen bevorstehenden Ausfall meldet, haben Datensicherung, kontrollierte Außerbetriebnahme und Austausch Vorrang vor einer reinen Speicherbereinigung.

7.13.30 Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Das Root-Dateisystem ist voll, weil ein Dienst ein
Protokoll ohne funktionierende Rotation erzeugt.

Erwarteter Befund:
df zeigt eine hohe Blockbelegung.
Das Protokollverzeichnis enthält eine stark gewachsene Datei.
Die Änderungszeit und die Dienstmeldungen passen zum Fehlerzeitpunkt.

Gegenbeweis:
Das Protokoll ist klein oder wächst nicht.
Die Belegung bleibt auch nach kontrolliertem Stoppen
des Dienstes unverändert.

Testmethode:
Dateisystembelegung, Verzeichnisgröße, Änderungszeit,
offene Dateien und Dienstprotokolle vergleichen.

Erfolgskriterium:
Der verursachende Schreibpfad ist eindeutig nachgewiesen.

Eine belastbare Hypothese enthält:

7.13.31 Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko
unnötige temporäre Daten entfernen Eigentümer und Entbehrlichkeit bestätigt benötigte Sitzungs- oder Arbeitsdaten können verloren gehen
Protokollrotation korrigieren Logwachstum nachgewiesen laufender Dienst kann Logdatei weiter offen halten
Journald begrenzen Journal als Ursache bestätigt ältere Diagnoseinformationen gehen verloren
Anwendungscache bereinigen Cache ist dokumentiert wiederherstellbar Lastspitze beim Neuaufbau
Backupretention korrigieren abgelaufene Sicherungen eindeutig bestimmt Wiederherstellungspunkte gehen verloren
Containerobjekte bereinigen jedes Objekt auf Nutzung geprüft Daten oder Rollbackimages können fehlen
Quota anpassen Quota als Ursache und Kapazität vorhanden unkontrolliertes weiteres Wachstum
Volume erweitern Backendkapazität und korrekte Ebenen bestätigt Partitions- oder Dateisystemschaden bei Fehlern
Thin Pool erweitern Poolgrenze nachgewiesen falsche Erweiterungsebene bleibt wirkungslos
Snapshot entfernen Abhängigkeiten und Retention geprüft Wiederherstellungspunkt geht verloren
Dienst kontrolliert neu starten gelöschte offene Datei nachgewiesen Dienstunterbrechung
fehlerhaften Schreibprozess stoppen akutes Wachstum bestätigt Anwendungs- oder Datenverlust
Storage austauschen Hardwarefehler bestätigt Betriebsunterbrechung und Migrationsrisiko

Vor der Maßnahme sind zu dokumentieren:

7.13.32 Beispiele für verändernde Bereinigungen

Die folgenden Befehle sind keine Erstdiagnose und dürfen nur nach Prüfung und Freigabe verwendet werden.

Systemd-Journal kontrolliert begrenzen

LÖSCHEND

sudo journalctl \
  --rotate \
  --vacuum-size=<Zielgröße>

Dabei werden archivierte Journaldateien bis zur angegebenen Zielgröße bereinigt. Relevante Protokolle müssen vorher ausgewertet oder gesichert werden.

Windows-Komponentenspeicher bereinigen

ÄNDERND

Dism.exe /Online /Cleanup-Image /StartComponentCleanup

Dieser Befehl darf nur nach der vorherigen Analyse mit /AnalyzeComponentStore und unter Berücksichtigung laufender Wartungs- oder Updatevorgänge verwendet werden.

Docker-Bereinigung

Vor jedem Prune-Befehl müssen mindestens folgende Ausgaben geprüft werden:

docker system df -v

docker ps -a

docker image ls

docker volume ls

Prune-Befehle sind löschend. Insbesondere --volumes darf nicht verwendet werden, ohne jedes betroffene Volume und dessen Datenverantwortung geprüft zu haben.

7.13.33 Maßnahmen, die nicht spontan ausgeführt werden dürfen

rm -rf auf unbekannten Verzeichnissen
Löschen unter /var/lib/docker
docker system prune -a --volumes
Löschen aktiver Datenbankdateien
Löschen von WAL- oder Transaktionslogs
Löschen aller Snapshots
vssadmin delete shadows
unkontrolliertes Verkleinern des VSS-Speichers
manuelles Löschen aus WinSxS
Leeren produktiver Protokolle ohne Sicherung
fsck auf einem schreibend eingebundenen Dateisystem
Ändern reservierter ext4-Blöcke ohne Kapazitätsplanung
Vergrößern einer Partition ohne Backup und Ebenenprüfung
Entfernen von Kubernetes-PVCs
Löschen unbekannter Container-Volumes
Deaktivieren von Quotas ohne Ursachenanalyse
Neustart des gesamten Hosts als erste Maßnahme

Eine Datei mit der Endung .log, .tmp, .bak oder .old ist nicht automatisch entbehrlich.

7.13.34 Vollständiger Diagnoseablauf

  1. Fehlermeldung vollständig aufnehmen
    Wortlaut, Anwendung, Benutzer und Zeitpunkt dokumentieren.

  2. Betroffenen Pfad bestimmen
    Exakten Datei-, Volume-, Mount- oder Containerpfad erfassen.

  3. Auswirkung bestimmen
    Einzelne Anwendung, Benutzer, Host oder Standort unterscheiden.

  4. Schreibtest nicht unkontrolliert wiederholen
    Zusätzliche Schreibvorgänge können die Lage verschärfen.

  5. Speicherebene bestimmen
    Anwendung, Container, Dateisystem, Volume, Pool und Backend zuordnen.

  6. Gesamtkapazität und freien Speicher erfassen
    Werte in Prozent und absoluten Größen dokumentieren.

  7. Inodes prüfen
    Besonders bei vielen kleinen Dateien.

  8. Quotas prüfen
    Benutzer-, Gruppen-, Projekt-, Verzeichnis- und Anwendungsquotas unterscheiden.

  9. Schreibschutz prüfen
    Read-only-Mount oder Dateisystemfehler ausschließen.

  10. Speicherpool prüfen
    RAID, LVM, Thin Pool, Storage Spaces, NAS oder SAN berücksichtigen.

  11. Snapshots prüfen
    VSS, APFS, Btrfs, ZFS, Hypervisor und Storage-Snapshots erfassen.

  12. Wachstumsrate bestimmen
    Aktuelle Werte mit Monitoring oder früheren Messungen vergleichen.

  13. Große Verzeichnisse eingrenzen
    Suche auf das betroffene Dateisystem beschränken.

  14. Große Dateien bestimmen
    Besitzer, Zweck und Änderungszeit dokumentieren.

  15. Viele kleine Dateien berücksichtigen
    Inodeverbrauch und Dateianzahl untersuchen.

  16. Gelöschte offene Dateien prüfen
    Besonders nach manueller Loglöschung.

  17. Protokolle und Rotation prüfen
    Fehlerschleifen, Debugmodus und Retention untersuchen.

  18. Datenbanken prüfen
    Daten-, Transaktions-, WAL- und Temp-Bereiche unterscheiden.

  19. Backupdaten prüfen
    Retention, abgebrochene Jobs und doppelte Sicherungen untersuchen.

  20. Containerdaten prüfen
    Images, Layer, Volumes, Bind-Mounts und Logs unterscheiden.

  21. Kubernetes-Ephemeralspeicher prüfen
    Nodefs, Imagefs, Inodes, Limits und Evictions auswerten.

  22. Betriebssystembereiche prüfen
    Updates, Dumps, Cache, temporäre Dateien und Papierkorb untersuchen.

  23. Hardware- und I/O-Fehler prüfen
    Ereignisse, Kernelmeldungen und Storagezustand korrelieren.

  24. Hypothese und Gegenbeweis formulieren
    Ursache vor jeder Änderung messbar beschreiben.

  25. Akutes Wachstum kontrollieren
    Verursachenden Schreibprozess nur mit Freigabe drosseln oder stoppen.

  26. Minimale sichere Entlastung planen
    Nur bestätigte, entbehrliche Daten auswählen.

  27. Eine Maßnahme durchführen
    Nicht mehrere Variablen gleichzeitig verändern.

  28. Freien Speicher erneut messen
    Absoluten Wert und Prozentwert dokumentieren.

  29. Ursprünglichen Schreibvorgang testen
    Anwendung und nicht nur Diagnosewerkzeug prüfen.

  30. Weitere Ebenen verifizieren
    Pool, Volume, Dateisystem und Anwendung erneut kontrollieren.

  31. Wachstum weiter beobachten
    Prüfen, ob der Speicher sofort wieder abnimmt.

  32. Dauerhafte Ursache beheben
    Rotation, Retention, Quota, Kapazität oder Anwendung korrigieren.

  33. Monitoring verbessern
    Prozentwert, freien Absolutwert, Inodes und Wachstumsrate überwachen.

  34. Vorgang dokumentieren
    Ursache, Maßnahme, Risiko, Ergebnis und Prävention festhalten.

7.13.35 Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
df zeigt 100 %, du ebenfalls sehr hoch sichtbare Dateien belegen das Dateisystem größte Verzeichnisse bestimmen
df zeigt 100 %, du deutlich weniger offene gelöschte Dateien, Snapshots oder Metadaten lsof +L1 und Snapshotprüfung
Blöcke frei, Inodes 100 % zu viele Dateien Verzeichnisse mit vielen kleinen Dateien bestimmen
nur ein Benutzer betroffen Benutzerquota Quota des Benutzers prüfen
nur ein Verzeichnis betroffen FSRM-, Projekt- oder Anwendungsquota wirksames Verzeichnislimit prüfen
Dateisystem ist read-only Dateisystem- oder Storagefehler Kernel- und Ereignisprotokolle
Root-Dateisystem voll Logs, Cache, Container oder fehlender Mount /var, /tmp, Docker und Mounts prüfen
nach Loglöschung keine Freigabe Datei wird noch geöffnet gehalten lsof +L1
Dockerhost voll Images, Layer, Volumes oder Logs docker system df -v
Container meldet voll, Host nicht Container-Layer, Volume oder Quota Mounts und beschreibbaren Layer prüfen
Kubernetes-Node zeigt DiskPressure Nodefs, Imagefs oder Inodes knapp Nodebeschreibung und Ereignisse
PVC vorhanden, Anwendung meldet voll Dateisystem innerhalb des PVC oder Storagequota Volume im Pod und Backend prüfen
Logical Volume hat Platz, Thin Pool ist voll Thin Provisioning erschöpft lvs mit Daten- und Metadatenprozent
Dateien wurden gelöscht, Snapshotgröße steigt Copy-on-Write hält alte Blöcke Snapshotbelegung prüfen
Windows-Volume voll, Verzeichnissumme kleiner VSS, Systemdateien oder unzugängliche Bereiche VSS und Systembereiche prüfen
macOS zeigt widersprüchliche Werte APFS-Container, Snapshots oder löschbarer Speicher APFS-Container und Snapshots prüfen
NAS-Freigabe voll, NAS-Pool hat Platz Share-, Benutzer- oder Volumequota Backendquota prüfen
Speicher wächst sehr schnell Fehlerschleife oder unkontrollierter Job Änderungszeit und aktive Prozesse
nach Bereinigung sofort wieder voll Ursache weiterhin aktiv Wachstumsquelle erneut messen
I/O-Fehler zusätzlich zu wenig Speicher Hardware- oder Pfadfehler Storagezustand und Ereignisse

7.13.36 Typische Diagnosefehler

7.13.37 Verifikation

Nach der Maßnahme müssen mindestens folgende Punkte geprüft werden:

Ein einzelner erfolgreicher Schreibtest reicht nicht aus, wenn der Speicher weiterhin unkontrolliert wächst.

7.13.38 Prävention und Monitoring

Zu überwachen sind:

Ein sinnvoller Alarm berücksichtigt nicht nur einen festen Prozentwert.

Beispiel:

Warnung:
Auslastung über organisationsspezifischem Grenzwert
UND weniger als definierter absoluter Freispeicher

Kritisch:
Kapazität reicht bei aktueller Wachstumsrate
nicht bis zum nächsten geplanten Eingriff

Zusätzliche Präventionsmaßnahmen:

7.13.39 Dokumentationsvorlage

Störung:
<exakte Fehlermeldung>

Zeitpunkt:
<Datum und Uhrzeit>

Betroffenes System:
<Hostname, VM, Container oder Node>

Betroffene Anwendung:
<Dienst oder Anwendung>

Betroffener Pfad:
<Laufwerksbuchstabe, Mountpoint oder Dateipfad>

Speicherebenen:
<Anwendung, Dateisystem, Volume, Pool und Backend>

Dateisystem:
<Typ und Mountoptionen>

Gesamtkapazität:
<Wert>

Freier Speicher vor der Maßnahme:
<Wert und Prozent>

Inodebelegung:
<Wert und Prozent>

Wirksame Quota:
<Typ, Limit und Nutzung>

Snapshotbelegung:
<Wert und Bestand>

Thin-Pool-Auslastung:
<Daten- und Metadatenprozent>

Wachstumsrate:
<Wert pro Stunde oder Tag>

Größte Verbraucher:
<Pfade, Größen und Besitzer>

Gelöschte offene Dateien:
<Befund>

Storage- und Hardwarezustand:
<Befund>

Nachgewiesene Ursache:
<technischer Nachweis>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

Durchgeführte Maßnahme:
<genau beschriebene Änderung>

Risiko und Rückweg:
<Beschreibung>

Freier Speicher nach der Maßnahme:
<Wert und Prozent>

Verifikation:
<Schreibtest, Anwendungstest und Monitoring>

Prävention:
<Rotation, Retention, Quota, Kapazität oder Monitoring>

7.13.40 Checkliste

7.13.41 Schnellreferenz

Aufgabe Befehl
Windows-Volumes Get-Volume
PowerShell-Dateisystemlaufwerke Get-PSDrive -PSProvider FileSystem
Windows-Datenträger Get-Disk
Windows-Partitionen Get-Partition
physische Windows-Speicherobjekte Get-PhysicalDisk
NTFS-Quota fsutil quota query C:
FSRM-Quotas Get-FsrmQuota
VSS-Speicher vssadmin list shadowstorage
Shadow Copies vssadmin list shadows
Windows-Komponentenspeicher Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore
Linux-Dateisystembelegung df -hT
Linux-Pfad prüfen df -hT <Pfad>
Linux-Inodes df -i
Mounts findmnt
Mount eines Pfades findmnt --target <Pfad>
Blockgeräte lsblk -o NAME,TYPE,FSTYPE,SIZE,FSAVAIL,FSUSE%,MOUNTPOINTS
Verzeichnisgrößen du -x -h --max-depth=1 <Pfad>
gelöschte offene Dateien lsof +L1
Journalbelegung journalctl --disk-usage
Benutzerquota quota -s
Quotaübersicht repquota -a
XFS-Quota xfs_quota -x -c 'report -h' <Mountpoint>
LVM Physical Volumes pvs
LVM Volume Groups vgs
LVM und Thin Pools lvs -a -o lv_name,vg_name,lv_size,pool_lv,origin,data_percent,metadata_percent
Btrfs-Auslastung btrfs filesystem usage -T <Mountpoint>
ZFS-Poolauslastung zpool list
ZFS-Datasetbelegung zfs list -o space
macOS-Dateisystembelegung df -h
macOS-Datenträger diskutil list
APFS-Struktur diskutil apfs list
APFS-Snapshots diskutil apfs listSnapshots /
lokale Time-Machine-Snapshots tmutil listlocalsnapshots /
Docker-Speicherübersicht docker system df -v
Docker-Containergrößen docker ps -a --size
Kubernetes-Nodes kubectl get nodes
Kubernetes-Nodezustand kubectl describe node <Node>
Kubernetes-PVCs kubectl get pvc --all-namespaces

7.13.42 Quellen

Offizielle Microsoft-Dokumentation

Offizielle Linux- und Projektdokumentation

Offizielle Docker-Dokumentation

Offizielle Kubernetes-Dokumentation

Offizielle Apple-Dokumentation

Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.

7.14 TLS- oder HTTPS-Verbindung schlägt fehl

7.14.1 Ziel dieser Seite

Diese Seite beschreibt die systematische Diagnose, wenn eine TLS- oder HTTPS-Verbindung nicht aufgebaut werden kann, eine Zertifikatswarnung erscheint oder eine Anwendung erst nach dem TLS-Handshake fehlschlägt.

Ziele der Diagnose:

Eine erfolgreiche TCP-Verbindung zu Port 443 beweist noch nicht, dass TLS oder HTTPS funktioniert.

7.14.2 Sicherheitskennzeichnungen

Kennzeichnung Bedeutung
LESEND erfasst ausschließlich Zustände und Messwerte
NETZAKTIV baut eine Verbindung auf oder ruft externe Ressourcen ab
SENSITIV kann Zertifikate, Header, interne Namen oder Sicherheitsinformationen anzeigen
ÄNDERND verändert Konfigurationen, Truststores oder Dienste
AUSFALLRISIKO kann bestehende TLS-Verbindungen oder Dienste unterbrechen

Grundregeln:

7.14.3 Vollständiger HTTPS-Verbindungspfad

Anwendung
→ Proxykonfiguration
→ DNS-Auflösung
→ IPv4- oder IPv6-Zieladresse
→ Routing und Firewall
→ TCP-Verbindung
→ TLS ClientHello
→ SNI und ALPN
→ TLS ServerHello
→ Serverzertifikat und Zertifikatskette
→ Zertifikatsprüfung
→ optionales Clientzertifikat
→ verschlüsselte HTTP-Anfrage
→ Reverse Proxy oder Load Balancer
→ Backend
→ HTTP-Antwort

Jede Ebene kann einen eigenen Fehler verursachen.

Eine Browsermeldung über HTTPS beweist nicht automatisch, dass das Zertifikat die Ursache ist. Der Fehler kann bereits bei DNS, TCP, Proxy, TLS-Version, SNI oder im Backend entstehen.

7.14.4 Fehlerklassen unterscheiden

Fehlerklasse Typischer Befund
DNS-Fehler Zielname wird nicht oder falsch aufgelöst
Routing- oder Firewallfehler Zieladresse oder Port ist nicht erreichbar
TCP-Fehler Timeout, Verbindungsablehnung oder TCP Reset
Proxyfehler falscher Proxy, Authentifizierung oder blockierter CONNECT-Tunnel
TLS-Protokollfehler Client und Server finden keine gemeinsame TLS-Version
Cipher-Fehler keine gemeinsame Cipher Suite oder Signaturalgorithmus
Zertifikatsnamenfehler FQDN stimmt nicht mit dem SAN überein
Gültigkeitsfehler Zertifikat ist abgelaufen oder noch nicht gültig
Vertrauensfehler Root-CA wird nicht vertraut
Kettenfehler Intermediate-CA fehlt oder Kette kann nicht aufgebaut werden
Sperrprüfungsfehler CRL- oder OCSP-Prüfung schlägt fehl
SNI-Fehler Server liefert das Zertifikat eines falschen virtuellen Hosts
ALPN-Fehler HTTP/1.1, HTTP/2 oder anderes Anwendungsprotokoll wird falsch ausgehandelt
mTLS-Fehler Clientzertifikat fehlt, ist falsch oder wird nicht akzeptiert
TLS-Inspection-Fehler Proxy ersetzt das Serverzertifikat durch ein eigenes Zertifikat
Serverkonfigurationsfehler Zertifikat, Schlüssel, Bindung oder Listener ist fehlerhaft
Reverse-Proxy-Fehler Frontend-TLS funktioniert, Backend-TLS schlägt fehl
HTTP-Fehler TLS funktioniert, Server liefert aber einen HTTP-Fehlercode
Anwendungsfehler Browser funktioniert, bestimmte Anwendung jedoch nicht
Truststore-Abweichung Betriebssystem, Browser, Java oder Container vertraut unterschiedlichen CAs

7.14.5 Typische Symptome und Fehlermeldungen

Mögliche Meldungen:

Certificate verify failed
Unable to get local issuer certificate
Unable to verify the first certificate
Self-signed certificate
Certificate has expired
Certificate is not yet valid
Hostname mismatch
Unknown CA
Bad certificate
Certificate required
Handshake failure
Protocol version
No shared cipher
TLS alert
Connection reset by peer
Connection refused
Operation timed out
ERR_SSL_PROTOCOL_ERROR
ERR_CERT_AUTHORITY_INVALID
ERR_CERT_DATE_INVALID
SEC_ERROR_UNKNOWN_ISSUER
SSL_ERROR_NO_CYPHER_OVERLAP
PKIX path building failed
unable to find valid certification path
The underlying connection was closed
Could not establish trust relationship
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

Die genaue Meldung, Anwendung, Uhrzeit und Clientplattform müssen dokumentiert werden.

7.14.6 Mindestinformationen erfassen

Vor der Diagnose sind festzuhalten:

Private Schlüssel, Passwörter, Sitzungscookies, API-Keys und Zugriffstokens gehören nicht in die Dokumentation.

7.14.7 TCP-, TLS- und HTTP-Fehler trennen

Testebene Erfolgsnachweis
DNS vorgesehene A- oder AAAA-Adresse wird geliefert
Netzwerk Route zum vorgesehenen Ziel besteht
TCP Drei-Wege-Handshake mit Zielport funktioniert
TLS Handshake wird mit gemeinsamer Version und Cipher abgeschlossen
Zertifikatsprüfung Name, Gültigkeit, Kette und Vertrauen sind korrekt
HTTP gültige HTTP-Antwort wird empfangen
Anwendung ursprüngliche Funktion arbeitet vollständig

Mögliche Einordnung:

TCP schlägt fehl
→ noch kein TLS-Problem nachgewiesen

TCP funktioniert, TLS schlägt fehl
→ TLS-Version, Cipher, SNI, Zertifikat oder mTLS prüfen

TLS funktioniert, HTTP 502 erscheint
→ Reverse Proxy oder Backend prüfen

HTTP 200 erscheint, Anwendung funktioniert nicht
→ Anwendungslogik, API, Cookie, Authentifizierung oder Inhalt prüfen

7.14.8 DNS und Zieladresse prüfen

Windows

Resolve-DnsName `
  -Name "app.example.test" `
  -Type A

Resolve-DnsName `
  -Name "app.example.test" `
  -Type AAAA

Linux und macOS

dig app.example.test A

dig app.example.test AAAA

Zu prüfen sind:

Wenn mehrere IP-Adressen vorhanden sind, müssen die tatsächlich verwendete Adresse und das Verhalten der einzelnen Ziele verglichen werden.

7.14.9 IPv4 und IPv6 getrennt testen

NETZAKTIV

curl \
  -4 \
  -v \
  https://app.example.test/

curl \
  -6 \
  -v \
  https://app.example.test/

Möglicher Befund:

Ein scheinbarer TLS-Fehler kann durch einen fehlerhaften IPv6-Pfad oder ein falsch konfiguriertes Zielsystem verursacht werden.

7.14.10 TCP-Port prüfen

Windows

Test-NetConnection `
  -ComputerName "app.example.test" `
  -Port 443

Wichtige Felder:

RemoteAddress
RemotePort
InterfaceAlias
SourceAddress
TcpTestSucceeded

Linux und macOS

nc \
  -vz \
  app.example.test \
  443

Alternativ kann bereits curl -v oder openssl s_client zum Aufbau der TCP-Verbindung verwendet werden.

Mögliche Ergebnisse:

Ergebnis Einordnung
Timeout Firewall, Routing, Proxy oder nicht antwortender Server
Connection refused Ziel erreichbar, aber kein Listener oder aktive Ablehnung
TCP Reset Firewall, Load Balancer oder Dienst beendet Verbindung
TCP erfolgreich erst jetzt TLS-Handshake untersuchen

Ein erfolgreicher Ping beweist keine Erreichbarkeit von TCP-Port 443.

7.14.11 Systemzeit und Zeitzone prüfen

Zertifikate besitzen einen Gültigkeitszeitraum:

Not Before
Not After

Eine falsche Systemzeit kann ein gültiges Zertifikat als abgelaufen oder noch nicht gültig erscheinen lassen.

Windows

Get-Date

w32tm /query /status

w32tm /query /source

Linux

date

date -u

timedatectl status

macOS

date

date -u

systemsetup -gettimezone

Zu prüfen sind:

7.14.12 HTTPS mit curl prüfen

NETZAKTIV, SENSITIV

curl \
  --connect-timeout 10 \
  --max-time 30 \
  -v \
  https://app.example.test/

Die verbose Ausgabe kann zeigen:

Verbose Ausgaben können sensible HTTP-Header enthalten und müssen vor Weitergabe geprüft werden.

Nur die HTTP-Header anzeigen:

curl \
  -sS \
  -D - \
  -o /dev/null \
  https://app.example.test/

Einige Anwendungen unterstützen keine HEAD-Anfrage. Deshalb ist eine normale GET-Anfrage mit verworfener Antwort häufig aussagekräftiger als curl -I.

7.14.13 Zertifikatsprüfung testweise abgrenzen

NUR ZUR DIAGNOSE, NICHT ALS LÖSUNG

curl \
  -v \
  -k \
  https://app.example.test/

Einordnung:

Normaler Test Test mit -k Einordnung
schlägt fehl funktioniert Zertifikatsvalidierung wahrscheinlich betroffen
schlägt fehl schlägt ebenfalls fehl nicht nur Zertifikatsvertrauen betroffen
funktioniert funktioniert kein aktueller Validierungsfehler
funktioniert nur auf einem Client anderer Client schlägt fehl Truststore oder Anwendung unterscheidet sich

-k deaktiviert die Überprüfung des Serverzertifikats. Es behebt weder DNS-, TCP-, TLS-Version-, Cipher-, SNI-, ALPN- noch mTLS-Probleme zuverlässig.

Die Option darf nicht in produktiven Skripten, Anwendungen oder dauerhaften Konfigurationen verbleiben.

7.14.14 Bestimmte IP-Adresse mit richtigem Hostnamen testen

Ein direkter Aufruf über eine IP-Adresse verändert häufig:

Deshalb sollte curl --resolve verwendet werden:

curl \
  -v \
  --resolve \
  app.example.test:443:192.0.2.25 \
  https://app.example.test/

Damit bleiben erhalten:

Nur die Ziel-IP-Adresse wird für den Test festgelegt.

Dies ist besonders nützlich bei:

7.14.15 TLS-Handshake mit OpenSSL prüfen

NETZAKTIV, SENSITIV

openssl s_client \
  -connect app.example.test:443 \
  -servername app.example.test \
  -showcerts \
  -verify_return_error \
  -verify_hostname app.example.test \
  </dev/null

Wichtige Ausgabebereiche:

CONNECTED
Certificate chain
subject
issuer
Server certificate
SSL handshake
Protocol
Cipher
ALPN protocol
Verify return code

Erfolgreiche OpenSSL-Verifikation:

Verify return code: 0 (ok)

Wichtige Optionen:

Option Bedeutung
-connect Zielhost und Port
-servername übermittelt SNI
-showcerts zeigt die vom Server gesendeten Zertifikate
-verify_return_error beendet bei Validierungsfehlern
-verify_hostname prüft den angegebenen Hostnamen
</dev/null beendet die Eingabe nach dem Handshake

Nicht jede ältere OpenSSL-Version unterstützt alle genannten Optionen.

7.14.16 Zertifikat lokal untersuchen

Vorhandene Zertifikatsdatei im PEM-Format:

LESEND

openssl x509 \
  -in server.pem \
  -noout \
  -subject \
  -issuer \
  -serial \
  -dates \
  -fingerprint \
  -sha256

Subject Alternative Names:

openssl x509 \
  -in server.pem \
  -noout \
  -ext subjectAltName

Vollständige Zertifikatsinformationen:

openssl x509 \
  -in server.pem \
  -noout \
  -text

Zu prüfen sind:

Private Schlüssel dürfen mit diesen Ausgaben nicht verwechselt oder weitergegeben werden.

7.14.17 Hostname und Subject Alternative Name prüfen

Für die Identitätsprüfung ist der vorgesehene Dienstname entscheidend.

Beispiel:

Aufgerufener Name:
app.example.test

Erforderlicher SAN:
DNS:app.example.test

Zu prüfen sind:

Beispiele:

*.example.test

kann typischerweise abdecken:

app.example.test
mail.example.test

aber nicht:

example.test
app.intern.example.test

Der CNAME-Zielname muss nicht zwingend im Zertifikat stehen. Entscheidend ist grundsätzlich der Name, unter dem der Client den Dienst aufruft und dessen Identität er prüft.

7.14.18 Zertifikatskette verstehen

Eine typische Kette:

Serverzertifikat
→ Intermediate-CA
→ Root-CA

Aufgaben:

Element Aufgabe
Serverzertifikat identifiziert den Dienst
Intermediate-CA verbindet Serverzertifikat mit vertrauenswürdiger CA
Root-CA bildet den lokalen Vertrauensanker

Der Server sollte gewöhnlich senden:

Serverzertifikat
Intermediate-CA-Zertifikat
weitere erforderliche Intermediate-Zertifikate

Die Root-CA wird gewöhnlich nicht als Teil der Serverkette benötigt, weil sie bereits im Truststore des Clients vorhanden sein muss.

Typische Kettenfehler:

7.14.19 Zertifikatskette lokal verifizieren

Vorhandene Dateien:

server.pem
intermediates.pem
root-ca.pem

LESEND

openssl verify \
  -purpose sslserver \
  -CAfile root-ca.pem \
  -untrusted intermediates.pem \
  server.pem

Erfolgreiches Ergebnis:

server.pem: OK

Dieser Test beweist die Gültigkeit nur gegenüber den ausdrücklich angegebenen CA-Dateien. Er beweist nicht, dass der Truststore der ursprünglichen Anwendung identisch konfiguriert ist.

7.14.20 Gültigkeitszeitraum prüfen

openssl x509 \
  -in server.pem \
  -noout \
  -dates

Mögliche Ausgabe:

notBefore=...
notAfter=...

Zu prüfen sind:

Ein erneuertes Zertifikat auf dem Dateisystem beweist nicht, dass der Listener dieses Zertifikat bereits verwendet.

7.14.21 Sperrprüfung, CRL und OCSP untersuchen

Mögliche Sperrmechanismen:

OCSP-Stapling des Servers anfordern:

NETZAKTIV

openssl s_client \
  -connect app.example.test:443 \
  -servername app.example.test \
  -status \
  </dev/null

Unter Windows kann eine vorhandene Zertifikatsdatei geprüft werden:

NETZAKTIV, kann AIA- und Sperrlistenadressen abrufen

certutil -verify -urlfetch server.cer

Zu prüfen sind:

Ein Fehler bei der Sperrprüfung darf nicht pauschal durch Abschalten der Sperrprüfung gelöst werden.

7.14.22 TLS-Versionen prüfen

Aktuelle TLS-Version aushandeln:

openssl s_client \
  -connect app.example.test:443 \
  -servername app.example.test \
  </dev/null

TLS 1.2 ausdrücklich testen:

openssl s_client \
  -connect app.example.test:443 \
  -servername app.example.test \
  -tls1_2 \
  </dev/null

TLS 1.3 ausdrücklich testen:

openssl s_client \
  -connect app.example.test:443 \
  -servername app.example.test \
  -tls1_3 \
  </dev/null

Zu prüfen sind:

Das Aktivieren veralteter TLS-Versionen ist keine geeignete Dauerlösung. Stattdessen muss die veraltete Gegenstelle aktualisiert oder ersetzt werden.

7.14.23 Cipher Suites und Algorithmen prüfen

Lokal verfügbare OpenSSL-Cipher anzeigen:

openssl ciphers -v

Unter Windows:

Get-TlsCipherSuite |
  Select-Object `
    Name,
    Protocols,
    Cipher,
    Hash,
    Exchange

Zu unterscheiden sind:

Ein RSA-Serverzertifikat, eine ECDSA-Cipher und ein bestimmter Schlüsselaustausch sind unterschiedliche Bestandteile und dürfen nicht gleichgesetzt werden.

TLS 1.3 definiert Cipher Suites anders als frühere TLS-Versionen. Deshalb ist eine reine Cipherliste ohne TLS-Version und Clientkontext unvollständig.

7.14.24 SNI prüfen

SNI übermittelt den gewünschten Servernamen bereits während des TLS-Handshakes.

Mit SNI:

openssl s_client \
  -connect 192.0.2.25:443 \
  -servername app.example.test \
  </dev/null

Ohne ausdrückliches SNI:

openssl s_client \
  -connect 192.0.2.25:443 \
  </dev/null

Wenn unterschiedliche Zertifikate erscheinen, verwendet der Server namensbasierte virtuelle TLS-Hosts.

Zu prüfen sind:

Ein Test ohne SNI kann ein anderes Zertifikat liefern als die reale Anwendung und darf deshalb nicht allein bewertet werden.

7.14.25 ALPN, HTTP/1.1 und HTTP/2 prüfen

ALPN wird während des TLS-Handshakes verwendet, um das Anwendungsprotokoll auszuhandeln.

openssl s_client \
  -connect app.example.test:443 \
  -servername app.example.test \
  -alpn h2,http/1.1 \
  </dev/null

Mit curl:

curl \
  --http1.1 \
  -v \
  https://app.example.test/

Falls die verwendete curl-Version HTTP/2 unterstützt:

curl \
  --http2 \
  -v \
  https://app.example.test/

Zu prüfen sind:

HTTP/3 verwendet QUIC über UDP und muss getrennt von klassischem HTTPS über TCP untersucht werden.

7.14.26 Gegenseitige TLS-Authentifizierung prüfen

Bei normalem TLS authentifiziert sich der Server gegenüber dem Client.

Bei Mutual TLS authentifizieren sich beide Seiten:

Serverzertifikat
+
Clientzertifikat

Test mit autorisiertem Clientzertifikat:

NETZAKTIV, SENSITIV

openssl s_client \
  -connect app.example.test:443 \
  -servername app.example.test \
  -cert client.pem \
  -key client.key \
  -verify_return_error \
  </dev/null

Zu prüfen sind:

Die Datei client.key ist besonders schützenswert. Pfade, Berechtigungen und Diagnoseausgaben müssen entsprechend behandelt werden.

7.14.27 Proxykonfiguration prüfen

Windows-WinHTTP-Proxy

netsh winhttp show proxy

Linux und macOS

env |
grep -i proxy

Mögliche Variablen:

HTTP_PROXY
HTTPS_PROXY
NO_PROXY
http_proxy
https_proxy
no_proxy

Zu prüfen sind:

Ein erfolgreicher Browsertest beweist nicht, dass ein Windows-Dienst, Java-Prozess oder Container dieselbe Proxykonfiguration verwendet.

7.14.28 TLS-Inspection erkennen

Bei TLS-Inspection beendet ein Sicherheitsgerät die TLS-Verbindung und baut anschließend eine neue TLS-Verbindung zum Ziel auf.

Mögliche Hinweise:

Vergleich:

  1. Zertifikat vom betroffenen Client erfassen.
  2. Zertifikat aus einem anderen autorisierten Netzwerk erfassen.
  3. Subject, Issuer, SAN, Seriennummer und Fingerprint vergleichen.
  4. Proxy- und Sicherheitsrichtlinie prüfen.
  5. Truststore der betroffenen Anwendung prüfen.

TLS-Inspection darf nicht ohne Freigabe umgangen werden. Eine notwendige Ausnahme muss über den vorgesehenen Sicherheitsprozess erfolgen.

7.14.29 Windows-Zertifikatsspeicher prüfen

Stores anzeigen:

LESEND

Get-ChildItem `
  -Path Cert:\CurrentUser

Get-ChildItem `
  -Path Cert:\LocalMachine

Persönliche Zertifikate des Computers:

Get-ChildItem `
  -Path Cert:\LocalMachine\My |
Select-Object `
  Subject,
  Issuer,
  Thumbprint,
  NotBefore,
  NotAfter,
  HasPrivateKey

Vertrauenswürdige Root-CAs:

Get-ChildItem `
  -Path Cert:\LocalMachine\Root |
Select-Object `
  Subject,
  Issuer,
  Thumbprint,
  NotAfter

Intermediate-CAs:

Get-ChildItem `
  -Path Cert:\LocalMachine\CA |
Select-Object `
  Subject,
  Issuer,
  Thumbprint,
  NotAfter

Zu unterscheiden sind:

Ein Zertifikat im Benutzerstore steht einem Dienstkonto oder Computersystem nicht automatisch zur Verfügung.

7.14.30 Windows-Schannel-Ereignisse prüfen

LESEND

Get-WinEvent `
  -FilterHashtable @{
    LogName = "System"
    ProviderName = "Schannel"
    StartTime = (Get-Date).AddHours(-6)
  } |
Select-Object `
  TimeCreated,
  Id,
  LevelDisplayName,
  Message

Zu korrelieren sind:

Schannel-Ereignisse allein enthalten nicht immer den vollständigen Fehlerpfad. Sie müssen mit Anwendung, CAPI2, Proxy, Netzwerk und Serverseite korreliert werden.

7.14.31 Windows-CAPI2-Protokoll prüfen

Pfad in der Ereignisanzeige:

Anwendungs- und Dienstprotokolle
→ Microsoft
→ Windows
→ CAPI2
→ Operational

Vorhandene Ereignisse ausgeben:

Get-WinEvent `
  -LogName "Microsoft-Windows-CAPI2/Operational" `
  -MaxEvents 100 |
Select-Object `
  TimeCreated,
  Id,
  LevelDisplayName,
  Message

CAPI2 kann unter anderem Hinweise liefern zu:

Das Protokoll ist möglicherweise nicht aktiviert. Eine Aktivierung ist eine Konfigurationsänderung und muss zeitlich begrenzt sowie dokumentiert werden.

7.14.32 Windows-TLS-Richtlinien erfassen

Verfügbare Cipher Suites:

Get-TlsCipherSuite

Vorhandene Schannel-Protokolleinstellungen:

Get-ChildItem `
  -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols" `
  -Recurse `
  -ErrorAction SilentlyContinue

Zu prüfen sind:

Registrywerte dürfen nicht nach allgemeinen Internetanleitungen verändert werden. Betriebssystemversion, Anwendung und Microsoft-Dokumentation müssen zusammenpassen.

7.14.33 Linux- und macOS-Truststores prüfen

OpenSSL-Version:

openssl version -a

OpenSSL-Konfigurationsverzeichnis:

openssl version -d

Je nach Linux-Distribution können CA-Zertifikate unter anderem verwaltet werden über:

/etc/ssl/certs
/etc/pki/ca-trust
/usr/local/share/ca-certificates

Die tatsächlich verwendeten Pfade hängen von Distribution, TLS-Bibliothek und Anwendung ab.

macOS-Systemschlüsselbund anzeigen:

security find-certificate \
  -a \
  -Z \
  /Library/Keychains/System.keychain

Zu prüfen sind:

Ein erfolgreicher Test mit Apple-Systemvertrauen beweist nicht, dass eine separat installierte OpenSSL- oder Java-Version denselben Truststore verwendet.

7.14.34 Java-Truststore prüfen

Java-Version:

java -version

Java-Pfad und Eigenschaften:

java \
  -XshowSettings:properties \
  -version

Standard-CA-Store anzeigen:

keytool \
  -list \
  -cacerts

Bestimmten Truststore anzeigen:

keytool \
  -list \
  -keystore <Truststore>

Zu prüfen sind:

Ein Import in den Betriebssystem-Truststore behebt keinen Java-Fehler, wenn die Anwendung ausschließlich ihren eigenen Truststore verwendet.

7.14.35 Container separat prüfen

Der Host und ein Container können unterschiedliche besitzen:

Containerkonfiguration:

docker inspect \
  <Containername>

Proxyvariablen:

docker exec \
  <Containername> \
  env

Zeit im Container:

docker exec \
  <Containername> \
  date -u

Falls curl im Image vorhanden ist:

docker exec \
  <Containername> \
  curl \
  -v \
  https://app.example.test/

Vergleich:

Test auf dem Host
gegen
Test im Container

Wenn nur der Container fehlschlägt, sind insbesondere CA-Bundle, Proxy, DNS, Netzwerknamespace und Anwendungslaufzeit zu prüfen.

Produktive Images dürfen nicht spontan durch Installation zusätzlicher Diagnosepakete verändert werden. Falls Werkzeuge fehlen, ist ein freigegebener Diagnosecontainer oder ein reproduzierbares Testimage zu verwenden.

7.14.36 Serverzertifikat und privaten Schlüssel zuordnen

Zertifikat und privater Schlüssel müssen dasselbe Schlüsselpaar bilden.

Öffentlichen Schlüssel des Zertifikats hashen:

LESEND

openssl x509 \
  -in server.pem \
  -pubkey \
  -noout |
openssl pkey \
  -pubin \
  -outform DER |
openssl sha256

Öffentlichen Anteil des privaten Schlüssels hashen:

SENSITIV – Zugriff auf privaten Schlüssel erforderlich

openssl pkey \
  -in server.key \
  -pubout \
  -outform DER |
openssl sha256

Die beiden Hashwerte müssen übereinstimmen.

Dieser Test gibt nicht den privaten Schlüssel aus. Der Zugriff auf die Schlüsseldatei bleibt dennoch sicherheitskritisch.

Zu prüfen sind zusätzlich:

7.14.37 Nginx prüfen

Konfigurationssyntax:

LESEND

sudo nginx -t

Dienststatus:

systemctl \
  status nginx \
  --no-pager

Protokolle:

journalctl \
  -u nginx \
  --since "-2 hours"

Zu prüfen sind:

Bei einer kombinierten Zertifikatsdatei steht gewöhnlich zuerst das Serverzertifikat, gefolgt von den erforderlichen Intermediate-Zertifikaten.

7.14.38 Apache HTTP Server prüfen

Konfigurationssyntax:

LESEND

sudo apachectl configtest

Alternativ, abhängig von der Installation:

sudo httpd -t

Dienststatus:

systemctl \
  status apache2 \
  --no-pager

oder:

systemctl \
  status httpd \
  --no-pager

Zu prüfen sind:

Der genaue Dienstname und die Konfigurationspfade hängen von Distribution und Installation ab und dürfen nicht angenommen werden.

7.14.39 IIS-Bindungen prüfen

Falls das WebAdministration-Modul vorhanden ist:

Import-Module WebAdministration

HTTPS-Bindungen:

Get-WebBinding `
  -Protocol https

SSL-Bindungen:

Get-ChildItem `
  -Path IIS:\SslBindings

Zu prüfen sind:

Ein gültiges Zertifikat im Windows-Zertifikatsspeicher beweist nicht, dass es an die richtige IIS-Site gebunden ist.

7.14.40 Reverse Proxy und Load Balancer getrennt prüfen

Mögliche TLS-Abschnitte:

Client
→ TLS zum Load Balancer
→ TLS zum Reverse Proxy
→ TLS zum Backend

Oder:

Client
→ TLS-Terminierung am Load Balancer
→ unverschlüsseltes HTTP zum Backend

Für jeden Abschnitt getrennt erfassen:

Typische Fehler:

Ein erfolgreicher externer TLS-Test prüft nicht automatisch die Verbindung vom Reverse Proxy zum Backend.

7.14.41 HTTP-Ebene nach erfolgreichem TLS prüfen

Wenn der TLS-Handshake erfolgreich ist, muss der HTTP-Statuscode ausgewertet werden.

Status Mögliche Einordnung
200 Anfrage grundsätzlich erfolgreich
301 oder 302 Redirectziel prüfen
400 fehlerhafte Anfrage oder Hostheader
401 Authentifizierung erforderlich oder fehlgeschlagen
403 Zugriff verweigert
404 Pfad oder virtueller Host falsch
405 HTTP-Methode nicht erlaubt
408 Request Timeout
421 Anfrage beim falschen Ursprung oder falscher Verbindung
429 Rate Limit
500 Anwendungs- oder Serverfehler
502 Proxy erreicht Backend nicht korrekt
503 Dienst oder Backend nicht verfügbar
504 Backend antwortet nicht rechtzeitig

Redirects verfolgen:

curl \
  -v \
  -L \
  https://app.example.test/

Zu prüfen sind:

Ein HTTP-Fehlercode beweist, dass mindestens eine TLS-Verbindung bereits erfolgreich aufgebaut wurde.

7.14.42 Netzwerkaufzeichnung einsetzen

Eine Netzwerkaufzeichnung ist sinnvoll, wenn unklar bleibt:

Bei TLS 1.3 sind größere Teile des Handshakes verschlüsselt als bei älteren Versionen. Mit Encrypted ClientHello kann auch der bisher sichtbare Servername geschützt werden.

Für die Entschlüsselung moderner TLS-Sitzungen werden in der Regel autorisiert erfasste Sitzungsschlüssel benötigt. Ein Server-Private-Key allein reicht insbesondere bei modernen Schlüsselaustauschverfahren nicht zur nachträglichen Entschlüsselung.

TLS-Schlüsselprotokolle und entschlüsselte Aufzeichnungen enthalten hochsensible Daten und müssen besonders geschützt, zeitlich begrenzt und anschließend sicher entfernt werden.

7.14.43 Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Der Reverse Proxy sendet beim Verbindungsaufbau zum Backend
keinen passenden SNI-Namen und erhält deshalb das
Default-Zertifikat eines anderen virtuellen Hosts.

Erwarteter Befund:
Der OpenSSL-Test gegen die Backend-IP liefert ohne SNI
ein anderes Zertifikat als mit dem vorgesehenen SNI-Namen.

Gegenbeweis:
Mit und ohne SNI wird dasselbe korrekte Zertifikat geliefert
und die Backendverbindung funktioniert.

Testmethode:
OpenSSL-Verbindungen mit identischer Ziel-IP und
unterschiedlicher SNI-Übermittlung vergleichen.

Erfolgskriterium:
Das abweichende Zertifikat und der fehlerhafte
Proxy-SNI-Pfad sind reproduzierbar nachgewiesen.

Eine belastbare Hypothese enthält:

7.14.44 Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko
Zertifikat erneuern Ablauf oder falsche Gültigkeit bestätigt falsche Bindung oder unvollständige Verteilung
vollständige Kette konfigurieren fehlendes Intermediate bestätigt falsche Reihenfolge oder falsche CA
Zertifikatsbindung korrigieren falscher Listener oder virtueller Host bestätigt andere Site kann betroffen sein
SNI korrigieren falsche Zertifikatsauswahl nachgewiesen weitere virtuelle Hosts betroffen
Backend-SNI korrigieren Proxy sendet falschen Namen Backendrouting ändert sich
Truststore ergänzen vorgesehene CA eindeutig bestätigt zusätzliche CA erhält Vertrauensstatus
Systemzeit korrigieren Zeitabweichung bestätigt Kerberos, Tokens und Logs betroffen
TLS-Policy korrigieren fehlende gemeinsame sichere Version bestätigt ältere Clients können ausfallen
Cipher-Policy korrigieren fehlende sichere Schnittmenge bestätigt Kompatibilität und Sicherheit betroffen
Clientzertifikat erneuern mTLS-Zertifikat fehlerhaft Identitätszuordnung kann ausfallen
Proxyregel korrigieren falscher Proxyweg bestätigt weitere Anwendungen betroffen
TLS-Inspection-Ausnahme Inspection als Ursache bestätigt und freigegeben Sicherheitskontrolle wird verändert
Reverse-Proxy-Backend korrigieren Backend-TLS-Fehler bestätigt Dienstunterbrechung möglich
Dienst kontrolliert neu laden neue Konfiguration geprüft kurze Unterbrechung oder Ladefehler
Load-Balancer-Nodes synchronisieren abweichende Zertifikate bestätigt mehrere produktive Nodes betroffen

Vor der Maßnahme sind zu dokumentieren:

7.14.45 Nicht zulässige Schnelllösungen

Zertifikatsprüfung dauerhaft deaktivieren
curl -k in produktive Skripte übernehmen
verify=false in Anwendungen eintragen
NODE_TLS_REJECT_UNAUTHORIZED=0 setzen
Java-Hostnameprüfung deaktivieren
beliebige Root-CA importieren
selbst signiertes Zertifikat ungeprüft vertrauen
private Schlüssel weitergeben
private Schlüssel in Containerimages einbauen
alte TLS-Versionen pauschal aktivieren
unsichere Cipher dauerhaft aktivieren
Sperrprüfung ohne Risikoanalyse abschalten
Truststore vollständig ersetzen
alle Zertifikate aus Stores löschen
Schannel-Registrywerte nach ungeprüfter Anleitung ändern
Reverse Proxy ohne Konfigurationstest neu starten
Zertifikat nur auf einem Load-Balancer-Node austauschen
TLS-Inspection heimlich umgehen

Eine funktionierende Verbindung ohne Zertifikatsprüfung ist kein Nachweis einer sicheren oder korrekten Lösung.

7.14.46 Vollständiger Diagnoseablauf

  1. Exakte Fehlermeldung aufnehmen
    Wortlaut, Anwendung, Client und Uhrzeit dokumentieren.

  2. Vollständige URL bestimmen
    Schema, FQDN, Port und Pfad erfassen.

  3. Fehlerumfang bestimmen
    Einzelnen Client, Anwendung, Standort oder alle Benutzer unterscheiden.

  4. Letzte Änderungen erfassen
    Zertifikatswechsel, Update, Proxy-, DNS- oder Firewalländerung prüfen.

  5. Systemzeit prüfen
    Datum, UTC, Zeitzone und Synchronisation bestätigen.

  6. DNS-Auflösung prüfen
    A, AAAA und CNAME auswerten.

  7. Tatsächliche Zieladresse bestimmen
    IPv4, IPv6, Load Balancer oder Proxy identifizieren.

  8. TCP-Port prüfen
    Timeout, Ablehnung und erfolgreichen Handshake unterscheiden.

  9. Proxyweg bestimmen
    Direktverbindung, expliziten Proxy, PAC oder TLS-Inspection unterscheiden.

  10. Normalen HTTPS-Test durchführen
    Zertifikatsprüfung nicht deaktivieren.

  11. TLS und HTTP trennen
    Handshakefehler und HTTP-Statuscode unterscheiden.

  12. OpenSSL-Handshake durchführen
    SNI und Hostnamenprüfung ausdrücklich angeben.

  13. TLS-Version dokumentieren
    Ausgehandelte Version erfassen.

  14. Cipher dokumentieren
    Ausgehandelte Cipher Suite erfassen.

  15. ALPN dokumentieren
    HTTP/1.1, HTTP/2 oder anderes Protokoll bestimmen.

  16. Serverzertifikat dokumentieren
    Subject, Issuer, Seriennummer und Fingerprint erfassen.

  17. SAN prüfen
    Aufgerufenen FQDN mit Zertifikat vergleichen.

  18. Gültigkeitszeitraum prüfen
    Server- und Intermediate-Zertifikate berücksichtigen.

  19. Zertifikatskette prüfen
    Fehlende oder falsche Intermediate-CA bestimmen.

  20. Root-Vertrauen prüfen
    Tatsächlichen Truststore der Anwendung untersuchen.

  21. Sperrprüfung prüfen
    CRL, OCSP, AIA und Netzwerkzugriff berücksichtigen.

  22. SNI prüfen
    Test mit und ohne vorgesehenen Servernamen vergleichen.

  23. Einzelne Zieladressen prüfen
    Load-Balancer-Nodes mit --resolve vergleichen.

  24. IPv4 und IPv6 vergleichen
    Unterschiedliche Pfade und Zertifikate bestimmen.

  25. mTLS prüfen
    Clientzertifikat, Schlüssel, Kette und Serververtrauen untersuchen.

  26. TLS-Inspection prüfen
    Zertifikatsaussteller und Fingerprint zwischen Netzen vergleichen.

  27. Anwendungsspezifischen Truststore prüfen
    Betriebssystem, Browser, Java und Container unterscheiden.

  28. Serverbindung prüfen
    Listener, virtuellen Host, Zertifikat und Schlüssel zuordnen.

  29. Zertifikat und Schlüssel vergleichen
    Öffentliche Schlüssel sicher hashen.

  30. Reverse Proxy und Backend trennen
    Frontend- und Backend-TLS einzeln testen.

  31. Serverprotokolle auswerten
    Handshake, Zertifikat, mTLS und Backendfehler korrelieren.

  32. Bei Bedarf Netzwerkaufzeichnung durchführen
    Nur autorisiert, begrenzt und datenschutzkonform.

  33. Hypothese und Gegenbeweis formulieren
    Ursache vor der Änderung messbar festlegen.

  34. Eine kontrollierte Maßnahme durchführen
    Risiko, Rückweg und Freigabe beachten.

  35. Konfiguration vor Reload prüfen
    Beispielsweise nginx -t oder apachectl configtest.

  36. Identischen TLS-Test wiederholen
    Version, Cipher, Zertifikat und Verify-Ergebnis vergleichen.

  37. HTTP-Antwort prüfen
    Statuscode, Redirect und Header auswerten.

  38. Ursprüngliche Anwendung testen
    Nicht nur curl oder OpenSSL verifizieren.

  39. Weitere Clients und Netze prüfen
    Repräsentative Systeme vergleichen.

  40. Temporäre Diagnoseänderungen zurücknehmen
    Logging, Capture, Testzertifikate und Ausnahmen entfernen.

  41. Ursache dokumentieren
    Fehlerhafte Ebene und technischer Nachweis festhalten.

  42. Prävention festlegen
    Monitoring, automatische Erneuerung und Konfigurationstest verbessern.

7.14.47 Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
DNS schlägt fehl Namensauflösung direkte A- und AAAA-Abfrage
TCP-Port 443 nicht erreichbar Routing, Firewall oder Listener Netzwerkpfad und Serverseite
TCP funktioniert, kein ServerHello TLS-Policy, Proxy oder Server Handshake und Serverlogs
curl -k funktioniert, normaler Test nicht Zertifikatsvalidierung Name, Kette, Zeit und Vertrauen
Hostname mismatch falsches Zertifikat oder falscher Name SAN und SNI prüfen
Zertifikat abgelaufen Erneuerung oder falscher Node alle Zieladressen vergleichen
Zertifikat noch nicht gültig Systemzeit oder falsches Zertifikat Zeit und Gültigkeitsbeginn
unbekannte CA Root fehlt oder TLS-Inspection Issuer und Truststore
lokale CA im Browser vertraut, Java nicht separater Java-Truststore keytool -list
Kette unvollständig Intermediate fehlt -showcerts und openssl verify
nur ein Client betroffen lokaler Truststore, Zeit oder Proxy anderen Client vergleichen
nur ein Load-Balancer-Node betroffen Zertifikatsverteilung unvollständig curl --resolve
ohne SNI falsches Zertifikat namensbasierter virtueller Host Test mit korrektem SNI
mit SNI ebenfalls falsches Zertifikat falsche Bindung oder Serverregel Listenerkonfiguration
TLS 1.2 funktioniert, TLS 1.3 nicht TLS-1.3-Pfad oder Intermediär Proxy und Serverpolicy
TLS 1.3 funktioniert, alter Client nicht veralteter Client Clientbibliothek und TLS-Version
keine gemeinsame Cipher Policy- oder Algorithmuskonflikt Client- und Serverlisten vergleichen
Browser funktioniert, Dienst nicht Proxy, Store oder Systemkonto Dienstkontext prüfen
Host funktioniert, Container nicht CA-Bundle, Proxy oder DNS Test im Container
Frontend-TLS funktioniert, HTTP 502 Backend nicht erreichbar oder Backend-TLS Proxy- und Backendlogs
HTTP 504 Backendtimeout Backendpfad und Antwortzeit
Clientzertifikat erforderlich mTLS Zertifikat und Schlüssel prüfen
unknown ca am Server bei mTLS Server vertraut Client-CA nicht Server-Truststore
nur hinter Security-Proxy fehlerhaft TLS-Inspection Zertifikatsaussteller vergleichen
OCSP- oder CRL-Fehler Sperrprüfungsziel nicht erreichbar AIA/CDP und Proxy prüfen
neuer Fingerprint nur auf manchen Nodes unsynchronisierte Zertifikate alle Nodes einzeln prüfen
HTTP 200, Anwendung fehlerhaft oberhalb von TLS Anwendung, Authentifizierung und Inhalt

7.14.48 Typische Diagnosefehler

7.14.49 Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Ein erfolgreicher Test mit deaktivierter Zertifikatsprüfung ist keine gültige Verifikation.

7.14.50 Prävention und Monitoring

Zu überwachen sind:

Empfohlener Zertifikatsprozess:

Erneuerung anfordern
→ Zertifikat und Kette validieren
→ Zertifikat und Schlüssel zuordnen
→ Testsystem oder einzelnen Node aktualisieren
→ Konfiguration prüfen
→ Dienst kontrolliert neu laden
→ externen TLS-Test durchführen
→ alle Nodes aktualisieren
→ Monitoring und Fingerprint prüfen
→ altes Zertifikat kontrolliert entfernen

Die Erneuerung gilt erst als erfolgreich, wenn der produktive Listener das neue Zertifikat tatsächlich ausliefert.

7.14.51 Dokumentationsvorlage

Störung:
<exakte Fehlermeldung>

Zeitpunkt:
<Datum und Uhrzeit>

Betroffener Client:
<Hostname, IP-Adresse und Betriebssystem>

Betroffene Anwendung:
<Browser, Dienst, Container oder Anwendung>

URL:
<vollständige URL>

FQDN:
<Servername>

Port:
<Port>

Aufgelöste Adressen:
<IPv4 und IPv6>

Verwendete Zieladresse:
<IP-Adresse>

Proxyweg:
<direkt, Proxy, PAC oder TLS-Inspection>

TCP-Ergebnis:
<Ergebnis>

TLS-Version:
<ausgehandelte Version>

Cipher Suite:
<ausgehandelte Cipher>

SNI:
<übermittelter Name>

ALPN:
<ausgehandeltes Protokoll>

Zertifikat-Subject:
<Wert>

Subject Alternative Names:
<Werte>

Issuer:
<Wert>

Seriennummer:
<Wert>

SHA-256-Fingerprint:
<Wert>

Gültigkeit:
<Not Before und Not After>

Zertifikatskette:
<Leaf, Intermediate und Root>

Truststore:
<Betriebssystem, Browser, Java oder Anwendung>

Sperrprüfung:
<CRL- und OCSP-Befund>

mTLS:
<erforderlich, Clientzertifikat und Ergebnis>

Reverse-Proxy-Pfad:
<Frontend und Backend>

HTTP-Ergebnis:
<Statuscode, Redirect und Antwortzeit>

Nachgewiesene Ursache:
<technischer Befund>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

Durchgeführte Maßnahme:
<genaue Änderung>

Risiko und Rückweg:
<Beschreibung>

Verifikation:
<identischer TLS-Test und Anwendungstest>

Prävention:
<Monitoring, Erneuerung oder Standardisierung>

7.14.52 Checkliste

7.14.53 Schnellreferenz

Aufgabe Befehl
Windows-DNS Resolve-DnsName app.example.test
Linux/macOS-DNS dig app.example.test A
Windows-TCP-Test Test-NetConnection app.example.test -Port 443
HTTPS-Diagnose curl -v https://app.example.test/
IPv4-Test curl -4 -v https://app.example.test/
IPv6-Test curl -6 -v https://app.example.test/
bestimmte IP mit richtigem Hostnamen curl -v --resolve app.example.test:443:192.0.2.25 https://app.example.test/
TLS-Handshake openssl s_client -connect app.example.test:443 -servername app.example.test </dev/null
Zertifikatskette anzeigen openssl s_client -connect app.example.test:443 -servername app.example.test -showcerts </dev/null
Hostname verifizieren openssl s_client -connect app.example.test:443 -servername app.example.test -verify_hostname app.example.test </dev/null
TLS 1.2 testen openssl s_client -connect app.example.test:443 -servername app.example.test -tls1_2 </dev/null
TLS 1.3 testen openssl s_client -connect app.example.test:443 -servername app.example.test -tls1_3 </dev/null
ALPN testen openssl s_client -connect app.example.test:443 -servername app.example.test -alpn h2,http/1.1 </dev/null
OCSP-Stapling anfordern openssl s_client -connect app.example.test:443 -servername app.example.test -status </dev/null
Zertifikatsdaten openssl x509 -in server.pem -noout -subject -issuer -serial -dates
SAN anzeigen openssl x509 -in server.pem -noout -ext subjectAltName
Zertifikatskette lokal prüfen openssl verify -purpose sslserver -CAfile root-ca.pem -untrusted intermediates.pem server.pem
Windows-Zertifikatsprüfung certutil -verify -urlfetch server.cer
Windows-Zertifikatsspeicher Get-ChildItem Cert:\LocalMachine
Windows-Cipher Suites Get-TlsCipherSuite
WinHTTP-Proxy netsh winhttp show proxy
Schannel-Ereignisse Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Schannel"}
Java-Truststore keytool -list -cacerts
Docker-Test docker exec <Container> curl -v https://app.example.test/
Nginx-Konfigurationstest nginx -t
Apache-Konfigurationstest apachectl configtest
IIS-HTTPS-Bindungen Get-WebBinding -Protocol https

7.14.54 Quellen

Offizielle Microsoft-Dokumentation

Offizielle OpenSSL-Dokumentation

Offizielle curl-Dokumentation

Offizielle Webserver-Dokumentation

Offizielle Java-Dokumentation

Offizielle Wireshark-Dokumentation

Standards

Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.

7.15 Backupjob ist fehlgeschlagen

7.15.1 Ziel dieser Seite

Diese Seite beschreibt die systematische Diagnose, wenn ein Backupjob:

Ziele der Diagnose:

Ein Backupjob gilt nicht allein deshalb als erfolgreich, weil ein Prozess mit Exit-Code 0 beendet wurde oder eine Sicherungsdatei vorhanden ist.

7.15.2 Sicherheitskennzeichnungen

Kennzeichnung Bedeutung
LESEND erfasst ausschließlich Zustände und Messwerte
NETZAKTIV greift auf Quell- oder Zielsysteme zu
LASTERZEUGEND kann Netzwerk, CPU, Arbeitsspeicher oder Storage stark belasten
ÄNDERND verändert Job-, Repository- oder Sicherungszustände
LÖSCHEND entfernt Recovery Points oder Repositorydaten
SENSITIV kann Zugangsdaten, Schlüssel oder geschützte Daten betreffen
AUSFALLRISIKO kann Sicherungen, Wiederherstellungen oder Produktivdienste unterbrechen

Grundregeln:

7.15.3 Ein Backup ist erst durch Wiederherstellung nachgewiesen

Ein technisch vollständiger Backupablauf besteht aus mehreren Nachweisen:

Job wurde geplant
→ Job wurde tatsächlich gestartet
→ Quelle wurde vollständig erfasst
→ konsistenter Sicherungszeitpunkt wurde erzeugt
→ Daten wurden übertragen
→ Daten wurden im Repository gespeichert
→ Metadaten und Katalog wurden geschrieben
→ Recovery Point wurde registriert
→ Integritätsprüfung war erfolgreich
→ Wiederherstellung wurde getestet
→ wiederhergestellte Anwendung funktioniert

Nicht ausreichend sind allein:

7.15.4 Wichtige Begriffe

Begriff Bedeutung
Vollbackup enthält den vollständigen ausgewählten Datenbestand
inkrementelles Backup enthält Änderungen seit der letzten relevanten Sicherung
differenzielles Backup enthält Änderungen seit dem letzten Vollbackup
synthetisches Vollbackup wird im Repository aus vorhandenen Sicherungsdaten erzeugt
Snapshot zeitpunktbezogener Zustand eines Volumes oder Dateisystems
crash-konsistent entspricht ungefähr dem Zustand nach einem unerwarteten Ausfall
anwendungskonsistent Anwendung und Datenbank wurden für den Sicherungspunkt koordiniert
Recovery Point für die Wiederherstellung registrierter Sicherungsstand
Repository logischer Speicherbereich für Backups und Metadaten
Retention Aufbewahrungsregel für Recovery Points
Immutability zeitlich begrenzter Schutz vor Änderung oder Löschung
Air Gap logische oder physische Trennung der Sicherung vom Produktivsystem
RPO maximal tolerierbarer Datenverlust in Zeit
RTO maximal tolerierbare Wiederherstellungsdauer
Backupfenster vorgesehener Zeitraum für die Sicherung
Restore-Test kontrollierter Nachweis der Wiederherstellbarkeit

Ein Storage-Snapshot auf demselben System ist allein kein vollständiger Schutz vor Ausfall, Fehlbedienung, Diebstahl oder Ransomware.

7.15.5 Phasen eines Backupjobs

Phase Mögliche Fehler
Planung falscher Zeitplan, deaktivierter Job, verpasster Start
Vorbereitung Konfiguration, Lizenz, Agent oder Dienst fehlerhaft
Authentifizierung Kennwort, Token, Zertifikat oder Schlüssel abgelaufen
Quellenprüfung Pfad, Volume, VM, Datenbank oder Container fehlt
Snapshot VSS-, LVM-, CSI-, Hypervisor- oder Storagefehler
Anwendungskonsistenz Writer, Datenbank oder Quiescing schlägt fehl
Lesen Berechtigung, Sperre, I/O-Fehler oder beschädigte Datei
Transport DNS, Routing, VPN, Firewall, TLS oder Timeout
Schreiben Repository voll, Quota, Schreibschutz oder Berechtigung
Deduplizierung Index-, Cache- oder Metadatenfehler
Katalogisierung Recovery Point wird nicht registriert
Verifikation Prüfsumme oder Strukturprüfung schlägt fehl
Retention alte Recovery Points werden nicht korrekt verarbeitet
Replikation sekundäre oder externe Kopie wird nicht erstellt
Abschluss Jobstatus, Benachrichtigung oder Monitoring ist falsch

Der erste sichtbare Fehler ist nicht immer die ursprüngliche Ursache. Ein später Repositoryfehler kann beispielsweise durch einen vorher fehlgeschlagenen Snapshot ausgelöst worden sein.

7.15.6 Fehlerklassen unterscheiden

Fehlerklasse Typischer Befund
Job nicht gestartet kein Lauf, kein Log oder nur Schedulerfehler
Job deaktiviert Zeitplan vorhanden, Ausführung aber abgeschaltet
falscher Dienstkontext manueller Start funktioniert, geplanter Lauf nicht
Agent nicht erreichbar Backupserver erreicht Client oder Proxy nicht
Quellpfad fehlt Volume, Freigabe, Mount oder PVC nicht vorhanden
Zugriff verweigert Dienstkonto darf Quelle oder Ziel nicht lesen beziehungsweise schreiben
Snapshot fehlgeschlagen VSS-, Hypervisor-, CSI- oder Storagefehler
Anwendung nicht konsistent Datenbank-Writer oder Quiescing fehlerhaft
Repository voll zu wenig Speicher, Quota oder Thin Pool voll
Repository nicht erreichbar DNS-, Netzwerk-, TLS- oder Mountfehler
Repository gesperrt paralleler Job oder verwaister Lock
Sicherungskette beschädigt erforderliches Voll- oder Inkrementbackup fehlt
Retention fehlerhaft alte Daten bleiben bestehen oder benötigte Punkte werden entfernt
Verschlüsselung fehlerhaft Schlüssel, Passwort oder KMS nicht verfügbar
Prüfsummenfehler Daten oder Repository beschädigt
Timeout Job überschreitet Backupfenster oder Netzwerkgrenze
Teilbackup einige Quellen oder Dateien wurden übersprungen
Katalogfehler Daten vorhanden, Recovery Point jedoch nicht nutzbar
Replikation fehlgeschlagen Primärbackup vorhanden, Zweitkopie fehlt
Immutability-Konflikt gewünschte Änderung oder Retention wird blockiert
Lizenz- oder Kapazitätslimit geschützte Systeme oder Datenmenge überschreiten Produktlimit
Sicherheitsvorfall Repository, Zugangsdaten oder Backupserver wurden manipuliert

7.15.7 Typische Symptome und Fehlermeldungen

Backup failed
Job failed
Partial success
Completed with warnings
Missed schedule
Access denied
Authentication failed
Permission denied
Repository unavailable
Repository is full
Quota exceeded
No space left on device
Snapshot creation failed
VSS writer failed
VSS_E_WRITERERROR
Unable to create snapshot
Volume not found
Source path not found
Connection timed out
Connection reset
TLS certificate verify failed
Repository locked
Stale lock
Checksum mismatch
Hash mismatch
Corrupt backup
Index damaged
Catalog update failed
Retention failed
Prune failed
Unable to decrypt
Encryption key not found
Object lock prevents deletion
Backup window exceeded
Incremental chain is broken
Recovery point unavailable
Restore validation failed

Die exakte Meldung einschließlich Fehlercode, Jobphase und Uhrzeit muss übernommen werden.

7.15.8 Sofortmaßnahmen

  1. Fehlermeldung vollständig dokumentieren.
  2. Job-ID, Jobname und Sicherungsprodukt erfassen.
  3. Start- und Endzeit bestimmen.
  4. Letzten erfolgreichen Recovery Point feststellen.
  5. Betroffene Quellen und Ziele bestimmen.
  6. RPO-Verletzung berechnen.
  7. Aktuelle Logs und Ereignisse sichern.
  8. Snapshot- oder VSS-Zustand prüfen.
  9. Repository nicht bereinigen oder entsperren.
  10. Prüfen, ob noch ein Job aktiv ist.
  11. Kapazität und Quota erfassen.
  12. Bei Sicherheitsverdacht Backupserver und Repository schützen.
  13. Ursache nachweisen, bevor der Job erneut gestartet wird.
  14. Nach der Korrektur einen kontrollierten neuen Lauf durchführen.
  15. Wiederherstellbarkeit des neuen Recovery Points testen.

Wiederholte Neustarts eines Backupjobs können:

7.15.9 RPO und aktuelle Schutzlücke bestimmen

Beispiel:

Letzter erfolgreicher Recovery Point:
01.08.2026 22:00 Uhr

Aktueller Zeitpunkt:
02.08.2026 10:00 Uhr

Aktuelle Schutzlücke:
12 Stunden

Vorgesehenes RPO:
4 Stunden

Ergebnis:
RPO ist bereits verletzt.

Zu dokumentieren sind:

Ein erfolgreicher Job nach der Störung beseitigt nicht rückwirkend die bereits entstandene RPO-Verletzung.

7.15.10 Job und Scheduler unter Windows prüfen

Geplanten Task anzeigen:

LESEND

Get-ScheduledTask `
  -TaskName "<Taskname>"

Laufzeitinformationen:

Get-ScheduledTask `
  -TaskName "<Taskname>" |
Get-ScheduledTaskInfo

Wichtige Felder:

State
LastRunTime
LastTaskResult
NextRunTime
NumberOfMissedRuns

Detaillierte Abfrage mit schtasks:

schtasks /query /tn "<Taskpfad-und-Name>" /v /fo LIST /hresult

Zu prüfen sind:

Ein gemapptes Netzlaufwerk der interaktiven Benutzersitzung steht einem geplanten Task nicht automatisch zur Verfügung. Für geplante Jobs sollte der tatsächlich erreichbare UNC-Pfad verwendet werden.

7.15.11 Windows-Task-Scheduler-Ereignisse prüfen

Vorhandene Ereignisse:

Get-WinEvent `
  -LogName "Microsoft-Windows-TaskScheduler/Operational" `
  -MaxEvents 100 |
Select-Object `
  TimeCreated,
  Id,
  LevelDisplayName,
  Message

Das Operational-Protokoll kann deaktiviert sein. Eine Aktivierung ist eine Konfigurationsänderung und muss dokumentiert werden.

Zu korrelieren sind:

7.15.12 Systemd-Timer unter Linux prüfen

Timerübersicht:

LESEND

systemctl list-timers --all

Bestimmten Timer prüfen:

systemctl \
  status backup.timer \
  --no-pager

Zugehörigen Dienst prüfen:

systemctl \
  status backup.service \
  --no-pager

Letzten Exit-Code erfassen:

systemctl show \
  backup.service \
  -p Result \
  -p ExecMainCode \
  -p ExecMainStatus \
  -p ActiveEnterTimestamp \
  -p ActiveExitTimestamp

Protokolle:

journalctl \
  -u backup.timer \
  -u backup.service \
  --since "-24 hours"

Zu prüfen sind:

7.15.13 Cronjobs prüfen

Cronjobs des aktuellen Benutzers:

crontab -l

Cronjobs von root:

sudo crontab -l

Systemweite Konfigurationen können abhängig von der Distribution unter anderem liegen in:

/etc/crontab
/etc/cron.d/
/etc/cron.hourly/
/etc/cron.daily/
/etc/cron.weekly/
/etc/cron.monthly/

Zu prüfen sind:

Ein Skript, das in einer interaktiven Shell funktioniert, muss nicht unter Cron funktionieren.

7.15.14 Quelle und Sicherungsumfang prüfen

Zu erfassen sind:

Linux-Mounts:

findmnt

lsblk \
  -o NAME,TYPE,FSTYPE,SIZE,FSAVAIL,FSUSE%,MOUNTPOINTS

Windows-Volumes:

Get-Volume

Datei- oder Verzeichnisexistenz:

Test-Path `
  -LiteralPath "<Quellpfad>"

Mögliche Fehler:

Ein erfolgreicher Job kann trotzdem unvollständig sein, wenn der Sicherungsumfang falsch definiert ist.

7.15.15 Kapazität, Inodes und Quotas prüfen

Windows

Get-Volume |
  Select-Object `
    DriveLetter,
    FileSystemLabel,
    FileSystem,
    Size,
    SizeRemaining,
    HealthStatus

Linux

df -hT

df -i

macOS

df -h

Zu prüfen sind:

Ein Backup kann trotz freiem Repository fehlschlagen, wenn der lokale Snapshot-, Cache-, Katalog- oder Temp-Bereich voll ist.

7.15.16 Windows Server Backup prüfen

Status eines laufenden Backups:

LESEND

wbadmin get status

Vorhandene Backupversionen:

wbadmin get versions

Verfügbare Datenträger:

wbadmin get disks

Vorhandene Windows-Server-Backup-Dienste:

Get-Service `
  -Name wbengine,VSS,swprv `
  -ErrorAction SilentlyContinue

Backup- und VSS-Ereignisse:

Get-WinEvent `
  -FilterHashtable @{
    LogName = "Application"
    StartTime = (Get-Date).AddHours(-12)
  } |
Where-Object {
  $_.ProviderName -in @(
    "Microsoft-Windows-Backup",
    "VSS"
  )
} |
Select-Object `
  TimeCreated,
  ProviderName,
  Id,
  LevelDisplayName,
  Message

Zu prüfen sind:

wbadmin start backup startet einen neuen Sicherungsvorgang und ist kein rein diagnostischer Befehl.

7.15.17 VSS systematisch prüfen

VSS-Writer unmittelbar nach dem Fehler prüfen:

LESEND

vssadmin list writers

VSS-Provider:

vssadmin list providers

Shadow-Copy-Speicher:

vssadmin list shadowstorage

Vorhandene Shadow Copies:

vssadmin list shadows

Ein gesunder Writer zeigt gewöhnlich:

State: Stable
Last error: No error

Zu prüfen sind:

Ein einzelner fehlerhafter Writer kann den gesamten anwendungskonsistenten Backupjob stoppen.

Der pauschale Neustart aller VSS-Dienste ist keine erste Diagnosemaßnahme. Zuerst muss der betroffene Writer dokumentiert und dem zugehörigen Dienst oder Produkt zugeordnet werden.

7.15.18 Snapshot und Anwendungskonsistenz unterscheiden

Mögliche Sicherungsarten:

Sicherungsart Eigenschaften
Dateikopie im laufenden Betrieb kann bei aktiven Datenbanken inkonsistent sein
crash-konsistenter Snapshot entspricht ungefähr einem ungeplanten Ausfall
anwendungskonsistenter Snapshot Anwendung bestätigt konsistenten Zustand
logisches Datenbankbackup exportiert Daten über Datenbankwerkzeuge
physisches Datenbankbackup sichert Datenbankdateien mit vorgesehenem Verfahren
Hypervisor-Snapshot sichert VM-Zustand, ersetzt aber nicht automatisch ein Backup
Storage-Snapshot liegt häufig auf demselben Storage und benötigt zusätzliche Kopie

Zu prüfen sind:

7.15.19 Netzwerkpfad zum Repository prüfen

Zu bestimmen sind:

Windows

Resolve-DnsName `
  -Name "<Repository-FQDN>"

Test-NetConnection `
  -ComputerName "<Repository-FQDN>" `
  -Port <Port>

SMB-Verbindungen:

Get-SmbConnection

Linux und macOS

getent hosts <Repository-FQDN>

findmnt

HTTPS-Endpunkt:

curl \
  -v \
  https://<Repository-FQDN>/

TLS-Test:

openssl s_client \
  -connect <Repository-FQDN>:<Port> \
  -servername <Repository-FQDN> \
  </dev/null

Zu prüfen sind:

7.15.20 Dienstkonto, Zugangsdaten und Secrets prüfen

Zu erfassen sind:

Typische Fehler:

Zugangsdaten dürfen nicht zur Diagnose in Befehlszeilen, Protokolle oder Tickets geschrieben werden.

7.15.21 Repositoryzustand prüfen

Zu prüfen sind:

Ein Repositorylock kann verursacht werden durch:

Ein Lock darf erst entfernt werden, wenn zweifelsfrei feststeht, dass kein zugehöriger Prozess mehr arbeitet.

7.15.22 Sicherungskette prüfen

Beispiel einer inkrementellen Kette:

Vollbackup
→ Inkrement 1
→ Inkrement 2
→ Inkrement 3

Für die Wiederherstellung können alle benötigten Kettenglieder erforderlich sein.

Beispiel einer differenziellen Sicherung:

Vollbackup
→ aktuelles Differenzialbackup

Zu prüfen sind:

Eine vorhandene letzte Inkrementdatei ist ohne die erforderliche Kette möglicherweise nicht wiederherstellbar.

7.15.23 Retention, Pruning und Immutability prüfen

Retention kann unter anderem festlegen:

Zu prüfen sind:

Immutability kann erklären, warum Speicher nicht freigegeben werden kann. Sie darf nicht deaktiviert werden, um einen Kapazitätsfehler kurzfristig zu umgehen.

7.15.24 Integrität und Prüfsummen unterscheiden

Eine Integritätsprüfung kann bestätigen:

Sie bestätigt nicht automatisch:

Deshalb sind sowohl technische Integritätsprüfungen als auch reale Restore-Tests erforderlich.

7.15.25 Restic-Repository prüfen

Die folgenden Befehle verwenden die bereits sicher konfigurierte Repository- und Kennwortbereitstellung. Kennwörter dürfen nicht direkt in den Befehl geschrieben werden.

Snapshots anzeigen:

LESEND

restic snapshots

Repositorystatistik:

restic stats

Locks anzeigen:

restic list locks

Repositorystruktur prüfen:

LESEND, LASTERZEUGEND

restic check

Repositorydaten vollständig lesen:

LESEND, SEHR LASTERZEUGEND

restic check --read-data

Ein --read-data-Lauf kann das gesamte Repository lesen und muss in das Betriebs- und Backupfenster passen.

Retention vorab simulieren:

LESEND

restic forget \
  --dry-run \
  <vorgesehene-Retention-Optionen>

Wichtige Regeln:

7.15.26 Rsync-Job prüfen

Version:

rsync --version

Trockenlauf:

LESEND, NETZAKTIV, möglicherweise LASTERZEUGEND

rsync \
  --dry-run \
  --itemize-changes \
  <Quelle> \
  <Ziel>

Unmittelbar nach dem Job den Exit-Code ausgeben:

printf '%s\n' "$?"

Wichtige Rsync-Exit-Codes:

Exit-Code Bedeutung
0 erfolgreich
1 Syntax- oder Verwendungsfehler
2 Protokollinkompatibilität
3 Fehler bei Auswahl von Ein- oder Ausgabedateien
5 Client-Server-Protokoll konnte nicht gestartet werden
10 Socket-I/O-Fehler
11 Datei-I/O-Fehler
12 Fehler im Rsync-Protokolldatenstrom
23 teilweise Übertragung wegen Fehler
24 teilweise Übertragung, weil Quelldateien verschwanden
30 Timeout bei Datenübertragung
35 Timeout beim Warten auf Daemonverbindung

Zu prüfen sind:

rsync --delete kann Daten am Ziel löschen. Eine Synchronisation mit --delete ist allein kein versioniertes Backup.

7.15.27 macOS und Time Machine prüfen

Time-Machine-Status:

LESEND

tmutil status

Konfigurierte Ziele:

tmutil destinationinfo

Letztes Backup:

tmutil latestbackup

Vorhandene Backups:

tmutil listbackups

Aktuelle Time-Machine-Protokolle:

log show \
  --predicate 'process == "backupd"' \
  --last 6h \
  --style compact

Speicherzustand:

df -h

Backupvolume:

diskutil info "<Backupvolume>"

Zu prüfen sind:

Netzwerkbasierte Time-Machine-Backups können über das Time-Machine-Menü mit gedrückter Wahltaste und „Backups überprüfen“ verifiziert werden.

Das Löschen oder Neuformatieren des Backupziels ist keine erste Diagnosemaßnahme.

7.15.28 Docker-Backups prüfen

Containerübersicht:

docker ps -a

Volumes:

docker volume ls

Bestimmtes Volume:

docker volume inspect \
  <Volumename>

Containermounts:

docker inspect \
  --format '{{json .Mounts}}' \
  <Containername>

Zu unterscheiden sind:

Wichtige Regeln:

Ein erfolgreicher Export des Containers beweist nicht, dass die persistenten Anwendungsdaten enthalten sind.

7.15.29 Kubernetes-Backupjobs prüfen

CronJobs:

kubectl get cronjobs \
  --all-namespaces

Jobs:

kubectl get jobs \
  --all-namespaces

Bestimmten Job untersuchen:

kubectl describe job \
  <Job> \
  -n <Namespace>

Podlogs:

kubectl logs \
  job/<Job> \
  -n <Namespace>

Ereignisse:

kubectl get events \
  --all-namespaces \
  --sort-by=.metadata.creationTimestamp

PVCs:

kubectl get pvc \
  --all-namespaces

VolumeSnapshots:

kubectl get volumesnapshot \
  --all-namespaces

VolumeSnapshotContents:

kubectl get volumesnapshotcontent

Zu prüfen sind:

Ein Kubernetes-Backup muss je nach Wiederherstellungsziel berücksichtigen:

Ein CSI-VolumeSnapshot ist nicht automatisch anwendungskonsistent und nicht automatisch außerhalb des ursprünglichen Storagebackends geschützt.

7.15.30 Datenbanken korrekt sichern

Aktive Datenbanken dürfen nicht wie gewöhnliche statische Dateien behandelt werden.

Zu unterscheiden sind:

Zu prüfen sind:

7.15.31 PostgreSQL-Backups prüfen

PostgreSQL unterstützt unterschiedliche Verfahren:

Basissicherung prüfen:

LESEND, LASTERZEUGEND

pg_verifybackup \
  <Backupverzeichnis>

Zu prüfen sind:

pg_verifybackup prüft die Struktur und Integrität einer geeigneten Basissicherung, ersetzt aber keinen vollständigen Wiederherstellungstest.

7.15.32 NAS-, SAN- und Storage-Snapshots prüfen

Zu erfassen sind:

Mögliche Fehler:

Ein Snapshot auf demselben NAS oder SAN schützt nicht vor dem vollständigen Ausfall oder der Kompromittierung dieses Systems.

7.15.33 Cloud- und Object-Storage-Ziele prüfen

Zu prüfen sind:

Ein Konto kann Schreibrechte besitzen, aber wegen fehlender List-, Read- oder Delete-Rechte bei Verifikation oder Retention scheitern.

7.15.34 Leistung, Backupfenster und Timeouts prüfen

Zu messen sind:

Mögliche Ursachen:

Ein Job, der das Backupfenster überschreitet, kann vom Scheduler oder Produkt beendet werden, obwohl Quelle und Ziel grundsätzlich funktionieren.

7.15.35 Ransomware- und Manipulationsverdacht

Warnsignale:

Bei begründetem Verdacht:

  1. Incident-Response-Prozess aktivieren.
  2. Beweise sichern.
  3. Repository vor weiteren Veränderungen schützen.
  4. Immutability und Offlinekopien prüfen.
  5. Backupzugangsdaten als möglicherweise kompromittiert behandeln.
  6. Keine normalen Retention- oder Pruningvorgänge starten.
  7. Wiederherstellungspunkt vor dem vermuteten Vorfall bestimmen.
  8. Restore ausschließlich in isolierter Umgebung testen.
  9. Produktivwiederherstellung erst nach Freigabe durchführen.

7.15.36 Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Der geplante Backupjob verwendet ein Dienstkonto,
dessen Kennwort geändert wurde. Deshalb kann der Task
nicht im unbeaufsichtigten Kontext starten.

Erwarteter Befund:
Der Task Scheduler zeigt einen Anmelde- oder
Authentifizierungsfehler.
Der manuelle Start unter einem anderen Konto funktioniert.
Es existiert kein neues Backuplog des eigentlichen Jobs.

Gegenbeweis:
Der Task startet nachweislich unter dem vorgesehenen Konto
und erreicht die erste Phase des Backupjobs.

Testmethode:
Taskstatus, Task-Scheduler-Ereignisse, ausführendes Konto
und Zeitpunkt des letzten Kennwortwechsels vergleichen.

Erfolgskriterium:
Schedulerfehler und Dienstkontoänderung sind zeitlich
und technisch eindeutig zugeordnet.

Eine belastbare Hypothese enthält:

7.15.37 Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko
Zeitplan korrigieren falscher oder deaktivierter Trigger bestätigt doppelter oder unerwarteter Lauf
Dienstkonto korrigieren Konto- oder Anmeldefehler bestätigt Zugriff auf Quelle und Ziel verändert sich
Zugangsdaten erneuern abgelaufenes Secret bestätigt falsches Secret unterbricht weitere Jobs
Quellpfad korrigieren falscher Pfad bestätigt falsche Daten könnten gesichert werden
Ausschlussregel korrigieren fehlende Daten nachgewiesen Backupmenge steigt
VSS-Writer-Ursache beheben fehlerhafter Writer dokumentiert Anwendungsdienst kann unterbrochen werden
Snapshotbereich erweitern Kapazitätsfehler bestätigt Storagebelegung steigt
Repositorykapazität erweitern Repository voll bestätigt falsche Ebene bleibt wirkungslos
Netzwerkregel korrigieren blockierter Pfad bestätigt Sicherheitsgrenze verändert sich
TLS-Zertifikat erneuern Zertifikatsfehler bestätigt falsche Kette oder Bindung
verwaisten Lock entfernen kein aktiver Prozess zweifelsfrei bestätigt Repositorybeschädigung bei Fehlentscheidung
Retention korrigieren fehlerhafte Richtlinie bestätigt Recovery Points können verloren gehen
Pruning ausführen Retention geprüft und Wartungsfenster vorhanden hohe Last und Repositorylock
beschädigte Kette neu aufbauen Kettenschaden bestätigt zusätzlicher Speicher und längeres Fenster
Vollbackup starten inkrementelle Basis unbrauchbar hohe Last und lange Laufzeit
Agent aktualisieren Kompatibilitätsfehler bestätigt Neustart oder Versionskonflikt
Anwendungshook korrigieren Konsistenzfehler bestätigt Anwendung kann beeinflusst werden
Backup erneut starten Ursache behoben und Kapazität vorhanden erneute Last und Snapshotbildung

Vor jeder Maßnahme sind zu dokumentieren:

7.15.38 Maßnahmen, die nicht spontan ausgeführt werden dürfen

Recovery Points manuell aus dem Repository löschen
Repositoryverzeichnisse umbenennen
Repositorylock ungeprüft entfernen
Retention pauschal verkürzen
Immutability deaktivieren
Object Lock umgehen
Pruning während eines aktiven Backups starten
alle Snapshots löschen
VSS-Dienste vor der Beweissicherung neu starten
Datenbankdateien im laufenden Betrieb kopieren
inkrementelle Kettenglieder einzeln löschen
Backupkatalog ohne Herstellervorgabe neu erstellen
Repositorydaten manuell verändern
Verschlüsselungsschlüssel ersetzen
verlorenes Repositorykennwort „zurücksetzen“
Backupziel neu formatieren
Docker-Volume ungeprüft als einfache Dateikopie sichern
Kubernetes-PVC löschen und neu erstellen
Restore direkt über Produktivdaten ausführen
beschädigtes Backup als einzigen Recovery Point behalten

7.15.39 Vollständiger Diagnoseablauf

  1. Fehlermeldung vollständig aufnehmen
    Wortlaut, Fehlercode, Job-ID und Zeitpunkt dokumentieren.

  2. Job und Sicherungsprodukt bestimmen
    Plan, Richtlinie, Agent und Server erfassen.

  3. Auswirkung bestimmen
    Einzelne Quelle, Jobgruppe, Repository oder gesamte Umgebung unterscheiden.

  4. Letzten erfolgreichen Recovery Point bestimmen
    Nicht nur letzten erfolgreichen Prozesslauf prüfen.

  5. RPO-Verletzung berechnen
    Aktuelle Schutzlücke mit Sollwert vergleichen.

  6. Jobphase bestimmen
    Planung, Snapshot, Lesen, Transport, Schreiben oder Abschluss unterscheiden.

  7. Scheduler prüfen
    Trigger, Konto, letzte Ausführung und Exit-Code erfassen.

  8. Backupdienste und Agenten prüfen
    Status und Version dokumentieren.

  9. Logs sichern
    Job-, Betriebssystem-, Anwendungs- und Repositorylogs korrelieren.

  10. Quelle vollständig bestimmen
    Pfade, Volumes, VMs, Container und Datenbanken erfassen.

  11. Ausschlüsse prüfen
    Neue oder versehentlich ausgeschlossene Daten erkennen.

  12. Quellberechtigungen prüfen
    Tatsächlichen Dienstkontext verwenden.

  13. Quellkapazität prüfen
    Freien Speicher, Inodes und Temp-Bereich untersuchen.

  14. Snapshotzustand prüfen
    VSS, Hypervisor, CSI oder Storage-Snapshot unterscheiden.

  15. Anwendungskonsistenz prüfen
    Writer, Hook oder Datenbankverfahren auswerten.

  16. Ziel und Repository bestimmen
    Host, Pfad, Port, Protokoll und Backend erfassen.

  17. Netzwerkpfad prüfen
    DNS, Routing, Firewall, VPN, Proxy und TLS untersuchen.

  18. Zielberechtigungen prüfen
    Schreiben, Lesen, Listen und gegebenenfalls Löschen unterscheiden.

  19. Repositorykapazität prüfen
    Speicher, Quota, Thin Pool, Katalog und Cache berücksichtigen.

  20. Repositorylock prüfen
    Aktive und verwaiste Locks unterscheiden.

  21. Parallele Jobs prüfen
    Backup, Restore, Replication, Retention und Pruning erfassen.

  22. Sicherungskette prüfen
    Vollbackup und erforderliche Folgebackups zuordnen.

  23. Retention und Immutability prüfen
    Aufbewahrung, Object Lock und Legal Hold berücksichtigen.

  24. Verschlüsselung prüfen
    Schlüssel, Kennwort, KMS und Zertifikate erfassen.

  25. Integrität prüfen
    Herstellervorgesehene Repositoryprüfung verwenden.

  26. Performance prüfen
    Dauer, Durchsatz, Latenz, Last und Backupfenster vergleichen.

  27. Sicherheitsverdacht bewerten
    Manipulation, ungewöhnliche Änderungen und fehlende Recovery Points prüfen.

  28. Hypothese und Gegenbeweis formulieren
    Ursache vor der Änderung messbar festlegen.

  29. Eine kontrollierte Maßnahme durchführen
    Risiko, Rückweg und Freigabe beachten.

  30. Job kontrolliert neu starten
    Doppelstarts und parallele Wartung ausschließen.

  31. Jobphasen überwachen
    Snapshot, Übertragung und Abschluss beobachten.

  32. Exit-Code und Warnungen auswerten
    Teilerfolg nicht als Vollerfolg behandeln.

  33. Neuen Recovery Point bestätigen
    Zeit, Umfang und Repository registrieren.

  34. Integritätsprüfung durchführen
    Katalog und Datenblöcke prüfen.

  35. Isolierten Restore-Test durchführen
    Repräsentative Daten oder Anwendung wiederherstellen.

  36. Wiederhergestellte Daten validieren
    Inhalt, Metadaten, Rechte und Anwendung prüfen.

  37. RPO und RTO bewerten
    Tatsächliche Werte dokumentieren.

  38. Sekundärkopie prüfen
    Offsite-, Offline- oder immutable Kopie bestätigen.

  39. Temporäre Änderungen zurücknehmen
    Debuglogging, Testfreigaben und Ausnahmen entfernen.

  40. Ursache dokumentieren
    Technischen Nachweis festhalten.

  41. Prävention festlegen
    Monitoring, Kapazität, Retention oder Jobdesign verbessern.

7.15.40 Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
kein Joblog vorhanden Scheduler oder Prozessstart fehlerhaft Scheduler-Ereignisse
Job startet manuell, geplant aber nicht Dienstkonto, Umgebung oder Rechte Ausführungskontext vergleichen
Task meldet Erfolg, kein Recovery Point Skript wertet Exit-Code falsch aus Unterprozess und Repository prüfen
Quelle fehlt Mount, Volume oder Pfad nicht verfügbar Mount- und Volumezustand
nur neue Verzeichnisse fehlen Ausschluss oder Berechtigung Jobumfang und ACLs
VSS-Writer fehlgeschlagen Anwendungskonsistenz fehlerhaft vssadmin list writers
Snapshot erstellt, Job scheitert später Transport, Repository oder Katalog nächste Jobphase
Repository voll Kapazität, Quota oder Retention Belegung aller Repositoryebenen
Repository hat Platz, Cache ist voll lokaler Stagingbereich erschöpft Quellhost und Proxy prüfen
nur geplanter Netzwerkjob scheitert gemapptes Laufwerk fehlt UNC-Pfad und Dienstkonto
Zugriff verweigert Berechtigung oder geändertes Konto Quell- und Zielrechte
Authentifizierung fehlgeschlagen Kennwort, Token oder Zertifikat Ablauf und Dienstkontext
Repository locked aktiver oder verwaister Prozess Prozesse und Jobhistorie
Inkrementbackup fehlt Kette unterbrochen Vollbackup und Folgepunkte
Retention schlägt fehl Immutability oder fehlendes Löschrecht Richtlinie und Object Lock
Pruning läuft sehr lange Repositorygröße oder Wartungsüberschneidung Prozess und I/O-Last
Rsync Exit-Code 23 teilweise Übertragung vollständige Fehlerausgabe
Rsync Exit-Code 24 Quelldateien verschwanden aktive Anwendung und Dateityp
Dockerexport erfolgreich, Daten fehlen Volume nicht enthalten Mounts und Volumes
Kubernetes-Snapshot nicht readyToUse CSI- oder Storagefehler Snapshotereignisse
Datenbankbackup vorhanden, Restore scheitert Inkonsistenz oder fehlende Logs Datenbankverifikation
Backup erfolgreich, Replikation fehlgeschlagen Zweitkopie fehlt Replikationsjob und Ziel
Backupdauer plötzlich erhöht Datenwachstum, Last oder Netzwerk Baselinevergleich
viele Dateien wurden neu gesichert Verschlüsselung, Zeitstempel oder Anwendung Änderungsursache
Prüfsummenfehler Repository- oder Storagebeschädigung Integritätsprüfung und Hardware
ältere Recovery Points fehlen unerwartet Retentionfehler oder Manipulation Audit- und Repositorylogs
Restore funktioniert, Anwendung nicht Abhängigkeiten oder Konsistenz fehlen vollständiger Anwendungstest

7.15.41 Typische Diagnosefehler

7.15.42 Verifikation und Restore-Test

Nach der Maßnahme müssen mindestens folgende Punkte geprüft werden:

Ein Restore-Test sollte nicht die produktiven Originaldaten überschreiben.

7.15.43 Stufen eines Restore-Tests

Stufe Nachweis
Katalogtest Recovery Point wird angezeigt
Lesetest Sicherungsdaten können gelesen werden
Integritätstest Prüfsummen und Repositorystruktur stimmen
Datei-Restore ausgewählte Dateien werden isoliert wiederhergestellt
Metadatenprüfung Rechte, Eigentümer und Zeitstempel stimmen
Datenbank-Restore Datenbank wird konsistent wiederhergestellt
Anwendungs-Restore Anwendung startet und arbeitet
System-Restore VM, Host oder Dienst wird vollständig wiederhergestellt
DR-Test definierte Notfallumgebung wird innerhalb des RTO aufgebaut

Je kritischer das System ist, desto höher muss die regelmäßig getestete Restore-Stufe sein.

7.15.44 Prävention und Monitoring

Zu überwachen sind:

Ein geeignetes Monitoring alarmiert nicht nur bei Failed, sondern auch bei:

7.15.45 Empfohlene Schutzstruktur

Eine robuste Sicherungsstrategie berücksichtigt mehrere Fehlerdomänen:

Produktivdaten
→ primäres Backuprepository
→ getrennte Zweitkopie
→ unveränderbare oder offline Kopie
→ regelmäßig getestete Wiederherstellung

Zu vermeiden ist:

Produktivdaten
und
einzige Sicherung
auf demselben Host,
demselben Storage Pool
oder mit denselben kompromittierbaren Zugangsdaten

Backups sollten entsprechend Schutzbedarf:

7.15.46 Dokumentationsvorlage

Störung:
<exakte Fehlermeldung>

Zeitpunkt:
<Datum und Uhrzeit>

Sicherungsprodukt:
<Produkt und Version>

Jobname:
<Name>

Job-ID:
<ID>

Betroffene Quelle:
<System, Volume, Pfad, VM, Container oder Datenbank>

Sicherungsziel:
<Repository, Freigabe, Bucket oder Storage>

Geplanter Start:
<Zeitpunkt>

Tatsächlicher Start:
<Zeitpunkt oder nicht gestartet>

Endzeit:
<Zeitpunkt>

Jobphase:
<Planung, Snapshot, Lesen, Transport, Schreiben,
Katalog, Retention oder Replikation>

Exit-Code:
<Wert>

Letzter erfolgreicher Recovery Point:
<Datum und Uhrzeit>

Letzter verifizierter Recovery Point:
<Datum und Uhrzeit>

Aktuelle Schutzlücke:
<Zeit>

Vorgesehenes RPO:
<Zeit>

Vorgesehenes RTO:
<Zeit>

Schedulerzustand:
<Befund>

Dienstkonto:
<Konto ohne Kennwort>

Quellzustand:
<Pfad, Volume, Mount und Berechtigungen>

Snapshotzustand:
<VSS, Hypervisor, CSI oder Storage>

Anwendungskonsistenz:
<Befund>

Netzwerkpfad:
<DNS, Ziel-IP, Port und Protokoll>

Repositoryzustand:
<Kapazität, Quota, Lock und Integrität>

Sicherungskette:
<Vollbackup und Abhängigkeiten>

Retention und Immutability:
<Befund>

Verschlüsselung:
<Verfahren und Schlüsselverfügbarkeit>

Nachgewiesene Ursache:
<technischer Befund>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

Durchgeführte Maßnahme:
<genaue Änderung>

Risiko und Rückweg:
<Beschreibung>

Neuer Recovery Point:
<Datum, Uhrzeit und ID>

Integritätsprüfung:
<Ergebnis>

Restore-Test:
<Ziel, Umfang und Ergebnis>

Tatsächliches RPO:
<Wert>

Tatsächliches RTO:
<Wert>

Prävention:
<Monitoring, Kapazität, Retention oder Prozessänderung>

7.15.47 Checkliste

7.15.48 Schnellreferenz

Aufgabe Befehl
Windows-Task Get-ScheduledTask -TaskName "<Taskname>"
Windows-Task-Laufzeit Get-ScheduledTask -TaskName "<Taskname>" | Get-ScheduledTaskInfo
detaillierte Taskabfrage schtasks /query /tn "<Task>" /v /fo LIST /hresult
Windows-Backupstatus wbadmin get status
Windows-Backupversionen wbadmin get versions
Windows-Backupdatenträger wbadmin get disks
VSS-Writer vssadmin list writers
VSS-Provider vssadmin list providers
VSS-Speicher vssadmin list shadowstorage
Windows-Volumes Get-Volume
Systemd-Timer systemctl list-timers --all
Backup-Service systemctl status backup.service
Backup-Service-Logs journalctl -u backup.service --since "-24 hours"
Benutzer-Cronjobs crontab -l
Root-Cronjobs sudo crontab -l
Linux-Speicher df -hT
Linux-Inodes df -i
Linux-Mounts findmnt
Rsync-Trockenlauf rsync --dry-run --itemize-changes <Quelle> <Ziel>
Restic-Snapshots restic snapshots
Restic-Statistik restic stats
Restic-Locks restic list locks
Restic-Prüfung restic check
Time-Machine-Status tmutil status
Time-Machine-Ziel tmutil destinationinfo
letztes Time-Machine-Backup tmutil latestbackup
Docker-Volumes docker volume ls
Docker-Volume untersuchen docker volume inspect <Volume>
Kubernetes-CronJobs kubectl get cronjobs --all-namespaces
Kubernetes-Jobs kubectl get jobs --all-namespaces
Kubernetes-PVCs kubectl get pvc --all-namespaces
Kubernetes-Snapshots kubectl get volumesnapshot --all-namespaces
PostgreSQL-Basissicherung prüfen pg_verifybackup <Backupverzeichnis>

7.15.49 Quellen

Offizielle Microsoft-Dokumentation

Offizielle Linux- und Projektdokumentation

Offizielle Docker-Dokumentation

Offizielle Kubernetes-Dokumentation

Offizielle PostgreSQL-Dokumentation

Offizielle Apple-Dokumentation

Offizielle Sicherheitsempfehlungen

Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.