# 7. Schnelle Entscheidungsbäume # 7.1 Ein Client hat kein Netzwerk Wenn nur ein einzelner Client keine Netzwerkverbindung besitzt, sollte die Fehlersuche schnell feststellen, auf welcher Ebene die Verbindung unterbrochen ist: 1. Netzwerkadapter, 2. physische oder drahtlose Verbindung, 3. IP-Konfiguration, 4. lokales Netzwerk, 5. Routing, 6. DNS, 7. Zielsystem oder Anwendung. Dieser Entscheidungsbaum dient der schnellen Eingrenzung. Die ausführliche Ende-zu-Ende-Analyse befindet sich auf der Seite **6.1 Client ohne Netzwerkverbindung – systematische Ende-zu-Ende-Analyse**. --- **1. Störungsumfang bestimmen** Zuerst prüfen: - 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: ```powershell Get-NetAdapter ``` Nur physische Adapter anzeigen: ```powershell Get-NetAdapter -Physical ``` Ausführliche Adapterinformationen: ```powershell 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: ```cmd netsh wlan show interfaces ``` Sichtbare WLAN-Netze anzeigen: ```cmd netsh wlan show networks ``` Gespeicherte WLAN-Profile anzeigen: ```cmd 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: ```cmd ipconfig /all ``` Alternativ mit PowerShell: ```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** ```text 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: ```powershell Get-Service -Name Dhcp ``` Adapterkonfiguration prüfen: ```powershell 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: ```cmd ipconfig /release ``` ```cmd 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: 1. DHCP Discover, 2. DHCP Offer, 3. DHCP Request, 4. DHCP Acknowledge. --- **5. Lokalen TCP/IP-Stack prüfen** Loopback-Adresse testen: ```cmd ping 127.0.0.1 ``` Eigene IPv4-Adresse testen: ```cmd 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: ```cmd ipconfig ``` Routingtabelle anzeigen: ```cmd route print ``` Alternativ: ```powershell Get-NetRoute ``` Gateway testen: ```cmd ping ``` Zusätzliche Verbindungsinformationen: ```powershell Test-NetConnection -ComputerName -InformationLevel Detailed ``` Nachbartabelle anzeigen: ```cmd arp -a ``` Oder mit PowerShell: ```powershell Get-NetNeighbor ``` **Entscheidungsbaum** ```text 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: ```cmd ping ``` Gezielten Dienst prüfen: ```powershell 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: ```cmd ping ``` Pfad untersuchen: ```cmd tracert ``` PowerShell-Diagnose: ```powershell 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: ```cmd ipconfig /all ``` Namensauflösung testen: ```cmd nslookup ``` Mit PowerShell: ```powershell Resolve-DnsName ``` Erreichbarkeit eines DNS-Servers prüfen: ```powershell 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** ```text 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: ```cmd 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: ```cmd ipconfig /flushdns ``` --- **10. Funktioniert nur die Anwendung nicht?** Wenn IP-Verbindung und Namensauflösung funktionieren, den tatsächlich benötigten Dienst prüfen. Porttest: ```powershell Test-NetConnection -ComputerName -Port ``` Beispiele: ```powershell Test-NetConnection -ComputerName -Port 443 ``` ```powershell Test-NetConnection -ComputerName -Port 445 ``` ```powershell 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: ```cmd 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: ```powershell Get-NetAdapter ``` IP-Konfiguration anzeigen: ```powershell Get-NetIPConfiguration ``` Routingtabelle prüfen: ```cmd route print ``` DNS-Server je Schnittstelle anzeigen: ```powershell 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: ```powershell Get-NetFirewallProfile ``` Aktive Verbindungen und lauschende Ports: ```powershell 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: ```cmd arp -a ``` Eigene MAC-Adresse erfassen: ```powershell 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: ```text Ereignisanzeige └─ Anwendungs- und Dienstprotokolle └─ Microsoft └─ Windows ├─ DHCP-Client ├─ DNS-Client ├─ NetworkProfile ├─ NlaSvc ├─ TCPIP └─ WLAN-AutoConfig ``` PowerShell-Beispiel für Systemereignisse: ```powershell 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: ```powershell 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: ```text arp ``` ```text dhcp ``` ```text dns ``` ```text icmp ``` Kombinierter Wireshark-Anzeigefilter: ```text 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** ```text 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** ```powershell Get-NetAdapter ``` Ergebnis: ```text Name Status LinkSpeed Ethernet Up 1 Gbps ``` IP-Konfiguration: ```cmd ipconfig /all ``` Ergebnis: ```text 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** 1. genaue Fehlermeldung und Uhrzeit erfassen. 2. feststellen, ob nur ein Client betroffen ist. 3. Ethernet, WLAN, VPN und betroffene Ziele unterscheiden. 4. Vergleichsclient prüfen. 5. Adapterstatus erfassen. 6. physischen Link oder WLAN-Verbindung prüfen. 7. `ipconfig /all` dokumentieren. 8. IP-Adresse und Subnetz prüfen. 9. bei `169.254.x.x` den DHCP-Pfad untersuchen. 10. Standardgateway prüfen. 11. Routingtabelle erfassen. 12. eigenes TCP/IP über Loopback testen. 13. lokales Vergleichsziel testen. 14. Gateway testen. 15. externe IP-Verbindung testen. 16. Pfad bei Bedarf mit `tracert` untersuchen. 17. DNS-Server und Namensauflösung prüfen. 18. benötigten Zielport testen. 19. Proxy, VPN und virtuelle Adapter berücksichtigen. 20. Firewall- und Sicherheitsprotokolle prüfen. 21. Ereignisse mit dem Fehlerzeitpunkt korrelieren. 22. genau eine Hypothese formulieren. 23. genau eine kontrollierte Änderung durchführen. 24. dieselben Tests erneut ausführen. 25. interne und externe Ziele prüfen. 26. Namensauflösung prüfen. 27. benötigte Anwendungen testen. 28. Vergleichsclient oder Vergleichsanschluss erneut testen. 29. temporäre Diagnosekonfiguration entfernen. 30. Ursache, Maßnahme und Nachweis dokumentieren. --- **22. Checkliste „Ein Client hat kein Netzwerk“** - [ ] 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](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig) - [Microsoft Learn – ping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping) - [Microsoft Learn – tracert](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/tracert) - [Microsoft Learn – pathping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pathping) - [Microsoft Learn – arp](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/arp) - [Microsoft Learn – route](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/route_ws2008) - [Microsoft Learn – nslookup](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/nslookup) - [Microsoft Learn – Get-NetAdapter](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapter) - [Microsoft Learn – Get-NetIPConfiguration](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netipconfiguration) - [Microsoft Learn – Get-NetRoute](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netroute) - [Microsoft Learn – Get-NetNeighbor](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netneighbor) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Get-DnsClientServerAddress](https://learn.microsoft.com/en-us/powershell/module/dnsclient/get-dnsclientserveraddress) - [Microsoft Learn – netsh wlan](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-wlan) - [Microsoft Learn – DHCP troubleshooting guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dhcp-guidance) - [Microsoft Learn – DHCP overview](https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-top) - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/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** ```text 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: ```cmd ipconfig /all ``` ```cmd ping ``` ```cmd ping ``` ```cmd nslookup ``` ```powershell 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: ```powershell Get-NetAdapter ``` Vollständige IP-Konfiguration anzeigen: ```cmd 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** ```text 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: ```cmd 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** ```text 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: ```powershell Get-Service -Name DHCPServer ``` ```powershell Get-DhcpServerv4Scope ``` ```powershell Get-DhcpServerv4ScopeStatistics ``` ```powershell Get-DhcpServerv4Binding ``` ```powershell 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: 1. DHCP Discover, 2. DHCP Offer, 3. DHCP Request, 4. DHCP Acknowledge. --- **8. Bestehende und neue Clients vergleichen** Dieser Vergleich ist bei DHCP-Störungen besonders aussagekräftig. | Beobachtung | Mögliche Erklärung | |---|---| | bestehende Clients funktionieren, neue nicht | DHCP-Bereich ausgeschöpft oder DHCP-Dienst gestört | | Clients funktionieren bis zum Ablauf des Leases | Lease-Erneuerung oder DHCP-Erreichbarkeit gestört | | Clients mit statischer IP funktionieren | DHCP-Pfad priorisieren | | statische und dynamische Clients funktionieren nicht | Gateway, VLAN, Switch oder Routing priorisieren | | nur Clients eines Subnetzes betroffen | DHCP-Bereich, Relay oder VLAN prüfen | | Clients erhalten unterschiedliche falsche Adressen | fremden DHCP-Server oder falsche VLAN-Zuweisung prüfen | Eine frei gewählte statische IP-Adresse sollte nicht unkontrolliert vergeben werden. Sie kann einen Adresskonflikt verursachen und den ursprünglichen Fehler verdecken. --- **9. Standardgateway prüfen** Auf mehreren Clients das konfigurierte Gateway feststellen: ```cmd ipconfig ``` Gateway testen: ```cmd ping ``` Routingtabelle anzeigen: ```cmd route print ``` Alternativ: ```powershell Get-NetRoute ``` Nachbartabelle prüfen: ```powershell 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: ```cmd ping ``` Pfad anzeigen: ```cmd tracert ``` PowerShell-Test: ```powershell Test-NetConnection -ComputerName -InformationLevel Detailed ``` **Entscheidungsbaum** ```text 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: ```cmd nslookup ``` ```powershell Resolve-DnsName ``` Konfigurierte DNS-Server anzeigen: ```powershell Get-DnsClientServerAddress ``` DNS-Port prüfen: ```powershell 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: ```text 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** ```cmd ipconfig /all ``` Ergebnis auf mehreren Clients: ```text 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** 1. genaue Fehlermeldung und Beginn erfassen. 2. Anzahl und Standort der betroffenen Clients bestimmen. 3. funktionierende Vergleichsclients suchen. 4. gemeinsame Switches, VLANs, Access Points oder Dienste ermitteln. 5. Ethernet und WLAN getrennt vergleichen. 6. Adapter- und Linkstatus mehrerer Clients prüfen. 7. IP-Konfiguration mehrerer Clients vergleichen. 8. auf `169.254.x.x`, falsche Subnetze oder fehlende Gateways achten. 9. DHCP-Dienst, Bereich und Relay prüfen. 10. Gateway jedes betroffenen VLANs testen. 11. lokales Vergleichsziel testen. 12. externe IP-Adresse testen. 13. DNS-Auflösung getrennt prüfen. 14. benötigten Zielport prüfen. 15. Switchstatus und Uplinks untersuchen. 16. VLAN- und Trunk-Konfiguration prüfen. 17. Spanning Tree und Portschutz berücksichtigen. 18. Firewall, NAT und Routing prüfen. 19. WAN- und Standortverbindungen prüfen. 20. Redundanz- und Failoverstatus prüfen. 21. Ereignisse mit dem Fehlerbeginn korrelieren. 22. letzte Änderungen ermitteln. 23. eine gemeinsame Ursache als Hypothese formulieren. 24. genau eine kontrollierte Maßnahme durchführen. 25. dieselben Tests nach der Änderung wiederholen. 26. alle zuvor betroffenen Bereiche testen. 27. Überwachung und Protokolle kontrollieren. 28. temporäre Diagnoseänderungen entfernen. 29. Ursache, Maßnahme und Nachweis dokumentieren. --- **18. Checkliste „Mehrere Clients haben kein Netzwerk“** - [ ] 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](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dhcp-guidance) - [Microsoft Learn – Troubleshoot problems on the DHCP server](https://learn.microsoft.com/en-us/windows-server/troubleshoot/troubleshoot-problems-on-dhcp-server) - [Microsoft Learn – Troubleshoot problems on the DHCP client](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-problems-dhcp-client) - [Microsoft Learn – Get-DhcpServerv4Scope](https://learn.microsoft.com/en-us/powershell/module/dhcpserver/get-dhcpserverv4scope) - [Microsoft Learn – Get-DhcpServerv4ScopeStatistics](https://learn.microsoft.com/en-us/powershell/module/dhcpserver/get-dhcpserverv4scopestatistics) - [Microsoft Learn – Get-DhcpServerv4Binding](https://learn.microsoft.com/en-us/powershell/module/dhcpserver/get-dhcpserverv4binding) - [Microsoft Learn – Get-DhcpServerv4Failover](https://learn.microsoft.com/en-us/powershell/module/dhcpserver/get-dhcpserverv4failover) - [Microsoft Learn – ipconfig](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig) - [Microsoft Learn – ping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping) - [Microsoft Learn – tracert](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/tracert) - [Microsoft Learn – Get-NetAdapter](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapter) - [Microsoft Learn – Get-NetRoute](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netroute) - [Microsoft Learn – Get-NetNeighbor](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netneighbor) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Cisco – Troubleshoot STP problems and related design considerations](https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10556-16.html) - [Cisco – Spanning Tree Protocol documentation](https://www.cisco.com/c/en/us/tech/lan-switching/spanning-tree-protocol/index.html) # 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: ```cmd ping 192.0.2.25 ``` funktioniert, aber: ```cmd 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. ```powershell Test-NetConnection -ComputerName -InformationLevel Detailed ``` Für einen konkreten Dienst: ```powershell Test-NetConnection -ComputerName -Port ``` Danach denselben Test mit dem Namen durchführen: ```powershell 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** ```text 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: ```text server01 server01.example.local portal.example.com files.example.local ``` Ein Kurzname wie `server01` ist nicht dasselbe wie der vollständige Name: ```text 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: ```cmd ipconfig /all ``` Gezielt die konfigurierten DNS-Server anzeigen: ```powershell Get-DnsClientServerAddress ``` Nur IPv4-DNS-Server: ```powershell Get-DnsClientServerAddress -AddressFamily IPv4 ``` DNS-Clientkonfiguration der Adapter anzeigen: ```powershell Get-DnsClient ``` Globale DNS-Einstellungen und Suffixsuchliste anzeigen: ```powershell 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: ```cmd ping ``` Ein fehlgeschlagener Ping beweist keinen Ausfall, da ICMP blockiert sein kann. TCP-Port 53 prüfen: ```powershell 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: ```powershell Resolve-DnsName ``` Beispiel: ```powershell Resolve-DnsName server01.example.local ``` Gezielt einen bestimmten DNS-Server abfragen: ```powershell Resolve-DnsName -Server ``` Alternativ: ```cmd nslookup ``` Bestimmten DNS-Server abfragen: ```cmd 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: ```powershell Resolve-DnsName server01.example.local -Server 192.0.2.10 ``` ```powershell 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: ```powershell Resolve-DnsName server01.example.local ``` Kurznamen testen: ```powershell Resolve-DnsName server01 ``` **Entscheidung** ```text 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: ```powershell Get-DnsClient ``` Globale Suffixsuchliste anzeigen: ```powershell Get-DnsClientGlobalSetting ``` In `ipconfig /all` insbesondere prüfen: ```text 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: ```powershell Resolve-DnsName -Type A ``` IPv6-Eintrag abfragen: ```powershell Resolve-DnsName -Type AAAA ``` Mit `nslookup`: ```cmd nslookup -type=A ``` ```cmd 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. ```powershell Resolve-DnsName ``` Danach den benötigten Port an der gelieferten Adresse testen: ```powershell 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: ```cmd ipconfig /displaydns ``` Alternativ: ```powershell Get-DnsClientCache ``` Gezielt nach einem Namen suchen: ```powershell 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** ```powershell Resolve-DnsName ``` und anschließend gezielt: ```powershell Resolve-DnsName -Server ``` Unterscheiden sich Cache und direkte Serverantwort, kann ein veralteter Cacheeintrag vorliegen. Cache erst nach der Dokumentation leeren: ```powershell Clear-DnsClientCache ``` Alternativ: ```cmd ipconfig /flushdns ``` Danach denselben Test erneut durchführen: ```powershell 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: ```text C:\Windows\System32\drivers\etc\hosts ``` Inhalt mit PowerShell anzeigen: ```powershell Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" ``` Relevante aktive Zeilen anzeigen: ```powershell 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: ```text 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: ```powershell Get-DnsServerZone ``` Bestimmte Zone prüfen: ```powershell Get-DnsServerZone -Name "" ``` Resource Record suchen: ```powershell Get-DnsServerResourceRecord -ZoneName "" -Name "" ``` A- und AAAA-Records der Zone anzeigen: ```powershell Get-DnsServerResourceRecord -ZoneName "" -RRType A ``` ```powershell 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: ```text server01.example.local ``` Dafür müssen mindestens folgende Bestandteile stimmen: ```text 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: ```powershell Resolve-DnsName ``` Ausführlich mit `nslookup`: ```cmd nslookup -debug ``` Mögliche Situation: 1. ein Record zeigte auf eine alte IP-Adresse, 2. der Record wurde auf dem DNS-Server korrigiert, 3. ein Client oder zwischengeschalteter Resolver besitzt noch die alte Antwort, 4. der Client verwendet diese bis zum Ablauf der TTL weiter. Zu berücksichtigen sind: - 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: ```powershell Get-DnsServerResourceRecord ` -ComputerName ` -ZoneName "" ` -Name "" ``` ```powershell 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: ```powershell Get-DnsServerForwarder ``` Conditional Forwarder anzeigen: ```powershell Get-DnsServerZone | Where-Object ZoneType -EQ "Forwarder" ``` Details einer Weiterleitungszone prüfen: ```powershell 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: ```powershell Resolve-DnsName -Server ``` **Entscheidung** ```text 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: ```powershell Resolve-DnsName -Type NS ``` SOA-Eintrag prüfen: ```powershell 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** ```text host.abteilung.example.local ``` Die Zone: ```text 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: ```powershell Test-NetConnection -ComputerName -Port 53 ``` Eine tatsächliche DNS-Abfrage ausführen: ```powershell Resolve-DnsName -Server ``` Abfrage ausdrücklich über TCP erzwingen: ```powershell 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: ```text portal.example.com ``` Intern: ```text 10.10.20.25 ``` Extern: ```text 198.51.100.25 ``` Vergleichsabfragen: ```powershell Resolve-DnsName portal.example.com -Server ``` ```powershell 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: ```powershell Get-DnsClientServerAddress ``` ```powershell Get-DnsClientGlobalSetting ``` NRPT-Regeln anzeigen: ```powershell Get-DnsClientNrptPolicy ``` Zusätzlich, abhängig von der Windows-Version: ```powershell 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: ```powershell 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: ```powershell 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: ```powershell Resolve-DnsName -Server ``` ```powershell 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: ```powershell Resolve-DnsName -Type CNAME ``` Normale Abfrage: ```powershell Resolve-DnsName ``` Beispiel: ```text 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** ```powershell Resolve-DnsName ``` ```powershell Test-NetConnection -ComputerName -Port ``` ```powershell 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: ```text \\192.0.2.25\Freigabe ``` Der Zugriff über den Namen scheitert: ```text \\fileserver.example.local\Freigabe ``` **IP-Prüfung** ```powershell Test-NetConnection -ComputerName 192.0.2.25 -Port 445 ``` Ergebnis: ```text TcpTestSucceeded : True ``` **Namensprüfung** ```powershell Resolve-DnsName fileserver.example.local ``` Ergebnis: ```text 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** ```powershell Resolve-DnsName fileserver.example.local -Server 192.0.2.10 ``` Ergebnis: ```text IPAddress : 192.0.2.25 ``` ```powershell Resolve-DnsName fileserver.example.local -Server 192.0.2.11 ``` Ergebnis: ```text 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** ```powershell Resolve-DnsName fileserver.example.local -Server 192.0.2.10 ``` ```powershell Resolve-DnsName fileserver.example.local -Server 192.0.2.11 ``` Beide Server liefern: ```text IPAddress : 192.0.2.25 ``` Zusätzlich: ```powershell Test-NetConnection -ComputerName fileserver.example.local -Port 445 ``` Ergebnis: ```text 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** 1. genaue Fehlermeldung und Uhrzeit erfassen. 2. verwendeten Namen exakt dokumentieren. 3. erwartete Ziel-IP und Zielport feststellen. 4. Zielport über die IP-Adresse prüfen. 5. Zielport über den Namen prüfen. 6. FQDN und Kurzname getrennt testen. 7. aktive Netzwerkadapter ermitteln. 8. konfigurierte DNS-Server dokumentieren. 9. DNS-Suffix und Suchliste prüfen. 10. VPN und virtuelle Adapter berücksichtigen. 11. jeden eingetragenen DNS-Server einzeln abfragen. 12. Antworten und TTL miteinander vergleichen. 13. A- und AAAA-Records getrennt prüfen. 14. CNAME-Kette untersuchen. 15. zurückgegebene IP-Adressen einzeln testen. 16. Clientcache anzeigen und dokumentieren. 17. negative Cacheeinträge berücksichtigen. 18. `hosts`-Datei kontrollieren. 19. Zone und Resource Record auf dem DNS-Server prüfen. 20. Record auf allen zuständigen DNS-Servern vergleichen. 21. Zonen- oder AD-Replikation untersuchen. 22. Forwarder und Conditional Forwarder prüfen. 23. Delegation und Nameserver prüfen. 24. UDP und TCP 53 unterscheiden. 25. Split-DNS berücksichtigen. 26. VPN-Routing, DNS-Zuweisung und NRPT prüfen. 27. DoH und anwendungseigene Resolver berücksichtigen. 28. genau eine Hypothese formulieren. 29. genau eine kontrollierte Maßnahme durchführen. 30. dieselben Abfragen erneut ausführen. 31. jeden vorgesehenen DNS-Server erneut testen. 32. den benötigten Dienst über den Namen prüfen. 33. Vergleichsclient oder Vergleichsstandort testen. 34. temporäre Diagnoseänderungen entfernen. 35. Ursache, Maßnahme und Nachweis dokumentieren. --- **29. Checkliste „Name geht nicht, IP geht“** - [ ] 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](https://learn.microsoft.com/en-us/powershell/module/dnsclient/) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Get-DnsClientServerAddress](https://learn.microsoft.com/en-us/powershell/module/dnsclient/get-dnsclientserveraddress) - [Microsoft Learn – Get-DnsClient](https://learn.microsoft.com/en-us/powershell/module/dnsclient/get-dnsclient) - [Microsoft Learn – Get-DnsClientGlobalSetting](https://learn.microsoft.com/en-us/powershell/module/dnsclient/get-dnsclientglobalsetting) - [Microsoft Learn – Get-DnsClientCache](https://learn.microsoft.com/en-us/powershell/module/dnsclient/get-dnsclientcache) - [Microsoft Learn – Clear-DnsClientCache](https://learn.microsoft.com/en-us/powershell/module/dnsclient/clear-dnsclientcache) - [Microsoft Learn – Get-DnsClientDohServerAddress](https://learn.microsoft.com/en-us/powershell/module/dnsclient/get-dnsclientdohserveraddress) - [Microsoft Learn – Secure DNS Client over HTTPS](https://learn.microsoft.com/en-us/windows-server/networking/dns/doh-client-support) - [Microsoft Learn – nslookup](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/nslookup) - [Microsoft Learn – ipconfig](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – DNS zones](https://learn.microsoft.com/en-us/windows-server/networking/dns/zone-types) - [Microsoft Learn – Manage DNS zones](https://learn.microsoft.com/en-us/windows-server/networking/dns/manage-dns-zones) - [Microsoft Learn – DNS forwarding](https://learn.microsoft.com/en-us/windows-server/networking/dns/forwarding) - [Microsoft Learn – Get-DnsServerZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverzone) - [Microsoft Learn – Get-DnsServerResourceRecord](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverresourcerecord) - [Microsoft Learn – Get-DnsServerForwarder](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverforwarder) - [Microsoft Learn – Get-DnsServerConditionalForwarderZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverconditionalforwarderzone) - [Microsoft Learn – Best practices for DNS client settings](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/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: ```text 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: ```cmd ipconfig /all ``` ```powershell Get-NetAdapter ``` ```powershell Get-NetIPConfiguration ``` ```powershell Get-NetIPAddress ``` ```powershell Get-NetRoute -AddressFamily IPv4 ``` Unter Linux: ```bash ip link show ``` ```bash ip address show ``` ```bash ip route show ``` Unter macOS: ```bash ifconfig ``` ```bash 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: ```powershell Get-NetAdapter | Format-Table Name, InterfaceDescription, Status, LinkSpeed, MacAddress ``` Auf einem Cisco-IOS-/IOS-XE-Switch beispielsweise: ```text show interfaces status ``` Gezielten Port prüfen: ```text show interfaces GigabitEthernet1/0/12 ``` Kurze Fehlerübersicht: ```text 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: ```text show cdp neighbors ``` Details: ```text show cdp neighbors detail ``` Link Layer Discovery Protocol: ```text show lldp neighbors ``` Details: ```text 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: ```text show vlan brief ``` Portbezogene Switchportinformationen: ```text show interfaces GigabitEthernet1/0/12 switchport ``` Relevante Portkonfiguration: ```text 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: ```text interface GigabitEthernet1/0/12 switchport mode access switchport access vlan 20 ``` **Mögliche Fehler** ```text switchport access vlan 10 ``` obwohl der Client VLAN 20 verwenden soll. Oder der Port arbeitet unerwartet als Trunk: ```text 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** ```text show vlan brief ``` Gezielt: ```text 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: ```powershell Get-NetAdapter | Format-Table Name, MacAddress, Status ``` Unter Linux: ```bash ip link show ``` Unter macOS: ```bash 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: ```text 00-11-22-33-44-55 ``` Auf Cisco-Switches wird sie normalerweise ohne Trennzeichen oder mit Punktgruppen gesucht: ```text 0011.2233.4455 ``` --- **10. MAC-Adress-Tabelle prüfen** Gesamte Tabelle: ```text show mac address-table ``` Bestimmte MAC-Adresse suchen: ```text show mac address-table address 0011.2233.4455 ``` MAC-Adressen eines VLANs: ```text show mac address-table vlan 20 ``` MAC-Adressen eines Ports: ```text 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: ```text 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: ```text show mac address-table address 0011.2233.4455 ``` Erwartung: ```text VLAN 20 -> GigabitEthernet1/0/12 ``` Prüfung auf dem Distribution-Switch: ```text show mac address-table address 0011.2233.4455 ``` Erwartung: ```text VLAN 20 -> GigabitEthernet1/0/48 ``` oder: ```text 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: ```text show interfaces trunk ``` Gezielten Port prüfen: ```text show interfaces GigabitEthernet1/0/48 switchport ``` Konfiguration anzeigen: ```text 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: ```text 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** ```text show interfaces trunk ``` Beispiel eines Fehlers: ```text Access-Switch: Allowed VLANs: 10,20,30 ``` ```text 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: ```text show interfaces trunk ``` ```text show interfaces switchport ``` Beispiel eines Mismatch: ```text 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: ```text 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: ```text interface GigabitEthernet1/0/12 switchport mode access switchport access vlan 20 switchport voice vlan 30 ``` Dabei kann gelten: ```text 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: ```powershell Get-NetNeighbor ``` ```cmd arp -a ``` Unter Linux: ```bash ip neighbor show ``` Unter macOS: ```bash 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: ```text show ip interface brief ``` Gezielt: ```text show interfaces Vlan20 ``` Konfiguration: ```text show running-config interface Vlan20 ``` ARP-Tabelle: ```text 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** ```text 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: 1. eigene IP-Konfiguration, 2. Ziel im gleichen VLAN, 3. Standardgateway, 4. Ziel in einem anderen internen VLAN, 5. externes Ziel. Windows: ```powershell Test-NetConnection -ComputerName ``` ```powershell Test-NetConnection -ComputerName ``` ```powershell 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: ```text show spanning-tree ``` Bestimmtes VLAN: ```text show spanning-tree vlan 20 ``` Bestimmten Port: ```text 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** ```text show spanning-tree detail ``` Zusätzlich Systemprotokoll prüfen: ```text 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: ```text show logging ``` MAC-Adresse gezielt suchen: ```text show mac address-table address ``` Wiederholt prüfen, ob der Port wechselt. Beispiel: ```text 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: ```text show etherchannel summary ``` Port-Channel prüfen: ```text show interfaces Port-channel1 ``` Trunkstatus: ```text show interfaces trunk ``` Konfiguration der Mitglieder vergleichen: ```text show running-config interface GigabitEthernet1/0/47 ``` ```text 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: ```text show port-security ``` Gezielter Port: ```text show port-security interface GigabitEthernet1/0/12 ``` Portstatus: ```text 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: ```text show authentication sessions ``` ```text show dot1x all ``` ```text show ip dhcp snooping ``` ```text show ip arp inspection ``` ```text show interfaces status err-disabled ``` ```text 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** ```text show interfaces status err-disabled ``` ```text show errdisable recovery ``` ```text 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: ```text 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: ```text vlan ``` Bestimmte VLAN-ID: ```text vlan.id == 20 ``` ARP: ```text arp ``` DHCP: ```text dhcp ``` LLDP: ```text lldp ``` STP: ```text 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** ```text Clientport: GigabitEthernet1/0/12 Access-VLAN: 20 Gateway: 192.0.2.1 Uplink: GigabitEthernet1/0/48 ``` **Clientprüfung** ```cmd ipconfig /all ``` Ergebnis: ```text IPv4-Adresse: 192.0.2.45 Gateway: 192.0.2.1 ``` **Portprüfung** ```text show interfaces GigabitEthernet1/0/12 switchport ``` Ergebnis: ```text Operational Mode: static access Access Mode VLAN: 20 ``` **MAC-Prüfung** ```text show mac address-table address 0011.2233.4455 ``` Ergebnis: ```text VLAN 20 0011.2233.4455 DYNAMIC Gi1/0/12 ``` Der Client wird am richtigen lokalen Port und im richtigen VLAN gelernt. **Trunkprüfung** ```text show interfaces trunk ``` Ergebnis am Access-Switch: ```text Port Gi1/0/48 Allowed VLANs: 10,20,30 ``` Ergebnis am Distribution-Switch: ```text 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: ```text show interfaces trunk ``` Ergebnis: ```text Allowed VLANs: 10,20,30 ``` MAC-Adresse auf dem Distribution-Switch: ```text show mac address-table address 0011.2233.4455 ``` Ergebnis: ```text VLAN 20 0011.2233.4455 DYNAMIC Gi1/0/48 ``` Clienttest: ```powershell 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** ```text show mac address-table address 0011.2233.4455 ``` Ergebnis: ```text 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** 1. genaue Störung, Zeitpunkt und Auswirkung dokumentieren. 2. feststellen, ob ein oder mehrere Clients betroffen sind. 3. vorgesehenes VLAN, Subnetz und Gateway ermitteln. 4. tatsächliche Client-MAC-Adresse feststellen. 5. tatsächlichen Switch und Port ermitteln. 6. physischen Linkstatus prüfen. 7. Fehlerzähler dokumentieren. 8. Portmodus prüfen. 9. Access- und Voice-VLAN prüfen. 10. Existenz und Status des VLANs prüfen. 11. Client-MAC in der MAC-Tabelle suchen. 12. MAC-Adresse über alle beteiligten Switches verfolgen. 13. jeden Uplink und Trunk ermitteln. 14. operativen Trunkstatus prüfen. 15. Allowed-VLAN-Listen auf beiden Seiten vergleichen. 16. Native VLAN auf beiden Seiten vergleichen. 17. VLAN-Existenz auf jedem Switch prüfen. 18. Spanning-Tree-Zustand für das betroffene VLAN prüfen. 19. blockierte oder inkonsistente Ports untersuchen. 20. Topology Changes und MAC-Flapping prüfen. 21. EtherChannel und seine Mitglieder prüfen. 22. Port-Security und `err-disabled` prüfen. 23. 802.1X, NAC und dynamische VLAN-Zuweisung berücksichtigen. 24. DHCP Snooping, ARP Inspection und IP Source Guard prüfen. 25. Gateway-SVI und dessen Status prüfen. 26. ARP- beziehungsweise Neighbor-Einträge untersuchen. 27. Kommunikation im gleichen VLAN testen. 28. Gateway separat testen. 29. Inter-VLAN-Kommunikation separat testen. 30. bei Bedarf autorisierten Paketmitschnitt durchführen. 31. genau eine Hypothese formulieren. 32. genau eine kontrollierte Maßnahme durchführen. 33. Port-, VLAN-, Trunk-, STP- und MAC-Zustand erneut prüfen. 34. Clientverbindung und benötigten Dienst erneut testen. 35. Ursache, Änderung und Nachweis dokumentieren. --- **33. Checkliste VLAN und Switching** - [ ] 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](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9600/software/release/17-14/configuration_guide/vlan/b_1714_vlan_9600_cg/configuring_vlans.html) - [Cisco – Configuring VLAN Trunks](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9400/software/release/17-14/configuration_guide/vlan/b_1714_vlan_9400_cg/configuring_vlan_trunks.html) - [Cisco – Configure and Troubleshoot Inter-VLAN Routing](https://www.cisco.com/c/en/us/support/docs/lan-switching/inter-vlan-routing/41260-189.html) - [Cisco – Troubleshoot LAN Switching Environments](https://www.cisco.com/c/en/us/support/docs/lan-switching/ethernet/12006-chapter22.html) - [Cisco – Troubleshoot Spanning Tree Issues](https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/28943-170.html) - [Cisco – Troubleshoot Spanning Tree PVID and Type Inconsistencies](https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24063-pvid-inconsistency-24063.html) - [Cisco – Troubleshoot MAC Flaps and Loops](https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol-stp-8021d/221722-troubleshoot-mac-flaps-loop-on-cisco-cat.html) - [Cisco – Understand Rapid Spanning Tree Protocol](https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24062-146.html) - [Cisco – IOS LAN Switching Command Reference](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/lanswitch/command/lsw-cr-book/lsw-s2.html) - [Microsoft Learn – Get-NetAdapter](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapter) - [Microsoft Learn – Get-NetIPConfiguration](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netipconfiguration) - [Microsoft Learn – Get-NetIPAddress](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netipaddress) - [Microsoft Learn – Get-NetNeighbor](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netneighbor) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Wireshark – IEEE 802.1Q VLAN Display Filter Reference](https://www.wireshark.org/docs/dfref/v/vlan.html) - [Wireshark – VLAN Capture Setup](https://wiki.wireshark.org/CaptureSetup/VLAN) - [Wireshark – PCAP Filter Reference](https://www.wireshark.org/docs/man-pages/pcap-filter.html) # 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** ```text Das Netzwerk ist langsam. ``` **Geeignete Beschreibung** ```text 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. ```text 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: ```text 1 Byte = 8 Bit ``` Beispiel: ```text 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: ```powershell Get-NetAdapter | Format-Table Name, InterfaceDescription, Status, LinkSpeed, MacAddress ``` Ausführliche IP-Konfiguration: ```powershell Get-NetIPConfiguration ``` Aktive IP-Adressen: ```powershell Get-NetIPAddress ``` Unter Linux: ```bash ip link show ``` ```bash ip address show ``` Unter macOS: ```bash 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: ```powershell Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric | Format-Table DestinationPrefix, NextHop, InterfaceAlias, RouteMetric ``` --- **5. Linkgeschwindigkeit und Duplex prüfen** Unter Windows: ```powershell Get-NetAdapter | Format-Table Name, Status, LinkSpeed ``` Auf Cisco-IOS-/IOS-XE-Switches beispielsweise: ```text show interfaces status ``` Gezielter Port: ```text 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** ```text 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: ```powershell Get-NetAdapterStatistics ``` Alle verfügbaren Werte eines Adapters: ```powershell Get-NetAdapterStatistics -Name "Ethernet" | Format-List * ``` Unter Linux: ```bash ip -s link show ``` Alternativ, sofern vorhanden: ```bash ethtool -S ``` Auf Cisco-Switches: ```text show interfaces GigabitEthernet1/0/12 ``` Kurze Fehlerübersicht: ```text 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. ```text Ausgangswert: 12 CRC-Fehler Nach 10 Minuten: 12 CRC-Fehler ``` Der Wert ist historisch vorhanden, steigt während des Tests jedoch nicht. ```text 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: ```cmd ping -n 20 ``` Mit festgelegter Paketgröße: ```cmd ping -n 20 -l 1400 ``` Linux: ```bash ping -c 20 ``` macOS: ```bash ping -c 20 ``` Zu dokumentieren sind: - Minimum, - Maximum, - Durchschnitt, - Paketverlust, - starke Abweichungen einzelner Antworten, - Unterschiede zu einem Referenzwert. **Beispiel** ```text 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: 1. eigenes TCP/IP-System, 2. Standardgateway, 3. Ziel im gleichen VLAN, 4. Ziel in einem anderen internen VLAN, 5. interner Server, 6. externes Ziel. Beispiel: ```cmd ping -n 20 ``` ```cmd ping -n 20 ``` ```cmd 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: ```cmd tracert -d ``` ```cmd pathping -n ``` PowerShell: ```powershell Test-NetConnection -ComputerName -TraceRoute ``` Unter Linux: ```bash traceroute -n ``` Alternativ, sofern vorhanden: ```bash mtr -n ``` Unter macOS: ```bash 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: ```bash iperf3 -s ``` Auf dem Client: ```bash iperf3 -c ``` Längere Messung: ```bash iperf3 -c -t 30 ``` Umgekehrte Richtung: ```bash iperf3 -c -R ``` Mehrere parallele Datenströme: ```bash iperf3 -c -P 4 ``` Bidirektionaler Test, sofern von der verwendeten Version unterstützt: ```bash iperf3 -c --bidir ``` UDP-Test nur mit kontrollierter Bandbreite: ```bash 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. ```text Client | Access-Switch | Distribution-Switch | Firewall oder Router | WAN oder Internet | Zielserver ``` Mögliche Vergleichsmessungen: ```text 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: ```text show interfaces status ``` ```text show interfaces counters errors ``` ```text show interfaces GigabitEthernet1/0/12 ``` Uplink prüfen: ```text 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** ```text 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: ```cmd 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** ```text 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: ```cmd 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: ```cmd ping -f -l 1400 ``` Linux: ```bash 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: ```text tcp.analysis.retransmission ``` Weitere mögliche Wiederholungen: ```text tcp.analysis.fast_retransmission ``` ```text tcp.analysis.spurious_retransmission ``` Verloren vermutete Segmente: ```text tcp.analysis.lost_segment ``` Empfangsfenster vollständig belegt: ```text tcp.analysis.window_full ``` Empfänger meldet ein Empfangsfenster von null: ```text tcp.analysis.zero_window ``` Alle TCP-Analysehinweise: ```text 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: ```text ip.addr == && ip.addr == ``` Nur TCP-Verkehr zwischen zwei Systemen: ```text tcp && ip.addr == && ip.addr == ``` TCP-Analysehinweise: ```text tcp.analysis.flags ``` ICMP-Fehlermeldungen: ```text icmp ``` DNS: ```text 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** ```text 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: ```powershell Get-Counter '\Processor(_Total)\% Processor Time' ``` ```powershell Get-Counter '\Memory\Available MBytes' ``` Netzwerkadapterstatistik: ```powershell Get-NetAdapterStatistics ``` Aktuelle TCP-Verbindungen: ```powershell Get-NetTCPConnection ``` Unter Linux: ```bash top ``` ```bash free -h ``` ```bash vmstat 1 ``` ```bash iostat -xz 1 ``` ```bash 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: ```text 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: ```text 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** ```text 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** ```cmd ping 192.0.2.80 -n 20 ``` Ergebnis: ```text Durchschnitt: 2 ms Paketverlust: 0 % ``` **Durchsatztest** ```bash iperf3 -c 192.0.2.80 -t 30 ``` Ergebnis: ```text Durchschnittlicher Durchsatz: 92 Mbit/s Retransmissions: erhöht ``` **Clientport** ```text show interfaces GigabitEthernet1/0/12 ``` Ergebnis: ```text Full-duplex, 1000 Mb/s Keine zunehmenden CRC-Fehler ``` **Uplinkprüfung** ```text show interfaces TenGigabitEthernet1/1/1 ``` Ergebnis: ```text Auslastung: 99 % Output Drops steigen ``` **Zeitlicher Vergleich** ```text 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** ```bash iperf3 -c 192.0.2.80 -t 30 ``` Ergebnis: ```text 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** ```text Ping: 1 ms Paketverlust: 0 % iperf3: 935 Mbit/s Interfacefehler: keine Zunahme ``` **Serverprüfung** ```text 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** 1. genaue Anwendung und Benutzeraktion ermitteln. 2. erwartete und tatsächliche Leistung dokumentieren. 3. Beginn, Dauer und zeitliches Muster bestimmen. 4. feststellen, ob ein oder mehrere Benutzer betroffen sind. 5. WLAN und Ethernet getrennt betrachten. 6. lokales und entferntes Ziel vergleichen. 7. Upload und Download getrennt prüfen. 8. tatsächlich verwendeten Netzwerkadapter feststellen. 9. Linkgeschwindigkeit und Duplex prüfen. 10. Fehler- und Verwerfungszähler dokumentieren. 11. Gateway, lokales Ziel und entferntes Ziel anpingen. 12. Latenz, Schwankung und Paketverlust vergleichen. 13. tatsächlichen Netzwerkpfad ermitteln. 14. Durchsatz mit einem autorisierten Testsystem messen. 15. beide Übertragungsrichtungen prüfen. 16. Netzwerkpfad in einzelne Segmente unterteilen. 17. Access-Port, Uplink und Serverport prüfen. 18. Auslastung und Warteschlangen untersuchen. 19. WLAN-Signal, SNR, Kanal und Airtime prüfen. 20. Firewall, Router, Proxy und VPN untersuchen. 21. MTU und mögliche Fragmentierungsprobleme prüfen. 22. TCP-Wiederholungen und Empfangsfenster untersuchen. 23. Anwendung und Netzwerk getrennt testen. 24. CPU, Arbeitsspeicher und Storage des Servers prüfen. 25. geplante Backups, Scans und Synchronisationen berücksichtigen. 26. Messwerte mit einer Baseline vergleichen. 27. genau eine Hypothese formulieren. 28. genau eine kontrollierte Änderung durchführen. 29. ursprüngliche Messungen wiederholen. 30. Nebenwirkungen und Sicherheitsfunktionen prüfen. 31. temporäre Diagnoseänderungen entfernen. 32. Ursache, Maßnahme, Rollback und Nachweis dokumentieren. --- **31. Checkliste „Netzwerk ist langsam“** - [ ] 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](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapterstatistics) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – ping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping) - [Microsoft Learn – tracert](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/tracert) - [Microsoft Learn – pathping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pathping) - [ESnet – iperf3 Documentation](https://software.es.net/iperf/) - [ESnet – Invoking iperf3](https://software.es.net/iperf/invoking.html) - [ESnet – iperf3 FAQ](https://software.es.net/iperf/faq.html) - [Cisco – Troubleshoot Switch Port and Interface Problems](https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/12027-53.html) - [Cisco – Troubleshoot Interface CRC Errors](https://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-aggregation-services-routers/225385-troubleshoot-interface-crc-errors-on.html) - [Cisco – RF Health and Wireless Troubleshooting](https://developer.cisco.com/docs/wireless-troubleshooting-tools/wlcca-rf-health/) - [Cisco – RF Analysis Tools](https://developer.cisco.com/docs/wireless-troubleshooting-tools/rf-analysis/) - [Wireshark – TCP Analysis](https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html) - [Wireshark – TCP Display Filter Reference](https://www.wireshark.org/docs/dfref/t/tcp.html) - [Wireshark – User’s Guide](https://www.wireshark.org/docs/wsug_html/) # 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. ```text 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: ```text Der Fehler ist im aktuellen Moment nicht sichtbar. ``` Es bedeutet nicht: ```text 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: ```text Der Fehler war heute Nachmittag. ``` Besser: ```text 02.08.2026, ungefähr 14:17 Uhr ``` Optimal: ```text 02.08.2026, 14:17:32 bis 14:17:47 Uhr ``` Zusätzlich dokumentieren: ```text 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: ```cmd w32tm /query /status ``` Konfigurierte Zeitquelle: ```cmd w32tm /query /source ``` Unter Linux: ```bash timedatectl status ``` Bei chrony, sofern eingesetzt: ```bash chronyc tracking ``` ```bash chronyc sources ``` **Beispiel** ```text 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: 1. Ist nur ein Benutzer betroffen? 2. Sind mehrere Benutzer betroffen? 3. Sind alle Benutzer eines Standorts betroffen? 4. Ist nur eine Anwendung betroffen? 5. Sind mehrere Dienste gleichzeitig betroffen? 6. Ist nur ein Client betroffen? 7. Sind alle Geräte an einem Switch betroffen? 8. Sind ausschließlich WLAN-Clients betroffen? 9. Sind nur VPN-Verbindungen betroffen? 10. Ist nur eine Übertragungsrichtung betroffen? 11. Ist nur ein bestimmter Server betroffen? 12. Sind interne und externe Ziele betroffen? **Bewertung** | Beobachtung | Möglicher Prüfbereich | |---|---| | nur ein Benutzer | Benutzerprofil, Sitzung oder Berechtigung | | nur ein Client | Client, Treiber, Kabel, WLAN oder lokale Software | | mehrere Clients am gleichen Switch | Switch, Uplink oder Stromversorgung | | alle WLAN-Clients eines Access Points | Access Point, Funkkanal oder AP-Uplink | | mehrere Dienste auf einem Server | Server, Betriebssystem oder gemeinsame Ressource | | mehrere Systeme gleichzeitig | Netzwerk, DNS, Authentifizierung, Storage oder Infrastruktur | | nur VPN-Benutzer | Internetzugang, Tunnel, Gateway, MTU oder Sitzungszeit | | alle Standorte gleichzeitig | zentrales System, Provider oder übergreifender Dienst | --- **9. Fehler automatisiert erfassen** Ein sporadischer Fehler sollte möglichst durch wiederholte Messungen sichtbar gemacht werden. Geeignete Messwerte sind beispielsweise: - 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** ```text Zeitstempel + Messwert + Ziel + Ergebnis ``` Beispiel: ```text 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: ```cmd ping -t ``` Der Test wird mit `Strg + C` beendet. Aussagekräftiger ist eine protokollierte PowerShell-Messung mit Zeitstempel: ```powershell 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: ```powershell 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: ```bash ping ``` macOS: ```bash ping ``` Mit Zeitstempeln unter Linux, sofern `ping` diese Option unterstützt: ```bash ping -D ``` Alternativ kann eine kontrollierte Schleife verwendet werden: ```bash 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: ```bash 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. ```text Client | Standardgateway | interner Server | externer Dienst ``` Beispiel: ```text 14:17:35 | Gateway erreichbar 14:17:35 | interner Server nicht erreichbar 14:17:35 | externer Dienst nicht erreichbar ``` Mögliche Eingrenzung: ```text Clientzugang funktioniert. Die Störung beginnt hinter dem Gateway oder auf einem gemeinsamen Folgepfad. ``` Anderes Beispiel: ```text 14:17:35 | Gateway nicht erreichbar 14:17:35 | interner Server nicht erreichbar 14:17:35 | externer Dienst nicht erreichbar ``` Mögliche Eingrenzung: ```text 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: ```powershell 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: ```powershell 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: ```powershell 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: ```bash journalctl \ --since "2026-08-02 14:15:00" \ --until "2026-08-02 14:20:00" ``` Nur Meldungen eines bestimmten Dienstes: ```bash journalctl \ -u \ --since "2026-08-02 14:15:00" \ --until "2026-08-02 14:20:00" ``` Kernelmeldungen: ```bash journalctl \ -k \ --since "2026-08-02 14:15:00" \ --until "2026-08-02 14:20:00" ``` Nur Warnungen und schwerwiegendere Meldungen: ```bash journalctl -p warning \ --since "2026-08-02 14:15:00" \ --until "2026-08-02 14:20:00" ``` Live verfolgen: ```bash 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** ```text 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: ```text 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: ```bash dumpcap -D ``` Beispiel für einen Ringpuffer: ```bash dumpcap \ -i 1 \ -b duration:300 \ -b files:12 \ -w sporadischer-fehler.pcapng ``` Bedeutung: ```text -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: ```text 12 Dateien × 5 Minuten = 60 Minuten ``` Mitschnitt auf einen bestimmten Host begrenzen: ```bash 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: ```text 14:17:31 Interface down 14:17:34 Interface up 14:18:02 Interface down 14:18:05 Interface up ``` Unter Windows: ```powershell Get-NetAdapter | Format-Table Name, Status, LinkSpeed, InterfaceDescription ``` Statistiken: ```powershell Get-NetAdapterStatistics ``` Unter Linux: ```bash ip link show ``` ```bash ip -s link show ``` Kernelmeldungen zum Netzwerk: ```bash journalctl -k | grep -Ei "link.*(up|down)|carrier|network" ``` Auf Cisco-IOS-/IOS-XE-Switches beispielsweise: ```text show logging ``` ```text show interfaces status ``` ```text 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** ```text 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** ```text 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: ```cmd 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: ```bash journalctl | grep -Ei "dhcp|lease" ``` Mögliche Hinweise: ```text 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: ```powershell Resolve-DnsName ``` DNS-Cache anzeigen: ```cmd ipconfig /displaydns ``` Unter Linux oder macOS, sofern `dig` vorhanden ist: ```bash dig ``` Wiederholte Abfrage: ```bash 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** ```text 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** ```text 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: ```bash openssl s_client \ -connect :443 \ -servername ``` Nur Zertifikatsdaten ausgeben: ```bash 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** ```text 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: ```powershell Get-ScheduledTask | Select-Object TaskName, TaskPath, State ``` Weitere Informationen: ```powershell Get-ScheduledTask | Get-ScheduledTaskInfo | Select-Object TaskName, LastRunTime, LastTaskResult, NextRunTime ``` Unter Linux mit systemd: ```bash 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** ```text 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: ```text 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: ```text 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: ```cmd netsh wlan show interfaces ``` Bericht zur WLAN-Nutzung: ```cmd 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. ```text 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** ```text 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: ```text 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: 1. nur autorisierte Tests durchführen, 2. Ausgangszustand dokumentieren, 3. erwartete Beobachtung festlegen, 4. nur einen Einflussfaktor verändern, 5. Messwerte während des Tests erfassen, 6. Test bei unerwarteten Auswirkungen abbrechen, 7. ursprünglichen Zustand wiederherstellen, 8. Ergebnis dokumentieren. Ein produktiver Fehler darf nicht absichtlich durch riskante Last, Stromunterbrechung, Sicherheitsdeaktivierung oder unkontrollierte Netzwerkänderung provoziert werden. --- **32. Hypothese messbar formulieren** Ungeeignet: ```text Vielleicht ist das Netzwerk schuld. ``` Besser: ```text Wenn der Fehler auftritt, verliert der Client vermutlich kurzzeitig die Verbindung zum Standardgateway. ``` Prüfung: ```text Client → Gateway kontinuierlich messen Client → Server kontinuierlich messen Client- und Switchportprotokolle vergleichen ``` Noch genauer: ```text 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: ```text 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** ```text Ä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** ```text 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: ```text 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** ```text 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** ```text 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** ```text 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** ```text 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** ```text Ursprünglichen Zeitplan und ursprüngliche Bandbreitenrichtlinie wiederherstellen. ``` **Verifikation** ```text 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** ```text Anmeldung: 08:05 Uhr Fehler: 16:05 Uhr Sitzungsdauer: 8 Stunden ``` Weitere Tage: ```text 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** ```text 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** ```text 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** 1. genaue Fehlermeldung und Benutzeraktion erfassen. 2. exakten Zeitpunkt und Dauer dokumentieren. 3. betroffenen Benutzer, Client und Standort bestimmen. 4. betroffene Anwendung und Zielsysteme erfassen. 5. prüfen, ob ein oder mehrere Benutzer betroffen sind. 6. feste Uhrzeit von fester Laufzeit unterscheiden. 7. Häufigkeit und wiederkehrendes Muster bestimmen. 8. Zeitsynchronisation aller beteiligten Systeme prüfen. 9. Monitoring- und Protokollaufbewahrung prüfen. 10. kontinuierliche Messung mit Zeitstempeln einrichten. 11. Gateway, internes Ziel und externes Ziel vergleichen. 12. TCP-Port und Anwendungsantwort getrennt prüfen. 13. Windows- oder Linux-Protokolle zeitlich filtern. 14. Client-, Netzwerk- und Serverprotokolle vergleichen. 15. Monitoringauflösung kontrolliert erhöhen. 16. Schnittstellenstatus und Link-Flaps beobachten. 17. Fehler- und Verwerfungszähler als Verlauf erfassen. 18. WLAN-Ereignisse, Roaming und Retry-Rate prüfen. 19. DHCP-Lease und mögliche Adresskonflikte untersuchen. 20. DNS-Auflösung, TTL und unterschiedliche Antworten prüfen. 21. Sitzungslaufzeiten, Token und Timeouts vergleichen. 22. Zertifikatslaufzeiten und Serverknoten prüfen. 23. geplante Aufgaben, Timer und Cronjobs untersuchen. 24. Backups, Scans, Updates und Replikationen vergleichen. 25. CPU, Arbeitsspeicher, Storage und Netzwerk überwachen. 26. Temperatur, Stromversorgung und PoE berücksichtigen. 27. WAN-, Provider- und VPN-Ereignisse prüfen. 28. bei Bedarf autorisierten Ringpuffer-Mitschnitt einrichten. 29. alle Ereignisse auf einer gemeinsamen Zeitleiste darstellen. 30. zuerst auftretendes Ereignis von Folgefehlern unterscheiden. 31. genau eine messbare Hypothese formulieren. 32. kontrollierte Reproduktion planen. 33. Ausgangszustand und Rollback dokumentieren. 34. genau eine freigegebene Änderung durchführen. 35. ursprüngliche Messungen wiederholen. 36. ausreichend langen Beobachtungszeitraum einhalten. 37. Nebenwirkungen und Sicherheitsfunktionen kontrollieren. 38. temporäre Diagnosemaßnahmen entfernen. 39. Ursache, Maßnahme, Rollback und Nachweis dokumentieren. --- **41. Checkliste „Fehler tritt nur manchmal auf“** - [ ] 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](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [Microsoft Learn – Test-Connection](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-connection) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Get-NetAdapterStatistics](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapterstatistics) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – w32tm](https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings) - [Microsoft Learn – netsh wlan](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-wlan) - [Microsoft Learn – Get-ScheduledTask](https://learn.microsoft.com/en-us/powershell/module/scheduledtasks/get-scheduledtask) - [systemd – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [systemd – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [Wireshark – dumpcap Manual Page](https://www.wireshark.org/docs/man-pages/dumpcap.html) - [Wireshark – Capture Setup](https://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureOptions.html) - [Wireshark – User’s Guide](https://www.wireshark.org/docs/wsug_html/) - [Cisco – Troubleshoot Port Flaps on Catalyst 9000 Series Switches](https://www.cisco.com/c/en/us/support/docs/switches/catalyst-9500-series-switches/218397-troubleshoot-port-flaps-on-catalyst-9000.html) - [Cisco – Troubleshoot Link Flap Issues on Nexus 9000](https://www.cisco.com/c/en/us/support/docs/switches/nexus-9000-series-switches/221572-troubleshoot-link-flap-issue-on-nexus-90.html) # 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: ```text Das Netzwerk ist langsam. ``` Besser: ```text 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** ```text 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** ```text 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: 1. Ist nur ein Benutzer betroffen? 2. Sind mehrere Benutzer betroffen? 3. Ist nur ein Standort betroffen? 4. Sind nur WLAN-Benutzer betroffen? 5. Sind auch kabelgebundene Clients betroffen? 6. Ist nur eine Anwendung langsam? 7. Sind mehrere Dienste desselben Servers betroffen? 8. Sind interne und externe Ziele betroffen? 9. Tritt das Problem zu einer bestimmten Uhrzeit auf? 10. Tritt es nur bei einer bestimmten Datenmenge auf? **Schnelle Eingrenzung** | Beobachtung | Wahrscheinlicher Prüfbereich | |---|---| | nur ein Client betroffen | Client, Treiber, Kabel, WLAN oder lokale Software | | mehrere Clients gleichzeitig betroffen | gemeinsame Infrastruktur oder zentraler Dienst | | nur ein Standort betroffen | Standortanbindung, Switch, WLAN oder WAN | | nur WLAN betroffen | Funkstrecke, Access Point, Kanal oder Roaming | | LAN und WLAN betroffen | gemeinsamer Netzwerkpfad, Server oder Anwendung | | nur eine Anwendung betroffen | Anwendung, Datenbank, API oder Sitzung | | mehrere Dienste eines Servers betroffen | Server, Betriebssystem, Storage oder Hypervisor | | alle internen Dienste langsam | Netzwerk, DNS, Firewall oder zentrale Infrastruktur | | nur Internet langsam | WAN, Provider, Proxy oder externe Ziele | | nur große Dateien langsam | Durchsatz, Paketverlust, Storage oder Übertragungsweg | | kleine Anfragen bereits langsam | Latenz, DNS, Anwendung oder Datenbank | --- **6. Vergleich mit einer funktionierenden Referenz** Ein Vergleichssystem sollte möglichst ähnlich sein: - 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** ```text 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: ```powershell Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 Name, CPU, WorkingSet ``` Netzwerkadapter anzeigen: ```powershell Get-NetAdapter | Format-Table Name, Status, LinkSpeed, InterfaceDescription ``` Adapterstatistiken: ```powershell Get-NetAdapterStatistics ``` Aktuelle IP-Konfiguration: ```cmd ipconfig /all ``` Unter Linux: ```bash top ``` Alternativ, sofern installiert: ```bash htop ``` Arbeitsspeicher: ```bash free -h ``` Datenträgerbelegung: ```bash df -h ``` Netzwerkschnittstellen: ```bash ip link show ``` Statistiken: ```bash 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: ```cmd ping -t ``` Beispiel: ```cmd ping -t 192.0.2.10 ``` Unter Linux oder macOS: ```bash ping ``` Es sollten mehrere Ziele verglichen werden: ```text 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: ```cmd tracert ``` Unter Linux: ```bash traceroute ``` Unter macOS: ```bash traceroute ``` Falls vorhanden, kann eine fortlaufende Pfadanalyse durchgeführt werden: ```bash 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: ```powershell Test-NetConnection -Port ``` Beispiel: ```powershell Test-NetConnection fileserver.example.local -Port 445 ``` Weitere Beispiele: ```powershell Test-NetConnection webserver.example.local -Port 443 ``` ```powershell Test-NetConnection dbserver.example.local -Port 1433 ``` Unter Linux oder macOS, sofern Netcat vorhanden ist: ```bash nc -vz ``` Beispiel: ```bash 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: ```bash 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: ```text 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** ```text 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: ```powershell Measure-Command { Resolve-DnsName } ``` Einzelne DNS-Abfrage: ```powershell Resolve-DnsName ``` Unter Linux oder macOS, sofern `dig` vorhanden ist: ```bash dig ``` Kurze Ausgabe: ```bash 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** ```text 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: ```bash iperf3 -s ``` Client: ```bash iperf3 -c ``` Messung in Gegenrichtung: ```bash iperf3 -c -R ``` Mehrere parallele Verbindungen: ```bash iperf3 -c -P 4 ``` UDP-Tests dürfen nur kontrolliert und mit begrenzter Bandbreite durchgeführt werden: ```bash 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: ```text 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** ```text 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: ```powershell Get-NetAdapterStatistics ``` Unter Linux: ```bash 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** ```text 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. ```text 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: ```cmd netsh wlan show interfaces ``` WLAN-Bericht: ```cmd 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: ```text 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: ```bash uptime ``` ```bash free -h ``` ```bash df -h ``` ```bash top ``` Falls installiert: ```bash vmstat 1 ``` ```bash iostat -xz 1 ``` Unter Windows können Task-Manager, Ressourcenmonitor, Leistungsüberwachung und PowerShell verwendet werden. Beispiel für Prozesse mit hoher CPU-Zeit: ```powershell 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** ```text 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** ```text 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** ```text 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** ```text 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: ```text 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** ```text 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** ```text 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`: ```bash 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** ```text 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: ```text Der Server ist wahrscheinlich überlastet. ``` Besser: ```text 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: ```text 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: ```text 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** ```text Ä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** ```text 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** ```text Gateway-Latenz: 1 ms Webserver-Latenz: 2 ms Paketverlust: 0 % TCP-Verbindungsaufbau: 20 ms Zeit bis zum ersten Byte: 7 s ``` **Servermessungen** ```text CPU-Auslastung: 35 % Arbeitsspeicher: unauffällig Netzwerkauslastung: 10 % Storage-Latenz: 6 ms ``` **Datenbankmessung** ```text 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** ```text 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** ```text 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** ```text LAN: normal WLAN außerhalb des Raums: normal WLAN im Besprechungsraum: langsam ``` **Messwerte** ```text 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** ```text 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** 1. genaue Benutzeraktion erfassen. 2. erwartete und tatsächliche Dauer dokumentieren. 3. Startzeitpunkt, Häufigkeit und Dauer bestimmen. 4. betroffene Benutzer, Clients und Standorte erfassen. 5. LAN, WLAN und VPN unterscheiden. 6. einzelne Anwendung und allgemeines Systemverhalten vergleichen. 7. betroffenen Client mit Referenzclient vergleichen. 8. normalen Leistungsbereich als Baseline bestimmen. 9. lokale CPU-, Speicher- und Datenträgerauslastung prüfen. 10. Verbindungsgeschwindigkeit und Adapterstatus prüfen. 11. Gateway, internes Ziel und externes Ziel messen. 12. Latenz und Paketverlust getrennt betrachten. 13. Netzwerkpfad untersuchen. 14. TCP-Port prüfen. 15. DNS-Antwortzeit messen. 16. Anwendungsantwort in einzelne Zeitanteile zerlegen. 17. kontrollierten Durchsatztest durchführen. 18. Interface-Fehler, Drops und Retransmissions prüfen. 19. WLAN-Auslastung und Retry-Rate berücksichtigen. 20. VPN-Pfad und VPN-Gateway prüfen. 21. Server-CPU und Arbeitsspeicher überwachen. 22. Paging, Swapping und Ressourcenlimits prüfen. 23. Storage-Latenz und Warteschlangen untersuchen. 24. Datenbankabfragen, Sperren und Verbindungen prüfen. 25. APIs und externe Abhängigkeiten untersuchen. 26. alle Serverknoten einzeln vergleichen. 27. geplante Aufgaben und Hintergrundprozesse prüfen. 28. Messwerte auf einer gemeinsamen Zeitleiste darstellen. 29. größten Zeitanteil bestimmen. 30. Ursache und Folge unterscheiden. 31. genau eine messbare Hypothese formulieren. 32. Ausgangszustand und Rollback dokumentieren. 33. genau eine freigegebene Änderung durchführen. 34. ursprüngliche Messung wiederholen. 35. ausreichend lange Verifikation durchführen. 36. Nebenwirkungen kontrollieren. 37. temporäre Diagnosemaßnahmen entfernen. 38. Ursache, Maßnahme und Nachweis dokumentieren. --- **41. Checkliste „Netzwerk oder Anwendung ist langsam“** - [ ] 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](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-connection) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Get-NetAdapter](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapter) - [Microsoft Learn – Get-NetAdapterStatistics](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapterstatistics) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – netsh wlan](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-wlan) - [Microsoft Learn – Windows Performance Monitor](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/perfmon) - [curl – Write-Out Variables](https://curl.se/docs/manpage.html#-w) - [iperf3 – Documentation](https://software.es.net/iperf/) - [Wireshark – User’s Guide](https://www.wireshark.org/docs/wsug_html/) - [Wireshark – TCP Analysis](https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html) - [Wireshark – dumpcap Manual Page](https://www.wireshark.org/docs/man-pages/dumpcap.html) - [systemd – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) # 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. ```text 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: ```text Zeitpunkt: betroffener Dienst: gemessene Antwortzeit: CPU: RAM: Datenträger: Netzwerk: auffälliger Prozess: auffälliges Ereignis: laufender Hintergrundjob: letzte Änderung: ``` --- **5. Sichere Schnellprüfung** Die erste Prüfung sollte möglichst nur lesend erfolgen. 1. Zeitpunkt und Umfang der Störung bestimmen. 2. CPU, RAM, Datenträger und Netzwerk gleichzeitig betrachten. 3. Prozesse mit ungewöhnlicher Ressourcennutzung ermitteln. 4. Backups, Virenscans, Snapshots und Wartungsjobs prüfen. 5. Betriebssystem-, Anwendungs- und Hypervisorlogs zeitlich vergleichen. 6. Antwortzeit vom Client und direkt auf dem Server messen. 7. Mit einem funktionierenden Vergleichssystem vergleichen. 8. Erst danach eine kontrollierte Maßnahme auswählen. Windows: ```powershell Get-Date Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 Name, Id, CPU, WorkingSet64 ``` Linux: ```bash 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: ```powershell Get-Counter '\Processor(_Total)\% Processor Time' ``` Prozesse nach gesamter CPU-Zeit sortieren: ```powershell Get-Process | Sort-Object CPU -Descending | Select-Object -First 15 Name, Id, CPU, Threads ``` Aktuelle Prozessorauslastung über CIM: ```powershell Get-CimInstance Win32_Processor | Select-Object Name, LoadPercentage ``` Linux: ```bash top ``` Mit installiertem Paket `sysstat`: ```bash pidstat 1 ``` Auslastung pro logischer CPU: ```bash 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: ```powershell Get-CimInstance Win32_OperatingSystem | Select-Object TotalVisibleMemorySize, FreePhysicalMemory ``` Prozesse nach Arbeitsspeicher sortieren: ```powershell Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 15 Name, Id, WorkingSet64, PagedMemorySize64 ``` Leistungsindikatoren abfragen: ```powershell Get-Counter ` '\Memory\Available MBytes', '\Memory\Pages/sec' ``` Linux: ```bash free -h ``` Ausführlichere Anzeige: ```bash vmstat 1 ``` Prozesse nach Speichernutzung sortieren: ```bash 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: ```powershell 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: ```powershell Get-Volume | Select-Object DriveLetter, FileSystemLabel, FileSystem, Size, SizeRemaining ``` Linux: ```bash df -h ``` Blockgeräte anzeigen: ```bash lsblk ``` I/O-Auslastung mit installiertem `sysstat`: ```bash iostat -xz 1 ``` Prozesse mit I/O-Aktivität: ```bash 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: ```powershell Test-Connection SRV-APP01 -Count 10 ``` TCP-Port prüfen: ```powershell Test-NetConnection SRV-APP01 -Port 443 ``` Netzwerkadapter anzeigen: ```powershell Get-NetAdapter | Select-Object Name, Status, LinkSpeed, MacAddress ``` Adapterstatistiken: ```powershell Get-NetAdapterStatistics ``` Aktive TCP-Verbindungen: ```powershell Get-NetTCPConnection | Group-Object State | Sort-Object Count -Descending ``` Linux: ```bash ping -c 10 srv-app01 ``` Route untersuchen: ```bash traceroute srv-app01 ``` Socketübersicht: ```bash ss -s ``` Interfaceinformationen: ```bash ip -s link ``` DNS-Auflösung prüfen: ```bash 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: ```powershell Resolve-DnsName SRV-DB01 ``` Konfigurierte DNS-Server: ```powershell Get-DnsClientServerAddress ``` DNS-Zwischenspeicher: ```powershell Get-DnsClientCache ``` Linux: ```bash resolvectl status ``` Namensauflösung messen: ```bash time getent hosts srv-db01.example.local ``` Mit `dig`: ```bash 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: ```powershell Get-Service | Where-Object Status -eq 'Running' ``` Automatisch startende, aber nicht laufende Dienste: ```powershell Get-CimInstance Win32_Service | Where-Object { $_.StartMode -eq 'Auto' -and $_.State -ne 'Running' } | Select-Object Name, DisplayName, State, StartMode ``` Linux-Dienste: ```bash systemctl --failed ``` Status eines Dienstes: ```bash 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: ```text 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: ```text 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: ```powershell Get-ScheduledTask | Where-Object State -eq 'Running' ``` Linux – systemd-Timer: ```bash systemctl list-timers ``` Cron-Konfiguration prüfen: ```bash 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: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'System' StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message ``` Windows-Anwendungsereignisse: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'Application' StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message ``` Linux: ```bash journalctl --since "2 hours ago" ``` Fehler mit hoher Priorität: ```bash journalctl -p err --since "2 hours ago" ``` Kernelmeldungen: ```bash 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: ```text 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: ```bash docker stats ``` Laufende Container: ```bash docker ps ``` Containerzustand: ```bash docker inspect CONTAINERNAME ``` Protokollausgabe: ```bash docker logs --since 2h CONTAINERNAME ``` Ressourcenlimits anzeigen: ```bash 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: ```text 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: ```bash 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: ```text CPU-Auslastung steigt Anwendung wird langsam ``` Mögliche Interpretationen: 1. Die hohe CPU-Auslastung verursacht die Verzögerung. 2. Die langsame externe Abhängigkeit führt zu zusätzlichen Wiederholungen und erhöht dadurch die CPU-Auslastung. 3. Ein dritter Prozess verursacht gleichzeitig beide Effekte. 4. Die CPU-Auslastung ist normal und nicht relevant. Ein Ursachennachweis wird stärker, wenn: - 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: ```text 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: ```text 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** ```text 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: ```text 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](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/perfmon) - [Microsoft Learn – Get-Counter](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-counter) - [Microsoft Learn – Get-Process](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-process) - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Get-NetAdapterStatistics](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapterstatistics) - [Red Hat – Viewing system processes](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/viewing-system-processes_managing-monitoring-and-updating-the-kernel) - [Red Hat – Monitoring performance with Performance Co-Pilot](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/monitoring_and_managing_system_status_and_performance/monitoring-performance-with-performance-co-pilot_monitoring-and-managing-system-status-and-performance) - [Docker Docs – Runtime metrics](https://docs.docker.com/engine/containers/runmetrics/) - [Docker Docs – Resource constraints](https://docs.docker.com/engine/containers/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: 1. Anwendungskonfiguration 2. Namensauflösung 3. Auswahl von IPv4 oder IPv6 4. lokales Routing 5. VPN oder Proxy 6. Clientfirewall 7. Netzwerkfirewall oder ACL 8. NAT oder Portweiterleitung 9. Load Balancer oder Reverse Proxy 10. TCP- oder UDP-Kommunikation 11. TLS-Handshake 12. Anwendungsprotokoll 13. Authentifizierung 14. Autorisierung 15. Backenddienste 16. vollständiger Benutzerablauf Ein Fehler auf einer späteren Ebene kann auftreten, obwohl alle vorherigen Ebenen funktionieren. Beispiele: - 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: ```text 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: ```powershell Resolve-DnsName -Name -Type A Resolve-DnsName -Name -Type AAAA ``` Linux: ```bash getent ahosts dig A dig AAAA ``` macOS: ```bash 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: ```powershell Test-NetConnection ` -ComputerName ` -Port ` -InformationLevel Detailed ``` Wichtige Felder: ```text ComputerName RemoteAddress RemotePort InterfaceAlias SourceAddress TcpTestSucceeded ``` Linux und macOS: ```bash 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** ```bash curl -v --connect-timeout 5 \ "https://:/" ``` Die Ausgabe wird schrittweise ausgewertet: 1. Welche IP-Adresse wird verwendet? 2. Wird eine TCP-Verbindung aufgebaut? 3. Beginnt der TLS-Handshake? 4. Welches Zertifikat wird präsentiert? 5. Wird die Zertifikatsprüfung erfolgreich abgeschlossen? 6. Welche HTTP-Anfrage wird gesendet? 7. Welcher HTTP-Statuscode wird empfangen? 8. Erfolgt eine Umleitung? 9. Antwortet ein Reverse Proxy oder der erwartete Anwendungsserver? 10. Wird eine Anwendungsfehlermeldung zurückgegeben? Wichtige HTTP-Ergebnisse: | Status | Einordnung | |---|---| | `2xx` | Anfrage wurde auf HTTP-Ebene erfolgreich verarbeitet | | `3xx` | Umleitung; Ziel im `Location`-Header prüfen | | `401` | Anwendung erreicht, Authentifizierung erforderlich oder fehlgeschlagen | | `403` | Anwendung erreicht, Zugriff wird verweigert | | `404` | Dienst antwortet, angeforderter Pfad oder virtuelle Zuordnung fehlt | | `407` | Proxy verlangt eine Authentifizierung | | `5xx` | Server, Gateway oder Backend meldet einen Fehler | Auch eine gültige HTTP-Fehlerantwort beweist, dass bereits mehrere Prüfebenen erfolgreich durchlaufen wurden. Sie beweist jedoch nicht, dass die benötigte Benutzerfunktion arbeitet. --- **7.9.14 Bestimmte IP-Adresse mit richtigem Hostnamen testen** Bei HTTPS sollte nicht einfach die IP-Adresse in die URL eingesetzt werden. Dadurch können sich SNI, Host-Header und Zertifikatsprüfung verändern. Mit curl kann ein Servername kontrolliert einer bestimmten Adresse zugeordnet werden: ```bash 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: ```bash 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: ```powershell netsh winhttp show proxy ``` Umgebungsvariablen in PowerShell: ```powershell Get-ChildItem Env: | Where-Object Name -Match '^(HTTP|HTTPS|NO)_PROXY$' ``` Linux: ```bash env | grep -iE '^(http|https|no)_proxy=' ``` macOS: ```bash 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: ```powershell Get-NetTCPConnection ` -LocalPort ` -State Listen | Select-Object LocalAddress, LocalPort, State, OwningProcess ``` Zugehörigen Prozess prüfen: ```powershell Get-Process -Id ``` Linux: ```bash sudo ss -lntp ``` macOS: ```bash 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: ```bash curl -v \ "http://127.0.0.1:/" ``` Bei einem namensabhängigen HTTPS-Dienst: ```bash 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: ```powershell Resolve-DnsName ` -Name ` -Server ``` DNS-Test unter Linux oder macOS: ```bash 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: ```bash 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: ```bash 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** 1. **Fehler aufnehmen** Anwendung, Benutzer, Client, Zeitpunkt, Meldung und ursprüngliche Benutzerfunktion dokumentieren. 2. **Umfang bestimmen** Einen Benutzer, einen Client, ein Netz oder alle Benutzer unterscheiden. 3. **Exaktes Ziel bestimmen** Servername, Adresse, Port, Protokoll, Pfad und Verbindungsweg erfassen. 4. **Namensauflösung prüfen** A- und AAAA-Antworten sowie tatsächlich verwendete Adresse vergleichen. 5. **Ping korrekt bewerten** Nur ICMP-Erreichbarkeit als bestätigt betrachten. 6. **Transportprotokoll bestimmen** TCP und UDP unterscheiden. 7. **TCP-Port oder UDP-Anwendung prüfen** Einen zum tatsächlichen Protokoll passenden Test verwenden. 8. **Listener kontrollieren** Port, Prozess und Bindungsadresse auf dem Server prüfen. 9. **Lokalen Anwendungstest durchführen** Dienst auf dem Server über den vorgesehenen Namen, Port und Pfad testen. 10. **Externen Anwendungstest durchführen** Denselben Dienst vom betroffenen Client aus prüfen. 11. **TLS untersuchen** SNI, Zertifikat, Vertrauenskette und Protokollkompatibilität prüfen. 12. **Proxy und VPN berücksichtigen** Tatsächlichen Verbindungsweg der Anwendung nachvollziehen. 13. **Anwendungsantwort auswerten** Statuscode, Protokollmeldung, Umleitung oder Authentifizierungsfehler bestimmen. 14. **Abhängigkeiten prüfen** Datenbank, Identitätsdienst, API, Speicher oder andere Backends untersuchen. 15. **Protokolle korrelieren** Client-, Server-, Proxy- und Anwendungsprotokolle auf denselben Zeitraum begrenzen. 16. **Bei Bedarf Paketverlauf erfassen** SYN, RST, TLS-Alert, Wiederholungen und Rückweg untersuchen. 17. **Hypothese formulieren** Erwartetes Prüfergebnis und möglichen Gegenbeweis festlegen. 18. **Eine kontrollierte Änderung durchführen** Risiko, Rückweg und Erfolgskriterium dokumentieren. 19. **Vollständige Funktion prüfen** Nicht nur Ping oder Port, sondern den ursprünglichen Benutzerablauf testen. 20. **Nachkontrolle durchführen** Protokolle, Überwachung und andere Benutzerfunktionen prüfen. --- **7.9.27 Befundmatrix** | Befund | Mögliche Erklärung | Nächster Nachweis | |---|---|---| | Ping auf IP funktioniert, Name nicht | Namensauflösungsproblem | A-, AAAA-, Hosts- und Resolverdaten prüfen | | Ping auf Name verwendet falsche Adresse | veralteter oder falscher Namenseintrag | autoritative und clientseitige Antwort vergleichen | | Ping funktioniert, TCP-Port hat Timeout | Portverkehr wird verworfen oder Antwort fehlt | Firewall, Routing und Paketverlauf prüfen | | Ping funktioniert, TCP-Port wird abgelehnt | kein Listener oder aktive Ablehnung | Listener und Prozess auf dem Server prüfen | | TCP-Port funktioniert, Verbindung wird sofort geschlossen | falsches Protokoll oder Dienst lehnt Sitzung ab | Dienstprotokoll und Serverlogs prüfen | | TCP funktioniert, TLS schlägt fehl | Zertifikat, SNI, TLS-Version oder Inspektion | `curl -v` oder `openssl s_client` auswerten | | TLS funktioniert, HTTP 401 | Authentifizierung erforderlich oder fehlerhaft | Benutzer-, Token- oder Identitätsanbieter prüfen | | TLS funktioniert, HTTP 403 | fehlende Autorisierung oder Richtlinie | Rollen und Zugriffsrichtlinie prüfen | | HTTP 404 | falscher Pfad oder virtuelle Zuordnung | URL, Host-Header und Proxyroute prüfen | | HTTP 407 | Proxy-Authentifizierung erforderlich | Proxyweg und Benutzerkontext prüfen | | HTTP 502 | Gateway erreicht Backend nicht korrekt | Reverse-Proxy- und Backendprotokolle prüfen | | HTTP 503 | Dienst vorübergehend nicht verfügbar | Healthcheck, Kapazität und Abhängigkeiten prüfen | | lokal funktioniert, entfernt nicht | Bindung, Hostfirewall oder Netzwerkpfad | Listeneradresse und Regeln vergleichen | | `curl` funktioniert, Anwendung nicht | anwendungsspezifische Konfiguration | Proxy, Cache, Zertifikatsspeicher und Benutzerkontext prüfen | | nur ein Client betroffen | lokaler Clientfehler | anderen Client und gleichen Benutzer testen | | nur ein Benutzer betroffen | Konto, Profil, Rechte oder Sitzung | anderes Konto am gleichen Client testen | | nur über VPN betroffen | Route, DNS, MTU oder VPN-Regel | mit und ohne VPN vergleichen | | nur IPv6 betroffen | AAAA-, IPv6-Routing- oder Firewallfehler | `curl -4` und `curl -6` vergleichen | | kleine Anfragen funktionieren | MTU, Paketverlust oder Kapazität möglich | Paketverlauf und größere Übertragung prüfen | | Port erreichbar, Geschäftsprozess scheitert | Backend oder Anwendungslogik fehlerhaft | vollständigen Ablauf und Abhängigkeiten prüfen | --- **7.9.28 Mögliche Ursachen und erforderliche Nachweise** | Mögliche Ursache | Erforderlicher Nachweis | |---|---| | falscher Port | Anwendungskonfiguration und tatsächlicher Listener zeigen unterschiedliche Ports | | Dienst gestoppt | kein Listener vorhanden und Dienststatus beziehungsweise Logs bestätigen den Ausfall | | falsche Listenerbindung | Dienst lauscht nur auf Loopback oder einer anderen Adresse | | Hostfirewall blockiert Port | konkrete Regel oder Protokoll zeigt den verworfenen Verbindungsversuch | | Netzwerkfirewall oder ACL | Trefferprotokoll oder beidseitiger Paketmitschnitt bestätigt die Unterbrechung | | falscher DNS-Eintrag | Anwendung verwendet eine nachweislich falsche oder veraltete Adresse | | fehlerhafter IPv6-Pfad | IPv6-Test scheitert reproduzierbar, IPv4-Test funktioniert | | Proxyfehler | Anwendung verwendet einen fehlerhaften Proxyweg, während direkter Test anders reagiert | | Reverse-Proxy-Fehler | Proxy antwortet, passende Route oder gesundes Backend fehlt | | Load-Balancer-Fehler | virtuelle Adresse ist erreichbar, aber Healthcheck oder Backendzustand ist fehlerhaft | | TLS-Fehler | TLS-Ausgabe zeigt Zertifikats-, SNI- oder Protokollproblem | | fehlende Authentifizierung | Anwendung antwortet mit konkretem Anmelde- oder Tokenfehler | | fehlende Autorisierung | Anmeldung funktioniert, Ressourcenzugriff wird nachvollziehbar verweigert | | ausgefallene Backendabhängigkeit | Frontend antwortet, Serverlogs belegen den Fehler der Abhängigkeit | | Ressourcenengpass | Fehler korreliert mit CPU, Speicher, Worker-, Verbindungs- oder Datenträgerengpass | | Path-MTU- oder Paketverlustproblem | Verbindung beginnt, größere Übertragung scheitert und Paketverlauf bestätigt Wiederholungen oder Größenproblem | | clientseitiger Anwendungsfehler | gleicher Benutzer und Dienst funktionieren mit einem anderen Client | | benutzerbezogener Fehler | anderer Benutzer arbeitet am gleichen Client erfolgreich | --- **7.9.29 Kontrollierte Maßnahmen, Risiko und Rückweg** | Maßnahme | Risiko | Rückweg | |---|---|---| | falschen Servernamen oder Port korrigieren | Verbindung erreicht anderes Ziel | ursprüngliche Konfiguration wiederherstellen | | gestoppten Dienst kontrolliert starten | Dienst kann erneut fehlschlagen oder Last erzeugen | Dienstzustand und Starttyp dokumentieren | | Listenerbindung korrigieren | Dienst wird auf zusätzlichen Netzen erreichbar | vorherige Bindung wiederherstellen | | minimale Firewallfreigabe ergänzen | zusätzliche Erreichbarkeit | konkrete Regel entfernen oder deaktivieren | | falschen DNS-Eintrag korrigieren | Clients wechseln auf neues Ziel | vorherigen Wert und TTL dokumentieren | | Reverse-Proxy-Route korrigieren | andere Anwendungen können betroffen sein | vorherige Proxykonfiguration zurückspielen | | fehlerhaftes Backend aus dem Load Balancer nehmen | geringere Kapazität | Backend nach erfolgreicher Prüfung wieder aufnehmen | | Proxykonfiguration korrigieren | anderer Netzwerkpfad wird verwendet | ursprüngliche Proxywerte wiederherstellen | | Zertifikatskette korrigieren | TLS-Dienst muss eventuell neu geladen werden | vorherige Zertifikatskonfiguration sichern | | Anwendungscache kontrolliert leeren | Sitzungs- oder Anmeldedaten können verloren gehen | Benutzer informieren und Ausgangszustand dokumentieren | | Backenddienst wiederherstellen | abhängige Anwendungen können beeinflusst werden | dienstspezifischen Wiederherstellungsplan verwenden | | Ressource freigeben oder Kapazität erhöhen | Lastverteilung kann sich ändern | vorherige Kapazitäts- oder Ressourcenwerte sichern | Pro Maßnahme sollte möglichst nur eine relevante Variable verändert werden. --- **7.9.30 Verifikation** Nach einer Maßnahme müssen mindestens folgende Prüfungen erfolgen: - 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](https://datatracker.ietf.org/doc/html/rfc792) - [RFC 9293 – Transmission Control Protocol](https://www.rfc-editor.org/rfc/rfc9293) - [RFC 9110 – HTTP Semantics](https://datatracker.ietf.org/doc/html/rfc9110) - [RFC 8446 – The Transport Layer Security Protocol Version 1.3](https://datatracker.ietf.org/doc/html/rfc8446) - [RFC 1191 – Path MTU Discovery für IPv4](https://datatracker.ietf.org/doc/html/rfc1191) - [RFC 8201 – Path MTU Discovery für IPv6](https://datatracker.ietf.org/doc/html/rfc8201) - [IANA – HTTP Status Code Registry](https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml) **Offizielle Hersteller- und Projektdokumentation** - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-nettcpconnection) - [Microsoft Learn – netsh winhttp](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-winhttp) - [curl – offizielle Befehlsreferenz](https://curl.se/docs/manpage.html) - [Everything curl – Verbose output](https://everything.curl.dev/usingcurl/verbose.html) - [OpenSSL – openssl s_client](https://docs.openssl.org/3.6/man1/openssl-s_client/) - [OpenBSD – nc(1)](https://man.openbsd.org/nc) **Lokale Befehlsreferenzen** Die genaue Syntax kann von Betriebssystem und installierter Version abhängen. Maßgeblich ist die lokale Befehlsreferenz: ```bash 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: ```text Der Benutzername oder das Kennwort ist falsch. ``` ```text Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar. ``` ```text Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden. ``` ```text Wir können Sie mit diesen Anmeldeinformationen nicht anmelden, weil Ihre Domäne nicht verfügbar ist. ``` ```text Der Sicherheitsdatenbank auf dem Server ist kein Computerkonto für diese Arbeitsstationsvertrauensstellung zugeordnet. ``` ```text 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: 1. Der Benutzer wählt den richtigen Anmeldeanbieter. 2. Windows ordnet den eingegebenen Namen dem vorgesehenen Konto zu. 3. Der Computer besitzt eine geeignete Netzwerkverbindung. 4. Der Client verwendet die vorgesehenen DNS-Server. 5. DNS liefert die erforderlichen Domänen- und Dienstinformationen. 6. DC Locator ermittelt einen geeigneten Domänencontroller. 7. Die benötigten Netzwerkprotokolle erreichen den Domänencontroller. 8. Client und Domänencontroller besitzen ausreichend synchronisierte Uhrzeiten. 9. Der Computer besitzt eine gültige Vertrauensbeziehung zur Domäne. 10. Kerberos, NTLM oder das vorgesehene zertifikatsbasierte Verfahren beginnt. 11. Der Domänencontroller prüft das Benutzerkonto und die Anmeldeinformationen. 12. Kontorichtlinien und Anmelderechte werden ausgewertet. 13. Windows erzeugt die Anmeldesitzung und das Zugriffstoken. 14. Benutzerprofil, Gruppenrichtlinien und Anmeldeskripte werden verarbeitet. 15. Der Desktop beziehungsweise die vorgesehene Sitzung wird bereitgestellt. Der sichtbare Fehler kann an jeder dieser Ebenen entstehen. --- **7.10.5 Zuerst die genaue Fehlerphase bestimmen** | Fehlerphase | Typische Beobachtung | Wahrscheinlicher Bereich | |---|---|---| | vor Eingabe der Anmeldedaten | Netzwerk- oder Anmeldeoption fehlt | Client, Treiber, VPN oder Anmeldeanbieter | | unmittelbar nach Eingabe | Kennwort- oder Kontofehler | Identität, Kennwort, Sperre oder Kontorichtlinie | | längere Wartezeit vor Fehlermeldung | kein DC, DNS, Netzwerk oder Timeout | Infrastruktur und Erreichbarkeit | | Meldung über Vertrauensstellung | Computerkonto oder sicherer Kanal | Computervertrauen | | Anmeldung funktioniert offline, aber nicht online | Cache oder unterschiedlicher DC-Zustand | DNS, DC, Kennwort oder Replikation | | Anmeldung wird akzeptiert, Desktop erscheint nicht | Profil, Richtlinie, Skript oder Ressource | Phase nach der Authentifizierung | | temporäres Profil wird geladen | Benutzerprofilproblem | Profilpfad, Datenträger oder Profildienst | | nur RDP schlägt fehl | RDP, NLA, Anmelderecht oder Zielsystem | entfernter Computer | | PIN schlägt fehl, Kennwort funktioniert | Windows Hello oder PIN-Anbieter | Hello-Schlüssel, TPM oder Richtlinie | | Smartcard schlägt fehl, Kennwort funktioniert | Zertifikat oder PKI | Smartcard, Zertifikatskette, KDC-Zertifikat oder Sperrprüfung | Eine erfolgreiche Kennwortprüfung bedeutet noch nicht, dass Benutzerprofil, Gruppenrichtlinien und Desktop erfolgreich geladen werden. --- **7.10.6 Beweise vor Änderungen sichern** Vor einem Neustart, einer Kennwortzurücksetzung, dem Entsperren eines Kontos oder einer Reparatur des sicheren Kanals sollten mindestens folgende Informationen gesichert werden: - 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: ```text \MaxMustermann ``` ```text max.mustermann@ ``` ```text .\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: ```cmd whoami whoami /user whoami /fqdn whoami /groups ``` In PowerShell: ```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: ```powershell Get-CimInstance Win32_ComputerSystem | Select-Object Name, PartOfDomain, Domain, Workgroup ``` Erwartet wird: ```text PartOfDomain : True Domain : ``` Zusätzlich: ```cmd systeminfo ``` Relevante Felder sind: ```text 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: ```text 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** ```powershell Get-NetAdapter | Select-Object Name, Status, LinkSpeed, MacAddress ``` ```powershell Get-NetIPConfiguration ``` ```cmd 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: ```powershell Get-DnsClientServerAddress | Select-Object InterfaceAlias, AddressFamily, ServerAddresses ``` Domänenname prüfen: ```powershell Resolve-DnsName -Name -Type A ``` Domänencontroller-Dienst prüfen: ```powershell Resolve-DnsName ` -Name _ldap._tcp.dc._msdcs. ` -Type SRV ``` Kerberos-Dienst prüfen: ```powershell Resolve-DnsName ` -Name _kerberos._tcp. ` -Type SRV ``` Einen bestimmten DNS-Server verwenden: ```powershell 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. ```cmd nltest /dsgetdc: ``` Erneute DNS-basierte Ermittlung ohne den bisherigen DC-Cache: ```cmd nltest /dsgetdc: /force ``` Nur einen beschreibbaren DC anfordern: ```cmd nltest /dsgetdc: /writable /force ``` Lokalen AD-Standort anzeigen: ```cmd nltest /dsgetsite ``` Bekannte Domänencontroller auflisten: ```cmd nltest /dclist: ``` In der Ausgabe von `nltest /dsgetdc` sind unter anderem wichtig: ```text 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: ```powershell 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: ```powershell 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: ```cmd w32tm /query /status w32tm /query /source w32tm /query /configuration ``` Zeitabweichung zu einem DC beobachten: ```cmd w32tm /stripchart /computer: /dataonly /samples:5 ``` Zusätzlich zu prüfen: ```powershell 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: ```cmd 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: ```powershell 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: ```powershell Get-ADUserResultantPasswordPolicy ` -Identity "" ``` Gezielte Suchbefehle: ```powershell Search-ADAccount -LockedOut -UsersOnly Search-ADAccount -AccountDisabled -UsersOnly Search-ADAccount -AccountExpired -UsersOnly Search-ADAccount -PasswordExpired -UsersOnly ``` Alternativ mit integrierten Werkzeugen: ```cmd 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: ```text 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: ```powershell Test-ComputerSecureChannel ` -Server "" ` -Verbose ``` Status des zuletzt verwendeten Netlogon-Kanals anzeigen: ```cmd 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: ```cmd klist ``` TGT anzeigen: ```cmd klist tgt ``` Alle Tickets der aktuellen Sitzung anzeigen: ```cmd 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: ```cmd 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: ```powershell 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: ```powershell 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: ```text 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: ```cmd repadmin /replsummary ``` ```cmd repadmin /showrepl ``` Gesamtstrukturweite Übersicht: ```cmd repadmin /showrepl * /csv ``` Grundlegender DC-Test: ```cmd dcdiag /v ``` DNS-Test für einen bestimmten DC: ```cmd 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: ```cmd 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: ```cmd gpresult /r ``` Computerrichtlinien: ```cmd gpresult /r /scope computer ``` Benutzerrichtlinien: ```cmd gpresult /r /scope user ``` `gpupdate /force` ist keine reine Diagnose. Der Befehl kann neue Richtlinien anwenden und den Ausgangszustand verändern. --- **7.10.31 Systematischer Diagnoseablauf** 1. **Fehlermeldung aufnehmen** Exakten Wortlaut, Benutzer, Computer, Uhrzeit und Anmeldeart dokumentieren. 2. **Anmeldephase bestimmen** Identität, Authentifizierung, Sitzung oder Profil unterscheiden. 3. **Umfang bestimmen** Einen Benutzer, einen Computer, einen Standort oder die gesamte Domäne unterscheiden. 4. **Anmeldeanbieter kontrollieren** Kennwort, PIN, Smartcard, lokales Konto und Domänenkonto unterscheiden. 5. **Namensformat prüfen** UPN und `DOMÄNE\Benutzer` kontrolliert vergleichen. 6. **Domänenmitgliedschaft prüfen** Lokale Mitgliedschaft und erwartete Domäne bestätigen. 7. **Online- und Cache-Anmeldung unterscheiden** Feststellen, ob ein DC tatsächlich beteiligt war. 8. **Netzwerkzustand prüfen** Schnittstelle, Adresse, Gateway, VPN und DNS-Server dokumentieren. 9. **DNS-SRV-Einträge prüfen** LDAP- und Kerberos-Diensteinträge auflösen. 10. **Domänencontroller ermitteln** `nltest /dsgetdc` und Standortinformationen auswerten. 11. **DC-Erreichbarkeit prüfen** DNS, Kerberos, LDAP, SMB, RPC und benötigte Zusatzdienste untersuchen. 12. **Zeit prüfen** Zeitquelle, Status und Abweichung zum DC bestimmen. 13. **Benutzerkonto prüfen** Existenz, UPN, Aktivierung, Sperre, Ablauf und Kennwortstatus auswerten. 14. **Sicheren Kanal prüfen** Ausschließlich mit lesenden Tests beginnen. 15. **Authentifizierungsverfahren bestimmen** Kerberos, NTLM, Smartcard oder Windows Hello unterscheiden. 16. **Ereignisse korrelieren** Client- und DC-Ereignisse auf denselben Versuch begrenzen. 17. **Fehlercode auswerten** Status, Substatus, Kerberos-Code und Anmeldetyp bestimmen. 18. **Replikation prüfen** Besonders bei DC- oder Standortabhängigkeit. 19. **Nachgelagerte Anmeldung prüfen** Profil, Gruppenrichtlinie, Skript und Ressourcen untersuchen. 20. **Hypothese formulieren** Erwarteten Befund und möglichen Gegenbeweis festlegen. 21. **Eine kontrollierte Maßnahme durchführen** Risiko, Berechtigung, Rückweg und Erfolgskriterium dokumentieren. 22. **Online-Domänenanmeldung verifizieren** Nicht nur Cache- oder lokale Anmeldung testen. 23. **Vollständige Benutzerfunktion prüfen** Desktop, Gruppenrichtlinien und benötigte Ressourcen kontrollieren. 24. **Nachkontrolle durchführen** Ereignisse, Replikation und weitere Benutzer beziehungsweise Systeme prüfen. --- **7.10.32 Befundmatrix** | Befund | Mögliche Erklärung | Nächster Nachweis | |---|---|---| | lokales Konto funktioniert, Domänenkonto nicht | Domänenweg oder Domänenkonto fehlerhaft | DNS, DC Locator, Konto und sicheren Kanal prüfen | | anderer Benutzer funktioniert am gleichen Computer | benutzerbezogener Fehler | Kontostatus, Kennwort und Profil prüfen | | gleicher Benutzer funktioniert an anderem Computer | clientbezogener Fehler | DNS, Zeit, sicherer Kanal und Profil prüfen | | Anmeldung funktioniert nur offline | Cache-Anmeldung | Onlineweg zum DC prüfen | | altes Kennwort funktioniert offline | alter lokaler Anmeldecache | Onlineanmeldung mit aktuellem Kennwort prüfen | | `nltest /dsgetdc` findet keinen DC | DNS, Netzwerk oder Netlogon | SRV-Einträge, DNS-Server und Dienst prüfen | | DC wird gefunden, Ports schlagen fehl | Firewall, Routing oder DC-Dienst | Regeln und beidseitige Protokolle prüfen | | Ereignis `0xC000005E` | keine Anmeldeserver verfügbar | DNS, DC Locator und Netzwerk prüfen | | Ereignis `0xC0000064` | Benutzer nicht gefunden | Identität und Kontobestand prüfen | | Ereignis `0xC000006A` | falsches Kennwort | Kennwort, Cache und gespeicherte Daten prüfen | | Ereignis `0xC0000234` | Konto gesperrt | Ereignis 4740 und Sperrquelle prüfen | | Kerberos `0x18` | Vorauthentifizierung fehlgeschlagen | Kennwort und zugehörigen Versuch prüfen | | Kerberos `0x25` | Zeitabweichung zu groß | Zeitquelle und Abweichung prüfen | | sicherer Kanal liefert `False` | Computervertrauen fehlerhaft | DNS, Zeit, Computerkonto und Replikation prüfen | | Vertrauensfehler nur bei einem Computer | Computerkennwort oder Computerkonto | sicheren Kanal kontrolliert reparieren | | Anmeldung funktioniert abhängig vom DC | Replikations- oder DC-Fehler | DC-Ereignisse und `repadmin` auswerten | | Kennwort funktioniert, PIN nicht | Windows-Hello-Problem | Hello-, TPM- und Richtlinienzustand prüfen | | Kennwort funktioniert, Smartcard nicht | PKI- oder Zertifikatsproblem | Zertifikate, KDC und Sperrprüfung untersuchen | | Ereignis 4624 vorhanden, Desktop fehlt | Authentifizierung erfolgreich, Folgephase fehlerhaft | Profil, GPO und Skripte prüfen | | nur RDP schlägt fehl | RDP-Recht, NLA oder Zielsystem | Logon Type 10 und Zielsystem prüfen | | Konto wird sofort erneut gesperrt | gespeichertes altes Kennwort | Quellcomputer und Hintergrundprozesse ermitteln | --- **7.10.33 Ursachen und erforderliche Nachweise** | Mögliche Ursache | Erforderlicher Nachweis | |---|---| | falsches Namensformat | Anmeldung richtet sich nachweislich an falsche Domäne oder lokales Konto | | falsches Kennwort | Ereigniscode und kontrollierter Identitätsabgleich bestätigen die Ursache | | Konto gesperrt | AD-Kontostatus und Ereignis gesper `4740` bestätigen die Sperre | | Konto deaktiviert | `Enabled : False` oder entsprechendes Änderungsereignis | | Konto abgelaufen | Ablaufdatum liegt in der Vergangenheit | | Kennwort abgelaufen | `PasswordExpired` oder Kerberos-Code `0x17` | | falscher DNS-Server | Client verwendet nicht den vorgesehenen AD-DNS-Server | | fehlender SRV-Eintrag | autorisierte DNS-Abfrage liefert den benötigten Eintrag nicht | | falscher DC-Eintrag | SRV- oder A/AAAA-Eintrag verweist auf falschen oder alten DC | | DC nicht erreichbar | protokollspezifischer Test und Netzwerkprotokoll bestätigen Unterbrechung | | falscher AD-Standort | `nltest /dsgetsite` und Subnetzkonfiguration stimmen nicht überein | | VPN vor Anmeldung fehlt | Onlineweg zum DC ist am Anmeldebildschirm nicht vorhanden | | Zeitabweichung | `w32tm` oder Kerberos-Code `0x25` bestätigt die Abweichung | | defekter sicherer Kanal | `Test-ComputerSecureChannel` meldet reproduzierbar `False` | | Computerkonto fehlt | AD-Abfrage bestätigt fehlendes oder falsches Computerkonto | | doppelter Computername | zwei Systeme verwenden nachweislich dieselbe Computeridentität | | AD-Replikationsfehler | `repadmin` oder DC-Protokolle zeigen fehlgeschlagene Replikation | | Kerberos-Verschlüsselungsproblem | Kerberos-Code und Kontokonfiguration bestätigen fehlende gemeinsame Verschlüsselungsart | | Smartcard-Zertifikatsproblem | Zertifikatsprüfung oder PKINIT-Ereignis bestätigt Ursache | | fehlendes Anmelderecht | Ereignis `0xC000015B` und wirksame Richtlinie stimmen überein | | Profilfehler | erfolgreiche Authentifizierung und Profildienstereignis liegen nacheinander vor | | Gruppenrichtlinienfehler | GroupPolicy-Protokoll zeigt konkrete fehlgeschlagene Richtlinienverarbeitung | | gespeichertes altes Kennwort | Ereignisse zeigen wiederholte Fehlversuche von bestimmtem Gerät oder Prozess | --- **7.10.34 Kontrollierte Maßnahmen, Risiko und Rückweg** | Maßnahme | Risiko | Rückweg beziehungsweise Kontrolle | |---|---|---| | richtigen Benutzer oder richtige Domäne auswählen | gering | ursprüngliche Eingabe dokumentieren | | Tastaturlayout korrigieren | Fehleingabe bleibt möglich | kontrollierte Testeingabe ohne Kennwortprotokollierung | | Netzwerk oder Voranmelde-VPN wiederherstellen | anderer Netzwerkweg wird aktiv | vorherigen Netzwerkzustand dokumentieren | | DNS-Konfiguration korrigieren | andere Namensauflösung kann beeinflusst werden | bisherige DNS-Werte sichern | | falschen SRV- oder Hosteintrag korrigieren | viele Clients können betroffen sein | bisherigen Wert und TTL dokumentieren | | Windows-Zeit kontrolliert synchronisieren | Zeitsprung kann Dienste beeinflussen | alte Quelle und Abweichung sichern | | Konto nach Ursachenprüfung entsperren | erneute sofortige Sperre möglich | Sperrquelle vorher ermitteln | | Kennwort nach Identitätsprüfung zurücksetzen | gespeicherte Daten oder Schlüssel können betroffen sein | vorgesehenes Identitätsverfahren verwenden | | sicheren Kanal reparieren | Computervertrauen wird verändert | verwendeten DC und Ausgangsbefund dokumentieren | | Computerkennwort zurücksetzen | Vertrauensbeziehung kann bei Fehler weiter ausfallen | lokale Administrationsmöglichkeit sicherstellen | | Computer neu in Domäne aufnehmen | Neustarts, Profilzuordnung und Verwaltungszustand können betroffen sein | nur als letzte Maßnahme mit Wiederaufnahmeplan | | AD-Replikationsfehler beheben | domänenweite Auswirkungen möglich | DC-spezifischen Änderungsplan verwenden | | GPO korrigieren | viele Benutzer oder Computer betroffen | Version, Sicherung und Zielbereich dokumentieren | | beschädigtes Profil reparieren | Benutzerdaten können verloren gehen | Profil und Daten nach Vorgabe sichern | | gespeicherte alte Anmeldeinformation aktualisieren | Anwendung oder Dienst kann ausfallen | betroffene Abhängigkeit vorher bestimmen | Pro Diagnoseversuch sollte möglichst nur eine relevante Variable verändert werden. --- **7.10.35 Sicheren Kanal kontrolliert reparieren** Eine Reparatur ist nur gerechtfertigt, wenn: - 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: ```powershell $Credential = Get-Credential "\" Test-ComputerSecureChannel ` -Repair ` -Server "" ` -Credential $Credential ` -Verbose ``` Alternativ kann das lokale Computerkennwort kontrolliert zurückgesetzt werden: ```powershell $Credential = Get-Credential "\" Reset-ComputerMachinePassword ` -Server "" ` -Credential $Credential ``` Danach: ```powershell 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: ```powershell 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: ```text 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](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/dc-locator) - [Microsoft Learn – Troubleshoot domain controller location issues](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/troubleshoot-domain-controller-location-issues) - [Microsoft Learn – Service overview and network port requirements for Windows](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements) - [Microsoft Learn – Configure a firewall for Active Directory domains and trusts](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/config-firewall-for-ad-domains-and-trusts) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Nltest](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731935%28v%3Dws.11%29) - [Microsoft Learn – Test-ComputerSecureChannel](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-computersecurechannel) - [Microsoft Learn – Reset-ComputerMachinePassword](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/reset-computermachinepassword) - [Microsoft Learn – Broken trust relationship between a domain-joined device and its domain](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/broken-trust-relationship-domain-joined-device-its-domain-secure-channel-issues) - [Microsoft Learn – Data collection for troubleshooting secure channel issues](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/data-collection-for-troubleshooting-secure-channel-issues) - [Microsoft Learn – Secure Channel Problems Detected](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/secure-channel-problems-detected) - [Microsoft Learn – How the Windows Time Service works](https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/how-the-windows-time-service-works) - [Microsoft Learn – Maximum tolerance for computer clock synchronization](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/maximum-tolerance-for-computer-clock-synchronization) - [Microsoft Learn – Interactive logon: Number of previous logons to cache](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available) - [Microsoft Learn – Cached and Stored Credentials Technical Overview](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh994565%28v%3Dws.11%29) - [Microsoft Learn – Klist](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/klist) - [Microsoft Learn – Kerberos authentication troubleshooting guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/kerberos-authentication-troubleshooting-guidance) - [Microsoft Learn – Get-ADUser](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-aduser) - [Microsoft Learn – Search-ADAccount](https://learn.microsoft.com/en-us/powershell/module/activedirectory/search-adaccount) - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [Microsoft Learn – Ereignis 4625: An account failed to log on](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4625) - [Microsoft Learn – Ereignis 4740: A user account was locked out](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4740) - [Microsoft Learn – Ereignis 4768: A Kerberos authentication ticket was requested](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768) - [Microsoft Learn – Ereignis 4769: A Kerberos service ticket was requested](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769) - [Microsoft Learn – Ereignis 4771: Kerberos pre-authentication failed](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4771) - [Microsoft Learn – Ereignis 4776: The computer attempted to validate the credentials for an account](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4776) - [Microsoft Learn – Dcdiag](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dcdiag) - [Microsoft Learn – Diagnose Active Directory replication failures](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/diagnose-replication-failures) - [Microsoft Learn – Verify DNS functionality to support directory replication](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/troubleshoot/verify-dns-functionality-to-support-directory-replication) - [Microsoft Learn – Advanced audit policy configuration settings](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/advanced-audit-policy-configuration) **Standards** - [RFC 4120 – The Kerberos Network Authentication Service](https://datatracker.ietf.org/doc/html/rfc4120) - [RFC 2782 – A DNS RR for specifying the location of services](https://datatracker.ietf.org/doc/html/rfc2782) 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: ```text host25.example.test → 192.0.2.25 ``` Dies ist eine Vorwärtsauflösung über einen A-Eintrag. ```text 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: ```text 192.0.2.25 ``` Daraus entsteht der Abfragename: ```text 25.2.0.192.in-addr.arpa. ``` Der zugehörige PTR-Eintrag kann auf folgenden Namen zeigen: ```text host25.example.test. ``` Für das Netz `192.0.2.0/24` lautet die typische Reverse-Lookup-Zone: ```text 2.0.192.in-addr.arpa ``` Der Knoten für die Adresse `192.0.2.25` lautet innerhalb dieser Zone: ```text 25 ``` Bei Adressbereichen, die nicht an einer Oktettgrenze delegiert werden, kann eine klassenlose Delegation nach RFC 2317 erforderlich sein. Der Zonenaufbau darf dann nicht allein aus der Subnetzmaske abgeleitet werden, sondern muss mit der tatsächlichen Delegation des Adressbereichs übereinstimmen. --- **7.11.5 Aufbau einer IPv6-Rückwärtsauflösung** IPv6-Rückwärtsauflösungen verwenden die Zone `ip6.arpa`. Dabei wird: 1. die IPv6-Adresse vollständig ausgeschrieben; 2. jede Hexadezimalstelle einzeln betrachtet; 3. die Reihenfolge aller Hexadezimalstellen umgekehrt; 4. zwischen jeder Stelle ein Punkt eingefügt; 5. `ip6.arpa` angehängt. Die Delegation erfolgt auf Basis einzelner Hexadezimalstellen, sogenannter Nibbles. Eine IPv6-Reverse-Zone muss deshalb anhand des tatsächlich delegierten IPv6-Präfixes erstellt werden. IPv6-Reverse-Namen dürfen nicht durch einfaches Umkehren der durch Doppelpunkte getrennten Adressblöcke gebildet werden. --- **7.11.6 Bedeutung eines fehlenden Reverse-Lookups** Ein fehlender PTR-Eintrag bedeutet zunächst nur, dass für die IP-Adresse kein entsprechender Name über Reverse-DNS ermittelt werden konnte. Das beweist nicht automatisch: - 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: ```text 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: ```cmd nslookup host25.example.test 192.0.2.53 ``` ```cmd nslookup 192.0.2.25 192.0.2.53 ``` PTR des DNS-Servers selbst prüfen: ```cmd 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** ```cmd ipconfig /all ``` ```powershell Get-DnsClientServerAddress ``` ```powershell Get-DnsClient ``` **Linux** ```bash cat /etc/resolv.conf ``` Bei Systemen mit `systemd-resolved` zusätzlich: ```bash resolvectl status ``` **macOS** ```bash 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: ```text 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: ```powershell Get-DnsClientNrptPolicy ``` Konfigurierte NRPT-Regeln anzeigen: ```powershell 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: ```cmd netsh dnsclient show state ``` Globale Einstellungen anzeigen: ```cmd netsh dnsclient show global ``` Konfigurierte verschlüsselte DNS-Server anzeigen: ```cmd 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: ```powershell 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** ```powershell Resolve-DnsName ` -Name "host25.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ``` AAAA-Eintrag: ```powershell Resolve-DnsName ` -Name "host25.example.test" ` -Type AAAA ` -Server "192.0.2.53" ` -DnsOnly ``` **Windows Eingabeaufforderung** ```cmd nslookup host25.example.test 192.0.2.53 ``` **Linux und macOS** ```bash dig @192.0.2.53 host25.example.test A ``` ```bash 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** ```powershell Resolve-DnsName ` -Name "192.0.2.25" ` -Type PTR ` -Server "192.0.2.53" ` -DnsOnly ``` **Windows Eingabeaufforderung** ```cmd nslookup 192.0.2.25 192.0.2.53 ``` **Linux und macOS** ```bash dig @192.0.2.53 -x 192.0.2.25 ``` Kompakte Ausgabe mit Antwort und Statistik: ```bash dig @192.0.2.53 -x 192.0.2.25 +noall +answer +comments +stats ``` Direkte Abfrage des vollständigen Reverse-Namens: ```bash 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: ```powershell Resolve-DnsName ` -Name "alias.example.test" ` -Type CNAME ` -Server "192.0.2.53" ` -DnsOnly ``` SRV prüfen: ```powershell Resolve-DnsName ` -Name "_service._tcp.example.test" ` -Type SRV ` -Server "192.0.2.53" ` -DnsOnly ``` Mit `dig`: ```bash dig @192.0.2.53 alias.example.test CNAME ``` ```bash 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: ```bash dig @192.0.2.53 host25.example.test A +stats ``` TCP erzwingen: ```bash dig @192.0.2.53 host25.example.test A +tcp +stats ``` **Windows PowerShell** ```powershell Measure-Command { Resolve-DnsName ` -Name "host25.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly } ``` TCP erzwingen: ```powershell 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: ```cmd ipconfig /displaydns ``` Alternativ: ```powershell 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: ```powershell Clear-DnsClientCache ``` Alternativ: ```cmd 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: ```powershell 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: ```powershell Resolve-DnsName ` -Name "host25.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ``` Vergleich über TCP: ```powershell 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: ```powershell Resolve-DnsName ` -Name "example.com" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ` -DnssecOk ``` Mit `dig`: ```bash dig @192.0.2.53 example.com A +dnssec ``` Vergleich über TCP: ```bash dig @192.0.2.53 example.com A +dnssec +tcp ``` EDNS testweise unterdrücken: ```bash 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: 1. Abfrage über den vom Client verwendeten DNS-Server; 2. Abfrage über einen alternativen vorgesehenen DNS-Server; 3. Abfrage über den autoritativen DNS-Server der betroffenen Zone. Wenn der autoritative Server schnell und korrekt antwortet, der rekursive Server jedoch langsam ist, liegt die Ursache wahrscheinlich bei Rekursion, Cache, Weiterleitung oder Delegationspfad. --- **7.11.24 Delegation der Reverse-Zone prüfen** Für eine Rückwärtsauflösung muss die DNS-Hierarchie auf den zuständigen autoritativen Server verweisen. **Linux und macOS** ```bash dig -x 192.0.2.25 +trace ``` Zuständige Nameserver der Reverse-Zone prüfen: ```bash 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: ```text host25.example.test. A 192.0.2.25 ``` ```text 25.2.0.192.in-addr.arpa. PTR host25.example.test. ``` Anschließend wird der PTR-Zielname wieder vorwärts aufgelöst: ```text host25.example.test. A 192.0.2.25 ``` Prüfschritte: 1. IP-Adresse rückwärts auflösen. 2. PTR-Zielnamen dokumentieren. 3. PTR-Zielnamen über A und AAAA auflösen. 4. Prüfen, ob die ursprüngliche IP-Adresse in den Ergebnissen enthalten ist. 5. Alle beteiligten autoritativen DNS-Server vergleichen. Mögliche Befunde: | Befund | Einordnung | |---|---| | kein PTR vorhanden | Reverse-Eintrag fehlt oder Zone ist nicht erreichbar | | PTR zeigt auf alten Hostnamen | veralteter Datensatz | | PTR-Zielname existiert nicht | unvollständige DNS-Konfiguration | | PTR-Zielname zeigt auf andere IP | Vorwärts- und Rückwärtsdaten stimmen nicht überein | | mehrere PTR-Einträge | technisch möglich, kann Anwendungen jedoch unterschiedlich beeinflussen | | mehrere A- oder AAAA-Adressen | kann bei Clustern, Load Balancing oder Mehrfachanbindung vorgesehen sein | | verschiedene DNS-Server liefern verschiedene PTR-Werte | Replikation, Zonentransfer oder uneinheitliche Konfiguration prüfen | Eine Vorwärts-Rückwärts-Konsistenz ist nicht für jede DNS-Anwendung zwingend vorgeschrieben. Bestimmte Mail-, Sicherheits- oder Identitätsprüfungen können sie jedoch voraussetzen. --- **7.11.27 Windows-DNS-Serverdienst und Zonen prüfen** Auf dem DNS-Server: ```powershell Get-Service -Name DNS ``` Zonen anzeigen: ```powershell Get-DnsServerZone ``` Nur Reverse-Lookup-Zonen: ```powershell Get-DnsServerZone | Where-Object { $_.IsReverseLookupZone } ``` Zustand einer bestimmten Zone: ```powershell 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: ```powershell Get-DnsServerResourceRecord ` -ZoneName "2.0.192.in-addr.arpa" ` -RRType PTR ``` Bestimmten Eintrag prüfen: ```powershell Get-DnsServerResourceRecord ` -ZoneName "2.0.192.in-addr.arpa" ` -Name "25" ` -RRType PTR ``` Von einem bestimmten DNS-Server lesen: ```powershell 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: ```powershell Get-DnsServerForwarder ``` Rekursionseinstellungen: ```powershell Get-DnsServerRecursion ``` Root Hints: ```powershell Get-DnsServerRootHint ``` Cacheeinstellungen: ```powershell 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: ```powershell Get-DnsServerStatistics ``` Statistiken einer bestimmten Zone: ```powershell 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: ```powershell Get-Counter -ListSet DNS ``` Beispiel für empfangene DNS-Abfragen und gesendete Antworten: ```powershell Get-Counter ` '\DNS\Total Query Received/sec', '\DNS\Total Response Sent/sec' ` -SampleInterval 2 ` -MaxSamples 10 ``` DNS-Prozess überwachen: ```powershell 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: ```text 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: ```powershell Register-DnsClient ``` Alternativ: ```cmd 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: ```cmd dcdiag /test:DNS /v /s: ``` Replikationsübersicht: ```cmd repadmin /replsummary ``` Replikationsdetails: ```cmd 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** 1. **Störungsbild dokumentieren** Client, Anwendung, Name oder IP-Adresse, Uhrzeit und genaue Verzögerung erfassen. 2. **Abfragerichtung bestimmen** Vorwärtsauflösung, Rückwärtsauflösung oder beide unterscheiden. 3. **Umfang bestimmen** Einzelner Client, Anwendung, Standort, Zone oder alle Systeme unterscheiden. 4. **Resolverpfad erfassen** DNS-Server, VPN, Suchsuffixe, Hosts-Datei, NRPT, DoH, DoT und lokale Resolver prüfen. 5. **Abfrage reproduzieren** Den vorgesehenen DNS-Server ausdrücklich angeben. 6. **Antwortcode dokumentieren** `NOERROR`, `NXDOMAIN`, `SERVFAIL`, `REFUSED` oder Timeout unterscheiden. 7. **Antwortzeit messen** Erste und wiederholte Abfrage getrennt messen. 8. **Vorwärts- und Reverse-Abfrage vergleichen** A beziehungsweise AAAA und PTR unabhängig testen. 9. **Alternativen DNS-Server testen** Unterschiedliche Serverantworten dokumentieren. 10. **UDP und TCP vergleichen** Transportabhängige Fehler abgrenzen. 11. **DoH oder DoT abgrenzen** Verschlüsselten und klassischen DNS-Pfad getrennt prüfen. 12. **Autoritativen Server bestimmen** Delegation und zuständige Zone prüfen. 13. **Direkte autoritative Abfrage durchführen** Rekursion und Forwarder vom Zonenzustand trennen. 14. **PTR-Datensatz prüfen** Zielname, TTL, Zeitstempel und Eigentümer auswerten. 15. **Vorwärts-Rückwärts-Konsistenz prüfen** PTR-Zielnamen erneut über A und AAAA auflösen. 16. **Weitere Datensatztypen prüfen** CNAME- oder SRV-Abhängigkeiten berücksichtigen. 17. **Cachezustand prüfen** Client-, Server- und Anwendungscache unterscheiden. 18. **Forwarder und Rekursion prüfen** Besonders bei langsamen externen oder bedingt weitergeleiteten Zonen. 19. **EDNS, MTU und DNSSEC prüfen** Wenn kleine Antworten funktionieren und größere Antworten ausfallen. 20. **Serverleistung prüfen** Abfragerate, CPU, Speicher, Fehler und Timeouts korrelieren. 21. **Dynamische Aktualisierung prüfen** Client, DHCP, Berechtigungen und Zonenrichtlinie untersuchen. 22. **Aging und Scavenging prüfen** Veraltete oder unerwartet gelöschte Datensätze abgrenzen. 23. **AD-Replikation prüfen** Wenn DNS-Server unterschiedliche Antworten liefern. 24. **Hypothese formulieren** Erwarteten Befund und möglichen Gegenbeweis festlegen. 25. **Eine kontrollierte Maßnahme durchführen** Risiko, Rückweg und Erfolgskriterium dokumentieren. 26. **Erneut unter denselben Bedingungen messen** Antwort, Code und Zeit mit dem Ausgangswert vergleichen. 27. **Gesamten DNS-Pfad verifizieren** Client, rekursiven Server, autoritativen Server und Anwendung prüfen. 28. **Präventionsmaßnahme dokumentieren** Ursache und dauerhafte Verbesserung festhalten. --- **7.11.39 Befundmatrix** | Befund | Mögliche Erklärung | Nächster Nachweis | |---|---|---| | `nslookup` zeigt `Unknown`, andere Abfragen funktionieren | PTR des DNS-Servers fehlt | DNS-Server-IP rückwärts abfragen | | Vorwärtsauflösung funktioniert, Reverse nicht | PTR oder Reverse-Zone fehlt | PTR-Abfrage und Zonenprüfung | | Reverse-Abfrage endet sofort mit `NXDOMAIN` | Name oder Zone meldet Nichtvorhandensein | Autorität und SOA der Antwort prüfen | | Reverse-Abfrage läuft in Timeout | Server, Delegation oder Netzwerkpfad antwortet nicht | autoritative Server und Paketpfad prüfen | | PTR zeigt auf alten Hostnamen | veralteter statischer oder dynamischer Eintrag | Lease, Zeitstempel und Datensatzeigentümer prüfen | | PTR-Zielname besitzt keinen A-/AAAA-Eintrag | unvollständige DNS-Konfiguration | Zielnamen vorwärts auflösen | | PTR-Zielname zeigt auf andere IP | Vorwärts-Rückwärts-Abweichung | vorgesehene Mehrfachadressierung prüfen | | erste Abfrage langsam, zweite schnell | Cacheeffekt | kalte und warme Messung vergleichen | | jede externe Abfrage langsam | Forwarder oder Rekursion | direkte Abfragen gegen Forwarder und Autorität | | nur interne Zone langsam | interne Delegation oder AD-DNS | autoritative interne Server vergleichen | | nur ein DNS-Server liefert falsche Antwort | lokaler Cache, Zone oder Replikation | Server direkt vergleichen | | UDP fehlerhaft, TCP erfolgreich | Firewall, EDNS, Fragmentierung oder MTU | Transportvergleich und Netzwerkaufzeichnung | | `SERVFAIL` nur bei signierter Zone | DNSSEC-Validierung oder Delegation | Validierungskette und Serverereignisse prüfen | | `REFUSED` | Rekursion oder Richtlinie verweigert Abfrage | Serverrichtlinie und Quellnetz prüfen | | A-Eintrag vorhanden, PTR fehlt | Reverse-Zone oder Updatepfad fehlt | DHCP-, Client- und Zonenupdate prüfen | | PTR wird nach IP-Wechsel nicht entfernt | Aging, Scavenging oder DHCP-Bereinigung | Leaseablauf, Zeitstempel und Zonenalterung | | unterschiedliche Antworten je DC | AD-Replikation oder uneinheitliche Zone | `repadmin`, `dcdiag` und direkte Abfragen | | Auflösung über IP schnell, über Namen langsam | DNS oder nachgelagerte Namensprüfung | direkte DNS-Zeit und Anwendungspfad vergleichen | | öffentliche IP besitzt keinen PTR | Provider hat keinen Reverse-Eintrag gesetzt | Betreiber des IP-Präfixes ermitteln | | neuer Datensatz bleibt zunächst unsichtbar | positiver oder negativer Cache | TTL und Cacheebenen prüfen | | `nslookup` und Anwendung liefern verschiedene Ergebnisse | NRPT, DoH oder anwendungseigener Resolver | tatsächlichen Resolverpfad bestimmen | | nur große Antworten schlagen fehl | EDNS-, MTU- oder Fragmentierungsproblem | UDP/TCP und Antwortgrößen vergleichen | | SRV wird gefunden, Dienst funktioniert nicht | Zielhost, Port oder Dienst fehlerhaft | SRV-Ziel und Dienstport prüfen | | CNAME wird aufgelöst, Zielname jedoch nicht | fehlerhaftes Aliasziel | CNAME-Kette vollständig prüfen | | klassisches DNS funktioniert, DoH nicht | Zertifikat, HTTPS-Port oder DoH-Endpunkt | DoH-Zustand und TLS-Verbindung prüfen | --- **7.11.40 Ursachen und erforderliche Nachweise** | Mögliche Ursache | Erforderlicher Nachweis | |---|---| | falscher DNS-Server | Clientkonfiguration und direkte Abfragen bestätigen abweichenden Resolver | | falsches DNS-Suffix | Resolverkonfiguration zeigt unerwartete Suchdomäne | | Hosts-Datei überschreibt DNS | lokaler Eintrag liefert abweichende Zuordnung | | anwendungseigener DNS-Cache | Anwendung liefert trotz korrektem Systemtest alten Wert | | NRPT-Fehler | wirksame Richtlinie leitet den Namensraum an falschen Resolver | | fehlerhafter Split-DNS-Pfad | interne und externe Resolver liefern unbeabsichtigt verschiedene Antworten | | DoH- oder DoT-Fehler | verschlüsselter Pfad scheitert bei funktionierendem klassischem DNS | | fehlende Reverse-Zone | zuständiger DNS-Server besitzt oder erreicht die Zone nicht | | fehlender PTR-Eintrag | autoritative PTR-Abfrage liefert keinen Datensatz | | falscher PTR-Eintrag | autoritative Antwort enthält unerwarteten Zielnamen | | fehlerhafte Delegation | übergeordnete Zone verweist auf falsche oder nicht erreichbare Server | | fehlerhafte RFC-2317-Konfiguration | CNAME- und Zonendelegation des Teilnetzes sind unvollständig | | fehlerhafte IPv6-Reverse-Zone | Nibble-Zone stimmt nicht mit dem delegierten Präfix überein | | nicht erreichbarer Forwarder | direkte Abfrage zum Forwarder scheitert reproduzierbar | | langsamer autoritativer Server | direkte autoritative Abfrage zeigt erhöhte Antwortzeit | | UDP-Blockierung | UDP-DNS scheitert, TCP-DNS funktioniert | | TCP-Blockierung | abgeschnittene UDP-Antwort kann nicht über TCP wiederholt werden | | Paketverlust | Aufzeichnung zeigt Wiederholungen oder fehlende Antworten | | MTU- oder Fragmentierungsproblem | große UDP-Antworten scheitern, TCP funktioniert | | DNS-Serverüberlastung | erhöhte Antwortzeit korreliert mit Abfragerate und Ressourcenlast | | ungeeignete TTL | Datensatz- und Cachewerte bestätigen zu kurze oder zu lange Speicherung | | negativer Cache | zuvor negative Antwort bleibt bis zum Ablauf wirksam | | falscher CNAME | Alias verweist auf fehlenden oder falschen Zielnamen | | falscher SRV-Eintrag | Dienstziel, Port, Priorität oder Gewicht sind unzutreffend | | DHCP aktualisiert PTR nicht | DHCP-Ereignis oder Konfiguration bestätigt fehlgeschlagene Aktualisierung | | fehlende Updateberechtigung | DNS- oder DHCP-Protokoll zeigt Zugriffsfehler | | veralteter statischer PTR | statischer Datensatz enthält alten Namen | | fehlerhaftes Scavenging | Konfiguration oder Ereignisse bestätigen unerwartete Löschung | | AD-Replikationsproblem | DNS-Server liefern unterschiedliche autoritative Daten und `repadmin` meldet Fehler | | DNSSEC-Validierungsfehler | `SERVFAIL` und Validierungsdaten bestätigen fehlerhafte Vertrauenskette | | öffentlicher PTR nicht delegiert | Provider beziehungsweise Präfixbetreiber bestätigt fehlende Reverse-Konfiguration | --- **7.11.41 Kontrollierte Maßnahmen, Risiko und Rückweg** | Maßnahme | Risiko | Rückweg beziehungsweise Kontrolle | |---|---|---| | vorgesehenen DNS-Server konfigurieren | andere Namensräume können beeinflusst werden | bisherige DNS-Werte dokumentieren | | falsches DNS-Suffix korrigieren | Suchverhalten verändert sich | ursprüngliche Suffixliste sichern | | fehlerhaften Hosts-Eintrag entfernen | Anwendung verliert lokale Sonderzuordnung | Datei und ursprünglichen Eintrag sichern | | NRPT-Regel korrigieren | VPN-Namensauflösung kann ausfallen | bisherige Regel und Zielserver sichern | | DoH- oder DoT-Konfiguration korrigieren | Transport und Fallbackverhalten ändern sich | bisherigen Verschlüsselungszustand dokumentieren | | fehlende Reverse-Zone anlegen | falscher Adressbereich kann überschrieben werden | Netz-ID und Zuständigkeit vorher bestätigen | | PTR-Eintrag anlegen | falscher Name wird veröffentlicht | IP, FQDN und Forward-Eintrag vorher prüfen | | veralteten PTR korrigieren | bestehende Abhängigkeiten können betroffen sein | alten Wert und Eigentümer dokumentieren | | Forwarder korrigieren | externe und interne Auflösung kann beeinflusst werden | bisherige Forwarderliste sichern | | Delegation korrigieren | gesamter Reverse-Bereich kann betroffen sein | bisherige NS- und CNAME-Daten sichern | | dynamische Updates korrigieren | viele Clients können Datensätze verändern | Zonenrichtlinie und Berechtigungen dokumentieren | | Clientregistrierung auslösen | mehrere A- oder PTR-Einträge können entstehen | vorhandene Einträge vorher erfassen | | Clientcache kontrolliert löschen | ursprünglicher Cachebefund geht verloren | Cacheinhalt vorher dokumentieren | | DNS-Servercache löschen | viele Abfragen müssen erneut rekursiv aufgelöst werden | nur gezielt und mit Lastkontrolle | | TTL ändern | Cacheverhalten vieler Resolver ändert sich | bisherigen Wert und Änderungszeit sichern | | Aging oder Scavenging anpassen | gültige Datensätze können gelöscht werden | Zonenexport und Änderungsplan vorsehen | | AD-Replikationsfehler beheben | mehrere DNS- und AD-Daten können betroffen sein | DC-spezifischen Wiederherstellungsplan verwenden | | analytische Protokollierung aktivieren | Leistung und Datenschutz können betroffen sein | Zeitfenster, Speicherlimit und Abschaltung festlegen | Pro Diagnoseversuch sollte möglichst nur eine relevante Variable verändert werden. --- **7.11.42 Beispiel: Reverse-Zone und PTR-Eintrag anlegen** Die folgenden Befehle sind verändernde Administrationsmaßnahmen und dürfen erst nach Prüfung von Netzbereich, Zonenverantwortung, Replikationsbereich und bestehender Konfiguration ausgeführt werden. AD-integrierte IPv4-Reverse-Zone für das Dokumentationsnetz `192.0.2.0/24`: ```powershell Add-DnsServerPrimaryZone ` -NetworkID "192.0.2.0/24" ` -ReplicationScope "Forest" ``` PTR-Eintrag für `192.0.2.25`: ```powershell Add-DnsServerResourceRecordPtr ` -Name "25" ` -ZoneName "2.0.192.in-addr.arpa" ` -PtrDomainName "host25.example.test." ``` Danach kontrollieren: ```powershell Get-DnsServerResourceRecord ` -ZoneName "2.0.192.in-addr.arpa" ` -Name "25" ` -RRType PTR ``` ```powershell 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: ```powershell 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: ```text 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](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-guidance) - [Microsoft Learn – Troubleshoot DNS servers](https://learn.microsoft.com/en-us/windows-server/networking/dns/troubleshoot/troubleshoot-dns-server) - [Microsoft Learn – Troubleshoot DNS client name resolution issues](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/troubleshoot-dns-client-resolution-issues) - [Microsoft Learn – DNS queries and lookups](https://learn.microsoft.com/en-us/windows-server/networking/dns/queries-lookups) - [Microsoft Learn – DNS architecture](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-architecture) - [Microsoft Learn – Manage DNS zones](https://learn.microsoft.com/en-us/windows-server/networking/dns/manage-dns-zones) - [Microsoft Learn – Manage DNS resource records](https://learn.microsoft.com/en-us/windows-server/networking/dns/manage-resource-records) - [Microsoft Learn – Dynamic DNS Update in Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/dynamic-update) - [Microsoft Learn – DNS scavenging setup](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dns-scavenging-setup) - [Microsoft Learn – Troubleshoot DNS scavenging issues](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-scavenging-issues) - [Microsoft Learn – Forwarders and conditional forwarders resolution timeouts](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/forwarders-resolution-timeouts) - [Microsoft Learn – Enable DNS logging and diagnostics](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-logging-and-diagnostics) - [Microsoft Learn – DNS encryption using DNS over HTTPS](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-encryption-dns-over-https) - [Microsoft Learn – Enable DNS over HTTPS in DNS Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/enable-dns-over-https-server) - [Microsoft Learn – Troubleshoot DNS over HTTPS in DNS Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/troubleshoot-dns-over-https-server) - [Microsoft Learn – Secure DNS Client over HTTPS](https://learn.microsoft.com/en-us/windows-server/networking/dns/doh-client-support) - [Microsoft Learn – netsh dnsclient](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-dnsclient) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – DnsClient PowerShell module](https://learn.microsoft.com/en-us/powershell/module/dnsclient/) - [Microsoft Learn – Clear-DnsClientCache](https://learn.microsoft.com/en-us/powershell/module/dnsclient/clear-dnsclientcache) - [Microsoft Learn – Register-DnsClient](https://learn.microsoft.com/en-us/powershell/module/dnsclient/register-dnsclient) - [Microsoft Learn – Get-DnsServerZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverzone) - [Microsoft Learn – Get-DnsServerResourceRecord](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverresourcerecord) - [Microsoft Learn – Add-DnsServerPrimaryZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverprimaryzone) - [Microsoft Learn – Add-DnsServerResourceRecordPtr](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverresourcerecordptr) - [Microsoft Learn – Get-DnsServerStatistics](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverstatistics) - [Microsoft Learn – Get-DnsServerCache](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsservercache) - [Microsoft Learn – Clear-DnsServerCache](https://learn.microsoft.com/en-us/powershell/module/dnsserver/clear-dnsservercache) - [Microsoft Learn – Set-DnsServerEncryptionProtocol](https://learn.microsoft.com/en-us/powershell/module/dnsserver/set-dnsserverencryptionprotocol) - [Microsoft Learn – DnsServer PowerShell module](https://learn.microsoft.com/en-us/powershell/module/dnsserver/) - [Microsoft Learn – Verify that SRV DNS records have been created](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/verify-srv-dns-records-have-been-created) - [Microsoft Learn – Dcdiag](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dcdiag) - [Microsoft Learn – Diagnose Active Directory replication failures](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/diagnose-replication-failures) **Standards** - [RFC 1034 – Domain Names: Concepts and Facilities](https://datatracker.ietf.org/doc/html/rfc1034) - [RFC 1035 – Domain Names: Implementation and Specification](https://datatracker.ietf.org/doc/html/rfc1035) - [RFC 2308 – Negative Caching of DNS Queries](https://datatracker.ietf.org/doc/html/rfc2308) - [RFC 2317 – Classless IN-ADDR.ARPA Delegation](https://datatracker.ietf.org/doc/html/rfc2317) - [RFC 3596 – DNS Extensions to Support IPv6](https://datatracker.ietf.org/doc/html/rfc3596) - [RFC 7858 – Specification for DNS over Transport Layer Security](https://datatracker.ietf.org/doc/html/rfc7858) - [RFC 8484 – DNS Queries over HTTPS](https://datatracker.ietf.org/doc/html/rfc8484) - [RFC 8499 – DNS Terminology](https://datatracker.ietf.org/doc/html/rfc8499) 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** 1. Zuerst beobachten und dokumentieren. 2. Den exakten Namen und Datensatztyp verwenden. 3. Clientverhalten und direkte DNS-Abfrage unterscheiden. 4. Den tatsächlich verwendeten DNS-Server bestimmen. 5. Antwortcode und Antwortinhalt getrennt bewerten. 6. Positive, negative und ausgebliebene Antworten unterscheiden. 7. Cache-, rekursive und autoritative Antworten trennen. 8. UDP, TCP, DoH und DoT nicht gleichsetzen. 9. Pro Versuch nur eine relevante Variable verändern. 10. Vor jeder Änderung Risiko und Rückweg dokumentieren. 11. Nach der Maßnahme denselben Test wiederholen. 12. Erst nach technischer Verifikation den Vorgang abschließen. Folgende Maßnahmen sind keine geeigneten ersten Diagnoseschritte: - 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: ```text server01 ``` ist für eine eindeutige DNS-Diagnose ungeeignet, solange nicht feststeht, welches DNS-Suffix ergänzt wird. Besser: ```text 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** ```powershell Get-NetIPConfiguration ``` ```cmd ipconfig /all ``` **Linux** ```bash ip address ``` ```bash ip route ``` **macOS** ```bash ifconfig ``` ```bash 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** ```powershell Get-DnsClientServerAddress ``` ```powershell Get-DnsClient ``` **Linux** ```bash cat /etc/resolv.conf ``` Bei `systemd-resolved`: ```bash resolvectl status ``` **macOS** ```bash 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: ```text server01 ``` kann der Resolver abhängig von seiner Suchliste nacheinander verschiedene Namen bilden: ```text server01.example.test server01.branch.example.test server01.other.example.test ``` Windows-Konfiguration prüfen: ```powershell Get-DnsClient ``` Linux mit `systemd-resolved`: ```bash resolvectl status ``` macOS: ```bash 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: ```powershell Get-DnsClientNrptPolicy ``` Konfigurierte NRPT-Regeln: ```powershell Get-DnsClientNrptRule ``` DNS-Clientzustand: ```cmd netsh dnsclient show state ``` Globale verschlüsselte DNS-Einstellungen: ```cmd netsh dnsclient show global ``` Konfigurierte DoH- oder DoT-Endpunkte: ```cmd 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: 1. Kann die Ziel-IP-Adresse direkt erreicht werden? 2. Liefert eine direkte DNS-Abfrage die erwartete Adresse? 3. Liefert der normale Betriebssystemresolver dieselbe Adresse? 4. Verwendet die Anwendung dieselbe Adresse? 5. Ist der eigentliche Dienst auf der Zieladresse erreichbar? Beispiel: ```powershell Resolve-DnsName "app.example.test" ``` Direkte Abfrage gegen einen bestimmten DNS-Server: ```powershell 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** ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ``` **Windows Eingabeaufforderung** ```cmd nslookup app.example.test 192.0.2.53 ``` **Linux und macOS** ```bash 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: ```powershell Resolve-DnsName "app.example.test" -Type A ``` ```powershell Resolve-DnsName "alias.example.test" -Type CNAME ``` ```powershell Resolve-DnsName "_service._tcp.example.test" -Type SRV ``` ```powershell Resolve-DnsName "example.test" -Type SOA ``` ```powershell 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** ```powershell Measure-Command { Resolve-DnsName ` -Name "app.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly } ``` **Linux und macOS** ```bash 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** ```powershell Get-DnsClientCache ``` Alternativ: ```cmd ipconfig /displaydns ``` **Linux mit systemd-resolved** ```bash resolvectl statistics ``` **Windows-DNS-Servercacheeinstellungen** ```powershell 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: 1. Ein Name wird abgefragt und liefert `NXDOMAIN`. 2. Der fehlende Datensatz wird anschließend angelegt. 3. Der Client oder rekursive Resolver liefert zunächst weiterhin die gespeicherte negative Antwort. 4. Erst nach Ablauf oder kontrollierter Löschung des Cacheeintrags wird der neue Datensatz sichtbar. Deshalb müssen SOA-Daten, negative TTL und alle beteiligten Cacheebenen berücksichtigt werden. --- **7.12.22 DNS-Server vergleichen** Eine identische Abfrage muss gezielt an jeden vorgesehenen DNS-Server gesendet werden. **Windows** ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ``` ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Type A ` -Server "192.0.2.54" ` -DnsOnly ``` **Linux und macOS** ```bash dig @192.0.2.53 app.example.test A ``` ```bash 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: ```powershell Test-NetConnection "192.0.2.53" -Port 53 ``` Dieser Befehl prüft nur TCP. Normale DNS-Abfrage: ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Server "192.0.2.53" ` -DnsOnly ``` TCP erzwingen: ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Server "192.0.2.53" ` -DnsOnly ` -TcpOnly ``` Mit `dig`: ```bash dig @192.0.2.53 app.example.test A ``` ```bash 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: ```bash dig @192.0.2.53 example.com A +dnssec ``` ```bash dig @192.0.2.53 example.com A +dnssec +tcp ``` Test ohne EDNS: ```bash 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: ```cmd netsh dnsclient show state ``` ```cmd netsh dnsclient show encryption ``` Bei verschlüsseltem DNS kann eine klassische Paketaufzeichnung den DNS-Inhalt nicht ohne zusätzliche, autorisierte Entschlüsselungsinformationen anzeigen. Ein erfolgreicher Test gegen UDP- oder TCP-Port `53` beweist nicht, dass ein DoH- oder DoT-Endpunkt funktioniert. --- **7.12.26 Rekursiven und autoritativen DNS-Server unterscheiden** Ein rekursiver DNS-Server beschafft die Antwort im Auftrag des Clients. Ein autoritativer DNS-Server verwaltet die maßgeblichen Daten einer Zone. Diagnosevergleich: 1. Client fragt vorgesehenen rekursiven DNS-Server. 2. Rekursiver Server liefert Fehler oder langsame Antwort. 3. Autoritativer DNS-Server wird direkt abgefragt. 4. Ergebnisse werden verglichen. Wenn der autoritative Server korrekt und schnell antwortet, liegt die Ursache wahrscheinlich bei: - 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: ```powershell Resolve-DnsName ` -Name "example.test" ` -Type SOA ` -Server "192.0.2.53" ` -DnsOnly ``` NS prüfen: ```powershell Resolve-DnsName ` -Name "example.test" ` -Type NS ` -Server "192.0.2.53" ` -DnsOnly ``` Mit `dig`: ```bash dig @192.0.2.53 example.test SOA ``` ```bash dig @192.0.2.53 example.test NS ``` Öffentliche Delegationskette verfolgen: ```bash 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: ```powershell Get-DnsServerForwarder ``` ```powershell Get-DnsServerRecursion ``` ```powershell Get-DnsServerRootHint ``` Zonen und bedingte Weiterleitungen: ```powershell 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** ```powershell Resolve-DnsName ` -Name "192.0.2.25" ` -Type PTR ` -Server "192.0.2.53" ` -DnsOnly ``` **Linux und macOS** ```bash dig @192.0.2.53 -x 192.0.2.25 ``` Danach muss der PTR-Zielname wieder vorwärts geprüft werden: ```powershell 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: ```powershell Resolve-DnsName ` -Name "example.com" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ` -DnssecOk ``` Mit `dig`: ```bash 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: ```powershell Get-Service -Name DNS ``` Zonen: ```powershell Get-DnsServerZone ``` Bestimmte Zone: ```powershell Get-DnsServerZone ` -Name "example.test" ``` Datensätze: ```powershell Get-DnsServerResourceRecord ` -ZoneName "example.test" ``` Serverstatistiken: ```powershell Get-DnsServerStatistics ``` Verfügbare Leistungsindikatoren: ```powershell 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: ```powershell Resolve-DnsName ` -Name "_ldap._tcp.dc._msdcs." ` -Type SRV ``` Kerberos-SRV-Einträge: ```powershell Resolve-DnsName ` -Name "_kerberos._tcp." ` -Type SRV ``` DNS-Test eines Domänencontrollers: ```cmd dcdiag /test:DNS /v /s: ``` Replikationsübersicht: ```cmd repadmin /replsummary ``` Replikationsdetails: ```cmd 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: ```powershell Register-DnsClient ``` Alternativ: ```cmd 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: ```powershell 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: ```text 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** 1. **Exakte Fehlermeldung aufnehmen** Wortlaut, Anwendung, Benutzer, Client und Uhrzeit dokumentieren. 2. **Betroffenen Namen bestimmen** Kurzname, FQDN oder IP-Adresse unterscheiden. 3. **Erwarteten Datensatztyp bestimmen** A, AAAA, CNAME, PTR, SRV, MX, TXT, NS oder SOA festlegen. 4. **Erwartetes Ergebnis dokumentieren** Vorgesehene IP-Adresse, Zielname oder Dienstinformation festhalten. 5. **Umfang bestimmen** Einzelnen Client, Standort, DNS-Server, Namen, Zone oder alle Systeme unterscheiden. 6. **Anwendung und DNS abgrenzen** Direkte IP-Verbindung, Systemresolver und Anwendung getrennt prüfen. 7. **Netzwerkzustand erfassen** Schnittstelle, Adresse, Gateway, VPN und Routing dokumentieren. 8. **Konfigurierte DNS-Server erfassen** DNS-Server pro Schnittstelle und Reihenfolge bestimmen. 9. **Suffixe und lokale Namensquellen prüfen** Suchliste, Hosts-Datei und Anwendungscache berücksichtigen. 10. **Resolverrichtlinien prüfen** NRPT, Split-DNS, Container-DNS und Sicherheitsresolver berücksichtigen. 11. **Verschlüsselten DNS-Pfad bestimmen** Klassisches DNS, DoH und DoT unterscheiden. 12. **Normale Systemauflösung testen** Prüfen, welches Ergebnis die Anwendung grundsätzlich erhalten kann. 13. **Direkte Abfrage durchführen** Vorgesehenen DNS-Server und Datensatztyp ausdrücklich angeben. 14. **Antwortcode auswerten** `NOERROR`, `NXDOMAIN`, `SERVFAIL`, `REFUSED` oder Timeout unterscheiden. 15. **Antwortinhalt auswerten** Wert, TTL, CNAME-Kette und Flags prüfen. 16. **Antwortzeit messen** Erste und wiederholte Abfrage vergleichen. 17. **Alternativen DNS-Server prüfen** Unterschiede zwischen vorgesehenen Resolvern dokumentieren. 18. **Cachezustand prüfen** Positive und negative Einträge auf allen relevanten Ebenen berücksichtigen. 19. **UDP und TCP vergleichen** Transportabhängige Fehler bestimmen. 20. **EDNS, MTU und Fragmentierung prüfen** Besonders bei großen Antworten oder VPN-Verbindungen. 21. **Rekursiven und autoritativen Server unterscheiden** Abfrageweg in einzelne Ebenen zerlegen. 22. **SOA, NS und Delegation prüfen** Zuständigkeit und Zonengrenze bestätigen. 23. **Autoritative Server direkt vergleichen** Datensatz, TTL, Seriennummer und Antwortcode auswerten. 24. **Forwarder und Rekursion prüfen** Erreichbarkeit, Richtlinien und Timeoutpfad untersuchen. 25. **DNSSEC prüfen** Signaturen, DS, DNSKEY, Trust Anchor und Validierungsfehler berücksichtigen. 26. **Reverse-Lookup prüfen** PTR, Reverse-Zone, Delegation und Vorwärtskonsistenz auswerten. 27. **DNS-Serverzustand prüfen** Dienst, Zonen, Statistiken, Last und Ereignisse untersuchen. 28. **AD-DNS und Replikation prüfen** Wenn AD-integrierte Zonen oder SRV-Einträge beteiligt sind. 29. **Dynamische Updates und DHCP prüfen** Registrierung, Eigentümer, Berechtigungen und Leasezustand auswerten. 30. **Aging und Scavenging prüfen** Bei veralteten oder unerwartet fehlenden Einträgen. 31. **Protokolle korrelieren** Client, DNS-Server, DHCP und Anwendung auf denselben Versuch begrenzen. 32. **Bei Bedarf Netzwerkaufzeichnung durchführen** Nur zeitlich und technisch begrenzt. 33. **Hypothese und Gegenbeweis formulieren** Ursache vor der Änderung messbar beschreiben. 34. **Eine kontrollierte Maßnahme ausführen** Risiko, Rückweg und Erfolgskriterium beachten. 35. **Identischen Test wiederholen** Antwortcode, Wert und Zeit mit dem Ausgangszustand vergleichen. 36. **Alternativen Pfad erneut prüfen** Weitere Clients, Resolver oder autoritative Server kontrollieren. 37. **Anwendung verifizieren** Nicht nur das Diagnosewerkzeug testen. 38. **Temporäre Änderungen zurücknehmen** Logging, Testregeln und Ausnahmen entfernen. 39. **Ursache dokumentieren** Technischen Nachweis und betroffenen Pfad festhalten. 40. **Prävention festlegen** Monitoring, Standardisierung oder Konfigurationsverbesserung umsetzen. --- **7.12.40 Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | IP-Verbindung funktioniert, Name nicht | DNS oder lokaler Resolverpfad | direkte A-/AAAA-Abfrage | | direkter DNS-Test funktioniert, Anwendung nicht | Anwendungscache, Proxy oder eigener Resolver | Anwendungsresolver und Zieladresse prüfen | | nur Kurzname schlägt fehl | Suffix- oder Suchlistenproblem | FQDN und Suffixkonfiguration vergleichen | | nur ein Client betroffen | lokale Konfiguration, Cache oder Hosts-Datei | anderen Client und direkte Serverabfrage vergleichen | | nur ein DNS-Server betroffen | Zone, Cache, Dienst oder Replikation | DNS-Server direkt vergleichen | | ganze Zone liefert `NXDOMAIN` | falscher Resolver oder fehlende Delegation | SOA, NS und autoritative Server prüfen | | `NOERROR`, aber keine A-Antwort | Name vorhanden, Datensatztyp fehlt | CNAME, AAAA und SOA prüfen | | `SERVFAIL` | Rekursion, DNSSEC oder Serverfehler | autoritative Abfrage und Protokolle | | `REFUSED` | Richtlinie, ACL oder deaktivierte Rekursion | Serverkonfiguration und Quellnetz prüfen | | Timeout | fehlende Antwort | Transport, Netzwerk und Serverlast prüfen | | UDP schlägt fehl, TCP funktioniert | Firewall, MTU, Fragmentierung oder EDNS | Netzwerkaufzeichnung und große Antwort prüfen | | erste Abfrage langsam, zweite schnell | Cacheeffekt | kalte und warme Abfrage vergleichen | | externe Namen langsam | Forwarder oder Rekursion | Forwarder direkt prüfen | | interne Namen langsam | interne Delegation, Forwarder oder AD-DNS | interne autoritative Server prüfen | | mit VPN falsche Antwort | NRPT oder Split-DNS | Resolver vor und nach VPN vergleichen | | Browser und System liefern verschiedene Antworten | Browser-DoH oder Anwendungscache | Browserresolver und Systemresolver vergleichen | | PTR fehlt, A funktioniert | Reverse-Zone oder PTR fehlt | Reverse-Delegation prüfen | | unterschiedliche Antworten je DC | AD-Replikation | `repadmin` und direkte DNS-Abfragen | | nur große Antworten scheitern | EDNS-, MTU- oder Fragmentierungsproblem | UDP/TCP-Vergleich | | nur signierte Zonen scheitern | DNSSEC-Validierungsfehler | DS-, DNSKEY- und EDE-Auswertung | | neuer Datensatz bleibt unsichtbar | positiver oder negativer Cache | TTL und Cacheebenen prüfen | | SRV vorhanden, Dienst nicht erreichbar | Zielhost, Port oder Dienst fehlerhaft | SRV-Ziel und Dienstport prüfen | --- **7.12.41 Typische Diagnosefehler** - 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** ```text 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: ```text 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](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-guidance) - [Microsoft Learn – Troubleshooting DNS clients](https://learn.microsoft.com/en-us/windows-server/networking/dns/troubleshoot/troubleshoot-dns-client) - [Microsoft Learn – Troubleshooting DNS servers](https://learn.microsoft.com/en-us/windows-server/networking/dns/troubleshoot/troubleshoot-dns-server) - [Microsoft Learn – Troubleshoot DNS client name resolution issues](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/troubleshoot-dns-client-resolution-issues) - [Microsoft Learn – Troubleshoot DNS name resolution on the Internet](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-name-resolution) - [Microsoft Learn – DNS queries and lookups](https://learn.microsoft.com/en-us/windows-server/networking/dns/queries-lookups) - [Microsoft Learn – DNS architecture](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-architecture) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – DnsClient PowerShell module](https://learn.microsoft.com/en-us/powershell/module/dnsclient/) - [Microsoft Learn – DnsServer PowerShell module](https://learn.microsoft.com/en-us/powershell/module/dnsserver/) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Best practices for DNS client settings](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/best-practices-for-dns-client-settings) - [Microsoft Learn – Forwarders and conditional forwarders resolution timeouts](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/forwarders-resolution-timeouts) - [Microsoft Learn – Dynamic DNS Update in Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/dynamic-update) - [Microsoft Learn – DNS scavenging setup](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dns-scavenging-setup) - [Microsoft Learn – Enable DNS logging and diagnostics](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-logging-and-diagnostics) - [Microsoft Learn – Validate and secure DNS responses using DNSSEC](https://learn.microsoft.com/en-us/windows-server/networking/dns/validate-dnssec-responses) - [Microsoft Learn – Secure DNS Client over HTTPS](https://learn.microsoft.com/en-us/windows-server/networking/dns/doh-client-support) - [Microsoft Learn – DNS encryption using DNS over HTTPS](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-encryption-dns-over-https) - [Microsoft Learn – netsh dnsclient](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-dnsclient) - [Microsoft Learn – Dcdiag](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dcdiag) - [Microsoft Learn – Verify DNS functionality to support directory replication](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/troubleshoot/verify-dns-functionality-to-support-directory-replication) **Offizielle Projektdokumentation** - [ISC BIND 9 – dig manual page](https://bind9.readthedocs.io/en/latest/manpages.html) - [ISC BIND 9 – Troubleshooting](https://bind9.readthedocs.io/en/v9.18.28/chapter9.html) - [systemd – resolvectl](https://www.freedesktop.org/software/systemd/man/resolvectl.html) - [systemd – systemd-resolved](https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html) **Standards** - [RFC 1034 – Domain Names: Concepts and Facilities](https://datatracker.ietf.org/doc/html/rfc1034) - [RFC 1035 – Domain Names: Implementation and Specification](https://datatracker.ietf.org/doc/html/rfc1035) - [RFC 2308 – Negative Caching of DNS Queries](https://datatracker.ietf.org/doc/html/rfc2308) - [RFC 4033 – DNS Security Introduction and Requirements](https://datatracker.ietf.org/doc/html/rfc4033) - [RFC 4035 – Protocol Modifications for DNS Security Extensions](https://datatracker.ietf.org/doc/html/rfc4035) - [RFC 6891 – Extension Mechanisms for DNS](https://datatracker.ietf.org/doc/html/rfc6891) - [RFC 7766 – DNS Transport over TCP](https://datatracker.ietf.org/doc/html/rfc7766) - [RFC 7858 – DNS over Transport Layer Security](https://datatracker.ietf.org/doc/html/rfc7858) - [RFC 8484 – DNS Queries over HTTPS](https://datatracker.ietf.org/doc/html/rfc8484) - [RFC 8499 – DNS Terminology](https://datatracker.ietf.org/doc/html/rfc8499) - [RFC 8914 – Extended DNS Errors](https://datatracker.ietf.org/doc/html/rfc8914) - [RFC 9520 – Negative Caching of DNS Resolution Failures](https://datatracker.ietf.org/doc/html/rfc9520) 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: ```text No space left on device ENOSPC Disk full There is not enough space on the disk Not enough disk space Quota exceeded EDQUOT Read-only file system EROFS I/O error DiskPressure Evicted ephemeral-storage Thin pool is full Metadata space exhausted ``` `No space left on device` kann sowohl auf erschöpfte Datenblöcke als auch auf erschöpfte Inodes oder interne Dateisystemreserven hinweisen. `Quota exceeded` betrifft dagegen gewöhnlich ein festgelegtes Speicherlimit und nicht zwingend das gesamte Dateisystem. --- **7.13.5 Sofortmaßnahmen ohne unkontrolliertes Löschen** 1. Exakte Fehlermeldung und Uhrzeit erfassen. 2. Betroffenen Host, Dienst, Benutzer, Container und Pfad bestimmen. 3. Kritikalität und Auswirkung bewerten. 4. Aktuelle Kapazität, Inodes, Quotas und Speicherpools dokumentieren. 5. Schreibintensive Prozesse und aktuelle Wachstumsrate identifizieren. 6. Bei akutem Wachstum eine kontrollierte Drosselung oder Beendigung des verursachenden Dienstes prüfen. 7. Keine unnötigen Neustarts durchführen. 8. Keine Protokolle, Datenbanken oder Container-Volumes spontan löschen. 9. Nur eindeutig entbehrliche und freigegebene Daten kontrolliert entfernen. 10. Nach jeder Maßnahme denselben Speichertest wiederholen. Ein Neustart kann die Situation verschärfen, wenn ein Dienst beim Start temporären Speicher benötigt oder eine Datenbank wegen fehlenden Speicherplatzes keine Wiederherstellung durchführen kann. --- **7.13.6 Speicherpfad vollständig abbilden** Der sichtbare Pfad kann mehrere Speicherebenen durchlaufen: ```text 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: ```text 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** ```powershell 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: ```powershell Get-PSDrive ` -PSProvider FileSystem ``` Lokale logische Laufwerke: ```powershell 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** ```powershell Get-Disk | Select-Object ` Number, FriendlyName, PartitionStyle, OperationalStatus, HealthStatus, Size ``` ```powershell Get-Partition | Select-Object ` DiskNumber, PartitionNumber, DriveLetter, Type, Size ``` ```powershell Get-Partition | Get-Volume | Select-Object ` DriveLetter, FileSystemLabel, FileSystem, Size, SizeRemaining ``` Von Speicherverwaltungsanbietern gemeldete physische Datenträger: ```powershell 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: ```powershell $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: ```powershell 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** ```cmd vssadmin list shadowstorage ``` ```cmd 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** ```cmd 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** ```cmd fsutil quota query C: ``` **File Server Resource Manager** ```powershell 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** ```powershell 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** ```bash 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: ```bash df -hT /var/lib/app ``` Exakte Blockwerte: ```bash 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** ```bash df -i ``` Bestimmten Pfad prüfen: ```bash 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** ```bash findmnt ``` Gezielte Ausgabe: ```bash findmnt \ -o TARGET,SOURCE,FSTYPE,OPTIONS ``` Bestimmten Pfad zuordnen: ```bash findmnt \ --target /var/lib/app ``` Blockgeräte: ```bash 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: ```bash du \ -x \ -h \ --max-depth=1 \ /var | sort -h ``` Zusammenfassung eines bestimmten Pfades: ```bash du \ -x \ -s \ -h \ /var/lib/app ``` Größte Dateien mit GNU `find`: ```bash 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: ```bash du -h /pfad/datei ``` ```bash 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** ```bash 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** ```bash journalctl --disk-usage ``` Journaldateien und Protokollverzeichnisse: ```bash du \ -x \ -h \ --max-depth=1 \ /var/log | sort -h ``` Logrotate-Konfiguration im Debugmodus prüfen: ```bash 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** ```bash quota -s ``` Quotaübersicht vorhandener quota-fähiger Dateisysteme: ```bash sudo repquota -a ``` XFS-Quotaauswertung: ```bash 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** ```bash sudo pvs ``` ```bash sudo vgs ``` ```bash 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: ```text 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** ```bash sudo btrfs filesystem usage -T /mountpoint ``` ```bash 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** ```bash zpool list ``` ```bash zfs list -o space ``` Snapshots: ```bash 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** ```bash df -h ``` Bestimmten Pfad prüfen: ```bash df -h /System/Volumes/Data ``` Datenträger und Partitionen: ```bash diskutil list ``` Informationen zum Startvolume: ```bash diskutil info / ``` APFS-Struktur: ```bash diskutil apfs list ``` APFS-Snapshots: ```bash diskutil apfs listSnapshots / ``` Lokale Time-Machine-Snapshots: ```bash tmutil listlocalsnapshots / ``` Große Verzeichnisse unterhalb des Datenvolumes: **LESEND, LASTERZEUGEND** ```bash sudo du \ -x \ -h \ -d 1 \ /System/Volumes/Data \ 2>/dev/null | sort -h ``` Gelöschte, noch geöffnete Dateien: ```bash 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** ```bash docker info \ --format '{{.DockerRootDir}}' ``` Docker-Speicherübersicht: ```bash docker system df ``` Detaillierte Übersicht: ```bash docker system df -v ``` Containergrößen: ```bash docker ps \ -a \ --size ``` Volumes: ```bash docker volume ls ``` Logpfade der Container: ```bash docker ps -aq | xargs -r docker inspect \ --format '{{.Name}} {{.LogPath}}' ``` Mounts eines bestimmten Containers: ```bash 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: ```text 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** ```bash kubectl get nodes ``` Bestimmten Node untersuchen: ```bash kubectl describe node ``` Zu prüfen sind insbesondere: ```text DiskPressure NodeHasDiskPressure ephemeral-storage imagefs.available imagefs.inodesFree nodefs.available nodefs.inodesFree ``` Ereignisse: ```bash kubectl get events \ --all-namespaces \ --sort-by=.metadata.creationTimestamp ``` Betroffenen Pod untersuchen: ```bash kubectl describe pod \ \ -n ``` Persistente Volumes: ```bash 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** ```bash findmnt \ -o TARGET,SOURCE,FSTYPE,OPTIONS ``` Aktuelle Kernelmeldungen: ```bash sudo dmesg \ --ctime | grep -Ei \ 'error|i/o|filesystem|read-only|corrupt|nvme|ata|scsi|ext4|xfs|btrfs' ``` Systemprotokolle: ```bash journalctl \ -k \ --since "-2 hours" ``` Falls `smartctl` installiert und für das Gerät geeignet ist: ```bash sudo smartctl \ -a \ /dev/ ``` macOS-Verifikation: ```bash 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: ```text 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** ```bash 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** ```cmd 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: ```bash docker system df -v ``` ```bash docker ps -a ``` ```bash docker image ls ``` ```bash 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** ```text rm -rf auf unbekannten Verzeichnissen Löschen unter /var/lib/docker docker system prune -a --volumes Löschen aktiver Datenbankdateien Löschen von WAL- oder Transaktionslogs Löschen aller Snapshots vssadmin delete shadows unkontrolliertes Verkleinern des VSS-Speichers manuelles Löschen aus WinSxS Leeren produktiver Protokolle ohne Sicherung fsck auf einem schreibend eingebundenen Dateisystem Ändern reservierter ext4-Blöcke ohne Kapazitätsplanung Vergrößern einer Partition ohne Backup und Ebenenprüfung Entfernen von Kubernetes-PVCs Löschen unbekannter Container-Volumes Deaktivieren von Quotas ohne Ursachenanalyse Neustart des gesamten Hosts als erste Maßnahme ``` Eine Datei mit der Endung `.log`, `.tmp`, `.bak` oder `.old` ist nicht automatisch entbehrlich. --- **7.13.34 Vollständiger Diagnoseablauf** 1. **Fehlermeldung vollständig aufnehmen** Wortlaut, Anwendung, Benutzer und Zeitpunkt dokumentieren. 2. **Betroffenen Pfad bestimmen** Exakten Datei-, Volume-, Mount- oder Containerpfad erfassen. 3. **Auswirkung bestimmen** Einzelne Anwendung, Benutzer, Host oder Standort unterscheiden. 4. **Schreibtest nicht unkontrolliert wiederholen** Zusätzliche Schreibvorgänge können die Lage verschärfen. 5. **Speicherebene bestimmen** Anwendung, Container, Dateisystem, Volume, Pool und Backend zuordnen. 6. **Gesamtkapazität und freien Speicher erfassen** Werte in Prozent und absoluten Größen dokumentieren. 7. **Inodes prüfen** Besonders bei vielen kleinen Dateien. 8. **Quotas prüfen** Benutzer-, Gruppen-, Projekt-, Verzeichnis- und Anwendungsquotas unterscheiden. 9. **Schreibschutz prüfen** Read-only-Mount oder Dateisystemfehler ausschließen. 10. **Speicherpool prüfen** RAID, LVM, Thin Pool, Storage Spaces, NAS oder SAN berücksichtigen. 11. **Snapshots prüfen** VSS, APFS, Btrfs, ZFS, Hypervisor und Storage-Snapshots erfassen. 12. **Wachstumsrate bestimmen** Aktuelle Werte mit Monitoring oder früheren Messungen vergleichen. 13. **Große Verzeichnisse eingrenzen** Suche auf das betroffene Dateisystem beschränken. 14. **Große Dateien bestimmen** Besitzer, Zweck und Änderungszeit dokumentieren. 15. **Viele kleine Dateien berücksichtigen** Inodeverbrauch und Dateianzahl untersuchen. 16. **Gelöschte offene Dateien prüfen** Besonders nach manueller Loglöschung. 17. **Protokolle und Rotation prüfen** Fehlerschleifen, Debugmodus und Retention untersuchen. 18. **Datenbanken prüfen** Daten-, Transaktions-, WAL- und Temp-Bereiche unterscheiden. 19. **Backupdaten prüfen** Retention, abgebrochene Jobs und doppelte Sicherungen untersuchen. 20. **Containerdaten prüfen** Images, Layer, Volumes, Bind-Mounts und Logs unterscheiden. 21. **Kubernetes-Ephemeralspeicher prüfen** Nodefs, Imagefs, Inodes, Limits und Evictions auswerten. 22. **Betriebssystembereiche prüfen** Updates, Dumps, Cache, temporäre Dateien und Papierkorb untersuchen. 23. **Hardware- und I/O-Fehler prüfen** Ereignisse, Kernelmeldungen und Storagezustand korrelieren. 24. **Hypothese und Gegenbeweis formulieren** Ursache vor jeder Änderung messbar beschreiben. 25. **Akutes Wachstum kontrollieren** Verursachenden Schreibprozess nur mit Freigabe drosseln oder stoppen. 26. **Minimale sichere Entlastung planen** Nur bestätigte, entbehrliche Daten auswählen. 27. **Eine Maßnahme durchführen** Nicht mehrere Variablen gleichzeitig verändern. 28. **Freien Speicher erneut messen** Absoluten Wert und Prozentwert dokumentieren. 29. **Ursprünglichen Schreibvorgang testen** Anwendung und nicht nur Diagnosewerkzeug prüfen. 30. **Weitere Ebenen verifizieren** Pool, Volume, Dateisystem und Anwendung erneut kontrollieren. 31. **Wachstum weiter beobachten** Prüfen, ob der Speicher sofort wieder abnimmt. 32. **Dauerhafte Ursache beheben** Rotation, Retention, Quota, Kapazität oder Anwendung korrigieren. 33. **Monitoring verbessern** Prozentwert, freien Absolutwert, Inodes und Wachstumsrate überwachen. 34. **Vorgang dokumentieren** Ursache, Maßnahme, Risiko, Ergebnis und Prävention festhalten. --- **7.13.35 Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | `df` zeigt 100 %, `du` ebenfalls sehr hoch | sichtbare Dateien belegen das Dateisystem | größte Verzeichnisse bestimmen | | `df` zeigt 100 %, `du` deutlich weniger | offene gelöschte Dateien, Snapshots oder Metadaten | `lsof +L1` und Snapshotprüfung | | Blöcke frei, Inodes 100 % | zu viele Dateien | Verzeichnisse mit vielen kleinen Dateien bestimmen | | nur ein Benutzer betroffen | Benutzerquota | Quota des Benutzers prüfen | | nur ein Verzeichnis betroffen | FSRM-, Projekt- oder Anwendungsquota | wirksames Verzeichnislimit prüfen | | Dateisystem ist `read-only` | Dateisystem- oder Storagefehler | Kernel- und Ereignisprotokolle | | Root-Dateisystem voll | Logs, Cache, Container oder fehlender Mount | `/var`, `/tmp`, Docker und Mounts prüfen | | nach Loglöschung keine Freigabe | Datei wird noch geöffnet gehalten | `lsof +L1` | | Dockerhost voll | Images, Layer, Volumes oder Logs | `docker system df -v` | | Container meldet voll, Host nicht | Container-Layer, Volume oder Quota | Mounts und beschreibbaren Layer prüfen | | Kubernetes-Node zeigt `DiskPressure` | Nodefs, Imagefs oder Inodes knapp | Nodebeschreibung und Ereignisse | | PVC vorhanden, Anwendung meldet voll | Dateisystem innerhalb des PVC oder Storagequota | Volume im Pod und Backend prüfen | | Logical Volume hat Platz, Thin Pool ist voll | Thin Provisioning erschöpft | `lvs` mit Daten- und Metadatenprozent | | Dateien wurden gelöscht, Snapshotgröße steigt | Copy-on-Write hält alte Blöcke | Snapshotbelegung prüfen | | Windows-Volume voll, Verzeichnissumme kleiner | VSS, Systemdateien oder unzugängliche Bereiche | VSS und Systembereiche prüfen | | macOS zeigt widersprüchliche Werte | APFS-Container, Snapshots oder löschbarer Speicher | APFS-Container und Snapshots prüfen | | NAS-Freigabe voll, NAS-Pool hat Platz | Share-, Benutzer- oder Volumequota | Backendquota prüfen | | Speicher wächst sehr schnell | Fehlerschleife oder unkontrollierter Job | Änderungszeit und aktive Prozesse | | nach Bereinigung sofort wieder voll | Ursache weiterhin aktiv | Wachstumsquelle erneut messen | | I/O-Fehler zusätzlich zu wenig Speicher | Hardware- oder Pfadfehler | Storagezustand und Ereignisse | --- **7.13.36 Typische Diagnosefehler** - 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: ```text 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** ```text 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](https://learn.microsoft.com/en-us/powershell/module/storage/get-volume) - [Microsoft Learn – Get-Disk](https://learn.microsoft.com/en-us/powershell/module/storage/get-disk) - [Microsoft Learn – Get-PhysicalDisk](https://learn.microsoft.com/en-us/powershell/module/storage/get-physicaldisk) - [Microsoft Learn – Get-PSDrive](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-psdrive) - [Microsoft Learn – Get-FsrmQuota](https://learn.microsoft.com/en-us/powershell/module/fileserverresourcemanager/get-fsrmquota) - [Microsoft Learn – FileServerResourceManager PowerShell module](https://learn.microsoft.com/en-us/powershell/module/fileserverresourcemanager/) - [Microsoft Learn – Vssadmin list shadowstorage](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc788045%28v%3Dws.11%29) - [Microsoft Learn – Determine the actual size of the WinSxS folder](https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/determine-the-actual-size-of-the-winsxs-folder) - [Microsoft Learn – Clean up the WinSxS folder](https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/clean-up-the-winsxs-folder) - [Microsoft Learn – Configure Storage Sense](https://learn.microsoft.com/en-us/windows/configuration/storage/storage-sense) **Offizielle Linux- und Projektdokumentation** - [GNU Coreutils – df invocation](https://www.gnu.org/software/coreutils/manual/html_node/df-invocation.html) - [GNU Coreutils – du invocation](https://www.gnu.org/software/coreutils/manual/html_node/du-invocation.html) - [systemd – journalctl](https://www.freedesktop.org/software/systemd/man/journalctl.html) - [systemd – journald.conf](https://www.freedesktop.org/software/systemd/man/journald.conf.html) - [Linux Kernel – ext4 documentation](https://docs.kernel.org/admin-guide/ext4.html) - [Red Hat – Disk Quotas](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-disk-quotas) - [Red Hat – Limiting XFS storage usage with quotas](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/managing_file_systems/assembly_limiting-storage-space-usage-on-xfs-with-quotas_managing-file-systems) - [Btrfs – btrfs-filesystem documentation](https://btrfs.readthedocs.io/en/latest/btrfs-filesystem.html) - [OpenZFS – zfs-list documentation](https://openzfs.github.io/openzfs-docs/man/master/8/zfs-list.8.html) **Offizielle Docker-Dokumentation** - [Docker Docs – docker system df](https://docs.docker.com/reference/cli/docker/system/df/) - [Docker Docs – Prune unused Docker objects](https://docs.docker.com/engine/manage-resources/pruning/) - [Docker Docs – docker system prune](https://docs.docker.com/reference/cli/docker/system/prune/) - [Docker Docs – docker volume prune](https://docs.docker.com/reference/cli/docker/volume/prune/) **Offizielle Kubernetes-Dokumentation** - [Kubernetes – Local ephemeral storage](https://kubernetes.io/docs/concepts/storage/ephemeral-storage/) - [Kubernetes – Node-pressure eviction](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/) - [Kubernetes – Ephemeral volumes](https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/) **Offizielle Apple-Dokumentation** - [Apple – Get detailed information about a disk](https://support.apple.com/guide/disk-utility/get-detailed-information-about-a-disk-dskutl1005/mac) - [Apple – Add, delete or erase APFS volumes](https://support.apple.com/guide/disk-utility/add-delete-or-erase-apfs-volumes-dskua9e6a110/mac) - [Apple – View APFS snapshots](https://support.apple.com/guide/disk-utility/view-apfs-snapshots-dskuf82354dc/mac) - [Apple – Repair a storage device](https://support.apple.com/guide/disk-utility/repair-a-storage-device-dskutl1040/mac) 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** ```text 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: ```text 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: ```text 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** ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Type A ``` ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Type AAAA ``` **Linux und macOS** ```bash dig app.example.test A ``` ```bash 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** ```bash curl \ -4 \ -v \ https://app.example.test/ ``` ```bash 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** ```powershell Test-NetConnection ` -ComputerName "app.example.test" ` -Port 443 ``` Wichtige Felder: ```text RemoteAddress RemotePort InterfaceAlias SourceAddress TcpTestSucceeded ``` **Linux und macOS** ```bash 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: ```text Not Before Not After ``` Eine falsche Systemzeit kann ein gültiges Zertifikat als abgelaufen oder noch nicht gültig erscheinen lassen. **Windows** ```powershell Get-Date ``` ```cmd w32tm /query /status ``` ```cmd w32tm /query /source ``` **Linux** ```bash date ``` ```bash date -u ``` ```bash timedatectl status ``` **macOS** ```bash date ``` ```bash date -u ``` ```bash 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** ```bash 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: ```bash 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** ```bash 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: ```bash 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** ```bash 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: ```bash docker inspect \ ``` Proxyvariablen: ```bash docker exec \ \ env ``` Zeit im Container: ```bash docker exec \ \ date -u ``` Falls `curl` im Image vorhanden ist: ```bash docker exec \ \ curl \ -v \ https://app.example.test/ ``` Vergleich: ```text 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** ```bash 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** ```bash 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** ```bash sudo nginx -t ``` Dienststatus: ```bash systemctl \ status nginx \ --no-pager ``` Protokolle: ```bash 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** ```bash sudo apachectl configtest ``` Alternativ, abhängig von der Installation: ```bash sudo httpd -t ``` Dienststatus: ```bash systemctl \ status apache2 \ --no-pager ``` oder: ```bash 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: ```powershell Import-Module WebAdministration ``` HTTPS-Bindungen: ```powershell Get-WebBinding ` -Protocol https ``` SSL-Bindungen: ```powershell 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: ```text Client → TLS zum Load Balancer → TLS zum Reverse Proxy → TLS zum Backend ``` Oder: ```text 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: ```bash 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: ```text 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** ```text Zertifikatsprüfung dauerhaft deaktivieren curl -k in produktive Skripte übernehmen verify=false in Anwendungen eintragen NODE_TLS_REJECT_UNAUTHORIZED=0 setzen Java-Hostnameprüfung deaktivieren beliebige Root-CA importieren selbst signiertes Zertifikat ungeprüft vertrauen private Schlüssel weitergeben private Schlüssel in Containerimages einbauen alte TLS-Versionen pauschal aktivieren unsichere Cipher dauerhaft aktivieren Sperrprüfung ohne Risikoanalyse abschalten Truststore vollständig ersetzen alle Zertifikate aus Stores löschen Schannel-Registrywerte nach ungeprüfter Anleitung ändern Reverse Proxy ohne Konfigurationstest neu starten Zertifikat nur auf einem Load-Balancer-Node austauschen TLS-Inspection heimlich umgehen ``` Eine funktionierende Verbindung ohne Zertifikatsprüfung ist kein Nachweis einer sicheren oder korrekten Lösung. --- **7.14.46 Vollständiger Diagnoseablauf** 1. **Exakte Fehlermeldung aufnehmen** Wortlaut, Anwendung, Client und Uhrzeit dokumentieren. 2. **Vollständige URL bestimmen** Schema, FQDN, Port und Pfad erfassen. 3. **Fehlerumfang bestimmen** Einzelnen Client, Anwendung, Standort oder alle Benutzer unterscheiden. 4. **Letzte Änderungen erfassen** Zertifikatswechsel, Update, Proxy-, DNS- oder Firewalländerung prüfen. 5. **Systemzeit prüfen** Datum, UTC, Zeitzone und Synchronisation bestätigen. 6. **DNS-Auflösung prüfen** A, AAAA und CNAME auswerten. 7. **Tatsächliche Zieladresse bestimmen** IPv4, IPv6, Load Balancer oder Proxy identifizieren. 8. **TCP-Port prüfen** Timeout, Ablehnung und erfolgreichen Handshake unterscheiden. 9. **Proxyweg bestimmen** Direktverbindung, expliziten Proxy, PAC oder TLS-Inspection unterscheiden. 10. **Normalen HTTPS-Test durchführen** Zertifikatsprüfung nicht deaktivieren. 11. **TLS und HTTP trennen** Handshakefehler und HTTP-Statuscode unterscheiden. 12. **OpenSSL-Handshake durchführen** SNI und Hostnamenprüfung ausdrücklich angeben. 13. **TLS-Version dokumentieren** Ausgehandelte Version erfassen. 14. **Cipher dokumentieren** Ausgehandelte Cipher Suite erfassen. 15. **ALPN dokumentieren** HTTP/1.1, HTTP/2 oder anderes Protokoll bestimmen. 16. **Serverzertifikat dokumentieren** Subject, Issuer, Seriennummer und Fingerprint erfassen. 17. **SAN prüfen** Aufgerufenen FQDN mit Zertifikat vergleichen. 18. **Gültigkeitszeitraum prüfen** Server- und Intermediate-Zertifikate berücksichtigen. 19. **Zertifikatskette prüfen** Fehlende oder falsche Intermediate-CA bestimmen. 20. **Root-Vertrauen prüfen** Tatsächlichen Truststore der Anwendung untersuchen. 21. **Sperrprüfung prüfen** CRL, OCSP, AIA und Netzwerkzugriff berücksichtigen. 22. **SNI prüfen** Test mit und ohne vorgesehenen Servernamen vergleichen. 23. **Einzelne Zieladressen prüfen** Load-Balancer-Nodes mit `--resolve` vergleichen. 24. **IPv4 und IPv6 vergleichen** Unterschiedliche Pfade und Zertifikate bestimmen. 25. **mTLS prüfen** Clientzertifikat, Schlüssel, Kette und Serververtrauen untersuchen. 26. **TLS-Inspection prüfen** Zertifikatsaussteller und Fingerprint zwischen Netzen vergleichen. 27. **Anwendungsspezifischen Truststore prüfen** Betriebssystem, Browser, Java und Container unterscheiden. 28. **Serverbindung prüfen** Listener, virtuellen Host, Zertifikat und Schlüssel zuordnen. 29. **Zertifikat und Schlüssel vergleichen** Öffentliche Schlüssel sicher hashen. 30. **Reverse Proxy und Backend trennen** Frontend- und Backend-TLS einzeln testen. 31. **Serverprotokolle auswerten** Handshake, Zertifikat, mTLS und Backendfehler korrelieren. 32. **Bei Bedarf Netzwerkaufzeichnung durchführen** Nur autorisiert, begrenzt und datenschutzkonform. 33. **Hypothese und Gegenbeweis formulieren** Ursache vor der Änderung messbar festlegen. 34. **Eine kontrollierte Maßnahme durchführen** Risiko, Rückweg und Freigabe beachten. 35. **Konfiguration vor Reload prüfen** Beispielsweise `nginx -t` oder `apachectl configtest`. 36. **Identischen TLS-Test wiederholen** Version, Cipher, Zertifikat und Verify-Ergebnis vergleichen. 37. **HTTP-Antwort prüfen** Statuscode, Redirect und Header auswerten. 38. **Ursprüngliche Anwendung testen** Nicht nur `curl` oder OpenSSL verifizieren. 39. **Weitere Clients und Netze prüfen** Repräsentative Systeme vergleichen. 40. **Temporäre Diagnoseänderungen zurücknehmen** Logging, Capture, Testzertifikate und Ausnahmen entfernen. 41. **Ursache dokumentieren** Fehlerhafte Ebene und technischer Nachweis festhalten. 42. **Prävention festlegen** Monitoring, automatische Erneuerung und Konfigurationstest verbessern. --- **7.14.47 Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | DNS schlägt fehl | Namensauflösung | direkte A- und AAAA-Abfrage | | TCP-Port `443` nicht erreichbar | Routing, Firewall oder Listener | Netzwerkpfad und Serverseite | | TCP funktioniert, kein ServerHello | TLS-Policy, Proxy oder Server | Handshake und Serverlogs | | `curl -k` funktioniert, normaler Test nicht | Zertifikatsvalidierung | Name, Kette, Zeit und Vertrauen | | Hostname mismatch | falsches Zertifikat oder falscher Name | SAN und SNI prüfen | | Zertifikat abgelaufen | Erneuerung oder falscher Node | alle Zieladressen vergleichen | | Zertifikat noch nicht gültig | Systemzeit oder falsches Zertifikat | Zeit und Gültigkeitsbeginn | | unbekannte CA | Root fehlt oder TLS-Inspection | Issuer und Truststore | | lokale CA im Browser vertraut, Java nicht | separater Java-Truststore | `keytool -list` | | Kette unvollständig | Intermediate fehlt | `-showcerts` und `openssl verify` | | nur ein Client betroffen | lokaler Truststore, Zeit oder Proxy | anderen Client vergleichen | | nur ein Load-Balancer-Node betroffen | Zertifikatsverteilung unvollständig | `curl --resolve` | | ohne SNI falsches Zertifikat | namensbasierter virtueller Host | Test mit korrektem SNI | | mit SNI ebenfalls falsches Zertifikat | falsche Bindung oder Serverregel | Listenerkonfiguration | | TLS 1.2 funktioniert, TLS 1.3 nicht | TLS-1.3-Pfad oder Intermediär | Proxy und Serverpolicy | | TLS 1.3 funktioniert, alter Client nicht | veralteter Client | Clientbibliothek und TLS-Version | | keine gemeinsame Cipher | Policy- oder Algorithmuskonflikt | Client- und Serverlisten vergleichen | | Browser funktioniert, Dienst nicht | Proxy, Store oder Systemkonto | Dienstkontext prüfen | | Host funktioniert, Container nicht | CA-Bundle, Proxy oder DNS | Test im Container | | Frontend-TLS funktioniert, HTTP 502 | Backend nicht erreichbar oder Backend-TLS | Proxy- und Backendlogs | | HTTP 504 | Backendtimeout | Backendpfad und Antwortzeit | | Clientzertifikat erforderlich | mTLS | Zertifikat und Schlüssel prüfen | | `unknown ca` am Server bei mTLS | Server vertraut Client-CA nicht | Server-Truststore | | nur hinter Security-Proxy fehlerhaft | TLS-Inspection | Zertifikatsaussteller vergleichen | | OCSP- oder CRL-Fehler | Sperrprüfungsziel nicht erreichbar | AIA/CDP und Proxy prüfen | | neuer Fingerprint nur auf manchen Nodes | unsynchronisierte Zertifikate | alle Nodes einzeln prüfen | | HTTP 200, Anwendung fehlerhaft | oberhalb von TLS | Anwendung, Authentifizierung und Inhalt | --- **7.14.48 Typische Diagnosefehler** - 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: ```text 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** ```text 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](https://learn.microsoft.com/en-us/windows-server/security/tls/what-s-new-in-tls-ssl-schannel-ssp-overview) - [Microsoft Learn – TLS registry settings](https://learn.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings) - [Microsoft Learn – Troubleshooting SSL-related IIS server-certificate issues](https://learn.microsoft.com/en-us/troubleshoot/developer/webapps/iis/www-authentication-authorization/troubleshooting-ssl-related-issues-server-certificate) - [Microsoft Learn – Certificate Provider](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/about/about_certificate_provider) - [Microsoft Learn – Certutil](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil) - [Microsoft Learn – Valid root CA certificates are untrusted](https://learn.microsoft.com/en-us/troubleshoot/windows-server/certificates-and-public-key-infrastructure-pki/valid-root-ca-certificates-untrusted) - [Microsoft Learn – Diagnostic logging for PKI and SSL certificate issues](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/diagnostic-logging-troubleshoot-workplace-join-issues) **Offizielle OpenSSL-Dokumentation** - [OpenSSL – s_client](https://docs.openssl.org/3.5/man1/openssl-s_client/) - [OpenSSL – x509](https://docs.openssl.org/3.5/man1/openssl-x509/) - [OpenSSL – verify](https://docs.openssl.org/3.5/man1/openssl-verify/) - [OpenSSL – Certificate verification options](https://docs.openssl.org/3.5/man1/openssl-verification-options/) - [OpenSSL – Command overview](https://docs.openssl.org/3.5/man1/) **Offizielle curl-Dokumentation** - [curl – Command-line manual](https://curl.se/docs/manpage.html) - [curl – TLS certificate verification](https://curl.se/docs/sslcerts.html) - [curl – SSL ciphers](https://curl.se/docs/ssl-ciphers.html) - [curl – Tutorial](https://curl.se/docs/tutorial.html) - [curl – HTTP scripting](https://curl.se/docs/httpscripting.html) **Offizielle Webserver-Dokumentation** - [Nginx – Configuring HTTPS servers](https://nginx.org/en/docs/http/configuring_https_servers.html) - [Nginx – HTTP SSL module](https://nginx.org/en/docs/http/ngx_http_ssl_module.html) - [Nginx – HTTP proxy module](https://nginx.org/en/docs/http/ngx_http_proxy_module.html) - [Apache HTTP Server – Configuration files and configtest](https://httpd.apache.org/docs/2.4/configuring.html) - [Apache HTTP Server – apachectl](https://httpd.apache.org/docs/current/programs/apachectl.html) **Offizielle Java-Dokumentation** - [Oracle – keytool](https://docs.oracle.com/en/java/javase/21/docs/specs/man/keytool.html) - [Oracle – JSSE Reference Guide](https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html) **Offizielle Wireshark-Dokumentation** - [Wireshark – User’s Guide](https://www.wireshark.org/docs/wsug_html/) - [Wireshark – TShark manual](https://www.wireshark.org/docs/man-pages/tshark.html) - [Wireshark – Exporting TLS session keys](https://www.wireshark.org/docs/wsug_html_chunked/ChIOExportSection.html) **Standards** - [RFC 5280 – Internet X.509 Public Key Infrastructure Certificate and CRL Profile](https://www.rfc-editor.org/rfc/rfc5280) - [RFC 6066 – TLS Extensions: Server Name Indication](https://www.rfc-editor.org/rfc/rfc6066) - [RFC 7301 – TLS Application-Layer Protocol Negotiation](https://www.rfc-editor.org/rfc/rfc7301) - [RFC 8446 – TLS 1.3](https://www.rfc-editor.org/rfc/rfc8446) - [RFC 9110 – HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110) - [RFC 9113 – HTTP/2](https://www.rfc-editor.org/rfc/rfc9113) - [RFC 9325 – Recommendations for Secure Use of TLS and DTLS](https://www.rfc-editor.org/rfc/rfc9325) - [RFC 9525 – Service Identity in TLS](https://www.rfc-editor.org/rfc/rfc9525) 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: ```text 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** ```text Backup failed Job failed Partial success Completed with warnings Missed schedule Access denied Authentication failed Permission denied Repository unavailable Repository is full Quota exceeded No space left on device Snapshot creation failed VSS writer failed VSS_E_WRITERERROR Unable to create snapshot Volume not found Source path not found Connection timed out Connection reset TLS certificate verify failed Repository locked Stale lock Checksum mismatch Hash mismatch Corrupt backup Index damaged Catalog update failed Retention failed Prune failed Unable to decrypt Encryption key not found Object lock prevents deletion Backup window exceeded Incremental chain is broken Recovery point unavailable Restore validation failed ``` Die exakte Meldung einschließlich Fehlercode, Jobphase und Uhrzeit muss übernommen werden. --- **7.15.8 Sofortmaßnahmen** 1. Fehlermeldung vollständig dokumentieren. 2. Job-ID, Jobname und Sicherungsprodukt erfassen. 3. Start- und Endzeit bestimmen. 4. Letzten erfolgreichen Recovery Point feststellen. 5. Betroffene Quellen und Ziele bestimmen. 6. RPO-Verletzung berechnen. 7. Aktuelle Logs und Ereignisse sichern. 8. Snapshot- oder VSS-Zustand prüfen. 9. Repository nicht bereinigen oder entsperren. 10. Prüfen, ob noch ein Job aktiv ist. 11. Kapazität und Quota erfassen. 12. Bei Sicherheitsverdacht Backupserver und Repository schützen. 13. Ursache nachweisen, bevor der Job erneut gestartet wird. 14. Nach der Korrektur einen kontrollierten neuen Lauf durchführen. 15. Wiederherstellbarkeit des neuen Recovery Points testen. Wiederholte Neustarts eines Backupjobs können: - 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: ```text 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** ```powershell Get-ScheduledTask ` -TaskName "" ``` Laufzeitinformationen: ```powershell Get-ScheduledTask ` -TaskName "" | Get-ScheduledTaskInfo ``` Wichtige Felder: ```text State LastRunTime LastTaskResult NextRunTime NumberOfMissedRuns ``` Detaillierte Abfrage mit `schtasks`: ```cmd 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: ```powershell 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** ```bash systemctl list-timers --all ``` Bestimmten Timer prüfen: ```bash systemctl \ status backup.timer \ --no-pager ``` Zugehörigen Dienst prüfen: ```bash systemctl \ status backup.service \ --no-pager ``` Letzten Exit-Code erfassen: ```bash systemctl show \ backup.service \ -p Result \ -p ExecMainCode \ -p ExecMainStatus \ -p ActiveEnterTimestamp \ -p ActiveExitTimestamp ``` Protokolle: ```bash 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: ```bash crontab -l ``` Cronjobs von `root`: ```bash sudo crontab -l ``` Systemweite Konfigurationen können abhängig von der Distribution unter anderem liegen in: ```text /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: ```bash findmnt ``` ```bash lsblk \ -o NAME,TYPE,FSTYPE,SIZE,FSAVAIL,FSUSE%,MOUNTPOINTS ``` Windows-Volumes: ```powershell Get-Volume ``` Datei- oder Verzeichnisexistenz: ```powershell 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** ```powershell Get-Volume | Select-Object ` DriveLetter, FileSystemLabel, FileSystem, Size, SizeRemaining, HealthStatus ``` **Linux** ```bash df -hT ``` ```bash df -i ``` **macOS** ```bash 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** ```cmd wbadmin get status ``` Vorhandene Backupversionen: ```cmd wbadmin get versions ``` Verfügbare Datenträger: ```cmd wbadmin get disks ``` Vorhandene Windows-Server-Backup-Dienste: ```powershell Get-Service ` -Name wbengine,VSS,swprv ` -ErrorAction SilentlyContinue ``` Backup- und VSS-Ereignisse: ```powershell 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** ```cmd vssadmin list writers ``` VSS-Provider: ```cmd vssadmin list providers ``` Shadow-Copy-Speicher: ```cmd vssadmin list shadowstorage ``` Vorhandene Shadow Copies: ```cmd vssadmin list shadows ``` Ein gesunder Writer zeigt gewöhnlich: ```text 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** ```powershell Resolve-DnsName ` -Name "" ``` ```powershell Test-NetConnection ` -ComputerName "" ` -Port ``` SMB-Verbindungen: ```powershell Get-SmbConnection ``` **Linux und macOS** ```bash getent hosts ``` ```bash findmnt ``` HTTPS-Endpunkt: ```bash curl \ -v \ https:/// ``` TLS-Test: ```bash 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: ```bash rsync --version ``` Trockenlauf: **LESEND, NETZAKTIV, möglicherweise LASTERZEUGEND** ```bash rsync \ --dry-run \ --itemize-changes \ \ ``` Unmittelbar nach dem Job den Exit-Code ausgeben: ```bash 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** ```bash tmutil status ``` Konfigurierte Ziele: ```bash tmutil destinationinfo ``` Letztes Backup: ```bash tmutil latestbackup ``` Vorhandene Backups: ```bash tmutil listbackups ``` Aktuelle Time-Machine-Protokolle: ```bash log show \ --predicate 'process == "backupd"' \ --last 6h \ --style compact ``` Speicherzustand: ```bash df -h ``` Backupvolume: ```bash 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: ```bash docker ps -a ``` Volumes: ```bash docker volume ls ``` Bestimmtes Volume: ```bash docker volume inspect \ ``` Containermounts: ```bash 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: ```bash kubectl get cronjobs \ --all-namespaces ``` Jobs: ```bash kubectl get jobs \ --all-namespaces ``` Bestimmten Job untersuchen: ```bash kubectl describe job \ \ -n ``` Podlogs: ```bash kubectl logs \ job/ \ -n ``` Ereignisse: ```bash kubectl get events \ --all-namespaces \ --sort-by=.metadata.creationTimestamp ``` PVCs: ```bash kubectl get pvc \ --all-namespaces ``` VolumeSnapshots: ```bash kubectl get volumesnapshot \ --all-namespaces ``` VolumeSnapshotContents: ```bash 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** ```bash 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: 1. Incident-Response-Prozess aktivieren. 2. Beweise sichern. 3. Repository vor weiteren Veränderungen schützen. 4. Immutability und Offlinekopien prüfen. 5. Backupzugangsdaten als möglicherweise kompromittiert behandeln. 6. Keine normalen Retention- oder Pruningvorgänge starten. 7. Wiederherstellungspunkt vor dem vermuteten Vorfall bestimmen. 8. Restore ausschließlich in isolierter Umgebung testen. 9. Produktivwiederherstellung erst nach Freigabe durchführen. --- **7.15.36 Hypothese und Gegenbeweis formulieren** Beispiel: ```text 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** ```text Recovery Points manuell aus dem Repository löschen Repositoryverzeichnisse umbenennen Repositorylock ungeprüft entfernen Retention pauschal verkürzen Immutability deaktivieren Object Lock umgehen Pruning während eines aktiven Backups starten alle Snapshots löschen VSS-Dienste vor der Beweissicherung neu starten Datenbankdateien im laufenden Betrieb kopieren inkrementelle Kettenglieder einzeln löschen Backupkatalog ohne Herstellervorgabe neu erstellen Repositorydaten manuell verändern Verschlüsselungsschlüssel ersetzen verlorenes Repositorykennwort „zurücksetzen“ Backupziel neu formatieren Docker-Volume ungeprüft als einfache Dateikopie sichern Kubernetes-PVC löschen und neu erstellen Restore direkt über Produktivdaten ausführen beschädigtes Backup als einzigen Recovery Point behalten ``` --- **7.15.39 Vollständiger Diagnoseablauf** 1. **Fehlermeldung vollständig aufnehmen** Wortlaut, Fehlercode, Job-ID und Zeitpunkt dokumentieren. 2. **Job und Sicherungsprodukt bestimmen** Plan, Richtlinie, Agent und Server erfassen. 3. **Auswirkung bestimmen** Einzelne Quelle, Jobgruppe, Repository oder gesamte Umgebung unterscheiden. 4. **Letzten erfolgreichen Recovery Point bestimmen** Nicht nur letzten erfolgreichen Prozesslauf prüfen. 5. **RPO-Verletzung berechnen** Aktuelle Schutzlücke mit Sollwert vergleichen. 6. **Jobphase bestimmen** Planung, Snapshot, Lesen, Transport, Schreiben oder Abschluss unterscheiden. 7. **Scheduler prüfen** Trigger, Konto, letzte Ausführung und Exit-Code erfassen. 8. **Backupdienste und Agenten prüfen** Status und Version dokumentieren. 9. **Logs sichern** Job-, Betriebssystem-, Anwendungs- und Repositorylogs korrelieren. 10. **Quelle vollständig bestimmen** Pfade, Volumes, VMs, Container und Datenbanken erfassen. 11. **Ausschlüsse prüfen** Neue oder versehentlich ausgeschlossene Daten erkennen. 12. **Quellberechtigungen prüfen** Tatsächlichen Dienstkontext verwenden. 13. **Quellkapazität prüfen** Freien Speicher, Inodes und Temp-Bereich untersuchen. 14. **Snapshotzustand prüfen** VSS, Hypervisor, CSI oder Storage-Snapshot unterscheiden. 15. **Anwendungskonsistenz prüfen** Writer, Hook oder Datenbankverfahren auswerten. 16. **Ziel und Repository bestimmen** Host, Pfad, Port, Protokoll und Backend erfassen. 17. **Netzwerkpfad prüfen** DNS, Routing, Firewall, VPN, Proxy und TLS untersuchen. 18. **Zielberechtigungen prüfen** Schreiben, Lesen, Listen und gegebenenfalls Löschen unterscheiden. 19. **Repositorykapazität prüfen** Speicher, Quota, Thin Pool, Katalog und Cache berücksichtigen. 20. **Repositorylock prüfen** Aktive und verwaiste Locks unterscheiden. 21. **Parallele Jobs prüfen** Backup, Restore, Replication, Retention und Pruning erfassen. 22. **Sicherungskette prüfen** Vollbackup und erforderliche Folgebackups zuordnen. 23. **Retention und Immutability prüfen** Aufbewahrung, Object Lock und Legal Hold berücksichtigen. 24. **Verschlüsselung prüfen** Schlüssel, Kennwort, KMS und Zertifikate erfassen. 25. **Integrität prüfen** Herstellervorgesehene Repositoryprüfung verwenden. 26. **Performance prüfen** Dauer, Durchsatz, Latenz, Last und Backupfenster vergleichen. 27. **Sicherheitsverdacht bewerten** Manipulation, ungewöhnliche Änderungen und fehlende Recovery Points prüfen. 28. **Hypothese und Gegenbeweis formulieren** Ursache vor der Änderung messbar festlegen. 29. **Eine kontrollierte Maßnahme durchführen** Risiko, Rückweg und Freigabe beachten. 30. **Job kontrolliert neu starten** Doppelstarts und parallele Wartung ausschließen. 31. **Jobphasen überwachen** Snapshot, Übertragung und Abschluss beobachten. 32. **Exit-Code und Warnungen auswerten** Teilerfolg nicht als Vollerfolg behandeln. 33. **Neuen Recovery Point bestätigen** Zeit, Umfang und Repository registrieren. 34. **Integritätsprüfung durchführen** Katalog und Datenblöcke prüfen. 35. **Isolierten Restore-Test durchführen** Repräsentative Daten oder Anwendung wiederherstellen. 36. **Wiederhergestellte Daten validieren** Inhalt, Metadaten, Rechte und Anwendung prüfen. 37. **RPO und RTO bewerten** Tatsächliche Werte dokumentieren. 38. **Sekundärkopie prüfen** Offsite-, Offline- oder immutable Kopie bestätigen. 39. **Temporäre Änderungen zurücknehmen** Debuglogging, Testfreigaben und Ausnahmen entfernen. 40. **Ursache dokumentieren** Technischen Nachweis festhalten. 41. **Prävention festlegen** Monitoring, Kapazität, Retention oder Jobdesign verbessern. --- **7.15.40 Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | kein Joblog vorhanden | Scheduler oder Prozessstart fehlerhaft | Scheduler-Ereignisse | | Job startet manuell, geplant aber nicht | Dienstkonto, Umgebung oder Rechte | Ausführungskontext vergleichen | | Task meldet Erfolg, kein Recovery Point | Skript wertet Exit-Code falsch aus | Unterprozess und Repository prüfen | | Quelle fehlt | Mount, Volume oder Pfad nicht verfügbar | Mount- und Volumezustand | | nur neue Verzeichnisse fehlen | Ausschluss oder Berechtigung | Jobumfang und ACLs | | VSS-Writer fehlgeschlagen | Anwendungskonsistenz fehlerhaft | `vssadmin list writers` | | Snapshot erstellt, Job scheitert später | Transport, Repository oder Katalog | nächste Jobphase | | Repository voll | Kapazität, Quota oder Retention | Belegung aller Repositoryebenen | | Repository hat Platz, Cache ist voll | lokaler Stagingbereich erschöpft | Quellhost und Proxy prüfen | | nur geplanter Netzwerkjob scheitert | gemapptes Laufwerk fehlt | UNC-Pfad und Dienstkonto | | Zugriff verweigert | Berechtigung oder geändertes Konto | Quell- und Zielrechte | | Authentifizierung fehlgeschlagen | Kennwort, Token oder Zertifikat | Ablauf und Dienstkontext | | Repository locked | aktiver oder verwaister Prozess | Prozesse und Jobhistorie | | Inkrementbackup fehlt | Kette unterbrochen | Vollbackup und Folgepunkte | | Retention schlägt fehl | Immutability oder fehlendes Löschrecht | Richtlinie und Object Lock | | Pruning läuft sehr lange | Repositorygröße oder Wartungsüberschneidung | Prozess und I/O-Last | | Rsync Exit-Code `23` | teilweise Übertragung | vollständige Fehlerausgabe | | Rsync Exit-Code `24` | Quelldateien verschwanden | aktive Anwendung und Dateityp | | Dockerexport erfolgreich, Daten fehlen | Volume nicht enthalten | Mounts und Volumes | | Kubernetes-Snapshot nicht `readyToUse` | CSI- oder Storagefehler | Snapshotereignisse | | Datenbankbackup vorhanden, Restore scheitert | Inkonsistenz oder fehlende Logs | Datenbankverifikation | | Backup erfolgreich, Replikation fehlgeschlagen | Zweitkopie fehlt | Replikationsjob und Ziel | | Backupdauer plötzlich erhöht | Datenwachstum, Last oder Netzwerk | Baselinevergleich | | viele Dateien wurden neu gesichert | Verschlüsselung, Zeitstempel oder Anwendung | Änderungsursache | | Prüfsummenfehler | Repository- oder Storagebeschädigung | Integritätsprüfung und Hardware | | ältere Recovery Points fehlen unerwartet | Retentionfehler oder Manipulation | Audit- und Repositorylogs | | Restore funktioniert, Anwendung nicht | Abhängigkeiten oder Konsistenz fehlen | vollständiger Anwendungstest | --- **7.15.41 Typische Diagnosefehler** - 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: ```text Produktivdaten → primäres Backuprepository → getrennte Zweitkopie → unveränderbare oder offline Kopie → regelmäßig getestete Wiederherstellung ``` Zu vermeiden ist: ```text 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** ```text 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](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/windows-server-backup-command-reference) - [Microsoft Learn – wbadmin start backup](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wbadmin-start-backup) - [Microsoft Learn – Volume Shadow Copy Service](https://learn.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service) - [Microsoft Learn – Backup fails because of a VSS Writer](https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/backup-fails-vss-writer) - [Microsoft Learn – No VSS writers are listed](https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/no-vss-writers-listed-run-vssadmin-list-writers) - [Microsoft Learn – Get-ScheduledTaskInfo](https://learn.microsoft.com/en-us/powershell/module/scheduledtasks/get-scheduledtaskinfo) - [Microsoft Learn – schtasks](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/schtasks) - [Microsoft Learn – schtasks query](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/schtasks-query) **Offizielle Linux- und Projektdokumentation** - [systemd – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [systemd – systemd.timer](https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html) - [systemd – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [Rsync – Official man page](https://download.samba.org/pub/rsync/rsync.1) - [Restic – Backing up](https://restic.readthedocs.io/en/stable/040_backup.html) - [Restic – Restoring](https://restic.readthedocs.io/en/stable/050_restore.html) - [Restic – Removing backup snapshots](https://restic.readthedocs.io/en/stable/060_forget.html) - [Restic – Working with repositories](https://restic.readthedocs.io/en/stable/045_working_with_repos.html) - [Restic – Troubleshooting](https://restic.readthedocs.io/en/stable/077_troubleshooting.html) **Offizielle Docker-Dokumentation** - [Docker Docs – Volumes](https://docs.docker.com/engine/storage/volumes/) - [Docker Docs – Storage](https://docs.docker.com/engine/storage/) - [Docker Docs – docker container export](https://docs.docker.com/reference/cli/docker/container/export/) - [Docker Docs – Back up and restore Docker Desktop data](https://docs.docker.com/desktop/settings-and-maintenance/backup-and-restore/) **Offizielle Kubernetes-Dokumentation** - [Kubernetes – Volume Snapshots](https://kubernetes.io/docs/concepts/storage/volume-snapshots/) - [Kubernetes – Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) - [Kubernetes – Operating etcd clusters](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/) **Offizielle PostgreSQL-Dokumentation** - [PostgreSQL – Backup and Restore](https://www.postgresql.org/docs/current/backup.html) - [PostgreSQL – pg_basebackup](https://www.postgresql.org/docs/current/app-pgbasebackup.html) - [PostgreSQL – pg_verifybackup](https://www.postgresql.org/docs/current/app-pgverifybackup.html) - [PostgreSQL – Continuous Archiving and Point-in-Time Recovery](https://www.postgresql.org/docs/current/continuous-archiving.html) **Offizielle Apple-Dokumentation** - [Apple – Back up your Mac with Time Machine](https://support.apple.com/en-us/104984) - [Apple – Time Machine troubleshooting](https://support.apple.com/guide/mac-help/time-machine-troubleshooting-mh15653/mac) - [Apple – If a Time Machine backup fails](https://support.apple.com/guide/mac-help/if-a-time-machine-backup-fails-mchlb955003d/mac) - [Apple – Verify your backup disk](https://support.apple.com/guide/mac-help/verify-your-backup-disk-mh26840/mac) - [Apple – Restore items backed up with Time Machine](https://support.apple.com/guide/mac-help/restore-files-mh11422/mac) **Offizielle Sicherheitsempfehlungen** - [BSI – Datensicherungskonzept CON.3](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/03_CON_Konzepte_und_Vorgehensweisen/CON_3_Datensicherungskonzept_Edition_2023.pdf) - [BSI – Top 10 Ransomware-Maßnahmen](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Cyber-Sicherheitslage/Analysen-und-Prognosen/Ransomware-Angriffe/Top-10-Ransomware-Massnahmen/top-10-ransomware-massnahmen.html) - [CISA – StopRansomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide) Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.