# 6. Netzwerk- und Verbindungsfehler # 6.1 Client ohne Netzwerkverbindung – systematische Ende-zu-Ende-Analyse Ein Client meldet „Kein Internet“, erreicht keine internen Systeme oder kann einzelne Netzwerkdienste nicht verwenden. Diese Beschreibung benennt zunächst nur das sichtbare Symptom. Sie beweist weder einen Kabeldefekt noch einen Ausfall des Routers oder Internetzugangs. Die Ursache kann an unterschiedlichen Stellen liegen: - physische Verbindung, - WLAN-Verbindung, - Netzwerkadapter, - VLAN-Zuordnung, - IP-Konfiguration, - DHCP, - ARP beziehungsweise IPv6 Neighbor Discovery, - Standardgateway, - Routing, - DNS, - Firewall, - Proxy, - VPN, - Authentifizierung, - Zielsystem, - Anwendung, - Internetzugang. Die Fehleranalyse muss deshalb vom betroffenen Client schrittweise bis zum Ziel erfolgen. --- **1. Lernziele** Nach dieser Seite kannst du: - eine ungenaue Störungsmeldung in ein prüfbares Fehlerbild übersetzen, - den betroffenen Umfang bestimmen, - physische Verbindung und logische Erreichbarkeit unterscheiden, - IPv4- und IPv6-Konfigurationen bewerten, - DHCP-, Gateway-, Routing- und DNS-Probleme auseinanderhalten, - lokale und entfernte Fehler voneinander abgrenzen, - geeignete Vergleichstests durchführen, - typische Fehlinterpretationen vermeiden, - Maßnahmen kontrolliert ausführen, - Ursache, Lösung und Nachprüfung dokumentieren. --- **2. Ausgangssituation** Ein Benutzer meldet: > „Mein Computer hat kein Netzwerk.“ Diese Aussage lässt entscheidende Fragen offen: - Ist Ethernet oder WLAN betroffen? - Besteht überhaupt eine Verbindung zum lokalen Netzwerk? - Funktioniert nur das Internet nicht? - Sind interne Systeme erreichbar? - Ist nur eine Anwendung betroffen? - Funktionieren Ziele über IP-Adresse, aber nicht über Namen? - Sind weitere Benutzer oder Geräte betroffen? - Trat das Problem plötzlich oder nach einer Änderung auf? - Ist der Fehler dauerhaft oder nur zeitweise vorhanden? - Funktioniert eine andere Netzwerkverbindung? - Ist ein VPN aktiv? - Wird ein Proxy verwendet? - betrifft das Problem IPv4, IPv6 oder beide Protokolle? Vor technischen Eingriffen muss aus der allgemeinen Meldung ein eindeutig prüfbares Symptom entstehen. --- **3. Fehlerbild präzisieren** Geeignete Fragen sind: - Welche konkrete Anwendung funktioniert nicht? - Welche Adresse oder welcher Dienst soll erreicht werden? - Welche Fehlermeldung wird angezeigt? - Seit wann besteht der Fehler? - Funktionierte die Verbindung zuvor? - Was wurde unmittelbar vorher verändert? - Sind interne und externe Ziele gleichermaßen betroffen? - Funktioniert der Zugriff über eine IP-Adresse? - Funktioniert der Zugriff über einen DNS-Namen? - Sind andere Geräte am selben Standort betroffen? - Funktioniert der Client über ein anderes Netzwerk? - Tritt der Fehler mit einem anderen Benutzerkonto ebenfalls auf? - Besteht der Fehler nur bei aktivem VPN? - Ist ein bestimmtes WLAN, Kabel, Dock oder VLAN beteiligt? **Beispiel für ein präzisiertes Fehlerbild** ```text Client: Notebook NB-204 Verbindung: Ethernet über USB-C-Dockingstation Standort: Gebäude B, Raum 204 Beginn: heute nach dem Wechsel des Arbeitsplatzes Lokale Linkanzeige: aktiv IPv4-Adresse: 169.254.37.18/16 Standardgateway: nicht vorhanden Interne und externe Ziele: nicht erreichbar Weitere Clients an derselben Datendose: ebenfalls ohne DHCP-Adresse WLAN-Verbindung des Notebooks: funktioniert ``` Damit ist die Untersuchung wesentlich stärker eingegrenzt als durch die ursprüngliche Aussage „Kein Netzwerk“. --- **4. Zuerst den Umfang bestimmen** | Beobachtung | wahrscheinlicher Untersuchungsbereich | |---|---| | nur eine Anwendung betroffen | Anwendung, Dienst, Port, Proxy, Zertifikat oder Berechtigung | | nur ein Ziel betroffen | Zielsystem, Zielnetz, DNS-Eintrag oder Route | | nur ein Client betroffen | Client, Adapter, Kabel, Port oder lokale Konfiguration | | mehrere Clients an einem Switch betroffen | Switch, Uplink, VLAN, Stromversorgung oder zentrale Dienste | | nur ein VLAN betroffen | VLAN-Konfiguration, Trunk, Gateway, DHCP-Relay oder ACL | | nur WLAN betroffen | Access Point, Authentifizierung, Funkversorgung oder WLAN-Konfiguration | | interne Ziele erreichbar, Internet nicht | Gateway, Firewall, NAT, Proxy oder Provider | | Internet erreichbar, interne Ziele nicht | internes Routing, VPN, DNS, Firewall oder Berechtigung | | IP-Adressen funktionieren, Namen nicht | DNS-Konfiguration oder Namensauflösung | | Namen werden aufgelöst, Verbindung scheitert | Routing, Firewall, Dienst, Port oder Anwendung | | nur ein Standort betroffen | Standortanbindung, lokales Gateway, WAN oder Standort-Firewall | | alle Systeme betroffen | zentrale Netzwerkkomponente, DNS, DHCP, Firewall, WAN oder Stromversorgung | > Der Umfang ist einer der wichtigsten Hinweise auf die Fehlerdomäne. Ein lokaler Eingriff am Client ist nicht sinnvoll, wenn gleichzeitig ein vollständiges VLAN oder ein ganzer Standort betroffen ist. --- **5. Ausgangszustand sichern** Vor Änderungen sollten mindestens dokumentiert werden: - Datum und Uhrzeit, - betroffener Client, - Benutzerkontext, soweit erforderlich, - Standort, - Anschlussart, - Dockingstation oder Adapter, - Switchport, sofern bekannt, - SSID bei WLAN, - IP-Adressen, - Präfix beziehungsweise Subnetzmaske, - Standardgateway, - DNS-Server, - DHCP-Status, - Routingtabelle, - Proxy- und VPN-Status, - genaue Fehlermeldung, - erreichbare und nicht erreichbare Ziele, - bereits ausgeführte Maßnahmen, - letzte bekannte funktionierende Nutzung, - vorausgegangene Änderungen. **Windows** ```powershell Get-Date Get-NetAdapter Get-NetIPConfiguration Get-NetIPAddress Get-NetRoute Get-DnsClientServerAddress ipconfig /all route print ``` **Linux** ```bash date ip link ip address ip route resolvectl status nmcli device status ``` **macOS** ```bash date networksetup -listallhardwareports ifconfig route -n get default scutil --dns ``` Je nach Betriebssystem, Version und Netzwerkkonfiguration können einzelne Befehle oder Ausgaben abweichen. --- **6. Prüfreihenfolge** ```text Fehlerbild präzisieren → Umfang bestimmen → Ausgangszustand dokumentieren → physische Verbindung prüfen → Netzwerkadapter prüfen → IP-Konfiguration bewerten → lokales Protokoll prüfen → Standardgateway testen → Routing untersuchen → DNS getrennt testen → Zielport und Dienst prüfen → Firewall, Proxy und VPN berücksichtigen → kontrollierten Vergleichstest durchführen → Maßnahme umsetzen → erneut messen → Funktion und Nebenwirkungen prüfen → Ursache und Lösung dokumentieren ``` Diese Reihenfolge ist kein starres Schema. Sie verhindert jedoch, dass ohne ausreichende Eingrenzung gleichzeitig Kabel, Einstellungen, Treiber und Netzwerkkomponenten verändert werden. --- **7. Physische Verbindung prüfen** Bei Ethernet sind zu prüfen: - sitzt das Kabel an beiden Seiten vollständig? - zeigt der Netzwerkadapter einen Link? - zeigt der Switchport einen Link? - ist das Kabel sichtbar beschädigt? - wird eine Dockingstation oder ein USB-Netzwerkadapter verwendet? - wird der richtige Anschluss verwendet? - ist der Switchport aktiviert? - stimmt die ausgehandelte Geschwindigkeit? - steigen Fehler- oder Verwerfungszähler? - befindet sich der Anschluss im erwarteten VLAN? - liefert die Dockingstation zuverlässig Strom? - funktioniert ein geprüftes Vergleichskabel? - funktioniert ein bekanntermaßen geeigneter Vergleichsport? **Windows** ```powershell Get-NetAdapter Get-NetAdapterStatistics ``` **Linux** ```bash ip -s link ethtool ``` **macOS** ```bash ifconfig networksetup -getMedia ``` `` muss durch den tatsächlichen Schnittstellennamen ersetzt werden. **Mögliche Beobachtungen** | Beobachtung | mögliche Einordnung | |---|---| | kein Link auf beiden Seiten | Kabel, Port, Adapter, Stromversorgung oder deaktivierte Schnittstelle | | Link nur mit 100 Mbit/s statt 1 Gbit/s | Adernpaar, Auflegung, Kabelqualität oder Aushandlung | | Link wechselt wiederholt | Kontaktproblem, Kabel, Adapter, Dock, Port oder Stromversorgung | | hohe CRC- beziehungsweise FCS-Fehler | physische Signalstörung, Kabel, Stecker oder Port | | viele Drops ohne physische Fehler | Überlastung, Puffer, QoS oder Systemressourcen | | anderer Switchport funktioniert | ursprünglicher Port oder dessen Konfiguration | | anderes Kabel funktioniert | ursprüngliches Kabel oder veränderter Steckkontakt verdächtig | | direkte Verbindung funktioniert, Dock nicht | Dock, USB-Verbindung, Treiber oder Stromversorgung | > Dass der Link aktiv ist, bestätigt nur eine Verbindung auf der Bitübertragungsschicht. Eine richtige IP-Konfiguration, VLAN-Zuordnung oder Ende-zu-Ende-Erreichbarkeit ist damit nicht bewiesen. --- **8. WLAN-Verbindung prüfen** Bei WLAN sind zusätzlich zu prüfen: - ist WLAN aktiviert? - befindet sich das Gerät im Flugmodus? - ist die richtige SSID ausgewählt? - wurde die Authentifizierung erfolgreich abgeschlossen? - besitzt das Gerät eine IP-Konfiguration? - ist das Signal ausreichend? - ist der Signal-Rausch-Abstand ausreichend? - besteht eine Captive-Portal-Anmeldung? - ist das Gerät im richtigen VLAN? - greift eine Geräte- oder Benutzerzulassung? - besteht eine auffällige Kanalnutzung? - funktioniert derselbe Client an einem anderen Standort? - funktioniert ein Vergleichsclient am betroffenen Standort? - wird zwischen verschiedenen Access Points oder Frequenzbändern gewechselt? **Windows** ```powershell netsh wlan show interfaces netsh wlan show networks mode=bssid ``` **Linux mit NetworkManager** ```bash nmcli device status nmcli device wifi list nmcli connection show --active ``` **macOS** ```bash networksetup -getairportnetwork en0 system_profiler SPAirPortDataType ``` Der tatsächliche Schnittstellenname kann abweichen. **Wichtige Unterscheidung** ```text mit SSID verbunden ≠ erfolgreich authentifiziert ≠ richtige VLAN-Zuordnung ≠ gültige IP-Konfiguration ≠ erreichbares Standardgateway ≠ funktionsfähiger DNS-Dienst ≠ erreichbares Internet ``` --- **9. Zustand des Netzwerkadapters prüfen** Ein Netzwerkadapter kann vorhanden, aber nicht funktionsfähig sein. Zu prüfen sind: - Schnittstelle aktiviert oder deaktiviert, - administrativer Zustand, - operativer Zustand, - Treiberstatus, - Firmwarestatus, - Hardwareerkennung, - MAC-Adresse, - Geschwindigkeit und Duplex, - Energieverwaltung, - virtuelle Netzwerkadapter, - VPN-Adapter, - Bridging, - Teaming oder Bonding, - auffällige Fehlerzähler, - wiederholte Trennung und Neuverbindung. **Windows** ```powershell Get-NetAdapter Get-NetAdapterAdvancedProperty Get-NetAdapterPowerManagement Get-PnpDevice -Class Net ``` **Linux** ```bash ip link ip -s link lspci -k lsusb ethtool ``` **macOS** ```bash networksetup -listallhardwareports ifconfig system_profiler SPNetworkDataType ``` > Ein Treiberupdate oder eine Neuinstallation sollte nicht die erste Maßnahme sein, solange der aktuelle Zustand noch nicht ausreichend dokumentiert und eingegrenzt wurde. --- **10. IPv4-Konfiguration bewerten** Eine vollständige IPv4-Konfiguration umfasst normalerweise: - IPv4-Adresse, - Subnetzmaske beziehungsweise Präfixlänge, - Standardgateway, - DNS-Server, - gegebenenfalls DHCP-Server, - Lease-Zeiten, - verbindungsspezifisches DNS-Suffix, - zusätzliche statische Routen. **Beispiel** ```text IPv4-Adresse: 192.168.10.24 Präfix: /24 Standardgateway: 192.168.10.1 DNS-Server: 192.168.10.10 und 192.168.10.11 DHCP-Server: 192.168.10.5 ``` Bei `/24` gehören beispielsweise `192.168.10.24` und `192.168.10.1` zum selben IPv4-Subnetz. **Typische Auffälligkeiten** | Beobachtung | mögliche Ursache | |---|---| | keine IPv4-Adresse | Adapter, DHCP, VLAN oder Konfiguration | | Adresse aus `169.254.0.0/16` | keine nutzbare DHCP-Antwort oder bewusst verwendete Link-Local-Adresse | | Adresse `0.0.0.0` | Initialisierung oder Adresszuweisung fehlgeschlagen | | falsches Subnetz | statische Fehlkonfiguration oder falscher DHCP-Bereich | | kein Standardgateway | DHCP-Option fehlt oder statische Konfiguration unvollständig | | falscher DNS-Server | DHCP-Option, VPN, manuelle Konfiguration oder Richtlinie | | doppelte IP-Adresse | Adresskonflikt | | sehr kurze Lease-Zeit | DHCP-Konfiguration oder Sondernetz | | mehrere Gateways | mehrdeutiges Routing oder mehrere aktive Adapter | | gültige Adresse, Gateway nicht erreichbar | VLAN, Layer 2, Gateway, ARP oder Firewall | | Gateway erreichbar, entfernte IP nicht | Routing, Firewall, NAT oder Zielpfad | --- **11. Automatische private IPv4-Adresse richtig einordnen** Erhält ein Windows-Client keine geeignete DHCP-Konfiguration, kann er automatisch eine Adresse aus `169.254.0.0/16` verwenden. Dieser Bereich ist für IPv4 Link-Local-Adressen vorgesehen. Eine solche Adresse bedeutet nicht automatisch: - dass der DHCP-Server ausgeschaltet ist, - dass das Netzwerkkabel defekt ist, - dass der Switch ausgefallen ist, - dass der Client überhaupt keine Verbindung besitzt. Mögliche Ursachen sind: - DHCP-Server nicht erreichbar, - DHCP-Dienst ausgefallen, - falsches VLAN, - fehlerhafter DHCP-Relay-Agent, - erschöpfter DHCP-Adressbereich, - DHCP-Antwort durch Sicherheitsfunktion blockiert, - fehlerhafte Portkonfiguration, - beschädigte Verbindung, - Clientfehler, - verzögerte Adressvergabe. **Zu prüfen sind** ```text physischer Link → VLAN-Zuordnung → DHCP-Anforderung → DHCP-Weiterleitung → DHCP-Server → verfügbarer Adressbereich → DHCP-Angebot → Clientannahme ``` --- **12. DHCP systematisch untersuchen** Der vereinfachte IPv4-DHCP-Ablauf wird häufig als DORA bezeichnet: ```text DHCPDISCOVER → DHCPOFFER → DHCPREQUEST → DHCPACK ``` Je nach Zustand und Erneuerung eines Leases können andere DHCP-Nachrichten auftreten. **Windows** ```powershell ipconfig /all ipconfig /release ipconfig /renew ``` **Linux mit NetworkManager** ```bash nmcli device show nmcli connection show --active ``` **macOS** ```bash ipconfig getpacket networksetup -getinfo ``` Eine Lease-Erneuerung verändert den Zustand und sollte nur kontrolliert ausgeführt werden. **Mögliche Fehlerstellen** | Phase | mögliche Ursache | |---|---| | Discover verlässt Client nicht | Schnittstelle, Clientdienst, lokale Firewall oder Treiber | | Discover erreicht Server nicht | VLAN, Switch, DHCP Snooping, Relay oder Routing | | Server sendet kein Offer | Dienst, Bereich, Reservierung, Richtlinie oder Adressmangel | | Offer erreicht Client nicht | Relay, VLAN, Sicherheitsfunktion oder Rückweg | | Client sendet keinen Request | Clientzustand oder ungeeignetes Angebot | | Server sendet kein ACK | Konflikt, Richtlinie, Bereich oder Serverfehler | | ACK erreicht Client nicht | Netzwerkpfad oder Sicherheitsfunktion | | Adresse vorhanden, Optionen fehlen | DHCP-Optionen oder Gültigkeitsbereich fehlerhaft | **Bei DHCP zusätzlich prüfen** - ist der richtige DHCP-Bereich aktiv? - sind freie Adressen vorhanden? - bestehen Ausschlüsse oder Reservierungen? - stimmt die Subnetzmaske? - wird das richtige Gateway verteilt? - werden geeignete DNS-Server verteilt? - stimmt der DHCP-Relay-Eintrag? - ist DHCP Snooping korrekt konfiguriert? - existiert ein nicht autorisierter DHCP-Server? - erscheinen Fehler oder Konflikte im DHCP-Protokoll? --- **13. IPv6 nicht übersehen** Ein Client kann gleichzeitig IPv4 und IPv6 verwenden. Daher können Fehler nur eines Protokollstapels zu scheinbar widersprüchlichen Ergebnissen führen. Zu prüfen sind: - Link-Local-Adresse, - globale oder lokale IPv6-Adresse, - Präfixlänge, - Standardroute, - Router Advertisement, - DNS-Server, - DHCPv6, sofern eingesetzt, - Duplicate Address Detection, - Neighbor Discovery, - Übergangs- oder Tunnelmechanismen, - IPv6-Firewallregeln. **Windows** ```powershell Get-NetIPAddress -AddressFamily IPv6 Get-NetRoute -AddressFamily IPv6 ipconfig /all ``` **Linux** ```bash ip -6 address ip -6 route ip -6 neighbor ``` **macOS** ```bash ifconfig netstat -rn -f inet6 ``` **Wichtige Einordnung** - Eine Adresse aus `fe80::/10` ist eine IPv6-Link-Local-Adresse. - Link-Local-Adressen gelten nur auf dem jeweiligen Link. - Bei der Verwendung einer Link-Local-Adresse kann eine Schnittstellenangabe erforderlich sein. - Ein funktionierendes IPv6 kann einen defekten IPv4-Pfad teilweise verdecken. - Ein fehlerhafter IPv6-Pfad kann Verzögerungen erzeugen, obwohl IPv4 funktioniert. - IPv6 sollte nicht allein zur Fehlerumgehung pauschal deaktiviert werden. --- **14. Lokalen Protokollstapel prüfen** Vor externen Zielen kann zunächst der lokale TCP/IP-Stapel geprüft werden. **IPv4** ```text 127.0.0.1 ``` **IPv6** ```text ::1 ``` **Windows** ```powershell ping 127.0.0.1 ping ::1 ``` **Linux und macOS** ```bash ping 127.0.0.1 ping6 ::1 ``` Abhängig vom Betriebssystem kann der IPv6-Befehl auch über `ping -6` erfolgen. Ein erfolgreicher Loopback-Test bestätigt Teile des lokalen Protokollstapels. Er bestätigt nicht: - den Netzwerkadapter, - das Kabel, - die WLAN-Verbindung, - die VLAN-Zuordnung, - das Standardgateway, - den DNS-Dienst, - die Erreichbarkeit anderer Systeme. --- **15. Eigene Adresse prüfen** Danach kann die eigene zugewiesene Adresse geprüft werden. ```text Loopback-Adresse → eigene IP-Adresse → Nachbar im selben Netz → Standardgateway → entferntes Ziel per IP → DNS-Server → Ziel per DNS-Namen → konkreter Dienst und Port ``` Auch ein erfolgreicher Ping auf die eigene Adresse bestätigt nicht automatisch, dass Pakete den physischen Netzwerkadapter tatsächlich verlassen. --- **16. ARP und Neighbor Discovery untersuchen** Für IPv4 wird ARP verwendet, um IPv4-Adressen auf MAC-Adressen im lokalen Netz abzubilden. IPv6 verwendet Neighbor Discovery über ICMPv6. **Windows** ```powershell arp -a Get-NetNeighbor ``` **Linux** ```bash ip neighbor ``` **macOS** ```bash arp -a ndp -a ``` **Mögliche Zustände** | Beobachtung | mögliche Einordnung | |---|---| | Gateway besitzt gültigen Nachbareintrag | lokale Auflösung war grundsätzlich möglich | | Eintrag bleibt unvollständig | Gegenstelle antwortet nicht oder Layer-2-Pfad fehlerhaft | | MAC-Adresse ändert sich unerwartet | Redundanz, Gatewaywechsel, Fehlkonfiguration oder Sicherheitsproblem | | falsche MAC-Adresse | doppelter Adressgebrauch, ARP-Spoofing oder falsche Netzstruktur | | viele unvollständige Einträge | Layer-2-, VLAN- oder Erreichbarkeitsproblem | | Nachbareintrag vorhanden, Ping scheitert | ICMP kann blockiert sein oder Gegenstelle antwortet nicht | Ein vorhandener ARP- oder Neighbor-Eintrag beweist nicht die vollständige Erreichbarkeit eines Dienstes. --- **17. Standardgateway prüfen** Das Standardgateway leitet Daten zu Zielen außerhalb des lokalen Netzes weiter. Zu prüfen sind: - ist ein Gateway eingetragen? - gehört das Gateway zum direkt erreichbaren Netz? - ist eine passende Standardroute vorhanden? - wird die richtige Schnittstelle verwendet? - stimmt die Metrik beziehungsweise Priorität? - ist das Gateway über ARP oder Neighbor Discovery erreichbar? - antwortet es auf zulässige Tests? - betrifft das Problem nur ein VLAN? - ist die Gateway-Schnittstelle aktiv? - bestehen redundante Gateways? - funktionieren Hin- und Rückweg? **Windows** ```powershell Get-NetRoute -DestinationPrefix "0.0.0.0/0" Get-NetRoute -AddressFamily IPv6 route print ``` **Linux** ```bash ip route ip -6 route ``` **macOS** ```bash route -n get default netstat -rn ``` > Ein Gateway muss nicht auf ICMP-Echo-Anfragen antworten. Ein fehlgeschlagener Ping allein beweist deshalb keinen Gateway-Ausfall. --- **18. Lokales und entferntes Ziel unterscheiden** Ob ein Ziel lokal oder entfernt ist, ergibt sich aus: - eigener IP-Adresse, - Präfix beziehungsweise Subnetzmaske, - Zieladresse, - Routingtabelle. **Beispiel** ```text Client: 192.168.10.24/24 Ziel A: 192.168.10.80 Ziel B: 192.168.20.80 ``` `Ziel A` liegt im selben `/24`-Netz und wird normalerweise direkt über die lokale Verbindung erreicht. `Ziel B` liegt in einem anderen Netz und benötigt eine passende Route, häufig über das Standardgateway. Eine falsche Subnetzmaske kann dazu führen, dass der Client ein entferntes Ziel fälschlich als lokal behandelt oder ein lokales Ziel unnötig an ein Gateway sendet. --- **19. Routingtabelle auswerten** Die Routingentscheidung berücksichtigt unter anderem: - Zielpräfix, - Präfixlänge, - Gateway, - Schnittstelle, - Metrik, - Richtlinien, - VPN-Routen, - statische Routen, - mehrere aktive Netzwerkadapter. Grundsätzlich gewinnt die spezifischste passende Route, also die Route mit dem längsten passenden Präfix. **Beispiel** ```text 0.0.0.0/0 über 192.168.10.1 10.0.0.0/8 über VPN 10.20.30.0/24 über 192.168.10.254 ``` Für ein Ziel in `10.20.30.0/24` ist die `/24`-Route spezifischer als die `/8`-Route und die Standardroute. **Typische Routingfehler** - keine Standardroute, - falsches Gateway, - falsche Präfixlänge, - unerwünschte VPN-Route, - gleiche Netze auf beiden Seiten eines VPN, - mehrere Standardrouten, - ungeeignete Metrik, - fehlende Rückroute, - asymmetrisches Routing, - veraltete statische Route, - falsche Schnittstellenbindung. --- **20. Erreichbarkeit schrittweise testen** Eine sinnvolle Testfolge lautet: ```text 1. Loopback 2. eigene Adresse 3. Gegenstelle im selben Subnetz 4. Standardgateway 5. entferntes internes Ziel per IP 6. externer Dienst per IP 7. DNS-Server 8. Name eines internen Ziels 9. Name eines externen Ziels 10. konkreter TCP- oder UDP-Dienst ``` Die Ziele müssen bewusst ausgewählt werden. Eine beliebige öffentliche IP-Adresse oder Website ist nicht automatisch ein geeigneter Referenzpunkt. **Beispielhafte Dokumentation** | Test | Ergebnis | Einordnung | |---|---|---| | Loopback erreichbar | erfolgreich | lokaler Protokollstapel grundsätzlich aktiv | | eigene Adresse erreichbar | erfolgreich | lokale Adressbindung vorhanden | | Gateway nicht erreichbar | fehlgeschlagen | Layer 2, VLAN, Gateway oder ICMP-Regel untersuchen | | internes Ziel per IP erreichbar | erfolgreich | grundlegendes Routing vorhanden | | interner Name nicht auflösbar | fehlgeschlagen | DNS gezielt untersuchen | | Name wird aufgelöst, Port 443 nicht erreichbar | fehlgeschlagen | Dienst, Firewall, Route oder Zielsystem | | Port 443 erreichbar, Browser scheitert | fehlgeschlagen | TLS, Proxy, Anwendung oder Authentifizierung | --- **21. Ping richtig interpretieren** `ping` verwendet ICMP-Echo-Anfragen und kann Hinweise auf Erreichbarkeit und Laufzeit geben. Ein erfolgreicher Ping kann bestätigen: - das Ziel beziehungsweise eine antwortende Komponente ist erreichbar, - ein Hin- und Rückweg für diese ICMP-Pakete besteht, - die verwendete Zieladresse war grundsätzlich erreichbar. Ein erfolgreicher Ping bestätigt nicht: - dass DNS funktioniert, - dass ein bestimmter TCP- oder UDP-Port erreichbar ist, - dass die Anwendung funktioniert, - dass keine Paketverluste bei anderer Last auftreten, - dass der gesamte Pfad fehlerfrei ist, - dass die Antwort tatsächlich vom erwarteten Anwendungsdienst stammt. Ein fehlgeschlagener Ping beweist nicht automatisch: - dass das Ziel ausgefallen ist, - dass keine Route besteht, - dass eine Firewall vollständig blockiert, - dass das Netzwerk unterbrochen ist. ICMP kann gefiltert, begrenzt oder vom Ziel nicht beantwortet werden. --- **22. Pfad mit Traceroute untersuchen** **Windows** ```powershell tracert Test-NetConnection -TraceRoute ``` **Linux** ```bash traceroute tracepath ``` **macOS** ```bash traceroute ``` Traceroute-Werkzeuge senden Pakete mit schrittweise erhöhtem Hop Limit beziehungsweise TTL-Wert. Zwischenrouter können daraufhin ICMP-Meldungen zurückgeben. **Grenzen** - Router müssen nicht antworten. - Ein Sternchen beweist keinen Ausfall. - Hin- und Rückweg können unterschiedlich sein. - Firewalls können die verwendeten Probe-Pakete filtern. - Load Balancing kann unterschiedliche Pfade anzeigen. - Der letzte sichtbare Hop ist nicht automatisch die Fehlerstelle. - Hohe Antwortzeit eines Zwischenrouters beweist keine Weiterleitungsverzögerung. - Unterschiedliche Implementierungen verwenden unterschiedliche Protokolle. > Entscheidend ist nicht nur, welcher Hop antwortet, sondern ob nachfolgende Hops und der eigentliche Zieldienst erreichbar sind. --- **23. DNS getrennt von der Netzwerkverbindung prüfen** Wenn ein Ziel per IP-Adresse erreichbar ist, aber nicht über seinen Namen, liegt der Untersuchungsbereich häufig bei der Namensauflösung. Zu prüfen sind: - konfigurierte DNS-Server, - Erreichbarkeit der DNS-Server, - Suchdomänen, - DNS-Suffix, - Record-Typ, - Name und Schreibweise, - DNS-Cache, - Split-DNS, - VPN-DNS, - Weiterleitungen, - Rekursion, - lokale Hosts-Datei, - DNSSEC, sofern relevant, - Ablaufzeit und Replikation, - Filter- oder Sicherheitsdienst. **Windows** ```powershell Resolve-DnsName nslookup Get-DnsClientServerAddress Get-DnsClientCache ``` **Linux** ```bash resolvectl query resolvectl status dig ``` **macOS** ```bash scutil --dns dig nslookup ``` **Gezielte Abfrage eines bestimmten DNS-Servers** ```bash dig @ ``` **Mögliche Ergebnisse** | Ergebnis | mögliche Einordnung | |---|---| | Name wird korrekt aufgelöst | DNS-Auflösung grundsätzlich erfolgreich | | `NXDOMAIN` | Name existiert aus Sicht des antwortenden DNS-Systems nicht | | Zeitüberschreitung | DNS-Server, Netzwerkpfad oder Firewall | | falsche Adresse | veralteter oder fehlerhafter Eintrag, Cache oder Split-DNS | | interner Name nur ohne VPN auflösbar | DNS-Zuweisung oder VPN-Routing untersuchen | | externer Name funktioniert, interner nicht | interne Zone, Suchdomäne oder Split-DNS | | ein DNS-Server antwortet, der andere nicht | Serverzustand, Pfad oder Konfiguration | | AAAA vorhanden, IPv6-Pfad fehlerhaft | IPv6 und Anwendungsauswahl untersuchen | > `nslookup`, `dig`, `Resolve-DnsName` und die Namensauflösung einer Anwendung können unterschiedliche Auflösungswege oder Bibliotheken verwenden. Ergebnisse müssen im Kontext des Betriebssystems und der Anwendung bewertet werden. --- **24. Port und Dienst statt nur Host testen** Ein erreichbarer Host bestätigt nicht, dass der benötigte Dienst erreichbar ist. **Windows** ```powershell Test-NetConnection -Port 443 ``` **Linux und macOS** ```bash nc -vz 443 ``` **HTTP beziehungsweise HTTPS** ```bash curl -I https:// curl -v https:// ``` **TLS-Verbindung** ```bash openssl s_client -connect :443 -servername ``` Die Werkzeuge müssen auf dem jeweiligen System vorhanden sein. Vertrauliche Header, Tokens, Cookies und Zertifikatsdaten dürfen nicht ungeprüft in Tickets oder öffentliche Dokumentationen übernommen werden. **Mögliche Ergebnisse** | Ergebnis | mögliche Einordnung | |---|---| | Verbindung hergestellt | TCP-Verbindung zum Port grundsätzlich möglich | | Verbindung abgelehnt | Ziel erreichbar, aber Dienst nicht aktiv oder Port geschlossen | | Zeitüberschreitung | Filterung, Routing, Zielzustand oder Rückweg | | TLS-Fehler | Zertifikat, Protokollversion, SNI, Uhrzeit oder Inspektion | | HTTP `401` oder `403` | Dienst erreichbar, Authentifizierung oder Berechtigung erforderlich | | HTTP `404` | Webdienst erreichbar, angeforderte Ressource nicht gefunden | | HTTP `500` | serverseitiger Anwendungsfehler | | Umleitungsschleife | Proxy-, Anwendung-, TLS- oder URL-Konfiguration | --- **25. Lokale Firewall prüfen** Eine lokale Firewall kann eingehenden oder ausgehenden Verkehr abhängig von folgenden Merkmalen filtern: - Quell- und Zieladresse, - Protokoll, - Port, - Netzwerkprofil, - Schnittstelle, - Anwendung, - Benutzer, - Dienst, - Richtung, - Sicherheitsrichtlinie. **Windows** ```powershell Get-NetFirewallProfile Get-NetFirewallRule -Enabled True ``` **Linux** Je nach System können unter anderem verwendet werden: ```bash nft list ruleset iptables -S ufw status verbose firewall-cmd --state ``` **macOS** ```bash /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate pfctl -s info ``` Zum Auslesen einzelner Firewallinformationen können erhöhte Rechte erforderlich sein. > Eine Firewall sollte nicht pauschal und dauerhaft deaktiviert werden. Besser ist ein zeitlich begrenzter, dokumentierter Test mit Freigabe oder die gezielte Auswertung von Protokollen und Regeln. --- **26. Netzwerk-Firewalls und ACLs berücksichtigen** Zwischen Client und Ziel können mehrere Filterinstanzen liegen: - Switch-ACL, - Router-ACL, - VLAN-Firewall, - Host-Firewall, - Standort-Firewall, - Cloud-Firewall, - Security Group, - Web Application Firewall, - Proxy, - VPN-Gateway, - Netzwerkzugangskontrolle. Zu prüfen sind: - Quelle, - Ziel, - Protokoll, - Quellport, - Zielport, - Richtung, - Zeitstempel, - zustandsbehaftete Sitzung, - NAT-Übersetzung, - passende Regel, - Regelreihenfolge, - Protokolleintrag, - Rückweg. Eine scheinbar passende Freigaberegel kann wirkungslos sein, wenn: - eine frühere Regel den Verkehr blockiert, - die falsche Zone verwendet wird, - die tatsächliche Quelladresse durch NAT verändert wurde, - die Anwendung einen zusätzlichen Port benötigt, - der Rückweg fehlt, - IPv6 anders behandelt wird als IPv4. --- **27. Proxy-Konfiguration untersuchen** Ein Proxy kann nur bestimmte Anwendungen oder Protokolle beeinflussen. Deshalb kann beispielsweise `ping` funktionieren, während der Browser keine Website öffnet. Zu prüfen sind: - manueller Proxy, - automatisch erkannter Proxy, - PAC-Datei, - systemweiter Proxy, - anwendungseigener Proxy, - Authentifizierung, - Ausnahmeliste, - HTTPS-Inspektion, - Erreichbarkeit des Proxyservers, - Namensauflösung des Proxys, - Zertifikatsvertrauen, - Umgebungsvariablen. **Windows** ```powershell netsh winhttp show proxy Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" ``` **Linux und macOS** ```bash env | grep -i proxy ``` **macOS zusätzlich** ```bash scutil --proxy ``` Sensible Inhalte aus PAC-Dateien, Proxyadressen oder Zugangsdaten dürfen nicht ungeschützt dokumentiert werden. --- **28. VPN als eigene Fehlerdomäne behandeln** Ein VPN verändert möglicherweise: - Routingtabelle, - Standardroute, - DNS-Server, - Suchdomänen, - MTU, - Firewallregeln, - Proxykonfiguration, - Quelladresse, - erreichbare Netze. **Vergleichstests** ```text ohne VPN → mit VPN → internes Ziel → externes Ziel → Ziel per IP → Ziel per Namen → Routingtabelle vorher und nachher → DNS-Konfiguration vorher und nachher ``` **Typische VPN-Probleme** - überlappende lokale und entfernte Netze, - fehlende Route, - falsches Split Tunneling, - gesamter Verkehr unerwartet durch den Tunnel, - interner DNS-Server nicht erreichbar, - MTU- oder Fragmentierungsproblem, - abgelaufenes Zertifikat, - fehlgeschlagene Authentifizierung, - lokale Firewallregel, - instabile Internetverbindung, - fehlerhafter VPN-Adapter. --- **29. MTU- und Fragmentierungsprobleme** Ein Pfad kann kleine Pakete übertragen, während größere Übertragungen scheitern oder hängen bleiben. Mögliche Symptome sind: - Ping mit kleinen Paketen funktioniert, - Webseiten laden nur teilweise, - Dateiübertragungen bleiben stehen, - VPN-Verbindungen sind instabil, - TLS-Verbindungen brechen ab, - einzelne Anwendungen funktionieren, andere nicht. Mögliche Ursachen: - ungeeignete MTU, - VPN-Overhead, - PPPoE-Overhead, - blockierte ICMP-Meldungen für Path MTU Discovery, - Tunnel oder Kapselung, - fehlerhafte Fragmentierungsbehandlung. **Windows – Beispieltest** ```powershell ping -f -l ``` **Linux – Beispieltest** ```bash ping -M do -s ``` Die geeignete Nutzlastgröße hängt vom Protokoll, Betriebssystem und Pfad ab. Ein einzelner Testwert darf nicht ohne Einordnung als allgemeingültige MTU übernommen werden. --- **30. Mehrere aktive Netzwerkadapter** Ein Client kann gleichzeitig verbunden sein über: - Ethernet, - WLAN, - Mobilfunk, - VPN, - virtuelle Maschine, - Container-Bridge, - USB-Netzwerkadapter, - Dockingstation, - Host-only-Netz, - virtuelle Switches. Dadurch können entstehen: - mehrere Standardrouten, - unerwartete Metriken, - falscher DNS-Server, - asymmetrisches Routing, - Namensauflösung über die falsche Schnittstelle, - falsche Quelladresse, - nicht erreichbare lokale Netze, - VPN-Konflikte. **Kontrollierter Test** 1. aktuelle Adapter und Routen dokumentieren. 2. tatsächlich verwendete Route zum Ziel bestimmen. 3. nicht benötigte Verbindung nur mit Freigabe vorübergehend trennen. 4. Test wiederholen. 5. ursprünglichen Zustand wiederherstellen. 6. Ursache dauerhaft in der Adapter-, Routing- oder VPN-Konfiguration beheben. --- **31. Vergleichstests richtig verwenden** Ein guter Vergleichstest verändert nur eine relevante Komponente. Mögliche Vergleichskomponenten sind: - geprüftes Netzwerkkabel, - anderer Switchport, - andere Datendose, - anderer Netzwerkadapter, - andere Dockingstation, - anderer Client, - anderer Benutzer, - anderes VLAN, - anderes WLAN, - anderes Ziel, - Verbindung ohne VPN, - Verbindung ohne Proxy, - direkte Verbindung statt Dockingstation. **Beispiel** ```text Ursprünglich: Client A + Dock A + Kabel A + Dose A → Fehler Vergleich 1: Client A + Dock A + geprüftes Kabel B + Dose A → Fehler Vergleich 2: Client A + Dock B + geprüftes Kabel B + Dose A → funktioniert ``` Damit wird Dock A zum Hauptverdacht. Vor dem endgültigen Austausch sollte das Ergebnis reproduziert und die übrige Konfiguration verglichen werden. > Wenn bei einem Test gleichzeitig Kabel, Port, Dock und Benutzer gewechselt werden, lässt sich aus dem Erfolg keine einzelne Ursache ableiten. --- **32. Paketaufzeichnung gezielt einsetzen** Wenn Statusanzeigen und Standardtests keine ausreichende Erklärung liefern, kann eine Paketaufzeichnung zeigen, welche Kommunikation tatsächlich stattfindet. Geeignete Werkzeuge sind beispielsweise: - Wireshark, - `tcpdump`, - `tshark`, - Windows-Paketaufzeichnungswerkzeuge, - Port Mirroring beziehungsweise SPAN, - Capture-Funktionen auf Firewalls, Routern oder Access Points. **Mögliche Fragestellungen** - verlässt eine DHCP-Anfrage den Client? - antwortet ein DHCP-Server? - wird eine ARP-Anfrage beantwortet? - erfolgt eine DNS-Anfrage? - welcher DNS-Server antwortet? - wird ein TCP-SYN gesendet? - kommt ein SYN-ACK oder RST zurück? - findet eine TLS-Aushandlung statt? - treten Wiederholungen oder Zeitüberschreitungen auf? - wird ICMP zur Fehleranzeige zurückgesendet? - kommuniziert die Anwendung mit dem erwarteten Ziel? **Beispielhafte Filter** ```text arp dhcp dns icmp icmpv6 tcp.port == 443 ip.addr == 192.0.2.10 ``` **Datenschutz und Sicherheit** Paketaufzeichnungen können enthalten: - IP-Adressen, - Hostnamen, - Benutzernamen, - Sitzungsdaten, - DNS-Anfragen, - unverschlüsselte Inhalte, - Authentifizierungsinformationen, - interne Systemstrukturen. Aufzeichnungen dürfen nur mit Berechtigung erstellt, auf das erforderliche Zeitfenster begrenzt, sicher gespeichert und kontrolliert weitergegeben werden. --- **33. Typische TCP-Beobachtungen** **Erfolgreicher Verbindungsaufbau** ```text Client → Server: SYN Server → Client: SYN, ACK Client → Server: ACK ``` **Port geschlossen** ```text Client → Server: SYN Server → Client: RST, ACK ``` **Keine sichtbare Antwort** ```text Client → Server: SYN Client → Server: erneutes SYN Client → Server: weiteres SYN ``` Mögliche Ursachen für eine ausbleibende Antwort sind: - Filterung, - Ziel nicht erreichbar, - Rückroute fehlt, - Server antwortet nicht, - Paket erreicht das Ziel nicht, - Antwort erreicht den Client nicht. Eine Paketaufzeichnung an nur einer Stelle zeigt nicht automatisch, an welcher Stelle des gesamten Pfades das Paket verloren geht. --- **34. Ereignisprotokolle gemeinsam auswerten** Relevante Quellen können sein: - Client-Ereignisprotokolle, - NetworkManager- oder Systemprotokolle, - DHCP-Serverprotokolle, - DNS-Protokolle, - Switch- und Routerprotokolle, - Firewallprotokolle, - VPN-Protokolle, - Proxyprotokolle, - Access-Point- und Controllerprotokolle, - Authentifizierungsserver, - Zielserverprotokolle, - Monitoringdaten. Alle Ereignisse sollten anhand eines möglichst genauen Zeitstempels zusammengeführt werden. **Zeitbezug** ```text 14:31:02 Client verliert Link 14:31:04 Switchport meldet Down 14:31:09 Switchport meldet Up 14:31:11 DHCP Discover 14:31:11 DHCP Offer 14:31:12 DHCP Request 14:31:12 DHCP ACK 14:31:14 DNS-Anfrage erfolgreich ``` Diese zeitliche Korrelation liefert stärkere Hinweise als voneinander getrennte Einzelmeldungen. --- **35. Praxisfall A: Client erhält eine Adresse aus 169.254.0.0/16** **Symptom** - Link ist aktiv. - Client besitzt `169.254.37.18/16`. - Standardgateway fehlt. - interne und externe Ziele sind nicht erreichbar. **Prüfung** 1. Adapterstatus dokumentieren. 2. Switchport und VLAN bestimmen. 3. anderes Gerät am selben Anschluss testen. 4. DHCP-Lease und DHCP-Clientprotokoll prüfen. 5. DHCP-Ablauf aufzeichnen. 6. Switch-Sicherheitsfunktionen prüfen. 7. DHCP-Relay kontrollieren. 8. DHCP-Bereich und freie Adressen prüfen. 9. Änderung einzeln durchführen. 10. neue Adressvergabe und Erreichbarkeit kontrollieren. **Mögliche Ursache** Der Switchport wurde nach einem Arbeitsplatzwechsel dem falschen VLAN zugeordnet. Der DHCP-Broadcast erreicht dadurch nicht den DHCP-Relay des vorgesehenen Clientnetzes. **Nachprüfung** - richtige IPv4-Adresse erhalten, - Gateway vorhanden, - geeignete DNS-Server vorhanden, - internes Ziel erreichbar, - externer Dienst erreichbar, - erneute Adressvergabe erfolgreich, - Portkonfiguration dokumentiert. --- **36. Praxisfall B: IP-Ziele funktionieren, DNS-Namen nicht** **Symptom** - Standardgateway erreichbar. - internes Ziel über IP-Adresse erreichbar. - Name `intranet.example.internal` wird nicht aufgelöst. **Prüfung** 1. konfigurierte DNS-Server dokumentieren. 2. DNS-Server per IP testen. 3. Namen über jeden DNS-Server einzeln abfragen. 4. DNS-Suffix und Suchdomäne prüfen. 5. VPN- und Split-DNS-Konfiguration vergleichen. 6. DNS-Zone und Resource Record prüfen. 7. Cache nur bei begründetem Verdacht kontrolliert leeren. 8. Auflösung und Anwendung erneut testen. **Mögliche Ursache** Nach dem Aufbau des VPN wird weiterhin ein öffentlicher DNS-Server verwendet. Dieser kennt die interne Zone nicht. **Nachprüfung** - interner Name wird korrekt aufgelöst, - erwartete IP-Adresse wird geliefert, - Anwendung erreicht das Ziel, - öffentliche Namensauflösung funktioniert weiterhin, - Verhalten nach erneuter VPN-Verbindung bleibt korrekt. --- **37. Praxisfall C: Website antwortet nicht, Ping funktioniert** **Symptom** - Zielname wird korrekt aufgelöst. - Ping zum Ziel ist erfolgreich. - HTTPS-Verbindung scheitert. **Prüfung** 1. aufgelöste Zieladresse dokumentieren. 2. TCP-Port 443 testen. 3. Pfad zum Ziel untersuchen. 4. lokale und zentrale Firewallprotokolle prüfen. 5. Proxykonfiguration prüfen. 6. TLS-Verbindung untersuchen. 7. Dienstzustand am Ziel prüfen. 8. Vergleich von internem und externem Zugriff durchführen. **Mögliche Ergebnisse** | Ergebnis | Einordnung | |---|---| | TCP-Port 443 abgelehnt | Host erreichbar, Dienst nicht aktiv oder Port geschlossen | | TCP-Verbindung läuft in Timeout | Firewall, Routing oder Rückweg | | TLS-Zertifikat abgelaufen | Transport funktioniert, TLS-Vertrauen scheitert | | Proxy meldet Zugriff verweigert | Proxyregel oder Berechtigung | | HTTP `503` | Webdienst oder nachgelagerter Dienst nicht verfügbar | | direkter Zugriff funktioniert, Proxyzugriff nicht | Proxykonfiguration oder Proxyzustand | --- **38. Praxisfall D: Nur über die Dockingstation kein Netzwerk** **Symptom** - WLAN funktioniert. - integrierter Netzwerkanschluss beziehungsweise anderer Adapter funktioniert. - Ethernet über die Dockingstation fällt wiederholt aus. **Prüfung** 1. Dockmodell und Anschlussart dokumentieren. 2. Linkstatus und Fehlerzähler prüfen. 3. Stromversorgung des Docks kontrollieren. 4. geprüftes Kabel verwenden. 5. anderen USB-C- beziehungsweise Thunderbolt-Anschluss testen. 6. Vergleichsdock verwenden. 7. Treiber- und Firmwarestand nach Herstellerangabe prüfen. 8. Energiesparverhalten untersuchen. 9. Ereignisprotokolle zum Zeitpunkt der Trennung auswerten. 10. Langzeittest nach der Maßnahme durchführen. **Mögliche Ursachen** - instabile Stromversorgung, - Dock-Firmware, - Treiber, - USB-Verbindung, - defekter Netzwerkcontroller, - ungeeignetes Kabel, - Energiesparzustand, - thermisches Problem. --- **39. Praxisfall E: Interne Systeme funktionieren nur ohne VPN** **Symptom** - ohne VPN sind lokale Systeme erreichbar. - nach dem VPN-Aufbau sind bestimmte lokale Netze nicht erreichbar. - Internetzugriff funktioniert weiterhin. **Prüfung** 1. Routingtabelle vor VPN-Verbindung sichern. 2. Routingtabelle nach VPN-Verbindung sichern. 3. DNS-Konfiguration vergleichen. 4. Zielnetz und lokales Clientnetz vergleichen. 5. überlappende Präfixe suchen. 6. verwendete Route zum Ziel bestimmen. 7. Split-Tunneling-Richtlinie prüfen. 8. VPN-Firewall- und Zugriffsrichtlinien prüfen. 9. kontrollierten Test mit geeignetem nicht überlappendem Netz durchführen. 10. dauerhafte Netz- oder VPN-Konfiguration korrigieren. **Mögliche Ursache** Das lokale Netz und ein entferntes Unternehmensnetz verwenden dasselbe IPv4-Präfix. Der Client kann nicht eindeutig bestimmen, ob das Ziel lokal oder über den VPN-Tunnel erreichbar ist. --- **40. Ungeeignete Sofortmaßnahmen** Folgende Maßnahmen können Spuren vernichten, neue Fehler erzeugen oder den ursprünglichen Zustand unklar machen: - Client sofort neu starten, - Switchport ohne Dokumentation umkonfigurieren, - Netzwerkadapter zurücksetzen, - alle gespeicherten WLAN-Profile löschen, - DHCP-Adresse mehrfach ungeprüft erneuern, - DNS-Cache ohne vorherige Prüfung leeren, - Firewall vollständig deaktivieren, - IPv6 pauschal abschalten, - VPN-Client neu installieren, - Netzwerkstack zurücksetzen, - Treiber ungeprüft ersetzen, - mehrere Kabel und Ports gleichzeitig wechseln, - statische Adresse als dauerhafte Umgehung eintragen, - Router oder Switch ohne Freigabe neu starten. Solche Maßnahmen sind nicht grundsätzlich verboten. Sie müssen jedoch begründet, freigegeben, dokumentiert und anschließend vollständig überprüft werden. --- **41. Häufige Fehlinterpretationen** | Aussage | fachliche Einordnung | |---|---| | „Der Link leuchtet, also funktioniert das Netzwerk.“ | Ein Link bestätigt keine gültige IP-Konfiguration oder Ende-zu-Ende-Verbindung. | | „Der Client hat eine IP-Adresse, also funktioniert DHCP.“ | Die Adresse kann statisch, veraltet, link-local oder aus dem falschen Netz sein. | | „Das Gateway antwortet nicht auf Ping, also ist es ausgefallen.“ | ICMP-Echo kann gefiltert oder deaktiviert sein. | | „Ping funktioniert, also liegt es an der Anwendung.“ | Der benötigte Dienst, Port, DNS, Proxy oder TLS kann weiterhin fehlerhaft sein. | | „Eine Website funktioniert, also funktioniert DNS.“ | Die Adresse kann aus einem Cache stammen oder die Anwendung kann einen anderen Resolver verwenden. | | „Eine Adresse aus 169.254.0.0/16 beweist einen defekten DHCP-Server.“ | VLAN, Relay, Switchport, Client oder Sicherheitsfunktionen können ursächlich sein. | | „Traceroute endet an Router X, also ist Router X defekt.“ | Router können Antworten filtern, obwohl sie Daten weiterhin übertragen. | | „Ohne Firewall funktioniert es, also muss sie dauerhaft deaktiviert bleiben.“ | Die konkrete Regel oder Zuordnung muss ermittelt und gezielt korrigiert werden. | | „Ein anderes Kabel funktioniert, also ist ausschließlich das ursprüngliche Kabel defekt.“ | Auch Kontakte, Position oder mechanische Belastung wurden verändert. | | „Nach dem Neustart funktioniert es, also ist der Fehler behoben.“ | Ein Neustart kann Symptome beseitigen, ohne die Ursache zu erklären. | | „IPv4 funktioniert, also ist die gesamte Netzwerkverbindung in Ordnung.“ | Anwendungen können IPv6 bevorzugen oder beide Protokolle verwenden. | | „Der Fehler liegt sicher beim Provider.“ | Lokale Verbindung, DNS, Routing, Firewall und Zielsystem müssen getrennt geprüft werden. | --- **42. Vollständige Prüfreihenfolge** 1. genaue Anwendung, Zieladresse und Fehlermeldung bestimmen. 2. Zeitpunkt und letzte bekannte Funktion dokumentieren. 3. betroffene Benutzer, Clients, Netze und Standorte bestimmen. 4. Ethernet, WLAN, VPN und Proxy unterscheiden. 5. Ausgangskonfiguration sichern. 6. physische Verbindung beziehungsweise WLAN-Zustand prüfen. 7. Netzwerkadapter und Fehlerzähler untersuchen. 8. IPv4- und IPv6-Konfiguration bewerten. 9. DHCP-Zustand prüfen. 10. lokale Routingtabelle auswerten. 11. ARP beziehungsweise Neighbor Discovery kontrollieren. 12. Standardgateway und lokales Netz untersuchen. 13. entferntes Ziel gezielt per IP-Adresse testen. 14. DNS-Auflösung separat prüfen. 15. konkreten Zielport und Dienst testen. 16. Pfad bei Bedarf mit Traceroute untersuchen. 17. lokale Firewall, zentrale Firewall und ACLs berücksichtigen. 18. Proxy- und VPN-Konfiguration vergleichen. 19. System-, Netzwerk- und Serverprotokolle zeitlich korrelieren. 20. bei Bedarf eine autorisierte Paketaufzeichnung erstellen. 21. kontrollierten Vergleichstest mit nur einer Änderung durchführen. 22. Hypothese anhand der Ergebnisse bestätigen oder verwerfen. 23. freigegebene Korrektur umsetzen. 24. ursprünglichen Test wiederholen. 25. verwandte Funktionen und mögliche Nebenwirkungen prüfen. 26. Ursache, Maßnahme und Nachweis dokumentieren. --- **43. Dokumentationsbeispiel** ```text Ticket: INC-20481 Zeitpunkt: 01.08.2026, 09:18 Uhr Client: NB-204 Standort: Gebäude B, Raum 204 Anschluss: Dockingstation über Ethernet Symptom: keine internen oder externen Ziele erreichbar Ausgangszustand: - physischer Link aktiv - IPv4-Adresse 169.254.37.18/16 - kein Standardgateway - kein verwendbarer DNS-Server - WLAN deaktiviert - anderer Client an derselben Dose ebenfalls ohne DHCP-Adresse Hypothese: Der Switchport befindet sich nach dem Arbeitsplatzwechsel im falschen VLAN. Prüfung: - Portbezeichnung mit Dokumentation verglichen - tatsächliche VLAN-Zuordnung am Switch geprüft - DHCP-Verkehr im zugewiesenen VLAN kontrolliert - Port war dem Drucker-VLAN statt dem Client-VLAN zugeordnet Ursache: Fehlerhafte VLAN-Zuordnung des Switchports nach einer Portänderung. Maßnahme: Switchport nach Freigabe dem vorgesehenen Client-VLAN zugeordnet. Nachprüfung: - DHCP-Adresse aus dem vorgesehenen Clientnetz erhalten - Standardgateway und DNS-Server korrekt - internes Ziel per IP erreichbar - interne DNS-Auflösung erfolgreich - HTTPS-Anwendung erreichbar - erneute DHCP-Adressvergabe erfolgreich - Switchport und Dokumentation stimmen überein Nebenwirkungen: Keine Auffälligkeiten an benachbarten Ports oder im vorgesehenen VLAN festgestellt. ``` --- **44. Checkliste Client ohne Netzwerkverbindung** - [ ] konkrete Fehlermeldung wurde erfasst. - [ ] betroffene Anwendung und Zieladresse sind bekannt. - [ ] Beginn und letzte bekannte Funktion wurden dokumentiert. - [ ] vorausgegangene Änderungen wurden erfragt. - [ ] Umfang der Störung wurde bestimmt. - [ ] Ethernet, WLAN, VPN und Proxy wurden unterschieden. - [ ] Ausgangszustand wurde vor Änderungen gesichert. - [ ] physischer Link beziehungsweise WLAN-Status wurde geprüft. - [ ] Netzwerkadapter und Treiberstatus wurden kontrolliert. - [ ] Fehler- und Verwerfungszähler wurden geprüft. - [ ] IPv4-Adresse und Präfix wurden bewertet. - [ ] IPv6-Konfiguration wurde berücksichtigt. - [ ] Standardgateway wurde geprüft. - [ ] DNS-Server wurden dokumentiert. - [ ] DHCP-Status und Lease wurden untersucht. - [ ] ARP beziehungsweise Neighbor Discovery wurde geprüft. - [ ] Routingtabelle wurde ausgewertet. - [ ] lokales und entferntes Ziel wurden unterschieden. - [ ] Ziel wurde kontrolliert per IP-Adresse getestet. - [ ] DNS-Auflösung wurde separat getestet. - [ ] benötigter Port und Dienst wurden geprüft. - [ ] Ping-Ergebnisse wurden nicht überbewertet. - [ ] Traceroute-Ergebnisse wurden fachlich eingeordnet. - [ ] lokale Firewall wurde berücksichtigt. - [ ] zentrale Firewall und ACLs wurden berücksichtigt. - [ ] Proxykonfiguration wurde geprüft. - [ ] VPN-Routen und VPN-DNS wurden geprüft. - [ ] mehrere aktive Adapter wurden berücksichtigt. - [ ] kontrollierter Vergleichstest veränderte nur eine Komponente. - [ ] Paketaufzeichnung erfolgte nur mit Berechtigung. - [ ] Protokolle wurden anhand der Zeitstempel korreliert. - [ ] Ursache wurde von Symptom und Vermutung getrennt. - [ ] Änderung wurde freigegeben und dokumentiert. - [ ] ursprünglicher Test wurde nach der Maßnahme wiederholt. - [ ] verwandte Funktionen und Nebenwirkungen wurden geprüft. - [ ] Ursache, Maßnahme und Ergebnis wurden dokumentiert. --- **45. Schnellreferenz** | Prüfschritt | geeignete Information | typische Auffälligkeit | |---|---|---| | Umfang | betroffene Clients, Dienste und Standorte | mehrere Geräte oder nur eine Anwendung | | Verbindung | Link, SSID, Authentifizierung | Link down oder falsches WLAN | | Adapter | Zustand, Treiber, Fehlerzähler | deaktiviert, instabil oder hohe Fehler | | IPv4 | Adresse, Präfix, Gateway | `169.254.0.0/16`, falsches Netz oder kein Gateway | | IPv6 | Adresse, Route, Neighbor | nur Link-Local oder fehlende Standardroute | | DHCP | Server, Lease, Optionen | kein Offer, falsche Optionen oder erschöpfter Bereich | | Layer 2 | ARP, Neighbor, VLAN | unvollständiger Eintrag oder falsches VLAN | | Routing | Route, Gateway, Metrik | falsche oder fehlende Route | | DNS | Server, Antwort, Record | Timeout, `NXDOMAIN` oder falsche Adresse | | Transport | Zielport und TCP-Zustand | Timeout, RST oder TLS-Fehler | | Firewall | Regel und Protokoll | Blockierung der tatsächlichen Quelle oder Zone | | Proxy | PAC, Authentifizierung, Ausnahme | Browser betroffen, andere Tests erfolgreich | | VPN | Routen, DNS und MTU | Netzüberlappung oder falsches Split Tunneling | | Zielsystem | Dienst und Protokoll | Port geschlossen oder Anwendung fehlerhaft | | Nachprüfung | ursprünglicher Test | Symptom beseitigt und keine Nebenwirkungen | --- **Merksatz** > „Kein Netzwerk“ ist keine Ursache, sondern eine ungenaue Symptombeschreibung. Eine belastbare Analyse bestimmt zuerst den Umfang und prüft anschließend kontrolliert Verbindung, Adapter, IP-Konfiguration, DHCP, lokales Netz, Gateway, Routing, DNS, Zielport und Anwendung. Jeder erfolgreiche Test bestätigt nur den tatsächlich geprüften Teil des Kommunikationswegs. --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Get-NetIPConfiguration](https://learn.microsoft.com/powershell/module/nettcpip/get-netipconfiguration) - [Microsoft Learn – Get-NetAdapter](https://learn.microsoft.com/powershell/module/netadapter/get-netadapter) - [Microsoft Learn – Get-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/get-netroute) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Windows-Befehle für TCP/IP-Diagnose](https://learn.microsoft.com/windows-server/administration/windows-commands/windows-commands) - [Red Hat – NetworkManager mit nmcli verwalten](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_networking/) - [Apple – networksetup Manual Page](https://ss64.com/mac/networksetup.html) - [Wireshark – Benutzerhandbuch](https://www.wireshark.org/docs/wsug_html_chunked/) - [Wireshark – Display Filter Reference](https://www.wireshark.org/docs/dfref/) - [RFC 2131 – Dynamic Host Configuration Protocol](https://www.rfc-editor.org/rfc/rfc2131) - [RFC 3927 – Dynamic Configuration of IPv4 Link-Local Addresses](https://www.rfc-editor.org/rfc/rfc3927) - [RFC 8200 – Internet Protocol, Version 6](https://www.rfc-editor.org/rfc/rfc8200) - [RFC 4861 – Neighbor Discovery for IPv6](https://www.rfc-editor.org/rfc/rfc4861) - [RFC 826 – Address Resolution Protocol](https://www.rfc-editor.org/rfc/rfc826) - [RFC 1034 – Domain Names: Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034) - [RFC 1035 – Domain Names: Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035) # 6.2 Mehrere Clients oder ganzer Standort ohne Netzwerk Wenn mehrere Clients, eine Abteilung, ein Stockwerk, ein Gebäude oder ein kompletter Standort gleichzeitig keine Netzwerkverbindung besitzen, ist ein unabhängiger Fehler an jedem einzelnen Endgerät unwahrscheinlich. Der gemeinsame Ausfallbereich rückt in den Mittelpunkt. Mögliche gemeinsame Komponenten sind: - Access Switch, - Switch-Uplink, - VLAN, - WLAN-SSID, - Access Point oder WLAN-Controller, - Standardgateway, - DHCP-Dienst, - DNS-Dienst, - Firewall, - Router, - WAN-Verbindung, - VPN-Tunnel, - Internetanschluss, - Stromversorgung, - zentrale Authentifizierung, - Netzwerkzugangskontrolle, - Providerverbindung, - gemeinsame Konfigurationsänderung. Das Ziel der Fehleranalyse besteht darin, den kleinsten gemeinsamen Ausfallbereich zu bestimmen und anschließend die darin enthaltenen Komponenten kontrolliert zu prüfen. > Je mehr Systeme gleichzeitig betroffen sind, desto wichtiger ist die Frage, welche technische Komponente oder Abhängigkeit sie gemeinsam verwenden. --- **1. Mehrere betroffene Clients verändern die Fehlerhypothese** Bei einem einzelnen betroffenen Client sind lokale Ursachen besonders wahrscheinlich: - Netzwerkkabel, - Netzwerkadapter, - Dockingstation, - lokale IP-Konfiguration, - lokaler Treiber, - lokale Firewall, - Betriebssystem, - Benutzerprofil. Bei mehreren gleichzeitig betroffenen Clients werden gemeinsame Ursachen wahrscheinlicher: - gemeinsamer Switch, - gemeinsamer Uplink, - gemeinsames VLAN, - gemeinsames Gateway, - gemeinsamer DHCP-Server, - gemeinsamer DNS-Server, - gemeinsamer WLAN-Bereich, - gemeinsame Firewall, - gemeinsame Standortanbindung, - gemeinsame Änderung. Lokale Clienttests bleiben wichtig. Sie dienen nun jedoch vor allem dazu, den gemeinsamen Fehlerumfang zu bestätigen und Unterschiede zwischen funktionierenden und nicht funktionierenden Bereichen zu erkennen. --- **2. Störungsumfang exakt bestimmen** Die Aussage „Der Standort hat kein Netzwerk“ ist zunächst nur eine ungenaue Symptombeschreibung. Zu klären sind: - Wie viele Benutzer melden den Fehler? - Wie viele Clients wurden tatsächlich geprüft? - Sind alle Geräte oder nur einzelne Gerätetypen betroffen? - Betrifft der Fehler Ethernet, WLAN oder beide? - Sind Drucker, Telefone, Kameras und andere Netzwerkgeräte betroffen? - Betrifft der Fehler nur einen Raum? - Betrifft er eine Etage? - Betrifft er ein Gebäude? - Betrifft er ein VLAN? - Betrifft er eine bestimmte SSID? - Betrifft er einen kompletten Standort? - Sind weitere Standorte betroffen? - Funktionieren interne Ziele? - Funktioniert das Internet? - Funktioniert die Namensauflösung? - Sind nur einzelne Anwendungen ausgefallen? - Können bestehende Verbindungen weiterarbeiten? - Scheitern nur neue Verbindungen? - Ist der Ausfall vollständig oder treten Paketverluste und Unterbrechungen auf? Eine belastbare Aussage lautet beispielsweise: ```text Seit etwa 09:17 Uhr können alle bisher geprüften kabelgebundenen Clients der dritten Etage weder das Standardgateway noch interne Dienste erreichen. WLAN-Clients derselben Etage funktionieren. Andere Etagen sind nicht betroffen. ``` Diese Beschreibung grenzt den Fehler erheblich stärker ein als „Netzwerk ausgefallen“. --- **3. Betroffenheitsmatrix erstellen** Eine einfache Matrix hilft, Gemeinsamkeiten zu erkennen. | Bereich | Ethernet | WLAN | interne Dienste | Internet | DNS | |---|---:|---:|---:|---:|---:| | Etage 1 | funktioniert | funktioniert | funktioniert | funktioniert | funktioniert | | Etage 2 | funktioniert | funktioniert | funktioniert | funktioniert | funktioniert | | Etage 3 | ausgefallen | funktioniert | ausgefallen | ausgefallen | nicht sinnvoll prüfbar | | Etage 4 | funktioniert | funktioniert | funktioniert | funktioniert | funktioniert | Aus diesem Beispiel ergibt sich: - kein standortweiter Ausfall, - kein allgemeiner Internet- oder DNS-Ausfall, - kein vollständiger Ausfall des zentralen Gateways, - wahrscheinlicher Fehler im kabelgebundenen Zugangsnetz der dritten Etage, - möglicher Access-Switch-, Uplink-, VLAN- oder Stromversorgungsfehler. Eine solche Matrix sollte nicht nur auf Benutzerangaben beruhen. Repräsentative Tests müssen die Angaben bestätigen. --- **4. Zeitpunkt und zeitlichen Verlauf ermitteln** Zu dokumentieren sind: - erster bekannter Fehlerzeitpunkt, - letzte bekannte fehlerfreie Nutzung, - gleichzeitiger oder schrittweiser Ausfall, - dauerhafter oder sporadischer Fehler, - Zeitpunkt automatischer Monitoringmeldungen, - Zeitpunkt letzter Änderungen, - Zeitpunkt von Strom-, Klima- oder Providerereignissen, - Wiederkehr in bestimmten Zeitabständen, - Abhängigkeit von Last oder Benutzeranzahl. **Mögliche zeitliche Muster** | Beobachtung | mögliche Einordnung | |---|---| | alle Clients fallen gleichzeitig aus | gemeinsame zentrale Komponente oder Verbindung | | Clients fallen nacheinander aus | DHCP-Leases, instabiler Switch, Schleife, Überlastung oder Stromproblem | | nur morgens bei Arbeitsbeginn | DHCP-Bereich, Authentifizierung, WLAN-Kapazität oder Lastproblem | | kurze Ausfälle in regelmäßigen Abständen | Redundanzumschaltung, instabiler Link, Routingprozess oder geplante Aufgabe | | Fehler direkt nach Änderung | Änderung als starke Hypothese untersuchen | | Fehler bei hoher Netzlast | Überlastung, Broadcast-Sturm, fehlerhafter Link oder Kapazitätsgrenze | | Fehler nach Stromunterbrechung | Gerät, Netzteil, USV, Startreihenfolge oder nicht gespeicherte Konfiguration | Zeitliche Nähe beweist noch keine Ursache. Sie legt jedoch eine gezielte Prüfreihenfolge nahe. --- **5. Letzte Änderungen prüfen** Vor einer Änderung am Netzwerk ist zu prüfen, ob kurz vor Beginn der Störung etwas verändert wurde. Mögliche Änderungen sind: - Switch-Konfiguration, - VLAN-Zuordnung, - Trunk-Konfiguration, - Spanning-Tree-Konfiguration, - Link Aggregation, - Routing, - Firewallregeln, - NAT, - DHCP-Bereich, - DHCP-Relay, - DNS-Konfiguration, - WLAN-Controller, - Access-Point-Firmware, - Netzwerkzugangskontrolle, - Zertifikate, - Provideranschluss, - Verkabelung, - Patchfeld, - Stromversorgung, - Server- oder Netzwerkupdate, - Wartungsarbeiten, - Umzug von Geräten, - Anschluss eines neuen Switches, - Anschluss eines nicht autorisierten Geräts. Zu jeder Änderung gehören: - genauer Zeitpunkt, - verantwortliche Person oder System, - betroffene Komponenten, - erwartete Wirkung, - dokumentierter Ausgangszustand, - mögliche Rückfallmaßnahme, - tatsächliche Protokolleinträge. > Ein zeitlicher Zusammenhang macht eine Änderung verdächtig, ersetzt aber nicht den technischen Nachweis. --- **6. Priorität und Auswirkung bewerten** Ein Ausfall mehrerer Clients kann ein Major Incident sein, muss es aber nicht automatisch sein. Zu bewerten sind: - Anzahl betroffener Benutzer, - betroffene Geschäftsprozesse, - betroffene Standorte, - verfügbare Ausweichmöglichkeiten, - Sicherheitsauswirkungen, - Produktionsstillstand, - Ausfall kritischer Dienste, - vertragliche Verpflichtungen, - erwartete Dauer, - Gefahr einer Ausweitung, - Abhängigkeit externer Kunden oder Partner. **Beispielhafte Einordnung** | Situation | mögliche Auswirkung | |---|---| | ein Besprechungsraum ohne Netzwerk | lokal begrenzt | | gesamtes Stockwerk ohne Netzwerk | erhebliche Benutzerbeeinträchtigung | | Produktionsnetz ausgefallen | geschäftskritisch | | Standort ohne WAN, lokale Systeme funktionieren | standortübergreifende Dienste betroffen | | DNS unternehmensweit ausgefallen | sehr großer scheinbarer Netzwerkausfall | | redundanter Uplink ausgefallen, Verkehr läuft weiter | noch kein Benutzerausfall, aber Redundanz verloren | Die Priorität richtet sich nach Auswirkung und Dringlichkeit, nicht allein nach der Anzahl eingehender Tickets. --- **7. Kommunikation während einer größeren Störung** Bei einer größeren Störung müssen technische Analyse und Kommunikation parallel organisiert werden. Sinnvolle Aufgabenverteilung: - technische Koordination, - Prüfung des Zugangsnetzes, - Prüfung zentraler Dienste, - Prüfung von Firewall, WAN und Provider, - Dokumentation der Ereignisse, - Kommunikation mit Benutzern und Verantwortlichen, - Koordination externer Dienstleister. Eine Statusmeldung sollte enthalten: ```text Bekannter Umfang: Kabelgebundene Clients in Gebäude B sind betroffen. WLAN und andere Gebäude funktionieren. Beginn: Etwa 09:17 Uhr. Aktueller Stand: Der gemeinsame Uplink des Access-Bereichs wird geprüft. Nächste Aktualisierung: 10:00 Uhr oder bei einer wesentlichen Änderung. ``` Nicht bestätigt werden sollten Aussagen wie: - „Der Provider ist schuld.“ - „Die Firewall ist abgestürzt.“ - „Das Problem ist gleich behoben.“ - „Es gehen keine Daten verloren.“ Solche Aussagen dürfen erst erfolgen, wenn belastbare Nachweise vorliegen. --- **8. Repräsentative Testpunkte auswählen** Nicht jeder einzelne Client muss vollständig untersucht werden. Es werden gezielt Testpunkte ausgewählt. Geeignete Auswahl: - ein betroffener Client aus jedem gemeldeten Bereich, - ein funktionierender Client aus einem benachbarten Bereich, - ein kabelgebundener und ein drahtloser Client, - ein Client im gleichen VLAN, - ein Client in einem anderen VLAN, - ein infrastrukturelles Gerät im betroffenen Bereich, - ein Test direkt am Access Switch, - ein Test hinter dem vermuteten Uplink, - ein Test am zentralen Standort. **Beispiel** ```text Client A: Etage 3, Switch 3A, VLAN 120 → betroffen Client B: Etage 3, Switch 3B, VLAN 120 → betroffen Client C: Etage 3, WLAN, VLAN 220 → funktioniert Client D: Etage 2, VLAN 120 → funktioniert ``` Damit liegt der Verdacht nicht automatisch beim gesamten VLAN 120. Wahrscheinlicher ist zunächst eine Komponente, die nur die kabelgebundene Versorgung der dritten Etage betrifft. --- **9. Gemeinsame Abhängigkeiten abbilden** Für die betroffenen Clients sollte der Kommunikationsweg vereinfacht dargestellt werden. ```text Clients → Access Switch → Uplink → Distribution Switch → VLAN-Gateway → Firewall oder Router → WAN beziehungsweise Internet → Zielsystem ``` Für WLAN kann der Weg abweichen: ```text WLAN-Client → Access Point → Access Switch → WLAN-Controller oder lokales Switching → VLAN-Gateway → Firewall oder Router → Zielsystem ``` Für jeden Abschnitt wird geprüft: - Nutzen alle betroffenen Clients diese Komponente? - Nutzen funktionierende Clients dieselbe Komponente? - Ist die Komponente erreichbar? - Sind Fehler oder Zustandsänderungen protokolliert? - Besteht eine redundante Verbindung? - Arbeitet die Redundanz tatsächlich? - Wurde die Konfiguration verändert? --- **10. Ausfallbereich durch funktionierende Grenzen bestimmen** Nicht nur fehlgeschlagene Tests sind wichtig. Funktionierende Bereiche bilden Grenzen des Fehlers. **Beispiel** ```text Clients an Switch A → ausgefallen Clients an Switch B → funktionieren beide verwenden dasselbe Gateway beide verwenden dieselben DNS-Server beide verwenden dieselbe Firewall ``` Dadurch werden Gateway, DNS und Firewall als alleinige gemeinsame Ursache weniger wahrscheinlich. Der Untersuchungsbereich verschiebt sich zu: - Switch A, - dessen Uplink, - dessen VLAN-Weiterleitung, - dessen Stromversorgung, - dessen lokale Verkabelung. Ein funktionierender Bereich schließt eine Komponente allerdings nur dann sinnvoll aus, wenn tatsächlich dieselbe Instanz, derselbe Pfad und dieselbe Konfiguration verwendet werden. --- **11. Stromversorgung und Umgebungsbedingungen prüfen** Ein Netzwerkausfall kann durch einen Strom- oder Umgebungsfehler verursacht werden. Zu prüfen sind: - besitzt der Netzwerkschrank Strom? - ist die USV aktiv? - bestehen USV-Alarme? - sind Sicherungen ausgelöst? - funktionieren Netzteile und redundante Netzteile? - sind Power Distribution Units aktiv? - ist der Switch vollständig gestartet? - bestehen Temperaturalarme? - funktioniert die Kühlung? - wurden Geräte versehentlich ausgeschaltet? - sind PoE-Verbraucher ausgefallen? - wurde das Strombudget überschritten? - gibt es auffälligen Geruch, Hitze oder Geräusche? Bei ausgefallener PoE-Versorgung können gleichzeitig betroffen sein: - Access Points, - IP-Telefone, - Kameras, - Zutrittskomponenten, - Sensoren. Ein aktiver Switch kann weiterhin ein PoE-Problem besitzen. Deshalb müssen Datenverkehr und Stromversorgung getrennt bewertet werden. --- **12. Physische Infrastruktur prüfen** Bei mehreren betroffenen Clients sind besonders gemeinsame physische Komponenten zu untersuchen: - Access Switch, - Switch-Uplink, - Glasfaserstrecke, - Kupfer-Uplink, - Patchkabel, - Patchfeld, - Transceiver, - Medienkonverter, - Stack-Kabel, - Modul oder Line Card, - Gebäudeverkabelung. Mögliche Hinweise: - Uplink ohne Link, - Link wechselt zwischen Up und Down, - hohe Anzahl CRC-Fehler, - Eingabefehler, - Verwerfungen, - fehlerhafte Transceiverwerte, - nur eine Richtung funktioniert, - ungewöhnlich niedrige ausgehandelte Geschwindigkeit, - Port befindet sich im Fehlerzustand, - Switch-Mitglied fehlt aus einem Stack, - Line Card ist ausgefallen. **Typische Zähler** | Zähler oder Zustand | mögliche Bedeutung | |---|---| | CRC-Fehler | physische Übertragungsfehler, Kabel, Stecker oder Transceiver | | Input Errors | unterschiedliche Empfangsfehler | | Output Drops | Warteschlange oder Überlastung | | Link Flaps | instabile Verbindung oder Komponente | | administratively down | Schnittstelle wurde deaktiviert | | err-disabled | Schutzfunktion oder erkannter Fehler | | keine optische Empfangsleistung | Glasfaser, Transceiver oder Gegenstelle | | viele Interface-Resets | instabiler Port, Treiber oder Hardware | Zähler müssen zusammen mit Laufzeit, Verkehrsmenge und Änderungsrate bewertet werden. Ein historischer Fehlerzähler beweist keinen aktuellen Defekt. --- **13. Access Switch prüfen** Zu einem betroffenen Access Switch sollten mindestens folgende Informationen erhoben werden: - Erreichbarkeit des Managements, - Betriebszeit, - letzter Neustart, - CPU-Auslastung, - Speicherauslastung, - Temperatur, - Netzteilstatus, - Stack-Status, - Uplink-Status, - Fehlerzähler, - VLAN-Zustand, - Spanning-Tree-Zustand, - MAC-Adresstabelle, - Port-Sicherheitszustände, - PoE-Status, - Systemprotokolle, - aktuelle Konfiguration, - letzte Konfigurationsänderung. Mögliche Befehle hängen von Hersteller und Betriebssystem ab. Bei Cisco-IOS-ähnlichen Systemen können beispielsweise relevant sein: ```text show interfaces status show interfaces counters errors show interfaces show logging show vlan brief show interfaces trunk show spanning-tree show etherchannel summary show mac address-table show power inline show environment show switch show version ``` Diese Befehle sind Beispiele. Syntax und Verfügbarkeit müssen anhand der Dokumentation des eingesetzten Geräts geprüft werden. --- **14. Uplink und Trunk untersuchen** Ein Access Switch kann erreichbar sein, während Nutzdaten wegen eines fehlerhaften Uplinks oder Trunks nicht korrekt übertragen werden. Zu prüfen sind: - physischer Linkstatus, - Geschwindigkeit und Duplex, - erlaubte VLANs, - native beziehungsweise untagged VLAN-Zuordnung, - Trunk-Modus, - VLAN-Pruning, - Gegenstellenkonfiguration, - Fehlerzähler, - Spanning-Tree-Zustand, - Link Aggregation, - Port-Sicherheitsmechanismen, - MTU, - einseitige Konfigurationsänderung. **Typische Fehler** - benötigtes VLAN nicht auf dem Trunk erlaubt, - VLAN nur auf einer Seite konfiguriert, - falsches untagged VLAN, - Uplink als Access-Port konfiguriert, - Trunk nach Änderung nicht vollständig übernommen, - Port durch Spanning Tree blockiert, - Mitglied einer Link Aggregation fehlerhaft, - Transceiver oder Faser gestört, - Uplink physisch aktiv, aber Datenverkehr verworfen. > Ein aktiver Link bestätigt weder eine korrekte Trunk-Konfiguration noch die Weiterleitung aller benötigten VLANs. --- **15. VLAN-Zuordnung prüfen** Wenn nur bestimmte Benutzergruppen oder Netzsegmente betroffen sind, ist die VLAN-Konfiguration ein zentraler Prüfpunkt. Zu prüfen sind: - existiert das VLAN auf allen notwendigen Switches? - sind Access-Ports dem richtigen VLAN zugeordnet? - wird das VLAN über alle erforderlichen Trunks transportiert? - besitzt das VLAN ein aktives Gateway? - ist DHCP beziehungsweise DHCP-Relay für dieses VLAN erreichbar? - blockieren Sicherheitsfunktionen den Verkehr? - stimmen Voice- und Data-VLAN? - bestehen dynamische VLAN-Zuweisungen? - verwendet die Netzwerkzugangskontrolle das erwartete VLAN? - wurde das VLAN umbenannt, gelöscht oder neu nummeriert? **Mögliche Beobachtungen** | Beobachtung | mögliche Einordnung | |---|---| | nur ein VLAN betroffen | VLAN-Pfad, Gateway, DHCP oder Richtlinie | | mehrere VLANs desselben Switches betroffen | Switch oder gemeinsamer Uplink | | VLAN funktioniert auf anderen Switches | lokaler Trunk oder Access Switch | | Clients erhalten Adresse aus falschem Netz | falsche VLAN-Zuordnung oder unerwarteter DHCP-Server | | statisch konfigurierte Clients funktionieren, DHCP-Clients nicht | DHCP-Pfad oder DHCP-Dienst | | Gateway im VLAN nicht per ARP erreichbar | Layer-2-Pfad, Gateway oder VLAN-Zuordnung | --- **16. Spanning Tree und Netzwerkschleifen** Spanning Tree verhindert Layer-2-Schleifen in redundanten Ethernet-Netzen. Fehlerhafte Verkabelung oder Konfiguration kann dennoch zu einer Schleife oder instabilen Topologie führen. Mögliche Symptome: - sehr hohe Broadcast-Last, - stark schwankende MAC-Adresstabellen, - MAC-Adressen erscheinen abwechselnd an verschiedenen Ports, - hohe CPU-Auslastung auf Switches, - Paketverluste, - langsame oder vollständig ausfallende Verbindungen, - häufige Topology Changes, - Managementzugriff nur sporadisch möglich, - mehrere Bereiche gleichzeitig betroffen, - Ausfall nach Anschluss eines kleinen Switches oder neuen Kabels. Zu prüfen sind: - Root Bridge, - blockierende und weiterleitende Ports, - letzte Topology Changes, - Anzahl der Topology Changes, - unerwartete Root-Bridge-Änderung, - BPDU Guard, - Root Guard, - Loop Guard, - PortFast beziehungsweise Edge-Port-Konfiguration, - neu angeschlossene Switches, - doppelte Verkabelung. > Bei Verdacht auf eine Schleife dürfen nicht wahllos Verbindungen getrennt werden. Zuerst müssen Topologie, betroffene Ports und aktuelle Zustände soweit möglich dokumentiert werden. --- **17. Link Aggregation und LACP prüfen** Mehrere physische Verbindungen können zu einer logischen Verbindung zusammengefasst sein. Zu prüfen sind: - sind alle erwarteten Mitglieder aktiv? - befinden sich beide Seiten in derselben Aggregation? - stimmen LACP-Modus und Parameter? - verwenden alle Mitglieder identische VLAN- und Trunk-Einstellungen? - bestehen einzelne suspendierte oder nicht gebündelte Ports? - ist die Hash-Verteilung auffällig? - funktionieren bestimmte Verbindungen nur über ein einzelnes fehlerhaftes Mitglied? - ist bei einem Gerätetausch eine alte Konfiguration verblieben? Mögliche Symptome: - nur einige Verbindungen funktionieren, - bestimmte Quell-Ziel-Kombinationen scheitern, - Paketverluste treten abhängig vom Verkehrsfluss auf, - Durchsatz ist deutlich reduziert, - Redundanz ist verloren, - MAC-Adressen wechseln unerwartet, - ein Mitglied leitet außerhalb des Bündels weiter. --- **18. Gateway und First-Hop-Redundanz prüfen** Das Gateway eines VLANs kann physisch oder logisch ausgefallen sein. Zu prüfen sind: - ist die Gateway-Schnittstelle aktiv? - ist die virtuelle Gateway-Adresse vorhanden? - antwortet das Gateway auf ARP beziehungsweise Neighbor Discovery? - besitzen Clients den richtigen Gateway-Eintrag? - ist die Gateway-MAC-Adresse plausibel? - ist die Routingfunktion aktiv? - besteht die verbundene Route? - funktionieren andere VLANs auf demselben Gerät? - bestehen CPU-, Speicher- oder Hardwareprobleme? - funktioniert ein redundantes Gatewaypaar? - stimmen aktive und passive Rollen? - trat ein Rollenwechsel auf? - besteht ein Split-Brain- oder Dual-Active-Zustand? - wird der Rückweg korrekt geroutet? Bei Redundanzprotokollen wie HSRP oder VRRP muss nicht nur der Gerätezustand, sondern auch die tatsächliche Erreichbarkeit der virtuellen Adresse geprüft werden. Eine als aktiv gemeldete Redundanzrolle beweist nicht automatisch, dass: - die Datenebene funktioniert, - alle VLANs übertragen werden, - die Upstream-Verbindung erreichbar ist, - der Rückweg vorhanden ist. --- **19. DHCP bei mehreren betroffenen Clients prüfen** Wenn viele Clients keine verwendbare IP-Konfiguration erhalten, kann eine gemeinsame DHCP-Störung vorliegen. Mögliche Symptome: - Adressen aus `169.254.0.0/16`, - kein Standardgateway, - fehlende DNS-Server, - alte Leases funktionieren noch, - neue Clients erhalten keine Adresse, - Clients erhalten Adressen aus dem falschen Netz, - Fehler beginnt bei hoher Benutzeranzahl, - nur ein bestimmtes VLAN ist betroffen. Zu prüfen sind: - läuft der DHCP-Dienst? - ist der DHCP-Server erreichbar? - ist der richtige Bereich aktiv? - sind freie Adressen vorhanden? - stimmen Subnetzmaske, Gateway und DNS-Optionen? - funktioniert DHCP-Relay? - ist die Relay-Adresse korrekt? - wird DHCP durch ACLs oder Firewalls blockiert? - besteht DHCP Snooping? - sind vertrauenswürdige Ports korrekt festgelegt? - antwortet ein unerwünschter DHCP-Server? - funktionieren redundante DHCP-Server? - stimmt der Failover-Zustand? - erreichen Discover-Pakete den Server? - erreicht das Offer den Client? **DHCP-Ablauf** ```text Client → DHCP Discover Server → DHCP Offer Client → DHCP Request Server → DHCP Acknowledgement ``` **Mögliche Beobachtungen** | Beobachtung | mögliche Einordnung | |---|---| | kein Discover sichtbar | Client, Access-Port, VLAN oder Aufzeichnungsstelle | | Discover im VLAN, aber nicht am Server | Relay, Routing, ACL oder VLAN-Pfad | | Discover erreicht Server, kein Offer | Dienst, Bereich, Richtlinie oder Adressmangel | | Offer verlässt Server, erreicht Client nicht | Rückweg, Relay, Snooping oder Layer 2 | | falscher Server antwortet | Rogue DHCP oder falscher gemeinsamer Layer-2-Bereich | | alte Clients funktionieren, neue nicht | erschöpfter Bereich oder gestörter Vergabeprozess | --- **20. DNS-Ausfall nicht mit vollständigem Netzwerkausfall verwechseln** Ein zentraler DNS-Ausfall kann bei vielen Benutzern den Eindruck erzeugen, das Netzwerk sei vollständig ausgefallen. Typische Beobachtungen: - Ziele sind per IP-Adresse erreichbar, - Namen können nicht aufgelöst werden, - bereits bestehende Sitzungen funktionieren teilweise weiter, - Anwendungen mit zwischengespeicherten Adressen funktionieren, - Anmeldungen und Active-Directory-Funktionen scheitern, - interne und externe Namen verhalten sich unterschiedlich. Zu prüfen sind: - Erreichbarkeit der DNS-Server per IP, - DNS-Dienstzustand, - Abfrage eines bekannten internen Namens, - Abfrage eines bekannten externen Namens, - Antwort jedes konfigurierten DNS-Servers, - Rekursion, - Weiterleitungen, - Zonen, - Replikation, - DNSSEC, sofern eingesetzt, - Firewallregeln für UDP und TCP Port 53, - ausgegebene DHCP-DNS-Optionen, - Split-DNS, - Standort- oder VPN-spezifische DNS-Server. **Windows** ```powershell Resolve-DnsName Resolve-DnsName -Server Get-DnsClientServerAddress ``` **Linux und macOS** ```bash dig dig @ ``` > Ein DNS-Fehler betrifft die Namensauflösung. Er beweist keinen Ausfall der zugrunde liegenden IP-Verbindung. --- **21. Netzwerkzugangskontrolle und Authentifizierung** In Unternehmensnetzen kann der Netzwerkzugang von einer Authentifizierung oder Autorisierung abhängen. Mögliche Komponenten: - IEEE 802.1X, - RADIUS, - Network Access Control, - Zertifikatsdienste, - Geräteidentifikation, - dynamische VLAN-Zuweisung, - Quarantäne-VLAN, - MAC Authentication Bypass, - Port-Security. Mögliche Symptome: - viele Ports wechseln gleichzeitig in einen nicht autorisierten Zustand, - Clients erhalten ein Quarantäne-VLAN, - kabelgebundene und drahtlose Anmeldungen scheitern, - neue Verbindungen scheitern, bestehende funktionieren, - Fehler beginnt nach Ablauf eines Zertifikats, - RADIUS-Server ist nicht erreichbar, - Uhrzeitabweichungen verhindern die Zertifikatsprüfung, - eine Richtlinienänderung betrifft ganze Gerätegruppen. Zu prüfen sind: - Status des Authentifizierungsdienstes, - Erreichbarkeit der RADIUS-Server, - Zertifikatsgültigkeit, - Systemzeit, - Richtlinienänderungen, - Switch- und Controllerprotokolle, - Ablehnungsgrund, - zugewiesenes VLAN, - Failover auf einen zweiten Authentifizierungsserver. --- **22. WLAN als eigene Fehlerdomäne untersuchen** Wenn mehrere WLAN-Clients betroffen sind, müssen Funk-, Zugangs- und zentrale WLAN-Komponenten getrennt geprüft werden. Zu prüfen sind: - ist die SSID sichtbar? - können Clients sich verbinden? - funktioniert die Authentifizierung? - erhalten sie eine IP-Adresse? - betrifft es einen Access Point oder mehrere? - betrifft es ein Frequenzband? - betrifft es eine SSID? - betrifft es einen Standort? - sind Access Points beim Controller registriert? - besitzen Access Points Strom und Uplink? - ist das vorgesehene VLAN verfügbar? - funktioniert DHCP? - besteht ausreichende Funkabdeckung? - gibt es starke Störungen? - ist die Clientanzahl ungewöhnlich hoch? - funktionieren Roaming und Controller-Kommunikation? - wurde Firmware oder Konfiguration geändert? **Abgrenzung** | Beobachtung | mögliche Einordnung | |---|---| | SSID nicht sichtbar | Access Point, Funkmodul, Controller oder SSID-Konfiguration | | SSID sichtbar, Anmeldung scheitert | Authentifizierung, Zertifikat, RADIUS oder Kennwort | | Anmeldung erfolgreich, keine IP-Adresse | VLAN, DHCP oder Tunnel | | IP-Adresse vorhanden, Gateway nicht erreichbar | VLAN-Pfad, Gateway oder Client-Isolation | | nur ein Access Point betroffen | AP, Uplink, PoE oder lokale Funkumgebung | | alle APs eines Standorts betroffen | Controllerpfad, Standort-Uplink, DHCP oder gemeinsame Konfiguration | | nur ein Frequenzband betroffen | Funkkonfiguration, Radarereignis oder Hardware | --- **23. Firewall, ACL und zentrale Sicherheitskomponenten** Ein gemeinsamer Filterfehler kann viele Clients oder ganze Netze betreffen. Zu prüfen sind: - tatsächliche Quellnetze, - Zielnetze, - Protokolle und Ports, - verwendete Sicherheitszone, - Regelreihenfolge, - Regeländerungen, - NAT, - Sitzungszustände, - Hochverfügbarkeitsstatus, - Routing auf der Firewall, - Schnittstellenstatus, - Ressourcenverbrauch, - Lizenz- oder Zertifikatsstatus, - Protokolle zum Fehlerzeitpunkt, - IPv4- und IPv6-Regeln, - Rückweg. **Mögliche Symptome** | Beobachtung | mögliche Einordnung | |---|---| | interne Kommunikation funktioniert, Internet nicht | Firewall, NAT, WAN oder Provider | | nur ein VLAN erreicht das Internet nicht | Zone, Regel, NAT oder Route | | neue Verbindungen scheitern, bestehende funktionieren | Sitzungsgrenze, Zustandsübergang oder Regeländerung | | nur HTTPS scheitert | Filter, Proxy, TLS-Inspektion oder Zertifikat | | aktive Firewall meldet fehlerfreien Zustand, Verkehr fällt aus | Datenebene, Route, Schnittstelle oder Clusterzustand | | nach Failover tritt Fehler auf | unsynchronisierte Zustände, Route, NAT oder Konfiguration | Eine Firewall sollte während einer größeren Störung nicht pauschal deaktiviert werden. Regeln und Protokolle müssen gezielt untersucht werden. --- **24. Routing und Rückweg prüfen** Wenn mehrere Netze betroffen sind, ist die Routingstruktur zu untersuchen. Zu prüfen sind: - verbundene Netze, - statische Routen, - dynamische Routingnachbarschaften, - Standardroute, - spezifische Zielrouten, - Routenauswahl, - Metrik beziehungsweise administrative Distanz, - Policy-based Routing, - VRF, - Route Redistribution, - zusammengefasste Routen, - Rückroute, - asymmetrisches Routing, - kürzlich zurückgezogene Präfixe. **Mögliche Beobachtungen** - Gateway ist erreichbar, entfernte Netze nicht. - Einige Zielnetze funktionieren, andere nicht. - Verkehr verlässt den Standort, Antworten kommen nicht zurück. - Nach einem Failover wird ein falscher Pfad gewählt. - Eine spezifische Route fehlt, während die Standardroute besteht. - Ein Standortpräfix wird nicht mehr angekündigt. - Dieselben Adressbereiche werden an mehreren Stellen verwendet. > Ein erfolgreicher Hinweg reicht nicht aus. Ende-zu-Ende-Kommunikation benötigt grundsätzlich auch einen funktionsfähigen Rückweg. --- **25. WAN- und Standortverbindung prüfen** Wenn lokale Kommunikation funktioniert, aber zentrale Systeme oder andere Standorte nicht erreichbar sind, liegt der Untersuchungsbereich häufig bei der Standortanbindung. Mögliche Verbindungen: - MPLS, - SD-WAN, - Site-to-Site-VPN, - Standleitung, - Metro Ethernet, - Internet-VPN, - Mobilfunk-Fallback, - direkte Cloud-Verbindung. Zu prüfen sind: - physischer WAN-Link, - Providerübergabe, - WAN-IP-Konfiguration, - Tunnelzustand, - Routingnachbarschaften, - Latenz, - Paketverlust, - Jitter, - MTU, - Verschlüsselungsstatus, - Zertifikate, - aktive und passive Leitungen, - automatische Umschaltung, - tatsächlicher Datenpfad, - Providerstörungsmeldungen. **Abgrenzung** ```text lokales Gateway erreichbar → lokaler Server erreichbar → zentraler Server nicht erreichbar → Internet erreichbar ``` Dies spricht eher für: - ausgefallenen Standorttunnel, - fehlende Route, - zentrale Firewallregel, - Rückwegproblem, - Ausfall des zentralen Ziels. Es spricht nicht für einen vollständigen lokalen Netzwerkausfall. --- **26. Internet- oder Providerstörung prüfen** Ein Provider sollte erst dann als Ursache benannt werden, wenn der lokale Verantwortungsbereich ausreichend geprüft wurde. Vor einer Eskalation sollten dokumentiert sein: - Kundennummer oder Anschlusskennung, - betroffener Standort, - Beginn der Störung, - Art des Anschlusses, - Status des Providerübergabegeräts, - physischer Link, - WAN-Adresse, - Erreichbarkeit des nächsten Provider-Hops, sofern testbar, - Paketverlust und Laufzeit, - Verhalten einer Ersatzverbindung, - lokale Router- und Firewallzustände, - bereits durchgeführte Tests, - relevante Protokolle. Ein fehlgeschlagener Ping auf einen Providerrouter beweist keinen Ausfall, da ICMP gefiltert sein kann. Eine erfolgreiche Mobilfunk- oder Ersatzverbindung zeigt, dass die Anwendung und das Ziel grundsätzlich funktionieren können. Sie beweist aber nicht allein, an welcher Stelle der ursprüngliche Anschluss fehlerhaft ist. --- **27. Redundanz und Failover nicht voraussetzen** Vorhandene Redundanz bedeutet nicht automatisch, dass ein Ausfall ohne Unterbrechung abgefangen wird. Zu prüfen sind: - ist die Ersatzkomponente tatsächlich betriebsbereit? - wird ihr Zustand überwacht? - sind Konfigurationen synchron? - existieren gültige Routen? - funktioniert die Umschaltung? - wird die Datenebene geprüft oder nur der Linkstatus? - bestehen gültige Lizenzen und Zertifikate? - reicht die Kapazität der Ersatzverbindung? - wurde das Failover regelmäßig getestet? - funktioniert auch die Rückschaltung? **Mögliche Fehlerbilder** - primäre Verbindung ausgefallen, sekundäre Verbindung übernimmt nicht, - sekundäre Verbindung wird aktiv, besitzt aber keine Route, - Firewallcluster wechselt die Rolle, Upstream-Switch verwendet weiterhin den alten Pfad, - Mobilfunk-Fallback ist aktiv, aber dessen Datenvolumen oder Richtlinie verhindert den Verkehr, - beide redundanten Geräte hängen an derselben ausgefallenen Stromversorgung, - beide Leitungen verwenden denselben physischen Gebäudeeintritt. > Redundanz schützt nur vor Fehlern, die im Entwurf berücksichtigt wurden und deren Umschaltung technisch funktioniert. --- **28. Broadcast-Sturm und Überlastung** Ein größeres Netz kann durch ungewöhnlich hohe Last stark beeinträchtigt werden. Mögliche Ursachen: - Layer-2-Schleife, - fehlerhaftes Gerät, - Broadcast-Sturm, - Multicast-Flut, - übermäßige unbekannte Unicasts, - Schadsoftware, - fehlerhafte Netzwerkkarte, - Backup- oder Replikationsverkehr, - Denial-of-Service, - überlasteter Uplink, - ausgeschöpfte Firewall-Sitzungstabelle. Mögliche Hinweise: - hohe Switch-CPU, - stark erhöhte Broadcast-Zähler, - Managementzugriff instabil, - hohe Portauslastung, - Output Drops, - Paketverlust über viele Clients, - zunehmende Latenz, - MAC-Adresstabelle verändert sich fortlaufend, - Problem verschwindet nach Isolation eines bestimmten Bereichs. Die verursachende Quelle sollte anhand von: - Interface-Zählern, - Flussdaten, - Switch-Protokollen, - MAC-Adresstabellen, - Port Mirroring, - Paketaufzeichnung, - Monitoringverlauf eingegrenzt werden. --- **29. Monitoringdaten auswerten** Monitoring kann zeigen, ob der Fehler lokal, zentral oder schrittweise entstanden ist. Relevante Messwerte: - Geräteerreichbarkeit, - Interface-Status, - Link Flaps, - Bandbreite, - Paketverlust, - Latenz, - CPU, - Speicher, - Temperatur, - Netzteilstatus, - PoE-Verbrauch, - Routingnachbarschaften, - VPN-Tunnel, - DHCP-Auslastung, - DNS-Antwortzeiten, - Firewall-Sitzungen, - Anzahl verbundener WLAN-Clients, - Access-Point-Zustände. **Beispielhafte Ereignisfolge** ```text 09:16:58 Uplink Gi1/0/48 meldet Down 09:16:59 Access Switch wird vom Monitoring nicht mehr erreicht 09:17:03 42 Clients werden als nicht erreichbar gemeldet 09:17:05 Access Points verlieren Controllerverbindung 09:17:21 Uplink meldet kurzzeitig Up 09:17:24 Uplink meldet erneut Down ``` Diese Reihenfolge spricht stärker für einen instabilen gemeinsamen Uplink als für unabhängige Fehler an 42 Clients. Monitoring kann jedoch Lücken besitzen: - Messintervall zu groß, - Überwachung nur per ICMP, - Monitoringpfad selbst betroffen, - Gerät antwortet auf Management, leitet aber keine Nutzdaten, - Messung erfolgt von nur einem Standort. --- **30. Protokolle zeitlich korrelieren** Bei einem größeren Ausfall sollten Protokolle verschiedener Systeme anhand derselben Zeitachse verglichen werden. Relevante Quellen: - Access Switch, - Distribution- und Core-Switch, - Router, - Firewall, - WLAN-Controller, - Access Points, - DHCP-Server, - DNS-Server, - RADIUS-Server, - VPN-Gateway, - Providergerät, - USV, - Virtualisierungsplattform, - Monitoring, - ausgewählte Clients. Voraussetzung für eine sinnvolle Korrelation ist eine möglichst genaue Zeitsynchronisation. **Beispiel** ```text 09:17:02 Distribution Switch: LACP-Mitglied verloren 09:17:03 Access Switch: Uplink-Protokoll wechselt Zustand 09:17:04 Spanning Tree: Topologieänderung 09:17:07 Monitoring: Access Switch nicht erreichbar 09:17:10 DHCP: Anfragen aus VLAN 120 bleiben aus ``` Diese Kombination ist aussagekräftiger als ein einzelner Clientfehler. --- **31. Paketaufzeichnung an geeigneten Punkten** Eine Paketaufzeichnung kann zeigen, bis zu welcher Stelle Verkehr gelangt. Mögliche Aufzeichnungspunkte: - betroffener Client, - funktionierender Vergleichsclient, - Access-Port, - Switch-Uplink, - VLAN-Gateway, - DHCP-Server, - DNS-Server, - Firewall, - Zielserver, - WAN-Schnittstelle. Mögliche Fragestellungen: - sendet der Client ARP-Anfragen? - erreicht ARP das Gateway? - antwortet das Gateway? - verlassen DHCP-Discover-Pakete das VLAN? - erreicht das DHCP-Offer den Uplink? - werden DNS-Anfragen gesendet? - antwortet der DNS-Server? - erreicht ein TCP-SYN die Firewall? - verlässt es die WAN-Schnittstelle? - kommt eine Antwort zurück? - treten Wiederholungen auf? - werden ICMP-Fehlermeldungen zurückgesendet? **Beispielhafte Wireshark-Filter** ```text arp dhcp dns icmp icmpv6 stp eth.addr == ip.addr == tcp.port == 443 ``` Eine Aufzeichnung an nur einem Punkt zeigt nicht automatisch, an welchem Abschnitt eines längeren Pfades ein Paket verloren geht. Bei komplexen Fehlern können zeitlich abgestimmte Aufzeichnungen an mehreren Stellen erforderlich sein. Paketaufzeichnungen dürfen nur mit Berechtigung erstellt und müssen geschützt gespeichert werden. --- **32. Änderungen kontrolliert zurücknehmen** Wenn eine konkrete Änderung als Ursache bestätigt oder sehr stark eingegrenzt wurde, kann eine Rücknahme sinnvoll sein. Vor dem Rollback sind zu klären: - ist der vorherige Zustand dokumentiert? - ist die alte Konfiguration weiterhin gültig? - wurden seitdem weitere abhängige Änderungen durchgeführt? - bestehen Sicherheitsrisiken durch die Rücknahme? - ist ein Wartungs- oder Freigabeprozess erforderlich? - kann die Rücknahme weitere Bereiche beeinträchtigen? - existiert eine aktuelle Sicherung? - wie wird der Erfolg geprüft? - wie wird bei Misserfolg weiter vorgegangen? Ein Rollback ist keine beliebige Rückkehr zu einer alten Konfiguration. Es ist eine geplante Änderung mit eigener Risiko- und Nachprüfung. --- **33. Ungeeignete Sofortmaßnahmen** Bei einem größeren Ausfall können unkoordinierte Eingriffe den Fehler ausweiten oder wichtige Spuren vernichten. Problematisch sind insbesondere: - alle Switches neu starten, - Firewall neu starten, - Router neu starten, - mehrere Uplinks gleichzeitig trennen, - Spanning Tree deaktivieren, - alle Ports administrativ aktivieren, - VLANs neu anlegen, ohne den Ausgangszustand zu sichern, - Firewall vollständig deaktivieren, - DHCP-Bereiche ungeprüft vergrößern, - Switch-Konfiguration durch eine alte Sicherung überschreiben, - Firmware während der Störung aktualisieren, - Provider ohne lokale Prüfung als Ursache festlegen, - mehrere Teams unabhängig Änderungen durchführen lassen, - Geräte austauschen, bevor Verkabelung und Konfiguration dokumentiert wurden. Solche Maßnahmen können im Einzelfall notwendig sein. Sie benötigen jedoch: - technische Begründung, - Freigabe, - Koordination, - dokumentierten Ausgangszustand, - Rückfallmöglichkeit, - vollständige Nachprüfung. --- **34. Praxisfall A: Gesamte Etage ohne kabelgebundenes Netzwerk** **Symptom** - alle geprüften Ethernet-Clients der dritten Etage sind betroffen, - WLAN funktioniert, - andere Etagen funktionieren, - Clients erhalten keine DHCP-Adresse, - Access Switch ist über eine separate Managementverbindung erreichbar. **Prüfung** 1. betroffene Access-Ports und VLANs dokumentieren. 2. Uplinkstatus des Etagen-Switches prüfen. 3. Trunk-Konfiguration beider Seiten vergleichen. 4. erlaubte VLANs kontrollieren. 5. Spanning-Tree-Zustand prüfen. 6. Fehlerzähler des Uplinks auswerten. 7. MAC-Adresstabelle kontrollieren. 8. DHCP-Verkehr am Client-VLAN untersuchen. 9. letzte Konfigurationsänderungen prüfen. 10. nach einer freigegebenen Korrektur alle betroffenen VLANs testen. **Mögliche Ursache** Bei einer Änderung wurde das Client-VLAN aus der Liste der auf dem Uplink erlaubten VLANs entfernt. Das Management-VLAN blieb verfügbar, weshalb der Switch weiterhin administrierbar war. **Nachprüfung** - Clients erhalten Adressen aus dem richtigen Bereich, - Gateway ist erreichbar, - interne DNS-Auflösung funktioniert, - zentrale Anwendungen sind erreichbar, - Internetzugriff funktioniert, - weitere VLANs des Switches funktionieren, - Trunk-Konfiguration beider Seiten ist dokumentiert. --- **35. Praxisfall B: Ganzer Standort erreicht zentrale Systeme nicht** **Symptom** - lokale Drucker und lokale Server funktionieren, - das lokale Gateway ist erreichbar, - zentrale Anwendungen sind nicht erreichbar, - andere Standorte funktionieren, - öffentlicher Internetzugriff funktioniert. **Prüfung** 1. lokale Kommunikation bestätigen. 2. zentrale Ziele per IP testen. 3. Standorttunnel prüfen. 4. Routingtabelle kontrollieren. 5. Ankündigung des Standortpräfixes prüfen. 6. Rückroute am zentralen Standort untersuchen. 7. Firewallprotokolle auswerten. 8. Tunnel- und Routingereignisse zeitlich vergleichen. 9. redundante Verbindung prüfen. 10. ursprünglichen Anwendungszugriff nach der Korrektur wiederholen. **Mögliche Ursache** Nach einer Änderung wurde das lokale Standortpräfix nicht mehr über den VPN-Tunnel angekündigt. Der Hinweg zu zentralen Systemen war teilweise vorhanden, die Antworten besaßen jedoch keine passende Rückroute. **Nachprüfung** - zentrale IP-Ziele erreichbar, - zentrale DNS-Namen auflösbar, - benötigte Anwendungsports erreichbar, - Hin- und Rückroute vorhanden, - erneuter Tunnelaufbau erfolgreich, - Internetverkehr weiterhin funktionsfähig. --- **36. Praxisfall C: Neue Clients erhalten kein Netzwerk** **Symptom** - bereits aktive Clients funktionieren, - neu gestartete oder neu angeschlossene Clients erhalten keine Adresse, - mehrere Bereiche desselben VLANs sind betroffen, - statisch konfigurierte Infrastrukturgeräte bleiben erreichbar. **Prüfung** 1. Adressbereich und freie Leases kontrollieren. 2. DHCP-Dienstzustand prüfen. 3. DHCP-Failoverstatus prüfen. 4. Discover-, Offer-, Request- und ACK-Ablauf aufzeichnen. 5. DHCP-Relay prüfen. 6. DHCP-Snooping-Zustand kontrollieren. 7. Lease-Dauer und Anzahl aktiver Geräte auswerten. 8. unerwünschte DHCP-Server ausschließen. 9. freigegebene Korrektur durchführen. 10. mehrere neue Adressvergaben testen. **Mögliche Ursache** Der DHCP-Bereich besitzt keine freien Adressen mehr. Bestehende Clients können ihre noch gültigen Adressen weiterverwenden, während neue Clients keine Lease erhalten. **Nachprüfung** - neue Clients erhalten gültige Adressen, - Gateway- und DNS-Optionen stimmen, - Lease-Erneuerung funktioniert, - Failoverzustand ist fehlerfrei, - Adressauslastung wird überwacht, - Ursache der unerwartet hohen Belegung ist dokumentiert. --- **37. Praxisfall D: Viele Benutzer melden „kein Internet“** **Symptom** - Gateway ist erreichbar, - öffentliche IP-Ziele sind erreichbar, - Websites können über Namen nicht geöffnet werden, - interne Anwendungen mit bereits bekannten Adressen funktionieren teilweise. **Prüfung** 1. IP-Verbindung getrennt von DNS testen. 2. jeden konfigurierten DNS-Server einzeln abfragen. 3. DNS-Dienstzustand prüfen. 4. Firewallregeln für DNS kontrollieren. 5. Weiterleitungen und Rekursion prüfen. 6. DHCP-DNS-Optionen auswerten. 7. Serverprotokolle zum Fehlerzeitpunkt prüfen. 8. internen und externen Namen testen. 9. DNS-Korrektur durchführen. 10. ursprüngliche Anwendungen erneut prüfen. **Mögliche Ursache** Der primäre und sekundäre DNS-Dienst waren auf derselben ausgefallenen Virtualisierungsplattform betrieben. Die Clients besaßen weiterhin eine funktionierende IP-Verbindung, konnten jedoch keine Namen auflösen. **Nachprüfung** - interne Namen werden korrekt aufgelöst, - externe Namen werden korrekt aufgelöst, - jeder vorgesehene DNS-Server antwortet, - Webanwendungen funktionieren, - Active-Directory-abhängige Dienste funktionieren, - tatsächliche Unabhängigkeit der DNS-Redundanz wird bewertet. --- **38. Praxisfall E: Standort fällt trotz redundanter WAN-Leitung aus** **Symptom** - primäre Leitung ist ausgefallen, - sekundäre Leitung wird als aktiv angezeigt, - zentrale Anwendungen und Internet sind trotzdem nicht erreichbar, - lokale Kommunikation funktioniert. **Prüfung** 1. physischen Zustand beider Leitungen prüfen. 2. aktive Standardroute kontrollieren. 3. Tunnelzustand der Ersatzleitung prüfen. 4. NAT und Firewallregeln prüfen. 5. Routingankündigungen kontrollieren. 6. DNS-Erreichbarkeit über den Ersatzpfad testen. 7. MTU und Paketgröße berücksichtigen. 8. Providerübergaben beider Leitungen vergleichen. 9. Datenverkehr auf der Ersatzschnittstelle aufzeichnen. 10. vollständigen Failover- und Rückschalttest planen. **Mögliche Ursache** Die Ersatzleitung war physisch aktiv, besaß jedoch wegen einer fehlenden Standardroute keinen verwendbaren Datenpfad. **Nachprüfung** - Internet und zentrale Dienste über Ersatzleitung erreichbar, - Tunnel aktiv, - DNS erreichbar, - benötigte NAT- und Firewallregeln wirksam, - automatisches Failover reproduzierbar, - Rückschaltung kontrolliert, - Monitoring erkennt nicht nur den Link-, sondern auch den Dienstzustand. --- **39. Häufige Fehlinterpretationen** | Aussage | fachliche Einordnung | |---|---| | „Viele Benutzer sind betroffen, also ist der Provider ausgefallen.“ | Auch Switch, VLAN, Gateway, DHCP, DNS, Firewall oder Standortanbindung können gemeinsam verantwortlich sein. | | „Der Switch ist erreichbar, also funktioniert er.“ | Management- und Nutzdatenpfad können getrennt sein. | | „Alle Ports zeigen Link, also ist das Netzwerk in Ordnung.“ | VLAN, Trunk, Gateway, DHCP und Routing können trotzdem fehlerhaft sein. | | „WLAN funktioniert, also kann der Switch nicht betroffen sein.“ | WLAN kann einen anderen Access Switch, ein anderes VLAN oder einen anderen Datenpfad verwenden. | | „Nur ein VLAN ist ausgefallen, also ist das Gateway defekt.“ | Auch Trunk, Relay, ACL oder VLAN-Zuordnung können betroffen sein. | | „Alte Clients funktionieren, also funktioniert DHCP.“ | Alte Clients können noch gültige Leases verwenden. | | „Die redundante Leitung ist aktiv, also funktioniert das Failover.“ | Linkstatus bestätigt keinen vollständigen Datenpfad. | | „Die Firewall zeigt Grün, also blockiert sie nichts.“ | Regeln, NAT, Routing oder Datenebene können trotzdem fehlerhaft sein. | | „Nach einem Neustart funktioniert alles, also ist die Ursache behoben.“ | Der Neustart kann Zustand und Spuren verändert haben, ohne die Ursache zu erklären. | | „Eine hohe CPU-Auslastung beweist einen Angriff.“ | Schleifen, Fehler, Monitoring, legitime Last und Kontrollprotokolle sind ebenfalls möglich. | | „Der letzte sichtbare Traceroute-Hop ist defekt.“ | Router können Antworten filtern und Verkehr trotzdem weiterleiten. | | „Zwei Netzteile bedeuten vollständige Redundanz.“ | Beide können an derselben Stromquelle oder USV angeschlossen sein. | --- **40. Vollständige Prüfreihenfolge** 1. konkrete Symptome und betroffene Anwendungen erfassen. 2. Anzahl und Verteilung der betroffenen Clients bestimmen. 3. Ethernet, WLAN, Telefonie und andere Gerätetypen unterscheiden. 4. funktionierende Vergleichsbereiche bestimmen. 5. Beginn, Verlauf und letzte bekannte Funktion dokumentieren. 6. letzte Änderungen und Wartungsarbeiten prüfen. 7. geschäftliche Auswirkung und Priorität bewerten. 8. Zuständigkeiten und Kommunikation koordinieren. 9. repräsentative betroffene und funktionierende Testpunkte auswählen. 10. gemeinsame technische Abhängigkeiten abbilden. 11. Stromversorgung, USV und Umgebung prüfen. 12. Access Switch und physische Uplinks untersuchen. 13. Fehlerzähler und Link Flaps auswerten. 14. Trunk- und VLAN-Konfiguration prüfen. 15. Spanning Tree und mögliche Schleifen untersuchen. 16. Link Aggregation und LACP prüfen. 17. Gateway und First-Hop-Redundanz kontrollieren. 18. DHCP-Dienst, Bereiche und Relay untersuchen. 19. DNS getrennt von der IP-Verbindung prüfen. 20. Netzwerkzugangskontrolle und Authentifizierung berücksichtigen. 21. bei WLAN-Störungen Access Points und Controller prüfen. 22. Firewall, ACL, NAT und Sicherheitszonen untersuchen. 23. Routing einschließlich Rückweg prüfen. 24. WAN, VPN und Providerübergabe kontrollieren. 25. tatsächliche Funktion redundanter Pfade prüfen. 26. Monitoringdaten und Protokolle zeitlich korrelieren. 27. bei Bedarf autorisierte Paketaufzeichnungen erstellen. 28. eine konkrete Hypothese formulieren. 29. Änderung oder Rollback freigeben lassen. 30. immer nur eine kontrollierbare Änderung durchführen. 31. ursprüngliches Symptom erneut testen. 32. weitere VLANs, Standorte und Dienste auf Nebenwirkungen prüfen. 33. Redundanz und erneuten Verbindungsaufbau testen. 34. Ursache, Maßnahme, Ergebnis und verbleibendes Risiko dokumentieren. 35. notwendige Präventionsmaßnahmen festlegen. --- **41. Dokumentationsbeispiel** ```text Ticket: INC-20614 Beginn: 01.08.2026, etwa 09:17 Uhr Standort: Gebäude B Umfang: kabelgebundene Clients der dritten Etage Nicht betroffen: WLAN, andere Etagen, zentrale Server Symptom: Betroffene Clients erhalten keine DHCP-Adresse und können das Standardgateway nicht erreichen. Ausgangszustand: - Access Switch erreichbar - Clientports physisch aktiv - WLAN derselben Etage funktioniert - andere Etagen im gleichen Client-VLAN funktionieren - Uplink des Access Switches aktiv - Client-VLAN nicht in der Liste der erlaubten Uplink-VLANs - Management-VLAN weiterhin erlaubt Hypothese: Das Client-VLAN wird am Uplink des Etagen-Switches nicht mehr transportiert. Prüfung: - Trunk-Konfiguration beider Uplink-Seiten verglichen - Konfigurationsänderung um 09:14 Uhr festgestellt - Client-VLAN fehlte nur auf der Seite des Access Switches - DHCP-Discover war am Clientport, aber nicht am Distribution Switch sichtbar Ursache: Unvollständige Liste erlaubter VLANs nach einer Uplink-Änderung. Maßnahme: Client-VLAN nach Freigabe wieder auf dem Uplink zugelassen. Nachprüfung: - mehrere Clients erhalten gültige DHCP-Adressen - Standardgateway erreichbar - interne DNS-Auflösung erfolgreich - zentrale Anwendungen erreichbar - Internetzugriff funktioniert - WLAN weiterhin funktionsfähig - weitere VLANs des Access Switches geprüft - Konfiguration gespeichert und dokumentiert Prävention: - Konfigurationsprüfung für Trunk-Änderungen ergänzen - VLAN-Erreichbarkeit in das Monitoring aufnehmen - Peer-Review für Änderungen an produktiven Uplinks einführen ``` --- **42. Checkliste für mehrere Clients oder einen Standort ohne Netzwerk** - [ ] genaue Anzahl und Verteilung der betroffenen Clients wurden bestimmt. - [ ] Benutzerangaben wurden durch repräsentative Tests bestätigt. - [ ] Ethernet und WLAN wurden getrennt geprüft. - [ ] funktionierende Vergleichsbereiche wurden dokumentiert. - [ ] interne Dienste, Internet und DNS wurden getrennt bewertet. - [ ] Beginn und zeitlicher Verlauf wurden erfasst. - [ ] letzte Änderungen wurden geprüft. - [ ] geschäftliche Auswirkung und Priorität wurden bewertet. - [ ] technische und kommunikative Zuständigkeiten wurden festgelegt. - [ ] gemeinsame Komponenten der betroffenen Clients wurden bestimmt. - [ ] Stromversorgung und USV wurden geprüft. - [ ] Access Switches wurden auf Zustand und Erreichbarkeit geprüft. - [ ] Uplink-Status und Fehlerzähler wurden kontrolliert. - [ ] Trunk-Konfiguration wurde auf beiden Seiten verglichen. - [ ] benötigte VLANs wurden über den vollständigen Pfad geprüft. - [ ] Spanning-Tree-Zustand und Topology Changes wurden untersucht. - [ ] Link Aggregation und LACP wurden berücksichtigt. - [ ] Gateway und Gateway-Redundanz wurden geprüft. - [ ] DHCP-Dienst, Bereich und Relay wurden untersucht. - [ ] DNS wurde getrennt von der IP-Verbindung getestet. - [ ] Netzwerkzugangskontrolle und RADIUS wurden berücksichtigt. - [ ] WLAN-Controller und Access Points wurden bei Bedarf geprüft. - [ ] Firewallregeln, NAT und ACLs wurden kontrolliert. - [ ] Hin- und Rückrouting wurden geprüft. - [ ] WAN- und VPN-Zustand wurden untersucht. - [ ] Provider wurde erst nach lokaler Eingrenzung einbezogen. - [ ] redundante Pfade wurden tatsächlich getestet. - [ ] Monitoringdaten wurden ausgewertet. - [ ] Protokolle verschiedener Komponenten wurden zeitlich korreliert. - [ ] Paketaufzeichnungen erfolgten nur mit Berechtigung. - [ ] eine konkrete technische Hypothese wurde formuliert. - [ ] Ausgangskonfiguration wurde vor Änderungen gesichert. - [ ] Änderung oder Rollback wurde freigegeben. - [ ] es wurde nur eine kontrollierbare Änderung gleichzeitig durchgeführt. - [ ] ursprüngliches Symptom wurde erneut getestet. - [ ] weitere Dienste und Bereiche wurden auf Nebenwirkungen geprüft. - [ ] Ursache, Maßnahme und Nachweis wurden dokumentiert. - [ ] Präventionsmaßnahmen wurden festgelegt. --- **43. Schnellreferenz** | Fehlerumfang | wahrscheinlicher gemeinsamer Untersuchungsbereich | |---|---| | einzelne Clients an einem Switch | Access-Ports, VLAN, Switch oder Uplink | | komplette Etage | Etagen-Switch, Uplink, Strom oder VLAN-Pfad | | ein VLAN an mehreren Switches | Gateway, DHCP, VLAN-Trunks, ACL oder Routing | | nur neue Clients | DHCP, Authentifizierung oder Adressbereich | | nur WLAN-Clients | Access Points, Controller, SSID, RADIUS, VLAN oder DHCP | | Ethernet und WLAN eines Standorts | Gateway, Firewall, WAN, zentrale Dienste oder Strom | | lokale Systeme funktionieren, zentrale nicht | WAN, VPN, Routing, Firewall oder Rückweg | | IP-Ziele funktionieren, Namen nicht | DNS | | interne Ziele funktionieren, Internet nicht | Firewall, NAT, WAN oder Provider | | alle Standorte betroffen | zentrale Firewall, DNS, Rechenzentrum, Cloud oder zentraler Routingbereich | | sporadische Ausfälle vieler Clients | Schleife, instabiler Uplink, Überlastung oder Redundanzproblem | | bestehende Sitzungen funktionieren, neue nicht | DHCP, DNS, Authentifizierung, Firewallzustand oder Kapazitätsgrenze | --- **Merksatz** > Bei mehreren gleichzeitig betroffenen Clients wird nicht jedes Endgerät einzeln als unabhängiger Fehlerfall behandelt. Entscheidend ist der kleinste gemeinsame Ausfallbereich. Funktionierende Vergleichsbereiche, gemeinsame Abhängigkeiten, Zeitstempel und gezielte Tests führen von der allgemeinen Meldung „Standort ohne Netzwerk“ zu einer überprüfbaren Ursache. --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – DHCP troubleshooting guidance for Windows Server](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dhcp-guidance) - [Microsoft Learn – Guidance for troubleshooting DNS](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-guidance) - [Microsoft Learn – Troubleshooting DNS servers](https://learn.microsoft.com/en-us/windows-server/networking/dns/troubleshoot/troubleshoot-dns-server) - [Cisco – Troubleshoot DHCP in Enterprise Networks](https://www.cisco.com/c/en/us/support/docs/ip/dynamic-address-allocation-resolution/27470-100.html) - [Cisco – Troubleshoot DHCP in a Layer 2 Only VLAN – Wired](https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/catalyst-center/224570-troubleshoot-dhcp-in-layer-2-only-vlan.html) - [Cisco – High Availability Campus Recovery Analysis](https://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/HA_recovery_DG/campusRecovery.html) - [Red Hat – Network troubleshooting and performance tuning](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/network_troubleshooting_and_performance_tuning/) - [Red Hat – Introduction to NetworkManager debugging](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/introduction-to-networkmanager-debugging_configuring-and-managing-networking) - [Red Hat – Mirroring a network interface](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/proc_mirroring-a-network-interface-by-using-nmcli_configuring-and-managing-networking) - [Wireshark – Benutzerhandbuch](https://www.wireshark.org/docs/wsug_html_chunked/) - [Wireshark – Display Filter Reference](https://www.wireshark.org/docs/dfref/) - [RFC 2131 – Dynamic Host Configuration Protocol](https://www.rfc-editor.org/rfc/rfc2131) - [RFC 826 – Address Resolution Protocol](https://www.rfc-editor.org/rfc/rfc826) - [RFC 1034 – Domain Names: Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034) - [RFC 1035 – Domain Names: Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035) - [RFC 5798 – Virtual Router Redundancy Protocol Version 3](https://www.rfc-editor.org/rfc/rfc5798) - [IEEE 802.1 Working Group](https://1.ieee802.org/) # 6.3 IP-Adresse erreichbar, Name nicht – DNS- und Namensauflösungsfehler Wenn ein Ziel über seine IP-Adresse erreichbar ist, der Zugriff über den Namen jedoch scheitert, funktioniert die grundlegende IP-Kommunikation wahrscheinlich. Der Fehler liegt dann häufig bei der Namensauflösung, ihrer Konfiguration oder einem davon abhängigen Dienst. Typische Meldungen sind: - „Die Website ist nicht erreichbar.“ - „Der Server wurde nicht gefunden.“ - „Der Netzwerkname wurde nicht gefunden.“ - „Der Hostname kann nicht aufgelöst werden.“ - „Mit der IP-Adresse funktioniert es.“ - „Internet geht, aber interne Anwendungen nicht.“ - „Einige Namen funktionieren, andere nicht.“ Die Aussage „IP geht, Name geht nicht“ grenzt den Fehlerbereich ein. Sie beweist aber noch nicht, dass ausschließlich der DNS-Server defekt ist. --- **1. Technischer Zusammenhang** Anwendungen verwenden häufig Namen statt IP-Adressen. ```text Benutzer oder Anwendung ↓ fragt nach server.example.test ↓ Namensauflösung ↓ liefert eine IP-Adresse ↓ Verbindung zur IP-Adresse ``` Beispiel: ```text intranet.example.test → 192.0.2.40 ``` Kann der Client `192.0.2.40` erreichen, den Namen `intranet.example.test` jedoch nicht auflösen, müssen insbesondere folgende Bereiche untersucht werden: - DNS-Konfiguration des Clients, - Erreichbarkeit des DNS-Servers, - DNS-Dienst, - zuständige Zone, - benötigter Resource Record, - Weiterleitung oder Rekursion, - Suchsuffix, - lokale Namensquellen, - Cache, - Firewallregeln für DNS, - DNSSEC, - Split-DNS, - VPN- oder standortspezifische DNS-Konfiguration. --- **2. Fehlerbild zuerst bestätigen** Die Benutzeraussage muss durch konkrete Tests bestätigt werden. Zu dokumentieren sind: - exakter Name, - vollständiger Name oder Kurzname, - bekannte Ziel-IP-Adresse, - betroffene Anwendung, - Fehlermeldung, - Zeitpunkt, - betroffener Client, - verwendete Netzwerkverbindung, - verwendeter DNS-Server, - interne oder externe Namensauflösung, - Vergleich mit einem funktionierenden Client. Beispiel: ```text Name: fileserver.example.test IP-Adresse: 192.0.2.40 IP-Adresse erreichbar: ja Name auflösbar: nein DNS-Server: 192.0.2.10 Betroffener Client: PC-023 Vergleichsclient: PC-024 funktioniert ``` Ein Test mit einer IP-Adresse muss denselben Zielsystem- und Netzwerkpfad sinnvoll prüfen. Der Aufruf irgendeiner erreichbaren IP-Adresse ist kein ausreichender Vergleich. --- **3. IP-Erreichbarkeit und Namensauflösung getrennt prüfen** Zuerst wird geprüft, ob das Ziel grundsätzlich per IP erreichbar ist. **Windows** ```powershell ping Test-NetConnection Test-NetConnection -Port ``` **Linux und macOS** ```bash ping traceroute nc -vz ``` Danach wird derselbe Dienst über den Namen getestet. **Windows** ```powershell ping Resolve-DnsName Test-NetConnection -Port ``` **Linux und macOS** ```bash ping dig host nslookup ``` **Mögliche Einordnung** | Ergebnis | mögliche Einordnung | |---|---| | IP und Name funktionieren | Fehler liegt möglicherweise bei Anwendung, Port, Authentifizierung oder zeitweiligem Zustand | | IP funktioniert, Name wird nicht aufgelöst | Namensauflösung untersuchen | | Name wird korrekt aufgelöst, Verbindung scheitert | Zieladresse, Port, Firewall, Routing oder Anwendung untersuchen | | IP und Name scheitern | grundlegende IP-Verbindung, Routing, Firewall oder Zielsystem untersuchen | | Name liefert eine falsche IP-Adresse | DNS-Daten, Cache, Hosts-Datei oder Split-DNS untersuchen | | nur der Kurzname scheitert | DNS-Suffix oder Suchliste untersuchen | | vollständiger Name und Kurzname scheitern | DNS-Server, Zone, Record oder Transport untersuchen | > Eine erfolgreiche Namensauflösung beweist nicht, dass der Zielservice erreichbar ist. Sie bestätigt zunächst nur, dass eine Antwort für den Namen geliefert wurde. --- **4. Vollständigen Namen verwenden** Bei der Fehlersuche sollte zwischen Kurzname und Fully Qualified Domain Name unterschieden werden. Beispiel: ```text Kurzname: fileserver Vollständiger Name: fileserver.example.test ``` Funktioniert der vollständige Name, der Kurzname jedoch nicht, sind häufig folgende Bereiche betroffen: - DNS-Suffix fehlt, - falsches DNS-Suffix, - falsche Suchreihenfolge, - VPN stellt keine benötigte Suchdomäne bereit, - DHCP verteilt eine falsche Domänenoption, - Kurzname wird über eine andere Auflösungsmethode gesucht, - mehrere gleichnamige Geräte existieren in verschiedenen Domänen. **Windows** ```powershell ipconfig /all Get-DnsClientGlobalSetting Get-DnsClient ``` **Linux** ```bash cat /etc/resolv.conf resolvectl status ``` **macOS** ```bash scutil --dns ``` Zu prüfen sind: - primäres DNS-Suffix, - verbindungsspezifisches DNS-Suffix, - DNS-Suffixsuchliste, - Reihenfolge der Suchdomänen, - aktive Netzwerkschnittstelle, - vom DHCP-Server gelieferte Einstellungen, - vom VPN-Client ergänzte Einstellungen. --- **5. Konfigurierte DNS-Server prüfen** Ein Client muss die vorgesehenen DNS-Server verwenden. **Windows** ```powershell ipconfig /all Get-DnsClientServerAddress ``` **Linux** ```bash resolvectl status cat /etc/resolv.conf nmcli device show ``` **macOS** ```bash scutil --dns networksetup -getdnsservers ``` Zu prüfen sind: - richtige DNS-Serveradressen, - Reihenfolge der DNS-Server, - IPv4- und IPv6-Konfiguration, - statische oder dynamische Konfiguration, - DNS-Angaben aus DHCP, - DNS-Einstellungen des VPN-Clients, - lokale Resolver, - Sicherheitssoftware oder DNS-Filter, - unerwünschte öffentliche DNS-Server. In einer Active-Directory-Umgebung dürfen Clients für interne AD-Namen normalerweise nicht ausschließlich beliebige öffentliche DNS-Resolver verwenden. Ein öffentlicher Resolver kennt die internen DNS-Zonen nicht. --- **6. Jeden DNS-Server einzeln abfragen** Sind mehrere DNS-Server eingetragen, muss jeder Server gezielt getestet werden. **Windows** ```powershell Resolve-DnsName -Server Resolve-DnsName -Server ``` Alternativ: ```powershell nslookup nslookup ``` **Linux und macOS** ```bash dig @ dig @ ``` **Beispielhafte Auswertung** | DNS-Server 1 | DNS-Server 2 | mögliche Einordnung | |---|---|---| | richtige Antwort | richtige Antwort | DNS-Server grundsätzlich konsistent | | richtige Antwort | keine Antwort | zweiter Server, Netzwerkpfad oder Firewall | | richtige Antwort | falsche Antwort | abweichende Zone, Replikation oder veraltete Daten | | keine Antwort | keine Antwort | Erreichbarkeit, Dienst, Firewall oder Clientkonfiguration | | `NXDOMAIN` | richtige Antwort | inkonsistente Zonen oder verschiedene DNS-Sichten | | unterschiedliche IP-Adressen | möglicherweise Split-DNS, Replikationsfehler oder abweichende Records | > Ein Client wechselt nicht in jedem Fall zum nächsten DNS-Server, nur weil der erste Server eine fachlich falsche Antwort liefert. Eine erhaltene negative oder falsche Antwort ist etwas anderes als ein nicht antwortender Server. --- **7. Bedeutung häufiger DNS-Ergebnisse** DNS-Abfragen können unterschiedliche Rückmeldungen liefern. | Ergebnis | Bedeutung | möglicher Untersuchungsbereich | |---|---|---| | `NOERROR` mit Antwort | Name wurde beantwortet | zurückgegebene Daten auf Richtigkeit prüfen | | `NOERROR` ohne passende Antwort | Name oder Typ besitzt möglicherweise keinen entsprechenden Record | Record-Typ, Zone oder Alias prüfen | | `NXDOMAIN` | angefragter Name existiert aus Sicht des antwortenden Servers nicht | Schreibweise, Zone, Record, Cache oder falscher DNS-Server | | `SERVFAIL` | Server konnte die Anfrage nicht erfolgreich bearbeiten | DNSSEC, Delegation, Upstream-Server oder Serverfehler | | `REFUSED` | Server verweigert die Anfrage | Richtlinie, Rekursion, ACL oder nicht erlaubter Client | | Zeitüberschreitung | keine rechtzeitige DNS-Antwort | Erreichbarkeit, Port 53, Überlastung oder Dienst | | falsche IP-Adresse | Antwort vorhanden, aber ungeeignet | Record, Cache, Hosts-Datei, Split-DNS oder Replikation | | `CNAME` ohne erreichbares Endziel | Alias vorhanden, Zielname problematisch | CNAME-Kette und Zielzone untersuchen | Die Meldung `NXDOMAIN` bedeutet nicht automatisch, dass der gesamte DNS-Dienst ausgefallen ist. Der Server hat geantwortet, kennt den angefragten Namen jedoch nicht. --- **8. Record-Typ gezielt prüfen** DNS enthält verschiedene Resource Records. | Typ | Aufgabe | |---|---| | `A` | Name zu IPv4-Adresse | | `AAAA` | Name zu IPv6-Adresse | | `CNAME` | Alias auf einen anderen Namen | | `PTR` | IP-Adresse zu Name bei Rückwärtsauflösung | | `MX` | zuständiger Mailserver | | `NS` | autoritativer Nameserver einer Zone | | `SOA` | Verwaltungsinformationen einer Zone | | `SRV` | Dienst und zuständiger Server | | `TXT` | Textinformationen, Prüf- und Richtliniendaten | **Windows** ```powershell Resolve-DnsName -Type A Resolve-DnsName -Type AAAA Resolve-DnsName -Type CNAME Resolve-DnsName -Type NS Resolve-DnsName -Type SOA Resolve-DnsName -Type SRV ``` **Linux und macOS** ```bash dig A dig AAAA dig CNAME dig NS dig SOA dig SRV ``` Wenn eine Anwendung einen bestimmten Record-Typ benötigt, reicht die erfolgreiche Abfrage eines anderen Typs nicht aus. Beispielsweise können Active-Directory-Dienste von SRV-Records abhängig sein. Ein vorhandener A-Record des Domain Controllers beweist nicht, dass alle benötigten SRV-Records korrekt vorhanden sind. --- **9. DNS-Transport und Port 53 prüfen** DNS verwendet grundsätzlich: - UDP Port 53, - TCP Port 53. UDP wird häufig für normale Abfragen verwendet. TCP kann unter anderem bei größeren, abgeschnittenen oder bestimmten serverseitigen Übertragungen erforderlich sein. Zu prüfen sind: - Client erreicht DNS-Server per IP, - UDP Port 53 ist erlaubt, - TCP Port 53 ist erlaubt, - lokale Firewall blockiert nicht, - Netzwerk-Firewall blockiert nicht, - VPN erlaubt DNS-Verkehr, - DNS-Server lauscht auf der vorgesehenen Adresse, - Antwortpakete erreichen den Client, - NAT oder Sicherheitsfilter verändern den Verkehr nicht. **Windows** ```powershell Test-NetConnection -Port 53 ``` Dieser Test prüft TCP Port 53. Er ersetzt keine Prüfung von UDP-DNS. **Linux und macOS** ```bash dig @ dig +tcp @ ``` **Mögliche Beobachtungen** | Beobachtung | mögliche Einordnung | |---|---| | UDP-Abfrage funktioniert, TCP-Abfrage scheitert | Firewall oder Dienstkonfiguration für TCP 53 | | kleine Antworten funktionieren, größere nicht | TCP-Fallback, Fragmentierung, EDNS oder MTU | | Anfrage verlässt Client, keine Antwort sichtbar | DNS-Server, Rückweg oder Filter | | Antwort erreicht Netzwerkschnittstelle, Anwendung erhält sie nicht | lokale Firewall, Resolver oder Sicherheitssoftware | | DNS-Server ist per IP erreichbar, Port 53 antwortet nicht | Dienst, Firewall oder falsche Zieladresse | --- **10. Lokalen DNS-Cache prüfen** Clients und Resolver speichern DNS-Antworten für eine bestimmte Zeit. Auch negative Antworten können zwischengespeichert werden. Mögliche Symptome: - ein Client erhält eine alte Adresse, - andere Clients funktionieren bereits, - nach einer DNS-Änderung bleibt der Fehler bestehen, - der Name funktioniert nach Ablauf einer gewissen Zeit, - eine direkte Abfrage beim DNS-Server ist korrekt, die Anwendung verwendet aber weiterhin eine alte Antwort. **Windows** ```powershell ipconfig /displaydns Clear-DnsClientCache ``` Alternativ: ```powershell ipconfig /flushdns ``` **Linux mit systemd-resolved** ```bash resolvectl statistics sudo resolvectl flush-caches ``` **macOS** Die verwendeten Cache-Mechanismen können von der macOS-Version und dem aktiven Resolver abhängen. Vor einer Cache-Bereinigung sollte deshalb zuerst geprüft werden, ob eine direkte DNS-Abfrage bereits die korrekte Antwort liefert. > Das Leeren des Cache ist eine Prüf- oder Korrekturmaßnahme für zwischengespeicherte Daten. Es behebt keine fehlenden Records, falschen Zonen oder nicht erreichbaren DNS-Server. --- **11. Hosts-Datei berücksichtigen** Vor oder neben DNS können lokale Namensquellen eine Rolle spielen. Eine fehlerhafte Hosts-Datei kann DNS-Ergebnisse überlagern. **Windows** ```text C:\Windows\System32\drivers\etc\hosts ``` **Linux und macOS** ```text /etc/hosts ``` Zu prüfen sind: - Eintrag für den betroffenen Namen, - veraltete IP-Adresse, - Schreibfehler, - doppelte Einträge, - Einträge durch Softwareverteilung, - Manipulation durch Schadsoftware, - abweichender Eintrag nur auf einzelnen Clients. Die Hosts-Datei sollte nicht ungeprüft als dauerhafte Ersatzlösung für einen fehlerhaften DNS-Eintrag verwendet werden. Dadurch würde die zentrale Ursache verborgen und eine schwer wartbare Sonderkonfiguration geschaffen. --- **12. Zuständige Zone und autoritative Server prüfen** Für einen internen Namen muss die zuständige DNS-Zone vorhanden und auf den vorgesehenen Servern verfügbar sein. Zu prüfen sind: - existiert die Zone? - ist sie geladen? - enthält sie den benötigten Record? - ist der Record aktiviert und korrekt geschrieben? - zeigt der Record auf die richtige Adresse? - besitzt die Zone korrekte NS-Einträge? - ist die Delegation korrekt? - stimmen primäre und sekundäre Kopien überein? - funktioniert die Replikation? - ist die Seriennummer plausibel? - bestehen abgelaufene oder veraltete Zonendaten? - ist eine bedingte Weiterleitung erforderlich? - antwortet der abgefragte Server autoritativ? **Windows-DNS-Server** ```powershell Get-DnsServerZone Get-DnsServerResourceRecord -ZoneName Get-DnsServerForwarder ``` **Allgemeine Abfragen** ```bash dig NS dig SOA dig +trace ``` `dig +trace` zeigt eine schrittweise Auflösung über die DNS-Hierarchie. Für rein interne Zonen ist dieser Test nicht in derselben Weise geeignet wie für öffentlich delegierte Zonen. --- **13. Rekursion und Weiterleitungen prüfen** Ein interner DNS-Server kennt nicht automatisch alle externen Namen. Er verwendet je nach Konfiguration: - Rekursion, - Root Hints, - allgemeine Forwarder, - Conditional Forwarder, - Stub-Zonen, - interne Delegationen. Mögliche Fehlerbilder: - interne Namen funktionieren, externe nicht, - externe Namen funktionieren, eine Partnerdomäne nicht, - nur Namen einer bestimmten internen Zone scheitern, - Abfragen an den internen DNS-Server liefern `SERVFAIL`, - direkte Abfragen an einen öffentlichen Resolver funktionieren, - ein Forwarder ist nicht erreichbar, - eine bedingte Weiterleitung zeigt auf veraltete Server. **Abgrenzung** | Ergebnis | möglicher Bereich | |---|---| | interne und externe Namen scheitern | Client, DNS-Server, Dienst oder Transport | | interne Namen funktionieren, externe nicht | Rekursion, Forwarder, Root Hints oder Firewall | | externe Namen funktionieren, interne nicht | interne Zone, falscher DNS-Server oder Split-DNS | | nur eine Partnerdomäne scheitert | Conditional Forwarder, Delegation oder Partner-DNS | | nur einzelne Records fehlen | Zone, Replikation oder Record-Verwaltung | --- **14. Split-DNS berücksichtigen** Bei Split-DNS kann derselbe Name abhängig vom verwendeten DNS-Server oder Standort unterschiedliche Antworten liefern. Beispiel: ```text intern: portal.example.test → 192.0.2.50 extern: portal.example.test → 198.51.100.50 ``` Zu prüfen sind: - befindet sich der Client intern, extern oder im VPN? - welcher DNS-Server beantwortet die Anfrage? - wird die interne oder externe Zone verwendet? - ist die interne Adresse aus dem aktuellen Netz erreichbar? - wird über das VPN der richtige DNS-Server bereitgestellt? - verwendet der Browser oder die Anwendung einen eigenen DNS-Dienst? - existieren widersprüchliche Records? Ein korrekt funktionierender öffentlicher DNS-Eintrag beweist nicht, dass der interne Eintrag korrekt ist. --- **15. VPN und mehrere Netzwerkschnittstellen** VPN-Verbindungen können DNS-Einstellungen gezielt verändern. Mögliche Fehlerbilder: - interne Namen funktionieren nur mit aktivem VPN, - externe Namen funktionieren, interne nicht, - nach dem Trennen des VPN bleibt eine ungeeignete DNS-Konfiguration aktiv, - der Client fragt den DNS-Server der falschen Schnittstelle, - Split-Tunneling und Split-DNS passen nicht zusammen, - lokale und entfernte Netze verwenden dieselbe Domäne, - mehrere aktive Adapter besitzen widersprüchliche DNS-Suffixe. Zu prüfen sind: - DNS-Server jeder Schnittstelle, - Schnittstellenmetrik, - DNS-Suffixe, - vom VPN übermittelte Suchdomänen, - Routen zum internen DNS-Server, - Erreichbarkeit des DNS-Servers durch den Tunnel, - Richtlinien des VPN-Clients, - Zustand nach erneutem Verbindungsaufbau. **Windows** ```powershell Get-NetIPConfiguration Get-DnsClient Get-DnsClientServerAddress Get-NetRoute ``` **Linux** ```bash ip address ip route resolvectl status ``` **macOS** ```bash ifconfig netstat -rn scutil --dns ``` --- **16. IPv4 und IPv6 getrennt betrachten** Ein Name kann sowohl einen A- als auch einen AAAA-Record besitzen. Mögliche Fehlerbilder: - A-Record ist korrekt, AAAA-Record ist falsch, - Client bevorzugt IPv6, der IPv6-Pfad funktioniert jedoch nicht, - Anwendung erhält nur eine IPv6-Adresse, - DNS funktioniert, aber die zurückgegebene Adressfamilie ist nicht erreichbar, - IPv6-DNS-Server ist eingetragen, aber nicht erreichbar. Zu prüfen sind: ```powershell Resolve-DnsName -Type A Resolve-DnsName -Type AAAA ``` ```bash dig A dig AAAA ping -4 ping -6 ``` Das pauschale Deaktivieren von IPv6 ist keine fachgerechte Standardlösung. Zuerst muss bestätigt werden, ob tatsächlich ein fehlerhafter AAAA-Record, IPv6-DNS-Server oder IPv6-Datenpfad vorliegt. --- **17. DNSSEC prüfen** DNSSEC ermöglicht die Prüfung signierter DNS-Daten. Fehler bei Signaturen oder Vertrauenskette können zu `SERVFAIL` führen. Mögliche Ursachen: - abgelaufene Signatur, - fehlerhafter DS-Record, - nicht passende Schlüssel, - unvollständige Vertrauenskette, - falsche Systemzeit, - fehlerhafte Zone nach Schlüsselwechsel, - validierender Resolver verwirft die Antwort. **Linux und macOS mit dig** ```bash dig +dnssec dig +trace ``` Bei DNSSEC-Problemen sollten geprüft werden: - exakter Antwortcode, - gesetzte DNSSEC-Flags, - Systemzeit, - Signaturgültigkeit, - Delegation, - Verhalten eines validierenden und eines nicht validierenden Resolvers. DNSSEC darf nicht pauschal deaktiviert werden, ohne den Fehler einzugrenzen und die Sicherheitsauswirkung zu bewerten. --- **18. Browser und verschlüsseltes DNS** Ein Browser oder eine Sicherheitsanwendung kann einen eigenen DNS-Auflösungsweg verwenden, beispielsweise DNS over HTTPS. Mögliche Beobachtungen: - `Resolve-DnsName` oder `dig` liefert eine richtige Antwort, - nur ein bestimmter Browser verwendet eine falsche oder keine Antwort, - Browser und Betriebssystem zeigen unterschiedliche Ergebnisse, - interne Namen funktionieren in einer Anwendung, im Browser jedoch nicht, - DNS-Filter oder Proxy beeinflusst nur Webverkehr. Zu prüfen sind: - verwendet die Anwendung den Systemresolver? - ist verschlüsseltes DNS aktiviert? - welcher Resolver wird dabei verwendet? - kann dieser Resolver interne Zonen kennen? - besteht ein Proxy? - besitzt die Anwendung einen eigenen Cache? - greift eine Sicherheitsrichtlinie ein? Ein funktionierender Kommandozeilentest beweist daher nicht in jedem Fall, dass die betroffene Anwendung denselben Resolver und dieselben DNS-Daten verwendet. --- **19. mDNS, LLMNR und NetBIOS nicht mit DNS verwechseln** Kurznamen und lokale Gerätenamen können abhängig vom Betriebssystem auch über andere Verfahren aufgelöst werden. Mögliche Verfahren: - DNS, - lokale Hosts-Datei, - Multicast DNS, - Link-Local Multicast Name Resolution, - NetBIOS Name Service, - anwendungseigene Verzeichnisse. Wenn ein Kurzname funktioniert, ist damit nicht automatisch bewiesen, dass DNS funktioniert. Der Name könnte über ein anderes Verfahren aufgelöst worden sein. Für eine eindeutige DNS-Prüfung sollten gezielte Werkzeuge verwendet werden: ```powershell Resolve-DnsName -Server ``` ```bash dig @ ``` --- **20. Reverse DNS getrennt prüfen** Die Rückwärtsauflösung ordnet einer IP-Adresse einen Namen zu. Dafür werden PTR-Records verwendet. Beispiel: ```text 192.0.2.40 → fileserver.example.test ``` **Windows** ```powershell Resolve-DnsName -Type PTR ``` **Linux und macOS** ```bash dig -x ``` Eine fehlende Rückwärtsauflösung verhindert nicht grundsätzlich jede Verbindung zur IP-Adresse. Bestimmte Anwendungen, Protokollierungen, Authentifizierungsverfahren oder Sicherheitsprüfungen können jedoch von einem korrekten PTR-Record abhängen. Vorwärts- und Rückwärtsauflösung sind deshalb getrennt zu prüfen. --- **21. Active Directory und DNS** Active Directory ist stark von DNS abhängig. DNS-Fehler können unter anderem beeinträchtigen: - Domänenanmeldung, - Auffinden von Domain Controllern, - Gruppenrichtlinien, - Kerberos, - LDAP, - Replikation, - Datei- und Druckdienste, - Zertifikatsdienste, - Verwaltungswerkzeuge. Benötigt werden unter anderem SRV-Records. Beispielhafte Prüfung: ```powershell Resolve-DnsName _ldap._tcp.dc._msdcs. -Type SRV Resolve-DnsName _kerberos._tcp. -Type SRV ``` Zu prüfen sind: - verwendet der Client ausschließlich vorgesehene interne DNS-Server? - sind SRV-Records vorhanden? - sind die eingetragenen Domain Controller erreichbar? - stimmen Systemzeit und Domänenzugehörigkeit? - sind DNS-Zonen zwischen Domain Controllern repliziert? - existieren alte Records nicht mehr vorhandener Systeme? - funktioniert die dynamische DNS-Registrierung? --- **22. Dynamische DNS-Registrierung** Clients und Server können ihre Records dynamisch registrieren. Mögliche Fehlerbilder: - neuer Client besitzt noch keinen Record, - Record zeigt auf eine alte Adresse, - DHCP aktualisiert DNS nicht, - Client darf den Record nicht aktualisieren, - alter Record wurde nicht entfernt, - Gerät besitzt mehrere Schnittstellen und registriert eine ungeeignete Adresse, - Replikation verteilt den aktualisierten Record nicht. **Windows-Client** ```powershell ipconfig /registerdns ``` Vor der Verwendung ist zu prüfen: - soll der Client den Record selbst registrieren? - übernimmt DHCP die Registrierung? - besitzt der Client eine gültige DNS-Konfiguration? - ist die Zone für dynamische Updates eingerichtet? - bestehen ausreichende Berechtigungen? - existiert bereits ein Record mit abweichendem Besitzer? `ipconfig /registerdns` ist keine Lösung für einen falsch eingerichteten DNS-Server oder eine fehlende Zone. --- **23. Zeitabhängige und sporadische Fehler** Sporadische Namensauflösungsfehler können entstehen durch: - inkonsistente DNS-Server, - fehlerhafte Replikation, - abwechselnd richtige und falsche Antworten, - instabile Netzwerkverbindung, - Paketverlust, - überlasteten DNS-Server, - ablaufende oder erneuerte Cache-Einträge, - DNS-Round-Robin, - einen fehlerhaften Server hinter einem Load Balancer, - unterschiedliche VPN-Zustände, - zeitweise nicht erreichbare Forwarder. Sinnvoll sind wiederholte, zeitgestempelte Abfragen. **PowerShell** ```powershell 1..10 | ForEach-Object { Get-Date Resolve-DnsName -Server Start-Sleep -Seconds 2 } ``` **Bash** ```bash for i in {1..10}; do date dig @ sleep 2 done ``` Zu vergleichen sind: - Antwortcode, - Antwortadresse, - antwortender Server, - TTL, - Laufzeit, - Häufigkeit von Zeitüberschreitungen. --- **24. Paketaufzeichnung für DNS** Eine Paketaufzeichnung kann zeigen: - ob der Client eine Anfrage sendet, - welchen DNS-Server er verwendet, - welcher Name und Record-Typ angefragt wird, - ob die Anfrage UDP oder TCP verwendet, - ob eine Antwort zurückkommt, - welcher Antwortcode geliefert wird, - ob Wiederholungen auftreten, - ob verschiedene DNS-Server angesprochen werden, - ob die Antwort abgeschnitten ist, - ob der Client die Antwort verwirft. **Wireshark-Filter** ```text dns udp.port == 53 tcp.port == 53 dns.qry.name == "" ip.addr == ``` **Typische Beobachtungen** | Paketaufzeichnung | mögliche Einordnung | |---|---| | keine DNS-Anfrage | Anwendungscache, Hosts-Datei, anderer Resolver oder Anwendung sendet nicht | | Anfrage an falschen Server | Client-, DHCP-, VPN- oder Schnittstellenkonfiguration | | Anfrage, keine Antwort | Server, Transport, Firewall oder Rückweg | | Antwort `NXDOMAIN` | Server kennt den Namen nicht | | Antwort `SERVFAIL` | serverseitige Auflösung, DNSSEC oder Delegation | | richtige Antwort, Anwendung scheitert | Cache, Anwendung, Zielservice oder Datenpfad | | wiederholte Anfragen an mehrere Server | Antwortausfall oder Zeitüberschreitung | | UDP-Antwort abgeschnitten, TCP scheitert | TCP Port 53, Firewall oder MTU | Paketaufzeichnungen dürfen nur mit entsprechender Berechtigung erstellt und müssen geschützt gespeichert werden. --- **25. Praxisfall A: Nur ein Client kann einen internen Namen nicht auflösen** **Symptom** - Server ist per IP erreichbar, - vollständiger interner Name funktioniert auf anderen Clients, - nur ein Client ist betroffen, - externe Namen funktionieren. **Prüfung** 1. DNS-Server des betroffenen Clients prüfen. 2. mit funktionierendem Client vergleichen. 3. vollständigen Namen gezielt abfragen. 4. jeden eingetragenen DNS-Server einzeln testen. 5. DNS-Cache prüfen. 6. Hosts-Datei kontrollieren. 7. VPN- und Schnittstellenkonfiguration prüfen. 8. Paketaufzeichnung bei Bedarf durchführen. **Mögliche Ursache** Der Client verwendet aufgrund einer statischen Alt-Konfiguration einen öffentlichen DNS-Server. Dieser kann die interne Zone nicht auflösen. **Nachprüfung** - interner DNS-Server ist eingetragen, - vollständiger Name wird korrekt aufgelöst, - Kurzname funktioniert mit richtigem Suffix, - externe Namen funktionieren weiterhin, - ursprüngliche Anwendung ist erreichbar. --- **26. Praxisfall B: Interne Namen funktionieren, externe Namen nicht** **Symptom** - interne Servernamen werden korrekt aufgelöst, - externe Namen liefern `SERVFAIL` oder Zeitüberschreitungen, - Internetziele sind per IP erreichbar, - mehrere Clients sind betroffen. **Prüfung** 1. DNS-Server direkt abfragen. 2. interne und externe Namen vergleichen. 3. allgemeine Forwarder prüfen. 4. Erreichbarkeit der Forwarder untersuchen. 5. Rekursion und Root Hints kontrollieren. 6. Firewallregeln für UDP und TCP Port 53 prüfen. 7. Serverprotokolle auswerten. 8. DNSSEC-Fehler ausschließen. **Mögliche Ursache** Der interne DNS-Server kann interne Zonen selbst beantworten. Der konfigurierte Forwarder für externe Namen ist jedoch nicht mehr erreichbar. **Nachprüfung** - interne Namen funktionieren, - externe Namen funktionieren, - mehrere externe Domänen wurden geprüft, - UDP- und TCP-Abfragen sind möglich, - redundante Weiterleitung wurde bewertet, - Monitoring erkennt externe Auflösungsfehler. --- **27. Praxisfall C: Vollständiger Name funktioniert, Kurzname nicht** **Symptom** ```text fileserver.example.test → funktioniert fileserver → funktioniert nicht ``` **Prüfung** 1. DNS-Suffixsuchliste anzeigen. 2. verbindungsspezifisches Suffix prüfen. 3. DHCP-Optionen kontrollieren. 4. VPN-Konfiguration untersuchen. 5. mit funktionierendem Client vergleichen. 6. tatsächlich angefragte Namen in einer Paketaufzeichnung prüfen. **Mögliche Ursache** Nach einer DHCP-Änderung wird das interne DNS-Suffix nicht mehr an neue Clients verteilt. **Nachprüfung** - vollständiger Name funktioniert, - Kurzname wird um das richtige Suffix ergänzt, - neue DHCP-Lease enthält die vorgesehene Konfiguration, - andere Namensräume funktionieren weiterhin. --- **28. Praxisfall D: Einige Clients erhalten eine falsche IP-Adresse** **Symptom** - derselbe Name liefert unterschiedliche Adressen, - ein Teil der Clients erreicht den Dienst, - andere Clients verbinden sich mit einem alten Server, - beide DNS-Server antworten. **Prüfung** 1. beide DNS-Server einzeln abfragen. 2. Records und TTL vergleichen. 3. Zone und Replikationszustand prüfen. 4. Cache auf Clients und Resolvern berücksichtigen. 5. Hosts-Dateien ausschließen. 6. Split-DNS-Konfiguration prüfen. 7. Anwendung nach Korrektur erneut testen. **Mögliche Ursache** Ein DNS-Server besitzt aufgrund einer Replikationsstörung noch einen alten A-Record. **Nachprüfung** - alle vorgesehenen DNS-Server liefern dieselbe korrekte Antwort, - Replikation funktioniert, - alte Records sind entfernt, - Clients erreichen den vorgesehenen Dienst, - Ursache der Replikationsstörung ist dokumentiert. --- **29. Praxisfall E: DNS-Abfrage funktioniert, Browser nicht** **Symptom** - Systemwerkzeug liefert die richtige Adresse, - nur ein Browser kann den internen Namen nicht öffnen, - andere Anwendungen funktionieren, - der Browser verwendet verschlüsseltes DNS. **Prüfung** 1. Ergebnis des Systemresolvers dokumentieren. 2. Browser-DNS-Konfiguration prüfen. 3. verwendeten verschlüsselten Resolver bestimmen. 4. Browsercache berücksichtigen. 5. Proxy- und Sicherheitsrichtlinien kontrollieren. 6. vollständigen Namen im Browser testen. **Mögliche Ursache** Der Browser sendet DNS-over-HTTPS-Abfragen an einen öffentlichen Resolver, der die interne Zone nicht kennt. **Nachprüfung** - Browser verwendet die vorgesehene Unternehmensrichtlinie, - interne Namen werden aufgelöst, - externe Namen funktionieren, - System- und Browserauflösung liefern konsistente Ergebnisse. --- **30. Ungeeignete Sofortmaßnahmen** Problematisch sind insbesondere: - DNS-Server ungeprüft neu starten, - öffentliche DNS-Server dauerhaft auf internen Clients eintragen, - DNSSEC pauschal deaktivieren, - IPv6 pauschal deaktivieren, - Firewall für Port 53 vollständig öffnen, - fehlende Records durch lokale Hosts-Einträge auf vielen Clients ersetzen, - komplette Zonen neu erstellen, - Replikation ohne Sicherung zurücksetzen, - Caches löschen, ohne vorher den Ausgangszustand zu dokumentieren, - mehrere DNS-Server gleichzeitig verändern, - produktive Records ohne Prüfung löschen, - den DNS-Server als Ursache festlegen, obwohl der Name korrekt aufgelöst wird. Vor Änderungen sind zu sichern beziehungsweise zu dokumentieren: - aktuelle Clientkonfiguration, - verwendete DNS-Server, - Abfrageergebnisse, - zuständige Zone, - vorhandene Records, - TTL, - Replikationszustand, - Weiterleitungen, - Zeitpunkt und Umfang der Störung. --- **31. Vollständige Prüfreihenfolge** 1. exakten betroffenen Namen erfassen. 2. Kurzname und vollständigen Namen unterscheiden. 3. bekannte Ziel-IP-Adresse dokumentieren. 4. Ziel per IP-Adresse und benötigtem Port prüfen. 5. denselben Dienst über den Namen testen. 6. Fehlermeldung und Zeitpunkt dokumentieren. 7. betroffene und funktionierende Clients vergleichen. 8. konfigurierte DNS-Server feststellen. 9. jeden DNS-Server einzeln abfragen. 10. Antwortcode und zurückgegebene Records bewerten. 11. A- und AAAA-Records getrennt prüfen. 12. DNS-Suffix und Suchliste kontrollieren. 13. lokale Hosts-Datei prüfen. 14. Cache nur nach Dokumentation berücksichtigen. 15. Erreichbarkeit des DNS-Servers prüfen. 16. UDP und TCP Port 53 berücksichtigen. 17. zuständige Zone und Record untersuchen. 18. autoritative Server und Delegation prüfen. 19. Replikation zwischen DNS-Servern kontrollieren. 20. Rekursion, Forwarder oder Conditional Forwarder untersuchen. 21. Split-DNS und aktuellen Standort berücksichtigen. 22. VPN und mehrere Schnittstellen prüfen. 23. anwendungseigene Resolver oder verschlüsseltes DNS berücksichtigen. 24. bei Bedarf eine autorisierte Paketaufzeichnung erstellen. 25. konkrete Hypothese formulieren. 26. genau eine kontrollierbare Änderung durchführen. 27. DNS-Abfrage erneut testen. 28. ursprüngliche Anwendung erneut testen. 29. interne und externe Namen prüfen. 30. zweiten DNS-Server und Vergleichsclient prüfen. 31. Ursache, Maßnahme und Ergebnis dokumentieren. 32. Monitoring oder Präventionsmaßnahme festlegen. --- **32. Dokumentationsbeispiel** ```text Ticket: INC-20631 Beginn: 02.08.2026, etwa 10:35 Uhr Umfang: neu verbundene VPN-Clients Betroffen: interne Servernamen Nicht betroffen: externe DNS-Namen und direkte IP-Verbindungen Symptom: Der Server fileserver.example.test ist über 192.0.2.40 erreichbar. Der Name kann auf betroffenen VPN-Clients nicht aufgelöst werden. Ausgangszustand: - VPN-Tunnel aktiv - Route zum internen Server vorhanden - Server per IP und TCP Port 445 erreichbar - externe Namen werden aufgelöst - betroffene Clients verwenden einen öffentlichen DNS-Server - interne DNS-Server werden vom VPN nicht bereitgestellt - funktionierende interne Clients verwenden 192.0.2.10 und 192.0.2.11 Hypothese: Die VPN-Konfiguration übermittelt nicht die für interne Zonen zuständigen DNS-Server. Prüfung: - Resolve-DnsName über Standardkonfiguration liefert NXDOMAIN - direkte Abfrage an 192.0.2.10 liefert 192.0.2.40 - interne DNS-Server sind durch den Tunnel erreichbar - VPN-Profil besitzt keine DNS-Serverzuweisung - Änderung des VPN-Profils zum Fehlerzeitpunkt festgestellt Ursache: Bei einer Änderung des VPN-Profils wurden die internen DNS-Server und die interne Suchdomäne nicht übernommen. Maßnahme: Interne DNS-Server und Suchdomäne nach Freigabe wieder in das VPN-Profil aufgenommen. Nachprüfung: - vollständiger interner Name wird korrekt aufgelöst - Kurzname funktioniert über die vorgesehene Suchdomäne - Dateidienst ist über den Namen erreichbar - externe Namensauflösung funktioniert - erneuter VPN-Verbindungsaufbau erfolgreich - zweiter DNS-Server geprüft - mehrere VPN-Clients erfolgreich getestet Prävention: - DNS-Funktion in den VPN-Abnahmetest aufnehmen - interne und externe Testnamen überwachen - Änderungen an VPN-Profilen durch Peer-Review prüfen ``` --- **33. Checkliste „Name geht nicht, IP geht“** - [ ] der exakte betroffene Name wurde dokumentiert. - [ ] Kurzname und vollständiger Name wurden getrennt getestet. - [ ] die bekannte Ziel-IP-Adresse wurde geprüft. - [ ] der benötigte Zielport wurde berücksichtigt. - [ ] die Fehlermeldung wurde dokumentiert. - [ ] ein funktionierender Vergleichsclient wurde geprüft. - [ ] die verwendeten DNS-Server wurden festgestellt. - [ ] jeder DNS-Server wurde einzeln abgefragt. - [ ] Antwortcodes wurden ausgewertet. - [ ] A- und AAAA-Records wurden getrennt geprüft. - [ ] CNAME-Ketten wurden bei Bedarf verfolgt. - [ ] DNS-Suffix und Suchliste wurden kontrolliert. - [ ] DHCP- und VPN-DNS-Einstellungen wurden berücksichtigt. - [ ] die Hosts-Datei wurde geprüft. - [ ] der DNS-Cache wurde vor einer Bereinigung bewertet. - [ ] die Erreichbarkeit des DNS-Servers wurde geprüft. - [ ] UDP und TCP Port 53 wurden berücksichtigt. - [ ] die zuständige Zone wurde bestimmt. - [ ] der benötigte Resource Record wurde geprüft. - [ ] autoritative Server wurden ermittelt. - [ ] Delegation und Replikation wurden berücksichtigt. - [ ] Rekursion und Weiterleitungen wurden geprüft. - [ ] Split-DNS wurde berücksichtigt. - [ ] IPv4 und IPv6 wurden getrennt betrachtet. - [ ] DNSSEC wurde bei `SERVFAIL` berücksichtigt. - [ ] anwendungseigene oder verschlüsselte DNS-Auflösung wurde geprüft. - [ ] eine Paketaufzeichnung erfolgte nur mit Berechtigung. - [ ] vor Änderungen wurde der Ausgangszustand dokumentiert. - [ ] nur eine kontrollierbare Änderung wurde durchgeführt. - [ ] die DNS-Abfrage wurde nach der Änderung wiederholt. - [ ] die ursprüngliche Anwendung wurde erneut getestet. - [ ] weitere interne und externe Namen wurden geprüft. - [ ] Ursache, Maßnahme und Nachweis wurden dokumentiert. --- **34. Schnellreferenz** | Fehlerbild | wahrscheinlicher Untersuchungsbereich | |---|---| | IP funktioniert, vollständiger Name nicht | DNS-Server, Zone, Record oder DNS-Transport | | vollständiger Name funktioniert, Kurzname nicht | DNS-Suffix oder Suchliste | | interne Namen funktionieren, externe nicht | Forwarder, Rekursion, Root Hints oder Firewall | | externe Namen funktionieren, interne nicht | falscher DNS-Server, interne Zone oder Split-DNS | | nur ein Client betroffen | Clientkonfiguration, Cache, Hosts-Datei oder Anwendung | | alle Clients betroffen | zentraler DNS-Dienst, Zone, Netzwerkpfad oder Firewall | | nur VPN-Clients betroffen | VPN-DNS, Suchdomäne, Route oder Split-DNS | | ein DNS-Server liefert falsche Daten | Zone, Replikation oder veralteter Record | | `NXDOMAIN` | Name aus Sicht des antwortenden Servers nicht vorhanden | | `SERVFAIL` | Serververarbeitung, Delegation, Forwarder oder DNSSEC | | Zeitüberschreitung | Erreichbarkeit, Port 53, Überlastung oder Rückweg | | richtige IP wird geliefert, Dienst scheitert | kein reiner DNS-Fehler; Port, Firewall, Anwendung oder Zielsystem | | A funktioniert, AAAA führt zum Fehler | IPv6-Record oder IPv6-Datenpfad | | Kommandozeile funktioniert, Browser nicht | Browsercache, Proxy oder verschlüsseltes DNS | | wechselnde Antworten | mehrere DNS-Server, Round-Robin, Split-DNS oder Replikation | | Reverse Lookup scheitert | PTR-Record oder Reverse-Lookup-Zone | --- **Merksatz** > Wenn die IP-Adresse funktioniert, der Name aber nicht, wird die Namensauflösung gezielt und schichtweise geprüft: verwendeter DNS-Server, vollständiger Name, Antwortcode, Record, Zone, Weiterleitung und tatsächlicher Resolver. Eine erreichbare IP-Adresse grenzt den Fehler ein, beweist aber weder einen DNS-Server-Ausfall noch die Funktionsfähigkeit des angesprochenen Dienstes. --- **Quellen und weiterführende Dokumentation** - [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 – Troubleshoot DNS client name resolution issues](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/troubleshoot-dns-client-resolution-issues) - [Microsoft Learn – Troubleshooting DNS servers](https://learn.microsoft.com/en-us/windows-server/networking/dns/troubleshoot/troubleshoot-dns-server) - [Microsoft Learn – DNS forwarder-related resolution failures](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-forwarders-related-failures) - [Microsoft Learn – Best practices for DNS client settings](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/best-practices-for-dns-client-settings) - [RFC 1034 – Domain Names: Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034) - [RFC 1035 – Domain Names: Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035) - [RFC 2181 – Clarifications to the DNS Specification](https://www.rfc-editor.org/rfc/rfc2181) - [RFC 9499 – DNS Terminology](https://www.rfc-editor.org/rfc/rfc9499) - [Wireshark – Display Filter Reference: DNS](https://www.wireshark.org/docs/dfref/d/dns.html) # 6.4 Host erreichbar, Dienst nicht – Ports, Firewall und Anwendungen systematisch prüfen Ein Zielsystem kann per IP-Adresse erreichbar sein, während der benötigte Dienst trotzdem nicht funktioniert. Typische Beispiele: - Ping auf den Server funktioniert, die Website öffnet sich jedoch nicht. - Der Servername wird korrekt aufgelöst, eine SSH-Verbindung scheitert aber. - Eine Dateifreigabe ist nicht erreichbar, obwohl der Server antwortet. - Die Anwendung meldet eine Zeitüberschreitung. - Ein TCP-Port ist erreichbar, die Anwendung liefert dennoch einen Fehler. - Der Dienst funktioniert lokal auf dem Server, aber nicht von anderen Geräten. - Einige Clients erreichen den Dienst, andere nicht. - Eine Verbindung funktioniert intern, über VPN oder Internet jedoch nicht. Die Erreichbarkeit eines Hosts und die Erreichbarkeit eines Dienstes sind getrennte Prüfungen. ```text Host erreichbar ↓ Zielport erreichbar ↓ TCP- oder UDP-Kommunikation funktioniert ↓ Dienst nimmt Anfragen an ↓ Anwendungsprotokoll funktioniert ↓ Authentifizierung und Berechtigung funktionieren ``` Ein erfolgreicher Ping bestätigt deshalb weder einen offenen Port noch einen funktionsfähigen Dienst. --- **1. Fehlerbild exakt erfassen** Vor der technischen Prüfung müssen die betroffene Verbindung und der erwartete Dienst eindeutig bestimmt werden. Zu dokumentieren sind: - Quellgerät, - Quell-IP-Adresse, - Zielname, - Ziel-IP-Adresse, - Zielport, - Transportprotokoll TCP oder UDP, - verwendete Anwendung, - Zeitpunkt des Fehlers, - genaue Fehlermeldung, - betroffene Benutzer oder Standorte, - funktionierende Vergleichsverbindungen, - letzte bekannte Funktionsfähigkeit, - kürzlich vorgenommene Änderungen. Beispiel: ```text Quelle: Client-17, 192.0.2.117 Ziel: appserver.example.test, 192.0.2.50 Dienst: HTTPS Transport: TCP Zielport: 443 Fehler: Verbindung nach etwa 20 Sekunden abgebrochen Betroffen: Clients im VLAN 30 Nicht betroffen: Clients im VLAN 20 ``` Die Aussage „Der Server geht nicht“ reicht nicht aus. Benötigt wird eine genaue Beschreibung der betroffenen Kommunikationsbeziehung. --- **2. Host-Erreichbarkeit und Dienst-Erreichbarkeit unterscheiden** Ein Ping verwendet ICMP. Anwendungsdienste verwenden dagegen meistens TCP oder UDP. Beispiel: ```text ping appserver.example.test ``` Ein erfolgreicher Ping kann bestätigen: - Namensauflösung liefert eine Adresse, - ICMP-Anfrage erreicht das Ziel, - ICMP-Antwort gelangt zurück. Er beweist nicht: - dass TCP Port 443 geöffnet ist, - dass eine Firewall den Anwendungsverkehr erlaubt, - dass der Webserver läuft, - dass TLS funktioniert, - dass die Anwendung eine gültige Antwort liefert, - dass der Benutzer zugriffsberechtigt ist. Umgekehrt kann ein Dienst funktionieren, obwohl Ping scheitert. ICMP kann gezielt blockiert sein, während der benötigte TCP- oder UDP-Port erlaubt bleibt. --- **3. Den tatsächlich benötigten Port bestimmen** Vor einem Porttest muss bekannt sein, welchen Zielport und welches Transportprotokoll die Anwendung verwendet. Beispiele: | Dienst | Transport | typischer Port | |---|---:|---:| | HTTP | TCP | 80 | | HTTPS | TCP | 443 | | SSH | TCP | 22 | | RDP | TCP und UDP | 3389 | | SMB | TCP | 445 | | DNS | UDP und TCP | 53 | | SMTP | TCP | 25 | | IMAP mit TLS | TCP | 993 | | PostgreSQL | TCP | 5432 | | MySQL | TCP | 3306 | | LDAP | TCP und teilweise UDP | 389 | | LDAPS | TCP | 636 | | NTP | UDP | 123 | | DHCP | UDP | 67 und 68 | Diese Ports sind typische Standardwerte. Anwendungen können abweichend konfiguriert sein. Zu prüfen sind daher: - Herstellerdokumentation, - Serverkonfiguration, - Reverse-Proxy-Konfiguration, - Container-Portzuordnung, - Load-Balancer-Konfiguration, - Firewallregeln, - tatsächlich geöffnete Sockets, - eventuell verwendete dynamische Ports. Ein Test des falschen Ports liefert keine verwertbare Aussage über den benötigten Dienst. --- **4. Zieladresse und Zielport gemeinsam prüfen** Ein Port gehört immer zu einer konkreten IP-Adresse und einem Transportprotokoll. ```text 192.0.2.50:443/TCP ``` Bei mehreren IP-Adressen muss geprüft werden, welche Adresse die Anwendung tatsächlich verwendet. Mögliche Fehler: - DNS liefert eine alte Adresse, - IPv6 wird gegenüber IPv4 bevorzugt, - der Dienst lauscht nur auf einer bestimmten Schnittstelle, - ein Load Balancer verwendet eine andere Adresse, - NAT leitet auf ein falsches Ziel weiter, - ein Client verwendet einen Proxy, - die Anwendung greift auf einen anderen Hostnamen zurück. Vor der Bewertung eines Porttests sollten deshalb Zielname und aufgelöste Adressen dokumentiert werden. **Windows** ```powershell Resolve-DnsName ``` **Linux und macOS** ```bash dig ``` --- **5. TCP-Port vom Client aus testen** **Windows** ```powershell Test-NetConnection -Port ``` Kurzform: ```powershell tnc -Port ``` Beispiel: ```powershell Test-NetConnection appserver.example.test -Port 443 ``` Wichtig ist insbesondere: ```text TcpTestSucceeded : True ``` oder: ```text TcpTestSucceeded : False ``` **PowerShell 7** ```powershell Test-Connection -TcpPort ``` **Linux und macOS** ```bash nc -vz ``` Beispiel: ```bash nc -vz appserver.example.test 443 ``` Alternativ kann bei bestimmten Diensten ein protokollspezifischer Test sinnvoller sein: ```bash curl -v http://:/ curl -vk https://:/ ``` > Ein erfolgreicher TCP-Porttest bestätigt zunächst nur, dass eine TCP-Verbindung aufgebaut werden konnte. Er beweist nicht, dass die Anwendung fachlich korrekt arbeitet. --- **6. TCP-Ergebnisse richtig einordnen** | Beobachtung | technische Bedeutung | möglicher Untersuchungsbereich | |---|---|---| | Verbindung erfolgreich | TCP-Verbindungsaufbau abgeschlossen | Anwendung, Protokoll, TLS, Authentifizierung oder Inhalt prüfen | | sofort abgelehnt | Ziel oder Zwischenkomponente sendet aktiv eine Ablehnung | kein Listener, falscher Port, Firewall mit Reject oder Dienst beendet | | Zeitüberschreitung | keine verwertbare Antwort innerhalb der Wartezeit | Firewall-Drop, Routing, Rückweg, NAT, Zielsystem oder Paketverlust | | Verbindung wird sofort zurückgesetzt | TCP-RST beendet die Verbindung | Dienst, Proxy, Firewall, Protokollfehler oder Anwendung | | Verbindung beginnt und bleibt hängen | TCP besteht, Anwendung antwortet nicht vollständig | Dienst, Backend, Überlastung, TLS, MTU oder Abhängigkeit | | Verbindung funktioniert nur per IP | Namensauflösung, Zertifikat, virtueller Host oder Proxy | | Verbindung funktioniert nur per Name | Anwendung benötigt Hostnamen, SNI oder virtuellen Host | | Port ist offen, Anwendung meldet Fehler | kein reiner Portfehler | Protokoll, Anwendung, Backend, Authentifizierung oder Berechtigung | Eine Zeitüberschreitung beweist nicht automatisch, dass eine Firewall die Verbindung blockiert. Auch ein fehlender Rückweg, ein falsches NAT-Ziel oder ein nicht reagierendes System kann dasselbe Verhalten verursachen. --- **7. TCP-Verbindungsaufbau verstehen** Der normale TCP-Verbindungsaufbau verwendet drei Schritte: ```text Client → Server: SYN Server → Client: SYN, ACK Client → Server: ACK ``` Danach kann die Anwendungsübertragung beginnen. Mögliche Abweichungen: | Paketfolge | mögliche Einordnung | |---|---| | SYN, SYN/ACK, ACK | TCP-Verbindung wurde aufgebaut | | wiederholte SYN-Pakete ohne Antwort | Paketverlust, Firewall-Drop, Routing, Ziel oder Rückweg | | SYN, danach RST/ACK | Port geschlossen oder Verbindung aktiv abgelehnt | | SYN, SYN/ACK, danach kein ACK | Rückweg zum Client, Client-Firewall oder asymmetrischer Pfad | | vollständiger Handshake, danach RST | Anwendung, Proxy oder Protokoll beendet die Verbindung | | vollständiger Handshake, keine Nutzdatenantwort | Dienst hängt, Backend wartet oder Anwendungsproblem | | wiederholte Übertragungen | Paketverlust, Überlastung, MTU oder instabiler Datenpfad | Diese Unterscheidung ist mit einer Paketaufzeichnung möglich. --- **8. UDP-Dienste getrennt betrachten** UDP besitzt keinen TCP-Handshake. Deshalb lässt sich ein UDP-Port nicht genauso zuverlässig wie ein TCP-Port mit einem einfachen Verbindungsversuch bewerten. Beispiel: ```bash nc -vzu ``` Ein solcher Test kann Pakete senden. Eine Erfolgsmeldung beweist jedoch nicht zwingend, dass: - der UDP-Dienst läuft, - das Paket den Server erreicht, - der Dienst die Anfrage verarbeitet, - eine Antwort zurückkommt, - die Anwendung das richtige Protokoll gesendet hat. Für UDP sollte möglichst ein protokollspezifisches Werkzeug verwendet werden. Beispiele: **DNS** ```bash dig @ ``` **NTP** ```bash ntpdate -q ``` Je nach System können andere Werkzeuge erforderlich sein. Mögliche UDP-Ergebnisse: | Beobachtung | mögliche Einordnung | |---|---| | gültige Anwendungsantwort | Hin- und Rückweg sowie Dienst grundsätzlich funktionsfähig | | ICMP Port Unreachable | am Zielport lauscht wahrscheinlich kein UDP-Dienst | | keine Antwort | Dienst antwortet nicht, Firewall, Paketverlust, falsche Anfrage oder Protokollverhalten | | Antwort nur bei kleinen Anfragen | Fragmentierung, MTU, EDNS oder Filter | | lokal funktioniert, entfernt nicht | Bind-Adresse, Firewall, Routing oder Zugriffsliste | Keine UDP-Antwort ist deshalb weniger eindeutig als eine erfolgreiche oder abgelehnte TCP-Verbindung. --- **9. Auf dem Server prüfen, ob der Dienst lauscht** Ein Dienst muss einen Socket auf der vorgesehenen Adresse und dem vorgesehenen Port geöffnet haben. **Windows** ```powershell Get-NetTCPConnection -State Listen Get-NetTCPConnection -LocalPort Get-NetUDPEndpoint -LocalPort ``` Alternativ: ```powershell netstat -ano netstat -ano | findstr : ``` Die zugehörige Prozess-ID kann geprüft werden mit: ```powershell Get-Process -Id ``` oder: ```cmd tasklist /FI "PID eq " ``` **Linux** ```bash ss -lntp ss -lntp 'sport = :' ss -lnup ``` Alternativ: ```bash sudo lsof -nP -iTCP: -sTCP:LISTEN sudo lsof -nP -iUDP: ``` **macOS** ```bash sudo lsof -nP -iTCP: -sTCP:LISTEN sudo lsof -nP -iUDP: ``` Zu prüfen sind: - ist ein Listener vorhanden? - ist es der erwartete Prozess? - verwendet er TCP oder UDP? - lauscht er auf dem erwarteten Port? - lauscht er auf der richtigen IP-Adresse? - verwendet er IPv4, IPv6 oder beides? - läuft möglicherweise ein anderer Prozess auf dem Port? - wurde die Konfiguration nach einer Änderung neu geladen? --- **10. Bind-Adresse richtig bewerten** Ein Dienst kann auf unterschiedlichen Adressen lauschen. Beispiele: ```text 127.0.0.1:8080 0.0.0.0:8080 192.0.2.50:8080 [::1]:8080 [::]:8080 ``` Typische Bedeutung: | Bind-Adresse | Bedeutung | |---|---| | `127.0.0.1` | nur lokales IPv4-Loopback | | `0.0.0.0` | grundsätzlich alle IPv4-Schnittstellen | | konkrete IPv4-Adresse | nur diese IPv4-Adresse | | `::1` | nur lokales IPv6-Loopback | | `::` | grundsätzlich IPv6 und abhängig vom System eventuell zusätzlich IPv4 | Ein Dienst, der ausschließlich auf `127.0.0.1` lauscht, kann lokal funktionieren und von entfernten Clients trotzdem nicht erreichbar sein. Nach Änderungen an Netzwerkschnittstellen oder IP-Adressen kann ein Dienst weiterhin an eine nicht mehr vorhandene oder falsche Adresse gebunden sein. --- **11. Dienststatus und Protokolle prüfen** Ein vorhandener Prozess bedeutet nicht automatisch, dass der Dienst betriebsbereit ist. **Windows** ```powershell Get-Service Get-Service -Name ``` **Linux mit systemd** ```bash systemctl status journalctl -u ``` **macOS** Je nach Installationsart können `launchctl`, anwendungseigene Werkzeuge oder Protokolldateien verwendet werden. Zu prüfen sind: - Dienststatus, - Startzeitpunkt, - wiederholte Neustarts, - Konfigurationsfehler, - fehlende Zertifikate, - belegter Port, - fehlende Berechtigungen, - nicht erreichbare Datenbank, - nicht erreichbarer Verzeichnisdienst, - Speicher- oder Datenträgerprobleme, - abgelaufene Lizenzen, - erschöpfte Verbindungen, - interne Warteschlangen, - Fehler unmittelbar zum Störungszeitpunkt. Ein Dienst kann als „running“ angezeigt werden und dennoch keine funktionsfähigen Anfragen bearbeiten. --- **12. Dienst lokal auf dem Server testen** Der lokale Test trennt die Anwendung vom entfernten Netzwerkpfad. Beispiele: ```bash curl -v http://127.0.0.1:/ curl -vk https://127.0.0.1:/ ``` Oder: ```bash nc -vz 127.0.0.1 nc -vz ``` Sinnvolle Vergleichstests: 1. Verbindung über `localhost`, 2. Verbindung über Loopback-Adresse, 3. Verbindung über die Server-IP, 4. Verbindung über den vollständigen Namen, 5. Verbindung von einem Client im selben Netz, 6. Verbindung aus dem betroffenen Netz. | Ergebnis | mögliche Einordnung | |---|---| | lokal und entfernt scheitern | Dienst, Listener oder lokale Konfiguration | | Loopback funktioniert, Server-IP lokal nicht | Bind-Adresse oder lokale Firewall | | lokal funktioniert, entfernt nicht | Firewall, Routing, ACL, NAT oder Netzwerkpfad | | IP funktioniert, Name nicht | DNS, virtueller Host, SNI oder Zertifikat | | Porttest funktioniert, Protokolltest nicht | Anwendung oder Protokoll | | ein Netz funktioniert, anderes nicht | Firewallregel, Routing, Segmentierung oder Rückweg | --- **13. Lokale Firewall des Servers prüfen** Auch wenn der Dienst lauscht, kann die lokale Firewall eingehende Verbindungen blockieren. Zu prüfen sind: - richtige Richtung der Regel, - richtiges Transportprotokoll, - richtiger lokaler Port, - richtige Quellnetze, - richtiges Netzwerkprofil, - richtige Anwendung oder Dienstzuordnung, - IPv4 und IPv6, - aktive Firewallzone, - Priorität und Reihenfolge der Regeln, - protokollierte Ablehnungen, - zentrale Richtlinien. **Windows** ```powershell Get-NetFirewallProfile Get-NetFirewallRule -Enabled True Get-NetFirewallPortFilter Get-NetFirewallAddressFilter ``` Eine genauere Zuordnung kann über gemeinsame Filter- und Regelobjekte erforderlich sein. **Linux mit firewalld** ```bash sudo firewall-cmd --get-active-zones sudo firewall-cmd --list-all ``` **Linux mit nftables** ```bash sudo nft list ruleset ``` **Linux mit iptables** ```bash sudo iptables -L -n -v sudo ip6tables -L -n -v ``` Firewallregeln sollten nicht pauschal deaktiviert werden. Eine kontrollierte, auf Quelle, Ziel, Port und Protokoll begrenzte Prüfung ist vorzuziehen. --- **14. Client-Firewall und Ausgangsregeln** Nicht nur der Server kann Verbindungen blockieren. Auch auf dem Client können ausgehende Regeln, Sicherheitssoftware oder Endpoint-Richtlinien wirken. Mögliche Ursachen: - ausgehender Zielport gesperrt, - Anwendung darf keine Verbindung herstellen, - Netzwerkprofil wurde geändert, - Sicherheitssoftware blockiert den Prozess, - TLS-Inspection greift ein, - lokale Proxyrichtlinie erzwingt einen anderen Pfad, - Host-Firewall verwirft Rückpakete, - EDR-System beendet die Verbindung. Wenn andere Anwendungen denselben Zielport erreichen, die betroffene Anwendung aber nicht, sollte zusätzlich eine prozessbezogene Einschränkung untersucht werden. --- **15. Netzwerk-Firewalls und ACLs** Zwischen Client und Server können mehrere Kontrollstellen liegen: ```text Client ↓ Client-Firewall ↓ VLAN- oder Router-ACL ↓ zentrale Firewall ↓ VPN-Gateway oder NAT ↓ Server-Firewall ↓ Dienst ``` Zu prüfen sind: - Quell-IP-Adresse, - Ziel-IP-Adresse, - Zielport, - Transportprotokoll, - Sicherheitszone, - Regelreihenfolge, - Zeitplan der Regel, - Benutzer- oder Anwendungsabhängigkeit, - NAT vor oder nach der Regelprüfung, - Sitzungsstatus, - Trefferzähler, - Protokolleinträge, - Rückweg. Eine Regel für TCP Port 443 erlaubt nicht automatisch UDP Port 443. Ebenso erlaubt eine Regel für IPv4 nicht zwingend IPv6-Verkehr. --- **16. Stateful Firewall und Rückverkehr** Stateful Firewalls verfolgen den Zustand einer Verbindung. Bei einer erlaubten ausgehenden TCP-Verbindung wird der passende Rückverkehr normalerweise über den Verbindungszustand zugeordnet. Fehler können entstehen durch: - asymmetrisches Routing, - Rückpakete passieren eine andere Firewall, - Firewallzustand ist abgelaufen, - NAT-Zuordnung fehlt, - Clusterknoten teilen Zustände nicht korrekt, - Quelladresse wird unerwartet geändert, - Verbindung bleibt länger inaktiv als der Session-Timeout, - Rückverkehr entspricht nicht der gespeicherten Sitzung. Typisches Symptom: ```text Client sendet SYN. Server antwortet mit SYN/ACK. Client erhält die Antwort nicht. ``` In diesem Fall ist der Dienst erreichbar, aber der Rückweg oder eine zustandsabhängige Verarbeitung ist gestört. --- **17. Routing und Rückweg prüfen** Ein erreichbarer Host über ICMP bedeutet nicht, dass jeder Anwendungsverkehr denselben Pfad nimmt oder gleich behandelt wird. **Windows** ```powershell tracert Test-NetConnection -TraceRoute Get-NetRoute ``` **Linux** ```bash traceroute tracepath ip route ip route get ``` **macOS** ```bash traceroute netstat -rn route -n get ``` Zu prüfen sind: - Route vom Client zum Server, - Rückroute vom Server zum Client, - Quell-IP-Auswahl, - mehrere Standardgateways, - Policy-Based Routing, - VPN-Routen, - überlappende Netze, - asymmetrische Wege, - segmentabhängige Firewallregeln. Die Rückroute muss vom Server oder seinem Gateway zum tatsächlichen Quellnetz führen. --- **18. NAT und Portweiterleitung** Bei Verbindungen über Netzgrenzen kann NAT die Ziel- oder Quelladresse verändern. Beispiel: ```text öffentliche Adresse: 198.51.100.20:443 NAT-Ziel: 192.0.2.50:8443 ``` Zu prüfen sind: - richtige öffentliche Zieladresse, - richtiger externer Port, - richtiges internes Ziel, - richtiger interner Port, - TCP oder UDP, - Quell-NAT, - Rückroute, - Firewallregel passend zur NAT-Verarbeitung, - konkurrierende Portweiterleitung, - Hairpin-NAT bei Zugriff von intern, - Ablauf der NAT-Sitzung. Ein lokal erreichbarer Dienst beweist nicht, dass die Portweiterleitung korrekt ist. --- **19. Container und virtuelle Maschinen** Bei containerisierten oder virtualisierten Diensten existieren zusätzliche Netzwerkschichten. Mögliche Fehler: - Container läuft, Port wurde aber nicht veröffentlicht, - Host-Port zeigt auf den falschen Container-Port, - Dienst lauscht im Container nur auf Loopback, - Container-Netzwerk fehlt, - Firewall auf dem Host blockiert, - Reverse Proxy erreicht den Container nicht, - falscher DNS-Name im internen Netzwerk, - virtuelle Maschine besitzt eine andere IP-Adresse, - Sicherheitsgruppe erlaubt den Port nicht, - Dienst wurde auf einen anderen Host verschoben. **Docker** ```bash docker ps docker port docker inspect ``` Beispiel einer Portzuordnung: ```text 0.0.0.0:8443 → Container:443/TCP ``` Ein Test auf Host-Port 443 wäre in diesem Beispiel ungeeignet, wenn der Dienst ausschließlich über Host-Port 8443 veröffentlicht wurde. --- **20. Reverse Proxy und Load Balancer** Zwischen Client und Anwendung können Reverse Proxy oder Load Balancer liegen. ```text Client ↓ Reverse Proxy oder Load Balancer ↓ Backend-Anwendung ``` Mögliche Fehlerbilder: - Frontend-Port ist erreichbar, Backend jedoch nicht, - falscher Hostname wird weitergeleitet, - Health Check schlägt fehl, - Backend-Port wurde geändert, - Zertifikat passt nicht, - virtuelle Hostkonfiguration fehlt, - Proxy-Zeitüberschreitung ist zu kurz, - ein einzelner Backend-Server ist fehlerhaft, - Sitzungspersistenz führt zu einem defekten Knoten, - Proxy liefert `502`, `503` oder `504`. Typische HTTP-Ergebnisse: | Ergebnis | mögliche Einordnung | |---|---| | `200` | Anfrage grundsätzlich erfolgreich | | `301` oder `302` | Weiterleitung prüfen | | `400` | Anfrage oder Hostheader ungeeignet | | `401` | Authentifizierung erforderlich oder fehlgeschlagen | | `403` | Zugriff durch Anwendung oder Richtlinie verweigert | | `404` | Pfad, virtueller Host oder Routingregel | | `502` | Proxy erhält keine gültige Backend-Antwort | | `503` | Dienst oder Backend nicht verfügbar | | `504` | Zeitüberschreitung zum Backend | Ein erreichbarer Proxy-Port beweist nicht, dass das Backend funktioniert. --- **21. TLS und Zertifikate prüfen** Bei verschlüsselten Diensten folgt nach dem TCP-Verbindungsaufbau der TLS-Handshake. Mögliche Fehler: - Zertifikat abgelaufen, - Zertifikatsname passt nicht zum Hostnamen, - Zertifikatskette unvollständig, - unbekannte Zertifizierungsstelle, - Client- und Serverprotokolle nicht kompatibel, - keine gemeinsame Cipher Suite, - Server Name Indication fehlt oder ist falsch, - Clientzertifikat erforderlich, - TLS-Inspection verändert die Verbindung, - Systemzeit ist falsch. **curl** ```bash curl -vk https://:/ ``` **OpenSSL** ```bash openssl s_client -connect : -servername ``` Dabei können geprüft werden: - ausgehandeltes TLS-Protokoll, - präsentierte Zertifikatskette, - Zertifikatsname, - Gültigkeitszeitraum, - Serverantwort, - Abbruchstelle. Die Option `-k` bei `curl` überspringt die Zertifikatsprüfung und darf nur zur Eingrenzung verwendet werden. Sie ist keine dauerhafte Lösung für Zertifikatsfehler. --- **22. Hostname, SNI und virtuelle Hosts** Mehrere Webanwendungen können dieselbe IP-Adresse und denselben Port verwenden. Der richtige Dienst wird dann anhand des Hostnamens ausgewählt. Beispiel: ```text portal.example.test → 192.0.2.50 wiki.example.test → 192.0.2.50 ``` Ein Test ausschließlich gegen die IP-Adresse kann deshalb: - die falsche Website liefern, - einen Zertifikatsfehler erzeugen, - die Standardseite des Proxys anzeigen, - mit einem HTTP-Fehler enden, - den falschen virtuellen Host verwenden. Geeigneter Test: ```bash curl -vk https://portal.example.test/ ``` Soll eine bestimmte IP-Adresse mit dem korrekten Hostnamen getestet werden: ```bash curl -vk --resolve portal.example.test:443:192.0.2.50 https://portal.example.test/ ``` Damit werden DNS, Ziel-IP, Hostheader und SNI kontrolliert voneinander getrennt. --- **23. Anwendung und Abhängigkeiten prüfen** Ein Dienst kann den Port öffnen, aber intern von weiteren Komponenten abhängig sein. Beispiele: - Datenbank, - Verzeichnisdienst, - DNS, - Dateispeicher, - Nachrichtenwarteschlange, - API, - Lizenzserver, - externer Identitätsanbieter, - Zertifikatsdienst, - weiterer Microservice. Mögliche Symptome: - TCP-Verbindung wird aufgebaut, - Loginseite erscheint, - Anmeldung scheitert, - Anfrage endet mit `500`, - Antwort dauert sehr lange, - nur bestimmte Funktionen sind betroffen, - Health Check meldet Fehler, - Dienst startet, wird aber nicht „ready“. Die Prüfung muss deshalb vom Frontend bis zu den tatsächlich benötigten Abhängigkeiten fortgesetzt werden. --- **24. Authentifizierung und Berechtigung abgrenzen** Eine erfolgreiche Netzwerkverbindung beweist nicht, dass der Benutzer oder Client den Dienst verwenden darf. Zu unterscheiden sind: - Zielport nicht erreichbar, - TLS-Verbindung fehlerhaft, - Benutzer nicht authentifiziert, - falsche Anmeldedaten, - Konto gesperrt, - fehlende Gruppenmitgliedschaft, - Zugriff durch Anwendung verweigert, - Zugriff durch Netzwerkregel verweigert, - Kerberos- oder Zertifikatsfehler, - Mandanten- oder Rollenproblem. Beispiele: ```text Connection timed out ``` weist eher auf Transport oder fehlende Antwort hin. ```text 401 Unauthorized ``` zeigt dagegen, dass eine HTTP-Antwort des Dienstes empfangen wurde und die Untersuchung auf Anwendungsebene fortgesetzt werden muss. --- **25. IPv4 und IPv6 getrennt prüfen** Ein Dienst kann für IPv4 und IPv6 unterschiedlich erreichbar sein. **Windows** ```powershell Resolve-DnsName -Type A Resolve-DnsName -Type AAAA Test-NetConnection -Port Test-NetConnection -Port ``` **Linux und macOS** ```bash curl -4 -v https:/// curl -6 -v https:/// nc -4 -vz nc -6 -vz ``` Mögliche Ursachen: - Dienst lauscht nur auf IPv4, - Dienst lauscht nur auf IPv6, - AAAA-Record zeigt auf eine falsche Adresse, - IPv6-Firewallregel fehlt, - IPv6-Rückroute fehlt, - Client bevorzugt einen nicht funktionsfähigen IPv6-Pfad. IPv6 sollte nicht pauschal deaktiviert werden. Zuerst ist nachzuweisen, welche Adressfamilie den Fehler verursacht. --- **26. MTU, Fragmentierung und große Datenmengen** Ein TCP-Handshake kann funktionieren, während größere Datenübertragungen scheitern. Mögliche Symptome: - Porttest erfolgreich, - kleine Anfragen funktionieren, - TLS-Handshake bleibt hängen, - Dateiübertragung bricht ab, - bestimmte Webseiten laden nur teilweise, - Verbindung über VPN scheitert bei größeren Paketen, - wiederholte TCP-Übertragungen treten auf. Mögliche Ursachen: - ungeeignete MTU, - blockierte ICMP-Meldungen für Path MTU Discovery, - Fragmentierung, - Tunnel-Overhead, - fehlerhafte MSS-Anpassung, - Paketverlust, - Sicherheitskomponente verwirft größere Pakete. **Linux** ```bash tracepath ``` **Windows** ```powershell ping -f -l ``` Der verwendbare Wert hängt von Protokoll-Headern und Datenpfad ab. Ein einzelner Pingwert darf deshalb nicht ungeprüft als endgültige MTU übernommen werden. --- **27. Proxys und anwendungsspezifische Netzwerkwege** Eine Anwendung kann einen anderen Netzwerkpfad verwenden als ein einfacher Porttest. Mögliche Unterschiede: - HTTP-Proxy, - SOCKS-Proxy, - automatische Proxykonfiguration, - VPN-Tunnel, - DNS over HTTPS, - anwendungseigener Resolver, - Service Mesh, - TLS-Inspection, - Cloud-Gateway, - Zero-Trust-Zugriff. Zu prüfen sind: - verwendet die Anwendung einen Proxy? - umgeht das Testwerkzeug den Proxy? - wird der Zielname durch den Proxy aufgelöst? - ist der Proxy selbst erreichbar? - erlaubt der Proxy den Zielport? - existiert eine Ausnahmeliste? - wird die Verbindung durch Benutzer- oder Gerätestatus gesteuert? Ein erfolgreicher direkter Test beweist nicht, dass der von der Anwendung verwendete Proxyweg funktioniert. --- **28. Sporadische und lastabhängige Fehler** Nicht jeder Dienstfehler besteht dauerhaft. Mögliche Ursachen: - Verbindungsgrenze erreicht, - Quellports erschöpft, - überlasteter Server, - Load Balancer verteilt auf einen defekten Knoten, - Firewall-Sitzungstabelle ausgelastet, - Paketverlust, - Dienst startet wiederholt neu, - Datenbankverbindungen erschöpft, - Timeouts zwischen Proxy und Backend, - DNS liefert wechselnde Ziele, - automatische Skalierung reagiert zu langsam. **Windows** ```powershell Get-NetTCPConnection Get-Counter '\TCPv4\Connections Established' ``` **Linux** ```bash ss -s ss -ant ``` Wiederholte Tests sollten mit Zeitstempel durchgeführt werden. **PowerShell** ```powershell 1..10 | ForEach-Object { Get-Date Test-NetConnection -Port Start-Sleep -Seconds 2 } ``` **Bash** ```bash for i in {1..10}; do date nc -vz sleep 2 done ``` Zu vergleichen sind: - Erfolg oder Fehler, - Antwortzeit, - Zieladresse, - betroffener Backend-Server, - Zeitpunkt, - gleichzeitige Last, - Firewall- und Anwendungsprotokolle. --- **29. Paketaufzeichnung einsetzen** Eine Paketaufzeichnung kann zeigen: - ob der Client ein SYN sendet, - ob das Ziel mit SYN/ACK oder RST antwortet, - ob Pakete erneut übertragen werden, - ob die Verbindung nach dem Handshake abbricht, - ob TLS beginnt, - ob eine Anwendungsantwort zurückkommt, - ob ICMP-Fehlermeldungen auftreten, - ob IPv4 oder IPv6 verwendet wird, - ob die tatsächliche Zieladresse stimmt, - ob Hin- und Rückweg vollständig sind. **Wireshark-Filter** ```text ip.addr == tcp.port == udp.port == tcp.flags.syn == 1 tcp.flags.reset == 1 tcp.analysis.retransmission icmp icmpv6 tls http ``` Für eine einzelne TCP-Verbindung kann nach Auswahl eines Pakets zusätzlich der zugehörige TCP-Stream gefiltert werden. **Typische Beobachtungen** | Paketaufzeichnung | mögliche Einordnung | |---|---| | kein Verbindungsversuch sichtbar | Anwendung, Proxy, Cache oder falsche Schnittstelle | | SYN verlässt Client, keine Antwort | Firewall-Drop, Routing, Ziel oder Rückweg | | SYN wird mit RST beantwortet | kein Listener oder aktive Ablehnung | | SYN/ACK erreicht Client, Client antwortet nicht | Client-Firewall, lokaler Stack oder falscher Zustand | | TCP-Handshake vollständig, danach TLS-Fehler | Zertifikat, SNI, Protokoll oder Cipher | | TCP-Handshake vollständig, HTTP `401` | Authentifizierung | | TCP-Handshake vollständig, HTTP `403` | Berechtigung oder Richtlinie | | TCP-Handshake vollständig, HTTP `502` | Proxy- oder Backend-Problem | | viele Wiederholungen | Paketverlust, Überlastung, MTU oder Datenpfad | | Verbindung wird durch RST beendet | Anwendung, Firewall, Proxy oder Betriebssystem | Paketaufzeichnungen dürfen nur mit entsprechender Berechtigung erstellt und müssen geschützt gespeichert werden. --- **30. Vergleichstests systematisch verwenden** Vergleichstests helfen, die fehlerhafte Grenze einzugrenzen. Sinnvolle Vergleiche: | Vergleich | mögliche Erkenntnis | |---|---| | betroffener und funktionierender Client | Clientkonfiguration oder Netzsegment | | Zielname und Ziel-IP | DNS, SNI oder virtueller Host | | IPv4 und IPv6 | Adressfamilie oder Datenpfad | | lokaler und entfernter Zugriff | Dienst oder Netzwerk | | gleiches VLAN und anderes VLAN | Routing, ACL oder Firewall | | internes Netz und VPN | VPN-Regel, Route oder DNS | | Frontend und Backend direkt | Proxy oder Load Balancer | | erster und zweiter Server | einzelnes Zielsystem oder zentraler Pfad | | kleiner und großer Datentransfer | MTU, Paketverlust oder Überlastung | | TCP-Porttest und Protokolltest | Transport oder Anwendung | Dabei sollte jeweils nur eine Variable verändert werden. --- **31. Praxisfall A: Ping funktioniert, HTTPS-Port nicht** **Symptom** - Server antwortet auf Ping, - Name wird korrekt aufgelöst, - TCP Port 443 läuft in eine Zeitüberschreitung, - andere Server im selben Netz sind erreichbar. **Prüfung** 1. Zieladresse dokumentieren. 2. TCP Port 443 vom Client testen. 3. Listener auf dem Server prüfen. 4. lokalen HTTPS-Test auf dem Server durchführen. 5. Server-Firewall kontrollieren. 6. Netzwerk-Firewall und Trefferprotokolle prüfen. 7. Paketaufzeichnung auf Client und Server vergleichen. **Mögliche Ursache** Der Webserver läuft und lauscht auf Port 443. Nach einer Netzsegmentierung fehlt jedoch die Freigabe vom neuen Client-VLAN zum Server. **Nachprüfung** - TCP Port 443 ist aus dem vorgesehenen VLAN erreichbar, - HTTPS liefert eine gültige Antwort, - nicht vorgesehene Quellnetze bleiben gesperrt, - Firewallregel ist dokumentiert, - ursprüngliche Anwendung funktioniert. --- **32. Praxisfall B: Dienst funktioniert lokal, aber nicht entfernt** **Symptom** - lokaler Aufruf über `localhost` funktioniert, - entfernter Porttest wird abgelehnt, - der Prozess läuft, - auf dem Server ist kein allgemeiner Listener sichtbar. **Prüfung** 1. Listener und Bind-Adresse feststellen. 2. Loopback und Server-IP lokal vergleichen. 3. Dienstkonfiguration prüfen. 4. nach einer Änderung den Dienst kontrolliert neu laden. 5. lokale Firewall berücksichtigen. 6. entfernten Test wiederholen. **Mögliche Ursache** Der Dienst lauscht ausschließlich auf `127.0.0.1`. **Nachprüfung** - Dienst lauscht auf der vorgesehenen Serveradresse, - lokaler Zugriff funktioniert, - entfernter Zugriff aus erlaubten Netzen funktioniert, - Firewall begrenzt den Zugriff weiterhin, - keine unnötige öffentliche Freigabe wurde geschaffen. --- **33. Praxisfall C: Port 443 ist offen, Website liefert 502** **Symptom** - TCP Port 443 ist erreichbar, - TLS-Verbindung wird aufgebaut, - Reverse Proxy antwortet mit `502 Bad Gateway`, - Backend-Anwendung ist nicht direkt erreichbar. **Prüfung** 1. Proxy-Antwort dokumentieren. 2. Proxy-Protokolle prüfen. 3. Backend-Ziel und Backend-Port feststellen. 4. Verbindung vom Proxy zum Backend testen. 5. Listener der Backend-Anwendung prüfen. 6. Container- oder Dienststatus kontrollieren. 7. Namensauflösung innerhalb des Proxy-Netzes prüfen. **Mögliche Ursache** Nach einer Änderung verwendet die Backend-Anwendung einen neuen Port. Die Proxy-Konfiguration zeigt weiterhin auf den alten Port. **Nachprüfung** - Proxy erreicht das richtige Backend, - Backend-Health-Check ist erfolgreich, - HTTPS-Aufruf liefert die erwartete Anwendung, - weitere virtuelle Hosts funktionieren, - Konfigurationsänderung ist dokumentiert. --- **34. Praxisfall D: Einige Clients erreichen den Dienst, andere nicht** **Symptom** - Clients im VLAN 20 können eine Anwendung öffnen, - Clients im VLAN 30 erhalten eine Zeitüberschreitung, - beide Gruppen lösen denselben Namen zur selben IP-Adresse auf, - der Dienst funktioniert lokal. **Prüfung** 1. Quell-IP-Adressen beider Clients erfassen. 2. Route und Gateway vergleichen. 3. Porttest aus beiden Netzen durchführen. 4. Firewallregeln und Trefferzähler prüfen. 5. Server-Firewall auf Quellnetzbegrenzungen untersuchen. 6. Paketaufzeichnung am Server durchführen. **Mögliche Ursache** Die Server-Firewall erlaubt Port 8443 nur aus dem alten VLAN 20. **Nachprüfung** - vorgesehene Clients aus VLAN 30 erreichen den Dienst, - VLAN 20 funktioniert weiterhin, - andere Netze bleiben gesperrt, - Quellnetze in der Regel sind korrekt dokumentiert. --- **35. Praxisfall E: TCP-Verbindung funktioniert, Anmeldung scheitert** **Symptom** - Zielname wird korrekt aufgelöst, - TCP-Port ist erreichbar, - TLS funktioniert, - Anwendung zeigt eine Anmeldeseite, - Benutzer erhält `401 Unauthorized`. **Prüfung** 1. erfolgreichen Transport dokumentieren. 2. Anwendungsprotokoll und Statuscode auswerten. 3. Benutzerkonto und Authentifizierungsquelle prüfen. 4. Uhrzeit, Zertifikate und gegebenenfalls Kerberos berücksichtigen. 5. funktionierendes Vergleichskonto verwenden. 6. Anwendungs- und Authentifizierungsprotokolle prüfen. **Mögliche Ursache** Der Benutzer ist nicht mehr Mitglied der für die Anwendung berechtigten Gruppe. **Nachprüfung** - Benutzer kann sich nach genehmigter Berechtigungskorrektur anmelden, - TCP- und TLS-Verbindung bleiben unverändert, - Zugriff ist auf vorgesehene Benutzer begrenzt, - Ursache und Berechtigungsänderung sind dokumentiert. --- **36. Ungeeignete Sofortmaßnahmen** Problematisch sind insbesondere: - Firewall vollständig deaktivieren, - beliebige Ports pauschal freigeben, - einen Dienst ungeprüft neu starten, - Server neu starten, ohne den Zustand zu dokumentieren, - Anwendung als Ursache festlegen, nur weil Ping funktioniert, - Netzwerk als Ursache festlegen, obwohl der Dienst keinen Listener besitzt, - Zertifikatsprüfung dauerhaft deaktivieren, - IPv6 pauschal abschalten, - NAT-Regeln ohne Sicherung verändern, - mehrere Firewalls gleichzeitig ändern, - Sicherheitssoftware ungeprüft entfernen, - Container neu erstellen, ohne Volumes und Konfiguration zu prüfen, - produktive Paketaufzeichnungen ungeschützt speichern, - Testzugänge oder temporäre Freigaben dauerhaft bestehen lassen. Vor Änderungen sollten dokumentiert werden: - Quell- und Zieladresse, - Zielport und Transportprotokoll, - DNS-Ergebnis, - Porttestergebnis, - Listener, - Dienststatus, - Firewallregeln, - NAT-Regeln, - Routen, - Protokolle, - Paketbeobachtungen, - Zeitpunkt und Umfang der Störung. --- **37. Vollständige Prüfreihenfolge** 1. betroffene Anwendung und genaue Fehlermeldung erfassen. 2. Quelle, Zielname und Ziel-IP-Adresse dokumentieren. 3. benötigten Zielport bestimmen. 4. TCP oder UDP unterscheiden. 5. Namensauflösung prüfen. 6. Host-Erreichbarkeit nur als Teilprüfung verwenden. 7. Zielport vom betroffenen Client testen. 8. Ergebnis als Erfolg, Ablehnung, Reset oder Zeitüberschreitung einordnen. 9. funktionierenden Vergleichsclient prüfen. 10. IPv4 und IPv6 getrennt betrachten. 11. auf dem Server den Listener prüfen. 12. Prozess zum Listener bestimmen. 13. Bind-Adresse kontrollieren. 14. Dienststatus und Protokolle auswerten. 15. Dienst über Loopback lokal testen. 16. Dienst über die Server-IP lokal testen. 17. protokollspezifischen Test durchführen. 18. lokale Server-Firewall prüfen. 19. Client-Firewall und Sicherheitssoftware berücksichtigen. 20. Netzwerk-Firewalls und ACLs prüfen. 21. Route vom Client zum Server untersuchen. 22. Rückweg vom Server zum Client prüfen. 23. NAT und Portweiterleitungen berücksichtigen. 24. VPN- und Segmentierungsregeln prüfen. 25. Container-, VM- oder Host-Portzuordnungen prüfen. 26. Reverse Proxy oder Load Balancer untersuchen. 27. Backend-Verbindungen testen. 28. TLS, Zertifikat, SNI und Hostnamen prüfen. 29. Anwendung, Authentifizierung und Berechtigung abgrenzen. 30. bei sporadischen Fehlern wiederholte Tests durchführen. 31. bei Bedarf autorisierte Paketaufzeichnung erstellen. 32. konkrete Hypothese formulieren. 33. genau eine kontrollierbare Änderung durchführen. 34. Listener und Dienststatus erneut prüfen. 35. Porttest wiederholen. 36. protokollspezifischen Test wiederholen. 37. ursprüngliche Anwendung erneut testen. 38. funktionierende und nicht vorgesehene Netze kontrollieren. 39. temporäre Freigaben entfernen. 40. Ursache, Maßnahme und Ergebnis dokumentieren. 41. Monitoring oder Präventionsmaßnahme festlegen. --- **38. Dokumentationsbeispiel** ```text Ticket: INC-20644 Beginn: 02.08.2026, etwa 14:20 Uhr Umfang: Clients im VLAN 30 Betroffen: HTTPS-Anwendung auf appserver.example.test Nicht betroffen: Clients im VLAN 20 Verbindung: Quelle: 192.0.2.117 Ziel: appserver.example.test Ziel-IP: 192.0.2.50 Transport: TCP Zielport: 443 Symptom: Der Server antwortet auf ICMP. Die Namensauflösung liefert die korrekte IP-Adresse. Der HTTPS-Aufruf läuft aus VLAN 30 in eine Zeitüberschreitung. Ausgangszustand: - DNS-Auflösung korrekt - ICMP-Antwort vorhanden - TCP Port 443 aus VLAN 30 nicht erreichbar - TCP Port 443 aus VLAN 20 erreichbar - Webserver lauscht auf 0.0.0.0:443 - lokaler HTTPS-Test auf dem Server erfolgreich - Server-Firewall erlaubt beide internen Netze - zentrale Firewall protokolliert verworfene SYN-Pakete aus VLAN 30 Hypothese: Bei der Einrichtung des neuen VLANs wurde die Freigabe zu TCP Port 443 auf dem Anwendungsserver nicht ergänzt. Prüfung: - Quell-IP und Ziel-IP bestätigt - Route zum Server vorhanden - Listener und Dienststatus korrekt - funktionierenden Client aus VLAN 20 verglichen - Firewallregel enthält nur das Quellnetz von VLAN 20 - keine SYN-Pakete aus VLAN 30 erreichen den Server Ursache: Die zentrale Firewallregel erlaubte den HTTPS-Zugriff nur aus VLAN 20. Maßnahme: Das freigegebene Quellobjekt wurde nach Genehmigung um das vorgesehene Clientnetz aus VLAN 30 ergänzt. Ziel und Port blieben unverändert. Nachprüfung: - TCP Port 443 aus VLAN 30 erreichbar - TLS-Handshake erfolgreich - Anwendung liefert HTTP 200 - Anmeldung funktioniert - VLAN 20 funktioniert weiterhin - Zugriff aus nicht freigegebenen Netzen bleibt blockiert - Firewallprotokoll und Trefferzähler geprüft Prävention: - Firewallfreigaben in die VLAN-Abnahme aufnehmen - automatisierten HTTPS-Health-Check aus beiden Clientnetzen einrichten - Änderungen an Netzsegmenten mit einer Kommunikationsmatrix prüfen ``` --- **39. Checkliste „Host erreichbar, Dienst nicht“** - [ ] die betroffene Anwendung wurde eindeutig benannt. - [ ] die genaue Fehlermeldung wurde dokumentiert. - [ ] Quellgerät und Quell-IP-Adresse wurden erfasst. - [ ] Zielname und Ziel-IP-Adresse wurden erfasst. - [ ] der benötigte Zielport wurde bestätigt. - [ ] TCP und UDP wurden unterschieden. - [ ] die Namensauflösung wurde geprüft. - [ ] Ping wurde nicht mit einem Diensttest gleichgesetzt. - [ ] der Zielport wurde vom betroffenen Client getestet. - [ ] Erfolg, Ablehnung, Reset oder Zeitüberschreitung wurden unterschieden. - [ ] ein funktionierender Vergleichsclient wurde geprüft. - [ ] IPv4 und IPv6 wurden getrennt betrachtet. - [ ] ein Listener auf dem Server wurde nachgewiesen. - [ ] der zugehörige Prozess wurde bestimmt. - [ ] die Bind-Adresse wurde kontrolliert. - [ ] der Dienststatus wurde geprüft. - [ ] Dienstprotokolle wurden ausgewertet. - [ ] der Dienst wurde lokal über Loopback getestet. - [ ] der Dienst wurde lokal über die Server-IP getestet. - [ ] ein protokollspezifischer Test wurde durchgeführt. - [ ] die lokale Server-Firewall wurde geprüft. - [ ] die Client-Firewall wurde berücksichtigt. - [ ] Netzwerk-Firewalls und ACLs wurden geprüft. - [ ] Firewallregeln wurden auf Quelle, Ziel, Port und Protokoll geprüft. - [ ] Hin- und Rückroute wurden berücksichtigt. - [ ] asymmetrisches Routing wurde bei Bedarf geprüft. - [ ] NAT und Portweiterleitungen wurden berücksichtigt. - [ ] VPN- und Segmentierungsregeln wurden geprüft. - [ ] Container- oder VM-Portzuordnungen wurden berücksichtigt. - [ ] Reverse Proxy oder Load Balancer wurde geprüft. - [ ] die Verbindung zum Backend wurde getestet. - [ ] TLS und Zertifikate wurden berücksichtigt. - [ ] Hostname, SNI und virtuelle Hosts wurden berücksichtigt. - [ ] Anwendung, Authentifizierung und Berechtigung wurden abgegrenzt. - [ ] MTU und Paketverlust wurden bei passenden Symptomen berücksichtigt. - [ ] anwendungsspezifische Proxys wurden geprüft. - [ ] bei sporadischen Fehlern wurden zeitgestempelte Tests durchgeführt. - [ ] eine Paketaufzeichnung erfolgte nur mit Berechtigung. - [ ] der Ausgangszustand wurde vor Änderungen dokumentiert. - [ ] es wurde nur eine kontrollierbare Änderung durchgeführt. - [ ] der Porttest wurde nach der Änderung wiederholt. - [ ] das Anwendungsprotokoll wurde erneut getestet. - [ ] die ursprüngliche Anwendung wurde erneut geprüft. - [ ] unzulässige Quellnetze bleiben weiterhin gesperrt. - [ ] temporäre Testfreigaben wurden entfernt. - [ ] Ursache, Maßnahme und Nachweis wurden dokumentiert. --- **40. Schnellreferenz** | Fehlerbild | wahrscheinlicher Untersuchungsbereich | |---|---| | Ping funktioniert, TCP-Port nicht | Listener, Firewall, Routing, NAT oder Rückweg | | TCP-Verbindung wird sofort abgelehnt | kein Listener, falscher Port oder aktive Ablehnung | | TCP-Verbindung läuft in Zeitüberschreitung | Firewall-Drop, Routing, NAT, Rückweg oder Ziel | | Port funktioniert lokal, entfernt nicht | Bind-Adresse, Firewall, ACL oder Netzwerkpfad | | Loopback funktioniert, Server-IP lokal nicht | Bind-Adresse oder lokale Firewall | | Port ist offen, Anwendung antwortet nicht | Dienst, Protokoll, Backend oder Überlastung | | TCP funktioniert, TLS scheitert | Zertifikat, SNI, Protokoll oder Cipher | | HTTPS liefert `401` | Authentifizierung | | HTTPS liefert `403` | Berechtigung oder Richtlinie | | HTTPS liefert `502` | Proxy erreicht Backend nicht korrekt | | HTTPS liefert `503` | Dienst oder Backend nicht verfügbar | | HTTPS liefert `504` | Zeitüberschreitung zwischen Proxy und Backend | | nur ein Client betroffen | Client-Firewall, Proxy, Route oder lokale Anwendung | | nur ein Netz betroffen | ACL, Firewall, Routing oder Quellnetzregel | | nur VPN-Clients betroffen | VPN-Route, VPN-Firewall, MTU oder DNS | | intern erreichbar, extern nicht | NAT, Portweiterleitung, externe Firewall oder Provider | | extern erreichbar, intern nicht | Hairpin-NAT, Split-DNS oder interne Firewall | | IP funktioniert, Hostname nicht | DNS, SNI, virtueller Host oder Zertifikat | | IPv4 funktioniert, IPv6 nicht | IPv6-Listener, Firewall, Route oder AAAA-Record | | kleine Anfragen funktionieren, große nicht | MTU, Fragmentierung, Paketverlust oder Timeout | | Verbindung scheitert sporadisch | Last, Porterschöpfung, defektes Backend oder Paketverlust | | UDP-Test bleibt ohne Antwort | Dienst, Firewall, falsche Anfrage oder normales Protokollverhalten | | SYN ohne Antwort | Drop, Routing, Ziel oder Rückweg | | SYN gefolgt von RST | Port geschlossen oder aktive Ablehnung | | Handshake vollständig, danach RST | Anwendung, Proxy, Firewall oder Protokoll | | Handshake vollständig, keine Antwort | Dienst hängt, Backend wartet oder Überlastung | --- **Merksatz** > Ein erreichbarer Host ist nicht automatisch ein erreichbarer Dienst. Geprüft werden müssen die vollständige Kommunikationsbeziehung aus Quelle, Zieladresse, Transportprotokoll und Zielport sowie anschließend Listener, Firewall, Rückweg und Anwendung. Ein erfolgreicher Porttest beweist den TCP-Verbindungsaufbau, aber noch nicht die Funktionsfähigkeit des Anwendungsprotokolls. --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Guidance for troubleshooting TCP/IP communication](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-tcp-ip-communication-guidance) - [Microsoft Learn – Troubleshoot TCP/IP connectivity](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/tcp-ip-connectivity-issues-troubleshooting) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Test-Connection](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-connection) - [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-nettcpconnection) - [Microsoft Learn – Get-NetUDPEndpoint](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netudpendpoint) - [Microsoft Learn – Windows Defender Firewall with Advanced Security administration](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/) - [RFC 9293 – Transmission Control Protocol](https://www.rfc-editor.org/rfc/rfc9293) - [RFC 768 – User Datagram Protocol](https://www.rfc-editor.org/rfc/rfc768) - [RFC 792 – Internet Control Message Protocol](https://www.rfc-editor.org/rfc/rfc792) - [RFC 8201 – Path MTU Discovery for IPv6](https://www.rfc-editor.org/rfc/rfc8201) - [Wireshark – Display Filter Reference: TCP](https://www.wireshark.org/docs/dfref/t/tcp.html) - [Wireshark – Display Filter Reference: UDP](https://www.wireshark.org/docs/dfref/u/udp.html) - [Wireshark User’s Guide – Building display filter expressions](https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html) # 6.5 Netzwerk ist langsam – Latenz, Paketverlust und Durchsatz systematisch analysieren Ein Netzwerk gilt nicht allein deshalb als langsam, weil eine Anwendung verzögert reagiert. Wahrgenommene Langsamkeit kann durch das Netzwerk selbst, den Client, den Server, den Datenträger, eine Anwendung, DNS, einen Proxy, ein VPN, WLAN, Paketverlust oder eine ausgelastete Zwischenkomponente entstehen. Typische Aussagen wie: ```text Das Internet ist langsam. Der Server reagiert träge. Der Download dauert zu lange. Die Verbindung hängt immer wieder. Das WLAN ist schlecht. ``` sind zunächst nur Symptombeschreibungen. Für eine belastbare Fehleranalyse muss bestimmt werden: - was genau langsam ist, - zwischen welchen Endpunkten gemessen wird, - ob Latenz, Paketverlust, Jitter oder Durchsatz betroffen sind, - ob der Fehler dauerhaft oder sporadisch auftritt, - ob nur ein Client, ein Netzsegment oder alle Benutzer betroffen sind, - ob das Netzwerk oder eine darüberliegende Anwendung begrenzt. --- **1. Die wichtigsten Messgrößen unterscheiden** | Messgröße | Bedeutung | Typische Auswirkung | |---|---|---| | Latenz | Zeit für die Übertragung zwischen zwei Endpunkten | verzögerte Reaktion, langsamer Sitzungsaufbau | | Round-Trip Time | Zeit für Hin- und Rückweg | messbar beispielsweise mit Ping oder TCP-Tests | | Paketverlust | Pakete erreichen das Ziel nicht | Wiederholungen, Einbrüche bei TCP, Audio- und Videostörungen | | Jitter | Schwankung der Laufzeit | Probleme bei Sprache, Video und Echtzeitanwendungen | | Durchsatz | tatsächlich übertragene Datenmenge pro Zeit | langsame Dateiübertragung oder Downloads | | Bandbreite | theoretisch oder vertraglich verfügbare Kapazität | stellt nur die mögliche Obergrenze dar | | Auslastung | aktuell genutzter Anteil einer Verbindung oder Ressource | Warteschlangen, Verzögerungen und Drops | | Retransmission | erneute TCP-Übertragung verlorener oder nicht bestätigter Segmente | geringerer Durchsatz und zusätzliche Verzögerung | | Queue | wartende Pakete oder Anfragen | steigende Latenz bei hoher Last | | Fehlerrate | fehlerhafte Frames, Pakete oder Übertragungen | Paketverlust, Neuübertragungen und Verbindungsabbrüche | Ein Link mit `1 Gbit/s` garantiert keinen Anwendungsdurchsatz von `1 Gbit/s`. Protokoll-Overhead, Latenz, TCP-Verhalten, Datenträgerleistung, Verschlüsselung, Gegenstelle und weitere gleichzeitig übertragene Daten reduzieren den praktisch erreichbaren Wert. --- **2. Langsamkeit exakt beschreiben** Vor jeder technischen Änderung sind folgende Fragen zu beantworten: - Welche Anwendung oder Übertragung ist langsam? - Wie lange dauert der Vorgang normalerweise? - Wie lange dauert er während der Störung? - Seit wann besteht das Problem? - Funktionierte es zuvor nachweislich schneller? - Ist der Fehler dauerhaft, periodisch oder zufällig? - Sind Download, Upload oder beide Richtungen betroffen? - Sind kleine Anfragen oder erst große Übertragungen betroffen? - Tritt die Verzögerung vor dem Verbindungsaufbau oder während der Datenübertragung auf? - Ist nur ein Benutzer betroffen? - Sind mehrere Clients im selben VLAN, WLAN oder Standort betroffen? - Funktioniert ein Vergleichsclient normal? - Ist die Verbindung per Kabel und WLAN gleichermaßen langsam? - Sind interne Ziele, externe Ziele oder beide betroffen? - Ist nur ein bestimmter Server oder sind mehrere Ziele betroffen? - Wird ein VPN, Proxy, Load Balancer oder Sicherheitsgateway verwendet? - Gab es unmittelbar zuvor Änderungen, Updates oder Wartungsarbeiten? - Treten gleichzeitig CPU-, RAM-, Datenträger- oder Anwendungsprobleme auf? Eine geeignete Ausgangsbeschreibung lautet beispielsweise: ```text Seit 02.08.2026 gegen 09:20 Uhr erreichen Clients im WLAN VLAN 30 beim Kopieren einer 2-GB-Testdatei zum internen Dateiserver nur noch etwa 8 bis 15 Mbit/s. Über kabelgebundene Clients im VLAN 20 werden zum selben Server etwa 700 Mbit/s erreicht. Kleine Webanfragen und DNS-Auflösungen funktionieren. Betroffen sind mehrere WLAN-Clients. ``` Diese Beschreibung ist wesentlich aussagekräftiger als: ```text Das Netzwerk ist langsam. ``` --- **3. Latenz, Durchsatz und Anwendungsdauer nicht gleichsetzen** Ein Dienst kann sich langsam anfühlen, obwohl der Netzwerkdurchsatz ausreichend ist. Beispiele: - eine DNS-Abfrage läuft in einen Timeout, - ein TLS-Handshake benötigt mehrere Versuche, - der Server wartet auf eine Datenbank, - der Datenträger des Servers ist ausgelastet, - eine Anwendung führt viele aufeinanderfolgende Anfragen aus, - ein Proxy untersucht den Datenverkehr, - eine Datei wird serverseitig auf Schadsoftware geprüft, - eine Anwendung arbeitet nur mit einer einzelnen TCP-Verbindung, - ein Benutzerprofil oder eine Gruppenrichtlinie verarbeitet viele Dateien, - der Client besitzt eine hohe CPU- oder Datenträgerauslastung. Umgekehrt kann eine Anwendung zunächst normal reagieren, während größere Übertragungen wegen Paketverlust, MTU-Problemen oder eines ausgelasteten Links einbrechen. Deshalb sind mindestens zwei Prüfarten notwendig: 1. kontrollierte Netzwerkmessung, 2. Test der tatsächlich betroffenen Anwendung. --- **4. Umfang der Störung durch Vergleichstests eingrenzen** | Vergleich | mögliche Erkenntnis | |---|---| | betroffener gegen funktionierenden Client | lokales Problem oder gemeinsamer Infrastrukturfehler | | WLAN gegen Kabel | Funkstrecke, Access Point oder WLAN-Konfiguration | | internes gegen externes Ziel | LAN, WAN, Provider oder Internetpfad | | Ziel im selben VLAN gegen anderes VLAN | lokales Segment oder gerouteter Pfad | | ein Server gegen mehrere Server | Zielsystem oder allgemeiner Netzwerkpfad | | IP-Adresse gegen Hostname | DNS oder Namensauflösung | | ohne VPN gegen mit VPN | Tunnel, MTU, Gateway oder VPN-Routing | | ohne Proxy gegen vorgesehener Proxyweg | Proxy oder Sicherheitsprüfung | | Download gegen Upload | richtungsabhängiger Engpass | | einzelne gegen mehrere TCP-Verbindungen | TCP, Latenz, Lastverteilung oder Serverbegrenzung | | kleine gegen große Übertragung | MTU, Paketverlust, Datenträger oder Durchsatz | | aktuelle Messung gegen historische Baseline | tatsächliche Abweichung vom Normalzustand | Bei einem Vergleich sollte möglichst nur eine Variable verändert werden. --- **5. Lokale Clientressourcen ausschließen** Ein langsamer Client kann ein Netzwerkproblem vortäuschen. Zu prüfen sind: - CPU-Auslastung, - Arbeitsspeicher und Paging, - Datenträgerauslastung und Datenträgerlatenz, - laufende Updates, - Backups und Synchronisationsprogramme, - Virenscanner oder EDR-Prüfungen, - Browser-Erweiterungen, - VPN-Client, - Proxysoftware, - Netzwerkfiltertreiber, - fehlerhafter Netzwerkkartentreiber, - Energiesparmodus, - thermische Begrenzung, - sehr viele parallele Verbindungen, - lokale Anwendung oder lokaler Cache. **Windows** ```powershell Get-Process | Sort-Object CPU -Descending Get-Counter '\Processor(_Total)\% Processor Time' Get-Counter '\Memory\Available MBytes' Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Transfer' Get-NetAdapter Get-NetAdapterStatistics ``` **Linux** ```bash top vmstat 1 free -h iostat -xz 1 ip -s link ``` **macOS** ```bash top vm_stat iostat -w 1 netstat -ib ``` Hohe CPU-, RAM- oder Datenträgerauslastung beweist noch nicht, dass sie die Netzwerkstörung verursacht. Entscheidend ist die zeitliche Übereinstimmung mit der langsamen Übertragung. --- **6. Verbindungstyp und ausgehandelten Link prüfen** Bei Ethernet sind insbesondere zu prüfen: - Interface aktiv, - ausgehandelte Geschwindigkeit, - Duplexmodus, - automatische Aushandlung, - Kabel und Steckverbindungen, - Switchport, - Dockingstation oder USB-Adapter, - Treiber und Firmware, - Fehlerzähler, - Port-Security, - VLAN-Zuweisung, - Energiesparfunktionen. Ein Client, der statt mit `1 Gbit/s` nur mit `100 Mbit/s` verbunden ist, kann beispielsweise durch ein ungeeignetes oder beschädigtes Kabel, eine fehlerhafte Adernpaarverbindung, einen Adapter oder den Switchport begrenzt sein. **Windows** ```powershell Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, LinkSpeed, MacAddress ``` Weitere Eigenschaften: ```powershell Get-NetAdapterAdvancedProperty -Name "" Get-NetAdapterStatistics -Name "" ``` **Linux** ```bash ip link show ip -s link show sudo ethtool sudo ethtool -S ``` **macOS** ```bash ifconfig networksetup -getMedia netstat -ib ``` Auf der Switchseite sind je nach Hersteller insbesondere zu prüfen: - administrativer und operativer Portstatus, - Geschwindigkeit und Duplex, - CRC- oder FCS-Fehler, - Input Errors und Output Errors, - Drops und Discards, - Link-Flaps, - Pause Frames, - Queue Drops, - Portauslastung, - STP-Zustand, - LACP- oder Port-Channel-Zustand. Geschwindigkeit, Duplex, Jumbo Frames und Offload-Einstellungen dürfen nicht wahllos verändert werden. Unterschiedliche Einstellungen an beiden Linkpartnern können neue Fehler verursachen. --- **7. Schnittstellenzähler richtig auswerten** Ein einzelner Zählerstand zeigt nicht, wann ein Fehler aufgetreten ist. Zähler müssen vor und während eines kontrollierten Tests verglichen werden. Beispiel: ```text Zeitpunkt A: CRC-Fehler: 12 Drops: 41 Zeitpunkt B nach Test: CRC-Fehler: 438 Drops: 41 ``` Die steigende Zahl der CRC-Fehler weist auf ein Problem der physischen Übertragung oder des Links hin. Mögliche Ursachen sind: - beschädigtes Kabel, - ungeeignete Verkabelung, - defekter Stecker, - fehlerhafter Switchport, - defekter Netzwerkadapter, - elektromagnetische Störung, - Transceiver- oder Glasfaserproblem. Steigende Drops bei gleichbleibenden CRC-Werten sprechen eher für: - überfüllte Warteschlange, - zu hohe Auslastung, - Microbursts, - unzureichende Puffer, - QoS- oder Policing-Regel, - überlastete CPU einer Netzwerkkomponente. Hersteller verwenden unterschiedliche Zählerbezeichnungen. Die genaue Bedeutung muss anhand der Dokumentation des eingesetzten Geräts geprüft werden. --- **8. Latenz zunächst kontrolliert messen** **Windows** ```powershell ping ping -t Test-Connection -Count 20 Test-NetConnection ``` **Linux** ```bash ping -c 20 ``` **macOS** ```bash ping -c 20 ``` Sinnvolle Ziele für getrennte Messungen: 1. eigenes Standardgateway, 2. Ziel im eigenen VLAN, 3. Ziel in einem anderen internen VLAN, 4. interner Server, 5. VPN-Gateway, 6. externes Ziel, 7. tatsächlich betroffener Anwendungsserver. Beispielhafte Eingrenzung: | Messung | Ergebnis | mögliche Einordnung | |---|---|---| | Gateway bereits langsam | lokaler Link, WLAN, Client oder erstes Netzsegment | | Gateway normal, interner Server langsam | Routing, Firewall, Servernetz oder Server | | interne Ziele normal, externe Ziele langsam | WAN, Provider, VPN, Proxy oder externer Pfad | | nur ein Ziel langsam | Zielserver, Zielnetz oder spezifischer Pfad | | nur unter Last langsam | Queue, Auslastung, Bufferbloat oder Ressourcenengpass | ICMP kann durch Firewalls, Router oder Zielsysteme begrenzt oder niedriger priorisiert werden. Ein verlorenes oder verspätetes Ping-Paket beweist deshalb allein noch keinen Verlust des tatsächlichen Anwendungsverkehrs. --- **9. Paketverlust korrekt untersuchen** Paketverlust kann auftreten: - zwischen Client und Switch, - auf einer WLAN-Funkstrecke, - auf einem überlasteten Uplink, - in einer Firewall, - an einem Router, - in einem VPN-Tunnel, - auf dem WAN- oder Providerpfad, - auf dem Serverinterface, - innerhalb eines virtualisierten Netzwerks. **Windows** ```powershell ping -n 100 pathping ``` **Linux** ```bash ping -c 100 mtr ``` **macOS** ```bash ping -c 100 traceroute ``` Bei `pathping`, `mtr` und ähnlichen Werkzeugen darf ein scheinbarer Verlust an einem Zwischenhop nicht automatisch als Fehler dieses Routers bewertet werden. Ein Router kann Antworten auf Diagnosepakete begrenzen, während er Transitverkehr weiterhin normal weiterleitet. Bedeutsamer ist ein Verlust, wenn: - er ab einem Hop beginnt und an allen folgenden Hops bestehen bleibt, - er gleichzeitig in Ende-zu-Ende-Messungen auftritt, - Interfacezähler oder Paketaufzeichnungen ihn bestätigen, - der tatsächliche Anwendungsverkehr Wiederholungen oder Abbrüche zeigt. --- **10. Pfad und Richtungsunterschiede untersuchen** **Windows** ```powershell tracert Test-NetConnection -TraceRoute Get-NetRoute ``` **Linux** ```bash traceroute tracepath ip route ip route get ``` **macOS** ```bash traceroute netstat -rn route -n get ``` Zu prüfen sind: - Hinweg vom Client zum Ziel, - Rückweg vom Ziel zum Client, - unerwartete Umwege, - VPN-Routen, - Policy-Based Routing, - asymmetrisches Routing, - geänderte Gateways, - überlappende Netze, - unterschiedliche IPv4- und IPv6-Pfade, - Load Balancer oder mehrere Zieladressen. Ein klassischer Traceroute zeigt normalerweise nur den beobachteten Hinweg. Der Rückweg kann anders verlaufen und muss gegebenenfalls von der Gegenstelle aus untersucht werden. --- **11. Durchsatz mit einer kontrollierten Gegenstelle messen** Für eine kontrollierte Ende-zu-Ende-Messung kann `iperf3` verwendet werden. Dabei werden Client und Server benötigt. **Server starten** ```bash iperf3 -s ``` **Clienttest** ```bash iperf3 -c ``` **Gegenrichtung testen** ```bash iperf3 -c -R ``` **Längerer Test** ```bash iperf3 -c -t 30 ``` **Mehrere parallele Datenströme** ```bash iperf3 -c -P 4 ``` **UDP-Test mit kontrollierter Zielrate** ```bash iperf3 -c -u -b -t 30 ``` Dabei sind zu dokumentieren: - Client und Server, - beide IP-Adressen, - Netzpfad, - Datum und Uhrzeit, - TCP oder UDP, - Testdauer, - Anzahl paralleler Datenströme, - Hin- oder Rückrichtung, - gemessener Durchsatz, - gemeldete Wiederholungen, - bei UDP zusätzlich Verlust und Jitter, - gleichzeitige Auslastung anderer Verbindungen. Wichtige Einschränkungen: - Das Ergebnis gilt nur für den Pfad zwischen den beiden Testendpunkten. - Der `iperf3`-Server muss autorisiert und kontrolliert betrieben werden. - Ein Test kann produktive Links stark auslasten. - UDP-Tests können bei ungeeigneter Zielrate erhebliche Paketverluste verursachen. - Mehrere parallele Verbindungen können einen höheren Gesamtdurchsatz erreichen als eine einzelne Verbindung. - Ein erfolgreicher `iperf3`-Test beweist nicht, dass DNS, TLS, Proxy oder Anwendung funktionieren. - Das iperf3-Projekt unterstützt offiziell Linux, FreeBSD und macOS; Windows-Builds stammen häufig aus anderen Quellen und sind nicht Teil der offiziellen Plattformunterstützung des Projekts. Tests in produktiven Netzen müssen zeitlich, räumlich und in ihrer Bandbreite begrenzt werden. --- **12. Dateitransfer nicht ungeprüft als Netzwerkbenchmark verwenden** Eine Dateiübertragung misst nicht ausschließlich das Netzwerk. Das Ergebnis kann begrenzt werden durch: - Quelldatenträger, - Zieldatenträger, - Dateisystem, - SMB, NFS, SFTP oder HTTPS, - Verschlüsselung, - Kompression, - Virenscanner, - viele kleine Dateien, - Server-CPU, - Client-CPU, - Berechtigungsprüfung, - Protokollsignierung, - Backup oder Snapshot, - Cache. Sinnvolle Vergleichstests: - große einzelne Datei gegen viele kleine Dateien, - Speicher-zu-Speicher-Test gegen Datenträgerübertragung, - kontrollierter Netzwerkdurchsatz gegen Anwendungsübertragung, - derselbe Client zu einem anderen Server, - ein anderer Client zum selben Server, - Lesen gegen Schreiben. Wenn `iperf3` einen normalen Netzwerkdurchsatz zeigt, die Dateiübertragung aber langsam bleibt, verschiebt sich die Untersuchung auf Protokoll, Datenträger, Server und Anwendung. --- **13. WLAN getrennt vom kabelgebundenen Netz prüfen** WLAN ist ein gemeinsam genutztes Funkmedium. Die angezeigte WLAN-Verbindungsrate entspricht nicht dem tatsächlich erreichbaren Nutzdurchsatz. Zu prüfen sind: - Signalstärke, - Signal-Rausch-Verhältnis, - verwendetes Frequenzband, - Kanal, - Kanalbreite, - Kanalauslastung, - Störungen, - Anzahl gleichzeitig aktiver Clients, - Airtime-Auslastung, - Wiederholungsrate, - Datenrate, - Roaming, - Access-Point-Auslastung, - Uplink des Access Points, - PoE-Versorgung, - Treiber und Firmware, - Entfernung und Hindernisse, - Hidden-Node-Probleme, - Band Steering, - Mindestdatenraten, - WLAN-Sicherheitsverfahren. **Windows** ```cmd netsh wlan show interfaces netsh wlan show drivers netsh wlan show wlanreport ``` **Linux** ```bash iw dev iw dev link nmcli device wifi list ``` **macOS** Auf macOS können die WLAN-Diagnose, die Systeminformationen sowie je nach Systemversion verfügbare Diagnosewerkzeuge verwendet werden. Die genaue Bedienung kann sich zwischen macOS-Versionen ändern. Wichtige Vergleichstests: 1. betroffener Client am aktuellen Standort, 2. derselbe Client näher am Access Point, 3. derselbe Client per Ethernet, 4. anderer Client am selben Standort, 5. anderer Access Point oder anderes Frequenzband, 6. Messung bei geringer und hoher Auslastung. Wenn der kabelgebundene Test normal und der WLAN-Test langsam ist, liegt die Ursache nicht automatisch am Access Point. Auch Clienttreiber, Funkumgebung, Kanalplanung, Airtime und Roaming müssen geprüft werden. --- **14. Auslastung, Warteschlangen und Bufferbloat** Ein Link kann unter geringer Last gute Latenzwerte und unter hoher Last starke Verzögerungen zeigen. Beispiel: ```text ohne Übertragung: Round-Trip Time zum Gateway: 2 ms während eines Uploads: Round-Trip Time zum Gateway: 180 ms ``` Mögliche Ursachen: - ausgelasteter Uplink, - zu große Warteschlangen, - fehlende oder ungeeignete QoS-Regeln, - Upload begrenzt Rückverkehr und Bestätigungen, - Firewall oder Router erreicht Leistungsgrenze, - VPN-Gateway ist ausgelastet, - WLAN-Airtime ist erschöpft, - Microbursts füllen einen Puffer, - Policer verwirft Pakete. Zu vergleichen sind: - Latenz ohne Last, - Latenz während Download, - Latenz während Upload, - Paketverlust, - Interfaceauslastung, - Queue Drops, - CPU der Netzwerkkomponente, - Anzahl aktiver Verbindungen. Eine hohe nominale Bandbreite verhindert solche Probleme nicht automatisch. Entscheidend sind Engpass, Warteschlangen und Lastverteilung entlang des vollständigen Pfades. --- **15. Duplex-, Speed- und Aushandlungsfehler** Ein Duplexproblem kann folgende Symptome verursachen: - geringer Durchsatz, - stark schwankende Übertragungsrate, - Framefehler, - Kollisionen oder späte Kollisionen bei älteren Ethernet-Szenarien, - viele Wiederholungen, - gute Werte ohne Last und schlechte Werte unter Last. Zu prüfen sind beide Linkpartner: ```text Clientinterface ↔ Switchport Serverinterface ↔ Switchport Switch-Uplink ↔ Gegenstelle Firewallinterface ↔ Switchport ``` Die Konfiguration muss zusammenpassen. Einseitiges Erzwingen von Geschwindigkeit oder Duplex kann einen Mismatch erzeugen. Bei modernen Gigabit-Ethernet-Verbindungen wird normalerweise automatische Aushandlung verwendet. Abweichungen dürfen nur entsprechend der Hardware- und Herstelleranforderungen konfiguriert werden. --- **16. MTU und Fragmentierung prüfen** MTU-Probleme können auftreten, obwohl Ping und kleine Anfragen funktionieren. Typische Symptome: - kleine Webseiten funktionieren, - größere Antworten bleiben hängen, - Dateiübertragungen brechen ab, - VPN-Verbindungen sind langsam, - TLS-Handshakes scheitern oder verzögern sich, - bestimmte Ziele funktionieren, andere nicht, - viele TCP-Wiederholungen, - Anwendungen warten bis zu einem Timeout. **Windows** ```powershell ping -f -l ``` **Linux** ```bash tracepath ping -M do -s ``` Die Nutzdatenlänge eines Pingpakets ist nicht mit der vollständigen IP-Paketgröße gleichzusetzen. IP- und ICMP-Header müssen berücksichtigt werden. Zu prüfen sind: - MTU des Clients, - MTU des Servers, - VLAN- und Tunnel-Overhead, - VPN, - PPPoE, - VXLAN oder andere Kapselung, - Jumbo Frames, - Path MTU Discovery, - blockierte ICMP-Fehlermeldungen, - MSS-Anpassung. Jumbo Frames dürfen nur verwendet werden, wenn der vollständige vorgesehene Pfad sie unterstützt. Eine Änderung ausschließlich an einem Endgerät ist keine geeignete Lösung. --- **17. TCP-Wiederholungen und Empfangsfenster untersuchen** TCP passt seine Übertragung an den Zustand des Datenpfades an. Paketverlust, hohe Laufzeit oder ein begrenztes Empfangsfenster können den Durchsatz stark reduzieren. Mögliche Beobachtungen: - Retransmissions, - Duplicate Acknowledgements, - Out-of-Order-Segmente, - Zero Window, - Window Full, - lange Abstände zwischen Anfrage und Antwort, - wiederholter Verbindungsaufbau, - Reset, - stark unterschiedlicher Durchsatz je Richtung. **Wireshark-Filter** ```text tcp.analysis.retransmission tcp.analysis.fast_retransmission tcp.analysis.spurious_retransmission tcp.analysis.duplicate_ack tcp.analysis.out_of_order tcp.analysis.lost_segment tcp.analysis.window_full tcp.analysis.zero_window tcp.analysis.zero_window_probe tcp.flags.reset == 1 ``` Mögliche Einordnung: | Beobachtung | mögliche Ursache | |---|---| | viele Retransmissions | Paketverlust, Überlastung, physischer Fehler oder Datenpfad | | Duplicate ACKs | fehlende oder verspätete Segmente | | Out-of-Order | unterschiedliche Pfade, Reordering oder Aufzeichnungsartefakt | | Zero Window | Empfänger verarbeitet Daten nicht schnell genug | | Window Full | ausgeschöpftes angekündigtes Empfangsfenster | | wiederholte RST-Pakete | Anwendung, Firewall, Proxy oder Betriebssystem | | lange Zeit bis zum ersten Datenpaket | Anwendung, DNS, TLS, Proxy oder Server | | schnelle Pakete, aber lange Anwendungspausen | Anwendung oder Backend statt Transport | Wireshark-Kennzeichnungen beruhen auf der im Mitschnitt sichtbaren Paketreihenfolge. Ein unvollständiger Mitschnitt, Paketverlust bei der Aufzeichnung oder NIC-Offloading kann die Interpretation beeinflussen. --- **18. Paketaufzeichnung an mehreren Punkten** Wenn die Ursache nicht eindeutig ist, kann eine autorisierte Paketaufzeichnung an mehreren Stellen helfen. Geeignete Punkte: - betroffener Client, - funktionierender Vergleichsclient, - Server, - vor und hinter einer Firewall, - Switch Mirror Port, - VPN-Endpunkt, - Reverse Proxy, - Load Balancer. Zu prüfen sind: - Zeit bis zur DNS-Antwort, - Zeit bis zum TCP-Verbindungsaufbau, - Zeit bis zum TLS-Handshake, - Zeit bis zur ersten Anwendungsantwort, - Paketverlust, - Wiederholungen, - Fenstergrößen, - Reset-Pakete, - ICMP-Fehlermeldungen, - verwendete IP-Adresse, - IPv4 oder IPv6, - tatsächlicher Datenpfad. Ein Mitschnitt nur auf dem Client zeigt nicht sicher, an welcher Zwischenstelle ein Paket verloren ging. Vergleichsmitschnitte an Client und Server können zeigen: ```text Paket verlässt den Client, erreicht aber den Server nicht. ``` oder: ```text Server sendet die Antwort, Client empfängt sie nicht. ``` Paketaufzeichnungen dürfen nur mit entsprechender Berechtigung erstellt und müssen geschützt gespeichert werden. --- **19. IPv4 und IPv6 getrennt vergleichen** Ein Client kann IPv6 bevorzugen, obwohl der IPv6-Pfad langsam oder fehlerhaft ist. **Windows** ```powershell Resolve-DnsName -Type A Resolve-DnsName -Type AAAA Test-Connection Test-Connection ``` **Linux und macOS** ```bash ping -4 ping -6 curl -4 -v https:/// curl -6 -v https:/// ``` Mögliche Ursachen: - unterschiedliche Routen, - falscher AAAA-Record, - IPv6-Firewallregel, - fehlerhafte IPv6-Rückroute, - Tunnel für eine Adressfamilie, - unterschiedliche Proxys oder Gateways, - Dienst antwortet nur über eine Adressfamilie zuverlässig. IPv6 sollte nicht pauschal deaktiviert werden. Zuerst ist nachzuweisen, welche Adressfamilie betroffen ist. --- **20. DNS, Proxy, TLS und Anwendungslatenz abgrenzen** **DNS-Zeit prüfen** ```bash dig ``` Mit `curl` können einzelne Zeitabschnitte gemessen werden: ```bash curl -sS -o /dev/null \ -w 'DNS: %{time_namelookup}\nTCP: %{time_connect}\nTLS: %{time_appconnect}\nErstes Byte: %{time_starttransfer}\nGesamt: %{time_total}\n' \ https:/// ``` Bedeutung: | Wert | untersuchter Bereich | |---|---| | `time_namelookup` | Namensauflösung | | `time_connect` | Zeit bis zum TCP-Verbindungsaufbau | | `time_appconnect` | Zeit bis zum Abschluss von TLS | | `time_starttransfer` | Zeit bis zum ersten empfangenen Byte | | `time_total` | gesamte Übertragungsdauer | Mögliche Einordnung: - DNS langsam, TCP normal: Resolver oder DNS-Pfad, - TCP-Verbindungsaufbau langsam: Netzwerkpfad, Paketverlust oder Ziel, - TLS langsam: Zertifikatsprüfung, TLS-Inspection oder Server, - erstes Byte langsam: Anwendung, Proxy, Backend oder Datenbank, - erstes Byte schnell, Übertragung langsam: Durchsatz, Paketverlust oder Serverausgabe. Ein einzelner Messwert reicht nicht aus. Messungen sollten wiederholt und mit einem funktionierenden Vergleich verglichen werden. --- **21. VPN und Tunnel berücksichtigen** VPN-Verbindungen erzeugen zusätzliche Netzwerkschichten. Mögliche Ursachen: - Tunnel-Overhead, - ungeeignete MTU, - fehlende MSS-Anpassung, - VPN-Gateway ausgelastet, - Verschlüsselung begrenzt CPU, - Full Tunnel leitet unnötigen Datenverkehr um, - Split-Tunnel-Regel fehlt, - DNS wird über einen entfernten Standort geleitet, - asymmetrisches Routing, - Paketverlust auf dem Transportpfad, - wechselnder Zugang zwischen WLAN und Mobilfunk, - Sicherheitsprüfung im VPN-Gateway. Sinnvolle Vergleichstests: 1. ohne VPN zu einem zulässigen Vergleichsziel, 2. mit VPN zum selben zulässigen Ziel, 3. internes Ziel über VPN, 4. externes Ziel bei Full Tunnel, 5. IPv4 und IPv6, 6. Download und Upload, 7. Latenz zum VPN-Gateway und zum Endziel. Ein langsamer Test über VPN beweist nicht automatisch, dass das VPN-Gateway die Ursache ist. Auch der lokale Internetzugang und der Pfad zum Gateway müssen geprüft werden. --- **22. Firewalls, Proxys und Sicherheitskomponenten** Sicherheitskomponenten können den Datenverkehr nicht nur erlauben oder blockieren, sondern auch verarbeiten. Mögliche Einflussfaktoren: - TLS-Inspection, - Virenprüfung, - Intrusion Prevention, - URL-Filter, - Data Loss Prevention, - Proxy-Caching, - Bandbreitenbegrenzung, - QoS- oder Policing-Regel, - hohe Sitzungsanzahl, - ausgelastete CPU, - voller Arbeitsspeicher, - überlastete Protokollierung, - Cluster-Failover, - fehlerhafte Lastverteilung. Zu prüfen sind: - Interfaceauslastung, - CPU und Arbeitsspeicher, - Sitzungstabelle, - Paket- und Fehlerzähler, - Queue Drops, - aktive Sicherheitsprofile, - Protokolle zum Störungszeitpunkt, - HA-Zustand, - Lizenz- oder Kapazitätsgrenzen, - Unterschiede zwischen untersuchten Anwendungen. Sicherheitsfunktionen dürfen nicht pauschal deaktiviert werden. Tests müssen genehmigt, zeitlich begrenzt und auf eine konkrete Kommunikationsbeziehung beschränkt sein. --- **23. Server und Anwendung als Engpass prüfen** Auch bei fehlerfreiem Netzwerk kann der Zielserver den Durchsatz begrenzen. Zu prüfen sind: - CPU pro Prozess und Thread, - Arbeitsspeicher, - Paging oder Swapping, - Datenträgerlatenz, - I/O-Wait, - Queue Depth, - Netzwerkinterface, - offene Verbindungen, - Connection Pools, - Datenbanklocks, - Anwendungswarteschlangen, - parallele Backups, - Virenscanner, - Snapshots, - Hypervisorauslastung, - Storage-Netzwerk, - Load Balancer, - Backend-Abhängigkeiten. Typisches Muster: ```text iperf3 zum Server: normal Dateiübertragung: langsam Server-Datenträger: dauerhaft ausgelastet ``` In diesem Fall ist ein Netzwerkengpass nicht nachgewiesen. Die Untersuchung muss auf Datenträger, Protokoll und Server fortgesetzt werden. --- **24. Virtualisierung und Container** Zusätzliche Ursachen bei virtuellen Systemen: - virtuelle Netzwerkkarte begrenzt, - vSwitch oder Bridge ausgelastet, - falsches VLAN Tagging, - Host-Uplink überlastet, - NIC Teaming oder Bonding fehlerhaft, - CPU-Steal oder CPU Ready, - Host Memory Pressure, - Storage-Latenz, - Sicherheitsgruppe oder virtuelle Firewall, - Overlay-Netzwerk, - Container-NAT, - Service Mesh, - Reverse Proxy, - Host-Portzuordnung, - fehlerhafte MTU innerhalb des Overlays. Die Prüfung sollte folgende Ebenen unterscheiden: ```text Anwendung ↓ Container oder virtuelle Maschine ↓ virtuelles Interface ↓ virtueller Switch oder Bridge ↓ Hostinterface ↓ physischer Switch ↓ weiterer Netzwerkpfad ``` Ein unauffälliger Zähler innerhalb der virtuellen Maschine schließt Fehler auf dem Host-Uplink nicht aus. --- **25. Sporadische Langsamkeit erfassen** Bei sporadischen Fehlern reichen manuelle Einzeltests häufig nicht aus. **PowerShell** ```powershell 1..30 | ForEach-Object { $time = Get-Date -Format "yyyy-MM-dd HH:mm:ss" $result = Test-Connection -Count 1 -ErrorAction SilentlyContinue [PSCustomObject]@{ Time = $time Status = if ($result) { "Erfolg" } else { "Fehler" } RTTms = if ($result) { $result.Latency } else { $null } } Start-Sleep -Seconds 10 } ``` Abhängig von der verwendeten PowerShell-Version können Eigenschaften des zurückgegebenen Objekts abweichen und müssen vor einer automatisierten Auswertung geprüft werden. **Bash** ```bash for i in {1..30}; do date '+%Y-%m-%d %H:%M:%S' ping -c 1 sleep 10 done ``` Zusätzlich zu erfassen sind: - Interfacezähler, - Link-Flaps, - Switchportstatus, - WLAN-Roaming, - Kanal- und Airtime-Auslastung, - CPU und RAM, - Datenträgerlatenz, - Firewall-Sitzungsanzahl, - geplante Backups, - Updates, - Scans, - Cronjobs oder Timer, - Providerereignisse, - Temperatur und Stromversorgung. Alle Systeme müssen möglichst einheitlich synchronisierte Zeit verwenden, damit Ereignisse auf einer gemeinsamen Zeitleiste verglichen werden können. --- **26. Praxisfall A: Nur ein Client ist langsam** **Symptom** - ein Client überträgt mit etwa 90 Mbit/s, - andere Clients am selben Switch erreichen wesentlich höhere Werte, - Server und Anwendung sind für andere Benutzer normal, - der betroffene Client zeigt eine Linkgeschwindigkeit von `100 Mbit/s`. **Prüfung** 1. Linkgeschwindigkeit dokumentieren. 2. Netzwerkkartenstatistik prüfen. 3. Kabel und Switchport kontrollieren. 4. Client mit bekannt funktionierendem Kabel testen. 5. denselben Switchport mit einem Vergleichsclient testen. 6. Treiber und Adapter prüfen. 7. kontrollierten Durchsatztest wiederholen. **Mögliche Ursache** Das Netzwerkkabel besitzt eine fehlerhafte Adernpaarverbindung. Deshalb wird nur Fast Ethernet statt Gigabit Ethernet ausgehandelt. **Nachprüfung** - Link wird mit der vorgesehenen Geschwindigkeit ausgehandelt, - Fehlerzähler steigen nicht, - kontrollierter Durchsatz entspricht wieder der Baseline, - die ursprüngliche Anwendung funktioniert, - Kabel und Ursache sind dokumentiert. --- **27. Praxisfall B: WLAN langsam, Ethernet normal** **Symptom** - mehrere WLAN-Clients sind langsam, - kabelgebundene Clients funktionieren, - Latenz zum Gateway steigt unter Last stark, - Access Point und Clients verwenden denselben stark belegten Kanal. **Prüfung** 1. WLAN- und Ethernettest vergleichen. 2. Signal, Kanal und Kanalauslastung erfassen. 3. Airtime und Wiederholungsrate am Access Point prüfen. 4. benachbarte Funknetze berücksichtigen. 5. Uplink und CPU des Access Points prüfen. 6. kontrollierte Messung bei geringer Last durchführen. 7. Kanalplanung entsprechend der vorhandenen Funkumgebung prüfen. **Mögliche Ursache** Der verwendete Kanal ist stark ausgelastet. Mehrere Access Points und fremde WLANs konkurrieren um dieselbe Airtime. **Nachprüfung** - vorgesehene Kanalplanung ist umgesetzt, - Wiederholungsrate ist gesunken, - Latenz bleibt auch unter kontrollierter Last stabiler, - Durchsatz hat sich nachweisbar verbessert, - benachbarte Funkzellen funktionieren weiterhin, - Änderung und Messergebnisse sind dokumentiert. --- **28. Praxisfall C: Download schnell, Upload langsam** **Symptom** - Downloads erreichen die erwartete Größenordnung, - Uploads brechen stark ein, - bei Uploadlast steigt die Latenz, - andere Anwendungen reagieren währenddessen verzögert. **Prüfung** 1. Download und Upload getrennt messen. 2. Gegenrichtung mit kontrollierter Messung prüfen. 3. WAN-Auslastung und Queue beobachten. 4. Firewall- und Router-CPU prüfen. 5. Drops und Policing-Zähler kontrollieren. 6. Providerprofil und vereinbarte Uploadrate prüfen. 7. VPN- und QoS-Regeln berücksichtigen. **Mögliche Ursache** Der verfügbare Upstream wird vollständig ausgelastet. Eine ungeeignete Warteschlangensteuerung verursacht zusätzliche Latenz. **Nachprüfung** - Upload bleibt innerhalb der vorgesehenen Kapazität, - interaktive Anwendungen bleiben unter Last nutzbar, - Queue Drops und Latenz wurden erneut gemessen, - vorgesehene Priorisierung funktioniert, - nicht autorisierte Bandbreitenerweiterungen wurden nicht vorgenommen. --- **29. Praxisfall D: Netzwerk normal, Anwendung langsam** **Symptom** - Latenz und Paketverlust sind unauffällig, - kontrollierter Durchsatz ist normal, - nur eine Webanwendung antwortet langsam, - Zeit bis zum ersten Byte ist stark erhöht. **Prüfung** 1. DNS-, TCP-, TLS- und Antwortzeiten getrennt messen. 2. Anwendung mit anderem Client vergleichen. 3. Reverse-Proxy-Protokolle prüfen. 4. Backend-Verbindung testen. 5. Anwendungs- und Datenbankprotokolle auswerten. 6. Serverressourcen kontrollieren. 7. zeitgleiche Jobs oder Locks prüfen. **Mögliche Ursache** Eine Datenbankabfrage wartet auf eine Sperre. Das Netzwerk transportiert die Pakete normal, die Anwendung erzeugt die Antwort jedoch verspätet. **Nachprüfung** - Zeit bis zum ersten Byte hat sich normalisiert, - Netzwerkwerte bleiben unverändert, - Datenbank- und Anwendungszustand sind fehlerfrei, - ursprünglicher Geschäftsprozess funktioniert, - Ursache und Maßnahme sind dokumentiert. --- **30. Praxisfall E: Über VPN funktionieren kleine Anfragen, große Übertragungen brechen ein** **Symptom** - Anmeldung am VPN funktioniert, - Ping und kleine Webanfragen funktionieren, - größere Dateiübertragungen hängen oder werden sehr langsam, - ohne VPN tritt das Problem nicht auf. **Prüfung** 1. Pfad und Tunnelart dokumentieren. 2. MTU auf Client, Tunnel und Zielpfad prüfen. 3. Paketaufzeichnung auf Wiederholungen untersuchen. 4. ICMP-Fehlermeldungen berücksichtigen. 5. MSS-Anpassung am Tunnel prüfen. 6. Upload und Download getrennt testen. 7. VPN-Gatewayauslastung kontrollieren. **Mögliche Ursache** Durch den Tunnel-Overhead ist die effektive MTU geringer. Notwendige Rückmeldungen für Path MTU Discovery werden auf dem Pfad verworfen. **Nachprüfung** - kleine und große Übertragungen funktionieren, - TCP-Wiederholungen sind zurückgegangen, - vorgesehene MTU- beziehungsweise MSS-Konfiguration ist dokumentiert, - andere VPN-Verbindungen wurden kontrolliert, - keine pauschale Deaktivierung von Sicherheitsfunktionen erfolgte. --- **31. Ungeeignete Sofortmaßnahmen** Problematisch sind insbesondere: - Netzwerkgeräte ohne Dokumentation neu starten, - Kabel, Switchports und Konfiguration gleichzeitig verändern, - Geschwindigkeit oder Duplex nur auf einer Seite erzwingen, - Jumbo Frames versuchsweise aktivieren, - IPv6 pauschal deaktivieren, - Firewalls oder Sicherheitsprüfung vollständig abschalten, - QoS-Regeln ohne Messung verändern, - produktive Links mit unkontrollierten Lasttests auslasten, - UDP-Tests mit beliebiger hoher Zielrate durchführen, - Provider verantwortlich machen, ohne den lokalen Pfad geprüft zu haben, - einen einzelnen Pingverlust als eindeutigen Beweis verwenden, - jeden Verlust an einem Traceroute-Hop als Fehler dieses Routers interpretieren, - eine Dateiübertragung als reinen Netzwerkbenchmark behandeln, - Paketaufzeichnungen ungeschützt speichern, - Netzwerkkartentreiber ungeprüft ersetzen, - Offload- und Empfangseinstellungen wahllos deaktivieren, - Server neu starten, ohne Ressourcen und Protokolle zu sichern. Vor Änderungen sollten mindestens dokumentiert werden: - Symptom, - betroffene Benutzer und Systeme, - Quelle und Ziel, - Verbindungstyp, - Linkgeschwindigkeit, - DNS-Ergebnis, - Latenz, - Paketverlust, - Durchsatz, - Interfacezähler, - Route, - Serverressourcen, - Zeitpunkt, - Vergleichssystem, - aktuelle Konfiguration. --- **32. Vollständige Prüfreihenfolge** 1. genaue langsame Funktion benennen. 2. Soll- und Istwert dokumentieren. 3. Zeitpunkt, Dauer und Häufigkeit erfassen. 4. betroffene Benutzer, Clients und Standorte bestimmen. 5. Quelle, Ziel und Datenrichtung dokumentieren. 6. funktionierenden Vergleichsclient bestimmen. 7. WLAN und Ethernet unterscheiden. 8. internes und externes Ziel vergleichen. 9. Clientressourcen prüfen. 10. Interface- und Linkstatus prüfen. 11. ausgehandelte Geschwindigkeit und Duplex kontrollieren. 12. Kabel, Adapter und Switchport berücksichtigen. 13. Interfacezähler vor dem Test erfassen. 14. Latenz zum Gateway messen. 15. Latenz zu internen und externen Zielen vergleichen. 16. Paketverlust Ende zu Ende untersuchen. 17. Pfad und Route prüfen. 18. IPv4 und IPv6 getrennt vergleichen. 19. Interfacezähler nach dem Test erneut erfassen. 20. Download und Upload getrennt messen. 21. kontrollierten Durchsatztest verwenden. 22. einzelne und parallele TCP-Verbindungen vergleichen. 23. Datenträger und Anwendung vom Netzwerk abgrenzen. 24. WLAN-Signal, Kanal, Airtime und Wiederholungen prüfen. 25. Uplinks, Port-Channels und Queue Drops kontrollieren. 26. Firewall, VPN, Proxy und Sicherheitsprüfung berücksichtigen. 27. Server-CPU, RAM und Datenträgerlatenz prüfen. 28. Virtualisierung, vSwitch und Host-Uplink untersuchen. 29. MTU, Tunnel und Fragmentierung bei passenden Symptomen prüfen. 30. TCP-Wiederholungen und Fensterverhalten analysieren. 31. bei Bedarf autorisierte Paketaufzeichnung erstellen. 32. Beobachtungen auf einer gemeinsamen Zeitleiste korrelieren. 33. konkrete Hypothese formulieren. 34. genau eine kontrollierbare Änderung durchführen. 35. Latenz erneut messen. 36. Paketverlust erneut prüfen. 37. Durchsatz erneut messen. 38. ursprüngliche Anwendung erneut testen. 39. funktionierende Vergleichssysteme kontrollieren. 40. temporäre Tests und Freigaben entfernen. 41. Ursache, Maßnahme und Nachweis dokumentieren. 42. Monitoring oder Präventionsmaßnahme festlegen. --- **33. Dokumentationsbeispiel** ```text Ticket: INC-20718 Beginn: 02.08.2026, etwa 09:20 Uhr Umfang: mehrere WLAN-Clients im VLAN 30 Nicht betroffen: kabelgebundene Clients im VLAN 20 Ziel: interner Dateiserver fileserver.example.test Symptom: Dateiübertragungen über WLAN erreichen nur etwa 8 bis 15 Mbit/s. Kabelgebundene Vergleichsclients erreichen zum selben Server etwa 700 Mbit/s. Kleine Webanfragen und DNS-Auflösungen funktionieren. Ausgangszustand: - DNS-Auflösung korrekt - Server per TCP erreichbar - Dateiserver für Ethernet-Clients normal - Serverressourcen unauffällig - Access-Point-Uplink mit 1 Gbit/s aktiv - keine steigenden CRC-Fehler am Uplink - hohe Kanalauslastung im verwendeten Frequenzbereich - erhöhte WLAN-Wiederholungsrate - Latenz zum Gateway steigt unter Last deutlich Hypothese: Die Funkzelle besitzt zu wenig freie Airtime. Der Datenverkehr wird wiederholt übertragen und wartet auf den Zugriff auf das Funkmedium. Prüfung: - Ethernet und WLAN mit demselben Ziel verglichen - mehrere WLAN-Clients getestet - Signalstärke und Kanal erfasst - Uplink und Server als Engpass ausgeschlossen - kontrollierter Durchsatztest in beide Richtungen durchgeführt - Access-Point-Statistiken zum Störungszeitpunkt ausgewertet Ursache: Starke Kanalbelegung und überlappende Funkzellen führten zu einer hohen Wiederholungsrate und geringer nutzbarer Airtime. Maßnahme: Die Kanalplanung der betroffenen Funkzellen wurde nach einer Funkumgebungsanalyse kontrolliert angepasst. Nachprüfung: - Latenz zum Gateway unter Last verbessert - Wiederholungsrate gesunken - kontrollierter WLAN-Durchsatz deutlich erhöht - ursprüngliche Dateiübertragung funktioniert - Ethernet-Clients weiterhin fehlerfrei - benachbarte Funkzellen kontrolliert Prävention: - Kanalauslastung und Wiederholungsrate überwachen - WLAN-Baseline pro Standort dokumentieren - Funkumgebung nach größeren Änderungen erneut prüfen ``` --- **34. Checkliste „Netzwerk ist langsam“** - [ ] die langsame Funktion wurde eindeutig benannt. - [ ] Soll- und Istzustand wurden dokumentiert. - [ ] Beginn, Dauer und Häufigkeit wurden erfasst. - [ ] betroffene Clients, Benutzer und Standorte wurden bestimmt. - [ ] Quelle, Ziel und Datenrichtung wurden dokumentiert. - [ ] ein funktionierender Vergleichsclient wurde verwendet. - [ ] WLAN und Ethernet wurden getrennt betrachtet. - [ ] interne und externe Ziele wurden verglichen. - [ ] Download und Upload wurden getrennt geprüft. - [ ] Client-CPU, RAM und Datenträger wurden berücksichtigt. - [ ] Interface- und Linkstatus wurden geprüft. - [ ] ausgehandelte Geschwindigkeit und Duplex wurden kontrolliert. - [ ] Kabel, Adapter, Dockingstation und Switchport wurden berücksichtigt. - [ ] Interfacezähler wurden vor und nach einem Test verglichen. - [ ] Latenz zum Gateway wurde gemessen. - [ ] Latenz zu weiteren Zielen wurde verglichen. - [ ] Paketverlust wurde Ende zu Ende geprüft. - [ ] Diagnoseantworten von Zwischenhops wurden nicht ungeprüft bewertet. - [ ] Route und Rückweg wurden berücksichtigt. - [ ] IPv4 und IPv6 wurden getrennt verglichen. - [ ] ein kontrollierter Durchsatztest wurde durchgeführt. - [ ] Gegenrichtung wurde geprüft. - [ ] einzelne und mehrere TCP-Verbindungen wurden bei Bedarf verglichen. - [ ] Dateisystem und Datenträger wurden vom Netzwerk abgegrenzt. - [ ] WLAN-Signal, Kanal und Airtime wurden geprüft. - [ ] Switch-Uplinks und Port-Channels wurden berücksichtigt. - [ ] Queue Drops und Auslastung wurden geprüft. - [ ] Firewall, Proxy, VPN und Sicherheitsprüfung wurden berücksichtigt. - [ ] Serverressourcen wurden geprüft. - [ ] Virtualisierung und Host-Uplink wurden berücksichtigt. - [ ] MTU und Tunnel-Overhead wurden bei passenden Symptomen geprüft. - [ ] TCP-Wiederholungen wurden bei Bedarf analysiert. - [ ] DNS-, TCP-, TLS- und Anwendungszeiten wurden abgegrenzt. - [ ] sporadische Fehler wurden zeitgestempelt erfasst. - [ ] Paketaufzeichnungen erfolgten nur mit Berechtigung. - [ ] eine konkrete Hypothese wurde formuliert. - [ ] nur eine kontrollierbare Änderung wurde vorgenommen. - [ ] Latenz, Verlust und Durchsatz wurden nach der Änderung erneut gemessen. - [ ] die ursprüngliche Anwendung wurde erneut getestet. - [ ] Vergleichssysteme funktionieren weiterhin. - [ ] temporäre Testkonfigurationen wurden entfernt. - [ ] Ursache, Maßnahme und Nachweis wurden dokumentiert. --- **35. Schnellreferenz** | Fehlerbild | wahrscheinlicher Untersuchungsbereich | |---|---| | nur ein Client langsam | Client, Kabel, Adapter, Treiber oder Switchport | | alle Clients eines Switches langsam | Uplink, Switch, VLAN oder gemeinsame Gegenstelle | | nur WLAN langsam | Funkumgebung, Airtime, Kanal, AP oder Client | | Ethernet und WLAN langsam | Gateway, Uplink, Firewall, WAN, Server oder Anwendung | | nur ein Server langsam | Zielserver, Servernetz, Datenträger oder Anwendung | | alle externen Ziele langsam | WAN, Provider, Firewall, Proxy oder VPN | | nur Upload langsam | Upstream, Queue, Policing, Provider oder VPN | | nur Download langsam | Downstream, Server, TCP, Proxy oder Client | | Latenz steigt nur unter Last | Queue, Auslastung, Bufferbloat oder Drops | | Ping normal, Dateiübertragung langsam | Durchsatz, Datenträger, Protokoll oder Anwendung | | Durchsatztest normal, Anwendung langsam | DNS, TLS, Proxy, Backend, Datenbank oder Server | | Link nur mit 100 Mbit/s | Kabel, Adapter, Switchport oder Aushandlung | | steigende CRC-/FCS-Fehler | physischer Link, Kabel, Transceiver oder Port | | steigende Drops ohne CRC-Fehler | Queue, Überlastung, Policing oder Puffer | | viele TCP-Retransmissions | Paketverlust, Überlastung oder Datenpfad | | TCP Zero Window | Empfänger verarbeitet Daten zu langsam | | kleine Pakete funktionieren, große nicht | MTU, Tunnel oder Fragmentierung | | nur über VPN langsam | Tunnel, MTU, Gateway, Verschlüsselung oder Route | | nur IPv6 langsam | IPv6-Pfad, Firewall, Route oder Zieladresse | | nur IPv4 langsam | IPv4-Pfad, NAT, Firewall oder Route | | nur zu bestimmten Zeiten langsam | Last, Backup, Scan, Job, Provider oder Funkumgebung | | ein TCP-Stream langsam, mehrere schneller | Latenz, Fenster, Verlust oder Serverbegrenzung | | WLAN-Signal gut, Durchsatz schlecht | Kanalauslastung, Airtime, Störung oder Wiederholungen | | erstes Byte langsam | Anwendung, Proxy, Backend oder Datenbank | | erstes Byte schnell, Download langsam | Durchsatz, Verlust, Serverausgabe oder Client | | lokale Ziele schnell, Internet langsam | WAN, Provider, NAT, Firewall oder Proxy | | Gateway bereits langsam | lokaler Link, WLAN, Client oder erstes Netzsegment | --- **Merksatz** > „Langsam“ ist keine eindeutige Fehlerursache. Eine belastbare Analyse trennt Latenz, Paketverlust, Jitter und Durchsatz, vergleicht funktionierende und betroffene Pfade und prüft anschließend Client, Link, WLAN, Switch, Firewall, WAN, Server und Anwendung. Erst reproduzierbare Messwerte vor und nach einer kontrollierten Änderung belegen eine Verbesserung. --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Guidance for troubleshooting TCP/IP performance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-tcp-ip-performance-guidance) - [Microsoft Learn – Overview of TCP/IP performance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/overview-of-tcpip-performance) - [Microsoft Learn – TCP/IP performance known issues](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/tcpip-performance-known-issues) - [Microsoft Learn – Network Adapter Performance Tuning in Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/technologies/network-subsystem/net-sub-performance-tuning-nics) - [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) - [ESnet – iperf3 documentation](https://software.es.net/iperf/) - [ESnet – Invoking iperf3](https://software.es.net/iperf/invoking.html) - [ESnet – iperf3 FAQ and supported platforms](https://software.es.net/iperf/faq.html) - [Wireshark User’s Guide – TCP Analysis](https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html) - [Wireshark – Display Filter Reference: TCP](https://www.wireshark.org/docs/dfref/t/tcp.html) - [Wireshark – TShark Manual](https://www.wireshark.org/docs/man-pages/tshark.html) - [RFC 6349 – Framework for TCP Throughput Testing](https://www.rfc-editor.org/rfc/rfc6349) - [RFC 9293 – Transmission Control Protocol](https://www.rfc-editor.org/rfc/rfc9293) - [RFC 8201 – Path MTU Discovery for IPv6](https://www.rfc-editor.org/rfc/rfc8201) - [RFC 1191 – Path MTU Discovery](https://www.rfc-editor.org/rfc/rfc1191) # 6.6 Fehler tritt nur manchmal auf – sporadische Störungen systematisch erfassen und korrelieren Sporadische Fehler gehören zu den schwierigsten Störungen in der IT-Fehleranalyse. Zum Zeitpunkt der Untersuchung funktioniert das betroffene System häufig wieder normal. Einzelne manuelle Tests liefern dann keine auffälligen Ergebnisse. Typische Aussagen sind: - „Das passiert nur manchmal.“ - „Nach einigen Minuten geht es wieder.“ - „Heute Morgen war alles langsam.“ - „Die Verbindung bricht unregelmäßig ab.“ - „Nach einem Neustart funktioniert es wieder.“ - „Der Fehler tritt nur bei bestimmten Benutzern auf.“ - „In den Protokollen ist nichts zu sehen.“ - „Es passiert meistens nachts oder unter hoher Last.“ Eine belastbare Untersuchung benötigt deshalb: 1. einen möglichst genauen Fehlerzeitpunkt, 2. eine reproduzierbare Beschreibung des Symptoms, 3. kontinuierliche oder ereignisgesteuerte Messungen, 4. ausreichend lange aufbewahrte Protokolle, 5. synchronisierte Systemzeiten, 6. Messdaten vor, während und nach dem Fehler, 7. eine gemeinsame Zeitleiste aller beteiligten Systeme. Ein unauffälliger Einzeltest beweist lediglich, dass der Fehler während dieses Tests nicht beobachtet wurde. --- **1. Was ist ein sporadischer Fehler?** Ein sporadischer Fehler tritt nicht dauerhaft und häufig nicht zuverlässig reproduzierbar auf. Mögliche Erscheinungsformen: - zufällig wirkende Verbindungsabbrüche, - zeitweise sehr hohe Latenz, - gelegentliche Anmeldefehler, - nur einzelne fehlgeschlagene DNS-Anfragen, - kurzzeitige Serverausfälle, - unregelmäßige WLAN-Unterbrechungen, - vereinzelte Zeitüberschreitungen, - Dienste reagieren vorübergehend nicht, - Dateien können manchmal nicht geöffnet werden, - eine Anwendung verliert gelegentlich ihre Sitzung, - ein Switchport wechselt kurzzeitig den Linkstatus, - ein DHCP-Lease wird gelegentlich nicht erneuert, - Zertifikats- oder Tokenfehler treten nur zu bestimmten Zeiten auf. Sporadisch bedeutet nicht automatisch zufällig. Häufig besitzt der Fehler ein Muster, das erst durch ausreichend lange Beobachtung sichtbar wird. --- **2. Typische Ursachen** Mögliche Ursachen sind: - kurzzeitige Link-Unterbrechung, - beschädigtes Kabel oder loser Steckverbinder, - instabile Stromversorgung, - Überhitzung, - WLAN-Interferenz, - Roaming zwischen Access Points, - ausgelasteter Uplink, - Microbursts, - kurzfristig volle Warteschlangen, - DHCP-Lease-Erneuerung, - ablaufender DNS-Cache oder DNS-TTL, - Token- oder Sitzungsablauf, - Idle-Timeout, - VPN-Rekeying, - Zertifikatsablauf oder fehlerhafte Zertifikatsprüfung, - geplantes Backup, - Virenscan, - Snapshot, - Replikation, - Datenbankwartung, - Softwareverteilung, - Update oder Neustart, - Ressourcenerschöpfung, - Speicherleck, - kurzzeitig hohe CPU- oder Datenträgerlast, - begrenzter Connection Pool, - Port- oder Socket-Erschöpfung, - Paketverlust, - Firewall- oder Proxy-Timeout, - Load-Balancer-Health-Check, - Cluster-Failover, - Providerstörung, - Fehler in einem externen Dienst. --- **3. Auswirkungen bestimmen** Vor der technischen Untersuchung muss der Umfang eingegrenzt werden. Zu klären ist: - ein Benutzer oder mehrere Benutzer, - ein Client oder mehrere Clients, - ein Standort oder mehrere Standorte, - WLAN oder Ethernet, - ein VLAN oder mehrere VLANs, - ein Server oder mehrere Server, - eine Anwendung oder mehrere Anwendungen, - interne oder externe Ziele, - IPv4 oder IPv6, - mit oder ohne VPN, - nur Upload oder nur Download, - nur ein bestimmter Geschäftsprozess, - nur eine bestimmte Uhrzeit, - nur unter Last, - nur nach längerer Inaktivität, - nur nach Anmeldung, Aufwachen oder Netzwerkwechsel. Eine Beobachtung wie „Das Netzwerk war kurz weg“ ist noch keine ausreichende Fehlerbeschreibung. --- **4. Fehlerzeitpunkt exakt erfassen** Der wichtigste Ausgangspunkt ist ein möglichst genauer Zeitstempel. Ungeeignet: ```text Der Fehler war heute Morgen. ``` Besser: ```text 02.08.2026 zwischen 09:14:20 und 09:15:05 Uhr ``` Noch besser: ```text 02.08.2026, 09:14:37 Uhr: Beim Öffnen von \\fileserver.example.test\projekte erschien nach etwa 30 Sekunden die Meldung „Der Netzwerkname wurde nicht gefunden“. 09:15:05 Uhr: Ein erneuter Versuch war erfolgreich. ``` Zusätzlich zu dokumentieren: - Zeitzone, - Benutzer, - Clientname, - Client-IP, - MAC-Adresse, - Standort, - Verbindungstyp, - Access Point oder Switchport, - Zielname, - Ziel-IP, - Anwendung, - verwendeter Port, - genaue Meldung, - Dauer, - Aktion unmittelbar vor dem Fehler, - Zustand nach dem Fehler. Screenshots sollten nach Möglichkeit die Uhrzeit enthalten. Andernfalls muss der Zeitpunkt separat dokumentiert werden. --- **5. Systemzeiten kontrollieren** Daten verschiedener Systeme können nur sinnvoll korreliert werden, wenn ihre Uhren ausreichend genau synchronisiert sind. Zu prüfen sind: - Uhrzeit, - Datum, - Zeitzone, - konfigurierte Zeitquelle, - Synchronisationsstatus, - Abweichung zur Referenz, - Zeitpunkt der letzten Synchronisation, - Erreichbarkeit der Zeitquelle, - Zeitstatus virtueller Maschinen, - Zeitquelle von Netzwerkgeräten, - Zeitquelle von Containern und Hosts. **Windows** ```powershell Get-Date Get-TimeZone w32tm /query /status w32tm /query /source w32tm /query /configuration ``` **Linux** ```bash date --iso-8601=seconds timedatectl status timedatectl timesync-status ``` **macOS** ```bash date systemsetup -gettimezone systemsetup -getusingnetworktime systemsetup -getnetworktimeserver ``` Ein Zeitunterschied von mehreren Minuten kann dazu führen, dass zusammengehörige Ereignisse in Client-, Server-, Firewall- und Netzwerkprotokollen nicht erkannt werden. Die Uhrzeit darf nicht unkontrolliert verändert werden. In Domänen, Clustern, Datenbanken und authentifizierten Umgebungen können Zeitsprünge zusätzliche Fehler verursachen. --- **6. Fehlermeldung vollständig sichern** Zu erfassen sind: - vollständiger Meldungstext, - Fehlercode, - Event-ID, - HTTP-Statuscode, - Anwendungscode, - Quell- und Zielsystem, - betroffene Datei oder Ressource, - Zeitpunkt, - vorherige Benutzeraktion, - Dauer bis zur Meldung, - Verhalten bei Wiederholung. Beispiel: ```text Ungeeignet: „VPN ging nicht.“ Geeignet: „Am 02.08.2026 um 11:42:18 Uhr brach die bestehende VPN-Verbindung nach ungefähr 27 Minuten Laufzeit ab. Der Client meldete Fehlercode 809. Der lokale Internetzugang funktionierte währenddessen weiter. Die erneute VPN-Verbindung war um 11:43:02 Uhr erfolgreich.“ ``` Die originale Meldung darf nicht nur sinngemäß wiedergegeben werden. --- **7. Muster suchen** Sporadische Fehler sollten nach wiederkehrenden Merkmalen untersucht werden. | Muster | möglicher Untersuchungsbereich | |---|---| | immer zur gleichen Uhrzeit | Backup, Scan, Update, Wartungsjob oder Provider | | nach längerer Inaktivität | Idle-Timeout, Energiesparmodus oder Sitzung | | nach Ablauf einer festen Dauer | Lease, Token, Session, NAT, Firewall oder VPN-Rekeying | | nur unter Last | Ressourcen, Queue, Uplink, Storage oder Connection Pool | | nur montags oder nach dem Wochenende | Lease, Kennwort, Zertifikat, Patch oder Neustart | | nur bei einem Benutzer | Benutzerprofil, Berechtigung, Token oder Endgerät | | nur bei einem Client | Hardware, Treiber, Kabel, WLAN oder lokale Software | | nur an einem Standort | WAN, WLAN, Switch, Strom oder Provider | | nur bei WLAN | Interferenz, Roaming, Airtime oder Access Point | | nur bei VPN | Tunnel, Gateway, MTU, Rekeying oder Route | | nach Aufwachen des Clients | Treiber, DHCP, DNS, VPN oder Energiesparmodus | | nach Konfigurationsänderung | fehlerhafte Änderung oder Abhängigkeit | | alle 30 oder 60 Minuten | geplanter Timer, Lease, Token, Job oder Polling | | bei hoher Raumtemperatur | Kühlung, Transceiver, Netzteil oder Hardware | | bei Regen oder Wind | Außenleitung, Funkstrecke, Strom oder Providerpfad | Eine zeitliche Übereinstimmung ist zunächst nur eine Korrelation und noch kein Beweis für die Ursache. --- **8. Kontinuierliche Erreichbarkeitsmessung unter Windows** Ein einfacher protokollierter Test kann prüfen, ob ein Ziel zum Störungszeitpunkt erreichbar war. ```powershell $Target = "" $LogFile = ".\availability.csv" "Time,Target,Status,LatencyMs" | Set-Content -Path $LogFile while ($true) { $Time = Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK" $Result = Test-Connection -TargetName $Target -Count 1 -ErrorAction SilentlyContinue if ($Result) { "$Time,$Target,Success,$($Result.Latency)" | Add-Content -Path $LogFile } else { "$Time,$Target,Failure," | Add-Content -Path $LogFile } Start-Sleep -Seconds 5 } ``` Vor dem Einsatz ist zu prüfen, welche Eigenschaften `Test-Connection` in der verwendeten PowerShell-Version zurückgibt. Beenden: ```text [CTRL] + [C] ``` Die Messung zeigt nur die ICMP-Erreichbarkeit des gewählten Ziels. Sie beweist nicht, dass DNS, TCP, TLS oder die Anwendung funktioniert haben. --- **9. Kontinuierliche Erreichbarkeitsmessung unter Linux und macOS** ```bash target="" logfile="./availability.log" while true; do printf '%s ' "$(date '+%Y-%m-%dT%H:%M:%S%z')" >> "$logfile" if ping -c 1 -W 2 "$target" >> "$logfile" 2>&1; then printf 'STATUS=SUCCESS\n' >> "$logfile" else printf 'STATUS=FAILURE\n' >> "$logfile" fi sleep 5 done ``` Je nach Betriebssystem unterscheiden sich die Optionen und die Einheit des Ping-Timeouts. Der konkrete Befehl muss auf dem Zielsystem geprüft werden. Beenden: ```text [CTRL] + [C] ``` Sinnvolle parallele Ziele: 1. Loopback-Adresse, 2. eigene IP-Adresse, 3. Standardgateway, 4. interner Server, 5. DNS-Server, 6. VPN-Gateway, 7. externes Vergleichsziel, 8. tatsächlich betroffener Dienst. Dadurch kann erkannt werden, ab welchem Teil des Pfades der Fehler sichtbar wird. --- **10. Dienst statt nur Ping überwachen** Wenn die Anwendung einen bestimmten TCP-Port benötigt, sollte zusätzlich dieser Port getestet werden. **Windows** ```powershell $Target = "" $Port = $LogFile = ".\tcp-check.csv" "Time,Target,Port,Success" | Set-Content -Path $LogFile while ($true) { $Time = Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK" $Result = Test-NetConnection -ComputerName $Target -Port $Port ` -InformationLevel Quiet "$Time,$Target,$Port,$Result" | Add-Content -Path $LogFile Start-Sleep -Seconds 10 } ``` **Linux und macOS** ```bash while true; do timestamp="$(date '+%Y-%m-%dT%H:%M:%S%z')" if nc -z -w 3 ; then printf '%s TARGET=%s PORT=%s STATUS=SUCCESS\n' \ "$timestamp" "" "" else printf '%s TARGET=%s PORT=%s STATUS=FAILURE\n' \ "$timestamp" "" "" fi sleep 10 done >> tcp-check.log 2>&1 ``` Ein erfolgreicher TCP-Verbindungsaufbau beweist noch nicht, dass Anmeldung, Datenbank, Backend oder vollständiger Geschäftsprozess funktionieren. --- **11. DNS kontinuierlich prüfen** Sporadische Namensauflösungsfehler können durch einen einzelnen Ping auf eine IP-Adresse übersehen werden. **Windows** ```powershell $Name = "" $LogFile = ".\dns-check.log" while ($true) { $Time = Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK" "===== $Time =====" | Add-Content -Path $LogFile Resolve-DnsName -Name $Name -ErrorAction Continue | Out-String | Add-Content -Path $LogFile Start-Sleep -Seconds 30 } ``` **Linux und macOS** ```bash while true; do printf '===== %s =====\n' "$(date '+%Y-%m-%dT%H:%M:%S%z')" dig sleep 30 done >> dns-check.log 2>&1 ``` Zu vergleichen sind: - Antwortzeit, - verwendeter DNS-Server, - Antwortcode, - A-Record, - AAAA-Record, - CNAME, - TTL, - wechselnde Zieladressen, - Antwort bei Erfolg und Fehler. Ein absichtlich wechselnder DNS-Eintrag, beispielsweise bei einem Load Balancer, darf nicht automatisch als Fehler bewertet werden. --- **12. HTTP- und Anwendungszeiten aufzeichnen** Für HTTP- oder HTTPS-Dienste kann `curl` einzelne Zeitabschnitte protokollieren. ```bash while true; do timestamp="$(date '+%Y-%m-%dT%H:%M:%S%z')" result="$(curl -sS -o /dev/null \ --connect-timeout 10 \ --max-time 30 \ -w 'code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}' \ https:/// 2>&1)" printf '%s %s\n' "$timestamp" "$result" sleep 30 done >> http-check.log ``` Mögliche Einordnung: | Beobachtung | möglicher Bereich | |---|---| | DNS-Zeit erhöht | Resolver oder DNS-Pfad | | TCP-Aufbau erhöht | Netzwerkpfad, Paketverlust oder Ziel | | TLS-Zeit erhöht | Zertifikatsprüfung, Inspection oder Server | | erstes Byte verspätet | Anwendung, Proxy, Backend oder Datenbank | | Gesamtzeit erhöht | Übertragung, Durchsatz, Server oder Client | | wechselnde Ziel-IP mit Fehler nur bei einer IP | Load Balancer oder einzelner Backend-Pfad | | HTTP-Fehlercode | Anwendung, Proxy, Authentifizierung oder Backend | Die Abfrage muss auf einen ungefährlichen und autorisierten Endpunkt begrenzt werden. --- **13. Interfacezustand und Fehlerzähler regelmäßig erfassen** Sporadische Linkfehler sind häufig nur als kurzzeitiger Statuswechsel oder steigender Fehlerzähler sichtbar. **Windows** ```powershell $LogFile = ".\adapter-statistics.csv" while ($true) { $Time = Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK" Get-NetAdapterStatistics | Select-Object @{ Name = "Time" Expression = { $Time } }, Name, ReceivedBytes, SentBytes, ReceivedUnicastPackets, SentUnicastPackets, ReceivedDiscardedPackets, OutboundDiscardedPackets, ReceivedPacketErrors, OutboundPacketErrors | Export-Csv -Path $LogFile -Append -NoTypeInformation Start-Sleep -Seconds 30 } ``` **Linux** ```bash while true; do printf '===== %s =====\n' "$(date '+%Y-%m-%dT%H:%M:%S%z')" ip -s link show dev ethtool ethtool -S sleep 30 done >> interface-check.log 2>&1 ``` **macOS** ```bash while true; do printf '===== %s =====\n' "$(date '+%Y-%m-%dT%H:%M:%S%z')" ifconfig netstat -ib sleep 30 done >> interface-check.log 2>&1 ``` Zu beobachten sind insbesondere: - Link up/down, - ausgehandelte Geschwindigkeit, - Duplex, - CRC- oder FCS-Fehler, - Eingabe- und Ausgabefehler, - verworfene Pakete, - Queue Drops, - Carrier-Fehler, - Link-Flaps, - neu ausgehandelte Verbindung, - steigende Fehlerdifferenz zwischen zwei Messzeitpunkten. Absolute Zählerstände reichen nicht aus. Entscheidend ist, ob und wann die Zähler während des Fehlers gestiegen sind. --- **14. Switchport und Access Point überwachen** Auf der Netzwerkkomponente sollten mindestens geprüft werden: - Portstatus, - letzter Statuswechsel, - Anzahl Link-Flaps, - Speed und Duplex, - CRC-/FCS-Fehler, - Input Errors, - Output Errors, - Discards, - Queue Drops, - Broadcast- und Multicast-Anteil, - PoE-Status, - Temperatur, - Transceiverwerte, - VLAN-Zugehörigkeit, - Spanning-Tree-Ereignisse, - Port-Channel-Status, - MAC-Adresswechsel, - WLAN-An- und Abmeldungen, - Roaming-Ereignisse, - Deauthentication, - Signalstärke, - Wiederholungsrate, - Kanal- und Airtime-Auslastung. Die Befehle und Zählerbezeichnungen unterscheiden sich je nach Hersteller und Modell. Ihre genaue Bedeutung muss anhand der jeweiligen Herstellerdokumentation geprüft werden. --- **15. Ereignisprotokolle unter Windows zeitlich eingrenzen** Beispiel für Systemereignisse eines bestimmten Zeitraums: ```powershell $Start = Get-Date "2026-08-02 09:10:00" $End = Get-Date "2026-08-02 09:20:00" Get-WinEvent -FilterHashtable @{ LogName = "System" StartTime = $Start EndTime = $End } | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message | Sort-Object TimeCreated ``` Mehrere Protokolle können getrennt untersucht werden: ```powershell $Logs = @( "System", "Application", "Microsoft-Windows-DNS-Client/Operational", "Microsoft-Windows-WLAN-AutoConfig/Operational" ) foreach ($Log in $Logs) { Get-WinEvent -FilterHashtable @{ LogName = $Log StartTime = $Start EndTime = $End } -ErrorAction SilentlyContinue | Select-Object @{ Name = "Log" Expression = { $Log } }, TimeCreated, Id, ProviderName, LevelDisplayName, Message } ``` Nicht jedes Protokoll ist auf jedem System vorhanden oder aktiviert. Zusätzliche Protokollierung sollte kontrolliert und mit Blick auf Speicherbedarf, Datenschutz und Systemlast aktiviert werden. --- **16. Protokolle unter Linux zeitlich eingrenzen** ```bash journalctl \ --since "2026-08-02 09:10:00" \ --until "2026-08-02 09:20:00" ``` Nur Meldungen eines Dienstes: ```bash journalctl \ -u .service \ --since "2026-08-02 09:10:00" \ --until "2026-08-02 09:20:00" ``` Kernelmeldungen: ```bash journalctl \ -k \ --since "2026-08-02 09:10:00" \ --until "2026-08-02 09:20:00" ``` Neue Meldungen fortlaufend beobachten: ```bash journalctl -f ``` Zu berücksichtigen sind: - Zeitzone, - persistente oder flüchtige Speicherung, - Aufbewahrungsdauer, - Rotation, - Rate Limiting, - ausreichender Datenträgerspeicher, - Berechtigungen, - zentrale Weiterleitung. Ein fehlender Eintrag beweist nicht automatisch, dass kein Fehler aufgetreten ist. Das Ereignis kann außerhalb der Aufbewahrungszeit liegen, in einem anderen Protokoll stehen oder nicht protokolliert worden sein. --- **17. Protokolle unter macOS zeitlich eingrenzen** ```bash log show \ --start "2026-08-02 09:10:00" \ --end "2026-08-02 09:20:00" \ --style syslog ``` Nach Prozess filtern: ```bash log show \ --start "2026-08-02 09:10:00" \ --end "2026-08-02 09:20:00" \ --predicate 'process == ""' \ --style syslog ``` Fortlaufende Beobachtung: ```bash log stream --style syslog ``` Die genaue Syntax und die verfügbaren Protokolldaten können sich zwischen macOS-Versionen unterscheiden. --- **18. Ringpuffer-Paketmitschnitt mit Dumpcap** Ein Ringpuffer bewahrt nur die letzten Aufzeichnungsdateien auf. Wenn der Fehler auftritt, muss die Aufzeichnung zeitnah gestoppt werden, bevor die relevanten Daten überschrieben werden. Interfaces anzeigen: ```bash dumpcap -D ``` Beispiel: ```bash dumpcap \ -i \ -w intermittent.pcapng \ -b duration:300 \ -b files:12 ``` Dieses Beispiel: - wechselt alle 300 Sekunden die Datei, - hält maximal 12 Dateien, - überschreibt anschließend die ältesten Dateien, - bewahrt damit ungefähr die letzten 60 Minuten auf. Alternative Begrenzung nach Dateigröße: ```bash dumpcap \ -i \ -w intermittent.pcapng \ -b filesize:100000 \ -b files:10 ``` Hierbei ist `filesize` in Kilobyte angegeben. Optionaler Capture-Filter: ```bash dumpcap \ -i \ -f "host and port " \ -w intermittent.pcapng \ -b duration:300 \ -b files:12 ``` Capture-Filter und Wireshark-Anzeigefilter besitzen unterschiedliche Syntax. Ein zu enger Filter kann die für die Ursachenanalyse benötigten Pakete ausschließen. --- **19. Ringpuffer-Paketmitschnitt mit tcpdump** ```bash tcpdump \ -i \ -s 0 \ -G 300 \ -W 12 \ -w 'intermittent-%Y%m%d-%H%M%S.pcap' ``` Möglicher Filter: ```bash tcpdump \ -i \ -s 0 \ -G 300 \ -W 12 \ -w 'intermittent-%Y%m%d-%H%M%S.pcap' \ 'host and port ' ``` Die Kombination und genaue Wirkung der Rotationsoptionen kann von der installierten `tcpdump`-Version abhängen und muss vor dem produktiven Einsatz mit der lokalen Handbuchseite geprüft werden: ```bash man tcpdump ``` Paketaufzeichnungen können personenbezogene Daten, Anmeldedaten, Sitzungsinformationen und vertrauliche Inhalte enthalten. Sie dürfen nur mit entsprechender Berechtigung erstellt, geschützt gespeichert und nach Abschluss kontrolliert gelöscht werden. --- **20. Windows-Paketmitschnitt mit Pktmon** Filter anzeigen: ```powershell pktmon filter list ``` Vorhandene Filter entfernen: ```powershell pktmon filter remove ``` Beispiel für eine begrenzte zirkuläre Aufzeichnung: ```powershell pktmon start ` --capture ` --comp nics ` --pkt-size 0 ` --file-name C:\Temp\intermittent.etl ` --file-size 512 ` --log-mode circular ``` Aufzeichnung stoppen: ```powershell pktmon stop ``` In PCAPNG umwandeln: ```powershell pktmon etl2pcap ` C:\Temp\intermittent.etl ` --out C:\Temp\intermittent.pcapng ``` Im zirkulären Modus werden bei Erreichen der festgelegten Größe ältere Ereignisse überschrieben. Die Aufzeichnung muss daher nach Auftreten des Fehlers zeitnah gestoppt werden. Die verfügbaren Optionen unterscheiden sich zwischen Windows-Versionen. Vor dem Einsatz ist die lokale Hilfe zu prüfen: ```powershell pktmon start help pktmon etl2pcap help ``` --- **21. Monitoringauflösung passend wählen** Ein Monitoringintervall von fünf Minuten kann einen Fehler übersehen, der nur 20 Sekunden dauert. Beispiel: ```text 09:10:00 Messung erfolgreich 09:12:15 Fehler beginnt 09:12:40 Fehler endet 09:15:00 Messung erfolgreich ``` Das Monitoring zeigt keinen Ausfall, obwohl der Dienst 25 Sekunden nicht verfügbar war. Mögliche Maßnahmen: - kürzeres Prüfintervall, - aktiver Diensttest statt nur Ping, - mehrere Messpunkte, - zeitlich begrenzte höhere Auflösung, - Event- oder Trap-Auswertung, - Aufzeichnung von Minimal-, Maximal- und Durchschnittswerten, - Perzentile statt ausschließlich Mittelwerte, - Statuswechsel sofort protokollieren, - Fehlerzähler als Differenz erfassen, - Rohdaten ausreichend lange aufbewahren. Eine höhere Auflösung erzeugt mehr Last, Daten und Warnmeldungen. Sie sollte gezielt für die betroffene Komponente und einen begrenzten Zeitraum verwendet werden. --- **22. Welche Messwerte langfristig hilfreich sind** **Client** - CPU, - RAM, - Datenträgerlatenz, - Netzwerkstatus, - Linkgeschwindigkeit, - WLAN-Signal, - verwendeter Access Point, - DHCP-Lease, - DNS-Server, - VPN-Status, - Ereignisprotokolle. **Switch und Router** - Interface up/down, - Fehler und Discards, - Auslastung, - Queue Drops, - Port-Channel-Status, - Routingnachbarn, - CPU, - RAM, - Temperatur, - Stromversorgung. **Firewall und VPN** - Sitzungsanzahl, - NAT-Auslastung, - CPU, - RAM, - Paketverlust, - Drops, - Tunnelstatus, - Rekeying, - Failover, - Sicherheitsereignisse. **Server** - CPU pro Prozess, - RAM, - Paging oder Swapping, - Datenträgerlatenz, - I/O-Wait, - Netzwerkfehler, - offene Verbindungen, - Queue, - Anwendungsthreads, - Connection Pools, - Datenbanklocks, - Dienstneustarts. **WLAN** - Signalstärke, - Signal-Rausch-Verhältnis, - Kanal, - Airtime, - Wiederholungsrate, - Roaming, - Deauthentication, - Access-Point-Auslastung, - Uplinkstatus. --- **23. Ablaufzeiten und regelmäßige Erneuerungen prüfen** Sporadische Fehler können entstehen, wenn ein regelmäßig erneuerter Zustand abläuft. Zu prüfen sind: - DHCP-Lease, - DNS-TTL, - ARP- und Neighbor-Cache, - Kerberos-Ticket, - OAuth- oder Anwendungstoken, - Websitzung, - Cookie, - Firewall-Session, - NAT-Zuordnung, - Load-Balancer-Persistenz, - VPN-SA und Rekeying, - Zertifikatsgültigkeit, - CRL- oder OCSP-Erreichbarkeit, - Kennwortablauf, - Maschinenkennwort, - Connection Pool, - Idle-Timeout, - Keepalive, - Lease eines verteilten Locks. Beispiel: ```text Fehlerabstand: ungefähr 60 Minuten Sitzungs-Timeout: 60 Minuten ``` Diese Übereinstimmung begründet eine Hypothese, beweist sie aber noch nicht. Der tatsächliche Ablauf und die anschließende Erneuerung müssen in Protokollen oder Paketdaten bestätigt werden. --- **24. Geplante Jobs und Wartungsarbeiten korrelieren** Zu untersuchen sind: - Backuppläne, - Snapshots, - Virenscans, - Patchmanagement, - Softwareverteilung, - Datenbankwartung, - Logrotation, - Replikation, - Synchronisation, - Indexierung, - Cronjobs, - systemd-Timer, - Windows-Aufgabenplanung, - Cloud-Automationen, - Container-Restarts, - Zertifikatserneuerung, - DHCP- oder DNS-Bereinigung, - Reportingjobs, - geplante Providerarbeiten. **Windows** ```powershell Get-ScheduledTask | Select-Object TaskPath, TaskName, State ``` Letzte und nächste Ausführung: ```powershell Get-ScheduledTask | Get-ScheduledTaskInfo | Select-Object TaskName, LastRunTime, LastTaskResult, NextRunTime ``` **Linux** ```bash systemctl list-timers --all ``` Zusätzlich können je nach System Cron-Konfigurationen und deren Protokolle relevant sein. Nur autorisierte Konfigurationen dürfen eingesehen werden. Aufgaben sollten nicht allein wegen einer zeitlichen Überschneidung deaktiviert werden. --- **25. Temperatur, Strom und physische Umgebung berücksichtigen** Kurzzeitige Ausfälle können durch physische Bedingungen verursacht werden. Zu prüfen sind: - Gerätetemperatur, - Lüfterstatus, - Netzteilstatus, - PoE-Leistung, - USV-Ereignisse, - Spannungsschwankungen, - transceiverbezogene Warnungen, - Tür- oder Racktemperatur, - Kabelbewegung, - Feuchtigkeit, - Außenleitung, - Bauarbeiten, - Funkstörungen, - Neustarts nach Stromverlust. Typisches Muster: ```text Hohe Last → Temperatur steigt → Schnittstelle oder Gerät fällt kurzzeitig aus → automatische Wiederherstellung → Untersuchung erfolgt später bei normaler Temperatur ``` Ein Neustart kann Temperatur-, Speicher- und Fehlerzustände zurücksetzen und dadurch wichtige Beweise beseitigen. --- **26. Änderungen und Deployments berücksichtigen** Zu dokumentieren sind: - Zeitpunkt der Änderung, - betroffene Systeme, - vorherige Version, - neue Version, - geänderte Konfiguration, - verantwortlicher Change, - Rollbackmöglichkeit, - erste beobachtete Störung, - weitere abhängige Systeme. Mögliche Änderungen: - Treiberupdate, - Firmwareupdate, - Betriebssystemupdate, - Firewallregel, - Routingänderung, - DNS-Änderung, - Zertifikatswechsel, - Anwendungsversion, - Datenbankschema, - Proxykonfiguration, - Load-Balancer-Pool, - VLAN-Änderung, - WLAN-Kanalplanung, - Container-Image, - Ressourcenlimit. „Seit dem Update“ ist eine wichtige Beobachtung, aber noch kein technischer Nachweis. Die fehlerhafte Version oder Einstellung muss durch Vergleich, Protokoll oder kontrollierten Rollback bestätigt werden. --- **27. Daten auf einer gemeinsamen Zeitleiste korrelieren** Beispiel: | Uhrzeit | Client | Switch | Firewall | Server | |---|---|---|---|---| | 09:14:31 | Anwendung startet Anfrage | Port aktiv | Sitzung angelegt | Anfrage empfangen | | 09:14:34 | wartet auf Antwort | Output Drops steigen | Weiterleitung erfolgt | Datenträgerlatenz steigt | | 09:14:37 | Timeout | Port weiterhin aktiv | Sitzung beendet | Anwendung antwortet verspätet | | 09:15:02 | erneuter Versuch | Zähler stabil | neue Sitzung | Antwort normal | Erst durch die gemeinsame Zeitleiste wird sichtbar, dass der Clienttimeout mit der erhöhten Datenträgerlatenz zusammenfällt. Zu korrelieren sind: - Benutzeraktion, - Clientprotokoll, - DNS-Antwort, - Paketmitschnitt, - Switchport, - Access Point, - Firewall, - VPN-Gateway, - Load Balancer, - Reverse Proxy, - Serverbetriebssystem, - Anwendung, - Datenbank, - Storage, - Hypervisor, - Providerereignis. Zeitangaben müssen auf dieselbe Zeitzone oder eine eindeutig dokumentierte Referenz umgerechnet werden. --- **28. Ereignisgesteuerte Datensicherung** Wenn der Benutzer den Fehler bemerkt, sollte ein festgelegtes Verfahren ausgelöst werden. Beispiel: ```text 1. genaue Uhrzeit notieren; 2. Screenshot erstellen; 3. betroffene Aktion nicht mehrfach unkontrolliert wiederholen; 4. Diagnosemarkierung oder Ticket auslösen; 5. laufenden Ringpuffer zeitnah stoppen; 6. Clientzustand sichern; 7. relevante Server- und Netzwerkprotokolle exportieren; 8. Monitoringdaten für den Zeitraum schützen; 9. Vergleichssystem prüfen; 10. Dateien eindeutig beschriften. ``` Beispiel für eine Markierungsdatei unter PowerShell: ```powershell $Time = Get-Date -Format "yyyy-MM-ddTHH-mm-ss.fffK" "Fehler durch Benutzer beobachtet: $Time" | Set-Content ".\incident-marker-$Time.txt" ``` Beispiel unter Bash: ```bash timestamp="$(date '+%Y-%m-%dT%H-%M-%S%z')" printf 'Fehler durch Benutzer beobachtet: %s\n' "$timestamp" \ > "incident-marker-$timestamp.txt" ``` Der Marker liefert keine Ursache, erleichtert aber das Auffinden des relevanten Zeitraums. --- **29. Praxisfall A: Verbindung bricht ungefähr jede Stunde ab** **Symptom** - eine Webanwendung trennt den Benutzer unregelmäßig, - der Fehler tritt meistens nach längerer Nutzung auf, - Netzwerk und Server bleiben erreichbar, - eine erneute Anmeldung funktioniert sofort. **Prüfung** 1. genaue Sitzungsdauer erfassen. 2. Browser-, Proxy- und Anwendungsprotokolle vergleichen. 3. Token- und Sitzungsablauf kontrollieren. 4. Firewall- und Load-Balancer-Timeout berücksichtigen. 5. Zeitpunkt der letzten Benutzeraktivität dokumentieren. 6. Ablauf und Erneuerung im Netzwerk- oder Anwendungsprotokoll prüfen. 7. funktionierenden Benutzer oder Client vergleichen. **Mögliche Ursache** Die Anwendung erneuert ein ablaufendes Token nicht korrekt. Nach Ablauf wird die nächste Anfrage abgelehnt. **Nachprüfung** - Sitzung bleibt über den bisherigen Fehlerzeitpunkt hinaus aktiv, - Token wird ordnungsgemäß erneuert, - keine zusätzlichen Anmeldefehler entstehen, - Firewall und Netzwerk bleiben unverändert unauffällig, - Ursache und Korrektur sind dokumentiert. --- **30. Praxisfall B: Switchport fällt kurzzeitig aus** **Symptom** - ein Client verliert gelegentlich für einige Sekunden die Verbindung, - anschließend funktioniert die Verbindung automatisch wieder, - spätere Pingtests sind unauffällig, - andere Clients sind nicht betroffen. **Prüfung** 1. Client- und Switchzeit synchronisieren. 2. Linkstatus kontinuierlich protokollieren. 3. Switchportereignisse auswerten. 4. Fehlerzähler vor und nach dem Ereignis vergleichen. 5. Kabel und Steckverbindungen kontrollieren. 6. Energiespar- und Treibereinstellungen berücksichtigen. 7. kontrollierten Kabel- oder Portvergleich durchführen. **Mögliche Ursache** Eine beschädigte Steckverbindung verursacht kurzzeitige Link-Flaps. **Nachprüfung** - keine weiteren Link-Flaps, - Fehlerzähler steigen nicht, - Verbindung bleibt unter kontrollierter Last stabil, - Vergleich über einen ausreichend langen Zeitraum, - getauschte Komponente und Messergebnisse dokumentiert. --- **31. Praxisfall C: Dienst jeden Morgen kurz langsam** **Symptom** - die Anwendung ist täglich zwischen 08:00 und 08:10 Uhr langsam, - Netzwerkdurchsatz und Paketverlust sind unauffällig, - Zeit bis zum ersten Byte steigt, - danach normalisiert sich der Dienst. **Prüfung** 1. Anwendungszeiten kontinuierlich erfassen. 2. Serverressourcen im betroffenen Zeitraum prüfen. 3. geplante Aufgaben und Backuppläne vergleichen. 4. Datenträgerlatenz und Datenbanklocks untersuchen. 5. Proxy- und Anwendungsprotokolle korrelieren. 6. Zustand außerhalb des Zeitfensters vergleichen. 7. Job nicht ungeprüft deaktivieren. **Mögliche Ursache** Ein täglicher Datenbankjob erzeugt hohe Datenträgerlast und konkurriert mit den Anwendungsabfragen. **Nachprüfung** - Job wird in einem vorgesehenen Wartungsfenster ausgeführt oder kontrolliert angepasst, - Datenträgerlatenz bleibt während der Nutzungszeit normal, - Zeit bis zum ersten Byte ist stabil, - ursprünglicher Geschäftsprozess funktioniert, - Backup- oder Wartungsziel bleibt erfüllt. --- **32. Praxisfall D: WLAN-Unterbrechung nur beim Standortwechsel** **Symptom** - Verbindung funktioniert an festen Standorten, - beim Wechsel zwischen zwei Gebäudebereichen entstehen kurze Unterbrechungen, - der Client verbindet sich anschließend automatisch erneut, - Ethernet ist nicht betroffen. **Prüfung** 1. genauen Weg und Zeitpunkt dokumentieren. 2. verwendeten Access Point vor und nach dem Fehler erfassen. 3. Roaming- und Deauthentication-Ereignisse prüfen. 4. Signalstärke und Überlappung untersuchen. 5. Authentifizierungsdauer berücksichtigen. 6. Kanal- und Airtime-Auslastung prüfen. 7. Vergleich mit anderem Client durchführen. **Mögliche Ursache** Der Client hält zu lange an einem schwächer werdenden Access Point fest und wechselt verspätet zur benachbarten Funkzelle. **Nachprüfung** - Roaming erfolgt innerhalb des vorgesehenen Bereichs, - Unterbrechungszeit ist reduziert, - andere Clients und Funkzellen funktionieren weiterhin, - Änderungen entsprechen der WLAN-Planung, - Messwerte vor und nach der Änderung sind dokumentiert. --- **33. Ungeeignete Sofortmaßnahmen** Problematisch sind insbesondere: - Systeme sofort neu starten, - mehrere Komponenten gleichzeitig verändern, - Protokolle erst lange nach dem Fehler prüfen, - Benutzerzeitangaben ungeprüft übernehmen, - einen erfolgreichen Ping als Gegenbeweis verwenden, - Monitoringmittelwerte ohne Rohdaten bewerten, - Protokollierung unbegrenzt aktivieren, - Mitschnitte ohne Größenbegrenzung erstellen, - Capture-Filter zu eng setzen, - alte Ringpufferdateien versehentlich überschreiben, - Firewalls oder Sicherheitsfunktionen pauschal deaktivieren, - geplante Jobs allein wegen zeitlicher Überschneidung abschalten, - Treiber oder Firmware ohne Vergleich austauschen, - Uhren während der Untersuchung manuell verändern, - vertrauliche Protokolle ungeschützt speichern, - einen zeitlichen Zusammenhang sofort als Ursache darstellen, - nur den betroffenen Client untersuchen, - nur Netzwerkdaten betrachten und Server oder Anwendung ignorieren. --- **34. Vollständige Prüfreihenfolge** 1. Symptom eindeutig beschreiben. 2. genaue Fehlermeldung sichern. 3. Beginn und Ende dokumentieren. 4. Zeitzone erfassen. 5. Benutzer, Client und Standort bestimmen. 6. Quelle, Ziel, Port und Anwendung dokumentieren. 7. betroffene und nicht betroffene Systeme bestimmen. 8. Häufigkeit und bisherige Zeitpunkte sammeln. 9. Muster nach Uhrzeit, Dauer und Last suchen. 10. Systemzeiten aller Beteiligten kontrollieren. 11. Vergleichssystem festlegen. 12. geeignete Messintervalle bestimmen. 13. Gateway und Ziel kontinuierlich prüfen. 14. betroffenen TCP-Dienst überwachen. 15. DNS-Antworten protokollieren. 16. Anwendungszeiten erfassen. 17. Interfacezustand und Fehlerzähler aufzeichnen. 18. Switchport oder Access Point überwachen. 19. Serverressourcen protokollieren. 20. relevante Ereignisprotokolle sichern. 21. zentrale Protokollierung und Aufbewahrung prüfen. 22. bei Bedarf autorisierten Ringpuffer-Mitschnitt starten. 23. Speicherbedarf und Datenschutz berücksichtigen. 24. Verfahren zum Markieren des Fehlerzeitpunkts festlegen. 25. bei Auftreten des Fehlers Ringpuffer sichern. 26. Daten vor, während und nach dem Ereignis vergleichen. 27. DHCP-, DNS-, Token-, Sitzungs- und Idle-Zeiten prüfen. 28. geplante Jobs, Backups, Scans und Updates korrelieren. 29. Temperatur, Stromversorgung und physische Umgebung berücksichtigen. 30. Provider- und Wartungsereignisse prüfen. 31. Änderungen und Deployments berücksichtigen. 32. gemeinsame Zeitleiste erstellen. 33. konkrete Hypothese formulieren. 34. genau eine kontrollierbare Änderung durchführen. 35. dieselben Messungen weiterlaufen lassen. 36. ausreichend lange Nachbeobachtung durchführen. 37. ursprüngliche Funktion erneut prüfen. 38. Vergleichssysteme kontrollieren. 39. temporäre Diagnosekonfiguration entfernen. 40. Ursache, Maßnahme und Nachweis dokumentieren. 41. dauerhaftes Monitoring oder Prävention festlegen. --- **35. Dokumentationsbeispiel** ```text Ticket: INC-20804 Zeitraum der Untersuchung: 02.08.2026 bis 05.08.2026 Betroffen: Client-WS-17, Ethernet, Switch SW-F2-03, Port 18 Nicht betroffen: weitere Clients desselben VLANs Ziel: fileserver.example.test, TCP 445 Symptom: Der Client verliert ein- bis dreimal täglich für ungefähr 5 bis 15 Sekunden den Zugriff auf den Dateiserver. Anschließend funktioniert der Zugriff ohne Benutzeraktion wieder. Erfasste Fehlerzeitpunkte: - 02.08.2026, 10:17:42 bis 10:17:51 Uhr - 03.08.2026, 14:32:08 bis 14:32:19 Uhr - 05.08.2026, 09:06:14 bis 09:06:23 Uhr Messungen: - kontinuierlicher Ping zu Gateway und Dateiserver - TCP-Prüfung auf Port 445 - Interfacezähler des Clients - Switchportstatus und Fehlerzähler - Windows-Systemereignisse - begrenzter Ringpuffer-Paketmitschnitt - Serverressourcen und SMB-Protokolle Beobachtung: Zum jeweiligen Fehlerzeitpunkt meldete der Switch einen kurzen Linkverlust an Port 18. Gleichzeitig wechselte das Clientinterface in den Zustand „Disconnected“. Gateway und Server waren für andere Clients erreichbar. Am Switchport stiegen zusätzlich die physischen Fehlerzähler. Hypothese: Die physische Verbindung zwischen Client und Switch ist instabil. Kontrollierte Änderung: Das Patchkabel wurde durch ein geprüftes Kabel ersetzt. Client, Switchport, Treiber und Serverkonfiguration blieben unverändert. Nachprüfung: - sieben Tage kontinuierliche Beobachtung - keine weiteren Link-Flaps - keine steigenden physischen Fehlerzähler - Gateway und Dateiserver durchgehend erreichbar - ursprünglicher Dateizugriff funktioniert - andere Systeme unverändert fehlerfrei Ursache: Beschädigtes Patchkabel mit sporadischer Unterbrechung. Prävention: - Switchport-Flaps zentral überwachen - steigende physische Fehlerzähler alarmieren - Fehlerzeitpunkte im Ticket immer sekundengenau dokumentieren ``` --- **36. Checkliste „Fehler tritt nur manchmal auf“** - [ ] das genaue Symptom wurde beschrieben. - [ ] der originale Meldungstext wurde gesichert. - [ ] Fehlercode oder Event-ID wurde dokumentiert. - [ ] Beginn und Ende des Fehlers wurden erfasst. - [ ] die Zeitzone wurde dokumentiert. - [ ] Benutzer, Client und Standort sind bekannt. - [ ] Quelle, Ziel, Port und Anwendung sind bekannt. - [ ] betroffene und nicht betroffene Systeme wurden bestimmt. - [ ] Häufigkeit und bisherige Zeitpunkte wurden gesammelt. - [ ] zeitliche oder belastungsabhängige Muster wurden gesucht. - [ ] Systemzeiten der beteiligten Systeme wurden geprüft. - [ ] ein funktionierendes Vergleichssystem wurde festgelegt. - [ ] Messintervalle sind kürzer als die vermutete Fehlerdauer. - [ ] Gateway und Ziel werden kontinuierlich geprüft. - [ ] der tatsächliche Dienst wird zusätzlich zu Ping geprüft. - [ ] DNS wird bei passenden Symptomen protokolliert. - [ ] Anwendungszeiten werden bei passenden Symptomen erfasst. - [ ] Interfacezustand und Fehlerzähler werden aufgezeichnet. - [ ] Switchport oder Access Point werden berücksichtigt. - [ ] Serverressourcen werden erfasst. - [ ] relevante Ereignisprotokolle sind ausreichend lange verfügbar. - [ ] Monitoringauflösung wurde kontrolliert erhöht. - [ ] Ringpuffer besitzt eine Größen- oder Zeitbegrenzung. - [ ] Paketaufzeichnung erfolgt nur mit Berechtigung. - [ ] Verfahren zum Markieren des Fehlerzeitpunkts ist festgelegt. - [ ] Daten vor, während und nach dem Fehler wurden gesichert. - [ ] DHCP-Lease und DNS-TTL wurden berücksichtigt. - [ ] Token-, Session- und Idle-Timeouts wurden berücksichtigt. - [ ] VPN-Rekeying und Firewall-Sitzungen wurden berücksichtigt. - [ ] geplante Jobs, Backups, Scans und Updates wurden geprüft. - [ ] Temperatur und Stromversorgung wurden berücksichtigt. - [ ] Änderungen und Deployments wurden geprüft. - [ ] Daten mehrerer Systeme wurden auf einer Zeitleiste korreliert. - [ ] Korrelation und nachgewiesene Ursache wurden getrennt bewertet. - [ ] eine konkrete Hypothese wurde formuliert. - [ ] nur eine kontrollierbare Änderung wurde vorgenommen. - [ ] die Nachbeobachtung war ausreichend lang. - [ ] ursprüngliche Funktion und Vergleichssysteme wurden geprüft. - [ ] temporäre Diagnosekonfigurationen wurden entfernt. - [ ] Ursache, Maßnahme und Nachweis wurden dokumentiert. - [ ] Monitoring oder Prävention wurde festgelegt. --- **37. Schnellreferenz** | Beobachtung | wahrscheinlicher Untersuchungsbereich | |---|---| | Fehler immer zur gleichen Uhrzeit | Job, Backup, Scan, Update oder Provider | | Fehler nach fester Laufzeit | Lease, Token, Session, NAT, Firewall oder VPN | | Fehler nach Inaktivität | Idle-Timeout, Energiesparen oder Sitzung | | nur ein Client betroffen | Client, Kabel, Treiber, Port oder Benutzerprofil | | alle Clients eines Standorts betroffen | Uplink, WAN, Firewall, Strom oder Provider | | nur WLAN betroffen | Funkumgebung, Roaming, Airtime oder Access Point | | nur beim Standortwechsel | Roaming, Authentifizierung oder Funkabdeckung | | nur unter Last | CPU, RAM, Storage, Queue, Uplink oder Pool | | nur nachts | Backup, Snapshot, Wartung, Scan oder Replikation | | Linkstatus wechselt kurz | Kabel, Port, Netzwerkkarte, Strom oder Treiber | | Fehlerzähler steigen | physischer Link, Queue, Überlastung oder Hardware | | Netzwerk normal, Anwendung hängt | Anwendung, Backend, Datenbank oder Storage | | nur einzelne Ziel-IP fehlerhaft | Load Balancer, Backend oder Zielpfad | | nur nach Aufwachen | Treiber, DHCP, DNS, VPN oder Energiesparmodus | | nur über VPN | Tunnel, Rekeying, MTU, Gateway oder Route | | Fehler verschwindet nach Neustart | Ressourcen, Speicherleck, Zustand oder Dienst | | Monitoring zeigt nichts | Intervall zu groß, falscher Test oder fehlende Rohdaten | | Logs zeigen nichts | falsches Protokoll, Rotation, Zeitabweichung oder fehlende Erfassung | | Paketmitschnitt enthält Ereignis nicht | Filter, falsches Interface oder Überschreibung | | zeitlicher Zusammenhang mit Job | mögliche Korrelation, Ursache noch zu beweisen | | Problem tritt bei Temperaturanstieg auf | Kühlung, Netzteil, Transceiver oder Hardware | | regelmäßige DNS-Fehler | Resolver, TTL, Cache, Netzwerkpfad oder DNS-Server | | regelmäßige Abmeldung | Token, Sitzung, Cookie, Proxy oder Load Balancer | | kurze Ausfälle ohne Linkverlust | Dienst, Routing, Firewall, Queue oder Server | | andere Clients funktionieren | gemeinsamer Server nicht automatisch ausgeschlossen, aber Clientpfad priorisieren | --- **Merksatz** > Sporadische Fehler werden selten durch einen einzelnen nachträglichen Test gefunden. Entscheidend sind sekundengenaue Zeitstempel, kontinuierliche Messungen, begrenzte Ringpuffer, ausreichend lange Protokollaufbewahrung und eine gemeinsame Zeitleiste von Client, Netzwerk, Server und Anwendung. Erst wenn Messdaten den Fehler vor, während und nach einer kontrollierten Änderung zeigen, ist die Ursache belastbar nachgewiesen. --- **Quellen und weiterführende Dokumentation** - [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 – Windows Time Service Tools and Settings](https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings) - [Microsoft Learn – Packet Monitor](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon) - [Microsoft Learn – pktmon start](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pktmon-start) - [Microsoft Learn – pktmon etl2pcap](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pktmon-etl2pcap) - [Microsoft Learn – Windows Event Forwarding](https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/use-windows-event-forwarding-to-assist-in-intrusion-detection) - [Wireshark – Dumpcap Manual](https://www.wireshark.org/docs/man-pages/dumpcap.html) - [Wireshark User’s Guide – Capturing with Dumpcap](https://www.wireshark.org/docs/wsug_html_chunked/AppToolsdumpcap.html) - [Wireshark User’s Guide – Capturing with tcpdump](https://www.wireshark.org/docs/wsug_html_chunked/AppToolstcpdump.html) - [tcpdump Manual Page](https://man7.org/linux/man-pages/man1/tcpdump.1.html) - [systemd – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [systemd – timedatectl](https://www.freedesktop.org/software/systemd/man/latest/timedatectl.html) - [curl – Write-out Variables](https://curl.se/docs/manpage.html#-w) - [RFC 5905 – Network Time Protocol Version 4](https://www.rfc-editor.org/rfc/rfc5905) - [RFC 2131 – Dynamic Host Configuration Protocol](https://www.rfc-editor.org/rfc/rfc2131) - [RFC 9293 – Transmission Control Protocol](https://www.rfc-editor.org/rfc/rfc9293) # 6.7 Anmeldung an der Domäne geht nicht Wenn sich ein Benutzer nicht an einer Active-Directory-Domäne anmelden kann, liegt die Ursache nicht automatisch an einem falschen Kennwort. Eine Domänenanmeldung benötigt mehrere funktionierende Komponenten: 1. der Client besitzt eine gültige Netzwerkkonfiguration, 2. der Client verwendet die vorgesehenen internen DNS-Server, 3. die Active-Directory-Domäne kann über DNS gefunden werden, 4. ein geeigneter Domain Controller ist erreichbar, 5. Client und Domain Controller besitzen ausreichend übereinstimmende Systemzeiten, 6. das Benutzerkonto ist vorhanden und verwendbar, 7. das Computerkonto und der sichere Kanal zur Domäne funktionieren, 8. Kerberos oder gegebenenfalls NTLM kann die Anmeldung verarbeiten, 9. Gruppenrichtlinien und Benutzerprofile verhindern die Anmeldung nicht, 10. die Domain Controller replizieren die benötigten Informationen ordnungsgemäß. Die sichtbare Meldung am Client beschreibt häufig nur das Ergebnis. Die eigentliche Ursache kann bei DNS, Uhrzeit, Netzwerk, Benutzerkonto, Computerkonto, Domain Controller, Replikation oder Richtlinien liegen. --- **1. Typische Fehlermeldungen** Mögliche Meldungen sind: ```text Der Benutzername oder das Kennwort ist falsch. ``` ```text Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar. ``` ```text Die Sicherheitsdatenbank auf dem Server enthält kein Computerkonto für diese Arbeitsstationsvertrauensstellung. ``` ```text Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden. ``` ```text Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden. ``` ```text Das referenzierte Konto ist momentan gesperrt und kann nicht für die Anmeldung verwendet werden. ``` ```text Die Anmeldung ist aufgrund einer Kontoeinschränkung nicht möglich. ``` ```text Die Anmeldemethode, die Sie verwenden möchten, ist nicht zulässig. ``` ```text Ihr Konto wurde deaktiviert. Wenden Sie sich an den Systemadministrator. ``` ```text Das Kennwort des Benutzers muss vor der Anmeldung geändert werden. ``` ```text Wir können Sie mit diesen Anmeldeinformationen nicht anmelden, weil Ihre Domäne nicht verfügbar ist. ``` Der genaue deutsche Wortlaut kann sich je nach Windows-Version unterscheiden. Deshalb sollten zusätzlich Fehlercode, Ereignis-ID, Uhrzeit und die englische Originalmeldung dokumentiert werden, wenn sie in einem Protokoll vorhanden ist. --- **2. Auswirkungen** Mögliche Auswirkungen: - ein einzelner Benutzer kann sich nicht anmelden, - alle Benutzer eines Clients sind betroffen, - mehrere Clients eines Standorts sind betroffen, - neue Benutzer können sich nicht anmelden, - bisher angemeldete Benutzer können sich nur mit zwischengespeicherten Anmeldedaten anmelden, - Gruppenrichtlinien werden nicht verarbeitet, - Netzlaufwerke und Drucker werden nicht verbunden, - Kerberos-Authentifizierung funktioniert nicht, - Dienste mit Domänenkonten starten nicht, - ein Computer verliert seine Vertrauensstellung, - Kennwortänderungen werden nicht überall erkannt, - Anmeldungen funktionieren abhängig vom erreichten Domain Controller, - Remoteanmeldungen funktionieren, lokale Konsolenanmeldungen jedoch nicht oder umgekehrt. --- **3. Sicherheits- und Betriebswarnung** Bei der Untersuchung dürfen Benutzerkonten, Computerkonten, Domain Controller und Vertrauensstellungen nicht unkontrolliert verändert werden. Insbesondere sollten nicht vorschnell: - Benutzerkennwörter zurückgesetzt, - Konten entsperrt, ohne die Sperrquelle zu untersuchen, - Computerkonten gelöscht, - Clients aus der Domäne entfernt, - Domain Controller neu gestartet, - DNS-Einträge manuell gelöscht, - Kerberos-Tickets produktiver Sitzungen entfernt, - Gruppenrichtlinien deaktiviert, - Sicherheitsrichtlinien abgeschwächt, - Replikationen erzwungen, - Zeiteinstellungen manuell verändert, - lokale Administratorzugänge neu angelegt, - Protokolle gelöscht werden. Das Entfernen eines Computers aus der Domäne und das anschließende erneute Hinzufügen ist keine Ursachenanalyse. Dadurch können Beweise verloren gehen und zusätzliche Probleme mit Profilen, Zertifikaten, Gruppenrichtlinien, BitLocker, Softwareverteilung oder Verwaltungsdiensten entstehen. Korrekturmaßnahmen sind nur mit entsprechender Berechtigung und nach Sicherung der Diagnosedaten durchzuführen. --- **4. Zuerst den Umfang bestimmen** Die wichtigste erste Frage lautet: > Ist nur ein Benutzer, nur ein Client oder ein größerer Teil der Domäne betroffen? | Beobachtung | zuerst zu untersuchender Bereich | |---|---| | ein Benutzer kann sich an keinem Client anmelden | Benutzerkonto, Kennwort, Sperre, Ablauf, Anmelderechte | | ein Benutzer kann sich nur an einem Client nicht anmelden | Client, lokales Profil, Anmeldeformat, Richtlinie, gespeicherte Daten | | kein Domänenbenutzer kann sich an einem Client anmelden | DNS, Netzwerk, Uhrzeit, sicherer Kanal, Computerkonto | | mehrere Clients eines Standorts sind betroffen | DNS, DHCP, VLAN, Standort-Uplink, Firewall, erreichbarer Domain Controller | | alle Benutzer der Domäne sind betroffen | Domain Controller, DNS, Replikation, Zeitdienst, zentrale Infrastruktur | | Anmeldung funktioniert offline, aber nicht im Firmennetz | erreichter Domain Controller, Kontostatus, Kennwort, DNS oder sicherer Kanal | | Anmeldung funktioniert im Firmennetz, aber nicht über VPN | VPN-Verbindungszeitpunkt, DNS, Routing, Firewall, Gerätezertifikat | | alte Anmeldedaten funktionieren offline | zwischengespeicherte Domänenanmeldung | | neues Kennwort funktioniert nur an manchen Clients | Replikation, erreichter Domain Controller, gespeicherte Anmeldedaten | | lokale Anmeldung funktioniert, Domänenanmeldung nicht | Domänenpfad, Benutzerkonto, DNS, Domain Controller oder Vertrauensstellung | | Anmeldung funktioniert mit einem anderen Domänenbenutzer | Benutzerkonto oder benutzerspezifische Richtlinie priorisieren | | Anmeldung funktioniert nach Neustart gelegentlich wieder | Netzwerkstart, DNS, Dienstreihenfolge, sicherer Kanal oder erreichter DC | Ein einzelner erfolgreicher Anmeldeversuch mit einem anderen Benutzer beweist nicht, dass die gesamte Domäneninfrastruktur fehlerfrei ist. Der andere Benutzer könnte zwischengespeicherte Anmeldedaten verwenden oder einen anderen Authentifizierungspfad besitzen. --- **5. Mindestinformationen erfassen** Vor einer Änderung sollten mindestens dokumentiert werden: ```text Ticket: Datum und genaue Uhrzeit: Zeitzone: Benutzerkonto: Clientname: Client-IP: Standort: Verbindung: Ethernet / WLAN / VPN Domäne: verwendetes Anmeldeformat: genauer Meldungstext: Fehlercode: Anmeldung lokal oder remote: erstmalige oder wiederkehrende Anmeldung: anderer Benutzer am selben Client getestet: derselbe Benutzer an anderem Client getestet: lokale Anmeldung möglich: Netzwerk vor der Anmeldung verfügbar: zuletzt erfolgreiche Anmeldung: kürzlich geändertes Kennwort: zuletzt installierte Updates oder Änderungen: ``` Kennwörter dürfen nicht in das Ticket oder Diagnoseprotokoll geschrieben werden. --- **6. Lokales Konto und Domänenkonto unterscheiden** Die Eingabe auf dem Anmeldebildschirm kann unterschiedliche Kontotypen ansprechen. **Domänenkonto als UPN** ```text benutzer@ad.example.test ``` **Domänenkonto im älteren Format** ```text EXAMPLE\benutzer ``` **Lokales Konto** ```text .\benutzer ``` oder: ```text CLIENT01\benutzer ``` `.\benutzer` bezeichnet ein lokales Konto des aktuellen Computers. Es ist keine Domänenanmeldung. Eine Anmeldung kann fehlschlagen, weil: - versehentlich das lokale Konto ausgewählt wurde, - eine falsche Domäne vorangestellt wurde, - der UPN-Suffix nicht zum Benutzerkonto passt, - ein gleichnamiges lokales Konto existiert, - der zuletzt verwendete Anmeldekontext übernommen wurde, - die Tastaturbelegung auf dem Anmeldebildschirm abweicht. Vor tieferer Diagnose sollte deshalb feststehen, welches Konto Windows tatsächlich authentifizieren soll. --- **7. Gesicherte Anmeldung und zwischengespeicherte Anmeldedaten** Windows kann erfolgreiche Domänenanmeldungen zwischenspeichern. Dadurch kann sich ein Benutzer möglicherweise an einem Notebook anmelden, obwohl momentan kein Domain Controller erreichbar ist. Das bedeutet: ```text Anmeldung erfolgreich ≠ Domain Controller war erreichbar ``` Bei einer zwischengespeicherten Anmeldung können anschließend trotzdem ausfallen: - Gruppenrichtlinien, - Netzlaufwerke, - Domänendrucker, - Kerberos-Tickets, - Zugriff auf interne Anwendungen, - Kennwortänderungen, - Anmeldung mit einem erstmals verwendeten Konto. Typische Hinweise auf eine zwischengespeicherte Anmeldung: - Anmeldung funktioniert ohne Netzwerk, - ein bereits bekannter Benutzer kann sich anmelden, - ein neuer Benutzer kann sich am selben Gerät nicht anmelden, - das neue Kennwort funktioniert nicht, das vorherige jedoch schon, - Domänenressourcen sind nach der Anmeldung nicht erreichbar, - Gruppenrichtlinien werden nicht aktualisiert. Die Anzahl zwischengespeicherter Anmeldungen wird durch Sicherheitsrichtlinien bestimmt. Diese Einstellung sollte nicht allein zur Fehlerbehebung verändert werden. --- **8. Netzwerkstatus vor der Anmeldung berücksichtigen** Eine Domänenanmeldung kann erfolgen, bevor WLAN, VPN oder 802.1X vollständig verfügbar ist. Zu prüfen sind: - ist das Netzwerkkabel angeschlossen, - ist der Switchport aktiv, - ist WLAN bereits am Anmeldebildschirm verbunden, - benötigt das WLAN zuerst eine Benutzeranmeldung, - verwendet der Client Maschinen- oder Benutzerzertifikate, - ist ein Pre-Logon-VPN erforderlich, - startet das VPN erst nach der Windows-Anmeldung, - erhält der Client rechtzeitig eine DHCP-Adresse, - wird ein falsches VLAN zugewiesen, - blockiert Network Access Control den Client, - benötigt der Netzwerkadapter nach dem Start ungewöhnlich lange, - wird durch Fast Startup ein fehlerhafter Netzwerkzustand übernommen. Nach der Anmeldung kann der aktuelle Zustand geprüft werden: ```powershell Get-NetAdapter ``` ```powershell Get-NetIPConfiguration ``` ```cmd ipconfig /all ``` Wichtige Angaben: - IPv4-Adresse, - IPv6-Adresse, - Subnetzmaske oder Präfix, - Standardgateway, - DHCP-Server, - DNS-Server, - DNS-Suffix, - Lease-Zeitpunkt, - Adapterstatus, - Name der Verbindung. Eine Adresse aus `169.254.0.0/16` weist bei IPv4 typischerweise darauf hin, dass keine reguläre DHCP-Konfiguration bezogen wurde. Sie beweist jedoch noch nicht, ob DHCP-Server, Relay, VLAN, Port oder Client die Ursache ist. --- **9. Erreichbarkeit schrittweise prüfen** Nach einer lokalen oder zwischengespeicherten Anmeldung kann der Netzwerkpfad untersucht werden. **Eigene Netzwerkkonfiguration** ```cmd ipconfig /all ``` **Standardgateway** ```powershell Test-Connection -TargetName -Count 4 ``` **Interner DNS-Server** ```powershell Test-Connection -TargetName -Count 4 ``` **Domain Controller** ```powershell Test-Connection -TargetName -Count 4 ``` **Relevante TCP-Verbindungen** ```powershell Test-NetConnection -ComputerName -Port 53 Test-NetConnection -ComputerName -Port 88 Test-NetConnection -ComputerName -Port 389 Test-NetConnection -ComputerName -Port 445 ``` Ein erfolgreicher Ping beweist nicht, dass DNS, Kerberos, LDAP, SMB, RPC oder die Anmeldung funktioniert. Umgekehrt kann Ping durch eine Firewall blockiert sein, obwohl die benötigten Dienste erreichbar sind. Active Directory verwendet mehrere Protokolle und dynamische RPC-Ports. Vier erfolgreiche Porttests ersetzen deshalb keine vollständige Prüfung des Domänenpfades. --- **10. DNS-Konfiguration des Clients prüfen** Active Directory ist in hohem Maß von DNS abhängig. Ein Domänenclient muss die DNS-Server verwenden, welche die Active-Directory-DNS-Zone und die zugehörigen Dienstressourceneinträge auflösen können. Prüfen: ```powershell Get-DnsClientServerAddress ``` ```powershell Get-DnsClientGlobalSetting ``` ```powershell Get-DnsClient ``` Alternativ: ```cmd ipconfig /all ``` Verdächtig sind insbesondere: - ausschließlich ein öffentlicher DNS-Server, - DNS-Server des Internetrouters statt des vorgesehenen AD-DNS, - falsche DNS-Server durch statische Konfiguration, - falsche DNS-Server durch VPN oder DHCP, - unerwarteter DNS-Suffix, - veraltete DNS-Adressen, - nicht erreichbarer bevorzugter DNS-Server, - Split-DNS mit fehlenden internen Einträgen, - unterschiedliche Antworten verschiedener DNS-Server. Öffentliche Resolver können Internetnamen auflösen, kennen aber normalerweise nicht die internen SRV-Einträge der Active-Directory-Domäne. Eine funktionierende Auflösung von `www.example.com` beweist daher nicht, dass Active Directory über DNS gefunden werden kann. --- **11. DNS-Auflösung der Domäne prüfen** **Domänenname auflösen** ```powershell Resolve-DnsName -Name ``` **Domain-Controller-Dienst suchen** ```powershell Resolve-DnsName ` -Name "_ldap._tcp.dc._msdcs." ` -Type SRV ``` **Kerberos-Dienst suchen** ```powershell Resolve-DnsName ` -Name "_kerberos._tcp." ` -Type SRV ``` **Global Catalog suchen** ```powershell Resolve-DnsName ` -Name "_ldap._tcp.gc._msdcs." ` -Type SRV ``` Mit `nslookup`: ```cmd nslookup -type=SRV _ldap._tcp.dc._msdcs. ``` ```cmd nslookup -type=SRV _kerberos._tcp. ``` Erwartet werden SRV-Antworten mit geeigneten Domain Controllern. Anschließend müssen auch deren Hostnamen auflösbar sein: ```powershell Resolve-DnsName -Name ``` Eine vorhandene SRV-Antwort reicht nicht aus, wenn: - der zurückgegebene Domain Controller nicht erreichbar ist, - sein Hostname auf eine falsche IP-Adresse zeigt, - ein veralteter Domain Controller eingetragen ist, - Firewall oder Routing die benötigten Dienste blockieren, - der Client einem falschen AD-Standort zugeordnet wird. --- **12. DNS-Cache kontrolliert untersuchen** Cache anzeigen: ```cmd ipconfig /displaydns ``` PowerShell: ```powershell Get-DnsClientCache ``` Der Cache kann Hinweise auf bereits verwendete Einträge liefern. Erst nach Sicherung der relevanten Informationen kann für einen kontrollierten Vergleich der Clientcache geleert werden: ```cmd ipconfig /flushdns ``` Das Leeren des DNS-Caches ist eine Zustandsänderung. Wenn der Fehler nur sporadisch auftritt, kann dadurch ein wichtiger Hinweis auf einen falschen oder veralteten Eintrag verloren gehen. Eine erfolgreiche Anmeldung nach dem Leeren beweist noch nicht, welcher DNS-Eintrag fehlerhaft war. Dafür müssen Antworten vor und nach der Änderung verglichen werden. --- **13. Domain Controller Locator prüfen** Windows verwendet den Domain Controller Locator, um einen geeigneten Domain Controller zu finden. **Domain Controller suchen** ```cmd nltest /dsgetdc: ``` **Erzwungene erneute Suche** ```cmd nltest /dsgetdc: /force ``` **Domain Controller eines AD-Standorts suchen** ```cmd nltest /dsgetdc: /site: ``` **Clientstandort anzeigen** ```cmd nltest /dsgetsite ``` **Liste der Domain Controller** ```cmd nltest /dclist: ``` Die Ausgabe von `nltest /dsgetdc` kann unter anderem zeigen: - gefundenen Domain Controller, - Adresse, - Domänen-GUID, - AD-Standort, - Eigenschaften wie LDAP, KDC, DNS oder Global Catalog. Fehler wie: ```text ERROR_NO_SUCH_DOMAIN ``` oder: ```text DsGetDcName failed: Status = 1355 ``` weisen darauf hin, dass kein geeigneter Domain Controller gefunden wurde. Die Ursache kann unter anderem bei DNS, Netzwerk, Firewall, AD-Standort, Dienstregistrierung oder Domain Controller liegen. --- **14. Verwendeten Anmeldeserver feststellen** Nach einer erfolgreichen Domänenanmeldung: ```cmd echo %LOGONSERVER% ``` PowerShell: ```powershell $env:LOGONSERVER ``` Zusätzlich: ```cmd whoami ``` ```cmd whoami /user ``` ```cmd whoami /groups ``` Der Wert von `LOGONSERVER` ist hilfreich, darf aber nicht als vollständiger Nachweis für jeden späteren Authentifizierungsvorgang betrachtet werden. Unterschiedliche Dienste können andere Domain Controller oder Kerberos-Dienstpfade verwenden. Wenn die Anmeldung nur bei einem bestimmten Domain Controller fehlschlägt, sind besonders zu prüfen: - Replikation, - DNS-Registrierung, - Erreichbarkeit, - Uhrzeit, - SYSVOL und NETLOGON, - Kerberos, - Kontostand auf diesem DC, - AD-Standortzuordnung. --- **15. Systemzeit und Zeitzone prüfen** Kerberos ist auf ausreichend übereinstimmende Zeit angewiesen. Eine zu große Zeitabweichung kann die Authentifizierung verhindern. **Clientstatus** ```cmd w32tm /query /status ``` **Konfiguration** ```cmd w32tm /query /configuration ``` **Zeitquelle** ```cmd w32tm /query /source ``` **Vergleich mit einem Domain Controller** ```cmd w32tm /stripchart /computer: /dataonly /samples:10 ``` **Windows-Time-Service** ```powershell Get-Service -Name W32Time ``` Zusätzlich dokumentieren: ```powershell Get-Date ``` ```powershell Get-TimeZone ``` Zu prüfen sind: - Datum, - Uhrzeit, - Zeitzone, - Zeitquelle, - letzte erfolgreiche Synchronisierung, - Erreichbarkeit der Zeitquelle, - Zeithierarchie der Domäne, - Zustand des Windows-Zeitdienstes, - Zeit des Hypervisors bei virtuellen Maschinen. Die Uhr darf während der Diagnose nicht unkontrolliert manuell verändert werden. Vor einer Korrektur sollten Status und Abweichung dokumentiert werden. --- **16. Benutzerkonto prüfen** Mit installiertem Active-Directory-PowerShell-Modul und ausreichender Berechtigung: ```powershell Get-ADUser -Identity ` -Properties Enabled, LockedOut, PasswordExpired, PasswordLastSet, AccountExpirationDate, UserPrincipalName, SamAccountName, LastLogonDate, LogonWorkstations ``` Gezielt formatieren: ```powershell Get-ADUser -Identity ` -Properties Enabled, LockedOut, PasswordExpired, PasswordLastSet, AccountExpirationDate, UserPrincipalName, LogonWorkstations | Select-Object SamAccountName, UserPrincipalName, Enabled, LockedOut, PasswordExpired, PasswordLastSet, AccountExpirationDate, LogonWorkstations ``` Zu prüfen sind: - Konto vorhanden, - Konto aktiviert, - Konto gesperrt, - Konto abgelaufen, - Kennwort abgelaufen, - Kennwortänderung erforderlich, - korrekter Benutzerprinzipalname, - korrekter Anmeldename, - erlaubte Arbeitsstationen, - erlaubte Anmeldezeiten, - Smartcard- oder Zertifikatsanforderungen, - Mitgliedschaften in relevanten Gruppen, - wirksame Richtlinien und Anmelderechte. `LastLogonDate` ist nicht für jede sekundengenaue Untersuchung geeignet. Je nach benötigter Genauigkeit müssen die entsprechenden Attribute und Ereignisprotokolle auf den relevanten Domain Controllern ausgewertet werden. --- **17. Kontosperre untersuchen** Ein Konto kann durch wiederholte fehlerhafte Anmeldeversuche gesperrt werden. Mögliche Quellen: - Benutzer gibt mehrfach ein falsches Kennwort ein, - Smartphone verwendet ein altes Kennwort, - gespeicherte Anmeldeinformationen, - getrennte RDP-Sitzung, - Windows-Dienst mit Benutzerkonto, - geplante Aufgabe, - Netzlaufwerk, - Drucker, - VPN-Client, - WLAN-Authentifizierung, - Outlook oder andere Anwendung, - Skript, - Anwendungspool, - zweiter Computer, - Gerät außerhalb des Firmennetzes, - Angriffsversuch. Kontostatus: ```powershell Get-ADUser -Identity -Properties LockedOut | Select-Object SamAccountName, LockedOut ``` Sperrereignisse auf einem Domain Controller: ```powershell Get-WinEvent -FilterHashtable @{ LogName = "Security" Id = 4740 } | Select-Object TimeCreated, Id, Message ``` Ereignis-ID `4740` zeigt eine Kontosperre. Das Ereignis kann Informationen über den aufrufenden Computer enthalten. Nur das Entsperren des Kontos behebt eine wiederkehrende Sperrquelle nicht. Vor dem Entsperren sollten Zeitpunkt, Domain Controller, aufrufender Computer und vorausgehende Authentifizierungsfehler dokumentiert werden. --- **18. Kennwortänderung und Replikation berücksichtigen** Nach einer Kennwortänderung können Probleme entstehen, wenn: - ein Client noch das alte Kennwort verwendet, - gespeicherte Anmeldedaten nicht aktualisiert wurden, - ein Gerät dauerhaft alte Zugangsdaten sendet, - Domain Controller nicht ordnungsgemäß replizieren, - ein Standort nur einen fehlerhaften Domain Controller erreicht, - ein Dienstkontokennwort geändert wurde, die Dienstkonfiguration jedoch nicht, - das Benutzerkonto gesperrt wurde, - der Benutzer offline arbeitet und zwischengespeicherte Anmeldedaten verwendet. Zu erfassen: ```text Zeitpunkt der Kennwortänderung: System, an dem das Kennwort geändert wurde: vermutlich beteiligter Domain Controller: erstes Auftreten des Fehlers: funktioniert altes Kennwort offline: funktioniert neues Kennwort online: funktioniert Anmeldung an anderem Client: funktioniert Anmeldung an anderem Standort: ``` Kennwörter dürfen nicht testweise an mehreren Stellen verteilt oder protokolliert werden. --- **19. Computerkonto prüfen** Ein Domänencomputer besitzt in Active Directory ein eigenes Computerkonto. Mit dem Active-Directory-PowerShell-Modul: ```powershell Get-ADComputer -Identity ` -Properties Enabled, PasswordLastSet, LastLogonDate, DistinguishedName, DNSHostName ``` Formatierte Ausgabe: ```powershell Get-ADComputer -Identity ` -Properties Enabled, PasswordLastSet, LastLogonDate, DistinguishedName, DNSHostName | Select-Object Name, DNSHostName, Enabled, PasswordLastSet, LastLogonDate, DistinguishedName ``` Zu prüfen sind: - Computerkonto vorhanden, - Computerkonto aktiviert, - korrekter Name, - keine unerwarteten doppelten oder alten Objekte, - erwartete Organisationseinheit, - plausibler Zeitpunkt des Maschinenkennworts, - Client wurde nicht aus einem alten Snapshot wiederhergestellt, - Client wurde nicht geklont, ohne korrekt vorbereitet zu werden, - Computerkonto wurde nicht gelöscht und neu erstellt, - Clientname wurde nicht unsachgemäß geändert. `PasswordLastSet` allein beweist nicht, dass der sichere Kanal funktioniert. Es ist nur ein Hinweis innerhalb der Gesamtanalyse. --- **20. Sicheren Kanal prüfen** Der sichere Kanal verbindet einen Domänenmitgliedscomputer mit der Domäne. **PowerShell auf einem Mitgliedscomputer** ```powershell Test-ComputerSecureChannel -Verbose ``` Mit ausdrücklich angegebener Domäne: ```powershell Test-ComputerSecureChannel ` -Server ` -Verbose ``` **NLTEST** ```cmd nltest /sc_query: ``` Zusätzliche Informationen: ```cmd nltest /sc_verify: ``` Je nach Systemrolle und verwendetem Werkzeug unterscheiden sich Bedeutung und Verhalten einzelner Prüfungen. `Test-ComputerSecureChannel` ist für Domänenmitgliedscomputer vorgesehen und sollte nicht als allgemeiner Zustandstest eines Domain Controllers verwendet werden. Ein fehlerhafter sicherer Kanal kann Meldungen verursachen wie: ```text Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden. ``` Mögliche Ursachen: - Maschinenkennwort stimmt zwischen Client und AD nicht überein, - Client wurde auf einen alten Snapshot zurückgesetzt, - Computerkonto wurde gelöscht oder neu angelegt, - replizierte Kontodaten sind inkonsistent, - Client wurde fehlerhaft geklont, - lange getrenntes oder zurückgesetztes System, - Wiederherstellung aus einem ungeeigneten Image, - DNS oder Netzwerk verhindert die Kontaktaufnahme. --- **21. Sicheren Kanal nur kontrolliert reparieren** Die folgenden Befehle verändern den Zustand und gehören nicht zur rein lesenden Diagnose. **PowerShell** ```powershell Test-ComputerSecureChannel ` -Repair ` -Credential (Get-Credential) ` -Verbose ``` Alternative: ```powershell Reset-ComputerMachinePassword ` -Server ` -Credential (Get-Credential) ``` Eine Reparatur sollte nur erfolgen, wenn: 1. DNS und Netzwerk geprüft wurden, 2. die Uhrzeit korrekt ist, 3. das richtige Computerkonto identifiziert wurde, 4. der Fehler des sicheren Kanals bestätigt wurde, 5. erforderliche Berechtigungen vorhanden sind, 6. Auswirkungen und Rückfallmöglichkeit bekannt sind, 7. Diagnoseinformationen vorher gesichert wurden. Nach der Reparatur müssen mindestens geprüft werden: - sicherer Kanal, - Neustartanforderung, - Domänenanmeldung, - Gruppenrichtlinien, - Kerberos-Tickets, - Zugriff auf Domänenressourcen, - Verwaltungs- und Sicherheitssoftware, - Ereignisprotokolle. Das Entfernen und erneute Hinzufügen zur Domäne sollte erst nach nachvollziehbarer Diagnose und gemäß dem betrieblichen Verfahren erfolgen. --- **22. Kerberos-Tickets prüfen** Aktuelle Tickets des angemeldeten Sicherheitskontexts: ```cmd klist ``` Kerberos-Ticket-Granting-Tickets anzeigen: ```cmd klist tgt ``` Weitere Sitzungsinformationen: ```cmd klist sessions ``` Verfügbarer Domain Controller: ```cmd klist query_bind ``` Je nach Windows-Version und Sicherheitskontext können die verfügbaren Unterbefehle und sichtbaren Tickets variieren. Die lokale Hilfe ist zu prüfen: ```cmd klist ? ``` Zu untersuchen sind: - ist ein TGT vorhanden, - welcher KDC wurde verwendet, - stimmen Client- und Domänenname, - sind Tickets abgelaufen, - treten Kerberos-Fehler in den Ereignisprotokollen auf, - funktioniert DNS für den KDC, - stimmt die Uhrzeit, - ist der verwendete Dienstprinzipalname korrekt, - wird unerwartet NTLM statt Kerberos verwendet. Tickets kontrolliert entfernen: ```cmd klist purge ``` `klist purge` verändert den Anmeldezustand der aktuellen Sitzung. Vorher sollten die vorhandenen Tickets dokumentiert werden. Eine erfolgreiche Funktion nach dem Purge beweist ohne Vergleich der vorherigen Tickets nicht automatisch die Ursache. --- **23. NTLM und Kerberos unterscheiden** Eine Windows-Domäne kann je nach Vorgang Kerberos oder NTLM verwenden. Vereinfacht: | Bereich | typischer Hinweis | |---|---| | Kerberos-Vorauthentifizierung fehlgeschlagen | Ereignis 4771 | | Kerberos-TGT angefordert | Ereignis 4768 | | Kerberos-Dienstticket angefordert | Ereignis 4769 | | NTLM-Anmeldeinformationen geprüft | Ereignis 4776 | | Anmeldung auf Zielsystem fehlgeschlagen | Ereignis 4625 | | Konto gesperrt | Ereignis 4740 | Ein Ereignis muss immer zusammen mit Zeitpunkt, Benutzer, Clientadresse, Anmeldetyp, Statuscode, Substatus und beteiligtem System bewertet werden. --- **24. Ereignis 4625 auswerten** Ereignis-ID `4625` bedeutet, dass eine Kontoanmeldung fehlgeschlagen ist. Es entsteht auf dem System, auf dem der Anmeldeversuch verarbeitet wurde. Zeitlich begrenzte Abfrage: ```powershell $Start = Get-Date "2026-08-02 09:10:00" $End = Get-Date "2026-08-02 09:20:00" Get-WinEvent -FilterHashtable @{ LogName = "Security" Id = 4625 StartTime = $Start EndTime = $End } | Select-Object TimeCreated, Id, Message ``` Wichtige Felder können sein: - Kontoname, - Kontodomäne, - Anmelde-ID, - Anmeldetyp, - Fehlergrund, - Status, - Substatus, - Arbeitsstationsname, - Quellnetzwerkadresse, - Quellport, - Authentifizierungspaket, - beteiligter Prozess. Häufige Anmeldetypen: | Anmeldetyp | Bedeutung | |---:|---| | 2 | interaktive Anmeldung an der Konsole | | 3 | Netzwerkanmeldung | | 4 | Batch, beispielsweise geplante Aufgabe | | 5 | Dienst | | 7 | Entsperren | | 8 | NetworkCleartext | | 9 | NewCredentials | | 10 | RemoteInteractive, beispielsweise RDP | | 11 | CachedInteractive | Anmeldetyp `11` weist auf eine interaktive Anmeldung mit zwischengespeicherten Domäneninformationen hin. Er bedeutet nicht, dass während der Anmeldung ein Domain Controller erreicht wurde. Status- und Substatuswerte müssen anhand der Microsoft-Dokumentation und des konkreten Ereignisses interpretiert werden. --- **25. Relevante Authentifizierungsereignisse** Auf Client, Mitgliedsserver und Domain Controllern können unter anderem relevant sein: | Ereignis-ID | allgemeine Bedeutung | |---:|---| | 4624 | erfolgreiche Anmeldung | | 4625 | fehlgeschlagene Anmeldung | | 4648 | Anmeldung mit ausdrücklich angegebenen Anmeldeinformationen | | 4672 | besondere Rechte wurden einer neuen Anmeldung zugewiesen | | 4722 | Benutzerkonto aktiviert | | 4725 | Benutzerkonto deaktiviert | | 4726 | Benutzerkonto gelöscht | | 4738 | Benutzerkonto geändert | | 4740 | Benutzerkonto gesperrt | | 4767 | Benutzerkonto entsperrt | | 4768 | Kerberos-TGT angefordert | | 4769 | Kerberos-Dienstticket angefordert | | 4770 | Kerberos-Dienstticket erneuert | | 4771 | Kerberos-Vorauthentifizierung fehlgeschlagen | | 4776 | Anmeldeinformationen wurden über NTLM geprüft | | 5719 | kein Domain Controller für eine sichere Sitzung verfügbar | | 5722 | Authentifizierung der Sitzung beziehungsweise des Computerkontos fehlgeschlagen | | 5805 | Sitzung eines Computers konnte nicht authentifiziert werden | Nicht jedes Ereignis ist standardmäßig aktiviert oder auf jedem System vorhanden. Ereignisse können auf unterschiedlichen beteiligten Computern entstehen. --- **26. Mehrere Ereignisse zeitlich abfragen** ```powershell $Start = Get-Date "2026-08-02 09:10:00" $End = Get-Date "2026-08-02 09:20:00" $Ids = 4624, 4625, 4648, 4740, 4768, 4769, 4771, 4776 Get-WinEvent -FilterHashtable @{ LogName = "Security" Id = $Ids StartTime = $Start EndTime = $End } | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message | Sort-Object TimeCreated ``` Systemereignisse: ```powershell Get-WinEvent -FilterHashtable @{ LogName = "System" Id = 5719, 5722, 5805 StartTime = $Start EndTime = $End } | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message | Sort-Object TimeCreated ``` Für große Protokolle sollte bereits serverseitig mit `FilterHashtable` nach Zeitraum und Ereignis-ID gefiltert werden. --- **27. Ereignisprotokolle auf dem Client prüfen** Relevante Protokolle können sein: ```text Windows-Protokolle → System Windows-Protokolle → Sicherheit Windows-Protokolle → Anwendung Anwendungs- und Dienstprotokolle → Microsoft → Windows → GroupPolicy → Operational Anwendungs- und Dienstprotokolle → Microsoft → Windows → User Profile Service → Operational Anwendungs- und Dienstprotokolle → Microsoft → Windows → DNS Client Events Anwendungs- und Dienstprotokolle → Microsoft → Windows → WLAN-AutoConfig → Operational ``` Vorhandene Protokolle auflisten: ```powershell Get-WinEvent -ListLog * | Where-Object { $_.LogName -match "GroupPolicy|User Profile|DNS|WLAN|Kerberos|Netlogon" } | Select-Object LogName, IsEnabled, RecordCount ``` Nicht jedes Protokoll ist auf jedem System aktiviert. Zusätzliche Protokollierung darf nur kontrolliert unter Berücksichtigung von Speicherbedarf, Datenschutz und Betriebsrichtlinien aktiviert werden. --- **28. Netlogon-Diagnose berücksichtigen** Der Netlogon-Dienst ist unter anderem an Domain-Controller-Ermittlung und sicherem Kanal beteiligt. Dienststatus: ```powershell Get-Service -Name Netlogon ``` Ausführliche Dienstinformationen: ```cmd sc.exe query netlogon ``` Netlogon kann ein Diagnoseprotokoll unter folgendem Pfad verwenden: ```text %windir%\debug\netlogon.log ``` Erweiterte Netlogon-Protokollierung verändert den Diagnosezustand und kann umfangreiche oder sensible Informationen erzeugen. Sie sollte nur gezielt, zeitlich begrenzt und entsprechend der offiziellen Microsoft-Anleitung aktiviert werden. Nach Abschluss muss eine zusätzlich aktivierte Diagnoseprotokollierung wieder auf den vorgesehenen Zustand zurückgesetzt werden. --- **29. Gruppenrichtlinien prüfen** Eine Anmeldung kann technisch erfolgreich sein, während Gruppenrichtlinien, Skripte oder Ressourcenverbindungen fehlschlagen. Aktuelle Richtlinien aktualisieren: ```cmd gpupdate /force ``` Dieser Befehl ist eine aktive Zustandsänderung und sollte erst nach Sicherung der relevanten Ereignisse verwendet werden. Resultierende Richtlinien anzeigen: ```cmd gpresult /r ``` Ausführlicher HTML-Bericht: ```cmd gpresult /h C:\Temp\gpresult.html ``` Relevante Fragen: - erreicht der Client SYSVOL und NETLOGON, - werden Benutzer- und Computerrichtlinien angewendet, - blockiert ein Anmelderecht die interaktive Anmeldung, - ist „Lokal anmelden zulassen“ passend konfiguriert, - greift „Lokal anmelden verweigern“, - greift „Anmelden über Remotedesktopdienste zulassen“, - verhindert eine Software Restriction Policy oder AppLocker einen Bestandteil, - hängt ein Anmelde- oder Startskript, - ist ein Netzlaufwerk oder Druckerziel nicht erreichbar, - wartet die Anmeldung auf das Netzwerk, - wurden Richtlinien kürzlich geändert. Ein lang laufendes Anmeldeskript kann wie eine fehlgeschlagene Anmeldung erscheinen, obwohl die Authentifizierung bereits abgeschlossen wurde. --- **30. SYSVOL und NETLOGON prüfen** Freigaben eines Domain Controllers anzeigen: ```cmd net view \\ ``` SYSVOL testen: ```cmd dir \\\SYSVOL ``` NETLOGON testen: ```cmd dir \\\NETLOGON ``` Wenn diese Pfade nicht erreichbar sind, sind unter anderem zu prüfen: - DNS-Auflösung, - SMB-Erreichbarkeit, - Firewall, - Domain-Controller-Dienstzustand, - SYSVOL-Bereitstellung, - DFS-Replikation, - Netzwerkpfad, - Berechtigungen, - sicherer Kanal. Ein erfolgreicher Verzeichniszugriff beweist nicht, dass alle Gruppenrichtlinien oder die AD-Replikation fehlerfrei sind. --- **31. Benutzerprofilfehler von Authentifizierungsfehlern trennen** Der Benutzer kann erfolgreich authentifiziert worden sein, obwohl Windows das Profil nicht laden kann. Typische Hinweise: ```text Die Anmeldung des Dienstes "Benutzerprofildienst" ist fehlgeschlagen. ``` ```text Das Benutzerprofil kann nicht geladen werden. ``` ```text Sie wurden mit einem temporären Profil angemeldet. ``` Dann sind besonders zu prüfen: - Ereignisse des User Profile Service, - freier Speicherplatz, - Erreichbarkeit eines servergespeicherten Profils, - Berechtigungen, - beschädigtes lokales Profil, - Profilcontainer, - FSLogix bei entsprechender Umgebung, - Antiviren- oder Sicherheitssoftware, - Datenträgerfehler, - Registry-Profilzuordnung, - gleichzeitige Sitzung oder gesperrte Profildatei. Ein Profilproblem darf nicht automatisch als fehlerhaftes Benutzerkonto oder fehlerhafte Domänenauthentifizierung behandelt werden. --- **32. RDP-Anmeldung gesondert untersuchen** Wenn nur die Remotedesktopanmeldung fehlschlägt, zusätzlich prüfen: - RDP-Dienst erreichbar, - TCP-Port erreichbar, - Network Level Authentication, - Benutzer besitzt RDP-Anmelderecht, - Benutzer ist nicht durch eine Richtlinie ausgeschlossen, - Zielsystem kann den Domain Controller erreichen, - Zielsystemzeit stimmt, - Zertifikat oder TLS-Verbindung funktioniert, - CredSSP- oder Sicherheitsrichtlinien sind kompatibel, - keine bereits bestehende oder beschränkte Sitzung, - Anmeldetyp `10` in Ereignis 4625, - Quelladresse und Zielsystem im Ereignis. Porttest: ```powershell Test-NetConnection -ComputerName -Port 3389 ``` Ein erfolgreicher Porttest beweist nur, dass eine TCP-Verbindung hergestellt werden konnte. Er beweist nicht, dass NLA, Authentifizierung, Anmelderechte oder Profilladen funktionieren. --- **33. Anmeldung über VPN untersuchen** Bei entfernten Clients ist entscheidend, wann das VPN verfügbar wird. Mögliche Fälle: 1. Benutzer meldet sich mit zwischengespeicherten Daten an und startet danach das VPN. 2. Ein gerätebasiertes VPN ist bereits vor der Anmeldung aktiv. 3. Ein Pre-Logon-VPN wird am Anmeldebildschirm gestartet. 4. Das VPN benötigt Benutzeranmeldedaten, die erst nach der Windows-Anmeldung verfügbar sind. 5. Das VPN verteilt falsche DNS-Server oder Routen. 6. Der VPN-Tunnel erreicht nicht alle benötigten Domain Controller. 7. MTU-, Firewall- oder Fragmentierungsprobleme stören einzelne Protokolle. 8. Gerätezertifikat oder Maschinenkonto ist fehlerhaft. Nach Aufbau des VPN prüfen: ```cmd ipconfig /all ``` ```powershell Get-DnsClientServerAddress ``` ```powershell Get-NetRoute ``` ```cmd nltest /dsgetdc: ``` ```cmd w32tm /query /status ``` Die erfolgreiche Anmeldung am Notebook vor dem VPN beweist nur, dass zwischengespeicherte Anmeldedaten verwendbar waren. --- **34. Domain Controller diagnostizieren** Auf einem Domain Controller und mit entsprechender Berechtigung: ```cmd dcdiag ``` Ausführliche Ausgabe in eine Datei: ```cmd dcdiag /v > C:\Temp\dcdiag.txt ``` DNS-Prüfung: ```cmd dcdiag /test:dns /v ``` Bestimmten Domain Controller testen: ```cmd dcdiag /s: /v ``` Unternehmensweite Prüfung: ```cmd dcdiag /e /v ``` Die unternehmensweite Prüfung kann umfangreich sein und sollte kontrolliert eingesetzt werden. Zu untersuchen sind unter anderem: - DNS, - Erreichbarkeit, - Netlogon, - Advertising, - Dienste, - Replikation, - SYSVOL, - Rollen und Verzeichniszustand. Nicht jede Warnung in `dcdiag` erklärt automatisch die konkrete Anmeldestörung. Der Zeitpunkt und der betroffene Authentifizierungspfad müssen weiterhin korreliert werden. --- **35. Active-Directory-Replikation prüfen** Zusammenfassung: ```cmd repadmin /replsummary ``` Eingehende Replikationspartner: ```cmd repadmin /showrepl ``` Alle Domain Controller detailliert: ```cmd repadmin /showrepl * /csv ``` Replikationswarteschlange: ```cmd repadmin /queue ``` Zu prüfen sind: - fehlgeschlagene Replikationen, - Zeitpunkt der letzten erfolgreichen Replikation, - Fehlercode, - betroffene Partition, - nur ein Standort oder ein Domain Controller betroffen, - DNS- oder RPC-Fehler, - Zeitabweichung, - Authentifizierungsfehler, - Netzwerkunterbrechung. Eine erzwungene Replikation ist eine aktive Änderung und sollte nicht als erster Diagnoseschritt verwendet werden. Wenn ein Benutzer sein Kennwort geändert hat und die Anmeldung abhängig vom erreichten Domain Controller funktioniert, ist eine Replikationsstörung eine mögliche Hypothese. Sie muss durch Replikationsdaten und den tatsächlich verwendeten Domain Controller bestätigt werden. --- **36. AD-Standorte und Subnetze berücksichtigen** Der Domain Controller Locator berücksichtigt Active-Directory-Standorte. Clientstandort: ```cmd nltest /dsgetsite ``` Gefundener Domain Controller: ```cmd nltest /dsgetdc: ``` Mögliche Fehler: - Clientsubnetz fehlt in Active Directory Sites and Services, - Subnetz ist dem falschen Standort zugeordnet, - lokaler Domain Controller ist nicht erreichbar, - Client verwendet einen entfernten Domain Controller, - DNS liefert veraltete oder ungeeignete Einträge, - Standort-Uplink blockiert benötigte Protokolle, - Anmeldung wird durch hohe Latenz oder Paketverlust verzögert, - nur der Domain Controller eines Standorts besitzt veraltete Daten. Ein entfernter Domain Controller ist nicht automatisch fehlerhaft. Die Standortzuordnung ist jedoch wichtig für Performance, Verfügbarkeit und Fehlereingrenzung. --- **37. Firewall und benötigte Dienste berücksichtigen** Active Directory verwendet mehrere Dienste, beispielsweise: - DNS, - Kerberos, - LDAP, - LDAPS bei entsprechender Konfiguration, - SMB, - RPC Endpoint Mapper, - dynamische RPC-Ports, - Global Catalog, - Kerberos-Kennwortänderung, - Zeitdienst. Einzelne typische Ports: | Dienst | Protokoll/Port | |---|---| | DNS | TCP/UDP 53 | | Kerberos | TCP/UDP 88 | | RPC Endpoint Mapper | TCP 135 | | NetBIOS Name Service | UDP 137 | | NetBIOS Datagram | UDP 138 | | NetBIOS Session | TCP 139 | | LDAP | TCP/UDP 389 | | SMB | TCP 445 | | Kerberos-Kennwortänderung | TCP/UDP 464 | | LDAPS | TCP 636 | | Global Catalog | TCP 3268 | | Global Catalog über TLS | TCP 3269 | | Windows-Zeitdienst | UDP 123 | | dynamisches RPC | versionsabhängiger TCP-Portbereich | Diese Tabelle ist keine vollständige Firewallfreigabe. Die tatsächlich benötigten Verbindungen hängen von Windows-Version, Topologie, Richtung und Funktion ab. Firewalls dürfen nicht pauschal deaktiviert werden. Stattdessen sind verworfene Verbindungen, Quell- und Zieladressen, Ports, Richtung und Zeitpunkt zu untersuchen. --- **38. Paketmitschnitt nur gezielt einsetzen** Wenn DNS, DC Locator, Kerberos oder LDAP weiterhin unklar bleiben, kann ein autorisierter Paketmitschnitt helfen. Mögliche Protokolle: ```text dns kerberos ldap tcp.port == 445 tcp.port == 135 ``` Möglicher Wireshark-Anzeigefilter: ```text dns || kerberos || ldap || tcp.port == 445 || tcp.port == 135 ``` Zu beobachten sind: - DNS-SRV-Abfragen, - zurückgegebene Domain Controller, - fehlgeschlagene Namensauflösung, - Kerberos-AS-REQ und AS-REP, - Kerberos-Fehler, - LDAP-Verbindungsaufbau, - TCP-Retransmissions, - Verbindungszurücksetzungen, - ICMP-Fehler, - stark verzögerte Antworten, - angesprochener Domain Controller, - wechselnde Domain Controller. Paketmitschnitte können Kontonamen, interne Strukturen, Tickets und andere vertrauliche Daten enthalten. Sie dürfen nur autorisiert, begrenzt, geschützt und kontrolliert ausgewertet werden. --- **39. Praxisfall A: Nur ein Benutzer kann sich nicht anmelden** **Symptom** - andere Benutzer können sich am selben Client anmelden, - der Benutzer kann sich auch an einem zweiten Client nicht anmelden, - Meldung weist auf gesperrtes Konto hin. **Prüfung** 1. genaue Uhrzeit dokumentieren, 2. Benutzerkonto und Sperrstatus prüfen, 3. Ereignis `4740` auf den Domain Controllern suchen, 4. aufrufenden Computer ermitteln, 5. vorausgehende Ereignisse `4771`, `4776` oder `4625` korrelieren, 6. gespeicherte Anmeldedaten, Dienste, Aufgaben, VPN und Mobilgeräte prüfen, 7. erst danach Konto kontrolliert entsperren, 8. Ereignisse weiter überwachen. **Mögliche Ursache** Ein geplanter Task auf einem alten Client verwendet weiterhin das vorherige Benutzerkennwort und sperrt das Konto wiederholt. **Nachprüfung** - Aufgabe verwendet ein vorgesehenes Dienstkonto oder aktualisierte sichere Konfiguration, - keine weiteren fehlerhaften Anmeldeversuche, - keine neue Kontosperre, - Benutzer kann sich anmelden, - Sperrquelle und Maßnahme sind dokumentiert. --- **40. Praxisfall B: Kein Benutzer kann sich an einem Client anmelden** **Symptom** - lokale Anmeldung funktioniert, - Domänenanmeldungen schlagen fehl, - andere Clients funktionieren, - `nltest /dsgetdc:` findet keinen Domain Controller. **Prüfung** 1. IP-Konfiguration erfassen, 2. DNS-Server prüfen, 3. SRV-Einträge abfragen, 4. Domain Controller auflösen, 5. Netzwerkpfad prüfen, 6. Systemzeit kontrollieren, 7. sicheren Kanal erst nach Wiederherstellung des Netzwerkpfades testen. **Mögliche Ursache** Der Client verwendet durch eine statische Fehlkonfiguration einen öffentlichen DNS-Server und kann die internen Active-Directory-SRV-Einträge nicht auflösen. **Nachprüfung** - Client erhält die vorgesehenen DNS-Server, - SRV-Abfragen funktionieren, - Domain Controller Locator findet einen geeigneten DC, - sicherer Kanal ist intakt, - Domänenanmeldung und Gruppenrichtlinien funktionieren, - Konfigurationsursache ist dokumentiert. --- **41. Praxisfall C: Vertrauensstellung ist fehlgeschlagen** **Symptom** - lokale Anmeldung funktioniert, - Domänenanmeldung meldet eine fehlerhafte Vertrauensstellung, - DNS und Domain Controller sind erreichbar, - der Client wurde kürzlich aus einem älteren Snapshot wiederhergestellt. **Prüfung** 1. Client- und Computerkonto eindeutig identifizieren, 2. DNS und Uhrzeit prüfen, 3. Computerkonto untersuchen, 4. sicheren Kanal testen, 5. Snapshot-Zeitpunkt und Maschinenkennwort berücksichtigen, 6. Diagnoseereignisse sichern, 7. sicheren Kanal nach Freigabe kontrolliert reparieren. **Mögliche Ursache** Der Snapshot enthält ein älteres Maschinenkennwort als das Computerkonto in Active Directory. **Nachprüfung** - sicherer Kanal funktioniert, - Domänenanmeldung ist möglich, - Gruppenrichtlinien werden verarbeitet, - Kerberos-Tickets werden ausgegeben, - Clientverwaltung funktioniert, - Wiederherstellungsverfahren für Domänencomputer wird angepasst. --- **42. Praxisfall D: Anmeldung funktioniert nur an einem Standort nicht** **Symptom** - Benutzer können sich am Hauptstandort anmelden, - an einer Außenstelle schlagen neue Anmeldungen fehl, - bereits bekannte Benutzer kommen teilweise über zwischengespeicherte Daten hinein, - ein lokaler Domain Controller wird über DNS gefunden. **Prüfung** 1. betroffenen AD-Standort und Subnetz prüfen, 2. gefundenen Domain Controller dokumentieren, 3. DNS- und Dienstereichbarkeit testen, 4. `dcdiag` auf dem lokalen DC auswerten, 5. `repadmin /replsummary` und `/showrepl` prüfen, 6. Uhrzeit vergleichen, 7. Kontostand auf beteiligten Domain Controllern vergleichen, 8. Standort-Uplink und Firewall berücksichtigen. **Mögliche Ursache** Der lokale Domain Controller repliziert Benutzer- und Kennwortänderungen wegen einer gestörten Standortverbindung nicht ordnungsgemäß. **Nachprüfung** - Replikation ist fehlerfrei, - Kennwortänderungen stehen an den vorgesehenen Domain Controllern zur Verfügung, - neue Benutzer können sich anmelden, - keine zwischengespeicherte Anmeldung wird fälschlich als Onlineanmeldung bewertet, - Standortverbindung wird überwacht. --- **43. Praxisfall E: Anmeldung dauert mehrere Minuten** **Symptom** - Anmeldeinformationen werden akzeptiert, - der Bildschirm bleibt lange bei „Willkommen“ oder „Benutzereinstellungen werden angewendet“, - Benutzerprofil wird schließlich geladen, - andere Standorte sind schneller. **Prüfung** 1. Authentifizierungszeit und Profil-Ladezeit trennen, 2. Ereignisse von GroupPolicy und User Profile Service prüfen, 3. `gpresult` auswerten, 4. SYSVOL und NETLOGON testen, 5. Anmelde- und Startskripte untersuchen, 6. Netzlaufwerke und Druckerverbindungen prüfen, 7. DNS und verwendeten Domain Controller erfassen, 8. Serverprofil oder Profilcontainer untersuchen, 9. Zeitlinie von Anmeldung, Richtlinien und Profilladen erstellen. **Mögliche Ursache** Ein Anmeldeskript wartet auf einen nicht erreichbaren Dateiserver, bis ein Timeout abläuft. **Nachprüfung** - Skriptziel ist erreichbar oder kontrolliert entfernt, - Anmeldung erfolgt innerhalb des vorgesehenen Zeitraums, - alle benötigten Richtlinien werden angewendet, - Netzlaufwerke und andere Geschäftsprozesse funktionieren, - Messwerte vor und nach der Änderung sind dokumentiert. --- **44. Ungeeignete Sofortmaßnahmen** Problematisch sind insbesondere: - Benutzerkennwort sofort zurücksetzen, - Konto nur entsperren und die Sperrquelle ignorieren, - Computerkonto löschen, - Client sofort aus der Domäne entfernen, - Domain Controller neu starten, - DNS-Cache leeren, bevor Einträge dokumentiert wurden, - Kerberos-Tickets löschen, bevor sie geprüft wurden, - Firewall vollständig deaktivieren, - Gruppenrichtlinien pauschal abschalten, - Systemzeit manuell verändern, - mehrere Domain Controller gleichzeitig verändern, - Replikation ungeprüft erzwingen, - DNS-Einträge manuell neu anlegen, ohne die Registrierungsursache zu prüfen, - Benutzerprofil löschen, obwohl die Authentifizierung fehlschlägt, - lokale Administratorrechte unnötig vergeben, - Kennwörter in Tickets oder Skripten speichern, - nur Ping verwenden, - nur den Client untersuchen, - eine zwischengespeicherte Anmeldung als erfolgreiche DC-Anmeldung bewerten, - einen erfolgreichen Test mit anderem Benutzer als Beweis für fehlerfreies AD ansehen. --- **45. Vollständige Prüfreihenfolge** 1. genauen Meldungstext sichern. 2. Datum, Uhrzeit und Zeitzone erfassen. 3. Benutzer, Client und Standort bestimmen. 4. lokales Konto und Domänenkonto unterscheiden. 5. verwendetes Anmeldeformat dokumentieren. 6. prüfen, ob eine zwischengespeicherte Anmeldung möglich war. 7. feststellen, ob ein Benutzer, ein Client oder mehrere Systeme betroffen sind. 8. Vergleich mit anderem Benutzer am selben Client durchführen. 9. Vergleich mit demselben Benutzer an einem anderen Client durchführen. 10. Netzwerkstatus vor der Anmeldung berücksichtigen. 11. IP-Konfiguration erfassen. 12. Gateway und internen DNS-Server prüfen. 13. konfigurierte DNS-Server und Suffixe kontrollieren. 14. Active-Directory-SRV-Einträge auflösen. 15. Hostnamen der Domain Controller auflösen. 16. Domain Controller Locator prüfen. 17. AD-Standort des Clients bestimmen. 18. verwendeten Domain Controller dokumentieren. 19. Uhrzeit, Zeitzone und Zeitquelle prüfen. 20. Benutzerkonto auf Aktivierung, Sperre und Ablauf prüfen. 21. Anmeldezeiten und erlaubte Arbeitsstationen berücksichtigen. 22. Kennwortänderung und gespeicherte Anmeldedaten prüfen. 23. Ereignisse `4625`, `4740`, `4771` und `4776` korrelieren. 24. bei RDP den Anmeldetyp und das Zielsystem berücksichtigen. 25. Computerkonto prüfen. 26. sicheren Kanal diagnostizieren. 27. Kerberos-Tickets und KDC prüfen. 28. SYSVOL und NETLOGON testen. 29. Gruppenrichtlinien und Anmeldeskripte untersuchen. 30. Profilfehler von Authentifizierungsfehlern trennen. 31. bei VPN den Pre-Logon-Netzwerkzustand prüfen. 32. Domain Controller mit `dcdiag` untersuchen. 33. Replikation mit `repadmin` prüfen. 34. Firewall-, Routing- und Standortpfad berücksichtigen. 35. Daten aller beteiligten Systeme auf einer Zeitleiste zusammenführen. 36. konkrete Hypothese formulieren. 37. genau eine kontrollierbare Änderung durchführen. 38. dieselben Prüfungen erneut ausführen. 39. Domänenanmeldung testen. 40. Gruppenrichtlinien und Domänenressourcen prüfen. 41. Vergleichsbenutzer und Vergleichsclient testen. 42. Ereignisprotokolle auf neue Fehler prüfen. 43. temporäre Diagnosekonfiguration entfernen. 44. Ursache, Änderung und Nachweis dokumentieren. 45. Monitoring oder Präventionsmaßnahme festlegen. --- **46. Dokumentationsbeispiel** ```text Ticket: INC-20831 Zeitraum: 02.08.2026, 08:14 bis 10:42 Uhr Benutzer: test.user Client: WS-BER-042 Domäne: ad.example.test Standort: Berlin Verbindung: Ethernet Symptom: Kein Domänenbenutzer kann sich an WS-BER-042 anmelden. Lokale Anmeldung ist möglich. Andere Clients desselben Standorts sind nicht betroffen. Meldung: „Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar.“ Vergleich: - anderer Domänenbenutzer am selben Client: fehlgeschlagen - betroffener Benutzer an anderem Client: erfolgreich - lokales Administratorkonto: erfolgreich Messungen: - Client besitzt gültige IPv4-Adresse und erreicht das Standardgateway - interner DNS-Server ist erreichbar - in der statischen Adapterkonfiguration ist jedoch ein öffentlicher DNS-Server eingetragen - Abfrage von _ldap._tcp.dc._msdcs.ad.example.test schlägt fehl - nltest /dsgetdc:ad.example.test liefert Fehler 1355 - Clientzeit ist korrekt - Computerkonto ist vorhanden und aktiviert Hypothese: Der Client kann aufgrund der falschen DNS-Konfiguration keine Active-Directory-Domain-Controller finden. Kontrollierte Änderung: Die statische DNS-Konfiguration wurde entsprechend der freigegebenen Netzwerkdokumentation auf die vorgesehenen internen DNS-Server korrigiert. Andere Einstellungen blieben unverändert. Nachprüfung: - SRV-Abfrage liefert die vorgesehenen Domain Controller - nltest findet einen Domain Controller des korrekten Standorts - sicherer Kanal ist intakt - Domänenanmeldung funktioniert - Gruppenrichtlinien werden verarbeitet - SYSVOL und NETLOGON sind erreichbar - keine neuen Netlogon- oder Anmeldefehler - Vergleichsbenutzer funktioniert ebenfalls Ursache: Falsch statisch eingetragener öffentlicher DNS-Server am Domänenclient. Prävention: - DNS-Konfiguration von Domänenclients zentral überwachen - statische Clientkonfigurationen vermeiden, wenn DHCP vorgesehen ist - Prüfung der AD-SRV-Auflösung in die Clientdiagnose aufnehmen ``` --- **47. Checkliste „Anmeldung an der Domäne geht nicht“** - [ ] der genaue Meldungstext wurde gesichert. - [ ] Fehlercode und Ereignis-ID wurden dokumentiert. - [ ] Datum, Uhrzeit und Zeitzone sind bekannt. - [ ] Benutzer, Client, Standort und Verbindungsart sind bekannt. - [ ] lokales Konto und Domänenkonto wurden unterschieden. - [ ] das verwendete Anmeldeformat wurde geprüft. - [ ] Tastaturbelegung und versehentliche Eingabefehler wurden berücksichtigt. - [ ] der Umfang der Störung wurde bestimmt. - [ ] ein anderer Benutzer wurde am selben Client geprüft. - [ ] derselbe Benutzer wurde an einem anderen Client geprüft. - [ ] eine mögliche zwischengespeicherte Anmeldung wurde erkannt. - [ ] der Netzwerkstatus vor der Anmeldung wurde berücksichtigt. - [ ] IP-Adresse, Gateway, DHCP und DNS wurden dokumentiert. - [ ] der Client verwendet die vorgesehenen internen DNS-Server. - [ ] DNS-Suffixe wurden geprüft. - [ ] die AD-Domäne ist auflösbar. - [ ] LDAP-SRV-Einträge sind auflösbar. - [ ] Kerberos-SRV-Einträge sind auflösbar. - [ ] die zurückgegebenen Domain Controller sind auflösbar und erreichbar. - [ ] Domain Controller Locator wurde geprüft. - [ ] der AD-Standort des Clients wurde bestimmt. - [ ] der tatsächlich verwendete Domain Controller wurde dokumentiert. - [ ] Datum, Uhrzeit, Zeitzone und Zeitquelle wurden geprüft. - [ ] Benutzerkonto ist vorhanden und aktiviert. - [ ] Benutzerkonto ist nicht gesperrt. - [ ] Konto und Kennwort sind nicht abgelaufen. - [ ] erlaubte Anmeldezeiten und Arbeitsstationen wurden berücksichtigt. - [ ] Ereignis `4740` wurde bei Kontosperren untersucht. - [ ] alte gespeicherte Kennwörter wurden als mögliche Sperrquelle berücksichtigt. - [ ] Kennwortänderung und AD-Replikation wurden berücksichtigt. - [ ] Computerkonto ist vorhanden und aktiviert. - [ ] sicherer Kanal wurde diagnostiziert. - [ ] Snapshot-, Klon- oder Wiederherstellungsereignisse wurden berücksichtigt. - [ ] Kerberos-Tickets wurden vor einer Veränderung geprüft. - [ ] Ereignisse `4625`, `4768`, `4769`, `4771` und `4776` wurden passend untersucht. - [ ] Anmeldetyp, Status und Substatus wurden ausgewertet. - [ ] SYSVOL und NETLOGON wurden geprüft. - [ ] Gruppenrichtlinien wurden berücksichtigt. - [ ] Anmeldeskripte und Ressourcenzuordnungen wurden geprüft. - [ ] Profilfehler wurden von Authentifizierungsfehlern getrennt. - [ ] bei RDP wurden NLA und Anmelderechte geprüft. - [ ] bei VPN wurde die Verfügbarkeit vor der Anmeldung berücksichtigt. - [ ] Domain Controller wurden bei Bedarf mit `dcdiag` geprüft. - [ ] Replikation wurde bei Bedarf mit `repadmin` geprüft. - [ ] Firewall und benötigte AD-Dienste wurden berücksichtigt. - [ ] Daten wurden auf einer gemeinsamen Zeitleiste korreliert. - [ ] keine Kennwörter wurden protokolliert. - [ ] nur eine kontrollierbare Änderung wurde durchgeführt. - [ ] Domänenanmeldung wurde nach der Änderung erneut geprüft. - [ ] Gruppenrichtlinien und Domänenressourcen funktionieren. - [ ] Vergleichsbenutzer und Vergleichsclient funktionieren. - [ ] temporäre Diagnosekonfiguration wurde entfernt. - [ ] Ursache, Maßnahme und Nachweis wurden dokumentiert. - [ ] eine Präventions- oder Monitoringmaßnahme wurde festgelegt. --- **48. Schnellreferenz** | Beobachtung | wahrscheinlicher Untersuchungsbereich | |---|---| | ein Benutzer überall betroffen | Konto, Kennwort, Sperre, Ablauf oder Anmelderechte | | alle Benutzer an einem Client betroffen | DNS, Netzwerk, Uhrzeit, Computerkonto oder sicherer Kanal | | mehrere Clients eines Standorts betroffen | Standort-DNS, VLAN, Uplink, Firewall oder lokaler DC | | lokale Anmeldung funktioniert | lokales System grundsätzlich zugänglich; Domänenpfad weiter prüfen | | alter Benutzer funktioniert offline | wahrscheinlich zwischengespeicherte Anmeldung | | neuer Benutzer funktioniert offline nicht | keine zwischengespeicherten Anmeldedaten vorhanden | | altes Kennwort funktioniert offline | Cache; keine Bestätigung des aktuellen Domänenkennworts | | öffentliches DNS funktioniert, AD nicht | interne AD-DNS-Zone oder SRV-Auflösung | | Fehler 1355 bei `nltest` | Domain Controller konnte nicht gefunden werden | | Uhrzeit stark abweichend | Kerberos und Zeitdienst | | Konto gesperrt | Sperrquelle über 4740 und vorausgehende Fehler suchen | | Sperre kehrt sofort zurück | Gerät, Dienst, Aufgabe, VPN oder gespeicherte Daten | | Vertrauensstellung fehlgeschlagen | Computerkonto oder sicherer Kanal | | Fehler nach Snapshot-Rückkehr | Maschinenkennwort oder Computerzustand | | Anmeldung abhängig vom DC | Replikation, DC-Zustand, DNS oder Standort | | Anmeldung funktioniert, Profil lädt nicht | User Profile Service, Speicher oder Profilpfad | | Anmeldung bleibt bei „Willkommen“ hängen | Gruppenrichtlinie, Skript, Profil oder Ressource | | RDP allein betroffen | NLA, RDP-Rechte, Zielsystem oder Anmeldetyp 10 | | VPN allein betroffen | Pre-Logon-Verbindung, DNS, Routing, Zertifikat oder Tunnel | | SYSVOL nicht erreichbar | DNS, SMB, DC, DFS-Replikation oder Firewall | | `Test-ComputerSecureChannel` negativ | sicheren Kanal und Voraussetzungen gezielt untersuchen | | Ping erfolgreich, Anmeldung fehlschlägt | DNS, Kerberos, LDAP, SMB, RPC, Konto oder Richtlinie | | anderes Konto funktioniert | benutzerspezifischen Bereich priorisieren | | derselbe Benutzer funktioniert an anderem Client | Client oder clientspezifische Richtlinie priorisieren | | keine Ereignisse gefunden | falsches System, falscher Zeitraum, Auditierung oder Rotation | | Anmeldung nach DNS-Korrektur möglich | DNS-Ursache durch Vorher-Nachher-Daten bestätigen | | Anmeldung nach Neustart möglich | Zustand geändert; Ursache noch nicht bewiesen | --- **Merksatz** > Eine Domänenanmeldung ist kein einzelner Vorgang, sondern eine Kette aus Netzwerk, DNS, Domain Controller Locator, Zeit, Benutzerkonto, Computerkonto, sicherem Kanal und Authentifizierungsprotokoll. Die Diagnose beginnt deshalb mit dem genauen Umfang und dem originalen Fehlerzeitpunkt. Erst danach werden Client, DNS, Domain Controller und Ereignisprotokolle auf einer gemeinsamen Zeitleiste geprüft. --- **Quellen und weiterführende Dokumentation** - [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 – Locating domain controllers in Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/dc-locator) - [Microsoft Learn – Domain controller is not functioning correctly](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/domain-controller-not-functioning-correctly) - [Microsoft Learn – Active Directory domain join troubleshooting guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/active-directory-domain-join-troubleshooting-guidance) - [Microsoft Learn – Event ID 5719, error 1311 or error 1355](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/troubleshoot-kerberos-domain-not-found-event-id-5719) - [Microsoft Learn – Diagnose Active Directory replication failures](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/diagnose-replication-failures) - [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 – Advanced Audit Policy Configuration settings](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/advanced-audit-policy-configuration) - [Microsoft Learn – Appendix L: Events to Monitor](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor) - [Microsoft Learn – Event 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 – 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 – Get-ADUser](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-aduser) - [Microsoft Learn – Get-ADComputer](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adcomputer) - [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 – dcdiag](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dcdiag) - [Microsoft Learn – repadmin](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc770963%28v%3Dws.11%29) - [Microsoft Learn – klist](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/klist) - [Microsoft Learn – w32tm](https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings) - [Microsoft Learn – gpresult](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/gpresult) - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent)