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: Netzwerkadapter, physische oder drahtlose Verbindung, IP-Konfiguration, lokales Netzwerk, Routing, DNS, 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: ist wirklich nur ein Client betroffen, funktionieren andere Clients am selben Switch oder Access Point, betrifft der Fehler Ethernet, WLAN oder beide Verbindungsarten, sind interne Ziele, das Internet oder nur einzelne Dienste nicht erreichbar, begann die Störung nach einer Änderung, funktioniert der Client an einem anderen Anschluss oder in einem anderen WLAN? 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: ist das Netzwerkkabel vollständig eingesteckt, leuchten oder blinken die Link-LEDs, ist der Adapter aktiviert, erkennt Windows eine Verbindung, funktioniert ein geprüftes Ersatzkabel, funktioniert derselbe Anschluss mit einem Vergleichsgerät, funktioniert der Client an einem anderen freigegebenen Switchport? Adapterstatus anzeigen: Get-NetAdapter Nur physische Adapter anzeigen: Get-NetAdapter -Physical Ausführliche Adapterinformationen: Get-NetAdapter | Format-List Name, InterfaceDescription, Status, LinkSpeed, MacAddress Entscheidung Status Up → mit der IP-Konfiguration fortfahren. Status Disconnected → Kabel, Dose, Patchfeld, Switchport und Adapter prüfen. Status Disabled → klären, warum der Adapter deaktiviert ist. Adapter fehlt vollständig → Geräteerkennung, Treiber, Hardware oder BIOS/UEFI prüfen. Link besteht nur mit einem anderen Kabel → ursprüngliches Kabel austauschen. Link besteht nur an einem anderen Port → ursprünglichen Anschluss und dessen Konfiguration untersuchen. Ein leuchtendes Link-Signal bestätigt nur die physische Verbindung. Es beweist nicht, dass VLAN, DHCP, Routing, DNS oder Anwendungen funktionieren. 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: ist WLAN eingeschaltet, ist der Flugmodus ausgeschaltet, wird die vorgesehene SSID angezeigt, ist der Client tatsächlich mit dieser SSID verbunden, stimmt die BSSID beziehungsweise der verbundene Access Point, ist die Signalqualität ausreichend, wurde die WLAN-Authentifizierung erfolgreich abgeschlossen, verwendet der Client das vorgesehene Benutzer- oder Computerzertifikat, greift eine zentrale WLAN-Richtlinie, wurde der Client in das richtige VLAN eingeordnet? Entscheidung SSID nicht sichtbar → Reichweite, Access Point, Funkband, Kanal, Treiber oder Richtlinie prüfen. SSID sichtbar, Verbindung scheitert → Profil, Schlüssel, 802.1X, Zertifikat oder RADIUS untersuchen. WLAN verbunden, aber keine gültige IP-Konfiguration → DHCP oder VLAN prüfen. Verbindung besteht mit falscher SSID → mit dem vorgesehenen Netz verbinden. sehr schwaches oder stark schwankendes Signal → Abstand, Störungen, Funkabdeckung und Roaming prüfen. 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: verwendeter Netzwerkadapter, IPv4- und gegebenenfalls IPv6-Adresse, Subnetzmaske beziehungsweise Präfixlänge, Standardgateway, DHCP aktiviert oder deaktiviert, DHCP-Server, Lease-Zeiten, DNS-Server, DNS-Suffix, Medienstatus, eventuell vorhandene virtuelle Adapter. 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: keine physische Verbindung, falsches VLAN, Switchport falsch konfiguriert, WLAN-Authentifizierung nicht vollständig, DHCP-Server nicht erreichbar, DHCP-Relay fehlt oder ist falsch konfiguriert, DHCP-Bereich ausgeschöpft, DHCP-Richtlinie oder Filter lehnt den Client ab, UDP 67 oder 68 wird blockiert, DHCP-Clientdienst funktioniert nicht, fremder DHCP-Server liefert eine falsche Konfiguration, Network Access Control weist ein Quarantäne-VLAN zu. 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 gültige Adresse wird vergeben → Lease-Daten und Erreichbarkeit weiterprüfen. Zeitüberschreitung → DHCP-Anfrage oder Antwort erreicht ihr Ziel möglicherweise nicht. falsches Subnetz wird vergeben → DHCP-Bereich, Relay, VLAN oder fremden DHCP-Server prüfen. Adresse wird vergeben, Gateway fehlt → DHCP-Optionen oder Richtlinie prüfen. Adresse wird vergeben, DNS-Server fehlen oder sind falsch → DHCP-DNS-Optionen prüfen. Bei weiterhin unklaren DHCP-Problemen kann ein autorisierter Paketmitschnitt zeigen, ob der DORA-Ablauf vollständig ist: DHCP Discover, DHCP Offer, DHCP Request, DHCP Acknowledge. 5. Lokalen TCP/IP-Stack prüfen Loopback-Adresse testen: ping 127.0.0.1 Eigene IPv4-Adresse testen: ping Entscheidung Loopback-Test schlägt fehl → lokalen TCP/IP-Stack oder Sicherheitssoftware untersuchen. Loopback funktioniert, eigene Adresse nicht → Adapterbindung, IP-Konfiguration oder lokale Filter prüfen. beide Tests funktionieren → Verbindung zum lokalen Netz untersuchen. 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 Zusätzliche Verbindungsinformationen: Test-NetConnection -ComputerName -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: erscheint das Gateway in der ARP- beziehungsweise Nachbartabelle, erreichen Vergleichsclients das Gateway, funktioniert der Zugriff auf ein anderes System im selben Subnetz, zeigen Switch und Access Point den Client im erwarteten VLAN, bestehen Port-Security-, NAC- oder MAC-Filterregeln? 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 Gezielten Dienst prüfen: Test-NetConnection -ComputerName -Port Entscheidung lokales Ziel erreichbar, Gateway nicht → Gateway, ICMP-Filterung oder Gateway-Adresse prüfen. weder lokales Ziel noch Gateway erreichbar → Layer 2, VLAN, Subnetzmaske, ARP, Port-Security oder Clientadapter prüfen. lokale Ziele funktionieren → Verbindung über das Gateway untersuchen. nur ein bestimmtes lokales Ziel scheitert → Zielsystem, Dienst, Firewall oder Berechtigung prüfen. 8. Funktioniert die Verbindung zu einer externen IP-Adresse? Ein freigegebenes bekanntes IP-Ziel verwenden: ping Pfad untersuchen: tracert PowerShell-Diagnose: Test-NetConnection -ComputerName -InformationLevel Detailed Entscheidung Gateway erreichbar, externe IP nicht → Routing, Firewall, NAT, VPN oder Internetübergang prüfen. externe IP erreichbar → grundlegendes IP-Routing funktioniert; DNS prüfen. tracert endet am ersten Hop → Gateway oder nachgelagertes Routing untersuchen. tracert zeigt einzelne Zeitüberschreitungen → nicht automatisch Paketverlust annehmen; Router können ICMP-Antworten begrenzen. Vergleichsclient erreicht dasselbe Ziel → clientspezifische Route, Firewall, VPN- oder Proxykonfiguration untersuchen. 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 Mit PowerShell: Resolve-DnsName Erreichbarkeit eines DNS-Servers prüfen: Test-NetConnection -ComputerName -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 -Port Beispiele: Test-NetConnection -ComputerName -Port 443 Test-NetConnection -ComputerName -Port 445 Test-NetConnection -ComputerName -Port 3389 Zusätzlich prüfen: läuft der Dienst auf dem Zielsystem, lauscht er auf dem erwarteten Port, blockiert eine lokale oder zentrale Firewall, ist ein Proxy erforderlich, verwendet die Anwendung einen falschen Proxy, beeinflusst ein VPN den Datenverkehr, ist das Zertifikat gültig, stimmen Systemzeit und Zertifikatszeitraum, ist nur ein Benutzerkonto betroffen, benötigt die Anwendung zusätzliche Ports oder Dienste, funktioniert der Zugriff im Vergleichsclient? 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: aktiver VPN-Tunnel, nicht vollständig beendete VPN-Verbindung, falsche Standardroute, Split-Tunneling-Konfiguration, falsche Routenmetrik, DNS-Server des VPN, virtuelle Hyper-V-, Docker-, WSL- oder Virtualisierungsadapter, Security- oder Filtertreiber, mehrere gleichzeitig aktive Netzwerkadapter, veraltete statische Routen. Vergleichstest Wenn betrieblich zulässig, den Zustand dokumentieren und anschließend prüfen, ob das Problem nur mit aktivem VPN auftritt. funktioniert die Verbindung ohne VPN → VPN-Routen, DNS, Filter oder Richtlinien untersuchen. funktioniert sie ausschließlich mit VPN → lokales Routing, lokales DNS oder Zugriffsvorgaben prüfen. betrifft der Fehler nur interne Ziele → interne Routen und interne DNS-Auflösung prüfen. betrifft der Fehler nach Trennung weiterhin alle Ziele → verbliebene Routen, Filtertreiber oder Adapterzustände prüfen. 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: aktuelles Netzwerkprofil, ausgehende Blockierregeln, Endpoint-Security- oder EDR-Richtlinien, Webfilter, lokale Paketfilter, kürzlich erfolgte Richtlinienänderungen, Quarantäne- oder Isolationszustand, fehlgeschlagene Gerätekonformität, Network Access Control. 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: Windows meldet einen IP-Adresskonflikt, Verbindung funktioniert wechselnd, ARP-Zuordnung ändert sich, ein anderes Gerät antwortet auf die Adresse, eine statisch konfigurierte Adresse liegt im DHCP-Bereich, nach einem Gerätewechsel tritt der Fehler auf. Nachbartabelle prüfen: arp -a Eigene MAC-Adresse erfassen: Get-NetAdapter | Format-Table Name, MacAddress, Status Prüfen: gehört die zur eigenen IP sichtbare MAC-Adresse tatsächlich zum Client, ist die Adresse doppelt vergeben, liegt eine statische Adresse im dynamischen DHCP-Bereich, existiert eine falsche DHCP-Reservierung, wurde ein Gerät geklont, verwendet eine virtuelle Maschine dieselbe Adresse? 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: Beginn der Störung, Linkverlust, DHCP-Fehler, Adresskonflikte, DNS-Fehler, WLAN-Trennung, Treiberneustart, VPN-Verbindung, Richtlinienänderung, Energiesparereignis, Systemstart oder Ruhezustand. 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: der Adapter nicht erkannt wird, der Link ständig auf- und abgebaut wird, Ereignisse einen Treiberfehler melden, der Fehler nach einem Treiber- oder Betriebssystemupdate begann, der Adapter auch in einem anderen Netz nicht funktioniert, ein USB-Netzwerkadapter ständig getrennt wird, andere Geräte am selben Anschluss funktionieren, ein geprüfter Ersatzadapter funktioniert. Vor Änderungen dokumentieren: Adaptermodell, Treiberversion, Treiberdatum, Hardware-ID, Ereignisse, vorhandene IP-Konfiguration, Zeitpunkt der letzten Änderung. 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: ARP-Anfragen und Antworten, DHCP Discover, Offer, Request und Acknowledge, DNS-Anfragen und Antworten, ICMP-Fehler, TCP-Verbindungsaufbau, Retransmissions, Verbindungszurücksetzungen, angesprochene Gateways und DNS-Server. 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 Netzwerkadapter ist aktiv. Physischer Link besteht. Der Client hat jedoch keine verwendbare DHCP-Konfiguration erhalten. Es liegt noch kein nachgewiesener Internet- oder DNS-Fehler vor. Der DHCP-Pfad muss geprüft werden. Vergleichstest Ein anderes Gerät wird kontrolliert am selben Anschluss geprüft und erhält ebenfalls keine DHCP-Adresse. Nächster Untersuchungsbereich Switchport, VLAN-Zuordnung, Patchung, DHCP-Relay, DHCP-Erreichbarkeit. Festgestellte Ursache Der Switchport wurde versehentlich einem nicht vorgesehenen VLAN zugeordnet. Nachprüfung vorgesehene VLAN-Zuordnung wiederhergestellt, Client erhält gültige Adresse, Subnetzmaske, Gateway und DNS-Server, Gateway erreichbar, interne und externe Ziele erreichbar, DNS-Auflösung funktioniert, benötigte Anwendungen funktionieren, zweiter Client am Anschluss ebenfalls erfolgreich, Ursache und Änderung dokumentiert. 20. Ungeeignete Sofortmaßnahmen Nicht als erste Maßnahme verwenden: Client sofort neu starten, Router oder Switch pauschal neu starten, Netzwerkadapter mehrfach deaktivieren und aktivieren, TCP/IP-Konfiguration ungeprüft zurücksetzen, DNS-Cache vor der Dokumentation löschen, DHCP-Lease vor der Erfassung freigeben, statische IP-Adresse „zum Test“ frei erfinden, öffentliche DNS-Server an einem Unternehmensclient eintragen, Firewall oder Endpoint-Security vollständig deaktivieren, VPN-Software ungeprüft deinstallieren, Netzwerkprofil löschen, WLAN-Profil sofort entfernen, Netzwerktreiber sofort deinstallieren, Switchport ungeprüft in ein anderes VLAN verschieben, mehrere Änderungen gleichzeitig durchführen, einen erfolgreichen Ping mit vollständiger Netzwerkfunktion gleichsetzen. Solche Maßnahmen verändern den Zustand, beseitigen Beweise oder erzeugen zusätzliche Fehler. 21. Vollständige Schnellprüfreihenfolge genaue Fehlermeldung und Uhrzeit erfassen. feststellen, ob nur ein Client betroffen ist. Ethernet, WLAN, VPN und betroffene Ziele unterscheiden. Vergleichsclient prüfen. Adapterstatus erfassen. physischen Link oder WLAN-Verbindung prüfen. ipconfig /all dokumentieren. IP-Adresse und Subnetz prüfen. bei 169.254.x.x den DHCP-Pfad untersuchen. Standardgateway prüfen. Routingtabelle erfassen. eigenes TCP/IP über Loopback testen. lokales Vergleichsziel testen. Gateway testen. externe IP-Verbindung testen. Pfad bei Bedarf mit tracert untersuchen. DNS-Server und Namensauflösung prüfen. benötigten Zielport testen. Proxy, VPN und virtuelle Adapter berücksichtigen. Firewall- und Sicherheitsprotokolle prüfen. Ereignisse mit dem Fehlerzeitpunkt korrelieren. genau eine Hypothese formulieren. genau eine kontrollierte Änderung durchführen. dieselben Tests erneut ausführen. interne und externe Ziele prüfen. Namensauflösung prüfen. benötigte Anwendungen testen. Vergleichsclient oder Vergleichsanschluss erneut testen. temporäre Diagnosekonfiguration entfernen. Ursache, Maßnahme und Nachweis dokumentieren. 22. Checkliste „Ein Client hat kein Netzwerk“ genaue Fehlermeldung wurde dokumentiert. Beginn und Uhrzeit der Störung sind bekannt. es wurde geprüft, ob weitere Clients betroffen sind. Ethernet, WLAN und VPN wurden unterschieden. interne, externe und einzelne Anwendungsziele wurden unterschieden. ein Vergleichsclient wurde geprüft. der aktive Netzwerkadapter ist bekannt. Adapterstatus und Linkgeschwindigkeit wurden dokumentiert. Kabel, Dose oder WLAN-Verbindung wurden geprüft. die vollständige IP-Konfiguration wurde gesichert. IP-Adresse und Subnetzmaske sind plausibel. eine mögliche 169.254.x.x -Adresse wurde erkannt. DHCP- oder statische Konfiguration wurde eindeutig bestimmt. DHCP-Server und Lease-Daten wurden dokumentiert. Standardgateway ist vorhanden und plausibel. DNS-Server sind vorhanden und vorgesehen. DNS-Suffix wurde berücksichtigt. Loopback-Test wurde durchgeführt. lokales Vergleichsziel wurde geprüft. Standardgateway wurde geprüft. externe IP-Verbindung wurde geprüft. Routingtabelle wurde untersucht. ARP- beziehungsweise Nachbartabelle wurde berücksichtigt. Namensauflösung wurde getrennt von IP-Erreichbarkeit geprüft. benötigter Zielport wurde getestet. Proxykonfiguration wurde bei Bedarf geprüft. VPN und virtuelle Adapter wurden berücksichtigt. lokale Firewall und Sicherheitssoftware wurden nicht pauschal deaktiviert. ein IP-Adresskonflikt wurde berücksichtigt. Ereignisprotokolle wurden mit dem Fehlerzeitpunkt korreliert. Treiberänderungen wurden erst nach der Netzwerkanalyse erwogen. vor aktiven Änderungen wurden Diagnoseinformationen gesichert. nur eine kontrollierbare Änderung wurde durchgeführt. die gleichen Tests wurden nach der Änderung wiederholt. interne und externe Ziele funktionieren. DNS-Auflösung funktioniert. benötigte Anwendungen funktionieren. Ursache, Änderung und Nachweis wurden dokumentiert. 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 Microsoft Learn – ipconfig Microsoft Learn – ping Microsoft Learn – tracert Microsoft Learn – pathping Microsoft Learn – arp Microsoft Learn – route Microsoft Learn – nslookup Microsoft Learn – Get-NetAdapter Microsoft Learn – Get-NetIPConfiguration Microsoft Learn – Get-NetRoute Microsoft Learn – Get-NetNeighbor Microsoft Learn – Test-NetConnection Microsoft Learn – Resolve-DnsName Microsoft Learn – Get-DnsClientServerAddress Microsoft Learn – netsh wlan Microsoft Learn – DHCP troubleshooting guidance Microsoft Learn – DHCP overview Microsoft Learn – Get-WinEvent 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: Switch oder Switch-Uplink, Access Point oder WLAN-Controller, VLAN, DHCP, Standardgateway, Routing, DNS, Firewall, Standortverbindung, zentrale Stromversorgung. 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: funktionierender Client am selben Switch, funktionierender Client in einem anderen VLAN, funktionierender Client an einem anderen Access Point, funktionierender Client in einem anderen Stockwerk, funktionierender Client an einem anderen Standort, kabelgebundener Client als Vergleich zu WLAN, WLAN-Client als Vergleich zu Ethernet. Auf jedem Vergleichsclient möglichst dieselben Prüfungen durchführen: ipconfig /all ping ping nslookup Test-NetConnection -ComputerName -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 mehrere Ethernetclients zeigen Disconnected → gemeinsamen Switch, Uplink oder Stromausfall prüfen. mehrere WLAN-Clients sind getrennt → Access Point, Controller, SSID oder Authentifizierung prüfen. Link besteht, aber keine gültige IP-Adresse → DHCP- oder VLAN-Pfad prüfen. Link und IP-Konfiguration bestehen → Gateway und Routing prüfen. nur einzelne Ports sind ohne Link → Portgruppe, Patchfeld oder Modul untersuchen. alle Ports eines Switches sind ohne Link → Switchstatus und Stromversorgung prüfen. Ein vorhandener Link beweist nur die physische Verbindung zwischen Client und nächster Netzwerkkomponente. 5. Switch und Uplink prüfen Bei einem räumlich begrenzten Ausfall prüfen: ist der Switch eingeschaltet, sind ungewöhnlich viele Ports ohne Link, funktioniert die Stromversorgung, meldet die unterbrechungsfreie Stromversorgung einen Fehler, ist der Uplink aktiv, ist ein redundanter Uplink blockiert oder ausgefallen, bestehen ungewöhnlich viele Port-Flaps, wurde ein Port durch eine Schutzfunktion deaktiviert, bestehen Fehler an einem Interface, wurde die VLAN- oder Trunk-Konfiguration geändert, gibt es Hinweise auf eine Netzwerkschleife, läuft Spanning Tree stabil, ist die CPU- oder Speicherauslastung auffällig, ist die MAC-Adresstabelle plausibel? Die genauen Befehle hängen vom Hersteller und Betriebssystem des Switches ab. Typische Informationen sind: Portstatus, Uplinkstatus, Interfacefehler, verworfene Frames, VLAN-Zuordnung, Trunk-VLANs, MAC-Adresstabelle, Spanning-Tree-Zustand, Port-Security- oder Errdisable-Ereignisse, Systemprotokoll, letzte Konfigurationsänderung. 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: alle betroffenen Clients befinden sich im selben IP-Subnetz, andere VLANs am selben Switch funktionieren, Clients erhalten Adressen aus einem falschen Subnetz, Clients erhalten überhaupt keine DHCP-Adresse, das Gateway dieses VLANs ist nicht erreichbar, die Störung begann nach einer Switch- oder Firewalländerung, ein neuer Switch oder Access Point wurde eingebunden, kabelgebundene und drahtlose Clients desselben VLANs sind betroffen. Zu prüfen sind: Access-VLAN der Clientports, VLAN-Zuweisung der SSID, erlaubte VLANs auf Trunks, native beziehungsweise ungetaggte VLAN-Konfiguration, VLAN-Existenz auf beteiligten Switches, Spanning-Tree-Zustand des VLANs, Gateway-Schnittstelle oder SVI, DHCP-Bereich und DHCP-Relay, VLAN-spezifische ACLs oder Firewallregeln, Routing zwischen den VLANs. Entscheidung nur Clients eines Ports im falschen VLAN → Access-Port-Konfiguration prüfen. mehrere Ports eines Switches betroffen → Portprofil oder Switchkonfiguration prüfen. VLAN funktioniert auf einem Switch, auf einem anderen nicht → Trunk und VLAN-Weiterleitung prüfen. VLAN funktioniert nirgends → Gateway, SVI, DHCP und zentrale Konfiguration prüfen. Clients erhalten Adressen eines anderen VLANs → Port-, Trunk-, SSID- oder DHCP-Konfiguration prüfen. 7. DHCP-Störung erkennen Auf mehreren betroffenen Clients prüfen: ipconfig /all Typische Hinweise auf einen gemeinsamen DHCP-Fehler: mehrere Clients besitzen Adressen aus 169.254.0.0/16 , das Standardgateway fehlt, DNS-Server fehlen, Clients erhalten Adressen aus einem falschen Subnetz, bestehende Clients funktionieren noch, neue Clients jedoch nicht, Clients mit gültigem Lease funktionieren bis zur Lease-Erneuerung, nur ein bestimmtes Subnetz erhält keine Adressen. 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: läuft der DHCP-Dienst, ist der DHCP-Server autorisiert, ist der betreffende Bereich aktiv, sind noch freie Adressen vorhanden, stimmen Subnetzmaske, Gateway und DNS-Optionen, funktioniert ein konfiguriertes DHCP-Failover, erreicht die Anfrage den DHCP-Server, antwortet der Server, funktioniert das DHCP-Relay, wird UDP 67 oder 68 blockiert, existiert ein nicht autorisierter DHCP-Server? Ein autorisierter Paketmitschnitt kann zeigen, an welcher Stelle der DORA-Ablauf endet: DHCP Discover, DHCP Offer, DHCP Request, 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 Routingtabelle anzeigen: route print Alternativ: Get-NetRoute Nachbartabelle prüfen: Get-NetNeighbor Entscheidung kein Client erreicht das Gateway → Gateway, VLAN, Switchpfad oder Firewall prüfen. nur ein VLAN erreicht sein Gateway nicht → Gateway-Schnittstelle, SVI oder VLAN-Zuordnung prüfen. Gateway erscheint nicht in der Nachbartabelle → Layer-2-Pfad und ARP untersuchen. Gateway erscheint mit MAC-Adresse, antwortet aber nicht auf Ping → ICMP kann blockiert sein; weitere Dienste testen. ein Vergleichs-VLAN erreicht sein Gateway → globale Gateway-Hardware ist nicht automatisch vollständig bestätigt; VLAN-spezifische Konfiguration prüfen. mehrere Gateways sind gleichzeitig ausgefallen → redundante Gatewaylösung, Core-Switch oder zentrale Firewall prüfen. 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 Pfad anzeigen: tracert PowerShell-Test: Test-NetConnection -ComputerName -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: Standardroute, dynamische oder statische Routen, Firewallzustand, NAT-Regeln, WAN-Schnittstelle, Providerverbindung, VPN- oder Standorttunnel, Hochverfügbarkeitsstatus, Routingnachbarschaften, kürzlich geänderte ACLs oder Firewallregeln. 11. DNS als gemeinsame Ursache erkennen Wenn IP-Adressen erreichbar sind, Namen jedoch auf mehreren Clients nicht funktionieren: nslookup Resolve-DnsName Konfigurierte DNS-Server anzeigen: Get-DnsClientServerAddress DNS-Port prüfen: Test-NetConnection -ComputerName -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 alle Clients verwenden denselben nicht erreichbaren DNS-Server → DNS-Server oder Netzwerkpfad prüfen. nur ein VLAN erreicht den DNS-Server nicht → Routing, ACL oder Firewall prüfen. DNS-Server antwortet, löst aber interne Namen nicht auf → Zone, Einträge oder Replikation prüfen. interne Namen funktionieren, externe nicht → Weiterleitung oder externe DNS-Erreichbarkeit prüfen. externe Namen funktionieren, interne nicht → interne DNS-Zone, Suchsuffix oder verwendeten DNS-Server prüfen. Clients verwenden falsche DNS-Server → DHCP-Optionen oder statische Konfiguration prüfen. 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: sind die Access Points erreichbar, erhalten sie Strom über PoE, ist der PoE-Budget-Grenzwert des Switches erreicht, besteht die Verbindung zum WLAN-Controller, wird die SSID ausgestrahlt, funktioniert RADIUS oder 802.1X, sind Zertifikate gültig, stimmt die Systemzeit, werden Clients dem vorgesehenen VLAN zugeordnet, funktioniert DHCP in diesem VLAN, besteht eine ungewöhnlich hohe Funkbelastung, trat der Fehler nach einer Konfigurationsänderung auf? 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: Status beider Firewalls oder Router, aktive und passive Rolle, Zustand des Synchronisationslinks, gemeinsames virtuelles Gateway, Status redundanter Switch-Uplinks, Link Aggregation oder EtherChannel, Spanning-Tree-Zustand, DHCP-Failover, DNS-Redundanz, redundante WAN-Verbindungen, Standort-VPN-Tunnel, Zeitpunkt eines Failovers. Mögliche Fehlerbilder: beide Systeme glauben, aktiv zu sein, kein System übernimmt die aktive Rolle, Zustände wurden nicht synchronisiert, virtuelle IP-Adresse ist nicht erreichbar, ein Teil der VLANs wurde nicht übernommen, Routing oder NAT fehlt nach der Umschaltung, ein redundanter Link ist physisch aktiv, transportiert aber nicht alle VLANs. 14. Änderungen und Zeitpunkte korrelieren Vor Maßnahmen prüfen: wann begann die Störung, wurden Switch-, Firewall- oder Routerregeln geändert, wurde ein VLAN hinzugefügt oder entfernt, gab es ein Firmware- oder Betriebssystemupdate, wurde ein Access Point oder Switch ausgetauscht, wurde die Patchung verändert, gab es einen Stromausfall, wurde ein Zertifikat erneuert, wurde eine DHCP- oder DNS-Konfiguration geändert, fand ein Failover statt, meldet der Provider eine Störung? 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 Ethernet und WLAN des Stockwerks sind betroffen. Alle betroffenen Access Points und Netzwerkdosen führen über denselben Etagen-Switch. Clients anderer Etagen erreichen interne Systeme und das Internet. Clientprüfung ipconfig /all Ergebnis auf mehreren Clients: IPv4-Adresse: 169.254.x.x Standardgateway: DHCP aktiviert: Ja Bewertung die Störung betrifft nicht nur einen Client, mehrere Clients erhalten keine DHCP-Konfiguration, Ethernet und WLAN besitzen dieselbe gemeinsame Infrastruktur, der Etagen-Switch oder dessen Uplink ist zu priorisieren. Infrastrukturprüfung Etagen-Switch ist eingeschaltet, Clientports besitzen Link, Uplink-Port ist jedoch ohne Verbindung, Gegenstelle zeigt ebenfalls keinen Link. 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 Uplink ist stabil aktiv, erforderliche VLANs werden transportiert, Clients erhalten gültige DHCP-Adressen, Gateways sind erreichbar, interne Systeme sind erreichbar, externe IP-Verbindung funktioniert, DNS-Auflösung funktioniert, Ethernet- und WLAN-Clients wurden getestet, Schnittstellenfehler und Protokolle wurden erneut geprüft, Ursache und Austausch wurden dokumentiert. 16. Ungeeignete Sofortmaßnahmen Nicht als erste Maßnahme verwenden: alle betroffenen Clients neu starten, Switch oder Router ohne Diagnose neu starten, Firewall ungeprüft deaktivieren, VLAN-Zuordnungen versuchsweise ändern, Switchports wahllos deaktivieren und aktivieren, DHCP-Leases auf allen Clients freigeben, allen Clients statische Adressen geben, öffentliche DNS-Server eintragen, Spanning Tree deaktivieren, redundante Links ungeprüft umstecken, Firewallregeln vollständig zurücksetzen, mehrere Infrastrukturänderungen gleichzeitig durchführen, funktionierende Konfigurationen überschreiben, Werkseinstellungen laden. Solche Maßnahmen können den Fehler vergrößern, Diagnoseinformationen vernichten oder weitere Netzwerkbereiche beeinträchtigen. 17. Vollständige Schnellprüfreihenfolge genaue Fehlermeldung und Beginn erfassen. Anzahl und Standort der betroffenen Clients bestimmen. funktionierende Vergleichsclients suchen. gemeinsame Switches, VLANs, Access Points oder Dienste ermitteln. Ethernet und WLAN getrennt vergleichen. Adapter- und Linkstatus mehrerer Clients prüfen. IP-Konfiguration mehrerer Clients vergleichen. auf 169.254.x.x , falsche Subnetze oder fehlende Gateways achten. DHCP-Dienst, Bereich und Relay prüfen. Gateway jedes betroffenen VLANs testen. lokales Vergleichsziel testen. externe IP-Adresse testen. DNS-Auflösung getrennt prüfen. benötigten Zielport prüfen. Switchstatus und Uplinks untersuchen. VLAN- und Trunk-Konfiguration prüfen. Spanning Tree und Portschutz berücksichtigen. Firewall, NAT und Routing prüfen. WAN- und Standortverbindungen prüfen. Redundanz- und Failoverstatus prüfen. Ereignisse mit dem Fehlerbeginn korrelieren. letzte Änderungen ermitteln. eine gemeinsame Ursache als Hypothese formulieren. genau eine kontrollierte Maßnahme durchführen. dieselben Tests nach der Änderung wiederholen. alle zuvor betroffenen Bereiche testen. Überwachung und Protokolle kontrollieren. temporäre Diagnoseänderungen entfernen. Ursache, Maßnahme und Nachweis dokumentieren. 18. Checkliste „Mehrere Clients haben kein Netzwerk“ Beginn und genaue Auswirkung der Störung sind dokumentiert. die betroffenen Clients und Standorte sind bekannt. funktionierende Vergleichsclients wurden geprüft. gemeinsame Switches, VLANs oder Access Points wurden ermittelt. Ethernet und WLAN wurden getrennt betrachtet. interne und externe Ziele wurden unterschieden. Linkstatus mehrerer Clients wurde geprüft. IP-Konfigurationen wurden miteinander verglichen. DHCP-Ausfall oder falscher DHCP-Bereich wurde berücksichtigt. freie DHCP-Leases wurden geprüft. DHCP-Relay wurde bei Bedarf geprüft. Standardgateways wurden getestet. lokale Vergleichsziele wurden getestet. externe IP-Ziele wurden getestet. DNS wurde getrennt von der IP-Erreichbarkeit geprüft. betroffene Zielports wurden geprüft. Switchstatus und Stromversorgung wurden kontrolliert. Switch-Uplinks wurden geprüft. Interfacefehler und Port-Flaps wurden berücksichtigt. VLAN- und Trunk-Konfigurationen wurden geprüft. Spanning-Tree-Zustand wurde berücksichtigt. Port-Security oder Errdisable wurde geprüft. Firewallregeln und ACLs wurden berücksichtigt. Routing und Standardroute wurden geprüft. NAT und Internetübergang wurden geprüft. WAN- oder Standortverbindungen wurden geprüft. WLAN-Controller, RADIUS und PoE wurden bei Bedarf geprüft. Hochverfügbarkeits- und Failoverstatus wurde kontrolliert. letzte Änderungen wurden mit dem Fehlerbeginn verglichen. vor Eingriffen wurden Protokolle und Zustände gesichert. nur eine kontrollierte Änderung wurde durchgeführt. dieselben Tests wurden anschließend wiederholt. alle betroffenen Clientgruppen funktionieren wieder. die Infrastrukturüberwachung zeigt einen stabilen Zustand. Ursache, Maßnahme und Nachweis wurden dokumentiert. 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 Microsoft Learn – DHCP troubleshooting guidance Microsoft Learn – Troubleshoot problems on the DHCP server Microsoft Learn – Troubleshoot problems on the DHCP client Microsoft Learn – Get-DhcpServerv4Scope Microsoft Learn – Get-DhcpServerv4ScopeStatistics Microsoft Learn – Get-DhcpServerv4Binding Microsoft Learn – Get-DhcpServerv4Failover Microsoft Learn – ipconfig Microsoft Learn – ping Microsoft Learn – tracert Microsoft Learn – Get-NetAdapter Microsoft Learn – Get-NetRoute Microsoft Learn – Get-NetNeighbor Microsoft Learn – Test-NetConnection Microsoft Learn – Resolve-DnsName Cisco – Troubleshoot STP problems and related design considerations Cisco – Spanning Tree Protocol documentation 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: falscher DNS-Server am Client, falscher oder unvollständiger Zielname, fehlendes DNS-Suffix, falscher DNS-Eintrag, veralteter positiver oder negativer Cacheeintrag, unterschiedliche Antworten mehrerer DNS-Server, fehlende Zonenreplikation, fehlerhafter Forwarder oder Conditional Forwarder, defekte Delegation, blockiertes UDP oder TCP auf Port 53, falsche hosts -Datei, VPN- oder NRPT-Regel, Split-DNS, DNS over HTTPS, nur fehlerhafter A- oder AAAA-Eintrag. 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 -InformationLevel Detailed Für einen konkreten Dienst: Test-NetConnection -ComputerName -Port Danach denselben Test mit dem Namen durchführen: Test-NetConnection -ComputerName -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: eingegebener Zielname, erwarteter vollständiger DNS-Name, Groß- und Kleinschreibung bei nachgelagerten Anwendungen, verwendete Anwendung, genaue Fehlermeldung, Zeitpunkt der Abfrage, erwartete IP-Adresse, tatsächlich gelieferte IP-Adresse, interne oder externe Domäne, Verbindung mit oder ohne VPN. 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: welcher Adapter aktiv verwendet wird, welche DNS-Server am aktiven Adapter eingetragen sind, ob die DNS-Server per DHCP oder statisch gesetzt wurden, ob ein VPN-Adapter eigene DNS-Server einträgt, ob virtuelle Adapter beteiligt sind, ob öffentliche DNS-Server an einem Domänenclient eingetragen sind, ob IPv4 und IPv6 unterschiedliche DNS-Server verwenden, ob ein verbindungsspezifisches DNS-Suffix vorhanden ist, ob die DNS-Suffixsuchliste korrekt ist. 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 Ein fehlgeschlagener Ping beweist keinen Ausfall, da ICMP blockiert sein kann. TCP-Port 53 prüfen: Test-NetConnection -ComputerName -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: dass UDP 53 funktioniert, dass der DNS-Dienst korrekte Antworten liefert, dass die richtige Zone vorhanden ist, dass der gewünschte Record existiert. 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 Beispiel: Resolve-DnsName server01.example.local Gezielt einen bestimmten DNS-Server abfragen: Resolve-DnsName -Server Alternativ: nslookup Bestimmten DNS-Server abfragen: nslookup Zu dokumentieren sind: abgefragter Name, verwendeter DNS-Server, Rückgabecode, zurückgegebene IP-Adresse, Record-Typ, autoritative oder nicht autoritative Antwort, TTL, Unterschiede zwischen mehreren DNS-Servern. 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“ kein DNS-Suffix vorhanden, falsches verbindungsspezifisches Suffix, falsche globale Suchliste, VPN ändert die Suffixsuchliste, DHCP-Option liefert ein falsches Suffix, Gruppenrichtlinie setzt eine falsche Suchliste, Anwendung ergänzt keinen DNS-Suffix, Kurzname ist mehrdeutig. 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 -Type A IPv6-Eintrag abfragen: Resolve-DnsName -Type AAAA Mit nslookup : nslookup -type=A nslookup -type=AAAA 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 Danach den benötigten Port an der gelieferten Adresse testen: Test-NetConnection -ComputerName -Port Zu klären sind: gehört die IP-Adresse zum vorgesehenen Server, ist die Adresse noch aktuell, existieren mehrere A- oder AAAA-Einträge, verweist ein CNAME auf das richtige Ziel, stammt die Antwort aus einer internen oder externen Zone, liefert das VPN eine andere Antwort, verwendet der Client möglicherweise einen alten Cacheeintrag? 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 "**" Zu prüfen sind: gespeicherter Name, Record-Typ, gespeicherte Adresse, verbleibende TTL, negativer Cacheeintrag, Unterschied zur direkten Abfrage des DNS-Servers. Vergleich Resolve-DnsName und anschließend gezielt: Resolve-DnsName -Server 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 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: Name verweist auf eine alte IP-Adresse, Tippfehler im Hostnamen, Testeintrag wurde nicht entfernt, Sicherheitssoftware hat einen Eintrag ergänzt, Anwendung erreicht dadurch ein anderes Ziel, ein lokaler Eintrag verdeckt die erwartete DNS-Antwort. 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 "" Resource Record suchen: Get-DnsServerResourceRecord -ZoneName "" -Name "" A- und AAAA-Records der Zone anzeigen: Get-DnsServerResourceRecord -ZoneName "" -RRType A Get-DnsServerResourceRecord -ZoneName "" -RRType AAAA Zu prüfen sind: existiert die richtige Zone, ist die Zone geladen, ist der Record vorhanden, stimmt der Record-Typ, stimmt die gespeicherte IP-Adresse, existiert ein alter zusätzlicher Record, verweist ein CNAME auf einen gültigen Zielnamen, ist der Record statisch oder dynamisch registriert, stimmt der Zeitstempel, ist die TTL plausibel, befindet sich der Record auf allen zuständigen DNS-Servern, wird möglicherweise eine gleichnamige, aber falsche Zone verwendet? 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 Ausführlich mit nslookup : nslookup -debug Mögliche Situation: ein Record zeigte auf eine alte IP-Adresse, der Record wurde auf dem DNS-Server korrigiert, ein Client oder zwischengeschalteter Resolver besitzt noch die alte Antwort, der Client verwendet diese bis zum Ablauf der TTL weiter. Zu berücksichtigen sind: lokaler Clientcache, Cache des DNS-Servers, Forwarder-Cache, Anwendungscache, Browsercache, Proxy- oder Sicherheitsgateway, negative Cacheeinträge. 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: Replikationsbereich der Zone, Zustand der Active-Directory-Replikation, Vorhandensein des Records auf allen zuständigen DNS-Servern, Zeitpunkt der letzten Änderung, Erreichbarkeit der Replikationspartner, Ereignisprotokolle von DNS und Active Directory. Zone auf mehreren Servern gezielt vergleichen: Get-DnsServerResourceRecord ` -ComputerName ` -ZoneName "" ` -Name "" Get-DnsServerResourceRecord ` -ComputerName ` -ZoneName "" ` -Name "" Hinweise auf ein Replikationsproblem ein DNS-Server liefert die neue IP-Adresse, ein anderer DNS-Server liefert die alte IP-Adresse, ein Server besitzt den Record, ein anderer meldet NXDOMAIN , Fehler tritt nur an einem Standort auf, Fehler tritt abhängig vom verwendeten DNS-Server auf, eine kürzlich angelegte Zone oder ein Record fehlt auf einzelnen Servern. 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 "" Zu prüfen sind: wird die betroffene Domäne lokal autoritativ beantwortet, existiert ein Conditional Forwarder für die Domäne, zeigen dessen Zieladressen auf die richtigen DNS-Server, sind diese Server erreichbar, antworten sie auf die betreffende Anfrage, funktioniert UDP und TCP 53, besteht der erforderliche VPN- oder Standortpfad, ist die Weiterleitungszone korrekt repliziert, greift unbeabsichtigt eine lokale Zone statt des Forwarders? Gezielte Prüfung des Zielservers: Resolve-DnsName -Server 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 -Type NS SOA-Eintrag prüfen: Resolve-DnsName -Type SOA Zu prüfen sind: existiert die Delegation in der übergeordneten Zone, sind die richtigen NS-Records eingetragen, lassen sich die Nameservernamen auflösen, stimmen benötigte Glue Records, sind die delegierten DNS-Server erreichbar, hosten diese Server die untergeordnete Zone, liefern sie den erwarteten Record? 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: Antwort ist für UDP zu groß, DNSSEC vergrößert die Antwort, Zonentransfer, Server fordert Wiederholung über TCP, bestimmte Netzwerk- oder Serverkonfigurationen. Nur TCP testen: Test-NetConnection -ComputerName -Port 53 Eine tatsächliche DNS-Abfrage ausführen: Resolve-DnsName -Server Abfrage ausdrücklich über TCP erzwingen: Resolve-DnsName -Server -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 Resolve-DnsName portal.example.com -Server Zu prüfen sind: ist der Client intern oder extern, besteht eine VPN-Verbindung, verwendet der Client den internen DNS-Server, existiert eine interne Zone mit demselben Namen, enthält die interne Zone den benötigten Record, liefert ein öffentlicher Resolver absichtlich eine andere Adresse, ist die interne Zieladresse vom aktuellen Standort erreichbar? 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: eigene DNS-Server erhalten, nur bestimmte DNS-Domänen über das VPN auflösen, eine DNS-Suffixsuchliste erhalten, Split-Tunneling verwenden, die Name Resolution Policy Table verwenden, interne und externe Anfragen unterschiedlich behandeln. 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: tritt der Fehler nur mit VPN auf, tritt der Fehler nur ohne VPN auf, ist der interne DNS-Server über den Tunnel erreichbar, wird das interne Präfix über das VPN geroutet, greift die vorgesehene NRPT-Regel, verwendet die betroffene Domäne den richtigen DNS-Server, überschreibt der VPN-Client die Suffixsuchliste, besteht eine Überschneidung interner und lokaler Netze? 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: ist DoH auf dem Client aktiviert, welcher DoH-Server wird verwendet, verwendet der Browser einen eigenen sicheren DNS-Dienst, umgeht die Anwendung den internen DNS-Server, kann der DoH-Server interne Namen überhaupt auflösen, blockiert eine Unternehmensrichtlinie nicht vorgesehene DoH-Verbindungen, funktioniert die Namensauflösung im Betriebssystem, aber nicht im Browser, funktioniert sie im Browser, aber nicht in anderen Anwendungen? 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: enthält der Server eine alte IP-Adresse, wurde zuvor eine negative Antwort gespeichert, liefert der autoritative Server inzwischen eine andere Antwort, verwenden mehrere DNS-Server unterschiedliche Cachezustände, funktioniert eine direkte Abfrage des autoritativen Servers? Beispiel: Resolve-DnsName -Server Resolve-DnsName -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 -Type CNAME Normale Abfrage: Resolve-DnsName Beispiel: portal.example.local CNAME -> webfarm.example.local A -> 192.0.2.80 Zu prüfen sind: existiert der CNAME, ist dessen Zielname korrekt geschrieben, lässt sich der Zielname auflösen, verweist die Kette auf eine gültige Adresse, besteht eine Schleife, liegt das Ziel in einer anderen Zone, funktioniert die Weiterleitung zu dieser Zone, existieren widersprüchliche Records? 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: Anwendung vollständig neu gestartet, anwendungseigener DNS-Cache, Browsercache, Proxykonfiguration, Browser-DoH, fest konfigurierte Zieladresse, Zertifikat stimmt nicht zum Namen, Anwendung verwendet einen Alias oder anderen Hostnamen, Load-Balancer oder Reverse Proxy, Verbindung über IPv4 oder IPv6, lokale Sicherheitssoftware, PAC-Datei oder Webproxy, Container, VM oder WSL mit eigener DNS-Konfiguration. Vergleichstests Resolve-DnsName Test-NetConnection -ComputerName -Port Test-NetConnection -ComputerName -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 SMB-Port 445 ist an der tatsächlichen Serveradresse erreichbar. Der Name wird aufgelöst. Die gelieferte Adresse ist jedoch veraltet. Es liegt kein allgemeiner Netzwerkausfall vor. DNS-Record, Cache und Replikation müssen geprüft werden. 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 Replikationsfehler untersucht und behoben, Replikation des DNS-Records bestätigt, beide DNS-Server liefern anschließend dieselbe Adresse, alter Clientcache erst nach der Dokumentation geleert. 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: öffentliche DNS-Server am Unternehmensclient eintragen, DNS-Server wahllos austauschen, DNS-Cache vor der Dokumentation löschen, DNS-Servercache vollständig leeren, hosts -Datei ungeprüft bearbeiten, einen neuen DNS-Record zusätzlich anlegen, ohne vorhandene Records zu prüfen, mehrere widersprüchliche A-Records erstellen, DNS-Zone auf jedem Server manuell nachbauen, DNS-Dienst oder Domain Controller sofort neu starten, VPN-Client ungeprüft deinstallieren, NRPT-Regeln ungeprüft löschen, DoH pauschal deaktivieren, IPv6 vollständig deaktivieren, Firewall vollständig abschalten, TTL ohne Ursachenanalyse stark verkürzen, mehrere DNS-Änderungen gleichzeitig durchführen, ausschließlich mit ping testen, erfolgreiche IP-Erreichbarkeit mit vollständiger Anwendungsfunktion gleichsetzen. 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 genaue Fehlermeldung und Uhrzeit erfassen. verwendeten Namen exakt dokumentieren. erwartete Ziel-IP und Zielport feststellen. Zielport über die IP-Adresse prüfen. Zielport über den Namen prüfen. FQDN und Kurzname getrennt testen. aktive Netzwerkadapter ermitteln. konfigurierte DNS-Server dokumentieren. DNS-Suffix und Suchliste prüfen. VPN und virtuelle Adapter berücksichtigen. jeden eingetragenen DNS-Server einzeln abfragen. Antworten und TTL miteinander vergleichen. A- und AAAA-Records getrennt prüfen. CNAME-Kette untersuchen. zurückgegebene IP-Adressen einzeln testen. Clientcache anzeigen und dokumentieren. negative Cacheeinträge berücksichtigen. hosts -Datei kontrollieren. Zone und Resource Record auf dem DNS-Server prüfen. Record auf allen zuständigen DNS-Servern vergleichen. Zonen- oder AD-Replikation untersuchen. Forwarder und Conditional Forwarder prüfen. Delegation und Nameserver prüfen. UDP und TCP 53 unterscheiden. Split-DNS berücksichtigen. VPN-Routing, DNS-Zuweisung und NRPT prüfen. DoH und anwendungseigene Resolver berücksichtigen. genau eine Hypothese formulieren. genau eine kontrollierte Maßnahme durchführen. dieselben Abfragen erneut ausführen. jeden vorgesehenen DNS-Server erneut testen. den benötigten Dienst über den Namen prüfen. Vergleichsclient oder Vergleichsstandort testen. temporäre Diagnoseänderungen entfernen. Ursache, Maßnahme und Nachweis dokumentieren. 29. Checkliste „Name geht nicht, IP geht“ genaue Fehlermeldung wurde dokumentiert. Zeitpunkt der fehlerhaften Abfrage ist bekannt. verwendeter Zielname wurde exakt übernommen. erwarteter FQDN ist bekannt. erwartete Ziel-IP ist bekannt. benötigter Zielport wurde bestimmt. Zielport ist über die IP-Adresse erreichbar. Zielport wurde auch über den Namen getestet. FQDN und Kurzname wurden getrennt geprüft. aktive Netzwerkadapter wurden ermittelt. konfigurierte DNS-Server wurden dokumentiert. DHCP- oder statische DNS-Konfiguration wurde unterschieden. DNS-Suffix wurde geprüft. DNS-Suffixsuchliste wurde geprüft. VPN-Adapter wurden berücksichtigt. virtuelle Adapter wurden berücksichtigt. jeder DNS-Server wurde einzeln abgefragt. Antworten mehrerer DNS-Server wurden verglichen. A-Record wurde geprüft. AAAA-Record wurde geprüft. CNAME-Kette wurde geprüft. zurückgegebene IP-Adressen wurden auf Plausibilität geprüft. alle gelieferten Zieladressen wurden berücksichtigt. TTL wurde dokumentiert. Clientcache wurde vor dem Leeren untersucht. negativer Cache wurde berücksichtigt. hosts -Datei wurde geprüft. zuständige DNS-Zone wurde ermittelt. Resource Record wurde serverseitig geprüft. mehrere zuständige DNS-Server wurden verglichen. Zonenreplikation wurde berücksichtigt. Active-Directory-Replikation wurde bei Bedarf geprüft. Forwarder wurden geprüft. Conditional Forwarder wurden geprüft. Delegationen wurden berücksichtigt. UDP und TCP 53 wurden unterschieden. Split-DNS wurde berücksichtigt. VPN-DNS und NRPT wurden berücksichtigt. DNS over HTTPS wurde berücksichtigt. anwendungseigene DNS-Auflösung wurde berücksichtigt. vor Änderungen wurden Antworten und Cachezustände gesichert. nur eine kontrollierbare Änderung wurde durchgeführt. dieselben Abfragen wurden anschließend wiederholt. alle vorgesehenen DNS-Server liefern konsistente Antworten. der benötigte Dienst funktioniert wieder über den Namen. Ursache, Maßnahme und Nachweis wurden dokumentiert. 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 Microsoft Learn – DNS Client PowerShell module Microsoft Learn – Resolve-DnsName Microsoft Learn – Get-DnsClientServerAddress Microsoft Learn – Get-DnsClient Microsoft Learn – Get-DnsClientGlobalSetting Microsoft Learn – Get-DnsClientCache Microsoft Learn – Clear-DnsClientCache Microsoft Learn – Get-DnsClientDohServerAddress Microsoft Learn – Secure DNS Client over HTTPS Microsoft Learn – nslookup Microsoft Learn – ipconfig Microsoft Learn – Test-NetConnection Microsoft Learn – DNS zones Microsoft Learn – Manage DNS zones Microsoft Learn – DNS forwarding Microsoft Learn – Get-DnsServerZone Microsoft Learn – Get-DnsServerResourceRecord Microsoft Learn – Get-DnsServerForwarder Microsoft Learn – Get-DnsServerConditionalForwarderZone Microsoft Learn – Best practices for DNS client settings 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: falsches Access-VLAN, VLAN auf einem Switch nicht vorhanden, VLAN auf einem Trunk nicht zugelassen, Native-VLAN-Mismatch, fehlerhafte Portkonfiguration, blockierter Port durch Spanning Tree, gestörter EtherChannel, falsche MAC-Adresszuordnung, Port-Security-Verletzung, Schleife oder MAC-Flapping, physischer Fehler an Port oder Verkabelung. 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: betroffener Client, MAC-Adresse des Clients, Switchname, physischer Switchport, vorgesehenes Access-VLAN, gegebenenfalls Voice-VLAN, IP-Subnetz des VLANs, vorgesehene Gateway-Adresse, beteiligte Uplinks, beteiligte Trunks, erlaubte VLANs auf jedem Trunk, Native VLAN, zuständiges SVI oder Router-Subinterface, mögliche EtherChannels, verwendete Spanning-Tree-Variante, Zeitpunkt und Umfang der Störung. 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: ist nur ein Client betroffen, sind mehrere Clients am gleichen Portpfad betroffen, betrifft der Fehler alle Ports eines Switches, betrifft der Fehler nur ein VLAN, betrifft er mehrere VLANs, betrifft er nur einen Switch, betrifft er mehrere Switches, funktioniert die Kommunikation innerhalb des VLANs, funktioniert die Kommunikation zum Gateway, funktioniert die Kommunikation zwischen VLANs, begann die Störung nach einer Änderung? 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 link show ip address show ip route show Unter macOS: ifconfig route -n get default Zu prüfen sind: ist der richtige Adapter aktiv, besitzt der Client eine Adresse aus dem vorgesehenen Subnetz, stimmt die Präfixlänge, stimmt das Standardgateway, stammt die Adresse aus dem erwarteten DHCP-Bereich, existieren zusätzliche aktive Adapter, verwendet der Client selbst VLAN-Tagging, ist eine Bridge oder virtuelle Netzwerkkarte aktiv, läuft eine VM oder ein Container mit eigener Netzwerkkonfiguration? 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: Portstatus, ausgehandeltes Tempo, Duplexmodus, Ein- und Ausgangsfehler, CRC-Fehler, Drops, Link-Flapping, Zeitpunkt der letzten Statusänderung, administrativ deaktivierter Port, Fehlerzustand wie err-disabled . 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 Link Layer Discovery Protocol: show lldp neighbors Details: show lldp neighbors detail Zu prüfen sind: welches Gerät tatsächlich angeschlossen ist, welcher lokale Port verwendet wird, welcher Gegenstellenport gemeldet wird, ob statt eines Clients ein weiterer Switch angeschlossen ist, ob ein IP-Telefon zwischen Client und Switch liegt, ob die dokumentierte Verkabelung mit der erkannten Topologie übereinstimmt. 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: administrativer Portmodus, tatsächlich verwendeter Portmodus, Access-VLAN, Voice-VLAN, Native VLAN bei einem Trunk, erlaubte VLANs, dynamische oder fest konfigurierte Aushandlung, zusätzliche Sicherheits- oder Authentifizierungsfunktionen. 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: existiert VLAN 20, ist es aktiv, besitzt es den erwarteten Namen, sind die vorgesehenen Access-Ports zugeordnet, existiert das VLAN auf jedem beteiligten Switch, wurde es möglicherweise gelöscht oder umnummeriert, ist eine VLAN-Verwaltung wie VTP beteiligt? 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: ip link show 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: wird die Client-MAC gelernt, wird sie im richtigen VLAN gelernt, erscheint sie am erwarteten Port, erscheint sie auf einem Uplink statt am lokalen Clientport, wechselt sie zwischen mehreren Ports, fehlt sie vollständig, ist der Eintrag dynamisch oder statisch? 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: VLAN auf dem nächsten Switch vorhanden, VLAN am Trunk zugelassen, Trunk tatsächlich aktiv, STP-Status des VLANs, EtherChannel-Zustand, Native-VLAN-Konfiguration, physische Verbindung. 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: ist der Port operativ ein Trunk, wird IEEE 802.1Q verwendet, welches Native VLAN ist konfiguriert, welche VLANs sind administrativ zugelassen, welche VLANs sind aktiv, welche VLANs werden tatsächlich weitergeleitet, welche VLANs sind durch Spanning Tree nicht blockiert? 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 VLAN bei einer Änderung aus der Liste entfernt, VLAN nur auf einer Trunkseite ergänzt, falscher Uplink bearbeitet, VLAN-Liste versehentlich vollständig ersetzt, EtherChannel-Mitglieder besitzen unterschiedliche Konfigurationen, VLAN existiert auf einem Switch nicht. 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 switchport Beispiel eines Mismatch: Switch A: Native VLAN 999 Switch B: Native VLAN 1 Mögliche Auswirkungen: ungetaggter Verkehr landet auf beiden Seiten in unterschiedlichen VLANs, Spanning Tree meldet eine PVID-Inkonsistenz, ein Port oder VLAN wird durch Schutzmechanismen blockiert, Verwaltungs- oder Steuerverkehr erreicht ein falsches VLAN, Sicherheitsrisiken durch unbeabsichtigte VLAN-Zuordnung. 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 transportiert normalerweise den Datenverkehr genau eines Data-VLANs, Endgerät sendet üblicherweise ungetaggte Ethernet-Frames, Switch ordnet eingehende Frames dem Access-VLAN zu. Trunk-Port transportiert mehrere VLANs, VLAN-Zuordnung erfolgt normalerweise über IEEE 802.1Q-Tags, Native-VLAN-Verkehr kann abhängig von der Konfiguration ungetaggt sein. 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: Servern mit mehreren VLANs, Hypervisoren, virtuellen Switches, Containernetzwerken, Firewalls, Access Points, IP-Telefonen, Netzwerktestgeräten, speziellen Netzwerkkartentreibern. Zu prüfen sind: ist am Client eine VLAN-ID konfiguriert, erwartet der Switch einen Access-Port oder Trunk, stimmt die VLAN-ID des Clients mit der Switchkonfiguration überein, entfernt der Netzwerkkartentreiber VLAN-Tags, existiert ein Hypervisor-vSwitch mit eigener VLAN-Zuordnung, wird das Tag bereits an einer anderen Ebene hinzugefügt? 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: funktioniert nur Telefonie oder nur der PC, ist das Data-VLAN korrekt, ist das Voice-VLAN korrekt, erkennt das Telefon die VLAN-Information, ist der PC-Port des Telefons aktiv, wird das Telefon per LLDP-MED oder CDP konfiguriert, sind beide VLANs auf dem Uplink zugelassen, existieren DHCP und Gateway in beiden VLANs? 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: besitzt der Client einen Eintrag für das Gateway, ist der Eintrag erreichbar oder unvollständig, stimmt die MAC-Adresse des Gateways, ändert sich die Gateway-MAC unerwartet, antworten Geräte im gleichen Subnetz auf ARP? 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: existiert das SVI, besitzt es die vorgesehene IP-Adresse, ist es administrativ aktiv, ist der Protokollstatus aktiv, ist das zugehörige VLAN vorhanden und aktiv, existiert mindestens ein erforderlicher aktiver Layer-2-Pfad, wird die Client-MAC beziehungsweise IP gelernt, ist ein Redundanzprotokoll beteiligt? Typisches Fehlerbild Vlan20 is administratively up, line protocol is down Mögliche Ursache: VLAN 20 existiert nicht aktiv, kein zugehöriger Layer-2-Port ist aktiv, VLAN wird nicht über einen funktionierenden Trunk transportiert, plattformspezifische Voraussetzungen sind nicht erfüllt. 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: eigene IP-Konfiguration, Ziel im gleichen VLAN, Standardgateway, Ziel in einem anderen internen VLAN, externes Ziel. Windows: Test-NetConnection -ComputerName Test-NetConnection -ComputerName Test-NetConnection -ComputerName -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: Root Bridge, Root Port, Designated Ports, blockierende beziehungsweise verwerfende Ports, Kosten und Prioritäten, Topology Changes, letzte Statusänderungen, inkonsistente Ports, unterschiedliche STP-Modi, unerwartete Root Bridge. 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: der einzige vorgesehene Pfad wird blockiert, Root Bridge befindet sich unerwartet an einem Access-Switch, Ports wechseln wiederholt ihren Zustand, VLANs verwenden unbeabsichtigt unterschiedliche Pfade, PVID- oder Type-Inconsistency wird gemeldet. 22. Spanning-Tree-Änderungen und Schleifen untersuchen show spanning-tree detail Zusätzlich Systemprotokoll prüfen: show logging Hinweise auf mögliche Schleifen: sehr viele Topology Changes, MAC-Adresse wechselt zwischen Ports, Broadcast- oder Multicast-Auslastung steigt stark, Switchmanagement reagiert langsam, mehrere Ports zeigen ungewöhnlich hohe Auslastung, Netzwerk fällt periodisch aus, STP-Root oder Root Port wechselt wiederholt. 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 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: Layer-2-Schleife, zwei aktive Verbindungen desselben Endgeräts ohne korrektes Teaming, falsch aufgebauter EtherChannel, nicht verwalteter Switch, Bridge auf einem Client, Hypervisor- oder Clusterkonfiguration, absichtlich bewegte virtuelle MAC-Adresse, Redundanzprotokoll. 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: gehören alle vorgesehenen Ports zum Channel, sind die Ports tatsächlich gebündelt, verwenden beide Seiten dasselbe Verfahren, stimmen Access- oder Trunkmodus überein, stimmen Native VLAN und Allowed-VLAN-Liste überein, stimmen Geschwindigkeit und Duplex, ist der Port-Channel durch STP freigegeben, sind einzelne Mitglieder suspendiert oder eigenständig aktiv? Typische Fehler ein Link ist nicht im Bundle, LACP ist nur auf einer Seite passend konfiguriert, Mitglieder besitzen unterschiedliche VLAN-Listen, physische Ports werden einzeln statt über den Port-Channel konfiguriert, ein paralleler Link bildet unbeabsichtigt eine Schleife. 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: ist Port-Security aktiviert, wie viele MAC-Adressen sind erlaubt, welche MAC-Adressen wurden gelernt, liegt eine Verletzung vor, welche Reaktion wurde ausgelöst, wurde der Port deaktiviert, wurde ein anderes Endgerät oder Dock angeschlossen? 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: 802.1X, MAC Authentication Bypass, Dynamic VLAN Assignment, DHCP Snooping, Dynamic ARP Inspection, IP Source Guard, BPDU Guard, Root Guard, Loop Guard, Storm Control, Private VLANs, Port-Isolation, Access Control Lists, Network Access Control. 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: BPDU Guard, Port-Security, Link-Flapping, EtherChannel-Fehlkonfiguration, UDLD, Loopback-Erkennung, DHCP-Ratenbegrenzung, Sicherheitsverletzung. 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 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: ob Frames VLAN-Tags besitzen, welche VLAN-ID verwendet wird, ob ARP-Anfragen gesendet werden, ob ARP-Antworten zurückkommen, ob DHCP Discover und Offer sichtbar sind, ob nur eine Richtung des Verkehrs vorhanden ist, ob LLDP- oder STP-Informationen auftreten. 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: Switch ohne Diagnose neu starten, Portkonfiguration vollständig löschen, VLAN vorschnell neu anlegen, alle VLANs auf jedem Trunk erlauben, Native VLAN wahllos auf VLAN 1 setzen, Spanning Tree deaktivieren, blockierte STP-Ports ungeprüft freigeben, EtherChannel auflösen, Port-Security pauschal deaktivieren, 802.1X oder NAC umgehen, BPDU Guard deaktivieren, DHCP Snooping oder ARP Inspection deaktivieren, MAC-Tabelle vor der Dokumentation vollständig löschen, alle Schnittstellen gleichzeitig zurücksetzen, redundante Links abziehen, ohne die Topologie zu prüfen, Firewall oder ACL als vermeintlichen VLAN-Test deaktivieren, mehrere Konfigurationsänderungen gleichzeitig durchführen, ausschließlich mit ping testen, einen erreichbaren Switch mit einem funktionierenden VLAN-Pfad gleichsetzen. Solche Maßnahmen können Diagnoseinformationen beseitigen, Sicherheitsgrenzen verändern oder eine Layer-2-Schleife verursachen. 32. Vollständige Schnellprüfreihenfolge genaue Störung, Zeitpunkt und Auswirkung dokumentieren. feststellen, ob ein oder mehrere Clients betroffen sind. vorgesehenes VLAN, Subnetz und Gateway ermitteln. tatsächliche Client-MAC-Adresse feststellen. tatsächlichen Switch und Port ermitteln. physischen Linkstatus prüfen. Fehlerzähler dokumentieren. Portmodus prüfen. Access- und Voice-VLAN prüfen. Existenz und Status des VLANs prüfen. Client-MAC in der MAC-Tabelle suchen. MAC-Adresse über alle beteiligten Switches verfolgen. jeden Uplink und Trunk ermitteln. operativen Trunkstatus prüfen. Allowed-VLAN-Listen auf beiden Seiten vergleichen. Native VLAN auf beiden Seiten vergleichen. VLAN-Existenz auf jedem Switch prüfen. Spanning-Tree-Zustand für das betroffene VLAN prüfen. blockierte oder inkonsistente Ports untersuchen. Topology Changes und MAC-Flapping prüfen. EtherChannel und seine Mitglieder prüfen. Port-Security und err-disabled prüfen. 802.1X, NAC und dynamische VLAN-Zuweisung berücksichtigen. DHCP Snooping, ARP Inspection und IP Source Guard prüfen. Gateway-SVI und dessen Status prüfen. ARP- beziehungsweise Neighbor-Einträge untersuchen. Kommunikation im gleichen VLAN testen. Gateway separat testen. Inter-VLAN-Kommunikation separat testen. bei Bedarf autorisierten Paketmitschnitt durchführen. genau eine Hypothese formulieren. genau eine kontrollierte Maßnahme durchführen. Port-, VLAN-, Trunk-, STP- und MAC-Zustand erneut prüfen. Clientverbindung und benötigten Dienst erneut testen. Ursache, Änderung und Nachweis dokumentieren. 33. Checkliste VLAN und Switching genaue Fehlermeldung wurde dokumentiert. Zeitpunkt der Störung ist bekannt. Umfang der Störung wurde bestimmt. vorgesehenes Client-VLAN ist bekannt. vorgesehenes IP-Subnetz ist bekannt. vorgesehenes Gateway ist bekannt. tatsächliche Client-MAC-Adresse wurde ermittelt. tatsächlicher Switch wurde ermittelt. tatsächlicher Switchport wurde ermittelt. physischer Linkstatus wurde geprüft. Geschwindigkeit und Duplex wurden geprüft. Fehlerzähler wurden dokumentiert. Link-Flapping wurde berücksichtigt. administrativer Portmodus wurde geprüft. operativer Portmodus wurde geprüft. Access-VLAN wurde geprüft. Voice-VLAN wurde bei Bedarf geprüft. clientseitiges VLAN-Tagging wurde berücksichtigt. VLAN existiert auf dem Access-Switch. VLAN ist aktiv. Client-MAC wird gelernt. MAC erscheint im richtigen VLAN. MAC erscheint am erwarteten Port. MAC wurde über den vollständigen Switchpfad verfolgt. alle beteiligten Uplinks wurden ermittelt. Trunkstatus wurde auf beiden Seiten geprüft. Allowed-VLAN-Listen wurden verglichen. Native VLAN wurde auf beiden Seiten geprüft. VLAN existiert auf jedem beteiligten Switch. Spanning Tree wurde für das betroffene VLAN geprüft. Root Bridge und Root Port wurden geprüft. blockierte Ports wurden bewertet. STP-Inkonsistenzen wurden berücksichtigt. Topology Changes wurden geprüft. MAC-Flapping wurde berücksichtigt. EtherChannel wurde geprüft. Konfiguration der Channel-Mitglieder wurde verglichen. Port-Security wurde geprüft. err-disabled wurde geprüft. 802.1X und NAC wurden berücksichtigt. DHCP Snooping wurde berücksichtigt. Dynamic ARP Inspection wurde berücksichtigt. Gateway-SVI wurde geprüft. ARP- beziehungsweise Neighbor Cache wurde geprüft. Ziel im gleichen VLAN wurde getestet. Gateway wurde getestet. Ziel in einem anderen VLAN wurde getestet. Layer-2- und Layer-3-Fehler wurden getrennt. vor Änderungen wurde der Ausgangszustand gesichert. nur eine kontrollierte Änderung wurde durchgeführt. ursprüngliche Prüfungen wurden anschließend wiederholt. temporäre Diagnoseänderungen wurden entfernt. Ursache, Maßnahme und Nachweis wurden dokumentiert. 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 Cisco – Configure VLANs on Catalyst Switches Cisco – Configuring VLAN Trunks Cisco – Configure and Troubleshoot Inter-VLAN Routing Cisco – Troubleshoot LAN Switching Environments Cisco – Troubleshoot Spanning Tree Issues Cisco – Troubleshoot Spanning Tree PVID and Type Inconsistencies Cisco – Troubleshoot MAC Flaps and Loops Cisco – Understand Rapid Spanning Tree Protocol Cisco – IOS LAN Switching Command Reference Microsoft Learn – Get-NetAdapter Microsoft Learn – Get-NetIPConfiguration Microsoft Learn – Get-NetIPAddress Microsoft Learn – Get-NetNeighbor Microsoft Learn – Test-NetConnection Wireshark – IEEE 802.1Q VLAN Display Filter Reference Wireshark – VLAN Capture Setup Wireshark – PCAP Filter Reference 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: Client oder Netzwerkkarte, Kabel, Switchport oder Transceiver, WLAN-Verbindung, überlasteter Uplink, Routingpfad, Firewall, VPN oder Proxy, WAN- beziehungsweise Internetanbindung, fehlerhafte MTU, TCP-Wiederholungen, Server, Anwendung oder Datenspeicher, allgemeine Überlastung zu bestimmten Zeiten. 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 Webseiten oder Anwendungen öffnen sich verzögert. Dateiübertragungen erreichen nur einen geringen Durchsatz. Netzlaufwerke reagieren langsam. Remote-Sitzungen stocken. Sprache oder Video weisen Aussetzer auf. Downloads sind schnell, Uploads jedoch langsam. Kleine Dateien funktionieren, große Übertragungen brechen ein. Nur WLAN-Clients sind betroffen. Nur ein bestimmter Client ist betroffen. Mehrere Benutzer sind gleichzeitig betroffen. Nur ein Server oder Dienst reagiert langsam. Die Störung tritt nur während bestimmter Uhrzeiten auf. Die Verbindung beginnt schnell und wird anschließend langsamer. Ping funktioniert, die Anwendung benötigt trotzdem lange. Über VPN ist die Verbindung langsamer als im lokalen Netzwerk. Die Leistung schwankt stark. Mögliche Auswirkungen verlängerte Arbeitsabläufe, Abbrüche bei Dateiübertragungen, schlechte Sprach- und Videoqualität, Zeitüberschreitungen in Anwendungen, verzögerte Datenbankabfragen, Probleme bei Backups und Synchronisationen, unvollständige Softwareverteilung, sinkende Produktivität, erhöhte Belastung durch wiederholte Übertragungen, Ausfall zeitkritischer Dienste. 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: Ausgangszustand, Messzeitpunkt, betroffene Systeme, aktuelle Konfiguration, aktuelle Fehlerzähler, bestehende Auslastung, verwendeter Testpfad, erwarteter Sollwert. 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: Welche Anwendung oder Übertragung ist langsam? Seit wann besteht die Störung? Ist sie dauerhaft oder zeitabhängig? Welche Leistung wird erwartet? Welche Leistung wird tatsächlich erreicht? Betrifft es Upload, Download oder beide Richtungen? Sind kleine und große Dateien gleichermaßen betroffen? Tritt die Störung lokal, über VPN oder über das Internet auf? Besteht das Problem über Ethernet, WLAN oder beide Zugangsarten? Funktionierte der gleiche Vorgang früher schneller? Existieren ältere Messwerte als Vergleich? 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: auf einem zweiten Client, am gleichen Switch, an einem anderen Switch, über Ethernet statt WLAN, innerhalb desselben VLANs, zu einem anderen Server, ohne VPN, sofern der vorgesehene Test dies erlaubt. 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: Ethernet-Header, IP-Header, TCP- oder UDP-Header, Verschlüsselung, Anwendungsoverhead, Dateisystem, Storage, Latenz, Paketverlust, konkurrierender Datenverkehr. 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 link show ip address show Unter macOS: ifconfig Zu prüfen sind: richtiger Netzwerkadapter aktiv, erwartete Linkgeschwindigkeit, zusätzlicher WLAN- oder Ethernet-Adapter, VPN-Adapter, virtuelle Netzwerkkarten, Dockingstation, USB-Netzwerkadapter, Bridge, Hypervisor oder Containernetzwerk, Energiesparzustand, aktueller Netzwerkkartentreiber. 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: ausgehandelte Geschwindigkeit, Duplexmodus, administrative Einstellungen, operativer Zustand, Übereinstimmung beider Seiten, unerwarteter Rückfall auf 100 Mbit/s , Halbduplex statt Vollduplex, Link-Flapping. Typisches Fehlerbild Erwartet: 1 Gbit/s Full Duplex Tatsächlich: 100 Mbit/s Mögliche Ursachen: beschädigtes oder ungeeignetes Kabel, fehlerhafte Ader oder Steckverbindung, problematische Dockingstation, defekter Switchport, Transceiverproblem, manuell erzwungene Geschwindigkeit, fehlerhafte Aushandlung, Netzwerkkartentreiber. 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 Auf Cisco-Switches: show interfaces GigabitEthernet1/0/12 Kurze Fehlerübersicht: show interfaces counters errors Zu prüfen sind: CRC- beziehungsweise FCS-Fehler, Input Errors, Output Errors, Discards, Drops, Runts, Giants, Frame Errors, Kollisionen, Late Collisions, Interface Resets, Queue Drops. 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 -n 20 Mit festgelegter Paketgröße: ping -n 20 -l 1400 Linux: ping -c 20 macOS: ping -c 20 Zu dokumentieren sind: Minimum, Maximum, Durchschnitt, Paketverlust, starke Abweichungen einzelner Antworten, Unterschiede zu einem Referenzwert. 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: blockieren, begrenzen, verzögert beantworten, niedriger priorisieren. 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: eigenes TCP/IP-System, Standardgateway, Ziel im gleichen VLAN, Ziel in einem anderen internen VLAN, interner Server, externes Ziel. Beispiel: ping -n 20 ping -n 20 ping -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 pathping -n PowerShell: Test-NetConnection -ComputerName -TraceRoute Unter Linux: traceroute -n Alternativ, sofern vorhanden: mtr -n Unter macOS: traceroute -n pathping kombiniert eine Pfadermittlung mit wiederholten ICMP-Messungen. Die Ausführung benötigt einige Zeit. Zu prüfen sind: unerwartete Route, zusätzlicher VPN- oder Proxy-Pfad, ungewöhnlich viele Hops, Wechsel des Pfades, erhöhte Latenz ab einem bestimmten Segment, Unterschiede zwischen funktionierendem und betroffenem Client. 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 Längere Messung: iperf3 -c -t 30 Umgekehrte Richtung: iperf3 -c -R Mehrere parallele Datenströme: iperf3 -c -P 4 Bidirektionaler Test, sofern von der verwendeten Version unterstützt: iperf3 -c --bidir UDP-Test nur mit kontrollierter Bandbreite: iperf3 -c -u -b 100M -t 20 Wichtige Werte gemessener Durchsatz, Retransmissions bei TCP, Paketverlust bei UDP, Jitter bei UDP, Unterschied zwischen Sende- und Empfangsrichtung, Schwankungen zwischen den Messintervallen. 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 Uplink prüfen: show interfaces GigabitEthernet1/0/48 Zu prüfen sind: Eingangs- und Ausgangsrate, Fehlerzähler, Drops, Queue Drops, Linkgeschwindigkeit, Duplex, Auslastung, Zeitpunkt der letzten Statusänderung, Uplink mit geringerer Geschwindigkeit als erwartet, überbuchter gemeinsamer Uplink. 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: steigende Latenz, Jitter, Paketverlust, Output Drops, TCP-Wiederholungen, schwankenden Durchsatz, schlechte Sprach- und Videoqualität. Zu prüfen sind: aktuelle Auslastung, Durchschnitt und Spitzenwerte, Ein- und Ausgangsrichtung, Queue Drops, Quality-of-Service-Klassen, Traffic Shaping, Policing, Backups oder Synchronisationen, große Softwareverteilungen, Cloud-Uploads, Kamerastreams, replizierende Server. 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: Signalstärke, Signal-Rausch-Abstand beziehungsweise SNR, verwendetes Frequenzband, Kanal, Kanalbreite, ausgehandelte Sende- und Empfangsrate, Anzahl der Wiederholungen, Entfernung zum Access Point, Hindernisse, Roaming, unerwarteter Access Point. Wichtig Ein starkes Signal allein beweist keine gute WLAN-Leistung. Auch bei guter Signalstärke können folgende Probleme bestehen: hoher Störpegel, hohe Kanalauslastung, Gleichkanalstörungen, überlappende Kanäle, viele gleichzeitig aktive Clients, langsame Clients mit hohem Airtime-Verbrauch, externe Störquellen, problematisches Roaming, überlasteter Access-Point-Uplink. 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: Channel Utilization, Anzahl verbundener Clients, Retry-Rate, Datenraten, Airtime-Nutzung, Co-Channel Interference, Adjacent-Channel Interference, Störpegel, Kanalbreite, Lastverteilung zwischen Access Points, Nutzung von 2,4 GHz, 5 GHz oder 6 GHz, auffällige Roaming-Ereignisse. 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: CPU- und Speicherauslastung, Schnittstellenauslastung, Paketverluste, Session-Anzahl, NAT-Tabellen, VPN-Verschlüsselungsleistung, Deep Packet Inspection, Intrusion Prevention, Malware-Scan, TLS-Inspection, Webfilter, Proxy-Cache, Traffic Shaping, Bandbreitenlimits, Quality of Service, Lizenz- oder Plattformgrenzen. 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: Leistung ohne Tunnel im gleichen Ausgangsnetz, Round-Trip-Time zum VPN-Gateway, Auslastung des VPN-Gateways, verwendetes VPN-Protokoll, Verschlüsselungsleistung, Paketverlust auf dem äußeren Transportpfad, MTU und Tunnel-Overhead, Split-Tunneling oder Full-Tunneling, konkurrierender Verkehr am Client, Uploadgeschwindigkeit des Clientanschlusses, Rückweg zum Client. 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 -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 -f -l 1400 Linux: ping -M do -s 1472 Zu prüfen sind: MTU des Clients, MTU der beteiligten Tunnel, VPN-Overhead, PPPoE-Overhead, ICMP-Meldungen zur notwendigen Fragmentierung, Path MTU Discovery, MSS-Anpassung, große Pakete gegenüber kleinen Paketen. 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: Häufigkeit der Wiederholungen, Richtung der Wiederholungen, zeitlicher Zusammenhang mit Leistungseinbrüchen, TCP Zero Window, TCP Window Full, Out-of-Order-Segmente, Round-Trip-Time, Verbindungsabbrüche, Resets. 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: TCP-Verbindungsaufbau, Antwortzeiten, Wiederholungen, Zero Window, Resets, DNS-Verzögerungen, ICMP-Fehlermeldungen, Fragmentierung, lange Pausen zwischen Anfrage und Antwort. Beispielhafte Wireshark-Filter: ip.addr == && ip.addr == Nur TCP-Verkehr zwischen zwei Systemen: tcp && ip.addr == && ip.addr == 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: langsame DNS-Auflösung, verzögerter TLS-Verbindungsaufbau, langsame Authentifizierung, langsame Datenbankabfrage, überlasteter Webserver, blockierter Anwendungsthread, externer API-Aufruf, Virenscanner, Dateisperren, langsamer Datenträger, hohe CPU- oder Speicherauslastung. 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: CPU-Auslastung, Speicherdruck, Swap-Nutzung, Datenträgerlatenz, Warteschlangen des Storage, Netzwerkauslastung, Anzahl der Verbindungen, Anwendungslimits, Datenbankauslastung, Backup- oder Scanprozesse, Virtualisierungshost, gemeinsam verwendete Ressourcen. 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 iperf3 für den Netzwerkpfad, lokale Lese- und Schreibtests nach Betriebsvorgaben, Dateiübertragung aus dem Arbeitsspeicher, Vergleich mit einem anderen Datenträger, Server-Monitoring für Storage-Latenz und Warteschlangen. 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: Backups, Replikationen, Cloud-Synchronisation, Softwareverteilung, Virenscans, Datenbankwartung, Patchmanagement, Videoüberwachung, geplante Exporte, Benutzeranmeldungen am Arbeitsbeginn, große Downloads oder Uploads, Storage-Snapshots, WAN-Auslastung, Provider- oder Standortauslastung. 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: Ping-Latenz, Jitter, Paketverlust, iperf3 -Durchsatz, Linkauslastung, Fehlerzähler, WLAN-SNR, WLAN-Kanalauslastung, CPU-Auslastung, Storage-Latenz, Anwendungsantwortzeit, Anzahl aktiver Sitzungen. 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: ursprünglichen Zeitplan wiederherstellen, ursprüngliche Bandbreitenrichtlinie wiederherstellen, Konfiguration erneut prüfen, Änderung dokumentieren. Verifikation iperf3 -c 192.0.2.80 -t 30 Ergebnis: Durchschnittlicher Durchsatz: 928 Mbit/s Retransmissions: keine auffällige Zunahme Zusätzlich: Uplink unterhalb der vorgesehenen Auslastungsgrenze, keine neuen Output Drops, Dateiübertragung wieder im normalen Bereich, Anwendungen reagieren normal, Benutzer bestätigen die Wiederherstellung. 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: Switch oder Router ohne Diagnose neu starten, Geschwindigkeit oder Duplex nur auf einer Seite erzwingen, WLAN-Kanäle wahllos verändern, Access Points unkontrolliert neu starten, Firewall- oder Sicherheitsprüfung deaktivieren, VPN umgehen, Quality of Service vollständig entfernen, alle Traffic-Limits pauschal aufheben, MTU ohne Messung verändern, TCP-Einstellungen ohne Baseline ändern, Netzwerkkartentreiber ungeprüft ersetzen, Fehlerzähler vor der Dokumentation löschen, produktive Links mit unkontrolliertem iperf3 auslasten, UDP-Tests ohne Bandbreitenlimit starten, ausschließlich einen öffentlichen Speedtest verwenden, aus einem einzelnen Ping auf die Gesamtleistung schließen, mehrere Änderungen gleichzeitig durchführen. Solche Maßnahmen können Diagnoseinformationen beseitigen, Sicherheitsgrenzen verändern oder zusätzliche Störungen erzeugen. 30. Vollständige Schnellprüfreihenfolge genaue Anwendung und Benutzeraktion ermitteln. erwartete und tatsächliche Leistung dokumentieren. Beginn, Dauer und zeitliches Muster bestimmen. feststellen, ob ein oder mehrere Benutzer betroffen sind. WLAN und Ethernet getrennt betrachten. lokales und entferntes Ziel vergleichen. Upload und Download getrennt prüfen. tatsächlich verwendeten Netzwerkadapter feststellen. Linkgeschwindigkeit und Duplex prüfen. Fehler- und Verwerfungszähler dokumentieren. Gateway, lokales Ziel und entferntes Ziel anpingen. Latenz, Schwankung und Paketverlust vergleichen. tatsächlichen Netzwerkpfad ermitteln. Durchsatz mit einem autorisierten Testsystem messen. beide Übertragungsrichtungen prüfen. Netzwerkpfad in einzelne Segmente unterteilen. Access-Port, Uplink und Serverport prüfen. Auslastung und Warteschlangen untersuchen. WLAN-Signal, SNR, Kanal und Airtime prüfen. Firewall, Router, Proxy und VPN untersuchen. MTU und mögliche Fragmentierungsprobleme prüfen. TCP-Wiederholungen und Empfangsfenster untersuchen. Anwendung und Netzwerk getrennt testen. CPU, Arbeitsspeicher und Storage des Servers prüfen. geplante Backups, Scans und Synchronisationen berücksichtigen. Messwerte mit einer Baseline vergleichen. genau eine Hypothese formulieren. genau eine kontrollierte Änderung durchführen. ursprüngliche Messungen wiederholen. Nebenwirkungen und Sicherheitsfunktionen prüfen. temporäre Diagnoseänderungen entfernen. Ursache, Maßnahme, Rollback und Nachweis dokumentieren. 31. Checkliste „Netzwerk ist langsam“ subjektive Aussage wurde in Messwerte übersetzt. erwarteter Sollwert ist bekannt. tatsächlicher Istwert wurde dokumentiert. Beginn und zeitliches Muster sind bekannt. Anzahl betroffener Benutzer wurde bestimmt. betroffene Anwendungen wurden bestimmt. Upload und Download wurden getrennt geprüft. WLAN und Ethernet wurden verglichen. lokales und entferntes Ziel wurden verglichen. verwendeter Netzwerkadapter wurde bestätigt. zusätzliche Adapter und VPN-Verbindungen wurden berücksichtigt. Linkgeschwindigkeit wurde geprüft. Duplexmodus wurde geprüft. Clientfehlerzähler wurden dokumentiert. Switchportfehler wurden dokumentiert. CRC-/FCS-Fehler wurden geprüft. Discards und Drops wurden geprüft. Gateway-Latenz wurde gemessen. Latenz zum Ziel wurde gemessen. Paketverlust wurde gemessen. Schwankungen beziehungsweise Jitter wurden berücksichtigt. Netzwerkpfad wurde ermittelt. Durchsatz wurde kontrolliert gemessen. beide Übertragungsrichtungen wurden geprüft. einzelne Netzwerksegmente wurden verglichen. Access-Port wurde geprüft. Uplink wurde geprüft. Serverport wurde geprüft. Auslastung und Warteschlangen wurden geprüft. WLAN-Signal und SNR wurden geprüft. WLAN-Kanalauslastung wurde geprüft. WLAN-Airtime und Retry-Rate wurden berücksichtigt. Firewall und Router wurden geprüft. VPN und Proxy wurden berücksichtigt. Traffic Shaping und Policing wurden geprüft. Quality of Service wurde berücksichtigt. MTU und Fragmentierung wurden geprüft. TCP-Retransmissions wurden berücksichtigt. TCP Window Full und Zero Window wurden berücksichtigt. Server-CPU wurde geprüft. Serverarbeitsspeicher wurde geprüft. Storage-Latenz wurde geprüft. Anwendung wurde getrennt vom Netzwerk getestet. zeitabhängige Prozesse wurden untersucht. Baseline oder Vergleichsmessung wurde verwendet. vor Änderungen wurde der Ausgangszustand gesichert. nur eine kontrollierte Änderung wurde durchgeführt. Rollback wurde festgelegt. ursprüngliche Messungen wurden wiederholt. temporäre Diagnoseänderungen wurden entfernt. Ursache, Maßnahme und Nachweis wurden dokumentiert. 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 Microsoft Learn – Get-NetAdapterStatistics Microsoft Learn – Test-NetConnection Microsoft Learn – ping Microsoft Learn – tracert Microsoft Learn – pathping ESnet – iperf3 Documentation ESnet – Invoking iperf3 ESnet – iperf3 FAQ Cisco – Troubleshoot Switch Port and Interface Problems Cisco – Troubleshoot Interface CRC Errors Cisco – RF Health and Wireless Troubleshooting Cisco – RF Analysis Tools Wireshark – TCP Analysis Wireshark – TCP Display Filter Reference Wireshark – User’s Guide 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 Netzwerkverbindung fällt für wenige Sekunden aus. Anwendung reagiert gelegentlich nicht. Benutzer kann sich manchmal nicht anmelden. Server ist nur zu bestimmten Zeiten langsam. VPN-Verbindung wird unregelmäßig getrennt. WLAN-Verbindung verliert kurzzeitig den Access Point. DNS-Auflösung schlägt vereinzelt fehl. Dateiübertragung bricht gelegentlich ab. Dienst startet nach einem Fehler automatisch neu. Druckauftrag funktioniert erst beim zweiten Versuch. Datenbankverbindung läuft in einen Timeout. Fehler verschwindet nach erneutem Laden der Anwendung. Problem tritt nur an einzelnen Tagen oder Uhrzeiten auf. Überwachung zeigt kurze Spitzen, obwohl der Durchschnitt normal ist. 2. Mögliche Auswirkungen Arbeitsunterbrechungen, verlorene oder doppelt ausgeführte Vorgänge, beschädigte Dateiübertragungen, getrennte Sitzungen, fehlgeschlagene Sicherungen, unvollständige Synchronisation, verzögerte Geschäftsprozesse, schwer nachvollziehbare Benutzerbeschwerden, steigender Supportaufwand, falsche Ursachenzuordnung, unerkannt zunehmende Hardwarefehler, Sicherheits- oder Verfügbarkeitsrisiken. 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: IP-Adressen, Benutzernamen, Gerätenamen, DNS-Abfragen, Kommunikationsbeziehungen, Sitzungsinformationen, Anmeldedaten, Anwendungsinhalte, personenbezogene Daten, vertrauliche Unternehmensdaten. Vor einer erweiterten Protokollierung sind deshalb zu klären: betriebliche Freigabe, erforderlicher Umfang, Speicherort, Zugriffsschutz, Aufbewahrungsdauer, Datenschutz, anschließende Löschung, mögliche Systembelastung. 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: exakter Zeitpunkt, Dauer, betroffener Benutzer, betroffenes Gerät, verwendete Anwendung, ausgeführte Aktion, Zielsystem, angezeigte Fehlermeldung, Netzwerkverbindung, Standort, Häufigkeit, mögliche Auslöser, Zustand vor und nach dem Fehler. 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: aktuelle Uhrzeit, Zeitzone, NTP-Quelle, Synchronisationsstatus, Zeitabweichung, Sommer- oder Winterzeit, UTC gegenüber lokaler Zeit, Zeitstempel von Netzwerkgeräten, Zeitstempel von Containern und virtuellen Maschinen. 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: mehrmals täglich, einmal täglich, an bestimmten Wochentagen, nach einer bestimmten Laufzeit, nach einer Anmeldung, nach dem Standby, nach einem Neustart, während hoher Last, nach einem Netzwerkwechsel, bei Ablauf einer Sitzung, bei einem Backup, während eines Updates, bei Temperaturänderungen, nur an einem Standort, nur im WLAN, nur über VPN 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: Ist nur ein Benutzer betroffen? Sind mehrere Benutzer betroffen? Sind alle Benutzer eines Standorts betroffen? Ist nur eine Anwendung betroffen? Sind mehrere Dienste gleichzeitig betroffen? Ist nur ein Client betroffen? Sind alle Geräte an einem Switch betroffen? Sind ausschließlich WLAN-Clients betroffen? Sind nur VPN-Verbindungen betroffen? Ist nur eine Übertragungsrichtung betroffen? Ist nur ein bestimmter Server betroffen? 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: Erreichbarkeit, Antwortzeit, Paketverlust, DNS-Auflösung, TCP-Port-Erreichbarkeit, HTTP-Status, Anwendungsantwortzeit, CPU-Auslastung, Arbeitsspeicher, Storage-Latenz, Interfacezustand, Fehlerzähler, Dienststatus, Anzahl der Sitzungen, Temperatur, Spannungs- oder Stromereignisse. 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 -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 "" -Count 1 -Quiet "$timestamp | | 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 "" -Port 443 "$timestamp | TCP 443: $($result.TcpTestSucceeded)" | Out-File -FilePath ".\tcp-443.log" -Append Start-Sleep -Seconds 5 } Wichtig Testintervall an die erwartete Fehlerdauer anpassen. Speicherbedarf begrenzen. Logdateien regelmäßig kontrollieren. Messung nach Abschluss wieder beenden. Ein erfolgreicher Ping beweist nicht, dass die Anwendung funktioniert. Ein fehlgeschlagener Ping beweist nicht automatisch einen vollständigen Ausfall, da ICMP blockiert oder begrenzt werden kann. 11. Kontinuierliche Erreichbarkeit unter Linux oder macOS prüfen Linux: ping macOS: ping Mit Zeitstempeln unter Linux, sofern ping diese Option unterstützt: ping -D Alternativ kann eine kontrollierte Schleife verwendet werden: while true; do timestamp=$(date '+%Y-%m-%d %H:%M:%S') if ping -c 1 -W 2 >/dev/null 2>&1; then echo "$timestamp | | erreichbar" else echo "$timestamp | | 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: Treiberfehler, Netzwerkunterbrechungen, Dienstabbrüche, unerwartete Neustarts, Datenträgerfehler, DNS-Fehler, Authentifizierungsfehler, Zeitabweichungen, Ressourcenknappheit, Anwendungsabstürze, automatische Wiederherstellungen. 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 \ --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: Dienstneustarts, Kernelmeldungen, Link-Up- und Link-Down-Ereignisse, DHCP-Ereignisse, DNS-Fehler, Speicherfehler, Out-of-Memory-Ereignisse, Datenträger- und Dateisystemfehler, Authentifizierungsfehler, Containerneustarts, Prozessabbrüche. 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: Client, Server, Switch, Router, Firewall, Access Point, VPN-Gateway, DNS-Server, DHCP-Server, Verzeichnisdienst, Hypervisor, Containerplattform, Anwendung, Datenbank, Storage, Monitoring, Cloud- oder Providerdienst. Vorteile einer zentralen Protokollierung: gemeinsame Suche, einheitliche Aufbewahrung, Vergleich mehrerer Systeme, Alarmierung, Erkennung wiederkehrender Muster, Ereigniszeitleisten, langfristige Auswertung. 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: Messintervall, Aggregation, Durchschnitt gegenüber Maximum, kurzfristige Spitzen, Anzahl der Messwerte, Aufbewahrungsstufen, Alarmverzögerung, Alarmrücksetzung, fehlende Messwerte. 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 richtige Netzwerkschnittstelle auswählen, Sichtbarkeit des relevanten Verkehrs prüfen, Speicherbedarf begrenzen, Capture-Filter möglichst eng setzen, Systembelastung beobachten, Zeitpunkt des Fehlers sofort dokumentieren, betroffene Dateien vor dem Überschreiben sichern, Mitschnitt nach der Diagnose beenden, Dateien geschützt speichern und anschließend geregelt löschen. 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 link show 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 Zu prüfen sind: Link-Up- und Link-Down-Zeitpunkte, Anzahl der Statuswechsel, CRC- oder FCS-Fehler, Interface Resets, Kabel, Stecker, Switchport, Transceiver, Dockingstation, Netzwerkkartentreiber, Energiesparzustand, Power over Ethernet, Port-Security, Spanning Tree, Aushandlung von Geschwindigkeit und Duplex. Ein Link-Flap kann sehr kurz sein und zwischen zwei manuellen Prüfungen vollständig verschwinden. Protokolle und historische Zähler sind deshalb besonders wichtig. 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: CRC-/FCS-Fehler, Input Errors, Output Errors, Discards, Drops, Interface Resets, Kollisionen, Retransmissions, WLAN-Retries, Queue Drops, verlorene Pakete, Linkstatuswechsel. 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: DHCP aktiviert, Lease erhalten, Lease läuft ab, DHCP-Server, aktuelle IPv4- und IPv6-Adresse, Standardgateway, DNS-Server, unerwartete Adressänderung, APIPA-Adresse, doppelte IP-Adresse. 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 DNS-Cache anzeigen: ipconfig /displaydns Unter Linux oder macOS, sofern dig vorhanden ist: dig Wiederholte Abfrage: dig +noall +answer Zu prüfen sind: Antwortzeit, zurückgegebene IP-Adressen, TTL, mehrere DNS-Server, unterschiedliche Antworten, fehlgeschlagene Abfragen, kurze TTL, veraltete Einträge, fehlerhafte Weiterleitung, DNSSEC-Fehler, Suchdomänen, Split-DNS, Wechsel zwischen funktionierenden und fehlerhaften Zieladressen. 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: Sitzungs-Timeout, Idle-Timeout, Access-Token-Ablauf, Refresh-Token-Ablauf, Kerberos-Ticketlaufzeit, VPN-Sitzungslaufzeit, Firewall-Session-Timeout, Proxy-Timeout, Load-Balancer-Timeout, Datenbankverbindungs-Timeout, DHCP-Lease, DNS-TTL, Zertifikatsablauf, API-Ratenlimit, Sperrzeit einer Anwendung. 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: Zeitpunkt der Anmeldung, Zeitpunkt der letzten Aktivität, Zeitpunkt der Tokenausstellung, Ablaufzeit, Zeitpunkt des Fehlers, erfolgreiche oder fehlgeschlagene Erneuerung, Verhalten nach erneuter Anmeldung. 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 :443 \ -servername Nur Zertifikatsdaten ausgeben: openssl s_client \ -connect :443 \ -servername \ /dev/null | openssl x509 -noout -subject -issuer -dates Zu prüfen sind: Beginn der Gültigkeit, Ablaufdatum, vollständige Zertifikatskette, Hostname, Zwischenzertifikate, Systemzeit, unterschiedliche Zertifikate an mehreren Servern, Load-Balancer-Knoten, Proxy- oder TLS-Inspection, automatische Zertifikatserneuerung. 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: Backups, Datenbankwartung, Logrotation, Virenscans, Softwareverteilung, Patchmanagement, Replikation, Cloud-Synchronisation, Storage-Snapshots, Zertifikatserneuerung, Berichterstellung, Dateiimporte, Exporte, Neustarts, Container-Updates, automatische Skalierung, Indexierung. 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: Start- und Endzeit, CPU-Auslastung, Arbeitsspeicher, Storage-Latenz, Netzwerkauslastung, Warteschlangen, Anwendungsantwortzeit, Anzahl der Fehler, Verhalten ohne den geplanten Prozess. 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: CPU- und Gerätetemperatur, Lüfterdrehzahl, Überhitzungswarnungen, Netzteilstatus, redundante Netzteile, USV-Ereignisse, Spannungsschwankungen, PoE-Leistungsbudget, Stromausfälle, fehlerhafte Steckverbindungen, Temperatur im Serverschrank, Tageszeit und Umgebungstemperatur. 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: Signalstärke, Signal-Rausch-Abstand, Kanalauslastung, Retry-Rate, Roaming, Kanalwechsel, Radarerkennung bei DFS-Kanälen, Access-Point-Neustarts, Anzahl aktiver Clients, Airtime, fremde WLAN-Netze, Bluetooth- oder andere Funkquellen, Mikrowellengeräte, bauliche Hindernisse, bewegliche Störquellen, fehlerhafter AP-Uplink, PoE-Unterbrechungen. 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: Verlust zum Provider-Gateway, Latenzsprünge, Leitungsstatus, Modem- oder Routerprotokolle, WAN-Interface-Fehler, Neuverbindungen, öffentliche IP-Adresswechsel, PPPoE-Sitzungen, Mobilfunkqualität, Providerwartungen, BGP- oder Routingänderungen, VPN-Neuaufbau, Auslastung der Standortanbindung, beide Übertragungsrichtungen. 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. Uplink-Auslastung und Drops ↓ Paketverlust ↓ Server nicht erreichbar ↓ Anwendungs-Timeout 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: Welches Ereignis trat zuerst auf? Welche Systeme sind voneinander abhängig? Welches Ereignis erklärt die nachfolgenden Fehler? Welcher Messwert änderte sich bereits vor der Benutzermeldung? Welche Meldung beschreibt nur eine Folge? 31. Kontrollierte Reproduktion versuchen Wenn ein Muster erkannt wurde, kann eine kontrollierte Reproduktion möglich sein. Beispiele: gleiche Aktion wiederholen, gleiche Sitzungsdauer abwarten, denselben Netzwerkpfad verwenden, Last unter kontrollierten Bedingungen erzeugen, Test vor und während eines geplanten Prozesses durchführen, betroffenes und funktionierendes Gerät vergleichen, unterschiedliche Serverknoten gezielt prüfen, WLAN und Ethernet vergleichen. Dabei gelten folgende Regeln: nur autorisierte Tests durchführen, Ausgangszustand dokumentieren, erwartete Beobachtung festlegen, nur einen Einflussfaktor verändern, Messwerte während des Tests erfassen, Test bei unerwarteten Auswirkungen abbrechen, ursprünglichen Zustand wiederherstellen, 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: erwartetes Ereignis, betroffene Komponente, Messwert, Zeitfenster, mögliche Widerlegung. 33. Genau eine kontrollierte Änderung durchführen Nach ausreichender Eingrenzung wird nur eine Änderung vorgenommen. Mögliche kontrollierte Änderungen: defektes Kabel ersetzen, betroffenen Switchport wechseln, vorgesehenen Treiber aktualisieren, fehlerhaften Serverknoten aus dem Load Balancer nehmen, geplanten Prozess nach Freigabe verschieben, Sitzungs-Timeout abgestimmt korrigieren, fehlerhafte DNS-Antwort korrigieren, defekten Access Point ersetzen, vorgesehene Bandbreitensteuerung anpassen, fehlerhafte Stromversorgung austauschen. 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: ursprüngliche Konfiguration, ursprüngliche Version, ursprünglicher Zeitplan, ursprünglicher Port, ursprüngliche Verkabelung, Sicherung vorhandener Einstellungen, verantwortliche Person, erlaubtes Änderungsfenster, Abbruchkriterium, Rückweg. 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: ursprüngliche Symptome, technische Messwerte, Protokolle, Fehlerzähler, Nebenwirkungen, Sicherheitsfunktionen, abhängige Systeme, Benutzerbestätigung. 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 Access-Token, Sitzungs-Timeout, Refresh-Token, Load Balancer, Proxy, Anwendungssitzung, Authentifizierungsdienst. 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: System ohne Protokollsicherung neu starten, Fehler als „nicht reproduzierbar“ schließen, alle Protokolle pauschal löschen, Fehlerzähler vor der Dokumentation zurücksetzen, DNS-Cache vor der Bestandsaufnahme leeren, mehrere Komponenten gleichzeitig ersetzen, Monitoring unbegrenzt hochauflösend aktivieren, unbegrenzten Paketmitschnitt starten, Sicherheitsfunktionen deaktivieren, VPN oder Authentifizierung umgehen, Backups ohne Freigabe abschalten, Sitzungszeiten pauschal erhöhen, automatische Updates vollständig deaktivieren, WLAN-Kanäle wahllos verändern, Produktivsysteme unkontrolliert belasten, aus einem einzelnen Ereignis eine Ursache ableiten, nur auf die Aussage „jetzt funktioniert es“ vertrauen. Solche Maßnahmen können Beweise vernichten, neue Störungen verursachen oder Sicherheits- und Betriebsvorgaben verletzen. 40. Vollständige Prüfreihenfolge genaue Fehlermeldung und Benutzeraktion erfassen. exakten Zeitpunkt und Dauer dokumentieren. betroffenen Benutzer, Client und Standort bestimmen. betroffene Anwendung und Zielsysteme erfassen. prüfen, ob ein oder mehrere Benutzer betroffen sind. feste Uhrzeit von fester Laufzeit unterscheiden. Häufigkeit und wiederkehrendes Muster bestimmen. Zeitsynchronisation aller beteiligten Systeme prüfen. Monitoring- und Protokollaufbewahrung prüfen. kontinuierliche Messung mit Zeitstempeln einrichten. Gateway, internes Ziel und externes Ziel vergleichen. TCP-Port und Anwendungsantwort getrennt prüfen. Windows- oder Linux-Protokolle zeitlich filtern. Client-, Netzwerk- und Serverprotokolle vergleichen. Monitoringauflösung kontrolliert erhöhen. Schnittstellenstatus und Link-Flaps beobachten. Fehler- und Verwerfungszähler als Verlauf erfassen. WLAN-Ereignisse, Roaming und Retry-Rate prüfen. DHCP-Lease und mögliche Adresskonflikte untersuchen. DNS-Auflösung, TTL und unterschiedliche Antworten prüfen. Sitzungslaufzeiten, Token und Timeouts vergleichen. Zertifikatslaufzeiten und Serverknoten prüfen. geplante Aufgaben, Timer und Cronjobs untersuchen. Backups, Scans, Updates und Replikationen vergleichen. CPU, Arbeitsspeicher, Storage und Netzwerk überwachen. Temperatur, Stromversorgung und PoE berücksichtigen. WAN-, Provider- und VPN-Ereignisse prüfen. bei Bedarf autorisierten Ringpuffer-Mitschnitt einrichten. alle Ereignisse auf einer gemeinsamen Zeitleiste darstellen. zuerst auftretendes Ereignis von Folgefehlern unterscheiden. genau eine messbare Hypothese formulieren. kontrollierte Reproduktion planen. Ausgangszustand und Rollback dokumentieren. genau eine freigegebene Änderung durchführen. ursprüngliche Messungen wiederholen. ausreichend langen Beobachtungszeitraum einhalten. Nebenwirkungen und Sicherheitsfunktionen kontrollieren. temporäre Diagnosemaßnahmen entfernen. Ursache, Maßnahme, Rollback und Nachweis dokumentieren. 41. Checkliste „Fehler tritt nur manchmal auf“ genaue Fehlermeldung wurde dokumentiert. Benutzeraktion wurde beschrieben. exakter Zeitpunkt wurde erfasst. Dauer des Fehlers wurde erfasst. betroffener Benutzer wurde bestimmt. betroffener Client wurde bestimmt. Standort und Netzwerkverbindung wurden erfasst. Anwendung und Zielsystem wurden bestimmt. Anzahl der betroffenen Benutzer wurde geprüft. feste Uhrzeit und feste Laufzeit wurden unterschieden. Häufigkeit wurde dokumentiert. wiederkehrendes Muster wurde gesucht. Zeitzonen wurden berücksichtigt. Zeitsynchronisation wurde geprüft. kontinuierliche Messung wurde eingerichtet. Messungen enthalten Zeitstempel. Gateway wurde überwacht. internes Ziel wurde überwacht. externes Ziel wurde berücksichtigt. TCP-Port wurde getrennt geprüft. Anwendungsantwort wurde getrennt geprüft. Windows-Ereignisprotokolle wurden geprüft. Linux-Systemprotokolle wurden geprüft. Anwendungsprotokolle wurden geprüft. Netzwerkgeräteprotokolle wurden geprüft. Protokollaufbewahrung wurde geprüft. Monitoringauflösung wurde geprüft. kurzfristige Spitzen wurden berücksichtigt. Interface-Flapping wurde geprüft. Fehlerzähler wurden als Verlauf dokumentiert. CRC-/FCS-Fehler wurden berücksichtigt. Drops und Discards wurden berücksichtigt. DHCP-Lease wurde geprüft. IP-Adresskonflikte wurden berücksichtigt. DNS-Auflösung wurde wiederholt geprüft. DNS-TTL wurde berücksichtigt. unterschiedliche DNS-Antworten wurden verglichen. Sitzungs- und Idle-Timeouts wurden geprüft. Tokenlaufzeiten wurden geprüft. Zertifikatslaufzeiten wurden geprüft. alle Serverknoten wurden verglichen. geplante Aufgaben wurden geprüft. Backups und Replikationen wurden berücksichtigt. Virenscans und Updates wurden berücksichtigt. CPU- und Speicherauslastung wurden beobachtet. Storage-Latenz wurde beobachtet. WLAN-Roaming und Funkstörungen wurden berücksichtigt. Provider-, WAN- und VPN-Ereignisse wurden geprüft. Temperatur und Stromversorgung wurden berücksichtigt. erforderlicher Paketmitschnitt wurde autorisiert. Ringpuffer und Speichergrenze wurden festgelegt. gemeinsame Ereigniszeitleiste wurde erstellt. Ursache und Folge wurden unterschieden. genau eine Hypothese wurde formuliert. Ausgangszustand wurde dokumentiert. Rollback wurde festgelegt. nur eine kontrollierte Änderung wurde durchgeführt. ausreichend lange Verifikation wurde durchgeführt. Nebenwirkungen wurden geprüft. temporäre Diagnosemaßnahmen wurden entfernt. Ursache, Maßnahme und Nachweis wurden dokumentiert. 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 Microsoft Learn – Get-WinEvent Microsoft Learn – Test-Connection Microsoft Learn – Test-NetConnection Microsoft Learn – Get-NetAdapterStatistics Microsoft Learn – Resolve-DnsName Microsoft Learn – w32tm Microsoft Learn – netsh wlan Microsoft Learn – Get-ScheduledTask systemd – journalctl systemd – systemctl Wireshark – dumpcap Manual Page Wireshark – Capture Setup Wireshark – User’s Guide Cisco – Troubleshoot Port Flaps on Catalyst 9000 Series Switches Cisco – Troubleshoot Link Flap Issues on Nexus 9000 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: langsamem Client, langsamem Netzwerk, hoher Latenz, Paketverlust, geringer verfügbarer Bandbreite, ausgelastetem WLAN, langsamem VPN, überlastetem Server, hoher Storage-Latenz, blockierter Datenbank, langsamem DNS, fehlerhaftem Serverknoten, Anwendungs- oder Schnittstellenproblem. 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: genaue Benutzeraktion, betroffene Anwendung, betroffene Datei oder Funktion, Startzeitpunkt, Dauer, Häufigkeit, betroffene Benutzer, betroffene Clients, Standort, LAN, WLAN oder VPN, internes oder externes Ziel, erwartete Dauer, tatsächlich gemessene Dauer, Fehlermeldungen, durchgeführte Änderungen. 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 hohe CPU-Auslastung, unzureichender Arbeitsspeicher, langsamer Datenträger, Hintergrundprogramme, Virenscanner, fehlerhafter Netzwerktreiber, Energiesparmodus, Browsererweiterungen, lokaler DNS-Cache, defekte Netzwerkkarte. Netzwerk Paketverlust, hohe Latenz, Interface-Fehler, Duplex- oder Geschwindigkeitsproblem, ausgelasteter Uplink, Queue Drops, fehlerhaftes Kabel, überlastetes WLAN, Roaming, VPN-Überlastung, MTU-Problem, fehlerhaftes Routing, langsame Namensauflösung. Server hohe CPU-Auslastung, zu wenig Arbeitsspeicher, Paging oder Swapping, hohe Storage-Latenz, volle Datenträger, überlastete Netzwerkschnittstelle, zu viele gleichzeitige Sitzungen, blockierte Prozesse, Virenscan, Backup, Snapshot, überlasteter Hypervisor. Anwendung und Datenbank langsame Datenbankabfrage, fehlender Datenbankindex, Datenbanksperre, erschöpfter Verbindungspool, langsame API, externer Dienst, fehlerhafter Serverknoten, Anwendungsfehler, ungeeignete Zeitüberschreitung, große oder ineffiziente Abfrage, überlastete Hintergrundverarbeitung. 5. Zuerst den Umfang bestimmen Zu klären ist: Ist nur ein Benutzer betroffen? Sind mehrere Benutzer betroffen? Ist nur ein Standort betroffen? Sind nur WLAN-Benutzer betroffen? Sind auch kabelgebundene Clients betroffen? Ist nur eine Anwendung langsam? Sind mehrere Dienste desselben Servers betroffen? Sind interne und externe Ziele betroffen? Tritt das Problem zu einer bestimmten Uhrzeit auf? 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: gleicher Standort, gleiches Netzwerk, gleiche Anwendung, gleiche Berechtigung, gleiche Datenmenge, gleicher Server, ähnliche Hardware, möglichst gleicher Zeitpunkt. 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: Antwortzeit einer Anwendung, Laufzeit einer Datenbankabfrage, Ping-Latenz, Paketverlust, DNS-Antwortzeit, Dateidurchsatz, CPU-Auslastung, Speicherauslastung, Storage-Latenz, Anzahl gleichzeitiger Sitzungen, Fehlerrate, Warteschlangenlänge. 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: ip link show Statistiken: ip -s link show Zu prüfen sind: CPU-Spitzen, Speicherdruck, Paging oder Swapping, Datenträgerauslastung, Hintergrundprozesse, Synchronisationsprogramme, Virenscanner, Softwareupdates, Treiberstatus, ausgehandelte Verbindungsgeschwindigkeit, Interface-Fehler, Energiesparzustände. Ein ausgelasteter Client kann eine langsame Anwendung verursachen, obwohl Netzwerk und Server ordnungsgemäß arbeiten. 9. Latenz und Paketverlust messen Unter Windows: ping -t Beispiel: ping -t 192.0.2.10 Unter Linux oder macOS: ping 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 Unter Linux: traceroute Unter macOS: traceroute Falls vorhanden, kann eine fortlaufende Pfadanalyse durchgeführt werden: mtr Zu prüfen sind: auffällige Latenzsprünge, wechselnde Pfade, Paketverlust, Routingänderungen, Unterschiede zwischen betroffenen und funktionierenden Clients. 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 -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 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: DNS langsam: Namensauflösung untersuchen, TCP langsam: Netzwerkpfad oder Zielsystem prüfen, TLS langsam: Zertifikatsprüfung, Proxy oder Serverlast prüfen, erstes Byte langsam: Anwendung, Server oder Datenbank prüfen, Download nach dem ersten Byte langsam: Durchsatz oder Datenmenge prüfen. 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 } Einzelne DNS-Abfrage: Resolve-DnsName Unter Linux oder macOS, sofern dig vorhanden ist: dig Kurze Ausgabe: dig +stats Zu prüfen sind: Antwortzeit, verwendeter DNS-Server, unterschiedliche Antworten, Zeitüberschreitungen, fehlerhafte Weiterleitung, IPv4- und IPv6-Verhalten, Suchdomänen, Split-DNS, mehrere Zieladressen. 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 Messung in Gegenrichtung: iperf3 -c -R Mehrere parallele Verbindungen: iperf3 -c -P 4 UDP-Tests dürfen nur kontrolliert und mit begrenzter Bandbreite durchgeführt werden: iperf3 -c -u -b 10M Zu vergleichen sind: Senderichtung, Empfangsrichtung, LAN, WLAN, VPN, betroffener Client, Referenzclient, verschiedene Zeitpunkte. 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: langsamer Quelldatenträger, langsamer Zieldatenträger, Virenscanner, Dateisystem, Verschlüsselung, SMB- oder NFS-Konfiguration, viele kleine Dateien, Kompression, CPU-Auslastung, Netzwerkdurchsatz, Storage-Latenz. 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: CRC-/FCS-Fehler, Input Errors, Output Errors, Discards, Queue Drops, Interface Resets, Kollisionen, Link-Flaps, Geschwindigkeits- und Duplexaushandlung. 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: geringer Durchsatz, hohe Anzahl von Fehlern, Kollisionen, stark unterschiedliche Sende- und Empfangsleistung, Verbindung handelt nur 100 Mbit/s statt 1 Gbit/s aus. Zu prüfen sind: Clientadapter, Switchport, Kabelkategorie, Stecker, Dockingstation, Medienkonverter, Transceiver, automatische Aushandlung. 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: Signalstärke, Signal-Rausch-Abstand, Kanalauslastung, Retry-Rate, verwendetes Frequenzband, Kanalbreite, Anzahl aktiver Clients, Airtime, Roaming, Access-Point-Auslastung, DFS-Kanalwechsel, Störquellen, AP-Uplink, PoE-Versorgung. 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: hohe Internetlatenz, Paketverlust, überlastetes VPN-Gateway, Verschlüsselungslast, ungeeignete MTU, getunnelter Internetverkehr, langsamer DNS-Server, geografische Entfernung, WLAN-Probleme des Benutzers, Bandbreitenbegrenzung, Neuaufbau des Tunnels. 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: betrifft es alle VPN-Benutzer, betrifft es nur einen Internetanbieter, tritt es nur zu bestimmten Zeiten auf, ist nur eine Anwendung betroffen, sind Senden und Empfangen unterschiedlich langsam, steigt die CPU-Auslastung des VPN-Gateways, treten Tunnelabbrüche oder Neuverbindungen auf. VPN- oder Sicherheitsfunktionen dürfen nicht zur Diagnose umgangen werden. 20. Serverressourcen prüfen Wichtige Messwerte: CPU-Auslastung, CPU-Warteschlange, Arbeitsspeicher, Paging oder Swapping, Datenträgerauslastung, Storage-Latenz, freie Speicherkapazität, Netzwerkauslastung, aktive Sitzungen, Prozessanzahl, Container- oder VM-Grenzen, Hypervisor-Auslastung. 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: Gesamtauslastung, Auslastung einzelner Kerne, Prozess mit hoher CPU-Nutzung, Laufzeit der hohen Last, Warteschlangen, virtuelle CPU-Zuteilung, CPU-Limits von Containern, Steal Time bei virtuellen Systemen, thermische Drosselung. 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: verfügbarer Arbeitsspeicher, Paging oder Swapping, Speicherdruck, Speicherwachstum eines Prozesses, Out-of-Memory-Ereignisse, Container- oder VM-Limits, wiederholte Prozessabbrüche. 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: Lese- und Schreiblatenz, Warteschlangentiefe, IOPS, Durchsatz, freie Kapazität, Dateisystem, RAID-Zustand, Controllerzustand, Cache, SAN- oder NAS-Verbindung, Snapshots, Replikation, Backup, Virenscan, Thin Provisioning, Storage-Überbelegung. 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: langsame Abfrage, fehlender Index, Datenbanksperre, Deadlock, zu viele gleichzeitige Verbindungen, erschöpfter Verbindungspool, hohe Storage-Latenz, Statistik- oder Wartungsproblem, große Ergebnismenge, ungeeigneter Ausführungsplan, Replikationsverzögerung. Zu vergleichen sind: Dauer der Benutzeranfrage, Dauer der zugehörigen Datenbankabfrage, Wartezeiten, Sperren, Anzahl aktiver Verbindungen, CPU- und Storage-Auslastung, Zeitpunkt von Wartungsaufgaben, Verhalten vergleichbarer Abfragen. 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: Antwortzeit jeder Abhängigkeit, externe APIs, Authentifizierungsdienst, Verzeichnisdienst, DNS, Proxy, Nachrichtenwarteschlange, Datenbank, Storage, Cache, Rate Limits, Zeitüberschreitungen. 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: andere Konfiguration, fehlerhafte Softwareversion, hohe CPU-Auslastung, langsames Storage, fehlerhaftes Zertifikat, fehlende Verbindung zur Datenbank, defekter Cache, Hintergrundprozess, ungleiche Lastverteilung. 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: Backup, Snapshot, Replikation, Virenscan, Softwareverteilung, Update, Datenimport, Export, Berichterstellung, Indexierung, Datenbankwartung, Logrotation, Cloud-Synchronisation. 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: TCP-Retransmissions, Verbindungsabbrüche, verzögerte Bestätigungen, DNS-Zeitüberschreitungen, lange Pausen zwischen Anfrage und Antwort, wiederholte Verbindungsaufbauten, TCP-Zero-Window-Ereignisse, TLS-Verbindungsaufbau, unterschiedliche Serverziele. 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: Mitschnitt autorisieren lassen, richtige Schnittstelle auswählen, Capture-Filter begrenzen, Speicherbedarf begrenzen, Datenschutz berücksichtigen, Zeitpunkt des Problems dokumentieren, Mitschnitt nach der Diagnose beenden, Dateien geschützt speichern, Dateien anschließend geregelt löschen. 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: Paketverlust, fehlerhaftes Kabel, WLAN-Störungen, überlastete Warteschlangen, WAN-Probleme, fehlerhafter Netzwerkadapter, MTU-Problem, überlastetes Zielsystem. 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: konkrete Komponente, erwarteten Messwert, erwartete Veränderung, Zeitfenster, Möglichkeit der Widerlegung. 33. Kontrollierte Änderung durchführen Erst nach ausreichender Eingrenzung wird genau eine Änderung vorgenommen. Mögliche Änderungen: defektes Kabel ersetzen, vorgesehenen Treiber aktualisieren, fehlerhaften Switchport wechseln, ungeeignete Sicherungszeit verschieben, fehlerhaften Serverknoten aus der Verteilung nehmen, abgestimmte Bandbreitensteuerung einrichten, Datenbankabfrage optimieren, fehlenden Index nach Prüfung ergänzen, Ressourcenlimit korrigieren, defekten Datenträger oder Access Point ersetzen. 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: ursprüngliche Konfiguration, ursprüngliche Version, Ausgangsmesswerte, verantwortliche Person, Änderungsfenster, erwartete Wirkung, Abbruchkriterium, Rückweg. 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: ursprüngliche Benutzeraktion, Antwortzeit, Latenz, Paketverlust, Durchsatz, Fehlerzähler, CPU-Auslastung, Arbeitsspeicher, Storage-Latenz, Datenbankwartezeit, Protokolle, Nebenwirkungen, Verhalten abhängiger Systeme. 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: Server ohne vorherige Messung neu starten, Netzwerkgerät wahllos neu starten, DNS-Cache vor der Bestandsaufnahme löschen, alle Netzwerkadapter zurücksetzen, mehrere Kabel und Ports gleichzeitig wechseln, Sicherheitssoftware ohne Freigabe deaktivieren, VPN umgehen, Firewallregeln pauschal ändern, WLAN-Kanäle wahllos wechseln, unbegrenzten Paketmitschnitt starten, produktives Netzwerk unkontrolliert auslasten, Datenbankabfragen ungeprüft verändern, Serverressourcen ohne Messwerte erhöhen, Zeitüberschreitungen pauschal verlängern, aus einem einzelnen Ping eine Ursache ableiten, hohe Bandbreite mit hoher Anwendungsleistung gleichsetzen. Solche Maßnahmen können Beweise vernichten, neue Fehler verursachen oder die eigentliche Ursache verdecken. 40. Vollständige Prüfreihenfolge genaue Benutzeraktion erfassen. erwartete und tatsächliche Dauer dokumentieren. Startzeitpunkt, Häufigkeit und Dauer bestimmen. betroffene Benutzer, Clients und Standorte erfassen. LAN, WLAN und VPN unterscheiden. einzelne Anwendung und allgemeines Systemverhalten vergleichen. betroffenen Client mit Referenzclient vergleichen. normalen Leistungsbereich als Baseline bestimmen. lokale CPU-, Speicher- und Datenträgerauslastung prüfen. Verbindungsgeschwindigkeit und Adapterstatus prüfen. Gateway, internes Ziel und externes Ziel messen. Latenz und Paketverlust getrennt betrachten. Netzwerkpfad untersuchen. TCP-Port prüfen. DNS-Antwortzeit messen. Anwendungsantwort in einzelne Zeitanteile zerlegen. kontrollierten Durchsatztest durchführen. Interface-Fehler, Drops und Retransmissions prüfen. WLAN-Auslastung und Retry-Rate berücksichtigen. VPN-Pfad und VPN-Gateway prüfen. Server-CPU und Arbeitsspeicher überwachen. Paging, Swapping und Ressourcenlimits prüfen. Storage-Latenz und Warteschlangen untersuchen. Datenbankabfragen, Sperren und Verbindungen prüfen. APIs und externe Abhängigkeiten untersuchen. alle Serverknoten einzeln vergleichen. geplante Aufgaben und Hintergrundprozesse prüfen. Messwerte auf einer gemeinsamen Zeitleiste darstellen. größten Zeitanteil bestimmen. Ursache und Folge unterscheiden. genau eine messbare Hypothese formulieren. Ausgangszustand und Rollback dokumentieren. genau eine freigegebene Änderung durchführen. ursprüngliche Messung wiederholen. ausreichend lange Verifikation durchführen. Nebenwirkungen kontrollieren. temporäre Diagnosemaßnahmen entfernen. Ursache, Maßnahme und Nachweis dokumentieren. 41. Checkliste „Netzwerk oder Anwendung ist langsam“ genaue Benutzeraktion wurde dokumentiert. erwartete Dauer wurde erfasst. tatsächliche Dauer wurde gemessen. Zeitpunkt und Häufigkeit wurden dokumentiert. betroffene Benutzer wurden bestimmt. betroffene Clients wurden bestimmt. betroffene Standorte wurden bestimmt. LAN, WLAN und VPN wurden unterschieden. interner und externer Zugriff wurden verglichen. betroffener Client wurde mit einer Referenz verglichen. Baseline wurde bestimmt. lokale CPU-Auslastung wurde geprüft. lokaler Arbeitsspeicher wurde geprüft. lokaler Datenträger wurde geprüft. Hintergrundprozesse wurden geprüft. Verbindungsgeschwindigkeit wurde geprüft. Adapterstatistiken wurden geprüft. Gateway-Latenz wurde gemessen. Server-Latenz wurde gemessen. Paketverlust wurde geprüft. Netzwerkpfad wurde untersucht. TCP-Port wurde geprüft. DNS-Antwortzeit wurde gemessen. Zeit bis zum ersten Byte wurde gemessen. tatsächlicher Durchsatz wurde geprüft. beide Übertragungsrichtungen wurden berücksichtigt. Interface-Fehler wurden geprüft. Drops und Discards wurden geprüft. TCP-Retransmissions wurden berücksichtigt. WLAN-Kanalauslastung wurde geprüft. WLAN-Retry-Rate wurde geprüft. VPN-Verbindung wurde berücksichtigt. Server-CPU wurde überwacht. Serverarbeitsspeicher wurde überwacht. Paging oder Swapping wurde geprüft. Storage-Latenz wurde gemessen. Datenträgerwarteschlangen wurden berücksichtigt. Datenbankabfragen wurden geprüft. Datenbanksperren wurden berücksichtigt. APIs und externe Abhängigkeiten wurden geprüft. alle Serverknoten wurden verglichen. Backups und Snapshots wurden berücksichtigt. Virenscans und Updates wurden berücksichtigt. gemeinsame Zeitleiste wurde erstellt. größter Zeitanteil wurde bestimmt. Ursache und Folge wurden unterschieden. messbare Hypothese wurde formuliert. Ausgangszustand wurde dokumentiert. Rollback wurde festgelegt. nur eine kontrollierte Änderung wurde durchgeführt. Messungen wurden anschließend wiederholt. ausreichend lange Verifikation wurde durchgeführt. Nebenwirkungen wurden geprüft. Ursache und Nachweis wurden dokumentiert. 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 Microsoft Learn – Test-Connection Microsoft Learn – Test-NetConnection Microsoft Learn – Get-NetAdapter Microsoft Learn – Get-NetAdapterStatistics Microsoft Learn – Resolve-DnsName Microsoft Learn – netsh wlan Microsoft Learn – Windows Performance Monitor curl – Write-Out Variables iperf3 – Documentation Wireshark – User’s Guide Wireshark – TCP Analysis Wireshark – dumpcap Manual Page systemd – journalctl 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: CPU-Auslastung, Arbeitsspeichermangel, Paging oder Swapping, langsamer Datenträger, hohe Datenträgerlatenz, Netzwerkprobleme, überlastete Anwendung, Datenbanksperren, Hintergrundjobs, Hypervisor-Engpässe, externe Abhängigkeiten. „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: Ist der gesamte Server langsam oder nur eine Anwendung? Sind alle Benutzer betroffen? Tritt das Problem lokal und über das Netzwerk auf? Sind nur bestimmte Funktionen betroffen? Besteht das Problem dauerhaft oder nur zu bestimmten Zeiten? Trat das Problem nach einer Änderung auf? Sind weitere Server betroffen? Gibt es ein funktionierendes Vergleichssystem? Wie wird die Verzögerung gemessen? Welche Antwortzeit gilt als normal? 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: Ist ein geschäftskritischer Dienst betroffen? Können Benutzer noch eingeschränkt arbeiten? Sind Datenverlust oder Folgefehler möglich? Betrifft das Problem einen oder mehrere Standorte? Verschlechtert sich der Zustand weiter? Gibt es ein funktionierendes Ersatzsystem? Besteht eine vereinbarte Reaktions- oder Wiederherstellungszeit? 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: genaue Uhrzeit mit Zeitzone, CPU-Auslastung, CPU-Auslastung pro Prozess, Arbeitsspeicherbelegung, Paging- oder Swap-Aktivität, Datenträgerauslastung, Datenträgerlatenz, Warteschlangen, Netzwerkfehler, aktive Verbindungen, Prozess- und Dienststatus, Eventlogs oder Journal, Anwendungslogs, Datenbankstatus, Hypervisorwerte, laufende Jobs, letzte Änderungen. 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. Zeitpunkt und Umfang der Störung bestimmen. CPU, RAM, Datenträger und Netzwerk gleichzeitig betrachten. Prozesse mit ungewöhnlicher Ressourcennutzung ermitteln. Backups, Virenscans, Snapshots und Wartungsjobs prüfen. Betriebssystem-, Anwendungs- und Hypervisorlogs zeitlich vergleichen. Antwortzeit vom Client und direkt auf dem Server messen. Mit einem funktionierenden Vergleichssystem vergleichen. 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: gesamte CPU-Auslastung, Auslastung einzelner Kerne, Auslastung pro Prozess und Thread, Dauer der Auslastung, System- und Benutzerzeit, Interrupts, virtuelle CPU-Bereitstellung, CPU-Wartezeiten des Hypervisors, CPU-Limits oder Drosselung. 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: verfügbarer Arbeitsspeicher, Auslagerungsaktivität, Speicherdruck, Arbeitsspeicher pro Prozess, Page Faults, Kernel- oder Pool-Speicher, zeitliche Entwicklung, Speicherlimits einer VM oder eines Containers. 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: Datenträgerlatenz, Lese- und Schreibraten, Warteschlangenlänge, IOPS, freier Speicherplatz, Dateisystemfehler, RAID-Zustand, SAN- oder NAS-Verbindung, Snapshot-Aktivität, Backup-Aktivität, Storage-Überbelegung, Zustand physischer Datenträger. 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: Paketverlust, Latenz, Schwankungen der Latenz, DNS-Auflösung, Duplex- oder Geschwindigkeitsfehler, Interfacefehler, Überlastung, VPN, Firewall, Proxy, Load Balancer, Routing, MTU-Probleme, viele oder erschöpfte Verbindungen. 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: langsame Anmeldung, verzögerte Verbindungen, Authentifizierungsprobleme, lange Wartezeiten beim Zugriff auf andere Server, langsame Datenbankverbindungen, Verzögerungen bei Reverse-Lookups. 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: korrekte DNS-Server, Antwortzeit, Forward- und Reverse-Auflösung, fehlerhafte oder veraltete Einträge, Suchdomänen, Erreichbarkeit der DNS-Server, unnötige Abfragen an externe DNS-Server. 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: ungewöhnlich hohe CPU- oder Speichernutzung, häufige Dienstneustarts, Prozesse im Warte- oder Blockierungszustand, sehr viele Threads, sehr viele offene Dateien, abgestürzte Unterprozesse, lange Warteschlangen, Ressourcenlimits, fehlerhafte Abhängigkeiten. 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: fehlerhafte Konfiguration, zu wenige Worker oder Threads, zu kleine Verbindungspools, blockierte Warteschlangen, langsame Datenbankabfragen, nicht erreichbare externe Dienste, Authentifizierungsprobleme, Cachefehler, unzureichende Ressourcenlimits, fehlerhaftes Update, wachsendes Log- oder temporäres Verzeichnis. Zu prüfen sind: Antwortzeit einzelner Funktionen, Anwendungslogs, Fehler- und Zeitüberschreitungen, Anzahl aktiver Sitzungen, Thread- oder Worker-Auslastung, Warteschlangenlänge, Cachetreffer, Verbindungspools, interne Gesundheitsprüfungen, Abhängigkeiten. 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: blockierende Transaktionen, Deadlocks, fehlende oder ungeeignete Indizes, langsame Abfragen, überlastetes Storage, zu wenig Arbeitsspeicher, zu viele Verbindungen, fehlerhafte Ausführungspläne, veraltete Statistiken, lange offene Transaktionen, Replikationsprobleme. Zu prüfen sind: Abfragelaufzeiten, aktive Verbindungen, blockierte Sitzungen, Locks und Deadlocks, langsame Abfrageprotokolle, Cache- und Speichernutzung, Storage-Latenz, Replikationsverzögerung, Anzahl wartender Transaktionen. 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: Datensicherung, Virenscan, Patchinstallation, Datenbankwartung, Protokollrotation, Indexerstellung, Synchronisation, Replikation, Berichtserstellung, Snapshot, Datenimport oder Datenexport. 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: Startzeit des Jobs, Beginn der Verlangsamung, CPU-Auslastung, I/O-Auslastung, Netzwerkverkehr, Ende des Jobs, Rückkehr zum Normalzustand. 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: Datenträgerfehler, Netzwerkfehler, Treiberprobleme, Dienstabbrüche, Zeitüberschreitungen, Speicherfehler, OOM-Ereignisse, Authentifizierungsfehler, Datenbankfehler, wiederholte Neustarts, Hardwarewarnungen. 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: vCPU-Auslastung, Arbeitsspeicher, Paging oder Swapping, virtuelle Datenträger, Netzwerkschnittstelle, Betriebssystemlogs, installierte Integrationstreiber. Auf dem Hypervisor zu prüfen: CPU-Auslastung des Hosts, CPU-Wartezeit, Speicherüberbelegung, Ballooning oder Swapping, Storage-Latenz, Netzwerküberlastung, Limits und Reservierungen, Snapshots, Zustand anderer VMs. 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: CPU-Limit, Arbeitsspeicherlimit, Neustartzähler, Containerlogs, Dateisystem, Storage-Treiber, Netzwerk, Zustand des Containerhosts, gemeinsam genutzte Ressourcen. 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: Datenbankserver, DNS-Server, Active Directory, Dateiserver, API, Cloud-Dienst, Authentifizierungsdienst, Mailserver, Proxy, Lizenzserver, Netzwerkspeicher. Zu prüfen sind: Erreichbarkeit, Namensauflösung, Portverbindung, Antwortzeit, Zertifikate, Authentifizierung, Zeitüberschreitungen, Rate Limits, Statusmeldungen des Dienstanbieters. 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: überhitzte CPU, thermische Drosselung, fehlerhafter Arbeitsspeicher, degradierter RAID-Verbund, defekter Datenträger, fehlerhafte Netzwerkkarte, instabiles Netzteil, Firmware- oder Treiberproblem. Zu prüfen sind: Hardwaremanagement wie iLO, iDRAC oder vergleichbare Systeme, Temperaturwerte, Lüfterstatus, RAID-Controller, SMART-Werte, Hardwareereignisse, Firmwarestand, Treiberstand, Herstellerdiagnose. 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: Betriebssystemupdate, Anwendungsupdate, Treiberupdate, neue Sicherheitssoftware, geänderte Richtlinie, zusätzliche Benutzer, Datenwachstum, neue VM, geändertes Backupfenster, neue Datenbankabfrage, geänderte Ressourcenlimits, Netzwerkanpassung. 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: typische CPU-Auslastung, typischer Arbeitsspeicherbedarf, normale Datenträgerlatenz, normale Netzwerklatenz, typische Benutzeranzahl, typische Antwortzeit, übliche Anzahl von Verbindungen, normale Auslastung zu bestimmten Tageszeiten. 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: Die hohe CPU-Auslastung verursacht die Verzögerung. Die langsame externe Abhängigkeit führt zu zusätzlichen Wiederholungen und erhöht dadurch die CPU-Auslastung. Ein dritter Prozess verursacht gleichzeitig beide Effekte. Die CPU-Auslastung ist normal und nicht relevant. Ein Ursachennachweis wird stärker, wenn: der Zeitpunkt übereinstimmt, die technische Wirkung plausibel ist, das Verhalten reproduzierbar ist, eine gezielte Maßnahme den Messwert und das Symptom verändert, alternative Ursachen ausgeschlossen wurden. 23. Kontrollierte Maßnahmen durchführen Nach der Analyse sollte genau eine passende Maßnahme durchgeführt werden. Mögliche Maßnahmen: störenden Hintergrundjob pausieren, fehlerhaften Prozess kontrolliert neu starten, Anwendung auf einen zweiten Knoten umleiten, Ressourcenlimit korrigieren, fehlerhafte Änderung zurücknehmen, freien Speicherplatz schaffen, Storage- oder Netzwerkproblem eskalieren, Datenbankblockierung durch die zuständige Stelle auflösen. Vor jeder Maßnahme: Ausgangszustand sichern, Auswirkung bestimmen, Freigabe prüfen, Rückweg festlegen, betroffene Benutzer informieren, Messkriterien bestimmen. Danach: dieselben Messwerte erneut erfassen, Antwortzeit erneut messen, Protokolle prüfen, Nebenwirkungen ausschließen, Ergebnis dokumentieren. 24. Warum ein Neustart nicht die erste Maßnahme sein sollte Ein Neustart kann: blockierte Prozesse beenden, Arbeitsspeicher freigeben, Warteschlangen zurücksetzen, Verbindungen neu aufbauen, ein Symptom vorübergehend beseitigen. Er kann aber auch: wichtige Fehlerzustände vernichten, Protokollzusammenhänge erschweren, eine eigentliche Ursache verbergen, ungeplante Ausfallzeit verursachen, Daten oder Transaktionen gefährden, das Problem später erneut auftreten lassen. Ein Neustart ist daher keine vollständige Ursachenanalyse. Falls ein Neustart erforderlich ist, sollten vorher mindestens folgende Informationen gesichert werden: Prozessliste, Ressourcenauslastung, aktive Verbindungen, relevante Protokolle, laufende Aufgaben, Zeitpunkt und Symptom, Wiederanlaufplan, Rückfalloption. 25. Nachkontrolle Nach einer Maßnahme muss nicht nur die Ressourcenauslastung, sondern auch die eigentliche Funktion geprüft werden. Zu kontrollieren sind: Antwortzeit des betroffenen Dienstes, CPU-Auslastung, Arbeitsspeicher, Paging oder Swap, Datenträgerlatenz, Netzwerkfehler, Dienststatus, Anwendungslogs, Datenbankstatus, Benutzerfunktion, Zustand abhängiger Systeme. 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: betroffener Server, betroffener Dienst, Beginn und Ende, Sollzustand, Istzustand, betroffene Benutzer, gemessene Werte, relevante Protokolle, identifizierte Ursache, durchgeführte Maßnahme, Rückweg, Ergebnis der Nachkontrolle, Nebenwirkungen, vorbeugende Maßnahme, verantwortliche Stelle. 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 „Server langsam“ nicht genauer eingrenzen. einen einzelnen hohen Messwert sofort als Ursache bewerten. nur CPU und Arbeitsspeicher prüfen. Datenträgerlatenz nicht berücksichtigen. belegten Arbeitsspeicher automatisch mit Speichermangel gleichsetzen. Ping als vollständigen Diensttest ansehen. DNS nicht prüfen. Anwendung und Server nicht voneinander trennen. externe Abhängigkeiten übersehen. nur den Gast und nicht den Hypervisor untersuchen. Containerlimits nicht berücksichtigen. Hintergrundjobs nicht mit dem Störungszeitpunkt vergleichen. Protokolle ohne genaue Uhrzeit untersuchen. mehrere Maßnahmen gleichzeitig durchführen. sofort neu starten. Zustand vor der Maßnahme nicht sichern. nach der Maßnahme nicht erneut messen. technische Messwerte prüfen, aber die Benutzerfunktion nicht testen. zeitliche Korrelation automatisch als Ursache bewerten. das funktionierende Vergleichssystem nicht nutzen. keine vorbeugende Maßnahme dokumentieren. 31. Checkliste „Server ist langsam“ betroffener Server wurde eindeutig bestimmt. betroffener Dienst wurde bestimmt. Sollzustand wurde dokumentiert. Istzustand wurde gemessen. Beginn und Häufigkeit wurden dokumentiert. betroffene Benutzer und Standorte wurden bestimmt. lokaler und entfernter Zugriff wurden verglichen. funktionierendes Vergleichssystem wurde geprüft. letzte Änderungen wurden ermittelt. Ausgangszustand wurde gesichert. CPU-Gesamtauslastung wurde geprüft. einzelne CPU-Kerne wurden berücksichtigt. CPU-Auslastung pro Prozess wurde geprüft. Arbeitsspeicher wurde geprüft. Paging oder Swapping wurde geprüft. Prozesse mit hoher Speichernutzung wurden ermittelt. freier Speicherplatz wurde geprüft. Datenträgerlatenz wurde geprüft. Datenträgerwarteschlange wurde geprüft. RAID- oder Storage-Zustand wurde berücksichtigt. Netzwerkverbindung wurde geprüft. Paketverlust und Latenz wurden geprüft. Netzwerkfehlerzähler wurden geprüft. DNS-Auflösung wurde geprüft. Anwendungsport wurde geprüft. aktive Verbindungen wurden geprüft. Dienste und Prozesse wurden geprüft. Anwendungslogs wurden geprüft. Betriebssystemlogs wurden geprüft. Datenbankzustand wurde geprüft. Datenbanksperren wurden berücksichtigt. externe Abhängigkeiten wurden geprüft. Backups und Wartungsjobs wurden geprüft. Virenscans wurden berücksichtigt. Hypervisorwerte wurden geprüft. VM- oder Containerlimits wurden geprüft. Hardwarezustand wurde berücksichtigt. Messwerte wurden zeitlich korreliert. genau eine kontrollierte Maßnahme wurde durchgeführt. Rückweg wurde festgelegt. dieselben Messwerte wurden anschließend erneut erfasst. fachliche Funktion wurde praktisch getestet. Nebenwirkungen wurden ausgeschlossen. Ursache, Maßnahme und Ergebnis wurden dokumentiert. vorbeugende Maßnahme wurde festgelegt. 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 Microsoft Learn – Windows Performance Monitor Microsoft Learn – Get-Counter Microsoft Learn – Get-Process Microsoft Learn – Get-WinEvent Microsoft Learn – Test-NetConnection Microsoft Learn – Resolve-DnsName Microsoft Learn – Get-NetAdapterStatistics Red Hat – Viewing system processes Red Hat – Monitoring performance with Performance Co-Pilot Docker Docs – Runtime metrics Docker Docs – Resource constraints 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: Der Server antwortet auf ping , aber die Webseite öffnet sich nicht. Die IP-Adresse ist erreichbar, aber die Anwendung meldet einen Timeout. Der TCP-Port ist erreichbar, aber die Anmeldung schlägt fehl. Der Dienst funktioniert lokal auf dem Server, jedoch nicht von einem Client. Die Anwendung funktioniert ohne VPN, aber nicht über den VPN-Tunnel. Einige Benutzer können zugreifen, andere nicht. IPv4 funktioniert, IPv6 jedoch nicht. Der Reverse Proxy antwortet, erreicht aber das Backend nicht. Die Anwendung zeigt 502 Bad Gateway oder 503 Service Unavailable . Die Startseite funktioniert, ein bestimmter Geschäftsprozess jedoch nicht. Ein Healthcheck ist erfolgreich, während Benutzerfunktionen fehlschlagen. Die Diagnose muss deshalb über ICMP hinausgehen und den tatsächlichen Anwendungsweg prüfen. 7.9.2 Diagnoseziel Ziel ist es, eindeutig festzustellen: welches Ziel die Anwendung tatsächlich verwendet; welche IP-Adresse verwendet wird; ob IPv4 oder IPv6 verwendet wird; welches Transportprotokoll erforderlich ist; welcher Port angesprochen wird; ob der Zielport erreichbar ist; ob auf dem Server ein passender Prozess lauscht; ob der Dienst an der richtigen Adresse gebunden ist; ob TLS und Zertifikatsprüfung funktionieren; ob ein Proxy, Reverse Proxy oder Load Balancer beteiligt ist; ob Authentifizierung und Autorisierung funktionieren; ob alle Backendabhängigkeiten verfügbar sind; an welcher Stelle die vollständige Kommunikationskette unterbrochen wird. 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: Anwendungskonfiguration Namensauflösung Auswahl von IPv4 oder IPv6 lokales Routing VPN oder Proxy Clientfirewall Netzwerkfirewall oder ACL NAT oder Portweiterleitung Load Balancer oder Reverse Proxy TCP- oder UDP-Kommunikation TLS-Handshake Anwendungsprotokoll Authentifizierung Autorisierung Backenddienste vollständiger Benutzerablauf Ein Fehler auf einer späteren Ebene kann auftreten, obwohl alle vorherigen Ebenen funktionieren. Beispiele: Ping funktioniert, aber TCP 443 wird blockiert. TCP 443 funktioniert, aber der TLS-Handshake schlägt fehl. TLS funktioniert, aber der HTTP-Pfad ist falsch. HTTP funktioniert, aber die Anmeldung wird verweigert. Die Anmeldung funktioniert, aber die Datenbank ist nicht erreichbar. Der Healthcheck funktioniert, aber der eigentliche Geschäftsprozess schlägt fehl. 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: der verwendete Zielname konnte für diesen Aufruf aufgelöst werden, sofern ein Name angegeben wurde; eine Zieladresse wurde ausgewählt; der Client konnte ein ICMP-Echo-Paket absenden; das Paket erreichte ein antwortendes System; eine ICMP-Echo-Antwort erreichte den Client; der ICMP-Hin- und Rückweg funktionierte für diese Paketgröße und diesen Zeitpunkt. Ping kann zusätzlich Hinweise liefern auf: Antwortzeit; Paketverlust; wechselnde Antwortzeiten; ausgewählte IPv4- oder IPv6-Adresse; grobe Erreichbarkeit eines Systems. 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: dass ein bestimmter TCP-Port geöffnet ist; dass ein UDP-Dienst funktioniert; dass der erwartete Prozess läuft; dass der Dienst an der richtigen Adresse lauscht; dass TLS funktioniert; dass das Zertifikat gültig ist; dass der richtige virtuelle Host ausgewählt wird; dass ein Reverse Proxy das Backend erreicht; dass ein Load Balancer ein gesundes Backend besitzt; dass ein Proxy die Verbindung zulässt; dass eine Anmeldung möglich ist; dass der Benutzer ausreichend berechtigt ist; dass Datenbank, API oder Verzeichnisdienst verfügbar sind; dass größere Pakete oder Datenübertragungen funktionieren; dass die eigentliche Anwendung dieselbe IP-Adresse wie Ping verwendet; dass der vollständige Benutzerablauf funktioniert. 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: Ist nur ein Benutzer betroffen? Ist nur ein Client betroffen? Ist nur ein Betriebssystem betroffen? Ist nur ein Standort oder VLAN betroffen? Tritt der Fehler nur über VPN auf? Tritt der Fehler nur bei WLAN oder nur bei LAN auf? Sind alle Benutzer betroffen? Funktioniert die Anwendung intern, aber nicht extern? Funktioniert sie über IPv4, aber nicht über IPv6? Betrifft der Fehler nur einen bestimmten Funktionsbereich? Tritt der Fehler dauerhaft oder nur zeitweise auf? Seit welchem Zeitpunkt besteht der Fehler? Welche Änderung erfolgte unmittelbar davor? 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: genaue Fehlermeldung; Screenshot oder vollständiger Fehlertext; Zeitpunkt einschließlich Zeitzone; betroffener Benutzer; betroffener Client; verwendetes Netzwerk; verwendeter Servername; verwendete Zieladresse; Port und Protokoll; URL oder Ressourcenpfad; Proxy- und VPN-Zustand; relevante Clientprotokolle; relevante Serverprotokolle; Reverse-Proxy- oder Load-Balancer-Protokolle; Dienststatus; Listener und Bindungsadresse; letzte Änderungen; Vergleich mit einem funktionierenden Client. Ein vorschneller Neustart kann flüchtige Hinweise beseitigen, beispielsweise: bestehende Verbindungen; Fehlerzustände; temporäre Protokolle; Speicherauslastung; Portbelegung; Prozesszustand; Warteschlangen; reproduzierbare Zeitüberschreitungen. Ä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: explizit eingetragener Servername; vollständige URL; abweichender Port; Hosts-Datei; DNS-Suffix; Suchdomäne; Service-Discovery; Umgebungsvariable; Proxykonfiguration; PAC-Datei; Reverse Proxy; Load Balancer; lokale Anwendungskonfiguration; gespeicherte Sitzung oder zwischengespeicherte Adresse; IPv4- oder IPv6-Verwendung; mandanten-, standort- oder benutzerabhängige Konfiguration; Umleitungen innerhalb der Anwendung. Besonders wichtig: Ein Ping auf den Servernamen kann eine andere Adresse verwenden als die Anwendung. Ein Proxy kann die eigentliche Verbindung stellvertretend aufbauen. Ein Load Balancer kann mehrere Backendserver verwenden. Ein Browser kann einen anderen Resolver oder einen eigenen Proxyweg verwenden. Eine Anwendung kann eine alte Adresse zwischengespeichert haben. Ein direkter Aufruf per IP-Adresse verändert bei HTTPS möglicherweise SNI, Hostname und Zertifikatsprüfung. 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 -Type A Resolve-DnsName -Name -Type AAAA Linux: getent ahosts dig A dig AAAA macOS: dscacheutil -q host -a name dig A dig AAAA Zu vergleichen sind: die von der Anwendung verwendete Adresse; die von ping angezeigte Adresse; die von curl -v verwendete Adresse; A- und AAAA-Antworten; die Antworten verschiedener DNS-Server; interne und öffentliche DNS-Antworten; das Verhalten mit und ohne VPN. 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 ` -Port ` -InformationLevel Detailed Wichtige Felder: ComputerName RemoteAddress RemotePort InterfaceAlias SourceAddress TcpTestSucceeded Linux und macOS: nc -vz Ein erfolgreicher TCP-Test beweist: der verwendete Name wurde aufgelöst; der Client konnte die verwendete Adresse erreichen; der TCP-Verbindungsaufbau zum angegebenen Port wurde abgeschlossen. Er beweist nicht: dass auf dem Port der erwartete Dienst läuft; dass TLS funktioniert; dass die Anwendung eine gültige Antwort liefert; dass eine Anmeldung möglich ist; dass der vollständige Geschäftsprozess funktioniert. 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 @ 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://:/" Die Ausgabe wird schrittweise ausgewertet: Welche IP-Adresse wird verwendet? Wird eine TCP-Verbindung aufgebaut? Beginnt der TLS-Handshake? Welches Zertifikat wird präsentiert? Wird die Zertifikatsprüfung erfolgreich abgeschlossen? Welche HTTP-Anfrage wird gesendet? Welcher HTTP-Statuscode wird empfangen? Erfolgt eine Umleitung? Antwortet ein Reverse Proxy oder der erwartete Anwendungsserver? 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 :: \ "https://:/" 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: mehreren A- oder AAAA-Adressen; Load Balancern; geplanten DNS-Änderungen; einem einzelnen verdächtigen Backend; dem Vergleich alter und neuer Zieladressen. 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 \ -verify_hostname \ -verify_return_error Zu prüfen sind: wird überhaupt eine TCP-Verbindung aufgebaut? beginnt der TLS-Handshake? wird der richtige Servername per SNI verwendet? stimmt der Zertifikatsname mit dem Servernamen überein? ist die Zertifikatskette vollständig? vertraut der verwendete Client der ausstellenden Zertifizierungsstelle? sind Zertifikat und Zwischenzertifikate gültig? wird eine gemeinsame TLS-Version beziehungsweise Cipher Suite gefunden? verlangt der Server ein Clientzertifikat? 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: eigene Proxyeinstellung der Anwendung; Browser- oder Benutzerproxy; PAC-Datei; Proxy-Bypassliste; Proxy-Authentifizierung; Abweichung zwischen WinHTTP und benutzerbezogenen Einstellungen; unterschiedliche Regeln für interne und externe Namen; VPN-abhängige Proxykonfiguration. 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 ` -State Listen | Select-Object LocalAddress, LocalPort, State, OwningProcess Zugehörigen Prozess prüfen: Get-Process -Id Linux: sudo ss -lntp macOS: sudo lsof -nP \ -iTCP: \ -sTCP:LISTEN Zu prüfen sind: richtiger Port; erwarteter Prozess; lokale Bindungsadresse; IPv4- oder IPv6-Bindung; Dienststatus; mehrere konkurrierende Prozesse; unerwartete Portänderung. 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:/" Bei einem namensabhängigen HTTPS-Dienst: curl -v \ --resolve ::127.0.0.1 \ "https://:/" 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: lokale Firewall auf dem Client; Hostfirewall auf dem Server; Netzwerkfirewall zwischen den Systemen; VLAN- oder Segment-ACL; VPN-Regel; NAT- oder Portweiterleitung; Security Group oder Cloud-Firewall; Load-Balancer-Listener; Load-Balancer-Healthcheck; Reverse-Proxy-Route; Quellnetz- oder benutzerabhängige Regel; Rückweg vom Server zum Client. Mögliche Konstellationen: ICMP ist erlaubt, TCP 443 wird verworfen. TCP 443 erreicht den Load Balancer, aber kein Backend ist gesund. Der Reverse Proxy besitzt keinen passenden virtuellen Host. Eine NAT-Regel leitet auf den falschen internen Port weiter. Eine Firewall erlaubt nur bestimmte Quellnetze. Der Hinweg funktioniert, der Rückweg verwendet eine falsche Route. Ein Hostname verweist noch auf eine alte virtuelle IP-Adresse. 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: Authentifizierung: Ist die angegebene Identität gültig? Autorisierung: Darf diese Identität die gewünschte Ressource verwenden? Anwendungszustand: Ist Konto, Mandant oder Lizenz in der Anwendung aktiv? Verzeichnisdienst: Kann die Anwendung LDAP, Active Directory oder einen Identitätsanbieter erreichen? Sitzung: Sind Cookie, Token oder Ticket gültig? Zeit: Sind Client, Server und Identitätsdienst ausreichend synchronisiert? 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: Datenbank; Verzeichnisdienst; DNS; API; Dateifreigabe; Objektspeicher; Nachrichtenwarteschlange; Cache; Lizenzserver; Identitätsanbieter; externer Cloud-Dienst; anderer Container oder interner Dienst. Typische Befunde: Reverse Proxy antwortet mit 502 Bad Gateway . Anwendung antwortet mit 503 Service Unavailable . Anmeldung bleibt hängen, weil der Identitätsdienst nicht erreichbar ist. Startseite funktioniert, Datenabfrage schlägt jedoch fehl. Healthcheck ist erfolgreich, Geschäftsprozess scheitert. Dienst nimmt TCP-Verbindungen an, besitzt aber keine freien Worker. Datenträger oder Dateisystem ist voll. Container ist erreichbar, aber eine interne Abhängigkeit fehlt. 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 ` -Server DNS-Test unter Linux oder macOS: dig @ A Ein fehlender UDP-Fehler beweist nicht, dass: der Port geöffnet ist; der Dienst läuft; die Anfrage den Server erreicht hat; der Server eine gültige Antwort senden kann; der Rückweg funktioniert. 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://:/" curl -6 -v \ "https://:/" Zu prüfen sind: besitzt der Name A- und AAAA-Einträge? welche Adresse verwendet die fehlerhafte Anwendung? ist der Dienst an IPv4 und IPv6 gebunden? besitzen beide Protokolle einen funktionierenden Rückweg? gelten für IPv4 und IPv6 unterschiedliche Firewallregeln? funktioniert der Proxy oder Load Balancer mit beiden Adressfamilien? wird eine veraltete oder nicht erreichbare IPv6-Adresse veröffentlicht? 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: fehlerhafte Path-MTU-Ermittlung; blockierte erforderliche ICMP-Fehlermeldungen; Fragmentierungsproblem; Paketverlust; fehlerhafter VPN-Tunnel; Überlastung; asymmetrischer Pfad; fehlerhafte Netzwerkhardware. Typische Hinweise: TCP-Verbindung wird aufgebaut, aber TLS bleibt während des Handshakes hängen. Kleine Webseiten funktionieren, Downloads brechen ab. Anwendung funktioniert ohne VPN, aber nicht über den Tunnel. Wiederholte TCP-Übertragungen sind im Paketmitschnitt sichtbar. Fehler tritt erst ab einer bestimmten Datenmenge auf. 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 \ host and 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 Fehler aufnehmen Anwendung, Benutzer, Client, Zeitpunkt, Meldung und ursprüngliche Benutzerfunktion dokumentieren. Umfang bestimmen Einen Benutzer, einen Client, ein Netz oder alle Benutzer unterscheiden. Exaktes Ziel bestimmen Servername, Adresse, Port, Protokoll, Pfad und Verbindungsweg erfassen. Namensauflösung prüfen A- und AAAA-Antworten sowie tatsächlich verwendete Adresse vergleichen. Ping korrekt bewerten Nur ICMP-Erreichbarkeit als bestätigt betrachten. Transportprotokoll bestimmen TCP und UDP unterscheiden. TCP-Port oder UDP-Anwendung prüfen Einen zum tatsächlichen Protokoll passenden Test verwenden. Listener kontrollieren Port, Prozess und Bindungsadresse auf dem Server prüfen. Lokalen Anwendungstest durchführen Dienst auf dem Server über den vorgesehenen Namen, Port und Pfad testen. Externen Anwendungstest durchführen Denselben Dienst vom betroffenen Client aus prüfen. TLS untersuchen SNI, Zertifikat, Vertrauenskette und Protokollkompatibilität prüfen. Proxy und VPN berücksichtigen Tatsächlichen Verbindungsweg der Anwendung nachvollziehen. Anwendungsantwort auswerten Statuscode, Protokollmeldung, Umleitung oder Authentifizierungsfehler bestimmen. Abhängigkeiten prüfen Datenbank, Identitätsdienst, API, Speicher oder andere Backends untersuchen. Protokolle korrelieren Client-, Server-, Proxy- und Anwendungsprotokolle auf denselben Zeitraum begrenzen. Bei Bedarf Paketverlauf erfassen SYN, RST, TLS-Alert, Wiederholungen und Rückweg untersuchen. Hypothese formulieren Erwartetes Prüfergebnis und möglichen Gegenbeweis festlegen. Eine kontrollierte Änderung durchführen Risiko, Rückweg und Erfolgskriterium dokumentieren. Vollständige Funktion prüfen Nicht nur Ping oder Port, sondern den ursprünglichen Benutzerablauf testen. 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: Servername wird in die erwartete Adresse aufgelöst; richtige IPv4- oder IPv6-Adresse wird verwendet; vorgesehener TCP- oder UDP-Dienst ist erreichbar; richtiger Prozess lauscht auf dem vorgesehenen Port; TLS-Handshake und Zertifikatsprüfung funktionieren; Anwendung liefert die erwartete Protokollantwort; Anmeldung funktioniert; benötigte Ressource kann geöffnet werden; vollständiger ursprünglicher Benutzerablauf funktioniert; Frontend und Backend arbeiten zusammen; Test funktioniert aus dem betroffenen Netz; bei größerem Umfang funktionieren mehrere repräsentative Clients; keine neuen Fehler erscheinen in Client-, Server- oder Proxyprotokollen; temporäre Freigaben oder Diagnoseänderungen wurden zurückgenommen; Firewall und Zertifikatsprüfung sind weiterhin aktiv; Überwachung prüft nicht nur Ping, sondern auch die Anwendungsfunktion; keine andere Anwendung wurde durch die Änderung beeinträchtigt. Ein erfolgreicher Ping oder Porttest allein ist keine ausreichende Verifikation. 7.9.31 Präventionsmaßnahmen Anwendungserreichbarkeit zusätzlich zu ICMP überwachen; TCP-Port, TLS und einen geeigneten Anwendungsendpunkt prüfen; kritische Geschäftsprozesse mit synthetischen Funktionstests überwachen; Servername, Port, Protokoll und Abhängigkeiten dokumentieren; DNS-Änderungen mit TTL und Rückweg planen; Zertifikatsablauf und vollständige Zertifikatskette überwachen; Proxy-, VPN- und Firewallregeln dokumentieren; Load-Balancer-Healthchecks an die tatsächliche Dienstfunktion anpassen; Listenerbindungen und Portzuordnungen dokumentieren; IPv4 und IPv6 getrennt überwachen; Kapazitätsgrenzen für Worker, Verbindungen, CPU, Speicher und Datenträger überwachen; Frontend- und Backendprotokolle zeitlich synchronisieren; Änderungen an DNS, Firewall, Proxy und Anwendung nachvollziehbar protokollieren; Wiederherstellungs- und Rückfallverfahren testen; Monitoring nicht auf „Host ist pingbar“ beschränken. 7.9.32 Typische Fehler bei der Diagnose Einen erfolgreichen Ping mit einer funktionierenden Anwendung gleichsetzen. Einen Ping als Test eines TCP- oder UDP-Ports interpretieren. Einen anderen Port als den tatsächlich konfigurierten Port testen. Die IP-Adresse statt des vorgesehenen HTTPS-Namens aufrufen. SNI, Host-Header und Zertifikatsnamen ignorieren. curl für einen nicht unterstützten oder nicht HTTP-basierten Dienst verwenden. Einen allgemeinen UDP-Test als sicheren Funktionsnachweis betrachten. Einen Timeout automatisch als Firewallfehler einstufen. Connection refused und Timeout gleichsetzen. Nur einen lokalen Test auf dem Server durchführen. Nur prüfen, ob der Prozess läuft, statt den Listener zu kontrollieren. Nur prüfen, ob der Port offen ist, statt das Anwendungsprotokoll zu testen. Eine HTTP-Antwort automatisch als vollständigen Anwendungserfolg werten. Einen Healthcheck mit dem eigentlichen Geschäftsprozess gleichsetzen. Proxy, VPN, Load Balancer oder Reverse Proxy ignorieren. IPv4 und IPv6 nicht getrennt prüfen. Firewalls vollständig deaktivieren. Zertifikatsprüfungen dauerhaft umgehen. Vor der Protokollsicherung Dienste oder Server neu starten. Zugangsdaten, Token oder vollständige Debugausgaben ungeschützt weitergeben. Nach einer Änderung nur erneut pingen und die ursprüngliche Benutzerfunktion nicht testen. 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 ursprüngliche Benutzerfunktion dokumentiert genaue Fehlermeldung und Fehlerzeitpunkt erfasst betroffene Benutzer und Clients bestimmt vollständiger Servername erfasst verwendete Zieladresse bestätigt TCP oder UDP bestimmt richtiger Port bestimmt Protokoll und URL-Pfad bestimmt Ping nur als ICMP-Test bewertet A- und AAAA-Auflösung geprüft tatsächlich verwendete Adresse kontrolliert TCP-Port oder UDP-Anwendung geprüft Listener und zugehöriger Prozess geprüft Bindungsadresse kontrolliert lokaler Anwendungstest durchgeführt entfernter Anwendungstest durchgeführt TLS und Zertifikat geprüft Proxy- und VPN-Weg geprüft Firewall, ACL und Rückweg berücksichtigt Load Balancer oder Reverse Proxy geprüft Anwendungsantwort und Statuscode ausgewertet Authentifizierung und Autorisierung unterschieden Backendabhängigkeiten geprüft IPv4 und IPv6 getrennt getestet Client-, Server- und Proxyprotokolle korreliert Paketmitschnitt nur bei Bedarf und berechtigt erstellt Hypothese und Gegenbeweis formuliert Risiko und Rückweg vor Änderung dokumentiert nur eine kontrollierte Änderung durchgeführt vollständiger Benutzerablauf verifiziert temporäre Diagnoseänderungen zurückgenommen Ergebnis und Präventionsmaßnahme dokumentiert 7.9.35 Schnellreferenz Aufgabe Windows Linux macOS Ping ping ping -c 4 ping -c 4 Namensauflösung Resolve-DnsName getent ahosts dscacheutil -q host -a name A-Eintrag Resolve-DnsName -Type A dig A dig A AAAA-Eintrag Resolve-DnsName -Type AAAA dig AAAA dig AAAA TCP-Port Test-NetConnection -Port nc -vz nc -vz HTTP oder HTTPS curl.exe -v curl -v curl -v IPv4 mit curl curl.exe -4 -v curl -4 -v curl -4 -v IPv6 mit curl curl.exe -6 -v curl -6 -v curl -6 -v bestimmte Ziel-IP curl.exe --resolve :: curl --resolve :: curl --resolve :: 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 RFC 792 – Internet Control Message Protocol RFC 9293 – Transmission Control Protocol RFC 9110 – HTTP Semantics RFC 8446 – The Transport Layer Security Protocol Version 1.3 RFC 1191 – Path MTU Discovery für IPv4 RFC 8201 – Path MTU Discovery für IPv6 IANA – HTTP Status Code Registry Offizielle Hersteller- und Projektdokumentation Microsoft Learn – Test-NetConnection Microsoft Learn – Resolve-DnsName Microsoft Learn – Get-NetTCPConnection Microsoft Learn – netsh winhttp curl – offizielle Befehlsreferenz Everything curl – Verbose output OpenSSL – openssl s_client OpenBSD – nc(1) 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: eine falsche Anmeldeidentität; falsche oder veraltete Anmeldeinformationen; ein gesperrtes, deaktiviertes oder abgelaufenes Benutzerkonto; eine fehlende Netzwerk- oder VPN-Verbindung; eine fehlerhafte DNS-Konfiguration; eine fehlgeschlagene Domänencontroller-Ermittlung; einen nicht erreichbaren Domänencontroller; eine zu große Zeitabweichung; einen Kerberos- oder NTLM-Fehler; einen beschädigten sicheren Kanal des Computers; eine fehlerhafte Active-Directory-Replikation; eine Anmelde-, Sicherheits- oder Zugriffsrichtlinie; eine Smartcard-, Zertifikats- oder Windows-Hello-Abhängigkeit; den Benutzerprofildienst, eine Gruppenrichtlinie oder ein Anmeldeskript; eine RDP-, NLA- oder Remotedesktop-Besonderheit; eine standort-, RODC- oder vertrauensstellungsabhängige Konfiguration. 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 \MaxMustermann Active-Directory-Domänenkonto \MaxMustermann Active-Directory-UPN max.mustermann@ 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: Der Benutzer wählt den richtigen Anmeldeanbieter. Windows ordnet den eingegebenen Namen dem vorgesehenen Konto zu. Der Computer besitzt eine geeignete Netzwerkverbindung. Der Client verwendet die vorgesehenen DNS-Server. DNS liefert die erforderlichen Domänen- und Dienstinformationen. DC Locator ermittelt einen geeigneten Domänencontroller. Die benötigten Netzwerkprotokolle erreichen den Domänencontroller. Client und Domänencontroller besitzen ausreichend synchronisierte Uhrzeiten. Der Computer besitzt eine gültige Vertrauensbeziehung zur Domäne. Kerberos, NTLM oder das vorgesehene zertifikatsbasierte Verfahren beginnt. Der Domänencontroller prüft das Benutzerkonto und die Anmeldeinformationen. Kontorichtlinien und Anmelderechte werden ausgewertet. Windows erzeugt die Anmeldesitzung und das Zugriffstoken. Benutzerprofil, Gruppenrichtlinien und Anmeldeskripte werden verarbeitet. 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: exakter Wortlaut der Fehlermeldung; Datum und Uhrzeit des Versuchs; betroffener Benutzer; betroffener Computer; Anmeldeart: lokal, Konsole, RDP, VPN, Smartcard, PIN oder Kennwort; eingegebenes Namensformat; aktueller Standort und Netzwerkweg; Verbindung mit oder ohne VPN; letzter erfolgreicher Anmeldezeitpunkt; Umfang des Fehlers; kürzlich erfolgte Kennwort-, Computer-, DNS-, VPN- oder Richtlinienänderungen; verwendeter oder erwarteter Domänencontroller; relevante Ereignisse auf Client und Domänencontroller. 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: welcher Benutzer angezeigt wird; welche Domäne oder welcher Computername unter dem Benutzer steht; ob „Anderer Benutzer“ gewählt wurde; ob Kennwort, PIN, Smartcard oder ein anderer Anmeldeanbieter aktiv ist; ob das richtige Tastaturlayout verwendet wird; ob Feststelltaste oder Num-Taste den eingegebenen Wert verändert; ob ein alter Benutzername automatisch vorausgefüllt wurde; ob ein lokales Konto statt des Domänenkontos gewählt wurde; ob ein UPN oder der DOMÄNE\Benutzer -Name erforderlich ist. Beispiele: \MaxMustermann max.mustermann@ .\MaxMustermann Bedeutung: \MaxMustermann erzwingt die Zuordnung zur angegebenen AD-Domäne. max.mustermann@ verwendet den Benutzerprinzipalnamen. .\MaxMustermann bezeichnet ein lokales Konto des Computers. 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: whoami beschreibt die bereits bestehende Sitzung. $env:LOGONSERVER zeigt den Anmeldeserver dieser Sitzung, nicht zwingend den DC, den ein neuer Versuch verwenden würde. Eine alte Sitzung kann weiter funktionieren, obwohl eine neue Anmeldung fehlschlägt. Eine Anmeldung aus dem lokalen Cache kann ohne aktuelle DC-Authentifizierung entstanden sein. Gruppenmitgliedschaften im bestehenden Zugriffstoken können veraltet sein. 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 : Zusätzlich: systeminfo Relevante Felder sind: Domäne Anmeldeserver Zu prüfen sind: ist der Computer tatsächlich Domänenmitglied? gehört er zur erwarteten Domäne? wurde er versehentlich in eine Arbeitsgruppe verschoben? wurde ein altes Systemabbild oder ein VM-Snapshot wiederhergestellt? existiert ein anderer Computer mit demselben Namen? wurde das Computerkonto gelöscht, zurückgesetzt oder neu angelegt? wurde das Gerät geklont, ohne die Identität ordnungsgemäß vorzubereiten? 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: dass ein Domänencontroller erreichbar war; dass das Konto aktuell aktiviert ist; dass das Konto aktuell nicht gesperrt ist; dass das aktuelle Domänenkennwort verwendet wurde; dass Kerberos-Tickets ausgestellt wurden; dass Netzwerkressourcen erreichbar sind; dass Gruppenmitgliedschaften aktuell sind. 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: aktive Schnittstelle; IPv4- und IPv6-Adresse; Präfix beziehungsweise Subnetzmaske; Standardgateway; DNS-Server; DHCP-Status; DNS-Suffix; VPN-Adapter; mehrere gleichzeitig aktive Verbindungen; APIPA-Adresse aus 169.254.0.0/16 ; unerwartete öffentliche oder private DNS-Server. 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 -Type A Domänencontroller-Dienst prüfen: Resolve-DnsName ` -Name _ldap._tcp.dc._msdcs. ` -Type SRV Kerberos-Dienst prüfen: Resolve-DnsName ` -Name _kerberos._tcp. ` -Type SRV Einen bestimmten DNS-Server verwenden: Resolve-DnsName ` -Name _ldap._tcp.dc._msdcs. ` -Type SRV ` -Server Zu prüfen sind: antwortet der vorgesehene interne DNS-Server? existieren die benötigten SRV-Einträge? verweisen die SRV-Einträge auf vorhandene Domänencontroller? lassen sich die zurückgegebenen DC-Namen in gültige Adressen auflösen? werden alte oder außer Betrieb genommene DCs geliefert? erhält der Client über VPN andere DNS-Server? verwendet eine zweite Netzwerkschnittstelle ungeeignete DNS-Server? stimmt das DNS-Suffix? sind IPv4- und IPv6-Antworten erreichbar? unterscheiden sich die Antworten verschiedener DNS-Server? Ö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: Erneute DNS-basierte Ermittlung ohne den bisherigen DC-Cache: nltest /dsgetdc: /force Nur einen beschreibbaren DC anfordern: nltest /dsgetdc: /writable /force Lokalen AD-Standort anzeigen: nltest /dsgetsite Bekannte Domänencontroller auflisten: nltest /dclist: 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 -Port 53 Test-NetConnection -ComputerName -Port 88 Test-NetConnection -ComputerName -Port 135 Test-NetConnection -ComputerName -Port 389 Test-NetConnection -ComputerName -Port 445 Je nach Funktion zusätzlich: Test-NetConnection -ComputerName -Port 464 Test-NetConnection -ComputerName -Port 3268 Test-NetConnection -ComputerName -Port 636 Test-NetConnection -ComputerName -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: Test-NetConnection prüft hier nur TCP. Ein erfolgreicher Test auf TCP 53 beweist keine funktionierende DNS-Kommunikation über UDP. Ein erfolgreicher Test auf TCP 88 beweist keine vollständige Kerberos-Authentifizierung. Ein erfolgreicher Test auf TCP 135 beweist nicht, dass der anschließend ausgehandelte dynamische RPC-Port erreichbar ist. Nicht jede Umgebung benötigt bei jedem Anmeldevorgang alle aufgeführten optionalen Ports. Ein allgemeiner UDP-Porttest liefert keinen eindeutigen Funktionsnachweis. Die Freigabe einzelner Ports ohne Kenntnis des vollständigen AD-Verbindungswegs kann unvollständig sein. 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: /dataonly /samples:5 Zusätzlich zu prüfen: Get-Service W32Time Zu vergleichen sind: Datum; Uhrzeit; Zeitzone; Zeitquelle; letzter erfolgreicher Synchronisierungszeitpunkt; Zeitabweichung zum verwendeten DC; Zustand des Windows-Zeitdienstes; Hypervisor- oder VM-Zeitsynchronisation; Zeitquellen der Domänencontroller; PDC-Emulator und externe Zeitquelle. 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 "" ` -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 "" Gezielte Suchbefehle: Search-ADAccount -LockedOut -UsersOnly Search-ADAccount -AccountDisabled -UsersOnly Search-ADAccount -AccountExpired -UsersOnly Search-ADAccount -PasswordExpired -UsersOnly Alternativ mit integrierten Werkzeugen: net user /domain Zu prüfen sind: existiert das Konto? wird der richtige UPN verwendet? ist das Konto aktiviert? ist das Konto gesperrt? ist das Konto abgelaufen? ist das Kennwort abgelaufen? wurde das Kennwort kürzlich geändert oder zurückgesetzt? darf sich das Konto nur an bestimmten Arbeitsstationen anmelden? gelten eingeschränkte Anmeldezeiten? gilt eine fein abgestufte Kennwortrichtlinie? besitzt das Konto besondere Authentifizierungsanforderungen? stammt der angezeigte Zustand vom gleichen DC, der den Fehler verarbeitet hat? 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: falscher Benutzer oder falsche Domäne; falsches Tastaturlayout; Feststelltaste oder Num-Taste; Kennwort wurde kürzlich geändert; alter zwischengespeicherter Anmeldenachweis; Kennwortänderung wurde noch nicht vollständig repliziert; gespeicherte alte Anmeldeinformationen; Konto wurde gesperrt; Kennwort ist abgelaufen; Benutzer muss das Kennwort bei der nächsten Anmeldung ändern; Kennwortänderungsdienst oder DC ist nicht erreichbar; Smartcard- oder Windows-Hello-Anbieter wurde statt Kennwort gewählt. 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 "" ` -Verbose Status des zuletzt verwendeten Netlogon-Kanals anzeigen: nltest /sc_query: Wichtige Einschränkungen: Test-ComputerSecureChannel ist für Domänenmitgliedscomputer geeignet. Auf Domänencontrollern kann das Cmdlet falsch-negative Ergebnisse liefern. nltest /sc_query meldet den Zustand der letzten Verwendung und ist kein vollständiger neuer Funktionstest. nltest /sc_verify ist kein rein lesender Test: Wenn der Kanal nicht funktioniert, kann der Befehl den Kanal entfernen und neu aufbauen. nltest /sc_reset , nltest /sc_change_pwd , Reset-ComputerMachinePassword und Test-ComputerSecureChannel -Repair verändern den Zustand. Eine Reparatur darf erst nach Prüfung von DNS, Netzwerk, Zeit, DC-Zustand und Computerkonto erfolgen. Mögliche Ursachen eines defekten sicheren Kanals: Wiederherstellung eines alten VM-Snapshots; Zurückspielen eines veralteten Systemabbilds; doppelter Computername; gelöschtes oder zurückgesetztes Computerkonto; Neuinstallation mit wiederverwendetem Computernamen; nicht ordnungsgemäß geklonter Rechner; nicht übereinstimmendes Computerkennwort; AD-Replikationsfehler; längere Netzwerk- oder DC-Probleme; fehlerhafte Automatisierung bei der Gerätebereitstellung. 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: funktionierende DNS-Auflösung; erreichbaren KDC auf dem Domänencontroller; ausreichend synchronisierte Zeit; ein gültiges Benutzerkonto; passende kryptografische Schlüssel; bei Dienstzugriffen einen korrekten Service Principal Name; bei Smartcard-Anmeldung geeignete Zertifikate und Vertrauensketten. 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: ist ein Ticket Granting Ticket vorhanden? für welche Kerberos-Realm wurde es ausgestellt? welcher KDC hat das Ticket ausgestellt? sind Start- und Ablaufzeit plausibel? sind Diensttickets für die erwarteten Dienste vorhanden? wird statt Kerberos möglicherweise NTLM verwendet? stimmt der Servername mit dem erwarteten Dienstnamen überein? klist purge löscht Kerberos-Tickets der angegebenen Anmeldesitzung und ist daher keine rein lesende Diagnose: klist purge Mögliche Auswirkungen: bestehende Zugriffe müssen neu authentifiziert werden; Netzlaufwerke oder Anwendungen können vorübergehend Verbindungen verlieren; die eigentliche Ursache kann durch das Löschen alter Nachweise verdeckt werden; der Befehl betrifft nur die ausgewählte Anmeldesitzung. 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: Windows-Protokolle → System Windows-Protokolle → Sicherheit Anwendungs- und Dienstprotokolle → Microsoft → Windows → GroupPolicy → Operational Anwendungs- und Dienstprotokolle → Microsoft → Windows → User Profile Service → Operational Netlogon-, DNS-Client-, LSA-, Kerberos-, W32Time- und Gruppenrichtlinienereignisse Auf dem beteiligten Domänencontroller: Windows-Protokolle → Sicherheit Windows-Protokolle → System Verzeichnisdienst DNS-Server DFS-Replikation Kerberos-, Netlogon-, KDC-, LSA- und Replikationsereignisse 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: Ereignis 4740 ; aufrufender Computer; Ereignisse 4771 bei Kerberos; Ereignisse 4776 bei NTLM; Ereignisse 4625 auf Quell- und Zielsystemen; gespeicherte Windows-Anmeldeinformationen; verbundene Netzlaufwerke; geplante Aufgaben; Windows-Dienste; Anwendungen mit gespeichertem Kennwort; Mobilgeräte und Mailprogramme; VPN-Clients; alte RDP-Sitzungen; Skripte; weitere Computer des Benutzers. 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: Zu prüfen sind: letzte erfolgreiche Replikation; Anzahl und Dauer der Fehler; betroffene Verzeichnispartition; Quell- und Ziel-DC; DNS-Fehler; RPC-Fehler; Zugriffs- oder Vertrauensfehler; Zeitabweichung; Replikation von Benutzer- und Computerkontoänderungen; Erreichbarkeit des PDC-Emulators; SYSVOL- und DFSR-Zustand. Mögliche Symptome eines Replikationsfehlers: neues Kennwort funktioniert nur über bestimmte DCs; Konto erscheint auf einem DC gesperrt und auf einem anderen nicht; neues Benutzer- oder Computerkonto ist nicht überall vorhanden; reparierter sicherer Kanal schlägt über einen anderen DC erneut fehl; Gruppenmitgliedschaften unterscheiden sich; Anmeldung funktioniert standortabhängig. 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: ist das Clientsubnetz in Active Directory Sites and Services eingetragen? ist es dem richtigen Standort zugeordnet? besitzt dieser Standort einen erreichbaren DC? antwortet ein entfernter DC schneller als der lokale DC? verteilt das VPN das richtige AD-Subnetz und die richtigen DNS-Server? sind die notwendigen Netze über den Tunnel erreichbar? existieren unterschiedliche Regeln vor und nach der Benutzeranmeldung? verwendet der Standort einen Read-Only Domain Controller? darf der RODC die Anmeldeinformationen dieses Benutzers zwischenspeichern? ist ein beschreibbarer DC erreichbar, wenn Kennwortänderung oder Kontosperrenbehandlung erforderlich ist? 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: wird der richtige Zielcomputer angesprochen? verwendet der RDP-Client gespeicherte alte Anmeldeinformationen? ist das richtige Namensformat angegeben? ist Network Level Authentication aktiv? kann das Zielsystem einen DC erreichen? ist der sichere Kanal des Zielsystems gültig? besitzt der Benutzer das Recht zur Anmeldung über Remotedesktopdienste? wird dieses Recht durch eine Verweigerungsrichtlinie überschrieben? ist der Benutzer Mitglied der vorgesehenen lokalen oder domänenweiten Gruppe? existiert bereits eine eingeschränkte oder getrennte Sitzung? liegt Ereignis 4625 mit Logon Type 10 vor? 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: Smartcard und Lesegerät; Benutzerzertifikat; Gültigkeitszeitraum; UPN beziehungsweise Identitätszuordnung; Zertifikatskette; Sperrstatus und Erreichbarkeit der CRL- oder OCSP-Dienste; KDC-Zertifikat des Domänencontrollers; geeignete Zertifikatvorlage; unterstützte Kryptografie; Zeit; Ereignis 4771 und PKINIT-Fehlercodes. Bei Windows Hello for Business zu prüfen: wurde PIN oder Kennwort gewählt? ist das Gerät ordnungsgemäß registriert? ist der Hello-Schlüssel vorhanden? ist das TPM verfügbar? stimmt der Vertrauensmodus der Organisation? wurden Richtlinien oder Zertifikate verändert? ist eine Onlineverbindung für den jeweiligen Vorgang erforderlich? 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: Benutzerprofildienst kann das Profil nicht laden; Profilpfad ist nicht erreichbar; servergespeichertes Profil ist beschädigt; lokaler Profildatenträger ist voll; Berechtigungen des Profilordners sind fehlerhaft; Gruppenrichtlinienverarbeitung hängt; Anmeldeskript wartet auf eine nicht erreichbare Ressource; Ordnerumleitung schlägt fehl; Netzlaufwerk oder Druckerzuordnung hat ein Timeout; Sicherheitssoftware blockiert den Sitzungsaufbau; Windows lädt ein temporäres Profil. 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 Fehlermeldung aufnehmen Exakten Wortlaut, Benutzer, Computer, Uhrzeit und Anmeldeart dokumentieren. Anmeldephase bestimmen Identität, Authentifizierung, Sitzung oder Profil unterscheiden. Umfang bestimmen Einen Benutzer, einen Computer, einen Standort oder die gesamte Domäne unterscheiden. Anmeldeanbieter kontrollieren Kennwort, PIN, Smartcard, lokales Konto und Domänenkonto unterscheiden. Namensformat prüfen UPN und DOMÄNE\Benutzer kontrolliert vergleichen. Domänenmitgliedschaft prüfen Lokale Mitgliedschaft und erwartete Domäne bestätigen. Online- und Cache-Anmeldung unterscheiden Feststellen, ob ein DC tatsächlich beteiligt war. Netzwerkzustand prüfen Schnittstelle, Adresse, Gateway, VPN und DNS-Server dokumentieren. DNS-SRV-Einträge prüfen LDAP- und Kerberos-Diensteinträge auflösen. Domänencontroller ermitteln nltest /dsgetdc und Standortinformationen auswerten. DC-Erreichbarkeit prüfen DNS, Kerberos, LDAP, SMB, RPC und benötigte Zusatzdienste untersuchen. Zeit prüfen Zeitquelle, Status und Abweichung zum DC bestimmen. Benutzerkonto prüfen Existenz, UPN, Aktivierung, Sperre, Ablauf und Kennwortstatus auswerten. Sicheren Kanal prüfen Ausschließlich mit lesenden Tests beginnen. Authentifizierungsverfahren bestimmen Kerberos, NTLM, Smartcard oder Windows Hello unterscheiden. Ereignisse korrelieren Client- und DC-Ereignisse auf denselben Versuch begrenzen. Fehlercode auswerten Status, Substatus, Kerberos-Code und Anmeldetyp bestimmen. Replikation prüfen Besonders bei DC- oder Standortabhängigkeit. Nachgelagerte Anmeldung prüfen Profil, Gruppenrichtlinie, Skript und Ressourcen untersuchen. Hypothese formulieren Erwarteten Befund und möglichen Gegenbeweis festlegen. Eine kontrollierte Maßnahme durchführen Risiko, Berechtigung, Rückweg und Erfolgskriterium dokumentieren. Online-Domänenanmeldung verifizieren Nicht nur Cache- oder lokale Anmeldung testen. Vollständige Benutzerfunktion prüfen Desktop, Gruppenrichtlinien und benötigte Ressourcen kontrollieren. 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: die Domänenmitgliedschaft bestätigt ist; DNS korrekt funktioniert; ein geeigneter DC erreichbar ist; die Zeit ausreichend synchronisiert ist; das Computerkonto vorhanden ist; Replikationsprobleme berücksichtigt wurden; ein autorisiertes lokales Administratorkonto verfügbar ist; Risiko und Rückweg dokumentiert wurden. Reparatur mit PowerShell: $Credential = Get-Credential "\" Test-ComputerSecureChannel ` -Repair ` -Server "" ` -Credential $Credential ` -Verbose Alternativ kann das lokale Computerkennwort kontrolliert zurückgesetzt werden: $Credential = Get-Credential "\" Reset-ComputerMachinePassword ` -Server "" ` -Credential $Credential Danach: Test-ComputerSecureChannel ` -Server "" ` -Verbose Anschließend sind je nach Verfahren ein Neustart und eine erneute Online-Domänenanmeldung erforderlich. Wichtig: Zugangsdaten dürfen nicht direkt in Klartext in einen Befehl geschrieben werden. nltest /sc_verify , nltest /sc_reset und nltest /sc_change_pwd können den Vertrauenszustand verändern. Auf Domänencontrollern gelten andere Reparaturverfahren. Das Entfernen und erneute Hinzufügen zur Domäne ist eine letzte Maßnahme. Eine Domänenneuanmeldung ohne Ursachenanalyse kann das Symptom nur vorübergehend beseitigen. Bei wiederkehrenden Vertrauensfehlern müssen Snapshot-Verfahren, Klonprozesse, doppelte Computernamen, Replikation und Computerkennwortänderungen untersucht werden. 7.10.36 Verifikation Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: Computer ist weiterhin Mitglied der richtigen Domäne; Client verwendet die vorgesehenen DNS-Server; LDAP- und Kerberos-SRV-Einträge werden korrekt aufgelöst; DC Locator findet einen geeigneten Domänencontroller; Client ist dem richtigen AD-Standort zugeordnet; erforderliche AD-Dienste sind erreichbar; Zeitquelle und Zeitabweichung sind plausibel; sicherer Kanal liefert ein erfolgreiches Ergebnis; Benutzerkonto ist aktiviert und nicht gesperrt; Anmeldung verwendet den richtigen Benutzer und die richtige Domäne; Anmeldung erfolgt online gegen einen Domänencontroller; ein Kerberos-TGT kann ausgestellt werden, sofern Kerberos vorgesehen ist; keine neuen Fehler 4625 , 4771 , 4776 , 3210 oder 5719 entstehen; Benutzerprofil wird vollständig geladen; Gruppenrichtlinien werden verarbeitet; Anmeldeskripte werden abgeschlossen; benötigte Netzressourcen funktionieren; RDP funktioniert, wenn es zum ursprünglichen Fehler gehörte; mehrere repräsentative Benutzer oder Clients funktionieren, wenn der Fehler größeren Umfang hatte; temporäre Diagnoseänderungen wurden zurückgenommen; Sicherheitsfunktionen wie NLA, Firewall und Zertifikatsprüfung bleiben aktiv; Ursache, Maßnahme und Prävention wurden dokumentiert. Eine erfolgreiche lokale oder zwischengespeicherte Anmeldung ist keine ausreichende Verifikation einer reparierten Domänenanmeldung. 7.10.37 Präventionsmaßnahmen redundante und überwachte Domänencontroller bereitstellen; DNS-Dienste und AD-SRV-Einträge überwachen; Clients ausschließlich mit vorgesehenen AD-DNS-Servern konfigurieren; AD-Standorte und Subnetze vollständig dokumentieren; VPN mit geeigneter DNS- und Routingkonfiguration bereitstellen; bei Bedarf einen sicheren Voranmelde-VPN-Weg vorsehen; Windows-Zeithierarchie überwachen; PDC-Emulator und externe Zeitquelle dokumentieren; AD-Replikation kontinuierlich überwachen; Domänencontrollerereignisse zentral sammeln; Kontosperren mit Quellcomputer auswerten; Kennwortänderungen und gespeicherte Anmeldeinformationen berücksichtigen; Computerobjekte nicht unkontrolliert löschen oder zurücksetzen; VM-Snapshot- und Wiederherstellungsverfahren mit AD-Vertrauensbeziehungen abstimmen; Computer nur über standardisierte Verfahren klonen; doppelte Computernamen verhindern; sicheren Kanal überwachen, ohne automatische unkontrollierte Reparaturen auszuführen; lokale Notfalladministration nach Sicherheitsvorgabe gewährleisten; Gruppenrichtlinien vor breiter Verteilung testen; Profil-, SYSVOL- und DFSR-Zustand überwachen; Zertifikatsablauf und Sperrprüfungsdienste bei Smartcard-Anmeldung überwachen; Windows-Hello-Bereitstellung und Vertrauensmodell dokumentieren; Sicherheitsprotokolle ausreichend groß dimensionieren; Uhrzeiten aller Systeme zentral korrelierbar halten; Runbooks für DNS-, DC-, Replikations- und Vertrauensfehler testen. 7.10.38 Typische Fehler bei der Diagnose Die Meldung sofort als falsches Kennwort interpretieren. Lokales Konto und Domänenkonto verwechseln. UPN, DNS-Domäne und NETBIOS-Domäne gleichsetzen. PIN und Domänenkennwort gleichsetzen. Eine Cache-Anmeldung als erfolgreiche Online-Domänenanmeldung werten. Nur den Domänennamen anpingen. Einen erfolgreichen Ping als Nachweis der AD-Anmeldung betrachten. Öffentliche DNS-Server auf einem Domänenclient eintragen. DNS-Caches löschen, bevor die falsche Antwort dokumentiert wurde. Nur TCP 389 prüfen und die übrigen AD-Abhängigkeiten ignorieren. Einen erfolgreichen Test auf TCP 135 als vollständigen RPC-Nachweis betrachten. UDP mit einem allgemeinen Porttest als sicher funktionsfähig einstufen. Zeit nur optisch ablesen und die tatsächliche Abweichung nicht messen. Ein Konto wiederholt testen und dadurch sperren. Ein gesperrtes Konto entsperren, ohne die Sperrquelle zu ermitteln. Das Kennwort vorsorglich zurücksetzen. Gespeicherte alte Kennwörter in Diensten oder Aufgaben ignorieren. nltest /sc_verify als rein lesenden Test verwenden. Den sicheren Kanal reparieren, bevor DNS und Netzwerk funktionieren. Test-ComputerSecureChannel auf einem DC wie auf einem Mitgliedscomputer interpretieren. Den Computer sofort aus der Domäne entfernen. AD-Replikation durch eine erzwungene Synchronisation „reparieren“, ohne den Fehler auszuwerten. Nur einen Domänencontroller untersuchen. Den verwendeten DC und Standort nicht dokumentieren. Ereignis 4625 ohne Status, Substatus und Logon Type interpretieren. Kerberos-Code 0x19 automatisch als Störung einstufen. Kerberos-Tickets löschen, bevor sie dokumentiert wurden. RDP-Fehler nur auf dem lokalen Client untersuchen. NLA, Firewall oder Zertifikatsprüfung dauerhaft deaktivieren. Profilfehler mit fehlgeschlagener Kennwortprüfung verwechseln. Vor der Protokollsicherung neu starten. Kennwörter oder vollständige Sicherheitsprotokolle ungeschützt weitergeben. Nach der Maßnahme nur eine lokale oder zwischengespeicherte Anmeldung testen. 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 exakte Fehlermeldung dokumentiert Benutzer, Computer und Fehlerzeitpunkt erfasst lokale, RDP-, VPN-, Smartcard-, PIN- oder Kennwortanmeldung bestimmt Fehlerphase bestimmt Umfang des Fehlers bestimmt richtiger Anmeldeanbieter gewählt lokales Konto und Domänenkonto unterschieden UPN und DOMÄNE\Benutzer geprüft Tastaturlayout kontrolliert Domänenmitgliedschaft bestätigt Online- und Cache-Anmeldung unterschieden aktive Netzwerkschnittstelle geprüft IP-Adresse, Gateway und VPN geprüft verwendete DNS-Server dokumentiert LDAP-SRV-Eintrag geprüft Kerberos-SRV-Eintrag geprüft zurückgegebene DC-Namen aufgelöst DC Locator ausgeführt AD-Standort geprüft geeigneter beschreibbarer DC bei Bedarf ermittelt DNS-Funktion gegen vorgesehenen Server geprüft Kerberos-Erreichbarkeit geprüft LDAP-Erreichbarkeit geprüft SMB-Erreichbarkeit geprüft RPC und dynamische Ports berücksichtigt UDP-Dienste nicht nur durch allgemeinen Porttest bewertet Windows-Zeitstatus geprüft Zeitquelle geprüft Abweichung zum DC gemessen Benutzerkonto gefunden UPN kontrolliert Kontoaktivierung geprüft Kontosperre geprüft Kontoablauf geprüft Kennwortablauf geprüft Anmeldezeiten und Arbeitsstationsbeschränkungen berücksichtigt Sperrquelle vor Entsperrung untersucht Computerkonto geprüft sicheren Kanal zunächst nur lesend geprüft Kerberos und NTLM unterschieden Kerberos-Tickets vor Änderungen dokumentiert Clientereignisse ausgewertet DC-Ereignisse ausgewertet Ereignis 4625 mit Status und Substatus geprüft Logon Type ausgewertet Kerberos-Ereignisse geprüft Ereignis 4740 bei Sperre geprüft AD-Replikation bei DC-Abhängigkeit geprüft RODC und Kennwortreplikationsrichtlinie berücksichtigt RDP und NLA bei Remoteanmeldung berücksichtigt Smartcard oder Windows Hello abgegrenzt Profil, Gruppenrichtlinie und Anmeldeskript geprüft Hypothese und Gegenbeweis formuliert Risiko und Rückweg dokumentiert nur eine kontrollierte Maßnahme durchgeführt Online-Domänenanmeldung verifiziert vollständiges Benutzerprofil geladen benötigte Netzwerkressourcen geprüft keine neuen relevanten Ereignisfehler vorhanden temporäre Diagnoseänderungen zurückgenommen Ursache und Präventionsmaßnahme dokumentiert 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. -Type SRV Kerberos-SRV-Eintrag Resolve-DnsName _kerberos._tcp. -Type SRV DC ermitteln nltest /dsgetdc: DC neu ermitteln nltest /dsgetdc: /force AD-Standort nltest /dsgetsite DC-Liste nltest /dclist: DNS-TCP-Test Test-NetConnection -Port 53 Kerberos-TCP-Test Test-NetConnection -Port 88 LDAP-TCP-Test Test-NetConnection -Port 389 SMB-TCP-Test Test-NetConnection -Port 445 RPC Endpoint Mapper Test-NetConnection -Port 135 Zeitstatus w32tm /query /status Zeitquelle w32tm /query /source Zeitvergleich w32tm /stripchart /computer: /dataonly /samples:5 Benutzerkonto Get-ADUser -Properties * gesperrte Konten Search-ADAccount -LockedOut -UsersOnly sicherer Kanal, nur Test Test-ComputerSecureChannel -Verbose letzter Netlogon-Kanalstatus nltest /sc_query: 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 Microsoft Learn – Locating Active Directory domain controllers in Windows and Windows Server Microsoft Learn – Troubleshoot domain controller location issues Microsoft Learn – Service overview and network port requirements for Windows Microsoft Learn – Configure a firewall for Active Directory domains and trusts Microsoft Learn – Resolve-DnsName Microsoft Learn – Test-NetConnection Microsoft Learn – Nltest Microsoft Learn – Test-ComputerSecureChannel Microsoft Learn – Reset-ComputerMachinePassword Microsoft Learn – Broken trust relationship between a domain-joined device and its domain Microsoft Learn – Data collection for troubleshooting secure channel issues Microsoft Learn – Secure Channel Problems Detected Microsoft Learn – How the Windows Time Service works Microsoft Learn – Maximum tolerance for computer clock synchronization Microsoft Learn – Interactive logon: Number of previous logons to cache Microsoft Learn – Cached and Stored Credentials Technical Overview Microsoft Learn – Klist Microsoft Learn – Kerberos authentication troubleshooting guidance Microsoft Learn – Get-ADUser Microsoft Learn – Search-ADAccount Microsoft Learn – Get-WinEvent Microsoft Learn – Ereignis 4625: An account failed to log on Microsoft Learn – Ereignis 4740: A user account was locked out Microsoft Learn – Ereignis 4768: A Kerberos authentication ticket was requested Microsoft Learn – Ereignis 4769: A Kerberos service ticket was requested Microsoft Learn – Ereignis 4771: Kerberos pre-authentication failed Microsoft Learn – Ereignis 4776: The computer attempted to validate the credentials for an account Microsoft Learn – Dcdiag Microsoft Learn – Diagnose Active Directory replication failures Microsoft Learn – Verify DNS functionality to support directory replication Microsoft Learn – Advanced audit policy configuration settings Standards RFC 4120 – The Kerberos Network Authentication Service RFC 2782 – A DNS RR for specifying the location of services 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: Ist nur eine Anwendung oder das gesamte System betroffen? Betrifft der Fehler Vorwärts- oder Rückwärtsauflösungen? Wird tatsächlich der vorgesehene DNS-Server verwendet? Antwortet der DNS-Server gar nicht, langsam oder mit einem Fehlercode? Ist der DNS-Server für die abgefragte Zone autoritativ? Stammt die Antwort aus einem Client-, Anwendungs- oder Servercache? Entsteht die Verzögerung lokal, im Netzwerk oder bei einem nachgelagerten DNS-Server? Existiert die benötigte Reverse-Lookup-Zone? Ist der PTR-Eintrag vorhanden und korrekt? Stimmen Vorwärts- und Rückwärtsauflösung überein? Betrifft der Fehler nur einen DNS-Server oder alle vorgesehenen DNS-Server? Liegt eine fehlerhafte Delegation, Weiterleitung oder dynamische Aktualisierung vor? Verwendet die Anwendung klassisches DNS, DoH, DoT oder einen eigenen Resolver? 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 Anwendungen starten oder verbinden sich mit deutlicher Verzögerung. Verbindungen über IP-Adresse funktionieren schneller als über den Hostnamen. Eine Anwendung wartet vor der eigentlichen Anmeldung mehrere Sekunden. Protokolle zeigen nur IP-Adressen statt Hostnamen. nslookup zeigt als DNS-Server Unknown oder UnKnown . Vorwärtsauflösung funktioniert, Rückwärtsauflösung jedoch nicht. Eine IP-Adresse liefert einen falschen oder veralteten Hostnamen. Derselbe Name liefert abhängig vom DNS-Server unterschiedliche Antworten. Die erste Abfrage ist langsam, weitere Abfragen sind schnell. Abfragen interner Namen funktionieren nur im Firmennetz oder VPN. Externe Namen sind langsam, interne Namen dagegen schnell. Nur Abfragen bestimmter Zonen sind betroffen. Kleine DNS-Antworten funktionieren, größere Antworten schlagen fehl. Abfragen über UDP schlagen fehl, über TCP funktionieren sie. Abfragen enden mit NXDOMAIN , SERVFAIL , REFUSED oder einem Timeout. Mailserver lehnen Verbindungen wegen fehlendem oder unpassendem Reverse-DNS ab. Überwachungssysteme erzeugen falsche Zuordnungen zwischen IP-Adresse und Hostname. Nach einer IP-Adressänderung bleibt der alte PTR-Eintrag bestehen. Neue Geräte erhalten einen A-Eintrag, aber keinen PTR-Eintrag. Browser und Betriebssystem liefern für denselben Namen unterschiedliche Ergebnisse. DNS funktioniert ohne VPN, aber nicht über den VPN-Tunnel. nslookup funktioniert, eine Anwendung mit NRPT-Auswertung jedoch nicht – oder umgekehrt. 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: die IPv6-Adresse vollständig ausgeschrieben; jede Hexadezimalstelle einzeln betrachtet; die Reihenfolge aller Hexadezimalstellen umgekehrt; zwischen jeder Stelle ein Punkt eingefügt; 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: dass die Vorwärtsauflösung fehlerhaft ist; dass der Host nicht erreichbar ist; dass der Hostname nicht existiert; dass der DNS-Server vollständig ausgefallen ist; dass Active Directory nicht funktioniert; dass die IP-Adresse ungültig ist. Reverse-Lookups werden unter anderem verwendet von: Diagnosewerkzeugen; Protokollierungs- und Überwachungssystemen; Mailservern; Sicherheitsprodukten; Inventarisierungsprogrammen; Netzwerkdiensten mit Hostnamenprüfung; Anwendungen, die eingehende IP-Adressen in Namen auflösen; Administratoren bei der Auswertung von Verbindungen. 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: betroffener Client; betroffene Anwendung; Datum und genaue Uhrzeit; Quell-IP-Adresse; verwendete Netzwerkschnittstelle; VPN-Zustand; konfigurierte DNS-Server; DNS-Suffixe und Suchliste; abgefragter Name beziehungsweise abgefragte IP-Adresse; Abfragetyp; verwendeter DNS-Server; vollständige Antwort; Antwortcode; Antwortzeit; autoritative oder rekursive Antwort; Verhalten bei Wiederholung; Verhalten über einen alternativen DNS-Server; Verhalten bei direkter IP-Verbindung; vorhandene Client- und Servercaches; vorhandene PTR-, A-, AAAA-, CNAME- oder SRV-Einträge; letzte DNS-, DHCP- oder IP-Adressänderung; verwendeter DNS-Transport. 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: welche DNS-Server tatsächlich eingetragen sind; welche Schnittstelle die DNS-Server bereitstellt; ob VPN oder Sicherheitssoftware eigene Resolver einbindet; ob interne DNS-Suffixe vorhanden sind; ob eine Suchliste zusätzliche Abfragen erzeugt; ob IPv4- und IPv6-Resolver unterschiedlich konfiguriert sind; ob Split-DNS oder eine namensbasierte Weiterleitung aktiv ist; ob öffentliche DNS-Server für interne Unternehmensnamen verwendet werden; ob die Reihenfolge der DNS-Server dem vorgesehenen Design entspricht. 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: lokale Hosts-Datei; DNS-Clientcache; anwendungseigener DNS-Cache; Browsercache; lokaler Stub-Resolver; VPN-Resolver; Name Resolution Policy Table unter Windows; mDNS; LLMNR; NetBIOS-Namensauflösung; Proxy; DNS over HTTPS; DNS over TLS; Container- oder Cluster-DNS; Sicherheits- beziehungsweise Filtersoftware. 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: welcher Namensraum von einer Regel erfasst wird; welcher DNS-Server für diesen Namensraum vorgesehen ist; ob die Regel nur bei aktivem VPN gilt; ob eine allgemeinere Regel eine spezifische Regel beeinflusst; ob interne und öffentliche Zone denselben Namen unterschiedlich beantworten; ob der VPN-Tunnel die benötigten DNS-Server erreicht; ob eine Anwendung die Windows-DNS-API verwendet. 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: verwendet das Betriebssystem DoH oder DoT? verwendet nur der Browser einen eigenen DoH-Resolver? stimmt die URI beziehungsweise der TLS-Hostname? ist das Zertifikat gültig und vertrauenswürdig? stimmt der Zertifikatsname mit dem DNS-Endpunkt überein? ist der verschlüsselte Port erreichbar? ist ein Fallback auf unverschlüsseltes DNS erlaubt? umgeht die Anwendung den Unternehmens-DNS-Server? kann der verschlüsselte Resolver interne Zonen auflösen? unterscheiden sich Antworten zwischen klassischem und verschlüsseltem DNS? 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: DoH verschlüsselt den Transportweg. DNSSEC schützt die Authentizität und Integrität signierter DNS-Daten. 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: Status beziehungsweise Antwortcode; PTR-Zielname; TTL; autoritative Kennzeichnung; antwortender DNS-Server; Antwortzeit; Verhalten bei wiederholter Abfrage. 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: erste Abfrage; unmittelbar wiederholte Abfrage; Abfrage eines sicher vorhandenen Namens; Abfrage eines nicht vorhandenen Namens; Vorwärtsauflösung; Rückwärtsauflösung; interner Name; externer Name; primärer DNS-Server; alternativer DNS-Server; UDP; TCP; mit und ohne VPN. 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: wurde der betroffene Name bereits zwischengespeichert? ist die Antwort positiv oder negativ? ist ein veralteter Wert vorhanden? stimmt der Datensatztyp? ist die verbleibende TTL plausibel? wurde die Antwort durch einen früheren VPN- oder Netzwerkzustand erzeugt? 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: die Anzahl der DNS-Abfragen erhöhen; rekursive DNS-Server stärker belasten; die Abhängigkeit von Netzwerk und autoritativen Servern erhöhen. Eine sehr hohe TTL kann: veraltete Antworten länger wirksam halten; geplante Änderungen verzögern; eine Fehlerkorrektur erst nach Ablauf des Caches sichtbar machen. 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: TTL des A-, AAAA-, CNAME-, SRV- oder PTR-Eintrags; SOA-Daten der betroffenen Zone; negative Cachezeit; Clientcache; rekursiver Servercache; anwendungseigener Cache. 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: wenn eine UDP-Antwort abgeschnitten wurde; bei größeren DNS-Antworten; bei bestimmten DNSSEC-Antworten; für Zonentransfers; wenn der Client TCP ausdrücklich verwendet. 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: einfache A-Abfrage funktioniert; DNSKEY-, TXT- oder umfangreiche AAAA-Antwort schlägt fehl; UDP-Abfrage endet im Timeout; dieselbe Abfrage funktioniert über TCP; Problem tritt nur über VPN, Tunnel oder bestimmte Firewalls auf; SERVFAIL tritt nur bei DNSSEC-signierten Zonen auf. 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: +dnssec beziehungsweise -DnssecOk fordert DNSSEC-bezogene Daten an; das Vorhandensein solcher Daten beweist nicht allein eine erfolgreiche Validierung; ein SERVFAIL kann durch eine fehlerhafte DNSSEC-Vertrauenskette entstehen; ein erfolgreicher TCP-Test bei fehlerhaftem UDP-Verhalten weist auf den Transportpfad, nicht automatisch auf falsche Zonendaten hin; EDNS darf nicht dauerhaft deaktiviert werden, nur um einen fehlerhaften Netzwerkpfad zu umgehen. 7.11.23 Autoritative Antwort, Rekursion und Weiterleitung unterscheiden Ein DNS-Server kann eine Antwort liefern: aus einer lokal gehosteten autoritativen Zone; aus seinem Cache; über einen allgemeinen Forwarder; über einen bedingten Forwarder; über iterative Rekursion; über eine Stubzone; über eine richtliniengesteuerte Rekursionskonfiguration. Für eine saubere Diagnose sind mindestens drei Ebenen zu vergleichen: Abfrage über den vom Client verwendeten DNS-Server; Abfrage über einen alternativen vorgesehenen DNS-Server; 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: existiert die übergeordnete Reverse-Zone? wurde der richtige Adressbereich delegiert? stimmen die NS-Einträge? lassen sich die Nameservernamen auflösen? sind die autoritativen Server erreichbar? antworten alle autoritativen Server gleich? existiert bei klassenlosen IPv4-Netzen eine korrekte RFC-2317-Delegation? stimmt die IPv6-Nibble-Delegation mit dem zugeteilten Präfix überein? verweist eine alte Delegation noch auf außer Betrieb genommene Server? 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: internes Adresskonzept; zuständige DNS-Server; AD-Integrations- und Replikationsbereich; DHCP-Aktualisierung; sichere dynamische Updates; Aging und Scavenging. Ö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: welcher Provider den IP-Adressbereich kontrolliert; ob der Provider eine Reverse-DNS-Verwaltung anbietet; welcher Ziel-FQDN eingetragen werden soll; ob der Zielname vorwärts wieder auf die öffentliche IP-Adresse zeigt; ob mehrere öffentliche IP-Adressen oder NAT berücksichtigt werden müssen. 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: IP-Adresse rückwärts auflösen. PTR-Zielnamen dokumentieren. PTR-Zielnamen über A und AAAA auflösen. Prüfen, ob die ursprüngliche IP-Adresse in den Ergebnissen enthalten ist. 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: läuft der DNS-Serverdienst? ist die Zone geladen? ist die Zone primär, sekundär, Stub- oder AD-integriert? ist die Zone angehalten? ist sie für dynamische Updates vorgesehen? auf welche Server wird sie repliziert? existieren mehrere widersprüchliche Zonen für denselben Namensraum? liegt eine veraltete sekundäre Zone vor? ist die Zone nur auf einem Teil der DNS-Server vorhanden? 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: Knotenname; PTR-Zielname; TTL; Zeitstempel; statischer oder dynamischer Datensatz; Ergebnis auf weiteren DNS-Servern; zugehöriger A- oder AAAA-Eintrag; aktuelle IP-Zuweisung. 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: sind die Forwarder erreichbar? antworten alle Forwarder zuverlässig? ist ihre Reihenfolge beziehungsweise Verfügbarkeit plausibel? ist Rekursion aktiviert, wenn sie benötigt wird? existiert ein bedingter Forwarder für die betroffene Zone? verweist der bedingte Forwarder auf aktuelle Server? sind Root Hints vorgesehen und verwendbar? sind Cachegrenzen und negative Cachezeit plausibel? bestehen DNS-Richtlinien oder Rekursionsbereiche? unterscheiden sich die Einstellungen zwischen DNS-Servern? 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: empfangene Abfragen; gesendete Antworten; Rekursionsvorgänge; Timeouts; Serverfehler; Formatfehler; abgelehnte Abfragen; Cacheverhalten; dynamische Updates; Paket- und Speicherstatistiken. 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: Abfragen pro Sekunde; Antworten pro Sekunde; CPU-Auslastung des DNS-Prozesses; Arbeitsspeicher; Netzwerkauslastung; Timeouts und Fehler; rekursive Abfragen; Antwortzeit aus Clientsicht; Zeitpunkt der Störung. 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: analytische Protokollierung nur gezielt aktivieren; Start- und Endzeit dokumentieren; ausreichenden Speicherplatz sicherstellen; Datenschutz und Schutz der DNS-Abfragedaten berücksichtigen; Protokollierung nach der Diagnose wieder zurücksetzen; Serverleistung während der Aufzeichnung überwachen; keine vollständigen internen DNS-Protokolle ungeschützt weitergeben. 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: Quell- und Ziel-IP-Adresse; verwendeter Port; UDP oder TCP; DNS-Transaktions-ID; Abfragetyp; Antwortcode; Wiederholungen; abgeschnittene UDP-Antworten; anschließender TCP-Versuch; Paketverlust; ICMP-Fehlermeldungen; Verzögerung zwischen Abfrage und Antwort; Wechsel zu einem weiteren DNS-Server; EDNS- und DNSSEC-bezogene Größenprobleme; TLS-Verbindungsaufbau bei DoH oder DoT. 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: existiert die Forward-Lookup-Zone? existiert die passende Reverse-Lookup-Zone? sind dynamische Updates für beide Zonen erlaubt? werden ausschließlich sichere dynamische Updates verwendet? soll der Client oder der DHCP-Server den PTR-Eintrag registrieren? besitzt das aktualisierende Konto die erforderlichen Rechte? gehört ein vorhandener Datensatz einem anderen Aktualisierungskonto? existiert ein veralteter statischer Eintrag? wird die Schnittstelle für DNS-Registrierung verwendet? stimmen Verbindungssuffix und Zonenname? sind mehrere aktive Schnittstellen beteiligt? erscheinen Aktualisierungsfehler in den DNS-, DHCP- oder Clientprotokollen? 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: DHCP-Bereich und aktuelle Lease; zugeteilte IP-Adresse; Clientname und FQDN; DNS-Optionen des DHCP-Bereichs; Einstellung zur Aktualisierung von A- und PTR-Einträgen; Verhalten bei Lease-Ablauf und Adressfreigabe; verwendete DHCP-DNS-Anmeldeinformationen; Berechtigungen und Eigentümer vorhandener DNS-Datensätze; mehrere DHCP-Server; Failover-Konfiguration; AD-Replikation der DNS-Zone; DHCP-Serverereignisse zum Zeitpunkt der Aktualisierung. Mögliche Fehlerbilder: A-Eintrag wird erstellt, PTR-Eintrag jedoch nicht; neuer PTR-Eintrag wird angelegt, alter PTR bleibt bestehen; PTR zeigt auf den Namen eines früheren Lease-Nehmers; ein DHCP-Server kann den Datensatz aktualisieren, ein anderer nicht; statischer Datensatz verhindert die erwartete Aktualisierung; die Reverse-Zone existiert nur auf einem Teil der DNS-Server. 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: ist Aging für die Zone aktiviert? ist Scavenging auf einem geeigneten DNS-Server aktiviert? wie lang sind No-Refresh- und Refresh-Intervall? wie lang ist der Scavenging-Zyklus? besitzt der Datensatz einen dynamischen Zeitstempel? ist der Datensatz statisch? wurde die Zone neu erstellt oder die Funktion nachträglich aktiviert? stimmt die Konfiguration zwischen Forward- und Reverse-Zone? können aktive Geräte ihre Datensätze rechtzeitig aktualisieren? passen DHCP-Leasezeit und DNS-Alterungskonzept zusammen? wurde ein Datensatz bereits als veraltet eingestuft? 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: Replikationsübersicht: repadmin /replsummary Replikationsdetails: repadmin /showrepl Zu prüfen sind: Replikationsbereich der Zone; vorhandene Verzeichnispartition; letzte erfolgreiche Replikation; betroffene Quell- und Ziel-Domänencontroller; DNS- und RPC-Fehler; unterschiedliche Datensatzstände; nur auf einzelnen DCs vorhandene PTR-Einträge; verzögerte Löschung veralteter Einträge; Zustand von AD DS und DNS-Serverdienst. Eine erzwungene Replikation ist keine erste Diagnosemaßnahme. Zuerst müssen Richtung, Partner, Fehlercode und Ursache bestimmt werden. 7.11.38 Systematischer Diagnoseablauf Störungsbild dokumentieren Client, Anwendung, Name oder IP-Adresse, Uhrzeit und genaue Verzögerung erfassen. Abfragerichtung bestimmen Vorwärtsauflösung, Rückwärtsauflösung oder beide unterscheiden. Umfang bestimmen Einzelner Client, Anwendung, Standort, Zone oder alle Systeme unterscheiden. Resolverpfad erfassen DNS-Server, VPN, Suchsuffixe, Hosts-Datei, NRPT, DoH, DoT und lokale Resolver prüfen. Abfrage reproduzieren Den vorgesehenen DNS-Server ausdrücklich angeben. Antwortcode dokumentieren NOERROR , NXDOMAIN , SERVFAIL , REFUSED oder Timeout unterscheiden. Antwortzeit messen Erste und wiederholte Abfrage getrennt messen. Vorwärts- und Reverse-Abfrage vergleichen A beziehungsweise AAAA und PTR unabhängig testen. Alternativen DNS-Server testen Unterschiedliche Serverantworten dokumentieren. UDP und TCP vergleichen Transportabhängige Fehler abgrenzen. DoH oder DoT abgrenzen Verschlüsselten und klassischen DNS-Pfad getrennt prüfen. Autoritativen Server bestimmen Delegation und zuständige Zone prüfen. Direkte autoritative Abfrage durchführen Rekursion und Forwarder vom Zonenzustand trennen. PTR-Datensatz prüfen Zielname, TTL, Zeitstempel und Eigentümer auswerten. Vorwärts-Rückwärts-Konsistenz prüfen PTR-Zielnamen erneut über A und AAAA auflösen. Weitere Datensatztypen prüfen CNAME- oder SRV-Abhängigkeiten berücksichtigen. Cachezustand prüfen Client-, Server- und Anwendungscache unterscheiden. Forwarder und Rekursion prüfen Besonders bei langsamen externen oder bedingt weitergeleiteten Zonen. EDNS, MTU und DNSSEC prüfen Wenn kleine Antworten funktionieren und größere Antworten ausfallen. Serverleistung prüfen Abfragerate, CPU, Speicher, Fehler und Timeouts korrelieren. Dynamische Aktualisierung prüfen Client, DHCP, Berechtigungen und Zonenrichtlinie untersuchen. Aging und Scavenging prüfen Veraltete oder unerwartet gelöschte Datensätze abgrenzen. AD-Replikation prüfen Wenn DNS-Server unterschiedliche Antworten liefern. Hypothese formulieren Erwarteten Befund und möglichen Gegenbeweis festlegen. Eine kontrollierte Maßnahme durchführen Risiko, Rückweg und Erfolgskriterium dokumentieren. Erneut unter denselben Bedingungen messen Antwort, Code und Zeit mit dem Ausgangswert vergleichen. Gesamten DNS-Pfad verifizieren Client, rekursiven Server, autoritativen Server und Anwendung prüfen. 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: Client verwendet die vorgesehenen DNS-Server; richtige Netzwerkschnittstelle und VPN-Regel sind aktiv; DNS-Suffixe und Suchliste sind korrekt; NRPT-Regeln wirken wie vorgesehen; verwendeter DNS-Transport ist bestimmt; Vorwärtsauflösung liefert den erwarteten A- beziehungsweise AAAA-Eintrag; Rückwärtsauflösung liefert den erwarteten PTR-Eintrag; PTR-Zielname lässt sich vorwärts auflösen; ursprüngliche IP-Adresse ist in der Vorwärtsantwort enthalten, sofern vorgesehen; CNAME- und SRV-Ziele sind auflösbar; alle autoritativen DNS-Server liefern denselben Datensatz; rekursive DNS-Server liefern konsistente Antworten; erste und wiederholte Antwortzeit sind plausibel; UDP- und TCP-Auflösung funktionieren; DoH oder DoT funktioniert, sofern vorgesehen; negative Cacheeinträge sind abgelaufen oder kontrolliert entfernt; Forwarder und bedingte Forwarder antworten; Reverse-Zone ist korrekt delegiert; AD-integrierte Zone repliziert fehlerfrei; dynamische Aktualisierung funktioniert, sofern vorgesehen; DHCP erzeugt oder entfernt PTR-Einträge korrekt; Aging und Scavenging löschen keine aktiven Datensätze; DNSSEC-validierte Zonen verursachen keine neuen Fehler; keine neuen DNS-, DHCP- oder Replikationsfehler entstehen; betroffene Anwendung verwendet die korrigierte Auflösung; temporäre Diagnoseprotokollierung wurde zurückgenommen; Ursache, Maßnahme und Prävention wurden dokumentiert. Eine einzelne erfolgreiche Cacheabfrage ist keine ausreichende Verifikation des vollständigen DNS-Pfads. 7.11.44 Präventionsmaßnahmen Forward- und Reverse-Zonen gemeinsam planen; Zuständigkeiten für private und öffentliche Reverse-Zonen dokumentieren; PTR-Einträge für wichtige Server und Infrastrukturkomponenten pflegen; DNS-Server selbst mit korrekten PTR-Einträgen versehen; Vorwärts- und Rückwärtskonsistenz regelmäßig prüfen; DNS-Server redundant bereitstellen; autoritative und rekursive Rollen dokumentieren; Forwarder und bedingte Forwarder überwachen; Reverse-Delegationen regelmäßig kontrollieren; klassenlose IPv4-Delegationen eindeutig dokumentieren; IPv6-Reverse-Zonen anhand der delegierten Präfixe planen; DNS-Antwortzeiten und Fehlerquoten als Baseline erfassen; Abfrageraten, CPU, Speicher und Netzwerk überwachen; UDP- und TCP-Port 53 in Firewallkonzepten berücksichtigen; DoH-, DoT-, DNSSEC- und EDNS-Verhalten bei Netzwerkänderungen testen; MTU und Fragmentierung auf VPN- und Tunnelpfaden berücksichtigen; TTL-Werte an Änderungs- und Lastanforderungen anpassen; negative Cachezeiten berücksichtigen; DHCP- und DNS-Aktualisierungsverantwortung eindeutig festlegen; abgesicherte Aktualisierungsverfahren verwenden; Aging und Scavenging zuerst in kontrolliertem Umfang testen; AD-Replikation überwachen; Zonenänderungen protokollieren; veraltete statische Einträge regelmäßig prüfen; VPN-, Split-DNS-, NRPT- und DoH-Konfigurationen dokumentieren; Anwendungen mit eigenem DNS-Verhalten erfassen; Runbooks für langsame DNS-Abfragen und fehlerhafte PTR-Einträge testen. 7.11.45 Typische Fehler bei der Diagnose Unknown in nslookup sofort als vollständigen DNS-Ausfall bewerten. Vorwärts- und Rückwärtsauflösung gleichsetzen. Einen vorhandenen A-Eintrag als Beweis für einen PTR-Eintrag betrachten. Einen fehlenden PTR-Eintrag automatisch als Verbindungsursache einstufen. Die Antwortzeit nicht messen. Nur eine einzelne Abfrage durchführen. Cachetreffer und vollständige Rekursion nicht unterscheiden. Den verwendeten DNS-Server nicht ausdrücklich angeben. Anwendungsergebnis und direkte DNS-Abfrage gleichsetzen. Hosts-Datei, VPN, NRPT, DoH oder Anwendungscache ignorieren. nslookup als vollständigen Test einer NRPT-Regel verwenden. Test-NetConnection -Port 53 als UDP-DNS-Test verwenden. Nur UDP oder nur TCP prüfen. NXDOMAIN , SERVFAIL und Timeout gleich behandeln. Eine negative Antwort mit einer ausgebliebenen Antwort verwechseln. DNS-Caches vor der Dokumentation löschen. Den DNS-Servercache routinemäßig leeren. Forwarder ändern, ohne die ursprüngliche Konfiguration zu sichern. Nur einen autoritativen DNS-Server prüfen. Die Reverse-Delegation nicht untersuchen. Bei öffentlichen IP-Adressen selbst eine nicht delegierte Reverse-Zone veröffentlichen wollen. IPv4-Oktette falsch anordnen. IPv6-Blöcke statt einzelner Nibbles umkehren. RFC-2317-Delegationen bei kleineren IPv4-Netzen ignorieren. PTR-Zielnamen nicht wieder vorwärts auflösen. Mehrere PTR- oder A-Einträge ohne Kenntnis des Systemdesigns löschen. CNAME-Ziele nicht bis zum endgültigen A- oder AAAA-Eintrag verfolgen. Einen erfolgreichen SRV-Lookup mit einem erreichbaren Dienst gleichsetzen. Große DNS-Antworten und Fragmentierung nicht berücksichtigen. DNSSEC bei SERVFAIL nicht prüfen. DoH und DNSSEC gleichsetzen. Dynamische Registrierung wiederholt auslösen, ohne Berechtigungen zu prüfen. Scavenging spontan aktivieren. Veraltete statische Einträge mit dynamischen Einträgen gleichsetzen. AD-Replikationsprobleme durch manuelle Datensatzänderungen verdecken. Analytische DNS-Protokollierung unbegrenzt eingeschaltet lassen. DNS-Protokolle mit internen Namen ungeschützt weitergeben. Nach der Änderung nur den Cache und nicht den vollständigen DNS-Pfad testen. 7.11.46 Checkliste betroffenes System und Anwendung dokumentiert genauer Fehlerzeitpunkt erfasst Vorwärts- oder Rückwärtsauflösung bestimmt Umfang der Störung bestimmt verwendete Netzwerkschnittstelle geprüft VPN-Zustand dokumentiert konfigurierte DNS-Server erfasst DNS-Suffixe und Suchliste geprüft Hosts-Datei berücksichtigt NRPT geprüft Split-DNS berücksichtigt DoH, DoT und Anwendungscache berücksichtigt betroffener Name oder IP-Adresse dokumentiert Abfragetyp bestimmt DNS-Server bei Test ausdrücklich angegeben vollständige Antwort dokumentiert Antwortcode ausgewertet Timeout von DNS-Fehlercode unterschieden erste Antwortzeit gemessen wiederholte Antwortzeit gemessen positiver Cache geprüft negativer Cache geprüft TTL dokumentiert Vorwärtsauflösung getestet IPv4-Rückwärtsauflösung getestet IPv6-Rückwärtsauflösung bei Bedarf getestet PTR-Zielname dokumentiert PTR-Zielname vorwärts aufgelöst Vorwärts-Rückwärts-Konsistenz geprüft CNAME-Kette bei Bedarf geprüft SRV-Ziel und Dienstport bei Bedarf geprüft primärer DNS-Server getestet alternativer DNS-Server getestet autoritativer DNS-Server bestimmt direkte autoritative Abfrage durchgeführt Reverse-Delegation geprüft RFC-2317-Konfiguration bei Teilnetzen berücksichtigt öffentliche oder private IP-Adresse unterschieden UDP-DNS getestet TCP-DNS getestet größere DNS-Antwort getestet EDNS und MTU berücksichtigt DNSSEC bei SERVFAIL berücksichtigt verschlüsselter DNS-Pfad bei Bedarf getestet Forwarder geprüft bedingte Forwarder geprüft Rekursion geprüft DNS-Serverdienst geprüft Reverse-Zone auf dem Server geprüft PTR-Datensatz direkt geprüft Zeitstempel und statischer Zustand geprüft Serverstatistiken ausgewertet Abfragerate und Serverlast korreliert DNS-Ereignisse ausgewertet dynamische Aktualisierung geprüft DHCP-Aktualisierung geprüft Berechtigungen und Datensatzeigentümer geprüft Aging und Scavenging geprüft AD-Replikation bei unterschiedlichen Antworten geprüft Hypothese und Gegenbeweis formuliert Risiko und Rückweg dokumentiert nur eine kontrollierte Maßnahme durchgeführt Antwortcode nach der Maßnahme geprüft Antwortzeit nach der Maßnahme geprüft vollständiger DNS-Pfad verifiziert Anwendung erneut getestet temporäre Diagnoseänderungen zurückgenommen Ursache und Präventionsmaßnahme dokumentiert 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 -Type A -Server -DnsOnly Vorwärtsauflösung IPv6 Resolve-DnsName -Type AAAA -Server -DnsOnly Rückwärtsauflösung Resolve-DnsName -Type PTR -Server -DnsOnly Rückwärtsauflösung mit dig dig @ -x CNAME prüfen Resolve-DnsName -Type CNAME -Server -DnsOnly SRV prüfen Resolve-DnsName -Type SRV -Server -DnsOnly TCP-DNS-Abfrage Resolve-DnsName -Server -TcpOnly -DnsOnly TCP-Port 53 prüfen Test-NetConnection -Port 53 DNSSEC-Daten anfordern Resolve-DnsName -Server -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 -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 Microsoft Learn – Guidance for troubleshooting DNS Microsoft Learn – Troubleshoot DNS servers Microsoft Learn – Troubleshoot DNS client name resolution issues Microsoft Learn – DNS queries and lookups Microsoft Learn – DNS architecture Microsoft Learn – Manage DNS zones Microsoft Learn – Manage DNS resource records Microsoft Learn – Dynamic DNS Update in Windows and Windows Server Microsoft Learn – DNS scavenging setup Microsoft Learn – Troubleshoot DNS scavenging issues Microsoft Learn – Forwarders and conditional forwarders resolution timeouts Microsoft Learn – Enable DNS logging and diagnostics Microsoft Learn – DNS encryption using DNS over HTTPS Microsoft Learn – Enable DNS over HTTPS in DNS Server Microsoft Learn – Troubleshoot DNS over HTTPS in DNS Server Microsoft Learn – Secure DNS Client over HTTPS Microsoft Learn – netsh dnsclient Microsoft Learn – Resolve-DnsName Microsoft Learn – DnsClient PowerShell module Microsoft Learn – Clear-DnsClientCache Microsoft Learn – Register-DnsClient Microsoft Learn – Get-DnsServerZone Microsoft Learn – Get-DnsServerResourceRecord Microsoft Learn – Add-DnsServerPrimaryZone Microsoft Learn – Add-DnsServerResourceRecordPtr Microsoft Learn – Get-DnsServerStatistics Microsoft Learn – Get-DnsServerCache Microsoft Learn – Clear-DnsServerCache Microsoft Learn – Set-DnsServerEncryptionProtocol Microsoft Learn – DnsServer PowerShell module Microsoft Learn – Verify that SRV DNS records have been created Microsoft Learn – Dcdiag Microsoft Learn – Diagnose Active Directory replication failures Standards RFC 1034 – Domain Names: Concepts and Facilities RFC 1035 – Domain Names: Implementation and Specification RFC 2308 – Negative Caching of DNS Queries RFC 2317 – Classless IN-ADDR.ARPA Delegation RFC 3596 – DNS Extensions to Support IPv6 RFC 7858 – Specification for DNS over Transport Layer Security RFC 8484 – DNS Queries over HTTPS RFC 8499 – DNS Terminology 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: welcher Name oder welche IP-Adresse betroffen ist; welcher Datensatztyp benötigt wird; welcher Client und welche Anwendung betroffen sind; welcher Resolverweg tatsächlich verwendet wird; welcher DNS-Server die Anfrage erhält; ob eine Antwort eintrifft; welcher Antwortcode zurückgegeben wird; ob die Antwort korrekt und aktuell ist; ob die Antwort aus einem Cache oder einer autoritativen Zone stammt; an welcher Stelle eine Verzögerung oder ein Fehler entsteht; welche einzelne Maßnahme die nachgewiesene Ursache behebt; wie die vollständige Funktion anschließend verifiziert wird. 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 Zuerst beobachten und dokumentieren. Den exakten Namen und Datensatztyp verwenden. Clientverhalten und direkte DNS-Abfrage unterscheiden. Den tatsächlich verwendeten DNS-Server bestimmen. Antwortcode und Antwortinhalt getrennt bewerten. Positive, negative und ausgebliebene Antworten unterscheiden. Cache-, rekursive und autoritative Antworten trennen. UDP, TCP, DoH und DoT nicht gleichsetzen. Pro Versuch nur eine relevante Variable verändern. Vor jeder Änderung Risiko und Rückweg dokumentieren. Nach der Maßnahme denselben Test wiederholen. Erst nach technischer Verifikation den Vorgang abschließen. Folgende Maßnahmen sind keine geeigneten ersten Diagnoseschritte: DNS-Cache sofort löschen; öffentlichen DNS-Server eintragen; DNS-Dienst neu starten; Zone neu erstellen; DNS-Einträge vorsorglich löschen; Forwarder verändern; Scavenging aktivieren; Client erneut in die Domäne aufnehmen; Firewall oder DNSSEC deaktivieren; VPN-, NRPT- oder DoH-Richtlinien entfernen. 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: exakter FQDN; gewünschter Datensatztyp; erwarteter Wert; vorgesehener DNS-Server; autoritativer DNS-Server; Vergleichsname, der sicher funktioniert; Vergleichsname, der sicher nicht existiert; vorgesehene Antwortzeit oder vorhandene Baseline. 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: aktive Schnittstelle; IPv4- und IPv6-Adresse; Subnetz beziehungsweise Präfix; Standardgateway; DNS-Server; DHCP- oder statische Konfiguration; Verbindungssuffix; VPN-Schnittstelle; unerwartete zusätzliche Schnittstellen; Container-, Hypervisor- oder Sicherheitsadapter. 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: DNS-Server pro Schnittstelle; Reihenfolge der DNS-Server; DNS-Suffixe; Suchliste; VPN-spezifische Resolver; IPv4- und IPv6-DNS-Server; lokale Stub-Adressen; namensraumabhängige Resolver. /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: interne Zonen unauflösbar machen; Active-Directory-SRV-Einträge verbergen; Split-DNS umgehen; interne Namen an externe Resolver übertragen; Anmeldungen, Gruppenrichtlinien und Dienstsuche beeinträchtigen; zu wechselnden Ergebnissen führen. 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: existiert ein Eintrag für den betroffenen Namen? stimmt die eingetragene IP-Adresse? existieren doppelte oder auskommentierte Varianten? verwendet die Anwendung einen eigenen lokalen Namensspeicher? stammt die erfolgreiche Auflösung überhaupt aus DNS? 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: falsches Verbindungssuffix; fehlende Suchdomäne; zu lange Suchliste; unerwartete Reihenfolge; unterschiedliche Suffixe zwischen LAN und VPN; ein Kurzname trifft unbeabsichtigt auf eine andere Zone; Suchanfragen erzeugen zusätzliche Verzögerungen. 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: Resolve-DnsName kann den Windows-Resolverpfad einschließlich NRPT verwenden. nslookup verwendet einen eigenen Abfrageweg und eignet sich nicht allein zur Prüfung der NRPT. Browser oder andere Anwendungen können eigene DoH-Resolver verwenden. Eine direkte Abfrage mit -Server prüft den angegebenen DNS-Server, aber nicht zwingend die gesamte normale Resolverauswahl der Anwendung. 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: Kann die Ziel-IP-Adresse direkt erreicht werden? Liefert eine direkte DNS-Abfrage die erwartete Adresse? Liefert der normale Betriebssystemresolver dieselbe Adresse? Verwendet die Anwendung dieselbe Adresse? 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: Abfragename; Datensatztyp; verwendeter DNS-Server; Antwortcode; Antwortinhalt; TTL; Antwortzeit; Flags; autoritative oder rekursive Antwort; zusätzliche CNAME-Ziele. 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: NODATA ist kein eigener RCODE, sondern beschreibt typischerweise NOERROR ohne den angefragten Datensatz. Timeout ist keine DNS-Antwort. SERVFAIL beweist nicht, dass der Name nicht existiert. NXDOMAIN und ein fehlender einzelner Datensatztyp sind nicht dasselbe. Extended DNS Errors können zusätzliche Hinweise liefern, werden aber nicht von jedem Resolver oder Diagnosewerkzeug angezeigt. 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: erste Abfrage; unmittelbar wiederholte Abfrage; vorhandener Name; nicht vorhandener Name; interner Name; externer Name; primärer DNS-Server; alternativer DNS-Server; rekursiver DNS-Server; autoritativer DNS-Server; UDP; TCP; mit und ohne VPN. 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: positiver oder negativer Cacheeintrag; Datensatztyp; gespeicherter Wert; verbleibende TTL; Herkunft des Eintrags; Verhalten nach Ablauf der TTL; Unterschiede zwischen Anwendung, Client und DNS-Server. 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: nicht vorhandenen Namen; vorhandenen Namen ohne angefragten Datensatztyp; vorübergehende Auflösungsfehler, abhängig vom Resolververhalten. Mögliche Folge: Ein Name wird abgefragt und liefert NXDOMAIN . Der fehlende Datensatz wird anschließend angelegt. Der Client oder rekursive Resolver liefert zunächst weiterhin die gespeicherte negative Antwort. 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: Antwortcode; Datensatzwert; TTL; CNAME-Kette; Antwortzeit; Autoritätsflag; SOA- und NS-Daten; DNSSEC-Verhalten. 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: bei abgeschnittenen UDP-Antworten; bei größeren Antworten; bei bestimmten DNSSEC-Antworten; bei Zonentransfers; wenn TCP ausdrücklich angefordert wird. 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: einfache A-Abfrage funktioniert; größere TXT-, DNSKEY- oder DNSSEC-Antwort schlägt fehl; Fehler tritt nur über VPN oder Tunnel auf; UDP endet im Timeout; dieselbe Abfrage funktioniert über TCP; Netzwerkaufzeichnung zeigt fragmentierte oder verlorene Pakete. 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: verwendetes Protokoll; Resolveradresse; DoH-URI beziehungsweise DoT-Hostname; TCP-Port; TLS-Zertifikat; Zertifikatsname; Vertrauenskette; Fallback auf klassisches DNS; Firewall- und Proxyweg; Anwendung mit eigenem DoH-Resolver; Erreichbarkeit interner Zonen. 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: Client fragt vorgesehenen rekursiven DNS-Server. Rekursiver Server liefert Fehler oder langsame Antwort. Autoritativer DNS-Server wird direkt abgefragt. Ergebnisse werden verglichen. Wenn der autoritative Server korrekt und schnell antwortet, liegt die Ursache wahrscheinlich bei: Rekursion; Forwarder; Cache; DNSSEC-Validierung; Netzwerkpfad; Richtlinie des rekursiven Servers. 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: richtige Zonengrenze; zuständige autoritative Server; Erreichbarkeit aller autoritativen Server; korrekte NS-Einträge; erforderliche Glue Records; SOA-Seriennummer; widersprüchliche Antworten; veraltete Delegation; fehlende oder falsche Child-Zone. 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: Erreichbarkeit aller Forwarder; Antwortzeit jedes Forwarders; bedingter Forwarder für den betroffenen Namensraum; aktuelle Zieladressen; Replikationsbereich eines AD-integrierten bedingten Forwarders; aktivierte oder deaktivierte Rekursion; Root-Hint-Verwendung; DNS-Richtlinien und Rekursionsbereiche; Timeout- und Fallbackverhalten. 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: Reverse-Zone; Delegation; PTR-Eintrag; Zielname; TTL; Vorwärts-Rückwärts-Konsistenz; veraltete Einträge; öffentliche oder private Zuständigkeit; dynamische Aktualisierung. 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: tritt SERVFAIL nur bei signierten Zonen auf? funktioniert die Abfrage über einen nicht validierenden Vergleichspfad? existieren DS- und DNSKEY-Datensätze? sind Signaturen gültig? stimmt die Systemzeit? ist der Trust Anchor vorhanden? verlangt die NRPT DNSSEC-Validierung? zeigt der Resolver einen Extended DNS Error an? besteht ein Größen- oder Transportproblem? -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: Dienststatus; geladene und angehaltene Zonen; primäre, sekundäre, Stub- oder AD-integrierte Zone; Replikationsbereich; dynamische Updates; Zonentransfer; Serverfehler; Rekursionsfehler; Abfragerate; CPU, Speicher und Netzwerk; Unterschiede zwischen DNS-Servern. 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." ` -Type SRV Kerberos-SRV-Einträge: Resolve-DnsName ` -Name "_kerberos._tcp." ` -Type SRV DNS-Test eines Domänencontrollers: dcdiag /test:DNS /v /s: Replikationsübersicht: repadmin /replsummary Replikationsdetails: repadmin /showrepl Zu prüfen sind: verwendet der Client ausschließlich vorgesehene AD-DNS-Server? existieren die benötigten SRV-Einträge? sind die SRV-Zielhosts über A oder AAAA auflösbar? sind die veröffentlichten Dienste erreichbar? existiert die Zone auf allen vorgesehenen DNS-Servern? funktioniert AD-Replikation? stimmen Standort- und Subnetzzuordnung? liefern verschiedene DCs unterschiedliche Antworten? 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: Existenz der Forward- und Reverse-Zone; erlaubte Aktualisierungsart; sichere dynamische Updates; Client- oder DHCP-Verantwortung; DHCP-Lease; DNS-Optionen des DHCP-Bereichs; Aktualisierung von A- und PTR-Einträgen; Datensatzeigentümer; Berechtigungen; statische Altbestände; DHCP-Failover; DNS- und DHCP-Ereignisse. 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: Aging-Einstellung der Zone; Scavenging-Einstellung des Servers; No-Refresh-Intervall; Refresh-Intervall; Scavenging-Zyklus; Zeitstempel des Datensatzes; statischer oder dynamischer Eintrag; DHCP-Leasezeit; Zeitpunkt der letzten Aktualisierung; unerwartet gelöschte Datensätze. 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: DNS-Client-Protokolle; DNS-Server-Audit-Protokoll; DNS-Server-Analytical-Protokoll; Systemprotokoll; DHCP-Serverprotokoll; Verzeichnisdienstprotokoll; anwendungsspezifische Protokolle. Zu korrelieren sind: genauer Zeitpunkt; Clientadresse; Abfragename; Datensatztyp; Antwortcode; verwendeter Server; dynamische Aktualisierung; Zonenladen; Replikation; DNSSEC; DoH; Dienststart oder Dienstfehler. 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: ob die Abfrage den Client verlässt; welcher DNS-Server angesprochen wird; ob eine Antwort zurückkommt; ob Wiederholungen stattfinden; ob UDP oder TCP verwendet wird; ob die UDP-Antwort abgeschnitten ist; ob anschließend TCP verwendet wird; ob Fragmentierung oder Paketverlust auftritt; wie lang die Antwort tatsächlich benötigt; ob der Client zu einem anderen DNS-Server wechselt. 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: vermutete Ursache; erwarteten messbaren Befund; möglichen Gegenbeweis; Testmethode; Erfolgskriterium; Risiko des Tests. 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: Ausgangszustand; betroffene Systeme und Zonen; Berechtigung; Risiko; Rückweg; Erfolgskriterium; vorgesehenes Testverfahren. 7.12.39 Vollständiger Diagnoseablauf Exakte Fehlermeldung aufnehmen Wortlaut, Anwendung, Benutzer, Client und Uhrzeit dokumentieren. Betroffenen Namen bestimmen Kurzname, FQDN oder IP-Adresse unterscheiden. Erwarteten Datensatztyp bestimmen A, AAAA, CNAME, PTR, SRV, MX, TXT, NS oder SOA festlegen. Erwartetes Ergebnis dokumentieren Vorgesehene IP-Adresse, Zielname oder Dienstinformation festhalten. Umfang bestimmen Einzelnen Client, Standort, DNS-Server, Namen, Zone oder alle Systeme unterscheiden. Anwendung und DNS abgrenzen Direkte IP-Verbindung, Systemresolver und Anwendung getrennt prüfen. Netzwerkzustand erfassen Schnittstelle, Adresse, Gateway, VPN und Routing dokumentieren. Konfigurierte DNS-Server erfassen DNS-Server pro Schnittstelle und Reihenfolge bestimmen. Suffixe und lokale Namensquellen prüfen Suchliste, Hosts-Datei und Anwendungscache berücksichtigen. Resolverrichtlinien prüfen NRPT, Split-DNS, Container-DNS und Sicherheitsresolver berücksichtigen. Verschlüsselten DNS-Pfad bestimmen Klassisches DNS, DoH und DoT unterscheiden. Normale Systemauflösung testen Prüfen, welches Ergebnis die Anwendung grundsätzlich erhalten kann. Direkte Abfrage durchführen Vorgesehenen DNS-Server und Datensatztyp ausdrücklich angeben. Antwortcode auswerten NOERROR , NXDOMAIN , SERVFAIL , REFUSED oder Timeout unterscheiden. Antwortinhalt auswerten Wert, TTL, CNAME-Kette und Flags prüfen. Antwortzeit messen Erste und wiederholte Abfrage vergleichen. Alternativen DNS-Server prüfen Unterschiede zwischen vorgesehenen Resolvern dokumentieren. Cachezustand prüfen Positive und negative Einträge auf allen relevanten Ebenen berücksichtigen. UDP und TCP vergleichen Transportabhängige Fehler bestimmen. EDNS, MTU und Fragmentierung prüfen Besonders bei großen Antworten oder VPN-Verbindungen. Rekursiven und autoritativen Server unterscheiden Abfrageweg in einzelne Ebenen zerlegen. SOA, NS und Delegation prüfen Zuständigkeit und Zonengrenze bestätigen. Autoritative Server direkt vergleichen Datensatz, TTL, Seriennummer und Antwortcode auswerten. Forwarder und Rekursion prüfen Erreichbarkeit, Richtlinien und Timeoutpfad untersuchen. DNSSEC prüfen Signaturen, DS, DNSKEY, Trust Anchor und Validierungsfehler berücksichtigen. Reverse-Lookup prüfen PTR, Reverse-Zone, Delegation und Vorwärtskonsistenz auswerten. DNS-Serverzustand prüfen Dienst, Zonen, Statistiken, Last und Ereignisse untersuchen. AD-DNS und Replikation prüfen Wenn AD-integrierte Zonen oder SRV-Einträge beteiligt sind. Dynamische Updates und DHCP prüfen Registrierung, Eigentümer, Berechtigungen und Leasezustand auswerten. Aging und Scavenging prüfen Bei veralteten oder unerwartet fehlenden Einträgen. Protokolle korrelieren Client, DNS-Server, DHCP und Anwendung auf denselben Versuch begrenzen. Bei Bedarf Netzwerkaufzeichnung durchführen Nur zeitlich und technisch begrenzt. Hypothese und Gegenbeweis formulieren Ursache vor der Änderung messbar beschreiben. Eine kontrollierte Maßnahme ausführen Risiko, Rückweg und Erfolgskriterium beachten. Identischen Test wiederholen Antwortcode, Wert und Zeit mit dem Ausgangszustand vergleichen. Alternativen Pfad erneut prüfen Weitere Clients, Resolver oder autoritative Server kontrollieren. Anwendung verifizieren Nicht nur das Diagnosewerkzeug testen. Temporäre Änderungen zurücknehmen Logging, Testregeln und Ausnahmen entfernen. Ursache dokumentieren Technischen Nachweis und betroffenen Pfad festhalten. 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 Fehlermeldung nicht vollständig dokumentieren. Kurzname und FQDN verwechseln. Den benötigten Datensatztyp nicht bestimmen. ping als vollständigen DNS-Test verwenden. Einen erfolgreichen Ping als Nachweis des Dienstes betrachten. Nur nslookup verwenden. NRPT mit nslookup prüfen. Anwendung und direkten DNS-Test gleichsetzen. Den tatsächlich verwendeten DNS-Server nicht bestimmen. Öffentlichen DNS-Server auf einem Domänenclient eintragen. Cache vor der Beweissicherung löschen. NXDOMAIN , NODATA , SERVFAIL und Timeout gleich behandeln. Nur den Antwortcode, aber nicht den Antwortinhalt prüfen. Nur den Antwortwert, aber nicht TTL und Quelle prüfen. Rekursiven und autoritativen DNS-Server verwechseln. Nur einen DNS-Server testen. UDP und TCP nicht getrennt prüfen. TCP-Port 53 als UDP-Nachweis verwenden. EDNS, MTU und Fragmentierung ignorieren. DoH oder DoT über einen klassischen DNS-Test als funktionsfähig bewerten. DNSSEC allein mit nslookup prüfen. +dnssec als vollständigen Validierungsnachweis interpretieren. Öffentliche +trace -Abfrage für eine interne Split-DNS-Zone verwenden. CNAME-, MX- oder SRV-Zielnamen nicht weiter auflösen. Erfolgreichen SRV-Lookup mit erreichbarem Dienst gleichsetzen. PTR-Fehler als vollständigen DNS-Ausfall bewerten. Forwarder verändern, ohne ihr Verhalten direkt zu testen. DNS-Dienst vorsorglich neu starten. Zone vorsorglich neu erstellen. Einträge löschen, ohne Eigentümer, TTL und Replikation zu prüfen. Scavenging unkontrolliert aktivieren. AD-Replikationsfehler durch manuelle DNS-Änderungen verdecken. Pro Diagnoseversuch mehrere Variablen verändern. Nur das Diagnosewerkzeug, aber nicht die Anwendung verifizieren. Temporäre Logging- oder Firewalländerungen aktiv lassen. 7.12.42 Verifikation Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: Client besitzt eine gültige Netzwerkkonfiguration; vorgesehene DNS-Server sind eingetragen; richtige Schnittstelle und VPN-Regel werden verwendet; Suffixe und Suchliste sind korrekt; Hosts-Datei enthält keinen widersprüchlichen Eintrag; NRPT und Split-DNS funktionieren wie vorgesehen; DoH oder DoT funktioniert, sofern vorgesehen; exakter FQDN wird korrekt aufgelöst; benötigter Datensatztyp ist vorhanden; Antwortcode ist korrekt; Antwortwert entspricht dem Sollzustand; TTL ist plausibel; rekursive und autoritative Antworten sind konsistent; alle vorgesehenen DNS-Server liefern den richtigen Wert; UDP und TCP funktionieren; DNSSEC-Validierung funktioniert, sofern vorgesehen; Vorwärts- und Rückwärtsauflösung stimmen überein, sofern erforderlich; SRV-, MX- und CNAME-Ziele sind vollständig auflösbar; AD-SRV-Einträge sind vorhanden; AD-Replikation ist fehlerfrei; dynamische Aktualisierung funktioniert, sofern vorgesehen; keine neuen DNS-, DHCP- oder Replikationsfehler entstehen; Antwortzeit entspricht der Baseline; ursprüngliche Anwendung funktioniert; weitere repräsentative Clients funktionieren; temporäre Diagnoseänderungen wurden zurückgenommen; Ursache, Maßnahme und Prävention wurden dokumentiert. Eine einzelne erfolgreiche Cacheabfrage ist keine ausreichende Verifikation. 7.12.43 Dokumentationsvorlage Störung: Zeitpunkt: Betroffener Client: Betroffene Anwendung: Abfragename: Datensatztyp: Erwartetes Ergebnis: Tatsächliches Ergebnis: Verwendeter Resolver: Resolverpfad: Vergleichstests: Nachgewiesene Ursache: Gegenbeweis ausgeschlossen durch: Durchgeführte Maßnahme: Risiko und Rückweg: Verifikation: Präventionsmaßnahme: 7.12.44 Checkliste exakte Fehlermeldung dokumentiert Datum und Uhrzeit erfasst betroffenen Client erfasst betroffene Anwendung erfasst Kurzname, FQDN und IP-Adresse unterschieden benötigten Datensatztyp bestimmt erwartetes Ergebnis dokumentiert Fehlerumfang bestimmt aktive Netzwerkschnittstelle geprüft IP-Adresse und Gateway geprüft VPN-Zustand dokumentiert konfigurierte DNS-Server erfasst DNS-Serverreihenfolge geprüft DNS-Suffixe und Suchliste geprüft Hosts-Datei geprüft Anwendungscache berücksichtigt NRPT geprüft Split-DNS berücksichtigt DoH oder DoT berücksichtigt normalen Systemresolver getestet direkte DNS-Abfrage durchgeführt DNS-Server ausdrücklich angegeben Antwortcode dokumentiert Antwortinhalt dokumentiert TTL dokumentiert Antwortflags berücksichtigt Antwortzeit gemessen erste und wiederholte Abfrage verglichen positiven Cache geprüft negativen Cache geprüft alternativen DNS-Server getestet UDP getestet TCP getestet EDNS und MTU berücksichtigt rekursiven Server bestimmt autoritativen Server bestimmt SOA geprüft NS-Einträge geprüft Delegation geprüft autoritative Server direkt verglichen Forwarder geprüft bedingte Forwarder geprüft Rekursion geprüft A- und AAAA-Einträge geprüft CNAME-Kette geprüft SRV- oder MX-Ziele bei Bedarf geprüft Reverse-Lookup geprüft DNSSEC bei Bedarf geprüft DNS-Serverdienst geprüft Zonenstatus geprüft Serverstatistiken geprüft Serverlast geprüft DNS-Ereignisse ausgewertet AD-SRV-Einträge bei Bedarf geprüft AD-Replikation bei Bedarf geprüft dynamische Updates bei Bedarf geprüft DHCP-DNS-Aktualisierung bei Bedarf geprüft Aging und Scavenging bei Bedarf geprüft Hypothese formuliert Gegenbeweis festgelegt Risiko und Rückweg dokumentiert nur eine kontrollierte Maßnahme durchgeführt identischen Test wiederholt ursprüngliche Anwendung getestet weitere repräsentative Systeme geprüft temporäre Änderungen zurückgenommen Ursache und Prävention dokumentiert 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 direkte A-Abfrage Resolve-DnsName -Type A -Server -DnsOnly direkte AAAA-Abfrage Resolve-DnsName -Type AAAA -Server -DnsOnly CNAME prüfen Resolve-DnsName -Type CNAME -Server -DnsOnly SRV prüfen Resolve-DnsName -Type SRV -Server -DnsOnly PTR prüfen Resolve-DnsName -Type PTR -Server -DnsOnly SOA prüfen Resolve-DnsName -Type SOA -Server -DnsOnly NS prüfen Resolve-DnsName -Type NS -Server -DnsOnly direkte Abfrage mit dig dig @ Reverse-Abfrage mit dig dig @ -x öffentliche Delegation verfolgen dig +trace TCP-DNS unter Windows Resolve-DnsName -Server -DnsOnly -TcpOnly TCP-DNS mit dig dig @ +tcp DNSSEC-Daten anfordern dig @ +dnssec Windows-Clientcache Get-DnsClientCache Windows-DNS-Dienst Get-Service DNS Windows-DNS-Zonen Get-DnsServerZone Windows-DNS-Datensätze Get-DnsServerResourceRecord -ZoneName 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: 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 Microsoft Learn – Guidance for troubleshooting DNS Microsoft Learn – Troubleshooting DNS clients Microsoft Learn – Troubleshooting DNS servers Microsoft Learn – Troubleshoot DNS client name resolution issues Microsoft Learn – Troubleshoot DNS name resolution on the Internet Microsoft Learn – DNS queries and lookups Microsoft Learn – DNS architecture Microsoft Learn – Resolve-DnsName Microsoft Learn – DnsClient PowerShell module Microsoft Learn – DnsServer PowerShell module Microsoft Learn – Test-NetConnection Microsoft Learn – Best practices for DNS client settings Microsoft Learn – Forwarders and conditional forwarders resolution timeouts Microsoft Learn – Dynamic DNS Update in Windows and Windows Server Microsoft Learn – DNS scavenging setup Microsoft Learn – Enable DNS logging and diagnostics Microsoft Learn – Validate and secure DNS responses using DNSSEC Microsoft Learn – Secure DNS Client over HTTPS Microsoft Learn – DNS encryption using DNS over HTTPS Microsoft Learn – netsh dnsclient Microsoft Learn – Dcdiag Microsoft Learn – Verify DNS functionality to support directory replication Offizielle Projektdokumentation ISC BIND 9 – dig manual page ISC BIND 9 – Troubleshooting systemd – resolvectl systemd – systemd-resolved Standards RFC 1034 – Domain Names: Concepts and Facilities RFC 1035 – Domain Names: Implementation and Specification RFC 2308 – Negative Caching of DNS Queries RFC 4033 – DNS Security Introduction and Requirements RFC 4035 – Protocol Modifications for DNS Security Extensions RFC 6891 – Extension Mechanisms for DNS RFC 7766 – DNS Transport over TCP RFC 7858 – DNS over Transport Layer Security RFC 8484 – DNS Queries over HTTPS RFC 8499 – DNS Terminology RFC 8914 – Extended DNS Errors RFC 9520 – Negative Caching of DNS Resolution Failures 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: den tatsächlich betroffenen Pfad bestimmen; logische und physische Speicherebenen unterscheiden; belegte Datenblöcke, Inodes und Quotas getrennt prüfen; plötzliches und kontinuierliches Wachstum unterscheiden; versteckte Speicherverbraucher erkennen; eine kurzfristige Entlastung kontrolliert durchführen; die eigentliche Ursache nachweisen; einen erneuten Kapazitätsengpass verhindern. 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: Zuerst den exakten Zustand und den Zeitpunkt dokumentieren. Keine Dateien aufgrund ihres Namens löschen. Aktive Datenbanken, Container-Volumes und Anwendungsdateien nicht manuell bereinigen. Protokolle vor dem Löschen auswerten und bei Bedarf sichern. Snapshots nicht ohne Kenntnis ihrer Abhängigkeiten entfernen. Dateisystemprüfungen nicht ungeprüft auf produktiv eingebundenen Dateisystemen ausführen. Speicherpools und Thin-Provisioning-Metadaten besonders vorsichtig behandeln. Vor jeder Änderung müssen Risiko, Freigabe, Rückweg und Erfolgskriterium feststehen. 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: Dateien können nicht mehr gespeichert werden. Anwendungen starten nicht oder stürzen ab. Datenbanken wechseln in einen Fehlerzustand. Updates und Paketinstallationen schlagen fehl. Benutzerprofile können nicht geladen werden. Protokolle werden nicht mehr geschrieben. Backupjobs brechen ab. Temporäre Dateien können nicht angelegt werden. Container starten wiederholt neu. Kubernetes-Pods werden wegen DiskPressure beendet. Ein Dateisystem wird plötzlich schreibgeschützt. Ein Volume wird mit 100 % Belegung angezeigt. Ein Benutzer kann nicht schreiben, andere Benutzer jedoch schon. Eine Freigabe meldet „voll“, obwohl der Server noch freien Gesamtspeicher besitzt. 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 Exakte Fehlermeldung und Uhrzeit erfassen. Betroffenen Host, Dienst, Benutzer, Container und Pfad bestimmen. Kritikalität und Auswirkung bewerten. Aktuelle Kapazität, Inodes, Quotas und Speicherpools dokumentieren. Schreibintensive Prozesse und aktuelle Wachstumsrate identifizieren. Bei akutem Wachstum eine kontrollierte Drosselung oder Beendigung des verursachenden Dienstes prüfen. Keine unnötigen Neustarts durchführen. Keine Protokolle, Datenbanken oder Container-Volumes spontan löschen. Nur eindeutig entbehrliche und freigegebene Daten kontrolliert entfernen. 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: Welcher genaue Pfad kann nicht beschrieben werden? Welches Dateisystem enthält diesen Pfad? Ist das gesamte Dateisystem oder nur ein Benutzer betroffen? Sind Datenblöcke, Inodes oder eine Quota erschöpft? Ist das Dateisystem beschreibbar eingebunden? Welche Daten sind zuletzt gewachsen? Trat das Wachstum plötzlich oder kontinuierlich auf? Existieren Snapshots, Shadow Copies oder Container-Layer? Gibt es einen Thin-Provisioning-Pool? Liegt das eigentliche Speichersystem auf einem NAS oder SAN? Sind gelöschte Dateien weiterhin geöffnet? Sind Protokolle, Caches, Dumps, Backups oder temporäre Dateien beteiligt? Liegt zusätzlich ein Hardware- oder Dateisystemfehler vor? Welche Mindestkapazität benötigt der betroffene Dienst zur Wiederaufnahme? 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: Get-Disk bildet nicht jede mögliche Storage-Architektur vollständig ab. Hardware-RAID-Controller können nur ein virtuelles Laufwerk anzeigen. SAN-LUNs erscheinen als Datenträger, obwohl die physische Kapazität extern verwaltet wird. Storage Spaces, Cluster Shared Volumes und herstellerspezifische Pools müssen zusätzlich in ihrer jeweiligen Verwaltung geprüft werden. 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: fehlende Berechtigungen können Ergebnisse unvollständig machen; rekursive Suchen können produktive Datenträger belasten; Dateisystemmetadaten, Snapshots und geöffnete gelöschte Dateien erscheinen nicht zwingend in der Summe; Hardlinks und Deduplizierung können die Auswertung beeinflussen; ein vollständiger Lauf über ein großes Servervolume darf nicht unkontrolliert gestartet werden. 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: verwendeter Shadow-Copy-Speicher; maximal erlaubter Speicher; betroffene Quell- und Speicher-Volumes; ungewöhnlich viele Snapshots; fehlgeschlagene Bereinigungen; Backupsoftware mit VSS-Nutzung. 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: Papierkorb; temporäre Benutzer- und Systemdateien; Windows-Update-Dateien; Speicherabbilder; Ruhezustandsdatei; Auslagerungsdatei; VSS-Speicher; Anwendungsprotokolle; Installationspakete; Datenbank- und Transaktionsprotokolle; Benutzerprofile; Synchronisationsordner; lokale Cloudkopien; Backup- und Exportverzeichnisse. 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: physisch freier Speicher des Volumes; NTFS-Benutzerquota; FSRM-Verzeichnisquota; Freigabe- oder Anwendungsquota; Cloud- oder Storage-Backendlimit. 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: Zeitpunkt des ersten Speicherfehlers; Volume oder Gerätename; Dateisystemfehler; I/O-Timeouts; zurückgesetzte Storageverbindungen; Shadow-Copy-Fehler; unerwartet entfernte Datenträger; RAID-, SAN- oder Multipath-Ereignisse; Anwendungs- und Datenbankfehler zum selben Zeitpunkt. 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: Cachedateien; Sitzungsdateien; Mailqueues; kleine temporäre Dateien; extrahierte Paketbestände; Container-Layer; Build-Artefakte; nicht rotierte Protokolle mit sehr vielen Einzeldateien; Monitoring- oder Metrikdateien; Anwendungen mit fehlerhafter Dateibereinigung. 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: tatsächlicher Mountpoint; zugrunde liegendes Gerät; Dateisystemtyp; Read-only-Option ro ; Bind-Mount; Overlay-Dateisystem; LVM; verschlüsseltes Volume; Netzwerkdateisystem; Container-Mount; unerwartet nicht eingebundenes Ziel. 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: df fragt die Belegung des gesamten Dateisystems ab. du summiert erreichbare Dateien und Verzeichnisse. Wenn df eine hohe Belegung zeigt, du aber deutlich weniger Daten findet, sind insbesondere zu prüfen: gelöschte, weiterhin geöffnete Dateien; fehlende Berechtigungen bei der du -Auswertung; Snapshots; Dateisystemmetadaten; reservierte Blöcke; Daten unterhalb eines Mountpoints; Copy-on-Write- und Reflink-Daten; Deduplizierung; Container-Overlay-Layer; unterschiedliche Dateisystemgrenzen; Sparse Files; Quotadaten; beschädigte Dateisystemmetadaten. 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: Prozessname; Prozess-ID; Dateisystem; Dateigröße; gelöschter Dateipfad; Dienstabhängigkeiten; Möglichkeit eines kontrollierten Reloads oder Neustarts. 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: ungewöhnlich hohe Fehlerrate; wiederholte identische Meldungen; deaktivierte oder fehlerhafte Rotation; Anwendungen mit eigener Logverwaltung; Debug- oder Trace-Level; fehlende Aufbewahrungsgrenze; gelöschte, noch geöffnete Protokolldateien; Komprimierungsfehler; falsche Dateiberechtigungen; voller Zielpfad der Rotation. 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: Soft Limit; Hard Limit; Grace Period; Blockquota; Inodequota; Benutzerquota; Gruppenquota; XFS-Projektquota. 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: data_percent nahe der Poolkapazität; metadata_percent nahe der Metadatenkapazität; erschöpfter freier Bereich der Volume Group; viele oder stark gewachsene Snapshots; ein Logical Volume, das kleiner als der zugrunde liegende Pool ist; ein vergrößertes Blockgerät, dessen Partition, Logical Volume oder Dateisystem nicht mitgewachsen ist. 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: Datenbelegung; Metadatenbelegung; Systembereich; Global Reserve; RAID- oder Redundanzprofil; fehlende Geräte; Snapshots und Subvolumes; geschätzter freier Speicher. 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: Poolkapazität; Dataset-Quota; Reservation und Refreservation; Snapshotbelegung; Kinder-Datasets; tatsächlich verfügbarer Speicher; Poolzustand. 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}}' \ Zu prüfen sind: Docker-Root-Dateisystem; beschreibbare Container-Layer; Images; gestoppte Container; Build-Cache; benannte und anonyme Volumes; Bind-Mounts; Containerprotokolle; Anwendungscaches; Datenbanken in Volumes; fehlende Logrotation. 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 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 \ \ -n 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: beschreibbare Container-Layer; emptyDir -Volumes; Node- und Containerprotokolle; Image-Speicher; temporäre Anwendungsdaten. 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: Besitzer der Daten; Erstellungs- und Änderungszeit; Wachstum pro Stunde oder Tag; vorgesehene Retention; aktive Prozesse; Abhängigkeit zu laufenden Diensten; Backupstatus; Replikationsstatus; Wiederherstellungsbedarf; Datenschutz und Aufbewahrungspflichten. 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: eingebundener Pfad; verwendetes Protokoll; Server oder Storageziel; Share- oder Exportname; LUN; Dateisystem; Storage Pool; Volume; Snapshotbestand; Benutzer- oder Verzeichnisquota; Thin-Provisioning-Kapazität; Replikations- und Reservebereiche; tatsächlich freier physischer Speicher. Mögliche Sonderfälle: nur eine Freigabequota ist erreicht; ein einzelner Benutzer hat sein Limit erreicht; das NAS-Volume ist voll, der Storage Pool aber nicht; der Pool ist voll, obwohl das Volume noch logischen Speicher meldet; Snapshots verhindern die Freigabe gelöschter Daten; eine Thin-LUN ist logisch größer als der physisch verfügbare Pool; das Dateisystem wurde wegen Backendfehlern schreibgeschützt; ein nicht eingebundenes Netzwerkziel führte zu lokalen Schreibvorgängen. 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/ 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: vermutete Ursache; betroffene Speicherebene; erwarteten Messwert; möglichen Gegenbeweis; sichere Testmethode; Risiko; Erfolgskriterium. 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: Ausgangszustand; betroffener Pfad; aktuelle Belegung; erwartete Freigabe; Datenverantwortlicher; Backupstatus; Freigabe; Risiko; Rückweg; Erfolgskriterium. 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= 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 Fehlermeldung vollständig aufnehmen Wortlaut, Anwendung, Benutzer und Zeitpunkt dokumentieren. Betroffenen Pfad bestimmen Exakten Datei-, Volume-, Mount- oder Containerpfad erfassen. Auswirkung bestimmen Einzelne Anwendung, Benutzer, Host oder Standort unterscheiden. Schreibtest nicht unkontrolliert wiederholen Zusätzliche Schreibvorgänge können die Lage verschärfen. Speicherebene bestimmen Anwendung, Container, Dateisystem, Volume, Pool und Backend zuordnen. Gesamtkapazität und freien Speicher erfassen Werte in Prozent und absoluten Größen dokumentieren. Inodes prüfen Besonders bei vielen kleinen Dateien. Quotas prüfen Benutzer-, Gruppen-, Projekt-, Verzeichnis- und Anwendungsquotas unterscheiden. Schreibschutz prüfen Read-only-Mount oder Dateisystemfehler ausschließen. Speicherpool prüfen RAID, LVM, Thin Pool, Storage Spaces, NAS oder SAN berücksichtigen. Snapshots prüfen VSS, APFS, Btrfs, ZFS, Hypervisor und Storage-Snapshots erfassen. Wachstumsrate bestimmen Aktuelle Werte mit Monitoring oder früheren Messungen vergleichen. Große Verzeichnisse eingrenzen Suche auf das betroffene Dateisystem beschränken. Große Dateien bestimmen Besitzer, Zweck und Änderungszeit dokumentieren. Viele kleine Dateien berücksichtigen Inodeverbrauch und Dateianzahl untersuchen. Gelöschte offene Dateien prüfen Besonders nach manueller Loglöschung. Protokolle und Rotation prüfen Fehlerschleifen, Debugmodus und Retention untersuchen. Datenbanken prüfen Daten-, Transaktions-, WAL- und Temp-Bereiche unterscheiden. Backupdaten prüfen Retention, abgebrochene Jobs und doppelte Sicherungen untersuchen. Containerdaten prüfen Images, Layer, Volumes, Bind-Mounts und Logs unterscheiden. Kubernetes-Ephemeralspeicher prüfen Nodefs, Imagefs, Inodes, Limits und Evictions auswerten. Betriebssystembereiche prüfen Updates, Dumps, Cache, temporäre Dateien und Papierkorb untersuchen. Hardware- und I/O-Fehler prüfen Ereignisse, Kernelmeldungen und Storagezustand korrelieren. Hypothese und Gegenbeweis formulieren Ursache vor jeder Änderung messbar beschreiben. Akutes Wachstum kontrollieren Verursachenden Schreibprozess nur mit Freigabe drosseln oder stoppen. Minimale sichere Entlastung planen Nur bestätigte, entbehrliche Daten auswählen. Eine Maßnahme durchführen Nicht mehrere Variablen gleichzeitig verändern. Freien Speicher erneut messen Absoluten Wert und Prozentwert dokumentieren. Ursprünglichen Schreibvorgang testen Anwendung und nicht nur Diagnosewerkzeug prüfen. Weitere Ebenen verifizieren Pool, Volume, Dateisystem und Anwendung erneut kontrollieren. Wachstum weiter beobachten Prüfen, ob der Speicher sofort wieder abnimmt. Dauerhafte Ursache beheben Rotation, Retention, Quota, Kapazität oder Anwendung korrigieren. Monitoring verbessern Prozentwert, freien Absolutwert, Inodes und Wachstumsrate überwachen. 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 Nur den prozentualen Wert betrachten. Den absolut freien Speicher nicht dokumentieren. Inodes nicht prüfen. Quotas nicht berücksichtigen. Anwendungspfad und tatsächliches Dateisystem verwechseln. Ein nicht eingebundenes Ziel übersehen. df und du als identische Messungen behandeln. Fehlende Berechtigungen bei rekursiven Suchen ignorieren. Gelöschte offene Dateien übersehen. Snapshots und Shadow Copies ignorieren. Thin Provisioning nur im Gastbetriebssystem prüfen. Container-Layer und Volume verwechseln. PVC-Größe mit freiem Speicher gleichsetzen. Protokolldatei löschen, ohne den schreibenden Prozess zu prüfen. Aktive Datenbankprotokolle manuell löschen. Docker-Volumes pauschal bereinigen. Alle Snapshots vorsorglich entfernen. Storagepool und Dateisystem gleichzeitig verändern. Mehrere Bereinigungen gleichzeitig ausführen. Keine Messung vor und nach der Maßnahme durchführen. Einen Neustart als Speicherbereinigung verwenden. Schreibschutz als reinen Kapazitätsfehler behandeln. Hardwarefehler nach einer kurzfristigen Speicherfreigabe ignorieren. Nur Platz freigeben, aber die Wachstumsursache nicht beheben. Keine zukünftige Kapazitäts- und Retentionsplanung festlegen. 7.13.37 Verifikation Nach der Maßnahme müssen mindestens folgende Punkte geprüft werden: betroffener Pfad liegt auf dem erwarteten Dateisystem; Dateisystem ist schreibbar; ausreichender absoluter Speicher ist verfügbar; prozentuale Auslastung liegt im vorgesehenen Bereich; Inodes sind verfügbar; wirksame Quotas sind korrekt; Thin Pool besitzt freie Daten- und Metadatenkapazität; Storage Pool und Backend besitzen Reserve; Snapshots entsprechen der vorgesehenen Retention; keine gelöschten großen Dateien werden weiterhin offengehalten; Logrotation funktioniert; Anwendung erzeugt keine unkontrollierte Datenmenge mehr; Container startet ohne Neustartschleife; Kubernetes-Node zeigt keinen DiskPressure ; Datenbank schreibt fehlerfrei; Backup- und Replikationsdienste funktionieren; keine neuen Dateisystem- oder I/O-Fehler erscheinen; ursprünglicher Schreibvorgang funktioniert; Wachstumsrate bleibt nach der Maßnahme kontrolliert; Monitoring löst korrekt aus; temporäre Änderungen wurden zurückgenommen; Ursache und Prävention wurden dokumentiert. Ein einzelner erfolgreicher Schreibtest reicht nicht aus, wenn der Speicher weiterhin unkontrolliert wächst. 7.13.38 Prävention und Monitoring Zu überwachen sind: prozentuale Dateisystembelegung; absolut freier Speicher; Inodebelegung; Wachstum pro Stunde und Tag; Quotaauslastung; Snapshotbelegung; Thin-Pool-Datenbereich; Thin-Pool-Metadatenbereich; Container- und Imagebelegung; Kubernetes nodefs und imagefs ; Backuprepository; Datenbank- und Transaktionslogs; Protokollverzeichnisse; Storagepoolkapazität; Hardware- und I/O-Fehler. 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: Kapazitätsprognosen erstellen; Retention verbindlich dokumentieren; Logrotation regelmäßig testen; Quotas mit Warnschwellen verwenden; Snapshotlebenszyklen überwachen; Thin Provisioning nicht überbuchen, ohne das Backend zu überwachen; Containerlogs begrenzen; Ephemeral-Storage-Requests und -Limits planen; Backuprepository und Produktionsdaten getrennt überwachen; Restore- und Bereinigungsvorgänge testen; Eigentümer für speicherintensive Pfade festlegen. 7.13.39 Dokumentationsvorlage Störung: Zeitpunkt: Betroffenes System: Betroffene Anwendung: Betroffener Pfad: Speicherebenen: Dateisystem: Gesamtkapazität: Freier Speicher vor der Maßnahme: Inodebelegung: Wirksame Quota: Snapshotbelegung: Thin-Pool-Auslastung: Wachstumsrate: Größte Verbraucher: Gelöschte offene Dateien: Storage- und Hardwarezustand: Nachgewiesene Ursache: Gegenbeweis ausgeschlossen durch: Durchgeführte Maßnahme: Risiko und Rückweg: Freier Speicher nach der Maßnahme: Verifikation: Prävention: 7.13.40 Checkliste exakte Fehlermeldung dokumentiert Datum und Uhrzeit erfasst betroffenen Host erfasst betroffene Anwendung erfasst betroffenen Benutzer erfasst exakten Schreibpfad bestimmt Dateisystem des Pfades bestimmt Mountpoint oder Laufwerksbuchstabe bestätigt Gesamtkapazität dokumentiert absolut freien Speicher dokumentiert prozentuale Auslastung dokumentiert Inodes geprüft Benutzerquota geprüft Gruppenquota geprüft Projekt- oder Verzeichnisquota geprüft Anwendungsquota geprüft Schreibschutz geprüft Mountoptionen geprüft Partition oder Logical Volume geprüft Volume Group oder Speicherpool geprüft Thin-Pool-Datenbereich geprüft Thin-Pool-Metadatenbereich geprüft RAID-, NAS- oder SAN-Kapazität geprüft Snapshots geprüft Shadow Copies geprüft größte Verzeichnisse bestimmt größte Dateien bestimmt Änderungszeiten geprüft Datenbesitzer bestimmt Wachstumsrate bestimmt viele kleine Dateien berücksichtigt df und du verglichen gelöschte offene Dateien geprüft Protokollwachstum geprüft Logrotation geprüft Datenbanklogs geprüft Backupretention geprüft Container-Layer geprüft Container-Volumes geprüft Containerlogs geprüft Kubernetes DiskPressure geprüft Ephemeral Storage geprüft PVC und Backend getrennt geprüft System- und Kernelprotokolle geprüft Hardware- und I/O-Fehler geprüft Hypothese formuliert Gegenbeweis festgelegt Risiko und Rückweg dokumentiert Datenverantwortlicher einbezogen nur eine kontrollierte Maßnahme durchgeführt freien Speicher erneut gemessen Inodes erneut geprüft Quota erneut geprüft ursprünglichen Schreibvorgang getestet ursprüngliche Anwendung getestet Wachstumsrate nachkontrolliert Monitoring geprüft temporäre Änderungen zurückgenommen Ursache dokumentiert Präventionsmaßnahme festgelegt 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 Linux-Inodes df -i Mounts findmnt Mount eines Pfades findmnt --target Blockgeräte lsblk -o NAME,TYPE,FSTYPE,SIZE,FSAVAIL,FSUSE%,MOUNTPOINTS Verzeichnisgrößen du -x -h --max-depth=1 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' 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 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 Kubernetes-PVCs kubectl get pvc --all-namespaces 7.13.42 Quellen Offizielle Microsoft-Dokumentation Microsoft Learn – Get-Volume Microsoft Learn – Get-Disk Microsoft Learn – Get-PhysicalDisk Microsoft Learn – Get-PSDrive Microsoft Learn – Get-FsrmQuota Microsoft Learn – FileServerResourceManager PowerShell module Microsoft Learn – Vssadmin list shadowstorage Microsoft Learn – Determine the actual size of the WinSxS folder Microsoft Learn – Clean up the WinSxS folder Microsoft Learn – Configure Storage Sense Offizielle Linux- und Projektdokumentation GNU Coreutils – df invocation GNU Coreutils – du invocation systemd – journalctl systemd – journald.conf Linux Kernel – ext4 documentation Red Hat – Disk Quotas Red Hat – Limiting XFS storage usage with quotas Btrfs – btrfs-filesystem documentation OpenZFS – zfs-list documentation Offizielle Docker-Dokumentation Docker Docs – docker system df Docker Docs – Prune unused Docker objects Docker Docs – docker system prune Docker Docs – docker volume prune Offizielle Kubernetes-Dokumentation Kubernetes – Local ephemeral storage Kubernetes – Node-pressure eviction Kubernetes – Ephemeral volumes Offizielle Apple-Dokumentation Apple – Get detailed information about a disk Apple – Add, delete or erase APFS volumes Apple – View APFS snapshots Apple – Repair a storage device 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: DNS-, Netzwerk-, TCP-, TLS- und HTTP-Fehler voneinander trennen; den tatsächlich verwendeten Zielhost und Port bestimmen; Zertifikatsname, Gültigkeit, Vertrauenskette und Sperrstatus prüfen; TLS-Versionen, Cipher Suites, SNI und ALPN untersuchen; Serverauthentifizierung und gegenseitige TLS-Authentifizierung unterscheiden; Proxy, TLS-Inspection, Reverse Proxy und Load Balancer berücksichtigen; client-, server- und anwendungsspezifische Truststores vergleichen; eine kontrollierte Maßnahme mit anschließender Verifikation durchführen. 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: Private Schlüssel niemals in Tickets, Chats oder Diagnoseausgaben kopieren. Private Schlüssel nicht per E-Mail oder ungeschützt übertragen. curl -k beziehungsweise --insecure nicht als dauerhafte Lösung verwenden. Zertifikatsprüfung nicht deaktivieren, um einen Fehler zu verdecken. Keine veralteten TLS-Versionen dauerhaft aktivieren. Keine CA-Zertifikate ungeprüft als vertrauenswürdig importieren. Bestehende Zertifikatsbindungen vor Änderungen dokumentieren. Bei Zertifikatswechseln immer Rückweg und Schlüsselzuordnung prüfen. Diagnoseausgaben vor Weitergabe auf Tokens, Cookies, Header und interne Namen prüfen. Netzwerkaufzeichnungen und TLS-Schlüsselprotokolle besonders schützen. 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: vollständige URL; verwendeter FQDN; Port; Client-IP-Adresse; Ziel-IP-Adresse; Zeitpunkt; betroffene Anwendung; Betriebssystem und Version; Browser- oder Anwendungsversion; Proxy- und VPN-Zustand; erwarteter Zertifikatsaussteller; erwarteter Reverse Proxy oder Load Balancer; funktioniert HTTP ohne TLS? funktioniert die Verbindung von anderen Clients? funktioniert sie aus anderen Netzen? trat der Fehler nach einer Änderung auf? wurde kürzlich ein Zertifikat erneuert? ist mTLS vorgesehen? handelt es sich um öffentliches oder internes PKI-Vertrauen? 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: richtige IPv4-Adresse; richtige IPv6-Adresse; internes oder öffentliches DNS; Split-DNS; VPN-DNS; CNAME-Kette; mehrere Zieladressen; veralteter Cache; CDN- oder Load-Balancer-Ziel; Hosts-Datei; DNS-Suffixe; Anwendung mit eigenem Resolver. 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: IPv4 funktioniert, IPv6 schlägt fehl; einzelne IPv4-Adresse liefert ein falsches Zertifikat; nur ein Load-Balancer-Node ist fehlerhaft; IPv6 führt zu einem anderen Reverse Proxy; DNS liefert eine veraltete Adresse. 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: Datum; Uhrzeit; Zeitzone; UTC-Abweichung; NTP-Quelle; Synchronisationsstatus; virtuelle Maschine mit fehlerhafter Hostzeitsynchronisation; Containerzeit; Domänenzeit; kürzlich geänderte Uhr. 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: verwendete Zieladresse; Proxyverwendung; TLS-Version; Cipher Suite; Zertifikatsbetreff; Zertifikatsaussteller; ALPN-Ergebnis; HTTP-Anfrage; HTTP-Statuscode; Redirect; Verbindungsabbruch. 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: den geprüften Zertifikatsnamen; SNI; HTTP-Hostheader; Auswahl des virtuellen Hosts. Deshalb sollte curl --resolve verwendet werden: curl \ -v \ --resolve \ app.example.test:443:192.0.2.25 \ https://app.example.test/ Damit bleiben erhalten: URL-Hostname; SNI; Zertifikatsnamenprüfung; HTTP-Hostheader. Nur die Ziel-IP-Adresse wird für den Test festgelegt. Dies ist besonders nützlich bei: mehreren Load-Balancer-Nodes; DNS-Umstellungen; fehlerhaftem Caching; Blue-Green-Deployments; alten und neuen Reverse Proxys; einzelnen fehlerhaften Backendpfaden. 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 \ Zu prüfen sind: tatsächlich verwendete Java-Version; java.home ; Truststorepfad; Truststoreformat; Truststorepasswort; Root- und Intermediate-CA; Zertifikatsalias; Gültigkeitszeitraum; Anwendung mit eigenem Truststore; Container besitzt anderen Java-Truststore; JVM-Startparameter; alte JVM ohne aktuelle CA-Liste. 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: DNS-Konfigurationen; Proxyvariablen; Systemzeiten; CA-Bundles; OpenSSL-Versionen; TLS-Bibliotheken; Java-Truststores; IPv4- oder IPv6-Pfade; Zertifikatsdateien. Containerkonfiguration: docker inspect \ Proxyvariablen: docker exec \ \ env Zeit im Container: docker exec \ \ date -u Falls curl im Image vorhanden ist: docker exec \ \ 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: Dateipfad; Dateiberechtigungen; Dateibesitzer; Verschlüsselung des Schlüssels; Kennwortzugriff; Dienstkonto; Hardware Security Module; Secret- oder Vault-Bereitstellung; Zertifikatsbindung; tatsächlich geladene Datei. 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: listen 443 ssl ; richtiger virtueller Host; server_name ; Zertifikatspfad; Schlüsselpfad; vollständige Zertifikatskette; Dateiberechtigungen; SNI; TLS-Protokolle; Cipher-Konfiguration; Clientzertifikatsanforderung; OCSP-Konfiguration; Reverse-Proxy-Backend; Backend-SNI; Backend-Zertifikatsprüfung; kontrollierter Reload nach Änderung. 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: SSL-Modul; virtueller Host; Port und Listener; ServerName ; Zertifikatsdatei; Schlüsseldatei; Zertifikatskette; Dateiberechtigungen; TLS-Versionen; Cipher; Clientzertifikate; Proxy zum Backend; Protokolle; kontrollierter Reload. 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: IP-Adresse; Port; Hostname; SNI-Einstellung; Zertifikat-Thumbprint; Zertifikatsspeicher; privater Schlüssel; Berechtigung des Dienstkontos; abgelaufenes Zertifikat; falsche Bindung; mehrere Sites auf demselben Listener; zentrale Zertifikatsspeicherung; Clientzertifikatsanforderung. 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: Zielhostname; Ziel-IP-Adresse; Port; SNI; Zertifikatsname; ausstellende CA; Truststore; TLS-Version; Cipher; Clientzertifikat; Healthcheck; Timeout; Backendstatus. Typische Fehler: Frontendzertifikat korrekt, Backendzertifikat abgelaufen; Load Balancer sendet falsches SNI; Backendzertifikat gilt nicht für den internen Namen; Proxy vertraut der internen CA nicht; Healthcheck verwendet HTTP statt HTTPS; Healthcheck verwendet IP-Adresse statt FQDN; Backend erwartet mTLS; nur ein Load-Balancer-Node besitzt das neue Zertifikat; Zertifikatsverteilung ist unvollständig; Proxy prüft Backendzertifikat nicht oder mit falschem Namen. 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: Redirect auf anderen Hostnamen; Redirect auf abgelaufenes Zertifikat; Wechsel zwischen internem und öffentlichem Namen; HTTP-zu-HTTPS-Schleife; falscher Port; falsches Schema; Proxyheader; Hostheader; Backendstatus; Anwendungspfad. 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: ob TCP aufgebaut wird; wer die Verbindung beendet; ob ein Reset erscheint; welches Ziel angesprochen wird; ob Retransmissions auftreten; ob ein TLS ClientHello gesendet wird; welche TLS-Versionen angeboten werden; ob SNI übermittelt wird; ob ein TLS Alert erscheint; ob der Server antwortet; ob mehrere Verbindungsversuche erfolgen; ob ein Proxy beteiligt ist. 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: betroffene Verbindungsebene; vermutete Ursache; erwarteten messbaren Befund; Gegenbeweis; Testmethode; Risiko; Erfolgskriterium. 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: Ausgangszustand; aktives Zertifikat; SHA-256-Fingerprint; Zertifikatsbindung; Servername; SNI; TLS-Version; Cipher; Truststore; Proxyweg; Risiko; Rückweg; Erfolgskriterium. 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 Exakte Fehlermeldung aufnehmen Wortlaut, Anwendung, Client und Uhrzeit dokumentieren. Vollständige URL bestimmen Schema, FQDN, Port und Pfad erfassen. Fehlerumfang bestimmen Einzelnen Client, Anwendung, Standort oder alle Benutzer unterscheiden. Letzte Änderungen erfassen Zertifikatswechsel, Update, Proxy-, DNS- oder Firewalländerung prüfen. Systemzeit prüfen Datum, UTC, Zeitzone und Synchronisation bestätigen. DNS-Auflösung prüfen A, AAAA und CNAME auswerten. Tatsächliche Zieladresse bestimmen IPv4, IPv6, Load Balancer oder Proxy identifizieren. TCP-Port prüfen Timeout, Ablehnung und erfolgreichen Handshake unterscheiden. Proxyweg bestimmen Direktverbindung, expliziten Proxy, PAC oder TLS-Inspection unterscheiden. Normalen HTTPS-Test durchführen Zertifikatsprüfung nicht deaktivieren. TLS und HTTP trennen Handshakefehler und HTTP-Statuscode unterscheiden. OpenSSL-Handshake durchführen SNI und Hostnamenprüfung ausdrücklich angeben. TLS-Version dokumentieren Ausgehandelte Version erfassen. Cipher dokumentieren Ausgehandelte Cipher Suite erfassen. ALPN dokumentieren HTTP/1.1, HTTP/2 oder anderes Protokoll bestimmen. Serverzertifikat dokumentieren Subject, Issuer, Seriennummer und Fingerprint erfassen. SAN prüfen Aufgerufenen FQDN mit Zertifikat vergleichen. Gültigkeitszeitraum prüfen Server- und Intermediate-Zertifikate berücksichtigen. Zertifikatskette prüfen Fehlende oder falsche Intermediate-CA bestimmen. Root-Vertrauen prüfen Tatsächlichen Truststore der Anwendung untersuchen. Sperrprüfung prüfen CRL, OCSP, AIA und Netzwerkzugriff berücksichtigen. SNI prüfen Test mit und ohne vorgesehenen Servernamen vergleichen. Einzelne Zieladressen prüfen Load-Balancer-Nodes mit --resolve vergleichen. IPv4 und IPv6 vergleichen Unterschiedliche Pfade und Zertifikate bestimmen. mTLS prüfen Clientzertifikat, Schlüssel, Kette und Serververtrauen untersuchen. TLS-Inspection prüfen Zertifikatsaussteller und Fingerprint zwischen Netzen vergleichen. Anwendungsspezifischen Truststore prüfen Betriebssystem, Browser, Java und Container unterscheiden. Serverbindung prüfen Listener, virtuellen Host, Zertifikat und Schlüssel zuordnen. Zertifikat und Schlüssel vergleichen Öffentliche Schlüssel sicher hashen. Reverse Proxy und Backend trennen Frontend- und Backend-TLS einzeln testen. Serverprotokolle auswerten Handshake, Zertifikat, mTLS und Backendfehler korrelieren. Bei Bedarf Netzwerkaufzeichnung durchführen Nur autorisiert, begrenzt und datenschutzkonform. Hypothese und Gegenbeweis formulieren Ursache vor der Änderung messbar festlegen. Eine kontrollierte Maßnahme durchführen Risiko, Rückweg und Freigabe beachten. Konfiguration vor Reload prüfen Beispielsweise nginx -t oder apachectl configtest . Identischen TLS-Test wiederholen Version, Cipher, Zertifikat und Verify-Ergebnis vergleichen. HTTP-Antwort prüfen Statuscode, Redirect und Header auswerten. Ursprüngliche Anwendung testen Nicht nur curl oder OpenSSL verifizieren. Weitere Clients und Netze prüfen Repräsentative Systeme vergleichen. Temporäre Diagnoseänderungen zurücknehmen Logging, Capture, Testzertifikate und Ausnahmen entfernen. Ursache dokumentieren Fehlerhafte Ebene und technischer Nachweis festhalten. 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 HTTPS sofort als reines Zertifikatsproblem behandeln. DNS und TCP nicht zuerst prüfen. Ping als Port- oder TLS-Nachweis verwenden. Direkten IP-Aufruf als vollständigen HTTPS-Test verwenden. SNI beim OpenSSL-Test vergessen. Hostnamenprüfung nicht ausdrücklich durchführen. Nur das Serverzertifikat, aber nicht die Kette prüfen. Nur das Ablaufdatum des Leaf-Zertifikats prüfen. Intermediate- und Root-Zertifikat verwechseln. Root-CA unnötig mit der Serverkette ausliefern. Subject prüfen, aber SAN ignorieren. Wildcard-Zertifikat zu weit auslegen. Systemzeit nicht prüfen. curl -k als Lösung verwenden. Browser und Anwendung denselben Truststore unterstellen. Benutzer- und Computerzertifikatsspeicher verwechseln. Java-Truststore ignorieren. Container-CA-Bundle ignorieren. Proxykontext des Dienstkontos nicht prüfen. TLS-Inspection nicht berücksichtigen. IPv4 und IPv6 nicht getrennt testen. Nur einen Load-Balancer-Node prüfen. Frontend- und Backend-TLS verwechseln. mTLS nicht von normalem TLS unterscheiden. Clientzertifikat ohne privaten Schlüssel verwenden. Zertifikat und privaten Schlüssel nicht zuordnen. Zertifikatsdatei ersetzen, aber Dienst nicht kontrolliert neu laden. Dienst neu starten, ohne vorher die Konfiguration zu testen. TLS-Version und Cipher Suite gleichsetzen. HTTP-Statuscode als TLS-Fehler behandeln. Sperrprüfung ohne Ursachenanalyse deaktivieren. Private Schlüssel in Diagnoseausgaben aufnehmen. Verbose Ausgaben mit Tokens oder Cookies ungeschützt weitergeben. Mehrere TLS-Einstellungen gleichzeitig verändern. Nur das Diagnosewerkzeug, aber nicht die Anwendung verifizieren. 7.14.49 Verifikation Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: DNS liefert die vorgesehenen Adressen; IPv4 und IPv6 funktionieren wie vorgesehen; TCP-Port ist erreichbar; richtiger Proxyweg wird verwendet; TLS-Handshake wird abgeschlossen; vorgesehene TLS-Version wird ausgehandelt; sichere gemeinsame Cipher Suite wird verwendet; SNI enthält den richtigen Namen; ALPN liefert das vorgesehene Protokoll; Serverzertifikat besitzt den richtigen SAN; Zertifikat ist aktuell gültig; vollständige Zertifikatskette wird geliefert; Client vertraut der vorgesehenen Root-CA; Sperrprüfung funktioniert; bei mTLS wird das richtige Clientzertifikat verwendet; privater Schlüssel ist vorhanden und geschützt; Zertifikat und Schlüssel gehören zusammen; alle Load-Balancer-Nodes liefern dasselbe Zertifikat; Reverse Proxy vertraut dem Backend; Backend-SNI ist korrekt; keine neuen Schannel-, CAPI2- oder Serverfehler entstehen; HTTP-Antwortcode entspricht dem Sollzustand; Redirects führen zum vorgesehenen Host; ursprüngliche Anwendung funktioniert; repräsentative Clients funktionieren; Container und Dienste funktionieren in ihrem tatsächlichen Kontext; temporäre Ausnahmen wurden entfernt; Fingerprint, Ablaufdatum und Erneuerungsweg wurden dokumentiert. Ein erfolgreicher Test mit deaktivierter Zertifikatsprüfung ist keine gültige Verifikation. 7.14.50 Prävention und Monitoring Zu überwachen sind: Ablaufdatum des Serverzertifikats; Ablaufdatum der Intermediate-CA; Ablaufdatum der Root-CA; Zertifikatsname und SAN; SHA-256-Fingerprint; vollständige Zertifikatskette; Erreichbarkeit des HTTPS-Endpunkts; TLS-Handshake; TLS-Version; Zertifikatsaussteller; OCSP- und CRL-Erreichbarkeit; automatische Zertifikatserneuerung; Verteilung auf alle Nodes; Reload des betroffenen Dienstes; Frontend- und Backend-TLS; mTLS-Clientzertifikate; Proxy- und Inspection-Zertifikate; Systemzeit; Konfigurationssyntax; HTTP-Statuscode und Antwortzeit. 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: Zeitpunkt: Betroffener Client: Betroffene Anwendung: URL: FQDN: Port: Aufgelöste Adressen: Verwendete Zieladresse: Proxyweg: TCP-Ergebnis: TLS-Version: Cipher Suite: SNI: <übermittelter Name> ALPN: Zertifikat-Subject: Subject Alternative Names: Issuer: Seriennummer: SHA-256-Fingerprint: Gültigkeit: Zertifikatskette: Truststore: Sperrprüfung: mTLS: Reverse-Proxy-Pfad: HTTP-Ergebnis: Nachgewiesene Ursache: Gegenbeweis ausgeschlossen durch: Durchgeführte Maßnahme: Risiko und Rückweg: Verifikation: Prävention: 7.14.52 Checkliste exakte Fehlermeldung dokumentiert Datum und Uhrzeit erfasst vollständige URL erfasst FQDN erfasst Port erfasst betroffene Anwendung erfasst Clientbetriebssystem erfasst Systemzeit geprüft Zeitzone geprüft DNS-A-Eintrag geprüft DNS-AAAA-Eintrag geprüft CNAME-Kette geprüft tatsächliche Zieladresse bestimmt IPv4 getestet IPv6 getestet TCP-Port geprüft Timeout und Ablehnung unterschieden Proxykonfiguration geprüft PAC-Datei berücksichtigt NO_PROXY berücksichtigt TLS-Inspection berücksichtigt normalen HTTPS-Test durchgeführt Zertifikatsprüfung nicht dauerhaft deaktiviert OpenSSL-Handshake durchgeführt SNI ausdrücklich angegeben Hostnamenprüfung durchgeführt TLS-Version dokumentiert Cipher Suite dokumentiert ALPN dokumentiert Serverzertifikat erfasst Subject geprüft SAN geprüft Wildcard-Gültigkeit geprüft Issuer geprüft Seriennummer dokumentiert SHA-256-Fingerprint dokumentiert Gültigkeitsbeginn geprüft Ablaufdatum geprüft Serverzertifikatskette geprüft Intermediate-CA geprüft Root-CA geprüft tatsächlichen Truststore bestimmt CRL geprüft OCSP geprüft AIA-Erreichbarkeit geprüft Sperrprüfungsrichtlinie berücksichtigt einzelne Load-Balancer-Nodes verglichen Test mit curl --resolve durchgeführt mTLS-Anforderung geprüft Clientzertifikat geprüft Client-CA-Vertrauen geprüft privater Schlüssel vorhanden Zertifikat und Schlüssel zugeordnet Windows-Schannel-Ereignisse geprüft CAPI2 bei Bedarf geprüft Windows-Zertifikatsspeicher geprüft Linux- oder macOS-Truststore geprüft Java-Truststore bei Bedarf geprüft Container-Truststore bei Bedarf geprüft Reverse-Proxy-Frontend geprüft Reverse-Proxy-Backend geprüft Backend-SNI geprüft Webserverkonfiguration getestet Serverprotokolle ausgewertet HTTP-Statuscode dokumentiert Redirects geprüft Hypothese formuliert Gegenbeweis festgelegt Risiko und Rückweg dokumentiert nur eine kontrollierte Maßnahme durchgeführt identischen TLS-Test wiederholt ursprüngliche Anwendung getestet weitere Clients geprüft alle Load-Balancer-Nodes geprüft temporäre Ausnahmen entfernt sensible Diagnoseinformationen geschützt Ursache dokumentiert Präventionsmaßnahme festgelegt 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 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 Microsoft Learn – Overview of TLS and Schannel SSP Microsoft Learn – TLS registry settings Microsoft Learn – Troubleshooting SSL-related IIS server-certificate issues Microsoft Learn – Certificate Provider Microsoft Learn – Certutil Microsoft Learn – Valid root CA certificates are untrusted Microsoft Learn – Diagnostic logging for PKI and SSL certificate issues Offizielle OpenSSL-Dokumentation OpenSSL – s_client OpenSSL – x509 OpenSSL – verify OpenSSL – Certificate verification options OpenSSL – Command overview Offizielle curl-Dokumentation curl – Command-line manual curl – TLS certificate verification curl – SSL ciphers curl – Tutorial curl – HTTP scripting Offizielle Webserver-Dokumentation Nginx – Configuring HTTPS servers Nginx – HTTP SSL module Nginx – HTTP proxy module Apache HTTP Server – Configuration files and configtest Apache HTTP Server – apachectl Offizielle Java-Dokumentation Oracle – keytool Oracle – JSSE Reference Guide Offizielle Wireshark-Dokumentation Wireshark – User’s Guide Wireshark – TShark manual Wireshark – Exporting TLS session keys Standards RFC 5280 – Internet X.509 Public Key Infrastructure Certificate and CRL Profile RFC 6066 – TLS Extensions: Server Name Indication RFC 7301 – TLS Application-Layer Protocol Negotiation RFC 8446 – TLS 1.3 RFC 9110 – HTTP Semantics RFC 9113 – HTTP/2 RFC 9325 – Recommendations for Secure Use of TLS and DTLS RFC 9525 – Service Identity in TLS 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: nicht gestartet wurde; abgebrochen ist; nur teilweise erfolgreich war; kein verwendbares Recovery Point erzeugt hat; ein inkonsistentes Backup erstellt hat; das Zielrepository nicht erreichen konnte; wegen Snapshot-, VSS-, Netzwerk-, Kapazitäts- oder Berechtigungsfehlern gescheitert ist; als erfolgreich angezeigt wird, dessen Daten aber nicht wiederhergestellt werden können. Ziele der Diagnose: den betroffenen Job und Sicherungszeitraum bestimmen; Scheduler-, Quell-, Snapshot-, Transport- und Zielfehler unterscheiden; Voll-, inkrementelle und differenzielle Sicherungsketten prüfen; Repository, Retention, Verschlüsselung und Unveränderbarkeit berücksichtigen; anwendungskonsistente Backups sicherstellen; die Wiederherstellbarkeit durch einen kontrollierten Restore-Test nachweisen; RPO und RTO bewerten; erneute Backupfehler verhindern. 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: Fehlgeschlagene Jobs, Protokolle und Statusdaten zuerst dokumentieren. VSS-Writer unmittelbar nach dem Fehler prüfen, bevor Dienste neu gestartet werden. Keine Recovery Points löschen, um kurzfristig Speicher freizugeben. Repositorys nicht ungeprüft entsperren. Retention oder Pruning nicht spontan verändern. Keine privaten Schlüssel, Repositorypasswörter oder Tokens in Diagnoseausgaben aufnehmen. Eine beschädigte Sicherungskette nicht durch manuelle Dateiänderungen „reparieren“. Produktive Datenbanken nicht durch unkoordinierte Dateikopien sichern. Restore-Tests nur in einem isolierten Ziel durchführen. Bei Ransomwareverdacht die Sicherungsumgebung nicht unkontrolliert verändern. 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: „Job erfolgreich“; vorhandene Backupdatei; belegter Speicher im Repository; vorhandener Snapshot; erfolgreiche Datenübertragung; gültige Prüfsumme einer einzelnen Datei; erfolgreiches Einlesen des Katalogs. 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 Fehlermeldung vollständig dokumentieren. Job-ID, Jobname und Sicherungsprodukt erfassen. Start- und Endzeit bestimmen. Letzten erfolgreichen Recovery Point feststellen. Betroffene Quellen und Ziele bestimmen. RPO-Verletzung berechnen. Aktuelle Logs und Ereignisse sichern. Snapshot- oder VSS-Zustand prüfen. Repository nicht bereinigen oder entsperren. Prüfen, ob noch ein Job aktiv ist. Kapazität und Quota erfassen. Bei Sicherheitsverdacht Backupserver und Repository schützen. Ursache nachweisen, bevor der Job erneut gestartet wird. Nach der Korrektur einen kontrollierten neuen Lauf durchführen. Wiederherstellbarkeit des neuen Recovery Points testen. Wiederholte Neustarts eines Backupjobs können: zusätzliche Snapshots erzeugen; Repositorylocks verursachen; Backupfenster überschreiten; Bandbreite und Storage belasten; fehlerhafte inkrementelle Ketten verlängern; verwertbare Beweise überschreiben. 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: letzter erfolgreicher Job; letzter erfolgreich verifizierter Recovery Point; letzter extern replizierter Recovery Point; letzter Restore-Test; aktueller Zeitpunkt; Änderungsrate der Produktivdaten; maximal tolerierbarer Datenverlust; Priorität des betroffenen Systems. 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 "" Laufzeitinformationen: Get-ScheduledTask ` -TaskName "" | Get-ScheduledTaskInfo Wichtige Felder: State LastRunTime LastTaskResult NextRunTime NumberOfMissedRuns Detaillierte Abfrage mit schtasks : schtasks /query /tn "" /v /fo LIST /hresult Zu prüfen sind: Task aktiviert; richtiger Trigger; letzte Laufzeit; nächster Lauf; verpasste Läufe; letzter Rückgabecode; ausführendes Konto; „Unabhängig von der Benutzeranmeldung ausführen“; „Mit höchsten Privilegien ausführen“; Recht „Anmelden als Stapelverarbeitungsauftrag“; Arbeitsverzeichnis; Argumente; Netzwerkverfügbarkeit; Ablauf des Kennworts; geändertes Dienstkonto; Laufzeitbegrenzung; parallele Ausführung; Verhalten nach verpasstem Start. 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: Triggerzeit; Start der Aktion; Prozess-ID; Rückgabecode; Abbruch; Zeitüberschreitung; Berechtigungsfehler; fehlender Benutzerkontext; mehrfacher Jobstart; Beendigung durch Task Scheduler. 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: Timer aktiviert; Timer tatsächlich geladen; letzter und nächster Lauf; OnCalendar ; Persistent ; zufällige Verzögerung; zugehörige Service-Unit; Exit-Code; Timeout; Benutzerkontext; Umgebungsvariablen; Arbeitsverzeichnis; Netzwerkabhängigkeiten; Secretbereitstellung; paralleler Lauf; System war zum geplanten Zeitpunkt ausgeschaltet. 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: richtiger Benutzer; korrekte Zeitangabe; Zeitzone; vollständige Programmpfade; reduzierte PATH -Variable; Arbeitsverzeichnis; Shell; Standardausgabe und Fehlerausgabe; Zugangsdaten; gemountete Dateisysteme; parallele Prozesse; Exit-Code; Job wurde durch einen anderen Lauf blockiert; Server war ausgeschaltet. Ein Skript, das in einer interaktiven Shell funktioniert, muss nicht unter Cron funktionieren. 7.15.14 Quelle und Sicherungsumfang prüfen Zu erfassen sind: vorgesehene Quellen; tatsächlich eingeschlossene Quellen; Ausschlüsse; Dateisystemgrenzen; Mountpoints; Volumes; virtuelle Maschinen; Container-Volumes; Datenbanken; Systemzustand; Anwendungsdaten; Konfigurationen; Secrets; Zertifikate; Berechtigungen und ACLs. Linux-Mounts: findmnt lsblk \ -o NAME,TYPE,FSTYPE,SIZE,FSAVAIL,FSUSE%,MOUNTPOINTS Windows-Volumes: Get-Volume Datei- oder Verzeichnisexistenz: Test-Path ` -LiteralPath "" Mögliche Fehler: Mount fehlt und leeres Verzeichnis wird gesichert; Laufwerksbuchstabe hat sich geändert; neue Partition wurde nicht in den Job aufgenommen; Ausschlussregel ist zu breit; symbolischer Link wird nicht verfolgt; Dateisystemgrenze wird nicht überschritten; Containerdaten liegen in einem anderen Volume; neuer Datenbankpfad fehlt; verschlüsseltes Volume ist nicht entsperrt; Quelldateien werden durch eine Anwendung gesperrt; Dienstkonto darf neue Verzeichnisse nicht lesen. 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: freier Speicher auf der Quelle; temporärer Snapshotbereich; Cache- und Stagingbereich; Repositorykapazität; Dateisystem-Inodes; Benutzer- oder Verzeichnisquota; Object-Storage-Quota; Cloudkontingent; Thin Pool; Deduplizierungsmetadaten; Katalogdatenbank; Logvolume; sekundäres Replikationsziel. 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: vorhandene Recovery Points; Jobstatus; Sicherungsziel; Quellvolumes; System-State-Komponenten; VSS-Fehler; Zielkapazität; Zugriff auf Netzwerkziel; Berechtigungen; Datenträgerstatus; Katalog; Ausschlüsse; parallele Sicherungssoftware. 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: Name des fehlgeschlagenen Writers; Writer-ID; Writer-Instanz-ID; Writerzustand; letzter Fehler; betroffene Anwendung; VSS-Provider; Shadow-Copy-Speicher; freier Speicher; parallele Backupsoftware; Zeitüberschreitung; Systemlast; Anwendung mit eigenem Writer; Datenbank- oder Hypervisorintegration. 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: Anwendung unterstützt Snapshotkoordination; Writer oder Hook wurde ausgeführt; Datenbank wurde gequiesced; Transaktionslogs sind enthalten; WAL-, Redo- oder Binärlogs sind verfügbar; Snapshot wurde korrekt aufgelöst; Hypervisor-Snapshot wurde konsolidiert; Storage-Snapshot wurde repliziert; mehrere Volumes wurden gleichzeitig konsistent erfasst; Restoreverfahren ist dokumentiert. 7.15.19 Netzwerkpfad zum Repository prüfen Zu bestimmen sind: Repositoryhostname; Ziel-IP-Adresse; Port; Protokoll; Proxy; VPN; Routing; Firewall; DNS; TLS; Netzwerkfreigabe; Objektstorage-Endpunkt; Backup-Gateway oder Proxyserver. Windows Resolve-DnsName ` -Name "" Test-NetConnection ` -ComputerName "" ` -Port SMB-Verbindungen: Get-SmbConnection Linux und macOS getent hosts findmnt HTTPS-Endpunkt: curl \ -v \ https:/// TLS-Test: openssl s_client \ -connect : \ -servername \ Wichtige Regeln: forget verändert Snapshotreferenzen; prune entfernt nicht mehr referenzierte Daten; prune kann lange dauern; während Wartungsvorgängen kann das Repository gesperrt sein; ein Lock darf nicht automatisch mit unlock entfernt werden; nach Pruning ist eine Integritätsprüfung sinnvoll; beschädigte Snapshots dürfen nicht ohne vorherige Sicherung und Ursachenanalyse repariert werden. 7.15.26 Rsync-Job prüfen Version: rsync --version Trockenlauf: LESEND, NETZAKTIV, möglicherweise LASTERZEUGEND rsync \ --dry-run \ --itemize-changes \ \ 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: vollständige Quelle und Ziel; SSH- oder Daemonverbindung; Berechtigungen; Eigentümer und Gruppen; ACLs; erweiterte Attribute; Hardlinks; Sparse Files; symbolische Links; Dateisystemgrenzen; Ausschlüsse; teilweise Übertragungen; gelöschte Quelldateien; Protokollausgabe; Exit-Code; verwendete Optionen. 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 "" Zu prüfen sind: Backupziel angeschlossen; Netzwerkziel erreichbar; Volume eingebunden; freier Speicher auf Quelle und Ziel; Verschlüsselungskennwort verfügbar; VPN oder Sicherheitssoftware beeinflusst Verbindung; Backupvolume unterstützt; lokale Snapshots; beschädigtes Backup; häufig geänderte große Dateien; Synchronisationsdienst blockiert Dateien; Mac ist entsperrt; Stromversorgung; Ruhezustand; aktuelle macOS-Version. 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 \ Containermounts: docker inspect \ --format '{{json .Mounts}}' \ Zu unterscheiden sind: Containerimage; beschreibbarer Container-Layer; benanntes Volume; anonymes Volume; Bind-Mount; externe Datenbank; Docker-Compose-Konfiguration; Secrets; Umgebungsvariablen; Zertifikate; Netzwerk- und Proxykonfiguration. Wichtige Regeln: docker export sichert keine eingebundenen Volumes. docker commit sichert keine Daten in eingebundenen Volumes. Daten in Volumes müssen separat gesichert werden. Eine Kopie eines aktiven Datenbankvolumes ist nicht automatisch anwendungskonsistent. Compose-Datei, Umgebungsvariablen und Secrets müssen getrennt und sicher berücksichtigt werden. Direktes Manipulieren der Daten unter dem Docker-Datenverzeichnis ist nicht unterstützt und kann Daten beschädigen. Vor dem Backup einer Datenbank muss deren vorgesehenes Sicherungsverfahren verwendet werden. 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 \ \ -n Podlogs: kubectl logs \ job/ \ -n 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: CronJob ausgesetzt; letzter Zeitplan; fehlgeschlagene Jobs; Pod-Exit-Code; BackoffLimit; aktive Deadline; ServiceAccount; RBAC; Secret; Repositoryzugriff; PVC-Mount; CSI-Treiber; VolumeSnapshotClass; readyToUse ; Snapshotfehler; Node-Druck; Ephemeral Storage; Netzwerkpolicy; externe Datenbank; S3- oder Object-Storage-Zugang; Aufbewahrung alter Jobs. Ein Kubernetes-Backup muss je nach Wiederherstellungsziel berücksichtigen: Kubernetes-Objekte; Namespaces; Deployments und StatefulSets; Services und Ingress; ConfigMaps; Secrets; CRDs und benutzerdefinierte Ressourcen; Persistent Volumes; externe Datenbanken; Images und Registryabhängigkeiten; Clusterkonfiguration; gegebenenfalls etcd. 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: logisches Backup; physisches Backup; anwendungskonsistenter Snapshot; Transaktionslogs; Point-in-Time Recovery; Replikation; dateibasierte Offlinekopie. Zu prüfen sind: Datenbankverbindung; Backupbenutzer; Berechtigung; Lock- und Transaktionszustand; verfügbare WAL-, Redo- oder Binärlogs; Logarchivierung; Backupmodus; Datenbankversion; Verschlüsselung; Komprimierung; freier Speicher; Konsistenzprüfung; Restoreversion; Abhängigkeit zu vorherigen Backups. 7.15.31 PostgreSQL-Backups prüfen PostgreSQL unterstützt unterschiedliche Verfahren: pg_dump für logische Sicherungen; pg_dumpall für clusterweite logische Objekte; pg_basebackup für physische Basissicherungen; WAL-Archivierung für Point-in-Time Recovery; pg_verifybackup zur Prüfung eines von pg_basebackup erzeugten Backups. Basissicherung prüfen: LESEND, LASTERZEUGEND pg_verifybackup \ Zu prüfen sind: Backupmanifest; erforderliche WAL-Dateien; Replikationsberechtigung; pg_hba.conf ; erreichbarer PostgreSQL-Port; max_wal_senders ; Archivierungsbefehl; WAL-Ziel; freier Speicher; Backup vom Primary oder Standby; Version der Werkzeuge; inkrementelle Abhängigkeiten; Point-in-Time-Recovery-Konfiguration. 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: Storage Pool; Volume; LUN; Dateisystem; Snapshot; Replikation; Zielsystem; Retention; Thin Provisioning; Quota; Kompression; Deduplizierung; Immutable Snapshot; Offsitekopie. Mögliche Fehler: Pool voll; Volume voll; Snapshotreserve voll; Thin Pool voll; Metadatenbereich voll; Snapshotlimit erreicht; Replikationsziel nicht erreichbar; Zertifikat abgelaufen; Storagekonto gesperrt; LUN nicht sichtbar; Multipathfehler; Snapshotabhängigkeit; Storagejob überschneidet sich mit Backupjob; Snapshot wurde erstellt, aber nicht extern kopiert; Quiescing der Anwendung fehlte. 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: Bucket oder Container; Region; Endpunkt; DNS; TLS-Zertifikat; Proxy; API-Token; Zugriffsschlüssel; Rolle; Schreibberechtigung; List-, Read- und Delete-Rechte; Object Lock; Retention; Legal Hold; Quota; Kosten- oder Kontolimit; Rate Limit; Request Timeout; Multipart Upload; unvollständige Uploads; KMS-Schlüssel; Verschlüsselung; Uhrzeit des Clients; Providerstatus. 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: gelesene Datenmenge; geschriebene Datenmenge; Änderungsrate; Deduplizierungsrate; Kompressionsrate; Durchsatz; Latenz; Paketverlust; CPU-Auslastung; Arbeitsspeicher; I/O-Wait; Repositorylatenz; Snapshotdauer; Gesamtdauer; verbleibendes Backupfenster. Mögliche Ursachen: Produktivlast; parallele Backupjobs; Virenscanner; Storage-Scrub; Rebuild; Snapshotkonsolidierung; WAN-Limit; hohe Latenz; Paketverlust; MTU-Problem; viele kleine Dateien; nicht erreichbarer erster Zielserver; zu kleiner Cache; langsame Deduplizierungsdatenbank; Wartungsjob im Repository; Cloud-API-Drosselung; neue große Datenmenge; geänderte Komprimierung oder Verschlüsselung. 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: mehrere Backupjobs gleichzeitig fehlerhaft; Backupkonto unerwartet gesperrt; Recovery Points fehlen; Retention wurde verändert; Immutability wurde deaktiviert; Repository enthält ungewöhnliche Löschvorgänge; ungewöhnlich viele Dateien wurden geändert; Datenmenge oder Deduplizierungsrate verändert sich stark; Backups enthalten bereits verschlüsselte Produktivdaten; Backupserver zeigt unbekannte Anmeldungen; Logs oder Auditdaten fehlen; Verschlüsselungsschlüssel wurden verändert; Repository ist plötzlich nicht erreichbar; ungewöhnliche API-Aufrufe; Sekundärkopie oder Offlinekopie fehlt ebenfalls. Bei begründetem Verdacht: Incident-Response-Prozess aktivieren. Beweise sichern. Repository vor weiteren Veränderungen schützen. Immutability und Offlinekopien prüfen. Backupzugangsdaten als möglicherweise kompromittiert behandeln. Keine normalen Retention- oder Pruningvorgänge starten. Wiederherstellungspunkt vor dem vermuteten Vorfall bestimmen. Restore ausschließlich in isolierter Umgebung testen. 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: betroffene Jobphase; vermutete Ursache; erwarteten Befund; Gegenbeweis; Testmethode; Risiko; Erfolgskriterium. 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: Job-ID; letzter erfolgreicher Recovery Point; aktuelle Schutzlücke; Repositoryzustand; laufende Prozesse; erwartete Datenmenge; Risiko; Freigabe; Rückweg; Erfolgskriterium. 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 Fehlermeldung vollständig aufnehmen Wortlaut, Fehlercode, Job-ID und Zeitpunkt dokumentieren. Job und Sicherungsprodukt bestimmen Plan, Richtlinie, Agent und Server erfassen. Auswirkung bestimmen Einzelne Quelle, Jobgruppe, Repository oder gesamte Umgebung unterscheiden. Letzten erfolgreichen Recovery Point bestimmen Nicht nur letzten erfolgreichen Prozesslauf prüfen. RPO-Verletzung berechnen Aktuelle Schutzlücke mit Sollwert vergleichen. Jobphase bestimmen Planung, Snapshot, Lesen, Transport, Schreiben oder Abschluss unterscheiden. Scheduler prüfen Trigger, Konto, letzte Ausführung und Exit-Code erfassen. Backupdienste und Agenten prüfen Status und Version dokumentieren. Logs sichern Job-, Betriebssystem-, Anwendungs- und Repositorylogs korrelieren. Quelle vollständig bestimmen Pfade, Volumes, VMs, Container und Datenbanken erfassen. Ausschlüsse prüfen Neue oder versehentlich ausgeschlossene Daten erkennen. Quellberechtigungen prüfen Tatsächlichen Dienstkontext verwenden. Quellkapazität prüfen Freien Speicher, Inodes und Temp-Bereich untersuchen. Snapshotzustand prüfen VSS, Hypervisor, CSI oder Storage-Snapshot unterscheiden. Anwendungskonsistenz prüfen Writer, Hook oder Datenbankverfahren auswerten. Ziel und Repository bestimmen Host, Pfad, Port, Protokoll und Backend erfassen. Netzwerkpfad prüfen DNS, Routing, Firewall, VPN, Proxy und TLS untersuchen. Zielberechtigungen prüfen Schreiben, Lesen, Listen und gegebenenfalls Löschen unterscheiden. Repositorykapazität prüfen Speicher, Quota, Thin Pool, Katalog und Cache berücksichtigen. Repositorylock prüfen Aktive und verwaiste Locks unterscheiden. Parallele Jobs prüfen Backup, Restore, Replication, Retention und Pruning erfassen. Sicherungskette prüfen Vollbackup und erforderliche Folgebackups zuordnen. Retention und Immutability prüfen Aufbewahrung, Object Lock und Legal Hold berücksichtigen. Verschlüsselung prüfen Schlüssel, Kennwort, KMS und Zertifikate erfassen. Integrität prüfen Herstellervorgesehene Repositoryprüfung verwenden. Performance prüfen Dauer, Durchsatz, Latenz, Last und Backupfenster vergleichen. Sicherheitsverdacht bewerten Manipulation, ungewöhnliche Änderungen und fehlende Recovery Points prüfen. Hypothese und Gegenbeweis formulieren Ursache vor der Änderung messbar festlegen. Eine kontrollierte Maßnahme durchführen Risiko, Rückweg und Freigabe beachten. Job kontrolliert neu starten Doppelstarts und parallele Wartung ausschließen. Jobphasen überwachen Snapshot, Übertragung und Abschluss beobachten. Exit-Code und Warnungen auswerten Teilerfolg nicht als Vollerfolg behandeln. Neuen Recovery Point bestätigen Zeit, Umfang und Repository registrieren. Integritätsprüfung durchführen Katalog und Datenblöcke prüfen. Isolierten Restore-Test durchführen Repräsentative Daten oder Anwendung wiederherstellen. Wiederhergestellte Daten validieren Inhalt, Metadaten, Rechte und Anwendung prüfen. RPO und RTO bewerten Tatsächliche Werte dokumentieren. Sekundärkopie prüfen Offsite-, Offline- oder immutable Kopie bestätigen. Temporäre Änderungen zurücknehmen Debuglogging, Testfreigaben und Ausnahmen entfernen. Ursache dokumentieren Technischen Nachweis festhalten. 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 Nur die letzte Fehlermeldung betrachten. Jobstatus „Warning“ als Erfolg behandeln. Exit-Code eines Unterprozesses nicht übernehmen. Letzten Job mit letztem Recovery Point gleichsetzen. RPO-Verletzung nicht berechnen. Scheduler und Backupsoftware nicht getrennt prüfen. Manuellen und geplanten Benutzerkontext gleichsetzen. Gemappte Laufwerke in unbeaufsichtigten Jobs verwenden. Fehlende Mounts übersehen. Nur Repositorykapazität prüfen. Quell-, Cache-, Snapshot- und Katalogspeicher ignorieren. Inodes nicht prüfen. VSS-Writer erst nach einem Neustart kontrollieren. Alle VSS-Dienste pauschal neu starten. Snapshot mit vollständigem Backup gleichsetzen. Crash-Konsistenz mit Anwendungskonsistenz verwechseln. Aktive Datenbankdateien unkoordiniert kopieren. Dockerexport als Volumebackup betrachten. Kubernetes-Objekte oder externe Datenbanken vergessen. PVC-Größe mit freiem Speicher gleichsetzen. Inkrementelle Abhängigkeiten ignorieren. Recovery Points manuell aus dem Repository löschen. Repositorylock automatisch entfernen. Retention unter Zeitdruck verkürzen. Immutability als Fehler statt Schutzfunktion behandeln. Prüfsummenprüfung mit Restore-Test gleichsetzen. Verschlüsselungsschlüssel nicht in den Wiederherstellungsplan aufnehmen. Backup und Replikation gleichsetzen. Nur lokale Kopie prüfen. Keine isolierte Wiederherstellung testen. Nur einzelne Datei, aber nicht Anwendung testen. Wiederherstellungsdauer nicht messen. Backupfehler bei möglichem Ransomwarevorfall normal behandeln. Temporäres Debuglogging aktiv lassen. Ursache nach erfolgreichem Wiederholungslauf nicht dokumentieren. 7.15.42 Verifikation und Restore-Test Nach der Maßnahme müssen mindestens folgende Punkte geprüft werden: Scheduler ist aktiviert; nächster Lauf ist korrekt; Dienstkonto ist gültig; Job startet im unbeaufsichtigten Kontext; alle vorgesehenen Quellen sind enthalten; Ausschlüsse entsprechen dem Sollzustand; Snapshot wurde erfolgreich erstellt; Anwendungskonsistenz wurde bestätigt; Daten wurden vollständig übertragen; Repository besitzt ausreichend Kapazität; Recovery Point wurde registriert; Job enthält keine unbeachteten Warnungen; Sicherungskette ist vollständig; Integritätsprüfung ist erfolgreich; Verschlüsselungsschlüssel ist verfügbar; sekundäre Kopie wurde erstellt; Immutability ist aktiv, sofern vorgesehen; repräsentative Dateien lassen sich wiederherstellen; Dateiinhalte stimmen; Dateigrößen stimmen; Zeitstempel stimmen, sofern erforderlich; Eigentümer und Berechtigungen stimmen; ACLs und erweiterte Attribute stimmen; Datenbank lässt sich öffnen; Anwendung startet mit den wiederhergestellten Daten; Abhängigkeiten und Konfigurationen sind vorhanden; tatsächliches RPO wurde bestimmt; tatsächliches RTO wurde gemessen; Restore-Dokumentation ist vollständig; temporäre Testdaten wurden kontrolliert entfernt. 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: letzter Jobstart; letzter erfolgreicher Job; letzter Recovery Point; letzter verifizierter Recovery Point; letzter externer Recovery Point; letzter Restore-Test; Alter des Restore-Tests; Jobdauer; übertragene Datenmenge; Änderungsrate; Durchsatz; Warnungen; Teilfehler; Repositorykapazität; Snapshotkapazität; Cachekapazität; Inodes; Quotas; Repositorylocks; Retention; Pruning; Immutability; Replikation; Verschlüsselungsschlüssel; Zertifikats- und Tokenablauf; RPO; RTO. Ein geeignetes Monitoring alarmiert nicht nur bei Failed , sondern auch bei: Job wurde nicht gestartet; kein neuer Recovery Point; Job erfolgreich, aber Datenmenge ungewöhnlich klein; Jobdauer ungewöhnlich kurz; Jobdauer ungewöhnlich lang; nur Teilbackup; letzte Verifikation zu alt; letzter Restore-Test zu alt; sekundäre Kopie fehlt; Immutability nicht aktiv; Repository wächst unerwartet; Retention wurde verändert. 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: verschlüsselt; getrennt; unveränderbar; überwacht; regelmäßig geprüft; regelmäßig wiederhergestellt; gegen unberechtigte Löschung geschützt sein. 7.15.46 Dokumentationsvorlage Störung: Zeitpunkt: Sicherungsprodukt: Jobname: Job-ID: Betroffene Quelle: Sicherungsziel: Geplanter Start: Tatsächlicher Start: Endzeit: Jobphase: Exit-Code: Letzter erfolgreicher Recovery Point: Letzter verifizierter Recovery Point: Aktuelle Schutzlücke: Vorgesehenes RPO: Vorgesehenes RTO: Schedulerzustand: Dienstkonto: Quellzustand: Snapshotzustand: Anwendungskonsistenz: Netzwerkpfad: Repositoryzustand: Sicherungskette: Retention und Immutability: Verschlüsselung: Nachgewiesene Ursache: Gegenbeweis ausgeschlossen durch: Durchgeführte Maßnahme: Risiko und Rückweg: Neuer Recovery Point: Integritätsprüfung: Restore-Test: Tatsächliches RPO: Tatsächliches RTO: Prävention: 7.15.47 Checkliste exakte Fehlermeldung dokumentiert Fehlercode dokumentiert Jobname erfasst Job-ID erfasst Sicherungsprodukt und Version erfasst Start- und Endzeit erfasst betroffene Jobphase bestimmt letzten erfolgreichen Job bestimmt letzten Recovery Point bestimmt letzten verifizierten Recovery Point bestimmt aktuelle Schutzlücke berechnet RPO bewertet RTO berücksichtigt Scheduler geprüft Trigger geprüft verpasste Läufe geprüft Dienstkonto geprüft Kennwortablauf geprüft Tokenablauf geprüft Zertifikatsablauf geprüft Recht zur geplanten Anmeldung geprüft Arbeitsverzeichnis geprüft Umgebungsvariablen geprüft Exit-Code geprüft Standardausgabe geprüft Fehlerausgabe geprüft Backupdienste geprüft Agentstatus geprüft Agentversion geprüft vollständige Quelle erfasst Quellpfade geprüft Volumes geprüft Mountpoints geprüft Ausschlüsse geprüft Quellberechtigungen geprüft freien Speicher der Quelle geprüft Inodes geprüft Cache- und Temp-Bereich geprüft Snapshotbereich geprüft VSS-Writer geprüft VSS-Provider geprüft Anwendungskonsistenz geprüft Hypervisor-Snapshot geprüft Storage-Snapshot geprüft Repositoryhostname bestimmt DNS geprüft Ziel-IP bestimmt Port geprüft Firewall geprüft VPN geprüft Proxy geprüft TLS geprüft Repositorypfad geprüft Zielberechtigungen geprüft Repositorykapazität geprüft Repositoryquota geprüft Thin Pool geprüft Repositorylock geprüft parallele Jobs geprüft Restorevorgänge geprüft Retentionjob geprüft Pruning geprüft Replikation geprüft Vollbackup bestimmt inkrementelle Kette geprüft differenzielle Abhängigkeit geprüft Katalog geprüft Repositoryindex geprüft Prüfsummen geprüft Verschlüsselungsschlüssel geprüft KMS-Erreichbarkeit geprüft Immutability geprüft Object Lock geprüft sekundäre Kopie geprüft Offsitekopie geprüft Offlinekopie geprüft Docker-Volumes bei Bedarf geprüft Kubernetes-Objekte bei Bedarf geprüft PVCs bei Bedarf geprüft VolumeSnapshots bei Bedarf geprüft Datenbankverfahren geprüft Transaktionslogs geprüft WAL-, Redo- oder Binärlogs geprüft Jobdauer mit Baseline verglichen Datenmenge mit Baseline verglichen Durchsatz geprüft Backupfenster geprüft Sicherheitsverdacht bewertet Hypothese formuliert Gegenbeweis festgelegt Risiko und Rückweg dokumentiert nur eine kontrollierte Maßnahme durchgeführt neuen Job überwacht neuen Recovery Point bestätigt Integritätsprüfung durchgeführt isolierten Restore-Test durchgeführt Dateiinhalte geprüft Metadaten und Berechtigungen geprüft Datenbank geöffnet Anwendung getestet tatsächliches RPO dokumentiert tatsächliches RTO gemessen temporäre Änderungen zurückgenommen Ursache dokumentiert Präventionsmaßnahme festgelegt 7.15.48 Schnellreferenz Aufgabe Befehl Windows-Task Get-ScheduledTask -TaskName "" Windows-Task-Laufzeit Get-ScheduledTask -TaskName "" | Get-ScheduledTaskInfo detaillierte Taskabfrage schtasks /query /tn "" /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 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 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 7.15.49 Quellen Offizielle Microsoft-Dokumentation Microsoft Learn – Windows Server Backup Command Reference Microsoft Learn – wbadmin start backup Microsoft Learn – Volume Shadow Copy Service Microsoft Learn – Backup fails because of a VSS Writer Microsoft Learn – No VSS writers are listed Microsoft Learn – Get-ScheduledTaskInfo Microsoft Learn – schtasks Microsoft Learn – schtasks query Offizielle Linux- und Projektdokumentation systemd – systemctl systemd – systemd.timer systemd – journalctl Rsync – Official man page Restic – Backing up Restic – Restoring Restic – Removing backup snapshots Restic – Working with repositories Restic – Troubleshooting Offizielle Docker-Dokumentation Docker Docs – Volumes Docker Docs – Storage Docker Docs – docker container export Docker Docs – Back up and restore Docker Desktop data Offizielle Kubernetes-Dokumentation Kubernetes – Volume Snapshots Kubernetes – Persistent Volumes Kubernetes – Operating etcd clusters Offizielle PostgreSQL-Dokumentation PostgreSQL – Backup and Restore PostgreSQL – pg_basebackup PostgreSQL – pg_verifybackup PostgreSQL – Continuous Archiving and Point-in-Time Recovery Offizielle Apple-Dokumentation Apple – Back up your Mac with Time Machine Apple – Time Machine troubleshooting Apple – If a Time Machine backup fails Apple – Verify your backup disk Apple – Restore items backed up with Time Machine Offizielle Sicherheitsempfehlungen BSI – Datensicherungskonzept CON.3 BSI – Top 10 Ransomware-Maßnahmen CISA – StopRansomware Guide Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.