IT-Fehleranalyse & Troubleshooting

Praxisnahes Nachschlagewerk zur systematischen Analyse und Behebung von IT-Fehlern. Von der Diagnose über die Ursachenfindung bis zur nachhaltigen Lösung typischer Probleme in Hardware, Software und Netzwerken.

Inhaltsangabe / Übersicht

IT-Praxiswissen – verbindliche Inhaltsübersicht

Status: alleinige Referenz für die weitere Ausarbeitung

Diese Inhaltsübersicht ersetzt alle früheren Übersichten, provisorischen Nummerierungen und frei fortgesetzten Seitenfolgen.

Verbindliche Regeln:

Kapitel 1 – Methodik, Dokumentation und Eskalation

Kapitel 2 – Grundwerkzeuge und Diagnosebefehle

Kapitel 3 – Strom, Hardware und physische Verbindung

Kapitel 4 – Ethernet, Switching und VLAN

Kapitel 5 – IPv4, IPv6, ARP, NDP und Routing

Kapitel 6 – DHCP

Kapitel 7 – DNS und Namensauflösung

Kapitel 8 – Zeit, NTP und Zeitzonen

Kapitel 9 – TCP, UDP, Ports, Firewall, NAT und Proxy

Kapitel 10 – WLAN

Kapitel 11 – WAN, Internet, VPN und Remotezugriff

Kapitel 12 – Windows-Clients

Kapitel 13 – Windows Server, Active Directory und Identität

Kapitel 14 – macOS-Clients

Kapitel 15 – Datei-, Freigabe-, Rechte- und Druckdienste

Kapitel 16 – Linux-Server

Kapitel 17 – Virtualisierung, Cluster und Hochverfügbarkeit

Kapitel 18 – Docker, Container und Kubernetes

Kapitel 19 – Storage, RAID, NAS, SAN und Backup

Kapitel 20 – Web, API, TLS, Reverse Proxy und Load Balancer

Kapitel 21 – Datenbanken, Queues und Backenddienste

Kapitel 22 – E-Mail, Collaboration und Cloud/SaaS

Kapitel 23 – Performance und „alles ist langsam“

Kapitel 24 – Security-Vorfälle und verdächtiges Verhalten

Kapitel 25 – Monitoring, Alarmierung und Dokumentation

Kapitel 26 – Spezialdienste

Kapitel 27 – Schnellreferenzen und Runbooks

Verbindliche Fortsetzungsregel

Die Ausarbeitung erfolgt ausschließlich in der Reihenfolge dieser Übersicht. Nach einer fertiggestellten Seite folgt immer die unmittelbar nächste vorhandene Nummer. Existiert in einem Kapitel keine weitere Seite, beginnt das nächste Kapitel mit .1.

Beispiel für den Übergang von Kapitel 8 zu Kapitel 9:

8.3 → 8.4 → 9.1

Nicht zulässig ist:

8.3 → 8.4 → 8.5

Eine Änderung dieser Übersicht ist nur dann gültig, wenn zuerst dieses Referenzdokument vollständig aktualisiert wird. Eine spontan erzeugte Seite verändert die Inhaltsübersicht nicht.

1. Grundlagen der systematischen Fehleranalyse

1. Grundlagen der systematischen Fehleranalyse

1.0 Diagnoseansatz – Systematische Fehleranalyse

Zweck dieser Seite

Diese Seite beschreibt die grundlegende Denk- und Arbeitsweise bei der professionellen IT-Fehleranalyse.

Sie ist die Einführungsseite des Kapitels. Konkrete Befehle, Befundformulare und detaillierte Diagnoseabläufe folgen auf den nächsten Seiten.

Was bedeutet systematische Fehleranalyse?

Systematische Fehleranalyse bedeutet, eine Störung nicht durch zufälliges Ausprobieren zu bearbeiten.

Stattdessen wird:

  1. das sichtbare Problem beschrieben;
  2. der betroffene Bereich eingegrenzt;
  3. der technische Datenpfad verstanden;
  4. eine mögliche Ursache als Hypothese formuliert;
  5. die Hypothese mit einem gezielten Test geprüft;
  6. nur die nachgewiesene Ursache behoben;
  7. die vollständige Funktion anschließend verifiziert.

Das Ziel ist nicht nur, das Symptom kurzfristig zu beseitigen. Die tatsächliche technische Ursache soll gefunden, behoben und dokumentiert werden.

Ein Symptom ist keine Ursache

Eine Störung wird zunächst meistens nur als Symptom wahrgenommen.

Beispiele:

Symptom Mögliche Ursachen
„Das Internet funktioniert nicht“ Interface, Kabel, VLAN, DHCP, Gateway, DNS, Proxy, Firewall, VPN oder Provider
„Der Server ist langsam“ CPU, RAM, Datenträger, Netzwerk, DNS, Anwendung, Datenbank, Backup oder Hypervisor
„Die Anmeldung funktioniert nicht“ Konto, Passwort, DNS, Uhrzeit, Kerberos, Domain Controller, MFA oder Berechtigungen
„Die Webseite ist nicht erreichbar“ DNS, Routing, Firewall, TCP-Port, TLS, Proxy, Webserver oder Anwendung
„Der Container startet nicht“ Image, Architektur, Konfiguration, Port, Volume, Rechte, Abhängigkeit oder Ressourcenlimit

Aus einem Symptom dürfen deshalb nicht sofort konkrete Reparaturmaßnahmen abgeleitet werden.

Typische Denkfehler

Vorschnelle Festlegung

Nach dem ersten Hinweis wird sofort eine Ursache angenommen.

Beispiel:

Der Hostname funktioniert nicht. Also ist der DNS-Server ausgefallen.

Der DNS-Server könnte erreichbar sein und trotzdem einen falschen Record liefern. Ebenso könnten DNS-Suffix, Clientcache, hosts-Datei, VPN-DNS oder Split-DNS die Ursache sein.

Bestätigungsfehler

Es werden nur noch Informationen gesucht, welche die eigene Vermutung bestätigen. Widersprechende Befunde werden ignoriert.

Korrelation mit Ursache verwechseln

Ein Fehler tritt nach einem Update auf. Daraus wird geschlossen, dass das Update die Ursache sein muss.

Die zeitliche Nähe ist ein wichtiger Hinweis, aber noch kein Nachweis.

Nur die eigene Komponente untersuchen

Der Clientadministrator untersucht nur den Client, der Netzwerkadministrator nur den Switch und der Serveradministrator nur den Server.

Eine Verbindung funktioniert jedoch nur, wenn der gesamte Datenpfad funktioniert.

Erfolgreichen Einzeltest überbewerten

Ein erfolgreicher Ping beweist nicht, dass DNS, TCP-Port, TLS, Authentifizierung oder Anwendung funktionieren.

Mehrere Änderungen gleichzeitig durchführen

Werden gleichzeitig DNS geändert, Firewallregeln angepasst und Dienste neu gestartet, kann anschließend nicht mehr festgestellt werden, welche Maßnahme tatsächlich wirksam war.

Neustart mit Fehlerbehebung verwechseln

Ein Neustart kann einen fehlerhaften Zustand vorübergehend beseitigen. Die Ursache ist dadurch nicht automatisch bekannt oder dauerhaft behoben.

Grundlegender Diagnosekreislauf

Symptom → Eingrenzung → Datenpfad → Hypothese → Test → Befund → Korrektur → Verifikation → Dokumentation

Nach jedem Test wird entschieden:

Erst eine bestätigte Hypothese führt zu einer konkreten Korrektur.

Die wichtigsten Eingrenzungsmethoden

Methode Grundidee Typischer Einsatz
Bottom-up Von Hardware und Verbindung zur Anwendung arbeiten Link-, Kabel-, VLAN- und Netzwerkprobleme
Top-down Bei Benutzer und Anwendung beginnen Anwendungs-, Zugriffs- und Authentifizierungsfehler
Divide and Conquer Datenpfad in Abschnitte teilen Lange oder komplexe Verbindungswege
Follow the Path Anfrage und Antwort vollständig verfolgen Routing, Firewall, NAT, Proxy und VPN
Known Good Comparison Mit funktionierendem System vergleichen Einzelne Benutzer, Clients oder Ports
Controlled Swap Komponente kontrolliert austauschen Kabel, Port, SFP, Netzteil oder Client
Two-Sided Analysis Sender und Empfänger gleichzeitig untersuchen Paketverlust und Kommunikationsabbrüche
Historical Comparison Aktuellen Zustand mit früherem Zustand vergleichen Änderungen, Updates und Performanceprobleme

Keine Methode ist grundsätzlich immer die richtige. Die Auswahl hängt vom Symptom und vom bekannten Datenpfad ab.

Technischen Datenpfad betrachten

Ein Dienst besteht häufig aus mehreren voneinander abhängigen Komponenten.

Beispiel:

Benutzer → Client → Netzwerkinterface → Switch oder Access Point → VLAN → Gateway → Firewall → Server → Anwendung → Datenbank

Für jede Komponente muss geklärt werden:

Dadurch lässt sich der fehlerhafte Abschnitt schrittweise eingrenzen.

Sender, Empfänger, Hinweg und Rückweg

Eine vollständige Verbindungsanalyse betrachtet immer vier Bereiche:

Bereich Fragestellung
Sender Wird die Anfrage korrekt erzeugt und gesendet?
Hinweg Erreicht die Anfrage das Ziel?
Empfänger Nimmt das Ziel die Anfrage an und antwortet es?
Rückweg Erreicht die Antwort den ursprünglichen Sender?

Eine Anfrage kann den Server erreichen, obwohl die Antwort wegen einer fehlenden Rückroute, einer Firewall oder asymmetrischem Routing verloren geht.

Vergleich mit einem funktionierenden System

Ein bekannt funktionierendes Vergleichssystem ist häufig aussagekräftiger als eine allgemeine Vermutung.

Verglichen werden können:

Entscheidend ist, möglichst nur einen Unterschied gleichzeitig zu untersuchen.

Beweise vor Veränderungen sichern

Viele technische Informationen sind flüchtig.

Dazu gehören:

Deshalb gilt:

Erst den ursprünglichen Zustand erfassen, danach verändern.

Welche Informationen konkret gesichert werden, wird auf der Seite 1.4 Flüchtige Informationen und Beweise sichern behandelt.

Eine Änderung pro Test

Jede Änderung muss eine konkrete Hypothese prüfen.

Beispiel:

Hypothese: Der Client befindet sich im falschen VLAN.

Geeigneter Test:

Switchport-Zuweisung und tatsächlich gelerntes VLAN mit einem funktionierenden Port vergleichen.

Erst wenn die Hypothese bestätigt ist, wird die VLAN-Konfiguration korrigiert.

Mehrere gleichzeitige Änderungen verhindern eine eindeutige Ursachenbestimmung.

Fehlerbehebung und Verifikation trennen

Eine ausgeführte Änderung ist noch keine bestätigte Lösung.

Nach der Korrektur muss geprüft werden:

Ein Fehler gilt erst dann als behoben, wenn die ursprüngliche Funktion vollständig getestet wurde.

Dokumentation als Teil der Fehlerbehebung

Eine vollständige Fehlerdokumentation enthält:

Die Dokumentation verhindert, dass derselbe Fehler später erneut vollständig untersucht werden muss.

Grundregeln

Seiten dieses Kapitels

Quellen

1. Grundlagen der systematischen Fehleranalyse

1.1 Störung strukturiert aufnehmen

Zweck dieser Seite

Diese Seite dient der vollständigen und einheitlichen Aufnahme einer IT-Störung.

Bevor mit der technischen Diagnose begonnen wird, müssen das sichtbare Problem, der Zeitpunkt, die betroffenen Systeme und die verfügbaren Beweise dokumentiert werden.

Eine gute Störungsaufnahme verhindert:

Grundregel

Die Störung wird zunächst beschrieben, aber noch nicht bewertet.

Beispiel:

Nicht ausreichend:

Das Netzwerk funktioniert nicht.

Besser:

Der Client erhält seit dem 30.07.2026 um 14:35 Uhr über Ethernet keine DHCP-Adresse. Windows verwendet stattdessen die IPv4-Adresse 169.254.18.24. Über WLAN erhält derselbe Client eine gültige Adresse und kann auf interne Dienste zugreifen.

Die zweite Beschreibung enthält ein beobachtbares Symptom, einen Zeitpunkt, ein betroffenes Interface und einen funktionierenden Vergleich.

Die wichtigsten Informationen

Information Fragestellung
Melder Wer hat die Störung gemeldet?
Zeitpunkt Wann wurde die Störung erstmals festgestellt?
Letzter funktionierender Zustand Wann funktionierte der Dienst zuletzt nachweislich?
Betroffener Benutzer Welcher Benutzer beobachtet das Problem?
Betroffenes Gerät Hostname, Gerätetyp und Betriebssystem
Betroffener Dienst Welche Anwendung, Verbindung oder Funktion ist gestört?
Standort Gebäude, Raum, Homeoffice, Außenstelle oder Cloud
Netzwerkverbindung Ethernet, WLAN, Mobilfunk oder VPN
Fehlermeldung Exakter und vollständiger Wortlaut
Reproduzierbarkeit Kann der Fehler gezielt erneut ausgelöst werden?
Häufigkeit Dauerhaft, gelegentlich, periodisch oder einmalig
Auswirkung Was kann der Benutzer oder das Unternehmen nicht durchführen?
Workaround Gibt es einen vorübergehend funktionierenden Alternativweg?
Letzte Änderungen Was wurde kurz vor dem Auftreten verändert?
Beweise Screenshots, Logs, Zeitstempel, Monitoring oder Paketmitschnitt

Exakte Fehlermeldung erfassen

Fehlermeldungen dürfen nicht nur sinngemäß wiedergegeben werden.

Dokumentiert werden:

Beispiel:

Nicht ausreichend:

Anmeldung geht nicht.

Besser:

Bei der Anmeldung erscheint um 08:14 Uhr die Meldung „Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.“

Exakte Fehlermeldungen ermöglichen eine gezieltere Suche in Logs und Herstellerdokumentationen.

Zeitpunkt dokumentieren

Der genaue Zeitpunkt ist erforderlich, um Ereignisse verschiedener Systeme miteinander zu vergleichen.

Dokumentiert werden:

Beispiel:

Fehler reproduziert am 30.07.2026 um 14:42:18 Uhr MESZ.

Ungefähre Angaben wie „heute Morgen“ oder „vorhin“ reichen für eine Logkorrelation nicht aus.

Zeit und Systeminformationen erfassen

Prüfung Windows Linux macOS
Hostname [RO] hostname [RO] hostname [RO] hostname
Benutzerkontext [RO] whoami [RO] whoami [RO] whoami
Systemzeit [RO] Get-Date -Format o [RO] date "+%Y-%m-%d %H:%M:%S %Z" [RO] date "+%Y-%m-%d %H:%M:%S %Z"
Betriebssystem [RO] Get-CimInstance Win32_OperatingSystem | Select-Object Caption,Version,BuildNumber [RO] cat /etc/os-release [RO] sw_vers
Laufzeit [RO] (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime [RO] uptime [RO] uptime
Letzter Systemstart [RO] Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime [RO] who -b [RO] sysctl -n kern.boottime

Diese Befehle verändern keine Konfiguration.

Betroffenes System erfassen

Für einen Client oder Server werden mindestens folgende Angaben benötigt:

Betroffenen Dienst erfassen

Der betroffene Dienst muss möglichst genau benannt werden.

Nicht ausreichend:

Der Server geht nicht.

Besser:

Die HTTPS-Anwendung auf app.example.internal ist über TCP 443 nicht erreichbar. Der Server antwortet weiterhin auf ICMP und SSH.

Mögliche Dienstangaben:

Sollzustand und Istzustand trennen

Zustand Beschreibung
Sollzustand Was sollte normalerweise geschehen?
Istzustand Was geschieht tatsächlich?
Abweichung Welcher konkrete Unterschied besteht?

Beispiel:

Zustand Beobachtung
Sollzustand Client erhält per DHCP eine Adresse aus 192.168.10.0/24
Istzustand Client verwendet 169.254.18.24/16
Abweichung Kein gültiger DHCP-Lease vorhanden

Reproduzierbarkeit dokumentieren

Ein reproduzierbarer Fehler ist leichter zu untersuchen als ein unregelmäßiger Fehler.

Dokumentiert werden:

  1. Ausgangszustand;
  2. genaue Aktion;
  3. verwendeter Benutzer;
  4. verwendetes Gerät;
  5. Zielsystem oder Zieladresse;
  6. erwartetes Ergebnis;
  7. tatsächliches Ergebnis;
  8. genaue Fehlerzeit.

Beispiel:

  1. Client ist über Ethernet verbunden.
  2. Benutzer öffnet https://app.example.internal.
  3. Browser wartet ungefähr 30 Sekunden.
  4. Anschließend erscheint ein Timeout.
  5. Fehler reproduziert um 14:42:18 Uhr MESZ.
  6. Andere Webseiten funktionieren.

Häufigkeit bestimmen

Auftreten Dokumentation
Dauerhaft Fehler tritt bei jedem Versuch auf
Gelegentlich Fehler tritt unregelmäßig auf
Periodisch Fehler tritt in erkennbaren Zeitabständen auf
Zeitabhängig Fehler tritt nur zu bestimmten Uhrzeiten auf
Lastabhängig Fehler tritt nur bei hoher Nutzung auf
Standortabhängig Fehler tritt nur in einem Gebäude oder Netz auf
Benutzerabhängig Fehler tritt nur mit einem bestimmten Konto auf
Geräteabhängig Fehler tritt nur an einem bestimmten Client auf
Einmalig Fehler konnte bisher nicht erneut erzeugt werden

Bei unregelmäßigen Fehlern müssen Zeitpunkt und Begleitumstände besonders genau dokumentiert werden.

Letzten funktionierenden Zustand festhalten

Die Frage lautet nicht nur:

Seit wann besteht der Fehler?

Zusätzlich muss geklärt werden:

Wann wurde die betroffene Funktion zuletzt nachweislich erfolgreich verwendet?

Beispiele:

Der letzte funktionierende Zustand begrenzt den Zeitraum, in dem eine auslösende Änderung stattgefunden haben kann.

Letzte Änderungen erfassen

An dieser Stelle werden Änderungen zunächst nur gesammelt. Die technische Bewertung erfolgt später auf der Seite 1.3 Zeitpunkt und letzte Änderungen untersuchen.

Mögliche Änderungen:

Auch die Antwort „Keine Änderung bekannt“ wird dokumentiert.

Auswirkung erfassen

Die technische Störung und ihre betriebliche Auswirkung sind getrennt zu dokumentieren.

Technische Störung Mögliche Auswirkung
Ein Client erhält keine IP-Adresse Ein Benutzer kann nicht arbeiten
DHCP für ein VLAN ausgefallen Eine gesamte Abteilung erhält keine Netzwerkverbindung
DNS-Auflösung gestört Mehrere Anwendungen erscheinen gleichzeitig ausgefallen
Fileserver nicht erreichbar Gemeinsame Dokumente können nicht geöffnet werden
VPN ausgefallen Remotezugriff für Außenstellen oder Homeoffice nicht möglich
Datenbank nicht erreichbar Geschäftsanwendung vollständig ausgefallen
Backup fehlgeschlagen Wiederherstellbarkeit möglicherweise gefährdet
Verdächtige Anmeldung Möglicher Security-Vorfall

Workaround dokumentieren

Ein vorhandener Workaround kann bei der Eingrenzung helfen.

Beispiele:

Ein Workaround ist keine dauerhafte Fehlerbehebung.

Beweise sichern

Mögliche Beweise:

Dateinamen sollten den Host und den Zeitpunkt enthalten.

Beispiel:

client01_systemlog_2026-07-30_1442.evtx

server01_network_2026-07-30_1442.pcapng

Sensible Daten, Passwörter, Tokens und private Schlüssel dürfen nicht ungeschützt in Tickets oder Dokumentationen eingefügt werden.

Vorlage für die Störungsaufnahme

Feld Eintrag
Ticket oder Referenz
Gemeldet von
Aufgenommen am
Aufgenommen durch
Beginn der Störung
Letzter funktionierender Zustand
Betroffener Benutzer
Betroffenes Gerät
Hostname
Betriebssystem und Version
Standort
Netzwerkverbindung
Betroffener Dienst
Zielsystem oder Zieladresse
Sollzustand
Istzustand
Exakte Fehlermeldung
Fehlercode oder Event-ID
Reproduzierbar
Schritte zur Reproduktion
Häufigkeit
Bekannte letzte Änderungen
Betriebliche Auswirkung
Vorhandener Workaround
Gesicherte Logs und Beweise
Genaue Fehlerzeit mit Zeitzone
Security-Verdacht
Zusätzliche Hinweise

Beispiel einer ausgefüllten Störungsaufnahme

Feld Eintrag
Ticket oder Referenz INC-2026-0730-01
Gemeldet von Benutzer der Arbeitsstation
Aufgenommen am 30.07.2026, 14:40 Uhr MESZ
Beginn der Störung ungefähr 14:35 Uhr
Letzter funktionierender Zustand 30.07.2026, 12:10 Uhr
Betroffenes Gerät Arbeitsplatzrechner
Hostname CLIENT-01
Betriebssystem und Version Windows 11
Standort Hauptstandort, Raum 204
Netzwerkverbindung Ethernet
Betroffener Dienst DHCP und allgemeiner Netzwerkzugriff
Sollzustand IPv4-Adresse aus 192.168.10.0/24
Istzustand IPv4-Adresse 169.254.18.24/16
Exakte Fehlermeldung Keine Fehlermeldung angezeigt
Reproduzierbar Ja
Häufigkeit Dauerhaft über Ethernet
Bekannte letzte Änderungen Keine Änderung bekannt
Betriebliche Auswirkung Benutzer kann keine internen Dienste erreichen
Vorhandener Workaround WLAN funktioniert
Gesicherte Beweise Ausgabe von ipconfig /all, Screenshot und Fehlerzeit
Security-Verdacht Nein

Diese Aufnahme beschreibt den Zustand. Die technische Eingrenzung erfolgt anschließend auf der Seite 1.2 Fehlerumfang mit Kreuztests bestimmen.

Ungeeignete Störungsbeschreibungen

Diese Aussagen enthalten Vermutungen oder sind technisch nicht ausreichend eingegrenzt.

Ergebnis dieser Seite

Nach Abschluss der Störungsaufnahme müssen folgende Punkte bekannt sein:

Erst danach beginnt die systematische technische Eingrenzung.

Nächste Seite

1.2 Fehlerumfang mit Kreuztests bestimmen

Quellen

1. Grundlagen der systematischen Fehleranalyse

1.2 Fehlerumfang mit Kreuztests bestimmen

Zweck dieser Seite

Diese Seite dient dazu, den Umfang einer Störung systematisch einzugrenzen.

Nach der Störungsaufnahme ist bekannt, welches Symptom beobachtet wurde. Jetzt wird geprüft, ob die Ursache wahrscheinlich beim Benutzer, beim Gerät, beim Netzwerk, beim Standort, beim Zielsystem oder bei einem zentralen Dienst liegt.

In dieser Phase wird die Ursache noch nicht behoben. Das Ziel ist zunächst, die Fehlerdomäne möglichst stark zu verkleinern.

Grundprinzip

Ein einzelner Test zeigt häufig nur, dass etwas funktioniert oder nicht funktioniert.

Ein Kreuztest verändert gezielt nur eine Bedingung:

Dadurch lässt sich erkennen, mit welcher Komponente der Fehler mitwandert.

Was ist eine Fehlerdomäne?

Eine Fehlerdomäne ist der technische oder organisatorische Bereich, in dem die Ursache wahrscheinlich liegt.

Mögliche Fehlerdomänen:

Fehlerdomäne Beispiele
Benutzer Konto, Passwort, Gruppen, Rollen, Profil oder persönliche Einstellungen
Gerät Betriebssystem, Treiber, lokale Firewall, Software oder Hardware
Netzwerkinterface Ethernetadapter, WLAN-Adapter, USB-Adapter oder virtuelle NIC
Verkabelung Patchkabel, Dose, Patchfeld oder Gebäudeverkabelung
Switchport Portkonfiguration, VLAN, Port Security oder Hardwarefehler
VLAN oder Subnetz DHCP, Gateway, ACL, Routing oder Broadcast-Domain
Standort Switch, Firewall, WAN, VPN, Provider oder Stromversorgung
Zielsystem Server, Anwendung, Dienst, Listener oder lokale Firewall
Zentraler Dienst DNS, DHCP, Active Directory, NTP, Proxy oder Cloud-Dienst
Benutzergruppe Gruppenrichtlinie, Berechtigung, Lizenz oder Conditional Access
Betriebssystemgruppe Update, Treiber, Softwareversion oder Sicherheitsrichtlinie
Zeitpunkt oder Last Backup, Wartungsjob, hohe Auslastung oder geplante Änderung

Die wichtigsten Eingrenzungsachsen

Achse Fragestellung
Benutzer Ist nur ein bestimmter Benutzer betroffen?
Gerät Tritt der Fehler nur an einem Gerät auf?
Interface Tritt der Fehler nur über Ethernet, WLAN oder VPN auf?
Port Tritt der Fehler nur an einem Switchport auf?
VLAN Sind alle Geräte eines VLANs betroffen?
Subnetz Sind alle Geräte eines IP-Netzes betroffen?
Standort Ist nur ein Gebäude oder eine Außenstelle betroffen?
Dienst Ist nur ein bestimmter Dienst betroffen?
Ziel Ist nur ein bestimmter Server betroffen?
Betriebssystem Sind nur Windows-, Linux- oder macOS-Systeme betroffen?
Version Sind nur Systeme mit einem bestimmten Patchstand betroffen?
Zeit Tritt der Fehler nur zu bestimmten Zeiten auf?
Last Tritt der Fehler nur bei hoher Nutzung auf?

Betroffen und nicht betroffen dokumentieren

Die nicht betroffenen Systeme sind für die Diagnose genauso wichtig wie die betroffenen Systeme.

Kategorie Betroffen Nicht betroffen
Benutzer
Geräte
Betriebssysteme
Standorte
Switchports
VLANs
Subnetze
Netzwerkverbindungen
Anwendungen
Server
Zeiträume

Beispiel:

Kategorie Betroffen Nicht betroffen
Benutzer user andere Benutzer
Gerät CLIENT-01 CLIENT-02
Netzwerkverbindung Ethernet WLAN
Dienst interne Dienste lokale Anwendungen
Standort Raum 204 Raum 205

Aus diesem Beispiel ergibt sich noch keine endgültige Ursache. Der Fehlerbereich wurde aber bereits auf Ethernet, Verkabelung, Switchport, VLAN-Zuweisung oder die Ethernetkonfiguration des Clients eingegrenzt.

Regel für kontrollierte Kreuztests

Bei einem Kreuztest wird möglichst nur eine Bedingung verändert.

Ungeeignet:

Bei diesem Test wurden mehrere Bedingungen verändert. Das Ergebnis ist nicht eindeutig.

Besser:

  1. gleicher Benutzer an anderem Gerät;
  2. anderer Benutzer am ursprünglichen Gerät;
  3. ursprüngliches Gerät über ein anderes Interface;
  4. ursprüngliches Gerät an anderem Switchport.

Kreuztest 1 – Gleicher Benutzer an anderem Gerät

Durchführung

Der betroffene Benutzer testet dieselbe Funktion an einem anderen, nachweislich funktionierenden Gerät.

Auswertung

Ergebnis Wahrscheinlicher Bereich
Fehler tritt auch am anderen Gerät auf Benutzerkonto, Berechtigung, Rolle, Lizenz, Profil oder zentral gespeicherte Einstellung
Fehler tritt am anderen Gerät nicht auf ursprüngliches Gerät, lokale Konfiguration, Interface oder Software
Fehler tritt nur an Geräten eines Standortes auf Standortnetz, Richtlinie oder gemeinsamer Dienst
Ergebnis abhängig vom Betriebssystem Clientsoftware, Treiber, Richtlinie oder Kompatibilität

Wichtig

Es muss wirklich dieselbe Funktion mit demselben Benutzer getestet werden.

Kreuztest 2 – Anderer Benutzer am gleichen Gerät

Durchführung

Ein anderer berechtigter Benutzer testet dieselbe Funktion am betroffenen Gerät.

Auswertung

Ergebnis Wahrscheinlicher Bereich
Anderer Benutzer ist ebenfalls betroffen Gerät, Betriebssystem, Netzwerk oder lokale Software
Anderer Benutzer ist nicht betroffen Benutzerprofil, Konto, Rechte, Gruppen oder persönliche Einstellungen
Administrator funktioniert, Standardbenutzer nicht Rechte, UAC, Richtlinie oder Dateiberechtigung
Lokaler Benutzer funktioniert, Domänenbenutzer nicht AD, DNS, Kerberos, GPO oder Netzwerkerreichbarkeit

Anmeldedaten dürfen nicht zwischen Benutzern weitergegeben werden. Der andere Benutzer meldet sich selbst an.

Kreuztest 3 – Gleiches Gerät über anderes Netzwerkinterface

Mögliche Vergleiche:

Auswertung

Ergebnis Wahrscheinlicher Bereich
Ethernet fehlerhaft, WLAN funktioniert Ethernetadapter, Kabel, Switchport, VLAN oder kabelgebundenes Netz
WLAN fehlerhaft, Ethernet funktioniert WLAN-Adapter, Funkversorgung, SSID, Authentifizierung oder WLAN-VLAN
Direkter Zugriff funktioniert, VPN nicht VPN, Tunnelrouting, VPN-DNS, MTU oder Berechtigung
VPN funktioniert, lokaler Standortzugriff nicht Standortnetz, lokales Routing, Firewall oder DNS
Beide Interfaces fehlerhaft Betriebssystem, zentrale Dienste, Zielsystem oder allgemeine Konfiguration

Ein funktionierendes alternatives Interface ist ein wichtiger Hinweis, aber noch keine dauerhafte Lösung.

Kreuztest 4 – Gleiches Gerät an anderem Switchport

Durchführung

Das betroffene Gerät wird kontrolliert mit einem nachweislich funktionierenden Port verbunden.

Dabei müssen berücksichtigt werden:

Auswertung

Ergebnis Wahrscheinlicher Bereich
Gerät funktioniert am anderen Port ursprünglicher Port, Portprofil, VLAN, Kabelweg oder Switchhardware
Gerät funktioniert auch am anderen Port nicht Client, Adapter, Betriebssystem oder übergeordneter Netzwerkdienst
Mehrere Geräte funktionieren am ursprünglichen Port nicht Port, Kabelweg oder Switchkonfiguration
Andere Geräte funktionieren am ursprünglichen Port ursprünglicher Client oder dessen Authentifizierung

Der Vergleichsport muss für denselben Einsatzzweck und dasselbe VLAN vorgesehen sein.

Kreuztest 5 – Funktionierendes Gerät am betroffenen Port

Durchführung

Ein bekannt funktionierendes Gerät wird mit dem ursprünglichen Kabel und Switchport verbunden.

Auswertung

Ergebnis Wahrscheinlicher Bereich
Vergleichsgerät funktioniert ursprünglicher Client, NIC, Treiber oder Clientkonfiguration
Vergleichsgerät funktioniert nicht Kabel, Dose, Patchfeld, Switchport, VLAN oder Portprofil
Vergleichsgerät erhält anderes VLAN 802.1X, NAC, MAC-basierte Zuweisung oder Portprofil
Vergleichsgerät erhält ebenfalls keine IP DHCP, VLAN, Relay, Snooping oder Portkonfiguration

Kreuztest 6 – Gleiches Gerät, anderes Ziel

Durchführung

Vom betroffenen Client werden mehrere technisch vergleichbare Ziele getestet.

Beispiele:

Auswertung

Ergebnis Wahrscheinlicher Bereich
Nur ein Ziel ist nicht erreichbar Zielserver, Zieldienst, Ziel-Firewall oder Rückroute
Alle Ziele eines Subnetzes sind nicht erreichbar Routing, ACL, Firewall oder Gateway dieses Netzes
Interne Ziele funktionieren, externe nicht WAN, NAT, Proxy, Firewall oder Provider
Externe Ziele funktionieren, interne nicht internes Routing, VPN, interne DNS-Auflösung oder interne Firewall
Nur ein bestimmter Dienst ist nicht erreichbar Port, Listener, Host-Firewall oder Anwendung

Kreuztest 7 – Andere Quelle, gleiches Ziel

Durchführung

Dasselbe Ziel wird von einem anderen Client, VLAN oder Standort getestet.

Auswertung

Ergebnis Wahrscheinlicher Bereich
Andere Quelle erreicht das Ziel ursprünglicher Client oder ursprünglicher Netzwerkpfad
Keine Quelle erreicht das Ziel Zielsystem, zentraler Dienst oder allgemeiner Netzwerkpfad
Nur ein VLAN erreicht das Ziel nicht VLAN-Gateway, ACL, Routing oder Firewallregel
Nur ein Standort erreicht das Ziel nicht WAN, Standortfirewall, VPN oder Provider
Nur ein Betriebssystem ist betroffen Clientsoftware, Zertifikat, Richtlinie oder Protokollkompatibilität

Kreuztest 8 – IP-Adresse gegen Hostname

Durchführung

Das Ziel wird zuerst über die IP-Adresse und anschließend über den Hostnamen geprüft.

Prüfung Windows Linux macOS
Ziel-IP testen [RO] Test-NetConnection <Ziel-IP> [RO] ping -c 4 <Ziel-IP> [RO] ping -c 4 <Ziel-IP>
Hostname testen [RO] Test-NetConnection <Hostname> [RO] ping -c 4 <Hostname> [RO] ping -c 4 <Hostname>
DNS-Abfrage [RO] Resolve-DnsName <Hostname> [RO] dig <Hostname> [RO] dig <Hostname>

Auswertung

Ergebnis Wahrscheinlicher Bereich
IP funktioniert, Hostname nicht DNS, DNS-Suffix, Clientcache oder hosts-Datei
IP und Hostname funktionieren nicht Erreichbarkeit, Routing, Firewall oder Zielsystem
Hostname löst auf falsche IP auf DNS-Record, Split-DNS, Cache oder falscher DNS-Server
A-Record funktioniert, AAAA-Pfad nicht IPv6-Konfiguration oder IPv6-Routing
Kurzname funktioniert nicht, FQDN funktioniert DNS-Suffix oder Suchdomäne

Kreuztest 9 – Ping gegen tatsächlichen Dienstport

Ein Ping prüft nicht den eigentlichen Anwendungsdienst.

Prüfung Windows Linux macOS
ICMP [RO] Test-NetConnection <Ziel> [RO] ping -c 4 <Ziel> [RO] ping -c 4 <Ziel>
TCP-Port [RO] Test-NetConnection <Ziel> -Port <Port> [RO] nc -vz <Ziel> <Port> [RO] nc -vz <Ziel> <Port>
HTTPS [RO] curl -v https://<Ziel>/ [RO] curl -v https://<Ziel>/ [RO] curl -v https://<Ziel>/

Auswertung

Ergebnis Wahrscheinlicher Bereich
Ping und Port funktionieren grundlegende Verbindung vorhanden; Anwendung weiter prüfen
Ping funktioniert, Port nicht Listener, Dienst, Host-Firewall oder Netzwerkfirewall
Ping funktioniert nicht, Port funktioniert ICMP wird wahrscheinlich gefiltert
Port funktioniert, HTTPS-Anfrage nicht TLS, Proxy, Host Header oder Anwendung
TCP-Verbindung wird zurückgesetzt Zielprozess, Firewall, Proxy oder Load Balancer

curl -v kann Header, Zertifikatsinformationen und sensible Sitzungsdaten anzeigen. Ausgaben müssen vor der Weitergabe geprüft werden.

Kreuztest 10 – Lokal gegen entfernt

Test Zweck
Dienst lokal auf dem Server testen Prüft, ob Anwendung und lokaler Listener funktionieren
Dienst aus gleichem VLAN testen Prüft den lokalen Netzwerkzugriff
Dienst aus anderem VLAN testen Prüft Routing und Firewall zwischen Netzen
Dienst über VPN testen Prüft Tunnel, VPN-Routing und VPN-DNS
Dienst aus externem Netz testen Prüft WAN, NAT, Reverse Proxy oder externe Firewall

Auswertung

Ergebnis Wahrscheinlicher Bereich
Lokal funktioniert, entfernt nicht Firewall, Bind-Adresse, Routing, NAT oder Netzwerkpfad
Lokal funktioniert nicht Dienst, Anwendung, Konfiguration oder Abhängigkeit
Gleiches VLAN funktioniert, anderes VLAN nicht Inter-VLAN-Routing, ACL oder Firewall
Intern funktioniert, extern nicht NAT, WAN-Firewall, DNS oder Reverse Proxy
Extern funktioniert, intern nicht Hairpin NAT, internes DNS oder interne Route

System- und Netzwerkidentität prüfen

Prüfung Windows Linux macOS
Benutzer [RO] whoami [RO] whoami [RO] whoami
Hostname [RO] hostname [RO] hostname [RO] hostname
Interfaces [RO] Get-NetAdapter [RO] ip -brief link [RO] ifconfig -l
IP-Adressen [RO] Get-NetIPAddress [RO] ip -brief address [RO] ifconfig
Standardroute [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" [RO] ip route show default [RO] route -n get default
DNS-Server [RO] Get-DnsClientServerAddress [RO] resolvectl status [RO] scutil --dns

Diese Informationen helfen zu prüfen, ob die verglichenen Systeme tatsächlich im erwarteten Netzwerk, VLAN oder Benutzerkontext arbeiten.

Empfohlene Reihenfolge der Kreuztests

  1. Betroffenen Benutzer und betroffenes Gerät bestätigen.
  2. Anderen Benutzer am gleichen Gerät testen.
  3. Gleichen Benutzer an anderem Gerät testen.
  4. Gleiches Gerät über anderes Interface testen.
  5. Anderes Gerät am gleichen Port testen.
  6. Gleiches Gerät an geeignetem Vergleichsport testen.
  7. Andere Ziele von gleicher Quelle testen.
  8. Gleiches Ziel von anderer Quelle testen.
  9. IP-Adresse gegen Hostname testen.
  10. Ping gegen tatsächlichen Dienstport testen.
  11. lokalen, internen und entfernten Zugriff vergleichen.
  12. Ergebnisse in einer Betroffen/Nicht-betroffen-Matrix festhalten.

Nicht jeder Fehler benötigt alle Kreuztests. Sobald die Fehlerdomäne eindeutig eingegrenzt ist, wird mit der passenden technischen Detailseite fortgefahren.

Auswertungsmatrix

Beobachtung Wahrscheinliche Fehlerdomäne Passende Folgeseite
Nur ein Benutzer betroffen Konto, Rechte oder Profil Benutzer- und Identitätsdiagnose
Nur ein Gerät betroffen Client, Treiber oder lokale Konfiguration Windows-, Linux- oder macOS-Diagnose
Nur Ethernet betroffen NIC, Kabel, Port oder VLAN Hardware, Switching und VLAN
Nur WLAN betroffen Funk, SSID, Authentifizierung oder WLAN-VLAN WLAN-Diagnose
Nur ein Port betroffen Switchport, Kabelweg oder Portprofil Switching und Verkabelung
Nur ein VLAN betroffen Gateway, DHCP Relay, ACL oder Routing VLAN, DHCP und Routing
Nur ein Standort betroffen WAN, VPN, Firewall oder Provider WAN- und Standortdiagnose
Nur ein Ziel betroffen Zielserver, Dienst oder Rückroute Server- und Dienstdiagnose
Nur ein Port oder Protokoll betroffen Listener oder Firewall TCP-, UDP- und Firewall-Diagnose
IP funktioniert, Hostname nicht DNS DNS-Diagnose
Alle Benutzer und Geräte betroffen zentraler Dienst oder Infrastruktur zentrale Infrastruktur prüfen
Fehler tritt nur zu bestimmten Zeiten auf Last, Job, Wartung oder Timeout Performance- und Zeitdiagnose

Vorlage zur Dokumentation der Kreuztests

Nummer Unveränderte Bedingung Veränderte Bedingung Ergebnis Schlussfolgerung
1
2
3
4
5

Beispiel

Ausgangssituation

CLIENT-01 erhält über Ethernet keine gültige DHCP-Adresse. Über WLAN funktioniert der Netzwerkzugriff.

Kreuztest Ergebnis
Anderer Benutzer an CLIENT-01 über Ethernet ebenfalls betroffen
Ursprünglicher Benutzer an CLIENT-02 funktioniert
CLIENT-01 über WLAN funktioniert
CLIENT-02 am Port von CLIENT-01 erhält ebenfalls keine DHCP-Adresse
CLIENT-01 an geeignetem Vergleichsport erhält gültige DHCP-Adresse

Schlussfolgerung

Der Fehler ist nicht benutzerabhängig und wahrscheinlich nicht durch die allgemeine Clientkonfiguration verursacht.

Die Fehlerdomäne wurde auf folgende Komponenten eingegrenzt:

Die weitere Diagnose erfolgt im Kapitel zu Verkabelung, Switching und VLAN.

Nicht vorschnell verändern

Während der Eingrenzung nicht gleichzeitig:

Zuerst muss festgestellt werden, mit welcher Komponente der Fehler zusammenhängt.

Ergebnis dieser Seite

Nach Abschluss der Kreuztests sollte bekannt sein, ob die Störung wahrscheinlich abhängig ist von:

Die technische Detaildiagnose beginnt anschließend innerhalb der eingegrenzten Fehlerdomäne.

Nächste Seite

1.3 Zeitpunkt und letzte Änderungen untersuchen

Quellen

1. Grundlagen der systematischen Fehleranalyse

1.3 Zeitpunkt und letzte Änderungen untersuchen

1.3 Zeitpunkt und letzte Änderungen untersuchen

Viele Störungen treten kurz nach einer Änderung auf. Deshalb gehört die Frage „Was hat sich verändert?“ zu den wichtigsten Schritten einer systematischen Fehleranalyse.

Dabei gilt jedoch:

Eine zeitliche Übereinstimmung ist ein Hinweis, aber noch kein Beweis für einen ursächlichen Zusammenhang.

Ein Update kurz vor einer Störung kann die Ursache sein. Es kann aber ebenso Zufall sein, während beispielsweise gleichzeitig eine Firewall-Regel, ein VLAN oder ein Zertifikat geändert wurde.

Ziel dieser Seite

Nach diesem Schritt sollten folgende Fragen beantwortet sein:

1. Das Störungszeitfenster bestimmen

Zuerst wird der Zeitraum eingegrenzt, in dem die Ursache wahrscheinlich entstanden ist.

Zeitpunkt Bedeutung Beispiel
Letzter bekannter funktionierender Zustand Funktion wurde erfolgreich verwendet oder geprüft Benutzer meldete sich um 13:50 Uhr erfolgreich an
Erste bekannte Störung Fehler wurde erstmals sicher beobachtet Anmeldung schlug um 14:35 Uhr fehl
Meldezeitpunkt Störung wurde an den Support gemeldet Ticket wurde um 14:47 Uhr erstellt
Beginn der Untersuchung Technische Analyse wurde gestartet Administrator begann um 15:05 Uhr
Störungszeitfenster Zeitraum zwischen „funktioniert“ und „funktioniert nicht“ 13:50 bis 14:35 Uhr

Je kleiner das Störungszeitfenster ist, desto gezielter können Änderungen, Ereignisse und Protokolle durchsucht werden.

Wichtige Unterscheidung

2. Uhrzeit und Zeitzone prüfen

Bevor Ereignisse verschiedener Systeme verglichen werden, müssen Uhrzeit und Zeitzone geprüft werden.

Abweichende Systemzeiten können eine korrekte Ereignisreihenfolge vortäuschen oder verbergen. Besonders relevant ist dies bei:

Aktuelle Uhrzeit anzeigen

Betriebssystem Befehl
Windows PowerShell [RO] Get-Date -Format o
Windows Eingabeaufforderung [RO] echo %date% %time%
Linux [RO] date "+%Y-%m-%d %H:%M:%S %Z"
macOS [RO] date "+%Y-%m-%d %H:%M:%S %Z"

Aktuelle UTC-Zeit anzeigen

Betriebssystem Befehl
Windows PowerShell [RO] (Get-Date).ToUniversalTime().ToString("o")
Linux [RO] date -u "+%Y-%m-%dT%H:%M:%SZ"
macOS [RO] date -u "+%Y-%m-%dT%H:%M:%SZ"

Zeitzone und Zeitsynchronisation prüfen

Betriebssystem Befehl
Windows PowerShell [RO] Get-TimeZone
Windows [RO] w32tm /query /status
Windows [RO] w32tm /query /source
Linux mit systemd [RO] timedatectl status
Linux mit chrony [RO] chronyc tracking
Linux mit chrony [RO] chronyc sources -v
macOS [RO] systemsetup -gettimezone
macOS [RO] sntp -d time.apple.com

[RO] bedeutet „Read-only“. Der Befehl liest Informationen aus und soll keine Konfiguration verändern.

Bei der Dokumentation sollte immer angegeben werden, ob eine Uhrzeit als lokale Zeit oder als UTC-Zeit notiert wurde.

3. Letzten Systemstart bestimmen

Ein Neustart kann eine Störung ausgelöst, beseitigt oder sichtbar gemacht haben. Manche Änderungen werden außerdem erst nach einem Neustart wirksam.

Betriebssystem Befehl
Windows PowerShell [RO] Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime
Windows Eingabeaufforderung [RO] systeminfo
Linux [RO] uptime -s
Linux [RO] who -b
Linux [RO] last reboot
macOS [RO] sysctl -n kern.boottime
macOS [RO] last reboot
Alle Unix-artigen Systeme [RO] uptime

Windows-Betriebsdauer berechnen

[RO] (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime

Typische Schlussfolgerungen

Beobachtung Mögliche Bedeutung
Störung begann direkt nach einem Neustart Dienststart, Treiber, Update, Abhängigkeit oder Startreihenfolge prüfen
System wurde unerwartet neu gestartet Stromversorgung, Absturz, Watchdog, Hypervisor oder automatischer Neustart prüfen
System wurde lange nicht neu gestartet Ausstehende Updates, Ressourcenprobleme oder nicht aktivierte Konfigurationsänderungen prüfen
Fehler verschwindet nach Neustart Flüchtiger Zustand, Ressourcenleck, blockierter Dienst oder fehlerhafter Cache möglich
Fehler erscheint erst nach Neustart Änderung wurde möglicherweise erst beim Systemstart aktiviert

4. Änderungen im Störungszeitfenster sammeln

Folgende Änderungsquellen sollten systematisch geprüft werden:

Bereich Typische Änderungen
Betriebssystem Updates, Neustarts, Treiber, Sicherheitsrichtlinien
Anwendungen Installation, Update, Deinstallation, Konfigurationsänderung
Dienste Start, Stopp, Absturz, Starttyp oder Dienstkonto geändert
Netzwerk VLAN, Routing, Switchport, ACL, Firewall-Regel, NAT
DNS Neuer, gelöschter oder geänderter Eintrag
DHCP Scope, Reservierung, Option, Lease oder Relay geändert
Active Directory Benutzer, Gruppe, Gruppenrichtlinie, Computerobjekt
Berechtigungen NTFS-, Freigabe-, Rollen- oder Cloud-Berechtigung
Zertifikate Ausstellung, Austausch, Ablauf oder Vertrauenskette
Storage Datenträger, LUN, Mount, Berechtigung, Speicherplatz
Virtualisierung Snapshot, Migration, Ressourcen oder virtuelle Netzwerke
Backup Sicherung, Wiederherstellung, Agent- oder Repository-Änderung
Cloud Sicherheitsgruppe, Rolle, Richtlinie, Netzwerk oder Ressource
Automatisierung Skript, geplante Aufgabe, Cronjob, Pipeline
Hardware Austausch, Firmware, Verkabelung oder Portwechsel
Externe Dienste Provider-Störung, Wartung oder geänderte Schnittstelle

5. Ereignisse im relevanten Zeitfenster anzeigen

Für die folgenden Beispiele wird dieses Störungszeitfenster verwendet:

Die Werte müssen an den tatsächlichen Vorfall angepasst werden.

Windows-Ereignisse mit PowerShell durchsuchen

Systemprotokoll innerhalb eines Zeitfensters

[RO] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"}

Anwendungsprotokoll innerhalb eines Zeitfensters

[RO] Get-WinEvent -FilterHashtable @{LogName="Application"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"}

Warnungen und Fehler anzeigen

[RO] Get-WinEvent -FilterHashtable @{LogName="System"; Level=2,3; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message

Level Bedeutung
1 Kritisch
2 Fehler
3 Warnung
4 Information
5 Ausführlich

Ereignisse als übersichtliche Tabelle darstellen

[RO] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Sort-Object TimeCreated | Format-Table TimeCreated, Id, ProviderName, LevelDisplayName -AutoSize

Nicht jeder Fehler erzeugt ein Ereignis der Stufe „Fehler“. Auch Informationsereignisse können wichtige Hinweise auf Dienststarts, Updates oder Konfigurationsänderungen enthalten.

Linux-Ereignisse mit journalctl durchsuchen

Alle Ereignisse innerhalb eines Zeitfensters

[RO] journalctl --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"

Nur Warnungen und schwerwiegendere Meldungen

[RO] journalctl --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" -p warning

Ereignisse eines bestimmten Dienstes

[RO] journalctl -u <Dienstname> --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"

Beispiel für SSH:

[RO] journalctl -u sshd --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"

Ereignisse des aktuellen Systemstarts

[RO] journalctl -b

Ereignisse des vorherigen Systemstarts

[RO] journalctl -b -1

Kernel-Meldungen des aktuellen Systemstarts

[RO] journalctl -k -b

macOS-Ereignisse durchsuchen

Systemprotokoll innerhalb eines Zeitfensters

[RO] log show --start "2026-07-30 14:00:00" --end "2026-07-30 15:00:00" --style compact

Nur Fehler und Störungen

[RO] log show --start "2026-07-30 14:00:00" --end "2026-07-30 15:00:00" --predicate 'messageType == error OR messageType == fault' --style compact

Ereignisse eines bestimmten Prozesses

[RO] log show --start "2026-07-30 14:00:00" --end "2026-07-30 15:00:00" --predicate 'process == "<Prozessname>"' --style compact

Beispiel für den Prozess softwareupdated:

[RO] log show --last 2h --predicate 'process == "softwareupdated"' --style compact

Alternativ können Protokolle über die Anwendung Konsole untersucht werden.

6. Betriebssystem- und Softwareupdates prüfen

Windows

Installierte Hotfixes anzeigen

[RO] Get-HotFix | Sort-Object InstalledOn -Descending

Ausgewählte Informationen darstellen

[RO] Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object InstalledOn, HotFixID, Description, InstalledBy

Windows-Update-Ereignisse anzeigen

[RO] Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" -MaxEvents 100 | Select-Object TimeCreated, Id, LevelDisplayName, Message

Windows-Update-Ereignisse innerhalb eines Zeitfensters

[RO] Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-WindowsUpdateClient/Operational"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"}

Windows-Update-Protokolldatei erzeugen

[RO] Get-WindowsUpdateLog

Das Cmdlet erstellt aus den ETL-Dateien eine lesbare Windows-Update-Protokolldatei.

Grafischer Weg

Einstellungen → Windows Update → Updateverlauf

Get-HotFix zeigt nicht zwingend jede installierte Aktualisierung an. Die Ausgabe sollte deshalb mit dem Windows-Updateverlauf, dem Ereignisprotokoll und gegebenenfalls dem eingesetzten Patchmanagement verglichen werden.

Debian und Ubuntu

APT-Transaktionsverlauf anzeigen

[RO] less /var/log/apt/history.log

DPKG-Aktivitäten anzeigen

[RO] less /var/log/dpkg.log

Installationen, Aktualisierungen und Deinstallationen suchen

[RO] grep -E " install | upgrade | remove " /var/log/dpkg.log

Ältere Protokolle können rotiert und komprimiert vorliegen:

[RO] zgrep -hE " install | upgrade | remove " /var/log/dpkg.log*

Red Hat Enterprise Linux, Rocky Linux, AlmaLinux und Fedora

DNF-Transaktionen anzeigen

[RO] dnf history list

Details einer Transaktion anzeigen

[RO] dnf history info <Transaktions-ID>

Letzte Transaktion untersuchen

[RO] dnf history info last

Installierte Pakete nach Installationszeit sortieren

[RO] rpm -qa --last

SUSE Linux Enterprise und openSUSE

Zypper-Verlauf anzeigen

[RO] less /var/log/zypp/history

Nur Paketinstallationen anzeigen

[RO] grep "|install|" /var/log/zypp/history

Nur Paketaktualisierungen anzeigen

[RO] grep "|update|" /var/log/zypp/history

Arch Linux

Paketmanager-Protokoll anzeigen

[RO] less /var/log/pacman.log

Paketänderungen suchen

[RO] grep -E "\[ALPM\] (installed|upgraded|removed)" /var/log/pacman.log

macOS

Verlauf der Softwareupdates anzeigen

[RO] softwareupdate --history

Installationsverlauf anzeigen

[RO] system_profiler SPInstallHistoryDataType

Grafischer Weg

Systeminformationen → Software → Installationen

Die Liste kann nach dem Installationsdatum sortiert werden.

7. Dienständerungen und Dienstabstürze prüfen

Windows

Besonders interessante Ereignisse des Service Control Managers:

Ereignis-ID Typische Bedeutung
7031 Dienst wurde unerwartet beendet
7034 Dienst wurde unerwartet beendet
7036 Dienst hat seinen Status geändert
7040 Starttyp eines Dienstes wurde geändert
7045 Ein neuer Dienst wurde installiert

Relevante Dienstereignisse abfragen

[RO] Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"; Id=7031,7034,7036,7040,7045; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Select-Object TimeCreated, Id, Message

Aktuellen Zustand eines Dienstes anzeigen

[RO] Get-Service -Name <Dienstname>

Dienstkonfiguration anzeigen

[RO] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object Name, State, StartMode, StartName, PathName

Linux

Status eines Dienstes anzeigen

[RO] systemctl status <Dienstname>

Protokoll eines Dienstes anzeigen

[RO] journalctl -u <Dienstname> --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"

Fehlgeschlagene Dienste anzeigen

[RO] systemctl --failed

Zeitpunkt der Dienstaktivierung anzeigen

[RO] systemctl show <Dienstname> -p ActiveEnterTimestamp -p InactiveEnterTimestamp

macOS

Geladene launchd-Dienste anzeigen

[RO] launchctl list

Nach einem bestimmten Dienst suchen

[RO] launchctl list | grep -i "<Suchbegriff>"

Prozessereignisse untersuchen

[RO] log show --last 2h --predicate 'process == "<Prozessname>"' --style compact

8. Geplante und automatisierte Änderungen prüfen

Nicht jede Änderung wird manuell durch einen Administrator ausgelöst. Häufige Ursachen sind:

Windows

Geplante Aufgaben anzeigen

[RO] Get-ScheduledTask

Laufzeitinformationen anzeigen

[RO] Get-ScheduledTask | Get-ScheduledTaskInfo | Sort-Object LastRunTime -Descending

Aufgaben mit Fehlerergebnis suchen

[RO] Get-ScheduledTask | Get-ScheduledTaskInfo | Where-Object {$_.LastTaskResult -ne 0}

Task-Scheduler-Ereignisse anzeigen

[RO] Get-WinEvent -LogName "Microsoft-Windows-TaskScheduler/Operational" -MaxEvents 100

Ein von 0 abweichender Rückgabewert ist ein Hinweis, muss aber anhand der jeweiligen Aufgabe interpretiert werden.

Linux

Systemd-Timer anzeigen

[RO] systemctl list-timers --all

Cronjobs des aktuellen Benutzers anzeigen

[RO] crontab -l

Systemweite Cron-Verzeichnisse prüfen

[RO] ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly

Cron-Ereignisse auf Debian und Ubuntu suchen

[RO] journalctl -u cron --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"

Cron-Ereignisse auf RHEL-kompatiblen Systemen suchen

[RO] journalctl -u crond --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"

macOS

Geladene launchd-Aufträge anzeigen

[RO] launchctl list

Systemweite LaunchDaemons anzeigen

[RO] ls -la /Library/LaunchDaemons

Systemweite LaunchAgents anzeigen

[RO] ls -la /Library/LaunchAgents

Benutzerspezifische LaunchAgents anzeigen

[RO] ls -la ~/Library/LaunchAgents

9. Konfigurationsänderungen vergleichen

Wenn eine frühere Konfigurationsversion vorhanden ist, sollte sie mit dem aktuellen Zustand verglichen werden.

Windows PowerShell

[RO] Compare-Object (Get-Content "<Vorherige-Datei>") (Get-Content "<Aktuelle-Datei>")

Linux und macOS

[RO] diff -u "<Vorherige-Datei>" "<Aktuelle-Datei>"

Git-verwaltete Konfigurationen

[RO] git status

[RO] git diff

[RO] git log --oneline --decorate -n 20

[RO] git log -p -- "<Datei>"

Mögliche Quellen früherer Konfigurationen

Der aktuelle Zustand zeigt nur, wie das System jetzt konfiguriert ist. Ohne Auditierung, Versionsverwaltung oder Backup lässt sich daraus nicht zuverlässig ableiten, wann und durch wen eine Änderung vorgenommen wurde.

10. Änderungen an Netzwerkkomponenten prüfen

Bei Netzwerkstörungen sollten nicht nur Server und Clients betrachtet werden.

Komponente Zu prüfende Änderungen
Switch Portstatus, VLAN, Trunk, Port-Security, STP, Firmware
Router Routing, Interface, NAT, ACL, dynamisches Routing
Firewall Regelwerk, NAT, VPN, Objektgruppen, Zertifikate
WLAN-Controller SSID, VLAN-Zuordnung, Authentifizierung, Funkkanal
DHCP-Server Scope, Optionen, Reservierungen, Relay
DNS-Server Einträge, Zonen, Weiterleitungen, Replikation
Load Balancer Backend, Health Check, Zertifikat, Listener
Proxy Ausnahmen, Authentifizierung, Zertifikat, Filterregel
NAC-System Richtlinie, Geräteprofil, Quarantäne
Provider Wartung, Routingänderung, Störung

Zu verwendende Informationsquellen

Besonders wichtige Angaben

11. Active Directory und Gruppenrichtlinien prüfen

Mögliche relevante Änderungen:

Windows-Sicherheitsprotokoll nach Änderungen durchsuchen

[RO] Get-WinEvent -FilterHashtable @{LogName="Security"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Select-Object TimeCreated, Id, Message

Der Zugriff auf das Sicherheitsprotokoll benötigt entsprechende Berechtigungen.

Resultierende Gruppenrichtlinien anzeigen

[RO] gpresult /r

Ausführlichen HTML-Bericht erstellen

[RO] gpresult /h "<Zielpfad>\gpresult.html"

Das Erstellen der HTML-Datei ist keine reine Leseoperation, verändert aber keine Systemkonfiguration. Es wird lediglich eine Berichtsdatei geschrieben.

Zeitpunkt der letzten Richtlinienverarbeitung prüfen

[RO] Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 100

Für eine zuverlässige Nachverfolgung von Änderungen müssen die passenden Überwachungsrichtlinien bereits vor dem Vorfall aktiviert worden sein.

12. Cloud- und SaaS-Änderungen prüfen

Je nach Umgebung sind unter anderem folgende Protokolle relevant:

Plattform Typische Quelle
Microsoft Entra ID Überwachungsprotokolle und Anmeldeprotokolle
Microsoft 365 Einheitliches Überwachungsprotokoll
Microsoft Azure Activity Log und Resource Logs
Amazon Web Services AWS CloudTrail
Google Cloud Cloud Audit Logs
VMware vCenter Tasks und Events
Proxmox VE Task History und Systemprotokoll
Backup-System Job-, Audit- und Konfigurationsverlauf
Endpoint-Management Geräte-, Richtlinien- und Bereitstellungsverlauf
Softwareverteilung Deployment- und Installationsstatus

Zu prüfen sind insbesondere:

13. Zeitachse erstellen

Alle relevanten Ereignisse werden in einer gemeinsamen Zeitachse dokumentiert.

Zeit Quelle oder System Ereignis oder Änderung Benutzer oder Prozess Beleg Bewertung
13:50 Client-PC Anmeldung erfolgreich Max Mustermann Benutzerangabe Letzter funktionierender Zustand
14:10 Windows Server Sicherheitsupdate installiert Patchmanagement Updateverlauf Zeitlich auffällig
14:31 Switch Port in anderes VLAN verschoben Admin-Konto Auditprotokoll Technisch passend
14:35 Client-PC Anmeldung nicht mehr möglich Max Mustermann Ticket und Ereignisprotokoll Erste bekannte Störung
14:42 Monitoring Domänencontroller weiterhin erreichbar Monitoring-System Messwert Serverausfall unwahrscheinlich
15:12 Testport Anmeldung funktioniert Testbenutzer Kreuztest Switchport als Fehlerbereich bestätigt

Dieses Beispiel zeigt:

14. Änderungen bewerten

Nicht jede gefundene Änderung besitzt dieselbe Bedeutung.

Kriterium Frage
Zeitliche Nähe Liegt die Änderung kurz vor dem ersten Fehler?
Technische Plausibilität Kann die Änderung genau dieses Fehlerbild verursachen?
Betroffener Umfang Entspricht der Änderungsumfang den betroffenen Benutzern oder Systemen?
Reproduzierbarkeit Tritt der Fehler nach der Änderung zuverlässig auf?
Gegenprobe Funktioniert es ohne die Änderung oder auf einem unveränderten Vergleichssystem?
Protokollbeleg Gibt es passende Fehler, Warnungen oder Statusänderungen?
Abhängigkeiten Betrifft die Änderung einen abhängigen Dienst oder ein vorgelagertes System?
Vergleichswerte Funktionieren nicht geänderte Systeme weiterhin?
Bekanntes Problem Ist das Verhalten vom Hersteller dokumentiert?

Praktische Priorisierung

Bewertung Bedeutung
Hoch Änderung liegt im Zeitfenster, passt technisch und wird durch Tests gestützt
Mittel Änderung liegt im Zeitfenster und ist technisch möglich, aber noch nicht bestätigt
Niedrig Änderung liegt nur zeitlich nahe, passt aber kaum zum Fehlerbild
Ausgeschlossen Gegenprobe oder Messung widerlegt den Zusammenhang

15. Korrelation und Ursache unterscheiden

Nur Korrelation

Wahrscheinlicher ursächlicher Zusammenhang

Die stärkste Bestätigung entsteht durch einen kontrollierten A/B-Test:

Zustand A Zustand B Schlussfolgerung
Änderung vorhanden, Fehler vorhanden Änderung entfernt, Fehler verschwunden Zusammenhang wahrscheinlich
Änderung vorhanden, Fehler vorhanden Änderung entfernt, Fehler bleibt Änderung vermutlich nicht ursächlich
Geändertes System gestört Unverändertes Vergleichssystem funktioniert Änderung oder Systemunterschied priorisieren
Beide Systeme gestört Gemeinsame Abhängigkeit untersuchen Lokale Änderung weniger wahrscheinlich

16. Vor einem Rollback beachten

Eine Änderung darf nicht allein aufgrund zeitlicher Nähe unüberlegt zurückgenommen werden.

Vor einem Rollback sollten folgende Punkte geklärt sein:

Sicheres Vorgehen

  1. Aktuellen Zustand dokumentieren.
  2. Relevante Protokolle und Konfigurationen sichern.
  3. Rollback-Auswirkungen bewerten.
  4. Freigabe einholen.
  5. Möglichst nur eine Änderung zurücknehmen.
  6. Den ursprünglichen Fehler erneut testen.
  7. Abhängige Funktionen prüfen.
  8. Ergebnis und Uhrzeit dokumentieren.
  9. System anschließend weiter beobachten.

Ein Rollback ist selbst eine Änderung und kann neue Störungen verursachen.

17. Häufige Fehler bei der Änderungsanalyse

Fehler Folge Besseres Vorgehen
Erstbeste Änderung wird beschuldigt Falsche Ursache wird verfolgt Technische Plausibilität und Gegenprobe prüfen
Nur der Server wird untersucht Netzwerk-, Client- oder Cloud-Änderung bleibt unentdeckt Gesamten Kommunikationsweg betrachten
Uhrzeiten werden ungeprüft verglichen Falsche Ereignisreihenfolge Uhrzeit, Zeitzone und Synchronisation prüfen
Nur Fehlerereignisse werden gelesen Wichtige Informationsereignisse fehlen Auch Starts, Stopps und Statusänderungen prüfen
Aktueller Zustand wird als Verlauf interpretiert Zeitpunkt und Urheber bleiben unbekannt Audit-, Versions- und Änderungsprotokolle verwenden
Mehrere Änderungen werden gleichzeitig zurückgenommen Ursache kann nicht mehr zugeordnet werden Möglichst eine Variable pro Test verändern
Protokolle werden erst nach Neustart gesichert Flüchtige Informationen gehen verloren Beweise vor Änderungen und Neustarts sichern
Benutzerangabe wird als exakter Fehlerbeginn behandelt Suchzeitraum wird zu eng gewählt Letzten sicheren Funktionstest und erste sichere Störung trennen
Nur geplante Änderungen werden geprüft Automatische oder unautorisierte Änderung fehlt Audit-, Deployment- und Automationsprotokolle einbeziehen
Provider oder SaaS wird vergessen Externe Störung bleibt unberücksichtigt Service Health und Anbieterstatus prüfen

18. Dokumentationsvorlage

Feld Eintrag
Letzter bekannter funktionierender Zustand
Quelle dieser Information
Erste bekannte Störung
Quelle dieser Information
Verwendete Zeitzone
Zeitabweichungen festgestellt Ja / Nein
Letzter Systemstart
Änderungen im Zeitfenster
Verantwortlicher Benutzer oder Prozess
Zugehöriges Change-Ticket
Technische Plausibilität Hoch / Mittel / Niedrig
Protokollbeleg vorhanden Ja / Nein
Vergleichssystem geprüft Ja / Nein
Gegenprobe durchgeführt Ja / Nein
Rollback durchgeführt Ja / Nein
Ergebnis
Vermutete Ursache
Ursache bestätigt Ja / Nein
Noch offene Prüfungen

Kurzcheckliste

Ergebnis dieses Arbeitsschrittes

Am Ende sollte eine nachvollziehbare Zeitachse vorliegen. Darin stehen der letzte funktionierende Zustand, der erste bekannte Fehler und alle technisch relevanten Änderungen dazwischen.

Eine Änderung gilt erst dann als wahrscheinliche Ursache, wenn sie:

Nächste Seite:
1.4 Flüchtige Informationen und Beweise sichern

Quellen und weiterführende Dokumentation

1. Grundlagen der systematischen Fehleranalyse

1.4 Flüchtige Informationen und Beweise sichern

1.4 Flüchtige Informationen und Beweise sichern

Bei einer Störung ist der erste Impuls häufig:

Diese Maßnahmen können die Funktion wiederherstellen. Gleichzeitig können sie jedoch genau die Informationen vernichten, die zur Ermittlung der Ursache benötigt werden.

Deshalb gilt:

Erst den aktuellen Zustand sichern, danach kontrolliert verändern.

Ein Neustart beseitigt unter anderem laufende Prozesse, bestehende Netzwerkverbindungen, Speicherinhalte, temporäre Zustände und Teile von Caches. Die Störung kann anschließend verschwunden sein, ohne dass ihre Ursache bekannt ist.

Ziel dieser Seite

Nach diesem Arbeitsschritt sollten:

1. Das Stop–Sichern–Ändern-Prinzip

Phase Tätigkeit
Stop Nicht sofort neu starten, zurücksetzen oder bereinigen
Sichern Flüchtige Zustände, Fehlermeldungen und Protokolle erfassen
Bewerten Dringlichkeit und mögliches Sicherheitsrisiko beurteilen
Ändern Eine kontrollierte Maßnahme durchführen
Prüfen Ursprünglichen Fehler erneut testen
Dokumentieren Maßnahme, Zeitpunkt und Ergebnis festhalten

Dieses Vorgehen verhindert, dass eine erfolgreiche Sofortmaßnahme die spätere Ursachenanalyse unmöglich macht.

2. Was sind flüchtige Informationen?

Flüchtige Informationen verändern sich während des laufenden Betriebs oder gehen beim Neustart verloren.

Information Warum flüchtig?
Arbeitsspeicher Inhalt geht beim Ausschalten oder Neustart verloren
Laufende Prozesse Werden beendet und beim Start möglicherweise anders aufgebaut
Prozess-IDs Werden nach einem Neustart oder Prozessstart neu vergeben
Netzwerkverbindungen TCP-Sitzungen und temporäre Verbindungen werden beendet
Offene Dateien Zuordnung zwischen Prozess und Datei geht verloren
ARP-/Neighbor-Cache Wird automatisch aktualisiert oder beim Neustart geleert
DNS-Cache Einträge laufen ab oder werden geleert
Routingzustand Dynamische Routen können sich verändern
Angemeldete Benutzer Sitzungen werden beendet
Temporäre Dateien Können automatisch entfernt werden
Zwischenspeicher Ändern sich durch normalen Betrieb
Auslastungswerte CPU-, RAM-, Datenträger- und Netzwerklast ändern sich fortlaufend
Live-Protokollmeldungen Können durch Logrotation oder begrenzte Speichergröße verschwinden
Fehlermeldung auf dem Bildschirm Verschwindet nach Schließen der Anwendung
Zustand eines hängenden Prozesses Geht beim Beenden oder Neustart verloren

3. Reihenfolge nach Flüchtigkeit

RFC 3227 empfiehlt, Beweise grundsätzlich von den flüchtigsten zu den weniger flüchtigen Informationen zu sichern.

Für die praktische Störungsanalyse kann folgende Reihenfolge verwendet werden:

Priorität Zu sichernde Information Beispiel
1 Sichtbare Fehlermeldung und Uhrzeit Screenshot, Fehlercode, betroffene Funktion
2 Laufende Prozesse und Arbeitsspeicherzustand Prozessliste, CPU- und RAM-Auslastung
3 Aktive Netzwerkverbindungen TCP-/UDP-Verbindungen, Quell- und Zieladressen
4 Temporäre Netzwerkinformationen ARP-, Neighbor- und DNS-Cache
5 Angemeldete Benutzer und Sitzungen Lokale, RDP-, SSH- oder Konsolensitzungen
6 Dienst- und Anwendungszustand Laufende, gestoppte oder fehlgeschlagene Dienste
7 Aktuelle System- und Kernelmeldungen Ereignisanzeige, Journal, Unified Log
8 Temporäre Dateien und Laufzeitdaten PID-Dateien, Sockets, temporäre Verzeichnisse
9 Permanente Protokolle und Konfigurationen Logdateien, Registry, Konfigurationsdateien
10 Zentrale und externe Daten SIEM, Monitoring, Firewall, Cloud-Audit
11 Backups und Archivdaten ältere Konfigurationen, Images, Sicherungen

Die konkrete Reihenfolge muss an den Vorfall angepasst werden. Bei einer laufenden Verschlüsselung oder Datenübertragung kann die Eindämmung wichtiger sein als eine vollständige Sammlung.

4. Normale Störung oder möglicher Sicherheitsvorfall?

Vor der Sammlung muss grob eingeschätzt werden, ob es sich um einen normalen technischen Fehler oder einen möglichen Sicherheitsvorfall handelt.

Normale technische Störung Möglicher Sicherheitsvorfall
Dienst reagiert nicht Unbekannter oder verdächtiger Prozess
Festplatte ist voll Viele Dateien werden unerwartet verschlüsselt
DNS-Eintrag ist falsch Unbekannte externe Netzwerkverbindungen
Update verursacht Kompatibilitätsfehler Sicherheitssoftware meldet Schadsoftware
Anwendung ist abgestürzt Neue unbekannte Administratorkonten
Netzwerkkabel ist defekt Protokolle wurden gelöscht oder deaktiviert
Berechtigung wurde falsch gesetzt Massenhafte fehlgeschlagene Anmeldungen
Zertifikat ist abgelaufen Daten werden unerwartet nach außen übertragen
Systemressourcen sind ausgelastet Sicherheitsrichtlinien wurden unerlaubt verändert
Konfiguration ist fehlerhaft Ransomware-Nachricht oder Erpressung

Bei einer normalen Störung

Bei einem möglichen Sicherheitsvorfall

Bei laufender Verschlüsselung, aktiver Ausbreitung oder möglichem Datenabfluss kann eine schnelle Netzwerkisolation erforderlich sein. Die Entscheidung sollte nach dem Incident-Response-Plan und durch die zuständige Stelle erfolgen. Die Beweissicherung darf eine notwendige Eindämmung nicht gefährlich verzögern.

5. Was vor der Sicherung vermieden werden sollte

Maßnahme Möglicher Informationsverlust
Computer neu starten Prozesse, Arbeitsspeicher und Verbindungen gehen verloren
Dienst neu starten ursprünglicher Dienstzustand und Prozess-ID gehen verloren
Anwendung schließen Fehlermeldung und Prozesszustand verschwinden
Prozess beenden offene Dateien, Verbindungen und Speicherzustand gehen verloren
ipconfig /flushdns ausführen Windows-DNS-Cache wird geleert
ARP- oder Neighbor-Cache leeren Zuordnung zwischen IP- und MAC-Adressen geht verloren
Protokolle leeren Ereignisse werden dauerhaft entfernt
Datenträgerbereinigung starten temporäre Dateien und mögliche Belege verschwinden
Update installieren Ausgangszustand wird verändert
Konfiguration zurücksetzen fehlerverursachende Einstellung ist nicht mehr nachvollziehbar
Snapshot zurückspielen aktueller Systemzustand wird überschrieben
Sicherheitssoftware vollständig scannen lassen Dateien können verändert, verschoben oder gelöscht werden
Diagnosewerkzeuge unkontrolliert installieren Systemzustand und Zeitstempel verändern sich
Kabel sofort abziehen Netzwerkzustand und Verbindungen gehen verloren
Browser oder Anwendung neu laden Sitzung, Cache und Fehlermeldung können verändert werden

Diese Maßnahmen sind nicht grundsätzlich falsch. Sie sollten nur möglichst erst nach der Sicherung des relevanten Ausgangszustands erfolgen.

6. Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] Liest Informationen aus und soll keine Konfiguration verändern
[FILE] Erstellt oder überschreibt eine Ausgabedatei
[PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte
[ACTIVE] Startet eine aktive Messung oder Aufzeichnung
[SENSITIV] Ausgabe kann vertrauliche oder personenbezogene Daten enthalten

Auch ein [RO]-Befehl erzeugt einen Prozess und kann Spuren in Protokollen, Shell-Historien oder Zugriffsdaten hinterlassen. Für eine normale Störungsdiagnose ist das meist vertretbar. Bei einer forensischen Untersuchung müssen die freigegebenen Werkzeuge und Verfahren der Organisation verwendet werden.

7. Fehlermeldung vollständig sichern

Folgende Informationen sollten erfasst werden:

Guter Screenshot

Ein guter Screenshot zeigt:

Ein zu stark zugeschnittener Screenshot kann wichtige Informationen wie Anwendung, Zielsystem oder Zeitpunkt entfernen.

Bei einem möglichen Sicherheitsvorfall

Wenn jede Interaktion mit dem System vermieden werden soll, kann der Bildschirm mit einem zweiten Gerät fotografiert werden. Dabei sind Datenschutz- und Unternehmensrichtlinien zu beachten.

8. Aktuellen Zeitpunkt zuerst dokumentieren

Windows

[RO] Get-Date -Format o

[RO] (Get-Date).ToUniversalTime().ToString("o")

[RO] Get-TimeZone

[RO] w32tm /query /status

Linux

[RO] date --iso-8601=seconds

[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"

[RO] timedatectl status

macOS

[RO] date "+%Y-%m-%dT%H:%M:%S%z"

[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"

[RO] systemsetup -gettimezone

Die Zeitprüfung ist wichtig, damit lokale Systemereignisse mit Firewall-, Server-, Cloud- und Monitoring-Protokollen verglichen werden können.

9. Grundzustand des Systems erfassen

Windows

Information Befehl
Hostname [RO] hostname
Betriebssystem [RO] Get-ComputerInfo
Windows-Version kompakt [RO] Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, BuildNumber, LastBootUpTime
Betriebsdauer [RO] (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
Aktueller Benutzer [RO] whoami
Benutzer und Gruppen [RO][SENSITIV] whoami /all
Angemeldete Sitzungen [RO] quser
Umgebungsvariablen [RO][SENSITIV] Get-ChildItem Env:
Laufwerke [RO] Get-Volume
Datenträgerbelegung [RO] Get-PSDrive -PSProvider FileSystem

Umgebungsvariablen können Token, Zugangsdaten, interne Pfade oder andere vertrauliche Werte enthalten. Sie sollten nur erfasst werden, wenn sie für die Störung relevant sind.

Linux

Information Befehl
Hostname und System [RO] hostnamectl
Kernel und Architektur [RO] uname -a
Distribution [RO] cat /etc/os-release
Betriebsdauer [RO] uptime
Letzter Systemstart [RO] uptime -s
Angemeldete Benutzer [RO] who -a
Benutzeraktivität [RO] w
Aktueller Benutzer [RO] id
Dateisystembelegung [RO] df -hT
Blockgeräte [RO] lsblk -f
Arbeitsspeicher [RO] free -h

macOS

Information Befehl
Hostname [RO] hostname
macOS-Version [RO] sw_vers
Kernel und Architektur [RO] uname -a
Systemübersicht [RO] system_profiler SPSoftwareDataType SPHardwareDataType
Betriebsdauer [RO] uptime
Letzter Systemstart [RO] sysctl -n kern.boottime
Angemeldete Benutzer [RO] who
Aktueller Benutzer [RO] id
Dateisystembelegung [RO] df -h
Arbeitsspeicher [RO] vm_stat

10. Laufende Prozesse sichern

Eine Prozessliste sollte möglichst vor dem Beenden oder Neustarten einer Anwendung erfasst werden.

Windows PowerShell

Prozessübersicht

[RO] Get-Process | Sort-Object CPU -Descending

Prozess, übergeordneter Prozess und Befehlszeile

[RO][SENSITIV] Get-CimInstance Win32_Process | Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine

Prozess anhand der Prozess-ID untersuchen

[RO] Get-Process -Id <PID> | Format-List *

Prozesse mit hoher Speichernutzung

[RO] Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 20 Name, Id, CPU, WorkingSet64

Linux

Vollständige Prozessliste

[RO][SENSITIV] ps auxww

Prozessbaum

[RO][SENSITIV] ps -ef --forest

Prozesse nach CPU-Auslastung

[RO] ps aux --sort=-%cpu | head -n 20

Prozesse nach Speichernutzung

[RO] ps aux --sort=-%mem | head -n 20

Aktuellen Systemzustand einmalig ausgeben

[RO] top -b -n 1

Offene Dateien eines Prozesses

[RO][PRIV][SENSITIV] lsof -p <PID>

macOS

Vollständige Prozessliste

[RO][SENSITIV] ps auxww

Prozesse nach CPU-Auslastung

[RO] top -l 1 -o cpu

Prozesse nach Speichernutzung

[RO] top -l 1 -o mem

Offene Dateien eines Prozesses

[RO][PRIV][SENSITIV] lsof -p <PID>

11. Aktive Netzwerkverbindungen sichern

Netzwerkverbindungen sollten vor dem Beenden eines Prozesses, dem Trennen des Netzwerks oder einem Neustart gesichert werden.

Windows

TCP-Verbindungen

[RO][PRIV] Get-NetTCPConnection

TCP-Verbindungen mit zugehörigem Prozess

[RO][PRIV] Get-NetTCPConnection | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess

UDP-Endpunkte

[RO][PRIV] Get-NetUDPEndpoint

Klassische Übersicht

[RO][PRIV] netstat -ano

Die letzte Spalte enthält unter Windows die Prozess-ID.

Prozess zu einer PID ermitteln

[RO] Get-Process -Id <PID>

Linux

TCP-, UDP- und lauschende Sockets

[RO][PRIV] ss -tulpn

Alle TCP-Verbindungen

[RO][PRIV] ss -tanp

Alle UDP-Endpunkte

[RO][PRIV] ss -uanp

Prozesse mit Netzwerkverbindungen

[RO][PRIV][SENSITIV] lsof -nP -i

Ohne Root-Rechte werden möglicherweise nicht alle Prozessinformationen angezeigt.

macOS

Aktive TCP-Verbindungen

[RO] netstat -anv -p tcp

UDP-Endpunkte

[RO] netstat -anv -p udp

Lauschende TCP-Prozesse

[RO][PRIV] lsof -nP -iTCP -sTCP:LISTEN

Bestehende TCP-Verbindungen

[RO][PRIV] lsof -nP -iTCP -sTCP:ESTABLISHED

12. Netzwerkkonfiguration und Caches sichern

Windows

Information Befehl
Vollständige IP-Konfiguration [RO] ipconfig /all
PowerShell-Netzwerkübersicht [RO] Get-NetIPConfiguration
Routingtabelle [RO] route print
PowerShell-Routen [RO] Get-NetRoute
ARP-/Neighbor-Cache [RO] arp -a
PowerShell-Neighbor-Tabelle [RO] Get-NetNeighbor
DNS-Cache [RO][SENSITIV] ipconfig /displaydns
PowerShell-DNS-Cache [RO][SENSITIV] Get-DnsClientCache
Proxykonfiguration [RO] netsh winhttp show proxy

Linux

Information Befehl
IP-Adressen und Interfaces [RO] ip -details address show
Linkzustand [RO] ip -details link show
Alle Routingtabellen [RO] ip route show table all
IPv6-Routen [RO] ip -6 route show table all
Neighbor-Tabelle [RO] ip neigh show
Resolverzustand [RO] resolvectl status
DNS-Konfiguration [RO] cat /etc/resolv.conf
NetworkManager-Verbindungen [RO][SENSITIV] nmcli connection show
NetworkManager-Geräte [RO] nmcli device status

resolvectl ist nur vorhanden, wenn die entsprechende systemd-Komponente verwendet wird.

macOS

Information Befehl
Interfaces und IP-Adressen [RO] ifconfig -a
Routingtabelle [RO] netstat -rn
Standardroute [RO] route -n get default
ARP-Cache [RO] arp -an
DNS-Konfiguration [RO][SENSITIV] scutil --dns
Netzwerkdienste [RO] networksetup -listallnetworkservices
Hardwareports [RO] networksetup -listallhardwareports
Proxykonfiguration [RO] scutil --proxy

13. Dienstzustand sichern

Windows

Alle Dienste anzeigen

[RO] Get-Service | Sort-Object Status, Name

Detaillierte Dienstinformationen

[RO][SENSITIV] Get-CimInstance Win32_Service | Select-Object Name, State, StartMode, StartName, ProcessId, PathName

Nur beendete automatisch startende Dienste

[RO] Get-CimInstance Win32_Service | Where-Object {$_.StartMode -eq "Auto" -and $_.State -ne "Running"} | Select-Object Name, State, StartMode

Linux

Fehlgeschlagene Dienste

[RO] systemctl --failed

Laufende Dienste

[RO] systemctl list-units --type=service --state=running

Alle installierten Diensteinheiten

[RO] systemctl list-unit-files --type=service

Bestimmten Dienst untersuchen

[RO] systemctl status <Dienstname> --no-pager

macOS

Geladene launchd-Dienste

[RO] launchctl list

Nach einem Dienst suchen

[RO] launchctl list | grep -i "<Suchbegriff>"

14. Ressourcen- und Datenträgerzustand sichern

Windows

Information Befehl
Laufwerke und freier Speicher [RO] Get-Volume
Dateisystemlaufwerke [RO] Get-PSDrive -PSProvider FileSystem
Speicherauslastung pro Prozess [RO] Get-Process | Sort-Object WorkingSet64 -Descending
Datenträgerstatus [RO] Get-PhysicalDisk
Ereignisse zu Datenträgern [RO] Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="disk"} -MaxEvents 50

Linux

Information Befehl
Arbeitsspeicher [RO] free -h
Dateisystembelegung [RO] df -hT
Inode-Belegung [RO] df -ih
Blockgeräte [RO] lsblk -f
Mounts [RO] findmnt
Kernelmeldungen [RO][PRIV] dmesg --ctime
Laufende I/O-Statistik [RO][ACTIVE] iostat -xz 1 5

iostat ist nicht auf jeder Installation vorhanden und gehört üblicherweise zum Paket sysstat.

macOS

Information Befehl
Arbeitsspeicherstatistik [RO] vm_stat
Dateisystembelegung [RO] df -h
Laufwerke und Partitionen [RO] diskutil list
Datenträgerinformationen [RO] diskutil info <Datenträger>
Laufende I/O-Statistik [RO][ACTIVE] iostat -w 1 -c 5

15. Protokolle exportieren

Protokolle sollten möglichst in ihrem nativen Format gesichert werden. Dadurch bleiben zusätzliche Felder, Ereigniskennungen und Metadaten erhalten.

Windows-Ereignisprotokolle exportieren

Zuerst muss ein neuer und freigegebener Zielordner angelegt werden.

[FILE] $target = Join-Path "<Zielpfad>" "$env:COMPUTERNAME-$(Get-Date -Format 'yyyyMMdd-HHmmss')"

[FILE] New-Item -ItemType Directory -Path $target

Systemprotokoll exportieren

[FILE][PRIV] wevtutil epl System "$target\System.evtx"

Anwendungsprotokoll exportieren

[FILE][PRIV] wevtutil epl Application "$target\Application.evtx"

Sicherheitsprotokoll exportieren

[FILE][PRIV][SENSITIV] wevtutil epl Security "$target\Security.evtx"

PowerShell-Protokoll exportieren

[FILE][PRIV][SENSITIV] wevtutil epl "Microsoft-Windows-PowerShell/Operational" "$target\PowerShell-Operational.evtx"

Ereignisse nur aus einem bestimmten Zeitfenster als CSV sichern

[FILE] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message | Export-Csv "$target\System-Zeitfenster.csv" -NoTypeInformation -Encoding UTF8

Das Sicherheitsprotokoll kann personenbezogene und sicherheitsrelevante Informationen enthalten und benötigt normalerweise erhöhte Berechtigungen.

Linux-Journal exportieren

Aktuellen Systemstart sichern

[FILE] journalctl -b --no-pager --output=short-iso-precise > "<Zielpfad>/journal-current-boot.log"

Vorherigen Systemstart sichern

[FILE] journalctl -b -1 --no-pager --output=short-iso-precise > "<Zielpfad>/journal-previous-boot.log"

Bestimmtes Zeitfenster sichern

[FILE] journalctl --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" --no-pager --output=short-iso-precise > "<Zielpfad>/journal-time-window.log"

Kernelmeldungen sichern

[FILE][PRIV] dmesg --ctime > "<Zielpfad>/dmesg.log"

Dienstprotokoll sichern

[FILE] journalctl -u <Dienstname> --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" --no-pager --output=short-iso-precise > "<Zielpfad>/<Dienstname>.log"

Die Umleitung mit > erstellt eine Datei oder überschreibt eine vorhandene Datei. Deshalb sollte immer ein neuer Zielordner verwendet werden.

macOS-Protokolle exportieren

Letzte Stunde als Text sichern

[FILE][SENSITIV] log show --last 1h --style compact > "<Zielpfad>/macOS-unified-log.txt"

Bestimmtes Zeitfenster sichern

[FILE][SENSITIV] log show --start "2026-07-30 14:00:00" --end "2026-07-30 15:00:00" --style compact > "<Zielpfad>/macOS-time-window.log"

Nur Fehler und Faults sichern

[FILE][SENSITIV] log show --last 1h --predicate 'messageType == error OR messageType == fault' --style compact > "<Zielpfad>/macOS-errors.log"

Systemdiagnose über die Oberfläche erstellen

Aktivitätsanzeige → Weitere Optionen → Systemdiagnose

Apple beschreibt diese Funktion als Möglichkeit, einen Diagnosebericht mit Informationen und Protokollen über den Mac zu erstellen.

Ein Systemdiagnosebericht kann umfangreiche und vertrauliche Informationen enthalten. Er darf nur an freigegebenen Speicherorten abgelegt und an berechtigte Empfänger weitergegeben werden.

16. Kompakte Windows-Diagnosesammlung

Das folgende Beispiel erstellt einen neuen Diagnoseordner und schreibt den aktuellen Zustand in einzelne Dateien.

<Zielpfad> muss vorher durch einen freigegebenen Speicherort ersetzt werden.

$target = Join-Path "<Zielpfad>" "$env:COMPUTERNAME-$(Get-Date -Format 'yyyyMMdd-HHmmss')"
New-Item -ItemType Directory -Path $target

Get-Date -Format o |
    Out-File "$target\collection-start.txt" -Encoding utf8

Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, BuildNumber, LastBootUpTime |
    Format-List |
    Out-File "$target\operating-system.txt" -Encoding utf8

Get-CimInstance Win32_Process |
    Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine |
    Export-Csv "$target\processes.csv" -NoTypeInformation -Encoding utf8

Get-Service |
    Sort-Object Status, Name |
    Export-Csv "$target\services.csv" -NoTypeInformation -Encoding utf8

Get-NetTCPConnection |
    Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess |
    Export-Csv "$target\tcp-connections.csv" -NoTypeInformation -Encoding utf8

Get-NetUDPEndpoint |
    Export-Csv "$target\udp-endpoints.csv" -NoTypeInformation -Encoding utf8

ipconfig /all |
    Out-File "$target\ipconfig-all.txt" -Encoding utf8

route print |
    Out-File "$target\routes.txt" -Encoding utf8

arp -a |
    Out-File "$target\arp-cache.txt" -Encoding utf8

ipconfig /displaydns |
    Out-File "$target\dns-cache.txt" -Encoding utf8

Get-Volume |
    Format-List |
    Out-File "$target\volumes.txt" -Encoding utf8

wevtutil epl System "$target\System.evtx"
wevtutil epl Application "$target\Application.evtx"

Get-Date -Format o |
    Out-File "$target\collection-end.txt" -Encoding utf8

Hinweise

17. Kompakte Linux-Diagnosesammlung

<Zielpfad> muss durch einen freigegebenen Speicherort ersetzt werden.

case_dir="<Zielpfad>/$(hostname)-$(date +%Y%m%d-%H%M%S)"
mkdir -p -- "$case_dir"

date --iso-8601=seconds > "$case_dir/collection-start.txt"
uname -a > "$case_dir/kernel.txt"
cat /etc/os-release > "$case_dir/os-release.txt"
uptime > "$case_dir/uptime.txt"
who -a > "$case_dir/logged-in-users.txt"
ps auxww > "$case_dir/processes.txt"
ss -tulpn > "$case_dir/network-sockets.txt" 2>&1
ip -details address show > "$case_dir/ip-addresses.txt"
ip route show table all > "$case_dir/routes.txt"
ip neigh show > "$case_dir/neighbors.txt"
resolvectl status > "$case_dir/dns-status.txt" 2>&1
systemctl --failed --no-pager > "$case_dir/failed-services.txt"
free -h > "$case_dir/memory.txt"
df -hT > "$case_dir/filesystems.txt"
df -ih > "$case_dir/inodes.txt"
lsblk -f > "$case_dir/block-devices.txt"
journalctl -b --no-pager --output=short-iso-precise > "$case_dir/journal-current-boot.log"
dmesg --ctime > "$case_dir/dmesg.log" 2>&1
date --iso-8601=seconds > "$case_dir/collection-end.txt"

Hinweise

18. Kompakte macOS-Diagnosesammlung

<Zielpfad> muss durch einen freigegebenen Speicherort ersetzt werden.

case_dir="<Zielpfad>/$(hostname)-$(date +%Y%m%d-%H%M%S)"
mkdir -p -- "$case_dir"

date "+%Y-%m-%dT%H:%M:%S%z" > "$case_dir/collection-start.txt"
sw_vers > "$case_dir/macos-version.txt"
uname -a > "$case_dir/kernel.txt"
system_profiler SPSoftwareDataType SPHardwareDataType > "$case_dir/system-profile.txt"
uptime > "$case_dir/uptime.txt"
who > "$case_dir/logged-in-users.txt"
ps auxww > "$case_dir/processes.txt"
ifconfig -a > "$case_dir/interfaces.txt"
netstat -rn > "$case_dir/routes.txt"
netstat -anv > "$case_dir/network-connections.txt"
arp -an > "$case_dir/arp-cache.txt"
scutil --dns > "$case_dir/dns-configuration.txt"
scutil --proxy > "$case_dir/proxy-configuration.txt"
launchctl list > "$case_dir/launchd-services.txt"
vm_stat > "$case_dir/memory.txt"
df -h > "$case_dir/filesystems.txt"
log show --last 1h --style compact > "$case_dir/unified-log-last-hour.txt"
date "+%Y-%m-%dT%H:%M:%S%z" > "$case_dir/collection-end.txt"

Hinweise

19. Paketaufzeichnung nur gezielt einsetzen

Eine Paketaufzeichnung kann zeigen:

Sie kann jedoch auch vertrauliche Inhalte, interne IP-Adressen, Hostnamen, Benutzerkennungen und Sitzungsinformationen enthalten.

Vor einer Aufzeichnung müssen deshalb geklärt sein:

Windows mit pktmon

Aufzeichnung starten

[FILE][ACTIVE][PRIV][SENSITIV] pktmon start --capture --pkt-size 0 --file-name "<Zielpfad>\capture.etl"

Aufzeichnung beenden

[ACTIVE][PRIV] pktmon stop

ETL-Datei in PCAPNG umwandeln

[FILE][SENSITIV] pktmon etl2pcap "<Zielpfad>\capture.etl" --out "<Zielpfad>\capture.pcapng"

Linux mit tcpdump

[FILE][ACTIVE][PRIV][SENSITIV] sudo tcpdump -i any -nn -s 0 -w "<Zielpfad>/capture.pcap"

Beenden mit Strg + C.

macOS mit tcpdump

[FILE][ACTIVE][PRIV][SENSITIV] sudo tcpdump -i <Interface> -nn -s 0 -w "<Zielpfad>/capture.pcap"

Beenden mit Strg + C.

Das richtige Interface kann vorher mit folgendem Befehl bestimmt werden:

[RO] networksetup -listallhardwareports

Eine ausführliche Paketanalyse wird später im Netzwerk-Kapitel behandelt.

20. Prüfsummen erstellen

Eine kryptografische Prüfsumme hilft zu erkennen, ob eine gesicherte Datei nachträglich verändert wurde.

Eine Prüfsumme beweist nicht automatisch, woher eine Datei stammt. Sie dokumentiert den Zustand der Datei zum Zeitpunkt der Prüfsummenbildung und ermöglicht spätere Integritätsprüfungen.

Die Prüfsummen sollten erst erstellt werden, nachdem die Sammlung abgeschlossen wurde und keine weiteren Dateien hinzugefügt werden.

Windows

Prüfsumme einer Datei

[RO] Get-FileHash "<Dateipfad>" -Algorithm SHA256

Prüfsummen eines Diagnoseordners als separate CSV-Datei

[FILE] Get-ChildItem "$target" -File -Recurse | Get-FileHash -Algorithm SHA256 | Export-Csv "$target-SHA256.csv" -NoTypeInformation -Encoding UTF8

Linux

Prüfsumme einer Datei

[RO] sha256sum "<Dateipfad>"

Prüfsummen aller Dateien eines Diagnoseordners

[FILE] (cd "$case_dir" && find . -type f -print0 | sort -z | xargs -0 -r sha256sum) > "${case_dir}-SHA256SUMS.txt"

macOS

Prüfsumme einer Datei

[RO] shasum -a 256 "<Dateipfad>"

Prüfsummen aller Dateien eines Diagnoseordners

[FILE] find "$case_dir" -type f -exec shasum -a 256 {} \; > "${case_dir}-SHA256SUMS.txt"

21. Integrität später überprüfen

Windows

[RO] Get-FileHash "<Dateipfad>" -Algorithm SHA256

Die neu berechnete Prüfsumme wird mit der zuvor dokumentierten Prüfsumme verglichen.

Linux

[RO] sha256sum -c "<SHA256SUMS-Datei>"

macOS

Wenn das Prüfsummenformat kompatibel vorliegt:

[RO] shasum -a 256 -c "<SHA256SUMS-Datei>"

22. Sicheren Speicherort auswählen

Diagnosedaten sollten nicht unkontrolliert auf dem betroffenen System verbleiben.

Geeignete Ziele

Ungeeignete Ziele

23. Mögliche sensible Inhalte

Datenquelle Mögliche sensible Informationen
Prozessliste Benutzernamen, Pfade, Befehlszeilen, Token
Netzwerkverbindungen interne IP-Adressen, externe Ziele, verwendete Dienste
DNS-Cache besuchte oder verwendete Hostnamen
Ereignisprotokolle Benutzerkonten, Systeme, Anmeldeereignisse
Paketaufzeichnung Nutzdaten, Sitzungen, Hostnamen, Identifikatoren
Konfigurationsdateien Kennwörter, API-Schlüssel, Zertifikate
Umgebungsvariablen Token, Schlüssel, Zugangsdaten
Browserdaten URLs, Sitzungsdaten, Benutzerverhalten
Systemdiagnose umfangreiche Hardware-, Benutzer- und Prozessinformationen
Cloud-Auditdaten Benutzeraktionen, IP-Adressen, Ressourcennamen

Vor der Weitergabe muss geprüft werden:

Bei Beweismitteln sollte eine unveränderte Originalkopie erhalten bleiben. Geschwärzte Arbeitskopien werden davon getrennt erstellt.

24. Beweismittelkette dokumentieren

Bei einem möglichen Sicherheitsvorfall oder einer rechtlich relevanten Untersuchung muss nachvollziehbar bleiben, wer wann mit welchen Daten gearbeitet hat.

Feld Dokumentation
Fall- oder Ticketnummer Eindeutige Referenz
System Hostname, Gerätetyp und gegebenenfalls Seriennummer
Eigentümer oder Fachbereich Verantwortliche Organisationseinheit
Sammler Name oder Administratorkonto der erfassenden Person
Beginn der Sammlung Datum, Uhrzeit und Zeitzone
Ende der Sammlung Datum, Uhrzeit und Zeitzone
Quelle System, Datenträger, Anwendung oder Protokoll
Verwendete Befehle Exakte Befehle und Parameter
Verwendete Werkzeuge Name und Version
Zielmedium Speicherort oder Datenträgerkennung
Dateiname Eindeutiger Name
Prüfsumme SHA-256-Wert
Übergabe Von wem, an wen und wann
Zugriff Wer öffnete oder kopierte die Daten?
Zweck Diagnose, Incident Response oder forensische Untersuchung
Veränderungen Jede bekannte Veränderung dokumentieren

Beispiel für einen eindeutigen Dateinamen

INC-2026-0042-SRV-DC01-System-20260730-151500.evtx

Der Dateiname enthält:

25. Prioritäten bei laufendem Produktionsausfall

Bei einem kritischen Produktionsausfall kann nicht unbegrenzt auf eine vollständige Sammlung gewartet werden.

Eine sinnvolle Mindestaufnahme besteht aus:

  1. Fehlermeldung und Zeitpunkt
  2. betroffenem System und Benutzer
  3. Prozess- und Dienstzustand
  4. Netzwerkverbindungen
  5. IP-Konfiguration und Routing
  6. Ressourcen- und Datenträgerzustand
  7. relevanten Ereignissen kurz vor dem Fehler
  8. ausgeführter Maßnahme
  9. Zustand nach der Maßnahme

Anschließend kann eine begründete Wiederherstellungsmaßnahme durchgeführt werden.

Priorität Entscheidung
Menschen oder physische Sicherheit betroffen Sicherheit hat Vorrang
Aktiver Sicherheitsangriff Eindämmung nach Incident-Response-Plan
Kritischer Produktionsstillstand Mindestaufnahme, danach freigegebene Wiederherstellung
Einzelner Arbeitsplatz betroffen Ausführlichere Diagnose meist möglich
Fehler gut reproduzierbar Zustand sichern und kontrollierte Tests durchführen
Fehler selten oder nicht reproduzierbar Vor einer Änderung besonders sorgfältig sichern

26. Nach jeder Änderung erneut sichern

Nach einer Maßnahme sollte nicht nur notiert werden, ob „es wieder geht“.

Zu dokumentieren sind:

Vorher-Nachher-Tabelle

Prüfpunkt Vor der Maßnahme Nach der Maßnahme
Fehler reproduzierbar
Dienstzustand
Prozess-ID
CPU-Auslastung
Speichernutzung
Netzwerkverbindung
DNS-Auflösung
Ereignisprotokoll
Benutzerfunktion
Monitoringstatus

27. Typische Fehler bei der Beweissicherung

Fehler Folge Besseres Vorgehen
Sofortiger Neustart Flüchtige Zustände gehen verloren Mindestzustand zuerst sichern
Screenshot ohne Uhrzeit Ereignis ist schwer einzuordnen Zeit und Zeitzone dokumentieren
Nur Fehlermeldung abschreiben Kontext und Details fehlen Vollständigen Screenshot und Fehlercode sichern
Protokoll als Text kopieren Metadaten können fehlen Wenn möglich natives Format exportieren
Diagnose auf betroffenem System speichern Daten können beim Ausfall verloren gehen Freigegebenes externes Ziel verwenden
Originaldatei bearbeiten Integrität ist nicht mehr nachvollziehbar Original schützen, Arbeitskopie verwenden
Keine Prüfsumme erstellen Spätere Veränderung schwer erkennbar SHA-256 dokumentieren
Mehrere Maßnahmen gleichzeitig Wirkung ist nicht zuordenbar Eine Variable pro Test ändern
Daten unverschlüsselt versenden Datenschutz- und Sicherheitsrisiko Freigegebenen Übertragungsweg verwenden
Vollständige Logs öffentlich hochladen Interne Daten werden offengelegt Daten prüfen, minimieren und schwärzen
Root- oder Admin-Rechte unnötig verwenden Größerer Eingriff in das System Niedrigste erforderliche Berechtigung verwenden
Sicherheitsvorfall wie normalen Fehler behandeln Spuren werden vernichtet oder Angriff breitet sich aus Incident-Response-Prozess aktivieren
Sammlung verzögert notwendige Eindämmung Schaden kann zunehmen Sicherheit und Eindämmung priorisieren
Nur lokale Protokolle sichern Zentrale Hinweise fehlen SIEM, Firewall, Cloud und Monitoring einbeziehen
Shell-Historie enthält sensible Befehle Zugangsdaten können offengelegt werden Geheimnisse niemals direkt in Befehle schreiben

28. Dokumentationsvorlage

Feld Eintrag
Ticket- oder Fallnummer
Datum und Uhrzeit
Zeitzone
Erfasser
Betroffenes System
Hostname
IP-Adresse
Betriebssystem
Betroffener Benutzer
Sichtbare Fehlermeldung
Fehlercode
Letzter funktionierender Zustand
Erste bekannte Störung
Screenshot gesichert Ja / Nein
Prozesse gesichert Ja / Nein
Verbindungen gesichert Ja / Nein
Netzwerkzustand gesichert Ja / Nein
Dienstzustand gesichert Ja / Nein
Ressourcenstatus gesichert Ja / Nein
Protokolle exportiert Ja / Nein
Paketaufzeichnung erstellt Ja / Nein / Nicht erforderlich
Diagnoseordner
Prüfsumme erstellt Ja / Nein
SHA-256-Datei
Sensible Daten enthalten Ja / Nein / Unbekannt
Sicherheitsvorfall vermutet Ja / Nein
Incident Response informiert Ja / Nein / Nicht erforderlich
Erste durchgeführte Änderung
Zeitpunkt der Änderung
Ergebnis der Änderung
Weitere Maßnahmen

Kurzcheckliste

Ergebnis dieses Arbeitsschrittes

Am Ende dieses Schrittes liegt ein dokumentierter Ausgangszustand vor. Dadurch kann auch nach einem Neustart, Dienstneustart oder einer Konfigurationsänderung nachvollzogen werden, was vor der Maßnahme auf dem System geschah.

Die wichtigste Regel lautet:

Eine schnelle Wiederherstellung behebt möglicherweise die Störung. Eine vorherige Zustandssicherung ermöglicht zusätzlich die Ursachenanalyse.

Bei einem möglichen Sicherheitsvorfall gelten die Incident-Response-Vorgaben der Organisation. Eine normale Diagnosesammlung ersetzt keine professionelle forensische Sicherung.

Nächste Seite:
1.5 Arbeitshypothesen bilden und Prüfungen priorisieren

Offizielle Standards und Herstellerdokumentation

1. Grundlagen der systematischen Fehleranalyse

1.5 Arbeitshypothesen bilden und Prüfungen priorisieren

Nachdem Störung, Umfang, Zeitpunkt, Änderungen und Ausgangszustand dokumentiert wurden, beginnt die gezielte Ursachensuche.

Dabei gilt:

Nicht die erste plausible Erklärung beheben, sondern mehrere mögliche Ursachen aufstellen und mit geeigneten Tests unterscheiden.

Eine Arbeitshypothese ist eine vorläufige, überprüfbare Erklärung für das beobachtete Fehlerbild. Sie ist noch keine bestätigte Ursache.

Ziel dieser Seite

Nach diesem Arbeitsschritt sollten:

1. Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] Read-only: liest Informationen aus
[TEST] Führt eine aktive Prüfung aus, beispielsweise eine DNS- oder TCP-Anfrage
[FILE] Erstellt oder überschreibt eine Datei
[PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte
[CHANGE] Verändert eine Konfiguration oder einen Betriebszustand
[SENSITIV] Ausgabe kann vertrauliche Daten enthalten

Ein [TEST] verändert normalerweise keine Konfiguration, erzeugt aber Netzwerkverkehr und möglicherweise Protokolleinträge. Wiederholte Anmeldeversuche können beispielsweise ein Benutzerkonto sperren.

2. Fakten, Vermutungen und Ursachen unterscheiden

Begriff Bedeutung Beispiel
Symptom Sichtbare Auswirkung der Störung Webseite ist nicht erreichbar
Fakt Durch Messung oder Beleg bestätigte Information TCP-Port 443 ist von Client A nicht erreichbar
Vermutung Nicht ausreichend begründete Annahme „Bestimmt ist die Firewall schuld“
Hypothese Überprüfbare mögliche Erklärung Eine Firewall-Regel blockiert VLAN 30 zu TCP 443
Vorhersage Erwartetes Ergebnis, wenn die Hypothese stimmt Clients aus VLAN 40 funktionieren, VLAN 30 nicht
Test Gezielte Prüfung der Vorhersage Porttest aus beiden VLANs
Ursache Durch Belege und Gegenproben bestätigte Erklärung ACL blockiert VLAN 30 zu TCP 443
Maßnahme Veränderung zur Beseitigung der Ursache Korrektur der freigegebenen ACL-Regel

Wichtig

„Nach dem Neustart funktionierte es wieder“ ist zunächst nur ein Ergebnis. Daraus folgt noch nicht, warum der Fehler auftrat.

Mögliche Erklärungen wären beispielsweise:

3. Eine präzise Problembeschreibung erstellen

Eine brauchbare Hypothese benötigt eine präzise Problembeschreibung.

Ungeeignet

Das Netzwerk funktioniert nicht.

Besser

Seit ungefähr 14:35 Uhr können Windows-Clients aus VLAN 30 den Server server.example über TCP 443 nicht erreichen. DNS liefert die erwartete IP-Adresse. Clients aus VLAN 40 erreichen denselben Port weiterhin.

Eine gute Problembeschreibung enthält:

4. Aufbau einer überprüfbaren Hypothese

Eine gute Arbeitshypothese kann nach diesem Muster formuliert werden:

Wenn <vermutete Ursache> vorliegt, dann müsste <beobachtbares Ergebnis> auftreten, weil <technischer Zusammenhang>. Das prüfen wir mit <Test>. Widerlegt wäre die Hypothese durch <Gegenergebnis>.

Beispiel

Wenn eine Firewall-Regel den Verkehr aus VLAN 30 blockiert, dann müsste der TCP-Port 443 aus VLAN 30 nicht erreichbar sein, während derselbe Port aus einem freigegebenen VLAN erreichbar ist. Widerlegt wäre die Hypothese, wenn die Verbindung aus beiden VLANs identisch fehlschlägt oder die Pakete nachweislich bis zum Server gelangen.

5. Schlechte und gute Hypothesen

Schlechte Formulierung Problem Bessere Formulierung
Die Firewall ist kaputt Zu allgemein und nicht überprüfbar Eine Firewall-Regel blockiert TCP 443 aus VLAN 30
Windows macht Probleme Kein konkreter Mechanismus Der Windows-DNS-Client verwendet einen veralteten Cacheeintrag
Der Server ist down „Down“ ist nicht definiert Der Webdienst lauscht nicht auf TCP 443
Es liegt am Benutzer Keine technische Erklärung Dem Benutzer fehlt die erforderliche Anwendungsrolle
Das Update war schuld Nur zeitliche Korrelation Update KB… hat den verwendeten Treiber ersetzt
DNS geht nicht Nicht eingegrenzt Der Client fragt einen nicht erreichbaren DNS-Server ab
Das Zertifikat ist falsch Zu ungenau Der aufgerufene Hostname fehlt im Subject Alternative Name
Das Netzwerk ist langsam Keine Messgröße Zwischen Client und Server treten Paketverluste auf

6. Mögliche Fehlerbereiche systematisch durchgehen

Für eine erste Hypothesenliste können folgende Bereiche verwendet werden:

Fehlerbereich Typische Ursachen
Benutzer Bedienfehler, falsche Eingabe, fehlende Berechtigung
Benutzerkonto Sperrung, Ablauf, Gruppenmitgliedschaft, MFA
Client-Hardware Netzwerkkarte, Datenträger, Arbeitsspeicher
Client-Betriebssystem Update, Treiber, lokaler Dienst, Richtlinie
Client-Konfiguration IP, DNS, Proxy, Zertifikat, Firewall
Anwendung Absturz, Cache, Version, Konfiguration
Namensauflösung DNS-Server, Eintrag, Suchdomäne, Cache
Netzwerkzugang WLAN, Switchport, VLAN, NAC, Port-Security
Netzwerkpfad Routing, ACL, Firewall, NAT, MTU
Zielserver Dienst, Ressourcen, Betriebssystem, Listener
Authentifizierung Kerberos, LDAP, RADIUS, Zertifikat, Token
Autorisierung Rolle, Gruppe, ACL, Dateiberechtigung
Abhängiger Dienst Datenbank, DNS, Storage, API, Queue
Sicherheitskomponente EDR, Antivirus, Proxy, Webfilter
Automatisierung Skript, GPO, Deployment, geplanter Job
Virtualisierung Ressourcen, virtuelles Netzwerk, Storage
Cloud oder Provider Plattformstörung, Richtlinie, Service Health
Letzte Änderung Update, Migration, Konfiguration, Zertifikat

Nicht jeder Bereich muss ausführlich geprüft werden. Die Eingrenzung aus den vorherigen Seiten bestimmt, welche Bereiche plausibel sind.

7. Hypothesen aus dem Fehlerumfang ableiten

Beobachtung Zu priorisierende Hypothesen
Nur ein Benutzer betroffen Konto, Berechtigung, Profil, Rolle
Alle Benutzer eines Clients betroffen Client, Betriebssystem, lokale Konfiguration
Ein Benutzer auf allen Clients betroffen Identität, Konto, Berechtigung
Nur ein Standort betroffen WAN, Firewall, DNS, Provider, Standortnetz
Nur ein VLAN betroffen Routing, ACL, DHCP, VLAN-Zuordnung
Alle Clients betroffen Server, zentraler Dienst, gemeinsame Abhängigkeit
Nur ein Server betroffen Dienst, Betriebssystem, Ressourcen, Serverkonfiguration
Nur ein Browser betroffen Browserprofil, Proxy, Zertifikat, Erweiterung
Zugriff per IP funktioniert, per Name nicht DNS, Hosts-Datei, Suchdomäne
Port erreichbar, Anwendung funktioniert nicht Protokoll, Authentifizierung, Anwendung
Anwendung lokal erreichbar, remote nicht Listener-Bindung, Firewall, Routing
Fehler nur zu bestimmten Zeiten geplanter Job, Last, Lease, Token, Zertifikat
Fehler nach Update Kompatibilität, Treiber, Richtlinie, Neustart
Fehler verschwindet nach Neustart Prozesszustand, Cache, Ressourcenleck
Neue Geräte betroffen DHCP, NAC, Zertifikat, Provisionierung
Alte Geräte betroffen, neue funktionieren veraltete Konfiguration oder Software

8. Belege für und gegen eine Hypothese sammeln

Eine professionelle Hypothese enthält nicht nur unterstützende Hinweise. Es müssen auch widersprechende Beobachtungen gesucht werden.

Hypothese Unterstützende Hinweise Widersprechende Hinweise
DNS-Problem Name wird nicht aufgelöst Direkte DNS-Abfrage liefert korrekte Adresse
Serverdienst ausgefallen Port ist von allen Clients geschlossen Dienst lauscht und andere Clients funktionieren
Benutzerberechtigung fehlt Nur ein Benutzer betroffen Derselbe Benutzer funktioniert auf anderem Client
Lokale Firewall blockiert Nur ein Client betroffen Verbindung scheitert auch von anderen Clients
VLAN-ACL blockiert Nur ein VLAN betroffen Pakete erreichen nachweislich den Server
Zertifikat abgelaufen TLS-Fehler und Ablaufdatum überschritten Zertifikat ist gültig und Hostname stimmt
Datenträger voll Freier Speicher ist nahezu null Ausreichend Speicher und keine I/O-Fehler
Update verursacht Fehler Fehler beginnt direkt nach Update Identisch aktualisierte Systeme funktionieren

Eine Hypothese sollte herabgestuft werden, wenn mehrere gesicherte Fakten ihr widersprechen.

9. Prüfungen sinnvoll priorisieren

Nicht automatisch die wahrscheinlichste Hypothese wird zuerst geprüft. Sinnvoll ist zunächst ein Test, der mit geringem Risiko möglichst viele Hypothesen unterscheidet.

Priorisierungskriterien

Kriterium Frage
Wahrscheinlichkeit Passt die Hypothese zum Fehlerbild?
Informationsgewinn Wie viele Ursachen kann der Test unterscheiden?
Sicherheit Kann der Test Datenverlust oder Ausfall verursachen?
Aufwand Wie viel Zeit und Vorbereitung benötigt der Test?
Reproduzierbarkeit Kann der Test zuverlässig wiederholt werden?
Reversibilität Lässt sich eine Veränderung sicher zurücknehmen?
Reichweite Betrifft der Test einen Client oder die Produktion?
Beweislage Gibt es bereits unterstützende oder widersprechende Fakten?

10. Prioritätsklassen

Priorität Bedeutung Beispiele
P1 Sicher, schnell und hoher Informationsgewinn Status, Logs, DNS-, TCP- und Vergleichstest
P2 Gezielte Prüfung mit begrenztem Aufwand Testkonto, anderer Client, isolierte Konfiguration
P3 Potenziell störende oder aufwendige Prüfung Dienstneustart, Failover, Rollback
P4 Unwahrscheinlich, widersprochen oder unverhältnismäßig großflächige Änderung ohne ausreichende Belege

Sinnvolle Reihenfolge

  1. passive Zustandsabfrage,
  2. Vergleich mit funktionierendem System,
  3. gezielte Netzwerk- oder Anwendungstests,
  4. Test in isolierter Umgebung,
  5. reversible Änderung,
  6. Dienstneustart oder Failover,
  7. Konfigurationsrollback,
  8. weitreichende Änderung oder Produktionsunterbrechung.

11. Tests müssen Hypothesen unterscheiden

Ein Test ist besonders nützlich, wenn unterschiedliche Hypothesen unterschiedliche Ergebnisse erwarten lassen.

Wenig aussagekräftiger Test

Der Benutzer soll es noch einmal versuchen.

Dieser Test zeigt lediglich, ob der Fehler weiterhin auftritt.

Aussagekräftiger Test

Derselbe Benutzer testet dieselbe Funktion auf einem funktionierenden Vergleichsclient.

Mögliche Interpretation:

Ergebnis Schlussfolgerung
Benutzer funktioniert auf Vergleichsclient Clientbezogene Ursache wahrscheinlicher
Benutzer funktioniert auch dort nicht Konto oder Berechtigung wahrscheinlicher
Andere Benutzer funktionieren auf betroffenem Client Benutzerbezogene Ursache wahrscheinlicher
Kein Benutzer funktioniert auf betroffenem Client Client- oder Netzwerkursache wahrscheinlicher

12. Vor dem Test das erwartete Ergebnis festlegen

Vor jedem Test sollte dokumentiert werden:

Testvorlage

Feld Eintrag
Hypothese
Technische Begründung
Test
Erwartetes Ergebnis
Widerlegendes Ergebnis
Risiko
Rückfallmöglichkeit
Tatsächliches Ergebnis
Bewertung Bestätigt / Gestützt / Unklar / Widerlegt
Nächster Schritt

13. Grundlegender Netzwerk- und Diensttest

Als Beispiel wird ein Webdienst verwendet:

server.example ist ein reservierter Beispieldomainname und muss durch das tatsächliche Ziel ersetzt werden.

14. Stufe 1 – Namensauflösung prüfen

Windows

[TEST] Resolve-DnsName server.example

Bestimmten DNS-Server abfragen

[TEST] Resolve-DnsName server.example -Server <DNS-Server-IP>

Alternative

[TEST] nslookup server.example

Linux

[TEST] getent ahosts server.example

[TEST] dig server.example

Kurze Ausgabe

[TEST] dig +short server.example

Bestimmten DNS-Server abfragen

[TEST] dig @<DNS-Server-IP> server.example

macOS

[TEST] dscacheutil -q host -a name server.example

[TEST] dig server.example

Kurze Ausgabe

[TEST] dig +short server.example

Bestimmten DNS-Server abfragen

[TEST] dig @<DNS-Server-IP> server.example

Interpretation der DNS-Prüfung

Ergebnis Mögliche Bedeutung
Keine Adresse wird geliefert DNS-Eintrag, DNS-Server oder Resolverproblem
Falsche IP-Adresse veralteter Eintrag, falsche Zone, Cache oder Split-DNS
Unterschiedliche Clients erhalten unterschiedliche IPs Split-DNS, Load Balancing, Cache oder andere Resolver
Bestimmter DNS-Server antwortet korrekt, Standardabfrage nicht Client verwendet falschen oder nicht erreichbaren DNS-Server
Name wird korrekt aufgelöst DNS-Grundfunktion wahrscheinlich vorhanden
Auflösung dauert sehr lange DNS-Server, Weiterleitung, Netzwerk oder Suchdomäne prüfen

Eine erfolgreiche DNS-Abfrage beweist noch nicht, dass der Zielservice erreichbar ist.

15. Stufe 2 – IP-Erreichbarkeit mit ICMP prüfen

Windows

[TEST] ping -n 4 <IP-Adresse>

Linux

[TEST] ping -c 4 <IP-Adresse>

macOS

[TEST] ping -c 4 <IP-Adresse>

Interpretation

Ergebnis Bedeutung
Antworten werden empfangen IP-Kommunikation per ICMP funktioniert
Keine Antwort Host, Route, Firewall oder ICMP-Filterung möglich
Hohe Latenz Netzlast, WAN-Strecke, WLAN oder Zielauslastung möglich
Paketverlust instabile Verbindung, Überlastung oder physisches Problem möglich
„Destination unreachable“ Route, Gateway oder Zielnetz nicht erreichbar
Ping per IP funktioniert, per Name nicht Namensauflösung priorisieren

Ein fehlgeschlagener Ping beweist nicht, dass der Server ausgefallen ist. ICMP kann blockiert sein, während der eigentliche TCP-Dienst funktioniert.

16. Stufe 3 – Zielport prüfen

Windows

[TEST] Test-NetConnection server.example -Port 443 -InformationLevel Detailed

Wichtige Felder:

Nur Ergebnis ausgeben

[TEST] Test-NetConnection server.example -Port 443 -InformationLevel Quiet

Linux

[TEST] nc -vz -w 3 server.example 443

macOS

[TEST] nc -vz -w 3 server.example 443

nc kann je nach Linux-Installation fehlen und muss gegebenenfalls als freigegebenes Paket installiert werden.

Interpretation des Porttests

Ergebnis Mögliche Bedeutung
TCP-Verbindung erfolgreich Netzwerkpfad und TCP-Listener grundsätzlich erreichbar
Verbindung abgelehnt Ziel erreichbar, aber kein Listener oder aktive Ablehnung
Zeitüberschreitung Paketfilter, Route, Überlastung oder nicht antwortendes Ziel
Name kann nicht aufgelöst werden DNS zuerst untersuchen
Nur ein Client scheitert Client, lokales Netzwerk oder lokale Firewall
Nur ein VLAN scheitert ACL, Firewall, Routing oder VLAN-Konfiguration
Alle Clients scheitern Dienst, Server, zentrale Firewall oder gemeinsame Abhängigkeit

Ein erfolgreicher TCP-Test beweist nur den Verbindungsaufbau zum Port. Er bestätigt noch nicht, dass Anmeldung, Anwendung oder Datenbank funktionieren.

17. Stufe 4 – Anwendungsebene prüfen

Windows

[TEST] curl.exe -v -o NUL https://server.example/

Linux

[TEST] curl -v -o /dev/null https://server.example/

macOS

[TEST] curl -v -o /dev/null https://server.example/

Die Option -v zeigt unter anderem:

Beim ersten Test sollte nicht -k beziehungsweise --insecure verwendet werden. Diese Option deaktiviert die Zertifikatsprüfung und kann genau den Fehler verbergen, der untersucht werden soll.

18. HTTP-Ergebnisse interpretieren

Ergebnis Interpretation
200 OK Anfrage wurde erfolgreich verarbeitet
301 oder 302 Weiterleitung; Ziel des Location-Headers prüfen
401 Unauthorized Dienst erreichbar, Authentifizierung erforderlich oder fehlgeschlagen
403 Forbidden Dienst erreichbar, Zugriff wird verweigert
404 Not Found Dienst erreichbar, Ressource oder Pfad nicht gefunden
408 Request Timeout Anfrage wurde nicht rechtzeitig verarbeitet
429 Too Many Requests Rate Limit oder zu viele Anfragen
500 Internal Server Error serverseitiger Anwendungsfehler
502 Bad Gateway Proxy oder Gateway erhält ungültige Backend-Antwort
503 Service Unavailable Dienst oder Backend nicht verfügbar
504 Gateway Timeout Proxy oder Gateway wartet vergeblich auf Backend
TLS-Zertifikatsfehler Zertifikat, Hostname, Vertrauenskette oder Uhrzeit prüfen
TCP-Verbindungsfehler Netzwerkpfad, Firewall oder Listener prüfen

Ein HTTP-Status ist ein wichtiger Hinweis, aber die genaue Bedeutung kann von der Anwendung abweichen.

19. TLS-Verbindung untersuchen

Auf Linux und macOS sowie unter Windows mit installiertem OpenSSL:

[TEST] openssl s_client -connect server.example:443 -servername server.example -showcerts

Zu prüfen sind:

Typische Befunde

Befund Mögliche Ursache
Zertifikat abgelaufen Zertifikat wurde nicht rechtzeitig erneuert
Zertifikat noch nicht gültig falsche Systemzeit oder falsches Zertifikat
Hostname stimmt nicht falsches Zertifikat, Alias oder fehlender SAN-Eintrag
Unbekannte CA Stamm- oder Zwischenzertifikat fehlt
Verbindung ohne Zertifikat beendet TLS-Listener oder Proxyproblem
Handshake Failure inkompatible TLS-Version, Cipher oder Clientzertifikat
Browser funktioniert, Anwendung nicht unterschiedlicher Trust Store oder TLS-Stack

20. Netzwerkpfad prüfen

Windows

[TEST] tracert server.example

PowerShell

[TEST] Test-NetConnection server.example -TraceRoute

Linux

[TEST] tracepath server.example

Alternativ, wenn installiert:

[TEST] traceroute server.example

macOS

[TEST] traceroute server.example

Wichtige Einschränkungen

21. Lokal gegen remote testen

Wenn ein Dienst direkt auf dem Server funktioniert, aber von Clients nicht erreichbar ist, wird die Ursache auf Netzwerkpfad, Listener-Bindung oder Firewall eingegrenzt.

Windows-Server

Dienst lokal testen

[TEST] Test-NetConnection localhost -Port <Port>

Listener prüfen

[RO][PRIV] Get-NetTCPConnection -State Listen -LocalPort <Port>

Zugehörigen Prozess bestimmen

[RO] Get-Process -Id <OwningProcess>

Linux-Server

Dienst lokal testen

[TEST] nc -vz -w 3 localhost <Port>

Listener prüfen

[RO][PRIV] ss -lntp | grep ":<Port>"

HTTP-Dienst lokal prüfen

[TEST] curl -v http://localhost:<Port>/

macOS-Server

Dienst lokal testen

[TEST] nc -vz -w 3 localhost <Port>

Listener prüfen

[RO][PRIV] lsof -nP -iTCP:<Port> -sTCP:LISTEN

Interpretation

Lokaler Test Remote-Test Wahrscheinlicher Bereich
Erfolgreich Erfolgreich Anwendung, Anmeldung oder Benutzerberechtigung
Erfolgreich Fehlgeschlagen Firewall, Routing, NAT oder Listener-Bindung
Fehlgeschlagen Fehlgeschlagen Dienst, Server oder Anwendung
Fehlgeschlagen Erfolgreich ungewöhnlicher Proxy-, Container- oder Load-Balancer-Pfad
Unterschiedlich je Quellnetz Unterschiedlich VLAN, ACL, Firewall oder Routing

22. Dienstzustand und Protokolle prüfen

Windows

[RO] Get-Service -Name <Dienstname>

[RO] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=(Get-Date).AddHours(-1)} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message

Linux

[RO] systemctl status <Dienstname> --no-pager

[RO] journalctl -u <Dienstname> --since "1 hour ago" --no-pager

macOS

[RO] launchctl list | grep -i "<Dienstname>"

[RO] log show --last 1h --predicate 'process == "<Prozessname>"' --style compact

Zu prüfende Hinweise

23. Benutzer- und Berechtigungshypothesen prüfen

Windows

Benutzeridentität und Gruppen

[RO][SENSITIV] whoami /all

NTFS-Berechtigungen

[RO][SENSITIV] icacls "<Pfad>"

PowerShell-ACL

[RO][SENSITIV] Get-Acl "<Pfad>" | Format-List

Domänenkanal auf Mitgliedscomputern prüfen

[TEST] Test-ComputerSecureChannel -Verbose

Test-ComputerSecureChannel ist für Domänenmitgliedscomputer vorgesehen. Auf Domänencontrollern ist dieses Cmdlet laut Microsoft nicht zur zuverlässigen Prüfung geeignet. Der Parameter -Repair wäre eine Änderung und gehört nicht zum reinen Test.

Linux

Benutzer und Gruppen

[RO] id <Benutzername>

Datei- und Verzeichnisrechte

[RO] ls -ld "<Pfad>"

Rechte des vollständigen Pfades

[RO] namei -l "<Pfad>"

POSIX-ACL anzeigen

[RO][SENSITIV] getfacl "<Pfad>"

macOS

Benutzer und Gruppen

[RO] id <Benutzername>

Dateirechte und ACL

[RO][SENSITIV] ls -lde "<Pfad>"

Typische Vergleichstests

Test Interpretation
Anderer Benutzer funktioniert am selben Client Benutzer oder Berechtigung priorisieren
Derselbe Benutzer funktioniert an anderem Client Client oder Benutzerprofil priorisieren
Testkonto mit gleicher Rolle funktioniert individuelles Konto untersuchen
Testkonto mit anderer Rolle funktioniert Rollen- oder Gruppenberechtigung untersuchen
Dateizugriff direkt möglich, Anwendung nicht Anwendung oder Dienstkonto untersuchen

Bei Anmeldetests muss eine mögliche Kontosperrung berücksichtigt werden.

24. Konfigurationen vergleichen

Windows PowerShell

[RO] Compare-Object (Get-Content "<Funktionierende-Datei>") (Get-Content "<Betroffene-Datei>")

Prüfsumme vergleichen

[RO] Get-FileHash "<Datei>" -Algorithm SHA256

Linux und macOS

[RO] diff -u "<Funktionierende-Datei>" "<Betroffene-Datei>"

Prüfsumme unter Linux

[RO] sha256sum "<Datei>"

Prüfsumme unter macOS

[RO] shasum -a 256 "<Datei>"

Zu vergleichende Werte

Eine unterschiedliche Prüfsumme zeigt nur, dass Dateien verschieden sind. Sie zeigt nicht, welcher Unterschied relevant ist.

25. Diagnosematrix für typische Ergebnisse

Testergebnis Wahrscheinlicher Fehlerbereich
DNS-Abfrage schlägt fehl DNS-Client, DNS-Server oder Netzwerk zum DNS-Server
DNS liefert falsche IP Zone, Cache, Hosts-Datei oder Split-DNS
IP-Ping funktioniert, Name nicht Namensauflösung
Ping scheitert, TCP funktioniert ICMP wird wahrscheinlich blockiert
TCP-Port ist erreichbar, HTTP scheitert Anwendung, TLS, Authentifizierung oder Protokoll
TCP-Verbindung wird abgelehnt Kein Listener oder aktive Ablehnung
TCP-Verbindung läuft in Timeout Filterung, Routing, Überlastung oder Ziel antwortet nicht
Lokal funktioniert, remote nicht Firewall, Routing, Listener-Bindung oder NAT
Andere Clients funktionieren Clientbezogene Ursache
Andere Benutzer funktionieren Benutzer, Konto, Profil oder Berechtigung
Gleiches VLAN betroffen VLAN, ACL, DHCP oder Gateway
Alle VLANs betroffen Server, Dienst oder zentrale Komponente
HTTP 401 Authentifizierung untersuchen
HTTP 403 Autorisierung oder Richtlinie untersuchen
HTTP 500 Anwendung oder Backend untersuchen
HTTP 502/504 Proxy, Load Balancer oder Backend untersuchen
Zertifikatsfehler Zeit, Hostname, Trust Store oder Zertifikatskette
Dienst läuft, aber kein Listener Konfiguration, Bindung oder Startfehler
Listener vorhanden, Anwendung reagiert nicht Prozesszustand, Abhängigkeit oder Ressourcen
Datenträger voll Speicherverbrauch und Logwachstum untersuchen

26. Mehrdeutige Ergebnisse erkennen

Ein einzelner Test liefert häufig keine eindeutige Ursache.

Beispiel: TCP-Timeout

Mögliche Ursachen:

Deshalb folgt auf einen mehrdeutigen Test ein zweiter Test, der diese Möglichkeiten weiter trennt.

Geeignete Folgeprüfungen

27. Beispiel einer vollständigen Hypothesenliste

Störung

Clients aus VLAN 30 können https://server.example nicht öffnen. Clients aus VLAN 40 funktionieren. DNS liefert in beiden VLANs dieselbe IP-Adresse.

Nr. Hypothese Belege dafür Belege dagegen Test Priorität
H1 ACL blockiert VLAN 30 zu TCP 443 Nur VLAN 30 betroffen Noch keine TCP-Test und Firewall-Log P1
H2 Falsches Gateway in VLAN 30 gesamtes VLAN betroffen Andere Ziele erreichbar Route und Gateway prüfen P1
H3 DNS liefert falsche Adresse Webdienst nicht erreichbar Beide VLANs erhalten dieselbe IP DNS-Ergebnisse vergleichen P4
H4 Webdienst ist ausgefallen Verbindung schlägt fehl VLAN 40 funktioniert lokaler und externer Porttest P4
H5 MTU-Problem im Netzwerkpfad HTTPS betroffen noch keine Größenabhängigkeit bekannt Paketgröße und Paketaufzeichnung P2
H6 Proxy wird nur in VLAN 30 verwendet nur bestimmte Clients betroffen möglich noch ungeprüft Proxykonfiguration vergleichen P2

Erste Prüfung

Test-NetConnection server.example -Port 443

Ergebnis:

Dadurch werden H1, H2 oder H6 wahrscheinlicher. H3 und H4 werden weniger wahrscheinlich.

Zweite Prüfung

Damit wird H1 stark gestützt.

Bestätigung

Nach einer freigegebenen Korrektur der betroffenen ACL-Regel funktioniert derselbe definierte Test aus VLAN 30. Die Firewall protokolliert nun eine erlaubte Verbindung.

28. Hypothesenstatus verwenden

Status Bedeutung
Offen Noch nicht geprüft
Gestützt Hinweise sprechen dafür
Teilweise gestützt Einige Ergebnisse passen, andere sind offen
Unklar Test war nicht eindeutig
Widerlegt Ergebnis widerspricht der Vorhersage
Bestätigt Mehrere Belege und Gegenprobe stützen die Ursache
Zurückgestellt Derzeit geringe Priorität
Nicht prüfbar Werkzeug, Zugriff oder Vergleichssystem fehlt

Eine Hypothese sollte nicht bereits nach einem passenden Einzelbefund als bestätigt gelten.

29. Wann gilt eine Ursache als bestätigt?

Eine Ursache ist ausreichend bestätigt, wenn möglichst mehrere Kriterien erfüllt sind:

Besonders starke Bestätigung

Zustand Ergebnis
Fehlerzustand vorhanden definierter Test schlägt fehl
Ursache kontrolliert entfernt derselbe Test funktioniert
Ursache in Testumgebung erneut hergestellt derselbe Test schlägt wieder fehl
Ursache erneut entfernt derselbe Test funktioniert wieder

In Produktionsumgebungen ist ein erneutes absichtliches Herstellen des Fehlers häufig nicht vertretbar. In diesem Fall müssen Protokolle, Vergleichssysteme und technische Plausibilität gemeinsam bewertet werden.

30. Typische Denkfehler vermeiden

Denkfehler Beschreibung Gegenmaßnahme
Bestätigungsfehler Es werden nur Belege für die Lieblingshypothese gesucht aktiv nach widersprechenden Fakten suchen
Fixierung Erste Erklärung wird nicht mehr hinterfragt mindestens mehrere Hypothesen notieren
Zeitliche Verwechslung Änderung vor Fehler wird automatisch zur Ursache technische Verbindung und Gegenprobe verlangen
Autoritätseffekt Aussage einer erfahrenen Person wird ungeprüft übernommen Messwerte und Protokolle verwenden
Verfügbarkeitseffekt Kürzlich erlebter Fehler wird überall vermutet aktuellen Umfang und aktuelle Fakten prüfen
Aktionismus Sichtbare Aktivität ersetzt systematische Diagnose erwartetes Testergebnis vorab definieren
Erfolgsfehlschluss Nach Neustart geht es, daher sei Ursache gefunden Wiederherstellung und Ursachenbestätigung trennen
Werkzeuggläubigkeit Ausgabe eines Werkzeugs wird als absolute Wahrheit angesehen Messgrenzen und Gegenprüfung beachten
Scheingenauigkeit Punktwert wird mit Gewissheit verwechselt Priorisierung als Hilfsmittel verwenden
Gruppendenken Team übernimmt eine Vermutung ohne Gegenargument gezielt eine alternative Erklärung verlangen

31. Regeln für aussagekräftige Tests

32. Dokumentationsvorlage für Hypothesen

Nr. Hypothese Technische Begründung Belege dafür Belege dagegen Geplanter Test Erwartetes Ergebnis Risiko Priorität Ergebnis Status
H1
H2
H3
H4

33. Dokumentationsvorlage für einen Test

Feld Eintrag
Ticketnummer
Hypothese
Testnummer
Datum und Uhrzeit
Zeitzone
Ausführende Person
Quellsystem
Quell-IP
Zielsystem
Ziel-IP
Protokoll und Port
Ausgangszustand
Exakter Befehl
Erwartetes Ergebnis
Tatsächliches Ergebnis
Vollständige Ausgabe gesichert Ja / Nein
Hypothese gestützt Ja / Nein / Unklar
Nebenwirkungen
Rückfall erforderlich Ja / Nein
Nächster Test

Kurzcheckliste

Ergebnis dieses Arbeitsschrittes

Am Ende liegt keine unsortierte Sammlung von Vermutungen mehr vor, sondern ein priorisierter Prüfplan.

Jede wichtige Hypothese enthält:

Dadurch wird die Fehlersuche nachvollziehbar, reproduzierbar und wesentlich effizienter.

Nächste Seite:
1.6 Prüfungen kontrolliert durchführen und Ergebnisse bewerten

Offizielle Hersteller- und Standarddokumentation

1. Grundlagen der systematischen Fehleranalyse

1.6 Prüfungen kontrolliert durchführen und Ergebnisse bewerten

Eine gute Hypothese ist nur dann nützlich, wenn sie mit einem kontrollierten und aussagekräftigen Test geprüft wird.

Dabei gilt:

Gleicher Ausgangszustand, gleicher Test, nur eine veränderte Variable und ein vorher festgelegtes erwartetes Ergebnis.

Wer mehrere Dinge gleichzeitig verändert, kann die Wirkung später keiner einzelnen Maßnahme zuordnen.

Ziel dieser Seite

Nach diesem Arbeitsschritt sollten:

1. Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] Read-only: liest Informationen aus
[TEST] Führt eine aktive Prüfung aus und kann Netzwerkverkehr oder Protokolleinträge erzeugen
[FILE] Erstellt oder überschreibt eine Datei
[PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte
[CHANGE] Verändert Konfiguration oder Betriebszustand
[DISRUPTIV] Kann Benutzer oder produktive Dienste beeinträchtigen
[SENSITIV] Ausgabe kann vertrauliche Daten enthalten

Auch ein [RO]- oder [TEST]-Befehl ist nicht vollständig spurlos. Er startet mindestens einen Prozess und kann in Protokollen, Shell-Historien, Firewalls oder SIEM-Systemen erscheinen.

2. Der kontrollierte Prüfablauf

Phase Tätigkeit
1. Prüfziel Welche Frage soll der Test beantworten?
2. Hypothese Welche mögliche Ursache wird geprüft?
3. Ausgangszustand Welche Messwerte liegen vor dem Test vor?
4. Vorhersage Welches Ergebnis wird erwartet?
5. Risiko Welche Nebenwirkungen kann der Test haben?
6. Abbruchkriterium Wann muss der Test sofort beendet werden?
7. Durchführung Exakten Befehl oder Ablauf verwenden
8. Aufzeichnung Zeit, Ausgabe und Rückgabewert sichern
9. Wiederholung Ergebnis bei Bedarf kontrolliert reproduzieren
10. Rückkehr Ausgangszustand wiederherstellen
11. Vergleich Vorher- und Nachher-Ergebnis vergleichen
12. Bewertung Hypothese bestätigen, stützen, offenlassen oder widerlegen

3. Testarten nach Eingriffsrisiko

Testart Beschreibung Beispiel Risiko
Passive Abfrage Liest vorhandenen Zustand Prozessliste, Logs, Routingtabelle Sehr niedrig
Aktiver Funktionstest Sendet eine kontrollierte Anfrage DNS-, Ping-, TCP- oder HTTP-Test Niedrig
Vergleichstest Vergleicht betroffenes und funktionierendes System Client A gegen Client B Niedrig
Wiederholungstest Prüft, ob das Ergebnis reproduzierbar ist fünf identische TCP-Tests Niedrig bis mittel
Isolationstest Verändert nur den Testkontext bestimmtes Backend mit curl --resolve Niedrig bis mittel
Reversible Änderung Verändert vorübergehend eine Einstellung freigegebene Testregel Mittel
Dienstbezogener Test Startet oder beendet einen Dienst Dienstneustart Hoch
Failover-Test Verlagert produktiven Betrieb Wechsel auf zweiten Server Hoch
Lasttest Erzeugt zusätzliche Last viele parallele Anfragen Hoch
Wiederherstellungstest Setzt Konfiguration oder Version zurück Rollback Hoch
Destruktiver Test Kann Daten oder Zustand zerstören Löschen, Zurücksetzen, Neuinstallation Sehr hoch

Passive, aktive und vergleichende Tests sollten normalerweise vor verändernden oder potenziell störenden Tests durchgeführt werden.

4. Prüfung und Reparatur nicht vermischen

Reine Prüfung

[TEST] Test-ComputerSecureChannel -Verbose

Dieser Befehl prüft auf einem Windows-Domänenmitglied den sicheren Kanal.

Verändernde Reparatur

[CHANGE] Test-ComputerSecureChannel -Repair

Der Parameter -Repair verändert den Zustand und ist keine reine Prüfung mehr.

Ein ähnlicher Unterschied besteht bei vielen Werkzeugen:

Prüfung Veränderung
Get-Service Restart-Service
systemctl status systemctl restart
ipconfig /displaydns ipconfig /flushdns
Get-NetRoute New-NetRoute oder Remove-NetRoute
journalctl Löschen oder Rotieren von Logs
diff Überschreiben der Konfiguration
Firewall-Log ansehen Firewall-Regel ändern
Zertifikat anzeigen Zertifikat ersetzen
Updateverlauf anzeigen Update installieren oder entfernen

Prüfung und Reparatur sollten im Ticket als getrennte Schritte dokumentiert werden.

5. Prüfziel präzise formulieren

Ungeeignet

Ich teste das Netzwerk.

Besser

Es wird geprüft, ob Client PC-030 aus VLAN 30 am 30.07.2026 um 15:30 Uhr eine TCP-Verbindung zu server.example auf Port 443 herstellen kann.

Noch besser

Hypothese H1: Eine ACL blockiert TCP 443 aus VLAN 30. Erwartet wird, dass der TCP-Test aus VLAN 30 fehlschlägt und derselbe Test aus VLAN 40 erfolgreich ist.

Ein präzises Prüfziel enthält:

6. Ausgangszustand als Baseline erfassen

Eine Baseline ist der dokumentierte Zustand vor dem Test.

Typische Baseline-Werte

Beispiel

Messwert Vor dem Test
Zeitpunkt 2026-07-30 15:30:00 CEST
Quelle PC-030
Quell-IP 192.0.2.30
Quell-VLAN VLAN 30
Ziel server.example
Ziel-IP 198.51.100.20
Zielport TCP 443
DNS-Auflösung erfolgreich
TCP-Test fehlgeschlagen
HTTP-Test keine Verbindung
Ping keine Antwort
Andere Ziele erreichbar
Vergleichsclient aus VLAN 40 funktioniert

Die IP-Adressen aus den Netzen 192.0.2.0/24 und 198.51.100.0/24 sind für Dokumentationsbeispiele reserviert.

7. Nur eine Variable verändern

Ungeeigneter Test

Gleichzeitig werden:

Wenn der Fehler danach verschwunden ist, bleibt unklar, welche Maßnahme wirksam war.

Besseres Vorgehen

  1. Ausgangszustand sichern.
  2. DNS-Auflösung prüfen.
  3. TCP-Verbindung prüfen.
  4. Vergleichsclient testen.
  5. anderes Kabel oder anderen Port testen.
  6. nach jedem Schritt denselben Funktionstest wiederholen.
  7. erst danach eine freigegebene Konfigurationsänderung durchführen.

8. Kontrollvariable und Vergleichssystem verwenden

Ein Vergleichssystem hilft zu erkennen, ob eine Ursache:

Test Konstante Werte Veränderte Variable
Gleicher Benutzer, anderer Client Benutzer, Ziel, Funktion Client
Anderer Benutzer, gleicher Client Client, Ziel, Funktion Benutzer
Gleicher Client, anderes VLAN Client, Benutzer, Ziel Netzwerkpfad
Gleiches VLAN, anderer Client Netzwerk, Ziel Client
Gleiches Ziel, direkter Porttest Client, Netzwerk, Ziel Anwendungsebene
Gleiche URL, bestimmtes Backend Client, URL, Hostname Backend
Gleiche Datei, anderes Konto Datei, Client, Pfad Berechtigung
Gleicher Dienst, localhost Server, Dienst, Port Netzwerkpfad entfällt

Je weniger Variablen sich zwischen den Testfällen unterscheiden, desto aussagekräftiger ist der Vergleich.

9. Testzeitpunkt dokumentieren

Windows

[RO] Get-Date -Format o

UTC-Zeit

[RO] (Get-Date).ToUniversalTime().ToString("o")

Linux

[RO] date --iso-8601=seconds

macOS

[RO] date "+%Y-%m-%dT%H:%M:%S%z"

Der Zeitpunkt sollte unmittelbar vor und nach dem Test erfasst werden. Dadurch kann die Ausgabe mit Server-, Firewall-, Proxy- und SIEM-Protokollen verglichen werden.

10. PowerShell-Sitzung protokollieren

PowerShell kann Befehle und Konsolenausgaben einer Sitzung in einer Transkriptdatei aufzeichnen.

Protokollierung starten

[FILE][SENSITIV] Start-Transcript -Path "<Zielpfad>\Testprotokoll.txt" -IncludeInvocationHeader -NoClobber

Protokollierung beenden

[FILE] Stop-Transcript

-IncludeInvocationHeader ergänzt Zeitinformationen zu den ausgeführten Befehlen.

-NoClobber verhindert, dass eine bereits vorhandene Datei überschrieben wird.

Zu beachten

11. Linux- und macOS-Terminalsitzung protokollieren

Das Werkzeug script erstellt eine Aufzeichnung der Terminalsitzung.

Aufzeichnung starten

[FILE][SENSITIV] script "<Zielpfad>/Testprotokoll.txt"

Anschließend werden die vorgesehenen Diagnosebefehle ausgeführt.

Aufzeichnung beenden

exit

Alternativ kann die Sitzung mit Strg + D beendet werden.

Zu beachten

12. Einzelne PowerShell-Ausgabe in Datei und Konsole schreiben

Tee-Object zeigt die Ausgabe auf der Konsole an und speichert sie gleichzeitig in einer Datei.

[FILE] Test-NetConnection server.example -Port 443 -InformationLevel Detailed | Tee-Object -FilePath "<Zielpfad>\tcp-test.txt"

Mit Zeitstempel

Get-Date -Format o |
    Tee-Object -FilePath "<Zielpfad>\tcp-test.txt"

Test-NetConnection server.example -Port 443 -InformationLevel Detailed |
    Tee-Object -FilePath "<Zielpfad>\tcp-test.txt" -Append

-Append fügt die Ausgabe an die vorhandene Datei an.

13. Einzelne Linux- oder macOS-Ausgabe sichern

Ausgabe und Fehlermeldungen in eine Datei schreiben

[FILE] <Befehl> > "<Zielpfad>/test-output.txt" 2>&1

Ausgabe gleichzeitig anzeigen und speichern

[FILE] <Befehl> 2>&1 | tee "<Zielpfad>/test-output.txt"

Bei einer Pipeline mit tee kann der direkt danach angezeigte Rückgabewert zur letzten Komponente der Pipeline gehören. Wenn der ursprüngliche Rückgabewert wichtig ist, sollte der Befehl zunächst ohne Pipeline ausgeführt und anschließend die Datei angezeigt werden.

Rückgabewert zuverlässig sichern

started_at=$(date "+%Y-%m-%dT%H:%M:%S%z")
curl --connect-timeout 5 --max-time 15 https://server.example/ > "<Zielpfad>/curl-test.txt" 2>&1
test_rc=$?
ended_at=$(date "+%Y-%m-%dT%H:%M:%S%z")

echo "Start: $started_at"
echo "Ende: $ended_at"
echo "Exit-Code: $test_rc"
cat "<Zielpfad>/curl-test.txt"

Der Rückgabewert muss unmittelbar nach dem geprüften Befehl in einer Variablen gesichert werden.

14. Rückgabewerte unter Windows auswerten

PowerShell-Cmdlets

$? zeigt an, ob die unmittelbar vorherige PowerShell-Operation erfolgreich abgeschlossen wurde.

[RO] $?

Mögliche Werte:

Native Programme

$LASTEXITCODE enthält den Rückgabewert des zuletzt ausgeführten nativen Programms.

curl.exe --connect-timeout 5 --max-time 15 https://server.example/
$curlExitCode = $LASTEXITCODE
"curl Exit-Code: $curlExitCode"

Windows-Eingabeaufforderung

[RO] echo %ERRORLEVEL%

Der Rückgabewert muss direkt nach dem betreffenden Programm geprüft werden. Ein nachfolgender Befehl kann den gespeicherten Wert verändern.

15. Rückgabewerte unter Linux und macOS auswerten

$? enthält den Rückgabewert des zuletzt ausgeführten Befehls.

curl --connect-timeout 5 --max-time 15 https://server.example/
test_rc=$?
echo "Exit-Code: $test_rc"

Unter Unix-artigen Systemen bedeutet üblicherweise:

Rückgabewert Allgemeine Bedeutung
0 Programm meldet Erfolg
ungleich 0 Programm meldet Fehler oder besonderen Zustand

Die genaue Bedeutung hängt vom jeweiligen Programm ab und muss in dessen Dokumentation geprüft werden.

16. Erfolg des Werkzeugs und Erfolg der Funktion unterscheiden

Ein Rückgabewert 0 bedeutet nicht automatisch, dass die vom Benutzer benötigte Funktion erfolgreich war.

Beispiel mit curl

Ohne zusätzliche Option kann curl eine HTTP-Antwort 404, 403 oder 500 empfangen und trotzdem mit Exit-Code 0 enden. Die Netzwerkübertragung war erfolgreich, obwohl die Anwendung einen Fehlerstatus zurückgab.

Deshalb müssen mindestens zwei Ebenen getrennt werden:

Ebene Beispiel
Werkzeugausführung curl konnte eine HTTP-Antwort empfangen
Fachliche Funktion Benutzer konnte sich erfolgreich anmelden
Anwendungsstatus Server antwortete mit HTTP 200
Inhaltliche Richtigkeit Gelieferte Daten sind vollständig und korrekt

HTTP-Fehler als curl-Fehler behandeln

[TEST] curl --fail --connect-timeout 5 --max-time 15 https://server.example/

Die Option --fail lässt curl bei HTTP-Statuscodes ab 400 einen Fehler melden. Dabei wird der Antworttext normalerweise nicht ausgegeben.

Für eine Diagnose ist es häufig besser, zunächst HTTP-Status und Ausgabe separat zu dokumentieren.

17. Zeitbegrenzungen verwenden

Tests sollten nicht unbegrenzt warten.

Windows

[TEST] curl.exe --connect-timeout 5 --max-time 15 https://server.example/

Linux

[TEST] curl --connect-timeout 5 --max-time 15 https://server.example/

macOS

[TEST] curl --connect-timeout 5 --max-time 15 https://server.example/

Option Bedeutung
--connect-timeout 5 maximal fünf Sekunden für die Verbindungsphase
--max-time 15 maximal 15 Sekunden für den gesamten Transfer

Zur Verbindungsphase gehören bei curl unter anderem DNS-Auflösung sowie TCP-, TLS- oder QUIC-Verbindungsaufbau.

18. HTTP-Zeiten gezielt messen

curl kann einzelne Zeitabschnitte einer HTTP-Verbindung ausgeben.

Windows PowerShell

[TEST] curl.exe -sS -o NUL -w 'code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' --connect-timeout 5 --max-time 15 https://server.example/

Linux und macOS

[TEST] curl -sS -o /dev/null -w "code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n" --connect-timeout 5 --max-time 15 https://server.example/

Bedeutung der Werte

Wert Bedeutung
http_code empfangener HTTP-Status
remote_ip tatsächlich verwendete Ziel-IP
time_namelookup Zeit bis zum Abschluss der Namensauflösung
time_connect Zeit bis zum TCP-Verbindungsaufbau
time_appconnect Zeit bis zum Abschluss des TLS-Handshakes
time_starttransfer Zeit bis zum ersten empfangenen Byte
time_total gesamte Übertragungszeit

Die Zeitwerte werden in Sekunden ausgegeben.

19. HTTP-Zeitwerte interpretieren

Beobachtung Mögliche Ursache
time_namelookup hoch DNS-Server, Resolver oder Weiterleitung langsam
time_connect hoch Netzwerkpfad, Firewall, Überlastung oder Server
time_appconnect deutlich höher TLS-Handshake, Zertifikat oder Kryptografie
time_starttransfer hoch Anwendung oder Backend benötigt lange
time_total hoch, erstes Byte schnell langsame Datenübertragung oder große Antwort
wechselnde remote_ip DNS-Rotation, Load Balancer oder mehrere Backends
wechselnder HTTP-Status unterschiedliche Backends oder instabiler Dienst
http_code=000 keine gültige HTTP-Antwort empfangen

Ein einzelner Messwert reicht bei sporadischen Fehlern nicht aus. Mehrere Messungen mit Zeitstempel sind aussagekräftiger.

20. Tests wiederholen, ohne unnötige Last zu erzeugen

Windows-Ping

[TEST] ping -n 10 <IP-Adresse>

Linux und macOS

[TEST] ping -c 10 <IP-Adresse>

Wiederholter TCP-Test unter Windows

1..5 | ForEach-Object {
    $result = Test-NetConnection server.example -Port 443 -InformationLevel Detailed

    [pscustomobject]@{
        Time          = Get-Date -Format o
        RemoteAddress = $result.RemoteAddress
        SourceAddress = $result.SourceAddress
        Success       = $result.TcpTestSucceeded
    }

    Start-Sleep -Seconds 2
}

Wiederholter TCP-Test unter Linux und macOS

for test_number in 1 2 3 4 5
do
    date "+%Y-%m-%dT%H:%M:%S%z"
    nc -vz -w 3 server.example 443
    sleep 2
done

Vor Wiederholungstests ist zu prüfen:

21. Sporadische Fehler richtig untersuchen

Ein sporadischer Fehler kann übersehen werden, wenn nur ein einzelner Test durchgeführt wird.

Zu dokumentieren sind:

Beispiel

Versuch Uhrzeit Ziel-IP TCP HTTP Gesamtzeit
1 15:30:00 198.51.100.20 erfolgreich 200 0,21 s
2 15:30:05 198.51.100.21 erfolgreich 503 4,92 s
3 15:30:10 198.51.100.20 erfolgreich 200 0,19 s
4 15:30:15 198.51.100.21 erfolgreich 503 5,01 s
5 15:30:20 198.51.100.20 erfolgreich 200 0,22 s

Das Muster deutet auf ein Problem mit dem Backend 198.51.100.21 hin.

22. Bestimmtes HTTPS-Ziel ohne DNS-Änderung testen

Der Aufruf einer HTTPS-Seite direkt über ihre IP-Adresse kann zu falschen Ergebnissen führen, weil:

Mit curl --resolve kann für einen einzelnen Test ein bestimmter Hostname einer bestimmten IP-Adresse zugeordnet werden, ohne DNS oder Hosts-Datei zu verändern.

Windows

[TEST] curl.exe --resolve "server.example:443:<IP-Adresse>" -v -o NUL https://server.example/

Linux und macOS

[TEST] curl --resolve "server.example:443:<IP-Adresse>" -v -o /dev/null https://server.example/

Dadurch bleiben erhalten:

Nur die Ziel-IP wird für diesen curl-Aufruf vorgegeben.

Beispiel für zwei Backends

[TEST] curl --resolve "server.example:443:198.51.100.20" -v -o /dev/null https://server.example/

[TEST] curl --resolve "server.example:443:198.51.100.21" -v -o /dev/null https://server.example/

Das direkte Testen eines Backends kann Load Balancer, WAF oder andere Schutzsysteme umgehen. Es darf nur erfolgen, wenn dieser Test technisch vorgesehen und autorisiert ist.

23. Lokalen Dienst und Netzwerkpfad getrennt testen

Windows-Server

[TEST] Test-NetConnection localhost -Port <Port>

[TEST] Test-NetConnection <Eigene-Server-IP> -Port <Port>

[TEST] Test-NetConnection <Servername> -Port <Port>

Linux-Server

[TEST] nc -vz -w 3 localhost <Port>

[TEST] nc -vz -w 3 <Eigene-Server-IP> <Port>

[TEST] nc -vz -w 3 <Servername> <Port>

macOS-Server

[TEST] nc -vz -w 3 localhost <Port>

[TEST] nc -vz -w 3 <Eigene-Server-IP> <Port>

[TEST] nc -vz -w 3 <Servername> <Port>

Interpretation

localhost Eigene IP Remote-Client Möglicher Fehlerbereich
erfolgreich erfolgreich erfolgreich Netzwerkgrundfunktion vorhanden
erfolgreich erfolgreich fehlgeschlagen Netzwerkpfad oder Firewall
erfolgreich fehlgeschlagen fehlgeschlagen Listener-Bindung oder lokale Firewall
fehlgeschlagen fehlgeschlagen fehlgeschlagen Dienst oder Anwendung
fehlgeschlagen erfolgreich erfolgreich besondere Proxy-, Container- oder Weiterleitungskonfiguration

24. Test mit und ohne Namensauflösung

DNS-basierter Test

[TEST] Test-NetConnection server.example -Port 443

Direkter TCP-Test zur bekannten IP

[TEST] Test-NetConnection <IP-Adresse> -Port 443

Unter Linux und macOS:

[TEST] nc -vz -w 3 server.example 443

[TEST] nc -vz -w 3 <IP-Adresse> 443

Interpretation

Name IP Möglicher Fehlerbereich
erfolgreich erfolgreich DNS und TCP-Grundfunktion vorhanden
fehlgeschlagen erfolgreich DNS oder Namensauswahl
erfolgreich fehlgeschlagen Testfehler oder unterschiedliche Zieladresse prüfen
fehlgeschlagen fehlgeschlagen Netzwerk, Firewall, Dienst oder Zielsystem

Der direkte IP-Test ist für TCP geeignet. Für HTTPS sollte wegen Host-Header, SNI und Zertifikatsprüfung curl --resolve verwendet werden.

25. Anwendungstest und Benutzerfunktion trennen

Ein technischer Test kann erfolgreich sein, obwohl die Benutzerfunktion weiterhin fehlschlägt.

Prüfebene Beispiel
DNS Hostname wird aufgelöst
Netzwerk Ziel-IP ist erreichbar
Transport TCP-Port ist erreichbar
TLS Zertifikat und Handshake funktionieren
HTTP Server liefert eine Antwort
Authentifizierung Benutzer kann sich anmelden
Autorisierung Benutzer darf die Funktion verwenden
Anwendung gewünschte Aktion wird verarbeitet
Datenebene Datenbank speichert oder liefert korrekte Daten
Geschäftsprozess gesamter Arbeitsablauf funktioniert

Beispiel

Die Ursache liegt dann nicht in der grundlegenden Erreichbarkeit, sondern möglicherweise in:

26. Vorher- und Nachher-Test identisch durchführen

Nach einer Maßnahme muss derselbe definierte Test erneut ausgeführt werden.

Ungeeigneter Vergleich

Diese Ergebnisse prüfen unterschiedliche Funktionen.

Geeigneter Vergleich

27. Vorher-Nachher-Protokoll

Feld Vorher Nachher
Zeitpunkt
Quellsystem
Quell-IP
Benutzer
Zielsystem
Ziel-IP
Protokoll und Port
DNS-Ergebnis
TCP-Ergebnis
TLS-Ergebnis
HTTP-Status
Antwortzeit
Anwendungsfunktion
Fehlermeldung
Monitoringstatus
Rückgabewert

28. Erfolgskriterien definieren

Ein Erfolgskriterium muss messbar sein.

Ungeeignet

Das System läuft wieder normal.

Besser

Schwellenwerte dürfen nicht frei erfunden werden. Sie müssen aus:

abgeleitet werden.

29. Abbruchkriterien definieren

Ein Test muss abgebrochen werden, wenn beispielsweise:

Abbruchvorlage

Feld Eintrag
Abbruchbedingung
Messgröße
Grenzwert
Verantwortliche Person
Sofortmaßnahme
Rückfallmaßnahme
Kommunikationsweg

30. Testergebnisse klassifizieren

Status Bedeutung
Bestanden Definiertes Erfolgskriterium vollständig erreicht
Nicht bestanden Definiertes Erfolgskriterium nicht erreicht
Teilweise bestanden Nur ein Teil der Kriterien erreicht
Nicht eindeutig Ergebnis lässt mehrere Erklärungen zu
Nicht reproduzierbar Fehler trat bei Wiederholung nicht erneut auf
Abgebrochen Abbruchkriterium wurde erreicht
Nicht durchgeführt Test konnte nicht ausgeführt werden
Ungültig Testbedingungen oder Messung waren fehlerhaft

„Nicht eindeutig“ ist ein gültiges Ergebnis. Es ist besser als eine unberechtigte Bestätigung.

31. Hypothese nach dem Test bewerten

Testergebnis Bewertung der Hypothese
Vorhersage vollständig eingetroffen Hypothese wird gestützt
Vorhersage mehrfach reproduziert Hypothese wird stark gestützt
Gegenprobe erfolgreich Ursache möglicherweise bestätigt
Ergebnis teilweise passend Hypothese bleibt offen
Ergebnis mehrdeutig neuer trennschärferer Test erforderlich
Vorhersage nicht eingetroffen Hypothese wird geschwächt
Widerlegendes Ergebnis eingetroffen Hypothese gilt als widerlegt
Testbedingungen fehlerhaft keine Bewertung möglich

Ein fehlgeschlagener Test bestätigt nicht automatisch die untersuchte Ursache. Er zeigt zunächst nur, dass die getestete Funktion unter den verwendeten Bedingungen fehlgeschlagen ist.

32. Falsch positive Ergebnisse

Ein Test meldet einen Fehler, obwohl die eigentliche Funktion verfügbar ist.

Beispiele

Test Falsch positives Ergebnis
Ping keine Antwort, weil ICMP blockiert ist
Traceroute Sternchen, obwohl Ziel erreichbar ist
Portscanner Port wirkt gefiltert, weil Sicherheitskomponente reagiert
DNS-Test anderer Load-Balancer wird als „falsche IP“ interpretiert
Zertifikatstest direkter IP-Aufruf erzeugt absichtlich Namensfehler
Dienststatus Dienst ist gestoppt, weil er socket-aktiviert gestartet wird
HTTP-HEAD Server lehnt HEAD ab, verarbeitet aber GET
Monitoring veralteter Alarm bleibt nach Wiederherstellung aktiv

33. Falsch negative Ergebnisse

Ein Test meldet Erfolg, obwohl die Benutzerfunktion weiterhin gestört ist.

Beispiele

Test Falsch negatives Ergebnis
Ping erfolgreich Anwendung oder Port kann trotzdem ausgefallen sein
TCP-Port erreichbar Anwendung kann fehlerhafte Antworten liefern
HTTP 200 Anmeldung oder Fachfunktion kann trotzdem fehlschlagen
Dienststatus „Running“ Prozess kann intern hängen
DNS-Auflösung erfolgreich zurückgegebene Adresse kann falsch sein
Einzelner Test erfolgreich sporadischer Fehler wird nicht erfasst
Testkonto funktioniert normales Benutzerkonto kann weiterhin falsche Rechte haben
Ein Backend funktioniert anderes Backend kann fehlerhaft sein
Speicherplatz vorhanden Inodes oder Quota können trotzdem erschöpft sein

34. Testwerkzeug und Testpunkt dokumentieren

Ein Ergebnis ist nur verständlich, wenn bekannt ist, wo und wie gemessen wurde.

Zu dokumentieren

Werkzeugversionen anzeigen

PowerShell

[RO] $PSVersionTable

curl

[RO] curl --version

OpenSSL

[RO] openssl version -a

Linux-Kernel

[RO] uname -a

macOS

[RO] sw_vers

Unterschiedliche Werkzeugversionen können verschiedene Optionen, Protokolle oder Standardwerte verwenden.

35. Produktivumgebung gegen Testumgebung abwägen

Umgebung Vorteil Nachteil
Produktionssystem reales Fehlerbild Risiko für Benutzer und Daten
Testsystem geringeres Risiko möglicherweise nicht identische Konfiguration
Staging produktionsähnlich möglicherweise andere Daten oder Last
isolierter Client einzelne Variable kontrollierbar nicht jeder Netzwerkpfad wird abgebildet
Snapshot-Kopie Zustand kann untersucht werden flüchtige Informationen fehlen möglicherweise
Labor Tests gut reproduzierbar Produktionsabhängigkeiten fehlen

Ein Testsystem ist nur dann aussagekräftig, wenn relevante Unterschiede zur Produktion dokumentiert sind.

36. Änderungen in der Produktion absichern

Vor einer verändernden Prüfung sollten geklärt sein:

Freigabevorlage

Feld Eintrag
Ticketnummer
Hypothese
geplante Änderung
betroffene Systeme
erwartete Auswirkung
Risiko
Wartungsfenster
Backup vorhanden Ja / Nein
Rückfallplan
Abbruchkriterium
Freigabe durch
ausführende Person
beobachtende Person

37. Tests mit Anmeldungen vorsichtig durchführen

Anmeldetests können:

Vor einem Anmeldetest prüfen:

Kennwörter, Token und API-Schlüssel dürfen nicht in Protokolldateien, Terminaltranskripten oder Befehlszeilen erscheinen.

38. Beispiel eines kontrollierten Tests

Störung

Eine Webanwendung liefert sporadisch HTTP 503.

Hypothesen

Prüfplan

Schritt Test Erwarteter Erkenntnisgewinn
1 DNS mehrfach abfragen verwendete Zieladressen bestimmen
2 curl-Zeitmessung wiederholen HTTP-Status, Ziel-IP und Zeitstufe erfassen
3 Backends einzeln mit --resolve testen fehlerhaftes Backend identifizieren
4 TCP- und TLS-Ergebnisse vergleichen Netzwerk- und TLS-Ursachen bewerten
5 Serverlogs zum Zeitpunkt prüfen Backendfehler bestätigen

Ergebnis

Bewertung

39. Testprotokoll-Vorlage

Feld Eintrag
Ticketnummer
Testnummer
Hypothesennummer
Prüfziel
Datum
Startzeit
Endzeit
Zeitzone
ausführende Person
Quellsystem
Quell-IP und VLAN
Zielsystem
Ziel-IP
Protokoll und Port
Benutzerkontext
Werkzeug und Version
exakter Befehl
Ausgangszustand
erwartetes Ergebnis
widerlegendes Ergebnis
tatsächliches Ergebnis
Rückgabewert
Ausgabedatei
Hypothesenbewertung
Nebenwirkungen
Rückfall durchgeführt Ja / Nein / Nicht erforderlich
Zustand nach dem Test
nächster Schritt

Kurzcheckliste

Ergebnis dieses Arbeitsschrittes

Am Ende dieses Schrittes liegt ein nachvollziehbares und reproduzierbares Testergebnis vor.

Ein brauchbares Testergebnis beantwortet:

Nächste Seite:
1.7 Ursache bestätigen und alternative Erklärungen ausschließen

Offizielle Hersteller- und Projektdokumentation

1. Grundlagen der systematischen Fehleranalyse

1.7 Ursache bestätigen und alternative Erklärungen ausschließen

Eine plausible Hypothese ist noch keine bestätigte Ursache. Auch wenn eine Maßnahme scheinbar erfolgreich war, kann ein anderer gleichzeitig veränderter Zustand für die Wiederherstellung verantwortlich gewesen sein.

Deshalb gilt:

Eine Ursache muss das Fehlerbild technisch erklären, zu Umfang und Zeitpunkt passen und durch Belege oder Gegenproben gestützt werden.

In komplexen IT-Systemen existiert häufig nicht nur eine einzelne Ursache. Meist wirken Auslöser, technische Fehler, Abhängigkeiten und begünstigende Bedingungen zusammen.

Ziel dieser Seite

Nach diesem Arbeitsschritt sollten:

1. Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] Read-only: liest Informationen aus
[TEST] Führt eine aktive Prüfung aus
[FILE] Erstellt oder überschreibt eine Datei
[PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte
[CHANGE] Verändert Konfiguration oder Betriebszustand
[DISRUPTIV] Kann Benutzer oder produktive Dienste beeinträchtigen
[SENSITIV] Ausgabe kann vertrauliche Daten enthalten

2. Symptom, unmittelbare Ursache und Grundursache unterscheiden

Ebene Bedeutung Beispiel
Symptom Sichtbare Auswirkung Webanwendung liefert HTTP 503
Unmittelbare technische Ursache Zustand, der das Symptom direkt erzeugt Backend kann keine Datenbankverbindung aufbauen
Auslöser Ereignis, das den Fehler aktiviert hat Neue Konfiguration wurde bereitgestellt
Grundursache Systemischer Grund, warum der Fehler möglich war Pipeline prüfte den Datenbank-Hostnamen nicht
Begünstigender Faktor Bedingung, die Entstehung oder Auswirkung verstärkte Änderung wurde gleichzeitig auf allen Backends verteilt
Erkennungslücke Grund für eine verspätete Erkennung Monitoring prüfte nur, ob TCP 443 erreichbar war
Wiederherstellungsfaktor Maßnahme, die den Betrieb wiederherstellte Konfigurationsrollback
Präventionsmaßnahme Maßnahme gegen eine Wiederholung Validierung und schrittweise Bereitstellung einführen

3. Beispiel einer vollständigen Ursachenkette

Ebene Feststellung
Symptom Benutzer erhalten HTTP 503
Direkte Ursache Webanwendung erreicht die Datenbank nicht
Technischer Mechanismus Falscher Datenbank-Hostname in der Anwendungskonfiguration
Auslöser Deployment um 14:31 Uhr
Grundursache Deployment-Pipeline akzeptiert ungeprüfte Konfigurationswerte
Begünstigender Faktor Änderung wurde auf allen Instanzen gleichzeitig ausgerollt
Erkennungslücke Kein Ende-zu-Ende-Monitoring der Anmeldung
Wiederherstellung Vorherige Konfiguration wurde wiederhergestellt
Prävention Schema-Validierung, Staging-Test und schrittweiser Rollout

Die Aussage „Das Deployment war schuld“ wäre zu ungenau. Erst die vollständige Ursachenkette zeigt, was technisch fehlschlug und wodurch eine Wiederholung verhindert werden kann.

4. Nicht vorschnell nach einer einzigen Ursache suchen

Komplexe Störungen entstehen häufig durch eine Kombination mehrerer Bedingungen.

Beispiel

Ein einzelnes fehlerhaftes Backend führt nicht zwangsläufig zu einem Gesamtausfall. Der Ausfall entsteht möglicherweise erst, weil zusätzlich:

In diesem Fall gibt es mehrere relevante Ursachen und beitragende Faktoren.

Zu dokumentierende Ursachenarten

5. Eine Ursache gilt nicht allein durch zeitliche Nähe als bestätigt

Unzureichende Aussage

Der Fehler begann nach dem Update, also war das Update die Ursache.

Erforderliche Zusatzfragen

6. Stärke von Belegen bewerten

Beleg Aussagekraft
Vermutung ohne Messwert Sehr gering
Einzelne Benutzerangabe Gering
Zeitliche Nähe Gering bis mittel
Passende Fehlermeldung Mittel
Reproduzierbares Muster Mittel bis hoch
Konfigurationsunterschied zum funktionierenden System Hoch
Protokoll zeigt direkten technischen Fehler Hoch
Paketaufzeichnung bestätigt Kommunikationsfehler Hoch
Fehler verschwindet nach kontrollierter Entfernung der Ursache Sehr hoch
Fehler erscheint in Testumgebung nach kontrollierter Wiederherstellung der Ursache erneut Sehr hoch
Mehrere voneinander unabhängige Belege stimmen überein Sehr hoch

Eine zuverlässige Bestätigung verwendet möglichst mehrere voneinander unabhängige Belege.

7. Kriterien für eine bestätigte Ursache

Eine Ursache sollte möglichst folgende Fragen beantworten:

Kriterium Frage
Technischer Mechanismus Wie erzeugt die Ursache das beobachtete Symptom?
Fehlerumfang Warum sind genau diese Systeme oder Benutzer betroffen?
Zeitlicher Zusammenhang Warum begann der Fehler zu diesem Zeitpunkt?
Reproduzierbarkeit Lässt sich das Verhalten kontrolliert wiederholen?
Vergleich Warum funktionieren nicht betroffene Systeme?
Gegenprobe Verschwindet das Symptom ohne die vermutete Ursache?
Alternativen Welche anderen Erklärungen wurden geprüft?
Widersprüche Gibt es Fakten, die nicht zur Ursache passen?
Beweislage Welche Logs, Messwerte oder Vergleiche bestätigen sie?
Wiederholungsschutz Welche Maßnahme verhindert ein erneutes Auftreten?

Wenn eine vermutete Ursache den Umfang oder den technischen Mechanismus nicht erklären kann, ist sie wahrscheinlich unvollständig.

8. Die Gegenfrage stellen

Eine besonders wichtige Frage lautet:

Was müsste beobachtet werden, wenn die vermutete Ursache nicht stimmt?

Beispiel

Hypothese:

Eine Firewall-Regel blockiert TCP 443 aus VLAN 30.

Mögliche Gegenbelege:

Gegenbelege müssen genauso sorgfältig dokumentiert werden wie unterstützende Belege.

9. Kontrafaktische Prüfung

Eine kontrafaktische Prüfung untersucht, was ohne die vermutete Ursache geschehen würde.

Frage Bedeutung
Wäre die Störung ohne diese Bedingung aufgetreten? Prüft die Notwendigkeit der Ursache
Existiert dieselbe Bedingung auf funktionierenden Systemen? Prüft, ob sie allein ausreichend ist
Verschwindet der Fehler, wenn die Bedingung entfernt wird? Prüft den direkten Zusammenhang
Erscheint der Fehler in einer Testumgebung erneut? Prüft Reproduzierbarkeit
Erklärt die Ursache auch die nicht betroffenen Systeme? Prüft den Fehlerumfang
Gibt es einen anderen Faktor mit derselben Wirkung? Prüft alternative Erklärungen

Eine Bedingung kann notwendig, aber allein nicht ausreichend sein. Beispielsweise kann ein fehlerhaftes Backend erst zusammen mit einer fehlerhaften Load-Balancer-Konfiguration einen vollständigen Ausfall verursachen.

10. Ursachenbestätigung mit A/B-Vergleich

Zustand A Zustand B Mögliche Interpretation
Betroffenes System Funktionierendes System Unterschiede priorisieren
Fehlerhafte Konfiguration Bekannte funktionierende Konfiguration Konfigurationsunterschied prüfen
Benutzer A gestört Benutzer B funktioniert Konto oder Berechtigung prüfen
VLAN 30 gestört VLAN 40 funktioniert Netzwerkpfad oder ACL prüfen
Backend 1 funktioniert Backend 2 gestört Backend-spezifische Ursache
Anwendungsversion alt funktioniert neue Version gestört Versionsänderung priorisieren
Proxy verwendet direkter Test funktioniert Proxy oder Proxyrichtlinie prüfen
DNS-Auflösung verwendet festes Ziel funktioniert DNS oder Zielauswahl prüfen

Der Vergleich ist nur aussagekräftig, wenn alle nicht untersuchten Bedingungen möglichst gleich bleiben.

11. Betroffenes und funktionierendes System vergleichen

Zu vergleichende Eigenschaften

Bereich Beispiele
Betriebssystem Version, Build, Kernel
Updates Patchstand und Installationszeit
Anwendung Version, Module, Erweiterungen
Konfiguration Inhalt, Prüfsumme, Änderungszeit
Dienste Status, Starttyp, Dienstkonto
Netzwerk IP, VLAN, Gateway, DNS, Proxy
Sicherheit Firewallprofil, EDR, Zertifikate
Benutzer Gruppen, Rollen, Richtlinien
Dateien Version, Besitzer, Rechte, ACL
Abhängigkeiten Datenbank, API, Storage, DNS
Umgebung Variablen, Pfade, Laufzeitversion
Ressourcen CPU, RAM, Datenträger, Quota

12. Dateien und Konfigurationen unter Windows vergleichen

Dateiinhalte vergleichen

[RO] Compare-Object (Get-Content "<Funktionierende-Datei>") (Get-Content "<Betroffene-Datei>")

SHA-256-Prüfsumme bilden

[RO] Get-FileHash "<Datei>" -Algorithm SHA256

Dateiinformationen anzeigen

[RO] Get-Item "<Datei>" | Select-Object FullName, Length, CreationTime, LastWriteTime

Versionsinformationen einer ausführbaren Datei

[RO] (Get-Item "<Dateipfad>").VersionInfo

Berechtigungen anzeigen

[RO][SENSITIV] Get-Acl "<Pfad>" | Format-List

Installierte Hotfixes vergleichen

[RO] Get-HotFix | Sort-Object InstalledOn -Descending

13. Dateien und Konfigurationen unter Linux vergleichen

Dateien zeilenweise vergleichen

[RO] diff -u "<Funktionierende-Datei>" "<Betroffene-Datei>"

SHA-256-Prüfsumme bilden

[RO] sha256sum "<Datei>"

Dateiinformationen anzeigen

[RO] stat "<Datei>"

Dateityp bestimmen

[RO] file "<Datei>"

Berechtigungen und ACL anzeigen

[RO][SENSITIV] getfacl "<Datei>"

Debian- oder Ubuntu-Paketversion

[RO] dpkg-query -W "<Paketname>"

RHEL-, Rocky-, AlmaLinux- oder Fedora-Paketversion

[RO] rpm -q "<Paketname>"

14. Dateien und Konfigurationen unter macOS vergleichen

Dateien zeilenweise vergleichen

[RO] diff -u "<Funktionierende-Datei>" "<Betroffene-Datei>"

SHA-256-Prüfsumme bilden

[RO] shasum -a 256 "<Datei>"

Dateiinformationen anzeigen

[RO] stat -x "<Datei>"

Dateityp bestimmen

[RO] file "<Datei>"

Berechtigungen und ACL anzeigen

[RO][SENSITIV] ls -lde "<Datei>"

Anwendungsversion über Systeminformationen suchen

[RO] system_profiler SPApplicationsDataType

Bei umfangreichen Installationen kann system_profiler SPApplicationsDataType längere Zeit benötigen und eine große Ausgabe erzeugen.

15. Prüfsummen richtig interpretieren

Ergebnis Bedeutung
Prüfsummen identisch Dateien sind zum Prüfzeitpunkt binär identisch
Prüfsummen unterschiedlich Mindestens ein Byte unterscheidet sich
Dateiinhalt gleich, Metadaten anders Besitzer, Rechte oder Zeitstempel können abweichen
Anwendungsversion gleich, Prüfsumme anders anderer Build, beschädigte Datei oder Modifikation möglich
Prüfsumme gleich, Verhalten anders Ursache liegt wahrscheinlich außerhalb der Datei

Eine identische Prüfsumme beweist nicht, dass die gesamte Umgebung identisch ist.

16. Dienstabhängigkeiten unter Windows prüfen

Benötigte Dienste anzeigen

[RO] Get-Service -Name <Dienstname> -RequiredServices

Abhängige Dienste anzeigen

[RO] Get-Service -Name <Dienstname> -DependentServices

Dienstkonfiguration anzeigen

[RO] sc.exe qc <Dienstname>

Erweiterte Dienstinformationen

[RO][SENSITIV] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object Name, State, StartMode, StartName, PathName, ProcessId

Dienstereignisse anzeigen

[RO] Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"; StartTime=(Get-Date).AddHours(-1)} | Select-Object TimeCreated, Id, Message

Listener eines Dienstes prüfen

[RO][PRIV] Get-NetTCPConnection -State Listen -LocalPort <Port>

Prozess zum Listener bestimmen

[RO] Get-Process -Id <OwningProcess>

17. Dienstabhängigkeiten unter Linux prüfen

Abhängigkeiten eines Dienstes anzeigen

[RO] systemctl list-dependencies <Dienstname>.service --all

Dienste anzeigen, die vom untersuchten Dienst abhängen

[RO] systemctl list-dependencies <Dienstname>.service --reverse --all

Deklarierte Abhängigkeiten und Reihenfolge

[RO] systemctl show <Dienstname>.service -p Requires -p Wants -p After -p Before

Effektive Unit-Konfiguration anzeigen

[RO] systemctl cat <Dienstname>.service

Dienstzustand anzeigen

[RO] systemctl status <Dienstname>.service --no-pager

Dienstprotokoll anzeigen

[RO] journalctl -u <Dienstname>.service --since "1 hour ago" --no-pager

Listener prüfen

[RO][PRIV] ss -lntp | grep ":<Port>"

Prozess untersuchen

[RO] ps -p <PID> -o pid,ppid,user,lstart,stat,%cpu,%mem,command

18. Dienstzustand unter macOS prüfen

macOS verwendet launchd. Die richtige Dienst-Domain hängt davon ab, ob es sich um einen System-, Benutzer- oder GUI-Dienst handelt.

Geladene Dienste anzeigen

[RO] launchctl list

Systemdienst untersuchen

[RO][PRIV] launchctl print system/<Dienstlabel>

Benutzerdienst untersuchen

[RO] launchctl print gui/<Benutzer-ID>/<Dienstlabel>

Die Benutzer-ID kann mit folgendem Befehl ermittelt werden:

[RO] id -u

Property-List anzeigen

[RO] plutil -p "<Pfad-zur-plist-Datei>"

Listener prüfen

[RO][PRIV] lsof -nP -iTCP:<Port> -sTCP:LISTEN

Prozess untersuchen

[RO] ps -p <PID> -o pid,ppid,user,lstart,state,%cpu,%mem,command

launchd bildet Abhängigkeiten nicht in derselben Weise wie systemd ab. Deshalb müssen zusätzlich verwendete Sockets, Dateien, Netzwerkziele und Anwendungsprotokolle geprüft werden.

19. Technische Abhängigkeiten vollständig betrachten

Ein sichtbarer Dienst kann von vielen weiteren Komponenten abhängen.

Komponente Mögliche Abhängigkeit
Client DNS, Proxy, Zertifikat, Richtlinie
DNS Zone, Forwarder, Netzwerk, Root-Server
Webserver Zertifikat, Dateisystem, Backend
Reverse Proxy Upstream, Health Check, DNS
Anwendung Datenbank, Cache, Queue, API
Datenbank Storage, Speicher, Replikation
Authentifizierung Active Directory, LDAP, RADIUS, MFA
Zertifikat CA, Zwischenzertifikat, Uhrzeit, Sperrprüfung
Dateifreigabe DNS, Kerberos, Berechtigung, Storage
Container Netzwerk, Volume, Secret, Image
Virtuelle Maschine Hypervisor, Datastore, virtuelles Netzwerk
Cloud-Dienst IAM, Sicherheitsgruppe, Region, Provider
Backup Agent, Repository, Netzwerk, Dienstkonto
Monitoring Agent, Collector, Zeit, Datenbank

20. Abhängigkeitskette dokumentieren

Beispiel: Anmeldung an einer Webanwendung

Reihenfolge Komponente Erforderliche Funktion
1 Client Netzwerkverbindung vorhanden
2 DNS Hostname wird korrekt aufgelöst
3 Firewall TCP 443 wird erlaubt
4 Load Balancer funktionsfähiges Backend wird gewählt
5 Webserver TLS und HTTP funktionieren
6 Anwendung Anmeldeanfrage wird verarbeitet
7 Identitätsdienst Benutzer wird authentifiziert
8 Datenbank Benutzer- und Sitzungsdaten sind verfügbar
9 Anwendung Rolle wird geprüft
10 Browser Sitzungscookie wird gespeichert

Ein Fehler in einer späteren Abhängigkeit kann nach außen wie ein allgemeiner „Webserverfehler“ wirken.

21. Abhängigkeit gezielt umgehen oder isolieren

Eine Komponente kann für einen Test kontrolliert aus dem Pfad genommen werden. Dies darf keine dauerhafte oder unautorisierte Umgehung von Sicherheitskontrollen werden.

DNS für einen einzelnen curl-Test umgehen

[TEST] curl --resolve "server.example:443:<IP-Adresse>" -v https://server.example/

Dadurch bleiben Hostname, HTTP-Host-Header, SNI und Zertifikatsprüfung erhalten.

Proxy für einen einzelnen curl-Test umgehen

[TEST] curl --noproxy "*" -v https://server.example/

Das Umgehen eines Unternehmensproxys kann gegen Sicherheitsrichtlinien verstoßen. Der Test darf nur durchgeführt werden, wenn direkte Verbindungen erlaubt und ausdrücklich autorisiert sind.

Anwendungsebene gegen Transportebene

Windows:

[TEST] Test-NetConnection server.example -Port 443

Linux und macOS:

[TEST] nc -vz -w 3 server.example 443

Anschließend:

[TEST] curl -v https://server.example/

TCP-Test HTTP-Test Wahrscheinlicher Bereich
erfolgreich erfolgreich grundlegender Dienstpfad funktioniert
erfolgreich fehlgeschlagen TLS, HTTP, Anwendung oder Authentifizierung
fehlgeschlagen nicht möglich Netzwerk, Firewall oder Listener
wechselnd wechselnd Load Balancer, Backend oder instabiler Pfad

22. Alternative Erklärungen bei typischen Beobachtungen

Beobachtung Mögliche alternative Erklärungen
Neustart löst Fehler Cache, Speicherleck, Prozesszustand, Verbindung, Timing
Dienstneustart löst Fehler Abhängigkeit wurde neu verbunden, Port freigegeben, Konfiguration neu geladen
DNS-Cache-Leerung löst Fehler TTL wäre gleichzeitig abgelaufen, DNS-Eintrag wurde parallel geändert
Firewall-Änderung löst Fehler Stateful Session wurde erneuert, NAT oder Route änderte sich
Update-Rollback löst Fehler Rollback enthielt ebenfalls Neustart oder Konfigurationsrücksetzung
Kabelwechsel löst Fehler Port wurde neu ausgehandelt, Switchport oder DHCP-Lease änderte sich
Anmeldung mit Testkonto funktioniert Konto, Rolle, Profil, MFA oder Lizenz unterscheiden sich
Zugriff über IP funktioniert DNS möglich, aber HTTPS über IP wurde nicht vollständig geprüft
Port ist offen Anwendung kann intern trotzdem fehlerhaft sein
Dienststatus ist „Running“ Prozess kann hängen oder Abhängigkeit nicht erreichen
Ein Test ist erfolgreich sporadischer Fehler kann weiterhin bestehen
Fehler verschwindet von selbst Last, Lease, TTL, Token oder Providerzustand änderte sich

23. Warum „Nach Maßnahme funktioniert es“ nicht immer genügt

Zwischen Maßnahme und erfolgreichem Test können weitere Veränderungen stattgefunden haben:

Deshalb müssen Zeitpunkt, technische Wirkung und Kontrolltest zusammen betrachtet werden.

24. Gegenprobe durchführen

Eine Gegenprobe testet, ob das Ergebnis wirklich von der vermuteten Ursache abhängt.

Geeignete Gegenproben

Nicht geeignete Gegenprobe

Eine produktive Fehlkonfiguration wird absichtlich erneut aktiviert, obwohl dadurch ein weiterer Ausfall entstehen könnte.

Eine erneute Fehlererzeugung gehört normalerweise in:

25. Die Fünf-Warum-Methode vorsichtig einsetzen

Die Fünf-Warum-Methode fragt wiederholt nach dem technischen oder organisatorischen Grund eines Fehlers.

Beispiel

Frage Antwort
Warum war die Anwendung nicht erreichbar? Der Dienst konnte nicht starten
Warum konnte der Dienst nicht starten? Die Konfigurationsdatei war ungültig
Warum war die Konfigurationsdatei ungültig? Ein Deployment setzte einen falschen Portwert
Warum wurde der falsche Wert akzeptiert? Es gab keine Schema-Validierung
Warum fehlte die Validierung? Sie war im Deploymentprozess nicht vorgesehen

Mögliche Grundursache

Der Deploymentprozess validiert Konfigurationswerte nicht vor der produktiven Bereitstellung.

Mögliche Prävention

26. Grenzen der Fünf-Warum-Methode

Die Methode darf nicht dazu führen, dass eine komplexe Störung künstlich auf eine einzelne lineare Ursache reduziert wird.

Mögliche Probleme

Für komplexe Störungen ist eine Ursachenmatrix häufig besser.

27. Ursachenmatrix

Faktor Vorhanden Notwendig Allein ausreichend Belegt Bewertung
Falscher Datenbank-Hostname Ja Ja Nein Konfigurationsvergleich Direkte Ursache
Keine Konfigurationsvalidierung Ja Nein Nein Pipeline geprüft Grundursache
Gleichzeitiger Rollout Ja Nein Nein Deploymentprotokoll Verstärkte Auswirkung
Kein Ende-zu-Ende-Monitoring Ja Nein Nein Monitoringkonfiguration Erkennungslücke
Hohe Benutzerlast Nein Nein Nein Monitoring Widerlegt
Datenbankausfall Nein Nein Nein Datenbankmonitoring Widerlegt

28. Menschliche Handlung nicht automatisch als Grundursache verwenden

Ungeeignet

Der Administrator hat die falsche Adresse eingetragen.

Diese Aussage beendet die Untersuchung zu früh.

Weiterführende Fragen

Eine sachliche Ursachenanalyse untersucht, wie Systeme und Prozesse verbessert werden können, statt einzelne Personen zu beschuldigen.

29. Bestätigungsgrade verwenden

Grad Bedeutung
Bestätigt Direkter Mechanismus, mehrere Belege und Gegenprobe vorhanden
Sehr wahrscheinlich Mechanismus und mehrere Belege vorhanden, Gegenprobe nicht möglich
Wahrscheinlich Plausibel und teilweise belegt
Möglich Technisch denkbar, aber kaum belegt
Unklar Belege reichen nicht für eine Bewertung
Unwahrscheinlich Mehrere Fakten widersprechen
Widerlegt Definierte Vorhersage wurde durch Gegenbeleg widerlegt

Wenn eine Gegenprobe aus Sicherheits- oder Produktionsgründen nicht möglich ist, sollte die Ursache als „sehr wahrscheinlich“ und nicht automatisch als vollständig bestätigt dokumentiert werden.

30. Wann die Ursachensuche beendet werden kann

Die Untersuchung kann beendet oder in eine spätere Nachanalyse überführt werden, wenn:

Eine Untersuchung sollte nicht endlos fortgeführt werden. Der notwendige Beweisgrad hängt von Auswirkung und Risiko der Störung ab.

Störung Erforderlicher Beweisgrad
Einzelner unkritischer Arbeitsplatz technische Plausibilität und dokumentierter Funktionstest
Wiederkehrende Unternehmensstörung mehrere Belege und Gegenprobe
Kritischer Produktionsausfall ausführliche Ursachenanalyse
Datenverlust hohe Beweissicherheit und Managementbeteiligung
Sicherheitsvorfall Incident Response und möglicherweise Forensik
Rechtlich relevanter Vorfall dokumentierte Beweismittelkette und Fachstellen

31. Vollständiges Praxisbeispiel

Störung

Seit 14:31 Uhr liefert https://server.example abwechselnd HTTP 200 und HTTP 503.

Fehlerumfang

Hypothesen

Nr. Hypothese
H1 DNS liefert eine nicht vorgesehene IP-Adresse
H2 Eines der Backends ist fehlerhaft
H3 Load Balancer verteilt Anfragen falsch
H4 Datenbank ist vollständig ausgefallen
H5 Clientnetzwerk ist instabil

Prüfungen

Bewertung der Hypothesen

Hypothese Bewertung Begründung
H1 Widerlegt Beide DNS-Adressen sind vorgesehen
H2 Bestätigt Fehler ist reproduzierbar an Backend 2 gebunden
H3 Teilweise bestätigt Health Check erkennt den Backendfehler nicht
H4 Widerlegt Datenbank und Backend 1 funktionieren
H5 Widerlegt TCP- und TLS-Verbindungen sind stabil

Ursachenkette

Ebene Feststellung
Symptom ungefähr jede zweite Anfrage liefert HTTP 503
Direkte Ursache Backend 2 erreicht die Datenbank nicht
Technischer Fehler falscher Datenbank-Hostname
Auslöser Deployment um 14:31 Uhr
Grundursache fehlende Validierung der Konfiguration
Begünstigender Faktor fehlerhafter Health Check
Erkennungslücke Monitoring prüft keine Datenbankfunktion
Sofortmaßnahme Backend 2 aus Rotation nehmen oder Konfiguration zurücksetzen
Prävention Validierung und anwendungsnahen Health Check einführen

32. Dokumentationsvorlage für die Ursachenkette

Feld Eintrag
Ticketnummer
Symptom
Fehlerumfang
Beginn der Störung
Direkte technische Ursache
Technischer Mechanismus
Auslöser
Grundursache
Begünstigende Faktoren
Erkennungslücken
Wiederherstellungsfaktoren
Unterstützende Belege
Widersprechende Belege
Geprüfte Alternativen
Durchgeführte Gegenprobe
Bestätigungsgrad
Verbleibende Unsicherheiten
Sofortmaßnahme
Präventionsmaßnahme

33. Vorlage für alternative Erklärungen

Nr. Alternative Erklärung Erwartete Beobachtung Tatsächliche Beobachtung Beleg Status
A1 Offen
A2 Offen
A3 Offen
A4 Offen

34. Prüffragen zur Grundursache

Kurzcheckliste

Ergebnis dieses Arbeitsschrittes

Am Ende dieses Schrittes liegt eine nachvollziehbare Ursachenkette vor. Sie unterscheidet:

Eine Ursache gilt nicht allein deshalb als bestätigt, weil der Fehler nach einer Änderung verschwunden ist. Sie muss zum Fehlerbild passen, durch technische Belege gestützt und gegen alternative Erklärungen geprüft worden sein.

Nächste Seite:
1.8 Lösung umsetzen, Rückfallplan anwenden und Funktion verifizieren

Offizielle Hersteller-, Standard- und Projektdokumentation

1. Grundlagen der systematischen Fehleranalyse

1.8 Lösung umsetzen, Rückfallplan anwenden und Funktion verifizieren

Nachdem die Ursache ausreichend bestätigt wurde, kann eine geeignete Lösung geplant und umgesetzt werden.

Dabei gilt:

Eine Störung gilt nicht als behoben, nur weil eine Fehlermeldung verschwunden ist. Die ursprüngliche Funktion, ihre Abhängigkeiten und mögliche Nebenwirkungen müssen anschließend geprüft werden.

Jede technische Korrektur ist selbst eine Änderung und kann neue Fehler verursachen. Deshalb benötigt auch eine scheinbar einfache Maßnahme einen definierten Ausgangszustand, Erfolgskriterien und einen Rückfallplan.

Ziel dieser Seite

Nach diesem Arbeitsschritt sollten:

1. Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] Read-only: liest Informationen aus
[TEST] Führt eine aktive Prüfung aus
[FILE] Erstellt oder überschreibt eine Datei
[PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte
[CHANGE] Verändert Konfiguration oder Betriebszustand
[DISRUPTIV] Kann Benutzer oder produktive Dienste beeinträchtigen
[SENSITIV] Ausgabe kann vertrauliche Daten enthalten

2. Maßnahmenarten unterscheiden

Maßnahmenart Zweck Beispiel
Sofortmaßnahme Auswirkungen schnell begrenzen fehlerhaftes Backend aus dem Load Balancer nehmen
Workaround Fehler umgehen, ohne Ursache zu entfernen Benutzer verwendet vorübergehend anderen Server
Mitigation Auswirkung oder Wahrscheinlichkeit reduzieren Traffic auf funktionierende Instanzen begrenzen
Reparatur unmittelbaren technischen Fehler beseitigen fehlerhafte Konfiguration korrigieren
Dauerhafte Lösung bestätigte Grundursache beseitigen automatische Konfigurationsvalidierung einführen
Präventionsmaßnahme Wiederholung oder Auswirkung verhindern Canary-Rollout und Monitoring ergänzen
Rollback vorherigen bekannten Zustand wiederherstellen vorherige Anwendungsversion aktivieren
Roll-forward Fehler durch eine neue Korrektur beheben korrigierte Folgeversion bereitstellen

Ein Workaround kann den Betrieb wiederherstellen, ohne die eigentliche Ursache zu beseitigen. Er muss deshalb als temporär gekennzeichnet und nachverfolgt werden.

3. Wiederherstellung und Ursachenbehebung unterscheiden

Wiederherstellung

Ziel ist, die betroffene Funktion möglichst schnell wieder bereitzustellen.

Beispiele:

Ursachenbehebung

Ziel ist, das erneute Auftreten zu verhindern.

Beispiele:

Eine Störung kann bereits wiederhergestellt sein, während die dauerhafte Ursachenbehebung noch offen ist.

4. Vor jeder Änderung zu klärende Fragen

5. Änderungsumfang möglichst klein halten

Eine Korrektur sollte nur die Komponente verändern, die für die bestätigte Ursache relevant ist.

Ungeeignet

Besser

  1. eine klar definierte Änderung,
  2. definierter Funktionstest,
  3. Beobachtung,
  4. nächste Änderung nur bei Bedarf.

Kleine Änderungen lassen sich leichter:

6. Risiko der Änderung bewerten

Risikofaktor Niedriges Risiko Hohes Risiko
Umfang einzelner Testclient gesamte Produktion
Reversibilität einfache Konfigurationsrücknahme irreversible Datenmigration
Verfügbarkeit redundantes System einzelner kritischer Server
Erfahrung dokumentierte Standardänderung erstmalige unbekannte Änderung
Abhängigkeiten wenige bekannte Abhängigkeiten viele unbekannte Abhängigkeiten
Daten keine Datenänderung Schema- oder Datenänderung
Zugang lokaler Konsolenzugang nur entfernte Verbindung
Testbarkeit funktionierende Testumgebung nur Produktion verfügbar
Beobachtung vollständiges Monitoring kaum Messwerte vorhanden
Zeitdruck geplantes Wartungsfenster ungeplanter kritischer Ausfall

7. Änderungsplan erstellen

Feld Eintrag
Ticket- oder Change-Nummer
bestätigte Ursache
geplante Änderung
technisches Ziel
betroffene Systeme
betroffene Benutzer
Abhängigkeiten
erwartete Unterbrechung
Risiko Niedrig / Mittel / Hoch
ausführende Person
beobachtende Person
Wartungsfenster
Sicherung des Ausgangszustands
Erfolgskriterien
Abbruchkriterien
Rückfallplan
Rückfallentscheidung durch
Kommunikationsweg
Beobachtungsdauer

8. Backup und Rollback unterscheiden

Begriff Bedeutung
Backup Sicherung von Daten oder Konfiguration
Restore Wiederherstellung aus einem Backup
Rollback Rückkehr zum vorherigen bekannten Betriebszustand
Snapshot Momentaufnahme eines bestimmten Systems oder Datenträgers
Export Sicherung einer Konfiguration in einem unterstützten Format
Roll-forward Korrektur durch eine nachfolgende Version oder Änderung

Ein vorhandenes Backup ist noch kein vollständiger Rückfallplan.

Ein Rückfallplan beantwortet zusätzlich:

9. Grenzen von Snapshots beachten

Ein Snapshot ersetzt kein reguläres Backup und ist nicht für jede Anwendung als Rückfallmethode geeignet.

Besondere Vorsicht gilt unter anderem bei:

Vor der Nutzung eines Snapshots muss geprüft werden:

10. Ausgangskonfiguration sichern

Für produktive Systeme sollte möglichst die vom Hersteller vorgesehene Export-, Backup- oder Versionsverwaltungsfunktion verwendet werden.

Einfache Dateikopien sind nur für einzelne Konfigurationsdateien geeignet, wenn Berechtigungen, Besitzer, ACLs, erweiterte Attribute und Anwendungsanforderungen berücksichtigt werden.

Windows-Beispiel für eine einzelne Konfigurationsdatei

$backupFile = Join-Path "<Zielpfad>" "config-$(Get-Date -Format 'yyyyMMdd-HHmmss').bak"

Copy-Item "<Konfigurationsdatei>" $backupFile

Get-FileHash -Path "<Konfigurationsdatei>", $backupFile -Algorithm SHA256

Kennzeichnung:

Die Prüfsummen sollten bei einer unveränderten Kopie identisch sein.

Linux-Beispiel für eine einzelne Konfigurationsdatei

backup_file="<Zielpfad>/config-$(date +%Y%m%d-%H%M%S).bak"

cp --preserve=all -- "<Konfigurationsdatei>" "$backup_file"

sha256sum "<Konfigurationsdatei>" "$backup_file"

cp --preserve=all ist eine GNU-Option und steht nicht auf jedem Unix-System zur Verfügung.

macOS-Beispiel für eine einzelne Konfigurationsdatei

backup_file="<Zielpfad>/config-$(date +%Y%m%d-%H%M%S).bak"

cp -p "<Konfigurationsdatei>" "$backup_file"

shasum -a 256 "<Konfigurationsdatei>" "$backup_file"

cp -p erhält wichtige Dateiattribute, garantiert aber nicht für jede Anwendung die vollständige Sicherung aller Metadaten. Für komplexe Anwendungen muss die vorgesehene Backupfunktion verwendet werden.

11. Konfiguration vor der Aktivierung validieren

Eine Konfigurationsdatei sollte möglichst vor einem Reload oder Neustart geprüft werden.

JSON unter Windows PowerShell prüfen

[TEST] Get-Content "<Datei.json>" -Raw | ConvertFrom-Json | Out-Null

Bei ungültigem JSON erzeugt PowerShell eine Fehlermeldung.

JSON unter Linux oder macOS mit Python prüfen

[TEST] python3 -m json.tool "<Datei.json>" > /dev/null

JSON mit jq prüfen, sofern installiert

[TEST] jq empty "<Datei.json>"

macOS-Property-List prüfen

[TEST] plutil -lint "<Datei.plist>"

systemd-Unit-Datei prüfen

[TEST] systemd-analyze verify "<Datei.service>"

NGINX-Konfiguration prüfen

[TEST][PRIV] nginx -t

Apache-Konfiguration prüfen

[TEST][PRIV] apachectl configtest

OpenSSH-Serverkonfiguration prüfen

[TEST][PRIV] sshd -t

Die Werkzeuge prüfen unterschiedliche Aspekte. Ein erfolgreicher Syntax-Test bestätigt nicht automatisch, dass Netzwerkziele, Zugangsdaten, Zertifikate und abhängige Dienste funktionieren.

12. PowerShell-Änderung mit WhatIf vorprüfen

Einige PowerShell-Cmdlets unterstützen den allgemeinen Parameter -WhatIf.

Beispiel

[TEST] Restart-Service -Name <Dienstname> -WhatIf

PowerShell zeigt, welche Aktion vorgesehen ist, führt den Neustart aber nicht aus.

Wichtige Einschränkung

-WhatIf:

13. Dienständerungen unter Windows

Aktuellen Zustand prüfen

[RO] Get-Service -Name <Dienstname>

Abhängige Dienste prüfen

[RO] Get-Service -Name <Dienstname> -DependentServices

Benötigte Dienste prüfen

[RO] Get-Service -Name <Dienstname> -RequiredServices

Dienstkonfiguration prüfen

[RO][SENSITIV] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object Name, State, StartMode, StartName, PathName, ProcessId

Neustart zunächst anzeigen

[TEST] Restart-Service -Name <Dienstname> -WhatIf

Dienst mit Bestätigungsabfrage neu starten

[CHANGE][DISRUPTIV][PRIV] Restart-Service -Name <Dienstname> -Confirm

Gestoppten Dienst starten

[CHANGE][PRIV] Start-Service -Name <Dienstname> -Confirm

Zustand danach prüfen

[RO] Get-Service -Name <Dienstname>

Restart-Service sendet eine Stopp- und anschließend eine Startanforderung. War der Dienst bereits gestoppt, versucht das Cmdlet ihn zu starten. Vorher müssen abhängige Dienste und Auswirkungen geprüft werden.

14. Dienständerungen unter Linux

Aktuellen Zustand prüfen

[RO] systemctl status <Dienstname>.service --no-pager

Zustand kompakt prüfen

[RO] systemctl is-active <Dienstname>.service

Reload-Fähigkeit prüfen

[RO] systemctl show <Dienstname>.service -p CanReload -p ActiveState -p SubState -p MainPID

Konfiguration neu laden

[CHANGE][PRIV] sudo systemctl reload <Dienstname>.service

Ein Reload funktioniert nur, wenn der Dienst diese Funktion unterstützt.

Dienst neu starten

[CHANGE][DISRUPTIV][PRIV] sudo systemctl restart <Dienstname>.service

Nur dann neu starten, wenn der Dienst bereits läuft

[CHANGE][DISRUPTIV][PRIV] sudo systemctl try-restart <Dienstname>.service

Zustand danach prüfen

[RO] systemctl status <Dienstname>.service --no-pager

Neue Protokolle anzeigen

[RO] journalctl -u <Dienstname>.service --since "5 minutes ago" --no-pager

15. Dienständerungen unter macOS

macOS verwendet launchd. Für die Befehle muss der richtige Dienstkontext bekannt sein.

Systemdienst prüfen

[RO][PRIV] launchctl print system/<Dienstlabel>

Benutzerdienst prüfen

[RO] launchctl print gui/$(id -u)/<Dienstlabel>

Systemdienst beenden und neu starten

[CHANGE][DISRUPTIV][PRIV] sudo launchctl kickstart -k system/<Dienstlabel>

Benutzerdienst beenden und neu starten

[CHANGE][DISRUPTIV] launchctl kickstart -k gui/$(id -u)/<Dienstlabel>

Die Option -k beendet eine bereits laufende Instanz, bevor sie neu gestartet wird.

Protokolle danach prüfen

[RO] log show --last 5m --predicate 'process == "<Prozessname>"' --style compact

Vor dem Einsatz muss die lokale Dokumentation mit man launchctl geprüft werden. System-, Benutzer- und GUI-Dienste verwenden unterschiedliche Domains. Ein falscher Dienstkontext kann dazu führen, dass nicht der erwartete Dienst angesprochen wird.

16. Reload, Restart und Reboot unterscheiden

Maßnahme Wirkung Typisches Risiko
Reload Konfiguration wird im laufenden Prozess neu geladen Niedrig bis mittel
Restart Prozess wird beendet und neu gestartet Mittel bis hoch
Reboot gesamtes Betriebssystem wird neu gestartet Hoch
Failover Betrieb wechselt auf anderes System Mittel bis hoch
Rollback vorheriger Zustand wird wiederhergestellt Abhängig von Daten und Anwendung

Sinnvolle Reihenfolge

  1. anwendungseigene Konfigurationsprüfung,
  2. Reload, wenn unterstützt,
  3. gezielter Dienstneustart,
  4. Failover oder Rollback,
  5. vollständiger Systemneustart nur mit technischer Begründung.

Ein vollständiger Neustart sollte nicht als Standardlösung verwendet werden, wenn ein einzelner Dienst gezielt behandelt werden kann.

17. Änderungen schrittweise ausrollen

Verfahren Beschreibung
Einzelner Testclient Änderung zunächst auf einem ausgewählten Client
Einzelne Instanz Änderung auf einem Server innerhalb einer redundanten Gruppe
Canary kleiner Anteil produktiver Systeme oder Anfragen
Rolling Deployment Instanzen werden nacheinander geändert
Blue-Green neue und alte Umgebung existieren parallel
Staged Rollout Änderung wird in definierten Stufen erweitert
Wartungsgruppe ausgewählte Benutzer oder Systeme werden zuerst umgestellt

Beispiel für einen stufenweisen Rollout

  1. Testumgebung,
  2. einzelne produktionsnahe Instanz,
  3. ausgewählte Benutzer,
  4. kleiner Produktionsanteil,
  5. Monitoring auswerten,
  6. weitere Instanzen,
  7. vollständiger Rollout.

Nach jeder Stufe muss ein Entscheidungspunkt bestehen:

18. Canary und Kontrollgruppe vergleichen

Messwert Kontrollgruppe Canary Bewertung
Fehlerrate 0,5 % 0,6 % ähnlich
Antwortzeit 220 ms 225 ms ähnlich
CPU-Auslastung 42 % 44 % ähnlich
HTTP 500 2 3 beobachten
erfolgreiche Anmeldungen 99,5 % 99,4 % ähnlich
neue Protokollfehler 0 0 unauffällig

Die Bewertung darf nicht nur auf dem Gesamtsystem erfolgen. Ein kleiner Canary kann in aggregierten Messwerten unsichtbar bleiben. Canary und Kontrollgruppe müssen getrennt ausgewertet werden.

19. Abbruchkriterien vor dem Rollout festlegen

Mögliche Abbruchkriterien:

Schwellenwerte müssen aus SLA, SLO, Monitoring-Baseline oder dokumentierten Anforderungen stammen und dürfen nicht frei erfunden werden.

20. Technische Verifikation in mehreren Ebenen

Ebene Zu prüfende Frage
Prozess Läuft der erwartete Prozess?
Dienst Meldet der Dienst einen gesunden Zustand?
Listener Lauscht der erwartete Port?
Netzwerk Ist das Ziel vom vorgesehenen Client erreichbar?
TLS Funktionieren Zertifikat und Handshake?
Protokoll Liefert der Dienst eine gültige Antwort?
Authentifizierung Kann sich der Benutzer anmelden?
Autorisierung Darf der Benutzer die vorgesehene Funktion verwenden?
Anwendung Funktioniert die konkrete Aktion?
Daten Werden Daten korrekt gelesen und geschrieben?
Abhängigkeiten Funktionieren Datenbank, Storage, DNS und APIs?
Monitoring Wird das System korrekt als gesund erkannt?
Protokolle Entstehen keine neuen relevanten Fehler?
Redundanz Sind verbleibende Instanzen und Failover weiterhin verfügbar?

21. Windows-Verifikation

Dienststatus

[RO] Get-Service -Name <Dienstname>

Prozess-ID des Dienstes

[RO] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object Name, State, ProcessId

TCP-Listener

[RO][PRIV] Get-NetTCPConnection -State Listen -LocalPort <Port>

Remote-Porttest

[TEST] Test-NetConnection <Servername> -Port <Port> -InformationLevel Detailed

HTTP- oder HTTPS-Test

[TEST] curl.exe -sS -o NUL -w "HTTP=%{http_code} Ziel=%{remote_ip} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https://<Servername>/

Neue Systemereignisse

[RO] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=(Get-Date).AddMinutes(-10)} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message

Neue Anwendungsereignisse

[RO] Get-WinEvent -FilterHashtable @{LogName="Application"; StartTime=(Get-Date).AddMinutes(-10)} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message

22. Linux-Verifikation

Dienststatus

[RO] systemctl status <Dienstname>.service --no-pager

Nur aktiven Zustand abfragen

[RO] systemctl is-active <Dienstname>.service

Hauptprozess-ID

[RO] systemctl show <Dienstname>.service -p MainPID

TCP-Listener

[RO][PRIV] ss -lntp | grep ":<Port>"

Remote-Porttest

[TEST] nc -vz -w 3 <Servername> <Port>

HTTP- oder HTTPS-Test

[TEST] curl -sS -o /dev/null -w "HTTP=%{http_code} Ziel=%{remote_ip} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https://<Servername>/

Neue Dienstprotokolle

[RO] journalctl -u <Dienstname>.service --since "10 minutes ago" --no-pager

Neue Fehler des Systems

[RO] journalctl --since "10 minutes ago" -p err --no-pager

23. macOS-Verifikation

Systemdienststatus

[RO][PRIV] launchctl print system/<Dienstlabel>

Benutzerdienststatus

[RO] launchctl print gui/$(id -u)/<Dienstlabel>

TCP-Listener

[RO][PRIV] lsof -nP -iTCP:<Port> -sTCP:LISTEN

Remote-Porttest

[TEST] nc -vz -w 3 <Servername> <Port>

HTTP- oder HTTPS-Test

[TEST] curl -sS -o /dev/null -w "HTTP=%{http_code} Ziel=%{remote_ip} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https://<Servername>/

Neue Prozessprotokolle

[RO] log show --last 10m --predicate 'process == "<Prozessname>"' --style compact

Neue Fehler und Faults

[RO] log show --last 10m --predicate 'messageType == error OR messageType == fault' --style compact

24. Ursprüngliche Benutzerfunktion prüfen

Eine technische Verifikation reicht nicht aus. Abschließend muss die ursprünglich gestörte Funktion getestet werden.

Beispiele

Der Test sollte möglichst:

durchgeführt werden.

25. Positive und negative Tests durchführen

Positiver Test

Prüft, ob eine erlaubte Funktion erfolgreich ist.

Beispiel:

Ein berechtigter Benutzer kann eine Datei lesen.

Negativer Test

Prüft, ob eine nicht erlaubte Funktion weiterhin verhindert wird.

Beispiel:

Ein unberechtigter Benutzer kann die Datei weiterhin nicht lesen.

Weitere negative Tests

Eine Lösung ist fehlerhaft, wenn sie die Funktion wiederherstellt, dabei aber Sicherheitskontrollen unbeabsichtigt entfernt.

26. Regressionstests durchführen

Ein Regressionstest prüft, ob bisher funktionierende Bereiche nach der Änderung weiterhin funktionieren.

Geänderte Komponente Mögliche Regressionstests
Firewall andere erlaubte und gesperrte Verbindungen
DNS interne und externe Namensauflösung
DHCP neue und bestehende Clients
Webserver Anmeldung, Upload, Download, API
Datenbank Lesen, Schreiben, Replikation, Backup
Dateiserver Lesen, Schreiben, ACL, Freigaben
Active Directory Anmeldung, Gruppenrichtlinie, Replikation
Proxy erlaubte Seiten, Ausnahmen, Authentifizierung
Zertifikat Browser, API, mobile Clients, alte Clients
Load Balancer alle Backends, Health Checks, Sitzungen
Backup Sicherung und testweise Wiederherstellung

27. Persistenz der Lösung prüfen

Manche Korrekturen funktionieren nur bis zum nächsten:

Zu prüfen ist:

Ein Neustart zur Persistenzprüfung darf nur geplant durchgeführt werden, wenn er technisch erforderlich und freigegeben ist.

28. Monitoring nach der Änderung

Nach einer erfolgreichen Funktionsprüfung muss das System weiter beobachtet werden.

Zu beobachtende Werte

Die Beobachtungsdauer richtet sich nach dem Fehlerbild.

Fehlerart Geeignete Beobachtung
dauerhafter Startfehler unmittelbare Tests nach Start
sporadischer Fehler mehrere typische Nutzungszyklen
nächtlicher Job mindestens nächster geplanter Lauf
DHCP-Problem mindestens ein Lease-Erneuerungszyklus
Backupfehler vollständiger Sicherungs- und Prüfzyklus
Lastproblem typischer Lastzeitraum
Zertifikatserneuerung vollständige Kette und betroffene Clients
Replikationsproblem vorgesehener Replikationszyklus

29. Rollback-Auslöser

Ein Rollback sollte ausgelöst werden, wenn:

Die Entscheidung darf nicht erst improvisiert werden, nachdem ein Problem entstanden ist.

30. Kontrollierter Rollback-Ablauf

  1. weiteren Rollout stoppen,
  2. zuständige Personen informieren,
  3. aktuellen Fehlerzustand sichern,
  4. Rückfallentscheidung dokumentieren,
  5. freigegebenen Rückfallplan ausführen,
  6. Dienst- und Systemstatus prüfen,
  7. ursprüngliche Funktion testen,
  8. negative Tests durchführen,
  9. Protokolle und Monitoring kontrollieren,
  10. Ergebnis dokumentieren,
  11. weitere Untersuchung planen.

Auch ein Rollback ist eine Änderung und kann fehlschlagen.

31. Rollback oder Roll-forward wählen

Situation Rollback eher geeignet Roll-forward eher geeignet
vorherige Version bekannt funktionsfähig Ja Möglich
Konfiguration einfach reversibel Ja Möglich
Datenbankschema bereits verändert Riskant Häufig besser
neue Daten nicht rückwärtskompatibel Riskant Häufig besser
kritische Sicherheitslücke würde wieder geöffnet Eher ungeeignet Besser
Fehlerkorrektur ist klein und geprüft Möglich Häufig besser
vorheriger Zustand nicht eindeutig Riskant Möglicherweise besser
Rollback bereits getestet Ja Nicht zwingend
Zeit bis zur Folgekorrektur sehr lang Häufig besser Eher ungeeignet
Produktionsauswirkung steigt schnell schneller sicherer Weg entscheidend schneller sicherer Weg entscheidend

Ein Rollback darf keine bekannte Sicherheitslücke oder Dateninkonsistenz unbewertet wieder einführen.

32. Rollback einfacher Konfigurationsdateien

Eine Konfigurationsdatei darf nur dann direkt zurückkopiert werden, wenn:

Windows-Beispiel

[CHANGE][PRIV] Copy-Item "<Sicherungsdatei>" "<Konfigurationsdatei>" -Force

Linux-Beispiel

[CHANGE][PRIV] sudo cp --preserve=all -- "<Sicherungsdatei>" "<Konfigurationsdatei>"

macOS-Beispiel

[CHANGE][PRIV] sudo cp -p "<Sicherungsdatei>" "<Konfigurationsdatei>"

Diese Befehle sind keine universelle Rollbacklösung. Datenbanken, Verzeichnisdienste, Cluster, Containerplattformen und komplexe Anwendungen benötigen die vom Hersteller vorgesehene Wiederherstellungsmethode.

Nach dem Zurückkopieren müssen mindestens geprüft werden:

33. Kommunikation während der Umsetzung

Zeitpunkt Information
Vor Beginn Umfang, erwartete Auswirkung und Zeitraum
Zu Beginn Änderung wurde gestartet
Währenddessen relevante Abweichungen oder Verzögerungen
Bei Abbruch Grund und eingeleitete Rückfallmaßnahme
Nach Erfolg Funktion wiederhergestellt und Beobachtung läuft
Nach Rollback vorheriger Zustand wiederhergestellt
Nach Abschluss Ergebnis, offene Punkte und Präventionsmaßnahmen

Technische Kommunikation sollte sachlich sein und zwischen folgenden Zuständen unterscheiden:

34. Vollständiges Praxisbeispiel

Störung

Ein Backend liefert HTTP 503, weil die Anwendung einen falschen Datenbank-Hostnamen verwendet.

Bestätigte Ursache

Die neue Konfigurationsdatei enthält db-prdo.example statt db-prod.example.

Geplante Lösung

Rückfallplan

Erfolgskriterien

Abbruchkriterien

Ablauf

Schritt Maßnahme
1 Ausgangszustand und Protokolle sichern
2 aktuelle Konfiguration sichern und Prüfsumme bilden
3 korrigierte Datei in Testumgebung validieren
4 ein Backend aus der Rotation nehmen
5 Konfiguration auf diesem Backend ändern
6 Konfigurationsprüfung ausführen
7 Dienst kontrolliert neu laden oder starten
8 Listener und Protokolle prüfen
9 Datenbankfunktion prüfen
10 HTTP- und Anmeldetest durchführen
11 Backend mit Kontrollgruppe vergleichen
12 Backend wieder in Rotation nehmen
13 Monitoring beobachten
14 Änderung schrittweise auf weitere Instanzen ausrollen

35. Verifikationsprotokoll

Feld Vor Änderung Nach Änderung Nach Beobachtung
Zeitpunkt
Dienststatus
Prozess-ID
Listener
Ziel-IP
HTTP-Status
Antwortzeit
Authentifizierung
Benutzerfunktion
Datenbankverbindung
Fehler im Protokoll
Monitoringstatus
Fehlerrate
Nebenwirkungen

36. Änderungs- und Rollbackprotokoll

Feld Eintrag
Ticket- oder Change-Nummer
bestätigte Ursache
umgesetzte Änderung
Beginn
Ende
ausführende Person
betroffene Systeme
Sicherungsdatei oder Backup
Prüfsumme
Konfigurationsprüfung Bestanden / Nicht bestanden
Dienstneustart erforderlich Ja / Nein
Erfolgskriterien erreicht Ja / Nein / Teilweise
Abbruchkriterium erreicht Ja / Nein
Rollback durchgeführt Ja / Nein
Rollback-Ergebnis
Benutzerfunktion geprüft Ja / Nein
Regressionstests durchgeführt
Beobachtungsdauer
neue Fehler
verbleibende Risiken
offene Maßnahmen

37. Häufige Fehler bei der Lösungsumsetzung

Fehler Folge Besseres Vorgehen
Keine Sicherung Ausgangszustand kann nicht wiederhergestellt werden Konfiguration oder Backup vorher sichern
Backup mit Rollback verwechselt Wiederherstellung ist nicht geplant vollständigen Rückfallablauf dokumentieren
Mehrere Änderungen gleichzeitig Wirkung nicht zuordenbar kleine einzelne Änderungen
Sofortiger vollständiger Rollout großer möglicher Ausfall Canary oder stufenweiser Rollout
Nur Dienststatus geprüft Benutzerfunktion kann weiterhin gestört sein Ende-zu-Ende-Test durchführen
Nur positiver Test Sicherheitskontrolle kann unbemerkt fehlen negativen Test ergänzen
Keine Abbruchkriterien zu lange an fehlerhafter Änderung festgehalten Grenzwerte vorher definieren
Rollback erst im Fehlerfall geplant zusätzliche Ausfallzeit Rollback vor Beginn vorbereiten
Snapshot als einziges Backup Wiederherstellung möglicherweise ungeeignet anwendungsgerechtes Backup verwenden
Neustart als Standardlösung unnötige Unterbrechung und Informationsverlust kleinste geeignete Maßnahme wählen
Monitoring sofort beendet sporadischer Fehler bleibt unentdeckt angemessene Beobachtungsdauer
Workaround als dauerhafte Lösung behandelt Grundursache bleibt bestehen Folgeaufgabe mit Verantwortlichkeit
Sicherheitsupdate zurückgenommen bekannte Schwachstelle erneut aktiv Sicherheitsrisiko bewerten und Roll-forward prüfen
Dokumentation erst später erstellt genaue Schritte und Zeiten gehen verloren während der Änderung dokumentieren

Kurzcheckliste

Ergebnis dieses Arbeitsschrittes

Am Ende dieses Schrittes ist die bestätigte Ursache durch eine kontrollierte und dokumentierte Änderung behandelt.

Die Lösung gilt erst als erfolgreich, wenn:

Nächste Seite:
1.9 Störung dokumentieren, abschließen und Wiederholung verhindern

Offizielle Hersteller-, Standard- und Projektdokumentation

1. Grundlagen der systematischen Fehleranalyse

1.9 Störung dokumentieren, abschließen und Wiederholung verhindern

Eine Störung ist nicht allein deshalb abgeschlossen, weil die betroffene Funktion wieder verfügbar ist.

Ein vollständiger Abschluss beantwortet zusätzlich:

Dabei gilt:

Eine gute Störungsdokumentation ermöglicht einer anderen Person, den Ablauf, die Ursache, die Prüfungen und die Lösung ohne mündliche Zusatzinformationen nachzuvollziehen.

Ziel dieser Seite

Nach diesem Arbeitsschritt sollten:

1. Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] Read-only: liest Informationen aus
[TEST] Führt eine aktive Prüfung aus
[FILE] Erstellt oder überschreibt eine Datei
[PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte
[CHANGE] Verändert Konfiguration oder Betriebszustand
[SENSITIV] Ausgabe kann vertrauliche Daten enthalten

2. Wiederhergestellt, gelöst und abgeschlossen unterscheiden

Status Bedeutung
Erkannt Störung wurde registriert
In Analyse Ursache wird untersucht
Workaround aktiv Funktion ist über einen vorläufigen Umweg verfügbar
Wiederhergestellt ursprüngliche Funktion ist wieder verfügbar
Unter Beobachtung Funktion läuft, Stabilität wird überwacht
Technisch gelöst bestätigte technische Ursache wurde beseitigt
Dauerhaft gelöst zusätzlich wurden erforderliche Präventionsmaßnahmen umgesetzt
Abgeschlossen Dokumentation, Übergabe und offene Maßnahmen sind vollständig
Wiedereröffnet Fehler trat erneut auf oder Abschlusskriterien waren nicht erfüllt

Ein Ticket sollte nicht als „dauerhaft gelöst“ bezeichnet werden, wenn lediglich ein Workaround aktiv ist.

3. Incident, Problem und Änderung unterscheiden

Element Hauptziel Beispiel
Störung oder Incident Betrieb schnell wiederherstellen Webanwendung wieder erreichbar machen
Problem oder Ursachenanalyse Grundursache und Wiederholungsrisiko untersuchen Ursache des wiederkehrenden Ausfalls bestimmen
Änderung oder Change kontrollierte technische Anpassung durchführen Konfigurationsvalidierung einführen
Wissenseintrag Wiederverwendbare Lösung dokumentieren Fehlerbild und Diagnosebefehle dokumentieren
Präventionsaufgabe Wiederholung oder Auswirkung verhindern Monitoring um Ende-zu-Ende-Test ergänzen

Ein einzelner Vorfall kann mehrere verknüpfte Einträge benötigen.

4. Abschlusskriterien festlegen

Eine Störung kann abgeschlossen werden, wenn mindestens folgende Punkte geklärt sind:

5. Abschlussentscheidung

Frage Ja Nein
Funktioniert die ursprüngliche Benutzeraktion?
Ist der technische Systemzustand stabil?
Sind Abhängigkeiten geprüft?
Sind negative Sicherheitstests bestanden?
Sind relevante Regressionstests bestanden?
Ist das Monitoring unauffällig?
Sind Protokolle nach der Lösung geprüft?
Ist die Ursache ausreichend dokumentiert?
Ist klar, ob es sich um Workaround oder Lösung handelt?
Sind offene Aufgaben zugewiesen?
Sind verbleibende Risiken dokumentiert?
Sind betroffene Personen informiert?

Wenn wesentliche Punkte mit „Nein“ beantwortet werden, sollte das Ticket nicht ohne Begründung endgültig geschlossen werden.

6. Inhalt einer vollständigen Störungsdokumentation

Abschnitt Inhalt
Kurzbeschreibung Was war sichtbar gestört?
Auswirkung Wer oder was war betroffen?
Beginn Erster bekannter Fehlerzeitpunkt
Erkennung Wie und wann wurde die Störung erkannt?
Wiederherstellung Wann funktionierte der Dienst wieder?
Abschluss Wann wurde die dauerhafte Lösung bestätigt?
Systeme betroffene Clients, Server, Netze und Dienste
Symptom Fehlermeldung und beobachtetes Verhalten
Fehlerumfang betroffene und nicht betroffene Bereiche
Zeitachse wichtige Ereignisse und Maßnahmen
Ursache bestätigte technische Ursache
Auslöser Ereignis, das den Fehler aktivierte
Begünstigende Faktoren Bedingungen, die Auswirkung oder Dauer verstärkten
Erkennungslücken Warum wurde der Fehler nicht früher erkannt?
Diagnose wichtige Befehle, Ausgaben und Tests
Wiederherstellung Sofortmaßnahme oder Workaround
Dauerhafte Lösung Beseitigung der Grundursache
Verifikation technische und fachliche Funktionstests
Rollback vorbereitet, durchgeführt oder nicht erforderlich
Offene Risiken verbleibende technische oder organisatorische Risiken
Folgeaufgaben Präventions-, Monitoring- und Dokumentationsaufgaben
Verantwortliche Zuständigkeit für jede offene Aufgabe

7. Kurzbeschreibung richtig formulieren

Ungeeignet

Server war kaputt und wurde repariert.

Besser

Am 30.07.2026 konnten Clients aus VLAN 30 zwischen 14:35 und 15:42 Uhr keine HTTPS-Verbindung zu server.example aufbauen. Ursache war eine fehlerhafte Firewall-ACL, die TCP 443 aus VLAN 30 blockierte. Nach Korrektur der ACL waren Porttest, Anmeldung und Monitoring erfolgreich.

Eine gute Kurzbeschreibung enthält:

8. Auswirkung dokumentieren

Die Auswirkung sollte möglichst konkret beschrieben werden.

Bereich Zu dokumentierende Angaben
Benutzer Anzahl oder betroffene Gruppen
Standorte Gebäude, Niederlassungen oder Netze
Systeme Clients, Server, Anwendungen
Funktionen Anmeldung, Dateiablage, E-Mail, Produktion
Dauer Beginn bis Wiederherstellung
Daten Verlust, Verzögerung oder Inkonsistenz
Sicherheit mögliche unautorisierte Zugriffe oder Kontrollverlust
Geschäft ausgefallene Prozesse oder Verzögerungen
Externe Parteien Kunden, Lieferanten oder Provider
Workaround verfügbar, eingeschränkt oder nicht vorhanden

Wenn keine genaue Anzahl verfügbar ist, sollte dies ausdrücklich vermerkt und nicht frei geschätzt werden.

9. Wichtige Zeitpunkte dokumentieren

Zeitpunkt Bedeutung
Letzter funktionierender Zustand Funktion wurde zuletzt erfolgreich verwendet
Tatsächlicher Fehlerbeginn soweit technisch bestimmbar
Erste Beobachtung Fehler wurde erstmals bemerkt
Erkennung Monitoring oder Support erkannte die Störung
Meldung Ticket wurde erstellt
Bestätigung Störung wurde technisch nachvollzogen
Eskalation weitere Stelle wurde beteiligt
Eindämmung Auswirkung wurde begrenzt
Wiederherstellung Benutzerfunktion war wieder verfügbar
Dauerhafte Lösung Grundursache wurde behandelt
Ende der Beobachtung Stabilität wurde ausreichend bestätigt
Abschluss Ticket wurde geschlossen

Alle Uhrzeiten sollten dieselbe Zeitzone verwenden oder eindeutig als lokale Zeit beziehungsweise UTC gekennzeichnet sein.

10. Zeitkennzahlen berechnen

Kennzahl Berechnung Bedeutung
Erkennungszeit Erkennung minus Fehlerbeginn Wie lange blieb der Fehler unentdeckt?
Reaktionszeit Beginn der Bearbeitung minus Erkennung Wie schnell begann die Reaktion?
Eindämmungszeit Eindämmung minus Erkennung Wie schnell wurde die Auswirkung begrenzt?
Wiederherstellungszeit Wiederherstellung minus Fehlerbeginn Wie lange war die Funktion beeinträchtigt?
Lösungszeit dauerhafte Lösung minus Fehlerbeginn Wie lange bis zur vollständigen Korrektur?

Abkürzungen wie MTTR werden in verschiedenen Organisationen unterschiedlich verwendet, beispielsweise für „Mean Time to Repair“, „Restore“, „Resolve“ oder „Recovery“. Deshalb sollte die konkret gemeinte Kennzahl ausgeschrieben und definiert werden.

11. Zeitachse erstellen

Zeit Quelle Ereignis Auswirkung oder Erkenntnis
14:31 Deployment neue Konfiguration verteilt möglicher Auslöser
14:35 Monitoring HTTP-Fehlerrate steigt erster technischer Hinweis
14:38 Benutzer Anmeldung schlägt fehl Benutzerwirkung bestätigt
14:42 Support Ticket erstellt Bearbeitung beginnt
14:48 Diagnose Backend 2 liefert HTTP 503 Fehler eingegrenzt
14:55 Anwendung falscher Datenbank-Hostname gefunden unmittelbare Ursache
15:05 Change Backend 2 aus Rotation genommen Auswirkung eingedämmt
15:17 Change Konfiguration korrigiert technische Lösung
15:22 Test Anmeldung erfolgreich Funktion wiederhergestellt
15:52 Monitoring keine neuen Fehler Stabilität bestätigt
16:00 Abschluss Folgeaufgaben erstellt Incident beendet

Wichtig

Die Zeitachse sollte Fakten enthalten. Vermutungen werden als solche gekennzeichnet.

12. Fakten und Bewertungen trennen

Fakt

Um 14:31 Uhr wurde Deployment 2026.07.30-3 ausgeführt.

Bewertung

Das Deployment war der Auslöser der Störung.

Fakt

Backend 2 protokollierte um 14:35 Uhr einen Fehler bei der Namensauflösung des Datenbankservers.

Bewertung

Der falsche Datenbank-Hostname verursachte die HTTP-503-Antworten.

Beide Arten von Informationen sind wichtig, müssen aber voneinander unterscheidbar bleiben.

13. Technische Diagnose dokumentieren

Nicht jede vollständige Konsolenausgabe muss direkt in den Tickettext kopiert werden. Das Ticket sollte jedoch die relevanten Befehle, Ergebnisse und Verweise enthalten.

Feld Beispiel
Prüfzeitpunkt 2026-07-30 14:48 CEST
Quellsystem PC-030
Zielsystem server.example
Befehl Test-NetConnection server.example -Port 443
Ergebnis TcpTestSucceeded: False
Vergleich Test aus VLAN 40 erfolgreich
Interpretation Fehler ist vom Quellnetz abhängig
Ausgabedatei INC-2026-0042-TCP-Test-PC030.txt
Hypothese H1 – ACL blockiert VLAN 30
Bewertung stark gestützt

14. Befehle und Ausgaben nachvollziehbar zuordnen

Geeignete Dateinamen

INC-2026-0042-PC030-TCP-Test-20260730-144800.txt

INC-2026-0042-FW01-Auditlog-20260730-145000.txt

INC-2026-0042-SRVAPP02-Application.evtx

Ein sinnvoller Dateiname enthält:

15. Abschlusszustand unter Windows dokumentieren

Zeitpunkt

[RO] Get-Date -Format o

Dienststatus

[RO] Get-Service -Name <Dienstname>

Prozess-ID

[RO] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object Name, State, ProcessId

Listener

[RO][PRIV] Get-NetTCPConnection -State Listen -LocalPort <Port>

Funktionstest

[TEST] Test-NetConnection <Servername> -Port <Port> -InformationLevel Detailed

Neue Systemfehler

[RO] Get-WinEvent -FilterHashtable @{LogName="System"; Level=1,2; StartTime=(Get-Date).AddMinutes(-30)} | Select-Object TimeCreated, Id, ProviderName, Message

Neue Anwendungsfehler

[RO] Get-WinEvent -FilterHashtable @{LogName="Application"; Level=1,2; StartTime=(Get-Date).AddMinutes(-30)} | Select-Object TimeCreated, Id, ProviderName, Message

16. Abschlusszustand unter Linux dokumentieren

Zeitpunkt

[RO] date --iso-8601=seconds

Dienststatus

[RO] systemctl status <Dienstname>.service --no-pager

Fehlgeschlagene Dienste

[RO] systemctl --failed

Listener

[RO][PRIV] ss -lntp | grep ":<Port>"

Funktionstest

[TEST] nc -vz -w 3 <Servername> <Port>

Neue Dienstprotokolle

[RO] journalctl -u <Dienstname>.service --since "30 minutes ago" --no-pager

Neue Systemfehler

[RO] journalctl --since "30 minutes ago" -p err --no-pager

17. Abschlusszustand unter macOS dokumentieren

Zeitpunkt

[RO] date "+%Y-%m-%dT%H:%M:%S%z"

Systemdienst

[RO][PRIV] launchctl print system/<Dienstlabel>

Benutzerdienst

[RO] launchctl print gui/$(id -u)/<Dienstlabel>

Listener

[RO][PRIV] lsof -nP -iTCP:<Port> -sTCP:LISTEN

Funktionstest

[TEST] nc -vz -w 3 <Servername> <Port>

Neue Prozessfehler

[RO] log show --last 30m --predicate 'process == "<Prozessname>" AND (messageType == error OR messageType == fault)' --style compact

18. Plattformübergreifenden HTTP-Abschlusstest durchführen

Windows

[TEST] curl.exe -sS -o NUL -w "HTTP=%{http_code} Ziel=%{remote_ip} DNS=%{time_namelookup} TCP=%{time_connect} TLS=%{time_appconnect} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https://<Servername>/

Linux und macOS

[TEST] curl -sS -o /dev/null -w "HTTP=%{http_code} Ziel=%{remote_ip} DNS=%{time_namelookup} TCP=%{time_connect} TLS=%{time_appconnect} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https://<Servername>/

Der Test dokumentiert unter anderem:

Die Werte müssen mit bekannten Normalwerten, Monitoring-Baselines oder vereinbarten Anforderungen verglichen werden.

19. Prüfsummen für Abschlussunterlagen erstellen

Die Prüfsummen sollten erst erstellt werden, nachdem keine weiteren Dateien mehr zur Sammlung hinzugefügt werden.

Windows

[FILE] Get-ChildItem "<Diagnoseordner>" -File -Recurse | Get-FileHash -Algorithm SHA256 | Export-Csv "<Diagnoseordner>-SHA256.csv" -NoTypeInformation -Encoding UTF8

Linux

[FILE] (cd "<Diagnoseordner>" && find . -type f -print0 | sort -z | xargs -0 -r sha256sum) > "<Diagnoseordner>-SHA256SUMS.txt"

macOS

[FILE] find "<Diagnoseordner>" -type f -exec shasum -a 256 {} \; > "<Diagnoseordner>-SHA256SUMS.txt"

Eine Prüfsumme dokumentiert die Integrität der Datei ab dem Zeitpunkt ihrer Berechnung. Sie beweist nicht automatisch Herkunft oder Authentizität.

20. Abschlussunterlagen schützen

Diagnose- und Abschlussunterlagen können enthalten:

Deshalb muss geklärt sein:

21. Wann eine ausführliche Nachanalyse sinnvoll ist

Eine ausführliche Nachanalyse oder ein Postmortem ist besonders sinnvoll bei:

Die Kriterien sollten möglichst bereits vor einer Störung organisatorisch festgelegt werden.

22. Sachliche und schuldfreie Nachanalyse

Eine Nachanalyse soll Systeme und Prozesse verbessern, nicht einzelne Personen beschuldigen.

Ungeeignet

Der Administrator war unvorsichtig und hat den falschen Wert eingetragen.

Besser

Die Verwaltungsoberfläche akzeptierte den ungültigen Wert ohne technische Validierung. Die Änderung wurde anschließend ohne Staging- oder Canary-Prüfung auf alle Instanzen verteilt.

Weiterführende Fragen

23. Regeln für eine sachliche Formulierung

Vermeiden Besser
Schuldzuweisung technischen Ablauf beschreiben
persönliche Bewertung beobachtbare Fakten verwenden
„offensichtlich“ konkrete Belege nennen
„immer“ oder „nie“ Zeitraum und Umfang nennen
„Server war kaputt“ betroffene Funktion beschreiben
„Netzwerkproblem“ Protokoll, Quelle und Ziel nennen
„Benutzerfehler“ konkrete Eingabe oder Prozesslücke nennen
„Problem gelöst“ getestete Funktion und Ergebnis nennen
„Monitoring versagte“ fehlende Prüfung oder Alarmbedingung nennen

24. Aufbau einer Nachanalyse

Abschnitt Inhalt
Titel eindeutiger Name und Ticketnummer
Datum Datum der Störung und Nachanalyse
Status Entwurf, geprüft oder abgeschlossen
Beteiligte Systeme technische Komponenten
Zusammenfassung kurze sachliche Beschreibung
Auswirkung Benutzer, Dienste, Dauer und Daten
Erkennung wie und wann die Störung erkannt wurde
Zeitachse wichtige Ereignisse
Ursache technische Ursache und Mechanismus
Auslöser aktivierendes Ereignis
Begünstigende Faktoren Bedingungen, die Wirkung verstärkten
Wiederherstellung Maßnahmen zur Betriebswiederherstellung
Lösung dauerhafte Korrektur
Was funktionierte gut? hilfreiche Abläufe und Werkzeuge
Was funktionierte nicht? technische oder organisatorische Lücken
Wo bestand Glück? Faktoren, die größeren Schaden zufällig verhinderten
Folgeaufgaben konkrete Verbesserungsmaßnahmen
Belege Protokolle, Tickets, Ausgaben und Changes

25. „Was funktionierte gut?“ dokumentieren

Beispiele:

Diese Punkte zeigen, welche bestehenden Prozesse beibehalten oder ausgebaut werden sollten.

26. „Was funktionierte nicht?“ dokumentieren

Beispiele:

Die Beschreibung sollte konkret genug sein, um daraus eine überprüfbare Aufgabe abzuleiten.

27. „Wo bestand Glück?“ dokumentieren

Dieser Abschnitt beschreibt Faktoren, die einen größeren Schaden verhindert haben, obwohl dafür keine verlässliche Schutzmaßnahme existierte.

Beispiele:

Glück ist keine dauerhafte Schutzmaßnahme. Daraus sollten Verbesserungsaufgaben entstehen.

28. Konkrete Folgeaufgaben erstellen

Eine Nachanalyse ohne konkrete und nachverfolgte Maßnahmen verbessert das System nicht.

Jede Folgeaufgabe benötigt:

Ungeeignet

Monitoring verbessern.

Besser

Bis zum 14.08.2026 wird für die Webanwendung ein Ende-zu-Ende-Check eingerichtet, der alle fünf Minuten eine Testanmeldung ausführt und bei drei aufeinanderfolgenden Fehlern alarmiert. Verantwortlich: Betriebsteam. Nachweis: erfolgreich ausgelöster Testalarm.

Die konkreten Zeitintervalle und Grenzwerte müssen aus den Anforderungen der jeweiligen Umgebung abgeleitet werden.

29. Folgeaufgaben kategorisieren

Kategorie Ziel Beispiel
Verhindern Fehlerentstehung verhindern Konfigurationsvalidierung
Begrenzen Auswirkung reduzieren Canary oder Rate Limit
Erkennen Fehler früher feststellen Ende-zu-Ende-Monitoring
Diagnostizieren Ursache schneller finden strukturierte Protokolle
Wiederherstellen Reparatur beschleunigen getesteter Rückfallplan
Dokumentieren Wissen verfügbar machen Runbook aktualisieren
Automatisieren manuelle Fehler reduzieren geprüfte Deployment-Pipeline
Schulen Verfahren bekannt machen Übung des Notfallablaufs
Entfernen unnötige Abhängigkeit beseitigen Single Point of Failure abbauen

30. Wirksamkeit von Maßnahmen priorisieren

Stärke Maßnahmenart Beispiel
1 Fehler technisch unmöglich machen ungültige Konfiguration wird abgelehnt
2 Änderung automatisch prüfen automatischer Syntax- und Funktionstest
3 Auswirkung begrenzen Canary, Redundanz, automatische Rücknahme
4 Fehler schnell erkennen Ende-zu-Ende-Monitoring
5 Wiederherstellung beschleunigen getestetes Runbook
6 Warnhinweis oder Checkliste manueller Prüfschritt
7 Erinnerung an mehr Aufmerksamkeit „Beim nächsten Mal besser aufpassen“

Technische Schutzmaßnahmen und automatisierte Prüfungen sind normalerweise zuverlässiger als eine reine Aufforderung zu größerer Aufmerksamkeit.

31. Folgeaufgaben richtig formulieren

Feld Beispiel
Aufgabe JSON-Konfiguration vor Deployment validieren
Begründung ungültiger Hostname verursachte Ausfall
Verantwortlich Plattformteam
Priorität Hoch
Zieltermin 14.08.2026
messbarer Endzustand Pipeline lehnt ungültiges Schema ab
Prüfmethode Testdeployment mit absichtlich ungültigem Wert
Ticket-ID TASK-2026-0182
Status Offen

32. Maßnahmenstatus verwenden

Status Bedeutung
Offen Aufgabe wurde erstellt
Geplant Umsetzung ist terminiert
In Bearbeitung Umsetzung läuft
Blockiert Abhängigkeit verhindert Umsetzung
Umgesetzt technische Änderung ist erfolgt
In Prüfung Wirksamkeit wird verifiziert
Abgeschlossen messbarer Endzustand ist bestätigt
Verworfen Aufgabe wurde begründet abgelehnt
Risiko akzeptiert Risiko wurde durch zuständige Stelle akzeptiert

„Umgesetzt“ und „wirksam bestätigt“ sollten unterschieden werden.

33. Monitoring aus der Störung verbessern

Nach einer Störung sollte geprüft werden:

Guter Alarm

Ein guter Alarm ist:

34. Benutzerwirkung statt nur Komponentenstatus überwachen

Komponentenprüfung Zusätzliche Ende-zu-Ende-Prüfung
Server antwortet auf Ping Benutzer kann Anwendung öffnen
TCP 443 ist erreichbar HTTPS-Anmeldung funktioniert
Dienststatus ist „Running“ konkrete API-Anfrage funktioniert
Datenbankprozess läuft Anwendung kann Daten lesen
Dateiserver ist erreichbar Testdatei kann gelesen werden
Drucker antwortet im Netz Testseite wird tatsächlich gedruckt
Backupjob startet Sicherung wird erfolgreich abgeschlossen und geprüft
DNS-Dienst läuft vorgesehener Name wird korrekt aufgelöst

35. Dokumentation und Runbooks aktualisieren

Nach der Störung sollten geprüft werden:

Ein guter Wissenseintrag enthält

36. Wiederkehrende Störungen erkennen

Einzelne Tickets sollten nach gemeinsamen Merkmalen ausgewertet werden.

Mögliche Suchmerkmale

Bei wiederkehrenden Störungen sollte ein übergeordneter Problem- oder Ursachenanalyse-Eintrag erstellt und mit den einzelnen Tickets verknüpft werden.

37. Verbleibende Risiken dokumentieren

Nicht jede Verbesserung kann sofort umgesetzt werden.

Risiko Wahrscheinlichkeit Auswirkung Zwischenmaßnahme Verantwortlich Termin
Fehler kann bis zur Pipeline-Anpassung erneut auftreten Mittel Hoch Änderungen manuell prüfen Plattformteam 14.08.2026
Monitoring erkennt Teilfehler nicht Mittel Mittel manuelle Kontrolle Betriebsteam 07.08.2026
Rollback noch nicht automatisiert Niedrig Hoch dokumentiertes manuelles Verfahren Entwicklung 21.08.2026

Ein Risiko darf nur durch die dafür zuständige Stelle akzeptiert werden.

38. Sicherheitsvorfälle gesondert behandeln

Bei einem möglichen oder bestätigten Sicherheitsvorfall darf der normale technische Ticketabschluss nicht allein entscheiden.

Zusätzlich können erforderlich sein:

Der technische Dienst kann bereits wiederhergestellt sein, während der Sicherheitsvorfall noch offen bleibt.

39. Abschlusskommunikation erstellen

Eine Abschlussmeldung sollte enthalten:

Beispiel

Die Störung beim Zugriff auf die Webanwendung ist seit 15:42 Uhr behoben. Betroffen waren Clients aus VLAN 30. Ursache war eine fehlerhafte Firewall-ACL für TCP 443. Die Regel wurde korrigiert und durch Port-, Anmelde- und Monitoringtests bestätigt. Weitere Einschränkungen sind derzeit nicht bekannt. Als Folgemaßnahme wird ein automatischer Verbindungstest aus jedem Client-VLAN eingerichtet. Referenz: INC-2026-0042.

40. Vollständiges Abschlussbeispiel

Zusammenfassung

Am 30.07.2026 konnten Clients aus VLAN 30 die Anwendung server.example über HTTPS nicht erreichen.

Auswirkung

Zeitraum

Ursache

Eine Firewall-ACL blockierte TCP 443 aus VLAN 30.

Auslöser

Die ACL wurde bei einer Netzwerkänderung um 14:31 Uhr unvollständig übernommen.

Begünstigender Faktor

Es existierte kein automatischer Verbindungstest aus jedem Client-VLAN.

Diagnose

Lösung

Die freigegebene ACL wurde korrigiert.

Verifikation

Folgeaufgaben

Aufgabe Verantwortlich Priorität Termin
Verbindungstest aus jedem Client-VLAN einrichten Monitoringteam Hoch 14.08.2026
ACL-Änderungsvorlage ergänzen Netzwerkteam Mittel 07.08.2026
Rückfallverfahren dokumentieren Netzwerkteam Mittel 07.08.2026
Netzplandokumentation aktualisieren Systemintegration Mittel 05.08.2026

41. Vorlage für eine vollständige Störungsdokumentation

Ticketnummer:
<Ticketnummer>

Titel:
<Kurze eindeutige Störungsbeschreibung>

Status:
Erkannt / In Analyse / Workaround / Wiederhergestellt / Beobachtung / Gelöst / Abgeschlossen

Zusammenfassung:
<Was ist passiert?>

Auswirkung:
<Benutzer, Systeme, Standorte, Funktionen und Daten>

Beginn der Störung:
<Datum, Uhrzeit und Zeitzone>

Erkennung:
<Datum, Uhrzeit, Quelle und Zeitzone>

Wiederherstellung:
<Datum, Uhrzeit und Zeitzone>

Ende der Beobachtung:
<Datum, Uhrzeit und Zeitzone>

Betroffene Systeme:
<Liste>

Nicht betroffene Vergleichssysteme:
<Liste>

Fehlermeldung:
<vollständiger Fehlertext>

Direkte technische Ursache:
<Ursache>

Technischer Mechanismus:
<Wie erzeugte die Ursache das Symptom?>

Auslöser:
<Ereignis oder Änderung>

Grundursache:
<systemischer Grund>

Begünstigende Faktoren:
<Liste>

Erkennungslücken:
<Liste>

Zeitachse:
<chronologische Ereignisse>

Diagnosebefehle und Ergebnisse:
<Befehle, Ausgaben und Verweise>

Sofortmaßnahme:
<Workaround oder Eindämmung>

Dauerhafte Lösung:
<umgesetzte Korrektur>

Rollback:
<vorbereitet, durchgeführt oder nicht erforderlich>

Verifikation:
<technische, fachliche, negative und Regressionstests>

Monitoring nach der Lösung:
<Messwerte und Beobachtungsdauer>

Verbleibende Risiken:
<Liste>

Folgeaufgaben:
<Ticket-ID, Verantwortliche, Priorität, Termin und Prüfmethode>

Abschlussfreigabe:
<zuständige Person oder Rolle>

42. Abschlusscheckliste

Ergebnis dieses Arbeitsschrittes

Am Ende dieses Schrittes ist nicht nur die technische Funktion wiederhergestellt. Der gesamte Vorfall ist nachvollziehbar dokumentiert, offene Risiken sind bekannt und konkrete Verbesserungsmaßnahmen wurden zugewiesen.

Eine Störung sollte erst abgeschlossen werden, wenn:

Nächste Seite und Abschluss von Kapitel 1:
1.10 Schnellreferenz – Diagnosebefehle für Windows, Linux und macOS

Offizielle Hersteller-, Behörden- und Projektdokumentation

1. Grundlagen der systematischen Fehleranalyse

1.10 Schnellreferenz – Diagnosebefehle für Windows, Linux und macOS

1.10 Schnellreferenz – Diagnosebefehle für Windows, Linux und macOS

Diese Seite fasst die wichtigsten Diagnosebefehle aus Kapitel 1 als plattformübergreifendes Nachschlagewerk zusammen.

Sie ist für die schnelle Fehlersuche gedacht. Die ausführliche Vorgehensweise, Einschränkungen und Interpretationen befinden sich auf den vorherigen Seiten.

Befehle nicht wahllos nacheinander ausführen. Zuerst Fehlerbild und Umfang bestimmen, flüchtige Informationen sichern und anschließend gezielt prüfen.

Die Bereiche ab Punkt 3 können über die jeweilige Überschrift auf- und zugeklappt werden.

1. Kennzeichnungen

Kennzeichnung Bedeutung
[RO] Read-only: liest Informationen aus
[TEST] Führt eine aktive Prüfung aus
[FILE] Erstellt oder überschreibt eine Datei
[PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte
[CHANGE] Verändert Konfiguration oder Betriebszustand
[DISRUPTIV] Kann Benutzer oder produktive Dienste beeinträchtigen
[SENSITIV] Ausgabe kann vertrauliche Daten enthalten

Auch [RO]-Befehle sind nicht vollständig spurlos. Sie starten Prozesse und können in Shell-Historien, Auditprotokollen oder Sicherheitslösungen erscheinen.

2. Platzhalter

Alle Angaben in spitzen Klammern müssen vor der Ausführung ersetzt werden.

Platzhalter Bedeutung
<Servername> Hostname oder FQDN des Zielservers
<IP-Adresse> IPv4- oder IPv6-Adresse
<Port> TCP- oder UDP-Port
<Dienstname> interner Dienstname
<Dienstlabel> launchd-Label unter macOS
<Prozessname> Name eines Prozesses
<PID> Prozess-ID
<Benutzername> Benutzerkonto
<Datei> vollständiger Dateipfad
<Pfad> Datei- oder Verzeichnispfad
<Zielpfad> freigegebener Speicherort
<Interface> Netzwerkschnittstelle
<DNS-Server-IP> Adresse des abzufragenden DNS-Servers
3. Plattformhinweise
Plattform Hinweise
Windows PowerShell möglichst mit normalen Benutzerrechten starten; erhöhte Rechte nur bei Bedarf
Linux Befehle unterscheiden sich nach Distribution, Init-System und installierten Paketen
macOS Viele Werkzeuge verwenden BSD-Syntax und unterscheiden sich von den Linux-Versionen
Alle Befehle mit Schreib-, Neustart- oder Aufzeichnungsfunktion vorher auf Auswirkungen prüfen

Lokale Hilfe anzeigen

Windows PowerShell Linux macOS
[RO] Get-Help <Befehl> -Full [RO] man <Befehl> [RO] man <Befehl>
[RO] Get-Command <Befehl> -Syntax [RO] <Befehl> --help [RO] <Befehl> -h oder man <Befehl>
4. Schneller Diagnoseablauf
Reihenfolge Prüfung Ziel
1 Uhrzeit und Zeitzone Protokolle korrekt vergleichen
2 Fehler exakt reproduzieren tatsächliches Symptom bestätigen
3 betroffene und funktionierende Systeme vergleichen Fehlerumfang eingrenzen
4 IP-Konfiguration prüfen lokale Netzwerkkonfiguration bestätigen
5 DNS prüfen Name und Zieladresse bestätigen
6 Routing und Gateway prüfen Netzwerkpfad bestätigen
7 Zielport prüfen Transportverbindung testen
8 Protokoll oder Anwendung prüfen HTTP, TLS oder Anwendungsebene
9 Dienst und Listener prüfen serverseitigen Zustand bestätigen
10 Protokolle prüfen technische Fehler und Zeitpunkt finden
11 Ressourcen prüfen CPU, RAM, Datenträger und I/O
12 letzte Änderungen prüfen Updates, Deployments und Konfiguration
13 Hypothesen mit Gegenprobe testen Ursache bestätigen oder widerlegen
14 Ausgangszustand sichern sichere Änderung und Rückfall ermöglichen
15 Lösung umsetzen und Ende-zu-Ende prüfen Funktion dauerhaft bestätigen
5. Datum, Uhrzeit und Zeitzone
Aufgabe Windows Linux macOS
Lokale Zeit [RO] Get-Date -Format o [RO] date --iso-8601=seconds [RO] date "+%Y-%m-%dT%H:%M:%S%z"
UTC-Zeit [RO] (Get-Date).ToUniversalTime().ToString("o") [RO] date -u "+%Y-%m-%dT%H:%M:%SZ" [RO] date -u "+%Y-%m-%dT%H:%M:%SZ"
Zeitzone [RO] Get-TimeZone [RO] timedatectl status [RO][PRIV] sudo systemsetup -gettimezone
Zeitquelle [RO] w32tm /query /source [RO] timedatectl timesync-status [TEST] sntp -d time.apple.com
Synchronisationsstatus [RO] w32tm /query /status [RO] timedatectl status [TEST] sntp -d time.apple.com
chrony-Status Nicht zutreffend [RO] chronyc tracking Nicht standardmäßig vorhanden
chrony-Quellen Nicht zutreffend [RO] chronyc sources -v Nicht standardmäßig vorhanden

Interpretation

Beobachtung Mögliche Bedeutung
Systemzeit weicht ab NTP-, Domänen-, Netzwerk- oder Konfigurationsproblem
Zeitzonen unterscheiden sich Ereignisse vor dem Vergleich umrechnen
Zeitquelle nicht erreichbar Firewall, DNS, Routing oder Zeitdienst prüfen
Kerberos- oder Zertifikatsfehler Systemzeit und Zeitzone zuerst prüfen
6. Hostname, Betriebssystem und Hardware
Aufgabe Windows Linux macOS
Hostname [RO] hostname [RO] hostname [RO] hostname
Systemübersicht [RO] Get-ComputerInfo [RO] hostnamectl [RO] system_profiler SPSoftwareDataType SPHardwareDataType
Betriebssystem [RO] Get-CimInstance Win32_OperatingSystem | Select-Object Caption,Version,BuildNumber [RO] cat /etc/os-release [RO] sw_vers
Kernel und Architektur [RO] systeminfo [RO] uname -a [RO] uname -a
Prozessor [RO] Get-CimInstance Win32_Processor [RO] lscpu [RO] sysctl -n machdep.cpu.brand_string
Hardwaremodell [RO] Get-CimInstance Win32_ComputerSystem [RO][PRIV] dmidecode -t system [RO] system_profiler SPHardwareDataType
Seriennummer [RO] Get-CimInstance Win32_BIOS | Select-Object SerialNumber [RO][PRIV] dmidecode -s system-serial-number [RO] system_profiler SPHardwareDataType

dmidecode ist nicht auf jeder Linux-Installation vorhanden und benötigt üblicherweise Root-Rechte.

7. Systemstart und Betriebsdauer
Aufgabe Windows Linux macOS
Letzter Start [RO] Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime [RO] uptime -s [RO] sysctl -n kern.boottime
Alternative [RO] systeminfo [RO] who -b [RO] last reboot
Betriebsdauer [RO] (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime [RO] uptime [RO] uptime
Neustartverlauf Ereignisanzeige beziehungsweise Systemprotokoll [RO] last reboot [RO] last reboot
Aktueller Boot Ereignisanzeige [RO] journalctl -b Unified Log über Startzeit eingrenzen
Vorheriger Boot Ereignisanzeige [RO] journalctl -b -1 [RO] last reboot
8. Benutzeridentität und Sitzungen
Aufgabe Windows Linux macOS
Aktueller Benutzer [RO] whoami [RO] whoami [RO] whoami
Benutzer-ID und Gruppen [RO][SENSITIV] whoami /all [RO] id [RO] id
Bestimmter Benutzer lokale oder Domänenverwaltung verwenden [RO] id <Benutzername> [RO] id <Benutzername>
Angemeldete Benutzer [RO] quser [RO] who -a [RO] who
Sitzungen und Aktivität [RO] query user [RO] w [RO] w
Lokale Benutzer [RO] Get-LocalUser [RO] getent passwd [RO] dscl . -list /Users
Lokale Gruppen [RO] Get-LocalGroup [RO] getent group [RO] dscl . -list /Groups

Ausgaben können Benutzernamen, SIDs, Gruppen und sicherheitsrelevante Informationen enthalten.

9. Prozesse
Aufgabe Windows Linux macOS
Prozessübersicht [RO] Get-Process [RO][SENSITIV] ps auxww [RO][SENSITIV] ps auxww
PID, Elternprozess und Befehlszeile [RO][SENSITIV] Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId,Name,ExecutablePath,CommandLine [RO][SENSITIV] ps -ef --forest [RO][SENSITIV] ps -axo pid,ppid,user,lstart,state,%cpu,%mem,command
Einzelnen Prozess prüfen [RO] Get-Process -Id <PID> | Format-List * [RO] ps -p <PID> -o pid,ppid,user,lstart,stat,%cpu,%mem,command [RO] ps -p <PID> -o pid,ppid,user,lstart,state,%cpu,%mem,command
Nach Namen suchen [RO] Get-Process -Name <Prozessname> [RO] pgrep -a <Prozessname> [RO] pgrep -fl <Prozessname>
Höchste CPU-Nutzung [RO] Get-Process | Sort-Object CPU -Descending | Select-Object -First 20 [RO] ps aux --sort=-%cpu | head -n 20 [RO] top -l 1 -o cpu
Höchste Speichernutzung [RO] Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 20 [RO] ps aux --sort=-%mem | head -n 20 [RO] top -l 1 -o mem
Offene Dateien eines Prozesses kein einheitlicher integrierter PowerShell-Befehl [RO][PRIV][SENSITIV] lsof -p <PID> [RO][PRIV][SENSITIV] lsof -p <PID>
10. Dienste
Aufgabe Windows Linux mit systemd macOS
Alle Dienste [RO] Get-Service [RO] systemctl list-units --type=service --all [RO] launchctl list
Bestimmten Dienst prüfen [RO] Get-Service -Name <Dienstname> [RO] systemctl status <Dienstname>.service --no-pager [RO][PRIV] launchctl print system/<Dienstlabel>
Benutzerdienst prüfen [RO] Get-Service -Name <Dienstname> [RO] systemctl --user status <Dienstname>.service [RO] launchctl print gui/$(id -u)/<Dienstlabel>
Fehlgeschlagene Dienste Status und Ereignisprotokoll prüfen [RO] systemctl --failed Prozess und Unified Log prüfen
Laufende Dienste [RO] Get-Service | Where-Object Status -eq "Running" [RO] systemctl list-units --type=service --state=running [RO] launchctl list
Dienstkonfiguration [RO][SENSITIV] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" [RO] systemctl cat <Dienstname>.service [RO] plutil -p "<Pfad-zur-plist>"
Prozess-ID [RO] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object ProcessId [RO] systemctl show <Dienstname>.service -p MainPID [RO] launchctl print system/<Dienstlabel>
Startmodus [RO] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object StartMode [RO] systemctl is-enabled <Dienstname>.service Property-List mit plutil -p prüfen
Dienstkonto [RO][SENSITIV] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object StartName [RO] systemctl show <Dienstname>.service -p User -p Group [RO] plutil -p "<Pfad-zur-plist>"
11. Dienstabhängigkeiten
Aufgabe Windows Linux mit systemd macOS
Benötigte Dienste [RO] Get-Service -Name <Dienstname> -RequiredServices [RO] systemctl list-dependencies <Dienstname>.service --all keine allgemeine Abhängigkeitsdarstellung
Abhängige Dienste [RO] Get-Service -Name <Dienstname> -DependentServices [RO] systemctl list-dependencies <Dienstname>.service --reverse --all anwendungsspezifisch prüfen
Reihenfolge und Anforderungen [RO] sc.exe qc <Dienstname> [RO] systemctl show <Dienstname>.service -p Requires -p Wants -p After -p Before Property-List und Dokumentation prüfen
Effektive Konfiguration [RO] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" [RO] systemctl cat <Dienstname>.service [RO] plutil -p "<Pfad-zur-plist>"
12. Arbeitsspeicher
Aufgabe Windows Linux macOS
Arbeitsspeicherübersicht [RO] Get-CimInstance Win32_OperatingSystem | Select-Object TotalVisibleMemorySize,FreePhysicalMemory [RO] free -h [RO] vm_stat
Prozessspeicher [RO] Get-Process | Sort-Object WorkingSet64 -Descending [RO] ps aux --sort=-%mem [RO] top -l 1 -o mem
Laufende Übersicht [RO] Get-Process oder Task-Manager [RO] top [RO] top

Bei Windows werden TotalVisibleMemorySize und FreePhysicalMemory in KiB ausgegeben.

13. Datenträger und Dateisysteme
Aufgabe Windows Linux macOS
Volumes [RO] Get-Volume [RO] lsblk -f [RO] diskutil list
Freier Speicher [RO] Get-PSDrive -PSProvider FileSystem [RO] df -hT [RO] df -h
Inode-Belegung nicht in dieser Unix-Form anwendbar [RO] df -ih [RO] df -ih
Mounts [RO] Get-Volume [RO] findmnt [RO] mount
Physische Datenträger [RO] Get-PhysicalDisk [RO] lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS [RO] diskutil list
Datenträgerinformationen [RO] Get-Disk [RO] lsblk -f [RO] diskutil info <Datenträger>
I/O-Messung Performance Monitor oder passende Counter [RO][TEST] iostat -xz 1 5 [RO][TEST] iostat -w 1 -c 5

iostat gehört unter Linux häufig zum Paket sysstat.

14. IP-Konfiguration
Aufgabe Windows Linux macOS
Vollständige IP-Konfiguration [RO] ipconfig /all [RO] ip -details address show [RO] ifconfig -a
PowerShell-Netzwerkübersicht [RO] Get-NetIPConfiguration Nicht zutreffend Nicht zutreffend
Interfacezustand [RO] Get-NetAdapter [RO] ip -details link show [RO] ifconfig -a
NetworkManager-Geräte Nicht zutreffend [RO] nmcli device status Nicht zutreffend
NetworkManager-Verbindungen Nicht zutreffend [RO][SENSITIV] nmcli connection show Nicht zutreffend
Hardwareports [RO] Get-NetAdapter [RO] ip link show [RO] networksetup -listallhardwareports
Netzwerkdienste Adapter über PowerShell NetworkManager oder systemd-networkd [RO] networksetup -listallnetworkservices
15. DHCP-Informationen am Client
Aufgabe Windows Linux macOS
DHCP-Server und Lease [RO] ipconfig /all abhängig vom Netzwerkmanager und DHCP-Client [RO] ipconfig getpacket <Interface>
NetworkManager-DHCP Nicht zutreffend [RO] nmcli device show <Interface> Nicht zutreffend
systemd-networkd Nicht zutreffend [RO] networkctl status <Interface> Nicht zutreffend
Interface-IP [RO] Get-NetIPAddress [RO] ip address show <Interface> [RO] ipconfig getifaddr <Interface>

DHCP-Lease-Dateien und Speicherorte unterscheiden sich nach Distribution und verwendetem Netzwerkdienst.

16. DNS-Konfiguration
Aufgabe Windows Linux macOS
DNS-Server [RO] Get-DnsClientServerAddress [RO] resolvectl status [RO][SENSITIV] scutil --dns
Resolverdatei ipconfig /all verwenden [RO] cat /etc/resolv.conf [RO] cat /etc/resolv.conf
Suchdomänen [RO] ipconfig /all [RO] resolvectl status [RO][SENSITIV] scutil --dns
DNS-Cache [RO][SENSITIV] Get-DnsClientCache kein einheitlicher systemweiter Cache-Dump kein einheitlicher systemweiter Cache-Dump
Alternative Cacheanzeige [RO][SENSITIV] ipconfig /displaydns abhängig vom Resolver abhängig vom Resolver
17. DNS-Auflösung
Aufgabe Windows Linux macOS
Standardabfrage [TEST] Resolve-DnsName <Servername> [TEST] getent ahosts <Servername> [TEST] dscacheutil -q host -a name <Servername>
Abfrage mit dig dig nur wenn installiert [TEST] dig <Servername> [TEST] dig <Servername>
Kurze Ausgabe [TEST] Resolve-DnsName <Servername> | Select-Object Name,Type,IPAddress [TEST] dig +short <Servername> [TEST] dig +short <Servername>
Bestimmten DNS-Server abfragen [TEST] Resolve-DnsName <Servername> -Server <DNS-Server-IP> [TEST] dig @<DNS-Server-IP> <Servername> [TEST] dig @<DNS-Server-IP> <Servername>
nslookup [TEST] nslookup <Servername> [TEST] nslookup <Servername> [TEST] nslookup <Servername>
Reverse Lookup [TEST] Resolve-DnsName <IP-Adresse> [TEST] dig -x <IP-Adresse> [TEST] dig -x <IP-Adresse>

Interpretation

Ergebnis Mögliche Bedeutung
Name wird nicht aufgelöst DNS-Server, Clientkonfiguration, Zone oder Netzwerk
Falsche IP-Adresse falscher Eintrag, Cache, Hosts-Datei oder Split-DNS
Verschiedene IP-Adressen Load Balancing, DNS-Rotation oder unterschiedliche Resolver
Bestimmter DNS-Server antwortet korrekt Standardresolver oder Clientkonfiguration prüfen
IP funktioniert, Name nicht DNS priorisieren
18. Hosts-Datei anzeigen
Windows Linux macOS
[RO] Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" [RO] cat /etc/hosts [RO] cat /etc/hosts

Die Hosts-Datei kann DNS-Ergebnisse lokal überschreiben.

19. Routing
Aufgabe Windows Linux macOS
Routingtabelle [RO] route print [RO] ip route show table all [RO] netstat -rn
PowerShell-Routen [RO] Get-NetRoute Nicht zutreffend Nicht zutreffend
IPv4-Routen [RO] Get-NetRoute -AddressFamily IPv4 [RO] ip -4 route show table all [RO] netstat -rn -f inet
IPv6-Routen [RO] Get-NetRoute -AddressFamily IPv6 [RO] ip -6 route show table all [RO] netstat -rn -f inet6
Route zu einem Ziel [RO] Test-NetConnection <IP-Adresse> -DiagnoseRouting -InformationLevel Detailed [RO] ip route get <IP-Adresse> [RO] route -n get <IP-Adresse>
Standardroute [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" [RO] ip route show default [RO] route -n get default
20. ARP- und Neighbor-Tabelle
Aufgabe Windows Linux macOS
ARP-Tabelle [RO] arp -a [RO] ip neigh show [RO] arp -an
PowerShell-Neighbor [RO] Get-NetNeighbor Nicht zutreffend Nicht zutreffend
Bestimmtes Interface [RO] Get-NetNeighbor -InterfaceAlias "<Interface>" [RO] ip neigh show dev <Interface> [RO] arp -an

Interpretation

Zustand Bedeutung
Reachable Nachbar wurde kürzlich bestätigt
Stale Eintrag vorhanden, aber nicht aktuell bestätigt
Incomplete oder Failed Adressauflösung fehlgeschlagen
unterschiedliche MAC-Adressen Redundanz, Proxy ARP, IP-Konflikt oder Änderung prüfen
21. Proxykonfiguration
Aufgabe Windows Linux macOS
WinHTTP-Proxy [RO] netsh winhttp show proxy Nicht zutreffend Nicht zutreffend
Umgebungsvariablen [RO][SENSITIV] Get-ChildItem Env: | Where-Object Name -Match "proxy" [RO][SENSITIV] env | grep -i proxy [RO][SENSITIV] env | grep -i proxy
Systemproxy Internetoptionen und Richtlinien prüfen Desktop- oder Netzwerkmanager abhängig [RO] scutil --proxy
curl ohne Proxy [TEST] curl.exe --noproxy "*" -v https://<Servername>/ [TEST] curl --noproxy "*" -v https://<Servername>/ [TEST] curl --noproxy "*" -v https://<Servername>/

Das Umgehen eines Unternehmensproxys darf nur erfolgen, wenn direkte Verbindungen erlaubt und der Test autorisiert ist.

22. Aktive TCP-Verbindungen
Aufgabe Windows Linux macOS
TCP-Verbindungen [RO][PRIV] Get-NetTCPConnection [RO][PRIV] ss -tanp [RO] netstat -anv -p tcp
Verbindungen mit PID [RO][PRIV] Get-NetTCPConnection | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcess [RO][PRIV] ss -tanp [RO][PRIV] lsof -nP -iTCP
Klassische Übersicht [RO][PRIV] netstat -ano [RO] netstat -antp sofern installiert [RO] netstat -anv -p tcp
Bestehende Verbindungen [RO] Get-NetTCPConnection -State Established [RO][PRIV] ss -tanp state established [RO][PRIV] lsof -nP -iTCP -sTCP:ESTABLISHED
23. UDP-Endpunkte
Windows Linux macOS
[RO][PRIV] Get-NetUDPEndpoint [RO][PRIV] ss -uanp [RO] netstat -anv -p udp
[RO][PRIV] netstat -ano -p udp [RO][PRIV] lsof -nP -iUDP [RO][PRIV] lsof -nP -iUDP

UDP besitzt keinen TCP-Verbindungszustand wie Established. Ein offener UDP-Endpunkt bestätigt nicht, dass eine Anwendung antwortet.

24. TCP-Listener
Aufgabe Windows Linux macOS
Alle Listener [RO][PRIV] Get-NetTCPConnection -State Listen [RO][PRIV] ss -lntp [RO][PRIV] lsof -nP -iTCP -sTCP:LISTEN
Bestimmter Port [RO][PRIV] Get-NetTCPConnection -State Listen -LocalPort <Port> [RO][PRIV] ss -lntp | grep ":<Port>" [RO][PRIV] lsof -nP -iTCP:<Port> -sTCP:LISTEN
PID zu Listener Eigenschaft OwningProcess verwenden Ausgabe von ss -lntp Ausgabe von lsof
Prozess zur PID [RO] Get-Process -Id <PID> [RO] ps -p <PID> -o pid,user,command [RO] ps -p <PID> -o pid,user,command

Ein Listener bestätigt nur, dass ein Prozess den Port gebunden hat. Die Anwendung kann intern trotzdem fehlerhaft sein.

25. ICMP-Erreichbarkeit
Aufgabe Windows Linux macOS
Vier Ping-Versuche [TEST] ping -n 4 <IP-Adresse> [TEST] ping -c 4 <IP-Adresse> [TEST] ping -c 4 <IP-Adresse>
Zehn Versuche [TEST] ping -n 10 <IP-Adresse> [TEST] ping -c 10 <IP-Adresse> [TEST] ping -c 10 <IP-Adresse>
PowerShell-Test [TEST] Test-Connection -ComputerName <Servername> -Count 4 PowerShell nur wenn installiert PowerShell nur wenn installiert

Ein fehlgeschlagener Ping beweist keinen Serverausfall. ICMP kann blockiert sein, während TCP- oder UDP-Dienste funktionieren.

26. TCP-Port testen
Windows Linux macOS
[TEST] Test-NetConnection <Servername> -Port <Port> -InformationLevel Detailed [TEST] nc -vz -w 3 <Servername> <Port> [TEST] nc -vz -w 3 <Servername> <Port>
[TEST] Test-NetConnection <Servername> -Port <Port> -InformationLevel Quiet nc verwenden nc verwenden

Windows-Auswertung

Besonders relevantes Feld:

TcpTestSucceeded

Interpretation

Ergebnis Mögliche Bedeutung
Verbindung erfolgreich Netzwerkpfad und TCP-Listener grundsätzlich erreichbar
Connection refused Ziel erreichbar, aber kein Listener oder aktive Ablehnung
Timeout Filterung, Routing, Überlastung oder nicht antwortendes Ziel
Name nicht auflösbar DNS zuerst prüfen
Nur ein Client betroffen lokales System, lokales Netz oder lokale Sicherheitssoftware
Nur ein VLAN betroffen ACL, Routing, Firewall oder VLAN-Konfiguration
27. Netzwerkpfad verfolgen
Windows Linux macOS
[TEST] tracert <Servername> [TEST] tracepath <Servername> [TEST] traceroute <Servername>
[TEST] Test-NetConnection <Servername> -TraceRoute [TEST] traceroute <Servername> sofern installiert [TEST] traceroute <Servername>

Sternchen bedeuten nicht automatisch einen Fehler. Router können Traceroute-Anfragen ignorieren und Nutzverkehr trotzdem weiterleiten.

28. Lokalen und entfernten Dienst vergleichen
Testpunkt Windows Linux macOS
localhost [TEST] Test-NetConnection localhost -Port <Port> [TEST] nc -vz -w 3 localhost <Port> [TEST] nc -vz -w 3 localhost <Port>
eigene IP [TEST] Test-NetConnection <Eigene-IP> -Port <Port> [TEST] nc -vz -w 3 <Eigene-IP> <Port> [TEST] nc -vz -w 3 <Eigene-IP> <Port>
Servername [TEST] Test-NetConnection <Servername> -Port <Port> [TEST] nc -vz -w 3 <Servername> <Port> [TEST] nc -vz -w 3 <Servername> <Port>

Interpretation

localhost Eigene IP Remote Möglicher Fehlerbereich
erfolgreich erfolgreich fehlgeschlagen Netzwerkpfad oder Firewall
erfolgreich fehlgeschlagen fehlgeschlagen Bindung oder lokale Firewall
fehlgeschlagen fehlgeschlagen fehlgeschlagen Dienst oder Anwendung
erfolgreich erfolgreich erfolgreich Transportebene funktioniert
29. HTTP- und HTTPS-Test
Aufgabe Windows Linux macOS
Ausführlicher Test [TEST] curl.exe -v -o NUL https://<Servername>/ [TEST] curl -v -o /dev/null https://<Servername>/ [TEST] curl -v -o /dev/null https://<Servername>/
Nur Header [TEST] curl.exe -vI https://<Servername>/ [TEST] curl -vI https://<Servername>/ [TEST] curl -vI https://<Servername>/
Zeitbegrenzung [TEST] curl.exe --connect-timeout 5 --max-time 15 https://<Servername>/ [TEST] curl --connect-timeout 5 --max-time 15 https://<Servername>/ [TEST] curl --connect-timeout 5 --max-time 15 https://<Servername>/
HTTP-Fehler als curl-Fehler [TEST] curl.exe --fail https://<Servername>/ [TEST] curl --fail https://<Servername>/ [TEST] curl --fail https://<Servername>/

Einige Server unterstützen die HTTP-Methode HEAD nicht korrekt. Ein fehlgeschlagener curl -I-Test sollte daher mit einem normalen GET-Test verglichen werden.

30. HTTP-Zeiten messen

Windows PowerShell

[TEST] curl.exe -sS -o NUL -w 'code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' --connect-timeout 5 --max-time 15 https://<Servername>/

Linux und macOS

[TEST] curl -sS -o /dev/null -w "code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n" --connect-timeout 5 --max-time 15 https://<Servername>/

Wert Bedeutung
http_code HTTP-Status
remote_ip verwendete Ziel-IP
time_namelookup Dauer der Namensauflösung
time_connect Dauer bis TCP-Verbindungsaufbau
time_appconnect Dauer bis TLS-Verbindungsaufbau
time_starttransfer Dauer bis zum ersten Byte
time_total Gesamtzeit
31. Bestimmtes HTTPS-Ziel ohne DNS-Änderung testen
Windows Linux macOS
[TEST] curl.exe --resolve "<Servername>:443:<IP-Adresse>" -v -o NUL https://<Servername>/ [TEST] curl --resolve "<Servername>:443:<IP-Adresse>" -v -o /dev/null https://<Servername>/ [TEST] curl --resolve "<Servername>:443:<IP-Adresse>" -v -o /dev/null https://<Servername>/

--resolve behält für diesen curl-Aufruf:

Nur die Ziel-IP wird vorgegeben.

32. TLS prüfen
Aufgabe Windows Linux macOS
TLS-Verbindung [TEST] openssl s_client -connect <Servername>:443 -servername <Servername> -showcerts sofern OpenSSL installiert [TEST] openssl s_client -connect <Servername>:443 -servername <Servername> -showcerts </dev/null [TEST] openssl s_client -connect <Servername>:443 -servername <Servername> -showcerts </dev/null
OpenSSL-Version [RO] openssl version -a [RO] openssl version -a [RO] openssl version -a
Zertifikatdatei [RO] openssl x509 -in "<Datei.pem>" -noout -text [RO] openssl x509 -in "<Datei.pem>" -noout -text [RO] openssl x509 -in "<Datei.pem>" -noout -text

Zu prüfen

33. HTTP-Status schnell interpretieren
Status Typische Bedeutung
200 Anfrage erfolgreich
301 oder 302 Weiterleitung
400 ungültige Anfrage
401 Authentifizierung erforderlich oder fehlgeschlagen
403 Zugriff verweigert
404 Ressource oder Pfad nicht gefunden
408 Anfrage-Timeout
429 zu viele Anfragen oder Rate Limit
500 interner Anwendungsfehler
502 Proxy oder Gateway erhält ungültige Backend-Antwort
503 Dienst oder Backend nicht verfügbar
504 Proxy oder Gateway wartet vergeblich auf Backend
000 bei curl keine gültige HTTP-Antwort empfangen

Die genaue Bedeutung kann durch die Anwendung erweitert oder verändert werden.

34. Windows-Ereignisprotokolle
Aufgabe Befehl
Systemprotokoll [RO] Get-WinEvent -LogName "System" -MaxEvents 100
Anwendungsprotokoll [RO] Get-WinEvent -LogName "Application" -MaxEvents 100
Warnungen und Fehler [RO] Get-WinEvent -FilterHashtable @{LogName="System"; Level=2,3; StartTime=(Get-Date).AddHours(-1)}
Kritische Fehler und Fehler [RO] Get-WinEvent -FilterHashtable @{LogName="System"; Level=1,2; StartTime=(Get-Date).AddHours(-1)}
Zeitfenster [RO] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"}
Ereignis-ID [RO] Get-WinEvent -FilterHashtable @{LogName="System"; Id=<Ereignis-ID>; StartTime=(Get-Date).AddHours(-1)}
Anbieter [RO] Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="<Anbieter>"; StartTime=(Get-Date).AddHours(-1)}
Übersicht [RO] Get-WinEvent -LogName "System" -MaxEvents 100 | Select-Object TimeCreated,Id,ProviderName,LevelDisplayName,Message

Windows-Ereignisstufen

Level Bedeutung
1 Kritisch
2 Fehler
3 Warnung
4 Information
5 Ausführlich
35. Windows-Dienstereignisse
Ereignis-ID Typische Bedeutung
7031 Dienst wurde unerwartet beendet
7034 Dienst wurde unerwartet beendet
7036 Dienstzustand wurde geändert
7040 Starttyp wurde geändert
7045 neuer Dienst wurde installiert

Abfrage

[RO] Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"; Id=7031,7034,7036,7040,7045; StartTime=(Get-Date).AddHours(-1)} | Select-Object TimeCreated,Id,Message

36. Windows-Ereignisprotokolle exportieren
Protokoll Befehl
System [FILE][PRIV] wevtutil epl System "<Zielpfad>\System.evtx"
Application [FILE][PRIV] wevtutil epl Application "<Zielpfad>\Application.evtx"
Security [FILE][PRIV][SENSITIV] wevtutil epl Security "<Zielpfad>\Security.evtx"
PowerShell Operational [FILE][PRIV][SENSITIV] wevtutil epl "Microsoft-Windows-PowerShell/Operational" "<Zielpfad>\PowerShell-Operational.evtx"

Vor dem Export sollte ein neuer Zielordner verwendet werden. Vorhandene Dateien dürfen nicht unkontrolliert überschrieben werden.

37. Linux-Journal
Aufgabe Befehl
Aktueller Boot [RO] journalctl -b
Vorheriger Boot [RO] journalctl -b -1
Letzte Stunde [RO] journalctl --since "1 hour ago"
Zeitfenster [RO] journalctl --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"
Bestimmter Dienst [RO] journalctl -u <Dienstname>.service --since "1 hour ago"
Kernelmeldungen [RO] journalctl -k -b
Warnungen und schwerer [RO] journalctl -p warning --since "1 hour ago"
Nur Fehler [RO] journalctl -p err --since "1 hour ago"
ISO-Zeitstempel [RO] journalctl -o short-iso-precise --since "1 hour ago"
Ohne Pager [RO] journalctl --since "1 hour ago" --no-pager
Klassische Kernelmeldungen [RO][PRIV] dmesg --ctime
38. Linux-Journal exportieren
Aufgabe Befehl
Aktueller Boot [FILE] journalctl -b --no-pager --output=short-iso-precise > "<Zielpfad>/journal-current-boot.log"
Vorheriger Boot [FILE] journalctl -b -1 --no-pager --output=short-iso-precise > "<Zielpfad>/journal-previous-boot.log"
Zeitfenster [FILE] journalctl --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" --no-pager --output=short-iso-precise > "<Zielpfad>/journal-time-window.log"
Dienst [FILE] journalctl -u <Dienstname>.service --since "1 hour ago" --no-pager --output=short-iso-precise > "<Zielpfad>/<Dienstname>.log"
Kernelmeldungen [FILE][PRIV] dmesg --ctime > "<Zielpfad>/dmesg.log"

Die Umleitung mit > überschreibt eine vorhandene Datei. Deshalb sollte ein neuer Zielordner verwendet werden.

39. macOS Unified Log
Aufgabe Befehl
Letzte Stunde [RO][SENSITIV] log show --last 1h --style compact
Zeitfenster [RO][SENSITIV] log show --start "2026-07-30 14:00:00" --end "2026-07-30 15:00:00" --style compact
Fehler und Faults [RO][SENSITIV] log show --last 1h --predicate 'messageType == error OR messageType == fault' --style compact
Bestimmter Prozess [RO][SENSITIV] log show --last 1h --predicate 'process == "<Prozessname>"' --style compact
Prozessfehler [RO][SENSITIV] log show --last 1h --predicate 'process == "<Prozessname>" AND (messageType == error OR messageType == fault)' --style compact
Live-Ansicht [RO][SENSITIV] log stream --style compact

Export

[FILE][SENSITIV] log show --last 1h --style compact > "<Zielpfad>/macOS-unified-log.txt"

Grafische Werkzeuge

40. Windows-Updates und Installationsverlauf
Aufgabe Befehl
Installierte Hotfixes [RO] Get-HotFix | Sort-Object InstalledOn -Descending
Hotfixdetails [RO] Get-HotFix | Select-Object InstalledOn,HotFixID,Description,InstalledBy
Updateereignisse [RO] Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" -MaxEvents 100
Updateereignisse im Zeitfenster [RO] Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-WindowsUpdateClient/Operational"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"}
Lesbare Updateprotokolldatei [FILE] Get-WindowsUpdateLog -LogPath "<Zielpfad>\WindowsUpdate.log"

Get-HotFix zeigt nicht zwingend jede Aktualisierung. Zusätzlich sollten Windows-Updateverlauf und Patchmanagement geprüft werden.

41. Linux-Paketverlauf
Distribution Aufgabe Befehl
Debian/Ubuntu APT-Verlauf [RO] less /var/log/apt/history.log
Debian/Ubuntu DPKG-Verlauf [RO] less /var/log/dpkg.log
Debian/Ubuntu Paketänderungen [RO] grep -E " install | upgrade | remove " /var/log/dpkg.log
Debian/Ubuntu rotierte Logs [RO] zgrep -hE " install | upgrade | remove " /var/log/dpkg.log*
RHEL/Rocky/Alma/Fedora DNF-Verlauf [RO] dnf history list
RHEL/Rocky/Alma/Fedora Transaktionsdetails [RO] dnf history info <Transaktions-ID>
RHEL/Rocky/Alma/Fedora letzte Transaktion [RO] dnf history info last
RPM-basiert Pakete nach Installationszeit [RO] rpm -qa --last
SUSE/openSUSE Zypper-Verlauf [RO] less /var/log/zypp/history
Arch Linux Pacman-Verlauf [RO] less /var/log/pacman.log
Arch Linux Änderungen filtern [RO] grep -E "\[ALPM\] (installed|upgraded|removed)" /var/log/pacman.log
42. macOS-Installationsverlauf
Aufgabe Befehl
Softwareupdateverlauf [RO] softwareupdate --history
Installationsverlauf [RO] system_profiler SPInstallHistoryDataType
Installierte Anwendungen [RO] system_profiler SPApplicationsDataType

Grafischer Weg:

Systeminformationen → Software → Installationen

43. Geplante Aufgaben und Automatisierung
Aufgabe Windows Linux macOS
Geplante Aufgaben [RO] Get-ScheduledTask [RO] crontab -l [RO] launchctl list
Laufzeitinformationen [RO] Get-ScheduledTask | Get-ScheduledTaskInfo | Sort-Object LastRunTime -Descending [RO] systemctl list-timers --all [RO] launchctl list
Auffällige Ergebnisse [RO] Get-ScheduledTask | Get-ScheduledTaskInfo | Where-Object LastTaskResult -ne 0 Cron- und Dienstprotokolle prüfen Unified Log prüfen
Task-Scheduler-Protokoll [RO] Get-WinEvent -LogName "Microsoft-Windows-TaskScheduler/Operational" -MaxEvents 100 Nicht zutreffend Nicht zutreffend
Systemweite Cronjobs Nicht zutreffend [RO] ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly Nicht zutreffend
Debian/Ubuntu-Cronlog Nicht zutreffend [RO] journalctl -u cron --since "1 hour ago" Nicht zutreffend
RHEL-Cronlog Nicht zutreffend [RO] journalctl -u crond --since "1 hour ago" Nicht zutreffend
LaunchDaemons Nicht zutreffend Nicht zutreffend [RO] ls -la /Library/LaunchDaemons
Systemweite LaunchAgents Nicht zutreffend Nicht zutreffend [RO] ls -la /Library/LaunchAgents
Benutzer-LaunchAgents Nicht zutreffend Nicht zutreffend [RO] ls -la ~/Library/LaunchAgents

Ein von 0 abweichendes Task-Ergebnis muss anhand der jeweiligen Aufgabe interpretiert werden.

44. Dateiinformationen
Aufgabe Windows Linux macOS
Dateiinformationen [RO] Get-Item "<Datei>" | Select-Object FullName,Length,CreationTime,LastWriteTime [RO] stat "<Datei>" [RO] stat -x "<Datei>"
Dateityp Erweiterung und Anwendung prüfen [RO] file "<Datei>" [RO] file "<Datei>"
Programmversion [RO] (Get-Item "<Datei>").VersionInfo Paketmanager oder --version --version oder Systeminformationen
Dateiinhalt [RO] Get-Content "<Datei>" [RO] less "<Datei>" [RO] less "<Datei>"
Rohinhalt [RO] Get-Content "<Datei>" -Raw [RO] cat "<Datei>" [RO] cat "<Datei>"

Bei großen oder binären Dateien sollte nicht der gesamte Inhalt unkontrolliert ausgegeben werden.

45. Dateien und Konfigurationen vergleichen
Aufgabe Windows Linux macOS
Textdateien vergleichen [RO] Compare-Object (Get-Content "<Datei-A>") (Get-Content "<Datei-B>") [RO] diff -u "<Datei-A>" "<Datei-B>" [RO] diff -u "<Datei-A>" "<Datei-B>"
Binäre Gleichheit [RO] Get-FileHash "<Datei>" -Algorithm SHA256 [RO] sha256sum "<Datei>" [RO] shasum -a 256 "<Datei>"
Git-Arbeitszustand [RO] git status [RO] git status [RO] git status
Git-Änderungen [RO] git diff [RO] git diff [RO] git diff
Letzte Commits [RO] git log --oneline --decorate -n 20 [RO] git log --oneline --decorate -n 20 [RO] git log --oneline --decorate -n 20
Verlauf einer Datei [RO] git log -p -- "<Datei>" [RO] git log -p -- "<Datei>" [RO] git log -p -- "<Datei>"
46. Prüfsummen
Aufgabe Windows Linux macOS
SHA-256 einer Datei [RO] Get-FileHash "<Datei>" -Algorithm SHA256 [RO] sha256sum "<Datei>" [RO] shasum -a 256 "<Datei>"
Prüfsumme prüfen neu berechnen und vergleichen [RO] sha256sum -c "<SHA256SUMS-Datei>" [RO] shasum -a 256 -c "<SHA256SUMS-Datei>"
Ordner-Manifest [FILE] Get-ChildItem "<Diagnoseordner>" -File -Recurse | Get-FileHash -Algorithm SHA256 | Export-Csv "<Diagnoseordner>-SHA256.csv" -NoTypeInformation -Encoding UTF8 [FILE] (cd "<Diagnoseordner>" && find . -type f -print0 | sort -z | xargs -0 -r sha256sum) > "<Diagnoseordner>-SHA256SUMS.txt" [FILE] find "<Diagnoseordner>" -type f -exec shasum -a 256 {} \; > "<Diagnoseordner>-SHA256SUMS.txt"

Eine Prüfsumme dokumentiert die Dateiintegrität ab dem Zeitpunkt ihrer Berechnung, aber nicht automatisch Herkunft oder Authentizität.

47. Dateiberechtigungen
Aufgabe Windows Linux macOS
ACL anzeigen [RO][SENSITIV] Get-Acl "<Pfad>" | Format-List [RO][SENSITIV] getfacl "<Pfad>" [RO][SENSITIV] ls -lde "<Pfad>"
Klassische Ansicht [RO][SENSITIV] icacls "<Pfad>" [RO] ls -ld "<Pfad>" [RO] ls -lde "<Pfad>"
Benutzergruppen [RO][SENSITIV] whoami /all [RO] id <Benutzername> [RO] id <Benutzername>
Vollständigen Pfad prüfen Pfadabschnitte mit Get-Acl prüfen [RO] namei -l "<Pfad>" Pfadabschnitte mit ls -lde prüfen
Besitzer und Gruppe [RO] Get-Acl "<Pfad>" | Select-Object Owner [RO] stat "<Pfad>" [RO] stat -x "<Pfad>"
48. Active Directory und Gruppenrichtlinien
Aufgabe Windows
Benutzer- und Gruppeninformationen [RO][SENSITIV] whoami /all
Resultierende Richtlinien kompakt [RO] gpresult /r
HTML-Bericht [FILE] gpresult /h "<Zielpfad>\gpresult.html"
Gruppenrichtlinienprotokoll [RO] Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 100
Sicheren Domänenkanal prüfen [TEST] Test-ComputerSecureChannel -Verbose
Bestimmten Domänencontroller prüfen [TEST] Test-ComputerSecureChannel -Server "<Domänencontroller>" -Verbose
Sicherheitsereignisse [RO][PRIV][SENSITIV] Get-WinEvent -LogName "Security" -MaxEvents 100

Test-ComputerSecureChannel ist für Domänenmitgliedscomputer vorgesehen. Der Parameter -Repair wäre eine Änderung und ist kein reiner Test.

49. Konfigurationssyntax prüfen
Format oder Dienst Windows Linux macOS
JSON mit PowerShell [TEST] Get-Content "<Datei.json>" -Raw | ConvertFrom-Json | Out-Null PowerShell nur wenn installiert PowerShell nur wenn installiert
JSON mit Python [TEST] python3 -m json.tool "<Datei.json>" > NUL [TEST] python3 -m json.tool "<Datei.json>" > /dev/null [TEST] python3 -m json.tool "<Datei.json>" > /dev/null
JSON mit jq [TEST] jq empty "<Datei.json>" [TEST] jq empty "<Datei.json>" [TEST] jq empty "<Datei.json>"
Property List Nicht zutreffend Nicht zutreffend [TEST] plutil -lint "<Datei.plist>"
systemd-Unit Nicht zutreffend [TEST] systemd-analyze verify "<Datei.service>" Nicht zutreffend
NGINX [TEST][PRIV] nginx -t sofern installiert [TEST][PRIV] nginx -t [TEST][PRIV] nginx -t sofern installiert
Apache installationsabhängig [TEST][PRIV] apachectl configtest [TEST][PRIV] apachectl configtest
OpenSSH-Server [TEST][PRIV] sshd -t sofern installiert [TEST][PRIV] sshd -t [TEST][PRIV] sshd -t

Ein erfolgreicher Syntax-Test bestätigt nicht, dass Netzwerkziele, Zertifikate, Berechtigungen und Abhängigkeiten funktionieren.

50. Terminal- und Diagnosesitzung protokollieren
Aufgabe Windows PowerShell Linux macOS
Aufzeichnung starten [FILE][SENSITIV] Start-Transcript -Path "<Zielpfad>\Testprotokoll.txt" -IncludeInvocationHeader -NoClobber [FILE][SENSITIV] script "<Zielpfad>/Testprotokoll.txt" [FILE][SENSITIV] script "<Zielpfad>/Testprotokoll.txt"
Aufzeichnung beenden [FILE] Stop-Transcript exit oder Strg + D exit oder Strg + D
Anzeigen und speichern [FILE] <Befehl> | Tee-Object -FilePath "<Zielpfad>\Ausgabe.txt" [FILE] <Befehl> 2>&1 | tee "<Zielpfad>/Ausgabe.txt" [FILE] <Befehl> 2>&1 | tee "<Zielpfad>/Ausgabe.txt"
Ausgabe und Fehler speichern [FILE] <Befehl> *> "<Zielpfad>\Ausgabe.txt" [FILE] <Befehl> > "<Zielpfad>/Ausgabe.txt" 2>&1 [FILE] <Befehl> > "<Zielpfad>/Ausgabe.txt" 2>&1

Transkripte können Benutzernamen, Pfade und andere sensible Informationen enthalten.

51. Rückgabewerte prüfen
Plattform Befehl Bedeutung
PowerShell-Cmdlet [RO] $? Erfolg der vorherigen PowerShell-Operation
PowerShell mit externem Programm [RO] $LASTEXITCODE Exit-Code des letzten nativen Programms
Windows CMD [RO] echo %ERRORLEVEL% Exit-Code des letzten Programms
Linux [RO] echo $? Exit-Code des letzten Befehls
macOS [RO] echo $? Exit-Code des letzten Befehls

Der Wert muss unmittelbar nach dem betreffenden Befehl gesichert werden.

Ein Exit-Code 0 bedeutet nur, dass das Werkzeug Erfolg meldet. Die Benutzer- oder Anwendungsfunktion kann trotzdem fehlschlagen.

52. Werkzeugversionen
Aufgabe Windows Linux macOS
PowerShell-Version [RO] $PSVersionTable [RO] pwsh -Version sofern installiert [RO] pwsh -Version sofern installiert
curl-Version [RO] curl.exe --version [RO] curl --version [RO] curl --version
OpenSSL-Version [RO] openssl version -a [RO] openssl version -a [RO] openssl version -a
Git-Version [RO] git --version [RO] git --version [RO] git --version
Python-Version [RO] python --version oder python3 --version [RO] python3 --version [RO] python3 --version

Unterschiedliche Versionen können verschiedene Optionen, Protokolle oder Standardwerte verwenden.

53. Paketaufzeichnung

Paketaufzeichnungen können vertrauliche Nutzdaten, Hostnamen, IP-Adressen und Sitzungsinformationen enthalten. Berechtigung, Speicherort, Zeitraum und Datenschutz müssen vorher geklärt sein.

Windows mit pktmon

Aufgabe Befehl
Aufzeichnung starten [FILE][TEST][PRIV][SENSITIV] pktmon start --capture --pkt-size 0 --file-name "<Zielpfad>\capture.etl"
Aufzeichnung beenden [TEST][PRIV] pktmon stop
In PCAPNG umwandeln [FILE][SENSITIV] pktmon etl2pcap "<Zielpfad>\capture.etl" --out "<Zielpfad>\capture.pcapng"

Linux mit tcpdump

[FILE][TEST][PRIV][SENSITIV] sudo tcpdump -i any -nn -s 0 -w "<Zielpfad>/capture.pcap"

macOS mit tcpdump

[FILE][TEST][PRIV][SENSITIV] sudo tcpdump -i <Interface> -nn -s 0 -w "<Zielpfad>/capture.pcap"

Beenden mit Strg + C.

54. Dienständerungen – nur nach Sicherung und Freigabe

Die folgenden Befehle verändern den Betriebszustand und gehören nicht an den Anfang der Diagnose.

Aufgabe Windows Linux macOS
Neustart nur anzeigen [TEST] Restart-Service -Name <Dienstname> -WhatIf keine vollständige systemctl-Simulation keine vollständige launchctl-Simulation
Dienst starten [CHANGE][PRIV] Start-Service -Name <Dienstname> -Confirm [CHANGE][PRIV] sudo systemctl start <Dienstname>.service [CHANGE][PRIV] sudo launchctl kickstart system/<Dienstlabel>
Konfiguration neu laden anwendungsspezifisch [CHANGE][PRIV] sudo systemctl reload <Dienstname>.service anwendungsspezifisch
Dienst neu starten [CHANGE][DISRUPTIV][PRIV] Restart-Service -Name <Dienstname> -Confirm [CHANGE][DISRUPTIV][PRIV] sudo systemctl restart <Dienstname>.service [CHANGE][DISRUPTIV][PRIV] sudo launchctl kickstart -k system/<Dienstlabel>
Nur laufenden Dienst neu starten Status vorher prüfen [CHANGE][DISRUPTIV][PRIV] sudo systemctl try-restart <Dienstname>.service Status vorher prüfen
Zustand danach [RO] Get-Service -Name <Dienstname> [RO] systemctl status <Dienstname>.service --no-pager [RO][PRIV] launchctl print system/<Dienstlabel>

Ein Reload funktioniert nur, wenn der jeweilige Dienst diese Funktion unterstützt.

55. Konfigurationsdatei sichern

Windows

$backupFile = Join-Path "<Zielpfad>" "config-$(Get-Date -Format 'yyyyMMdd-HHmmss').bak"
Copy-Item "<Konfigurationsdatei>" $backupFile
Get-FileHash -Path "<Konfigurationsdatei>", $backupFile -Algorithm SHA256

Linux

backup_file="<Zielpfad>/config-$(date +%Y%m%d-%H%M%S).bak"
cp --preserve=all -- "<Konfigurationsdatei>" "$backup_file"
sha256sum "<Konfigurationsdatei>" "$backup_file"

macOS

backup_file="<Zielpfad>/config-$(date +%Y%m%d-%H%M%S).bak"
cp -p "<Konfigurationsdatei>" "$backup_file"
shasum -a 256 "<Konfigurationsdatei>" "$backup_file"

Für komplexe Anwendungen, Datenbanken, Verzeichnisdienste und Cluster muss die vorgesehene Backup- oder Exportfunktion verwendet werden.

56. Einfache Konfigurationsdatei zurückspielen

Nur verwenden, wenn Sicherung, Dateirechte, Besitzer, Metadaten und Anwendungsvorgaben geprüft wurden.

Windows Linux macOS
[CHANGE][PRIV] Copy-Item "<Sicherungsdatei>" "<Konfigurationsdatei>" -Force [CHANGE][PRIV] sudo cp --preserve=all -- "<Sicherungsdatei>" "<Konfigurationsdatei>" [CHANGE][PRIV] sudo cp -p "<Sicherungsdatei>" "<Konfigurationsdatei>"

Danach prüfen:

57. Häufige Ergebniskombinationen
Beobachtung Wahrscheinlicher Prüfbereich
Zugriff per IP funktioniert, per Name nicht DNS, Hosts-Datei oder Suchdomäne
DNS liefert unterschiedliche IPs Split-DNS, Load Balancing oder Cache
Ping scheitert, TCP funktioniert ICMP wahrscheinlich blockiert
Ping funktioniert, TCP scheitert Port, Listener oder Firewall
TCP erfolgreich, TLS scheitert Zertifikat, TLS-Version, Cipher oder SNI
TLS erfolgreich, HTTP 500 Anwendung oder Backend
HTTP 401 Authentifizierung
HTTP 403 Autorisierung oder Sicherheitsrichtlinie
HTTP 502 oder 504 Proxy, Load Balancer oder Backend
localhost funktioniert, Remotezugriff nicht Listener-Bindung, Firewall oder Netzwerkpfad
localhost funktioniert nicht Dienst oder Anwendung
nur ein Benutzer betroffen Konto, Rolle, Berechtigung oder Profil
nur ein Client betroffen Clientkonfiguration, lokaler Dienst oder Sicherheitssoftware
nur ein VLAN betroffen VLAN, ACL, Routing, DHCP oder Gateway
alle Clients betroffen Server, Dienst oder gemeinsame Abhängigkeit
Dienststatus „Running“, aber Port fehlt Bindungs-, Konfigurations- oder Prozessproblem
Port vorhanden, Anwendung antwortet nicht Anwendung hängt oder Abhängigkeit fehlt
Neustart behebt Fehler vorübergehend Cache, Speicherleck, Prozesszustand oder Verbindung
Datenträger frei, Schreiben scheitert Inodes, Quota, Berechtigung oder Read-only-Mount
58. Häufige Fehlermeldungen bei Netzwerkverbindungen
Meldung Mögliche Bedeutung
Connection refused Ziel erreichbar, aber kein Listener oder aktive Ablehnung
Connection timed out Paketverlust, Filterung, Routing oder nicht antwortendes Ziel
No route to host Route, Gateway, Interface oder Netz nicht erreichbar
Network is unreachable keine geeignete Route oder Schnittstelle
Name or service not known Namensauflösung fehlgeschlagen
Temporary failure in name resolution DNS-Server oder Resolver vorübergehend nicht verfügbar
Hostname mismatch Zertifikat passt nicht zum aufgerufenen Hostnamen
Certificate expired Zertifikat ist abgelaufen
Permission denied Dateirechte, ACL, Rolle oder Sicherheitsrichtlinie
Address already in use Port oder Socket bereits gebunden
No space left on device Speicherplatz oder Inodes erschöpft
Too many open files Datei- oder Prozesslimit erreicht
59. Was vor einem Neustart gesichert werden sollte
Priorität Information
1 Fehlermeldung und Screenshot
2 Uhrzeit und Zeitzone
3 laufende Prozesse
4 Dienstzustand
5 aktive Netzwerkverbindungen
6 Listener
7 IP-Konfiguration und Routing
8 ARP-, Neighbor- und DNS-Cache
9 angemeldete Benutzer
10 CPU-, RAM- und Datenträgerzustand
11 aktuelle Protokolle
12 letzte Änderungen
13 Konfiguration und Prüfsummen
60. Was nicht unüberlegt ausgeführt werden sollte
Maßnahme Grund
Computer neu starten flüchtige Informationen gehen verloren
Dienst sofort neu starten ursprünglicher Prozesszustand geht verloren
Prozess beenden Verbindungen, Speicher und offene Dateien verschwinden
DNS-Cache leeren diagnostisch relevante Cacheeinträge gehen verloren
ARP-Tabelle leeren Zuordnungen zwischen IP und MAC gehen verloren
Protokolle löschen Belege gehen verloren
Firewall vollständig deaktivieren Sicherheitsrisiko und unklarer Test
Update installieren Ausgangszustand wird verändert
Konfiguration zurücksetzen Fehlerursache ist schwerer nachvollziehbar
Snapshot unkontrolliert zurückspielen Daten- und Konsistenzrisiko
mehrere Änderungen gleichzeitig Wirkung kann nicht zugeordnet werden
61. Minimaler Erstsnapshot – Windows
Aufgabe Befehl
Zeit [RO] Get-Date -Format o
Betriebssystem [RO] Get-CimInstance Win32_OperatingSystem
letzter Start [RO] Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime
Benutzer [RO][SENSITIV] whoami /all
Prozesse [RO][SENSITIV] Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId,Name,CommandLine
Dienste [RO] Get-Service
IP-Konfiguration [RO] ipconfig /all
Routing [RO] route print
ARP [RO] arp -a
DNS-Cache [RO][SENSITIV] ipconfig /displaydns
TCP-Verbindungen [RO][PRIV] netstat -ano
Volumes [RO] Get-Volume
Fehlerprotokoll [RO] Get-WinEvent -FilterHashtable @{LogName="System"; Level=1,2; StartTime=(Get-Date).AddHours(-1)}
62. Minimaler Erstsnapshot – Linux
Aufgabe Befehl
Zeit [RO] date --iso-8601=seconds
Betriebssystem [RO] cat /etc/os-release
Kernel [RO] uname -a
Betriebsdauer [RO] uptime
Benutzer [RO] who -a
Prozesse [RO][SENSITIV] ps auxww
Dienste [RO] systemctl --failed
IP-Konfiguration [RO] ip -details address show
Routing [RO] ip route show table all
Neighbor [RO] ip neigh show
DNS [RO] resolvectl status
Sockets [RO][PRIV] ss -tulpn
Speicher [RO] free -h
Dateisysteme [RO] df -hT
Journal [RO] journalctl -b -p warning --no-pager
Kernelmeldungen [RO][PRIV] dmesg --ctime
63. Minimaler Erstsnapshot – macOS
Aufgabe Befehl
Zeit [RO] date "+%Y-%m-%dT%H:%M:%S%z"
Betriebssystem [RO] sw_vers
Kernel [RO] uname -a
Betriebsdauer [RO] uptime
Benutzer [RO] who
Prozesse [RO][SENSITIV] ps auxww
Dienste [RO] launchctl list
IP-Konfiguration [RO] ifconfig -a
Routing [RO] netstat -rn
ARP [RO] arp -an
DNS [RO][SENSITIV] scutil --dns
TCP-Verbindungen [RO] netstat -anv -p tcp
Speicher [RO] vm_stat
Dateisysteme [RO] df -h
Protokollfehler [RO][SENSITIV] log show --last 1h --predicate 'messageType == error OR messageType == fault' --style compact
64. Abschlussprüfung nach einer Lösung
Ebene Windows Linux macOS
Zeitpunkt Get-Date -Format o date --iso-8601=seconds date "+%Y-%m-%dT%H:%M:%S%z"
Dienststatus Get-Service -Name <Dienstname> systemctl status <Dienstname>.service launchctl print system/<Dienstlabel>
Listener Get-NetTCPConnection -State Listen -LocalPort <Port> ss -lntp | grep ":<Port>" lsof -nP -iTCP:<Port> -sTCP:LISTEN
TCP-Test Test-NetConnection <Servername> -Port <Port> nc -vz -w 3 <Servername> <Port> nc -vz -w 3 <Servername> <Port>
HTTP-Test curl.exe https://<Servername>/ curl https://<Servername>/ curl https://<Servername>/
neue Fehler Get-WinEvent journalctl log show
Benutzerfunktion ursprünglichen Ablauf wiederholen ursprünglichen Ablauf wiederholen ursprünglichen Ablauf wiederholen
Sicherheit unerlaubten Zugriff negativ testen unerlaubten Zugriff negativ testen unerlaubten Zugriff negativ testen
Monitoring zentrale Überwachung prüfen zentrale Überwachung prüfen zentrale Überwachung prüfen
65. Wichtigste Regeln

Ergebnis dieser Seite

Diese Seite bildet die Schnellreferenz für Kapitel 1. Sie enthält die wichtigsten Befehle für:

Damit ist Kapitel 1 – Grundlagen der systematischen Fehleranalyse abgeschlossen.

Offizielle Hersteller-, Standard- und Projektdokumentation

2. Grundwerkzeuge und Befehle

2. Grundwerkzeuge und Befehle

2.0 Werkzeugwahl, Kennzeichnungen und sichere Anwendung

Ziel dieser Seite

Diese Seite erklärt, wie für eine konkrete Diagnosefrage das passende Werkzeug ausgewählt wird. Sie legt außerdem die Kennzeichnungen fest, die in diesem Kapitel vor den Befehlen verwendet werden.

Die wichtigste Grundregel lautet:

Erst die Diagnosefrage formulieren, dann das Werkzeug auswählen und erst danach den Befehl ausführen.

Ein Werkzeug ist ein Messinstrument. Es ersetzt weder eine Hypothese noch die Bewertung des Ergebnisses.

1. Grundhaltung bei der Werkzeugwahl

Administratoren sollten nicht möglichst viele Befehle ausführen, sondern mit möglichst wenigen, gezielten Prüfungen die Fehlerdomäne eingrenzen.

Vor jedem Befehl werden deshalb fünf Fragen beantwortet:

  1. Was möchte ich mit diesem Befehl feststellen?
  2. Welches Ergebnis erwarte ich bei einem funktionierenden System?
  3. Welches Ergebnis würde meine Hypothese widerlegen?
  4. Kann der Befehl den Zustand des Systems verändern?
  5. Welche Daten muss ich zusammen mit dem Ergebnis dokumentieren?

Ein Befehl ohne konkrete Diagnosefrage erzeugt häufig nur zusätzliche Informationen, aber noch keine Erkenntnis.

Beispiel

Ungeeignete Fragestellung:

Ich führe erst einmal alle Netzwerkbefehle aus.

Geeignete Fragestellung:

Ich möchte feststellen, über welches Interface und welches Gateway der Client das Ziel 192.0.2.25 erreichen würde.

Dazu wird zunächst die Routingentscheidung geprüft. Ein Paketmitschnitt oder ein Portscan wäre zu diesem Zeitpunkt normalerweise noch nicht erforderlich.

2. Bedeutung der Kennzeichnungen

Die folgenden Kennzeichnungen stehen in diesem Buch vor Befehlen. Sie gehören nicht zum Befehl und dürfen nicht mit eingegeben werden.

Kennzeichnung Bedeutung Typische Auswirkung
[RO] Read-only beziehungsweise nur lesende Abfrage Liest Status oder Konfiguration aus, ohne sie absichtlich zu verändern
[TEST] Aktiver Diagnosetest Sendet kontrollierte Anfragen oder Testpakete
[PRIV] Erhöhte Rechte erforderlich Benötigt Administrator-, Root- oder vergleichbare Rechte
[FILE] Erzeugt oder exportiert eine Datei Benötigt einen geeigneten und geschützten Ablageort
[SENS] Möglicherweise sensible Ausgabe Kann interne Adressen, Namen, Benutzer-, Zertifikats- oder Nutzdaten enthalten
[LOAD] Erzeugt relevante Last oder Datenverkehr Kann Bandbreite, CPU, Speicher oder einen Zielservice belasten
[CHANGE] Verändert Zustand oder Konfiguration Erfordert Prüfung, Dokumentation und normalerweise einen Rückfallplan
[DISRUPT] Möglicherweise dienstunterbrechend Darf nur mit geklärter Auswirkung und entsprechender Freigabe eingesetzt werden

Kennzeichnungen können kombiniert werden.

Beispiele:

[RO] ip address
2. Grundwerkzeuge und Befehle

2.1 Windows-Netzwerkbefehle

Ziel dieser Seite

Diese Seite enthält die wichtigsten klassischen Windows-Befehle für die praktische Netzwerkdiagnose. Sie behandelt vor allem Werkzeuge, die über die Eingabeaufforderung cmd.exe oder aus PowerShell heraus gestartet werden können.

Die objektorientierten PowerShell-Cmdlets wie Get-NetIPConfiguration, Get-NetRoute, Resolve-DnsName und Test-NetConnection folgen auf der nächsten Seite.

1. Wichtige Hinweise zur Verwendung

Die Kennzeichnungen wie [RO], [TEST] und [CHANGE] gehören nicht zum Befehl und dürfen nicht mit eingegeben werden.

Die Beispiele verwenden reservierte Dokumentationsadressen und -namen:

Platzhalter Bedeutung
192.0.2.25 Beispielhafte IPv4-Zieladresse
192.0.2.53 Beispielhafter DNS-Server
server.example.test Beispielhafter vollständiger DNS-Name
example.test Beispielhafte DNS-Domäne
<Ziel> Durch echten Hostnamen oder echte IP-Adresse ersetzen
<Adaptername> Durch den tatsächlichen Namen des Netzwerkadapters ersetzen
<PID> Durch eine ermittelte Prozess-ID ersetzen
<Ausgabepfad> Durch einen vorhandenen und geeigneten Speicherort ersetzen

Vor einer Veränderung sollten zuerst die [RO]-Befehle ausgeführt und deren Ergebnisse gesichert werden.

2. Schnellübersicht

Aufgabe Kennzeichnung Befehl
Computername anzeigen [RO] hostname
MAC-Adressen anzeigen [RO] getmac /v
Grundlegende IP-Konfiguration [RO] ipconfig
Vollständige IP-Konfiguration [RO][SENS] ipconfig /all
DNS-Clientcache anzeigen [RO][SENS] ipconfig /displaydns
DNS-Clientcache leeren [CHANGE] ipconfig /flushdns
DHCP-Lease freigeben [CHANGE][DISRUPT] ipconfig /release
DHCP-Lease erneuern [TEST][CHANGE] ipconfig /renew
IPv4-Erreichbarkeit testen [TEST] ping /4 <Ziel>
IPv6-Erreichbarkeit testen [TEST] ping /6 <Ziel>
Netzwerkpfad anzeigen [TEST] tracert /d <Ziel>
Pfad und Paketverlust untersuchen [TEST] pathping /n <Ziel>
Routingtabelle anzeigen [RO] route print
IPv4-ARP-Cache anzeigen [RO] arp -a
DNS-Abfrage ausführen [TEST] nslookup <Ziel>
Bestimmten DNS-Server abfragen [TEST] nslookup <Ziel> <DNS-Server>
TCP-Verbindungen und Listener anzeigen [RO][SENS] netstat -ano
Prozess zu einer PID ermitteln [RO] tasklist /FI "PID eq <PID>"
Status der Netzwerkinterfaces [RO] netsh interface show interface
IPv4-Nachbartabelle anzeigen [RO] netsh interface ipv4 show neighbors
IPv6-Nachbartabelle anzeigen [RO] netsh interface ipv6 show neighbors
WLAN-Verbindung anzeigen [RO][SENS] netsh wlan show interfaces
Sichtbare WLANs anzeigen [TEST][SENS] netsh wlan show networks mode=bssid
WLAN-Bericht erzeugen [FILE][SENS] netsh wlan show wlanreport
WinHTTP-Proxy anzeigen [RO][SENS] netsh winhttp show proxy
Firewallstatus anzeigen [RO] netsh advfirewall show allprofiles state

3. Empfohlene Reihenfolge für eine erste Windows-Netzwerkdiagnose

Schritt Diagnosefrage Befehl
1 Auf welchem Computer wird getestet? hostname
2 Welche Netzwerkadapter sind vorhanden und aktiv? netsh interface show interface
3 Welche IP-, Gateway-, DHCP- und DNS-Konfiguration liegt vor? ipconfig /all
4 Funktioniert der lokale TCP/IP-Stack? ping 127.0.0.1
5 Ist das lokale Standardgateway erreichbar? ping <Gateway-IP>
6 Ist eine entfernte IP-Adresse erreichbar? ping /4 <Ziel-IP>
7 Funktioniert die Namensauflösung? nslookup <Zielname>
8 Sind IP-Adresse und Name unterschiedlich betroffen? ping <Ziel-IP> und ping <Zielname>
9 Welchen Weg nimmt der Datenverkehr? tracert /d <Ziel>
10 Gibt es Hinweise auf Verlust oder starke Latenz? pathping /n <Ziel>
11 Welche Route wird wahrscheinlich verwendet? route print
12 Existiert eine lokale Nachbarzuordnung? arp -a
13 Lauscht lokal ein Prozess auf dem erwarteten Port? netstat -ano
14 Welcher Prozess gehört zur gefundenen PID? tasklist /FI "PID eq <PID>"
15 Sind Proxy oder Windows-Firewall relevant? netsh winhttp show proxy und netsh advfirewall show currentprofile

Diese Reihenfolge ist ein Ausgangspunkt. Sie wird an das konkrete Fehlerbild angepasst.

4. Computername und MAC-Adressen

Computername anzeigen

Kennzeichnung: [RO]

hostname

Der Befehl zeigt den Hostnamenanteil des vollständigen Computernamens an.

Das ist nützlich, um sicherzustellen, dass die Diagnose tatsächlich auf dem vorgesehenen System durchgeführt wird.

Computername über die Umgebungsvariable anzeigen

Kennzeichnung: [RO]

echo %COMPUTERNAME%

%COMPUTERNAME% zeigt üblicherweise denselben Computernamen in Großbuchstaben an. In Clusterumgebungen kann sich die Ausgabe von hostname jedoch durch die Variable _CLUSTER_NETWORK_NAME_ unterscheiden.

MAC-Adressen und zugehörige Adapter anzeigen

Kennzeichnung: [RO]

getmac /v

Ausführliche Ausgabe als Liste:

getmac /v /fo list

Ausgabe als CSV:

getmac /v /fo csv

Wichtige Felder:

Feld Bedeutung
Connection Name Name des Netzwerkadapters
Network Adapter Beschreibung des Netzwerkgeräts
Physical Address MAC-Adresse
Transport Name Windows-interne Transportzuordnung

Wichtig

Bei WLAN können private beziehungsweise zufällige MAC-Adressen verwendet werden. Die aktuell verwendete MAC-Adresse muss deshalb nicht dauerhaft mit der auf dem Gerät aufgedruckten Hardwareadresse übereinstimmen.

5. IP-Konfiguration mit ipconfig untersuchen

Grundlegende Konfiguration anzeigen

Kennzeichnung: [RO]

ipconfig

Der Befehl zeigt unter anderem:

Vollständige Konfiguration anzeigen

Kennzeichnung: [RO][SENS]

ipconfig /all

ipconfig /all ist einer der wichtigsten ersten Diagnosebefehle auf Windows-Systemen.

Die Ausgabe kann interne Adressen, DNS-Suffixe, DHCP-Server und andere Infrastrukturinformationen enthalten und sollte deshalb als sensibel behandelt werden.

Wichtige Felder in der Ausgabe

Feld Diagnosebedeutung
Host Name Name des lokalen Systems
Primary DNS Suffix Primäres DNS-Suffix des Computers
Node Type Verwendeter NetBIOS-Namensauflösungstyp
IP Routing Enabled Gibt an, ob IP-Weiterleitung aktiviert ist
Adapter Description Treiber- beziehungsweise Adapterbeschreibung
Physical Address MAC-Adresse des Adapters
DHCP Enabled Gibt an, ob IPv4 per DHCP konfiguriert wird
Autoconfiguration Enabled Zeigt, ob automatische Adressierung möglich ist
IPv4 Address Aktuelle IPv4-Adresse
Subnet Mask Zugehörige IPv4-Subnetzmaske
Lease Obtained Beginn des aktuellen DHCP-Leases
Lease Expires Ablaufzeit des aktuellen DHCP-Leases
Default Gateway Router für nicht lokal erreichbare Ziele
DHCP Server DHCP-Server, von dem die Konfiguration stammt
DNS Servers Eingetragene DNS-Server in ihrer Reihenfolge
Connection-specific DNS Suffix DNS-Suffix des jeweiligen Adapters
NetBIOS over Tcpip Status von NetBIOS über TCP/IP
Media State Verbindungszustand eines Adapters

Typische Auffälligkeiten

Beobachtung Mögliche Bedeutung Nächste Prüfung
Media disconnected Adapter besitzt derzeit keine aktive Verbindung Kabel, WLAN-Verbindung, Adapterstatus und Switchport
IPv4-Adresse aus 169.254.0.0/16 Windows verwendet wahrscheinlich APIPA, weil keine verwendbare DHCP-Konfiguration vorliegt DHCP-Server, VLAN, Relay, Firewall und Link prüfen
Kein Standardgateway Ziele außerhalb des lokalen Subnetzes sind normalerweise nicht über eine Default Route erreichbar DHCP-Optionen, statische Konfiguration und Routingtabelle
Unerwarteter DNS-Server DNS-Anfragen können an einen falschen Resolver gehen DHCP-Option 6, VPN, statische Konfiguration und Richtlinien
Mehrere Standardgateways Windows kann einen unerwarteten Ausgangspfad wählen Routingtabelle und Metriken prüfen
Altes Lease Nicht automatisch fehlerhaft, aber bei Netzänderungen relevant Lease-Zeiten und DHCP-Server vergleichen
Nur IPv6-Link-Local-Adresse Keine globale oder standortweite IPv6-Konfiguration erkennbar Router Advertisements, DHCPv6 und IPv6-Routing
Falsches DNS-Suffix Kurznamen können falsch oder gar nicht aufgelöst werden Adapter-, DHCP-, VPN- und Domänenkonfiguration

APIPA richtig bewerten

Eine Adresse aus 169.254.0.0/16 wird von Windows automatisch vergeben, wenn ein DHCP-konfigurierter Adapter keine verwendbare DHCP-Antwort erhält.

Damit ist unter Umständen Kommunikation mit anderen Systemen im selben lokalen Segment möglich, die ebenfalls eine passende Link-Local-Adresse besitzen. Normale geroutete Kommunikation in andere Subnetze ist damit jedoch nicht möglich.

Eine APIPA-Adresse beweist noch nicht, an welcher Stelle DHCP scheitert. Mögliche Ursachen sind unter anderem:

6. DNS-Clientcache mit ipconfig prüfen

DNS-Clientcache anzeigen

Kennzeichnung: [RO][SENS]

ipconfig /displaydns

Der Cache kann enthalten:

Die Ausgabe sollte möglichst vor dem Leeren des Caches gesichert werden.

DNS-Clientcache in eine Datei schreiben

Kennzeichnung: [RO][FILE][SENS]

ipconfig /displaydns > "<Ausgabepfad>\dns-cache.txt"

DNS-Clientcache leeren

Kennzeichnung: [CHANGE]

ipconfig /flushdns

Der Befehl entfernt dynamisch hinzugefügte positive und negative Einträge aus dem DNS-Clientcache.

Nicht sofort ausführen

Das Leeren des Caches kann:

Deshalb zuerst:

ipconfig /displaydns

Danach bei begründeter Hypothese:

ipconfig /flushdns

Anschließend denselben Namen erneut testen.

Dynamische DNS-Registrierung anstoßen

Kennzeichnung: [TEST][CHANGE]

ipconfig /registerdns

Der Befehl stößt die manuelle dynamische Registrierung der konfigurierten DNS-Namen und IP-Adressen an.

Er ist für Probleme mit dynamischen DNS-Updates gedacht und nicht als allgemeiner erster Reparaturbefehl.

Nach der Ausführung sollten zusätzlich geprüft werden:

7. DHCP-Lease erneuern

Aktuelle DHCP-Konfiguration eines Adapters freigeben

Kennzeichnung: [CHANGE][DISRUPT]

ipconfig /release "<Adaptername>"

Für alle DHCP-konfigurierten IPv4-Adapter:

ipconfig /release

Dadurch wird die aktuelle DHCP-Konfiguration verworfen. Die Netzwerkverbindung kann unterbrochen werden.

DHCP-Konfiguration erneuern

Kennzeichnung: [TEST][CHANGE]

ipconfig /renew "<Adaptername>"

Für alle DHCP-konfigurierten IPv4-Adapter:

ipconfig /renew

DHCPv6-Konfiguration freigeben und erneuern

Kennzeichnung: [CHANGE][DISRUPT]

ipconfig /release6 "<Adaptername>"

Kennzeichnung: [TEST][CHANGE]

ipconfig /renew6 "<Adaptername>"

Wichtige Sicherheitsregel

ipconfig /release darf nicht unüberlegt in einer entfernten Administrationssitzung ausgeführt werden. Die Verbindung zum System kann dadurch sofort abbrechen.

Vorher sichern

ipconfig /all

Nachher vergleichen

ipconfig /all

Zu vergleichen sind insbesondere:

Auswertung

Ergebnis Mögliche Schlussfolgerung
Lease wird erfolgreich erneuert DHCP-Kommunikation funktioniert grundsätzlich
APIPA-Adresse nach dem Versuch Keine verwendbare DHCP-Antwort erhalten
Alte Adresse bleibt bestehen Lease möglicherweise noch gültig oder Erneuerung nicht erfolgreich
Neuer falscher Adressbereich Falsches VLAN, falscher Scope oder nicht autorisierter DHCP-Server möglich
Gateway oder DNS fehlt DHCP-Antwort beziehungsweise DHCP-Optionen unvollständig oder falsch
Befehl betrifft falschen Adapter Adaptername, virtuelle Adapter und aktive Verbindung prüfen

8. Erreichbarkeit mit ping prüfen

ping sendet ICMP-Echoanforderungen und zeigt empfangene Echoantworten sowie die jeweilige Round-Trip-Zeit an.

Ein erfolgreicher Ping beweist nicht, dass ein bestimmter TCP- oder UDP-Dienst funktioniert.

Ein fehlgeschlagener Ping beweist nicht sicher, dass das Ziel ausgeschaltet ist. ICMP kann gefiltert, begrenzt oder deaktiviert sein.

IPv4-Ziel testen

Kennzeichnung: [TEST]

ping /4 192.0.2.25

IPv6-Ziel testen

Kennzeichnung: [TEST]

ping /6 server.example.test

Namen testen

Kennzeichnung: [TEST]

ping server.example.test

Die erste Ausgabezeile zeigt normalerweise, in welche IP-Adresse der Name aufgelöst wurde.

Mehrere Anfragen senden

Kennzeichnung: [TEST]

ping /n 10 192.0.2.25

Windows sendet standardmäßig vier Echoanforderungen. /n 10 erhöht die Anzahl auf zehn.

Zeitüberschreitung festlegen

Kennzeichnung: [TEST]

ping /n 10 /w 1000 192.0.2.25

/w 1000 wartet pro Anfrage maximal 1000 Millisekunden auf eine Antwort.

Dauerhaft testen

Kennzeichnung: [TEST]

ping /t 192.0.2.25

Steuerung:

Tastenkombination Wirkung
Strg + Unterbrechen Zwischenstatistik anzeigen und Test fortsetzen
Strg + C Test beenden und Abschlussstatistik anzeigen

Ein dauerhafter Ping sollte nicht unbeaufsichtigt laufen.

IPv4 oder IPv6 gezielt erzwingen

ping /4 server.example.test

ping /6 server.example.test

Damit lässt sich erkennen, ob nur einer der beiden Protokollpfade betroffen ist.

Paketgröße testen

Kennzeichnung: [TEST]

ping /4 /f /l 1472 192.0.2.25

Bedeutung:

Option Bedeutung
/4 IPv4 verwenden
/f „Do not Fragment“-Bit setzen
/l 1472 ICMP-Datenfeld mit 1472 Byte verwenden

1472 Byte plus 20 Byte IPv4-Header und 8 Byte ICMP-Header ergeben 1500 Byte. Das ist ein üblicher Startwert für Ethernet mit einer MTU von 1500, aber nicht für jeden Pfad passend.

Wenn eine Fragmentierungsmeldung erscheint, kann die Nutzlast schrittweise reduziert werden.

Beispiel:

ping /4 /f /l 1464 192.0.2.25

ping /4 /f /l 1400 192.0.2.25

Dieser Test kann Hinweise auf Probleme mit folgenden Komponenten geben:

Ping-Ausgaben interpretieren

Ausgabe Bedeutung
Reply from ... Eine ICMP-Echoantwort wurde empfangen
Request timed out Innerhalb der Wartezeit wurde keine passende Echoantwort empfangen
Destination host unreachable Das meldende System oder ein Router konnte das Ziel nicht erreichen
General failure Lokaler Versand ist fehlgeschlagen; lokale Konfiguration, Route, Interface oder Netzwerkstack prüfen
Ping request could not find host Der angegebene Name konnte nicht aufgelöst werden
Stark wechselnde Laufzeiten Mögliche Überlastung, WLAN-Störung, Warteschlangen oder wechselnde Pfade
Paketverlust Mögliche Filterung, Überlastung oder Verbindungsstörung; weitere Messungen erforderlich

Bei Destination host unreachable ist entscheidend, welche IP-Adresse die Meldung sendet:

TTL nicht als exakte Hopanzahl interpretieren

Der angezeigte TTL-Wert ist der verbleibende TTL-Wert der empfangenen Antwort. Da der ursprüngliche Startwert des Zielsystems normalerweise nicht sicher bekannt ist, kann daraus nicht zuverlässig die genaue Zahl der durchlaufenen Router berechnet werden.

9. Systematischer Ping-Test

Die folgende Reihenfolge grenzt den Fehler schrittweise ein.

1. Lokalen IPv4-Loopback testen

ping 127.0.0.1

Prüft grundlegende lokale IPv4-Verarbeitung. Der Test verlässt den Computer nicht.

2. Lokalen IPv6-Loopback testen

ping ::1

Prüft grundlegende lokale IPv6-Verarbeitung.

3. Eigene IP-Adresse testen

ping <Eigene-IP-Adresse>

Prüft die Bindung der Adresse an den lokalen Netzwerkstack. Der Test beweist noch keine funktionierende physische Verbindung.

4. Standardgateway testen

ping <Gateway-IP>

Prüft die ICMP-Kommunikation zum Gateway, sofern dieses ICMP beantwortet.

5. Entfernte IP-Adresse testen

ping <Entfernte-IP-Adresse>

Prüft den gerouteten IP-Pfad ohne Abhängigkeit von der DNS-Namensauflösung.

6. Zielname testen

ping server.example.test

Vergleich:

IP-Test Namenstest Wahrscheinlicher Bereich
Erfolgreich Erfolgreich Grundlegende IP-Kommunikation und Namensauflösung funktionieren
Erfolgreich Fehlgeschlagen Namensauflösung, Suffix, Cache oder hosts-Datei prüfen
Fehlgeschlagen Name wird aufgelöst Routing, Firewall, Zielsystem oder Rückweg prüfen
Beide fehlgeschlagen Keine eindeutige Aussage Lokale Konfiguration, Gateway, DNS und Pfad getrennt prüfen

10. Netzwerkpfad mit tracert untersuchen

tracert erhöht schrittweise den TTL-Wert und versucht dadurch, die Router auf dem Weg zum Ziel sichtbar zu machen.

Pfad zu einem Ziel anzeigen

Kennzeichnung: [TEST]

tracert server.example.test

Namensauflösung der Zwischenstationen deaktivieren

Kennzeichnung: [TEST]

tracert /d 192.0.2.25

/d verhindert Reverse-DNS-Abfragen für Zwischenrouter. Dadurch wird die Ausgabe häufig schneller und DNS-Verzögerungen beeinflussen die Messung weniger.

IPv4 erzwingen

tracert /4 server.example.test

IPv6 erzwingen

tracert /6 server.example.test

Maximale Hopanzahl begrenzen

tracert /d /h 15 192.0.2.25

Wartezeit pro Antwort verringern

tracert /d /w 1000 192.0.2.25

/w 1000 wartet bis zu 1000 Millisekunden auf die jeweilige ICMP-Antwort.

Ausgabe interpretieren

Beobachtung Mögliche Bedeutung
Ziel wird erreicht Ein ICMP-basierter Pfad konnte bis zum Ziel verfolgt werden
Einzelner Hop zeigt *, spätere Hops antworten Dieser Router antwortet möglicherweise nicht auf TTL-Überschreitungen; Weiterleitung funktioniert trotzdem
Ab einem Hop nur noch * Filterung, fehlende Rückantwort, Pfadunterbrechung oder nicht antwortende Router möglich
Erster Hop unerwartet Falsches Gateway, VPN, virtueller Adapter oder unerwartete Route möglich
Pfad unterscheidet sich zwischen Tests Dynamisches Routing, Load Balancing, VPN-Wechsel oder andere Pfadauswahl möglich
Hohe Laufzeit an einem Hop, spätere Hops wieder normal Der Router priorisiert seine eigenen ICMP-Antworten möglicherweise niedrig; kein sicherer Beweis für Weiterleitungsverzögerung
Hohe Laufzeit beginnt an einem Hop und bleibt danach erhöht Möglicher Engpass oder langsamer Abschnitt ab diesem Bereich

Wichtig

Drei Sternchen bedeuten nur, dass für diese Versuche keine erwartete ICMP-Antwort empfangen wurde. Sie beweisen nicht automatisch einen Paketverlust für normalen Anwendungsverkehr.

11. Paketverlust und Latenz mit pathping untersuchen

pathping kombiniert eine Pfadermittlung mit wiederholten ICMP-Messungen zu den Zwischenstationen.

Standardtest

Kennzeichnung: [TEST]

pathping 192.0.2.25

Ohne Namensauflösung

Kennzeichnung: [TEST]

pathping /n 192.0.2.25

Anzahl der Abfragen begrenzen

pathping /n /q 20 192.0.2.25

Zeitabstand zwischen aufeinanderfolgenden Pings festlegen

pathping /n /q 20 /p 500 192.0.2.25
Option Bedeutung
/n Keine Namensauflösung der Zwischenrouter
/q 20 20 Echoanforderungen pro Router
/p 500 500 Millisekunden zwischen aufeinanderfolgenden Pings
/w 1000 Bis zu 1000 Millisekunden auf eine Antwort warten
/4 Nur IPv4 verwenden
/6 Nur IPv6 verwenden

Wartezeit beachten

pathping benötigt deutlich länger als tracert, weil nach der Pfaderkennung über einen Zeitraum Messwerte gesammelt werden.

Verlust richtig interpretieren

Wenn ein Zwischenrouter bei an ihn gerichteten ICMP-Paketen Verlust zeigt, aber alle folgenden Hops und das Ziel keinen entsprechenden Verlust zeigen, ist die Weiterleitung wahrscheinlich nicht im gleichen Maß betroffen.

Mögliche Erklärung:

Wird ein Verlust ab einem bestimmten Link angezeigt und setzt sich bis zum Ziel fort, ist dieser Abschnitt wesentlich verdächtiger.

Pathping ist kein Beweis für Anwendungsleistung

Der Befehl prüft ICMP. Eine TCP-, UDP-, TLS- oder Anwendungsstörung muss mit dem tatsächlichen Protokoll weiter untersucht werden.

12. Routingtabelle mit route anzeigen

Gesamte Routingtabelle anzeigen

Kennzeichnung: [RO][SENS]

route print

Die Ausgabe enthält:

Routen für einen bestimmten Bereich filtern

Kennzeichnung: [RO]

route print 192.0.2.*

Wichtige Bestandteile

Spalte Bedeutung
Network Destination Zielnetz oder Zielhost
Netmask Netzmaske der Route
Gateway Nächster Router beziehungsweise Next Hop
Interface Lokale Ausgangsadresse
Metric Kostenwert der Route
On-link Ziel ist über das angegebene Interface direkt erreichbar

Default Route erkennen

Network Destination: 0.0.0.0
Netmask:              0.0.0.0

Diese Route wird verwendet, wenn keine spezifischere passende IPv4-Route vorhanden ist.

Routenauswahl vereinfacht

Windows berücksichtigt grundsätzlich:

  1. passende Zielpräfixe;
  2. die spezifischste passende Route;
  3. bei gleich spezifischen Routen die Metriken;
  4. die zugehörige Interfacemetrik und Routenkonfiguration.

Eine Route zu 192.0.2.0/24 ist beispielsweise spezifischer als die Default Route 0.0.0.0/0.

Typische Auffälligkeiten

Beobachtung Mögliche Ursache
Keine Default Route Kein Gateway konfiguriert oder DHCP-Konfiguration unvollständig
Mehrere Default Routes Mehrere Adapter, VPN, virtuelle Netzwerke oder fehlerhafte Konfiguration
Unerwartet niedrige Metrik Datenverkehr verwendet möglicherweise den falschen Adapter
Zielroute zeigt auf VPN Split-Tunnel- oder VPN-Routing relevant
Spezifische Route zeigt auf falsches Gateway Statische Route oder Software hat die Pfadauswahl verändert
Route ist On-link, Ziel liegt aber nicht im lokalen Segment Falsche Subnetzmaske oder Präfixlänge möglich
Persistente Route unerwartet vorhanden Frühere manuelle Konfiguration oder Softwareinstallation prüfen

Verändernde route-Befehle

Folgende Befehle verändern die Routingtabelle und sind keine reinen Diagnosebefehle:

route add
route change
route delete
route /f

route /f entfernt einen großen Teil der Routingeinträge und kann Netzwerk- sowie Remotesitzungen unterbrechen. Der Befehl darf nicht als allgemeiner Reparaturversuch verwendet werden.

13. ARP-Cache und IPv4-Nachbartabelle prüfen

ARP ordnet IPv4-Adressen im lokalen Segment den zugehörigen MAC-Adressen zu.

ARP-Cache aller Interfaces anzeigen

Kennzeichnung: [RO][SENS]

arp -a

Ein bestimmtes Ziel anzeigen

arp -a 192.0.2.25

Tabelle eines bestimmten Interfaces anzeigen

arp -a -N <Lokale-Interface-IP>

Ausgabe interpretieren

Typ Bedeutung
dynamic Zuordnung wurde dynamisch per ARP gelernt
static Zuordnung wurde statisch eingetragen oder vom System vorgegeben
Kein Eintrag Ziel wurde noch nicht lokal aufgelöst, liegt nicht im lokalen Segment oder ARP-Auflösung ist fehlgeschlagen

Gezielte Prüfung

Zuerst das lokale Ziel ansprechen:

ping 192.0.2.25

Danach ARP-Tabelle prüfen:

arp -a 192.0.2.25

Wenn das Ziel im selben IPv4-Subnetz liegt, aber trotz eines Kommunikationsversuchs keine passende MAC-Adresse gelernt wird, sollten unter anderem geprüft werden:

ARP-Eintrag löschen

Kennzeichnung: [PRIV][CHANGE]

arp -d 192.0.2.25

Der Eintrag sollte erst gelöscht werden, nachdem sein vorheriger Zustand dokumentiert wurde.

Das Löschen erzwingt bei der nächsten Kommunikation eine neue ARP-Auflösung. Es beweist jedoch nicht, warum ein vorheriger Eintrag falsch oder veraltet war.

IPv6 beachten

arp gilt für IPv4. IPv6 verwendet Neighbor Discovery.

IPv6-Nachbarn anzeigen:

netsh interface ipv6 show neighbors

14. DNS mit nslookup prüfen

nslookup kann DNS-Server direkt abfragen und unterstützt einen nicht interaktiven sowie einen interaktiven Modus.

Einzelnen Namen mit dem Standard-DNS-Server abfragen

Kennzeichnung: [TEST][SENS]

nslookup server.example.test

Bestimmten DNS-Server abfragen

nslookup server.example.test 192.0.2.53

So können Antworten unterschiedlicher DNS-Server miteinander verglichen werden.

IPv4-A-Record abfragen

nslookup -type=A server.example.test 192.0.2.53

IPv6-AAAA-Record abfragen

nslookup -type=AAAA server.example.test 192.0.2.53

Mailserver abfragen

nslookup -type=MX example.test 192.0.2.53

Nameserver einer Zone abfragen

nslookup -type=NS example.test 192.0.2.53

TXT-Record abfragen

nslookup -type=TXT example.test 192.0.2.53

SRV-Record abfragen

nslookup -type=SRV _ldap._tcp.dc._msdcs.example.test 192.0.2.53

Reverse Lookup ausführen

nslookup 192.0.2.25 192.0.2.53

Dabei wird nach einem PTR-Record gesucht.

Interaktiven Modus starten

nslookup

Beispiel innerhalb des interaktiven Modus:

server 192.0.2.53
set type=AAAA
server.example.test
exit

Ausgabe interpretieren

Ausgabe Bedeutung
Server Verwendeter DNS-Server
Address Adresse des verwendeten DNS-Servers
Name Zurückgegebener kanonischer Name
Addresses Zurückgegebene IP-Adressen
Aliases Gefundene Aliasnamen
Non-authoritative answer Antwort stammt nicht direkt vom autoritativen Server
NXDOMAIN beziehungsweise „Non-existent domain“ Angefragter Name existiert laut Antwort nicht
Request timed out DNS-Server antwortete innerhalb des Timeouts nicht
Server failed DNS-Server meldet einen Verarbeitungsfehler
Refused DNS-Server lehnt die Anfrage ab

Wichtige Einschränkung

Eine erfolgreiche nslookup-Abfrage beweist nicht, dass eine Anwendung denselben Namen auf dieselbe Weise auflöst.

Zusätzlich relevant sein können:

Die Anwendung sollte deshalb anschließend ebenfalls direkt getestet werden.

15. NetBIOS-Namensauflösung mit nbtstat prüfen

nbtstat ist hauptsächlich für ältere beziehungsweise weiterhin verwendete NetBIOS-over-TCP/IP-Umgebungen relevant.

Lokale NetBIOS-Namenstabelle anzeigen

Kennzeichnung: [RO][SENS]

nbtstat /n

NetBIOS-Namenscache anzeigen

nbtstat /c

Remote-Tabelle über den NetBIOS-Namen abfragen

Kennzeichnung: [TEST][SENS]

nbtstat /a <Remote-NetBIOS-Name>

Remote-Tabelle über die IPv4-Adresse abfragen

nbtstat /A 192.0.2.25

Groß- und Kleinschreibung der Optionen ist hier wichtig:

Option Abfrage
/a Remotecomputer über NetBIOS-Namen
/A Remotecomputer über IPv4-Adresse

nbtstat sollte nur verwendet werden, wenn NetBIOS, WINS, ältere SMB-Namensauflösung oder eine entsprechende Legacy-Anwendung tatsächlich relevant ist.

16. Verbindungen, Listener und Ports mit netstat prüfen

Aktive TCP-Verbindungen anzeigen

Kennzeichnung: [RO][SENS]

netstat

Alle Verbindungen und Listener numerisch anzeigen

netstat -an

Verbindungen, Listener und Prozess-IDs anzeigen

netstat -ano

Bedeutung:

Option Funktion
-a Alle aktiven TCP-Verbindungen sowie TCP- und UDP-Listener anzeigen
-n Adressen und Ports numerisch anzeigen
-o Zugehörige Prozess-ID anzeigen
-b Beteiligte ausführbare Datei anzeigen
-e Ethernet-Statistiken anzeigen
-r Routingtabelle anzeigen
-s Protokollstatistiken anzeigen
-p Ausgabe auf ein Protokoll begrenzen

Ausführbare Programme anzeigen

Kennzeichnung: [RO][PRIV][SENS]

netstat -abno

-b kann langsam sein und benötigt ausreichende Rechte.

Nach einem Port filtern

Kennzeichnung: [RO][SENS]

netstat -ano | findstr ":443"

Achtung

Die Suche findet :443 sowohl bei lokalen als auch bei entfernten Adressen. Das Ergebnis muss anhand der Spalte Local Address beziehungsweise Foreign Address bewertet werden.

Nur Listener suchen

netstat -ano | findstr "LISTENING"

Auf einem deutschsprachigen Windows kann die Zustandsbezeichnung lokalisiert ausgegeben werden. Für zuverlässig automatisierbare Abfragen sind die PowerShell-Cmdlets der nächsten Seite besser geeignet.

Prozess zu einer PID suchen

tasklist /FI "PID eq 1234"

Wenn mehrere Windows-Dienste von einem gemeinsamen svchost.exe-Prozess gehostet werden:

tasklist /SVC /FI "PID eq 1234"

Protokollstatistiken anzeigen

netstat -s

Ethernet- und Protokollstatistiken anzeigen

netstat -e -s

Routingtabelle über netstat anzeigen

netstat -r

Das entspricht funktional weitgehend:

route print

Ausgabe regelmäßig aktualisieren

netstat -ano 5

Die Ausgabe wird alle fünf Sekunden aktualisiert. Mit Strg + C wird die Wiederholung beendet.

17. TCP-Zustände interpretieren

Zustand Bedeutung Diagnosehinweis
LISTENING Lokaler Prozess wartet auf Verbindungen Erwarteter Dienst besitzt grundsätzlich einen Listener
SYN_SENT Verbindungsanfrage wurde gesendet, passende Antwort steht aus Ziel, Firewall, Route oder Rückweg prüfen
SYN_RECEIVED Anfrage wurde empfangen und beantwortet, Abschluss des Handshakes steht aus Clientantwort oder Rückweg prüfen
ESTABLISHED TCP-Verbindung ist aufgebaut TCP funktioniert; Anwendung kann trotzdem fehlerhaft sein
FIN_WAIT_1 Lokale Seite hat das Beenden eingeleitet Kurzzeitig normal
FIN_WAIT_2 Bestätigung liegt vor, Beendigung der Gegenseite steht aus Viele dauerhafte Einträge können auf Anwendungsprobleme hindeuten
CLOSE_WAIT Gegenseite hat beendet; lokale Anwendung muss noch schließen Viele dauerhafte Einträge deuten häufig auf eine nicht sauber schließende Anwendung
LAST_ACK Lokale Seite wartet auf letzte Bestätigung Kurzzeitig normal
TIME_WAIT Verbindung wartet vor vollständiger Freigabe Viele Einträge können bei hoher Verbindungsrate normal sein
CLOSED Keine aktive TCP-Verbindung Normaler Endzustand

Ein einzelner Zustand ist selten ausreichend. Entscheidend sind:

18. Netzwerkinterfaces mit netsh prüfen

Status aller Netzwerkinterfaces anzeigen

Kennzeichnung: [RO]

netsh interface show interface

Typische Felder:

Feld Bedeutung
Admin State Administrativ aktiviert oder deaktiviert
State Aktueller Verbindungszustand
Type Art des Interfaces
Interface Name Windows-Name des Interfaces

IPv4-Interfaces anzeigen

netsh interface ipv4 show interfaces

IPv6-Interfaces anzeigen

netsh interface ipv6 show interfaces

IPv4-Konfiguration anzeigen

netsh interface ipv4 show config

IPv4-Adressen anzeigen

netsh interface ipv4 show addresses

IPv4-Routen anzeigen

netsh interface ipv4 show route

IPv4-Nachbarn anzeigen

netsh interface ipv4 show neighbors

IPv6-Adressen anzeigen

netsh interface ipv6 show addresses

IPv6-Routen anzeigen

netsh interface ipv6 show route

IPv6-Nachbarn anzeigen

netsh interface ipv6 show neighbors

Subinterfaces und MTU anzeigen

netsh interface ipv4 show subinterfaces

Diese Ausgabe ist unter anderem für folgende Probleme hilfreich:

19. WLAN mit netsh untersuchen

Aktuelle WLAN-Verbindung anzeigen

Kennzeichnung: [RO][SENS]

netsh wlan show interfaces

Mögliche Angaben:

WLAN-Treiber und Fähigkeiten anzeigen

netsh wlan show drivers

Damit lassen sich unter anderem prüfen:

Sichtbare WLANs anzeigen

Kennzeichnung: [TEST][SENS]

netsh wlan show networks

Sichtbare WLANs einschließlich BSSIDs anzeigen

netsh wlan show networks mode=bssid

Damit können unter anderem verglichen werden:

Gespeicherte WLAN-Profile anzeigen

Kennzeichnung: [RO][SENS]

netsh wlan show profiles

Bestimmtes WLAN-Profil anzeigen

netsh wlan show profile name="<Profilname>"

Die Liste gespeicherter SSIDs kann sensible Informationen über Standorte oder interne Netzwerknamen enthalten.

WLAN-Bericht erzeugen

Kennzeichnung: [FILE][SENS]

netsh wlan show wlanreport

Windows erzeugt einen HTML-Bericht und zeigt den Speicherort in der Ausgabe an.

Der Bericht kann Informationen enthalten über:

Der Bericht ist als sensible Diagnosedatei zu behandeln.

Typische WLAN-Auffälligkeiten

Beobachtung Mögliche Ursache
Interface State ist disconnected Keine WLAN-Verbindung aktiv
Unerwartete SSID Client ist mit dem falschen Netz verbunden
Unerwartete BSSID Verbindung mit anderem Access Point als erwartet
Niedrige Signalstärke Entfernung, Dämpfung, Antenne oder ungünstiger Standort
Niedrige Datenrate Schlechte Funkbedingungen, alter Standard oder Störung
Stark schwankendes Signal Bewegung, Interferenz, Roaming oder Treiberproblem
Überfüllter Kanal Co-Channel-Interference möglich
Profil vorhanden, Verbindung scheitert Authentifizierung, Zertifikat, Schlüssel oder Richtlinie prüfen
WLAN verbunden, aber APIPA WLAN-Assoziierung funktioniert, DHCP jedoch möglicherweise nicht

20. Proxykonfiguration prüfen

WinHTTP-Proxy anzeigen

Kennzeichnung: [RO][SENS]

netsh winhttp show proxy

Der Befehl zeigt die Proxykonfiguration für Anwendungen und Dienste an, die WinHTTP verwenden.

Mögliche Ausgaben:

Wichtige Einschränkung

Die WinHTTP-Konfiguration ist nicht automatisch identisch mit:

Ein funktionierender Browser beweist daher nicht, dass ein Windows-Dienst mit WinHTTP ebenfalls den richtigen Proxy verwendet.

Nicht ungeprüft ausführen

Folgende Befehle verändern die Proxykonfiguration:

netsh winhttp set proxy
netsh winhttp reset proxy
netsh winhttp import proxy

Sie benötigen eine begründete Änderung, eine dokumentierte Ausgangskonfiguration und einen Rückfallplan.

21. Windows-Firewallstatus prüfen

Status aller Firewallprofile anzeigen

Kennzeichnung: [RO]

netsh advfirewall show allprofiles state

Aktuelles Firewallprofil anzeigen

netsh advfirewall show currentprofile

Firewallrichtlinie des aktuellen Profils anzeigen

netsh advfirewall show currentprofile firewallpolicy

Protokollierung des aktuellen Profils anzeigen

netsh advfirewall show currentprofile logging

Zu prüfen sind:

Firewall nicht pauschal deaktivieren

Das vollständige Ausschalten der Firewall ist kein geeigneter erster Diagnosetest.

Besser:

  1. betroffenes Profil feststellen;
  2. Richtung bestimmen;
  3. Protokoll und Port bestimmen;
  4. lokale und entfernte Adresse bestimmen;
  5. passende Regeln und Logs prüfen;
  6. nur bei Freigabe eine eng begrenzte temporäre Testregel verwenden;
  7. Testregel anschließend wieder entfernen.

22. Diagnoseausgaben sichern

IP-Konfiguration exportieren

Kennzeichnung: [RO][FILE][SENS]

ipconfig /all > "<Ausgabepfad>\ipconfig-all.txt"

Routingtabelle exportieren

route print > "<Ausgabepfad>\route-print.txt"

ARP-Tabelle exportieren

arp -a > "<Ausgabepfad>\arp-cache.txt"

Verbindungen und Listener exportieren

netstat -ano > "<Ausgabepfad>\netstat-ano.txt"

Pfadtest exportieren

Kennzeichnung: [TEST][FILE][SENS]

tracert /d 192.0.2.25 > "<Ausgabepfad>\tracert.txt"

Standardausgabe und Fehlermeldungen gemeinsam sichern

pathping /n 192.0.2.25 > "<Ausgabepfad>\pathping.txt" 2>&1

An eine vorhandene Datei anhängen

ipconfig /all >> "<Ausgabepfad>\netzdiagnose.txt"

Bedeutung:

Operator Wirkung
> Datei neu erstellen beziehungsweise vorhandenen Inhalt überschreiben
>> Ausgabe an vorhandene Datei anhängen
2>&1 Fehlermeldungen zusammen mit der Standardausgabe umleiten

Vor dem Überschreiben einer vorhandenen Diagnosedatei muss geprüft werden, ob sie noch benötigt wird.

23. Kompakter Erfassungsblock

Die folgenden Befehle verändern keine Netzwerkkonfiguration. Die Ausgabe kann jedoch sensible Informationen enthalten.

hostname
getmac /v
ipconfig /all
route print
arp -a
netstat -ano
netsh interface show interface
netsh interface ipv4 show neighbors
netsh interface ipv6 show neighbors
netsh winhttp show proxy
netsh advfirewall show allprofiles state

Bei WLAN-Systemen zusätzlich:

netsh wlan show interfaces
netsh wlan show drivers
netsh wlan show profiles

Diese Sammlung ist nur eine Bestandsaufnahme. Sie ersetzt keine gezielte Bewertung der Ergebnisse.

24. Diagnosepfade für häufige Fehlerbilder

Fehlerbild: Keine Netzwerkverbindung

netsh interface show interface
ipconfig /all
route print
arp -a

Prüfen:

Fehlerbild: IP-Adresse vorhanden, aber kein Internet

ipconfig /all
ping <Gateway-IP>
ping /4 <Bekannte-Ziel-IP>
nslookup <Bekannter-Zielname>
tracert /d <Bekannte-Ziel-IP>
netsh winhttp show proxy
netsh advfirewall show currentprofile

Auswertung:

Ergebnis Verdächtiger Bereich
Gateway nicht erreichbar lokales Netz, VLAN, WLAN, Kabel oder Gateway
Gateway erreichbar, externe IP nicht Routing, Firewall, NAT oder Provider
Externe IP erreichbar, Name nicht DNS
Name und IP erreichbar, Anwendung nicht Port, TLS, Proxy oder Anwendung
Nur Dienst verwendet keinen Internetzugriff WinHTTP-Proxy, Dienstkonto oder Firewall

Fehlerbild: DNS funktioniert nicht

ipconfig /all
ipconfig /displaydns
nslookup server.example.test
nslookup server.example.test 192.0.2.53
ping /4 server.example.test
ping /6 server.example.test

Prüfen:

Fehlerbild: Ein lokaler Dienst ist nicht erreichbar

netstat -ano | findstr ":443"
tasklist /FI "PID eq <PID>"
netsh advfirewall show currentprofile

Prüfen:

Der Test eines entfernten TCP-Ports folgt auf der nächsten Seite mit Test-NetConnection.

Fehlerbild: Verbindung ist langsam oder instabil

ping /n 50 <Gateway-IP>
ping /n 50 <Ziel-IP>
tracert /d <Ziel-IP>
pathping /n <Ziel-IP>
netstat -e -s

Bei WLAN zusätzlich:

netsh wlan show interfaces
netsh wlan show networks mode=bssid
netsh wlan show wlanreport

Prüfen:

Fehlerbild: Nur IPv4 oder nur IPv6 funktioniert

ipconfig /all
ping /4 server.example.test
ping /6 server.example.test
tracert /4 server.example.test
tracert /6 server.example.test
route print
netsh interface ipv4 show route
netsh interface ipv6 show route
netsh interface ipv6 show neighbors

Prüfen:

25. Typische Fehlinterpretationen

Fehlinterpretation Richtige Bewertung
Ping funktioniert, also funktioniert das Netzwerk vollständig Ping prüft nur eine bestimmte ICMP-Kommunikation
Ping funktioniert nicht, also ist das Ziel ausgeschaltet ICMP kann gefiltert oder begrenzt sein
Sternchen bei tracert bedeuten Paketverlust Der Router hat möglicherweise nur keine ICMP-Antwort gesendet
Verlust an einem pathping-Zwischenhop beweist einen defekten Router Entscheidend ist, ob sich der Verlust bis zum Ziel fortsetzt
nslookup funktioniert, also funktioniert DNS für jede Anwendung Anwendungen können andere Resolverpfade, Caches oder Proxys verwenden
Eine ARP-Tabelle zeigt alle erreichbaren Systeme Sie enthält nur bereits gelernte oder statische lokale IPv4-Nachbarn
ESTABLISHED bedeutet, dass die Anwendung funktioniert Es beweist nur eine aufgebaute TCP-Verbindung
Viele TIME_WAIT-Einträge sind automatisch ein Fehler Sie können bei hoher normaler Verbindungsrate entstehen
169.254.x.x bedeutet defekte Netzwerkkarte Es weist normalerweise auf automatische Adressierung ohne verwendbare DHCP-Konfiguration hin
Mehrere Gateways sind automatisch redundant Sie können zu unerwarteter Routenauswahl führen
Firewall ausschalten ist der schnellste Test Das erzeugt ein Sicherheitsrisiko und liefert oft keine saubere Ursachenanalyse
DNS-Cache sofort leeren hilft immer Dabei kann der ursprüngliche Fehlerzustand verloren gehen

26. Befehle mit besonderer Vorsicht

Befehl Kennzeichnung Risiko
ipconfig /release [CHANGE][DISRUPT] Entfernt die aktuelle DHCP-Konfiguration
ipconfig /renew [TEST][CHANGE] Verändert die aktuelle DHCP-Konfiguration
ipconfig /flushdns [CHANGE] Entfernt den DNS-Clientcache und mögliche Beweise
ipconfig /registerdns [TEST][CHANGE] Stößt dynamische DNS-Registrierungen an
arp -d <IP> [PRIV][CHANGE] Entfernt eine Nachbarzuordnung
route add [PRIV][CHANGE] Fügt eine Route hinzu
route change [PRIV][CHANGE] Verändert eine Route
route delete [PRIV][CHANGE][DISRUPT] Entfernt eine Route
route /f [PRIV][CHANGE][DISRUPT] Entfernt einen großen Teil der Routingtabelle
netsh interface set ... [PRIV][CHANGE][DISRUPT] Verändert Interfacekonfiguration
netsh winhttp reset proxy [PRIV][CHANGE] Entfernt die WinHTTP-Proxykonfiguration
netsh advfirewall set ... [PRIV][CHANGE][DISRUPT] Verändert Firewallrichtlinien
netsh wlan disconnect [CHANGE][DISRUPT] Trennt eine WLAN-Verbindung
netsh wlan delete profile [PRIV][CHANGE] Löscht ein gespeichertes WLAN-Profil

Vor diesen Befehlen müssen Ausgangszustand, Auswirkung und Rückfallplan dokumentiert werden.

27. Grenzen der klassischen Windows-Befehle

Die klassischen Befehle sind schnell verfügbar und eignen sich gut für eine erste Diagnose. Sie haben jedoch einige Einschränkungen:

Für strukturierte und gezielte Windows-Diagnosen folgt deshalb:

2.2 PowerShell-Netzwerkdiagnose

Quellen und weiterführende Dokumentation

2. Grundwerkzeuge und Befehle

2.2 PowerShell-Netzwerkdiagnose

PowerShell stellt Netzwerkdaten als strukturierte Objekte bereit. Dadurch lassen sich Informationen gezielt filtern, sortieren, vergleichen und exportieren.

Die Cmdlets dieser Seite gehören zu Windows-Modulen wie NetAdapter, NetTCPIP, DnsClient und NetSecurity. Sie sind für die Netzwerkdiagnose unter Windows vorgesehen.

Kennzeichnungen

Kennzeichnung Bedeutung
[RO] Nur lesender Befehl; verändert keine Konfiguration
[TEST] Führt einen aktiven Netzwerk- oder Verbindungstest aus
[PRIV] Benötigt möglicherweise eine PowerShell mit Administratorrechten
[CHANGE] Verändert einen Zustand oder eine Konfiguration
[DISRUPT] Kann eine bestehende Verbindung oder einen Dienst unterbrechen
[FILE] Schreibt Informationen in eine Datei
[SENS] Ausgabe kann sensible System-, Netzwerk- oder Prozessdaten enthalten

Für die erste Diagnose möglichst mit [RO]-Befehlen beginnen. Veränderungen sollten erst erfolgen, wenn die Ursache ausreichend eingegrenzt und eine Rückfallmöglichkeit vorhanden ist.

1. PowerShell und benötigte Netzwerkmodule prüfen

Bevor ein Cmdlet verwendet wird, sollte geprüft werden, welche PowerShell-Version und welche Windows-Netzwerkmodule vorhanden sind.

Aufgabe PowerShell-Befehl
PowerShell-Version anzeigen [RO] $PSVersionTable
Betriebssysteminformationen anzeigen [RO] Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
Netzwerkmodule suchen [RO] Get-Module -ListAvailable NetAdapter, NetTCPIP, DnsClient, NetSecurity
Befehle eines Moduls auflisten [RO] Get-Command -Module NetTCPIP
Hilfe zu einem Cmdlet anzeigen [RO] Get-Help Test-NetConnection -Full
Verwendungsbeispiele anzeigen [RO] Get-Help Resolve-DnsName -Examples
Syntax eines Cmdlets anzeigen [RO] Get-Command Get-NetAdapter -Syntax

Typische Fehler

Meldung oder Beobachtung Mögliche Bedeutung
The term ... is not recognized Cmdlet oder Modul ist nicht vorhanden beziehungsweise nicht geladen
Access denied Administratorrechte oder zusätzliche Berechtigungen erforderlich
Keine Ausgabe Filter ist möglicherweise zu eng oder es existiert kein passendes Objekt
Einzelne Eigenschaften fehlen Unterschiedliche Windows-, PowerShell- oder Modulversion
2. Netzwerkadapter und Verbindungsstatus prüfen

Get-NetAdapter zeigt physische und virtuelle Netzwerkadapter einschließlich Status, Geschwindigkeit, MAC-Adresse und Schnittstellenindex.

Aufgabe PowerShell-Befehl
Alle sichtbaren Netzwerkadapter anzeigen [RO] Get-NetAdapter
Auch ausgeblendete Adapter anzeigen [RO] Get-NetAdapter -IncludeHidden
Wichtige Eigenschaften auswählen [RO] Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, LinkSpeed, MacAddress, ifIndex
Nur aktive Adapter anzeigen [RO] Get-NetAdapter | Where-Object Status -eq "Up"
Nicht aktive Adapter anzeigen [RO] Get-NetAdapter | Where-Object Status -ne "Up"
Adapter nach Status gruppieren [RO] Get-NetAdapter -IncludeHidden | Group-Object Status
Detailinformationen eines Adapters anzeigen [RO] Get-NetAdapter -Name "Ethernet" | Format-List *
Adapterstatistik anzeigen [RO] Get-NetAdapterStatistics
Fehler- und Verwerfungszähler anzeigen [RO] Get-NetAdapterStatistics | Select-Object Name, ReceivedPacketErrors, OutboundPacketErrors, ReceivedDiscardedPackets, OutboundDiscardedPackets
Treiberinformationen anzeigen [RO] Get-NetAdapter | Select-Object Name, DriverDescription, DriverVersion, DriverDate
Verbindungstyp und Netzwerkprofil anzeigen [RO] Get-NetConnectionProfile

Wichtige Eigenschaften

Eigenschaft Bedeutung
Status Betriebszustand des Adapters
LinkSpeed Ausgehandelte Verbindungsgeschwindigkeit
MacAddress Hardwareadresse des Netzwerkadapters
ifIndex Schnittstellenindex für weitere Cmdlets
ReceivedPacketErrors Fehlerhaft empfangene Pakete
OutboundPacketErrors Fehler beim Senden
ReceivedDiscardedPackets Empfangene, aber verworfene Pakete
OutboundDiscardedPackets Zu sendende, aber verworfene Pakete

Hinweise zur Auswertung

3. IP-Konfiguration vollständig erfassen

Get-NetIPConfiguration liefert eine zusammengefasste Ansicht der IP-Konfiguration. Für einzelne Eigenschaften stehen zusätzliche Cmdlets zur Verfügung.

Aufgabe PowerShell-Befehl
Aktive IP-Konfiguration anzeigen [RO] Get-NetIPConfiguration
Alle IP-Konfigurationen anzeigen [RO] Get-NetIPConfiguration -All
Ausführliche Ausgabe erzeugen [RO] Get-NetIPConfiguration -All | Format-List *
IPv4-Adressen anzeigen [RO] Get-NetIPAddress -AddressFamily IPv4
IPv6-Adressen anzeigen [RO] Get-NetIPAddress -AddressFamily IPv6
Verwendbare IPv4-Adressen anzeigen [RO] Get-NetIPAddress -AddressFamily IPv4 | Where-Object AddressState -eq "Preferred"
Loopback- und APIPA-Adressen ausblenden [RO] Get-NetIPAddress -AddressFamily IPv4 | Where-Object { $_.IPAddress -notlike "127.*" -and $_.IPAddress -notlike "169.254.*" }
IP-Schnittstellen anzeigen [RO] Get-NetIPInterface
IPv4-Schnittstellen nach Metrik sortieren [RO] Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric
Standardgateways anzeigen [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0"
DNS-Serveradressen anzeigen [RO] Get-DnsClientServerAddress
Nur IPv4-DNS-Server anzeigen [RO] Get-DnsClientServerAddress -AddressFamily IPv4
DHCP-Status anzeigen [RO] Get-NetIPInterface | Select-Object InterfaceAlias, AddressFamily, Dhcp, ConnectionState

Wichtige Prüfpunkte

Prüffeld Erwartung beziehungsweise Fehlerhinweis
IP-Adresse Muss zum vorgesehenen Netzwerk passen
Präfixlänge Muss zur Netzmaske des Netzwerks passen
Standardgateway Muss im Regelfall aus dem lokalen Netz erreichbar sein
DNS-Server Muss erreichbar und für die benötigten Zonen zuständig sein
DHCP Muss zur vorgesehenen statischen oder dynamischen Konfiguration passen
InterfaceMetric Niedrigerer Wert wird bei konkurrierenden Schnittstellen bevorzugt
169.254.x.x Kann auf eine fehlgeschlagene DHCP-Zuweisung hinweisen
Mehrere Standardrouten Können zu einem unerwarteten Verbindungsweg führen

Kompakte Bestandsaufnahme

Get-NetIPConfiguration -All |
    Select-Object InterfaceAlias,
                  InterfaceDescription,
                  NetProfile,
                  IPv4Address,
                  IPv6Address,
                  IPv4DefaultGateway,
                  DNSServer
4. Erreichbarkeit und TCP-Ports testen

Test-NetConnection kombiniert mehrere klassische Netzwerkprüfungen und liefert strukturierte Ergebnisse.

Aufgabe PowerShell-Befehl
Grundlegende Erreichbarkeit testen [TEST] Test-NetConnection 192.0.2.10
Detaillierte Ausgabe anzeigen [TEST] Test-NetConnection 192.0.2.10 -InformationLevel Detailed
Standardgateway testen [TEST] Test-NetConnection 192.0.2.1 -InformationLevel Detailed
Internet-IP testen [TEST] Test-NetConnection 1.1.1.1 -InformationLevel Detailed
HTTPS-Port testen [TEST] Test-NetConnection example.com -Port 443 -InformationLevel Detailed
SSH-Port testen [TEST] Test-NetConnection 192.0.2.10 -Port 22 -InformationLevel Detailed
RDP-Port testen [TEST] Test-NetConnection 192.0.2.10 -Port 3389 -InformationLevel Detailed
SMB-Port testen [TEST] Test-NetConnection 192.0.2.10 -Port 445 -InformationLevel Detailed
Routenverfolgung durchführen [TEST] Test-NetConnection example.com -TraceRoute
Nur boolesches Testergebnis ausgeben [TEST] Test-NetConnection example.com -Port 443 -InformationLevel Quiet

Die Adressen 192.0.2.0/24, 198.51.100.0/24 und 203.0.113.0/24 sind Dokumentationsnetze. Sie müssen in echten Prüfungen durch die tatsächlichen Zieladressen ersetzt werden.

Wichtige Ergebnisfelder

Eigenschaft Bedeutung
ComputerName Angegebenes Ziel
RemoteAddress Aufgelöste Zieladresse
NameResolutionResults Ergebnisse der Namensauflösung
SourceAddress Verwendete lokale Quelladresse
InterfaceAlias Verwendete Netzwerkschnittstelle
NetRoute Ausgewählte Route
PingSucceeded Ergebnis des ICMP-Tests
TcpTestSucceeded Ergebnis des TCP-Verbindungsversuchs
RemotePort Getesteter Zielport

Interpretation

Ergebnis Mögliche Bedeutung
PingSucceeded = False, TCP-Test erfolgreich ICMP wird möglicherweise blockiert; der getestete Dienst ist trotzdem erreichbar
Namensauflösung schlägt fehl, IP-Test funktioniert DNS-Problem wahrscheinlich
Gateway erreichbar, externes Ziel nicht erreichbar Routing, Firewall, Provider oder Upstream-System prüfen
IP-Adresse erreichbar, TCP-Port nicht erreichbar Dienst, Zielport oder Firewall prüfen
Falsches InterfaceAlias Routingmetrik, VPN oder mehrere aktive Adapter prüfen
Falsche SourceAddress IP-Konfiguration oder Routenauswahl prüfen
5. DNS-Auflösung gezielt untersuchen

Resolve-DnsName erlaubt präzisere DNS-Abfragen als ein einfacher Verbindungstest.

Aufgabe PowerShell-Befehl
Namen mit Standardeinstellungen auflösen [TEST] Resolve-DnsName example.com
Nur DNS verwenden [TEST] Resolve-DnsName example.com -DnsOnly
IPv4-Adresse abfragen [TEST] Resolve-DnsName example.com -Type A -DnsOnly
IPv6-Adresse abfragen [TEST] Resolve-DnsName example.com -Type AAAA -DnsOnly
Mailserver abfragen [TEST] Resolve-DnsName example.com -Type MX -DnsOnly
Nameserver abfragen [TEST] Resolve-DnsName example.com -Type NS -DnsOnly
TXT-Einträge abfragen [TEST] Resolve-DnsName example.com -Type TXT -DnsOnly
Reverse-DNS-Abfrage durchführen [TEST] Resolve-DnsName 192.0.2.10 -Type PTR -DnsOnly
Bestimmten DNS-Server verwenden [TEST] Resolve-DnsName example.com -Server 192.0.2.53 -DnsOnly
Nur lokalen DNS-Cache abfragen [RO] Resolve-DnsName example.com -CacheOnly
DNS-Cache anzeigen [RO] Get-DnsClientCache
Cache nach einem Namen durchsuchen [RO] Get-DnsClientCache | Where-Object Entry -like "*example.com*"
Konfigurierte DNS-Server anzeigen [RO] Get-DnsClientServerAddress
DNS-Clientkonfiguration anzeigen [RO] Get-DnsClient

DNS-Vergleichstest

Resolve-DnsName example.com -DnsOnly
Resolve-DnsName example.com -Server 192.0.2.53 -DnsOnly
Resolve-DnsName example.com -Server 1.1.1.1 -DnsOnly

Auswertung

Beobachtung Mögliche Ursache
Interner DNS-Server antwortet nicht DNS-Dienst, Firewall, Routing oder Erreichbarkeit prüfen
Externer DNS-Server funktioniert, interner nicht Problem wahrscheinlich beim internen Resolver
Interne Namen funktionieren extern nicht Normal, wenn die Zone nur intern vorhanden ist
Unterschiedliche Antworten verschiedener Resolver Split-DNS, Cache, Replikationsverzug oder unterschiedliche Zonen
NXDOMAIN Name existiert aus Sicht des verwendeten DNS-Servers nicht
SERVFAIL DNS-Server konnte die Anfrage nicht erfolgreich verarbeiten
Timeout DNS-Server nicht erreichbar, blockiert oder zu langsam
Auflösung funktioniert nur aus dem Cache Aktuelle DNS-Kommunikation möglicherweise gestört

Öffentliche DNS-Server dürfen nicht unüberlegt zum Test interner Namen verwendet werden. Interne Hostnamen, Domänennamen und Strukturen können sensible Informationen darstellen.

6. Routing und ausgewählten Netzwerkweg prüfen
Aufgabe PowerShell-Befehl
Gesamte Routingtabelle anzeigen [RO] Get-NetRoute
IPv4-Routen anzeigen [RO] Get-NetRoute -AddressFamily IPv4
IPv6-Routen anzeigen [RO] Get-NetRoute -AddressFamily IPv6
Standardroute anzeigen [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0"
Routen nach Metrik sortieren [RO] Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric
Route einer Schnittstelle anzeigen [RO] Get-NetRoute -InterfaceAlias "Ethernet"
Wahrscheinlich verwendete Route bestimmen [RO] Find-NetRoute -RemoteIPAddress 1.1.1.1
Schnittstellenmetriken anzeigen [RO] Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric
Routenverfolgung durchführen [TEST] Test-NetConnection example.com -TraceRoute

Wichtige Eigenschaften

Eigenschaft Bedeutung
DestinationPrefix Zielnetz der Route
NextHop Nächster Router beziehungsweise Gateway
InterfaceAlias Verwendete Netzwerkschnittstelle
RouteMetric Metrik der einzelnen Route
InterfaceMetric Metrik der Schnittstelle
Publish Gibt an, ob die Route veröffentlicht wird
Protocol Herkunft beziehungsweise Routingprotokoll der Route

Typische Fehlerbilder

7. ARP- und IPv6-Nachbartabelle prüfen

Get-NetNeighbor zeigt bekannte Nachbarn auf direkt angeschlossenen Netzen. Bei IPv4 entspricht dies funktional weitgehend der ARP-Tabelle; bei IPv6 werden Einträge des Neighbor Discovery Protocols angezeigt.

Aufgabe PowerShell-Befehl
Gesamte Nachbartabelle anzeigen [RO] Get-NetNeighbor
IPv4-Nachbarn anzeigen [RO] Get-NetNeighbor -AddressFamily IPv4
IPv6-Nachbarn anzeigen [RO] Get-NetNeighbor -AddressFamily IPv6
Nachbarn eines Adapters anzeigen [RO] Get-NetNeighbor -InterfaceAlias "Ethernet"
Einträge nach Zustand sortieren [RO] Get-NetNeighbor | Sort-Object State, InterfaceAlias
Bestimmte IP-Adresse suchen [RO] Get-NetNeighbor -IPAddress 192.0.2.10
Erreichbare Einträge anzeigen [RO] Get-NetNeighbor | Where-Object State -eq "Reachable"
Unvollständige Einträge anzeigen [RO] Get-NetNeighbor | Where-Object State -eq "Incomplete"

Wichtige Zustände

Zustand Bedeutung
Reachable Nachbar wurde kürzlich erfolgreich erreicht
Stale Eintrag ist vorhanden, wurde aber länger nicht bestätigt
Delay Erreichbarkeitsprüfung wird verzögert
Probe Aktive Erreichbarkeitsprüfung läuft
Incomplete Adressauflösung konnte noch nicht abgeschlossen werden
Permanent Statischer beziehungsweise dauerhafter Eintrag

Fehlerhinweise

8. TCP-Verbindungen, offene Ports und Prozesse untersuchen

Get-NetTCPConnection zeigt lokale TCP-Endpunkte und bestehende TCP-Verbindungen.

Aufgabe PowerShell-Befehl
Alle TCP-Verbindungen anzeigen [RO] Get-NetTCPConnection
Lauschende TCP-Ports anzeigen [RO] Get-NetTCPConnection -State Listen
Bestehende Verbindungen anzeigen [RO] Get-NetTCPConnection -State Established
Verbindungen zu einem Zielport suchen [RO] Get-NetTCPConnection -RemotePort 443
Lokalen Port untersuchen [RO] Get-NetTCPConnection -LocalPort 443
Nach Zustand gruppieren [RO] Get-NetTCPConnection | Group-Object State
Verbindungen sortiert anzeigen [RO] Get-NetTCPConnection | Sort-Object State, LocalPort
UDP-Endpunkte anzeigen [RO] Get-NetUDPEndpoint
Prozess über PID ermitteln [RO] Get-Process -Id 1234

Lauschende Ports mit Prozessnamen anzeigen

Get-NetTCPConnection -State Listen |
    Select-Object LocalAddress,
                  LocalPort,
                  OwningProcess,
                  @{
                      Name = "ProcessName"
                      Expression = {
                          (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName
                      }
                  } |
    Sort-Object LocalPort

Bestehende Verbindungen mit Prozessnamen anzeigen

Get-NetTCPConnection -State Established |
    Select-Object LocalAddress,
                  LocalPort,
                  RemoteAddress,
                  RemotePort,
                  OwningProcess,
                  @{
                      Name = "ProcessName"
                      Expression = {
                          (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName
                      }
                  }

Interpretation

Beobachtung Mögliche Bedeutung
Erwarteter Port fehlt im Zustand Listen Dienst läuft nicht, lauscht auf anderem Port oder konnte den Port nicht binden
Port lauscht nur auf 127.0.0.1 Dienst ist nur lokal erreichbar
Port lauscht auf 0.0.0.0 Dienst lauscht grundsätzlich auf allen IPv4-Schnittstellen
Port lauscht auf :: Dienst lauscht grundsätzlich auf IPv6 und möglicherweise abhängig von der Anwendung auch auf IPv4
Viele Verbindungen im Zustand SYN_SENT Ziel, Route, Dienst oder Firewall antwortet möglicherweise nicht
Viele Verbindungen im Zustand TIME_WAIT Kann bei vielen kurzlebigen TCP-Verbindungen normal sein
Unerwarteter Prozess lauscht auf einem Port Dienstzuordnung und Sicherheitslage prüfen

Eine Verbindung im Zustand Listen bestätigt nur, dass lokal ein Prozess auf dem Port wartet. Sie bestätigt nicht, dass der Port aus einem anderen Netz erreichbar ist.

9. Windows-Firewall diagnostizieren

Die Firewall sollte zunächst nur ausgelesen werden. Ein vollständiges Abschalten der Firewall ist kein geeigneter erster Diagnoseschritt.

Aufgabe PowerShell-Befehl
Firewallprofile anzeigen [RO] Get-NetFirewallProfile
Status der Profile kompakt anzeigen [RO] Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction
Aktivierte Regeln anzeigen [RO] Get-NetFirewallRule -Enabled True
Aktivierte Blockierungsregeln anzeigen [RO] Get-NetFirewallRule -Enabled True -Action Block
Eingehende Regeln anzeigen [RO] Get-NetFirewallRule -Direction Inbound
Regel anhand des Anzeigenamens suchen [RO] Get-NetFirewallRule -DisplayName "*Remote Desktop*"
Portfilter anzeigen [RO] Get-NetFirewallPortFilter
Regeln für lokalen Port 443 suchen [RO] Get-NetFirewallPortFilter | Where-Object LocalPort -eq 443 | Get-NetFirewallRule
Regeln für TCP-Port 445 suchen [RO] Get-NetFirewallPortFilter | Where-Object { $_.Protocol -eq "TCP" -and $_.LocalPort -eq 445 } | Get-NetFirewallRule
Adressfilter einer Regel anzeigen [RO] Get-NetFirewallRule -DisplayName "REGELNAME" | Get-NetFirewallAddressFilter
Portfilter einer Regel anzeigen [RO] Get-NetFirewallRule -DisplayName "REGELNAME" | Get-NetFirewallPortFilter
Anwendungsfilter einer Regel anzeigen [RO] Get-NetFirewallRule -DisplayName "REGELNAME" | Get-NetFirewallApplicationFilter

Warum zeigt Get-NetFirewallRule nicht alle Ports und Adressen direkt an?

Windows speichert Bedingungen wie Ports, Programme und Adressen in zugeordneten Filterobjekten. Deshalb werden für eine vollständige Analyse zusätzlich folgende Cmdlets verwendet:

Sinnvolle Prüfreihenfolge

  1. Aktives Netzwerkprofil mit Get-NetConnectionProfile feststellen.
  2. Firewallstatus des Profils mit Get-NetFirewallProfile prüfen.
  3. Prüfen, ob der Dienst lokal auf dem erwarteten Port lauscht.
  4. Passende eingehende oder ausgehende Regel suchen.
  5. Port-, Adress-, Programm- und Profilfilter der Regel prüfen.
  6. Verbindung von einem autorisierten Testsystem aus testen.

Die Firewall nicht pauschal deaktivieren. Dadurch verändert sich die Sicherheitslage und das Testergebnis bildet die ursprüngliche Konfiguration nicht mehr korrekt ab.

10. Diagnoseausgaben filtern, vergleichen und exportieren

PowerShell-Ausgaben bestehen aus Objekten. Die Filterung sollte deshalb möglichst vor der Formatierung erfolgen.

Aufgabe PowerShell-Befehl
Bestimmte Eigenschaften auswählen [RO] Get-NetAdapter | Select-Object Name, Status, LinkSpeed
Objekte filtern [RO] Get-NetAdapter | Where-Object Status -ne "Up"
Ergebnisse sortieren [RO] Get-NetRoute | Sort-Object RouteMetric
Ergebnisse gruppieren [RO] Get-NetTCPConnection | Group-Object State
Anzahl ermitteln [RO] (Get-NetTCPConnection -State Established).Count
Tabellenansicht erzeugen [RO] Get-NetAdapter | Format-Table -AutoSize
Detailansicht erzeugen [RO] Get-NetIPConfiguration | Format-List *
CSV-Datei exportieren [RO][FILE][SENS] Get-NetTCPConnection | Export-Csv -Path ".\tcp-connections.csv" -NoTypeInformation -Encoding UTF8
Objekte vollständig speichern [RO][FILE][SENS] Get-NetIPConfiguration -All | Export-Clixml -Path ".\ip-configuration.xml"
Textprotokoll erzeugen [RO][FILE][SENS] Get-NetIPConfiguration -All | Format-List * | Out-File ".\ip-configuration.txt" -Encoding utf8

Zwei Messzeitpunkte vergleichen

$Vorher = Get-NetTCPConnection
Start-Sleep -Seconds 10
$Nachher = Get-NetTCPConnection

Compare-Object $Vorher $Nachher -Property State, LocalAddress, LocalPort, RemoteAddress, RemotePort

Hinweise

11. Eingreifende Befehle nur nach der Diagnose verwenden

Die folgenden Befehle verändern einen Zustand und gehören nicht zur rein lesenden Bestandsaufnahme.

Maßnahme PowerShell-Befehl Auswirkung
DNS-Clientcache leeren [CHANGE][PRIV] Clear-DnsClientCache Lokal gespeicherte DNS-Antworten werden entfernt
Netzwerkadapter neu starten [CHANGE][PRIV][DISRUPT] Restart-NetAdapter -Name "Ethernet" Adapter wird deaktiviert und erneut aktiviert
DHCP-Lease erneuern [CHANGE][PRIV][DISRUPT] ipconfig /release; ipconfig /renew Vorhandene DHCP-Adresse wird zunächst freigegeben
DNS-Registrierung anfordern [CHANGE][PRIV] Register-DnsClient Dynamische DNS-Registrierung wird angestoßen

Vor einem Eingriff prüfen

Restart-NetAdapter kann eine Remoteverbindung sofort unterbrechen. Der Befehl darf auf entfernten Produktivsystemen nur mit abgesichertem Rückfallweg verwendet werden.

12. Praktische PowerShell-Diagnosereihenfolge

Schritt 1 – Adapter prüfen

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

Schritt 2 – IP-Konfiguration prüfen

Get-NetIPConfiguration -All

Schritt 3 – Standardroute und DNS-Server prüfen

Get-NetRoute -DestinationPrefix "0.0.0.0/0"
Get-DnsClientServerAddress

Schritt 4 – Lokales Standardgateway testen

Test-NetConnection 192.0.2.1 -InformationLevel Detailed

Schritt 5 – Externe IP-Adresse testen

Test-NetConnection 1.1.1.1 -InformationLevel Detailed

Schritt 6 – DNS-Auflösung testen

Resolve-DnsName example.com -DnsOnly

Schritt 7 – Zielport testen

Test-NetConnection example.com -Port 443 -InformationLevel Detailed

Schritt 8 – Route zum Ziel prüfen

Find-NetRoute -RemoteIPAddress 1.1.1.1
Test-NetConnection example.com -TraceRoute

Schritt 9 – Lokale Ports und Prozesse prüfen

Get-NetTCPConnection -State Listen |
    Sort-Object LocalPort

Schritt 10 – Firewallstatus prüfen

Get-NetFirewallProfile
Get-NetFirewallRule -Enabled True |
    Select-Object DisplayName, Direction, Action, Profile

Diagnoselogik

Ergebnis Nächster Schwerpunkt
Adapter nicht aktiv Kabel, WLAN, Adapter, Treiber oder Port prüfen
Keine passende IP-Adresse DHCP oder statische IP-Konfiguration prüfen
Gateway nicht erreichbar Lokales Netz, VLAN, WLAN, Switch oder Gateway prüfen
Externe IP erreichbar, DNS-Name nicht DNS-Konfiguration und Resolver prüfen
Ziel-IP erreichbar, Zielport nicht Dienst, Portbindung und Firewall prüfen
Falscher Adapter oder falsche Quelladresse Routing, Metrik, VPN und mehrere Adapter prüfen
Dienst lauscht lokal, ist extern aber nicht erreichbar Firewall, NAT, Routing und Dienstbindung prüfen

Kurzreferenz

Diagnoseziel Befehl
Adapterstatus [RO] Get-NetAdapter
Adapterstatistik [RO] Get-NetAdapterStatistics
IP-Gesamtübersicht [RO] Get-NetIPConfiguration -All
IP-Adressen [RO] Get-NetIPAddress
Schnittstellen und Metriken [RO] Get-NetIPInterface
Netzwerkprofil [RO] Get-NetConnectionProfile
DNS-Server [RO] Get-DnsClientServerAddress
DNS-Auflösung [TEST] Resolve-DnsName example.com -DnsOnly
DNS-Cache [RO] Get-DnsClientCache
Verbindungstest [TEST] Test-NetConnection example.com
TCP-Porttest [TEST] Test-NetConnection example.com -Port 443
Routenverfolgung [TEST] Test-NetConnection example.com -TraceRoute
Routingtabelle [RO] Get-NetRoute
Route zu einem Ziel [RO] Find-NetRoute -RemoteIPAddress 1.1.1.1
Nachbartabelle [RO] Get-NetNeighbor
TCP-Verbindungen [RO] Get-NetTCPConnection
UDP-Endpunkte [RO] Get-NetUDPEndpoint
Firewallprofile [RO] Get-NetFirewallProfile
Firewallregeln [RO] Get-NetFirewallRule

Merksatz

PowerShell-Netzwerkdiagnose bedeutet nicht, möglichst viele Befehle auszuführen. Entscheidend ist, die Ergebnisse als zusammenhängende Beweiskette auszuwerten: Adapter → IP-Konfiguration → Gateway → Route → DNS → Zielport → lokaler Dienst → Firewall.

Quellen

2. Grundwerkzeuge und Befehle

2.3 Linux-Netzwerkbefehle

Linux stellt für die Netzwerkdiagnose verschiedene Werkzeuge bereit. Welche Befehle verfügbar sind, hängt von Distribution, Installation und verwendeter Netzwerkverwaltung ab.

Die wichtigsten Werkzeuggruppen sind:

Kennzeichnungen

Kennzeichnung Bedeutung
[RO] Nur lesender Befehl; verändert keine Konfiguration
[TEST] Führt einen aktiven Netzwerk- oder Verbindungstest aus
[PRIV] Benötigt Root-Rechte beziehungsweise sudo
[CHANGE] Verändert einen Zustand oder eine Konfiguration
[DISRUPT] Kann eine Verbindung oder einen Dienst unterbrechen
[FILE] Schreibt Informationen in eine Datei
[SENS] Ausgabe kann sensible System-, Netzwerk- oder Prozessdaten enthalten

Vor Veränderungen sollten zunächst die lesenden [RO]-Befehle verwendet und deren Ergebnisse dokumentiert werden.

1. Linux-System und verfügbare Werkzeuge prüfen

Zunächst muss geklärt werden, welche Distribution, welcher Kernel und welche Netzwerkwerkzeuge vorhanden sind.

Aufgabe Linux-Befehl
Distribution anzeigen [RO] cat /etc/os-release
Kernelversion anzeigen [RO] uname -r
Architektur anzeigen [RO] uname -m
Hostname anzeigen [RO] hostnamectl
Aktuellen Benutzer anzeigen [RO] id
Prüfen, ob ein Befehl vorhanden ist [RO] command -v ip
Mehrere Werkzeuge prüfen [RO] command -v ip ss ping tracepath traceroute mtr dig resolvectl nmcli networkctl ethtool
Version von iproute2 anzeigen [RO] ip -Version
Hilfe zum ip-Befehl anzeigen [RO] ip help
Handbuchseite öffnen [RO] man ip
Handbuch für einen Teilbefehl öffnen [RO] man ip-route
Kurzhilfe eines Teilbefehls anzeigen [RO] ip route help

Typische Paketnamen

Werkzeug Häufiger Paketname
ip, ss iproute2
ping, tracepath iputils beziehungsweise iputils-ping und iputils-tracepath
dig, host dnsutils, bind-utils oder bind-tools
traceroute traceroute
mtr mtr
ethtool ethtool
lsof lsof
nc netcat-openbsd, nmap-ncat oder vergleichbares Paket

Paketnamen unterscheiden sich zwischen Debian, Ubuntu, Fedora, Red Hat Enterprise Linux, Rocky Linux, AlmaLinux, SUSE, Arch Linux und anderen Distributionen.

2. Netzwerkschnittstellen und Linkstatus prüfen

ip link zeigt Netzwerkschnittstellen unabhängig davon, ob bereits eine IP-Adresse konfiguriert wurde.

Aufgabe Linux-Befehl
Alle Schnittstellen anzeigen [RO] ip link show
Kompakte Übersicht anzeigen [RO] ip -brief link show
Details und Statistiken anzeigen [RO] ip -details -statistics link show
Einzelne Schnittstelle anzeigen [RO] ip link show dev enp1s0
Empfangs- und Sendestatistik anzeigen [RO] ip -statistics link show dev enp1s0
Betriebszustand über sysfs lesen [RO] cat /sys/class/net/enp1s0/operstate
Physische Trägererkennung lesen [RO] cat /sys/class/net/enp1s0/carrier
MTU anzeigen [RO] cat /sys/class/net/enp1s0/mtu
MAC-Adresse anzeigen [RO] cat /sys/class/net/enp1s0/address
Alle Schnittstellennamen auflisten [RO] ls -1 /sys/class/net

enp1s0 ist nur ein Beispiel. Der tatsächliche Name kann beispielsweise eth0, ens18, eno1, enp3s0, wlan0 oder wlp2s0 lauten.

Wichtige Angaben von ip link

Angabe Bedeutung
UP Schnittstelle wurde administrativ aktiviert
LOWER_UP Physische beziehungsweise untergeordnete Verbindung wurde erkannt
NO-CARRIER Kein physischer Link erkannt
state UP Schnittstelle ist betriebsbereit
state DOWN Schnittstelle ist nicht aktiv
mtu Maximum Transmission Unit
link/ether MAC-Adresse einer Ethernet-Schnittstelle
qlen Länge der Sendewarteschlange

Typische Fehlerbilder

Beobachtung Mögliche Bedeutung
state DOWN Schnittstelle wurde deaktiviert oder nicht aktiviert
UP, aber kein LOWER_UP Kein physischer Link, Kabel-, Port- oder WLAN-Problem
NO-CARRIER Kein Trägersignal erkannt
Viele errors Kabel, Port, Treiber, Hardware oder Aushandlung prüfen
Viele dropped Überlastung, Warteschlangen, Treiber oder Puffer prüfen
Unerwartete MTU Kann Fragmentierungs- oder Tunnelprobleme verursachen
Schnittstelle fehlt vollständig Treiber, Hardwareerkennung, virtuelle Maschine oder Gerätezuordnung prüfen
3. IP-Adressen und Adresszustände prüfen
Aufgabe Linux-Befehl
Alle Adressen anzeigen [RO] ip address show
Kompakte Adressübersicht [RO] ip -brief address show
IPv4-Adressen anzeigen [RO] ip -4 address show
IPv6-Adressen anzeigen [RO] ip -6 address show
Adressen einer Schnittstelle anzeigen [RO] ip address show dev enp1s0
Nur globale IPv4-Adressen anzeigen [RO] ip -4 address show scope global
Nur globale IPv6-Adressen anzeigen [RO] ip -6 address show scope global
Adressen ohne Loopback anzeigen [RO] ip -brief address show | grep -v '^lo'
Hostadressen kompakt anzeigen [RO] hostname -I

Wichtige Angaben

Angabe Bedeutung
inet IPv4-Adresse
inet6 IPv6-Adresse
/24, /64 Präfixlänge
scope host Nur lokal auf diesem System gültig
scope link Nur im direkt verbundenen Netz gültig
scope global Über das lokale System beziehungsweise Netz hinaus verwendbar
dynamic Adresse wurde dynamisch vergeben
secondary Zusätzliche Adresse auf derselben Schnittstelle
tentative IPv6 Duplicate Address Detection ist noch nicht abgeschlossen
deprecated Adresse soll nicht mehr für neue Verbindungen verwendet werden
valid_lft Verbleibende Gültigkeitsdauer
preferred_lft Verbleibende bevorzugte Nutzungsdauer

Prüfpunkte

Eine Adresse aus 169.254.0.0/16 kann darauf hinweisen, dass keine reguläre IPv4-Konfiguration beziehungsweise keine erfolgreiche DHCP-Zuweisung vorhanden ist.

4. Routingtabelle und verwendeten Netzwerkweg prüfen
Aufgabe Linux-Befehl
IPv4-Routingtabelle anzeigen [RO] ip route show
IPv6-Routingtabelle anzeigen [RO] ip -6 route show
Alle Routingtabellen anzeigen [RO] ip route show table all
Standardroute anzeigen [RO] ip route show default
Route zu einem Ziel bestimmen [RO] ip route get 1.1.1.1
Route mit gewünschter Quelladresse prüfen [RO] ip route get 1.1.1.1 from 192.0.2.10
Route über eine Schnittstelle suchen [RO] ip route show dev enp1s0
Policy-Routing-Regeln anzeigen [RO] ip rule show
IPv6-Policy-Regeln anzeigen [RO] ip -6 rule show
Routingtabellen-Namen anzeigen [RO] cat /etc/iproute2/rt_tables
Änderungen an Routen überwachen [RO] ip monitor route

Wichtige Angaben

Angabe Bedeutung
default Standardroute für nicht spezifischer bekannte Ziele
via Nächster Router beziehungsweise Gateway
dev Verwendete Netzwerkschnittstelle
src Bevorzugte lokale Quelladresse
metric Routenmetrik
proto dhcp Route wurde über DHCP bereitgestellt
proto kernel Route wurde automatisch durch den Kernel erzeugt
table Verwendete Routingtabelle
scope link Ziel befindet sich direkt am lokalen Link

Beispielausgabe

default via 192.0.2.1 dev enp1s0 proto dhcp src 192.0.2.10 metric 100
192.0.2.0/24 dev enp1s0 proto kernel scope link src 192.0.2.10 metric 100

Interpretation

Typische Fehlerbilder

5. ARP- und IPv6-Nachbartabelle prüfen

ip neigh zeigt IPv4-ARP- und IPv6-Nachbareinträge.

Aufgabe Linux-Befehl
Nachbartabelle anzeigen [RO] ip neighbour show
Kompakte Nachbartabelle anzeigen [RO] ip -brief neighbour show
IPv4-Nachbarn anzeigen [RO] ip -4 neighbour show
IPv6-Nachbarn anzeigen [RO] ip -6 neighbour show
Nachbarn einer Schnittstelle anzeigen [RO] ip neighbour show dev enp1s0
Bestimmte IP-Adresse suchen [RO] ip neighbour show 192.0.2.1
Fehlgeschlagene Einträge anzeigen [RO] ip neighbour show nud failed
Unvollständige Einträge anzeigen [RO] ip neighbour show nud incomplete
Änderungen überwachen [RO] ip monitor neighbour

Wichtige Zustände

Zustand Bedeutung
REACHABLE Nachbar wurde kürzlich erfolgreich erreicht
STALE Eintrag ist vorhanden, wurde aber länger nicht bestätigt
DELAY Prüfung der Erreichbarkeit wird verzögert
PROBE Aktive Erreichbarkeitsprüfung läuft
INCOMPLETE Adressauflösung ist noch nicht abgeschlossen
FAILED Adressauflösung beziehungsweise Erreichbarkeitsprüfung ist fehlgeschlagen
PERMANENT Dauerhaft konfigurierter Eintrag
NOARP Für diesen Eintrag wird keine normale Nachbarauflösung verwendet

Fehlerhinweise

6. Erreichbarkeit mit ping prüfen
Aufgabe Linux-Befehl
Vier ICMP-Anfragen senden [TEST] ping -c 4 192.0.2.1
Externe IP-Adresse testen [TEST] ping -c 4 1.1.1.1
DNS-Namen testen [TEST] ping -c 4 example.com
Nur IPv4 verwenden [TEST] ping -4 -c 4 example.com
Nur IPv6 verwenden [TEST] ping -6 -c 4 example.com
Bestimmte Schnittstelle verwenden [TEST] ping -I enp1s0 -c 4 192.0.2.1
Bestimmte Quelladresse verwenden [TEST] ping -I 192.0.2.10 -c 4 192.0.2.1
Timeout pro Antwort begrenzen [TEST] ping -c 4 -W 2 192.0.2.1
Gesamtlaufzeit begrenzen [TEST] ping -c 4 -w 10 192.0.2.1
Paketgröße prüfen [TEST] ping -c 4 -s 1400 192.0.2.1
Keine Fragmentierung erlauben [TEST] ping -c 4 -M do -s 1400 192.0.2.1

Wichtige Ergebnisse

Wert Bedeutung
time Antwortzeit beziehungsweise Round Trip Time
ttl Verbleibende IPv4 Time to Live
icmp_seq Nummer der ICMP-Anfrage
packet loss Anteil verlorener Anfragen
min/avg/max Minimale, durchschnittliche und maximale Laufzeit
mdev Streuung der Laufzeiten unter Linux

Interpretation

Ergebnis Mögliche Bedeutung
IP-Adresse erreichbar, DNS-Name nicht DNS-Problem wahrscheinlich
Gateway nicht erreichbar Lokales Netz, VLAN, WLAN, Switch oder Gateway prüfen
Ziel nicht erreichbar, Gateway erreichbar Routing, Firewall oder entferntes System prüfen
Einzelne Paketverluste Überlastung, Funkstörung, Linkfehler oder Rate Limiting möglich
Hohe Laufzeitschwankungen Überlastung, WLAN-Störung oder wechselnder Netzwerkweg
Destination Host Unreachable Lokales System oder Router kennt keinen funktionierenden Weg
Keine Antwort Ziel offline, ICMP blockiert oder Netzwerkweg gestört

Ein fehlgeschlagener Ping beweist nicht, dass ein Ziel vollständig unerreichbar ist. ICMP kann blockiert sein, während ein TCP-Dienst weiterhin funktioniert.

7. Netzwerkpfad mit tracepath, traceroute und mtr untersuchen
Aufgabe Linux-Befehl
Pfad ohne Root-Rechte prüfen [TEST] tracepath example.com
IPv4-Pfad prüfen [TEST] tracepath -4 example.com
IPv6-Pfad prüfen [TEST] tracepath -6 example.com
Klassische Routenverfolgung [TEST] traceroute example.com
Keine Namensauflösung durchführen [TEST] traceroute -n example.com
TCP-Traceroute zu Port 443 [TEST][PRIV] sudo traceroute -T -p 443 example.com
Laufende kombinierte Messung [TEST] mtr example.com
Bericht mit 20 Messzyklen [TEST] mtr --report --report-cycles 20 example.com
Bericht ohne DNS-Auflösung [TEST] mtr --report --numeric --report-cycles 20 example.com
TCP-MTR zu Port 443 [TEST][PRIV] sudo mtr --tcp --port 443 --report example.com

Unterschiede

Werkzeug Schwerpunkt
tracepath Einfacher Pfadtest und Erkennung der Path MTU; häufig ohne Root-Rechte nutzbar
traceroute Klassische Routenverfolgung mit verschiedenen Protokolloptionen
mtr Kombiniert laufende Ping- und Traceroute-Messungen

Wichtige Hinweise zur Auswertung

8. DNS-Konfiguration und Namensauflösung prüfen

Welche DNS-Werkzeuge funktionieren, hängt vom verwendeten Resolver und den installierten Paketen ab.

Aufgabe Linux-Befehl
Resolver-Konfiguration prüfen [RO] cat /etc/resolv.conf
systemd-resolved-Status anzeigen [RO] resolvectl status
DNS-Server pro Schnittstelle anzeigen [RO] resolvectl dns
DNS-Domänen pro Schnittstelle anzeigen [RO] resolvectl domain
Namen über den Systemresolver abfragen [TEST] resolvectl query example.com
Auflösung über NSS testen [TEST] getent hosts example.com
IPv4- und IPv6-Ergebnisse anzeigen [TEST] getent ahosts example.com
Standard-DNS-Abfrage durchführen [TEST] dig example.com
IPv4-Adresse abfragen [TEST] dig A example.com
IPv6-Adresse abfragen [TEST] dig AAAA example.com
Mailserver abfragen [TEST] dig MX example.com
Nameserver abfragen [TEST] dig NS example.com
Kurzausgabe erzeugen [TEST] dig +short example.com
Bestimmten DNS-Server verwenden [TEST] dig @192.0.2.53 example.com
Vollständigen Delegationsweg prüfen [TEST] dig +trace example.com
Reverse-DNS-Abfrage durchführen [TEST] dig -x 192.0.2.10
Alternative kompakte Abfrage [TEST] host example.com
Reverse-Abfrage mit host [TEST] host 192.0.2.10

Warum können die Ergebnisse unterschiedlich sein?

Werkzeug Verwendeter Weg
getent hosts Systemweite Name Service Switch-Konfiguration aus /etc/nsswitch.conf
resolvectl query systemd-resolved
dig Direkte DNS-Abfrage; berücksichtigt nicht automatisch alle NSS-Quellen
host Direkte DNS-Abfrage
Anwendung Kann eigenen Resolver, eigenen Cache oder DNS over HTTPS verwenden

Zusätzliche Prüfungen

Aufgabe Linux-Befehl
NSS-Reihenfolge prüfen [RO] grep '^hosts:' /etc/nsswitch.conf
Lokale Hosts-Datei prüfen [RO] cat /etc/hosts
Status von systemd-resolved prüfen [RO] systemctl status systemd-resolved --no-pager
DNS-Protokoll anzeigen [RO][PRIV] sudo journalctl -u systemd-resolved --since "30 minutes ago"
DNS-Statistik anzeigen [RO] resolvectl statistics

Typische Fehlerbilder

Interne Hostnamen und DNS-Zonen können sensible Unternehmensinformationen darstellen. Sie sollten nicht unüberlegt an öffentliche Resolver gesendet werden.

9. NetworkManager mit nmcli diagnostizieren

nmcli ist das Kommandozeilenwerkzeug für NetworkManager.

Aufgabe Linux-Befehl
Allgemeinen Status anzeigen [RO] nmcli general status
Prüfen, ob NetworkManager läuft [RO] nmcli -terse -fields RUNNING general
Gerätestatus anzeigen [RO] nmcli device status
Details aller Geräte anzeigen [RO] nmcli device show
Details einer Schnittstelle anzeigen [RO] nmcli device show enp1s0
Verbindungprofile auflisten [RO] nmcli connection show
Aktive Profile anzeigen [RO] nmcli connection show --active
Detailinformationen eines Profils anzeigen [RO] nmcli connection show "PROFILNAME"
IP-Adressen eines Profils anzeigen [RO] nmcli -get-values IP4.ADDRESS connection show "PROFILNAME"
DNS-Daten eines Profils anzeigen [RO] nmcli -get-values IP4.DNS connection show "PROFILNAME"
NetworkManager-Konnektivitätsstatus anzeigen [RO] nmcli networking connectivity
Konnektivität neu prüfen [TEST] nmcli networking connectivity check
WLAN-Zustand anzeigen [RO] nmcli radio wifi
Sichtbare WLANs auflisten [TEST] nmcli device wifi list
Änderungen überwachen [RO] nmcli monitor

Für Skripte sollten die vollständigen Befehlsnamen statt möglicherweise mehrdeutiger Abkürzungen verwendet werden.

Wichtige Gerätezustände

Zustand Bedeutung
connected Gerät verwendet ein aktives Verbindungsprofil
disconnected Gerät ist vorhanden, aber nicht verbunden
connecting Verbindungsaufbau läuft
unavailable Gerät kann momentan nicht verwendet werden
unmanaged NetworkManager verwaltet dieses Gerät nicht

Wichtiger Unterschied

10. systemd-networkd mit networkctl diagnostizieren

networkctl zeigt den Zustand von Schnittstellen, wenn systemd-networkd verwendet wird.

Aufgabe Linux-Befehl
Schnittstellenübersicht anzeigen [RO] networkctl list
Gesamtstatus anzeigen [RO] networkctl status
Einzelne Schnittstelle anzeigen [RO] networkctl status enp1s0
LLDP-Nachbarn anzeigen [RO] networkctl lldp
Status von systemd-networkd anzeigen [RO] systemctl status systemd-networkd --no-pager
Protokoll der letzten 30 Minuten anzeigen [RO][PRIV] sudo journalctl -u systemd-networkd --since "30 minutes ago"
Konfigurationsdateien auflisten [RO] find /etc/systemd/network /run/systemd/network /usr/lib/systemd/network -maxdepth 1 -type f 2>/dev/null

Typische Fehlerbilder

Nicht gleichzeitig davon ausgehen, dass NetworkManager und systemd-networkd dieselbe Schnittstelle verwalten. Zuerst muss festgestellt werden, welcher Dienst tatsächlich zuständig ist.

11. Link, Treiber und Hardware mit ethtool prüfen

ethtool liefert Informationen über Ethernet-Schnittstellen, Treiber und Aushandlung.

Aufgabe Linux-Befehl
Linkeinstellungen anzeigen [RO] ethtool enp1s0
Treiberinformationen anzeigen [RO] ethtool -i enp1s0
Schnittstellenstatistik anzeigen [RO][PRIV] sudo ethtool -S enp1s0
Offload-Funktionen anzeigen [RO] ethtool -k enp1s0
Pause-Parameter anzeigen [RO] ethtool -a enp1s0
Ringpuffer anzeigen [RO][PRIV] sudo ethtool -g enp1s0
Zeitstempelfunktionen anzeigen [RO] ethtool -T enp1s0

Wichtige Angaben

Angabe Bedeutung
Speed Ausgehandelte Geschwindigkeit
Duplex Halb- oder Vollduplex
Auto-negotiation Automatische Aushandlung aktiviert oder deaktiviert
Link detected Physischer Link erkannt
Port Verwendeter Anschlusstyp
driver Verwendetes Kernelmodul
version Treiberversion
firmware-version Firmwareversion des Adapters

Typische Fehlerbilder

12. Offene Ports, Verbindungen und Prozesse mit ss prüfen

ss ist das zentrale moderne Werkzeug zur Untersuchung von Sockets und ersetzt viele frühere netstat-Anwendungsfälle.

Aufgabe Linux-Befehl
Socket-Zusammenfassung anzeigen [RO] ss -summary
Lauschende TCP-Ports anzeigen [RO] ss -listen -tcp -numeric
Lauschende TCP- und UDP-Ports anzeigen [RO] ss -listen -numeric -tcp -udp
Ports mit Prozessen anzeigen [RO][PRIV] sudo ss -listen -numeric -tcp -udp -processes
Alle TCP-Verbindungen anzeigen [RO] ss -all -tcp -numeric
Bestehende TCP-Verbindungen anzeigen [RO] ss -tcp -numeric state established
TCP-Verbindungen mit internen Informationen [RO] ss -tcp -numeric -info
Lokalen Port 443 prüfen [RO] ss -listen -tcp -numeric 'sport = :443'
Verbindungen zu Zielport 443 anzeigen [RO] ss -tcp -numeric 'dport = :443'
UNIX-Sockets anzeigen [RO] ss -x -all

Häufig verwendete Kurzform

sudo ss -lntup

Die Optionen bedeuten:

Option Bedeutung
-l Nur lauschende Sockets
-n Numerische Adressen und Ports
-t TCP
-u UDP
-p Zugehörige Prozesse anzeigen

Interpretation

Beobachtung Mögliche Bedeutung
Erwarteter Port fehlt Dienst läuft nicht oder lauscht auf einem anderen Port
Dienst lauscht nur auf 127.0.0.1 Nur lokale Verbindungen möglich
Dienst lauscht auf 0.0.0.0 Lauscht grundsätzlich auf allen IPv4-Adressen
Dienst lauscht auf :: Lauscht auf IPv6; IPv4-Verhalten hängt zusätzlich von System und Anwendung ab
Viele Verbindungen in SYN-SENT Ziel oder Firewall antwortet möglicherweise nicht
Viele Verbindungen in SYN-RECV Viele eingehende, noch nicht vollständig aufgebaute Verbindungen
Große Send-Q Daten können möglicherweise nicht schnell genug gesendet werden
Große Recv-Q Anwendung verarbeitet empfangene Daten möglicherweise nicht schnell genug
13. Ports und Prozesse mit lsof und fuser zuordnen
Aufgabe Linux-Befehl
Alle Netzwerkdateien anzeigen [RO][PRIV] sudo lsof -numeric -P -i
Lauschende TCP-Ports anzeigen [RO][PRIV] sudo lsof -numeric -P -iTCP -sTCP:LISTEN
TCP-Port 443 untersuchen [RO][PRIV] sudo lsof -numeric -P -iTCP:443
UDP-Port 53 untersuchen [RO][PRIV] sudo lsof -numeric -P -iUDP:53
Prozess auf TCP-Port 443 suchen [RO][PRIV] sudo fuser -verbose 443/tcp
Prozess auf UDP-Port 53 suchen [RO][PRIV] sudo fuser -verbose 53/udp
Prozessdetails anhand der PID anzeigen [RO] ps -fp 1234
Ausführliche Prozessinformationen anzeigen [RO] ps -p 1234 -o pid,ppid,user,group,cmd

Bei fehlenden Root-Rechten werden möglicherweise nicht alle Prozessinformationen angezeigt.

14. TCP- und UDP-Ports aktiv testen
Aufgabe Linux-Befehl
TCP-Port testen [TEST] nc -verbose -zero -wait 3 example.com 443
SSH-Port testen [TEST] nc -verbose -zero -wait 3 192.0.2.10 22
Mehrere Ports testen [TEST] nc -verbose -zero -wait 3 192.0.2.10 22 80 443
UDP-Port testen [TEST] nc -verbose -zero -udp -wait 3 192.0.2.53 53
Bash-TCP-Test durchführen [TEST] timeout 3 bash -c '</dev/tcp/example.com/443'

Häufig verwendete Kurzform

nc -vz -w 3 example.com 443

Mögliche Ergebnisse

Ergebnis Bedeutung
succeeded oder open TCP-Verbindung konnte aufgebaut werden
Connection refused Ziel erreichbar, aber kein Dienst akzeptiert die Verbindung oder lehnt sie aktiv ab
timed out Keine rechtzeitige Antwort; Firewall, Routing oder Zielsystem prüfen
No route to host Kein verwendbarer Netzwerkweg oder entsprechende ICMP-Rückmeldung
Name or service not known Namensauflösung fehlgeschlagen

Ein UDP-Test mit nc kann ohne Antwort nicht zuverlässig beweisen, ob der UDP-Port offen oder geschlossen ist. UDP besitzt keinen TCP-Verbindungsaufbau.

15. Firewallstatus lesend prüfen

Linux-Systeme können unterschiedliche Werkzeuge zur Firewallverwaltung einsetzen. Zuerst muss festgestellt werden, welches System tatsächlich aktiv ist.

Aufgabe Linux-Befehl
nftables-Regelwerk anzeigen [RO][PRIV][SENS] sudo nft list ruleset
iptables-Filterregeln anzeigen [RO][PRIV][SENS] sudo iptables -S
iptables-Regeln mit Zählern anzeigen [RO][PRIV][SENS] sudo iptables -L -numeric -verbose
IPv6-iptables-Regeln anzeigen [RO][PRIV][SENS] sudo ip6tables -S
UFW-Status anzeigen [RO][PRIV] sudo ufw status verbose
firewalld-Status prüfen [RO] firewall-cmd --state
Aktive firewalld-Zonen anzeigen [RO][PRIV] sudo firewall-cmd --get-active-zones
Regeln der aktiven Zone anzeigen [RO][PRIV][SENS] sudo firewall-cmd --list-all
Alle firewalld-Zonen anzeigen [RO][PRIV][SENS] sudo firewall-cmd --list-all-zones
nftables-Dienststatus anzeigen [RO] systemctl status nftables --no-pager
firewalld-Dienststatus anzeigen [RO] systemctl status firewalld --no-pager
UFW-Dienststatus anzeigen [RO] systemctl status ufw --no-pager

Prüfpunkte

Die Firewall nicht pauschal deaktivieren. Zuerst müssen Dienstbindung, Route, verwendete Schnittstelle und passende Regeln geprüft werden.

16. Netzwerkdienste und Protokolle prüfen
Aufgabe Linux-Befehl
Fehlgeschlagene Dienste anzeigen [RO] systemctl --failed
NetworkManager-Status anzeigen [RO] systemctl status NetworkManager --no-pager
systemd-networkd-Status anzeigen [RO] systemctl status systemd-networkd --no-pager
systemd-resolved-Status anzeigen [RO] systemctl status systemd-resolved --no-pager
Dienstprotokoll anzeigen [RO][PRIV] sudo journalctl -u NetworkManager --since "30 minutes ago"
networkd-Protokoll anzeigen [RO][PRIV] sudo journalctl -u systemd-networkd --since "30 minutes ago"
resolved-Protokoll anzeigen [RO][PRIV] sudo journalctl -u systemd-resolved --since "30 minutes ago"
Kernelmeldungen zum Netzwerk filtern `[RO][PRIV] sudo dmesg --human | grep -Ei 'link
Kernelmeldungen des aktuellen Starts [RO][PRIV] sudo journalctl -kernel -boot
Letzte Kernelmeldungen live verfolgen [RO][PRIV] sudo journalctl -kernel -follow
Startzeit eines Dienstes anzeigen [RO] systemctl show NetworkManager -property ActiveEnterTimestamp

Typische Protokollhinweise

Protokolle müssen immer mit Zeitstempel, betroffener Schnittstelle und vorhergehenden Ereignissen ausgewertet werden. Eine einzelne Meldung ohne Kontext reicht selten zur Ursachenbestimmung.

17. Diagnoseinformationen sichern und vergleichen
Aufgabe Linux-Befehl
Linkinformationen speichern [RO][FILE][SENS] ip -details -statistics link show > link-status.txt
IP-Adressen speichern [RO][FILE][SENS] ip address show > ip-addresses.txt
Routingtabellen speichern [RO][FILE][SENS] ip route show table all > routes.txt
Policy-Regeln speichern [RO][FILE][SENS] ip rule show > routing-rules.txt
Nachbartabelle speichern [RO][FILE][SENS] ip neighbour show > neighbours.txt
Ports und Prozesse speichern [RO][PRIV][FILE][SENS] sudo ss -lntup > listening-ports.txt
NetworkManager-Status speichern [RO][FILE][SENS] nmcli device show > networkmanager-devices.txt
Resolverstatus speichern [RO][FILE][SENS] resolvectl status > resolver-status.txt
Netzwerkprotokolle speichern [RO][PRIV][FILE][SENS] sudo journalctl -u NetworkManager --since "1 hour ago" > networkmanager-log.txt

Zwei Messzeitpunkte vergleichen

ip -brief address show > addresses-vorher.txt
ip route show table all > routes-vorher.txt

# Messung oder freigegebene Änderung durchführen

ip -brief address show > addresses-nachher.txt
ip route show table all > routes-nachher.txt

diff -u addresses-vorher.txt addresses-nachher.txt
diff -u routes-vorher.txt routes-nachher.txt

Hinweise

18. Eingreifende Befehle nur nach der Diagnose verwenden

Die folgenden Befehle verändern den Systemzustand und können insbesondere über SSH die eigene Verbindung unterbrechen.

Maßnahme Linux-Befehl Auswirkung
Schnittstelle deaktivieren [CHANGE][PRIV][DISRUPT] sudo ip link set dev enp1s0 down Verbindung wird unterbrochen
Schnittstelle aktivieren [CHANGE][PRIV] sudo ip link set dev enp1s0 up Schnittstelle wird aktiviert
NetworkManager-Gerät trennen [CHANGE][PRIV][DISRUPT] sudo nmcli device disconnect enp1s0 Aktive Verbindung wird getrennt
NetworkManager-Gerät verbinden [CHANGE][PRIV] sudo nmcli device connect enp1s0 NetworkManager versucht eine Verbindung aufzubauen
Verbindungsprofil neu aktivieren [CHANGE][PRIV][DISRUPT] sudo nmcli connection up "PROFILNAME" Profil wird aktiviert beziehungsweise neu angewendet
NetworkManager neu starten [CHANGE][PRIV][DISRUPT] sudo systemctl restart NetworkManager Verwaltete Verbindungen können unterbrochen werden
systemd-networkd neu starten [CHANGE][PRIV][DISRUPT] sudo systemctl restart systemd-networkd Verwaltete Verbindungen können unterbrochen werden
DNS-Cache leeren [CHANGE][PRIV] sudo resolvectl flush-caches Lokale DNS-Cacheeinträge werden entfernt

Vor einem Eingriff prüfen

Auf einem entfernten System darf die aktive Managementschnittstelle nicht ohne gesicherten Rückfallweg deaktiviert oder neu gestartet werden.

19. Praktische Linux-Diagnosereihenfolge

Schritt 1 – System und Netzwerkverwaltung identifizieren

cat /etc/os-release
systemctl is-active NetworkManager
systemctl is-active systemd-networkd

Schritt 2 – Linkstatus prüfen

ip -brief link show
ip -statistics link show

Schritt 3 – IP-Adressen prüfen

ip -brief address show

Schritt 4 – Standardroute und Routenauswahl prüfen

ip route show default
ip route get 1.1.1.1
ip rule show

Schritt 5 – Nachbartabelle prüfen

ip neighbour show

Schritt 6 – Standardgateway testen

ping -c 4 192.0.2.1

Schritt 7 – Externe IP-Adresse testen

ping -c 4 1.1.1.1

Schritt 8 – DNS-Konfiguration prüfen

cat /etc/resolv.conf
resolvectl status

Schritt 9 – DNS-Auflösung testen

getent hosts example.com
dig example.com

Schritt 10 – Zielport testen

nc -vz -w 3 example.com 443

Schritt 11 – Lokale Ports und Prozesse prüfen

sudo ss -lntup

Schritt 12 – Netzwerkpfad untersuchen

tracepath example.com
mtr --report --numeric --report-cycles 20 example.com

Schritt 13 – Firewallstatus prüfen

sudo nft list ruleset

Schritt 14 – Netzwerkprotokolle prüfen

sudo journalctl -u NetworkManager --since "30 minutes ago"
sudo journalctl -kernel --since "30 minutes ago"

Diagnoselogik

Ergebnis Nächster Schwerpunkt
Schnittstelle fehlt Hardware, Treiber, virtuelle Maschine oder Gerätezuordnung prüfen
Schnittstelle DOWN Administrativen Zustand und Netzwerkverwaltung prüfen
Kein LOWER_UP beziehungsweise kein Carrier Kabel, WLAN, Switchport oder Linkpartner prüfen
Keine passende IP-Adresse DHCP oder statische Konfiguration prüfen
Keine Standardroute Gateway- und Profilkonfiguration prüfen
Gateway nicht erreichbar Lokales Netz, VLAN, Bridge, Switch oder WLAN prüfen
Externe IP erreichbar, DNS-Name nicht DNS-Konfiguration und Resolver prüfen
Ziel-IP erreichbar, Zielport nicht Dienst, Portbindung und Firewall prüfen
Falsche Quelladresse oder Schnittstelle Routing, Policy Routing, VPN und Metrik prüfen
Dienst lauscht lokal, ist extern aber nicht erreichbar Firewall, Routing, NAT und Bind-Adresse prüfen

Kurzreferenz

Diagnoseziel Linux-Befehl
Schnittstellenstatus [RO] ip -brief link show
Schnittstellenstatistik [RO] ip -statistics link show
IP-Adressen [RO] ip -brief address show
IPv4-Adressen [RO] ip -4 address show
IPv6-Adressen [RO] ip -6 address show
Standardroute [RO] ip route show default
Route zu einem Ziel [RO] ip route get 1.1.1.1
Policy Routing [RO] ip rule show
Nachbartabelle [RO] ip neighbour show
Gateway testen [TEST] ping -c 4 192.0.2.1
Netzwerkpfad [TEST] tracepath example.com
Fortlaufende Pfadanalyse [TEST] mtr example.com
Resolverstatus [RO] resolvectl status
Namensauflösung über NSS [TEST] getent hosts example.com
DNS-Abfrage [TEST] dig example.com
NetworkManager-Status [RO] nmcli general status
NetworkManager-Geräte [RO] nmcli device status
systemd-networkd-Status [RO] networkctl status
Ethernet-Link [RO] ethtool enp1s0
Treiberinformationen [RO] ethtool -i enp1s0
Lauschende Ports [RO][PRIV] sudo ss -lntup
TCP-Port testen [TEST] nc -vz -w 3 example.com 443
Port einem Prozess zuordnen [RO][PRIV] sudo lsof -nP -iTCP:443
nftables-Regeln [RO][PRIV] sudo nft list ruleset
Dienststatus [RO] systemctl status DIENST --no-pager
Dienstprotokoll [RO][PRIV] sudo journalctl -u DIENST
Kernelprotokoll [RO][PRIV] sudo journalctl -kernel

Veraltete und moderne Befehle

Älterer Befehl Bevorzugter moderner Befehl
ifconfig ip address, ip link
route -n ip route
arp -n ip neighbour
netstat -lntup ss -lntup

Ältere Werkzeuge können weiterhin installiert sein. Für neue Dokumentationen und aktuelle Linux-Systeme sollten grundsätzlich die iproute2-Werkzeuge verwendet werden.

Merksatz

Die Linux-Netzwerkdiagnose folgt einer festen Kette: Schnittstelle → Link → IP-Adresse → Nachbartabelle → Route → Gateway → DNS → Zielport → lokaler Dienst → Firewall → Protokolle.

Quellen

2. Grundwerkzeuge und Befehle

2.4 macOS-Netzwerkdiagnose

macOS basiert auf Darwin und stellt zahlreiche BSD- und Apple-spezifische Netzwerkwerkzeuge bereit. Einige Befehle ähneln Linux-Kommandos, verwenden aber teilweise andere Optionen und Ausgabeformate.

Wichtige macOS-Werkzeuge sind:

Kennzeichnungen

Kennzeichnung Bedeutung
[RO] Nur lesender Befehl; verändert keine Konfiguration
[TEST] Führt einen aktiven Netzwerk- oder Verbindungstest aus
[PRIV] Benötigt Administratorrechte beziehungsweise sudo
[CHANGE] Verändert einen Zustand oder eine Konfiguration
[DISRUPT] Kann eine Verbindung oder einen Dienst unterbrechen
[FILE] Schreibt Informationen in eine Datei
[SENS] Ausgabe kann sensible System-, Netzwerk- oder Prozessdaten enthalten

Vor Änderungen sollten Netzwerkdienst, Schnittstelle, IP-Konfiguration, Route, DNS-Server und aktive VPN- beziehungsweise Proxykonfiguration dokumentiert werden.

1. macOS-Version und verfügbare Werkzeuge prüfen
Aufgabe macOS-Befehl
macOS-Version anzeigen [RO] sw_vers
Produktversion kompakt anzeigen [RO] sw_vers -productVersion
Build-Nummer anzeigen [RO] sw_vers -buildVersion
Kernelversion anzeigen [RO] uname -a
Prozessorarchitektur anzeigen [RO] uname -m
Hardwareübersicht anzeigen [RO] system_profiler SPHardwareDataType
Softwareübersicht anzeigen [RO] system_profiler SPSoftwareDataType
Prüfen, ob ein Befehl vorhanden ist [RO] command -v networkQuality
Mehrere Werkzeuge prüfen [RO] command -v networksetup scutil ifconfig route netstat arp ndp ping traceroute dig lsof nc wdutil networkQuality
Hilfe zu networksetup anzeigen [RO] networksetup -help
Lokale Handbuchseite öffnen [RO] man networksetup
Handbuchseite zu scutil öffnen [RO] man scutil
Handbuchseite zu ifconfig öffnen [RO] man ifconfig

Hinweis zu macOS-Versionen

Nicht jedes Werkzeug steht in jeder macOS-Version zur Verfügung:

2. Netzwerkdienste und Hardwareports zuordnen

Unter macOS muss zwischen einem Netzwerkdienst und der technischen Schnittstelle unterschieden werden.

Beispiele:

Netzwerkdienst Mögliche Schnittstelle
Wi-Fi en0 oder eine andere en-Schnittstelle
Ethernet en0, en1, en5 oder eine andere Schnittstelle
USB-Ethernet Abhängig vom angeschlossenen Adapter
Thunderbolt Bridge Bridge- beziehungsweise Thunderbolt-Schnittstelle
VPN Häufig utun0, utun1 oder eine weitere utun-Schnittstelle

Zuordnung prüfen

Aufgabe macOS-Befehl
Alle Hardwareports auflisten [RO] networksetup -listallhardwareports
Alle Netzwerkdienste auflisten [RO] networksetup -listallnetworkservices
Reihenfolge der Netzwerkdienste anzeigen [RO] networksetup -listnetworkserviceorder
Informationen zum Dienst Wi-Fi anzeigen [RO] networksetup -getinfo "Wi-Fi"
Informationen zum Dienst Ethernet anzeigen [RO] networksetup -getinfo "Ethernet"
Aktive Netzwerksicht anzeigen [RO] scutil --nwi
Netzwerkkonfiguration über System Profiler anzeigen [RO][SENS] system_profiler SPNetworkDataType

Wichtiger Unterschied

Vor jedem Befehl mit en0, en1 oder einem Dienstnamen muss die tatsächliche Zuordnung mit networksetup -listallhardwareports geprüft werden.

3. Netzwerkschnittstellen und Linkstatus prüfen
Aufgabe macOS-Befehl
Alle Schnittstellen anzeigen [RO] ifconfig -a
Einzelne Schnittstelle anzeigen [RO] ifconfig en0
Aktive Schnittstellen anzeigen [RO] ifconfig -u
Inaktive Schnittstellen anzeigen [RO] ifconfig -d
Schnittstellennamen auflisten [RO] ifconfig -l
Schnittstellenstatistik anzeigen [RO] netstat -ibn
Netzwerkhardware anzeigen [RO][SENS] system_profiler SPNetworkDataType
Ethernet-Hardwareinformationen anzeigen [RO] system_profiler SPEthernetDataType

Wichtige Angaben von ifconfig

Angabe Bedeutung
UP Schnittstelle wurde administrativ aktiviert
RUNNING Schnittstelle ist betriebsbereit
ACTIVE Aktiver physischer beziehungsweise logischer Link
status: active Verbindung wurde erkannt
status: inactive Keine aktive Verbindung erkannt
ether MAC-Adresse
inet IPv4-Adresse
inet6 IPv6-Adresse
netmask Netzmaske, häufig hexadezimal dargestellt
broadcast IPv4-Broadcastadresse
mtu Maximum Transmission Unit
media Medium, Geschwindigkeit und Duplexmodus

Typische Fehlerbilder

Beobachtung Mögliche Bedeutung
status: inactive Kein Link, WLAN getrennt, Kabel- oder Portproblem
Schnittstelle fehlt Adapter, Treiber, USB-/Thunderbolt-Verbindung oder Hardware prüfen
Keine inet-Adresse Keine verwendbare IPv4-Konfiguration
Nur 169.254.x.x Keine reguläre IPv4-Konfiguration beziehungsweise DHCP-Zuweisung
Unerwartete MTU VPN-, Tunnel- oder Fragmentierungsproblem möglich
Viele Fehler in netstat -ibn Link-, Adapter-, Treiber- oder Überlastungsproblem möglich
4. IP-Konfiguration und DHCP prüfen
Aufgabe macOS-Befehl
IPv4-Adresse einer Schnittstelle anzeigen [RO] ipconfig getifaddr en0
Gesamte Schnittstellenkonfiguration anzeigen [RO] ifconfig en0
Informationen des Dienstes Wi-Fi anzeigen [RO] networksetup -getinfo "Wi-Fi"
Informationen des Dienstes Ethernet anzeigen [RO] networksetup -getinfo "Ethernet"
DHCP-Paketinformationen anzeigen [RO][PRIV][SENS] sudo ipconfig getpacket en0
DHCP-Server auslesen [RO][PRIV] sudo ipconfig getoption en0 server_identifier
Subnetzmaske auslesen [RO][PRIV] sudo ipconfig getoption en0 subnet_mask
Router aus DHCP auslesen [RO][PRIV] sudo ipconfig getoption en0 router
DNS-Server aus DHCP auslesen [RO][PRIV] sudo ipconfig getoption en0 domain_name_server
IPv6-Konfiguration anzeigen [RO] ifconfig en0 | grep inet6
Netzwerkstatus zusammengefasst anzeigen [RO] scutil --nwi

Prüfpunkte

ipconfig getpacket zeigt die zuletzt erhaltenen DHCP-Informationen. Die Ausgabe kann interne Netzwerkinformationen enthalten.

5. Routingtabelle und verwendeten Netzwerkweg prüfen
Aufgabe macOS-Befehl
Standardroute anzeigen [RO] route -n get default
Route zu einer IPv4-Adresse anzeigen [RO] route -n get 1.1.1.1
Route zu einem DNS-Namen anzeigen [RO][TEST] route -n get example.com
IPv4-Routingtabelle anzeigen [RO] netstat -rn -f inet
IPv6-Routingtabelle anzeigen [RO] netstat -rn -f inet6
Gesamte Routingtabelle anzeigen [RO] netstat -rn
Netzwerkstatus anzeigen [RO] scutil --nwi
Aktive VPN-/Tunnel-Schnittstellen suchen [RO] ifconfig -l | tr ' ' '\n' | grep '^utun'
Details einer Tunnel-Schnittstelle anzeigen [RO] ifconfig utun0

Wichtige Angaben von route -n get

Angabe Bedeutung
destination Zieladresse
gateway Nächster Router
interface Verwendete Schnittstelle
flags Eigenschaften der Route
recvpipe Empfangspufferinformationen
sendpipe Sendepufferinformationen

Wichtige Flags der Routingtabelle

Flag Bedeutung
U Route ist aktiv
G Ziel wird über ein Gateway erreicht
H Hostroute zu einem einzelnen Ziel
S Statische Route
C Geklonte Route
I Schnittstellenroute

Typische Fehlerbilder

6. ARP- und IPv6-Nachbartabelle prüfen
Aufgabe macOS-Befehl
Gesamte IPv4-ARP-Tabelle anzeigen [RO] arp -an
Bestimmte IPv4-Adresse prüfen [RO] arp -n 192.0.2.1
IPv6-Nachbartabelle anzeigen [RO] ndp -an
IPv6-Standardrouter anzeigen [RO] ndp -r
IPv6-Präfixinformationen anzeigen [RO] ndp -p
Schnittstelleninformationen anzeigen [RO] ndp -i en0

Typische Beobachtungen

Beobachtung Mögliche Bedeutung
(incomplete) MAC-Auflösung wurde nicht abgeschlossen
Kein Gateway-Eintrag Gateway wurde noch nicht angesprochen oder ist nicht erreichbar
Unerwartete MAC-Adresse Doppelte IP-Adresse, anderes Gateway oder Sicherheitsproblem möglich
Gleiche IP mit wechselnder MAC-Adresse Hochverfügbarkeit, doppelte Adresse oder Manipulation prüfen
IPv6-Nachbarstatus nicht erreichbar Lokalen IPv6-Link und Router Advertisement prüfen

Ein fehlender ARP-Eintrag beweist nicht automatisch einen Fehler. Ein Eintrag entsteht normalerweise erst, wenn das Ziel angesprochen wurde.

7. Erreichbarkeit mit ping prüfen
Aufgabe macOS-Befehl
Vier Anfragen an das Gateway senden [TEST] ping -c 4 192.0.2.1
Externe IPv4-Adresse testen [TEST] ping -c 4 1.1.1.1
DNS-Namen testen [TEST] ping -c 4 example.com
Bestimmte Quelladresse verwenden [TEST] ping -S 192.0.2.10 -c 4 192.0.2.1
IPv6-Ziel testen [TEST] ping6 -c 4 2001:db8::1
IPv6-Link-Local-Ziel mit Schnittstelle testen [TEST] ping6 -c 4 fe80::1%en0
Paketgröße testen [TEST] ping -c 4 -s 1400 192.0.2.1
Akustisches Signal bei Antwort [TEST] ping -a -c 4 192.0.2.1

Wichtige Ergebnisse

Wert Bedeutung
time Round Trip Time
ttl Verbleibende IPv4 Time to Live
icmp_seq Nummer der ICMP-Anfrage
packet loss Anteil verlorener Pakete
min/avg/max/stddev Laufzeitstatistik

Interpretation

Ergebnis Mögliche Bedeutung
Gateway nicht erreichbar Lokales Netz, WLAN, Kabel, VLAN oder Router prüfen
IP-Adresse erreichbar, DNS-Name nicht DNS-Problem wahrscheinlich
Externe IP nicht erreichbar, Gateway erreichbar Routing, Firewall, Provider oder Upstream prüfen
Ping schlägt fehl, TCP-Port funktioniert ICMP wird möglicherweise blockiert
Hohe Laufzeitschwankungen WLAN-Störung, Überlastung oder wechselnder Netzwerkweg
Paketverlust Funkstörung, Linkproblem, Überlastung oder Rate Limiting möglich
8. Netzwerkpfad mit traceroute untersuchen
Aufgabe macOS-Befehl
Netzwerkpfad anzeigen [TEST] traceroute example.com
Keine DNS-Auflösung durchführen [TEST] traceroute -n example.com
Anzahl der Hops begrenzen [TEST] traceroute -m 15 example.com
Wartezeit pro Probe begrenzen [TEST] traceroute -w 2 example.com
IPv6-Netzwerkpfad anzeigen [TEST] traceroute6 example.com
ICMP statt UDP verwenden [TEST][PRIV] sudo traceroute -I example.com

Auswertung

9. DNS-Konfiguration und Namensauflösung prüfen

scutil --dns zeigt die tatsächlich vom macOS-System verwendete Resolverkonfiguration. Die Ausgabe kann mehrere Resolver für verschiedene Domänen und Schnittstellen enthalten.

Aufgabe macOS-Befehl
Gesamte Resolverkonfiguration anzeigen [RO][SENS] scutil --dns
DNS-Server des Dienstes Wi-Fi anzeigen [RO] networksetup -getdnsservers "Wi-Fi"
DNS-Server des Dienstes Ethernet anzeigen [RO] networksetup -getdnsservers "Ethernet"
Suchdomänen anzeigen [RO] networksetup -getsearchdomains "Wi-Fi"
Namen über den Systemcache abfragen [TEST] dscacheutil -q host -a name example.com
Standard-DNS-Abfrage durchführen [TEST] dig example.com
IPv4-Adresse abfragen [TEST] dig A example.com
IPv6-Adresse abfragen [TEST] dig AAAA example.com
Mailserver abfragen [TEST] dig MX example.com
Kurzausgabe erzeugen [TEST] dig +short example.com
Bestimmten Resolver verwenden [TEST] dig @192.0.2.53 example.com
Vollständigen Delegationsweg prüfen [TEST] dig +trace example.com
Reverse-DNS-Abfrage durchführen [TEST] dig -x 192.0.2.10
Alternative Abfrage durchführen [TEST] host example.com
Lokale Hosts-Datei anzeigen [RO] cat /etc/hosts

Warum kann macOS mehrere Resolver anzeigen?

macOS kann Resolver abhängig von folgenden Faktoren auswählen:

Typische Fehlerbilder

Beobachtung Mögliche Ursache
dig funktioniert, Anwendung jedoch nicht Anwendung, Cache, Proxy oder eigener Resolver
Öffentlicher Name funktioniert, interner nicht Split-DNS, VPN oder interner Resolver prüfen
Falscher DNS-Server in scutil --dns Netzwerkdienst, VPN oder Profil prüfen
Mehrere Resolver mit unterschiedlicher Reihenfolge Domänenspezifische Resolver oder VPN-Konfiguration
IP-Adresse erreichbar, Name nicht DNS-Problem wahrscheinlich
Unterschiedliche Antworten verschiedener DNS-Server Split-DNS, Cache oder unterschiedliche Zonen

Für die tatsächliche Resolverauswahl von macOS ist scutil --dns normalerweise aussagekräftiger als eine isolierte Betrachtung einzelner Konfigurationsfelder.

10. Proxy-, VPN- und Network-Extension-Einflüsse prüfen
Aufgabe macOS-Befehl
Systemweite Proxykonfiguration anzeigen [RO][SENS] scutil --proxy
HTTP-Proxy für Wi-Fi anzeigen [RO] networksetup -getwebproxy "Wi-Fi"
HTTPS-Proxy für Wi-Fi anzeigen [RO] networksetup -getsecurewebproxy "Wi-Fi"
Automatische Proxykonfiguration anzeigen [RO] networksetup -getautoproxyurl "Wi-Fi"
Proxy-Bypass-Domänen anzeigen [RO][SENS] networksetup -getproxybypassdomains "Wi-Fi"
Aktive Netzwerksicht anzeigen [RO] scutil --nwi
Tunnel-Schnittstellen anzeigen [RO] ifconfig -l | tr ' ' '\n' | grep '^utun'
Systemerweiterungen anzeigen [RO][SENS] systemextensionsctl list
Netzwerkdienste nach Reihenfolge anzeigen [RO] networksetup -listnetworkserviceorder

Mögliche Einflussfaktoren

Typisches Fehlerbild

Beobachtung Mögliche Ursache
Ping funktioniert, Webseiten nicht Proxy, DNS, TLS, Browser oder Filtersoftware
Nur einzelne Anwendungen betroffen Anwendungsproxy oder anwendungsspezifische Network Extension
Verbindung funktioniert ohne VPN VPN-Routing, DNS oder Richtlinie prüfen
Interne Namen funktionieren nur mit VPN Split-DNS oder interne DNS-Zone
Falsche Route über utun VPN- oder Filtersoftware beeinflusst Routing
11. WLAN-Verbindung und Funkqualität prüfen

Zuordnung und Status

Aufgabe macOS-Befehl
Wi-Fi-Hardwareport bestimmen [RO] networksetup -listallhardwareports
Wi-Fi-Energiezustand anzeigen [RO] networksetup -getairportpower en0
Verbundenes WLAN anzeigen [RO] networksetup -getairportnetwork en0
WLAN-Informationen anzeigen [RO][PRIV][SENS] sudo wdutil info
Ausführliche WLAN-Hardwareinformationen [RO][SENS] system_profiler SPAirPortDataType
WLAN-Schnittstelle anzeigen [RO] ifconfig en0

Vor der Verwendung von en0 muss die tatsächliche Wi-Fi-Schnittstelle mit networksetup -listallhardwareports bestimmt werden.

Wichtige WLAN-Werte

Wert Bedeutung
SSID Name des WLANs
BSSID MAC-Adresse des Access Points
RSSI Empfangssignalstärke
Noise Grundrauschen
Channel Verwendeter Funkkanal
Tx Rate Aktuelle Übertragungsrate
PHY Mode Verwendeter WLAN-Standard
Security Sicherheitsverfahren
MCS Modulation and Coding Scheme
NSS Anzahl räumlicher Datenströme

Signalbewertung als grobe Orientierung

RSSI Grobe Einordnung
etwa -30 dBm Sehr stark
etwa -50 dBm Gut
etwa -67 dBm Für viele Anwendungen noch brauchbar
etwa -70 dBm Schwach
unter -80 dBm Häufig instabil

RSSI-Werte allein beweisen keinen Fehler. Kanalbelegung, Störungen, Rauschen, Wiederholungen, Access-Point-Auslastung und Roaming müssen ebenfalls berücksichtigt werden.

Grafische Wireless Diagnostics öffnen

  1. Wahltaste beziehungsweise Option gedrückt halten.
  2. In der Menüleiste auf das Wi-Fi-Symbol klicken.
  3. Wireless Diagnostics öffnen auswählen.
  4. Anweisungen des Assistenten befolgen.

Wireless Diagnostics verändert laut Apple nicht die Netzwerksettings. Nach einer Analyse kann eine Diagnosedatei unter /var/tmp erzeugt werden. Der Dateiname beginnt mit WirelessDiagnostics und endet mit .tar.gz.

12. Netzwerkqualität und Reaktionsfähigkeit messen

networkQuality misst nicht nur die verfügbare Kapazität, sondern auch die Reaktionsfähigkeit der Verbindung unter Last.

Aufgabe macOS-Befehl
Standardmessung durchführen [TEST] networkQuality
Ausführliche Messung durchführen [TEST] networkQuality -v
Upload und Download nacheinander messen [TEST] networkQuality -s
Bestimmte Schnittstelle verwenden [TEST] networkQuality -I en0
Hilfe anzeigen [RO] networkQuality -h
Lokale Handbuchseite öffnen [RO] man networkQuality

Typische Ergebnisfelder

Ergebnis Bedeutung
Downlink capacity Gemessene Downloadkapazität
Uplink capacity Gemessene Uploadkapazität
Responsiveness Reaktionsfähigkeit unter Last
Idle Latency Latenz ohne zusätzliche Last
RPM Round-trips per Minute

Hinweise

13. Offene Ports, Verbindungen und Prozesse prüfen
Aufgabe macOS-Befehl
Lauschende TCP-Ports anzeigen [RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN
Alle Netzwerkverbindungen anzeigen [RO][PRIV] sudo lsof -nP -i
TCP-Port 443 untersuchen [RO][PRIV] sudo lsof -nP -iTCP:443
UDP-Port 53 untersuchen [RO][PRIV] sudo lsof -nP -iUDP:53
TCP-Sockets anzeigen [RO] netstat -anv -p tcp
UDP-Sockets anzeigen [RO] netstat -anv -p udp
Netzwerkstatistik anzeigen [RO] netstat -s
Schnittstellenstatistik anzeigen [RO] netstat -ibn
Prozessdetails anzeigen [RO] ps -p 1234 -o pid,ppid,user,command

Interpretation

Beobachtung Mögliche Bedeutung
Erwarteter Port fehlt Dienst läuft nicht oder lauscht auf einem anderen Port
Dienst lauscht auf 127.0.0.1 Nur lokal erreichbar
Dienst lauscht auf 0.0.0.0 Lauscht grundsätzlich auf allen IPv4-Schnittstellen
Dienst lauscht auf :: Lauscht auf IPv6; IPv4-Verhalten ist zusätzlich zu prüfen
Unerwarteter Prozess lauscht Dienstzuordnung und Sicherheitslage prüfen
Viele Verbindungen im Verbindungsaufbau Ziel, Route, Dienst oder Firewall antwortet möglicherweise nicht
14. TCP- und UDP-Ports aktiv testen
Aufgabe macOS-Befehl
HTTPS-Port testen [TEST] nc -vz -w 3 example.com 443
SSH-Port testen [TEST] nc -vz -w 3 192.0.2.10 22
SMB-Port testen [TEST] nc -vz -w 3 192.0.2.10 445
Mehrere Ports testen [TEST] nc -vz -w 3 192.0.2.10 22 80 443
UDP-Port testen [TEST] nc -vzu -w 3 192.0.2.53 53

Mögliche Ergebnisse

Ergebnis Bedeutung
succeeded TCP-Verbindung konnte aufgebaut werden
Connection refused Ziel erreichbar, aber Port geschlossen oder aktiv abgelehnt
Timeout Keine rechtzeitige Antwort; Firewall, Route oder Ziel prüfen
No route to host Kein verwendbarer Netzwerkweg oder entsprechende Rückmeldung
Namensauflösungsfehler DNS-Konfiguration prüfen

Bei UDP kann ein fehlendes Ergebnis nicht zuverlässig beweisen, dass ein Port offen oder geschlossen ist.

15. macOS-Firewall und Packet Filter prüfen

macOS besitzt verschiedene Sicherheitskomponenten:

Application Firewall

Aufgabe macOS-Befehl
Globalen Firewallstatus anzeigen [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
Stealth-Modus anzeigen [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode
Block-all-Modus anzeigen [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getblockall
Registrierte Anwendungen anzeigen [RO][PRIV][SENS] sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps

Packet Filter

Aufgabe macOS-Befehl
PF-Status anzeigen [RO][PRIV] sudo pfctl -s info
Geladene Regeln anzeigen [RO][PRIV][SENS] sudo pfctl -sr
NAT-Regeln anzeigen [RO][PRIV][SENS] sudo pfctl -sn
Status und Statistiken anzeigen [RO][PRIV] sudo pfctl -s all
PF-Tabellen anzeigen [RO][PRIV][SENS] sudo pfctl -s Tables

Prüfreihenfolge

  1. Prüfen, ob der Dienst lokal auf dem erwarteten Port lauscht.
  2. Bind-Adresse des Dienstes prüfen.
  3. Application-Firewallstatus prüfen.
  4. PF-Status und Regeln prüfen.
  5. Network Extensions und Sicherheitssoftware berücksichtigen.
  6. Port von einem autorisierten zweiten System testen.

Die Firewall nicht pauschal deaktivieren. Dadurch wird die Sicherheitslage verändert und das ursprüngliche Fehlerbild verfälscht.

16. Netzwerkprotokolle mit log untersuchen

macOS verwendet das Unified Logging System.

Aufgabe macOS-Befehl
Meldungen der letzten 30 Minuten anzeigen [RO][PRIV][SENS] sudo log show --last 30m --style compact
Meldungen von mDNSResponder anzeigen [RO][PRIV][SENS] sudo log show --last 30m --predicate 'process == "mDNSResponder"' --style compact
Meldungen von configd anzeigen [RO][PRIV][SENS] sudo log show --last 30m --predicate 'process == "configd"' --style compact
WLAN-Prozesse suchen [RO][PRIV][SENS] sudo log show --last 30m --predicate 'process CONTAINS[c] "airport" OR process CONTAINS[c] "WiFi"' --style compact
DNS-Meldungen live verfolgen [RO][PRIV][SENS] sudo log stream --predicate 'process == "mDNSResponder"' --style compact
Allgemeine Netzwerkbegriffe suchen `[RO][PRIV][SENS] sudo log show --last 30m --style compact | grep -Ei 'network

Prüfpunkte

Das macOS-Protokoll kann private und sensible Inhalte maskieren. Mit Administratorrechten können dennoch schützenswerte System- und Netzwerkdaten sichtbar werden.

17. Diagnoseinformationen sichern und vergleichen
Aufgabe macOS-Befehl
Schnittstellen sichern [RO][FILE][SENS] ifconfig -a > interfaces.txt
Routingtabelle sichern [RO][FILE][SENS] netstat -rn > routes.txt
Standardroute sichern [RO][FILE][SENS] route -n get default > default-route.txt
DNS-Konfiguration sichern [RO][FILE][SENS] scutil --dns > dns-status.txt
Proxykonfiguration sichern [RO][FILE][SENS] scutil --proxy > proxy-status.txt
Netzwerkdienste sichern [RO][FILE][SENS] networksetup -listnetworkserviceorder > network-services.txt
Netzwerkübersicht sichern [RO][FILE][SENS] system_profiler SPNetworkDataType > network-profiler.txt
Offene Ports sichern [RO][PRIV][FILE][SENS] sudo lsof -nP -i > network-connections.txt
WLAN-Diagnose sichern [RO][PRIV][FILE][SENS] sudo wdutil info > wifi-status.txt

Zwei Zustände vergleichen

ifconfig -a > interfaces-vorher.txt
netstat -rn > routes-vorher.txt
scutil --dns > dns-vorher.txt

# Messung oder freigegebene Änderung durchführen

ifconfig -a > interfaces-nachher.txt
netstat -rn > routes-nachher.txt
scutil --dns > dns-nachher.txt

diff -u interfaces-vorher.txt interfaces-nachher.txt
diff -u routes-vorher.txt routes-nachher.txt
diff -u dns-vorher.txt dns-nachher.txt

Datenschutz

Diagnoseausgaben können enthalten:

Vor einer Weitergabe müssen sensible Angaben redigiert werden.

18. Eingreifende Befehle und Rückfallmöglichkeiten

Die folgenden Befehle verändern einen Zustand und können eine Remoteverbindung sofort unterbrechen.

Maßnahme macOS-Befehl Auswirkung
DNS-Cache leeren [CHANGE][PRIV] sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder Lokale DNS-Cacheeinträge werden verworfen
Wi-Fi ausschalten [CHANGE][PRIV][DISRUPT] sudo networksetup -setairportpower en0 off WLAN-Verbindung wird getrennt
Wi-Fi einschalten [CHANGE][PRIV] sudo networksetup -setairportpower en0 on WLAN wird wieder aktiviert
Schnittstelle deaktivieren [CHANGE][PRIV][DISRUPT] sudo ifconfig en0 down Alle Verbindungen über die Schnittstelle werden getrennt
Schnittstelle aktivieren [CHANGE][PRIV] sudo ifconfig en0 up Schnittstelle wird wieder aktiviert
Netzwerkdienst auf DHCP setzen [CHANGE][PRIV][DISRUPT] sudo networksetup -setdhcp "Wi-Fi" Vorhandene manuelle IPv4-Konfiguration wird ersetzt

en0 und Wi-Fi sind Beispiele. Vorher müssen die tatsächliche Schnittstelle und der tatsächliche Netzwerkdienst bestimmt werden.

Vor einem Eingriff prüfen

Rollback-Beispiele

Änderung Rückfall
Wi-Fi ausgeschaltet Wi-Fi mit networksetup -setairportpower ... on wieder einschalten
Schnittstelle deaktiviert Schnittstelle mit ifconfig ... up wieder aktivieren
DHCP statt statischer IP gesetzt Dokumentierte IP-, Masken-, Router- und DNS-Werte wiederherstellen
Netzwerkumgebung gewechselt Vorherige Netzwerkumgebung wieder auswählen
Proxy verändert Dokumentierte Proxywerte wiederherstellen

Verifikation nach einer Änderung

networksetup -getinfo "Wi-Fi"
ifconfig en0
route -n get default
scutil --dns
ping -c 4 192.0.2.1
ping -c 4 1.1.1.1
dig example.com
nc -vz -w 3 example.com 443
19. Praktische macOS-Diagnosereihenfolge

Schritt 1 – macOS-Version erfassen

sw_vers

Schritt 2 – Netzwerkdienst und Schnittstelle zuordnen

networksetup -listallhardwareports
networksetup -listnetworkserviceorder

Schritt 3 – Schnittstellenstatus prüfen

ifconfig -a
netstat -ibn

Schritt 4 – IP-Konfiguration prüfen

networksetup -getinfo "Wi-Fi"
ipconfig getifaddr en0

Schritt 5 – Standardroute prüfen

route -n get default
route -n get 1.1.1.1

Schritt 6 – Nachbartabelle prüfen

arp -an
ndp -an

Schritt 7 – Standardgateway testen

ping -c 4 192.0.2.1

Schritt 8 – Externe IP-Adresse testen

ping -c 4 1.1.1.1

Schritt 9 – DNS-Konfiguration prüfen

scutil --dns
networksetup -getdnsservers "Wi-Fi"

Schritt 10 – DNS-Auflösung testen

dscacheutil -q host -a name example.com
dig example.com

Schritt 11 – Proxy und VPN prüfen

scutil --proxy
scutil --nwi
ifconfig -l | tr ' ' '\n' | grep '^utun'

Schritt 12 – Zielport testen

nc -vz -w 3 example.com 443

Schritt 13 – Lokale Ports prüfen

sudo lsof -nP -iTCP -sTCP:LISTEN

Schritt 14 – Netzwerkpfad prüfen

traceroute -n example.com

Schritt 15 – Netzwerkqualität messen

networkQuality -v

Schritt 16 – Firewall und Protokolle prüfen

/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
sudo pfctl -s info
sudo log show --last 30m --style compact

Diagnoselogik

Ergebnis Nächster Schwerpunkt
Schnittstelle fehlt Adapter, USB-/Thunderbolt-Verbindung oder Hardware prüfen
Schnittstelle inaktiv WLAN, Kabel, Netzwerkdienst oder Port prüfen
Keine passende IP-Adresse DHCP oder manuelle Konfiguration prüfen
Keine Standardroute Router, Dienstreihenfolge, VPN oder Konfiguration prüfen
Gateway nicht erreichbar Lokales Netz, WLAN, VLAN, Switch oder Router prüfen
Externe IP erreichbar, DNS-Name nicht Resolver, DNS-Server und Split-DNS prüfen
Ziel-IP erreichbar, Zielport nicht Dienst, Bind-Adresse und Firewall prüfen
Nur Anwendungen betroffen Proxy, TLS, Private Relay oder Network Extension prüfen
Falsche Route über utun VPN- beziehungsweise Filtersoftware prüfen
Schlechte WLAN-Werte Signal, Kanal, Rauschen, Roaming und Access Point prüfen

Kurzreferenz

Diagnoseziel macOS-Befehl
macOS-Version [RO] sw_vers
Hardwareports [RO] networksetup -listallhardwareports
Netzwerkdienste [RO] networksetup -listallnetworkservices
Dienstreihenfolge [RO] networksetup -listnetworkserviceorder
Netzwerkschnittstellen [RO] ifconfig -a
Schnittstellenstatistik [RO] netstat -ibn
IPv4-Adresse [RO] ipconfig getifaddr en0
Dienstinformationen [RO] networksetup -getinfo "Wi-Fi"
Standardroute [RO] route -n get default
Route zu einem Ziel [RO] route -n get 1.1.1.1
IPv4-Routingtabelle [RO] netstat -rn -f inet
ARP-Tabelle [RO] arp -an
IPv6-Nachbarn [RO] ndp -an
Gateway testen [TEST] ping -c 4 192.0.2.1
Netzwerkpfad [TEST] traceroute -n example.com
DNS-Konfiguration [RO] scutil --dns
DNS-Abfrage [TEST] dig example.com
Systemresolver testen [TEST] dscacheutil -q host -a name example.com
Proxykonfiguration [RO] scutil --proxy
Netzwerkstatus [RO] scutil --nwi
WLAN-Informationen [RO][PRIV] sudo wdutil info
Netzwerkqualität [TEST] networkQuality -v
Lauschende Ports [RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN
TCP-Port testen [TEST] nc -vz -w 3 example.com 443
Application Firewall [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
Packet Filter [RO][PRIV] sudo pfctl -s info
Systemprotokoll [RO][PRIV] sudo log show --last 30m --style compact

Veraltete beziehungsweise nicht mehr zuverlässige Werkzeuge

Werkzeug Bewertung
Privates airport-Kommandozeilenwerkzeug Auf aktuellen macOS-Versionen nicht als zuverlässiger Standard verwenden
ifconfig Unter macOS weiterhin Bestandteil des Systems und für Diagnose geeignet
netstat Unter macOS weiterhin für Routing-, Socket- und Schnittstellendiagnose verwendbar
wdutil Auf aktuellen macOS-Versionen für WLAN-Diagnose bevorzugen
Wireless Diagnostics Von Apple bereitgestelltes grafisches Diagnosewerkzeug

Merksatz

Die macOS-Netzwerkdiagnose folgt der Kette: Netzwerkdienst → Schnittstelle → Link → IP-Adresse → Nachbartabelle → Route → Gateway → DNS → Proxy/VPN → Zielport → lokaler Dienst → Firewall → Protokolle.

Quellen

2. Grundwerkzeuge und Befehle

2.5 Wireshark und TShark – Netzwerkverkehr aufzeichnen und analysieren

Ziel dieser Seite

Wireshark und TShark ermöglichen die detaillierte Untersuchung des Netzwerkverkehrs. Sie helfen unter anderem bei der Analyse von:

Ein Paketmitschnitt sollte erst dann begonnen werden, wenn die betroffenen Systeme, der ungefähre Fehlerzeitpunkt und der erwartete Kommunikationsweg bekannt sind.

Wichtig: Paketmitschnitte dürfen ausschließlich in Netzwerken und auf Systemen durchgeführt werden, für die eine entsprechende Berechtigung vorliegt. Aufzeichnungen können Benutzernamen, IP-Adressen, DNS-Anfragen, Sitzungsinformationen und unverschlüsselte Anwendungsdaten enthalten.

Kennzeichnungen

Kennzeichnung Bedeutung
[RO] Nur lesender beziehungsweise auswertender Befehl
[TEST] Aktiver Diagnose- oder Aufzeichnungsvorgang
[PRIV] Erhöhte Berechtigungen können erforderlich sein
[FILE] Der Befehl erstellt oder verarbeitet eine Datei
[SENS] Die Ausgabe oder Datei kann sensible Informationen enthalten
[DISRUPT] Der Vorgang kann Systeme oder Netzwerkverbindungen beeinflussen

1. Was ist der Unterschied zwischen Wireshark, TShark und Dumpcap?

Werkzeuge und Aufgaben anzeigen
Werkzeug Aufgabe Typischer Einsatz
Wireshark Grafische Paketaufzeichnung und Analyse Interaktive Fehlersuche am Arbeitsplatz
TShark Kommandozeilenversion der Wireshark-Analyse Server, Skripte und automatisierte Auswertungen
Dumpcap Spezialisierte Paketaufzeichnung Ressourcenarme oder länger laufende Mitschnitte
Capinfos Zeigt Eigenschaften einer Mitschnittdatei Kontrolle von Dateiformat, Zeitraum und Paketanzahl
Mergecap Führt mehrere Mitschnittdateien zusammen Gemeinsame Analyse mehrerer Aufzeichnungen
Editcap Bearbeitet oder verkleinert Mitschnittdateien Zeitbereiche oder einzelne Pakete extrahieren

Wireshark und TShark verwenden dieselben Protokoll-Dissektoren und dieselbe Display-Filter-Sprache. Die eigentliche Paketaufzeichnung wird üblicherweise von Dumpcap durchgeführt.

Grundlegende Versionsprüfung

Aufgabe Befehl
Wireshark-Version anzeigen [RO] wireshark --version
TShark-Version anzeigen [RO] tshark --version
Dumpcap-Version anzeigen [RO] dumpcap --version
Capinfos-Version anzeigen [RO] capinfos --version

2. Welche Voraussetzungen müssen vor einem Paketmitschnitt geprüft werden?

Vorbedingungen und Berechtigungen anzeigen

Vor dem Mitschnitt müssen mindestens folgende Punkte geklärt werden:

Prüffrage Bedeutung
Welches System ist betroffen? Bestimmt den geeigneten Aufzeichnungspunkt
Welche Gegenstelle wird angesprochen? Ermöglicht einen gezielten Host- oder Portfilter
Wann tritt der Fehler auf? Verhindert unnötig lange Aufzeichnungen
Welches Protokoll wird erwartet? Erleichtert die spätere Analyse
Welche Schnittstelle transportiert den Verkehr? Verhindert einen Mitschnitt auf dem falschen Adapter
Ist der Mitschnitt autorisiert? Schützt personenbezogene und betriebliche Daten
Gibt es ausreichend Speicherplatz? Verhindert eine volle Festplatte
Sind die Systemuhren synchronisiert? Ermöglicht den Vergleich mit Server- und Anwendungslogs

Betriebssystemspezifische Hinweise

Betriebssystem Typische Voraussetzung
Windows Für Live-Mitschnitte wird normalerweise Npcap benötigt
Linux Der Benutzer benötigt Zugriff auf Dumpcap beziehungsweise die Capture-Gruppe; alternativ sind erhöhte Rechte erforderlich
macOS Die Wireshark-Installation richtet üblicherweise die notwendigen BPF-Berechtigungen ein
Remote-Server Häufig wird TShark oder Dumpcap ohne grafische Oberfläche verwendet

Wireshark oder TShark sollten nicht dauerhaft als Administrator beziehungsweise root ausgeführt werden. Besser ist eine gezielte Berechtigung ausschließlich für die Paketaufzeichnung.

3. Wie wird die richtige Netzwerkschnittstelle ausgewählt?

Schnittstellen ermitteln und überprüfen

Verfügbare Capture-Schnittstellen anzeigen

[RO] tshark -D

Alternativ:

[RO] dumpcap -D

Beispielhafte Ausgabe:

1. \Device\NPF_{...} (Ethernet)
2. \Device\NPF_{...} (WLAN)
3. \Device\NPF_Loopback (Adapter for loopback traffic capture)

Unter Linux oder macOS können Namen wie diese erscheinen:

1. enp0s31f6
2. wlan0
3. lo

oder:

1. en0
2. en1
3. lo0

Die Schnittstelle kann über ihre Nummer oder ihren Namen ausgewählt werden:

[TEST][PRIV] tshark -i 1

[TEST][PRIV] tshark -i en0

Prüfmethode

  1. Die vermutete Schnittstelle auswählen.
  2. Einen kurzen Mitschnitt starten.
  3. Einen bekannten und autorisierten Test erzeugen, beispielsweise eine DNS-Abfrage oder einen Ping.
  4. Prüfen, ob die erwarteten Pakete erscheinen.
  5. Erst danach den eigentlichen Fehler reproduzieren.

Typische Fehler bei der Schnittstellenauswahl

Ein leerer Mitschnitt beweist nicht, dass kein Netzwerkverkehr vorhanden war. Zuerst müssen Schnittstelle, Aufzeichnungspunkt, Berechtigung und Capture-Filter geprüft werden.

4. Wie wird mit Wireshark ein kontrollierter Mitschnitt erstellt?

Vorgehensweise in der grafischen Oberfläche anzeigen

Empfohlener Ablauf

  1. Wireshark starten.
  2. Die Schnittstelle anhand der Paketaktivität und der Systemkonfiguration auswählen.
  3. Unter Capture → Options die Schnittstelle kontrollieren.
  4. Falls erforderlich einen Capture-Filter eintragen.
  5. Die Aufzeichnung starten.
  6. Den Fehler möglichst einmal gezielt reproduzieren.
  7. Die Aufzeichnung sofort danach beenden.
  8. Die Datei im Format pcapng speichern.
  9. Zeitpunkt, Client, Server, Testschritt und beobachtetes Verhalten dokumentieren.
  10. Für die Analyse Display-Filter verwenden.

Empfohlene Dokumentation

Feld Beispiel
Startzeit 2026-07-31 14:02:10 CEST
Endzeit 2026-07-31 14:03:05 CEST
Client 192.0.2.10
Server 198.51.100.20
Benutzer Max Mustermann
Test Anmeldung an der Beispielanwendung
Erwartung Anmeldeseite wird geladen
Beobachtung Verbindungsabbruch nach etwa fünf Sekunden
Capture-Schnittstelle Ethernet 1
Capture-Filter host 198.51.100.20

Die Aufzeichnung sollte so kurz und zielgerichtet wie möglich sein. Dadurch sinken Speicherbedarf, Analyseaufwand und Datenschutzrisiko.

5. Was ist der Unterschied zwischen Capture-Filter und Display-Filter?

Filterarten und wichtige Unterschiede anzeigen
Eigenschaft Capture-Filter Display-Filter
Zeitpunkt Während der Aufzeichnung Während oder nach der Analyse
Wirkung Nicht passende Pakete werden nicht aufgezeichnet Pakete bleiben in der Datei, werden aber ausgeblendet
Sprache libpcap-/BPF-Syntax Wireshark-Display-Filter-Syntax
TShark-Option -f -Y
Nachträglich änderbar Nein Ja
Leistungsbedarf Vergleichsweise gering Bei Live-Analyse möglicherweise höher
Beispiel tcp port 443 tcp.port == 443

Capture-Filter

tcp port 443

Display-Filter

tcp.port == 443

Diese beiden Filter dürfen nicht verwechselt werden.

Ein Capture-Filter verwirft alle nicht passenden Pakete bereits bei der Aufzeichnung. Fehlende Pakete können später nicht wiederhergestellt werden.

Ein Display-Filter verändert die gespeicherte Aufzeichnung nicht. Er kann jederzeit geändert oder entfernt werden.

Für eine Live-Aufzeichnung, die gleichzeitig mit -w gespeichert wird, sollte die Eingrenzung mit -f erfolgen. Ein mit -Y angegebener Display-Filter ist dafür kein Ersatz.

6. Welche Capture-Filter werden häufig verwendet?

Capture-Filter-Tabelle anzeigen
Aufgabe Capture-Filter
Verkehr eines IPv4-Hosts host 192.0.2.10
Nur Verkehr von einem Host src host 192.0.2.10
Nur Verkehr zu einem Host dst host 192.0.2.10
Verkehr eines IPv4-Netzes net 192.0.2.0/24
TCP-Port 443 tcp port 443
UDP-Port 53 udp port 53
Zielport 443 tcp dst port 443
Quellport 443 tcp src port 443
DNS über TCP oder UDP port 53
DHCPv4 udp port 67 or udp port 68
HTTP oder HTTPS tcp port 80 or tcp port 443
ICMPv4 icmp
ICMPv6 icmp6
ARP arp
Host und Port kombinieren host 192.0.2.10 and tcp port 443
Zwei Hosts host 192.0.2.10 or host 198.51.100.20
Host ausschließen not host 192.0.2.10
SSH-Verkehr ausschließen not tcp port 22
Broadcast- oder Multicastverkehr ether broadcast or ether multicast

Beispiel: nur HTTPS-Verkehr zu einem Testserver aufzeichnen

[TEST][PRIV][FILE][SENS] tshark -i 1 -f "host 198.51.100.20 and tcp port 443" -a duration:60 -w https-test.pcapng

Wichtige Filterregeln

7. Welche Display-Filter werden häufig verwendet?

Display-Filter-Tabelle anzeigen
Aufgabe Display-Filter
IPv4-Adresse als Quelle oder Ziel ip.addr == 192.0.2.10
Nur IPv4-Quelle ip.src == 192.0.2.10
Nur IPv4-Ziel ip.dst == 192.0.2.10
IPv4-Netz ip.addr == 192.0.2.0/24
IPv6-Adresse ipv6.addr == 2001:db8::10
TCP-Port tcp.port == 443
UDP-Port udp.port == 53
Mehrere TCP-Ports tcp.port in {80, 443, 8080}
ARP arp
ICMPv4 icmp
ICMPv6 icmpv6
DNS dns
Bestimmter DNS-Name dns.qry.name == "example.com"
DNS-Fehlerantworten dns.flags.response == 1 && dns.flags.rcode != 0
DHCPv4 dhcp
HTTP-Anfragen http.request
TLS-Handshake tls.handshake
TCP-SYN ohne ACK tcp.flags.syn == 1 && tcp.flags.ack == 0
TCP-RST tcp.flags.reset == 1
TCP-FIN tcp.flags.fin == 1
TCP-Wiederholungsübertragung tcp.analysis.retransmission
TCP-Fast-Retransmission tcp.analysis.fast_retransmission
Duplicate ACK tcp.analysis.duplicate_ack
Vermutetes verlorenes Segment tcp.analysis.lost_segment
TCP-Zero-Window tcp.analysis.zero_window
Bestimmte Paketnummer frame.number == 100
Pakete ab Sekunde 10 frame.time_relative >= 10
Zeitbereich von Sekunde 10 bis 20 frame.time_relative >= 10 && frame.time_relative <= 20
Große Frames frame.len > 1500
Expert-Information mit Fehlerstufe _ws.expert.severity == error

Filter kombinieren

ip.addr == 192.0.2.10 && tcp.port == 443

dns || dhcp

ip.addr == 192.0.2.10 && (tcp.analysis.retransmission || tcp.analysis.duplicate_ack)

Wichtiger Hinweis zu booleschen Feldern

Dieser Filter prüft nur, ob das Feld vorhanden ist:

tcp.flags.syn

Um ausschließlich gesetzte SYN-Flags zu finden, muss der Wert geprüft werden:

tcp.flags.syn == 1

8. Wie werden mit TShark kurze und kontrollierte Mitschnitte erstellt?

TShark-Aufzeichnungsbefehle anzeigen
Aufgabe Befehl
Schnittstellen anzeigen [RO] tshark -D
Live-Verkehr auf Schnittstelle 1 anzeigen [TEST][PRIV][SENS] tshark -i 1
Genau 100 Pakete erfassen [TEST][PRIV][FILE][SENS] tshark -i 1 -c 100 -w capture.pcapng
60 Sekunden aufzeichnen [TEST][PRIV][FILE][SENS] tshark -i 1 -a duration:60 -w capture.pcapng
Auf 100.000 KiB Dateigröße begrenzen [TEST][PRIV][FILE][SENS] tshark -i 1 -a filesize:100000 -w capture.pcapng
HTTPS-Verkehr aufzeichnen [TEST][PRIV][FILE][SENS] tshark -i 1 -f "tcp port 443" -a duration:60 -w https.pcapng
Verkehr eines Hosts aufzeichnen [TEST][PRIV][FILE][SENS] tshark -i 1 -f "host 192.0.2.10" -a duration:60 -w host-test.pcapng
DNS-Verkehr aufzeichnen [TEST][PRIV][FILE][SENS] tshark -i 1 -f "port 53" -a duration:60 -w dns-test.pcapng

-c 100 beendet die Aufzeichnung nach 100 erfassten Paketen.

-a duration:60 beendet die Aufzeichnung nach 60 Sekunden.

-a filesize:100000 beendet sie nach ungefähr 100.000 KiB.

-w capture.pcapng schreibt die Rohpakete in eine Mitschnittdatei. Es handelt sich nicht um eine normale Textdatei.

Kontrollierter Beispielablauf

[RO] tshark -D

[TEST][PRIV][FILE][SENS] tshark -i 1 -f "host 198.51.100.20 and tcp port 443" -a duration:60 -w https-test.pcapng

Während der 60 Sekunden wird der Fehler genau einmal reproduziert. Anschließend wird die Datei offline ausgewertet.

9. Wie werden vorhandene Mitschnittdateien mit TShark ausgewertet?

Offline-Analyse anzeigen
Aufgabe Befehl
Datei einlesen [RO][FILE][SENS] tshark -r capture.pcapng
Namensauflösung deaktivieren [RO][FILE][SENS] tshark -n -r capture.pcapng
Nur DNS anzeigen [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "dns"
Nur TCP-Port 443 anzeigen [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "tcp.port == 443"
Paketdetails anzeigen [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "frame.number == 100" -V
Hexadezimaldaten anzeigen [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "frame.number == 100" -x
Nur bestimmte Protokolldetails [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "dns" -O dns

Die Option -n deaktiviert die Namensauflösung. Dadurch werden:

Pakete aus einer Datei filtern und in eine neue Datei schreiben

[RO][FILE][SENS] tshark -r capture.pcapng -Y "ip.addr == 192.0.2.10" -w host-only.pcapng

Dieser Befehl liest eine vorhandene Datei, wendet einen Display-Filter an und schreibt die passenden Pakete in eine neue Mitschnittdatei.

10. Wie werden gezielt Felder oder CSV-Daten ausgegeben?

Feldextraktion und CSV-Ausgabe anzeigen

Mit -T fields wird eine tabellarische Feldausgabe erzeugt. Die gewünschten Felder werden mit -e angegeben.

DNS-Abfragen extrahieren

[RO][FILE][SENS] tshark -n -r capture.pcapng -Y "dns.qry.name" -T fields -e frame.time -e ip.src -e ip.dst -e dns.qry.name

TCP-Verbindungen untersuchen

[RO][FILE][SENS] tshark -n -r capture.pcapng -Y "tcp" -T fields -e frame.number -e frame.time_relative -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport -e tcp.flags

CSV-Ausgabe mit Kopfzeile

[RO][FILE][SENS] tshark -n -r capture.pcapng -Y "dns" -T fields -E header=y -E separator=, -E quote=d -e frame.time -e ip.src -e ip.dst -e dns.qry.name

Bedeutung der Optionen

Option Bedeutung
-T fields Gibt ausschließlich ausgewählte Felder aus
-e Feldname Fügt ein Feld zur Ausgabe hinzu
-E header=y Schreibt die Feldnamen als Kopfzeile
-E separator=, Verwendet ein Komma als Trennzeichen
-E quote=d Setzt Feldwerte in doppelte Anführungszeichen

Bei einem deutschen Tabellenkalkulationsprogramm kann das Komma als Dezimal- oder Listentrennzeichen interpretiert werden. Die Importoptionen müssen deshalb bewusst kontrolliert werden.

11. Welche TShark-Statistiken helfen bei der schnellen Übersicht?

Statistikbefehle anzeigen
Aufgabe Befehl
Protokollhierarchie [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z io,phs
TCP-Konversationen [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z conv,tcp
UDP-Konversationen [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z conv,udp
IPv4-Endpunkte [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z endpoints,ip
IPv6-Endpunkte [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z endpoints,ipv6
Ethernet-Endpunkte [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z endpoints,eth
Statistik pro Sekunde [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z io,stat,1
DNS-Statistik [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z dns,tree

Bedeutung

In Wireshark befinden sich entsprechende Ansichten überwiegend im Menü Statistics.

12. Wie werden große oder länger laufende Mitschnitte begrenzt?

Ringpuffer und Dateibegrenzung anzeigen

Ein unbegrenzter Mitschnitt kann eine Festplatte vollständig füllen. Für längere Aufzeichnungen sollte deshalb ein Ringpuffer verwendet werden.

Zwölf Dateien mit jeweils fünf Minuten Aufzeichnungsdauer

[TEST][PRIV][FILE][SENS] tshark -i 1 -b duration:300 -b files:12 -w capture.pcapng

Damit entsteht ein Ringpuffer für ungefähr eine Stunde:

12 Dateien × 5 Minuten = 60 Minuten

Wenn die zwölfte Datei vollständig ist, wird die älteste Datei überschrieben.

Fünf Dateien mit jeweils ungefähr 100.000 KiB

[TEST][PRIV][FILE][SENS] tshark -i 1 -b filesize:100000 -b files:5 -w capture.pcapng

Wichtige Regeln

13. Wie werden Mitschnittdateien geprüft und zusammengeführt?

Capinfos und Mergecap anzeigen

Dateieigenschaften anzeigen

[RO][FILE][SENS] capinfos capture.pcapng

Capinfos zeigt unter anderem:

Kompakte tabellarische Ausgabe

[RO][FILE][SENS] capinfos -T capture.pcapng

Mehrere Dateien zusammenführen

[RO][FILE][SENS] mergecap -w merged.pcapng part1.pcapng part2.pcapng

Mergecap ordnet Pakete standardmäßig anhand ihrer Zeitstempel ein. Deshalb müssen die Systemuhren der beteiligten Aufzeichnungssysteme möglichst genau synchronisiert sein.

Vor dem Zusammenführen sollten die Zeiträume geprüft werden:

[RO][FILE][SENS] capinfos part1.pcapng part2.pcapng

14. Wie wird eine TCP-Verbindung systematisch analysiert?

TCP-Diagnose anzeigen

Schritt 1: Verbindungsaufbau suchen

tcp.flags.syn == 1 && tcp.flags.ack == 0

Ein regulärer TCP-Verbindungsaufbau besteht vereinfacht aus:

Schritt Richtung Flags
1 Client → Server SYN
2 Server → Client SYN, ACK
3 Client → Server ACK

Interpretation

Beobachtung Mögliche Ursache
SYN wird wiederholt, aber kein SYN/ACK sichtbar Server nicht erreichbar, Firewall verwirft Pakete, Routingproblem oder falscher Aufzeichnungspunkt
SYN wird mit RST beantwortet Zielsystem erreichbar, aber Port geschlossen oder Dienst lehnt Verbindung ab
SYN/ACK sichtbar, abschließendes ACK fehlt Rückwegproblem, Clientproblem oder Filter-/Aufzeichnungslücke
Drei-Wege-Handshake vollständig Grundlegender TCP-Verbindungsaufbau war erfolgreich
RST während der Sitzung Verbindung wurde von einem Endpunkt oder einem Zwischensystem abgebrochen
FIN/ACK-Sequenz Geordneter Verbindungsabbau

Hilfreiche Filter

tcp.flags.reset == 1

tcp.analysis.retransmission

tcp.analysis.duplicate_ack

tcp.analysis.zero_window

tcp.analysis.window_full

TCP-Stream isolieren

Nach Auswahl eines TCP-Pakets kann in Wireshark verwendet werden:

Analyze → Follow → TCP Stream

Alternativ lässt sich nach einer Streamnummer filtern:

tcp.stream == 0

Eine TCP-Wiederholungsübertragung ist zunächst eine Beobachtung und noch keine eindeutige Ursache. Sie kann durch echten Paketverlust, verspätete Pakete, einen unvollständigen Mitschnitt, asymmetrisches Routing oder den Aufzeichnungspunkt entstehen.

15. Wie werden DNS-Probleme untersucht?

DNS-Diagnose anzeigen

Grundfilter

dns

Nur DNS-Anfragen

dns.flags.response == 0

Nur DNS-Antworten

dns.flags.response == 1

Bestimmten Namen untersuchen

dns.qry.name == "example.com"

Fehlerantworten anzeigen

dns.flags.response == 1 && dns.flags.rcode != 0

Typische Beobachtungen

Beobachtung Mögliche Bedeutung
Anfrage sichtbar, aber keine Antwort DNS-Server nicht erreichbar, Paketverlust, Firewall oder falscher Rückweg
Antwort NXDOMAIN Der angefragte Name existiert aus Sicht des antwortenden DNS-Servers nicht
Antwort SERVFAIL DNS-Server konnte die Anfrage nicht erfolgreich verarbeiten
Mehrere identische Anfragen Antwort fehlt, kommt verspätet oder wird vom Client nicht akzeptiert
Antwort enthält unerwartete Adresse Falscher DNS-Eintrag, falscher DNS-Server, Split-DNS oder Cacheproblem
Lange Zeit zwischen Anfrage und Antwort Verzögerter DNS-Server, Weiterleitungs- oder Netzwerkproblem

TShark-Auswertung

[RO][FILE][SENS] tshark -n -r capture.pcapng -Y "dns" -T fields -e frame.time_relative -e ip.src -e ip.dst -e dns.id -e dns.qry.name -e dns.flags.response -e dns.flags.rcode

Bei DNS-Problemen müssen Paketmitschnitt und lokale Resolver-Konfiguration gemeinsam betrachtet werden. Ein korrekter DNS-Austausch beweist noch nicht, dass die Anwendung das Ergebnis richtig verarbeitet hat.

16. Wie werden DHCP-Probleme untersucht?

DHCP-Diagnose anzeigen

Display-Filter

dhcp

Capture-Filter

udp port 67 or udp port 68

Der reguläre DHCPv4-Ablauf wird häufig als DORA bezeichnet:

Reihenfolge Nachricht Richtung
1 Discover Client sucht DHCP-Server
2 Offer DHCP-Server bietet eine Konfiguration an
3 Request Client fordert das Angebot an
4 ACK Server bestätigt die Zuweisung

Interpretation

Beobachtung Mögliche Ursache
Discover, aber kein Offer DHCP-Server nicht erreichbar, Relay fehlt, VLAN falsch oder Adresspool erschöpft
Offer sichtbar, aber kein Request Client akzeptiert das Angebot nicht oder Mitschnitt ist unvollständig
Request, aber kein ACK Serverproblem, Relayproblem oder Paketverlust
DHCP NAK Angeforderte Adresse oder Konfiguration wurde abgelehnt
Mehrere unterschiedliche Offers Mehrere DHCP-Server antworten; möglicherweise unerwünschter DHCP-Server
DORA vollständig DHCP-Kommunikation war grundsätzlich erfolgreich

Bei VLAN-übergreifendem DHCP muss zusätzlich der DHCP-Relay beziehungsweise IP-Helper untersucht werden.

17. Wie werden TLS- und HTTPS-Probleme untersucht?

TLS-Diagnose anzeigen

TLS-Verkehr

tls

TLS-Handshake

tls.handshake

TLS-Warnungen und Fehler

tls.alert_message

TCP-Port 443 zusammen mit TLS

tcp.port == 443 && tls

Typischer vereinfachter Ablauf

  1. TCP-Verbindung wird aufgebaut.
  2. Client sendet einen TLS-ClientHello.
  3. Server sendet einen TLS-ServerHello.
  4. Zertifikats- und Schlüsselparameter werden ausgetauscht.
  5. Die verschlüsselte Anwendungskommunikation beginnt.

Beobachtungen

Beobachtung Mögliche Bedeutung
TCP-Handshake fehlt Noch kein TLS-Problem; zuerst Netzwerk und TCP untersuchen
ClientHello ohne ServerHello Server, Firewall, TLS-Proxy oder Rückweg prüfen
TLS Alert TLS-Seite meldet einen Protokoll- oder Zertifikatsfehler
ServerHello vorhanden, späterer Abbruch Zertifikat, Cipher Suites, TLS-Version oder Anwendung prüfen
Verschlüsselte Application Data TLS-Verbindung wurde mindestens bis zur verschlüsselten Datenübertragung aufgebaut

Der Inhalt moderner HTTPS-Verbindungen ist verschlüsselt. Ohne ausdrücklich autorisierte Schlüssel- oder Debug-Daten sind hauptsächlich Metadaten, TCP-Verhalten und Teile des TLS-Handshakes sichtbar.

18. Welche Analysefehler treten bei Wireshark besonders häufig auf?

Fehlinterpretationen und Gegenmaßnahmen anzeigen
Fehler Warum problematisch? Richtige Reaktion
Capture- und Display-Filter verwechselt Erwartete Pakete werden nicht gespeichert oder Filter funktioniert nicht Syntax und Einsatzzeitpunkt prüfen
Falsche Schnittstelle gewählt Relevanter Verkehr fehlt Kurzen Kontrollmitschnitt durchführen
Zu enger Capture-Filter Entscheidende Begleitpakete fehlen Zunächst breiter und zeitlich begrenzt aufzeichnen
Zu langer Mitschnitt Große Dateien und hoher Analyseaufwand Fehler gezielt reproduzieren und sofort stoppen
Namensauflösung aktiviert Adressen erscheinen verändert oder Analyse erzeugt zusätzliche Anfragen Für reproduzierbare CLI-Ausgaben -n verwenden
Jedes TCP-Retransmission-Ereignis als Paketverlust bewertet Analyseindikatoren können durch unvollständige Mitschnitte entstehen Sequenznummern, Aufzeichnungspunkt und Gegenmitschnitt prüfen
Rote oder schwarze Markierung als Beweis betrachtet Farben beruhen auf konfigurierten Regeln Paketdetails und tatsächliche Felder untersuchen
Checksum-Fehler sofort als Netzfehler bewertet Checksum Offloading kann auf dem sendenden Host scheinbar fehlerhafte Prüfsummen erzeugen Gegenstelle oder Netzwerkpfad vergleichen
Fehlende Pakete als Beweis für eine Firewall gewertet Falscher Aufzeichnungspunkt oder asymmetrischer Weg möglich Auf beiden Seiten oder an einem geeigneten Übergabepunkt mitschneiden
Promiscuous Mode überschätzt Ein Switch sendet fremden Unicast-Verkehr nicht automatisch an jeden Port Autorisierten Mirror-/SPAN-Port oder TAP verwenden
Zeitstempel verschiedener Systeme ungeprüft verglichen Abweichende Systemuhren verfälschen die Reihenfolge NTP-Status und Zeitzonen prüfen
Verschlüsselten Inhalt erwartet TLS schützt die Nutzdaten Handshake, Metadaten und autorisierte Logs auswerten

Checksum Offloading

Bei ausgehenden Paketen kann das Betriebssystem die endgültige Prüfsumme erst durch die Netzwerkkarte berechnen lassen. Ein Mitschnitt auf dem sendenden System kann das Paket vor dieser Berechnung erfassen. Wireshark kennzeichnet die Prüfsumme dann möglicherweise als fehlerhaft, obwohl sie auf dem Übertragungsmedium korrekt war.

TCP-Analysekennzeichnungen

Filter wie tcp.analysis.retransmission sind Ergebnisse der Wireshark-Analyse. Sie sind wertvolle Hinweise, aber keine automatische Ursachenfeststellung.

19. Wo muss der Paketmitschnitt durchgeführt werden?

Geeigneten Aufzeichnungspunkt bestimmen

Der geeignete Mitschnittpunkt hängt vom vermuteten Fehlerbereich ab.

Vermuteter Fehler Geeigneter Mitschnittpunkt
Anwendung auf dem Client Direkt auf dem Client
Server antwortet nicht Client und möglichst Server
Firewall oder Routing Vor und hinter dem betroffenen Übergang
DHCP über mehrere VLANs Client-VLAN, Relay und Servernetz
DNS-Auflösung Client und gegebenenfalls DNS-Server
VPN-Verbindung Physische und virtuelle VPN-Schnittstelle
Containerkommunikation Host-, Bridge- und gegebenenfalls Containerschnittstelle
Virtuelle Maschine Gastbetriebssystem und gegebenenfalls virtueller Switch
Sporadischer Paketverlust Beide Endpunkte oder geeigneter Netzwerk-TAP

In einem geswitchten Ethernet-Netz sieht ein Endgerät normalerweise:

Für fremden Unicastverkehr ist ein autorisierter Mirror-/SPAN-Port, Netzwerk-TAP oder ein Mitschnitt direkt auf einem Endpunkt erforderlich.

Vergleichsmethode

Client-Mitschnitt → Netzwerkübergang → Server-Mitschnitt

Wenn ein Paket im Client-Mitschnitt vorhanden ist, aber im Server-Mitschnitt fehlt, liegt die Unterbrechung wahrscheinlich zwischen diesen Punkten. Für eine belastbare Aussage müssen Filter, Zeitstempel und Aufzeichnungsvollständigkeit geprüft werden.

20. Wie sieht ein sicherer Diagnoseablauf mit Wireshark oder TShark aus?

Empfohlene Schrittfolge anzeigen

Vorbereitung

  1. Störung und erwartetes Verhalten dokumentieren.
  2. Client, Server, IP-Adressen, Ports und Protokolle bestimmen.
  3. Fehlerzeitpunkt und reproduzierbaren Test festlegen.
  4. Berechtigung für den Mitschnitt prüfen.
  5. Zeitsynchronisation der beteiligten Systeme prüfen.
  6. Speicherort und Speicherplatz kontrollieren.

Aufzeichnung

  1. Richtige Schnittstelle mit tshark -D oder Wireshark bestimmen.
  2. Einen kurzen Kontrollmitschnitt durchführen.
  3. Einen angemessenen Capture-Filter setzen.
  4. Zeit-, Paket- oder Dateigrößenbegrenzung festlegen.
  5. Aufzeichnung starten.
  6. Fehler genau einmal reproduzieren.
  7. Aufzeichnung sofort beenden.
  8. Datei eindeutig benennen und sicher speichern.

Analyse

  1. Zuerst Protokollhierarchie, Endpunkte und Konversationen prüfen.
  2. Relevante Client-Server-Kommunikation isolieren.
  3. ARP, DHCP und DNS vor TCP und Anwendung betrachten.
  4. TCP-Verbindungsaufbau, Abbruch und Wiederholungen prüfen.
  5. Anschließend TLS- oder Anwendungsprotokoll untersuchen.
  6. Zeitstempel mit Server-, Firewall- und Anwendungslogs vergleichen.
  7. Beobachtung und mögliche Ursache voneinander trennen.

Validierung

  1. Hypothese durch einen kontrollierten Vergleichstest prüfen.
  2. Falls erforderlich, Mitschnitte an zwei Punkten vergleichen.
  3. Nach einer Änderung denselben Test erneut durchführen.
  4. Ergebnis, Änderung und Nachweis dokumentieren.

21. Wie müssen Paketmitschnitte geschützt werden?

Datenschutz- und Sicherheitsregeln anzeigen

Paketmitschnitte können enthalten:

Mindestmaßnahmen

Das Öffnen von Follow TCP Stream, Follow HTTP Stream oder ähnlichen Ansichten kann zusammenhängende Anwendungsdaten sichtbar machen. Diese Funktionen dürfen deshalb nur bei entsprechender Berechtigung verwendet werden.

22. Kurzreferenz

Die wichtigsten Befehle und Filter anzeigen

TShark-Befehle

Aufgabe Befehl
Version [RO] tshark --version
Schnittstellen [RO] tshark -D
100 Pakete aufzeichnen [TEST][PRIV][FILE][SENS] tshark -i 1 -c 100 -w capture.pcapng
60 Sekunden aufzeichnen [TEST][PRIV][FILE][SENS] tshark -i 1 -a duration:60 -w capture.pcapng
Capture-Filter anwenden [TEST][PRIV][FILE][SENS] tshark -i 1 -f "tcp port 443" -a duration:60 -w capture.pcapng
Datei lesen [RO][FILE][SENS] tshark -n -r capture.pcapng
Display-Filter anwenden [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "dns"
Protokollhierarchie [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z io,phs
TCP-Konversationen [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z conv,tcp
IPv4-Endpunkte [RO][FILE][SENS] tshark -n -r capture.pcapng -q -z endpoints,ip
Dateiinformationen [RO][FILE][SENS] capinfos capture.pcapng
Dateien zusammenführen [RO][FILE][SENS] mergecap -w merged.pcapng part1.pcapng part2.pcapng

Wichtige Capture-Filter

Aufgabe Filter
Host host 192.0.2.10
Netz net 192.0.2.0/24
HTTPS tcp port 443
DNS port 53
DHCP udp port 67 or udp port 68
ICMPv4 icmp
ICMPv6 icmp6
ARP arp

Wichtige Display-Filter

Aufgabe Filter
Host ip.addr == 192.0.2.10
HTTPS-Port tcp.port == 443
DNS dns
DHCP dhcp
TLS-Handshake tls.handshake
TCP-Verbindungsbeginn tcp.flags.syn == 1 && tcp.flags.ack == 0
TCP-Abbruch tcp.flags.reset == 1
Wiederholungsübertragung tcp.analysis.retransmission
Duplicate ACK tcp.analysis.duplicate_ack
TCP-Stream tcp.stream == 0

Merksätze

Quellen

2. Grundwerkzeuge und Befehle

2.6 tcpdump und Capture-Filter – Paketmitschnitte im Terminal

Ziel dieser Seite

tcpdump ist ein Kommandozeilenwerkzeug zum Aufzeichnen und Anzeigen von Netzwerkpaketen. Es eignet sich besonders für:

tcpdump verwendet die Capture-Filter-Sprache von libpcap. Diese Filter bestimmen bereits während des Mitschnitts, welche Pakete verarbeitet und gespeichert werden.

Wichtig: Ein Capture-Filter lässt sich nachträglich nicht rückgängig machen. Pakete, die nicht zum Filter passen, werden nicht in die Mitschnittdatei aufgenommen.

Kennzeichnungen

Kennzeichnung Bedeutung
[RO] Nur lesender beziehungsweise auswertender Befehl
[TEST] Aktiver Diagnose- oder Aufzeichnungsvorgang
[PRIV] Erhöhte Berechtigungen können erforderlich sein
[FILE] Der Befehl erstellt oder verarbeitet eine Datei
[SENS] Ausgabe oder Datei kann sensible Informationen enthalten
[CHANGE] Der Befehl verändert eine Einstellung oder Datei
[DISRUPT] Der Vorgang kann Netzwerk oder Systembetrieb beeinflussen

1. Auf welchen Betriebssystemen kann tcpdump verwendet werden?

Betriebssystemübersicht anzeigen
Betriebssystem Verfügbarkeit Typischer Aufruf
Linux Meist über die Paketverwaltung installierbar sudo tcpdump
macOS Standardmäßig vorhanden sudo tcpdump
FreeBSD/OpenBSD/NetBSD Üblicherweise vorhanden doas tcpdump oder sudo tcpdump
Windows Nicht Bestandteil von Windows Vorzugsweise TShark oder Wireshark mit Npcap
Netzwerk-Appliance Häufig vorhanden, aber herstellerabhängig Herstellerdokumentation beachten
Container Nur mit passenden Netzwerk- und Capture-Berechtigungen Meist besser auf dem Container-Host mitschneiden

Version prüfen

[RO] tcpdump --version

Die Ausgabe nennt normalerweise sowohl die tcpdump- als auch die libpcap-Version.

Linux: Installation prüfen

[RO] command -v tcpdump

macOS: Installationspfad prüfen

[RO] command -v tcpdump

Windows

Unter Windows sollte für eine vergleichbare Aufgabe normalerweise TShark verwendet werden:

[RO] tshark --version

[RO] tshark -D

WinDump existiert als tcpdump-ähnliches Werkzeug für Windows, ist aber kein Bestandteil der aktuellen Windows-Bordmittel. Für ein modernes Administrationsumfeld sind Wireshark und TShark mit Npcap in der Regel die besser dokumentierte Lösung.

2. Welche Berechtigungen benötigt tcpdump?

Capture-Berechtigungen und Sicherheitsprinzip anzeigen

Das Lesen von Netzwerkpaketen erfordert in der Regel besondere Betriebssystemberechtigungen. Ein normaler Benutzer darf deshalb häufig keinen Live-Mitschnitt starten.

Typischer Aufruf unter Linux und macOS

[TEST][PRIV][SENS] sudo tcpdump

Das Lesen einer bereits vorhandenen Mitschnittdatei benötigt normalerweise keine Capture-Berechtigung:

[RO][FILE][SENS] tcpdump -r capture.pcap

Sicherheitsprinzip

Je nach Linux-Distribution kann tcpdump mit Linux-Capabilities oder einer herstellerspezifischen Berechtigungsregel ausgestattet sein. Solche Änderungen dürfen nicht pauschal aus fremden Anleitungen übernommen werden. Vorher müssen Sicherheitsrichtlinie, Paketquelle und bestehende Berechtigungen geprüft werden.

3. Wie werden Schnittstellen ermittelt und ausgewählt?

Schnittstellenbefehle anzeigen

Mit tcpdump verfügbare Capture-Schnittstellen anzeigen

[RO] tcpdump -D

Alternativ:

[RO] tcpdump --list-interfaces

Beispielhafte Schnittstellennamen:

System Typische Namen
Linux eth0, ens18, enp3s0, wlan0, lo
macOS en0, en1, lo0, utun0
Container-Host docker0, br-..., veth...
VPN tun0, tap0, wg0, utun...

Bestimmte Schnittstelle verwenden

[TEST][PRIV][SENS] sudo tcpdump -i eth0

[TEST][PRIV][SENS] sudo tcpdump -i en0

Loopbackverkehr aufzeichnen

Linux:

[TEST][PRIV][SENS] sudo tcpdump -i lo

macOS:

[TEST][PRIV][SENS] sudo tcpdump -i lo0

Mehrere reguläre Schnittstellen erfassen

[TEST][PRIV][SENS] sudo tcpdump -i any

Die Pseudoschnittstelle any wird auf Linux und aktuellen macOS-Versionen unterstützt. Dabei gelten Einschränkungen:

Richtige Schnittstelle kontrollieren

[TEST][PRIV][SENS] sudo tcpdump -i en0 -nn -c 20

Danach wird ein bekannter, autorisierter Test erzeugt, beispielsweise:

ping 192.0.2.1

Sind die erwarteten Pakete nicht sichtbar, müssen folgende Punkte geprüft werden:

4. Welche Optionen werden bei tcpdump häufig verwendet?

Optionstabelle anzeigen
Option Bedeutung
-D Verfügbare Capture-Schnittstellen anzeigen
-i INTERFACE Schnittstelle auswählen
-n Adressen und andere numerische Angaben nicht in Namen umwandeln
-nn Insbesondere auch Portnummern numerisch anzeigen
-c ANZAHL Nach einer bestimmten Paketanzahl beenden
-w DATEI Rohpakete in eine Datei schreiben
-r DATEI Pakete aus einer Datei lesen
-v Ausführlichere Ausgabe
-vv Noch ausführlichere Ausgabe
-vvv Maximale standardmäßige Detailstufe
-q Verkürzte Ausgabe
-e Link-Layer-Header, beispielsweise MAC-Adressen, anzeigen
-A Nutzdaten als ASCII anzeigen
-x Paketdaten hexadezimal anzeigen
-X Paketdaten hexadezimal und als ASCII anzeigen
-XX Wie -X, einschließlich Link-Layer-Header
-tt Zeit als Unix-Zeitstempel ausgeben
-ttt Zeitdifferenz zum vorherigen Paket ausgeben
-tttt Datum und Uhrzeit pro Paket ausgeben
-ttttt Zeitdifferenz zum ersten angezeigten Paket ausgeben
-s LÄNGE Maximale Anzahl aufgezeichneter Bytes je Paket festlegen
-B GRÖSSE Betriebssystem-Capture-Puffer in KiB festlegen
-C GRÖSSE Ausgabedatei nach Erreichen einer Größe wechseln
-G SEKUNDEN Ausgabedatei zeitgesteuert wechseln
-W ANZAHL Anzahl rotierter Dateien begrenzen
-U Pakete zeitnah in die Ausgabedatei schreiben
-K Prüfsummenprüfung bei der Anzeige deaktivieren
-Q in|out|inout Aufzeichnungsrichtung festlegen, sofern unterstützt
-p Promiscuous Mode nicht aktivieren
-F DATEI Capture-Filter aus einer Datei lesen

Nicht jede Option wird von jeder Betriebssystem- und libpcap-Version unterstützt. Deshalb sollten Version und lokale Hilfeseite geprüft werden:

[RO] tcpdump --version

[RO] man tcpdump

5. Wie wird ein kurzer, kontrollierter Mitschnitt durchgeführt?

Grundlegende Mitschnittbefehle anzeigen

20 Pakete anzeigen und danach beenden

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -c 20

100 Pakete in eine Datei schreiben

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -c 100 -w capture.pcap

Nur Verkehr eines bestimmten Hosts aufzeichnen

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -c 500 -w host-test.pcap 'host 192.0.2.10'

Nur HTTPS-Verkehr zu einem Server aufzeichnen

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -c 1000 -w https-test.pcap 'host 198.51.100.20 and tcp port 443'

Mitschnitt manuell beenden

Ein laufender Mitschnitt wird normalerweise mit folgender Tastenkombination beendet:

[Strg] + [C]

Nach dem Beenden zeigt tcpdump Zähler an:

packets captured
packets received by filter
packets dropped by kernel

Die genaue Bedeutung von packets received by filter ist betriebssystemabhängig. Besonders wichtig ist:

packets dropped by kernel

Ein Wert größer als null weist darauf hin, dass der Capture-Mechanismus Pakete wegen fehlenden Pufferplatzes verworfen hat. Die Aufzeichnung ist dann möglicherweise unvollständig.

6. Wie ist ein tcpdump-Filter grundsätzlich aufgebaut?

BPF-Filterlogik anzeigen

Ein Capture-Filter besteht aus einer oder mehreren Bedingungen. Diese können mit logischen Operatoren verbunden werden.

Operator Bedeutung
and Beide Bedingungen müssen zutreffen
or Mindestens eine Bedingung muss zutreffen
not Bedingung wird ausgeschlossen
( ) Gruppiert mehrere Bedingungen

Einzelne Bedingung

host 192.0.2.10

Zwei Bedingungen mit and

host 192.0.2.10 and tcp port 443

Alternative Bedingungen mit or

tcp port 80 or tcp port 443

Bedingung ausschließen

not port 22

Gruppierung mit Klammern

host 192.0.2.10 and (tcp port 80 or tcp port 443)

Filter mit Leerzeichen, Klammern oder Shell-Sonderzeichen sollten immer in einfache Anführungszeichen gesetzt werden:

sudo tcpdump -i eth0 -nn 'host 192.0.2.10 and (tcp port 80 or tcp port 443)'

Dadurch wird verhindert, dass die Shell Zeichen wie (, ), !, & oder | selbst interpretiert.

7. Welche Host-, Netz- und Richtungsfilter gibt es?

Host- und Netzfilter anzeigen
Aufgabe Filter
Host als Quelle oder Ziel host 192.0.2.10
Nur Pakete von einem Host src host 192.0.2.10
Nur Pakete zu einem Host dst host 192.0.2.10
Einer von zwei Hosts host 192.0.2.10 or host 198.51.100.20
Kommunikation zwischen zwei Hosts host 192.0.2.10 and host 198.51.100.20
Host ausschließen not host 192.0.2.10
IPv4-Netz net 192.0.2.0/24
Nur Quelle aus einem Netz src net 192.0.2.0/24
Nur Ziel in einem Netz dst net 198.51.100.0/24
Netz ausschließen not net 192.0.2.0/24
Bestimmte Ethernet-Adresse ether host 00:11:22:33:44:55
Nur Ethernet-Quelle ether src 00:11:22:33:44:55
Nur Ethernet-Ziel ether dst 00:11:22:33:44:55

Kommunikation zwischen genau zwei IPv4-Systemen

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'host 192.0.2.10 and host 198.51.100.20'

Bei zwei unterschiedlichen Hosts bedeutet diese Schreibweise praktisch, dass beide Adressen im Paket vorkommen müssen: eine als Quelle und die andere als Ziel.

Nur Verkehr vom Client zum Server

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'src host 192.0.2.10 and dst host 198.51.100.20'

Nur Rückverkehr

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'src host 198.51.100.20 and dst host 192.0.2.10'

8. Welche Protokoll- und Portfilter werden häufig verwendet?

Protokoll- und Portfilter anzeigen
Aufgabe Filter
Nur IPv4 ip
Nur IPv6 ip6
TCP tcp
UDP udp
ICMPv4 icmp
ICMPv6 icmp6
ARP arp
TCP- oder UDP-Port 53 port 53
Nur TCP-Port 53 tcp port 53
Nur UDP-Port 53 udp port 53
TCP-Quellport 443 tcp src port 443
TCP-Zielport 443 tcp dst port 443
Portbereich tcp portrange 8000-8100
Zielportbereich tcp dst portrange 8000-8100
TCP-Port 80 oder 443 tcp port 80 or tcp port 443
TCP-Port 22 ausschließen tcp and not port 22
Broadcastverkehr ether broadcast
Multicastverkehr ether multicast

Wichtiger Unterschied

port 53

erfasst TCP und UDP auf Port 53.

udp port 53

erfasst ausschließlich UDP auf Port 53.

tcp port 53

erfasst ausschließlich TCP auf Port 53.

Dieser Unterschied ist beispielsweise bei DNS wichtig, da DNS sowohl UDP als auch TCP verwenden kann.

9. Welche Filter eignen sich für typische Netzwerkprotokolle?

Protokolltabelle anzeigen
Protokoll oder Aufgabe Capture-Filter
ARP arp
ICMPv4 icmp
ICMPv6 icmp6
DNS über TCP und UDP port 53
DHCPv4 udp port 67 or udp port 68
DHCPv6 udp port 546 or udp port 547
HTTP tcp port 80
HTTPS tcp port 443
HTTP und HTTPS tcp port 80 or tcp port 443
SSH tcp port 22
SMTP tcp port 25
NTP udp port 123
SNMP udp port 161 or udp port 162
LDAP tcp port 389 or udp port 389
LDAPS tcp port 636
Kerberos port 88
SMB tcp port 445
RDP tcp port 3389 or udp port 3389
SIP port 5060 or port 5061
TFTP udp port 69
WireGuard Üblicherweise der konfigurierte UDP-Port, beispielsweise udp port 51820
IPsec IKE udp port 500 or udp port 4500
VXLAN-Standardport udp port 4789

DNS-Aufzeichnung

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w dns.pcap 'port 53'

DHCPv4-Aufzeichnung

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -e -w dhcp.pcap 'udp port 67 or udp port 68'

SMB-Kommunikation mit einem Server

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w smb-test.pcap 'host 198.51.100.20 and tcp port 445'

Portfilter zeigen Verkehr auf den angegebenen Ports. Sie beweisen nicht automatisch, dass der Verkehr tatsächlich das erwartete Anwendungsprotokoll enthält.

10. Wie werden TCP-Verbindungsaufbau und Verbindungsabbruch gefiltert?

TCP-Flag-Filter anzeigen

Die TCP-Steuerflags befinden sich im TCP-Header. Mit tcp[tcpflags] lassen sie sich gezielt prüfen.

Aufgabe Capture-Filter
Alle Pakete mit gesetztem SYN tcp[tcpflags] & tcp-syn != 0
Initiales SYN ohne ACK `tcp[tcpflags] & (tcp-syn
SYN und ACK gesetzt `tcp[tcpflags] & (tcp-syn
Pakete mit RST tcp[tcpflags] & tcp-rst != 0
Pakete mit FIN tcp[tcpflags] & tcp-fin != 0
Pakete mit PSH tcp[tcpflags] & tcp-push != 0

Neue TCP-Verbindungsversuche anzeigen

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn'

SYN/ACK-Antworten anzeigen

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-ack) == (tcp-syn|tcp-ack)'

TCP-Resets anzeigen

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-rst != 0'

Nur TCP-Resets eines bestimmten Servers

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'host 198.51.100.20 and tcp[tcpflags] & tcp-rst != 0'

Interpretation

Beobachtung Mögliche Bedeutung
Wiederholte SYN-Pakete ohne SYN/ACK Keine Antwort sichtbar, Paketverlust, Firewall, Routing- oder Serverproblem
SYN wird mit RST beantwortet System erreichbar, aber Port geschlossen oder Verbindung abgelehnt
SYN/ACK erreicht Client nicht Rückweg, Firewall, asymmetrisches Routing oder Aufzeichnungspunkt prüfen
RST während bestehender Verbindung Endpunkt oder Zwischensystem bricht die TCP-Verbindung ab
FIN-Sequenz Regulärer geordneter Verbindungsabbau möglich

tcpdump kennzeichnet Wiederholungsübertragungen nicht so komfortabel wie Wireshark. Für eine detaillierte TCP-Analyse sollte die Datei anschließend mit Wireshark oder TShark untersucht werden.

11. Wie werden Paketgrößen gefiltert?

Längenfilter anzeigen
Aufgabe Filter
Pakete kleiner oder gleich 100 Byte less 100
Pakete größer oder gleich 1500 Byte greater 1500
TCP-Pakete größer oder gleich 1500 Byte tcp and greater 1500
UDP-Pakete kleiner oder gleich 100 Byte udp and less 100

Große IPv4-Pakete anzeigen

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'ip and greater 1500'

Bei less und greater ist zu beachten:

12. Wie werden VLAN-Pakete gefiltert?

VLAN-Filter und Fallstricke anzeigen

Pakete mit 802.1Q-VLAN-Tag

vlan

Bestimmte VLAN-ID

vlan 100

IPv4-Verkehr im VLAN 100

vlan 100 and ip

HTTPS-Verkehr im VLAN 100

vlan 100 and tcp port 443

Aufzeichnung

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -e -w vlan100.pcap 'vlan 100'

Die Option -e zeigt bei der Textausgabe den Link-Layer-Header an und kann dadurch VLAN- und MAC-Informationen sichtbar machen.

Wichtige Einschränkungen

Beispiel für doppelte VLAN-Kapselung:

vlan 100 and vlan 200

Ob diese Pakete am gewählten Aufzeichnungspunkt sichtbar sind, hängt von Netzwerkkarte, Treiber, Offloading und Switch-Konfiguration ab.

13. Wie wird die Textausgabe sinnvoll formatiert?

Ausgabeoptionen und Beispiele anzeigen

Numerische Ausgabe mit Datum und Uhrzeit

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -tttt

MAC-Adressen anzeigen

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -e

Ausführliche Ausgabe

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -vv

Hexadezimal- und ASCII-Ausgabe

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -X -c 10

Link-Layer-Header, Hexadezimal- und ASCII-Daten

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -XX -c 10

Kurzausgabe

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -q

Bedeutung der Zeitoptionen

Option Ausgabe
Keine zusätzliche Option Uhrzeit seit Mitternacht
-tt Sekunden seit Unix-Epoche
-ttt Differenz zum vorherigen Paket
-tttt Datum und Uhrzeit
-ttttt Differenz zum ersten Paket

-A, -X und -XX können sensible Nutzdaten sichtbar machen. Sie sollten nur gezielt und bei entsprechender Berechtigung verwendet werden.

14. Wie werden Mitschnittdateien gespeichert und gelesen?

Dateibefehle anzeigen

Pakete als Rohdaten speichern

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w capture.pcap

Während -w verwendet wird, schreibt tcpdump die Rohpakete in die Datei. Die normale Paketbeschreibung erscheint dabei nicht automatisch im Terminal.

Vorhandene Datei lesen

[RO][FILE][SENS] tcpdump -nn -r capture.pcap

Mit Datum und ausführlicher Ausgabe lesen

[RO][FILE][SENS] tcpdump -nn -tttt -vv -r capture.pcap

Nur DNS aus einer vorhandenen Datei lesen

[RO][FILE][SENS] tcpdump -nn -r capture.pcap 'port 53'

Nur Verkehr eines Hosts lesen

[RO][FILE][SENS] tcpdump -nn -r capture.pcap 'host 192.0.2.10'

Paketanzahl einer Datei bestimmen, sofern von der installierten Version unterstützt

[RO][FILE][SENS] tcpdump --count -r capture.pcap

Alternativ kann das Wireshark-Werkzeug Capinfos verwendet werden:

[RO][FILE][SENS] capinfos capture.pcap

Datei während des Mitschnitts paketweise aktualisieren

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -U -w capture.pcap

-U sorgt dafür, dass jedes empfangene Paket zeitnah in die Ausgabedatei geschrieben wird. Das kann hilfreich sein, wenn eine Aufzeichnung während eines Absturzes oder Fehlers möglichst aktuell bleiben soll.

15. Wie wird die Größe eines Mitschnitts begrenzt?

Dateigröße und Ringpuffer anzeigen

Nach ungefähr 100 MB eine neue Datei beginnen

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -C 100 -w capture.pcap

Ohne Einheit verwendet -C Millionen Byte:

100 = 100.000.000 Byte

Moderne tcpdump-Versionen unterstützen zusätzlich Einheiten:

Angabe Einheit
100K 100 × 1.024 Byte
100M 100 × 1.048.576 Byte
1G 1 × 1.073.741.824 Byte

Zehn Dateien mit jeweils ungefähr 100 MiB als Ringpuffer

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -C 100M -W 10 -w capture.pcap

Bei Verwendung von -C zusammen mit -W:

Ungefähre maximale Gesamtgröße

10 Dateien × 100 MiB = ungefähr 1.000 MiB

Die Größenprüfung erfolgt vor dem Schreiben eines neuen Pakets. Eine Datei kann deshalb geringfügig größer als der angegebene Wert werden.

16. Wie werden Mitschnittdateien zeitgesteuert gewechselt?

Zeitrotation korrekt verwenden

Alle fünf Minuten eine neue Datei

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -G 300 -w 'capture-%Y%m%d-%H%M%S.pcap'

Beispielhafte Dateinamen:

capture-20260731-140000.pcap
capture-20260731-140500.pcap
capture-20260731-141000.pcap

Nach zwölf Fünf-Minuten-Dateien beenden

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -G 300 -W 12 -w 'capture-%Y%m%d-%H%M%S.pcap'

Das entspricht ungefähr:

12 Dateien × 5 Minuten = 60 Minuten

Wichtiger Unterschied

Kombination Verhalten
-C und -W Ringpuffer; ältere Dateien werden überschrieben
-G und -W Nach der festgelegten Anzahl Dateien wird tcpdump beendet
-C, -G und -W gemeinsam -W begrenzt nach aktueller Dokumentation nicht zuverlässig wie bei den einzelnen Varianten und beeinflusst hauptsächlich die Dateinamen

Bei -G sollte -w einen eindeutigen Zeitplatzhalter enthalten. Andernfalls kann jede neue Datei denselben Namen erhalten und die vorherige Datei überschreiben.

Sicheres Beispiel

-w 'capture-%Y%m%d-%H%M%S.pcap'

Problematisches Beispiel

-w capture.pcap

17. Wie wird die Aufzeichnungsdauer auf Linux und macOS begrenzt?

Zeitlich begrenzte Aufzeichnung anzeigen

tcpdump besitzt die Option -G für den Dateiw echsel, aber keine allgemeine, plattformübergreifende Option nach dem Muster „nach genau 60 Sekunden stoppen“.

Linux mit GNU timeout

[TEST][PRIV][FILE][SENS] sudo timeout 60 tcpdump -i eth0 -nn -w capture.pcap 'host 192.0.2.10'

timeout gehört nicht zu tcpdump, sondern zu den GNU Coreutils. Der Befehl steht nicht auf jedem Unix-System standardmäßig zur Verfügung.

macOS

Auf macOS ist GNU timeout standardmäßig nicht vorhanden. Stattdessen sind folgende Methoden geeignet:

macOS: nach einem Zeitintervall beenden

[TEST][PRIV][FILE][SENS] sudo tcpdump -i en0 -nn -G 60 -W 1 -w 'capture-%Y%m%d-%H%M%S.pcap' 'host 192.0.2.10'

Dieser Befehl erstellt eine Aufzeichnungsdatei und beendet tcpdump nach dem ersten Rotationsintervall.

Vor dem praktischen Einsatz sollte das Verhalten der lokal installierten tcpdump-Version mit einem kurzen Test geprüft werden.

18. Wie wird die Snapshot-Länge verwendet?

Snapshot-Länge und Auswirkungen anzeigen

Die Snapshot-Länge bestimmt, wie viele Byte eines Pakets gespeichert werden.

-s LÄNGE

Beispiel:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -s 128 -w headers.pcap

Damit werden höchstens 128 Byte je Paket aufgezeichnet.

Vorteile einer verkürzten Snapshot-Länge

Nachteile

Abgeschnittene Pakete können in der tcpdump-Ausgabe mit einer Kennzeichnung wie dieser erscheinen:

[|proto]

Die aktuelle tcpdump-Standard-Snapshot-Länge ist sehr groß und erfasst normalerweise das vollständige Paket. Eine kleinere Snapshot-Länge sollte nur verwendet werden, wenn klar ist, welche Header und Daten für die Diagnose benötigt werden.

19. Wie werden Paketverluste während des Mitschnitts erkannt?

Capture-Drops und Gegenmaßnahmen anzeigen

Beim Beenden zeigt tcpdump normalerweise unter anderem:

packets captured
packets received by filter
packets dropped by kernel

Bewertung

Zähler Bedeutung
packets captured Von tcpdump empfangene und verarbeitete Pakete
packets received by filter Betriebssystemabhängiger Zähler des Capture-Mechanismus
packets dropped by kernel Wegen fehlenden Capture-Pufferplatzes verworfene Pakete

Sind Kernel-Drops vorhanden, können folgende Maßnahmen helfen:

  1. Capture-Filter enger setzen.
  2. Mitschnitt auf eine Datei schreiben statt alles im Terminal auszugeben.
  3. Ausgabeoptionen wie -A, -X, -XX oder -vvv während des Live-Mitschnitts vermeiden.
  4. Capture-Puffer vorsichtig vergrößern.
  5. Snapshot-Länge nur bei fachlicher Begründung verkleinern.
  6. Auf einem leistungsfähigeren oder geeigneteren System mitschneiden.
  7. Festplattenleistung und freien Speicherplatz prüfen.
  8. Netzwerk-TAP oder spezielle Capture-Hardware verwenden.

Capture-Puffer beispielsweise auf 4.096 KiB setzen

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -B 4096 -w capture.pcap

Ein größerer Puffer garantiert keinen verlustfreien Mitschnitt. Der Wert muss zum Betriebssystem, Datenaufkommen und verfügbaren Speicher passen.

20. Warum zeigt tcpdump manchmal fehlerhafte Prüfsummen an?

Checksum-Offloading erklären

Netzwerkkarten können Prüfsummenberechnungen für IP, TCP oder UDP übernehmen. Bei ausgehenden Paketen kann tcpdump das Paket erfassen, bevor die Netzwerkkarte die endgültige Prüfsumme eingesetzt hat.

Dadurch kann tcpdump scheinbar fehlerhafte Prüfsummen anzeigen, obwohl das Paket korrekt übertragen wurde.

Prüfsummenprüfung bei der Anzeige deaktivieren

[RO][FILE][SENS] tcpdump -K -nn -r capture.pcap

Live:

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -K -nn

-K verhindert lediglich die Prüfsummenprüfung durch tcpdump. Es repariert keine Pakete und verändert nicht die Netzwerkkonfiguration.

Sinnvolle Prüfung

Das Deaktivieren von Hardware-Offloading wäre eine Systemänderung und kann Leistung oder Verhalten beeinflussen. Es gehört deshalb nicht zu den ersten Diagnosemaßnahmen.

21. Wie wird eingehender oder ausgehender Verkehr gefiltert?

Richtungsfilter anzeigen

Auf unterstützten Plattformen kann -Q verwendet werden:

Option Bedeutung
-Q in Nur eingehender Verkehr
-Q out Nur ausgehender Verkehr
-Q inout Beide Richtungen

Nur eingehende Pakete

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -Q in -nn

Nur ausgehende DNS-Pakete

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -Q out -nn 'port 53'

-Q wird nicht auf jeder Plattform und nicht von jeder Capture-Schnittstelle unterstützt.

Eine portablere Alternative besteht darin, Quell- und Zieladresse ausdrücklich zu filtern:

src host 192.0.2.10

oder:

dst host 192.0.2.10

Dabei wird die Richtung anhand der Paketadressen und nicht anhand der Betriebssystem-Schnittstellenrichtung bestimmt.

22. Wie wird ein Filter vor dem eigentlichen Mitschnitt geprüft?

Filtertest und Fehlermeldungen anzeigen

Ein falsch formulierter Filter kann dazu führen, dass tcpdump nicht startet oder unerwartete Pakete erfasst.

Kurzer Praxistest

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -c 10 'host 192.0.2.10 and tcp port 443'

Kompilierten BPF-Code anzeigen

[RO][PRIV] sudo tcpdump -i eth0 -d 'host 192.0.2.10 and tcp port 443'

-d kompiliert den Filter, gibt die resultierenden BPF-Anweisungen lesbar aus und beendet tcpdump, ohne einen normalen Mitschnitt zu starten.

Filter aus einer Datei lesen

Beispielinhalt einer autorisiert erstellten Filterdatei:

host 192.0.2.10 and
(tcp port 80 or tcp port 443)

Filterdatei verwenden:

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -F capture-filter.txt

Wird -F verwendet, wird ein zusätzlicher Filterausdruck auf der Kommandozeile ignoriert. Deshalb sollte nicht gleichzeitig ein weiterer Filter hinter dem Befehl angegeben werden.

23. Welche typischen Fehler treten bei tcpdump auf?

Fehlertabelle anzeigen
Fehler oder Beobachtung Wahrscheinliche Erklärung Prüfung
tcpdump: command not found tcpdump nicht installiert oder nicht im Suchpfad command -v tcpdump
You don't have permission to capture Capture-Berechtigung fehlt Berechtigungen und Sicherheitsrichtlinie prüfen
Keine Pakete sichtbar Falsche Schnittstelle oder zu enger Filter tcpdump -D, Kontrollmitschnitt ohne Filter
Namen statt IP-Adressen Namensauflösung aktiv -nn verwenden
Mitschnittdatei wächst unbegrenzt Keine Größen- oder Zeitbegrenzung -C, -W oder -G verwenden
Nur eine Datei trotz -G Dateiname enthält keinen eindeutigen Zeitplatzhalter Zeitformat in -w ergänzen
Alte Dateien werden überschrieben Ringpuffer aktiv oder Dateiname nicht eindeutig Optionen und Zielverzeichnis prüfen
Hohe Anzahl dropped by kernel Capture-Puffer oder Systemleistung reicht nicht Filter, -B, Ausgabe und Speicher prüfen
bad udp cksum oder ähnliche Meldung Möglicherweise Checksum Offloading Gegenstelle vergleichen oder Anzeige mit -K prüfen
Pakete erscheinen abgeschnitten Snapshot-Länge zu klein -s-Einstellung prüfen
VLAN-Tag fehlt Access-Port oder Hardware-Offloading Switch-Port, Treiber und Gegenmitschnitt prüfen
Fremder Unicastverkehr fehlt Switch sendet ihn nicht an diesen Port Autorisierten SPAN-Port oder TAP verwenden
Filter funktioniert in Wireshark, aber nicht in tcpdump Display-Filter mit Capture-Filter verwechselt libpcap-Syntax verwenden
SSH-Mitschnitt enthält überwiegend eigene Sitzung Administrationsverbindung wird mitgeschnitten Eigene SSH-Verbindung gezielt ausschließen

Eigene SSH-Sitzung ausschließen

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w capture.pcap 'not tcp port 22'

Dieser Filter schließt allerdings sämtlichen TCP-Verkehr auf Port 22 aus. Falls SSH selbst untersucht werden soll, darf dieser Filter nicht verwendet werden.

24. Wie wird tcpdump über SSH sicher eingesetzt?

Remote-Diagnose anzeigen

Beim Start von tcpdump über SSH wird auch die eigene SSH-Verbindung sichtbar, sofern sie den untersuchten Netzwerkpfad verwendet.

Eigene SSH-Verbindung ausschließen

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w capture.pcap 'not tcp port 22'

Besser ist ein genauer Ausschluss, wenn die Managementadresse bekannt ist:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w capture.pcap 'not (host 192.0.2.50 and tcp port 22)'

Dabei ist 192.0.2.50 beispielhaft die autorisierte Managementstation.

Risiken einer Remote-Sitzung

Deshalb sollten mindestens eine dieser Begrenzungen verwendet werden:

Nach der Diagnose muss geprüft werden, ob tcpdump noch läuft:

[RO] pgrep -a tcpdump

Dieser Befehl ist auf Linux üblich. Die genaue Verfügbarkeit ist betriebssystemabhängig.

25. Wie werden Container- und VM-Verbindungen untersucht?

Virtuelle Netzwerke und Namespaces anzeigen

Bei Containern und virtuellen Maschinen kann der Verkehr an mehreren Stellen sichtbar sein:

Anwendung
    ↓
Container- oder Gast-Schnittstelle
    ↓
virtuelle Bridge oder virtueller Switch
    ↓
Host-Schnittstelle
    ↓
physisches Netzwerk

Typische Linux-Schnittstellen

Schnittstelle Bedeutung
docker0 Standard-Docker-Bridge
br-... Benutzerdefinierte Docker-Bridge
veth... Virtuelles Ethernet-Paar eines Containers
virbr0 Häufige libvirt-Bridge
tap... Virtuelle TAP-Schnittstelle
eth0 oder ens... Physische oder virtuelle Host-Schnittstelle

Schnittstellen anzeigen

[RO] ip link show

[RO] tcpdump -D

Docker-Bridge untersuchen

[TEST][PRIV][FILE][SENS] sudo tcpdump -i docker0 -nn -w docker-bridge.pcap

Host-Schnittstelle und Container-IP filtern

[TEST][PRIV][FILE][SENS] sudo tcpdump -i any -nn -w container-test.pcap 'host 192.0.2.10'

Ein Mitschnitt innerhalb eines Containers benötigt zusätzliche Berechtigungen wie Netzwerk-Capabilities und erweitert die Angriffsfläche. Wenn möglich, sollte deshalb auf dem autorisierten Container-Host oder an der Bridge aufgezeichnet werden.

Bei Kubernetes, Overlay-Netzen, VXLAN und Service-Proxys kann die sichtbare Adresse je nach Aufzeichnungspunkt durch NAT oder Kapselung verändert sein.

26. Wie sieht ein systematischer Diagnoseablauf mit tcpdump aus?

Empfohlene Schrittfolge anzeigen

Vorbereitung

  1. Störung, Sollzustand und Fehlerzeitpunkt dokumentieren.
  2. Client, Server, IP-Adressen, Ports und Protokolle ermitteln.
  3. Den erwarteten Netzwerkpfad bestimmen.
  4. Berechtigung für den Mitschnitt prüfen.
  5. Systemzeit und Zeitzone kontrollieren.
  6. Freien Speicherplatz prüfen.
  7. Schutzbedarf der Mitschnittdatei festlegen.

Schnittstelle prüfen

  1. Verfügbare Schnittstellen mit tcpdump -D anzeigen.
  2. Einen kurzen Kontrollmitschnitt ohne engen Filter durchführen.
  3. Mit einem bekannten Test prüfen, ob die richtige Schnittstelle ausgewählt wurde.

Mitschnitt planen

  1. Einen möglichst gezielten Capture-Filter formulieren.
  2. Filter mit einer kleinen Paketanzahl testen.
  3. Paket-, Größen- oder Zeitbegrenzung festlegen.
  4. Dateinamen, Zielverzeichnis und Berechtigungen prüfen.

Mitschnitt durchführen

  1. tcpdump starten.
  2. Fehler genau einmal reproduzieren.
  3. Start- und Endzeit notieren.
  4. Mitschnitt kontrolliert beenden.
  5. Capture-Zähler und Kernel-Drops prüfen.
  6. Kontrollieren, ob tcpdump noch läuft.

Analyse

  1. Datei zunächst mit tcpdump -nn -r prüfen.
  2. Dateieigenschaften mit capinfos kontrollieren.
  3. Datei anschließend in Wireshark oder TShark öffnen.
  4. Kommunikationsrichtung, TCP-Handshake, DNS, TLS und Anwendung untersuchen.
  5. Zeitstempel mit System-, Firewall- und Anwendungslogs vergleichen.

Validierung

  1. Beobachtung und vermutete Ursache getrennt dokumentieren.
  2. Hypothese durch einen gezielten Vergleichstest prüfen.
  3. Falls erforderlich, an einem zweiten Punkt mitschneiden.
  4. Nach einer Änderung denselben Test erneut durchführen.
  5. Nicht mehr benötigte Mitschnittdateien gemäß Richtlinie löschen.

27. Kurzreferenz – tcpdump-Befehle

Befehlstabelle anzeigen
Aufgabe Befehl
Version anzeigen [RO] tcpdump --version
Schnittstellen anzeigen [RO] tcpdump -D
20 Pakete anzeigen [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -c 20
100 Pakete speichern [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -c 100 -w capture.pcap
Alle regulären Schnittstellen [TEST][PRIV][SENS] sudo tcpdump -i any -nn
Datei lesen [RO][FILE][SENS] tcpdump -nn -r capture.pcap
Datei ausführlich lesen [RO][FILE][SENS] tcpdump -nn -tttt -vv -r capture.pcap
MAC-Adressen anzeigen [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -e
Hex und ASCII anzeigen [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -X -c 10
Host filtern [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'host 192.0.2.10'
HTTPS filtern [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp port 443'
DNS filtern [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'port 53'
Initiale TCP-SYN-Pakete [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn'
TCP-RST-Pakete [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-rst != 0'
Ringpuffer nach Größe [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -C 100M -W 10 -w capture.pcap
Dateien alle fünf Minuten [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -G 300 -w 'capture-%Y%m%d-%H%M%S.pcap'
Nach zwölf Zeitdateien stoppen [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -G 300 -W 12 -w 'capture-%Y%m%d-%H%M%S.pcap'
Capture-Puffer setzen [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -B 4096 -w capture.pcap
Datei sofort aktualisieren [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -U -w capture.pcap

28. Kurzreferenz – Capture-Filter

Filtertabelle anzeigen
Aufgabe Filter
IPv4 ip
IPv6 ip6
TCP tcp
UDP udp
ARP arp
ICMPv4 icmp
ICMPv6 icmp6
Host host 192.0.2.10
Quellhost src host 192.0.2.10
Zielhost dst host 192.0.2.10
IPv4-Netz net 192.0.2.0/24
Ethernet-Adresse ether host 00:11:22:33:44:55
TCP- oder UDP-Port port 53
TCP-Port tcp port 443
UDP-Port udp port 123
Zielport tcp dst port 443
Portbereich tcp portrange 8000-8100
DHCPv4 udp port 67 or udp port 68
DHCPv6 udp port 546 or udp port 547
HTTP oder HTTPS tcp port 80 or tcp port 443
Initiales TCP-SYN tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn
TCP-RST tcp[tcpflags] & tcp-rst != 0
VLAN 100 vlan 100
Broadcast ether broadcast
Multicast ether multicast
Große Pakete greater 1500
SSH ausschließen not tcp port 22
Host und HTTPS host 192.0.2.10 and tcp port 443
Host und zwei Ports host 192.0.2.10 and (tcp port 80 or tcp port 443)

Merksätze

Quellen

2. Grundwerkzeuge und Befehle

2.7 Nmap im autorisierten Netz – Hosts, Ports und Dienste untersuchen

Ziel dieser Seite

Nmap ist ein Werkzeug zur aktiven Netzwerkerkundung und Portanalyse. Administratoren können damit unter anderem prüfen:

Nmap sendet aktiv Pakete oder Verbindungsversuche an Zielsysteme. Es ist daher kein rein passives Diagnosewerkzeug.

Nmap darf ausschließlich gegen eigene Systeme oder mit eindeutiger Genehmigung des zuständigen Betreibers verwendet werden. Vor einem Scan müssen Zielbereich, Zeitraum, Scanart, Quellsystem und zulässige Intensität festgelegt werden.

Kennzeichnungen

Kennzeichnung Bedeutung
[RO] Lokale Abfrage ohne Netzwerkprüfung
[TEST] Aktiver Netzwerk- oder Diensttest
[PRIV] Erhöhte Berechtigungen können erforderlich sein
[FILE] Befehl erstellt oder verarbeitet Dateien
[SENS] Ausgabe kann sensible Infrastrukturinformationen enthalten
[DISRUPT] Test kann Dienste, Geräte oder Überwachungssysteme belasten
[CHANGE] Befehl verändert eine Einstellung oder Datei

1. Wofür sollte Nmap in der Fehleranalyse verwendet werden?

Geeignete und ungeeignete Einsatzbereiche anzeigen

Geeignete administrative Aufgaben

Aufgabe Beispiel
Einzelnen Dienst prüfen Ist TCP-Port 443 vom Clientnetz erreichbar?
Erreichbare Systeme erfassen Welche freigegebenen Testsysteme antworten im VLAN?
Firewalländerung kontrollieren Ist der freigegebene Port nach der Regeländerung erreichbar?
Dienstinventar vergleichen Stimmen offene Ports mit der Dokumentation überein?
Dienstidentifikation Welcher Dienst antwortet tatsächlich auf einem Port?
TCP und UDP unterscheiden Antwortet nur TCP oder auch UDP?
Erreichbarkeit aus verschiedenen Segmenten vergleichen Ist der Dienst intern erreichbar, aus dem Gastnetz aber gefiltert?
Fehlerzustand dokumentieren Welche Ergebnisse waren vor und nach einer Änderung sichtbar?

Nmap ist nicht geeignet für

Ein offener Port beweist nur, dass aus Sicht des Scanstandorts eine entsprechende Antwort empfangen wurde. Er beweist nicht, dass:

2. Wie wird Nmap auf Windows, Linux und macOS geprüft?

Installations- und Versionsprüfung anzeigen
Aufgabe Windows Linux macOS
Programmpfad suchen [RO] Get-Command nmap [RO] command -v nmap [RO] command -v nmap
Version anzeigen [RO] nmap --version [RO] nmap --version [RO] nmap --version
Hilfe anzeigen [RO] nmap -h [RO] nmap -h [RO] nmap -h
Lokale Handbuchseite Nicht standardmäßig vorhanden [RO] man nmap [RO] man nmap

Windows

Die offizielle Windows-Installation von Nmap verwendet normalerweise Npcap für Raw-Packet-Funktionen. Für bestimmte Scanarten sollte PowerShell oder die Eingabeaufforderung als Administrator gestartet werden.

Linux und macOS

Scanarten, die Raw-IP-Pakete verwenden, benötigen normalerweise erhöhte Rechte:

[TEST][PRIV][SENS] sudo nmap -sS -p 443 192.0.2.10

Ein TCP-Connect-Scan kann gewöhnlich ohne erhöhte Rechte ausgeführt werden:

[TEST][SENS] nmap -sT -p 443 192.0.2.10

Die tatsächlich verfügbaren Funktionen hängen von Betriebssystem, Nmap-Version, Rechten und Paket-Capture-Treiber ab.

3. Welche Freigaben müssen vor einem Scan vorliegen?

Autorisierungscheckliste anzeigen

Vor einem Scan sollten mindestens folgende Punkte dokumentiert sein:

Punkt Beispiel
Auftraggeber Zuständige IT-Abteilung
Zielsystem 192.0.2.10
Zielnetz 192.0.2.0/28
Erlaubte Ports TCP 22, 80 und 443
Erlaubte Scanarten Host Discovery, TCP Connect, Versionserkennung
Scanquelle Administrationssystem 192.0.2.50
Zeitraum 14:00–14:15 Uhr
Verantwortliche Kontaktperson Max Mustermann
Abbruchkriterium Dienstfehler, hohe Last oder Alarmmeldung
Protokollierung Ausgabe als normale, XML- und grepbare Datei
Erwarteter Sollzustand TCP 443 offen, TCP 22 gefiltert

Vor dem Start klären

Die Erlaubnis, einen einzelnen Server zu prüfen, ist keine Erlaubnis zum Scan des gesamten Subnetzes.

4. Wie werden Zielsysteme sicher angegeben?

Zielspezifikation anzeigen
Zielart Beispiel
Einzelne IPv4-Adresse 192.0.2.10
Mehrere einzelne Ziele 192.0.2.10 192.0.2.20
DNS-Name server.example.com
CIDR-Netz 192.0.2.0/28
IPv4-Adressbereich 192.0.2.10-20
IPv6-Adresse 2001:db8::10
Ziele aus einer Datei -iL targets.txt
Bestimmtes Ziel ausschließen --exclude 192.0.2.15
Ausschlussliste verwenden --excludefile excluded.txt

Einzelnes Ziel

[TEST][SENS] nmap 192.0.2.10

Kleines, ausdrücklich freigegebenes Netz

[TEST][SENS] nmap 192.0.2.0/28

IPv6-Ziel

[TEST][SENS] nmap -6 2001:db8::10

Ziele aus einer autorisiert erstellten Datei

[TEST][FILE][SENS] nmap -iL targets.txt

Zielbereich nur auflösen und auflisten, ohne Zielpakete zu senden

[RO][SENS] nmap -sL 192.0.2.0/28

-sL führt einen List Scan durch. Dabei werden die Ziele aufgelistet und standardmäßig gegebenenfalls Reverse-DNS-Abfragen durchgeführt. Es findet kein normaler Host- oder Portscan gegen die Zielsysteme statt.

Ohne DNS-Auflösung auflisten

[RO][SENS] nmap -sL -n 192.0.2.0/28

Das Auflisten des Zielbereichs vor dem aktiven Scan hilft, fehlerhafte CIDR-Angaben frühzeitig zu erkennen.

5. Wie wird geprüft, welche Hosts erreichbar sind?

Host Discovery anzeigen

Nur Host-Erkennung, ohne Portscan

[TEST][SENS] nmap -sn 192.0.2.0/28

-sn deaktiviert den anschließenden Portscan. Nmap führt aber weiterhin aktive Host-Erkennungsprüfungen durch.

Ohne Namensauflösung

[TEST][SENS] nmap -sn -n 192.0.2.0/28

Grund für die Bewertung anzeigen

[TEST][SENS] nmap -sn --reason 192.0.2.0/28

Lokales Ethernet-Netz

Im lokalen Ethernet-Netz verwendet Nmap für die Host-Erkennung normalerweise ARP beziehungsweise bei IPv6 Neighbor Discovery. Das ist häufig zuverlässiger als ein einfacher ICMP-Echo-Test.

Gezielte ICMP-Echo-Erkennung

[TEST][PRIV][SENS] sudo nmap -sn -PE 192.0.2.0/28

TCP-SYN-Erkennung auf freigegebenen Ports

[TEST][PRIV][SENS] sudo nmap -sn -PS22,80,443 192.0.2.0/28

TCP-ACK-Erkennung

[TEST][PRIV][SENS] sudo nmap -sn -PA80,443 192.0.2.0/28

UDP-Erkennung auf einem gezielt freigegebenen Port

[TEST][PRIV][SENS] sudo nmap -sn -PU53 192.0.2.0/28

Wichtige Interpretation

Ergebnis Aussage
Host is up Nmap hat eine als Erreichbarkeitsnachweis bewertete Antwort erhalten
Kein Hosteintrag Keine ausreichende Antwort empfangen
ICMP antwortet nicht Host kann trotzdem über TCP oder UDP erreichbar sein
ARP-Antwort im lokalen Netz Gerät ist auf Layer 2 erreichbar
Hohe Latenz Kann durch Netzwerk, Zielsystem oder Scanverfahren entstehen

Ein fehlender Hosttreffer beweist nicht, dass das System ausgeschaltet ist. Firewalls können die für die Erkennung verwendeten Pakete verwerfen.

6. Was bedeutet -Pn, und wann sollte es verwendet werden?

Portscan ohne vorherige Host-Erkennung anzeigen

Mit -Pn behandelt Nmap die angegebenen Ziele als erreichbar und überspringt die normale Host-Erkennung.

[TEST][SENS] nmap -Pn -p 443 192.0.2.10

Sinnvoller Einsatz

Auswirkung

Ohne erfolgreiche Host-Erkennung würde Nmap möglicherweise melden:

Host seems down.

Mit -Pn wird der Portscan trotzdem durchgeführt.

Risiko bei großen Zielbereichen

nmap -Pn 192.0.2.0/16

Dieser Scan würde jedes Ziel im Bereich als aktiv behandeln und entsprechend prüfen. Das kann sehr lange dauern und erhebliche Netzlast oder Sicherheitsmeldungen verursachen.

-Pn sollte nicht pauschal für große Netze verwendet werden. Es eignet sich hauptsächlich für bekannte, ausdrücklich freigegebene Einzelziele oder kleine Zielgruppen.

7. Welche Portzustände zeigt Nmap an?

Portzustände und Bedeutung anzeigen
Zustand Bedeutung
open Eine Anwendung nimmt an diesem Port Verbindungen oder Pakete an
closed Ziel ist erreichbar, aber an diesem Port antwortet kein Dienst
filtered Nmap kann wegen eines Filters oder Netzwerkhindernisses nicht bestimmen, ob der Port offen oder geschlossen ist
unfiltered Port ist erreichbar, der verwendete Scan kann aber nicht zwischen offen und geschlossen unterscheiden
open|filtered Nmap kann nicht zwischen offen und gefiltert unterscheiden
closed|filtered Nmap kann nicht zwischen geschlossen und gefiltert unterscheiden

Wichtig

filtered bedeutet nicht automatisch:

Eine Firewall auf dem Zielsystem blockiert den Port.

Mögliche Ursachen sind unter anderem:

Mit --reason zeigt Nmap an, auf welcher Antwort oder Nichtantwort die Bewertung beruht:

[TEST][SENS] nmap --reason -p 22,80,443 192.0.2.10

8. Welche Ports scannt Nmap standardmäßig?

Portauswahl anzeigen

Ohne ausdrückliche Portangabe untersucht Nmap standardmäßig die 1.000 häufigsten Ports des jeweiligen gescannten Protokolls. Es handelt sich nicht automatisch um alle 65.535 TCP-Ports.

Bestimmte Ports

[TEST][SENS] nmap -p 22,80,443 192.0.2.10

Portbereich

[TEST][SENS] nmap -p 8000-8100 192.0.2.10

Alle TCP-Ports

[TEST][SENS] nmap -p- 192.0.2.10

-p- steht für die Ports 1 bis 65.535. Ein vollständiger Portscan ist wesentlich umfangreicher als ein Standardscan und muss ausdrücklich freigegeben sein.

Die häufigsten 100 Ports

[TEST][SENS] nmap --top-ports 100 192.0.2.10

Schneller Scan der häufigsten Ports

[TEST][SENS] nmap -F 192.0.2.10

-F reduziert die Anzahl der normalerweise untersuchten Ports. Die genaue Portauswahl hängt von der lokalen Nmap-Dienstdatenbank ab.

Nur offene Ports anzeigen

[TEST][SENS] nmap --open -p 22,80,443,445,3389 192.0.2.10

--open verkürzt die Ausgabe. Für die Fehleranalyse können geschlossene und gefilterte Ports jedoch wichtige Informationen liefern. Die vollständige Ausgabe sollte deshalb häufig bevorzugt werden.

9. Was ist ein TCP-Connect-Scan?

TCP-Connect-Scan `-sT` anzeigen

Der TCP-Connect-Scan verwendet die normale connect()-Funktion des Betriebssystems. Er kann gewöhnlich ohne Raw-Packet-Rechte ausgeführt werden.

[TEST][SENS] nmap -sT -p 22,80,443 192.0.2.10

Eigenschaften

Eigenschaft TCP Connect
Option -sT
Erhöhte Rechte Normalerweise nicht erforderlich
Verbindung Vollständiger TCP-Verbindungsaufbau zu offenen Ports
Protokollierung am Ziel Wahrscheinlich
Eignung Funktionale Erreichbarkeitsprüfung einzelner TCP-Ports
Belastung Bei wenigen Ports normalerweise gering, aber aktiv

Einzelnen HTTPS-Port prüfen

[TEST][SENS] nmap -sT -Pn -p 443 --reason 192.0.2.10

Da bei offenen Ports eine vollständige Verbindung aufgebaut wird, kann der Zielserver den Versuch in seinen Logs erfassen.

Für einen gezielten administrativen Funktionstest ist das nicht grundsätzlich nachteilig: Der Scan soll nachvollziehbar und autorisiert sein.

10. Was ist ein TCP-SYN-Scan?

TCP-SYN-Scan `-sS` anzeigen

Beim SYN-Scan sendet Nmap ein TCP-SYN-Paket, ohne bei einem offenen Port eine vollständige Anwendungssitzung aufzubauen.

[TEST][PRIV][SENS] sudo nmap -sS -p 22,80,443 192.0.2.10

Typische Antworten

Antwort Nmap-Bewertung
SYN/ACK open
RST closed
Keine Antwort nach Wiederholungen filtered
Bestimmte ICMP-Unreachable-Antwort filtered

Eigenschaften

Eigenschaft TCP SYN
Option -sS
Erhöhte Rechte Auf Unix-Systemen normalerweise erforderlich
Vollständige TCP-Verbindung Nein
Unterscheidung open, closed, filtered
Eignung Kontrollierte Portprüfung im autorisierten Netz

Der Ausdruck „halb offen“ bedeutet nicht, dass der Scan unsichtbar ist. Firewalls, IDS, IPS und Zielsysteme können SYN-Scans erkennen und protokollieren.

11. Wie werden UDP-Dienste geprüft?

UDP-Scan `-sU` anzeigen

UDP ist verbindungslos. Ein fehlendes Antwortpaket lässt deshalb häufig keine eindeutige Entscheidung zu.

Gezielter UDP-Scan

[TEST][PRIV][SENS] sudo nmap -sU -p 53,123,161 192.0.2.10

Mit Begründung und Versionserkennung

[TEST][PRIV][SENS] sudo nmap -sU -sV --reason -p 53,123,161 192.0.2.10

Typische Ergebnisse

Antwort Mögliche Bewertung
Gültige UDP-Antwort open
ICMP Port Unreachable closed
Bestimmte andere ICMP-Fehler filtered
Keine Antwort open|filtered

Warum UDP-Scans länger dauern

Nur die tatsächlich benötigten Ports prüfen

[TEST][PRIV][SENS] sudo nmap -sU -p 53 192.0.2.10

Ein ungeplanter Scan aller 65.535 UDP-Ports kann sehr lange dauern und unnötige Last verursachen.

12. Wie werden TCP und UDP gemeinsam untersucht?

Kombinierten Scan anzeigen

TCP-SYN- und UDP-Scan können kombiniert werden:

[TEST][PRIV][SENS] sudo nmap -sS -sU -p T:53,80,443,U:53,123 192.0.2.10

Bedeutung

Ausdruck Geprüfte Ports
T:53,80,443 TCP 53, 80 und 443
U:53,123 UDP 53 und 123

Ohne die Präfixe T: und U: kann die Portzuordnung bei einem kombinierten Scan missverständlich werden.

DNS über TCP und UDP prüfen

[TEST][PRIV][SENS] sudo nmap -sS -sU -p T:53,U:53 192.0.2.10

Ein offener TCP- und UDP-Port bestätigt noch nicht, dass DNS-Anfragen korrekt beantwortet werden. Danach sollte ein protokollspezifischer Test folgen, beispielsweise mit dig, Resolve-DnsName oder nslookup.

13. Wie werden Dienste und Versionen erkannt?

Service- und Versionserkennung `-sV` anzeigen

Die Versionserkennung sendet zusätzliche, teilweise protokollspezifische Anfragen an offene oder wahrscheinlich offene Ports.

[TEST][SENS] nmap -sV -p 22,80,443 192.0.2.10

Leichtere Versionserkennung

[TEST][SENS] nmap -sV --version-light -p 22,80,443 192.0.2.10

Intensität festlegen

[TEST][SENS] nmap -sV --version-intensity 2 -p 22,80,443 192.0.2.10

Der Wertebereich für --version-intensity reicht von 0 bis 9:

Intensität Verhalten
0 Nur wenige, besonders wahrscheinliche Prüfungen
2 Reduzierte, häufig ausreichende Prüfung
7 Standardintensität
9 Alle verfügbaren Versionserkennungs-Probes

Interpretation

443/tcp open  https  nginx 1.24.0

Dabei sind zu unterscheiden:

Feld Aussage
443/tcp Untersuchte Port-/Protokollkombination
open Nmap erhielt eine Antwort für einen offenen Port
https Erkannter oder anhand der Portzuordnung vermuteter Dienst
nginx 1.24.0 Von Nmap ermittelte oder geschätzte Produktversion

Versionsergebnisse können unvollständig oder irreführend sein, beispielsweise durch:

Ein Nmap-Versionshinweis sollte mit der lokalen Paketverwaltung, der Anwendungskonfiguration oder der Herstelleroberfläche bestätigt werden.

14. Wie wird eine Betriebssystemerkennung durchgeführt?

OS-Erkennung `-O` anzeigen

Nmap versucht anhand verschiedener Netzwerkmerkmale, das Betriebssystem des Zielsystems zu bestimmen.

[TEST][PRIV][SENS] sudo nmap -O 192.0.2.10

Nur gezielte Ports und OS-Erkennung

[TEST][PRIV][SENS] sudo nmap -O -p 22,80,443 192.0.2.10

Erkennungsversuche begrenzen

[TEST][PRIV][SENS] sudo nmap -O --osscan-limit 192.0.2.0/28

--osscan-limit beschränkt die OS-Erkennung auf Ziele, bei denen Nmap dafür geeignete Bedingungen erkennt.

Voraussetzungen für gute Ergebnisse

Nmap erzielt bessere Resultate, wenn mindestens:

vorhanden sind.

Mögliche Ungenauigkeiten

Die Ausgabe ist eine Netzwerkerkennung beziehungsweise Schätzung und kein sicherer Beweis für das installierte Betriebssystem.

15. Welche einfachen NSE-Skripte können für die Diagnose verwendet werden?

Nmap Scripting Engine sicher einordnen

Die Nmap Scripting Engine, kurz NSE, erweitert Nmap um Skripte. Diese können von einfachen Informationsabfragen bis zu Sicherheits- und Belastungstests reichen.

Standard-Skripte

[TEST][DISRUPT][SENS] nmap -sC -p 22,80,443 192.0.2.10

-sC entspricht:

--script=default

Auch Standardskripte senden zusätzliche Anfragen an Dienste und sollten nur nach Freigabe verwendet werden.

Bestimmtes, zuvor geprüftes Skript

[TEST][SENS] nmap --script http-title -p 80,443 192.0.2.10

Skriptbeschreibung anzeigen

[RO] nmap --script-help http-title

Mehrere freigegebene Informationsskripte

[TEST][SENS] nmap --script http-title,http-headers -p 80,443 192.0.2.10

Vor einem NSE-Einsatz müssen geprüft werden:

Im normalen Troubleshooting nicht pauschal verwenden

--script vuln
--script exploit
--script brute
--script dos
--script intrusive

Diese Kategorien können Schwachstellenprüfungen, Anmeldeversuche oder belastende Tests enthalten. Sie gehören nicht in eine gewöhnliche Netzwerkdiagnose ohne gesonderten Auftrag.

Auch die Kategorie safe ist keine absolute Garantie für Wirkungslosigkeit. Das konkrete Skript muss vor dem Einsatz geprüft werden.

16. Warum sollte -A nicht unüberlegt verwendet werden?

Aggressive Erkennung erklären

Die Option -A aktiviert mehrere Funktionen gleichzeitig:

[TEST][PRIV][DISRUPT][SENS] sudo nmap -A 192.0.2.10

Für eine gezielte Fehleranalyse ist dieser Befehl häufig zu breit. Er sendet mehr unterschiedliche Prüfungen als ein einfacher Portscan und erzeugt umfangreichere Logs und mögliche Sicherheitsmeldungen.

Besser ist eine schrittweise Auswahl:

[TEST][SENS] nmap -sT -p 443 192.0.2.10

Danach bei Bedarf:

[TEST][SENS] nmap -sV --version-light -p 443 192.0.2.10

Und nur bei begründetem Bedarf:

[TEST][PRIV][SENS] sudo nmap -O -p 22,80,443 192.0.2.10

Dadurch bleibt erkennbar, welche Scanoption welche Reaktion verursacht hat.

17. Wie wird die Namensauflösung kontrolliert?

DNS-Optionen anzeigen

Keine DNS-Auflösung durchführen

[TEST][SENS] nmap -n -p 22,80,443 192.0.2.10

DNS-Auflösung für alle Ziele erzwingen

[TEST][SENS] nmap -R -p 22,80,443 192.0.2.10

Bedeutung

Option Wirkung
-n Keine Reverse-DNS-Auflösung
-R Reverse-DNS-Auflösung für alle Ziele
Keine Option Nmap entscheidet abhängig vom Scanergebnis

Für reproduzierbare Portprüfungen ist -n häufig sinnvoll:

Wenn die DNS-Zuordnung selbst Teil der Diagnose ist, sollte sie bewusst separat geprüft werden.

18. Wie wird die Scanrate kontrolliert?

Timing und Belastungsbegrenzung anzeigen

Nmap bietet Timing-Vorlagen:

Vorlage Name Einordnung
-T0 Paranoid Extrem langsam
-T1 Sneaky Sehr langsam
-T2 Polite Reduzierte Geschwindigkeit
-T3 Normal Standard
-T4 Aggressive Schneller, nur in stabilen und freigegebenen Netzen
-T5 Insane Sehr aggressiv; für normales Troubleshooting ungeeignet

Normale Geschwindigkeit

[TEST][SENS] nmap -T3 -p 22,80,443 192.0.2.10

Rücksichtsvollere Prüfung

[TEST][SENS] nmap -T2 -p 22,80,443 192.0.2.10

Maximale Paketrate begrenzen

[TEST][SENS] nmap --max-rate 50 -p 1-1000 192.0.2.10

--max-rate 50 fordert Nmap auf, im Durchschnitt nicht schneller als 50 Pakete pro Sekunde zu senden. Abhängig von Scanart und Betriebssystem können trotzdem kurzfristige Abweichungen auftreten.

Host-Zeitüberschreitung

[TEST][SENS] nmap --host-timeout 2m -p 22,80,443 192.0.2.10

Wenn ein Ziel nach zwei Minuten nicht vollständig geprüft wurde, beendet Nmap die weitere Bearbeitung dieses Hosts.

Für empfindliche Systeme

19. Wie werden Ergebnisse gespeichert?

Ausgabeformate anzeigen
Option Format Verwendung
-oN DATEI Normale Textausgabe Menschliche Auswertung
-oX DATEI XML Automatisierte Verarbeitung
-oG DATEI Grepbares Format Älteres zeilenorientiertes Format
-oA BASISNAME Alle drei Formate Vollständige Dokumentation

Normale Ausgabe speichern

[TEST][FILE][SENS] nmap -sT -p 22,80,443 -oN server-scan.txt 192.0.2.10

XML-Ausgabe

[TEST][FILE][SENS] nmap -sT -p 22,80,443 -oX server-scan.xml 192.0.2.10

Alle Hauptformate

[TEST][FILE][SENS] nmap -sT -p 22,80,443 -oA server-scan 192.0.2.10

Dabei entstehen typischerweise:

server-scan.nmap
server-scan.xml
server-scan.gnmap

Zusätzlich Terminalausgabe mit tee speichern

Linux und macOS:

[TEST][FILE][SENS] nmap -sT -p 22,80,443 192.0.2.10 | tee server-scan.txt

PowerShell:

[TEST][FILE][SENS] nmap -sT -p 22,80,443 192.0.2.10 | Tee-Object -FilePath server-scan.txt

tee beziehungsweise Tee-Object speichert nur die sichtbare Textausgabe. Für strukturierte Verarbeitung sollte -oX oder -oA verwendet werden.

20. Wie werden Ergebnisse vor und nach einer Änderung verglichen?

Vergleichsdiagnose anzeigen

Vor der Änderung

[TEST][FILE][SENS] nmap -n -sT -p 22,80,443 --reason -oA server-before 192.0.2.10

Nach der Änderung

[TEST][FILE][SENS] nmap -n -sT -p 22,80,443 --reason -oA server-after 192.0.2.10

Linux und macOS:

[RO][FILE][SENS] diff -u server-before.nmap server-after.nmap

PowerShell:

[RO][FILE][SENS] Compare-Object (Get-Content .\server-before.nmap) (Get-Content .\server-after.nmap)

Für einen aussagekräftigen Vergleich müssen identisch sein:

Andernfalls können Unterschiede durch die Testmethode statt durch die eigentliche Änderung entstehen.

21. Wie wird ein bestimmter Dienst systematisch geprüft?

Diagnosefolge für einen einzelnen Dienst anzeigen

Beispiel: HTTPS auf TCP-Port 443.

1. Namensauflösung getrennt prüfen

Windows:

[RO] Resolve-DnsName server.example.com

Linux oder macOS:

[RO] dig server.example.com

2. Host Discovery durchführen

[TEST][SENS] nmap -sn --reason 192.0.2.10

3. Port unabhängig von Host Discovery prüfen

[TEST][SENS] nmap -Pn -n -sT -p 443 --reason 192.0.2.10

4. Dienst vorsichtig identifizieren

[TEST][SENS] nmap -Pn -n -sV --version-light -p 443 192.0.2.10

5. Anwendungsebene prüfen

[TEST][SENS] curl -vkI https://192.0.2.10/

Bei namensabhängigen virtuellen Hosts sollte der korrekte DNS-Name verwendet werden:

[TEST][SENS] curl -vI https://server.example.com/

6. TLS gesondert prüfen

[TEST][SENS] openssl s_client -connect 192.0.2.10:443 -servername server.example.com

Interpretation

Ergebnis Nächster Schritt
Port closed Dienststatus und lokale Listener prüfen
Port filtered Firewall, ACL, Routing und Paketmitschnitt prüfen
Port open, curl fehlschlägt HTTP-, TLS-, Proxy- oder Anwendungsproblem untersuchen
Port open, TLS falsch Zertifikat, SNI, TLS-Version und Zeit prüfen
Nmap erkennt falschen Dienst Direkten Protokolltest durchführen
Unterschiedliche Ergebnisse aus zwei Netzen Firewall- und Routingpfad vergleichen

Nmap beantwortet hauptsächlich die Frage:

Wie reagiert dieser Port aus Sicht dieses Scanstandorts?

Für die vollständige Fehlerursache sind weitere Werkzeuge erforderlich.

22. Wie wird ein Firewallproblem eingegrenzt?

Vergleich zwischen Netzsegmenten anzeigen

Ein Scan sollte von genau den Standorten erfolgen, deren Erreichbarkeit untersucht wird.

Clientnetz A → Firewall → Servernetz
Clientnetz B → Firewall → Servernetz

Scan aus Netz A

[TEST][FILE][SENS] nmap -Pn -n -sT -p 443 --reason -oN netz-a.txt 192.0.2.10

Scan aus Netz B

[TEST][FILE][SENS] nmap -Pn -n -sT -p 443 --reason -oN netz-b.txt 192.0.2.10

Mögliche Beobachtung

Netz A Netz B Mögliche Schlussfolgerung
open filtered Unterschiedliche Firewall-, ACL- oder Routingbehandlung
open closed Möglicherweise anderes Ziel, NAT oder unterschiedliche Antwortquelle
filtered filtered Gemeinsamer Filter, fehlender Rückweg oder Ziel nicht erreichbar
open open Grundlegende Portfreigabe aus beiden Netzen vorhanden

Zusätzlich sollten geprüft werden:

Ein Nmap-Ergebnis allein zeigt nicht, an welchem Gerät ein Paket verworfen wurde.

23. Welche Scanarten sollten im normalen Troubleshooting vermieden werden?

Nicht empfohlene Optionen anzeigen

Folgende Funktionen gehören normalerweise nicht zur alltäglichen Fehleranalyse:

Scanart oder Option Grund
Idle Scan -sI Verwendet ein fremdes System als sogenanntes Zombie-System
FTP Bounce -b Missbraucht einen FTP-Server als Relay
Eigene TCP-Flags --scanflags Kann Filter- und IDS-Umgehung dienen
Decoys -D Verschleiert die tatsächliche Scanquelle
Quelladress-Spoofing -S Erschwert Rückverfolgung und kann Netzstörungen verursachen
Fragmentierung -f Wird häufig zur Filterumgehung eingesetzt
--badsum Erzeugt absichtlich ungültige Prüfsummen
NSE-Kategorie brute Führt Anmeldeversuche durch
NSE-Kategorie exploit Versucht Sicherheitslücken auszunutzen
NSE-Kategorie dos Kann Dienste beeinträchtigen
NSE-Kategorie intrusive Kann Systeme oder Anwendungen belasten
Ungeprüftes -A gegen viele Systeme Kombiniert mehrere aktive Erkennungsverfahren
-T5 Sehr aggressive Zeitsteuerung

Solche Funktionen werden in diesem Troubleshooting-Buch nicht als Standardbefehle empfohlen. Für einen gesonderten Sicherheitstest sind ein eigener Auftrag, eine genaue Risikoanalyse und abgestimmte Abbruchkriterien erforderlich.

24. Welche typischen Fehlinterpretationen gibt es?

Fehlertabelle anzeigen
Fehlinterpretation Korrekte Einordnung
Host seems down bedeutet ausgeschaltet Discovery-Pakete können gefiltert worden sein
open bedeutet Anwendung funktioniert Nur der Port reagiert; Anwendungstest folgt
closed bedeutet Firewall blockiert Das Ziel antwortet normalerweise aktiv mit „kein Listener“
filtered bedeutet lokale Host-Firewall Filter kann an jeder Stelle des Pfads liegen
open|filtered bedeutet offen Nmap kann offen und gefiltert nicht unterscheiden
Dienstname in der Porttabelle ist sicher erkannt Ohne -sV kann er nur aus der Portzuordnung stammen
Angezeigte Version ist garantiert installiert Banner, Proxy oder Backport können abweichen
OS-Erkennung ist ein sicherer Beweis Es handelt sich um eine Fingerprint-Schätzung
Kein Ergebnis bei UDP bedeutet geschlossen Häufig lautet der Zustand open|filtered
-Pn macht den Scan passiv Portscan bleibt aktiv; nur Host Discovery wird übersprungen
SYN-Scan ist unsichtbar IDS, IPS, Firewalls und Systeme können ihn erkennen
Ein Scan aus dem Servernetz gilt auch für das Clientnetz Unterschiedliche Netzwerkpfade können andere Ergebnisse liefern
Nmap ist ein vollständiger Schwachstellenscanner Nmap ist primär ein Netzwerk- und Portscanner
Viele Optionen liefern automatisch bessere Ergebnisse Mehr Prüfungen erhöhen Last, Logs und Fehlinterpretationsrisiko

25. Wie werden Nmap-Ergebnisse verifiziert?

Gegenprüfungen anzeigen
Nmap-Beobachtung Geeignete Gegenprüfung
TCP-Port offen Test-NetConnection, nc, curl oder anwendungsspezifischer Client
TCP-Port geschlossen Lokale Listener mit Get-NetTCPConnection, ss oder lsof prüfen
Port gefiltert Firewall-Logs, Routing und Paketmitschnitt prüfen
DNS-Dienst offen Resolve-DnsName, dig oder nslookup
HTTP/HTTPS offen curl
TLS erkannt openssl s_client
SSH offen Autorisierten SSH-Verbindungsaufbau durchführen
SMB offen SMB-Client und Serverlogs prüfen
Dienstversion erkannt Lokale Paket- oder Anwendungsversion prüfen
Betriebssystem erkannt Lokale Systeminformationen oder Inventarsystem prüfen
Host nicht erkannt ARP/Neighbor-Tabelle, Ping, TCP-Test und Switchinformationen prüfen

Lokale Listener prüfen

Betriebssystem Befehl
Windows [RO] Get-NetTCPConnection -State Listen
Linux [RO] ss -lntup
macOS [RO] sudo lsof -nP -iTCP -sTCP:LISTEN

Ein Port kann lokal lauschen und trotzdem aus dem untersuchten Netzsegment nicht erreichbar sein. Umgekehrt kann NAT oder Portweiterleitung einen extern erreichbaren Port zeigen, obwohl auf der Zieladresse selbst kein entsprechender lokaler Listener sichtbar ist.

26. Wie sieht ein sicherer Nmap-Diagnoseablauf aus?

Empfohlene Schrittfolge anzeigen

Vorbereitung

  1. Auftrag und Ziel der Prüfung dokumentieren.
  2. Zulässige Zieladressen und Ports festlegen.
  3. Scanquelle und Netzwerksegment dokumentieren.
  4. Empfindliche Systeme identifizieren.
  5. Erlaubte Scanarten und maximale Rate festlegen.
  6. Ansprechpartner und Abbruchkriterium festlegen.
  7. Systemzeit und Speicherort der Ergebnisse prüfen.

Zielkontrolle

  1. Zielbereich zuerst mit -sL -n auflisten.
  2. CIDR-Präfix und Ausschlüsse kontrollieren.
  3. Mit einem einzelnen Testsystem beginnen.

Schrittweise Prüfung

  1. Host Discovery mit -sn durchführen.
  2. Falls erforderlich einen bekannten Port mit -Pn prüfen.
  3. Nur benötigte Ports mit -p angeben.
  4. Zunächst TCP Connect oder SYN Scan verwenden.
  5. UDP nur für konkret benötigte Ports prüfen.
  6. --reason zur Interpretation hinzufügen.
  7. Versionserkennung nur bei Bedarf verwenden.
  8. NSE-Skripte einzeln prüfen und freigeben.
  9. Scanrate und Zielsystemüberwachung beobachten.

Dokumentation

  1. Ausgabe mit -oA speichern.
  2. Nmap-Version und verwendeten Befehl dokumentieren.
  3. Beginn, Ende und Scanquelle festhalten.
  4. Ergebnisse als Beobachtung und nicht sofort als Ursache dokumentieren.

Validierung

  1. Offene Ports mit einem Protokollwerkzeug prüfen.
  2. Gefilterte Ports mit Firewall-Logs und Paketmitschnitten untersuchen.
  3. Lokale Listener auf dem Zielsystem prüfen.
  4. Nach einer Änderung denselben Scan erneut ausführen.
  5. Ergebnisse vergleichen.
  6. Zuständige Personen über Abschluss oder Auffälligkeiten informieren.
  7. Scanresultate gemäß Schutz- und Löschrichtlinie behandeln.

27. Kurzreferenz – sichere Basisbefehle

Nmap-Befehlstabelle anzeigen
Aufgabe Befehl
Version anzeigen [RO] nmap --version
Hilfe anzeigen [RO] nmap -h
Zielbereich nur auflisten [RO][SENS] nmap -sL -n 192.0.2.0/28
Hosts erkennen [TEST][SENS] nmap -sn -n 192.0.2.0/28
Grund anzeigen [TEST][SENS] nmap -sn -n --reason 192.0.2.0/28
Einzelnen TCP-Port prüfen [TEST][SENS] nmap -Pn -n -sT -p 443 --reason 192.0.2.10
Mehrere TCP-Ports [TEST][SENS] nmap -sT -p 22,80,443 192.0.2.10
SYN-Scan [TEST][PRIV][SENS] sudo nmap -sS -p 22,80,443 192.0.2.10
UDP-Ports [TEST][PRIV][SENS] sudo nmap -sU -p 53,123,161 192.0.2.10
TCP und UDP [TEST][PRIV][SENS] sudo nmap -sS -sU -p T:53,80,443,U:53,123 192.0.2.10
Häufigste 100 Ports [TEST][SENS] nmap --top-ports 100 192.0.2.10
Alle TCP-Ports [TEST][SENS] nmap -p- 192.0.2.10
Nur offene Ports ausgeben [TEST][SENS] nmap --open -p 22,80,443 192.0.2.10
Dienstversionen vorsichtig prüfen [TEST][SENS] nmap -sV --version-light -p 22,80,443 192.0.2.10
Betriebssystem schätzen [TEST][PRIV][SENS] sudo nmap -O 192.0.2.10
IPv6-Ziel [TEST][SENS] nmap -6 -p 22,80,443 2001:db8::10
Scanrate begrenzen [TEST][SENS] nmap --max-rate 50 -p 1-1000 192.0.2.10
Ergebnisse vollständig speichern [TEST][FILE][SENS] nmap -sT -p 22,80,443 -oA server-scan 192.0.2.10
Skriptbeschreibung anzeigen [RO] nmap --script-help http-title
HTTP-Titel prüfen [TEST][SENS] nmap --script http-title -p 80,443 192.0.2.10

28. Kurzreferenz – wichtigste Optionen

Optionstabelle anzeigen
Option Bedeutung
-sL Ziele nur auflisten
-sn Nur Host Discovery, kein Portscan
-Pn Host Discovery überspringen
-n Keine DNS-Auflösung
-R Reverse-DNS-Auflösung erzwingen
-sT TCP Connect Scan
-sS TCP SYN Scan
-sU UDP Scan
-p Ports angeben
-p- Alle Ports von 1 bis 65.535
-F Schneller Scan mit reduzierter Portauswahl
--top-ports N N häufigste Ports prüfen
--open Nur offene oder möglicherweise offene Ports anzeigen
--reason Grund für Host- und Portbewertung anzeigen
-sV Dienst- und Versionserkennung
--version-light Reduzierte Versionserkennung
-O Betriebssystemerkennung
-6 IPv6 verwenden
-iL Ziele aus Datei lesen
--exclude Ziel ausschließen
--excludefile Ausschlüsse aus Datei lesen
-T2 Rücksichtsvolle Timing-Vorlage
-T3 Normale Timing-Vorlage
--max-rate Maximale durchschnittliche Paketrate begrenzen
--host-timeout Zeitlimit pro Host
-oN Normale Ausgabe speichern
-oX XML-Ausgabe speichern
-oG Grepbare Ausgabe speichern
-oA Alle Hauptformate speichern
-sC Standard-NSE-Skripte ausführen
--script Bestimmte NSE-Skripte auswählen
--script-help Beschreibung eines Skripts anzeigen

Merksätze

Quellen

2. Grundwerkzeuge und Befehle

2.8 iPerf3 – Bandbreite, Durchsatz, Jitter und Paketverlust messen

Ziel dieser Seite

iPerf3 erzeugt kontrollierten Netzwerkverkehr zwischen zwei Systemen und misst dabei die erreichbare Übertragungsleistung. Es hilft unter anderem bei der Untersuchung von:

iPerf3 besteht aus einem Server und einem Client:

iPerf3-Client → Netzwerkpfad → iPerf3-Server

Standardmäßig sendet der Client TCP-Testdaten an den Server. Mit -R wird die Richtung umgekehrt.

Wichtig: iPerf3 erzeugt aktiv Datenverkehr und kann eine Netzwerkverbindung vollständig auslasten. Tests dürfen nur zwischen autorisierten Systemen und mit abgestimmter Testdauer und Datenrate durchgeführt werden.

Kennzeichnungen

Kennzeichnung Bedeutung
[RO] Lokale Abfrage ohne Netzwerktest
[TEST] Aktiver Netzwerk- oder Leistungstest
[PRIV] Erhöhte Berechtigungen können erforderlich sein
[FILE] Befehl erstellt oder verarbeitet eine Datei
[SENS] Ausgabe kann sensible Infrastrukturinformationen enthalten
[CHANGE] Befehl verändert eine Einstellung oder Datei
[DISRUPT] Test kann Netzwerk, Endgeräte oder andere Verbindungen belasten

1. Was misst iPerf3 – und was misst es nicht?

Messumfang anzeigen
Messwert TCP UDP
Übertragene Datenmenge Ja Ja
Durchschnittlicher Durchsatz Ja Ja
Durchsatz je Messintervall Ja Ja
TCP-Wiederholungsübertragungen Systemabhängig, häufig auf Senderseite Nein
TCP Congestion Window Systemabhängig Nein
UDP-Jitter Nein Ja
UDP-Paketverlust Nein Ja
Verlorene Datagramme Nein Ja
Empfangene Datagramme Nein Ja
Reihenfolgefehler Teilweise über UDP-Zähler erkennbar Ja

iPerf3 misst den Durchsatz zwischen den beiden iPerf3-Prozessen. Das Ergebnis ist nicht automatisch identisch mit:

iPerf3 umgeht normalerweise folgende Anwendungsfaktoren

Dadurch kann iPerf3 helfen, Netzwerkpfad und Anwendung voneinander zu trennen:

iPerf3 schnell + Anwendung langsam
→ Ursache wahrscheinlich nicht ausschließlich der reine Netzwerkdurchsatz

iPerf3 langsam + Anwendung langsam
→ Netzwerkpfad oder beteiligte Systeme weiter untersuchen

2. Auf welchen Betriebssystemen wird iPerf3 offiziell unterstützt?

Betriebssystemübersicht anzeigen
Betriebssystem Offizielle ESnet-Unterstützung Hinweis
Linux Ja Vollständiger Haupteinsatzbereich
FreeBSD Ja Offiziell unterstützt
macOS Ja In der ESnet-Dokumentation als OSX bezeichnet
Windows Nein ESnet empfiehlt für Windows iPerf2
Andere Systeme Nicht generell zugesichert Funktionsumfang kann abweichen

Nach der offiziellen ESnet-FAQ wird iPerf3 nicht offiziell unter Windows unterstützt. Es existieren Community-Builds für Windows, bei denen jedoch nicht alle Optionen funktionieren müssen.

Konsequenz für dieses Buch

Ein iPerf3-Client benötigt einen iPerf3-Server. Ein iPerf2-Client benötigt einen iPerf2-Server.

3. Wie wird die installierte Version geprüft?

Versions- und Hilfebefehle anzeigen
Aufgabe Windows mit Community-Build Linux macOS
Programmpfad [RO] Get-Command iperf3 [RO] command -v iperf3 [RO] command -v iperf3
Version [RO] iperf3 --version [RO] iperf3 --version [RO] iperf3 --version
Kurzform der Version [RO] iperf3 -v [RO] iperf3 -v [RO] iperf3 -v
Hilfe [RO] iperf3 -h [RO] iperf3 -h [RO] iperf3 -h
Handbuch Nicht standardmäßig [RO] man iperf3 [RO] man iperf3

Die Version muss auf Client und Server dokumentiert werden:

Client: iPerf 3.x
Server: iPerf 3.x

Unterschiedliche iPerf3-Versionen funktionieren häufig miteinander, können aber:

Seit iPerf3 3.16 verwendet jeder parallele Teststream einen eigenen Thread. Ältere Versionen waren für den Testdatenverkehr grundsätzlich auf einen Thread begrenzt. Bei hohen Datenraten kann die verwendete Version deshalb das Ergebnis wesentlich beeinflussen.

4. Welche Freigaben müssen vor einem Leistungstest vorliegen?

Testplanung anzeigen
Punkt Beispiel
Client 192.0.2.10
Server 192.0.2.20
Port TCP/UDP 5201
Testprotokoll TCP und anschließend UDP
Testdauer 30 Sekunden je Richtung
Maximale UDP-Rate 100 Mbit/s
Parallelstreams Zunächst 1, anschließend 4
Netzwerkpfad Client-VLAN → Firewall → Server-VLAN
Testzeitraum Wartungsfenster
Verantwortliche Person Max Mustermann
Abbruchkriterium Hohe Last, Paketverlust anderer Anwendungen oder Alarmmeldung

Vorher prüfen:

Ein unbegrenzter TCP-Test versucht, so viel Bandbreite wie möglich zu verwenden. Auch ein zehn Sekunden langer Standardtest kann deshalb andere Verbindungen beeinflussen.

5. Welche Netzwerkverbindungen benötigt iPerf3?

Ports und Verbindungsaufbau anzeigen

Der iPerf3-Server lauscht standardmäßig auf Port 5201.

TCP-Test

Client → Server: TCP 5201

UDP-Test

Client → Server: TCP 5201 für Steuerung
Client → Server: UDP 5201 für Testdaten

Auch bei einem UDP-Test verwendet iPerf3 eine TCP-Steuerverbindung. Daher muss neben UDP 5201 auch TCP 5201 erreichbar sein.

Benutzerdefinierter Port

Server:

[TEST][DISRUPT] iperf3 -s -p 5002

Client:

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -p 5002

Für einen UDP-Test auf Port 5002 müssen gegebenenfalls beide Protokolle freigegeben sein:

TCP 5002
UDP 5002

Port vor dem Test prüfen

Windows:

[TEST] Test-NetConnection 192.0.2.20 -Port 5201

Linux:

[TEST] nc -vz 192.0.2.20 5201

macOS:

[TEST] nc -vz 192.0.2.20 5201

Ein erfolgreicher TCP-Porttest bestätigt nur die Steuerverbindung. Er bestätigt noch nicht, dass ein UDP-Testdatenstrom funktioniert.

6. Wie wird ein iPerf3-Server gestartet?

Serverbefehle anzeigen

Server auf dem Standardport 5201 starten

[TEST][DISRUPT] iperf3 -s

Server auf einem anderen Port

[TEST][DISRUPT] iperf3 -s -p 5002

Server an eine bestimmte lokale IP-Adresse binden

[TEST][DISRUPT] iperf3 -s -B 192.0.2.20

Server nur für einen Test starten und danach beenden

[TEST][DISRUPT] iperf3 -s -1

-1 beziehungsweise --one-off bedeutet:

Das ist für kontrollierte Einzeltests häufig sicherer als ein dauerhaft laufender Server.

Einmaliger Server auf bestimmter Adresse und bestimmtem Port

[TEST][DISRUPT] iperf3 -s -1 -B 192.0.2.20 -p 5201

Ausführliche Ausgabe

[TEST][DISRUPT] iperf3 -s -V

Serverausgabe in eine Datei schreiben

[TEST][FILE][SENS][DISRUPT] iperf3 -s --logfile iperf3-server.log --forceflush

--forceflush schreibt die Intervallergebnisse zeitnah in die Logdatei, statt sie länger zu puffern.

7. Wie wird der laufende Server kontrolliert?

Listener und Prozess prüfen

Linux: Listener prüfen

[RO] ss -lntp | grep ':5201'

macOS: Listener prüfen

[RO][PRIV] sudo lsof -nP -iTCP:5201 -sTCP:LISTEN

Windows mit Community-Build

[RO] Get-NetTCPConnection -LocalPort 5201 -State Listen

Prozess suchen

Linux:

[RO] pgrep -a iperf3

macOS:

[RO] pgrep -fl iperf3

Windows:

[RO] Get-Process iperf3 -ErrorAction SilentlyContinue

Nach dem Test sollte ein nicht mehr benötigter iPerf3-Server beendet werden. Bei Verwendung von -1 beendet er sich nach der Clientverbindung automatisch.

8. Wie wird ein grundlegender TCP-Test durchgeführt?

Standardtest anzeigen

Auf dem Server

[TEST][DISRUPT] iperf3 -s -1

Auf dem Client

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20

Standardmäßig:

Test für 30 Sekunden

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30

Ausgabe alle fünf Sekunden

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -i 5

Einheit Mbit/s erzwingen

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -f m

Serverausgabe zusätzlich am Client abrufen

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 --get-server-output

Die Serverausgabe wird nur abgerufen, wenn der Test vollständig abgeschlossen wird. Bei einem abgebrochenen Test kann sie fehlen.

9. Welche Richtung wird mit iPerf3 gemessen?

Normal-, Reverse- und Bidirektionstest anzeigen

Standardrichtung

Client → Server

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30

Dabei sendet der Client die Testdaten.

Umgekehrte Richtung

Server → Client

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R

-R wird auf dem Client angegeben, obwohl anschließend der Server die Testdaten sendet.

Beide Richtungen gleichzeitig

Client ↔ Server

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 --bidir

--bidir testet beide Richtungen gleichzeitig. Das erzeugt mehr Last als zwei getrennte Einzeltests und erschwert die Interpretation.

Empfohlene Reihenfolge

  1. Client zum Server testen.
  2. Server zum Client mit -R testen.
  3. Ergebnisse vergleichen.
  4. Erst bei begründetem Bedarf --bidir verwenden.

Mögliche Ursachen für unterschiedliche Richtungen

10. Wie wird ein UDP-Test sicher durchgeführt?

UDP-Test mit kontrollierter Datenrate anzeigen

Wichtiger Unterschied

Bei TCP passt das Protokoll die Senderate unter anderem anhand von Bestätigungen, Verlust und Überlastung an. Bei UDP muss eine gewünschte Senderate festgelegt werden.

Die iPerf3-Standardrate für UDP beträgt laut aktueller Dokumentation 1 Mbit/s.

UDP-Test mit 10 Mbit/s

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -t 30

UDP-Test mit 100 Mbit/s

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 100M -t 30

Umgekehrter UDP-Test

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 100M -t 30 -R

UDP-Test ohne iPerf3-interne Bitratenbegrenzung

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 0 -t 30

-b 0 deaktiviert die interne Begrenzung. Dadurch kann der Test sehr viel Verkehr erzeugen und erheblichen Paketverlust verursachen.

-b 0 sollte in produktiven Netzen nicht als erster Test verwendet werden.

Sichere Steigerung

10 Mbit/s → 25 Mbit/s → 50 Mbit/s → 100 Mbit/s

Nach jeder Stufe werden geprüft:

11. Wie werden UDP-Jitter und Paketverlust interpretiert?

UDP-Messwerte anzeigen

Eine UDP-Zusammenfassung kann sinngemäß enthalten:

0.00-30.00 sec  350 MBytes  97.9 Mbits/sec  0.250 ms  1250/250000 (0.5%)
Wert Bedeutung
350 MBytes Übertragene beziehungsweise empfangene Datenmenge
97.9 Mbits/sec Gemessene durchschnittliche Datenrate
0.250 ms Berechneter Jitter
1250/250000 Verlorene Datagramme im Verhältnis zur erwarteten Gesamtzahl
0.5% Berechnete Verlustquote

Jitter

Jitter beschreibt bei iPerf3 die Schwankung der Paketlaufzeit, nicht die absolute Latenz.

Daher gilt:

Niedriger Jitter ≠ automatisch niedrige Latenz

Für die absolute Laufzeit werden zusätzlich beispielsweise benötigt:

Paketverlust

Verlustquote = verlorene Datagramme / erwartete Datagramme × 100

Ein Paketverlust unter hoher UDP-Last bedeutet nicht automatisch einen Defekt. Er kann auch entstehen, weil:

Der Test sollte deshalb mit mehreren kontrollierten Datenraten wiederholt werden.

12. Wie wird die maximale UDP-Kapazität schrittweise angenähert?

Stufentest anzeigen

Beispiel für einen freigegebenen 100-Mbit/s-Pfad:

Stufe 1

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -t 30

Stufe 2

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 25M -t 30

Stufe 3

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 50M -t 30

Stufe 4

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 90M -t 30

Dokumentation

Zielrate Empfangsrate Paketverlust Jitter Bewertung
10 Mbit/s 10 Mbit/s 0 % 0,2 ms Unauffällig
25 Mbit/s 25 Mbit/s 0 % 0,3 ms Unauffällig
50 Mbit/s 49,8 Mbit/s 0,1 % 0,5 ms Beobachten
90 Mbit/s 72 Mbit/s 18 % 5,2 ms Kapazitätsgrenze überschritten

Die Werte in dieser Tabelle sind lediglich ein Rechen- und Dokumentationsbeispiel und keine allgemein gültigen Grenzwerte.

Die sinnvoll nutzbare Rate liegt unterhalb des Punktes, an dem Verlust und Jitter deutlich ansteigen.

13. Wie werden parallele TCP-Streams verwendet?

Parallelverbindungen `-P` anzeigen

Vier parallele TCP-Streams

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 4 -t 30

Acht parallele Streams

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 8 -t 30

Umgekehrte Richtung mit vier Streams

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 4 -t 30 -R

Seit iPerf3 3.16 verwendet jeder Teststream einen eigenen Thread. Dadurch können mehrere Streams mehrere CPU-Kerne nutzen.

Warum mehrere Streams mehr Durchsatz erreichen können

Wichtige Interpretation

1 Stream langsam
4 Streams schnell

bedeutet nicht automatisch, dass die Verbindung fehlerfrei ist. Eine einzelne Anwendung verwendet möglicherweise nur eine TCP-Verbindung und erreicht dann weiterhin den niedrigeren Wert.

Empfohlener Vergleich

Test Zweck
-P 1 Leistung einer einzelnen TCP-Verbindung
-P 4 Verhalten mehrerer paralleler Verbindungen
-P 8 Prüfung auf CPU-, Queue- oder Window-Limit
-R Vergleich der Gegenrichtung

14. Wie werden Testdauer, Datenmenge und Warmlaufphase festgelegt?

Zeit- und Mengenoptionen anzeigen

Testdauer

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 60

-t 60 testet 60 Sekunden.

Bestimmte Datenmenge übertragen

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -n 1G

Bestimmte Anzahl Blöcke übertragen

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -k 10000

Die Optionen -t, -n und -k schließen sich gegenseitig aus. Pro Test darf nur eine davon zur Begrenzung verwendet werden.

Erste fünf Sekunden nicht in die Statistik aufnehmen

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -O 5

-O 5 führt zunächst fünf Sekunden Warmlauf durch und lässt diese Messwerte aus der abschließenden Teststatistik heraus.

Das hilft, den Einfluss des TCP Slow Start auf die Zusammenfassung zu reduzieren.

Sinnvoller stabiler TCP-Test

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -O 5 -i 5

Die gesamte Verbindung besteht dabei aus Warmlaufphase und ausgewerteter Testphase. Die genaue Laufzeit ist daher länger als der reine Auswertungszeitraum.

15. Wie wird eine bestimmte lokale IP-Adresse verwendet?

Quelladresse und Schnittstellenbindung anzeigen

Ein System kann mehrere Netzwerkschnittstellen und IP-Adressen besitzen:

Client an eine lokale IP-Adresse binden

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -B 192.0.2.10

Server an eine lokale IP-Adresse binden

[TEST][DISRUPT] iperf3 -s -B 192.0.2.20

Linux: an ein Interface binden, sofern unterstützt

[TEST][PRIV][DISRUPT][SENS] sudo iperf3 -c 192.0.2.20 --bind-dev eth0

--bind-dev ist nicht auf allen Plattformen verfügbar und kann erhöhte Rechte erfordern.

Vorher prüfen

Windows:

[RO] Get-NetIPConfiguration

Linux:

[RO] ip address show

macOS:

[RO] ifconfig

Die Quelladresse beeinflusst:

16. Wie werden IPv4 und IPv6 getrennt getestet?

IPv4- und IPv6-Befehle anzeigen

IPv4 erzwingen

[TEST][DISRUPT][SENS] iperf3 -4 -c 192.0.2.20

IPv6 erzwingen

[TEST][DISRUPT][SENS] iperf3 -6 -c 2001:db8::20

IPv6-Reversetest

[TEST][DISRUPT][SENS] iperf3 -6 -c 2001:db8::20 -R

IPv6-Link-Local-Adresse

Bei einer Link-Local-Adresse muss die Schnittstelle beziehungsweise Zone angegeben werden:

[TEST][DISRUPT][SENS] iperf3 -6 -c fe80::20%en0

Der genaue Schnittstellenname ist betriebssystemspezifisch.

Vergleich

Test Ergebnis
IPv4 schnell, IPv6 langsam IPv6-Routing, MTU, Firewall oder Tunnel prüfen
IPv4 funktioniert, IPv6 nicht IPv6-Adresse, Route, Neighbor Discovery und Firewall prüfen
IPv6 funktioniert, IPv4 nicht IPv4-Routing, NAT oder Firewall prüfen
Beide langsam Gemeinsamen Netzwerkpfad und Endgeräte untersuchen

17. Wie werden Ergebnisse als JSON gespeichert?

JSON- und Logausgabe anzeigen

JSON im Terminal ausgeben

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -J

Linux und macOS: JSON in Datei schreiben

[TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 -J > iperf3-result.json

PowerShell mit Community-iPerf3

[TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 -J | Out-File -Encoding utf8 iperf3-result.json

Direkte Logdatei

[TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 --logfile iperf3-result.log

Zeitstempel hinzufügen

[TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 --timestamps --logfile iperf3-result.log

Zeilenweise JSON-Objekte während des Tests

[TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 --json-stream > iperf3-stream.jsonl

--json-stream ist eine neuere Funktion. Vor Verwendung muss geprüft werden, ob die installierte Version sie unterstützt.

Für eine vollständige Dokumentation festhalten

18. Wie werden TCP-Ergebnisse interpretiert?

TCP-Ausgabe erklären

Eine TCP-Ausgabe enthält am Ende typischerweise eine Sender- und eine Empfängerzeile:

[SUM] 0.00-30.00 sec  3.20 GBytes  916 Mbits/sec  sender
[SUM] 0.00-30.00 sec  3.19 GBytes  913 Mbits/sec  receiver
Feld Bedeutung
Intervall Ausgewerteter Zeitraum
Transfer Übertragene Datenmenge
Bitrate Durchschnittliche Übertragungsrate
Sender Messung aus Sicht des Senders
Receiver Messung aus Sicht des Empfängers
Retr TCP-Wiederholungsübertragungen, sofern verfügbar
Cwnd TCP Congestion Window, sofern ausgegeben

Sender und Receiver

Die Werte können geringfügig voneinander abweichen, beispielsweise durch:

Bei sehr kurzen Tests kann die Differenz stärker auffallen. Die ESnet-FAQ weist darauf hin, dass Testdaten noch unterwegs sein können, wenn die Steuerverbindung bereits das Testende verarbeitet.

Retransmissions

Viele Wiederholungsübertragungen können hinweisen auf:

Sie beweisen allein jedoch noch keine bestimmte Ursache.

Schwankender Durchsatz

Mögliche Ursachen:

19. Wie wird geprüft, ob Client oder Server der Engpass ist?

Endgerätevergleich anzeigen

1. Normalrichtung

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30

2. Gegenrichtung

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R

3. Einzelstream

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 1 -t 30

4. Vier Streams

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 4 -t 30

5. CPU-Auslastung parallel beobachten

Linux:

[RO] top

macOS:

[RO] top

Windows:

[RO] Get-Counter '\Processor(_Total)\% Processor Time'

Interpretationsbeispiele

Beobachtung Mögliche Ursache
Normalrichtung langsam, Reverse schnell Senderseite des Clients oder Empfängerseite des Servers prüfen
Normalrichtung schnell, Reverse langsam Senderseite des Servers oder Empfängerseite des Clients prüfen
Ein Stream langsam, mehrere schnell Einzelstream-, Latenz-, TCP-Window- oder CPU-Limit
Beide Richtungen gleich langsam Gemeinsamer Pfad, Linkrate, Firewall, VPN oder CPU
CPU erreicht 100 % Endsystem möglicherweise Messgrenze
Durchsatz schwankt mit CPU Verarbeitungslimit wahrscheinlich
Nur WLAN langsam Funkstrecke, Kanal, Signal oder Airtime prüfen
LAN schnell, VPN langsam VPN-Gateway, Verschlüsselung, MTU oder Routing prüfen

20. Wie werden Netzwerkkarten- und Interface-Zähler einbezogen?

Betriebssystemspezifische Kontrollbefehle anzeigen

Windows

[RO] Get-NetAdapter

[RO] Get-NetAdapterStatistics

[RO] Get-NetAdapter | Select-Object Name, Status, LinkSpeed

Linux

[RO] ip -s link show

[RO] ethtool eth0

[RO][PRIV] sudo ethtool -S eth0

macOS

[RO] ifconfig en0

[RO] netstat -ib

Vor und nach dem iPerf3-Test vergleichen

Zu prüfen sind unter anderem:

Ein iPerf3-Ergebnis ohne Interface- und Systemauslastung zeigt nur den gemessenen End-to-End-Durchsatz, aber nicht automatisch die Engpassstelle.

21. Welche Rolle spielen MTU, MSS und Paketgröße?

MTU- und Längenoptionen anzeigen

TCP Maximum Segment Size setzen

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -M 1460

-M setzt die gewünschte TCP-MSS. Der tatsächlich verwendete Wert kann durch Betriebssystem und Netzwerkpfad beeinflusst werden.

Für Ethernet mit einer MTU von 1500 Byte ergibt sich bei IPv4 ohne zusätzliche Optionen häufig:

1500 Byte MTU
- 20 Byte IPv4-Header
- 20 Byte TCP-Header
= 1460 Byte TCP-MSS

Bei IPv6 sind die Basisheader größer:

1500 Byte MTU
- 40 Byte IPv6-Header
- 20 Byte TCP-Header
= 1440 Byte TCP-MSS

Zusätzliche Header, TCP-Optionen, VLAN, VPN oder Tunnel können die nutzbare Größe beeinflussen.

iPerf3-Puffer- beziehungsweise Blocklänge

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -l 512

-l bestimmt die Länge des von iPerf3 gelesenen oder geschriebenen Puffers. Sie ist nicht identisch mit der Ethernet-Framegröße.

UDP mit bestimmter Datagrammlänge

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -l 1200

IPv4-UDP mit gesetztem Don't-Fragment-Bit

[TEST][DISRUPT][SENS] iperf3 -4 -c 192.0.2.20 -u -b 10M -l 1400 --dont-fragment

--dont-fragment gilt nach der offiziellen Dokumentation nur für UDP über IPv4.

Größenoptionen sollten nur gezielt verändert werden. Ungeeignete Werte können Fragmentierung, Verluste oder irreführende Ergebnisse verursachen.

22. Warum kann der TCP-Durchsatz plötzlich fast auf null fallen?

Offloading- und Segmentierungsprobleme anzeigen

Nach der offiziellen ESnet-FAQ kann ein fast vollständig einbrechender TCP-Durchsatz unter anderem mit fehlerhaftem TCP-Offloading zusammenhängen.

Mögliche beteiligte Funktionen:

Diagnosevergleich

Normalrichtung

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30

Reverse-Richtung

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R

Kleinere Schreibgröße

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -l 512

MSS testweise begrenzen

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -M 1460

Zusätzliche Prüfung

Das Deaktivieren von Offloading ist eine Systemänderung und kann die Leistung beeinflussen. Es sollte erst nach dokumentierter Diagnose, Freigabe und mit Rückfallplan erfolgen.

23. Wie werden WLAN-Verbindungen sinnvoll getestet?

WLAN-Testaufbau anzeigen

Ein geeigneter WLAN-Testaufbau ist:

WLAN-Client
    ↓ Funkstrecke
Access Point
    ↓ Ethernet
Kabelgebundener iPerf3-Server

Der Server sollte möglichst per Ethernet angebunden sein. Sind Client und Server beide im WLAN, teilen sie sich möglicherweise dieselbe Funkzeit. Das Ergebnis enthält dann zwei Funkübertragungen und ist schwerer zu interpretieren.

Empfohlene Tests

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -t 30

Die UDP-Rate wird anschließend vorsichtig erhöht.

Zusätzlich dokumentieren

Wichtiger Unterschied

WLAN-Linkrate ≠ nutzbarer TCP-Durchsatz

Die angezeigte PHY-Rate enthält Protokoll-, Funk-, Bestätigungs- und Verwaltungsanteile. Der tatsächlich nutzbare TCP-Durchsatz ist daher niedriger.

24. Wie werden VPN- und Standortverbindungen untersucht?

Vergleichsmessungen anzeigen

Messung ohne VPN

Client → lokaler iPerf3-Server

Messung durch VPN

Client → VPN-Tunnel → entfernter iPerf3-Server

Normalrichtung

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30

Reverse-Richtung

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R

UDP mit kontrollierter Rate

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 20M -t 30

Mögliche VPN-Engpässe

Vergleichstabelle

Test Ohne VPN Mit VPN
TCP Client → Server 940 Mbit/s 180 Mbit/s
TCP Server → Client 940 Mbit/s 350 Mbit/s
UDP ohne Verlust 800 Mbit/s 150 Mbit/s
Jitter 0,2 ms 3,5 ms

Diese Zahlen sind nur ein Dokumentationsbeispiel. Sie stellen keine allgemeinen Sollwerte dar.

25. Wie wird zwischen Netzwerk- und Speicherproblem unterschieden?

iPerf3 und Dateiübertragung vergleichen

Netzwerktest

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30

Anschließend reale Dateiübertragung prüfen

Beispielsweise:

Interpretation

iPerf3 Dateiübertragung Mögliche Ursache
Schnell Schnell Grundsätzlich unauffällig
Schnell Langsam Speicher, Dateisystem, Protokoll, Virenscan oder Anwendung
Langsam Langsam Netzwerkpfad oder Endsysteme weiter prüfen
Schwankend Schwankend Paketverlust, WLAN, CPU, QoS oder konkurrierender Verkehr

iPerf3 bietet außerdem -F, um eine Datei als Datenquelle oder -senke zu verwenden:

[TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 -F testfile.bin

Diese Funktion bezieht Speicherzugriffe in die Messung ein.

-F macht iPerf3 nicht zu einem zuverlässigen Dateiübertragungsprogramm. Die empfangene Datei kann sich in Länge, Eigenschaften oder Inhalt vom Original unterscheiden.

26. Welche typischen Fehler treten bei iPerf3 auf?

Fehlertabelle anzeigen
Fehler oder Beobachtung Mögliche Ursache Prüfung
command not found iPerf3 nicht installiert oder nicht im Suchpfad command -v iperf3 beziehungsweise Get-Command iperf3
unable to connect to server Server läuft nicht, falsche IP oder Firewall Listener und TCP-Port 5201 prüfen
Connection refused Ziel erreichbar, aber kein Listener am Port Serverprozess und Port prüfen
Connection timed out Firewall, Routing oder Rückwegproblem Nmap, Traceroute und Paketmitschnitt
UDP-Test startet nicht TCP-Steuerverbindung fehlt TCP 5201 prüfen
TCP funktioniert, UDP nicht UDP-Port gefiltert oder falsche Firewallregel UDP-Freigabe und Paketmitschnitt
Ergebnis viel niedriger als Linkrate Protokolloverhead, CPU, Verlust oder Pfadbegrenzung CPU, Interface-Zähler und Gegenrichtung
Reverse deutlich schneller Asymmetrie oder unterschiedlicher Endgeräteengpass Sender- und Empfängerseite vergleichen
Ein Stream langsam, mehrere schnell Einzelstream-, Window-, Latenz- oder CPU-Limit -P 1 und -P 4 vergleichen
Hoher UDP-Verlust Zielrate zu hoch oder Empfangspfad überlastet Rate schrittweise reduzieren
Hoher Jitter Warteschlangen, WLAN, Überlastung oder QoS geringere Rate und paralleles Monitoring
TCP bricht fast auf null ein Mögliches Offloading- oder MTU-Problem -R, -l, -M und Paketmitschnitt
Ergebnis schwankt stark Test zu kurz oder konkurrierender Verkehr längerer Test und Monitoring
Windows-Option funktioniert nicht Community-Build nicht vollständig kompatibel Buildquelle und unterstützte Optionen prüfen
Server bleibt erreichbar Server ohne -1 gestartet Prozess kontrolliert beenden
JSON-Datei leer Test nicht abgeschlossen oder Ausgabeproblem Befehl ohne Umleitung testen
Port bereits belegt Anderer iPerf3-Prozess oder Dienst Listener des Ports prüfen

27. Welche Fehlinterpretationen müssen vermieden werden?

Prüfungs- und Praxisfallen anzeigen
Fehlinterpretation Richtige Einordnung
iPerf3 zeigt die Internetgeschwindigkeit Es misst nur zwischen dem iPerf3-Client und -Server
1-Gbit/s-Link muss exakt 1 Gbit/s TCP erreichen Protokoll- und Systemanteile reduzieren den Nutzdurchsatz
Hoher TCP-Durchsatz bedeutet null Paketverlust TCP kann Verlust durch Wiederholungen ausgleichen
UDP-Verlust bedeutet defektes Kabel Die konfigurierte Senderate kann zu hoch sein
Jitter ist dasselbe wie Latenz Jitter ist die Schwankung der Laufzeit
-R wird auf dem Server eingegeben -R wird am Client angegeben
UDP verwendet nur UDP 5201 Die Steuerverbindung verwendet weiterhin TCP
Mehrere Streams zeigen die Leistung einer einzelnen Anwendung Eine Anwendung kann nur einen Stream verwenden
--bidir entspricht zwei getrennten Tests Gleichzeitiger Verkehr beeinflusst beide Richtungen
Ein kurzer Test ist immer aussagekräftig TCP Slow Start und kurzfristige Schwankungen beeinflussen ihn
iPerf3 prüft Festplattenleistung Standardmäßig werden synthetische Daten verwendet
iPerf3 und iPerf2 sind kompatibel Beide Werkzeuge verwenden unterschiedliche Protokolle
Community-iPerf3 unter Windows ist offiziell unterstützt ESnet unterstützt iPerf3 unter Windows nicht offiziell
Höchstmögliche Rate ist automatisch der richtige Test Produktive Netze müssen kontrolliert und stufenweise getestet werden

28. Wie sieht ein systematischer iPerf3-Diagnoseablauf aus?

Empfohlene Schrittfolge anzeigen

Vorbereitung

  1. Fehlerbild und erwarteten Durchsatz dokumentieren.
  2. Client, Server und Netzwerkpfad festlegen.
  3. Testgenehmigung und Wartungszeitraum prüfen.
  4. Maximale Testdauer und Datenrate festlegen.
  5. iPerf3-Versionen auf beiden Endpunkten dokumentieren.
  6. CPU-, Interface- und Monitoringansichten vorbereiten.
  7. Firewallfreigabe für TCP und gegebenenfalls UDP prüfen.

Server

  1. Server möglichst kabelgebunden und leistungsfähig auswählen.
  2. Server an die richtige Adresse binden.
  3. Für Einzeltests möglichst -1 verwenden.
  4. Listener auf Port 5201 kontrollieren.

Basistest

  1. TCP-Einzelstream für 30 Sekunden durchführen.
  2. TCP-Reverse-Test durchführen.
  3. Sender- und Receiverwerte dokumentieren.
  4. CPU- und Interface-Zähler prüfen.

Vertiefung

  1. Vier parallele Streams testen.
  2. Ergebnis mit Einzelstream vergleichen.
  3. UDP bei niedriger Rate beginnen.
  4. Rate schrittweise erhöhen.
  5. Jitter und Paketverlust dokumentieren.
  6. IPv4 und IPv6 bei Bedarf getrennt testen.
  7. WLAN-, VPN- oder VLAN-Pfade separat vergleichen.

Analyse

  1. Langsamen Pfad mit Ping, Traceroute und Paketmitschnitt untersuchen.
  2. Firewall-, Switch- und VPN-Monitoring vergleichen.
  3. MTU, MSS und Offloading nur bei konkreten Hinweisen untersuchen.
  4. iPerf3-Ergebnis mit realer Anwendung vergleichen.

Abschluss

  1. Testbefehle und Ergebnisse speichern.
  2. Temporäre Firewallfreigaben zurücknehmen.
  3. Nicht mehr benötigten Serverprozess beenden.
  4. Beobachtung, Hypothese, Änderung und Nachtest dokumentieren.

29. Kurzreferenz – iPerf3-Befehle

Befehlstabelle anzeigen
Aufgabe Befehl
Version [RO] iperf3 --version
Hilfe [RO] iperf3 -h
Server starten [TEST][DISRUPT] iperf3 -s
Server für einen Test [TEST][DISRUPT] iperf3 -s -1
Server an IP binden [TEST][DISRUPT] iperf3 -s -B 192.0.2.20
Anderen Port verwenden [TEST][DISRUPT] iperf3 -s -p 5002
TCP-Standardtest [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20
30 Sekunden testen [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30
Gegenrichtung [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R
Beide Richtungen gleichzeitig [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 --bidir
Vier TCP-Streams [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 4 -t 30
UDP mit 10 Mbit/s [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -t 30
UDP mit 100 Mbit/s [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 100M -t 30
Reverse-UDP [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 100M -t 30 -R
Warmlaufphase auslassen [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -O 5
Lokale IP binden [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -B 192.0.2.10
IPv4 erzwingen [TEST][DISRUPT][SENS] iperf3 -4 -c 192.0.2.20
IPv6 erzwingen [TEST][DISRUPT][SENS] iperf3 -6 -c 2001:db8::20
JSON-Ausgabe [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -J
Logdatei [TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 --logfile result.log
Serverausgabe abrufen [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 --get-server-output
MSS setzen [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -M 1460
Pufferlänge setzen [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -l 512

30. Kurzreferenz – wichtigste Optionen

Optionstabelle anzeigen
Option Bedeutung
-s Servermodus
-c HOST Clientmodus und Zielserver
-p PORT Server- beziehungsweise Zielport
-1 Server nach einer Clientverbindung beenden
-t SEKUNDEN Testdauer
-n MENGE Zu übertragende Datenmenge
-k ANZAHL Anzahl zu übertragender Blöcke
-i SEKUNDEN Ausgabeintervall
-f m Ausgabe beispielsweise in Mbit/s
-R Testrichtung umkehren
--bidir Beide Richtungen gleichzeitig testen
-u UDP statt TCP
-b RATE Zielbitrate setzen
-P ANZAHL Parallele Streams
-O SEKUNDEN Warmlaufzeit aus Statistik auslassen
-B ADRESSE An lokale IP-Adresse binden
--bind-dev An ein Interface binden, sofern unterstützt
-4 IPv4 erzwingen
-6 IPv6 erzwingen
-J JSON-Ausgabe
--json-stream Zeilenweise JSON-Ausgabe
--logfile Ausgabe in Logdatei
--forceflush Ausgabe je Intervall sofort schreiben
--timestamps Zeitstempel voranstellen
--get-server-output Serverausgabe am Client abrufen
-M TCP-MSS festlegen
-l Puffer- beziehungsweise UDP-Datagrammlänge
-w Socketpuffergröße setzen
-N Nagle-Algorithmus für TCP/SCTP deaktivieren
-Z Zero-Copy-Sendemethode verwenden
--dont-fragment IPv4-DF-Bit bei UDP setzen

Merksätze

Quellen

2. Grundwerkzeuge und Befehle

2.9 curl – HTTP-, HTTPS-, API-, DNS-, Proxy- und Verbindungsdiagnose

Ziel dieser Seite

curl überträgt Daten anhand einer URL und eignet sich besonders zur Diagnose von Webdiensten und APIs. Administratoren können damit unter anderem prüfen:

curl ist kein vollständiger Browser. JavaScript, grafische Darstellung, Browser-Erweiterungen und komplexe Browser-Sitzungen werden nicht wie in einem normalen Webbrowser ausgeführt.

Kennzeichnungen

Kennzeichnung Bedeutung
[RO] Lokale Informationsabfrage
[TEST] Aktive Netzwerk- oder Anwendungsanfrage
[PRIV] Erhöhte Berechtigungen können erforderlich sein
[FILE] Befehl liest oder erstellt eine Datei
[SENS] Anfrage oder Ausgabe kann sensible Informationen enthalten
[CHANGE] Anfrage kann Daten oder einen Zustand verändern
[DISRUPT] Anfrage kann einen Dienst oder produktive Daten beeinflussen

1. Wie wird curl unter Windows, Linux und macOS aufgerufen?

Betriebssystemübersicht anzeigen
Aufgabe Windows Linux macOS
Programmpfad [RO] Get-Command curl.exe [RO] command -v curl [RO] command -v curl
Version [RO] curl.exe --version [RO] curl --version [RO] curl --version
Kurzhilfe [RO] curl.exe --help [RO] curl --help [RO] curl --help
Gesamte Hilfe [RO] curl.exe --manual [RO] curl --manual [RO] curl --manual
Lokales Handbuch Nicht standardmäßig [RO] man curl [RO] man curl

Wichtig unter Windows PowerShell

In älteren Windows-PowerShell-Versionen kann curl als Alias für Invoke-WebRequest definiert sein. Dann verhält sich der Befehl nicht wie das echte curl-Programm.

Deshalb unter Windows eindeutig verwenden:

[RO] curl.exe --version

Alias prüfen:

[RO] Get-Command curl

Wenn als Befehlstyp Alias und als Ziel Invoke-WebRequest erscheint, muss für die in dieser Seite gezeigte Syntax ausdrücklich curl.exe verwendet werden.

Build-Funktionen prüfen

[RO] curl --version

Die Ausgabe zeigt unter anderem:

Nicht jede curl-Installation unterstützt alle Optionen und Protokolle. Entscheidend ist der lokal installierte Build.

2. Was passiert bei einem einfachen curl-Aufruf?

Grundlegende Anfrage anzeigen

Linux und macOS:

[TEST][SENS] curl https://example.com/

Windows:

[TEST][SENS] curl.exe https://example.com/

Ohne weitere Optionen schreibt curl den empfangenen Antwortinhalt auf die Standardausgabe.

Bei einer HTML-Seite erscheint daher der HTML-Quelltext:

<!doctype html>
<html>
...
</html>

Explizites URL-Schema verwenden

Empfohlen:

https://example.com/

Nicht empfohlen:

example.com

Ohne Schema versucht curl, das Protokoll zu erraten. Für reproduzierbare Diagnosen sollte immer ausdrücklich http:// oder https:// angegeben werden.

URL in Anführungszeichen setzen

[TEST][SENS] curl 'https://example.com/search?q=test&lang=de'

Besonders Zeichen wie diese können von einer Shell interpretiert werden:

&
?
*
[
]
{
}

In PowerShell und klassischen Windows-Kommandozeilen können sich die Regeln für Anführungszeichen unterscheiden. Bei einfachen URLs funktionieren doppelte Anführungszeichen meist plattformübergreifend:

[TEST][SENS] curl "https://example.com/search?q=test&lang=de"

3. Wie werden HTTP-Header angezeigt?

Headeroptionen anzeigen

Nur Antwortheader anfordern

[TEST][SENS] curl -I https://example.com/

-I beziehungsweise --head veranlasst curl bei HTTP, eine HEAD-Anfrage zu senden.

Header und Antwortinhalt anzeigen

[TEST][SENS] curl -i https://example.com/

-i fügt die Antwortheader vor dem Inhalt ein.

Antwortheader separat auf die Standardausgabe schreiben

[TEST][SENS] curl -D - https://example.com/

Header in eine Datei schreiben

[TEST][FILE][SENS] curl -D response-headers.txt -o response-body.html https://example.com/

Wichtiger Unterschied

Option Wirkung
-I Sendet bei HTTP eine HEAD-Anfrage
-i Zeigt Header und Antwortinhalt einer normalen Anfrage
-D DATEI Schreibt empfangene Header separat
-o DATEI Schreibt den Antwortinhalt in eine Datei

Nicht jeder Server behandelt HEAD und GET identisch. Ein erfolgreicher HEAD-Test beweist deshalb nicht sicher, dass ein GET-Aufruf denselben Status erhält.

GET ausführen, aber Antwortinhalt verwerfen

Linux und macOS:

[TEST][SENS] curl -sS -o /dev/null -D - https://example.com/

Windows:

[TEST][SENS] curl.exe -sS -o NUL -D - https://example.com/

Damit wird eine normale GET-Anfrage durchgeführt, ohne den vollständigen Inhalt im Terminal auszugeben.

4. Wie wird nur der HTTP-Statuscode ausgegeben?

Statuscode-Prüfung anzeigen

Linux und macOS:

[TEST] curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/

Windows:

[TEST] curl.exe -sS -o NUL -w "%{http_code}\n" https://example.com/

Statuscode und Ziel-URL nach Weiterleitungen

Linux und macOS:

[TEST] curl -sS -L -o /dev/null -w "HTTP=%{http_code} URL=%{url_effective}\n" https://example.com/

Windows:

[TEST] curl.exe -sS -L -o NUL -w "HTTP=%{http_code} URL=%{url_effective}\n" https://example.com/

HTTP-Statusgruppen

Bereich Bedeutung
100–199 Information
200–299 Erfolgreiche Verarbeitung
300–399 Weiterleitung
400–499 Anfrage- oder Clientfehler
500–599 Serverfehler

Häufige Statuscodes

Status Bedeutung
200 OK Anfrage erfolgreich
201 Created Ressource erstellt
204 No Content Erfolgreich, aber ohne Antwortinhalt
301 Moved Permanently Dauerhafte Weiterleitung
302 Found Temporäre Weiterleitung
304 Not Modified Ressource seit Cacheprüfung nicht geändert
307 Temporary Redirect Temporäre Weiterleitung unter Beibehaltung der Methode
308 Permanent Redirect Dauerhafte Weiterleitung unter Beibehaltung der Methode
400 Bad Request Anfrage syntaktisch oder fachlich ungültig
401 Unauthorized Authentifizierung fehlt oder ist ungültig
403 Forbidden Anfrage verstanden, Zugriff verweigert
404 Not Found Ressource nicht gefunden
405 Method Not Allowed HTTP-Methode nicht erlaubt
408 Request Timeout Server wartete zu lange auf die Anfrage
409 Conflict Konflikt mit aktuellem Ressourcenstatus
429 Too Many Requests Rate Limit erreicht
500 Internal Server Error Interner Serverfehler
502 Bad Gateway Gateway oder Proxy erhielt ungültige Upstream-Antwort
503 Service Unavailable Dienst momentan nicht verfügbar
504 Gateway Timeout Gateway erhielt nicht rechtzeitig eine Upstream-Antwort

Ein HTTP-Fehlercode bedeutet, dass die HTTP-Kommunikation grundsätzlich stattgefunden hat. DNS, TCP und normalerweise auch TLS waren bis zu diesem Punkt bereits erfolgreich.

5. Warum liefert curl bei einem HTTP-Fehler trotzdem Exitcode 0?

HTTP-Status und curl-Exitcode unterscheiden

Ohne --fail bewertet curl eine erfolgreich empfangene HTTP-Antwort als erfolgreiche Übertragung – auch wenn der Server beispielsweise 404 oder 500 zurückgibt.

HTTP-Statuscode 404
curl-Exitcode 0

Das bedeutet:

Übertragung technisch erfolgreich
Anwendung meldet HTTP-Fehler

Bei HTTP-Fehlern mit Exitcode ungleich 0 beenden

[TEST] curl --fail https://example.com/missing

Kurzform:

[TEST] curl -f https://example.com/missing

HTTP-Fehlercode liefern und Antwortinhalt behalten

[TEST][SENS] curl --fail-with-body https://example.com/missing

--fail-with-body:

Für Skripte häufig sinnvoll

[TEST] curl -sS --fail-with-body https://example.com/health
Option Verhalten
-s Fortschrittsanzeige unterdrücken
-S Fehlermeldung trotz -s anzeigen
--fail-with-body HTTP-Fehler als curl-Fehler behandeln und Inhalt behalten

6. Wie werden Weiterleitungen untersucht?

Redirect-Diagnose anzeigen

Nur erste Antwort anzeigen

[TEST][SENS] curl -I http://example.com/

Mögliche Ausgabe:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/

Weiterleitungen automatisch verfolgen

[TEST][SENS] curl -L http://example.com/

Header aller Weiterleitungsstufen anzeigen

[TEST][SENS] curl -L -I http://example.com/

Maximale Anzahl Weiterleitungen begrenzen

[TEST][SENS] curl -L --max-redirs 5 https://example.com/

Effektive Ziel-URL ausgeben

Linux und macOS:

[TEST] curl -sS -L -o /dev/null -w "%{url_effective}\n" http://example.com/

Windows:

[TEST] curl.exe -sS -L -o NUL -w "%{url_effective}\n" http://example.com/

Typische Redirect-Probleme

--location-trusted kann Zugangsdaten auch an andere Weiterleitungsziele weitergeben. Diese Option sollte aus Sicherheitsgründen nicht unüberlegt verwendet werden.

7. Wie wird eine ausführliche Verbindungsdiagnose durchgeführt?

Verbose-Ausgabe `-v` anzeigen 
[TEST][SENS] curl -v https://example.com/

Die ausführliche Ausgabe enthält unter anderem:

Kennzeichnungen in der Ausgabe

Zeichen Bedeutung
* curl-interne Status- oder Verbindungsinformation
> Von curl an den Server gesendete Daten beziehungsweise Header
< Vom Server empfangene Daten beziehungsweise Header
{ oder } In bestimmten Trace-Ausgaben übertragene Daten

Beispiel:

> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/...
> Accept: */*

< HTTP/1.1 200 OK
< Content-Type: text/html
< Content-Length: 1256

Nur Header und Verbindungsinformationen, Inhalt verwerfen

Linux und macOS:

[TEST][SENS] curl -v -o /dev/null https://example.com/

Windows:

[TEST][SENS] curl.exe -v -o NUL https://example.com/

Die Verbose-Ausgabe kann Zugangsdaten, Cookies, API-Token oder interne Header enthalten. Sie muss vor einer Weitergabe geprüft und bereinigt werden.

8. Wie wird eine detaillierte Ablaufverfolgung erstellt?

Trace-Optionen anzeigen

ASCII-Trace in eine Datei schreiben

[TEST][FILE][SENS] curl --trace-ascii curl-trace.txt https://example.com/

Trace mit Zeitstempeln

[TEST][FILE][SENS] curl --trace-time --trace-ascii curl-trace.txt https://example.com/

Binären Trace schreiben

[TEST][FILE][SENS] curl --trace curl-trace.bin https://example.com/

Ein Trace kann deutlich mehr Informationen als -v enthalten, darunter:

Trace-Dateien sind daher als sensible Diagnosedaten zu behandeln.

Nicht gleichzeitig unkontrolliert verwenden

-v
--trace
--trace-ascii

--trace beziehungsweise --trace-ascii überschreibt die frühere Auswahl der Trace-Ausgabe. Für eine reproduzierbare Diagnose sollte nur die tatsächlich benötigte Variante verwendet werden.

9. Wie werden DNS-, TCP-, TLS- und Serverzeiten gemessen?

Zeitmessung mit `--write-out` anzeigen

Linux und macOS:

[TEST] curl -sS -o /dev/null -w "DNS=%{time_namelookup}s TCP=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s Gesamt=%{time_total}s HTTP=%{http_code}\n" https://example.com/

Windows:

[TEST] curl.exe -sS -o NUL -w "DNS=%{time_namelookup}s TCP=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s Gesamt=%{time_total}s HTTP=%{http_code}\n" https://example.com/

Bedeutung der Zeitwerte

Variable Bedeutung
time_namelookup Zeit bis zum Abschluss der Namensauflösung
time_connect Zeit vom Start bis zur hergestellten TCP-Verbindung
time_appconnect Zeit bis zum Abschluss des TLS- oder anderen Anwendungs-Handshakes
time_pretransfer Zeit bis unmittelbar vor Beginn der Übertragung
time_starttransfer Zeit bis zum ersten empfangenen Antwortbyte
time_redirect Gesamtdauer vorheriger Weiterleitungen
time_total Gesamtdauer der Übertragung
http_code Letzter empfangener HTTP-Statuscode
remote_ip Tatsächlich verwendete Ziel-IP-Adresse
remote_port Tatsächlich verwendeter Zielport
local_ip Verwendete lokale IP-Adresse
num_redirects Anzahl verfolgter Weiterleitungen
url_effective Effektive URL nach Weiterleitungen

Erweiterte Messung

Linux und macOS:

[TEST] curl -sS -L -o /dev/null -w "Lokal=%{local_ip} Remote=%{remote_ip}:%{remote_port} DNS=%{time_namelookup}s TCP=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s Redirect=%{time_redirect}s Gesamt=%{time_total}s Status=%{http_code} Redirects=%{num_redirects} URL=%{url_effective}\n" https://example.com/

Windows:

[TEST] curl.exe -sS -L -o NUL -w "Lokal=%{local_ip} Remote=%{remote_ip}:%{remote_port} DNS=%{time_namelookup}s TCP=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s Redirect=%{time_redirect}s Gesamt=%{time_total}s Status=%{http_code} Redirects=%{num_redirects} URL=%{url_effective}\n" https://example.com/

10. Wie werden Zeitmessungen richtig interpretiert?

Zeitanteile einordnen

Die Zeitvariablen sind überwiegend kumulativ seit Beginn des curl-Aufrufs. Für einzelne Phasen müssen Differenzen gebildet werden.

DNS-Dauer

DNS = time_namelookup

TCP-Aufbau nach DNS

TCP-Phase = time_connect - time_namelookup

TLS-Handshake nach TCP-Aufbau

TLS-Phase = time_appconnect - time_connect

Serververarbeitung bis zum ersten Byte

Bei HTTPS vereinfacht:

Server-/Anwendungsphase = time_starttransfer - time_appconnect

Übertragung nach dem ersten Byte

Downloadphase = time_total - time_starttransfer

Beispiel

Messwert Wert
time_namelookup 0,020 s
time_connect 0,050 s
time_appconnect 0,120 s
time_starttransfer 0,420 s
time_total 0,500 s

Daraus folgt:

DNS = 0,020 s
TCP = 0,050 - 0,020 = 0,030 s
TLS = 0,120 - 0,050 = 0,070 s
Server bis erstes Byte = 0,420 - 0,120 = 0,300 s
Restliche Übertragung = 0,500 - 0,420 = 0,080 s

Diese Zuordnung ist eine Diagnosehilfe. Proxys, wiederverwendete Verbindungen, Weiterleitungen und unterschiedliche Protokolle können die Interpretation verändern.

11. Wie werden Verbindungs- und Gesamtzeit begrenzt?

Timeouts anzeigen

Maximal fünf Sekunden für den Verbindungsaufbau

[TEST] curl --connect-timeout 5 https://example.com/

Maximal 15 Sekunden für den gesamten Vorgang

[TEST] curl --max-time 15 https://example.com/

Kurzform:

[TEST] curl -m 15 https://example.com/

Kombination

[TEST] curl --connect-timeout 5 --max-time 15 https://example.com/
Option Begrenzter Bereich
--connect-timeout Verbindungsphase einschließlich notwendiger DNS-, TCP- und gegebenenfalls Proxy-/TLS-Vorgänge bis zur Verbindung
--max-time Gesamter curl-Vorgang

Langsame Übertragung abbrechen

[TEST] curl --speed-limit 1000 --speed-time 10 https://example.com/large-file

Der Vorgang wird abgebrochen, wenn die Übertragungsrate während des festgelegten Zeitraums unter dem Grenzwert liegt.

Zu kurze Timeouts können langsame, aber funktionierende Verbindungen fälschlich als Fehler erscheinen lassen.

12. Wie werden IPv4 und IPv6 getrennt geprüft?

IPv4-/IPv6-Vergleich anzeigen

IPv4 erzwingen

[TEST] curl -4 -v https://example.com/

IPv6 erzwingen

[TEST] curl -6 -v https://example.com/

Nur Status und Ziel-IP vergleichen

Linux und macOS:

[TEST] curl -4 -sS -o /dev/null -w "IPv4=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/

[TEST] curl -6 -sS -o /dev/null -w "IPv6=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/

Windows:

[TEST] curl.exe -4 -sS -o NUL -w "IPv4=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/

[TEST] curl.exe -6 -sS -o NUL -w "IPv6=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/

Interpretation

IPv4 IPv6 Mögliche Ursache
Funktioniert Funktioniert nicht IPv6-DNS, Routing, Firewall, Neighbor Discovery oder MTU
Langsam Schnell Unterschiedlicher Netzwerkpfad oder unterschiedliche Gegenstelle
Schnell Langsam IPv6-Pfad, Tunnel oder Zielserver prüfen
Unterschiedliche Inhalte DNS-/CDN-/Proxy-Zuordnung untersuchen

13. Wie wird ein Hostname gezielt gegen eine bestimmte IP-Adresse getestet?

DNS umgehen, Hostname und TLS-SNI erhalten

Für HTTPS muss der Hostname normalerweise gleichzeitig für diese Funktionen erhalten bleiben:

Dafür eignet sich --resolve.

[TEST][SENS] curl --resolve example.com:443:192.0.2.20 https://example.com/

Dieser Befehl bedeutet:

Hostname in URL: example.com
Zielport: 443
Tatsächliche Ziel-IP: 192.0.2.20
HTTP-Host: example.com
TLS-SNI: example.com
Zertifikatsname: example.com

Ausführlicher Test

[TEST][SENS] curl -v --resolve example.com:443:192.0.2.20 https://example.com/

HTTP ohne TLS

[TEST][SENS] curl --resolve example.com:80:192.0.2.20 http://example.com/

Warum nicht nur die IP-Adresse aufrufen?

curl https://192.0.2.20/

Dabei verwendet curl die IP-Adresse als Zielnamen. Das kann verursachen:

Nur einen Host-Header setzen

curl -H "Host: example.com" https://192.0.2.20/

setzt zwar den HTTP-Host-Header, aber nicht automatisch das passende TLS-SNI für example.com. Für HTTPS ist --resolve deshalb in der Regel die richtige Diagnoseoption.

14. Was ist der Unterschied zwischen --resolve und --connect-to?

Zielumleitung erklären

--resolve

[TEST][SENS] curl --resolve example.com:443:192.0.2.20 https://example.com/

--resolve fügt für die angegebene Host-/Portkombination eine temporäre Namenszuordnung hinzu.

--connect-to

[TEST][SENS] curl --connect-to example.com:443:192.0.2.20:8443 https://example.com/

Damit verbindet sich curl tatsächlich mit:

192.0.2.20:8443

Die ursprüngliche URL bleibt:

https://example.com/

Dadurch bleiben insbesondere:

auf example.com bezogen.

Typischer Einsatz

Beide Optionen gelten nur für den jeweiligen curl-Aufruf und verändern nicht dauerhaft die lokale DNS-Konfiguration.

15. Wie werden TLS und Zertifikate geprüft?

TLS-Diagnose anzeigen

Normale Zertifikatsprüfung

[TEST][SENS] curl -v https://example.com/

curl prüft dabei abhängig vom verwendeten TLS-Backend unter anderem:

Bestimmte CA-Datei verwenden

[TEST][FILE][SENS] curl --cacert company-ca.pem https://internal.example.com/

TLS 1.2 oder höher anfordern

[TEST][SENS] curl --tlsv1.2 https://example.com/

--tlsv1.2 legt die minimale TLS-Version auf 1.2 fest. Neuere Versionen können weiterhin ausgehandelt werden.

Maximal TLS 1.2

[TEST][SENS] curl --tlsv1.2 --tls-max 1.2 https://example.com/

TLS 1.3 oder höher anfordern

[TEST][SENS] curl --tlsv1.3 https://example.com/

Die Unterstützung hängt von curl-Version und TLS-Bibliothek ab.

Clientzertifikat

[TEST][FILE][SENS] curl --cert client.pem --key client.key https://example.com/

Format und Optionen können vom verwendeten TLS-Backend abhängen.

Zertifikatsprüfung deaktivieren

[TEST][SENS] curl -k https://example.com/

-k beziehungsweise --insecure deaktiviert die normale Echtheitsprüfung. Dadurch kann curl keine vertrauenswürdige Identität des Servers garantieren.

-k darf höchstens als klar gekennzeichneter Vergleichstest verwendet werden. Es ist keine Lösung für ein Zertifikatsproblem.

Sinnvolle Interpretation

Normaler Test Mit -k Mögliche Ursache
Fehler Erfolgreich Zertifikatsvertrauen, Hostname oder Zertifikatskette prüfen
Fehler Fehler Problem wahrscheinlich nicht nur Zertifikatsprüfung
Erfolgreich Erfolgreich Kein Grund, -k dauerhaft zu verwenden

16. Wie werden HTTP-Versionen geprüft?

HTTP/1.1, HTTP/2 und HTTP/3 anzeigen

HTTP/1.1 anfordern

[TEST][SENS] curl --http1.1 -v https://example.com/

HTTP/2 anfordern

[TEST][SENS] curl --http2 -v https://example.com/

HTTP/3 versuchen

[TEST][SENS] curl --http3 -v https://example.com/

Ausschließlich HTTP/3

[TEST][SENS] curl --http3-only -v https://example.com/

Die Optionen funktionieren nur, wenn der installierte curl-Build die jeweilige Protokollversion unterstützt:

[RO] curl --version

Interpretation

Beobachtung Mögliche Ursache
HTTP/1.1 funktioniert, HTTP/2 nicht Proxy, TLS-ALPN, Server- oder curl-Buildproblem
HTTP/2 funktioniert, HTTP/3 nicht QUIC/UDP, Firewall, Serverunterstützung oder curl-Build
HTTP/3 funktioniert nur ohne VPN VPN oder Firewall blockiert beziehungsweise beeinträchtigt UDP
Unterschiedliche Antworten Reverse Proxy oder Anwendung behandelt Protokolle unterschiedlich

HTTP/3 verwendet QUIC über UDP. Ein erfolgreicher HTTPS-Test über TCP beweist deshalb nicht, dass HTTP/3 erreichbar ist.

17. Wie werden eigene Request-Header gesetzt?

Header mit `-H` anzeigen

Accept-Header setzen

[TEST][SENS] curl -H "Accept: application/json" https://api.example.com/status

Benutzerdefinierten Header setzen

[TEST][SENS] curl -H "X-Diagnostic-ID: test-001" https://example.com/

Mehrere Header

[TEST][SENS] curl -H "Accept: application/json" -H "X-Diagnostic-ID: test-001" https://api.example.com/status

User-Agent setzen

[TEST][SENS] curl -A "IT-Diagnose/1.0" https://example.com/

Alternativ:

[TEST][SENS] curl -H "User-Agent: IT-Diagnose/1.0" https://example.com/

Header entfernen

[TEST][SENS] curl -H "User-Agent:" https://example.com/

Ein Header mit leerem Wert nach dem Doppelpunkt wird entfernt.

Vorsicht

Benutzerdefinierte Header können:

Header aus Browser-Entwicklerwerkzeugen dürfen nicht ungeprüft übernommen werden. Insbesondere Cookies, Tokens und Sitzungskennungen müssen geschützt werden.

18. Wie werden GET-Parameter korrekt übertragen?

Query-Parameter anzeigen

Parameter direkt in der URL

[TEST][SENS] curl "https://api.example.com/search?q=server&limit=10"

Parameter URL-codieren

[TEST][SENS] curl -G --data-urlencode "q=Server Fehleranalyse" --data-urlencode "limit=10" https://api.example.com/search

-G sorgt dafür, dass die mit --data-urlencode angegebenen Daten als URL-Query und nicht als POST-Body verwendet werden.

Ergebnis sinngemäß:

https://api.example.com/search?q=Server%20Fehleranalyse&limit=10

Warum URL-Encoding wichtig ist

Zeichen wie diese besitzen in URLs eine besondere Bedeutung:

Leerzeichen
&
=
?
#
+
%

--data-urlencode verhindert viele Fehler durch nicht korrekt codierte Werte.

19. Wie werden POST-, PUT-, PATCH- und DELETE-Anfragen getestet?

HTTP-Methoden und API-Beispiele anzeigen

Ändernde API-Anfragen dürfen nur gegen ausdrücklich freigegebene Testressourcen ausgeführt werden.

POST mit Formulardaten

[TEST][CHANGE][SENS] curl -X POST -d "name=Max Mustermann" -d "active=true" https://api.example.com/users

Bei Verwendung von -d wählt curl bei HTTP automatisch POST, sofern keine andere Methode angegeben wird. -X POST ist deshalb häufig nicht erforderlich:

[TEST][CHANGE][SENS] curl -d "name=Max Mustermann" -d "active=true" https://api.example.com/users

POST mit JSON

[TEST][CHANGE][SENS] curl -H "Content-Type: application/json" -d '{"name":"Max Mustermann","active":true}' https://api.example.com/users

Neuere curl-Versionen unterstützen:

[TEST][CHANGE][SENS] curl --json '{"name":"Max Mustermann","active":true}' https://api.example.com/users

--json setzt geeignete JSON-Header und verwendet die Daten als Request-Body. Die Verfügbarkeit hängt von der curl-Version ab.

JSON aus Datei

[TEST][FILE][CHANGE][SENS] curl -H "Content-Type: application/json" --data-binary @request.json https://api.example.com/users

PUT

[TEST][CHANGE][SENS] curl -X PUT -H "Content-Type: application/json" --data-binary @request.json https://api.example.com/users/123

PATCH

[TEST][CHANGE][SENS] curl -X PATCH -H "Content-Type: application/json" -d '{"active":false}' https://api.example.com/users/123

DELETE

[TEST][CHANGE][DISRUPT][SENS] curl -X DELETE https://api.example.com/users/123

OPTIONS

[TEST][SENS] curl -i -X OPTIONS https://api.example.com/users

OPTIONS kann Hinweise auf erlaubte Methoden oder CORS-Header liefern. Server müssen jedoch nicht alle Fähigkeiten vollständig darüber offenlegen.

20. Was ist der Unterschied zwischen -d und --data-binary?

Übertragung von Request-Daten erklären
Option Verhalten
-d beziehungsweise --data Sendet HTTP-Daten; Zeilenenden und Dateieinlesung folgen den Regeln dieser Option
--data-raw Wie --data, aber @ wird nicht als Dateiverweis behandelt
--data-binary Überträgt Daten weitgehend unverändert
--data-urlencode URL-codiert die Daten
--json Sendet JSON und setzt passende Header

Textdaten

[TEST][CHANGE][SENS] curl -d "name=Max Mustermann" https://api.example.com/users

Datei binär beziehungsweise unverändert senden

[TEST][FILE][CHANGE][SENS] curl --data-binary @request.json https://api.example.com/import

Wörtliches @ senden

[TEST][CHANGE][SENS] curl --data-raw "@example" https://api.example.com/test

Bei -d @datei interpretiert curl den Wert als Dateipfad. Bei --data-raw wird ein führendes @ dagegen wörtlich übertragen.

21. Wie werden Dateien hoch- und heruntergeladen?

Dateitransfer anzeigen

Antwort in benannte Datei schreiben

[TEST][FILE][SENS] curl -o download.bin https://example.com/file.bin

Remote-Dateinamen verwenden

[TEST][FILE][SENS] curl -O https://example.com/file.bin

Weiterleitung verfolgen und Remote-Dateinamen verwenden

[TEST][FILE][SENS] curl -L -O https://example.com/file.bin

Teilweise Übertragung fortsetzen

[TEST][FILE][SENS] curl -C - -O https://example.com/file.bin

Download bei Fehler entfernen

[TEST][FILE][SENS] curl --fail --remove-on-error -o download.bin https://example.com/file.bin

Datei mit PUT hochladen

[TEST][FILE][CHANGE][SENS] curl -T upload.bin https://example.com/upload.bin

Multipart-Formularupload

[TEST][FILE][CHANGE][SENS] curl -F "file=@upload.bin" https://example.com/upload

Vor einem Upload müssen Ziel, Methode, Überschreibverhalten und Berechtigung geprüft werden.

22. Wie wird eine HTTP-Authentifizierung getestet?

Basic, Digest, Bearer und Negotiate anzeigen

Benutzername angeben und Passwort interaktiv abfragen

[TEST][SENS] curl -u "max.mustermann" https://example.com/protected

curl fordert das Passwort interaktiv an.

Benutzername und Passwort direkt angeben

[TEST][SENS] curl -u "max.mustermann:BEISPIELPASSWORT" https://example.com/protected

Diese Schreibweise ist für reale Zugangsdaten nicht empfohlen, weil das Passwort:

sichtbar werden kann.

Basic Authentication ausdrücklich verwenden

[TEST][SENS] curl --basic -u "max.mustermann" https://example.com/protected

Digest Authentication

[TEST][SENS] curl --digest -u "max.mustermann" https://example.com/protected

Unterstützte Methode automatisch auswählen

[TEST][SENS] curl --anyauth -u "max.mustermann" https://example.com/protected

--anyauth kann eine zusätzliche Anfrage erzeugen, um die angebotenen Methoden zu erkennen.

Bearer-Token

[TEST][SENS] curl -H "Authorization: Bearer TOKEN_NICHT_HIER_EINTRAGEN" https://api.example.com/status

Negotiate/Kerberos, sofern Build und Umgebung es unterstützen

[TEST][SENS] curl --negotiate -u : https://example.com/protected

Zugangsdaten, Tokens und Cookies dürfen nicht in BookStack-Seiten, Tickets oder allgemein lesbaren Skripten gespeichert werden.

23. Wie werden Cookies untersucht?

24. Wie wird ein HTTP-Proxy getestet?

Proxy-Diagnose anzeigen

HTTP-Proxy verwenden

[TEST][SENS] curl -x http://proxy.example.com:8080 https://example.com/

Langform:

[TEST][SENS] curl --proxy http://proxy.example.com:8080 https://example.com/

Proxy-Benutzername interaktiv verwenden

[TEST][SENS] curl -x http://proxy.example.com:8080 -U "max.mustermann" https://example.com/

Proxy umgehen

[TEST][SENS] curl --noproxy example.com https://example.com/

Proxy für alle Ziele umgehen

[TEST][SENS] curl --noproxy "*" https://example.com/

Umgebungsvariablen prüfen

Linux und macOS:

[RO][SENS] env | grep -i proxy

PowerShell:

[RO][SENS] Get-ChildItem Env: | Where-Object Name -Match 'proxy'

Häufig verwendete Variablen:

http_proxy
https_proxy
all_proxy
NO_PROXY
no_proxy

Wichtiger Sicherheitshinweis

Die Variable http_proxy wird von curl aus Sicherheitsgründen nur in Kleinschreibung akzeptiert. Andere Proxyvariablen können je nach Protokoll und Umgebung unterschiedliche Groß-/Kleinschreibungen unterstützen.

Direkt- und Proxytest vergleichen

Direkt:

[TEST][SENS] curl --noproxy "*" -v https://example.com/

Über Proxy:

[TEST][SENS] curl -x http://proxy.example.com:8080 -v https://example.com/

25. Wie wird ein SOCKS-Proxy getestet?

SOCKS4- und SOCKS5-Optionen anzeigen

SOCKS5-Proxy, DNS-Auflösung durch den Proxy

[TEST][SENS] curl --socks5-hostname 192.0.2.50:1080 https://example.com/

SOCKS5-Proxy, lokale DNS-Auflösung

[TEST][SENS] curl --socks5 192.0.2.50:1080 https://example.com/

SOCKS4a

[TEST][SENS] curl --socks4a 192.0.2.50:1080 https://example.com/

Wichtiger Unterschied

Option DNS-Auflösung
--socks5 Lokal durch curl
--socks5-hostname Durch den SOCKS5-Proxy
--socks4 Lokal
--socks4a Durch den Proxy

Der Unterschied ist wichtig, wenn:

26. Wie werden komprimierte Antworten geprüft?

Kompression anzeigen 
[TEST][SENS] curl --compressed -v https://example.com/

Mit --compressed fordert curl eine unterstützte komprimierte Antwort an und dekomprimiert sie anschließend.

In der Anfrage kann beispielsweise erscheinen:

Accept-Encoding: deflate, gzip, br, zstd

Die tatsächlich angebotenen Verfahren hängen vom curl-Build ab.

Header prüfen

[TEST][SENS] curl --compressed -I https://example.com/

Mögliche Antwort:

Content-Encoding: gzip

Typische Probleme

27. Wie werden lokale Unix-Sockets getestet?

Unix-Domain-Socket-Diagnose anzeigen

Auf Linux und anderen Unix-Systemen können HTTP-Dienste über einen Unix-Domain-Socket erreichbar sein.

[TEST][SENS] curl --unix-socket /run/example/app.sock http://localhost/health

curl verbindet sich dabei mit dem lokalen Socket. Der Hostname in der URL wird weiterhin für die HTTP-Anfrage verwendet.

Typische Einsatzbereiche

Beispiel Docker-Socket

[TEST][PRIV][SENS] curl --unix-socket /var/run/docker.sock http://localhost/_ping

Zugriff auf /var/run/docker.sock entspricht auf vielen Systemen weitreichenden administrativen Rechten. Dieser Zugriff darf nicht leichtfertig vergeben oder in Container durchgereicht werden.

28. Wie werden Wiederholungsversuche verwendet?

Retry-Optionen anzeigen

Bis zu drei Wiederholungsversuche

[TEST][SENS] curl --retry 3 https://example.com/

Maximale Gesamtzeit für Wiederholungen

[TEST][SENS] curl --retry 3 --retry-max-time 30 https://example.com/

Feste Verzögerung zwischen Versuchen

[TEST][SENS] curl --retry 3 --retry-delay 2 https://example.com/

Auch abgelehnte TCP-Verbindungen erneut versuchen

[TEST][SENS] curl --retry 3 --retry-connrefused https://example.com/

Alle Fehler wiederholen

[TEST][CHANGE][DISRUPT][SENS] curl --retry 3 --retry-all-errors https://example.com/

--retry-all-errors darf bei ändernden Anfragen nicht unüberlegt verwendet werden. Ein POST, PUT oder DELETE könnte auf dem Server bereits verarbeitet worden sein, obwohl curl die Antwort nicht erhalten hat.

Dadurch könnte eine Wiederholung:

Wiederholungsversuche sind bei idempotenten GET- oder HEAD-Anfragen meist leichter zu bewerten als bei ändernden API-Aufrufen.

29. Welche curl-Exitcodes sind für die Diagnose wichtig?

Exitcode-Tabelle anzeigen
Exitcode Bedeutung
0 Vorgang aus Sicht von curl erfolgreich
3 URL fehlerhaft
5 Proxyname konnte nicht aufgelöst werden
6 Hostname konnte nicht aufgelöst werden
7 Verbindung zum Ziel konnte nicht hergestellt werden
22 HTTP-Fehler bei Verwendung von --fail oder --fail-with-body
23 Fehler beim Schreiben empfangener Daten
26 Fehler beim Lesen lokaler Daten
28 Zeitüberschreitung
35 TLS-/SSL-Verbindungsfehler
47 Zu viele Weiterleitungen
52 Leere Serverantwort
55 Fehler beim Senden von Netzwerkdaten
56 Fehler beim Empfangen von Netzwerkdaten
60 Zertifikat konnte nicht verifiziert werden
77 Problem beim Lesen der CA-Zertifikatsdatei
92 HTTP/2-Protokollfehler

Die vollständige Liste hängt von der curl-Version ab:

[RO] curl --manual

Exitcode unter Linux und macOS anzeigen

curl -sS --fail-with-body https://example.com/health
echo $?

Exitcode unter PowerShell anzeigen

curl.exe -sS --fail-with-body https://example.com/health
$LASTEXITCODE

Wichtige Unterscheidung

HTTP-Statuscode
≠
curl-Exitcode

Beispiel:

HTTP 404 ohne --fail → curl-Exitcode kann 0 sein
HTTP 404 mit --fail → curl-Exitcode 22

30. Wie werden Fehler nach Diagnoseebene eingeordnet?

Fehlerkette anzeigen
curl-Beobachtung Wahrscheinliche Ebene
Exitcode 6 DNS-Auflösung
Exitcode 7 TCP-Verbindung, Routing, Firewall oder Listener
Exitcode 28 DNS, Verbindung, Server oder Übertragung zu langsam
Exitcode 35 TLS-Handshake
Exitcode 60 Zertifikatsvertrauen oder Hostname
HTTP 301/302 Weiterleitung
HTTP 401 Authentifizierung
HTTP 403 Autorisierung, WAF oder Richtlinie
HTTP 404 URL, Routing oder Ressource
HTTP 429 Rate Limit
HTTP 500 Anwendung oder Backend
HTTP 502 Proxy/Gateway und Upstream
HTTP 503 Dienst nicht verfügbar oder Wartungszustand
HTTP 504 Gateway wartet vergeblich auf Upstream
Verbindung funktioniert, Antwort langsam Anwendung, Datenbank, Upstream oder Serverlast
IP funktioniert, Name nicht DNS
--resolve funktioniert, normaler Aufruf nicht DNS-Zuordnung oder Load-Balancer-Ziel
-k funktioniert, normaler Test nicht Zertifikatsprüfung
IPv4 funktioniert, IPv6 nicht IPv6-DNS, Routing, Firewall oder MTU
Direkt funktioniert, Proxy nicht Proxy, Authentifizierung oder Proxy-Richtlinie

31. Welche typischen Fehlinterpretationen gibt es?

Praxisfallen anzeigen
Fehlinterpretation Richtige Einordnung
curl ohne Fehler bedeutet HTTP 200 Ohne --fail kann auch HTTP 404 oder 500 Exitcode 0 ergeben
-I prüft exakt dasselbe wie GET -I sendet bei HTTP eine HEAD-Anfrage
-k behebt TLS Es deaktiviert nur die Zertifikatsprüfung
Aufruf über IP testet denselben virtuellen Host Host-Header, SNI und Zertifikatsprüfung können abweichen
Eigener Host-Header setzt automatisch SNI TLS-SNI wird dadurch nicht zuverlässig angepasst
--resolve verändert lokales DNS dauerhaft Gilt nur für den jeweiligen curl-Aufruf
time_connect ist nur die TCP-Dauer Wert ist kumulativ seit Beginn des Aufrufs
Hohe TTFB beweist Netzwerkproblem Server, Anwendung oder Backend können langsam sein
HTTP 403 bedeutet falsches Passwort Authentifizierung kann korrekt sein, aber Zugriff ist verboten
HTTP 502 ist immer der Webserver Häufig meldet ein Gateway ein Upstream-Problem
Bearer-Token in der Kommandozeile ist sicher Token kann in Historie und Prozessinformationen erscheinen
Verbose-Ausgabe kann bedenkenlos geteilt werden Header, Cookies und Tokens können enthalten sein
curl verhält sich wie ein Browser JavaScript und Browserkontext fehlen
Retry ist bei POST immer sicher Änderung kann bereits verarbeitet worden sein
Proxyvariable ist ausgeschlossen, weil -x fehlt curl kann Proxyvariablen aus der Umgebung verwenden

32. Wie sieht ein systematischer curl-Diagnoseablauf aus?

Empfohlene Schrittfolge anzeigen

Vorbereitung

  1. Erwartete URL, Methode und Antwort dokumentieren.
  2. Hostname, IP-Adresse, Port und Protokoll bestimmen.
  3. Prüfen, ob Proxy, VPN oder Load Balancer beteiligt sind.
  4. Authentifizierung und Schutzbedarf der Daten klären.
  5. Ändernde Anfragen nur gegen freigegebene Testressourcen richten.

Grundtest

  1. curl-Version und unterstützte Funktionen prüfen.
  2. URL mit explizitem https:// oder http:// verwenden.
  3. Verbindung mit -v untersuchen.
  4. HTTP-Statuscode und effektive URL ausgeben.
  5. Exitcode kontrollieren.

Eingrenzung

  1. IPv4 mit -4 und IPv6 mit -6 vergleichen.
  2. DNS mit --resolve kontrolliert umgehen.
  3. Direktverbindung und Proxyverbindung vergleichen.
  4. Redirect-Kette mit -L -I prüfen.
  5. TLS normal und höchstens vergleichsweise mit -k testen.
  6. HTTP/1.1 und HTTP/2 bei Bedarf vergleichen.
  7. DNS-, TCP-, TLS-, TTFB- und Gesamtzeit messen.

Anwendung

  1. Header und Content-Type prüfen.
  2. Erwartete HTTP-Methode verwenden.
  3. Request-Body und Zeichenkodierung kontrollieren.
  4. Authentifizierung ohne Offenlegung der Zugangsdaten testen.
  5. API-Antwort und Serverlogs zeitlich vergleichen.

Validierung

  1. Ergebnis aus einem zweiten Netzwerksegment vergleichen.
  2. Reverse-Proxy-, Firewall- und Anwendungslogs prüfen.
  3. Bei Netzwerkverdacht Paketmitschnitt erstellen.
  4. Nach einer Änderung denselben curl-Befehl erneut ausführen.
  5. Befehl, Zeitpunkt, Exitcode, HTTP-Status und Zeiten dokumentieren.
  6. Diagnoseausgaben vor Weitergabe von Secrets bereinigen.

33. Kurzreferenz – häufige curl-Befehle

Befehlstabelle anzeigen
Aufgabe Linux/macOS
Version [RO] curl --version
Seite abrufen [TEST][SENS] curl https://example.com/
Nur HEAD-Anfrage [TEST][SENS] curl -I https://example.com/
Header und Inhalt [TEST][SENS] curl -i https://example.com/
Ausführliche Diagnose [TEST][SENS] curl -v https://example.com/
Redirects verfolgen [TEST][SENS] curl -L https://example.com/
Statuscode [TEST] curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/
HTTP-Fehler als Fehler behandeln [TEST] curl -sS --fail-with-body https://example.com/
Connect-Timeout [TEST] curl --connect-timeout 5 https://example.com/
Gesamttimeout [TEST] curl --max-time 15 https://example.com/
IPv4 [TEST] curl -4 https://example.com/
IPv6 [TEST] curl -6 https://example.com/
DNS temporär überschreiben [TEST][SENS] curl --resolve example.com:443:192.0.2.20 https://example.com/
Bestimmte CA-Datei [TEST][FILE][SENS] curl --cacert company-ca.pem https://example.com/
HTTP/1.1 [TEST] curl --http1.1 https://example.com/
HTTP/2 [TEST] curl --http2 https://example.com/
JSON senden [TEST][CHANGE][SENS] curl -H "Content-Type: application/json" -d '{"active":true}' https://api.example.com/item
Datei herunterladen [TEST][FILE][SENS] curl -o file.bin https://example.com/file.bin
Proxy verwenden [TEST][SENS] curl -x http://proxy.example.com:8080 https://example.com/
Proxy umgehen [TEST][SENS] curl --noproxy "*" https://example.com/
Trace erstellen [TEST][FILE][SENS] curl --trace-time --trace-ascii curl-trace.txt https://example.com/

Windows verwendet dieselbe Optionssyntax, aber eindeutig curl.exe und NUL statt /dev/null:

[TEST] curl.exe -sS -o NUL -w "HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/

34. Kurzreferenz – wichtigste Optionen

Optionstabelle anzeigen
Option Bedeutung
-V, --version Version und Build-Funktionen anzeigen
-v, --verbose Ausführliche Verbindungsinformationen
-I, --head Bei HTTP HEAD-Anfrage senden
-i, --show-headers Antwortheader zusammen mit Inhalt anzeigen
-D, --dump-header Antwortheader separat schreiben
-o, --output Antwortinhalt in Datei schreiben
-O, --remote-name Remote-Dateinamen verwenden
-s, --silent Fortschritts- und normale Fehlermeldungen unterdrücken
-S, --show-error Fehler trotz --silent anzeigen
-f, --fail HTTP-Fehler als curl-Fehler behandeln
--fail-with-body HTTP-Fehler melden und Inhalt behalten
-L, --location Weiterleitungen verfolgen
--max-redirs Anzahl der Weiterleitungen begrenzen
-w, --write-out Messwerte und Metadaten ausgeben
--connect-timeout Verbindungszeit begrenzen
-m, --max-time Gesamtdauer begrenzen
-4 IPv4 erzwingen
-6 IPv6 erzwingen
--resolve Temporäre Host-/Port-/IP-Zuordnung
--connect-to Tatsächliches Verbindungsziel ändern
-k, --insecure Zertifikatsprüfung deaktivieren
--cacert Bestimmte CA-Datei verwenden
--cert Clientzertifikat verwenden
--key Privaten Schlüssel verwenden
--tlsv1.2 Mindestens TLS 1.2
--tls-max Maximale TLS-Version
--http1.1 HTTP/1.1 verwenden
--http2 HTTP/2 anfordern
--http3 HTTP/3 versuchen
-H, --header Request-Header setzen
-A, --user-agent User-Agent setzen
-d, --data Request-Daten senden
--data-binary Daten weitgehend unverändert senden
--data-urlencode Daten URL-codieren
--json JSON-Daten senden
-X, --request HTTP-Methode ausdrücklich festlegen
-u, --user Serverauthentifizierung
-U, --proxy-user Proxyauthentifizierung
-b, --cookie Cookies senden beziehungsweise lesen
-c, --cookie-jar Cookies speichern
-x, --proxy Proxy verwenden
--noproxy Proxy für Ziele umgehen
--compressed Komprimierte Antwort anfordern
--retry Wiederholungsversuche
--trace-ascii Lesbaren Trace schreiben
--trace-time Trace mit Zeitstempeln versehen

Merksätze

Quellen

2. Grundwerkzeuge und Befehle

2.10 OpenSSL – TLS-Verbindungen, Zertifikate und Zertifikatsketten prüfen

Ziel dieser Seite

OpenSSL ist eine Sammlung von Werkzeugen und Bibliotheken für Kryptografie, Zertifikate und TLS. In der Fehleranalyse wird der Befehl openssl unter anderem verwendet, um:

OpenSSL kann private Schlüssel und andere hochsensible kryptografische Daten verarbeiten. Befehle mit privaten Schlüsseln dürfen nur auf autorisierten Systemen und in geschützten Verzeichnissen ausgeführt werden.

Kennzeichnungen

Kennzeichnung Bedeutung
[RO] Nur lesende lokale Prüfung
[TEST] Aktiver Netzwerk- oder TLS-Test
[PRIV] Erhöhte Berechtigungen können erforderlich sein
[FILE] Befehl liest oder erstellt eine Datei
[SENS] Ausgabe oder Datei enthält möglicherweise sensible Informationen
[CHANGE] Befehl erstellt oder verändert Dateien
[DISRUPT] Test kann Dienst, Sitzung oder produktive Daten beeinflussen

1. Wie wird die OpenSSL-Version geprüft?

Versions- und Buildinformationen anzeigen
Aufgabe Windows Linux macOS
Programmpfad [RO] Get-Command openssl.exe [RO] command -v openssl [RO] command -v openssl
Version [RO] openssl.exe version [RO] openssl version [RO] openssl version
Ausführliche Version [RO] openssl.exe version -a [RO] openssl version -a [RO] openssl version -a
Befehlsübersicht [RO] openssl.exe help [RO] openssl help [RO] openssl help
Hilfe zu s_client [RO] openssl.exe s_client -help [RO] openssl s_client -help [RO] openssl s_client -help

Ausführliche Buildinformationen

[RO] openssl version -a

Die Ausgabe kann unter anderem enthalten:

Betriebssystemspezifische Hinweise

Betriebssystem Hinweis
Windows OpenSSL ist kein allgemeines Windows-Bordmittel und muss aus einer vertrauenswürdigen Quelle stammen oder mit einer Anwendung mitgeliefert werden
Linux Version und Konfiguration hängen von Distribution und Paketstand ab
macOS Der Befehl openssl kann je nach Installation LibreSSL oder eine separat installierte OpenSSL-Version aufrufen
Container Der Container kann eine andere OpenSSL-Version als der Host verwenden

OpenSSL und LibreSSL sind nicht vollständig optionskompatibel. Vor der Übernahme eines Befehls muss deshalb geprüft werden:

openssl version
openssl s_client -help

2. Wie wird eine grundlegende TLS-Verbindung getestet?

Verbindung mit `s_client` anzeigen 
[TEST][SENS] openssl s_client -connect example.com:443

Der Befehl baut eine TCP-Verbindung zu Port 443 auf und startet anschließend einen TLS-Handshake.

Mit ausdrücklich gesetztem SNI

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com

-servername setzt die TLS-Erweiterung Server Name Indication.

Kompakte Ausgabe, sofern von der installierten Version unterstützt

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -brief

Verbindung beenden

Nach dem TLS-Handshake wartet s_client häufig auf weitere Eingaben. Die Sitzung kann normalerweise mit folgender Tastenkombination beendet werden:

[Strg] + [C]

Neuere OpenSSL-Versionen unterstützen einen nicht interaktiven Modus:

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -no-interactive

Vor Verwendung muss geprüft werden:

[RO] openssl s_client -help

Wichtige Ausgabeinformationen

3. Warum muss SNI ausdrücklich berücksichtigt werden?

SNI und virtuelle Hosts erklären

Mehrere HTTPS-Dienste können dieselbe IP-Adresse und denselben Port verwenden:

192.0.2.20:443
├── wiki.example.com
├── mail.example.com
└── api.example.com

Der Client teilt dem Server während des TLS-Handshakes mit, welchen Hostnamen er erreichen möchte. Das geschieht über SNI.

Wiki prüfen

[TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername wiki.example.com

API prüfen

[TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername api.example.com

Der Server kann abhängig vom SNI-Namen unterschiedliche Zertifikate zurückgeben.

Ohne SNI

[TEST][SENS] openssl s_client -connect 192.0.2.20:443 -noservername

Mögliche Folgen:

Ein Test gegen eine IP-Adresse ohne passenden SNI-Namen bildet den Zugriff eines normalen Browsers auf einen DNS-Namen nicht zuverlässig nach.

4. Wie wird ein TLS-Server über eine bestimmte IP-Adresse getestet?

Ziel-IP und Hostname getrennt prüfen

Angenommen:

Hostname: wiki.example.com
Test-IP: 192.0.2.20
Port: 443

Direkter TLS-Test gegen diese IP mit richtigem SNI

[TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername wiki.example.com

Dadurch wird:

Für eine vollständige Hostnamenprüfung sollte zusätzlich verwendet werden:

[TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername wiki.example.com -verify_hostname wiki.example.com -verify_return_error

Vergleich mit curl

[TEST][SENS] curl --resolve wiki.example.com:443:192.0.2.20 https://wiki.example.com/

OpenSSL untersucht hauptsächlich TLS und Zertifikate. curl führt zusätzlich eine HTTP-Anfrage aus.

5. Was bedeutet eine erfolgreiche TLS-Verbindung?

Handshake, Zertifikat und Anwendung unterscheiden

Ein erfolgreicher TLS-Handshake beweist zunächst:

Er beweist nicht automatisch:

Diagnoseebenen

DNS
  ↓
TCP
  ↓
TLS-Handshake
  ↓
Zertifikatsprüfung
  ↓
HTTP oder anderes Anwendungsprotokoll
  ↓
Anwendung

Für HTTPS sollte nach dem OpenSSL-Test zusätzlich eine HTTP-Prüfung erfolgen:

[TEST][SENS] curl -v https://wiki.example.com/

6. Warum kann s_client trotz Zertifikatsfehler eine Verbindung fortsetzen?

Wichtige Besonderheit der Zertifikatsprüfung anzeigen

openssl s_client ist ein Diagnosewerkzeug. Standardmäßig kann es nach Zertifikatsprüffehlern fortfahren, damit weitere Probleme sichtbar werden.

Eine Ausgabe wie:

verify error:num=20:unable to get local issuer certificate

bedeutet deshalb nicht zwingend, dass der TLS-Handshake sofort abgebrochen wird.

Bei Zertifikatsfehlern wirklich abbrechen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_return_error

Zusätzlich Hostnamen prüfen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error

Erwartetes positives Ergebnis

Verification: OK

oder in der ausführlichen Ausgabe:

Verify return code: 0 (ok)

Wichtig

TLS-Handshake abgeschlossen
≠
Zertifikat erfolgreich validiert

Für eine belastbare Prüfung müssen mindestens berücksichtigt werden:

7. Wie wird der Zertifikatsname geprüft?

Hostname und IP-Adresse validieren

DNS-Hostname prüfen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error

Verbindung gegen IP, aber DNS-Namen prüfen

[TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername wiki.example.com -verify_hostname wiki.example.com -verify_return_error

IP-Adresse als Zertifikatsidentität prüfen

[TEST][SENS] openssl s_client -connect 192.0.2.20:443 -verify_ip 192.0.2.20 -verify_return_error

Ein Zertifikat muss die IP-Adresse dafür als IP-Eintrag im Subject Alternative Name enthalten. Ein DNS-Name oder ein Common Name mit einer IP-ähnlichen Zeichenfolge ist dafür nicht automatisch ausreichend.

Zu unterscheiden

Option Aufgabe
-connect Tatsächliches Netzwerkziel
-servername Im TLS-Handshake gesendeter SNI-Name
-verify_hostname Erwartete DNS-Identität im Zertifikat
-verify_ip Erwartete IP-Identität im Zertifikat

Diese Werte können bei gezielten Tests unterschiedlich sein.

8. Wie wird die vom Server gesendete Zertifikatsliste angezeigt?

Zertifikate mit `-showcerts` anzeigen 
[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -showcerts

-showcerts zeigt die Zertifikate so an, wie der Server sie übermittelt hat.

Typische Reihenfolge:

1. Server-/Leaf-Zertifikat
2. Zwischenzertifikat
3. weiteres Zwischenzertifikat

Ein Root-Zertifikat wird von einem TLS-Server normalerweise nicht mitgesendet, weil es bereits im Vertrauensspeicher des Clients vorhanden sein soll.

Wichtiger Hinweis

Die Ausgabe von -showcerts ist:

Typischer Fehler

Server sendet nur Leaf-Zertifikat
→ Client kann Aussteller möglicherweise nicht finden
→ unable to get local issuer certificate

9. Wie wird ein Serverzertifikat in eine Datei übernommen?

Leaf-Zertifikat extrahieren

Unter Linux und macOS kann das erste vom Server ausgegebene Zertifikat an openssl x509 weitergegeben werden:

[TEST][FILE][SENS] openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -outform PEM > server-cert.pem

Anschließend prüfen:

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -subject -issuer -dates

Wichtig

Diese Pipeline übernimmt normalerweise das erste PEM-Zertifikat aus der Ausgabe und damit üblicherweise das Leaf-Zertifikat. Sie speichert nicht automatisch die vollständige Zertifikatskette.

Für die vollständige Kette sollte die Ausgabe von -showcerts kontrolliert und jedes Zertifikat eindeutig getrennt gespeichert werden.

Unter Windows

Shell-Pipelines und Umleitungen unterscheiden sich zwischen:

Daher sollte unter Windows zunächst die Ausgabe kontrolliert in eine Datei geschrieben und das gewünschte PEM-Zertifikat anschließend eindeutig extrahiert werden. Binärdaten und private Schlüssel dürfen nicht unkontrolliert durch Textkonvertierungen einer Shell verändert werden.

10. Wie wird ein lokales Zertifikat vollständig angezeigt?

Zertifikatsinhalt mit `openssl x509` anzeigen 
[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -text

Kompakte Kerninformationen

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -subject -issuer -serial -dates

SHA-256-Fingerabdruck

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -fingerprint -sha256

Public-Key-Information

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -pubkey

Wichtige Zertifikatsfelder

Feld Bedeutung
Subject Identität des Zertifikatsinhabers
Issuer Ausstellende Zertifizierungsstelle
Serial Number Seriennummer des Zertifikats
Not Before Beginn der Gültigkeit
Not After Ende der Gültigkeit
Public Key Algorithm Typ des öffentlichen Schlüssels
Signature Algorithm Signaturalgorithmus der CA
Subject Alternative Name Gültige DNS-Namen, IP-Adressen oder andere Identitäten
Key Usage Zulässige grundlegende Schlüsselverwendungen
Extended Key Usage Beispielsweise TLS Web Server Authentication
Basic Constraints Kennzeichnung als Endzertifikat oder CA-Zertifikat
Authority Information Access Hinweise auf Aussteller und OCSP
CRL Distribution Points Verweise auf Sperrlisten

11. Wie werden Subject Alternative Names angezeigt?

SAN-Felder prüfen 
[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext subjectAltName

Beispiel:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com, DNS:api.example.com

Weitere Erweiterungen

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext keyUsage

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext extendedKeyUsage

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext basicConstraints

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext authorityInfoAccess

Wichtig

Moderne TLS-Clients prüfen die Identität hauptsächlich anhand von Subject Alternative Name. Der Common Name allein sollte nicht als verlässlicher Ersatz für fehlende SAN-Einträge betrachtet werden.

12. Wie wird die Gültigkeitsdauer eines Zertifikats geprüft?

Start-, Ablaufdatum und Restlaufzeit anzeigen

Gültigkeitszeitraum anzeigen

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -dates

Ausgabe:

notBefore=...
notAfter=...

Nur Ablaufdatum

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -enddate

Prüfen, ob das Zertifikat mindestens noch 30 Tage gültig ist

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -checkend 2592000

Berechnung:

30 Tage × 24 Stunden × 60 Minuten × 60 Sekunden
= 2.592.000 Sekunden

Exitcode auswerten

Linux und macOS:

openssl x509 -in server-cert.pem -noout -checkend 2592000
echo $?

PowerShell:

openssl.exe x509 -in server-cert.pem -noout -checkend 2592000
$LASTEXITCODE
Exitcode Bedeutung
0 Zertifikat ist über den angegebenen Zeitraum hinaus gültig
ungleich 0 Zertifikat läuft innerhalb des Zeitraums ab oder ist bereits abgelaufen

Zusätzlich muss die lokale Systemzeit korrekt sein. Eine falsche Uhr kann gültige Zertifikate als noch nicht gültig oder abgelaufen erscheinen lassen.

13. Wie wird eine Zertifikatskette lokal geprüft?

Kettenprüfung mit `openssl verify` anzeigen

Angenommene Dateien:

server-cert.pem
intermediate-ca.pem
root-ca.pem

Kette prüfen

[RO][FILE][SENS] openssl verify -CAfile root-ca.pem -untrusted intermediate-ca.pem server-cert.pem

Erwartetes Ergebnis:

server-cert.pem: OK

Zusätzlich Hostnamen prüfen

[RO][FILE][SENS] openssl verify -CAfile root-ca.pem -untrusted intermediate-ca.pem -verify_hostname wiki.example.com server-cert.pem

Für TLS-Serverzweck prüfen

[RO][FILE][SENS] openssl verify -CAfile root-ca.pem -untrusted intermediate-ca.pem -purpose sslserver server-cert.pem

Bedeutung

Option Aufgabe
-CAfile root-ca.pem Vertrauensanker
-untrusted intermediate-ca.pem Nicht direkt vertrautes Zwischenzertifikat zur Kettenbildung
-verify_hostname Erwarteten DNS-Namen prüfen
-purpose sslserver Eignung für TLS-Server prüfen

Das Zwischenzertifikat wird mit -untrusted zur Kettenbildung bereitgestellt. Dadurch wird es nicht automatisch selbst zum Vertrauensanker.

14. Welche typischen Fehler der Zertifikatskette gibt es?

Verify-Fehler einordnen
Fehlermeldung Mögliche Bedeutung
unable to get local issuer certificate Aussteller oder Zwischenzertifikat fehlt beziehungsweise ist nicht auffindbar
unable to verify the first certificate Kette kann vom Leaf-Zertifikat nicht zu einem vertrauten Root aufgebaut werden
self-signed certificate Zertifikat ist selbstsigniert und nicht als vertrauenswürdig hinterlegt
self-signed certificate in certificate chain Selbstsigniertes Zertifikat in der Kette ist nicht als Vertrauensanker akzeptiert
certificate has expired Zertifikat liegt nach notAfter
certificate is not yet valid Systemzeit liegt vor notBefore
hostname mismatch Erwarteter Name passt nicht zum Zertifikat
invalid CA certificate Zertifikat ist nicht korrekt als CA verwendbar
path length constraint exceeded CA-Pfadlängenbegrenzung verletzt
unsupported certificate purpose Zertifikat ist nicht für den geprüften Zweck vorgesehen
certificate signature failure Signatur konnte nicht korrekt bestätigt werden

Prüfreihenfolge

  1. Leaf-Zertifikat untersuchen.
  2. Issuer des Leaf-Zertifikats bestimmen.
  3. Passendes Zwischenzertifikat prüfen.
  4. Issuer und Subject der Kettenglieder vergleichen.
  5. CA-Eigenschaften kontrollieren.
  6. Vertrauensanker eindeutig festlegen.
  7. Gültigkeitszeiten aller Zertifikate prüfen.
  8. Hostnamen und Verwendungszweck prüfen.

15. Wie wird eine interne Zertifizierungsstelle verwendet?

Eigene CA für einen einzelnen Test angeben

TLS-Verbindung mit eigener CA-Datei prüfen

[TEST][FILE][SENS] openssl s_client -connect wiki.example.com:443 -servername wiki.example.com -verify_hostname wiki.example.com -verify_return_error -CAfile company-root-ca.pem

Lokales Zertifikat prüfen

[RO][FILE][SENS] openssl verify -CAfile company-root-ca.pem -untrusted company-intermediate-ca.pem -verify_hostname wiki.example.com server-cert.pem

Wichtig

Die Angabe von -CAfile gilt für diesen OpenSSL-Aufruf. Sie installiert die CA nicht automatisch in:

Ein erfolgreicher OpenSSL-Test mit eigener CA-Datei beweist deshalb nicht, dass alle Anwendungen dieser CA vertrauen.

16. Wie werden TLS 1.2 und TLS 1.3 getrennt getestet?

Protokollversionen anzeigen

Ausschließlich TLS 1.2

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_2

Ausschließlich TLS 1.3

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_3

Minimalversion festlegen, sofern unterstützt

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -min_protocol TLSv1.2

Maximalversion festlegen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -max_protocol TLSv1.2

Interpretation

TLS 1.2 TLS 1.3 Mögliche Aussage
Erfolgreich Erfolgreich Beide Versionen werden unterstützt
Erfolgreich Fehler Server, Proxy oder Client unterstützt TLS 1.3 nicht oder blockiert es
Fehler Erfolgreich Server erlaubt möglicherweise nur TLS 1.3
Beide Fehler TCP, SNI, Zertifikat, Cipher oder Dienst prüfen

Ein Versionsfehler kann auch durch einen zwischengeschalteten Proxy, Load Balancer oder TLS-Inspection-Dienst verursacht werden.

17. Wie werden Cipher Suites geprüft?

Cipher-Informationen anzeigen

Verfügbare Cipher Suites des lokalen OpenSSL-Builds

[RO] openssl ciphers -v

Nur TLS-1.2-kompatible Auswahl untersuchen

[RO] openssl ciphers -v -tls1_2

Nur TLS-1.3-Cipher-Suites anzeigen, sofern unterstützt

[RO] openssl ciphers -v -tls1_3

Bestimmte TLS-1.2-Cipher-Auswahl testen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_2 -cipher 'ECDHE-RSA-AES128-GCM-SHA256'

Bestimmte TLS-1.3-Cipher-Suite testen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_3 -ciphersuites 'TLS_AES_128_GCM_SHA256'

Wichtiger Unterschied

Option Gilt hauptsächlich für
-cipher TLS 1.2 und älter
-ciphersuites TLS 1.3

Die tatsächlich verfügbaren Cipher Suites hängen von:

ab.

Eine einzelne funktionierende Cipher Suite beweist nicht, dass die gesamte TLS-Konfiguration sicher oder vollständig kompatibel ist.

18. Wie wird ALPN für HTTP/2 und HTTP/1.1 geprüft?

ALPN-Aushandlung anzeigen

HTTP/2 und HTTP/1.1 anbieten

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -alpn 'h2,http/1.1'

Mögliche Ausgabe:

ALPN protocol: h2

oder:

ALPN protocol: http/1.1

Nur HTTP/2 anbieten

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -alpn h2

Interpretation

Ergebnis Bedeutung
h2 Server und Client einigten sich auf HTTP/2
http/1.1 HTTP/1.1 wurde gewählt
Keine ALPN-Aushandlung Server, Proxy oder OpenSSL-Build unterstützt beziehungsweise verwendet ALPN nicht
TLS-Abbruch Protokoll-, Cipher-, SNI- oder Richtlinienproblem möglich

ALPN bestimmt das Anwendungsprotokoll innerhalb der TLS-Verbindung. OpenSSL s_client führt danach nicht automatisch eine vollständige HTTP/2-Anfrage aus.

Für den Anwendungstest:

[TEST][SENS] curl --http2 -v https://example.com/

19. Wie wird OCSP Stapling geprüft?

OCSP-Statusantwort anzeigen 
[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -status

Die Option fordert während des TLS-Handshakes eine gestapelte OCSP-Antwort an.

Mögliche Ausgabe:

OCSP response:
...
Cert Status: good

Mögliche Ergebnisse

Beobachtung Einordnung
Gültige Antwort mit good Server lieferte eine auswertbare OCSP-Statusantwort
revoked Zertifikat wird als gesperrt gemeldet
unknown OCSP-Responder kennt den Status nicht eindeutig
OCSP response: no response sent Server lieferte kein OCSP Stapling
Fehlerhafte Antwort OCSP-Antwort, Signatur oder Aktualität prüfen

Kein OCSP Stapling bedeutet nicht automatisch, dass das Zertifikat gesperrt oder die TLS-Verbindung ungültig ist. Ob Stapling erforderlich ist, hängt von Zertifikat, Anwendung und Richtlinie ab.

20. Wie wird STARTTLS bei Maildiensten geprüft?

SMTP, IMAP und POP3 anzeigen

Bei STARTTLS beginnt die Verbindung unverschlüsselt und wird anschließend innerhalb des Anwendungsprotokolls auf TLS umgestellt.

SMTP auf Port 25

[TEST][SENS] openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

SMTP Submission auf Port 587

[TEST][SENS] openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com

IMAP mit STARTTLS

[TEST][SENS] openssl s_client -starttls imap -connect mail.example.com:143 -servername mail.example.com

POP3 mit STARTTLS

[TEST][SENS] openssl s_client -starttls pop3 -connect mail.example.com:110 -servername mail.example.com

LMTP mit STARTTLS, sofern unterstützt

[TEST][SENS] openssl s_client -starttls lmtp -connect mail.example.com:24 -servername mail.example.com

Direktes TLS ohne STARTTLS

Dienst Typischer Port Aufruf
SMTPS 465 openssl s_client -connect mail.example.com:465 -servername mail.example.com
IMAPS 993 openssl s_client -connect mail.example.com:993 -servername mail.example.com
POP3S 995 openssl s_client -connect mail.example.com:995 -servername mail.example.com

STARTTLS und direktes TLS dürfen nicht verwechselt werden.

21. Wie wird STARTTLS bei LDAP und Datenbanken geprüft?

LDAP-, PostgreSQL- und MySQL-Beispiele anzeigen

LDAP mit STARTTLS

[TEST][SENS] openssl s_client -starttls ldap -connect ldap.example.com:389 -servername ldap.example.com

LDAPS mit direktem TLS

[TEST][SENS] openssl s_client -connect ldap.example.com:636 -servername ldap.example.com

PostgreSQL mit TLS-Aushandlung

[TEST][SENS] openssl s_client -starttls postgres -connect db.example.com:5432 -servername db.example.com

MySQL mit TLS-Aushandlung, sofern von der installierten OpenSSL-Version unterstützt

[TEST][SENS] openssl s_client -starttls mysql -connect db.example.com:3306 -servername db.example.com

Nicht jede OpenSSL- oder LibreSSL-Version unterstützt alle -starttls-Protokolle. Verfügbarkeit prüfen:

[RO] openssl s_client -help

Ein erfolgreicher TLS-Handshake beweist nicht, dass anschließend eine Datenbank- oder LDAP-Anmeldung erfolgreich ist.

22. Wie wird eine Verbindung über einen HTTP-Proxy getestet?

HTTP-CONNECT-Proxy anzeigen 
[TEST][SENS] openssl s_client -proxy proxy.example.com:8080 -connect example.com:443 -servername example.com

OpenSSL sendet dabei eine HTTP-CONNECT-Anfrage an den Proxy und baut durch den Tunnel die TLS-Verbindung zum Zielserver auf.

Proxybenutzer angeben

[TEST][SENS] openssl s_client -proxy proxy.example.com:8080 -proxy_user max.mustermann -proxy_pass stdin -connect example.com:443 -servername example.com

Das Passwort wird über die angegebene Passwortquelle eingelesen.

Wichtiger Sicherheitshinweis

Die von s_client unterstützte Proxy-Basisauthentifizierung überträgt die Zugangsdaten vor dem TLS-Tunnel in leicht rückwandelbarer Base64-Form an den Proxy. Sie ist nur in entsprechend geschützten und autorisierten Umgebungen zu verwenden.

Direkt- und Proxytest vergleichen

Direkt:

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com

Über Proxy:

[TEST][SENS] openssl s_client -proxy proxy.example.com:8080 -connect example.com:443 -servername example.com

Unterschiedliche Zertifikate können auf TLS-Inspection oder unterschiedliche Netzwerkpfade hinweisen.

23. Wie wird eine mTLS-Verbindung mit Clientzertifikat geprüft?

Clientzertifikat und privaten Schlüssel verwenden

Clientzertifikat und Schlüssel getrennt

[TEST][FILE][SENS] openssl s_client -connect api.example.com:443 -servername api.example.com -cert client-cert.pem -key client-key.pem

Zusätzlich Serverzertifikat und Hostname verifizieren

[TEST][FILE][SENS] openssl s_client -connect api.example.com:443 -servername api.example.com -cert client-cert.pem -key client-key.pem -CAfile company-root-ca.pem -verify_hostname api.example.com -verify_return_error

Clientzertifikatskette angeben

[TEST][FILE][SENS] openssl s_client -connect api.example.com:443 -servername api.example.com -cert client-cert.pem -key client-key.pem -cert_chain client-chain.pem -build_chain

Die Optionen -cert_chain und -build_chain sind versionsabhängig.

Mögliche Fehler

Private Schlüssel dürfen niemals in Tickets, BookStack-Seiten, Chatnachrichten oder Diagnoseausgaben eingefügt werden.

24. Wie wird ein privater Schlüssel geprüft, ohne ihn auszugeben?

Schlüsselstruktur sicher prüfen

Allgemeinen privaten Schlüssel prüfen

[RO][FILE][SENS] openssl pkey -in server-key.pem -check -noout

Bei einem verschlüsselten Schlüssel wird normalerweise eine Passphrase abgefragt.

Nur öffentliche Schlüsselkomponente ausgeben

[RO][FILE][SENS] openssl pkey -in server-key.pem -pubout

Schlüsselinformation ohne private Bestandteile

[RO][FILE][SENS] openssl pkey -in server-key.pem -pubout -text_pub -noout

Nicht unkontrolliert verwenden

openssl pkey -in server-key.pem -text

Dieser Befehl kann private Schlüsselbestandteile ausgeben. Solche Ausgaben dürfen nicht in Logs, Terminalsitzungsaufzeichnungen oder Tickets gelangen.

Dateiberechtigungen prüfen

Linux:

[RO][FILE][SENS] stat server-key.pem

macOS:

[RO][FILE][SENS] stat -x server-key.pem

Windows:

[RO][FILE][SENS] Get-Acl .\server-key.pem

25. Wie wird geprüft, ob Zertifikat und privater Schlüssel zusammengehören?

Öffentliche Schlüssel vergleichen

Die zuverlässige allgemeine Methode besteht darin, aus beiden Dateien den öffentlichen Schlüssel zu gewinnen und dessen DER-Darstellung zu hashen.

Hash des öffentlichen Schlüssels aus dem Zertifikat

[RO][FILE][SENS] openssl x509 -in server-cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256

Hash des öffentlichen Schlüssels aus dem privaten Schlüssel

[RO][FILE][SENS] openssl pkey -in server-key.pem -pubout -outform DER | openssl dgst -sha256

Wenn beide SHA-256-Werte identisch sind, besitzen Zertifikat und privater Schlüssel denselben öffentlichen Schlüssel.

Beispiel

SHA2-256(stdin)= abcdef...
SHA2-256(stdin)= abcdef...

Warum nicht nur den RSA-Modulus vergleichen?

Der klassische Modulusvergleich funktioniert nur für bestimmte Schlüsselarten wie RSA. Der Vergleich des normalisierten öffentlichen Schlüssels funktioniert auch für andere von OpenSSL unterstützte Schlüsseltypen, beispielsweise EC-Schlüssel.

26. Wie wird eine Certificate Signing Request geprüft?

CSR-Inhalt und Signatur anzeigen

Gesamten CSR-Inhalt anzeigen

[RO][FILE][SENS] openssl req -in request.csr -noout -text

Subject anzeigen

[RO][FILE][SENS] openssl req -in request.csr -noout -subject

CSR-Signatur prüfen

[RO][FILE][SENS] openssl req -in request.csr -noout -verify

Öffentlichen Schlüssel des CSR ausgeben

[RO][FILE][SENS] openssl req -in request.csr -noout -pubkey

Zu prüfen

Ein CSR ist noch kein Zertifikat. Er enthält:

Er enthält nicht den privaten Schlüssel.

27. Wie wird geprüft, ob CSR und privater Schlüssel zusammengehören?

CSR-Schlüsselvergleich anzeigen

Öffentlichen Schlüssel aus dem CSR hashen

[RO][FILE][SENS] openssl req -in request.csr -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256

Öffentlichen Schlüssel aus dem privaten Schlüssel hashen

[RO][FILE][SENS] openssl pkey -in server-key.pem -pubout -outform DER | openssl dgst -sha256

Sind beide Werte identisch, gehört der private Schlüssel zum CSR.

Nach Ausstellung zusätzlich vergleichen

CSR ↔ privater Schlüssel
Zertifikat ↔ privater Schlüssel

Dadurch wird geprüft, ob die Zertifizierungsstelle tatsächlich das Zertifikat für den vorgesehenen Schlüssel ausgestellt hat.

28. Wie werden PEM- und DER-Zertifikate unterschieden und konvertiert?

Zertifikatsformate anzeigen

PEM

PEM ist textbasiert und enthält Markierungen wie:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

DER

DER ist ein binäres ASN.1-Format und besitzt keine lesbaren BEGIN-/END-Markierungen.

PEM-Zertifikat anzeigen

[RO][FILE][SENS] openssl x509 -in certificate.pem -inform PEM -noout -text

DER-Zertifikat anzeigen

[RO][FILE][SENS] openssl x509 -in certificate.der -inform DER -noout -text

DER nach PEM konvertieren

[CHANGE][FILE][SENS] openssl x509 -in certificate.der -inform DER -out certificate.pem -outform PEM

PEM nach DER konvertieren

[CHANGE][FILE][SENS] openssl x509 -in certificate.pem -inform PEM -out certificate.der -outform DER

Die Dateiendung allein beweist das Format nicht. Dateien mit .cer oder .crt können PEM oder DER enthalten.

29. Wie wird eine PKCS#12-Datei untersucht?

PFX/P12-Inhalt sicher prüfen

PKCS#12-Dateien verwenden häufig die Endungen:

.p12
.pfx

Sie können enthalten:

Inhalt anzeigen, aber keine privaten Schlüssel ausgeben

[RO][FILE][SENS] openssl pkcs12 -in bundle.p12 -info -noout

Nur Zertifikate anzeigen, keine privaten Schlüssel

[RO][FILE][SENS] openssl pkcs12 -in bundle.p12 -nokeys

Nur das Client- beziehungsweise Leaf-Zertifikat extrahieren

[CHANGE][FILE][SENS] openssl pkcs12 -in bundle.p12 -clcerts -nokeys -out client-cert.pem

CA-Zertifikate extrahieren

[CHANGE][FILE][SENS] openssl pkcs12 -in bundle.p12 -cacerts -nokeys -out ca-chain.pem

Privaten Schlüssel extrahieren

[CHANGE][FILE][SENS] openssl pkcs12 -in bundle.p12 -nocerts -out client-key-encrypted.pem

Dieser Vorgang erzeugt eine Datei mit privatem Schlüssel und ist besonders sensibel. Die Ausgabedatei sollte verschlüsselt und mit streng beschränkten Dateirechten gespeichert werden.

Unverschlüsselten privaten Schlüssel exportieren

Optionen wie -nodes beziehungsweise das neuere -noenc können unverschlüsselte private Schlüssel erzeugen. Das sollte nur in begründeten Ausnahmefällen, mit dokumentierter Freigabe und geeigneten Dateirechten erfolgen.

30. Wie werden Zertifikatsfingerabdrücke verglichen?

SHA-256-Fingerprints anzeigen

Zertifikatsfingerabdruck

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -fingerprint -sha256

Hash der gesamten Datei

[RO][FILE][SENS] openssl dgst -sha256 server-cert.pem

Diese beiden Werte sind nicht dasselbe:

Prüfung Gehashte Daten
openssl x509 -fingerprint -sha256 DER-codiertes Zertifikat
openssl dgst -sha256 server-cert.pem Tatsächliche Datei einschließlich PEM-Darstellung

Zwei PEM-Dateien können dasselbe Zertifikat enthalten, aber wegen unterschiedlicher Zeilenenden oder Formatierung unterschiedliche Dateihashes besitzen. Der Zertifikatsfingerabdruck bleibt dagegen identisch.

Betriebssystemspezifischer Dateihash

Windows:

[RO][FILE][SENS] Get-FileHash .\server-cert.pem -Algorithm SHA256

Linux:

[RO][FILE][SENS] sha256sum server-cert.pem

macOS:

[RO][FILE][SENS] shasum -a 256 server-cert.pem

31. Wie werden detaillierte TLS-Zustände und Nachrichten untersucht?

Erweiterte Diagnoseoptionen anzeigen

TLS-Zustandswechsel anzeigen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -state

TLS-Protokollnachrichten anzeigen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -msg

Umfangreicher Trace, sofern unterstützt

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -trace

TLS-Erweiterungen anzeigen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tlsextdebug

Wichtiger Hinweis

-debug, -msg und -trace können sehr umfangreiche Hexadezimal- und Protokollausgaben erzeugen. Sie sollten erst verwendet werden, wenn:

32. Wie werden IPv4 und IPv6 getrennt getestet?

IPv4-/IPv6-TLS-Vergleich anzeigen

IPv4 erzwingen

[TEST][SENS] openssl s_client -4 -connect example.com:443 -servername example.com

IPv6 erzwingen

[TEST][SENS] openssl s_client -6 -connect example.com:443 -servername example.com

Direkte IPv6-Adresse

[TEST][SENS] openssl s_client -connect '[2001:db8::20]:443' -servername example.com

Bei einer IPv6-Adresse in host:port-Schreibweise muss die Adresse in eckige Klammern gesetzt werden.

Interpretation

IPv4 IPv6 Mögliche Ursache
Erfolgreich Fehler IPv6-DNS, Routing, Firewall, MTU oder Zielkonfiguration
Fehler Erfolgreich IPv4-Routing, NAT, Firewall oder Zielkonfiguration
Unterschiedliches Zertifikat Unterschiedlicher Load Balancer oder Server
Unterschiedliche TLS-Version Unterschiedliche Proxy- oder Serverkonfiguration

33. Wie wird ein TLS-Fehler systematisch eingegrenzt?

Diagnosekette anzeigen

1. DNS prüfen

Windows:

[RO] Resolve-DnsName example.com

Linux:

[RO] dig example.com

macOS:

[RO] dig example.com

2. TCP-Port prüfen

Windows:

[TEST] Test-NetConnection example.com -Port 443

Linux und macOS:

[TEST] nc -vz example.com 443

3. TLS mit SNI prüfen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com

4. Zertifikatsprüfung erzwingen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error

5. Zertifikatsliste anzeigen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -showcerts

6. TLS-Versionen getrennt prüfen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_2

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_3

7. Anwendung prüfen

[TEST][SENS] curl -v https://example.com/

8. Logs vergleichen

34. Wie werden typische OpenSSL-Fehler eingeordnet?

Fehlertabelle anzeigen
Fehler oder Beobachtung Mögliche Ursache
Connection refused Ziel erreichbar, aber kein Listener am Port
Connection timed out Firewall, Routing, Rückweg oder Ziel nicht erreichbar
no peer certificate available TLS-Handshake brach vor Zertifikatsübertragung ab
wrong version number Falsches Protokoll am Port, beispielsweise direktes TLS gegen einen Klartextport
unknown protocol Ziel spricht kein erwartetes TLS-Protokoll
handshake failure Keine gemeinsamen Parameter, Richtlinie, Clientzertifikat oder Serverkonfiguration
no shared cipher Keine gemeinsame Cipher Suite
unsupported protocol TLS-Version nicht unterstützt oder deaktiviert
certificate verify failed Vertrauenskette, Zeit, Zweck oder Name fehlerhaft
unable to get local issuer certificate Zwischenzertifikat oder Aussteller fehlt
self-signed certificate Nicht vertrautes selbstsigniertes Zertifikat
certificate has expired Zertifikat abgelaufen
certificate is not yet valid Systemzeit falsch oder Gültigkeit noch nicht begonnen
hostname mismatch Zertifikat gilt nicht für erwarteten Namen
bad certificate Gegenstelle lehnt Zertifikat ab
certificate required Server verlangt ein Clientzertifikat
tlsv1 alert protocol version Gegenstelle akzeptiert angebotene TLS-Version nicht
unexpected eof while reading Gegenstelle oder Zwischenkomponente beendet Verbindung ohne regulären TLS-Abschluss
Falsches Zertifikat SNI fehlt, falscher Load Balancer oder falsches Ziel
Verify return code: 0 (ok) trotz falscher Anwendung TLS-Zertifikat okay, Anwendungsproblem bleibt möglich

35. Welche Fehlinterpretationen müssen vermieden werden?

Praxisfallen anzeigen
Fehlinterpretation Richtige Einordnung
TLS-Handshake erfolgreich bedeutet Zertifikat gültig s_client kann nach Verify-Fehlern fortfahren
CONNECTED bedeutet TLS vollständig erfolgreich Es bestätigt zunächst die hergestellte Transportverbindung
-showcerts zeigt eine validierte Kette Es zeigt nur die vom Server gesendeten Zertifikate
Root-Zertifikat fehlt in Serverausgabe Root-CA wird normalerweise nicht mitgesendet
Common Name reicht immer aus Moderne Clients prüfen hauptsächlich SAN
Test über IP entspricht Test über DNS-Namen SNI und Hostnamenprüfung können abweichen
-servername prüft automatisch den Zertifikatsnamen SNI und Hostnamenvalidierung sind getrennte Funktionen
-verify_hostname setzt automatisch das Netzwerkziel Das Netzwerkziel wird durch -connect bestimmt
Selbstsigniert bedeutet automatisch unsicher Es bedeutet zunächst, dass kein externer Vertrauenspfad vorliegt
Verify return code: 0 beweist funktionierende Website Nur die geprüfte TLS-/Zertifikatsebene ist erfolgreich
Gleiches Subject bedeutet gleiches Zertifikat Seriennummer, Public Key und Fingerprint können verschieden sein
Gleicher Dateihash ist der einzige Zertifikatsvergleich PEM-Formatierung kann Dateihash verändern
PKCS#12 ist nur ein Zertifikat Datei kann zusätzlich private Schlüssel und Ketten enthalten
Private Schlüssel können zur Diagnose angezeigt werden Private Schlüssel dürfen nicht offengelegt werden
-tls1_2 bedeutet mindestens TLS 1.2 Bei s_client erzwingt die Option den Test mit TLS 1.2
Fehlendes OCSP Stapling bedeutet gesperrt Server hat lediglich keine Stapling-Antwort geliefert

36. Wie sieht ein sicherer OpenSSL-Diagnoseablauf aus?

Empfohlene Schrittfolge anzeigen

Vorbereitung

  1. Erwarteten Hostnamen, Ziel-IP und Port dokumentieren.
  2. Klären, ob direktes TLS oder STARTTLS verwendet wird.
  3. OpenSSL- beziehungsweise LibreSSL-Version prüfen.
  4. Erwartete Zertifizierungsstelle und Zertifikatsnamen ermitteln.
  5. Systemzeit und Zeitzone kontrollieren.
  6. Private Schlüssel und Passwortquellen schützen.

Verbindung

  1. DNS-Auflösung prüfen.
  2. TCP-Port prüfen.
  3. TLS-Verbindung mit richtigem SNI aufbauen.
  4. Tatsächlich ausgehandelte TLS-Version und Cipher Suite dokumentieren.
  5. ALPN bei HTTP-Diensten prüfen.

Zertifikat

  1. Zertifikatsprüffehlermeldungen beachten.
  2. Prüfung mit -verify_return_error erzwingen.
  3. Hostnamen mit -verify_hostname prüfen.
  4. Serverzertifikate mit -showcerts anzeigen.
  5. Leaf- und Zwischenzertifikate getrennt untersuchen.
  6. SAN, Issuer, Subject und Gültigkeit prüfen.
  7. Kette mit openssl verify lokal nachvollziehen.

Vertiefung

  1. TLS 1.2 und TLS 1.3 getrennt testen.
  2. IPv4 und IPv6 vergleichen.
  3. Direkt- und Proxyverbindung vergleichen.
  4. Bei mTLS Clientzertifikat und Schlüsselzuordnung prüfen.
  5. Bei STARTTLS das richtige Anwendungsprotokoll angeben.
  6. Nur bei Bedarf -state, -msg oder -trace verwenden.

Validierung

  1. HTTPS zusätzlich mit curl prüfen.
  2. Server-, Proxy- und Firewall-Logs vergleichen.
  3. Bei Netzwerkverdacht Paketmitschnitt erstellen.
  4. Nach einer Änderung exakt denselben Test wiederholen.
  5. Diagnoseausgaben vor Weitergabe auf sensible Daten prüfen.
  6. Temporär extrahierte Schlüssel- oder Zertifikatsdateien sicher behandeln.

37. Kurzreferenz – häufige OpenSSL-Befehle

Befehlstabelle anzeigen
Aufgabe Befehl
Version [RO] openssl version -a
TLS-Verbindung [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com
Kompakte Ausgabe [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -brief
Hostname prüfen [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error
Zertifikatsliste [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -showcerts
Eigene CA [TEST][FILE][SENS] openssl s_client -connect example.com:443 -servername example.com -CAfile root-ca.pem -verify_return_error
TLS 1.2 [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_2
TLS 1.3 [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_3
ALPN [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -alpn 'h2,http/1.1'
OCSP Stapling [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -status
SMTP STARTTLS [TEST][SENS] openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com
IMAP STARTTLS [TEST][SENS] openssl s_client -starttls imap -connect mail.example.com:143 -servername mail.example.com
LDAP STARTTLS [TEST][SENS] openssl s_client -starttls ldap -connect ldap.example.com:389 -servername ldap.example.com
Zertifikat anzeigen [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -text
Kerndaten [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -subject -issuer -serial -dates
SAN anzeigen [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext subjectAltName
SHA-256-Fingerprint [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -fingerprint -sha256
30 Tage Restlaufzeit [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -checkend 2592000
Kette prüfen [RO][FILE][SENS] openssl verify -CAfile root-ca.pem -untrusted intermediate-ca.pem server-cert.pem
Privaten Schlüssel prüfen [RO][FILE][SENS] openssl pkey -in server-key.pem -check -noout
CSR prüfen [RO][FILE][SENS] openssl req -in request.csr -noout -text -verify
PKCS#12 untersuchen [RO][FILE][SENS] openssl pkcs12 -in bundle.p12 -info -noout
DER nach PEM [CHANGE][FILE][SENS] openssl x509 -in certificate.der -inform DER -out certificate.pem -outform PEM

38. Kurzreferenz – wichtige s_client-Optionen

Optionstabelle anzeigen
Option Bedeutung
-connect host:port Netzwerkziel festlegen
-servername name TLS-SNI setzen
-noservername Kein SNI senden
-verify_hostname name DNS-Namen des Zertifikats prüfen
-verify_ip adresse IP-Identität des Zertifikats prüfen
-verify_return_error Bei Zertifikatsprüffehlern abbrechen
-CAfile datei Vertrauenswürdige CA-Datei verwenden
-showcerts Vom Server gesendete Zertifikate anzeigen
-brief Kompakte Verbindungsübersicht
-no-interactive Nicht interaktiver Modus, sofern unterstützt
-4 IPv4 erzwingen
-6 IPv6 erzwingen
-tls1_2 TLS 1.2 erzwingen
-tls1_3 TLS 1.3 erzwingen
-min_protocol Minimale Protokollversion
-max_protocol Maximale Protokollversion
-cipher Cipher-Auswahl für TLS 1.2 und älter
-ciphersuites Cipher-Suites für TLS 1.3
-alpn ALPN-Protokolle anbieten
-status OCSP-Stapling-Antwort anfordern
-starttls STARTTLS für ein Anwendungsprotokoll
-proxy HTTP-CONNECT-Proxy verwenden
-cert Clientzertifikat angeben
-key Privaten Clientschlüssel angeben
-cert_chain Clientzertifikatskette angeben
-state TLS-Zustände anzeigen
-msg TLS-Protokollnachrichten anzeigen
-trace Ausführlichen TLS-Trace anzeigen
-tlsextdebug TLS-Erweiterungen anzeigen

Merksätze

Quellen

2. Grundwerkzeuge und Befehle

2.11 Microsoft Sysinternals – Windows-Prozesse und Systemaktivitäten analysieren

Microsoft Sysinternals ist eine Sammlung spezialisierter Werkzeuge zur Diagnose von Windows-Systemen. Die Programme ermöglichen wesentlich tiefere Einblicke als der Task-Manager oder die üblichen Windows-Bordmittel.

Mit Sysinternals lassen sich unter anderem folgende Fragen beantworten:

Wichtig: Sysinternals liefert technische Beobachtungen, aber nicht automatisch die Ursache einer Störung. Ein einzelner ungewöhnlicher Eintrag ist noch kein Beweis für einen Fehler oder Schadsoftware. Entscheidend sind Zusammenhang, zeitlicher Ablauf, Vergleichswerte und reproduzierbares Verhalten.

1. Kennzeichnungen und Sicherheitsregeln
Kennzeichnung Bedeutung
[RO] Read-only: liest Informationen aus, ohne den Zustand absichtlich zu verändern
[TEST] Führt einen aktiven Test aus oder erzeugt zusätzliche Systemlast
[PRIV] Benötigt möglicherweise Administratorrechte
[FILE] Erzeugt oder verändert eine Datei
[SENS] Ergebnis kann vertrauliche Daten enthalten
[CHANGE] Verändert Einstellungen oder einen Systemzustand
[DISRUPT] Kann Programme, Verbindungen oder Dienste unterbrechen

Bei der Arbeit mit Sysinternals gelten folgende Grundregeln:

  1. Werkzeuge ausschließlich von Microsoft beziehungsweise über die offizielle Sysinternals-Seite beziehen.
  2. Vor einer Analyse Zeitpunkt, betroffenen Computer, angemeldeten Benutzer und Fehlerbild dokumentieren.
  3. Zuerst nur beobachten und Daten erfassen.
  4. Prozesse, Handles, Verbindungen oder Autostarteinträge nicht vorschnell beenden beziehungsweise löschen.
  5. Administratorrechte nur verwenden, wenn sie für die Untersuchung erforderlich sind.
  6. Speicherabbilder, Process-Monitor-Aufzeichnungen und exportierte Listen als vertrauliche Daten behandeln.
  7. VirusTotal-Abfragen nur unter Beachtung der betrieblichen Datenschutz- und Sicherheitsvorgaben verwenden.
  8. Änderungen immer mit Rückweg, Sicherung und dokumentiertem Ausgangszustand durchführen.
2. Sysinternals sicher beziehen und starten

Die Werkzeuge können einzeln oder als vollständige Sysinternals Suite heruntergeladen werden.

Offizielle Bezugsquellen:

Die Suite eignet sich besonders für einen zentral gepflegten administrativen Werkzeugbestand.

Beispiel für eine lokale Ablage

C:\Admin\Sysinternals\

Start über Sysinternals Live

\\live.sysinternals.com\tools\procexp.exe

\\live.sysinternals.com\tools\procmon.exe

Das direkte Starten über Sysinternals Live kann durch Firewall-, Proxy-, WebDAV-, SMB- oder Sicherheitsrichtlinien verhindert werden. Für reproduzierbare Analysen ist eine lokal bereitgestellte und betrieblich freigegebene Version häufig sinnvoller.

Grundlegende Prüfung einer heruntergeladenen Datei

[RO] Get-AuthenticodeSignature "C:\Admin\Sysinternals\procexp.exe"

[RO] Get-FileHash "C:\Admin\Sysinternals\procexp.exe" -Algorithm SHA256

Die Signatur sollte gültig sein und zu Microsoft gehören. Ein Hashwert dient zur eindeutigen Dokumentation einer untersuchten Version, beweist allein aber nicht deren Vertrauenswürdigkeit.

Wichtiger Hinweis zur Lizenzvereinbarung

Viele Sysinternals-Kommandozeilenwerkzeuge unterstützen:

-accepteula

Damit wird die Lizenzvereinbarung ohne interaktive Rückfrage akzeptiert. Diese Option sollte nur eingesetzt werden, wenn die Lizenzvereinbarung organisatorisch geprüft und akzeptiert wurde.

3. Welches Sysinternals-Werkzeug eignet sich für welches Problem?
Problem oder Fragestellung Geeignetes Werkzeug Typische Untersuchung
Hohe CPU-Auslastung Process Explorer, PsList, ProcDump Verursachenden Prozess und Threads bestimmen
Ungewöhnlich hoher Speicherverbrauch Process Explorer, RAMMap, VMMap Speicherverteilung und Prozesswachstum untersuchen
Datei oder Ordner ist gesperrt Process Explorer, Handle Prozess mit geöffnetem Handle ermitteln
Anwendung startet nicht Process Monitor, Autoruns, Sigcheck Fehlende Dateien, Berechtigungsfehler und Abhängigkeiten suchen
Anwendung stürzt ab ProcDump, Process Monitor Speicherabbild und Aktivitäten vor dem Absturz erfassen
Anwendung reagiert nicht Process Explorer, ProcDump Threads untersuchen und Hang-Dump erzeugen
Unbekannte Netzwerkverbindung TCPView, Process Explorer Verbindung einem Prozess zuordnen
Langsame Windows-Anmeldung Autoruns, Process Monitor Anmeldeobjekte, Dienste und Dateizugriffe untersuchen
Verdächtiger Autostart Autoruns, Sigcheck Herausgeber, Signatur, Pfad und Startmechanismus prüfen
Unbekannte ausführbare Datei Sigcheck, Process Explorer Signatur, Hash, Pfad und laufenden Prozess untersuchen
DLL-Konflikt Process Explorer, ListDLLs, Process Monitor Geladene DLL-Versionen und Suchpfade vergleichen
Handle-Leak Process Explorer, Handle Entwicklung der Handle-Anzahl beobachten
Speicherverteilung des Systems RAMMap Standby-Liste, Dateicache und physische Speichernutzung analysieren
Speicherbelegung eines Prozesses VMMap Private, gemeinsam genutzte und zugeordnete Bereiche untersuchen
Dauerhafte Ereigniserfassung Sysmon Sicherheitsrelevante Systemereignisse protokollieren
Fernadministration PsTools Autorisierte Prozess-, Dienst- und Systemabfragen durchführen
4. Process Explorer – Prozesse genauer untersuchen

Process Explorer ist eine erweiterte Prozessanzeige. Das Werkzeug stellt Prozesse hierarchisch dar und zeigt unter anderem:

Sinnvoller Diagnoseablauf

  1. Process Explorer möglichst zunächst ohne Administratorrechte starten.
  2. Prozessbaum und auffällige Prozesse identifizieren.
  3. Bei unvollständiger Sichtbarkeit kontrolliert als Administrator neu starten.
  4. Eigenschaften des betroffenen Prozesses öffnen.
  5. Pfad, Kommandozeile, Benutzerkonto und übergeordneten Prozess prüfen.
  6. CPU-, Speicher-, Datenträger- und Netzwerkentwicklung beobachten.
  7. Digitale Signatur kontrollieren.
  8. Bei hoher CPU-Auslastung die einzelnen Threads untersuchen.
  9. Beobachtungen mit Zeitpunkt und Prozess-ID dokumentieren.

Wichtige Bewertungsfragen

Eigenschaft Fragestellung
Image Path Liegt die Datei im erwarteten Programmverzeichnis?
Command Line Mit welchen Parametern wurde der Prozess gestartet?
Parent Process Welcher Prozess hat ihn gestartet?
User Name Unter welchem Benutzer- oder Dienstkonto läuft er?
Verified Signer Ist die Signatur gültig und passt der Herausgeber?
Start Time Begann das Problem mit dem Prozessstart?
Threads Welcher Thread erzeugt die Auslastung?
Handles Steigt die Anzahl dauerhaft an?
TCP/IP Baut der Prozess unerwartete Verbindungen auf?

Datei oder DLL suchen

Über die Suchfunktion von Process Explorer kann nach einem Teil des Datei-, Ordner-, Registry- oder DLL-Namens gesucht werden. Dadurch lässt sich beispielsweise ermitteln, welcher Prozess eine Datei geöffnet hält.

Find → Find Handle or DLL

Wichtige Grenzen

Eingreifende Funktionen

Aktion Risiko
Prozess beenden [CHANGE][DISRUPT] Ungespeicherte Daten können verloren gehen
Prozessbaum beenden [CHANGE][DISRUPT] Beendet zusätzlich untergeordnete Prozesse
Prozess anhalten [CHANGE][DISRUPT] Anwendung oder abhängige Dienste können blockieren
Handle schließen [CHANGE][DISRUPT] Anwendung kann abstürzen oder Daten beschädigen
Priorität ändern [CHANGE] Kann Leistungsverhalten und Stabilität beeinflussen

Diese Funktionen gehören nicht zur ersten Diagnosephase.

5. Process Monitor – Datei-, Registry- und Prozesszugriffe verfolgen

Process Monitor, kurz Procmon, zeichnet in Echtzeit folgende Aktivitäten auf:

Process Monitor eignet sich besonders, wenn eine Anwendung:

Empfohlener Aufnahmeablauf

  1. Fehlerbild und genaue Uhrzeit notieren.
  2. Process Monitor starten.
  3. Laufende Aufzeichnung zunächst anhalten.
  4. Bereits angezeigte Ereignisse leeren.
  5. Filter auf den betroffenen Prozess setzen.
  6. Aufzeichnung starten.
  7. Fehler genau einmal reproduzieren.
  8. Aufzeichnung sofort wieder anhalten.
  9. Ereignisse unmittelbar vor und nach dem Fehler untersuchen.
  10. Originalaufzeichnung im PML-Format sichern.
  11. Sensible Daten und Aufbewahrungsregeln beachten.

Nützliche Standard-Tastenkombinationen

Funktion Tastenkombination
Aufzeichnung starten oder anhalten Strg+E
bisher angezeigte Ereignisse löschen Strg+X
Filterdialog öffnen Strg+L
Ereignis suchen Strg+F
Aufnahme speichern Strg+S

Beispiel für einen Prozessfilter

Process Name  is  beispiel.exe  Include

Weitere nützliche Filter:

Process ID    is        4321          Include
Result        is        ACCESS DENIED Include
Path          contains  \Config\      Include
Operation     is        CreateFile    Include

Mehrere Include-Filter derselben Eigenschaft wirken typischerweise wie eine ODER-Verknüpfung. Unterschiedliche Eigenschaften grenzen das Ergebnis weiter ein. Der Filter sollte deshalb bewusst aufgebaut und im Filterdialog kontrolliert werden.

Häufige Resultate richtig interpretieren

Resultat Grundbedeutung Bewertung
SUCCESS Operation war erfolgreich Kein Fehler für diese einzelne Operation
NAME NOT FOUND Name oder Objekt wurde nicht gefunden Kann normaler Suchlauf oder tatsächliche Ursache sein
PATH NOT FOUND Ein Bestandteil des Pfades fehlt Pfad, Laufwerk, Freigabe oder Konfiguration prüfen
ACCESS DENIED Zugriff wurde verweigert Berechtigungen, Integritätsstufe und Sicherheitssoftware prüfen
SHARING VIOLATION Objekt ist inkompatibel geöffnet Öffnenden Prozess und Freigabemodus untersuchen
BUFFER OVERFLOW bereitgestellter Puffer war zunächst zu klein Häufig Bestandteil einer normalen Größenabfrage
REPARSE Zugriff wurde über einen Reparse Point umgeleitet Junction, symbolischen Link oder Cloud-Platzhalter prüfen
END OF FILE Dateiende wurde erreicht Kann bei normalen Lesevorgängen auftreten

NAME NOT FOUND und BUFFER OVERFLOW treten bei normalen Windows-Abläufen sehr häufig auf. Entscheidend ist, ob danach ein erfolgreicher Alternativzugriff erfolgt oder die Anwendung unmittelbar anschließend scheitert.

PML-Dateien

Eine gespeicherte PML-Datei kann enthalten:

Daher gilt:

[SENS][FILE] PML-Dateien nur geschützt speichern und kontrolliert weitergeben.
6. Autoruns – Autostarts und Anmeldeverzögerungen untersuchen

Autoruns zeigt zahlreiche Stellen, über die Programme, Dienste, Treiber und Erweiterungen automatisch gestartet werden können.

Dazu gehören unter anderem:

Sicherer Diagnoseablauf

  1. Autoruns starten und vollständiges Einlesen abwarten.
  2. Betroffenen Benutzer und Systemkontext beachten.
  3. Eintrag, Pfad, Herausgeber und digitale Signatur prüfen.
  4. Vor Veränderungen einen Export oder Screenshot erstellen.
  5. Microsoft-Einträge nur ausblenden, um Fremdsoftware übersichtlicher zu prüfen.
  6. Bei einem begründeten Verdacht einen Eintrag zunächst deaktivieren.
  7. System oder Anmeldung kontrolliert testen.
  8. Ergebnis dokumentieren.
  9. Eintrag wieder aktivieren, wenn keine Verbesserung eingetreten ist.

Das Entfernen des Häkchens deaktiviert einen Eintrag und ist grundsätzlich leichter rückgängig zu machen als das Löschen.

[CHANGE] Deaktivieren: Eintrag abwählen

[CHANGE][DISRUPT] Löschen: Eintrag dauerhaft entfernen

Autostarteinträge sollten während der Fehleranalyse nicht vorschnell gelöscht werden.

Autorunsc – Kommandozeilenversion

Alle Kategorien anzeigen:

[RO][PRIV] autorunsc.exe -a * -s

Alle Kategorien mit Signaturprüfung und CSV-Ausgabe erfassen:

[RO][PRIV][FILE] autorunsc.exe -a * -s -c > C:\Temp\autoruns.csv

Microsoft-Einträge ausblenden:

[RO][PRIV] autorunsc.exe -a * -m -s

Geplante Aufgaben anzeigen:

[RO][PRIV] autorunsc.exe -a t -s

Dienste und nicht deaktivierte Treiber anzeigen:

[RO][PRIV] autorunsc.exe -a s -s

Anmeldeeinträge anzeigen:

[RO] autorunsc.exe -a l -s

WMI-Autostarts anzeigen:

[RO][PRIV] autorunsc.exe -a m -s

Wichtige Kategorien

Option Kategorie
-a * Alle Kategorien
-a b Boot-Execute-Einträge
-a d AppInit-DLLs
-a e Explorer-Erweiterungen
-a h Image Hijacks
-a i Internet-Explorer-Erweiterungen
-a k Known DLLs
-a l Anmeldeeinträge
-a m WMI-Einträge
-a n Winsock- und Netzwerkprovider
-a p Druckmonitor-DLLs
-a r LSA-Sicherheitsprovider
-a s Dienste und nicht deaktivierte Treiber
-a t Geplante Aufgaben
-a w Winlogon-Einträge

VirusTotal-Hinweis

Die Autoruns- und Autorunsc-Integration kann Hashwerte an VirusTotal übermitteln. Abhängig von den gewählten Optionen können unbekannte Dateien auch hochgeladen werden.

[SENS] Keine VirusTotal-Abfrage ohne betriebliche Freigabe durchführen.

Insbesondere darf eine Upload-Funktion nicht für vertrauliche, proprietäre oder personenbezogene Dateien verwendet werden. Eine VirusTotal-Erkennung ist außerdem nur ein Hinweis und kein abschließender Malware-Beweis.

7. TCPView und Tcpvcon – Netzwerkverbindungen Prozessen zuordnen

TCPView zeigt TCP- und UDP-Endpunkte einschließlich:

Damit lässt sich beispielsweise feststellen, welches Programm eine Verbindung zu einer bestimmten IP-Adresse aufgebaut hat oder welcher Prozess auf einem lokalen Port lauscht.

Typischer Untersuchungsablauf

  1. TCPView starten.
  2. Nach Prozess, Port oder Zieladresse suchen.
  3. Namensauflösung bei Bedarf deaktivieren, damit nur tatsächliche IP-Adressen erscheinen.
  4. Prozess-ID und Programmpfad mit Process Explorer abgleichen.
  5. Zieladresse, Port, Prozesskontext und Verbindungszeitpunkt dokumentieren.
  6. Erst danach bewerten, ob die Verbindung erwartet ist.

Tcpvcon – Kommandozeilenversion

Aktive TCP-Verbindungen anzeigen:

[RO] tcpvcon.exe

Alle TCP- und UDP-Endpunkte anzeigen:

[RO] tcpvcon.exe -a

Namensauflösung deaktivieren:

[RO] tcpvcon.exe -a -n

CSV-Ausgabe erzeugen:

[RO][FILE] tcpvcon.exe -a -n -c > C:\Temp\tcp-endpoints.csv

Bestimmten Prozess untersuchen:

[RO] tcpvcon.exe -a -n beispiel.exe

Bestimmte PID untersuchen:

[RO] tcpvcon.exe -a -n 4321
Option Bedeutung
-a Alle Endpunkte anzeigen
-c CSV-Ausgabe erzeugen
-n Adressen nicht in Namen auflösen
Prozessname oder PID Ausgabe auf einen Prozess begrenzen

TCPView kann eine bestehende TCP-Verbindung schließen:

[CHANGE][DISRUPT] Close Connection

Dadurch wird nur die konkrete Verbindung unterbrochen. Der Prozess kann anschließend erneut eine Verbindung herstellen. Diese Funktion ersetzt weder eine Firewall-Regel noch das Beenden oder Konfigurieren des verursachenden Programms.

8. Handle – Dateisperren und offene Objekte ermitteln

Handle zeigt geöffnete Handles eines Prozesses an. Damit kann insbesondere festgestellt werden, welches Programm eine Datei oder einen Ordner geöffnet hält.

Handle benötigt laut Microsoft Administratorrechte.

Nach einem Teil eines Dateinamens suchen:

[RO][PRIV] handle.exe bericht.xlsx

Nach einem Pfadbestandteil suchen:

[RO][PRIV] handle.exe C:\Daten\Projekt

Handles eines bestimmten Prozesses anzeigen:

[RO][PRIV] handle.exe -p explorer

Handles einer bestimmten PID anzeigen:

[RO][PRIV] handle.exe -p 4321

Besitzenden Benutzer anzeigen:

[RO][PRIV] handle.exe -u bericht.xlsx

Anzahl der verschiedenen Handle-Typen anzeigen:

[RO][PRIV] handle.exe -s

Alle Arten von Handles anzeigen:

[RO][PRIV] handle.exe -a -p 4321

Beispielausgabe sinngemäß interpretieren

beispiel.exe pid: 4321
  7C: File  C:\Daten\Projekt\bericht.xlsx
Feld Bedeutung
beispiel.exe Prozessname
4321 Prozess-ID
7C Handle-Wert in hexadezimaler Schreibweise
File Objekttyp
Pfad geöffnetes Objekt

Handle kann ein einzelnes Handle zwangsweise schließen:

[CHANGE][DISRUPT][PRIV] handle.exe -c 7C -p 4321

Das erzwungene Schließen eines Handles kann Anwendungen zum Absturz bringen, Daten beschädigen oder das System destabilisieren. Diese Funktion ist kein regulärer erster Lösungsweg. Besser ist es, das verantwortliche Programm geordnet zu schließen oder den zugehörigen Dienst kontrolliert zu beenden.

Die Option -y unterdrückt die Sicherheitsabfrage beim Schließen und sollte bei einer manuellen Fehleranalyse nicht eingesetzt werden.

9. Sigcheck – Signaturen, Versionen und Hashwerte prüfen

Sigcheck zeigt unter anderem:

Erweiterte Dateiinformationen anzeigen:

[RO] sigcheck.exe -nobanner -a "C:\Programme\Beispiel\beispiel.exe"

Hashwerte anzeigen:

[RO] sigcheck.exe -nobanner -h "C:\Programme\Beispiel\beispiel.exe"

Signatur und Zertifikatskette anzeigen:

[RO] sigcheck.exe -nobanner -i "C:\Programme\Beispiel\beispiel.exe"

Kombinierte Prüfung:

[RO] sigcheck.exe -nobanner -a -h -i "C:\Programme\Beispiel\beispiel.exe"

Nicht signierte ausführbare Dateien in System32 suchen:

[RO][PRIV] sigcheck.exe -nobanner -u -e C:\Windows\System32

Unterordner rekursiv untersuchen:

[RO][PRIV] sigcheck.exe -nobanner -u -e -s C:\Windows\System32
Option Bedeutung
-a Erweiterte Versionsinformationen anzeigen
-e Nur ausführbare Images untersuchen
-h Hashwerte anzeigen
-i Zertifikatskette und Katalog anzeigen
-s Unterverzeichnisse rekursiv durchsuchen
-u Ohne VirusTotal nur nicht signierte Dateien anzeigen
-c CSV-Ausgabe
-ct Tabulatorgetrennte Ausgabe
-nobanner Startbanner ausblenden
-accepteula Lizenzvereinbarung ohne Dialog akzeptieren

Bewertung einer Signatur

Ergebnis Aussage
Gültige Signatur Datei wurde signiert und seit der Signierung nicht entsprechend verändert
Ungültige Signatur Signaturprüfung ist fehlgeschlagen
Keine Signatur Datei besitzt keine auswertbare digitale Signatur
Bekannter Herausgeber Herausgeber ergibt sich aus dem Zertifikat
Unbekannter Herausgeber Vertrauenskette oder Signatur fehlt beziehungsweise ist nicht vertrauenswürdig

Eine gültige Signatur bedeutet nicht automatisch, dass die Datei sicher oder erwünscht ist. Eine nicht signierte Datei ist umgekehrt nicht automatisch Schadsoftware.

VirusTotal-Optionen

-v

fragt den VirusTotal-Status anhand des Dateihashs ab.

-vs

kann Dateien, die VirusTotal noch nicht kennt, zur Analyse hochladen.

[SENS] `-vs` niemals ohne ausdrückliche Datenschutz- und Sicherheitsfreigabe verwenden.
10. PsList und weitere PsTools – Prozesse und Dienste per Kommandozeile prüfen

Die PsTools enthalten verschiedene Kommandozeilenwerkzeuge für lokale und entfernte Windows-Systeme.

Werkzeug Aufgabe Risiko
PsList Prozessinformationen anzeigen [RO]
PsService Dienste abfragen und verwalten Abfrage [RO], Änderungen [CHANGE][DISRUPT]
PsLoggedOn angemeldete Benutzer anzeigen [RO][SENS]
PsInfo Systeminformationen anzeigen [RO]
PsKill Prozesse beenden [CHANGE][DISRUPT]
PsExec Prozesse lokal oder remote starten [PRIV][CHANGE][DISRUPT]
PsShutdown Computer herunterfahren oder neu starten [PRIV][CHANGE][DISRUPT]

Lokale Prozesse anzeigen:

[RO] pslist.exe

Prozessbaum anzeigen:

[RO] pslist.exe -t

Detaillierte Speicherinformationen anzeigen:

[RO] pslist.exe -m

Bestimmte PID untersuchen:

[RO] pslist.exe 4321

Entfernten Computer abfragen:

[RO][PRIV] pslist.exe \\PC-023

Remote-Abfragen dürfen ausschließlich auf autorisierten Systemen erfolgen. Windows-Firewall, administrative Freigaben, Namensauflösung, Dienststeuerung und Berechtigungen können den Zugriff beeinflussen.

Umgang mit Zugangsdaten

PsTools können bei manchen Werkzeugen Benutzername und Kennwort als Parameter entgegennehmen. Kennwörter sollten nicht direkt in Befehlszeilen eingetragen werden, da sie beispielsweise in:

sichtbar werden können.

Wenn möglich, sollte ein bereits autorisierter administrativer Kontext oder eine betrieblich freigegebene Lösung zur privilegierten Administration verwendet werden.

Besonders eingreifende Werkzeuge

[CHANGE][DISRUPT] pskill.exe 4321

beendet einen Prozess.

[PRIV][CHANGE][DISRUPT] psexec.exe \\PC-023 Programm.exe

startet einen Prozess auf einem entfernten Computer.

Diese Befehle sind keine reinen Diagnosebefehle. Vor ihrer Verwendung müssen Zielsystem, Prozess, Auswirkung, Berechtigung und Rückweg eindeutig geklärt sein.

11. ProcDump – Speicherabbilder bei Abstürzen, Hängern und Lastspitzen erstellen

ProcDump kann Speicherabbilder eines Prozesses manuell oder beim Eintreten bestimmter Bedingungen erzeugen.

Typische Auslöser sind:

Vollständiges Speicherabbild einer PID erzeugen

[TEST][PRIV][FILE][SENS] procdump.exe -ma 4321 C:\Dumps

Speicherabbild bei nicht reagierendem Fenster

[TEST][PRIV][FILE][SENS] procdump.exe -ma -h beispiel.exe C:\Dumps

Bis zu drei Speicherabbilder bei erhöhter CPU-Auslastung

[TEST][PRIV][FILE][SENS] procdump.exe -ma -n 3 -s 5 -c 80 beispiel.exe C:\Dumps

Der Befehl reagiert, wenn der Prozess die angegebene CPU-Schwelle für die festgelegte Anzahl aufeinanderfolgender Sekunden überschreitet.

Speicherabbild bei einer unbehandelten Ausnahme

[TEST][PRIV][FILE][SENS] procdump.exe -ma -e beispiel.exe C:\Dumps

Auf einen noch nicht gestarteten Prozess warten

[TEST][PRIV][FILE][SENS] procdump.exe -ma -e -w beispiel.exe C:\Dumps
Option Bedeutung
-ma vollständiges Speicherabbild
-mm Mini-Dump; Standard
-n 3 maximal drei Abbilder erzeugen
-s 5 Bedingung muss fünf Sekunden bestehen
-c 80 CPU-Schwelle von 80 Prozent
-h bei einem nicht reagierenden Fenster auslösen
-e bei unbehandelter Ausnahme auslösen
-e 1 zusätzlich bei First-Chance-Ausnahmen auslösen
-w auf den Start des Prozesses warten
-t beim Beenden des Prozesses auslösen
-o vorhandene Zieldatei überschreiben

Warum Speicherabbilder besonders geschützt werden müssen

Ein Speicherabbild kann unter anderem enthalten:

[SENS][FILE] Speicherabbilder verschlüsselt ablegen, Zugriff begrenzen und nach der Analyse kontrolliert löschen.

Vollständige Abbilder können groß sein und während der Erstellung zusätzliche CPU-, Arbeitsspeicher- und Datenträgerlast verursachen. Auf produktiven Systemen sind Speicherplatz und mögliche Unterbrechungen vorab zu prüfen.

ProcDump kann außerdem als systemweiter Postmortem-Debugger registriert werden. Da dies die Systemkonfiguration verändert, gehört eine solche Registrierung nicht in die normale spontane Diagnose:

[PRIV][CHANGE] procdump.exe -ma -i C:\Dumps

Rücknahme:

[PRIV][CHANGE] procdump.exe -u
12. RAMMap und VMMap – Arbeitsspeicher genauer analysieren

RAMMap

RAMMap untersucht die Verwendung des physischen Arbeitsspeichers des gesamten Windows-Systems.

Wichtige Ansichten:

Ansicht Aussage
Use Counts Speichernutzung nach Verwendungsart
Processes physische Speichernutzung nach Prozess
Priority Summary Speicher nach Priorität
Physical Pages einzelne physische Speicherseiten
Physical Ranges physische Speicherbereiche
File Summary im RAM befindliche Dateidaten
File Details einzelne Dateien und Speicherseiten

RAMMap hilft bei Fragen wie:

VMMap

VMMap untersucht den virtuellen und physischen Speicher eines einzelnen Prozesses.

VMMap zeigt unter anderem:

VMMap ist besonders nützlich, wenn der Speicherverbrauch eines bestimmten Prozesses über längere Zeit zunimmt.

Beobachtung statt Momentaufnahme

Bei einem vermuteten Speicherproblem sollten mehrere Messpunkte dokumentiert werden:

Zeitpunkt Private Bytes Working Set Commit Handles Threads
Start … … … … …
nach 15 Minuten … … … … …
nach Reproduktion … … … … …
nach 60 Minuten … … … … …

Ein hoher Wert allein beweist kein Speicherleck. Entscheidend ist, ob die Nutzung unter vergleichbaren Bedingungen dauerhaft wächst und nicht wieder freigegeben wird.

RAMMap enthält Funktionen zum Leeren bestimmter Speicherlisten. Diese verändern den Systemzustand und können Messergebnisse verfälschen:

[CHANGE][DISRUPT] „Empty“-Funktionen nicht während der ursprünglichen Beweissicherung verwenden.
13. ListDLLs – geladene DLLs eines Prozesses anzeigen

ListDLLs zeigt die von Prozessen geladenen DLLs an. Das Werkzeug kann helfen, wenn:

DLLs eines bestimmten Prozesses anzeigen:

[RO] listdlls.exe beispiel.exe

DLLs einer bestimmten PID anzeigen:

[RO] listdlls.exe 4321

Nach Prozessen suchen, die eine bestimmte DLL geladen haben:

[RO] listdlls.exe beispiel.dll

Versionsinformationen anzeigen:

[RO] listdlls.exe -v beispiel.exe

Nicht signierte DLLs hervorheben beziehungsweise anzeigen:

[RO] listdlls.exe -u beispiel.exe

Bei der Bewertung sind mindestens folgende Punkte zu prüfen:

Eine DLL mit ungewöhnlichem Pfad ist ein Prüfhinweis, aber noch kein Beweis für Manipulation.

14. Sysmon – dauerhafte sicherheitsrelevante Ereigniserfassung

Sysmon installiert einen Windows-Systemdienst und einen Treiber. Anschließend protokolliert es abhängig von der Konfiguration detaillierte Systemereignisse, beispielsweise:

Die Ereignisse befinden sich üblicherweise unter:

Anwendungs- und Dienstprotokolle
└─ Microsoft
   └─ Windows
      └─ Sysmon
         └─ Operational

Sysmon ist kein spontanes Read-only-Diagnosewerkzeug. Installation und Konfiguration verändern das System dauerhaft:

[PRIV][CHANGE] sysmon64.exe -accepteula -i config.xml

Aktuelle Konfiguration anzeigen:

[RO][PRIV] sysmon64.exe -c

Konfiguration aktualisieren:

[PRIV][CHANGE] sysmon64.exe -c config.xml

Sysmon deinstallieren:

[PRIV][CHANGE][DISRUPT] sysmon64.exe -u

Vor einer Einführung müssen geklärt werden:

Sysmon bewertet Ereignisse nicht selbst als gutartig oder bösartig. Die Qualität der Ergebnisse hängt wesentlich von der Konfiguration und der anschließenden Auswertung ab.

15. Praxisfall – hohe CPU-Auslastung untersuchen

Ziel: Verursachenden Prozess und möglichst den auslösenden Thread bestimmen.

  1. Uhrzeit und wahrgenommene Auswirkung dokumentieren.
  2. Mit Task-Manager oder Process Explorer den Prozess bestimmen.
  3. CPU-Verlauf über einen angemessenen Zeitraum beobachten.
  4. Prozesspfad, Benutzer, Kommandozeile und übergeordneten Prozess prüfen.
  5. In Process Explorer die Prozesseigenschaften öffnen.
  6. Unter Threads nach CPU-Auslastung sortieren.
  7. Auffälligen Thread und zugehöriges Modul dokumentieren.
  8. Ereignisanzeige und Anwendungsprotokolle zum selben Zeitpunkt prüfen.
  9. Bei reproduzierbaren Lastspitzen kontrolliert ProcDump einsetzen.
  10. Speicherabbild an Hersteller oder Entwicklung zur Analyse übergeben.

Nicht vorschnell tun:

16. Praxisfall – Datei oder Ordner lässt sich nicht ändern, löschen oder umbenennen

Typische Meldungen

Diagnoseablauf

  1. Vollständigen Pfad dokumentieren.
  2. Berechtigungen und Besitzverhältnisse prüfen.
  3. Mit Process Explorer nach Dateiname oder Pfad suchen.
  4. Alternativ Handle verwenden:
[RO][PRIV] handle.exe "C:\Daten\Projekt\bericht.xlsx"
  1. Prozessname, PID, Benutzerkonto und Zweck identifizieren.
  2. Prüfen, ob der Prozess regulär geschlossen werden kann.
  3. Bei einem Dienst den zuständigen Dienst bestimmen.
  4. Anwendung oder Dienst kontrolliert schließen.
  5. Dateioperation erneut testen.
  6. Ergebnis dokumentieren.

Ein Handle sollte nicht zwangsweise geschlossen werden, solange ein geordnetes Beenden des verantwortlichen Programms möglich ist.

17. Praxisfall – Anwendung startet nicht

Diagnoseablauf

  1. Exakte Fehlermeldung und Uhrzeit dokumentieren.
  2. Anwendungspfad und Version prüfen.
  3. Digitale Signatur der Programmdatei prüfen:
[RO] sigcheck.exe -nobanner -a -h -i "C:\Programme\Beispiel\beispiel.exe"
  1. Ereignisanzeige und anwendungseigene Protokolle prüfen.
  2. Process Monitor vorbereiten.
  3. Filter auf den Prozessnamen setzen.
  4. Aufnahme starten und Anwendung einmal starten.
  5. Aufnahme sofort stoppen.
  6. Letzte Zugriffe vor dem Prozessende untersuchen.
  7. Besonders auf folgende Resultate achten:
ACCESS DENIED
PATH NOT FOUND
NAME NOT FOUND
SHARING VIOLATION
BAD IMAGE
  1. Geladene DLLs und deren Pfade prüfen.
  2. Vergleich mit einem funktionierenden Referenzsystem durchführen.
  3. Erst nach belegter Ursache Berechtigung, Pfad, Konfiguration oder Installation ändern.

Viele NAME NOT FOUND-Ereignisse sind Teil eines normalen Suchvorgangs. Relevant ist häufig der letzte nicht erfolgreich ersetzte Zugriff unmittelbar vor dem Abbruch.

18. Praxisfall – unbekannte Netzwerkverbindung untersuchen
  1. Lokale und entfernte Adresse dokumentieren.
  2. Port, Protokoll und Verbindungsstatus erfassen.
  3. Prozess-ID mit TCPView oder Tcpvcon bestimmen:
[RO] tcpvcon.exe -a -n
  1. Prozess-ID in Process Explorer untersuchen.
  2. Dateipfad, Kommandozeile, Benutzer und übergeordneten Prozess prüfen.
  3. Signatur und Hash der ausführbaren Datei erfassen.
  4. DNS-Auflösung und Zielsystem kontrollieren.
  5. Prüfen, ob die Verbindung zur Funktion der Anwendung passt.
  6. Firewall-, Proxy- und Sicherheitsprotokolle zum selben Zeitpunkt vergleichen.
  7. Bei tatsächlichem Verdacht das Incident-Response-Verfahren des Unternehmens anwenden.

Eine unbekannte externe IP-Adresse kann beispielsweise zu einem CDN, Cloudanbieter, Update-Dienst oder Sicherheitsdienst gehören. Eine Eigentümerabfrage allein beweist daher weder Zweck noch Vertrauenswürdigkeit der Verbindung.

19. Häufige Fehlinterpretationen vermeiden
Beobachtung Falscher Schluss Richtige Einordnung
Prozess ist unbekannt Prozess ist Schadsoftware Pfad, Signatur, Herausgeber, Parent und Funktion prüfen
Datei ist nicht signiert Datei ist schädlich Signatur ist nur ein Bewertungskriterium
Datei ist signiert Datei ist sicher Auch signierte Software kann unerwünscht oder verwundbar sein
Procmon zeigt NAME NOT FOUND Ursache wurde gefunden Suchvorgänge erzeugen diesen Status regelmäßig
Procmon zeigt BUFFER OVERFLOW Speicherüberlauf der Anwendung Häufig normale Ermittlung der benötigten Puffergröße
Viele TCP-Verbindungen System ist kompromittiert Browser, Cloud- und Kommunikationsprogramme erzeugen viele Verbindungen
Hoher RAM-Verbrauch Arbeitsspeicher ist defekt Cache, Commit, Working Set und Speichertypen getrennt prüfen
Hohe Handle-Anzahl Sicheres Handle-Leak Verlauf und Referenzwerte beobachten
VirusTotal meldet nichts Datei ist garantiert sicher Fehlende Erkennungen sind keine Sicherheitsgarantie
Autoruns-Eintrag ist unbekannt Eintrag muss gelöscht werden Zweck, Pfad und Herausgeber zunächst ermitteln
Prozess lässt sich beenden Problem ist gelöst Ursache kann weiterbestehen und erneut auftreten
20. Empfohlener Sysinternals-Diagnoseablauf
Phase Vorgehen Geeignete Werkzeuge
1. Störung aufnehmen Fehler, Zeitpunkt und Auswirkung dokumentieren Ticket, Screenshot, Ereignisanzeige
2. Prozess bestimmen Prozessname, PID und Benutzer ermitteln Process Explorer, PsList
3. Herkunft prüfen Pfad, Parent, Kommandozeile und Signatur prüfen Process Explorer, Sigcheck
4. Aktivität beobachten Datei-, Registry-, Prozess- und Netzwerkzugriffe erfassen Process Monitor, TCPView
5. Ressourcen untersuchen CPU, Handles und Speicherentwicklung prüfen Process Explorer, Handle, RAMMap, VMMap
6. Autostart prüfen Startmechanismen und Anmeldeobjekte untersuchen Autoruns
7. Fehler reproduzieren Gefilterte, zeitlich begrenzte Aufnahme erstellen Process Monitor
8. Beweise sichern PML, CSV, Screenshots oder Dump geschützt speichern Procmon, Autorunsc, ProcDump
9. Hypothese testen Nur eine kontrollierte Änderung durchführen abhängig von Ursache
10. Ergebnis bestätigen Ausgangsfehler erneut testen und Nebenwirkungen prüfen gleiche Messmethode
11. Dokumentieren Ursache, Änderung, Ergebnis und Rückweg festhalten BookStack, Ticketsystem

Merksatz

Erst beobachten, dann zuordnen, anschließend vergleichen und erst danach verändern.

21. Kompakte Befehlsübersicht
Aufgabe Befehl Kennzeichnung
Signatur mit PowerShell prüfen Get-AuthenticodeSignature "C:\Pfad\Datei.exe" [RO]
SHA-256-Hash berechnen Get-FileHash "C:\Pfad\Datei.exe" -Algorithm SHA256 [RO]
Alle Autostarts anzeigen autorunsc.exe -a * -s [RO][PRIV]
Autostarts als CSV speichern autorunsc.exe -a * -s -c > C:\Temp\autoruns.csv [RO][PRIV][FILE]
Alle Netzwerkendpunkte anzeigen tcpvcon.exe -a -n [RO]
Endpunkte als CSV speichern tcpvcon.exe -a -n -c > C:\Temp\tcp.csv [RO][FILE]
Dateiinhaber suchen handle.exe bericht.xlsx [RO][PRIV]
Handles eines Prozesses anzeigen handle.exe -p 4321 [RO][PRIV]
Dateisignatur und Hash prüfen sigcheck.exe -nobanner -a -h -i Datei.exe [RO]
Nicht signierte System32-Dateien suchen sigcheck.exe -nobanner -u -e C:\Windows\System32 [RO][PRIV]
Prozessliste anzeigen pslist.exe [RO]
Prozessbaum anzeigen pslist.exe -t [RO]
DLLs eines Prozesses anzeigen listdlls.exe 4321 [RO]
vollständiges Prozessabbild erzeugen procdump.exe -ma 4321 C:\Dumps [TEST][PRIV][FILE][SENS]
Dump bei nicht reagierendem Fenster procdump.exe -ma -h beispiel.exe C:\Dumps [TEST][PRIV][FILE][SENS]
Sysmon-Konfiguration anzeigen sysmon64.exe -c [RO][PRIV]
Handle zwangsweise schließen handle.exe -c 7C -p 4321 [PRIV][CHANGE][DISRUPT]
Prozess zwangsweise beenden pskill.exe 4321 [CHANGE][DISRUPT]
22. Dokumentationsvorlage für eine Sysinternals-Analyse 
Ticketnummer:
Analysedatum:
Administrator:
Betroffener Computer:
Betriebssystem:
Angemeldeter Benutzer:
Fehlerbeginn:
Fehlerbeschreibung:
Auswirkung:

Betroffener Prozess:
Prozess-ID:
Programmdatei:
Dateiversion:
Benutzerkonto:
Übergeordneter Prozess:
Kommandozeile:
Digitale Signatur:
SHA-256:

Verwendete Sysinternals-Werkzeuge:
Werkzeugversionen:
Verwendete Filter:
Aufnahmezeitraum:

Beobachtungen:
- 
- 
- 

Ermittelte Auffälligkeiten:
- 
- 
- 

Arbeitshypothese:
Beleg für die Hypothese:
Durchgeführter Test:
Testergebnis:
Durchgeführte Änderung:
Rückweg:
Abschlussprüfung:

Erzeugte Dateien:
- PML:
- CSV:
- Speicherabbild:
- Screenshots:

Speicherort:
Zugriffsberechtigung:
Lösch- oder Aufbewahrungsfrist:
23. Offizielle Quellen und weiterführende Dokumentation

Da Microsoft die Sysinternals-Werkzeuge regelmäßig aktualisiert, sollte vor dem produktiven Einsatz immer die aktuelle offizielle Dokumentation der verwendeten Version geprüft werden.

2. Grundwerkzeuge und Befehle

2.12 Protokolle und Logs systematisch auswerten

Protokolldateien gehören zu den wichtigsten Informationsquellen bei der Fehleranalyse. Sie dokumentieren Ereignisse, Zustandsänderungen, Warnungen und Fehler, die während des Betriebs eines Systems oder einer Anwendung auftreten.

Logs können unter anderem folgende Fragen beantworten:

Grundregel: Nicht mit dem auffälligsten Fehler beginnen, sondern mit dem ersten relevanten Ereignis in der zeitlichen Kette.

1. Kennzeichnungen und Sicherheitsregeln
Kennzeichnung Bedeutung
[RO] Liest Informationen aus, ohne sie absichtlich zu verändern
[TEST] Führt einen aktiven Test aus oder erzeugt zusätzliche Logeinträge
[PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte
[FILE] Erzeugt oder verändert eine Datei
[SENS] Ausgabe kann vertrauliche Daten enthalten
[CHANGE] Verändert Konfiguration, Protokollierung oder Systemzustand
[DISRUPT] Kann Dienste oder Systeme beeinträchtigen

Logs können unter anderem folgende vertrauliche Informationen enthalten:

Deshalb gilt:

  1. Protokolle nur so umfangreich wie erforderlich erfassen.
  2. Exportierte Logs geschützt speichern.
  3. Zugriff auf autorisierte Personen begrenzen.
  4. Vor externer Weitergabe sensible Inhalte redigieren.
  5. Originaldateien möglichst unverändert sichern.
  6. Arbeitskopien getrennt vom Original anlegen.
  7. Aufbewahrungs- und Löschfristen beachten.
  8. Protokolle niemals unkontrolliert in öffentliche Analysedienste hochladen.
2. Wie wird eine Log-Analyse systematisch begonnen?

Vor dem Öffnen der ersten Protokolldatei sollten mindestens folgende Informationen bekannt sein:

Information Beispiel
Betroffenes System CLIENT-023
Betroffener Dienst DNS-Client
Fehlerbeginn 2026-07-31 09:42:15 CEST
Letzter bekannter funktionierender Zeitpunkt 2026-07-31 09:35 CEST
Betroffener Benutzer Max Mustermann
Fehlerbeschreibung Interne Anwendung nicht erreichbar
Reproduzierbarkeit Bei jedem Anmeldeversuch
Kürzliche Änderung VPN-Client aktualisiert
Zeitzone des meldenden Systems Europe/Berlin
Vergleichssystem CLIENT-024 funktioniert

Empfohlener Analysezeitraum

Der Zeitraum sollte zunächst eng um das Ereignis gelegt werden:

Fehlerzeitpunkt: 09:42 Uhr
Erste Untersuchung: 09:37 bis 09:47 Uhr

Falls dort keine Ursache erkennbar ist, wird das Zeitfenster schrittweise erweitert.

Bewährte Reihenfolge

  1. Uhrzeit und Zeitzone aller beteiligten Systeme prüfen.
  2. Fehler reproduzieren und exakten Zeitpunkt notieren.
  3. Passendes Protokoll bestimmen.
  4. Zeitfenster begrenzen.
  5. Nach Quelle, Dienst, Prozess oder Ereignis-ID filtern.
  6. Das erste relevante Ereignis suchen.
  7. Vorhergehende und nachfolgende Ereignisse betrachten.
  8. Meldungen zwischen beteiligten Systemen zeitlich korrelieren.
  9. Hypothese aufstellen.
  10. Hypothese durch einen kontrollierten Test überprüfen.
3. Welche Informationen eines Logeintrags sind wichtig?
Feld Bedeutung Prüffrage
Zeitstempel Zeitpunkt des Ereignisses Welche Zeitzone wird verwendet?
Hostname meldendes System Ist es wirklich das betroffene System?
Quelle oder Provider erzeugende Komponente Welcher Dienst oder Treiber meldet das Ereignis?
Prozess und PID beteiligter Prozess Läuft derselbe Prozess noch?
Benutzer oder UID Sicherheitskontext Unter welchem Konto trat der Fehler auf?
Schweregrad Einordnung durch die Anwendung Ist Error wirklich die Ursache?
Ereignis-ID typisierter Ereigniscode Ist die ID providerspezifisch?
Nachricht menschenlesbare Beschreibung Enthält sie Ursache, Folge oder nur Status?
Fehlercode technischer Rückgabewert Ist der Code dezimal oder hexadezimal?
Korrelations-ID verbindet zusammengehörige Vorgänge Taucht dieselbe ID in anderen Logs auf?
Dienst oder Unit betroffene Komponente Welche Abhängigkeiten besitzt sie?
Datei und Zeile Position im Programmcode Passt sie zur eingesetzten Version?
Dauer Laufzeit einer Operation Wo entsteht die Verzögerung?
Remote-Endpunkt beteiligtes Zielsystem Waren DNS, Routing und Port erreichbar?

Eine Ereignis-ID ist normalerweise nur zusammen mit der Quelle eindeutig.

Ereignis-ID 1000 von Quelle A ≠ Ereignis-ID 1000 von Quelle B
4. Wie werden Schweregrade richtig interpretiert?
Allgemeiner Schweregrad Typische Bedeutung
Trace sehr detaillierter interner Ablauf
Debug Diagnoseinformationen für Entwicklung und Administration
Information reguläres Ereignis oder Statusmeldung
Notice bemerkenswertes, aber nicht zwingend fehlerhaftes Ereignis
Warning unerwarteter Zustand; Verarbeitung kann weiterlaufen
Error Operation ist fehlgeschlagen
Critical schwerwiegender Fehler mit deutlicher Beeinträchtigung
Alert unmittelbares Eingreifen erforderlich
Emergency System oder Dienst ist nicht mehr verwendbar

Die genaue Bedeutung hängt von der jeweiligen Anwendung ab. Nicht jedes Programm verwendet dieselbe Einteilung.

Wichtige Regeln

Beispiel einer Ereigniskette

09:42:10 INFO     DNS-Abfrage gestartet
09:42:15 WARNING  Zeitüberschreitung bei DNS-Server 192.168.10.10
09:42:15 INFO     Zweiter DNS-Server wird verwendet
09:42:16 INFO     Name erfolgreich aufgelöst
09:42:16 ERROR    HTTPS-Verbindung abgelehnt

Hier ist die DNS-Warnung möglicherweise nicht die unmittelbare Ursache, weil die Namensauflösung anschließend erfolgreich war. Die abgelehnte HTTPS-Verbindung muss getrennt untersucht werden.

5. Wie werden Datum, Uhrzeit und Zeitzone geprüft?
Aufgabe Windows Linux macOS
Lokale Zeit [RO] Get-Date -Format o [RO] date --iso-8601=seconds [RO] date "+%Y-%m-%dT%H:%M:%S%z"
UTC-Zeit [RO] (Get-Date).ToUniversalTime().ToString("o") [RO] date -u "+%Y-%m-%dT%H:%M:%SZ" [RO] date -u "+%Y-%m-%dT%H:%M:%SZ"
Zeitzone [RO] Get-TimeZone [RO] timedatectl status [RO][PRIV] sudo systemsetup -gettimezone
Zeitquelle [RO] w32tm /query /source [RO] timedatectl timesync-status [TEST] sntp -d time.apple.com
Synchronisationsstatus [RO] w32tm /query /status [RO] timedatectl status [TEST] sntp -d time.apple.com
chrony-Status Nicht zutreffend [RO] chronyc tracking Nicht standardmäßig vorhanden
chrony-Quellen Nicht zutreffend [RO] chronyc sources -v Nicht standardmäßig vorhanden

Warum ist das wichtig?

Bereits wenige Minuten Zeitabweichung können die Zuordnung zwischen folgenden Systemen erschweren:

Ein Zeitstempel ohne Zeitzone ist nicht eindeutig.

2026-07-31 14:30:00

Ein Zeitstempel mit Offset ist eindeutig zuordenbar:

2026-07-31T14:30:00+02:00

UTC-Darstellung:

2026-07-31T12:30:00Z
6. Wie werden Windows-Ereignisprotokolle grafisch untersucht?

Die Windows-Ereignisanzeige wird mit folgendem Befehl geöffnet:

[RO] eventvwr.msc

Wichtige Protokollbereiche:

Protokoll Typische Inhalte
Anwendung Anwendungs-, Datenbank- und Laufzeitfehler
Sicherheit Anmeldungen, Kontoereignisse und überwachte Zugriffe
Setup Installation und Systemkonfiguration
System Treiber, Dienste, Netzwerk und Betriebssystem
Weitergeleitete Ereignisse zentral gesammelte Ereignisse anderer Systeme
Anwendungs- und Dienstprotokolle komponentenspezifische Windows-Protokolle

Empfohlenes Vorgehen

  1. Passendes Protokoll auswählen.
  2. Aktuelles Protokoll filtern verwenden.
  3. Zeitraum auf den Störungszeitraum begrenzen.
  4. Ereignisebene auswählen.
  5. Falls bekannt, Quelle und Ereignis-ID eingeben.
  6. Ereignis in der Detailansicht öffnen.
  7. Allgemeine und XML-Ansicht vergleichen.
  8. Ereignisse unmittelbar davor und danach untersuchen.
  9. Relevante Ereignisse exportieren oder dokumentieren.

Wichtige Felder

Die XML-Ansicht kann Informationen enthalten, die in der allgemeinen Beschreibung nicht vollständig dargestellt werden.

7. Wie werden Windows-Ereignisse mit PowerShell gelesen?

Verfügbare Ereignisprotokolle auflisten

[RO] Get-WinEvent -ListLog * |
    Select-Object LogName, RecordCount, IsEnabled, LogMode, MaximumSizeInBytes

Nur aktivierte Protokolle anzeigen:

[RO] Get-WinEvent -ListLog * |
    Where-Object IsEnabled |
    Sort-Object LogName |
    Select-Object LogName, RecordCount

Neueste Ereignisse des Systemprotokolls

[RO] Get-WinEvent -LogName System -MaxEvents 20

Neueste Ereignisse des Anwendungsprotokolls

[RO] Get-WinEvent -LogName Application -MaxEvents 20

Ereignisse der letzten Stunde

[RO] $Start = (Get-Date).AddHours(-1)

Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    StartTime = $Start
}

Fehler und kritische Ereignisse der letzten 24 Stunden

[RO] $Start = (Get-Date).AddHours(-24)

Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    Level     = 1, 2
    StartTime = $Start
} | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message
Level Windows-Ebene
1 Kritisch
2 Fehler
3 Warnung
4 Information
5 Ausführlich

Nach Ereignis-ID filtern

[RO] Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    Id      = 7036
} -MaxEvents 20

Nach Provider filtern

[RO] Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Service Control Manager'
    StartTime    = (Get-Date).AddHours(-4)
}

Mehrere Ereignis-IDs abfragen

[RO] Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    Id        = 6005, 6006, 6008, 1074
    StartTime = (Get-Date).AddDays(-7)
} | Select-Object TimeCreated, Id, ProviderName, Message

Ergebnis übersichtlich ausgeben

[RO] Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    Level     = 1, 2, 3
    StartTime = (Get-Date).AddHours(-2)
} | Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  MachineName,
                  Message |
    Format-List

Nach Text in der Meldung suchen

[RO] Get-WinEvent -LogName Application -MaxEvents 1000 |
    Where-Object Message -Match 'timeout|Zeitüberschreitung'

Die Filterung mit FilterHashtable erfolgt bereits beim Abruf und ist bei großen Protokollen effizienter als eine nachträgliche Filterung mit Where-Object. Eine Textsuche in der formatierten Nachricht erfordert jedoch häufig eine nachträgliche Auswertung.

8. Wie werden Windows-Ereignisse exportiert und archiviert?

Systemprotokoll als EVTX exportieren

[RO][PRIV][FILE][SENS] wevtutil epl System C:\Temp\System.evtx

Anwendungsprotokoll exportieren

[RO][PRIV][FILE][SENS] wevtutil epl Application C:\Temp\Application.evtx

Ereignisse mit PowerShell als CSV exportieren

[RO][FILE][SENS] $Start = (Get-Date).AddHours(-2)

Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    StartTime = $Start
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  MachineName,
                  Message |
    Export-Csv -Path 'C:\Temp\System-Events.csv' -NoTypeInformation -Encoding UTF8

Ereignisse als XML sichern

[RO][FILE][SENS] Get-WinEvent -LogName System -MaxEvents 100 |
    Export-Clixml -Path 'C:\Temp\System-Events.xml'

Verfügbare Protokolle mit wevtutil auflisten

[RO] wevtutil el

Letzte zehn Systemereignisse im Textformat anzeigen

[RO] wevtutil qe System /c:10 /rd:true /f:text
Option Bedeutung
qe Ereignisse abfragen
epl Protokoll exportieren
/c:10 maximal zehn Ereignisse
/rd:true neueste Ereignisse zuerst
/f:text Textausgabe
/f:xml XML-Ausgabe

Protokoll nicht während der Analyse löschen

Der folgende Befehl löscht ein Ereignisprotokoll und darf nicht als regulärer Diagnoseschritt verwendet werden:

[PRIV][CHANGE][DISRUPT] wevtutil cl System

Das Löschen vernichtet möglicherweise entscheidende Beweise und kann gegen betriebliche oder rechtliche Vorgaben verstoßen.

9. Wie werden Linux-Protokolle mit journalctl untersucht?

Bei systemd-basierten Linux-Systemen werden viele Ereignisse im systemd-Journal gespeichert und mit journalctl ausgewertet.

Gesamtes Journal anzeigen

[RO] journalctl

Neueste Einträge zuerst anzeigen

[RO] journalctl -r

Aktuellen Systemstart untersuchen

[RO] journalctl -b

Vorherigen Systemstart untersuchen

[RO] journalctl -b -1

Verfügbare Systemstarts anzeigen

[RO] journalctl --list-boots

Nur Kernelmeldungen anzeigen

[RO] journalctl -k

Kernelmeldungen des aktuellen Starts

[RO] journalctl -k -b

Protokoll eines Dienstes anzeigen

[RO] journalctl -u ssh.service

[RO] journalctl -u nginx.service

Protokoll eines Dienstes live verfolgen

[RO] journalctl -u nginx.service -f

Beenden mit:

Strg+C

Ereignisse seit einem Zeitpunkt

[RO] journalctl --since "2026-07-31 09:30:00"

Zeitfenster eingrenzen

[RO] journalctl \
  --since "2026-07-31 09:30:00" \
  --until "2026-07-31 10:00:00"

Relative Zeitangaben

[RO] journalctl --since "30 minutes ago"

[RO] journalctl --since today

Nach Priorität filtern

[RO] journalctl -p err

Fehler und schwerwiegendere Meldungen des aktuellen Starts:

[RO] journalctl -b -p err

Warnungen und schwerwiegendere Meldungen eines Dienstes:

[RO] journalctl -u nginx.service -p warning
Priorität Nummer
emerg 0
alert 1
crit 2
err 3
warning 4
notice 5
info 6
debug 7

Mit -p warning werden normalerweise warning und alle schwerwiegenderen Prioritäten angezeigt.

Nach Prozess-ID filtern

[RO] journalctl _PID=4321

Nach ausführbarer Datei filtern

[RO] journalctl _EXE=/usr/sbin/sshd

Nach Benutzer-ID filtern

[RO] journalctl _UID=1000

Ausgabe ohne Pager

[RO] journalctl -u nginx.service --no-pager

ISO-Zeitstempel verwenden

[RO] journalctl -u nginx.service -o short-iso

Ausführliche Felder eines Ereignisses anzeigen

[RO] journalctl -u nginx.service -n 10 -o verbose
10. Wie wird der Status eines Linux-Dienstes einschließlich Logs geprüft?

Dienststatus anzeigen

[RO] systemctl status nginx.service

Ohne interaktiven Pager:

[RO] systemctl status nginx.service --no-pager

Vollständige Zeilen ohne Kürzung:

[RO] systemctl status nginx.service --no-pager --full

Prüfen, ob der Dienst aktiv ist

[RO] systemctl is-active nginx.service

Prüfen, ob der Dienst aktiviert ist

[RO] systemctl is-enabled nginx.service

Fehlgeschlagene Units anzeigen

[RO] systemctl --failed

Journal des Dienstes seit dem aktuellen Start

[RO] journalctl -b -u nginx.service

Wichtige Unterscheidung

Befehl Aussage
systemctl is-active Läuft die Unit aktuell?
systemctl is-enabled Ist ein automatischer Start konfiguriert?
systemctl status Status, PID und letzte Logmeldungen
journalctl -u ausführlicher zeitlicher Verlauf der Unit

Ein Dienst kann aktiviert, aber aktuell nicht aktiv sein. Umgekehrt kann ein manuell gestarteter Dienst aktiv sein, obwohl er nicht für den automatischen Start aktiviert wurde.

11. Wie werden klassische Linux-Protokolldateien gelesen?

Abhängig von Distribution und Dienst befinden sich Textprotokolle häufig unter:

/var/log/

Typische Beispiele:

Pfad Möglicher Inhalt
/var/log/syslog allgemeine Systemmeldungen bei Debian/Ubuntu
/var/log/messages allgemeine Systemmeldungen bei RHEL-artigen Systemen
/var/log/auth.log Authentifizierungsereignisse bei Debian/Ubuntu
/var/log/secure Authentifizierungsereignisse bei RHEL-artigen Systemen
/var/log/kern.log Kernelmeldungen
/var/log/dmesg gespeicherte Boot- und Kernelmeldungen
/var/log/nginx/ Nginx-Zugriffs- und Fehlerprotokolle
/var/log/apache2/ Apache-Protokolle bei Debian/Ubuntu
/var/log/httpd/ Apache-Protokolle bei RHEL-artigen Systemen

Die tatsächlichen Pfade hängen von Distribution, Paket, Konfiguration und Protokollierungsdienst ab. Sie müssen deshalb auf dem konkreten System geprüft werden.

Datei mit less öffnen

[RO] less /var/log/syslog

Nützliche Tasten in less:

Taste Funktion
G zum Dateiende
g zum Dateianfang
/text vorwärts suchen
?text rückwärts suchen
n nächster Treffer
N vorheriger Treffer
q beenden

Letzte Zeilen anzeigen

[RO] tail -n 50 /var/log/syslog

Neue Zeilen live verfolgen

[RO] tail -f /var/log/syslog

Datei auch nach Rotation weiterverfolgen

[RO] tail -F /var/log/nginx/error.log

tail -F versucht im Gegensatz zu tail -f, die Datei nach einer Rotation oder Neuerstellung erneut zu öffnen.

Bestimmten Begriff suchen

[RO] grep -i "error" /var/log/syslog

Mehrere Begriffe suchen

[RO] grep -Ei "error|failed|timeout|denied" /var/log/syslog

Zeilennummern anzeigen

[RO] grep -Ein "error|failed|timeout|denied" /var/log/syslog

Treffer mit Kontext anzeigen

[RO] grep -Ein -B 3 -A 5 "timeout" /var/log/syslog
Option Bedeutung
-i Groß- und Kleinschreibung ignorieren
-E erweiterte reguläre Ausdrücke
-n Zeilennummer anzeigen
-B 3 drei Zeilen vor dem Treffer
-A 5 fünf Zeilen nach dem Treffer
-C 5 fünf Zeilen vor und nach dem Treffer
12. Wie werden rotierte und komprimierte Linux-Logs durchsucht?

Protokolle werden häufig rotiert, damit einzelne Dateien nicht unbegrenzt wachsen.

Beispiel:

auth.log
auth.log.1
auth.log.2.gz
auth.log.3.gz
Datei Bedeutung
auth.log aktuelles Protokoll
auth.log.1 vorherige unkomprimierte Generation
auth.log.2.gz ältere komprimierte Generation

Komprimiertes Protokoll anzeigen

[RO] zless /var/log/auth.log.2.gz

Komprimiertes Protokoll durchsuchen

[RO] zgrep -i "failed" /var/log/auth.log.2.gz

Mehrere rotierte Dateien durchsuchen

[RO] zgrep -Ei "failed|denied|timeout" /var/log/auth.log.*.gz

Aktuelle und ältere unkomprimierte Dateien durchsuchen:

[RO] grep -Ei "failed|denied|timeout" /var/log/auth.log /var/log/auth.log.1

Vor einer Analyse sollte geprüft werden, ob der Störungszeitpunkt bereits in einer rotierten Datei liegt.

13. Wie werden Kernel- und Hardwaremeldungen unter Linux geprüft?

Kernelmeldungen aus dem Journal

[RO] journalctl -k -b

Klassische dmesg-Ausgabe

[RO][PRIV] sudo dmesg

Menschenlesbare Zeitstempel:

[RO][PRIV] sudo dmesg --human

Nur Warnungen und Fehler anzeigen:

[RO][PRIV] sudo dmesg --level=warn,err,crit,alert,emerg

Nach typischen Hardware- und Netzwerkproblemen suchen:

[RO][PRIV] sudo dmesg --human |
    grep -Ei "error|failed|timeout|reset|link.*down|I/O"

Typische Hinweise:

Meldung Mögliche Untersuchungsrichtung
I/O error Datenträger, Kabel, Controller oder Dateisystem
link down Netzwerkkabel, Switchport, Treiber oder Interface
reset Gerät, Bus, Treiber oder Stromversorgung
out of memory Speicherdruck und OOM-Killer
segfault Programmfehler, Bibliothek oder Speicherproblem
read-only filesystem Dateisystemfehler oder Schutzreaktion
firmware failed to load fehlende oder inkompatible Firmware

Eine Meldung beschreibt zunächst nur eine Beobachtung. Beispielsweise kann ein link down durch das bewusste Abziehen eines Kabels entstanden sein.

14. Wie werden macOS-Protokolle mit der Konsole untersucht?

Die App Konsole zeigt unter anderem:

Öffnen über Spotlight:

Konsole

Oder über das Terminal:

[RO] open -a Console

Empfohlenes Vorgehen

  1. In der Seitenleiste den lokalen Mac auswählen.
  2. Live-Anzeige nur für einen kurzen Zeitraum aktivieren.
  3. Suchfeld nach Prozess, Subsystem, Kategorie oder Meldung filtern.
  4. Fehler einmal reproduzieren.
  5. Live-Anzeige wieder anhalten.
  6. Ereignisse unmittelbar vor und nach dem Fehler untersuchen.
  7. Detailbereich des Ereignisses öffnen.
  8. Prozess, Subsystem, Kategorie und Zeitstempel dokumentieren.

Abhängig von Benutzerrechten und Systemeinstellungen sind nicht alle Meldungen sichtbar. Für bestimmte Protokolle kann eine administrative Authentifizierung erforderlich sein.

15. Wie werden macOS-Protokolle mit log show ausgewertet?

macOS verwendet das Unified Logging System. Historische Ereignisse werden mit log show untersucht.

Letzte zehn Minuten anzeigen

[RO] log show --last 10m

Letzte Stunde anzeigen

[RO] log show --last 1h

Kompakte Darstellung

[RO] log show --last 10m --style compact

Nach Prozess filtern

[RO] log show \
  --last 30m \
  --style compact \
  --predicate 'process == "Safari"'

Nach Subsystem filtern

[RO] log show \
  --last 30m \
  --style compact \
  --predicate 'subsystem == "com.apple.network"'

Das konkrete Subsystem muss zuvor aus einem passenden Ereignis ermittelt werden. Es darf nicht allein anhand des Produktnamens angenommen werden.

Nach Text in der Ereignismeldung suchen

[RO] log show \
  --last 30m \
  --style compact \
  --predicate 'eventMessage CONTAINS[c] "error"'

Mehrere Bedingungen kombinieren

[RO] log show \
  --last 30m \
  --style compact \
  --predicate 'process == "Safari" AND eventMessage CONTAINS[c] "network"'

Informations- und Debugmeldungen einbeziehen

[RO] log show \
  --last 10m \
  --info \
  --debug \
  --style compact

Debugmeldungen können sehr umfangreich sein. Das Zeitfenster sollte deshalb möglichst klein gewählt werden.

Bestimmtes Zeitfenster untersuchen

[RO] log show \
  --start '2026-07-31 09:30:00' \
  --end '2026-07-31 09:45:00' \
  --style compact

Datumsformat, Zeitzone und unterstützte Optionen sollten auf der eingesetzten macOS-Version mit man log beziehungsweise log help show geprüft werden.

16. Wie werden macOS-Protokolle live verfolgt?

Live-Ausgabe starten

[RO] log stream

Kompakte Live-Ausgabe

[RO] log stream --style compact

Bestimmten Prozess verfolgen

[RO] log stream \
  --style compact \
  --predicate 'process == "Safari"'

Nach Meldungsinhalt filtern

[RO] log stream \
  --style compact \
  --predicate 'eventMessage CONTAINS[c] "timeout"'

Informationsmeldungen einbeziehen

[RO] log stream --info --style compact

Beenden mit:

Strg+C

Sicherer Ablauf

  1. Filter vorbereiten.
  2. Live-Aufzeichnung starten.
  3. Problem genau einmal reproduzieren.
  4. Aufzeichnung sofort beenden.
  5. Zeitstempel und relevante Ereignisse dokumentieren.

Eine ungefilterte Live-Ausgabe kann sehr schnell unübersichtlich werden.

17. Wie werden Docker-Containerlogs untersucht?

Docker schreibt standardmäßig die Standardausgabe und Standardfehlerausgabe eines Containers in den konfigurierten Logging-Treiber. Die tatsächlich verfügbaren Logs hängen deshalb von Container, Anwendung und Logging-Konfiguration ab.

Laufende Container anzeigen

[RO] docker ps

Auch beendete Container anzeigen:

[RO] docker ps -a

Logs eines Containers anzeigen

[RO][SENS] docker logs beispiel-container

Letzte 100 Zeilen anzeigen

[RO][SENS] docker logs --tail 100 beispiel-container

Zeitstempel einblenden

[RO][SENS] docker logs --timestamps --tail 100 beispiel-container

Logs live verfolgen

[RO][SENS] docker logs --follow --tail 100 beispiel-container

Logs seit einem relativen Zeitpunkt

[RO][SENS] docker logs --since 30m beispiel-container

Logs seit einem absoluten Zeitpunkt

[RO][SENS] docker logs \
  --since "2026-07-31T09:30:00+02:00" \
  beispiel-container

Zeitfenster begrenzen

[RO][SENS] docker logs \
  --since "2026-07-31T09:30:00+02:00" \
  --until "2026-07-31T09:45:00+02:00" \
  --timestamps \
  beispiel-container

Docker-Compose-Dienste anzeigen

[RO] docker compose ps

Logs eines Compose-Dienstes

[RO][SENS] docker compose logs --tail 100 beispiel-dienst

Compose-Logs live verfolgen

[RO][SENS] docker compose logs --follow --tail 100 beispiel-dienst

Wichtige Grenzen

18. Wie werden Webserver- und Reverse-Proxy-Logs interpretiert?

Webserver führen häufig mindestens zwei getrennte Protokolle:

Protokoll Inhalt
Access Log eingegangene HTTP-Anfragen und Antwortstatus
Error Log interne Fehler, Verbindungsprobleme und Konfigurationshinweise

Typischer Access-Log-Eintrag:

192.0.2.50 - - [31/Jul/2026:09:42:15 +0200] "GET /login HTTP/1.1" 502 157
Bestandteil Bedeutung
192.0.2.50 Client-IP-Adresse
Zeitstempel Zeitpunkt und Zeitzone
GET HTTP-Methode
/login angeforderter Pfad
HTTP/1.1 Protokollversion
502 HTTP-Statuscode
157 übertragene Antwortgröße, abhängig vom Logformat

Wichtige HTTP-Statusgruppen

Bereich Bedeutung
1xx Information
2xx erfolgreiche Verarbeitung
3xx Umleitung
4xx Anfrage konnte aus Clientsicht nicht verarbeitet werden
5xx serverseitige Verarbeitung fehlgeschlagen

Typische Statuscodes:

Status Bedeutung Untersuchungsrichtung
200 Anfrage erfolgreich Inhalt und Antwortzeit prüfen
301/302 Umleitung Ziel und Weiterleitungskette prüfen
400 ungültige Anfrage Header, Syntax und Proxy prüfen
401 Authentifizierung erforderlich oder fehlgeschlagen Anmeldedaten und Authentifizierungsdienst
403 Zugriff verweigert Berechtigungen und Regeln
404 Ressource nicht gefunden Pfad, Routing und Deployment
429 zu viele Anfragen Rate-Limit und Last
500 interner Serverfehler Anwendungslog prüfen
502 ungültige Antwort vom Backend Backend-Erreichbarkeit und Proxy
503 Dienst nicht verfügbar Dienststatus, Wartung und Kapazität
504 Zeitüberschreitung zum Backend Backend-Laufzeit, Netzwerk und Timeout

Ein 502 wird häufig am Reverse Proxy sichtbar, obwohl die eigentliche Ursache im Backenddienst liegt. Deshalb müssen Proxy- und Backend-Logs über Zeitstempel, Pfad und Korrelations-ID verbunden werden.

19. Wie werden Authentifizierungsfehler untersucht?

Bei Anmeldeproblemen können mehrere Systeme beteiligt sein:

Client
  → Anwendung
    → Reverse Proxy
      → Identitätsanbieter
        → Verzeichnisdienst
          → MFA-Dienst

Zu erfassende Informationen

Typische Ursachen

Beobachtung Mögliche Untersuchungsrichtung
Benutzer unbekannt falscher Mandant, falsche Domäne oder Synchronisation
Kennwort abgelehnt falsches Kennwort, Kontosperre oder abgelaufenes Kennwort
Token abgelaufen Zeitabweichung oder zu lange Sitzung
Zertifikat ungültig Ablaufdatum, Vertrauenskette oder Hostname
MFA fehlgeschlagen Endgerät, Push-Dienst oder Richtlinie
Zugriff verweigert Rolle, Gruppe oder Conditional-Access-Regel
LDAP nicht erreichbar DNS, Routing, Port, TLS oder Dienststatus
Wiederholte Fehlversuche gespeicherte alte Zugangsdaten oder automatischer Dienst

Authentifizierungsprotokolle enthalten besonders schützenswerte Informationen. Kennwörter, Tokens oder Cookies dürfen nicht in die Dokumentation kopiert werden.

20. Wie werden Meldungen verschiedener Systeme miteinander korreliert?

Beispiel einer verteilten Anfrage

09:42:15.120 Client sendet Anfrage
09:42:15.145 Reverse Proxy nimmt Anfrage an
09:42:15.151 Backend beginnt Verarbeitung
09:42:20.152 Backend meldet Datenbank-Timeout
09:42:20.153 Reverse Proxy erhält keine gültige Antwort
09:42:20.154 Client erhält HTTP 504

Der 504-Fehler auf dem Client ist hier eine Folge. Der erste technisch relevante Fehler ist der Datenbank-Timeout im Backend.

Geeignete Korrelationsmerkmale

Merkmal Nutzen
Zeitstempel grobe zeitliche Zuordnung
Request-ID eindeutige Anfrageverfolgung
Trace-ID verteilte Ablaufverfolgung
Session-ID Zuordnung zu einer Sitzung
Benutzer-ID Zuordnung zu einem Konto
Quell-IP Zuordnung zu einem Client
Zielpfad Zuordnung zu einer Funktion
Prozess-ID Zuordnung zu einem lokalen Prozess
Transaktions-ID Zuordnung zu einem Geschäftsvorgang

Korrelationsregel

Gleiche Uhrzeit allein ist kein Beweis für denselben Vorgang.

Je mehr Merkmale übereinstimmen, desto belastbarer ist die Zuordnung.

21. Wie wird nach Fehlercodes und Meldungen gesucht?

Vor der Internetrecherche sollten folgende Angaben vollständig erfasst werden:

Gute Suchanfrage

Microsoft-Windows-DNS-Client Event ID 1014 Windows 11

Ungenaue Suchanfrage

Internet geht nicht Fehler

Quellenreihenfolge

  1. offizielle Herstellerdokumentation,
  2. offizielle Knowledge Base oder Supportartikel,
  3. offizielle Quellcode-Repositories und Issue-Tracker,
  4. Dokumentation des eingesetzten Projekts,
  5. seriöse Fachquellen,
  6. Community-Beiträge als ergänzende Hinweise.

Ein Community-Beitrag kann eine nützliche Hypothese liefern, ersetzt aber keine Prüfung am eigenen System.

22. Welche typischen Fehler werden bei der Log-Analyse gemacht?
Fehler Folge Besseres Vorgehen
Nur nach dem Wort error suchen relevante Warnungen und Statusmeldungen fehlen Dienst, Zeitfenster und Ereigniskette prüfen
Nur das letzte Ereignis betrachten ursprüngliche Ursache wird übersehen zeitlich rückwärts zum ersten relevanten Fehler gehen
Zeitzonen ignorieren Ereignisse werden falsch zugeordnet Zeit und UTC-Offset dokumentieren
Gesamtes Log ungefiltert lesen relevante Ereignisse gehen in der Menge unter Zeitfenster und Quelle begrenzen
Logs vor Sicherung löschen Beweise gehen verloren zuerst exportieren und Integrität sichern
Debug-Logging dauerhaft aktivieren Speicherplatz- und Datenschutzprobleme kurzzeitig aktivieren und danach zurücksetzen
Fehlermeldung isoliert suchen falsche Produkt- oder Versionslösung Quelle, Version und Kontext ergänzen
Nur ein System prüfen verteilte Ursache bleibt verborgen alle beteiligten Systeme korrelieren
Fehlerhäufigkeit nicht beachten Einzelereignis wird überbewertet Häufigkeit und Vergleichswerte prüfen
Geheimnisse in Tickets kopieren Sicherheitsvorfall möglich Daten vor Weitergabe redigieren
Logdatei während der Analyse verändern Beweiskraft sinkt Original sichern und Arbeitskopie verwenden
Nur Fehlermeldungen berücksichtigen erfolgreicher Fallback wird übersehen gesamte Ereigniskette betrachten
23. Wie wird eine aussagekräftige Ereigniskette erstellt?

Eine gute Ereigniskette enthält nicht sämtliche Logzeilen, sondern die für den Vorgang relevanten Ereignisse.

Zeit System Quelle Ereignis Bedeutung
09:42:10.100 CLIENT-023 Anwendung Anfrage gestartet Benutzeraktion beginnt
09:42:10.130 PROXY-01 Nginx Anfrage angenommen Proxy ist erreichbar
09:42:10.150 APP-01 Backend DB-Abfrage gestartet Backend verarbeitet Anfrage
09:42:15.151 APP-01 Backend DB-Timeout erster belegter Fehler
09:42:15.152 PROXY-01 Nginx Upstream timeout Folgefehler
09:42:15.160 CLIENT-023 Anwendung HTTP 504 sichtbare Auswirkung

Auswertung

Symptom:
Client erhält HTTP 504.

Erster belegter Fehler:
Datenbank-Timeout auf APP-01.

Folgefehler:
Reverse Proxy erhält keine rechtzeitige Backend-Antwort.

Nächster Prüfschritt:
Datenbankerreichbarkeit, Datenbanklast und Abfragedauer im Zeitraum
09:42:10 bis 09:42:15 untersuchen.
24. Kompakte Befehlsübersicht für Windows, Linux und macOS
Aufgabe Windows Linux macOS
Grafische Loganzeige öffnen [RO] eventvwr.msc abhängig von Desktop und Distribution [RO] open -a Console
Neueste Systemereignisse [RO] Get-WinEvent -LogName System -MaxEvents 20 [RO] journalctl -n 20 [RO] log show --last 10m --style compact
Aktuellen Start untersuchen Ereignis-IDs und Startzeit filtern [RO] journalctl -b [RO] log show --last boot --style compact
Vorherigen Start untersuchen Systemprotokoll nach vorherigem Startzeitraum filtern [RO] journalctl -b -1 über Zeitfenster beziehungsweise Logarchiv
Kernelmeldungen Systemprotokoll und providerspezifische Logs [RO] journalctl -k -b [RO] log show --last 1h --predicate 'process == "kernel"'
Letzte Stunde Get-WinEvent mit StartTime=(Get-Date).AddHours(-1) [RO] journalctl --since "1 hour ago" [RO] log show --last 1h
Dienstprotokoll nach Provider oder Dienstprotokoll filtern [RO] journalctl -u nginx.service nach process oder subsystem filtern
Live-Anzeige Ereignisanzeige oder providerspezifisch [RO] journalctl -f [RO] log stream --style compact
Fehler filtern Get-WinEvent mit Level=1,2 [RO] journalctl -p err Predicate nach Prozess, Typ oder Meldung
Textdatei lesen [RO] Get-Content .\app.log [RO] less /var/log/app.log [RO] less /Pfad/app.log
Letzte 50 Zeilen [RO] Get-Content .\app.log -Tail 50 [RO] tail -n 50 /var/log/app.log [RO] tail -n 50 /Pfad/app.log
Datei live verfolgen [RO] Get-Content .\app.log -Wait -Tail 50 [RO] tail -F /var/log/app.log [RO] tail -F /Pfad/app.log
Text suchen [RO] Select-String -Path .\app.log -Pattern 'error' [RO] grep -i 'error' /var/log/app.log [RO] grep -i 'error' /Pfad/app.log
Komprimiertes Log lesen abhängig vom Archivformat [RO] zless /var/log/app.log.2.gz [RO] gzcat /Pfad/app.log.gz | less
Ereignisse exportieren [FILE][SENS] wevtutil epl System C:\Temp\System.evtx [FILE][SENS] journalctl --since today > journal.txt [FILE][SENS] log show --last 1h > macos-log.txt
Containerlogs [RO][SENS] docker logs --tail 100 NAME [RO][SENS] docker logs --tail 100 NAME [RO][SENS] docker logs --tail 100 NAME

log show --last boot kann je nach eingesetzter macOS-Version beziehungsweise Werkzeugsyntax nicht verfügbar sein. Die lokal unterstützten Optionen sind mit log help show zu prüfen. Ein festes Zeitfenster mit --start und --end ist die eindeutigere Alternative.

25. Dokumentationsvorlage für eine Log-Analyse 
Ticketnummer:
Analysedatum:
Betroffenes System:
Betriebssystem:
Anwendung oder Dienst:
Anwendungsversion:
Betroffener Benutzer:
Fehlerbeschreibung:
Fehlerzeitpunkt:
Zeitzone:
Letzter funktionierender Zeitpunkt:
Reproduzierbar: Ja / Nein

Untersuchte Protokolle:
- 
- 
- 

Verwendete Filter:
- Zeitraum:
- Quelle/Provider:
- Ereignis-ID:
- Prozess/PID:
- Dienst/Unit:
- Benutzer/UID:
- Korrelations-ID:
- Suchbegriffe:

Erster relevanter Fehler:
Zeitpunkt:
System:
Quelle:
Ereignis-ID oder Fehlercode:
Vollständige Meldung:

Vorhergehende Ereignisse:
- 
- 
- 

Nachfolgende Ereignisse:
- 
- 
- 

Ereigniskette:
1.
2.
3.
4.

Arbeitshypothese:
Begründung:
Kontrollierter Test:
Testergebnis:

Ermittelte Ursache:
Durchgeführte Änderung:
Rückweg:
Abschlussprüfung:

Gesicherte Dateien:
- EVTX:
- Journal:
- Textlog:
- CSV:
- Diagnosearchiv:

Original unverändert gesichert: Ja / Nein
Sensible Daten redigiert: Ja / Nein
Speicherort:
Zugriffsberechtigung:
Aufbewahrungs- oder Löschfrist:
26. Offizielle Quellen und weiterführende Dokumentation

Microsoft

Linux und systemd

Apple

Docker

Befehlsoptionen, Protokollpfade und verfügbare Felder können von Betriebssystem-, Distributions- und Anwendungsversion abhängen. Vor dem produktiven Einsatz ist deshalb zusätzlich die lokale Hilfeseite des konkreten Systems zu prüfen.

2. Grundwerkzeuge und Befehle

2.13 Monitoringdaten und Leistungswerte richtig interpretieren

Monitoring erfasst den Zustand von Systemen und Diensten über einen längeren Zeitraum. Im Gegensatz zu einer einzelnen Momentaufnahme zeigt es Entwicklungen, wiederkehrende Muster und Zusammenhänge zwischen verschiedenen Messwerten.

Monitoringdaten helfen unter anderem bei folgenden Fragen:

Grundregel: Ein einzelner hoher Messwert beweist noch keine Ursache. Entscheidend sind Verlauf, Dauer, Vergleichswerte, Benutzerwirkung und die Korrelation mit anderen Signalen.

1. Kennzeichnungen und Sicherheitsregeln
Kennzeichnung Bedeutung
[RO] Liest Informationen aus, ohne den Zustand absichtlich zu verändern
[TEST] Führt eine aktive Messung durch oder erzeugt zusätzliche Last
[PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte
[FILE] Erzeugt oder verändert eine Datei
[SENS] Ausgabe kann vertrauliche Daten enthalten
[CHANGE] Verändert Einstellungen oder den Systemzustand
[DISRUPT] Kann Dienste oder Systeme beeinträchtigen

Monitoringdaten können vertrauliche Informationen enthalten:

Dashboards, Exporte und Screenshots dürfen deshalb nur kontrolliert weitergegeben werden.

2. Was ist der Unterschied zwischen Monitoring und Observability?
Begriff Bedeutung
Monitoring Erfasst vorher festgelegte Zustände und Messwerte
Logging Dokumentiert einzelne Ereignisse und Meldungen
Metriken Numerische Werte über einen Zeitraum
Tracing Verfolgt eine Anfrage durch mehrere Komponenten
Observability Ermöglicht, den internen Systemzustand aus Metriken, Logs und Traces abzuleiten
Alerting Meldet definierte Zustände oder Abweichungen
Dashboard Visualisiert ausgewählte Messwerte
Profiling Untersucht, wo ein Programm Rechenzeit oder Speicher verwendet

Zusammenhang

Metrik zeigt:
Die Antwortzeit ist seit 09:42 Uhr erhöht.

Log zeigt:
Datenbankabfragen laufen in ein Timeout.

Trace zeigt:
Die Verzögerung entsteht im Datenbankzugriff.

Profiling zeigt:
Eine bestimmte Funktion erzeugt besonders teure Abfragen.

Monitoring zeigt häufig, dass ein Problem besteht. Logs, Traces und weitere Diagnosewerkzeuge helfen anschließend festzustellen, warum es besteht.

3. Wie wird eine Baseline erstellt?

Eine Baseline beschreibt den normalen Zustand eines Systems unter vergleichbaren Bedingungen.

Sinnvolle Vergleichszeiträume sind beispielsweise:

Beispiel

Messwert Normalbetrieb Störungszeitraum
CPU-Auslastung 25–45 % 85–100 %
Antwortzeit p95 180–260 ms 3.800 ms
Fehlerrate 0,2 % 12 %
Datenbankverbindungen 20–35 100
Datenträgerlatenz 2–8 ms 140 ms
Anfragen pro Sekunde 100–140 110

Da die Anfragemenge nahezu unverändert ist, die Antwortzeit, Fehlerrate und Datenträgerlatenz aber stark gestiegen sind, sollte die Untersuchung auf Datenträger und Datenbank konzentriert werden.

Eine sinnvolle Baseline berücksichtigt:

Ein Grenzwert ohne Baseline ist häufig willkürlich.

4. Welche Arten von Metriken gibt es?
Metriktyp Verhalten Beispiel
Counter steigt normalerweise an und kann bei Neustart zurückgesetzt werden Gesamtzahl der HTTP-Anfragen
Gauge kann steigen und fallen aktuelle Speichernutzung
Histogram zählt Beobachtungen in Wertebereichen Verteilung von Antwortzeiten
Summary berechnet Beobachtungen und Quantile clientseitig Antwortzeitquantile
Rate Änderung eines Counters pro Zeiteinheit Fehler pro Sekunde
Ratio Verhältnis zweier Werte Fehleranteil an allen Anfragen

Counter

requests_total = 150000

Der Gesamtwert ist für eine aktuelle Belastung meist weniger aussagekräftig als seine Änderungsrate.

PromQL-Beispiel:

rate(http_requests_total[5m])

Gauge

active_connections = 42

Der Wert beschreibt den aktuellen Zustand und kann steigen oder fallen.

PromQL-Beispiele:

avg_over_time(active_connections[15m])

max_over_time(active_connections[15m])

Fehlerrate berechnen

sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Für eine Prozentdarstellung:

100 *
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

rate() ist für Counter vorgesehen. Auf einen Gauge angewendet würde die Abfrage inhaltlich meist keinen sinnvollen Messwert ergeben.

5. Welche Messstrategien eignen sich für Infrastruktur und Dienste?

USE-Methode für Ressourcen

Buchstabe Bedeutung Fragestellung
U Utilization Wie stark wird die Ressource verwendet?
S Saturation Gibt es Warteschlangen oder Rückstau?
E Errors Treten Fehler auf?

Beispiel für einen Datenträger:

USE-Bereich Messwert
Utilization aktive Zeit des Datenträgers
Saturation Warteschlangenlänge
Errors I/O-Fehler und Timeouts

RED-Methode für Dienste

Buchstabe Bedeutung Fragestellung
R Rate Wie viele Anfragen werden verarbeitet?
E Errors Wie viele Anfragen schlagen fehl?
D Duration Wie lange dauert die Verarbeitung?

Golden Signals

Signal Bedeutung
Latency Dauer einer Anfrage
Traffic aktuelle Nutzung oder Anfragemenge
Errors fehlgeschlagene Operationen
Saturation Annäherung an eine Kapazitätsgrenze

USE hilft besonders bei der Untersuchung technischer Ressourcen. RED und die Golden Signals zeigen stärker die tatsächliche Benutzerwirkung.

6. Wie werden Durchschnitt, Maximum und Perzentile interpretiert?

Beispiel für zehn Antwortzeiten

100, 110, 115, 120, 125, 130, 140, 150, 200, 5000 ms

Der Durchschnitt wird durch den einzelnen sehr langsamen Wert deutlich beeinflusst. Gleichzeitig kann ein Durchschnitt die Verteilung und einzelne besonders langsame Anfragen verbergen.

Kennzahl Aussage
Minimum kleinster gemessener Wert
Maximum größter gemessener Wert
Durchschnitt arithmetischer Mittelwert
Median beziehungsweise p50 50 % der Werte liegen höchstens hier
p90 90 % der Werte liegen höchstens hier
p95 95 % der Werte liegen höchstens hier
p99 99 % der Werte liegen höchstens hier

Beispiel

p50 = 120 ms
p95 = 800 ms
p99 = 4.500 ms

Interpretation:

Wichtig:

7. Wie wird CPU-Auslastung richtig interpretiert?

Hohe CPU-Auslastung bedeutet zunächst nur, dass Rechenzeit verwendet wird. Sie kann sowohl normal als auch problematisch sein.

Zu prüfende Fragen

Typische CPU-Zustände unter Linux

Zustand Bedeutung
us Zeit für Benutzerprozesse
sy Zeit im Kernel
id Leerlauf
wa Warten auf I/O
st Zeit, die einer VM durch den Hypervisor entzogen wurde
hi Hardware-Interrupts
si Software-Interrupts

Beispiele

Beobachtung Untersuchungsrichtung
hohes us Anwendungsprozess, Berechnung oder Schleife
hohes sy Kernel, Treiber, Systemaufrufe oder Netzwerk
hohes wa Datenträger oder anderes blockierendes I/O
hohes st in VM Überbelegung oder Belastung des Hypervisors
hohe Interruptlast Netzwerkadapter, Treiber oder Hardware
ein Kern bei 100 % möglicherweise einzelner nicht parallelisierter Thread

Windows

[RO] Get-Counter '\Processor(_Total)\% Processor Time'

Alle logischen Prozessoren:

[RO] Get-Counter '\Processor(*)\% Processor Time'

Prozessbezogene CPU-Werte:

[RO] Get-Counter '\Process(*)\% Processor Time'

Mehrere Messungen im Abstand von zwei Sekunden:

[RO] Get-Counter '\Processor(_Total)\% Processor Time' `
    -SampleInterval 2 `
    -MaxSamples 10

Linux

[RO] uptime

[RO] top

[RO] vmstat 1 10

Falls sysstat installiert ist:

[RO] mpstat -P ALL 1 10

Prozesse nach CPU-Auslastung sortieren:

[RO] ps -eo pid,ppid,user,%cpu,%mem,comm --sort=-%cpu | head

macOS

[RO] top -l 1 -o cpu

[RO] ps -Ao pid,ppid,user,%cpu,%mem,comm -r | head

Eine kurzzeitige CPU-Auslastung von 100 % ist nicht automatisch ein Problem. Kritisch wird sie insbesondere dann, wenn sie länger anhält, Warteschlangen erzeugt und gleichzeitig die Antwortzeit oder Fehlerrate steigt.

8. Was bedeutet Load Average unter Linux und macOS?

Load Average wird typischerweise für die letzten 1, 5 und 15 Minuten angezeigt:

[RO] uptime

Beispiel:

load average: 8.20, 6.10, 3.40

Die Werte sind keine Prozentwerte.

Unter Linux umfasst die Last unter anderem ausführbare beziehungsweise auf CPU wartende Tasks und Tasks in nicht unterbrechbarem Wartezustand, beispielsweise bei bestimmten I/O-Vorgängen.

Logische CPUs bestimmen

Linux:

[RO] nproc

macOS:

[RO] sysctl -n hw.logicalcpu

Vereinfachtes Beispiel

8 logische CPUs
Load Average 1 Minute: 8

Das kann bedeuten, dass die ausführbaren Kapazitäten ungefähr vollständig beansprucht sind. Die genaue Bewertung erfordert jedoch zusätzliche Informationen.

8 logische CPUs
Load Average 1 Minute: 16

Das deutet auf mehr gleichzeitig wartende oder nicht unterbrechbar blockierte Tasks hin, als unmittelbar abgearbeitet werden können.

Wichtige Einschränkungen

9. Wie wird Arbeitsspeicher richtig interpretiert?

Ein fast vollständig belegter physischer Arbeitsspeicher bedeutet nicht automatisch Speichermangel. Betriebssysteme verwenden freien Speicher unter anderem als Cache.

Wichtiger als der reine Wert „belegt“ sind:

Begriffe

Begriff Bedeutung
Physical Memory tatsächlich vorhandener RAM
Available kurzfristig für Anwendungen verfügbarer Speicher
Cache für schnellere Zugriffe verwendeter Speicher
Working Set aktuell im RAM befindliche Seiten eines Prozesses
Private Bytes nur einem Prozess zugeordneter zugesicherter Speicher
Commit zugesicherter virtueller Speicher
Pagefile beziehungsweise Swap Auslagerungsspeicher
Page Fault Zugriff auf nicht aktuell passend zugeordnete Speicherseite
Hard Page Fault benötigte Seite muss aus Datei oder Auslagerung geladen werden

Viele Page Faults sind normal. Erst eine anhaltend hohe Rate teurer Datenträgerzugriffe zusammen mit Speicherdruck und schlechter Leistung ist ein deutlicher Problemhinweis.

Windows

[RO] Get-Counter '\Memory\Available MBytes'

[RO] Get-Counter '\Memory\% Committed Bytes In Use'

[RO] Get-Counter '\Memory\Pages/sec'

Prozesse nach Arbeitsspeichernutzung:

[RO] Get-Process |
    Sort-Object WorkingSet64 -Descending |
    Select-Object -First 10 Name,
        Id,
        @{Name='WorkingSetMiB';Expression={
            [math]::Round($_.WorkingSet64 / 1MB, 1)
        }}

Linux

[RO] free -h

[RO] vmstat 1 10

Prozesse nach Speicheranteil:

[RO] ps -eo pid,user,%mem,rss,vsz,comm --sort=-%mem | head

OOM-Ereignisse suchen:

[RO][PRIV] sudo journalctl -k |
    grep -Ei 'out of memory|oom-killer|killed process'

macOS

[RO] memory_pressure

[RO] vm_stat

[RO] top -l 1 -o mem

Hinweise auf ein mögliches Speicherproblem

10. Wie werden Datenträgerauslastung und I/O-Latenz interpretiert?

Zu einer Datenträgeranalyse gehören mindestens:

Messwert Aussage
IOPS Anzahl der Operationen pro Sekunde
Throughput übertragene Datenmenge pro Sekunde
Latency Dauer einer Operation
Queue Length wartende oder laufende I/O-Anfragen
Utilization Anteil der aktiven Messzeit
Free Space verfügbarer Speicherplatz
Errors fehlerhafte oder abgebrochene Operationen

Hohe IOPS sind nicht automatisch problematisch. Ein Speichersystem kann viele kleine Operationen oder wenige große Übertragungen verarbeiten. Entscheidend ist, ob Latenz und Warteschlange unter der aktuellen Last steigen.

Windows

[RO] Get-Counter '\PhysicalDisk(*)\% Disk Time'

[RO] Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Read'

[RO] Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Write'

[RO] Get-Counter '\PhysicalDisk(*)\Current Disk Queue Length'

[RO] Get-Counter '\PhysicalDisk(*)\Disk Reads/sec'

[RO] Get-Counter '\PhysicalDisk(*)\Disk Writes/sec'

Freien Speicherplatz prüfen:

[RO] Get-Volume |
    Select-Object DriveLetter,
                  FileSystemLabel,
                  FileSystem,
                  HealthStatus,
                  SizeRemaining,
                  Size

Windows Performance Counter für Avg. Disk sec/Read und Avg. Disk sec/Write werden in Sekunden ausgegeben. 0,020 entspricht 20 Millisekunden.

Linux

[RO] df -hT

[RO] df -i

Falls sysstat installiert ist:

[RO] iostat -xz 1 10

Prozessbezogene I/O-Werte:

[RO] pidstat -d 1 10

Kernelmeldungen zu I/O-Fehlern:

[RO][PRIV] sudo journalctl -k |
    grep -Ei 'I/O error|timeout|reset|read-only|filesystem'

macOS

[RO] df -h

[RO] iostat -w 1 -c 10

Typische Fehlinterpretationen

Beobachtung Fehlinterpretation
Datenträger zu 100 % aktiv maximale Datenübertragungsrate erreicht
wenig Durchsatz Datenträger ist nicht belastet
hoher Durchsatz Datenträger ist überlastet
voller Speicherplatz einzige mögliche Ursache ist Datenmenge
hohe Latenz physischer Datenträger ist zwingend defekt

Ein Datenträger kann bei kleinen zufälligen Zugriffen vollständig beschäftigt sein, obwohl der Datendurchsatz gering bleibt.

11. Wie werden Netzwerkmesswerte interpretiert?

Wichtige Netzwerkmesswerte:

Messwert Bedeutung
Bandbreite theoretische oder konfigurierte Übertragungskapazität
Throughput tatsächlich übertragene Datenmenge
Utilization genutzter Anteil der Kapazität
Packets per Second Pakete pro Sekunde
Errors fehlerhafte Frames oder Pakete
Discards/Drops verworfene Pakete
Retransmissions erneut übertragene TCP-Segmente
Latency Laufzeit einer Übertragung
Jitter Schwankung der Laufzeit
Packet Loss Anteil verlorener Pakete
Connections Anzahl aktiver Verbindungen

Windows

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

Adapterstatistiken:

[RO] Get-NetAdapterStatistics

Performance Counter:

[RO] Get-Counter '\Network Interface(*)\Bytes Total/sec'

[RO] Get-Counter '\TCPv4\Segments Retransmitted/sec'

Linux

[RO] ip -s link

[RO] ss -s

[RO] cat /proc/net/dev

TCP-Statistik:

[RO] nstat

Treiber- und Adapterstatistiken:

[RO][PRIV] sudo ethtool -S eth0

macOS

[RO] netstat -ib

[RO] netstat -s

[RO] ifconfig

Zusammenhänge

Beobachtung Mögliche Untersuchungsrichtung
steigende RX-Errors Kabel, Transceiver, Port, Duplex oder Hardware
steigende Drops ohne Linkfehler Puffer, CPU, Treiber oder Überlastung
viele TCP-Retransmissions Paketverlust, Überlastung oder instabile Verbindung
hohe Latenz ohne Paketverlust Warteschlangen, Routing oder überlasteter Dienst
Bandbreite dauerhaft nahe Kapazität Kapazitätsengpass möglich
geringe Bandbreitennutzung und hohe Antwortzeit Problem möglicherweise in Anwendung oder Zielsystem
nur ein Client betroffen lokales Interface, WLAN, Treiber oder Clientkonfiguration
alle Clients betroffen gemeinsamer Pfad, Dienst oder Upstream

Zähler sollten mindestens zweimal gemessen werden. Ein seit dem Systemstart aufgelaufener Fehlerzähler ist ohne zeitliche Änderung nur begrenzt aussagekräftig.

12. Wie werden Latenz, Jitter und Paketverlust gemessen?

Erreichbarkeit und Round-Trip-Time

Aufgabe Windows Linux macOS
vier ICMP-Anfragen [TEST] ping ziel.example [TEST] ping -c 4 ziel.example [TEST] ping -c 4 ziel.example
fortlaufender Ping [TEST] ping -t ziel.example [TEST] ping ziel.example [TEST] ping ziel.example
Route prüfen [TEST] tracert ziel.example [TEST] traceroute ziel.example [TEST] traceroute ziel.example
kombinierte Pfadanalyse [TEST] pathping ziel.example [TEST] mtr ziel.example [TEST] mtr ziel.example

Nicht jedes System beantwortet ICMP-Anfragen. Ein fehlgeschlagener Ping beweist daher nicht, dass der eigentliche Dienst nicht erreichbar ist.

Anwendungsnahe HTTPS-Messung

Windows, Linux und macOS:

[TEST] curl -o /dev/null -sS \
  -w 'DNS: %{time_namelookup}\nTCP: %{time_connect}\nTLS: %{time_appconnect}\nTTFB: %{time_starttransfer}\nGesamt: %{time_total}\n' \
  https://example.com/
curl-Wert Bedeutung
time_namelookup Dauer bis zum Abschluss der Namensauflösung
time_connect Dauer bis zur TCP-Verbindung
time_appconnect Dauer bis zum Abschluss von TLS
time_starttransfer Zeit bis zum ersten Antwortbyte
time_total Gesamtdauer

Interpretationsbeispiel

DNS:    0,010 s
TCP:    0,030 s
TLS:    0,080 s
TTFB:   3,500 s
Gesamt: 3,510 s

DNS, TCP und TLS sind schnell. Die lange Zeit bis zum ersten Byte weist eher auf Verarbeitung im Server oder Backend hin.

13. Was bedeutet Sättigung und wie wird sie erkannt?

Auslastung und Sättigung sind nicht dasselbe.

Auslastung:
Wie stark wird eine Ressource verwendet?

Sättigung:
Wie viel Arbeit muss warten, weil die Ressource nicht sofort verfügbar ist?

Beispiele

Ressource Auslastung Sättigung
CPU CPU-Zeit in Prozent ausführbare Warteschlange
RAM belegter Speicher Speicherdruck und Paging
Datenträger aktive Zeit I/O-Warteschlange
Netzwerk übertragene Bitrate Drops und Warteschlangen
Datenbank aktive Verbindungen wartende Abfragen
Threadpool aktive Threads wartende Tasks
Connection Pool belegte Verbindungen wartende oder abgewiesene Anfragen

Ein System kann noch unter 100 % Auslastung liegen und trotzdem bereits Verzögerungen aufweisen.

Linux Pressure Stall Information

Wenn vom Kernel unterstützt:

[RO] cat /proc/pressure/cpu

[RO] cat /proc/pressure/memory

[RO] cat /proc/pressure/io

Beispiel:

some avg10=4.20 avg60=2.10 avg300=0.80 total=1234567
full avg10=1.00 avg60=0.40 avg300=0.10 total=234567
Feld Bedeutung
some mindestens einige Tasks waren durch die Ressource blockiert
full alle nicht untätigen Tasks waren gleichzeitig blockiert
avg10 durchschnittlicher Zeitanteil der letzten 10 Sekunden
avg60 durchschnittlicher Zeitanteil der letzten 60 Sekunden
avg300 durchschnittlicher Zeitanteil der letzten 300 Sekunden
total gesamte Stall-Zeit in Mikrosekunden seit dem Start

PSI misst den Zeitverlust durch Ressourcenknappheit und ergänzt reine Auslastungswerte.

14. Wie werden virtuelle Maschinen und Container richtig bewertet?

Bei virtuellen Systemen existieren mehrere Messebenen:

Physischer Host
  → Hypervisor
    → virtuelle Maschine
      → Container
        → Anwendung

Ein Wert innerhalb eines Containers zeigt nicht zwingend die vollständige Situation des Hosts.

Zu prüfen

Docker-Ressourcen anzeigen

[RO] docker stats --no-stream

Nur ausgewählte Spalten:

[RO] docker stats --no-stream \
  --format 'table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.NetIO}}\t{{.BlockIO}}\t{{.PIDs}}'

Containerstatus prüfen:

[RO] docker ps -a

Konfigurierte Limits eines Containers untersuchen:

[RO][SENS] docker inspect beispiel-container

OOM-Status prüfen:

[RO] docker inspect \
  --format '{{.Name}} OOMKilled={{.State.OOMKilled}} ExitCode={{.State.ExitCode}}' \
  beispiel-container

Wichtige Grenzen

15. Wie werden fehlende oder veraltete Messwerte erkannt?

Keine Daten bedeuten nicht automatisch, dass alles in Ordnung ist.

Mögliche Ursachen:

Prometheus-Verfügbarkeit eines Targets

up

Nur nicht erfolgreich abgefragte Targets:

up == 0

Fehlende Zeitreihe erkennen:

absent(up{job="beispiel"})

Metriken ohne aktuelle Stichprobe können veraltet sein. Deshalb müssen folgende Zeitpunkte unterschieden werden:

Prüfreihenfolge

  1. Zeitbereich des Dashboards prüfen.
  2. Zeitpunkt des letzten Datenpunkts prüfen.
  3. Target- oder Agentstatus kontrollieren.
  4. Datenquelle direkt abfragen.
  5. Netzwerkverbindung zwischen Monitoring und Ziel prüfen.
  6. Konfigurationsänderungen kontrollieren.
  7. Monitoringfehler getrennt vom überwachten Dienst bewerten.
16. Wie werden sinnvolle Schwellenwerte festgelegt?

Ein sinnvoller Schwellenwert basiert auf:

Ungeeignete Regel

CPU > 80 % → sofort kritischer Alarm

Bessere Regelidee

CPU-Auslastung über 90 % für mindestens 15 Minuten
UND
Antwortzeit p95 über dem vereinbarten Zielwert

Beispiel für mehrstufige Grenzwerte

Zustand Bedingung Reaktion
Information ungewöhnlicher Trend ohne Auswirkung Dashboard beobachten
Warnung Grenzwert länger überschritten während Betriebszeit untersuchen
Kritisch Benutzerwirkung oder unmittelbarer Ausfall sofortige Bearbeitung
Kapazitätswarnung prognostizierte Erschöpfung in 14 Tagen Kapazität planen

Hysterese

Unterschiedliche Ein- und Ausschaltschwellen verhindern, dass ein Alarm ständig wechselt.

Alarm aktivieren: Wert über 90 %
Alarm beenden: Wert unter 80 %

Pending Period

Eine Bedingung muss für eine festgelegte Dauer bestehen, bevor der Alarm ausgelöst wird.

CPU > 90 % für 10 Minuten

Dadurch führen kurze Lastspitzen nicht sofort zu einem Alarm.

17. Was sind Flapping und Alert Fatigue?

Flapping

Ein Alarm wechselt häufig zwischen aktiv und normal:

09:00 Alarm
09:01 behoben
09:02 Alarm
09:03 behoben

Mögliche Gegenmaßnahmen:

Alert Fatigue

Zu viele oder nicht relevante Meldungen führen dazu, dass wichtige Alarme übersehen werden.

Typische Ursachen:

Ein guter Alarm beantwortet:

  1. Was ist betroffen?
  2. Welche Benutzerwirkung besteht?
  3. Seit wann besteht das Problem?
  4. Welcher Messwert löste den Alarm aus?
  5. Wie lange besteht die Bedingung?
  6. Wer ist zuständig?
  7. Welches Dashboard und Runbook gehören dazu?
  8. Welche ersten Prüfungen sind erforderlich?

Wenn aus einer Meldung keine sinnvolle Handlung folgt, eignet sie sich möglicherweise besser für ein Dashboard als für eine Alarmierung.

18. Wie werden Dashboards bei einer Störung gelesen?

Empfohlene Reihenfolge

  1. Zeitfenster auf den Störungszeitraum einstellen.
  2. Zeitzone des Dashboards prüfen.
  3. Zeitpunkt einer gemeldeten Störung markieren.
  4. Benutzerorientierte Signale prüfen:
    • Verfügbarkeit,
    • Antwortzeit,
    • Fehlerrate,
    • Anfragemenge.
  5. Technische Ressourcen prüfen:
    • CPU,
    • RAM,
    • Datenträger,
    • Netzwerk.
  6. Deployments, Updates und Wartungsereignisse einblenden.
  7. Betroffene Instanzen mit funktionierenden Instanzen vergleichen.
  8. Zeitfenster vor und nach dem Ereignis betrachten.
  9. Rohdaten oder detailliertere Ansicht öffnen.
  10. Hypothese anhand von Logs oder Traces prüfen.

Zoomfehler vermeiden

Ein Wert kann je nach gewähltem Zeitraum unterschiedlich wirken:

24-Stunden-Ansicht:
kurzer, kaum sichtbarer Ausschlag

5-Minuten-Ansicht:
deutliche Lastspitze von drei Minuten

Umgekehrt kann ein extrem kurzes Zeitfenster einen normalen Ausschlag dramatischer erscheinen lassen, als er im Betriebszusammenhang ist.

Zu prüfen

19. Wie werden typische Messwertkombinationen interpretiert?
Beobachtung Mögliche Richtung Nächster Prüfschritt
CPU hoch, Antwortzeit normal erwartete Verarbeitung Kapazitätsreserve und Dauer prüfen
CPU hoch, Antwortzeit hoch CPU-Engpass möglich Prozess, Threads und Run Queue prüfen
CPU niedrig, Load hoch I/O-Wartezustände möglich vmstat, iostat und PSI prüfen
RAM belegt, Available ausreichend möglicherweise normaler Cache Paging und Speicherdruck prüfen
RAM knapp, Swap steigt Speicherdruck Prozesse und Wachstum untersuchen
Datenträger aktiv, Latenz niedrig hohe, aber verarbeitbare Last Warteschlange und Trend prüfen
Datenträger aktiv, Latenz hoch I/O-Engpass möglich Prozess-I/O und Storage prüfen
Netzwerkdurchsatz hoch, keine Fehler möglicherweise normale Übertragung Kapazität und Anwendungskontext
Retransmissions steigen Paketverlust möglich Interfacefehler und Pfad prüfen
Antwortzeit hoch, Ressourcen normal externe Abhängigkeit möglich Traces, DNS und Backenddienste
Fehlerquote hoch, Traffic normal Funktions- oder Backendfehler Logs und Deployments prüfen
Traffic steigt, Fehler und Latenz steigen Kapazitätsgrenze möglich Sättigung und Skalierung prüfen
Messwerte verschwinden Monitoring- oder Zielausfall Target, Agent und Datenquelle prüfen
nur eine Instanz auffällig lokales Problem Konfiguration und Host vergleichen
alle Instanzen gleichzeitig auffällig gemeinsame Abhängigkeit Datenbank, Netzwerk und Deployment

Diese Kombinationen sind Ausgangspunkte für Hypothesen und keine automatischen Ursachenfeststellungen.

20. Praxisfall – Anwendung ist zu bestimmten Zeiten langsam

Ausgangslage

Benutzer melden täglich zwischen 02:00 und 02:30 Uhr lange Antwortzeiten.

Vorgehen

  1. Benutzerwirkung mit p95- oder p99-Antwortzeit bestätigen.
  2. Anfragerate und Fehlerrate im selben Zeitraum prüfen.
  3. CPU-, RAM-, Datenträger- und Netzwerkverlauf vergleichen.
  4. Geplante Aufgaben und Backups prüfen.
  5. Datenbankverbindungen und Abfragedauer kontrollieren.
  6. Logs nach Timeouts und Warteschlangen durchsuchen.
  7. Mit einem störungsfreien Zeitraum vergleichen.
  8. Abhängigkeiten und Storage überprüfen.
  9. Ursache durch kontrollierte zeitliche oder technische Änderung testen.
  10. Ergebnis über mehrere Tage beobachten.

Beispiel einer Korrelation

02:00 Uhr: Backup beginnt
02:02 Uhr: Datenträgerlatenz steigt
02:03 Uhr: Datenbankabfragen werden langsamer
02:04 Uhr: Antwortzeit p95 steigt
02:05 Uhr: erste HTTP-Timeouts
02:30 Uhr: Backup endet
02:32 Uhr: Werte normalisieren sich

Diese zeitliche Kette ist ein starker Hinweis, aber die Hypothese muss durch einen kontrollierten Test bestätigt werden.

21. Praxisfall – freier Speicherplatz nimmt kontinuierlich ab

Erforderliche Messwerte

Windows

[RO] Get-Volume |
    Select-Object DriveLetter,
                  FileSystemLabel,
                  HealthStatus,
                  SizeRemaining,
                  Size

Größte Dateien in einem bekannten Untersuchungsverzeichnis:

[RO][SENS] Get-ChildItem 'C:\Logs' -File -Recurse -ErrorAction SilentlyContinue |
    Sort-Object Length -Descending |
    Select-Object -First 20 FullName,
        @{Name='SizeMiB';Expression={
            [math]::Round($_.Length / 1MB, 1)
        }}

Linux

[RO] df -hT

[RO][PRIV] sudo du -xhd 1 /var | sort -h

macOS

[RO] df -h

[RO][PRIV] sudo du -xhd 1 /Library | sort -h

Prognosebeispiel

Freier Speicher: 100 GB
Verbrauch: 5 GB pro Tag
Vereinfachte Restzeit: ungefähr 20 Tage

Die Wachstumsrate kann schwanken. Eine Prognose sollte deshalb auf mehreren Messpunkten und einem geeigneten Zeitraum beruhen.

Dateien dürfen erst gelöscht werden, wenn Zweck, Eigentümer, Aufbewahrungspflicht und Wiederherstellbarkeit geklärt sind.

22. Kompakte Befehlsübersicht für Windows, Linux und macOS
Aufgabe Windows Linux macOS
Leistungsanzeige öffnen [RO] perfmon.msc abhängig vom Werkzeug [RO] open -a "Activity Monitor"
Prozessübersicht [RO] Get-Process [RO] top [RO] top -l 1
CPU messen [RO] Get-Counter '\Processor(_Total)\% Processor Time' [RO] mpstat -P ALL 1 10 [RO] top -l 1 -o cpu
Load Average kein direkt gleichwertiger Standardwert [RO] uptime [RO] uptime
logische CPUs [RO] (Get-CimInstance Win32_ComputerSystem).NumberOfLogicalProcessors [RO] nproc [RO] sysctl -n hw.logicalcpu
verfügbarer RAM [RO] Get-Counter '\Memory\Available MBytes' [RO] free -h [RO] memory_pressure
Speicheraktivität [RO] Get-Counter '\Memory\Pages/sec' [RO] vmstat 1 10 [RO] vm_stat 1
Prozesse nach RAM [RO] Get-Process | Sort-Object WorkingSet64 -Descending [RO] ps -eo pid,%mem,rss,comm --sort=-%mem [RO] top -l 1 -o mem
Dateisystembelegung [RO] Get-Volume [RO] df -hT [RO] df -h
Inode-Nutzung nicht direkt vergleichbar [RO] df -i [RO] df -i
Datenträger-I/O [RO] Get-Counter '\PhysicalDisk(*)\% Disk Time' [RO] iostat -xz 1 10 [RO] iostat -w 1 -c 10
Interfaceübersicht [RO] Get-NetAdapter [RO] ip link [RO] ifconfig
Interfacezähler [RO] Get-NetAdapterStatistics [RO] ip -s link [RO] netstat -ib
TCP-Zusammenfassung [RO] Get-NetTCPConnection [RO] ss -s [RO] netstat -s
Erreichbarkeit [TEST] ping ziel.example [TEST] ping -c 4 ziel.example [TEST] ping -c 4 ziel.example
Pfadprüfung [TEST] tracert ziel.example [TEST] traceroute ziel.example [TEST] traceroute ziel.example
Containerressourcen [RO] docker stats --no-stream [RO] docker stats --no-stream [RO] docker stats --no-stream
Linux-Ressourcendruck Nicht zutreffend [RO] cat /proc/pressure/{cpu,memory,io} Nicht standardmäßig vorhanden

mpstat, iostat, pidstat, nstat, mtr und ethtool sind nicht auf jeder Linux-Installation standardmäßig vorhanden. Fehlende Werkzeuge dürfen nicht ohne Prüfung der Paketquelle und betriebliche Freigabe installiert werden.

23. Systematischer Ablauf einer Monitoringanalyse
Phase Vorgehen
1. Symptom bestimmen Benutzerwirkung und betroffene Funktion dokumentieren
2. Zeitraum festlegen Fehlerbeginn, Ende und Zeitzone bestimmen
3. Datenqualität prüfen letzte Messung, Lücken und Datenquelle kontrollieren
4. Baseline wählen vergleichbaren funktionierenden Zeitraum bestimmen
5. RED prüfen Anfragerate, Fehlerrate und Dauer untersuchen
6. USE prüfen Auslastung, Sättigung und Fehler der Ressourcen untersuchen
7. Änderungspunkte prüfen Updates, Deployments, Backups und Wartung einblenden
8. Umfang bestimmen einzelne Instanz, Dienstgruppe oder gesamte Umgebung
9. Hypothese bilden möglichen Zusammenhang konkret formulieren
10. Logs und Traces prüfen technische Ursache weiter eingrenzen
11. Kontrolliert testen nur eine begründete Änderung durchführen
12. Wirkung bestätigen dieselben Messwerte erneut vergleichen
13. Langfristig beobachten Rückfall und Nebenwirkungen ausschließen
14. Dokumentieren Ursache, Messwerte, Änderung und Ergebnis festhalten

Formulierung einer guten Hypothese

Wenn die erhöhte Datenträgerlatenz die Ursache der langsamen Anwendung ist,
muss die Antwortzeit bei vergleichbarer Anfragemenge mit der
Datenträgerlatenz steigen und nach deren Normalisierung wieder sinken.

Diese Hypothese ist messbar und überprüfbar.

24. Dokumentationsvorlage für eine Monitoringanalyse 
Ticketnummer:
Analysedatum:
Betroffener Dienst:
Betroffene Systeme:
Benutzerwirkung:
Fehlerbeginn:
Fehlerende:
Zeitzone:
Reproduzierbar: Ja / Nein

Verwendetes Monitoringsystem:
Datenquelle:
Abfrageintervall:
Auswertungsintervall:
Letzter Datenpunkt:
Datenlücken vorhanden: Ja / Nein

Vergleichszeitraum:
Begründung für den Vergleichszeitraum:

Benutzerorientierte Messwerte:
- Verfügbarkeit:
- Anfragerate:
- Fehlerrate:
- Antwortzeit p50:
- Antwortzeit p95:
- Antwortzeit p99:

Ressourcenwerte:
- CPU-Auslastung:
- CPU-Sättigung:
- verfügbarer RAM:
- Paging/Swap:
- Datenträgerauslastung:
- Datenträgerlatenz:
- Datenträgerwarteschlange:
- Netzwerkdurchsatz:
- Netzwerkfehler:
- TCP-Retransmissions:
- freier Speicherplatz:

Änderungen im Zeitraum:
- Deployment:
- Update:
- Backup:
- Wartung:
- Konfigurationsänderung:

Auffällige Korrelationen:
1.
2.
3.

Arbeitshypothese:
Erwartetes Messergebnis:
Kontrollierter Test:
Tatsächliches Ergebnis:

Ermittelte Ursache:
Durchgeführte Änderung:
Rückweg:
Abschlussprüfung:
Beobachtungszeitraum nach der Änderung:

Dashboard:
Abfrage:
Screenshot oder Export:
Sensible Daten redigiert: Ja / Nein
25. Offizielle Quellen und weiterführende Dokumentation

Microsoft

Linux

Prometheus

Grafana

Docker

Bezeichnungen, Einheiten und Berechnungsmethoden können sich zwischen Betriebssystemen, Exportern und Monitoringprodukten unterscheiden. Vor einem direkten Vergleich muss immer geprüft werden, was die konkrete Metrik tatsächlich misst.

2. Grundwerkzeuge und Befehle

2.14 Sichere Paketmitschnitte, Datenschutz und Beweissicherung

Ein Paketmitschnitt zeichnet Netzwerkpakete an einer Netzwerkschnittstelle oder einem definierten Messpunkt auf. Je nach Protokoll und Verschlüsselung kann eine Aufzeichnung nicht nur technische Metadaten, sondern auch Kommunikationsinhalte enthalten.

Ein Paketmitschnitt kann unter anderem sichtbar machen:

Grundregel: So wenig wie möglich, so gezielt wie nötig und nur so lange wie erforderlich mitschneiden.

1. Kennzeichnungen und Sicherheitsregeln
Kennzeichnung Bedeutung
[RO] Liest vorhandene Informationen aus
[TEST] Führt eine aktive Messung oder Aufzeichnung durch
[PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte
[FILE] Erzeugt oder verändert eine Datei
[SENS] Datei oder Ausgabe kann vertrauliche Daten enthalten
[CHANGE] Verändert Konfiguration oder Systemzustand
[DISRUPT] Kann Verbindungen oder Dienste beeinträchtigen

Ein Live-Paketmitschnitt ist keine rein passive Read-only-Aktion. Er liest laufende Kommunikation mit und schreibt sie in eine Datei:

[TEST][PRIV][FILE][SENS]

Vor jeder Aufzeichnung müssen mindestens folgende Punkte geklärt werden:

  1. Gibt es einen konkreten technischen Anlass?
  2. Liegt eine ausreichende betriebliche und rechtliche Freigabe vor?
  3. Welche Systeme und Kommunikationsverbindungen dürfen erfasst werden?
  4. Wer ist für die Aufzeichnung verantwortlich?
  5. Welcher Zeitraum ist erforderlich?
  6. Welche Daten sollen ausdrücklich nicht erfasst werden?
  7. Wo wird die Datei gespeichert?
  8. Wer darf die Datei auswerten?
  9. Darf sie an Hersteller oder Dienstleister weitergegeben werden?
  10. Wann wird sie gelöscht?
2. Warum sind Paketmitschnitte besonders sensibel?

Eine PCAP- oder PCAPNG-Datei kann mehr Informationen enthalten, als für die technische Untersuchung zunächst sichtbar sind.

Mögliche Inhalte:

Datenart Beispiel
Netzwerkkennungen IP- und MAC-Adressen
Benutzerbezug Benutzername, Gerät oder interne Zuordnung
Kommunikationspartner interne und externe Zielsysteme
DNS-Daten angefragte Domains und Hostnamen
Zeitdaten Zeitpunkt und Dauer der Kommunikation
Inhaltsdaten unverschlüsselte Nachrichten oder Dateien
Authentifizierungsdaten Cookies, Tokens oder Anmeldeinformationen
Organisationsdaten interne Server-, Standort- und Kundennamen
Sicherheitsdaten Ports, Dienste, Zertifikate und Netzwerkstruktur
Entschlüsselungsgeheimnisse TLS-Key-Log oder eingebettete Schlüsselblöcke

Auch verschlüsselter Datenverkehr enthält auswertbare Metadaten:

Verschlüsselung macht einen Paketmitschnitt daher nicht automatisch datenschutzrechtlich oder sicherheitstechnisch unbedenklich.

3. Welche betrieblichen und rechtlichen Prüfungen sind erforderlich?

Die zulässige Verarbeitung hängt vom konkreten Zweck, der Organisation, den betroffenen Personen und den geltenden Vorgaben ab. Diese Seite ersetzt keine rechtliche Prüfung.

Möglicherweise einzubeziehende Stellen:

Relevante Datenschutzgrundsätze sind unter anderem:

Grundsatz Bedeutung für Paketmitschnitte
Rechtmäßigkeit und Transparenz Verarbeitung benötigt eine tragfähige Grundlage
Zweckbindung Daten nur für den festgelegten Diagnosezweck verwenden
Datenminimierung nur erforderliche Kommunikation erfassen
Richtigkeit Zeit, Messpunkt und Dateiintegrität dokumentieren
Speicherbegrenzung Datei nicht länger als erforderlich aufbewahren
Integrität und Vertraulichkeit Zugriff, Transport und Speicherung schützen
Rechenschaftspflicht Zweck, Freigabe und Verarbeitung dokumentieren

Nicht ausreichend sind Aussagen wie:

„Es ist nur für die Technik.“

„Die Verbindung ist verschlüsselt.“

„Wir schneiden nur kurz mit.“

Auch ein kurzer technischer Mitschnitt kann personenbezogene oder vertrauliche Daten enthalten.

4. Welche Freigaben sollten vor Beginn dokumentiert werden? 
Ticketnummer:
Verantwortliche Person:
Auftraggebende Stelle:
Technischer Zweck:
Betroffene Systeme:
Betroffene Netzsegmente:
Betroffene Benutzergruppen:
Erlaubte Protokolle:
Ausgeschlossene Systeme und Daten:
Beginn:
Geplantes Ende:
Maximale Dateigröße:
Speicherort:
Auswertungsberechtigte Personen:
Vorgesehene Weitergabe:
Aufbewahrungsfrist:
Löschtermin:
Datenschutzprüfung erforderlich: Ja / Nein
Datenschutzprüfung erfolgt: Ja / Nein
Betriebsrat einzubeziehen: Ja / Nein / Nicht zutreffend
Informationssicherheit informiert: Ja / Nein
Freigabe erteilt durch:
Freigabezeitpunkt:

Bei einem akuten Sicherheitsvorfall können besondere Incident-Response-Regelungen gelten. Auch dann müssen Zuständigkeit, Beweissicherung und Zugriff nachvollziehbar dokumentiert werden.

5. Wo sollte ein Paketmitschnitt durchgeführt werden?

Der Messpunkt bestimmt, welcher Datenverkehr sichtbar ist.

Messpunkt Sichtbarer Datenverkehr Typischer Zweck
betroffener Client Kommunikation dieses Clients lokales Clientproblem
Anwendungsserver ein- und ausgehende Serverkommunikation Backend- oder Dienstproblem
Reverse Proxy Client- und Backendverbindungen des Proxys HTTP- und TLS-Fehler eingrenzen
DNS-Server DNS-Anfragen am Server Auflösungsprobleme
Firewall Verkehr an der jeweiligen Schnittstelle Routing, NAT und Filterung
Switch-SPAN-Port gespiegelter Verkehr ausgewählter Ports oder VLANs segmentübergreifende Analyse
virtueller Switch Verkehr virtueller Systeme VM- und Hypervisoranalyse
Containerhost Verkehr von Containern und Bridges Containerkommunikation

Grundsatz

So nah wie möglich am vermuteten Problem mitschneiden.

Bei komplexen Problemen können zwei gleichzeitige Mitschnitte sinnvoll sein:

Client-Mitschnitt + Server-Mitschnitt

Damit lässt sich beispielsweise prüfen:

Vor einem Vergleich müssen die Systemuhren geprüft werden.

6. Wie wird die richtige Netzwerkschnittstelle bestimmt?

Windows

[RO] Get-NetAdapter |
    Select-Object Name,
                  InterfaceDescription,
                  Status,
                  LinkSpeed,
                  MacAddress,
                  ifIndex

IP-Konfiguration zuordnen:

[RO] Get-NetIPConfiguration

Wireshark-Schnittstellen anzeigen:

[RO] dumpcap.exe -D

[RO] tshark.exe -D

Linux

[RO] ip -brief address

[RO] ip route

[RO] dumpcap -D

[RO] tcpdump -D

macOS

[RO] ifconfig

Standardroute und verwendetes Interface:

[RO] route -n get default

Wireshark-Schnittstellen:

[RO] dumpcap -D

[RO] tcpdump -D

Typische Schnittstellen

Name Mögliche Bedeutung
Ethernet kabelgebundener Windows-Adapter
Wi-Fi Windows-WLAN
eth0, enp…, ens… Linux-Ethernet
wlan0, wlp… Linux-WLAN
en0, en1 macOS-Netzwerkschnittstelle
lo, lo0 Loopback
docker0 Docker-Bridge
br-… benutzerdefinierte Container-Bridge
vEthernet (…) virtueller Windows-Adapter
utun… macOS-Tunnel oder VPN
any zusammengefasste Linux-Capture-Schnittstelle

Die Namenskonvention allein reicht nicht. Die Schnittstelle muss über IP-Adresse, Route und tatsächliche Paketaktivität bestätigt werden.

7. Wie wird vor dem Mitschnitt ein Capture-Plan erstellt? 
Fehler:
HTTPS-Aufruf an app.example.intern schlägt sporadisch fehl.

Betroffener Client:
CLIENT-023

Ziel:
192.0.2.20

Port:
TCP 443

Schnittstelle:
Ethernet / Index 4

Geplanter Zeitraum:
maximal 120 Sekunden

Auslöser:
Benutzer führt genau einen Anmeldeversuch aus.

Capture-Filter:
host 192.0.2.20 and tcp port 443

Datei:
TICKET-4711_CLIENT-023_20260731T094200+0200.pcapng

Maximale Dateigröße:
100 MB

Speicherort:
geschütztes Diagnoseverzeichnis

Nachbereitung:
Zeitfenster weiter reduzieren, Hash bilden, Zugriff begrenzen.

Löschtermin:
nach Abschluss gemäß Ticket und interner Richtlinie

Ein guter Capture-Plan verhindert unkontrollierte Daueraufzeichnungen und unnötig große Dateien.

8. Wie wird bereits bei der Aufnahme Datenminimierung umgesetzt?

Vier zentrale Begrenzungen:

  1. richtige Schnittstelle,
  2. enger Capture-Filter,
  3. kurze Aufzeichnungsdauer,
  4. begrenzte Paketlänge oder Dateigröße.

Capture-Filter nach Host

host 192.0.2.20

Nur Kommunikation zwischen zwei Systemen

host 192.0.2.10 and host 192.0.2.20

Nur HTTPS zu einem Ziel

host 192.0.2.20 and tcp port 443

Nur DNS zu einem bestimmten DNS-Server

host 192.0.2.53 and port 53

Nur TCP zwischen zwei Systemen

tcp and host 192.0.2.10 and host 192.0.2.20

Bestimmtes Subnetz ausschließen

host 192.0.2.20 and not net 198.51.100.0/24

Wichtige Filterbegriffe

Ausdruck Bedeutung
host 192.0.2.20 Quelle oder Ziel ist dieser Host
src host 192.0.2.20 Host ist Quelle
dst host 192.0.2.20 Host ist Ziel
net 192.0.2.0/24 Verkehr eines Netzes
port 53 Quell- oder Zielport 53
src port 53 Quellport 53
dst port 443 Zielport 443
tcp nur TCP
udp nur UDP
icmp nur ICMP
and beide Bedingungen müssen zutreffen
or mindestens eine Bedingung trifft zu
not Bedingung ausschließen

Capture-Filter verwenden die Syntax von libpcap/BPF. Sie unterscheiden sich von Wireshark-Display-Filtern.

9. Was ist der Unterschied zwischen Capture- und Display-Filter?
Filterart Zeitpunkt Wirkung
Capture-Filter während der Aufnahme nicht passende Pakete werden nicht gespeichert
Display-Filter nach beziehungsweise während der Anzeige Pakete bleiben in der Datei, werden aber ausgeblendet

Capture-Filter

host 192.0.2.20 and tcp port 443

Entsprechender Display-Filter

ip.addr == 192.0.2.20 && tcp.port == 443

Ein Display-Filter reduziert nicht den sensiblen Inhalt der gespeicherten Originaldatei.

Ausgeblendet ≠ entfernt

Vor einer Weitergabe muss eine neue, tatsächlich reduzierte Datei erzeugt und anschließend erneut geprüft werden.

10. Wie wird mit dumpcap eine zeitlich begrenzte Aufnahme erstellt?

dumpcap ist die spezialisierte Capture-Komponente von Wireshark. Die grafische Wireshark-Anwendung muss dadurch nicht mit erhöhten Rechten ausgeführt werden.

Schnittstellen auflisten

[RO] dumpcap -D

60 Sekunden auf Schnittstelle 1 mitschneiden

[TEST][PRIV][FILE][SENS] dumpcap \
  -i 1 \
  -a duration:60 \
  -w capture.pcapng

Gezielter HTTPS-Mitschnitt

[TEST][PRIV][FILE][SENS] dumpcap \
  -i 1 \
  -f "host 192.0.2.20 and tcp port 443" \
  -a duration:60 \
  -w capture.pcapng

Nach 10.000 Paketen stoppen

[TEST][PRIV][FILE][SENS] dumpcap \
  -i 1 \
  -f "host 192.0.2.20" \
  -c 10000 \
  -w capture.pcapng

Nach einer Dateigröße von ungefähr 100.000 kB stoppen

[TEST][PRIV][FILE][SENS] dumpcap \
  -i 1 \
  -f "host 192.0.2.20" \
  -a filesize:100000 \
  -w capture.pcapng

Bei dumpcap wird filesize in Kilobyte zu jeweils 1.000 Byte angegeben.

Wichtige Optionen

Option Bedeutung
-D Schnittstellen auflisten
-i Schnittstelle auswählen
-f Capture-Filter
-a duration:60 nach 60 Sekunden stoppen
-a filesize:100000 bei ungefähr 100 MB stoppen
-c 10000 nach 10.000 Paketen stoppen
-s 96 maximal 96 Byte jedes Pakets speichern
-w Ausgabedatei
-p Promiscuous Mode deaktivieren
-q reduzierte Statusausgabe

Der tatsächliche Schnittstellenname oder die Nummer muss vorher mit dumpcap -D ermittelt werden.

11. Wie wird mit tcpdump eine begrenzte Aufnahme erstellt?

tcpdump ist unter Linux und macOS häufig verfügbar. Unter Windows werden üblicherweise Wireshark, Dumpcap oder TShark mit Npcap verwendet.

60 Sekunden gezielt aufzeichnen

Linux:

[TEST][PRIV][FILE][SENS] sudo timeout 60 \
  tcpdump -i eth0 \
  -nn \
  -w capture.pcap \
  'host 192.0.2.20 and tcp port 443'

timeout gehört zum GNU-Coreutils-Umfeld und ist unter macOS nicht standardmäßig in derselben Form vorhanden.

Nach 10.000 Paketen stoppen

Linux und macOS:

[TEST][PRIV][FILE][SENS] sudo tcpdump \
  -i en0 \
  -nn \
  -c 10000 \
  -w capture.pcap \
  'host 192.0.2.20 and tcp port 443'

Paketlänge auf 96 Byte begrenzen

[TEST][PRIV][FILE][SENS] sudo tcpdump \
  -i en0 \
  -nn \
  -s 96 \
  -c 10000 \
  -w capture-truncated.pcap \
  'host 192.0.2.20 and tcp port 443'

Wichtige Optionen

Option Bedeutung
-i en0 Aufnahmeschnittstelle
-nn keine Hostnamen- und Portnamensauflösung
-c 10000 nach 10.000 Paketen stoppen
-s 96 Snapshot-Länge 96 Byte
-w DATEI Rohpakete in Datei schreiben
-r DATEI vorhandene Datei lesen
Filter am Ende Capture-Filter

Eine geringe Snapshot-Länge reduziert den gespeicherten Paketinhalt, kann aber wichtige Protokollinformationen abschneiden. Außerdem bleiben Netzwerkheader, Adressen und möglicherweise Teile der Nutzdaten erhalten. Trunkierung ist keine vollständige Anonymisierung.

12. Wie wird eine Ringpuffer-Aufzeichnung sicher begrenzt?

Ein Ringpuffer schreibt mehrere Dateien und überschreibt nach Erreichen der festgelegten Anzahl die älteste Datei. Dadurch wird der maximale Speicherverbrauch begrenzt.

Dumpcap: fünf Dateien mit jeweils 60 Sekunden

[TEST][PRIV][FILE][SENS] dumpcap \
  -i 1 \
  -f "host 192.0.2.20 and tcp port 443" \
  -b duration:60 \
  -b files:5 \
  -w capture.pcapng

Dumpcap: fünf Dateien mit jeweils ungefähr 50 MB

[TEST][PRIV][FILE][SENS] dumpcap \
  -i 1 \
  -f "host 192.0.2.20 and tcp port 443" \
  -b filesize:50000 \
  -b files:5 \
  -w capture.pcapng

tcpdump: fünf Dateien mit ungefähr 50 MB

[TEST][PRIV][FILE][SENS] sudo tcpdump \
  -i eth0 \
  -nn \
  -C 50 \
  -W 5 \
  -w capture.pcap \
  'host 192.0.2.20 and tcp port 443'

Bei tcpdump können Einheit und Verhalten einzelner Rotationsoptionen von der verwendeten Implementierung und Version abhängen. Vor dem Einsatz muss die lokale Dokumentation geprüft werden:

[RO] man tcpdump

Wichtiger Hinweis

Ein Ringpuffer verhindert unbegrenztes Dateiwachstum, löscht aber ältere Aufzeichnungen automatisch durch Überschreiben. Er ist deshalb nicht geeignet, wenn alle Daten unverändert als Beweismittel erhalten bleiben müssen.

13. Wie wird der Promiscuous Mode bewertet?

Im Promiscuous Mode nimmt eine Netzwerkkarte zusätzlich Frames entgegen, die nicht unmittelbar an ihre eigene MAC-Adresse adressiert sind.

Promiscuous Mode ≠ automatisch gesamter Netzwerkverkehr

In einem geswitchten Netzwerk sieht ein Client normalerweise weiterhin nur:

Für zusätzlichen Verkehr ist häufig ein korrekt konfigurierter SPAN- beziehungsweise Mirror-Port oder ein anderer geeigneter Messpunkt erforderlich.

Promiscuous Mode mit dumpcap deaktivieren

[TEST][PRIV][FILE][SENS] dumpcap \
  -i 1 \
  -p \
  -f "host 192.0.2.20" \
  -a duration:60 \
  -w capture.pcapng

Wenn nur lokaler Hostverkehr benötigt wird, kann die Deaktivierung des Promiscuous Mode die Erfassung unbeabsichtigten Verkehrs reduzieren.

14. Was ist bei WLAN-Mitschnitten und Monitor Mode zu beachten?

Der WLAN-Monitor-Mode kann rohe 802.11-Frames eines Funkkanals erfassen. Unterstützung und Verhalten hängen ab von:

Das Aktivieren des Monitor Mode kann die bestehende WLAN-Verbindung unterbrechen:

[CHANGE][DISRUPT]

Zusätzlich können Kommunikationsdaten anderer Geräte im Funkbereich erfasst werden. Ein WLAN-Mitschnitt benötigt daher eine besonders klare technische und organisatorische Abgrenzung.

Für eine gewöhnliche Client-Fehleranalyse ist häufig ein Mitschnitt am regulären Netzwerkinterface ohne Monitor Mode ausreichend.

15. Wie wird eine laufende Aufnahme überwacht?

Während der Aufnahme sind folgende Werte zu kontrollieren:

Speicherplatz prüfen

Windows:

[RO] Get-Volume

Linux:

[RO] df -h

macOS:

[RO] df -h

Dateigröße beobachten

Windows:

[RO] Get-Item '.\capture.pcapng' |
    Select-Object FullName, Length, LastWriteTime

Linux und macOS:

[RO] ls -lh capture.pcapng

Wenn Capture-Pakete verworfen werden, ist die Aufzeichnung möglicherweise unvollständig. Mögliche Ursachen:

Ein größerer Capture-Puffer kann helfen, benötigt aber zusätzlichen Arbeitsspeicher und ersetzt keine Bewertung der Systemkapazität.

16. Wie wird ein Mitschnitt unmittelbar nach der Aufnahme geprüft?

Dateiinformationen anzeigen

Windows, Linux und macOS:

[RO][SENS] capinfos capture.pcapng

Wichtige Informationen:

Kurze Protokollübersicht

[RO][SENS] tshark -r capture.pcapng -q -z io,phs

Kommunikationsbeziehungen

[RO][SENS] tshark -r capture.pcapng -q -z endpoints,ip

[RO][SENS] tshark -r capture.pcapng -q -z conv,tcp

Prüffragen

  1. Enthält die Datei den erwarteten Zeitraum?
  2. Ist die richtige Schnittstelle erfasst?
  3. Ist der Zielverkehr enthalten?
  4. Wurde unbeabsichtigter Fremdverkehr gespeichert?
  5. Sind unverschlüsselte Inhalte sichtbar?
  6. Enthält die Datei eingebettete Entschlüsselungsgeheimnisse?
  7. Sind Kommentare oder Metadaten vorhanden?
  8. Ist eine weitere Reduktion erforderlich?
  9. Muss die Originaldatei erhalten bleiben?
  10. Wer darf die Datei öffnen?
17. Wie wird aus einer großen Aufzeichnung eine zeitlich begrenzte Arbeitskopie erstellt?

Mit editcap kann ein Zeitbereich aus einer vorhandenen Datei in eine neue Datei geschrieben werden.

Zeitbereich mit UTC-Offset auswählen

[RO][FILE][SENS] editcap \
  -A "2026-07-31T09:42:00+02:00" \
  -B "2026-07-31T09:44:00+02:00" \
  original.pcapng \
  arbeitskopie.pcapng

-A nimmt Pakete ab dem angegebenen Zeitpunkt auf. -B begrenzt auf Pakete vor dem angegebenen Endzeitpunkt.

Bestimmte Paketnummern übernehmen

Nur Pakete 200 bis 750 schreiben:

[RO][FILE][SENS] editcap \
  -r \
  original.pcapng \
  arbeitskopie.pcapng \
  200-750

Erste 500 Pakete übernehmen

[RO][FILE][SENS] editcap \
  -r \
  original.pcapng \
  erste-500.pcapng \
  1-500

Die neue Datei muss anschließend erneut mit Wireshark, TShark oder Capinfos geprüft werden. Eine erfolgreiche Programmausführung beweist nicht, dass alle unerwünschten Daten entfernt wurden.

18. Wie wird eine Datei nach einem Display-Filter exportiert?

Mit TShark kann aus einer vorhandenen Aufzeichnung eine gefilterte Datei erzeugt werden.

Nur Verkehr eines bestimmten Hosts exportieren

[RO][FILE][SENS] tshark \
  -r original.pcapng \
  -Y "ip.addr == 192.0.2.20" \
  -w gefiltert.pcapng

Nur TCP-Port 443 zu einem bestimmten Host

[RO][FILE][SENS] tshark \
  -r original.pcapng \
  -Y "ip.addr == 192.0.2.20 && tcp.port == 443" \
  -w gefiltert.pcapng

Nur ein bestimmtes TCP-Gespräch

Zunächst Streamnummer in Wireshark oder TShark bestimmen. Anschließend beispielsweise:

[RO][FILE][SENS] tshark \
  -r original.pcapng \
  -Y "tcp.stream == 4" \
  -w tcp-stream-4.pcapng

Wichtig

19. Wie werden eingebettete Entschlüsselungsgeheimnisse und Kommentare entfernt?

PCAPNG-Dateien können zusätzliche Metadaten enthalten, darunter:

Vor einer Weitergabe muss geprüft werden, ob solche Informationen vorhanden sind.

Eingebettete Entschlüsselungsgeheimnisse entfernen

[RO][FILE][SENS] editcap \
  --discard-all-secrets \
  original.pcapng \
  ohne-secrets.pcapng

Capture- und Paketkommentare entfernen

[RO][FILE][SENS] editcap \
  --discard-capture-comment \
  --discard-packet-comments \
  original.pcapng \
  ohne-kommentare.pcapng

Kombiniert

[RO][FILE][SENS] editcap \
  --discard-all-secrets \
  --discard-capture-comment \
  --discard-packet-comments \
  original.pcapng \
  bereinigt.pcapng

Danach muss die Ausgabedatei erneut geprüft werden:

[RO][SENS] capinfos bereinigt.pcapng

Das Entfernen von Geheimnisblöcken und Kommentaren entfernt nicht automatisch IP-Adressen, MAC-Adressen, Hostnamen oder Nutzdaten.

20. Warum ist Trunkierung keine vollständige Anonymisierung?

Mit editcap -s kann die gespeicherte Länge jedes Pakets begrenzt werden.

Auf 96 Byte kürzen

[RO][FILE][SENS] editcap \
  -s 96 \
  original.pcapng \
  gekuerzt.pcapng

Dadurch können Teile der Nutzdaten entfernt werden. Abhängig von den vorhandenen Protokollheadern können aber weiterhin enthalten sein:

Eine feste Snapshot-Länge kann außerdem die technische Analyse beeinträchtigen.

Gekürzt ≠ anonymisiert

Eine belastbare Anonymisierung erfordert:

Wireshark und Editcap bieten keine allgemeine Ein-Klick-Anonymisierung, die für jedes Protokoll zuverlässig sämtliche personenbezogenen oder vertraulichen Inhalte entfernt.

21. Wie werden Hashwerte zur Integritätsprüfung erstellt?

Ein kryptografischer Hash dokumentiert den Zustand einer Datei zu einem bestimmten Zeitpunkt. Wird die Datei verändert, ändert sich mit sehr hoher Wahrscheinlichkeit auch der Hash.

Windows

[RO] Get-FileHash `
    'C:\Diagnose\original.pcapng' `
    -Algorithm SHA256

Hash in Datei dokumentieren:

[RO][FILE] Get-FileHash `
    'C:\Diagnose\original.pcapng' `
    -Algorithm SHA256 |
    Format-List |
    Out-File 'C:\Diagnose\original.pcapng.sha256.txt'

Linux

[RO] sha256sum original.pcapng

[RO][FILE] sha256sum original.pcapng \
  > original.pcapng.sha256

macOS

[RO] shasum -a 256 original.pcapng

[RO][FILE] shasum -a 256 original.pcapng \
  > original.pcapng.sha256

Erneut prüfen

Linux:

[RO] sha256sum -c original.pcapng.sha256

macOS:

[RO] shasum -a 256 -c original.pcapng.sha256

Ein Hash beweist nicht automatisch, wer die Datei erstellt hat oder ob der ursprüngliche Mitschnitt vollständig war. Er hilft aber festzustellen, ob sich genau diese Datei nach der Hashbildung verändert hat.

22. Wie werden Original und Arbeitskopie getrennt?

Empfohlene Struktur:

TICKET-4711/
├── original/
│   ├── TICKET-4711_CLIENT-023_original.pcapng
│   └── TICKET-4711_CLIENT-023_original.pcapng.sha256
├── working/
│   ├── TICKET-4711_zeitfenster.pcapng
│   └── TICKET-4711_tcp-stream-4.pcapng
├── export/
│   └── TICKET-4711_freigegebene-kopie.pcapng
└── dokumentation/
    └── TICKET-4711_capture-protokoll.txt

Regeln

Das Original enthält möglicherweise mehr sensible Daten als die freigegebene Weitergabekopie und benötigt entsprechend strengere Zugriffsrechte.

23. Wie werden Dateizugriffe technisch eingeschränkt?

Windows-Beispiel

Vererbung entfernen:

[CHANGE][PRIV] icacls "C:\Diagnose\TICKET-4711" /inheritance:r

Einem ausdrücklich festgelegten Konto Zugriff gewähren:

[CHANGE][PRIV] icacls "C:\Diagnose\TICKET-4711" /grant:r "DOMÄNE\Diagnosekonto:(OI)(CI)F"

Vorher müssen Konto, gewünschte Rechte und bestehende Berechtigungen genau geprüft werden. Ein falscher icacls-Befehl kann berechtigte Personen aussperren.

Aktuelle Berechtigungen anzeigen:

[RO] icacls "C:\Diagnose\TICKET-4711"

Linux und macOS

Verzeichnis nur für den Eigentümer zugänglich machen:

[CHANGE] chmod 700 /pfad/TICKET-4711

Datei nur für den Eigentümer les- und schreibbar machen:

[CHANGE] chmod 600 /pfad/TICKET-4711/original.pcapng

Berechtigungen prüfen:

[RO] ls -ld /pfad/TICKET-4711

[RO] ls -l /pfad/TICKET-4711

Dateiberechtigungen ersetzen keine Verschlüsselung, keine sichere Übertragung und keine organisatorische Zugriffskontrolle.

24. Wie wird ein Paketmitschnitt sicher weitergegeben?

Vor jeder Weitergabe:

  1. Empfänger und Zweck bestätigen.
  2. Vertragliche und datenschutzrechtliche Zulässigkeit prüfen.
  3. Nur den erforderlichen Zeit- und Datenbereich exportieren.
  4. Unnötige Pakete entfernen.
  5. Kommentare und eingebettete Geheimnisse entfernen.
  6. Datei auf unverschlüsselte Inhalte prüfen.
  7. Freigegebene Kopie getrennt speichern.
  8. Hash der freigegebenen Datei berechnen.
  9. Sicheren Übertragungsweg verwenden.
  10. Kennwort oder Schlüssel über einen getrennten Kanal übermitteln.
  11. Übergabe im Ticket dokumentieren.
  12. Löschung beim Empfänger vereinbaren und dokumentieren.

Nicht geeignete Übertragungswege

Ein vom Hersteller bereitgestelltes Supportportal ist nicht automatisch für beliebige vertrauliche Daten freigegeben. Vertragslage, Standort, Auftragsverarbeitung und interne Vorgaben müssen geprüft werden.

25. Was ist bei TLS-Entschlüsselung zu beachten?

TLS-Entschlüsselung kann Inhalte sichtbar machen, die gerade durch Verschlüsselung geschützt werden sollen.

Mögliche Inhalte:

TLS-Key-Log-Dateien und private Schlüssel sind besonders schützenswert:

[SENS] Eine TLS-Key-Log-Datei kann die Entschlüsselung aufgezeichneter Sitzungen ermöglichen.

Regeln

PCAPNG-Dateien können Entschlüsselungsgeheimnisse eingebettet enthalten. Vor einer Weitergabe muss dies ausdrücklich geprüft werden.

26. Welche Fehler treten bei Paketmitschnitten häufig auf?
Fehler Folge Besseres Vorgehen
falsche Schnittstelle relevanter Verkehr fehlt IP-Konfiguration und Route vorher prüfen
Aufnahme am falschen Messpunkt Ursache bleibt unsichtbar Kommunikationsweg zeichnen
kein Capture-Filter unnötig viele sensible Daten Zielhost und Port begrenzen
nur Display-Filter verwendet Fremdverkehr bleibt in Datei reduzierte Datei exportieren
Aufnahme läuft unbegrenzt Speicherplatz und Datenschutzproblem Dauer, Größe oder Ringpuffer begrenzen
Fehler nicht reproduziert relevanter Vorgang fehlt exakten Reproduktionszeitpunkt notieren
Namensauflösung aktiv Anzeige wird verfälscht oder zusätzliche DNS-Last entsteht bei Analyse gegebenenfalls numerische Anzeige verwenden
Zeitabweichung ignoriert Client- und Servermitschnitt passen nicht zusammen Uhren und Zeitzonen prüfen
Snapshot-Länge zu klein benötigte Protokolldaten fehlen Anforderung vor Aufnahme bestimmen
Snapshot-Länge unbegrenzt unnötige Nutzdaten werden gespeichert erforderliche Länge bewusst festlegen
Original direkt bearbeitet Nachvollziehbarkeit geht verloren Original und Arbeitskopie trennen
Datei unverschlüsselt versendet Datenabfluss möglich freigegebenen sicheren Kanal verwenden
PCAP öffentlich hochgeladen vertrauliche Daten offengelegt interne oder freigegebene Analyse
Datei nur umbenannt Inhalt bleibt vollständig erhalten echte Reduktion und Prüfung durchführen
Hash erst nach Bearbeitung erstellt ursprünglicher Zustand nicht belegt Hash unmittelbar nach Sicherung bilden
Wireshark als Root gestartet unnötig große Angriffsfläche Capture-Funktion auf Dumpcap beschränken
27. Wie läuft ein sicherer Paketmitschnitt vollständig ab?
Phase Vorgehen
1. Auftrag klären technisches Problem und Zweck dokumentieren
2. Freigabe einholen Zuständigkeit, Datenschutz und Sicherheit klären
3. Kommunikationsweg zeichnen Client, Netzwerkkomponenten und Server bestimmen
4. Messpunkt wählen so nah wie möglich am vermuteten Problem
5. Schnittstelle prüfen Interface, IP-Adresse und Route bestätigen
6. Filter festlegen Host, Port und Protokoll begrenzen
7. Umfang begrenzen Dauer, Paketanzahl, Dateigröße und Snapshot-Länge
8. Speicher schützen Zugriffsrechte und freien Speicherplatz prüfen
9. Aufnahme starten Startzeit und Werkzeugversion dokumentieren
10. Fehler reproduzieren genau definierte Aktion ausführen
11. Aufnahme stoppen unmittelbar nach dem relevanten Vorgang
12. Datei prüfen Zeitraum, Pakete, Fremdverkehr und Geheimnisse
13. Original sichern Hash bilden und Original unverändert ablegen
14. Arbeitskopie erzeugen Zeitfenster und relevante Kommunikation reduzieren
15. Technisch analysieren Protokollablauf und Fehlerhypothese untersuchen
16. Weitergabe vorbereiten Daten minimieren und Freigabe einholen
17. Ergebnis dokumentieren Ursache, Belege und Grenzen festhalten
18. Daten löschen Aufbewahrungsfrist und Löschbestätigung beachten
28. Kompakte Befehlsübersicht
Aufgabe Befehl Kennzeichnung
Capture-Schnittstellen anzeigen dumpcap -D [RO]
tcpdump-Schnittstellen anzeigen tcpdump -D [RO]
60 Sekunden aufzeichnen dumpcap -i 1 -a duration:60 -w capture.pcapng [TEST][PRIV][FILE][SENS]
gefiltert aufzeichnen dumpcap -i 1 -f "host 192.0.2.20 and tcp port 443" -a duration:60 -w capture.pcapng [TEST][PRIV][FILE][SENS]
nach 10.000 Paketen stoppen dumpcap -i 1 -c 10000 -w capture.pcapng [TEST][PRIV][FILE][SENS]
Paketlänge begrenzen dumpcap -i 1 -s 96 -a duration:60 -w capture.pcapng [TEST][PRIV][FILE][SENS]
Ringpuffer dumpcap -i 1 -b duration:60 -b files:5 -w capture.pcapng [TEST][PRIV][FILE][SENS]
Dateiinformationen capinfos capture.pcapng [RO][SENS]
Protokollhierarchie tshark -r capture.pcapng -q -z io,phs [RO][SENS]
IP-Endpunkte tshark -r capture.pcapng -q -z endpoints,ip [RO][SENS]
TCP-Gespräche tshark -r capture.pcapng -q -z conv,tcp [RO][SENS]
Zeitbereich exportieren editcap -A "START" -B "ENDE" original.pcapng arbeitskopie.pcapng [RO][FILE][SENS]
Paketbereich exportieren editcap -r original.pcapng auszug.pcapng 200-750 [RO][FILE][SENS]
Pakete nach Filter exportieren tshark -r original.pcapng -Y "ip.addr == 192.0.2.20" -w gefiltert.pcapng [RO][FILE][SENS]
Geheimnisblöcke entfernen editcap --discard-all-secrets original.pcapng bereinigt.pcapng [RO][FILE][SENS]
Kommentare entfernen editcap --discard-capture-comment --discard-packet-comments original.pcapng bereinigt.pcapng [RO][FILE][SENS]
Paketdaten kürzen editcap -s 96 original.pcapng gekuerzt.pcapng [RO][FILE][SENS]
SHA-256 unter Windows Get-FileHash .\capture.pcapng -Algorithm SHA256 [RO]
SHA-256 unter Linux sha256sum capture.pcapng [RO]
SHA-256 unter macOS shasum -a 256 capture.pcapng [RO]
29. Dokumentationsvorlage für einen Paketmitschnitt 
Ticketnummer:
Auftraggebende Stelle:
Ausführende Person:
Freigabe erteilt durch:
Freigabezeitpunkt:
Datenschutzprüfung:
Informationssicherheit informiert:
Betriebsrat einbezogen oder nicht erforderlich:

Technischer Zweck:
Fehlerbeschreibung:
Betroffene Systeme:
Betroffene Benutzergruppe:
Ausgeschlossene Systeme:
Erlaubter Datenumfang:

Capture-System:
Betriebssystem:
Capture-Werkzeug:
Werkzeugversion:
Capture-Schnittstelle:
IP-Adresse der Schnittstelle:
Capture-Position:
Promiscuous Mode: Ja / Nein
Monitor Mode: Ja / Nein

Capture-Filter:
Snapshot-Länge:
Maximale Dauer:
Maximale Paketanzahl:
Maximale Dateigröße:
Ringpuffer: Ja / Nein
Anzahl Ringpufferdateien:

Startzeit:
Endzeit:
Zeitzone:
Zeitpunkt der Fehlerreproduktion:
Durchgeführte Aktion:

Originaldatei:
Dateigröße:
Paketanzahl:
Erstes Paket:
Letztes Paket:
SHA-256 des Originals:
Speicherort des Originals:
Zugriffsberechtigte Personen:

Arbeitskopie:
Verwendeter Zeitfilter:
Verwendeter Display-Filter:
Entfernte Kommentare:
Entfernte Entschlüsselungsgeheimnisse:
Snapshot-Länge nach Bearbeitung:
SHA-256 der Arbeitskopie:

Ermittelte Beobachtungen:
1.
2.
3.

Arbeitshypothese:
Beleg:
Gegenprüfung:
Ermittelte Ursache:

Weitergabe erforderlich: Ja / Nein
Empfänger:
Rechts- und Datenschutzprüfung:
Weitergabedatei:
SHA-256 der Weitergabedatei:
Übertragungsweg:
Übergabezeitpunkt:
Löschvereinbarung mit Empfänger:

Interne Aufbewahrungsfrist:
Geplanter Löschtermin:
Tatsächlicher Löschzeitpunkt:
Löschung bestätigt durch:
30. Offizielle Quellen und weiterführende Dokumentation

Wireshark

tcpdump und libpcap

Datenschutzrecht

Welche rechtliche Grundlage, Beteiligung oder Dokumentation im konkreten Unternehmen erforderlich ist, muss durch die zuständigen Datenschutz-, Sicherheits- und Rechtsstellen entschieden werden. Die technische Möglichkeit eines Paketmitschnitts stellt keine automatische Berechtigung zur Durchführung dar.

3. Netzwerkfehler systematisch analysieren

3. Netzwerkfehler systematisch analysieren

3.0 Netzwerkfehler systematisch eingrenzen

Netzwerkstörungen sollten nicht durch zufälliges Ausprobieren einzelner Befehle untersucht werden. Eine zuverlässige Diagnose beginnt beim betroffenen Endgerät und arbeitet sich schrittweise durch die beteiligten Ebenen und Komponenten bis zum Zielsystem vor.

Dieses Kapitel behandelt typische Fehler in lokalen Netzwerken, standortübergreifenden Verbindungen und beim Zugriff auf interne oder externe Dienste.

Grundregel: Zuerst feststellen, auf welcher Ebene die Kommunikation scheitert. Erst danach wird die konkrete Ursache innerhalb dieser Ebene untersucht.

1. Welche Ziele verfolgt dieses Kapitel?

Nach diesem Kapitel soll eine Netzwerkstörung strukturiert folgenden Bereichen zugeordnet werden können:

Das Ziel ist nicht nur, die Verbindung wiederherzustellen, sondern die tatsächliche Ursache nachvollziehbar zu bestimmen und zu dokumentieren.

2. Welche Seiten enthält das Kapitel?
Seite Thema Zentrale Fragestellung
3.0 Netzwerkfehler systematisch eingrenzen Wie wird eine Netzwerkstörung grundsätzlich untersucht?
3.1 Störungsumfang und Kommunikationsweg bestimmen Wer ist betroffen und welchen Weg nimmt die Verbindung?
3.2 Physische Verbindung und Netzwerkschnittstelle Bestehen Link, Signal und fehlerfreie Schnittstellenkommunikation?
3.3 IP-Konfiguration und Subnetz prüfen Besitzt das Endgerät eine gültige und passende Konfiguration?
3.4 DHCP-Fehler analysieren Warum erhält ein Client keine oder eine falsche IP-Konfiguration?
3.5 ARP und IPv6 Neighbor Discovery Kann die lokale Zieladresse einer MAC-Adresse zugeordnet werden?
3.6 VLAN- und Layer-2-Fehler Befinden sich Port und Endgerät im richtigen logischen Netz?
3.7 Standardgateway und Routing Existiert ein gültiger Weg zum Zielnetz?
3.8 DNS-Fehler analysieren Ist nur die Namensauflösung oder die gesamte Verbindung gestört?
3.9 Ports und Transportprotokolle prüfen Ist der benötigte TCP- oder UDP-Dienst erreichbar?
3.10 Firewall und Paketfilter untersuchen Wo und warum wird Kommunikation zugelassen oder verworfen?
3.11 NAT und Portweiterleitungen Werden Adressen und Ports korrekt übersetzt?
3.12 Proxy und Reverse Proxy Scheitert die Verbindung am Proxy, Backend oder Client?
3.13 VPN- und Tunnelprobleme Sind Tunnel, Routen, DNS und MTU korrekt?
3.14 WLAN-Störungen analysieren Liegt die Ursache bei Signal, Funkkanal, Authentifizierung oder IP-Konfiguration?
3.15 Paketverlust, Latenz und Jitter Wo entsteht eine instabile oder langsame Verbindung?
3.16 MTU, MSS und Fragmentierungsprobleme Sind Pakete für einen Teil des Übertragungsweges zu groß?
3.17 Asymmetrisches Routing Nehmen Hin- und Rückweg unterschiedliche, problematische Wege?
3.18 Netzwerkfehler mit Wireshark erkennen Welche Paketsequenz belegt die technische Störung?
3.19 Typische Netzwerkfehler nach Symptomen Welche Prüfungen passen zu einem konkreten Fehlerbild?
3.20 Befehlsübersicht für Windows, Linux und macOS Welcher Befehl prüft welche Netzwerkebene?
3.21 Dokumentations- und Eskalationsvorlage Wie wird die Analyse vollständig übergeben?
3. Welche Kennzeichnungen werden verwendet?
Kennzeichnung Bedeutung
[RO] Read-only: liest Informationen aus
[TEST] führt eine aktive Netzwerkprüfung durch
[PRIV] benötigt möglicherweise Administrator- oder Root-Rechte
[FILE] erzeugt oder verändert eine Datei
[SENS] Ausgabe kann vertrauliche Daten enthalten
[CHANGE] verändert eine Konfiguration oder einen Systemzustand
[DISRUPT] kann eine bestehende Verbindung oder einen Dienst unterbrechen

Beispiele

[RO] Get-NetIPConfiguration

Der Befehl zeigt die vorhandene Windows-Netzwerkkonfiguration an.

[TEST] ping -c 4 192.0.2.1

Der Befehl sendet aktiv ICMP-Echo-Anfragen.

[PRIV][CHANGE][DISRUPT] Restart-NetAdapter -Name 'Ethernet'

Dieser Befehl startet den Netzwerkadapter neu und unterbricht dabei bestehende Verbindungen. Er darf nicht als erster Diagnoseschritt verwendet werden.

4. Wie wird der Kommunikationsweg dargestellt?

Vor der technischen Analyse sollte der erwartete Kommunikationsweg gezeichnet werden.

Beispiel: Zugriff auf eine interne Anwendung

Client
  → Netzwerkschnittstelle
    → Access Switch
      → VLAN
        → Standardgateway
          → Firewall
            → Reverse Proxy
              → Anwendungsserver
                → Datenbankserver

Beispiel: Internetzugriff

Client
  → Switch oder Access Point
    → lokales Gateway
      → Firewall
        → NAT
          → Internetprovider
            → externes Zielsystem

Beispiel: VPN-Zugriff

Client
  → lokales Netzwerk
    → Internet
      → VPN-Gateway
        → VPN-Tunnel
          → interne Firewall
            → Zielserver

Jede Verbindung besteht aus mehreren möglichen Fehlerstellen. Der Kommunikationsweg verhindert, dass Komponenten untersucht werden, die an der Verbindung überhaupt nicht beteiligt sind.

5. Wie wird eine Netzwerkstörung sinnvoll eingegrenzt?

Die Untersuchung sollte vom Allgemeinen zum Spezifischen erfolgen.

Schritt Fragestellung
1 Was funktioniert konkret nicht?
2 Seit wann besteht die Störung?
3 Wer oder was ist betroffen?
4 Was funktioniert weiterhin?
5 Welche Änderung ging der Störung voraus?
6 Welcher Kommunikationsweg wird erwartet?
7 Auf welcher Ebene liegt der erste Fehler?
8 Ist die Störung reproduzierbar?
9 Welche Messung belegt die Vermutung?
10 Welche einzelne Änderung kann die Hypothese prüfen?
11 Wurde die ursprüngliche Funktion wiederhergestellt?
12 Wurden Ursache, Änderung und Ergebnis dokumentiert?

Beispiel

Unzureichende Fehlerbeschreibung:
„Das Netzwerk funktioniert nicht.“

Bessere Fehlerbeschreibung:
„CLIENT-023 kann seit 09:42 Uhr den internen Webserver
app.example.intern nicht über TCP 443 erreichen. Andere interne Server
sind erreichbar. Weitere Clients im selben VLAN sind nicht betroffen.“

Die zweite Beschreibung grenzt die Störung bereits deutlich ein:

6. Welche Prüfungsreihenfolge ist in der Praxis sinnvoll?
Reihenfolge Bereich Beispielprüfung
1 Fehlerbild und Umfang ein Benutzer, mehrere Benutzer oder gesamter Standort?
2 lokale Schnittstelle Adapter aktiv, Link vorhanden, Fehlerzähler?
3 IP-Konfiguration Adresse, Präfix, Gateway und DNS korrekt?
4 lokale TCP/IP-Funktion Loopback und eigene Adresse erreichbar?
5 lokales Netz Gateway und Nachbarn erreichbar?
6 Routing existiert eine Route zum Ziel?
7 Namensauflösung wird der richtige Name zur richtigen Adresse aufgelöst?
8 Transportebene ist der benötigte TCP- oder UDP-Port erreichbar?
9 Sicherheitskomponenten blockieren Host-Firewall, Netzwerk-Firewall oder ACL?
10 Anwendungsebene antwortet der eigentliche Dienst korrekt?
11 Performance treten Latenz, Paketverlust oder Wiederholungen auf?
12 Paketmitschnitt welche Paketsequenz belegt den Fehler?

Diese Reihenfolge darf an das konkrete Fehlerbild angepasst werden. Wenn beispielsweise bereits eine falsche IP-Adresse sichtbar ist, muss nicht zuerst ein entfernter Anwendungsserver untersucht werden.

7. Wie helfen OSI- und TCP/IP-Modell bei der Fehleranalyse?
OSI-Schicht Typische Komponenten Typische Fehler
1 – Bitübertragung Kabel, Funk, Stecker, Transceiver kein Link, Signalstörung, beschädigtes Kabel
2 – Sicherung Ethernet, MAC, Switch, VLAN falsches VLAN, Portfehler, Layer-2-Schleife
3 – Vermittlung IPv4, IPv6, Router falsches Subnetz, fehlende Route, falsches Gateway
4 – Transport TCP, UDP Port geschlossen, Verbindungsabbruch, Paketverlust
5 – Sitzung Sitzungssteuerung Sitzung läuft ab oder wird nicht aufgebaut
6 – Darstellung TLS, Kodierung Zertifikat, Verschlüsselung oder Format inkompatibel
7 – Anwendung DNS, HTTP, SMB, SSH Dienstfehler, Authentifizierung oder falsche Konfiguration

Wichtiger Hinweis

Das OSI-Modell ist ein Denk- und Strukturierungsmodell. Reale Protokolle und Anwendungen lassen sich nicht immer vollständig einer einzigen Schicht zuordnen.

Praktische Reihenfolge

Link vorhanden?
  ↓
gültige IP-Konfiguration?
  ↓
lokales Gateway erreichbar?
  ↓
Route zum Ziel vorhanden?
  ↓
Name korrekt aufgelöst?
  ↓
Port erreichbar?
  ↓
Anwendungsprotokoll funktioniert?
8. Was bedeutet Bottom-up, Top-down und Divide-and-Conquer?

Bottom-up

Die Untersuchung beginnt auf der untersten Ebene:

Kabel → Link → VLAN → IP → Route → Port → Anwendung

Geeignet bei:

Top-down

Die Untersuchung beginnt bei der Anwendung:

Anwendung → Port → DNS → Route → IP → Link

Geeignet bei:

Divide-and-Conquer

Die Untersuchung beginnt an einer sinnvollen mittleren Stelle:

Kann der Client das Standardgateway erreichen?

Diese Methode ist oft besonders effizient, wenn der Kommunikationsweg bekannt ist.

9. Welche Vergleichstests liefern besonders schnell Hinweise?
Vergleich Aussage
gleicher Client, anderes Ziel Ist nur ein Ziel betroffen?
anderer Client, gleiches Ziel Ist nur ein Client betroffen?
gleiche Verbindung per IP statt Name Liegt ein DNS-Problem nahe?
gleicher Dienst über anderen Port Ist nur ein Port oder Protokoll betroffen?
LAN statt WLAN Liegt die Ursache möglicherweise im Funknetz?
ohne VPN statt mit VPN Entsteht das Problem durch Tunnel, Routen oder VPN-DNS?
funktionierendes Referenzsystem Welche Konfiguration unterscheidet sich?
lokaler Zugriff statt entfernter Zugriff Funktioniert der Dienst grundsätzlich?
anderer Benutzer am selben Client Ist das Problem benutzerabhängig?
gleicher Benutzer an anderem Client Ist das Problem geräteabhängig?

Ein Vergleich ist besonders aussagekräftig, wenn dabei nur ein relevanter Faktor verändert wird.

10. Welche ersten Prüfungen sind betriebssystemübergreifend möglich?
Aufgabe Windows Linux macOS
Hostname [RO] hostname [RO] hostname [RO] hostname
lokale Zeit [RO] Get-Date -Format o [RO] date --iso-8601=seconds [RO] date "+%Y-%m-%dT%H:%M:%S%z"
Adapterübersicht [RO] Get-NetAdapter [RO] ip -brief link [RO] ifconfig
IP-Konfiguration [RO] Get-NetIPConfiguration [RO] ip -brief address [RO] ifconfig
Routingtabelle [RO] Get-NetRoute [RO] ip route [RO] netstat -rn
ARP-/Nachbartabelle [RO] Get-NetNeighbor [RO] ip neigh [RO] arp -an
DNS-Konfiguration [RO] Get-DnsClientServerAddress [RO] resolvectl status [RO] scutil --dns
Name auflösen [TEST] Resolve-DnsName example.com [TEST] getent hosts example.com [TEST] dscacheutil -q host -a name example.com
Gateway testen [TEST] Test-Connection GATEWAY -Count 4 [TEST] ping -c 4 GATEWAY [TEST] ping -c 4 GATEWAY
Route verfolgen [TEST] tracert ZIEL [TEST] traceroute ZIEL [TEST] traceroute ZIEL
TCP-Port prüfen [TEST] Test-NetConnection ZIEL -Port 443 [TEST] nc -vz ZIEL 443 [TEST] nc -vz ZIEL 443
HTTP(S) prüfen [TEST] curl -v https://ZIEL/ [TEST] curl -v https://ZIEL/ [TEST] curl -v https://ZIEL/
Verbindungen anzeigen [RO] Get-NetTCPConnection [RO] ss -tulpen [RO] netstat -anv

Die Platzhalter GATEWAY und ZIEL müssen durch vorher eindeutig bestimmte Adressen oder Namen ersetzt werden.

11. Wie werden Testergebnisse richtig bewertet?
Ergebnis Sichere Aussage Nicht automatisch bewiesen
Link ist aktiv physische beziehungsweise logische Linkerkennung besteht vollständige Netzwerkfunktion
Ping erfolgreich ICMP-Antwort kam zurück Anwendungsport funktioniert
Ping fehlgeschlagen keine ICMP-Antwort erhalten Zielsystem ist ausgeschaltet
DNS-Auflösung erfolgreich Name wurde in eine Adresse aufgelöst Zieladresse ist erreichbar
TCP-Port erreichbar TCP-Verbindung konnte aufgebaut werden Anwendung arbeitet fachlich korrekt
HTTP 401 Webdienst antwortet und fordert Authentifizierung Zugangsdaten sind falsch
HTTP 403 Anfrage wurde verstanden und verweigert Netzwerk-Firewall blockiert
HTTP 502 Proxy erhielt keine gültige Backendantwort Proxy selbst ist zwingend defekt
Traceroute endet vor dem Ziel weitere Antworten fehlen Fehler liegt sicher am letzten sichtbaren Hop
Keine Pakete im Mitschnitt am Messpunkt wurde nichts erfasst Client hat nichts gesendet

Jeder Test beantwortet nur eine begrenzte technische Frage. Die Aussage darf nicht weiter ausgedehnt werden, als das Testergebnis tatsächlich belegt.

12. Welche Störungsumfänge werden unterschieden?
Umfang Mögliche Untersuchungsrichtung
ein Benutzer Benutzerprofil, Berechtigung oder individuelle Konfiguration
ein Endgerät Adapter, Treiber, IP-Konfiguration oder lokale Firewall
ein Switchport Kabel, Port, VLAN oder Port-Security
ein VLAN Gateway, DHCP, ACL oder VLAN-Konfiguration
ein Standort WAN, Standortfirewall, DNS oder Internetanschluss
ein Dienst Serverprozess, Port, Firewall oder Backend
mehrere Dienste auf einem Server Server, Betriebssystem oder gemeinsame Ressource
alle internen Ziele lokales Routing, Gateway oder Firewall
nur externe Ziele NAT, Proxy, Internetzugang oder Provider
alle Systeme zentrale Infrastruktur, Stromversorgung oder großflächige Störung

Hilfreiche Eingrenzungsfragen

Funktioniert derselbe Zugriff von einem anderen Client?

Kann der betroffene Client ein anderes Ziel erreichen?

Funktioniert der Zugriff über die IP-Adresse?

Ist nur ein Port oder sind alle Dienste des Zielsystems betroffen?

Tritt der Fehler per LAN und WLAN auf?

Tritt der Fehler nur bei aktivem VPN auf?
13. Welche Änderungen sind besonders häufig mit Netzwerkstörungen verbunden?

Die zeitliche Nähe einer Änderung ist ein wichtiger Hinweis, aber noch kein Beweis für die Ursache.

14. Welche Maßnahmen sollten nicht vorschnell durchgeführt werden?
Maßnahme Risiko
Netzwerkadapter neu starten bestehende Verbindungen werden unterbrochen
DHCP-Lease freigeben Remotezugriff kann verloren gehen
IP-Adresse ändern Adresskonflikt oder vollständiger Verbindungsverlust
Routingtabelle verändern falsche oder asymmetrische Wege
DNS-Cache löschen Beweise und Vergleichszustand verändern sich
Firewall deaktivieren erhebliche Sicherheitslücke
Switchport neu konfigurieren mehrere Systeme können betroffen sein
VLAN ändern Endgerät verliert möglicherweise jede Erreichbarkeit
Router oder Firewall neu starten großflächiger Ausfall
VPN neu installieren Konfiguration und Protokolle können verloren gehen
Zertifikatsprüfung abschalten Sicherheitsmechanismus wird umgangen
MTU blind reduzieren Symptom wird möglicherweise nur verdeckt
Paketfilterregeln löschen Sicherheits- und Betriebsrisiko

Vor einer Änderung sollten der Ausgangszustand, die Hypothese, die erwartete Wirkung und der Rückweg dokumentiert werden.

15. Wie wird eine Netzwerkhypothese korrekt formuliert?

Ungeeignete Vermutung

„Bestimmt ist die Firewall schuld.“

Prüfbare Hypothese

Der Client erreicht das Zielsystem auf ICMP-Ebene, aber der TCP-Verbindungsaufbau
zu Port 443 erhält keine Antwort. Andere Clients im selben VLAN können den Port
erreichen. Deshalb wird eine clientbezogene Filterung oder ein Rückwegproblem
vermutet.

Dazugehörige Prüfungen

  1. Quell-IP des betroffenen Clients bestätigen.
  2. TCP-Porttest mit Zeitstempel durchführen.
  3. Host-Firewall und Sicherheitssoftware prüfen.
  4. Firewall-Logs nach Quell- und Zieladresse durchsuchen.
  5. Paketmitschnitt am Client und gegebenenfalls am Ziel vergleichen.
  6. Funktionierenden Referenzclient gegenüberstellen.

Eine Hypothese muss durch Beobachtungen begründet und durch einen konkreten Test widerlegbar sein.

16. Welche Mindestinformationen gehören in ein Netzwerkticket? 
Ticketnummer:
Meldende Person:
Betroffener Benutzer:
Betroffenes Endgerät:
Standort:
Verbindungsart: LAN / WLAN / VPN / Mobilfunk
Fehlerbeginn:
Zeitzone:
Letzter funktionierender Zeitpunkt:
Fehler reproduzierbar: Ja / Nein
Exakte Fehlermeldung:

Quellhostname:
Quell-IP:
Quell-MAC:
Quell-VLAN:
Quellgateway:
Verwendete DNS-Server:

Zielhostname:
Ziel-IP:
Zielport:
Transportprotokoll:
Anwendungsprotokoll:

Betroffene Benutzer oder Geräte:
Funktionierende Vergleichssysteme:
Weiterhin funktionierende Verbindungen:
Kürzliche Änderungen:

Erwarteter Kommunikationsweg:
1.
2.
3.
4.

Bisherige Prüfungen:
- 
- 
- 

Bisherige Änderungen:
- 
- 
- 

Arbeitshypothese:
Nächster Prüfschritt:
Rückweg bei Änderung:
17. Wann muss eine Netzwerkstörung eskaliert werden?

Eine Eskalation ist sinnvoll oder erforderlich, wenn:

Eine gute Eskalation enthält:

18. Merkschema für die erste Eingrenzung 
1. Wer ist betroffen?
2. Was genau funktioniert nicht?
3. Was funktioniert weiterhin?
4. Seit wann besteht der Fehler?
5. Was wurde vorher geändert?
6. Welcher Kommunikationsweg wird erwartet?
7. Besteht ein Link?
8. Ist die IP-Konfiguration gültig?
9. Ist das Gateway erreichbar?
10. Existiert eine Route?
11. Funktioniert die Namensauflösung?
12. Ist der Zielport erreichbar?
13. Antwortet die Anwendung?
14. Wo befindet sich der erste belegte Fehler?
15. Welche Messung bestätigt die Ursache?

Kurzform

Umfang → Link → IP → Gateway → Route → DNS → Port → Anwendung
19. Offizielle Quellen und weiterführende Dokumentation

Microsoft

Linux

Apple

Wireshark und tcpdump

Die genaue Befehlssyntax und die verfügbaren Optionen können von Betriebssystem- und Werkzeugversion abhängen. Vor Änderungen an produktiven Systemen muss zusätzlich die lokale Dokumentation geprüft werden.

3. Netzwerkfehler systematisch analysieren

3.1 Störungsumfang und Kommunikationsweg bestimmen*

Bevor einzelne Netzwerkprotokolle, Firewallregeln oder Server untersucht werden, muss der Umfang der Störung bestimmt werden. Dadurch lässt sich erkennen, ob die Ursache wahrscheinlich auf einem Endgerät, in einem Netzsegment, an einer zentralen Komponente oder am Zielsystem liegt.

Danach wird der erwartete Kommunikationsweg vom betroffenen Client bis zum Ziel dokumentiert.

Grundregel: Erst bestimmen, wer betroffen ist und welchen Weg die Kommunikation nehmen soll. Danach Messungen an den beteiligten Komponenten durchführen.

1. Welche Informationen müssen zuerst aufgenommen werden?
Information Beispiel
Betroffener Benutzer Max Mustermann
Betroffenes Gerät CLIENT-023
Standort Berlin
Verbindungsart LAN
Fehlerbeginn 2026-07-31 09:42 CEST
Letzter funktionierender Zeitpunkt 2026-07-31 09:35 CEST
Zielanwendung interne Webanwendung
Zielname app.example.intern
Ziel-IP-Adresse 192.0.2.20
Zielport TCP 443
Exakte Fehlermeldung Verbindung wegen Zeitüberschreitung fehlgeschlagen
Reproduzierbarkeit bei jedem Aufruf
Betroffene Benutzer nur ein Benutzer bekannt
Kürzliche Änderung VPN-Client wurde aktualisiert

Ungeeignete Fehlerbeschreibung

„Das Internet funktioniert nicht.“

Geeignete Fehlerbeschreibung

CLIENT-023 kann seit 09:42 Uhr die interne Anwendung
https://app.example.intern nicht öffnen. Der Browser meldet nach ungefähr
30 Sekunden eine Zeitüberschreitung. Andere Internetseiten sind erreichbar.
CLIENT-024 kann die interne Anwendung weiterhin öffnen.

Diese Beschreibung grenzt den Fehler bereits auf einen Client beziehungsweise dessen Kommunikationsweg ein.

2. Welche Fragen sollten der meldenden Person gestellt werden?
  1. Was wollten Sie genau durchführen?
  2. Welche Anwendung oder Adresse haben Sie verwendet?
  3. Welche Fehlermeldung wird vollständig angezeigt?
  4. Seit wann tritt der Fehler auf?
  5. Hat die Funktion vorher auf demselben Gerät funktioniert?
  6. Tritt der Fehler bei jedem Versuch auf?
  7. Sind weitere Benutzer betroffen?
  8. Funktionieren andere interne Anwendungen?
  9. Funktionieren externe Internetseiten?
  10. Besteht die Verbindung über LAN, WLAN oder VPN?
  11. Wurde der Arbeitsplatz oder Standort gewechselt?
  12. Wurde kurz vorher etwas aktualisiert oder verändert?
  13. Funktioniert der Zugriff von einem anderen Gerät?
  14. Funktioniert der Zugriff mit einem anderen Benutzerkonto?
  15. Welche Auswirkung hat die Störung auf die Arbeit?

Wichtig

Die Fragen sollten möglichst konkrete und überprüfbare Antworten erzeugen.

Ungenau:
„Ist das Netzwerk langsam?“

Besser:
„Wie lange dauert der Aufruf normalerweise und wie lange dauert er jetzt?“
3. Wie wird der Störungsumfang bestimmt?
Prüffrage Wenn ja Wenn nein
Ist nur ein Benutzer betroffen? Benutzerkonto, Profil und Berechtigungen prüfen Umfang auf Geräte oder Gruppen erweitern
Ist nur ein Endgerät betroffen? lokale Konfiguration, Adapter und Host-Firewall prüfen gemeinsame Infrastruktur untersuchen
Ist nur ein Switchport betroffen? Kabel, Port, VLAN und Port-Security prüfen Switch oder VLAN weiter untersuchen
Ist nur ein VLAN betroffen? Gateway, DHCP, ACL und VLAN-Konfiguration prüfen übergeordnete Komponenten untersuchen
Ist nur ein Standort betroffen? Standortverbindung, Firewall und lokales DNS prüfen zentrale oder externe Ursache möglich
Ist nur ein Zielsystem betroffen? Zielserver, Dienst, Port und Firewall prüfen gemeinsamer Netzwerkpfad möglich
Ist nur ein bestimmter Port betroffen? Dienst, Firewall und Transportprotokoll prüfen grundlegende Erreichbarkeit untersuchen
Sind alle externen Ziele betroffen? Internetzugang, NAT, Proxy oder Provider prüfen zielbezogene Störung möglich
Sind alle internen Ziele betroffen? lokales Gateway, Routing oder zentrale Firewall prüfen einzelner Dienst oder Pfad betroffen
Sind alle Systeme betroffen? zentrale Infrastruktur oder großflächige Störung prüfen Fehler weiter eingrenzen

Mögliche Umfangsebenen

Benutzer
  → Gerät
    → Switchport
      → Access Switch
        → VLAN
          → Standort
            → Unternehmensnetz
              → Dienst
                → externer Anbieter

Je höher die gemeinsame betroffene Ebene liegt, desto wahrscheinlicher ist eine gemeinsame technische Ursache.

4. Welche Vergleichstests sind besonders aussagekräftig?
Test Gleichbleibender Faktor Veränderter Faktor Mögliche Aussage
anderer Benutzer am selben Client Gerät und Netzwerkpfad Benutzerkonto Benutzer- oder Berechtigungsproblem
gleicher Benutzer an anderem Client Benutzer und Ziel Endgerät gerätebezogenes Problem
anderer Client am selben Anschluss Switchport und Pfad Endgerät Endgerät oder Kabel eingrenzen
gleicher Client an anderem Anschluss Client Port und möglicherweise VLAN Switchport oder Verkabelung
LAN statt WLAN Client und Ziel Zugangsnetz WLAN-spezifisches Problem
WLAN statt LAN Client und Ziel Zugangsnetz LAN-Port, Kabel oder VLAN
IP-Adresse statt DNS-Name Client und Zielsystem Namensauflösung DNS-Problem möglich
anderes Ziel im selben Netz Client und lokaler Pfad Zielsystem zielbezogene Störung
gleiches Ziel über anderen Port Client und Ziel Dienst beziehungsweise Port port- oder dienstbezogen
ohne VPN statt mit VPN Client und Ziel Tunnel, Routen und VPN-DNS VPN-spezifisches Problem

Bei einem Vergleichstest sollte möglichst nur ein relevanter Faktor verändert werden. Werden gleichzeitig Benutzer, Gerät, Netzwerk und Standort gewechselt, ist das Ergebnis kaum eindeutig zuzuordnen.

5. Wie wird bestimmt, was weiterhin funktioniert?

Die funktionierenden Bereiche sind für die Eingrenzung genauso wichtig wie der eigentliche Fehler.

Beispiel

Funktioniert:
- Anmeldung am Client
- Zugriff auf andere interne Webanwendungen
- Zugriff auf externe Internetseiten
- DNS-Auflösung des betroffenen Zielnamens
- Ping zum Standardgateway

Funktioniert nicht:
- TCP-Verbindung zu app.example.intern auf Port 443

Daraus kann zunächst abgeleitet werden:

Negativtest und Positivtest

Testart Beispiel
Negativtest betroffene Anwendung funktioniert nicht
Positivtest andere Anwendung im selben Zielnetz funktioniert
Referenztest anderer Client erreicht dieselbe Anwendung

Eine belastbare Eingrenzung verwendet möglichst alle drei Testarten.

6. Wie wird das Quellsystem eindeutig identifiziert?

Die Bezeichnung „mein Computer“ reicht für eine technische Analyse nicht aus.

Zu erfassen sind:

Windows

[RO] hostname

[RO] Get-ComputerInfo |
    Select-Object CsName,
                  WindowsProductName,
                  WindowsVersion,
                  OsBuildNumber

[RO] Get-NetIPConfiguration

[RO] Get-NetAdapter |
    Select-Object Name,
                  InterfaceDescription,
                  Status,
                  LinkSpeed,
                  MacAddress,
                  ifIndex

Linux

[RO] hostnamectl

[RO] ip -brief address

[RO] ip route

[RO] ip -brief link

macOS

[RO] scutil --get ComputerName

[RO] sw_vers

[RO] ifconfig

[RO] netstat -rn

[RO] networksetup -listallhardwareports

Die erfasste IP-Adresse muss der tatsächlich für die Zielverbindung verwendeten Schnittstelle zugeordnet werden. Ein System kann gleichzeitig LAN, WLAN, VPN, virtuelle Adapter und Containerinterfaces besitzen.

7. Wie wird das Zielsystem eindeutig bestimmt?

Ein Dienstname oder eine URL muss in seine technischen Bestandteile zerlegt werden.

Beispiel-URL

https://app.example.intern:8443/login
Bestandteil Wert
Schema beziehungsweise Protokoll HTTPS
Hostname app.example.intern
expliziter Port TCP 8443
Pfad /login
erwartetes Zielsystem Reverse Proxy oder Webserver
möglicher Backenddienst Anwendungsserver
mögliche weitere Abhängigkeit Datenbank oder Identitätsanbieter

Zu erfassen sind:

Windows

[RO] Resolve-DnsName app.example.intern

[TEST] Test-NetConnection app.example.intern -Port 443

Linux

[RO] getent ahosts app.example.intern

[TEST] nc -vz app.example.intern 443

macOS

[RO] dscacheutil -q host -a name app.example.intern

[TEST] nc -vz app.example.intern 443

Ein Hostname kann mehrere IPv4- und IPv6-Adressen zurückgeben. Es muss dokumentiert werden, welche Adresse der Client beim fehlerhaften Versuch tatsächlich verwendet.

8. Wie wird der erwartete Kommunikationsweg gezeichnet?

Direkter Zugriff im lokalen Netz

CLIENT-023
192.0.2.10/24
  │
  ├─ Access Switch SW-01
  │    VLAN 20
  │
  └─ SERVER-01
       192.0.2.20/24
       TCP 443

Da Quelle und Ziel im selben IPv4-Subnetz liegen, ist normalerweise kein Router für die direkte Kommunikation erforderlich.

Zugriff in ein anderes internes Netz

CLIENT-023
192.0.2.10/24
  │
  ├─ Access Switch SW-01
  │    VLAN 20
  │
  ├─ Standardgateway
  │    192.0.2.1
  │
  ├─ Core Router oder Firewall
  │
  ├─ Server-VLAN 40
  │
  └─ APP-01
       198.51.100.20/24
       TCP 443

Zugriff über Reverse Proxy

Browser
  → DNS-Auflösung
    → Reverse Proxy TCP 443
      → TLS-Verarbeitung
        → Backend TCP 8080
          → Anwendung
            → Datenbank

Zugriff über VPN

Client
  → lokales Gateway
    → Internet
      → VPN-Gateway
        → verschlüsselter Tunnel
          → interne Route
            → interne Firewall
              → Zielserver

Zu jeder Verbindung sollte bekannt sein:

9. Wie wird geprüft, welchen Weg das Betriebssystem verwenden möchte?

Windows – Route zu einem Ziel untersuchen

[RO] Find-NetRoute -RemoteIPAddress 198.51.100.20

Routingtabelle anzeigen:

[RO] Get-NetRoute -AddressFamily IPv4 |
    Sort-Object DestinationPrefix, RouteMetric |
    Format-Table ifIndex,
                 DestinationPrefix,
                 NextHop,
                 RouteMetric,
                 InterfaceMetric

Pfad verfolgen:

[TEST] tracert -d 198.51.100.20

Linux – ausgewählte Route anzeigen

[RO] ip route get 198.51.100.20

Beispielausgabe:

198.51.100.20 via 192.0.2.1 dev eth0 src 192.0.2.10
Feld Bedeutung
via 192.0.2.1 nächster Router
dev eth0 verwendete Schnittstelle
src 192.0.2.10 ausgewählte Quelladresse

Pfad verfolgen:

[TEST] traceroute -n 198.51.100.20

macOS – ausgewählte Route anzeigen

[RO] route -n get 198.51.100.20

Pfad verfolgen:

[TEST] traceroute -n 198.51.100.20

Traceroute zeigt nur antwortende Zwischenstationen. Firewalls und Router können die verwendeten Diagnosepakete verwerfen oder nicht beantworten. Ein Sternchen beweist daher nicht, dass genau dieser Hop den eigentlichen Anwendungsverkehr blockiert.

10. Wie wird bei mehreren Netzwerkschnittstellen die verwendete Schnittstelle bestimmt?

Ein Client kann gleichzeitig besitzen:

Das Betriebssystem wählt den Weg anhand der Routingtabelle, der Präfixlänge und der Metrik.

Windows

Ausgewählte Route:

[RO] Find-NetRoute -RemoteIPAddress 198.51.100.20

Schnittstellenmetriken:

[RO] Get-NetIPInterface |
    Sort-Object AddressFamily, InterfaceMetric |
    Select-Object ifIndex,
                  InterfaceAlias,
                  AddressFamily,
                  ConnectionState,
                  InterfaceMetric

Linux

[RO] ip route get 198.51.100.20

Richtlinienregeln anzeigen:

[RO] ip rule show

Alle wichtigen Routingtabellen anzeigen:

[RO] ip route show table all

macOS

[RO] route -n get 198.51.100.20

Netzwerkdienstreihenfolge grafisch prüfen:

Systemeinstellungen
→ Netzwerk
→ Aktionsmenü
→ Reihenfolge der Dienste festlegen

Die sichtbare Dienstreihenfolge allein ersetzt nicht die Prüfung der tatsächlich ausgewählten Route.

11. Wie werden lokale und entfernte Ziele unterschieden?

Das Endgerät entscheidet anhand von IP-Adresse und Präfix beziehungsweise Subnetzmaske, ob das Ziel lokal erreichbar sein sollte.

Lokales Ziel

Quelle: 192.0.2.10/24
Ziel:   192.0.2.20

Beide Adressen gehören zum Netz:

192.0.2.0/24

Der Client versucht normalerweise, die MAC-Adresse des Zielsystems direkt zu ermitteln.

Entferntes Ziel

Quelle: 192.0.2.10/24
Ziel:   198.51.100.20

Das Ziel liegt außerhalb des lokalen Netzes. Der Client sendet das Paket normalerweise an einen Router beziehungsweise das passende Next Hop.

Bedeutung für die Fehleranalyse

Zieltyp Erste technische Untersuchung
lokal VLAN, ARP beziehungsweise Neighbor Discovery, Switchport
entfernt Standardgateway, Route, Firewall und Rückweg
unklar lokale IP-Konfiguration und Präfix zuerst prüfen

Eine falsche Subnetzmaske kann dazu führen, dass ein Client ein entferntes Ziel fälschlich für lokal hält oder ein lokales Ziel unnötig an das Gateway sendet.

12. Wie wird bestimmt, ob IPv4 oder IPv6 verwendet wird?

Ein Hostname kann IPv4- und IPv6-Adressen besitzen.

Windows

[RO] Resolve-DnsName app.example.intern -Type A

[RO] Resolve-DnsName app.example.intern -Type AAAA

Bestehende TCP-Verbindung prüfen:

[RO] Get-NetTCPConnection |
    Where-Object RemotePort -eq 443 |
    Select-Object LocalAddress,
                  LocalPort,
                  RemoteAddress,
                  RemotePort,
                  State,
                  OwningProcess

Linux

[RO] getent ahosts app.example.intern

IPv4 gezielt testen:

[TEST] curl -4 -I https://app.example.intern/

IPv6 gezielt testen:

[TEST] curl -6 -I https://app.example.intern/

macOS

[RO] dscacheutil -q host -a name app.example.intern

[TEST] curl -4 -I https://app.example.intern/

[TEST] curl -6 -I https://app.example.intern/

Wenn IPv4 funktioniert und IPv6 nicht, bedeutet das nicht automatisch, dass IPv6 deaktiviert werden sollte. Stattdessen müssen IPv6-Adresse, Präfix, Router, DNS, Firewall und Rückweg untersucht werden.

13. Wie wird ein Dienst hinter Load Balancer oder Reverse Proxy berücksichtigt?

Der im DNS eingetragene Endpunkt ist möglicherweise nicht der eigentliche Anwendungsserver.

Client
  → DNS
    → virtuelle IP-Adresse
      → Load Balancer oder Reverse Proxy
        → Backend 1
        → Backend 2
        → Backend 3

Zu dokumentieren sind:

Mögliche Fehlerbilder

Beobachtung Untersuchungsrichtung
jeder zweite Aufruf schlägt fehl einzelnes Backend möglicherweise fehlerhaft
direkter Backendzugriff funktioniert Proxy- oder Frontendkonfiguration prüfen
Proxy antwortet mit 502 Backendverbindung oder Antwort ungültig
Proxy antwortet mit 504 Backend antwortet nicht rechtzeitig
Zertifikat passt nicht SNI, Hostname oder TLS-Terminierung prüfen
nur ein Benutzer betroffen Sitzung, Cookie oder bestimmtes Backend prüfen
DNS liefert mehrere Adressen jede Zieladresse getrennt testen

Ein erfolgreicher Test gegen ein einzelnes Backend beweist nicht, dass der vollständige produktive Weg über den Load Balancer funktioniert.

14. Wie wird ein Proxy im Kommunikationsweg erkannt?

Windows – WinHTTP-Proxy

[RO] netsh winhttp show proxy

Benutzerbezogene Windows-Proxyeinstellungen:

[RO] Get-ItemProperty `
    'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
    Select-Object ProxyEnable,
                  ProxyServer,
                  AutoConfigURL

Linux

[RO][SENS] env |
    grep -iE '^(http|https|all|no)_proxy='

macOS

[RO] scutil --proxy

Proxykonfiguration eines bestimmten Netzwerkdienstes:

[RO] networksetup -getwebproxy "Wi-Fi"

[RO] networksetup -getsecurewebproxy "Wi-Fi"

Zu beachten

Ein Proxy muss daher als eigene Komponente in den Kommunikationsweg aufgenommen werden.

15. Wie wird eine Störungsmatrix erstellt?

Eine Störungsmatrix macht Muster sichtbar.

Test CLIENT-023 CLIENT-024 CLIENT-025
Gateway erreichbar Ja Ja Ja
DNS-Auflösung Ja Ja Ja
Ziel-IP erreichbar Ja Ja Ja
TCP 443 erreichbar Nein Ja Ja
Anwendung funktioniert Nein Ja Ja
Internetzugriff Ja Ja Ja
VLAN 20 20 30
Betriebssystem Windows Windows Linux

Erste Einordnung

Da nur CLIENT-023 betroffen ist und andere Clients denselben Zielport erreichen, sind folgende Bereiche wahrscheinlicher:

Eine allgemeine Störung des Zielservers ist anhand dieser Matrix weniger wahrscheinlich, aber noch nicht vollständig ausgeschlossen.

16. Wie wird eine Zeitlinie der Störung erstellt?
Zeitpunkt Ereignis
09:30 VPN-Client-Update abgeschlossen
09:35 letzter erfolgreicher Anwendungszugriff
09:40 Client wurde neu gestartet
09:42 erster fehlgeschlagener Zugriff
09:45 Fehler im Ticket gemeldet
09:50 anderer Client erfolgreich getestet
09:55 DNS-Auflösung erfolgreich geprüft
10:00 TCP-Porttest schlägt fehl

Auswertung

Die zeitliche Nähe zwischen VPN-Update und Störung erzeugt eine prüfbare Hypothese. Sie beweist jedoch noch nicht, dass das Update die Ursache ist.

Zu prüfen wären beispielsweise:

17. Welche typischen Fehlschlüsse müssen vermieden werden?
Beobachtung Unzulässiger Schluss Richtige Einordnung
ein Benutzer meldet den Fehler nur ein Benutzer ist betroffen Umfang aktiv prüfen
Ping funktioniert Anwendung funktioniert nur ICMP-Erreichbarkeit bestätigt
Ping funktioniert nicht Host ist offline ICMP kann blockiert sein
DNS liefert eine Adresse DNS ist vollständig korrekt Adresse und verwendete Antwort prüfen
Port 443 ist erreichbar Webanwendung ist fehlerfrei nur TCP-Verbindungsaufbau bestätigt
Traceroute zeigt Sterne dort liegt der Fehler Hop antwortet möglicherweise nur nicht
anderer Client funktioniert Zielserver ist fehlerfrei clientspezifischer oder intermittierender Fehler möglich
direkter Backendtest funktioniert gesamter Dienstpfad funktioniert Proxy, Load Balancer und DNS fehlen im Test
Fehler trat nach Update auf Update ist die Ursache zeitlicher Zusammenhang ist nur ein Hinweis
nur WLAN betroffen Access Point ist defekt Funk, Authentifizierung, VLAN und Client prüfen
hohe Latenz an einem Hop dieser Router verursacht Verzögerung Antwortpriorisierung kann abweichen
18. Welche Informationen werden an die nächste Diagnosephase übergeben?

Nach der ersten Eingrenzung sollten folgende Ergebnisse vorliegen:

Störungsumfang:
Nur CLIENT-023 betroffen.

Quelle:
CLIENT-023
192.0.2.10/24
LAN
VLAN 20

Ziel:
app.example.intern
198.51.100.20
TCP 443

Erwarteter Weg:
CLIENT-023
→ SW-01
→ Gateway 192.0.2.1
→ FW-01
→ Reverse Proxy
→ APP-01

Funktioniert:
- Link vorhanden
- gültige IP-Adresse
- Gateway erreichbar
- DNS-Auflösung erfolgreich
- andere interne und externe Ziele erreichbar

Funktioniert nicht:
- TCP-Verbindung zum Zielport 443

Vergleich:
CLIENT-024 im selben VLAN erreicht das Ziel.

Änderung:
VPN-Client wurde kurz vorher aktualisiert.

Arbeitshypothese:
Lokale Route, VPN-Filter oder Host-Firewall auf CLIENT-023.

Nächste Diagnosephase:
Physische Schnittstelle, IP-Konfiguration und ausgewählte Route
des Clients vollständig prüfen.

Damit beginnt die nächste Seite:

3.2 Physische Verbindung und Netzwerkschnittstelle prüfen
19. Dokumentationsvorlage 
Ticketnummer:
Bearbeitungsbeginn:
Bearbeitende Person:
Priorität:

Fehlerbeschreibung:
Exakte Fehlermeldung:
Fehlerbeginn:
Letzter funktionierender Zeitpunkt:
Zeitzone:
Reproduzierbar: Ja / Nein

BETROFFENER UMFANG

Benutzer:
Endgeräte:
Switchports:
VLANs:
Standorte:
Dienste:
Zielsysteme:
Nicht betroffen:

QUELLE

Hostname:
Betriebssystem:
Benutzer:
Verbindungsart:
Schnittstelle:
MAC-Adresse:
IPv4-Adresse und Präfix:
IPv6-Adresse und Präfix:
Standardgateway:
DNS-Server:
VLAN:
VPN:
Proxy:

ZIEL

Dienstname:
URL oder Freigabe:
Hostname:
IPv4-Adresse:
IPv6-Adresse:
Transportprotokoll:
Port:
Anwendungsprotokoll:
Load Balancer:
Reverse Proxy:
Backend:
Weitere Abhängigkeiten:

ERWARTETER KOMMUNIKATIONSWEG

1.
2.
3.
4.
5.
6.

VERGLEICHSTESTS

Gleicher Client, anderes Ziel:
Anderer Client, gleiches Ziel:
IP-Adresse statt Name:
LAN statt WLAN:
Ohne VPN:
Anderer Benutzer:
Referenzsystem:

FUNKTIONIERT WEITERHIN

-
-
-

FUNKTIONIERT NICHT

-
-
-

ZEITLINIE

Zeitpunkt:
Ereignis:

Zeitpunkt:
Ereignis:

Kürzliche Änderungen:
Arbeitshypothese:
Begründung:
Nächster Prüfschritt:
Eskalation erforderlich: Ja / Nein
20. Offizielle Quellen und weiterführende Dokumentation

Microsoft

Linux

Apple

Der erwartete Kommunikationsweg muss anhand der tatsächlich eingesetzten Netzwerkarchitektur dokumentiert werden. Beispieladressen und Komponentennamen dürfen nicht ungeprüft auf eine produktive Umgebung übertragen werden.

3. Netzwerkfehler systematisch analysieren

3.2 Physische Verbindung und Netzwerkschnittstelle prüfen

Auf der untersten Netzwerkebene wird geprüft, ob zwischen Endgerät und nächster Netzwerkkomponente eine technisch funktionsfähige Verbindung besteht. Dazu gehören Kabel, Stecker, Transceiver, Switchport, WLAN-Signal, Netzwerkkarte, Treiber, Linkstatus, Geschwindigkeit, Duplexmodus und Fehlerzähler.

Grundregel: Ein angezeigter Link beweist nur, dass die beteiligten Schnittstellen eine physische beziehungsweise logische Verbindung erkannt haben. Er beweist nicht, dass VLAN, IP-Konfiguration, Routing oder Anwendungen funktionieren.

1. Welche Komponenten gehören zur physischen Verbindung?

Kupfer-Ethernet

Endgerät
  → Netzwerkkarte
    → RJ45-Stecker
      → Patchkabel
        → Netzwerkdose
          → Gebäudeverkabelung
            → Patchpanel
              → Patchkabel
                → Switchport

Glasfaserverbindung

Gerät
  → Netzwerkkarte
    → Transceiver
      → Glasfaserkabel
        → Patchfeld
          → Glasfaserstrecke
            → Transceiver
              → Switchport

WLAN-Verbindung

Client
  → WLAN-Adapter
    → Funkverbindung
      → Access Point
        → Ethernet-Uplink
          → Switchport

Jede Komponente kann vollständig ausfallen oder die Verbindung nur zeitweise beeinträchtigen.

2. Welche Symptome sprechen für einen Fehler auf Layer 1 oder am Netzwerkadapter?

Einzelne ältere Fehlerzähler beweisen keine aktuelle Störung. Entscheidend ist, ob die Zähler während des Fehlerzeitraums weiter ansteigen.

3. Welche Sichtprüfung sollte zuerst durchgeführt werden?
Prüfung Fragestellung
Kabel Ist es geknickt, beschädigt, gequetscht oder ungewöhnlich gespannt?
Stecker Sitzt der Stecker vollständig und rastet er ein?
Netzwerkdose Ist die richtige und dokumentierte Dose verbunden?
Patchpanel Ist die Zuordnung zum Switchport korrekt?
Switchport Leuchtet beziehungsweise blinkt die Linkanzeige?
Netzwerkkarte Wird ein Link angezeigt?
Transceiver Sitzt das Modul vollständig im Steckplatz?
Glasfaser Stimmen Fasertyp und Transceivertyp überein?
Dockingstation Ist sie mit Strom versorgt und korrekt verbunden?
USB-Adapter Wird er vom Betriebssystem erkannt?
Access Point Ist der Client tatsächlich mit dem erwarteten AP verbunden?

Sicherheitsregeln bei Glasfaser

[CHANGE][DISRUPT] Das Entfernen eines Kabels oder Transceivers unterbricht die Verbindung.
5. Wie wird der Adapterstatus unter Windows geprüft?

Alle sichtbaren Netzwerkadapter

[RO] Get-NetAdapter |
    Sort-Object Name |
    Format-Table Name,
                 InterfaceDescription,
                 ifIndex,
                 Status,
                 LinkSpeed,
                 MacAddress

Auch ausgeblendete Adapter anzeigen

[RO] Get-NetAdapter -IncludeHidden |
    Sort-Object Name |
    Format-Table Name,
                 InterfaceDescription,
                 ifIndex,
                 Status,
                 LinkSpeed,
                 MacAddress

Bestimmten Adapter vollständig anzeigen

[RO] Get-NetAdapter -Name 'Ethernet' |
    Format-List *

Physische Adapter anzeigen

[RO] Get-NetAdapter -Physical |
    Format-Table Name,
                 InterfaceDescription,
                 Status,
                 LinkSpeed,
                 MacAddress

Grafische Adapterübersicht öffnen

[RO] ncpa.cpl

Wichtige Felder

Feld Bedeutung
Name logischer Windows-Adaptername
InterfaceDescription Hersteller- oder Treiberbezeichnung
ifIndex Schnittstellenindex
Status aktueller Adapterstatus
LinkSpeed gemeldete Verbindungsgeschwindigkeit
MacAddress Hardwareadresse des Adapters

Virtuelle Adapter, VPN-Adapter und Hypervisorinterfaces müssen von der tatsächlich verwendeten physischen Schnittstelle unterschieden werden.

6. Wie werden Windows-Adapterstatistiken untersucht?

Grundlegende Statistiken

[RO] Get-NetAdapterStatistics

Bestimmten Adapter vollständig anzeigen

[RO] Get-NetAdapterStatistics -Name 'Ethernet' |
    Format-List *

Kompakte Übersicht

[RO] Get-NetAdapterStatistics -Name 'Ethernet' |
    Select-Object Name,
                  ReceivedBytes,
                  ReceivedUnicastPackets,
                  ReceivedDiscardedPackets,
                  ReceivedPacketErrors,
                  SentBytes,
                  SentUnicastPackets,
                  OutboundDiscardedPackets,
                  OutboundPacketErrors

Zähler zu zwei Zeitpunkten vergleichen

[RO] $Vorher = Get-NetAdapterStatistics -Name 'Ethernet'

Start-Sleep -Seconds 30

$Nachher = Get-NetAdapterStatistics -Name 'Ethernet'

[PSCustomObject]@{
    ZeitraumSekunden        = 30
    EmpfangeneBytes         = $Nachher.ReceivedBytes - $Vorher.ReceivedBytes
    GesendeteBytes          = $Nachher.SentBytes - $Vorher.SentBytes
    Empfangsfehler          = $Nachher.ReceivedPacketErrors - $Vorher.ReceivedPacketErrors
    Sendefehler             = $Nachher.OutboundPacketErrors - $Vorher.OutboundPacketErrors
    Empfangsverwerfungen    = $Nachher.ReceivedDiscardedPackets - $Vorher.ReceivedDiscardedPackets
    Sendeverwerfungen       = $Nachher.OutboundDiscardedPackets - $Vorher.OutboundDiscardedPackets
}

Start-Sleep verändert keine Netzwerkkonfiguration, verlängert aber die Ausführung der Messung. Die Zähler werden nur gelesen.

Bewertung

Zähler Mögliche Bedeutung
ReceivedPacketErrors steigt fehlerhafte empfangene Pakete oder Frames
OutboundPacketErrors steigt Fehler beim Senden
ReceivedDiscardedPackets steigt Pakete wurden trotz möglicher Fehlerfreiheit verworfen
OutboundDiscardedPackets steigt ausgehende Pakete wurden verworfen
Bytes steigen nicht möglicherweise keine Aktivität oder falscher Adapter

Die genaue Herkunft einzelner Zähler hängt vom Netzwerktreiber und Adapter ab.

7. Wie werden Windows-Treiber und erweiterte Adaptereigenschaften geprüft?

Treiberinformationen des Adapters

[RO] Get-NetAdapter -Name 'Ethernet' |
    Select-Object Name,
                  InterfaceDescription,
                  DriverInformation,
                  DriverFileName,
                  DriverVersion,
                  DriverDate

Falls die Treiberdetails in der Ausgabe des eingesetzten Systems nicht vollständig bereitgestellt werden:

[RO] Get-CimInstance Win32_PnPSignedDriver |
    Where-Object DeviceClass -eq 'NET' |
    Select-Object DeviceName,
                  Manufacturer,
                  DriverProviderName,
                  DriverVersion,
                  DriverDate,
                  IsSigned

Erweiterte Eigenschaften anzeigen

[RO] Get-NetAdapterAdvancedProperty -Name 'Ethernet'

Energiespareinstellungen anzeigen

[RO] Get-NetAdapterPowerManagement -Name 'Ethernet'

Hardwarestatus über den Geräte-Manager

[RO] devmgmt.msc

Zu prüfen sind:

Erweiterte Eigenschaften besitzen je nach Hersteller, Treiber und Sprache unterschiedliche Namen. Werte dürfen nicht anhand fremder Beispiele ungeprüft verändert werden.

[CHANGE][DISRUPT] Änderungen an Geschwindigkeit, Duplex, Offloading,
Puffern oder Energieverwaltung können die Verbindung unterbrechen
oder die Leistung verschlechtern.
9. Wie werden Geschwindigkeit, Duplex und Autonegotiation unter Linux geprüft?

Falls ethtool installiert ist:

[RO][PRIV] sudo ethtool eth0

Typische relevante Felder:

Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
Link detected: yes
Feld Bedeutung
Supported link modes vom Adapter unterstützte Modi
Advertised link modes der Gegenstelle angebotene Modi
Link partner advertised link modes von der Gegenstelle angebotene Modi
Speed ausgehandelte Geschwindigkeit
Duplex Halb- oder Vollduplex
Auto-negotiation automatische Aushandlung aktiv oder inaktiv
Port physischer Medientyp
Link detected Link erkannt

Treiber- und Firmwareinformationen

[RO][PRIV] sudo ethtool -i eth0

Treiberstatistiken

[RO][PRIV] sudo ethtool -S eth0

Pause-Frame-Einstellungen anzeigen

[RO][PRIV] sudo ethtool -a eth0

Energy Efficient Ethernet anzeigen

[RO][PRIV] sudo ethtool --show-eee eth0

Nicht jeder Treiber unterstützt alle Abfragen. Eine Meldung wie Operation not supported kann bedeuten, dass Adapter oder Treiber die entsprechende Funktion nicht bereitstellen.

10. Wie werden Linux-Schnittstellenfehler und Verwerfungen geprüft?

Standardstatistiken anzeigen

[RO] ip -s link show dev eth0

Detailliertere Standardstatistiken:

[RO] ip -s -s link show dev eth0

Beispielstruktur:

RX: bytes  packets  errors  dropped  missed  mcast
TX: bytes  packets  errors  dropped  carrier collsns

Zähler aus sysfs

[RO] grep . /sys/class/net/eth0/statistics/*

Ausgewählte Zähler:

[RO] for Datei in \
  rx_packets rx_bytes rx_errors rx_dropped \
  tx_packets tx_bytes tx_errors tx_dropped \
  collisions; do
    printf '%-20s ' "$Datei"
    cat "/sys/class/net/eth0/statistics/$Datei"
done

Zweimal messen

[RO] ip -s link show dev eth0

Fehler reproduzieren oder einen definierten Zeitraum abwarten:

[RO] ip -s link show dev eth0

Nur wenn sich ein Fehlerzähler im relevanten Zeitraum erhöht, besteht ein zeitlicher Zusammenhang zur aktuellen Störung.

11. Wie werden Link- und Treibermeldungen unter Linux gesucht?

Kernelmeldungen des aktuellen Starts

[RO][PRIV] sudo journalctl -k -b

Nach typischen Netzwerkmeldungen suchen:

[RO][PRIV] sudo journalctl -k -b |
    grep -Ei 'link.*(up|down)|carrier|duplex|firmware|eth|network|reset|timeout'

Meldungen einer bestimmten Schnittstelle

[RO][PRIV] sudo journalctl -k -b |
    grep -F 'eth0'

NetworkManager-Protokoll

[RO][PRIV] sudo journalctl -b -u NetworkManager

systemd-networkd-Protokoll

[RO][PRIV] sudo journalctl -b -u systemd-networkd

Je nach Distribution und Netzwerkkonfiguration wird nur einer dieser Dienste verwendet. Die tatsächliche Netzwerkverwaltung muss auf dem System bestimmt werden.

Typische Hinweise:

12. Wie wird der Schnittstellenstatus unter macOS geprüft?

Hardwareports und Gerätenamen zuordnen

[RO] networksetup -listallhardwareports

Beispiel:

Hardware Port: Ethernet
Device: en0
Ethernet Address: 00:11:22:33:44:55

Alle Schnittstellen anzeigen

[RO] ifconfig

Bestimmte Schnittstelle anzeigen

[RO] ifconfig en0

Wichtige Felder:

Feld Bedeutung
status: active Link beziehungsweise Dienst ist aktiv
status: inactive kein aktiver Link
ether MAC-Adresse
media aktuelles Medium und ausgehandelter Modus
mtu Maximum Transmission Unit
RX/TX-Informationen abhängig von Befehl und Ausgabe

Status eines Netzwerkdienstes

[RO] networksetup -getinfo "Ethernet"

Der Dienstname muss vorher mit folgendem Befehl ermittelt werden:

[RO] networksetup -listallnetworkservices

Medienstatus

[RO] networksetup -getMedia "Ethernet"

Die Verfügbarkeit und Ausgabe von -getMedia hängen vom Adapter, Treiber und Netzwerkdienst ab.

13. Wie werden Schnittstellenzähler unter macOS geprüft?

Interfaceübersicht mit Zählern

[RO] netstat -ib

Nur eine bestimmte Schnittstelle:

[RO] netstat -ib -I en0

Regelmäßig aktualisierte Anzeige:

[RO] netstat -w 1 -I en0

Beenden mit:

Strg+C

Je nach macOS-Version enthält die Ausgabe unter anderem:

Systembericht zur Netzwerkkonfiguration

[RO][SENS] system_profiler SPNetworkDataType

Der Systembericht kann interne Netzwerk-, Geräte- und Dienstinformationen enthalten und sollte bei einer Weitergabe entsprechend behandelt werden.

14. Wie werden Geschwindigkeit und Duplex richtig bewertet?

Beispiel einer erwarteten Verbindung

Endgerät: Gigabit-Ethernet
Switchport: Gigabit-Ethernet
Kabel: für Gigabit geeignet
Erwartung: 1000 Mbit/s, Full Duplex
Gemessen: 100 Mbit/s, Full Duplex

Mögliche Ursachen:

Duplex-Mismatch

Ein Duplex-Mismatch kann entstehen, wenn eine Seite fest auf Vollduplex gestellt ist, während die andere Seite anders konfiguriert ist oder keine passende Aushandlung erfolgt.

Mögliche Symptome:

Empfehlung

Bei modernen Ethernetverbindungen sollte Autonegotiation normalerweise auf beiden Seiten konsistent verwendet werden. Eine manuelle Einstellung darf nur entsprechend Herstellerdokumentation und abgestimmt auf beiden Seiten vorgenommen werden.

[CHANGE][DISRUPT] Geschwindigkeit und Duplex nicht einseitig und nicht
ohne dokumentierten Rückweg verändern.
15. Wie werden Fehlerzähler richtig interpretiert?
Zähler Mögliche technische Bedeutung
RX Errors allgemeine Empfangsfehler
TX Errors allgemeine Sendefehler
CRC Errors Frame-Prüfsumme stimmt nicht
Frame Errors ungültige Frameausrichtung oder Rahmenfehler
Length Errors unerwartete Frame- beziehungsweise Paketlänge
Dropped/Discards Paket wurde verworfen
Overruns Puffer oder Verarbeitung konnte Daten nicht rechtzeitig übernehmen
Missed Adapter oder Treiber konnte Pakete nicht übernehmen
Carrier Errors Trägersignalproblem beim Senden
Collisions Kollisionen im Halbduplexbetrieb
Late Collisions verspätete Kollisionen, häufig Hinweis auf Duplex- oder Segmentproblem
FEC Corrected Fehler wurden durch Forward Error Correction korrigiert
FEC Uncorrectable Fehler konnten durch FEC nicht korrigiert werden
Link Down Events Anzahl erkannter Linkabbrüche

Wichtige Einschränkungen

Geeignete Messung

1. Ausgangswerte notieren.
2. Fehler reproduzieren.
3. Zähler erneut erfassen.
4. Differenz berechnen.
5. Gegenseite im selben Zeitraum prüfen.
16. Warum müssen beide Seiten einer Ethernetverbindung geprüft werden?

Eine Verbindung besitzt zwei Enden:

Client-NIC ←→ Switchport

Ein Client kann beispielsweise nur Empfangsfehler melden, während der Switch Sendefehler oder Linkabbrüche protokolliert.

Auf beiden Seiten sollten geprüft werden:

Client Switch
Linkstatus Portstatus
Geschwindigkeit ausgehandelte Geschwindigkeit
Duplex ausgehandelter Duplexmodus
RX-Fehler TX-Fehler
TX-Fehler RX-Fehler
Drops Discards
Treibermeldungen Port- und Systemlogs
MAC-Adresse gelernte MAC-Adresse
Verbindungszeitpunkt letzte Linkänderung
Adaptermodell Port- und Transceivertyp

Die konkreten Switchbefehle unterscheiden sich je nach Hersteller und Betriebssystem. Sie dürfen nicht aus Beispielen anderer Plattformen übernommen werden.

17. Wie wird ein Kabel- oder Portfehler durch einen Vergleichstest eingegrenzt?

Ausgangslage

CLIENT-023 verliert wiederholt den Link.

Kontrollierter Vergleich

Test Geänderter Faktor Ergebnisinterpretation
bekannt funktionierendes Patchkabel Patchkabel Fehler verschwindet: ursprüngliches Kabel verdächtig
anderer freigegebener Switchport Switchport und möglicherweise Konfiguration Fehler verschwindet: Port oder Portkonfiguration prüfen
anderer Client am selben Kabel Endgerät Fehler bleibt: Kabel, Dose oder Port wahrscheinlicher
gleicher Client an anderer Dose Gebäudestrecke und Port Fehler verschwindet: ursprüngliche Strecke prüfen
USB-Adapter statt interner NIC Netzwerkadapter Fehler verschwindet: interne NIC oder Treiber prüfen

Wichtig

[CHANGE][DISRUPT] Kabel- und Portwechsel unterbrechen bestehende Verbindungen.
18. Wie werden Dockingstationen und USB-Netzwerkadapter untersucht?

Zusätzliche mögliche Fehlerstellen:

Notebook
  → USB-C- beziehungsweise Thunderbolt-Port
    → Dockingstation
      → interner Netzwerkadapter
        → RJ45-Port
          → Netzwerkkabel

Zu prüfen sind:

Typische Symptome

Ein Treiber- oder Firmwareupdate sollte nur nach Prüfung von Modell, Hardwareversion, Herstellerdokumentation, Freigabe und Rückweg erfolgen.

19. Wie werden Energieverwaltung und Ruhezustand als Ursache geprüft?

Mögliche Hinweise:

Windows-Einstellungen nur anzeigen

[RO] Get-NetAdapterPowerManagement -Name 'Ethernet'

Windows-Ereignisse des Netzwerkadapters suchen

[RO] Get-WinEvent -LogName System -MaxEvents 1000 |
    Where-Object {
        $_.ProviderName -match 'NDIS|Kernel-PnP|Netwtw|e1d|e2f|Network'
    } |
    Select-Object TimeCreated,
                  Id,
                  ProviderName,
                  LevelDisplayName,
                  Message

Providernamen unterscheiden sich je nach Adapter und Treiber. Der Filter ist deshalb nur eine erste Suche.

Linux

[RO][PRIV] sudo journalctl -b |
    grep -Ei 'suspend|resume|link.*(up|down)|network|firmware'

macOS

[RO] pmset -g log |
    grep -Ei 'sleep|wake'

Energiesparfunktionen sollten nicht dauerhaft deaktiviert werden, solange der Zusammenhang nicht belegt ist.

20. Warum sollten Offloading-Funktionen nicht vorschnell deaktiviert werden?

Netzwerkadapter können bestimmte Aufgaben in Hardware oder Treiber ausführen:

Diese Funktionen können CPU-Last reduzieren und den Durchsatz erhöhen. Gleichzeitig können sie die Darstellung in einem lokalen Paketmitschnitt beeinflussen.

Beispielsweise kann Wireshark auf dem sendenden Host scheinbar ungültige Prüfsummen anzeigen, obwohl die korrekte Prüfsumme erst später vom Netzwerkadapter berechnet wird.

Angezeigter Checksum-Fehler im lokalen Mitschnitt
≠ automatisch beschädigtes Paket im Netzwerk

Vor einer Änderung müssen geprüft werden:

[CHANGE][DISRUPT] Offloading-Funktionen nicht pauschal als
„Problemlösung“ deaktivieren.
21. Wann ist ein Adapterneustart sinnvoll und welches Risiko besteht?

Ein Adapterneustart kann einen vorübergehend fehlerhaften Treiber- oder Gerätezustand beheben. Er beseitigt aber möglicherweise nur das Symptom und zerstört den ursprünglichen Diagnosezustand.

Vorher erfassen

Windows

[PRIV][CHANGE][DISRUPT] Restart-NetAdapter -Name 'Ethernet'

Linux

[PRIV][CHANGE][DISRUPT] sudo ip link set dev eth0 down

[PRIV][CHANGE][DISRUPT] sudo ip link set dev eth0 up

macOS

[PRIV][CHANGE][DISRUPT] sudo ifconfig en0 down

[PRIV][CHANGE][DISRUPT] sudo ifconfig en0 up

Bei einer Remoteverbindung kann der Administrator durch das Deaktivieren der verwendeten Schnittstelle den eigenen Zugriff verlieren. Ein Adapterneustart darf remote nur mit gesichertem alternativem Zugangsweg durchgeführt werden.

22. Welche systematische Prüfungsreihenfolge ist sinnvoll?
Schritt Prüfung
1 betroffene Schnittstelle eindeutig bestimmen
2 Kabel, Stecker, Adapter und Linkanzeige kontrollieren
3 administrativen und operativen Status abfragen
4 ausgehandelte Geschwindigkeit und Duplex prüfen
5 Ausgangswerte der Fehlerzähler dokumentieren
6 Fehler reproduzieren oder definierten Zeitraum beobachten
7 Fehlerzähler erneut abfragen und Differenzen bestimmen
8 Treiber-, Kernel- und Switchprotokolle vergleichen
9 Gegenstelle beziehungsweise Switchport prüfen
10 bekannt funktionierendes Kabel oder Vergleichsgerät verwenden
11 erst danach eine kontrollierte Änderung durchführen
12 ursprüngliches Fehlerbild erneut testen
13 Ergebnis und Rückweg dokumentieren

Merksatz

Ansehen → Status lesen → Zähler vergleichen → Gegenseite prüfen
→ kontrolliert tauschen → erneut messen
23. Kompakte Befehlsübersicht für Windows, Linux und macOS
Aufgabe Windows Linux macOS
Adapterübersicht [RO] Get-NetAdapter [RO] ip -brief link [RO] networksetup -listallhardwareports
physische Adapter [RO] Get-NetAdapter -Physical abhängig vom Gerätetyp über Hardwareportzuordnung
Adapterdetails [RO] Get-NetAdapter -Name 'Ethernet' | Format-List * [RO] ip link show dev eth0 [RO] ifconfig en0
Linkstatus Feld Status [RO] cat /sys/class/net/eth0/carrier Feld status in ifconfig en0
Geschwindigkeit Feld LinkSpeed [RO][PRIV] sudo ethtool eth0 [RO] networksetup -getMedia "Ethernet"
Duplex Adapterdetails beziehungsweise erweiterte Eigenschaften [RO][PRIV] sudo ethtool eth0 Medienausgabe des Adapters
Fehlerzähler [RO] Get-NetAdapterStatistics [RO] ip -s -s link show dev eth0 [RO] netstat -ib -I en0
Treiberinformationen [RO] Get-NetAdapter | Select Name,DriverInformation,DriverVersion [RO][PRIV] sudo ethtool -i eth0 [RO][SENS] system_profiler SPNetworkDataType
Treiberstatistiken [RO] Get-NetAdapterStatistics -Name 'Ethernet' | Format-List * [RO][PRIV] sudo ethtool -S eth0 abhängig vom Adaptertreiber
erweiterte Eigenschaften [RO] Get-NetAdapterAdvancedProperty -Name 'Ethernet' [RO][PRIV] sudo ethtool eth0 abhängig vom Adapter
Energieverwaltung [RO] Get-NetAdapterPowerManagement -Name 'Ethernet' Treiber- und Systemkonfiguration prüfen [RO] pmset -g
Linkereignisse Windows-Systemprotokoll [RO] ip monitor link [RO] log stream --style compact
Kernel-/Treiberlogs Get-WinEvent -LogName System [RO][PRIV] sudo journalctl -k -b [RO] log show --last 1h --style compact
Adapter neu starten [PRIV][CHANGE][DISRUPT] Restart-NetAdapter -Name 'Ethernet' [PRIV][CHANGE][DISRUPT] sudo ip link set eth0 down/up [PRIV][CHANGE][DISRUPT] sudo ifconfig en0 down/up

Die Beispielnamen Ethernet, eth0 und en0 müssen durch die zuvor eindeutig ermittelte Schnittstelle ersetzt werden.

24. Dokumentationsvorlage 
Ticketnummer:
Prüfzeitpunkt:
Zeitzone:
Betroffenes Gerät:
Betriebssystem:
Standort:
Verbindungsart:

SCHNITTSTELLE

Adaptername:
Schnittstellenindex:
Adaptermodell:
MAC-Adresse:
Treiberanbieter:
Treiberversion:
Treiberdatum:
Firmwareversion:
Administrativer Status:
Operativer Status:
Link erkannt: Ja / Nein
Geschwindigkeit:
Duplex:
Autonegotiation:
MTU:
Energy Efficient Ethernet:
Energieverwaltung:

PHYSISCHE STRECKE

Endgeräteport:
Adapter oder Dockingstation:
Patchkabel:
Netzwerkdose:
Patchpanel:
Switch:
Switchport:
VLAN:
Transceivertyp:
Fasertyp:
Linkanzeige Client:
Linkanzeige Switch:

ZÄHLER VORHER

Zeitpunkt:
RX-Pakete:
RX-Bytes:
RX-Fehler:
RX-Drops:
CRC-Fehler:
Framefehler:
TX-Pakete:
TX-Bytes:
TX-Fehler:
TX-Drops:
Kollisionen:
Link-Down-Ereignisse:

ZÄHLER NACHHER

Zeitpunkt:
RX-Pakete:
RX-Bytes:
RX-Fehler:
RX-Drops:
CRC-Fehler:
Framefehler:
TX-Pakete:
TX-Bytes:
TX-Fehler:
TX-Drops:
Kollisionen:
Link-Down-Ereignisse:

DIFFERENZ UND BEWERTUNG

-
-
-

VERGLEICHSTEST

Getauschte Komponente:
Ausgangszustand dokumentiert:
Erwartetes Ergebnis:
Tatsächliches Ergebnis:
Ursprünglicher Zustand wiederhergestellt:

TREIBER- UND SWITCHMELDUNGEN

-
-
-

Arbeitshypothese:
Beleg:
Durchgeführte Änderung:
Rückweg:
Abschlussprüfung:
Ermittelte Ursache:
25. Offizielle Quellen und weiterführende Dokumentation

Microsoft

Linux

Apple

Verfügbare Statistiken und Eigenschaften hängen vom Betriebssystem, Adapter, Treiber, Transceiver und Hersteller ab. Nicht angezeigte Zähler dürfen nicht als Wert null interpretiert werden.

3. Netzwerkfehler systematisch analysieren

3.3 IP-Konfiguration und Subnetz prüfen

Nachdem die physische Verbindung und der Netzwerkadapter geprüft wurden, wird die logische IP-Konfiguration untersucht. Ein aktiver Link reicht nicht aus: Das Endgerät benötigt eine zum Netzwerk passende IPv4- oder IPv6-Adresse, eine korrekte Präfixlänge, geeignete Routen sowie gegebenenfalls ein Standardgateway und DNS-Server.

Grundregel: Die angezeigte IP-Konfiguration muss mit der vorgesehenen Netzwerkdokumentation verglichen werden. Eine formal gültige Adresse kann trotzdem für den konkreten Standort oder das zugewiesene VLAN falsch sein.

1. Welche Angaben gehören zu einer vollständigen IP-Konfiguration?

IPv4

IPv6

Beispieldokumentation

Schnittstelle: Ethernet
MAC-Adresse: 00-11-22-33-44-55
VLAN: 20

IPv4-Adresse: 192.0.2.23
Präfixlänge: /24
Subnetzmaske: 255.255.255.0
Netzwerkadresse: 192.0.2.0
Broadcastadresse: 192.0.2.255
Standardgateway: 192.0.2.1
DNS-Server: 192.0.2.53, 192.0.2.54
Adressquelle: DHCP
2. Welche Symptome sprechen für eine fehlerhafte IP-Konfiguration?
3. Wie wird die IP-Konfiguration unter Windows angezeigt?

Kompakte PowerShell-Übersicht

[RO] Get-NetIPConfiguration

Vollständige klassische Ausgabe

[RO][SENS] ipconfig /all

Die Ausgabe kann Hostname, MAC-Adressen, DNS-Suffixe, DHCP-Server und interne Netzwerkadressen enthalten.

Nur aktive Adapter mit IPv4-Konfiguration

[RO] Get-NetIPConfiguration |
    Where-Object NetAdapter.Status -eq 'Up' |
    Select-Object InterfaceAlias,
                  InterfaceIndex,
                  IPv4Address,
                  IPv4DefaultGateway,
                  DNSServer

Alle IP-Adressen anzeigen

[RO] Get-NetIPAddress |
    Sort-Object InterfaceIndex, AddressFamily, IPAddress |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 AddressFamily,
                 IPAddress,
                 PrefixLength,
                 PrefixOrigin,
                 SuffixOrigin,
                 AddressState

Nur IPv4-Adressen

[RO] Get-NetIPAddress -AddressFamily IPv4 |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 IPAddress,
                 PrefixLength,
                 PrefixOrigin,
                 AddressState

Nur IPv6-Adressen

[RO] Get-NetIPAddress -AddressFamily IPv6 |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 IPAddress,
                 PrefixLength,
                 PrefixOrigin,
                 AddressState

Standardrouten anzeigen

[RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' |
    Sort-Object RouteMetric |
    Format-Table InterfaceAlias,
                 ifIndex,
                 DestinationPrefix,
                 NextHop,
                 RouteMetric,
                 InterfaceMetric

IPv6-Standardrouten:

[RO] Get-NetRoute -DestinationPrefix '::/0' |
    Sort-Object RouteMetric |
    Format-Table InterfaceAlias,
                 ifIndex,
                 DestinationPrefix,
                 NextHop,
                 RouteMetric,
                 InterfaceMetric
4. Wie wird die IP-Konfiguration unter Linux angezeigt?

Kompakte Adressübersicht

[RO] ip -brief address

Ausführliche Adressübersicht

[RO] ip address show

Bestimmte Schnittstelle

[RO] ip address show dev eth0

Nur IPv4

[RO] ip -4 address show

Nur IPv6

[RO] ip -6 address show

IPv4-Routingtabelle

[RO] ip -4 route

IPv6-Routingtabelle

[RO] ip -6 route

Route und ausgewählte Quelladresse zu einem Ziel

[RO] ip route get 198.51.100.20

IPv6:

[RO] ip -6 route get 2001:db8:20::20

NetworkManager-Verbindungen

Falls NetworkManager verwendet wird:

[RO] nmcli connection show

Aktive Verbindungen:

[RO] nmcli connection show --active

Geräteinformationen:

[RO] nmcli device show

systemd-networkd

Falls systemd-networkd verwendet wird:

[RO] networkctl status

[RO] networkctl status eth0

Nicht jede Linux-Installation verwendet NetworkManager oder systemd-networkd. Zuerst muss bestimmt werden, welche Komponente die Netzwerkkonfiguration verwaltet.

5. Wie wird die IP-Konfiguration unter macOS angezeigt?

Hardwareports und Gerätenamen

[RO] networksetup -listallhardwareports

Alle Schnittstellen

[RO] ifconfig

Bestimmte Schnittstelle

[RO] ifconfig en0

IPv4-Konfiguration eines Netzwerkdienstes

[RO] networksetup -getinfo "Ethernet"

Der tatsächliche Dienstname muss vorher ermittelt werden:

[RO] networksetup -listallnetworkservices

IPv4-Konfigurationsmethode

[RO] networksetup -getinfo "Wi-Fi"

DNS-Konfiguration

[RO][SENS] scutil --dns

IPv4-Routingtabelle

[RO] netstat -rn -f inet

IPv6-Routingtabelle

[RO] netstat -rn -f inet6

Ausgewählte Route zu einem IPv4-Ziel

[RO] route -n get 198.51.100.20

Ausgewählte Route zu einem IPv6-Ziel

[RO] route -n get -inet6 2001:db8:20::20

Die Dienstbezeichnung Ethernet oder Wi-Fi darf nicht ungeprüft übernommen werden. Sie kann auf einem konkreten Mac anders benannt sein.

6. Wie wird eine IPv4-Adresse einem Subnetz zugeordnet?

Beispiel

IPv4-Adresse: 192.0.2.23
Präfix:        /24
Subnetzmaske:  255.255.255.0

Daraus ergibt sich:

Bestandteil Wert
Netzwerkadresse 192.0.2.0
erster typischer Host 192.0.2.1
letzter typischer Host 192.0.2.254
Broadcastadresse 192.0.2.255
Gesamtzahl Adressen 256
klassisch nutzbare Hostadressen 254

Vergleich zweier Ziele

Client: 192.0.2.23/24
Ziel A: 192.0.2.80
Ziel B: 198.51.100.20

Wichtig

Die erste und letzte Adresse eines Subnetzes werden bei klassischer IPv4-Subnetznutzung als Netzwerk- und Broadcastadresse verwendet. Sonderfälle wie /31 für Punkt-zu-Punkt-Verbindungen und /32 für einzelne Hostrouten müssen gesondert betrachtet werden.

7. Wie werden Präfixlänge und Subnetzmaske umgerechnet?
Präfix Subnetzmaske Adressen insgesamt klassisch nutzbare Hosts
/16 255.255.0.0 65.536 65.534
/17 255.255.128.0 32.768 32.766
/18 255.255.192.0 16.384 16.382
/19 255.255.224.0 8.192 8.190
/20 255.255.240.0 4.096 4.094
/21 255.255.248.0 2.048 2.046
/22 255.255.252.0 1.024 1.022
/23 255.255.254.0 512 510
/24 255.255.255.0 256 254
/25 255.255.255.128 128 126
/26 255.255.255.192 64 62
/27 255.255.255.224 32 30
/28 255.255.255.240 16 14
/29 255.255.255.248 8 6
/30 255.255.255.252 4 2
/31 255.255.255.254 2 Sonderfall für Punkt-zu-Punkt
/32 255.255.255.255 1 einzelne Hostadresse

Berechnung der Gesamtzahl

2 hoch (32 − Präfixlänge)

Beispiel /27:

2 hoch (32 − 27)
= 2 hoch 5
= 32 Adressen

Für gewöhnliche IPv4-Subnetze werden Netzwerk- und Broadcastadresse abgezogen:

32 − 2 = 30 klassische Hostadressen
8. Wie wird eine falsche Subnetzmaske erkannt?

Vorgesehene Konfiguration

Client: 192.0.2.130/25
Gateway: 192.0.2.129

Das vorgesehene Subnetz lautet:

192.0.2.128/25

Adressbereich:

192.0.2.128 bis 192.0.2.255

Fehlerhafte Konfiguration

Client: 192.0.2.130/24

Der Client hält nun den gesamten Bereich 192.0.2.0/24 für lokal. Ein Ziel wie 192.0.2.50 wird deshalb direkt per ARP gesucht, obwohl es nach der vorgesehenen Netzplanung in einem anderen Subnetz liegen kann.

Mögliche Symptome

Die Präfixlänge muss mit DHCP-Konfiguration, VLAN-Plan und Referenzsystemen verglichen werden.

9. Was bedeutet eine IPv4-Adresse aus 169.254.0.0/16?

Windows und andere Betriebssysteme können eine IPv4-Link-Local-Adresse aus folgendem Bereich verwenden:

169.254.0.0/16

Unter Windows wird dies häufig als APIPA bezeichnet.

Beispiel:

169.254.73.22/16

Das ist ein Hinweis darauf, dass keine reguläre IPv4-Konfiguration vorliegt beziehungsweise keine gewünschte DHCP-Konfiguration bezogen werden konnte. Die Adresse ermöglicht nur eingeschränkte lokale Kommunikation mit kompatibel konfigurierten Geräten im selben Link-Local-Bereich.

Mögliche Ursachen

Windows-Prüfung

[RO] Get-NetIPAddress -AddressFamily IPv4 |
    Where-Object IPAddress -Like '169.254.*'

Linux-Prüfung

[RO] ip -4 address show |
    grep '169\.254\.'

macOS-Prüfung

[RO] ifconfig |
    grep '169\.254\.'

Eine Link-Local-Adresse sollte nicht durch eine willkürlich gewählte statische Adresse ersetzt werden. Zuerst muss die vorgesehene Adressvergabe geklärt werden.

10. Welche besonderen IPv4-Adressbereiche müssen erkannt werden?
Bereich Zweck
0.0.0.0 nicht spezifizierte IPv4-Adresse
0.0.0.0/0 Standardroute beziehungsweise alle IPv4-Ziele
127.0.0.0/8 Loopback
169.254.0.0/16 IPv4 Link-Local
10.0.0.0/8 privater IPv4-Adressraum
172.16.0.0/12 privater IPv4-Adressraum
192.168.0.0/16 privater IPv4-Adressraum
100.64.0.0/10 Shared Address Space, häufig für Carrier-Grade NAT
224.0.0.0/4 Multicast
255.255.255.255 Limited Broadcast

Die in diesem Buch verwendeten Bereiche 192.0.2.0/24, 198.51.100.0/24 und 203.0.113.0/24 sind für Dokumentationsbeispiele vorgesehen und sollten nicht als produktive Adressplanung übernommen werden.

11. Wie werden Standardgateway und lokale Erreichbarkeit geprüft?

Zuerst muss das konfigurierte Gateway ausgelesen werden. Es darf nicht angenommen werden, dass es immer auf .1 endet.

Windows

[RO] Get-NetIPConfiguration |
    Select-Object InterfaceAlias,
                  IPv4Address,
                  IPv4DefaultGateway

Gateway testen:

[TEST] Test-Connection 192.0.2.1 -Count 4

Linux

[RO] ip route show default

Gateway testen:

[TEST] ping -c 4 192.0.2.1

macOS

[RO] route -n get default

Gateway testen:

[TEST] ping -c 4 192.0.2.1

Interpretation

Ergebnis Aussage
Gateway antwortet ICMP-Kommunikation zum Gateway funktioniert
Gateway antwortet nicht keine ICMP-Antwort; Ursache noch offen
Nachbartabelle enthält Gateway Layer-2-Zuordnung wurde ermittelt
keine Nachbarzuordnung VLAN-, ARP-, NDP- oder Linkproblem möglich
andere Clients erreichen Gateway clientbezogene Ursache wahrscheinlicher
Gateway blockiert ICMP Ping ist als Nachweis ungeeignet

Ein fehlgeschlagener Ping beweist nicht, dass das Gateway vollständig unerreichbar ist. Manche Gateways beantworten ICMP nicht oder nur eingeschränkt.

12. Wie wird erkannt, welche Quelladresse für ein Ziel verwendet wird?

Bei mehreren Adressen und Schnittstellen ist nicht automatisch die erwartete Quelladresse aktiv.

Windows

[RO] Find-NetRoute -RemoteIPAddress 198.51.100.20

Die Ausgabe zeigt unter anderem:

Linux

[RO] ip route get 198.51.100.20

Beispiel:

198.51.100.20 via 192.0.2.1 dev eth0 src 192.0.2.23

macOS

[RO] route -n get 198.51.100.20

Zu kontrollieren sind:

Feld Prüffrage
Interface Wird der erwartete Adapter verwendet?
Source Wird die richtige Quelladresse gewählt?
Gateway Wird der erwartete Router verwendet?
Route Ist das Ziel als lokal, spezifisch oder über Default geroutet?
Metrik Gibt es eine bevorzugte konkurrierende Route?

Eine unerwartete Quelladresse kann zu Firewall-, Rückweg-, NAT- oder Berechtigungsproblemen führen.

13. Wie werden mehrere Standardgateways bewertet?

Mehrere Standardrouten können beabsichtigt sein, beispielsweise bei:

Sie können aber auch zu unerwarteten Wegen führen.

Windows

[RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' |
    Sort-Object RouteMetric, InterfaceMetric

Linux

[RO] ip route show default

[RO] ip rule show

macOS

[RO] netstat -rn -f inet |
    grep '^default'

Zu prüfen

Längstes passendes Präfix hat grundsätzlich Vorrang vor einer weniger
spezifischen Route. Die Metrik entscheidet erst zwischen geeigneten
konkurrierenden Routen nach den Regeln des jeweiligen Betriebssystems.
14. Wie werden IPv6-Adressen unterschieden?
IPv6-Typ Typischer Bereich beziehungsweise Merkmal Zweck
Unspecified :: keine bestimmte Adresse
Loopback ::1 lokaler Host
Link-Local fe80::/10 Kommunikation auf dem lokalen Link
Unique Local fc00::/7 interne IPv6-Adressierung
Global Unicast typischerweise aus 2000::/3 global routbare Kommunikation
Multicast ff00::/8 Gruppenkommunikation

Link-Local-Adresse

Beispiel:

fe80::1234:5678:9abc:def0%12

Die Scope-ID %12 beziehungsweise ein Interfacebezug ist erforderlich, weil derselbe Link-Local-Bereich auf mehreren Schnittstellen existieren kann.

Windows

[RO] Get-NetIPAddress -AddressFamily IPv6 |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 IPAddress,
                 PrefixLength,
                 AddressState,
                 PrefixOrigin,
                 SuffixOrigin

Linux

[RO] ip -6 address show

macOS

[RO] ifconfig |
    grep -E '^[a-z0-9]+:|inet6'

Eine vorhandene Link-Local-Adresse beweist nicht, dass globales oder standortübergreifendes IPv6-Routing funktioniert.

15. Was bedeuten bevorzugte, veraltete und vorläufige Adresszustände?

Eine IP-Adresse kann vorhanden sein, aber noch nicht vollständig verwendbar sein.

Windows-Feld AddressState

Zustand Bedeutung
Tentative Prüfung auf Adresskonflikt noch nicht abgeschlossen
Duplicate doppelte Adresse erkannt
Deprecated Adresse soll nicht mehr für neue Verbindungen bevorzugt werden
Preferred Adresse kann normal verwendet werden
Invalid Adresse ist nicht gültig

Linux-Ausgabe kann unter anderem zeigen

Kennzeichnung Bedeutung
tentative Duplicate Address Detection läuft
dadfailed Duplicate Address Detection ist fehlgeschlagen
deprecated Adresse wird für neue Verbindungen nicht bevorzugt
temporary temporäre IPv6-Adresse
dynamic dynamisch zugewiesen

Prüfung unter Linux

[RO] ip address show

Eine Adresse im Zustand Duplicate oder dadfailed darf nicht als normal funktionsfähig betrachtet werden.

16. Wie wird ein IP-Adresskonflikt erkannt?

Mögliche Symptome:

Windows

[RO] Get-NetIPAddress |
    Where-Object AddressState -ne 'Preferred' |
    Format-Table InterfaceAlias,
                 IPAddress,
                 AddressFamily,
                 AddressState

Systemereignisse untersuchen:

[RO] Get-WinEvent -LogName System -MaxEvents 1000 |
    Where-Object {
        $_.Message -match 'duplicate|conflict|Adressenkonflikt'
    } |
    Select-Object TimeCreated,
                  Id,
                  ProviderName,
                  Message

Linux

[RO] ip address show |
    grep -E 'tentative|dadfailed|deprecated'

Kernel- und Netzwerkprotokolle:

[RO][PRIV] sudo journalctl -b |
    grep -Ei 'duplicate|conflict|dadfailed'

macOS

[RO] log show --last 1h --style compact \
    --predicate 'eventMessage CONTAINS[c] "duplicate" OR eventMessage CONTAINS[c] "conflict"'

Wichtig

Das absichtliche Senden von ARP-Probes mit zusätzlichen Werkzeugen ist ein aktiver Test und kann Sicherheitsüberwachung auslösen. Solche Werkzeuge dürfen nur im autorisierten Netz eingesetzt werden.

Bei einem bestätigten Konflikt müssen DHCP-Leases, statische Zuweisungen, Reservierungen, Dokumentation und die MAC-Adressen beider Geräte geprüft werden.

17. Wie werden DNS-Server innerhalb der IP-Konfiguration geprüft?

An dieser Stelle wird nur geprüft, welche DNS-Server konfiguriert sind. Die eigentliche DNS-Fehleranalyse erfolgt auf Seite 3.8.

Windows

[RO] Get-DnsClientServerAddress |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 AddressFamily,
                 ServerAddresses

Linux mit systemd-resolved

[RO] resolvectl status

Klassische Resolverdatei:

[RO] cat /etc/resolv.conf

Die Datei /etc/resolv.conf kann automatisch generiert oder ein symbolischer Link sein:

[RO] ls -l /etc/resolv.conf

macOS

[RO][SENS] scutil --dns

Dienstbezogene DNS-Server:

[RO] networksetup -getdnsservers "Wi-Fi"

Zu prüfen

Ein Eintrag in der Konfiguration beweist noch nicht, dass der DNS-Server erreichbar ist oder korrekte Antworten liefert.

18. Wie wird DHCP von statischer Adressierung unterschieden?

Windows

[RO] Get-NetIPInterface -AddressFamily IPv4 |
    Select-Object InterfaceAlias,
                  InterfaceIndex,
                  Dhcp,
                  ConnectionState

Adressursprung:

[RO] Get-NetIPAddress -AddressFamily IPv4 |
    Select-Object InterfaceAlias,
                  IPAddress,
                  PrefixLength,
                  PrefixOrigin,
                  SuffixOrigin

Vollständige Leaseinformationen:

[RO][SENS] ipconfig /all

Linux mit NetworkManager

[RO] nmcli device show

Verbindungsprofil:

[RO][SENS] nmcli connection show

Die genaue Verbindung kann anschließend gezielt abgefragt werden:

[RO][SENS] nmcli connection show "VERBINDUNGSNAME"

macOS

[RO] networksetup -getinfo "Ethernet"

Mögliche Zustände

Zustand Bewertung
DHCP vorgesehen und DHCP aktiv grundsätzlich passend
DHCP vorgesehen, aber statische Adresse Fehlkonfiguration möglich
statische Adresse vorgesehen, aber DHCP aktiv falsche Adresse möglich
DHCP-Adresse aus falschem Subnetz falsches VLAN oder falscher DHCP-Server möglich
DHCP-Lease abgelaufen Erneuerung und DHCP-Erreichbarkeit prüfen
Link-Local-Adresse reguläre DHCP-Konfiguration vermutlich nicht erhalten

Die detaillierte DHCP-Analyse folgt auf Seite 3.4.

19. Welche lokalen Tests sind nach der Konfigurationsprüfung sinnvoll?

Die Adressen müssen durch die tatsächlichen Werte des untersuchten Systems ersetzt werden.

Reihenfolge Test Aussage
1 Loopback testen lokaler TCP/IP-Stack reagiert
2 eigene Adresse testen eigene konfigurierte Adresse reagiert lokal
3 Gateway testen Kommunikation bis zum lokalen Router
4 Ziel im selben Subnetz testen lokale Layer-2-Kommunikation
5 entferntes Ziel per IP testen Routing grundsätzlich möglich
6 Ziel per Name testen Namensauflösung zusätzlich beteiligt

Windows

[TEST] Test-Connection 127.0.0.1 -Count 4

[TEST] Test-Connection 192.0.2.23 -Count 4

[TEST] Test-Connection 192.0.2.1 -Count 4

Linux und macOS

[TEST] ping -c 4 127.0.0.1

[TEST] ping -c 4 192.0.2.23

[TEST] ping -c 4 192.0.2.1

IPv6-Loopback

Windows:

[TEST] Test-Connection ::1 -Count 4

Linux und macOS:

[TEST] ping -c 4 ::1

Ein erfolgreicher Test zur eigenen IP-Adresse durchläuft nicht zwangsläufig den vollständigen physischen Netzwerkweg.

20. Warum sollten IP-Einstellungen nicht vorschnell verändert werden?

Mögliche Risiken:

Vor jeder Änderung sichern

Windows

[RO][FILE][SENS] Get-NetIPConfiguration |
    Format-List * |
    Out-File 'C:\Temp\NetIPConfiguration-vorher.txt'

[RO][FILE][SENS] Get-NetIPAddress |
    Format-List * |
    Out-File 'C:\Temp\NetIPAddress-vorher.txt'

[RO][FILE][SENS] Get-NetRoute |
    Format-Table -AutoSize |
    Out-File 'C:\Temp\NetRoute-vorher.txt' -Width 300

Linux

[RO][FILE][SENS] ip address show > /tmp/ip-address-vorher.txt

[RO][FILE][SENS] ip route show table all > /tmp/ip-route-vorher.txt

macOS

[RO][FILE][SENS] ifconfig > /tmp/ifconfig-vorher.txt

[RO][FILE][SENS] netstat -rn > /tmp/netstat-route-vorher.txt

Die verwendeten Speicherorte müssen zur betrieblichen Umgebung und deren Datenschutzvorgaben passen.

21. Welche eingreifenden Befehle existieren und warum sind sie riskant?

Windows – DHCP-Lease freigeben

[PRIV][CHANGE][DISRUPT] ipconfig /release

Lease erneut anfordern:

[PRIV][CHANGE][DISRUPT] ipconfig /renew

Linux mit NetworkManager – Verbindung neu aktivieren

[PRIV][CHANGE][DISRUPT] sudo nmcli connection down "VERBINDUNGSNAME"

[PRIV][CHANGE][DISRUPT] sudo nmcli connection up "VERBINDUNGSNAME"

macOS – DHCP-Lease erneuern

[PRIV][CHANGE][DISRUPT] sudo ipconfig set en0 DHCP

Der macOS-Befehl setzt die betreffende Schnittstelle auf DHCP und ist deshalb nicht für ein System geeignet, das statisch konfiguriert sein soll.

Diese Befehle dürfen erst verwendet werden, nachdem die vorhandene Konfiguration, der vorgesehene Adressierungsmodus und ein Rückweg dokumentiert wurden. Bei einer Remoteverbindung kann der eigene Zugriff sofort verloren gehen.

22. Wie wird eine Referenzkonfiguration verglichen?

Ein funktionierendes Vergleichssystem sollte möglichst folgende Merkmale teilen:

Vergleichstabelle

Eigenschaft Betroffener Client Referenzclient Bewertung
VLAN 20 20 gleich
IPv4-Adresse 192.0.2.23 192.0.2.24 plausibel
Präfix /24 /24 gleich
Gateway 192.0.2.1 192.0.2.1 gleich
DNS 1 192.0.2.53 192.0.2.53 gleich
DNS 2 fehlt 192.0.2.54 Abweichung
DHCP aktiv aktiv gleich
IPv6 nur Link-Local globale Adresse Abweichung
Standardroute Ethernet Ethernet gleich
VPN-Route vorhanden nicht vorhanden relevante Abweichung

Eine Abweichung ist zunächst ein Untersuchungshinweis. Sie ist erst dann eine belegte Ursache, wenn sie zum Fehlerbild passt und durch einen kontrollierten Test bestätigt wird.

23. Welche typischen Fehlinterpretationen müssen vermieden werden?
Beobachtung Falscher Schluss Richtige Einordnung
IP-Adresse ist vorhanden Konfiguration ist korrekt Subnetz, Gateway und Adressquelle vergleichen
Adresse beginnt mit 192.168 Adresse gehört zum richtigen Netz privater Bereich umfasst viele unterschiedliche Netze
Gateway endet auf .1 Gateway ist automatisch korrekt vorgesehenes Gateway dokumentiert prüfen
169.254.x.x ist vorhanden Netzwerkkarte ist defekt reguläre IPv4-Konfiguration fehlt vermutlich
Ping zur eigenen IP funktioniert Netzwerkkabel funktioniert Test kann lokal beantwortet werden
Gateway antwortet nicht Gateway ist ausgefallen ICMP kann blockiert sein
mehrere Adressen vorhanden zwingend Fehlkonfiguration bei IPv6 und mehreren Interfaces normal möglich
IPv6 ist vorhanden IPv6-Internet funktioniert Link-Local-Adresse reicht dafür nicht
DNS-Server ist eingetragen DNS funktioniert Erreichbarkeit und Antwort separat prüfen
DHCP ist aktiviert korrekte Lease wurde empfangen Leasewerte und DHCP-Server prüfen
/24 sieht üblich aus Präfix ist korrekt Netzplan und Referenzsystem vergleichen
eine Default Route existiert richtiger Weg wird verwendet spezifischere Routen und Metriken prüfen
24. Wie sieht der systematische Prüfablauf aus?
Schritt Prüfung
1 tatsächlich verwendete Schnittstelle bestimmen
2 vollständige IPv4- und IPv6-Konfiguration erfassen
3 Adressquelle DHCP, statisch, SLAAC oder andere bestimmen
4 Adresse und Präfix mit dem Netzplan vergleichen
5 Netzwerk- und Broadcastadresse bei IPv4 bestimmen
6 Gateway und DNS-Server vergleichen
7 Adresszustand auf Duplicate, Tentative oder Deprecated prüfen
8 Standardrouten und spezifische Routen untersuchen
9 ausgewählte Route und Quelladresse zum Ziel prüfen
10 Loopback, eigene Adresse und Gateway kontrolliert testen
11 mit funktionierendem Referenzclient vergleichen
12 erst danach DHCP, ARP/NDP oder Routing vertieft untersuchen
13 Änderungen nur mit Sicherung und Rückweg durchführen
14 Ergebnis dokumentieren

Merksatz

Schnittstelle → Adresse → Präfix → Gateway → DNS
→ Route → Quelladresse → Vergleich
25. Kompakte Befehlsübersicht für Windows, Linux und macOS
Aufgabe Windows Linux macOS
vollständige Konfiguration [RO][SENS] ipconfig /all [RO] ip address show [RO] ifconfig
kompakte Übersicht [RO] Get-NetIPConfiguration [RO] ip -brief address [RO] networksetup -getinfo "DIENST"
IPv4-Adressen [RO] Get-NetIPAddress -AddressFamily IPv4 [RO] ip -4 address [RO] ifconfig
IPv6-Adressen [RO] Get-NetIPAddress -AddressFamily IPv6 [RO] ip -6 address [RO] ifconfig
IPv4-Routen [RO] Get-NetRoute -AddressFamily IPv4 [RO] ip -4 route [RO] netstat -rn -f inet
IPv6-Routen [RO] Get-NetRoute -AddressFamily IPv6 [RO] ip -6 route [RO] netstat -rn -f inet6
Standardroute IPv4 [RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' [RO] ip route show default [RO] route -n get default
Route zu Ziel [RO] Find-NetRoute -RemoteIPAddress ZIEL-IP [RO] ip route get ZIEL-IP [RO] route -n get ZIEL-IP
DNS-Server [RO] Get-DnsClientServerAddress [RO] resolvectl status [RO][SENS] scutil --dns
DHCP-Status [RO] Get-NetIPInterface -AddressFamily IPv4 [RO] nmcli device show [RO] networksetup -getinfo "DIENST"
Loopback testen [TEST] Test-Connection 127.0.0.1 -Count 4 [TEST] ping -c 4 127.0.0.1 [TEST] ping -c 4 127.0.0.1
Gateway testen [TEST] Test-Connection GATEWAY -Count 4 [TEST] ping -c 4 GATEWAY [TEST] ping -c 4 GATEWAY
Lease freigeben [PRIV][CHANGE][DISRUPT] ipconfig /release abhängig vom Netzwerkmanager nicht direkt gleichwertig
Lease erneuern [PRIV][CHANGE][DISRUPT] ipconfig /renew abhängig vom Netzwerkmanager [PRIV][CHANGE][DISRUPT] sudo ipconfig set INTERFACE DHCP

Die Platzhalter DIENST, INTERFACE, GATEWAY und ZIEL-IP müssen durch zuvor eindeutig ermittelte Werte ersetzt werden.

26. Dokumentationsvorlage 
Ticketnummer:
Prüfzeitpunkt:
Zeitzone:
Betroffenes Gerät:
Betriebssystem:
Benutzer:
Standort:
VLAN:
Verbindungsart:

SCHNITTSTELLE

Schnittstellenname:
Schnittstellenindex:
MAC-Adresse:
Status:
Linkgeschwindigkeit:
MTU:

IPV4

IPv4-Adresse:
Präfixlänge:
Subnetzmaske:
Netzwerkadresse:
Broadcastadresse:
Adresszustand:
Adressquelle:
DHCP aktiviert:
DHCP-Server:
Leasebeginn:
Leaseende:
Standardgateway:
DNS-Server:
Ausgewählte Quelladresse zum Ziel:
Ausgewählte Route:
Next Hop:

IPV6

Link-Local-Adresse:
Globale beziehungsweise interne IPv6-Adresse:
Präfixlänge:
Adresszustand:
Adressquelle:
Standardrouter:
DNS-Server:
Ausgewählte Quelladresse zum Ziel:
Ausgewählte Route:
Next Hop:

LOKALE TESTS

Loopback IPv4:
Loopback IPv6:
Eigene IPv4-Adresse:
Eigene IPv6-Adresse:
IPv4-Gateway:
IPv6-Router:
Ziel im lokalen Subnetz:
Entferntes Ziel per IP:

REFERENZVERGLEICH

Referenzgerät:
Gleiches VLAN:
IPv4-Präfix:
Gateway:
DNS-Server:
Adressquelle:
Relevante Abweichungen:

AUFFÄLLIGKEITEN

-
-
-

Arbeitshypothese:
Nächster Prüfschritt:
Gesicherter Ausgangszustand:
Durchgeführte Änderung:
Rückweg:
Abschlussprüfung:
Ermittelte Ursache:
27. Offizielle Quellen und weiterführende Dokumentation

Microsoft

Linux

Apple

Standards

Adressen, Präfixe, Gateways und DNS-Server müssen immer mit der tatsächlichen Netzwerkdokumentation verglichen werden. Die Beispielwerte auf dieser Seite sind keine Vorgabe für produktive Netze.

3. Netzwerkfehler systematisch analysieren

3.4 DHCP-Fehler analysieren

DHCP stellt Clients automatisch Netzwerkparameter zur Verfügung. Dazu gehören typischerweise IP-Adresse, Präfix beziehungsweise Subnetzmaske, Standardgateway, DNS-Server, DNS-Suchdomäne und Lease-Dauer.

Eine erfolgreiche DHCP-Zuweisung beweist jedoch nicht automatisch, dass alle übermittelten Parameter korrekt sind. Ein Client kann eine technisch gültige Adresse aus dem falschen Subnetz oder von einem nicht vorgesehenen DHCP-Server erhalten.

Grundregel: Zuerst die vorhandene Lease und deren Herkunft dokumentieren. Erst danach darf eine Freigabe oder Erneuerung durchgeführt werden.

1. Welche Symptome sprechen für ein DHCP-Problem?
2. Welche Informationen müssen vor einer Veränderung erfasst werden?
Information Beispiel
Clienthostname CLIENT-023
MAC-Adresse 00-11-22-33-44-55
Schnittstelle Ethernet
VLAN 20
aktuelle IPv4-Adresse 192.0.2.23
Präfix beziehungsweise Maske /24 beziehungsweise 255.255.255.0
Standardgateway 192.0.2.1
DNS-Server 192.0.2.53, 192.0.2.54
DHCP aktiviert Ja
DHCP-Server 192.0.2.10
Lease erhalten 2026-07-31 08:00 CEST
Lease läuft ab 2026-08-01 08:00 CEST
erwarteter DHCP-Bereich 192.0.2.20–192.0.2.200
Fehlerbeginn 2026-07-31 09:42 CEST

Vor einer Lease-Erneuerung sollten zusätzlich gespeichert werden:

3. Wie funktioniert DHCPv4 grundsätzlich?

Der klassische erstmalige DHCPv4-Ablauf wird häufig als DORA bezeichnet:

Client                                   DHCP-Server
  │                                           │
  │──── DHCPDISCOVER ────────────────────────>│
  │<─── DHCPOFFER ────────────────────────────│
  │──── DHCPREQUEST ─────────────────────────>│
  │<─── DHCPACK ──────────────────────────────│
  │                                           │
Nachricht Absender Bedeutung
DHCPDISCOVER Client sucht verfügbare DHCP-Server
DHCPOFFER Server bietet Adresse und Parameter an
DHCPREQUEST Client fordert ein bestimmtes Angebot an
DHCPACK Server bestätigt die Lease
DHCPNAK Server lehnt angeforderte Konfiguration ab
DHCPDECLINE Client meldet angebotene Adresse als problematisch
DHCPRELEASE Client gibt eine Lease frei
DHCPINFORM Client fordert Optionen an, ohne eine neue Adresse zu beziehen

DHCPv4 verwendet grundsätzlich:

Richtung UDP-Port
Server 67
Client 68

Die erste Kommunikation erfolgt häufig per Broadcast, weil der Client zunächst noch keine reguläre IPv4-Adresse und keinen bekannten DHCP-Server besitzt.

4. Wie wird eine bestehende DHCP-Konfiguration unter Windows geprüft?

Vollständige Konfiguration

[RO][SENS] ipconfig /all

Zu prüfen sind insbesondere:

DHCP aktiviert
IPv4-Adresse
Subnetzmaske
Lease erhalten
Lease läuft ab
Standardgateway
DHCP-Server
DNS-Server
Verbindungsspezifisches DNS-Suffix

DHCP-Status der Schnittstellen

[RO] Get-NetIPInterface -AddressFamily IPv4 |
    Select-Object InterfaceAlias,
                  InterfaceIndex,
                  Dhcp,
                  ConnectionState,
                  InterfaceMetric

Adressursprung

[RO] Get-NetIPAddress -AddressFamily IPv4 |
    Select-Object InterfaceAlias,
                  InterfaceIndex,
                  IPAddress,
                  PrefixLength,
                  PrefixOrigin,
                  SuffixOrigin,
                  AddressState

Konfiguration sichern

[RO][FILE][SENS] ipconfig /all |
    Out-File 'C:\Temp\ipconfig-vor-dhcp-test.txt'

[RO][FILE][SENS] Get-NetIPConfiguration |
    Format-List * |
    Out-File 'C:\Temp\netipconfig-vor-dhcp-test.txt'

Die Verzeichnisse müssen vorhanden und für Diagnoseinformationen freigegeben sein.

5. Wie werden DHCP-Clientereignisse unter Windows gelesen?

Verfügbare DHCP-bezogene Protokolle suchen

[RO] Get-WinEvent -ListLog '*DHCP*' |
    Select-Object LogName,
                  IsEnabled,
                  RecordCount

Je nach Windows-Version und aktivierten Kanälen können unter anderem DHCP-Client-Protokolle unter folgendem Bereich vorhanden sein:

Anwendungs- und Dienstprotokolle
→ Microsoft
  → Windows
    → Dhcp-Client

Aktivierte DHCP-Protokolle auslesen

[RO] Get-WinEvent -ListLog '*DHCP*' |
    Where-Object {
        $_.IsEnabled -and $_.RecordCount -gt 0
    } |
    ForEach-Object {
        Get-WinEvent -LogName $_.LogName -MaxEvents 50 -ErrorAction SilentlyContinue
    } |
    Sort-Object TimeCreated -Descending |
    Select-Object TimeCreated,
                  LogName,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  Message

Systemprotokoll nach DHCP-Meldungen durchsuchen

[RO] Get-WinEvent -LogName System -MaxEvents 1000 |
    Where-Object {
        $_.ProviderName -Match 'Dhcp' -or
        $_.Message -Match 'DHCP'
    } |
    Sort-Object TimeCreated -Descending |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  Message

Protokollname, Provider und Ereignis-ID können sich zwischen Windows-Versionen unterscheiden. Deshalb sollte zuerst mit Get-WinEvent -ListLog '*DHCP*' geprüft werden, welche Kanäle tatsächlich vorhanden sind.

6. Wie wird eine bestehende DHCP-Konfiguration unter Linux geprüft?

Grundlegende IP-Konfiguration

[RO] ip -4 address

[RO] ip -4 route

Mit NetworkManager

Gerätestatus:

[RO] nmcli device status

Ausführliche Gerätedaten:

[RO][SENS] nmcli device show eth0

Aktive Verbindungen:

[RO] nmcli connection show --active

Verbindungsprofil:

[RO][SENS] nmcli connection show "VERBINDUNGSNAME"

Zu prüfen sind insbesondere Eigenschaften wie:

Die tatsächlich verfügbaren Felder hängen von NetworkManager-Version und Backend ab.

Mit systemd-networkd

[RO] networkctl status eth0

[RO] networkctl status --all

Lease-Dateien

Speicherort und Format von Lease-Dateien hängen von Distribution und Netzwerkmanager ab. Es sollte nicht von einem festen Pfad ausgegangen werden. Vorhandene Dateien können gesucht werden, ohne sie zu verändern:

[RO][PRIV][SENS] sudo find /run /var/lib \
    -maxdepth 4 \
    -type f \
    \( -iname '*lease*' -o -iname '*dhcp*' \) \
    2>/dev/null

Gefundene Dateien dürfen nicht gelöscht oder verändert werden, bevor Netzwerkmanager und Zweck eindeutig bestimmt wurden.

7. Wie werden DHCP-Clientprotokolle unter Linux geprüft?

NetworkManager

[RO][PRIV] sudo journalctl -b -u NetworkManager

Nach DHCP-Meldungen filtern:

[RO][PRIV] sudo journalctl -b -u NetworkManager |
    grep -Ei 'dhcp|lease|offer|request|ack|nak|timeout'

systemd-networkd

[RO][PRIV] sudo journalctl -b -u systemd-networkd

Nach DHCP-Meldungen filtern:

[RO][PRIV] sudo journalctl -b -u systemd-networkd |
    grep -Ei 'dhcp|lease|offer|request|ack|nak|timeout'

Allgemeine Protokollsuche

[RO][PRIV] sudo journalctl -b |
    grep -Ei 'dhcp|lease|dhclient|NetworkManager|systemd-networkd'

Kernelmeldungen zur Schnittstelle

[RO][PRIV] sudo journalctl -k -b |
    grep -E 'eth0|link.*(up|down)|carrier'

Vor der Interpretation muss bekannt sein, welcher Dienst die Schnittstelle verwaltet. Meldungen eines installierten, aber nicht verwendeten DHCP-Clients sind möglicherweise irrelevant.

8. Wie wird eine bestehende DHCP-Konfiguration unter macOS geprüft?

Netzwerkdienste auflisten

[RO] networksetup -listallnetworkservices

Hardwareports zuordnen

[RO] networksetup -listallhardwareports

Konfiguration eines Dienstes

[RO] networksetup -getinfo "Ethernet"

DHCP-Paketinformationen einer Schnittstelle

[RO][SENS] ipconfig getpacket en0

Diese Ausgabe kann unter anderem enthalten:

Nur die aktuelle IPv4-Adresse

[RO] ipconfig getifaddr en0

DNS-Konfiguration

[RO][SENS] scutil --dns

Systemprotokolle nach DHCP durchsuchen

[RO] log show \
    --last 1h \
    --style compact \
    --predicate 'process == "bootp" OR eventMessage CONTAINS[c] "DHCP"'

Je nach macOS-Version können Prozessname, Subsystem und verfügbare Meldungen abweichen. Eine leere Ausgabe beweist nicht, dass kein DHCP-Vorgang stattgefunden hat.

9. Wie wird geprüft, ob der Client überhaupt DHCP verwendet?

Ein Client kann eine statische Adresse besitzen und deshalb keine reguläre DHCP-Lease anfordern.

Windows

[RO] Get-NetIPInterface -AddressFamily IPv4 |
    Select-Object InterfaceAlias,
                  Dhcp,
                  ConnectionState

Linux mit NetworkManager

[RO] nmcli connection show "VERBINDUNGSNAME" |
    grep -E '^ipv4\.method'

Typische Werte:

Wert Bedeutung
auto automatische IPv4-Konfiguration, typischerweise DHCP
manual statische Konfiguration
disabled IPv4 deaktiviert
shared geteilte Verbindung mit eigener Adressbereitstellung

macOS

[RO] networksetup -getinfo "Ethernet"

Die Ausgabe zeigt die verwendete Konfigurationsmethode.

Prüffragen

10. Wie wird eine DHCPv4-Störung anhand der Nachrichten eingegrenzt?
Sichtbare Nachrichten Mögliche Untersuchungsrichtung
kein DHCPDISCOVER DHCP-Client, Schnittstelle oder Capture-Punkt prüfen
DISCOVER, aber kein OFFER VLAN, Relay, Filter, Server oder Bereich prüfen
mehrere OFFER mehrere DHCP-Server vorhanden; Berechtigung prüfen
OFFER, aber kein REQUEST Clientzustand oder nicht gewähltes Angebot prüfen
REQUEST, aber kein ACK Server, Relay, Filter oder Adressprüfung untersuchen
REQUEST gefolgt von NAK angeforderte Adresse ist für Server nicht gültig
ACK mit falschen Optionen Scope-, Policy- oder Optionskonfiguration prüfen
wiederholte DORA-Sequenzen Lease wird nicht übernommen oder Verbindung bricht ab
DECLINE Client vermutet Adresskonflikt
Lease funktioniert nur im Server-VLAN DHCP-Relay oder Routing prüfen

Die Interpretation muss anhand von Transaktions-ID, Client-MAC beziehungsweise Client-Identifier und Zeitstempel erfolgen. Gleichzeitige DHCP-Vorgänge anderer Clients dürfen nicht verwechselt werden.

11. Wie wird DHCP-Verkehr sicher mit Wireshark oder TShark geprüft?

Wireshark-Display-Filter für DHCPv4

dhcp

Je nach Wireshark-Version wird auch weiterhin der ältere Protokollname bootp in Feldern oder Filtern verwendet. Der folgende Filter ist deshalb ebenfalls verbreitet:

bootp

Nur DHCPv4-Ports

udp.port == 67 || udp.port == 68

TShark-Liveanzeige

[TEST][PRIV][SENS] tshark \
  -i INTERFACE \
  -f "udp port 67 or udp port 68"

Zeitlich begrenzte Aufnahme mit dumpcap

[TEST][PRIV][FILE][SENS] dumpcap \
  -i INTERFACE \
  -f "udp port 67 or udp port 68" \
  -a duration:60 \
  -w dhcp-test.pcapng

DHCP-Nachrichtentypen aus einer Datei anzeigen

[RO][SENS] tshark \
  -r dhcp-test.pcapng \
  -Y "bootp" \
  -T fields \
  -e frame.time \
  -e eth.src \
  -e ip.src \
  -e ip.dst \
  -e bootp.option.dhcp

Feldnamen können sich zwischen Wireshark-Versionen ändern. Die lokal verfügbaren Felder sollten geprüft werden:

[RO] tshark -G fields |
    grep -Ei 'dhcp|bootp'

Ein Paketmitschnitt darf nur mit Freigabe und unter Beachtung der Regeln aus Seite 2.14 erstellt werden.

12. Wie wird ein fehlendes DHCPOFFER untersucht?

Wenn der Client DHCPDISCOVER sendet, aber kein Angebot erhält, wird der Kommunikationsweg geprüft:

Client
  → Switchport
    → Client-VLAN
      → DHCP-Relay oder direktes Broadcastsegment
        → Netzwerkpfad
          → DHCP-Server

Prüffragen

  1. Ist der Client im richtigen VLAN?
  2. Wird das DHCPDISCOVER am Client gesendet?
  3. Wird es am Switch beziehungsweise Relay empfangen?
  4. Ist für dieses VLAN ein DHCP-Relay konfiguriert?
  5. Verwendet das Relay die richtige Serveradresse?
  6. Ist der DHCP-Server vom Relay aus erreichbar?
  7. Ist UDP 67/68 auf dem Weg erlaubt?
  8. Existiert ein aktiver DHCP-Bereich für das Clientnetz?
  9. Besitzt der Bereich noch freie Adressen?
  10. Ist der Serverdienst aktiv?
  11. Wird die Anfrage durch eine Policy abgelehnt?
  12. Enthält die Relay-Anfrage die erwarteten Informationen?
  13. Wird ein Angebot zurückgesendet?
  14. Erreicht das Angebot wieder den Client?

Wenn nur ein Client betroffen ist, während andere Clients am selben Anschlussbereich neue Leases erhalten, ist ein vollständiger Ausfall des DHCP-Servers weniger wahrscheinlich.

13. Welche Aufgabe hat ein DHCP-Relay?

IPv4-Broadcasts werden normalerweise nicht durch Router weitergeleitet. Befindet sich der DHCP-Server in einem anderen Netz, nimmt ein DHCP-Relay die Clientanfrage entgegen und leitet sie an den Server weiter.

Client-VLAN 20
192.0.2.0/24
  │
  ├─ DHCPDISCOVER als Broadcast
  │
  └─ Gateway/DHCP-Relay
       │
       └─ Weiterleitung zum DHCP-Server
            198.51.100.10

Der Server muss anhand der Relayinformationen erkennen können, für welches Clientnetz eine Adresse vergeben werden soll.

Typische Relay-Probleme

Typisches Muster

DHCP funktioniert im selben Netz wie der Server,
aber nicht in einem entfernten VLAN.

Dies ist ein starker Hinweis auf Relay, Routing, Firewall oder fehlenden Scope für das entfernte Netz.

14. Wie wird ein erschöpfter DHCP-Bereich erkannt?

Mögliche Symptome:

Zu prüfen

Bereich Prüffrage
Adresspool Wie viele Adressen enthält er?
aktive Leases Wie viele Adressen sind vergeben?
freie Adressen Wie viele können noch vergeben werden?
Ausschlüsse Welche Adressen sind ausgeschlossen?
Reservierungen Welche Adressen sind fest zugeordnet?
Lease-Dauer Passt sie zur Nutzung des Netzes?
veraltete Einträge Sind Leases nicht mehr aktiver Geräte vorhanden?
Konflikterkennung Wurden Adressen als problematisch markiert?

Eine Vergrößerung des Bereichs ist eine Netzwerkänderung. Präfix, Gateway, VLAN, Routing, Ausschlüsse und mögliche Überschneidungen müssen vorher geprüft werden.

15. Wie wird ein nicht autorisierter DHCP-Server erkannt?

Ein nicht vorgesehener DHCP-Server kann Clients falsche Netzwerkparameter liefern.

Mögliche Hinweise:

Prüfung mit einem Paketmitschnitt

DHCPDISCOVER
  ← DHCPOFFER von Server A
  ← DHCPOFFER von Server B

Zu dokumentieren sind:

Wichtig

Mehrere DHCP-Server können absichtlich zur Redundanz eingesetzt werden. Mehrere Angebote sind deshalb nicht automatisch ein Sicherheitsvorfall. Die Server müssen mit der vorgesehenen Architektur verglichen werden.

Ein tatsächlich unbekannter DHCP-Server ist umgehend an Netzwerk- und Informationssicherheitsverantwortliche zu eskalieren.

16. Wie werden falsche DHCP-Optionen erkannt?

Eine Lease kann erfolgreich bestätigt werden und trotzdem falsche Parameter enthalten.

Typische DHCP-Optionen:

Option Zweck
1 Subnetzmaske
3 Router beziehungsweise Standardgateway
6 DNS-Server
15 Domainname
42 NTP-Server
51 Lease-Dauer
54 DHCP-Server-Identifier
58 Renewal Time T1
59 Rebinding Time T2
66 TFTP- beziehungsweise Servername, abhängig vom Einsatz
67 Bootdateiname
119 Domain Search List
121 Classless Static Routes

Nicht jede Option wird in jeder Umgebung verwendet.

Typische Fehler

Die wirksame Option kann aus mehreren Konfigurationsebenen stammen. Deshalb muss die tatsächlich an den Client übertragene DHCP-Antwort geprüft werden.

17. Wie funktionieren Verlängerung und Rebinding einer Lease?

Eine DHCP-Lease besitzt eine begrenzte Gültigkeitsdauer.

Vereinfacht:

Leasebeginn
  │
  ├─ T1: Client versucht Erneuerung beim bisherigen Server
  │
  ├─ T2: Client versucht Erneuerung über weitere erreichbare Server
  │
  └─ Leaseende: Adresse darf nicht unbegrenzt weiterverwendet werden

Typische Standardbeziehungen, sofern der Server nichts anderes vorgibt:

T1 ungefähr 50 % der Lease-Dauer
T2 ungefähr 87,5 % der Lease-Dauer

Die tatsächlich übertragenen Werte sind entscheidend.

Mögliche Fehlerbilder

Situation Auswirkung
Erstanfrage funktioniert, Verlängerung nicht bestehende Verbindung kann bis zum Leaseende bestehen
Server zeitweise nicht erreichbar Client versucht weitere Erneuerungen
DHCPNAK bei Erneuerung Client muss Konfiguration verwerfen und neu anfordern
Netzwerkwechsel alte Adresse passt möglicherweise nicht zum neuen VLAN
sehr kurze Lease häufige DHCP-Kommunikation und höhere Serverlast
sehr lange Lease Änderungen werden langsamer wirksam
18. Wann dürfen Lease-Freigabe und -Erneuerung durchgeführt werden?

Erst nachdem der Ausgangszustand dokumentiert wurde und geklärt ist, dass die Schnittstelle DHCP verwenden soll.

Windows

Lease freigeben:

[PRIV][CHANGE][DISRUPT] ipconfig /release

Lease erneuern:

[PRIV][CHANGE][DISRUPT] ipconfig /renew

Nur einen benannten Adapter ansprechen:

[PRIV][CHANGE][DISRUPT] ipconfig /release "Ethernet"

[PRIV][CHANGE][DISRUPT] ipconfig /renew "Ethernet"

Die Behandlung von Platzhaltern und Adapternamen sollte auf dem konkreten Windows-System mit ipconfig /? geprüft werden.

Linux mit NetworkManager

Verbindung erneut aktivieren:

[PRIV][CHANGE][DISRUPT] sudo nmcli connection down "VERBINDUNGSNAME"

[PRIV][CHANGE][DISRUPT] sudo nmcli connection up "VERBINDUNGSNAME"

Abhängig von NetworkManager-Version und Profil kann auch eine erneute Anwendung vorhandener Einstellungen möglich sein:

[PRIV][CHANGE][DISRUPT] sudo nmcli device reapply eth0

Dies erzwingt nicht in jedem Fall einen vollständigen neuen DHCP-DORA-Ablauf.

macOS

DHCP-Konfiguration auf einer Schnittstelle anfordern:

[PRIV][CHANGE][DISRUPT] sudo ipconfig set en0 DHCP

Dieser Befehl setzt die Schnittstelle auf DHCP und darf nicht verwendet werden, wenn eine statische Konfiguration vorgesehen ist.

Bei Remotezugriff kann die Freigabe einer Lease die eigene Administrationsverbindung sofort beenden.

19. Warum sollte dhclient nicht ungeprüft parallel gestartet werden?

Der Befehl dhclient ist nicht auf jeder Linux-Installation vorhanden. Außerdem kann die Schnittstelle bereits durch NetworkManager, systemd-networkd oder einen anderen Netzwerkdienst verwaltet werden.

Ein zusätzlich gestarteter DHCP-Client kann:

Vor einer Verwendung muss geprüft werden:

[RO] ps -ef |
    grep -E '[d]hclient|[N]etworkManager|[s]ystemd-networkd'

[RO] systemctl --type=service --state=running |
    grep -Ei 'network|dhcp'

dhclient sollte nur verwendet werden, wenn er tatsächlich der vorgesehene DHCP-Client dieser Schnittstelle ist und seine lokale Dokumentation geprüft wurde.

20. Wie unterscheidet sich DHCPv6 von DHCPv4?

DHCPv6 ist kein direkter identischer Ersatz für DHCPv4.

IPv6-Clients können Konfigurationen unter anderem erhalten durch:

DHCPv6 verwendet:

Richtung UDP-Port
Client 546
Server 547

Vereinfachter DHCPv6-Ablauf:

Client                                   DHCPv6-Server
  │                                           │
  │──── SOLICIT ─────────────────────────────>│
  │<─── ADVERTISE ────────────────────────────│
  │──── REQUEST ─────────────────────────────>│
  │<─── REPLY ────────────────────────────────│

Typische Nachrichten:

Wireshark-Filter

dhcpv6

Capture-Filter:

udp port 546 or udp port 547

Das IPv6-Standardgateway wird üblicherweise über Router Advertisements und nicht als klassische DHCPv6-Gatewayoption bezogen. Deshalb müssen DHCPv6 und Neighbor Discovery beziehungsweise Router Advertisements gemeinsam betrachtet werden.

21. Wie wird zwischen Client-, Netz- und Serverproblem unterschieden?
Beobachtung Wahrscheinlichere Richtung
nur ein Client betroffen Clientzustand, Profil, Adapter oder MAC-bezogene Policy
alle Clients an einem Port betroffen Port, VLAN oder lokale Infrastruktur
alle neuen Clients eines VLANs betroffen Relay, Scope oder Filter
alle VLANs betroffen DHCP-Dienst oder zentrale Infrastruktur
bestehende Leases funktionieren Bereich erschöpft oder Neuanfrage gestört
DISCOVER verlässt Client nicht Client oder Schnittstelle
DISCOVER sichtbar, aber nicht am Relay VLAN- oder Switchingpfad
DISCOVER erreicht Server, kein OFFER Server, Scope oder Policy
OFFER verlässt Server, erreicht Client nicht Rückweg, Relay oder Filter
ACK erreicht Client, Konfiguration fehlt Client übernimmt Lease nicht
ACK enthält falsche Werte Server-, Scope-, Policy- oder Reservierungsoption
mehrere OFFER von unbekannten Servern möglicher Rogue-DHCP-Server

Diese Zuordnung bildet eine Arbeitshypothese und muss durch Logs, Paketmitschnitte und Vergleichstests bestätigt werden.

22. Welche Serverprüfungen sind erforderlich?

Die konkreten Befehle hängen vom DHCP-Serverprodukt ab. Unabhängig vom Produkt sollten folgende Punkte geprüft werden:

  1. Läuft der DHCP-Dienst?
  2. Ist der Server autorisiert beziehungsweise betrieblich freigegeben?
  3. Ist der richtige Bereich aktiv?
  4. Passt der Bereich zum Clientnetz?
  5. Sind freie Adressen vorhanden?
  6. Stimmen Präfix und Subnetzmaske?
  7. Stimmen Gateway- und DNS-Optionen?
  8. Existiert eine Reservierung für den Client?
  9. Gibt es Ausschlussbereiche?
  10. Wurde die Adresse als Konflikt markiert?
  11. Greift eine Policy oder Geräteklassifizierung?
  12. Sind Failover- beziehungsweise Redundanzpartner synchron?
  13. Erreichen Anfragen den Server?
  14. Verlässt die Antwort den Server?
  15. Sind Relayinformationen korrekt?
  16. Enthalten Serverlogs einen Ablehnungsgrund?

Wichtig

Die Oberfläche eines DHCP-Servers zeigt möglicherweise einen freien Bereich, während Policies, Reservierungen oder Failoverzustände die tatsächliche Vergabe beeinflussen. Die Serverprotokolle und die reale DHCP-Antwort sind deshalb ebenfalls zu prüfen.

23. Welche typischen Fehlinterpretationen müssen vermieden werden?
Beobachtung Falscher Schluss Richtige Einordnung
169.254.x.x vorhanden Netzwerkkarte ist defekt reguläre DHCP-Konfiguration wurde vermutlich nicht bezogen
DHCP aktiviert Lease ist korrekt Server, Adresse und Optionen prüfen
DHCPOFFER sichtbar DHCP funktioniert vollständig REQUEST und ACK müssen folgen
DHCPACK sichtbar Netzwerk funktioniert übertragene Optionen können falsch sein
mehrere Angebote Angriff liegt vor redundante Server können beabsichtigt sein
bestehende Clients funktionieren DHCP-Server ist gesund nur Verlängerung oder freie Adressen können betroffen sein
Ping zum DHCP-Server scheitert DHCP muss scheitern Relay und ICMP-Regeln getrennt bewerten
Server befindet sich in anderem Netz DHCP kann nicht funktionieren Relay kann Broadcasts weiterleiten
Lease wurde erneuert Ursache wurde behoben Fehler kann nur vorübergehend verdeckt sein
statische Adresse funktioniert DHCP-Fehler ist bewiesen VLAN, Routing und Adresskonflikte bleiben möglich
keine DHCP-Logs vorhanden keine Anfrage wurde gesendet falscher Logkanal oder fehlende Protokollierung möglich
DNS funktioniert nicht DHCP ist vollständig ausgefallen möglicherweise nur Option 6 fehlerhaft
24. Wie sieht der systematische Prüfablauf aus?
Schritt Prüfung
1 betroffene Schnittstelle und VLAN bestimmen
2 vorhandene Lease vollständig sichern
3 DHCP-Server, Leasezeiten und Optionen dokumentieren
4 mit funktionierendem Client im selben VLAN vergleichen
5 DHCP-Clientprotokolle untersuchen
6 Verfügbarkeit freier Adressen serverseitig prüfen
7 bei Bedarf autorisierten Paketmitschnitt vorbereiten
8 DHCP-Vorgang kontrolliert reproduzieren
9 DORA-Sequenz und Server-Identifier auswerten
10 Relay-, Routing- und Firewallpfad kontrollieren
11 Serverlogs und Scope-Konfiguration prüfen
12 falsche oder fehlende Optionen bestimmen
13 nur eine begründete Änderung durchführen
14 neue Lease mit Ausgangswert vergleichen
15 Gateway, DNS und Zielverbindung testen
16 Ursache und Änderung dokumentieren

Merksatz

Lease lesen → Clientlog prüfen → DORA verfolgen
→ Relay prüfen → Server und Scope prüfen → kontrolliert erneuern
25. Kompakte Befehlsübersicht für Windows, Linux und macOS
Aufgabe Windows Linux macOS
vollständige Konfiguration [RO][SENS] ipconfig /all [RO] ip address show [RO] ifconfig
DHCP-Status [RO] Get-NetIPInterface -AddressFamily IPv4 [RO] nmcli device show [RO] networksetup -getinfo "DIENST"
Adressursprung [RO] Get-NetIPAddress -AddressFamily IPv4 [RO] nmcli connection show "NAME" [RO] networksetup -getinfo "DIENST"
DHCP-Paketdaten in ipconfig /all teilweise sichtbar abhängig vom Netzwerkmanager [RO][SENS] ipconfig getpacket en0
Clientlogs [RO] Get-WinEvent -ListLog '*DHCP*' [RO][PRIV] sudo journalctl -b -u NetworkManager [RO] log show --last 1h --predicate 'eventMessage CONTAINS[c] "DHCP"'
NetworkManager-Status nicht zutreffend [RO] nmcli device status nicht zutreffend
networkd-Status nicht zutreffend [RO] networkctl status nicht zutreffend
DHCPv4-Capture dumpcap -f "udp port 67 or udp port 68" gleicher Befehl gleicher Befehl
DHCPv6-Capture dumpcap -f "udp port 546 or udp port 547" gleicher Befehl gleicher Befehl
Lease freigeben [PRIV][CHANGE][DISRUPT] ipconfig /release abhängig vom Netzwerkmanager kein direkt gleichwertiger allgemeiner Lesebefehl
Lease erneuern [PRIV][CHANGE][DISRUPT] ipconfig /renew Verbindung kontrolliert neu aktivieren [PRIV][CHANGE][DISRUPT] sudo ipconfig set en0 DHCP

Die Platzhalter DIENST, NAME, INTERFACE und en0 müssen durch die tatsächlich ermittelten Bezeichnungen ersetzt werden.

26. Dokumentationsvorlage 
Ticketnummer:
Prüfzeitpunkt:
Zeitzone:
Betroffener Client:
Benutzer:
Standort:
Schnittstelle:
MAC-Adresse:
Switch:
Switchport:
VLAN:

VORHANDENE KONFIGURATION

DHCP aktiviert:
IPv4-Adresse:
Präfix/Subnetzmaske:
Adresszustand:
Standardgateway:
DNS-Server:
DNS-Suchdomäne:
DHCP-Server:
Lease erhalten:
T1:
T2:
Lease läuft ab:
Weitere DHCP-Optionen:

ERWARTETE KONFIGURATION

DHCP-Bereich:
Präfix/Subnetzmaske:
Standardgateway:
DNS-Server:
DHCP-Server:
Lease-Dauer:
Weitere Optionen:

VERGLEICHSCLIENT

Hostname:
Gleiches VLAN:
DHCP-Server:
IPv4-Adresse:
Präfix:
Gateway:
DNS-Server:
Lease erfolgreich:
Relevante Abweichungen:

CLIENTPROTOKOLL

Zeitpunkt:
Meldung:
Provider/Dienst:
Ereignis-ID:

PAKETABLAUF

DHCPDISCOVER sichtbar: Ja / Nein
DHCPOFFER sichtbar: Ja / Nein
Anzahl anbietender Server:
DHCPREQUEST sichtbar: Ja / Nein
DHCPACK sichtbar: Ja / Nein
DHCPNAK sichtbar: Ja / Nein
DHCPDECLINE sichtbar: Ja / Nein
Transaktions-ID:
Client-Identifier:
Server-Identifier:
Angebotene Adresse:
Übertragene Optionen:

RELAY

Relay erforderlich:
Relayadresse:
Anfrage erreicht Relay:
Anfrage erreicht Server:
Antwort erreicht Relay:
Antwort erreicht Client:

SERVER

Dienststatus:
Scope aktiv:
Freie Adressen:
Ausschlüsse:
Reservierungen:
Konflikte:
Policy:
Failoverstatus:
Serverlog:

Arbeitshypothese:
Begründung:
Gesicherter Ausgangszustand:
Durchgeführter Test:
Durchgeführte Änderung:
Rückweg:
Neue Lease:
Abschlussprüfung:
Ermittelte Ursache:
27. Offizielle Quellen und weiterführende Dokumentation

Microsoft

Linux

Apple

Wireshark

Standards

DHCP-Serverbefehle und Verwaltungsoberflächen unterscheiden sich je nach Hersteller und Produkt. Änderungen an Scopes, Relays, Optionen oder Failoverkonfigurationen dürfen nur anhand der Dokumentation des tatsächlich eingesetzten Systems vorgenommen werden.

3. Netzwerkfehler systematisch analysieren

3.5 ARP und IPv6 Neighbor Discovery analysieren

Damit ein Endgerät ein IP-Paket innerhalb eines lokalen Ethernetnetzes übertragen kann, benötigt es die zugehörige MAC-Adresse des nächsten direkten Kommunikationspartners.

Bei IPv4 übernimmt diese Zuordnung das Address Resolution Protocol, kurz ARP. IPv6 verwendet dafür Neighbor Discovery, kurz NDP beziehungsweise ND, auf Basis von ICMPv6.

Grundregel: Für ein Ziel im lokalen Subnetz wird die MAC-Adresse des Zielsystems benötigt. Für ein Ziel in einem entfernten Subnetz wird normalerweise die MAC-Adresse des nächsten Routers benötigt – nicht die MAC-Adresse des entfernten Zielsystems.

1. Welche Aufgabe erfüllt ARP?

ARP ordnet eine lokale IPv4-Adresse einer MAC-Adresse zu.

Beispiel im selben Subnetz

CLIENT-023
IPv4: 192.0.2.23/24
MAC:  00-11-22-33-44-55

SERVER-01
IPv4: 192.0.2.80/24
MAC:  AA-BB-CC-DD-EE-FF

Der Client kennt zunächst nur die IPv4-Adresse des Servers und sendet eine ARP-Anfrage:

Wer hat 192.0.2.80?
Antwort bitte an 192.0.2.23.

Die Anfrage wird als Ethernet-Broadcast gesendet:

FF:FF:FF:FF:FF:FF

Der Server antwortet normalerweise per Unicast:

192.0.2.80 befindet sich unter AA:BB:CC:DD:EE:FF.

Der Client kann die Zuordnung anschließend vorübergehend in seiner Nachbartabelle speichern.

2. Welche MAC-Adresse wird bei einem entfernten IPv4-Ziel aufgelöst?

Ausgangslage

Client:  192.0.2.23/24
Gateway: 192.0.2.1
Ziel:    198.51.100.20

Das Ziel liegt nicht im lokalen Subnetz 192.0.2.0/24.

Der Client ermittelt daher normalerweise nicht die MAC-Adresse von 198.51.100.20, sondern die MAC-Adresse des nächsten Routers:

ARP-Anfrage:
Wer hat 192.0.2.1?

Anschließend entsteht vereinfacht folgender Frame:

Ethernet-Ziel-MAC: MAC-Adresse des Gateways
IP-Zieladresse:    198.51.100.20
Ebene Ziel
Ethernet nächster Router
IPv4 entferntes Zielsystem

Die Ethernetadressen können sich an jedem gerouteten Abschnitt ändern. Die IP-Zieladresse bleibt ohne NAT normalerweise bis zum Ziel bestehen.

3. Welche Symptome sprechen für ein ARP- oder Neighbor-Discovery-Problem?
4. Wie wird entschieden, ob ARP für das Ziel oder für das Gateway verwendet wird?

Zuerst wird die ausgewählte Route geprüft.

Windows

[RO] Find-NetRoute -RemoteIPAddress 198.51.100.20

Linux

[RO] ip route get 198.51.100.20

macOS

[RO] route -n get 198.51.100.20

Bewertung

Routenergebnis Aufzulösender direkter Nachbar
Ziel gilt als direkt verbunden Ziel-IP-Adresse
Route enthält ein Gateway beziehungsweise Next Hop Gateway-Adresse
Route verwendet Tunnelinterface Verhalten abhängig vom Tunnel
Route fehlt keine reguläre Weiterleitung möglich
Ziel wird fälschlich als lokal behandelt möglicherweise falsches Präfix

Eine falsche Subnetzmaske kann dazu führen, dass ein Client ARP-Anfragen für ein eigentlich entferntes Ziel sendet.

5. Wie wird die IPv4-Nachbartabelle unter Windows angezeigt?

PowerShell

[RO] Get-NetNeighbor -AddressFamily IPv4

Übersichtliche Darstellung

[RO] Get-NetNeighbor -AddressFamily IPv4 |
    Sort-Object InterfaceIndex, IPAddress |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 IPAddress,
                 LinkLayerAddress,
                 State,
                 PolicyStore

Ein bestimmter Nachbar

[RO] Get-NetNeighbor `
    -InterfaceAlias 'Ethernet' `
    -IPAddress '192.0.2.1'

Klassischer Befehl

[RO] arp -a

Bestimmte IP-Adresse suchen:

[RO] arp -a 192.0.2.1

Die PowerShell-Ausgabe zeigt zusätzlich den Zustand des Eintrags. arp -a unterscheidet hauptsächlich zwischen dynamischen und statischen Einträgen.

6. Welche Neighbor-Zustände zeigt Windows?

Mögliche Zustände von Get-NetNeighbor:

Zustand Bedeutung
Unreachable Nachbar gilt als nicht erreichbar
Incomplete Auflösung wurde begonnen, aber noch nicht abgeschlossen
Probe Erreichbarkeit wird aktiv geprüft
Delay Prüfung wird kurz verzögert
Stale Eintrag ist vorhanden, wurde aber länger nicht bestätigt
Reachable Nachbar wurde kürzlich als erreichbar bestätigt
Permanent statischer beziehungsweise dauerhafter Eintrag
Unknown Zustand konnte nicht eindeutig bestimmt werden

Ein Eintrag im Zustand Stale ist nicht automatisch fehlerhaft. Er kann bei der nächsten Verwendung erneut geprüft werden.

Ein dauerhaft Incomplete bleibender Eintrag deutet darauf hin, dass die Adressauflösung nicht erfolgreich abgeschlossen wird.

7. Wie wird die IPv4-Nachbartabelle unter Linux angezeigt?

Alle IPv4-Nachbarn

[RO] ip -4 neighbour show

Kurzform:

[RO] ip -4 neigh

Bestimmte Schnittstelle

[RO] ip -4 neighbour show dev eth0

Bestimmte IP-Adresse

[RO] ip -4 neighbour show 192.0.2.1

Änderungen live beobachten

[RO] ip monitor neigh

Beenden mit:

Strg+C

Klassischer ARP-Befehl

[RO] arp -an

Der ältere Befehl arp ist nicht auf jeder Linux-Installation standardmäßig vorhanden. Für moderne Systeme ist ip neighbour vorzuziehen.

8. Welche Neighbor-Zustände zeigt Linux?
Zustand Bedeutung
INCOMPLETE Adressauflösung läuft, aber MAC-Adresse fehlt
REACHABLE Nachbar wurde kürzlich als erreichbar bestätigt
STALE Eintrag ist bekannt, Bestätigung ist aber älter
DELAY Erreichbarkeitsprüfung wird verzögert
PROBE Nachbar wird aktiv geprüft
FAILED Auflösung beziehungsweise Erreichbarkeitsprüfung ist fehlgeschlagen
NOARP für diesen Eintrag wird keine normale Nachbarauflösung durchgeführt
PERMANENT statischer, dauerhafter Eintrag

Beispiel

192.0.2.1 dev eth0 lladdr 00:11:22:33:44:01 REACHABLE
Bestandteil Bedeutung
192.0.2.1 IPv4-Adresse des Nachbarn
dev eth0 verwendete Schnittstelle
lladdr Link-Layer-Adresse folgt
00:11:22:33:44:01 MAC-Adresse
REACHABLE aktueller Zustand

Fehlgeschlagener Eintrag

192.0.2.80 dev eth0 FAILED

Dies bedeutet, dass die Nachbarauflösung beziehungsweise Erreichbarkeitsprüfung fehlgeschlagen ist. Die genaue Ursache kann weiterhin bei VLAN, Zielgerät, Switch, WLAN-Isolation oder Filterung liegen.

9. Wie wird die IPv4-Nachbartabelle unter macOS angezeigt?

Alle ARP-Einträge

[RO] arp -an

Bestimmte IP-Adresse

[RO] arp -n 192.0.2.1

Routingtabelle mit Link-Layer-Einträgen

[RO] netstat -rn -f inet

Beispiel eines vollständigen Eintrags:

? (192.0.2.1) at 00:11:22:33:44:01 on en0 ifscope [ethernet]

Beispiel eines unvollständigen Eintrags:

? (192.0.2.80) at (incomplete) on en0 ifscope [ethernet]

Ein unvollständiger Eintrag bedeutet, dass keine verwendbare MAC-Adresse ermittelt wurde.

10. Wie wird ein Nachbareintrag kontrolliert erzeugt?

Wenn noch kein Eintrag vorhanden ist, kann eine normale Kommunikation zum direkten Nachbarn die Auflösung auslösen.

Windows

[TEST] Test-Connection 192.0.2.1 -Count 1

Danach:

[RO] Get-NetNeighbor `
    -InterfaceAlias 'Ethernet' `
    -IPAddress '192.0.2.1'

Linux

[TEST] ping -c 1 192.0.2.1

Danach:

[RO] ip neighbour show 192.0.2.1

macOS

[TEST] ping -c 1 192.0.2.1

Danach:

[RO] arp -n 192.0.2.1

Auch wenn das Ziel ICMP nicht beantwortet, kann durch die lokale Zustellung ein ARP-Eintrag entstehen. Voraussetzung ist, dass das Betriebssystem das Ziel als direkten Nachbarn behandelt.

11. Wie wird ARP mit arping aktiv geprüft?

arping sendet aktive ARP-Anfragen auf einer lokalen Ethernetverbindung. Das Werkzeug ist nicht unter jedem Betriebssystem standardmäßig vorhanden.

Linux-Beispiel

[TEST][PRIV] sudo arping \
    -I eth0 \
    -c 4 \
    192.0.2.1
Option Bedeutung
-I eth0 Schnittstelle
-c 4 vier Anfragen
Zieladresse direkt zu prüfende lokale IPv4-Adresse

Einsatzmöglichkeiten

Einschränkungen

Vor der Verwendung muss die lokale Syntax geprüft werden:

[RO] arping --help

oder:

[RO] man arping
12. Wie wird ARP mit Wireshark oder TShark untersucht?

Wireshark-Display-Filter

arp

Nur Anfragen:

arp.opcode == 1

Nur Antworten:

arp.opcode == 2

Bestimmte IPv4-Adresse:

arp.src.proto_ipv4 == 192.0.2.1 || arp.dst.proto_ipv4 == 192.0.2.1

Capture-Filter

arp

TShark-Liveanzeige

[TEST][PRIV][SENS] tshark \
  -i INTERFACE \
  -f "arp"

Zeitlich begrenzte Aufnahme

[TEST][PRIV][FILE][SENS] dumpcap \
  -i INTERFACE \
  -f "arp" \
  -a duration:30 \
  -w arp-diagnose.pcapng

ARP-Felder anzeigen

[RO][SENS] tshark \
  -r arp-diagnose.pcapng \
  -Y "arp" \
  -T fields \
  -e frame.time \
  -e eth.src \
  -e eth.dst \
  -e arp.opcode \
  -e arp.src.proto_ipv4 \
  -e arp.src.hw_mac \
  -e arp.dst.proto_ipv4 \
  -e arp.dst.hw_mac

Die lokal verfügbaren Feldnamen können geprüft werden:

[RO] tshark -G fields |
    grep -E $'\tarp\.'
13. Wie wird eine erfolglose ARP-Auflösung im Paketmitschnitt erkannt?

Typisches Muster:

Client → Broadcast: Who has 192.0.2.80?
Client → Broadcast: Who has 192.0.2.80?
Client → Broadcast: Who has 192.0.2.80?
Keine Antwort

Mögliche Ursachen:

Wichtiger Gegencheck

Wenn der Client ARP für eine entfernte Zieladresse sendet, muss zuerst Präfix und Route geprüft werden. Die Ursache liegt dann möglicherweise nicht bei ARP, sondern in einer falschen Subnetzkonfiguration.

14. Was ist Gratuitous ARP?

Gratuitous ARP ist eine ARP-Nachricht, bei der ein Gerät eine eigene IPv4-/MAC-Zuordnung ohne vorherige normale Anfrage bekannt gibt oder prüft.

Mögliche Zwecke:

Typisches Szenario

Firewall A besitzt virtuelle IP 192.0.2.1.
Firewall A fällt aus.
Firewall B übernimmt 192.0.2.1.
Firewall B sendet Gratuitous ARP mit ihrer MAC-Adresse.

Clients sollen dadurch die neue Zuordnung lernen.

Viele Gratuitous-ARP-Nachrichten sind nicht automatisch schädlich. Sie müssen im Zusammenhang mit Hochverfügbarkeit, Clusterbetrieb, Virtualisierung und Adresskonflikten bewertet werden.

15. Was ist Proxy ARP?

Beim Proxy ARP antwortet ein Gerät auf eine ARP-Anfrage für eine andere IPv4-Adresse mit seiner eigenen MAC-Adresse.

Vereinfacht:

Client fragt:
Wer hat 192.0.2.80?

Router antwortet:
192.0.2.80 befindet sich unter meiner MAC-Adresse.

Der Router übernimmt anschließend die Weiterleitung zum eigentlichen Ziel.

Proxy ARP kann bewusst eingesetzt werden, beispielsweise für bestimmte Netzdesigns oder Übergangslösungen. Es kann aber auch Fehlkonfigurationen verbergen.

Hinweise auf Proxy ARP

Proxy ARP darf nicht ohne Prüfung der Netzwerkarchitektur als Angriff oder Fehlfunktion bewertet werden.

16. Welche Aufgabe erfüllt IPv6 Neighbor Discovery?

IPv6 verwendet kein ARP. Neighbor Discovery arbeitet mit ICMPv6 und übernimmt mehrere Funktionen:

Wichtige ICMPv6-Nachrichten:

Typ Nachricht Aufgabe
133 Router Solicitation Client fordert Routerinformationen an
134 Router Advertisement Router teilt Präfixe und Parameter mit
135 Neighbor Solicitation Nachbarauflösung oder Erreichbarkeitsprüfung
136 Neighbor Advertisement Antwort beziehungsweise Ankündigung eines Nachbarn
137 Redirect Router weist auf einen besseren nächsten Hop hin

NDP verwendet Multicast statt des aus IPv4 bekannten Broadcasts.

17. Wie funktioniert die IPv6-Nachbarauflösung?

Vereinfachter Ablauf:

Client                                   IPv6-Nachbar
  │                                           │
  │──── Neighbor Solicitation ───────────────>│
  │<─── Neighbor Advertisement ───────────────│
  │                                           │

Die Neighbor Solicitation wird normalerweise an eine zur Zieladresse gehörende Solicited-Node-Multicast-Adresse gesendet.

Wichtiger Unterschied zu ARP

IPv4 IPv6
ARP ICMPv6 Neighbor Discovery
Ethernet-Broadcast IPv6-Multicast
separate ARP-Nachricht Teil von ICMPv6
ARP-Tabelle IPv6-Nachbartabelle

ICMPv6 darf nicht pauschal blockiert werden. Viele ICMPv6-Nachrichten sind für die grundlegende IPv6-Funktion erforderlich.

18. Wie wird die IPv6-Nachbartabelle unter Windows angezeigt? 
[RO] Get-NetNeighbor -AddressFamily IPv6

Übersicht:

[RO] Get-NetNeighbor -AddressFamily IPv6 |
    Sort-Object InterfaceIndex, IPAddress |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 IPAddress,
                 LinkLayerAddress,
                 State

Bestimmte Link-Local-Adresse:

[RO] Get-NetNeighbor `
    -InterfaceAlias 'Ethernet' `
    -IPAddress 'fe80::1'

Bei Link-Local-Adressen ist die Schnittstelle beziehungsweise Scope-ID entscheidend, da fe80::/10 auf mehreren Interfaces verwendet werden kann.

Alternative klassische Anzeige

[RO] netsh interface ipv6 show neighbors
19. Wie wird die IPv6-Nachbartabelle unter Linux angezeigt?

Alle IPv6-Nachbarn

[RO] ip -6 neighbour show

Bestimmte Schnittstelle

[RO] ip -6 neighbour show dev eth0

Bestimmte Adresse

[RO] ip -6 neighbour show 2001:db8:20::20

Änderungen beobachten

[RO] ip monitor neigh

Router und Standardroute

[RO] ip -6 route show default

IPv6-Adressen und deren Zustand

[RO] ip -6 address show dev eth0

Auf folgende Zustände achten:

tentative
dadfailed
deprecated

dadfailed weist darauf hin, dass Duplicate Address Detection für diese Adresse fehlgeschlagen ist.

20. Wie wird die IPv6-Nachbartabelle unter macOS angezeigt?

IPv6-Nachbartabelle

[RO] ndp -an

Bestimmten Nachbarn anzeigen

[RO] ndp -n fe80::1%en0

Die Schnittstellenangabe %en0 ist bei Link-Local-Adressen häufig erforderlich.

IPv6-Routingtabelle

[RO] netstat -rn -f inet6

IPv6-Konfiguration einer Schnittstelle

[RO] ifconfig en0

Zu prüfen sind:

21. Wie wird IPv6 Neighbor Discovery mit Wireshark untersucht?

Alle Neighbor-Discovery-Nachrichten

icmpv6.type >= 133 && icmpv6.type <= 137

Router Solicitation

icmpv6.type == 133

Router Advertisement

icmpv6.type == 134

Neighbor Solicitation

icmpv6.type == 135

Neighbor Advertisement

icmpv6.type == 136

Redirect

icmpv6.type == 137

Bestimmte IPv6-Adresse

ipv6.addr == 2001:db8:20::20

Capture-Filter für relevante ICMPv6-Nachrichten

icmp6

Zeitlich begrenzte Aufnahme

[TEST][PRIV][FILE][SENS] dumpcap \
  -i INTERFACE \
  -f "icmp6" \
  -a duration:30 \
  -w ipv6-nd.pcapng

TShark-Auswertung

[RO][SENS] tshark \
  -r ipv6-nd.pcapng \
  -Y "icmpv6.type >= 133 && icmpv6.type <= 137" \
  -T fields \
  -e frame.time \
  -e eth.src \
  -e eth.dst \
  -e ipv6.src \
  -e ipv6.dst \
  -e icmpv6.type
22. Was ist Duplicate Address Detection bei IPv6?

Bevor eine neue IPv6-Adresse regulär verwendet wird, prüft der Host normalerweise, ob sie bereits auf dem lokalen Link verwendet wird.

Vereinfacht:

Neuer Host
  → Neighbor Solicitation für die eigene geplante Adresse
  → keine widersprechende Antwort: Adresse kann verwendet werden

Antwortet ein anderes Gerät, kann die Adresse als doppelt erkannt werden.

Mögliche Zustände

Zustand Bedeutung
tentative Prüfung läuft
preferred Adresse kann normal verwendet werden
deprecated Adresse wird nicht mehr für neue Verbindungen bevorzugt
dadfailed beziehungsweise Duplicate Konflikt erkannt

Mögliche Ursachen eines DAD-Fehlers

Ein DAD-Fehler darf nicht durch dauerhaftes Abschalten der Konflikterkennung verdeckt werden.

23. Wie werden Router Advertisements in die Diagnose einbezogen?

Router Advertisements können unter anderem mitteilen:

Typische Fehlerbilder

Windows-Routen

[RO] Get-NetRoute -AddressFamily IPv6

Linux

[RO] ip -6 route

macOS

[RO] netstat -rn -f inet6

Ein vorhandener DHCPv6-Server ersetzt nicht automatisch die Router Advertisements für die Standardrouterinformation.

24. Warum dürfen Nachbartabellen nicht vorschnell geleert werden?

Das Leeren einer Nachbartabelle:

Vorher sollten gespeichert werden:

Windows

[RO][FILE][SENS] Get-NetNeighbor |
    Export-Csv 'C:\Temp\nachbartabelle-vorher.csv' `
    -NoTypeInformation `
    -Encoding UTF8

Linux

[RO][FILE][SENS] ip neighbour show \
    > /tmp/nachbartabelle-vorher.txt

macOS

[RO][FILE][SENS] arp -an \
    > /tmp/arp-vorher.txt

[RO][FILE][SENS] ndp -an \
    > /tmp/ndp-vorher.txt

Die Speicherorte müssen den betrieblichen Datenschutz- und Sicherheitsvorgaben entsprechen.

25. Welche eingreifenden Befehle existieren?

Windows – IPv4-Nachbartabelle leeren

[PRIV][CHANGE][DISRUPT] netsh interface ip delete arpcache

Linux – dynamische IPv4-Nachbarn einer Schnittstelle leeren

[PRIV][CHANGE][DISRUPT] sudo ip -4 neighbour flush dev eth0

Linux – IPv6-Nachbarn einer Schnittstelle leeren

[PRIV][CHANGE][DISRUPT] sudo ip -6 neighbour flush dev eth0

macOS – einzelnen ARP-Eintrag entfernen

[PRIV][CHANGE][DISRUPT] sudo arp -d 192.0.2.1

macOS – einzelnen IPv6-Nachbareintrag entfernen

[PRIV][CHANGE][DISRUPT] sudo ndp -d fe80::1%en0

Diese Befehle sind keine ersten Diagnoseschritte. Bei Remotezugriff kann insbesondere das Entfernen des Gatewayeintrags die aktive Verbindung kurzfristig beeinträchtigen. Syntax und unterstützte Optionen müssen lokal mit der jeweiligen Hilfeseite geprüft werden.

26. Wie werden statische Nachbareinträge bewertet?

Statische Einträge können bewusst eingerichtet sein, beispielsweise für:

Sie können jedoch veraltet sein, wenn:

Windows

[RO] Get-NetNeighbor |
    Where-Object State -eq 'Permanent'

Linux

[RO] ip neighbour show nud permanent

macOS

[RO] arp -an

Statische Einträge dürfen nicht gelöscht werden, bevor Eigentümer, Zweck, Konfigurationsquelle und Rückweg geklärt sind.

27. Wie werden ARP-Spoofing und Neighbor-Discovery-Manipulation erkannt?

Mögliche Hinweise:

Sicheres Vorgehen

  1. aktuelle Nachbartabelle sichern,
  2. Zeitpunkt dokumentieren,
  3. Switch-MAC-Tabelle und Portzuordnung prüfen,
  4. DHCP- und Netzwerkdokumentation vergleichen,
  5. Paketmitschnitt nur mit Freigabe erstellen,
  6. Hochverfügbarkeits- und Proxyfunktionen ausschließen,
  7. Informationssicherheit einbeziehen,
  8. verdächtiges Gerät nicht unkoordiniert verändern.

Eine gemeinsame MAC-Adresse für mehrere IP-Adressen ist nicht automatisch ein Angriff. Router, Load Balancer, Firewalls, Proxy ARP und Cluster können dieses Muster beabsichtigt erzeugen.

28. Wie wird zwischen Client-, VLAN- und Zielproblem unterschieden?
Beobachtung Wahrscheinlichere Richtung
nur ein Client erhält keine ARP-Antwort Client, Port oder lokale Sicherheitsregel
mehrere Clients im VLAN betroffen VLAN, Switch oder Zielsystem
andere VLANs erreichen das Ziel betroffenes VLAN oder Gatewayinterface
ARP-Anfrage verlässt Client nicht Clientstack oder Schnittstelle
Anfrage sichtbar, Antwort fehlt Ziel, VLAN-Pfad oder Filter
Antwort erreicht Switch, aber nicht Client Port, WLAN oder Sicherheitsfunktion
falsche MAC antwortet Proxy, Konflikt oder Manipulation
Gateway wird aufgelöst, Ziel nicht erreichbar Problem liegt wahrscheinlich nach Layer 2
Ziel wird fälschlich per ARP gesucht falsches Präfix oder falsche Route
IPv6 NS ohne NA Ziel, VLAN, Filter oder NDP-Konfiguration
nur IPv6 betroffen ICMPv6, RA, NDP oder IPv6-VLAN-Pfad
29. Welche typischen Fehlinterpretationen müssen vermieden werden?
Beobachtung Falscher Schluss Richtige Einordnung
ARP-Tabelle ist leer Netzwerk ist defekt möglicherweise wurde noch kein lokaler Nachbar angesprochen
Eintrag ist Stale Ziel ist nicht erreichbar Eintrag wird bei Nutzung erneut geprüft
Eintrag ist Incomplete Ziel ist ausgeschaltet VLAN, Präfix und Filter bleiben mögliche Ursachen
entfernte Ziel-IP fehlt in ARP Fehler liegt vor nur der lokale Next Hop wird benötigt
viele IPs haben dieselbe MAC Angriff Router, Proxy ARP oder Cluster möglich
MAC-Adresse wechselt Angriff Failover oder Gerätewechsel möglich
Ping funktioniert nicht ARP funktioniert nicht Nachbartabelle getrennt prüfen
ARP funktioniert Anwendung funktioniert nur lokale Adressauflösung bestätigt
IPv6 hat keine ARP-Tabelle IPv6 benötigt keine Auflösung IPv6 verwendet NDP
ICMPv6 wird blockiert nur Ping ist betroffen zentrale IPv6-Funktionen können ausfallen
Nachbartabelle wurde geleert und es funktioniert Ursache wurde behoben Problem kann nur vorübergehend verdeckt sein
Gratuitous ARP sichtbar Manipulation Konfliktprüfung oder Failover möglich
30. Wie sieht der systematische Prüfablauf aus?
Schritt Prüfung
1 IP-Adresse und Präfix des Clients bestätigen
2 ausgewählte Route zum Ziel bestimmen
3 direkt aufzulösenden Nachbarn identifizieren
4 vorhandene Nachbartabelle unverändert sichern
5 Zustand und MAC-Adresse des Eintrags prüfen
6 mit funktionierendem Referenzclient vergleichen
7 normale Kommunikation zum direkten Nachbarn auslösen
8 Nachbartabelle erneut prüfen
9 bei Bedarf ARP beziehungsweise NDP kontrolliert mitschneiden
10 Anfrage und Antwort auf Client- und Netzseite verfolgen
11 Switchport, VLAN und MAC-Zuordnung prüfen
12 Proxy-, Cluster- und Hochverfügbarkeitsfunktionen berücksichtigen
13 Konflikt oder Manipulationsverdacht eskalieren
14 Tabelle nur nach Beweissicherung gezielt verändern
15 ursprüngliches Fehlerbild erneut testen
16 Ursache und Ergebnis dokumentieren

Merksatz

Route bestimmen → direkten Nachbarn bestimmen
→ Tabelle prüfen → Anfrage verfolgen → Antwort verfolgen
31. Kompakte Befehlsübersicht für Windows, Linux und macOS
Aufgabe Windows Linux macOS
IPv4-Nachbarn [RO] Get-NetNeighbor -AddressFamily IPv4 [RO] ip -4 neighbour [RO] arp -an
IPv6-Nachbarn [RO] Get-NetNeighbor -AddressFamily IPv6 [RO] ip -6 neighbour [RO] ndp -an
einzelner IPv4-Nachbar [RO] Get-NetNeighbor -IPAddress ZIEL [RO] ip neighbour show ZIEL [RO] arp -n ZIEL
einzelne IPv6-Adresse [RO] Get-NetNeighbor -IPAddress ZIEL [RO] ip -6 neighbour show ZIEL [RO] ndp -n ZIEL%INTERFACE
Route zum Ziel [RO] Find-NetRoute -RemoteIPAddress ZIEL [RO] ip route get ZIEL [RO] route -n get ZIEL
Nachbaränderungen live PowerShell wiederholt abfragen [RO] ip monitor neigh wiederholt arp beziehungsweise ndp
ARP aktiv testen normales Test-Connection [TEST][PRIV] sudo arping -I INTERFACE -c 4 ZIEL abhängig von installiertem Werkzeug
ARP mitschneiden [TEST][PRIV][SENS] tshark -i INTERFACE -f "arp" gleicher Befehl gleicher Befehl
NDP mitschneiden [TEST][PRIV][SENS] tshark -i INTERFACE -f "icmp6" gleicher Befehl gleicher Befehl
ARP-Cache leeren [PRIV][CHANGE][DISRUPT] netsh interface ip delete arpcache [PRIV][CHANGE][DISRUPT] sudo ip -4 neigh flush dev INTERFACE [PRIV][CHANGE][DISRUPT] sudo arp -d ZIEL
IPv6-Nachbarn leeren nur gezielt nach lokaler Dokumentation [PRIV][CHANGE][DISRUPT] sudo ip -6 neigh flush dev INTERFACE [PRIV][CHANGE][DISRUPT] sudo ndp -d ZIEL%INTERFACE

Die Platzhalter ZIEL und INTERFACE müssen durch vorher eindeutig bestimmte Werte ersetzt werden.

32. Dokumentationsvorlage 
Ticketnummer:
Prüfzeitpunkt:
Zeitzone:
Betroffener Client:
Betriebssystem:
Schnittstelle:
MAC-Adresse:
VLAN:

IP-KONFIGURATION

Client-IPv4:
IPv4-Präfix:
Client-IPv6:
IPv6-Präfix:
Standardgateway IPv4:
Standardrouter IPv6:

ZIEL

Zielname:
Ziel-IPv4:
Ziel-IPv6:
Ziel laut Präfix lokal: Ja / Nein
Ausgewählte Route:
Ausgewählte Quelladresse:
Next Hop:
Direkt aufzulösender Nachbar:

NACHBARTABELLE VOR DEM TEST

IPv4-Nachbar:
MAC-Adresse:
Schnittstelle:
Zustand:
Dynamisch oder statisch:

IPv6-Nachbar:
MAC-Adresse:
Schnittstelle:
Zustand:
Dynamisch oder statisch:

AKTIVER TEST

Verwendeter Test:
Startzeit:
Endzeit:
Anfragen gesendet:
Antworten empfangen:

PAKETMITSCHNITT

ARP Request sichtbar:
ARP Reply sichtbar:
Neighbor Solicitation sichtbar:
Neighbor Advertisement sichtbar:
Router Advertisement sichtbar:
Quell-MAC:
Antwort-MAC:
Mehrere Antworten:
Gratuitous ARP:
Proxy ARP vermutet:
DAD fehlgeschlagen:

NETZWERKSEITE

Switch:
Switchport:
Port-VLAN:
Gelernte Client-MAC:
Gelernte Ziel-MAC:
MAC wechselt zwischen Ports:
Port-Security-Ereignisse:
ARP-/NDP-Schutzereignisse:

REFERENZCLIENT

Hostname:
Gleiches VLAN:
Nachbar-IP:
Nachbar-MAC:
Nachbarzustand:
Relevante Abweichungen:

Arbeitshypothese:
Begründung:
Originaltabelle gesichert:
Durchgeführte Änderung:
Rückweg:
Abschlussprüfung:
Ermittelte Ursache:
Sicherheitseskalation erforderlich: Ja / Nein
33. Offizielle Quellen und weiterführende Dokumentation

Microsoft

Linux

Apple

Wireshark

Standards

Nachbarzustände, Zeitlimits und verfügbare Diagnosefelder hängen vom Betriebssystem, Treiber und Netzwerkdesign ab. Eine fehlende Antwort muss immer zusammen mit Route, Präfix, VLAN und tatsächlichem Messpunkt bewertet werden.

3. Netzwerkfehler systematisch analysieren

3.6 VLAN- und Layer-2-Fehler analysieren

Virtual LANs teilen eine physische Switchinfrastruktur in getrennte logische Layer-2-Netze. Geräte in unterschiedlichen VLANs können nicht allein über Switching miteinander kommunizieren. Für die Kommunikation zwischen VLANs ist normalerweise ein Router oder eine Layer-3-Switch-Funktion erforderlich.

VLAN-Fehler können dazu führen, dass ein Endgerät zwar einen aktiven Link besitzt, aber keine passende DHCP-Adresse erhält, sein Gateway nicht erreicht oder im falschen logischen Netz landet.

Grundregel: Linkstatus und VLAN-Zugehörigkeit sind getrennte Eigenschaften. Ein Switchport kann physisch aktiv und gleichzeitig logisch dem falschen VLAN zugeordnet sein.

1. Welche Aufgaben erfüllt ein VLAN?

Ein VLAN bildet eine eigene Layer-2-Broadcast-Domain.

Physischer Switch
├─ VLAN 10 – Verwaltung
├─ VLAN 20 – Clients
├─ VLAN 30 – VoIP
├─ VLAN 40 – Server
└─ VLAN 50 – Gäste

Innerhalb eines VLANs werden unter anderem folgende Nachrichten verteilt:

Ein Router trennt normalerweise die Broadcast-Domains und vermittelt bei Bedarf zwischen den VLANs.

Beispiel

CLIENT-023 in VLAN 20
192.0.2.23/24

SERVER-01 in VLAN 40
198.51.100.20/24

Die Kommunikation benötigt:

VLAN 20
  → Gateway für VLAN 20
    → Layer-3-Routing und mögliche Firewallregeln
      → Gateway beziehungsweise Interface für VLAN 40
        → VLAN 40
2. Was ist der Unterschied zwischen Access-Port und Trunk?
Porttyp Typischer Einsatz Verhalten
Access-Port normales Endgerät gehört normalerweise zu einem ungetaggten VLAN
Trunk Verbindung zwischen Switches, Routern, Servern oder Access Points transportiert mehrere VLANs
Hybrid-/General-Port herstellerabhängige Mischform kombiniert getaggte und ungetaggte VLANs
Routed Port Layer-3-Verbindung arbeitet nicht als gewöhnlicher Switchport

Access-Port

Client
  │ ungetaggter Ethernetframe
  ▼
Switchport als Access-Port in VLAN 20

Der Client muss normalerweise keine VLAN-ID kennen. Der Switch ordnet eingehende ungetaggte Frames dem konfigurierten Access-VLAN zu.

Trunk

Switch A
  │ VLAN 10 getaggt
  │ VLAN 20 getaggt
  │ VLAN 40 getaggt
  ▼
Switch B

Die VLAN-Zugehörigkeit wird bei IEEE 802.1Q über einen VLAN-Tag im Ethernetframe transportiert.

3. Welche Informationen enthält ein IEEE-802.1Q-Tag?

Ein 802.1Q-Tag enthält unter anderem:

Feld Bedeutung
PCP Prioritätsinformation nach IEEE 802.1p
DEI Drop Eligible Indicator
VLAN ID VLAN-Kennung

Die VLAN-ID besitzt 12 Bit. Dadurch sind Werte von 0 bis 4095 darstellbar. Die Randwerte sind reserviert beziehungsweise besitzen Sonderbedeutungen; für reguläre VLAN-Zuordnungen werden typischerweise VLAN-IDs 1 bis 4094 verwendet.

Vereinfachter Ethernetframe

Ohne VLAN-Tag:

Ziel-MAC
Quell-MAC
EtherType
Nutzdaten
FCS

Mit 802.1Q-Tag:

Ziel-MAC
Quell-MAC
802.1Q-Tag
EtherType
Nutzdaten
FCS

Der zusätzliche Tag vergrößert den Ethernetframe um vier Byte. Geräte und Netzwerkpfade müssen entsprechend kompatibel sein.

4. Welche Symptome sprechen für einen VLAN-Fehler?
5. Welche Informationen müssen vor einer VLAN-Analyse bekannt sein?
Information Beispiel
Clienthostname CLIENT-023
Client-MAC-Adresse 00-11-22-33-44-55
Switch SW-ACCESS-01
Switchport Port 17
vorgesehene VLAN-ID 20
Portmodus Access
erwartetes Subnetz 192.0.2.0/24
erwartetes Gateway 192.0.2.1
erwarteter DHCP-Server beziehungsweise Relay dokumentierte Infrastruktur
nächster Uplink SW-CORE-01
Fehlerbeginn 2026-07-31 09:42 CEST
letzte Änderung Portkonfiguration wurde angepasst

Bei einem Trunk zusätzlich:

6. Wie wird ein Access-Port systematisch geprüft?

Auf der Switchseite sollten mindestens folgende Eigenschaften geprüft werden:

Eigenschaft Prüffrage
administrativer Status Ist der Port aktiviert?
operativer Status Besteht ein Link?
Portmodus Ist der Port tatsächlich als Access-Port vorgesehen?
Access-VLAN Ist das richtige VLAN zugeordnet?
Voice-VLAN Existiert eine zusätzliche Telefonzuordnung?
MAC-Tabelle Wird die erwartete MAC-Adresse gelernt?
Port-Security Ist die Client-MAC zugelassen?
Authentifizierung Ist 802.1X beziehungsweise MAB erfolgreich?
Spanning Tree Ist der Port forwarding oder blockiert?
Fehlerzähler Steigen CRC-, Drop- oder andere Fehler?
Beschreibung Passt die Dokumentation zum angeschlossenen Gerät?

Erwartetes Muster

Switchport: Port 17
Modus: Access
Access-VLAN: 20
MAC-Adresse: 00:11:22:33:44:55
Spanning Tree: Forwarding
Port-Security: kein Verstoß

Wenn die MAC-Adresse des Clients an diesem Port nicht gelernt wird, müssen Link, Kabel, Clientaktivität, Authentifizierung und Portzustand geprüft werden.

7. Wie wird ein Trunk systematisch geprüft?

Prüfpunkte auf beiden Seiten

Eigenschaft Seite A Seite B
Portmodus Trunk Trunk
erlaubte VLANs identische beziehungsweise kompatible Liste identische beziehungsweise kompatible Liste
natives VLAN abgestimmt abgestimmt
Tagging abgestimmt abgestimmt
Linkaggregation gleiche logische Verbindung gleiche logische Verbindung
Geschwindigkeit und Duplex kompatibel kompatibel
Spanning Tree erwarteter Zustand erwarteter Zustand

Typischer Fehler

Switch A erlaubt:
VLAN 10, 20, 40

Switch B erlaubt:
VLAN 10, 40

Auswirkung:

VLAN 20 funktioniert nicht über diesen Trunk.
VLAN 10 und VLAN 40 funktionieren weiterhin.

Dadurch kann der Eindruck entstehen, der Uplink sei grundsätzlich in Ordnung, obwohl nur ein bestimmtes VLAN fehlt.

8. Was ist ein Native-VLAN- oder ungetaggtes VLAN?

Auf manchen Trunks wird ein definiertes VLAN ungetaggt übertragen. Die genaue Bezeichnung und das Verhalten sind hersteller- und konfigurationsabhängig.

Fehlkonfiguration

Switch A:
ungetaggtes VLAN 10

Switch B:
ungetaggtes VLAN 20

Ein ungetaggter Frame wird dann auf beiden Seiten unterschiedlichen VLANs zugeordnet.

Mögliche Auswirkungen:

Wichtig

Die Begriffe native, untagged, PVID, default VLAN und access VLAN werden von Herstellern nicht immer identisch verwendet. Die Dokumentation des konkret eingesetzten Switches muss geprüft werden.

9. Was ist die PVID?

PVID steht für Port VLAN Identifier. Sie bestimmt bei vielen Switchplattformen, welchem VLAN ein ungetaggt eingehender Frame zugeordnet wird.

Vereinfacht:

Untagged Frame trifft auf Port mit PVID 20
  → Switch ordnet den Frame VLAN 20 zu

Die PVID ist nicht automatisch dasselbe wie die vollständige Liste aus getaggten und ungetaggten VLAN-Mitgliedschaften.

Bei einer Prüfung müssen deshalb getrennt betrachtet werden:

10. Wie wird die lokale VLAN-Konfiguration unter Windows geprüft?

Normale Endgeräte an Access-Ports besitzen häufig keine lokale VLAN-Konfiguration. Die VLAN-Zuordnung erfolgt dann ausschließlich am Switch.

Adapter und erweiterte Eigenschaften anzeigen

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

[RO] Get-NetAdapterAdvancedProperty -Name 'Ethernet'

Nach VLAN-bezogenen Eigenschaften suchen:

[RO] Get-NetAdapterAdvancedProperty -Name 'Ethernet' |
    Where-Object {
        $_.DisplayName -Match 'VLAN|Priority' -or
        $_.RegistryKeyword -Match 'VLAN|Priority'
    } |
    Format-Table DisplayName,
                 DisplayValue,
                 RegistryKeyword,
                 RegistryValue

Wichtige Einschränkung

Bezeichnungen und Verfügbarkeit hängen vom Netzwerktreiber ab. Ein fehlendes VLAN-Feld bedeutet nicht automatisch, dass keine VLAN-Nutzung möglich ist.

Hyper-V-Adapter anzeigen

Falls Hyper-V installiert und der Administrator dafür zuständig ist:

[RO][PRIV] Get-VMNetworkAdapterVlan -ManagementOS

VLAN-Konfiguration virtueller Maschinen:

[RO][PRIV] Get-VM |
    Get-VMNetworkAdapter |
    Get-VMNetworkAdapterVlan

Die Hyper-V-Cmdlets sind nur verfügbar, wenn die entsprechenden Hyper-V-Komponenten installiert sind.

11. Wie wird die VLAN-Konfiguration unter Linux geprüft?

Detaillierte Linkinformationen

[RO] ip -d link show

Bestimmte Schnittstelle

[RO] ip -d link show dev eth0.20

Beispiel einer VLAN-Schnittstelle:

eth0.20@eth0
    vlan protocol 802.1Q id 20
Bestandteil Bedeutung
eth0.20 Name der logischen VLAN-Schnittstelle
@eth0 zugrunde liegende Schnittstelle
802.1Q VLAN-Tagging-Protokoll
id 20 VLAN-ID 20

VLAN-Schnittstellen übersichtlich suchen

[RO] ip -d -o link show |
    grep -i 'vlan'

Linux-Bridge-VLANs

Falls Linux Bridging mit VLAN-Filtering verwendet wird:

[RO][PRIV] sudo bridge vlan show

Detaillierte Bridge-Links:

[RO][PRIV] sudo bridge -d link show

Forwarding-Datenbank beziehungsweise MAC-Tabelle:

[RO][PRIV] sudo bridge fdb show

NetworkManager-Verbindungen

[RO] nmcli connection show

Nur VLAN-Verbindungen:

[RO] nmcli -f NAME,TYPE,DEVICE connection show |
    grep -i vlan

Vollständiges Profil:

[RO][SENS] nmcli connection show "VLAN-VERBINDUNGSNAME"
12. Wie wird die VLAN-Konfiguration unter macOS geprüft?

Alle Schnittstellen

[RO] ifconfig

VLAN-Schnittstellen suchen

[RO] ifconfig -a |
    grep -E '^[[:alnum:]].*:|vlan:'

Eine VLAN-Schnittstelle kann abhängig von Konfiguration und macOS-Version beispielsweise als vlan0 erscheinen.

Netzwerkdienste

[RO] networksetup -listallnetworkservices

Hardwareports

[RO] networksetup -listallhardwareports

Die grafische VLAN-Verwaltung und ihre Verfügbarkeit hängen von macOS-Version, Adapter und Treiber ab. Nicht jeder USB- oder Thunderbolt-Ethernetadapter unterstützt VLAN-Konfigurationen in gleicher Weise.

Ein Mac an einem gewöhnlichen Access-Port benötigt normalerweise keine lokale VLAN-ID.

13. Wie wird geprüft, ob der Client im erwarteten VLAN gelandet ist?

Der Client sieht die VLAN-ID an einem gewöhnlichen Access-Port normalerweise nicht direkt. Deshalb werden mehrere Informationen kombiniert.

Prüfung Erwartetes Ergebnis
Switchportkonfiguration vorgesehenes Access-VLAN
erhaltene DHCP-Adresse Subnetz des vorgesehenen VLANs
Standardgateway Gateway des vorgesehenen VLANs
DNS-Server passende Infrastruktur
sichtbare Nachbarn Geräte des erwarteten Netzes
Switch-MAC-Tabelle Client-MAC am erwarteten Port und VLAN
Vergleichsclient passende Konfiguration am gleichen Standort

Beispiel

Vorgesehen:

VLAN 20
Subnetz 192.0.2.0/24
Gateway 192.0.2.1

Tatsächlich:

Clientadresse 198.51.100.45/24
Gateway 198.51.100.1

Dies ist ein starker Hinweis auf:

14. Wie wird die MAC-Adresstabelle zur VLAN-Diagnose verwendet?

Ein Switch lernt Quell-MAC-Adressen eingehender Frames und ordnet sie normalerweise einem Port und VLAN zu.

Zu prüfende Zuordnung

MAC-Adresse: 00:11:22:33:44:55
VLAN: 20
Port: 17

Mögliche Auffälligkeiten

Beobachtung Mögliche Ursache
MAC nicht gelernt kein Verkehr, Linkproblem, Authentifizierung oder Port blockiert
MAC im falschen VLAN Port- oder Taggingfehler
MAC am falschen Port Dokumentationsfehler, Umstecken oder Layer-2-Schleife
MAC wechselt schnell zwischen Ports Schleife, redundanter Pfad oder Fehlverkabelung
viele MACs an Clientport Switch, Bridge, Hypervisor oder unerlaubtes Gerät angeschlossen
nur Telefon-MAC sichtbar PC-Port des Telefons oder Daten-VLAN prüfen
MAC erscheint hinter Uplink Client befindet sich an nachgelagertem Switch

Die konkreten Befehle zur MAC-Tabelle sind herstellerabhängig. Suchkriterium sollte die zuvor eindeutig ermittelte Client-MAC-Adresse sein.

15. Wie werden Voice-VLAN und angeschlossener PC berücksichtigt?

Ein IP-Telefon kann zwei logische Verbindungen bereitstellen:

Switchport
  → Voice-VLAN für Telefon
  → Data-VLAN für PC hinter dem Telefon

Mögliche Fehlerbilder:

Zu prüfen sind:

16. Wie beeinflussen 802.1X und dynamische VLAN-Zuweisung die Diagnose?

Bei portbasierter Netzwerkzugangskontrolle kann ein Gerät abhängig von seiner Authentifizierung einem VLAN zugewiesen werden.

Vereinfachter Ablauf:

Client
  → Switch oder Access Point
    → Authentifizierungsdienst
      → Zugelassenes VLAN

Mögliche Ergebnisse:

Typische Symptome

Zu erfassen

Das manuelle Setzen eines festen VLANs kann die eigentliche Authentifizierungsstörung verdecken und Sicherheitsrichtlinien umgehen.

17. Wie beeinflusst Spanning Tree die Layer-2-Kommunikation?

Spanning Tree verhindert Layer-2-Schleifen, indem redundante Pfade kontrolliert blockiert werden.

Mögliche Portzustände beziehungsweise Rollen unterscheiden sich je nach verwendeter STP-Variante und Hersteller. Für die Diagnose ist entscheidend, ob der erwartete Port Nutzdaten weiterleitet.

Mögliche Symptome

Wichtige Prüfung

Ist der Port für das betroffene VLAN im Zustand Forwarding?

Ein physisch aktiver Port kann durch Spanning Tree logisch blockiert sein.

Warnung

[CHANGE][DISRUPT] Spanning Tree darf nicht als schnelle Fehlerbehebung
deaktiviert werden. Dadurch können Layer-2-Schleifen und großflächige
Netzwerkausfälle entstehen.
18. Was ist eine Layer-2-Schleife und wie wird sie erkannt?

Ethernetframes besitzen auf Layer 2 kein mit IP-TTL direkt vergleichbares allgemeines Feld, das eine Schleife zuverlässig beendet. Eine Schleife kann deshalb zu einem Broadcast Storm führen.

Mögliche Symptome

Sicheres Vorgehen

  1. Netzwerkverantwortliche und Incident-Prozess aktivieren.
  2. betroffene Switches und VLANs bestimmen,
  3. STP-Ereignisse und MAC-Flapping prüfen,
  4. letzte Verkabelungs- und Portänderungen kontrollieren,
  5. Schleifenpfad anhand der Topologie eingrenzen,
  6. nur koordiniert einen eindeutig bestimmten Port isolieren,
  7. Stabilisierung und Ursache dokumentieren.

Ein wahlloses Entfernen von Uplinks kann Redundanz und weitere Standorte beeinträchtigen.

19. Wie wirken Port-Security und MAC-Limits?

Port-Security kann die Anzahl oder Identität zugelassener MAC-Adressen begrenzen.

Mögliche Reaktionen bei einem Verstoß:

Typische Ursachen eines Verstoßes

Zu prüfen

Port-Security darf nicht einfach deaktiviert werden, ohne Sicherheitszweck und Richtlinie zu prüfen.

20. Wie werden private oder zufällige MAC-Adressen berücksichtigt?

Moderne Betriebssysteme können bei WLAN-Verbindungen private beziehungsweise zufällige MAC-Adressen verwenden. Abhängig von Plattform und Konfiguration kann dies auch die Wiedererkennung eines Geräts beeinflussen.

Mögliche Auswirkungen:

Prüfung

Die aktuell verwendete MAC-Adresse muss mit folgenden Stellen verglichen werden:

Eine private MAC-Adresse ist nicht automatisch eine Fehlfunktion. Ihre Verwendung kann beabsichtigter Datenschutzstandard oder durch eine Richtlinie gesteuert sein.

21. Wie werden VLAN-Tags mit Wireshark geprüft?

Wireshark-Display-Filter für VLAN-Tags

vlan

Bestimmte VLAN-ID:

vlan.id == 20

Mehrere VLAN-IDs:

vlan.id == 20 || vlan.id == 40

Nur DHCP in VLAN 20:

vlan.id == 20 && (udp.port == 67 || udp.port == 68)

Capture-Filter

vlan

Bestimmtes VLAN:

vlan 20

Bestimmtes VLAN und Host:

vlan 20 and host 192.0.2.23

Zeitlich begrenzte Aufnahme

[TEST][PRIV][FILE][SENS] dumpcap \
  -i INTERFACE \
  -f "vlan 20" \
  -a duration:30 \
  -w vlan20.pcapng

TShark-Auswertung

[RO][SENS] tshark \
  -r vlan20.pcapng \
  -Y "vlan" \
  -T fields \
  -e frame.time \
  -e eth.src \
  -e eth.dst \
  -e vlan.id \
  -e vlan.priority

Lokal verfügbare VLAN-Felder:

[RO] tshark -G fields |
    grep -E $'\tvlan\.'
22. Warum ist ein VLAN-Tag im Clientmitschnitt möglicherweise nicht sichtbar?

Mögliche Gründe:

  1. Der Client befindet sich an einem Access-Port und empfängt ungetaggte Frames.
  2. Der Netzwerkadapter entfernt VLAN-Tags in Hardware.
  3. Der Treiber übergibt Tags nicht an das Capture-Werkzeug.
  4. Offloading beeinflusst die lokale Darstellung.
  5. Es wurde auf der falschen Schnittstelle mitgeschnitten.
  6. Der Tag befindet sich nur auf einem anderen Abschnitt des Netzwerkweges.
  7. Eine virtuelle Bridge oder ein Hypervisor verarbeitet den Tag vor der Aufzeichnung.
Kein sichtbarer VLAN-Tag im lokalen Mitschnitt
≠ kein VLAN im Netzwerk

Für die Prüfung eines Trunks ist ein geeigneter Messpunkt am Trunk beziehungsweise ein korrekt konfigurierter Mirror-Port erforderlich. Eine solche Aufzeichnung muss autorisiert und datenschutzgerecht durchgeführt werden.

23. Wie werden virtuelle Maschinen und Hypervisor-VLANs berücksichtigt?

Mögliche Modelle:

VLAN-Zuordnung am virtuellen Switch

VM sendet ungetaggt
  → virtueller Switch ordnet VLAN 40 zu
    → physischer Uplink überträgt VLAN 40 getaggt

VLAN-Zuordnung in der VM

VM erzeugt 802.1Q-Tag
  → virtueller Switch reicht Tag durch
    → physischer Trunk transportiert VLAN

Mögliche Fehler

Zu prüfen sind:

24. Wie werden Linux-Bridge und Container-VLANs berücksichtigt?

Vereinfachter Pfad:

Container oder VM
  → virtuelle Schnittstelle
    → Linux-Bridge
      → VLAN-Filterung
        → physische Schnittstelle
          → Switch-Trunk

Bridge-Übersicht

[RO][PRIV] sudo bridge link show

VLAN-Zuordnungen

[RO][PRIV] sudo bridge vlan show

MAC-Tabelle der Bridge

[RO][PRIV] sudo bridge fdb show

Detaillierte Links

[RO] ip -d link show

Mögliche Fehler:

Docker-Standardbridges verwenden nicht automatisch dieselbe VLAN-Struktur wie ein physischer Switch. Das konkrete Container- und Hostnetz muss separat dokumentiert werden.

25. Wie werden VLANs über mehrere Switches verfolgt?

Beispielpfad

CLIENT-023
  → SW-ACCESS-01 Port 17
    → VLAN 20
      → Uplink 1
        → SW-DISTRIBUTION-01
          → Port-Channel 10
            → SW-CORE-01
              → Gateway VLAN 20

Für jeden Abschnitt wird geprüft:

Abschnitt Prüfung
Clientport Access-VLAN und Client-MAC
erster Switch MAC wird im richtigen VLAN gelernt
Uplink VLAN 20 ist erlaubt
nächster Switch VLAN existiert und ist aktiv
Linkaggregation alle Mitglieder sind konsistent
Spanning Tree erwarteter Pfad ist forwarding
Gateway VLAN-Interface ist aktiv
Rückweg führt zurück in dasselbe Client-VLAN

Methode

Die Client-MAC-Adresse wird vom Access-Port in Richtung Core verfolgt. Die Gateway-MAC-Adresse wird in Gegenrichtung geprüft.

27. Wie wird zwischen VLAN-, DHCP- und Routingproblem unterschieden?
Beobachtung Wahrscheinlichere Richtung
keine DHCP-Adresse, ARP ebenfalls ohne Antwort VLAN oder Layer 2 möglich
DHCP-Adresse aus falschem Subnetz falsches VLAN oder Rogue-DHCP möglich
korrekte Adresse, Gateway-MAC nicht auflösbar VLAN, Gatewayinterface oder Layer 2
Gateway erreichbar, anderes VLAN nicht Routing oder Firewall
Geräte im selben VLAN kommunizieren lokales Layer 2 grundsätzlich aktiv
nur ein Trunkabschnitt betroffen erlaubte VLANs oder Tagging
nur neue Clients betroffen DHCP oder Zugangskontrolle
nur ein Port betroffen Access-VLAN, Port-Security oder Verkabelung
alle Ports eines VLANs betroffen VLAN, Gateway, STP oder Uplink
VLAN lokal verfügbar, über Uplink nicht Trunk oder Spanning Tree
Ziel wird im falschen Subnetz gesucht Clientpräfix oder DHCP-Option

Ein Fehler kann mehrere Ebenen gleichzeitig betreffen. Beispielsweise kann ein falsches Access-VLAN zu einer falschen DHCP-Konfiguration führen.

28. Welche eingreifenden Änderungen dürfen nicht vorschnell erfolgen?
Änderung Risiko
Access-VLAN ändern Client verliert Verbindung oder landet im falschen Sicherheitsbereich
Trunk-VLAN hinzufügen unerwartete Netze werden erweitert
Trunk-VLAN entfernen gesamtes VLAN fällt über den Uplink aus
natives VLAN ändern ungetaggter Verkehr wird falsch zugeordnet
Port auf Trunk umstellen Endgerät kann Tags erhalten oder Sicherheitsgrenze verändert sich
Port-Security deaktivieren Zugriffsschutz wird aufgehoben
802.1X umgehen Sicherheitsrichtlinie wird umgangen
Spanning Tree deaktivieren Layer-2-Schleife und Broadcast Storm möglich
Port-Channel verändern mehrere Verbindungen können ausfallen
VLAN auf Hypervisor ändern VM- oder Managementzugriff kann ausfallen
VLAN-Interface löschen IP-Kommunikation dieses Netzes fällt aus

Vor jeder Änderung müssen dokumentiert werden:

29. Welche typischen Fehlinterpretationen müssen vermieden werden?
Beobachtung Falscher Schluss Richtige Einordnung
Link ist aktiv VLAN ist korrekt Link und VLAN sind getrennte Zustände
Client sieht keinen VLAN-Tag kein VLAN vorhanden Access-Port liefert gewöhnlich ungetaggte Frames
DHCP funktioniert VLAN ist korrekt DHCP kann aus falschem VLAN stammen
Ping im VLAN funktioniert Trunk ist vollständig korrekt andere VLANs können fehlen
VLAN 20 funktioniert lokal VLAN 20 funktioniert überall Uplinkpfad separat prüfen
MAC fehlt in Tabelle Gerät ist ausgeschaltet Authentifizierung, Port oder fehlende Aktivität möglich
MAC wechselt den Port Angriff Schleife, Redundanz oder legitime Migration möglich
STP blockiert Port STP ist defekt Blockierung kann notwendiger Schleifenschutz sein
mehrere MACs am Port unerlaubter Switch Telefon, Hypervisor oder Bridge möglich
gleiche VLAN-ID gleiches Layer-2-Netz getrennte Switchdomänen können dieselbe ID verwenden
Portwechsel behebt Fehler Switchport ist defekt anderer Port kann anderes VLAN oder Policy besitzen
VLAN hinzufügen behebt Fehler Änderung war korrekt Sicherheits- und Architekturprüfung bleibt erforderlich
30. Wie sieht der systematische Prüfablauf aus?
Schritt Prüfung
1 Client, MAC-Adresse, Switch und Port bestimmen
2 vorgesehenes VLAN und Subnetz aus Dokumentation ermitteln
3 aktuelle Clientadresse mit dem vorgesehenen VLAN vergleichen
4 Portmodus, Access-VLAN, PVID und Voice-VLAN prüfen
5 Authentifizierungs- und Port-Security-Status prüfen
6 Client-MAC in der Switchtabelle suchen
7 Gateway-MAC und lokale Kommunikation prüfen
8 betroffenen VLAN-Pfad über alle Uplinks verfolgen
9 erlaubte und getaggte VLANs auf beiden Seiten vergleichen
10 Spanning-Tree-Zustand je betroffenem VLAN prüfen
11 Linkaggregation und Mitgliedsports vergleichen
12 virtuelle Switches und Bridges einbeziehen
13 bei Bedarf autorisierten Mitschnitt am geeigneten Messpunkt erstellen
14 Hypothese mit einer einzelnen kontrollierten Änderung testen
15 DHCP, Gateway und Zielverbindung erneut prüfen
16 ursprüngliche Konfiguration beziehungsweise Rückweg dokumentieren

Merksatz

Client-MAC → Access-Port → VLAN → Uplink → Trunk
→ Spanning Tree → Gateway
31. Kompakte Befehlsübersicht
Aufgabe Windows Linux macOS
Adapter anzeigen [RO] Get-NetAdapter [RO] ip -brief link [RO] ifconfig
VLAN-Eigenschaften der NIC [RO] Get-NetAdapterAdvancedProperty -Name 'Ethernet' [RO] ip -d link show [RO] ifconfig -a
VLAN-Schnittstellen suchen treiberabhängig [RO] ip -d -o link show | grep -i vlan `[RO] ifconfig -a | grep -E '^[[:alnum:]].*:
Hyper-V-VLANs [RO][PRIV] Get-VMNetworkAdapterVlan -ManagementOS nicht zutreffend nicht zutreffend
VM-VLANs [RO][PRIV] Get-VM | Get-VMNetworkAdapter | Get-VMNetworkAdapterVlan hypervisorabhängig hypervisorabhängig
Linux-Bridge-VLANs nicht zutreffend [RO][PRIV] sudo bridge vlan show nicht standardmäßig gleichwertig
Linux-Bridge-MAC-Tabelle nicht zutreffend [RO][PRIV] sudo bridge fdb show nicht standardmäßig gleichwertig
VLAN-Tags anzeigen [RO][SENS] tshark -r DATEI -Y "vlan" gleicher Befehl gleicher Befehl
VLAN 20 mitschneiden [TEST][PRIV][FILE][SENS] dumpcap -i INTERFACE -f "vlan 20" -a duration:30 -w vlan20.pcapng gleicher Befehl gleicher Befehl
DHCP in VLAN 20 anzeigen [RO][SENS] tshark -r DATEI -Y "vlan.id == 20 && (udp.port == 67 || udp.port == 68)" gleicher Befehl gleicher Befehl

Switchbefehle sind hersteller- und betriebssystemspezifisch. Für produktive Switches müssen ausschließlich die offiziellen Befehle der tatsächlich eingesetzten Plattform verwendet werden.

32. Dokumentationsvorlage 
Ticketnummer:
Prüfzeitpunkt:
Zeitzone:
Standort:
Betroffener Client:
Client-MAC:
Client-IP:
Erwartetes Subnetz:
Erwartetes Gateway:
Erwartete VLAN-ID:

ACCESS-PORT

Switch:
Switchmodell:
Switch-Betriebssystem:
Switchport:
Portbeschreibung:
Administrativer Status:
Operativer Status:
Portmodus:
Access-/Data-VLAN:
Voice-VLAN:
PVID:
Getaggte VLANs:
Ungetaggte VLANs:
802.1X-Status:
Dynamisch zugewiesenes VLAN:
Port-Security-Status:
Erlaubte MAC-Anzahl:
Gelernte MAC-Adressen:
Verstoßzähler:
STP-Zustand:
Fehlerzähler:

UPLINKPFAD

Switch 1:
Ausgangsport:
Erlaubte VLANs:
Natives/ungetaggtes VLAN:
Port-Channel:
STP-Zustand:

Switch 2:
Eingangsport:
Erlaubte VLANs:
Natives/ungetaggtes VLAN:
Port-Channel:
STP-Zustand:

Weitere Switches:
-

GATEWAY

Gatewaygerät:
VLAN-Interface:
Interfacezustand:
Gateway-IP:
Gateway-MAC:
Routing aktiv:
Firewall beteiligt:

CLIENTPRÜFUNG

Erhaltene IPv4-Adresse:
Präfix:
DHCP-Server:
Standardgateway:
DNS-Server:
Gateway-MAC aufgelöst:
Gateway erreichbar:
Referenzclient:
Relevante Abweichungen:

VIRTUELLE INFRASTRUKTUR

Hypervisor:
Virtueller Switch:
Portgruppe:
VM-VLAN:
Physischer Uplink:
Bridge-VLAN:
PVID:
Getaggt/ungetaggt:

PAKETMITSCHNITT

Messpunkt:
Sichtbare VLAN-ID:
Erwartete VLAN-ID:
DHCP sichtbar:
ARP sichtbar:
Unbeabsichtigter Fremdverkehr:
Capture-Datei:
Hash:

Arbeitshypothese:
Begründung:
Gesicherte Ausgangskonfiguration:
Geplante Änderung:
Freigabe:
Rückweg:
Tatsächliches Ergebnis:
Abschlussprüfung:
Ermittelte Ursache:
33. Offizielle Quellen und weiterführende Dokumentation

Microsoft

Linux

Apple

Wireshark

Standards

VLAN-Begriffe und Konfigurationsmodelle unterscheiden sich zwischen Switchherstellern. Insbesondere die Bedeutung von Access, Trunk, Tagged, Untagged, Native VLAN und PVID muss anhand der offiziellen Dokumentation des konkret eingesetzten Geräts geprüft werden.

3. Netzwerkfehler systematisch analysieren

3.7 Standardgateway und Routing analysieren

Routing bestimmt, über welchen Netzwerkpfad ein IP-Paket sein Ziel erreicht. Liegt das Ziel nicht im direkt angeschlossenen Subnetz, benötigt der Client eine passende Route zu einem Router beziehungsweise Next Hop.

Das Standardgateway wird verwendet, wenn keine spezifischere Route zum Ziel vorhanden ist. Eine vorhandene Standardroute beweist jedoch nicht, dass sie korrekt ist oder dass der vollständige Hin- und Rückweg funktioniert.

Grundregel: Nicht nur prüfen, ob eine Route vorhanden ist. Es muss geprüft werden, welche Route für das konkrete Ziel tatsächlich ausgewählt wird und ob ein passender Rückweg existiert.

1. Welche Aufgaben erfüllt ein Router?

Ein Router verbindet unterschiedliche IP-Netze.

Beispiel

Clientnetz:
192.0.2.0/24

Servernetz:
198.51.100.0/24

Kommunikationsweg:

CLIENT-023
192.0.2.23/24
  │
  ├─ Standardgateway 192.0.2.1
  │
  ├─ Router oder Firewall
  │
  └─ SERVER-01
       198.51.100.20/24

Der Client erkennt anhand seines Präfixes, dass 198.51.100.20 nicht im lokalen Subnetz liegt. Er übergibt das Paket deshalb an einen Router.

Der Router:

  1. liest die Ziel-IP-Adresse,
  2. sucht die passendste Route,
  3. bestimmt Ausgangsschnittstelle und nächsten Hop,
  4. verringert bei IPv4 die TTL beziehungsweise bei IPv6 den Hop Limit,
  5. leitet das Paket weiter oder verwirft es.
2. Wann wird das Standardgateway verwendet?

Die IPv4-Standardroute lautet:

0.0.0.0/0

Die IPv6-Standardroute lautet:

::/0

Sie passen grundsätzlich auf jedes Ziel der jeweiligen Adressfamilie. Spezifischere Routen werden jedoch bevorzugt.

Beispielroutingtabelle

Zielpräfix Next Hop Bedeutung
192.0.2.0/24 direkt verbunden lokales Clientnetz
198.51.100.0/24 192.0.2.254 spezifische Route zum Servernetz
0.0.0.0/0 192.0.2.1 Standardroute

Für das Ziel 198.51.100.20 wird die spezifische /24-Route verwendet und nicht die Standardroute.

3. Was bedeutet Longest Prefix Match?

Wenn mehrere Routen zu einem Ziel passen, wird grundsätzlich die Route mit dem längsten passenden Präfix bevorzugt.

Beispiel

Route Passt auf 198.51.100.20? Präfixlänge
0.0.0.0/0 Ja 0
198.51.0.0/16 Ja 16
198.51.100.0/24 Ja 24
198.51.100.20/32 Ja 32

Ausgewählt wird:

198.51.100.20/32

Reihenfolge:

Hostroute /32
  vor
Netzroute /24
  vor
gröberer Netzroute /16
  vor
Standardroute /0

Eine Route mit niedrigerer Metrik gewinnt nicht gegen eine passendere Route mit längerem Präfix. Die Metrik wird für konkurrierende, in der Auswahl gleich geeignete Routen relevant.

4. Welche Bestandteile besitzt ein Routingtabelleneintrag?
Bestandteil Bedeutung
Zielpräfix Netz oder Host, für den die Route gilt
Präfixlänge Genauigkeit der Route
Next Hop nächster Router
Ausgangsschnittstelle verwendeter Adapter
Quelladresse für das Ziel ausgewählte lokale Adresse
Metrik Kosten beziehungsweise Priorität
Protokoll oder Ursprung statisch, verbunden, DHCP oder Routingprotokoll
Gültigkeitsdauer bei dynamischen Einträgen möglicherweise begrenzt
Routingtabelle bei Policy Routing eine bestimmte Tabelle

Beispiel

198.51.100.0/24 via 192.0.2.254 dev eth0 metric 100
Feld Wert
Ziel 198.51.100.0/24
Next Hop 192.0.2.254
Schnittstelle eth0
Metrik 100
5. Welche Symptome sprechen für einen Routingfehler?
6. Wie wird die Routingtabelle unter Windows angezeigt?

IPv4-Routen

[RO] Get-NetRoute -AddressFamily IPv4 |
    Sort-Object DestinationPrefix, RouteMetric |
    Format-Table ifIndex,
                 InterfaceAlias,
                 DestinationPrefix,
                 NextHop,
                 RouteMetric,
                 InterfaceMetric,
                 Protocol,
                 State

IPv6-Routen

[RO] Get-NetRoute -AddressFamily IPv6 |
    Sort-Object DestinationPrefix, RouteMetric |
    Format-Table ifIndex,
                 InterfaceAlias,
                 DestinationPrefix,
                 NextHop,
                 RouteMetric,
                 InterfaceMetric,
                 Protocol,
                 State

Klassische Gesamtausgabe

[RO] route print

Nur IPv4:

[RO] route print -4

Nur IPv6:

[RO] route print -6

Standardrouten

[RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' |
    Format-Table InterfaceAlias,
                 ifIndex,
                 NextHop,
                 RouteMetric,
                 InterfaceMetric,
                 Protocol

IPv6:

[RO] Get-NetRoute -DestinationPrefix '::/0'
7. Wie wird unter Windows die tatsächlich ausgewählte Route geprüft? 
[RO] Find-NetRoute -RemoteIPAddress 198.51.100.20

Die Ausgabe enthält typischerweise:

Zusätzliche Schnittstelleninformationen

[RO] Get-NetIPInterface |
    Sort-Object AddressFamily, InterfaceMetric |
    Format-Table ifIndex,
                 InterfaceAlias,
                 AddressFamily,
                 ConnectionState,
                 InterfaceMetric,
                 AutomaticMetric

Konkrete Zielprüfung

[TEST] Test-NetConnection 198.51.100.20 -InformationLevel Detailed

Mit Traceroute:

[TEST] Test-NetConnection 198.51.100.20 `
    -TraceRoute `
    -InformationLevel Detailed

Test-NetConnection -TraceRoute prüft den Pfad mit den von Windows dafür vorgesehenen Diagnosemechanismen. Ein nicht antwortender Hop beweist nicht automatisch einen Weiterleitungsfehler.

8. Wie wird die Routingtabelle unter Linux angezeigt?

IPv4-Hauptroutingtabelle

[RO] ip -4 route show

IPv6-Hauptroutingtabelle

[RO] ip -6 route show

Alle Routingtabellen

[RO] ip route show table all

IPv6:

[RO] ip -6 route show table all

Standardroute

[RO] ip route show default

IPv6:

[RO] ip -6 route show default

Detaillierte Routen

[RO] ip -details route show

Routingregeln

[RO] ip rule show

Policy Routing kann dazu führen, dass eine andere Tabelle verwendet wird als die gewöhnliche main-Tabelle.

9. Wie wird unter Linux die tatsächlich ausgewählte Route geprüft? 
[RO] ip route get 198.51.100.20

Beispiel:

198.51.100.20 via 192.0.2.1 dev eth0 src 192.0.2.23 uid 1000
Feld Bedeutung
Ziel 198.51.100.20
via nächster Router
dev Ausgangsschnittstelle
src ausgewählte Quelladresse
uid bei entsprechender Ausgabe berücksichtigte Benutzer-ID

Route mit bestimmter Quelladresse prüfen

[RO] ip route get 198.51.100.20 from 192.0.2.23

IPv6

[RO] ip -6 route get 2001:db8:20::20

Bei Policy Routing kann die Routenauswahl von folgenden Merkmalen abhängen:

10. Wie wird die Routingtabelle unter macOS angezeigt?

IPv4-Routen

[RO] netstat -rn -f inet

IPv6-Routen

[RO] netstat -rn -f inet6

IPv4-Standardroute

[RO] route -n get default

Ausgewählte Route zu einem IPv4-Ziel

[RO] route -n get 198.51.100.20

Ausgewählte Route zu einem IPv6-Ziel

[RO] route -n get -inet6 2001:db8:20::20

Typische Felder:

Feld Bedeutung
destination Ziel
gateway Next Hop
interface Ausgangsschnittstelle
flags Routeneigenschaften
recvpipe/sendpipe interne Routinginformationen
mtu routenbezogene MTU, falls vorhanden

VPN-Verbindungen erscheinen unter macOS häufig über Tunnelinterfaces wie utun0, utun1 oder weitere nummerierte Varianten.

11. Wie werden mehrere Standardrouten bewertet?

Mehrere Standardrouten können beabsichtigt sein:

Windows

[RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' |
    Sort-Object RouteMetric, InterfaceMetric |
    Format-Table InterfaceAlias,
                 NextHop,
                 RouteMetric,
                 InterfaceMetric,
                 Protocol

Linux

[RO] ip route show default

[RO] ip rule show

macOS

[RO] netstat -rn -f inet |
    grep '^default'

Prüffragen

  1. Welche Route gehört zur aktiven Schnittstelle?
  2. Welche Route besitzt die wirksame Priorität?
  3. Gibt es spezifischere VPN-Routen?
  4. Welche Quelladresse wird ausgewählt?
  5. Passt der Rückweg zu dieser Quelladresse?
  6. Ist eine Route nur ein verbliebener Eintrag eines getrennten Adapters?
  7. Wird IPv4 anders als IPv6 geroutet?

Die numerische Metrik ist nicht zwischen verschiedenen Betriebssystemen direkt vergleichbar.

12. Wie beeinflussen Schnittstellen- und Routenmetrik die Auswahl unter Windows?

Windows berücksichtigt unter anderem:

Vereinfacht kann bei gleich spezifischen Routen eine Kombination aus Routen- und Schnittstellenmetrik die bevorzugte Route beeinflussen.

Schnittstellenmetriken

[RO] Get-NetIPInterface |
    Format-Table InterfaceAlias,
                 AddressFamily,
                 AutomaticMetric,
                 InterfaceMetric,
                 ConnectionState

Routenmetriken

[RO] Get-NetRoute |
    Format-Table DestinationPrefix,
                 NextHop,
                 InterfaceAlias,
                 RouteMetric,
                 InterfaceMetric

Eine aktivierte automatische Metrik lässt Windows den Wert anhand der Schnittstelleneigenschaften bestimmen.

[CHANGE][DISRUPT] Metriken nicht verändern, nur weil eine numerische
Reihenfolge unerwartet aussieht. Zuerst die tatsächlich gewählte Route
mit Find-NetRoute prüfen.
13. Was ist eine Hostroute?

Eine Hostroute gilt nur für eine einzelne Zieladresse.

IPv4

198.51.100.20/32

IPv6

2001:db8:20::20/128

Beispiel:

198.51.100.20/32 via 192.0.2.254
0.0.0.0/0 via 192.0.2.1

Nur das Ziel 198.51.100.20 wird über 192.0.2.254 geleitet. Andere Ziele verwenden weiterhin die Standardroute.

Mögliche Fehler

14. Was ist Policy-Based Routing?

Bei gewöhnlichem Routing wird hauptsächlich die Zieladresse betrachtet. Policy-Based Routing kann zusätzliche Kriterien verwenden:

Linux-Regeln anzeigen

[RO] ip rule show

Beispielstruktur:

0:      from all lookup local
100:    from 192.0.2.0/24 lookup firma-a
32766:  from all lookup main
32767:  from all lookup default

Tabelle anzeigen:

[RO] ip route show table firma-a

Falls die Tabelle nur eine Nummer besitzt:

[RO] ip route show table 100

Eine korrekte Route in der main-Tabelle beweist bei Policy Routing nicht, dass sie für den konkreten Datenstrom verwendet wird.

15. Was ist eine VRF und warum ist sie für die Diagnose wichtig?

Eine Virtual Routing and Forwarding Instance stellt eine getrennte Routingdomäne bereit.

Vereinfacht:

Router
├─ VRF FIRMA-A
│   └─ eigene Routingtabelle
└─ VRF FIRMA-B
    └─ eigene Routingtabelle

Dieselben IP-Netze können in getrennten VRFs vorkommen, ohne direkt miteinander verbunden zu sein.

Mögliche Fehler

Linux-VRFs anzeigen, falls verwendet:

[RO] ip -d link show type vrf

Routen einer Tabelle:

[RO] ip route show table TABELLENNAME

Befehle auf Routern und Firewalls sind herstellerabhängig und müssen im korrekten Routingkontext ausgeführt werden.

16. Wie wird ein fehlender Rückweg erkannt?

Für eine funktionierende Kommunikation werden Hin- und Rückweg benötigt.

Hinweg:
CLIENT-023 → Router A → SERVER-01

Rückweg:
SERVER-01 → Router B → CLIENT-023

Ein Rückweg darf anders verlaufen, muss aber:

Typische Symptome eines fehlenden Rückwegs

Prüfung

  1. Clientroute zum Server prüfen.
  2. Serverroute zur Clientadresse prüfen.
  3. Zwischenrouter und Firewalls prüfen.
  4. NAT-Zustände berücksichtigen.
  5. Paketmitschnitt an mindestens zwei geeigneten Messpunkten vergleichen.
17. Was ist asymmetrisches Routing?

Beim asymmetrischen Routing nehmen Hin- und Rückweg unterschiedliche Pfade.

Hinweg:
Client → Firewall A → Server

Rückweg:
Server → Firewall B → Client

Asymmetrisches Routing ist nicht grundsätzlich fehlerhaft. Es kann jedoch problematisch sein für:

Typische Hinweise

Die ausführliche Analyse asymmetrischer Wege wird auf Seite 3.17 behandelt.

18. Wie wird der Netzwerkpfad mit tracert oder traceroute untersucht?

Windows

Ohne Namensauflösung:

[TEST] tracert -d 198.51.100.20

Mit Zielname:

[TEST] tracert app.example.intern

Linux

[TEST] traceroute -n 198.51.100.20

macOS

[TEST] traceroute -n 198.51.100.20

Prinzip

Traceroute sendet Pakete mit schrittweise erhöhtem TTL- beziehungsweise Hop-Limit-Wert.

TTL 1 → erster Router
TTL 2 → zweiter Router
TTL 3 → dritter Router

Ein Router, an dem der Wert abläuft, kann eine ICMP-Time-Exceeded-Nachricht zurücksenden.

Wichtig

19. Wie werden Sternchen in einer Traceroute interpretiert?

Beispiel:

1  192.0.2.1       1 ms
2  203.0.113.1     5 ms
3  * * *
4  198.51.100.20  12 ms

Da Hop 4 antwortet, hat Hop 3 den Verkehr offenbar weitergeleitet. Hop 3 beantwortet nur die Diagnoseanfrage nicht.

Mögliche Gründe für Sternchen

Erst wenn alle nachfolgenden Hops ebenfalls fehlen, kann ab dieser Stelle ein Problem vermutet werden. Selbst dann muss geprüft werden, ob das Ziel oder eine Firewall Diagnoseverkehr absichtlich blockiert.

20. Wie wird eine Routing-Schleife erkannt?

Eine Routing-Schleife entsteht, wenn Router Pakete wiederholt gegenseitig weiterleiten.

Beispiel:

Router A → Router B → Router A → Router B

Mögliche Traceroute-Ausgabe:

5  192.0.2.1
6  192.0.2.2
7  192.0.2.1
8  192.0.2.2
9  192.0.2.1

Mögliche Ursachen

Die TTL beziehungsweise der Hop Limit verhindert, dass ein einzelnes Paket unbegrenzt zirkuliert. Die Schleife kann trotzdem fortlaufend neue Verbindungen beeinträchtigen.

21. Wie werden Paketverlust und Latenz entlang des Pfades bewertet?

Windows PathPing

[TEST] pathping -n 198.51.100.20

PathPing kombiniert eine Pfadermittlung mit längerfristigen Messungen zu den Hops. Die Ausführung kann mehrere Minuten dauern.

Linux und macOS mit MTR

Falls mtr installiert und freigegeben ist:

[TEST] mtr -n -r -c 20 198.51.100.20
Option Bedeutung
-n keine Namensauflösung
-r Bericht erzeugen
-c 20 20 Messzyklen

Interpretationsregel

Paketverlust an einem Zwischenhop,
aber kein Verlust an nachfolgenden Hops
→ wahrscheinlich nur reduzierte Antwortpriorität dieses Hops.

Paketverlust beginnt an einem Hop
und setzt sich bis zum Ziel fort
→ möglicher Verlust ab diesem Pfadabschnitt.

Auch dieses Muster ist nur ein Hinweis. Das verwendete Diagnoseprotokoll kann anders behandelt werden als die eigentliche Anwendung.

22. Wie wird ein bestimmter TCP-Dienst entlang des Pfades berücksichtigt?

Ein erfolgreicher Traceroute beweist nicht, dass ein bestimmter Port zugelassen ist.

Windows

[TEST] Test-NetConnection 198.51.100.20 `
    -Port 443 `
    -InformationLevel Detailed

Linux

[TEST] nc -vz -w 5 198.51.100.20 443

macOS

[TEST] nc -vz -w 5 198.51.100.20 443

Je nach nc-Implementierung können Optionen und Ausgabe abweichen. Lokale Hilfe prüfen:

[RO] nc -h

Bewertung

Test Erfolgreich Fehlgeschlagen
Routingprüfung IP-Pfad grundsätzlich vorhanden Route, Filter oder Ziel offen
TCP-Porttest TCP-Verbindungsaufbau möglich Filter, Dienst, Rückweg oder Routing offen
Anwendungstest Protokollantwort erhalten Anwendung, Authentifizierung oder Backend offen
23. Wie wird eine Route mit einem Paketmitschnitt bestätigt?

Auf einem Ethernetclient zeigt die Ziel-MAC-Adresse, an welchen direkten Nachbarn das Paket übergeben wird.

Entferntes Ziel

IP-Ziel: 198.51.100.20
Ethernet-Ziel: MAC-Adresse des Gateways

Lokales Ziel

IP-Ziel: 192.0.2.80
Ethernet-Ziel: MAC-Adresse des Zielsystems

Wireshark-Filter

Bestimmtes Ziel:

ip.dst == 198.51.100.20

IPv6:

ipv6.dst == 2001:db8:20::20

TTL anzeigen beziehungsweise filtern:

ip.ttl

IPv6 Hop Limit:

ipv6.hlim

ICMP Time Exceeded:

icmp.type == 11

ICMPv6 Time Exceeded:

icmpv6.type == 3

Ein lokaler Mitschnitt zeigt nur den Verkehr am ausgewählten Interface. Er beweist nicht, wie nachfolgende Router das Paket weiterleiten.

24. Wie beeinflussen VPN-Verbindungen die Routingtabelle?

Ein VPN kann folgende Routen installieren:

Full Tunnel

0.0.0.0/0 → VPN

Der gesamte IPv4-Verkehr soll durch den Tunnel geführt werden.

Split Tunnel

10.0.0.0/8 → VPN
0.0.0.0/0 → lokales Gateway

Nur bestimmte Netze werden über das VPN erreicht.

Typische Fehler

Vergleich

Routingtabelle vor VPN-Verbindung
Routingtabelle nach VPN-Verbindung

Dabei dürfen sensible interne Routen nur geschützt dokumentiert werden.

25. Wie werden überlappende Netze erkannt?

Beispiel

Lokales Heimnetz:

192.168.1.0/24

Entferntes Firmennetz über VPN:

192.168.1.0/24

Der Client kann nicht allein anhand der Zieladresse unterscheiden, ob 192.168.1.50 lokal oder über das VPN erreicht werden soll.

Mögliche Auswirkungen:

Prüfung

Windows

[RO] Find-NetRoute -RemoteIPAddress 192.168.1.50

Linux

[RO] ip route get 192.168.1.50

macOS

[RO] route -n get 192.168.1.50

Die nachhaltige Lösung erfordert eine abgestimmte Adressplanung oder ein vorgesehenes VPN-/NAT-Konzept. Willkürliche Hostrouten sind häufig nur eine begrenzte Übergangslösung.

26. Wie werden dynamische Routingprotokolle berücksichtigt?

Router können Routen dynamisch austauschen, beispielsweise über:

Zu prüfen sind:

Typische Symptome

Die konkreten Befehle sind router- und herstellerabhängig. Sie müssen anhand der offiziellen Dokumentation der eingesetzten Plattform ausgewählt werden.

27. Warum dürfen statische Routen nicht vorschnell hinzugefügt werden?

Eine zusätzliche statische Route kann ein Symptom kurzfristig umgehen, aber:

Vorher dokumentieren

28. Welche eingreifenden Routingbefehle existieren?

Die folgenden Beispiele verändern die Routingtabelle und sind keine regulären ersten Diagnoseschritte.

Windows – temporäre Route

[PRIV][CHANGE][DISRUPT] New-NetRoute `
    -DestinationPrefix '198.51.100.0/24' `
    -InterfaceAlias 'Ethernet' `
    -NextHop '192.0.2.254' `
    -RouteMetric 10 `
    -PolicyStore ActiveStore

Route entfernen:

[PRIV][CHANGE][DISRUPT] Remove-NetRoute `
    -DestinationPrefix '198.51.100.0/24' `
    -InterfaceAlias 'Ethernet' `
    -NextHop '192.0.2.254'

Linux – Route hinzufügen

[PRIV][CHANGE][DISRUPT] sudo ip route add \
    198.51.100.0/24 \
    via 192.0.2.254 \
    dev eth0

Route entfernen:

[PRIV][CHANGE][DISRUPT] sudo ip route del \
    198.51.100.0/24 \
    via 192.0.2.254 \
    dev eth0

macOS – temporäre Route hinzufügen

[PRIV][CHANGE][DISRUPT] sudo route -n add \
    -net 198.51.100.0/24 \
    192.0.2.254

Route entfernen:

[PRIV][CHANGE][DISRUPT] sudo route -n delete \
    -net 198.51.100.0/24 \
    192.0.2.254

Vor der Ausführung müssen Interface, Next Hop, Präfix und Rückweg geprüft werden. Eine falsche Route kann den Remotezugriff sofort unterbrechen. Temporäre Betriebssystemrouten sind außerdem nicht automatisch nach einem Neustart persistent.

29. Welche typischen Fehlinterpretationen müssen vermieden werden?
Beobachtung Falscher Schluss Richtige Einordnung
Standardroute vorhanden Routing funktioniert Next Hop und Rückweg prüfen
Gateway antwortet auf Ping alle Ziele sind erreichbar nur ICMP zum Gateway bestätigt
Traceroute zeigt Sterne dort liegt der Fehler Hop antwortet möglicherweise nur nicht
hohe Zeit an einem Hop dieser Hop bremst den Verkehr Antwortpriorisierung kann abweichen
Verlust an Zwischenhop dort gehen Nutzdaten verloren nachfolgende Hops vergleichen
Zielroute ist sichtbar sie wird verwendet konkrete Auswahl zum Ziel prüfen
niedrigste Metrik gewinnt immer Route ist bevorzugt längstes passendes Präfix zuerst
Hinweg funktioniert Verbindung muss funktionieren Rückweg kann fehlen
asymmetrischer Pfad zwingend Fehlkonfiguration kann beabsichtigt, aber für Stateful-Systeme problematisch sein
Route hinzufügen behebt Zugriff Ursache ist gelöst ursprünglicher Routingfehler kann verdeckt sein
VPN verbunden interne Routen sind korrekt konkrete Zielroute prüfen
Ping über IP funktioniert DNS und Anwendung funktionieren nur IP-/ICMP-Test bestätigt
30. Wie sieht der systematische Prüfablauf aus?
Schritt Prüfung
1 Quell- und Zieladresse eindeutig bestimmen
2 Präfix des Clients prüfen
3 feststellen, ob das Ziel lokal oder entfernt ist
4 aktuelle Routingtabelle unverändert sichern
5 ausgewählte Route zum konkreten Ziel bestimmen
6 Ausgangsschnittstelle, Quelladresse und Next Hop prüfen
7 direkten Next Hop über ARP beziehungsweise NDP kontrollieren
8 Ziel per IP und passendem Dienst testen
9 Pfad mit Traceroute oder vergleichbarem Werkzeug untersuchen
10 Router- und Firewallrouting entlang des Pfades prüfen
11 Rückroute vom Ziel zur tatsächlichen Quelladresse kontrollieren
12 VPN, Policy Routing, VRF und NAT berücksichtigen
13 Routingtabellen redundanter Systeme vergleichen
14 Hypothese mit Mitschnitt oder gezieltem Test bestätigen
15 Änderungen nur mit Freigabe und Rückweg durchführen
16 Funktion und Nebenwirkungen abschließend prüfen

Merksatz

Ziel bestimmen → Longest Prefix Match → Quelladresse
→ Interface → Next Hop → Hinweg → Rückweg
31. Kompakte Befehlsübersicht für Windows, Linux und macOS
Aufgabe Windows Linux macOS
IPv4-Routen [RO] Get-NetRoute -AddressFamily IPv4 [RO] ip -4 route [RO] netstat -rn -f inet
IPv6-Routen [RO] Get-NetRoute -AddressFamily IPv6 [RO] ip -6 route [RO] netstat -rn -f inet6
klassische Gesamtausgabe [RO] route print [RO] ip route show table all [RO] netstat -rn
IPv4-Standardroute [RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' [RO] ip route show default [RO] route -n get default
IPv6-Standardroute [RO] Get-NetRoute -DestinationPrefix '::/0' [RO] ip -6 route show default [RO] netstat -rn -f inet6
Route zu IPv4-Ziel [RO] Find-NetRoute -RemoteIPAddress ZIEL [RO] ip route get ZIEL [RO] route -n get ZIEL
Route zu IPv6-Ziel [RO] Find-NetRoute -RemoteIPAddress ZIEL [RO] ip -6 route get ZIEL [RO] route -n get -inet6 ZIEL
Routingregeln Windows-Routingauswahl prüfen [RO] ip rule show Systemroutingtabelle prüfen
Schnittstellenmetrik [RO] Get-NetIPInterface Routingmetriken in ip route Routenflags und Dienstreihenfolge
Pfad ohne DNS [TEST] tracert -d ZIEL [TEST] traceroute -n ZIEL [TEST] traceroute -n ZIEL
längere Pfadmessung [TEST] pathping -n ZIEL [TEST] mtr -n -r -c 20 ZIEL [TEST] mtr -n -r -c 20 ZIEL
TCP-Port prüfen [TEST] Test-NetConnection ZIEL -Port 443 [TEST] nc -vz -w 5 ZIEL 443 [TEST] nc -vz -w 5 ZIEL 443
Route hinzufügen [PRIV][CHANGE][DISRUPT] New-NetRoute … [PRIV][CHANGE][DISRUPT] sudo ip route add … [PRIV][CHANGE][DISRUPT] sudo route -n add …
Route entfernen [PRIV][CHANGE][DISRUPT] Remove-NetRoute … [PRIV][CHANGE][DISRUPT] sudo ip route del … [PRIV][CHANGE][DISRUPT] sudo route -n delete …

mtr und teilweise traceroute sind nicht auf jeder Linux-Installation standardmäßig vorhanden. Fehlende Werkzeuge dürfen nur aus einer freigegebenen Paketquelle installiert werden.

32. Dokumentationsvorlage 
Ticketnummer:
Prüfzeitpunkt:
Zeitzone:
Betroffener Client:
Standort:
VLAN:
VPN aktiv: Ja / Nein

QUELLE

Hostname:
IPv4-Adresse/Präfix:
IPv6-Adresse/Präfix:
Schnittstelle:
Schnittstellenindex:
Schnittstellenmetrik:
MAC-Adresse:

ZIEL

Hostname:
Ziel-IPv4:
Ziel-IPv6:
Zielport:
Transportprotokoll:
Ziel laut Clientpräfix lokal: Ja / Nein

AUSGEWÄHLTE ROUTE

Adressfamilie:
Zielpräfix:
Präfixlänge:
Quelladresse:
Ausgangsschnittstelle:
Next Hop:
Routenmetrik:
Schnittstellenmetrik:
Routenursprung:
Routingtabelle/VRF:
Policy-Regel:
Direkter Nachbar aufgelöst:
Nachbar-MAC:

STANDARDROUTEN

IPv4-Standardroute:
IPv4-Next-Hop:
IPv4-Schnittstelle:
IPv4-Metrik:

IPv6-Standardroute:
IPv6-Next-Hop:
IPv6-Schnittstelle:
IPv6-Metrik:

PFAD

Hop 1:
Hop 2:
Hop 3:
Hop 4:
Letzter antwortender Hop:
Ziel erreicht:
Sternchen oder Timeouts:
Schleife erkennbar:
Pfadänderungen:

RÜCKWEG

Tatsächliche Quelladresse:
Route des Zielsystems zur Quelle:
Next Hop des Zielsystems:
Beteiligte Router:
Beteiligte Firewalls:
Asymmetrischer Weg:
NAT beteiligt:
Rückantwort am Ziel sichtbar:
Rückantwort am Client sichtbar:

VPN/POLICY ROUTING

Full Tunnel oder Split Tunnel:
Vom VPN installierte Route:
Überlappendes lokales Netz:
Policy-Regel:
Separate Routingtabelle:
Tunnelinterface:

REFERENZVERGLEICH

Referenzclient:
Ausgewählte Route:
Quelladresse:
Next Hop:
Pfad:
Relevante Abweichungen:

Arbeitshypothese:
Begründung:
Gesicherte Routingtabelle:
Geplante Änderung:
Freigabe:
Rückweg:
Tatsächliches Ergebnis:
Abschlussprüfung:
Ermittelte Ursache:
33. Offizielle Quellen und weiterführende Dokumentation

Microsoft

Linux

Apple

Wireshark

Standards

Routingbefehle auf Firewalls, Routern, Layer-3-Switches und VPN-Gateways sind herstellerabhängig. Für Änderungen muss die offizielle Dokumentation der tatsächlich eingesetzten Plattform verwendet werden.

3. Netzwerkfehler systematisch analysieren

3.8 DNS-Fehler systematisch analysieren

Das Domain Name System ordnet Namen technischen Informationen zu. Dazu gehören insbesondere IPv4- und IPv6-Adressen, zuständige Nameserver, Mailserver, Dienstinformationen und Validierungsdaten.

Ein DNS-Fehler liegt nahe, wenn ein Dienst über seine IP-Adresse erreichbar ist, aber nicht über seinen Namen. Dieser Vergleich ist jedoch nur dann aussagekräftig, wenn der Dienst einen direkten Zugriff über die IP-Adresse technisch unterstützt. HTTPS, virtuelle Webserver und Load Balancer benötigen häufig zusätzlich den korrekten Hostnamen.

Grundregel: Zuerst ermitteln, welcher Name von welchem Client über welchen Resolver aufgelöst werden soll. Danach Antwort, Fehlerstatus, Autorität, Cache, Transportweg und tatsächliche Nutzung durch die Anwendung prüfen.

1. Welche Aufgaben erfüllt DNS?

DNS kann unter anderem folgende Informationen bereitstellen:

Recordtyp Aufgabe
A Name zu IPv4-Adresse
AAAA Name zu IPv6-Adresse
CNAME Alias auf einen anderen Namen
MX zuständige Mailserver
NS autoritative Nameserver einer Zone
SOA grundlegende Verwaltungsinformationen einer Zone
PTR IP-Adresse zu Name bei Reverse DNS
TXT frei definierte Textinformationen und Verifikationsdaten
SRV Dienst, Zielhost, Port, Priorität und Gewichtung
CAA zulässige Zertifizierungsstellen
DS Verweis in der DNSSEC-Vertrauenskette
DNSKEY öffentlicher DNSSEC-Schlüssel
RRSIG DNSSEC-Signatur eines Recordsets

Beispiel

app.example.intern
  → CNAME proxy.example.intern
    → A 192.0.2.20
    → AAAA 2001:db8:20::20

Die Anwendung kann am Ende IPv4 oder IPv6 verwenden. Daher müssen alle beteiligten Records und der tatsächlich gewählte Zielendpunkt berücksichtigt werden.

2. Welche Symptome sprechen für ein DNS-Problem?
3. Welche Informationen müssen vor der Analyse erfasst werden?
Information Beispiel
betroffener Client CLIENT-023
Betriebssystem Windows 11
betroffener Name app.example.intern
vollständig qualifizierter Name app.example.intern.
erwarteter Recordtyp A und AAAA
erwartete IPv4-Adresse 192.0.2.20
erwartete IPv6-Adresse 2001:db8:20::20
verwendeter DNS-Server 192.0.2.53
vorgesehener DNS-Server 192.0.2.53
DNS-Suchdomäne example.intern
VPN aktiv Ja
Fehlerbeginn 2026-07-31 09:42 CEST
letzter funktionierender Zeitpunkt 2026-07-31 09:35 CEST
exakte Fehlermeldung Name konnte nicht aufgelöst werden
betroffene Anwendung Browser
Vergleichsclient CLIENT-024 funktioniert

Zusätzlich sollte geprüft werden:

4. Wie läuft eine rekursive DNS-Auflösung vereinfacht ab? 
Client
  → rekursiver Resolver
    → Root-Nameserver
      → TLD-Nameserver
        → autoritativer Nameserver
          → rekursiver Resolver
            → Client

Für interne Zonen kann der Ablauf anders sein:

Client
  → interner Resolver
    → interne autoritative Zone
      → Client

Oder über einen Conditional Forwarder:

Client
  → lokaler Resolver
    → bedingte Weiterleitung für partner.example
      → Resolver des Partners
        → autoritative Antwort

Caches können den vollständigen Ablauf verkürzen. Eine vorhandene Cacheantwort muss nicht jedes Mal erneut beim autoritativen Server abgefragt werden.

5. Was ist der Unterschied zwischen rekursivem und autoritativem DNS-Server?
Serverrolle Aufgabe
rekursiver Resolver ermittelt Antworten im Auftrag des Clients und speichert sie möglicherweise im Cache
autoritativer Nameserver liefert verbindliche Daten für eine von ihm verwaltete Zone
Forwarder leitet Abfragen an einen anderen Resolver weiter
Conditional Forwarder leitet nur bestimmte DNS-Namensräume an definierte Resolver weiter
Stub Resolver DNS-Komponente auf dem Endgerät, die Resolver befragt

Ein DNS-Server kann abhängig von Produkt und Konfiguration mehrere Rollen übernehmen.

Wichtige Diagnosefrage

Ist die falsche Antwort bereits auf dem autoritativen Server vorhanden
oder entsteht sie erst durch Cache, Weiterleitung oder Clientkonfiguration?
6. Welche Ports und Transportprotokolle verwendet DNS?

DNS verwendet grundsätzlich:

Transport Port Typischer Einsatz
UDP 53 viele gewöhnliche Abfragen und Antworten
TCP 53 große Antworten, Wiederholungen nach Truncation und Zonentransfers
TCP 853 DNS over TLS
TCP 443 DNS over HTTPS
UDP 443 DNS over HTTP/3 kann über QUIC verwendet werden

Wichtig

Eine Firewallregel, die nur UDP 53 erlaubt, kann DNS teilweise funktionieren lassen und bei bestimmten Antworten dennoch Fehler verursachen.

Mögliche Ursachen für den Wechsel zu TCP:

7. Wie wird die DNS-Clientkonfiguration unter Windows geprüft?

DNS-Server je Schnittstelle

[RO] Get-DnsClientServerAddress |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 AddressFamily,
                 ServerAddresses

DNS-Clientkonfiguration

[RO] Get-DnsClient |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 ConnectionSpecificSuffix,
                 RegisterThisConnectionsAddress,
                 UseSuffixWhenRegistering

Vollständige IP-Konfiguration

[RO][SENS] ipconfig /all

Zu prüfen sind:

DNS-over-HTTPS-Konfiguration

Je nach Windows-Version:

[RO] Get-DnsClientDohServerAddress

Das Cmdlet kann abhängig von Windows-Version und installiertem PowerShell-Modul nicht verfügbar sein.

8. Wie werden DNS-Abfragen unter Windows mit Resolve-DnsName durchgeführt?

Standardabfrage

[TEST] Resolve-DnsName app.example.intern

A-Record

[TEST] Resolve-DnsName app.example.intern -Type A

AAAA-Record

[TEST] Resolve-DnsName app.example.intern -Type AAAA

CNAME

[TEST] Resolve-DnsName app.example.intern -Type CNAME

MX

[TEST] Resolve-DnsName example.com -Type MX

SRV

[TEST] Resolve-DnsName `
    _ldap._tcp.example.intern `
    -Type SRV

PTR beziehungsweise Reverse DNS

[TEST] Resolve-DnsName 192.0.2.20 -Type PTR

Bestimmten DNS-Server abfragen

[TEST] Resolve-DnsName `
    app.example.intern `
    -Type A `
    -Server 192.0.2.53

Nur DNS verwenden und zusätzliche lokale Namensauflösungsmechanismen vermeiden

[TEST] Resolve-DnsName `
    app.example.intern `
    -Type A `
    -DnsOnly

TCP erzwingen

[TEST] Resolve-DnsName `
    app.example.intern `
    -Type A `
    -TcpOnly

Mit -TcpOnly kann geprüft werden, ob DNS über TCP 53 funktioniert.

9. Wie wird nslookup unter Windows, Linux und macOS verwendet?

Einfache Abfrage

[TEST] nslookup app.example.intern

Bestimmten Server abfragen

[TEST] nslookup app.example.intern 192.0.2.53

Bestimmten Recordtyp abfragen

[TEST] nslookup -type=AAAA app.example.intern 192.0.2.53

[TEST] nslookup -type=MX example.com 192.0.2.53

Reverse DNS

[TEST] nslookup 192.0.2.20 192.0.2.53

nslookup ist weit verbreitet, bildet aber nicht zwingend denselben Auflösungsweg ab wie eine Anwendung oder der native Systemresolver. Für eine vollständige Analyse sollten zusätzlich die betriebssystemspezifischen Werkzeuge verwendet werden.

10. Wie wird die DNS-Clientkonfiguration unter Linux geprüft?

systemd-resolved

[RO] resolvectl status

Bestimmte Schnittstelle:

[RO] resolvectl status eth0

Zu prüfen sind:

Resolverdatei

[RO] cat /etc/resolv.conf

Prüfen, ob es sich um einen symbolischen Link handelt:

[RO] ls -l /etc/resolv.conf

Beispiel:

nameserver 127.0.0.53
search example.intern
options edns0 trust-ad

127.0.0.53 kann auf den lokalen Stub Resolver von systemd-resolved verweisen. Der tatsächlich verwendete Upstream-DNS-Server muss dann mit resolvectl status bestimmt werden.

NetworkManager

[RO][SENS] nmcli device show |
    grep -E 'GENERAL.DEVICE|IP4.DNS|IP6.DNS|IP4.DOMAIN|IP6.DOMAIN'
11. Wie werden DNS-Abfragen unter Linux mit resolvectl durchgeführt?

Systemresolver verwenden

[TEST] resolvectl query app.example.intern

Bestimmten Recordtyp abfragen

[TEST] resolvectl query \
    --type=A \
    app.example.intern

[TEST] resolvectl query \
    --type=AAAA \
    app.example.intern

Bestimmte Schnittstelle verwenden

[TEST] resolvectl query \
    --interface=eth0 \
    app.example.intern

Resolverstatistik

[RO] resolvectl statistics

Serverfunktionen zurücksetzen beziehungsweise Cache leeren

Diese Befehle verändern den Resolverzustand und gehören nicht zur ersten Analyse:

[PRIV][CHANGE] sudo resolvectl reset-statistics

[PRIV][CHANGE] sudo resolvectl flush-caches

Vor dem Leeren sollte die vorhandene Antwort dokumentiert werden.

12. Wie werden DNS-Abfragen mit dig durchgeführt?

dig ist nicht auf jedem System standardmäßig installiert.

A- und AAAA-Abfrage

[TEST] dig app.example.intern A

[TEST] dig app.example.intern AAAA

Bestimmten Resolver abfragen

[TEST] dig @192.0.2.53 app.example.intern A

Kurze Ausgabe

[TEST] dig +short @192.0.2.53 app.example.intern A

Vollständige Antwort mit Kommentaren

[TEST] dig @192.0.2.53 app.example.intern A

TCP verwenden

[TEST] dig +tcp @192.0.2.53 app.example.intern A

DNSSEC-Daten anfordern

[TEST] dig +dnssec @192.0.2.53 example.com A

Autoritative Nameserver einer Zone

[TEST] dig @192.0.2.53 example.intern NS

SOA-Record

[TEST] dig @192.0.2.53 example.intern SOA

Reverse-Auflösung

[TEST] dig -x 192.0.2.20 @192.0.2.53

Delegationsweg verfolgen

[TEST] dig +trace example.com

dig +trace befragt die DNS-Hierarchie schrittweise selbst. Es entspricht nicht dem normalen rekursiven Weg über den konfigurierten Resolver und kann durch Firewalls oder interne Zonen eingeschränkt sein.

13. Welche Felder einer dig-Ausgabe sind wichtig?

Beispielstruktur:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra
;; QUESTION SECTION:
;app.example.intern.       IN A

;; ANSWER SECTION:
app.example.intern. 300    IN A 192.0.2.20

;; Query time: 12 msec
;; SERVER: 192.0.2.53#53
;; WHEN: ...
;; MSG SIZE  rcvd: ...
Feld Bedeutung
status DNS-Antwortstatus
id Transaktions-ID
qr Nachricht ist eine Antwort
aa autoritative Antwort
tc Antwort wurde gekürzt
rd Rekursion wurde angefordert
ra Rekursion ist verfügbar
ad validierende Stelle kennzeichnet Daten als authentifiziert
cd Client fordert deaktivierte DNSSEC-Prüfung
ANSWER eigentliche Antwortrecords
AUTHORITY zuständige beziehungsweise autoritative Informationen
ADDITIONAL zusätzliche hilfreiche Records
TTL verbleibende Cachelebensdauer
SERVER tatsächlich abgefragter Resolver
Query time gemessene Abfragedauer

Das ad-Flag muss im Zusammenhang mit dem befragten validierenden Resolver bewertet werden. Es beweist nicht, dass der lokale Client selbst die gesamte DNSSEC-Kette validiert hat.

14. Wie wird die DNS-Konfiguration unter macOS geprüft?

Aktuelle Resolverkonfiguration

[RO][SENS] scutil --dns

macOS kann mehrere Resolverkonfigurationen parallel besitzen, beispielsweise für:

DNS-Server eines Netzwerkdienstes

[RO] networksetup -getdnsservers "Wi-Fi"

Suchdomänen

[RO] networksetup -getsearchdomains "Wi-Fi"

IP-Konfiguration

[RO] networksetup -getinfo "Wi-Fi"

Der tatsächliche Netzwerkdienst muss vorher bestimmt werden:

[RO] networksetup -listallnetworkservices

Hosts-Auflösung über Systemmechanismen

[TEST] dscacheutil -q host -a name app.example.intern

Dieser Test bildet den macOS-Systemresolver besser ab als eine direkte Abfrage eines einzelnen DNS-Servers mit dig.

15. Warum können dig und eine Anwendung unterschiedliche Ergebnisse liefern?

dig sendet eine direkte DNS-Abfrage. Eine Anwendung kann dagegen weitere Mechanismen verwenden:

Beispiel

dig @192.0.2.53 app.example.intern
→ 192.0.2.20

Browser
→ verwendet eigenen DoH-Resolver
→ erhält keine interne Adresse

Deshalb sollten mindestens zwei Ebenen geprüft werden:

  1. direkte DNS-Serverantwort,
  2. tatsächliche Auflösung über das Betriebssystem beziehungsweise die Anwendung.
16. Wie wird die lokale Hosts-Datei geprüft?

Ein Eintrag in der Hosts-Datei kann DNS für den betreffenden Namen übersteuern.

Windows

[RO][PRIV][SENS] Get-Content `
    "$env:SystemRoot\System32\drivers\etc\hosts"

Nicht auskommentierte Zeilen anzeigen:

[RO][PRIV][SENS] Get-Content `
    "$env:SystemRoot\System32\drivers\etc\hosts" |
    Where-Object {
        $_.Trim() -and
        -not $_.Trim().StartsWith('#')
    }

Linux

[RO][SENS] cat /etc/hosts

macOS

[RO][SENS] cat /etc/hosts

Typische Probleme

Hosts-Dateien dürfen nicht vorschnell geändert werden. Zuerst müssen Ursprung, Zweck und Konfigurationsmanagement geklärt werden.

17. Wie beeinflusst ein DNS-Suchsuffix die Auflösung?

Ein nicht vollständig qualifizierter Name kann durch eine Suchdomäne ergänzt werden.

Eingabe:

app

Suchdomäne:

example.intern

Mögliche Anfrage:

app.example.intern

Bei mehreren Suchdomänen können mehrere Abfragen entstehen:

app.berlin.example.intern
app.example.intern
app

Prüfung unter Windows

[RO] Get-DnsClient |
    Select-Object InterfaceAlias,
                  ConnectionSpecificSuffix

Zusätzlich:

[RO][SENS] ipconfig /all

Linux

[RO] resolvectl status

[RO] cat /etc/resolv.conf

macOS

[RO][SENS] scutil --dns

Sicherer Vergleich

Kurzname:
app

Vollqualifizierter Name:
app.example.intern.

Der abschließende Punkt kennzeichnet in DNS-Werkzeugen einen absoluten Namen und verhindert dort normalerweise die Ergänzung eines Suchsuffixes.

18. Wie werden DNS-Antwortstatus richtig interpretiert?
Status Bedeutung
NOERROR mit Antwort Abfrage war erfolgreich und enthält Antwortdaten
NOERROR ohne gesuchten Record Name kann existieren, aber Recordtyp fehlt
NXDOMAIN abgefragter Name existiert laut Antwort nicht
SERVFAIL Server konnte keine gültige Antwort liefern
REFUSED Server verweigert die Abfrage
FORMERR Abfrageformat wurde als fehlerhaft bewertet
NOTIMP Operation wird nicht unterstützt
Timeout keine rechtzeitige verwertbare Antwort erhalten

Wichtige Unterscheidung

NXDOMAIN:
Der Name existiert laut DNS-Antwort nicht.

NOERROR ohne A-Record:
Der Name kann existieren, besitzt aber keinen A-Record.

SERVFAIL kann unter anderem entstehen durch:

19. Wie wird zwischen NXDOMAIN und fehlendem Recordtyp unterschieden?

A-Record abfragen

[TEST] dig @192.0.2.53 app.example.intern A

Mögliche Ergebnisse:

Fall 1 – Name existiert nicht

status: NXDOMAIN

Fall 2 – Name existiert, besitzt aber keinen A-Record

status: NOERROR
ANSWER: 0

Im Authority-Bereich kann ein SOA-Record erscheinen.

Fall 3 – Name besitzt nur AAAA

[TEST] dig @192.0.2.53 app.example.intern AAAA

liefert eine IPv6-Adresse.

Diese Unterscheidung ist wichtig, weil das Anlegen eines A-Records bei einem vollständig falschen Namen eine andere Maßnahme wäre als das Ergänzen eines fehlenden Recordtyps.

20. Wie werden CNAME-Ketten untersucht?

Direkte Abfrage

[TEST] dig @192.0.2.53 app.example.intern CNAME

Vollständige Auflösung

[TEST] dig @192.0.2.53 app.example.intern A

Mögliche Kette:

app.example.intern
  → CNAME proxy.example.intern
    → CNAME proxy-berlin.example.net
      → A 192.0.2.20

Zu prüfen sind:

Der erfolgreiche Abschluss der DNS-Kette beweist noch nicht, dass die Anwendung oder das Zertifikat korrekt ist.

21. Wie wird Split DNS beziehungsweise Split-Horizon DNS geprüft?

Bei Split DNS liefert derselbe Name abhängig vom verwendeten Resolver oder Standort unterschiedliche Antworten.

Interner Resolver

app.example.com
→ 192.0.2.20

Öffentlicher Resolver

app.example.com
→ 203.0.113.20

Dies kann beabsichtigt sein.

Vergleichsabfragen

[TEST] dig @192.0.2.53 app.example.com A

[TEST] dig @ÖFFENTLICHER-RESOLVER app.example.com A

Ein öffentlicher Resolver darf nur verwendet werden, wenn dies nach Unternehmensrichtlinie zulässig und aus dem Netz erreichbar ist.

Typische Fehler

22. Wie beeinflussen VPN und schnittstellenbezogenes DNS die Auflösung?

Ein VPN kann:

Prüfung vor und nach VPN-Verbindung

Eigenschaft vor VPN nach VPN
DNS-Server dokumentieren dokumentieren
Suchdomänen dokumentieren dokumentieren
Routen zum DNS-Server dokumentieren dokumentieren
A-Antwort vergleichen vergleichen
AAAA-Antwort vergleichen vergleichen
Systemresolver vergleichen vergleichen

Windows

[RO] Get-DnsClientServerAddress

Linux

[RO] resolvectl status

macOS

[RO][SENS] scutil --dns

Ein interner DNS-Server kann korrekt eingetragen sein, aber über die aktuelle Routingtabelle nicht erreichbar sein. Deshalb muss zusätzlich die Route zum Resolver geprüft werden.

23. Wie wird die Erreichbarkeit des DNS-Servers geprüft?

Route zum Resolver

Windows:

[RO] Find-NetRoute -RemoteIPAddress 192.0.2.53

Linux:

[RO] ip route get 192.0.2.53

macOS:

[RO] route -n get 192.0.2.53

TCP-Port 53 testen

Windows:

[TEST] Test-NetConnection 192.0.2.53 -Port 53

Linux und macOS:

[TEST] nc -vz -w 5 192.0.2.53 53

Dieser Test prüft nur TCP 53.

Tatsächliche DNS-Abfrage über UDP

[TEST] dig @192.0.2.53 app.example.intern A

Tatsächliche DNS-Abfrage über TCP

[TEST] dig +tcp @192.0.2.53 app.example.intern A

Auswertung

UDP-Abfrage TCP-Abfrage Mögliche Richtung
erfolgreich erfolgreich Transport grundsätzlich verfügbar
erfolgreich fehlerhaft TCP 53, Firewall oder Serverlistener prüfen
fehlerhaft erfolgreich UDP 53, Fragmentierung oder Filter prüfen
fehlerhaft fehlerhaft Route, Firewall, Server oder falsche Adresse
24. Wie werden große DNS-Antworten und das TC-Flag untersucht?

Das DNS-Headerflag TC bedeutet, dass eine Antwort gekürzt wurde.

Vereinfachter Ablauf:

Client → DNS-Abfrage über UDP
Server → gekürzte Antwort mit TC=1
Client → Wiederholung über TCP
Server → vollständige Antwort über TCP

dig-Ausgabe über UDP

[TEST] dig @192.0.2.53 example.com DNSKEY

Vergleich über TCP

[TEST] dig +tcp @192.0.2.53 example.com DNSKEY

Wireshark-Display-Filter

dns.flags.truncated == 1

Mögliche Fehlerursachen:

25. Wie werden TTL und DNS-Caching interpretiert?

TTL steht für Time to Live und gibt an, wie lange ein DNS-Record gecacht werden darf.

Beispiel

app.example.intern. 300 IN A 192.0.2.20

TTL:

300 Sekunden = 5 Minuten

Nach einer Änderung können Resolver die alte Antwort bis zum Ablauf der noch vorhandenen TTL verwenden.

Wichtig

Vergleich zu unterschiedlichen Zeitpunkten

[TEST] dig @192.0.2.53 app.example.intern A

Zu dokumentieren:

26. Was ist negatives DNS-Caching?

Auch negative Antworten wie NXDOMAIN oder das Fehlen eines bestimmten Recordtyps können zeitweise gecacht werden.

Mögliche Situation:

09:00 Name existiert noch nicht.
09:01 Client fragt und erhält NXDOMAIN.
09:05 Record wird angelegt.
09:06 Client erhält weiterhin die gecachte negative Antwort.

Die Dauer des negativen Cachings hängt unter anderem von den Zonen- und Resolverinformationen ab.

Diagnose

Ein Cache sollte erst geleert werden, nachdem die ursprüngliche Antwort und deren TTL gesichert wurden.

27. Wie wird der DNS-Cache unter Windows geprüft?

Cache anzeigen

[RO] Get-DnsClientCache

Nach einem Namen suchen:

[RO] Get-DnsClientCache |
    Where-Object Entry -Match 'app\.example\.intern'

Klassische Anzeige

[RO] ipconfig /displaydns

Cache exportieren

[RO][FILE][SENS] Get-DnsClientCache |
    Export-Csv 'C:\Temp\dns-cache-vorher.csv' `
    -NoTypeInformation `
    -Encoding UTF8

Der Cache kann interne Namen und aufgerufene Ziele enthalten und ist daher als sensibel zu behandeln.

28. Wann darf ein DNS-Cache geleert werden?

Das Leeren des Caches verändert den Diagnosezustand und kann eine fehlerhafte Antwort nur vorübergehend verbergen.

Windows

[PRIV][CHANGE] Clear-DnsClientCache

Alternative:

[PRIV][CHANGE] ipconfig /flushdns

Linux mit systemd-resolved

[PRIV][CHANGE] sudo resolvectl flush-caches

Andere Linux-Resolver besitzen eigene Verfahren. Es existiert kein allgemeiner Befehl für alle Linux-Systeme.

macOS

[PRIV][CHANGE] sudo dscacheutil -flushcache

Anschließend kann abhängig von macOS-Version zusätzlich ein HUP-Signal an den DNS-Responder erforderlich sein:

[PRIV][CHANGE] sudo killall -HUP mDNSResponder

Diese macOS-Befehle sollten nur nach Prüfung der eingesetzten Version und lokalen Dokumentation verwendet werden.

Vorher sichern

29. Wie werden autoritative DNS-Daten geprüft?

Zuständige Nameserver ermitteln

[TEST] dig @192.0.2.53 example.intern NS

SOA-Record prüfen

[TEST] dig @192.0.2.53 example.intern SOA

Autoritativen Server direkt abfragen

[TEST] dig @AUTORITATIVER-SERVER app.example.intern A

In der Antwort sollte bei einer autoritativen Antwort typischerweise das aa-Flag erscheinen.

Zu prüfen

Wenn autoritative Server unterschiedliche Zonenversionen liefern, können Clients abhängig vom befragten Server unterschiedliche Ergebnisse erhalten.

30. Wie wird die SOA-Seriennummer verwendet?

Der SOA-Record enthält Verwaltungsinformationen einer DNS-Zone, darunter eine Seriennummer.

[TEST] dig @DNS-SERVER example.intern SOA

Mehrere autoritative Server vergleichen:

[TEST] dig @DNS-SERVER-1 example.intern SOA

[TEST] dig @DNS-SERVER-2 example.intern SOA

Mögliche Auffälligkeit

Server 1: Serial 2026073105
Server 2: Serial 2026073002

Dies kann auf eine noch nicht erfolgte oder fehlgeschlagene Zonenübertragung beziehungsweise Replikation hinweisen.

Die Bedeutung und das Format der Seriennummer werden durch die DNS-Verwaltung der jeweiligen Umgebung bestimmt. Eine höhere dezimale Darstellung ist häufig, aber nicht jede Organisation verwendet dasselbe Schema.

31. Wie werden Delegationsfehler erkannt?

Eine übergeordnete Zone verweist per NS-Records auf die autoritativen Server einer untergeordneten Zone.

example.com
  → Delegation für berlin.example.com
    → ns1.berlin.example.com
    → ns2.berlin.example.com

Mögliche Fehler:

Öffentliche Delegation verfolgen

[TEST] dig +trace berlin.example.com

Für interne Zonen muss der interne Delegations- und Weiterleitungsweg anhand der Unternehmensarchitektur geprüft werden.

32. Wie werden DNSSEC-Probleme erkannt?

DNSSEC ermöglicht die kryptografische Prüfung von DNS-Daten. Ein Fehler in der Vertrauenskette kann dazu führen, dass validierende Resolver mit SERVFAIL antworten.

Abfrage mit DNSSEC-Daten

[TEST] dig +dnssec @192.0.2.53 example.com A

Validierung testweise durch den Resolver anfragen, aber Checking Disabled setzen

[TEST] dig +cdflag @192.0.2.53 example.com A

Wenn eine normale Abfrage SERVFAIL liefert, dieselbe Abfrage mit +cdflag aber Daten zurückgibt, ist ein DNSSEC-Validierungsproblem eine mögliche Hypothese.

Mögliche Ursachen

+cdflag deaktiviert nicht dauerhaft die Serverkonfiguration. Es kennzeichnet die einzelne Abfrage entsprechend. Das Ergebnis darf nur als Diagnosehinweis verwendet werden.

33. Wie beeinflusst DNS over HTTPS die Fehleranalyse?

Bei DNS over HTTPS werden DNS-Abfragen in HTTPS-Verbindungen übertragen. Dadurch kann eine Anwendung den betriebssystemseitig konfigurierten DNS-Server umgehen.

Mögliche Auswirkungen:

Prüffragen

DoH sollte nicht pauschal deaktiviert werden. Zuerst müssen Unternehmensrichtlinie, Sicherheitskonzept und tatsächlicher Auflösungsweg geprüft werden.

34. Wie wird DNS-Verkehr mit Wireshark untersucht?

Alle klassischen DNS-Nachrichten

dns

Nur DNS-Anfragen

dns.flags.response == 0

Nur DNS-Antworten

dns.flags.response == 1

Bestimmter Name

dns.qry.name == "app.example.intern"

Bestimmter Recordtyp

A-Record:

dns.qry.type == 1

AAAA-Record:

dns.qry.type == 28

NXDOMAIN

dns.flags.rcode == 3

SERVFAIL

dns.flags.rcode == 2

Gekürzte Antworten

dns.flags.truncated == 1

Lange Antwortzeit

dns.time > 1

dns.time ist verfügbar, wenn Wireshark Anfrage und passende Antwort einander zuordnen konnte.

35. Wie wird DNS-Verkehr sicher mitgeschnitten?

Capture-Filter für klassischen DNS-Verkehr

port 53

Nur bestimmter DNS-Server

host 192.0.2.53 and port 53

Zeitlich begrenzte Aufnahme

[TEST][PRIV][FILE][SENS] dumpcap \
  -i INTERFACE \
  -f "host 192.0.2.53 and port 53" \
  -a duration:30 \
  -w dns-diagnose.pcapng

TShark-Liveanzeige

[TEST][PRIV][SENS] tshark \
  -i INTERFACE \
  -f "host 192.0.2.53 and port 53"

Felder aus einer Datei ausgeben

[RO][SENS] tshark \
  -r dns-diagnose.pcapng \
  -Y "dns" \
  -T fields \
  -e frame.time \
  -e ip.src \
  -e ip.dst \
  -e udp.srcport \
  -e udp.dstport \
  -e dns.id \
  -e dns.flags.response \
  -e dns.flags.rcode \
  -e dns.qry.name \
  -e dns.qry.type

DNS-Aufzeichnungen können aufgerufene interne und externe Namen offenlegen und müssen gemäß Seite 2.14 geschützt werden.

36. Wie wird eine DNS-Anfrage im Paketmitschnitt ausgewertet?

Erfolgreicher Ablauf

Client → Resolver:
Query A app.example.intern

Resolver → Client:
Response NOERROR
A 192.0.2.20

Timeout

Client → Resolver:
Query A app.example.intern

Client → Resolver:
Wiederholung

Keine Antwort

NXDOMAIN

Client → Resolver:
Query A app.example.intern

Resolver → Client:
Response NXDOMAIN

TCP-Fallback

Client → Resolver über UDP:
Query

Resolver → Client:
Response, Truncated

Client → Resolver über TCP:
SYN, SYN-ACK, ACK
DNS Query

Resolver → Client über TCP:
vollständige DNS Response

Zu prüfen

37. Wie wird zwischen Client-, Resolver- und Zonenproblem unterschieden?
Beobachtung Wahrscheinlichere Richtung
nur eine Anwendung betroffen Anwendungscache, DoH oder Proxy
nur ein Client betroffen Clientcache, Hosts-Datei oder DNS-Konfiguration
alle Clients eines DNS-Servers betroffen Resolver, Forwarder oder dessen Netzwerkpfad
direkter autoritativer Server korrekt, Resolver falsch Cache oder Weiterleitung
alle autoritativen Server falsch Zonendaten
ein autoritativer Server weicht ab Replikation oder Zonentransfer
UDP funktioniert, TCP nicht Firewall oder TCP-Listener
TCP funktioniert, UDP nicht UDP-Filter, Fragmentierung oder Middlebox
interne Namen nur ohne DoH Anwendung umgeht internen Resolver
Auflösung korrekt, Verbindung fehlerhaft Problem liegt nach DNS
A funktioniert, AAAA führt zum Fehler IPv6-Pfad oder Ziel prüfen
SERVFAIL nur bei validierendem Resolver DNSSEC möglich
Name mit Punkt funktioniert, Kurzname nicht Suchsuffix oder Suchreihenfolge
38. Welche typischen Fehlinterpretationen müssen vermieden werden?
Beobachtung Falscher Schluss Richtige Einordnung
Ping per IP funktioniert DNS ist sicher die einzige Ursache Dienst kann Hostnamen oder TLS benötigen
nslookup funktioniert Anwendung verwendet dieselbe Auflösung Anwendung kann eigenen Resolver verwenden
DNS-Server ist eingetragen er wird tatsächlich verwendet schnittstellen- und anwendungsbezogene Resolver prüfen
NXDOMAIN DNS-Server ist ausgefallen Server antwortet, Name existiert laut Antwort nicht
SERVFAIL Name existiert nicht Server konnte keine gültige Antwort liefern
NOERROR gesuchter Record ist vorhanden Antwort kann leer sein
DNS-Cache geleert und Zugriff geht Ursache ist behoben veraltete Quelle kann erneut cachen
A-Record ist korrekt Dienst ist vollständig korrekt AAAA, CNAME, TLS und Backend prüfen
öffentliche Antwort unterscheidet sich eine Seite ist falsch Split DNS kann beabsichtigt sein
Port 53 per TCP erreichbar DNS funktioniert UDP und tatsächliche Abfrage separat prüfen
keine Port-53-Pakete sichtbar Anwendung stellt keine DNS-Anfrage DoH, Cache oder falscher Messpunkt möglich
kurze Query Time gesamte Anwendung ist schnell nur DNS-Abfragedauer gemessen
39. Wie sieht der systematische Prüfablauf aus?
Schritt Prüfung
1 betroffenen Namen und Recordtyp eindeutig bestimmen
2 Clientzeit, Netzwerk und VPN-Zustand dokumentieren
3 konfigurierte und tatsächlich verwendete Resolver bestimmen
4 Hosts-Datei und Suchsuffixe prüfen
5 Systemresolver abfragen
6 konfigurierten DNS-Server direkt abfragen
7 A, AAAA und mögliche CNAME-Kette untersuchen
8 Antwortstatus, TTL, Flags und Server dokumentieren
9 funktionierenden Client oder Resolver vergleichen
10 UDP- und TCP-Abfrage vergleichen
11 autoritative Server direkt prüfen
12 SOA-Seriennummern und Zonendaten vergleichen
13 Split DNS, VPN, DoH und Conditional Forwarding berücksichtigen
14 bei Bedarf autorisierten Paketmitschnitt erstellen
15 Cache erst nach Beweissicherung kontrolliert leeren
16 DNS-Antwort und tatsächliche Dienstverbindung erneut testen
17 Ursache und Änderung dokumentieren

Merksatz

Name → Recordtyp → Systemresolver → konfigurierter Resolver
→ autoritativer Server → Cache → tatsächliche Anwendung
40. Kompakte Befehlsübersicht für Windows, Linux und macOS
Aufgabe Windows Linux macOS
DNS-Konfiguration [RO] Get-DnsClientServerAddress [RO] resolvectl status [RO][SENS] scutil --dns
DNS-Suffixe [RO] Get-DnsClient [RO] resolvectl status [RO] networksetup -getsearchdomains "DIENST"
vollständige Netzkonfiguration [RO][SENS] ipconfig /all [RO] cat /etc/resolv.conf [RO] networksetup -getinfo "DIENST"
Systemauflösung [TEST] Resolve-DnsName NAME [TEST] resolvectl query NAME [TEST] dscacheutil -q host -a name NAME
A-Record [TEST] Resolve-DnsName NAME -Type A [TEST] dig NAME A [TEST] dig NAME A
AAAA-Record [TEST] Resolve-DnsName NAME -Type AAAA [TEST] dig NAME AAAA [TEST] dig NAME AAAA
bestimmten Resolver abfragen [TEST] Resolve-DnsName NAME -Server DNS-SERVER [TEST] dig @DNS-SERVER NAME [TEST] dig @DNS-SERVER NAME
TCP erzwingen [TEST] Resolve-DnsName NAME -Server DNS-SERVER -TcpOnly [TEST] dig +tcp @DNS-SERVER NAME [TEST] dig +tcp @DNS-SERVER NAME
Reverse DNS [TEST] Resolve-DnsName IP -Type PTR [TEST] dig -x IP @DNS-SERVER [TEST] dig -x IP @DNS-SERVER
NS-Records [TEST] Resolve-DnsName ZONE -Type NS [TEST] dig @DNS-SERVER ZONE NS gleicher Befehl
SOA-Record [TEST] Resolve-DnsName ZONE -Type SOA [TEST] dig @DNS-SERVER ZONE SOA gleicher Befehl
Hosts-Datei [RO][PRIV][SENS] Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" [RO][SENS] cat /etc/hosts [RO][SENS] cat /etc/hosts
DNS-Cache anzeigen [RO] Get-DnsClientCache [RO] resolvectl statistics kein gleichwertiger vollständiger Standardbefehl
DNS-Cache leeren [PRIV][CHANGE] Clear-DnsClientCache [PRIV][CHANGE] sudo resolvectl flush-caches [PRIV][CHANGE] sudo dscacheutil -flushcache
DNS mitschneiden [TEST][PRIV][FILE][SENS] dumpcap -i INTERFACE -f "host DNS-SERVER and port 53" -a duration:30 -w dns.pcapng gleicher Befehl gleicher Befehl

Die Platzhalter NAME, ZONE, IP, DNS-SERVER, DIENST und INTERFACE müssen durch vorher eindeutig bestimmte Werte ersetzt werden.

41. Dokumentationsvorlage 
Ticketnummer:
Prüfzeitpunkt:
Zeitzone:
Betroffener Client:
Betriebssystem:
Benutzer:
Standort:
VLAN:
VPN aktiv:
Betroffene Anwendung:

ABFRAGE

Eingegebener Name:
Vollständig qualifizierter Name:
Recordtyp:
Erwartete Antwort:
Tatsächliche Antwort:
Exakte Fehlermeldung:

CLIENTKONFIGURATION

Schnittstelle:
IPv4-Adresse:
IPv6-Adresse:
DNS-Server IPv4:
DNS-Server IPv6:
DNS-Suchdomänen:
Lokale Hosts-Datei geprüft:
Passender Hosts-Eintrag:
DoH aktiv oder vermutet:
Proxy aktiv:
Anwendungscache:

SYSTEMRESOLVER

Verwendeter Test:
Antwortstatus:
Antwortrecords:
TTL:
CNAME-Kette:
Antwortzeit:
Verwendeter Resolver:
IPv4 oder IPv6:

DIREKTE DNS-ABFRAGE

DNS-Server:
UDP erfolgreich:
TCP erfolgreich:
A-Antwort:
AAAA-Antwort:
CNAME:
Status:
Flags:
TTL:
Query Time:

AUTORITATIVE DATEN

Zone:
Autoritative Nameserver:
Direkt abgefragter Server:
AA-Flag:
A-Record:
AAAA-Record:
CNAME:
SOA-Seriennummer:
Weitere autoritative Server:
Seriennummern identisch:
Delegation korrekt:
DNSSEC-Status:

VERGLEICH

Referenzclient:
Verwendeter Resolver:
Antwort:
TTL:
Anwendung funktioniert:
Relevante Abweichungen:

PAKETMITSCHNITT

Messpunkt:
DNS-Anfrage sichtbar:
DNS-Antwort sichtbar:
Transaktions-ID:
UDP oder TCP:
Response Code:
Truncated:
Wiederholungen:
Antwortzeit:
Capture-Datei:
Hash:

CACHE

Clientcache vor Änderung gesichert:
Resolvercache vermutet:
Negative Antwort:
Cache geleert:
Ergebnis nach Cacheleerung:

Arbeitshypothese:
Begründung:
Durchgeführter Test:
Geplante Änderung:
Freigabe:
Rückweg:
Abschlussprüfung:
Ermittelte Ursache:
42. Offizielle Quellen und weiterführende Dokumentation

Microsoft

Linux und systemd

ISC BIND

Apple

Wireshark

Standards

DNS-Verwaltungsbefehle und Serverprotokolle unterscheiden sich je nach Produkt. Änderungen an Zonen, Delegationen, Forwardern, DNSSEC oder Resolverrichtlinien dürfen nur anhand der Dokumentation des tatsächlich eingesetzten DNS-Systems vorgenommen werden.

3. Netzwerkfehler systematisch analysieren

3.9 Ports und Transportprotokolle prüfen

Ein erreichbarer Host bedeutet noch nicht, dass der benötigte Dienst erreichbar ist. ping prüft hauptsächlich die IP-Erreichbarkeit über ICMP. Es prüft weder einen TCP-Port noch zuverlässig die Funktionsfähigkeit eines Anwendungsdienstes.

Die zentrale Frage dieser Seite lautet:

Ist der benötigte Dienst über das richtige Transportprotokoll, die richtige Zieladresse und den richtigen Port erreichbar?

1. Sicherheits- und Aktionskennzeichnungen
Kennzeichnung Bedeutung
[RO] Rein lesender Befehl, der normalerweise keine Konfiguration verändert
[TEST] Aktiver Test, der Netzwerkverkehr oder Protokollanfragen erzeugt
[PRIV] Erhöhte Rechte beziehungsweise Administrator- oder Root-Rechte können erforderlich sein
[FILE] Der Befehl schreibt Ausgaben in eine Datei
[SENS] Die Ausgabe kann sensible Daten enthalten
[CHANGE] Der Befehl verändert eine Konfiguration
[DISRUPT] Der Befehl kann einen Dienst oder eine Verbindung beeinträchtigen

Wichtiger Grundsatz: Portscans und aktive Verbindungstests dürfen nur auf Systemen durchgeführt werden, für die eine entsprechende Berechtigung vorliegt.

2. TCP, UDP und ICMP unterscheiden
Protokoll Eigenschaft Typisches Verhalten bei einem Test
TCP Verbindungsorientiert Vor der Datenübertragung wird eine Verbindung aufgebaut
UDP Verbindungslos Datagramme werden ohne vorherigen Verbindungsaufbau gesendet
ICMP Kontroll- und Diagnoseprotokoll Übermittelt beispielsweise Echo-Antworten oder Fehlermeldungen
ICMPv6 Kontrollprotokoll für IPv6 Wird unter anderem für Fehler, Neighbor Discovery und Path-MTU-Ermittlung benötigt

TCP-Verbindungsaufbau:

Client                         Server
  |                              |
  | -------- SYN --------------> |
  | <----- SYN, ACK ------------ |
  | -------- ACK --------------> |
  |                              |
  |     Verbindung aufgebaut     |

Der erfolgreiche TCP-Handshake beweist:

Er beweist jedoch noch nicht:

Besonderheit bei UDP:

UDP besitzt keinen vergleichbaren Verbindungsaufbau. Bleibt eine Antwort aus, kann das bedeuten:

Ein erfolgreicher UDP-Test benötigt deshalb möglichst eine gültige Anfrage des jeweiligen Anwendungsprotokolls, beispielsweise eine DNS-Abfrage anstelle eines beliebigen UDP-Pakets.

3. Port, Socket und Verbindung eindeutig beschreiben

Ein Port gehört immer zu einem Transportprotokoll. Die Angabe „Port 53“ ist ohne das Protokoll unvollständig, weil TCP-Port 53 und UDP-Port 53 getrennte Endpunkte sind.

Eine Netzwerkverbindung wird im Normalfall durch folgende Angaben unterschieden:

Transportprotokoll
Quell-IP-Adresse
Quellport
Ziel-IP-Adresse
Zielport

Beispiel:

TCP 192.0.2.25:53144 → 192.0.2.53:443

Dabei ist 53144 normalerweise ein temporärer Clientport und 443 der angesprochene Dienstport.

Wichtige Begriffe:

Begriff Bedeutung
Dienstport Port, auf dem eine Serveranwendung Verbindungen oder Datagramme erwartet
Quellport Vom Client verwendeter Port; häufig dynamisch vergeben
Listening Socket Lokaler Socket, der auf eingehende TCP-Verbindungen wartet
UDP Endpoint Lokaler UDP-Endpunkt, der Datagramme empfangen kann
Ephemeral Port Temporärer, vom Betriebssystem vergebener Clientport
Loopback-Adresse Nur lokal erreichbare Adresse, beispielsweise 127.0.0.1 oder ::1
Wildcard-Adresse Bindung an mehrere beziehungsweise alle lokalen Adressen
Verbindungsstatus Zustand einer TCP-Verbindung, beispielsweise LISTEN oder ESTABLISHED
4. Häufig verwendete Ports einordnen

Die folgende Tabelle enthält typische Standardbelegungen. Anwendungen können jedoch auf abweichende Ports konfiguriert werden.

Dienst Transportprotokoll Standardport
SSH TCP 22
SMTP TCP 25
DNS UDP und TCP 53
DHCP-Server UDP 67
DHCP-Client UDP 68
HTTP TCP 80
Kerberos UDP und TCP 88
NTP UDP 123
LDAP TCP und teilweise UDP 389
HTTPS TCP 443
SMB TCP 445
LDAPS TCP 636
Microsoft SQL Server TCP 1433
MySQL/MariaDB TCP 3306
RDP TCP und UDP 3389
PostgreSQL TCP 5432

Nicht allein auf die Portnummer verlassen: Ein offener TCP-Port 443 beweist nicht, dass dort tatsächlich ein ordnungsgemäßer HTTPS-Dienst läuft.

5. Typische Fehlermeldungen richtig interpretieren
Beobachtung Wahrscheinliche Bedeutung
Verbindung erfolgreich TCP-Verbindungsaufbau war möglich
Connection refused Ziel wurde erreicht, aber der Port wird nicht angenommen oder aktiv abgelehnt
Connection timed out Keine verwertbare Antwort; Paketverlust, Filterung, Routing- oder Rückwegproblem möglich
No route to host Lokales oder entferntes Routingproblem beziehungsweise entsprechende ICMP-Rückmeldung
Network is unreachable Keine geeignete Route oder Schnittstelle vorhanden
Host is unreachable Ziel oder nächster Hop konnte nicht erreicht werden
Name or service not known Namensauflösung fehlgeschlagen; der Porttest wurde möglicherweise noch nicht ausgeführt
Address already in use Ein anderer Prozess oder Socket verwendet bereits die Adresse beziehungsweise den Port
Permission denied Fehlende Berechtigung oder Sicherheitsrichtlinie verhindert den Zugriff
Verbindung sofort zurückgesetzt Anwendung, Zielsystem oder Sicherheitskomponente sendet ein TCP-RST
TCP-Test erfolgreich, Anwendung fehlerhaft Fehler liegt wahrscheinlich oberhalb der Transportschicht

Fehlermeldungen können je nach Betriebssystem, Anwendung und Sprache abweichen.

6. Auf dem Server prüfen, ob der Port geöffnet wurde

Zuerst wird direkt auf dem betroffenen Server geprüft:

  1. Läuft der erwartete Prozess?
  2. Lauscht er auf dem erwarteten Port?
  3. Verwendet er TCP oder UDP?
  4. An welche IP-Adresse wurde der Socket gebunden?
  5. Ist der Dienst nur über IPv4, nur über IPv6 oder über beides erreichbar?
  6. Stimmt der Prozess tatsächlich mit dem erwarteten Dienst überein?
Aufgabe Windows Linux macOS
TCP-Verbindungen und Listener [RO] Get-NetTCPConnection [RO] ss -tan [RO] netstat -anv -p tcp
Nur TCP-Listener [RO] Get-NetTCPConnection -State Listen [RO] ss -ltn [RO] lsof -nP -iTCP -sTCP:LISTEN
UDP-Endpunkte [RO] Get-NetUDPEndpoint [RO] ss -lun [RO] lsof -nP -iUDP
TCP-Listener mit Prozess [RO] Get-NetTCPConnection -State Listen [RO][PRIV] sudo ss -ltnp [RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN
UDP-Endpunkte mit Prozess [RO] Get-NetUDPEndpoint [RO][PRIV] sudo ss -lunp [RO][PRIV] sudo lsof -nP -iUDP
Klassische Übersicht [RO] netstat -ano [RO] ss -tuln [RO] netstat -anv

lsof ist auf einigen Linux-Systemen nicht standardmäßig installiert. Unter Linux ist ss normalerweise das bevorzugte Werkzeug.

Windows – bestimmten TCP-Port prüfen:

[RO] Get-NetTCPConnection -LocalPort 443 -ErrorAction SilentlyContinue

Windows – nur Listener auf einem bestimmten Port:

[RO] Get-NetTCPConnection -State Listen -LocalPort 443 -ErrorAction SilentlyContinue

Windows – UDP-Endpunkt prüfen:

[RO] Get-NetUDPEndpoint -LocalPort 53 -ErrorAction SilentlyContinue

Windows – Prozess zu einem Listener ermitteln:

[RO] Get-NetTCPConnection -State Listen -LocalPort 443 |
    Select-Object LocalAddress, LocalPort, State, OwningProcess

Anschließend die ermittelte Prozess-ID einsetzen:

[RO] Get-Process -Id 4321

Alternativ mit klassischen Werkzeugen:

[RO] netstat -ano
[RO] tasklist /FI "PID eq 4321"

Linux – TCP-Port 443 prüfen:

[RO] ss -ltn 'sport = :443'

Linux – UDP-Port 53 prüfen:

[RO] ss -lun 'sport = :53'

Linux – Prozessinformationen anzeigen:

[RO][PRIV] sudo ss -ltnp 'sport = :443'

[RO][PRIV] sudo ss -lunp 'sport = :53'

macOS – TCP-Port 443 prüfen:

[RO] lsof -nP -iTCP:443 -sTCP:LISTEN

macOS – UDP-Port 53 prüfen:

[RO][PRIV] sudo lsof -nP -iUDP:53

Achtung: Eine leere Ausgabe bedeutet meistens, dass kein passender Socket gefunden wurde. Sie ist nicht automatisch ein Programmfehler.

7. Bind-Adressen eines Dienstes beurteilen

Ein Prozess kann laufen und trotzdem nur über eine falsche oder zu stark eingeschränkte Adresse erreichbar sein.

Lokale Adresse Typische Bedeutung
127.0.0.1:8080 Nur über IPv4-Loopback auf demselben System erreichbar
::1:8080 Nur über IPv6-Loopback auf demselben System erreichbar
192.0.2.10:443 Nur über diese konkrete lokale IPv4-Adresse erreichbar
0.0.0.0:443 An alle passenden lokalen IPv4-Adressen gebunden
[::]:443 IPv6-Wildcard; ob zusätzlich IPv4 angenommen wird, hängt von Betriebssystem und Anwendung ab

Typischer Fehler:

Dienst läuft
↓
Port ist lokal geöffnet
↓
Dienst lauscht aber nur auf 127.0.0.1
↓
Lokaler Test funktioniert
↓
Entfernter Zugriff schlägt fehl

Eine Bindung an 0.0.0.0 oder [::] bedeutet nicht automatisch, dass der Port von außen erreichbar ist. Firewalls, VLANs, Routing, NAT und Sicherheitsrichtlinien gelten weiterhin.

8. TCP-Port von einem Client aus prüfen

Der Test sollte möglichst von dem System oder Netzwerksegment ausgeführt werden, in dem der Fehler tatsächlich auftritt.

Betriebssystem TCP-Porttest
Windows [TEST] Test-NetConnection server.example.internal -Port 443 -InformationLevel Detailed
Linux [TEST] nc -vz -w 5 server.example.internal 443
macOS [TEST] nc -vz -w 5 server.example.internal 443
Plattformübergreifend mit Nmap [TEST] nmap -sT -p 443 server.example.internal

Windows:

[TEST] Test-NetConnection server.example.internal -Port 443 -InformationLevel Detailed

Besonders relevante Felder:

ComputerName
RemoteAddress
RemotePort
InterfaceAlias
SourceAddress
TcpTestSucceeded

Nur das Wesentliche ausgeben:

[TEST] Test-NetConnection server.example.internal -Port 443 |
    Select-Object ComputerName, RemoteAddress, RemotePort, SourceAddress, TcpTestSucceeded

Wichtig: Test-NetConnection -Port prüft einen TCP-Port. Es ist kein allgemeiner UDP-Porttest.

Linux und macOS:

[TEST] nc -vz -w 5 server.example.internal 443

Mehrere TCP-Ports einzeln prüfen:

[TEST] nc -vz -w 5 server.example.internal 22
[TEST] nc -vz -w 5 server.example.internal 80
[TEST] nc -vz -w 5 server.example.internal 443

Die verfügbaren nc-Optionen unterscheiden sich zwischen Implementierungen. Im Zweifel die lokale Hilfe prüfen:

[RO] nc -h

Nmap – einzelnen TCP-Port prüfen:

[TEST] nmap -sT -p 443 server.example.internal

Mehrere festgelegte TCP-Ports prüfen:

[TEST] nmap -sT -p 22,80,443 server.example.internal

Nmap nur im freigegebenen Umfang einsetzen. Ein vollständiger Portscan ist für die Prüfung eines bekannten Dienstes normalerweise nicht erforderlich.

9. Nmap-Portzustände richtig interpretieren
Zustand Typische Bedeutung
open Eine Anwendung nimmt Verbindungen oder Datagramme auf diesem Port an
closed Ziel ist erreichbar, aber auf dem Port lauscht kein Dienst
filtered Nmap kann wegen Paketfilterung nicht sicher feststellen, ob der Port geöffnet ist
unfiltered Port ist erreichbar, aber der konkrete Offen-/Geschlossen-Zustand wurde mit der verwendeten Scanmethode nicht bestimmt
open|filtered Nmap kann nicht zwischen geöffnet und gefiltert unterscheiden
closed|filtered Nmap kann nicht zwischen geschlossen und gefiltert unterscheiden

Die Bewertung hängt von Scanart, Berechtigungen, Zielsystem und den empfangenen Antworten ab.

10. UDP-Dienste sinnvoll prüfen

Ein allgemeiner UDP-Porttest ist nur eingeschränkt aussagekräftig. Nach Möglichkeit sollte immer das eigentliche Anwendungsprotokoll geprüft werden.

Dienst Sinnvoller Funktionstest
DNS nslookup, Resolve-DnsName oder dig
NTP w32tm, chronyc, ntpq oder sntp, abhängig vom System
DHCP DHCP-Ablauf und Paketmitschnitt analysieren
Syslog über UDP Empfang auf dem Syslog-Server und Paketmitschnitt prüfen
SNMP Autorisierte SNMP-Abfrage mit gültigen Parametern durchführen

DNS gezielt über UDP testen:

Windows:

[TEST] Resolve-DnsName example.org -Server 192.0.2.53 -Type A -DnsOnly

Linux und macOS, sofern dig installiert ist:

[TEST] dig @192.0.2.53 example.org A

DNS gezielt über TCP testen:

Windows:

[TEST] Resolve-DnsName example.org -Server 192.0.2.53 -Type A -DnsOnly -TcpOnly

Linux und macOS:

[TEST] dig +tcp @192.0.2.53 example.org A

Netcat-UDP-Test:

[TEST] nc -vzu -w 3 192.0.2.53 53

Dieser Test ist nicht mit einem erfolgreichen DNS-Funktionstest gleichzusetzen. Eine scheinbare Erfolgsmeldung kann lediglich bedeuten, dass lokal kein unmittelbarer Fehler festgestellt wurde.

Nmap-UDP-Test:

[TEST][PRIV] sudo nmap -sU -p 53 192.0.2.53

UDP-Scans können langsam und mehrdeutig sein. Ein Ergebnis wie open|filtered ist bei UDP häufig, wenn weder eine Protokollantwort noch eine eindeutige ICMP-Fehlermeldung empfangen wurde.

11. Nicht nur den Port, sondern die Anwendung testen

Ein Porttest prüft die Transportschicht. Danach sollte ein Test mit dem tatsächlichen Anwendungsprotokoll folgen.

Anwendung Beispiel
HTTP [TEST] curl -v http://server.example.internal/
HTTPS [TEST] curl -vk https://server.example.internal/
HTTPS mit regulärer Zertifikatsprüfung [TEST] curl -v https://server.example.internal/
TLS-Handshake [TEST] openssl s_client -connect server.example.internal:443 -servername server.example.internal
DNS über UDP [TEST] dig @192.0.2.53 example.org A
DNS über TCP [TEST] dig +tcp @192.0.2.53 example.org A
SSH-Protokolltest [TEST] ssh -vvv user@server.example.internal

HTTP-Header abrufen:

[TEST] curl -I https://server.example.internal/

Ausführliche HTTPS-Diagnose:

[TEST][SENS] curl -v https://server.example.internal/

Bei curl -v können Header, Cookies, interne Hostnamen und weitere sensible Informationen sichtbar werden. Zugangsdaten oder Sitzungstoken dürfen nicht ungeprüft dokumentiert werden.

TLS-Verbindung untersuchen:

[TEST][SENS] openssl s_client \
    -connect server.example.internal:443 \
    -servername server.example.internal

-servername übermittelt den Servernamen per SNI. Das ist wichtig, wenn mehrere TLS-Websites dieselbe IP-Adresse verwenden.

Hinweis zu curl -k:

[TEST] curl -vk https://server.example.internal/

-k deaktiviert die Zertifikatsprüfung. Das kann zur Eingrenzung eines Zertifikatsfehlers verwendet werden, darf aber nicht als dauerhafte Lösung betrachtet werden.

12. IPv4 und IPv6 getrennt prüfen

Ein Hostname kann gleichzeitig eine IPv4- und eine IPv6-Adresse besitzen. Dadurch kann derselbe Porttest je nach ausgewählter Adresse unterschiedlich ausfallen.

Namensauflösung kontrollieren:

Windows:

[RO] Resolve-DnsName server.example.internal

Linux:

[RO] getent ahosts server.example.internal

macOS:

[RO] dscacheutil -q host -a name server.example.internal

HTTP gezielt über IPv4 testen:

[TEST] curl -4 -v https://server.example.internal/

HTTP gezielt über IPv6 testen:

[TEST] curl -6 -v https://server.example.internal/

Netcat gezielt über IPv4 oder IPv6:

[TEST] nc -4 -vz -w 5 server.example.internal 443
[TEST] nc -6 -vz -w 5 server.example.internal 443

Windows – aufgelöste Zieladresse beachten:

[TEST] Test-NetConnection server.example.internal -Port 443 -InformationLevel Detailed

In der Ausgabe muss RemoteAddress kontrolliert werden. Ein erfolgreicher IPv4-Test beweist nicht, dass IPv6 funktioniert – und umgekehrt.

13. TCP-Zustände beurteilen
TCP-Zustand Bedeutung Diagnosehinweis
LISTEN Socket wartet auf eingehende Verbindungen Dienst ist lokal grundsätzlich gebunden
SYN-SENT Client hat SYN gesendet und wartet Viele dauerhafte Einträge können auf fehlende Antworten hindeuten
SYN-RECEIVED SYN wurde empfangen, SYN-ACK gesendet Viele Einträge können auf fehlende abschließende ACKs hinweisen
ESTABLISHED TCP-Verbindung besteht Transportverbindung funktioniert grundsätzlich
FIN-WAIT-1 Aktives Schließen wurde begonnen Kurzzeitig normal
FIN-WAIT-2 Eigenes FIN wurde bestätigt Dauerhafte Häufung kann auf Probleme der Gegenstelle hinweisen
CLOSE-WAIT Gegenstelle hat geschlossen, lokale Anwendung noch nicht Viele dauerhafte Einträge deuten häufig auf ein Anwendungsproblem hin
LAST-ACK Lokale Seite wartet auf Bestätigung ihres FIN Kurzzeitig normal
TIME-WAIT Verbindung bleibt vorübergehend gespeichert Viele Einträge können bei hoher Verbindungsrate normal sein
CLOSED Keine Verbindung vorhanden Normaler Endzustand

Windows – bestehende TCP-Verbindungen:

[RO] Get-NetTCPConnection -State Established

Windows – Verbindungen zu einem bestimmten Zielport:

[RO] Get-NetTCPConnection -RemotePort 443

Linux – bestehende TCP-Verbindungen:

[RO] ss -tn state established

Linux – Verbindungen mit Zustand und Timern:

[RO] ss -tano

macOS – TCP-Zustände:

[RO] netstat -anv -p tcp

Ein einzelner Zustand ist nur eine Momentaufnahme. Bei sporadischen Problemen sind wiederholte Beobachtungen, Anwendungsprotokolle und gegebenenfalls ein Paketmitschnitt erforderlich.

14. TCP-Paketmuster interpretieren
Beobachtung im Mitschnitt Typische Interpretation
SYN → SYN/ACK → ACK TCP-Verbindung wurde aufgebaut
Wiederholte SYN-Pakete ohne Antwort Paketverlust, Filterung, falsches Routing, ausgefallenes Ziel oder fehlerhafter Rückweg
SYN → RST/ACK Ziel ist erreichbar, aber Port ist geschlossen oder wird aktiv abgelehnt
SYN-ACK kommt an, abschließendes ACK fehlt Problem auf der Clientseite oder beim Rückweg des ACK möglich
Verbindung wird aufgebaut und sofort mit RST beendet Anwendung oder Sicherheitskomponente bricht Verbindung ab
Viele Retransmissions Paketverlust, Überlastung, fehlerhafte Verbindung oder asymmetrische Erfassung möglich
TCP-Verbindung erfolgreich, HTTP-Fehler folgt Transportschicht funktioniert; Fehler liegt wahrscheinlich auf Anwendungsebene

Ein Paketmitschnitt sollte möglichst gleichzeitig auf Client und Server erfolgen. Dadurch lässt sich feststellen, an welcher Stelle Pakete verloren gehen oder verändert werden.

15. Paketmitschnitt für einen Port erstellen

Paketmitschnitte können IP-Adressen, Hostnamen, Nutzdaten, Cookies und andere vertrauliche Informationen enthalten. Speicherung und Weitergabe müssen den betrieblichen Datenschutz- und Sicherheitsvorgaben entsprechen.

Linux – TCP-Port 443 mitschneiden:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i any -nn \
    'host 192.0.2.20 and tcp port 443' \
    -w port-443.pcap

Linux – UDP-Port 53 mitschneiden:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i any -nn \
    'host 192.0.2.53 and udp port 53' \
    -w dns-udp.pcap

macOS – vorher Schnittstellen ermitteln:

[RO] networksetup -listallhardwareports

Anschließend beispielsweise:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i en0 -nn \
    'host 192.0.2.20 and tcp port 443' \
    -w port-443.pcap

Windows – verfügbare Schnittstellen mit Dumpcap anzeigen:

[RO] dumpcap -D

Windows – Mitschnitt auf Schnittstelle 1:

[TEST][PRIV][FILE][SENS] dumpcap -i 1 `
    -f "host 192.0.2.20 and tcp port 443" `
    -w port-443.pcapng

Die Schnittstellennummer 1 ist nur ein Beispiel und muss vorher mit dumpcap -D ermittelt werden.

16. Nützliche Wireshark-Anzeigefilter
Aufgabe Wireshark-Anzeigefilter
TCP-Port 443 tcp.port == 443
UDP-Port 53 udp.port == 53
Verkehr zu oder von einer IP-Adresse ip.addr == 192.0.2.20
IPv6-Adresse ipv6.addr == 2001:db8::20
IP-Adresse und TCP-Port ip.addr == 192.0.2.20 && tcp.port == 443
TCP-SYN-Pakete tcp.flags.syn == 1
Nur erste SYN-Pakete ohne gesetztes ACK tcp.flags.syn == 1 && tcp.flags.ack == 0
TCP-Reset tcp.flags.reset == 1
Vermutete TCP-Wiederholungen tcp.analysis.retransmission
Doppelte ACKs tcp.analysis.duplicate_ack
TCP-Verbindungsaufbau `tcp.connection.syn
ICMP-Meldungen icmp
ICMPv6-Meldungen icmpv6

Wireshark-Analysehinweise wie tcp.analysis.retransmission sind Interpretationen anhand des vorhandenen Mitschnitts. Fehlende Pakete am Beginn oder während der Aufzeichnung können zu irreführenden Markierungen führen.

17. Container und veröffentlichte Ports prüfen

Bei Containerdiensten müssen mehrere Ebenen unterschieden werden:

Client
  ↓
Host-IP und veröffentlichter Hostport
  ↓
Portweiterleitung oder Proxy
  ↓
Container-IP und Containerport
  ↓
Anwendungsprozess im Container

Laufende Container und Portzuordnungen anzeigen:

[RO] docker ps --format 'table {{.Names}}\t{{.Ports}}'

Portzuordnung eines Containers anzeigen:

[RO] docker port webserver

Container detailliert untersuchen:

[RO][SENS] docker inspect webserver

Zu prüfen sind:

Eine Docker-Ausgabe wie diese:

127.0.0.1:8080->80/tcp

bedeutet, dass der veröffentlichte Hostport normalerweise nur über die Loopback-Adresse des Docker-Hosts erreichbar ist.

Eine Ausgabe wie:

0.0.0.0:8080->80/tcp

zeigt eine Veröffentlichung über die passenden IPv4-Adressen des Hosts. Ob ein entfernter Zugriff erlaubt ist, hängt zusätzlich von Firewall, Routing und Netzwerkrichtlinien ab.

18. Typische Fehlerbilder systematisch eingrenzen

Fall A – Auf dem Server existiert kein Listener

Porttest vom Client schlägt fehl
↓
Auf dem Server ist kein LISTEN-Socket vorhanden
↓
Dienststatus, Dienstkonfiguration und Protokolldateien prüfen

Mögliche Ursachen:

Fall B – Dienst lauscht nur auf Loopback

Lokaler Test erfolgreich
Entfernter Test nicht erfolgreich
Listener: 127.0.0.1:PORT oder ::1:PORT

Wahrscheinliche Ursache:

Fall C – Listener vorhanden, entfernter Test läuft in einen Timeout

Mögliche Ursachen:

Fall D – Connection refused

Mögliche Ursachen:

Fall E – TCP-Test erfolgreich, Anwendung funktioniert nicht

Die Netz- und Transportschicht funktionieren zumindest grundsätzlich. Anschließend prüfen:

Fall F – Nur manche Clients sind betroffen

Vergleich zwischen funktionierendem und betroffenem Client:

Fall G – UDP-Test liefert kein eindeutiges Ergebnis

Vorgehen:

  1. Gültige Anfrage des Anwendungsprotokolls senden.
  2. Gleichzeitig auf Client und Server mitschneiden.
  3. Prüfen, ob die Anfrage den Server erreicht.
  4. Prüfen, ob der Server eine Antwort erzeugt.
  5. Prüfen, ob die Antwort den Client erreicht.
  6. ICMP- beziehungsweise ICMPv6-Fehlermeldungen beachten.
19. Empfohlener Diagnoseablauf
Schritt Prüfung Ergebnisfrage
1 Zielhost, Zieladresse, Transportprotokoll und Port bestimmen Was soll genau erreicht werden?
2 Namensauflösung kontrollieren Wird die erwartete IP-Adresse verwendet?
3 Routing und Quelladresse kontrollieren Wird der erwartete Netzwerkpfad verwendet?
4 Dienststatus auf dem Server prüfen Läuft die Anwendung?
5 Lokalen Listener oder UDP-Endpunkt prüfen Lauscht der Dienst auf Port und Adresse?
6 Prozess dem Socket zuordnen Gehört der Port zur erwarteten Anwendung?
7 Lokal auf dem Server testen Funktioniert der Dienst lokal?
8 Vom betroffenen Clientsegment testen Ist der Transportweg funktionsfähig?
9 IPv4 und IPv6 getrennt testen Ist nur eine Adressfamilie betroffen?
10 Anwendungsprotokoll testen Antwortet der eigentliche Dienst korrekt?
11 Firewall, ACL, NAT und Proxy prüfen Wird der Verkehr unterwegs beeinflusst?
12 Paketmitschnitt erstellen Wo endet der erfolgreiche Paketfluss?
13 Vergleich mit funktionierendem System Welche relevante Abweichung besteht?
14 Ergebnis dokumentieren Ist die Diagnose reproduzierbar?

Grundregel:

Listener vorhanden
≠
Port aus jedem Netz erreichbar
≠
Anwendung funktionsfähig
≠
Benutzer kann den Dienst erfolgreich verwenden

Jede dieser Aussagen muss getrennt geprüft werden.

20. Kompakte Befehlstabelle
Aufgabe Windows Linux macOS
TCP-Listener anzeigen [RO] Get-NetTCPConnection -State Listen [RO] ss -ltn [RO] lsof -nP -iTCP -sTCP:LISTEN
UDP-Endpunkte anzeigen [RO] Get-NetUDPEndpoint [RO] ss -lun [RO] lsof -nP -iUDP
Listener mit Prozess [RO] Get-NetTCPConnection -State Listen [RO][PRIV] sudo ss -ltnp [RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN
TCP-Port 443 lokal prüfen [RO] Get-NetTCPConnection -State Listen -LocalPort 443 [RO] ss -ltn 'sport = :443' [RO] lsof -nP -iTCP:443 -sTCP:LISTEN
TCP-Port entfernt testen [TEST] Test-NetConnection HOST -Port 443 [TEST] nc -vz -w 5 HOST 443 [TEST] nc -vz -w 5 HOST 443
HTTP testen [TEST] curl.exe -v http://HOST/ [TEST] curl -v http://HOST/ [TEST] curl -v http://HOST/
HTTPS testen [TEST] curl.exe -v https://HOST/ [TEST] curl -v https://HOST/ [TEST] curl -v https://HOST/
TLS-Handshake Falls OpenSSL installiert: [TEST] openssl s_client -connect HOST:443 -servername HOST [TEST] openssl s_client -connect HOST:443 -servername HOST [TEST] openssl s_client -connect HOST:443 -servername HOST
TCP-Port mit Nmap [TEST] nmap -sT -p 443 HOST [TEST] nmap -sT -p 443 HOST [TEST] nmap -sT -p 443 HOST
UDP-Port mit Nmap Administrator-Konsole: [TEST][PRIV] nmap -sU -p 53 HOST [TEST][PRIV] sudo nmap -sU -p 53 HOST [TEST][PRIV] sudo nmap -sU -p 53 HOST
Bestehende TCP-Verbindungen [RO] Get-NetTCPConnection -State Established [RO] ss -tn state established [RO] netstat -anv -p tcp
Prozess über PID suchen [RO] Get-Process -Id PID [RO] ps -fp PID [RO] ps -p PID -o pid,ppid,user,command

HOST, PID, IP-Adressen und Ports müssen durch die Werte des konkreten Störungsfalls ersetzt werden.

21. Änderungen erst nach gesicherter Diagnose durchführen

Nicht vorschnell:

Stattdessen:

  1. Fehlerzustand dokumentieren.
  2. Erwarteten Sollzustand bestimmen.
  3. Ursache möglichst eindeutig nachweisen.
  4. Änderung genehmigen lassen.
  5. Nur die erforderliche Änderung durchführen.
  6. Funktion und Sicherheit anschließend erneut prüfen.
  7. Rückfallmöglichkeit und Ergebnis dokumentieren.

Ein temporär deaktivierter Paketfilter kann zwar eine Hypothese bestätigen, erzeugt aber ein Sicherheitsrisiko und kann den ursprünglichen Zustand verändern. Besser ist eine gezielte Auswertung von Regeln, Protokollen und Paketmitschnitten.

22. Dokumentationsvorlage für Port- und Transportfehler 
Störung:
Zeitpunkt:
Betroffener Benutzer beziehungsweise Standort:
Clientname:
Client-IP-Adresse:
Client-VLAN:
Client-Betriebssystem:

Zielhostname:
Aufgelöste Zieladresse:
Verwendete Adressfamilie: IPv4 / IPv6
Transportprotokoll: TCP / UDP
Zielport:
Erwarteter Dienst:

Lokaler Listener vorhanden: Ja / Nein
Bind-Adresse:
Zugehöriger Prozess:
Prozess-ID:
Dienststatus:

Lokaler Funktionstest:
Entfernter Porttest:
Anwendungsprotokolltest:
TCP- beziehungsweise UDP-Ergebnis:
Beobachtete Fehlermeldung:
Firewall- oder ACL-Prüfung:
Paketmitschnitt vorhanden:
Beobachtetes Paketmuster:

Vergleich mit funktionierendem System:
Festgestellte Ursache:
Durchgeführte Änderung:
Änderung genehmigt durch:
Ergebnis der Nachprüfung:
Offene Punkte:

Vor der Ablage müssen Passwörter, Sitzungstoken, personenbezogene Daten und andere vertrauliche Inhalte entfernt oder geschützt werden.

23. Kontrollfragen nach der Diagnose
24. Quellen und weiterführende Dokumentation
3. Netzwerkfehler systematisch analysieren

3.10 Firewall- und Paketfilterfehler analysieren

Firewalls können Verbindungen erlauben, verwerfen, ausdrücklich ablehnen, protokollieren oder an andere Ziele weiterleiten. Eine Anwendung kann korrekt laufen und auf dem richtigen Port lauschen, während der Zugriff trotzdem durch einen lokalen oder zentralen Paketfilter verhindert wird.

Die zentrale Frage dieser Seite lautet:

Erreicht der Datenverkehr das Zielsystem, und welche Firewallregel entscheidet tatsächlich über das Paket?

1. Sicherheits- und Aktionskennzeichnungen
Kennzeichnung Bedeutung
[RO] Rein lesender Befehl, der normalerweise keine Konfiguration verändert
[TEST] Aktiver Test, der Netzwerkverkehr erzeugt
[PRIV] Administrator- oder Root-Rechte können erforderlich sein
[FILE] Der Befehl schreibt Ausgaben in eine Datei
[SENS] Die Ausgabe kann sensible Informationen enthalten
[CHANGE] Der Befehl verändert die Konfiguration
[DISRUPT] Der Befehl kann Verbindungen oder Dienste beeinträchtigen

Firewallregeln enthalten häufig interne IP-Adressen, Servernamen, Anwendungen, Netzwerkbereiche und Sicherheitsrichtlinien. Entsprechende Ausgaben sind vertraulich zu behandeln.

2. Firewallfehler nicht vorschnell vermuten

Die Meldung „Das ist bestimmt die Firewall“ ist zunächst nur eine Hypothese. Vor einer Änderung müssen mindestens folgende Punkte geprüft werden:

  1. Wurde der richtige Hostname verwendet?
  2. Wurde die erwartete IP-Adresse aufgelöst?
  3. Ist eine gültige Route zum Ziel vorhanden?
  4. Läuft der benötigte Dienst?
  5. Lauscht der Dienst auf dem erwarteten Port und Protokoll?
  6. Lauscht der Dienst an der richtigen IP-Adresse?
  7. Funktioniert der Zugriff lokal auf dem Server?
  8. Funktioniert der Zugriff aus einem anderen Netzsegment?
  9. Erreicht das Paket das Zielsystem?
  10. Wird eine Blockierung protokolliert?

Wichtig:

Timeout
≠
sicherer Nachweis einer Firewallblockierung

Ein Timeout kann ebenfalls durch Paketverlust, falsches Routing, einen fehlenden Rückweg, eine falsche Zieladresse, NAT-Fehler oder einen ausgefallenen Host entstehen.

3. DROP, REJECT und ALLOW unterscheiden
Aktion Verhalten Typische Beobachtung
ALLOW beziehungsweise ACCEPT Passender Verkehr wird zugelassen Verbindung kann aufgebaut werden
DROP Paket wird ohne Antwort verworfen Client wartet häufig bis zum Timeout
REJECT Paket wird abgelehnt und eine Fehlermeldung zurückgesendet Client erhält häufig schnell einen Fehler
LOG Paketinformationen werden protokolliert Allein keine endgültige Erlaubnis oder Blockierung
DNAT beziehungsweise Portweiterleitung Zieladresse oder Zielport wird verändert Client erreicht möglicherweise ein internes Ziel
SNAT beziehungsweise Masquerading Quelladresse wird verändert Ziel erkennt die Adresse des NAT-Systems
RETURN Verarbeitung kehrt zur aufrufenden Regelkette zurück Wirkung hängt von weiteren Regeln ab

Bei TCP kann eine aktive Ablehnung beispielsweise durch ein TCP-RST sichtbar werden. Bei anderen Fällen kann eine ICMP- oder ICMPv6-Fehlermeldung zurückgegeben werden.

Das genaue Verhalten hängt vom Betriebssystem, Regelwerk und eingesetzten Sicherheitsprodukt ab.

4. Prüfen, welche Firewall tatsächlich verwendet wird

Auf einem System können mehrere Verwaltungsebenen vorhanden sein:

Eine Oberfläche wie ufw oder firewalld verwaltet im Hintergrund das eigentliche Paketfiltersystem. Regeln sollten deshalb nicht unkoordiniert über mehrere Werkzeuge verändert werden.

Betriebssystem Typische lokale Filter
Windows Windows Defender Firewall, IPsec-Regeln, Sicherheitssoftware
Linux nftables, firewalld, ufw, iptables und Sicherheitssoftware
macOS Anwendungsfirewall, Packet Filter pf und Sicherheitssoftware

Grundregel:

Zuerst die aktive Verwaltungs- und Richtlinienebene identifizieren, danach Regeln bewerten.

5. Datenfluss und Prüfrichtung festlegen

Vor der Regelsuche muss der betroffene Datenfluss eindeutig beschrieben werden.

Client-IP:Quellport
        ↓
Transportprotokoll
        ↓
Ziel-IP:Zielport
        ↓
Serveranwendung

Zu dokumentieren sind:

Merkmal Beispiel
Richtung Client zum Server
Adressfamilie IPv4
Transportprotokoll TCP
Quelladresse 192.0.2.25
Quellport dynamisch, beispielsweise 53144
Zieladresse 192.0.2.53
Zielport 443
Schnittstelle Ethernet beziehungsweise eth0
Netzwerkprofil oder Zone Domain beziehungsweise public
Anwendung Webserver
Zeitpunkt Mit Zeitzone und Sekunden

Eingehend und ausgehend sind standortabhängig:

Client: ausgehende Verbindung
Server: eingehende Verbindung

Bei Routern, NAT-Systemen und Firewalls zwischen Netzen kann zusätzlich die Weiterleitungsrichtung betroffen sein.

6. Windows-Firewallstatus und aktive Profile prüfen

Windows verwendet die Profile:

Je nach aktiver Netzwerkverbindung können unterschiedliche Profile und Regeln gelten.

Aktives Netzwerkprofil prüfen:

[RO] Get-NetConnectionProfile |
    Format-Table InterfaceAlias, Name, NetworkCategory, IPv4Connectivity, IPv6Connectivity

Status aller Firewallprofile:

[RO] Get-NetFirewallProfile |
    Format-Table Name, Enabled, DefaultInboundAction, DefaultOutboundAction

Ausführliche Profileinstellungen:

[RO] Get-NetFirewallProfile |
    Format-List Name, Enabled, DefaultInboundAction, DefaultOutboundAction,
                AllowInboundRules, AllowLocalFirewallRules,
                AllowLocalIPsecRules, NotifyOnListen,
                LogAllowed, LogBlocked, LogFileName, LogMaxSizeKilobytes

Klassische Statusanzeige:

[RO] netsh advfirewall show allprofiles

Zu kontrollieren sind:

Typischer Fehler:

Regel gilt nur für Profil Private
↓
Netzwerk wurde als Public erkannt
↓
Regel greift nicht

Das Netzwerkprofil darf nicht allein zur Fehlerbehebung verändert werden. Zuerst ist zu prüfen, warum Windows das Netzwerk entsprechend eingestuft hat und welche Unternehmensrichtlinie gelten soll.

7. Windows-Firewallregeln untersuchen

Alle aktivierten Regeln anzeigen:

[RO][SENS] Get-NetFirewallRule -Enabled True |
    Format-Table DisplayName, Direction, Action, Profile

Aktive Blockierungsregeln anzeigen:

[RO][SENS] Get-NetFirewallRule -Enabled True -Action Block |
    Format-Table DisplayName, Direction, Profile

Aktive eingehende Erlaubnisregeln anzeigen:

[RO][SENS] Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow |
    Format-Table DisplayName, Profile

Bestimmte Regel ausführlich anzeigen:

[RO][SENS] Get-NetFirewallRule -DisplayName "NAME DER REGEL" |
    Format-List *

Windows speichert Port-, Adress-, Programm-, Dienst- und Schnittstellenbedingungen in zugehörigen Filterobjekten. Get-NetFirewallRule allein zeigt deshalb nicht alle Bedingungen einer Regel.

Portbedingungen einer Regel:

[RO] Get-NetFirewallRule -DisplayName "NAME DER REGEL" |
    Get-NetFirewallPortFilter |
    Format-List *

Adressbedingungen einer Regel:

[RO][SENS] Get-NetFirewallRule -DisplayName "NAME DER REGEL" |
    Get-NetFirewallAddressFilter |
    Format-List *

Anwendungsbedingung einer Regel:

[RO][SENS] Get-NetFirewallRule -DisplayName "NAME DER REGEL" |
    Get-NetFirewallApplicationFilter |
    Format-List *

Dienstbedingung einer Regel:

[RO] Get-NetFirewallRule -DisplayName "NAME DER REGEL" |
    Get-NetFirewallServiceFilter |
    Format-List *

Schnittstellenbedingung einer Regel:

[RO] Get-NetFirewallRule -DisplayName "NAME DER REGEL" |
    Get-NetFirewallInterfaceFilter |
    Format-List *

Regeln für lokalen TCP-Port 443 suchen:

[RO][SENS] Get-NetFirewallPortFilter -Protocol TCP |
    Where-Object LocalPort -eq "443" |
    Get-NetFirewallRule |
    Format-Table DisplayName, Enabled, Direction, Action, Profile

Regeln für lokalen UDP-Port 53 suchen:

[RO][SENS] Get-NetFirewallPortFilter -Protocol UDP |
    Where-Object LocalPort -eq "53" |
    Get-NetFirewallRule |
    Format-Table DisplayName, Enabled, Direction, Action, Profile

Regeln für eine bestimmte Anwendung suchen:

[RO][SENS] Get-NetFirewallApplicationFilter |
    Where-Object Program -like "*\PROGRAMM.exe" |
    Get-NetFirewallRule |
    Format-Table DisplayName, Enabled, Direction, Action, Profile

Der Programmpfad muss durch den tatsächlichen Pfad beziehungsweise ein eindeutiges Suchmuster ersetzt werden.

8. Windows-Regeln vollständig beurteilen

Bei einer vermeintlich passenden Regel müssen alle Bedingungen kontrolliert werden:

Bedingung Kontrollfrage
Enabled Ist die Regel aktiviert?
Direction Gilt sie eingehend oder ausgehend?
Action Erlaubt oder blockiert sie?
Profile Gilt sie für das aktive Profil?
Protocol TCP, UDP, ICMPv4 oder ICMPv6?
LocalPort Stimmt der lokale Port?
RemotePort Ist ein bestimmter entfernter Port vorgegeben?
LocalAddress Gilt sie für die verwendete lokale Adresse?
RemoteAddress Ist die Clientadresse oder ihr Netz erlaubt?
Program Stimmt der ausführbare Programmpfad?
Service Ist die Regel an einen bestimmten Dienst gebunden?
InterfaceType Gilt sie für LAN, WLAN oder Remotezugriff?
EdgeTraversalPolicy Ist spezieller eingehender Verkehr betroffen?
Richtlinienquelle Stammt sie lokal, aus Gruppenrichtlinien oder MDM?

Richtlinienquelle anzeigen:

[RO][SENS] Get-NetFirewallRule -PolicyStore ActiveStore |
    Select-Object DisplayName, Enabled, Direction, Action, Profile,
                  PolicyStoreSourceType, PolicyStoreSource |
    Format-Table -AutoSize

ActiveStore repräsentiert die wirksame Zusammenführung der angewendeten Richtlinien. Eine lokal sichtbare Regel kann durch zentral verwaltete Vorgaben eingeschränkt sein.

Wichtig: Eine scheinbar passende Erlaubnisregel beweist nicht automatisch, dass keine andere wirksame Regel oder Sicherheitskomponente den Datenverkehr blockiert.

9. Windows-Firewallprotokollierung prüfen

Konfigurierte Protokolldateien und Einstellungen anzeigen:

[RO] Get-NetFirewallProfile |
    Select-Object Name, LogAllowed, LogBlocked, LogFileName, LogMaxSizeKilobytes |
    Format-List

Der konkrete Speicherort muss aus LogFileName übernommen werden. Er sollte nicht angenommen oder fest im Diagnoseablauf vorgegeben werden.

Konfigurierte Protokolldatei lesen:

[RO][PRIV][SENS] Get-Content "PFAD AUS LogFileName" -Tail 100

Datei fortlaufend beobachten:

[RO][PRIV][SENS] Get-Content "PFAD AUS LogFileName" -Tail 20 -Wait

Während der Beobachtung wird der fehlgeschlagene Verbindungstest erneut ausgeführt. Dabei müssen Zeitpunkt, Quelladresse, Zieladresse, Protokoll und Port abgeglichen werden.

Ereignisprotokolle zur Firewall suchen:

[RO][PRIV][SENS] Get-WinEvent -ListLog *Firewall* |
    Select-Object LogName, IsEnabled, RecordCount

Anschließend kann ein tatsächlich vorhandenes Protokoll gezielt abgefragt werden:

[RO][PRIV][SENS] Get-WinEvent -LogName "ERMITTELTER PROTOKOLLNAME" -MaxEvents 50

Nicht jede Paketblockierung erscheint automatisch im Windows-Ereignisprotokoll. Die erforderliche Überwachung beziehungsweise Protokollierung muss zuvor aktiviert und durch die Unternehmensrichtlinie erlaubt sein.

10. Linux-Firewallsystem identifizieren

Vorhandene Werkzeuge ermitteln:

[RO] command -v firewall-cmd
[RO] command -v nft
[RO] command -v ufw
[RO] command -v iptables

Aktive Dienste prüfen:

[RO] systemctl is-active firewalld
[RO] systemctl is-active nftables
[RO] systemctl is-active ufw

Eine Ausgabe wie inactive, failed oder unknown muss im Kontext der jeweiligen Distribution bewertet werden. Beispielsweise kann ein nftables-Regelwerk aktiv sein, obwohl kein dauerhaft laufender nftables-Dienst angezeigt wird.

Geladene nftables-Regeln prüfen:

[RO][PRIV][SENS] sudo nft list ruleset

iptables-Regeln prüfen:

[RO][PRIV][SENS] sudo iptables -S
[RO][PRIV][SENS] sudo ip6tables -S

iptables-Regeln mit Zählern:

[RO][PRIV][SENS] sudo iptables -L -n -v --line-numbers
[RO][PRIV][SENS] sudo ip6tables -L -n -v --line-numbers

Auf modernen Linux-Systemen kann der Befehl iptables ein Kompatibilitätsfrontend für nftables sein. Deshalb muss geprüft werden, welche Verwaltungsebene die Distribution tatsächlich verwendet.

11. firewalld analysieren

firewalld arbeitet mit Zonen. Schnittstellen oder Quellnetze werden einer Zone zugeordnet, für die Dienste, Ports und weitere Regeln gelten.

Status prüfen:

[RO] firewall-cmd --state

Standardzone anzeigen:

[RO] firewall-cmd --get-default-zone

Aktive Zonen und zugehörige Schnittstellen anzeigen:

[RO] firewall-cmd --get-active-zones

Zone einer bestimmten Schnittstelle ermitteln:

[RO] firewall-cmd --get-zone-of-interface=eth0

eth0 muss durch die tatsächliche Schnittstelle ersetzt werden.

Komplette Laufzeitkonfiguration einer Zone anzeigen:

[RO][SENS] firewall-cmd --zone=public --list-all

Alle Zonen anzeigen:

[RO][SENS] firewall-cmd --list-all-zones

Freigegebene Dienste:

[RO] firewall-cmd --zone=public --list-services

Freigegebene Ports:

[RO] firewall-cmd --zone=public --list-ports

Prüfen, ob TCP-Port 443 in der Laufzeitkonfiguration freigegeben ist:

[RO] firewall-cmd --zone=public --query-port=443/tcp

Prüfen, ob der HTTPS-Dienst freigegeben ist:

[RO] firewall-cmd --zone=public --query-service=https

Rich Rules anzeigen:

[RO][SENS] firewall-cmd --zone=public --list-rich-rules

Policies anzeigen:

[RO][SENS] firewall-cmd --get-policies

Bei jeder Prüfung muss die tatsächlich aktive Zone verwendet werden. Die Zone public ist nur ein Beispiel.

12. firewalld: Laufzeit- und dauerhafte Konfiguration vergleichen

firewalld trennt zwischen:

Aktuelle Laufzeitkonfiguration:

[RO][SENS] firewall-cmd --zone=public --list-all

Dauerhafte Konfiguration:

[RO][SENS] firewall-cmd --permanent --zone=public --list-all

Typische Abweichungen:

Situation Folge
Port nur zur Laufzeit freigegeben Freigabe verschwindet nach Reload oder Neustart
Port nur dauerhaft eingetragen Freigabe ist noch nicht zwingend zur Laufzeit aktiv
Falsche Zone bearbeitet Regel existiert, gilt aber nicht für die betroffene Schnittstelle
Dienstname freigegeben, aber andere Portdefinition erwartet Tatsächlicher Dienstport kann abweichen
Schnittstellenzuordnung geändert Anderes Zonenregelwerk wird wirksam

Eine Abweichung ist nicht automatisch ein Fehler. Sie muss mit dem vorgesehenen Sollzustand verglichen werden.

13. ufw analysieren

Status und Standardrichtlinien anzeigen:

[RO][PRIV][SENS] sudo ufw status verbose

Regeln nummeriert anzeigen:

[RO][PRIV][SENS] sudo ufw status numbered

Erweiterte Rohdarstellung anzeigen:

[RO][PRIV][SENS] sudo ufw show raw

Zu kontrollieren sind:

Beispiel einer begrenzten Regelbeschreibung:

TCP-Port 443
nur aus 192.0.2.0/24
eingehend
über die vorgesehene Schnittstelle

Eine Ausgabe wie 443 ALLOW Anywhere muss zusätzlich hinsichtlich IPv4, IPv6 und der tatsächlich aktiven Backend-Regeln bewertet werden.

14. nftables-Regelwerk untersuchen

Gesamtes geladenes Regelwerk anzeigen:

[RO][PRIV][SENS] sudo nft list ruleset

Tabellen anzeigen:

[RO][PRIV] sudo nft list tables

Regelwerk mit Handles anzeigen:

[RO][PRIV][SENS] sudo nft -a list ruleset

Regelwerk mit Zählern und Handles beobachten:

[RO][PRIV][SENS] sudo nft -a list ruleset

Bei nftables sind insbesondere zu prüfen:

Bestandteil Bedeutung
Familie ip, ip6, inet, arp, bridge oder netdev
Tabelle Logische Sammlung von Chains und Regeln
Base Chain An einen Netfilter-Hook gebundene Kette
Hook Beispielsweise input, output oder forward
Priority Reihenfolge gegenüber anderen Base Chains
Policy Standardaktion der Base Chain
Match Bedingung wie Adresse, Port, Protokoll oder Schnittstelle
Verdict Beispielsweise accept, drop, reject, jump oder return
Counter Anzahl passender Pakete und Bytes
Handle Interne Kennung einer Regel

Wichtige Diagnosefrage:

Steigt der Zähler der vermuteten Regel, während der Verbindungstest ausgeführt wird?

Wenn der Zähler nicht steigt, kann dies bedeuten:

15. iptables-Regeln untersuchen

Filterregeln mit Zählern und Zeilennummern:

[RO][PRIV][SENS] sudo iptables -L -n -v --line-numbers

IPv6-Regeln:

[RO][PRIV][SENS] sudo ip6tables -L -n -v --line-numbers

Regeln in Befehlsschreibweise:

[RO][PRIV][SENS] sudo iptables -S

NAT-Tabelle:

[RO][PRIV][SENS] sudo iptables -t nat -L -n -v --line-numbers

Weitere häufig relevante Tabellen:

[RO][PRIV][SENS] sudo iptables -t mangle -L -n -v --line-numbers
[RO][PRIV][SENS] sudo iptables -t raw -L -n -v --line-numbers

Zu prüfen sind:

Bei iptables entscheidet häufig die erste zutreffende Regel, die ein endgültiges Ziel wie ACCEPT, DROP oder REJECT ausführt. Eine Erlaubnisregel unterhalb einer bereits passenden Blockierungsregel wird dann nicht erreicht.

16. macOS-Anwendungsfirewall prüfen

Die macOS-Anwendungsfirewall kontrolliert hauptsächlich eingehende Verbindungen anhand von Anwendungen und Diensten. Sie ist nicht mit dem Packet Filter pf gleichzusetzen.

Grafische Prüfung:

Systemeinstellungen
→ Netzwerk
→ Firewall

Je nach macOS-Version können die genaue Position und Bezeichnungen abweichen.

Status der Anwendungsfirewall:

[RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate

Prüfen, ob alle eingehenden Verbindungen blockiert werden:

[RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getblockall

Stealth-Modus prüfen:

[RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode

Automatische Freigabe signierter Software prüfen:

[RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getallowsigned

Konfigurierte Anwendungen anzeigen:

[RO][PRIV][SENS] sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps

Zu kontrollieren sind:

Die genaue Ausgabe von socketfilterfw kann zwischen macOS-Versionen variieren.

17. macOS Packet Filter pf prüfen

pf ist ein paketbasierter Filter und getrennt von der macOS-Anwendungsfirewall zu betrachten.

Status und grundlegende Informationen:

[RO][PRIV] sudo pfctl -s info

Geladene Filterregeln anzeigen:

[RO][PRIV][SENS] sudo pfctl -s rules

NAT-Regeln anzeigen:

[RO][PRIV][SENS] sudo pfctl -s nat

Alle verfügbaren pf-Informationen anzeigen:

[RO][PRIV][SENS] sudo pfctl -s all

Zustandstabelle anzeigen:

[RO][PRIV][SENS] sudo pfctl -s states

Regeln mit zusätzlichen Informationen anzeigen:

[RO][PRIV][SENS] sudo pfctl -vvs rules

Zu kontrollieren sind:

Nicht ausführen, solange keine ausdrücklich genehmigte Änderung vorgesehen ist:

pf aktivieren oder deaktivieren
Regelwerk neu laden
Zustandstabellen leeren
Anchors verändern

Solche Aktionen können bestehende Netzwerkverbindungen und Sicherheitsrichtlinien beeinflussen.

18. Host-Firewall oder Netzwerk-Firewall unterscheiden

Ein Vergleich mehrerer Messpunkte hilft, die blockierende Stelle einzugrenzen.

Client
  ↓
Client-Firewall
  ↓
Switch/VLAN
  ↓
Router oder zentrale Firewall
  ↓
Server-Firewall
  ↓
Serveranwendung
Beobachtung Mögliche Schlussfolgerung
Paket verlässt den Client nicht Client-Firewall, Anwendung oder lokales Routing prüfen
Paket verlässt Client, erreicht Server aber nicht Netzwerkpfad, ACL, VPN, NAT oder zentrale Firewall prüfen
Paket erreicht Server, aber Anwendung erhält es nicht Server-Firewall oder falsche Bindung prüfen
SYN erreicht Server, keine Antwort verlässt ihn Listener, Server-Firewall oder lokales Routing prüfen
SYN-ACK verlässt Server, erreicht Client nicht Rückweg oder Filter zwischen Server und Client prüfen
Verbindung funktioniert lokal, aber nicht entfernt Bind-Adresse, Server-Firewall oder Netzwerkfilter prüfen
Nur ein Quellnetz ist betroffen Quellnetz-, VLAN-, Zonen- oder Adressregel prüfen
Nur IPv6 ist betroffen IPv6-Regeln und ICMPv6 gesondert prüfen

Ein gleichzeitiger Paketmitschnitt auf Client und Server ist wesentlich aussagekräftiger als ein einseitiger Porttest.

19. Paketmitschnitt zur Firewallanalyse verwenden

Linux – TCP-Port 443 auf allen Schnittstellen:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i any -nn \
    'host 192.0.2.25 and tcp port 443' \
    -w firewall-test.pcap

macOS – TCP-Port 443 auf einer konkreten Schnittstelle:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i en0 -nn \
    'host 192.0.2.25 and tcp port 443' \
    -w firewall-test.pcap

Windows mit Dumpcap – Schnittstellen ermitteln:

[RO] dumpcap -D

Windows – Mitschnitt auf der zuvor bestimmten Schnittstelle:

[TEST][PRIV][FILE][SENS] dumpcap -i 1 `
    -f "host 192.0.2.25 and tcp port 443" `
    -w firewall-test.pcapng

Die Schnittstellennamen und -nummern sind Beispiele und müssen vorher ermittelt werden.

Wireshark-Anzeigefilter:

Aufgabe Filter
Gesamter Verkehr zwischen zwei IPv4-Systemen ip.addr == 192.0.2.25 && ip.addr == 192.0.2.53
TCP-Port 443 tcp.port == 443
Erste TCP-SYN-Pakete tcp.flags.syn == 1 && tcp.flags.ack == 0
TCP-Reset tcp.flags.reset == 1
ICMP-Fehler icmp
ICMPv6-Fehler icmpv6
Vermutete Wiederholungen tcp.analysis.retransmission

Interpretation:

Paketmuster Mögliche Bedeutung
Wiederholtes SYN ohne Antwort DROP, Paketverlust, falscher Rückweg oder ausgefallenes Ziel
SYN gefolgt von RST/ACK Port geschlossen oder aktive Ablehnung
ICMP administratively prohibited Paketfilter oder Richtlinie lehnt Verkehr ausdrücklich ab
SYN und SYN-ACK sichtbar, ACK fehlt Rückweg oder Clientseite prüfen
Vollständiger Handshake sichtbar Firewall lässt den TCP-Aufbau grundsätzlich zu
Handshake erfolgreich, danach Abbruch Anwendungs-, TLS- oder Sitzungsproblem möglich

Der Mitschnitt beweist nur, was am jeweiligen Messpunkt sichtbar war.

20. Firewallprotokolle zeitlich korrekt auswerten

Für eine zuverlässige Zuordnung werden folgende Werte benötigt:

Datum und Uhrzeit
Zeitzone
Quelladresse
Zieladresse
Transportprotokoll
Quellport
Zielport
Richtung
Aktion
Schnittstelle oder Zone
Regelname beziehungsweise Regel-ID

Systemzeit prüfen:

Betriebssystem Befehl
Windows [RO] Get-Date -Format o
Linux [RO] date --iso-8601=seconds
macOS [RO] date "+%Y-%m-%dT%H:%M:%S%z"

Bei zentralen Firewalls können Zeitstempel in UTC gespeichert werden. Client-, Server- und Firewallzeit müssen deshalb einschließlich Zeitzone verglichen werden.

Empfohlener Testablauf:

  1. Exakten Startzeitpunkt notieren.
  2. Einen einzelnen reproduzierbaren Verbindungstest durchführen.
  3. Exakten Endzeitpunkt notieren.
  4. Protokolle auf dieses Zeitfenster beschränken.
  5. Quell- und Zieladresse sowie Port abgleichen.
  6. Regelname und Aktion dokumentieren.
  7. Bei NAT sowohl ursprüngliche als auch übersetzte Adressen berücksichtigen.
21. Stateful Inspection und Verbindungszustände berücksichtigen

Moderne Firewalls arbeiten häufig zustandsorientiert. Sie verfolgen bestehende Verbindungen und unterscheiden beispielsweise:

Dadurch kann Rückverkehr erlaubt sein, obwohl keine allgemeine eingehende Freigabe für den dynamischen Clientport existiert.

Linux – Conntrack-Werkzeug vorhanden?

[RO] command -v conntrack

Verbindungseinträge anzeigen, sofern das Werkzeug installiert ist:

[RO][PRIV][SENS] sudo conntrack -L

Nur TCP-Verbindungen zu Port 443 filtern:

[RO][PRIV][SENS] sudo conntrack -L -p tcp --dport 443

conntrack ist nicht auf jedem Linux-System standardmäßig installiert.

Mögliche Fehlerbilder:

Zustandstabellen dürfen nicht ohne Freigabe geleert werden. Das kann zahlreiche bestehende Verbindungen unterbrechen.

22. ICMP und ICMPv6 nicht pauschal blockieren

ICMP beziehungsweise ICMPv6 wird nicht nur für ping verwendet. Es übermittelt wichtige Netzwerk- und Fehlermeldungen.

Dazu gehören unter anderem:

Eine zu weitgehende Blockierung kann zu schwer erkennbaren Fehlern führen:

Kleine Pakete funktionieren
↓
Größere Übertragungen bleiben hängen
↓
Erforderliche MTU-Fehlermeldung wird blockiert
↓
Path-MTU-Ermittlung funktioniert nicht richtig

Bei IPv6 sind bestimmte ICMPv6-Funktionen für den regulären Betrieb notwendig. „ICMP vollständig blockieren“ ist daher keine geeignete allgemeine Sicherheitsregel.

23. Typische Firewallfehler
Fehler Wirkung
Falsches Windows-Profil Regel ist vorhanden, aber nicht aktiv
Falsche firewalld-Zone Regel gilt nicht für die betroffene Schnittstelle
TCP statt UDP freigegeben Anwendung bleibt nicht erreichbar
UDP statt TCP freigegeben TCP-Verbindung schlägt weiterhin fehl
Falscher lokaler oder entfernter Port Regel passt nicht zum Datenfluss
Zu enges Quellnetz Bestimmte Clients funktionieren, andere nicht
IPv4-Regel ohne IPv6-Entsprechung Zugriff funktioniert nur über IPv4
Falscher Programmpfad Anwendungsregel greift nach Update nicht mehr
Erlaubnisregel unterhalb einer Blockierungsregel Vorherige Regel entscheidet bereits
Runtime- und permanente Regeln weichen ab Fehler erscheint nach Reload oder Neustart
Eingehend und ausgehend verwechselt Falsche Richtung wurde freigegeben
INPUT und FORWARD verwechselt Router- oder Containerverkehr wird falsch bewertet
Rückweg läuft über andere Firewall Stateful Inspection kann Verbindung verwerfen
Lokale und zentrale Richtlinie widersprechen sich Erwartete lokale Regel ist nicht wirksam
Containerport nicht veröffentlicht Host-Firewallregel allein löst das Problem nicht
Sicherheitssoftware zusätzlich aktiv Native Firewallregeln erklären das Verhalten nicht vollständig
24. Containerverkehr und Firewalls berücksichtigen

Containerverkehr kann zusätzliche Regelketten, Bridges, NAT-Regeln und Weiterleitungen verwenden.

Client
  ↓
Host-Firewall
  ↓
veröffentlichter Hostport
  ↓
NAT oder Container-Proxy
  ↓
Container-Netzwerk
  ↓
Containerport

Docker-Portzuordnungen prüfen:

[RO] docker ps --format 'table {{.Names}}\t{{.Ports}}'

Portzuordnung eines Containers:

[RO] docker port CONTAINERNAME

Docker-Netzwerke anzeigen:

[RO] docker network ls

Konkretes Netzwerk untersuchen:

[RO][SENS] docker network inspect NETZWERKNAME

Zu prüfen sind:

Firewallregeln, die von einer Containerplattform erzeugt wurden, dürfen nicht manuell verändert werden, ohne deren Verwaltungslogik und Auswirkungen zu berücksichtigen.

25. Sichere Gegenprobe ohne vollständiges Abschalten

Eine Firewall vollständig zu deaktivieren ist keine bevorzugte Diagnosemethode. Bessere Gegenproben sind:

  1. Regelzähler vor und nach einem einzelnen Test vergleichen.
  2. Blockierungsprotokoll aktivieren, sofern genehmigt.
  3. Gleichzeitig auf Client und Server mitschneiden.
  4. Eine eng begrenzte temporäre Testregel beantragen.
  5. Nur eine definierte Quelladresse erlauben.
  6. Nur den benötigten Zielport und das richtige Protokoll erlauben.
  7. Testzeitraum begrenzen.
  8. Änderung und Rückbau dokumentieren.
  9. Regel nach dem Test entfernen oder deaktivieren.
  10. Anschließend den ursprünglichen Zustand bestätigen.

Beispiel für den Umfang einer genehmigten Testregel:

Quelle:       192.0.2.25
Ziel:         192.0.2.53
Protokoll:    TCP
Zielport:     443
Richtung:     eingehend
Gültigkeit:   nur während des Wartungsfensters
Protokoll:    aktiv

Die konkreten Änderungsbefehle werden erst nach Prüfung des vorhandenen Regelwerks, der Verwaltungsplattform und des genehmigten Sollzustands erstellt.

26. Warum die Firewall nicht einfach deaktiviert werden sollte

Ein vollständiges Abschalten kann:

Microsoft empfiehlt ausdrücklich, die Windows-Firewall nicht einfach zu deaktivieren. Stattdessen sollen gezielte Regeln und Diagnosefunktionen verwendet werden.

Nicht als allgemeiner Diagnoseschritt verwenden:

Windows-Firewall vollständig ausschalten
firewalld stoppen
ufw deaktivieren
nftables-Regelwerk leeren
iptables-Regeln leeren
pf deaktivieren
Sicherheitssoftware beenden

Diese Aktionen sind Änderungen mit potenziell weitreichenden Sicherheits- und Betriebsfolgen.

27. Systematischer Diagnoseablauf
Schritt Prüfung Leitfrage
1 Datenfluss definieren Welche Quelle muss welches Ziel über welches Protokoll und welchen Port erreichen?
2 Fehler reproduzieren Ist das Verhalten reproduzierbar und zeitlich dokumentiert?
3 DNS und Zieladresse prüfen Wird wirklich das erwartete System angesprochen?
4 Routing prüfen Verwendet das Paket den erwarteten Weg?
5 Serverdienst prüfen Läuft der Dienst und lauscht er richtig?
6 Lokalen Test durchführen Funktioniert der Dienst direkt auf dem Server?
7 Firewallsystem identifizieren Welches Werkzeug und welche Richtlinie sind tatsächlich aktiv?
8 Profil, Zone oder Schnittstelle prüfen Welcher Regelbereich gilt für den Verkehr?
9 Passende Regeln suchen Stimmen Richtung, Protokoll, Port, Adressen und Anwendung?
10 Reihenfolge und Priorität prüfen Entscheidet vorher bereits eine andere Regel?
11 Zähler und Protokolle beobachten Trifft der Testverkehr auf die vermutete Regel?
12 Client- und Servermitschnitt vergleichen An welcher Stelle verschwindet das Paket?
13 Zentrale Filter prüfen Gibt es ACL, VPN-, Cloud- oder Netzwerk-Firewalls?
14 Eng begrenzte Änderung planen Welche minimale Änderung stellt den Sollzustand her?
15 Änderung genehmigen und dokumentieren Wer hat Umfang und Zeitraum freigegeben?
16 Nachprüfung durchführen Funktioniert der Dienst und bleibt die Sicherheit erhalten?
28. Kompakte Befehlstabelle
Aufgabe Windows Linux macOS
Aktives Netzwerkprofil oder Zone [RO] Get-NetConnectionProfile firewalld: [RO] firewall-cmd --get-active-zones Anwendungsfirewall besitzt keine direkt vergleichbaren Netzwerkprofile
Firewallstatus [RO] Get-NetFirewallProfile firewalld: [RO] firewall-cmd --state [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
Aktive Regeln [RO][SENS] Get-NetFirewallRule -Enabled True nftables: [RO][PRIV][SENS] sudo nft list ruleset pf: [RO][PRIV][SENS] sudo pfctl -s rules
Blockierungsregeln [RO][SENS] Get-NetFirewallRule -Enabled True -Action Block Regelwerk nach drop beziehungsweise reject untersuchen Anwendungsregeln: [RO][PRIV][SENS] sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps
TCP-Portregel suchen [RO] Get-NetFirewallPortFilter -Protocol TCP firewalld: [RO] firewall-cmd --zone=ZONE --query-port=443/tcp pf-Regeln: [RO][PRIV][SENS] sudo pfctl -vvs rules
UDP-Portregel suchen [RO] Get-NetFirewallPortFilter -Protocol UDP firewalld: [RO] firewall-cmd --zone=ZONE --query-port=53/udp pf-Regeln: [RO][PRIV][SENS] sudo pfctl -vvs rules
Firewallprofile ausführlich [RO] Get-NetFirewallProfile | Format-List * Nicht direkt vergleichbar [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getblockall
iptables-Regeln Nicht zutreffend [RO][PRIV][SENS] sudo iptables -L -n -v --line-numbers Nicht standardmäßig verwendet
nftables-Regeln Nicht zutreffend [RO][PRIV][SENS] sudo nft -a list ruleset Nicht zutreffend
ufw-Status Nicht zutreffend [RO][PRIV][SENS] sudo ufw status verbose Nicht zutreffend
pf-Status Nicht zutreffend Nicht standardmäßig für alle Distributionen [RO][PRIV] sudo pfctl -s info
TCP-Porttest [TEST] Test-NetConnection HOST -Port 443 [TEST] nc -vz -w 5 HOST 443 [TEST] nc -vz -w 5 HOST 443
Paketmitschnitt Dumpcap oder pktmon [TEST][PRIV][FILE][SENS] sudo tcpdump ... [TEST][PRIV][FILE][SENS] sudo tcpdump ...

HOST, ZONE, Schnittstellen, Adressen und Ports müssen durch die Werte des konkreten Störungsfalls ersetzt werden.

29. Dokumentationsvorlage für Firewallfehler 
Störung:
Zeitpunkt:
Zeitzone:
Betroffener Standort:
Betroffener Benutzer oder Dienst:

Clienthostname:
Client-IP-Adresse:
Client-VLAN:
Client-Schnittstelle:

Zielhostname:
Ziel-IP-Adresse:
Zielport:
Transportprotokoll:
Adressfamilie: IPv4 / IPv6
Erwartete Anwendung:

Dienststatus:
Lokaler Listener:
Bind-Adresse:
Lokaler Funktionstest:
Entfernter Verbindungstest:
Fehlermeldung:

Aktive lokale Firewall:
Aktives Profil beziehungsweise aktive Zone:
Standardaktion eingehend:
Standardaktion ausgehend:
Vermutete Regel:
Regelrichtung:
Regelaktion:
Quellbeschränkung:
Zielbeschränkung:
Portbedingung:
Programmbedingung:
Richtlinienquelle:

Regelzähler vor dem Test:
Regelzähler nach dem Test:
Firewallprotokolleintrag:
Paket am Client sichtbar:
Paket am Server sichtbar:
Antwort am Server sichtbar:
Antwort am Client sichtbar:

Zentrale Firewall oder ACL:
NAT beteiligt:
Container oder Reverse Proxy beteiligt:
Festgestellte Ursache:
Genehmigte Änderung:
Rückfallplan:
Ergebnis der Nachprüfung:
30. Kontrollfragen nach der Diagnose
31. Quellen und weiterführende Dokumentation
3. Netzwerkfehler systematisch analysieren

3.11 NAT- und Portweiterleitungsfehler analysieren

Network Address Translation verändert IP-Adressen und teilweise auch Portnummern während der Übertragung. NAT wird unter anderem an Internetroutern, Firewalls, VPN-Gateways, Virtualisierungshosts und Containerplattformen eingesetzt.

Eine Portweiterleitung kann korrekt eingetragen aussehen und trotzdem nicht funktionieren. Neben der eigentlichen NAT-Regel müssen Routing, Firewall, öffentlicher Anschluss, Rückweg und Zielanwendung geprüft werden.

Die zentralen Fragen dieser Seite lauten:

Erreicht das Paket das NAT-System, wird es korrekt übersetzt und kann das Zielsystem über einen gültigen Rückweg antworten?

1. Sicherheits- und Aktionskennzeichnungen
Kennzeichnung Bedeutung
[RO] Rein lesender Befehl, der normalerweise keine Konfiguration verändert
[TEST] Aktiver Test, der Netzwerkverkehr erzeugt
[PRIV] Administrator- oder Root-Rechte können erforderlich sein
[FILE] Der Befehl schreibt Ausgaben in eine Datei
[SENS] Die Ausgabe kann sensible Informationen enthalten
[CHANGE] Der Befehl verändert eine Konfiguration
[DISRUPT] Der Befehl kann Verbindungen oder Dienste beeinträchtigen

NAT-Tabellen und Routerkonfigurationen können interne Adressen, öffentliche Adressen und erreichbare Dienste offenlegen. Ausgaben dürfen nicht ungeprüft veröffentlicht werden.

2. NAT-Grundbegriffe unterscheiden
Begriff Bedeutung
NAT Allgemeiner Begriff für die Übersetzung von Netzwerkadressen
Source NAT – SNAT Verändert die Quelladresse eines Pakets
Destination NAT – DNAT Verändert die Zieladresse eines Pakets
PAT Verändert zusätzlich Portnummern; mehrere Verbindungen können eine öffentliche Adresse teilen
Masquerading Dynamische Form von SNAT, häufig mit der Adresse der ausgehenden Schnittstelle
Portweiterleitung Eingehender Port wird an eine interne Adresse und gegebenenfalls einen anderen Port weitergeleitet
Redirect Verkehr wird auf das NAT-System selbst beziehungsweise einen lokalen Port umgeleitet
Hairpin NAT Interne Clients greifen über die öffentliche Adresse auf einen ebenfalls internen Dienst zu
Static NAT Feste Zuordnung zwischen Adressen
Dynamic NAT Dynamische Zuordnung aus einem Adresspool
Double NAT Zwei aufeinanderfolgende Systeme führen NAT durch
CGNAT Provider übersetzt mehrere Kundenanschlüsse hinter gemeinsamen öffentlichen Adressen
NAT-Tabelle Regel- oder Zustandsspeicher für Übersetzungen
Conntrack Zustandsverfolgung von Netzwerkverbindungen

Wichtig: Eine Portweiterleitung ist keine automatische Bestätigung, dass der Verkehr auch durch die Firewall erlaubt wird.

3. SNAT, DNAT und PAT am Beispiel

Ausgehende Verbindung mit SNAT beziehungsweise PAT:

Interner Client
192.168.10.25:53144
        ↓
Internetrouter
        ↓
Öffentliche Darstellung
203.0.113.10:62001
        ↓
Webserver
198.51.100.20:443

Der Webserver sieht als Quelle normalerweise die öffentliche Adresse des NAT-Systems und nicht unmittelbar die private Clientadresse.

Eingehende Portweiterleitung mit DNAT:

Externer Client
198.51.100.25:54000
        ↓
203.0.113.10:8443
Öffentliche Routeradresse und externer Port
        ↓ DNAT
192.168.10.50:443
Interner Server und interner Port

Die vollständige Zuordnung lautet in diesem Beispiel:

TCP 203.0.113.10:8443
→ TCP 192.168.10.50:443

Diese Angaben müssen getrennt dokumentiert werden:

4. Private, öffentliche und gemeinsam genutzte Adressen erkennen

Private IPv4-Adressbereiche nach RFC 1918:

Bereich CIDR
10.0.0.0 bis 10.255.255.255 10.0.0.0/8
172.16.0.0 bis 172.31.255.255 172.16.0.0/12
192.168.0.0 bis 192.168.255.255 192.168.0.0/16

Shared Address Space für Carrier-Grade NAT:

100.64.0.0/10

Das entspricht:

100.64.0.0 bis 100.127.255.255

Weitere nicht öffentlich weiterleitbare Beispiele:

Bereich Verwendung
127.0.0.0/8 IPv4-Loopback
169.254.0.0/16 IPv4-Link-Local
224.0.0.0/4 IPv4-Multicast
::1/128 IPv6-Loopback
fe80::/10 IPv6-Link-Local
fc00::/7 IPv6 Unique Local Addresses

Eine Adresse aus einem privaten oder CGNAT-Bereich auf der WAN-Seite des eigenen Routers ist ein deutlicher Hinweis darauf, dass noch ein vorgeschaltetes NAT-System existiert.

5. Häufige Ursachen einer fehlerhaften Portweiterleitung
Ursache Typische Wirkung
Falsche öffentliche IP-Adresse Test erreicht nicht den vorgesehenen Router
Dynamische öffentliche Adresse hat sich geändert Alter DNS-Eintrag oder alte Dokumentation zeigt auf falsches Ziel
CGNAT beim Provider Eingehende Verbindungen erreichen den Kundenrouter nicht direkt
Double NAT Weiterleitung existiert nur auf einem von zwei Routern
Falsches Transportprotokoll TCP wurde weitergeleitet, Dienst benötigt aber UDP oder umgekehrt
Falscher externer Port Client spricht einen anderen Port an
Falscher interner Port Weiterleitung endet nicht am Listener der Anwendung
Falsche interne Zieladresse Serveradresse wurde geändert oder per DHCP neu vergeben
Dienst lauscht nur auf Loopback NAT erreicht den Server, aber nicht den Dienst
Dienst läuft nicht Zielport ist geschlossen
Host-Firewall blockiert Paket erreicht das Zielsystem, wird dort aber verworfen
Router-Firewall blockiert DNAT-Regel allein reicht nicht aus
Fehlender Rückweg Antwort nimmt einen anderen oder ungültigen Weg
Hairpin NAT fehlt Interner Test über öffentliche Adresse schlägt fehl, externer Zugriff kann trotzdem funktionieren
Quelladressbeschränkung Nur bestimmte externe Netze dürfen zugreifen
Falsche Schnittstelle Regel gilt nicht für die tatsächliche WAN-Schnittstelle
IPv4 und IPv6 verwechselt IPv4-Portweiterleitung beeinflusst eine direkte IPv6-Verbindung nicht
Mehrfach belegter externer Port Regelkonflikt oder falsches Ziel
VPN verändert den Pfad Anfrage oder Antwort läuft über einen Tunnel
Containerport nicht veröffentlicht NAT endet am Host, aber nicht am Container
6. Portweiterleitung vollständig dokumentieren

Eine Beschreibung wie „Port 443 ist freigegeben“ ist nicht ausreichend.

Vollständige Beschreibung:

Bezeichnung:       Externer Webzugriff
Adressfamilie:     IPv4
WAN-Schnittstelle: WAN
Quelladresse:      beliebig oder definierter Bereich
Öffentliche IP:    203.0.113.10
Transport:         TCP
Externer Port:     8443
Internes Ziel:     192.168.10.50
Interner Port:     443
Firewallaktion:    Erlauben
Protokollierung:   Aktiviert
Zeitplan:          Dauerhaft

Zusätzlich sollte dokumentiert werden:

7. Zuerst den internen Zieldienst prüfen

Bevor NAT untersucht wird, muss der Dienst ohne Portweiterleitung direkt im internen Netz funktionieren.

Listener auf dem Zielsystem prüfen:

Aufgabe Windows Linux macOS
TCP-Listener [RO] Get-NetTCPConnection -State Listen [RO] ss -ltn [RO] lsof -nP -iTCP -sTCP:LISTEN
UDP-Endpunkte [RO] Get-NetUDPEndpoint [RO] ss -lun [RO] lsof -nP -iUDP
TCP-Port 443 [RO] Get-NetTCPConnection -State Listen -LocalPort 443 [RO] ss -ltn 'sport = :443' [RO] lsof -nP -iTCP:443 -sTCP:LISTEN

Dienst direkt über seine interne Adresse testen:

Windows:

[TEST] Test-NetConnection 192.168.10.50 -Port 443 -InformationLevel Detailed

Linux und macOS:

[TEST] nc -vz -w 5 192.168.10.50 443

Anwendungstest:

[TEST] curl -v https://192.168.10.50/

Bei HTTPS kann ein Zertifikatsfehler auftreten, wenn das Zertifikat für einen Hostnamen und nicht für die IP-Adresse ausgestellt wurde. Für eine korrekte Anwendungsprüfung sollte möglichst der vorgesehene Hostname verwendet werden.

Entscheidung:

Interner Zugriff funktioniert nicht
↓
Zuerst Dienst, Bind-Adresse, lokale Firewall und internes Routing prüfen
↓
NAT noch nicht als Hauptursache behandeln
8. Statische interne Zieladresse sicherstellen

Eine Portweiterleitung verweist normalerweise auf eine konkrete interne IP-Adresse. Ändert sich diese Adresse durch DHCP, zeigt die Regel anschließend möglicherweise auf das falsche System.

Windows:

[RO] Get-NetIPConfiguration

[RO] Get-NetIPAddress -AddressFamily IPv4 |
    Format-Table InterfaceAlias, IPAddress, PrefixLength, PrefixOrigin

Linux:

[RO] ip -br address

[RO] ip address show

macOS:

[RO] ifconfig

[RO] networksetup -listallhardwareports

Zu prüfen sind:

Eine statische Adresse außerhalb des verwalteten Adressplans kann ebenfalls zu Konflikten führen. Bevorzugt wird eine dokumentierte statische Zuweisung oder DHCP-Reservierung entsprechend der Unternehmensvorgaben.

9. Öffentliche Adresse des Anschlusses bestimmen

Zuerst wird die WAN-Adresse direkt in der Verwaltungsoberfläche des Routers oder der Firewall abgelesen. Anschließend kann sie mit der von einem externen Dienst erkannten Adresse verglichen werden.

Lokale Adressen anzeigen:

Windows:

[RO] Get-NetIPAddress |
    Format-Table InterfaceAlias, AddressFamily, IPAddress, PrefixLength

Linux:

[RO] ip -br address

macOS:

[RO] ifconfig

Lokale Befehle zeigen auf einem Client hinter NAT normalerweise nicht die öffentliche IPv4-Adresse des Internetanschlusses.

Öffentlich sichtbare IPv4-Adresse über einen externen Dienst abfragen:

Windows:

[TEST][SENS] Invoke-RestMethod -Uri "https://api.ipify.org"

Linux und macOS:

[TEST][SENS] curl -4 https://api.ipify.org

Öffentlich sichtbare IPv6-Adresse:

[TEST][SENS] curl -6 https://api64.ipify.org

Dabei wird die öffentliche Quelladresse an einen externen Dienst übertragen. Die Nutzung muss durch die betrieblichen Richtlinien erlaubt sein.

Auswertung:

Vergleich Mögliche Bedeutung
Router-WAN-Adresse entspricht externer IPv4-Adresse Router besitzt wahrscheinlich direkt diese öffentliche IPv4-Adresse
Router-WAN-Adresse ist privat Vorgeschalteter Router oder Provider-NAT vorhanden
Router-WAN-Adresse liegt in 100.64.0.0/10 CGNAT ist wahrscheinlich
Router-WAN-Adresse und erkannte öffentliche Adresse unterscheiden sich Weiteres NAT-System oder Proxy vorhanden
Keine öffentliche IPv4-Adresse vorhanden Anschluss kann IPv6, DS-Lite oder andere Providertechnik verwenden

Die genaue Anschlussart muss anhand der Router- und Providerinformationen bestätigt werden.

10. CGNAT, DS-Lite und Double NAT erkennen

Double NAT:

Internet
   ↓
Router oder Modemrouter 1
   ↓ privates Netz
Router 2
   ↓ privates Netz
Interner Server

Für eine klassische eingehende IPv4-Verbindung kann eine Weiterleitung auf beiden NAT-Systemen erforderlich sein.

Carrier-Grade NAT:

Internet
   ↓
Öffentliche Provideradresse
   ↓
Provider-NAT
   ↓
Kundenrouter mit Adresse aus 100.64.0.0/10

Eine Portweiterleitung auf dem Kundenrouter kann das vorgeschaltete Provider-NAT nicht automatisch konfigurieren.

DS-Lite:

Bei DS-Lite wird IPv4-Verkehr über eine Providerinfrastruktur transportiert und typischerweise auf Providerseite übersetzt. Eine frei erreichbare öffentliche IPv4-Adresse steht dem eigenen Router dabei häufig nicht direkt zur Verfügung.

Prüfschritte:

  1. WAN-Adresse des Routers ablesen.
  2. Extern erkannte IPv4-Adresse abfragen.
  3. Adressen miteinander vergleichen.
  4. Prüfen, ob die WAN-Adresse privat oder aus 100.64.0.0/10 ist.
  5. Anschlussinformationen des Providers kontrollieren.
  6. Prüfen, ob eine öffentliche IPv4-Adresse gebucht oder verfügbar ist.
  7. Alternativen wie IPv6, VPN, Reverse Tunnel oder Providerfreigabe nur nach Sicherheitsprüfung planen.
11. Portweiterleitung wirklich von außen testen

Ein Test aus demselben LAN über die öffentliche Adresse ist kein zuverlässiger Ersatz für einen externen Test. Er hängt von der Unterstützung für Hairpin NAT ab.

Geeignete externe Testquellen sind beispielsweise:

Externer TCP-Test unter Windows:

[TEST] Test-NetConnection 203.0.113.10 -Port 8443 -InformationLevel Detailed

Externer TCP-Test unter Linux oder macOS:

[TEST] nc -vz -w 5 203.0.113.10 8443

Anwendungstest mit Hostname:

[TEST] curl -v https://service.example.net:8443/

Gezielter Nmap-Test:

[TEST] nmap -sT -p 8443 203.0.113.10

Tests dürfen nur gegen die eigene beziehungsweise ausdrücklich freigegebene Infrastruktur ausgeführt werden.

12. Hairpin NAT richtig beurteilen

Hairpin NAT wird benötigt, wenn ein interner Client über die öffentliche Adresse oder den öffentlichen DNS-Namen auf einen internen Server zugreift.

Interner Client
      ↓
öffentliche Adresse des eigenen Routers
      ↓
Portweiterleitung
      ↓
interner Server im gleichen Standort

Typisches Fehlerbild:

Zugriff über Mobilfunk funktioniert
Zugriff aus dem internen LAN über öffentliche Adresse funktioniert nicht
Direkter Zugriff über interne Adresse funktioniert

Das deutet auf fehlendes oder fehlerhaftes Hairpin NAT hin. Es beweist nicht, dass die allgemeine externe Portweiterleitung defekt ist.

Mögliche Lösungen abhängig von der Infrastruktur:

Änderungen an DNS oder NAT müssen zum vorgesehenen Netzdesign passen.

13. Split DNS als Alternative zu Hairpin NAT erkennen

Bei Split DNS kann derselbe Hostname intern und extern unterschiedliche Antworten liefern.

Extern:

service.example.net → 203.0.113.10

Intern:

service.example.net → 192.168.10.50

DNS-Antwort prüfen:

Windows:

[TEST] Resolve-DnsName service.example.net -Type A

Linux und macOS:

[TEST] dig service.example.net A

Bestimmten internen DNS-Server abfragen:

[TEST] dig @192.168.10.53 service.example.net A

Bestimmten externen DNS-Server abfragen:

[TEST] dig @1.1.1.1 service.example.net A

Die Verwendung öffentlicher DNS-Server muss durch die Netz- und Datenschutzrichtlinien erlaubt sein. Unternehmensinterne Namen dürfen nicht unnötig an externe Resolver übermittelt werden.

Zu prüfen sind:

14. Windows-NAT-Konfiguration prüfen

Die folgenden Befehle betreffen Windows-NAT-Konfigurationen, die über das NetNat-Modul verwaltet werden, beispielsweise in bestimmten Hyper-V- oder Windows-Container-Szenarien. Sie zeigen nicht automatisch die NAT-Regeln eines externen Routers an.

Vorhandene Windows-NAT-Objekte anzeigen:

[RO][PRIV][SENS] Get-NetNat

Ausführliche Anzeige:

[RO][PRIV][SENS] Get-NetNat |
    Format-List *

Statische Zuordnungen anzeigen:

[RO][PRIV][SENS] Get-NetNatStaticMapping

NAT-Sitzungen anzeigen:

[RO][PRIV][SENS] Get-NetNatSession

Interne Hyper-V-Switches prüfen, sofern Hyper-V eingesetzt wird:

[RO][PRIV] Get-VMSwitch

IP-Adressen der virtuellen Schnittstellen:

[RO] Get-NetIPAddress |
    Where-Object InterfaceAlias -Like "vEthernet*" |
    Format-Table InterfaceAlias, AddressFamily, IPAddress, PrefixLength

Zu prüfen sind:

Keine NAT-Objekte löschen oder neu erstellen, solange der Sollzustand und die Auswirkungen nicht vollständig geklärt sind.

15. Linux-NAT mit nftables prüfen

Gesamtes nftables-Regelwerk anzeigen:

[RO][PRIV][SENS] sudo nft list ruleset

Tabellen anzeigen:

[RO][PRIV] sudo nft list tables

Regelwerk einschließlich Handles anzeigen:

[RO][PRIV][SENS] sudo nft -a list ruleset

Bei NAT-Regeln sind insbesondere folgende Hooks relevant:

Hook Typische Verwendung
prerouting DNAT eingehender Pakete vor der Routingentscheidung
output DNAT lokal erzeugter Pakete
postrouting SNAT oder Masquerading nach der Routingentscheidung
input Bestimmte SNAT-Sonderfälle für lokal zugestellte Pakete

Typische nftables-Ausdrücke erkennen:

dnat to 192.168.10.50:443
snat to 203.0.113.10
masquerade
redirect to :8080

Regeln mit Zählern untersuchen:

[RO][PRIV][SENS] sudo nft -a list ruleset

Zu prüfen ist, ob die Paket- und Bytezähler der erwarteten NAT- und Filterregeln während eines einzelnen Tests steigen.

Wichtig: NAT-Anweisungen sind an NAT-Chains und die dafür vorgesehenen Hooks gebunden. Eine sichtbare Regel beweist nicht, dass das Paket den dazugehörigen Pfad tatsächlich durchläuft.

16. Linux-NAT mit iptables prüfen

NAT-Tabelle mit Zählern und Zeilennummern:

[RO][PRIV][SENS] sudo iptables -t nat -L -n -v --line-numbers

NAT-Regeln in Befehlsschreibweise:

[RO][PRIV][SENS] sudo iptables -t nat -S

IPv6-NAT-Regeln, sofern in der Umgebung verwendet:

[RO][PRIV][SENS] sudo ip6tables -t nat -L -n -v --line-numbers

Filterregeln für weitergeleiteten Verkehr:

[RO][PRIV][SENS] sudo iptables -L FORWARD -n -v --line-numbers

Typische Ziele:

Ziel Bedeutung
DNAT Zieladresse oder Zielport verändern
SNAT Quelladresse oder Quellport verändern
MASQUERADE Dynamische Quelladressübersetzung
REDIRECT Verkehr an das lokale System umleiten
ACCEPT Verkehr zulassen
DROP Verkehr ohne Antwort verwerfen
REJECT Verkehr aktiv ablehnen

Eine passende DNAT-Regel allein reicht nicht aus. Weitergeleiteter Verkehr muss zusätzlich durch die Filterregeln zugelassen und korrekt geroutet werden.

17. IP-Forwarding prüfen

Ein Linux-System, das Pakete zwischen Schnittstellen weiterleiten soll, benötigt eine passende Forwarding-Konfiguration.

IPv4-Forwarding:

[RO] sysctl net.ipv4.ip_forward

Alternative Anzeige:

[RO] cat /proc/sys/net/ipv4/ip_forward

Typische Werte:

Wert Bedeutung
0 IPv4-Weiterleitung deaktiviert
1 IPv4-Weiterleitung aktiviert

IPv6-Forwarding:

[RO] sysctl net.ipv6.conf.all.forwarding

Die Aktivierung von Forwarding ist eine Konfigurationsänderung und darf nicht automatisch vorgenommen werden. Zuerst muss geklärt werden, ob das System laut Netzdesign als Router arbeiten soll.

Zusätzlich prüfen:

[RO] ip route show
[RO] ip -6 route show

NAT ersetzt keine gültige Routingkonfiguration.

18. macOS-NAT- und pf-Regeln prüfen

macOS kann NAT und Weiterleitung über den Packet Filter pf beziehungsweise durch Anwendungen und Systemdienste umsetzen.

pf-Status:

[RO][PRIV] sudo pfctl -s info

NAT-Regeln anzeigen:

[RO][PRIV][SENS] sudo pfctl -s nat

Filterregeln anzeigen:

[RO][PRIV][SENS] sudo pfctl -s rules

Zustände anzeigen:

[RO][PRIV][SENS] sudo pfctl -s states

Regeln mit zusätzlichen Informationen und Zählern:

[RO][PRIV][SENS] sudo pfctl -vvs nat

[RO][PRIV][SENS] sudo pfctl -vvs rules

Routingtabelle prüfen:

[RO] netstat -rn

IPv4-Forwardingstatus:

[RO] sysctl net.inet.ip.forwarding

Zu beachten ist, dass VPN-, Virtualisierungs-, Container- und Sicherheitssoftware eigene pf-Anchors oder Regeln verwenden kann. Das Regelwerk darf nicht ohne Kenntnis dieser Abhängigkeiten neu geladen oder geleert werden.

19. Connection Tracking und NAT-Zustände prüfen

NAT ist normalerweise zustandsorientiert. Das System merkt sich, wie eine Verbindung übersetzt wurde, damit Antwortpakete korrekt zurückübersetzt werden können.

Linux – prüfen, ob conntrack vorhanden ist:

[RO] command -v conntrack

Alle Verbindungseinträge anzeigen:

[RO][PRIV][SENS] sudo conntrack -L

TCP-Verbindungen zu einem Zielport filtern:

[RO][PRIV][SENS] sudo conntrack -L -p tcp --dport 443

UDP-Verbindungen zu einem Zielport filtern:

[RO][PRIV][SENS] sudo conntrack -L -p udp --dport 53

Je nach Übersetzungsrichtung können in einem Eintrag ursprüngliche und übersetzte Adressen erscheinen.

Zu kontrollieren sind:

Zustandstabellen dürfen nicht unkontrolliert geleert werden. Dadurch können bestehende Verbindungen unterbrochen werden.

20. Rückweg und asymmetrisches Routing prüfen

Nach DNAT erreicht ein Paket möglicherweise den internen Server. Der Server muss jedoch über einen gültigen Weg antworten.

Sollzustand:

Externer Client
      ↓
NAT-Gateway
      ↓
Interner Server
      ↓
NAT-Gateway
      ↓
Externer Client

Problematischer asymmetrischer Rückweg:

Anfrage:
Client → NAT-Gateway A → Server

Antwort:
Server → Gateway B → Client

Das NAT-Gateway A sieht die Antwort nicht und kann die notwendige Rückübersetzung nicht durchführen.

Standardgateway des Zielservers prüfen:

Windows:

[RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" |
    Sort-Object RouteMetric |
    Format-Table InterfaceAlias, NextHop, RouteMetric

Linux:

[RO] ip route show default

macOS:

[RO] route -n get default

Route zu einer externen Testadresse prüfen:

Windows:

[RO] Find-NetRoute -RemoteIPAddress 198.51.100.25

Linux:

[RO] ip route get 198.51.100.25

macOS:

[RO] route -n get 198.51.100.25

Die Beispieladresse muss durch die tatsächliche Adresse des autorisierten Testsystems ersetzt werden.

21. Paketmitschnitt vor und nach der Übersetzung erstellen

Idealerweise wird auf beiden Seiten des NAT-Systems gleichzeitig mitgeschnitten.

WAN-Mitschnitt:
Ziel 203.0.113.10:8443

LAN-Mitschnitt:
Ziel 192.168.10.50:443

Linux – WAN-Schnittstelle:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i WAN_INTERFACE -nn \
    'tcp port 8443' \
    -w nat-wan.pcap

Linux – LAN-Schnittstelle:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i LAN_INTERFACE -nn \
    'host 192.168.10.50 and tcp port 443' \
    -w nat-lan.pcap

macOS:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \
    'tcp port 8443 or tcp port 443' \
    -w nat-test.pcap

Windows mit Dumpcap – Schnittstellen ermitteln:

[RO] dumpcap -D

Mitschnitt auf einer bestimmten Schnittstelle:

[TEST][PRIV][FILE][SENS] dumpcap -i 1 `
    -f "tcp port 8443 or tcp port 443" `
    -w nat-test.pcapng

WAN_INTERFACE, LAN_INTERFACE, INTERFACE und die Dumpcap-Schnittstellennummer müssen vorher ermittelt werden.

22. Paketmuster bei NAT-Fehlern interpretieren
WAN-Seite LAN-Seite Mögliche Interpretation
Kein Paket sichtbar Kein Paket sichtbar Falsche öffentliche Adresse, CGNAT, vorgeschalteter Filter oder Clientproblem
SYN sichtbar Kein weitergeleitetes SYN DNAT-Regel, Firewall oder Routing auf dem NAT-System prüfen
SYN an externen Port sichtbar SYN an richtiges internes Ziel sichtbar Übersetzung funktioniert grundsätzlich
SYN erreicht internen Server Kein SYN-ACK vom Server Dienst, Bind-Adresse, Host-Firewall oder Serverrouting prüfen
SYN-ACK verlässt Server Keine Antwort auf WAN-Seite NAT-Zustand, Forwarding, Filter oder Rückweg prüfen
Vollständiger Handshake auf beiden Seiten Anwendung schlägt dennoch fehl Fehler wahrscheinlich oberhalb der Transportschicht
RST kommt vom internen Server Ziel erreichbar, aber Port wird nicht angenommen
ICMP-Fehler sichtbar Abhängig vom Fehlercode Routing-, Filter- oder Erreichbarkeitsproblem weiter untersuchen

Wichtig: Ein Mitschnitt auf nur einer Schnittstelle zeigt nicht den gesamten Übersetzungsvorgang.

23. Docker-Portweiterleitungen prüfen

Docker verwendet bei Bridge-Netzwerken Port Publishing, NAT beziehungsweise Firewallregeln, um Hostports an Containerports weiterzuleiten.

Container und Portzuordnungen anzeigen:

[RO] docker ps --format 'table {{.Names}}\t{{.Ports}}'

Portzuordnung eines bestimmten Containers:

[RO] docker port CONTAINERNAME

Containerkonfiguration prüfen:

[RO][SENS] docker inspect CONTAINERNAME

Docker-Netzwerke anzeigen:

[RO] docker network ls

Netzwerk untersuchen:

[RO][SENS] docker network inspect NETZWERKNAME

Beispiele:

0.0.0.0:8080->80/tcp

Der Hostport 8080/TCP wurde an den Containerport 80/TCP veröffentlicht und ist an den passenden IPv4-Adressen des Hosts gebunden.

127.0.0.1:8080->80/tcp

Der Hostport ist an die Loopback-Adresse gebunden und normalerweise nur vom Docker-Host erreichbar.

8080->80/tcp

Die genaue Bindung muss über die vollständige Docker-Ausgabe beziehungsweise docker inspect geprüft werden.

Wichtig:

EXPOSE 80

EXPOSE dokumentiert den vorgesehenen Containerport, veröffentlicht ihn aber nicht automatisch auf dem Host.

24. Docker-NAT systematisch testen

Ebene 1 – Anwendung im Container

[RO] docker ps

[RO][SENS] docker logs --tail 100 CONTAINERNAME

Ebene 2 – Portzuordnung

[RO] docker port CONTAINERNAME

Ebene 3 – Zugriff vom Docker-Host

[TEST] curl -v http://127.0.0.1:8080/

Ebene 4 – Zugriff über die LAN-Adresse des Hosts

[TEST] curl -v http://HOST_LAN_IP:8080/

Ebene 5 – Zugriff aus einem anderen LAN-System

[TEST] nc -vz -w 5 HOST_LAN_IP 8080

Ebene 6 – Zugriff über eine externe Routerweiterleitung

[TEST] nc -vz -w 5 OEFFENTLICHE_IP EXTERNER_PORT

Der letzte Test muss wirklich aus einem externen Netz erfolgen, sofern Hairpin NAT nicht ausdrücklich mitgeprüft werden soll.

25. IPv4-NAT und IPv6-Zugriff nicht verwechseln

Bei IPv4 wird NAT häufig eingesetzt, weil private Adressen nicht direkt aus dem Internet erreichbar sind.

Bei IPv6 besitzt ein System häufig eine global routbare Adresse. Eine klassische IPv4-Portweiterleitung ist dann nicht automatisch beteiligt. Der Zugriff wird stattdessen insbesondere durch folgende Komponenten bestimmt:

DNS-Einträge prüfen:

Windows:

[TEST] Resolve-DnsName service.example.net -Type A
[TEST] Resolve-DnsName service.example.net -Type AAAA

Linux und macOS:

[TEST] dig service.example.net A
[TEST] dig service.example.net AAAA

HTTPS getrennt testen:

[TEST] curl -4 -v https://service.example.net/
[TEST] curl -6 -v https://service.example.net/

Typischer Fehler:

IPv4-Portweiterleitung ist korrekt
↓
Client bevorzugt jedoch den vorhandenen AAAA-Eintrag
↓
Verbindung erfolgt über IPv6
↓
IPv6-Firewall oder IPv6-Dienstbindung ist fehlerhaft
26. Dynamisches DNS prüfen

Bei wechselnden öffentlichen Adressen wird häufig Dynamic DNS verwendet.

Zu prüfen sind:

DNS-Eintrag prüfen:

Windows:

[TEST] Resolve-DnsName service.example.net

Linux und macOS:

[TEST] dig service.example.net A
[TEST] dig service.example.net AAAA

Autoritativen Nameserver ermitteln:

[TEST] dig service.example.net NS

Antwort eines bestimmten autoritativen Servers abfragen:

[TEST] dig @AUTORITATIVER_DNS_SERVER service.example.net A

Ein veralteter lokaler Cache kann sich von der bereits aktualisierten autoritativen Antwort unterscheiden.

27. NAT-Loopback, Proxy und Reverse Proxy auseinanderhalten

Ein öffentlich erreichbarer Dienst kann über mehrere Weiterleitungsstufen verfügen:

Internet
  ↓
Router-DNAT
  ↓
Reverse Proxy
  ↓
Container-Port
  ↓
Anwendung

Jede Ebene benötigt eine eigene Prüfung.

Ebene Prüffrage
Router-DNAT Wird der externe Port an das richtige interne System weitergeleitet?
Host-Firewall Darf der Verkehr den Reverse Proxy erreichen?
Reverse Proxy Existiert die richtige Host- und Zielkonfiguration?
Container Publishing Ist der Hostport an den Containerport gebunden?
Anwendung Lauscht die Anwendung und verarbeitet sie die Anfrage?
DNS Zeigt der Hostname auf die erwartete öffentliche Adresse?
TLS Stimmt Zertifikat, Hostname und SNI?

Ein funktionierender Router-DNAT beweist nicht, dass der Reverse Proxy oder das Backend funktioniert.

28. Keine unkontrollierte Exposition interner Dienste

Eine Portweiterleitung macht einen Dienst potenziell aus externen Netzen erreichbar. Vor einer Freigabe müssen mindestens geprüft werden:

Besonders Datenbanken, interne Verwaltungsoberflächen, Dateifreigaben und unverschlüsselte Protokolle sollten nicht unkontrolliert direkt veröffentlicht werden.

Keine automatische oder pauschale Portfreigabe über UPnP voraussetzen. Dynamisch erstellte Weiterleitungen müssen ebenso geprüft und dokumentiert werden.

29. Änderungen nur kontrolliert durchführen

Nicht vorschnell:

Sicherer Änderungsablauf:

  1. Istzustand exportieren oder dokumentieren.
  2. Gewünschten Datenfluss vollständig definieren.
  3. Bestehende Regeln und Abhängigkeiten prüfen.
  4. Änderung genehmigen lassen.
  5. Eng begrenzte Regel erstellen.
  6. Protokollierung aktivieren, soweit vorgesehen.
  7. Von intern und extern testen.
  8. Sicherheitsprüfung durchführen.
  9. Ergebnis dokumentieren.
  10. Bei Misserfolg den vorherigen Zustand wiederherstellen.
30. Systematischer Diagnoseablauf
Schritt Prüfung Leitfrage
1 Datenfluss dokumentieren Welche externe Adresse und welcher Port sollen wohin übersetzt werden?
2 Zielanwendung prüfen Läuft der interne Dienst?
3 Listener prüfen Lauscht der Dienst auf Adresse, Port und Protokoll?
4 Internen Zugriff testen Funktioniert der Dienst ohne NAT?
5 Interne Zieladresse prüfen Stimmt die NAT-Regel noch mit der Serveradresse überein?
6 WAN-Adresse prüfen Besitzt der Router die erwartete öffentliche Adresse?
7 CGNAT oder Double NAT prüfen Existiert ein vorgeschaltetes NAT-System?
8 DNS prüfen Zeigt der Hostname auf die aktuelle öffentliche Adresse?
9 NAT-Regel prüfen Stimmen Protokoll, externe und interne Ports sowie Zieladresse?
10 Firewallregeln prüfen Wird der übersetzte Verkehr zugelassen?
11 Forwarding prüfen Darf das System Pakete zwischen Schnittstellen weiterleiten?
12 Rückweg prüfen Antwortet der Server über das NAT-Gateway?
13 Extern testen Erreicht ein Client außerhalb des LANs den Port?
14 Hairpin NAT getrennt testen Betrifft der Fehler nur interne Clients?
15 Paketmitschnitt auf beiden Seiten Wird das Paket korrekt übersetzt?
16 NAT- und Regelzähler prüfen Trifft der Test die erwartete Regel?
17 Container oder Proxy prüfen Existieren weitere Weiterleitungsstufen?
18 Änderung minimal planen Welche kleinste genehmigte Korrektur behebt die Ursache?
19 Nachprüfung Funktioniert der Dienst intern und extern?
20 Dokumentation Sind Regel, Risiko und Rückfallplan festgehalten?
31. Kompakte Befehlstabelle
Aufgabe Windows Linux macOS
Lokale IP-Adressen [RO] Get-NetIPAddress [RO] ip -br address [RO] ifconfig
Standardgateway [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" [RO] ip route show default [RO] route -n get default
Route zu einem Ziel [RO] Find-NetRoute -RemoteIPAddress IP [RO] ip route get IP [RO] route -n get IP
TCP-Listener [RO] Get-NetTCPConnection -State Listen [RO] ss -ltn [RO] lsof -nP -iTCP -sTCP:LISTEN
Internen TCP-Port testen [TEST] Test-NetConnection IP -Port PORT [TEST] nc -vz -w 5 IP PORT [TEST] nc -vz -w 5 IP PORT
Windows-NAT anzeigen [RO][PRIV][SENS] Get-NetNat Nicht zutreffend Nicht zutreffend
Statische Windows-NAT-Zuordnungen [RO][PRIV][SENS] Get-NetNatStaticMapping Nicht zutreffend Nicht zutreffend
nftables-Regeln Nicht zutreffend [RO][PRIV][SENS] sudo nft -a list ruleset Nicht zutreffend
iptables-NAT Nicht zutreffend [RO][PRIV][SENS] sudo iptables -t nat -L -n -v --line-numbers Nicht zutreffend
pf-NAT Nicht zutreffend Nicht standardmäßig allgemein vorhanden [RO][PRIV][SENS] sudo pfctl -vvs nat
IPv4-Forwarding Abhängig von Windows-Rolle [RO] sysctl net.ipv4.ip_forward [RO] sysctl net.inet.ip.forwarding
Conntrack Abhängig von Windows-NAT [RO][PRIV][SENS] sudo conntrack -L pf: [RO][PRIV][SENS] sudo pfctl -s states
Docker-Portzuordnung [RO] docker port CONTAINER [RO] docker port CONTAINER [RO] docker port CONTAINER
Öffentliche IPv4 abfragen [TEST][SENS] Invoke-RestMethod https://api.ipify.org [TEST][SENS] curl -4 https://api.ipify.org [TEST][SENS] curl -4 https://api.ipify.org
DNS-A- und AAAA-Einträge [TEST] Resolve-DnsName HOST [TEST] dig HOST A und [TEST] dig HOST AAAA [TEST] dig HOST A und [TEST] dig HOST AAAA
Externen TCP-Port testen [TEST] Test-NetConnection PUBLIC_IP -Port PORT [TEST] nc -vz -w 5 PUBLIC_IP PORT [TEST] nc -vz -w 5 PUBLIC_IP PORT

IP, PORT, HOST, PUBLIC_IP und CONTAINER müssen durch die Werte des konkreten Störungsfalls ersetzt werden.

32. Dokumentationsvorlage für NAT-Fehler 
Störung:
Zeitpunkt:
Zeitzone:
Betroffener Dienst:
Betroffener Standort:

Öffentlicher DNS-Name:
Aufgelöste IPv4-Adresse:
Aufgelöste IPv6-Adresse:
Router-WAN-Adresse:
Extern erkannte IPv4-Adresse:
CGNAT oder Double NAT vermutet: Ja / Nein
Anschlussart:

Transportprotokoll:
Externe IP-Adresse:
Externer Port:
Interne Zieladresse:
Interner Zielport:
WAN-Schnittstelle:
LAN-Schnittstelle:
Erlaubte Quelladressen:

Interner Server:
Aktuelle Server-IP:
Server-Standardgateway:
Listener vorhanden:
Bind-Adresse:
Host-Firewall geprüft:
Interner Funktionstest:

NAT-System:
NAT-Regelname:
NAT-Regel aktiviert:
DNAT-Regel:
SNAT- oder Masquerading-Regel:
Forwarding aktiviert:
Filterregel:
Regelzähler vor Test:
Regelzähler nach Test:

Test aus internem Netz:
Test über öffentliche Adresse aus internem Netz:
Test aus externem Netz:
Hairpin NAT erforderlich:
Paket auf WAN-Seite sichtbar:
Paket auf LAN-Seite sichtbar:
Antwort des Servers sichtbar:
Antwort auf WAN-Seite sichtbar:

Container beteiligt:
Reverse Proxy beteiligt:
VPN beteiligt:
Festgestellte Ursache:
Genehmigte Änderung:
Rückfallplan:
Ergebnis der Nachprüfung:
33. Kontrollfragen nach der Diagnose
34. Quellen und weiterführende Dokumentation
3. Netzwerkfehler systematisch analysieren

3.12 Proxy- und Reverse-Proxy-Fehler analysieren

Ein Proxy befindet sich zwischen Client und Zielsystem. Je nach Proxyart verarbeitet, filtert, protokolliert oder vermittelt er Verbindungen. Dadurch kann eine direkte Verbindung funktionieren, während der Zugriff über den Proxy fehlschlägt – oder umgekehrt.

Die zentralen Fragen dieser Seite lauten:

Welcher Proxy wird tatsächlich verwendet, wie wurde er ausgewählt und an welcher Stelle zwischen Client, Proxy und Zielsystem scheitert die Verbindung?

1. Sicherheits- und Aktionskennzeichnungen
Kennzeichnung Bedeutung
[RO] Rein lesender Befehl, der normalerweise keine Konfiguration verändert
[TEST] Aktiver Test, der Netzwerkverkehr erzeugt
[PRIV] Administrator- oder Root-Rechte können erforderlich sein
[FILE] Der Befehl schreibt Ausgaben in eine Datei
[SENS] Die Ausgabe kann sensible Informationen enthalten
[CHANGE] Der Befehl verändert eine Konfiguration
[DISRUPT] Der Befehl kann Verbindungen oder Dienste beeinträchtigen

Proxykonfigurationen und ausführliche HTTP-Ausgaben können interne Hostnamen, Benutzernamen, Cookies, Autorisierungsheader und Sitzungstoken enthalten. Sie dürfen nicht ungeprüft dokumentiert oder weitergegeben werden.

2. Proxyarten unterscheiden
Proxyart Position und Aufgabe
Forward Proxy Vermittelt Verbindungen von Clients zu externen oder internen Zielen
Explicit Proxy Client kennt Proxyadresse und Proxyport ausdrücklich
Transparent Proxy Verkehr wird ohne ausdrückliche Proxykonfiguration umgeleitet
Reverse Proxy Nimmt Anfragen für Serverdienste entgegen und leitet sie an Backends weiter
SOCKS-Proxy Vermittelt TCP-Verbindungen und abhängig von Version und Werkzeug weitere Funktionen
Caching Proxy Speichert Antworten zwischen, um Zugriffe zu beschleunigen oder Datenverkehr zu reduzieren
Filtering Proxy Filtert Ziele, Kategorien, Inhalte oder Dateitypen
TLS-Inspection-Proxy Entschlüsselt und untersucht TLS-Verbindungen entsprechend der Sicherheitsrichtlinie
PAC-Proxy Proxy wird durch eine Proxy-Autokonfigurationsdatei ausgewählt
WPAD Verfahren zur automatischen Ermittlung einer Proxykonfiguration
Application Proxy Gilt nur für eine bestimmte Anwendung oder einen bestimmten Dienst
System Proxy Wird durch Betriebssystemkomponenten oder mehrere Anwendungen verwendet

Wichtig: Nicht jede Anwendung verwendet automatisch die systemweite Proxykonfiguration.

3. Forward Proxy und Reverse Proxy auseinanderhalten

Forward Proxy:

Client
  ↓
Forward Proxy
  ↓
Zielserver im Internet oder Netzwerk

Der Client oder das Betriebssystem kennt den Proxy normalerweise.

Reverse Proxy:

Client
  ↓
Reverse Proxy
  ↓
Backend-Anwendung

Der Client kennt normalerweise nur den öffentlichen Dienstnamen. Dass dahinter ein Reverse Proxy und ein oder mehrere Backends stehen, muss für ihn nicht sichtbar sein.

Fehlerstelle Typische Prüfung
Client zum Forward Proxy DNS, Route, Port, Authentifizierung
Forward Proxy zum Zielserver Proxyprotokoll, Filterregel, DNS und Ausgangsverbindung
Client zum Reverse Proxy DNS, Port, TLS und Firewall
Reverse Proxy zum Backend Backendadresse, Port, Protokoll, TLS und Anwendung
Backend selbst Dienststatus, Listener, Protokolle und Antwortzeit
4. Typische Fehlermeldungen einordnen
Meldung oder Status Typische Bedeutung
Could not resolve proxy Proxyhostname konnte nicht aufgelöst werden
Failed to connect to proxy Proxyadresse wurde ermittelt, Verbindung zum Proxyport schlägt fehl
407 Proxy Authentication Required Forward Proxy verlangt eine Authentifizierung
403 Forbidden Zugriff wird durch Zielserver, Proxy oder Richtlinie verweigert
502 Bad Gateway Reverse Proxy erhielt keine gültige Antwort vom Backend
503 Service Unavailable Dienst oder Backend ist nicht verfügbar
504 Gateway Timeout Proxy erhielt innerhalb der vorgesehenen Zeit keine Backendantwort
Connection refused Ziel erreichbar, aber Port wird nicht angenommen
Connection timed out Keine rechtzeitige Antwort; Filterung, Routing oder Ausfall möglich
ERR_PROXY_CONNECTION_FAILED Browser konnte den konfigurierten Proxy nicht verwenden
ERR_TUNNEL_CONNECTION_FAILED Aufbau eines Proxytunnels, häufig per CONNECT, ist fehlgeschlagen
Zertifikat nicht vertrauenswürdig Zertifikatskette, TLS-Inspection oder falsches Zertifikat prüfen
Umleitungsschleife Proxy-, Anwendungsschema- oder Hostheaderkonfiguration prüfen
Nur Browser funktioniert Anwendung verwendet möglicherweise andere Proxyeinstellungen
Browser funktioniert nicht, CLI schon Browser-, PAC-, Zertifikats- oder Erweiterungskonfiguration prüfen

Ein HTTP-Statuscode beweist noch nicht eindeutig, welche Komponente ihn erzeugt hat. Antwortheader und Protokolle müssen miteinander verglichen werden.

5. Den betroffenen Datenfluss dokumentieren

Vor der Diagnose müssen folgende Angaben bekannt sein:

Client:
Client-IP:
Benutzerkontext:
Anwendung:
Ziel-URL:
Zielhostname:
Zielport:
Proxyart:
Proxyhostname:
Proxy-IP:
Proxyport:
PAC-URL:
Verwendete Authentifizierung:
Zeitpunkt:
Fehlermeldung:

Zusätzlich prüfen:

6. Mehrere Proxykonfigurationen berücksichtigen

Auf demselben System können unterschiedliche Einstellungen gleichzeitig existieren:

Typisches Fehlerbild:

Browser verwendet PAC-Datei
PowerShell-Dienst verwendet WinHTTP
CLI-Programm verwendet HTTPS_PROXY
Anwendung besitzt eigene Proxykonfiguration

Deshalb muss immer genau geprüft werden, welche Anwendung unter welchem Benutzerkonto betroffen ist.

7. Proxy-Umgebungsvariablen prüfen

Häufig verwendete Variablen:

http_proxy
https_proxy
all_proxy
no_proxy
HTTP_PROXY
HTTPS_PROXY
ALL_PROXY
NO_PROXY

Die unterstützte Schreibweise hängt von Anwendung und Bibliothek ab. Bei curl besitzt insbesondere http_proxy eine besondere Behandlung und wird aus Sicherheitsgründen nur in Kleinbuchstaben ausgewertet.

Windows PowerShell:

[RO][SENS] Get-ChildItem Env: |
    Where-Object Name -Match '^(http|https|all|no)_proxy$' |
    Sort-Object Name

Windows CMD:

[RO][SENS] set | findstr /I "http_proxy https_proxy all_proxy no_proxy"

Linux und macOS:

[RO][SENS] env | grep -iE '^(http|https|all|no)_proxy='

Nur Variablennamen ohne Werte anzeigen:

[RO] env | sed -n 's/^\([^=]*[Pp][Rr][Oo][Xx][Yy]\)=.*/\1/p'

Proxy-URLs können Zugangsdaten enthalten:

http://benutzer:passwort@proxy.example.internal:8080

Solche Werte dürfen nicht in Tickets, Bildschirmfotos oder Dokumentationen übernommen werden.

8. Windows: WinHTTP-Proxy prüfen

WinHTTP wird von bestimmten Windows-Diensten und Anwendungen verwendet. Seine Konfiguration kann von den benutzerbezogenen Proxy-Einstellungen abweichen.

Grundlegende WinHTTP-Konfiguration:

[RO][SENS] netsh winhttp show proxy

Erweiterte WinHTTP-Konfiguration:

[RO][SENS] netsh winhttp show advproxy

Mögliche Informationen:

Wichtig:

Direkter Zugriff im Browser funktioniert
≠
WinHTTP-Dienst funktioniert

und:

WinHTTP funktioniert
≠
Browser verwendet dieselbe Konfiguration

Änderungsbefehle wie netsh winhttp reset proxy, set proxy oder import proxy dürfen nicht als rein lesende Diagnosebefehle verwendet werden.

9. Windows: benutzerbezogene Proxyeinstellungen prüfen

Relevante Benutzereinstellungen auslesen:

[RO][SENS] Get-ItemProperty `
    "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" |
    Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL, AutoDetect

Je nach Windows-Version und Richtlinienquelle können einzelne Eigenschaften fehlen oder anders verwaltet werden.

Eigenschaft Typische Bedeutung
ProxyEnable Manuell eingetragener Proxy aktiviert
ProxyServer Proxyadresse beziehungsweise protokollspezifische Zuordnungen
ProxyOverride Umgehungsliste
AutoConfigURL URL einer PAC-Datei
AutoDetect Automatische Erkennung aktiviert

Nur vorhandene Werte einzeln prüfen:

[RO][SENS] Get-ItemProperty `
    "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" `
    -ErrorAction SilentlyContinue

Zu kontrollieren sind:

Registrywerte sollten nicht direkt verändert werden, solange Verwaltungsquelle und Sollzustand nicht geklärt sind.

10. Windows: Richtlinien und Benutzerkontext prüfen

Angewendete Gruppenrichtlinien anzeigen:

[RO][FILE][SENS] gpresult /h "%TEMP%\gpresult-proxy.html"

Die erzeugte HTML-Datei befindet sich im temporären Verzeichnis des aktuellen Benutzers.

Nur Textausgabe:

[RO][SENS] gpresult /r

Zu prüfen sind:

Benutzerkontext bestimmen:

[RO] whoami

Ein Dienstkonto, Systemkonto oder anderer Benutzer kann eine andere Proxy- und Zertifikatskonfiguration besitzen als der interaktiv angemeldete Benutzer.

11. macOS-Proxyeinstellungen prüfen

Unter macOS werden Proxyeinstellungen pro Netzwerkdienst verwaltet, beispielsweise getrennt für WLAN und Ethernet.

Netzwerkdienste anzeigen:

[RO] networksetup -listallnetworkservices

Ein Sternchen vor einem Dienstnamen weist in der Ausgabe darauf hin, dass der Netzwerkdienst deaktiviert ist.

HTTP-Proxy eines Netzwerkdienstes:

[RO][SENS] networksetup -getwebproxy "Wi-Fi"

HTTPS-Proxy:

[RO][SENS] networksetup -getsecurewebproxy "Wi-Fi"

SOCKS-Proxy:

[RO][SENS] networksetup -getsocksfirewallproxy "Wi-Fi"

PAC-URL:

[RO][SENS] networksetup -getautoproxyurl "Wi-Fi"

Proxy-Umgehungsliste:

[RO][SENS] networksetup -getproxybypassdomains "Wi-Fi"

Wi-Fi muss durch den tatsächlich verwendeten Netzwerkdienst ersetzt werden.

Alle aktiven Proxyinformationen zusammengefasst anzeigen:

[RO][SENS] scutil --proxy

Zu kontrollieren sind:

12. Linux-Proxyeinstellungen prüfen

Linux besitzt keine für alle Distributionen und Anwendungen einheitliche Proxyverwaltung. Zu prüfen sind insbesondere:

Umgebungsvariablen:

[RO][SENS] env | grep -iE '^(http|https|all|no)_proxy='

Systemweite Umgebungsdatei prüfen, sofern vorhanden:

[RO][SENS] test -f /etc/environment && sed -n '/[Pp][Rr][Oo][Xx][Yy]/p' /etc/environment

systemd-Umgebung eines Dienstes anzeigen:

[RO][PRIV][SENS] sudo systemctl show DIENSTNAME \
    --property=Environment \
    --property=EnvironmentFiles

Vollständige Unit-Konfiguration anzeigen:

[RO][PRIV][SENS] sudo systemctl cat DIENSTNAME

Laufenden Prozess und Benutzer prüfen:

[RO] systemctl status DIENSTNAME

DIENSTNAME muss durch den tatsächlichen Dienst ersetzt werden.

Ein interaktiver Shell-Test beweist nicht, dass ein systemd-Dienst dieselben Umgebungsvariablen verwendet.

13. Manuelle Proxyverbindung mit curl testen

HTTP-Ziel ausdrücklich über einen Proxy testen:

[TEST][SENS] curl -v \
    --proxy http://proxy.example.internal:8080 \
    http://example.com/

HTTPS-Ziel über einen HTTP-Proxy testen:

[TEST][SENS] curl -v \
    --proxy http://proxy.example.internal:8080 \
    https://example.com/

Bei HTTPS verwendet curl über einen HTTP-Proxy normalerweise einen CONNECT-Tunnel zum Ziel.

Nur Antwortheader abrufen:

[TEST][SENS] curl -I \
    --proxy http://proxy.example.internal:8080 \
    https://example.com/

Zeitlimit setzen:

[TEST][SENS] curl -v \
    --connect-timeout 5 \
    --max-time 15 \
    --proxy http://proxy.example.internal:8080 \
    https://example.com/

Wichtige Ausgaben:

Trying PROXY_IP:PORT
Connected to proxy
CONNECT ziel.example:443
HTTP/1.1 200 Connection established
Proxy-Authenticate
HTTP-Statuscode
TLS-Handshake
Zertifikatskette

curl -v kann sensible Header ausgeben. Vor der Dokumentation müssen Zugangsdaten, Cookies und Token entfernt werden.

14. Direkten Zugriff und Proxyzugriff vergleichen

Proxy ausdrücklich umgehen:

[TEST][SENS] curl -v --noproxy "*" https://example.com/

Proxy ausdrücklich verwenden:

[TEST][SENS] curl -v \
    --proxy http://proxy.example.internal:8080 \
    https://example.com/

Nur für ein bestimmtes Ziel den Proxy umgehen:

[TEST][SENS] curl -v \
    --noproxy "example.com" \
    https://example.com/

Vergleich:

Direkter Zugriff Proxyzugriff Mögliche Eingrenzung
Erfolgreich Fehlerhaft Proxy, Authentifizierung, PAC oder Filterrichtlinie prüfen
Fehlerhaft Erfolgreich Direkter Weg blockiert oder Proxy ist vorgeschrieben
Beide fehlerhaft Ziel, DNS, Clientnetz oder allgemeine Störung prüfen
Beide erfolgreich Fehler ist möglicherweise anwendungsspezifisch
Nur Browser fehlerhaft Browserprofil, PAC, Zertifikat oder Erweiterung prüfen
Nur Systemdienst fehlerhaft WinHTTP-, Dienstkonto- oder Dienstumgebung prüfen

Ein direkter Test darf nur durchgeführt werden, wenn die Sicherheitsrichtlinie einen Proxy-Bypass erlaubt.

15. Proxyhostname, Port und Erreichbarkeit prüfen

Namensauflösung des Proxys:

Windows:

[TEST] Resolve-DnsName proxy.example.internal

Linux:

[TEST] getent ahosts proxy.example.internal

macOS:

[TEST] dscacheutil -q host -a name proxy.example.internal

Proxyport testen:

Windows:

[TEST] Test-NetConnection proxy.example.internal -Port 8080 -InformationLevel Detailed

Linux und macOS:

[TEST] nc -vz -w 5 proxy.example.internal 8080

Route zum Proxy prüfen:

Windows:

[RO] Find-NetRoute -RemoteIPAddress PROXY_IP

Linux:

[RO] ip route get PROXY_IP

macOS:

[RO] route -n get PROXY_IP

Ein erfolgreicher TCP-Porttest beweist nur, dass eine Verbindung zum Proxyport aufgebaut werden konnte. Er beweist nicht, dass der Proxy die gewünschte Zielverbindung erlaubt.

16. PAC-Datei und automatische Proxyauswahl prüfen

Eine PAC-Datei enthält JavaScript und liefert über die Funktion FindProxyForURL() eine Proxyentscheidung.

Typische Rückgabewerte:

DIRECT
PROXY proxy.example.internal:8080
HTTPS proxy.example.internal:8443
SOCKS socks.example.internal:1080

Mehrere Möglichkeiten können in einer Reihenfolge angegeben werden:

PROXY proxy1.example.internal:8080;
PROXY proxy2.example.internal:8080;
DIRECT

Konfigurierte PAC-URL ermitteln:

PAC-Datei kontrolliert abrufen:

[TEST][SENS] curl -v "http://config.example.internal/proxy.pac"

Ohne möglicherweise bereits gesetzte Proxyvariablen abrufen:

[TEST][SENS] curl -v --noproxy "*" \
    "http://config.example.internal/proxy.pac"

Zu prüfen sind:

PAC-Dateien sind ausführbarer JavaScript-Code und dürfen nur aus vertrauenswürdigen Quellen bezogen werden.

17. WPAD und automatische Erkennung beurteilen

WPAD kann eine Proxykonfiguration automatisch bereitstellen. Abhängig von der Umgebung kann die Ermittlung unter anderem über DHCP oder DNS erfolgen.

Mögliche Fehler:

Windows-DNS-Suffixe prüfen:

[RO] Get-DnsClient |
    Select-Object InterfaceAlias, ConnectionSpecificSuffix

Windows-DNS-Konfiguration:

[RO] Get-DnsClientGlobalSetting

Linux-Suchdomänen prüfen:

[RO] resolvectl status

Falls resolvectl nicht vorhanden ist:

[RO] cat /etc/resolv.conf

macOS-DNS-Konfiguration:

[RO][SENS] scutil --dns

WPAD darf nicht durch willkürlich angelegte DNS-Einträge getestet werden. Eine fehlerhafte oder manipulierte WPAD-Konfiguration kann den gesamten Webverkehr umleiten.

18. Proxy-Umgehungslisten prüfen

Eine Umgehungsliste bestimmt, welche Ziele direkt und nicht über den Proxy erreicht werden.

Typische Einträge:

localhost
127.0.0.1
::1
*.example.internal
192.168.0.0/16
<local>

Die unterstützte Syntax unterscheidet sich zwischen Betriebssystemen und Anwendungen. Nicht jede Anwendung versteht CIDR-Netze, Platzhalter oder <local> gleich.

Typische Fehler:

curl-Entscheidung sichtbar machen:

[TEST][SENS] curl -v https://service.example.internal/

In der ausführlichen Ausgabe kann curl anzeigen, welche Proxy- beziehungsweise NO_PROXY-Variable berücksichtigt wurde.

19. Proxy-Authentifizierung untersuchen

Ein Forward Proxy kann unter anderem folgende Verfahren verwenden:

Proxyantwort ohne Zugangsdaten prüfen:

[TEST][SENS] curl -v \
    --proxy http://proxy.example.internal:8080 \
    https://example.com/

Auf folgende Header achten:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic
Proxy-Authenticate: NTLM
Proxy-Authenticate: Negotiate

Sicherheitsregeln:

Benutzerkontext prüfen:

Windows:

[RO] whoami

Linux und macOS:

[RO] id

Ein Hintergrunddienst besitzt möglicherweise keine interaktive Benutzersitzung und kann daher keine integrierte Proxyauthentifizierung durchführen.

20. TLS-Inspection und Zertifikatsfehler analysieren

Bei TLS-Inspection baut die Sicherheitskomponente getrennte TLS-Verbindungen auf:

Client
  ↓ TLS-Verbindung 1
Inspection-Proxy
  ↓ TLS-Verbindung 2
Zielserver

Der Client sieht dabei ein vom Inspection-System ausgestelltes Zertifikat.

Zertifikat über den vorgesehenen Verbindungsweg prüfen:

[TEST][SENS] curl -v https://example.com/

TLS-Verbindung zu einem HTTPS-Ziel über HTTP-Proxy untersuchen:

[TEST][SENS] curl -v \
    --proxy http://proxy.example.internal:8080 \
    https://example.com/

Zu prüfen sind:

Typisches Fehlerbild:

Browser funktioniert
CLI-Anwendung meldet unbekannte Zertifizierungsstelle

Mögliche Ursache:

Die Zertifikatsprüfung darf nicht dauerhaft deaktiviert werden. Optionen wie curl -k dienen höchstens einer genehmigten Eingrenzung und stellen keine Fehlerbehebung dar.

21. Reverse Proxy vom Backend trennen

Ein Reverse-Proxy-Datenfluss besteht mindestens aus zwei Verbindungen:

Verbindung 1:
Client → Reverse Proxy

Verbindung 2:
Reverse Proxy → Backend

Beide Verbindungen können unterschiedliche Eigenschaften besitzen:

Eigenschaft Clientseite Backendseite
Protokoll HTTPS HTTP oder HTTPS
Port 443 beispielsweise 80, 8080 oder 8443
DNS öffentlicher Dienstname interner Backendname
Zertifikat öffentliches oder internes Frontendzertifikat gegebenenfalls internes Backendzertifikat
Authentifizierung Benutzeranmeldung Dienst- oder keine zusätzliche Anmeldung
Firewall Client zum Proxy Proxy zum Backend
Timeout Frontendtimeout Upstreamtimeout

Ein erfolgreicher Zugriff auf den Reverse-Proxy-Port beweist nicht, dass das Backend erreichbar ist.

22. Reverse Proxy systematisch prüfen

Schritt 1 – DNS des öffentlichen Dienstnamens:

Windows:

[TEST] Resolve-DnsName service.example.net

Linux und macOS:

[TEST] dig service.example.net A
[TEST] dig service.example.net AAAA

Schritt 2 – Frontend-Port:

Windows:

[TEST] Test-NetConnection service.example.net -Port 443

Linux und macOS:

[TEST] nc -vz -w 5 service.example.net 443

Schritt 3 – Frontend-Anwendung:

[TEST][SENS] curl -v https://service.example.net/

Schritt 4 – Backend vom Reverse-Proxy-System aus:

[TEST][SENS] curl -v http://backend.example.internal:8080/

Schritt 5 – Backend-Port:

[TEST] nc -vz -w 5 backend.example.internal 8080

Schritt 6 – Protokolle des Reverse Proxys:

Der Backendtest muss vom Reverse-Proxy-System beziehungsweise aus dessen Netzwerk- oder Containerkontext erfolgen. Ein Test von einem Administrator-PC kann einen anderen Netzwerkpfad verwenden.

23. Wichtige Reverse-Proxy-Header prüfen

Reverse Proxys übermitteln dem Backend häufig Informationen über die ursprüngliche Anfrage.

Typische Header:

Host
X-Forwarded-For
X-Forwarded-Host
X-Forwarded-Proto
Forwarded
Header Typische Aufgabe
Host Ursprünglich angesprochener Hostname
X-Forwarded-For Ursprüngliche Clientadresse beziehungsweise Proxykette
X-Forwarded-Host Ursprünglich verwendeter Host
X-Forwarded-Proto Ursprüngliches Schema wie http oder https
Forwarded Standardisierter Header für Proxyinformationen

Mögliche Fehler:

Forwarded-Header dürfen nur von ausdrücklich vertrauenswürdigen Proxys als verlässlich behandelt werden.

24. Reverse-Proxy-Statuscodes untersuchen
Status Mögliche Ursache
400 Ungültige Anfrage, fehlerhafter Hostheader oder Protokollfehler
401 Anwendung verlangt Authentifizierung
403 Zugriff durch Proxy oder Backend verweigert
404 Falscher Host, Pfad oder Backendrouting
408 Anfrage wurde nicht rechtzeitig vollständig empfangen
413 Anfrage oder Upload überschreitet eine Größenbegrenzung
421 Anfrage wurde einem unpassenden Ziel beziehungsweise virtuellen Host zugeordnet
429 Rate Limit wurde erreicht
431 Header sind zu groß
499 Nicht standardisierter, insbesondere bei NGINX verwendeter Status für Clientabbruch
500 Interner Anwendungs- oder Proxyfehler
502 Backend nicht erreichbar oder ungültige Backendantwort
503 Kein verfügbares Backend oder Dienst absichtlich nicht verfügbar
504 Backend antwortet nicht rechtzeitig

Zur eindeutigen Zuordnung müssen Antwortheader, Proxyprotokoll und Backendprotokoll zum selben Zeitpunkt verglichen werden.

25. NGINX-Reverse-Proxy prüfen

Die folgenden Befehle gelten nur, wenn NGINX tatsächlich eingesetzt wird.

Konfigurationssyntax prüfen:

[RO][PRIV][SENS] sudo nginx -t

Dieser Befehl prüft die Konfiguration, lädt sie aber nicht neu.

Vollständig aufgelöste Konfiguration anzeigen:

[RO][PRIV][SENS] sudo nginx -T

Die Ausgabe kann Zertifikatspfade, interne Hostnamen und weitere sensible Konfigurationswerte enthalten.

Dienststatus:

[RO] systemctl status nginx

Prozess und Listener:

[RO] ss -ltnp

Dienstprotokolle über systemd:

[RO][PRIV][SENS] sudo journalctl -u nginx --since "-15 minutes"

Zu prüfen sind:

Ein erfolgreicher nginx -t beweist nur, dass NGINX die Konfiguration syntaktisch akzeptiert. Er beweist nicht, dass das Backend erreichbar ist.

26. Container und Reverse Proxy prüfen

Bei containerisierten Anwendungen entstehen zusätzliche Ebenen:

Client
  ↓
Hostport
  ↓
Reverse-Proxy-Container
  ↓
Docker-Netzwerk
  ↓
Backend-Container
  ↓
Anwendung

Container und Ports anzeigen:

[RO] docker ps --format 'table {{.Names}}\t{{.Ports}}'

Netzwerke anzeigen:

[RO] docker network ls

Netzwerk untersuchen:

[RO][SENS] docker network inspect NETZWERKNAME

Containerprotokolle:

[RO][SENS] docker logs --tail 100 CONTAINERNAME

Umgebungsvariablen eines Containers kontrollieren:

[RO][SENS] docker inspect CONTAINERNAME

Zu prüfen sind:

27. NO_PROXY bei Containern und internen Diensten prüfen

Ein Container kann ausgehende Verbindungen über einen Forward Proxy senden. Interne Dienste sollten abhängig vom Sollzustand möglicherweise direkt erreichbar sein.

Beispiel:

HTTP_PROXY=http://proxy.example.internal:8080
HTTPS_PROXY=http://proxy.example.internal:8080
NO_PROXY=localhost,127.0.0.1,backend,backend.example.internal

Typisches Fehlerbild:

Anwendung möchte internen Backend-Container erreichen
↓
Backendname fehlt in NO_PROXY
↓
Anfrage wird an Unternehmensproxy gesendet
↓
Proxy kann internen Containernamen nicht auflösen
↓
Verbindung schlägt fehl

Konfiguration anzeigen:

[RO][SENS] docker inspect CONTAINERNAME

Die genaue NO_PROXY-Syntax hängt von Anwendung und verwendeter Bibliothek ab. Änderungen müssen deshalb mit deren Dokumentation abgeglichen werden.

28. DNS-Auflösung aus dem richtigen Kontext prüfen

Client, Forward Proxy, Reverse Proxy und Backend können unterschiedliche DNS-Server und Antworten verwenden.

System Muss auflösen können
Client Proxyhostname und gegebenenfalls Zielhostname
Forward Proxy Externes oder internes Ziel
Reverse Proxy Backendhostname
Backend Abhängige Datenbanken, APIs und Dienste
Container Containername oder internen DNS-Namen

Windows:

[TEST] Resolve-DnsName HOSTNAME

Linux:

[TEST] getent ahosts HOSTNAME

macOS:

[TEST] dscacheutil -q host -a name HOSTNAME

Der Befehl muss auf dem System ausgeführt werden, das die jeweilige Verbindung tatsächlich aufbaut.

Typisches Beispiel:

Administrator-PC kann backend.example.internal auflösen
Reverse-Proxy-Container kann den Namen nicht auflösen

Der erfolgreiche Test vom Administrator-PC ist dann für die Backendverbindung nicht ausreichend.

29. Zeitüberschreitungen systematisch unterscheiden

Ein Proxyweg kann mehrere Time-outs besitzen:

Client-Verbindungszeit
Proxy-Verbindungszeit zum Backend
Zeit zum Senden der Anfrage
Zeit bis zum ersten Antwortbyte
Zeit zwischen Antwortdaten
Gesamtdauer der Anfrage

curl-Zeitmessung:

[TEST][SENS] curl -sS -o /dev/null \
    -w 'DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nStartTransfer: %{time_starttransfer}\nTotal: %{time_total}\nHTTP: %{http_code}\n' \
    https://service.example.net/

Über einen expliziten Proxy:

[TEST][SENS] curl -sS -o /dev/null \
    --proxy http://proxy.example.internal:8080 \
    -w 'DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nStartTransfer: %{time_starttransfer}\nTotal: %{time_total}\nHTTP: %{http_code}\n' \
    https://service.example.net/

Die Zeitwerte müssen mit Proxy- und Backendprotokollen verglichen werden. Ein 504 beweist nicht automatisch, dass das Backend vollständig ausgefallen ist; es kann lediglich später als das konfigurierte Zeitlimit geantwortet haben.

30. Paketmitschnitt für Proxyfehler erstellen

Verkehr zwischen Client und Forward Proxy:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \
    'host PROXY_IP and tcp port PROXY_PORT' \
    -w client-proxy.pcap

Verkehr zwischen Reverse Proxy und Backend:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \
    'host BACKEND_IP and tcp port BACKEND_PORT' \
    -w proxy-backend.pcap

Windows mit Dumpcap – Schnittstellen anzeigen:

[RO] dumpcap -D

Windows – Proxyverkehr aufzeichnen:

[TEST][PRIV][FILE][SENS] dumpcap -i 1 `
    -f "host PROXY_IP and tcp port PROXY_PORT" `
    -w proxy-test.pcapng

Wireshark-Anzeigefilter:

Aufgabe Filter
Proxyport 8080 tcp.port == 8080
HTTP-Statuscodes http.response.code
Status 407 http.response.code == 407
Status 502 http.response.code == 502
Status 504 http.response.code == 504
HTTP-CONNECT http.request.method == "CONNECT"
TLS-Handshake tls.handshake
TCP-Reset tcp.flags.reset == 1
TCP-Wiederholungen tcp.analysis.retransmission

Verschlüsselter Datenverkehr zeigt ohne zulässige Entschlüsselung nicht den vollständigen HTTP-Inhalt.

31. Typische Fehlerbilder systematisch eingrenzen

Fall A – Proxyhostname kann nicht aufgelöst werden

Prüfen:

Fall B – Proxyport ist nicht erreichbar

Prüfen:

Fall C – HTTP 407

Prüfen:

Fall D – Browser funktioniert, Dienst nicht

Prüfen:

Fall E – Direkter Zugriff funktioniert, Proxyzugriff nicht

Prüfen:

Fall F – Reverse Proxy liefert 502

Prüfen:

Fall G – Reverse Proxy liefert 504

Prüfen:

Fall H – Endlose Umleitung

Prüfen:

32. Keine vorschnellen Proxyänderungen durchführen

Nicht unkontrolliert:

Sicheres Vorgehen:

  1. Istkonfiguration dokumentieren.
  2. Verwaltungsquelle bestimmen.
  3. Betroffene Anwendung und Benutzerkontext feststellen.
  4. Direkten und proxied Datenfluss getrennt prüfen.
  5. Proxy- und Backendprotokolle zeitlich zuordnen.
  6. Ursache nachweisen.
  7. Änderung genehmigen lassen.
  8. Kleinste erforderliche Änderung durchführen.
  9. Funktion und Sicherheit prüfen.
  10. Rückfallmöglichkeit dokumentieren.
33. Systematischer Diagnoseablauf
Schritt Prüfung Leitfrage
1 Anwendung und Benutzerkontext bestimmen Wer baut die Verbindung tatsächlich auf?
2 Ziel-URL dokumentieren Welcher Host, Port und welches Protokoll werden verwendet?
3 Proxyart bestimmen Forward Proxy, PAC, transparent oder Reverse Proxy?
4 Konfigurationsquelle ermitteln System, Anwendung, Richtlinie, Variable oder MDM?
5 Proxyhostname auflösen Wird die erwartete Proxyadresse verwendet?
6 Proxyport prüfen Ist der Proxy transportseitig erreichbar?
7 PAC- beziehungsweise WPAD-Auswahl prüfen Welcher Proxy wird für diese URL gewählt?
8 Umgehungsliste prüfen Soll das Ziel direkt oder über Proxy erreicht werden?
9 Proxytest durchführen Welche Antwort liefert der Proxy?
10 Authentifizierung prüfen Wird 407 oder ein anderes Verfahren verwendet?
11 Direkten Vergleichstest durchführen Liegt der Fehler nur im Proxyweg?
12 Zertifikatskette prüfen Ist TLS-Inspection oder ein Vertrauensproblem beteiligt?
13 Reverse-Proxy-Frontend prüfen Erreicht der Client den Reverse Proxy?
14 Backend vom Proxy aus prüfen Kann der Proxy das Backend erreichen?
15 Header und Protokoll prüfen Stimmen Host, Schema und Forwarded-Header?
16 Protokolle vergleichen Welche Komponente erzeugt den Fehler?
17 Paketmitschnitt erstellen An welcher Verbindung scheitert der Datenfluss?
18 Minimale Änderung planen Welche konkrete Korrektur stellt den Sollzustand her?
19 Nachprüfung Funktionieren Anwendung, Authentifizierung und TLS?
20 Dokumentation Sind Ursache, Änderung und Rückfallplan festgehalten?
34. Kompakte Befehlstabelle
Aufgabe Windows Linux macOS
Proxyvariablen [RO][SENS] Get-ChildItem Env: | Where-Object Name -Match 'proxy' [RO][SENS] env | grep -i proxy [RO][SENS] env | grep -i proxy
WinHTTP-Proxy [RO][SENS] netsh winhttp show proxy Nicht zutreffend Nicht zutreffend
Erweiterter WinHTTP-Proxy [RO][SENS] netsh winhttp show advproxy Nicht zutreffend Nicht zutreffend
Benutzerproxy [RO][SENS] Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" Abhängig von Desktop und Anwendung [RO][SENS] scutil --proxy
HTTP-Proxy Abhängig von Anwendung Über Umgebungs- oder Anwendungskonfiguration [RO][SENS] networksetup -getwebproxy "Wi-Fi"
HTTPS-Proxy Abhängig von Anwendung Über Umgebungs- oder Anwendungskonfiguration [RO][SENS] networksetup -getsecurewebproxy "Wi-Fi"
PAC-URL Registry beziehungsweise WinHTTP prüfen Abhängig von Desktop und Anwendung [RO][SENS] networksetup -getautoproxyurl "Wi-Fi"
Proxyhostname auflösen [TEST] Resolve-DnsName PROXY [TEST] getent ahosts PROXY [TEST] dscacheutil -q host -a name PROXY
Proxyport prüfen [TEST] Test-NetConnection PROXY -Port PORT [TEST] nc -vz -w 5 PROXY PORT [TEST] nc -vz -w 5 PROXY PORT
Expliziter Proxytest [TEST][SENS] curl.exe -v --proxy http://PROXY:PORT URL [TEST][SENS] curl -v --proxy http://PROXY:PORT URL [TEST][SENS] curl -v --proxy http://PROXY:PORT URL
Proxy umgehen [TEST][SENS] curl.exe -v --noproxy "*" URL [TEST][SENS] curl -v --noproxy "*" URL [TEST][SENS] curl -v --noproxy "*" URL
Dienstumgebung Windows-Dienstkontext getrennt prüfen [RO][PRIV][SENS] sudo systemctl show DIENST --property=Environment Abhängig von LaunchDaemon und Anwendung
Reverse-Proxy-Backend testen [TEST] Test-NetConnection BACKEND -Port PORT [TEST] nc -vz -w 5 BACKEND PORT [TEST] nc -vz -w 5 BACKEND PORT
NGINX-Konfiguration Falls installiert: [RO] nginx -t [RO][PRIV][SENS] sudo nginx -t Falls installiert: [RO][PRIV][SENS] sudo nginx -t
Containerprotokolle [RO][SENS] docker logs --tail 100 CONTAINER [RO][SENS] docker logs --tail 100 CONTAINER [RO][SENS] docker logs --tail 100 CONTAINER

PROXY, PORT, URL, DIENST, BACKEND und CONTAINER müssen durch die Werte des konkreten Störungsfalls ersetzt werden.

35. Dokumentationsvorlage für Proxyfehler 
Störung:
Zeitpunkt:
Zeitzone:
Benutzer:
Client:
Client-IP:
Betriebssystem:
Betroffene Anwendung:
Anwendungsversion:

Ziel-URL:
Zielhostname:
Ziel-IP:
Zielport:
HTTP oder HTTPS:
Fehlermeldung:
HTTP-Statuscode:

Proxyart:
Proxyhostname:
Proxy-IP:
Proxyport:
Konfigurationsquelle:
PAC-URL:
WPAD verwendet:
Umgehungsliste:
Proxy-Authentifizierung:
TLS-Inspection:

WinHTTP-Konfiguration:
Benutzerkonfiguration:
Umgebungsvariablen:
Anwendungseigene Konfiguration:
Gruppenrichtlinie oder MDM:

Proxy-DNS erfolgreich:
Proxyport erreichbar:
Expliziter Proxytest:
Direkter Vergleichstest:
Zertifikatsaussteller:
Proxyprotokolleintrag:

Reverse Proxy beteiligt:
Frontend erreichbar:
Backendhostname:
Backend-IP:
Backendport:
Backendprotokoll:
Backend vom Proxy erreichbar:
Backenddienst aktiv:
Proxy-Fehlerprotokoll:
Backend-Fehlerprotokoll:
Forwarded-Header geprüft:

Paketmitschnitt vorhanden:
Festgestellte Ursache:
Genehmigte Änderung:
Rückfallplan:
Ergebnis der Nachprüfung:
36. Kontrollfragen nach der Diagnose
37. Quellen und weiterführende Dokumentation
3. Netzwerkfehler systematisch analysieren

3.13 VPN- und Tunnelverbindungen analysieren

Ein Virtual Private Network erweitert die lokale Netzwerkumgebung um einen verschlüsselten oder logisch getrennten Tunnel. Eine angezeigte VPN-Verbindung kann erfolgreich aufgebaut sein, obwohl interne Dienste, DNS-Auflösung oder einzelne Netzbereiche weiterhin nicht funktionieren.

Die zentralen Fragen dieser Seite lauten:

Wird der Tunnel vollständig aufgebaut, erhält der Client die richtige Konfiguration und wird der betroffene Datenverkehr tatsächlich durch den vorgesehenen Tunnel geleitet?

1. Sicherheits- und Aktionskennzeichnungen
Kennzeichnung Bedeutung
[RO] Rein lesender Befehl, der normalerweise keine Konfiguration verändert
[TEST] Aktiver Test, der Netzwerkverkehr erzeugt
[PRIV] Administrator- oder Root-Rechte können erforderlich sein
[FILE] Der Befehl schreibt Ausgaben in eine Datei
[SENS] Die Ausgabe kann sensible Informationen enthalten
[CHANGE] Der Befehl verändert eine Konfiguration
[DISRUPT] Der Befehl kann Verbindungen oder Dienste beeinträchtigen

VPN-Ausgaben können Benutzernamen, öffentliche Schlüssel, interne Netze, Serveradressen, Zertifikatsinformationen und Sicherheitsrichtlinien enthalten. Private Schlüssel, Pre-Shared Keys, Passwörter und Sitzungstoken dürfen niemals dokumentiert oder weitergegeben werden.

2. VPN- und Tunnelarten unterscheiden
Art Typische Verwendung
Remote-Access-VPN Einzelne Clients verbinden sich mit einem Unternehmensnetz
Site-to-Site-VPN Zwei oder mehr Netzwerke werden miteinander verbunden
Full Tunnel Grundsätzlich wird der gesamte vorgesehene Datenverkehr durch das VPN geleitet
Split Tunnel Nur definierte Netze oder Anwendungen verwenden den Tunnel
Device Tunnel Verbindung wird im Gerätekontext aufgebaut
User Tunnel Verbindung wird im Benutzerkontext aufgebaut
Always-On-VPN Tunnel wird automatisch oder dauerhaft aufgebaut
Policy-Based VPN Auswahl des Tunnelverkehrs anhand definierter Richtlinien
Route-Based VPN Tunnel wird als routbare virtuelle Schnittstelle behandelt
Application VPN Nur ausgewählte Anwendungen verwenden den Tunnel
Overlay-Netzwerk Virtuelles Netz wird über ein bestehendes Netz gelegt
Zero-Trust-Zugang Zugriff wird zusätzlich anhand von Identität, Gerät und Richtlinien bewertet

Wichtig: Die Anzeige „Verbunden“ bestätigt häufig nur den Tunnelaufbau. Sie beweist nicht, dass die benötigte Anwendung erreichbar ist.

3. Häufige VPN-Protokolle und Transportwege
VPN-Technik Typischer Transport
IKEv2/IPsec UDP 500 und bei NAT-T UDP 4500
IPsec ESP IP-Protokollnummer 50, kein TCP- oder UDP-Port
IPsec AH IP-Protokollnummer 51, kein TCP- oder UDP-Port
L2TP Typischerweise UDP 1701, häufig zusammen mit IPsec
SSTP TCP 443
OpenVPN Häufig UDP oder TCP 1194, aber frei konfigurierbar
WireGuard UDP, Port frei konfigurierbar; häufig wird 51820 verwendet
GRE IP-Protokollnummer 47, kein TCP- oder UDP-Port
TLS-basierte Hersteller-VPNs Häufig TCP 443 oder UDP-basierter Transport
SSH-Tunnel TCP, häufig Port 22, aber konfigurierbar

Die tatsächlichen Ports und Protokolle müssen immer aus der produktiven VPN-Konfiguration entnommen werden.

Nicht verwechseln:

GRE = IP-Protokoll 47
ESP = IP-Protokoll 50
AH  = IP-Protokoll 51

Diese Zahlen sind keine Portnummern.

4. Die Diagnose in Phasen aufteilen
Phase Zentrale Frage
1. Basisverbindung Besitzt der Client eine funktionierende Verbindung zum Internet oder Unternehmensnetz?
2. Serverauflösung Kann der VPN-Gatewayname korrekt aufgelöst werden?
3. Transport Ist der benötigte Port beziehungsweise das IP-Protokoll erreichbar?
4. Authentifizierung Werden Benutzer, Gerät, Zertifikat und MFA akzeptiert?
5. Tunnelerstellung Wird eine virtuelle Schnittstelle beziehungsweise Security Association aufgebaut?
6. Adressierung Erhält der Client die vorgesehene Tunneladresse?
7. Routing Werden die benötigten Zielnetze in den Tunnel geleitet?
8. DNS Werden interne Namen über die vorgesehenen Resolver aufgelöst?
9. Richtlinie Darf Benutzer und Gerät auf das Ziel zugreifen?
10. Anwendung Antwortet der eigentliche Dienst?
11. Stabilität Bleibt der Tunnel verbunden und leistungsfähig?

Durch diese Trennung wird verhindert, dass ein Anwendungsfehler fälschlich als VPN-Aufbaufehler behandelt wird.

5. Störungsumfang zuerst bestimmen

Vor den technischen Prüfungen sind folgende Fragen zu beantworten:

Wichtiger Vergleichstest:

Gleiches Gerät + anderes Zugangsnetz
Gleiches Benutzerkonto + anderes Gerät
Anderer Benutzer + gleiches Gerät
Funktionierender und fehlerhafter Client im Vergleich

Dabei müssen Datenschutz, Kontosicherheit und betriebliche Berechtigungen eingehalten werden.

6. Basisverbindung vor dem VPN prüfen

Ein VPN benötigt zunächst eine funktionierende Verbindung zum VPN-Gateway.

Aufgabe Windows Linux macOS
Schnittstellen [RO] Get-NetAdapter [RO] ip -br link [RO] ifconfig
IP-Konfiguration [RO] Get-NetIPConfiguration [RO] ip -br address [RO] ifconfig
Standardroute [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" [RO] ip route show default [RO] route -n get default
DNS-Konfiguration [RO] Get-DnsClientServerAddress [RO] resolvectl status [RO][SENS] scutil --dns
Internetziel testen [TEST] Test-NetConnection example.com -Port 443 [TEST] curl -I https://example.com/ [TEST] curl -I https://example.com/

Vor dem Verbindungsversuch dokumentieren:

Ein Captive Portal in einem Hotel-, Bahn- oder Gastnetz kann den VPN-Aufbau verhindern, obwohl eine WLAN-Verbindung angezeigt wird.

7. VPN-Gateway auflösen und Transportweg prüfen

Namensauflösung:

Windows:

[TEST] Resolve-DnsName vpn.example.net

Linux:

[TEST] getent ahosts vpn.example.net

macOS:

[TEST] dscacheutil -q host -a name vpn.example.net

Route zum Gateway prüfen:

Windows:

[RO] Find-NetRoute -RemoteIPAddress VPN_GATEWAY_IP

Linux:

[RO] ip route get VPN_GATEWAY_IP

macOS:

[RO] route -n get VPN_GATEWAY_IP

TCP-basierten Gatewayport prüfen:

Windows:

[TEST] Test-NetConnection vpn.example.net -Port 443 -InformationLevel Detailed

Linux und macOS:

[TEST] nc -vz -w 5 vpn.example.net 443

Ein erfolgreicher TCP-Porttest gilt nur für TCP. Er prüft keine UDP-basierten IKEv2-, OpenVPN- oder WireGuard-Verbindungen.

8. Windows-VPN-Profile und Status prüfen

VPN-Profile des aktuellen Benutzers:

[RO][SENS] Get-VpnConnection

Geräteweite VPN-Profile:

[RO][PRIV][SENS] Get-VpnConnection -AllUserConnection

Ausführliche Darstellung:

[RO][SENS] Get-VpnConnection |
    Format-List *

Klassische Anzeige aktiver RAS-Verbindungen:

[RO] rasdial

Netzwerkadapter einschließlich virtueller Adapter:

[RO] Get-NetAdapter -IncludeHidden |
    Sort-Object Status, Name |
    Format-Table Name, InterfaceDescription, Status, LinkSpeed

IP-Konfiguration aller Schnittstellen:

[RO][SENS] Get-NetIPConfiguration -All

Zu kontrollieren sind:

Get-VpnConnection zeigt nur VPN-Profile, die über die entsprechenden Windows-VPN-Komponenten verwaltet werden. Herstellerclients können eigene Konfigurationen und Diagnosewerkzeuge verwenden.

9. Windows-Routen vor und nach dem VPN vergleichen

Routingtabelle:

[RO] Get-NetRoute |
    Sort-Object AddressFamily, DestinationPrefix, RouteMetric |
    Format-Table AddressFamily, DestinationPrefix, NextHop,
                 InterfaceAlias, RouteMetric

IPv4-Routingtabelle klassisch:

[RO] route print -4

IPv6-Routingtabelle:

[RO] route print -6

Route zu einem internen Ziel bestimmen:

[RO] Find-NetRoute -RemoteIPAddress 10.20.30.40

Besonders relevant:

DestinationPrefix
NextHop
InterfaceAlias
RouteMetric
InterfaceMetric

Vergleichsablauf:

  1. Routingtabelle ohne VPN erfassen.
  2. VPN verbinden.
  3. Routingtabelle erneut erfassen.
  4. Neue und veränderte Routen vergleichen.
  5. Route zum betroffenen internen Ziel bestimmen.
  6. Prüfen, ob die Route über den VPN-Adapter führt.

Eine vorhandene Route beweist noch nicht, dass die VPN-Gegenstelle den Verkehr erlaubt oder korrekt zurückleitet.

10. Windows-VPN-Ereignisprotokolle prüfen

Vorhandene VPN- und RAS-Protokolle ermitteln:

[RO][PRIV][SENS] Get-WinEvent -ListLog *Ras* |
    Select-Object LogName, IsEnabled, RecordCount

[RO][PRIV][SENS] Get-WinEvent -ListLog *VPN* |
    Select-Object LogName, IsEnabled, RecordCount

RasClient-Protokoll abfragen, sofern vorhanden:

[RO][PRIV][SENS] Get-WinEvent `
    -LogName "Microsoft-Windows-RasClient/Operational" `
    -MaxEvents 100

Zeitlich begrenzen:

[RO][PRIV][SENS] Get-WinEvent `
    -FilterHashtable @{
        LogName   = "Microsoft-Windows-RasClient/Operational"
        StartTime = (Get-Date).AddMinutes(-30)
    }

Zusätzlich können abhängig vom VPN-Typ Protokolle zu folgenden Komponenten relevant sein:

Nicht jede Umgebung aktiviert alle Diagnoseprotokolle standardmäßig.

11. Windows-IPsec-Sicherheitszuordnungen prüfen

Bei IPsec-basierten Verbindungen können Security Associations wichtige Informationen liefern.

Main-Mode-Sicherheitszuordnungen:

[RO][PRIV][SENS] Get-NetIPsecMainModeSA

Quick-Mode-Sicherheitszuordnungen:

[RO][PRIV][SENS] Get-NetIPsecQuickModeSA

Main-Mode-Regeln:

[RO][PRIV][SENS] Get-NetIPsecMainModeRule

Verbindungs-Sicherheitsregeln:

[RO][PRIV][SENS] Get-NetIPsecRule

Zu prüfen sind:

Leere Ausgaben können bedeuten, dass keine entsprechende aktive IPsec-Sicherheitszuordnung existiert oder dass der eingesetzte VPN-Client nicht über diese Windows-Komponenten arbeitet.

12. Linux: Tunnel, Verbindungen und Schnittstellen prüfen

Aktive NetworkManager-Verbindungen:

[RO][SENS] nmcli connection show --active

Gerätestatus:

[RO] nmcli device status

Alle Schnittstellen:

[RO] ip -br link

IP-Adressen:

[RO][SENS] ip -br address

Routingtabelle:

[RO] ip route show

IPv6-Routingtabelle:

[RO] ip -6 route show

Policy-Routingregeln:

[RO] ip rule show

Alle Routingtabellen:

[RO][SENS] ip route show table all

Mögliche Tunnelschnittstellen tragen abhängig von Technik und Hersteller Namen wie:

tun0
tap0
wg0
ppp0
ipsec0
Herstellerspezifischer Name

Der Name allein bestätigt nicht, dass der Tunnel vollständig funktionsfähig ist.

13. Linux-Protokolle prüfen

NetworkManager-Protokolle:

[RO][PRIV][SENS] sudo journalctl -u NetworkManager --since "-30 minutes"

Aktuelle Kernelmeldungen zu Netzwerkproblemen:

[RO][PRIV][SENS] sudo journalctl -k --since "-30 minutes"

Vorhandene VPN-Dienste suchen:

[RO] systemctl list-units --type=service |
    grep -Ei 'openvpn|wireguard|strongswan|ipsec|vpn'

Protokoll eines konkret ermittelten Dienstes:

[RO][PRIV][SENS] sudo journalctl -u TATSAECHLICHER_DIENSTNAME \
    --since "-30 minutes"

Der Unit-Name muss vorher ermittelt werden. Namen wie openvpn.service oder openvpn-client@NAME.service dürfen nicht ohne Prüfung angenommen werden.

14. macOS: VPN-Status und virtuelle Schnittstellen prüfen

VPN-Konfigurationen anzeigen:

[RO][SENS] scutil --nc list

Status einer bekannten VPN-Konfiguration:

[RO][SENS] scutil --nc status "VPN-DIENSTNAME"

Alle Schnittstellen anzeigen:

[RO][SENS] ifconfig

Routingtabelle:

[RO] netstat -rn

Standardroute:

[RO] route -n get default

Route zu einem internen Ziel:

[RO] route -n get 10.20.30.40

DNS-Konfiguration:

[RO][SENS] scutil --dns

Proxykonfiguration:

[RO][SENS] scutil --proxy

Viele Hersteller-VPN-Clients verwalten Tunnel und Filter über System Extensions oder Network Extensions. Ihre vollständige Konfiguration ist nicht zwingend über networksetup oder scutil --nc sichtbar.

15. WireGuard-Verbindungen prüfen

Die folgenden Befehle gelten nur, wenn WireGuard eingesetzt wird und die Werkzeuge installiert sind.

WireGuard-Status:

[RO][PRIV][SENS] sudo wg show

Typische Angaben:

interface
public key
listening port
peer
endpoint
allowed ips
latest handshake
transfer
persistent keepalive

Bestimmte Schnittstelle:

[RO][PRIV][SENS] sudo wg show wg0

Routing und Adresse der Schnittstelle:

[RO] ip address show dev wg0

[RO] ip route show

Besonders relevant:

Feld Diagnose
latest handshake Fand kürzlich ein Handshake statt?
transfer Steigen gesendete und empfangene Datenmengen?
endpoint Wird die erwartete Gegenstellenadresse verwendet?
allowed ips Welche Zielnetze werden diesem Peer zugeordnet?
persistent keepalive Ist bei NAT-Szenarien ein Keepalive konfiguriert?

Typische Muster:

Beobachtung Mögliche Bedeutung
Kein aktueller Handshake Endpoint, UDP-Port, Schlüssel, Firewall oder Gegenstelle prüfen
Gesendet steigt, empfangen nicht Rückweg, Peer-Konfiguration oder Firewall prüfen
Handshake aktuell, internes Ziel nicht erreichbar Routen, AllowedIPs, Forwarding und Zielnetz prüfen
Nur nach Datenverkehr Handshake sichtbar Kann je nach Nutzung normal sein
Tunnel funktioniert nur kurz NAT-Zustand, Keepalive oder Netzwechsel prüfen

Konfigurationsausgaben, die private oder vorab geteilte Schlüssel enthalten könnten, dürfen nicht veröffentlicht werden.

16. OpenVPN-Verbindungen prüfen

Die folgenden Prüfungen gelten nur, wenn OpenVPN eingesetzt wird.

Installierte Version:

[RO] openvpn --version

Laufenden Prozess suchen:

[RO][SENS] ps aux | grep '[o]penvpn'

Ermittelte systemd-Dienste prüfen:

[RO] systemctl list-units --type=service |
    grep -i openvpn

Protokoll eines konkret ermittelten Dienstes:

[RO][PRIV][SENS] sudo journalctl -u TATSAECHLICHER_OPENVPN_DIENST \
    --since "-30 minutes"

Typische Meldungsgruppen:

Meldung Mögliche Bedeutung
TLS handshake failed Zertifikat, Uhrzeit, Transport oder Gegenstelle prüfen
AUTH_FAILED Benutzeranmeldung, MFA oder Kontostatus prüfen
Cannot resolve host address DNS-Auflösung des Gateways fehlgeschlagen
Connection timed out Transportweg, Firewall oder Gateway prüfen
Inactivity timeout Kein ausreichender Datenverkehr oder Gegenstelle nicht erreichbar
Route addition failed Rechte, Routenkonflikt oder Plattformproblem
TUN/TAP device error Virtueller Adapter oder Berechtigung fehlerhaft
Initialization Sequence Completed Tunnelinitialisierung wurde abgeschlossen

Die exakte Formulierung hängt von OpenVPN-Version, Plattform und Verwaltungslösung ab.

17. VPN-Adressierung prüfen

Nach erfolgreichem Aufbau erhält der Client abhängig vom VPN eine Adresse auf einer virtuellen Schnittstelle.

Windows:

[RO][SENS] Get-NetIPAddress |
    Sort-Object InterfaceAlias, AddressFamily |
    Format-Table InterfaceAlias, AddressFamily, IPAddress,
                 PrefixLength, AddressState

Linux:

[RO][SENS] ip -br address

macOS:

[RO][SENS] ifconfig

Zu kontrollieren sind:

18. Überschneidende lokale und entfernte Netze erkennen

Ein häufiges Remote-Access-Problem entsteht, wenn das lokale Netz denselben Adressbereich wie das entfernte Unternehmensnetz verwendet.

Beispiel:

Lokales Heimnetz:      192.168.1.0/24
Entferntes Firmennetz: 192.168.1.0/24

Der Client kann dann nicht allein anhand der Zieladresse eindeutig entscheiden, ob das Ziel lokal oder über das VPN erreichbar ist.

Route zum Ziel prüfen:

Windows:

[RO] Find-NetRoute -RemoteIPAddress 192.168.1.50

Linux:

[RO] ip route get 192.168.1.50

macOS:

[RO] route -n get 192.168.1.50

Mögliche Lösungen im Netzdesign:

Eine manuell gesetzte Einzelroute ist höchstens eine kontrollierte Zwischenlösung und kann andere lokale Ziele unerreichbar machen.

19. Split Tunnel und Full Tunnel prüfen

Full Tunnel:

Interne Ziele → VPN
Internetverkehr → VPN

Split Tunnel:

Interne Ziele → VPN
Internetverkehr → lokale Verbindung

Windows-Profil prüfen:

[RO][SENS] Get-VpnConnection |
    Select-Object Name, ConnectionStatus, SplitTunneling,
                  TunnelType, ServerAddress

Standardrouten unter Windows:

[RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" |
    Format-Table InterfaceAlias, NextHop, RouteMetric

Linux:

[RO] ip route show
[RO] ip rule show

macOS:

[RO] netstat -rn

Zu prüfen sind:

Split Tunneling ist eine Sicherheits- und Architekturentscheidung und darf nicht eigenmächtig aktiviert oder deaktiviert werden.

20. Route zu einem betroffenen Ziel eindeutig bestimmen

Windows:

[RO] Find-NetRoute -RemoteIPAddress 10.20.30.40

Linux:

[RO] ip route get 10.20.30.40

macOS:

[RO] route -n get 10.20.30.40

Zu dokumentieren sind:

Zieladresse
verwendete Schnittstelle
nächster Hop
Quelladresse
Routenpräfix
Metrik

Typische Diagnose:

Tunnel ist verbunden
↓
Route zum Ziel zeigt auf WLAN statt VPN
↓
Benötigte VPN-Route fehlt oder wird durch spezifischere Route verdrängt

Die längste passende Präfixroute ist grundsätzlich besonders relevant. Eine spezifischere Route kann eine weniger spezifische VPN-Standardroute übersteuern.

21. Interne DNS-Auflösung über VPN prüfen

Windows-DNS-Server pro Schnittstelle:

[RO][SENS] Get-DnsClientServerAddress |
    Format-Table InterfaceAlias, AddressFamily, ServerAddresses

Windows-Suffixe:

[RO] Get-DnsClient |
    Select-Object InterfaceAlias, ConnectionSpecificSuffix,
                  RegisterThisConnectionsAddress

Linux:

[RO][SENS] resolvectl status

macOS:

[RO][SENS] scutil --dns

Internen Namen über den vorgesehenen DNS-Server prüfen:

Windows:

[TEST] Resolve-DnsName server.example.internal `
    -Server 10.20.0.53

Linux und macOS:

[TEST] dig @10.20.0.53 server.example.internal A

IP-Adresse und Hostname getrennt testen:

Zugriff über interne IP funktioniert
Zugriff über internen Hostnamen funktioniert nicht

Das deutet eher auf DNS, Suchsuffixe oder Namensrichtlinien als auf einen allgemeinen Tunnelfehler hin.

22. Split DNS und DNS-Leaks beurteilen

Bei Split DNS sollen bestimmte interne Namensräume über interne DNS-Server und andere Namen über lokale oder öffentliche Resolver aufgelöst werden.

Beispiel:

*.example.internal → interner DNS-Server über VPN
andere Namen        → lokaler oder definierter externer DNS-Server

Mögliche Fehler:

Vergleichstest:

[TEST] dig server.example.internal

[TEST] dig @10.20.0.53 server.example.internal

Unterschiedliche Antworten zeigen, dass Resolverauswahl, Cache oder Split-DNS-Regeln weiter untersucht werden müssen.

23. Authentifizierung, Zertifikate und Uhrzeit prüfen

Mögliche Authentifizierungsbestandteile:

Systemzeit prüfen:

Betriebssystem Befehl
Windows [RO] Get-Date -Format o
Linux [RO] date --iso-8601=seconds
macOS [RO] date "+%Y-%m-%dT%H:%M:%S%z"

Zeitsynchronisation:

Windows:

[RO] w32tm /query /status

Linux:

[RO] timedatectl status

macOS:

[RO] systemsetup -getusingnetworktime

Für den macOS-Befehl können erhöhte Rechte erforderlich sein:

[RO][PRIV] sudo systemsetup -getusingnetworktime

Zu prüfen sind:

Private Schlüssel dürfen niemals mit Diagnoseausgaben exportiert werden.

24. MTU- und Fragmentierungsprobleme erkennen

VPN-Protokolle fügen zusätzliche Header hinzu. Dadurch sinkt die nutzbare Paketgröße innerhalb des Tunnels.

Typische Symptome:

Windows – IPv4-Paket mit gesetztem Don't-Fragment-Bit:

[TEST] ping -4 -f -l 1400 10.20.30.40

Linux:

[TEST] ping -4 -M do -s 1400 10.20.30.40

macOS:

[TEST] ping -D -s 1400 10.20.30.40

Die angegebene Nutzdatenlänge ist nicht identisch mit der gesamten IP-Paketgröße. Bei IPv4 kommen üblicherweise mindestens IP- und ICMP-Header hinzu.

Schnittstellen-MTU anzeigen:

Windows:

[RO] Get-NetIPInterface |
    Format-Table InterfaceAlias, AddressFamily, NlMtu, InterfaceMetric

Linux:

[RO] ip link show

macOS:

[RO] ifconfig

Die MTU darf nicht ohne Messung und Freigabe verändert werden. Eine zu kleine MTU kann Leistung reduzieren; eine zu große MTU kann Fragmentierungs- oder Black-Hole-Probleme verursachen.

25. Path-MTU-Discovery und ICMP berücksichtigen

Path-MTU-Discovery benötigt bestimmte ICMP- beziehungsweise ICMPv6-Rückmeldungen.

Wichtige Meldungen:

Werden diese Meldungen blockiert, kann ein Path-MTU-Black-Hole entstehen:

Kleine Pakete funktionieren
↓
Großes Paket überschreitet Pfad-MTU
↓
Router kann oder darf nicht fragmentieren
↓
ICMP-Fehlermeldung wird blockiert
↓
Sender erfährt die zulässige Größe nicht
↓
Übertragung bleibt hängen

Paketmitschnittfilter:

icmp
icmpv6

ICMP und ICMPv6 dürfen nicht pauschal als unnötig betrachtet oder vollständig blockiert werden.

26. Lokale Firewall und VPN-Kill-Switch prüfen

Ein VPN-Client kann zusätzliche Filterregeln installieren, um Verkehr außerhalb des Tunnels zu verhindern.

Mögliche Funktionen:

Typische Fehlerbilder:

Zu prüfen sind:

Kill-Switch- oder Sicherheitsfunktionen dürfen nicht ohne Freigabe deaktiviert werden.

27. Lokale Netzwerkzugriffe während des VPNs prüfen

Ein VPN kann Zugriffe auf lokale Netze absichtlich unterbinden.

Betroffene Beispiele:

Route zum lokalen Ziel prüfen:

Windows:

[RO] Find-NetRoute -RemoteIPAddress 192.168.1.50

Linux:

[RO] ip route get 192.168.1.50

macOS:

[RO] route -n get 192.168.1.50

Mögliche Ursachen:

Lokalen LAN-Zugriff während des VPNs zu erlauben ist eine Sicherheitsentscheidung und keine rein technische Komforteinstellung.

28. VPN über restriktive Netze prüfen

Hotels, Gast-WLANs, Mobilfunkanbieter und Unternehmensnetze können bestimmte VPN-Protokolle einschränken.

Vergleichstest:

VPN über Firmennetz fehlerhaft
VPN über Mobilfunk erfolgreich

Das deutet auf einen Unterschied im Zugangsnetz hin, beispielsweise:

Öffentliche Quelladresse vergleichen:

Windows:

[TEST][SENS] Invoke-RestMethod -Uri "https://api.ipify.org"

Linux und macOS:

[TEST][SENS] curl -4 https://api.ipify.org

Die Nutzung eines externen Dienstes muss durch die betrieblichen Richtlinien erlaubt sein.

29. Stabilität und wiederkehrende Abbrüche untersuchen

Bei sporadischen Abbrüchen dokumentieren:

Kontinuierlicher Test zu einem internen Ziel:

Windows:

[TEST] ping -t 10.20.30.40

Linux:

[TEST] ping 10.20.30.40

macOS:

[TEST] ping 10.20.30.40

Zusätzlich sollte ein Ziel außerhalb des VPNs getestet werden, um zwischen Verlust der Basisverbindung und Verlust des Tunnels zu unterscheiden.

Windows – zeitlich begrenzte PowerShell-Ausgabe:

[TEST] Test-Connection 10.20.30.40 -Count 20

Ping kann durch Richtlinien blockiert sein. Ein fehlender Ping ist deshalb kein alleiniger Nachweis eines Tunnelausfalls.

30. Anwendung statt nur Ping testen

Nach Routing- und DNS-Prüfung muss der benötigte Dienst getestet werden.

Dienst Beispiel
HTTPS [TEST] curl -v https://service.example.internal/
TCP-Port [TEST] Test-NetConnection HOST -Port PORT
SSH [TEST] ssh -vvv user@HOST
DNS [TEST] Resolve-DnsName HOST -Server DNS_SERVER
SMB Unter Windows: [TEST] Test-NetConnection HOST -Port 445
RDP Unter Windows: [TEST] Test-NetConnection HOST -Port 3389

Linux und macOS – TCP-Port:

[TEST] nc -vz -w 5 HOST PORT

Reihenfolge:

Tunnelstatus
→ Route
→ DNS
→ Port
→ Anwendungsprotokoll
→ Authentifizierung

Ein erfolgreicher VPN-Aufbau beweist nicht, dass eine Zugriffsrichtlinie den jeweiligen Anwendungsdienst erlaubt.

31. Paketmitschnitt für VPN-Fehler erstellen

Es können zwei Datenebenen betrachtet werden:

Äußerer Verkehr:
Client ↔ VPN-Gateway

Innerer Verkehr:
Tunneladresse ↔ internes Ziel

Linux – äußerer Verkehr zum VPN-Gateway:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i PHYSISCHE_SCHNITTSTELLE -nn \
    'host VPN_GATEWAY_IP' \
    -w vpn-outer.pcap

Linux – innerer Verkehr auf einer Tunnelschnittstelle:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i TUNNEL_INTERFACE -nn \
    'host INTERNES_ZIEL' \
    -w vpn-inner.pcap

macOS:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \
    'host VPN_GATEWAY_IP' \
    -w vpn-test.pcap

Windows – Schnittstellen mit Dumpcap anzeigen:

[RO] dumpcap -D

Windows – Mitschnitt:

[TEST][PRIV][FILE][SENS] dumpcap -i 1 `
    -f "host VPN_GATEWAY_IP" `
    -w vpn-test.pcapng

Die Schnittstellen müssen vorher eindeutig ermittelt werden.

32. Wireshark-Filter für VPN-Diagnosen
Aufgabe Anzeigefilter
IKE isakmp
UDP 500 udp.port == 500
NAT-T über UDP 4500 udp.port == 4500
ESP esp
AH ah
OpenVPN auf Standardport `udp.port == 1194
WireGuard auf häufigem Port udp.port == 51820
SSTP-Verkehr tcp.port == 443
DNS dns
ICMP icmp
ICMPv6 icmpv6
TCP-Reset tcp.flags.reset == 1
Wiederholte TCP-Pakete tcp.analysis.retransmission

Die tatsächlichen Ports können abweichen und müssen aus der Konfiguration übernommen werden.

Verschlüsselter VPN-Verkehr zeigt im äußeren Mitschnitt normalerweise nicht die ursprünglichen Anwendungsdaten.

33. Paketmuster interpretieren
Beobachtung Mögliche Interpretation
Keine Pakete zum VPN-Gateway DNS, Route, Anwendung oder lokaler Filter prüfen
Ausgehende Pakete, keine Antwort Gateway, Firewall, Provider, NAT oder Rückweg prüfen
IKE-Austausch beginnt und endet Authentifizierung, Richtlinie oder Verfahren prüfen
Tunnelhandshake erfolgreich Transport und kryptografischer Aufbau funktionieren grundsätzlich
Tunnelverkehr wird gesendet, nichts empfangen Gegenstelle, Rückroute oder Filter prüfen
Inneres Paket verlässt Tunnel, keine Antwort Zielnetz, Zielhost oder serverseitige Route prüfen
Antworten kommen im Tunnel an, Anwendung erhält sie nicht Lokale Firewall, Route oder Anwendung prüfen
Kleine Pakete funktionieren, große nicht MTU und Path-MTU-Discovery prüfen
Häufige Neuverbindungen Basisnetz, Rekey, NAT-Timeout oder Clientstabilität prüfen

Ein einseitiger Paketmitschnitt zeigt nur den jeweiligen Messpunkt. Bei komplexen Fehlern sollten Client, VPN-Gateway und internes Ziel zeitgleich betrachtet werden.

34. Typische Fehlerbilder systematisch eingrenzen

Fall A – VPN-Gatewayname wird nicht aufgelöst

Prüfen:

Fall B – Authentifizierung schlägt fehl

Prüfen:

Fall C – VPN verbunden, keine internen Ziele erreichbar

Prüfen:

Fall D – Interne IP funktioniert, Hostname nicht

Prüfen:

Fall E – Nur ein internes Netz ist nicht erreichbar

Prüfen:

Fall F – VPN funktioniert über Mobilfunk, aber nicht über WLAN

Prüfen:

Fall G – Verbindung bricht bei großen Übertragungen ab

Prüfen:

Fall H – Nach dem Trennen funktioniert das Internet nicht

Prüfen:

35. VPN-Serverseite mit einbeziehen

Die Clientdiagnose allein reicht nicht immer aus. Auf der Serverseite sind zu prüfen:

Client- und Serverprotokolle müssen anhand von Benutzer, Tunneladresse und Zeitstempel zugeordnet werden.

36. Keine vorschnellen VPN-Änderungen durchführen

Nicht unkontrolliert:

Sicherer Ablauf:

  1. Istzustand dokumentieren.
  2. Client- und Profilversion feststellen.
  3. Fehler reproduzieren.
  4. Basisnetz und Gatewaytransport prüfen.
  5. Tunnelstatus, Adresse, Route und DNS prüfen.
  6. Client- und Serverprotokolle vergleichen.
  7. Ursache nachweisen.
  8. Änderung genehmigen lassen.
  9. Kleinste erforderliche Korrektur durchführen.
  10. Tunnelaufbau und Zielanwendung erneut testen.
  11. Rückfallmöglichkeit und Ergebnis dokumentieren.
37. Systematischer Diagnoseablauf
Schritt Prüfung Leitfrage
1 Störungsumfang bestimmen Benutzer, Gerät, Standort oder allgemeine Störung?
2 Basisverbindung prüfen Funktioniert das Netz ohne VPN?
3 Captive Portal ausschließen Ist der Internetzugang vollständig freigeschaltet?
4 Gateway auflösen Wird die richtige VPN-Adresse verwendet?
5 Route zum Gateway prüfen Läuft der äußere Verkehr über die Basisschnittstelle?
6 Transport prüfen Erreichen benötigte Ports und Protokolle das Gateway?
7 Authentifizierung prüfen Werden Konto, MFA und Zertifikat akzeptiert?
8 Tunnelstatus prüfen Wurde der Tunnel tatsächlich aufgebaut?
9 Tunneladresse prüfen Hat der Client die vorgesehene Adresse erhalten?
10 Routen vergleichen Werden die Zielnetze durch den Tunnel geleitet?
11 Netzüberlappungen prüfen Konfligiert das lokale Netz mit dem Zielnetz?
12 DNS prüfen Werden interne Namen über richtige Resolver aufgelöst?
13 Zielport testen Ist der benötigte Dienst transportseitig erreichbar?
14 Anwendung testen Funktioniert das eigentliche Protokoll?
15 MTU prüfen Scheitern nur größere Pakete oder Übertragungen?
16 Stabilität beobachten Wann und unter welchen Bedingungen bricht der Tunnel ab?
17 Protokolle vergleichen Welche Seite beendet oder verweigert die Verbindung?
18 Paketmitschnitt erstellen Wo endet der erfolgreiche Datenfluss?
19 Minimale Änderung planen Welche konkrete Korrektur stellt den Sollzustand her?
20 Nachprüfung Funktionieren Tunnel, DNS, Routing und Anwendung?
38. Kompakte Befehlstabelle
Aufgabe Windows Linux macOS
VPN-Profile [RO][SENS] Get-VpnConnection [RO][SENS] nmcli connection show [RO][SENS] scutil --nc list
Geräteweite Profile [RO][PRIV][SENS] Get-VpnConnection -AllUserConnection Abhängig vom VPN-Client Abhängig von MDM und VPN-Client
Aktiver VPN-Status [RO] rasdial [RO][SENS] nmcli connection show --active [RO][SENS] scutil --nc status "VPN-NAME"
Schnittstellen [RO] Get-NetAdapter -IncludeHidden [RO] ip -br link [RO] ifconfig
IP-Adressen [RO][SENS] Get-NetIPAddress [RO][SENS] ip -br address [RO][SENS] ifconfig
Routingtabelle [RO] Get-NetRoute [RO] ip route show [RO] netstat -rn
Route zum Ziel [RO] Find-NetRoute -RemoteIPAddress IP [RO] ip route get IP [RO] route -n get IP
DNS-Konfiguration [RO][SENS] Get-DnsClientServerAddress [RO][SENS] resolvectl status [RO][SENS] scutil --dns
Gateway auflösen [TEST] Resolve-DnsName VPN_HOST [TEST] getent ahosts VPN_HOST [TEST] dscacheutil -q host -a name VPN_HOST
TCP-Gatewayport [TEST] Test-NetConnection VPN_HOST -Port PORT [TEST] nc -vz -w 5 VPN_HOST PORT [TEST] nc -vz -w 5 VPN_HOST PORT
Internen Port testen [TEST] Test-NetConnection INTERNER_HOST -Port PORT [TEST] nc -vz -w 5 INTERNER_HOST PORT [TEST] nc -vz -w 5 INTERNER_HOST PORT
MTU anzeigen [RO] Get-NetIPInterface [RO] ip link show [RO] ifconfig
DF-Test [TEST] ping -4 -f -l 1400 IP [TEST] ping -4 -M do -s 1400 IP [TEST] ping -D -s 1400 IP
WireGuard Falls installiert: [RO][PRIV][SENS] wg show [RO][PRIV][SENS] sudo wg show Falls installiert: [RO][PRIV][SENS] sudo wg show
NetworkManager-Protokoll Nicht zutreffend [RO][PRIV][SENS] sudo journalctl -u NetworkManager --since "-30 minutes" Nicht zutreffend
RAS-Protokoll [RO][PRIV][SENS] Get-WinEvent -LogName "Microsoft-Windows-RasClient/Operational" Nicht zutreffend Nicht zutreffend

VPN-NAME, IP, VPN_HOST, PORT und INTERNER_HOST müssen durch die Werte des konkreten Störungsfalls ersetzt werden.

39. Dokumentationsvorlage für VPN-Fehler 
Störung:
Zeitpunkt:
Zeitzone:
Benutzer:
Gerät:
Betriebssystem:
VPN-Client:
VPN-Clientversion:
VPN-Profil:
VPN-Technik:

Zugangsnetz:
Zugangsart: LAN / WLAN / Mobilfunk
Lokale IP-Adresse:
Standardgateway:
Öffentliche IP-Adresse:
Captive Portal ausgeschlossen:
Proxy vorhanden:

VPN-Gatewayname:
Aufgelöste Gatewayadresse:
Verwendete Adressfamilie:
Gatewayport beziehungsweise IP-Protokoll:
Route zum Gateway:
Transporttest:
Authentifizierungsverfahren:
MFA:
Zertifikat geprüft:
Systemzeit geprüft:

Tunnelstatus:
Tunneladresse:
Virtuelle Schnittstelle:
Split Tunnel oder Full Tunnel:
Verteilte IPv4-Routen:
Verteilte IPv6-Routen:
Route zum betroffenen Ziel:
Lokale Netzüberlappung:
VPN-DNS-Server:
DNS-Suffixe:
Interne Namensauflösung:

Betroffenes Ziel:
Ziel-IP:
Zielport:
Transportprotokoll:
Porttest:
Anwendungstest:
MTU-Test:
Paketverlust:
Abbruchzeitpunkt:

Clientprotokoll:
Gatewayprotokoll:
Serverseitige Richtlinie:
Rückroute zum VPN-Adresspool:
Paketmitschnitt vorhanden:

Vergleich über anderes Zugangsnetz:
Vergleich mit anderem Benutzer:
Vergleich mit anderem Gerät:
Festgestellte Ursache:
Genehmigte Änderung:
Rückfallplan:
Ergebnis der Nachprüfung:
40. Kontrollfragen nach der Diagnose
41. Quellen und weiterführende Dokumentation
3. Netzwerkfehler systematisch analysieren

3.14 WLAN- und Funkverbindungsfehler analysieren

Eine WLAN-Verbindung besteht nicht nur aus „verbunden“ oder „nicht verbunden“. Zwischen Client und Anwendung liegen Funkübertragung, Authentifizierung, Zuordnung zu einem Access Point, VLAN-Zuweisung, IP-Konfiguration, Routing, DNS und der eigentliche Netzwerkdienst.

Die zentralen Fragen dieser Seite lauten:

Kann der Client das gewünschte WLAN zuverlässig empfangen, sich korrekt authentifizieren und anschließend über das zugewiesene Netzwerk störungsfrei kommunizieren?

1. Sicherheits- und Aktionskennzeichnungen
Kennzeichnung Bedeutung
[RO] Rein lesender Befehl, der normalerweise keine Konfiguration verändert
[TEST] Aktiver Test, der Funk- oder Netzwerkverkehr erzeugt
[PRIV] Administrator- oder Root-Rechte können erforderlich sein
[FILE] Der Befehl schreibt Ausgaben in eine Datei
[SENS] Die Ausgabe kann sensible Informationen enthalten
[CHANGE] Der Befehl verändert eine Konfiguration
[DISRUPT] Der Befehl kann eine Verbindung oder Funkversorgung beeinträchtigen

WLAN-Diagnosen können SSIDs, BSSIDs, MAC-Adressen, Standorte, Benutzernamen, interne Netze und Authentifizierungsinformationen enthalten. Kennwörter und private Schlüssel dürfen niemals exportiert oder dokumentiert werden.

2. WLAN-Fehler in Schichten aufteilen
Ebene Zentrale Frage
Hardware Ist der WLAN-Adapter vorhanden und betriebsbereit?
Funk Ist das gewünschte WLAN mit ausreichender Qualität empfangbar?
802.11-Verbindung Kann sich der Client mit dem Access Point verbinden?
Authentifizierung Werden Kennwort, Zertifikat oder 802.1X-Anmeldung akzeptiert?
Netzwerkzuweisung Erhält der Client das richtige VLAN und die richtige IP-Konfiguration?
Routing Ist das Standardgateway erreichbar?
DNS Funktioniert die Namensauflösung?
Internetzugang Ist ein externer Zugriff möglich?
Anwendung Funktioniert der tatsächlich benötigte Dienst?
Stabilität Bleibt die Verbindung bei Bewegung und Last erhalten?

Grundregel:

Mit WLAN verbunden
≠
gültige IP-Konfiguration
≠
Internetzugang
≠
Anwendung funktioniert
3. Wichtige WLAN-Begriffe unterscheiden
Begriff Bedeutung
SSID Sichtbarer beziehungsweise konfigurierter WLAN-Netzwerkname
BSSID Kennung einer konkreten Funkzelle, üblicherweise eine MAC-Adresse
Access Point Stellt die WLAN-Funkzelle bereit
Band Frequenzbereich, beispielsweise 2,4 GHz, 5 GHz oder 6 GHz
Kanal Genutzter Teil des Frequenzbereichs
Kanalbreite Beispielsweise 20, 40, 80 oder 160 MHz
RSSI Empfangssignalstärke, häufig in dBm angegeben
Noise Gemessener beziehungsweise geschätzter Rauschpegel
SNR Abstand zwischen Nutzsignal und Rauschen
PHY-Rate Ausgehandelte Bruttodatenrate der Funkverbindung
Durchsatz Tatsächlich nutzbare Datenübertragungsrate
Roaming Wechsel eines Clients zwischen Funkzellen
Band Steering Access Point versucht, Clients in ein geeignetes Frequenzband zu lenken
Airtime Anteil der Funkzeit, den Geräte für Übertragungen verwenden
DFS Dynamische Kanalauswahl zum Schutz bestimmter Radarsysteme
Hidden SSID SSID wird nicht regulär in Beacon-Frames angekündigt
802.1X Portbasierte Authentifizierung, häufig in Unternehmens-WLANs
Captive Portal Webbasierte Freischaltung, häufig in Gastnetzen

Mehrere Access Points können dieselbe SSID anbieten, aber jeweils eine eigene BSSID verwenden.

4. Störungsumfang zuerst bestimmen

Vor technischen Änderungen ist zu klären:

Sinnvolle Vergleichsmatrix:

Vergleich Erkenntnis
Gleiches Gerät, anderer Standort Funkzelle oder Standortproblem
Gleiches Gerät, andere SSID SSID-, Authentifizierungs- oder VLAN-Problem
Anderes Gerät, gleiche Position Client- oder allgemeines Funkproblem
WLAN gegenüber Ethernet Funkebene gegenüber allgemeinem Netzwerkproblem
Betroffener gegenüber funktionierendem Client Konfigurationsunterschiede
Nähe zum AP gegenüber Randbereich Signal-, Störungs- oder Roamingproblem
5. Signalstärke in dBm richtig interpretieren

WLAN-Signalstärken werden häufig als negative dBm-Werte angegeben.

-45 dBm ist stärker als -75 dBm

Eine näher an null liegende Zahl bedeutet ein stärkeres Signal.

RSSI-Beispiel Grobe praktische Einordnung
-30 dBm Extrem stark, meist in unmittelbarer Nähe
-40 bis -50 dBm Sehr stark
-50 bis -60 dBm Häufig gut für anspruchsvolle Anwendungen
-60 bis -67 dBm Häufig noch brauchbar bis gut
-67 bis -70 dBm Je nach Anwendung und Umgebung grenzwertig
-70 bis -80 dBm Schwach, geringere Datenraten und Wiederholungen wahrscheinlich
unter -80 dBm Häufig instabil oder nicht mehr sinnvoll nutzbar

Diese Werte sind keine universellen Garantien. Antennen, Clienthardware, Kanalbreite, Störungen, Anwendung und Messverfahren beeinflussen das Ergebnis.

Signal-Rausch-Abstand näherungsweise:

SNR = Signalpegel − Rauschpegel

Beispiel:

Signal:  -60 dBm
Rauschen: -90 dBm

SNR = 30 dB

Ein starkes Signal kann trotzdem schlecht nutzbar sein, wenn das Rauschen oder die Kanalbelegung ebenfalls hoch ist.

6. PHY-Rate und tatsächlichen Durchsatz unterscheiden

Die angezeigte Verbindungsrate ist eine ausgehandelte Bruttodatenrate und nicht der tatsächlich nutzbare Anwendungsdurchsatz.

Abzüge entstehen unter anderem durch:

Deshalb gilt:

PHY-Rate 866 Mbit/s
≠
866 Mbit/s nutzbarer Datendurchsatz

Ein Internet-Speedtest misst zusätzlich Internetanschluss, WAN, Testserver und Providerpfad. Zur reinen WLAN-Beurteilung ist ein lokaler Testserver im kabelgebundenen LAN besser geeignet.

7. Windows: WLAN-Schnittstelle und Verbindung prüfen

WLAN-Schnittstellen und aktuelle Verbindung:

[RO][SENS] netsh wlan show interfaces

Typische Angaben:

Name
Beschreibung
GUID
Physische Adresse
Status
SSID
BSSID
Netzwerktyp
Funktyp
Authentifizierung
Verschlüsselung
Kanal
Empfangsrate
Übertragungsrate
Signal
Profil

Alle relevanten WLAN-Informationen:

[RO][SENS] netsh wlan show all

Windows-Netzwerkadapter:

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

IP-Konfiguration:

[RO][SENS] Get-NetIPConfiguration

Adapterstatistik:

[RO] Get-NetAdapterStatistics |
    Format-Table Name, ReceivedBytes, SentBytes,
                 ReceivedDiscardedPackets, OutboundDiscardedPackets,
                 ReceivedPacketErrors, OutboundPacketErrors

Paketfehler und verworfene Pakete müssen über einen Zeitraum beziehungsweise im Vergleich zu einem funktionierenden Zustand bewertet werden.

8. Windows: sichtbare Netze, BSSIDs und Kanäle prüfen

Sichtbare WLAN-Netze:

[RO][SENS] netsh wlan show networks

Sichtbare Netze einschließlich BSSIDs:

[RO][SENS] netsh wlan show networks mode=bssid

Damit lassen sich unter anderem vergleichen:

Wichtige Fragen:

Ein einfacher Scan ist nur eine Momentaufnahme und erkennt nicht jede Störung oder Auslastung.

9. Windows: Treiber und Fähigkeiten prüfen

WLAN-Treiberinformationen:

[RO][SENS] netsh wlan show drivers

Mögliche Angaben:

Wireless Capabilities:

[RO][SENS] netsh wlan show wirelesscapabilities

PowerShell-Treiberinformationen:

[RO][SENS] Get-CimInstance Win32_PnPSignedDriver |
    Where-Object DeviceClass -eq "NET" |
    Select-Object DeviceName, DriverProviderName,
                  DriverVersion, DriverDate

Treiberstände sollten mit der offiziellen Freigabe des Geräte- oder Adapterherstellers verglichen werden. Ein neuerer generischer Treiber ist nicht automatisch besser als der vom Systemhersteller freigegebene Treiber.

10. Windows: gespeicherte WLAN-Profile prüfen

Gespeicherte Profile:

[RO][SENS] netsh wlan show profiles

Bestimmtes Profil anzeigen:

[RO][SENS] netsh wlan show profile name="SSID-ODER-PROFILNAME"

Zu kontrollieren sind:

Nicht verwenden:

key=clear

Dadurch könnte ein gespeicherter WLAN-Schlüssel im Klartext ausgegeben werden. Das ist für eine normale Fehleranalyse nicht erforderlich und darf nicht in Dokumentationen verwendet werden.

11. Windows-WLAN-Bericht erstellen

WLAN-Bericht erzeugen:

[RO][PRIV][FILE][SENS] netsh wlan show wlanreport

Windows zeigt nach der Erstellung den konkreten Speicherort des Berichts an. Dieser Pfad sollte aus der Ausgabe übernommen und nicht angenommen werden.

Der Bericht kann unter anderem enthalten:

Der Bericht enthält sensible Netzwerkdaten und muss entsprechend geschützt werden.

WLAN-Ereignisprotokoll prüfen:

[RO][PRIV][SENS] Get-WinEvent `
    -LogName "Microsoft-Windows-WLAN-AutoConfig/Operational" `
    -MaxEvents 100

Zeitlich begrenzen:

[RO][PRIV][SENS] Get-WinEvent `
    -FilterHashtable @{
        LogName   = "Microsoft-Windows-WLAN-AutoConfig/Operational"
        StartTime = (Get-Date).AddMinutes(-30)
    }
12. Linux: WLAN-Schnittstellen und Verbindungsstatus prüfen

Netzwerkgeräte:

[RO] ip -br link

NetworkManager-Gerätestatus:

[RO] nmcli device status

Aktive Verbindungen:

[RO][SENS] nmcli connection show --active

WLAN-Schnittstellen mit iw:

[RO] iw dev

Aktuelle Verbindung einer bestimmten Schnittstelle:

[RO][SENS] iw dev wlan0 link

wlan0 muss durch den tatsächlich ermittelten Schnittstellennamen ersetzt werden.

Typische Angaben von iw dev wlan0 link:

BSSID
SSID
Frequenz
RX-Daten
TX-Daten
Signal
RX-Bitrate
TX-Bitrate

Stationsinformationen:

[RO][SENS] iw dev wlan0 station dump

Abhängig von Treiber und Betriebsmodus können zusätzliche Werte wie Signal, Bitrate, Wiederholungen und übertragene Daten angezeigt werden.

13. Linux: sichtbare Netze und Funkumgebung prüfen

WLAN-Scan mit NetworkManager:

[TEST][SENS] nmcli device wifi list

Scan für eine bestimmte Schnittstelle:

[TEST][SENS] nmcli device wifi list ifname wlan0

Ausgewählte Felder anzeigen:

[TEST][SENS] nmcli -f IN-USE,SSID,BSSID,MODE,CHAN,FREQ,RATE,SIGNAL,SECURITY \
    device wifi list

Regulierungsdomäne prüfen:

[RO] iw reg get

WLAN-Fähigkeiten des Adapters:

[RO][SENS] iw list

iw list kann eine sehr umfangreiche Ausgabe erzeugen. Relevant sind unter anderem:

Die Regulierungsdomäne darf nicht willkürlich verändert werden. Zulässige Kanäle und Sendeleistungen sind landesabhängig reguliert.

14. Linux: NetworkManager-Protokolle auswerten

Aktuelle NetworkManager-Protokolle:

[RO][PRIV][SENS] sudo journalctl -u NetworkManager --since "-30 minutes"

WLAN-bezogene Kernelmeldungen:

[RO][PRIV][SENS] sudo journalctl -k --since "-30 minutes" |
    grep -Ei 'wlan|wifi|wireless|80211|firmware'

Treiberzuordnung der Netzwerkschnittstellen:

[RO][SENS] lspci -k |
    grep -A 4 -Ei 'network|wireless'

Bei USB-WLAN-Adaptern:

[RO][SENS] lsusb

Zu suchen sind unter anderem:

15. macOS: WLAN-Schnittstelle und Verbindung prüfen

Hardwareports und Gerätenamen anzeigen:

[RO] networksetup -listallhardwareports

Dadurch wird ermittelt, welche Schnittstelle zum WLAN gehört, beispielsweise en0 oder en1. Der Name darf nicht ohne Prüfung vorausgesetzt werden.

Aktuell verbundenes WLAN:

[RO][SENS] networksetup -getairportnetwork en0

en0 muss durch die tatsächlich ermittelte WLAN-Schnittstelle ersetzt werden.

Ausführliche WLAN- und Hardwareinformationen:

[RO][SENS] system_profiler SPAirPortDataType

IP-Konfiguration:

[RO][SENS] ifconfig en0

Netzwerkdienstkonfiguration:

[RO][SENS] networksetup -getinfo "Wi-Fi"

Wi-Fi muss durch den tatsächlichen Namen des Netzwerkdienstes ersetzt werden.

16. macOS: aktuelle WLAN-Diagnoseinformationen prüfen

Auf aktuellen macOS-Versionen kann wdutil WLAN-Diagnoseinformationen bereitstellen.

Verfügbarkeit und Hilfe prüfen:

[RO] command -v wdutil

[RO] wdutil help

Aktuelle Diagnoseinformationen, sofern von der installierten Version unterstützt:

[RO][PRIV][SENS] sudo wdutil info

Die verfügbaren Unterbefehle und Ausgaben können sich zwischen macOS-Versionen unterscheiden. Deshalb muss zuerst die lokale Hilfe geprüft werden.

Mögliche Informationen sind:

Ältere Anleitungen verwenden häufig das interne airport-Werkzeug. Dessen Verfügbarkeit und Verhalten ist auf aktuellen macOS-Versionen nicht zuverlässig vorauszusetzen; deshalb wird es hier nicht als Standardbefehl verwendet.

17. macOS Wireless Diagnostics verwenden

Apple stellt die grafische Anwendung „Diagnose für drahtlose Umgebungen“ beziehungsweise „Wireless Diagnostics“ bereit.

Aufruf:

  1. Mit dem problematischen WLAN verbinden, soweit möglich.
  2. Wahltaste beziehungsweise Option gedrückt halten.
  3. Auf das WLAN-Symbol in der Menüleiste klicken.
  4. „Diagnose für drahtlose Umgebungen öffnen“ auswählen.
  5. Den Anweisungen folgen.

Apple gibt an, dass die Diagnose selbst die Netzwerkeinstellungen nicht verändert.

Die Diagnose kann ein komprimiertes Archiv erzeugen. Apple dokumentiert dafür:

/var/tmp

Der Dateiname beginnt mit:

WirelessDiagnostics

und endet mit:

.tar.gz

Das Archiv kann umfangreiche und sensible System- und Netzwerkdaten enthalten und darf nur geschützt weitergegeben werden.

18. Frequenzbänder praktisch unterscheiden
Eigenschaft 2,4 GHz 5 GHz 6 GHz
Reichweite Häufig größer Häufig geringer als 2,4 GHz Häufig stärker durch Entfernung und Hindernisse beeinflusst
Kanalkapazität Begrenzter Mehr verfügbare Kanalressourcen Große zusätzliche Frequenzressourcen
Störquellen Viele WLAN- und Nicht-WLAN-Geräte Häufig weniger Nicht-WLAN-Störungen Abhängig von regionaler Freigabe und Nutzung
Wanddurchdringung Häufig günstiger Häufig geringer Häufig geringer
Geräteunterstützung Sehr weit verbreitet Weit verbreitet Nur geeignete neuere Geräte
Kanalbreiten Häufig 20 oder 40 MHz Häufig 20 bis 160 MHz Abhängig von Standard und Gerät auch sehr breite Kanäle

Die tatsächlich nutzbaren Frequenzen und Kanalbreiten hängen von Land, Gerät, Treiber, Access Point und WLAN-Standard ab.

Typischer Zielkonflikt:

Breitere Kanäle
→ potenziell höhere Datenrate
→ benötigen mehr Frequenzspektrum
→ höhere Wahrscheinlichkeit von Überlappungen oder Störungen
19. Kanalbelegung und Störungen beurteilen

Ein WLAN-Kanal ist ein gemeinsam genutztes Medium. Alle Geräte auf demselben oder überlappenden Kanal teilen sich die verfügbare Funkzeit.

Mögliche Störquellen:

Co-Channel-Interference:

Mehrere WLANs verwenden denselben Kanal und müssen sich die Funkzeit teilen.

Adjacent-Channel-Interference:

Überlappende Kanäle beeinflussen sich, ohne sauber koordiniert zu werden.

Im 2,4-GHz-Band werden bei 20-MHz-Kanalbreite häufig überlappungsarme Planungen verwendet. Welche Kanäle zulässig und sinnvoll sind, hängt von der regionalen Regulierung und dem vorhandenen Kanalplan ab.

Ein Scan zeigt andere WLANs, aber nicht zuverlässig alle Nicht-WLAN-Störquellen. Dafür kann ein geeigneter Spektrumanalysator erforderlich sein.

20. DFS-Ereignisse berücksichtigen

Bestimmte 5-GHz-Kanäle unterliegen Dynamic Frequency Selection. Erkennt ein Access Point ein relevantes Radarsignal, kann er den Kanal wechseln oder die Aussendung vorübergehend einstellen.

Mögliche Symptome:

Zu prüfen sind:

DFS darf nicht pauschal als Fehler betrachtet werden. Es handelt sich um eine regulatorisch vorgesehene Schutzfunktion.

21. Authentifizierung und Verschlüsselung prüfen

Mögliche WLAN-Sicherheitsverfahren:

Zu kontrollieren sind:

Systemzeit:

Betriebssystem Befehl
Windows [RO] Get-Date -Format o
Linux [RO] date --iso-8601=seconds
macOS [RO] date "+%Y-%m-%dT%H:%M:%S%z"

Bei Zertifikats- und Kerberos-basierten Verfahren kann eine falsche Systemzeit die Anmeldung verhindern.

22. 802.1X- und Enterprise-WLAN eingrenzen

Ein Enterprise-WLAN kann mehrere Komponenten enthalten:

WLAN-Client
    ↓
Access Point
    ↓
WLAN-Controller
    ↓
RADIUS-Server
    ↓
Identitätsdienst
    ↓
VLAN- und Zugriffsrichtlinie

Zu dokumentieren sind:

Typische Fehler:

Beobachtung Mögliche Ursache
Kennwortabfrage wiederholt sich Zugangsdaten, EAP oder Zertifikatsprüfung
Zertifikatswarnung Vertrauenskette oder Serveridentität
Verbindung hergestellt, falsches Netz Dynamische VLAN-Zuweisung oder Richtlinie
Nur Gerätetunnel vor Anmeldung fehlt Computerzertifikat oder Geräteauthentifizierung
Benutzer funktioniert auf anderem Gerät Gerätezertifikat, Profil oder Gerätekonformität
Alle Benutzer an einem AP betroffen AP-, Controller- oder Netzwerkpfad zum RADIUS

Client-, Controller- und RADIUS-Protokolle müssen zeitlich miteinander verglichen werden.

23. Nach der WLAN-Verbindung DHCP prüfen

Windows:

[RO][SENS] Get-NetIPConfiguration

[RO][SENS] ipconfig /all

Linux:

[RO][SENS] ip -br address

[RO] ip route show

macOS:

[RO][SENS] networksetup -getinfo "Wi-Fi"

[RO][SENS] ifconfig en0

Zu kontrollieren sind:

Typisches Fehlerbild:

WLAN-Authentifizierung erfolgreich
↓
Client wird dem falschen VLAN zugeordnet
↓
DHCP-Server nicht erreichbar oder falscher Adressbereich
↓
Kein nutzbarer Netzwerkzugang

Eine IPv4-Adresse aus 169.254.0.0/16 weist häufig darauf hin, dass keine reguläre IPv4-DHCP-Zuweisung erfolgt ist.

24. Gateway, DNS und Internet getrennt testen

Stufe 1 – eigene IP-Konfiguration prüfen

IP-Adresse
Subnetzmaske beziehungsweise Präfix
Standardgateway
DNS-Server

Stufe 2 – Standardgateway testen

Windows:

[TEST] Test-Connection GATEWAY_IP -Count 4

Linux und macOS:

[TEST] ping -c 4 GATEWAY_IP

Stufe 3 – externe IP-Adresse testen:

Windows:

[TEST] Test-NetConnection 1.1.1.1 -Port 443

Linux und macOS:

[TEST] nc -vz -w 5 1.1.1.1 443

Stufe 4 – DNS-Auflösung testen

Windows:

[TEST] Resolve-DnsName example.com

Linux und macOS:

[TEST] dig example.com

Stufe 5 – Anwendung testen

[TEST] curl -I https://example.com/

Öffentliche Testziele dürfen nur verwendet werden, wenn dies durch die betrieblichen Richtlinien erlaubt ist.

25. Captive Portal erkennen

Gast-, Hotel- und öffentliche WLANs verlangen häufig eine browserbasierte Freischaltung.

Typische Symptome:

Zu prüfen sind:

Zertifikatswarnungen auf HTTPS-Seiten dürfen nicht einfach bestätigt werden. Für die Portalanmeldung sollte die vom Betreiber vorgesehene sichere Methode verwendet werden.

26. Zufällige MAC-Adressen berücksichtigen

Moderne Betriebssysteme können pro WLAN eine private beziehungsweise zufällige MAC-Adresse verwenden.

Das kann folgende Auswirkungen haben:

Windows-Status anzeigen:

[RO][SENS] netsh wlan show randomization

Windows-Schnittstellenadresse:

[RO] Get-NetAdapter |
    Format-Table Name, MacAddress, Status

Linux:

[RO] ip link show

macOS:

[RO] ifconfig en0

Die aktuelle Schnittstellenadresse allein zeigt nicht zwingend, ob und nach welchem Verfahren sie für ein bestimmtes WLAN erzeugt wurde. Die Einstellung sollte zusätzlich in der WLAN-Konfiguration des Betriebssystems geprüft werden.

Private MAC-Adressen dürfen nicht pauschal deaktiviert werden. Ihre Nutzung ist eine Datenschutz- und Netzwerkdesignentscheidung.

27. Roamingprobleme analysieren

Beim Roaming entscheidet der Client normalerweise selbst, wann er zu einer anderen Funkzelle wechselt. Access Points und Controller können diese Entscheidung unterstützen oder beeinflussen.

Typische Symptome:

Zu dokumentieren sind:

Wichtige Standards und Funktionen:

Funktion Aufgabe
802.11k Informationen über benachbarte Funkzellen
802.11v Unterstützung bei Netzwerkauswahl und Übergängen
802.11r Beschleunigte Übergänge zwischen Access Points
PMK-Caching Wiederverwendung bestimmter Authentifizierungsinformationen

Unterstützung und Verhalten hängen von Client, Access Point, Sicherheitsverfahren und Konfiguration ab.

28. Sticky Clients und Ping-Pong-Roaming erkennen

Sticky Client:

Client bleibt mit schwacher BSSID verbunden
obwohl eine nähere BSSID verfügbar ist

Mögliche Ursachen:

Ping-Pong-Roaming:

Client wechselt wiederholt zwischen zwei BSSIDs

Mögliche Ursachen:

Ein erzwungenes Trennen des Clients kann kurzfristig helfen, beweist aber keine nachhaltige Fehlerbehebung.

29. Energiesparfunktionen berücksichtigen

WLAN-Adapter und Betriebssysteme können die Funkhardware zum Energiesparen in reduzierte Betriebszustände versetzen.

Typische Symptome:

Windows-Energiezustände:

[RO] powercfg /getactivescheme

Windows-WLAN-Bericht:

[RO][PRIV][FILE][SENS] netsh wlan show wlanreport

Linux:

[RO] iw dev wlan0 get power_save

Nicht jeder Treiber unterstützt dieselbe Abfrage.

macOS:

[RO] pmset -g

Energiesparfunktionen sollten nicht dauerhaft deaktiviert werden, bevor Treiber, Firmware und das konkrete Fehlerbild geprüft wurden.

30. Paketverlust und Latenz lokal messen

Zuerst wird das lokale Standardgateway getestet. Dadurch bleiben Internetprovider und externe Netze zunächst außerhalb der Messung.

Windows:

[TEST] Test-Connection GATEWAY_IP -Count 50

Alternativ:

[TEST] ping -n 50 GATEWAY_IP

Linux und macOS:

[TEST] ping -c 50 GATEWAY_IP

Zu bewerten sind:

Wichtig: Access Points oder Gateways können ICMP niedriger priorisieren. Ein Ping-Test ist deshalb ein Hinweis, aber keine vollständige Qualitätsmessung.

31. Durchsatz im lokalen Netz mit iperf3 testen

Ein lokaler kabelgebundener iperf3-Server hilft, WLAN und Internetanschluss voneinander zu trennen.

Auf dem autorisierten kabelgebundenen Testserver:

[TEST] iperf3 -s

Auf dem WLAN-Client:

[TEST] iperf3 -c SERVER_IP

Gegenrichtung testen:

[TEST] iperf3 -c SERVER_IP -R

Bestimmte Testdauer:

[TEST] iperf3 -c SERVER_IP -t 30

UDP-Test mit begrenzter Zielrate:

[TEST] iperf3 -c SERVER_IP -u -b 20M -t 30

UDP-Tests erzeugen gezielt Last und müssen mit einer angemessenen Bandbreite begonnen werden.

Zu dokumentieren sind:

32. Internet-Speedtest nicht mit WLAN-Messung verwechseln

Ein Internet-Speedtest umfasst:

WLAN
+ lokales LAN
+ Router
+ Firewall
+ Internetanschluss
+ Provider
+ Routing zum Testserver
+ Testserver

Ein schlechtes Ergebnis kann daher auch bei einem fehlerfreien WLAN entstehen.

Empfohlene Reihenfolge:

  1. WLAN-Signal und Verbindungsparameter prüfen.
  2. Lokales Gateway testen.
  3. Lokalen kabelgebundenen iperf3-Server testen.
  4. Erst danach Internetdurchsatz messen.
  5. WLAN- und Ethernetmessung zum selben Ziel vergleichen.
  6. Messung zu mehreren Zeitpunkten wiederholen.

Die Aussage „WLAN liefert nur 50 Mbit/s“ ist ohne lokalen Vergleich nicht ausreichend belegt.

33. Airtime und hohe Clientdichte berücksichtigen

WLAN ist ein geteiltes Medium. Auch langsam sendende Clients verbrauchen Funkzeit.

Mögliche Ursachen hoher Airtime-Auslastung:

Typische Symptome:

Für eine zuverlässige Bewertung werden Controllerstatistiken oder geeignete WLAN-Analysewerkzeuge benötigt.

34. Access Point, Switch und VLAN gemeinsam prüfen

Ein Access Point benötigt selbst eine funktionierende kabelgebundene Infrastruktur.

Zu prüfen sind:

Typisches Fehlerbild:

Client verbindet sich erfolgreich mit SSID
↓
Access Point ordnet Client falschem VLAN zu
↓
Client erhält keine oder falsche IP-Konfiguration

Switchportzähler beachten:

Ein scheinbares Funkproblem kann tatsächlich auf dem kabelgebundenen AP-Uplink entstehen.

35. Mesh- und Repeater-Probleme erkennen

Bei Mesh-Systemen und Repeatern wird Verkehr zusätzlich über einen drahtlosen oder kabelgebundenen Backhaul übertragen.

Client
  ↓ WLAN
Mesh-Knoten oder Repeater
  ↓ Backhaul
Haupt-Access-Point
  ↓ LAN
Ziel

Zu prüfen sind:

Ein Repeater mit starkem Signal zum Client kann trotzdem eine schlechte Gesamtverbindung liefern, wenn sein eigener Uplink schwach ist.

36. Versteckte SSIDs und Netzwerkprofile beurteilen

Eine versteckte SSID verbessert die Verschlüsselung nicht. Clients müssen möglicherweise aktiv nach dem bekannten Netz suchen.

Mögliche Nachteile:

Zu prüfen sind:

Das Löschen und Neuerstellen eines Profils ist eine Änderung. Vorher sollten Profilquelle, Unternehmensrichtlinie und Zugangsdaten geklärt werden.

37. Keine vorschnellen WLAN-Änderungen durchführen

Nicht unkontrolliert:

Sicherer Ablauf:

  1. Istzustand und Standort dokumentieren.
  2. SSID, BSSID, Kanal, Band und Signal erfassen.
  3. Fehler reproduzieren.
  4. Client und Vergleichsgerät prüfen.
  5. Authentifizierung und VLAN-Zuweisung kontrollieren.
  6. DHCP, Gateway und DNS testen.
  7. Lokalen Durchsatz messen.
  8. Client-, AP-, Controller- und RADIUS-Protokolle vergleichen.
  9. Ursache nachweisen.
  10. Änderung genehmigen lassen.
  11. Auswirkung auf andere Funkzellen und Clients berücksichtigen.
  12. Nachprüfung am ursprünglichen Fehlerort durchführen.
38. Systematischer Diagnoseablauf
Schritt Prüfung Leitfrage
1 Störungsumfang bestimmen Client, Standort, BSSID, SSID oder gesamtes WLAN?
2 Hardwarestatus prüfen Wird der WLAN-Adapter korrekt erkannt?
3 Treiber und Fähigkeiten prüfen Unterstützt der Client Band und Sicherheitsverfahren?
4 Funkumgebung erfassen Ist die SSID sichtbar und wie stark ist das Signal?
5 BSSID und Kanal dokumentieren Mit welcher Funkzelle ist der Client verbunden?
6 Authentifizierung prüfen Wird Personal- oder Enterprise-Anmeldung akzeptiert?
7 VLAN-Zuweisung prüfen Landet der Client im vorgesehenen Netz?
8 IP-Konfiguration prüfen Sind Adresse, Gateway und DNS korrekt?
9 Gateway testen Funktioniert der lokale Netzwerkpfad?
10 DNS testen Werden Namen korrekt aufgelöst?
11 Anwendung testen Funktioniert der tatsächlich benötigte Dienst?
12 Paketverlust messen Ist die Funkverbindung stabil?
13 Lokalen Durchsatz messen Welche Leistung liefert nur das WLAN?
14 Roaming prüfen Tritt der Fehler beim BSSID-Wechsel auf?
15 Kanal und Auslastung prüfen Ist die Funkzelle gestört oder überlastet?
16 AP-Uplink prüfen Funktioniert die kabelgebundene Infrastruktur?
17 Protokolle vergleichen Welche Komponente lehnt ab oder trennt?
18 Minimale Änderung planen Welche konkrete Korrektur stellt den Sollzustand her?
19 Nachprüfung Funktioniert es am ursprünglichen Standort unter Last?
20 Dokumentation Sind Ursache, Messwerte und Änderung festgehalten?
39. Kompakte Befehlstabelle
Aufgabe Windows Linux macOS
WLAN-Verbindungsstatus [RO][SENS] netsh wlan show interfaces [RO][SENS] iw dev wlan0 link [RO][SENS] networksetup -getairportnetwork en0
Netzwerkschnittstellen [RO] Get-NetAdapter [RO] ip -br link [RO] networksetup -listallhardwareports
Sichtbare WLANs [RO][SENS] netsh wlan show networks mode=bssid [TEST][SENS] nmcli device wifi list Wireless Diagnostics beziehungsweise [RO][PRIV][SENS] sudo wdutil info, falls unterstützt
WLAN-Treiber [RO][SENS] netsh wlan show drivers [RO][SENS] lspci -k beziehungsweise [RO][SENS] lsusb [RO][SENS] system_profiler SPAirPortDataType
WLAN-Fähigkeiten [RO][SENS] netsh wlan show wirelesscapabilities [RO][SENS] iw list [RO][SENS] system_profiler SPAirPortDataType
Gespeicherte Profile [RO][SENS] netsh wlan show profiles [RO][SENS] nmcli connection show Über WLAN-Einstellungen beziehungsweise MDM prüfen
IP-Konfiguration [RO][SENS] Get-NetIPConfiguration [RO][SENS] ip -br address [RO][SENS] networksetup -getinfo "Wi-Fi"
Standardroute [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" [RO] ip route show default [RO] route -n get default
DNS-Konfiguration [RO][SENS] Get-DnsClientServerAddress [RO][SENS] resolvectl status [RO][SENS] scutil --dns
Adapterstatistik [RO] Get-NetAdapterStatistics [RO][SENS] iw dev wlan0 station dump Abhängig von macOS-Version: wdutil prüfen
WLAN-Protokoll [RO][PRIV][SENS] Get-WinEvent -LogName "Microsoft-Windows-WLAN-AutoConfig/Operational" [RO][PRIV][SENS] sudo journalctl -u NetworkManager Wireless Diagnostics
WLAN-Bericht [RO][PRIV][FILE][SENS] netsh wlan show wlanreport Protokolle und Befehlsausgaben getrennt sichern Wireless Diagnostics erzeugt Diagnosearchiv
Gatewaytest [TEST] Test-Connection GATEWAY_IP -Count 20 [TEST] ping -c 20 GATEWAY_IP [TEST] ping -c 20 GATEWAY_IP
Lokaler Durchsatz [TEST] iperf3 -c SERVER_IP [TEST] iperf3 -c SERVER_IP [TEST] iperf3 -c SERVER_IP

wlan0, en0, Wi-Fi, GATEWAY_IP und SERVER_IP müssen durch die tatsächlich ermittelten Werte ersetzt werden.

40. Dokumentationsvorlage für WLAN-Fehler 
Störung:
Zeitpunkt:
Zeitzone:
Standort:
Raum beziehungsweise Bereich:
Benutzer:
Client:
Betriebssystem:
WLAN-Adapter:
Treiberversion:

SSID:
BSSID:
Access Point:
Frequenzband:
Frequenz:
Kanal:
Kanalbreite:
WLAN-Standard:
Signal beziehungsweise RSSI:
Rauschpegel:
SNR:
TX-PHY-Rate:
RX-PHY-Rate:
Sicherheitsverfahren:

Authentifizierung erfolgreich:
802.1X-Verfahren:
RADIUS-Ergebnis:
Zugewiesenes VLAN:
Client-IP-Adresse:
Präfix:
Standardgateway:
DHCP-Server:
DNS-Server:
IPv6-Konfiguration:

Gatewaytest:
Paketverlust:
Latenz:
DNS-Test:
Anwendungstest:
Lokaler iperf3-Test:
Internettest:
Captive Portal:
Private MAC-Adresse:

Alte BSSID vor Roaming:
Neue BSSID nach Roaming:
Unterbrechungsdauer:
Roamingzeitpunkt:

Vergleichsgerät:
Vergleich an anderem Standort:
Vergleich über Ethernet:
Andere Clients betroffen:
Andere SSIDs betroffen:

Access-Point-Protokoll:
Controllerprotokoll:
RADIUS-Protokoll:
Switchportstatus:
PoE-Status:
Uplinkfehler:
DFS-Ereignis:
Kanalauslastung:

Festgestellte Ursache:
Genehmigte Änderung:
Rückfallplan:
Ergebnis der Nachprüfung:
41. Kontrollfragen nach der Diagnose
42. Quellen und weiterführende Dokumentation
3. Netzwerkfehler systematisch analysieren

3.15 Paketverlust, Latenz, Jitter und Bandbreite analysieren

Netzwerkleistung besteht aus mehreren voneinander unabhängigen Messgrößen. Eine Verbindung kann einen hohen Durchsatz erreichen und trotzdem für Sprache, Remotezugriff oder Echtzeitanwendungen ungeeignet sein. Umgekehrt kann eine Verbindung mit begrenzter Bandbreite sehr stabil und reaktionsschnell arbeiten.

Die zentralen Fragen dieser Seite lauten:

An welchem Abschnitt des Datenpfads verschlechtert sich die Verbindung, welche Messgröße ist betroffen und tritt das Problem dauerhaft oder nur unter Last auf?

1. Sicherheits- und Aktionskennzeichnungen
Kennzeichnung Bedeutung
[RO] Rein lesender Befehl, der normalerweise keine Konfiguration verändert
[TEST] Aktiver Test, der Netzwerkverkehr erzeugt
[PRIV] Administrator- oder Root-Rechte können erforderlich sein
[FILE] Der Befehl schreibt Ausgaben in eine Datei
[SENS] Die Ausgabe kann sensible Informationen enthalten
[CHANGE] Der Befehl verändert eine Konfiguration
[DISRUPT] Der Befehl kann eine Verbindung oder einen Dienst beeinträchtigen

Bandbreiten- und Lasttests dürfen nur gegen ausdrücklich freigegebene Systeme durchgeführt werden. Sie können Leitungen, Firewalls, Server und andere Benutzer erheblich belasten.

2. Die wichtigsten Leistungsbegriffe unterscheiden
Begriff Bedeutung
Latenz Zeit, die eine Übertragung von einem Punkt zu einem anderen benötigt
Round-Trip Time – RTT Zeit für Hin- und Rückweg
Jitter Schwankung der Paketlaufzeit
Paketverlust Anteil gesendeter Pakete, die das Ziel beziehungsweise die Messstelle nicht erreichen
Bandbreite Theoretische oder konfigurierte Übertragungskapazität
Durchsatz Tatsächlich übertragene Datenmenge pro Zeit
Goodput Für die Anwendung nutzbare Datenmenge ohne Protokoll- und Wiederholungsdaten
Retransmission Erneute Übertragung verlorener oder nicht bestätigter TCP-Daten
Congestion Überlastung eines Netzwerkpfads oder einer Warteschlange
Bufferbloat Stark steigende Latenz durch übermäßig gefüllte Warteschlangen
Burst Loss Mehrere Paketverluste in kurzer Folge
Out-of-Order Pakete treffen in anderer Reihenfolge ein
Duplication Pakete treffen mehrfach ein
Queueing Delay Verzögerung durch Warteschlangen
Serialization Delay Zeit, um ein Paket auf einen Link zu übertragen
Processing Delay Verarbeitungszeit in einem Netzwerkgerät
Propagation Delay Physikalische Signallaufzeit über das Medium
3. Bit, Byte und Übertragungsraten richtig umrechnen 
1 Byte = 8 Bit
Einheit Bedeutung
1 kbit/s üblicherweise 1.000 Bit pro Sekunde
1 Mbit/s üblicherweise 1.000.000 Bit pro Sekunde
1 Gbit/s üblicherweise 1.000.000.000 Bit pro Sekunde
1 MB/s 8 Mbit/s
100 MB/s 800 Mbit/s
125 MB/s 1.000 Mbit/s beziehungsweise 1 Gbit/s

Dateigrößen können binär oder dezimal angegeben werden. Zusätzlich reduzieren Protokoll-Overhead, Verschlüsselung, Wiederholungen und Dateisystemverarbeitung den nutzbaren Durchsatz.

Beispiel:

1-Gbit/s-Ethernet
≠
125 MB/s garantierte Nutzdatenrate
4. Messziel und Datenpfad vollständig beschreiben

Vor der Messung ist der genaue Pfad zu dokumentieren:

Client
  ↓
WLAN oder Ethernet
  ↓
Access Point oder Switch
  ↓
Router beziehungsweise Firewall
  ↓
VPN, WAN oder Internet
  ↓
Zielnetz
  ↓
Server
  ↓
Anwendung und Datenträger

Benötigte Angaben:

Quelle:
Quell-IP:
Quellschnittstelle:
Ziel:
Ziel-IP:
Transportprotokoll:
Zielport:
IPv4 oder IPv6:
VPN beteiligt:
Proxy beteiligt:
NAT beteiligt:
Testzeitpunkt:
Gegenrichtung:
Erwartete Leistung:
Beobachtete Leistung:

Ohne definierten Messpfad ist die Aussage „Das Netzwerk ist langsam“ nicht technisch verwertbar.

5. Die Verbindung abschnittsweise messen
Messabschnitt Typisches Ziel
Client zur lokalen Schnittstelle Adapter und Betriebssystem
Client zum Standardgateway lokales LAN beziehungsweise WLAN
Client zu lokalem Server internes Netzwerk
Client zu anderem VLAN Routing und interne Firewall
Client zum VPN-Gateway Internet- oder WAN-Basisverbindung
Client durch VPN zum internen Server Tunnel, VPN-Routing und Zielnetz
Client zum Internetziel Provider- und Internetpfad
Reverse Proxy zum Backend Servernetz und Backend
Server zum Datenspeicher Speicher- oder Anwendungsengpass

Grundregel:

Mit der nächstgelegenen sinnvollen Messstelle beginnen und den Pfad schrittweise erweitern.

6. Einzelmessung und Langzeitmessung unterscheiden

Eine einzelne Messung kann zufällig in einem guten oder schlechten Moment stattfinden.

Für eine belastbare Diagnose dokumentieren:

Durchschnittswerte können kurze Ausfälle verdecken:

99 Messungen: 10 ms
1 Messung:    2.000 ms

Durchschnitt:
29,9 ms

Der Durchschnitt wirkt noch relativ niedrig, obwohl eine einzelne Verzögerung von zwei Sekunden für Echtzeitanwendungen deutlich spürbar sein kann.

7. ICMP-Ping sinnvoll einsetzen

Ping misst die Round-Trip Time von ICMP Echo Request und Echo Reply.

Windows:

[TEST] ping -n 20 ZIEL_IP

Windows PowerShell:

[TEST] Test-Connection ZIEL_IP -Count 20

Linux:

[TEST] ping -c 20 ZIEL_IP

macOS:

[TEST] ping -c 20 ZIEL_IP

Zu dokumentieren sind:

Wichtig: Ein Ziel kann ICMP blockieren oder niedriger priorisieren, während Anwendungsverkehr weiterhin funktioniert.

8. Ping-Ergebnisse korrekt interpretieren
Beobachtung Mögliche Bedeutung
Gleichmäßig niedrige RTT Pfad ist für diese Messung stabil
Dauerhaft hohe RTT Entfernung, langsamer Link, Tunnel oder Überlastung
Einzelne starke Spitzen Queueing, Funkstörung, Last oder Verarbeitungsspitze
Regelmäßige Spitzen periodischer Datenverkehr, Scan, Backup oder Energiesparfunktion
Vereinzelter Verlust Störung, Überlastung oder ICMP-Priorisierung
Verlust in Bursts Link-Flap, Funkproblem, Queue Drop oder Pfadwechsel
Kein Ping, Anwendung funktioniert ICMP wird möglicherweise gefiltert
Ping zur IP funktioniert, zum Namen nicht Namensauflösung prüfen
Gatewayping schlecht Problem wahrscheinlich bereits im lokalen Zugangsnetz
Gatewayping gut, externes Ziel schlecht Problem liegt wahrscheinlich hinter dem Gateway

Ein Ping beweist nicht die Leistungsfähigkeit von TCP, UDP oder der Anwendung.

9. Lokales Gateway zuerst messen

Standardgateway ermitteln:

Windows:

[RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" |
    Sort-Object RouteMetric |
    Format-Table InterfaceAlias, NextHop, RouteMetric

Linux:

[RO] ip route show default

macOS:

[RO] route -n get default

Gateway über längeren Zeitraum testen:

Windows:

[TEST] ping -n 100 GATEWAY_IP

Linux und macOS:

[TEST] ping -c 100 GATEWAY_IP

Wenn bereits zum lokalen Gateway Paketverlust oder starke Latenzschwankungen auftreten, sollten zuerst folgende Komponenten geprüft werden:

10. Mehrere Messziele parallel vergleichen

Für die Eingrenzung werden mehrere Ziele betrachtet:

Ziel 1: lokales Gateway
Ziel 2: interner Server
Ziel 3: WAN-Gegenstelle
Ziel 4: Anwendungsserver

Interpretationsbeispiel:

Gateway Interner Server Externes Ziel Mögliche Eingrenzung
gut gut schlecht WAN, Provider oder externer Pfad
gut schlecht gut internes Routing, VLAN oder Serverpfad
schlecht schlecht schlecht lokales Zugangsnetz
gut gut gut möglicherweise anwendungsspezifisches Problem
gut nur VPN-Ziel schlecht gut VPN oder entferntes Netz

Parallele Messungen müssen mit sinnvollen Intervallen erfolgen, damit die Diagnose nicht selbst unnötige Last erzeugt.

11. TCP-Erreichbarkeit und TCP-Latenz prüfen

Wenn ICMP blockiert wird, kann ein Test zum tatsächlichen TCP-Port sinnvoller sein.

Windows:

[TEST] Test-NetConnection server.example.internal `
    -Port 443 `
    -InformationLevel Detailed

Linux und macOS:

[TEST] nc -vz -w 5 server.example.internal 443

Diese Befehle zeigen hauptsächlich, ob ein TCP-Verbindungsaufbau möglich ist. Sie liefern noch keine vollständige Leistungsmessung.

Windows mit PsPing, sofern autorisiert installiert:

[TEST] psping -n 20 server.example.internal:443

PsPing kann TCP-Verbindungszeiten messen und ist besonders nützlich, wenn ICMP nicht beantwortet wird.

12. Anwendungsantwortzeiten mit curl zerlegen

Zeitanteile einer HTTP- beziehungsweise HTTPS-Anfrage:

[TEST][SENS] curl -sS -o /dev/null \
    -w 'DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nStartTransfer: %{time_starttransfer}\nTotal: %{time_total}\nHTTP: %{http_code}\n' \
    https://service.example.net/
curl-Wert Bedeutung
time_namelookup Zeit bis zum Abschluss der Namensauflösung
time_connect Zeit bis zum TCP-Verbindungsaufbau
time_appconnect Zeit bis zum Abschluss des TLS-Handshakes
time_starttransfer Zeit bis zum ersten Antwortbyte
time_total Gesamtdauer
http_code HTTP-Statuscode

Typische Eingrenzung:

Auffälliger Wert Mögliche Ursache
DNS-Zeit hoch DNS-Server, Suche oder Netzwerkpfad
Connect-Zeit hoch Latenz, Paketverlust, Firewall oder Serverlistener
TLS-Zeit hoch TLS-Handshake, Zertifikatsprüfung oder CPU
StartTransfer hoch Server, Datenbank oder Backend
Total hoch, StartTransfer normal große Antwort, begrenzte Bandbreite oder langsamer Client
13. Netzwerkpfad mit traceroute und tracert prüfen

Windows ohne Namensauflösung:

[TEST] tracert -d ZIEL_IP

Linux:

[TEST] traceroute -n ZIEL_IP

Falls traceroute nicht installiert ist:

[TEST] tracepath -n ZIEL_IP

macOS:

[TEST] traceroute -n ZIEL_IP

Zu kontrollieren sind:

Ein Sternchen bei einem Zwischenrouter beweist keinen Paketverlust des weitergeleiteten Nutzverkehrs. Der Router kann Antworten auf Diagnosepakete begrenzen oder vollständig unterdrücken.

14. IPv4 und IPv6 getrennt messen

Ein Hostname kann sowohl IPv4- als auch IPv6-Adressen besitzen. Die Pfade und Leistungswerte können deutlich voneinander abweichen.

Windows:

[TEST] ping -4 -n 20 HOSTNAME
[TEST] ping -6 -n 20 HOSTNAME

[TEST] tracert -4 -d HOSTNAME
[TEST] tracert -6 -d HOSTNAME

Linux:

[TEST] ping -4 -c 20 HOSTNAME
[TEST] ping -6 -c 20 HOSTNAME

macOS:

[TEST] ping -c 20 IPV4_ADRESSE
[TEST] ping6 -c 20 IPV6_ADRESSE

HTTP getrennt testen:

[TEST] curl -4 -I https://service.example.net/
[TEST] curl -6 -I https://service.example.net/

Ein gutes IPv4-Ergebnis beweist nicht, dass der IPv6-Pfad ebenfalls funktioniert.

15. Windows pathping verwenden

pathping kombiniert Pfadermittlung mit wiederholten Messungen zu Zwischenstationen.

Ohne Namensauflösung:

[TEST] pathping /n ZIEL_IP

IPv4:

[TEST] pathping /n /4 ZIEL_IP

IPv6:

[TEST] pathping /n /6 ZIEL_IP

Die Messung kann mehrere Minuten dauern.

Wichtige Interpretation:

Wenn ein Zwischenhop hohen Verlust zeigt, spätere Hops und das Ziel aber keinen entsprechenden Verlust zeigen, priorisiert oder begrenzt der Zwischenrouter wahrscheinlich nur seine eigenen ICMP-Antworten.

Ein echter Weiterleitungsverlust wird typischerweise ab einer Stelle auch an nachfolgenden Hops beziehungsweise am Ziel sichtbar.

16. MTR unter Linux und macOS verwenden

mtr kombiniert fortlaufende Pfad- und Latenzmessungen. Es ist nicht auf jedem System standardmäßig installiert.

Prüfen, ob MTR vorhanden ist:

[RO] command -v mtr

Interaktive Messung ohne Namensauflösung:

[TEST] mtr -n ZIEL_IP

Berichtsmodus mit 100 Messzyklen:

[TEST] mtr -n -r -c 100 ZIEL_IP

TCP-basierter Test zu Port 443, sofern von der installierten Version unterstützt:

[TEST][PRIV] sudo mtr -n -r -c 100 -T -P 443 ZIEL_IP

Vor Verwendung erweiterter Optionen lokale Hilfe prüfen:

[RO] mtr --help

Auch bei MTR gilt: Verlust an einem Zwischenhop allein ist kein Beweis für weitergeleiteten Paketverlust.

17. Paketverlust mathematisch einordnen 
Paketverlust in Prozent =
(verlorene Pakete ÷ gesendete Pakete) × 100

Beispiel:

Gesendet: 1.000
Empfangen: 990
Verloren: 10

Paketverlust = 1 %

Die Auswirkungen hängen von Anwendung und Verteilung des Verlusts ab.

Verlustmuster Mögliche Wirkung
Einzelne gleichmäßig verteilte Verluste TCP-Wiederholungen, kurze Audiofehler
Mehrere Verluste in Folge deutliche Unterbrechung oder Timeout
Verlust nur unter Last überfüllte Queue oder überlasteter Link
Verlust nur in eine Richtung asymmetrisches Problem
Verlust nur großer Pakete MTU- oder Fragmentierungsproblem
ICMP-Verlust ohne Anwendungsverlust mögliche ICMP-Priorisierung

Burst Loss ist für Echtzeitanwendungen häufig problematischer als derselbe prozentuale Verlust gleichmäßig verteilt.

18. Jitter messen und beurteilen

Jitter beschreibt die Schwankung von Paketlaufzeiten. Es gibt unterschiedliche Berechnungsmethoden; Werte verschiedener Werkzeuge sind daher nicht immer direkt vergleichbar.

Typische Symptome hohen Jitters:

ping zeigt Schwankungen der RTT, ist aber kein vollständiger Ersatz für eine anwendungsnahe Jittermessung.

Für UDP kann iperf3 Jitter und Datagrammverlust ausgeben:

[TEST] iperf3 -c SERVER_IP -u -b 10M -t 30

Mit niedriger, kontrollierter Zielrate beginnen. Eine zu hohe Testbandbreite erzeugt selbst Verlust und Jitter.

19. iperf3-Testumgebung vorbereiten

Für eine kontrollierte Messung werden benötigt:

iperf3-Client
iperf3-Server
freigegebener Testpfad
bekannte Schnittstellen
ausreichende Serverleistung
definierte Testdauer

Server starten:

[TEST] iperf3 -s

Standardmäßig verwendet iperf3 Port 5201. Der Port kann verändert werden.

Clienttest:

[TEST] iperf3 -c SERVER_IP

Anderer Port:

Server:

[TEST] iperf3 -s -p 5202

Client:

[TEST] iperf3 -c SERVER_IP -p 5202

Firewallregeln müssen zum gewählten Transport und Port passen.

Bei UDP-Tests verwendet iperf3 zusätzlich eine TCP-Steuerverbindung. Die genaue Port- und Firewallkonfiguration ist deshalb vorab zu prüfen.

20. TCP-Durchsatz mit iperf3 messen

Standardtest vom Client zum Server:

[TEST] iperf3 -c SERVER_IP

30 Sekunden testen:

[TEST] iperf3 -c SERVER_IP -t 30

Gegenrichtung – Server sendet zum Client:

[TEST] iperf3 -c SERVER_IP -R -t 30

Beide Richtungen gleichzeitig, sofern unterstützt:

[TEST] iperf3 -c SERVER_IP --bidir -t 30

Mehrere parallele TCP-Datenströme:

[TEST] iperf3 -c SERVER_IP -P 4 -t 30

Parallele Datenströme können einen Pfad stärker auslasten und höhere Messwerte erzielen. Sie können aber Probleme eines einzelnen Datenstroms verdecken und erhebliche Last erzeugen.

Empfohlene Reihenfolge:

  1. Ein TCP-Datenstrom zum Server.
  2. Ein TCP-Datenstrom in Gegenrichtung.
  3. Bei Bedarf mehrere Datenströme.
  4. Erst danach gleichzeitiger bidirektionaler Test.
21. UDP mit iperf3 kontrolliert messen

UDP-Test mit 10 Mbit/s Zielrate:

[TEST] iperf3 -c SERVER_IP -u -b 10M -t 30

Gegenrichtung:

[TEST] iperf3 -c SERVER_IP -u -b 10M -t 30 -R

Relevante Ergebnisse:

Teststrategie:

niedrige Rate
→ Ergebnis prüfen
→ Rate schrittweise erhöhen
→ Beginn von Verlust und Jitter dokumentieren

Nicht sofort mit der maximal erwarteten Linkgeschwindigkeit beginnen. Ein UDP-Test besitzt keine TCP-Staukontrolle und kann andere Verbindungen stark beeinträchtigen.

22. iperf3-Ergebnisse als JSON speichern

JSON-Ausgabe anzeigen:

[TEST][SENS] iperf3 -c SERVER_IP -J

In Datei speichern:

[TEST][FILE][SENS] iperf3 -c SERVER_IP -t 30 -J > iperf3-test.json

UDP-Ergebnis speichern:

[TEST][FILE][SENS] iperf3 -c SERVER_IP \
    -u -b 10M -t 30 -J > iperf3-udp-test.json

Vor einer Weitergabe prüfen, ob die Datei interne IP-Adressen, Hostnamen oder andere sensible Angaben enthält.

23. iperf3-Ergebnisse richtig interpretieren
Beobachtung Mögliche Bedeutung
Hinrichtung gut, Rückrichtung schlecht asymmetrischer Pfad, QoS, Empfangs- oder Sendeseite
Ein Stream schlecht, mehrere gut RTT, TCP-Fenster, Verlust oder CPU pro Stream
TCP gut, UDP bei niedriger Rate schlecht Queue, Policing, Funk- oder UDP-spezifischer Pfad
UDP erst ab bestimmter Rate mit Verlust Kapazitäts- beziehungsweise Queuegrenze
Werte schwanken stark Funk, Last, Pfadwechsel oder konkurrierender Verkehr
Server- und Clientwerte unterscheiden sich Verlust beziehungsweise unvollständige Übertragung
Hohe Retransmissions Paketverlust, Überlastung oder fehlerhafter Link
Durchsatz exakt an einer Rate begrenzt Policer, Shaper, Vertrag oder Schnittstellenlimit
CPU nahe 100 Prozent Endsystem kann der Engpass sein
Datenträger langsam, iperf3 gut Speicher oder Anwendung statt Netzwerk

Ein iperf3-Test misst Arbeitsspeicher-zu-Arbeitsspeicher-Netzwerkleistung und nicht automatisch Datei-, Datenbank- oder Anwendungsleistung.

24. TCP-Wiederholungen und Zustände prüfen

Windows-TCP-Statistik:

[RO] netstat -s -p tcp

Windows-Verbindungen:

[RO] Get-NetTCPConnection |
    Format-Table LocalAddress, LocalPort, RemoteAddress,
                 RemotePort, State

Linux-TCP-Statistik:

[RO] nstat

Falls nstat nicht vorhanden ist:

[RO] netstat -s

Linux-Socketdiagnose:

[RO][SENS] ss -ti

macOS-TCP-Statistik:

[RO] netstat -s -p tcp

Zähler sind kumulativ und müssen über einen definierten Messzeitraum verglichen werden. Ein hoher Gesamtwert allein beweist kein aktuelles Problem.

25. Schnittstellenzähler und physische Fehler prüfen

Windows:

[RO] Get-NetAdapterStatistics |
    Format-Table Name, ReceivedBytes, SentBytes,
                 ReceivedDiscardedPackets, OutboundDiscardedPackets,
                 ReceivedPacketErrors, OutboundPacketErrors

Linux:

[RO] ip -s link

Linux – erweiterte Treiberstatistiken:

[RO][PRIV][SENS] sudo ethtool -S INTERFACE

macOS:

[RO] netstat -ib

[RO] ifconfig

Zu prüfen sind:

Entscheidend ist, ob Zähler während des reproduzierten Fehlers ansteigen.

26. Linkgeschwindigkeit und Duplex prüfen

Windows:

[RO] Get-NetAdapter |
    Format-Table Name, Status, LinkSpeed, MediaConnectionState

Linux:

[RO] ip link show INTERFACE

[RO][PRIV] sudo ethtool INTERFACE

macOS:

[RO] ifconfig INTERFACE

Abhängig vom Adapter können zusätzliche Informationen über networksetup oder system_profiler verfügbar sein.

Zu prüfen sind:

Ein Link mit 1 Gbit/s Anzeige beweist nicht, dass er fehlerfrei oder vollständig auslastbar ist.

27. Bufferbloat erkennen

Bufferbloat liegt vor, wenn Warteschlangen unter Last stark anwachsen und dadurch die Latenz deutlich steigt.

Typisches Verhalten:

Ping ohne Last:  10 ms
Ping unter Last: 300 ms
Paketverlust:    möglicherweise gering
Durchsatz:       hoch

Trotz hohen Durchsatzes reagieren Sprache, Spiele, Remote-Desktop und interaktive Anwendungen schlecht.

Testablauf:

  1. Kontinuierlichen Ping zum geeigneten Ziel starten.
  2. Basislatenz ohne Last dokumentieren.
  3. Kontrollierten iperf3-Test starten.
  4. Latenz während Downloadrichtung beobachten.
  5. Latenz während Uploadrichtung beobachten.
  6. Test stoppen.
  7. Erholung der Latenz dokumentieren.

Beispiel:

Terminal 1:

[TEST] ping ZIEL_IP

Terminal 2:

[TEST] iperf3 -c SERVER_IP -t 30

Anschließend:

[TEST] iperf3 -c SERVER_IP -R -t 30

Eine Optimierung kann Queue Management oder Traffic Shaping erfordern. Solche Änderungen müssen am tatsächlichen Engpass und nicht willkürlich am Client erfolgen.

28. QoS, Shaping und Policing berücksichtigen
Funktion Wirkung
Classification Verkehr wird einer Klasse zugeordnet
Marking Pakete erhalten beispielsweise eine DSCP-Markierung
Queuing Pakete werden in Warteschlangen eingeordnet
Scheduling Reihenfolge der Übertragung wird bestimmt
Shaping Datenrate wird durch Puffern geglättet
Policing Überschreitender Verkehr wird verworfen oder neu markiert
Rate Limit Datenrate wird begrenzt
Priorisierung Bestimmte Klassen werden bevorzugt behandelt

Typische Symptome einer Richtlinie:

QoS ist kein Ersatz für ausreichende Kapazität. Eine Priorisierung kann wichtige Anwendungen schützen, erzeugt aber keine zusätzliche Bandbreite.

29. Server und Client als Engpass ausschließen

Während des Netzwerktests sind auf beiden Endsystemen zu prüfen:

Windows:

[RO] Get-Counter '\Processor(_Total)\% Processor Time'

[RO] Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 10

Linux:

[RO] uptime

[RO] top

macOS:

[RO] top -l 1

Ein Durchsatztest kann durch die Rechenleistung eines virtuellen oder kleinen Systems begrenzt werden, obwohl das Netzwerk höhere Kapazität besitzt.

30. Dateiübertragung nicht als alleinigen Netzwerktest verwenden

Eine Dateiübertragung misst gleichzeitig:

Quelldatenträger
+ Dateisystem
+ Serverdienst
+ Protokoll
+ Netzwerk
+ Sicherheitsprüfung
+ Zieldatenträger

Mögliche nicht netzwerkbezogene Engpässe:

Empfohlene Trennung:

iperf3 gut
Dateikopie langsam
→ Speicher, Dateidienst oder Anwendung weiter prüfen
31. MTU und große Pakete prüfen

Windows mit Don't-Fragment-Bit:

[TEST] ping -4 -f -l 1400 ZIEL_IP

Linux:

[TEST] ping -4 -M do -s 1400 ZIEL_IP

macOS:

[TEST] ping -D -s 1400 ZIEL_IP

MTU anzeigen:

Betriebssystem Befehl
Windows [RO] Get-NetIPInterface
Linux [RO] ip link show
macOS [RO] ifconfig

Die Ping-Nutzdatenlänge ist nicht mit der gesamten IP-Paketgröße identisch. Header müssen zusätzlich berücksichtigt werden.

Typische MTU-Symptome:

32. Paketmitschnitt zur Leistungsanalyse verwenden

Linux:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \
    'host ZIEL_IP' \
    -w performance-test.pcap

macOS:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \
    'host ZIEL_IP' \
    -w performance-test.pcap

Windows mit Dumpcap – Schnittstellen ermitteln:

[RO] dumpcap -D

Mitschnitt:

[TEST][PRIV][FILE][SENS] dumpcap -i 1 `
    -f "host ZIEL_IP" `
    -w performance-test.pcapng

Paketmitschnitte können vertrauliche Nutzdaten und Metadaten enthalten. Aufzeichnungsdauer und Filter sollten auf den benötigten Umfang begrenzt werden.

33. Wireshark-Filter für Leistungsprobleme
Aufgabe Anzeigefilter
Verkehr zu einer IPv4-Adresse ip.addr == 192.0.2.20
Verkehr zu einer IPv6-Adresse ipv6.addr == 2001:db8::20
TCP-Wiederholungen tcp.analysis.retransmission
Schnelle Wiederholungen tcp.analysis.fast_retransmission
Vermutete verlorene Segmente tcp.analysis.lost_segment
Doppelte ACKs tcp.analysis.duplicate_ack
Out-of-Order tcp.analysis.out_of_order
Zero Window tcp.analysis.zero_window
Window Full tcp.analysis.window_full
TCP-Reset tcp.flags.reset == 1
ICMP icmp
ICMPv6 icmpv6
DNS-Antwortzeit dns.time
TCP-Verbindungsaufbau `tcp.connection.syn

Wireshark-Analyseflags sind Schlussfolgerungen aus dem vorhandenen Mitschnitt. Fehlende Pakete am Messpunkt können falsche oder irreführende Markierungen erzeugen.

34. Einseitige und doppelseitige Mitschnitte unterscheiden

Einseitiger Mitschnitt:

zeigt nur Pakete am lokalen Messpunkt

Doppelseitiger Mitschnitt:

Clientmitschnitt
+
Servermitschnitt
+
synchronisierte Zeit

Dadurch lässt sich erkennen:

Für exakte Laufzeitvergleiche müssen die Uhren der Messsysteme ausreichend synchronisiert sein.

35. Zwischenhop-Verlust nicht falsch interpretieren

Beispiel:

Hop 1:  0 % Verlust
Hop 2: 60 % Verlust
Hop 3:  0 % Verlust
Ziel:   0 % Verlust

Hop 2 leitet den Verkehr offensichtlich weiter, antwortet aber nur eingeschränkt auf Diagnosepakete.

Wahrscheinlicher tatsächlicher Weiterleitungsverlust:

Hop 1:  0 % Verlust
Hop 2: 20 % Verlust
Hop 3: 20 % Verlust
Hop 4: 20 % Verlust
Ziel:  20 % Verlust

Auch dieses Muster muss mit weiteren Messungen bestätigt werden, da Pfadwechsel, Load Balancing und asymmetrische Routen Ergebnisse beeinflussen können.

36. Typische Fehlerbilder systematisch eingrenzen

Fall A – Latenz bereits zum Gateway hoch

Prüfen:

Fall B – Gateway gut, Internet schlecht

Prüfen:

Fall C – Durchsatz gut, Echtzeitanwendung schlecht

Prüfen:

Fall D – Download gut, Upload schlecht

Prüfen:

Fall E – Kleine Übertragungen funktionieren, große nicht

Prüfen:

Fall F – iperf3 gut, Dateikopie langsam

Prüfen:

Fall G – Nur zu Stoßzeiten schlecht

Prüfen:

Fall H – Nur ein TCP-Datenstrom langsam

Prüfen:

37. Keine unkontrollierten Lasttests durchführen

Nicht vorschnell:

Sicherer Testablauf:

  1. Testumfang genehmigen lassen.
  2. Quelle, Ziel und Pfad dokumentieren.
  3. Niedrige Last verwenden.
  4. Messdauer begrenzen.
  5. Überwachung parallel aktivieren.
  6. Last schrittweise erhöhen.
  7. Test bei negativen Auswirkungen sofort beenden.
  8. Hin- und Rückrichtung getrennt messen.
  9. Ergebnis samt Uhrzeit dokumentieren.
  10. Testdienste anschließend kontrolliert beenden.
38. Systematischer Diagnoseablauf
Schritt Prüfung Leitfrage
1 Problem konkretisieren Latenz, Jitter, Verlust oder Durchsatz?
2 Quelle und Ziel dokumentieren Welcher Datenpfad ist betroffen?
3 Schnittstellenstatus prüfen Stimmen Link, Geschwindigkeit und Fehlerzähler?
4 Lokales Gateway messen Beginnt das Problem bereits im Zugangsnetz?
5 Internen Server messen Ist das lokale LAN betroffen?
6 Externen Pfad messen Beginnt das Problem hinter dem Router?
7 IPv4 und IPv6 vergleichen Ist nur eine Adressfamilie betroffen?
8 Pfad ermitteln Welche Hops werden tatsächlich verwendet?
9 Hin- und Rückrichtung messen Ist das Problem asymmetrisch?
10 TCP-Durchsatz messen Welche Nutzrate erreicht ein Datenstrom?
11 UDP kontrolliert messen Wie entwickeln sich Jitter und Verlust?
12 Latenz unter Last prüfen Liegt Bufferbloat vor?
13 Schnittstellenzähler vergleichen Steigen Fehler oder Drops während des Tests?
14 Endsystemlast prüfen Begrenzen CPU oder Anwendung das Ergebnis?
15 MTU prüfen Scheitern nur größere Pakete?
16 Paketmitschnitt erstellen Sind Wiederholungen oder Zeitlücken sichtbar?
17 Vergleichssystem messen Ist das Ergebnis client- oder pfadspezifisch?
18 Ursache nachweisen Welche Messwerte belegen die Fehlerstelle?
19 Minimale Änderung planen Welche Korrektur behebt den Engpass?
20 Nachprüfung durchführen Verbessern sich alle relevanten Messgrößen?
39. Kompakte Befehlstabelle
Aufgabe Windows Linux macOS
Ping mit 20 Paketen [TEST] ping -n 20 ZIEL_IP [TEST] ping -c 20 ZIEL_IP [TEST] ping -c 20 ZIEL_IP
Standardgateway [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" [RO] ip route show default [RO] route -n get default
Route zum Ziel [RO] Find-NetRoute -RemoteIPAddress ZIEL_IP [RO] ip route get ZIEL_IP [RO] route -n get ZIEL_IP
Pfad ohne DNS [TEST] tracert -d ZIEL_IP [TEST] traceroute -n ZIEL_IP [TEST] traceroute -n ZIEL_IP
Pfad und Verlust [TEST] pathping /n ZIEL_IP Falls installiert: [TEST] mtr -n -r -c 100 ZIEL_IP Falls installiert: [TEST] mtr -n -r -c 100 ZIEL_IP
TCP-Porttest [TEST] Test-NetConnection HOST -Port PORT [TEST] nc -vz -w 5 HOST PORT [TEST] nc -vz -w 5 HOST PORT
TCP-Durchsatz [TEST] iperf3 -c SERVER_IP [TEST] iperf3 -c SERVER_IP [TEST] iperf3 -c SERVER_IP
Gegenrichtung [TEST] iperf3 -c SERVER_IP -R [TEST] iperf3 -c SERVER_IP -R [TEST] iperf3 -c SERVER_IP -R
UDP-Test [TEST] iperf3 -c SERVER_IP -u -b 10M [TEST] iperf3 -c SERVER_IP -u -b 10M [TEST] iperf3 -c SERVER_IP -u -b 10M
Schnittstellenzähler [RO] Get-NetAdapterStatistics [RO] ip -s link [RO] netstat -ib
Linkinformationen [RO] Get-NetAdapter [RO][PRIV] sudo ethtool INTERFACE [RO] ifconfig INTERFACE
TCP-Statistik [RO] netstat -s -p tcp [RO] nstat oder [RO] netstat -s [RO] netstat -s -p tcp
MTU [RO] Get-NetIPInterface [RO] ip link show [RO] ifconfig
DF-Test [TEST] ping -4 -f -l 1400 ZIEL_IP [TEST] ping -4 -M do -s 1400 ZIEL_IP [TEST] ping -D -s 1400 ZIEL_IP
HTTP-Zeiten [TEST][SENS] curl.exe -w ... URL [TEST][SENS] curl -w ... URL [TEST][SENS] curl -w ... URL

ZIEL_IP, HOST, PORT, SERVER_IP, INTERFACE und URL müssen durch die Werte des konkreten Störungsfalls ersetzt werden.

40. Dokumentationsvorlage für Leistungsprobleme 
Störung:
Zeitpunkt:
Zeitzone:
Standort:
Benutzer:
Client:
Betriebssystem:

Quellschnittstelle:
Quell-IP:
Linkgeschwindigkeit:
Duplex:
WLAN-SSID:
WLAN-BSSID:
WLAN-Signal:
VPN beteiligt:
Proxy beteiligt:

Zielhostname:
Ziel-IP:
Zielport:
Transportprotokoll:
IPv4 oder IPv6:
Erwarteter Datenpfad:
Gemessener Datenpfad:

Gateway-RRT Minimum:
Gateway-RRT Durchschnitt:
Gateway-RRT Maximum:
Gateway-Paketverlust:

Ziel-RTT Minimum:
Ziel-RTT Durchschnitt:
Ziel-RTT Maximum:
Ziel-Paketverlust:
Jitter:
Burst Loss:

iperf3 TCP Client zu Server:
iperf3 TCP Server zu Client:
iperf3 parallele Streams:
iperf3 UDP Zielrate:
iperf3 UDP empfangene Rate:
iperf3 UDP Jitter:
iperf3 UDP Verlust:

Latenz ohne Last:
Latenz unter Uploadlast:
Latenz unter Downloadlast:

RX-Fehler vorher:
RX-Fehler nachher:
TX-Fehler vorher:
TX-Fehler nachher:
Drops vorher:
Drops nachher:
TCP-Retransmissions:

Client-CPU:
Server-CPU:
Server-Datenträger:
Testdauer:
Anzahl der Messungen:
Vergleichssystem:
Vergleichszeitpunkt:

MTU:
Größte erfolgreiche DF-Nutzlast:
Paketmitschnitt:
Festgestellte Ursache:
Genehmigte Änderung:
Rückfallplan:
Ergebnis der Nachprüfung:
41. Kontrollfragen nach der Diagnose
42. Quellen und weiterführende Dokumentation
3. Netzwerkfehler systematisch analysieren

3.16 Paketmitschnitt mit Wireshark, tcpdump, Dumpcap und Pktmon

Ein Paketmitschnitt zeigt, welche Netzwerkpakete an einem bestimmten Messpunkt tatsächlich sichtbar sind. Damit lassen sich Vermutungen durch überprüfbare Beobachtungen ersetzen.

Ein Mitschnitt beantwortet jedoch nur Fragen über den gewählten Messpunkt. Ein dort fehlendes Paket kann bereits vorher verloren gegangen sein, während ein sichtbares Paket hinter dem Messpunkt weiterhin verworfen werden kann.

Die zentralen Fragen dieser Seite lauten:

Welcher Datenfluss muss untersucht werden, an welchem Punkt muss dafür aufgezeichnet werden und welches Paketmuster würde die jeweilige Hypothese bestätigen oder widerlegen?

1. Sicherheits- und Aktionskennzeichnungen
Kennzeichnung Bedeutung
[RO] Rein lesender Befehl, der normalerweise keine Konfiguration verändert
[TEST] Aktive Diagnose beziehungsweise Paketaufzeichnung
[PRIV] Administrator- oder Root-Rechte können erforderlich sein
[FILE] Der Befehl schreibt Ausgaben in eine Datei
[SENS] Die Ausgabe kann sensible Informationen enthalten
[CHANGE] Der Befehl verändert eine Konfiguration
[DISRUPT] Der Befehl kann eine Verbindung oder einen Dienst beeinträchtigen

Paketmitschnitte können enthalten:

Paketaufzeichnungen dürfen nur im genehmigten Umfang erstellt, gespeichert und weitergegeben werden.

2. Paketmitschnitt und Protokollierung unterscheiden
Datenquelle Inhalt
Paketmitschnitt Tatsächlich sichtbare Netzwerkframes beziehungsweise Pakete
Betriebssystemprotokoll Interpretation und Ereignisse des Betriebssystems
Firewallprotokoll Regelentscheidung wie Allow, Drop oder Reject
Anwendungsprotokoll Verarbeitung innerhalb der Anwendung
Proxyprotokoll Client-, Ziel-, Backend- und HTTP-Informationen
Switchzähler Fehler, Drops, Auslastung und Portstatus
Controllerprotokoll WLAN-, VPN- oder Infrastrukturereignisse
Flow-Daten Zusammengefasste Informationen über Netzwerkflüsse
SNMP-Messwert Zähler und Status eines Netzwerkgeräts

Ein Paketmitschnitt zeigt nicht automatisch:

Die beste Diagnose kombiniert Paketmitschnitt, Systemprotokoll und Anwendungsergebnis.

3. Datenfluss vor der Aufzeichnung definieren

Vor dem Start müssen mindestens diese Angaben bekannt sein:

Clienthostname:
Client-IP-Adresse:
Serverhostname:
Server-IP-Adresse:
Transportprotokoll:
Clientport:
Serverport:
Anwendungsprotokoll:
IPv4 oder IPv6:
Startzeitpunkt:
Fehlerauslöser:
Erwartetes Paketmuster:

Beispiel:

Client:       192.0.2.25
Server:       192.0.2.53
Transport:    TCP
Serverport:   443
Anwendung:    HTTPS
Fehler:       Verbindung läuft in einen Timeout

Passender enger Filter:

host 192.0.2.25 and host 192.0.2.53 and tcp port 443

Ein enger Filter reduziert Datenmenge und Datenschutzrisiko. Er kann jedoch wichtige Begleitprotokolle wie DNS, ARP, ICMP oder ICMPv6 ausblenden.

4. Den richtigen Messpunkt auswählen 
Client
  ↓
Access Point oder Switch
  ↓
Router beziehungsweise Firewall
  ↓
VPN oder WAN
  ↓
Servernetz
  ↓
Server
  ↓
Anwendung

Mögliche Messpunkte:

Leitfrage:

Welche Netzwerkkomponente baut die betroffene Verbindung tatsächlich auf?

Bei einem Reverse Proxy ist der Administrator-PC nicht der richtige Messpunkt für die Verbindung zwischen Proxy und Backend.

5. Einseitigen und doppelseitigen Mitschnitt unterscheiden

Einseitiger Mitschnitt:

Clientmitschnitt

Er zeigt nur, was am Client sichtbar ist.

Doppelseitiger Mitschnitt:

Clientmitschnitt
+
Servermitschnitt
+
synchronisierte Zeit

Damit lässt sich feststellen:

Bei komplexen Problemen ist ein gleichzeitiger Mitschnitt an beiden Endpunkten wesentlich aussagekräftiger.

6. Zeit und Zeitzone synchronisieren

Für den Vergleich mehrerer Mitschnitte und Protokolle müssen Zeit und Zeitzone bekannt sein.

Betriebssystem Lokale Zeit
Windows [RO] Get-Date -Format o
Linux [RO] date --iso-8601=seconds
macOS [RO] date "+%Y-%m-%dT%H:%M:%S%z"

UTC-Zeit:

Windows:

[RO] (Get-Date).ToUniversalTime().ToString("o")

Linux und macOS:

[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"

Zu dokumentieren sind:

Eine Zeitabweichung von wenigen Sekunden kann die Zuordnung kurzer Verbindungsversuche erheblich erschweren.

7. Aufzeichnungsschnittstelle eindeutig bestimmen

Windows mit Dumpcap:

[RO] dumpcap -D

Windows-Netzwerkadapter:

[RO] Get-NetAdapter -IncludeHidden |
    Format-Table Name, InterfaceDescription, Status, MacAddress

Linux:

[RO] ip -br link

[RO] tcpdump -D

macOS:

[RO] networksetup -listallhardwareports

[RO] ifconfig

[RO] tcpdump -D

Zu prüfen sind:

Route zum Ziel:

Betriebssystem Befehl
Windows [RO] Find-NetRoute -RemoteIPAddress ZIEL_IP
Linux [RO] ip route get ZIEL_IP
macOS [RO] route -n get ZIEL_IP
8. Besonderheiten der Schnittstelle any unter Linux

Mit any kann tcpdump gleichzeitig auf mehreren Linux-Schnittstellen aufzeichnen:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i any -nn \
    -w capture.pcap

Vorteile:

Einschränkungen:

Für eine präzise Layer-2-Analyse sollte möglichst die konkrete Schnittstelle gewählt werden.

9. Promiscuous Mode und WLAN Monitor Mode unterscheiden

Promiscuous Mode:

Eine Ethernet-Schnittstelle nimmt zusätzlich Frames an, die nicht direkt an ihre eigene MAC-Adresse adressiert sind. In einem geswitchten Netzwerk werden dadurch jedoch nicht automatisch alle Frames anderer Switchports sichtbar.

WLAN Monitor Mode:

Ein geeigneter WLAN-Adapter erfasst 802.11-Funkframes auf einem bestimmten Kanal beziehungsweise Frequenzbereich.

Modus Typische Verwendung
Normaler WLAN-Clientmodus Verkehr des eigenen Clients untersuchen
Promiscuous Mode Zusätzliche sichtbare Ethernetframes erfassen
Monitor Mode WLAN-Management-, Kontroll- und Datenframes untersuchen
Switch Port Mirroring Verkehr ausgewählter Switchports oder VLANs spiegeln
Network TAP Physischer Messpunkt in einer Verbindung

Monitor Mode kann die normale WLAN-Verbindung unterbrechen und wird nicht von jeder Hardware, jedem Treiber oder Betriebssystem unterstützt.

10. Grenzen eines Mitschnitts im geswitchten Netzwerk

Ein Client an einem Switchport sieht normalerweise:

Er sieht normalerweise nicht automatisch:

Für fremden Unicastverkehr sind abhängig von Infrastruktur und Berechtigung erforderlich:

Ein falsch konfigurierter Mirror-Port kann Pakete verlieren, wenn die gespiegelte Datenmenge seine Kapazität überschreitet.

11. Capture Filter und Display Filter unterscheiden
Filterart Zeitpunkt Wirkung
Capture Filter während der Aufzeichnung Nur passende Pakete werden gespeichert
Display Filter nach beziehungsweise während der Anzeige Alle gespeicherten Pakete bleiben erhalten, nur die Ansicht wird gefiltert

Capture Filter:

host 192.0.2.20 and tcp port 443

Wireshark Display Filter:

ip.addr == 192.0.2.20 && tcp.port == 443

Die Syntax ist nicht austauschbar.

Grundentscheidung:

12. Wichtige Capture Filter
Aufgabe Capture Filter
Einzelner Host host 192.0.2.20
Quelle src host 192.0.2.20
Ziel dst host 192.0.2.20
Zwei Hosts host 192.0.2.20 and host 192.0.2.53
Gesamtes IPv4-Netz net 192.0.2.0/24
TCP tcp
UDP udp
ICMP icmp
ICMPv6 icmp6
TCP-Port 443 tcp port 443
UDP-Port 53 udp port 53
Quellport src port 443
Zielport dst port 443
DNS über TCP oder UDP port 53
DHCPv4 udp port 67 or udp port 68
DHCPv6 udp port 546 or udp port 547
ARP arp
Host und Port host 192.0.2.20 and tcp port 443
Zwei Ports tcp port 80 or tcp port 443
Verkehr ohne SSH not tcp port 22

Capture Filter verwenden die Syntax der Paketfilterbibliothek. Vor produktiven Aufzeichnungen sollte die lokale Unterstützung geprüft werden.

13. Wichtige Wireshark Display Filter
Aufgabe Display Filter
IPv4-Adresse ip.addr == 192.0.2.20
IPv6-Adresse ipv6.addr == 2001:db8::20
Zwei IPv4-Systeme ip.addr == 192.0.2.20 && ip.addr == 192.0.2.53
TCP-Port tcp.port == 443
UDP-Port udp.port == 53
DNS dns
DHCPv4 dhcp
DHCPv6 dhcpv6
ARP arp
ICMP icmp
ICMPv6 icmpv6
HTTP-Anfragen http.request
HTTP-Antworten http.response
HTTP-Status 502 http.response.code == 502
TLS-Handshake tls.handshake
TCP-SYN tcp.flags.syn == 1
Erstes SYN ohne ACK tcp.flags.syn == 1 && tcp.flags.ack == 0
TCP-Reset tcp.flags.reset == 1
TCP-FIN tcp.flags.fin == 1
Wiederholungen tcp.analysis.retransmission
Doppelte ACKs tcp.analysis.duplicate_ack
Out-of-Order tcp.analysis.out_of_order
Zero Window tcp.analysis.zero_window
Vermutetes verlorenes Segment tcp.analysis.lost_segment
14. Linux mit tcpdump aufzeichnen

Alle Pakete einer Schnittstelle:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \
    -w capture.pcap

Nur definierter Client und TCP-Port 443:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \
    'host 192.0.2.25 and tcp port 443' \
    -w https-test.pcap

DNS-Verkehr:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \
    'port 53' \
    -w dns-test.pcap

DHCPv4:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \
    'udp port 67 or udp port 68' \
    -w dhcp-test.pcap

Ohne Datei, direkt lesbar:

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn \
    'host 192.0.2.25 and tcp port 443'

-nn verhindert die Auflösung von Hostnamen und Dienstnamen. Dadurch wird die Ausgabe schneller und eindeutiger.

15. macOS mit tcpdump aufzeichnen

Zuerst die tatsächliche Schnittstelle ermitteln:

[RO] networksetup -listallhardwareports

Beispiel für Ethernet oder WLAN auf en0:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i en0 -nn \
    'host 192.0.2.25 and tcp port 443' \
    -w https-test.pcap

DNS-Verkehr:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i en0 -nn \
    'port 53' \
    -w dns-test.pcap

VPN-Tunnel untersuchen:

[RO] ifconfig

Anschließend die tatsächlich ermittelte Tunnelschnittstelle verwenden:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i TUNNEL_INTERFACE -nn \
    'host INTERNES_ZIEL' \
    -w vpn-inner.pcap

Schnittstellennamen wie en0 oder utun0 dürfen nicht ohne vorherige Prüfung vorausgesetzt werden.

16. Windows mit Dumpcap aufzeichnen

Dumpcap ist Bestandteil einer Wireshark-Installation und kann ohne grafische Oberfläche aufzeichnen.

Schnittstellen anzeigen:

[RO] dumpcap -D

Auf Schnittstelle 1 aufzeichnen:

[TEST][PRIV][FILE][SENS] dumpcap -i 1 `
    -w capture.pcapng

Mit Capture Filter:

[TEST][PRIV][FILE][SENS] dumpcap -i 1 `
    -f "host 192.0.2.25 and tcp port 443" `
    -w https-test.pcapng

Aufzeichnung nach 60 Sekunden beenden:

[TEST][PRIV][FILE][SENS] dumpcap -i 1 `
    -a duration:60 `
    -w capture-60s.pcapng

Die Schnittstellennummer 1 ist nur ein Beispiel und muss vorher mit dumpcap -D ermittelt werden.

17. Windows mit Pktmon aufzeichnen

Pktmon ist ein in Windows integriertes Diagnosewerkzeug. Es kann Pakete an mehreren Stellen innerhalb des Windows-Netzwerkstacks erfassen und verworfene Pakete erkennen.

Vor Verwendung lokale Syntax prüfen:

[RO] pktmon help

Aktuellen Status anzeigen:

[RO][PRIV] pktmon status

Netzwerkkomponenten anzeigen:

[RO][PRIV][SENS] pktmon list

Aufzeichnung in eine ETL-Datei starten:

[TEST][PRIV][FILE][SENS] pktmon start --capture --pkt-size 0 --file-name pktmon.etl

Fehler reproduzieren und Aufzeichnung beenden:

[TEST][PRIV][FILE][SENS] pktmon stop

ETL nach PCAPNG konvertieren:

[RO][FILE][SENS] pktmon etl2pcap pktmon.etl --out pktmon.pcapng

Pktmon-Optionen können sich zwischen unterstützten Windows-Versionen unterscheiden. Vor einer produktiven Aufzeichnung müssen die lokale Hilfe und der geplante Umfang geprüft werden.

18. Pktmon-Drop-Erkennung richtig behandeln

Pktmon kann zusätzlich Informationen über innerhalb des Windows-Netzwerkstacks verworfene Pakete erfassen.

Pktmon-Zähler anzeigen:

[RO][PRIV][SENS] pktmon counters

Nur als verworfen markierte Pakete konvertieren:

[RO][FILE][SENS] pktmon etl2pcap pktmon.etl ^
    --drop-only ^
    --out pktmon-drops.pcapng

Microsoft weist darauf hin, dass bei der PCAPNG-Konvertierung bestimmte Pktmon-Metadaten verloren gehen können. PCAPNG unterscheidet danach nicht automatisch zwischen regulär weitergeleiteten und verworfenen Paketen.

Deshalb sollten bei Bedarf getrennte Dateien erzeugt werden:

vollständige Aufzeichnung
+
separate Drop-Aufzeichnung
+
ursprüngliche ETL-Datei

Die ursprüngliche ETL-Datei muss geschützt aufbewahrt werden, wenn die zusätzlichen Pktmon-Informationen für die Diagnose benötigt werden.

19. Ringspeicher mit Dumpcap verwenden

Eine unbegrenzte Aufzeichnung kann den Datenträger füllen. Dumpcap unterstützt Ringspeicher mit mehreren Dateien.

Datei alle fünf Minuten wechseln und maximal zwölf Dateien behalten:

[TEST][PRIV][FILE][SENS] dumpcap -i 1 `
    -b duration:300 `
    -b files:12 `
    -w ringbuffer.pcapng

Zusätzlich Capture Filter verwenden:

[TEST][PRIV][FILE][SENS] dumpcap -i 1 `
    -f "host 192.0.2.25" `
    -b duration:300 `
    -b files:12 `
    -w ringbuffer.pcapng

Damit werden ungefähr die letzten 60 Minuten in zwölf Fünf-Minuten-Dateien gehalten. Dateiverarbeitung und Wechselverhalten müssen mit der installierten Dumpcap-Version geprüft werden.

20. Größenbegrenzten Ringspeicher mit tcpdump verwenden

Datei nach ungefähr 100 Millionen Byte wechseln und maximal zehn Dateien verwenden:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \
    -C 100 \
    -W 10 \
    -w capture.pcap

Mit Filter:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \
    'host 192.0.2.25' \
    -C 100 \
    -W 10 \
    -w capture.pcap

Die genaue Dateibenennung und Rotation hängt von der installierten tcpdump-Version ab. Vor einer Langzeitaufzeichnung lokale Hilfe prüfen:

[RO] tcpdump --help

oder:

[RO] man tcpdump
21. Capture-Länge und vollständige Pakete berücksichtigen

Die Capture-Länge bestimmt, wie viele Byte eines Pakets gespeichert werden.

tcpdump – vollständige Pakete anfordern:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \
    -s 0 \
    -w capture.pcap

Bei aktuellen tcpdump-Versionen bedeutet -s 0, dass die vom Werkzeug unterstützte maximale Paketlänge erfasst wird.

Abwägung:

Kurze Capture-Länge Vollständige Pakete
weniger Speicherbedarf höhere Datenmenge
geringeres Datenschutzrisiko mehr Protokolldetails
Nutzdaten möglicherweise abgeschnitten Nutzdaten möglicherweise vollständig enthalten
Headeranalyse häufig möglich Anwendungsanalyse eher möglich

Für eine reine Headeranalyse sollte geprüft werden, ob eine begrenzte Capture-Länge ausreicht.

22. tcpdump-Datei nachträglich lesen

PCAP-Datei ohne Namensauflösung anzeigen:

[RO][SENS] tcpdump -nn -r capture.pcap

Nur TCP-Port 443 aus einer vorhandenen Datei anzeigen:

[RO][SENS] tcpdump -nn -r capture.pcap \
    'tcp port 443'

Zeitstempel ausführlicher anzeigen:

[RO][SENS] tcpdump -tttt -nn -r capture.pcap

Das nachträgliche Filter verändert die Originaldatei nicht.

23. TShark für automatisierte Auswertung verwenden

TShark ist die Kommandozeilenversion der Wireshark-Protokollanalyse.

Schnittstellen anzeigen:

[RO] tshark -D

Vorhandene Datei lesen:

[RO][SENS] tshark -r capture.pcapng

Display Filter anwenden:

[RO][SENS] tshark -r capture.pcapng \
    -Y 'tcp.port == 443'

DNS-Anfragen ausgeben:

[RO][SENS] tshark -r capture.pcapng \
    -Y 'dns.flags.response == 0' \
    -T fields \
    -e frame.time \
    -e ip.src \
    -e dns.qry.name

TCP-Wiederholungen ausgeben:

[RO][SENS] tshark -r capture.pcapng \
    -Y 'tcp.analysis.retransmission'

HTTP-Statuscodes:

[RO][SENS] tshark -r capture.pcapng \
    -Y 'http.response' \
    -T fields \
    -e frame.time \
    -e ip.src \
    -e ip.dst \
    -e http.response.code
24. Capture Filter und Display Filter bei TShark verwenden

Capture Filter während der Aufzeichnung:

[TEST][PRIV][FILE][SENS] tshark -i INTERFACE \
    -f 'host 192.0.2.25 and tcp port 443' \
    -w capture.pcapng

Display Filter auf vorhandener Datei:

[RO][SENS] tshark -r capture.pcapng \
    -Y 'ip.addr == 192.0.2.25 && tcp.port == 443'

Zuordnung:

-f = Capture Filter
-Y = Display Filter

Ein Display Filter kann nicht als Capture Filter übernommen werden, wenn er eine Wireshark-spezifische Syntax verwendet.

25. Dateien mit capinfos untersuchen

capinfos gehört zur Wireshark-Werkzeugsammlung.

Grundinformationen:

[RO][SENS] capinfos capture.pcapng

Mögliche Angaben:

Mehrere Dateien vergleichen:

[RO][SENS] capinfos client.pcapng server.pcapng

Damit lassen sich unter anderem Zeitbereiche und Größen vor einer Zusammenführung kontrollieren.

26. Mitschnitte mit mergecap zusammenführen

mergecap führt mehrere Capture-Dateien in eine neue Datei zusammen.

[RO][FILE][SENS] mergecap \
    -w combined.pcapng \
    client.pcapng \
    server.pcapng

Vorher müssen geprüft werden:

Eine zusammengeführte Datei kann dasselbe Paket mehrfach enthalten, wenn es an mehreren Messpunkten erfasst wurde.

27. Mitschnitte mit editcap begrenzen

editcap kann Capture-Dateien bearbeiten, aufteilen oder zeitlich begrenzen.

Lokale Hilfe:

[RO] editcap --help

Erste 1.000 Pakete in neue Datei schreiben:

[RO][FILE][SENS] editcap -r capture.pcapng \
    capture-first-1000.pcapng \
    1-1000

Datei in Paketeinheiten aufteilen:

[RO][FILE][SENS] editcap -c 10000 \
    capture.pcapng \
    capture-part.pcapng

Vor dem Bearbeiten muss die Originaldatei unverändert aufbewahrt werden. Eine verkleinerte Datei kann für die Weitergabe sinnvoll sein, entfernt aber nicht automatisch alle sensiblen Inhalte.

28. Paketnamen und Frame-Nummern richtig verwenden

In Wireshark sind wichtige Spalten:

Spalte Bedeutung
No. Frame-Nummer innerhalb der geöffneten Datei
Time Zeitstempel beziehungsweise relative Zeit
Source Quelladresse
Destination Zieladresse
Protocol erkannter Protokolldissektor
Length Frame- beziehungsweise Paketlänge
Info zusammengefasste Protokollinformation

Wichtig: Frame-Nummern gelten nur innerhalb der konkreten Datei. Nach Filterung, Zusammenführung oder Bearbeitung können sich Nummern ändern.

Für eine belastbare Dokumentation zusätzlich angeben:

29. Wireshark Follow Stream verwenden

Wireshark kann zusammengehörige Datenströme darstellen:

Damit lassen sich beispielsweise betrachten:

Sicherheitswarnung: Follow Stream kann vollständige unverschlüsselte Anwendungsdaten und Zugangsinformationen anzeigen. Inhalte dürfen nicht ungeprüft kopiert oder weitergegeben werden.

30. TCP-Handshake analysieren

Erfolgreicher Verbindungsaufbau:

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

Wireshark-Filter:

tcp.flags.syn == 1

Nur erste SYN-Pakete:

tcp.flags.syn == 1 && tcp.flags.ack == 0
Paketmuster Typische Interpretation
SYN, SYN-ACK, ACK TCP-Verbindung aufgebaut
Wiederholte SYN ohne Antwort Drop, Verlust, falscher Rückweg oder Ziel nicht erreichbar
SYN gefolgt von RST/ACK Ziel erreichbar, Port geschlossen oder aktiv abgelehnt
SYN-ACK erreicht Client, ACK fehlt Clientseite oder Rückweg des ACK prüfen
Handshake erfolgreich, danach RST Anwendung, Proxy oder Sicherheitskomponente beendet Verbindung
Handshake erfolgreich, keine Nutzdaten Anwendung wartet oder Protokollablauf fehlerhaft
31. TCP-Verbindungsabbau analysieren

Ein regulärer TCP-Abbau verwendet FIN- und ACK-Segmente. Ein RST beendet eine Verbindung unmittelbar.

Filter:

tcp.flags.fin == 1 || tcp.flags.reset == 1
Beobachtung Mögliche Bedeutung
FIN/ACK-Austausch geordneter Verbindungsabbau
RST vom Client Clientanwendung oder lokales System bricht ab
RST vom Server Serveranwendung oder Serverstack bricht ab
RST von unbekannter Zwischenadresse Firewall, Proxy oder anderes Zwischensystem möglich
FIN nach Anwendungserfolg häufig normal
RST direkt nach TLS-Start TLS-, Richtlinien- oder Protokollproblem möglich

Die Quelladresse eines RST allein beweist nicht immer seine tatsächliche Herkunft, da Sicherheitsgeräte Pakete im Namen eines Endpunkts erzeugen können.

32. TCP-Wiederholungen vorsichtig interpretieren

Filter:

tcp.analysis.retransmission

Weitere Filter:

tcp.analysis.fast_retransmission
tcp.analysis.spurious_retransmission
tcp.analysis.duplicate_ack
tcp.analysis.out_of_order
tcp.analysis.lost_segment

Mögliche Ursachen:

Wireshark-Analyseflags sind Interpretationen. Sie müssen mit Sequenznummern, ACKs und möglichst einem Mitschnitt der Gegenstelle überprüft werden.

33. NIC-Offloading und ungewöhnliche Paketgrößen berücksichtigen

Netzwerkadapter und Betriebssysteme können Verarbeitung auslagern:

Dadurch können lokale Mitschnitte zeigen:

Typischer Hinweis:

Checksum incorrect

direkt auf dem sendenden Host bedeutet nicht automatisch, dass das Paket mit falscher Prüfsumme auf dem Netzwerk übertragen wurde. Die Netzwerkkarte kann die Prüfsumme erst nach dem lokalen Capture-Punkt berechnen.

Ein Mitschnitt auf der Gegenstelle oder einem externen TAP zeigt eher den tatsächlich übertragenen Zustand.

34. ARP und IPv6 Neighbor Discovery analysieren

ARP-Filter:

arp

Typischer IPv4-Ablauf:

Who has 192.0.2.1?
192.0.2.1 is at 00:11:22:33:44:55

Zu prüfen sind:

IPv6 Neighbor Discovery:

icmpv6

Zu prüfen sind unter anderem:

ICMPv6 darf nicht pauschal als unwichtiger Diagnoseverkehr betrachtet werden.

35. DHCPv4-Ablauf analysieren

Capture Filter:

udp port 67 or udp port 68

Display Filter:

dhcp

Typischer Ablauf:

DHCP Discover
DHCP Offer
DHCP Request
DHCP ACK

Bekannt als:

DORA
Fehlendes Paket Mögliche Eingrenzung
Kein Discover sichtbar Client oder falsche Schnittstelle prüfen
Discover, kein Offer DHCP-Server, Relay, VLAN oder Filter prüfen
Offer sichtbar, Client fordert nicht an Client, Auswahl oder fehlerhaftes Angebot
Request, kein ACK Server, Adresspool, Richtlinie oder Relay
DHCP NAK Adresse oder Netzzuordnung wird abgelehnt
Mehrere unterschiedliche Offers mehrere DHCP-Server vorhanden
36. DNS-Ablauf analysieren

Capture Filter:

port 53

Display Filter:

dns

Nur DNS-Anfragen:

dns.flags.response == 0

Nur DNS-Antworten:

dns.flags.response == 1

Bestimmter Name:

dns.qry.name == "service.example.internal"

Zu prüfen sind:

Typische Antwortcodes:

Code Bedeutung
NOERROR Anfrage wurde ohne DNS-Fehler verarbeitet
NXDOMAIN Name existiert laut Antwort nicht
SERVFAIL Resolver konnte Anfrage nicht erfolgreich bearbeiten
REFUSED Server verweigert die Anfrage
37. TLS-Handshake analysieren

Filter:

tls.handshake

Typischer Ablauf kann enthalten:

Client Hello
Server Hello
Certificate
Schlüsselaustausch
Finished
Application Data

Zu prüfen sind:

TLS-Alerts:

tls.alert_message

Verschlüsselte Anwendungsdaten können ohne zulässige Sitzungsschlüssel nicht inhaltlich analysiert werden. Private Server-Schlüssel sind bei modernen Verfahren nicht automatisch ausreichend, um aufgezeichnete Sitzungen nachträglich zu entschlüsseln.

38. HTTP- und Proxyfehler analysieren

HTTP-Anfragen:

http.request

HTTP-Antworten:

http.response

Statuscode:

http.response.code

Proxy-CONNECT:

http.request.method == "CONNECT"

Zu prüfen sind:

Bei HTTPS sind HTTP-Inhalte normalerweise verschlüsselt. Sichtbar bleiben abhängig vom Verfahren unter anderem IP-Adressen, Ports, TLS-Handshake und teilweise Servername.

39. ICMP- und ICMPv6-Fehler auswerten

Filter:

icmp || icmpv6

Mögliche Meldungen:

Diese Meldungen enthalten häufig Teile des ursprünglichen Pakets. Dadurch kann festgestellt werden, welche Verbindung die Fehlermeldung ausgelöst hat.

ICMP-Fehlermeldungen sind wichtige Bestandteile der Netzwerkfunktion und nicht nur Ping-Antworten.

40. NAT-, Proxy- und Containerpfade vergleichen

Vor NAT:

192.168.10.25:53144 → 198.51.100.20:443

Nach SNAT:

203.0.113.10:62001 → 198.51.100.20:443

Vor DNAT:

198.51.100.25:54000 → 203.0.113.10:8443

Nach DNAT:

198.51.100.25:54000 → 192.168.10.50:443

Für die Zuordnung werden benötigt:

Auf Containerhosts kann derselbe Datenfluss an Host-, Bridge- und Containerinterface mehrfach erscheinen.

41. Virtuelle Maschinen und Container richtig erfassen

Mögliche Messpunkte:

physischer Host
virtueller Switch
VM-Schnittstelle
Container-Bridge
Container-Netzwerk-Namespace
Anwendungscontainer

Zu prüfen sind:

Ein Mitschnitt auf dem Administrator-PC beantwortet keine Frage über eine interne Container-zu-Container-Verbindung.

42. Verschlüsselung und ihre Analysegrenzen

Verschlüsselte Protokolle schützen die Nutzdaten:

Ohne zulässige Entschlüsselungsinformationen sind häufig trotzdem sichtbar:

Nicht durchführen:

43. Fehler bei der Aufzeichnung selbst erkennen

Ein Capture-System kann Pakete verlieren.

Mögliche Ursachen:

Wireshark, Dumpcap oder tcpdump können Informationen über vom Capture-Prozess verworfene Pakete ausgeben.

Wichtig:

Im Mitschnitt fehlend
≠
sicher im Netzwerk verloren

Das Paket kann lediglich vom Messsystem nicht gespeichert worden sein.

44. Aussagekräftige Dateinamen verwenden

Empfohlenes Schema:

DATUM_UHRZEIT_MESSPUNKT_QUELLE_ZIEL_PROTOKOLL.pcapng

Beispiel:

2026-07-31_143500_client01_web01_https.pcapng

Keine sensiblen Benutzernamen oder vollständigen personenbezogenen Angaben in Dateinamen verwenden.

Zusätzlich eine Textnotiz anlegen:

Dateiname:
Messpunkt:
Schnittstelle:
Capture Filter:
Startzeit:
Fehlerzeit:
Endzeit:
Client:
Server:
Testhandlung:
Zeitzone:
Bearbeiter:
45. Sichere Aufbewahrung und Weitergabe

Vor einer Weitergabe:

  1. Originaldatei geschützt aufbewahren.
  2. Nur relevanten Zeitbereich extrahieren.
  3. Nur benötigte Pakete übernehmen.
  4. Nutzdaten auf sensible Inhalte prüfen.
  5. DNS-Namen, Adressen und Identitäten bewerten.
  6. Unternehmensrichtlinien beachten.
  7. Empfänger und Übertragungsweg festlegen.
  8. Aufbewahrungsfrist dokumentieren.
  9. Nicht mehr benötigte Kopien kontrolliert löschen.

Eine PCAP-Datei ist kein harmloser Screenshot. Sie kann vollständige Kommunikationsinhalte enthalten.

46. Systematischer Ablauf einer Paketaufzeichnung
Schritt Aufgabe Leitfrage
1 Fehlerhypothese formulieren Welches Paketmuster wird erwartet?
2 Datenfluss dokumentieren Welche Quelle kommuniziert mit welchem Ziel?
3 Messpunkt auswählen Wo muss das Paket sichtbar sein?
4 Schnittstelle bestimmen Über welches Interface führt die Route?
5 Zeit synchronisieren Können mehrere Datenquellen verglichen werden?
6 Datenschutzumfang festlegen Welche Daten dürfen aufgezeichnet werden?
7 Capture Filter wählen Welche Pakete werden wirklich benötigt?
8 Speicherbegrenzung planen Dauer, Größe oder Ringspeicher?
9 Aufzeichnung starten Läuft sie auf der richtigen Schnittstelle?
10 Fehler einmal reproduzieren Ist der Zeitpunkt exakt dokumentiert?
11 Aufzeichnung beenden Wurde unnötige weitere Erfassung vermieden?
12 Capture-Verluste prüfen Hat das Messsystem Pakete verworfen?
13 Display Filter anwenden Welcher einzelne Datenfluss ist relevant?
14 Protokollablauf untersuchen Wo weicht Ist vom Soll ab?
15 Gegenstelle vergleichen Ist Verlust oder Verzögerung lokalisierbar?
16 Systemprotokolle abgleichen Warum wurde das Paket abgelehnt?
17 Ergebnis dokumentieren Welche Frames belegen die Ursache?
18 Daten sichern oder bereinigen Welche Aufbewahrung ist erforderlich?
47. Kompakte Befehlstabelle
Aufgabe Windows Linux macOS
Schnittstellen anzeigen [RO] dumpcap -D [RO] tcpdump -D [RO] tcpdump -D
Route zum Ziel [RO] Find-NetRoute -RemoteIPAddress IP [RO] ip route get IP [RO] route -n get IP
Gesamte Aufzeichnung [TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -w capture.pcapng [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -w capture.pcap [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -w capture.pcap
Hostfilter [TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -f "host IP" -w host.pcapng [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn 'host IP' -w host.pcap [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn 'host IP' -w host.pcap
Portfilter [TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -f "tcp port 443" -w https.pcapng [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn 'tcp port 443' -w https.pcap [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn 'tcp port 443' -w https.pcap
60 Sekunden [TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -a duration:60 -w test.pcapng [TEST][PRIV][FILE][SENS] timeout 60 sudo tcpdump -i INTERFACE -nn -w test.pcap – Verfügbarkeit von timeout prüfen Beendigung kontrolliert per Tastatur oder Werkzeugoption planen
Ringspeicher [TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -b duration:300 -b files:12 -w ring.pcapng [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -C 100 -W 10 -w ring.pcap [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -C 100 -W 10 -w ring.pcap
PCAP lesen [RO][SENS] tshark -r capture.pcapng [RO][SENS] tcpdump -nn -r capture.pcap [RO][SENS] tcpdump -nn -r capture.pcap
Display Filter [RO][SENS] tshark -r capture.pcapng -Y "tcp.port == 443" [RO][SENS] tshark -r capture.pcap -Y "tcp.port == 443" [RO][SENS] tshark -r capture.pcap -Y "tcp.port == 443"
Dateiinformationen [RO][SENS] capinfos capture.pcapng [RO][SENS] capinfos capture.pcap [RO][SENS] capinfos capture.pcap
Windows-Inbox-Capture [TEST][PRIV][FILE][SENS] pktmon start --capture --pkt-size 0 --file-name pktmon.etl Nicht zutreffend Nicht zutreffend
Pktmon beenden [TEST][PRIV][FILE][SENS] pktmon stop Nicht zutreffend Nicht zutreffend
Pktmon konvertieren [RO][FILE][SENS] pktmon etl2pcap pktmon.etl --out pktmon.pcapng Nicht zutreffend Nicht zutreffend

NUMMER, INTERFACE und IP müssen durch die zuvor ermittelten Werte ersetzt werden.

48. Dokumentationsvorlage für Paketmitschnitte 
Störung:
Hypothese:
Erwartetes Paketmuster:
Zeitpunkt:
Zeitzone:

Clienthostname:
Client-IP:
Client-MAC:
Serverhostname:
Server-IP:
Serverport:
Transportprotokoll:
Anwendungsprotokoll:
IPv4 oder IPv6:

Messpunkt 1:
Messsystem 1:
Schnittstelle 1:
Capture Filter 1:
Dateiname 1:
Startzeit 1:
Endzeit 1:
Verworfene Capture-Pakete 1:

Messpunkt 2:
Messsystem 2:
Schnittstelle 2:
Capture Filter 2:
Dateiname 2:
Startzeit 2:
Endzeit 2:
Verworfene Capture-Pakete 2:

Fehler ausgelöst um:
Auslösende Handlung:
Beobachtete Fehlermeldung:

Relevanter Datenstrom:
Relevante Frame-Nummern:
Relevante Zeitstempel:
TCP-Handshake:
DNS-Ablauf:
TLS-Handshake:
HTTP-Status:
ICMP-Fehler:
Wiederholungen:
Verbindungsabbau:

Paket verlässt Client:
Paket erreicht Server:
Server antwortet:
Antwort erreicht Client:
Festgestellte Verluststelle:
Zusätzliche Systemprotokolle:
Festgestellte Ursache:

Datenschutzprüfung:
Originaldatei geschützt gespeichert:
Reduzierte Weitergabedatei:
Aufbewahrungsfrist:
Ergebnis der Nachprüfung:
49. Kontrollfragen nach der Analyse
50. Quellen und weiterführende Dokumentation
3. Netzwerkfehler systematisch analysieren

3.17 Befehlsübersicht – Netzwerkdiagnose unter Windows, Linux und macOS

Diese Seite dient als schnelle Befehlsreferenz für die systematische Netzwerkdiagnose. Die ausführliche Interpretation, Fehlerbilder und Sicherheitsregeln stehen auf den vorherigen Seiten dieses Kapitels.

1. Kennzeichnungen
Kennzeichnung Bedeutung
[RO] Rein lesender Befehl
[TEST] Aktiver Test, der Netzwerkverkehr erzeugt
[PRIV] Administrator- oder Root-Rechte können erforderlich sein
[FILE] Ausgabe wird in eine Datei geschrieben
[SENS] Ausgabe kann sensible Informationen enthalten
[CHANGE] Befehl verändert eine Konfiguration
[DISRUPT] Befehl kann Verbindungen oder Dienste beeinträchtigen

Platzhalter:

Platzhalter Ersetzen durch
INTERFACE Tatsächlicher Schnittstellenname
HOST Hostname des Zielsystems
IP IP-Adresse
PORT TCP- oder UDP-Port
DNS_SERVER IP-Adresse des DNS-Servers
CONTAINER Tatsächlicher Containername
ZONE Tatsächliche firewalld-Zone
DIENST Tatsächlicher Dienstname
DATEI Gewünschter Dateiname beziehungsweise Pfad

Befehle mit Platzhaltern dürfen nicht unverändert ausgeführt werden.

2. Empfohlene Kurzreihenfolge
Schritt Prüfung Leitfrage
1 Schnittstellenstatus Ist der Adapter aktiv und verbunden?
2 IP-Konfiguration Stimmen Adresse, Präfix, Gateway und DNS?
3 Loopback Funktioniert der lokale TCP/IP-Stack?
4 Eigene Adresse Ist die lokale Schnittstelle erreichbar?
5 Gateway Funktioniert das lokale Netz?
6 Entfernte IP Funktionieren Routing und Rückweg?
7 DNS Wird der richtige Name aufgelöst?
8 Route Welcher Pfad und welche Schnittstelle werden verwendet?
9 Port Ist der benötigte Transportdienst erreichbar?
10 Anwendung Antwortet das tatsächliche Protokoll?
11 Firewall, NAT, VPN oder Proxy Wo wird der Datenfluss beeinflusst?
12 Paketmitschnitt Welches Paketmuster belegt die Ursache?
3. Betriebssystem, Hostname, Zeit und Benutzer
Aufgabe Windows Linux macOS
Betriebssystem [RO] Get-ComputerInfo [RO] cat /etc/os-release [RO] sw_vers
Kernel beziehungsweise Systemversion [RO] systeminfo [RO] uname -a [RO] uname -a
Hostname [RO] hostname [RO] hostnamectl [RO] scutil --get ComputerName
Aktueller Benutzer [RO] whoami [RO] id [RO] id
Lokale Zeit [RO] Get-Date -Format o [RO] date --iso-8601=seconds [RO] date "+%Y-%m-%dT%H:%M:%S%z"
UTC-Zeit [RO] (Get-Date).ToUniversalTime().ToString("o") [RO] date -u "+%Y-%m-%dT%H:%M:%SZ" [RO] date -u "+%Y-%m-%dT%H:%M:%SZ"
Zeitzone [RO] Get-TimeZone [RO] timedatectl status [RO][PRIV] sudo systemsetup -gettimezone
Zeitstatus [RO] w32tm /query /status [RO] timedatectl status [RO][PRIV] sudo systemsetup -getusingnetworktime
4. Netzwerkadapter und Schnittstellen
Aufgabe Windows Linux macOS
Adapterübersicht [RO] Get-NetAdapter [RO] ip -br link [RO] ifconfig
Versteckte Adapter [RO] Get-NetAdapter -IncludeHidden Nicht direkt vergleichbar [RO] ifconfig -a
Aktive Adapter [RO] Get-NetAdapter | Where-Object Status -eq "Up" [RO] ip link show up [RO] ifconfig -u
MAC-Adressen [RO] Get-NetAdapter | Format-Table Name,MacAddress [RO] ip link show [RO] ifconfig
Linkgeschwindigkeit [RO] Get-NetAdapter | Format-Table Name,Status,LinkSpeed [RO][PRIV] sudo ethtool INTERFACE [RO] ifconfig INTERFACE
Adapterstatistik [RO] Get-NetAdapterStatistics [RO] ip -s link [RO] netstat -ib
Treiberinformationen [RO][SENS] Get-CimInstance Win32_PnPSignedDriver | Where-Object DeviceClass -eq "NET" [RO][SENS] lspci -k [RO][SENS] system_profiler SPNetworkDataType
USB-Netzwerkadapter Geräte-Manager beziehungsweise PnP-Geräte prüfen [RO][SENS] lsusb [RO][SENS] system_profiler SPUSBDataType
Schnittstellenzuordnung [RO] Get-NetIPInterface [RO] ip address show [RO] networksetup -listallhardwareports

Windows kompakt:

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

Linux kompakt:

[RO] ip -br link
[RO] ip -br address

macOS – Hardwareport und Gerätename zuordnen:

[RO] networksetup -listallhardwareports
5. IPv4- und IPv6-Konfiguration
Aufgabe Windows Linux macOS
Gesamte IP-Konfiguration [RO][SENS] Get-NetIPConfiguration -All [RO][SENS] ip address show [RO][SENS] ifconfig
Klassische Ausgabe [RO][SENS] ipconfig /all Nicht zutreffend Nicht zutreffend
Kompakte Adressen [RO][SENS] Get-NetIPAddress [RO][SENS] ip -br address [RO][SENS] ifconfig
Nur IPv4 [RO] Get-NetIPAddress -AddressFamily IPv4 [RO] ip -4 address show [RO] ifconfig
Nur IPv6 [RO] Get-NetIPAddress -AddressFamily IPv6 [RO] ip -6 address show [RO] ifconfig
Schnittstellen-MTU [RO] Get-NetIPInterface [RO] ip link show [RO] ifconfig
Netzwerkdienstinformationen Nicht direkt vergleichbar NetworkManager: [RO] nmcli device show [RO][SENS] networksetup -getinfo "Wi-Fi"

Windows nach Schnittstelle sortiert:

[RO][SENS] Get-NetIPAddress |
    Sort-Object InterfaceAlias, AddressFamily |
    Format-Table InterfaceAlias, AddressFamily,
                 IPAddress, PrefixLength, AddressState
6. DHCP prüfen
Aufgabe Windows Linux macOS
DHCP-Konfiguration [RO][SENS] ipconfig /all [RO][SENS] nmcli device show [RO][SENS] ipconfig getpacket INTERFACE
IPv4-Adresse [RO] Get-NetIPAddress -AddressFamily IPv4 [RO] ip -4 address show [RO] ipconfig getifaddr INTERFACE
DHCP-Paketmitschnitt Dumpcap: udp port 67 or udp port 68 tcpdump: udp port 67 or udp port 68 tcpdump: udp port 67 or udp port 68
DHCPv6-Mitschnitt Dumpcap: udp port 546 or udp port 547 tcpdump: udp port 546 or udp port 547 tcpdump: udp port 546 or udp port 547

Windows – Lease erneuern:

[CHANGE][DISRUPT] ipconfig /renew

Windows – Lease freigeben und neu beziehen:

[CHANGE][DISRUPT] ipconfig /release
[CHANGE][DISRUPT] ipconfig /renew

macOS – DHCP für einen Netzwerkdienst erneuern:

[CHANGE][DISRUPT][PRIV] sudo ipconfig set INTERFACE DHCP

Unter Linux hängt das sichere Erneuern vom verwendeten Netzwerkmanager ab. Zuerst prüfen:

[RO] nmcli device status
[RO] systemctl is-active NetworkManager
[RO] systemctl is-active systemd-networkd

DHCP-Erneuerungen können bestehende Verbindungen unterbrechen und dürfen nicht unkontrolliert auf Remote-Systemen ausgeführt werden.

7. ARP und IPv6 Neighbor Discovery
Aufgabe Windows Linux macOS
IPv4-Nachbarn [RO][SENS] Get-NetNeighbor -AddressFamily IPv4 [RO][SENS] ip -4 neigh show [RO][SENS] arp -an
IPv6-Nachbarn [RO][SENS] Get-NetNeighbor -AddressFamily IPv6 [RO][SENS] ip -6 neigh show [RO][SENS] ndp -an
Klassische ARP-Tabelle [RO][SENS] arp -a [RO][SENS] ip neigh show [RO][SENS] arp -a
Bestimmte Adresse [RO] Get-NetNeighbor -IPAddress IP [RO] ip neigh show IP [RO] arp -n IP
ARP-Mitschnitt Capture Filter arp [TEST][PRIV][SENS] sudo tcpdump -i INTERFACE -nn arp [TEST][PRIV][SENS] sudo tcpdump -i INTERFACE -nn arp
NDP-Mitschnitt Capture Filter icmp6 [TEST][PRIV][SENS] sudo tcpdump -i INTERFACE -nn icmp6 [TEST][PRIV][SENS] sudo tcpdump -i INTERFACE -nn icmp6

Nachbartabellen dürfen nicht unkontrolliert geleert werden. Dadurch können bestehende Verbindungen kurzfristig beeinflusst werden.

8. VLAN und Layer 2
Aufgabe Windows Linux macOS
Adapter und MAC [RO] Get-NetAdapter [RO] ip link show [RO] ifconfig
VLAN-Schnittstellen Abhängig vom Adaptertreiber und Hyper-V [RO] ip -d link show type vlan [RO] networksetup -listVLANs
Bridge [RO] Get-NetAdapterBinding beziehungsweise Hyper-V prüfen [RO] bridge link show [RO] ifconfig bridge0
Linkstatistik [RO] Get-NetAdapterStatistics [RO] ip -s link [RO] netstat -ib
Ethernetdetails Adaptereigenschaften und Switch prüfen [RO][PRIV] sudo ethtool INTERFACE [RO] ifconfig INTERFACE
LLDP-Nachbarn Abhängig von installiertem Werkzeug Falls installiert: [RO] lldpcli show neighbors Abhängig von installiertem Werkzeug

VLAN-Zuordnung wird häufig auf Switch, Access Point, Hypervisor oder Controller festgelegt und ist am Client nicht vollständig sichtbar.

9. Routing und Standardgateway
Aufgabe Windows Linux macOS
Routingtabelle [RO] Get-NetRoute [RO] ip route show [RO] netstat -rn
IPv4-Routen [RO] route print -4 [RO] ip -4 route show [RO] netstat -rn -f inet
IPv6-Routen [RO] route print -6 [RO] ip -6 route show [RO] netstat -rn -f inet6
IPv4-Standardroute [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" [RO] ip route show default [RO] route -n get default
IPv6-Standardroute [RO] Get-NetRoute -DestinationPrefix "::/0" [RO] ip -6 route show default [RO] route -n get -inet6 default
Route zu einem Ziel [RO] Find-NetRoute -RemoteIPAddress IP [RO] ip route get IP [RO] route -n get IP
Policy Routing Abhängig von Windows-Richtlinien [RO] ip rule show [RO] netstat -rn
Alle Linux-Tabellen Nicht zutreffend [RO][SENS] ip route show table all Nicht zutreffend

Windows übersichtlich:

[RO] Get-NetRoute |
    Sort-Object AddressFamily, DestinationPrefix, RouteMetric |
    Format-Table AddressFamily, DestinationPrefix,
                 NextHop, InterfaceAlias, RouteMetric
10. Ping und grundlegende Erreichbarkeit
Aufgabe Windows Linux macOS
IPv4-Ping [TEST] ping -4 -n 4 IP [TEST] ping -4 -c 4 IP [TEST] ping -c 4 IPV4
IPv6-Ping [TEST] ping -6 -n 4 IP [TEST] ping -6 -c 4 IP [TEST] ping6 -c 4 IPV6
20 Messungen [TEST] ping -n 20 IP [TEST] ping -c 20 IP [TEST] ping -c 20 IP
Fortlaufender Ping [TEST] ping -t IP [TEST] ping IP [TEST] ping IP
PowerShell-Test [TEST] Test-Connection IP -Count 4 Nicht zutreffend Nicht zutreffend
Größere Nutzlast [TEST] ping -n 4 -l 1400 IP [TEST] ping -c 4 -s 1400 IP [TEST] ping -c 4 -s 1400 IP
Don't Fragment [TEST] ping -4 -f -l 1400 IP [TEST] ping -4 -M do -s 1400 IP [TEST] ping -D -s 1400 IP

Empfohlene Reihenfolge:

Loopback
→ eigene Adresse
→ Standardgateway
→ internes Ziel
→ externes Ziel
→ Hostname
11. Netzwerkpfad untersuchen
Aufgabe Windows Linux macOS
Pfad mit DNS [TEST] tracert HOST [TEST] traceroute HOST [TEST] traceroute HOST
Pfad ohne DNS [TEST] tracert -d IP [TEST] traceroute -n IP [TEST] traceroute -n IP
IPv4-Pfad [TEST] tracert -4 -d HOST [TEST] traceroute -4 -n HOST [TEST] traceroute -4 -n HOST
IPv6-Pfad [TEST] tracert -6 -d HOST [TEST] traceroute -6 -n HOST [TEST] traceroute -6 -n HOST
Pfad und Verlust [TEST] pathping /n IP Falls installiert: [TEST] mtr -n -r -c 100 IP Falls installiert: [TEST] mtr -n -r -c 100 IP
Path-MTU-Hinweis Nicht direkt vergleichbar [TEST] tracepath -n IP MTU mit Ping und Route prüfen

Zwischenhops können ICMP-Antworten begrenzen. Verlust an einem einzelnen Zwischenhop ist kein Beweis für weitergeleiteten Paketverlust, wenn nachfolgende Hops und das Ziel keinen entsprechenden Verlust zeigen.

12. DNS-Konfiguration prüfen
Aufgabe Windows Linux macOS
DNS-Server [RO][SENS] Get-DnsClientServerAddress [RO][SENS] resolvectl status [RO][SENS] scutil --dns
DNS-Suffixe [RO] Get-DnsClient [RO] resolvectl status [RO][SENS] scutil --dns
Klassische Konfiguration [RO][SENS] ipconfig /all [RO][SENS] cat /etc/resolv.conf [RO][SENS] scutil --dns
Hosts-Datei [RO][SENS] Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" [RO][SENS] cat /etc/hosts [RO][SENS] cat /etc/hosts
DNS-Cache [RO][SENS] Get-DnsClientCache Resolverabhängig [RO][SENS] dscacheutil -cachedump -entries Host – Ausgabe abhängig von macOS-Version

/etc/resolv.conf kann unter Linux automatisch erzeugt sein und bildet bei lokalen Stub-Resolvern nicht zwingend die vollständige Resolverlogik ab.

13. DNS-Abfragen durchführen
Aufgabe Windows Linux macOS
Standardabfrage [TEST] Resolve-DnsName HOST [TEST] dig HOST [TEST] dig HOST
A-Record [TEST] Resolve-DnsName HOST -Type A [TEST] dig HOST A [TEST] dig HOST A
AAAA-Record [TEST] Resolve-DnsName HOST -Type AAAA [TEST] dig HOST AAAA [TEST] dig HOST AAAA
PTR-Record [TEST] Resolve-DnsName IP -Type PTR [TEST] dig -x IP [TEST] dig -x IP
Bestimmter DNS-Server [TEST] Resolve-DnsName HOST -Server DNS_SERVER [TEST] dig @DNS_SERVER HOST [TEST] dig @DNS_SERVER HOST
DNS über TCP [TEST] Resolve-DnsName HOST -Server DNS_SERVER -TcpOnly [TEST] dig +tcp @DNS_SERVER HOST [TEST] dig +tcp @DNS_SERVER HOST
Kurze Ausgabe [TEST] (Resolve-DnsName HOST -Type A).IPAddress [TEST] dig +short HOST [TEST] dig +short HOST
Vollständige Ablaufverfolgung Nicht direkt vergleichbar [TEST] dig +trace HOST [TEST] dig +trace HOST
Klassischer Test [TEST] nslookup HOST DNS_SERVER [TEST] nslookup HOST DNS_SERVER [TEST] nslookup HOST DNS_SERVER

dig +trace fragt mehrere DNS-Server ab und darf nur verwendet werden, wenn direkte externe DNS-Abfragen erlaubt sind.

14. DNS-Cache kontrolliert leeren

Diese Befehle verändern den lokalen Cache und können die Reproduzierbarkeit beeinflussen.

Betriebssystem Befehl
Windows [CHANGE] ipconfig /flushdns
Linux mit systemd-resolved [CHANGE][PRIV] sudo resolvectl flush-caches
macOS [CHANGE][PRIV] sudo dscacheutil -flushcache

Unter Linux hängt der Befehl vom tatsächlich verwendeten Resolver ab. Vorher prüfen:

[RO] systemctl is-active systemd-resolved

Das Leeren eines DNS-Caches behebt keine fehlerhafte DNS-Zone, falsche Delegierung oder falsche Serverkonfiguration.

15. TCP-Listener, UDP-Endpunkte und Verbindungen
Aufgabe Windows Linux macOS
TCP-Verbindungen [RO] Get-NetTCPConnection [RO] ss -tan [RO] netstat -anv -p tcp
TCP-Listener [RO] Get-NetTCPConnection -State Listen [RO] ss -ltn [RO] lsof -nP -iTCP -sTCP:LISTEN
UDP-Endpunkte [RO] Get-NetUDPEndpoint [RO] ss -lun [RO] lsof -nP -iUDP
Listener mit Prozess Prozess-ID über OwningProcess [RO][PRIV] sudo ss -ltnp [RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN
Bestehende TCP-Verbindungen [RO] Get-NetTCPConnection -State Established [RO] ss -tn state established [RO] netstat -anv -p tcp
Klassische Übersicht [RO] netstat -ano [RO] ss -tuln [RO] netstat -anv
TCP-Statistik [RO] netstat -s -p tcp [RO] nstat beziehungsweise [RO] netstat -s [RO] netstat -s -p tcp

Bestimmten TCP-Port prüfen:

Windows:

[RO] Get-NetTCPConnection -State Listen -LocalPort PORT `
    -ErrorAction SilentlyContinue

Linux:

[RO] ss -ltn 'sport = :PORT'

macOS:

[RO] lsof -nP -iTCP:PORT -sTCP:LISTEN
16. Prozess zu einem Port ermitteln

Windows:

[RO] Get-NetTCPConnection -State Listen -LocalPort PORT |
    Select-Object LocalAddress, LocalPort, State, OwningProcess

Anschließend:

[RO] Get-Process -Id PID

Alternativ:

[RO] netstat -ano
[RO] tasklist /FI "PID eq PID"

Linux:

[RO][PRIV] sudo ss -ltnp 'sport = :PORT'

[RO][PRIV] sudo lsof -nP -iTCP:PORT -sTCP:LISTEN

macOS:

[RO][PRIV] sudo lsof -nP -iTCP:PORT -sTCP:LISTEN

[RO] ps -p PID -o pid,ppid,user,command
17. TCP- und UDP-Porttests
Aufgabe Windows Linux macOS
TCP-Port [TEST] Test-NetConnection HOST -Port PORT [TEST] nc -vz -w 5 HOST PORT [TEST] nc -vz -w 5 HOST PORT
Detaillierter TCP-Test [TEST] Test-NetConnection HOST -Port PORT -InformationLevel Detailed [TEST] nc -vz -w 5 HOST PORT [TEST] nc -vz -w 5 HOST PORT
Nmap TCP Connect [TEST] nmap -sT -p PORT HOST [TEST] nmap -sT -p PORT HOST [TEST] nmap -sT -p PORT HOST
Nmap UDP Administrator-Konsole: [TEST][PRIV] nmap -sU -p PORT HOST [TEST][PRIV] sudo nmap -sU -p PORT HOST [TEST][PRIV] sudo nmap -sU -p PORT HOST
Netcat UDP Falls Netcat installiert: [TEST] nc -vzu HOST PORT [TEST] nc -vzu -w 3 HOST PORT [TEST] nc -vzu -w 3 HOST PORT

UDP-Tests sind ohne gültige Anfrage des Anwendungsprotokolls häufig nicht eindeutig. Test-NetConnection -Port ist ein TCP-Test.

Nmap und Portscans dürfen nur gegen ausdrücklich freigegebene Systeme verwendet werden.

18. HTTP, HTTPS und TLS prüfen
Aufgabe Windows Linux macOS
HTTP-Header [TEST] curl.exe -I http://HOST/ [TEST] curl -I http://HOST/ [TEST] curl -I http://HOST/
HTTPS-Header [TEST] curl.exe -I https://HOST/ [TEST] curl -I https://HOST/ [TEST] curl -I https://HOST/
Ausführlicher Test [TEST][SENS] curl.exe -v https://HOST/ [TEST][SENS] curl -v https://HOST/ [TEST][SENS] curl -v https://HOST/
Nur IPv4 [TEST] curl.exe -4 -I https://HOST/ [TEST] curl -4 -I https://HOST/ [TEST] curl -4 -I https://HOST/
Nur IPv6 [TEST] curl.exe -6 -I https://HOST/ [TEST] curl -6 -I https://HOST/ [TEST] curl -6 -I https://HOST/
TLS-Handshake Falls OpenSSL installiert: [TEST][SENS] openssl s_client -connect HOST:443 -servername HOST [TEST][SENS] openssl s_client -connect HOST:443 -servername HOST [TEST][SENS] openssl s_client -connect HOST:443 -servername HOST

HTTP-Zeitanteile:

[TEST][SENS] curl -sS -o /dev/null \
    -w 'DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nStartTransfer: %{time_starttransfer}\nTotal: %{time_total}\nHTTP: %{http_code}\n' \
    https://HOST/

curl -k deaktiviert die Zertifikatsprüfung und darf nicht als dauerhafte Lösung verwendet werden.

19. Windows-Firewall prüfen
Aufgabe Befehl
Aktives Netzwerkprofil [RO] Get-NetConnectionProfile
Firewallprofile [RO] Get-NetFirewallProfile
Ausführliche Profile [RO] Get-NetFirewallProfile | Format-List *
Aktivierte Regeln [RO][SENS] Get-NetFirewallRule -Enabled True
Blockierungsregeln [RO][SENS] Get-NetFirewallRule -Enabled True -Action Block
Eingehende Erlaubnisregeln [RO][SENS] Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow
Portfilter [RO][SENS] Get-NetFirewallPortFilter
Adressfilter einer Regel [RO][SENS] Get-NetFirewallRule -DisplayName "REGEL" | Get-NetFirewallAddressFilter
Programmfilter [RO][SENS] Get-NetFirewallRule -DisplayName "REGEL" | Get-NetFirewallApplicationFilter
Aktiver Richtlinienspeicher [RO][SENS] Get-NetFirewallRule -PolicyStore ActiveStore
Klassische Übersicht [RO] netsh advfirewall show allprofiles

Regeln für TCP-Port 443 suchen:

[RO][SENS] Get-NetFirewallPortFilter -Protocol TCP |
    Where-Object LocalPort -eq "443" |
    Get-NetFirewallRule |
    Format-Table DisplayName, Enabled, Direction, Action, Profile
20. Linux-Firewall prüfen
System Aufgabe Befehl
firewalld Status [RO] firewall-cmd --state
firewalld Aktive Zonen [RO] firewall-cmd --get-active-zones
firewalld Zone einer Schnittstelle [RO] firewall-cmd --get-zone-of-interface=INTERFACE
firewalld Zonenkonfiguration [RO][SENS] firewall-cmd --zone=ZONE --list-all
firewalld TCP-Port prüfen [RO] firewall-cmd --zone=ZONE --query-port=443/tcp
firewalld Dienste [RO] firewall-cmd --zone=ZONE --list-services
firewalld Permanente Konfiguration [RO][SENS] firewall-cmd --permanent --zone=ZONE --list-all
nftables Regelwerk [RO][PRIV][SENS] sudo nft list ruleset
nftables Regeln mit Handles [RO][PRIV][SENS] sudo nft -a list ruleset
iptables IPv4-Regeln [RO][PRIV][SENS] sudo iptables -L -n -v --line-numbers
iptables IPv6-Regeln [RO][PRIV][SENS] sudo ip6tables -L -n -v --line-numbers
ufw Status [RO][PRIV][SENS] sudo ufw status verbose
ufw Nummerierte Regeln [RO][PRIV][SENS] sudo ufw status numbered

Runtime- und permanente firewalld-Konfiguration müssen getrennt verglichen werden.

21. macOS-Firewall und pf prüfen
Aufgabe Befehl
Anwendungsfirewallstatus [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
Alle eingehenden Verbindungen blockieren [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getblockall
Stealth-Modus [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode
Konfigurierte Anwendungen [RO][PRIV][SENS] sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps
pf-Status [RO][PRIV] sudo pfctl -s info
pf-Regeln [RO][PRIV][SENS] sudo pfctl -s rules
pf-NAT [RO][PRIV][SENS] sudo pfctl -s nat
pf-Zustände [RO][PRIV][SENS] sudo pfctl -s states
Regeln mit Zählern [RO][PRIV][SENS] sudo pfctl -vvs rules

Die macOS-Anwendungsfirewall und pf sind getrennte Filterebenen.

22. NAT und Portweiterleitung
Aufgabe Windows Linux macOS
Windows-NAT [RO][PRIV][SENS] Get-NetNat Nicht zutreffend Nicht zutreffend
Statische Zuordnungen [RO][PRIV][SENS] Get-NetNatStaticMapping Nicht zutreffend Nicht zutreffend
NAT-Sitzungen [RO][PRIV][SENS] Get-NetNatSession Conntrack verwenden pf-Zustände verwenden
nftables-NAT Nicht zutreffend [RO][PRIV][SENS] sudo nft -a list ruleset Nicht zutreffend
iptables-NAT Nicht zutreffend [RO][PRIV][SENS] sudo iptables -t nat -L -n -v --line-numbers Nicht zutreffend
pf-NAT Nicht zutreffend Nicht standardmäßig allgemein vorhanden [RO][PRIV][SENS] sudo pfctl -vvs nat
IPv4-Forwarding Rollenabhängig [RO] sysctl net.ipv4.ip_forward [RO] sysctl net.inet.ip.forwarding
Conntrack Windows-NAT-Sitzungen [RO][PRIV][SENS] sudo conntrack -L [RO][PRIV][SENS] sudo pfctl -s states

Öffentlich sichtbare IPv4-Adresse:

Windows:

[TEST][SENS] Invoke-RestMethod -Uri "https://api.ipify.org"

Linux und macOS:

[TEST][SENS] curl -4 https://api.ipify.org

Dabei wird die öffentliche Quelladresse an einen externen Dienst übermittelt.

23. Proxy prüfen
Aufgabe Windows Linux macOS
Proxyvariablen [RO][SENS] Get-ChildItem Env: | Where-Object Name -Match 'proxy' [RO][SENS] env | grep -i proxy [RO][SENS] env | grep -i proxy
WinHTTP-Proxy [RO][SENS] netsh winhttp show proxy Nicht zutreffend Nicht zutreffend
Erweiterter WinHTTP-Proxy [RO][SENS] netsh winhttp show advproxy Nicht zutreffend Nicht zutreffend
Benutzerproxy Registry Internet Settings prüfen Desktop- und anwendungsabhängig [RO][SENS] scutil --proxy
HTTP-Proxy Anwendungsspezifisch Umgebungs- oder Anwendungskonfiguration [RO][SENS] networksetup -getwebproxy "Wi-Fi"
HTTPS-Proxy Anwendungsspezifisch Umgebungs- oder Anwendungskonfiguration [RO][SENS] networksetup -getsecurewebproxy "Wi-Fi"
PAC-URL Registry beziehungsweise WinHTTP Desktop- und anwendungsabhängig [RO][SENS] networksetup -getautoproxyurl "Wi-Fi"
Proxy-Ausnahmen Registry beziehungsweise WinHTTP NO_PROXY prüfen [RO][SENS] networksetup -getproxybypassdomains "Wi-Fi"

Windows-Benutzereinstellungen:

[RO][SENS] Get-ItemProperty `
    "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" |
    Select-Object ProxyEnable, ProxyServer,
                  ProxyOverride, AutoConfigURL, AutoDetect

Expliziter Proxytest:

[TEST][SENS] curl -v \
    --proxy http://PROXY:PORT \
    https://HOST/

Proxy ausdrücklich umgehen:

[TEST][SENS] curl -v --noproxy "*" https://HOST/

Ein Proxy-Bypass darf nur ausgeführt werden, wenn die Sicherheitsrichtlinie dies erlaubt.

24. VPN prüfen
Aufgabe Windows Linux macOS
VPN-Profile [RO][SENS] Get-VpnConnection [RO][SENS] nmcli connection show [RO][SENS] scutil --nc list
Geräteweite Profile [RO][PRIV][SENS] Get-VpnConnection -AllUserConnection Clientabhängig MDM- und clientabhängig
Aktive RAS-Verbindung [RO] rasdial [RO][SENS] nmcli connection show --active [RO][SENS] scutil --nc status "VPN-NAME"
Virtuelle Schnittstellen [RO] Get-NetAdapter -IncludeHidden [RO] ip -br link [RO] ifconfig
VPN-Routen [RO] Get-NetRoute [RO] ip route show [RO] netstat -rn
DNS über VPN [RO][SENS] Get-DnsClientServerAddress [RO][SENS] resolvectl status [RO][SENS] scutil --dns
WireGuard Falls installiert: [RO][PRIV][SENS] wg show [RO][PRIV][SENS] sudo wg show Falls installiert: [RO][PRIV][SENS] sudo wg show
RAS-Protokoll [RO][PRIV][SENS] Get-WinEvent -LogName "Microsoft-Windows-RasClient/Operational" Clientabhängig Clientabhängig
NetworkManager-Protokoll Nicht zutreffend [RO][PRIV][SENS] sudo journalctl -u NetworkManager --since "-30 minutes" Nicht zutreffend

Windows – Split Tunneling prüfen:

[RO][SENS] Get-VpnConnection |
    Select-Object Name, ConnectionStatus,
                  SplitTunneling, TunnelType, ServerAddress
25. WLAN prüfen
Aufgabe Windows Linux macOS
Aktuelle Verbindung [RO][SENS] netsh wlan show interfaces [RO][SENS] iw dev INTERFACE link [RO][SENS] networksetup -getairportnetwork INTERFACE
Sichtbare Netze [RO][SENS] netsh wlan show networks mode=bssid [TEST][SENS] nmcli device wifi list Wireless Diagnostics beziehungsweise wdutil, falls unterstützt
WLAN-Schnittstellen [RO] Get-NetAdapter [RO] iw dev [RO] networksetup -listallhardwareports
Treiber [RO][SENS] netsh wlan show drivers [RO][SENS] lspci -k beziehungsweise lsusb [RO][SENS] system_profiler SPAirPortDataType
Fähigkeiten [RO][SENS] netsh wlan show wirelesscapabilities [RO][SENS] iw list [RO][SENS] system_profiler SPAirPortDataType
Gespeicherte Profile [RO][SENS] netsh wlan show profiles [RO][SENS] nmcli connection show WLAN-Einstellungen beziehungsweise MDM
Stationsstatistik Informationen unter show interfaces [RO][SENS] iw dev INTERFACE station dump Falls unterstützt: [RO][PRIV][SENS] sudo wdutil info
Regulierungsdomäne Treiber- und Regionseinstellungen [RO] iw reg get Systemverwaltet
WLAN-Protokoll WLAN-AutoConfig-Ereignisse NetworkManager und Kernel Wireless Diagnostics
WLAN-Bericht [RO][PRIV][FILE][SENS] netsh wlan show wlanreport Protokolle getrennt sichern Wireless Diagnostics erzeugt ein Diagnosearchiv

Windows-Ereignisse:

[RO][PRIV][SENS] Get-WinEvent `
    -LogName "Microsoft-Windows-WLAN-AutoConfig/Operational" `
    -MaxEvents 100
26. Leistung, Paketverlust und Bandbreite
Aufgabe Windows Linux macOS
100 Pingtests [TEST] ping -n 100 IP [TEST] ping -c 100 IP [TEST] ping -c 100 IP
Pfad und Verlust [TEST] pathping /n IP Falls installiert: [TEST] mtr -n -r -c 100 IP Falls installiert: [TEST] mtr -n -r -c 100 IP
TCP-Durchsatz [TEST] iperf3 -c SERVER_IP [TEST] iperf3 -c SERVER_IP [TEST] iperf3 -c SERVER_IP
Gegenrichtung [TEST] iperf3 -c SERVER_IP -R [TEST] iperf3 -c SERVER_IP -R [TEST] iperf3 -c SERVER_IP -R
30 Sekunden [TEST] iperf3 -c SERVER_IP -t 30 [TEST] iperf3 -c SERVER_IP -t 30 [TEST] iperf3 -c SERVER_IP -t 30
Parallele Streams [TEST] iperf3 -c SERVER_IP -P 4 [TEST] iperf3 -c SERVER_IP -P 4 [TEST] iperf3 -c SERVER_IP -P 4
UDP 10 Mbit/s [TEST] iperf3 -c SERVER_IP -u -b 10M -t 30 [TEST] iperf3 -c SERVER_IP -u -b 10M -t 30 [TEST] iperf3 -c SERVER_IP -u -b 10M -t 30
JSON-Ausgabe [TEST][FILE][SENS] iperf3 -c SERVER_IP -J > test.json [TEST][FILE][SENS] iperf3 -c SERVER_IP -J > test.json [TEST][FILE][SENS] iperf3 -c SERVER_IP -J > test.json
Schnittstellenfehler [RO] Get-NetAdapterStatistics [RO] ip -s link [RO] netstat -ib

Lasttests dürfen nur auf freigegebenen Systemen und mit kontrollierter Datenrate durchgeführt werden.

27. Docker- und Containernetzwerke
Aufgabe Befehl
Laufende Container und Ports [RO] docker ps --format 'table {{.Names}}\t{{.Ports}}'
Portzuordnung [RO] docker port CONTAINER
Netzwerke [RO] docker network ls
Netzwerkdetails [RO][SENS] docker network inspect NETZWERK
Containerdetails [RO][SENS] docker inspect CONTAINER
Containerprotokoll [RO][SENS] docker logs --tail 100 CONTAINER
Containerprozesse [RO] docker top CONTAINER
Container-IP-Konfiguration Über docker inspect und Netzwerkdefinition prüfen
Veröffentlichte Hostports [RO] docker ps --format 'table {{.Names}}\t{{.Ports}}'

Typische Portzuordnung:

0.0.0.0:8080->80/tcp

Nur Loopback:

127.0.0.1:8080->80/tcp

EXPOSE im Dockerfile veröffentlicht einen Port nicht automatisch auf dem Host.

28. Prozesse und Dienste prüfen
Aufgabe Windows Linux macOS
Prozesse [RO] Get-Process [RO] ps aux [RO] ps aux
Prozess per PID [RO] Get-Process -Id PID [RO] ps -fp PID [RO] ps -p PID -o pid,ppid,user,command
Dienste [RO] Get-Service [RO] systemctl --type=service [RO] launchctl list
Bestimmter Dienst [RO] Get-Service -Name DIENST [RO] systemctl status DIENST Dienstabhängig
Aktuelle Logs Ereignisprotokoll beziehungsweise Anwendung [RO][PRIV][SENS] sudo journalctl -u DIENST --since "-30 minutes" Unified Logging beziehungsweise Anwendung
CPU-Prozesse [RO] Get-Process | Sort-Object CPU -Descending [RO] top [RO] top -l 1

Linux-Dienstkonfiguration:

[RO][PRIV][SENS] sudo systemctl cat DIENST

Linux-Dienstumgebung:

[RO][PRIV][SENS] sudo systemctl show DIENST \
    --property=Environment \
    --property=EnvironmentFiles
29. Paketmitschnitt – Schnittstellen und Basisbefehle
Aufgabe Windows Linux macOS
Capture-Schnittstellen [RO] dumpcap -D [RO] tcpdump -D [RO] tcpdump -D
Vollständige Aufzeichnung [TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -w capture.pcapng [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -w capture.pcap [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -w capture.pcap
Bestimmter Host Dumpcap mit -f "host IP" tcpdump mit 'host IP' tcpdump mit 'host IP'
TCP-Port 443 Dumpcap mit -f "tcp port 443" tcpdump mit 'tcp port 443' tcpdump mit 'tcp port 443'
DNS Dumpcap mit -f "port 53" tcpdump mit 'port 53' tcpdump mit 'port 53'
DHCPv4 Dumpcap mit -f "udp port 67 or udp port 68" tcpdump mit entsprechendem Filter tcpdump mit entsprechendem Filter
PCAP lesen [RO][SENS] tshark -r capture.pcapng [RO][SENS] tcpdump -nn -r capture.pcap [RO][SENS] tcpdump -nn -r capture.pcap
Dateiinformationen [RO][SENS] capinfos capture.pcapng [RO][SENS] capinfos capture.pcap [RO][SENS] capinfos capture.pcap

Windows – 60 Sekunden:

[TEST][PRIV][FILE][SENS] dumpcap -i NUMMER `
    -a duration:60 `
    -w capture.pcapng

Linux oder macOS – bestimmter Datenfluss:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \
    'host CLIENT_IP and host SERVER_IP and tcp port PORT' \
    -w capture.pcap
30. Paketmitschnitt – Ringspeicher

Dumpcap – alle fünf Minuten wechseln, zwölf Dateien:

[TEST][PRIV][FILE][SENS] dumpcap -i NUMMER `
    -b duration:300 `
    -b files:12 `
    -w ringbuffer.pcapng

tcpdump – größenbasiert, maximal zehn Dateien:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \
    -C 100 \
    -W 10 \
    -w ringbuffer.pcap

Vor einer Langzeitaufzeichnung prüfen:

31. Windows Pktmon
Aufgabe Befehl
Hilfe [RO] pktmon help
Status [RO][PRIV] pktmon status
Komponenten [RO][PRIV][SENS] pktmon list
Aufzeichnung starten [TEST][PRIV][FILE][SENS] pktmon start --capture --pkt-size 0 --file-name pktmon.etl
Aufzeichnung beenden [TEST][PRIV][FILE][SENS] pktmon stop
Zähler [RO][PRIV][SENS] pktmon counters
Nach PCAPNG konvertieren [RO][FILE][SENS] pktmon etl2pcap pktmon.etl --out pktmon.pcapng
Nur Drops konvertieren [RO][FILE][SENS] pktmon etl2pcap pktmon.etl --drop-only --out pktmon-drops.pcapng

Pktmon kann Pakete an mehreren Stellen des Windows-Netzwerkstacks erfassen. Die ursprüngliche ETL-Datei enthält Informationen, die bei der PCAPNG-Konvertierung teilweise verloren gehen können.

32. Wichtige Wireshark Display Filter
Aufgabe Display Filter
IPv4-Adresse ip.addr == 192.0.2.20
IPv6-Adresse ipv6.addr == 2001:db8::20
Zwei Systeme ip.addr == 192.0.2.20 && ip.addr == 192.0.2.53
TCP-Port tcp.port == 443
UDP-Port udp.port == 53
ARP arp
IPv6 Neighbor Discovery icmpv6
DHCPv4 dhcp
DHCPv6 dhcpv6
DNS dns
DNS-Anfrage dns.flags.response == 0
DNS-Antwort dns.flags.response == 1
HTTP-Anfrage http.request
HTTP-Antwort http.response
TLS-Handshake tls.handshake
TCP-SYN tcp.flags.syn == 1
Erstes SYN tcp.flags.syn == 1 && tcp.flags.ack == 0
TCP-Reset tcp.flags.reset == 1
TCP-FIN tcp.flags.fin == 1
Wiederholung tcp.analysis.retransmission
Doppelte ACKs tcp.analysis.duplicate_ack
Out-of-Order tcp.analysis.out_of_order
Zero Window tcp.analysis.zero_window
ICMP icmp
ICMPv6 icmpv6
IKE isakmp
IPsec NAT-T udp.port == 4500
ESP esp
33. TShark-Auswertung

Datei mit Display Filter lesen:

[RO][SENS] tshark -r capture.pcapng \
    -Y 'tcp.port == 443'

DNS-Anfragen:

[RO][SENS] tshark -r capture.pcapng \
    -Y 'dns.flags.response == 0' \
    -T fields \
    -e frame.time \
    -e ip.src \
    -e dns.qry.name

HTTP-Statuscodes:

[RO][SENS] tshark -r capture.pcapng \
    -Y 'http.response' \
    -T fields \
    -e frame.time \
    -e ip.src \
    -e ip.dst \
    -e http.response.code

TCP-Wiederholungen:

[RO][SENS] tshark -r capture.pcapng \
    -Y 'tcp.analysis.retransmission'

Mitschnitte zusammenführen:

[RO][FILE][SENS] mergecap \
    -w combined.pcapng \
    client.pcapng \
    server.pcapng
34. Typische Symptom-zu-Befehl-Zuordnung
Symptom Erste sinnvolle Prüfungen
Kein Netzwerk Adapterstatus, IP-Konfiguration, Gateway
Adresse 169.254.x.x DHCP, VLAN, DHCP-Paketmitschnitt
Gateway nicht erreichbar ARP/NDP, Subnetz, WLAN, Kabel, Switchport
IP funktioniert, Hostname nicht DNS-Server, Resolve-DnsName, dig
Host antwortet, Dienst nicht Listener, Porttest, Firewall
Connection refused Listener und Prozess prüfen
Timeout Route, Firewall, Rückweg und Paketmitschnitt
Nur ein Client betroffen Clientkonfiguration mit Vergleichssystem vergleichen
Nur ein VLAN betroffen VLAN, Gateway, DHCP-Relay und ACL
Nur extern nicht erreichbar NAT, Firewall, öffentliche Adresse und CGNAT
Nur intern über öffentlichen Namen fehlerhaft Hairpin NAT oder Split DNS
Browser funktioniert, Dienst nicht WinHTTP, Proxyvariablen und Benutzerkontext
VPN verbunden, internes Ziel nicht erreichbar Tunneladresse, Route, DNS und Netzüberlappung
WLAN verbunden, kein Internet DHCP, Gateway, DNS und Captive Portal
Verbindung langsam Gatewayping, Fehlerzähler, iperf3 und Auslastung
Kleine Pakete funktionieren, große nicht MTU, ICMP und Path-MTU-Discovery
Sporadische Abbrüche Langzeitmessung, Logs, Link-Flaps und Paketmitschnitt
TCP funktioniert, UDP nicht UDP-spezifischen Diensttest, Firewall und Mitschnitt
IPv4 funktioniert, IPv6 nicht IPv6-Adresse, Route, DNS-AAAA und ICMPv6
Container lokal erreichbar, extern nicht Port Publishing, Bind-Adresse, Host-Firewall und NAT
35. Kompakter Diagnoseblock pro Betriebssystem

Windows – rein lesender Basisblock:

[RO] Get-Date -Format o
[RO] hostname
[RO] Get-NetAdapter
[RO][SENS] Get-NetIPConfiguration -All
[RO] Get-NetRoute
[RO][SENS] Get-DnsClientServerAddress
[RO][SENS] Get-NetNeighbor
[RO] Get-NetTCPConnection
[RO] Get-NetUDPEndpoint
[RO] Get-NetAdapterStatistics
[RO] Get-NetConnectionProfile
[RO] Get-NetFirewallProfile

Linux – rein lesender Basisblock:

[RO] date --iso-8601=seconds
[RO] hostnamectl
[RO] ip -br link
[RO][SENS] ip -br address
[RO] ip route show
[RO] ip -6 route show
[RO][SENS] ip neigh show
[RO][SENS] resolvectl status
[RO] ss -tuln
[RO] ip -s link

Falls resolvectl nicht vorhanden ist:

[RO][SENS] cat /etc/resolv.conf

macOS – rein lesender Basisblock:

[RO] date "+%Y-%m-%dT%H:%M:%S%z"
[RO] sw_vers
[RO] scutil --get ComputerName
[RO] networksetup -listallhardwareports
[RO][SENS] ifconfig
[RO] netstat -rn
[RO][SENS] arp -an
[RO][SENS] ndp -an
[RO][SENS] scutil --dns
[RO] netstat -anv
[RO] netstat -ib

Die Kennzeichnungen [RO] und [SENS] sind Dokumentationsmarkierungen und werden beim tatsächlichen Kopieren eines Befehls nicht mit eingegeben.

36. Dokumentationsvorlage für eine Netzwerkdiagnose 
Störung:
Zeitpunkt:
Zeitzone:
Benutzer:
Standort:
Client:
Betriebssystem:

Schnittstelle:
MAC-Adresse:
Linkstatus:
Linkgeschwindigkeit:
WLAN-SSID:
WLAN-BSSID:
VLAN:

IPv4-Adresse:
IPv4-Präfix:
IPv4-Gateway:
IPv6-Adresse:
IPv6-Präfix:
IPv6-Gateway:
DHCP-Server:
DNS-Server:
DNS-Suffixe:

Zielhostname:
Aufgelöste Zieladresse:
Transportprotokoll:
Zielport:
Anwendung:

Loopbacktest:
Gatewaytest:
Interner IP-Test:
Externer IP-Test:
DNS-Test:
Routenergebnis:
Porttest:
Anwendungstest:

Listener vorhanden:
Zugehöriger Prozess:
Firewallstatus:
Passende Firewallregel:
NAT beteiligt:
Proxy beteiligt:
VPN beteiligt:
Container beteiligt:

Paketverlust:
Latenz:
Jitter:
TCP-Durchsatz:
UDP-Verlust:
Schnittstellenfehler:

Paketmitschnitt:
Messpunkt:
Capture Filter:
Relevante Frames:
Systemprotokolle:
Festgestellte Ursache:
Genehmigte Änderung:
Rückfallplan:
Ergebnis der Nachprüfung:
37. Abschließende Kontrollfragen
38. Quellen und Befehlsreferenzen

4. Server- und Dienstfehler systematisch analysieren

4. Server- und Dienstfehler systematisch analysieren

4.0 Server- und Dienstfehler systematisch analysieren

Server- und Dienstfehler liegen vor, wenn ein benötigter Dienst nicht startet, unerwartet beendet wird, nicht erreichbar ist oder zwar Verbindungen annimmt, aber fehlerhafte Ergebnisse liefert.

Dieses Kapitel behandelt die systematische Analyse von Diensten und Serveranwendungen unter Windows, Linux und macOS. Dazu gehören unter anderem Webserver, Datenbanken, Datei- und Druckdienste, Anwendungsserver sowie Hintergrunddienste.

Grundsatz:
Ein erreichbarer Server ist nicht automatisch ein funktionierender Server. Netzwerkverbindung, Port, Dienstprozess und Anwendungsfunktion müssen getrennt geprüft werden.

Ziele dieses Kapitels

Nach Abschluss dieses Kapitels sollst du:

Sicherheits- und Risikokennzeichnungen

Kennzeichnung Bedeutung
[RO] Rein lesender Befehl; verändert normalerweise nichts
[TEST] Führt eine aktive Prüfung oder Verbindungsanfrage aus
[PRIV] Erfordert möglicherweise Administrator- oder Rootrechte
[FILE] Liest eine Datei oder schreibt eine Ausgabe in eine Datei
[SENS] Ausgabe kann sensible Informationen enthalten
[CHANGE] Verändert Einstellungen, Zustände oder Konfigurationen
[DISRUPT] Kann einen Dienst oder laufenden Betrieb unterbrechen

Befehle mit [CHANGE] oder [DISRUPT] dürfen erst nach Prüfung der Auswirkungen und möglichst innerhalb eines abgestimmten Wartungsfensters ausgeführt werden.

1. Diagnosemodell für Server- und Dienstfehler

Ein Dienst wird schrittweise von außen nach innen geprüft:

Ebene Leitfrage Typische Prüfung
1. Benutzer Was funktioniert aus Sicht des Benutzers nicht? Fehlermeldung und Zeitpunkt aufnehmen
2. Client Ist nur ein Gerät oder Benutzer betroffen? Vergleich mit anderem Client
3. Namensauflösung Wird der richtige Servername aufgelöst? DNS-Abfrage durchführen
4. Netzwerk Ist der Server erreichbar? Route und Erreichbarkeit prüfen
5. Transport Ist der benötigte TCP- oder UDP-Port erreichbar? Porttest durchführen
6. Betriebssystem Läuft das Betriebssystem stabil? Ressourcen und Ereignisse prüfen
7. Dienst Läuft der benötigte Dienst? Dienststatus und Prozess prüfen
8. Abhängigkeiten Funktionieren abhängige Dienste und Systeme? Datenbank, DNS, Speicher oder Authentifizierung prüfen
9. Konfiguration Ist der Dienst korrekt konfiguriert? Konfigurationsdateien und Startparameter prüfen
10. Anwendung Liefert der Dienst fachlich korrekte Ergebnisse? Anwendungsspezifischen Funktionstest durchführen

Wichtig: ping prüft nicht, ob ein Anwendungsdienst funktioniert. Ein Server kann ICMP-Anfragen beantworten, obwohl beispielsweise der Web-, Datenbank- oder Dateidienst ausgefallen ist.

2. Vier grundlegende Dienstzustände unterscheiden
Zustand Beschreibung Typische Ursache
Server nicht erreichbar Bereits die Netzwerkverbindung scheitert Routing, VLAN, Firewall, Stromversorgung oder Netzwerkkarte
Port nicht erreichbar Server ist erreichbar, aber der Dienstport nicht Dienst gestoppt, falscher Port oder Firewall
Port erreichbar, Anwendung fehlerhaft Verbindung wird aufgebaut, die Anfrage schlägt jedoch fehl Konfiguration, Berechtigung, Datenbank oder Anwendung
Dienst funktioniert teilweise Nur bestimmte Benutzer oder Funktionen sind betroffen Rechte, Mandant, Backend, Datenbestand oder Lastproblem

Diese Zustände dürfen nicht miteinander verwechselt werden. Die Fehlersuche beginnt immer bei der niedrigsten noch nicht nachgewiesenen Funktionsebene.

3. Schnellprüfung unter Windows, Linux und macOS

Die folgenden Befehle liefern eine erste Übersicht. <DIENST> und <PORT> müssen durch die tatsächlichen Werte ersetzt werden.

Aufgabe Windows Linux macOS
Rechnername [RO] hostname [RO] hostnamectl [RO] scutil --get ComputerName
Systemlaufzeit [RO] (Get-CimInstance Win32_OperatingSystem).LastBootUpTime [RO] uptime [RO] uptime
Dienststatus [RO] Get-Service -Name "<DIENST>" [RO] systemctl status <DIENST> --no-pager [RO] launchctl print system/<DIENST>
Alle laufenden Dienste [RO] Get-Service | Where-Object Status -eq "Running" [RO] systemctl list-units --type=service --state=running [RO] launchctl list
Prozess suchen [RO] Get-Process -Name "<PROZESS>" -ErrorAction SilentlyContinue [RO] pgrep -a <PROZESS> [RO] pgrep -alf <PROZESS>
TCP-Listener anzeigen [RO] Get-NetTCPConnection -State Listen [RO][PRIV] sudo ss -lntp [RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN
Bestimmten Port prüfen [RO] Get-NetTCPConnection -LocalPort <PORT> -ErrorAction SilentlyContinue [RO][PRIV] sudo ss -lntp "sport = :<PORT>" [RO][PRIV] sudo lsof -nP -iTCP:<PORT> -sTCP:LISTEN
Remote-TCP-Port testen [TEST] Test-NetConnection <SERVER> -Port <PORT> [TEST] nc -vz <SERVER> <PORT> [TEST] nc -vz <SERVER> <PORT>
CPU und Arbeitsspeicher [RO] Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 [RO] top [RO] top -o cpu
Freien Speicherplatz prüfen [RO] Get-Volume [RO] df -hT [RO] df -h

launchctl print system/<DIENST> benötigt das Dienstlabel und nicht zwingend den sichtbaren Namen einer Anwendung. Benutzerbezogene LaunchAgents befinden sich außerdem nicht in der Systemdomäne.

4. Reihenfolge der praktischen Fehlersuche
  1. Störung und betroffene Funktion genau beschreiben.
  2. Zeitpunkt und Dauer der Störung erfassen.
  3. Prüfen, welche Benutzer, Clients und Standorte betroffen sind.
  4. Letzte Änderungen und bekannte Wartungsarbeiten ermitteln.
  5. Servername und Zielsystem eindeutig bestimmen.
  6. DNS-Auflösung und Netzwerkpfad überprüfen.
  7. Erreichbarkeit des benötigten Ports testen.
  8. Dienststatus, Prozess und Startart kontrollieren.
  9. Kontrollieren, auf welcher Adresse und welchem Port der Dienst lauscht.
  10. Abhängige Dienste und externe Systeme überprüfen.
  11. System- und Anwendungsprotokolle für den Störungszeitraum auswerten.
  12. CPU, Arbeitsspeicher, Datenträger und offene Dateien prüfen.
  13. Konfiguration, Berechtigungen und Zertifikate kontrollieren.
  14. Einen gezielten Funktionstest durchführen.
  15. Erst danach eine geeignete Maßnahme planen.
  16. Nach der Maßnahme Funktion und Nebenwirkungen überprüfen.
  17. Ursache, Maßnahme und Ergebnis dokumentieren.
5. Kapitelübersicht
Seite Thema Inhalt
4.0 Server- und Dienstfehler systematisch analysieren Kapitelübersicht und Diagnosemodell
4.1 Störung und betroffenen Dienst eingrenzen Benutzer, Clients, Standorte und Zeiträume
4.2 Dienststatus und Startart prüfen Windows-Dienste, systemd und launchd
4.3 Prozesse und Prozesszustände analysieren PID, Elternprozess, Laufzeit und Ressourcen
4.4 Listener, Ports und Bindungsadressen prüfen TCP, UDP, IPv4, IPv6 und Loopback
4.5 Dienstabhängigkeiten untersuchen Abhängige Dienste, Backends und Startreihenfolge
4.6 System- und Dienstprotokolle auswerten Ereignisanzeige, Journal und Unified Logging
4.7 Dienststartfehler analysieren Exitcodes, Zeitüberschreitungen und Abstürze
4.8 Konfigurationsfehler untersuchen Syntax, Pfade, Parameter und Umgebungsvariablen
4.9 Benutzer-, Dienstkonto- und Berechtigungsfehler Konten, Dateirechte und Zugriffstoken
4.10 Ressourcenengpässe erkennen CPU, RAM, Datenträger und Dateideskriptoren
4.11 Speicherplatz- und Dateisystemfehler Volumes, Inodes, Quotas und schreibgeschützte Dateisysteme
4.12 Zertifikats- und TLS-Probleme Gültigkeit, Vertrauenskette, Name und Protokoll
4.13 Webserver und HTTP-Dienste analysieren HTTP-Statuscodes, Header, Logs und virtuelle Hosts
4.14 Datenbankverbindungen analysieren Port, Anmeldung, Berechtigungen und Verbindungspools
4.15 Datei- und Freigabedienste analysieren SMB, NFS, Berechtigungen und Sperren
4.16 Druckdienste und Warteschlangen analysieren Spooler, Druckaufträge, Treiber und Erreichbarkeit
4.17 Wiederkehrende Dienstabbrüche untersuchen Crash-Loops, Neustartregeln und Ursachenanalyse
4.18 Dienste kontrolliert neu starten Risikoanalyse, Abhängigkeiten und Funktionstest
4.19 Befehlsübersicht – Server- und Dienstdiagnose Vergleichstabelle für Windows, Linux und macOS
6. Entscheidungsweg bei einem nicht erreichbaren Dienst
Prüfschritt Ergebnis Nächste Aktion
Wird der richtige Servername verwendet? Nein Zielsystem und Dokumentation korrigieren
Wird der Name korrekt aufgelöst? Nein DNS-Konfiguration untersuchen
Ist der Server über das Netzwerk erreichbar? Nein Netzwerkpfad, VLAN, Routing und Firewall prüfen
Ist der benötigte Port erreichbar? Nein Listener, Dienststatus und Paketfilter prüfen
Läuft der Dienstprozess? Nein Startfehler und Protokolle untersuchen
Lauscht der Prozess auf dem erwarteten Port? Nein Bindungsadresse und Konfiguration prüfen
Antwortet das Anwendungsprotokoll? Nein Dienstprotokoll, TLS und Abhängigkeiten prüfen
Funktioniert die Anmeldung? Nein Konto, Kennwort, Berechtigungen und Identitätsdienst prüfen
Funktioniert die gewünschte Aktion? Nein Anwendung, Backend und Datenbestand untersuchen
Funktioniert alles wieder? Ja Ursache und Lösung dokumentieren
7. Wichtige Informationen vor einem Dienstneustart

Vor einem Neustart müssen mindestens folgende Fragen beantwortet werden:

Ein Neustart kann die Verfügbarkeit kurzfristig wiederherstellen, beseitigt aber nicht automatisch die eigentliche Fehlerursache. Vorher sollten Zustand, Zeitstempel, Fehlermeldungen und relevante Protokolle erfasst werden.

8. Mindestdokumentation eines Dienstfehlers
Information Beispiel
Betroffener Dienst Intranet-Webanwendung
Server srv-web01.example.local
Betriebssystem Windows Server beziehungsweise Linux-Distribution und Version
Beginn der Störung Datum und genaue Uhrzeit mit Zeitzone
Betroffene Benutzer Alle Benutzer am Standort Berlin
Fehlerbild HTTP-Verbindung wird aufgebaut, Antwortcode 503
Dienststatus Dienst läuft beziehungsweise ist beendet
Prozess Prozessname und PID
Port und Bindungsadresse TCP 443 auf einer bestimmten IP-Adresse
Relevante Protokollmeldung Ereignis-ID, Exitcode oder Fehlermeldung
Letzte Änderung Aktualisierung oder Konfigurationsänderung
Durchgeführte Prüfungen DNS-, Port-, Dienst- und Funktionstest
Maßnahme Konfiguration korrigiert und Dienst kontrolliert neu gestartet
Funktionstest Anmeldung und Beispielabfrage erfolgreich
Ursache Technische Grundursache
Vorbeugung Monitoring, Dokumentation oder Konfigurationsprüfung

Merksatz

Erreichbarkeit beweist nur den Netzwerkweg. Ein offener Port beweist nur einen Listener. Erst ein erfolgreicher Anwendungstest beweist die Funktion des Dienstes.

Weiterführende Quellen

4. Server- und Dienstfehler systematisch analysieren

4.1 Störung und betroffenen Dienst eingrenzen

Bevor Prozesse, Ports oder Protokolldateien untersucht werden, muss eindeutig feststehen, welche Funktion tatsächlich gestört ist. Eine Meldung wie „Der Server funktioniert nicht“ reicht für eine gezielte Fehleranalyse nicht aus.

Grundsatz:
Zuerst das Fehlerbild und den Störungsumfang bestimmen. Erst danach mit technischen Prüfungen beginnen.

Ziele dieser Seite

Nach dieser Seite sollst du:

1. Ruhig und hypothesenoffen beginnen

Bei einer Störung entsteht schnell der Wunsch, sofort einen Dienst neu zu starten oder eine bekannte Lösung auszuprobieren. Dadurch können jedoch wichtige Diagnoseinformationen verloren gehen.

Eine sinnvolle Haltung lautet:

  1. Störungsmeldung nicht ungeprüft als Ursache übernehmen.
  2. Beobachtungen von Vermutungen trennen.
  3. Noch keine technische Ursache festlegen.
  4. Zuerst den Umfang der Störung bestimmen.
  5. Mit einfachen und möglichst lesenden Prüfungen beginnen.
  6. Pro Arbeitsschritt nur eine wesentliche Veränderung durchführen.
  7. Vor und nach jeder Maßnahme vergleichen.
  8. Ergebnisse und Zeitpunkte dokumentieren.
Aussage Einordnung
„Das Intranet ist nicht erreichbar.“ Beobachtung beziehungsweise Fehlerbild
„Der Webserver ist abgestürzt.“ Noch unbestätigte Hypothese
„TCP-Port 443 antwortet nicht.“ Technisches Prüfergebnis
„Der Webdienst befindet sich im Zustand Stopped.“ Technisches Prüfergebnis
„Der Dienst wurde durch fehlenden Speicher beendet.“ Mögliche Ursache, die durch Protokolle belegt werden muss

Wichtig: Eine Fehlermeldung beschreibt häufig nur die Stelle, an der ein Fehler sichtbar wird – nicht die eigentliche Ursache.

2. Aus einer Störungsmeldung ein konkretes Fehlerbild erstellen

Eine gute Fehlerbeschreibung beantwortet mindestens folgende Fragen:

Frage Beispiel
Was funktioniert nicht? Anmeldung an der internen Webanwendung
Welche konkrete Aktion schlägt fehl? Absenden des Anmeldeformulars
Welche Fehlermeldung erscheint? HTTP-Statuscode 503
Seit wann besteht das Problem? Seit 31.07.2026 um 09:15 Uhr
Tritt der Fehler dauerhaft oder zeitweise auf? Bei jedem Anmeldeversuch
Wer ist betroffen? Alle Benutzer am Standort Berlin
Welche Clients sind betroffen? Windows-, Linux- und macOS-Clients
Welche Funktion arbeitet weiterhin? Startseite der Anwendung ist erreichbar
Wurde eine alternative Verbindung getestet? Zugriff über einen zweiten Client ebenfalls fehlerhaft
Was wurde zuletzt verändert? Aktualisierung der Anwendung am Vorabend

Unzureichende Beschreibung:

„Der Server geht nicht.“

Verwertbare Beschreibung:

„Seit 09:15 Uhr erhalten alle geprüften Benutzer beim Anmelden an https://intranet.example.local den HTTP-Statuscode 503. Die Namensauflösung funktioniert und die Startseite ist erreichbar. Der Fehler tritt von mehreren Clients und Benutzerkonten aus auf.“

3. Störungsumfang mit einer Eingrenzungsmatrix bestimmen
Prüfdimension Mögliche Eingrenzung
Benutzer Ein Benutzer, Benutzergruppe oder alle Benutzer
Endgerät Ein Client, Gerätetyp oder alle Clients
Betriebssystem Nur Windows, Linux, macOS oder alle Systeme
Standort Ein Raum, Gebäude, Standort oder alle Standorte
Netzwerk LAN, WLAN, VPN, Gastnetz oder alle Zugangswege
Anwendung Eine Funktion, ein Modul oder vollständige Anwendung
Dienst Ein Dienst, mehrere Dienste oder gesamter Server
Zeitpunkt Dauerhaft, sporadisch, zu bestimmten Uhrzeiten
Daten Einzelne Datei, Datensatz, Freigabe oder alle Daten
Berechtigung Einzelnes Konto, Rolle, Gruppe oder alle Konten
Protokoll HTTP, HTTPS, SMB, SSH, RDP oder Datenbankverbindung
Backend Datenbank, Verzeichnisdienst, Speicher oder externe API

Beispiele für Schlussfolgerungen:

Beobachtung Wahrscheinlicher Untersuchungsbereich
Nur ein Benutzer ist betroffen Konto, Profil, Berechtigung oder benutzerspezifische Daten
Nur ein Client ist betroffen Clientkonfiguration, Cache, Zertifikat oder lokale Firewall
Alle Benutzer eines Standortes sind betroffen Standortnetz, WAN, DNS, Routing oder Firewall
Alle Benutzer sind betroffen Zentraler Dienst, Server, Backend oder globale Änderung
Nur ein Anwendungsmodul ist betroffen Modulkonfiguration, Backend oder Berechtigung
Zugriff per IP-Adresse funktioniert, per Name nicht DNS oder Namenskonfiguration
TCP-Port ist offen, Anwendung antwortet fehlerhaft Anwendung, Backend, TLS oder Berechtigung
Fehler tritt nur unter hoher Last auf Ressourcen, Grenzwerte, Verbindungspool oder Zeitüberschreitung

Diese Zuordnungen sind Arbeitshypothesen und noch kein endgültiger Ursachenbeweis.

4. Betroffenen Server und Dienst eindeutig identifizieren

Vor der technischen Prüfung müssen folgende Angaben geklärt werden:

Information Beispiel
Angezeigter Dienstname Interne Webanwendung
Technischer Dienstname intranet-api
Prozessname intranet-api.exe beziehungsweise intranet-api
Servername srv-app01.example.local
IP-Adresse 192.0.2.20
Protokoll HTTPS
Zielport TCP 443
Pfad oder URL https://intranet.example.local/login
Backend srv-db01.example.local
Verantwortliches System Webserver, Anwendungsdienst oder Datenbank
Produktivstatus Produktiv-, Test- oder Entwicklungssystem

Der sichtbare Name einer Anwendung, der Betriebssystem-Dienstname und der Prozessname können unterschiedlich sein.

Beispiel einer Dienstkette:

Client
  → DNS
  → Firewall oder Loadbalancer
  → Webserver
  → Anwendungsdienst
  → Datenbank
  → Verzeichnisdienst oder externe API

Die Störung kann an jeder Übergabestelle dieser Kette entstehen.

5. Basisinformationen des untersuchten Servers erfassen

Die folgenden Befehle verändern den Systemzustand normalerweise nicht.

Aufgabe Windows PowerShell Linux macOS
Rechnername [RO] hostname [RO] hostname [RO] hostname
Vollständiger DNS-Name [RO] [System.Net.Dns]::GetHostEntry($env:COMPUTERNAME).HostName [RO] hostname --fqdn [RO] hostname -f
Betriebssysteminformationen [RO] Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber [RO][FILE] cat /etc/os-release [RO] sw_vers
Systemarchitektur [RO] $env:PROCESSOR_ARCHITECTURE [RO] uname -m [RO] uname -m
Kernel beziehungsweise Systemversion [RO] systeminfo [RO] uname -a [RO] uname -a
Letzter Systemstart [RO] (Get-CimInstance Win32_OperatingSystem).LastBootUpTime [RO] uptime -s [RO] sysctl -n kern.boottime
Aktuelle Laufzeit [RO] (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime [RO] uptime [RO] uptime
Aktuelle Uhrzeit [RO] Get-Date -Format o [RO] date --iso-8601=seconds [RO] date "+%Y-%m-%dT%H:%M:%S%z"
Zeitzone [RO] Get-TimeZone [RO] timedatectl status [RO][PRIV] sudo systemsetup -gettimezone
Angemeldete Benutzer [RO] quser [RO] who [RO] who

Hinweise:

6. Dienstnamen und Prozesse zunächst nur lesend suchen

Die Platzhalter <SUCHBEGRIFF>, <DIENST> und <PROZESS> müssen ersetzt werden.

Aufgabe Windows PowerShell Linux macOS
Dienst nach Namen suchen [RO] Get-Service -Name "*<SUCHBEGRIFF>*" -ErrorAction SilentlyContinue [RO] systemctl list-unit-files --type=service | grep -i -- "<SUCHBEGRIFF>" [RO] launchctl list | grep -i -- "<SUCHBEGRIFF>"
Dienst nach Anzeigenamen suchen [RO] Get-Service -DisplayName "*<SUCHBEGRIFF>*" -ErrorAction SilentlyContinue Nicht getrennt vorhanden Nicht getrennt vorhanden
Status eines Dienstes [RO] Get-Service -Name "<DIENST>" [RO] systemctl status "<DIENST>" --no-pager [RO] launchctl print "system/<DIENST>"
Prozess nach Namen suchen [RO] Get-Process -Name "<PROZESS>" -ErrorAction SilentlyContinue [RO] pgrep -a "<PROZESS>" [RO] pgrep -alf "<PROZESS>"
Prozesse ausführlich anzeigen [RO] Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId,Name,CommandLine [RO] ps -eo user,pid,ppid,lstart,stat,cmd [RO] ps -axo user,pid,ppid,lstart,state,command

Besonderheiten:

Auf dieser frühen Diagnosestufe sollte ein Dienst noch nicht neu gestartet werden. Zuerst müssen Status, Prozess, Port und relevante Protokolle erfasst werden.

7. Geeignete Vergleichstests durchführen

Ein Vergleichstest verändert jeweils nur eine Prüfdimension. Dadurch lässt sich erkennen, welche Eigenschaft mit dem Fehler zusammenhängt.

Ausgangssituation Sinnvoller Vergleich
Ein Benutzer meldet einen Fehler Anderes Benutzerkonto am gleichen Client
Ein Client ist betroffen Gleicher Benutzer an einem anderen Client
WLAN-Zugriff scheitert Gleicher Client über LAN oder VPN
Zugriff per Servername scheitert DNS-Ergebnis prüfen und mit dokumentierter Zieladresse vergleichen
Eine URL funktioniert nicht Andere Funktion desselben Dienstes testen
Ein Standort ist betroffen Zugriff von einem anderen Standort testen
Zugriff über Loadbalancer scheitert Backend nur über den vorgesehenen administrativen Testweg prüfen
Anwendung meldet einen Fehler Porttest und protokollspezifischen Funktionstest getrennt durchführen
Produktivsystem ist betroffen Verhalten im freigegebenen Testsystem vergleichen
Fehler tritt zeitabhängig auf Ergebnisse mit Last, Sicherung oder geplanten Aufgaben vergleichen

Regel für einen aussagekräftigen Vergleich:

Gleicher Benutzer + anderer Client
oder
anderer Benutzer + gleicher Client
oder
gleicher Client + anderer Netzwerkweg

Werden mehrere Eigenschaften gleichzeitig verändert, ist das Ergebnis häufig nicht eindeutig.

Der direkte Zugriff auf ein Backend kann Sicherheitsregeln, Authentifizierung, TLS-Prüfungen oder den Loadbalancer umgehen. Er darf nur über einen freigegebenen administrativen Testweg erfolgen.

8. Ersten Client-zu-Dienst-Test dokumentieren

Bevor auf dem Server weitergesucht wird, sollte der Fehler möglichst reproduziert und genau protokolliert werden.

Prüfpunkte Zu dokumentierende Information
Ausgangsgerät Hostname, Betriebssystem und Netzwerkverbindung
Benutzerkontext Betroffenes Konto oder Rolle, ohne Kennwort
Ziel Servername, URL, Freigabe oder Anwendung
Zeitpunkt Datum, Uhrzeit und Zeitzone
Aktion Exakter Arbeitsschritt, der den Fehler auslöst
Ergebnis Vollständige Fehlermeldung oder Statuscode
Dauer Sofortiger Fehler oder Zeitüberschreitung
Wiederholbarkeit Immer, sporadisch oder nur einmal
Vergleichstest Zweiter Client, Benutzer oder Netzwerkweg
Beweismittel Screenshot, Ereignis-ID, Logauszug oder Befehlsausgabe

Beispiel:

Zeitpunkt:       2026-07-31T09:15:42+02:00
Client:          client-017
Betriebssystem:  Windows 11
Benutzerrolle:   Standardbenutzer
Ziel:            https://intranet.example.local/login
Aktion:          Anmeldeformular abgesendet
Ergebnis:        HTTP 503
Dauer:           Antwort nach ungefähr 2 Sekunden
Wiederholbar:    Ja
Vergleich:       Gleicher Fehler auf einem zweiten Client

Sensible Inhalte wie Kennwörter, Sitzungscookies, Zugriffstoken, private Schlüssel oder vollständige personenbezogene Daten dürfen nicht in die Dokumentation übernommen werden.

9. Letzte Änderungen und zeitliche Zusammenhänge erfassen

Viele Dienstfehler entstehen nach einer technischen oder organisatorischen Änderung. Ein zeitlicher Zusammenhang ist jedoch noch kein Beweis für die Ursache.

Zu prüfen sind insbesondere:

Frage Zweck
Was wurde geändert? Technische Änderung bestimmen
Wann wurde es geändert? Zeitliche Übereinstimmung prüfen
Auf welchem System? Betroffene Komponente bestimmen
Wer oder welcher Prozess führte die Änderung aus? Rückfragen und Audit ermöglichen
Wurde die Änderung getestet? Fehlende Prüfungen erkennen
Gibt es einen Rückfallplan? Wiederherstellung bewerten
Besteht der Fehler auch ohne diese Änderung? Kausalität weiter untersuchen

Die Aussage „Seit dem Update besteht der Fehler“ ist eine wichtige Spur. Erst ein reproduzierbarer Zusammenhang oder ein passender Protokolleintrag macht daraus einen belastbaren Ursachenhinweis.

10. Wann die Eingrenzung abgeschlossen ist

Die erste Eingrenzung ist ausreichend, wenn folgende Punkte beantwortet sind:

Beispiel einer abgeschlossenen Eingrenzung:

Alle geprüften Benutzer können die Startseite des Intranets über HTTPS aufrufen. Beim Absenden des Anmeldeformulars antwortet die Anwendung jedoch mit HTTP 503. Der Fehler tritt von Windows-, Linux- und macOS-Clients sowie an zwei Standorten auf. DNS-Auflösung und Netzwerkzugriff funktionieren. Als Nächstes werden deshalb Dienststatus, Prozess und Backend-Abhängigkeiten auf dem Anwendungsserver geprüft.

11. Typische Fehler bei der ersten Eingrenzung
Fehler Folge Bessere Vorgehensweise
Sofortiger Neustart Flüchtige Diagnoseinformationen gehen verloren Zustand und Protokolle zuerst sichern
Fehlermeldung als Ursache behandeln Untersuchung beginnt an der falschen Stelle Beobachtung und Ursache trennen
Nur einen Benutzer befragen Störungsumfang bleibt unbekannt Vergleich mit weiteren Benutzern durchführen
Nur ping verwenden Dienstfunktion bleibt ungeprüft Port- und Anwendungstest ergänzen
Mehrere Änderungen gleichzeitig Wirkung einzelner Maßnahmen bleibt unklar Änderungen einzeln durchführen
Servername nicht verifizieren Falsches System wird untersucht Ziel, IP-Adresse und Umgebung abgleichen
Test- und Produktivsystem verwechseln Falsche Ergebnisse oder Betriebsrisiko Umgebung eindeutig dokumentieren
Keine Zeitstempel erfassen Protokolle lassen sich schlecht zuordnen Datum, Uhrzeit und Zeitzone notieren
Nur Erfolg oder Fehler notieren Diagnose ist nicht nachvollziehbar Befehl, Ausgabe und Kontext dokumentieren
Geheimnisse in Tickets kopieren Sicherheitsrisiko Kennwörter, Token und Cookies entfernen
12. Kompakte Checkliste für den Einsatz 
[ ] Konkrete gestörte Funktion erfasst
[ ] Vollständige Fehlermeldung erfasst
[ ] Datum, Uhrzeit und Zeitzone notiert
[ ] Betroffene Benutzer bestimmt
[ ] Betroffene Clients und Betriebssysteme bestimmt
[ ] Betroffene Standorte und Netzwerkwege bestimmt
[ ] Funktionierende Bereiche dokumentiert
[ ] Fehler reproduziert
[ ] Vergleichstest durchgeführt
[ ] Servername und Umgebung verifiziert
[ ] Dienstname, Prozess, Protokoll und Port zugeordnet
[ ] Abhängige Systeme aufgenommen
[ ] Letzte Änderungen erfragt
[ ] Ausgangszustand vor Änderungen dokumentiert
[ ] Keine Kennwörter, Token oder vertraulichen Daten gespeichert
[ ] Nächster technischer Prüfschritt festgelegt

Ergebnis dieser Diagnosestufe

Am Ende dieser Seite steht noch nicht zwingend die Ursache fest. Es muss jedoch klar sein:

Was ist gestört?
Wer oder was ist betroffen?
Seit wann besteht die Störung?
Welcher Dienst stellt die Funktion bereit?
Auf welchem System läuft er?
Wie lässt sich der Fehler reproduzieren?
Welche technische Ebene wird als Nächstes geprüft?

Die nächste Diagnosestufe ist die Überprüfung von Dienststatus und Startart.

Weiterführende Quellen

4. Server- und Dienstfehler systematisch analysieren

4.2 Dienststatus und Startart prüfen

Nachdem der betroffene Dienst eindeutig bestimmt wurde, wird geprüft, ob er:

Grundsatz:
Zuerst den vorhandenen Zustand vollständig erfassen. Einen Dienst erst danach und nur bei betrieblicher Freigabe starten, stoppen oder neu starten.

Ziele dieser Seite

Nach dieser Seite sollst du:

Sicherheitskennzeichnungen

Kennzeichnung Bedeutung
[RO] Rein lesende Abfrage
[TEST] Aktiver Test ohne beabsichtigte dauerhafte Konfigurationsänderung
[PRIV] Erfordert möglicherweise erhöhte Rechte
[FILE] Greift lesend oder schreibend auf eine Datei zu
[SENS] Ausgabe kann sensible Informationen enthalten
[CHANGE] Verändert den Dienstzustand oder die Konfiguration
[DISRUPT] Kann laufende Verbindungen oder Arbeitsvorgänge unterbrechen
1. Startart und Dienststatus nicht verwechseln

Die Startart beschreibt, wann beziehungsweise wodurch ein Dienst gestartet werden soll. Der Dienststatus beschreibt seinen aktuellen Zustand.

Startart beziehungsweise Aktivierung Aktueller Zustand Mögliche Bewertung
Automatisch aktiviert Läuft Normaler Zustand
Automatisch aktiviert Beendet Startfehler, Absturz oder bewusster Stopp möglich
Manuell beziehungsweise bedarfsgesteuert Beendet Kann ein normaler Zustand sein
Manuell beziehungsweise bedarfsgesteuert Läuft Dienst wurde angefordert oder manuell gestartet
Deaktiviert Beendet Erwarteter Zustand
Deaktiviert Läuft Zustandsänderung möglicherweise noch nicht wirksam oder Sonderfall
Aktiviert Wiederholt startend und stoppend Absturzschleife oder fehlerhafte Startbedingung möglich

Ein beendeter Dienst ist nicht automatisch fehlerhaft. Bedarfsgesteuerte Dienste laufen häufig nur, wenn sie tatsächlich benötigt werden.

2. Dienstverwaltung der Betriebssysteme vergleichen
Betriebssystem Dienstverwaltung Konfigurationseinheit Typische Statusabfrage
Windows Service Control Manager Windows-Dienst Get-Service oder sc.exe query
Linux mit systemd systemd Unit, meistens .service systemctl status
macOS launchd Daemon, Agent oder XPC-Service launchctl print

Wichtige Unterschiede:

3. Dienststatus unter Windows prüfen

<DIENSTNAME> muss durch den internen Dienstnamen ersetzt werden.

Status eines bestimmten Dienstes:

[RO] Get-Service -Name "<DIENSTNAME>"

Ausgewählte Statusinformationen anzeigen:

[RO] Get-Service -Name "<DIENSTNAME>" |
    Select-Object Name, DisplayName, Status, ServiceType

Mit einem Teil des Dienstnamens suchen:

[RO] Get-Service -Name "*<SUCHBEGRIFF>*" -ErrorAction SilentlyContinue

Mit einem Teil des Anzeigenamens suchen:

[RO] Get-Service -DisplayName "*<SUCHBEGRIFF>*" -ErrorAction SilentlyContinue

Alle beendeten Dienste anzeigen:

[RO] Get-Service |
    Where-Object Status -eq "Stopped" |
    Sort-Object DisplayName

Alle laufenden Dienste anzeigen:

[RO] Get-Service |
    Where-Object Status -eq "Running" |
    Sort-Object DisplayName

Dienststatus mit sc.exe abfragen:

[RO] sc.exe query "<DIENSTNAME>"

Erweiterte Statusabfrage einschließlich Prozess-ID:

[RO] sc.exe queryex "<DIENSTNAME>"

Typische Zustände sind:

Zustand Bedeutung
Running beziehungsweise RUNNING Dienst wird ausgeführt
Stopped beziehungsweise STOPPED Dienst wird nicht ausgeführt
StartPending beziehungsweise START_PENDING Startvorgang läuft
StopPending beziehungsweise STOP_PENDING Beendigung läuft
PausePending Pausierung wird vorbereitet
Paused Dienst ist pausiert
ContinuePending Fortsetzung wird vorbereitet

Bleibt ein Dienst ungewöhnlich lange in StartPending oder StopPending, müssen Prozess, Abhängigkeiten und Ereignisprotokolle untersucht werden. Ein erzwungener Abbruch ist nicht der erste Diagnoseschritt.

4. Startart und Dienstkonto unter Windows prüfen

Get-Service zeigt den Laufzustand, aber nicht alle Konfigurationsinformationen. Dafür kann die CIM-Klasse Win32_Service verwendet werden.

Vollständige Basiskonfiguration eines Dienstes:

[RO][SENS] Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'" |
    Select-Object Name,
                  DisplayName,
                  State,
                  Status,
                  StartMode,
                  StartName,
                  ProcessId,
                  ExitCode,
                  ServiceSpecificExitCode,
                  PathName

Nur Startart und Dienstkonto anzeigen:

[RO] Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'" |
    Select-Object Name, State, StartMode, StartName

Konfiguration mit sc.exe prüfen:

[RO][SENS] sc.exe qc "<DIENSTNAME>"

Typische Werte für StartMode:

Wert Bedeutung
Auto Automatischer Start
Manual Manueller beziehungsweise bedarfsgesteuerter Start
Disabled Dienst ist deaktiviert
Boot Start durch den Systemlader, normalerweise bei Treibern
System Start während der Kernelinitialisierung, normalerweise bei Treibern

Typische Angaben von sc.exe qc:

Angabe Bedeutung
SERVICE_NAME Interner Dienstname
TYPE Art des Dienstes oder Treibers
START_TYPE Konfigurierte Startart
ERROR_CONTROL Verhalten bei Startfehlern während des Systemstarts
BINARY_PATH_NAME Programmdatei und Startparameter
DEPENDENCIES Konfigurierte Abhängigkeiten
SERVICE_START_NAME Verwendetes Dienstkonto

[SENS]: Programmpfade und Startparameter können interne Verzeichnisstrukturen, Servernamen oder andere schützenswerte Konfigurationsangaben enthalten.

5. Verzögerten automatischen Start unter Windows prüfen

Die Startart Auto allein zeigt nicht immer, ob der automatische Start verzögert erfolgt.

Dienstkonfiguration über CIM prüfen:

[RO] Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'" |
    Select-Object Name, State, StartMode, DelayedAutoStart

Interpretation:

StartMode DelayedAutoStart Bedeutung
Auto False Normaler automatischer Start
Auto True Verzögerter automatischer Start
Manual False Manueller oder bedarfsgesteuerter Start
Disabled False Dienst ist deaktiviert

Falls DelayedAutoStart auf dem untersuchten System nicht ausgegeben wird, kann der Wert gezielt in der Dienstkonfiguration der Registrierung geprüft werden:

[RO] Get-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Services\<DIENSTNAME>" `
    -Name DelayedAutoStart `
    -ErrorAction SilentlyContinue

Dabei gilt üblicherweise:

Wert Bedeutung
1 Verzögerter automatischer Start aktiviert
0 oder nicht vorhanden Kein verzögerter Start daraus ableitbar

Die Registrierung darf an dieser Stelle nur gelesen werden. Eine Änderung der Startart gehört in ein freigegebenes Änderungsverfahren.

6. Dienststatus unter Linux mit systemd prüfen

<DIENST> muss durch den tatsächlichen Unit-Namen ersetzt werden, beispielsweise nginx.service.

Ausführlichen Status anzeigen:

[RO] systemctl status "<DIENST>" --no-pager

Aktuellen Laufzustand abfragen:

[RO] systemctl is-active "<DIENST>"

Prüfen, ob die Unit für einen automatischen Start aktiviert ist:

[RO] systemctl is-enabled "<DIENST>"

Prüfen, ob die Unit fehlgeschlagen ist:

[RO] systemctl is-failed "<DIENST>"

Wichtige Eigenschaften kompakt anzeigen:

[RO] systemctl show "<DIENST>" \
  --property=Id,Names,LoadState,ActiveState,SubState,UnitFileState,MainPID,ExecMainCode,ExecMainStatus,Result

Alle fehlgeschlagenen Units anzeigen:

[RO] systemctl --failed --no-pager

Laufende Dienste anzeigen:

[RO] systemctl list-units \
  --type=service \
  --state=running \
  --no-pager

Installierte Service-Unit-Dateien und Aktivierungszustände anzeigen:

[RO] systemctl list-unit-files --type=service --no-pager

systemctl status zeigt zusätzlich einige aktuelle Protokollzeilen. Für eine vollständige Protokollanalyse wird später gezielt journalctl verwendet.

7. systemd-Zustände richtig interpretieren

systemd verwendet mehrere voneinander unabhängige Zustandsangaben.

Ladezustand:

LoadState Bedeutung
loaded Unit-Datei wurde erfolgreich geladen
not-found Keine passende Unit-Datei gefunden
error Fehler beim Laden
masked Unit wurde maskiert und kann nicht normal gestartet werden

Aktivzustand:

ActiveState Bedeutung
active Unit ist aktiv
inactive Unit ist nicht aktiv
activating Aktivierung läuft
deactivating Deaktivierung läuft
failed Aktivierung oder Ausführung ist fehlgeschlagen
reloading Konfiguration wird neu geladen

Typische Aktivierungszustände:

systemctl is-enabled Bedeutung
enabled Für einen vorgesehenen automatischen Start aktiviert
enabled-runtime Nur bis zum nächsten Neustart aktiviert
disabled Nicht für automatischen Start aktiviert
static Keine eigene Aktivierung über einen Installationsabschnitt; kann abhängig gestartet werden
indirect Indirekte Aktivierung über eine andere Unit vorgesehen
masked Start vollständig blockiert
masked-runtime Bis zum nächsten Neustart maskiert
generated Unit wurde dynamisch erzeugt
transient Temporäre Unit
not-found Unit wurde nicht gefunden

Wichtige Kombinationen:

Laufzustand Aktivierungszustand Bewertung
active enabled Läuft und ist dauerhaft aktiviert
inactive enabled Sollte möglicherweise laufen; Start- und Protokollprüfung erforderlich
active disabled Wurde manuell, abhängig oder auf anderem Weg gestartet
inactive static Kann bei bedarfsgesteuerten oder abhängigen Units normal sein
failed beliebig Fehlerursache und Protokolle untersuchen
inactive masked Start ist absichtlich blockiert

disabled bedeutet nicht automatisch „defekt“. Es bedeutet zunächst nur, dass die Unit nicht über ihre normalen Installationsverknüpfungen für den automatischen Start aktiviert ist.

8. systemd-Unit-Datei und Startbefehl prüfen

Wirksame Unit-Datei einschließlich Ergänzungen anzeigen:

[RO][FILE][SENS] systemctl cat "<DIENST>"

Pfad der geladenen Unit-Datei anzeigen:

[RO] systemctl show "<DIENST>" --property=FragmentPath

Ergänzende Drop-in-Konfigurationen anzeigen:

[RO] systemctl show "<DIENST>" --property=DropInPaths

Startbefehl und Dienstkonto anzeigen:

[RO][SENS] systemctl show "<DIENST>" \
  --property=User,Group,ExecStart,WorkingDirectory,EnvironmentFiles

Abhängigkeiten anzeigen:

[RO] systemctl list-dependencies "<DIENST>" --no-pager

Prüfen, wodurch die Unit für den Systemstart eingebunden ist:

[RO] systemctl is-enabled "<DIENST>"

Die Ausgabe von systemctl cat kann enthalten:

[SENS]: Unit-Dateien können interne Pfade, Serveradressen oder Umgebungsdateien referenzieren. Die Inhalte von geheimen Umgebungsdateien dürfen nicht ungeprüft in Tickets oder Dokumentationen kopiert werden.

9. Dienststatus unter macOS mit launchd prüfen

macOS unterscheidet unter anderem folgende Domains:

Domain Bedeutung Beispiel
system Systemweite Dienste system/com.example.service
user/<UID> Dienste eines Benutzerkontextes user/501/com.example.service
gui/<UID> Dienste einer grafischen Anmeldesitzung gui/501/com.example.agent

Benutzer-ID des aktuell angemeldeten Terminalbenutzers anzeigen:

[RO] id -u

Systemweiten Dienst prüfen:

[RO] launchctl print "system/<LABEL>"

Dienst im GUI-Kontext des aktuellen Benutzers prüfen:

[RO] launchctl print "gui/$(id -u)/<LABEL>"

Gesamten Systembereich anzeigen:

[RO] launchctl print system

GUI-Bereich des aktuellen Benutzers anzeigen:

[RO] launchctl print "gui/$(id -u)"

Die Detailausgabe eines Dienstes kann unter anderem enthalten:

Die Ausgabe von launchctl print ist für die manuelle Diagnose bestimmt. Apple garantiert ihr Format nicht als stabile Schnittstelle für Skripte.

10. Deaktivierte launchd-Dienste unter macOS prüfen

Deaktivierungsüberschreibungen im Systembereich anzeigen:

[RO] launchctl print-disabled system

Deaktivierungsüberschreibungen im GUI-Bereich anzeigen:

[RO] launchctl print-disabled "gui/$(id -u)"

Ein Eintrag mit true bedeutet, dass der Dienst in dieser Domain deaktiviert wurde. Ein Eintrag mit false bedeutet, dass eine Aktivierungsüberschreibung vorhanden sein kann.

Wichtig:

11. launchd-Konfiguration unter macOS prüfen

Typische Speicherorte sind:

Pfad Bedeutung
/System/Library/LaunchDaemons Von macOS bereitgestellte systemweite Dienste
/Library/LaunchDaemons Zusätzlich installierte systemweite Dienste
/System/Library/LaunchAgents Von macOS bereitgestellte Benutzer-Agenten
/Library/LaunchAgents Zusätzlich installierte Benutzer-Agenten
~/Library/LaunchAgents Agenten des jeweiligen Benutzers

Dateien unter /System/Library gehören zum Betriebssystem und dürfen nicht manuell verändert werden.

Konfigurationsdatei eines bekannten Drittanbieterdienstes lesbar anzeigen:

[RO][FILE][SENS] plutil -p "/Library/LaunchDaemons/<LABEL>.plist"

Konfigurationsdatei auf formale plist-Fehler prüfen:

[RO][FILE] plutil -lint "/Library/LaunchDaemons/<LABEL>.plist"

Benutzerbezogenen Agenten anzeigen:

[RO][FILE][SENS] plutil -p "$HOME/Library/LaunchAgents/<LABEL>.plist"

Typische Schlüssel einer launchd-plist:

Schlüssel Bedeutung
Label Eindeutige Dienstbezeichnung
Program Auszuführendes Programm
ProgramArguments Programm und Argumente
RunAtLoad Start beim Laden der Jobdefinition
KeepAlive Bedingungen für Ausführung beziehungsweise Neustart
StartInterval Zeitgesteuerter Start in Sekundenabständen
StartCalendarInterval Kalenderbasierter Start
WatchPaths Start bei Änderungen überwachter Pfade
QueueDirectories Start, wenn ein überwachtes Verzeichnis nicht leer ist
UserName Benutzerkonto eines systemweiten Daemons
GroupName Gruppenkonto eines systemweiten Daemons
WorkingDirectory Arbeitsverzeichnis
StandardOutPath Datei für Standardausgabe
StandardErrorPath Datei für Fehlerausgabe
Disabled Standardvorgabe zur Deaktivierung; kann überschrieben werden

RunAtLoad, KeepAlive und andere Startbedingungen sind nicht direkt mit den Windows-Startarten gleichzusetzen. launchd ist stark auf bedarfs- und ereignisgesteuertes Starten ausgelegt.

12. Letzten Exitstatus und wiederholte Starts erkennen
Betriebssystem Prüfung
Windows Dienststatus, Prozess-ID, Exitcode und Ereignisprotokolle
Linux Result, ExecMainCode, ExecMainStatus, Neustartzähler und Journal
macOS state, pid, last exit code und Unified Logging

Windows:

[RO] Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'" |
    Select-Object Name, State, ProcessId, ExitCode, ServiceSpecificExitCode

Linux:

[RO] systemctl show "<DIENST>" \
  --property=ActiveState,SubState,Result,MainPID,ExecMainCode,ExecMainStatus,NRestarts

macOS:

[RO] launchctl print "system/<LABEL>"

Bei macOS sind insbesondere folgende Angaben relevant:

state
pid
last exit code
runs
reason

Die tatsächlich vorhandenen Felder können abhängig vom Dienst und von der macOS-Version abweichen.

Verdächtige Anzeichen:

Ein Exitcode ist zunächst nur ein technischer Hinweis. Seine genaue Bedeutung muss anhand der Dienst-, Hersteller- oder Betriebssystemdokumentation bestimmt werden.

13. Status vor einer Änderung dokumentieren

Vor einem Start, Stopp oder Neustart sollten mindestens folgende Informationen gesichert werden:

Information Zweck
Datum, Uhrzeit und Zeitzone Zuordnung zu Protokolleinträgen
Dienstname und Anzeigename Eindeutige Identifikation
Aktueller Status Ausgangszustand
Konfigurierte Startart Sollverhalten
Prozess-ID Zuordnung zum Prozess
Dienstkonto Berechtigungsprüfung
Programmpfad und Argumente Konfigurationsprüfung
Exitcode Hinweis auf Beendigungsursache
Abhängigkeiten Auswirkungsanalyse
Neustartregeln Erkennung automatischer Wiederanläufe
Letzte Protokollmeldungen Erhaltung flüchtiger Diagnoseinformationen
Aktive Verbindungen Bewertung möglicher Unterbrechungen

Kompakte Dokumentationsvorlage:

Zeitpunkt:
Server:
Betriebssystem:
Dienstname:
Anzeigename beziehungsweise Label:
Dienststatus:
Startart beziehungsweise Aktivierung:
Prozess-ID:
Dienstkonto:
Programmpfad:
Letzter Exitcode:
Neustartzähler:
Abhängigkeiten:
Relevante Protokollmeldung:
Bewertung:
Nächster Prüfschritt:
14. Dienstzustand verändern – nur nach Freigabe

Die folgenden Befehle sind keine reinen Diagnosebefehle. Sie verändern den Zustand und können Benutzer, Verbindungen oder Datenverarbeitung beeinträchtigen.

Aufgabe Windows PowerShell Linux mit systemd macOS mit launchd
Dienst starten [CHANGE][PRIV] Start-Service -Name "<DIENSTNAME>" [CHANGE][PRIV] sudo systemctl start "<DIENST>" [CHANGE][PRIV] sudo launchctl kickstart "system/<LABEL>"
Dienst stoppen [CHANGE][DISRUPT][PRIV] Stop-Service -Name "<DIENSTNAME>" [CHANGE][DISRUPT][PRIV] sudo systemctl stop "<DIENST>" [CHANGE][DISRUPT][PRIV] sudo launchctl kill SIGTERM "system/<LABEL>"
Dienst neu starten [CHANGE][DISRUPT][PRIV] Restart-Service -Name "<DIENSTNAME>" [CHANGE][DISRUPT][PRIV] sudo systemctl restart "<DIENST>" [CHANGE][DISRUPT][PRIV] sudo launchctl kickstart -k "system/<LABEL>"
Aktivieren [CHANGE][PRIV] Set-Service -Name "<DIENSTNAME>" -StartupType Automatic [CHANGE][PRIV] sudo systemctl enable "<DIENST>" [CHANGE][PRIV] sudo launchctl enable "system/<LABEL>"
Deaktivieren [CHANGE][DISRUPT][PRIV] Set-Service -Name "<DIENSTNAME>" -StartupType Disabled [CHANGE][PRIV] sudo systemctl disable "<DIENST>" [CHANGE][PRIV] sudo launchctl disable "system/<LABEL>"

Wichtige Unterschiede:

Diese Befehle sollten erst nach Sicherung des Ausgangszustands, Prüfung der Auswirkungen und betrieblicher Freigabe eingesetzt werden.

15. Typische Fehlinterpretationen
Fehlinterpretation Tatsächliche Bedeutung
„Der Dienst ist beendet, also ist er defekt.“ Ein manueller oder bedarfsgesteuerter Dienst kann regulär beendet sein
„Der Dienst ist aktiviert, also läuft er.“ Aktivierung und aktueller Laufzustand sind getrennte Eigenschaften
„Der Prozess läuft, also funktioniert der Dienst.“ Port, Protokoll und Anwendungsfunktion können trotzdem fehlerhaft sein
„systemd zeigt static, also ist die Unit deaktiviert.“ Die Unit kann durch Abhängigkeiten oder andere Auslöser gestartet werden
„systemd zeigt disabled, also kann die Unit nicht gestartet werden.“ Ein deaktivierter Dienst kann weiterhin manuell gestartet werden
„systemd zeigt masked, das ist dasselbe wie disabled.“ Eine maskierte Unit ist zusätzlich gegen normalen Start blockiert
„launchd zeigt keine PID, also ist der Dienst defekt.“ Ein bedarfsgesteuerter Job kann momentan ohne Prozess sein
„Exitcode 0 beweist vollständige Funktion.“ Er zeigt nur eine erfolgreiche Beendigung nach Definition des Programms
„Ein Neustart hat das Problem gelöst.“ Er kann nur das sichtbare Fehlerbild vorübergehend beseitigt haben
„Automatischer Neustart ist immer erwünscht.“ Er kann Abstürze verdecken oder eine Neustartschleife erzeugen
16. Checkliste zur Status- und Startartprüfung 
[ ] Internen Dienstnamen beziehungsweise launchd-Label ermittelt
[ ] Anzeigenamen und technischen Namen unterschieden
[ ] Richtigen Server und richtige Umgebung bestätigt
[ ] Aktuellen Dienststatus erfasst
[ ] Startart beziehungsweise Aktivierungszustand geprüft
[ ] Bedarfsgesteuerten Betrieb berücksichtigt
[ ] Deaktivierung oder Maskierung geprüft
[ ] Prozess-ID erfasst
[ ] Dienstkonto beziehungsweise Ausführungskontext geprüft
[ ] Programmpfad und Startargumente geprüft
[ ] Exitcode und dienstspezifischen Exitcode erfasst
[ ] Neustartzähler beziehungsweise wiederholte Starts geprüft
[ ] Abhängigkeiten aufgenommen
[ ] Ausgangszustand vor Änderungen dokumentiert
[ ] Noch keine ungeprüfte Zustandsänderung durchgeführt
[ ] Nächsten Diagnoseschritt festgelegt

Bewertung des Ergebnisses

Ergebnis Nächster Schritt
Dienst ist nicht registriert oder nicht auffindbar Installation, Produktdokumentation und Zielsystem prüfen
Dienst ist deaktiviert oder maskiert Grund der Deaktivierung und Änderungsverlauf klären
Dienst ist beendet, sollte aber laufen Startfehler, Exitcode und Protokolle untersuchen
Dienst hängt im Übergangszustand Prozess, Abhängigkeiten und Protokolle prüfen
Dienst startet und beendet sich wieder Exitcode, Neustartregeln und Anwendungsprotokolle prüfen
Dienst läuft stabil Prozess, Listener, Port und Anwendungsfunktion prüfen
Dienst läuft unter falschem Konto Konfiguration und benötigte Berechtigungen untersuchen
Startart entspricht nicht dem Sollzustand Sollkonfiguration und letzte Änderungen prüfen
Zustand ist unklar Keine Änderung durchführen; weitere Beweise sammeln

Merksatz

„Aktiviert“ beschreibt die Startkonfiguration. „Läuft“ beschreibt den aktuellen Zustand. „Funktioniert“ muss durch einen eigenen Anwendungstest bewiesen werden.

Weiterführende Quellen

4. Server- und Dienstfehler systematisch analysieren

4.3 Prozesse und Prozesszustände analysieren

Ein Betriebssystemdienst wird letztlich durch einen oder mehrere Prozesse ausgeführt. Auch wenn die Dienstverwaltung den Zustand „läuft“ meldet, kann der zugehörige Prozess blockiert sein, ungewöhnlich viele Ressourcen verbrauchen oder fortlaufend beendet und neu gestartet werden.

Grundsatz:
Ein vorhandener Prozess beweist nur, dass eine Prozessinstanz existiert. Er beweist nicht, dass der Dienst Anfragen korrekt verarbeitet.

Ziele dieser Seite

Nach dieser Seite sollst du:

1. Dienst, Prozess, Thread und PID unterscheiden
Begriff Bedeutung
Dienst Vom Betriebssystem verwaltete Hintergrundfunktion
Prozess Laufende Instanz eines Programms
PID Eindeutige Prozess-ID innerhalb des aktuell laufenden Systems
PPID PID des Elternprozesses
Thread Ausführungsstrang innerhalb eines Prozesses
Handle Windows-Verweis auf eine verwendete Systemressource
Dateideskriptor Unix-Verweis auf Datei, Socket, Pipe oder andere Ressource
Elternprozess Prozess, der einen anderen Prozess erzeugt hat
Kindprozess Von einem anderen Prozess erzeugter Prozess
Prozessbaum Hierarchische Darstellung von Eltern- und Kindprozessen

Ein Dienst kann:

Eine PID ist nicht dauerhaft. Nach dem Ende eines Prozesses kann dieselbe Nummer später einem anderen Prozess zugewiesen werden.

2. Prozesse unter Windows suchen und anzeigen

Die Platzhalter <PROZESS> und <PID> müssen ersetzt werden.

Prozess nach Namen suchen:

[RO] Get-Process -Name "<PROZESS>" -ErrorAction SilentlyContinue

Die Dateiendung .exe wird bei Get-Process -Name normalerweise nicht angegeben.

Prozess über die PID suchen:

[RO] Get-Process -Id <PID> -ErrorAction SilentlyContinue

Ausgewählte Prozessinformationen anzeigen:

[RO] Get-Process -Id <PID> |
    Select-Object Id,
                  ProcessName,
                  StartTime,
                  CPU,
                  WorkingSet64,
                  PrivateMemorySize64,
                  VirtualMemorySize64,
                  HandleCount,
                  Responding

Alle Prozesse nach CPU-Zeit sortieren:

[RO] Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 15 Id, ProcessName, CPU, WorkingSet64

Alle Prozesse nach belegtem Arbeitsspeicher sortieren:

[RO] Get-Process |
    Sort-Object WorkingSet64 -Descending |
    Select-Object -First 15 Id, ProcessName, WorkingSet64, CPU

Klassische Prozessübersicht:

[RO] tasklist

Bestimmten Prozess mit tasklist suchen:

[RO] tasklist /FI "PID eq <PID>"

Eigenschaften wie StartTime oder Path können bei geschützten Prozessen oder ohne ausreichende Rechte einen Zugriffsfehler verursachen.

3. Dienst einem Windows-Prozess zuordnen

Dienstname, Status und PID ermitteln:

[RO] Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'" |
    Select-Object Name, DisplayName, State, StartName, ProcessId

Alle laufenden Dienste mit ihrer PID anzeigen:

[RO] Get-CimInstance Win32_Service |
    Where-Object State -eq "Running" |
    Select-Object Name, DisplayName, ProcessId, StartName |
    Sort-Object ProcessId

Alle Dienste innerhalb einer bestimmten PID suchen:

[RO] Get-CimInstance Win32_Service -Filter "ProcessId=<PID>" |
    Select-Object Name, DisplayName, State, StartName

Erweiterte Dienstabfrage mit sc.exe:

[RO] sc.exe queryex "<DIENSTNAME>"

Dienstinformationen mit Prozessinformationen verbinden:

[RO][SENS] $service = Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'"
Get-CimInstance Win32_Process -Filter "ProcessId=$($service.ProcessId)" |
    Select-Object ProcessId,
                  ParentProcessId,
                  Name,
                  ExecutablePath,
                  CommandLine

Mehrere Windows-Dienste können sich einen gemeinsamen Hostprozess teilen. Das ist beispielsweise bei bestimmten svchost.exe-Instanzen üblich. Deshalb darf nicht allein anhand des Prozessnamens entschieden werden, welcher Dienst betroffen ist.

4. Windows-Prozessdetails mit CIM prüfen

Prozessname, Elternprozess, Pfad und Befehlszeile anzeigen:

[RO][SENS] Get-CimInstance Win32_Process -Filter "ProcessId=<PID>" |
    Select-Object ProcessId,
                  ParentProcessId,
                  Name,
                  ExecutablePath,
                  CommandLine,
                  CreationDate

Elternprozess ermitteln:

[RO] $process = Get-CimInstance Win32_Process -Filter "ProcessId=<PID>"
Get-CimInstance Win32_Process -Filter "ProcessId=$($process.ParentProcessId)" |
    Select-Object ProcessId, ParentProcessId, Name, CreationDate

Direkte Kindprozesse anzeigen:

[RO][SENS] Get-CimInstance Win32_Process -Filter "ParentProcessId=<PID>" |
    Select-Object ProcessId, ParentProcessId, Name, CommandLine

Anzahl der Threads und Handles prüfen:

[RO] Get-Process -Id <PID> |
    Select-Object Id,
                  ProcessName,
                  HandleCount,
                  @{Name="ThreadCount";Expression={$_.Threads.Count}}

Ausführungskonto des Prozesses abfragen:

[RO][PRIV] Invoke-CimMethod `
    -InputObject (Get-CimInstance Win32_Process -Filter "ProcessId=<PID>") `
    -MethodName GetOwner

[SENS]: Befehlszeilen können interne Pfade, Benutzernamen, Serveradressen oder unsicher übergebene Zugangsdaten enthalten. Die Ausgabe darf nicht ungeprüft weitergegeben werden.

5. Prozesse unter Linux suchen und anzeigen

Prozess nach Namen suchen:

[RO] pgrep -a "<PROZESS>"

Exakte Übereinstimmung des Prozessnamens verwenden:

[RO] pgrep -x -a "<PROZESS>"

Vollständige Befehlszeile durchsuchen:

[RO][SENS] pgrep -f -a "<SUCHMUSTER>"

Bestimmte PID untersuchen:

[RO][SENS] ps -p <PID> \
  -o user,pid,ppid,lstart,etime,stat,%cpu,%mem,rss,vsz,cmd

Alle Prozesse ausführlich anzeigen:

[RO][SENS] ps -eo user,pid,ppid,lstart,etime,stat,%cpu,%mem,rss,vsz,cmd

Nach CPU-Auslastung sortieren:

[RO] ps -eo pid,ppid,user,stat,%cpu,%mem,etime,comm \
  --sort=-%cpu |
  head -n 16

Nach residentem Speicher sortieren:

[RO] ps -eo pid,ppid,user,stat,%cpu,%mem,rss,etime,comm \
  --sort=-rss |
  head -n 16

Interaktive Prozessübersicht:

[RO] top

Falls installiert:

[RO] htop

htop gehört nicht auf jeder Linux-Distribution zur Standardinstallation.

6. Linux-Prozessdetails über das proc-Dateisystem prüfen

Linux stellt Prozessinformationen normalerweise unter /proc/<PID> bereit.

Ausführbare Datei bestimmen:

[RO][PRIV] sudo readlink -f "/proc/<PID>/exe"

Arbeitsverzeichnis anzeigen:

[RO][PRIV] sudo readlink -f "/proc/<PID>/cwd"

Prozessstatus anzeigen:

[RO][FILE][SENS] cat "/proc/<PID>/status"

Befehlszeile lesbar darstellen:

[RO][FILE][SENS] tr '\0' ' ' < "/proc/<PID>/cmdline"

Umgebungsvariablen anzeigen:

[RO][FILE][SENS][PRIV] sudo tr '\0' '\n' < "/proc/<PID>/environ"

Grenzwerte des Prozesses anzeigen:

[RO][FILE] cat "/proc/<PID>/limits"

Eingehängte Ressourcen des Prozesses anzeigen:

[RO][FILE][SENS] cat "/proc/<PID>/mountinfo"

Anzahl geöffneter Dateideskriptoren ermitteln:

[RO][PRIV] sudo find "/proc/<PID>/fd" -mindepth 1 -maxdepth 1 -printf '.' |
    wc -c

/proc/<PID>/environ kann Kennwörter, Token oder andere geheime Werte enthalten. Diese Abfrage darf nur bei berechtigtem Diagnosebedarf erfolgen. Die Ausgabe gehört nicht ungefiltert in ein Ticket.

7. systemd-Dienst einem Linux-Prozess zuordnen

Hauptprozess eines Dienstes anzeigen:

[RO] systemctl show "<DIENST>" \
  --property=MainPID,ControlPID,ExecMainPID,ExecMainStartTimestamp

Prozessbaum der Unit im Status anzeigen:

[RO] systemctl status "<DIENST>" --no-pager

Prozesse innerhalb der Unit beziehungsweise Control Group anzeigen:

[RO] systemd-cgls --unit "<DIENST>"

Ressourcennutzung von Control Groups beobachten:

[RO] systemd-cgtop

Hauptprozess anschließend mit ps untersuchen:

[RO][SENS] ps -p <PID> \
  -o user,pid,ppid,lstart,etime,stat,%cpu,%mem,rss,vsz,cmd

Wichtig:

8. Prozesse unter macOS suchen und anzeigen

Prozess nach Namen oder Befehlszeile suchen:

[RO][SENS] pgrep -alf "<SUCHMUSTER>"

Exakten Prozessnamen suchen:

[RO] pgrep -x "<PROZESS>"

Bestimmte PID ausführlich anzeigen:

[RO][SENS] ps -p <PID> \
  -o user,pid,ppid,lstart,etime,state,%cpu,%mem,rss,vsz,command

Alle Prozesse ausführlich anzeigen:

[RO][SENS] ps -axo user,pid,ppid,lstart,etime,state,%cpu,%mem,rss,vsz,command

Prozesse nach aktueller CPU-Nutzung sortiert anzeigen:

[RO] ps -Arcwwxo pid,ppid,user,state,%cpu,%mem,rss,etime,command

Prozesse nach Speicherverbrauch sortiert anzeigen:

[RO] ps -Amcwwxo pid,ppid,user,state,%cpu,%mem,rss,etime,command

Interaktive Prozessübersicht nach CPU-Nutzung:

[RO] top -o cpu

Drei Messungen für eine bestimmte PID ausgeben:

[RO] top -l 3 -pid <PID> \
  -stats pid,command,cpu,mem,threads,state,time

Bei top -l ist die erste CPU-Messung möglicherweise noch nicht aussagekräftig, weil für eine belastbare Prozentberechnung ein zeitlicher Vergleich benötigt wird.

9. launchd-Dienst einem macOS-Prozess zuordnen

Systemweiten launchd-Dienst prüfen:

[RO] launchctl print "system/<LABEL>"

Benutzerbezogenen Dienst prüfen:

[RO] launchctl print "gui/$(id -u)/<LABEL>"

In der Ausgabe sind insbesondere folgende Angaben relevant:

state
pid
runs
last exit code
program
arguments

Gefundene PID anschließend untersuchen:

[RO][SENS] ps -p <PID> \
  -o user,pid,ppid,lstart,etime,state,%cpu,%mem,rss,vsz,command

Direkte Kindprozesse einer PID anzeigen:

[RO][SENS] pgrep -P <PID> -a

Geöffnete Dateien und Netzwerkressourcen des Prozesses anzeigen:

[RO][SENS][PRIV] sudo lsof -nP -p <PID>

Ein launchd-Job kann geladen und funktionsfähig sein, obwohl momentan keine PID angezeigt wird. Das ist bei bedarfsgesteuerten Diensten möglich.

10. Wichtige Prozessfelder verstehen
Feld Bedeutung Diagnosewert
PID Prozess-ID Identifiziert die aktuelle Instanz
PPID Elternprozess-ID Zeigt den erzeugenden Prozess
USER Ausführungskonto Wichtig für Berechtigungen
START beziehungsweise LSTART Startzeit Hilft beim Erkennen von Neustarts
ETIME Vergangene Zeit seit Prozessstart Zeigt kurze oder lange Laufzeit
STAT beziehungsweise STATE Prozesszustand Erkennt Schlafen, Warten, Stopp oder Zombie
%CPU CPU-Nutzung Hinweis auf Last oder Endlosschleife
%MEM Anteil am physischen Speicher Grober Speichervergleich
RSS Aktuell residenter physischer Speicher Praktischer Speicherindikator
VSZ Virtueller Adressraum Nicht mit tatsächlich belegtem RAM gleichsetzen
TIME Verbrauchte CPU-Zeit Kumulierte Prozessorzeit
CMD beziehungsweise COMMAND Programm und Argumente Identifikation und Konfigurationsprüfung
THREADS Anzahl der Threads Hinweis auf Threadwachstum
HandleCount Offene Windows-Handles Hinweis auf Ressourcenleck
FD Dateideskriptor Geöffnete Ressource unter Unix-Systemen

Hoher virtueller Speicher bedeutet nicht automatisch, dass entsprechend viel physischer Arbeitsspeicher belegt ist.

11. Linux-Prozesszustände interpretieren

Der erste Buchstabe in der Spalte STAT beschreibt den grundlegenden Zustand.

Zustand Bedeutung Bewertung
R Laufend oder ausführungsbereit Bei dauerhafter hoher CPU-Nutzung untersuchen
S Unterbrechbarer Schlafzustand Häufig normal; Prozess wartet auf ein Ereignis
D Nicht unterbrechbarer Wartezustand Häufig Warten auf Ein-/Ausgabe; dauerhaft auffällig
T Gestoppt oder durch Debugger angehalten Ursache des Stopps prüfen
t Während Ablaufverfolgung gestoppt Debugger oder Tracing prüfen
Z Zombie Prozess ist beendet, Elternprozess hat Status noch nicht abgeholt
I Leerlaufender Kernel-Thread Normaler Kernelzustand
X Beendeter Prozess Normalerweise nur sehr kurz sichtbar

Weitere Zeichen können zusätzliche Eigenschaften angeben:

Zeichen Bedeutung
< Höhere Priorität
N Niedrigere Priorität
L Speicherseiten sind gesperrt
s Prozess ist Sitzungsleiter
l Mehrere Threads
+ Vordergrund-Prozessgruppe

Wichtige Bewertung:

12. macOS-Prozesszustände interpretieren

macOS verwendet ebenfalls Zustandszeichen, deren genaue Kombination mehrere Eigenschaften enthalten kann.

Zustand Grundbedeutung
R Laufend oder ausführungsbereit
S Schlafend für weniger als ungefähr 20 Sekunden
I Länger inaktiv beziehungsweise schlafend
D Warten auf Datenträger- oder andere nicht unterbrechbare Ein-/Ausgabe
T Angehalten
Z Zombie
U Nicht unterbrechbarer Wartezustand
H Angehaltene Ausführung
L Prozess besitzt gesperrte Speicherseiten

Abhängig von der Ausgabe können zusätzliche Zeichen erscheinen. Deshalb sollte bei Unklarheiten die lokale Handbuchseite herangezogen werden:

[RO] man ps

Prozesszustände dürfen nicht isoliert bewertet werden. Entscheidend ist, ob ein Zustand über einen längeren Messzeitraum bestehen bleibt und gleichzeitig eine Funktionsstörung vorliegt.

13. CPU-Verbrauch richtig untersuchen

Eine einzelne Momentaufnahme reicht häufig nicht aus. CPU-Nutzung sollte über mehrere Messpunkte beobachtet werden.

Beobachtung Mögliche Erklärung
Kurzer CPU-Ausschlag Reguläre Verarbeitung einer Anfrage
Dauerhaft hohe CPU-Nutzung Hohe Last, Schleife, Kompression, Verschlüsselung oder fehlerhafte Verarbeitung
Niedrige CPU-Nutzung trotz Störung Warten auf Netzwerk, Datenträger, Sperre oder Backend
Hohe gesamte CPU-Last, Dienst selbst unauffällig Konkurrenz durch andere Prozesse
Ein Prozess über 100 Prozent unter Unix Nutzung mehrerer CPU-Kerne möglich
Steigende kumulierte CPU-Zeit Prozess verbraucht weiterhin Prozessorzeit

Windows – zwei Messpunkte vergleichen:

[RO] Get-Process -Id <PID> |
    Select-Object Id, ProcessName, CPU, StartTime

Die Eigenschaft CPU enthält die bisher vom Prozess verbrauchte Prozessorzeit in Sekunden und nicht die momentane prozentuale Auslastung.

Linux – Prozess beobachten:

[RO] top -p <PID>

macOS – mehrere Messpunkte erfassen:

[RO] top -l 5 -s 2 -pid <PID> \
  -stats pid,command,cpu,mem,threads,state,time

Ein Prozess mit niedriger CPU-Nutzung kann trotzdem blockiert sein. Warten auf Ein-/Ausgabe benötigt häufig kaum Prozessorzeit.

14. Speicherverbrauch richtig untersuchen
Messwert Bedeutung
Working Set Derzeit im physischen Speicher befindliche Speicherseiten unter Windows
Private Memory Speicher, der dem Prozess privat zugeordnet ist
RSS Residenter physischer Speicher unter Unix-Systemen
VSZ Gesamter virtueller Adressraum
Swap Auf Auslagerungsspeicher verschobene Daten
Page Fault Zugriff auf eine nicht aktuell im Working Set befindliche Speicherseite

Windows:

[RO] Get-Process -Id <PID> |
    Select-Object Id,
                  ProcessName,
                  WorkingSet64,
                  PrivateMemorySize64,
                  VirtualMemorySize64,
                  PagedMemorySize64

Linux:

[RO] ps -p <PID> -o pid,etime,%mem,rss,vsz,stat,comm

macOS:

[RO] ps -p <PID> -o pid,etime,%mem,rss,vsz,state,command

Hinweise auf ein mögliches Speicherleck:

Ein Speicherleck lässt sich nicht durch einen einzelnen hohen Messwert beweisen. Dafür ist eine Zeitreihe unter vergleichbarer Last erforderlich.

15. Threads, Handles und Dateideskriptoren prüfen

Ein Prozess kann funktionsunfähig werden, obwohl er weiterhin läuft. Ursachen können erschöpfte Handles, Dateideskriptoren oder ungewöhnlich viele Threads sein.

Ressource Windows Linux macOS
Threads Get-Process ps -L ps -M
Handles HandleCount Nicht gleichbedeutend Nicht gleichbedeutend
Dateideskriptoren Über spezialisierte Werkzeuge /proc/<PID>/fd oder lsof lsof
Geöffnete Dateien Sysinternals-Werkzeuge oder Prozesswerkzeuge lsof -p lsof -p

Windows – Thread- und Handleanzahl:

[RO] Get-Process -Id <PID> |
    Select-Object Id,
                  ProcessName,
                  HandleCount,
                  @{Name="ThreadCount";Expression={$_.Threads.Count}}

Linux – Threads anzeigen:

[RO] ps -L -p <PID> -o pid,tid,psr,stat,%cpu,comm

Linux – geöffnete Ressourcen anzeigen:

[RO][SENS][PRIV] sudo lsof -nP -p <PID>

macOS – Threads anzeigen:

[RO] ps -M -p <PID>

macOS – geöffnete Ressourcen anzeigen:

[RO][SENS][PRIV] sudo lsof -nP -p <PID>

Verdächtig ist nicht allein eine hohe Anzahl, sondern insbesondere:

16. Wechselnde PIDs und Neustartschleifen erkennen

Eine neue PID kann bedeuten, dass ein Prozess neu gestartet wurde.

Windows – wiederholte Dienstabfrage:

[RO] Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'" |
    Select-Object Name, State, ProcessId, ExitCode

Linux – Neustartzähler und Hauptprozess:

[RO] systemctl show "<DIENST>" \
  --property=MainPID,NRestarts,ActiveEnterTimestamp,ExecMainStartTimestamp,Result

macOS – Anzahl der Starts und aktuelle PID:

[RO] launchctl print "system/<LABEL>"

Anzeichen einer Neustartschleife:

Ein automatisch neu gestarteter Dienst kann nach außen zeitweise erreichbar wirken. Die wechselnden PIDs und kurzen Unterbrechungen sind dann wichtige Diagnosehinweise.

17. Nicht reagierenden Prozess richtig bewerten

Ein Prozess kann:

Windows-Eigenschaft Responding:

[RO] Get-Process -Id <PID> |
    Select-Object Id, ProcessName, Responding

Diese Eigenschaft ist hauptsächlich bei Prozessen mit grafischer Benutzeroberfläche hilfreich. Sie ist kein zuverlässiger allgemeiner Funktionstest für Serverdienste.

Bessere Bewertung eines Serverprozesses:

  1. Bleibt die PID stabil?
  2. Verändert sich die CPU-Zeit?
  3. Lauscht der Prozess auf dem erwarteten Port?
  4. Nimmt er neue Verbindungen an?
  5. Reagiert das Anwendungsprotokoll?
  6. Gibt es blockierte Ein-/Ausgabe?
  7. Steigt die Anzahl offener Verbindungen oder Dateien?
  8. Zeigen Protokolle Zeitüberschreitungen oder Sperren?
  9. Funktionieren abhängige Systeme?
  10. Reagiert der Prozess auf einen kontrollierten Diagnosetest?

„Läuft“ und „reagiert“ sind unterschiedliche Zustände.

18. Prozess beenden – nur als kontrollierte Maßnahme

Die folgenden Befehle verändern den Systemzustand und können Datenverlust oder Dienstunterbrechungen verursachen.

Aufgabe Windows Linux macOS
Reguläre Beendigung anfordern [CHANGE][DISRUPT] Stop-Process -Id <PID> [CHANGE][DISRUPT] kill -TERM <PID> [CHANGE][DISRUPT] kill -TERM <PID>
Beendigung erzwingen [CHANGE][DISRUPT][PRIV] Stop-Process -Id <PID> -Force [CHANGE][DISRUPT][PRIV] sudo kill -KILL <PID> [CHANGE][DISRUPT][PRIV] sudo kill -KILL <PID>

Vorher prüfen:

[ ] PID unmittelbar vor der Maßnahme erneut verifiziert
[ ] Prozessname und Dienstzuordnung bestätigt
[ ] Aktive Benutzer und Verbindungen geprüft
[ ] Laufende Schreibvorgänge und Transaktionen berücksichtigt
[ ] Prozess- und Dienstprotokolle gesichert
[ ] Abhängige Dienste geprüft
[ ] Cluster- oder Failover-Verhalten berücksichtigt
[ ] Automatische Neustartregel geprüft
[ ] Betriebliche Freigabe vorhanden
[ ] Funktionstest nach der Maßnahme vorbereitet

Wichtige Unterschiede:

Niemals eine alte, zuvor notierte PID ungeprüft verwenden. Die PID könnte inzwischen einem anderen Prozess gehören.

19. Typische Fehlinterpretationen
Fehlinterpretation Richtige Bewertung
„Die PID existiert, also funktioniert der Dienst.“ Nur die Prozessinstanz wurde nachgewiesen
„Der Prozess verwendet wenig CPU, also ist er gesund.“ Er kann auf Ein-/Ausgabe oder eine Sperre warten
„Hohe CPU-Nutzung ist immer ein Fehler.“ Sie kann durch reguläre Last entstehen
„Hoher virtueller Speicher ist vollständig belegter RAM.“ Virtueller Adressraum und residenter Speicher unterscheiden sich
„Ein Zombie verbraucht sehr viel Arbeitsspeicher.“ Er belegt hauptsächlich einen Prozesslisteneintrag
„Der Zombie muss mit kill beendet werden.“ Der Prozess ist bereits beendet; der Elternprozess muss seinen Status abholen
„Eine neue PID ist unproblematisch.“ Sie kann einen Absturz und automatischen Neustart anzeigen
„Der Prozessname identifiziert den Dienst eindeutig.“ Mehrere Dienste können denselben Prozessnamen verwenden
„Responding=True beweist die Serverfunktion.“ Es ist kein vollständiger Anwendungstest
„SIGKILL ist schneller und deshalb besser.“ Es verhindert eine kontrollierte Bereinigung und erhöht das Risiko
20. Checkliste zur Prozessanalyse 
[ ] Dienst dem richtigen Prozess zugeordnet
[ ] PID unmittelbar aktuell ermittelt
[ ] Prozessname geprüft
[ ] Elternprozess und Kindprozesse geprüft
[ ] Ausführungskonto geprüft
[ ] Programmpfad und Befehlszeile geprüft
[ ] Startzeit und bisherige Laufzeit geprüft
[ ] Prozesszustand geprüft
[ ] CPU über mehrere Messpunkte beobachtet
[ ] Speicherverbrauch über einen Zeitraum bewertet
[ ] Threadanzahl geprüft
[ ] Handles beziehungsweise Dateideskriptoren geprüft
[ ] Geöffnete Dateien und Sockets bei Bedarf geprüft
[ ] Wechselnde PID ausgeschlossen oder dokumentiert
[ ] Automatische Neustarts geprüft
[ ] Exitcode und Protokolle gesichert
[ ] Noch keine ungeprüfte Prozessbeendigung durchgeführt
[ ] Nächsten Diagnoseschritt festgelegt

Bewertung des Ergebnisses

Ergebnis Nächster Schritt
Kein Prozess vorhanden, Dienst sollte laufen Dienststartfehler und Protokolle prüfen
Prozess wird fortlaufend neu gestartet Exitcode, Neustartregel und Startprotokoll untersuchen
Prozess läuft stabil Listener, Ports und Anwendungsfunktion prüfen
Prozess verwendet dauerhaft viel CPU Threads, Anfragen, Schleifen und Last untersuchen
Speicherverbrauch steigt kontinuierlich Zeitreihe, Grenzwerte und mögliche Speicherlecks untersuchen
Prozess verbleibt in einem Wartezustand Datenträger, Netzwerk, Sperren und Backends prüfen
Zombieprozesse sammeln sich Elternprozess und dessen Fehlerbehandlung untersuchen
Handle- oder Dateideskriptoranzahl steigt Ressourcenleck und Grenzwerte untersuchen
Falsches Ausführungskonto Dienstkonfiguration und Berechtigungen prüfen
Unerwarteter Elternprozess Startweg, Überwachung, Wrapper oder Sicherheitsvorfall untersuchen

Merksatz

Der Dienststatus zeigt die Sicht der Dienstverwaltung. Die Prozessanalyse zeigt, was die ausführende Instanz tatsächlich tut – oder worauf sie wartet.

Weiterführende Quellen

4. Server- und Dienstfehler systematisch analysieren

4.4 Listener, Ports und Bindungsadressen prüfen

4.4 Listener, Ports und Bindungsadressen prüfen

Ein laufender Dienstprozess ist nur dann über das Netzwerk erreichbar, wenn er einen passenden Socket geöffnet und an die erwartete lokale Adresse sowie den vorgesehenen Port gebunden hat.

Grundsatz:
Dienststatus, Prozess, Listener und erfolgreiche Anwendungsantwort sind vier getrennte Nachweise.

Ziele dieser Seite

Nach dieser Seite sollst du:

1. Socket, Listener, Port und Verbindung unterscheiden
Begriff Bedeutung
Socket Betriebssystemobjekt für eine Kommunikationsverbindung oder einen Endpunkt
Lokale Adresse IP-Adresse der lokalen Netzwerkschnittstelle
Lokaler Port Portnummer auf dem untersuchten System
Remoteadresse IP-Adresse der Gegenstelle
Remoteport Portnummer der Gegenstelle
TCP-Listener Passiver TCP-Socket, der neue Verbindungen annehmen kann
UDP-Endpunkt Gebundener UDP-Socket; UDP besitzt keinen TCP-ähnlichen LISTEN-Zustand
Bindung Zuordnung eines Sockets zu lokaler Adresse und Port
Wildcard-Bindung Bindung an alle passenden lokalen Adressen
Loopback-Bindung Zugriff nur über die lokale Loopback-Schnittstelle
Established Vollständig aufgebaute TCP-Verbindung

Beispiel einer TCP-Verbindung:

Client:  192.0.2.50:53124
Server:  192.0.2.20:443

Dabei ist 53124 normalerweise ein temporärer Clientport und 443 der bekannte Serverport.

2. Erwarteten Netzwerkendpunkt vor der Prüfung festlegen

Vor der Listenerprüfung müssen folgende Sollwerte bekannt sein:

Eigenschaft Beispiel
Protokoll TCP
Port 443
IP-Version IPv4 und IPv6
Erwartete Bindungsadresse 192.0.2.20
Erwarteter Prozess Webserverprozess
Erwarteter Dienst Interner Webdienst
Erlaubte Quellnetze Unternehmens-LAN und VPN
Verschlüsselung TLS
Anwendungsprotokoll HTTPS
Zugriffspfad Direkt, über Proxy oder Loadbalancer

Unzureichende Prüffrage:

„Ist Port 443 offen?“

Bessere Prüffragen:

3. Bindungsadressen richtig interpretieren
Bindungsadresse Typische Bedeutung
127.0.0.1 Nur lokale IPv4-Verbindungen
::1 Nur lokale IPv6-Verbindungen
0.0.0.0 Alle lokalen IPv4-Adressen
:: beziehungsweise [::] IPv6-Wildcard; mögliche IPv4-Mitbenutzung ist system- und socketabhängig
Bestimmte IPv4-Adresse Nur diese lokale IPv4-Adresse
Bestimmte IPv6-Adresse Nur diese lokale IPv6-Adresse

Beispiel:

Ein Server besitzt folgende Adressen:

127.0.0.1
192.0.2.20
198.51.100.20

Der Dienst bindet sich an:

127.0.0.1:8080

Dann ist der Dienst normalerweise nicht direkt über 192.0.2.20:8080 oder 198.51.100.20:8080 erreichbar.

Bindet er sich an:

0.0.0.0:8080

nimmt er grundsätzlich auf allen lokalen IPv4-Adressen Verbindungen an. Firewall- und Routingregeln gelten zusätzlich.

Eine Wildcard-Bindung bedeutet nicht, dass der Port aus jedem Netzwerk erreichbar ist. Paketfilter, Routing, NAT, Sicherheitsgruppen und vorgeschaltete Systeme können den Zugriff weiterhin verhindern.

4. TCP-Listener unter Windows anzeigen

Alle TCP-Listener anzeigen:

[RO] Get-NetTCPConnection -State Listen |
    Sort-Object LocalPort, LocalAddress

Wichtige Felder auswählen:

[RO] Get-NetTCPConnection -State Listen |
    Select-Object LocalAddress, LocalPort, State, OwningProcess |
    Sort-Object LocalPort, LocalAddress

Bestimmten TCP-Port prüfen:

[RO] Get-NetTCPConnection `
    -State Listen `
    -LocalPort <PORT> `
    -ErrorAction SilentlyContinue

Bestimmte lokale Adresse und Port prüfen:

[RO] Get-NetTCPConnection `
    -State Listen `
    -LocalAddress "<IP-ADRESSE>" `
    -LocalPort <PORT> `
    -ErrorAction SilentlyContinue

Klassische Alternative:

[RO] netstat -ano -p tcp

Nur TCP-Listener mit netstat:

[RO] netstat -ano -p tcp |
    Select-String "LISTENING"

Get-NetTCPConnection liefert strukturierte PowerShell-Objekte und ist deshalb für gezielte Filterungen besser geeignet als das Verarbeiten formatierter netstat-Ausgaben.

5. UDP-Endpunkte unter Windows anzeigen

UDP besitzt keinen Verbindungszustand Listen. Stattdessen werden gebundene UDP-Endpunkte angezeigt.

Alle UDP-Endpunkte anzeigen:

[RO] Get-NetUDPEndpoint |
    Select-Object LocalAddress, LocalPort, OwningProcess |
    Sort-Object LocalPort, LocalAddress

Bestimmten UDP-Port prüfen:

[RO] Get-NetUDPEndpoint `
    -LocalPort <PORT> `
    -ErrorAction SilentlyContinue

Klassische Alternative:

[RO] netstat -ano -p udp

Wichtig:

6. Windows-Port dem verantwortlichen Prozess zuordnen

TCP-Port und Prozess-ID ermitteln:

[RO] Get-NetTCPConnection `
    -State Listen `
    -LocalPort <PORT> `
    -ErrorAction SilentlyContinue |
    Select-Object LocalAddress, LocalPort, OwningProcess

Zugehörigen Prozess anzeigen:

[RO] $connection = Get-NetTCPConnection `
    -State Listen `
    -LocalPort <PORT> `
    -ErrorAction SilentlyContinue

$connection |
    ForEach-Object {
        Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
    } |
    Select-Object Id, ProcessName, StartTime

Prozess und Dienst über eine gefundene PID zuordnen:

[RO] Get-CimInstance Win32_Service -Filter "ProcessId=<PID>" |
    Select-Object Name, DisplayName, State, StartName

Alle TCP-Listener zusammen mit Prozessnamen anzeigen:

[RO] Get-NetTCPConnection -State Listen |
    ForEach-Object {
        $process = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue

        [PSCustomObject]@{
            LocalAddress = $_.LocalAddress
            LocalPort    = $_.LocalPort
            PID          = $_.OwningProcess
            ProcessName  = $process.ProcessName
        }
    } |
    Sort-Object LocalPort, LocalAddress

Mehrere Listener können dieselbe PID verwenden. Ebenso kann ein Prozess auf mehreren Adressen und Ports lauschen.

7. Listener unter Linux mit ss anzeigen

ss ist auf modernen Linux-Systemen das bevorzugte Werkzeug für Socketinformationen.

Alle lauschenden TCP-Sockets numerisch anzeigen:

[RO] ss -lnt

TCP-Listener einschließlich Prozessinformationen anzeigen:

[RO][PRIV] sudo ss -lntp

Gebundene UDP-Sockets anzeigen:

[RO] ss -lnu

UDP-Sockets einschließlich Prozessinformationen anzeigen:

[RO][PRIV] sudo ss -lnup

TCP- und UDP-Sockets gemeinsam anzeigen:

[RO][PRIV] sudo ss -lntup

Bedeutung wichtiger Optionen:

Option Bedeutung
-l Nur lauschende beziehungsweise unverbundene Server-Sockets
-n Adressen und Ports numerisch ausgeben
-t TCP-Sockets
-u UDP-Sockets
-p Zugehörige Prozesse anzeigen
-4 Nur IPv4
-6 Nur IPv6

Nur IPv4-TCP-Listener:

[RO] ss -4 -lnt

Nur IPv6-TCP-Listener:

[RO] ss -6 -lnt

Ohne ausreichende Berechtigungen können Prozessname und PID in der Ausgabe fehlen.

8. Bestimmten Port oder Prozess unter Linux prüfen

Bestimmten TCP-Listener prüfen:

[RO][PRIV] sudo ss -lntp "sport = :<PORT>"

Bestimmten UDP-Port prüfen:

[RO][PRIV] sudo ss -lnup "sport = :<PORT>"

Offene Netzwerkressourcen einer PID anzeigen:

[RO][SENS][PRIV] sudo lsof -nP -a -p <PID> -i

TCP-Listener einer PID anzeigen:

[RO][SENS][PRIV] sudo lsof \
    -nP \
    -a \
    -p <PID> \
    -iTCP \
    -sTCP:LISTEN

Bestimmten TCP-Port mit lsof prüfen:

[RO][PRIV] sudo lsof -nP -iTCP:<PORT> -sTCP:LISTEN

Bestimmten UDP-Port mit lsof prüfen:

[RO][PRIV] sudo lsof -nP -iUDP:<PORT>

lsof ist nicht auf jeder minimalen Linux-Installation vorhanden. In diesem Fall kann zunächst ss verwendet werden.

9. Listener unter macOS anzeigen

Alle TCP-Listener anzeigen:

[RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN

Bestimmten TCP-Port prüfen:

[RO][PRIV] sudo lsof -nP -iTCP:<PORT> -sTCP:LISTEN

Gebundene UDP-Sockets anzeigen:

[RO][PRIV] sudo lsof -nP -iUDP

Bestimmten UDP-Port prüfen:

[RO][PRIV] sudo lsof -nP -iUDP:<PORT>

Netzwerksockets einer bestimmten PID anzeigen:

[RO][SENS][PRIV] sudo lsof -nP -a -p <PID> -i

TCP-Verbindungen und Listener mit netstat anzeigen:

[RO] netstat -anv -p tcp

UDP-Sockets mit netstat anzeigen:

[RO] netstat -anv -p udp

Unter macOS ist lsof für die Zuordnung von Netzwerkendpunkten zu Prozessen meist übersichtlicher als netstat.

10. Ausgabe von ss, lsof und netstat lesen

Beispiel eines TCP-Listeners:

LISTEN  0  128  0.0.0.0:443  0.0.0.0:*

Interpretation:

Feld Bedeutung
LISTEN Socket nimmt neue TCP-Verbindungen an
0.0.0.0:443 Bindung an TCP-Port 443 auf allen lokalen IPv4-Adressen
0.0.0.0:* Noch keine bestimmte entfernte Gegenstelle
0 Je nach Werkzeug aktueller Warteschlangenwert
128 Je nach Werkzeug Warteschlangen- oder Grenzwert

Beispiel einer aufgebauten Verbindung:

192.0.2.20:443  192.0.2.50:53124  ESTABLISHED

Interpretation:

Lokaler Serverendpunkt:  192.0.2.20:443
Entfernter Client:       192.0.2.50:53124
Zustand:                 Verbindung aufgebaut

Bei der Auswertung muss zuerst bestimmt werden, welches System Client und welches System Server ist. Ein hoher temporärer Port gehört häufig zum Client.

11. IPv4 und IPv6 getrennt prüfen

Ein Dienst kann:

Windows – IPv4-Listener eines Ports:

[RO] Get-NetTCPConnection -State Listen -LocalPort <PORT> |
    Where-Object LocalAddress -NotLike "*:*"

Windows – IPv6-Listener eines Ports:

[RO] Get-NetTCPConnection -State Listen -LocalPort <PORT> |
    Where-Object LocalAddress -Like "*:*"

Linux – IPv4 prüfen:

[RO][PRIV] sudo ss -4 -lntp "sport = :<PORT>"

Linux – IPv6 prüfen:

[RO][PRIV] sudo ss -6 -lntp "sport = :<PORT>"

macOS – IPv4 prüfen:

[RO][PRIV] sudo lsof -nP -i4TCP:<PORT> -sTCP:LISTEN

macOS – IPv6 prüfen:

[RO][PRIV] sudo lsof -nP -i6TCP:<PORT> -sTCP:LISTEN

Aus einer Bindung an [::]:<PORT> darf nicht ungeprüft geschlossen werden, dass IPv4 ebenfalls funktioniert. IPv4 und IPv6 müssen praktisch getrennt getestet werden.

12. Lokalen TCP-Porttest durchführen

Ein lokaler Test hilft zu unterscheiden, ob der Dienst grundsätzlich Verbindungen annimmt oder ob nur der externe Zugriff fehlschlägt.

Windows – IPv4-Loopback testen:

[TEST] Test-NetConnection 127.0.0.1 -Port <PORT>

Windows – konkrete Serveradresse testen:

[TEST] Test-NetConnection <SERVER-IP> -Port <PORT>

Linux – IPv4-Loopback testen:

[TEST] nc -vz -w 3 127.0.0.1 <PORT>

Linux – konkrete Serveradresse testen:

[TEST] nc -vz -w 3 <SERVER-IP> <PORT>

macOS – IPv4-Loopback testen:

[TEST] nc -vz -w 3 127.0.0.1 <PORT>

macOS – konkrete Serveradresse testen:

[TEST] nc -vz -w 3 <SERVER-IP> <PORT>

IPv6-Loopback unter Linux oder macOS testen:

[TEST] nc -6 -vz -w 3 ::1 <PORT>

Interpretation:

Loopback Server-IP Mögliche Bewertung
Erfolgreich Erfolgreich Lokaler Listener grundsätzlich erreichbar
Erfolgreich Fehlgeschlagen Falsche Bindung oder lokaler Paketfilter möglich
Fehlgeschlagen Erfolgreich Dienst lauscht möglicherweise nur auf einer konkreten Adresse
Fehlgeschlagen Fehlgeschlagen Kein Listener, falscher Port oder Paketfilter
Erfolgreich Extern fehlgeschlagen Externe Firewall, Routing oder Netzpfad untersuchen

Ein erfolgreicher TCP-Porttest beweist nur, dass ein TCP-Verbindungsaufbau möglich war. Er beweist nicht, dass die Anwendung fachlich korrekt antwortet.

13. TCP-Port von einem entfernten Client testen

Der Test sollte aus dem tatsächlich betroffenen Netzwerk oder von einem vergleichbaren Client erfolgen.

Betriebssystem Befehl
Windows [TEST] Test-NetConnection <SERVER> -Port <PORT>
Linux [TEST] nc -vz -w 3 <SERVER> <PORT>
macOS [TEST] nc -vz -w 3 <SERVER> <PORT>

Windows mit ausführlicher Ausgabe:

[TEST] Test-NetConnection <SERVER> -Port <PORT> -InformationLevel Detailed

Wichtige Ausgabe:

ComputerName
RemoteAddress
RemotePort
InterfaceAlias
SourceAddress
TcpTestSucceeded

Prüffragen:

14. UDP-Porttests vorsichtig bewerten

Linux oder macOS:

[TEST] nc -vzu -w 3 <SERVER> <PORT>

Ein solcher Test kann jedoch häufig nicht zuverlässig bestätigen, dass:

Bessere UDP-Prüfung:

Dienst Geeigneter protokollspezifischer Test
DNS dig oder nslookup
NTP ntpq, chronyc oder geeigneter NTP-Client
DHCP Kontrollierter DHCP-Test im vorgesehenen Netz
SNMP snmpget mit autorisierten Zugangsdaten
TFTP Kontrollierter TFTP-Clienttest
Syslog Testnachricht und serverseitige Protokollkontrolle

Bei UDP ist ein protokollspezifischer Funktionstest wesentlich aussagekräftiger als ein allgemeiner Portscan.

15. Lokal erreichbar, von außen nicht erreichbar

Wenn ein lokaler Porttest erfolgreich ist, ein entfernter Test aber fehlschlägt, kommen unter anderem folgende Ursachen infrage:

Diagnosereihenfolge:

1. Listener und Bindungsadresse prüfen
2. Lokalen Test über Loopback durchführen
3. Lokalen Test über die Server-IP durchführen
4. Test aus demselben Subnetz durchführen
5. Test aus dem betroffenen Clientnetz durchführen
6. Hostfirewall prüfen
7. Netzwerkpfad und Zwischenfirewalls prüfen
8. Paketmitschnitt auf Client und Server erwägen
16. Portkonflikte erkennen

Ein Portkonflikt entsteht, wenn ein Prozess eine Adresse-Port-Kombination verwenden möchte, die bereits unvereinbar belegt ist.

Typische Fehlermeldungen:

Address already in use
Only one usage of each socket address is normally permitted
Failed to bind
Bind failed
EADDRINUSE
Port is already allocated

Windows:

[RO] Get-NetTCPConnection -State Listen -LocalPort <PORT> |
    Select-Object LocalAddress, LocalPort, OwningProcess

[RO] Get-NetUDPEndpoint -LocalPort <PORT> |
    Select-Object LocalAddress, LocalPort, OwningProcess

Linux:

[RO][PRIV] sudo ss -lntup "sport = :<PORT>"

macOS – TCP:

[RO][PRIV] sudo lsof -nP -iTCP:<PORT> -sTCP:LISTEN

macOS – UDP:

[RO][PRIV] sudo lsof -nP -iUDP:<PORT>

Prüffragen bei einem Konflikt:

Einen unbekannten Prozess nicht allein deshalb beenden, weil er den gewünschten Port verwendet. Zuerst müssen Prozess, Dienst und betriebliche Funktion eindeutig zugeordnet werden.

17. Wichtige TCP-Zustände einordnen
Zustand Bedeutung Mögliche Diagnose
LISTEN Server wartet auf neue Verbindungen Listener vorhanden
SYN_SENT Lokales System versucht eine Verbindung aufzubauen Rückantwort fehlt oder Ziel nicht erreichbar
SYN_RECEIVED Verbindungsanfrage empfangen, Handshake noch nicht abgeschlossen Clientantwort fehlt oder Warteschlange belastet
ESTABLISHED TCP-Verbindung vollständig aufgebaut Transportverbindung vorhanden
FIN_WAIT_1 Lokales System hat Beendigung eingeleitet Normal während Verbindungsabbau
FIN_WAIT_2 Bestätigung erhalten, Abschluss der Gegenseite fehlt Bei großer dauerhafter Anzahl untersuchen
CLOSE_WAIT Gegenseite hat beendet, lokale Anwendung noch nicht Große dauerhafte Anzahl kann auf Anwendungsfehler hinweisen
LAST_ACK Lokale Anwendung beendet, letzte Bestätigung steht aus Normal kurzzeitig
TIME_WAIT Verbindung wird nach Beendigung vorübergehend vorgehalten Häufig normal
CLOSED Socket ist nicht aktiv Keine Verbindung
CLOSING Beide Seiten beenden nahezu gleichzeitig Normal kurzzeitig

Einzelne Verbindungen in TIME_WAIT oder CLOSE_WAIT sind noch kein Fehler. Auffällig sind große oder kontinuierlich wachsende Bestände über einen längeren Zeitraum.

18. Aufgebaute Verbindungen eines Dienstes prüfen

Windows – Verbindungen einer PID:

[RO] Get-NetTCPConnection -OwningProcess <PID> |
    Select-Object LocalAddress,
                  LocalPort,
                  RemoteAddress,
                  RemotePort,
                  State

Linux – alle TCP-Verbindungen einer PID über lsof:

[RO][SENS][PRIV] sudo lsof -nP -a -p <PID> -iTCP

macOS – alle TCP-Verbindungen einer PID:

[RO][SENS][PRIV] sudo lsof -nP -a -p <PID> -iTCP

Damit können unter anderem folgende Fragen beantwortet werden:

Remoteadressen, interne Servernamen und Verbindungsziele können sensible Infrastrukturinformationen darstellen.

19. Container und vorgeschaltete Dienste berücksichtigen

Bei containerisierten oder weitergeleiteten Anwendungen können mehrere Portebenen vorhanden sein.

Client
  → Hostadresse: veröffentlichter Port
  → Firewall oder Proxy
  → Containeradresse: interner Port
  → Anwendungsprozess

Beispiel:

Host:       192.0.2.20:8443
Container:  172.18.0.5:443
Anwendung:  0.0.0.0:443 im Container

Prüfungen müssen deshalb unterscheiden zwischen:

Typische Fehler:

Die allgemeine Socketprüfung bleibt gleich, muss aber in jedem relevanten Netzwerk-Namespace beziehungsweise auf jeder Weiterleitungsstufe wiederholt werden.

20. Typische Fehlerbilder systematisch bewerten
Beobachtung Mögliche Ursache Nächster Schritt
Dienst läuft, aber kein Listener vorhanden Start unvollständig, falsche Konfiguration oder interner Fehler Dienstprotokoll und Startparameter prüfen
Falscher Prozess besitzt den Port Portkonflikt oder falsche Dienstinstanz Prozess und Änderungshistorie untersuchen
Listener nur auf 127.0.0.1 Dienst nur für lokale Nutzung konfiguriert Sollkonfiguration und Proxy-Aufbau prüfen
Listener nur auf einer Server-IP Bindung an falsche oder alte Adresse Netzwerkkonfiguration und Dienstkonfiguration prüfen
Listener nur auf IPv4 IPv6-Clients erreichen den Dienst nicht Sollzustand und IPv6-Konfiguration prüfen
Listener nur auf IPv6 IPv4-Zugriff möglicherweise nicht verfügbar IPv4 getrennt testen
Lokaler Test erfolgreich, entfernter Test fehlerhaft Firewall, Routing oder falsche Bindung Netzwerkpfad schrittweise prüfen
TCP-Verbindung erfolgreich, Anwendung fehlerhaft Protokoll-, TLS-, Backend- oder Berechtigungsproblem Anwendungsspezifischen Test durchführen
Viele CLOSE_WAIT-Verbindungen Anwendung schließt Sockets möglicherweise nicht Prozess- und Anwendungscode beziehungsweise Herstellerhinweise prüfen
Viele SYN_RECEIVED-Verbindungen Handshakes bleiben unvollständig Last, Netzwerk, Filter und mögliche Angriffe prüfen
UDP-Endpunkt vorhanden, Test ohne Antwort Test möglicherweise nicht protokollgerecht Protokollspezifischen Test verwenden
Port wechselt nach jedem Start Dynamische Portkonfiguration oder fehlerhafte Vorgabe Effektive Konfiguration prüfen
21. Typische Fehlinterpretationen
Fehlinterpretation Richtige Bewertung
„Der Dienst läuft, also ist der Port offen.“ Der Prozess muss tatsächlich einen Socket gebunden haben
„Port offen bedeutet Anwendung funktioniert.“ Nur der Transportverbindungsaufbau wurde bestätigt
„0.0.0.0 bedeutet Zugriff aus dem gesamten Internet.“ Es bedeutet alle lokalen IPv4-Adressen; Netzwerkfilter gelten weiterhin
„127.0.0.1 ist die Server-IP für Clients.“ Loopback ist nur auf dem jeweiligen System erreichbar
„UDP hat ebenfalls einen LISTEN-Zustand.“ UDP verwendet keinen TCP-ähnlichen Listenerzustand
„Ein fehlgeschlagener UDP-Test beweist einen geschlossenen Port.“ Ohne Protokollantwort ist das Ergebnis oft nicht eindeutig
„[::] beweist gleichzeitig IPv4-Erreichbarkeit.“ IPv4 muss separat getestet werden
„Jeder hohe Clientport ist ein unbekannter Serverdienst.“ Temporäre Clientports sind normal
„Viele TIME_WAIT-Einträge bedeuten automatisch einen Fehler.“ Der Zustand ist Bestandteil des normalen TCP-Abbaus
„Ein Portkonflikt darf durch sofortiges Beenden gelöst werden.“ Der besitzende Prozess muss zuerst eindeutig identifiziert werden
22. Checkliste zur Listener- und Portprüfung 
[ ] Erwartetes Protokoll bestimmt
[ ] Erwarteten Port bestimmt
[ ] Erwartete Bindungsadresse bestimmt
[ ] IPv4 und IPv6 berücksichtigt
[ ] Dienststatus geprüft
[ ] Prozess und aktuelle PID geprüft
[ ] TCP-Listener beziehungsweise UDP-Endpunkt gesucht
[ ] Port dem richtigen Prozess zugeordnet
[ ] Loopback-Bindung ausgeschlossen oder als vorgesehen bestätigt
[ ] Wildcard- oder Einzeladressbindung bewertet
[ ] Lokalen Test über Loopback durchgeführt
[ ] Lokalen Test über die Serveradresse durchgeführt
[ ] Test aus dem betroffenen Clientnetz durchgeführt
[ ] Aufgelöste Zieladresse kontrolliert
[ ] TCP-Verbindungszustände geprüft
[ ] Portkonflikt ausgeschlossen
[ ] Proxy-, Loadbalancer- oder Containerstufe berücksichtigt
[ ] UDP nur mit geeignetem Protokolltest bewertet
[ ] Noch keine ungeprüfte Prozessbeendigung durchgeführt
[ ] Nächsten Diagnoseschritt dokumentiert

Bewertung des Ergebnisses

Ergebnis Nächster Schritt
Kein Listener vorhanden Dienststart, Konfiguration und Protokolle untersuchen
Falscher Prozess besitzt den Port Portkonflikt und Prozessursprung untersuchen
Listener verwendet falschen Port Effektive Dienstkonfiguration prüfen
Listener bindet an falsche Adresse Netzwerkschnittstellen und Bindungskonfiguration prüfen
Nur Loopback ist gebunden Vorgesehenen Proxy oder externe Bindung prüfen
Lokaler Test funktioniert Externen Netzwerkpfad prüfen
Entfernter TCP-Test scheitert Firewall, Routing, NAT und Zwischenkomponenten prüfen
TCP-Test funktioniert TLS und Anwendungsprotokoll prüfen
Viele problematische TCP-Zustände Anwendung, Last und Gegenstellen untersuchen
UDP-Ergebnis ist unklar Protokollspezifischen Funktionstest durchführen

Merksatz

Ein laufender Prozess ohne Listener ist nicht erreichbar. Ein Listener ohne erfolgreichen Porttest ist nicht nachgewiesen erreichbar. Ein erfolgreicher Porttest ohne Anwendungstest beweist noch keine funktionierende Anwendung.

Weiterführende Quellen

4. Server- und Dienstfehler systematisch analysieren

4.5 Dienstabhängigkeiten untersuchen*

Ein Dienst kann korrekt gestartet sein und trotzdem nicht funktionieren, wenn eine benötigte Abhängigkeit fehlt oder fehlerhaft arbeitet. Solche Abhängigkeiten können vom Betriebssystem ausdrücklich konfiguriert oder nur innerhalb der Anwendung hinterlegt sein.

Grundsatz:
Ein abhängiger Dienst kann nur so zuverlässig funktionieren wie die gesamte Kette seiner benötigten Komponenten.

Ziele dieser Seite

Nach dieser Seite sollst du:

1. Formale und funktionale Abhängigkeiten unterscheiden
Art Beschreibung Beispiel
Formale Dienstabhängigkeit In der Betriebssystem-Dienstverwaltung eingetragen Webdienst benötigt einen lokalen Datenbankdienst
Startreihenfolge Legt fest, was vorher oder nachher gestartet wird Anwendung startet nach dem Netzwerkziel
Netzwerkabhängigkeit Externes System muss über das Netzwerk erreichbar sein Anwendung verbindet sich mit Datenbankserver
Namensauflösung Dienst benötigt funktionierendes DNS Backend wird über Hostnamen angesprochen
Speicherabhängigkeit Lokales oder entferntes Dateisystem muss verfügbar sein Anwendung benötigt SMB- oder NFS-Freigabe
Authentifizierungsabhängigkeit Identitätsdienst wird benötigt Anmeldung über Active Directory oder LDAP
Zertifikatsabhängigkeit Vertrauenskette und Gültigkeit müssen stimmen TLS-Verbindung zu einer API
Zeitabhängigkeit Systemuhren müssen ausreichend synchron sein Kerberos oder Zertifikatsprüfung
Ressourcenabhängigkeit CPU, RAM, Speicherplatz oder Dateideskriptoren werden benötigt Datenbank kann keine Dateien mehr schreiben
Anwendungsabhängigkeit Andere Anwendung oder API muss funktionieren Warenwirtschaft greift auf Zahlungsdienst zu
Konfigurationsabhängigkeit Datei, Variable oder Secret muss vorhanden sein Datenbank-URL aus Umgebungsvariable
Infrastrukturabhängigkeit Plattformkomponente stellt Laufzeit bereit Container-Runtime, Hypervisor oder Cluster

Betriebssystemwerkzeuge zeigen normalerweise nur die formal registrierten Abhängigkeiten. Externe Datenbanken, DNS-Server, APIs oder Netzwerkspeicher erscheinen dort häufig nicht.

2. Eine Dienstkette darstellen

Eine Anwendung kann beispielsweise folgende Kette besitzen:

Benutzer
  → Client
  → DNS
  → Netzwerk und Firewall
  → Loadbalancer
  → Reverse Proxy
  → Webserver
  → Anwendungsdienst
  → Datenbank
  → Verzeichnisdienst
  → Netzwerkspeicher
  → externe API

Für jede Verbindung sollten folgende Informationen erfasst werden:

Eigenschaft Beispiel
Quellsystem Anwendungsserver
Zielsystem Datenbankserver
Zielname srv-db01.example.local
Zielport TCP 5432
Protokoll PostgreSQL
Authentifizierung Dienstkonto
Verschlüsselung TLS
Zeitüberschreitung 10 Sekunden
Kritikalität Erforderlich
Verhalten bei Ausfall Anmeldung nicht möglich
Überwachung TCP- und Datenbankabfrage
Verantwortlichkeit Datenbankbetrieb

Praktische Dokumentationsform:

Quelle Abhängigkeit Ziel Port/Protokoll Kritisch Nachweis
Webserver Namensauflösung DNS-Server UDP/TCP 53 Ja DNS-Abfrage
Webserver Anwendung App-Server TCP 8443 Ja HTTPS-Test
App-Server Datenbank DB-Server TCP 5432 Ja Datenbankabfrage
App-Server Anmeldung LDAP-Server TCP 636 Ja LDAPS-Test
App-Server Dateispeicher Fileserver SMB 445 Nein Freigabetest
3. Erforderliche und optionale Abhängigkeiten unterscheiden
Abhängigkeitstyp Verhalten bei Ausfall
Zwingend erforderlich Dienst kann nicht starten oder Hauptfunktion fällt aus
Optional Nur Zusatzfunktion fällt aus
Bedingt erforderlich Nur bestimmte Benutzer oder Vorgänge sind betroffen
Redundant Andere Instanz kann übernehmen
Zwischengespeichert Funktioniert vorübergehend mit vorhandenen Cache-Daten
Asynchron Anfragen werden zunächst in eine Warteschlange geschrieben
Startabhängig Nur während des Starts erforderlich
Laufzeitabhängig Während des gesamten Betriebs erforderlich
Verwaltungsabhängig Nur für Administration oder Monitoring erforderlich

Beispiele:

Der Ausfall einer Abhängigkeit führt nicht immer zum vollständigen Dienststillstand. Teilfunktionen und verzögerte Fehler müssen deshalb ausdrücklich geprüft werden.

4. Windows-Dienstabhängigkeiten mit PowerShell prüfen

<DIENSTNAME> muss durch den internen Dienstnamen ersetzt werden.

Dienst und erforderliche Systemdienste anzeigen:

[RO] Get-Service -Name "<DIENSTNAME>" -RequiredServices

Nur die erforderlichen Dienste übersichtlich anzeigen:

[RO] (Get-Service -Name "<DIENSTNAME>").ServicesDependedOn |
    Select-Object Name, DisplayName, Status

Dienste anzeigen, die vom untersuchten Dienst abhängen:

[RO] Get-Service -Name "<DIENSTNAME>" -DependentServices

Abhängige Dienste übersichtlich anzeigen:

[RO] (Get-Service -Name "<DIENSTNAME>").DependentServices |
    Select-Object Name, DisplayName, Status

Dienst und beide Abhängigkeitsrichtungen erfassen:

[RO] $service = Get-Service -Name "<DIENSTNAME>"

$service | Select-Object Name, DisplayName, Status

"Benötigte Dienste:"
$service.ServicesDependedOn |
    Select-Object Name, DisplayName, Status

"Abhängige Dienste:"
$service.DependentServices |
    Select-Object Name, DisplayName, Status

Wichtig:

5. Windows-Dienstabhängigkeiten mit sc.exe prüfen

Konfiguration einschließlich eingetragener Abhängigkeiten anzeigen:

[RO][SENS] sc.exe qc "<DIENSTNAME>"

Relevant ist insbesondere der Abschnitt:

DEPENDENCIES

Direkt abhängige Dienste anzeigen:

[RO] sc.exe enumdepend "<DIENSTNAME>"

Erweiterte Dienstinformationen anzeigen:

[RO] sc.exe queryex "<DIENSTNAME>"

Interpretation:

Abfrage Richtung
sc.exe qc → DEPENDENCIES Welche Dienste benötigt der untersuchte Dienst?
sc.exe enumdepend Welche Dienste hängen vom untersuchten Dienst ab?

sc.exe qc kann Programmpfade, Dienstkonten und interne Konfigurationsinformationen anzeigen. Die Ausgabe sollte deshalb als potenziell sensibel behandelt werden.

6. Zustand aller formalen Windows-Abhängigkeiten prüfen

Benötigte Dienste samt Startart und Konto untersuchen:

[RO] $requiredServices = (Get-Service -Name "<DIENSTNAME>").ServicesDependedOn

foreach ($requiredService in $requiredServices) {
    Get-CimInstance Win32_Service `
        -Filter "Name='$($requiredService.Name)'" |
        Select-Object Name,
                      DisplayName,
                      State,
                      StartMode,
                      StartName,
                      ProcessId,
                      ExitCode
}

Mögliche Auffälligkeiten:

Ein laufender erforderlicher Dienst kann trotzdem funktional gestört sein. Nach dem Status müssen Listener, Protokoll und tatsächliche Funktion geprüft werden.

7. Abhängigkeiten unter Linux mit systemd anzeigen

Direkte und indirekte Abhängigkeiten anzeigen:

[RO] systemctl list-dependencies "<DIENST>" --no-pager

Nur unmittelbare Abhängigkeiten anzeigen:

[RO] systemctl list-dependencies \
  --plain \
  --no-pager \
  "<DIENST>"

Rückwärts gerichtete Abhängigkeiten anzeigen:

[RO] systemctl list-dependencies \
  --reverse \
  --no-pager \
  "<DIENST>"

Abhängigkeiten und Reihenfolgenbeziehungen strukturiert anzeigen:

[RO] systemctl show "<DIENST>" \
  --property=Requires,Wants,Requisite,BindsTo,PartOf,After,Before,Conflicts

Wirksame Unit-Konfiguration anzeigen:

[RO][FILE][SENS] systemctl cat "<DIENST>"

Status abhängiger Units prüfen:

[RO] systemctl --failed --no-pager

systemctl list-dependencies zeigt systemd-Units. Eine in der Anwendung konfigurierte Datenbank oder API wird nur dann sichtbar, wenn dafür ausdrücklich eine systemd-Beziehung definiert wurde.

8. systemd-Beziehungen richtig interpretieren
Direktive Grundbedeutung
Requires= Starke Anforderungsbeziehung zu einer anderen Unit
Wants= Schwächere Anforderungsbeziehung
Requisite= Andere Unit muss bereits aktiv sein; sie wird dadurch nicht automatisch gestartet
BindsTo= Engere Bindung an den Aktivzustand einer anderen Unit
PartOf= Bestimmte Stop- und Neustartaktionen werden weitergegeben
After= Diese Unit wird nach der genannten Unit gestartet
Before= Diese Unit wird vor der genannten Unit gestartet
Conflicts= Units sollen nicht gleichzeitig aktiv sein
OnFailure= Andere Unit wird bei einem Fehlschlag aktiviert

Besonders wichtig:

Requires=  ist nicht dasselbe wie After=
Wants=     ist nicht dasselbe wie After=
After=     legt Reihenfolge fest, aber keine zwingende Anforderung
Before=    legt Reihenfolge fest, aber keine zwingende Anforderung

Beispiel:

[Unit]
Requires=postgresql.service
After=network-online.target postgresql.service

Mögliche Interpretation:

Für eine zuverlässige Bewertung müssen Anforderungs- und Reihenfolgedirektiven gemeinsam betrachtet werden.

9. Abhängigkeitsbaum unter systemd in beide Richtungen lesen

Vorwärts gerichtete Frage:

Was benötigt dieser Dienst?

[RO] systemctl list-dependencies "<DIENST>" --no-pager

Rückwärts gerichtete Frage:

Welche Units benötigen diesen Dienst?

[RO] systemctl list-dependencies \
  --reverse \
  --no-pager \
  "<DIENST>"

Nur Abhängigkeiten vor einem Neustart prüfen:

[RO] systemctl show "<DIENST>" \
  --property=RequiredBy,WantedBy,ConsistsOf,PartOf

Bewertung vor einer Maßnahme:

Feststellung Bedeutung
Viele rückwärtige Abhängigkeiten Neustart kann mehrere Dienste beeinflussen
PartOf= vorhanden Neustart- oder Stoppaktionen können gekoppelt sein
BindsTo= vorhanden Ausfall kann abhängige Unit ebenfalls deaktivieren
Gemeinsame Datenbankabhängigkeit Datenbankfehler kann mehrere Anwendungen betreffen
Gemeinsames Netzwerkmount Speicherfehler kann mehrere Dienste blockieren
Gemeinsames Target Nicht jede aufgeführte Unit ist zwingend funktional abhängig
10. Abhängigkeiten unter macOS mit launchd untersuchen

launchd besitzt laut Apple kein allgemeines ausdrückliches Abhängigkeitsmodell wie systemd. Dienstinteraktionen sollen möglichst über bedarfsgesteuerte IPC-Mechanismen gelöst werden.

Deshalb müssen mehrere Informationsquellen kombiniert werden.

Systemweiten Dienst anzeigen:

[RO] launchctl print "system/<LABEL>"

Benutzerbezogenen Dienst anzeigen:

[RO] launchctl print "gui/$(id -u)/<LABEL>"

Konfigurationsdatei eines bekannten Drittanbieterdienstes anzeigen:

[RO][FILE][SENS] plutil -p "/Library/LaunchDaemons/<LABEL>.plist"

Benutzerbezogenen LaunchAgent anzeigen:

[RO][FILE][SENS] plutil -p "$HOME/Library/LaunchAgents/<LABEL>.plist"

In der plist können unter anderem folgende Auslöser relevant sein:

Schlüssel Bedeutung
MachServices Vom Job bereitgestellte Mach-Dienste
Sockets Von launchd verwaltete Sockets
KeepAlive Bedingungen für fortlaufende oder erneute Ausführung
PathState Startbedingung anhand vorhandener Pfade
OtherJobEnabled Bedingung anhand des Aktivierungszustands anderer Jobs
WatchPaths Start bei Änderung beobachteter Pfade
QueueDirectories Start bei nicht leerem Verzeichnis
NetworkState Historische grobe Netzwerkbedingung; nicht als Erreichbarkeitsnachweis verwenden
StartOnMount Start beim Einhängen eines Dateisystems

Der Schlüssel OtherJobEnabled bildet keine harte, zuverlässige Dienstabhängigkeit wie ein allgemeines Abhängigkeitsmodell. Apple beschreibt solche Bedingungen als Hinweise und empfiehlt bedarfsgesteuerte IPC-Mechanismen.

11. Versteckte Anwendungsabhängigkeiten finden

Funktionale Abhängigkeiten können an folgenden Stellen dokumentiert oder konfiguriert sein:

Typische Konfigurationsbegriffe:

host
hostname
server
endpoint
url
uri
database
db_host
connection_string
ldap
smtp
proxy
upstream
backend
api
mount
share
certificate
key
timeout
retry

Konfigurationsdateien und Umgebungsvariablen können Geheimnisse enthalten. Nicht wahllos nach Inhalten suchen oder vollständige Dateien in Tickets kopieren.

12. Aktive Netzwerkabhängigkeiten eines Prozesses erkennen

Bereits aufgebaute Verbindungen können Hinweise auf verwendete Backends liefern.

Windows:

[RO][SENS] Get-NetTCPConnection -OwningProcess <PID> |
    Select-Object LocalAddress,
                  LocalPort,
                  RemoteAddress,
                  RemotePort,
                  State

Linux:

[RO][SENS][PRIV] sudo lsof -nP -a -p <PID> -i

macOS:

[RO][SENS][PRIV] sudo lsof -nP -a -p <PID> -i

Damit können Hinweise gefunden werden auf:

Einschränkungen:

13. DNS-Abhängigkeit prüfen

Wenn ein Dienst ein Backend über einen Namen anspricht, muss genau dieser Name aus dem Kontext des Dienstservers geprüft werden.

Aufgabe Windows Linux macOS
A- und AAAA-Auflösung [TEST] Resolve-DnsName "<BACKEND>" [TEST] getent ahosts "<BACKEND>" [TEST] dscacheutil -q host -a name "<BACKEND>"
DNS gezielt abfragen [TEST] Resolve-DnsName "<BACKEND>" -Server <DNS-IP> [TEST] dig @<DNS-IP> "<BACKEND>" A [TEST] dig @<DNS-IP> "<BACKEND>" A
IPv6-Adresse abfragen [TEST] Resolve-DnsName "<BACKEND>" -Type AAAA [TEST] dig "<BACKEND>" AAAA [TEST] dig "<BACKEND>" AAAA

Zu prüfen:

Eine erfolgreiche DNS-Abfrage beweist nur die Namensauflösung. Der zurückgegebene Zielserver muss anschließend über das erforderliche Protokoll geprüft werden.

14. TCP-Abhängigkeit eines Backends prüfen

Windows:

[TEST] Test-NetConnection "<BACKEND>" -Port <PORT>

Linux:

[TEST] nc -vz -w 3 "<BACKEND>" <PORT>

macOS:

[TEST] nc -vz -w 3 "<BACKEND>" <PORT>

Mögliche Ergebnisse:

Ergebnis Bedeutung
Namensauflösung fehlerhaft DNS-Abhängigkeit gestört
Verbindung abgelehnt Ziel erreichbar, aber kein passender Listener oder aktive Ablehnung
Zeitüberschreitung Filterung, Routingproblem oder nicht reagierendes Ziel möglich
TCP-Verbindung erfolgreich Transportweg bis zum Port funktioniert
Anwendung antwortet trotzdem fehlerhaft Protokoll, TLS, Anmeldung oder Backendfunktion prüfen

Der Test muss vom tatsächlichen Anwendungsserver oder aus einem technisch gleichwertigen Netzwerkpfad erfolgen. Ein erfolgreicher Test vom Administrator-Client beweist nicht, dass der Dienstserver denselben Zugriff besitzt.

15. HTTP- oder API-Abhängigkeit prüfen

Nur Antwortheader eines HTTP- oder HTTPS-Endpunkts anfordern:

Betriebssystem Befehl
Windows [TEST][SENS] curl.exe -I --connect-timeout 5 "https://<BACKEND>/<PFAD>"
Linux [TEST][SENS] curl -I --connect-timeout 5 "https://<BACKEND>/<PFAD>"
macOS [TEST][SENS] curl -I --connect-timeout 5 "https://<BACKEND>/<PFAD>"

Ausführliche TLS- und Verbindungsdiagnose:

Betriebssystem Befehl
Windows [TEST][SENS] curl.exe -v --connect-timeout 5 "https://<BACKEND>/<PFAD>"
Linux [TEST][SENS] curl -v --connect-timeout 5 "https://<BACKEND>/<PFAD>"
macOS [TEST][SENS] curl -v --connect-timeout 5 "https://<BACKEND>/<PFAD>"

Zu prüfen:

-v kann Header und andere sensible Informationen anzeigen. Zugangstoken oder Sitzungscookies dürfen nicht in die Befehlszeile oder Dokumentation übernommen werden.

16. Speicher- und Dateisystemabhängigkeiten prüfen
Aufgabe Windows Linux macOS
Eingebundene Datenträger [RO] Get-Volume [RO] findmnt [RO] mount
Freier Speicherplatz [RO] Get-Volume [RO] df -hT [RO] df -h
Bestimmten Pfad prüfen [RO] Test-Path "<PFAD>" [RO] findmnt --target "<PFAD>" [RO] df -h "<PFAD>"
Pfadinformationen [RO][FILE] Get-Item "<PFAD>" [RO][FILE] stat "<PFAD>" [RO][FILE] stat "<PFAD>"
Schreibrechte des aktuellen Kontos [RO][FILE] Get-Acl "<PFAD>" [RO][FILE] namei -l "<PFAD>" [RO][FILE] ls -lde "<PFAD>"

Zu prüfen:

Schreibtests verändern das Dateisystem und dürfen nur gezielt, mit freigegebenem Testpfad und anschließendem Aufräumen durchgeführt werden.

17. Zeit- und Synchronisationsabhängigkeit prüfen

Falsche Systemzeit kann unter anderem folgende Funktionen beeinträchtigen:

Aufgabe Windows Linux macOS
Lokale Zeit [RO] Get-Date -Format o [RO] date --iso-8601=seconds [RO] date "+%Y-%m-%dT%H:%M:%S%z"
UTC-Zeit [RO] (Get-Date).ToUniversalTime().ToString("o") [RO] date -u "+%Y-%m-%dT%H:%M:%SZ" [RO] date -u "+%Y-%m-%dT%H:%M:%SZ"
Zeitzone [RO] Get-TimeZone [RO] timedatectl status [RO][PRIV] sudo systemsetup -gettimezone
Zeitstatus [RO] w32tm /query /status [RO] timedatectl status [RO] systemsetup -getusingnetworktime

Prüfung:

18. Authentifizierungsabhängigkeit prüfen

Typische abhängige Identitätsdienste:

Vor einer Anmeldeprüfung kontrollieren:

  1. Wird der Identitätsserver korrekt aufgelöst?
  2. Ist der erforderliche Port erreichbar?
  3. Ist die Systemzeit synchron?
  4. Ist das Dienstkonto aktiv?
  5. Ist das Kennwort beziehungsweise Secret gültig?
  6. Ist das Konto gesperrt?
  7. Besitzt das Konto die erforderlichen Rechte?
  8. Ist das Serverzertifikat gültig?
  9. Funktioniert nur die Anmeldung nicht oder auch die gesamte Anwendung?
  10. Sind alle Benutzer oder nur einzelne Konten betroffen?

Kennwörter, Tokens und private Schlüssel dürfen niemals in Diagnoseausgaben, Tickets oder BookStack-Beispiele kopiert werden.

19. Gemeinsame Abhängigkeit als Ursache erkennen

Wenn mehrere Dienste gleichzeitig ausfallen, sollte nach einer gemeinsamen Komponente gesucht werden.

Beobachtung Mögliche gemeinsame Abhängigkeit
Mehrere Anwendungen können Benutzer nicht anmelden Verzeichnisdienst, DNS oder Zeitquelle
Mehrere Webseiten liefern Backendfehler Datenbank, Reverse Proxy oder Speicher
Mehrere Dienste können keine Dateien schreiben Volume, Dateisystem oder Berechtigung
Nur externe APIs schlagen fehl Proxy, Internetzugang, DNS oder Zertifikatskette
Alle Dienste eines Hosts sind langsam CPU, RAM, Datenträger oder Virtualisierungsplattform
Mehrere Container starten nicht Container-Runtime, Netzwerk oder Storage
Anwendungen an einem Standort sind betroffen WAN, VPN, DNS oder Firewall
Fehler beginnt exakt gleichzeitig Gemeinsame Änderung oder Infrastrukturkomponente

Vorgehen:

1. Betroffene Dienste auflisten
2. Zeitpunkt jedes Ausfalls vergleichen
3. Gemeinsame DNS-, Netzwerk- und Speicherpfade bestimmen
4. Gemeinsame Datenbanken und Identitätsdienste bestimmen
5. Gemeinsame Änderungen ermitteln
6. Gemeinsame Abhängigkeit direkt prüfen
7. Nach Wiederherstellung alle abhängigen Funktionen testen
20. Startreihenfolge nicht mit Betriebsbereitschaft verwechseln

Ein Dienst kann laut Betriebssystem gestartet worden sein, obwohl seine Funktion noch nicht vollständig bereitsteht.

Beispiel:

00:00 Datenbankprozess startet
00:02 Dienstverwaltung meldet „läuft“
00:05 Datenbank führt Wiederherstellung aus
00:40 Datenbank nimmt Anmeldungen an

Startet die Anwendung bereits bei Sekunde 3, kann ihre Verbindung fehlschlagen, obwohl der Datenbankdienst formal läuft.

Mögliche Lösungen innerhalb eines geplanten Änderungsverfahrens:

Eine feste Wartezeit ist häufig weniger zuverlässig als eine echte Bereitschaftsprüfung.

21. Auswirkungen vor einem Neustart einer Abhängigkeit prüfen

Vor dem Neustart eines gemeinsam verwendeten Dienstes müssen die abhängigen Verbraucher bestimmt werden.

Windows:

[RO] (Get-Service -Name "<DIENSTNAME>").DependentServices |
    Select-Object Name, DisplayName, Status

Linux:

[RO] systemctl list-dependencies \
  --reverse \
  --no-pager \
  "<DIENST>"

macOS:

Da launchd kein allgemeines ausdrückliches Abhängigkeitsmodell besitzt, müssen zusätzlich geprüft werden:

Freigabecheck:

[ ] Alle bekannten Verbraucher identifiziert
[ ] Aktive Sitzungen und Transaktionen geprüft
[ ] Cluster- oder Failover-Verhalten geprüft
[ ] Wiederverbindungsverhalten der Clients bekannt
[ ] Neustartreihenfolge festgelegt
[ ] Wartungsfenster beziehungsweise Freigabe vorhanden
[ ] Diagnoseinformationen vorab gesichert
[ ] Funktionstests für alle wichtigen Verbraucher vorbereitet
[ ] Rückfallmöglichkeit festgelegt
22. Abhängigkeitsfehler schrittweise eingrenzen

Empfohlene Reihenfolge:

  1. Hauptfunktion und Fehlermeldung bestimmen.
  2. Formale Dienstabhängigkeiten erfassen.
  3. Architektur und funktionale Abhängigkeiten ergänzen.
  4. Kritische und optionale Abhängigkeiten kennzeichnen.
  5. Namen der Zielsysteme prüfen.
  6. DNS-Auflösung prüfen.
  7. Netzwerkport vom tatsächlichen Dienstserver prüfen.
  8. TLS- und Zertifikatsprüfung durchführen.
  9. Protokollspezifischen Funktionstest durchführen.
  10. Authentifizierung mit einem freigegebenen Testkonto prüfen.
  11. Speicher- und Ressourcenabhängigkeiten prüfen.
  12. Zeitstempel der beteiligten Systeme vergleichen.
  13. Protokolle auf Quelle und Ziel korrelieren.
  14. Gemeinsame Abhängigkeiten anderer gestörter Dienste prüfen.
  15. Erst nach gesicherter Ursache eine Änderung planen.

Prüfkette:

Name korrekt?
  ↓
DNS korrekt?
  ↓
Route vorhanden?
  ↓
Port erreichbar?
  ↓
TLS gültig?
  ↓
Protokoll antwortet?
  ↓
Authentifizierung erfolgreich?
  ↓
Berechtigung ausreichend?
  ↓
Fachliche Anfrage erfolgreich?
23. Typische Fehlinterpretationen
Fehlinterpretation Richtige Bewertung
„Alle Abhängigkeiten stehen in der Dienstverwaltung.“ Viele funktionale Abhängigkeiten sind nur in der Anwendung konfiguriert
„Der erforderliche Dienst läuft, also funktioniert er.“ Seine fachliche Funktion muss separat geprüft werden
„After= bedeutet, dass der andere systemd-Dienst zwingend benötigt wird.“ After= legt nur eine Reihenfolge fest
„Requires= bedeutet automatisch die richtige Startreihenfolge.“ Dafür kann zusätzlich After= oder Before= erforderlich sein
„Ein erfolgreicher Porttest beweist die Backendfunktion.“ Nur der Transportweg wurde bestätigt
„DNS liefert eine Adresse, also ist das richtige Backend erreicht.“ Adresse, Zertifikat und Anwendungsantwort müssen geprüft werden
„Alle Benutzer sind betroffen, also liegt es am Hauptdienst.“ Eine gemeinsame Abhängigkeit kann ausgefallen sein
„Ein Neustart der Hauptanwendung repariert die Abhängigkeit.“ Er kann nur neue Verbindungsversuche auslösen
„Startreihenfolge beweist Betriebsbereitschaft.“ Ein Prozess kann laufen, während die Initialisierung noch andauert
„Ein optionales Backend kann ignoriert werden.“ Es kann für einzelne wichtige Funktionen zwingend sein
24. Checkliste zur Abhängigkeitsanalyse 
[ ] Hauptdienst eindeutig bestimmt
[ ] Formale Betriebssystem-Abhängigkeiten erfasst
[ ] Vorwärts gerichtete Abhängigkeiten geprüft
[ ] Rückwärts gerichtete Abhängigkeiten geprüft
[ ] Startreihenfolge getrennt von Anforderung bewertet
[ ] Kritische und optionale Abhängigkeiten unterschieden
[ ] Externe Datenbanken erfasst
[ ] DNS- und Zeitabhängigkeiten erfasst
[ ] Authentifizierungsdienste erfasst
[ ] Speicher- und Dateisystemabhängigkeiten erfasst
[ ] Proxys, Loadbalancer und APIs erfasst
[ ] Container-, Cluster- oder Cloud-Abhängigkeiten berücksichtigt
[ ] DNS-Auflösung vom Dienstserver geprüft
[ ] Zielport vom Dienstserver geprüft
[ ] TLS und Zertifikatsname geprüft
[ ] Protokollspezifischer Funktionstest durchgeführt
[ ] Gemeinsame Abhängigkeiten anderer Störungen geprüft
[ ] Protokollzeitstempel korreliert
[ ] Auswirkungen eines Neustarts bewertet
[ ] Keine Geheimnisse dokumentiert
[ ] Nächsten Diagnoseschritt festgelegt

Bewertung des Ergebnisses

Ergebnis Nächster Schritt
Formale Abhängigkeit ist beendet Status, Startfehler und Protokolle dieser Abhängigkeit prüfen
Abhängigkeit ist deaktiviert oder maskiert Sollzustand und Änderungshistorie klären
DNS-Auflösung schlägt fehl DNS-Konfiguration und verwendeten Namen prüfen
Port der Abhängigkeit ist nicht erreichbar Listener, Firewall und Netzwerkpfad prüfen
Port ist erreichbar, Protokolltest scheitert TLS, Authentifizierung und Anwendung prüfen
Speicherpfad fehlt Mount, Volume, Netzwerk und Berechtigungen prüfen
Nur Anmeldung schlägt fehl Identitätsdienst, Zeit und Dienstkonto prüfen
Mehrere Dienste sind gleichzeitig betroffen Gemeinsame Abhängigkeit priorisiert untersuchen
Backend ist erst spät betriebsbereit Healthcheck, Wiederholungslogik und Startablauf prüfen
Alle Abhängigkeiten funktionieren Hauptdienstkonfiguration und Dienstprotokolle untersuchen

Merksatz

Die sichtbare Anwendung ist oft nur das letzte Glied einer langen Dienstkette. Die Ursache liegt häufig in einer gemeinsam genutzten, zunächst unsichtbaren Abhängigkeit.

Weiterführende Quellen

4. Server- und Dienstfehler systematisch analysieren

4.6 System- und Dienstprotokolle auswerten

System- und Dienstprotokolle dokumentieren Ereignisse, die während des Starts, Betriebs und Beendens eines Dienstes auftreten. Sie können Hinweise auf Konfigurationsfehler, fehlende Berechtigungen, nicht erreichbare Abhängigkeiten, Ressourcenmangel oder Programmabstürze liefern.

Grundsatz:
Protokolle werden nicht wahllos nach dem Wort „Fehler“ durchsucht. Zuerst werden Zeitraum, betroffener Dienst, Server und auslösende Aktion festgelegt.

Ziele dieser Seite

Nach dieser Seite sollst du:

1. Beobachtung, Protokollhinweis und Ursache unterscheiden
Ebene Beispiel
Benutzerbeobachtung Anmeldung schlägt um 09:15 Uhr fehl
Anwendungsprotokoll Datenbankverbindung um 09:15:02 Uhr fehlgeschlagen
Systemprotokoll Netzwerkschnittstelle um 09:14:58 Uhr getrennt
Backendprotokoll Keine Anfrage vom Anwendungsserver eingegangen
Ursache Netzwerkschnittstelle verlor aufgrund eines Treiberfehlers die Verbindung
Folgefehler Anwendung meldete anschließend einen Datenbankfehler

Eine Protokollmeldung kann sein:

Der erste sichtbare Fehler in einer Anwendung ist nicht zwingend das zeitlich erste technische Ereignis.

2. Vor der Suche ein genaues Zeitfenster festlegen

Folgende Zeitangaben müssen möglichst genau bestimmt werden:

Information Beispiel
Beginn des Fehlers 2026-07-31T09:15:00+02:00
Ende beziehungsweise letzter Fehler 2026-07-31T09:22:00+02:00
Zeitzone Europe/Berlin, UTC+02:00
Auslösende Aktion Anmeldung abgesendet
Clientzeit 09:15:00
Serverzeit 09:15:02
Backendzeit 07:15:02 UTC
Vergleichszeitpunkt Letzte erfolgreiche Anmeldung um 09:13 Uhr

Empfohlener Suchbereich:

Einige Minuten vor dem ersten sichtbaren Fehler
bis
einige Minuten nach dem letzten beobachteten Fehler

Prüffragen:

3. Protokollanalyse mit einer klaren Hypothese beginnen

Ungeeignete Suche:

„Ich suche in allen Protokollen nach Fehlern.“

Geeignete Suche:

„Ich untersuche zwischen 09:10 und 09:20 Uhr die Ereignisse des Anwendungsdienstes, des Service Control Managers und der Datenbankverbindung.“

Eine gute Protokollsuche verwendet möglichst mehrere Filter:

Empfohlene Reihenfolge:

1. Zeitpunkt festlegen
2. Hauptdienst filtern
3. Erste relevante Fehlermeldung bestimmen
4. Einige Ereignisse davor lesen
5. Abhängige Systeme prüfen
6. Fehlercode in offizieller Dokumentation nachschlagen
7. Ereignisse zeitlich zusammenführen
8. Hypothese mit einem gezielten Test überprüfen
4. Protokollquellen der Betriebssysteme vergleichen
Bereich Windows Linux mit systemd macOS
Zentrale Oberfläche Ereignisanzeige journalctl Konsole
Zentrales Befehlswerkzeug Get-WinEvent journalctl log
Systemereignisse Protokoll System System-Journal Unified Logging
Anwendungsereignisse Protokoll Application oder eigenes Protokoll Journal oder Anwendungsdatei Unified Logging oder Anwendungsdatei
Dienstverwaltung Service Control Manager systemd launchd
Kernelmeldungen Protokoll System journalctl -k log show und Diagnoseberichte
Absturzberichte Windows Error Reporting Coredump- oder Anwendungsmechanismus Diagnoseberichte
Dateibasierte Logs Anwendungsspezifisch Häufig unter /var/log oder Produktpfad Anwendungsspezifisch

Nicht jede Anwendung schreibt in das zentrale Betriebssystemprotokoll. Herstellerdokumentation und effektive Dienstkonfiguration müssen zusätzlich geprüft werden.

5. Verfügbare Windows-Ereignisprotokolle ermitteln

Alle registrierten Protokolle auflisten:

[RO] Get-WinEvent -ListLog *

Nur aktivierte Protokolle anzeigen:

[RO] Get-WinEvent -ListLog * |
    Where-Object IsEnabled |
    Select-Object LogName, RecordCount, FileSize, MaximumSizeInBytes |
    Sort-Object LogName

Bestimmtes Protokoll untersuchen:

[RO] Get-WinEvent -ListLog "System"

Registrierte Ereignisanbieter suchen:

[RO] Get-WinEvent -ListProvider "*<SUCHBEGRIFF>*"

Typische Windows-Protokolle:

Protokoll Typischer Inhalt
System Dienste, Treiber, Netzwerk und Betriebssystem
Application Anwendungen und Laufzeitumgebungen
Security Sicherheitsereignisse und Überwachung
Setup Installation und Systemeinrichtung
ForwardedEvents Weitergeleitete Ereignisse
Anwendungs- und Dienstprotokolle Komponenten- oder produktspezifische Ereignisse

Der Zugriff auf das Sicherheitsprotokoll und bestimmte administrative Protokolle erfordert erhöhte Berechtigungen.

6. Letzte Windows-Ereignisse anzeigen

Letzte 50 Systemereignisse anzeigen:

[RO] Get-WinEvent -LogName "System" -MaxEvents 50 |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  Message

Letzte 50 Anwendungsereignisse anzeigen:

[RO] Get-WinEvent -LogName "Application" -MaxEvents 50 |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  Message

Neueste Ereignisse zuerst tabellarisch anzeigen:

[RO] Get-WinEvent -LogName "System" -MaxEvents 100 |
    Format-Table TimeCreated,
                 Id,
                 LevelDisplayName,
                 ProviderName,
                 Message -Wrap

Format-Table sollte hauptsächlich für die Anzeige verwendet werden. Für Export oder Weiterverarbeitung bleiben die ursprünglichen Ereignisobjekte geeigneter.

7. Windows-Ereignisse nach Zeitfenster filtern

Ereignisse der letzten Stunde:

[RO] $startTime = (Get-Date).AddHours(-1)

Get-WinEvent -FilterHashtable @{
    LogName   = "System"
    StartTime = $startTime
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  Message

Festes Zeitfenster verwenden:

[RO] $startTime = Get-Date "2026-07-31 09:10:00"
$endTime   = Get-Date "2026-07-31 09:20:00"

Get-WinEvent -FilterHashtable @{
    LogName   = "System"
    StartTime = $startTime
    EndTime   = $endTime
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  Message

System- und Anwendungsprotokoll gemeinsam durchsuchen:

[RO] Get-WinEvent -FilterHashtable @{
    LogName   = "System", "Application"
    StartTime = $startTime
    EndTime   = $endTime
} |
    Sort-Object TimeCreated |
    Select-Object TimeCreated,
                  LogName,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  Message

Die Uhrzeitangaben werden im Kontext des ausführenden Systems interpretiert. Zeitzone und Uhrzeitsynchronisation müssen deshalb vor der Korrelation geklärt sein.

8. Windows-Ereignisse nach Quelle, ID und Schweregrad filtern

Nach Ereignisanbieter filtern:

[RO] Get-WinEvent -FilterHashtable @{
    LogName      = "System"
    ProviderName = "Service Control Manager"
    StartTime    = (Get-Date).AddHours(-2)
}

Nach bestimmten Ereignis-IDs filtern:

[RO] Get-WinEvent -FilterHashtable @{
    LogName      = "System"
    ProviderName = "Service Control Manager"
    Id           = 7000, 7001, 7031, 7034
    StartTime    = (Get-Date).AddHours(-24)
} |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

Nur kritische Ereignisse und Fehler anzeigen:

[RO] Get-WinEvent -FilterHashtable @{
    LogName   = "System"
    Level     = 1, 2
    StartTime = (Get-Date).AddHours(-2)
}

Übliche Windows-Ereignisebenen:

Zahlenwert Ebene
1 Kritisch
2 Fehler
3 Warnung
4 Information
5 Ausführlich

Ereignis-IDs sind nur zusammen mit Anbieter und Protokoll eindeutig zu bewerten. Dieselbe ID kann bei unterschiedlichen Anbietern eine andere Bedeutung besitzen.

9. Typische Windows-Dienstereignisse einordnen

Häufig relevante Ereignisse des Service Control Managers sind:

Ereignis-ID Typische Bedeutung
7000 Dienst konnte nicht gestartet werden
7001 Abhängiger Dienst oder Abhängigkeitsgruppe konnte nicht gestartet werden
7009 Zeitüberschreitung beim Warten auf eine Dienstverbindung
7011 Zeitüberschreitung bei einer Diensttransaktion
7023 Dienst wurde mit einem Fehler beendet
7024 Dienst wurde mit einem dienstspezifischen Fehler beendet
7031 Dienst wurde unerwartet beendet; Wiederherstellungsaktion kann folgen
7034 Dienst wurde unerwartet beendet
7035 Steuerbefehl wurde an einen Dienst gesendet
7036 Dienst wechselte in einen anderen Zustand
7040 Startart wurde geändert
7045 Ein Dienst wurde im System installiert

Wichtig:

10. Windows-Ereignisse nach Nachrichtentext durchsuchen

Nach einem Dienstnamen innerhalb eines begrenzten Zeitraums suchen:

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = "System", "Application"
    StartTime = (Get-Date).AddHours(-2)
} |
    Where-Object Message -Match "<DIENSTNAME>" |
    Select-Object TimeCreated,
                  LogName,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  Message

Nach einem Fehlercode suchen:

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = "System", "Application"
    StartTime = (Get-Date).AddHours(-24)
} |
    Where-Object Message -Match "<FEHLERCODE>"

Textfilter mit Where-Object werden erst nach dem Lesen der Ereignisse angewendet und können bei großen Protokollen langsam sein. Zeitfenster, Protokoll und Anbieter sollten deshalb bereits serverseitig mit FilterHashtable eingeschränkt werden.

11. Windows-Ereignisse mit wevtutil prüfen und sichern

Informationen zu einem Protokoll anzeigen:

[RO] wevtutil get-log "System"

Kurzform:

[RO] wevtutil gl "System"

Die letzten Ereignisse eines Protokolls abfragen:

[RO] wevtutil query-events "System" /count:20 /reverse-direction:true /format:text

Kurzform:

[RO] wevtutil qe "System" /c:20 /rd:true /f:text

Ein vollständiges Ereignisprotokoll exportieren:

[RO][FILE][SENS][PRIV] wevtutil export-log `
    "System" `
    "<AUSGABEDATEI>.evtx"

Kurzform:

[RO][FILE][SENS][PRIV] wevtutil epl "System" "<AUSGABEDATEI>.evtx"

Eine EVTX-Datei kann Benutzernamen, Rechnernamen, interne Pfade, IP-Adressen und sicherheitsrelevante Ereignisse enthalten. Sie darf nur kontrolliert weitergegeben werden.

12. Linux-Journal eines Dienstes anzeigen

Gesamtes Journal einer systemd-Unit anzeigen:

[RO][SENS][PRIV] sudo journalctl -u "<DIENST>" --no-pager

Neueste Einträge zuerst anzeigen:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  --reverse \
  --no-pager

Letzte 100 Einträge anzeigen:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  -n 100 \
  --no-pager

Nur Ereignisse des aktuellen Systemstarts:

[RO][SENS][PRIV] sudo journalctl \
  -b \
  -u "<DIENST>" \
  --no-pager

Ereignisse des vorherigen Systemstarts:

[RO][SENS][PRIV] sudo journalctl \
  -b -1 \
  -u "<DIENST>" \
  --no-pager

Ob Ereignisse früherer Systemstarts verfügbar sind, hängt von der Journal-Konfiguration und Aufbewahrung ab.

13. Linux-Journal nach Zeitfenster filtern

Ereignisse seit einer festen Uhrzeit:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  --since "2026-07-31 09:10:00" \
  --no-pager

Festes Start- und Endzeitfenster:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  --since "2026-07-31 09:10:00" \
  --until "2026-07-31 09:20:00" \
  --no-pager

Relative Zeitangabe:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  --since "1 hour ago" \
  --no-pager

Alle Ereignisse des heutigen Tages:

[RO][SENS][PRIV] sudo journalctl --since today --no-pager

Zeitstempel mit ISO-Datum ausgeben:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  --since "1 hour ago" \
  --output=short-iso \
  --no-pager
14. Linux-Journal nach Priorität filtern

Übliche syslog-Prioritäten:

Wert Name Bedeutung
0 emerg System unbenutzbar
1 alert Sofortige Maßnahme erforderlich
2 crit Kritischer Zustand
3 err Fehler
4 warning Warnung
5 notice Bedeutender normaler Zustand
6 info Information
7 debug Debugmeldung

Fehler und schwerwiegendere Meldungen eines Dienstes:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  -p err \
  --since "1 hour ago" \
  --no-pager

Warnungen und schwerwiegendere Meldungen:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  -p warning \
  --since "1 hour ago" \
  --no-pager

Nur einen bestimmten Prioritätsbereich verwenden:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  -p warning..err \
  --since "1 hour ago" \
  --no-pager

Nicht jede Anwendung verwendet Prioritäten korrekt. Eine relevante Fehlermeldung kann deshalb als info oder ohne geeignete Priorität protokolliert worden sein.

15. Linux-Journal nach Prozess oder Kennung filtern

Nach Prozess-ID filtern:

[RO][SENS][PRIV] sudo journalctl _PID=<PID> --no-pager

Nach ausführbarer Datei filtern:

[RO][SENS][PRIV] sudo journalctl \
  _EXE="<VOLLSTÄNDIGER_PROGRAMMPFAD>" \
  --no-pager

Nach syslog-Kennung filtern:

[RO][SENS][PRIV] sudo journalctl \
  -t "<KENNUNG>" \
  --no-pager

Felder eines Ereignisses ausführlich anzeigen:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  -n 20 \
  -o verbose \
  --no-pager

Mögliche strukturierte Felder:

_SYSTEMD_UNIT
_PID
_UID
_GID
_EXE
_COMM
_HOSTNAME
SYSLOG_IDENTIFIER
PRIORITY
MESSAGE

PID-Filter sind nur für die Lebensdauer der jeweiligen Prozessinstanz geeignet. Nach einem Neustart besitzt der Dienst möglicherweise eine neue PID.

16. Linux-Kernel- und Bootmeldungen prüfen

Kernelmeldungen des aktuellen Systemstarts:

[RO][SENS][PRIV] sudo journalctl -k -b --no-pager

Kernelwarnungen und schwerwiegendere Meldungen:

[RO][SENS][PRIV] sudo journalctl \
  -k \
  -b \
  -p warning \
  --no-pager

Alle Meldungen des aktuellen Systemstarts:

[RO][SENS][PRIV] sudo journalctl -b --no-pager

Verfügbare Systemstarts anzeigen:

[RO] journalctl --list-boots

Relevante Kernelhinweise können sein:

17. Linux-Journal live beobachten

Neue Ereignisse eines Dienstes live anzeigen:

[TEST][SENS][PRIV] sudo journalctl \
  -f \
  -u "<DIENST>"

Mit bestehenden letzten Zeilen beginnen:

[TEST][SENS][PRIV] sudo journalctl \
  -n 50 \
  -f \
  -u "<DIENST>"

Nur Warnungen und schwerwiegendere Meldungen verfolgen:

[TEST][SENS][PRIV] sudo journalctl \
  -f \
  -u "<DIENST>" \
  -p warning

Vorgehen beim kontrollierten Live-Test:

1. Live-Ansicht starten
2. Genauen Startzeitpunkt notieren
3. Eine einzelne Testaktion ausführen
4. Neue Ereignisse beobachten
5. Testaktion und Ereignisse zeitlich zuordnen
6. Live-Ansicht mit Strg+C beenden
7. Relevante Meldungen dokumentieren

Live-Logging kann große Mengen ausgeben. Der Filter sollte vor dem Test möglichst eng gesetzt werden.

18. Linux-Journalgröße und Aufbewahrung prüfen

Belegten Speicherplatz des Journals anzeigen:

[RO] journalctl --disk-usage

Verfügbare Systemstarts anzeigen:

[RO] journalctl --list-boots

Journal-Konfiguration lesen:

[RO][FILE] systemd-analyze cat-config systemd/journald.conf

Wichtige Konfigurationsbereiche können sein:

Storage
SystemMaxUse
RuntimeMaxUse
MaxRetentionSec
MaxFileSec
RateLimitIntervalSec
RateLimitBurst

Mögliche Gründe für fehlende alte Einträge:

Aufbewahrungseinstellungen dürfen nicht während einer Störung ungeprüft verändert werden. Zuerst muss der aktuelle Zustand dokumentiert werden.

19. Textbasierte Linux-Anwendungsprotokolle prüfen

Der tatsächliche Protokollpfad muss aus Herstellerdokumentation oder effektiver Konfiguration ermittelt werden.

Letzte Zeilen einer bekannten Protokolldatei:

[RO][FILE][SENS][PRIV] sudo tail -n 100 "<PROTOKOLLDATEI>"

Neue Einträge live verfolgen:

[TEST][FILE][SENS][PRIV] sudo tail -F "<PROTOKOLLDATEI>"

Nach einem festen Text suchen:

[RO][FILE][SENS][PRIV] sudo grep \
  -n \
  -i \
  -- "<SUCHTEXT>" \
  "<PROTOKOLLDATEI>"

Komprimierte rotierte Protokolle durchsuchen:

[RO][FILE][SENS][PRIV] sudo zgrep \
  -n \
  -i \
  -- "<SUCHTEXT>" \
  "<PROTOKOLLDATEI>.gz"

Datei kontrolliert mit Pager öffnen:

[RO][FILE][SENS][PRIV] sudo less "<PROTOKOLLDATEI>"

Nützliche Tasten in less:

Taste Funktion
/Text Vorwärts suchen
?Text Rückwärts suchen
n Nächster Treffer
N Vorheriger Treffer
G Dateiende
g Dateianfang
q Beenden

Keine angenommenen Standardpfade verwenden. Container, Pakete und Hersteller können unterschiedliche Protokollziele konfigurieren.

20. macOS Unified Logging nach Zeitraum auswerten

Meldungen der letzten Stunde anzeigen:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --style compact \
  --no-pager

Meldungen seit dem letzten Systemstart:

[RO][SENS][PRIV] sudo log show \
  --last boot \
  --style compact \
  --no-pager

Festes Zeitfenster verwenden:

[RO][SENS][PRIV] sudo log show \
  --start "2026-07-31 09:10:00" \
  --end "2026-07-31 09:20:00" \
  --style compact \
  --no-pager

Lokale Zeitzone ausdrücklich verwenden:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --timezone local \
  --style compact \
  --no-pager

Standardmäßig zeigt log show nicht zwingend alle Info- und Debugmeldungen. Diese Ebenen werden bei Bedarf ausdrücklich aktiviert.

21. macOS-Protokolle nach Prozess filtern

Nach Prozessnamen filtern:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate 'process == "<PROZESS>"' \
  --style compact \
  --no-pager

Nach Prozess-ID filtern:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate 'processIdentifier == <PID>' \
  --style compact \
  --no-pager

Info-Meldungen einschließen:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --info \
  --predicate 'process == "<PROZESS>"' \
  --style compact \
  --no-pager

Info- und Debugmeldungen einschließen:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --info \
  --debug \
  --predicate 'process == "<PROZESS>"' \
  --style compact \
  --no-pager

Die Erhöhung des sichtbaren Umfangs kann sehr große Ausgaben erzeugen. Zuerst sollte mit engem Zeitfenster und Prozessfilter gearbeitet werden.

22. macOS-Protokolle nach Subsystem und Schweregrad filtern

Nach bekanntem Subsystem filtern:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate 'subsystem == "<SUBSYSTEM>"' \
  --style compact \
  --no-pager

Fehler und Faults eines Prozesses anzeigen:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate 'process == "<PROZESS>" AND (messageType == error OR messageType == fault)' \
  --style compact \
  --no-pager

Nach Text innerhalb der Meldung suchen:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate 'eventMessage CONTAINS[c] "<SUCHTEXT>"' \
  --style compact \
  --no-pager

Wichtige Filterfelder:

Feld Bedeutung
process Name des erzeugenden Prozesses
processIdentifier PID
subsystem Logisches Subsystem
category Kategorie innerhalb des Subsystems
messageType Meldungstyp
eventMessage Meldungstext
sender Bibliothek oder ausführende Komponente
processImagePath Programmpfad
23. macOS-Protokolle live beobachten

Meldungen eines Prozesses live verfolgen:

[TEST][SENS][PRIV] sudo log stream \
  --predicate 'process == "<PROZESS>"' \
  --style compact

Fehler und Faults live verfolgen:

[TEST][SENS][PRIV] sudo log stream \
  --predicate 'process == "<PROZESS>" AND (messageType == error OR messageType == fault)' \
  --style compact

Live-Ausgabe zeitlich begrenzen:

[TEST][SENS][PRIV] sudo log stream \
  --timeout 5m \
  --predicate 'process == "<PROZESS>"' \
  --style compact

Info-Ebene einbeziehen:

[TEST][SENS][PRIV] sudo log stream \
  --level info \
  --predicate 'process == "<PROZESS>"' \
  --style compact

Der Befehl wird ohne Zeitbegrenzung mit Strg+C beendet. Eine zeitliche Begrenzung verhindert versehentlich lange laufende Mitschnitte.

24. macOS-Protokollarchiv sichern

Protokolle der letzten Stunde in ein Logarchiv sammeln:

[RO][FILE][SENS][PRIV] sudo log collect \
  --last 1h \
  --output "<AUSGABEDATEI>.logarchive"

Protokolle ab einem festen Zeitpunkt sammeln:

[RO][FILE][SENS][PRIV] sudo log collect \
  --start "2026-07-31 09:10:00" \
  --output "<AUSGABEDATEI>.logarchive"

Ein .logarchive kann später mit der App „Konsole“ oder mit log show ausgewertet werden.

Archiv über die Kommandozeile lesen:

[RO][FILE][SENS] log show \
  --archive "<AUSGABEDATEI>.logarchive" \
  --style compact \
  --no-pager

Ein vollständiges macOS-Logarchiv kann umfangreiche und sensible Systeminformationen enthalten. Vor einer externen Weitergabe müssen Zweck, Empfänger und Datenschutz geprüft werden.

25. Anwendungsprotokolle unter Windows und macOS berücksichtigen

Nicht jede Anwendung verwendet ausschließlich das zentrale Systemprotokoll.

Mögliche Protokollziele:

Protokollpfad korrekt ermitteln über:

  1. Herstellerdokumentation,
  2. wirksame Dienstkonfiguration,
  3. Startparameter,
  4. Umgebungsvariablen,
  5. Dienstkonto,
  6. Containerdefinition,
  7. Protokollierungs- oder Loggingabschnitt der Anwendung.

Keine Verzeichnisse oder Dateinamen als gegeben annehmen. Der wirksame Pfad kann durch Installation, Paketierung oder lokale Konfiguration verändert worden sein.

26. Containerprotokolle berücksichtigen

Bei containerisierten Diensten können Protokolle an mehreren Stellen entstehen:

Hostbetriebssystem
  → Container-Runtime
  → Container
  → Prozess im Container
  → Anwendung
  → externes zentrales Logging

Mögliche Protokollquellen:

Prüffragen:

Die konkrete Runtime wird in dieser Seite nicht vorausgesetzt. Die passenden Befehle müssen anhand der tatsächlich eingesetzten Containerplattform ausgewählt werden.

27. Protokolle mehrerer Systeme zeitlich korrelieren

Beispiel:

Zeit System Ereignis
09:14:58 Datenbankserver Datenträger meldet Schreibfehler
09:15:00 Datenbankserver Datenbank beendet Schreibtransaktion mit Fehler
09:15:02 Anwendungsserver Datenbankverbindung wird zurückgesetzt
09:15:03 Webserver Backend antwortet nicht
09:15:04 Client HTTP 503 wird angezeigt

Wahrscheinliche Ereigniskette:

Datenträgerfehler
  → Datenbankfehler
  → Verbindung des Anwendungsservers bricht ab
  → Webserver erhält keine gültige Backendantwort
  → Benutzer sieht HTTP 503

Vorgehen:

  1. Alle Zeitstempel in dieselbe Zeitzone überführen.
  2. Erstes technisches Ereignis bestimmen.
  3. Vorhergehende Warnungen berücksichtigen.
  4. Fehler auf Quell- und Zielsystem vergleichen.
  5. Verbindungs- oder Korrelations-IDs verwenden.
  6. Ursache und Folge in einer Zeitleiste dokumentieren.
  7. Hypothese mit technischen Tests bestätigen.
28. Fehlercodes richtig auswerten

Ein Fehlercode sollte zusammen mit folgendem Kontext dokumentiert werden:

Betriebssystem:
Produkt:
Komponente:
Version:
Protokoll:
Ereignisanbieter:
Ereignis-ID:
Fehlercode:
Vollständige Meldung:
Zeitpunkt:
Auslösende Aktion:

Regeln:

Eine Suchmaschinenfundstelle ohne passenden Hersteller-, Versions- und Komponentenkontext ist kein ausreichender Ursachenbeweis.

29. Fehlende Protokolle richtig bewerten

Keine gefundene Meldung bedeutet nicht automatisch, dass kein Fehler auftrat.

Mögliche Gründe:

Das Fehlen einer Meldung ist nur dann aussagekräftig, wenn bekannt ist, dass genau dieses Ereignis an dieser Stelle protokolliert werden müsste.

30. Sensible Inhalte in Protokollen erkennen

Protokolle können enthalten:

Vor Weitergabe prüfen:

[ ] Zweck der Weitergabe geklärt
[ ] Empfänger berechtigt
[ ] Zeitraum auf das Notwendige begrenzt
[ ] Nicht relevante Ereignisse entfernt
[ ] Kennwörter und Token entfernt
[ ] Cookies und Authorization-Header entfernt
[ ] Personenbezogene Daten geschützt
[ ] Interne Infrastrukturinformationen bewertet
[ ] Originaldatei beweissicher aufbewahrt
[ ] Bearbeitete Kopie als solche gekennzeichnet

Das Original darf bei einer Beweissicherung nicht unkontrolliert verändert werden. Für Weitergaben wird eine gesonderte bereinigte Kopie erstellt.

31. Relevante Protokollstellen dokumentieren

Dokumentationsvorlage:

Störung:
Server:
Dienst:
Betriebssystem:
Zeitzone:
Untersuchter Zeitraum:
Protokollquelle:
Ereignisanbieter beziehungsweise Prozess:
Ereignis-ID:
Fehlercode:
Zeitstempel:
Vollständige relevante Meldung:
Unmittelbar vorhergehendes Ereignis:
Unmittelbar folgendes Ereignis:
Betroffene Abhängigkeit:
Interpretation:
Beleg für die Interpretation:
Nächster Prüfschritt:

Gute Dokumentation:

Um 09:15:02 Uhr protokollierte der Anwendungsdienst eine zurückgesetzte Datenbankverbindung. Zwei Sekunden zuvor meldete der Datenbankserver einen Schreibfehler. Die zeitliche Reihenfolge spricht für einen Zusammenhang, der durch Datenträger- und Datenbankprüfung bestätigt werden muss.

Unzureichende Dokumentation:

In den Logs stand etwas mit Datenbank.

32. Typische Fehler bei der Protokollanalyse
Fehler Folge Bessere Vorgehensweise
Gesamtes Protokoll ohne Zeitfilter lesen Relevante Ereignisse gehen in Datenmenge unter Enges Zeitfenster verwenden
Nur Fehlerstufe anzeigen Relevante Warnungen oder Infos fehlen Kontext vor und nach dem Fehler lesen
Nur Hauptserver prüfen Backendursache bleibt verborgen Abhängige Systeme einbeziehen
Neueste Meldung als Ursache behandeln Folgefehler wird verwechselt Zeitlich erstes relevantes Ereignis suchen
Ereignis-ID ohne Anbieter bewerten Falsche Bedeutung möglich Anbieter, Protokoll und Version notieren
Zeitzonen ignorieren Ereigniskette wird falsch sortiert Zeitstempel normalisieren
Debuglogging dauerhaft aktivieren Datenmenge und Datenschutzrisiko steigen Nur kontrolliert und zeitlich begrenzt
Protokoll während Störung löschen Beweise gehen verloren Nur lesen und sichern
Vollständiges Archiv ungeprüft versenden Sensible Daten werden offengelegt Bereinigte Kopie erstellen
Einzelne Meldung ohne Funktionstest bewerten Hypothese bleibt unbestätigt Gezielten Test durchführen
33. Checkliste zur Protokollanalyse 
[ ] Störung und auslösende Aktion eindeutig beschrieben
[ ] Server und Dienst bestätigt
[ ] Beginn und Ende des Fehlers bestimmt
[ ] Zeitzonen aller beteiligten Systeme geprüft
[ ] Zeitfenster einige Minuten erweitert
[ ] Betriebssystemprotokoll geprüft
[ ] Dienst- beziehungsweise Anwendungsprotokoll geprüft
[ ] Ereignisanbieter oder Prozess gefiltert
[ ] Ereignis-ID und Fehlercode erfasst
[ ] Meldungen unmittelbar vor dem Fehler gelesen
[ ] Meldungen unmittelbar nach dem Fehler gelesen
[ ] Abhängige Systeme geprüft
[ ] Ursache und Folge getrennt
[ ] Prozessneustart und PID-Wechsel berücksichtigt
[ ] Protokollaufbewahrung und Rotation geprüft
[ ] Fehlende Meldungen nicht vorschnell bewertet
[ ] Relevante Protokolle gesichert
[ ] Sensible Inhalte vor Weitergabe entfernt
[ ] Hypothese durch einen technischen Test geprüft
[ ] Ergebnis und nächster Schritt dokumentiert

Bewertung des Ergebnisses

Ergebnis Nächster Schritt
Dienst konnte nicht gestartet werden Exitcode, Konto, Pfad und Konfiguration prüfen
Dienst wurde unerwartet beendet Absturzbericht, Ressourcen und Wiederherstellungsaktion prüfen
Abhängigkeit ist nicht erreichbar DNS-, Netzwerk-, Port- und Backendprüfung durchführen
Zugriff wurde verweigert Dienstkonto, Datei- und Systemberechtigungen prüfen
Speicher- oder Datenträgerfehler vorhanden Ressourcen und Dateisystem untersuchen
TLS- oder Zertifikatsfehler vorhanden Zertifikat, Name, Zeit und Vertrauenskette prüfen
Protokoll zeigt Zeitüberschreitung Zielsystem, Last, Netzwerk und Timeoutursache prüfen
Mehrere Systeme zeigen dieselbe Ereigniskette Gemeinsame Ursache priorisiert untersuchen
Keine Meldung gefunden Zeitfenster, Quelle, Aufbewahrung und Logziel prüfen
Protokoll liefert nur einen Folgefehler Zeitlich frühere Komponente untersuchen

Merksatz

Ein Protokolleintrag ist ein Beweis für eine aufgezeichnete Beobachtung. Erst Zeitfolge, Systemzusammenhang und ein bestätigender Test machen daraus einen belastbaren Ursachenhinweis.

Weiterführende Quellen

4. Server- und Dienstfehler systematisch analysieren

4.7 Dienststartfehler analysieren

Ein Dienststartfehler liegt vor, wenn ein Dienst nicht gestartet werden kann, im Startvorgang hängen bleibt oder unmittelbar nach dem Start wieder beendet wird.

Grundsatz:
Nicht mehrfach auf „Starten“ klicken. Zuerst Status, Exitcode, Protokolle und Startkonfiguration sichern, damit die ursprüngliche Fehlerursache nicht durch Folgeereignisse verdeckt wird.

Ziele dieser Seite

Nach dieser Seite sollst du:

1. Arten von Dienststartfehlern unterscheiden
Fehlerbild Beschreibung Mögliche Ursache
Dienst nicht gefunden Dienstverwaltung kennt den Namen nicht Falscher Name, Dienst nicht installiert oder andere Umgebung
Dienst deaktiviert Start wird durch Konfiguration verhindert Bewusste Deaktivierung oder fehlerhafte Änderung
Dienst maskiert systemd blockiert den Start vollständig Administrativer Schutz oder fehlerhafte Maskierung
Programmdatei fehlt Angegebene ausführbare Datei ist nicht vorhanden Unvollständiges Update, Löschung oder falscher Pfad
Zugriff verweigert Dienst darf Programm, Datei oder Ressource nicht verwenden Konto- oder Berechtigungsfehler
Abhängigkeit fehlt Benötigter Dienst oder Backend ist nicht verfügbar Dienst-, DNS-, Netzwerk- oder Speicherfehler
Start dauert zu lange Dienst meldet nicht rechtzeitig Betriebsbereitschaft Blockierte Initialisierung oder langsames Backend
Prozess beendet sich sofort Programm startet und bricht unmittelbar ab Konfiguration, Portkonflikt oder fehlende Ressource
Prozess stürzt ab Unbehandelte Ausnahme oder schwerer Laufzeitfehler Softwarefehler, Bibliothek oder inkompatible Version
Neustartschleife Dienst wird automatisch fortlaufend neu gestartet Wiederherstellungsregel und unveränderte Fehlerursache
Startgrenze erreicht Dienstverwaltung unterbindet weitere Versuche Zu viele Fehlstarts innerhalb kurzer Zeit
Dienst läuft, ist aber nicht bereit Prozess existiert, Initialisierung ist unvollständig Backend, Migration, Cache oder Healthcheck
2. Mindestinformationen vor einem neuen Startversuch sichern 
[ ] Datum, Uhrzeit und Zeitzone
[ ] Server und Betriebssystem
[ ] Interner Dienstname beziehungsweise launchd-Label
[ ] Aktueller Dienststatus
[ ] Startart beziehungsweise Aktivierungszustand
[ ] Prozess-ID, falls vorhanden
[ ] Letzter Exitcode
[ ] Dienstspezifischer Exitcode
[ ] Programmpfad und Startparameter
[ ] Dienstkonto
[ ] Formale Abhängigkeiten
[ ] Wiederherstellungs- und Neustartregeln
[ ] Relevante Systemprotokolle
[ ] Relevante Anwendungsprotokolle
[ ] Letzte Konfigurations- oder Softwareänderung

Erst nach dieser Sicherung sollte ein weiterer kontrollierter Startversuch durchgeführt werden.

3. Allgemeiner Diagnoseweg bei Startfehlern 
Dienst vorhanden?
  ↓
Aktiviert und nicht blockiert?
  ↓
Programmpfad vorhanden?
  ↓
Startkonfiguration syntaktisch gültig?
  ↓
Dienstkonto gültig?
  ↓
Datei- und Verzeichnisrechte ausreichend?
  ↓
Abhängigkeiten verfügbar?
  ↓
Port und andere Ressourcen verfügbar?
  ↓
Prozess startet?
  ↓
Prozess bleibt aktiv?
  ↓
Dienst meldet Betriebsbereitschaft?
  ↓
Anwendungstest erfolgreich?

Empfohlene Reihenfolge:

  1. Exakten Dienstnamen bestätigen.
  2. Aktuellen Status erfassen.
  3. Exitcode und Protokolle sichern.
  4. Startart und Blockierungen prüfen.
  5. Programmpfad und Argumente kontrollieren.
  6. Dienstkonto und Berechtigungen prüfen.
  7. Abhängigkeiten testen.
  8. Portkonflikte und Ressourcen prüfen.
  9. Konfiguration mit Herstellerwerkzeug validieren.
  10. Einen einzelnen kontrollierten Startversuch durchführen.
  11. Protokolle während dieses Versuchs beobachten.
  12. Ergebnis dokumentieren und erneut bewerten.
4. Windows-Dienststatus und Exitcodes erfassen

Grundlegenden Dienststatus anzeigen:

[RO] Get-Service -Name "<DIENSTNAME>"

Erweiterte Dienstinformationen anzeigen:

[RO] Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'" |
    Select-Object Name,
                  DisplayName,
                  State,
                  Status,
                  StartMode,
                  StartName,
                  ProcessId,
                  ExitCode,
                  ServiceSpecificExitCode

Status mit sc.exe prüfen:

[RO] sc.exe queryex "<DIENSTNAME>"

Wichtige Angaben:

Angabe Bedeutung
STATE Aktueller Dienstzustand
WIN32_EXIT_CODE Windows- beziehungsweise Dienstausgangscode
SERVICE_EXIT_CODE Dienstspezifischer Ausgangscode
CHECKPOINT Fortschrittswert bei längeren Zustandswechseln
WAIT_HINT Vom Dienst geschätzte Wartezeit
PID Aktuelle Prozess-ID, sofern vorhanden

Ein Exitcode 0 ist nur dann aussagekräftig, wenn der Dienst regulär beendet wurde. Ein Dienst kann trotzdem seine vorgesehene Funktion nicht bereitgestellt haben.

5. Windows-Startkonfiguration prüfen

Konfiguration des Dienstes anzeigen:

[RO][SENS] sc.exe qc "<DIENSTNAME>"

Konfiguration über CIM anzeigen:

[RO][SENS] Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'" |
    Select-Object Name,
                  StartMode,
                  StartName,
                  PathName,
                  ServiceType,
                  DesktopInteract

Zu prüfen sind:

Feld Prüffrage
BINARY_PATH_NAME beziehungsweise PathName Ist der Programmpfad korrekt?
Startparameter Sind Argumente vollständig und korrekt maskiert?
SERVICE_START_NAME beziehungsweise StartName Wird das vorgesehene Dienstkonto verwendet?
START_TYPE beziehungsweise StartMode Ist der Dienst deaktiviert?
DEPENDENCIES Sind alle formalen Abhängigkeiten vorhanden?
TYPE beziehungsweise ServiceType Passt die Dienstart zur Anwendung?

Wichtig bei Programmpfaden:

6. Windows-Programmpfad kontrolliert prüfen

Da PathName auch Argumente enthalten kann, darf die gesamte Zeichenfolge nicht ungeprüft an Test-Path übergeben werden.

Konfigurierte Zeichenfolge zunächst nur anzeigen:

[RO][SENS] Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'" |
    Select-Object Name, PathName

Anschließend wird der tatsächliche ausführbare Pfad aus der Ausgabe ermittelt und separat geprüft:

[RO][FILE] Test-Path -LiteralPath "<AUSFÜHRBARE_DATEI>"

Dateiinformationen anzeigen:

[RO][FILE][SENS] Get-Item -LiteralPath "<AUSFÜHRBARE_DATEI>" |
    Select-Object FullName, Length, CreationTime, LastWriteTime, VersionInfo

Berechtigungen anzeigen:

[RO][FILE][SENS] Get-Acl -LiteralPath "<AUSFÜHRBARE_DATEI>" |
    Format-List

Zusätzlich prüfen:

7. Windows-Dienstkonto und Anmelderechte prüfen

Dienstkonto anzeigen:

[RO] Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'" |
    Select-Object Name, StartName, State, StartMode

Mögliche Kontotypen:

Zu prüfen:

Ein manueller Programmstart als Administrator beweist nicht, dass das Programm unter dem tatsächlichen Dienstkonto funktioniert.

8. Typische Windows-Startfehler einordnen
Fehler Typische Bedeutung Prüfrichtung
Fehler 2 Angegebene Datei wurde nicht gefunden Programmpfad, Bibliothek oder Konfigurationspfad
Fehler 5 Zugriff verweigert Konto, Rechte oder Sicherheitssoftware
Fehler 1068 Abhängigkeitsdienst oder Abhängigkeitsgruppe konnte nicht gestartet werden Formale Abhängigkeiten
Fehler 1069 Anmeldung des Dienstkontos fehlgeschlagen Konto, Kennwort und Anmelderecht
Fehler 1053 Dienst antwortete nicht rechtzeitig auf Start- oder Steuerungsanforderung Initialisierung, Timeout, Programmfehler
Fehler 1067 Prozess wurde unerwartet beendet Anwendungsprotokoll, Konfiguration oder Absturz
Fehler 1079 Konto stimmt nicht mit anderen Diensten im gemeinsamen Prozess überein Dienstkonto und gemeinsam verwendeter Prozess
Fehler 193 Keine gültige Win32-Anwendung Architektur, Dateityp oder fehlerhafte Programmdatei

Die vollständige Fehlermeldung, das betroffene Produkt und die Windows-Version müssen immer mit dokumentiert werden. Die Tabelle ist eine Eingrenzungshilfe, kein Ersatz für die konkrete Herstellerdiagnose.

9. Windows-Ereignisse eines Startversuchs auswerten

Service-Control-Manager-Ereignisse der letzten Stunde:

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName      = "System"
    ProviderName = "Service Control Manager"
    StartTime    = (Get-Date).AddHours(-1)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  Message

Typische startbezogene Ereignisse filtern:

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName      = "System"
    ProviderName = "Service Control Manager"
    Id           = 7000, 7001, 7009, 7011, 7023, 7024, 7031, 7034
    StartTime    = (Get-Date).AddHours(-24)
} |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

System- und Anwendungsereignisse im festen Zeitfenster verbinden:

[RO][SENS] $startTime = Get-Date "2026-07-31 09:10:00"
$endTime   = Get-Date "2026-07-31 09:20:00"

Get-WinEvent -FilterHashtable @{
    LogName   = "System", "Application"
    StartTime = $startTime
    EndTime   = $endTime
} |
    Sort-Object TimeCreated |
    Select-Object TimeCreated,
                  LogName,
                  ProviderName,
                  Id,
                  LevelDisplayName,
                  Message
10. Windows-Wiederherstellungsaktionen prüfen

Ein Dienst kann nach einem Fehlstart oder Absturz automatisch neu gestartet werden.

Konfigurierte Fehleraktionen anzeigen:

[RO] sc.exe qfailure "<DIENSTNAME>"

Zusätzlichen Fehleraktionsstatus anzeigen:

[RO] sc.exe qfailureflag "<DIENSTNAME>"

Mögliche Aktionen:

Prüffragen:

Wiederherstellungsregeln dürfen nicht ungeprüft verändert werden. Sie können die Verfügbarkeit und das Verhalten bei Abstürzen erheblich beeinflussen.

11. systemd-Status und Startursache unter Linux prüfen

Ausführlichen Status anzeigen:

[RO][SENS][PRIV] sudo systemctl status "<DIENST>" --no-pager

Wichtige Zustände strukturiert anzeigen:

[RO] systemctl show "<DIENST>" \
  --property=LoadState,ActiveState,SubState,UnitFileState,Result,MainPID,ExecMainCode,ExecMainStatus,StatusErrno,NRestarts

Prüfen, ob die Unit aktiviert ist:

[RO] systemctl is-enabled "<DIENST>"

Prüfen, ob sie fehlgeschlagen ist:

[RO] systemctl is-failed "<DIENST>"

Alle fehlgeschlagenen Units anzeigen:

[RO] systemctl --failed --no-pager

Wichtige Angaben:

Eigenschaft Bedeutung
LoadState Wurde die Unit korrekt geladen?
ActiveState Übergeordneter Aktivzustand
SubState Detaillierter Unterzustand
Result Ergebnis des letzten Start- oder Laufvorgangs
MainPID PID des Hauptprozesses
ExecMainCode Art der Prozessbeendigung
ExecMainStatus Exitcode oder Signalnummer
StatusErrno Gemeldeter Fehlerwert, sofern vorhanden
NRestarts Anzahl automatischer Neustarts
12. systemd-Ergebniswerte interpretieren

Mögliche Result-Werte können unter anderem sein:

Ergebnis Typische Bedeutung
success Vorgang wurde aus Sicht von systemd erfolgreich beendet
exit-code Prozess beendete sich mit nicht als erfolgreich bewertetem Exitcode
signal Prozess wurde durch ein Signal beendet
core-dump Prozess wurde durch Signal beendet und erzeugte einen Core Dump
timeout Start-, Stopp- oder Laufzeitgrenze wurde überschritten
watchdog Watchdog-Reaktion blieb aus
start-limit-hit Zu viele Startversuche in kurzer Zeit
resources Benötigte Systemressource konnte nicht bereitgestellt werden
protocol Dienst erfüllte das erwartete Startprotokoll nicht
dependency Eine benötigte Unit schlug fehl
exec-condition Eine konfigurierte Startbedingung verhinderte den Start

Beendigungsart:

ExecMainCode Grundbedeutung
exited Prozess beendete sich über einen Exitcode
killed Prozess wurde durch ein Signal beendet
dumped Prozess wurde durch Signal beendet und erzeugte möglicherweise einen Dump

Die konkrete Bedeutung von ExecMainStatus hängt davon ab, ob der Prozess regulär beendet oder durch ein Signal beendet wurde. Zusätzlich muss die Dokumentation des Programms geprüft werden.

13. systemd-Unit und wirksame Startparameter prüfen

Wirksame Unit einschließlich Drop-ins anzeigen:

[RO][FILE][SENS] systemctl cat "<DIENST>"

Wichtige Startparameter strukturiert anzeigen:

[RO][SENS] systemctl show "<DIENST>" \
  --property=Type,User,Group,ExecStart,ExecStartPre,ExecStartPost,WorkingDirectory,EnvironmentFiles,FragmentPath,DropInPaths

Unit-Datei formal prüfen:

[RO][FILE] systemd-analyze verify "<UNIT-DATEI>"

Zu prüfen sind:

systemd-analyze verify benötigt den tatsächlichen Pfad einer Unit-Datei. Der Pfad sollte mit systemctl show <DIENST> --property=FragmentPath ermittelt werden.

14. Linux-Programmpfad und Berechtigungen prüfen

Konfigurierten Startbefehl anzeigen:

[RO][SENS] systemctl show "<DIENST>" --property=ExecStart

Datei des bekannten Programmpfads prüfen:

[RO][FILE] stat "<AUSFÜHRBARE_DATEI>"

Dateityp und Architektur prüfen:

[RO][FILE] file "<AUSFÜHRBARE_DATEI>"

Berechtigungen aller Pfadbestandteile anzeigen:

[RO][FILE] namei -l "<AUSFÜHRBARE_DATEI>"

Dynamische Bibliotheksabhängigkeiten eines geeigneten dynamischen ELF-Programms anzeigen:

[RO][FILE][SENS] ldd "<AUSFÜHRBARE_DATEI>"

Wichtiger Sicherheitshinweis:

ldd sollte nicht ungeprüft auf nicht vertrauenswürdige ausführbare Dateien angewendet werden. Abhängig von System und Binärdatei kann die Auswertung Sicherheitsrisiken besitzen.

Alternativ kann bei ELF-Dateien zunächst statisch geprüft werden:

[RO][FILE] readelf -d "<AUSFÜHRBARE_DATEI>"

Zu prüfen:

15. Linux-Dienstkonto und Dienstkontext prüfen

Konfiguriertes Konto anzeigen:

[RO] systemctl show "<DIENST>" --property=User,Group,DynamicUser

Benutzerkonto prüfen:

[RO] getent passwd "<DIENSTBENUTZER>"

Gruppenmitgliedschaften anzeigen:

[RO] id "<DIENSTBENUTZER>"

Arbeitsverzeichnis prüfen:

[RO] systemctl show "<DIENST>" --property=WorkingDirectory

Referenzierte Umgebungsdateien anzeigen:

[RO][SENS] systemctl show "<DIENST>" --property=EnvironmentFiles

Zu prüfen:

Das Starten des Programms als root ist kein gültiger Nachweis für die Funktion unter dem tatsächlichen Dienstkonto.

16. systemd-Protokolle eines Startfehlers auswerten

Protokolle des aktuellen Systemstarts:

[RO][SENS][PRIV] sudo journalctl \
  -b \
  -u "<DIENST>" \
  --no-pager

Letzte 100 Einträge:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  -n 100 \
  --output=short-iso \
  --no-pager

Fehler und schwerwiegendere Meldungen:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  -p err \
  --since "1 hour ago" \
  --no-pager

Dienst- und Systemmeldungen im selben Zeitfenster:

[RO][SENS][PRIV] sudo journalctl \
  --since "2026-07-31 09:10:00" \
  --until "2026-07-31 09:20:00" \
  --output=short-iso \
  --no-pager

Kernelmeldungen berücksichtigen:

[RO][SENS][PRIV] sudo journalctl \
  -k \
  -b \
  -p warning \
  --no-pager
17. systemd-Neustartschleife und Startbegrenzung erkennen

Neustartregeln anzeigen:

[RO] systemctl show "<DIENST>" \
  --property=Restart,RestartUSec,NRestarts

Startbegrenzung anzeigen:

[RO] systemctl show "<DIENST>" \
  --property=StartLimitIntervalUSec,StartLimitBurst,Result

Anzeichen:

Fehlerstatus erst nach der Beweissicherung zurücksetzen:

[CHANGE][PRIV] sudo systemctl reset-failed "<DIENST>"

reset-failed:

Dieser Befehl darf deshalb erst nach Dokumentation von Result, NRestarts, Status und Journal verwendet werden.

18. systemd-Diensttypen als mögliche Fehlerursache prüfen
Type= Erwartetes Verhalten
simple Gestarteter Prozess gilt unmittelbar als Hauptprozess
exec Start gilt nach erfolgreichem Ausführen des Programms als erfolgt
forking Programm erzeugt Hintergrundprozess; häufig mit PID-Datei
oneshot Prozess führt Aufgabe aus und beendet sich wieder
notify Dienst meldet systemd ausdrücklich Betriebsbereitschaft
dbus Bereitschaft hängt von einem D-Bus-Namen ab
idle Ausführung wird verzögert, bis andere Jobs abgearbeitet sind

Mögliche Fehlkonfigurationen:

Der korrekte Diensttyp muss anhand der Programmdokumentation und des tatsächlichen Prozessverhaltens bestimmt werden.

19. launchd-Status und letzten Exitstatus unter macOS prüfen

Systemweiten Dienst prüfen:

[RO] launchctl print "system/<LABEL>"

Benutzerbezogenen Dienst prüfen:

[RO] launchctl print "gui/$(id -u)/<LABEL>"

Relevante Angaben können sein:

state
pid
runs
last exit code
program
arguments
reason
path

Deaktivierungsüberschreibungen prüfen:

[RO] launchctl print-disabled system

GUI-Domain des aktuellen Benutzers prüfen:

[RO] launchctl print-disabled "gui/$(id -u)"

Wichtig:

20. launchd-Konfiguration unter macOS prüfen

Bekannte systemweite plist anzeigen:

[RO][FILE][SENS] plutil -p "/Library/LaunchDaemons/<LABEL>.plist"

Formale plist-Prüfung durchführen:

[RO][FILE] plutil -lint "/Library/LaunchDaemons/<LABEL>.plist"

Benutzerbezogene plist prüfen:

[RO][FILE][SENS] plutil -p "$HOME/Library/LaunchAgents/<LABEL>.plist"

Zu prüfen sind:

Schlüssel Prüffrage
Label Stimmt das Label mit dem verwendeten Dienstziel überein?
Program Existiert das Programm?
ProgramArguments Sind Programm und Argumente korrekt angeordnet?
WorkingDirectory Existiert das Arbeitsverzeichnis?
UserName Existiert das Konto und besitzt es die nötigen Rechte?
GroupName Existiert die Gruppe?
KeepAlive Wird ein fehlerhafter Prozess wiederholt gestartet?
RunAtLoad Soll der Job beim Laden gestartet werden?
StandardOutPath Kann die Datei beziehungsweise das Verzeichnis verwendet werden?
StandardErrorPath Kann die Fehlerausgabe geschrieben werden?
EnvironmentVariables Sind erforderliche Variablen vorhanden?

ProgramArguments ist ein Array. Das erste Element bezeichnet üblicherweise das auszuführende Programm, wenn nicht zusätzlich Program angegeben wurde.

21. macOS-Programmpfad und Berechtigungen prüfen

Programmdatei prüfen:

[RO][FILE] stat "<AUSFÜHRBARE_DATEI>"

Dateityp und Architektur anzeigen:

[RO][FILE] file "<AUSFÜHRBARE_DATEI>"

Berechtigungen und erweiterte Zugriffslisten anzeigen:

[RO][FILE][SENS] ls -lde "<AUSFÜHRBARE_DATEI>"

Code-Signatur anzeigen und prüfen:

[RO][FILE][SENS] codesign \
  --verify \
  --deep \
  --strict \
  --verbose=2 \
  "<AUSFÜHRBARE_DATEI>"

Gatekeeper-Bewertung für einen geeigneten Anwendungstyp prüfen:

[RO][FILE][SENS] spctl \
  --assess \
  --type execute \
  --verbose=4 \
  "<AUSFÜHRBARE_DATEI>"

Hinweise:

22. macOS-Protokolle eines Startfehlers auswerten

Nach Prozess suchen:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate 'process == "<PROZESS>"' \
  --style compact \
  --no-pager

Nach launchd- und Prozessmeldungen suchen:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate 'process == "launchd" OR process == "<PROZESS>"' \
  --style compact \
  --no-pager

Fehler und Faults anzeigen:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate '(process == "launchd" OR process == "<PROZESS>") AND (messageType == error OR messageType == fault)' \
  --style compact \
  --no-pager

Live-Beobachtung während eines kontrollierten Startversuchs:

[TEST][SENS][PRIV] sudo log stream \
  --timeout 5m \
  --predicate 'process == "launchd" OR process == "<PROZESS>"' \
  --style compact
23. launchctl-Fehlercode unter macOS übersetzen

Wenn ein launchctl-Befehl einen numerischen Fehlercode liefert, kann dieser mit launchctl error lesbarer dargestellt werden.

Automatische Einordnung versuchen:

[RO] launchctl error <FEHLERCODE>

POSIX-Fehlerbereich angeben:

[RO] launchctl error posix <FEHLERCODE>

Mach-Fehlerbereich angeben:

[RO] launchctl error mach <FEHLERCODE>

Bootstrap-Fehlerbereich angeben:

[RO] launchctl error bootstrap <FEHLERCODE>

Die übersetzte Meldung beschreibt den technischen Fehlerbereich. Die konkrete Ursache muss weiterhin anhand von plist, Programmpfad, Berechtigungen und Protokollen bestimmt werden.

24. Kontrollierten Startversuch durchführen

Ein Startversuch verändert den Dienstzustand und kann Folgeprozesse, Netzwerkverbindungen oder automatische Wiederherstellungsaktionen auslösen.

Betriebssystem Startbefehl
Windows [CHANGE][PRIV] Start-Service -Name "<DIENSTNAME>"
Linux [CHANGE][PRIV] sudo systemctl start "<DIENST>"
macOS systemweit [CHANGE][PRIV] sudo launchctl kickstart "system/<LABEL>"
macOS Benutzerkontext [CHANGE] launchctl kickstart "gui/$(id -u)/<LABEL>"

macOS – PID bei erfolgreichem kickstart ausgeben:

[CHANGE][PRIV] sudo launchctl kickstart \
  -p \
  "system/<LABEL>"

Ablauf:

1. Aktuellen Status und Protokolle sichern
2. Live-Protokollansicht vorbereiten
3. Genaue Startzeit notieren
4. Genau einen Startversuch ausführen
5. Rückgabemeldung vollständig erfassen
6. Dienststatus sofort prüfen
7. Prozess-ID und Laufzeit prüfen
8. Listener prüfen
9. Neue Protokollmeldungen sichern
10. Anwendungstest durchführen
11. Keine weiteren Versuche ohne neue Erkenntnis starten
25. Manuellen Programmstart nur kontrolliert verwenden

Ein direkter Programmstart kann zusätzliche Fehlermeldungen auf der Konsole sichtbar machen. Er ist aber nicht automatisch sicher oder mit dem Dienststart gleichwertig.

Vorher prüfen:

Der manuelle Start kann sich unterscheiden durch:

Eigenschaft Dienststart Manueller Start
Benutzerkonto Dienstkonto Aktueller Terminalbenutzer
Arbeitsverzeichnis Konfiguriert oder systemabhängig Aktuelles Verzeichnis
Umgebungsvariablen Dienstspezifisch Shell- beziehungsweise Benutzervariablen
Berechtigungen Dienstkontext Benutzer- oder Administratorkontext
Netzwerkressourcen Dienstabhängig Benutzersitzung
Sicherheitsrichtlinien Dienstmanager und Sandbox Terminalkontext
Standardausgabe Journal, Datei oder Ereignisprotokoll Terminal

Deshalb wird kein generischer Direktstartbefehl verwendet. Der korrekte Diagnosemodus muss aus der offiziellen Dokumentation der jeweiligen Anwendung stammen.

26. Häufige technische Ursachen eines sofortigen Abbruchs
27. Zeitüberschreitung beim Dienststart analysieren

Ein Timeout bedeutet zunächst, dass ein erwarteter Zustand nicht innerhalb der vorgesehenen Zeit erreicht wurde.

Mögliche Ursachen:

Prüfung:

1. Startzeit genau feststellen
2. Letzte Meldung vor dem Timeout ermitteln
3. Prozesszustand während des Wartens prüfen
4. CPU- und I/O-Verhalten beobachten
5. Netzwerkverbindungen des Prozesses prüfen
6. Abhängigkeiten direkt testen
7. Herstellerdokumentation zur Initialisierung prüfen
8. Timeout nicht erhöhen, bevor die Warteursache bekannt ist

Eine Vergrößerung des Timeouts kann einen langsamen, aber legitimen Start ermöglichen. Sie kann jedoch ebenso einen eigentlichen Fehler nur länger verbergen.

28. Portkonflikt als Startursache prüfen

Windows:

[RO] Get-NetTCPConnection `
  -State Listen `
  -LocalPort <PORT> `
  -ErrorAction SilentlyContinue |
    Select-Object LocalAddress, LocalPort, OwningProcess

Linux:

[RO][PRIV] sudo ss -lntp "sport = :<PORT>"

macOS:

[RO][PRIV] sudo lsof \
  -nP \
  -iTCP:<PORT> \
  -sTCP:LISTEN

Wenn der Port belegt ist:

  1. PID feststellen.
  2. Prozessname bestimmen.
  3. Dienstzuordnung prüfen.
  4. Bindungsadresse kontrollieren.
  5. Prüfen, ob eine alte Instanz läuft.
  6. Container- oder Proxybelegung berücksichtigen.
  7. Keinen Prozess ungeprüft beenden.
  8. Sollkonfiguration und letzte Änderungen prüfen.
29. Ressourcenmangel als Startursache prüfen
Aufgabe Windows Linux macOS
Freier Speicherplatz [RO] Get-Volume [RO] df -hT [RO] df -h
Arbeitsspeicher [RO] Get-CimInstance Win32_OperatingSystem | Select-Object TotalVisibleMemorySize,FreePhysicalMemory [RO] free -h [RO] vm_stat
Prozessübersicht [RO] Get-Process | Sort-Object WorkingSet64 -Descending [RO] top [RO] top -o mem
Dateisystemzustand [RO] Get-Volume [RO] findmnt [RO] mount
Offene Dateien des Prozesses Betriebssystemspezifische Prozesswerkzeuge [RO][PRIV] sudo lsof -p <PID> [RO][PRIV] sudo lsof -p <PID>

Mögliche Startfehler:

30. Letzte Änderungen priorisiert untersuchen

Besonders relevant sind Änderungen an:

Zeitlicher Vergleich:

Letzter erfolgreicher Start
  → Änderung
  → erster fehlgeschlagener Start

Ein zeitlicher Zusammenhang ist ein starker Hinweis, aber noch kein Beweis. Die betroffene Konfiguration oder Komponente muss technisch geprüft werden.

31. Typische Fehlinterpretationen
Fehlinterpretation Richtige Bewertung
„Der Startknopf zeigt einen Fehler, also ist Windows beziehungsweise systemd defekt.“ Die Dienstverwaltung meldet häufig nur den Fehler des gestarteten Programms
„Exitcode 0 bedeutet, der Dienst funktioniert.“ Nur die gemeldete Beendigung wurde als erfolgreich bewertet
„Der Prozess war kurz sichtbar, also startete der Dienst erfolgreich.“ Er kann während der Initialisierung abgebrochen sein
„Manueller Start als Administrator funktioniert, also stimmen die Dienstrechte.“ Der Dienst verwendet einen anderen Kontext
„Mehr Startversuche erhöhen die Chance auf Erfolg.“ Sie können Protokolle überlagern und Startbegrenzungen auslösen
„Timeout erhöhen löst den Fehler.“ Die eigentliche Warteursache bleibt möglicherweise bestehen
„Die Konfigurationsdatei ist syntaktisch gültig, also ist sie fachlich korrekt.“ Pfade, Konten und Backends können weiterhin falsch sein
„Der Port ist frei, also muss der Dienst starten.“ Viele weitere Startvoraussetzungen bleiben ungeprüft
„Ein Neustartzähler beweist einen Softwarefehler.“ Auch fehlende Abhängigkeiten oder Rechte können Wiederholungen auslösen
„Fehlerstatus zurücksetzen repariert den Dienst.“ Nur gespeicherter Zustand und Zähler werden zurückgesetzt
32. Checkliste zur Analyse eines Dienststartfehlers 
[ ] Exakten Dienstnamen beziehungsweise Label bestätigt
[ ] Richtigen Server und richtige Umgebung bestätigt
[ ] Aktuellen Status gesichert
[ ] Exitcode und dienstspezifischen Exitcode erfasst
[ ] Relevante Protokolle vor neuem Startversuch gesichert
[ ] Startart und Deaktivierung geprüft
[ ] systemd-Maskierung beziehungsweise launchd-Override geprüft
[ ] Programmpfad und Startparameter geprüft
[ ] Programmdatei vorhanden
[ ] Dateityp und Architektur geprüft
[ ] Dienstkonto und Gruppe geprüft
[ ] Datei- und Verzeichnisrechte geprüft
[ ] Arbeitsverzeichnis geprüft
[ ] Umgebungs- und Konfigurationsdateien ermittelt
[ ] Formale Abhängigkeiten geprüft
[ ] Externe Backends geprüft
[ ] Portkonflikt ausgeschlossen
[ ] Speicherplatz und Arbeitsspeicher geprüft
[ ] Neustartregeln und Startbegrenzungen geprüft
[ ] Letzte Änderungen erfasst
[ ] Genau einen kontrollierten Startversuch durchgeführt
[ ] Prozess, PID und Laufzeit danach geprüft
[ ] Listener und Anwendungsfunktion geprüft
[ ] Ursache, Maßnahme und Ergebnis dokumentiert

Bewertung des Ergebnisses

Ergebnis Nächster Schritt
Dienst nicht vorhanden Installation, Dienstname und Zielsystem prüfen
Dienst deaktiviert oder maskiert Grund und Sollzustand vor Änderung klären
Programmdatei fehlt Installation, Update und Dateisystem untersuchen
Zugriff verweigert Dienstkonto, Rechte und Sicherheitsrichtlinien prüfen
Abhängigkeit schlägt fehl Betroffene Abhängigkeit separat analysieren
Port ist belegt Besitzenden Prozess und Konfiguration untersuchen
Konfiguration ist ungültig Fehlerstelle mit Herstellerwerkzeug bestimmen
Prozess beendet sich mit Exitcode Produktspezifische Bedeutung des Codes prüfen
Prozess wird durch Signal beendet Signalursache, Ressourcen und Absturzdiagnose prüfen
Start läuft in Timeout Letzte Initialisierungsphase und Abhängigkeiten untersuchen
Startgrenze wurde erreicht Fehlerzustand sichern und Grund der Fehlstarts beheben
Dienst startet und bleibt aktiv Listener und Anwendungstest durchführen

Merksatz

Ein Dienststartfehler ist selten mit einem weiteren Startversuch erklärt. Entscheidend ist die erste Phase, in der Sollzustand und tatsächlicher Startablauf voneinander abweichen.

Weiterführende Quellen

4. Server- und Dienstfehler systematisch analysieren

4.8 Konfigurationsfehler untersuchen

Ein Dienst kann installiert, gestartet und über den vorgesehenen Port erreichbar sein, aber aufgrund einer fehlerhaften oder veralteten Konfiguration trotzdem nicht richtig funktionieren.

Grundsatz:
Nicht irgendeine Konfigurationsdatei prüfen, sondern zuerst feststellen, welche Konfiguration der laufende Dienst tatsächlich verwendet.

Ziele dieser Seite

Nach dieser Seite sollst du:

1. Arten von Konfigurationsfehlern unterscheiden
Fehlerart Beispiel
Syntaxfehler Fehlende Klammer oder ungültiges Trennzeichen
Tippfehler Falscher Schlüsselname oder Hostname
Datentypfehler Text statt Zahl oder true statt erwarteter Zeichenfolge
Wertebereichsfehler Port außerhalb des gültigen Bereichs
Fehlender Pflichtwert Datenbankadresse nicht angegeben
Falscher Dateipfad Zertifikat oder Datenverzeichnis nicht gefunden
Falsche Berechtigung Dienstkonto kann Datei nicht lesen
Falsche Eigentümerschaft Datei gehört nicht dem vorgesehenen Konto
Überschreibung Lokales Drop-in ersetzt den erwarteten Wert
Versionskonflikt Option wird von neuer Version nicht mehr unterstützt
Formatfehler JSON, XML, YAML oder plist ist formal ungültig
Kodierungsfehler Falsche Zeichenkodierung oder Byte Order Mark
Zeilenendefehler Windows-Zeilenenden stören ein Unix-Werkzeug
Umgebungsfehler Variable ist im Terminal, aber nicht im Dienstkontext vorhanden
Geheimnisfehler Kennwort, Token oder Schlüssel fehlt beziehungsweise ist abgelaufen
Zielsystemfehler Konfiguration zeigt auf Test- statt Produktivsystem
Reihenfolgefehler Spätere Datei überschreibt eine frühere Einstellung
Neustart fehlt Datei wurde geändert, Dienst verwendet aber noch alten Zustand
Reload ungeeignet Dienst unterstützt kein dynamisches Neuladen
Konfiguration nicht eingebunden Bearbeitete Datei wird vom Dienst gar nicht geladen
2. Konfigurationsquelle und wirksame Konfiguration unterscheiden

Eine Anwendung kann Einstellungen aus mehreren Quellen beziehen:

Programmstandardwerte
  → Hauptkonfigurationsdatei
  → eingebundene Zusatzdateien
  → lokale Überschreibungen
  → Umgebungsvariablen
  → Startparameter
  → zentrale Konfigurationsverwaltung
  → zur Laufzeit gespeicherte Einstellungen

Später ausgewertete Quellen können frühere Werte überschreiben. Die genaue Priorität ist produktspezifisch.

Begriff Bedeutung
Standardwert Vom Programm verwendeter Wert ohne eigene Konfiguration
Quelldatei Datei, in der eine Einstellung gespeichert ist
Include Zusätzlich geladene Konfigurationsdatei
Drop-in Ergänzende oder überschreibende Konfiguration
Startparameter Beim Programmstart übergebener Wert
Umgebungsvariable Einstellung aus dem Prozesskontext
Wirksame Konfiguration Tatsächlich vom Dienst verwendeter Gesamtzustand
Laufzeitkonfiguration Nach dem Start möglicherweise intern veränderter Zustand

Eine korrekt aussehende Hauptdatei beweist nicht, dass ihr Wert tatsächlich wirksam ist.

3. Vor jeder Prüfung den Konfigurationspfad belegen

Der Konfigurationspfad sollte aus mindestens einer belastbaren Quelle stammen:

  1. offizielle Herstellerdokumentation,
  2. Dienststartparameter,
  3. systemd-Unit beziehungsweise launchd-plist,
  4. Windows-Dienstkonfiguration,
  5. Anwendungsausgabe zur wirksamen Konfiguration,
  6. Installations- oder Deploymentdokumentation,
  7. Containerdefinition,
  8. Protokollmeldung beim Dienststart.

Nicht ausreichend:

Zu dokumentieren:

Dienst:
Produkt und Version:
Konfigurationsquelle:
Tatsächlicher Pfad:
Weitere Includes:
Umgebungsdateien:
Startparameter:
Konfigurationspriorität:
Zeitpunkt der Prüfung:
4. Konfigurationsquelle unter Windows ermitteln

Dienstpfad und Startparameter anzeigen:

[RO][SENS] Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'" |
    Select-Object Name, StartName, PathName

Alternative mit sc.exe:

[RO][SENS] sc.exe qc "<DIENSTNAME>"

Anschließend sind zu prüfen:

Programmpfad und Argumente werden in PathName gemeinsam dargestellt. Sie müssen bei der Auswertung sorgfältig getrennt werden.

5. Konfigurationsquelle unter Linux mit systemd ermitteln

Wirksame Unit und Drop-ins anzeigen:

[RO][FILE][SENS] systemctl cat "<DIENST>"

Wichtige Pfade und Startparameter anzeigen:

[RO][SENS] systemctl show "<DIENST>" \
  --property=FragmentPath,DropInPaths,ExecStart,WorkingDirectory,EnvironmentFiles

Umgebungswerte anzeigen:

[RO][SENS] systemctl show "<DIENST>" --property=Environment

Systemweite Konfigurationsdateien eines systemd-Bestandteils zusammenführen:

[RO][FILE] systemd-analyze cat-config "<KONFIGURATIONSNAME>"

systemd-analyze cat-config ist für unterstützte Konfigurationshierarchien von systemd-Komponenten gedacht. Es ist kein universeller Parser für beliebige Anwendungen.

Zu prüfen:

6. Konfigurationsquelle unter macOS ermitteln

Systemweiten launchd-Job anzeigen:

[RO] launchctl print "system/<LABEL>"

Benutzerbezogenen Job anzeigen:

[RO] launchctl print "gui/$(id -u)/<LABEL>"

Bekannte plist lesbar anzeigen:

[RO][FILE][SENS] plutil -p "/Library/LaunchDaemons/<LABEL>.plist"

Benutzerbezogene plist anzeigen:

[RO][FILE][SENS] plutil -p "$HOME/Library/LaunchAgents/<LABEL>.plist"

Relevante plist-Schlüssel:

Program
ProgramArguments
WorkingDirectory
EnvironmentVariables
UserName
GroupName
StandardOutPath
StandardErrorPath

Zusätzlich kann eine Anwendung Einstellungen aus dem macOS-Preferences-System verwenden.

Bekannte Preferences-Domain lesend anzeigen:

[RO][SENS] defaults read "<DOMAIN>"

Einzelnen bekannten Schlüssel lesen:

[RO][SENS] defaults read "<DOMAIN>" "<SCHLÜSSEL>"

defaults read liest Preferences-Domains. Es ist kein allgemeines Werkzeug für die zuverlässige Bearbeitung beliebiger plist-Dateien.

7. Dateiexistenz und Metadaten vergleichen
Aufgabe Windows Linux macOS
Existenz prüfen [RO][FILE] Test-Path -LiteralPath "<DATEI>" [RO][FILE] test -f "<DATEI>" [RO][FILE] test -f "<DATEI>"
Metadaten anzeigen [RO][FILE] Get-Item -LiteralPath "<DATEI>" [RO][FILE] stat "<DATEI>" [RO][FILE] stat "<DATEI>"
Dateityp prüfen [RO][FILE] Get-Item -LiteralPath "<DATEI>" | Select-Object FullName,Length,Extension [RO][FILE] file "<DATEI>" [RO][FILE] file "<DATEI>"
Eigentümer und Rechte [RO][FILE][SENS] Get-Acl -LiteralPath "<DATEI>" [RO][FILE] stat -c '%U %G %A %a %n' "<DATEI>" [RO][FILE] stat -f '%Su %Sg %Sp %N' "<DATEI>"
Symbolischen Link anzeigen [RO][FILE] Get-Item -LiteralPath "<DATEI>" | Select-Object FullName,LinkType,Target [RO][FILE] readlink "<DATEI>" [RO][FILE] readlink "<DATEI>"

Zu prüfen:

Ein Änderungszeitpunkt beweist nur, dass sich Dateimetadaten oder Dateiinhalt geändert haben. Er beweist nicht, wer die fachliche Änderung vorgenommen hat.

8. Berechtigungen aller Pfadbestandteile prüfen

Ein Dienst benötigt nicht nur Rechte auf die Datei selbst. Er muss auch die übergeordneten Verzeichnisse erreichen können.

Windows – Datei und übergeordnetes Verzeichnis:

[RO][FILE][SENS] Get-Acl -LiteralPath "<DATEI>" |
    Format-List

[RO][FILE][SENS] Get-Acl -LiteralPath "<VERZEICHNIS>" |
    Format-List

Linux – vollständigen Pfad zerlegen:

[RO][FILE] namei -l "<DATEI>"

Linux – ACL anzeigen:

[RO][FILE][SENS] getfacl "<DATEI>"

getfacl ist nicht auf jeder Minimalinstallation vorhanden.

macOS – Datei und erweiterte ACL anzeigen:

[RO][FILE][SENS] ls -lde "<DATEI>"

macOS – alle Pfadbestandteile prüfen:

[RO][FILE] ls -lde "<VERZEICHNIS>" "<DATEI>"

Mögliche Fehler:

9. Hashwert einer Konfiguration erfassen

Ein kryptografischer Hashwert hilft festzustellen, ob zwei Dateien denselben Inhalt besitzen. Er zeigt nicht, welcher Inhalt fachlich richtig ist.

Betriebssystem SHA-256-Befehl
Windows [RO][FILE] Get-FileHash -Algorithm SHA256 -LiteralPath "<DATEI>"
Linux [RO][FILE] sha256sum "<DATEI>"
macOS [RO][FILE] shasum -a 256 "<DATEI>"

Mögliche Verwendung:

Wichtig:

10. Zwei Konfigurationsstände vergleichen

Windows – zeilenweiser Vergleich:

[RO][FILE][SENS] Compare-Object `
    (Get-Content -LiteralPath "<REFERENZDATEI>") `
    (Get-Content -LiteralPath "<AKTUELLE_DATEI>")

Bedeutung der Seitenindikatoren:

Indikator Bedeutung
<= Zeile befindet sich nur in der Referenz
=> Zeile befindet sich nur in der aktuellen Datei

Linux:

[RO][FILE][SENS] diff -u "<REFERENZDATEI>" "<AKTUELLE_DATEI>"

macOS:

[RO][FILE][SENS] diff -u "<REFERENZDATEI>" "<AKTUELLE_DATEI>"

Hinweise:

11. JSON-Konfiguration prüfen

Windows PowerShell:

[RO][FILE][SENS] Test-Json `
    -Json (Get-Content -LiteralPath "<DATEI>.json" -Raw)

JSON einlesen und strukturiert anzeigen:

[RO][FILE][SENS] Get-Content -LiteralPath "<DATEI>.json" -Raw |
    ConvertFrom-Json

Linux mit installiertem jq:

[RO][FILE][SENS] jq empty "<DATEI>.json"

macOS mit plutil:

[RO][FILE] plutil -lint "<DATEI>.json"

JSON lesbar ausgeben, ohne Quelldatei zu verändern:

[RO][FILE][SENS] plutil \
  -convert json \
  -o - \
  -- "<DATEI>.json"

Zu beachten:

12. XML- und plist-Konfiguration prüfen

Beliebiges XML unter Windows PowerShell einlesen:

[RO][FILE][SENS] [xml](
    Get-Content -LiteralPath "<DATEI>.xml" -Raw
)

Ein Parserfehler weist auf ungültiges XML hin. Ein erfolgreiches Einlesen beweist noch keine Gültigkeit gegenüber einem Produktschema.

Linux mit installiertem xmllint:

[RO][FILE] xmllint --noout "<DATEI>.xml"

macOS – plist-Syntax prüfen:

[RO][FILE] plutil -lint "<DATEI>.plist"

macOS – plist lesbar anzeigen:

[RO][FILE][SENS] plutil -p "<DATEI>.plist"

macOS – Typ eines bekannten plist-Schlüssels prüfen:

[RO][FILE] plutil \
  -type "<SCHLÜSSELPFAD>" \
  "<DATEI>.plist"

Zu unterscheiden:

Prüfung Aussage
XML syntaktisch lesbar Grundlegende XML-Struktur ist gültig
plist mit plutil -lint gültig Property-List-Format ist syntaktisch gültig
Schema gültig Felder und Struktur entsprechen einem definierten Schema
Fachlich gültig Werte funktionieren für das konkrete Produkt
Wirksam Anwendung verwendet diese Werte tatsächlich
13. YAML-, INI- und proprietäre Formate prüfen

Für YAML, INI und herstellerspezifische Formate gibt es kein einzelnes betriebssystemübergreifendes Standardwerkzeug, das gleichzeitig Syntax und fachliche Gültigkeit zuverlässig prüft.

Geeignete Reihenfolge:

  1. offizielles Validierungswerkzeug des Produkts verwenden,
  2. produktspezifischen Testmodus verwenden,
  3. unterstütztes Schema verwenden,
  4. Parser nur aus einer vertrauenswürdigen Quelle verwenden,
  5. Ausgabe mit der verwendeten Produktversion dokumentieren.

Typische YAML-Fehler:

Typische INI-Fehler:

Keine beliebigen Online-Validatoren für produktive Konfigurationen verwenden. Dateien können interne Adressen, Konten, Tokens oder andere Geheimnisse enthalten.

14. systemd-Unit-Dateien und Überschreibungen prüfen

Wirksame Unit anzeigen:

[RO][FILE][SENS] systemctl cat "<DIENST>"

Unit formal prüfen:

[RO][FILE] systemd-analyze verify "<UNIT-DATEI>"

Lokale Abweichungen von ausgelieferten Unit-Dateien anzeigen:

[RO][FILE][SENS] systemd-delta

Nur Abweichungen für systemd-Systemkonfigurationen anzeigen:

[RO][FILE][SENS] systemd-delta --type=overridden,extended

Mögliche Kategorien von systemd-delta:

Kategorie Bedeutung
overridden Ursprüngliche Datei wurde vollständig überschrieben
extended Drop-in ergänzt oder verändert Einstellungen
masked Unit ist maskiert
equivalent Dateien sind inhaltlich gleichwertig
redirected Datei verweist auf ein anderes Ziel

Besonders prüfen:

15. launchd-plist unter macOS prüfen

Syntax prüfen:

[RO][FILE] plutil -lint "/Library/LaunchDaemons/<LABEL>.plist"

Struktur lesbar anzeigen:

[RO][FILE][SENS] plutil -p "/Library/LaunchDaemons/<LABEL>.plist"

Label gezielt auslesen:

[RO][FILE] plutil \
  -extract Label raw \
  "/Library/LaunchDaemons/<LABEL>.plist"

Programmpfad gezielt auslesen:

[RO][FILE][SENS] plutil \
  -extract Program raw \
  "/Library/LaunchDaemons/<LABEL>.plist"

Falls kein Program-Schlüssel vorhanden ist, kann der Programmpfad im ersten Element von ProgramArguments stehen.

Erstes Argument auslesen:

[RO][FILE][SENS] plutil \
  -extract ProgramArguments.0 raw \
  "/Library/LaunchDaemons/<LABEL>.plist"

Zu prüfen:

16. Umgebungsvariablen als Fehlerquelle untersuchen

Eine Variable kann in der interaktiven Shell vorhanden sein, aber im Dienstkontext fehlen.

Typische verwendete Variablen:

PATH
HOME
TEMP
TMP
LANG
LC_ALL
HTTP_PROXY
HTTPS_PROXY
NO_PROXY
DATABASE_URL
CONFIG_PATH
CERT_PATH

Windows – Umgebungsvariablen der aktuellen Sitzung:

[RO][SENS] Get-ChildItem Env:

Windows – maschinenweite Variable lesen:

[RO][SENS] [Environment]::GetEnvironmentVariable(
    "<VARIABLE>",
    "Machine"
)

Linux – für systemd konfigurierte Dienstvariablen anzeigen:

[RO][SENS] systemctl show "<DIENST>" \
  --property=Environment,EnvironmentFiles

macOS – launchd-Job und plist prüfen:

[RO][SENS] launchctl print "system/<LABEL>"

[RO][FILE][SENS] plutil -p "/Library/LaunchDaemons/<LABEL>.plist"

Wichtig:

Die vollständige Umgebung eines produktiven Prozesses darf nicht ungeprüft ausgegeben oder weitergegeben werden.

17. Relative Pfade und Arbeitsverzeichnis prüfen

Folgende Konfiguration kann problematisch sein:

config/application.conf
certificates/server.crt
logs/application.log
./data

Relative Pfade werden vom Arbeitsverzeichnis des Prozesses aus aufgelöst. Dieses kann beim Dienststart anders sein als beim manuellen Start.

Windows – Dienstpfad anzeigen:

[RO][SENS] Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'" |
    Select-Object Name, PathName

Linux – Arbeitsverzeichnis anzeigen:

[RO] systemctl show "<DIENST>" --property=WorkingDirectory

macOS – plist prüfen:

[RO][FILE][SENS] plutil -p "/Library/LaunchDaemons/<LABEL>.plist"

Prüffragen:

Für Serverdienste sind eindeutig dokumentierte absolute Pfade meist leichter nachvollziehbar. Ob sie unterstützt werden, entscheidet jedoch die Produktkonfiguration.

18. Zeichenkodierung und Zeilenenden prüfen

Windows – Anfangsbytes einer Datei anzeigen:

[RO][FILE] Format-Hex -LiteralPath "<DATEI>" |
    Select-Object -First 5

Linux – Dateityp und mögliche Kodierungshinweise:

[RO][FILE] file "<DATEI>"

macOS:

[RO][FILE] file "<DATEI>"

Typische Probleme:

Unsichtbare Zeichen unter Linux oder macOS darstellen:

[RO][FILE][SENS] sed -n 'l' "<DATEI>"

Eine Konvertierung verändert die Datei und darf erst nach Sicherung, Freigabe und Kenntnis des erwarteten Formats durchgeführt werden.

19. Include-Dateien und Konfigurationshierarchie prüfen

Eine Hauptdatei kann weitere Dateien laden:

Hauptdatei
  → conf.d/*.conf
  → lokale Überschreibung
  → geheime Umgebungsdatei
  → automatisch generierte Datei

Zu prüfen:

Die Lade- und Überschreibungsreihenfolge muss aus der Dokumentation des konkreten Produkts entnommen werden.

20. Versionskompatibilität der Konfiguration prüfen

Nach einem Update können Einstellungen:

Zu dokumentieren:

Vorherige Produktversion:
Aktuelle Produktversion:
Version der Konfigurationsvorlage:
Datum der letzten Konfigurationsänderung:
Migrationshinweise gelesen:
Veraltete Optionen:
Neue Pflichtwerte:
Geänderte Standardwerte:

Prüfquellen:

  1. offizielle Versionshinweise,
  2. Upgrade- oder Migrationsanleitung,
  3. Beispielkonfiguration derselben Version,
  4. produktspezifischer Konfigurationstest,
  5. Startprotokoll mit Warnungen zu veralteten Optionen.

Eine Beispieldatei aus einer neueren oder älteren Version darf nicht ungeprüft als Referenz verwendet werden.

21. Secrets und Zugangsdaten sicher behandeln

Konfigurationsdateien können enthalten:

Regeln:

[ ] Keine vollständige Geheimdatei in ein Ticket kopieren
[ ] Keine Secrets in Terminalbefehle mit Protokollierung einsetzen
[ ] Keine produktive Konfiguration in Online-Validatoren hochladen
[ ] Keine privaten Schlüssel mit Vergleichsausgaben veröffentlichen
[ ] Nur bereinigte Kopien weitergeben
[ ] Originaldatei geschützt aufbewahren
[ ] Dateirechte vor und nach einer Maßnahme prüfen
[ ] Kompromittierte Geheimnisse nicht nur zurückändern, sondern rotieren

Unsichere Darstellung:

DATABASE_URL=postgres://admin:Kennwort@db-server/database

Bereinigte Darstellung:

DATABASE_URL=postgres://<BENUTZER>:<ENTFERNT>@<DB-SERVER>/<DATENBANK>
22. Containerkonfiguration berücksichtigen

Bei Containern können Einstellungen stammen aus:

Prüffragen:

Eine Änderung an einer Hostdatei ist nur wirksam, wenn genau diese Datei in den Container eingebunden und von der Anwendung verwendet wird.

23. Konfiguration vor einer Änderung beweissicher erfassen

Mindestens erfassen:

Information Zweck
Vollständiger Pfad Eindeutige Dateiidentifikation
Dateigröße Plausibilitätsprüfung
Änderungszeit Zeitlicher Zusammenhang
Eigentümer und Rechte Zugriffskontrolle
SHA-256-Hash Inhaltsidentifikation
Produktversion Kompatibilitätsprüfung
Dienststartparameter Nachweis der Verwendung
Include-Dateien Vollständige Konfigurationskette
Wirksame Werte Tatsächlicher Zustand
Geheimnisstatus Schutzbedarf
Sicherungspfad Rückfallmöglichkeit

Dokumentationsvorlage:

Dienst:
Produktversion:
Konfigurationsdatei:
Weitere Konfigurationsquellen:
Eigentümer:
Berechtigungen:
Änderungszeit:
SHA-256:
Wirksame Konfiguration geprüft:
Syntaxprüfung:
Herstellervalidierung:
Auffälliger Wert:
Letzte bekannte funktionierende Version:
Geplante Änderung:
Rückfallmöglichkeit:
24. Kontrollierter Änderungsablauf

Eine Konfigurationsänderung besteht nicht nur aus dem Bearbeiten einer Datei.

1. Ursache und Sollwert bestimmen
2. Produktversion und Dokumentation prüfen
3. Originalzustand dokumentieren
4. Geschützte Sicherung erstellen
5. Genau eine fachliche Änderung durchführen
6. Syntax validieren
7. Produktspezifischen Konfigurationstest ausführen
8. Unterschied zur Ausgangsversion prüfen
9. Eigentümer und Berechtigungen kontrollieren
10. Reload oder Neustart nach Dokumentation planen
11. Protokolle während der Aktivierung beobachten
12. Technischen und fachlichen Funktionstest durchführen
13. Nebenwirkungen prüfen
14. Bei Fehlschlag kontrolliert zurückrollen
15. Ursache, Änderung und Ergebnis dokumentieren

Risiken:

25. Reload, Neustart und Neuerstellung unterscheiden
Maßnahme Wirkung
Reload Dienst liest unterstützte Konfigurationsbereiche neu ein
Neustart Prozess wird beendet und neu gestartet
Systemneustart Gesamtes Betriebssystem startet neu
Containerneustart Gleiche Containerinstanz wird erneut gestartet
Containerneuerstellung Container wird aus Definition und Image neu erzeugt
Redeployment Anwendung und Konfiguration werden erneut bereitgestellt

Prüffragen:

Nicht jeder Dienst übernimmt jede Einstellung durch einen Reload. Die unterstützte Aktivierungsmethode muss aus der Produktdokumentation stammen.

26. Typische Fehlinterpretationen
Fehlinterpretation Richtige Bewertung
„Die Datei ist syntaktisch gültig, also funktioniert die Konfiguration.“ Werte, Pfade und Abhängigkeiten können trotzdem falsch sein
„Ich habe die Standarddatei geprüft.“ Der Dienst kann eine andere Datei verwenden
„Die Datei wurde geändert, also nutzt der Prozess den neuen Wert.“ Reload oder Neustart kann fehlen
„Der Wert steht nur einmal in der Hauptdatei.“ Include, Variable oder Startparameter kann ihn überschreiben
„Manueller Start funktioniert.“ Die Shell kann andere Variablen und Rechte besitzen
„Gleicher Dateiname bedeutet gleiche Konfiguration.“ Inhalt muss mit Hash oder Vergleich geprüft werden
„Der neueste Änderungszeitpunkt zeigt den Verursacher.“ Er zeigt nur eine Dateiänderung
„Die Beispielkonfiguration ist immer korrekt.“ Sie muss zur eingesetzten Version passen
„Eine Sicherungsdatei im Konfigurationsordner ist ungefährlich.“ Wildcard-Includes können sie mitladen
„Zurückkopieren der Datei stellt alles wieder her.“ Daten-, Schema- oder Laufzeitänderungen können bestehen bleiben
27. Checkliste zur Konfigurationsanalyse 
[ ] Richtigen Dienst und richtige Produktversion bestätigt
[ ] Tatsächliche Konfigurationsquelle ermittelt
[ ] Startparameter geprüft
[ ] Umgebungsvariablen berücksichtigt
[ ] Hauptdatei und Includes erfasst
[ ] Überschreibungsreihenfolge geklärt
[ ] Wirksame Konfiguration ermittelt
[ ] Datei vorhanden und nicht leer
[ ] Symbolische Links geprüft
[ ] Eigentümer und Berechtigungen geprüft
[ ] Arbeitsverzeichnis berücksichtigt
[ ] Syntax mit geeignetem Werkzeug geprüft
[ ] Produktspezifische Validierung durchgeführt
[ ] Pflichtwerte und Datentypen geprüft
[ ] Pfade und Zielsysteme geprüft
[ ] Port- und Protokollwerte geprüft
[ ] Versionskompatibilität geprüft
[ ] Referenzdatei gehört zur gleichen Version
[ ] Hash und Änderungszeit dokumentiert
[ ] Unterschiede zur funktionierenden Version geprüft
[ ] Secrets geschützt
[ ] Ausgangszustand gesichert
[ ] Genau eine Änderung geplant
[ ] Aktivierungsmethode geklärt
[ ] Rückfallmöglichkeit vorbereitet
[ ] Funktionstest festgelegt

Bewertung des Ergebnisses

Ergebnis Nächster Schritt
Falsche Datei wurde geprüft Tatsächliche Konfigurationsquelle untersuchen
Syntax ungültig Fehlerstelle sichern und nach Produktschema korrigieren
Syntax gültig, Wert aber falsch Sollwert und Abhängigkeit prüfen
Datei wird überschrieben Konfigurationspriorität und übergeordnete Quelle prüfen
Dienst verwendet alte Werte Unterstützten Reload oder Neustart planen
Pfad existiert nicht Deployment, Mount und Dateisystem prüfen
Dienstkonto kann Datei nicht lesen Berechtigung und Eigentümer untersuchen
Option ist veraltet Migrationsdokumentation der eingesetzten Version prüfen
Umgebungsvariable fehlt Tatsächlichen Dienstkontext prüfen
Konfigurationen unterscheiden sich Änderung fachlich bewerten und Ursache bestimmen
Konfiguration ist korrekt und wirksam Berechtigungen, Ressourcen und Anwendung untersuchen

Merksatz

Nicht die Datei, die ein Administrator bearbeitet, ist entscheidend, sondern die Konfiguration, die der Dienst im tatsächlichen Laufzeitkontext wirksam verwendet.

Weiterführende Quellen

4. Server- und Dienstfehler systematisch analysieren

4.9 Benutzer-, Dienstkonto- und Berechtigungsfehler

Jeder Dienst arbeitet in einem bestimmten Sicherheitskontext. Dieser entscheidet, auf welche Dateien, Verzeichnisse, Netzwerkressourcen, Zertifikate, Ports und Betriebssystemfunktionen der Dienst zugreifen darf.

Grundsatz:
Ein erfolgreicher Zugriff als Administrator beweist nicht, dass das tatsächliche Dienstkonto denselben Zugriff besitzt.

Ziele dieser Seite

Nach dieser Seite sollst du:

1. Sicherheitskontext eines Dienstes verstehen

Der Sicherheitskontext kann unter anderem enthalten:

Bei jedem Zugriff bewertet das System mehrere Faktoren:

Dienstkonto
  + Gruppenmitgliedschaften
  + lokale Rechte
  + ACLs des Zielobjekts
  + übergeordnete Verzeichnisrechte
  + Sicherheitsrichtlinien
  + Dienst- oder Containerbeschränkungen
  = effektiver Zugriff
2. Authentifizierung und Autorisierung unterscheiden
Begriff Leitfrage Beispiel
Authentifizierung Wer ist der Dienst? Anmeldung als Dienstkonto
Autorisierung Was darf dieses Konto? Leserechte auf Konfigurationsdatei
Identifikation Welches Konto wird verwendet? UID, SID oder Benutzername
Gruppenmitgliedschaft Welche Rollen besitzt das Konto? Mitglied der Datenbankgruppe
Privileg Welche Systemoperation ist erlaubt? Binden an privilegierten Port
ACL Welche Rechte gelten auf einem Objekt? Schreiben in Datenverzeichnis
Sicherheitsrichtlinie Welche zusätzliche Kontrolle greift? SELinux oder macOS TCC

Typische Trennung:

Anmeldung fehlgeschlagen
  → Authentifizierungsproblem

Anmeldung erfolgreich, Zugriff verweigert
  → Autorisierungsproblem
3. Typische Fehlerbilder eines Dienstkontos
Fehlerbild Mögliche Ursache
Dienst startet nicht Konto ungültig oder Anmelderecht fehlt
Zugriff verweigert Datei-, ACL- oder Sicherheitsrichtlinienfehler
Lokaler Zugriff funktioniert, Netzwerkzugriff nicht Andere Netzwerkidentität oder fehlende Remote-Berechtigung
Manueller Start funktioniert Administrator besitzt mehr Rechte als Dienstkonto
Dienst funktioniert bis zum Kennwortwechsel Hinterlegtes Dienstkennwort ist veraltet
Nur eine Datei ist nicht zugänglich Abweichender Eigentümer oder ACL
Schreiben scheitert, Lesen funktioniert Schreibrecht auf Datei oder Verzeichnis fehlt
Datei kann gelesen, aber nicht ersetzt werden Änderungsrecht auf Verzeichnis fehlt
Programm ist ausführbar, startet aber nicht Bibliothek, Arbeitsverzeichnis oder Sicherheitsrichtlinie blockiert
Zugriff funktioniert nach Anmeldung, aber nicht beim Boot Benutzersitzung oder Netzlaufwerk fehlt
macOS-Dienst erhält trotz POSIX-Rechten keinen Zugriff Datenschutzkontrolle oder Sandbox blockiert
Linux-Dienst erhält trotz Modus 777 keinen Zugriff SELinux, AppArmor, Mountoption oder systemd-Sandboxing
4. Dienstkonto unter Windows bestimmen

Dienstkonto und Status anzeigen:

[RO] Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'" |
    Select-Object Name,
                  DisplayName,
                  State,
                  StartMode,
                  StartName,
                  ProcessId

Alternative mit sc.exe:

[RO][SENS] sc.exe qc "<DIENSTNAME>"

Relevant ist:

SERVICE_START_NAME

Typische Windows-Dienstkonten:

Konto Grundlegende Einordnung
LocalSystem Sehr weitreichende lokale Rechte
LocalService Begrenzte lokale Rechte
NetworkService Begrenzte lokale Rechte, Netzwerkzugriff typischerweise als Computerkonto
Virtuelles Dienstkonto Dienstbezogene lokale Identität
Lokales Benutzerkonto Gilt primär auf dem lokalen System
Domänenkonto Kann abhängig von Berechtigungen auf Domänenressourcen zugreifen
Gruppenverwaltetes Dienstkonto Durch Active Directory verwaltetes Dienstkonto

Das Konto sollte nur die für den Dienst benötigten Rechte besitzen. Die Vergabe von Administratorrechten ist keine geeignete Standardlösung für ein Berechtigungsproblem.

5. Aktuellen Windows-Benutzerkontext anzeigen

Diese Befehle zeigen den Kontext der aktuellen Sitzung – nicht automatisch den Kontext des Dienstes.

Benutzername anzeigen:

[RO] whoami

Benutzer und SID anzeigen:

[RO] whoami /user

Gruppen anzeigen:

[RO][SENS] whoami /groups

Privilegien anzeigen:

[RO][SENS] whoami /priv

Gesamten aktuellen Sicherheitskontext anzeigen:

[RO][SENS] whoami /all

Die Ausgabe ist als Vergleich hilfreich. Sie darf aber nicht auf das Dienstkonto übertragen werden, wenn der Befehl in einer Administrator- oder Benutzersitzung ausgeführt wurde.

6. Lokales Windows-Konto und Gruppen prüfen

Lokales Konto suchen:

[RO] Get-LocalUser -Name "<BENUTZER>" -ErrorAction SilentlyContinue

Status eines lokalen Kontos anzeigen:

[RO][SENS] Get-LocalUser -Name "<BENUTZER>" |
    Select-Object Name,
                  Enabled,
                  LastLogon,
                  PasswordExpires,
                  PasswordRequired,
                  UserMayChangePassword

Mitgliedschaften einer lokalen Gruppe anzeigen:

[RO][SENS] Get-LocalGroupMember -Group "<GRUPPE>"

Alle lokalen Gruppen anzeigen:

[RO] Get-LocalGroup

Einschränkungen:

7. Windows-Dateirechte mit Get-Acl prüfen

ACL einer Datei anzeigen:

[RO][FILE][SENS] Get-Acl -LiteralPath "<DATEI>" |
    Format-List

Zugriffsregeln übersichtlich anzeigen:

[RO][FILE][SENS] (Get-Acl -LiteralPath "<DATEI>").Access |
    Select-Object IdentityReference,
                  FileSystemRights,
                  AccessControlType,
                  IsInherited,
                  InheritanceFlags,
                  PropagationFlags

ACL eines Verzeichnisses anzeigen:

[RO][FILE][SENS] (Get-Acl -LiteralPath "<VERZEICHNIS>").Access |
    Select-Object IdentityReference,
                  FileSystemRights,
                  AccessControlType,
                  IsInherited

Wichtige Felder:

Feld Bedeutung
IdentityReference Konto oder Gruppe
FileSystemRights Zugewiesene Rechte
Allow Erlaubende Regel
Deny Verweigernde Regel
IsInherited Regel wurde von übergeordnetem Objekt geerbt
Owner Eigentümer des Objekts

Eine explizite Verweigerung kann eine erlaubende Berechtigung überstimmen. Die effektive Bewertung hängt jedoch von der vollständigen ACL und dem Zugriffstoken ab.

8. Windows-Dateirechte mit icacls prüfen

ACL einer Datei oder eines Verzeichnisses anzeigen:

[RO][FILE][SENS] icacls "<PFAD>"

ACLs unterhalb eines Verzeichnisses anzeigen:

[RO][FILE][SENS] icacls "<VERZEICHNIS>" /T /C

/T durchsucht Unterverzeichnisse rekursiv und kann bei großen Verzeichnisbäumen eine sehr umfangreiche Ausgabe erzeugen.

Typische Rechtekürzel:

Kürzel Bedeutung
F Vollzugriff
M Ändern
RX Lesen und Ausführen
R Lesen
W Schreiben
D Löschen
N Kein Zugriff
I Geerbte Regel

Typische Vererbungskennzeichnungen:

Kürzel Bedeutung
OI Vererbung an Dateien
CI Vererbung an Unterverzeichnisse
IO Regel gilt nur durch Vererbung
NP Keine weitere Vererbung

Auf dieser Diagnoseseite wird icacls nur lesend verwendet. Parameter wie /grant, /deny, /remove oder /reset verändern Berechtigungen.

9. Effektive Windows-Rechte mit AccessChk untersuchen

AccessChk ist ein zusätzliches Microsoft-Sysinternals-Werkzeug und nicht Bestandteil jeder Windows-Installation.

Grundlegende Prüfung eines Kontos auf einen bekannten Pfad:

[RO][FILE][SENS] accesschk.exe `
    -nobanner `
    -v `
    "<KONTO>" `
    "<PFAD>"

Prüfung eines Verzeichnisses:

[RO][FILE][SENS] accesschk.exe `
    -nobanner `
    -d `
    -v `
    "<KONTO>" `
    "<VERZEICHNIS>"

Vor Verwendung prüfen:

Wenn AccessChk nicht vorhanden oder nicht freigegeben ist, wird es nicht ungeprüft heruntergeladen oder auf einem Produktivserver installiert.

10. Erforderliche Windows-Dienstprivilegien prüfen

Vom Dienst angeforderte Privilegien anzeigen:

[RO] sc.exe qprivs "<DIENSTNAME>"

Wiederherstellungs- und Dienstkonfiguration ergänzend prüfen:

[RO] sc.exe qfailure "<DIENSTNAME>"

[RO][SENS] sc.exe qc "<DIENSTNAME>"

Wichtig:

11. Windows-Anmeldefehler des Dienstkontos untersuchen

Typische Ursachen:

Service-Control-Manager-Ereignisse prüfen:

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName      = "System"
    ProviderName = "Service Control Manager"
    StartTime    = (Get-Date).AddHours(-2)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  Message

Sicherheitsereignisse erfordern entsprechende Berechtigungen:

[RO][SENS][PRIV] Get-WinEvent -FilterHashtable @{
    LogName   = "Security"
    StartTime = (Get-Date).AddHours(-2)
} |
    Select-Object TimeCreated,
                  Id,
                  ProviderName,
                  Message

Das Sicherheitsprotokoll kann sehr viele sensible Informationen enthalten. Es sollte mit passenden Ereignis-IDs, Zeitfenstern und zuständigen Sicherheitsadministratoren ausgewertet werden.

12. Windows-Netzwerkidentität des Dienstkontos berücksichtigen

Der lokale Kontoname ist nicht zwingend die Identität, die ein entfernter Server sieht.

Dienstkonto Mögliche Netzwerkidentität
Lokales Benutzerkonto Auf entferntem System nicht automatisch bekannt
LocalService Netzwerkzugriff typischerweise anonym beziehungsweise sehr begrenzt
NetworkService Zugriff im Domänenumfeld typischerweise als Computerkonto
LocalSystem Zugriff im Domänenumfeld typischerweise als Computerkonto
Domänenkonto Eigenes Domänenkonto
gMSA Verwaltete Domänenidentität

Prüffragen:

Bei einer Windows-Freigabe müssen sowohl die Freigabeberechtigung als auch die NTFS-Berechtigung den benötigten Zugriff erlauben.

13. Dienstkonto unter Linux bestimmen

systemd-Dienstkonto anzeigen:

[RO] systemctl show "<DIENST>" \
  --property=User,Group,DynamicUser,SupplementaryGroups

Wirksame Unit prüfen:

[RO][FILE][SENS] systemctl cat "<DIENST>"

Benutzerkonto auflösen:

[RO] getent passwd "<DIENSTBENUTZER>"

Gruppenkonto auflösen:

[RO] getent group "<DIENSTGRUPPE>"

UID, primäre und zusätzliche Gruppen anzeigen:

[RO] id "<DIENSTBENUTZER>"

Wichtig:

14. POSIX-Dateirechte unter Linux verstehen

Beispiel:

-rwxr-x--- 1 appuser appgroup 4096 Jul 31 09:00 application

Interpretation:

Bereich Bedeutung
- Reguläre Datei
rwx Eigentümer darf lesen, schreiben und ausführen
r-x Gruppe darf lesen und ausführen
--- Andere besitzen keine Rechte
appuser Eigentümer
appgroup Gruppe

Rechte:

Recht Datei Verzeichnis
r Dateiinhalt lesen Verzeichnisinhalt auflisten
w Dateiinhalt verändern Einträge anlegen oder entfernen
x Datei ausführen Verzeichnis durchlaufen und Objekte erreichen

Schreibrecht auf einer Datei und Schreibrecht auf dem übergeordneten Verzeichnis sind unterschiedliche Berechtigungen. Das Ersetzen oder Löschen einer Datei hängt häufig vom Verzeichnisrecht ab.

15. Linux-Dateirechte und Pfadbestandteile prüfen

Dateirechte anzeigen:

[RO][FILE] ls -ld "<DATEI>"

Numerische und symbolische Rechte anzeigen:

[RO][FILE] stat -c '%U %G %A %a %n' "<DATEI>"

Alle Bestandteile eines Pfads prüfen:

[RO][FILE] namei -l "<DATEI>"

Verzeichnis und Zieldatei gemeinsam prüfen:

[RO][FILE] ls -ld "<VERZEICHNIS>" "<DATEI>"

Prüffragen:

16. Linux-ACLs prüfen

ACL einer Datei anzeigen:

[RO][FILE][SENS] getfacl "<DATEI>"

ACL eines Verzeichnisses anzeigen:

[RO][FILE][SENS] getfacl "<VERZEICHNIS>"

Mögliche Ausgabe:

user::rw-
user:appuser:r--
group::r--
mask::r--
other::---

Wichtige Elemente:

Eintrag Bedeutung
user:: Rechte des Eigentümers
user:name: Rechte eines bestimmten Benutzers
group:: Rechte der Eigentümergruppe
group:name: Rechte einer bestimmten Gruppe
mask:: Maximale wirksame Rechte benannter Benutzer und Gruppen
other:: Rechte aller übrigen Benutzer
default: Standard-ACL für neu erstellte Unterobjekte

Die ACL-Maske kann weitergehende angezeigte Einzelrechte begrenzen. Deshalb müssen sowohl Eintrag als auch mask bewertet werden.

17. Linux-Zugriff im tatsächlichen Benutzerkontext testen

Die folgenden Tests lesen oder verändern die Zieldatei nicht. Sie prüfen nur, ob der angegebene Zugriff laut Betriebssystem möglich ist.

Leserecht prüfen:

[TEST][PRIV] sudo -u "<DIENSTBENUTZER>" \
  test -r "<DATEI>"

Schreibrecht prüfen:

[TEST][PRIV] sudo -u "<DIENSTBENUTZER>" \
  test -w "<DATEI>"

Ausführungsrecht prüfen:

[TEST][PRIV] sudo -u "<DIENSTBENUTZER>" \
  test -x "<AUSFÜHRBARE_DATEI>"

Verzeichniszugriff prüfen:

[TEST][PRIV] sudo -u "<DIENSTBENUTZER>" \
  test -x "<VERZEICHNIS>"

Rückgabecode unmittelbar anzeigen:

[TEST][PRIV] sudo -u "<DIENSTBENUTZER>" \
  test -r "<DATEI>"

echo $?
Rückgabecode Bedeutung
0 Bedingung erfüllt
ungleich 0 Bedingung nicht erfüllt oder Prüfung nicht möglich

Einschränkung:

Ein erfolgreicher test -r- oder test -w-Befehl beweist nicht, dass SELinux, AppArmor, Anwendungssandboxing oder produktspezifische Regeln jeden späteren Zugriff erlauben.

18. Linux-Sonderrechte und Mountoptionen berücksichtigen

Mountoptionen des Zielpfads anzeigen:

[RO][FILE] findmnt --target "<PFAD>"

Mögliche relevante Optionen:

Option Bedeutung
ro Dateisystem ist schreibgeschützt
rw Dateisystem ist beschreibbar
noexec Direkte Ausführung von Dateien auf diesem Dateisystem wird verhindert
nosuid Setuid- und Setgid-Wirkung wird eingeschränkt
nodev Gerätedateien werden nicht interpretiert

Dateirechte einschließlich Sonderbits anzeigen:

[RO][FILE] stat -c '%A %a %U %G %n' "<DATEI>"

Mögliche Sonderbits:

Sonderrechte dürfen nicht als schnelle Problembehebung gesetzt werden. Eine falsche Verwendung kann erhebliche Sicherheitsrisiken erzeugen.

19. SELinux als zusätzliche Zugriffskontrolle prüfen

Diese Befehle sind nur auf Systemen mit installiertem SELinux-Werkzeug relevant.

SELinux-Status anzeigen:

[RO] getenforce

Mögliche Ergebnisse:

Zustand Bedeutung
Enforcing Richtlinien werden durchgesetzt
Permissive Verstöße werden protokolliert, aber nicht blockiert
Disabled SELinux ist deaktiviert

SELinux-Kontext einer Datei anzeigen:

[RO][FILE][SENS] ls -lZ "<DATEI>"

Prozesskontext anzeigen:

[RO][SENS] ps -eZ |
    grep -- "<PROZESS>"

Aktuelle AVC-Verweigerungen suchen:

[RO][SENS][PRIV] sudo ausearch -m AVC -ts recent

Wichtig:

20. AppArmor als zusätzliche Zugriffskontrolle prüfen

Diese Befehle gelten nur, wenn AppArmor installiert und aktiv ist.

AppArmor-Status anzeigen:

[RO][PRIV] sudo aa-status

Kernel- und Systemmeldungen nach Verweigerungen durchsuchen:

[RO][SENS][PRIV] sudo journalctl \
  -k \
  --since "1 hour ago" |
    grep -i -- "apparmor"

Mögliche Zustände:

Zustand Bedeutung
Enforce Profilregeln werden durchgesetzt
Complain Verstöße werden protokolliert, aber normalerweise nicht blockiert
Unconfined Prozess wird nicht durch ein AppArmor-Profil eingeschränkt

AppArmor darf nicht pauschal deaktiviert werden. Zuerst müssen Profil, verweigerter Pfad und tatsächlich erforderlicher Zugriff bestimmt werden.

21. systemd-Sandboxing und Capabilities prüfen

Auch ohne SELinux oder AppArmor kann systemd einen Dienst zusätzlich einschränken.

Sicherheitsrelevante Eigenschaften anzeigen:

[RO][SENS] systemctl show "<DIENST>" \
  --property=NoNewPrivileges,ProtectSystem,ProtectHome,PrivateTmp,PrivateDevices,ReadOnlyPaths,ReadWritePaths,InaccessiblePaths,CapabilityBoundingSet,AmbientCapabilities

Mögliche Einschränkungen:

Eigenschaft Mögliche Wirkung
ProtectSystem= Teile des Dateisystems werden schreibgeschützt
ProtectHome= Zugriff auf Benutzerverzeichnisse wird eingeschränkt
PrivateTmp= Dienst erhält eigenes temporäres Verzeichnis
PrivateDevices= Zugriff auf Geräte wird eingeschränkt
ReadOnlyPaths= Bestimmte Pfade werden schreibgeschützt
ReadWritePaths= Ausgewählte Pfade werden beschreibbar gemacht
InaccessiblePaths= Pfade werden unzugänglich
NoNewPrivileges= Erwerb neuer Privilegien wird verhindert
CapabilityBoundingSet= Verfügbare Linux-Capabilities werden begrenzt

Ein erfolgreicher Zugriff aus einer normalen Shell beweist nicht, dass derselbe Pfad innerhalb der systemd-Sandbox verfügbar ist.

22. Dienstkonto unter macOS bestimmen

Systemweiten launchd-Job anzeigen:

[RO] launchctl print "system/<LABEL>"

launchd-plist anzeigen:

[RO][FILE][SENS] plutil -p "/Library/LaunchDaemons/<LABEL>.plist"

Relevante Schlüssel:

UserName
GroupName
Program
ProgramArguments
WorkingDirectory
EnvironmentVariables

Falls UserName bei einem systemweiten LaunchDaemon nicht gesetzt ist, muss der tatsächliche Ausführungskontext anhand von launchd-Konfiguration und laufendem Prozess geprüft werden.

Ausführungskonto eines laufenden Prozesses anzeigen:

[RO][SENS] ps -p <PID> \
  -o user,uid,gid,pid,ppid,command
23. Benutzer und Gruppen unter macOS prüfen

UID, GID und Gruppen eines Kontos anzeigen:

[RO] id "<BENUTZER>"

Lokales Benutzerkonto über Directory Service anzeigen:

[RO][SENS] dscl . -read "/Users/<BENUTZER>"

Bestimmte lokale Gruppe anzeigen:

[RO][SENS] dscl . -read "/Groups/<GRUPPE>"

Gruppenmitgliedschaft prüfen:

[RO] dsmemberutil checkmembership \
  -U "<BENUTZER>" \
  -G "<GRUPPE>"

Hinweise:

24. POSIX-Rechte und ACLs unter macOS prüfen

Rechte, Eigentümer und ACL anzeigen:

[RO][FILE][SENS] ls -lde "<DATEI>"

Erweiterte Attribute zusätzlich anzeigen:

[RO][FILE][SENS] ls -lde@ "<DATEI>"

Dateiflags anzeigen:

[RO][FILE][SENS] ls -ldeO "<DATEI>"

Metadaten strukturiert anzeigen:

[RO][FILE] stat -f '%Su %Sg %Sp %N' "<DATEI>"

Mögliche zusätzliche Einflussfaktoren:

Ein + in der Ausgabe von ls -l weist auf ACL-Einträge hin. Ein @ weist auf erweiterte Attribute hin.

25. Zugriff unter macOS im Benutzerkontext testen

Leserecht prüfen:

[TEST][PRIV] sudo -u "<DIENSTBENUTZER>" \
  test -r "<DATEI>"

Schreibrecht prüfen:

[TEST][PRIV] sudo -u "<DIENSTBENUTZER>" \
  test -w "<DATEI>"

Ausführungsrecht prüfen:

[TEST][PRIV] sudo -u "<DIENSTBENUTZER>" \
  test -x "<AUSFÜHRBARE_DATEI>"

Rückgabecode anzeigen:

[TEST][PRIV] sudo -u "<DIENSTBENUTZER>" \
  test -r "<DATEI>"

echo $?

Dieser Test bildet nicht automatisch den vollständigen launchd-, Sandbox- oder Datenschutzkontext eines Dienstes nach.

26. macOS-Datenschutzkontrollen berücksichtigen

macOS schützt unter anderem Zugriffe auf:

Ein Zugriff kann trotz korrekter POSIX-Rechte und ACLs verweigert werden.

Protokolle nach dem Prozess durchsuchen:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate 'process == "<PROZESS>"' \
  --style compact \
  --no-pager

Nach möglichen Zugriffsverweigerungen suchen:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate 'process == "<PROZESS>" AND (messageType == error OR messageType == fault)' \
  --style compact \
  --no-pager

Wichtig:

27. macOS System Integrity Protection und Dateiflags berücksichtigen

SIP-Status anzeigen:

[RO] csrutil status

System Integrity Protection schützt bestimmte Systembereiche auch vor weitreichenden Benutzerkonten.

Dateiflags prüfen:

[RO][FILE] ls -ldeO "<DATEI>"

Mögliche Einflussfaktoren:

SIP darf nicht als allgemeine Fehlerbehebung deaktiviert werden. Zuerst muss geklärt werden, warum eine Anwendung auf einen geschützten Systembereich zugreifen möchte.

28. Netzwerkfreigaben und entfernte Ressourcen prüfen

Bei einer entfernten Ressource existieren mindestens zwei Berechtigungsebenen:

Lokaler Dienstkontext
  → Netzwerkidentität
  → Authentifizierung am Ziel
  → Freigabe- oder Dienstberechtigung
  → Dateisystem- oder Objektberechtigung

Prüffragen:

Die Berechtigungsprüfung muss auch auf dem Zielsystem erfolgen. Der Quellserver kann häufig nur feststellen, dass der Zugriff abgelehnt wurde.

29. Containerbenutzer und Hostrechte berücksichtigen

Ein Containerprozess kann innerhalb und außerhalb des Containers unterschiedliche Identitätsdarstellungen besitzen.

Zu prüfen sind:

Typisches Fehlerbild:

Datei auf dem Host gehört UID 1000
Containerprozess läuft als UID 1001
Volume ist nur für UID 1000 beschreibbar
Anwendung meldet „Permission denied“

Ein Wechsel des Containers auf Benutzer root ist keine geeignete Standardlösung. Zuerst müssen vorgesehene UID, GID und Volume-Berechtigungen aus der Image- beziehungsweise Herstellerdokumentation ermittelt werden.

30. Leserecht, Schreibrecht und Änderungsrecht praktisch unterscheiden
Gewünschte Aktion Typischer benötigter Zugriff
Dateiinhalt lesen Leserecht auf Datei und Durchlaufrecht auf Verzeichnisse
Dateiinhalt verändern Schreibrecht auf Datei
Neue Datei anlegen Schreib- und Durchlaufrecht auf Verzeichnis
Datei ersetzen Rechte auf Datei und beziehungsweise oder Verzeichnis, abhängig vom Verfahren
Datei löschen Lösch- beziehungsweise Verzeichnisrecht
Programm ausführen Ausführungsrecht und Zugriff auf Bibliotheken
Verzeichnis auflisten Leserecht auf Verzeichnis
Pfad durchlaufen Ausführungsrecht auf Verzeichnis
Logdatei erzeugen Schreibrecht auf Zielverzeichnis
Socketdatei erstellen Schreibrecht auf Laufzeitverzeichnis

Viele Anwendungen speichern eine Konfiguration, indem sie eine neue Datei erzeugen und anschließend die alte Datei ersetzen. Dafür kann Schreibrecht auf der ursprünglichen Datei allein unzureichend sein.

31. Berechtigungsproblem sicher reproduzieren

Ein geeigneter Test verändert möglichst wenig und verwendet das tatsächliche Konto.

Testablauf:

1. Dienstkonto bestimmen
2. Zielobjekt und benötigte Aktion bestimmen
3. Aktuelle Rechte und ACLs sichern
4. Sicherheitsrichtlinien prüfen
5. Lesenden Zugriff im Dienstkontext testen
6. Protokolle auf Quelle und Ziel beobachten
7. Nur bei Bedarf einen freigegebenen Schreibtest verwenden
8. Ergebnis und Rückgabecode dokumentieren
9. Testdateien vollständig entfernen
10. Keine Rechte auf Verdacht erweitern

Ungeeigneter Test:

Als Administrator Datei öffnen

Besserer Test:

Mit tatsächlicher Dienstidentität exakt den benötigten Zugriff prüfen
32. Warum chmod 777 oder Vollzugriff keine geeignete Diagnose ist

Eine pauschale Rechteerweiterung:

Besseres Vorgehen:

  1. benötigte Aktion bestimmen,
  2. tatsächliches Dienstkonto bestimmen,
  3. aktuell fehlende Einzelberechtigung bestimmen,
  4. vorgesehene Herstellerberechtigung prüfen,
  5. kleinste ausreichende Änderung planen,
  6. Änderung dokumentieren,
  7. Funktion testen,
  8. überflüssige Rechte ausschließen.
33. Gruppenmitgliedschaft richtig bewerten

Eine neue Gruppenmitgliedschaft ist nicht immer sofort in jedem Prozess wirksam.

Mögliche Gründe:

Prüfung:

Konto Mitglied der Gruppe?
  ↓
Gruppe auf Zielobjekt berechtigt?
  ↓
ACL-Maske oder Deny-Regel berücksichtigt?
  ↓
Aktuelles Zugriffstoken enthält die Gruppe?
  ↓
Dienstprozess nach Änderung neu authentifiziert?

Ein Neustart darf erst nach Erfassung des Ausgangszustands und Prüfung der Auswirkungen erfolgen.

34. Typische Fehlinterpretationen
Fehlinterpretation Richtige Bewertung
„Administrator kann zugreifen, also stimmen die Rechte.“ Dienstkonto besitzt einen anderen Sicherheitskontext
„Die Datei hat Leserecht, also kann der Dienst sie öffnen.“ Übergeordnete Verzeichnisse und Sicherheitsrichtlinien zählen ebenfalls
„Der Benutzer steht in der ACL, also ist der Zugriff erlaubt.“ Deny-Regeln, Gruppen und ACL-Masken können das Ergebnis verändern
„Linux-Modus 777 erlaubt immer alles.“ SELinux, AppArmor, Mountoptionen und Sandbox können weiter blockieren
„Root darf auf jeden macOS-Pfad zugreifen.“ SIP und Datenschutzkontrollen können zusätzliche Grenzen setzen
„Lokales Dienstkonto verwendet denselben Namen am Fileserver.“ Die Netzwerkidentität kann eine andere sein
„Gruppenänderung ist sofort wirksam.“ Laufender Prozess kann ein altes Token besitzen
„Schreibrecht auf Datei erlaubt das Ersetzen der Datei.“ Dafür können Rechte auf dem Verzeichnis erforderlich sein
„Full Disk Access ist die einfachste Lösung.“ Es ist eine sehr weitreichende Sicherheitsfreigabe
„Der Dienst benötigt Administratorrechte.“ Meist muss nur eine konkrete Ressource passend berechtigt werden
35. Checkliste zur Berechtigungsanalyse 
[ ] Tatsächliches Dienstkonto bestimmt
[ ] Benutzerkonto existiert und ist aktiviert
[ ] Kontosperre und Kennwortstatus geprüft
[ ] Primäre und zusätzliche Gruppen erfasst
[ ] UID, GID beziehungsweise SID dokumentiert
[ ] Dienstanmelderecht geprüft
[ ] Verweigernde Richtlinien berücksichtigt
[ ] Zieldatei und benötigte Aktion bestimmt
[ ] Rechte aller Pfadbestandteile geprüft
[ ] Eigentümer und Gruppe geprüft
[ ] ACLs und Vererbung geprüft
[ ] ACL-Maske beziehungsweise Deny-Regeln berücksichtigt
[ ] Dateisystem-Mountoptionen geprüft
[ ] Zugriff im tatsächlichen Konto getestet
[ ] Lokalen und entfernten Zugriff getrennt geprüft
[ ] Netzwerkidentität des Dienstes bestimmt
[ ] Zielsystemprotokoll geprüft
[ ] SELinux beziehungsweise AppArmor berücksichtigt
[ ] systemd-Sandboxing berücksichtigt
[ ] macOS-Datenschutz und SIP berücksichtigt
[ ] Container-UID und Volume-Rechte berücksichtigt
[ ] Keine pauschale Rechteerweiterung durchgeführt
[ ] Kleinste notwendige Änderung bestimmt
[ ] Ausgangsberechtigungen vor Änderung gesichert
[ ] Funktion und Sicherheit nach Änderung geprüft

Bewertung des Ergebnisses

Ergebnis Nächster Schritt
Dienstkonto ungültig oder gesperrt Kontostatus und Verwaltungsprozess prüfen
Dienstanmeldung schlägt fehl Kennwort, Anmelderecht und Richtlinien prüfen
Datei kann nicht gelesen werden Pfad-, Datei- und ACL-Rechte prüfen
Datei lesbar, aber nicht schreibbar Datei- und Verzeichnisrechte getrennt prüfen
Lokaler Zugriff funktioniert, Remotezugriff nicht Netzwerkidentität und Zielberechtigung prüfen
Klassische Rechte stimmen, Zugriff bleibt verweigert SELinux, AppArmor, Sandbox oder macOS-Datenschutz prüfen
Gruppenrecht fehlt im laufenden Prozess Token- beziehungsweise Prozessneuerstellung planen
Container kann Volume nicht beschreiben UID-, GID-, Mount- und Sicherheitslabel prüfen
Zugriff funktioniert nur als Administrator Fehlende Einzelberechtigung des Dienstkontos bestimmen
Alle Berechtigungen stimmen Ressourcen, Konfiguration und Anwendungslogik untersuchen

Merksatz

Berechtigungen werden nicht danach bewertet, was ein Administrator darf, sondern danach, was das tatsächliche Dienstkonto im echten Laufzeit- und Zielsystemkontext darf.

Weiterführende Quellen

4. Server- und Dienstfehler systematisch analysieren

4.10 Ressourcenengpässe erkennen

Ein Dienst kann korrekt konfiguriert sein und trotzdem langsam, instabil oder nicht erreichbar werden, wenn ihm oder dem Gesamtsystem benötigte Ressourcen fehlen.

Grundsatz:
Ein einzelner hoher Messwert beweist noch keinen Engpass. Entscheidend sind Messdauer, Vergleichswerte, Auslastungsursache und der zeitliche Zusammenhang mit der Störung.

Ziele dieser Seite

Nach dieser Seite sollst du:

1. Welche Ressourcen können einen Dienst begrenzen?
Ressource Typisches Fehlerbild
CPU Hohe Antwortzeiten, Zeitüberschreitungen, verzögerte Verarbeitung
Arbeitsspeicher Paging, Prozessabbrüche, fehlgeschlagene Allokationen
Swap beziehungsweise Auslagerungsdatei Hohe Latenz durch Speicherauslagerung
Datenträger-I/O Lange Wartezeiten, blockierte Prozesse, langsame Datenbank
Speicherplatz Schreiben, Starten oder Protokollieren schlägt fehl
Inodes Linux kann trotz freiem Speicherplatz keine Dateien anlegen
Dateideskriptoren Neue Dateien oder Sockets können nicht geöffnet werden
Windows-Handles Zugriff auf Dateien, Registry, Events oder Prozesse schlägt fehl
Threads Neue Aufgaben oder Verbindungen können nicht verarbeitet werden
Prozesslimit Neue Prozesse können nicht erzeugt werden
Netzwerkbandbreite Langsame Übertragung und Warteschlangen
Verbindungspool Neue Datenbank- oder HTTP-Verbindungen warten
Portbereich Neue ausgehende TCP-Verbindungen schlagen fehl
GPU oder Beschleuniger Spezialisierte Berechnung kann nicht ausgeführt werden
Quota Benutzer oder Dienst darf keine weiteren Daten speichern
Containerlimit Dienst erreicht CPU-, RAM- oder Prozessgrenze des Containers
2. Auslastung und Engpass unterscheiden
Zustand Beschreibung
Auslastung Eine Ressource wird verwendet
Hohe Auslastung Ressource wird stark verwendet, Dienst funktioniert aber noch
Sättigung Neue Arbeit muss warten
Engpass Ressourcenbegrenzung beeinträchtigt die benötigte Funktion
Überlast Eingehende Arbeit übersteigt dauerhaft die Verarbeitungskapazität
Ressourcenleck Verbrauch steigt, obwohl abgeschlossene Arbeit Ressourcen freigeben sollte
Grenzwertfehler Konfiguriertes Limit wird vor der technischen Kapazität erreicht

Beispiel:

CPU-Auslastung: 95 %
Antwortzeit:     normal
Warteschlange:   niedrig
Fehler:          keine

Das ist hohe Auslastung, aber noch kein bewiesener Engpass.

CPU-Auslastung: 95 %
Antwortzeit:     stark erhöht
Warteschlange:   wächst
Timeouts:        vorhanden

Hier besteht ein belastbarer Hinweis auf CPU-Sättigung.

3. Immer über mehrere Messpunkte prüfen

Eine Momentaufnahme kann zufällig während einer kurzen Lastspitze entstehen.

Empfohlene Messstruktur:

Zeitpunkt
CPU gesamt
CPU des Dienstprozesses
verfügbarer Arbeitsspeicher
Swap- beziehungsweise Paging-Aktivität
Datenträger-I/O und Wartezeit
Anzahl aktiver Anfragen
Anwendungsantwortzeit
Fehlerrate

Sinnvolle Vergleichszeiträume:

Ein Messwerkzeug erzeugt selbst Last. Abtastrate, Anzahl der Messwerte und Detailgrad müssen zum System passen.

4. Schnellübersicht für Windows, Linux und macOS
Aufgabe Windows Linux macOS
Systemlaufzeit [RO] (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime [RO] uptime [RO] uptime
Logische Prozessoren [RO] (Get-CimInstance Win32_ComputerSystem).NumberOfLogicalProcessors [RO] nproc [RO] sysctl -n hw.logicalcpu
Prozessübersicht [RO] Get-Process [RO] top [RO] top
Speicherübersicht [RO] Get-CimInstance Win32_OperatingSystem [RO] free -h [RO] memory_pressure
Swap [RO] Get-CimInstance Win32_PageFileUsage [RO] swapon --show [RO] sysctl vm.swapusage
Datenträgerübersicht [RO] Get-Volume [RO] iostat [RO] iostat
Prozesslimits Betriebssystemspezifisch [RO][FILE] cat /proc/<PID>/limits [RO] launchctl limit
Systemprotokolle [RO] Get-WinEvent [RO][PRIV] sudo journalctl [RO][PRIV] sudo log show
5. CPU-Grunddaten unter Windows prüfen

Anzahl logischer Prozessoren anzeigen:

[RO] Get-CimInstance Win32_ComputerSystem |
    Select-Object NumberOfProcessors,
                  NumberOfLogicalProcessors

Gesamte CPU-Auslastung als Momentaufnahme:

[RO] Get-CimInstance `
    Win32_PerfFormattedData_PerfOS_Processor `
    -Filter "Name='_Total'" |
    Select-Object Name,
                  PercentProcessorTime,
                  PercentUserTime,
                  PercentPrivilegedTime,
                  PercentIdleTime

Mehrere Messpunkte mit Get-Counter erfassen:

[RO] Get-Counter `
    -Counter '\Processor(_Total)\% Processor Time' `
    -SampleInterval 2 `
    -MaxSamples 5

Die Namen klassischer Windows-Leistungsindikatoren können auf lokalisierten Windows-Systemen übersetzt sein. Falls ein Counterpfad nicht gefunden wird, müssen die auf diesem System vorhandenen Zählersätze ermittelt werden.

Verfügbare Zählersätze suchen:

[RO] Get-Counter -ListSet * |
    Select-Object CounterSetName |
    Sort-Object CounterSetName
6. CPU-verbrauchende Windows-Prozesse ermitteln

Prozesse nach kumulierter CPU-Zeit sortieren:

[RO] Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 15 Id,
                           ProcessName,
                           CPU,
                           StartTime

Die Eigenschaft CPU enthält die gesamte bisher verbrauchte Prozessorzeit des Prozesses in Sekunden. Sie ist kein momentaner Prozentwert.

Momentane Prozessauslastung über formatierte Leistungsdaten:

[RO] Get-CimInstance Win32_PerfFormattedData_PerfProc_Process |
    Where-Object Name -NotIn "_Total", "Idle" |
    Sort-Object PercentProcessorTime -Descending |
    Select-Object -First 15 Name,
                           IDProcess,
                           PercentProcessorTime,
                           ThreadCount,
                           WorkingSetPrivate

Bestimmte PID untersuchen:

[RO] Get-Process -Id <PID> |
    Select-Object Id,
                  ProcessName,
                  StartTime,
                  CPU,
                  Threads,
                  HandleCount

Die Prozess-CPU-Ausgabe kann bei mehreren logischen Prozessoren anders skaliert wirken als die gesamte Systemauslastung. Werte müssen im Kontext des verwendeten Messwerkzeugs interpretiert werden.

7. Arbeitsspeicher unter Windows prüfen

Gesamten und freien physischen Speicher anzeigen:

[RO] Get-CimInstance Win32_OperatingSystem |
    Select-Object @{
        Name="TotalRAM_GiB"
        Expression={[math]::Round($_.TotalVisibleMemorySize / 1MB, 2)}
    }, @{
        Name="FreeRAM_GiB"
        Expression={[math]::Round($_.FreePhysicalMemory / 1MB, 2)}
    }, @{
        Name="FreeVirtualMemory_GiB"
        Expression={[math]::Round($_.FreeVirtualMemory / 1MB, 2)}
    }

Die CIM-Werte werden hier von KiB in GiB umgerechnet.

Speicherindikatoren als Momentaufnahme:

[RO] Get-CimInstance Win32_PerfFormattedData_PerfOS_Memory |
    Select-Object AvailableMBytes,
                  PercentCommittedBytesInUse,
                  PagesPerSec,
                  PageReadsPerSec,
                  PageWritesPerSec,
                  PoolPagedBytes,
                  PoolNonpagedBytes

Mehrere Messpunkte des verfügbaren Speichers:

[RO] Get-Counter `
    -Counter '\Memory\Available MBytes' `
    -SampleInterval 2 `
    -MaxSamples 5

Ein niedriger Wert bei „freiem“ Speicher ist nicht automatisch ein Fehler, weil Betriebssysteme ungenutzten Speicher als Cache verwenden. Verfügbarer Speicher, Paging-Aktivität und Anwendungsfunktion müssen gemeinsam betrachtet werden.

8. Speicherverbrauch von Windows-Prozessen prüfen

Nach Working Set sortieren:

[RO] Get-Process |
    Sort-Object WorkingSet64 -Descending |
    Select-Object -First 15 Id,
                           ProcessName,
                           @{
                               Name="WorkingSet_MiB"
                               Expression={[math]::Round($_.WorkingSet64 / 1MB, 2)}
                           },
                           @{
                               Name="PrivateMemory_MiB"
                               Expression={[math]::Round($_.PrivateMemorySize64 / 1MB, 2)}
                           }

Bestimmten Prozess untersuchen:

[RO] Get-Process -Id <PID> |
    Select-Object Id,
                  ProcessName,
                  WorkingSet64,
                  PrivateMemorySize64,
                  VirtualMemorySize64,
                  PagedMemorySize64,
                  PeakWorkingSet64
Wert Bedeutung
WorkingSet64 Derzeit im physischen Speicher befindliche Seiten
PrivateMemorySize64 Privat zugeordneter Speicher
VirtualMemorySize64 Virtueller Adressraum
PagedMemorySize64 Auslagerungsfähiger Speicher
PeakWorkingSet64 Bisheriger Höchstwert des Working Sets

Virtueller Speicher darf nicht direkt mit physisch belegtem RAM gleichgesetzt werden.

9. Windows-Auslagerungsdatei prüfen

Nutzung der Auslagerungsdatei anzeigen:

[RO] Get-CimInstance Win32_PageFileUsage |
    Select-Object Name,
                  AllocatedBaseSize,
                  CurrentUsage,
                  PeakUsage

Die Größen werden üblicherweise in MiB angegeben.

Konfiguration der Auslagerungsdatei anzeigen:

[RO] Get-CimInstance Win32_PageFileSetting |
    Select-Object Name,
                  InitialSize,
                  MaximumSize

Mögliche Hinweise auf Speicherdruck:

Das Vorhandensein einer verwendeten Auslagerungsdatei ist nicht automatisch ein Fehler. Entscheidend ist eine dauerhaft hohe Paging-Aktivität zusammen mit Leistungsproblemen.

10. Windows-Datenträger-I/O prüfen

Formatierte Datenträgerleistungsdaten anzeigen:

[RO] Get-CimInstance Win32_PerfFormattedData_PerfDisk_PhysicalDisk |
    Where-Object Name -ne "_Total" |
    Select-Object Name,
                  DiskReadsPerSec,
                  DiskWritesPerSec,
                  DiskReadBytesPerSec,
                  DiskWriteBytesPerSec,
                  AvgDiskQueueLength,
                  CurrentDiskQueueLength,
                  PercentDiskTime

Mehrere Messpunkte mit Get-Counter:

[RO] Get-Counter `
    -Counter '\PhysicalDisk(*)\Avg. Disk sec/Read',
             '\PhysicalDisk(*)\Avg. Disk sec/Write',
             '\PhysicalDisk(*)\Current Disk Queue Length' `
    -SampleInterval 2 `
    -MaxSamples 5

Auch hier können lokalisierte Leistungsindikatornamen abweichen.

Zu prüfen:

11. Windows-Handles und Threads prüfen

Gesamtanzahl von Prozessen, Threads und Handles:

[RO] Get-CimInstance Win32_PerfFormattedData_PerfOS_System |
    Select-Object Processes, Threads

[RO] Get-CimInstance Win32_PerfFormattedData_PerfOS_Objects |
    Select-Object Processes,
                  Threads,
                  Events,
                  Mutexes,
                  Sections,
                  Semaphores

Prozesse nach Handleanzahl sortieren:

[RO] Get-Process |
    Sort-Object HandleCount -Descending |
    Select-Object -First 15 Id,
                           ProcessName,
                           HandleCount,
                           @{
                               Name="ThreadCount"
                               Expression={$_.Threads.Count}
                           }

Bestimmten Prozess prüfen:

[RO] Get-Process -Id <PID> |
    Select-Object Id,
                  ProcessName,
                  HandleCount,
                  @{
                      Name="ThreadCount"
                      Expression={$_.Threads.Count}
                  }

Ein mögliches Ressourcenleck zeigt sich eher durch kontinuierliches Wachstum als durch einen einzelnen hohen Wert.

12. Windows-Protokolle nach Ressourcenfehlern durchsuchen

Systemereignisse der letzten zwei Stunden:

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

System- und Anwendungsereignisse gemeinsam:

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = "System", "Application"
    StartTime = (Get-Date).AddHours(-2)
} |
    Where-Object Message -Match "memory|resource|disk|paging|quota|handle|thread" |
    Sort-Object TimeCreated |
    Select-Object TimeCreated,
                  LogName,
                  ProviderName,
                  Id,
                  Message

Textfilter hängen von Sprache und Formulierung der Ereignismeldung ab. Anbieter, Ereignis-ID und Zeitfenster sind zuverlässigere zusätzliche Filter.

13. CPU und Load Average unter Linux prüfen

Systemlaufzeit und Load Average anzeigen:

[RO] uptime

Nur Load Average anzeigen:

[RO][FILE] cat /proc/loadavg

Anzahl verfügbarer Verarbeitungseinheiten anzeigen:

[RO] nproc

Interaktive Prozessübersicht:

[RO] top

Nach CPU-Verbrauch sortieren:

[RO] ps -eo pid,ppid,user,stat,%cpu,%mem,etime,comm \
  --sort=-%cpu |
  head -n 16

Falls sysstat installiert ist – CPU je Prozessor messen:

[RO] mpstat -P ALL 2 5

mpstat, pidstat und iostat gehören häufig zum Paket sysstat, sind aber nicht auf jeder Installation vorhanden.

14. Linux Load Average richtig interpretieren

Die drei Load-Average-Werte beziehen sich üblicherweise auf ungefähr:

1 Minute
5 Minuten
15 Minuten

Load Average ist nicht dasselbe wie CPU-Prozent. Unter Linux werden dabei auch bestimmte Prozesse in nicht unterbrechbarem Wartezustand berücksichtigt.

Grobe Einordnung:

Load Average
geteilt durch
Anzahl verfügbarer CPUs

Dies ist nur eine Orientierung.

Beobachtung Mögliche Interpretation
Hoher Load und hohe CPU-Nutzung CPU-Sättigung möglich
Hoher Load und niedrige CPU-Nutzung I/O-Wartezustände möglich
Kurzzeitig hoher 1-Minuten-Wert Lastspitze
Hohe 1-, 5- und 15-Minuten-Werte Länger andauernde Belastung
Load steigt, Warteschlange wächst System verarbeitet Arbeit nicht schnell genug

Ein Load-Wert von 4 ist auf einem System mit zwei CPUs anders zu bewerten als auf einem System mit 32 CPUs.

15. Linux-CPU über mehrere Messpunkte prüfen

Systemweite Messreihe mit vmstat:

[RO] vmstat 2 5

Wichtige Spalten:

Spalte Bedeutung
r Ausführungsbereite Prozesse
b Prozesse in blockiertem Zustand
us CPU-Zeit im Benutzerbereich
sy CPU-Zeit im Kernelbereich
id Leerlauf
wa I/O-Wartezeit
st Durch Hypervisor entnommene CPU-Zeit
si Swap-In
so Swap-Out

Die erste Zeile von vmstat kann Durchschnittswerte seit dem Systemstart darstellen. Für eine aktuelle Bewertung sind die folgenden Intervallzeilen wichtiger.

Bestimmten Prozess mit installiertem pidstat beobachten:

[RO] pidstat -p <PID> 2 5

Alle Prozesse mit hoher CPU-Aktivität beobachten:

[RO] pidstat -u 2 5
16. Arbeitsspeicher unter Linux prüfen

Lesbare Speicherübersicht:

[RO] free -h

Kernel-Speicherinformationen:

[RO][FILE] cat /proc/meminfo

Wichtige Werte:

Wert Bedeutung
MemTotal Gesamter physischer Speicher
MemFree Vollständig ungenutzter Speicher
MemAvailable Schätzung des für neue Anwendungen verfügbaren Speichers
Buffers Pufferspeicher
Cached Dateicache
SwapTotal Gesamter Swap
SwapFree Freier Swap
Dirty Noch nicht auf Datenträger geschriebene Seiten
Slab Kernel-Datenstrukturen

Für die praktische Bewertung ist MemAvailable meist aussagekräftiger als MemFree, weil Linux freien RAM bewusst als Cache nutzt.

17. Linux-Prozesse nach Speicherverbrauch untersuchen

Nach residentem Speicher sortieren:

[RO] ps -eo pid,ppid,user,stat,%cpu,%mem,rss,vsz,etime,comm \
  --sort=-rss |
  head -n 16

Bestimmten Prozess anzeigen:

[RO][SENS] ps -p <PID> \
  -o user,pid,ppid,stat,%cpu,%mem,rss,vsz,etime,cmd

Detaillierte Prozessspeicherwerte:

[RO][FILE][SENS] cat "/proc/<PID>/status"

Relevant sind unter anderem:

VmPeak
VmSize
VmHWM
VmRSS
RssAnon
RssFile
VmSwap
Threads
Wert Bedeutung
VmSize Virtueller Adressraum
VmRSS Residenter physischer Speicher
VmHWM Bisheriger Höchstwert des residenten Speichers
VmSwap Für den Prozess ausgelagerter Speicher
Threads Threadanzahl
18. Swap und Paging unter Linux prüfen

Aktive Swap-Bereiche anzeigen:

[RO] swapon --show

Gesamtnutzung anzeigen:

[RO] free -h

Swap-Aktivität über mehrere Messpunkte:

[RO] vmstat 2 5

Relevant:

Spalte Bedeutung
si Von Swap eingelesene Daten
so In Swap geschriebene Daten

Bewertung:

19. Linux-Datenträger-I/O prüfen

Grundlegende Datenträgerstatistik:

[RO] iostat

Falls sysstat installiert ist – erweiterte Messreihe:

[RO] iostat -xz 2 5

Wichtige Felder können je nach Version enthalten:

Feld Bedeutung
r/s Lesevorgänge pro Sekunde
w/s Schreibvorgänge pro Sekunde
rkB/s Gelesene KiB pro Sekunde
wkB/s Geschriebene KiB pro Sekunde
await Durchschnittliche Wartezeit
aqu-sz Durchschnittliche Warteschlangenlänge
%util Anteil der Zeit mit aktiven I/O-Anfragen

Prozessbezogene I/O-Aktivität mit pidstat:

[RO] pidstat -d 2 5

%util und Warteschlangenwerte müssen zur Datenträgerart und Speicherarchitektur passend bewertet werden. RAID, SSD, SAN und virtuelle Datenträger verhalten sich unterschiedlich.

20. Linux Pressure Stall Information prüfen

Auf unterstützten Linux-Kernels stehen Druckinformationen unter /proc/pressure bereit.

CPU-Druck:

[RO][FILE] cat /proc/pressure/cpu

Speicherdruck:

[RO][FILE] cat /proc/pressure/memory

I/O-Druck:

[RO][FILE] cat /proc/pressure/io

Mögliche Zeilen:

some
full
Wert Bedeutung
some Mindestens eine Aufgabe wurde durch Ressourcenmangel verzögert
full Alle nicht im Leerlauf befindlichen Aufgaben waren gleichzeitig verzögert
avg10 Durchschnitt der letzten 10 Sekunden
avg60 Durchschnitt der letzten 60 Sekunden
avg300 Durchschnitt der letzten 300 Sekunden
total Kumulierte Verzögerungszeit in Mikrosekunden

Fehlen die Dateien, unterstützt oder aktiviert das System diese Schnittstelle möglicherweise nicht.

21. Linux-Dateideskriptor- und Prozessgrenzen prüfen

Grenzwerte eines laufenden Prozesses:

[RO][FILE] cat "/proc/<PID>/limits"

Besonders relevant:

Max open files
Max processes
Max locked memory
Max address space
Max core file size

Anzahl geöffneter Dateideskriptoren:

[RO][PRIV] sudo find "/proc/<PID>/fd" \
  -mindepth 1 \
  -maxdepth 1 \
  -printf '.' |
    wc -c

systemd-Grenzwerte anzeigen:

[RO] systemctl show "<DIENST>" \
  --property=LimitNOFILE,LimitNPROC,TasksCurrent,TasksMax,MemoryCurrent,MemoryMax,CPUQuotaPerSecUSec

Aktuelle Shell-Grenzen anzeigen:

[RO] ulimit -a

ulimit -a zeigt die Grenzen der aktuellen Shell und nicht automatisch die Grenzen eines bereits laufenden Dienstes.

22. Linux-Protokolle nach Ressourcenfehlern durchsuchen

Warnungen und Fehler des aktuellen Systemstarts:

[RO][SENS][PRIV] sudo journalctl \
  -b \
  -p warning \
  --no-pager

Kernelmeldungen nach Speicherproblemen durchsuchen:

[RO][SENS][PRIV] sudo journalctl \
  -k \
  -b \
  --no-pager |
    grep -i -E -- "out of memory|oom|killed process|memory cgroup"

Nach I/O- und Dateisystemproblemen suchen:

[RO][SENS][PRIV] sudo journalctl \
  -k \
  -b \
  --no-pager |
    grep -i -E -- "i/o error|filesystem|read-only|blocked for more than"

Dienstprotokoll im Störungszeitraum:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  --since "2026-07-31 09:10:00" \
  --until "2026-07-31 09:20:00" \
  --no-pager
23. CPU und Load Average unter macOS prüfen

Systemlaufzeit und Load Average:

[RO] uptime

Logische und physische CPUs:

[RO] sysctl -n hw.logicalcpu

[RO] sysctl -n hw.physicalcpu

Interaktive Übersicht nach CPU-Nutzung:

[RO] top -o cpu

Fünf Messungen im Abstand von zwei Sekunden:

[RO] top \
  -l 5 \
  -s 2 \
  -o cpu \
  -stats pid,command,cpu,mem,threads,state,time

Bestimmten Prozess beobachten:

[RO] top \
  -l 5 \
  -s 2 \
  -pid <PID> \
  -stats pid,command,cpu,mem,threads,state,time

Bei top -l kann die erste CPU-Messung ungeeignet sein, weil zur Prozentberechnung noch kein vollständiges vorheriges Intervall vorliegt.

24. Speicher unter macOS prüfen

Speicherdruck anzeigen:

[RO] memory_pressure

Virtuelle Speicherstatistik:

[RO] vm_stat

Gesamten physischen Speicher anzeigen:

[RO] sysctl -n hw.memsize

Swap-Nutzung anzeigen:

[RO] sysctl vm.swapusage

Prozesse nach Speicherverbrauch sortieren:

[RO] ps -Amcwwxo pid,ppid,user,state,%cpu,%mem,rss,vsz,etime,command

Bestimmten Prozess anzeigen:

[RO][SENS] ps -p <PID> \
  -o user,pid,ppid,state,%cpu,%mem,rss,vsz,etime,command

macOS verwaltet Arbeitsspeicher unter anderem durch Cache, Kompression und Swap. „Freier Speicher“ allein ist deshalb weniger aussagekräftig als Speicherdruck, Swap-Aktivität und Anwendungsreaktion.

25. vm_stat unter macOS interpretieren

vm_stat zeigt Speicherwerte in Seiten an. Die Seitengröße wird in der ersten Ausgabezeile genannt.

Wichtige Werte können sein:

Wert Bedeutung
Pages free Freie Seiten
Pages active Aktiv verwendete Seiten
Pages inactive Inaktive, möglicherweise wiederverwendbare Seiten
Pages speculative Spekulativ geladene Seiten
Pages wired down Nicht auslagerbarer Speicher
Pages occupied by compressor Durch Speicherkompression belegte Seiten
Pageins Vom Datenträger eingelesene Seiten
Pageouts Auf Datenträger ausgelagerte Seiten
Swapins Aus Swap eingelesene Seiten
Swapouts In Swap geschriebene Seiten

Viele Werte sind kumuliert seit dem Systemstart. Für aktuelle Aktivität müssen Messungen über einen definierten Zeitraum verglichen werden.

26. Datenträger-I/O unter macOS prüfen

Datenträgerübersicht:

[RO] iostat

Fünf Messungen im Abstand von zwei Sekunden:

[RO] iostat -w 2 -c 5

CPU- und Datenträgerstatistik ausführlicher anzeigen:

[RO] iostat -d -c 5 -w 2

Prozessbezogene Beobachtung mit top:

[RO] top \
  -l 5 \
  -s 2 \
  -o cpu \
  -stats pid,command,cpu,mem,purg,cmprs,pageins,faults

Zu prüfen:

27. Prozess- und Dateigrenzen unter macOS prüfen

Grenzwerte von launchd anzeigen:

[RO] launchctl limit

Grenzwerte der aktuellen Shell anzeigen:

[RO] ulimit -a

Offene Ressourcen eines Prozesses anzeigen:

[RO][SENS][PRIV] sudo lsof -nP -p <PID>

Anzahl der ausgegebenen offenen Ressourcen grob zählen:

[RO][SENS][PRIV] sudo lsof -nP -p <PID> |
    wc -l

Die Kopfzeile von lsof wird dabei mitgezählt.

Threadanzahl anzeigen:

[RO] ps -M -p <PID>

Die Grenzwerte einer Shell sind nicht automatisch mit denen eines launchd-Dienstes identisch. Für den Dienst müssen launchd-Konfiguration, Prozesskontext und tatsächlicher Verbrauch berücksichtigt werden.

28. macOS-Protokolle nach Ressourcenproblemen prüfen

Fehler und Faults der letzten Stunde:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate 'messageType == error OR messageType == fault' \
  --style compact \
  --no-pager

Dienstprozess filtern:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate 'process == "<PROZESS>"' \
  --style compact \
  --no-pager

Nach ressourcenbezogenen Meldungstexten suchen:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate 'eventMessage CONTAINS[c] "memory" OR eventMessage CONTAINS[c] "resource" OR eventMessage CONTAINS[c] "disk"' \
  --style compact \
  --no-pager

Textfilter sind nur eine Ergänzung. Prozess, Zeitfenster, Subsystem und konkrete Fehlermeldung müssen ebenfalls berücksichtigt werden.

29. CPU-Engpass systematisch erkennen

Belastbare Hinweise:

Mögliche Ursachen:

Nicht ausreichend als Beweis:

Ein einzelner Messwert von 100 %
30. Arbeitsspeicherengpass systematisch erkennen

Belastbare Hinweise:

Mögliche Ursachen:

Ein Dienstneustart kann den Speicherverbrauch kurzfristig reduzieren, beweist aber nicht, dass die Ursache beseitigt wurde.

31. I/O-Engpass systematisch erkennen

Belastbare Hinweise:

Mögliche Ursachen:

Hoher Datendurchsatz kann normal sein. Ein Engpass zeigt sich durch Wartezeit, Warteschlange und beeinträchtigte Anwendung.

32. Ressourcenleck erkennen

Ein Ressourcenleck wird durch eine Zeitreihe sichtbar.

Mögliche Lecks:

Typisches Muster:

Dienststart          niedriger Verbrauch
nach 1 Stunde        höherer Verbrauch
nach 6 Stunden       weiter gestiegen
nach 24 Stunden      Grenzwert erreicht
nach Dienstneustart  wieder niedriger Verbrauch

Nachweisstrategie:

  1. gleiche Messgröße verwenden,
  2. regelmäßige Zeitpunkte erfassen,
  3. Last und Benutzerzahl mit dokumentieren,
  4. Prozessneustarts berücksichtigen,
  5. Grenzwert und Fehlereintritt bestimmen,
  6. Herstellerdiagnose oder Profiler kontrolliert einsetzen.

Wachstum kann durch einen vorgesehenen Cache entstehen. Ein Leck ist erst wahrscheinlich, wenn Ressourcen trotz abgeschlossener Arbeit nicht angemessen freigegeben werden und der Verbrauch problematisch weiter steigt.

33. Virtualisierung und Containerlimits berücksichtigen

Ein Gastbetriebssystem kann normale Hostwerte anzeigen, obwohl die Virtualisierungsplattform Ressourcen begrenzt.

Zu prüfen:

Typische Fehlinterpretation:

„Der Host hat noch freien RAM, deshalb kann der Container keinen Speichermangel haben.“

Ein Container kann sein eigenes Limit erreichen, obwohl der Host noch freie Ressourcen besitzt.

34. Engpass anhand einer Vergleichsmatrix eingrenzen
CPU RAM I/O-Wartezeit Mögliche Richtung
Hoch Normal Niedrig CPU-intensive Verarbeitung
Niedrig Knapp Hoch Paging oder Speicherdruck
Niedrig Normal Hoch Datenträger- oder Netzwerkstorage
Hoch Knapp Hoch Gesamtsystem überlastet
Niedrig Normal Niedrig Externes Backend, Sperre oder Anwendung
Normal Verbrauch steigt Zunehmend Mögliches Speicherleck
Normal Normal Normal Anwendungs-, Netzwerk- oder Konfigurationsfehler

Diese Matrix ist eine Eingrenzungshilfe und kein automatischer Ursachenbeweis.

35. Typische Fehlinterpretationen
Fehlinterpretation Richtige Bewertung
„100 Prozent CPU bedeutet immer einen Fehler.“ Kurze oder produktive Vollauslastung kann normal sein
„Freier RAM ist niedrig, also fehlt Speicher.“ Cache und verfügbarer Speicher müssen berücksichtigt werden
„Swap wird verwendet, also ist das System überlastet.“ Aktuelle Swap-Aktivität und Speicherdruck sind entscheidend
„Hoher Datendurchsatz bedeutet I/O-Engpass.“ Wartezeit und Warteschlange sind entscheidender
„Load Average entspricht CPU-Prozent.“ Load berücksichtigt unter Linux weitere Wartezustände
„Die erste vmstat-Zeile zeigt die aktuelle Last.“ Sie kann Durchschnittswerte seit dem Start enthalten
„Get-Process CPU ist der aktuelle Prozentwert.“ Es ist kumulierte CPU-Zeit
„Virtueller Speicher ist vollständig belegter RAM.“ Virtueller Adressraum und residenter Speicher unterscheiden sich
„Ein Neustart behebt das Ressourcenproblem.“ Er kann Zähler und Verbrauch nur vorübergehend zurücksetzen
„Der Host hat Ressourcen, also hat der Container sie ebenfalls.“ Container und VM können eigene Limits besitzen
36. Dokumentationsvorlage für Ressourcenengpässe 
Störung:
Server:
Dienst:
Prozess und PID:
Betriebssystem:
Virtualisiert beziehungsweise containerisiert:
Messzeitraum:
Abtastintervall:
CPU gesamt:
CPU des Prozesses:
Load Average:
Verfügbarer Arbeitsspeicher:
Speicher des Prozesses:
Swap- beziehungsweise Paging-Aktivität:
Datenträgerlatenz:
Datenträgerwarteschlange:
Dateideskriptor- beziehungsweise Handleanzahl:
Threadanzahl:
Konfigurierte Limits:
Anwendungsantwortzeit:
Fehlerrate:
Gleichzeitige Benutzer oder Aufgaben:
Relevante Protokollmeldung:
Vergleichswert:
Bewertung:
Nächster Prüfschritt:
37. Checkliste zur Ressourcenanalyse 
[ ] Störungszeitraum genau bestimmt
[ ] System- und Prozesswerte getrennt erfasst
[ ] Mehrere Messpunkte aufgenommen
[ ] Normalen Vergleichszeitraum bestimmt
[ ] Anzahl logischer CPUs berücksichtigt
[ ] CPU-Auslastung und Warteschlange geprüft
[ ] Load Average richtig eingeordnet
[ ] Verfügbaren Arbeitsspeicher geprüft
[ ] Prozessspeicher geprüft
[ ] Paging beziehungsweise Swapping geprüft
[ ] Speicherdruck berücksichtigt
[ ] Datenträgerdurchsatz geprüft
[ ] I/O-Wartezeit und Warteschlange geprüft
[ ] Speicherplatz und Dateisystem grob geprüft
[ ] Handle- beziehungsweise Dateideskriptoranzahl geprüft
[ ] Thread- und Prozessgrenzen geprüft
[ ] Ressourcenlecks über Zeitreihe geprüft
[ ] Betriebssystemprotokolle geprüft
[ ] Anwendungsprotokolle geprüft
[ ] VM- und Containerlimits berücksichtigt
[ ] Gleichzeitige Sicherungen und Updates berücksichtigt
[ ] Messwerte mit Antwortzeit und Fehlerrate korreliert
[ ] Noch keine ungeprüfte Limitänderung durchgeführt
[ ] Ursache und nächster Schritt dokumentiert

Bewertung des Ergebnisses

Ergebnis Nächster Schritt
CPU dauerhaft gesättigt Verursachenden Prozess, Threads und Arbeitslast untersuchen
Hoher Load bei niedriger CPU I/O-Wartezustände und blockierte Prozesse prüfen
Speicherdruck und aktives Swapping Prozessspeicher, Limits und mögliches Leck untersuchen
Prozessverbrauch steigt kontinuierlich Zeitreihe und Herstellerdiagnose erstellen
Datenträgerlatenz erhöht Datenträger, Dateisystem, Storage und konkurrierende Last prüfen
Dateideskriptor- oder Handlegrenze erreicht Leck, Grenzwert und benötigte Kapazität untersuchen
Containerlimit erreicht Sollressourcen und Plattformkonfiguration prüfen
Host überlastet Andere VMs, Container und Hostprozesse berücksichtigen
Ressourcenwerte normal Abhängigkeiten, Sperren, Netzwerk und Anwendung untersuchen
Speicherplatz oder Dateisystem auffällig Mit Seite 4.11 detailliert weiterprüfen

Merksatz

Ein Ressourcenengpass wird nicht durch einen hohen Wert bewiesen, sondern durch dauerhaftes Warten, erreichte Grenzen und eine gleichzeitig beeinträchtigte Dienstfunktion.

Weiterführende Quellen

4. Server- und Dienstfehler systematisch analysieren

4.11 Speicherplatz- und Dateisystemfehler

Speicherplatzprobleme gehören zu den häufigsten Ursachen für Dienststörungen. Dabei muss ein Datenträger nicht vollständig belegt sein: Auch ausgeschöpfte Benutzerquoten, fehlende Inodes, schreibgeschützte Dateisysteme, Snapshots, nicht eingehängte Volumes oder Ein-/Ausgabefehler können Schreibvorgänge verhindern.

Typische Auswirkungen sind:

Wichtig: Freier Speicherplatz allein reicht nicht als Prüfung. Untersucht werden müssen Kapazität, Inodes, Quoten, Einhängezustand, Schreibbarkeit, Dateisystemzustand und die zugrunde liegende Speicherhardware.

Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] Nur lesender Befehl
[TEST] Führt eine aktive Prüfung aus
[PRIV] Erhöhte Berechtigungen erforderlich
[FILE] Liest Dateien oder Verzeichnisse ein
[SENS] Ausgabe kann sensible Informationen enthalten
[CHANGE] Verändert Daten oder Systemzustand
[DISRUPT] Kann den Betrieb unterbrechen
1. Fehlerbild und betroffenen Speicherpfad bestimmen

Zuerst muss festgestellt werden, welcher konkrete Pfad nicht mehr funktioniert. Die Meldung „Datenträger voll“ sagt noch nicht, welches Volume, Dateisystem oder Speichersystem betroffen ist.

Zu klären sind:

Typische Fehlermeldungen

Fehlermeldung Mögliche Ursache
No space left on device Speicherplatz oder Inodes ausgeschöpft
Disk full Datenträger, Quote oder Speicherpool voll
Read-only file system Dateisystem schreibgeschützt eingebunden
Input/output error Dateisystem-, Datenträger- oder Controllerfehler
Access denied Berechtigung, Quote oder schreibgeschützter Pfad
File system is corrupt Inkonsistente Dateisystemstrukturen
The volume is dirty Dateisystem wurde nicht sauber getrennt oder weist Fehler auf
Datei oder Verzeichnis fehlt Volume möglicherweise nicht eingehängt
Schreiben funktioniert nur als Administrator Quote, Berechtigung oder reservierter Speicherbereich
Freier Speicher wird nach dem Löschen nicht größer Datei noch geöffnet, Snapshot oder Papierkorb

Prüffragen

Ein Schreibtest darf nur in einem dafür vorgesehenen Verzeichnis durchgeführt werden. In Anwendungs-, Datenbank- oder Systemverzeichnissen dürfen nicht unkontrolliert Testdateien angelegt werden.

2. Speicherschichten systematisch eingrenzen

Zwischen einer Anwendung und dem physischen Datenträger können mehrere Speicherschichten liegen:

  1. Anwendung oder Dienst
  2. Datei und Verzeichnis
  3. Dateisystem
  4. Partition oder Volume
  5. LVM-, Storage-Spaces- oder APFS-Container
  6. Virtueller Datenträger
  7. RAID, SAN, NAS oder Hypervisor-Datastore
  8. Controller und physischer Datenträger

Ein Fehler kann auf jeder dieser Ebenen auftreten.

Beobachtung Wahrscheinliche Ebene
Nur eine Anwendung kann nicht schreiben Anwendung, Pfad, Berechtigung oder Quote
Alle Anwendungen auf einem Volume sind betroffen Dateisystem oder Volume
Volume fehlt nach einem Neustart Mount-, Geräte- oder Konfigurationsfehler
Mehrere virtuelle Maschinen sind betroffen Hypervisor, Datastore, SAN oder NAS
Betriebssystem meldet Ein-/Ausgabefehler Datenträger, Controller oder Speicherverbindung
Gastbetriebssystem zeigt freien Platz, Datastore ist voll Virtualisierungs- oder Thin-Provisioning-Ebene
Netzfreigabe ist betroffen, lokaler Speicher funktioniert Netzwerkdateisystem oder Speicherserver

Besonderheit bei Thin Provisioning

Bei dynamisch bereitgestelltem Speicher können unterschiedliche Ansichten entstehen:

Deshalb müssen bei virtuellen Servern sowohl das Betriebssystem als auch Hypervisor und Speicherplattform kontrolliert werden.

3. Speicherbelegung unter Windows prüfen

Volumes und freien Speicher anzeigen

[RO] Get-Volume |
    Select-Object DriveLetter, FileSystemLabel, FileSystem,
        HealthStatus, OperationalStatus, SizeRemaining, Size

Belegung in Prozent berechnen

[RO] Get-Volume |
    Where-Object { $_.Size -gt 0 } |
    Select-Object DriveLetter, FileSystemLabel,
        @{Name='Belegt_GB';Expression={[math]::Round(($_.Size-$_.SizeRemaining)/1GB,2)}},
        @{Name='Frei_GB';Expression={[math]::Round($_.SizeRemaining/1GB,2)}},
        @{Name='Belegt_Prozent';Expression={[math]::Round((($_.Size-$_.SizeRemaining)/$_.Size)*100,1)}}

Datenträger anzeigen

[RO] Get-Disk |
    Select-Object Number, FriendlyName, PartitionStyle,
        OperationalStatus, HealthStatus, Size

Partitionen anzeigen

[RO] Get-Partition |
    Select-Object DiskNumber, PartitionNumber, DriveLetter,
        Type, Size, OperationalStatus

Informationen zu einem bestimmten Volume

[RO] Get-Volume -DriveLetter <BUCHSTABE>

Beispiel:

[RO] Get-Volume -DriveLetter C

NTFS-Dirty-Bit abfragen

[RO][PRIV] fsutil dirty query <LAUFWERK>:

Beispiel:

[RO][PRIV] fsutil dirty query C:

NTFS-Quoten abfragen

[RO][PRIV][SENS] fsutil quota query <LAUFWERK>:

Beispiel:

[RO][PRIV][SENS] fsutil quota query D:

Große Dateien in einem bekannten Verzeichnis suchen

[TEST][FILE][SENS] Get-ChildItem -LiteralPath "<PFAD>" -File -Recurse -ErrorAction SilentlyContinue |
    Sort-Object Length -Descending |
    Select-Object -First 20 FullName,
        @{Name='Groesse_GB';Expression={[math]::Round($_.Length/1GB,2)}}

Eine rekursive Suche kann auf großen Verzeichnissen, Dateiservern oder langsamen Datenträgern erhebliche Last und lange Laufzeiten verursachen. Die Suche sollte auf den betroffenen Pfad begrenzt werden.

Typische Windows-Ursachen

4. Speicherbelegung unter Linux prüfen

Kapazität und Dateisystemtyp anzeigen

[RO] df -hT

Belegung für einen bestimmten Pfad anzeigen

[RO] df -hT "<PFAD>"

Inode-Belegung anzeigen

[RO] df -i

Blockgeräte und Dateisysteme anzeigen

[RO] lsblk -f

Eingehängte Dateisysteme übersichtlich anzeigen

[RO] findmnt

Zugehöriges Dateisystem eines Pfades ermitteln

[RO] findmnt --target "<PFAD>"

Mount-Optionen eines Pfades anzeigen

[RO] findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS --target "<PFAD>"

Größe eines bestimmten Verzeichnisses ermitteln

[TEST][FILE] du -sh "<PFAD>"

Direkte Unterverzeichnisse nach Größe sortieren

[TEST][FILE][PRIV][SENS] sudo du -xhd1 "<PFAD>" | sort -h

Bedeutung von -x:

Benutzerquote anzeigen, sofern Quoten eingerichtet sind

[RO][SENS] quota -s

Quota-Bericht für Dateisysteme anzeigen

[RO][PRIV][SENS] sudo repquota -a

Die Programme quota und repquota sind nicht auf jedem Linux-System standardmäßig installiert. Zudem müssen Quoten auf dem betreffenden Dateisystem eingerichtet sein.

Typische Linux-Ursachen

du liest Verzeichnisstrukturen ein und kann auf großen Dateisystemen viel Ein-/Ausgabelast erzeugen. Auf Produktivsystemen sollte die Untersuchung auf kleine und verdächtige Pfade begrenzt werden.

5. Speicherbelegung unter macOS prüfen

Belegung der Dateisysteme anzeigen

[RO] df -h

Belegung für einen bestimmten Pfad anzeigen

[RO] df -h "<PFAD>"

Datenträger und Volumes anzeigen

[RO] diskutil list

Informationen über ein Volume oder Gerät anzeigen

[RO] diskutil info "<VOLUME-ODER-GERÄT>"

Beispiele:

[RO] diskutil info /

[RO] diskutil info disk3

APFS-Container und Volumes anzeigen

[RO] diskutil apfs list

Lokale Time-Machine-Snapshots anzeigen

[RO] tmutil listlocalsnapshots /

Größe eines Verzeichnisses ermitteln

[TEST][FILE] du -sh "<PFAD>"

Direkte Unterverzeichnisse nach Größe sortieren

[TEST][FILE][PRIV][SENS] sudo du -xhd 1 "<PFAD>" | sort -h

Besonderheit bei APFS

Mehrere APFS-Volumes können sich den freien Speicherplatz eines gemeinsamen Containers teilen. Deshalb darf die Belegung einzelner APFS-Volumes nicht wie bei vollständig getrennten Partitionen addiert werden.

Zusätzlich können für APFS-Volumes eingerichtet sein:

Typische macOS-Ursachen

6. Inode-Erschöpfung unter Linux erkennen

Linux-Dateisysteme verwenden Inodes zur Verwaltung von Dateien und Verzeichnissen. Ein Dateisystem kann noch freien Speicherplatz besitzen und trotzdem keine neuen Dateien mehr anlegen, wenn keine freien Inodes verfügbar sind.

Inode-Belegung prüfen

[RO] df -i

Beispielhafte Interpretation:

Speicherplatz Inodes Bedeutung
100 % belegt Frei Kapazitätsproblem
Frei 100 % belegt Zu viele Dateien beziehungsweise Inode-Problem
100 % belegt 100 % belegt Kapazität und Inodes ausgeschöpft
Frei Frei Andere Ursache untersuchen

Typische Verursacher einer Inode-Erschöpfung

Anzahl der Einträge unter einem begrenzten Pfad ermitteln

[TEST][FILE][SENS] find "<PFAD>" -xdev -printf '.' | wc -c

Das Durchsuchen sehr großer Verzeichnisbäume kann erhebliche Last verursachen. Der Befehl sollte nicht unkontrolliert auf dem gesamten Root-Dateisystem ausgeführt werden.

Auf Windows mit NTFS und macOS mit APFS wird eine klassische Inode-Erschöpfung normalerweise nicht auf dieselbe Weise diagnostiziert. Dort stehen Kapazität, Quoten, Dateisystemmetadaten und Containergrenzen im Vordergrund.

7. Gelöschte, aber noch geöffnete Dateien untersuchen

Unter Linux und macOS kann ein Prozess eine Datei weiterhin geöffnet halten, nachdem sie aus dem Verzeichnis gelöscht wurde. Der Dateiname ist dann nicht mehr sichtbar, die Datenblöcke bleiben aber belegt, bis der Prozess die Datei schließt.

Das kommt häufig bei Protokolldateien vor:

  1. Eine große Protokolldatei wird gelöscht.
  2. Der Dienst schreibt weiterhin in den offenen Dateideskriptor.
  3. du findet die Datei nicht mehr.
  4. df zeigt weiterhin den belegten Speicher.
  5. Erst nach dem Schließen der Datei wird der Platz freigegeben.

Linux und macOS

[RO][PRIV][SENS] sudo lsof +L1

Wichtige Spalten:

Spalte Bedeutung
COMMAND Prozessname
PID Prozess-ID
USER Prozessbenutzer
FD Dateideskriptor
SIZE/OFF Größe beziehungsweise Dateiposition
NAME Dateiname, häufig mit Hinweis auf Löschung

Sinnvolle Reaktion

Einen Prozess nur zum Freigeben von Speicher zu beenden, kann einen Dienstausfall oder Datenverlust verursachen. Zuerst müssen Dienst, Kritikalität und Abhängigkeiten geprüft werden.

Unter Windows werden geöffnete Dateien anders behandelt. Eine regulär geöffnete Datei kann dort häufig nicht ohne Weiteres gelöscht werden. Zur Analyse können beispielsweise Ressourcenmonitor, Process Explorer oder anwendungsspezifische Werkzeuge verwendet werden.

8. Schreibgeschützte und falsch eingehängte Dateisysteme erkennen

Ein Dateisystem kann vorhanden und lesbar sein, Schreibzugriffe aber verweigern. Linux kann ein fehlerhaftes Dateisystem abhängig von Konfiguration und Fehlertyp schreibgeschützt erneut einhängen.

Linux: Mount-Optionen eines Pfades prüfen

[RO] findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS --target "<PFAD>"

In der Ausgabe bedeuten:

Option Bedeutung
rw Lesen und Schreiben
ro Nur Lesen
noexec Ausführung von Programmen nicht erlaubt
nosuid SUID- und SGID-Bits werden nicht berücksichtigt
nodev Gerätedateien werden nicht interpretiert

Linux: Kernelmeldungen prüfen

[RO][PRIV][SENS] sudo journalctl -k -b -p warning --no-pager

Gezielt nach speicherbezogenen Meldungen suchen:

[RO][PRIV][SENS] sudo journalctl -k -b --no-pager |
    grep -Ei 'I/O error|filesystem|read-only|corrupt|ext4|xfs|btrfs|nvme|ata|scsi'

macOS: Eingehängte Dateisysteme anzeigen

[RO] mount

macOS: Volume-Informationen anzeigen

[RO] diskutil info "<VOLUME-ODER-GERÄT>"

Windows: Volumezustand anzeigen

[RO] Get-Volume |
    Select-Object DriveLetter, FileSystemLabel,
        HealthStatus, OperationalStatus

Wichtige Unterscheidung

Ein Schreibfehler kann verursacht werden durch:

Ein Berechtigungsfehler sollte deshalb nicht automatisch durch das Erteilen weitreichender Rechte „behoben“ werden.

9. Snapshots, Schattenkopien und gemeinsam genutzten Speicher prüfen

Snapshots können Speicherplatz belegen, obwohl die sichtbaren Dateien wenig Platz benötigen. Beim Ändern oder Löschen von Dateien müssen ältere Datenblöcke möglicherweise für den Snapshot erhalten bleiben.

Windows: Schattenkopien anzeigen

[RO][PRIV] vssadmin list shadows

Windows: Schattenkopiespeicher anzeigen

[RO][PRIV] vssadmin list shadowstorage

macOS: lokale Time-Machine-Snapshots anzeigen

[RO] tmutil listlocalsnapshots /

macOS: APFS-Struktur anzeigen

[RO] diskutil apfs list

Linux

Abhängig von der Speichertechnik kommen unterschiedliche Werkzeuge zum Einsatz:

Technik Typische Prüfung
LVM [RO][PRIV] sudo lvs
Btrfs [RO][PRIV] sudo btrfs filesystem usage "<PFAD>"
ZFS [RO] zfs list
ZFS-Snapshots [RO] zfs list -t snapshot

Diese Werkzeuge stehen nur zur Verfügung, wenn die jeweilige Speichertechnik installiert und verwendet wird.

Snapshots dürfen nicht allein aufgrund ihres Alters gelöscht werden. Vorher ist zu prüfen:

10. Dateisystemzustand unter Windows prüfen

Onlineprüfung mit CHKDSK

[TEST][PRIV] chkdsk <LAUFWERK>: /scan

Beispiel:

[TEST][PRIV] chkdsk C: /scan

Onlineprüfung mit PowerShell

[TEST][PRIV] Repair-Volume -DriveLetter <BUCHSTABE> -Scan

Beispiel:

[TEST][PRIV] Repair-Volume -DriveLetter D -Scan

NTFS-Selbstreparaturstatus abfragen

[RO][PRIV] fsutil repair query <LAUFWERK>:

Systemprotokoll nach Speichermeldungen durchsuchen

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    StartTime = (Get-Date).AddHours(-24)
} |
Where-Object {
    $_.ProviderName -match 'Disk|Ntfs|volmgr|volsnap|storport'
} |
Select-Object TimeCreated, LevelDisplayName, ProviderName, Id, Message

Die tatsächlich verwendeten Anbieter können je nach Windows-Version, Treiber und Speicherhardware abweichen.

Reparaturbefehle nur geplant einsetzen

[CHANGE][DISRUPT][PRIV] chkdsk <LAUFWERK>: /f

[CHANGE][DISRUPT][PRIV] Repair-Volume -DriveLetter <BUCHSTABE> -OfflineScanAndFix

Diese Befehle können:

Vor einer Reparatur müssen Sicherung, Wartungsfenster, betroffene Dienste und Wiederherstellungsweg geklärt sein.

11. Dateisystemzustand unter Linux prüfen

Zuerst muss der Dateisystemtyp bestimmt werden:

[RO] findmnt -no SOURCE,FSTYPE,TARGET --target "<PFAD>"

oder:

[RO] lsblk -f

Kernelmeldungen untersuchen

[RO][PRIV][SENS] sudo journalctl -k -b -p warning --no-pager

Anzeigen, welchen Prüfbefehl fsck verwenden würde

[RO][PRIV] sudo fsck -N "<GERÄT>"

Beispiel:

[RO][PRIV] sudo fsck -N /dev/sdb1

-N zeigt an, welche Aktion vorgesehen wäre, ohne die Dateisystemprüfung auszuführen.

Wichtige Sicherheitsregel

Eine tatsächliche Dateisystemreparatur darf nicht unkontrolliert auf einem eingehängten Produktivdateisystem durchgeführt werden.

[CHANGE][DISRUPT][PRIV] sudo fsck "<GERÄT>"

Vorher müssen mindestens geklärt sein:

Bei XFS, Btrfs, ZFS und anderen Dateisystemen gelten eigene Prüf- und Reparaturverfahren. Ein generisches fsck ist nicht für jedes Dateisystem die richtige Reparaturmethode.

12. Dateisystemzustand unter macOS prüfen

Volume überprüfen

[TEST][PRIV] sudo diskutil verifyVolume "<VOLUME>"

Beispiel:

[TEST][PRIV] sudo diskutil verifyVolume /

Physisches Gerät und Volume-Struktur anzeigen

[RO] diskutil list

[RO] diskutil info "<VOLUME-ODER-GERÄT>"

Reparatur eines Volumes

[CHANGE][DISRUPT][PRIV] sudo diskutil repairVolume "<VOLUME>"

Eine Reparatur des Startvolumes sollte nicht unkontrolliert im laufenden Produktivbetrieb erfolgen. Apple empfiehlt für die Prüfung und Reparatur des Startdatenträgers die macOS-Wiederherstellung und das Festplattendienstprogramm.

Vorher sind erforderlich:

Das Festplattendienstprogramm kann nicht alle Hardware- oder Dateisystemprobleme erkennen beziehungsweise reparieren. Wiederkehrende Fehler können auf einen ausfallenden Datenträger hinweisen.

13. Datenträger- und Ein-/Ausgabefehler erkennen

Ein volles Dateisystem und ein defekter Datenträger sind unterschiedliche Fehlerklassen. Meldungen wie I/O error, Zeitüberschreitungen, Zurücksetzungen eines Controllers oder wiederholte Dateisystembeschädigungen weisen auf eine tiefere Speicherstörung hin.

Windows

[RO] Get-Disk |
    Select-Object Number, FriendlyName, OperationalStatus,
        HealthStatus, Size

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    StartTime = (Get-Date).AddHours(-24)
} |
Where-Object {
    $_.ProviderName -match 'Disk|Ntfs|storport|stornvme|volmgr'
} |
Select-Object TimeCreated, LevelDisplayName, ProviderName, Id, Message

Linux

[RO][PRIV][SENS] sudo journalctl -k -b --no-pager |
    grep -Ei 'I/O error|timeout|reset|corrupt|nvme|ata|scsi|blk_update'

Falls smartmontools installiert ist und das Gerät SMART-Daten bereitstellt:

[RO][PRIV][SENS] sudo smartctl -a "<GERÄT>"

macOS

[RO] diskutil info "<GERÄT>"

Je nach Datenträger und Anschluss kann ein SMART-Status angezeigt werden. Externe USB-Gehäuse und Speicheradapter geben SMART-Daten nicht immer an das Betriebssystem weiter.

Hinweise auf einen möglichen Hardwarefehler

Bei Verdacht auf einen ausfallenden Datenträger hat die Sicherung beziehungsweise kontrollierte Datenrettung Vorrang vor wiederholten Reparaturversuchen.

14. Abweichung zwischen df, du und sichtbaren Dateien erklären

Unter Linux und macOS können verschiedene Werkzeuge unterschiedliche Werte anzeigen.

Werkzeug Misst hauptsächlich
df Belegte und freie Blöcke des Dateisystems
du Über Verzeichniseinträge erreichbare Dateien
lsof +L1 Gelöschte, aber weiterhin geöffnete Dateien
Snapshot-Werkzeug Durch Snapshots erhaltene Daten
Quota-Werkzeug Benutzer- oder Gruppenverbrauch
Storage-Plattform Physische oder bereitgestellte Speicherkapazität

Mögliche Ursachen für unterschiedliche Werte

Verdeckte Dateien unter einem Mountpoint

Wenn Dateien in einem Verzeichnis liegen und anschließend ein anderes Dateisystem auf dieses Verzeichnis eingehängt wird, sind die ursprünglichen Dateien weiterhin vorhanden, aber im normalen Verzeichnisbaum nicht sichtbar.

Zur Untersuchung muss der Mountpoint kontrolliert und das darunterliegende Dateisystem in einem geplanten Wartungsfenster separat betrachtet werden. Ein Produktivvolume darf nicht allein zu Diagnosezwecken unkontrolliert ausgehängt werden.

15. Typische Fehlinterpretationen vermeiden
Fehlinterpretation Richtige Bewertung
„Es sind noch 5 GB frei, also ist alles in Ordnung.“ Freier Platz muss relativ zu Wachstum, Anwendung und Dateisystemgröße bewertet werden.
„Die Datei wurde gelöscht, also ist der Platz frei.“ Ein Prozess oder Snapshot kann die Daten weiterhin festhalten.
„Das Volume ist erreichbar, also ist es beschreibbar.“ Mount-Optionen, Quoten und Berechtigungen prüfen.
„No space left bedeutet immer, dass die Festplatte voll ist.“ Unter Linux können auch Inodes erschöpft sein.
„CHKDSK oder fsck kann gefahrlos ausgeführt werden.“ Reparaturen verändern Strukturen und können den Betrieb unterbrechen.
„SMART ist unauffällig, also ist der Datenträger fehlerfrei.“ Nicht alle Fehler werden erkannt oder weitergereicht.
„Der Gastserver zeigt freien Platz, also ist der Speicher verfügbar.“ Datastore oder Storage-Pool kann trotzdem voll sein.
„Alle großen Dateien können gelöscht werden.“ Eigentümer, Zweck, Sicherung und Aufbewahrung müssen geklärt werden.
„Mehr Rechte lösen den Schreibfehler.“ Ursache kann Quote, Read-only-Zustand oder Dateisystemfehler sein.
„Eine Reparatur ersetzt die Datensicherung.“ Reparatur und Sicherung verfolgen unterschiedliche Ziele.
16. Sichere Reihenfolge der Fehleranalyse
  1. Originale Fehlermeldung und betroffenen Pfad dokumentieren.
  2. Zugehöriges Volume beziehungsweise Dateisystem bestimmen.
  3. Freien Speicherplatz und prozentuale Belegung prüfen.
  4. Unter Linux zusätzlich die Inode-Belegung prüfen.
  5. Benutzer- und Dateisystemquoten kontrollieren.
  6. Mount-, Volume- und Schreibzustand untersuchen.
  7. Wachstum nach Verzeichnis, Anwendung und Zeitpunkt eingrenzen.
  8. Snapshots und Schattenkopien berücksichtigen.
  9. Nach gelöschten, aber geöffneten Dateien suchen.
  10. System- und Kernelprotokolle auf Ein-/Ausgabefehler prüfen.
  11. Speicherhardware, RAID, Hypervisor oder SAN/NAS einbeziehen.
  12. Erst danach über Bereinigung, Erweiterung oder Reparatur entscheiden.
  13. Änderungen nur nach Sicherung, Freigabe und dokumentiertem Rückweg durchführen.
  14. Nach der Maßnahme Dienstfunktion und freien Speicher erneut prüfen.

Grundsatz für Bereinigungen

Vor dem Löschen einer Datei müssen folgende Fragen beantwortet sein:

17. Schnelle Befehlsübersicht
Aufgabe Windows Linux macOS
Volume-Belegung [RO] Get-Volume [RO] df -hT [RO] df -h
Datenträger anzeigen [RO] Get-Disk [RO] lsblk -f [RO] diskutil list
Partitionen anzeigen [RO] Get-Partition [RO] lsblk [RO] diskutil list
Dateisystem eines Pfades Volume anhand Laufwerksbuchstaben prüfen [RO] findmnt --target "<PFAD>" [RO] df -h "<PFAD>"
Mount-Optionen Nicht direkt vergleichbar [RO] findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS --target "<PFAD>" [RO] mount
Verzeichnisgröße [TEST][FILE] Get-ChildItem ... [TEST][FILE] du -sh "<PFAD>" [TEST][FILE] du -sh "<PFAD>"
Inode-Belegung Nicht vergleichbar [RO] df -i Nicht üblicherweise erforderlich
Benutzerquote [RO][PRIV] fsutil quota query <LAUFWERK>: [RO] quota -s APFS-Quote mit diskutil apfs list prüfen
Dirty-Bit [RO][PRIV] fsutil dirty query <LAUFWERK>: Nicht direkt vergleichbar Nicht direkt vergleichbar
Gelöschte offene Dateien Spezielle Prozesswerkzeuge [RO][PRIV] sudo lsof +L1 [RO][PRIV] sudo lsof +L1
Snapshots [RO][PRIV] vssadmin list shadows Abhängig von LVM, Btrfs oder ZFS [RO] tmutil listlocalsnapshots /
Dateisystemprüfung [TEST][PRIV] chkdsk <LAUFWERK>: /scan Dateisystemspezifisch; nicht auf gemountetem Produktivsystem [TEST][PRIV] sudo diskutil verifyVolume "<VOLUME>"
Systemmeldungen [RO] Get-WinEvent [RO][PRIV] sudo journalctl -k Systemprotokoll und diskutil
Hardwarezustand [RO] Get-Disk [RO][PRIV] sudo smartctl -a "<GERÄT>" [RO] diskutil info "<GERÄT>"
18. Entscheidungsmatrix
Befund Wahrscheinliche Ursache Nächster Schritt
Volume nahezu 100 % belegt Kapazitätsproblem Größte Verbraucher und Wachstum ermitteln
Speicher frei, Inodes 100 % Zu viele Dateien Verursachendes Verzeichnis und Anwendung ermitteln
Speicher frei, Benutzer kann nicht schreiben Quote oder Berechtigung Quote, Besitz und ACL prüfen
df hoch, du deutlich niedriger Offene gelöschte Datei oder Snapshot lsof +L1 und Snapshots prüfen
Volume nur lesbar Dateisystem- oder Hardwarefehler Protokolle sichern und Wartung planen
Volume nach Neustart nicht vorhanden Mount-, Geräte- oder Konfigurationsfehler Geräteerkennung und Mount-Konfiguration prüfen
Wiederkehrende I/O-Fehler Hardware, Controller oder Speicherpfad Sicherung und Storage-Eskalation
Gast hat Platz, Datastore ist voll Thin Provisioning oder Snapshot-Wachstum Hypervisor und Speicherplattform prüfen
Speicher wird schnell erneut voll Ursache nicht behoben Wachstum messen und Rotation beziehungsweise Retention korrigieren
Reparatur findet wiederholt Fehler Datenträger- oder tiefer Dateisystemschaden Daten sichern und Austausch bewerten
19. Dokumentationsvorlage 
Ticket:
Datum und Uhrzeit:
Bearbeiter:

Betroffenes System:
Betroffener Dienst:
Betroffener Benutzer:
Betroffener Pfad:
Volume beziehungsweise Dateisystem:
Dateisystemtyp:
Lokaler, virtueller oder externer Speicher:

Originale Fehlermeldung:

Gesamtkapazität:
Freier Speicher:
Belegung in Prozent:
Inode-Belegung:
Quota-Status:
Mount- beziehungsweise Volume-Status:
Schreibgeschützt:
Snapshots vorhanden:
Gelöschte offene Dateien:
Auffällige große Verzeichnisse oder Dateien:

Betriebssystemmeldungen:
Dateisystemmeldungen:
Hardware- oder Controllerfehler:
RAID-, SAN-, NAS- oder Datastore-Status:

Vermutete Ursache:
Durchgeführte Tests:
Durchgeführte Änderungen:
Sicherung geprüft:
Wartungsfenster:
Rückfallplan:

Ergebnis:
Funktionsprüfung:
Verbleibender freier Speicher:
Weiterführende Maßnahmen:

Merksatz

„Datenträger voll“ ist keine vollständige Diagnose. Ein Systemintegrator prüft Kapazität, Inodes, Quoten, Mountzustand, Snapshots, offene Dateien, Dateisystem und Speicherhardware getrennt – und repariert erst nach Sicherung und klarer Ursachenanalyse.

Quellen und weiterführende Dokumentation

4. Server- und Dienstfehler systematisch analysieren

4.12 Zeit-, Zeitzonen- und Synchronisationsfehler

Eine falsche Systemzeit kann Fehler verursachen, die zunächst wie Netzwerk-, Zertifikats-, Anmelde- oder Anwendungsprobleme wirken. Besonders in Active-Directory-Umgebungen, verteilten Systemen, Datenbanken, Clustern und virtualisierten Umgebungen ist eine zuverlässige Zeitsynchronisation entscheidend.

Typische Auswirkungen sind:

Wichtig: Datum, Uhrzeit, Zeitzone und Zeitsynchronisation sind unterschiedliche Prüfbereiche. Eine korrekt aussehende Uhrzeit bedeutet nicht automatisch, dass das System korrekt synchronisiert ist.

Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] Nur lesender Befehl
[TEST] Führt eine aktive Prüfung aus
[PRIV] Erhöhte Berechtigungen erforderlich
[SENS] Ausgabe kann sensible Informationen enthalten
[CHANGE] Verändert Konfiguration oder Systemzustand
[DISRUPT] Kann laufende Dienste oder Anwendungen beeinflussen
1. Warum eine korrekte Systemzeit wichtig ist

Viele IT-Systeme verwenden Zeitstempel nicht nur zur Anzeige, sondern als Bestandteil ihrer Sicherheits- und Ablaufsteuerung.

System oder Funktion Bedeutung der Systemzeit
Active Directory Kerberos verwendet Zeitstempel zum Schutz vor wiederholten Anmeldeversuchen
TLS und Zertifikate Gültigkeitsbeginn und Gültigkeitsende werden gegen die Systemzeit geprüft
Protokollierung Ereignisse verschiedener Systeme müssen zeitlich vergleichbar sein
Datenbanken Transaktionen, Replikation und Datensätze besitzen Zeitstempel
Sicherungen Zeitpläne und inkrementelle Sicherungen hängen von Zeitinformationen ab
MFA und TOTP Einmalpasswörter werden aus Zeitintervallen berechnet
E-Mail Nachrichten und Signaturen enthalten Zeitstempel
Monitoring Messwerte müssen in der richtigen Reihenfolge gespeichert werden
Cluster Knoten müssen Ereignisse zeitlich konsistent bewerten
Dateisynchronisation Änderungszeiten beeinflussen die Entscheidung, welche Datei neuer ist
Lizenzsysteme Lizenzen können an Zeiträume gebunden sein
Aufgabenplanung Startzeitpunkte hängen von lokaler Zeit und Zeitzone ab

Eine Zeitabweichung kann daher gleichzeitig mehrere scheinbar unabhängige Dienste beeinträchtigen.

2. Fehlerbild strukturiert aufnehmen

Zuerst muss festgestellt werden, welche Zeitinformation tatsächlich falsch ist.

Zu prüfende Fragen

Abweichungsmuster und erste Hinweise

Beobachtung Mögliche Ursache
Abweichung um genau eine Stunde Falsche Zeitzone oder Sommerzeitregel
Abweichung um mehrere volle Stunden Falsche Zeitzone
Abweichung wächst langsam Ungenaue lokale Uhr oder fehlende Synchronisation
Zeit springt nach einem Neustart zurück Hardwareuhr, Firmware, Host oder leere CMOS-Batterie
Nur virtuelle Maschinen betroffen Hypervisor-Zeitquelle oder Snapshot
Alle Domänenmitglieder betroffen Fehler in der AD-Zeithierarchie
Nur ein Domänenmitglied betroffen Lokaler Zeitdienst, Netzwerk oder Richtlinie
Uhrzeit stimmt, TLS schlägt trotzdem fehl UTC, Datum und Zertifikatszeitraum kontrollieren
Protokolle wirken zeitversetzt UTC- und Lokalzeitdarstellung vergleichen
Zeitserver ist per Ping erreichbar, Synchronisation scheitert NTP, Firewall oder Serverantwort prüfen

Eine Abweichung um eine volle Stunde deutet meistens eher auf die Zeitzone als auf eine fehlerhafte NTP-Synchronisation hin.

3. Datum, Uhrzeit und Zeitzone vergleichen

Die Werte sollten möglichst gleichzeitig auf dem betroffenen System und einem vertrauenswürdigen Vergleichssystem erfasst werden.

Aufgabe Windows Linux macOS
Lokale Zeit [RO] Get-Date -Format o [RO] date --iso-8601=seconds [RO] date "+%Y-%m-%dT%H:%M:%S%z"
UTC-Zeit [RO] (Get-Date).ToUniversalTime().ToString("o") [RO] date -u "+%Y-%m-%dT%H:%M:%SZ" [RO] date -u "+%Y-%m-%dT%H:%M:%SZ"
Zeitzone [RO] Get-TimeZone [RO] timedatectl status [RO][PRIV] sudo systemsetup -gettimezone
Zeitzonendatei Nicht zutreffend [RO] readlink -f /etc/localtime Nicht zutreffend
Hardwareuhr Nicht direkt erforderlich [RO][PRIV] sudo hwclock --show Nicht regulär erforderlich

Warum UTC und lokale Zeit getrennt geprüft werden

Beispiel

Wenn UTC korrekt ist, die lokale Zeit aber um eine Stunde abweicht, liegt die Ursache wahrscheinlich in der Zeitzone oder Sommerzeitregel und nicht in der eigentlichen Zeitsynchronisation.

4. Windows-Zeitdienst untersuchen

Windows verwendet den Dienst W32Time zur Zeitsynchronisation.

Status des Zeitdienstes prüfen

[RO] Get-Service -Name W32Time

Ausführlicher:

[RO] Get-CimInstance Win32_Service -Filter "Name='W32Time'" |
    Select-Object Name, State, StartMode, StartName, ExitCode

Aktuelle Zeitquelle anzeigen

[RO] w32tm /query /source

Synchronisationsstatus anzeigen

[RO] w32tm /query /status

Ausführlichen Status anzeigen

[RO] w32tm /query /status /verbose

Konfiguration anzeigen

[RO][SENS] w32tm /query /configuration

Konfigurierte Zeitpartner anzeigen

[RO][SENS] w32tm /query /peers

Zeitzone anzeigen

[RO] Get-TimeZone

oder:

[RO] tzutil /g

Mögliche Ausgaben bei der Zeitquelle

Ausgabe Bedeutung
Name eines Domänencontrollers Synchronisation über die AD-Zeithierarchie
Name eines NTP-Servers Direkte Synchronisation mit diesem Server
Local CMOS Clock Lokale Hardwareuhr wird verwendet
VM IC Time Synchronization Provider Zeit wird über den Hypervisor bereitgestellt
Free-running System Clock Keine geeignete externe Synchronisation

Local CMOS Clock oder Free-running System Clock ist bei einem normalen Domänenmitglied meist ein Hinweis darauf, dass die erwartete Domänenzeitquelle nicht verwendet wird. Bei isolierten Systemen kann die Bewertung anders ausfallen.

5. Windows-Zeitabweichung aktiv messen

Mit w32tm /stripchart kann die Abweichung zu einem Zeitserver gemessen werden, ohne die lokale Uhr zu verändern.

[TEST] w32tm /stripchart /computer:<ZEITSERVER> /samples:5 /dataonly

Beispiel:

[TEST] w32tm /stripchart /computer:dc01.example.local /samples:5 /dataonly

Fortlaufende Messung:

[TEST] w32tm /stripchart /computer:<ZEITSERVER> /dataonly

Die fortlaufende Ausgabe wird mit Strg + C beendet.

Wichtige Interpretation

Ergebnis Bedeutung
Kleine, stabile Abweichung Synchronisation wahrscheinlich funktionsfähig
Große, stabile Abweichung Falsche Quelle oder noch nicht korrigierte Uhr
Abweichung wächst Lokale Uhr driftet oder wird nicht nachgeregelt
Keine Antwort Name, Netzwerk, Firewall oder NTP-Dienst prüfen
Zeitüberschreitung NTP-Antwort erreicht den Client nicht

Der Test bestätigt nicht automatisch, dass Windows diese Gegenstelle als aktive Zeitquelle verwendet. Die aktive Quelle muss zusätzlich mit w32tm /query /source geprüft werden.

6. Active-Directory-Zeithierarchie verstehen

Domänenmitglieder sollten grundsätzlich der Active-Directory-Zeithierarchie folgen.

Vereinfachter Aufbau:

Externe zuverlässige Zeitquelle
              │
              ▼
PDC-Emulator der Gesamtstruktur-Stammdomäne
              │
              ▼
Weitere Domänencontroller
              │
              ▼
Mitgliedsserver und Clients

PDC-Emulator ermitteln

[RO][SENS] netdom query fsmo

Alternativ mit PowerShell:

[RO][SENS] Get-ADDomain |
    Select-Object DNSRoot, PDCEmulator

Dafür muss das ActiveDirectory-PowerShell-Modul verfügbar sein.

Domänencontroller anzeigen

[RO][SENS] nltest /dclist:<DOMÄNE>

Verwendeten Domänencontroller anzeigen

[RO][SENS] nltest /dsgetdc:<DOMÄNE>

Zeitstatus eines entfernten Windows-Systems abfragen

[RO][SENS] w32tm /query /computer:<COMPUTER> /status

Dafür sind ausreichende Berechtigungen und eine erreichbare Remoteverwaltung erforderlich.

Wichtige Regeln

7. Windows-Ereignisprotokolle auswerten

Zeitdienst-Ereignisse im Systemprotokoll anzeigen

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Microsoft-Windows-Time-Service'
    StartTime    = (Get-Date).AddHours(-24)
} |
Select-Object TimeCreated, LevelDisplayName, Id, Message

Operational-Protokoll des Zeitdienstes prüfen

[RO][SENS] Get-WinEvent -LogName `
    'Microsoft-Windows-Time-Service/Operational' `
    -ErrorAction SilentlyContinue |
Select-Object -First 100 TimeCreated, LevelDisplayName, Id, Message

Dienststatus und letzte Meldungen gemeinsam bewerten

[RO] Get-Service W32Time

[RO] w32tm /query /source

[RO] w32tm /query /status

Typische Hinweise in Ereignissen

Einzelne ältere Warnungen beweisen keine aktuelle Störung. Zeitstempel, Wiederholungsrate und aktueller Synchronisationsstatus müssen gemeinsam bewertet werden.

8. Linux mit systemd-timesyncd untersuchen

Viele Linux-Distributionen verwenden systemd-timesyncd. Andere Systeme verwenden stattdessen chrony, ntpd oder eine herstellerspezifische Lösung.

Gesamtstatus anzeigen

[RO] timedatectl status

Wichtige Felder:

Feld Bedeutung
Local time Lokale Uhrzeit
Universal time UTC-Zeit
RTC time Hardwareuhr
Time zone Aktive Zeitzone
System clock synchronized Synchronisationszustand
NTP service Status eines erkannten NTP-Dienstes
RTC in local TZ Gibt an, ob die Hardwareuhr Lokalzeit verwendet

Status der Zeitsynchronisation anzeigen

[RO] timedatectl timesync-status

Alle verfügbaren Synchronisationsinformationen anzeigen

[RO] timedatectl show-timesync --all

Dienststatus prüfen

[RO] systemctl status systemd-timesyncd --no-pager

Protokolle anzeigen

[RO][PRIV][SENS] sudo journalctl -u systemd-timesyncd \
    --since "-24 hours" --no-pager

Konfiguration anzeigen

[RO][FILE] systemd-analyze cat-config systemd/timesyncd.conf

timedatectl timesync-status und show-timesync funktionieren nur, wenn systemd-timesyncd verwendet und von der eingesetzten systemd-Version unterstützt wird. Bei chrony oder ntpd müssen deren eigene Werkzeuge verwendet werden.

9. Linux mit chrony untersuchen

Chrony wird häufig auf Linux-Servern, virtuellen Maschinen und Systemen mit unregelmäßiger Netzwerkverbindung verwendet.

Synchronisationsstatus anzeigen

[RO] chronyc tracking

Wichtige Werte:

Wert Bedeutung
Reference ID Aktuell verwendete Referenz
Stratum Entfernung zur ursprünglichen Referenzuhr
Ref time Zeitpunkt der letzten verwendeten Messung
System time Abweichung der Systemuhr
Last offset Zuletzt gemessene Abweichung
RMS offset Langfristige Abweichung
Leap status Synchronisations- beziehungsweise Schaltsekundenstatus

Zeitquellen anzeigen

[RO] chronyc sources -v

Messwerte der Quellen anzeigen

[RO] chronyc sourcestats -v

Chrony-Aktivität prüfen

[RO] chronyc activity

Dienststatus anzeigen

[RO] systemctl status chronyd --no-pager

Je nach Distribution kann der Dienst auch chrony heißen:

[RO] systemctl status chrony --no-pager

Protokolle anzeigen

[RO][PRIV][SENS] sudo journalctl -u chronyd \
    --since "-24 hours" --no-pager

oder:

[RO][PRIV][SENS] sudo journalctl -u chrony \
    --since "-24 hours" --no-pager

Kennzeichen in chronyc sources -v

Zeichen Bedeutung
^* Aktuell ausgewählte NTP-Quelle
^+ Geeignete zusätzliche Quelle
^- Geeignete, aber nicht verwendete Quelle
^? Quelle nicht erreichbar oder noch nicht ausreichend bewertet
^x Quelle wird als fehlerhaft bewertet
^~ Quelle weist zu große Schwankungen auf

Ein erreichbarer Server ist nicht automatisch eine geeignete Zeitquelle. Chrony bewertet unter anderem Abweichung, Stabilität und Messqualität.

10. Linux mit klassischem ntpd untersuchen

Auf älteren oder speziell konfigurierten Systemen kann weiterhin ntpd verwendet werden.

Dienststatus prüfen

[RO] systemctl status ntp --no-pager

oder abhängig von der Distribution:

[RO] systemctl status ntpd --no-pager

Zeitpartner anzeigen

[RO] ntpq -pn

Typische Markierungen:

Zeichen Bedeutung
* Aktuell ausgewählte Zeitquelle
+ Geeignete zusätzliche Quelle
- Von der Auswahl verworfene Quelle
x Als falsch bewertete Quelle
Leerzeichen Quelle wurde noch nicht ausgewählt

Protokolle anzeigen

[RO][PRIV][SENS] sudo journalctl -u ntp \
    --since "-24 hours" --no-pager

oder:

[RO][PRIV][SENS] sudo journalctl -u ntpd \
    --since "-24 hours" --no-pager

Es sollte zuerst ermittelt werden, welcher Zeitdienst tatsächlich aktiv ist. Mehrere parallel aktive Zeitdienste können sich gegenseitig beeinflussen.

11. Aktiven Zeitdienst unter Linux bestimmen

Erkannten NTP-Dienst anzeigen

[RO] timedatectl status

Typische Dienste prüfen

[RO] systemctl is-active systemd-timesyncd

[RO] systemctl is-active chronyd

[RO] systemctl is-active chrony

[RO] systemctl is-active ntpd

[RO] systemctl is-active ntp

Laufende Prozesse suchen

[RO] ps -ef |
    grep -E '[c]hronyd|[n]tpd|[s]ystemd-timesyncd'

Typische Problemkonstellationen

12. Zeitstatus unter macOS untersuchen

Lokale Zeit anzeigen

[RO] date "+%Y-%m-%dT%H:%M:%S%z"

UTC-Zeit anzeigen

[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"

Zeitzone anzeigen

[RO][PRIV] sudo systemsetup -gettimezone

Prüfen, ob Netzwerkzeit aktiviert ist

[RO][PRIV] sudo systemsetup -getusingnetworktime

Eingetragenen Netzwerkzeitserver anzeigen

[RO][PRIV][SENS] sudo systemsetup -getnetworktimeserver

Aktive Systemeinstellungen anzeigen

[RO] systemsetup -help

systemsetup benötigt für viele Abfragen Administratorrechte.

NTP-Server aktiv abfragen

[TEST] sntp -d <ZEITSERVER>

Beispiel:

[TEST] sntp -d time.apple.com

Dieser Test fragt eine Zeitquelle ab, ändert aber nicht automatisch die lokale Systemzeit.

Zeitbezogene Protokolle der letzten Stunde durchsuchen

[RO][PRIV][SENS] sudo log show --last 1h \
    --predicate 'process == "timed" OR process == "sntp"' \
    --style compact

Die vorhandenen Prozessnamen und Protokolle können sich zwischen macOS-Versionen unterscheiden.

Grafische Kontrolle

Apple-Menü
→ Systemeinstellungen
→ Allgemein
→ Datum & Uhrzeit

Dort werden unter anderem geprüft:

13. Erreichbarkeit des Zeitservers prüfen

NTP verwendet normalerweise UDP-Port 123. Ein erfolgreicher Ping beweist nicht, dass NTP funktioniert.

Namensauflösung prüfen

Windows:

[RO] Resolve-DnsName "<ZEITSERVER>"

Linux:

[RO] getent ahosts "<ZEITSERVER>"

macOS:

[RO] dscacheutil -q host -a name "<ZEITSERVER>"

Windows: NTP-Antwort und Zeitabweichung testen

[TEST] w32tm /stripchart /computer:<ZEITSERVER> /samples:5 /dataonly

Linux mit chrony

[RO] chronyc sources -v

macOS

[TEST] sntp -d <ZEITSERVER>

Netzwerkaufzeichnung unter Linux

[TEST][PRIV][SENS] sudo tcpdump -ni any udp port 123

Netzwerkaufzeichnung unter macOS

[TEST][PRIV][SENS] sudo tcpdump -ni any udp port 123

Dabei ist zu prüfen:

  1. Verlässt eine Anfrage das System?
  2. Wird sie an die erwartete IP-Adresse gesendet?
  3. Kommt eine Antwort zurück?
  4. Verwendet das System tatsächlich diese Gegenstelle?
  5. Blockiert eine lokale oder zentrale Firewall UDP 123?
  6. Überschreibt ein VPN die Route oder DNS-Auflösung?

Ein einfacher TCP-Porttest ist für NTP ungeeignet, weil NTP normalerweise UDP und nicht TCP verwendet.

14. Zeitzone und Sommerzeit untersuchen

Eine korrekte Synchronisation liefert eine gemeinsame Zeitbasis. Die lokale Darstellung hängt zusätzlich von der Zeitzone ab.

Windows

[RO] Get-TimeZone

[RO] tzutil /g

Verfügbare Zeitzonen anzeigen:

[RO] Get-TimeZone -ListAvailable

Linux

[RO] timedatectl status

[RO] readlink -f /etc/localtime

Verfügbare Zeitzonen anzeigen:

[RO] timedatectl list-timezones

macOS

[RO][PRIV] sudo systemsetup -gettimezone

Typische Zeitzonenfehler

Wichtige Unterscheidung

Situation Bewertung
UTC falsch Synchronisations- oder Uhrenproblem
UTC richtig, Lokalzeit falsch Zeitzonenproblem
Betriebssystemzeit richtig, Anwendung falsch Anwendungskonfiguration prüfen
Anzeige richtig, Logzeit abweichend Prüfen, ob das Protokoll UTC verwendet
15. Virtuelle Maschinen und Hypervisor berücksichtigen

Virtuelle Maschinen können ihre Zeit aus mehreren Quellen erhalten:

Wenn mehrere Quellen gleichzeitig eingreifen, kann die Uhr springen oder ständig korrigiert werden.

Typische Ursachen

Prüfreihenfolge

  1. Zeitquelle innerhalb der VM ermitteln.
  2. Zeitstatus des Hypervisors prüfen.
  3. Gasterweiterungen und Integrationsdienste kontrollieren.
  4. Domänenrolle der VM berücksichtigen.
  5. Snapshot- oder Migrationsereignisse zeitlich vergleichen.
  6. Prüfen, ob mehrere Zeitquellen gleichzeitig aktiv sind.
  7. Herstellerempfehlung des verwendeten Hypervisors beachten.

Windows-VM

[RO] w32tm /query /source

Die Ausgabe:

VM IC Time Synchronization Provider

weist bei Hyper-V auf eine Zeitbereitstellung über die Integrationskomponenten hin.

Bei Domänencontrollern muss besonders sorgfältig geplant werden, welche Zeitquelle maßgeblich ist. Eine unkontrollierte Änderung kann die gesamte Domänenzeithierarchie beeinflussen.

16. Container und Zeitzonenfehler untersuchen

Container verwenden normalerweise die Kernel-Uhr des Hosts. Die angezeigte lokale Zeit kann dennoch durch Zeitzonendateien, Umgebungsvariablen oder das Container-Image abweichen.

Zeit auf dem Host prüfen

[RO] date --iso-8601=seconds

Zeit in einem Docker-Container prüfen

[RO] docker exec "<CONTAINER>" date --iso-8601=seconds

UTC-Zeit im Container prüfen

[RO] docker exec "<CONTAINER>" date -u "+%Y-%m-%dT%H:%M:%SZ"

Zeitzonenumgebung prüfen

[RO][SENS] docker inspect "<CONTAINER>" \
    --format '{{range .Config.Env}}{{println .}}{{end}}'

In der Ausgabe kann nach einer Variable wie TZ gesucht werden.

Typische Ursachen

Die Systemzeit eines Containers sollte nicht durch zusätzliche Berechtigungen oder manuelle Änderungen korrigiert werden. Zuerst müssen Hostzeit, Zeitzone und Anwendungskonfiguration geprüft werden.

17. Hardwareuhr und Firmware berücksichtigen

Die Hardwareuhr, auch RTC genannt, hält die Zeit während des ausgeschalteten Zustands. Beim Start übernimmt das Betriebssystem einen Ausgangswert und synchronisiert ihn anschließend.

Linux

[RO][PRIV] sudo hwclock --show

Vergleich mit der Systemzeit:

[RO] date --iso-8601=seconds

Mögliche Ursachen für eine falsche Startzeit

Typisches Fehlerbild einer schwachen CMOS-Batterie

Bei virtuellen Maschinen existiert keine normale austauschbare CMOS-Batterie. Dort müssen Hypervisor, virtuelle Hardwareuhr und Hostzeit geprüft werden.

18. Zeitabhängige Sicherheitsfehler erkennen

Kerberos

Kerberos verwendet Zeitstempel, um wiederholte Verwendung abgefangener Authentifizierungsdaten zu erschweren. Eine zu große Abweichung zwischen Client, Domänencontroller und Server kann Anmeldungen verhindern.

Typische Meldungen:

TLS und Zertifikate

Zertifikate besitzen unter anderem:

Bei falscher Systemzeit kann ein gültiges Zertifikat erscheinen als:

Zeitbasierte Einmalpasswörter

TOTP-Verfahren berechnen Codes aus:

Wenn Smartphone, Server oder Authentifizierungsdienst zeitlich abweichen, werden korrekte Codes abgelehnt.

Prüfregel

Bei gleichzeitigen Fehlern in Anmeldung, Zertifikaten und MFA sollte die Systemzeit sehr früh in der Diagnose geprüft werden.

19. Sichere Korrekturmaßnahmen

Vor jeder Änderung muss die Ursache bestimmt werden. Ein manuelles Stellen der Uhr kann Protokolle, Datenbanken, Cluster und laufende Anwendungen beeinflussen.

Windows: erneute Synchronisation anfordern

[CHANGE][PRIV] w32tm /resync

Mit erneuter Erkennung der Zeitquelle:

[CHANGE][PRIV] w32tm /resync /rediscover

Linux mit systemd-timesyncd

Zeitdienst nur nach bestätigter Ursache neu starten:

[CHANGE][PRIV] sudo systemctl restart systemd-timesyncd

Linux mit chrony

Dienst nur nach bestätigter Ursache neu starten:

[CHANGE][PRIV] sudo systemctl restart chronyd

Abhängig von der Distribution:

[CHANGE][PRIV] sudo systemctl restart chrony

Große Zeitkorrekturen

Große Zeitsprünge können:

Vor einer großen Korrektur sind deshalb zu prüfen:

Die Zeit niemals absichtlich zurückstellen, ohne die Auswirkungen auf Datenbanken, Protokolle und verteilte Systeme zu bewerten.

20. Typische Fehlinterpretationen vermeiden
Fehlinterpretation Richtige Bewertung
„Die Uhr in der Taskleiste stimmt.“ Quelle, Synchronisationsstatus, UTC und Zeitzone zusätzlich prüfen.
„Ping zum Zeitserver funktioniert.“ Ping prüft nicht die NTP-Kommunikation über UDP 123.
„Der Zeitdienst läuft, also synchronisiert er.“ Ein aktiver Dienst kann ohne brauchbare Quelle laufen.
„Eine Stunde Abweichung ist ein NTP-Fehler.“ Häufig ist die Zeitzone oder Sommerzeitregel falsch.
„Alle Systeme müssen dieselbe lokale Uhrzeit anzeigen.“ Systeme in verschiedenen Zeitzonen können dieselbe UTC-Zeit verwenden.
„Die Uhr kann gefahrlos manuell gestellt werden.“ Zeitsprünge können Anwendungen und Protokolle beeinflussen.
„Jeder Domänenclient sollte einen öffentlichen NTP-Server verwenden.“ Domänenmitglieder sollten normalerweise der AD-Zeithierarchie folgen.
„Der Hypervisor regelt die Zeit vollständig.“ Gastzeitdienst und Hypervisor können gleichzeitig eingreifen.
„Container besitzen eine vollständig eigene Uhr.“ Container verwenden normalerweise die Kernel-Uhr des Hosts.
„Ein Neustart behebt die Zeit dauerhaft.“ Eine fehlerhafte Quelle oder Konfiguration bleibt bestehen.
21. Sichere Reihenfolge der Fehleranalyse
  1. Fehlerzeitpunkt und originale Fehlermeldung dokumentieren.
  2. Lokale Zeit und UTC-Zeit erfassen.
  3. Zeitzone kontrollieren.
  4. Abweichung mit einem vertrauenswürdigen Vergleichssystem bestimmen.
  5. Aktiven Zeitdienst identifizieren.
  6. Tatsächlich verwendete Zeitquelle ermitteln.
  7. Synchronisationsstatus und letzte erfolgreiche Messung prüfen.
  8. Namensauflösung der Zeitquelle testen.
  9. NTP-Antwort beziehungsweise Zeitabweichung aktiv prüfen.
  10. Firewall, Routing und UDP 123 untersuchen.
  11. Ereignis- beziehungsweise Systemprotokolle auswerten.
  12. Domänen-, Virtualisierungs- oder Containerstruktur berücksichtigen.
  13. Erst danach eine erneute Synchronisation oder Konfigurationsänderung durchführen.
  14. Nach der Maßnahme Quelle, Status und Abweichung erneut kontrollieren.
  15. Ursache und Korrektur dokumentieren.
22. Schnelle Befehlsübersicht
Aufgabe Windows Linux macOS
Lokale Zeit [RO] Get-Date -Format o [RO] date --iso-8601=seconds [RO] date "+%Y-%m-%dT%H:%M:%S%z"
UTC-Zeit [RO] (Get-Date).ToUniversalTime().ToString("o") [RO] date -u "+%Y-%m-%dT%H:%M:%SZ" [RO] date -u "+%Y-%m-%dT%H:%M:%SZ"
Zeitzone [RO] Get-TimeZone [RO] timedatectl status [RO][PRIV] sudo systemsetup -gettimezone
Zeitdienst [RO] Get-Service W32Time [RO] systemctl status <DIENST> Systemdienst wird durch macOS verwaltet
Zeitquelle [RO] w32tm /query /source [RO] timedatectl timesync-status oder [RO] chronyc tracking [RO][PRIV] sudo systemsetup -getnetworktimeserver
Synchronisationsstatus [RO] w32tm /query /status [RO] timedatectl status oder [RO] chronyc tracking [RO][PRIV] sudo systemsetup -getusingnetworktime
Zeitpartner [RO] w32tm /query /peers [RO] chronyc sources -v oder [RO] ntpq -pn Eingetragener Netzwerkzeitserver
Abweichung testen [TEST] w32tm /stripchart ... Quellenstatus des verwendeten Dienstes [TEST] sntp -d <ZEITSERVER>
Protokolle [RO] Get-WinEvent ... [RO][PRIV] sudo journalctl -u <DIENST> [RO][PRIV] sudo log show ...
Hardwareuhr Nicht üblicherweise separat [RO][PRIV] sudo hwclock --show Nicht regulär erforderlich
Synchronisation anfordern [CHANGE][PRIV] w32tm /resync Abhängig vom eingesetzten Dienst Durch macOS beziehungsweise Systemeinstellungen
NTP-Verkehr erfassen Paketaufzeichnung erforderlich [TEST][PRIV] sudo tcpdump -ni any udp port 123 [TEST][PRIV] sudo tcpdump -ni any udp port 123
23. Entscheidungsmatrix
Befund Wahrscheinliche Ursache Nächster Schritt
UTC korrekt, Lokalzeit falsch Zeitzone oder Sommerzeit Zeitzonenkonfiguration prüfen
UTC und Lokalzeit falsch Zeitquelle oder Synchronisation Dienst und Quelle untersuchen
Zeitdienst läuft, keine Quelle Netzwerk, DNS, Firewall oder Konfiguration Erreichbarkeit und Zeitpartner prüfen
Quelle ist lokale Hardwareuhr Keine externe Synchronisation Erwartete Zeitarchitektur prüfen
Nur Domänenanmeldungen betroffen Kerberos-Zeitabweichung möglich Client, Server und DC vergleichen
TLS und MFA gleichzeitig fehlerhaft Systemzeit wahrscheinlich falsch Datum, UTC und Quelle sofort prüfen
Zeit springt nach Neustart zurück RTC, Firmware, Host oder CMOS-Batterie Startzeit und Hardware prüfen
Nur eine VM betroffen Hypervisor- oder Gastkonfiguration Beide Zeitquellen vergleichen
Alle Domänensysteme betroffen Fehler in der AD-Zeithierarchie PDC-Emulator und übergeordnete Quelle prüfen
Abweichung wächst kontinuierlich Uhrdrift oder keine Nachregelung Messwerte und Dienstprotokolle untersuchen
Exakt eine Stunde Abweichung Zeitzone oder Sommerzeit Zeitzone statt NTP-Konfiguration prüfen
Host korrekt, Container falsch Container-Zeitzone oder Anwendung TZ, Zeitzonendateien und Anwendung prüfen
24. Dokumentationsvorlage 
Ticket:
Datum und Uhrzeit der Analyse:
Bearbeiter:

Betroffenes System:
Betriebssystem:
Systemrolle:
Physisch, virtuell oder Container:
Domänenmitglied:
Betroffene Anwendung oder Funktion:

Originale Fehlermeldung:
Lokale Zeit:
UTC-Zeit:
Zeitzone:
Vergleichssystem:
Gemessene Abweichung:

Aktiver Zeitdienst:
Dienststatus:
Aktive Zeitquelle:
Konfigurierte Zeitpartner:
Letzte erfolgreiche Synchronisation:
Stratum beziehungsweise Hierarchie:
NTP-Antwort erhalten:
UDP 123 erreichbar:
DNS-Auflösung:

Zeitbezogene Protokollmeldungen:
Hypervisor-Zeitquelle:
Snapshot oder Migration:
Hardwareuhr:
Gruppenrichtlinie oder Geräteverwaltung:

Vermutete Ursache:
Durchgeführte Tests:
Durchgeführte Änderung:
Auswirkung der Änderung:
Rückfallplan:

Zeitquelle nach der Maßnahme:
Abweichung nach der Maßnahme:
Synchronisationsstatus nach der Maßnahme:
Funktionsprüfung:
Weiterführende Maßnahmen:

Merksatz

Bei Zeitfehlern werden immer vier Dinge getrennt geprüft: aktuelle UTC-Zeit, lokale Zeitzone, verwendete Zeitquelle und tatsächlicher Synchronisationsstatus. Die Uhr wird erst verändert, wenn Ursache und Auswirkungen geklärt sind.

Quellen und weiterführende Dokumentation

4. Server- und Dienstfehler systematisch analysieren

4.13 Update-, Patch- und Paketverwaltungsfehler

Updates können in verschiedenen Phasen scheitern: bei der Erkennung, beim Herunterladen, bei der Signaturprüfung, während der Installation, beim Neustart oder erst nach der Aktivierung der neuen Komponenten.

Dabei muss zwischen Betriebssystemupdates, Sicherheitsupdates, Treibern, Firmware, Anwendungspaketen und verwalteten Unternehmensupdates unterschieden werden.

Typische Auswirkungen sind:

Wichtig: Die Meldung „Update fehlgeschlagen“ bezeichnet nur das Ergebnis. Für die Diagnose müssen Updatequelle, Fehlerphase, Fehlercode, Systemzustand und Protokolle getrennt untersucht werden.

Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] Nur lesender Befehl
[TEST] Führt eine aktive Prüfung aus
[PRIV] Erhöhte Berechtigungen erforderlich
[FILE] Liest Dateien oder Verzeichnisse
[SENS] Ausgabe kann sensible Informationen enthalten
[CHANGE] Verändert Cache, Konfiguration oder Systemzustand
[DISRUPT] Kann Dienste unterbrechen oder einen Neustart erfordern
1. Updatefehler strukturiert aufnehmen

Vor einer Reparatur müssen die genaue Updateart und die Fehlerphase bestimmt werden.

Zu erfassende Informationen

Fehlerphasen

Phase Typische Ursachen
Erkennung Updatequelle, Richtlinie, MDM, Repository oder nicht unterstützte Version
Download Netzwerk, DNS, Proxy, Firewall, CDN oder Speicherplatz
Signaturprüfung Falsche Zeit, Zertifikat, Schlüsselbund oder beschädigter Download
Vorbereitung Speicherplatz, Abhängigkeiten, Paketdatenbank oder Systemdateien
Installation Gesperrte Dateien, laufende Dienste, Abhängigkeiten oder Berechtigungen
Neustart Pending-Reboot-Zustand, Bootfehler, Treiber oder Firmware
Aktivierung Dienststart, Konfigurationsmigration oder inkompatible Anwendung
Rollback Installationsfehler, Bootproblem oder nicht erfüllte Voraussetzung

Dokumentationsregel

Der originale Fehlercode muss vollständig übernommen werden. Beschreibungen wie „irgendein Updatefehler“ reichen für eine gezielte Analyse nicht aus.

2. Vorbedingungen auf allen Betriebssystemen prüfen

Viele Updatefehler entstehen nicht in der Paketverwaltung selbst.

Prüfbereich Warum er wichtig ist
Freier Speicherplatz Updates benötigen Platz für Download, Entpacken, Installation und Rückfall
Datum und Uhrzeit Signaturen, Zertifikate und TLS-Verbindungen sind zeitabhängig
DNS Update- und Repositoryserver müssen aufgelöst werden
Internet beziehungsweise internes Netzwerk Updatequelle muss erreichbar sein
Proxy Systemdienste verwenden möglicherweise andere Proxyeinstellungen als Benutzer
Neustartstatus Eine ältere Installation kann noch nicht abgeschlossen sein
Systemversion Nicht mehr unterstützte Versionen erhalten möglicherweise keine Updates
Architektur Paket muss zu x64, ARM64 oder einer anderen Architektur passen
Paketquelle Repository, WSUS oder MDM muss gültige Metadaten bereitstellen
Signaturen Paket und Metadaten müssen vertrauenswürdig sein
Berechtigungen Installation benötigt normalerweise administrative Rechte
Sicherung Fehlerhafte Updates können einen Rollback erforderlich machen

Schnellprüfung des Speicherplatzes

Windows:

[RO] Get-Volume |
    Select-Object DriveLetter, FileSystemLabel,
        HealthStatus, SizeRemaining, Size

Linux:

[RO] df -hT

macOS:

[RO] df -h

Zeit prüfen

Windows:

[RO] Get-Date -Format o

Linux:

[RO] timedatectl status

macOS:

[RO] date "+%Y-%m-%dT%H:%M:%S%z"
3. Betriebssystemversion und Architektur ermitteln

Ein Update kann nur installiert werden, wenn Version, Build, Edition und Architektur unterstützt werden.

Windows

[RO] Get-ComputerInfo |
    Select-Object WindowsProductName, WindowsEditionId,
        WindowsVersion, OsBuildNumber, OsArchitecture

Kompakter:

[RO] Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, BuildNumber, OSArchitecture

Linux

[RO][FILE] cat /etc/os-release

[RO] uname -r

[RO] uname -m

macOS

[RO] sw_vers

[RO] uname -m

Typische Architekturbezeichnungen

Bezeichnung Bedeutung
x86_64 beziehungsweise AMD64 64-Bit-x86
aarch64 beziehungsweise ARM64 64-Bit-ARM
i386 oder i686 32-Bit-x86
arm64 unter macOS Apple Silicon
x86_64 unter macOS Intel-Mac oder gegebenenfalls übersetzter Prozess

Die Prozessorarchitektur des Hosts, die Architektur des Betriebssystems und die Architektur eines einzelnen Programms können unterschiedlich sein.

4. Windows-Updatequelle und Richtlinien prüfen

Windows-Geräte können Updates aus unterschiedlichen Quellen beziehen:

Windows-Update-Richtlinien anzeigen

[RO][SENS] Get-ItemProperty `
    -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' `
    -ErrorAction SilentlyContinue

Richtlinien für automatische Updates anzeigen

[RO][SENS] Get-ItemProperty `
    -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' `
    -ErrorAction SilentlyContinue

Angewendete Gruppenrichtlinien dokumentieren

[RO][SENS] gpresult /scope computer /r

Ausführlichen HTML-Bericht erstellen:

[RO][FILE][SENS] gpresult /scope computer /h "<ZIELPFAD>\gpresult-computer.html"

Relevante Hinweise

Beobachtung Mögliche Bedeutung
Interner Update-Server eingetragen Gerät verwendet wahrscheinlich WSUS
WSUS-Server nicht erreichbar Erkennung und Download können scheitern
Keine sichtbare lokale Richtlinie Einstellung kann über MDM oder andere Verwaltung kommen
Einstellung springt zurück Zentrale Richtlinie überschreibt lokale Änderung
Update wird anderen Geräten angeboten Zielgruppen-, Freigabe- oder Kompatibilitätsunterschied möglich
Gerät erhält nur bestimmte Updatearten Richtlinie oder Updatekanal begrenzt das Angebot

Registrywerte dürfen nicht allein aufgrund einer Internetanleitung gelöscht oder verändert werden. Zuerst muss festgestellt werden, ob sie zentral verwaltet werden.

5. Windows-Update-Dienste untersuchen

Relevante Dienste anzeigen

[RO] Get-Service -Name wuauserv, bits, cryptsvc, trustedinstaller |
    Select-Object Name, DisplayName, Status, StartType

Bedeutung:

Dienst Aufgabe
wuauserv Windows Update
BITS Hintergrundübertragung von Dateien
CryptSvc Kryptografische Dienste und Signaturprüfungen
TrustedInstaller Windows Modules Installer

Ausführliche Dienstinformationen

[RO] Get-CimInstance Win32_Service |
    Where-Object {
        $_.Name -in 'wuauserv','BITS','CryptSvc','TrustedInstaller'
    } |
    Select-Object Name, State, StartMode, StartName, ExitCode

Abhängigkeiten eines Dienstes anzeigen

[RO] Get-Service -Name wuauserv -RequiredServices

Wichtige Bewertung

6. Installierte Windows-Updates und Verlauf prüfen

Ausgewählte installierte Updates anzeigen

[RO] Get-HotFix |
    Sort-Object InstalledOn -Descending |
    Select-Object HotFixID, Description, InstalledOn, InstalledBy

Get-HotFix zeigt nicht jede denkbare Update-, Treiber-, App- oder Servicing-Komponente an. Die Ausgabe darf deshalb nicht als vollständiges Inventar aller installierten Aktualisierungen interpretiert werden.

Installierte Windows-Pakete mit DISM anzeigen

[RO][PRIV] DISM.exe /Online /Get-Packages /Format:Table

Nach einem bestimmten KB-Paket suchen

[RO] Get-HotFix -Id <KB-NUMMER> -ErrorAction SilentlyContinue

Beispiel:

[RO] Get-HotFix -Id KB5030000 -ErrorAction SilentlyContinue

Die KB-Nummer im Beispiel ist durch die tatsächlich zu prüfende Nummer zu ersetzen.

Installationszeit und Paketstatus mit DISM prüfen

[RO][PRIV] DISM.exe /Online /Get-PackageInfo /PackageName:<PAKETNAME>

Den exakten Paketnamen erhält man zuvor über:

[RO][PRIV] DISM.exe /Online /Get-Packages /Format:Table
7. Windows-Updateprotokolle auswerten

Moderne Windows-Versionen speichern Windows-Update-Ereignisse überwiegend als ETL-Daten. Get-WindowsUpdateLog erzeugt daraus eine lesbare Protokolldatei.

Lesbares WindowsUpdate-Protokoll erzeugen

[RO][FILE][SENS] Get-WindowsUpdateLog -LogPath "<ZIELPFAD>\WindowsUpdate.log"

Der Befehl sammelt und konvertiert vorhandene Protokolldaten. Die erzeugte Datei kann Servernamen, URLs, Geräteinformationen und Fehlerdetails enthalten.

Windows-Update-Ereignisse anzeigen

[RO][SENS] Get-WinEvent -LogName `
    'Microsoft-Windows-WindowsUpdateClient/Operational' |
Select-Object -First 100 TimeCreated, LevelDisplayName, Id, Message

Nur Warnungen und Fehler der letzten 24 Stunden

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-WindowsUpdateClient/Operational'
    StartTime = (Get-Date).AddHours(-24)
} |
Where-Object {
    $_.LevelDisplayName -in 'Warning','Error','Warnung','Fehler'
} |
Select-Object TimeCreated, LevelDisplayName, Id, Message

Servicing-Protokolle

[RO][FILE][SENS] %WINDIR%\Logs\CBS\CBS.log

[RO][FILE][SENS] %WINDIR%\Logs\DISM\dism.log

Setup- und Upgradeprotokolle können unter anderem hier liegen

[RO][FILE][SENS] %WINDIR%\Panther

[RO][FILE][SENS] %WINDIR%\Logs\MoSetup

Die tatsächlich vorhandenen Dateien hängen von Updateart, Betriebssystemversion und Fehlerphase ab.

Bei der Protokollanalyse suchen nach

8. Ausstehenden Windows-Neustart erkennen

Ein ausstehender Neustart kann weitere Updates, Rolleninstallationen oder Paketänderungen blockieren.

Component-Based-Servicing prüfen

[RO] Test-Path `
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'

Windows-Update-Neustartstatus prüfen

[RO] Test-Path `
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'

Ausstehende Dateiumbenennungen prüfen

[RO][SENS] Get-ItemProperty `
    -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager' `
    -Name PendingFileRenameOperations `
    -ErrorAction SilentlyContinue

Bewertung

9. Windows-Komponentenspeicher prüfen

Beschädigungen im Windows-Komponentenspeicher können Updates und Rolleninstallationen verhindern.

Schnelle Prüfung

[TEST][PRIV] DISM.exe /Online /Cleanup-Image /CheckHealth

/CheckHealth prüft, ob bereits eine Beschädigung markiert wurde. Es führt keinen vollständigen Scan aus.

Ausführlichere Prüfung

[TEST][PRIV] DISM.exe /Online /Cleanup-Image /ScanHealth

Systemdateien prüfen

[TEST][PRIV] sfc /verifyonly

Reparatur des Komponentenspeichers

[CHANGE][PRIV] DISM.exe /Online /Cleanup-Image /RestoreHealth

Systemdateien prüfen und reparieren

[CHANGE][PRIV] sfc /scannow

Wichtige Hinweise

DISM und SFC sind keine pauschalen ersten Schritte für jeden Updatefehler. Zuerst müssen Fehlercode, Quelle, Speicherplatz und Updatephase geprüft werden.

10. Windows-Proxy und Netzwerkpfad prüfen

Windows-Systemdienste können andere Proxyeinstellungen verwenden als ein angemeldeter Benutzer.

WinHTTP-Proxy anzeigen

[RO] netsh winhttp show proxy

DNS-Auflösung prüfen

[RO] Resolve-DnsName "<UPDATE-ODER-WSUS-SERVER>"

HTTPS-Erreichbarkeit eines konkret bekannten Servers prüfen

[TEST] Test-NetConnection `
    -ComputerName "<SERVERNAME>" `
    -Port 443

Bei einem internen WSUS-Server muss der tatsächlich konfigurierte Port verwendet werden.

Route anzeigen

[RO] Test-NetConnection `
    -ComputerName "<SERVERNAME>" `
    -TraceRoute

Typische Ursachen

Öffentliche Updateplattformen verwenden mehrere dynamische Endpunkte. Es sollten keine unbestätigten Einzeladressen dauerhaft freigeschaltet werden; maßgeblich ist die aktuelle Herstellerdokumentation.

11. Debian- und Ubuntu-Paketverwaltung prüfen

Debian und Ubuntu verwenden üblicherweise APT und dpkg.

Betriebssystemversion prüfen

[RO][FILE] cat /etc/os-release

Konfigurierte Paketquellen anzeigen

[RO][FILE][SENS] grep -RhsE '^[[:space:]]*deb ' \
    /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null

Neuere APT-Quellen können zusätzlich im Deb822-Format mit der Endung .sources gespeichert sein:

[RO][FILE][SENS] grep -RhsE \
    '^[[:space:]]*(Types|URIs|Suites|Components|Signed-By):' \
    /etc/apt/sources.list.d 2>/dev/null

Paketstatus auf Inkonsistenzen prüfen

[RO][PRIV] sudo dpkg --audit

Alternativ:

[RO][PRIV] sudo dpkg -C

Paketabhängigkeiten prüfen

[TEST][PRIV] sudo apt-get check

Installierte und verfügbare Version eines Pakets anzeigen

[RO] apt-cache policy "<PAKETNAME>"

Zurückgehaltene Pakete anzeigen

[RO] apt-mark showhold

Paketarchitektur anzeigen

[RO] dpkg --print-architecture

Zusätzlich konfigurierte Architekturen:

[RO] dpkg --print-foreign-architectures

Letzte dpkg-Aktionen anzeigen

[RO][FILE][SENS] tail -n 100 /var/log/dpkg.log

APT-Verlauf anzeigen, sofern vorhanden

[RO][FILE][SENS] ls -l /var/log/apt

[RO][FILE][SENS] tail -n 100 /var/log/apt/history.log
12. APT-Aktualisierung und Fehlerausgabe kontrolliert prüfen

Das Aktualisieren der Paketlisten ist bereits eine Veränderung des lokalen Paketcache.

[CHANGE][PRIV] sudo apt update

Dabei sind besonders folgende Meldungen zu beachten:

Meldung Mögliche Ursache
Temporary failure resolving DNS-Problem
Connection timed out Netzwerk, Proxy, Firewall oder Repository
404 Not Found Falscher Distributionsname oder veraltete Quelle
NO_PUBKEY Fehlender oder falsch eingebundener Signaturschlüssel
Release file is not valid yet Systemzeit möglicherweise falsch
does not have a Release file Quelle unterstützt die Distribution nicht
Hash Sum mismatch Spiegelserver, Proxycache oder inkonsistente Metadaten
Could not get lock Andere Paketverwaltung ist aktiv
Unmet dependencies Abhängigkeitskonflikt
held broken packages Zurückgehaltene oder nicht auflösbare Pakete
No space left on device Speicherplatz oder Inodes ausgeschöpft

Simulation einer Installation

[TEST] apt-get --simulate install "<PAKETNAME>"

Die Simulation verändert keine Pakete, bildet aber nicht jede Nebenwirkung eines tatsächlichen Installationsskripts ab.

Paketinformationen anzeigen

[RO] apt-cache show "<PAKETNAME>"

Abhängigkeiten anzeigen

[RO] apt-cache depends "<PAKETNAME>"

Reverse-Abhängigkeiten anzeigen

[RO] apt-cache rdepends "<PAKETNAME>"
13. Paketmanager-Sperren unter Linux untersuchen

Eine Sperrdatei darf nicht allein aufgrund ihrer Existenz gelöscht werden. Zuerst muss geprüft werden, ob ein Paketmanager tatsächlich arbeitet.

APT- und dpkg-Prozesse anzeigen

[RO][SENS] ps -ef |
    grep -E '[a]pt|[d]pkg|[u]nattended-upgrade'

Prozesse mit geöffneten APT- oder dpkg-Sperren anzeigen

[RO][PRIV][SENS] sudo lsof \
    /var/lib/dpkg/lock \
    /var/lib/dpkg/lock-frontend \
    /var/lib/apt/lists/lock \
    /var/cache/apt/archives/lock 2>/dev/null

Automatische Updates prüfen

[RO] systemctl status apt-daily.service --no-pager

[RO] systemctl status apt-daily-upgrade.service --no-pager

Protokolle automatischer Updates

[RO][PRIV][SENS] sudo journalctl \
    -u apt-daily.service \
    -u apt-daily-upgrade.service \
    --since "-24 hours" --no-pager

Das Löschen einer Sperrdatei oder Beenden eines Paketmanagers während einer Installation kann die Paketdatenbank beschädigen. Erst muss geklärt werden, ob der Prozess noch arbeitet, wartet oder abgestürzt ist.

14. Unvollständige dpkg-Transaktionen behandeln

Ein abgebrochener Installationsprozess kann Pakete in einem nicht fertig konfigurierten Zustand hinterlassen.

Zustand zunächst prüfen

[RO][PRIV] sudo dpkg --audit

Paketstatus eines bestimmten Pakets anzeigen

[RO] dpkg-query -W \
    -f='${Package}\t${Status}\t${Version}\n' "<PAKETNAME>"

Noch nicht konfigurierte Pakete konfigurieren

[CHANGE][PRIV] sudo dpkg --configure -a

Abhängigkeiten reparieren

[CHANGE][PRIV] sudo apt-get --fix-broken install

Diese Befehle können:

Vorher sollten geprüft werden:

Bei apt-get --fix-broken install muss die vorgeschlagene Paketliste vor der Bestätigung vollständig gelesen werden.

15. DNF- und RPM-Systeme untersuchen

Fedora, Red Hat Enterprise Linux und verwandte Distributionen verwenden häufig DNF und RPM.

Betriebssystemversion

[RO][FILE] cat /etc/os-release

Aktive Repositories anzeigen

[RO][SENS] dnf repolist

Alle bekannten Repositories anzeigen

[RO][SENS] dnf repolist --all

Paketdatenbank und Abhängigkeiten prüfen

[TEST][PRIV] sudo dnf check

Verfügbare Aktualisierungen prüfen

[TEST][PRIV] sudo dnf check-update

dnf check-update kann mit Rückgabecode 100 enden, wenn Updates verfügbar sind. Dieser Rückgabecode bedeutet dann nicht automatisch einen Fehler.

Paketinformationen anzeigen

[RO] dnf info "<PAKETNAME>"

Installierte Paketversion anzeigen

[RO] rpm -q "<PAKETNAME>"

Paketarchitektur anzeigen

[RO] rpm -q --queryformat \
    '%{NAME}\t%{VERSION}-%{RELEASE}\t%{ARCH}\n' "<PAKETNAME>"

Transaktionsverlauf anzeigen

[RO][SENS] dnf history

Details einer Transaktion

[RO][SENS] dnf history info <TRANSAKTIONS-ID>

Installierte Dateien gegen RPM-Metadaten prüfen

[TEST][PRIV][FILE][SENS] sudo rpm -Va

rpm -Va kann lange laufen und meldet auch absichtlich veränderte Konfigurationsdateien. Abweichungen sind nicht automatisch Beschädigungen.

16. Zypper- und RPM-Systeme untersuchen

SUSE Linux Enterprise und openSUSE verwenden typischerweise Zypper.

Repositories anzeigen

[RO][SENS] zypper repos

Ausführlicher:

[RO][SENS] zypper repos --details

Verfügbare Patches anzeigen

[TEST][PRIV] sudo zypper list-patches

Abhängigkeiten prüfen

[TEST][PRIV] sudo zypper verify

Paketinformationen anzeigen

[RO] zypper info "<PAKETNAME>"

Installierte Version prüfen

[RO] rpm -q "<PAKETNAME>"

Zypper-Protokoll lesen

[RO][FILE][SENS] tail -n 100 /var/log/zypper.log
17. macOS-Softwareupdates untersuchen

macOS-Version und Build anzeigen

[RO] sw_vers

Verfügbare Apple-Softwareupdates suchen

[TEST] softwareupdate --list

Der Befehl kontaktiert die konfigurierte Updateinfrastruktur und kann einige Zeit benötigen.

Verlauf installierter Apple-Updates anzeigen

[RO] softwareupdate --history

Ausführlicher Verlauf:

[RO] softwareupdate --history --all

Hilfe der installierten softwareupdate-Version anzeigen

[RO] softwareupdate --help

Die verfügbaren Optionen von softwareupdate können sich zwischen macOS-Versionen unterscheiden. Deshalb sollte die lokale Hilfe geprüft werden, bevor Installationsoptionen verwendet werden.

Freien Speicherplatz prüfen

[RO] df -h /

Datum und Uhrzeit prüfen

[RO] date "+%Y-%m-%dT%H:%M:%S%z"

Netzwerkzeitstatus prüfen

[RO][PRIV] sudo systemsetup -getusingnetworktime

Eingetragenen Zeitserver anzeigen

[RO][PRIV][SENS] sudo systemsetup -getnetworktimeserver

MDM-Registrierungsstatus anzeigen

[RO][PRIV][SENS] sudo profiles status -type enrollment

Ein verwalteter Mac kann Updates aufgrund von MDM-Vorgaben:

18. macOS-Updateprotokolle auswerten

Softwareupdate-Protokolle der letzten Stunde

[RO][PRIV][SENS] sudo log show --last 1h \
    --predicate 'process == "softwareupdated"' \
    --style compact

Mehrere typische Updateprozesse berücksichtigen

[RO][PRIV][SENS] sudo log show --last 2h \
    --predicate 'process == "softwareupdated" OR process == "softwareupdate"' \
    --style compact

Nur Fehler und schwerwiegende Meldungen

[RO][PRIV][SENS] sudo log show --last 2h \
    --predicate '(process == "softwareupdated" OR process == "softwareupdate") AND messageType >= error' \
    --style compact

Die von macOS verwendeten Prozesse und Protokollfelder können sich zwischen Versionen unterscheiden. Wenn die Abfrage keine Ergebnisse liefert, bedeutet dies nicht automatisch, dass kein Updateversuch stattgefunden hat.

Typische Ursachen

19. Repository-, Signatur- und Zertifikatsfehler unterscheiden

Softwarepakete und Repositorymetadaten werden normalerweise kryptografisch geprüft.

Typische Fehlerursachen

Ursache Wirkung
Falsche Systemzeit Zertifikat oder signierte Metadaten erscheinen ungültig
Abgelaufener Signaturschlüssel Repository wird nicht akzeptiert
Falscher Schlüssel Signatur kann nicht verifiziert werden
Manipulierender Proxy TLS- oder Zertifikatsprüfung schlägt fehl
Unvollständiger Download Prüfsumme stimmt nicht
Veraltete Repositorydefinition Release-Datei oder Paketpfad fehlt
Nicht unterstützte Distribution Repository stellt keine passenden Metadaten bereit
Falsche Architektur Paket kann nicht installiert werden
Internes Zertifikat fehlt Unternehmensrepository wird nicht vertraut
Spiegelserver nicht synchron Metadaten und Paketdateien passen vorübergehend nicht zusammen

Sicherheitsregel

Signatur- und Zertifikatsprüfungen dürfen nicht dauerhaft deaktiviert werden, um eine Installation „zum Laufen zu bringen“.

Stattdessen müssen geprüft werden:

  1. Systemzeit
  2. Repositoryadresse
  3. Distributionsversion
  4. Paketarchitektur
  5. erwarteter Signaturschlüssel
  6. Zertifikatskette
  7. Proxy- oder TLS-Inspection
  8. Integrität des Downloads
  9. offizielle Installationsanleitung des Herstellers
20. Abhängigkeiten und Versionskonflikte analysieren

Paketmanager installieren selten nur eine einzelne Datei. Pakete besitzen Abhängigkeiten, Konflikte und Versionsanforderungen.

Typische Beziehungen

Beziehung Bedeutung
Abhängigkeit Zusätzlich benötigtes Paket
Versionsabhängigkeit Nur bestimmte Versionen sind zulässig
Konflikt Pakete dürfen nicht gleichzeitig installiert sein
Ersatz Ein Paket ersetzt ein anderes
Empfehlung Zusätzliches Paket wird empfohlen
Architekturabhängigkeit Paket benötigt eine bestimmte Plattform
Modulschnittstelle Anwendung benötigt eine kompatible Bibliotheksversion

APT-Abhängigkeiten anzeigen

[RO] apt-cache depends "<PAKETNAME>"

APT-Reverse-Abhängigkeiten

[RO] apt-cache rdepends "<PAKETNAME>"

RPM-Abhängigkeiten anzeigen

[RO] rpm -qR "<PAKETNAME>"

Paket ermitteln, das eine Fähigkeit bereitstellt

DNF:

[RO] dnf provides "<DATEI-ODER-FÄHIGKEIT>"

APT:

[RO] apt-file search "<DATEINAME>"

apt-file ist nicht standardmäßig auf jedem System installiert und benötigt einen eigenen Suchindex.

Diagnosefragen

21. Paketcache und heruntergeladene Dateien richtig bewerten

Beschädigte oder unvollständige Downloads können wiederholte Fehler verursachen. Das pauschale Löschen aller Updatecaches ist dennoch kein sinnvoller erster Diagnoseschritt.

Vor einer Cachebereinigung prüfen

APT-Downloadcache anzeigen

[RO][FILE] du -sh /var/cache/apt/archives

DNF-Cachebelegung anzeigen

[RO][FILE][PRIV] sudo du -sh /var/cache/dnf

Windows-Update-Downloadbereich

[RO][FILE][PRIV] %WINDIR%\SoftwareDistribution\Download

Der Ordner SoftwareDistribution darf nicht unkontrolliert umbenannt oder gelöscht werden. Ein Reset der Windows-Updatekomponenten verändert den Updatezustand und erschwert möglicherweise die ursprüngliche Ursachenanalyse.

22. Automatische Updates und Wartungsfenster prüfen

Automatische Aktualisierungen können parallel zu manuellen Arbeiten laufen oder durch Wartungsregeln eingeschränkt sein.

Windows

Zu prüfen sind:

Debian und Ubuntu

[RO] systemctl status apt-daily.timer --no-pager

[RO] systemctl status apt-daily-upgrade.timer --no-pager

[RO][FILE] systemctl list-timers --all |
    grep -E 'apt|upgrade'

DNF-Systeme

[RO] systemctl list-timers --all |
    grep -E 'dnf|upgrade'

Je nach Distribution und Konfiguration kann beispielsweise dnf-automatic verwendet werden.

macOS

Zu prüfen sind:

Automatische Updateprozesse dürfen nicht beendet werden, ohne ihren aktuellen Transaktionszustand zu prüfen.

23. Updatefehler nach dem Neustart analysieren

Ein Update kann zunächst erfolgreich erscheinen und erst beim Neustart scheitern.

Typische Symptome

Prüfreihenfolge

  1. Exakte Meldung und Zeitpunkt dokumentieren.
  2. Prüfen, ob ein automatischer Rollback erfolgt ist.
  3. Update- und Bootprotokolle sichern.
  4. Zuletzt installierte Pakete ermitteln.
  5. Dienst- und Treiberstatus kontrollieren.
  6. Freien Speicherplatz prüfen.
  7. Abhängige Systeme und Clusterstatus berücksichtigen.
  8. Herstellerhinweise zum konkreten Update prüfen.
  9. Rücknahme nur nach Bewertung der Sicherheitsauswirkung durchführen.
  10. Vor erneuter Installation die ursprüngliche Ursache beheben.

Linux: vorherigen Boot untersuchen

[RO][PRIV][SENS] sudo journalctl -b -1 -p warning --no-pager

Windows: letzte Systemfehler

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    StartTime = (Get-Date).AddHours(-24)
} |
Where-Object {
    $_.LevelDisplayName -in 'Warning','Error','Warnung','Fehler'
} |
Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message
24. Updates in Clustern und hochverfügbaren Systemen

Bei Clustern, Replikationssystemen und redundanten Diensten reicht die Betrachtung eines einzelnen Servers nicht aus.

Vor einem Update prüfen

Gefahren

Ein Snapshot eines einzelnen Clusterknotens ist kein vollständiger Rückfallplan für einen verteilten Dienst.

25. Sichere Reihenfolge der Updatefehleranalyse
  1. Betroffenes Update, Paket oder KB eindeutig bestimmen.
  2. Originalen Fehlercode und Fehlerzeitpunkt dokumentieren.
  3. Betriebssystemversion, Build und Architektur prüfen.
  4. Updatephase bestimmen.
  5. Freien Speicherplatz und Inodes kontrollieren.
  6. Datum, Uhrzeit und Zeitzone prüfen.
  7. Ausstehenden Neustart berücksichtigen.
  8. Updatequelle, Repository, WSUS oder MDM ermitteln.
  9. DNS, Proxy, Firewall und Erreichbarkeit prüfen.
  10. Paketmanager- beziehungsweise Updatedienste untersuchen.
  11. Protokolle zum Fehlerzeitpunkt auswerten.
  12. Paketabhängigkeiten und Signaturen prüfen.
  13. Aktive Installations- oder Sperrprozesse identifizieren.
  14. Systemdateien beziehungsweise Paketdatenbank kontrollieren.
  15. Erst danach Cachebereinigung oder Reparaturmaßnahmen planen.
  16. Änderung im Wartungsfenster durchführen.
  17. Neustartbedarf kontrolliert umsetzen.
  18. Update-, Dienst- und Anwendungsfunktion verifizieren.
  19. Ergebnis und verbleibende Risiken dokumentieren.
26. Typische Fehlinterpretationen vermeiden
Fehlinterpretation Richtige Bewertung
„Der Download hängt bei 0 Prozent.“ Verbindung, Metadatenprüfung oder Vorbereitung kann bereits laufen.
„Der Update-Dienst ist beendet.“ Bedarfsgesteuerter Dienst kann regulär beendet sein.
„Ping funktioniert, also ist Windows Update erreichbar.“ DNS, HTTPS, Proxy, CDN und Authentifizierung sind zusätzlich relevant.
„Ein Neustart ist immer harmlos.“ Produktivdienste, Cluster und Benutzer müssen berücksichtigt werden.
„Cache löschen behebt jeden Updatefehler.“ Es entfernt Symptome und erschwert möglicherweise die Diagnose.
„Signaturprüfung kann vorübergehend deaktiviert werden.“ Dadurch wird eine wichtige Sicherheitskontrolle umgangen.
„Get-HotFix zeigt alle installierten Updates.“ Es erfasst nicht jede Update- und Paketart.
„Rückgabecode 100 von dnf ist ein Fehler.“ Bei dnf check-update kann er verfügbare Updates anzeigen.
„Eine Sperrdatei kann einfach gelöscht werden.“ Eine aktive Pakettransaktion könnte beschädigt werden.
„Update fehlgeschlagen bedeutet fehlerhaftes Update.“ Ursache kann lokal in Speicher, Netzwerk, Zeit oder Paketstatus liegen.
„Snapshot entspricht einer Sicherung.“ Snapshot und unabhängige Sicherung erfüllen unterschiedliche Aufgaben.
„Update erfolgreich bedeutet Dienst funktionsfähig.“ Nachkontrolle von Diensten und Anwendungen bleibt erforderlich.
27. Schnelle Befehlsübersicht
Aufgabe Windows Debian/Ubuntu RHEL/Fedora macOS
Betriebssystemversion [RO] Get-ComputerInfo [RO] cat /etc/os-release [RO] cat /etc/os-release [RO] sw_vers
Architektur [RO] Get-CimInstance Win32_OperatingSystem [RO] dpkg --print-architecture [RO] uname -m [RO] uname -m
Freier Speicher [RO] Get-Volume [RO] df -hT [RO] df -hT [RO] df -h
Updatequelle Richtlinien und WSUS prüfen APT-Quelldateien prüfen [RO] dnf repolist MDM und Updateeinstellungen
Updatedienste [RO] Get-Service wuauserv,bits,cryptsvc,trustedinstaller APT-Timer und Prozesse DNF-Timer und Prozesse macOS-Systemdienst
Updatehistorie Get-HotFix und DISM APT- und dpkg-Protokolle [RO] dnf history [RO] softwareupdate --history
Verfügbare Updates Windows-Updateverwaltung [CHANGE][PRIV] sudo apt update [TEST][PRIV] sudo dnf check-update [TEST] softwareupdate --list
Paketstatus prüfen DISM [RO][PRIV] sudo dpkg --audit [TEST][PRIV] sudo dnf check Updateprotokoll prüfen
Abhängigkeiten prüfen CBS- und DISM-Protokoll [TEST][PRIV] sudo apt-get check [TEST][PRIV] sudo dnf check Nicht direkt vergleichbar
Paketversion DISM oder Get-HotFix [RO] apt-cache policy "<PAKET>" [RO] rpm -q "<PAKET>" Anwendungsspezifisch
Ausstehender Neustart Registryindikatoren prüfen /var/run/reboot-required kann distributionsabhängig existieren Paket- und Kernelstatus prüfen Update- und MDM-Status prüfen
Protokolle Get-WindowsUpdateLog, CBS, Ereignisanzeige /var/log/apt, /var/log/dpkg.log, Journal dnf history, Journal [RO][PRIV] log show ...
Systemintegrität [TEST][PRIV] DISM /ScanHealth Paketdatenbank prüfen [TEST][PRIV] rpm -Va Festplatten- und Updateprotokolle
Proxy [RO] netsh winhttp show proxy APT- und Umgebungsvariablen prüfen DNF- und Umgebungsvariablen prüfen Netzwerk- und MDM-Konfiguration
28. Entscheidungsmatrix
Befund Wahrscheinliche Ursache Nächster Schritt
Update wird nicht angeboten Richtlinie, Kanal, Kompatibilität oder Supportstatus Quelle und Voraussetzungen prüfen
Download startet nicht DNS, Proxy, Firewall oder Repository Netzwerkpfad untersuchen
Download wiederholt beschädigt Proxycache, Spiegelserver oder Datenträger Prüfsumme, Quelle und Speicher prüfen
Signatur ungültig Zeit, Schlüssel oder Zertifikatskette Zeit und Vertrauenskette prüfen
Nicht genügend Speicher System- oder temporäres Volume voll Speicherverbrauch analysieren
Paketmanager ist gesperrt Andere Transaktion aktiv Prozess und Protokolle prüfen
Paketabhängigkeit nicht erfüllbar Fehlendes Repository oder Versionskonflikt Abhängigkeitsbaum untersuchen
Neustart wird wiederholt verlangt Ausstehende Operation nicht abgeschlossen Pending-Reboot-Status und Protokolle prüfen
Update rollt zurück Installations-, Treiber- oder Bootfehler Setup- und Systemprotokolle auswerten
Mehrere Geräte betroffen Zentrale Quelle, Richtlinie oder Herstellerproblem Gemeinsamen Nenner ermitteln
Nur ein Gerät betroffen Lokaler Cache, Zustand oder Konfiguration Mit funktionierendem Vergleichssystem abgleichen
Update erfolgreich, Dienst ausgefallen Inkompatibilität oder Konfigurationsmigration Dienstprotokolle und Herstellerhinweise prüfen
Betriebssystem nicht mehr unterstützt Keine reguläre Updateversorgung Geplantes Upgrade beziehungsweise Migration
DNF endet mit Code 100 Updates verfügbar Nicht als Paketmanagerfehler behandeln
29. Dokumentationsvorlage 
Ticket:
Datum und Uhrzeit:
Bearbeiter:

Betroffenes System:
Betriebssystem:
Version und Build:
Architektur:
Systemrolle:
Physisch oder virtuell:
Cluster- oder Domänenmitglied:

Updateart:
KB-, Paket- oder Versionsnummer:
Updatequelle:
WSUS, Repository oder MDM:
Fehlerphase:
Originaler Fehlercode:
Originale Fehlermeldung:
Zeitpunkt des Fehlers:

Freier Speicher:
Inode-Belegung:
Datum und Uhrzeit:
Ausstehender Neustart:
Updatedienst:
Paketmanager:
Aktive Installationsprozesse:
Sperrstatus:

DNS-Auflösung:
Proxy:
Erreichbarkeit der Updatequelle:
Signatur- oder Zertifikatsfehler:
Repositorystatus:
Abhängigkeitsfehler:

Relevante Protokolle:
Letzte erfolgreiche Aktualisierung:
Letzte Änderungen:
Vergleich mit funktionierendem System:

Vermutete Ursache:
Durchgeführte Tests:
Sicherung geprüft:
Wartungsfenster:
Durchgeführte Änderung:
Neustart durchgeführt:
Rückfallplan:

Installationsstatus nach der Maßnahme:
Dienststatus:
Anwendungsprüfung:
Monitoring unauffällig:
Weiterführende Maßnahmen:

Merksatz

Bei Updatefehlern wird nicht sofort der Cache gelöscht oder das Paket erneut installiert. Zuerst werden Updatequelle, Fehlerphase, Fehlercode, Speicherplatz, Zeit, Netzwerk, Paketstatus und Protokolle geprüft.

Quellen und weiterführende Dokumentation

4. Server- und Dienstfehler systematisch analysieren

4.14 Virtualisierungs- und Containerfehler

Bei virtualisierten Systemen befindet sich die Ursache einer Störung nicht zwangsläufig innerhalb des betroffenen Servers oder Containers. Der Fehler kann im Gastbetriebssystem, Hypervisor, Hostbetriebssystem, virtuellen Netzwerk, Storage, Managementsystem oder in einer Abhängigkeit außerhalb der Virtualisierungsplattform liegen.

Typische Auswirkungen sind:

Wichtig: Eine laufende VM, ein laufender Container oder ein Status Up beweist nur, dass der jeweilige Prozess gestartet wurde. Damit ist noch nicht bestätigt, dass Betriebssystem, Anwendung, Netzwerk, Storage und Abhängigkeiten funktionieren.

Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] Nur lesender Befehl
[TEST] Führt eine aktive Prüfung aus
[PRIV] Erhöhte Berechtigungen erforderlich
[FILE] Liest Dateien, Images, Volumes oder Verzeichnisse
[SENS] Ausgabe kann sensible Informationen enthalten
[CHANGE] Verändert Konfiguration oder Systemzustand
[DISRUPT] Kann den Betrieb unterbrechen
1. Fehlerbereich zuerst eindeutig bestimmen

Virtualisierungsfehler müssen schichtweise eingegrenzt werden.

Anwendung
    │
Gastbetriebssystem oder Container
    │
Virtuelle Netzwerkkarte und virtueller Datenträger
    │
Hypervisor beziehungsweise Container-Engine
    │
Hostbetriebssystem
    │
Physisches Netzwerk und Storage
    │
Hardware

Erste Prüffragen

Erste Einordnung

Beobachtung Wahrscheinlicher Fehlerbereich
Nur ein Dienst in einer VM gestört Anwendung oder Gastbetriebssystem
Gesamte VM nicht erreichbar, Konsole funktioniert Gastnetzwerk oder virtueller Switch
Gesamte VM reagiert auch über Konsole nicht Gast, Ressourcen oder virtueller Datenträger
Mehrere VMs auf einem Host betroffen Host, Hypervisor, Netzwerk oder Storage
VMs auf mehreren Hosts betroffen Gemeinsames Netzwerk, Cluster oder Storage
Nur ein Container beendet sich Anwendung, Image oder Containerkonfiguration
Alle Container reagieren nicht Container-Engine, Host oder gemeinsame Ressource
Container läuft, veröffentlichter Port fehlt Portfreigabe oder Netzwerkkonfiguration
Daten fehlen nach Neuerstellung Volume oder Bind-Mount nicht korrekt eingebunden
2. VM, Container, Image und Host unterscheiden
Begriff Bedeutung
Host Physisches oder virtuelles System, das VMs oder Container ausführt
Hypervisor Virtualisierungsschicht für virtuelle Maschinen
Virtuelle Maschine Virtuelles Computersystem mit eigenem Betriebssystemkernel
Gastbetriebssystem Betriebssystem innerhalb einer VM
Container-Engine Verwaltet Images, Container, Netzwerke und Volumes
Image Unveränderliche Vorlage für einen Container
Container Laufende oder beendete Instanz eines Images
Volume Von der Containerlebensdauer getrennter persistenter Speicher
Bind-Mount Verzeichnis oder Datei des Hosts wird in den Container eingebunden
Snapshot beziehungsweise Checkpoint Zustandsaufnahme einer VM oder eines Datenträgers
Virtueller Switch Softwarebasierte Netzwerkverbindung für VMs
Portveröffentlichung Zuordnung eines Hostports zu einem Containerport

Wichtige Unterschiede

3. Hostzustand vor der Gastanalyse prüfen

Bevor eine VM oder ein Container verändert wird, muss der Hostzustand kontrolliert werden.

Prüfbereich Typische Auswirkung
CPU-Auslastung VMs und Container reagieren langsam
RAM-Auslastung OOM-Ereignisse, Swapping oder VM-Startfehler
Speicherplatz Images, Snapshots und virtuelle Datenträger können nicht wachsen
Inodes unter Linux Containerdateien können nicht erstellt werden
Storage-Latenz VMs frieren ein oder Datenbanken werden langsam
Netzwerk Mehrere Gäste verlieren gleichzeitig die Verbindung
Zeit Authentifizierung, Zertifikate und Cluster können fehlschlagen
Hypervisordienst VMs können nicht verwaltet oder gestartet werden
Container-Engine Containerstatus und Netzwerke sind nicht verfügbar

Windows-Host

[RO] Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, BuildNumber,
        FreePhysicalMemory, TotalVisibleMemorySize

[RO] Get-Volume |
    Select-Object DriveLetter, FileSystemLabel,
        HealthStatus, SizeRemaining, Size

[RO] Get-Counter `
    '\Processor(_Total)\% Processor Time',
    '\Memory\Available MBytes'

Linux-Host

[RO] uptime

[RO] free -h

[RO] df -hT

[RO] df -i

[RO] lsblk -f

[RO] vmstat 1 5

macOS-Host

[RO] uptime

[RO] vm_stat

[RO] df -h

[RO] diskutil list
4. Hyper-V-Host und virtuelle Maschinen prüfen

Die Hyper-V-PowerShell-Befehle sind nur verfügbar, wenn die Hyper-V-Verwaltungstools installiert sind.

Hyper-V-Hostinformationen anzeigen

[RO][PRIV] Get-VMHost |
    Select-Object Name, LogicalProcessorCount,
        MemoryCapacity, VirtualMachinePath,
        VirtualHardDiskPath

Alle virtuellen Maschinen anzeigen

[RO][PRIV] Get-VM |
    Select-Object Name, State, Status, CPUUsage,
        MemoryAssigned, Uptime, Version

Bestimmte VM anzeigen

[RO][PRIV] Get-VM -Name "<VM-NAME>" |
    Format-List *

Die vollständige Ausgabe kann sehr umfangreich sein.

Nur nicht normal laufende VMs anzeigen

[RO][PRIV] Get-VM |
    Where-Object {
        $_.State -ne 'Running' -or $_.Status -ne 'Operating normally'
    } |
    Select-Object Name, State, Status

Wichtige VM-Zustände

Zustand Bedeutung
Running VM ist eingeschaltet
Off VM ist ausgeschaltet
Paused Ausführung wurde angehalten
Saved VM-Zustand wurde gespeichert
Starting VM wird gestartet
Stopping VM wird beendet
Saving Zustand wird gespeichert
Critical im Status Hyper-V meldet einen kritischen Zustand

Ein Zustand Running sagt nichts darüber aus, ob das Gastbetriebssystem vollständig gestartet oder ein Dienst erreichbar ist.

5. Hyper-V-Arbeitsspeicher und CPU prüfen

VM-Arbeitsspeicher anzeigen

[RO][PRIV] Get-VMMemory -VMName "<VM-NAME>" |
    Select-Object VMName, DynamicMemoryEnabled,
        Startup, Minimum, Maximum, Buffer,
        Priority

Speicherzuweisung aller VMs anzeigen

[RO][PRIV] Get-VM |
    Select-Object Name, State,
        @{Name='MemoryAssigned_GB';Expression={
            [math]::Round($_.MemoryAssigned / 1GB, 2)
        }},
        CPUUsage, Uptime

Prozessorausweisung einer VM anzeigen

[RO][PRIV] Get-VMProcessor -VMName "<VM-NAME>" |
    Select-Object VMName, Count, Reserve,
        Maximum, RelativeWeight, CompatibilityForMigrationEnabled

Typische Ressourcenprobleme

Zusätzlich innerhalb der VM prüfen

Windows-Gast:

[RO] Get-Counter `
    '\Processor(_Total)\% Processor Time',
    '\Memory\Available MBytes'

Linux-Gast:

[RO] free -h

[RO] vmstat 1 5
6. Hyper-V-Netzwerk untersuchen

Virtuelle Switches anzeigen

[RO][PRIV] Get-VMSwitch |
    Select-Object Name, SwitchType, NetAdapterInterfaceDescription

Virtuelle Netzwerkadapter einer VM anzeigen

[RO][PRIV] Get-VMNetworkAdapter -VMName "<VM-NAME>" |
    Select-Object VMName, Name, SwitchName,
        Status, MacAddress, IPAddresses

Alle VM-Netzwerkadapter anzeigen

[RO][PRIV] Get-VMNetworkAdapter -All |
    Select-Object VMName, Name, SwitchName,
        Status, MacAddress, IPAddresses

VLAN-Konfiguration anzeigen

[RO][PRIV] Get-VMNetworkAdapterVlan -VMName "<VM-NAME>"

Erweiterte Adapterfunktionen anzeigen

[RO][PRIV] Get-VMNetworkAdapterAdvancedFeature `
    -VMName "<VM-NAME>"

Typische Ursachen

Hyper-V-Switchtypen

Typ Verbindung
External Verbindung zum physischen Netzwerk
Internal Kommunikation zwischen Host und VMs
Private Kommunikation nur zwischen VMs desselben Hosts
7. Hyper-V-Datenträger und Checkpoints prüfen

Virtuelle Festplatten einer VM anzeigen

[RO][PRIV] Get-VMHardDiskDrive -VMName "<VM-NAME>" |
    Select-Object VMName, ControllerType,
        ControllerNumber, ControllerLocation, Path

Informationen über eine bekannte VHD- oder VHDX-Datei

[RO][PRIV][SENS] Get-VHD -Path "<VHDX-PFAD>" |
    Select-Object Path, VhdFormat, VhdType,
        FileSize, Size, MinimumSize, ParentPath,
        Attached

Checkpoints einer VM anzeigen

[RO][PRIV] Get-VMSnapshot -VMName "<VM-NAME>" |
    Select-Object VMName, Name, SnapshotType,
        CreationTime, ParentSnapshotName

Checkpoints aller VMs anzeigen

[RO][PRIV] Get-VM |
    Get-VMSnapshot |
    Select-Object VMName, Name, SnapshotType,
        CreationTime

Speicherpfade und freien Speicher vergleichen

[RO] Get-Volume |
    Select-Object DriveLetter, FileSystemLabel,
        HealthStatus, SizeRemaining, Size

Typische Ursachen

AVHDX-Dateien und Snapshotketten dürfen nicht manuell im Dateisystem gelöscht oder umbenannt werden. Dadurch kann die virtuelle Festplattenkette unbrauchbar werden.

8. Hyper-V-Integrationsdienste und Ereignisprotokolle prüfen

Integrationsdienste einer VM anzeigen

[RO][PRIV] Get-VMIntegrationService -VMName "<VM-NAME>" |
    Select-Object Name, Enabled, PrimaryStatusDescription,
        SecondaryStatusDescription

Hyper-V-VMMS-Ereignisse

[RO][SENS] Get-WinEvent -LogName `
    'Microsoft-Windows-Hyper-V-VMMS-Admin' `
    -ErrorAction SilentlyContinue |
Select-Object -First 100 TimeCreated, LevelDisplayName, Id, Message

Hyper-V-Worker-Ereignisse

[RO][SENS] Get-WinEvent -LogName `
    'Microsoft-Windows-Hyper-V-Worker-Admin' `
    -ErrorAction SilentlyContinue |
Select-Object -First 100 TimeCreated, LevelDisplayName, Id, Message

Nur Ereignisse der letzten 24 Stunden

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-Hyper-V-VMMS-Admin'
    StartTime = (Get-Date).AddHours(-24)
} -ErrorAction SilentlyContinue |
Select-Object TimeCreated, LevelDisplayName, Id, Message

Typische Meldungsbereiche

9. KVM und libvirt unter Linux prüfen

Alle libvirt-VMs anzeigen

[RO][PRIV] sudo virsh list --all

Status einer VM

[RO][PRIV] sudo virsh domstate "<VM-NAME>"

Ausführliche VM-Informationen

[RO][PRIV][SENS] sudo virsh dominfo "<VM-NAME>"

Virtuelle Netzwerkadapter

[RO][PRIV][SENS] sudo virsh domiflist "<VM-NAME>"

Virtuelle Datenträger

[RO][PRIV][SENS] sudo virsh domblklist "<VM-NAME>" --details

VM-Ressourcenstatistik

[TEST][PRIV][SENS] sudo virsh domstats "<VM-NAME>"

Snapshots anzeigen

[RO][PRIV] sudo virsh snapshot-list "<VM-NAME>"

Virtuelle Netzwerke anzeigen

[RO][PRIV] sudo virsh net-list --all

Storage-Pools anzeigen

[RO][PRIV] sudo virsh pool-list --all

Storage-Volumes eines Pools anzeigen

[RO][PRIV][SENS] sudo virsh vol-list "<POOL-NAME>"

virsh kann je nach Verbindung auf eine lokale oder entfernte libvirt-Instanz zugreifen. Vor Änderungen muss geprüft werden, welche Verbindung und welcher Host tatsächlich verwendet werden.

10. KVM-, QEMU- und libvirt-Dienste untersuchen

Je nach Distribution und libvirt-Version können unterschiedliche Dienste verwendet werden.

Klassischer libvirt-Dienst

[RO] systemctl status libvirtd --no-pager

Modularer QEMU-Dienst

[RO] systemctl status virtqemud --no-pager

Laufende QEMU-Prozesse anzeigen

[RO][SENS] ps -ef | grep '[q]emu-system'

libvirt-Protokolle

[RO][PRIV][SENS] sudo journalctl -u libvirtd \
    --since "-24 hours" --no-pager

virtqemud-Protokolle

[RO][PRIV][SENS] sudo journalctl -u virtqemud \
    --since "-24 hours" --no-pager

Kernelunterstützung prüfen

[RO] lsmod | grep -E '^kvm|kvm_'

CPU-Virtualisierungsmerkmale anzeigen

[RO] lscpu |
    grep -E 'Virtualization|Hypervisor|Architecture'

KVM-Gerät prüfen

[RO][FILE] ls -l /dev/kvm

Typische Ursachen

11. VMware und andere Hypervisoren systematisch eingrenzen

Die genauen Befehle hängen von Produkt, Version und Managementplattform ab. Ohne bestätigte Plattform sollten keine produktspezifischen Befehle übernommen werden.

Zu prüfende Bereiche

Typische Fehler

Beobachtung Mögliche Ursache
VM ist „orphaned“ oder „inaccessible“ Konfigurationsdatei oder Datastore nicht erreichbar
Snapshot kann nicht erstellt werden Datastore voll oder Snapshotkette fehlerhaft
Migration scheitert CPU, Netzwerk, Storage oder Kompatibilität
VM-Netzwerk fehlt Portgruppe oder virtueller Switch falsch
Konsole funktioniert, Netzwerk nicht Gastnetzwerk, VLAN oder Portgruppe
Mehrere Hosts nicht verwaltbar Managementserver, Zertifikat oder Netzwerk
HA startet VM nicht Clusterkapazität, Admission Control oder Storage
Tools-Status veraltet Gasterweiterungen fehlen oder sind inkompatibel

Änderungen an Datastore-Dateien dürfen nur mit dokumentierten Herstellerverfahren durchgeführt werden.

12. Docker-Client und Docker-Daemon unterscheiden

Docker besteht mindestens aus:

Der Client kann installiert sein, obwohl der Daemon nicht erreichbar ist.

Client- und Serverversion anzeigen

[RO] docker version

Wenn nur der Clientbereich erscheint und der Serverbereich einen Fehler meldet, kann der Docker-Daemon nicht erreicht werden.

Ausführliche Docker-Informationen

[RO][SENS] docker info

Die Ausgabe kann enthalten:

Docker-Kontext anzeigen

[RO][SENS] docker context show

Alle Docker-Kontexte anzeigen

[RO][SENS] docker context ls

Ein falscher Docker-Kontext kann dazu führen, dass Befehle gegen einen anderen Host oder Docker Desktop statt gegen die erwartete Engine ausgeführt werden.

13. Docker-Dienst unter Linux prüfen

Docker-Dienststatus

[RO] systemctl status docker --no-pager

Container-Runtime prüfen

[RO] systemctl status containerd --no-pager

Docker-Protokolle der letzten 24 Stunden

[RO][PRIV][SENS] sudo journalctl -u docker \
    --since "-24 hours" --no-pager

containerd-Protokolle

[RO][PRIV][SENS] sudo journalctl -u containerd \
    --since "-24 hours" --no-pager

Docker-Socket prüfen

[RO][FILE] ls -l /var/run/docker.sock

Typische Fehlermeldungen

Meldung Mögliche Ursache
Cannot connect to the Docker daemon Daemon gestoppt, falscher Socket oder falscher Kontext
permission denied am Socket Benutzer besitzt keine erforderliche Berechtigung
no space left on device Speicherplatz oder Inodes ausgeschöpft
address already in use Hostport bereits belegt
network not found Konfiguriertes Docker-Netzwerk fehlt
volume not found Extern erwartetes Volume fehlt
manifest unknown Image oder Tag existiert nicht
no matching manifest Architektur oder Plattform wird nicht angeboten
pull access denied Registry, Anmeldung oder Berechtigung
toomanyrequests Registry-Limit erreicht
14. Containerstatus und Exit-Code prüfen

Laufende Container anzeigen

[RO][SENS] docker ps

Alle Container einschließlich beendeter Container

[RO][SENS] docker ps -a

Kompakte Zustandsübersicht

[RO][SENS] docker ps -a \
    --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'

Zustand eines Containers detailliert anzeigen

[RO][SENS] docker inspect "<CONTAINER>" \
    --format '{{json .State}}'

Wichtige Zustandsinformationen gezielt anzeigen

[RO][SENS] docker inspect "<CONTAINER>" \
    --format 'Status={{.State.Status}} ExitCode={{.State.ExitCode}} OOMKilled={{.State.OOMKilled}} Error={{.State.Error}} StartedAt={{.State.StartedAt}} FinishedAt={{.State.FinishedAt}}'

Neustartzähler anzeigen

[RO] docker inspect "<CONTAINER>" \
    --format 'RestartCount={{.RestartCount}}'

Typische Exit-Codes

Exit-Code Typische Bedeutung
0 Prozess wurde erfolgreich beendet
1 Allgemeiner Anwendungsfehler
2 Häufig falsche Argumente oder Anwendungsfehler
125 Docker konnte den Container nicht starten
126 Befehl gefunden, aber nicht ausführbar
127 Befehl nicht gefunden
137 Prozess erhielt häufig SIGKILL; OOM oder erzwungenes Beenden möglich
139 Segmentation Fault möglich
143 Prozess erhielt normalerweise SIGTERM

Ein Exit-Code beschreibt zunächst nur das Ende des Hauptprozesses. Die genaue Ursache muss mit Containerprotokoll, Docker-Ereignissen und Hostmeldungen bestätigt werden.

15. Containerprotokolle sicher auswerten

Letzte 100 Protokollzeilen

[RO][SENS] docker logs --tail 100 "<CONTAINER>"

Protokolle mit Zeitstempeln

[RO][SENS] docker logs --timestamps --tail 100 "<CONTAINER>"

Protokolle seit einem bestimmten Zeitraum

[RO][SENS] docker logs --since 1h "<CONTAINER>"

Protokolle fortlaufend beobachten

[TEST][SENS] docker logs --follow --tail 100 "<CONTAINER>"

Die fortlaufende Ausgabe wird mit Strg + C beendet. Dadurch wird normalerweise nicht der Container beendet, sondern nur die lokale Anzeige.

Wichtige Einschränkungen

16. Healthcheck und Anwendungszustand prüfen

Ein Docker-Healthcheck bewertet einen im Image oder Container definierten Test.

Healthcheckstatus anzeigen

[RO][SENS] docker inspect "<CONTAINER>" \
    --format '{{json .State.Health}}'

Kompakte Anzeige

[RO][SENS] docker inspect "<CONTAINER>" \
    --format 'Status={{.State.Status}} Health={{if .State.Health}}{{.State.Health.Status}}{{else}}nicht definiert{{end}}'

Healthcheck-Konfiguration anzeigen

[RO][SENS] docker inspect "<CONTAINER>" \
    --format '{{json .Config.Healthcheck}}'

Mögliche Health-Zustände

Zustand Bedeutung
starting Startphase oder noch nicht genügend Prüfungen
healthy Definierter Test war erfolgreich
unhealthy Definierter Test ist wiederholt fehlgeschlagen
Nicht vorhanden Kein Docker-Healthcheck definiert

Wichtige Bewertung

17. Containerressourcen und OOM-Fehler untersuchen

Aktuelle Ressourcennutzung einmalig anzeigen

[TEST][SENS] docker stats --no-stream

Nur einen Container anzeigen

[TEST][SENS] docker stats --no-stream "<CONTAINER>"

Konfigurierte Ressourcenlimits anzeigen

[RO][SENS] docker inspect "<CONTAINER>" \
    --format 'Memory={{.HostConfig.Memory}} MemorySwap={{.HostConfig.MemorySwap}} NanoCPUs={{.HostConfig.NanoCpus}} PidsLimit={{.HostConfig.PidsLimit}}'

Prüfen, ob der Container wegen Speichermangel beendet wurde

[RO] docker inspect "<CONTAINER>" \
    --format 'OOMKilled={{.State.OOMKilled}} ExitCode={{.State.ExitCode}}'

Linux-Kernelmeldungen zu OOM

[RO][PRIV][SENS] sudo journalctl -k -b --no-pager |
    grep -Ei 'out of memory|oom-kill|killed process'

Typische Ursachen

Ein höheres Speicherlimit behebt kein Speicherleck. Zuerst müssen Verbrauch, Wachstum und Anwendungsprotokolle untersucht werden.

18. Docker-Prozesse und Hauptprozess prüfen

Prozesse im Container anzeigen

[RO][SENS] docker top "<CONTAINER>"

Konfigurierten Startbefehl anzeigen

[RO][SENS] docker inspect "<CONTAINER>" \
    --format 'Entrypoint={{json .Config.Entrypoint}} Cmd={{json .Config.Cmd}}'

Arbeitsverzeichnis und Benutzer anzeigen

[RO][SENS] docker inspect "<CONTAINER>" \
    --format 'User={{.Config.User}} WorkingDir={{.Config.WorkingDir}}'

Typische Ursachen eines sofortigen Containerendes

Ein Container bleibt nur so lange aktiv, wie sein Hauptprozess läuft. Das erfolgreiche Erstellen des Containers bedeutet nicht, dass dieser Prozess dauerhaft läuft.

19. Docker-Portveröffentlichungen und Listener prüfen

Portzuordnungen aller Container

[RO][SENS] docker ps \
    --format 'table {{.Names}}\t{{.Ports}}'

Portzuordnung eines Containers

[RO][SENS] docker port "<CONTAINER>"

Detaillierte Portkonfiguration

[RO][SENS] docker inspect "<CONTAINER>" \
    --format '{{json .NetworkSettings.Ports}}'

Listener auf dem Linux-Host

[RO][PRIV][SENS] sudo ss -lntup

Listener auf Windows

[RO][PRIV][SENS] Get-NetTCPConnection -State Listen |
    Sort-Object LocalPort |
    Select-Object LocalAddress, LocalPort, OwningProcess

Listener auf macOS

[RO][PRIV][SENS] sudo lsof -nP -iTCP -sTCP:LISTEN

Wichtige Unterscheidung

Client
  │
  ▼
Host-IP:Hostport
  │
Portveröffentlichung
  ▼
Container-IP:Containerport
  │
  ▼
Anwendungslistener

Ein Fehler kann an jeder Stelle liegen.

Typische Ursachen

20. Docker-Netzwerke und DNS untersuchen

Docker-Netzwerke anzeigen

[RO][SENS] docker network ls

Netzwerkdetails anzeigen

[RO][SENS] docker network inspect "<NETZWERK>"

Die Ausgabe kann Container-IP-Adressen, Netzwerknamen und weitere interne Informationen enthalten.

Netzwerke eines Containers anzeigen

[RO][SENS] docker inspect "<CONTAINER>" \
    --format '{{json .NetworkSettings.Networks}}'

DNS-Konfiguration im Container anzeigen

[RO][SENS] docker exec "<CONTAINER>" cat /etc/resolv.conf

Der Befehl funktioniert nur, wenn der Container läuft und cat im Image vorhanden ist.

Namensauflösung im Container testen

[TEST][SENS] docker exec "<CONTAINER>" \
    getent hosts "<ZIELNAME>"

getent ist nicht in jedem Container-Image vorhanden.

TCP-Verbindung aus einem Container testen

[TEST][SENS] docker exec "<CONTAINER>" \
    curl -v --connect-timeout 5 "http://<ZIEL>:<PORT>/"

curl ist nicht in jedem Image installiert. Fehlende Diagnosewerkzeuge dürfen nicht unkontrolliert in einen Produktivcontainer installiert werden.

Typische Ursachen

localhost innerhalb eines Containers bezeichnet normalerweise den Container selbst und nicht den Docker-Host oder einen anderen Container.

21. Docker-Volumes und Bind-Mounts untersuchen

Volumes anzeigen

[RO][SENS] docker volume ls

Volumeinformationen anzeigen

[RO][SENS] docker volume inspect "<VOLUME>"

Mounts eines Containers anzeigen

[RO][SENS] docker inspect "<CONTAINER>" \
    --format '{{json .Mounts}}'

Kompakte Mountübersicht

[RO][SENS] docker inspect "<CONTAINER>" \
    --format '{{range .Mounts}}{{println .Type .Source "->" .Destination "RW=" .RW}}{{end}}'

Speicherverbrauch der Docker-Objekte

[TEST][SENS] docker system df

Ausführlich:

[TEST][SENS] docker system df -v

Typische Ursachen fehlender Daten

docker volume prune und docker system prune dürfen nicht als allgemeine Fehlerbehebung ausgeführt werden. Sie können nicht verwendete, aber weiterhin benötigte Daten oder Images entfernen.

22. Docker-Images und Architektur prüfen

Lokale Images anzeigen

[RO][SENS] docker image ls

Imageinformationen anzeigen

[RO][SENS] docker image inspect "<IMAGE>:<TAG>"

Architektur eines lokalen Images

[RO] docker image inspect "<IMAGE>:<TAG>" \
    --format 'OS={{.Os}} Architecture={{.Architecture}}'

Hostarchitektur

Linux:

[RO] uname -m

macOS:

[RO] uname -m

Windows:

[RO] Get-CimInstance Win32_OperatingSystem |
    Select-Object OSArchitecture

Typische Fehlermeldungen

Meldung Mögliche Ursache
no matching manifest Image unterstützt die Hostplattform nicht
exec format error Binärdatei besitzt falsche Architektur oder fehlerhaften Interpreter
manifest unknown Tag oder Image existiert nicht
pull access denied Privates Image oder falscher Name
unauthorized Registryanmeldung oder Berechtigung fehlt
certificate signed by unknown authority Registryzertifikat wird nicht vertraut
unexpected EOF Download oder Netzwerkverbindung abgebrochen

Multi-Architektur-Images

Ein Image-Tag kann verschiedene plattformspezifische Manifestvarianten enthalten. Deshalb muss geprüft werden, ob genau die benötigte Kombination aus Betriebssystem und Architektur angeboten wird.

23. Umgebungsvariablen und Geheimnisse prüfen

Konfigurierte Containerumgebung anzeigen

[RO][SENS] docker inspect "<CONTAINER>" \
    --format '{{range .Config.Env}}{{println .}}{{end}}'

Diese Ausgabe kann Passwörter, Tokens, API-Schlüssel und Datenbankzugänge enthalten. Sie darf nicht unredigiert in Tickets, Dokumentationen oder externe Systeme kopiert werden.

Nur Namen der Umgebungsvariablen anzeigen

[RO][SENS] docker inspect "<CONTAINER>" \
    --format '{{range .Config.Env}}{{println .}}{{end}}' |
    sed 's/=.*$/=<REDACTED>/'

Typische Fehler

Sicherheitsregel

Geheimnisse sollten nicht dauerhaft als Klartext in:

gespeichert werden.

24. Docker-Compose-Projekte untersuchen

Je nach Installation wird das aktuelle Plugin mit docker compose verwendet. Ältere Systeme können noch das separate Werkzeug docker-compose besitzen.

Projektstatus anzeigen

[RO][SENS] docker compose ps -a

Compose-Prozesse anzeigen

[RO][SENS] docker compose top

Letzte Protokollzeilen aller Dienste

[RO][SENS] docker compose logs --tail 100

Protokoll eines Dienstes

[RO][SENS] docker compose logs --tail 100 "<DIENST>"

Zusammengeführte Konfiguration prüfen

[RO][SENS] docker compose config

docker compose config kann aufgelöste Umgebungsvariablen und sensible Werte enthalten. Die Ausgabe muss vor Weitergabe redigiert werden.

Dienste der Konfiguration anzeigen

[RO] docker compose config --services

Images der Konfiguration anzeigen

[RO][SENS] docker compose config --images

Typische Compose-Fehler

25. Docker-Ereignisse und Neustartschleifen untersuchen

Ereignisse der letzten Stunde

[RO][SENS] docker events --since 1h

Der Befehl wartet nach Ausgabe vorhandener Ereignisse auf neue Ereignisse und wird mit Strg + C beendet.

Ereignisse eines Containers

[RO][SENS] docker events \
    --since 1h \
    --filter container="<CONTAINER>"

Nur bestimmte Ereignistypen

[RO][SENS] docker events \
    --since 1h \
    --filter container="<CONTAINER>" \
    --filter event=die

Neustartrichtlinie anzeigen

[RO] docker inspect "<CONTAINER>" \
    --format '{{json .HostConfig.RestartPolicy}}'

Typische Neustartrichtlinien

Richtlinie Verhalten
no Kein automatischer Neustart
always Container wird grundsätzlich neu gestartet
unless-stopped Neustart, außer er wurde ausdrücklich beendet
on-failure Neustart bei fehlerhaftem Exit-Code

Eine Neustartrichtlinie kann die eigentliche Störung verdecken. Der Container erscheint wiederholt kurz als laufend, obwohl der Hauptprozess ständig abstürzt.

Prüfreihenfolge bei Neustartschleifen

  1. Neustartzähler erfassen.
  2. Exit-Code und OOM-Status prüfen.
  3. Protokolle mit Zeitstempeln lesen.
  4. Startbefehl und Umgebungsvariablen kontrollieren.
  5. Mounts und Berechtigungen prüfen.
  6. Abhängige Dienste untersuchen.
  7. Hostereignisse und Speicherzustand prüfen.
  8. Erst danach über Änderungen an der Neustartrichtlinie entscheiden.
26. Docker Desktop unter Windows und macOS eingrenzen

Docker Desktop führt Linux-Container normalerweise innerhalb einer verwalteten Virtualisierungsumgebung aus. Dadurch existieren zusätzliche Schichten:

Docker-Client
    │
Docker Desktop
    │
Verwaltete Linux-VM beziehungsweise Virtualisierungsschicht
    │
Docker Engine
    │
Container

Plattformübergreifende Prüfungen

[RO] docker version

[RO][SENS] docker info

[RO][SENS] docker context ls

[RO][SENS] docker ps -a

[TEST][SENS] docker system df

Zusätzlich unter Windows prüfen

WSL-Status anzeigen

[RO] wsl --status

WSL-Distributionen anzeigen

[RO][SENS] wsl --list --verbose

Zusätzlich unter macOS prüfen

Das Beenden oder Zurücksetzen von Docker Desktop kann alle laufenden Container unterbrechen. Ein Factory Reset kann lokale Images, Container, Netzwerke und andere Daten entfernen und darf nicht als allgemeine Diagnosemaßnahme verwendet werden.

27. Podman-Container unter Linux untersuchen

Podman besitzt viele Docker-ähnliche Befehle, verwendet aber kein identisches Betriebsmodell. Rootless- und Rootful-Container besitzen getrennte Ansichten.

Container anzeigen

[RO][SENS] podman ps -a

Podman-Systeminformationen

[RO][SENS] podman info

Containerdetails

[RO][SENS] podman inspect "<CONTAINER>"

Protokolle

[RO][SENS] podman logs --tail 100 "<CONTAINER>"

Ressourcennutzung

[TEST][SENS] podman stats --no-stream

Netzwerke

[RO][SENS] podman network ls

Volumes

[RO][SENS] podman volume ls

Speicherverbrauch

[TEST][SENS] podman system df

Wichtige Besonderheit

Ein Container, der als normaler Benutzer erstellt wurde, erscheint normalerweise nicht automatisch in der Root-Ansicht:

[RO][SENS] podman ps -a

und:

[RO][PRIV][SENS] sudo podman ps -a

können deshalb unterschiedliche Container anzeigen.

28. Snapshots, Checkpoints und Sicherungen richtig bewerten

Snapshots und Checkpoints speichern abhängig von der Plattform:

Sie sind für kurzfristige Rückfallpunkte geeignet, ersetzen aber keine unabhängige Sicherung.

Risiken lang bestehender Snapshots

Vor einer Snapshotaktion prüfen

Snapshotdateien niemals manuell löschen. Erstellung, Zusammenführung und Entfernung müssen über das vorgesehene Managementwerkzeug erfolgen.

29. Zeitfehler in virtuellen Systemen untersuchen

Eine VM kann Zeit aus mehreren Quellen erhalten:

Windows-Gast

[RO] w32tm /query /source

[RO] w32tm /query /status

Linux-Gast

[RO] timedatectl status

[RO] chronyc tracking

falls chrony verwendet wird.

Typische Ursachen

Bei Authentifizierungs-, Zertifikats- und Protokollproblemen sollte die Zeit frühzeitig geprüft werden.

30. Kritische Änderungen und gefährliche Schnelllösungen

Folgende Maßnahmen dürfen nicht unkontrolliert durchgeführt werden:

Maßnahme Risiko
VM hart ausschalten Datenverlust und Dateisystemfehler
Container mit kill beenden Anwendung erhält keine reguläre Beendigungszeit
Docker Factory Reset Verlust lokaler Docker-Daten
docker system prune Entfernt nicht verwendete Docker-Objekte
docker volume prune Kann persistente Daten entfernen
Snapshotdateien manuell löschen Virtuelle Datenträgerkette kann unbrauchbar werden
VHDX oder QCOW2 während des Betriebs kopieren Kopie kann inkonsistent sein
VM auf Snapshot zurücksetzen Neuere Daten und Zustände gehen verloren
Hypervisordienst neu starten Mehrere VMs können betroffen sein
Netzwerkbrücke oder Switch neu erstellen Alle verbundenen Gäste können getrennt werden
Storage aushängen VMs und Container verlieren Datenträgerzugriff
Rechte auf Docker-Socket weit öffnen Praktisch administrative Kontrolle über den Host
Secrets unredigiert exportieren Zugangsdaten werden offengelegt

Vor einer Änderung erforderlich

31. Sichere Reihenfolge der Fehleranalyse
  1. Betroffene Anwendung, VM oder Container eindeutig bestimmen.
  2. Umfang der Störung feststellen.
  3. Host, Hypervisor und Managementzugang prüfen.
  4. Hostressourcen und Speicherplatz kontrollieren.
  5. VM- beziehungsweise Containerstatus und Startzeit erfassen.
  6. Exit-Code, Healthcheck und Ereignisse prüfen.
  7. Protokolle zum Fehlerzeitpunkt auswerten.
  8. Virtuelles Netzwerk und Portzuordnung untersuchen.
  9. Virtuelle Datenträger, Volumes und Mounts kontrollieren.
  10. Abhängige Dienste und Namensauflösung prüfen.
  11. Ressourcenlimits und OOM-Ereignisse untersuchen.
  12. Image-, Versions- und Architekturkompatibilität prüfen.
  13. Snapshot-, Migrations- und Änderungsverlauf berücksichtigen.
  14. Sicherung und Rückfallplan verifizieren.
  15. Erst danach eine Änderung oder einen kontrollierten Neustart durchführen.
  16. Anwendung aus interner und externer Sicht testen.
  17. Host, VM, Container und Monitoring erneut kontrollieren.
  18. Ursache und Maßnahme dokumentieren.
32. Schnelle Befehlsübersicht
Aufgabe Hyper-V KVM/libvirt Docker auf Windows, Linux und macOS
Hostinformationen [RO][PRIV] Get-VMHost Hostbefehle wie free, df, uptime [RO][SENS] docker info
Alle Gäste [RO][PRIV] Get-VM [RO][PRIV] sudo virsh list --all [RO][SENS] docker ps -a
Gaststatus [RO][PRIV] Get-VM -Name "<VM>" [RO][PRIV] sudo virsh domstate "<VM>" [RO] docker inspect "<CONTAINER>" --format '{{json .State}}'
Ressourcen VM-, Host- und Performance-Counter [TEST][PRIV] sudo virsh domstats "<VM>" [TEST] docker stats --no-stream
Netzwerke [RO][PRIV] Get-VMSwitch [RO][PRIV] sudo virsh net-list --all [RO] docker network ls
Gastnetzadapter [RO][PRIV] Get-VMNetworkAdapter -VMName "<VM>" [RO][PRIV] sudo virsh domiflist "<VM>" [RO] docker inspect "<CONTAINER>" --format '{{json .NetworkSettings.Networks}}'
Datenträger [RO][PRIV] Get-VMHardDiskDrive -VMName "<VM>" [RO][PRIV] sudo virsh domblklist "<VM>" --details [RO] docker inspect "<CONTAINER>" --format '{{json .Mounts}}'
Snapshots [RO][PRIV] Get-VMSnapshot -VMName "<VM>" [RO][PRIV] sudo virsh snapshot-list "<VM>" Nicht direkt vergleichbar
Protokolle Hyper-V-Ereignisprotokolle Journal und VM-Protokolle [RO][SENS] docker logs --tail 100 "<CONTAINER>"
Ereignisse Windows-Ereignisanzeige Journal [RO][SENS] docker events --since 1h
Ports Gast und virtuellen Switch prüfen Gast und Bridge prüfen [RO] docker port "<CONTAINER>"
Volumes VHD/VHDX und Hostvolume Storage-Pools und Volumes [RO] docker volume ls
Speicherverbrauch Hostvolume und VHDX-Größe df, Pools und Images [TEST] docker system df -v
Architektur Host- und Gastarchitektur [RO] uname -m docker image inspect ... --format '{{.Architecture}}'
Healthcheck Gast- beziehungsweise anwendungsspezifisch Gast- beziehungsweise anwendungsspezifisch docker inspect ... --format '{{json .State.Health}}'
33. Entscheidungsmatrix
Befund Wahrscheinliche Ursache Nächster Schritt
VM läuft, Konsole funktioniert, Netzwerk nicht Gastnetzwerk, Switch oder VLAN Virtuelle und interne Netzwerkkonfiguration prüfen
VM startet nicht, Host-RAM knapp Ressourcenproblem Host- und VM-Speicherzuweisung prüfen
Mehrere VMs frieren ein Host oder gemeinsames Storage Hostlast und Storage-Latenz prüfen
Snapshot wächst stark Viele Schreibänderungen oder alter Snapshot Zweck, Größe und Zusammenführung planen
Container endet mit Code 127 Startbefehl nicht gefunden Entrypoint, Cmd und Image prüfen
Container endet mit Code 137 OOM oder erzwungenes Beenden möglich OOM-Status und Hostprotokolle prüfen
Container läuft, Anwendung nicht erreichbar Listener, Port oder Healthcheck Containerlistener und Portzuordnung prüfen
Port kann nicht gebunden werden Hostport bereits belegt Hostlistener und Compose-Konfiguration prüfen
Container findet Datenbank nicht DNS, Netzwerk oder Hostname Gemeinsames Netzwerk und Dienstnamen prüfen
Daten nach Neuerstellung weg Fehlendes oder falsches Volume Mountkonfiguration und vorhandene Volumes prüfen
Image startet auf ARM nicht Plattform nicht unterstützt Imagearchitektur und Manifest prüfen
Docker-Client findet Daemon nicht Dienst, Socket oder Kontext docker version, Dienst und Kontext prüfen
Nur Root sieht Podman-Container Rootful- und Rootless-Ansicht Richtigen Benutzerkontext verwenden
Host hat Platz, Docker meldet voll Docker-Disk, Inodes oder Storage-Layer docker system df, df und Inodes prüfen
Nach Snapshot stimmen Anmeldungen nicht Zeitabweichung Gastzeit und Zeitquelle prüfen
34. Dokumentationsvorlage 
Ticket:
Datum und Uhrzeit:
Bearbeiter:

Betroffene Plattform:
Hypervisor oder Container-Engine:
Version:
Host:
Hostbetriebssystem:
Physischer oder virtueller Host:
Cluster:
Managementsystem:

Betroffene VM oder Container:
VM- beziehungsweise Container-ID:
Image und Tag:
Gastbetriebssystem:
Architektur:
Aktueller Zustand:
Startzeit:
Uptime:
Exit-Code:
Healthcheck:
Neustartzähler:

Umfang der Störung:
Originale Fehlermeldung:
Fehlerzeitpunkt:
Letzte funktionierende Nutzung:
Letzte Änderung:
Update, Snapshot oder Migration:

Host-CPU:
Host-RAM:
Hostspeicher:
Inode-Belegung:
Storage-Zustand:
Virtueller Datenträger:
Snapshots oder Checkpoints:

Virtueller Switch oder Netzwerk:
VLAN:
IP-Adresse:
DNS:
Portveröffentlichung:
Hostlistener:
Containerlistener:
Firewall:

Volumes und Mounts:
Berechtigungen:
Umgebungsvariablen geprüft:
Sensible Werte redigiert:
Abhängige Dienste:
Zeitquelle:

Relevante Hostprotokolle:
Hypervisorprotokolle:
Gastprotokolle:
Containerprotokolle:
OOM-Ereignisse:

Vermutete Ursache:
Durchgeführte Tests:
Sicherung geprüft:
Wartungsfenster:
Durchgeführte Änderung:
Rückfallplan:

Status nach der Maßnahme:
Interne Funktionsprüfung:
Externe Funktionsprüfung:
Monitoring:
Weiterführende Maßnahmen:

Merksatz

Bei Virtualisierungs- und Containerfehlern wird immer von außen nach innen geprüft: Host, Virtualisierungsschicht, Netzwerk und Storage, Gast beziehungsweise Container und erst danach die Anwendung. Ein Status Running oder Up ist noch kein Funktionsnachweis.

Quellen und weiterführende Dokumentation

5. Werkzeuge der Fehleranalyse

5. Werkzeuge der Fehleranalyse

5.1 Windows – Integrierte Werkzeuge zur Fehleranalyse

Windows stellt zahlreiche grafische Werkzeuge, Befehlszeilenprogramme und PowerShell-Cmdlets zur systematischen Fehleranalyse bereit. Damit lassen sich unter anderem Ereignisprotokolle, Prozesse, Dienste, Ressourcen, Datenträger, Netzwerkverbindungen, Systemdateien und Abstürze untersuchen.

Die Werkzeuge liefern jedoch zunächst nur Befunde. Einzelne Warnungen, hohe Messwerte oder Ereignis-IDs beweisen noch keine Ursache. Ergebnisse müssen immer mit Fehlerzeitpunkt, Symptomen, Änderungen und weiteren Datenquellen abgeglichen werden.

Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] Nur lesender Befehl
[TEST] Führt einen aktiven Test aus
[CHANGE] Kann den Systemzustand verändern
[PRIV] Erfordert möglicherweise administrative Rechte
[SENS] Ausgabe kann sensible Informationen enthalten
[RESTART] Neustart oder Unterbrechung möglich

Befehle mit [CHANGE], [RESTART] oder [SENS] müssen vor ihrer Verwendung besonders sorgfältig geprüft werden.

1. Diagnosewerkzeuge gezielt auswählen
Fragestellung Geeignetes Werkzeug
Was geschah zum Fehlerzeitpunkt? Ereignisanzeige, Get-WinEvent
Welcher Prozess belastet das System? Task-Manager, Ressourcenmonitor, Get-Process
Welcher Dienst läuft nicht? Diensteverwaltung, Get-Service, sc.exe
Welches Programm öffnet einen Port? Ressourcenmonitor, Get-NetTCPConnection, netstat
Funktioniert die Namensauflösung? Resolve-DnsName, nslookup
Ist ein TCP-Port erreichbar? Test-NetConnection
Welche Route nimmt ein Paket? tracert, pathping
Ist ein Datenträger voll? Explorer, Datenträgerverwaltung, Get-Volume
Sind Windows-Systemdateien beschädigt? SFC und DISM
Warum wurde Windows neu gestartet? Ereignisanzeige, Get-WinEvent
Welche Treiber und Geräte sind vorhanden? Geräte-Manager, Get-PnpDevice, driverquery
Wie entwickelt sich die Leistung über Zeit? Leistungsüberwachung, Datenkollektorsätze
Welche Änderungen gingen der Störung voraus? Zuverlässigkeitsverlauf, Updateverlauf, Ereignisprotokolle
Warum ist Windows abgestürzt? Speicherabbild, WinDbg, Ereignisprotokolle

Grundregel

  1. Symptom und Zeitpunkt festhalten.
  2. Umfang der Störung bestimmen.
  3. Ereignisprotokolle zum betreffenden Zeitraum prüfen.
  4. Ressourcen und betroffene Komponenten untersuchen.
  5. Abhängigkeiten kontrollieren.
  6. Erst danach Änderungen durchführen.
  7. Ergebnis und Rückfallmöglichkeit dokumentieren.
2. Windows-Version und Systeminformationen erfassen

Windows-Versionsdialog öffnen

[RO] winver

Systeminformationen anzeigen

[RO][SENS] systeminfo

Die Ausgabe kann unter anderem Computername, Betriebssystemversion, Installationsdatum, Arbeitsspeicher, Domänenzugehörigkeit und installierte Hotfixes enthalten.

Windows-Version mit PowerShell

[RO] Get-ComputerInfo |
    Select-Object WindowsProductName,
                  WindowsVersion,
                  OsBuildNumber,
                  OsArchitecture

Betriebssystem über CIM abfragen

[RO] Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption,
                  Version,
                  BuildNumber,
                  OSArchitecture,
                  LastBootUpTime

Computer- und Hardwareinformationen

[RO][SENS] Get-ComputerInfo

Systeminformationen grafisch öffnen

[RO] msinfo32

msinfo32 enthält eine umfassende Übersicht über Hardware, Komponenten, Treiber, Ressourcen und die Softwareumgebung.

Systeminformationen können Computername, Benutzerbezug, Netzwerkdaten und installierte Software offenlegen. Exporte müssen vor einer Weitergabe geprüft werden.

3. Ereignisanzeige verwenden

Ereignisanzeige öffnen

[RO] eventvwr.msc

Wichtige Windows-Protokolle

Protokoll Typische Inhalte
Anwendung Ereignisse von Programmen und Anwendungsdiensten
Sicherheit Anmeldungen, Zugriffsprüfungen und Sicherheitsereignisse
Setup Installation und Einrichtung von Windows-Komponenten
System Treiber, Dienste, Hardware und Betriebssystemkomponenten
Weitergeleitete Ereignisse Von anderen Computern empfangene Ereignisse

Unter Anwendungs- und Dienstprotokolle befinden sich zusätzliche komponentenspezifische Protokolle, beispielsweise für PowerShell, Windows Defender, DNS, Gruppenrichtlinien oder Remotedesktopdienste.

Ereignisstufen

Stufe Bedeutung
Kritisch Schwerwiegendes Ereignis, häufig mit Ausfall oder unerwartetem Neustart
Fehler Eine Funktion oder Operation ist fehlgeschlagen
Warnung Mögliches Problem oder auffälliger Zustand
Information Regulärer Vorgang oder Statusmeldung
Ausführlich Besonders detaillierte Diagnoseinformation

Wichtige Bewertungsregeln

Benutzerdefinierte Ansicht erstellen

  1. Ereignisanzeige öffnen.
  2. Benutzerdefinierte Ansichten auswählen.
  3. Benutzerdefinierte Ansicht erstellen öffnen.
  4. Zeitraum und Ereignisstufen festlegen.
  5. Benötigte Protokolle oder Quellen auswählen.
  6. Filter speichern und Ergebnisse chronologisch untersuchen.

Das bloße Löschen eines Ereignisprotokolls behebt keine Ursache und vernichtet möglicherweise wichtige Diagnoseinformationen.

4. Windows-Ereignisse mit PowerShell untersuchen

Verfügbare klassische Protokolle anzeigen

[RO] Get-WinEvent -ListLog * |
    Select-Object LogName, RecordCount, IsEnabled

Letzte 50 Systemereignisse

[RO][SENS] Get-WinEvent -LogName System -MaxEvents 50

Fehler und kritische Ereignisse der letzten 24 Stunden

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    Level     = 1, 2
    StartTime = (Get-Date).AddHours(-24)
} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message

Ereignisse einer bestimmten Quelle

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Service Control Manager'
    StartTime    = (Get-Date).AddDays(-1)
} | Select-Object TimeCreated, Id, LevelDisplayName, Message

Bestimmte Ereignis-ID suchen

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    Id        = 6008
    StartTime = (Get-Date).AddDays(-7)
}

Ergebnisse exportieren

[RO][SENS] Get-WinEvent -LogName System -MaxEvents 500 |
    Export-Csv -Path ".\systemereignisse.csv" -NoTypeInformation -Encoding UTF8

Exportierte Ereignisse können Benutzernamen, Computerbezeichnungen, Pfade, IP-Adressen und Anwendungsdaten enthalten.

Vorteil von FilterHashtable

Die Filterung erfolgt bereits beim Abruf. Das ist bei großen Ereignisprotokollen meist effizienter, als zunächst alle Ereignisse einzulesen und sie anschließend mit Where-Object zu filtern.

5. Häufig relevante Windows-Ereignisse einordnen
Ereignis-ID Typische Quelle Grundsätzliche Bedeutung
41 Kernel-Power Windows wurde ohne reguläres Herunterfahren neu gestartet
1074 User32 Ein Prozess oder Benutzer leitete Herunterfahren oder Neustart ein
6005 EventLog Ereignisprotokolldienst wurde gestartet
6006 EventLog Ereignisprotokolldienst wurde regulär beendet
6008 EventLog Vorheriges Herunterfahren war unerwartet
7031 Service Control Manager Ein Dienst wurde unerwartet beendet
7034 Service Control Manager Ein Dienst wurde unerwartet beendet
7040 Service Control Manager Starttyp eines Dienstes wurde geändert
7045 Service Control Manager Ein Dienst wurde im System installiert

Die Ereignis-ID allein ist kein vollständiger Befund. Quelle, Meldung, Zeitpunkt, betroffene Komponente und benachbarte Ereignisse müssen zusätzlich ausgewertet werden.

Ein Ereignis Kernel-Power 41 bestätigt beispielsweise, dass Windows zuvor nicht ordnungsgemäß heruntergefahren wurde. Es beweist jedoch nicht, ob Stromverlust, Hardwarefehler, Absturz, erzwungenes Ausschalten oder eine andere Ursache verantwortlich war.

6. Zuverlässigkeitsverlauf auswerten

Zuverlässigkeitsüberwachung öffnen

[RO] perfmon /rel

Der Zuverlässigkeitsverlauf stellt wichtige Ereignisse nach Tagen geordnet dar. Dazu können gehören:

Sinnvolle Vorgehensweise

  1. Tag und Uhrzeit der Störung auswählen.
  2. Kritische Ereignisse untersuchen.
  3. Gleichzeitig installierte Updates oder Anwendungen beachten.
  4. Technische Details öffnen.
  5. Befund mit Ereignisanzeige und Anwendungsprotokollen vergleichen.

Der Stabilitätsindex ist eine verdichtete Kennzahl. Er beweist nicht, welche Komponente die Ursache einer Störung ist.

7. Task-Manager zur ersten Eingrenzung verwenden

Task-Manager öffnen

[RO] taskmgr

Wichtige Bereiche

Registerkarte Verwendung
Prozesse Momentane CPU-, RAM-, Datenträger-, Netzwerk- und GPU-Nutzung
Leistung Gesamtauslastung und zeitliche Kurzansicht
App-Verlauf Ressourcennutzung unterstützter Apps
Autostart-Apps Programme beim Benutzerstart
Benutzer Ressourcen nach angemeldeten Benutzern
Details Prozesse mit PID, Status, Benutzer und weiteren Spalten
Dienste Dienststatus und zugehörige Informationen

Bei hoher Auslastung prüfen

Das sofortige Beenden eines unbekannten Prozesses kann Datenverlust verursachen oder Systemfunktionen unterbrechen.

8. Prozesse mit PowerShell untersuchen

Prozesse anzeigen

[RO][SENS] Get-Process

Prozesse nach CPU-Zeit sortieren

[RO][SENS] Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 15 Name, Id, CPU, WorkingSet64

CPU enthält die bisher verbrauchte Prozessorzeit und nicht unmittelbar die aktuelle prozentuale CPU-Auslastung.

Prozesse nach Arbeitsspeicher sortieren

[RO][SENS] Get-Process |
    Sort-Object WorkingSet64 -Descending |
    Select-Object -First 15 Name,
        Id,
        @{Name='RAM_MiB';Expression={[math]::Round($_.WorkingSet64 / 1MB, 1)}}

Bestimmten Prozess anzeigen

[RO][SENS] Get-Process -Id <PID>

Prozessdetails über CIM

[RO][SENS] Get-CimInstance Win32_Process -Filter "ProcessId=<PID>" |
    Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine

Die Befehlszeile kann Pfade, Benutzerdaten, Servernamen oder sogar ungeschützt übergebene Zugangsdaten enthalten.

Prozess kontrolliert beenden

[CHANGE] Stop-Process -Id <PID>

Erzwungenes Beenden

[CHANGE] Stop-Process -Id <PID> -Force

-Force darf nicht als allgemeine Fehlerbehebung verwendet werden. Nicht gespeicherte Daten können verloren gehen und abhängige Komponenten können ausfallen.

9. Ressourcenmonitor verwenden

Ressourcenmonitor öffnen

[RO] resmon

Der Ressourcenmonitor zeigt detaillierte Informationen zu:

Typische Anwendungsfälle

Ein Hard Fault ist nicht automatisch ein Hardwarefehler. Er bezeichnet in diesem Zusammenhang einen Speicherzugriff, bei dem benötigte Daten nicht im physischen Arbeitsspeicher vorlagen und aus einer anderen Speicherquelle geladen werden mussten.

10. Leistungsüberwachung und Performance Counter

Leistungsüberwachung öffnen

[RO] perfmon

Die Leistungsüberwachung kann Messwerte in Echtzeit anzeigen oder über Datenkollektorsätze längerfristig erfassen.

Verfügbare Leistungsindikatoren mit PowerShell anzeigen

[RO] Get-Counter -ListSet *

Einzelne Messung durchführen

[TEST] Get-Counter '\Processor(_Total)\% Processor Time'

Mehrere Messwerte erfassen

[TEST] Get-Counter `
    '\Processor(_Total)\% Processor Time',
    '\Memory\Available MBytes',
    '\PhysicalDisk(_Total)\Avg. Disk sec/Transfer' `
    -SampleInterval 2 `
    -MaxSamples 10

Wichtige Kategorien

Kategorie Beispiele
Processor Gesamtauslastung und Prozessorzeit
Memory verfügbarer Speicher und Paging
PhysicalDisk Warteschlangen, Übertragungen und Latenz
Network Interface übertragene und verworfene Daten
Process Werte einzelner Prozesse
System Prozesse, Threads und Systemaktivität

Bewertungsregeln

11. Dienste untersuchen

Diensteverwaltung öffnen

[RO] services.msc

Alle Dienste mit PowerShell anzeigen

[RO] Get-Service

Beendete Dienste anzeigen

[RO] Get-Service |
    Where-Object Status -eq 'Stopped'

Ein beendeter Dienst ist nicht automatisch fehlerhaft. Viele Dienste werden nur bei Bedarf gestartet.

Bestimmten Dienst prüfen

[RO] Get-Service -Name "<DIENSTNAME>"

Ausführlichere Dienstinformationen

[RO][SENS] Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'" |
    Select-Object Name,
                  DisplayName,
                  State,
                  StartMode,
                  StartName,
                  PathName,
                  ProcessId

Dienstkonfiguration mit sc.exe

[RO] sc.exe qc "<DIENSTNAME>"

Dienstabhängigkeiten

[RO] Get-Service -Name "<DIENSTNAME>" -RequiredServices

Abhängige Dienste

[RO] Get-Service -Name "<DIENSTNAME>" -DependentServices

Dienst starten

[CHANGE][PRIV] Start-Service -Name "<DIENSTNAME>"

Dienst neu starten

[CHANGE][PRIV][RESTART] Restart-Service -Name "<DIENSTNAME>"

Vor einem Dienstneustart müssen abhängige Anwendungen, aktive Benutzer, Transaktionen und Auswirkungen auf andere Systeme geprüft werden.

12. Netzwerkgrundlagen erfassen

Vollständige IP-Konfiguration

[RO][SENS] ipconfig /all

PowerShell-Netzwerkkonfiguration

[RO][SENS] Get-NetIPConfiguration

IP-Adressen anzeigen

[RO][SENS] Get-NetIPAddress

Netzwerkadapter anzeigen

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

Routingtabelle anzeigen

[RO][SENS] route print

Alternativ:

[RO][SENS] Get-NetRoute |
    Sort-Object InterfaceIndex, DestinationPrefix

DNS-Server anzeigen

[RO][SENS] Get-DnsClientServerAddress

Wichtige Prüfwerte

Eine APIPA-Adresse kann darauf hinweisen, dass keine erwartete IPv4-Konfiguration per DHCP bezogen wurde. Sie beweist jedoch nicht allein, warum der DHCP-Vorgang scheiterte.

13. Erreichbarkeit und Netzwerkpfad testen

Lokalen TCP/IP-Stack testen

[TEST] ping 127.0.0.1

Standardgateway testen

[TEST] ping <GATEWAY-IP>

Ziel testen

[TEST] ping <ZIEL>

Route zum Ziel verfolgen

[TEST][SENS] tracert <ZIEL>

Verlust und Laufzeit entlang des Pfades untersuchen

[TEST][SENS] pathping <ZIEL>

TCP-Port mit PowerShell testen

[TEST][SENS] Test-NetConnection -ComputerName "<ZIEL>" -Port <PORT>

Beispiel:

[TEST][SENS] Test-NetConnection -ComputerName "server.example" -Port 443

Erweiterte Verbindungsinformationen

[TEST][SENS] Test-NetConnection -ComputerName "<ZIEL>" -DiagnoseRouting -InformationLevel Detailed

Bewertungsregeln

14. DNS-Auflösung untersuchen

DNS-Abfrage mit PowerShell

[TEST][SENS] Resolve-DnsName "<HOSTNAME>"

Bestimmten DNS-Server abfragen

[TEST][SENS] Resolve-DnsName "<HOSTNAME>" -Server "<DNS-SERVER>"

Klassische DNS-Abfrage

[TEST][SENS] nslookup <HOSTNAME>

DNS-Clientcache anzeigen

[RO][SENS] Get-DnsClientCache

Alternativ:

[RO][SENS] ipconfig /displaydns

DNS-Clientcache leeren

[CHANGE][PRIV] Clear-DnsClientCache

Alternativ:

[CHANGE][PRIV] ipconfig /flushdns

Typische Fehlerquellen

Das Leeren des DNS-Caches sollte nur erfolgen, wenn ein veralteter lokaler Cache als Ursache infrage kommt. Es behebt keine falschen Einträge auf dem DNS-Server.

15. Ports und Verbindungen untersuchen

TCP-Verbindungen anzeigen

[RO][SENS] Get-NetTCPConnection

Lauschende TCP-Ports

[RO][SENS] Get-NetTCPConnection -State Listen |
    Sort-Object LocalPort |
    Select-Object LocalAddress, LocalPort, OwningProcess

Zugehörigen Prozess bestimmen

[RO][SENS] Get-Process -Id <PID>

Klassische Portübersicht

[RO][SENS] netstat -ano

Lauschende Ports

[RO][SENS] netstat -ano | findstr LISTENING

Ausführbare Programme einbeziehen

[RO][PRIV][SENS] netstat -abno

UDP-Endpunkte

[RO][SENS] Get-NetUDPEndpoint |
    Sort-Object LocalPort

Wichtige Zustände

Zustand Bedeutung
Listen Prozess wartet auf eingehende TCP-Verbindungen
Established TCP-Verbindung besteht
TimeWait Verbindung wurde beendet und bleibt vorübergehend gespeichert
SynSent Verbindungsaufbau wurde begonnen, Antwort steht noch aus
CloseWait Gegenstelle hat beendet; lokaler Prozess muss noch schließen

Ein offener Hostport beweist noch nicht, dass die Anwendung fachlich korrekt arbeitet. Zusätzlich müssen Protokoll, Antwort und gegebenenfalls Authentifizierung getestet werden.

16. Windows-Firewall untersuchen

Firewallprofile anzeigen

[RO] Get-NetFirewallProfile |
    Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction

Aktivierte Firewallregeln anzeigen

[RO][SENS] Get-NetFirewallRule -Enabled True |
    Select-Object DisplayName, Direction, Action, Profile

Regeln anhand eines Namens suchen

[RO][SENS] Get-NetFirewallRule |
    Where-Object DisplayName -Like '*<SUCHBEGRIFF>*'

Firewallverwaltung öffnen

[RO] wf.msc

Typische Prüfpunkte

Die Firewall darf nicht pauschal deaktiviert werden, um ein Verbindungsproblem zu testen. Stattdessen muss die konkrete Verbindung mit passender Protokollierung und eng begrenzten Regeln untersucht werden.

17. Datenträger, Volumes und Speicherplatz prüfen

Volumes anzeigen

[RO] Get-Volume |
    Select-Object DriveLetter,
                  FileSystemLabel,
                  FileSystem,
                  HealthStatus,
                  SizeRemaining,
                  Size

Datenträger anzeigen

[RO] Get-Disk

Partitionen anzeigen

[RO] Get-Partition

Freien Speicher übersichtlich berechnen

[RO] Get-Volume |
    Where-Object DriveLetter |
    Select-Object DriveLetter,
        FileSystemLabel,
        @{Name='Frei_GiB';Expression={[math]::Round($_.SizeRemaining / 1GB, 2)}},
        @{Name='Gesamt_GiB';Expression={[math]::Round($_.Size / 1GB, 2)}}

Datenträgerverwaltung öffnen

[RO] diskmgmt.msc

Dateisystem online prüfen

[TEST][PRIV] chkdsk C: /scan

Wichtige Unterscheidungen

Reparaturoptionen wie chkdsk /f oder /r können lange Laufzeiten, exklusive Datenträgerzugriffe oder einen Neustart erfordern. Sie dürfen nicht ohne Sicherung und Wartungsplanung eingesetzt werden.

18. Arbeitsspeicher untersuchen

Grundlegende Speicherinformationen

[RO] Get-CimInstance Win32_OperatingSystem |
    Select-Object @{
        Name='Gesamt_GiB'
        Expression={[math]::Round($_.TotalVisibleMemorySize / 1MB, 2)}
    }, @{
        Name='Frei_GiB'
        Expression={[math]::Round($_.FreePhysicalMemory / 1MB, 2)}
    }

Installierte Speichermodule

[RO][SENS] Get-CimInstance Win32_PhysicalMemory |
    Select-Object BankLabel,
                  DeviceLocator,
                  Capacity,
                  Speed,
                  Manufacturer,
                  PartNumber

Windows-Speicherdiagnose öffnen

[TEST][RESTART] mdsched.exe

Die Speicherdiagnose bietet normalerweise einen Test beim nächsten Neustart oder einen sofortigen Neustart mit anschließender Prüfung an.

Ein Speicherdiagnosetest unter Last oder ein einzelner erfolgreicher Durchlauf schließt sporadische Hardwarefehler nicht zwingend aus.

19. Geräte und Treiber prüfen

Geräte-Manager öffnen

[RO] devmgmt.msc

Vorhandene Plug-and-Play-Geräte

[RO][SENS] Get-PnpDevice

Geräte mit Fehlerstatus

[RO][SENS] Get-PnpDevice |
    Where-Object Status -ne 'OK'

Installierte Treiber

[RO][SENS] driverquery /v

Signierte Treiber mit PowerShell

[RO][SENS] Get-CimInstance Win32_PnPSignedDriver |
    Select-Object DeviceName,
                  DriverVersion,
                  DriverDate,
                  Manufacturer,
                  InfName

Typische Prüfpunkte

Ein neuerer Treiber ist nicht automatisch geeigneter. Entscheidend sind Hardwaremodell, Betriebssystemversion und Freigabe durch Hersteller oder Geräteanbieter.

20. Autostart, Aufgaben und Systemstart untersuchen

Autostartprogramme über CIM anzeigen

[RO][SENS] Get-CimInstance Win32_StartupCommand |
    Select-Object Name, Command, Location, User

Aufgabenplanung öffnen

[RO] taskschd.msc

Geplante Aufgaben anzeigen

[RO][SENS] Get-ScheduledTask |
    Select-Object TaskPath, TaskName, State

Aufgaben mit letztem Ergebnis

[RO][SENS] Get-ScheduledTask | ForEach-Object {
    $info = $_ | Get-ScheduledTaskInfo
    [PSCustomObject]@{
        TaskPath       = $_.TaskPath
        TaskName       = $_.TaskName
        State          = $_.State
        LastRunTime    = $info.LastRunTime
        LastTaskResult = $info.LastTaskResult
        NextRunTime    = $info.NextRunTime
    }
}

Systemkonfiguration öffnen

[RO] msconfig

Autostarteinträge und geplante Aufgaben dürfen nicht wahllos deaktiviert werden. Sie können zu Sicherheitssoftware, Backups, Updates, Treibern oder geschäftskritischen Anwendungen gehören.

21. Windows-Updates prüfen

Installierte Hotfixes anzeigen

[RO] Get-HotFix |
    Sort-Object InstalledOn -Descending

Updateverlauf in den Einstellungen

Einstellungen
→ Windows Update
→ Updateverlauf

Windows-Update-Ereignisse abrufen

[RO][SENS] Get-WinEvent -LogName `
    'Microsoft-Windows-WindowsUpdateClient/Operational' `
    -MaxEvents 100 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

Typische Prüfpunkte

Ein zeitlicher Zusammenhang zwischen Update und Fehler ist ein wichtiger Hinweis, aber noch kein Ursachennachweis. Vor einer Deinstallation müssen bekannte Probleme, Sicherheitsfolgen und Herstellerangaben geprüft werden.

22. Windows-Systemdateien mit SFC prüfen

Der System File Checker überprüft geschützte Windows-Systemdateien und kann beschädigte Dateien ersetzen.

Systemdateien prüfen und reparieren

[CHANGE][PRIV] sfc /scannow

Nur eine bestimmte Datei prüfen

[TEST][PRIV] sfc /verifyfile="<VOLLSTÄNDIGER_PFAD>"

Nur prüfen, ohne Reparatur

[TEST][PRIV] sfc /verifyonly

Mögliche Ergebnisse

SFC-Einträge aus dem CBS-Protokoll filtern

[RO][PRIV][SENS] findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log

SFC ist kein universelles Reparaturprogramm. Es untersucht geschützte Windows-Systemdateien, nicht automatisch Anwendungsdateien, Benutzerdaten, Hardware oder sämtliche Konfigurationen.

23. Windows-Komponentenspeicher mit DISM prüfen

DISM kann den Zustand des Windows-Abbilds beziehungsweise Komponentenspeichers untersuchen und reparieren.

Schnelle Statusprüfung

[RO][PRIV] DISM /Online /Cleanup-Image /CheckHealth

Ausführliche Prüfung

[TEST][PRIV] DISM /Online /Cleanup-Image /ScanHealth

Windows-Abbild reparieren

[CHANGE][PRIV] DISM /Online /Cleanup-Image /RestoreHealth

Bedeutung der Parameter

Parameter Bedeutung
/Online Aktuell laufendes Windows wird bearbeitet
/Cleanup-Image Wartungsfunktion für das Windows-Abbild
/CheckHealth Prüft, ob eine Beschädigung bereits erkannt wurde
/ScanHealth Führt eine ausführlichere Prüfung durch
/RestoreHealth Versucht erkannte Beschädigungen zu reparieren

Wichtige Hinweise

DISM-Protokoll

C:\Windows\Logs\DISM\dism.log

CBS-Protokoll

C:\Windows\Logs\CBS\CBS.log

DISM und SFC dürfen nicht reflexartig bei jedem Windows-Problem ausgeführt werden. Zuerst sollte ein Zusammenhang mit beschädigten Windows-Komponenten oder Systemdateien begründet werden.

24. Gruppenrichtlinien und Richtlinienanwendung prüfen

Angewendete Richtlinien anzeigen

[RO][SENS] gpresult /r

Ausführlichen HTML-Bericht erzeugen

[RO][SENS] gpresult /h ".\gpresult.html"

Resultant Set of Policy öffnen

[RO][SENS] rsop.msc

Gruppenrichtlinien-Ereignisse

[RO][SENS] Get-WinEvent -LogName `
    'Microsoft-Windows-GroupPolicy/Operational' `
    -MaxEvents 100 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

Gruppenrichtlinien aktualisieren

[CHANGE][PRIV] gpupdate /force

gpupdate /force kann Richtlinien erneut anwenden, Anmelde- oder Neustartanforderungen auslösen und den Arbeitszustand beeinflussen. Der Befehl ist kein Ersatz für die Analyse einer fehlerhaften Richtlinie.

25. Anmeldungen und Benutzerkontext untersuchen

Aktuellen Benutzer anzeigen

[RO] whoami

Gruppen und Sicherheitskennungen anzeigen

[RO][SENS] whoami /groups

Aktuelle Berechtigungen anzeigen

[RO][SENS] whoami /priv

Angemeldete Sitzungen

[RO][SENS] query user

Lokale Benutzer anzeigen

[RO][SENS] Get-LocalUser

Lokale Gruppenmitgliedschaften

[RO][SENS] Get-LocalGroupMember -Group "<GRUPPENNAME>"

Kerberos-Tickets anzeigen

[RO][SENS] klist

Typische Ursachen kontextabhängiger Fehler

Ein erfolgreicher Test als Administrator beweist nicht, dass die Funktion für den vorgesehenen Benutzer korrekt berechtigt ist.

26. Remotedienste und Freigaben prüfen

SMB-Freigaben anzeigen

[RO][SENS] Get-SmbShare

Bestehende SMB-Verbindungen

[RO][SENS] Get-SmbConnection

Erreichbarkeit von SMB testen

[TEST][SENS] Test-NetConnection -ComputerName "<SERVER>" -Port 445

Remotedesktopport testen

[TEST][SENS] Test-NetConnection -ComputerName "<SERVER>" -Port 3389

WinRM-Konfiguration anzeigen

[RO][SENS] winrm get winrm/config

WinRM-Verbindung testen

[TEST][SENS] Test-WSMan -ComputerName "<SERVER>"

Wichtige Unterscheidung

Eine erfolgreiche TCP-Verbindung bestätigt nur, dass der getestete Port erreichbar ist. Sie bestätigt nicht automatisch:

27. Abstürze und Speicherabbilder untersuchen

Windows kann bei System- oder Anwendungsabstürzen Speicherabbilder erzeugen.

Typische Speicherorte

C:\Windows\MEMORY.DMP
C:\Windows\Minidump\
%LOCALAPPDATA%\CrashDumps\

Die tatsächliche Konfiguration und der Speicherort können abweichen.

Start- und Wiederherstellungseinstellungen öffnen

[RO] sysdm.cpl

Danach:

Erweitert
→ Starten und Wiederherstellen
→ Einstellungen

Typische Abbildarten

Typ Inhalt
Kleines Speicherabbild Begrenzte Informationen zum Absturz
Kernelspeicherabbild Kernelbezogene Speicherbereiche
Automatisches Speicherabbild Von Windows verwaltete Auswahl
Vollständiges Speicherabbild Umfassender Inhalt des physischen Speichers
Aktives Speicherabbild Für aktive Kernel- und Systembereiche optimiert

Wichtige Sicherheitsregel

Speicherabbilder können enthalten:

Speicherabbilder müssen wie sensible Diagnosedaten behandelt und dürfen nicht ungeprüft weitergegeben werden.

Zur detaillierten Analyse kann Microsoft WinDbg eingesetzt werden. WinDbg wird auf einer späteren Seite zusammen mit weiteren spezialisierten Werkzeugen behandelt.

28. Abgesicherter Modus und sauberer Systemstart

Der abgesicherte Modus startet Windows mit einer eingeschränkten Auswahl von Treibern und Diensten. Damit kann geprüft werden, ob ein Fehler durch zusätzliche Software, Treiber oder Autostartkomponenten beeinflusst wird.

Ein sauberer Systemstart deaktiviert gezielt nicht benötigte Dienste und Autostartprogramme, um Konflikte einzugrenzen.

Systemkonfiguration öffnen

[CHANGE][RESTART] msconfig

Wichtige Risiken

Geeignete Fragestellung

Tritt der Fehler auch mit einer minimalen Auswahl von Treibern,
Diensten und Autostartprogrammen auf?

Ein ausbleibender Fehler grenzt die Ursache ein, identifiziert aber noch nicht automatisch die verantwortliche Komponente.

29. Fernzugriff und Datensammlung sicher durchführen

Vor einer Ferndiagnose müssen geklärt werden:

Computername prüfen

[RO] $env:COMPUTERNAME

Benutzerkontext prüfen

[RO] whoami

PowerShell-Remotesitzung testen

[TEST][SENS] Test-WSMan -ComputerName "<COMPUTER>"

Befehl remote ausführen

[RO][SENS] Invoke-Command -ComputerName "<COMPUTER>" -ScriptBlock {
    Get-CimInstance Win32_OperatingSystem |
        Select-Object Caption, Version, LastBootUpTime
}

Remoteausgaben, Transkripte und Diagnosearchive können sensible Daten enthalten. Sie müssen zweckgebunden gespeichert, geschützt und nach den geltenden Vorgaben gelöscht werden.

30. Gefährliche Schnelllösungen vermeiden
Maßnahme Risiko
Unbekannten Prozess sofort beenden Datenverlust oder Dienstausfall
Dienst ohne Prüfung neu starten Unterbrechung abhängiger Anwendungen
Windows-Firewall vollständig deaktivieren Schutzwirkung entfällt
Ereignisprotokolle löschen Diagnosenachweise gehen verloren
Registrywerte auf Verdacht ändern System oder Anwendung wird beschädigt
Treiber ungeprüft aktualisieren Inkompatibilität oder Startfehler
Update sofort deinstallieren Sicherheitslücke oder Folgefehler
chkdsk /f ungeplant ausführen Neustart und lange Ausfallzeit
DISM oder SFC als Universallösung verwenden Ursache bleibt ungeklärt
Autostart und Dienste wahllos deaktivieren Sicherheits- und Geschäftsfunktionen fallen aus
Speicherabbild unredigiert weitergeben Geheimnisse und Benutzerdaten werden offengelegt
Computer hart ausschalten Daten- und Dateisystemschäden
Systemwiederherstellung ungeprüft starten Neuere Änderungen können verloren gehen
„PC zurücksetzen“ verwenden Anwendungen, Einstellungen oder Daten gehen verloren

Vor einer Änderung prüfen

  1. Ist die Ursache ausreichend eingegrenzt?
  2. Welche Systeme und Benutzer sind betroffen?
  3. Existiert eine aktuelle Sicherung?
  4. Ist die Maßnahme reversibel?
  5. Welche Abhängigkeiten bestehen?
  6. Ist ein Neustart erforderlich?
  7. Gibt es ein Wartungsfenster?
  8. Wie wird die Funktion anschließend getestet?
  9. Wie wird die Änderung dokumentiert?
31. Sichere Reihenfolge einer Windows-Fehleranalyse
  1. Betroffenen Computer und Benutzer eindeutig bestimmen.
  2. Originale Fehlermeldung und Fehlerzeitpunkt erfassen.
  3. Umfang und Reproduzierbarkeit prüfen.
  4. Windows-Version, Build und letzte Startzeit erfassen.
  5. Änderungen, Updates und Installationen vor dem Fehler feststellen.
  6. Ereignisanzeige und Zuverlässigkeitsverlauf zum Fehlerzeitpunkt prüfen.
  7. Prozesse, Dienste und aktuelle Ressourcenbelastung untersuchen.
  8. Freien Speicherplatz und Datenträgerzustand kontrollieren.
  9. Netzwerk, DNS, Route und benötigte Ports getrennt testen.
  10. Benutzerkontext, Berechtigungen und Richtlinien berücksichtigen.
  11. Treiber, Geräte und Abhängigkeiten prüfen.
  12. Erkenntnisse aus mehreren Datenquellen abgleichen.
  13. Sicherung und Rückfallplan kontrollieren.
  14. Kleinste geeignete Änderung durchführen.
  15. Interne und externe Funktionsprüfung ausführen.
  16. Ereignisse und Ressourcen nach der Maßnahme erneut prüfen.
  17. Ursache, Maßnahme und Ergebnis dokumentieren.
32. Schnelle Befehlsübersicht
Aufgabe Befehl
Windows-Version [RO] winver
Systeminformationen [RO][SENS] systeminfo
Ereignisanzeige [RO] eventvwr.msc
Systemereignisse [RO][SENS] Get-WinEvent -LogName System -MaxEvents 50
Zuverlässigkeitsverlauf [RO] perfmon /rel
Task-Manager [RO] taskmgr
Ressourcenmonitor [RO] resmon
Leistungsüberwachung [RO] perfmon
Prozesse [RO][SENS] Get-Process
Dienste [RO] Get-Service
Dienstkonfiguration [RO] sc.exe qc "<DIENSTNAME>"
IP-Konfiguration [RO][SENS] ipconfig /all
Adapter [RO] Get-NetAdapter
Routingtabelle [RO][SENS] route print
Erreichbarkeit [TEST] ping <ZIEL>
Route [TEST][SENS] tracert <ZIEL>
TCP-Port [TEST][SENS] Test-NetConnection "<ZIEL>" -Port <PORT>
DNS [TEST][SENS] Resolve-DnsName "<HOSTNAME>"
TCP-Verbindungen [RO][SENS] Get-NetTCPConnection
Ports und PID [RO][SENS] netstat -ano
Firewallprofile [RO] Get-NetFirewallProfile
Volumes [RO] Get-Volume
Datenträger [RO] Get-Disk
Geräte [RO][SENS] Get-PnpDevice
Treiber [RO][SENS] driverquery /v
Geplante Aufgaben [RO][SENS] Get-ScheduledTask
Gruppenrichtlinien [RO][SENS] gpresult /r
Benutzerkontext [RO] whoami
Systemdateien [CHANGE][PRIV] sfc /scannow
Abbildprüfung [TEST][PRIV] DISM /Online /Cleanup-Image /ScanHealth
Abbildreparatur [CHANGE][PRIV] DISM /Online /Cleanup-Image /RestoreHealth
33. Dokumentationsvorlage 
Ticket:
Datum und Uhrzeit:
Bearbeiter:

Computername:
Windows-Edition:
Windows-Version:
Build:
Architektur:
Letzter Systemstart:
Benutzerkontext:
Domäne oder Arbeitsgruppe:

Originale Fehlermeldung:
Fehlerzeitpunkt:
Erstmals aufgetreten:
Reproduzierbar:
Betroffene Benutzer:
Betroffene Anwendung oder Funktion:
Umfang der Störung:
Letzte funktionierende Nutzung:

Letzte Änderung:
Installierte Updates:
Treiberänderung:
Softwareinstallation:
Richtlinienänderung:

Relevante Ereignisquellen:
Ereignis-IDs:
Zuverlässigkeitsverlauf:
Betroffene Prozesse:
Betroffene Dienste:
CPU:
Arbeitsspeicher:
Datenträger:
Freier Speicher:

IP-Konfiguration:
DNS:
Standardgateway:
Getestetes Ziel:
Getesteter Port:
Testergebnis:
Firewallprofil:
Firewallregel:

Gerätestatus:
Treiberversion:
Systemdateiprüfung:
DISM-Status:
Absturzabbild:
Sensible Daten redigiert:

Vermutete Ursache:
Durchgeführte Tests:
Sicherung geprüft:
Geplante Änderung:
Erwartete Auswirkung:
Rückfallplan:
Neustart erforderlich:

Ergebnis nach der Maßnahme:
Interne Funktionsprüfung:
Externe Funktionsprüfung:
Monitoring:
Weiterführende Maßnahmen:

Merksatz

Windows stellt viele Diagnosewerkzeuge bereit, doch kein einzelnes Werkzeug liefert automatisch die Ursache. Eine belastbare Fehleranalyse verbindet Zeitpunkt, Ereignisse, Prozesse, Dienste, Ressourcen, Netzwerk, Änderungen und Benutzerkontext zu einem nachvollziehbaren Gesamtbild.

Quellen und weiterführende Dokumentation

5. Werkzeuge der Fehleranalyse

5.2 Microsoft Sysinternals – Erweiterte Werkzeuge zur Fehleranalyse

Microsoft Sysinternals ist eine Sammlung spezialisierter Diagnose-, Analyse- und Verwaltungswerkzeuge. Die Programme ermöglichen einen wesentlich tieferen Einblick in Prozesse, Autostarts, Dateizugriffe, Registryzugriffe, Netzwerkverbindungen, Arbeitsspeicher, Berechtigungen, Active Directory und Systemereignisse als viele integrierte Windows-Werkzeuge.

Sysinternals-Werkzeuge können unter anderem helfen bei:

Sysinternals-Werkzeuge liefern technische Beobachtungen und Messdaten. Ein auffälliger Eintrag ist noch kein Beweis für Malware, einen Defekt oder die eigentliche Ursache einer Störung.

Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] Nur lesender beziehungsweise beobachtender Einsatz
[TEST] Führt einen aktiven Test oder eine Aufzeichnung durch
[CHANGE] Verändert Prozesse, Dateien, Konfigurationen oder Systemzustand
[PRIV] Erhöhte Berechtigungen können erforderlich sein
[RESTART] Kann einen Neustart oder eine Unterbrechung verursachen
[REMOTE] Greift auf einen anderen Computer zu
[SENS] Ausgabe kann sensible Informationen enthalten
[DANGER] Hohes Risiko für Ausfall, Datenverlust oder Sicherheitsprobleme

Die Kennzeichnungen sind Hinweise für den administrativen Einsatz. Ob eine Freigabe erforderlich ist, hängt zusätzlich von der jeweiligen Organisation, dem betroffenen System und den geltenden Sicherheitsvorgaben ab.

1. Was ist Microsoft Sysinternals?

Die Sysinternals-Werkzeuge wurden ursprünglich von Mark Russinovich und Bryce Cogswell entwickelt. Microsoft übernahm Sysinternals im Jahr 2006 und stellt die Werkzeuge weiterhin bereit.

Die Sammlung besteht überwiegend aus kleinen, spezialisierten Programmen. Viele davon müssen nicht klassisch installiert werden und können nach dem Entpacken direkt gestartet werden.

Wichtige Werkzeuggruppen

Bereich Beispiele
Prozesse Process Explorer, ProcDump, PsList, PsKill
Systemaktivität Process Monitor, Sysmon, DebugView
Autostart Autoruns, Autorunsc
Netzwerk TCPView, Tcpvcon, PsPing
Arbeitsspeicher RAMMap, VMMap
Dateien und Objekte Handle, ListDLLs, Streams, PendMoves
Sicherheit und Rechte Sigcheck, AccessChk, AccessEnum, ShareEnum
Active Directory AD Explorer, AD Insight, AD Restore
Datenträger Disk2vhd, DiskMon, Disk Usage, NTFSInfo
Remotewerkzeuge PsExec, PsService, PsInfo, PsLoggedOn
Kernelanalyse LiveKd, WinObj
Systeminformation Coreinfo, BgInfo, LogonSessions

Abgrenzung

Sysinternals ist:

Die Werkzeuge ergänzen Ereignisanzeige, Task-Manager, Ressourcenmonitor, Leistungsüberwachung, PowerShell und spezialisierte Debuggingprogramme.

2. Sysinternals sicher beziehen

Sysinternals-Werkzeuge sollten ausschließlich aus vertrauenswürdigen Microsoft-Quellen bezogen werden.

Offizielle Möglichkeiten

  1. Einzelwerkzeuge über Microsoft Learn herunterladen
  2. vollständige Sysinternals Suite herunterladen
  3. Sysinternals Suite aus dem Microsoft Store installieren
  4. Werkzeuge über Sysinternals Live ausführen

Sysinternals Suite

Die Suite enthält einen großen Teil der Diagnosewerkzeuge in einem gemeinsamen Archiv. Für bestimmte Plattformen stellt Microsoft unterschiedliche Pakete bereit, darunter x64 und ARM64.

Microsoft Store

Bei der Store-Version werden grafische Programme im Startmenü eingetragen. Die Befehlszeilenprogramme können über App-Ausführungsaliase aufgerufen werden.

Sysinternals Live

Ein Werkzeug kann direkt von Sysinternals Live gestartet werden:

[TEST][SENS] \\live.sysinternals.com\tools\procexp.exe

Beispiel für Process Monitor:

[TEST][SENS] \\live.sysinternals.com\tools\procmon.exe

Dabei müssen Netzwerkzugriff, Proxy, Firewall, Namensauflösung und die Sicherheitsrichtlinien der Organisation berücksichtigt werden.

In kontrollierten Unternehmensumgebungen sollte nicht ungeprüft eine ausführbare Datei direkt aus dem Internet gestartet werden. Besser ist häufig ein freigegebenes, geprüftes und versioniertes internes Werkzeugverzeichnis.

3. Integrität und Signatur prüfen

Vor dem Einsatz sollte geprüft werden:

Digitale Signatur mit PowerShell kontrollieren

[RO] Get-AuthenticodeSignature ".\procexp.exe" |
    Select-Object Status, StatusMessage, SignerCertificate

Dateihash berechnen

[RO] Get-FileHash ".\procexp.exe" -Algorithm SHA256

Der Hash kann zur internen Dokumentation und zum Vergleich identischer Werkzeugstände verwendet werden. Ein Hash beweist allein jedoch nicht, dass eine Datei vertrauenswürdig ist.

Sysinternals Sigcheck verwenden

[RO] sigcheck.exe -a -h -i ".\procexp.exe"

Typische Informationen können sein:

Eine gültige Signatur bestätigt die signierte Herkunft und Dateiintegrität innerhalb der Signaturprüfung. Sie beweist nicht automatisch, dass jede ausgeführte Funktion im konkreten Einsatz sicher oder erwünscht ist.

4. Allgemeine Einsatzregeln

Vor dem Start eines Sysinternals-Werkzeugs sollte feststehen:

  1. Welcher Fehler wird untersucht?
  2. Welcher Computer ist betroffen?
  3. Welcher Benutzerkontext ist betroffen?
  4. Wann tritt der Fehler auf?
  5. Welches Werkzeug kann die benötigte Beobachtung liefern?
  6. Welche Daten können bei der Aufzeichnung entstehen?
  7. Ist eine erhöhte Ausführung erforderlich?
  8. Wie groß kann die Protokolldatei werden?
  9. Wo wird sie geschützt gespeichert?
  10. Wann wird die Aufzeichnung beendet?
  11. Wie werden sensible Daten redigiert?
  12. Welche Änderung muss anschließend zurückgenommen werden?

Grundregeln

5. Process Explorer – Prozesse und Abhängigkeiten analysieren

Process Explorer zeigt Prozesse hierarchisch an und liefert detaillierte Informationen zu:

Starten

[RO][SENS] procexp.exe

Für vollständige Informationen über Systemprozesse können erhöhte Rechte erforderlich sein:

[RO][PRIV][SENS] procexp.exe

Wichtige Funktionen

Funktion Verwendung
Process Tree Eltern-Kind-Beziehungen von Prozessen erkennen
Lower Pane – Handles Geöffnete Dateien, Registryschlüssel und andere Objekte untersuchen
Lower Pane – DLLs Geladene DLLs und speicherabgebildete Dateien anzeigen
Find Handle or DLL Prozess zu einer Datei, einem Objekt oder einer DLL finden
Properties Threads, Netzwerk, Sicherheit, Umgebung und Startparameter untersuchen
Verify Image Signatures Signaturen ausführbarer Dateien prüfen
Save Prozessübersicht für die Dokumentation speichern
Create Dump Speicherabbild eines Prozesses erzeugen
Kill Process Tree Prozess und untergeordnete Prozesse beenden

Typische Anwendungsfälle

Prozessfarben

Process Explorer kann unterschiedliche Prozesstypen farblich kennzeichnen. Die genaue Bedeutung hängt von der konfigurierten Farbauswahl ab und sollte über die Programmeinstellungen kontrolliert werden.

Eine Farbe oder ein nicht verifizierter Signaturstatus ist kein automatischer Malware-Nachweis.

6. Blockierte Dateien mit Process Explorer finden

Wenn eine Datei nicht gelöscht, verschoben oder ersetzt werden kann, kann ein geöffneter Handle dafür verantwortlich sein.

Vorgehensweise

  1. Process Explorer starten.
  2. Find öffnen.
  3. Find Handle or DLL auswählen.
  4. eindeutigen Teil des Datei- oder Verzeichnisnamens eingeben.
  5. Treffer und zugehörigen Prozess prüfen.
  6. Anwendung möglichst regulär schließen.
  7. Dateioperation erneut testen.

Nicht als erste Maßnahme verwenden

Das direkte Schließen eines Handles kann den Zustand der Anwendung beschädigen, Datenverlust verursachen oder zu einem späteren Absturz führen.

Die sichere Lösung besteht normalerweise darin, die verursachende Anwendung oder den zugehörigen Dienst kontrolliert zu beenden.

7. Handle – offene Dateien und Objekte per Befehlszeile

Handle zeigt offene Handles von Prozessen an. Damit kann unter anderem ermittelt werden, welcher Prozess eine bestimmte Datei oder ein Verzeichnis verwendet.

Nach einem Dateinamen suchen

[RO][PRIV][SENS] handle.exe "<DATEINAME>"

Beispiel

[RO][PRIV][SENS] handle.exe "datenbank.db"

Handles eines bestimmten Prozesses anzeigen

[RO][PRIV][SENS] handle.exe -p <PID>

Ausgabe ohne Banner

[RO][PRIV][SENS] handle.exe -nobanner "<SUCHBEGRIFF>"

Handle schließen

[CHANGE][PRIV][DANGER] handle.exe -c <HANDLE-ID> -p <PID>

Das erzwungene Schließen eines Handles kann Daten beschädigen oder einen Prozess destabilisieren. Diese Funktion darf nur verwendet werden, wenn Objekt, Prozess, Abhängigkeiten und Auswirkungen eindeutig bekannt sind.

8. Process Monitor – Datei-, Registry- und Prozessaktivität erfassen

Process Monitor, kurz Procmon, zeichnet in Echtzeit unter anderem folgende Aktivitäten auf:

Starten

[TEST][PRIV][SENS] procmon.exe

Process Monitor beginnt normalerweise unmittelbar mit der Aufzeichnung. Deshalb sollte die Aufzeichnung zunächst angehalten und gezielt vorbereitet werden.

Empfohlene Grundreihenfolge

  1. Process Monitor starten.
  2. Aufzeichnung anhalten.
  3. bestehende Ereignisse leeren.
  4. passende Filter festlegen.
  5. Aufzeichnung starten.
  6. Fehler möglichst genau reproduzieren.
  7. Aufzeichnung sofort wieder anhalten.
  8. relevante Ereignisse untersuchen.
  9. Aufzeichnung im nativen PML-Format sichern.
  10. sensible Inhalte vor einer Weitergabe prüfen.

Typische Filter

Feld Bedingung Beispiel
Process Name is anwendung.exe
PID is konkrete Prozess-ID
Path contains Verzeichnis oder Registrypfad
Operation is CreateFile
Operation is RegOpenKey
Result is ACCESS DENIED
Result is NAME NOT FOUND
User is betroffenes Benutzerkonto
Duration greater than auffällig langsame Operationen

Process Monitor zeichnet sehr viele normale und erwartete Vorgänge auf. Einzelne Meldungen wie NAME NOT FOUND, PATH NOT FOUND oder ACCESS DENIED sind nicht automatisch Fehlerursachen.

9. Process-Monitor-Ergebnisse richtig interpretieren

Häufige Ergebnisse

Ergebnis Grundbedeutung
SUCCESS Operation wurde erfolgreich abgeschlossen
NAME NOT FOUND Angefragter Name wurde nicht gefunden
PATH NOT FOUND Ein Bestandteil des Pfades wurde nicht gefunden
ACCESS DENIED Zugriff wurde im verwendeten Kontext verweigert
SHARING VIOLATION Zugriff kollidiert mit einer bestehenden Freigabe oder geöffneten Datei
BUFFER OVERFLOW Puffer war für die erste Abfrage zu klein; kann Teil eines normalen Abfragemusters sein
NO MORE FILES Verzeichnisabfrage hat keine weiteren Ergebnisse
REPARSE Verarbeitung über einen Reparse Point
END OF FILE Dateiende erreicht
FILE LOCKED WITH ONLY READERS Sperrzustand der Datei

Bewertungsfragen

Wichtiger Grundsatz

Viele Programme suchen nacheinander an mehreren Stellen nach Dateien oder Registrywerten. Mehrere fehlgeschlagene Suchvorgänge können deshalb völlig normal sein, wenn anschließend ein erfolgreicher Treffer erfolgt.

10. Process Monitor per Befehlszeile einsetzen

Process Monitor unterstützt Befehlszeilenoptionen für reproduzierbare Aufzeichnungen.

Lizenzdialog vorab akzeptieren

[CHANGE] procmon.exe /AcceptEula

Aufzeichnung mit Sicherungsdatei starten

[TEST][PRIV][SENS] procmon.exe /AcceptEula /Quiet /BackingFile "C:\Diagnose\trace.pml"

Laufende Process-Monitor-Instanz beenden

[CHANGE][PRIV] procmon.exe /Terminate

Gespeicherte PML-Datei als CSV exportieren

[RO][SENS] procmon.exe /OpenLog "C:\Diagnose\trace.pml" /SaveAs "C:\Diagnose\trace.csv"

Bootaufzeichnung

Process Monitor besitzt eine Boot-Logging-Funktion, mit der Aktivitäten während des Systemstarts erfasst werden können. Diese muss über die Programmoberfläche oder passend geplante Optionen kontrolliert aktiviert und anschließend wieder beendet werden.

Bootaufzeichnungen können sehr groß werden und sensible Systeminformationen enthalten. Sie dürfen nicht unbegrenzt aktiviert bleiben.

11. Autoruns – Autostarts vollständig untersuchen

Autoruns zeigt deutlich mehr Autostartorte als die einfache Autostartansicht des Task-Managers.

Dazu können gehören:

Starten

[RO][PRIV][SENS] autoruns.exe

Wichtige Funktionen

Funktion Zweck
Hide Microsoft Entries Microsoft-Einträge ausblenden
Hide Windows Entries Windows-Einträge ausblenden
Verify Code Signatures digitale Signaturen prüfen
Check VirusTotal Hash beziehungsweise Datei über VirusTotal prüfen
Jump to Entry Registry- oder Dateisystemeintrag öffnen
Jump to Image zugehörige Datei öffnen
Process Explorer laufenden Prozess in Process Explorer öffnen
Compare aktuellen Zustand mit gespeicherter Ausgabe vergleichen
User Autostarts anderer Benutzer auswählen

Sicheres Deaktivieren

Ein Kontrollkästchen kann deaktiviert werden, um einen Autostart vorübergehend abzuschalten. Das ist in der Regel besser reversibel als das sofortige Löschen des Eintrags.

Eintrag deaktivieren
→ System oder Anwendung kontrolliert testen
→ Ergebnis dokumentieren
→ Eintrag bei ausbleibender Wirkung wieder aktivieren

Ein unbekannter oder nicht signierter Autostarteintrag ist nicht automatisch schädlich. Vor einer Änderung müssen Pfad, Herausgeber, Signatur, Zweck, Abhängigkeiten und betroffene Anwendung geprüft werden.

12. Autorunsc – Autostarts per Befehlszeile erfassen

Autorunsc ist die Befehlszeilenversion von Autoruns und eignet sich für dokumentierbare Bestandsaufnahmen.

Grundlegende Ausgabe

[RO][PRIV][SENS] autorunsc.exe -a * -c -h -s

Dabei können abhängig von der Werkzeugversion und den gewählten Optionen unter anderem Autostartkategorie, Pfad, Signatur und Hash ausgegeben werden.

CSV-Datei erzeugen

[RO][PRIV][SENS] autorunsc.exe -a * -c -h -s > "C:\Diagnose\autoruns.csv"

Nur Microsoft-Einträge ausblenden

[RO][PRIV][SENS] autorunsc.exe -a * -m -c -h -s

Vor einer produktiven Erfassung prüfen

[RO] autorunsc.exe /?

Die verfügbaren Parameter können sich mit Werkzeugversionen verändern. Vor automatisierter Verwendung muss die Hilfe der tatsächlich eingesetzten Version geprüft werden.

13. VirusTotal-Integration datenschutzgerecht verwenden

Mehrere Sysinternals-Werkzeuge können Hashwerte oder Dateien mit VirusTotal abgleichen.

Dabei muss unterschieden werden zwischen:

Mögliche Risiken

Die Übermittlung einer internen Datei an einen externen Analysedienst darf nicht automatisch erfolgen. Vorher müssen Datenschutz, Geheimhaltung, Eigentumsrechte und Sicherheitsvorgaben geprüft werden.

Ein VirusTotal-Ergebnis ist außerdem kein alleiniger Beweis:

14. TCPView – Netzwerkverbindungen Prozessen zuordnen

TCPView zeigt aktive TCP- und UDP-Endpunkte mit den zugehörigen Prozessen an.

Starten

[RO][PRIV][SENS] tcpview.exe

Typische Informationen

Typische Anwendungsfälle

Befehlszeilenversion

[RO][PRIV][SENS] tcpvcon.exe -a -c

Vor der Verwendung sollte die lokale Hilfe geprüft werden:

[RO] tcpvcon.exe /?

Eine Verbindung zu einer unbekannten IP-Adresse ist kein automatischer Sicherheitsvorfall. Content-Delivery-Netzwerke, Cloudplattformen, Telemetrie, Updates, Proxys und gemeinsam genutzte Infrastrukturen können die Zuordnung erschweren.

15. RAMMap – physischen Arbeitsspeicher analysieren

RAMMap zeigt, wie Windows den physischen Arbeitsspeicher verwendet.

Starten

[RO][PRIV][SENS] rammap.exe

Wichtige Ansichten

Ansicht Inhalt
Use Counts Speicher nach Verwendungsart
Processes Speicherzuordnung nach Prozessen
Priority Summary Speicher nach Prioritätsklassen
Physical Pages einzelne physische Speicherseiten
Physical Ranges physische Speicherbereiche
File Summary im Speicher gehaltene Dateidaten
File Details einzelne Dateiseiten
Page Table Speicher für Seitentabellen

Wichtige Speicherbegriffe

Begriff Bedeutung
Active aktuell verwendete Speicherseiten
Standby zwischengespeicherte Seiten, die bei Bedarf wiederverwendet werden können
Modified veränderte Seiten, die vor Wiederverwendung geschrieben werden müssen
Free unmittelbar freier Speicher
Zeroed gelöschte und zur Wiederverwendung vorbereitete Seiten
Driver Locked durch Treiber gesperrte Speicherseiten
Metafile Dateisystem-Metadaten im Cache

Bewertungsregeln

RAMMap enthält Funktionen zum Leeren bestimmter Speicherlisten. Diese verändern den Speicherzustand und können die Leistung vorübergehend verschlechtern.

Speicherlisten dürfen nicht routinemäßig geleert werden, nur um eine niedrigere RAM-Anzeige zu erzeugen. Dadurch wird die Ursache eines Speicherproblems nicht behoben.

16. VMMap – virtuellen Speicher eines Prozesses untersuchen

VMMap analysiert den virtuellen und physischen Speicher eines einzelnen Prozesses.

Starten

[RO][PRIV][SENS] vmmap.exe

Anschließend wird ein laufender Prozess ausgewählt oder eine Anwendung durch VMMap gestartet.

Untersuchte Speicherarten

Typische Anwendungsfälle

Sinnvolle Vorgehensweise bei vermutetem Speicherleck

  1. Anwendung in einem definierten Ausgangszustand starten.
  2. ersten VMMap-Snapshot erfassen.
  3. reproduzierbare Aktion mehrfach ausführen.
  4. zweiten Snapshot erfassen.
  5. Snapshots vergleichen.
  6. wachsende Speichertypen identifizieren.
  7. Ergebnis mit Prozessmetriken, Dumps und Anwendungsprotokollen abgleichen.

Ein wachsender Working Set allein beweist kein Speicherleck. Caches und noch erreichbare, später freigegebene Daten können ebenfalls wachsen.

17. ProcDump – Speicherabbilder bei bestimmten Ereignissen erzeugen

ProcDump kann Speicherabbilder eines Prozesses erzeugen, wenn festgelegte Bedingungen eintreten.

Mögliche Auslöser sind unter anderem:

Hilfe der installierten Version anzeigen

[RO] procdump.exe -?

Manuelles vollständiges Speicherabbild eines Prozesses

[TEST][PRIV][SENS] procdump.exe -ma <PID> "C:\Diagnose"

Auf Prozessnamen warten und vollständigen Dump bei Ausnahme erzeugen

[TEST][PRIV][SENS] procdump.exe -ma -e -w "<PROZESSNAME.exe>" "C:\Diagnose"

Dump bei nicht reagierendem Fenster

[TEST][PRIV][SENS] procdump.exe -ma -h "<PROZESSNAME.exe>" "C:\Diagnose"

Überwachung beenden

Die betreffende ProcDump-Instanz muss kontrolliert beendet werden, wenn die Diagnose abgeschlossen ist.

Wichtige Planungsfragen

Vollständige Prozessabbilder können Passwörter, Tokens, Schlüssel, Dokumentinhalte, Datenbanksätze und andere Geheimnisse enthalten. Sie müssen wie hochsensible Daten geschützt werden.

18. Sysmon – sicherheitsrelevante Systemereignisse protokollieren

System Monitor, kurz Sysmon, ist ein Windows-Systemdienst mit Gerätetreiber. Nach der Installation protokolliert er ausgewählte Systemaktivitäten in das Windows-Ereignisprotokoll.

Sysmon kann abhängig von Version und Konfiguration unter anderem erfassen:

Wichtiger Speicherort

Anwendungs- und Dienstprotokolle
→ Microsoft
→ Windows
→ Sysmon
→ Operational

Sysmon mit Konfiguration installieren

[CHANGE][PRIV] sysmon.exe -accepteula -i "C:\Konfiguration\sysmon-config.xml"

Konfiguration aktualisieren

[CHANGE][PRIV] sysmon.exe -c "C:\Konfiguration\sysmon-config.xml"

Aktuelle Konfiguration anzeigen

[RO][PRIV][SENS] sysmon.exe -c

Sysmon deinstallieren

[CHANGE][PRIV] sysmon.exe -u

Sysmon besitzt keine automatische Alarmierungs- oder Bewertungslogik. Die Ereignisse müssen durch geeignete Regeln, ein SIEM, ein EDR-System oder eine kontrollierte manuelle Analyse ausgewertet werden.

19. Sysmon-Konfiguration fachgerecht planen

Eine Sysmon-Konfiguration bestimmt, welche Ereignisse einbezogen oder ausgeschlossen werden.

Ziele einer guten Konfiguration

Risiken einer ungeprüften Konfiguration

Beispiel einer minimalen XML-Grundstruktur

<Sysmon schemaversion="<SCHEMA-VERSION>">
  <EventFiltering>
    <ProcessCreate onmatch="include">
    </ProcessCreate>
  </EventFiltering>
</Sysmon>

Die erforderliche Schemaversion und die unterstützten Ereignisse müssen mit der tatsächlich verwendeten Sysmon-Version geprüft werden.

Konfigurationsschema anzeigen

[RO] sysmon.exe -s

Eine fremde Sysmon-Konfiguration sollte nicht ungeprüft in einer produktiven Umgebung übernommen werden. Sie muss an Systeme, Anwendungen, Datenschutz, Ereignissammlung und Erkennungsziele angepasst werden.

20. Sigcheck – Signaturen, Versionen und Hashwerte untersuchen

Sigcheck zeigt Datei- und Signaturinformationen an.

Einzelne Datei untersuchen

[RO][SENS] sigcheck.exe -a -h -i "<DATEI>"

Verzeichnis rekursiv untersuchen

[RO][SENS] sigcheck.exe -s -a -h "<VERZEICHNIS>"

Nicht signierte Dateien suchen

[RO][SENS] sigcheck.exe -u -e "<VERZEICHNIS>"

CSV-Ausgabe

[RO][SENS] sigcheck.exe -c -h "<DATEI>"

Typische Prüfungen

Auch legitime Programme können unsignierte Komponenten besitzen. Umgekehrt kann eine gültig signierte Datei für unerwünschte Zwecke missbraucht oder mit einem kompromittierten Zertifikat signiert worden sein.

21. ListDLLs – geladene DLLs anzeigen

ListDLLs zeigt geladene DLLs und deren Pfade an.

Alle geladenen DLLs anzeigen

[RO][PRIV][SENS] listdlls.exe

DLLs eines bestimmten Prozesses

[RO][PRIV][SENS] listdlls.exe <PID>

Alternativ kann nach einem Prozessnamen gefiltert werden:

[RO][PRIV][SENS] listdlls.exe "<PROZESSNAME>"

Nach einer bestimmten DLL suchen

[RO][PRIV][SENS] listdlls.exe -d "<DLL-NAME>"

Typische Auffälligkeiten

Der Dateiname allein ist nicht ausreichend. Pfad, Version, Signatur, Hash, Ladegrund und Anwendungskontext müssen gemeinsam bewertet werden.

22. Strings – lesbare Zeichenfolgen in Dateien suchen

Strings extrahiert lesbare ANSI- und Unicode-Zeichenfolgen aus Binärdateien.

Datei untersuchen

[RO][SENS] strings.exe "<DATEI>"

Mindestlänge festlegen

[RO][SENS] strings.exe -n 8 "<DATEI>"

Ausgabe nach einem Begriff filtern

[RO][SENS] strings.exe -n 8 "<DATEI>" | findstr /i "<SUCHBEGRIFF>"

Mögliche Anwendungsfälle

Einschränkungen

Strings ist ein Hinweiswerkzeug und kein vollständiges Verfahren zur Malwareanalyse oder zum Reverse Engineering.

23. Streams – alternative NTFS-Datenströme untersuchen

NTFS-Dateien können neben dem normalen Dateiinhalt alternative Datenströme besitzen. Windows verwendet solche Datenströme unter anderem für Herkunftsinformationen heruntergeladener Dateien.

Datenströme anzeigen

[RO][SENS] streams.exe "<DATEI>"

Verzeichnis rekursiv untersuchen

[RO][SENS] streams.exe -s "<VERZEICHNIS>"

Alternative Datenströme löschen

[CHANGE][DANGER] streams.exe -d "<DATEI-ODER-VERZEICHNIS>"

Das pauschale Löschen alternativer Datenströme kann Sicherheitskennzeichnungen wie Herkunftsinformationen entfernen und dadurch Schutzfunktionen beeinflussen. Vorher müssen Inhalt, Zweck und Auswirkungen geprüft werden.

PowerShell kann Datenströme ebenfalls anzeigen:

[RO][SENS] Get-Item "<DATEI>" -Stream *
24. AccessChk – effektive Zugriffsrechte untersuchen

AccessChk zeigt Zugriffsrechte auf verschiedene Windows-Objekte an.

Dazu gehören unter anderem:

Hilfe anzeigen

[RO] accesschk.exe /?

Verzeichnisrechte untersuchen

[RO][PRIV][SENS] accesschk.exe -d "<VERZEICHNIS>"

Rechte eines bestimmten Kontos prüfen

[RO][PRIV][SENS] accesschk.exe -d "<BENUTZER-ODER-GRUPPE>" "<VERZEICHNIS>"

Dienstrechte untersuchen

[RO][PRIV][SENS] accesschk.exe -c "<DIENSTNAME>"

Typische Anwendungsfälle

AccessChk-Ausgaben müssen zusammen mit Vererbung, Gruppenmitgliedschaften, Integritätsstufe, Privilegien, Freigaberechten und dem tatsächlichen Benutzerkontext bewertet werden.

25. AccessEnum und ShareEnum

AccessEnum

AccessEnum stellt Berechtigungen für Dateien, Verzeichnisse und Registrybereiche übersichtlich dar. Es kann helfen, Abweichungen innerhalb größerer Strukturen zu finden.

[RO][PRIV][SENS] accessenum.exe

Typische Verwendung:

ShareEnum

ShareEnum untersucht SMB-Freigaben und deren Sicherheitseinstellungen innerhalb erreichbarer Netzwerkbereiche.

[RO][PRIV][REMOTE][SENS] shareenum.exe

Zu prüfen sind unter anderem

ShareEnum darf nur in ausdrücklich freigegebenen Netzwerkbereichen verwendet werden. Eine technische Erreichbarkeit ist keine Berechtigung zum Scannen.

26. PsTools – lokale und entfernte Administration

PsTools ist eine Sammlung von Befehlszeilenwerkzeugen für lokale und entfernte Windows-Systeme.

Wichtige Werkzeuge

Werkzeug Hauptfunktion
PsExec Prozess lokal oder remote starten
PsInfo Systeminformationen abrufen
PsList Prozesse und Threads anzeigen
PsKill Prozesse beenden
PsService Dienste anzeigen oder steuern
PsLoggedOn angemeldete Benutzer untersuchen
PsLogList Ereignisprotokolle ausgeben
PsFile remote geöffnete Dateien anzeigen
PsPing Netzwerklatenz und Durchsatz testen
PsShutdown Computer herunterfahren oder neu starten
PsSuspend Prozesse anhalten oder fortsetzen
PsGetSid SID eines Computers oder Kontos anzeigen

Systeminformationen lokal abrufen

[RO][SENS] psinfo.exe

Systeminformationen remote abrufen

[RO][REMOTE][SENS] psinfo.exe \\<COMPUTER>

Prozesse remote anzeigen

[RO][REMOTE][SENS] pslist.exe \\<COMPUTER>

Angemeldete Benutzer untersuchen

[RO][REMOTE][SENS] psloggedon.exe \\<COMPUTER>

PsTools können administrative Remoteaktionen ausführen. Authentifizierung, Firewall, administrative Freigaben, Sicherheitsrichtlinien, Protokollierung und Auswirkungen auf das Zielsystem müssen vorher geklärt werden.

27. PsExec sicher einsetzen

PsExec kann Prozesse lokal oder auf entfernten Windows-Systemen starten.

Remote-Befehlszeile starten

[CHANGE][PRIV][REMOTE][SENS] psexec.exe \\<COMPUTER> cmd.exe

Befehl remote ausführen

[CHANGE][PRIV][REMOTE][SENS] psexec.exe \\<COMPUTER> ipconfig /all

Prozess als lokales Systemkonto starten

[CHANGE][PRIV][DANGER] psexec.exe -s -i cmd.exe

Der letzte Befehl erzeugt einen besonders privilegierten Kontext und darf nur für klar begründete administrative Diagnosen verwendet werden.

Sicherheitsregeln

Anmeldeinformationen in einer Befehlszeile können in Prozesslisten, Protokollen, Shellverläufen oder Diagnoseaufzeichnungen sichtbar werden.

28. PsPing – Netzwerkverbindungen und Leistung testen

PsPing erweitert einfache Ping-Tests um TCP-Verbindungs-, Latenz- und Durchsatzmessungen.

ICMP-Test

[TEST][SENS] psping.exe <ZIEL>

TCP-Port testen

[TEST][SENS] psping.exe <ZIEL>:<PORT>

Beispiel:

[TEST][SENS] psping.exe server.example:443

Längere Messung

[TEST][SENS] psping.exe -n 20 server.example:443

Für Bandbreitenmessungen ist eine passende PsPing-Instanz als Empfänger erforderlich. Die genauen Parameter müssen anhand der Hilfe der eingesetzten Version gewählt werden:

[RO] psping.exe /?

Bewertungsregeln

29. AD Explorer – Active Directory untersuchen

AD Explorer ist ein grafischer Viewer und Editor für Active Directory.

Das Werkzeug kann:

Starten

[RO][PRIV][REMOTE][SENS] adexplorer.exe

Typische Anwendungsfälle

Risiken

AD Explorer kann nicht nur lesen, sondern bei ausreichenden Rechten auch Objekte verändern. Ein versehentliches Ändern oder Löschen kann Domänendienste und Anwendungen beeinträchtigen.

Für reine Diagnosezwecke sollte nach Möglichkeit ein Konto mit nur den notwendigen Leserechten verwendet werden.

Snapshots können enthalten:

Sie müssen entsprechend geschützt werden.

30. AD Insight und AD Restore

AD Insight

AD Insight überwacht LDAP-Clientaufrufe eines Prozesses und kann helfen, Active-Directory-Kommunikation einer Anwendung zu untersuchen.

Typische Fragen:

[TEST][PRIV][SENS] adinsight.exe

Die Aufzeichnung kann sehr viele interne Verzeichnisinformationen enthalten.

AD Restore

AD Restore kann gelöschte Active-Directory-Objekte untersuchen und in unterstützten Fällen wiederherstellen.

[RO][PRIV][SENS] adrestore.exe

Eine tatsächliche Wiederherstellung verändert Active Directory:

[CHANGE][PRIV][DANGER]

AD Restore darf nicht ohne Kenntnis von AD-Papierkorb, Tombstone-Zustand, Replikation, Objektabhängigkeiten, Wiederherstellungsziel und organisatorischer Freigabe eingesetzt werden.

31. Coreinfo – CPU- und Virtualisierungsfunktionen prüfen

Coreinfo zeigt die Zuordnung logischer Prozessoren sowie unterstützte Prozessor- und Virtualisierungsfunktionen an.

Starten

[RO] coreinfo.exe

Virtualisierungsbezogene Informationen

[RO] coreinfo.exe -v

Typische Anwendungsfälle

Die Anzeige einer CPU-Funktion beweist nicht automatisch, dass sie von Firmware, Betriebssystem, Hypervisor und Anwendung vollständig nutzbar ist.

32. BgInfo – Systeminformationen auf dem Desktop anzeigen

BgInfo kann technische Systeminformationen in den Desktophintergrund einblenden.

Mögliche Angaben:

Starten

[RO][SENS] bginfo.exe

BgInfo eignet sich beispielsweise für:

Datenschutz beachten

Auf gemeinsam betrachteten Desktops dürfen keine unnötigen sensiblen Angaben angezeigt werden. Dazu gehören beispielsweise:

BgInfo ist eine Anzeigehilfe und kein Werkzeug zur laufenden Zustandsüberwachung.

33. Disk2vhd – Datenträgerabbild als virtuelle Festplatte

Disk2vhd erstellt virtuelle Festplattendateien aus Volumes eines laufenden Windows-Systems. Dafür kann der Volumeschattenkopie-Dienst verwendet werden, um einen konsistenteren Zeitpunkt abzubilden.

Starten

[TEST][PRIV][SENS] disk2vhd.exe

Mögliche Anwendungsfälle

Wichtige Grenzen

Eine virtualisierte Kopie eines Produktivsystems muss isoliert gestartet werden, damit keine doppelten Computerkonten, IP-Adressen, Dienste oder automatischen Aufgaben das Produktivnetz beeinflussen.

34. LiveKd – laufenden Kernel mit Debugger untersuchen

LiveKd ermöglicht die Untersuchung eines laufenden Windows-Systems mit Microsoft-Kerneldebuggern, ohne die klassische Remote-Debuggingverbindung zu einem zweiten Computer aufzubauen.

Starten

[TEST][PRIV][SENS] livekd.exe

Je nach Konfiguration wird ein kompatibler Microsoft-Debugger benötigt.

Mögliche Anwendungsfälle

Grenzen

LiveKd ist ein spezialisiertes Werkzeug für fortgeschrittene Windows- und Treiberanalyse. Es sollte nicht ohne Debuggingkenntnisse auf produktiven Systemen eingesetzt werden.

35. WinObj – Windows-Objektmanager untersuchen

WinObj zeigt den Namensraum des Windows-Objektmanagers.

Darin können unter anderem sichtbar sein:

Starten

[RO][PRIV][SENS] winobj.exe

Typische Anwendungsfälle

WinObj zeigt interne Windows-Objekte. Die bloße Existenz eines unbekannten Objekts ist kein Beweis für einen Fehler oder eine Kompromittierung.

36. PendMoves und MoveFile – Dateioperationen beim Neustart

Wenn Dateien während des laufenden Betriebs nicht ersetzt oder gelöscht werden können, kann Windows Operationen für den nächsten Systemstart vormerken.

Ausstehende Operationen anzeigen

[RO][PRIV][SENS] pendmoves.exe

Datei beim nächsten Neustart verschieben

[CHANGE][PRIV][RESTART] movefile.exe "<QUELLE>" "<ZIEL>"

Datei beim nächsten Neustart löschen

[CHANGE][PRIV][RESTART][DANGER] movefile.exe "<DATEI>" ""

Risiken

Vor dem Vormerken einer Löschung müssen Datei, Hersteller, Signatur, Anwendung, Wiederherstellungsweg und Auswirkungen eindeutig geklärt sein.

37. SDelete – sicher überschreiben

SDelete kann Dateien oder freien Speicherplatz überschreiben, um die Wiederherstellung gelöschter Daten zu erschweren.

Hilfe anzeigen

[RO] sdelete.exe /?

Datei sicher löschen

[CHANGE][PRIV][DANGER] sdelete.exe "<DATEI>"

Freien Speicherplatz bearbeiten

[CHANGE][PRIV][DANGER] sdelete.exe -c <LAUFWERK>

Wichtige Einschränkungen

SDelete ist keine allgemeine Fehlerbehebungsmaßnahme. Vor dem Einsatz müssen Datenträgertyp, Sicherungen, Snapshots, Aufbewahrungspflichten und Löschkonzept geprüft werden.

38. NotMyFault nur in isolierten Testsystemen verwenden

NotMyFault kann absichtlich:

Das Werkzeug dient beispielsweise zum Testen von:

[DANGER][PRIV][RESTART] notmyfault.exe

NotMyFault darf niemals auf einem produktiven System, einem gemeinsam genutzten Schulungssystem oder einem nicht vollständig isolierten Testsystem ausprobiert werden. Es verursacht absichtlich schwerwiegende Störungen.

Vor einem Test müssen mindestens vorhanden sein:

39. Geeignetes Werkzeug nach Fehlerbild auswählen
Fehlerbild Geeignete Werkzeuge
Datei lässt sich nicht löschen Process Explorer, Handle
Anwendung startet nicht Process Monitor, Autoruns, Ereignisanzeige
Anwendung findet Datei nicht Process Monitor
Zugriff verweigert Process Monitor, AccessChk, AccessEnum
hohe CPU-Auslastung Process Explorer, ProcDump, Leistungsüberwachung
wachsender RAM-Verbrauch Process Explorer, VMMap, RAMMap, ProcDump
unbekannter Autostart Autoruns, Sigcheck, Process Explorer
unbekannte Netzwerkverbindung TCPView, Process Explorer, Sigcheck
sporadischer Absturz ProcDump, Ereignisanzeige, WinDbg
unbekannte DLL Process Explorer, ListDLLs, Sigcheck
verdächtige Datei Sigcheck, Strings, Streams
Active-Directory-Abfrage fehlerhaft AD Explorer, AD Insight
Remoteprozess untersuchen PsList, PsInfo, PsLoggedOn
TCP-Latenz oder Durchsatz PsPing
Kernel- oder Treiberproblem LiveKd, WinDbg, Process Monitor
Startproblem durch Zusatzsoftware Autoruns, Process Monitor Boot Logging
Speicheraufteilung unklar RAMMap
Prozessspeicher im Detail VMMap
ausstehende Dateilöschung PendMoves
CPU-Funktion oder Virtualisierung Coreinfo
Systemkopie für Laboranalyse Disk2vhd
40. Typischer Ablauf einer Sysinternals-Analyse
  1. Originale Fehlermeldung erfassen.
  2. Fehlerzeitpunkt dokumentieren.
  3. betroffenen Computer und Benutzer bestätigen.
  4. Reproduzierbarkeit prüfen.
  5. integrierte Windows-Protokolle untersuchen.
  6. kleinstes passende Sysinternals-Werkzeug auswählen.
  7. Werkzeugquelle, Version und Signatur kontrollieren.
  8. Berechtigungsbedarf prüfen.
  9. mögliche sensible Daten berücksichtigen.
  10. Aufzeichnung vorbereiten.
  11. Filter möglichst eng festlegen.
  12. Ausgangszustand dokumentieren.
  13. Aufzeichnung starten.
  14. Fehler einmal reproduzieren.
  15. Aufzeichnung unmittelbar beenden.
  16. Ereignisse zeitlich eingrenzen.
  17. Prozess, Pfad, Benutzer, Operation und Ergebnis vergleichen.
  18. normale Such- und Fehlversuche von relevanten Fehlern unterscheiden.
  19. Befund mit Ereignisanzeige und Anwendungsprotokollen abgleichen.
  20. Hypothese formulieren.
  21. möglichst kleinen und reversiblen Test planen.
  22. Sicherung und Rückfallplan prüfen.
  23. Änderung durchführen.
  24. Funktion erneut testen.
  25. Diagnosewerkzeuge und temporäre Überwachung beenden.
  26. Daten geschützt speichern oder ordnungsgemäß löschen.
  27. Ursache, Maßnahme und Ergebnis dokumentieren.
41. Beispiel – Anwendung meldet „Datei nicht gefunden“

Ausgangslage

Eine Anwendung meldet beim Start, eine Konfigurationsdatei sei nicht vorhanden. Die Datei ist im erwarteten Verzeichnis sichtbar.

Vorgehensweise

  1. tatsächlichen Anwendungsprozess bestimmen.
  2. Process Monitor starten.
  3. Aufzeichnung anhalten und leeren.
  4. Filter auf den Prozessnamen setzen.
  5. optional nach einem Teil des Dateinamens filtern.
  6. Aufzeichnung starten.
  7. Fehler reproduzieren.
  8. Aufzeichnung beenden.
  9. Operationen wie CreateFile untersuchen.
  10. tatsächlich abgefragten Pfad prüfen.
  11. Benutzerkontext kontrollieren.
  12. Ergebnisse vor und nach dem Fehler vergleichen.

Mögliche Befunde

Geeignete Ergänzungen

42. Beispiel – Anwendung verbraucht immer mehr Arbeitsspeicher

Vorgehensweise

  1. Ausgangswert im Task-Manager oder mit PowerShell erfassen.
  2. Process Explorer zur Beobachtung verwenden.
  3. Private Bytes, Working Set und Commit unterscheiden.
  4. VMMap-Snapshot im Ausgangszustand speichern.
  5. reproduzierbare Benutzeraktion mehrfach ausführen.
  6. zweiten VMMap-Snapshot erstellen.
  7. wachsende Speicherart bestimmen.
  8. bei Bedarf ProcDump kontrolliert konfigurieren.
  9. Speicherabbild mit geeignetem Debugger untersuchen.
  10. Anwendungsversion und bekannte Fehler des Herstellers prüfen.

Nicht ausreichend als Beweis

Stärkerer Hinweis auf ein Leck

Ein bestimmter Speicherbereich wächst bei wiederholbarer identischer Aktion fortlaufend, wird nicht wieder freigegeben und korreliert mit der Störung.

43. Beispiel – langsamer Anwendungsstart

Geeignete Werkzeuge

Vorgehensweise

  1. Startzeit reproduzierbar messen.
  2. Process Monitor vorbereiten.
  3. nur den Startvorgang aufzeichnen.
  4. Ereignisse nach Dauer untersuchen.
  5. wiederholte Datei- oder Registryzugriffe identifizieren.
  6. Netzwerkpfade und Namensauflösung beachten.
  7. untergeordnete Prozesse im Process Tree prüfen.
  8. Signaturen und Pfade geladener Komponenten kontrollieren.
  9. Ergebnis mit einem funktionierenden System vergleichen.

Mögliche Ursachen

44. Gefährliche Fehlinterpretationen vermeiden
Beobachtung Nicht automatisch bewiesen
Prozess ist nicht signiert Prozess ist Schadsoftware
VirusTotal zeigt einen Treffer Datei ist eindeutig schädlich
VirusTotal zeigt keinen Treffer Datei ist sicher
Process Monitor zeigt ACCESS DENIED Dieser Zugriff verursacht den Fehler
Process Monitor zeigt NAME NOT FOUND Die Datei fehlt fehlerhaft
hohe Zahl offener Handles Handle-Leck
viele TCP-Verbindungen Angriff oder Schadsoftware
unbekannte Remote-IP unberechtigter Datenverkehr
hoher Standby-Speicher Arbeitsspeichermangel
Prozess besitzt hohen Working Set Speicherleck
DLL liegt im Benutzerprofil DLL ist bösartig
Autostarteintrag ist unbekannt Eintrag darf gelöscht werden
Sysmon erzeugt kein Ereignis Aktivität fand nicht statt
Prozess läuft als SYSTEM Prozess ist legitim
Datei besitzt Microsoft im Namen Datei stammt von Microsoft
45. Diagnosedaten sicher speichern und weitergeben

Sysinternals-Ausgaben können enthalten:

Vor der Weitergabe

  1. Empfänger und Zweck bestimmen.
  2. erforderlichen Datenumfang begrenzen.
  3. Datei auf Geheimnisse prüfen.
  4. personenbezogene Daten redigieren.
  5. verschlüsselten Übertragungsweg verwenden.
  6. Zugriffsrechte beschränken.
  7. Aufbewahrungsdauer festlegen.
  8. Löschung dokumentieren.
  9. öffentliche Uploadplattformen vermeiden.
  10. Speicherabbilder besonders schützen.

Besonders sensible Dateitypen

Dateityp Risiko
PML-Aufzeichnung Pfade, Registry, Prozesse, Benutzer und Aktivitäten
Prozessdump vollständige Speicherinhalte des Prozesses
Kernel-Dump umfangreiche System- und Speicherinformationen
AD-Explorer-Snapshot Verzeichnisstruktur und Objektattribute
Autoruns-Export Softwarebestand, Pfade und Autostarts
TCPView-Export Netzwerkziele und Prozesszuordnung
Sysmon-Protokoll Befehlszeilen, Hashwerte, DNS- und Netzwerkaktivität
46. Schnelle Werkzeugübersicht
Aufgabe Werkzeug
Prozesshierarchie anzeigen Process Explorer
offene Datei finden Process Explorer, Handle
geladene DLLs prüfen Process Explorer, ListDLLs
Datei- und Registryzugriffe verfolgen Process Monitor
Bootaktivität aufzeichnen Process Monitor
Autostarts untersuchen Autoruns
Autostarts exportieren Autorunsc
Netzwerkverbindungen zuordnen TCPView
physische RAM-Nutzung analysieren RAMMap
Prozessspeicher analysieren VMMap
Prozessdump erstellen ProcDump
dauerhafte Sicherheitsereignisse erfassen Sysmon
Signatur und Hash prüfen Sigcheck
lesbare Binärdateiinhalte finden Strings
alternative NTFS-Datenströme anzeigen Streams
Berechtigungen untersuchen AccessChk
Berechtigungsabweichungen suchen AccessEnum
Freigaben untersuchen ShareEnum
Remoteprozesse starten PsExec
Remoteprozesse anzeigen PsList
Systeminformationen remote abrufen PsInfo
angemeldete Benutzer prüfen PsLoggedOn
Netzwerklatenz testen PsPing
Active Directory durchsuchen AD Explorer
LDAP-Aufrufe verfolgen AD Insight
gelöschte AD-Objekte untersuchen AD Restore
CPU-Funktionen anzeigen Coreinfo
Systemdaten auf Desktop anzeigen BgInfo
virtuelle Systemkopie erstellen Disk2vhd
laufenden Kernel untersuchen LiveKd
Objektmanager anzeigen WinObj
ausstehende Dateioperationen anzeigen PendMoves
Dateioperation für Neustart planen MoveFile
Daten sicher überschreiben SDelete
Absturz absichtlich erzeugen NotMyFault – nur isoliertes Labor
47. Dokumentationsvorlage 
Ticket:
Datum und Uhrzeit:
Bearbeiter:

Computername:
Windows-Version:
Build:
Architektur:
Benutzerkontext:
Betroffener Prozess:
PID:
Prozesspfad:
Befehlszeile:
Prozessherausgeber:
Signaturstatus:

Originale Fehlermeldung:
Fehlerzeitpunkt:
Reproduzierbar:
Reproduktionsschritte:
Letzte funktionierende Nutzung:
Letzte Änderung:

Verwendetes Sysinternals-Werkzeug:
Werkzeugversion:
Bezugsquelle:
Hash des Werkzeugs:
Erhöht ausgeführt:
Startzeit der Aufzeichnung:
Endzeit der Aufzeichnung:
Verwendete Filter:
Verwendete Befehlszeile:
Speicherort der Diagnosedaten:

Relevanter Prozess:
Übergeordneter Prozess:
Benutzer:
Operation:
Objekt oder Pfad:
Ergebnis:
Zeitlicher Zusammenhang:
Vergleichssystem geprüft:
Normales Verhalten ausgeschlossen:

Autostarteintrag:
Signatur:
Hash:
VirusTotal verwendet:
Datei hochgeladen:
Freigabe für externen Dienst vorhanden:

Lokale Adresse:
Lokaler Port:
Remoteadresse:
Remoteport:
Verbindungsstatus:
Zugehöriger Prozess:

RAM-Ausgangswert:
RAM-Endwert:
Working Set:
Private Bytes:
Commit:
Wachsende Speicherart:
Dump erzeugt:
Dump-Typ:
Dump-Größe:
Dump geschützt gespeichert:

Sysmon-Konfiguration:
Sysmon-Ereignis-ID:
Ereignisquelle:
SIEM-Abfrage:

Vermutete Ursache:
Zusätzliche Datenquelle:
Geplante Änderung:
Sicherung geprüft:
Rückfallplan:
Änderung durchgeführt:
Neustart erforderlich:

Ergebnis nach Änderung:
Fehler erneut getestet:
Monitoring kontrolliert:
Temporäre Aufzeichnung beendet:
Diagnosedaten redigiert:
Aufbewahrungsfrist:
Abschluss:

Merksatz

Sysinternals macht interne Windows-Abläufe sichtbar, bestimmt aber nicht automatisch deren Bedeutung. Erst die Verbindung aus Fehlerzeitpunkt, Prozess, Benutzerkontext, Pfad, Operation, Ergebnis, Systemzustand und Vergleichsdaten ermöglicht eine belastbare Ursachenanalyse.

Quellen und weiterführende Dokumentation

5. Werkzeuge der Fehleranalyse

5.3 Windows Server, Active Directory und Gruppenrichtlinien

Windows-Server-Infrastrukturen bestehen häufig aus mehreren voneinander abhängigen Diensten. Eine Störung bei Anmeldung, Gruppenrichtlinien, Namensauflösung oder Dateizugriff kann deshalb ihre eigentliche Ursache in einem anderen Teilbereich haben.

Typische Abhängigkeiten sind:

Ein erfolgreicher Ping beweist weder eine funktionierende Domänenanmeldung noch eine fehlerfreie AD-Replikation. Ebenso beweist eine erfolgreiche Anmeldung nicht, dass alle Gruppenrichtlinien, DNS-Zonen oder Verzeichnisänderungen korrekt repliziert wurden.

Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] grundsätzlich nur lesende Diagnose
[TEST] erzeugt Testzugriffe oder zusätzliche Protokolle
[CHANGE] verändert Konfiguration, Cache oder Systemzustand
[PRIV] erhöhte oder administrative Rechte erforderlich beziehungsweise sinnvoll
[REMOTE] greift auf einen anderen Computer oder Dienst zu
[SENS] Ausgabe kann interne oder personenbezogene Informationen enthalten
[LOG] kann umfangreiche zusätzliche Protokolldaten erzeugen
[DANGER] fehlerhafte Verwendung kann größere Störungen verursachen
[RESTART] kann einen Neustart oder eine Dienstunterbrechung erfordern

Die Kennzeichnungen sind Sicherheitshinweise dieser Dokumentation und nicht Bestandteil der eigentlichen Befehle.

1. Abhängigkeiten einer Windows-Domäne verstehen

Eine typische Domänenanmeldung umfasst mehrere Schritte:

  1. Der Client ermittelt über DNS einen geeigneten Domain Controller.
  2. Der DC-Locator berücksichtigt Domäne, Standort und verfügbare Dienste.
  3. Client und Domain Controller prüfen ihre Vertrauensbeziehung.
  4. Kerberos oder NTLM authentifiziert den Benutzer.
  5. Active Directory liefert Benutzer-, Computer- und Gruppeninformationen.
  6. SYSVOL stellt Gruppenrichtliniendateien und Anmeldeskripte bereit.
  7. Der Gruppenrichtliniendienst ermittelt und verarbeitet passende GPOs.
  8. Weitere Dienste stellen Profile, Laufwerke, Drucker oder Anwendungen bereit.

Daraus ergibt sich eine wichtige Diagnose-Reihenfolge:

  1. lokaler Netzwerkzustand
  2. IP-Konfiguration
  3. DNS-Clientkonfiguration
  4. DNS-Auflösung der Domänendienste
  5. Erreichbarkeit eines geeigneten Domain Controllers
  6. Uhrzeit und Zeitzone
  7. Secure Channel
  8. Kerberos-Tickets und SPNs
  9. AD-Replikation
  10. SYSVOL und DFS-Replikation
  11. Gruppenrichtlinienverarbeitung
  12. abhängige Serverrollen

In Active Directory ist DNS Bestandteil der Dienstermittlung. Ein Client, der ausschließlich einen öffentlichen DNS-Server verwendet, kann zwar Internetnamen auflösen, aber normalerweise die internen Domänendienste nicht korrekt ermitteln.

2. Diagnosekontext und Ausgangslage dokumentieren

Vor der ersten Änderung müssen mindestens folgende Angaben erfasst werden:

Grundinformationen auf einem Client

[RO][SENS] hostname
[RO][SENS] whoami
[RO][SENS] whoami /upn
[RO][SENS] whoami /user
[RO][SENS] whoami /groups
[RO][SENS] systeminfo
[RO][SENS] ipconfig /all

Domäneninformationen mit PowerShell

[RO][SENS] Get-CimInstance Win32_ComputerSystem |
    Select-Object Name, Domain, PartOfDomain

Anmelde- und Logonserver-Variablen

[RO][SENS] set LOGONSERVER
[RO][SENS] set USERDNSDOMAIN
[RO][SENS] set USERDOMAIN

Die Variable LOGONSERVER ist ein nützlicher Hinweis, aber keine vollständige Aussage darüber, welcher Domain Controller bei allen späteren LDAP-, Kerberos-, DNS- oder GPO-Vorgängen verwendet wird.

3. Ereignisprotokolle gezielt untersuchen

Wichtige Protokolle befinden sich in der Ereignisanzeige unter:

Ereignisanzeige
├── Windows-Protokolle
│   ├── Anwendung
│   ├── Sicherheit
│   └── System
└── Anwendungs- und Dienstprotokolle
    └── Microsoft
        └── Windows

Relevante Protokollbereiche können sein:

GroupPolicy-Betriebsprotokoll

Anwendungs- und Dienstprotokolle
└── Microsoft
    └── Windows
        └── GroupPolicy
            └── Operational

Ereignisse per PowerShell abrufen

[RO][PRIV][SENS] Get-WinEvent -LogName System -MaxEvents 100

[RO][PRIV][SENS] Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 100

Nach Zeitraum und Ebene filtern

[RO][PRIV][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = "System"
    StartTime = (Get-Date).AddHours(-2)
    Level     = 2,3
}

Verfügbare Protokolle suchen

[RO][SENS] Get-WinEvent -ListLog * |
    Where-Object LogName -match "GroupPolicy|DNS|DFS|Kerberos|Netlogon|Failover"

Ereignis-IDs dürfen nicht isoliert interpretiert werden. Quelle, Windows-Version, Ereignistext, Fehlercode, Zeitpunkt und begleitende Ereignisse müssen gemeinsam ausgewertet werden.

4. Domain Controller mit DCDiag prüfen

dcdiag führt verschiedene Tests für Domain Controller aus. Abhängig von den Parametern werden unter anderem Erreichbarkeit, DNS, Replikation, Dienste, Rolleninhaber und Verzeichnispartitionen geprüft.

Grundprüfung des lokalen Domain Controllers

[TEST][PRIV][SENS] dcdiag

Ausführliche Ausgabe

[TEST][PRIV][SENS] dcdiag /v

Bestimmten Domain Controller prüfen

[TEST][PRIV][REMOTE][SENS] dcdiag /s:<DC-NAME>

Alle Domain Controller des Unternehmensbereichs prüfen

[TEST][PRIV][REMOTE][SENS] dcdiag /e

DNS-Tests ausführen

[TEST][PRIV][REMOTE][SENS] dcdiag /test:DNS /e /v

Bestimmten Test ausführen

[TEST][PRIV][SENS] dcdiag /test:<TESTNAME>

Ausgabe in Dateien schreiben

[TEST][PRIV][SENS] dcdiag /v /f:"<AUSGABEDATEI>"

Wichtige Bewertungsfragen

dcdiag liefert mehrere unabhängige Testergebnisse. Eine einzelne Warnung beweist nicht automatisch einen Gesamtausfall des Domain Controllers.

5. AD-Replikation mit Repadmin untersuchen

Active Directory ist ein Multi-Master-Verzeichnis. Änderungen werden zwischen Domain Controllern repliziert. Fehler können dazu führen, dass Benutzer, Gruppen, Kennwörter, Computerobjekte oder DNS-Daten auf verschiedenen DCs unterschiedliche Stände besitzen.

Gesamtübersicht

[RO][PRIV][REMOTE][SENS] repadmin /replsummary

Die Ausgabe zeigt unter anderem:

Eingehende Replikationspartner anzeigen

[RO][PRIV][REMOTE][SENS] repadmin /showrepl

Bestimmten Domain Controller untersuchen

[RO][PRIV][REMOTE][SENS] repadmin /showrepl <DC-NAME>

Alle Domain Controller ausführlich untersuchen

[RO][PRIV][REMOTE][SENS] repadmin /showrepl * /csv

Replikationswarteschlange anzeigen

[RO][PRIV][SENS] repadmin /queue

Replikationsmetadaten eines Objekts untersuchen

[RO][PRIV][REMOTE][SENS] repadmin /showobjmeta <DC-NAME> "<DISTINGUISHED-NAME>"

Replikation anstoßen

[CHANGE][PRIV][REMOTE] repadmin /syncall <DC-NAME> /AdeP

Dieser Befehl darf nicht als erster Diagnoseschritt verwendet werden. Er verändert zwar keine AD-Objektinhalte direkt, löst aber Replikationsvorgänge aus und kann Netzwerk- sowie Systemlast erzeugen.

Typische Fehlerbereiche

Fehler oder Beobachtung Möglicher Prüfbereich
RPC-Server nicht verfügbar DNS, Firewall, RPC, Routing, Dienste
Zugriff verweigert Secure Channel, Kerberos, Berechtigungen, Zeit
Zielprinzipalname falsch SPN, Computerkontokennwort, DNS, Kerberos
DNS-Nachschlagefehler DNS-Client, Zonen, SRV-Records, Registrierung
große Replikationsverzögerung Standortverbindungen, Zeitplan, Erreichbarkeit
nur eine Partition betroffen Namenskontext und zuständiger Replikationspfad
nur ein DC betroffen lokaler Dienst, DNS, Datenbank oder Netzwerkpfad

Eine manuell erfolgreich ausgelöste Replikation beweist nicht, dass Topologie, Zeitplan und automatische Replikation dauerhaft funktionieren.

6. Domain Controller über den DC-Locator ermitteln

Der DC-Locator ermittelt anhand von DNS-Daten, Domäne, Standort und Anforderungen einen geeigneten Domain Controller.

Domain Controller ermitteln

[TEST][SENS] nltest /dsgetdc:<DOMÄNE>

Beispiel:

[TEST][SENS] nltest /dsgetdc:example.internal

Ermittlung neu durchführen

[CHANGE][SENS] nltest /dsgetdc:<DOMÄNE> /force

Domain Controller auflisten

[RO][SENS] nltest /dclist:<DOMÄNE>

Standort des Computers anzeigen

[RO][SENS] nltest /dsgetsite

Standortabdeckung eines DCs untersuchen

[RO][SENS] nltest /dsgetsite

DNS-SRV-Einträge prüfen

[TEST][SENS] nslookup -type=SRV _ldap._tcp.dc._msdcs.<DOMÄNE>

[TEST][SENS] nslookup -type=SRV _kerberos._tcp.<DOMÄNE>

Zu prüfen sind:

Das direkte Eintragen eines Domain Controllers in die Hosts-Datei ersetzt die DNS-basierte Dienstermittlung nicht und kann die eigentliche Ursache verdecken.

7. Secure Channel prüfen

Domänenmitglieder besitzen ein Computerkonto mit einem Kennwort. Der Secure Channel verwendet diese Vertrauensbeziehung für die Kommunikation mit der Domäne.

Secure Channel mit NLTest prüfen

[TEST][PRIV][REMOTE][SENS] nltest /sc_verify:<DOMÄNE>

Vertraute Domäne abfragen

[RO][PRIV][SENS] nltest /sc_query:<DOMÄNE>

PowerShell-Prüfung auf einem Domänenmitglied

[TEST][PRIV][REMOTE] Test-ComputerSecureChannel -Verbose

Test-ComputerSecureChannel ist für Domänenmitglieder vorgesehen. Die Interpretation auf Domain Controllern unterscheidet sich, weil DCs eigene Replikations- und Vertrauensmechanismen verwenden.

Reparatur mit PowerShell

[CHANGE][PRIV][REMOTE][DANGER] Test-ComputerSecureChannel -Repair -Credential "<DOMÄNE>\<ADMIN-KONTO>"

Vor einer Reparatur müssen geprüft werden:

Ein Computer sollte nicht vorschnell aus der Domäne entfernt und wieder aufgenommen werden. Dadurch können Computerkonto, Zertifikate, lokale Profile, verschlüsselte Daten, Dienstkonten und Verwaltungszuordnungen beeinflusst werden.

8. DNS-Clientkonfiguration der Domänenmitglieder prüfen

Vollständige IP-Konfiguration

[RO][SENS] ipconfig /all

PowerShell-Übersicht

[RO][SENS] Get-DnsClientServerAddress

[RO][SENS] Get-NetIPConfiguration

Zu prüfen sind:

DNS-Clientcache anzeigen

[RO][SENS] ipconfig /displaydns

DNS-Clientcache leeren

[CHANGE] ipconfig /flushdns

Das Leeren des Caches kann einen neuen Auflösungsversuch erzwingen, beseitigt aber keine fehlerhafte Zone, falsche Delegierung oder falsche DNS-Clientkonfiguration.

DNS-Namen prüfen

[TEST][SENS] Resolve-DnsName "<HOSTNAME>"

[TEST][SENS] Resolve-DnsName "<FQDN>" -Type A

[TEST][SENS] Resolve-DnsName "_ldap._tcp.dc._msdcs.<DOMÄNE>" -Type SRV

Ein Domänenclient sollte nicht ohne geplante interne DNS-Weiterleitung öffentliche DNS-Resolver zusätzlich zu internen AD-DNS-Servern verwenden. Windows behandelt mehrere eingetragene DNS-Server nicht als einfache interne-und-externe Suchreihenfolge.

9. DNS-Server und AD-integrierte Zonen untersuchen

Wichtige Prüfbereiche im DNS-Manager:

DNS-Serverzonen mit PowerShell anzeigen

[RO][PRIV][SENS] Get-DnsServerZone

Ressourceneinträge einer Zone anzeigen

[RO][PRIV][SENS] Get-DnsServerResourceRecord -ZoneName "<ZONE>"

DNS-Servereinstellungen anzeigen

[RO][PRIV][SENS] Get-DnsServer

Weiterleitungen anzeigen

[RO][PRIV][SENS] Get-DnsServerForwarder

DNS-Diagnose mit DCDiag

[TEST][PRIV][SENS] dcdiag /test:DNS /v

DNS-Registrierung eines Domänenmitglieds anfordern

[CHANGE] ipconfig /registerdns

Auf einem Domain Controller kann außerdem eine erneute Registrierung domänenbezogener Einträge erforderlich sein. Dienstneustarts dürfen jedoch erst nach Prüfung der Auswirkungen erfolgen.

DNS-Debugprotokollierung

Die DNS-Debugprotokollierung kann sehr viele Daten und interne Abfragen erfassen. Sie sollte:

  1. nur mit einem konkreten Fehlerbild aktiviert werden,
  2. nach Client, Protokoll oder Pakettyp begrenzt werden,
  3. nur so lange wie erforderlich laufen,
  4. hinsichtlich Speicherplatz überwacht werden,
  5. anschließend wieder deaktiviert werden.
[CHANGE][PRIV][LOG][SENS]

DNS-Debuglogs können interne Hostnamen, abgefragte Dienste, Clientadressen und Benutzeraktivitäten offenlegen.

10. Netlogon-Protokollierung kontrolliert verwenden

Netlogon ist unter anderem an Domänenanmeldung, DC-Locator und Secure-Channel-Vorgängen beteiligt.

Eine erweiterte Netlogon-Protokollierung darf nur zeitlich begrenzt aktiviert werden.

Aktuellen Netlogon-Zustand prüfen

[RO][PRIV] sc query netlogon

Netlogon-Diagnoseprotokollierung aktivieren

[CHANGE][PRIV][LOG][SENS] nltest /dbflag:0x2080ffff

Protokollierung wieder auf den Standardzustand zurücksetzen

[CHANGE][PRIV] nltest /dbflag:0x0

Das Protokoll befindet sich typischerweise unter:

%windir%\debug\netlogon.log

Vor und während der Aufzeichnung müssen geprüft werden:

Der Debug-Schalter darf nicht unkontrolliert dauerhaft aktiviert bleiben. Die Datei kann umfangreich werden und interne Domäneninformationen enthalten.

11. Kerberos-Tickets mit Klist untersuchen

Kerberos verwendet Tickets zur Authentifizierung. Dabei sind unter anderem Client, Key Distribution Center, Zielservice, SPN, Uhrzeit und DNS beteiligt.

Tickets des aktuellen Anmeldekontexts anzeigen

[RO][SENS] klist

Ticket Granting Tickets anzeigen

[RO][SENS] klist tgt

Kerberos-Sitzungen anzeigen

[RO][SENS] klist sessions

Tickets löschen

[CHANGE][SENS] klist purge

Das Löschen der Tickets beeinflusst den aktuellen Authentifizierungskontext. Anwendungen müssen danach möglicherweise neue Tickets anfordern.

Ticket für einen Dienst anfordern

[TEST][REMOTE][SENS] klist get <SPN>

Typische Prüfungen

klist purge ist keine Ursachenbehebung. Wenn DNS, SPN, Zeit oder Kontokonfiguration fehlerhaft sind, tritt das Problem nach Ausstellung neuer Tickets erneut auf.

12. Service Principal Names mit SetSPN prüfen

Ein SPN identifiziert eine Dienstinstanz für Kerberos. Er muss dem richtigen AD-Konto eindeutig zugeordnet sein.

SPNs eines Kontos anzeigen

[RO][PRIV][SENS] setspn -L "<KONTO>"

Bestimmten SPN suchen

[RO][PRIV][SENS] setspn -Q "<SPN>"

Forestweit nach doppelten SPNs suchen

[RO][PRIV][REMOTE][SENS] setspn -X

SPN mit Duplikatprüfung registrieren

[CHANGE][PRIV][DANGER] setspn -S "<SPN>" "<KONTO>"

SPN entfernen

[CHANGE][PRIV][DANGER] setspn -D "<SPN>" "<KONTO>"

Vor jeder Änderung müssen geprüft werden:

Typische Kerberos-Probleme entstehen durch:

SPNs dürfen nicht durch Ausprobieren auf verschiedene Konten geschrieben werden. Eine falsche Zuordnung kann die Kerberos-Authentifizierung mehrerer Systeme beeinträchtigen.

13. Zeitsynchronisation mit W32Time prüfen

Kerberos benötigt ausreichend übereinstimmende Zeitangaben. In einer AD-Domäne folgt die Zeithierarchie grundsätzlich der Domänenhierarchie. Der PDC-Emulator der Gesamtstruktur-Stammdomäne besitzt dabei eine besondere Rolle.

Status anzeigen

[RO][SENS] w32tm /query /status

Zeitquelle anzeigen

[RO][SENS] w32tm /query /source

Konfiguration anzeigen

[RO][SENS] w32tm /query /configuration

Peers anzeigen

[RO][SENS] w32tm /query /peers

Domänenhierarchie überwachen

[TEST][REMOTE][SENS] w32tm /monitor

Abweichung zu einem Computer messen

[TEST][REMOTE][SENS] w32tm /stripchart /computer:<COMPUTER> /dataonly /samples:10

Neue Synchronisation anfordern

[CHANGE][PRIV][REMOTE] w32tm /resync

Zu prüfen sind:

FSMO-Rollen anzeigen

[RO][PRIV][SENS] netdom query fsmo

Die manuelle Konfiguration externer Zeitserver auf allen Domänenmitgliedern kann die vorgesehene AD-Zeithierarchie umgehen. Änderungen müssen passend zur Rolle des Systems geplant werden.

14. Gruppenrichtlinienergebnis mit GPResult untersuchen

gpresult zeigt die Resultant Set of Policy, also die ermittelten Gruppenrichtlinienergebnisse für Computer und Benutzer.

Zusammenfassung

[RO][SENS] gpresult /r

Ausführliche Ausgabe

[RO][SENS] gpresult /v

Maximal ausführliche Textausgabe

[RO][SENS] gpresult /z

HTML-Bericht erzeugen

[RO][SENS] gpresult /h "<BERICHT>.html"

Nur Computerrichtlinien anzeigen

[RO][PRIV][SENS] gpresult /scope computer /r

Nur Benutzerrichtlinien anzeigen

[RO][SENS] gpresult /scope user /r

Bericht für einen anderen Benutzer

[RO][PRIV][SENS] gpresult /user "<DOMÄNE>\<BENUTZER>" /h "<BERICHT>.html"

Wichtige Auswertungsbereiche:

Eine GPO kann in der Gruppenrichtlinienverwaltung vorhanden und mit einer OU verknüpft sein, ohne auf das untersuchte Objekt angewendet zu werden.

15. Gruppenrichtlinienabruf mit GPUpdate testen

Normale Aktualisierung

[CHANGE][REMOTE] gpupdate

Alle Richtlinieneinstellungen erneut verarbeiten

[CHANGE][REMOTE] gpupdate /force

Zeitlimit festlegen

[CHANGE][REMOTE] gpupdate /wait:<SEKUNDEN>

Abmeldung zulassen, falls erforderlich

[CHANGE][REMOTE] gpupdate /logoff

Neustart zulassen, falls erforderlich

[CHANGE][REMOTE][RESTART] gpupdate /boot

gpupdate /force sollte nicht reflexartig auf vielen Systemen gleichzeitig ausgeführt werden. Es kann:

Empfohlener Testablauf

  1. gpresult vor der Aktualisierung speichern.
  2. Fehlerzeitpunkt dokumentieren.
  3. Ereignisprotokoll prüfen.
  4. gpupdate auf einem kontrollierten Testsystem ausführen.
  5. Meldungen vollständig dokumentieren.
  6. erforderliche Abmeldung oder Neustart berücksichtigen.
  7. gpresult erneut erzeugen.
  8. vorherigen und nachfolgenden Zustand vergleichen.
16. Warum eine GPO nicht angewendet wird

Mögliche Ursachen:

Prüfreihenfolge

  1. Objekt und OU bestätigen.
  2. GPO-Verknüpfung bestätigen.
  3. GPO-Status prüfen.
  4. Sicherheitsfilter prüfen.
  5. Delegierung prüfen.
  6. WMI-Filter prüfen.
  7. Vererbung und Reihenfolge prüfen.
  8. gpresult auswerten.
  9. GroupPolicy-Betriebsprotokoll auswerten.
  10. DNS, DC-Locator und SYSVOL testen.
  11. AD- und DFS-R-Replikation prüfen.
  12. erforderliche Abmeldung oder Neustart testen.
17. GPO-Verarbeitung fachgerecht dokumentieren

Für jede untersuchte Gruppenrichtlinie sollten folgende Angaben erfasst werden:

Aufgabe:
Betroffener Benutzer:
Betroffener Computer:
Domäne:
Standort:
Verwendeter Domain Controller:

Name der GPO:
GPO-ID:
GPO-Status:
Benutzer- oder Computerkonfiguration:
Verknüpfte OU:
Verknüpfungsreihenfolge:
Verknüpfung aktiviert:
Erzwungen:
Vererbung blockiert:
Sicherheitsfilter:
Delegierung:
WMI-Filter:
Loopback-Modus:

Pfad der Richtlinieneinstellung:
Konfigurierte Einstellung:
Erwarteter Wert:
Tatsächlicher Wert:

GPResult vor dem Test:
GPUpdate-Ergebnis:
Abmeldung erforderlich:
Neustart erforderlich:
GPResult nach dem Test:
GroupPolicy-Ereignisse:
SYSVOL erreichbar:
AD-Replikation geprüft:
DFS-R-Replikation geprüft:

Ursache:
Änderung:
Rückfallplan:
Testergebnis:
18. SYSVOL und NETLOGON prüfen

SYSVOL enthält unter anderem Gruppenrichtliniendateien und Skripte. Active Directory speichert den Verzeichnisanteil einer GPO, während SYSVOL den Dateianteil enthält. Beide Teile müssen konsistent und repliziert sein.

Freigaben eines Domain Controllers anzeigen

[RO][REMOTE][SENS] net view \\<DC-NAME>

Erwartete Domänencontroller-Freigaben sind normalerweise:

SYSVOL öffnen

[TEST][REMOTE][SENS] dir \\<DC-NAME>\SYSVOL

NETLOGON öffnen

[TEST][REMOTE][SENS] dir \\<DC-NAME>\NETLOGON

Bestimmte Richtlinie prüfen

[RO][REMOTE][SENS] dir "\\<DC-NAME>\SYSVOL\<DOMÄNE>\Policies\{<GPO-GUID>}"

Zu vergleichen sind:

Dateien in SYSVOL dürfen nicht als normale Konfigurationsmethode manuell auf mehreren Domain Controllern bearbeitet oder kopiert werden. Dadurch können AD- und Dateianteil einer GPO inkonsistent werden.

19. DFS-Replikation von SYSVOL untersuchen

Moderne Windows-Domänen verwenden DFS Replication für SYSVOL. Wichtige Datenquellen sind:

DFS-R-Zustand abfragen

[RO][PRIV][SENS] dfsrdiag ReplicationState

Konfiguration neu aus Active Directory einlesen

[CHANGE][PRIV] dfsrdiag PollAD

DFS-R-Ereignisse abrufen

[RO][PRIV][SENS] Get-WinEvent -LogName "DFS Replication" -MaxEvents 200

Typische Prüfbereiche:

Eine DFS-R-Wiederherstellung oder autoritative SYSVOL-Synchronisierung ist eine eingriffsintensive Maßnahme. Sie darf erst nach gesicherter Diagnose, aktueller Sicherung und dokumentiertem Wiederherstellungsplan durchgeführt werden.

20. DHCP-Server untersuchen

DHCP-Probleme können dazu führen, dass Clients:

DHCP-Konfiguration auf dem Client

[RO][SENS] ipconfig /all

Lease freigeben

[CHANGE] ipconfig /release

Lease erneuern

[CHANGE][REMOTE] ipconfig /renew

Diese Befehle unterbrechen die aktuelle IP-Konnektivität und sollten nicht unüberlegt über eine entfernte Verwaltungssitzung ausgeführt werden.

DHCP-Server anzeigen

[RO][PRIV][SENS] Get-DhcpServerInDC

IPv4-Bereiche anzeigen

[RO][PRIV][REMOTE][SENS] Get-DhcpServerv4Scope -ComputerName "<DHCP-SERVER>"

Leases anzeigen

[RO][PRIV][REMOTE][SENS] Get-DhcpServerv4Lease -ComputerName "<DHCP-SERVER>" -ScopeId "<NETZ-ID>"

Bereichsstatistik anzeigen

[RO][PRIV][REMOTE][SENS] Get-DhcpServerv4ScopeStatistics -ComputerName "<DHCP-SERVER>"

Serveroptionen anzeigen

[RO][PRIV][REMOTE][SENS] Get-DhcpServerv4OptionValue -ComputerName "<DHCP-SERVER>"

Zu prüfen sind:

DHCP-Debug- und Auditlogs können MAC-Adressen, Hostnamen, IP-Adressen und zeitliche Gerätenutzung enthalten und müssen entsprechend geschützt werden.

21. DFS-Namespace und DFS-Replikation unterscheiden

DFS besteht aus unterschiedlichen Funktionen:

Komponente Aufgabe
DFS Namespace stellt einen einheitlichen logischen Pfad bereit
DFS Replication repliziert Ordnerinhalte zwischen Servern

Ein erreichbarer Namespace beweist nicht, dass alle Replikationspartner denselben Datenstand besitzen. Umgekehrt beweist ein gesunder DFS-R-Status nicht, dass Namespace-Ziele, Berechtigungen und Verweise korrekt funktionieren.

Namespacepfad testen

[TEST][REMOTE][SENS] dir "\\<DOMÄNE>\<NAMESPACE>"

DFS-Ziele und Verweise untersuchen

[RO][SENS] dfsutil /pktinfo

Zwischengespeicherte Verweise leeren

[CHANGE] dfsutil /pktflush

Typische Prüfbereiche

22. Failovercluster untersuchen

Ein Failovercluster besteht aus mehreren voneinander abhängigen Komponenten:

Cluster anzeigen

[RO][PRIV][REMOTE][SENS] Get-Cluster

Knoten anzeigen

[RO][PRIV][REMOTE][SENS] Get-ClusterNode

Clustergruppen anzeigen

[RO][PRIV][REMOTE][SENS] Get-ClusterGroup

Ressourcen anzeigen

[RO][PRIV][REMOTE][SENS] Get-ClusterResource

Quorum anzeigen

[RO][PRIV][REMOTE][SENS] Get-ClusterQuorum

Clusterprotokoll erzeugen

[TEST][PRIV][REMOTE][LOG][SENS] Get-ClusterLog -UseLocalTime -Destination "<VERZEICHNIS>"

Cluster validieren

[TEST][PRIV][REMOTE][LOG][SENS] Test-Cluster

Die vollständige Validierung kann Netzwerk-, Speicher- und Systemtests durchführen. Umfang und Auswirkungen müssen vor dem Start geprüft werden.

Typische Diagnosefragen

Das manuelle Verschieben oder Neustarten einer Clusterrolle ist eine Änderung am produktiven Dienst und keine rein lesende Diagnose.

23. Server Manager und Windows Admin Center richtig einordnen

Server Manager

Server Manager kann unter anderem anzeigen:

Windows Admin Center

Windows Admin Center kann abhängig von Version und Erweiterungen unter anderem verwalten:

Grenzen

Verwaltungsoberflächen fassen Zustände zusammen. Für belastbare Diagnosen müssen häufig Ereignisprotokolle, PowerShell-Ausgaben, Dienstprotokolle und Netzwerkdaten ergänzt werden.

24. Leistungsüberwachung auf Windows Server

Leistungsprobleme dürfen nicht allein anhand einer einzelnen CPU- oder RAM-Anzeige bewertet werden.

Wichtige Bereiche:

Leistungsindikatoren anzeigen

[RO][SENS] Get-Counter -ListSet *

Beispielhafte Systemindikatoren

[TEST][SENS] Get-Counter `
    "\Processor(_Total)\% Processor Time",
    "\Memory\Available MBytes",
    "\PhysicalDisk(_Total)\Avg. Disk sec/Transfer",
    "\System\Processor Queue Length"

Wichtige Regeln

Ein einzelner hoher Messwert beweist noch keinen Engpass. Entscheidend sind Dauer, Wiederholbarkeit, Warteschlangen, Antwortzeiten und Auswirkungen auf den Dienst.

25. Typische Fehlerbilder und geeignete Werkzeuge
Fehlerbild Geeignete Prüfungen
Benutzer kann sich nicht anmelden DNS, DC-Locator, Zeit, Secure Channel, Kerberos, Netlogon, Ereignisse
Anmeldung funktioniert nur manchmal mehrere DCs vergleichen, Replikation, DNS, Standorte, Zeit
neues Kennwort funktioniert nicht überall repadmin, verwendeten DC feststellen, PDC-Erreichbarkeit
neuer Benutzer ist auf einem Server unbekannt AD-Replikation, verwendeten DC, DNS
Computer meldet fehlende Vertrauensstellung Secure Channel, Computerkonto, DNS, Zeit
GPO wird nicht angewendet gpresult, GroupPolicy-Log, OU, Filter, SYSVOL, Replikation
GPO besitzt auf verschiedenen Clients andere Werte verwendeten DC, AD- und SYSVOL-Replikation, Filter
Netzlaufwerk fehlt GPO, DNS, DFS, SMB, Berechtigungen, Benutzerkontext
Domain Controller wird nicht gefunden DNS-Client, SRV-Records, DC-Locator, Firewall
Kerberos funktioniert nur mit bestimmtem Namen DNS, SPN, Alias, Dienstkonto
Zugriff fällt auf NTLM zurück Kerberos-Ticket, SPN, Zielname, DNS
Uhrzeit springt zurück W32Time, Domänenhierarchie, Hypervisor-Zeitquelle
DHCP-Client erhält APIPA DHCP-Server, Relay, VLAN, Bereich, Firewall
falscher DNS-Server per DHCP Bereichs- und Serveroptionen prüfen
SYSVOL fehlt DFS-R, Netlogon, DC-Zustand, Ereignisse
Dateien in DFS unterscheiden sich DFS-R-Zustand, Rückstand, Konflikte, Dateisperren
Clusterrolle startet nicht Ressourcenabhängigkeiten, Clusterlog, Systemlog, DNS, Speicher
Server Manager zeigt Server als offline WinRM, Firewall, DNS, Berechtigungen, Zielzustand
26. Empfohlener Gesamtablauf bei Domänenproblemen
  1. originale Fehlermeldung erfassen.
  2. Benutzer, Computer und Zeitpunkt bestätigen.
  3. Umfang der Störung bestimmen.
  4. letzte Änderung dokumentieren.
  5. lokale Netzwerkverbindung prüfen.
  6. ipconfig /all erfassen.
  7. konfigurierte DNS-Server prüfen.
  8. Domänennamen und SRV-Einträge auflösen.
  9. Domain Controller mit nltest /dsgetdc ermitteln.
  10. verwendeten Standort prüfen.
  11. Domain Controller gezielt erreichen.
  12. Uhrzeit und Zeitquelle vergleichen.
  13. Secure Channel prüfen.
  14. Kerberos-Tickets untersuchen.
  15. bei Dienstproblemen SPNs prüfen.
  16. System- und Anwendungsprotokolle auswerten.
  17. auf Domain Controllern dcdiag ausführen.
  18. AD-Replikation mit repadmin prüfen.
  19. bei GPO-Problemen gpresult sichern.
  20. GroupPolicy-Betriebsprotokoll untersuchen.
  21. SYSVOL auf mehreren DCs vergleichen.
  22. DFS-R-Ereignisse prüfen.
  23. Hypothese aus mehreren Befunden formulieren.
  24. kleinste reversible Maßnahme planen.
  25. Sicherung und Rückfallplan prüfen.
  26. Änderung kontrolliert durchführen.
  27. Funktion mit demselben Testszenario erneut prüfen.
  28. Replikation und Monitoring nachkontrollieren.
  29. temporäre Debugprotokollierung deaktivieren.
  30. Ursache, Maßnahme und Ergebnis dokumentieren.
27. Beispiel – Gruppenrichtlinie wird auf CLIENT1 nicht angewendet

Ausgangslage

Eine auf DC1 erstellte und mit einer OU verknüpfte GPO soll auf CLIENT1 angewendet werden. Die konfigurierte Einstellung ist auf dem Client nicht wirksam.

Vorgehensweise

  1. Benutzer- und Computername auf CLIENT1 bestätigen.
  2. prüfen, ob die Einstellung eine Benutzer- oder Computerrichtlinie ist.
  3. tatsächliche OU des Zielobjekts kontrollieren.
  4. GPO-Verknüpfung in der Gruppenrichtlinienverwaltung prüfen.
  5. GPO-Status und Verknüpfungsstatus prüfen.
  6. Sicherheitsfilter und Delegierung kontrollieren.
  7. WMI-Filter prüfen.
  8. gpresult vor einer Änderung erzeugen:
[RO][SENS] gpresult /h "%TEMP%\gpresult-vorher.html"
  1. verwendeten Domain Controller und DNS-Zustand prüfen:
[RO][SENS] set LOGONSERVER
[TEST][SENS] nltest /dsgetdc:<DOMÄNE>
[RO][SENS] ipconfig /all
  1. GroupPolicy-Betriebsprotokoll untersuchen.
  2. SYSVOL auf dem verwendeten DC prüfen.
  3. AD- und DFS-R-Replikation zwischen DC1 und weiteren DCs prüfen.
  4. kontrollierte Aktualisierung durchführen:
[CHANGE][REMOTE] gpupdate /force
  1. erforderliche Abmeldung oder Neustart durchführen.
  2. neuen Bericht erzeugen:
[RO][SENS] gpresult /h "%TEMP%\gpresult-nachher.html"
  1. beide Berichte vergleichen.

Mögliche Befunde

28. Beispiel – Benutzer kann sich nur an manchen Computern anmelden

Mögliche Ursachen

Prüfungen auf funktionierendem und betroffenem Computer

[RO][SENS] ipconfig /all
[TEST][SENS] nltest /dsgetdc:<DOMÄNE>
[RO][SENS] nltest /dsgetsite
[TEST][PRIV][SENS] nltest /sc_verify:<DOMÄNE>
[RO][SENS] w32tm /query /status
[RO][SENS] w32tm /query /source
[RO][SENS] klist
[RO][SENS] gpresult /r

Anschließend müssen die Ergebnisse miteinander verglichen werden:

29. Beispiel – Active-Directory-Änderung erscheint nicht auf DC2

Ausgangslage

Ein auf DC1 angelegtes oder geändertes Objekt ist auf DC2 nicht sichtbar.

Vorgehensweise

  1. Objekt und Änderungszeitpunkt dokumentieren.
  2. sicherstellen, dass tatsächlich unterschiedliche DCs abgefragt werden.
  3. AD-Replikationsübersicht erstellen:
[RO][PRIV][SENS] repadmin /replsummary
  1. eingehende Partner von DC2 untersuchen:
[RO][PRIV][SENS] repadmin /showrepl DC2
  1. betroffenen Namenskontext bestimmen.
  2. DNS-Auflösung zwischen DC1 und DC2 prüfen.
  3. RPC- und Firewall-Erreichbarkeit berücksichtigen.
  4. Uhrzeit vergleichen.
  5. Ereignisprotokoll Directory Service untersuchen.
  6. Replikationsmetadaten des Objekts vergleichen:
[RO][PRIV][SENS] repadmin /showobjmeta DC1 "<DISTINGUISHED-NAME>"

[RO][PRIV][SENS] repadmin /showobjmeta DC2 "<DISTINGUISHED-NAME>"
  1. erst nach Ursachenprüfung eine kontrollierte Replikation auslösen.
  2. anschließend automatische Replikation weiter beobachten.

Das manuelle Kopieren, erneute Anlegen oder Löschen des Objekts kann Konflikte erzeugen und die ursprüngliche Replikationsursache verdecken.

30. Gefährliche Fehlinterpretationen vermeiden
Beobachtung Nicht automatisch bewiesen
Ping zum DC funktioniert LDAP, Kerberos, SMB und RPC funktionieren
Domänenname wird aufgelöst alle benötigten SRV-Records sind korrekt
Anmeldung funktioniert Anmeldung erfolgte aktuell gegen einen DC
LOGONSERVER zeigt DC1 jeder Domänendienst verwendet DC1
gpupdate war erfolgreich gewünschte GPO wurde angewendet
GPO ist verknüpft Zielobjekt darf sie anwenden
GPO erscheint in gpresult jede einzelne Einstellung wurde erfolgreich verarbeitet
Benutzer ist Gruppenmitglied aktuelles Token enthält die neue Mitgliedschaft
klist zeigt Tickets Ticket gehört zum richtigen Dienst und SPN
SPN existiert SPN ist dem richtigen Konto eindeutig zugeordnet
Uhrzeit sieht gleich aus Zeitquelle und tatsächliche Abweichung sind korrekt
repadmin /replsummary zeigt wenig Fehler alle Partitionen und Objekte sind aktuell
SYSVOL ist erreichbar SYSVOL besitzt auf allen DCs denselben Stand
DHCP-Lease existiert Optionen, VLAN und DNS-Daten sind korrekt
Clusterressource ist online Anwendung ist fachlich funktionsfähig
Ereignis-ID ist bekannt Ursache ist ohne Ereignistext eindeutig
31. Sicherheits- und Datenschutzanforderungen

Diagnosedaten können enthalten:

Vor der Weitergabe müssen:

  1. Zweck und Empfänger bestimmt werden.
  2. benötigte Daten begrenzt werden.
  3. Kennwörter, Schlüssel und Tokens ausgeschlossen werden.
  4. personenbezogene Angaben redigiert werden.
  5. Dateien verschlüsselt übertragen werden.
  6. Zugriffsrechte beschränkt werden.
  7. Aufbewahrungsfristen festgelegt werden.
  8. temporäre Debuglogs wieder deaktiviert werden.
  9. nicht mehr benötigte Diagnosedaten sicher gelöscht werden.
  10. externe Analysedienste organisatorisch freigegeben sein.

Kennwörter dürfen nicht in Befehlszeilen, Dokumentationen, Screenshots oder Protokolldateien eingetragen werden.

32. Dokumentationsvorlage 
Ticket:
Datum und Uhrzeit:
Bearbeiter:

Betroffener Benutzer:
Betroffener Computer:
Windows-Version:
Serverrolle:
Domäne:
Active-Directory-Standort:
IP-Adresse:
DNS-Server:
Gateway:
VPN:
Verwendeter Domain Controller:
LOGONSERVER:

Originale Fehlermeldung:
Fehlerzeitpunkt:
Reproduzierbar:
Betroffene Systeme:
Letzte funktionierende Nutzung:
Letzte Änderung:

DC-Locator-Ergebnis:
Secure-Channel-Ergebnis:
Zeitquelle:
Zeitabweichung:
Kerberos-Tickets:
Verwendeter KDC:
Untersuchter SPN:
SPN-Zuordnung:
Doppelte SPNs:

DCDiag-Ergebnis:
Fehlgeschlagener Test:
Repadmin-Replikationsübersicht:
Betroffener Quell-DC:
Betroffener Ziel-DC:
Betroffener Namenskontext:
Letzte erfolgreiche Replikation:
Replikationsfehlercode:
Replikationsmetadaten geprüft:

DNS-Zone:
DNS-Record:
SRV-Records:
Dynamische Registrierung:
DNS-Ereignisse:
DNS-Debuglog verwendet:
Netlogon-Debuglog verwendet:
Debuglogging wieder deaktiviert:

GPO:
GPO-ID:
Benutzer- oder Computerrichtlinie:
Verknüpfte OU:
Sicherheitsfilter:
Delegierung:
WMI-Filter:
Vererbungsreihenfolge:
Loopback-Modus:
GPResult vorher:
GPUpdate-Ergebnis:
GPResult nachher:
GroupPolicy-Ereignisse:
Abmeldung erforderlich:
Neustart erforderlich:

SYSVOL erreichbar:
NETLOGON erreichbar:
GPO-Dateianteil vorhanden:
DFS-R-Status:
DFS-R-Ereignisse:
Replikationsrückstand:

DHCP-Server:
DHCP-Bereich:
Lease:
Bereichsauslastung:
Router-Option:
DNS-Option:
DNS-Suffix:
DHCP-Relay:
DHCP-Failover:

Cluster:
Clusterknoten:
Clusterrolle:
Fehlgeschlagene Ressource:
Abhängige Ressourcen:
Quorum:
Witness:
Clusterlog:
Failover-Zeitpunkt:

Vermutete Ursache:
Belege:
Geplante Maßnahme:
Sicherung:
Rückfallplan:
Änderung:
Ergebnis:
Wiederholungstest:
Monitoring:
Abschluss:

Merksatz

Bei Fehlern in Windows-Domänen muss die Abhängigkeitskette vollständig betrachtet werden: Netzwerk ermöglicht die Verbindung, DNS findet den Dienst, Zeit und Secure Channel schaffen die Vertrauensbasis, Kerberos authentifiziert, Active Directory liefert die Objekte, Replikation verteilt den Zustand und SYSVOL stellt die Gruppenrichtliniendateien bereit.

Quellen und weiterführende Dokumentation

5. Werkzeuge der Fehleranalyse

5.4 Linux – Werkzeuge zur Fehleranalyse

Linux-Systeme stellen zahlreiche integrierte Werkzeuge für die Fehleranalyse bereit. Die konkrete Verfügbarkeit und Ausgabe hängt unter anderem ab von:

Auf modernen Serverdistributionen wird häufig systemd eingesetzt. Andere Systeme können jedoch alternative Init- und Protokollierungssysteme verwenden.

Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[RO] grundsätzlich lesende Abfrage
[TEST] aktiver Test, der Netzwerk- oder Systemlast erzeugen kann
[CHANGE] verändert den Systemzustand
[PRIV] benötigt häufig Root-Rechte oder sudo
[REMOTE] kommuniziert mit einem anderen System oder Dienst
[LOG] erzeugt möglicherweise umfangreiche Protokolldaten
[SENS] Ausgabe kann interne oder personenbezogene Informationen enthalten
[DANGER] kann bei falscher Anwendung Dienste, Daten oder das gesamte System gefährden
[RESTART] kann einen Dienst- oder Systemneustart auslösen

Die Kennzeichnungen sind Sicherheitshinweise und kein Bestandteil des eigentlichen Befehls.

1. Diagnose vor der Änderung

Eine Linux-Fehleranalyse sollte nicht mit einem Neustart, einer Paketaktualisierung oder dem Löschen von Dateien beginnen. Zuerst muss der fehlerhafte Zustand gesichert werden.

Grundfragen

Grundlegende Systeminformationen

[RO][SENS] hostnamectl
[RO] uname -a
[RO] cat /etc/os-release
[RO] uptime
[RO][SENS] who
[RO][SENS] last -x

last -x kann unter anderem Anmeldungen, Neustarts und Herunterfahrvorgänge anzeigen. Die verfügbaren Daten hängen von der Protokollierung und Rotation der zugrunde liegenden Dateien ab.

2. Hilfe und Dokumentation direkt auf dem System verwenden

Vor der Verwendung unbekannter Optionen sollte die lokal installierte Dokumentation geprüft werden.

[RO] man <BEFEHL>
[RO] info <BEFEHL>
[RO] <BEFEHL> --help
[RO] apropos "<SUCHBEGRIFF>"
[RO] man -k "<SUCHBEGRIFF>"
[RO] type <BEFEHL>
[RO] command -V <BEFEHL>

Warum die lokale Dokumentation wichtig ist

Befehle aus fremden Anleitungen dürfen nicht ungeprüft mit Root-Rechten ausgeführt werden.

3. Systemzustand und Auslastung überblicken 
[RO] uptime
[RO] top
[RO] free -h
[RO] vmstat 1 10
[RO] cat /proc/loadavg
[RO] nproc
[RO] lscpu

Falls installiert:

[RO] htop
[RO] mpstat -P ALL 1 10
[RO] pidstat 1 10

Load Average richtig einordnen

Die drei Load-Average-Werte beziehen sich üblicherweise auf ungefähr 1, 5 und 15 Minuten. Sie erfassen nicht ausschließlich CPU-Auslastung, sondern unter Linux auch Tasks, die nicht unterbrechbar warten, beispielsweise auf bestimmte I/O-Vorgänge.

Die Bewertung muss deshalb berücksichtigen:

Ein hoher Load-Wert beweist allein weder eine CPU-Überlastung noch einen bestimmten Hardwarefehler.

4. Prozesse untersuchen 
[RO][SENS] ps aux
[RO][SENS] ps -ef
[RO][SENS] ps -eo pid,ppid,user,stat,%cpu,%mem,etime,cmd
[RO][SENS] pstree -ap
[RO] pgrep -a "<NAME>"
[RO][PRIV][SENS] lsof -p <PID>

Prozesszustände

Zustand Grundbedeutung
R läuft oder ist ausführbar
S unterbrechbarer Schlafzustand
D nicht unterbrechbarer Schlafzustand, häufig im Zusammenhang mit I/O
T angehalten oder verfolgt
Z Zombieprozess

Ein Zombieprozess hat seine Ausführung beendet, wurde aber vom Elternprozess noch nicht vollständig abgeholt. Das Beenden des Zombies selbst löst die Ursache normalerweise nicht; der Elternprozess muss untersucht werden.

Signale kontrolliert verwenden

[CHANGE] kill -TERM <PID>
[CHANGE] kill -HUP <PID>
[CHANGE][DANGER] kill -KILL <PID>

kill -9 sollte nicht als Standardmaßnahme verwendet werden. Offene Transaktionen, temporäre Dateien oder gemeinsam genutzte Ressourcen können in einem problematischen Zustand verbleiben.

5. Systemd-Dienste prüfen 
[RO] systemctl status <DIENST>
[RO] systemctl is-active <DIENST>
[RO] systemctl is-enabled <DIENST>
[RO] systemctl is-failed <DIENST>
[RO] systemctl list-units --type=service --state=failed
[RO] systemctl list-dependencies <DIENST>
[RO] systemctl show <DIENST>
[RO] systemctl cat <DIENST>

Wichtige Unterscheidung

Zustand Aussage
active Unit ist entsprechend ihrem Typ aktiv
inactive Unit ist derzeit nicht aktiv
failed Start oder Ausführung ist fehlgeschlagen
enabled Unit soll über ihre Installationsverknüpfungen automatisch eingebunden werden
disabled entsprechende automatische Einbindung ist nicht aktiviert
masked Aktivierung und Start sind durch eine Verknüpfung auf /dev/null blockiert

active beweist nicht automatisch, dass die Anwendung fachlich funktioniert. Ein Webserver kann beispielsweise laufen, während eine abhängige Datenbank oder eine bestimmte Website nicht erreichbar ist.

Ändernde Aktionen

[CHANGE][PRIV] sudo systemctl start <DIENST>
[CHANGE][PRIV] sudo systemctl stop <DIENST>
[CHANGE][PRIV][RESTART] sudo systemctl restart <DIENST>
[CHANGE][PRIV] sudo systemctl reload <DIENST>
[CHANGE][PRIV] sudo systemctl reset-failed <DIENST>

reload funktioniert nur, wenn die Unit beziehungsweise das Programm dies unterstützt. reset-failed löscht den registrierten Fehlerzustand, behebt aber nicht dessen Ursache.

6. Änderungen an Systemd-Units richtig behandeln

Effektive Unit-Konfiguration anzeigen

[RO] systemctl cat <DIENST>

Abhängigkeiten untersuchen

[RO] systemctl list-dependencies <DIENST>
[RO] systemctl list-dependencies --reverse <DIENST>

Lokale Überschreibung bearbeiten

[CHANGE][PRIV] sudo systemctl edit <DIENST>

Unit-Dateien neu einlesen

[CHANGE][PRIV] sudo systemctl daemon-reload

daemon-reload liest Unit-Dateien und die systemd-Abhängigkeitsstruktur neu ein. Es startet den betroffenen Dienst nicht automatisch neu.

Vor einer Änderung müssen gesichert werden:

Paketverwaltete Unit-Dateien unter /usr/lib/systemd/system oder /lib/systemd/system sollten nicht direkt als dauerhafte Anpassungsmethode bearbeitet werden. Lokale Drop-ins verhindern, dass Paketaktualisierungen die Anpassung einfach überschreiben.

7. Journal mit Journalctl auswerten 
[RO][SENS] journalctl
[RO][SENS] journalctl -b
[RO][SENS] journalctl -b -1
[RO][SENS] journalctl -p warning
[RO][SENS] journalctl -u <DIENST>
[RO][SENS] journalctl -u <DIENST> -b
[RO][SENS] journalctl --since "2026-08-01 14:00:00"
[RO][SENS] journalctl --since "30 minutes ago"
[RO][SENS] journalctl -k
[RO][SENS] journalctl -f

Zusätzliche Filter

[RO][SENS] journalctl _PID=<PID>
[RO][SENS] journalctl _UID=<UID>
[RO][SENS] journalctl _COMM=<PROGRAMM>
[RO][SENS] journalctl -o verbose

Speicherbelegung des Journals

[RO] journalctl --disk-usage

Zu beachten sind:

journalctl -f zeigt neu eintreffende Einträge. Es ersetzt nicht die Untersuchung älterer Ereignisse vor dem sichtbaren Fehler.

8. Klassische Protokolldateien untersuchen

Abhängig von der Distribution und Konfiguration können relevante Dateien beispielsweise unter /var/log liegen.

[RO][PRIV][SENS] sudo ls -lah /var/log
[RO][PRIV][SENS] sudo tail -n 200 <LOGDATEI>
[RO][PRIV][SENS] sudo tail -f <LOGDATEI>
[RO][PRIV][SENS] sudo less <LOGDATEI>
[RO][PRIV][SENS] sudo grep -iE "error|fail|warning" <LOGDATEI>

Mögliche Protokolle sind unter anderem:

Diese Pfade sind nicht auf jeder Distribution vorhanden. Ein System kann Ereignisse ausschließlich oder zusätzlich im systemd-Journal speichern.

Rotierte Protokolle

[RO][PRIV][SENS] sudo zless <LOGDATEI>.gz
[RO][PRIV][SENS] sudo zgrep -i "<SUCHTEXT>" <LOGDATEI>.gz

Protokolldateien dürfen nicht gelöscht oder geleert werden, bevor Ursache, Aufbewahrungspflichten und Auswirkungen auf laufende Prozesse geklärt sind.

9. Kernelmeldungen und Hardwareereignisse prüfen 
[RO][PRIV][SENS] sudo dmesg
[RO][PRIV][SENS] sudo dmesg --ctime
[RO][PRIV][SENS] sudo dmesg --level=err,warn
[RO][PRIV][SENS] sudo journalctl -k -b
[RO][PRIV][SENS] sudo journalctl -k -b -1

Typische Suchbegriffe:

[RO][PRIV][SENS] sudo dmesg --ctime | grep -iE "error|fail|timeout|reset|oom|I/O"

Zu untersuchen sind beispielsweise:

Der Kernel-Ringpuffer ist begrenzt. Ältere Meldungen können überschrieben worden sein. Außerdem dürfen Zeitangaben aus dmesg nicht ungeprüft mit Zeitstempeln anderer Protokolle gleichgesetzt werden.

10. Arbeitsspeicher und OOM-Killer untersuchen 
[RO] free -h
[RO] cat /proc/meminfo
[RO][SENS] ps -eo pid,user,%mem,rss,vsz,cmd --sort=-rss
[RO] vmstat 1 10
[RO][PRIV][SENS] sudo journalctl -k | grep -iE "out of memory|oom|killed process"

Wichtige Bereiche:

Linux verwendet freien Arbeitsspeicher sinnvoll als Cache. Ein geringer Wert in der Spalte free bedeutet daher nicht automatisch Speichermangel. Für die erste Bewertung ist bei free insbesondere available relevant.

Swap-Nutzung anzeigen

[RO] swapon --show
[RO] cat /proc/swaps

Das Leeren von Caches oder Deaktivieren von Swap ist keine allgemeine Speicherreparatur und kann zusätzliche Last oder einen Systemausfall verursachen.

11. Datenträger, Partitionen und Einhängepunkte prüfen 
[RO][SENS] lsblk -f
[RO][SENS] findmnt
[RO] df -hT
[RO] df -i
[RO][PRIV][SENS] sudo fdisk -l
[RO][PRIV][SENS] sudo blkid

Warum df -h und df -i benötigt werden

Ein Dateisystem kann trotz freier Datenblöcke keine neuen Dateien mehr anlegen, wenn keine freien Inodes verfügbar sind.

Große Verzeichnisse ermitteln

[RO][PRIV][SENS] sudo du -xhd1 <VERZEICHNIS> | sort -h

Gelöschte, aber noch geöffnete Dateien suchen

[RO][PRIV][SENS] sudo lsof +L1

Wenn ein Prozess eine gelöschte Datei noch geöffnet hält, kann der belegte Speicherplatz bis zum Schließen des Dateideskriptors weiterhin belegt bleiben.

du und df messen unterschiedliche Sachverhalte. Abweichungen beweisen nicht automatisch einen Dateisystemfehler.

12. Datenträger-I/O und Gerätezustand analysieren

Falls die erforderlichen Werkzeuge installiert sind:

[RO] iostat -xz 1 10
[RO][PRIV] sudo smartctl -a /dev/<GERÄT>
[RO][PRIV] sudo nvme smart-log /dev/<NVME-GERÄT>

Zu prüfen sind:

SMART-Werte müssen geräte- und herstellerspezifisch interpretiert werden. Ein bestandener allgemeiner SMART-Status schließt einen Defekt nicht sicher aus.

Selbsttests, Reparaturbefehle und Schreibtests können Last erzeugen oder ein vorgeschädigtes Medium zusätzlich beanspruchen. Vorher müssen Sicherungsstand und Auswirkungen geklärt werden.

13. Dateisystemfehler sicher behandeln

Dateisystemtyp und Einhängezustand prüfen

[RO][SENS] findmnt
[RO][SENS] lsblk -f
[RO] mount
[RO][PRIV][SENS] sudo journalctl -k | grep -iE "filesystem|ext4|xfs|btrfs|I/O error"

Eine Dateisystemprüfung muss zum tatsächlichen Dateisystem passen. Werkzeuge für ext-Dateisysteme, XFS und Btrfs sind nicht beliebig austauschbar.

[TEST][PRIV][DANGER] sudo fsck <BLOCKGERÄT>

fsck darf nicht unüberlegt auf einem schreibend eingehängten Dateisystem ausgeführt werden. Vor einer Reparatur müssen Dateisystemtyp, Geräteziel, Einhängezustand, Sicherung und Wiederherstellungsplan eindeutig geklärt sein.

Bei Root-Dateisystemen kann eine Prüfung im Rettungsmodus, über ein Wartungssystem oder beim Start erforderlich sein.

14. Netzwerkadapter und Adressen untersuchen 
[RO][SENS] ip -br link
[RO][SENS] ip -br address
[RO][SENS] ip address show
[RO][SENS] ip -s link
[RO][SENS] ip route show
[RO][SENS] ip rule show
[RO][SENS] ip neigh show

Zu prüfen sind:

Die früher verbreiteten Werkzeuge ifconfig, route und netstat werden auf vielen modernen Linux-Systemen durch Werkzeuge aus iproute2, insbesondere ip und ss, ersetzt.

15. Erreichbarkeit und Pfad testen 
[TEST][REMOTE] ping -c 4 <IP-ODER-HOSTNAME>
[TEST][REMOTE] ping -6 -c 4 <IPv6-ODER-HOSTNAME>
[TEST][REMOTE][SENS] tracepath <ZIEL>
[TEST][REMOTE][SENS] traceroute <ZIEL>
[TEST][REMOTE][SENS] mtr <ZIEL>

Ein erfolgreicher Ping beweist nur, dass die verwendete ICMP-Kommunikation in dieser Richtung und zu diesem Zeitpunkt funktioniert hat. Er beweist nicht, dass:

Ein fehlgeschlagener Ping beweist umgekehrt keinen vollständigen Ausfall, da ICMP gefiltert oder begrenzt werden kann.

16. DNS-Auflösung untersuchen 
[RO][SENS] cat /etc/resolv.conf
[RO][SENS] getent hosts <HOSTNAME>
[TEST][REMOTE][SENS] dig <HOSTNAME>
[TEST][REMOTE][SENS] dig <HOSTNAME> A
[TEST][REMOTE][SENS] dig <HOSTNAME> AAAA
[TEST][REMOTE][SENS] dig -x <IP-ADRESSE>
[TEST][REMOTE][SENS] dig @<DNS-SERVER> <HOSTNAME>
[TEST][REMOTE][SENS] resolvectl query <HOSTNAME>
[RO][SENS] resolvectl status

getent hosts berücksichtigt die konfigurierte Namensdienstauflösung des Systems und kann daher für die tatsächliche Anwendungssicht aussagekräftiger sein als eine isolierte DNS-Abfrage.

Zu prüfen sind:

/etc/resolv.conf kann eine automatisch erzeugte Datei oder ein symbolischer Link sein. Manuelle Änderungen können überschrieben werden und sind nicht zwingend die richtige dauerhafte Konfigurationsmethode.

17. Ports, Sockets und Verbindungen prüfen 
[RO][PRIV][SENS] sudo ss -lntup
[RO][SENS] ss -tan
[RO][SENS] ss -s
[RO][PRIV][SENS] sudo lsof -i
[TEST][REMOTE] nc -vz <HOST> <PORT>
[TEST][REMOTE][SENS] curl -v <URL>

Zu prüfen sind:

Ein offener TCP-Port beweist nur, dass eine Verbindung angenommen werden kann. Die fachliche Funktion der Anwendung muss separat getestet werden.

18. Netzwerkverkehr mit Tcpdump erfassen 
[TEST][PRIV][REMOTE][LOG][SENS] sudo tcpdump -i <INTERFACE>
[TEST][PRIV][REMOTE][LOG][SENS] sudo tcpdump -i <INTERFACE> host <IP-ADRESSE>
[TEST][PRIV][REMOTE][LOG][SENS] sudo tcpdump -i <INTERFACE> port <PORT>
[TEST][PRIV][REMOTE][LOG][SENS] sudo tcpdump -i <INTERFACE> -nn -s 0 -w <DATEI>.pcap

Vor einer Aufzeichnung müssen festgelegt werden:

Eine Paketaufzeichnung kann enthalten:

Ohne Begrenzung kann eine Aufzeichnung sehr groß werden. Bei produktiven Systemen sollten rotierende Dateien, zeitliche Begrenzung und möglichst enge Capture-Filter verwendet werden.

19. Firewall und Paketfilter prüfen

Je nach System können unterschiedliche Frameworks oder Verwaltungswerkzeuge eingesetzt werden.

[RO][PRIV][SENS] sudo nft list ruleset
[RO][PRIV][SENS] sudo iptables -S
[RO][PRIV][SENS] sudo iptables -t nat -S
[RO][PRIV][SENS] sudo firewall-cmd --list-all
[RO][PRIV][SENS] sudo ufw status verbose

Zu prüfen sind:

Mehrere Werkzeuge können auf dasselbe oder auf unterschiedliche Backends zugreifen. Eine leere iptables-Ausgabe beweist daher nicht automatisch, dass keine Filterregeln aktiv sind.

20. NetworkManager untersuchen 
[RO][SENS] nmcli general status
[RO][SENS] nmcli device status
[RO][SENS] nmcli connection show
[RO][SENS] nmcli device show <INTERFACE>
[RO][SENS] nmcli connection show "<VERBINDUNG>"
[RO][PRIV][SENS] journalctl -u NetworkManager -b

Zu prüfen sind:

Änderungen mit nmcli können eine SSH-Verbindung sofort unterbrechen. Vor Remoteänderungen sind Konsolenzugang und Rückfallplan erforderlich.

21. Benutzer, Gruppen und Berechtigungen prüfen 
[RO][SENS] id <BENUTZER>
[RO][SENS] groups <BENUTZER>
[RO][SENS] getent passwd <BENUTZER>
[RO][SENS] getent group <GRUPPE>
[RO][SENS] namei -l <PFAD>
[RO][SENS] stat <PFAD>
[RO][SENS] ls -ld <PFAD>
[RO][SENS] getfacl <PFAD>

Bei einem Pfadproblem müssen alle übergeordneten Verzeichnisse berücksichtigt werden. Für das Durchlaufen eines Verzeichnisses ist das Ausführungsrecht am Verzeichnis entscheidend.

Zu unterscheiden sind:

chmod 777 ist keine fachgerechte Standardlösung. Es kann Daten ungewollt für alle lokalen Benutzer veränderbar machen und verdeckt die eigentliche Ursache.

22. SELinux und AppArmor berücksichtigen

SELinux

[RO] getenforce
[RO] sestatus
[RO][PRIV][SENS] sudo ausearch -m AVC,USER_AVC -ts recent
[RO][PRIV][SENS] sudo journalctl | grep -i "avc:"

AppArmor

[RO] aa-status
[RO][PRIV][SENS] sudo journalctl -k | grep -i apparmor

Ein Unix-Dateirecht kann korrekt erscheinen, während eine Mandatory-Access-Control-Richtlinie den Zugriff trotzdem verhindert.

SELinux dauerhaft zu deaktivieren oder ein AppArmor-Profil ungeprüft abzuschalten ist keine geeignete Ursachenanalyse. Zuerst müssen die konkrete Ablehnung, der betroffene Kontext und die erwartete Richtlinie festgestellt werden.

23. Geöffnete Dateien und Systemaufrufe untersuchen 
[RO][PRIV][SENS] sudo lsof -p <PID>
[RO][PRIV][SENS] sudo lsof <PFAD>
[RO][PRIV][SENS] sudo lsof -i :<PORT>
[TEST][PRIV][LOG][SENS] sudo strace -p <PID>
[TEST][PRIV][LOG][SENS] sudo strace -f -o <DATEI> <BEFEHL>

strace kann sichtbar machen, ob ein Prozess beispielsweise an folgenden Vorgängen scheitert:

Die Ausgabe kann sehr umfangreich sein und sensible Daten enthalten. Außerdem kann Tracing das Zeitverhalten eines Prozesses beeinflussen.

Ein produktiver Prozess sollte nur mit geklärter Auswirkung verfolgt werden. Geheimnisse, Pfade und Nutzdaten können in der Ausgabe erscheinen.

24. Paketbestand und beschädigte Installationen prüfen

Debian- und Ubuntu-basierte Systeme

[RO][SENS] dpkg -l
[RO] dpkg -S <PFAD>
[RO] apt-cache policy <PAKET>
[RO][PRIV] sudo dpkg --verify

RPM-basierte Systeme

[RO][SENS] rpm -qa
[RO] rpm -qf <PFAD>
[RO] rpm -V <PAKET>
[RO] dnf info <PAKET>

Zu prüfen sind:

Eine Paketverifikation zeigt Abweichungen, bewertet aber nicht automatisch, ob diese absichtlich, harmlos oder fehlerursächlich sind.

25. Bootvorgang untersuchen 
[RO] systemd-analyze
[RO] systemd-analyze blame
[RO] systemd-analyze critical-chain
[RO][SENS] journalctl -b
[RO][SENS] journalctl -b -1
[RO] systemctl --failed
[RO][PRIV][SENS] sudo dmesg --ctime

Bei Startproblemen sind zu prüfen:

systemd-analyze blame zeigt die Initialisierungszeit einzelner Units, beweist aber nicht allein, dass die oben angezeigte Unit den gesamten Start entsprechend verzögert hat. Parallelisierung und Abhängigkeiten müssen berücksichtigt werden.

26. Zeit und Zeitsynchronisation prüfen 
[RO] date
[RO] timedatectl
[RO] timedatectl timesync-status
[RO][SENS] chronyc tracking
[RO][SENS] chronyc sources -v

Die verfügbaren Befehle hängen vom eingesetzten Zeitdienst ab.

Zu prüfen sind:

Eine falsche Systemzeit kann Protokollkorrelation, TLS, Authentifizierung, Datenbanken und geplante Aufgaben beeinträchtigen.

27. Geplante Aufgaben untersuchen 
[RO][SENS] crontab -l
[RO][PRIV][SENS] sudo crontab -l
[RO][PRIV][SENS] sudo ls -la /etc/cron.*
[RO] systemctl list-timers --all
[RO] systemctl status <TIMER>.timer
[RO][SENS] journalctl -u <TIMER>.timer
[RO][SENS] journalctl -u <DIENST>.service

Typische Fehlerursachen:

Ein Skript, das in einer interaktiven Shell funktioniert, muss unter Cron oder einem systemd-Timer nicht mit derselben Umgebung ausgeführt werden.

28. Container und Virtualisierung berücksichtigen 
[RO] systemd-detect-virt
[RO][SENS] cat /proc/1/cgroup
[RO][SENS] lsns
[RO][SENS] docker ps
[RO][SENS] podman ps
[RO][SENS] docker inspect <CONTAINER>
[RO][SENS] docker logs <CONTAINER>

Bei Containerproblemen müssen Host und Container getrennt untersucht werden:

Ein laufender Container beweist nicht, dass der darin betriebene Dienst erreichbar oder funktionsfähig ist. Ein Container verwendet grundsätzlich den Kernel des Hosts und ist keine vollständige virtuelle Maschine.

29. Bash-Skripte kontrolliert debuggen

Syntax prüfen

[RO] bash -n <SKRIPT>

Ablauf mit Trace ausführen

[TEST][LOG][SENS] bash -x <SKRIPT>

In einem Skript kann die Trace-Ausgabe abschnittsweise aktiviert werden:

set -x
<ZU_UNTERSUCHENDE_BEFEHLE>
set +x

Zu prüfen sind:

set -x kann Kennwörter, Tokens, Argumente und andere Geheimnisse in Protokolle schreiben. Es darf nicht unkontrolliert in produktiven Skripten aktiviert werden.

30. Typische Fehlerbilder und geeignete Werkzeuge
Fehlerbild Geeignete Prüfungen
Dienst startet nicht systemctl status, journalctl -u, Unit-Konfiguration, Abhängigkeiten, Rechte
Server reagiert langsam uptime, top, vmstat, iostat, free, Prozess- und I/O-Analyse
Datenträger voll df -hT, df -i, du, lsof +L1, Journalgröße
Prozess wird beendet Kerneljournal, OOM-Meldungen, cgroup-Grenzen, Dienstkonfiguration
Port nicht erreichbar ss, Dienst-Bindung, Firewall, Route, nc, tcpdump
Hostname wird falsch aufgelöst getent, dig, resolvectl, nsswitch.conf, Hosts-Datei
Netzwerk fällt sporadisch aus Linkstatistik, NetworkManager-Journal, Route, mtr, tcpdump
Datei kann nicht geöffnet werden namei, stat, getfacl, SELinux/AppArmor, lsof, strace
System bootet langsam systemd-analyze, vorheriges Journal, Mounts, Abhängigkeiten
Root-Dateisystem nur lesbar Kernelmeldungen, I/O-Fehler, Dateisystemzustand, Storage
Cronjob läuft nicht Benutzerkontext, Umgebung, absolute Pfade, Cronlogs, Exit-Code
Container startet ständig neu Containerstatus, Exit-Code, Logs, Healthcheck, Volumes, Ressourcen
Anwendung funktioniert lokal, aber nicht remote Bind-Adresse, Firewall, Routing, NAT, DNS, TLS
Zeitstempel sind unplausibel timedatectl, Zeitdienst, Zeitzone, VM-Zeitquelle
Änderungen verschwinden nach Neustart persistente Konfiguration, generierte Dateien, NetworkManager, systemd-Drop-ins
31. Empfohlener Gesamtablauf bei Linux-Problemen
  1. vollständige Fehlermeldung erfassen.
  2. Benutzer, Host, Dienst und Zeitpunkt dokumentieren.
  3. Umfang und Reproduzierbarkeit bestimmen.
  4. letzte Änderung feststellen.
  5. Distribution, Version, Kernel und Laufzeitumgebung erfassen.
  6. Systemzeit und Uptime prüfen.
  7. CPU, Load, Arbeitsspeicher und I/O überblicken.
  8. Speicherplatz und Inodes prüfen.
  9. betroffenen Prozess oder Dienst bestimmen.
  10. Dienststatus und Abhängigkeiten prüfen.
  11. Journal im passenden Zeitfenster auswerten.
  12. Kernelmeldungen kontrollieren.
  13. Konfiguration und Berechtigungen prüfen.
  14. SELinux oder AppArmor berücksichtigen.
  15. bei Netzwerkproblemen Adapter, Adressen und Routen prüfen.
  16. DNS-Auflösung über den tatsächlich verwendeten Resolver testen.
  17. Ports und Bind-Adressen prüfen.
  18. Firewall und Paketpfad untersuchen.
  19. bei Bedarf eng gefilterte Paketaufzeichnung erstellen.
  20. Hypothese aus mehreren Befunden formulieren.
  21. kleinste reversible Maßnahme planen.
  22. Sicherung und Rückfallplan prüfen.
  23. Änderung kontrolliert durchführen.
  24. denselben Fehlerfall erneut testen.
  25. Dienste, Logs und Monitoring nachkontrollieren.
  26. temporäres Debugging deaktivieren.
  27. Ursache, Maßnahme und Ergebnis dokumentieren.
32. Gefährliche Fehlinterpretationen vermeiden
Beobachtung Nicht automatisch bewiesen
Prozess erscheint in ps Anwendung funktioniert
Dienst ist active Dienst ist fachlich erreichbar
Port steht auf LISTEN Remotezugriff funktioniert
Ping funktioniert TCP, UDP, DNS und Anwendung funktionieren
DNS liefert eine Adresse Adresse ist aktuell und der Dienst erreichbar
free zeigt wenig freien RAM akuter Speichermangel
Load Average ist hoch ausschließlich CPU-Überlastung
df zeigt freien Platz genügend freie Inodes vorhanden
du ist kleiner als df Dateisystem ist beschädigt
SMART meldet PASSED Datenträger ist fehlerfrei
Firewallregel existiert sie trifft in der gewünschten Richtung zu
Dateirechte sind korrekt SELinux, AppArmor oder ACLs erlauben den Zugriff
Neustart behebt das Symptom Ursache ist behoben
Paketdatei wurde verändert Veränderung verursacht den Fehler
Container läuft Anwendung im Container ist gesund
keine Fehlermeldung sichtbar Vorgang war erfolgreich
33. Sicherheits- und Datenschutzanforderungen

Linux-Diagnosedaten können enthalten:

Vor einer Weitergabe müssen:

  1. Zweck und Empfänger bestimmt werden.
  2. nur erforderliche Daten erfasst werden.
  3. Kennwörter, Schlüssel, Cookies und Tokens entfernt werden.
  4. personenbezogene Angaben redigiert werden.
  5. Paketmitschnitte besonders geschützt werden.
  6. Dateien verschlüsselt übertragen werden.
  7. Zugriffsrechte und Aufbewahrungsdauer festgelegt werden.
  8. temporäres Debugging deaktiviert werden.
  9. nicht mehr benötigte Diagnosedaten sicher gelöscht werden.
  10. externe Analysedienste organisatorisch freigegeben sein.

Shell-History, Prozesslisten und Trace-Ausgaben können Geheimnisse enthalten, wenn diese als Befehlsargumente übergeben wurden.

34. Dokumentationsvorlage 
Ticket:
Datum und Uhrzeit:
Bearbeiter:

Hostname:
Distribution:
Version:
Kernel:
Architektur:
Physisch, VM oder Container:
Zeitzone:
Uptime:

Betroffener Benutzer:
Betroffener Dienst:
Betroffener Prozess:
PID:
Originale Fehlermeldung:
Fehlerzeitpunkt:
Reproduzierbar:
Betroffene Systeme:
Letzte funktionierende Nutzung:
Letzte Änderung:

CPU-Auslastung:
Load Average:
Arbeitsspeicher:
Swap:
OOM-Ereignis:
Datenträgerauslastung:
Freier Speicher:
Freie Inodes:
I/O-Wartezeit:
Dateisystem:
Mount-Optionen:
Kernelmeldungen:

Dienststatus:
Unit-Datei:
Drop-ins:
Abhängigkeiten:
Startbenutzer:
Exit-Code:
Journal-Zeitraum:
Erste relevante Fehlermeldung:

Interface:
IP-Adresse:
Präfix:
Gateway:
Route:
DNS-Server:
DNS-Ergebnis:
Lauschadresse:
Port:
Firewall:
Paketaufzeichnung:

Dateipfad:
Eigentümer:
Gruppe:
Modus:
ACL:
SELinux:
AppArmor:
Geöffnete Dateien:
Strace verwendet:

Paket:
Installierte Version:
Paketquelle:
Verifikation:
Letztes Update:

Vermutete Ursache:
Belege:
Geplante Maßnahme:
Sicherung:
Rückfallplan:
Durchgeführte Änderung:
Testergebnis:
Monitoring:
Abschluss:

Merksatz

Bei der Linux-Fehleranalyse wird zuerst der Zustand gesichert und anschließend die Abhängigkeitskette geprüft: Hardware und Kernel stellen die Grundlage bereit, Dateisystem und Netzwerk ermöglichen den Zugriff, Benutzerrechte und Sicherheitsrichtlinien kontrollieren die Berechtigung, Dienste stellen die Funktion bereit und Protokolle verbinden Fehler, Zeitpunkt und Ursache.

Quellen und weiterführende Dokumentation

5. Werkzeuge der Fehleranalyse

5.5 macOS – Werkzeuge zur Fehleranalyse

Kurz erklärt

macOS stellt grafische Diagnoseprogramme und zahlreiche Unix-Werkzeuge im Terminal bereit. Damit lassen sich unter anderem folgende Bereiche untersuchen:

Viele Terminalbefehle ähneln Linux-Befehlen. macOS verwendet jedoch eigene Komponenten und Verwaltungsmechanismen, beispielsweise:

Ein Symptom ist noch keine Ursache. Auch unter macOS müssen zuerst Zustand, Zeitpunkt, Umfang und betroffene Komponente bestimmt werden, bevor Einstellungen verändert, Dateien gelöscht oder Dienste neu gestartet werden.

1. Sichere Arbeitsweise

Vor einer Veränderung sollten möglichst viele Informationen im fehlerhaften Zustand gesichert werden.

Empfohlene Reihenfolge

  1. Störung und erwartetes Verhalten beschreiben.
  2. Zeitpunkt und letzte Änderungen feststellen.
  3. betroffene Benutzer, Geräte und Anwendungen bestimmen.
  4. Systemversion und Hardwaremodell erfassen.
  5. Prozess-, Ressourcen- und Netzwerkzustand dokumentieren.
  6. relevante Protokolle sichern.
  7. eine prüfbare Hypothese formulieren.
  8. eine möglichst kleine und reversible Prüfung durchführen.
  9. Ergebnis und Nebenwirkungen dokumentieren.
  10. erst danach eine dauerhafte Lösung umsetzen.

Vor Veränderungen prüfen

Wichtige Schutzmechanismen

Mechanismus Bedeutung für die Fehleranalyse
Benutzerrechte Viele Informationen sind nur für den aktuellen Benutzer sichtbar.
sudo Führt einen Befehl mit erhöhten Rechten aus, hebt aber nicht automatisch alle macOS-Schutzmechanismen auf.
TCC Kontrolliert unter anderem den Zugriff auf Dateien, Kamera, Mikrofon, Bildschirmaufnahme und Bedienungshilfen.
Festplattenvollzugriff Kann für Terminal oder Diagnoseprogramme erforderlich sein, um geschützte Daten einzusehen.
SIP Schützt kritische Systembereiche und Systemprozesse vor Veränderungen.
Gatekeeper Bewertet heruntergeladene Programme und deren Signatur beziehungsweise Beglaubigung.
FileVault verschlüsselt das Startvolume und beeinflusst Zugriff und Wiederherstellung.
MDM Kann Einstellungen, Profile, Erweiterungen und Sicherheitsrichtlinien zentral vorgeben.

sudo und Festplattenvollzugriff sind nicht dasselbe. Ein als Administrator ausgeführter Prozess kann weiterhin durch TCC oder SIP eingeschränkt werden.

2. Schnelle Systemübersicht

Vor einer tieferen Analyse sollten Betriebssystem, Hardware, Laufzeit und Zeitpunkt erfasst werden.

macOS-Version anzeigen

sw_vers

Typische Ausgabe:

ProductName:            macOS
ProductVersion:         14.7.4
BuildVersion:           23H420

Nur die Versionsnummer:

sw_vers -productVersion

Nur die Buildnummer:

sw_vers -buildVersion

Kernel und Architektur anzeigen

uname -a

uname -m

Typische Architekturen:

Ausgabe Bedeutung
arm64 Prozess läuft nativ auf einem Mac mit Apple-Chip
x86_64 Intel-Prozess oder unter bestimmten Bedingungen ein durch Rosetta übersetzter Prozess

Hardware- und Systembericht

system_profiler SPHardwareDataType SPSoftwareDataType

Kompaktere Darstellung:

system_profiler SPHardwareDataType SPSoftwareDataType -detailLevel mini

Alle verfügbaren Datentypen anzeigen:

system_profiler -listDataTypes

Bestimmte Bereiche gezielt untersuchen:

system_profiler SPNetworkDataType

system_profiler SPUSBDataType

system_profiler SPThunderboltDataType

system_profiler SPBluetoothDataType

system_profiler SPStorageDataType

system_profiler SPPowerDataType

system_profiler SPDisplaysDataType

Ein vollständiger Aufruf von system_profiler kann umfangreich sein und längere Zeit benötigen. Für eine gezielte Fehleranalyse sollten nur die relevanten Datentypen abgefragt werden.

Laufzeit und Last

uptime

Aktuelles Datum und Zeitzone

date

systemsetup -gettimezone

systemsetup benötigt für viele Abfragen Administratorrechte:

sudo systemsetup -gettimezone

Computername und Hostnamen

scutil --get ComputerName

scutil --get LocalHostName

scutil --get HostName

Wenn kein expliziter HostName gesetzt wurde, kann der letzte Befehl eine Fehlermeldung ausgeben. Das beweist allein keine Störung.

3. „Über diesen Mac“ und Systeminformationen

Die grafische App Systeminformationen zeigt Hardware-, Netzwerk- und Softwareinformationen an.

Öffnen

open -a "System Information"

Geeignete Diagnosebereiche

Typische Fragestellungen

Wenn ein Gerät in den Systeminformationen erscheint, ist zunächst nur seine Erkennung bestätigt. Daraus folgt noch nicht, dass Treiber, Berechtigungen, Anwendung und vollständige Funktion korrekt sind.

4. Aktivitätsanzeige

Die Aktivitätsanzeige ist das zentrale grafische Werkzeug zur Untersuchung laufender Prozesse und der Ressourcennutzung.

Öffnen

open -a "Activity Monitor"

Je nach Spracheinstellung wird die App als Aktivitätsanzeige dargestellt.

Wichtige Bereiche

Bereich wichtige Informationen
CPU CPU-Anteil, CPU-Zeit, Threads, nicht reagierende Prozesse
Speicher Speicherverbrauch, Speicherdruck, komprimierter Speicher, Swap
Energie Energiebedarf einzelner Anwendungen
Festplatte gelesene und geschriebene Daten
Netzwerk empfangene und gesendete Daten und Pakete

Darstellung richtig auswählen

Über Darstellung kann festgelegt werden, welche Prozesse angezeigt werden:

Ein Prozess kann ansonsten übersehen werden, obwohl er weiterhin ausgeführt wird.

Speicherdruck interpretieren

Zustand Einordnung
Grün Speicher kann derzeit effizient bereitgestellt werden.
Gelb Speicherressourcen stehen unter zunehmendem Druck.
Rot Der verfügbare Speicher reicht für die aktuelle Last nicht angemessen aus.

Nicht allein der Wert „freier Speicher“ ist entscheidend. macOS verwendet freien Arbeitsspeicher bewusst als Cache. Aussagekräftiger sind:

Prozess beenden

Die Aktivitätsanzeige bietet:

Vor dem Beenden prüfen:

Ein Prozess mit hoher CPU-Auslastung ist nicht automatisch fehlerhaft. Entscheidend sind Arbeitslast, Dauer, Benutzerwirkung und erwartetes Verhalten.

5. Prozesse im Terminal untersuchen

Prozessliste

ps aux

Nach einem Prozess suchen:

ps aux | grep -i "prozessname"

Damit der Suchbefehl selbst nicht als Treffer erscheint:

pgrep -afil "prozessname"

Prozesse hierarchisch anzeigen

ps -axo pid,ppid,user,%cpu,%mem,state,start,time,command

Momentaufnahme der Ressourcennutzung

top -l 1

Nach CPU-Auslastung sortieren:

top -l 1 -o cpu

Nach Speicherverbrauch sortieren:

top -l 1 -o mem

Nur einen bestimmten Prozess beobachten:

top -pid 1234

1234 muss durch die tatsächliche Prozess-ID ersetzt werden.

Signal zum geordneten Beenden senden

kill 1234

Erzwungenes Beenden

kill -9 1234

SIGKILL sollte nur verwendet werden, wenn ein geordneter Abbruch nicht funktioniert. Der Prozess kann dann keine Aufräumarbeiten mehr ausführen oder Daten geordnet speichern.

Prozess untersuchen

sample 1234 10

Der Befehl erstellt für zehn Sekunden Stichproben der ausgeführten Funktionen. Das kann bei hoher CPU-Auslastung oder blockierten Prozessen helfen.

Geöffnete Dateien und Verbindungen

lsof -p 1234

Alle offenen Dateien mit einem bestimmten Pfad suchen:

lsof "/Pfad/zur/Datei"

Prozess ermitteln, der einen TCP-Port verwendet:

lsof -nP -iTCP:8080

Nur TCP-Listener anzeigen:

lsof -nP -iTCP -sTCP:LISTEN

Bewertung

Beobachtung mögliche Hypothese
dauerhaft hohe CPU-Last Endlosschleife, rechenintensive Aufgabe, fehlerhafte Erweiterung
steigender Speicherverbrauch Speicherleck, ungewöhnliche Datenmenge, Cache-Verhalten
Prozess reagiert nicht blockierte Ein-/Ausgabe, Deadlock, abhängiger Dienst
Prozess startet nach Beenden erneut Verwaltung durch launchd, Login-Objekt oder MDM
Port ist bereits belegt konkurrierender Dienst oder zweite Programminstanz
Datei bleibt geöffnet Prozess verhindert Aushängen, Verschieben oder Löschen

Diese Beobachtungen sind Hinweise, aber noch keine bestätigten Ursachen.

6. Arbeitsspeicher untersuchen

Speicherstatistik

vm_stat

Die Werte werden überwiegend in Speicherseiten ausgegeben. Die Seitengröße steht in der ersten Ausgabezeile und darf nicht pauschal als immer identisch angenommen werden.

Speicherdruck prüfen

memory_pressure

Swap-Nutzung

sysctl vm.swapusage

Wichtige Zusammenhänge

Geeignete Beweiskette

  1. Zeitpunkt der Verlangsamung bestimmen.
  2. Speicherdruck in der Aktivitätsanzeige prüfen.
  3. Swap- und Komprimierungswerte erfassen.
  4. Prozesse nach Speicherverbrauch sortieren.
  5. Entwicklung über einen längeren Zeitraum beobachten.
  6. Anwendungs- und Systemprotokolle zum gleichen Zeitpunkt auswerten.

7. CPU- und Systemlast untersuchen

CPU-Übersicht

top -l 1 -o cpu

Lastmittelwerte

uptime

Die drei Load-Average-Werte beziehen sich auf unterschiedliche Zeiträume. Sie dürfen nicht direkt wie Prozentwerte interpretiert werden.

Prozessbezogene Stichprobe

sample 1234 10

Systemweite Diagnose bei Hängern

sudo spindump

spindump sammelt umfangreiche Informationen über Prozesszustände und Aufrufstapel. Die Erfassung kann kurzfristig zusätzliche Last erzeugen und sensible Informationen enthalten.

Mögliche Ursachen hoher CPU-Auslastung

Erst prüfen, welche Arbeit der Prozess ausführt und ob die Last nach Abschluss der Aufgabe wieder sinkt.

8. Datenträger, APFS und Speicherplatz

Dateisystembelegung

df -h

Nur das Startvolume:

df -h /

Verzeichnisgrößen

du -sh ~/Downloads

Unterverzeichnisse vergleichen:

du -sh ~/Library/* 2>/dev/null

Fehlende Berechtigungen oder TCC-Schutz können dazu führen, dass nicht alle Verzeichnisse gelesen werden.

Datenträgerstruktur

diskutil list

Informationen zum Startvolume

diskutil info /

APFS-Struktur

diskutil apfs list

Volume schreibgeschützt prüfen

diskutil verifyVolume /

Das Prüfen kann Zeit und Ein-/Ausgabeleistung beanspruchen. Für produktive Systeme sollte die Auswirkung vorher bewertet werden.

Festplattendienstprogramm öffnen

open -a "Disk Utility"

In der App sollte für eine vollständige Darstellung gewählt werden:

Darstellung → Alle Geräte einblenden

Dadurch werden die Ebenen sichtbar:

  1. physisches Speichergerät,
  2. Partition beziehungsweise APFS-Container,
  3. APFS-Volume,
  4. gegebenenfalls APFS-Volumegruppe.

Erste Hilfe

Apple empfiehlt, bei einer Prüfung mit dem letzten Volume eines Speichergeräts zu beginnen und anschließend nacheinander weitere Volumes, Container und zuletzt das physische Speichergerät zu prüfen.

Wichtige Grenzen

Datenträgeraktivität beobachten

iostat -w 1

Abbruch mit:

Control + C

Dateisystemzugriffe live beobachten

sudo fs_usage

Nach einem Prozess filtern:

sudo fs_usage -w -f filesystem | grep -i "prozessname"

fs_usage kann sehr viele Daten erzeugen und zusätzliche Last verursachen.

Typische Fehlerbilder

Symptom zu prüfen
Startvolume fast voll df, große Benutzerdateien, lokale Snapshots, Caches, Protokolle
Volume wird nicht aktiviert diskutil list, diskutil info, Dateisystemzustand
externes Laufwerk fehlt Systeminformationen, Kabel, Stromversorgung, USB-/Thunderbolt-Erkennung
langsame Dateizugriffe iostat, fs_usage, Synchronisation, Verschlüsselung, Datenträgerzustand
Dateien können nicht gelöscht werden Berechtigungen, Flags, erweiterte Attribute, geöffnete Dateien
Volume ist schreibgeschützt Dateisystemfehler, Bereitstellungsoptionen, Medium, Berechtigungen

9. Dateien, Berechtigungen und Attribute

macOS verwendet neben klassischen Unix-Rechten weitere Eigenschaften:

Datei ausführlich anzeigen

ls -leO@ "/Pfad/zur/Datei"

Bedeutung:

Option Anzeige
-l ausführliche Dateiinformationen
-e Access Control Lists
-O Dateiflags
-@ erweiterte Attribute

Dateimetadaten

stat "/Pfad/zur/Datei"

Erweiterte Attribute

xattr -l "/Pfad/zur/Datei"

Rekursiv anzeigen:

xattr -lr "/Pfad/zum/Ordner"

Besitz und Rechte

ls -ld "/Pfad/zum/Ordner"

Geöffnete Datei ermitteln

lsof "/Pfad/zur/Datei"

Typische Ursachen für „Operation not permitted“

Eine Berechtigungsfehlermeldung sollte nicht sofort mit chmod 777, rekursivem chown oder dem Entfernen aller Attribute beantwortet werden. Zuerst muss geklärt werden, welcher Schutzmechanismus den Zugriff verhindert.

10. Unified Logging und die App „Konsole“

macOS verwendet ein zentrales Protokollsystem, das strukturierte Meldungen, Aktivitäten und Signposts verarbeiten kann.

Konsole öffnen

open -a Console

Die App kann unter anderem anzeigen:

Wichtige Filterkriterien

Aktuelle Protokolle anzeigen

log show --last 1h --style compact

Nur Meldungen eines Prozesses:

log show --last 1h --style compact --predicate 'process == "Safari"'

Nach einem Textbestandteil suchen:

log show --last 1h --style compact --predicate 'eventMessage CONTAINS[c] "error"'

Live-Meldungen verfolgen:

log stream --style compact

Live nach Prozess filtern:

log stream --style compact --predicate 'process == "Safari"'

Nach Subsystem filtern:

log show --last 1h --style compact --predicate 'subsystem == "com.apple.network"'

Ob ein bestimmtes Subsystem tatsächlich verwendet wird, muss anhand vorhandener Ereignisse geprüft werden.

Zeitfenster gezielt festlegen

log show --start "2026-08-01 14:00:00" --end "2026-08-01 14:30:00" --style compact

Logarchiv sammeln

sudo log collect --last 1h --output ~/Desktop/SystemLogs.logarchive

Vor dem Weitergeben eines Logarchivs prüfen, ob es enthält:

Fehlinterpretationen vermeiden

Beobachtung korrekte Einordnung
Meldung enthält „error“ Kann relevant sein, beweist aber nicht automatisch die Ursache.
keine sichtbare Fehlermeldung Protokollierung kann eingeschränkt, verzögert, privat oder in einem anderen Subsystem erfolgt sein.
viele Meldungen eines Prozesses Hohe Meldungszahl ist nicht automatisch ein Fehler.
Meldung liegt zeitlich nach dem Symptom Sie kann Folge statt Ursache sein.
wiederkehrende Warnung Bedeutung muss mit Funktion, Zeitpunkt und Auswirkung abgeglichen werden.

Protokolle sollten nicht ausschließlich nach den Wörtern „error“ oder „failed“ durchsucht werden. Entscheidend sind zeitlicher Zusammenhang, betroffene Komponente und technische Bedeutung.

11. Absturz- und Diagnoseberichte

Typische benutzerbezogene Diagnoseberichte befinden sich unter:

~/Library/Logs/DiagnosticReports/

Systemweite Berichte können sich unter folgendem Pfad befinden:

/Library/Logs/DiagnosticReports/

Inhalte anzeigen:

ls -lt ~/Library/Logs/DiagnosticReports/

Nach einem Programmnamen suchen:

find ~/Library/Logs/DiagnosticReports -type f -iname "*Programmname*"

Typische Berichtstypen

Bericht mögliche Bedeutung
Crash Report Prozess wurde durch einen Fehler oder ein Signal beendet
Hang Report Anwendung reagierte über einen bestimmten Zeitraum nicht
Spin Report Prozess war aktiv, konnte aber nicht angemessen fortfahren
Panic Report schwerwiegender Kernel- oder Hardwarekontext
Jetsam-/Ressourcenbericht Prozessbeendigung oder Einschränkung aufgrund von Ressourcenbedingungen

Bei der Auswertung prüfen

Ein Funktionsname im abstürzenden Thread beweist nicht automatisch, dass genau diese Komponente die eigentliche Ursache ist.

12. Netzwerkadapter und Netzwerkkonfiguration

Alle Schnittstellen

ifconfig

Nur aktive Schnittstellen:

ifconfig -u

Hardwareports und BSD-Gerätenamen zuordnen

networksetup -listallhardwareports

Beispiel:

Hardware Port: Wi-Fi
Device: en0
Ethernet Address: aa:bb:cc:dd:ee:ff

Der Gerätename darf nicht pauschal als en0 angenommen werden. Er muss auf dem jeweiligen Mac geprüft werden.

Alle Netzwerkdienste

networksetup -listallnetworkservices

Ein Stern vor einem Netzwerkdienst bedeutet, dass dieser deaktiviert ist.

Konfiguration eines Dienstes

networksetup -getinfo "Wi-Fi"

IP-Adresse einer Schnittstelle

ipconfig getifaddr en0

en0 muss durch die tatsächlich ermittelte Schnittstelle ersetzt werden.

DHCP-Informationen

ipconfig getpacket en0

Standardroute

route -n get default

Routingtabelle

netstat -rn

Aktueller DNS-Zustand

scutil --dns

Die Ausgabe zeigt die tatsächlich von macOS verwalteten Resolver und ist für die Diagnose häufig aussagekräftiger als das alleinige Betrachten einer einzelnen DNS-Adresse in den Systemeinstellungen.

Proxykonfiguration

scutil --proxy

Netzwerkzustand beobachten

scutil --nwi

Typische Prüfreihenfolge

  1. Wird der Adapter erkannt?
  2. Ist die Schnittstelle aktiv?
  3. besitzt sie eine erwartete IP-Konfiguration?
  4. existiert eine passende Route?
  5. ist das lokale Gateway erreichbar?
  6. funktioniert die Namensauflösung?
  7. ist der Zielport erreichbar?
  8. funktioniert das Anwendungsprotokoll?
  9. beeinflussen VPN, Proxy, Filter oder Firewall die Verbindung?

13. Erreichbarkeit, DNS und Ports prüfen

IP-Erreichbarkeit

ping -c 4 192.168.1.1

Namensauflösung und Erreichbarkeit

ping -c 4 example.com

Ein fehlgeschlagener Ping beweist nicht automatisch, dass ein Host oder Dienst nicht erreichbar ist. ICMP kann gefiltert werden.

Route untersuchen

traceroute example.com

DNS-Abfrage

dig example.com

Bestimmten DNS-Server abfragen:

dig @192.168.1.1 example.com

macOS-Systemauflösung prüfen

dscacheutil -q host -a name example.com

Zielport testen

nc -vz example.com 443

UDP-Prüfungen mit nc liefern aufgrund der verbindungslosen Arbeitsweise von UDP nicht dieselbe Bestätigung wie ein erfolgreicher TCP-Verbindungsaufbau.

HTTP- und TLS-Verbindung

curl -v https://example.com/

Nur Header abrufen:

curl -I https://example.com/

Zeitwerte erfassen:

curl -o /dev/null -sS \
  -w 'DNS: %{time_namelookup}\nTCP: %{time_connect}\nTLS: %{time_appconnect}\nGesamt: %{time_total}\n' \
  https://example.com/

Lokale Listener

lsof -nP -iTCP -sTCP:LISTEN

Verbindungen eines Prozesses

lsof -nP -a -p 1234 -i

Eine erfolgreiche TCP-Verbindung bestätigt nur, dass der Verbindungsaufbau zu diesem Ziel und Port möglich war. Sie bestätigt noch keine korrekte Anmeldung, Anwendungsfunktion oder Datenverarbeitung.

14. Paketmitschnitt unter macOS

macOS enthält tcpdump.

Verfügbare Schnittstellen

sudo tcpdump -D

Verkehr einer Schnittstelle beobachten

sudo tcpdump -i en0

Ohne Namensauflösung

sudo tcpdump -nn -i en0

Nur Verkehr eines Hosts

sudo tcpdump -nn -i en0 host 192.168.1.50

Nur einen Port

sudo tcpdump -nn -i en0 port 443

In eine Datei schreiben

sudo tcpdump -nn -i en0 -w ~/Desktop/mitschnitt.pcap

Begrenzte Anzahl Pakete

sudo tcpdump -nn -i en0 -c 500 -w ~/Desktop/mitschnitt.pcap

Vor dem Mitschnitt festlegen

Paketmitschnitte können enthalten:

15. WLAN-Diagnose

Verbindungsinformationen anzeigen

Bei gedrückter Option-Taste auf das WLAN-Symbol in der Menüleiste klicken.

Je nach macOS-Version werden unter anderem angezeigt:

Diagnose für drahtlose Umgebungen

  1. Mit dem problematischen WLAN verbinden.
  2. Option-Taste gedrückt halten.
  3. WLAN-Menü öffnen.
  4. Diagnose für drahtlose Umgebungen öffnen wählen.

Apple weist darauf hin, dass die Diagnoseanalyse selbst keine Änderungen an den Netzwerkeinstellungen vornimmt.

Mögliche Diagnosebereiche

Wichtige Abgrenzung

Beobachtung Einordnung
WLAN ist verbunden bestätigt nicht automatisch Internetzugriff
starke Signalstärke bestätigt nicht automatisch geringe Störung oder hohen Durchsatz
Internet funktioniert bestätigt nicht automatisch lokale DNS-, VPN- oder Anwendungsfunktion
anderes Gerät funktioniert grenzt ein, schließt aber benutzer- oder gerätespezifische Ursachen nicht aus
Ethernet funktioniert spricht für einen WLAN-bezogenen Unterschied, beweist aber noch keine bestimmte WLAN-Ursache

16. Dienste und launchd

macOS verwendet launchd zur Verwaltung vieler System- und Benutzerdienste.

Benutzerdomäne anzeigen

launchctl print gui/$(id -u)

Systemdomäne anzeigen

sudo launchctl print system

Bestimmten Benutzerdienst untersuchen

launchctl print gui/$(id -u)/com.beispiel.dienst

Bestimmten Systemdienst untersuchen

sudo launchctl print system/com.beispiel.dienst

Der genaue Dienstbezeichner muss vorher ermittelt werden.

Typische Speicherorte

~/Library/LaunchAgents/
/Library/LaunchAgents/
/Library/LaunchDaemons/
/System/Library/LaunchAgents/
/System/Library/LaunchDaemons/

Bedeutung:

Ort typischer Zweck
~/Library/LaunchAgents benutzerspezifische Agenten
/Library/LaunchAgents zusätzliche Agenten für Benutzer
/Library/LaunchDaemons zusätzliche systemweite Daemons
/System/Library/... von macOS bereitgestellte und geschützte Dienste

Eigenschaftslistendatei prüfen

plutil -lint "/Pfad/zur/Datei.plist"

Inhalt lesbar ausgeben:

plutil -p "/Pfad/zur/Datei.plist"

Typische Fehlerursachen

Dienste sollten nicht allein aufgrund ihres unbekannten Namens deaktiviert oder gelöscht werden. Zuerst müssen Hersteller, Pfad, Signatur, Zweck und Abhängigkeiten bestimmt werden.

17. Login-Objekte und Hintergrundelemente

Grafische Verwaltung:

Systemeinstellungen → Allgemein → Anmeldeobjekte und Erweiterungen

Dort können je nach macOS-Version unter anderem sichtbar sein:

Typische Diagnose

  1. Namen und Hersteller dokumentieren.
  2. Installationspfad und Signatur prüfen.
  3. Zeitpunkt der Installation feststellen.
  4. Abhängigkeit von benötigten Anwendungen prüfen.
  5. Element testweise kontrolliert deaktivieren.
  6. Verhalten nach erneuter Anmeldung oder Neustart vergleichen.
  7. Änderung anschließend zurücknehmen oder dokumentiert beibehalten.

Der sichere Modus kann helfen festzustellen, ob eine Störung mit beim Start geladenen Softwarebestandteilen zusammenhängt. Er benennt jedoch nicht automatisch die konkrete Ursache.

18. Codesignatur und Gatekeeper prüfen

Signatur anzeigen

codesign -dv --verbose=4 "/Applications/Beispiel.app"

Die Detailausgabe erfolgt bei codesign häufig über den Fehlerausgabekanal, obwohl kein Fehler vorliegt.

Signatur verifizieren

codesign --verify --deep --strict --verbose=2 "/Applications/Beispiel.app"

Gatekeeper-Bewertung

spctl --assess --type execute --verbose=4 "/Applications/Beispiel.app"

Quarantäneattribut anzeigen

xattr -l "/Applications/Beispiel.app"

Paketinformationen

pkgutil --pkg-info "Paketkennung"

Installierte Paketkennungen durchsuchen:

pkgutil --pkgs | grep -i "hersteller"

Wichtige Einordnung

19. System- und Netzwerkerweiterungen

Moderne macOS-Versionen verwenden für viele Funktionen Systemerweiterungen statt klassischer Kernel Extensions.

Systemerweiterungen anzeigen

systemextensionsctl list

Geladene Kernelkomponenten untersuchen

kmutil showloaded

Je nach Systemversion, Architektur und Berechtigung kann die Ausgabe eingeschränkt sein.

Typische beteiligte Anwendungen

Bei Problemen prüfen

Eine Sicherheits- oder Netzwerkerweiterung darf auf Unternehmenssystemen nicht ohne Freigabe deaktiviert werden.

20. Energieverwaltung und Ruhezustand

Aktuelle Energieeinstellungen

pmset -g

Akkuzustand

pmset -g batt

Aktive Ruhezustandsverhinderungen

pmset -g assertions

Geplante Energieereignisse

pmset -g sched

Power-Management-Protokoll

pmset -g log

Die Ausgabe kann sehr umfangreich sein und sollte zeitlich gefiltert werden.

Hardwareinformationen zur Stromversorgung

system_profiler SPPowerDataType

Typische Fragestellungen

Eine hohe Akkunutzung ist nicht automatisch ein Akkudefekt. Zuerst müssen Energieverbrauch, Arbeitslast, Display, Funkverbindungen, Hintergrundprozesse und angeschlossene Geräte geprüft werden.

21. Spotlight untersuchen

Spotlight-Indizierung kann zeitweise CPU-, Datenträger- und Energieauslastung verursachen.

Status eines Volumes

mdutil -s /

Metadaten einer Datei

mdls "/Pfad/zur/Datei"

Spotlight-Suche im Terminal

mdfind "Suchbegriff"

Typische Hinweise auf Spotlight-Aktivität

Die Indizierung sollte nicht ohne bestätigte Ursache dauerhaft deaktiviert werden. Zuerst ist zu prüfen, ob es sich um eine vorübergehende und erwartete Aktivität handelt.

22. Zeit und Synchronisation

Eine falsche Systemzeit kann unter anderem verursachen:

Zeit anzeigen

date

Konfiguration des Zeitservers

sudo systemsetup -getnetworktimeserver

Netzwerkzeitstatus

sudo systemsetup -getusingnetworktime

Zeitzone

sudo systemsetup -gettimezone

Bei der Protokollauswertung müssen lokale Zeit, UTC, Zeitzone und Sommerzeit berücksichtigt werden.

23. MDM und Konfigurationsprofile

Registrierungsstatus

profiles status -type enrollment

Konfigurationsprofile anzeigen

sudo profiles show -type configuration

Verfügbarkeit, Umfang und erforderliche Rechte können von der macOS-Version und Geräteverwaltung abhängen.

Profile können beeinflussen

Eine Einstellung kann in der grafischen Oberfläche unveränderbar erscheinen, weil sie durch ein Profil oder MDM vorgegeben wird. Das ist nicht automatisch ein Bedienungs- oder Dateirechtefehler.

24. Sicherer Modus

Der sichere Modus kann helfen zu bestimmen, ob eine Störung mit Software zusammenhängt, die während des regulären Starts geladen wird.

Mac mit Apple-Chip

  1. Mac vollständig ausschalten.
  2. Ein-/Ausschalter gedrückt halten, bis die Startoptionen erscheinen.
  3. Startvolume auswählen.
  4. Umschalttaste gedrückt halten.
  5. Im gesicherten Modus fortfahren wählen.

Intel-basierter Mac

  1. Mac einschalten oder neu starten.
  2. sofort die Umschalttaste gedrückt halten.
  3. Taste beim Anmeldefenster loslassen.
  4. anmelden; gegebenenfalls ist eine zweite Anmeldung erforderlich.

Diagnostische Aussage

Ergebnis Einordnung
Fehler tritt im sicheren Modus nicht auf Hinweis auf einen Unterschied bei geladenen Komponenten, Caches oder Startobjekten
Fehler tritt weiterhin auf Drittanbieter-Startkomponenten werden weniger wahrscheinlich, aber nicht vollständig ausgeschlossen
System startet nur im sicheren Modus Startobjekte, Erweiterungen, Dateisystem oder Softwarekonflikte gezielt prüfen

Der sichere Modus ist ein Eingrenzungstest. Er identifiziert nicht automatisch die fehlerhafte Komponente.

25. Apple Diagnose

Apple Diagnose prüft bestimmte interne Hardwarekomponenten des Mac.

Apple weist ausdrücklich darauf hin, dass damit nicht geprüft werden:

Vorbereitung

  1. Mac ausschalten.
  2. nicht benötigte externe Geräte trennen.
  3. Tastatur, Maus, Display, Ethernet und Stromversorgung dürfen angeschlossen bleiben.
  4. Mac auf eine feste und gut belüftete Fläche stellen.
  5. Internetverbindung bereithalten, falls erforderlich.

Mac mit Apple-Chip

  1. Ein-/Ausschalter gedrückt halten, bis die Startoptionen erscheinen.
  2. Ein-/Ausschalter loslassen.
  3. Command-D gedrückt halten, um Apple Diagnose zu starten.

Intel-basierter Mac

  1. Mac einschalten.
  2. sofort die Taste D gedrückt halten.
  3. Taste loslassen, wenn ein Fortschrittsbalken oder die Sprachauswahl erscheint.

Ergebnis dokumentieren

Ein Ergebnis „keine Probleme gefunden“ schließt nicht alle Hardwarefehler aus. Sporadische, temperaturabhängige oder externe Fehler können unentdeckt bleiben.

26. macOS-Wiederherstellung

Die macOS-Wiederherstellung stellt eine vom normalen System getrennte Umgebung bereit.

Typische Funktionen

Mac mit Apple-Chip starten

  1. Mac vollständig ausschalten.
  2. Ein-/Ausschalter gedrückt halten, bis die Startoptionen erscheinen.
  3. Optionen wählen.
  4. Fortfahren wählen.

Intel-basierter Mac starten

Beim Einschalten sofort eine passende Tastenkombination gedrückt halten:

Kombination Zweck
Command-R integrierte macOS-Wiederherstellung
Option-Command-R Internet-Wiederherstellung mit einer kompatiblen aktuellen macOS-Version
Shift-Option-Command-R je nach Mac ursprüngliche oder nächstverfügbare Version über Internet-Wiederherstellung

Die tatsächlich angebotene Version kann vom Mac-Modell und der Verfügbarkeit abhängen.

Wiederherstellungsprotokoll

In der Wiederherstellung:

Fenster → Wiederherstellungsprotokoll

Das Protokoll kann gefiltert und in einer Datei gesichert werden.

Diagnostischer Nutzen

Eine Neuinstallation sollte nicht der erste Diagnoseschritt sein. Sie kann den fehlerhaften Zustand verändern und beseitigt keine externen Hardware-, Netzwerk-, Benutzerprofil- oder Konfigurationsursachen.

27. USB-, Thunderbolt- und externe Geräte

USB-Geräte

system_profiler SPUSBDataType

Thunderbolt- beziehungsweise USB4-Geräte

system_profiler SPThunderboltDataType

Speichergeräte

diskutil list

Offene Verbindungen während des Einsteckens beobachten

log stream --style compact

Anschließend kann nach passenden Prozessen, Subsystemen oder Meldungstexten gefiltert werden.

Kreuztests

Eingrenzung

Beobachtung mögliche Ebene
Gerät fehlt in Systeminformationen Kabel, Anschluss, Stromversorgung, Hardware
Gerät erscheint, aber nicht in der Anwendung Anwendung, Berechtigung, Treiber, Modus
Datenträger erscheint in diskutil, aber nicht im Finder Volume, Aktivierung, Finder-Einstellung, Dateisystem
Gerät funktioniert direkt, aber nicht am Hub Hub, Stromversorgung, Kabel, Kompatibilität
Gerät funktioniert nur an einem Benutzerkonto benutzerspezifische Einstellung oder Berechtigung

28. Bluetooth untersuchen

Systembericht

system_profiler SPBluetoothDataType

Zu prüfen

Das Löschen sämtlicher Kopplungen oder Einstellungsdateien ist keine geeignete Erstmaßnahme. Zuerst sollten Zustand und Umfang dokumentiert werden.

29. Druckerdiagnose

Konfigurierte Drucker

lpstat -p -d

Druckerstatus

lpstat -t

Druckaufträge

lpstat -o

CUPS-Weboberfläche

Auf aktuellen Systemen kann die Weboberfläche deaktiviert sein. Ihr Status und die organisatorischen Sicherheitsvorgaben müssen vor einer Aktivierung geprüft werden.

Typische Prüfreihenfolge

  1. Wird der Drucker lokal beziehungsweise im Netzwerk erreicht?
  2. ist die richtige Warteschlange ausgewählt?
  3. hängt ein Auftrag in der Warteschlange?
  4. stimmt Treiber beziehungsweise verwendetes Druckprotokoll?
  5. funktioniert Namensauflösung?
  6. ist der Drucker über IPP, AirPrint oder einen Printserver eingebunden?
  7. bestehen Authentifizierungs- oder Berechtigungsfehler?
  8. tritt der Fehler bei anderen Benutzern auf?

30. Systemdiagnose sammeln

macOS kann ein umfangreiches Diagnosetaket erzeugen:

sudo sysdiagnose

Der Vorgang kann mehrere Minuten dauern. Speicherort und Abschlussmeldung müssen der Terminalausgabe entnommen werden.

Ein sysdiagnose kann unter anderem enthalten:

Vor dem Einsatz beachten

sysdiagnose ist kein Ersatz für eine gezielte Hypothese. Es ist besonders sinnvoll, wenn:

31. Werkzeugwahl nach Symptom

Symptom erste geeignete Werkzeuge
Mac ist allgemein langsam Aktivitätsanzeige, top, vm_stat, memory_pressure, iostat, Speicherplatzprüfung
Anwendung reagiert nicht Aktivitätsanzeige, sample, Konsole, Diagnoseberichte
Anwendung stürzt ab Konsole, DiagnosticReports, codesign, Versions- und Erweiterungsprüfung
kein Internetzugriff networksetup, ifconfig, route, scutil --dns, ping, dig, nc, curl
WLAN instabil Option-WLAN-Menü, Diagnose für drahtlose Umgebungen, Kreuztest mit Ethernet
Port nicht erreichbar nc, lsof, curl, tcpdump
Datenträger fehlt Systeminformationen, diskutil list, Festplattendienstprogramm
Volume fast voll df, du, Festplattendienstprogramm
Datei kann nicht geöffnet werden ls -leO@, xattr, stat, TCC-, Signatur- und Eigentümerprüfung
Hintergrunddienst startet nicht launchctl print, plutil, Unified Log
hoher Energieverbrauch Aktivitätsanzeige, pmset, system_profiler SPPowerDataType
USB-Gerät funktioniert nicht Systeminformationen, USB-/Thunderbolt-Bericht, Kabel- und Direktanschlusstest
Startproblem sicherer Modus, Apple Diagnose, macOS-Wiederherstellung, Festplattendienstprogramm
Problem nur bei einem Benutzer neues Testkonto, benutzerspezifische Agenten, Einstellungen und TCC
Problem nach Softwareinstallation Login-Objekte, Systemerweiterungen, pkgutil, codesign, Protokolle

32. Praxisbeispiel: Eine Anwendung startet nicht

Symptom

Eine Anwendung beendet sich unmittelbar nach dem Start.

Sichere Untersuchung

  1. genaue Anwendungsversion erfassen,
  2. macOS-Version und Build erfassen,
  3. Zeitpunkt des Startversuchs notieren,
  4. prüfen, ob andere Benutzer betroffen sind,
  5. Anwendung aus dem Terminal oder Finder starten,
  6. Live-Protokollierung auf den Prozess filtern,
  7. Absturzbericht sichern,
  8. Signatur und Gatekeeper-Bewertung prüfen,
  9. geladene Erweiterungen und Plug-ins berücksichtigen,
  10. erst danach Konfigurationen verändern.

Beispielbefehle

sw_vers

codesign --verify --deep --strict --verbose=2 "/Applications/Beispiel.app"

spctl --assess --type execute --verbose=4 "/Applications/Beispiel.app"

log stream --style compact --predicate 'process == "Beispiel"'

ls -lt ~/Library/Logs/DiagnosticReports/

Mögliche Hypothesen

Das sofortige Löschen aller Einstellungsdateien würde den Beweiszustand verändern und kann benutzerspezifische Daten vernichten.

33. Praxisbeispiel: Netzwerk funktioniert im Browser nicht

Symptom

Webseiten werden nicht geladen.

Schrittweise Eingrenzung

networksetup -listallhardwareports

ifconfig

route -n get default

ping -c 4 192.168.1.1

scutil --dns

dig example.com

nc -vz example.com 443

curl -v https://example.com/

scutil --proxy

Bewertung

Ergebnis nächste Eingrenzung
keine IP-Adresse Link, WLAN, DHCP
IP vorhanden, keine Standardroute Netzwerkkonfiguration, DHCP, VPN
Gateway nicht erreichbar lokales Netz, VLAN, WLAN, Router
IP-Ziel erreichbar, DNS fehlschlägt Resolver, DNS-Server, VPN, Filter
DNS funktioniert, Port 443 fehlschlägt Firewall, Route, Proxy, Zielservice
curl funktioniert, Browser nicht Browserprofil, Erweiterung, Proxy, Zertifikat, TCC
Problem nur mit VPN VPN-Route, DNS, Netzwerkerweiterung, Richtlinie

34. Praxisbeispiel: Mac ist plötzlich sehr langsam

Zuerst sichern

date

uptime

top -l 1 -o cpu

memory_pressure

sysctl vm.swapusage

df -h /

iostat -w 1

Danach prüfen

Das Beenden des Prozesses mit der höchsten CPU-Auslastung ist keine vollständige Ursachenanalyse. Der Prozess kann eine notwendige Folgearbeit ausführen oder nur auf eine andere Störung reagieren.

35. Typische Fehlinterpretationen

Aussage fachliche Einordnung
„Der Arbeitsspeicher ist fast vollständig belegt.“ macOS nutzt Speicher bewusst für Anwendungen und Caches. Speicherdruck und Swap sind aussagekräftiger.
„sudo müsste auf alles zugreifen können.“ TCC und SIP können den Zugriff trotz Root-Rechten begrenzen.
„Der Prozess hat die höchste CPU-Auslastung und ist daher defekt.“ Hohe Auslastung kann zur erwarteten Arbeit gehören.
„Apple Diagnose meldet keinen Fehler, also ist die Hardware sicher fehlerfrei.“ Nicht alle Hardwarefehler und keine externen Komponenten werden vollständig geprüft.
„WLAN ist verbunden, deshalb muss Internet funktionieren.“ WLAN-Verbindung, IP-Konfiguration, Routing, DNS und Internetdienst sind unterschiedliche Ebenen.
„Erste Hilfe repariert auch eine defekte SSD.“ Das Werkzeug prüft beziehungsweise repariert Dateisystemstrukturen, nicht verschlissene Hardware.
„Im Protokoll steht error; das ist die Ursache.“ Die Meldung kann erwartet, unabhängig oder eine Folge des eigentlichen Fehlers sein.
„Eine gültige Codesignatur beweist, dass die Anwendung funktioniert.“ Sie bestätigt nicht die fehlerfreie Funktion oder Kompatibilität.
„Der sichere Modus behebt die Ursache.“ Er dient vor allem als Vergleichs- und Eingrenzungstest.
„Das Gerät erscheint im Systembericht und funktioniert deshalb vollständig.“ Erkennung, Treiber, Berechtigung und Anwendungsfunktion müssen getrennt geprüft werden.
„Ein Neustart hat geholfen, also ist die Ursache beseitigt.“ Der Neustart kann nur flüchtigen Zustand zurückgesetzt haben.
„ping schlägt fehl, daher ist der Server offline.“ ICMP kann blockiert sein, obwohl der eigentliche Dienst erreichbar ist.
„Das Löschen aller Einstellungen ist die schnellste Lösung.“ Dadurch können Beweise und Benutzerdaten verloren gehen, ohne die Ursache zu bestätigen.

36. Checkliste macOS-Fehleranalyse

37. Schnellreferenz

Aufgabe Werkzeug oder Befehl
macOS-Version sw_vers
Architektur uname -m
Hardwareübersicht system_profiler SPHardwareDataType
Prozessliste ps aux
Prozess suchen pgrep -afil "Name"
CPU-Auslastung top -l 1 -o cpu
Speicherdruck memory_pressure
Speicherseiten vm_stat
Swap sysctl vm.swapusage
Datenträgerstruktur diskutil list
APFS-Struktur diskutil apfs list
Dateisystembelegung df -h
Verzeichnisgröße du -sh Pfad
offene Dateien lsof
Listener lsof -nP -iTCP -sTCP:LISTEN
Netzwerkadapter networksetup -listallhardwareports
Schnittstellen ifconfig
Standardroute route -n get default
Routingtabelle netstat -rn
DNS-Zustand scutil --dns
Proxy-Zustand scutil --proxy
DNS-Abfrage dig example.com
Porttest nc -vz host port
HTTP-/TLS-Test curl -v URL
Paketmitschnitt sudo tcpdump -nn -i Schnittstelle
Protokollhistorie log show
Live-Protokoll log stream
Dienst untersuchen launchctl print
PLIST prüfen plutil -lint Datei.plist
Dateirechte und Attribute ls -leO@ Pfad
Signatur prüfen codesign --verify
Gatekeeper prüfen spctl --assess
Systemerweiterungen systemextensionsctl list
Energiezustand pmset -g
Ruhezustandsblocker pmset -g assertions
MDM-Status profiles status -type enrollment
umfangreiche Diagnose sudo sysdiagnose

Merksatz

macOS-Fehleranalyse bedeutet nicht, wahllos Einstellungen zurückzusetzen oder Schutzmechanismen zu umgehen. Zuerst werden Systemzustand, Prozesse, Ressourcen, Protokolle, Netzwerk, Datenträger und Berechtigungen getrennt untersucht. Danach wird eine konkrete Hypothese mit einer kleinen, kontrollierten und möglichst reversiblen Maßnahme geprüft.

Quellen und weiterführende Dokumentation

5. Werkzeuge der Fehleranalyse

5.6 Netzwerkgeräte – Werkzeuge zur Fehleranalyse

Netzwerkgeräte wie Switches, Router, Firewalls, WLAN-Access-Points, Controller, Load Balancer und VPN-Gateways verfügen meist über eigene Diagnosefunktionen. Dazu gehören:

Die genaue Syntax hängt von Hersteller, Produktfamilie, Betriebssystem und Softwareversion ab. Ein Befehl darf deshalb nicht ungeprüft auf ein anderes Gerät übertragen werden.

1. Grundregeln für die Untersuchung

Vor jedem Zugriff müssen geklärt werden:

Zuerst nur lesend untersuchen

Geeignet sind zunächst:

Zu vermeiden sind ohne bestätigte Ursache und Freigabe:

Eine reine Statusabfrage ist nicht auf jedem Gerät vollständig risikofrei. Umfangreiche Support- oder Diagnosebefehle können CPU, Arbeitsspeicher, Konsole oder Managementverbindung belasten.

2. Systematisch von unten nach oben prüfen

Ebene typische Fragestellung
Stromversorgung Ist das Gerät eingeschaltet und ausreichend versorgt?
Hardware Sind Module, Netzteile, Lüfter und Temperatursensoren fehlerfrei?
physische Verbindung Besteht Link? Stimmen Medium, Kabel, Transceiver und Geschwindigkeit?
Sicherungsschicht Stimmen VLAN, Trunk, STP, LACP und MAC-Lernen?
Netzwerkschicht Stimmen IP-Adresse, Präfix, ARP/ND und Routing?
Transport Ist der benötigte TCP- oder UDP-Port erreichbar?
Sicherheit Blockieren ACL, Firewall, NAC oder VPN-Richtlinien?
Anwendung Funktionieren DNS, DHCP, RADIUS, NTP oder andere Dienste?
Management Erreichen Monitoring, Syslog, SNMP und zentrale Verwaltung das Gerät?

Ein Fehler sollte möglichst auf die kleinste betroffene Ebene eingegrenzt werden.

3. Zustand vor Veränderungen sichern

Vor einer Änderung sollten mindestens dokumentiert werden:

Typische Beweissicherung

Gerät:
Standort:
Hersteller und Modell:
Betriebssystem und Version:
Managementadresse:
Zeitpunkt:
Symptom:
betroffene Schnittstelle:
betroffenes VLAN beziehungsweise VRF:
Quelladresse:
Zieladresse:
Zielport und Protokoll:
letzte Änderung:
gesicherte Ausgaben:
durchgeführte Tests:
Ergebnis:

4. Managementzugriff prüfen

Typische Zugriffswege sind:

Sicherheitsregeln

Bei fehlendem Zugriff unterscheiden

Beobachtung mögliche Ursache
Gerät antwortet nicht auf Ping ICMP gefiltert, falsche Route, Gerät ausgefallen oder Managementadresse falsch
Ping funktioniert, SSH nicht Dienst deaktiviert, ACL, falscher Port, Überlastung oder Authentifizierungsproblem
SSH-Verbindung startet, Anmeldung schlägt fehl lokales Konto, RADIUS, TACACS+, Zertifikat oder Berechtigung
Zugriff nur über Konsole möglich Managementnetz, Routing, VRF, ACL oder Managementdienst
zentrale Verwaltung zeigt Gerät offline Managementpfad, Zertifikat, Zeit, DNS, Tunnel oder Controllerverbindung
Zugriff funktioniert nur von einem Netz Routing, Firewall, Management-ACL oder VRF

5. Geräteidentität und Softwarestand

Zu erfassen sind:

Cisco IOS beziehungsweise IOS XE

show version

show inventory

show license summary

Juniper Junos

show version

show chassis hardware

show system uptime

Aruba AOS-CX

show version

show system

show inventory

Die verfügbaren Befehle können je nach Plattform und Version abweichen.

6. CPU, Arbeitsspeicher und Systemzustand

Hohe Auslastung kann dazu führen, dass:

Cisco IOS beziehungsweise IOS XE

show processes cpu

show processes memory

show platform resources

Juniper Junos

show chassis routing-engine

show system processes extensive

show system memory

Aruba AOS-CX

show system resource-utilization

top cpu

top memory

Bei Auffälligkeiten prüfen

Ein Prozess mit hoher CPU-Auslastung ist nicht automatisch die Ursache. Er kann auf einen Broadcast-Sturm, eine Routinginstabilität oder eine andere Störung reagieren.

7. Hardware, Temperatur und Stromversorgung

Zu prüfen sind:

Cisco IOS beziehungsweise IOS XE

show environment

show platform

show power

show power inline

Nicht jeder Befehl ist auf jeder Cisco-Plattform vorhanden.

Juniper Junos

show chassis environment

show chassis alarms

show system alarms

show poe controller

Aruba AOS-CX

show environment

show system power-supply

show system fans

show poe brief

Typische Warnsignale

8. Schnittstellenstatus untersuchen

Für jede betroffene Schnittstelle sind mindestens zu prüfen:

Cisco IOS beziehungsweise IOS XE

Übersicht:

show interfaces status

IP-bezogene Übersicht:

show ip interface brief

Details einer Schnittstelle:

show interfaces GigabitEthernet1/0/1

Beschreibungen:

show interfaces description

Fehlerübersicht auf unterstützten Switches:

show interfaces counters errors

Juniper Junos

Übersicht:

show interfaces terse

Details:

show interfaces ge-0/0/1 extensive

Beschreibung und Status:

show interfaces descriptions

Aruba AOS-CX

show interface brief

show interface 1/1/1

show interface 1/1/1 statistics

Status fachlich einordnen

Zustand mögliche Bedeutung
administrativ deaktiviert Schnittstelle wurde durch Konfiguration abgeschaltet
physisch down kein Link, Kabel-, Transceiver-, Gegenstellen- oder Stromproblem
physisch up, Protokoll down Problem oberhalb der reinen Signalerkennung
häufige Linkwechsel Kabel, Stecker, Transceiver, Stromversorgung oder Autonegotiation
viele Eingangsfehler Medium, Signal, Überlastung oder fehlerhafte Hardware
viele Ausgangsdrops Ausgangswarteschlange überlastet oder Zielverbindung langsamer
Zähler steigen nicht möglicherweise falsche Schnittstelle oder kein Verkehr
Link up bestätigt nur die Verbindung auf der entsprechenden Ebene

9. Fehlerzähler bewerten

Typische Zähler sind:

Mögliche Einordnung

Zähler mögliche Ursache
CRC-Fehler Kabel, Steckverbindung, Transceiver, elektromagnetische Störung oder Gegenstelle
Late Collisions Duplexproblem oder ungeeignete gemeinsame Medienumgebung
Input Drops Eingangspuffer oder Verarbeitung überlastet
Output Drops Ausgangsschnittstelle oder Warteschlange überlastet
Giants zu große Frames, MTU-Abweichung oder fehlerhafte Frames
Runts beschädigte oder zu kurze Ethernetframes
viele Linkwechsel instabile physische Verbindung oder Energieversorgung

Für eine korrekte Bewertung

  1. aktuellen Zählerstand dokumentieren,
  2. Laufzeit des Geräts berücksichtigen,
  3. Datenverkehr beobachten,
  4. Veränderung des Zählers messen,
  5. Gegenstelle prüfen,
  6. Kabel beziehungsweise Transceiver kontrolliert gegenprüfen,
  7. Fehler nicht allein anhand eines historischen Gesamtwerts bewerten.

Ein hoher Zählerstand kann über Monate entstanden sein. Entscheidend ist häufig, ob der Wert während des aktuellen Fehlers weiter steigt.

10. Geschwindigkeit, Duplex und Autonegotiation

Typische Probleme entstehen durch:

Zu vergleichen sind immer beide Seiten der Verbindung.

Prüffragen

11. Transceiver und Glasfaserdiagnose

Diagnoseinformationen können enthalten:

Cisco – abhängig von Plattform und Software

show interfaces transceiver detail

Juniper Junos

show interfaces diagnostics optics

Bestimmte Schnittstelle:

show interfaces diagnostics optics ge-0/0/1

Aruba AOS-CX

show interface transceiver

Die genaue Syntax muss in der Dokumentation der verwendeten Plattform geprüft werden.

Wichtige Einordnung

12. VLAN-Zuordnung prüfen

Typische Ursachen sind:

Cisco IOS beziehungsweise IOS XE

show vlan brief

show interfaces trunk

show interfaces GigabitEthernet1/0/1 switchport

Juniper Junos – abhängig vom Switching-Modell

show vlans

show ethernet-switching interfaces

Aruba AOS-CX

show vlan

show vlan port 1/1/1

show interface 1/1/1

Prüfreihenfolge

  1. Endgeräteport identifizieren.
  2. Portmodus bestimmen.
  3. Access- oder untagged VLAN prüfen.
  4. Trunk beziehungsweise tagged VLANs prüfen.
  5. Zwischenverbindungen untersuchen.
  6. VLAN auf jedem beteiligten Gerät prüfen.
  7. Layer-3-Gateway des VLANs kontrollieren.
  8. DHCP, ARP und Sicherheitsrichtlinien prüfen.

13. MAC-Adresstabelle untersuchen

Die MAC-Adresstabelle zeigt, an welcher Schnittstelle ein Switch eine MAC-Adresse gelernt hat.

Cisco IOS beziehungsweise IOS XE

show mac address-table

Bestimmte Adresse:

show mac address-table address aaaa.bbbb.cccc

Bestimmte Schnittstelle:

show mac address-table interface GigabitEthernet1/0/1

Juniper Junos

show ethernet-switching table

Aruba AOS-CX

show mac-address-table

Mögliche Beobachtungen

Beobachtung Einordnung
MAC-Adresse fehlt kein Verkehr, falsches VLAN, Port down oder Gerät nicht verbunden
MAC-Adresse am erwarteten Port Layer-2-Lernen funktioniert zumindest in dieser Richtung
MAC-Adresse an unerwartetem Port Verkabelung, Schleife, virtuelle Umgebung oder Topologie prüfen
MAC-Adresse wechselt zwischen Ports Schleife, redundante Fehlkonfiguration oder tatsächlich bewegtes Gerät
sehr viele MAC-Adressen an einem Endgeräteport unerwarteter Switch, Hypervisor, Access Point oder Sicherheitsproblem
Tabelle nahezu ausgelastet ungewöhnlich viele Geräte, Angriff oder Dimensionierungsproblem

Eine gelernte MAC-Adresse bestätigt nicht, dass IP-Konfiguration, Routing, DNS oder die Anwendung funktionieren.

14. Spanning Tree untersuchen

Spanning Tree verhindert Layer-2-Schleifen in redundanten Ethernetnetzen.

Zu prüfen sind:

Cisco IOS beziehungsweise IOS XE

show spanning-tree

Bestimmtes VLAN:

show spanning-tree vlan 10

Details:

show spanning-tree detail

Juniper Junos

show spanning-tree bridge

show spanning-tree interface

Aruba AOS-CX

show spanning-tree

show spanning-tree detail

Hinweise auf eine Layer-2-Schleife

Ein durch STP blockierter Port ist nicht automatisch fehlerhaft. Das Blockieren kann die beabsichtigte schleifenfreie Topologie herstellen.

Bei gebündelten Verbindungen müssen geprüft werden:

Cisco IOS beziehungsweise IOS XE

show etherchannel summary

show lacp neighbor

show interfaces port-channel 1

Juniper Junos

show interfaces ae0 extensive

show lacp interfaces

Aruba AOS-CX

show lacp interfaces

show interface lag 1

Typische Fehler

16. LLDP und CDP zur Topologieprüfung

Nachbarerkennungsprotokolle helfen dabei, die tatsächlich angeschlossene Gegenstelle zu bestimmen.

Cisco Discovery Protocol

show cdp neighbors

Details:

show cdp neighbors detail

show lldp neighbors

show lldp neighbors detail

Juniper Junos

show lldp neighbors

show lldp neighbors detail

Aruba AOS-CX

show lldp neighbor-info

Zu beachten

17. ARP und IPv6 Neighbor Discovery

ARP ordnet IPv4-Adressen MAC-Adressen zu. IPv6 verwendet Neighbor Discovery.

Cisco IOS beziehungsweise IOS XE

show ip arp

show ipv6 neighbors

Juniper Junos

show arp

show ipv6 neighbors

Aruba AOS-CX

show arp

show ipv6 neighbors

Typische Beobachtungen

Beobachtung mögliche Ursache
kein Eintrag Ziel nicht lokal, keine Antwort, falsches VLAN oder falsches Präfix
Eintrag unvollständig ARP- beziehungsweise Neighbor-Anfrage bleibt unbeantwortet
wechselnde MAC-Adresse doppelte IP-Adresse, Cluster, Proxy ARP oder Fehlkonfiguration
MAC-Adresse stimmt nicht mit erwartetem Gerät überein doppelte Adresse, falsche Dokumentation oder Manipulation
Eintrag vorhanden, Kommunikation scheitert Problem kann oberhalb der Nachbarauflösung liegen

Das manuelle Löschen von ARP- oder Neighbor-Einträgen verändert den Zustand und sollte erst nach Dokumentation und mit konkreter Hypothese erfolgen.

18. IP-Adressen und Routingtabelle

Zu prüfen sind:

Cisco IOS beziehungsweise IOS XE

show ip interface brief

show ip route

Bestimmtes Ziel:

show ip route 192.0.2.10

IPv6:

show ipv6 route

VRF-Übersicht:

show vrf

Juniper Junos

show interfaces terse

show route

Bestimmtes Ziel:

show route 192.0.2.10

Routinginstanzen:

show route instance

Aruba AOS-CX

show ip interface brief

show ip route

show vrf

Routingprüfung

  1. Quellnetz bestimmen.
  2. Zieladresse exakt bestimmen.
  3. verwendete VRF beziehungsweise Routinginstanz feststellen.
  4. Route zum Ziel prüfen.
  5. nächsten Hop prüfen.
  6. Erreichbarkeit des nächsten Hops prüfen.
  7. Rückroute untersuchen.
  8. Policy-Based Routing berücksichtigen.
  9. NAT, Firewall und VPN berücksichtigen.
  10. bei dynamischem Routing den Protokollzustand prüfen.

Eine vorhandene Hinroute bestätigt keine funktionierende Rückroute. Asymmetrische Wege können insbesondere bei Firewalls und zustandsbehafteten Systemen Probleme verursachen.

19. Ping richtig verwenden

Ping verwendet ICMP Echo Request und Echo Reply.

Damit können unter anderem untersucht werden:

Cisco IOS beziehungsweise IOS XE

ping 192.0.2.10

Erweiterter Dialog:

ping

Juniper Junos

ping 192.0.2.10

Bestimmte Quelladresse:

ping 192.0.2.10 source 192.0.2.1

Aruba AOS-CX

ping 192.0.2.10

Die Optionen für Quelladresse, VRF, Paketgröße und Anzahl sind versionsabhängig.

Sinnvolle Zielreihenfolge

  1. eigene Schnittstellenadresse,
  2. direkt verbundener nächster Hop,
  3. Gateway,
  4. entferntes IP-Ziel,
  5. Ziel über Namen.

Grenzen

20. Traceroute richtig verwenden

Traceroute hilft dabei, den Pfad beziehungsweise die antwortenden Zwischenstationen zu untersuchen.

Cisco IOS beziehungsweise IOS XE

traceroute 192.0.2.10

Juniper Junos

traceroute 192.0.2.10

Aruba AOS-CX

traceroute 192.0.2.10

Einordnung

21. Dynamische Routingprotokolle

Bei OSPF, BGP und anderen Protokollen sind drei Ebenen getrennt zu prüfen:

  1. besteht die Nachbarschaft?
  2. werden erwartete Routen ausgetauscht?
  3. wird die gewünschte Route tatsächlich für die Weiterleitung verwendet?

Cisco – OSPF

show ip ospf neighbor

show ip ospf interface

show ip route ospf

Cisco – BGP

show ip bgp summary

show ip bgp

show ip route bgp

Juniper – OSPF

show ospf neighbor

show ospf interface

show route protocol ospf

Juniper – BGP

show bgp summary

show route protocol bgp

Aruba AOS-CX – je nach Plattform und Funktionsumfang

show ip ospf neighbors

show bgp all summary

Typische Ursachen

Eine bestehende Routingnachbarschaft bestätigt nicht, dass alle benötigten Präfixe korrekt angenommen, ausgewählt und weitergeleitet werden.

22. ACL- und Firewallregeln prüfen

Bei Zugriffslisten und Firewalls müssen geprüft werden:

Cisco IOS beziehungsweise IOS XE

show access-lists

show ip access-lists

Zuordnung zu Schnittstellen:

show ip interface

Juniper SRX

show security policies

show security policies hit-count

show security flow session

show security nat source rule all

Wichtige Einordnung

23. DHCP untersuchen

Zu prüfen sind:

Cisco IOS beziehungsweise IOS XE

DHCP-Relay auf einer Schnittstelle erkennen:

show running-config interface Vlan10

DHCP Snooping:

show ip dhcp snooping

DHCP-Bindings bei lokalem DHCP-Server:

show ip dhcp binding

Juniper Junos

Die Befehle hängen davon ab, ob das Gerät als DHCP-Server, Relay oder Sicherheitsgerät arbeitet. Beispiele:

show dhcp server binding

show dhcp relay binding

Diese Befehle sind nicht auf jeder Junos-Plattform in derselben Form verfügbar.

Typische Fehlerkette

Client Discover
→ Switch und VLAN
→ DHCP Relay
→ Routing beziehungsweise Firewall
→ DHCP Server
→ Offer und Acknowledgement
→ Rückweg zum Client

24. DNS, NTP, RADIUS und TACACS+

Netzwerkgeräte sind häufig von Infrastrukturdiensten abhängig.

DNS-Probleme können verursachen

NTP-Probleme können verursachen

RADIUS- oder TACACS+-Probleme können verursachen

Cisco IOS beziehungsweise IOS XE

show clock

show ntp associations

show ntp status

show aaa servers

Die verfügbaren AAA-Befehle unterscheiden sich nach Plattform und Version.

Juniper Junos

show system uptime

show ntp associations

show system users

Prüfen

25. Protokolle auswerten

Netzwerkgeräte können Protokolle speichern oder an einen zentralen Syslog-Server senden.

Zu erfassen sind:

Cisco IOS beziehungsweise IOS XE

show logging

Juniper Junos

show log messages

Letzte Einträge:

show log messages | last 50

Aruba AOS-CX

show logging

Typische Meldungen

Eine einzelne Fehlermeldung beweist nicht automatisch die Ursache. Sie muss zeitlich und technisch mit dem beobachteten Symptom verbunden werden.

26. Syslog-Schweregrade

Die verbreitete Syslog-Einteilung umfasst:

Wert Bezeichnung Bedeutung
0 Emergency System nicht verwendbar
1 Alert sofortige Maßnahme erforderlich
2 Critical kritischer Zustand
3 Error Fehlerzustand
4 Warning Warnung
5 Notice bedeutender normaler Zustand
6 Informational Informationsmeldung
7 Debug ausführliche Diagnosemeldung

Die tatsächliche Nutzung der Stufen hängt vom Hersteller und der jeweiligen Komponente ab.

Zu beachten

27. SNMP und Telemetrie

SNMP und Streaming-Telemetrie können langfristige Messwerte liefern.

Typische Werte sind:

SNMP-Versionen

Version Einordnung
SNMPv1 veraltet, keine moderne Absicherung
SNMPv2c Community-basierte Absicherung, keine angemessene Vertraulichkeit
SNMPv3 unterstützt Benutzer-, Authentifizierungs- und Verschlüsselungsmechanismen

SNMPv3 sollte bevorzugt werden, sofern die Umgebung es unterstützt.

Diagnostischer Nutzen

Grenzen

28. Paketmitschnitt auf Netzwerkgeräten

Viele Router, Firewalls und Switches unterstützen lokale oder gespiegelte Paketmitschnitte.

Mögliche Verfahren:

Vorher festlegen

Wichtige Einschränkungen

Paketmitschnitte können enthalten:

29. Debug-Befehle

Debug-Befehle erzeugen detaillierte Laufzeitinformationen.

Sie können:

Vor einem Debug

  1. konkrete Hypothese formulieren,
  2. Herstellerdokumentation prüfen,
  3. Auswirkungen für die Plattform prüfen,
  4. Wartungsfreigabe einholen,
  5. Filter festlegen,
  6. Zeitdauer begrenzen,
  7. Beendigung des Debugs vorbereiten,
  8. alternative Beobachtungsmöglichkeit prüfen.

Cisco IOS beziehungsweise IOS XE

Aktive Debugs anzeigen:

show debugging

Debug-Ausgaben vollständig beenden:

undebug all

Der Befehl debug all darf auf produktiven Geräten nicht als allgemeine Diagnosemaßnahme verwendet werden.

Ein Debug sollte nur gezielt, zeitlich begrenzt und unter Beobachtung durchgeführt werden.

30. Konfiguration vergleichen

Zu unterscheiden sind:

Cisco IOS beziehungsweise IOS XE

show running-config

show startup-config

Letzte Konfigurationsänderung:

show archive log config all

Der Archivierungsbefehl liefert nur dann passende Daten, wenn die entsprechende Funktion unterstützt und eingerichtet ist.

Juniper Junos

show configuration

Vergleich mit vorheriger Konfiguration:

show system commit

show system rollback compare 1

Aruba AOS-CX

show running-config

show startup-config

Beim Vergleich beachten

Eine Konfiguration darf nicht ungeprüft vollständig in ein Ticket oder öffentliches Dokument kopiert werden. Sie kann Kennwörter, Schlüssel, Community-Strings, Adressen und interne Topologieinformationen enthalten.

31. Hochverfügbarkeit und Stacks

Bei redundanten Geräten sind zusätzlich zu prüfen:

Mögliche Fehlerbilder

Beobachtung mögliche Ursache
beide Geräte halten sich für aktiv Split Brain oder unterbrochene Kontrollverbindung
passives Gerät nicht bereit Versions-, Konfigurations- oder Hardwareproblem
Failover funktioniert, Sitzungen brechen ab fehlende oder unvollständige Sitzungssynchronisation
nur Ports eines Stack-Mitglieds betroffen Mitglied, Stack-Verbindung oder Stromversorgung
wiederholte Rollenwechsel instabile Verbindung, Ressourcenproblem oder fehlerhafte Zustandsprüfung
Redundanz angezeigt, aber gemeinsamer Uplink fehlt logische Redundanz ohne vollständige Pfadredundanz

Ein manuell ausgelöstes Failover ist eine produktive Änderung und benötigt eine Risikoprüfung.

32. WLAN-Access-Points und Controller

Bei WLAN-Problemen müssen Funk-, Netzwerk- und Authentifizierungsebene getrennt werden.

Zu prüfen sind:

Typische WLAN-Werte

Fehlinterpretationen vermeiden

Beobachtung Einordnung
starke Signalstärke bestätigt nicht automatisch gute Signalqualität oder geringen Störpegel
Client ist verbunden bestätigt nicht automatisch DHCP, Routing oder Internetzugriff
SSID ist sichtbar bestätigt nicht automatisch erfolgreiche Authentifizierung
Access Point ist online bestätigt nicht automatisch störungsfreien Funkbetrieb
hohe theoretische Datenrate entspricht nicht automatisch dem tatsächlichen Durchsatz
viele Access Points können bei ungeeigneter Planung zusätzliche Störungen verursachen

33. VPN untersuchen

Bei einem VPN müssen getrennt geprüft werden:

  1. physische und IP-Erreichbarkeit,
  2. Namensauflösung,
  3. IKE- beziehungsweise Kontrollverbindung,
  4. Authentifizierung,
  5. Tunnelaufbau,
  6. Verschlüsselungsparameter,
  7. Routen,
  8. Sicherheitsrichtlinien,
  9. NAT-Ausnahmen,
  10. Datenzähler,
  11. Rückweg,
  12. MTU und Fragmentierung.

Typische Fehler

Ein angezeigter VPN-Status „up“ bestätigt nicht automatisch, dass Nutzdaten in beide Richtungen übertragen werden.

34. NAT untersuchen

Bei NAT sind zu erfassen:

Typische Probleme

Eine erfolgreiche NAT-Übersetzung bestätigt noch nicht, dass der Zielservice antwortet.

35. Support- und Diagnosepakete

Viele Hersteller bieten einen Sammelbefehl oder eine Supportdatei an.

Beispiele:

Cisco – plattformabhängig

show tech-support

Juniper Junos

request support information

Aruba AOS-CX

show tech

Diese Ausgaben können sehr umfangreich sein und das Gerät belasten.

Sie können enthalten:

Vor der Erstellung

36. Typische Prüfreihenfolge bei einem ausgefallenen Switchport

  1. betroffenes Endgerät und Port bestimmen,
  2. Linkstatus prüfen,
  3. Portbeschreibung kontrollieren,
  4. Fehlerzähler dokumentieren,
  5. Geschwindigkeit und Duplex prüfen,
  6. VLAN-Zuordnung prüfen,
  7. MAC-Adresstabelle prüfen,
  8. STP-Zustand prüfen,
  9. Port-Security oder NAC prüfen,
  10. PoE-Zustand prüfen,
  11. Nachbarinformationen prüfen,
  12. Gegenstelle untersuchen,
  13. Kabel oder Transceiver kontrolliert gegenprüfen,
  14. nach jeder Maßnahme erneut testen.

Beispiel Cisco IOS beziehungsweise IOS XE

show interfaces status

show interfaces GigabitEthernet1/0/1

show interfaces GigabitEthernet1/0/1 switchport

show mac address-table interface GigabitEthernet1/0/1

show spanning-tree interface GigabitEthernet1/0/1 detail

show power inline GigabitEthernet1/0/1

37. Praxisbeispiel: Client erreicht das Gateway nicht

Symptom

Ein Client besitzt eine IP-Adresse, kann aber sein Standardgateway nicht erreichen.

Prüfung

  1. IP-Adresse und Präfix des Clients kontrollieren.
  2. Standardgateway kontrollieren.
  3. physische Verbindung prüfen.
  4. Access-VLAN des Ports prüfen.
  5. VLAN auf den Trunks verfolgen.
  6. MAC-Adresse des Clients suchen.
  7. ARP-Eintrag auf Client und Gateway prüfen.
  8. Gateway-Schnittstelle beziehungsweise SVI prüfen.
  9. STP-Zustand prüfen.
  10. Port-Security, NAC und ACL prüfen.
  11. Paketmitschnitt nur bei verbleibender Unklarheit verwenden.

Mögliche Ursachen

38. Praxisbeispiel: VLAN funktioniert an einem Switch, am nächsten nicht

Prüfung

  1. VLAN auf beiden Switches anzeigen.
  2. Access-Port des Clients prüfen.
  3. Uplink und Trunk bestimmen.
  4. erlaubte VLANs auf beiden Seiten vergleichen.
  5. native beziehungsweise untagged VLANs vergleichen.
  6. STP-Zustand für das VLAN prüfen.
  7. MAC-Adresse entlang des Pfads verfolgen.
  8. LACP-Zustand bei gebündeltem Uplink prüfen.
  9. Zwischen-Switches einbeziehen.
  10. erst danach Konfiguration ändern.

Mögliche Ursachen

39. Praxisbeispiel: Standortverbindung ist langsam

Zuerst messen

Mögliche Ursachen

Ein hoher Ping-Wert allein beweist keine geringe verfügbare Bandbreite. Laufzeit, Paketverlust, Jitter und Durchsatz sind unterschiedliche Messgrößen.

40. Praxisbeispiel: Gerät ist im Monitoring offline

Prüfreihenfolge

  1. ist nur das Monitoring oder auch die Nutzfunktion betroffen?
  2. ist die Managementadresse erreichbar?
  3. stimmt die Route zum Managementnetz?
  4. funktioniert der verwendete SNMP-, HTTPS- oder Telemetrieport?
  5. stimmt die Management-VRF?
  6. sind ACL und Firewallregeln unverändert?
  7. sind Zugangsdaten oder Zertifikate abgelaufen?
  8. stimmt die Gerätezeit?
  9. ist der Monitoringdienst selbst funktionsfähig?
  10. antwortet das Gerät über einen anderen Managementweg?

Mögliche Einordnung

Ergebnis mögliche Ursache
Nutzdaten funktionieren, Monitoring nicht Managementpfad, SNMP, Zertifikat oder Monitoringserver
Ping funktioniert, SNMP nicht SNMP-Konfiguration, ACL, Zugangsdaten oder Dienst
mehrere Geräte gleichzeitig offline Monitoringserver, gemeinsamer Managementpfad oder zentrale Firewall
nur ein Standort offline WAN-, VPN- oder Standortproblem
Gerät nur über Konsole erreichbar Managementnetz, Routing, ACL oder Überlastung

41. Häufige Fehlinterpretationen

Aussage fachliche Einordnung
„Der Port ist up, also ist die Verbindung in Ordnung.“ Linkstatus bestätigt nicht VLAN, Routing, Fehlerfreiheit oder Anwendung.
„Ping funktioniert, daher ist der Dienst erreichbar.“ Ping prüft keinen Anwendungsport und keine Anmeldung.
„Die Route ist vorhanden, also muss der Verkehr funktionieren.“ Rückroute, Firewall, NAT und operative Weiterleitung müssen ebenfalls stimmen.
„Der Traceroute endet an einem Router, also ist dieser defekt.“ Zwischenstationen können Antworten filtern oder begrenzen.
„STP blockiert einen Port, deshalb liegt ein Fehler vor.“ Das Blockieren kann die beabsichtigte Schleifenvermeidung sein.
„Der Fehlerzähler ist hoch, daher besteht der Fehler noch.“ Entscheidend ist, ob der Zähler während der Störung weiter steigt.
„Die MAC-Adresse wurde gelernt, also funktioniert der Client.“ Nur das Layer-2-Lernen wurde nachgewiesen.
„Das VPN ist up, also fließen Daten.“ Routen, Richtlinien, NAT und Rückweg können weiterhin fehlerhaft sein.
„Das Gerät ist im Monitoring offline, also ist es ausgefallen.“ Nur der Management- oder Monitoringpfad kann gestört sein.
„Ein Neustart behebt das Problem.“ Er kann nur flüchtigen Zustand entfernen und Beweise vernichten.
„show tech ist nur eine harmlose Abfrage.“ Umfangreiche Ausgaben können Ressourcen beanspruchen und vertrauliche Daten enthalten.
„Debug zeigt viele Fehler, also ist die Ursache gefunden.“ Debug-Meldungen müssen mit Zeitpunkt, Datenpfad und Symptom abgeglichen werden.

42. Checkliste Netzwerkgeräte-Fehleranalyse

43. Schnellreferenz

Aufgabe Cisco IOS/IOS XE Juniper Junos Aruba AOS-CX
Version show version show version show version
Hardware show inventory show chassis hardware show inventory
Systemzustand show platform resources show chassis routing-engine show system resource-utilization
Schnittstellenübersicht show ip interface brief show interfaces terse show ip interface brief
Schnittstellendetails show interfaces … show interfaces … extensive show interface …
VLANs show vlan brief show vlans show vlan
Trunks show interfaces trunk show ethernet-switching interfaces Port- und VLAN-Status prüfen
MAC-Tabelle show mac address-table show ethernet-switching table show mac-address-table
Spanning Tree show spanning-tree show spanning-tree bridge show spanning-tree
LACP show lacp neighbor show lacp interfaces show lacp interfaces
LLDP show lldp neighbors show lldp neighbors show lldp neighbor-info
ARP show ip arp show arp show arp
Routingtabelle show ip route show route show ip route
OSPF-Nachbarn show ip ospf neighbor show ospf neighbor show ip ospf neighbors
BGP-Übersicht show ip bgp summary show bgp summary show bgp all summary
Protokolle show logging show log messages show logging
NTP show ntp associations show ntp associations versionsabhängig
Ping ping Ziel ping Ziel ping Ziel
Traceroute traceroute Ziel traceroute Ziel traceroute Ziel
Supportausgabe show tech-support request support information show tech

Diese Tabelle ist eine Orientierung. Vor der Verwendung muss die Befehlsreferenz der konkreten Plattform und Softwareversion geprüft werden.

Merksatz

Netzwerkgeräte werden nicht durch wahllose Neustarts, Tabellenlöschungen oder dauerhafte Debug-Ausgaben untersucht. Zuerst werden Hardware, Schnittstellen, VLANs, Nachbartabellen, Routing, Sicherheitsregeln, Protokolle und Abhängigkeiten getrennt geprüft. Danach wird eine konkrete Hypothese mit einer kleinen, kontrollierten und möglichst reversiblen Maßnahme getestet.

Quellen und weiterführende Dokumentation

5. Werkzeuge der Fehleranalyse

5.7 Physische Messgeräte – Werkzeuge zur Fehleranalyse

Softwarewerkzeuge zeigen, wie Betriebssysteme, Netzwerkgeräte und Anwendungen einen Fehler wahrnehmen. Physische Messgeräte untersuchen dagegen Kabel, Steckverbindungen, elektrische Signale, optische Signale, Funkstörungen und die tatsächliche Stromversorgung.

Sie werden benötigt, wenn beispielsweise:

Ein Messgerät liefert Messwerte und Beobachtungen. Die Ursache ergibt sich erst aus der Verbindung zwischen Symptom, Messpunkt, Referenzwert, Vergleichsmessung und technischer Dokumentation.

1. Sicherheits- und Freigaberegeln

Vor jeder physischen Messung müssen geklärt werden:

Grundregeln

2. Sichtprüfung vor dem Einsatz eines Messgeräts

Eine systematische Sichtprüfung kann bereits viele Fehler erkennen.

Zu prüfen sind:

LED-Anzeigen einordnen

Anzeige mögliche Bedeutung
keine Link-LED kein Signal, Gegenstelle aus, falsches Medium, Kabel- oder Portfehler
Link vorhanden, keine Aktivität keine Datenübertragung oder nur momentan kein Verkehr
ständig hohe Aktivität starke Auslastung, Schleife, Broadcastlast oder normaler hoher Verkehr
orange beziehungsweise gelbe LED herstellerabhängig: Geschwindigkeit, Warnung, Blockierung oder Fehler
wechselnde Farben herstellerabhängiger Status oder ausgehandelte Geschwindigkeit
PoE-Fehleranzeige Leistungsbudget, Klassifizierung, Kurzschluss oder inkompatibles Gerät

3. Ersatzkabel bekannter Qualität

Ein geprüftes Ersatzkabel ist eines der wichtigsten Diagnosemittel.

Es eignet sich für den kontrollierten Vergleich von:

Das Ersatzkabel muss:

Vorgehensweise

  1. Ausgangszustand dokumentieren.
  2. betroffene Verbindung eindeutig bestimmen.
  3. nur das verdächtige Kabel austauschen.
  4. alle übrigen Komponenten unverändert lassen.
  5. Funktion erneut prüfen.
  6. ursprüngliches Kabel bei Bedarf separat testen.
  7. Ergebnis dokumentieren.

Einordnung

Ergebnis mögliche Schlussfolgerung
Fehler verschwindet mit Ersatzkabel ursprüngliches Kabel oder dessen Steckkontakt ist verdächtig
Fehler bleibt unverändert Ursache liegt möglicherweise an Port, Gerät, Konfiguration oder weiterem Leitungsweg
Fehler tritt nur bei Bewegung auf Kabelbruch, Steckkontakt oder Zugbelastung möglich
niedrigere Geschwindigkeit funktioniert Signalqualität, Kabelkategorie, Adernpaar oder Transceiver möglich
Ersatzkabel funktioniert nur an anderem Port Port- oder Konfigurationsproblem möglich

Ein funktionierendes Ersatzkabel beweist nicht automatisch, dass die gesamte feste Gebäudeverkabelung fehlerfrei ist.

4. Einfacher Kupfer-Kabeltester

Ein einfacher Kabeltester prüft vor allem die elektrische Verbindung und die Aderzuordnung eines Kupferkabels.

Typische Prüfungen sind:

Typische Fehlerbilder

Messergebnis Bedeutung
Open mindestens eine Ader ist unterbrochen
Short unerwünschte elektrische Verbindung zwischen Adern
Reversed Adern eines Paares sind vertauscht
Crossed Adern beziehungsweise Paare sind falsch zugeordnet
Split Pair Pinbelegung kann logisch richtig erscheinen, aber die Adern stammen aus falschen verdrillten Paaren
Shield Open Schirmverbindung ist unterbrochen
Length Error gemessene Länge oder Fehlerentfernung ist unplausibel

Grenzen eines einfachen Kabeltesters

Ein bestandener Wiremap-Test bestätigt nicht automatisch:

Ein Kabel kann bei 100 Mbit/s funktionieren und bei 1, 2,5, 5 oder 10 Gbit/s fehlschlagen.

5. Verification, Qualification und Certification

Bei Kupferverkabelung müssen drei Prüfklassen unterschieden werden.

Prüfklasse Zweck typische Aussage
Verification Verdrahtung und grundlegende physische Fehler prüfen Adern korrekt verbunden oder Fehler vorhanden
Qualification Eignung für bestimmte Netzwerktechnik untersuchen Verbindung unterstützt wahrscheinlich eine bestimmte Ethernet-Anwendung
Certification Verkabelung gegen definierte Norm- und Kategoriegrenzen messen Permanent Link oder Channel besteht beziehungsweise besteht nicht

Verification

Geeignet für:

Qualification

Kann zusätzlich untersuchen:

Certification

Ein Kabelzertifizierer misst abhängig von Norm, Adapter und Messaufbau unter anderem:

Ein einfacher Kabeltester ersetzt keinen normgerechten Kabelzertifizierer.

6. Kabelzertifizierer

Ein Kabelzertifizierer wird verwendet, wenn nachgewiesen werden muss, ob eine installierte Verkabelung eine bestimmte Kategorie, Klasse oder Anwendung erfüllt.

Vor der Messung müssen festgelegt werden:

Messaufbau umfasst typischerweise
Permanent Link fest installierte Verkabelung zwischen den Anschlussstellen
Channel gesamte Übertragungsstrecke einschließlich Patchkabeln und Steckverbindungen

Die Messergebnisse verschiedener Aufbauten dürfen nicht ohne Berücksichtigung der verwendeten Adapter und Grenzwerte miteinander verglichen werden.

Bei einem fehlgeschlagenen Test dokumentieren

Typische Ursachen eines nicht bestandenen Zertifizierungstests

7. TDR für Kupferleitungen

Ein Time Domain Reflectometer sendet einen Impuls in eine Leitung und wertet Reflexionen aus. Dadurch können Änderungen der elektrischen Eigenschaften entlang eines Kabels lokalisiert werden.

Ein TDR kann je nach Gerät Hinweise liefern auf:

Vereinfachtes Prinzip

Messgerät
→ elektrischer Impuls
→ Ausbreitung im Kabel
→ Reflexion an einer Störstelle
→ Berechnung der Entfernung aus der Laufzeit

Die Entfernungsberechnung hängt von der Ausbreitungsgeschwindigkeit des Kabels ab. Häufig wird dafür der NVP-Wert verwendet.

NVP

NVP steht für Nominal Velocity of Propagation und beschreibt die Signalausbreitung im Verhältnis zur Lichtgeschwindigkeit.

Ein falscher NVP-Wert führt zu einer falschen Entfernungsangabe.

Einordnung typischer Reflexionen

Beobachtung mögliche Ursache
starke Reflexion am Leitungsende offenes Ende oder Abschluss
starke Reflexion vor erwartetem Ende Unterbrechung oder beschädigte Verbindung
Reflexion mit entgegengesetzter Charakteristik Kurzschluss oder starke Impedanzänderung
mehrere Reflexionen mehrere Steckstellen, Abzweigungen oder Beschädigungen
unplausible Entfernung falscher NVP, falscher Kabeltyp oder komplexer Leitungsweg

Ein TDR lokalisiert eine elektrische Auffälligkeit. Es zeigt nicht automatisch, welches Bauteil dort tatsächlich beschädigt ist.

8. Tongenerator und Leitungssucher

Ein Tongenerator speist ein Suchsignal in eine Leitung ein. Ein Leitungssucher beziehungsweise eine induktive Prüfsonde hilft, dieses Signal an Kabeln, Patchfeldern oder Anschlussdosen zu erkennen.

Geeignet für:

Sichere Vorgehensweise

  1. Leitung eindeutig bestimmen.
  2. prüfen, ob sie aktiv ist oder Spannung führt.
  3. Gerätespezifikation beachten.
  4. Tongenerator passend anschließen.
  5. Signal am vermuteten Leitungsweg verfolgen.
  6. mehrere mögliche Leitungen vergleichen.
  7. Leitung anschließend eindeutig beschriften.
  8. Dokumentation aktualisieren.

Grenzen

9. Port- und Leitungslokalisierung über Link Blink

Einige Netzwerkprüfgeräte können den Link am Switchport gezielt auf- und abbauen oder ein Blinkmuster erzeugen.

Damit kann ein Administrator einen physischen Port identifizieren, ohne ausschließlich den Leitungsweg mit einem Tongenerator zu verfolgen.

Zu beachten

10. Loopback-Stecker

Ein Loopback-Stecker führt Sende- und Empfangssignale an einer Schnittstelle kontrolliert zurück.

Mögliche Varianten existieren unter anderem für:

Mögliche Einsatzzwecke

Risiken

Loopback-Stecker dürfen nur nach Herstelleranleitung und mit eindeutiger Zuordnung verwendet werden.

11. Vergleichshardware

Vergleichshardware hilft dabei, einen Fehler auf Gerät, Adapter, Kabel, Port oder Konfiguration einzugrenzen.

Geeignet sind beispielsweise:

Kontrollierter Vergleich

  1. nur eine Komponente verändern,
  2. kompatible Vergleichshardware verwenden,
  3. Versions- und Treiberunterschiede dokumentieren,
  4. identische Verbindung erneut testen,
  5. Ergebnis mit dem Ausgangszustand vergleichen,
  6. ursprüngliche Komponente separat untersuchen.

Fehlinterpretationen vermeiden

Ergebnis Einordnung
anderer Adapter funktioniert ursprünglicher Adapter, Treiber oder dessen Kompatibilität ist verdächtig
anderer Laptop funktioniert Fehler kann am ersten Client liegen, muss aber nicht ausschließlich Hardware sein
anderer Port funktioniert ursprünglicher Port oder dessen Konfiguration ist verdächtig
anderer Transceiver funktioniert ursprünglicher Transceiver oder dessen Kompatibilität ist verdächtig
Ersatznetzteil funktioniert ursprüngliches Netzteil oder dessen Leistungsabgabe ist verdächtig

12. PoE-Tester

Ein PoE-Tester untersucht Power over Ethernet zwischen Power Sourcing Equipment und Powered Device.

Begriffe

Begriff Bedeutung
PSE stellt PoE-Leistung bereit, beispielsweise Switch oder Injektor
PD empfängt PoE-Leistung, beispielsweise Access Point, Kamera oder Telefon
Endspan PoE wird direkt durch den Switch bereitgestellt
Midspan PoE wird durch einen zwischengeschalteten Injektor bereitgestellt
PoE-Klasse handelt beziehungsweise beschreibt den Leistungsbedarf
PoE-Budget insgesamt verfügbare Leistung eines Switches

Je nach Messgerät können untersucht werden:

Typische PoE-Probleme

PoE-Prüfreihenfolge

  1. Leistungsanforderung des Endgeräts bestimmen.
  2. unterstützten PoE-Standard des Switches prüfen.
  3. PoE-Konfiguration und Gesamtbudget kontrollieren.
  4. Messung direkt am Switchport durchführen.
  5. Messung an der entfernten Netzwerkdose durchführen.
  6. Spannungs- und Leistungsunterschied vergleichen.
  7. Kabel auf Wiremap und Widerstandsprobleme prüfen.
  8. Endgerät mit geprüftem Kabel und geeignetem PSE testen.
  9. Ereignisprotokolle und Portstatus untersuchen.

Eine Leerlaufspannung bestätigt nicht, dass unter realer Last ausreichend Leistung zur Verfügung steht.

13. Passive PoE-Verbindungen

Passives PoE verwendet möglicherweise dauerhaft anliegende Spannung ohne standardisierte Aushandlung.

Risiken sind:

Vor dem Anschließen müssen geprüft werden:

Passives PoE darf nicht allein anhand eines identischen RJ45-Steckers als kompatibel betrachtet werden.

14. Multimeter

Ein Multimeter kann abhängig von Gerät, Messleitungen und Qualifikation unter anderem messen:

Mögliche IT-nahe Einsatzbereiche sind:

Gefahren

Verbindliche Begrenzung

Multimeter dürfen nur durch dafür qualifizierte Personen, mit geeignetem Messgerät und innerhalb des zulässigen Einsatzbereichs verwendet werden.

Ein IT-Administrator sollte keine Arbeiten an Netzspannung, Stromverteilungen oder geöffneten Netzteilen durchführen, wenn dafür die elektrotechnische Qualifikation und Freigabe fehlen.

15. Netzteil- und Stromversorgungsprüfung

Viele scheinbare Netzwerk- oder Gerätefehler entstehen durch die Stromversorgung.

Zu prüfen sind:

Typische Fehlerbilder

Beobachtung mögliche Ursache
Gerät startet wiederholt neu instabiles Netzteil, Überlast, Temperatur oder Hardwarefehler
Gerät funktioniert ohne Zusatzmodule Netzteil zu schwach oder defektes Modul
redundante Netzteile angezeigt, aber nur ein Stromkreis keine vollständige Stromredundanz
Fehler nur bei hoher Last Spannungseinbruch, Leistungsgrenze oder Kühlungsproblem
USV meldet Batteriebetrieb Stromversorgung vor der USV oder Netzqualität prüfen
Gerät bleibt nach Stromausfall aus Startverhalten, Netzteil, USV oder Hardwarezustand

16. Glasfaser-Grundlagen für die Messung

Vor einer Glasfasermessung müssen bekannt sein:

Häufige Steckertypen

Wichtige Unterscheidungen

dBm und dB

Einheit Bedeutung
dBm absoluter optischer Leistungspegel bezogen auf 1 mW
dB Verhältnis beziehungsweise Verlust zwischen zwei Pegeln

Ein Wert von -10 dBm ist kein Verlust von -10 dB. Absoluter Pegel und Streckendämpfung müssen getrennt behandelt werden.

17. Glasfaser inspizieren und reinigen

Verschmutzte Steckerendflächen gehören zu den häufigsten Ursachen optischer Probleme.

Mögliche Verunreinigungen sind:

Grundregel

inspizieren
→ bei Bedarf reinigen
→ erneut inspizieren
→ erst danach verbinden

Benötigte Werkzeuge können sein:

Wichtige Regeln

Eine verschmutzte Endfläche kann nicht nur die Messung verfälschen, sondern beim Verbinden auch die Gegenseite verschmutzen oder beschädigen.

18. Visual Fault Locator

Ein Visual Fault Locator speist sichtbares rotes Licht in eine Glasfaser ein.

Er kann helfen bei:

Grenzen

19. Optischer Leistungsmesser

Ein optischer Leistungsmesser misst den empfangenen optischen Pegel.

Vor der Messung müssen bekannt sein:

Mögliche Ergebnisse

Messwert Einordnung
innerhalb des zulässigen Bereichs Pegel ist grundsätzlich geeignet
unterhalb der Empfindlichkeitsgrenze Signal zu schwach
oberhalb der Übersteuerungsgrenze Signal zu stark
stark schwankender Pegel instabile Quelle, Stecker, Faser oder Bewegung
kein Pegel falsche Faser, Sender aus, Unterbrechung oder falsche Wellenlänge
Pegel ausreichend, Link bleibt down Ursache kann Transceiver, Protokoll, Geschwindigkeit oder Gegenstelle sein

Typische Ursachen für zu geringe Leistung

20. Optical Loss Test Set

Ein Optical Loss Test Set besteht typischerweise aus Lichtquelle und Leistungsmesser. Es bestimmt die Einfügedämpfung einer Glasfaserstrecke.

Vereinfachtes Verfahren

Referenzmessung
→ Messleitungen und Lichtquelle referenzieren
→ zu prüfende Strecke einfügen
→ empfangenen Pegel messen
→ Verlust bestimmen
→ mit Grenzwert vergleichen

Vorher festzulegen sind:

Fehlerquellen bei der Messung

Eine Messung ist nur dann vergleichbar, wenn Referenzmethode, Wellenlänge, Messleitungen und Grenzwerte dokumentiert wurden.

21. OTDR für Glasfaser

Ein Optical Time Domain Reflectometer sendet optische Impulse in eine Faser und wertet das zurückgestreute beziehungsweise reflektierte Licht über die Zeit aus.

Ein OTDR kann je nach Gerät darstellen:

Vereinfachte Darstellung

OTDR
→ optischer Impuls
→ Rückstreuung entlang der Faser
→ Reflexionen an Ereignissen
→ Ereignistabelle und Kurve

Launch- und Receive-Faser

Eine Vorlauffaser kann erforderlich sein, um:

Eine Nachlauffaser kann erforderlich sein, um:

Wichtige OTDR-Einstellungen

Einfluss der Pulsbreite

Einstellung Vorteil Nachteil
kurze Pulsbreite bessere Auflösung nahe beieinanderliegender Ereignisse geringere Reichweite und schwächeres Signal
lange Pulsbreite größere Reichweite und besserer Dynamikbereich größere Totzonen und geringere Ereignisauflösung

Grenzen

22. SFP- und Transceiver-Diagnose

Viele Transceiver unterstützen Digital Optical Monitoring beziehungsweise Digital Diagnostic Monitoring.

Mögliche Werte sind:

Beispielhafte Einordnung

Beobachtung mögliche Ursache
Empfangsleistung zu niedrig Dämpfung, Verschmutzung, falsche Faser oder schwacher Sender
Empfangsleistung zu hoch ungeeigneter Transceiver oder fehlendes Dämpfungsglied
Sendeleistung außerhalb der Grenze Transceiverfehler oder Temperaturproblem
hohe Temperatur unzureichende Kühlung, hoher Umgebungswert oder Modulproblem
Werte nur auf einer Seite auffällig Richtung der Faserstrecke gezielt untersuchen
keine Diagnosedaten Modul unterstützt DDM nicht oder Gerät liest es nicht aus

Zusätzlich prüfen

Optische Diagnosedaten des Transceivers sind hilfreich, ersetzen aber keine unabhängige Messung bei unklaren oder widersprüchlichen Ergebnissen.

23. WLAN-Spektrumanalysator

Ein WLAN-Scanner zeigt hauptsächlich WLAN-Netze und deren Protokollinformationen. Ein Spektrumanalysator untersucht dagegen die Hochfrequenzenergie im verwendeten Frequenzbereich und kann auch nicht WLAN-basierte Störquellen sichtbar machen.

Mögliche Untersuchungen

Mögliche Störquellen

Messparameter

Vorgehensweise

  1. betroffenen Ort bestimmen.
  2. Zeitpunkt und Symptom dokumentieren.
  3. Messung am betroffenen Clientstandort durchführen.
  4. Vergleichsmessung an einem funktionierenden Standort durchführen.
  5. zeitlichen Verlauf beobachten.
  6. Störquelle durch räumliche Messungen eingrenzen.
  7. WLAN-Konfiguration und Spektrummessung gemeinsam auswerten.
  8. Änderung kontrolliert testen.
  9. erneut messen.

Eine hohe WLAN-Signalstärke bestätigt keine geringe Interferenz und keine gute Signalqualität.

24. WLAN-Site-Survey-Werkzeuge

Ein Site Survey untersucht die räumliche WLAN-Versorgung.

Mögliche Ergebnisse sind:

Arten

Art Beschreibung
Predictive Survey rechnerische Planung anhand von Gebäude- und Materialdaten
Passive Survey Empfang und Auswertung vorhandener Funksignale
Active Survey aktive Verbindung und Messung von Netzwerkleistung
Spectrum Survey Untersuchung der Funkenergie einschließlich nicht WLAN-basierter Quellen

Zu beachten

25. Temperaturmessung und Wärmebildkamera

Temperaturprobleme können zu instabilen Geräten, Leistungseinbrüchen und vorzeitigem Hardwareausfall führen.

Mögliche Werkzeuge sind:

Zu prüfen sind

Grenzen von Infrarotmessungen

26. Serielle Konsole

Eine serielle Konsole ermöglicht lokalen Zugriff, wenn das normale Managementnetz nicht funktioniert.

Mögliche Anschlüsse sind:

Benötigt werden gegebenenfalls:

Typische Parameter

Geschwindigkeit: 9600 oder herstellerspezifisch
Datenbits: 8
Parität: keine
Stoppbits: 1
Flusssteuerung: keine

Die konkreten Werte müssen der Herstellerdokumentation entnommen werden.

Mögliche Diagnoseinformationen

Sicherheitsregeln

27. Out-of-Band-Management

Out-of-Band-Management verwendet einen vom normalen Datenpfad getrennten Managementweg.

Beispiele sind:

Mögliche Funktionen

Sicherheitsanforderungen

Out-of-Band-Management ist kein gewöhnliches Messgerät, aber ein unabhängiger Diagnoseweg zur physischen Hardware und zum Startvorgang.

28. In-Band und Out-of-Band unterscheiden

Merkmal In-Band-Management Out-of-Band-Management
Datenpfad nutzt reguläres Netzwerk nutzt separaten Managementweg
Abhängigkeit vom Betriebssystem häufig vorhanden häufig geringer oder keine
Zugriff bei Routingfehler möglicherweise nicht möglich bei funktionsfähigem OOB-Pfad weiterhin möglich
Zugriff während des Bootens meist eingeschränkt häufig möglich
Risiko Ausfall des Produktivnetzes blockiert Zugriff separater Weg muss besonders geschützt werden
Beispiele SSH, HTTPS, SNMP Konsole, iLO, iDRAC, CIMC, IPMI, Konsolenserver

Eine physisch vorhandene Managementbuchse bestätigt nicht automatisch, dass ein vollständig unabhängiger Out-of-Band-Pfad aufgebaut wurde.

29. Messgerät selbst überprüfen

Auch ein Messgerät kann fehlerhaft sein.

Vor wichtigen Messungen prüfen:

Kontrollmessung

Eine Kontrollmessung an einer bekannten, funktionierenden Referenz hilft dabei, Fehler des Messaufbaus zu erkennen.

Wenn ein unerwartetes Ergebnis große Folgen hätte, sollte es mit einer zweiten Messung, einem anderen Messaufbau oder einem unabhängigen Messgerät bestätigt werden.

30. Kalibrierung und Rückführbarkeit

Bei Zertifizierungs- und Abnahmemessungen ist die Kalibrierung besonders wichtig.

Zu dokumentieren sind:

Eine abgelaufene Kalibrierung bedeutet nicht zwangsläufig, dass jeder Messwert falsch ist. Sie kann jedoch die Nachweisbarkeit und Verwendbarkeit der Messergebnisse beeinträchtigen.

31. Messergebnisse dokumentieren

Eine Messung sollte mindestens folgende Angaben enthalten:

Feld Inhalt
Ticket oder Vorgang eindeutige Referenz
Datum und Uhrzeit Zeitpunkt der Messung
Messperson verantwortliche Person
Standort Gebäude, Raum, Rack oder Anschluss
Verbindung Start- und Endpunkt
Gerät Hersteller, Modell und Seriennummer
Messgerät Hersteller, Modell und Seriennummer
Kalibrierung gültig bis beziehungsweise Status
Messaufbau Permanent Link, Channel, direkt am Port oder anderer Aufbau
Einstellung Standard, Wellenlänge, NVP, Pulsbreite oder Messbereich
Ausgangszustand ursprüngliches Symptom
Messwert tatsächliches Ergebnis
Grenzwert erwarteter beziehungsweise zulässiger Wert
Maßnahme kontrollierte Änderung
Nachmessung Ergebnis nach der Maßnahme
Anhänge Fotos, Kurven, Berichte oder Exportdateien

Beispiel

Verbindung: Patchfeld A-17 → Datendose B-204
Symptom: Link fällt mehrmals pro Stunde auf 100 Mbit/s zurück
Messgerät: Kabelzertifizierer, Seriennummer dokumentiert
Messaufbau: Permanent Link
Grenzwert: Cat 6A
Ergebnis: nicht bestanden
Auffälligkeit: NEXT am nahen Anschluss
Fehlerentfernung: innerhalb des Anschlussbereichs
Maßnahme: Anschluss neu aufgelegt
Nachmessung: bestanden
Funktionstest: stabiler 1-Gbit/s-Link, Fehlerzähler steigen nicht weiter

32. Messwerte richtig vergleichen

Vergleichsmessungen sind nur sinnvoll, wenn die Bedingungen vergleichbar sind.

Zu berücksichtigen sind:

Ungültige Vergleiche

33. Kontrollierte Prüfreihenfolge bei Kupferproblemen

  1. Symptom und betroffene Verbindung bestimmen.
  2. Portstatus und Fehlerzähler dokumentieren.
  3. sichtbare Schäden prüfen.
  4. Steckverbindungen kontrollieren.
  5. geprüftes Patchkabel verwenden.
  6. Gegenstelle mit Vergleichshardware testen.
  7. Wiremap und Kabellänge prüfen.
  8. Fehlerentfernung mit TDR untersuchen.
  9. bei Leistungsanforderungen qualifizieren oder zertifizieren.
  10. PoE gegebenenfalls unter Last messen.
  11. Anschlussstellen und Patchfeld untersuchen.
  12. nach jeder Maßnahme erneut messen.
  13. Konfiguration und physische Messung gemeinsam bewerten.
  14. Ursache und Ergebnis dokumentieren.

34. Kontrollierte Prüfreihenfolge bei Glasfaserproblemen

  1. Fasertyp, Wellenlänge und Transceiver bestimmen.
  2. Portstatus und optische Diagnosedaten dokumentieren.
  3. richtige Polarität prüfen.
  4. Endflächen sicher inspizieren.
  5. bei Bedarf reinigen und erneut inspizieren.
  6. geprüftes Patchkabel einsetzen.
  7. sichtbare Fehlersuche nur mit geeignetem VFL durchführen.
  8. optischen Empfangspegel messen.
  9. Streckendämpfung mit geeigneter Lichtquelle und Leistungsmesser bestimmen.
  10. Ereignisse und Fehlerentfernung bei Bedarf mit OTDR untersuchen.
  11. Messung gegebenenfalls in Gegenrichtung wiederholen.
  12. Ergebnis mit Linkbudget und Grenzwerten vergleichen.
  13. nach jeder Maßnahme erneut messen.
  14. Messkurven und Berichte sichern.

35. Praxisbeispiel: Link fällt auf 100 Mbit/s zurück

Symptom

Ein Gigabit-Endgerät verbindet sich nur mit 100 Mbit/s oder wechselt wiederholt zwischen Geschwindigkeiten.

Prüfung

  1. unterstützte Geschwindigkeiten beider Geräte prüfen.
  2. Auto-Negotiation auf beiden Seiten kontrollieren.
  3. Portstatus und Fehlerzähler dokumentieren.
  4. geprüftes Patchkabel einsetzen.
  5. alle vier Adernpaare mit Kabeltester prüfen.
  6. feste Gebäudeverkabelung untersuchen.
  7. Split Pair, Unterbrechung oder schlechte Auflegung prüfen.
  8. Verbindung bei Bedarf qualifizieren oder zertifizieren.
  9. Vergleichsport und Vergleichsadapter verwenden.
  10. nach der Maßnahme Linkgeschwindigkeit und Fehlerzähler erneut prüfen.

Mögliche Ursachen

36. Praxisbeispiel: PoE-Gerät startet wiederholt neu

Symptom

Ein Access Point oder eine Kamera startet unter Last neu.

Prüfung

  1. PoE-Anforderung des Geräts bestimmen.
  2. unterstützten Standard und Port des Switches prüfen.
  3. verfügbares Gesamtbudget kontrollieren.
  4. Switchprotokolle untersuchen.
  5. Leistung direkt am Switchport prüfen.
  6. Leistung an der entfernten Dose unter Last prüfen.
  7. Kabelweg und Widerstandsunsymmetrie untersuchen.
  8. geprüftes kurzes Kabel verwenden.
  9. geeigneten Vergleichsport oder PSE einsetzen.
  10. Temperatur und Firmware berücksichtigen.

Mögliche Ursachen

37. Praxisbeispiel: Glasfaserlink bleibt down

Prüfung

  1. Transceivertypen auf beiden Seiten vergleichen.
  2. Geschwindigkeit und Wellenlänge prüfen.
  3. Singlemode beziehungsweise Multimode prüfen.
  4. Faserpolarität kontrollieren.
  5. Transceiver vollständig einsetzen.
  6. optische Diagnosedaten auslesen.
  7. Endflächen inspizieren und fachgerecht reinigen.
  8. geprüftes Patchkabel verwenden.
  9. optischen Pegel messen.
  10. Strecke mit OLTS beziehungsweise OTDR untersuchen.
  11. Transceiver kontrolliert austauschen.
  12. Port- und Gerätekonfiguration prüfen.

Mögliche Ursachen

38. Praxisbeispiel: WLAN ist nur in einem Raum instabil

Prüfung

  1. betroffene Clients und Zeiten bestimmen.
  2. Signalstärke und SNR messen.
  3. Kanal und Kanalnutzung prüfen.
  4. Spektrum am betroffenen Ort untersuchen.
  5. Vergleichsmessung außerhalb des Raums durchführen.
  6. zeitabhängige Störquelle suchen.
  7. Wandmaterialien und Raumaufteilung berücksichtigen.
  8. Client mit Vergleichshardware testen.
  9. Access-Point-Position und Sendeleistung prüfen.
  10. Änderung nur einzeln durchführen und erneut messen.

Mögliche Ursachen

39. Praxisbeispiel: Server ist über das Netzwerk nicht erreichbar

Prüfung

  1. Stromversorgung und Statusanzeigen prüfen.
  2. Switchport und Kabel untersuchen.
  3. Out-of-Band-Management testen.
  4. Hardwareereignisse und Sensoren prüfen.
  5. Remote-Konsole öffnen.
  6. Bootstatus beobachten.
  7. Betriebssystem- und Netzwerkzustand prüfen.
  8. bei Bedarf geprüftes Kabel und Vergleichsport verwenden.
  9. Netzteil- und Temperaturzustand untersuchen.
  10. Neustart nur nach Freigabe und Beweissicherung durchführen.

Mögliche Ergebnisse

Ergebnis Einordnung
Out-of-Band erreichbar, Betriebssystem nicht Betriebssystem, Treiber, Netzwerkdienst oder Konfiguration
weder In-Band noch Out-of-Band erreichbar Stromversorgung, Managementpfad oder Hardware
Remote-Konsole zeigt Startfehler Bootmedium, Dateisystem, Firmware oder Hardware
Hardwarestatus zeigt Alarm betroffene Komponente gezielt untersuchen
anderer Switchport funktioniert ursprünglicher Port oder dessen Konfiguration
geprüftes Kabel funktioniert ursprüngliche Verkabelung verdächtig

40. Häufige Fehlinterpretationen

Aussage fachliche Einordnung
„Der Kabeltester zeigt alle Adern, also ist das Kabel für 10 Gbit/s geeignet.“ Ein einfacher Wiremap-Test zertifiziert keine Übertragungsleistung.
„Mit dem Ersatzkabel funktioniert es, also ist sicher nur das Kabel defekt.“ Auch ein Steckkontakt oder eine veränderte mechanische Belastung kann beteiligt sein.
„PoE-Spannung ist vorhanden, also reicht die Leistung aus.“ Entscheidend ist die verfügbare Leistung unter Last.
„Der optische Pegel ist sichtbar, also ist die Faser in Ordnung.“ Pegel, Dämpfung, Reflexionen, Polarität und Protokoll müssen getrennt geprüft werden.
„Das OTDR zeigt einen Fehler bei 20 Metern, also ist dort sicher das Kabel gebrochen.“ Die Anzeige beschreibt ein optisches Ereignis; Messparameter und Leitungsweg müssen berücksichtigt werden.
„Starke WLAN-Signalstärke bedeutet eine gute Verbindung.“ Interferenz, SNR, Kanalnutzung und Retries können die Verbindung trotzdem beeinträchtigen.
„Die Temperatur fühlt sich normal an.“ subjektive Wahrnehmung ersetzt keine Messung und keine Herstellergrenze.
„Der Managementport ist erreichbar, also ist der Server vollständig in Ordnung.“ Out-of-Band-Zugriff bestätigt nicht den Zustand des Betriebssystems oder der Anwendung.
„Ein Multimeter ist ungefährlich, weil nur Kleinspannung gemessen wird.“ falsche Bedienung und unbekannte Stromkreise können weiterhin Schäden verursachen.
„Ein einmal bestandener Test beweist dauerhaft fehlerfreie Verkabelung.“ Kabel, Stecker und Umgebungsbedingungen können sich später verändern.

41. Checkliste physische Messgeräte

42. Schnellreferenz

Werkzeug Hauptzweck bestätigt nicht automatisch
geprüftes Ersatzkabel verdächtiges Kabel kontrolliert vergleichen Fehlerfreiheit der festen Verkabelung
einfacher Kabeltester Wiremap, Unterbrechung und Kurzschluss prüfen Einhaltung einer Kabelkategorie
Kabelqualifizierer Eignung für Netzwerkanwendung untersuchen normgerechte Zertifizierung
Kabelzertifizierer Verkabelung gegen definierte Grenzwerte messen fehlerfreie Switch- oder Endgeräte
TDR Entfernung zu elektrischer Auffälligkeit bestimmen genaue mechanische Ursache
Tongenerator Leitung suchen und zuordnen Ethernet-Leistungsfähigkeit
Loopback-Stecker lokalen Sende- und Empfangspfad prüfen gesamten Ende-zu-Ende-Pfad
PoE-Tester PoE-Erkennung und Leistung untersuchen stabile Leistung ohne Lastmessung
Multimeter geeignete elektrische Größen messen sichere Bedienung ohne Qualifikation
Glasfaser-Inspektionssonde Endflächen untersuchen optische Dämpfung
Visual Fault Locator grobe Fehler und Faserzuordnung prüfen normgerechte Streckenqualität
optischer Leistungsmesser absoluten Empfangspegel messen genaue Position einer Fehlerstelle
OLTS Einfügedämpfung der Strecke messen genaue Lage einzelner Ereignisse
OTDR Ereignisse und Entfernungen entlang der Faser analysieren vollständigen Ersatz für OLTS
Spektrumanalysator Funkenergie und Störquellen untersuchen erfolgreiche WLAN-Anmeldung
Wärmebildkamera Temperaturverteilung sichtbar machen interne Bauteiltemperatur ohne Einordnung
Konsolenkabel lokalen Gerätezugriff ermöglichen funktionierendes Netzwerk
Out-of-Band-Management unabhängigen Hardware- und Konsolenzugriff bereitstellen funktionierendes Betriebssystem

Merksatz

Physische Fehleranalyse beginnt mit Sichtprüfung, Dokumentation und einem kontrollierten Vergleich. Danach wird das passende Messgerät eingesetzt: Kabeltester für Verdrahtung, Zertifizierer für Übertragungsgrenzen, TDR und OTDR für Fehlerentfernungen, Leistungsmesser für optische Pegel, PoE-Tester für Stromversorgung unter realen Bedingungen und Spektrumanalysator für Funkstörungen. Ein einzelner Messwert ersetzt niemals die technische Einordnung und die abschließende Funktionsprüfung.

Quellen und weiterführende Dokumentation

6. Netzwerk- und Verbindungsfehler

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:

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

1. Lernziele

Nach dieser Seite kannst du:

2. Ausgangssituation

Ein Benutzer meldet:

„Mein Computer hat kein Netzwerk.“

Diese Aussage lässt entscheidende Fragen offen:

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

3. Fehlerbild präzisieren

Geeignete Fragen sind:

Beispiel für ein präzisiertes Fehlerbild

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

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

4. Zuerst den Umfang bestimmen

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

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

5. Ausgangszustand sichern

Vor Änderungen sollten mindestens dokumentiert werden:

Windows

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

Linux

macOS

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

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

6. Prüfreihenfolge

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

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

7. Physische Verbindung prüfen

Bei Ethernet sind zu prüfen:

Windows

Get-NetAdapter
Get-NetAdapterStatistics

Linux

ip -s link
ethtool <schnittstelle>

macOS

ifconfig <schnittstelle>
networksetup -getMedia <netzwerkdienst>

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

Mögliche Beobachtungen

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

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

8. WLAN-Verbindung prüfen

Bei WLAN sind zusätzlich zu prüfen:

Windows

netsh wlan show interfaces
netsh wlan show networks mode=bssid

Linux mit NetworkManager

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

macOS

networksetup -getairportnetwork en0
system_profiler SPAirPortDataType

Der tatsächliche Schnittstellenname kann abweichen.

Wichtige Unterscheidung

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

9. Zustand des Netzwerkadapters prüfen

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

Zu prüfen sind:

Windows

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

Linux

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

macOS

networksetup -listallhardwareports
ifconfig
system_profiler SPNetworkDataType

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

10. IPv4-Konfiguration bewerten

Eine vollständige IPv4-Konfiguration umfasst normalerweise:

Beispiel

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

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

Typische Auffälligkeiten

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

11. Automatische private IPv4-Adresse richtig einordnen

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

Eine solche Adresse bedeutet nicht automatisch:

Mögliche Ursachen sind:

Zu prüfen sind

12. DHCP systematisch untersuchen

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

DHCPDISCOVER
→ DHCPOFFER
→ DHCPREQUEST
→ DHCPACK

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

Windows

ipconfig /all
ipconfig /release
ipconfig /renew

Linux mit NetworkManager

nmcli device show
nmcli connection show --active

macOS

ipconfig getpacket <schnittstelle>
networksetup -getinfo <netzwerkdienst>

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

Mögliche Fehlerstellen

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

Bei DHCP zusätzlich prüfen

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:

Windows

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

Linux

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

macOS

ifconfig
netstat -rn -f inet6

Wichtige Einordnung

14. Lokalen Protokollstapel prüfen

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

IPv4

127.0.0.1

IPv6

::1

Windows

ping 127.0.0.1
ping ::1

Linux und macOS

ping 127.0.0.1
ping6 ::1

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

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

15. Eigene Adresse prüfen

Danach kann die eigene zugewiesene Adresse geprüft werden.

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

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

16. ARP und Neighbor Discovery untersuchen

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

Windows

arp -a
Get-NetNeighbor

Linux

ip neighbor

macOS

arp -a
ndp -a

Mögliche Zustände

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

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

17. Standardgateway prüfen

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

Zu prüfen sind:

Windows

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

Linux

ip route
ip -6 route

macOS

route -n get default
netstat -rn

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

18. Lokales und entferntes Ziel unterscheiden

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

Beispiel

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

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

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

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

19. Routingtabelle auswerten

Die Routingentscheidung berücksichtigt unter anderem:

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

Beispiel

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

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

Typische Routingfehler

20. Erreichbarkeit schrittweise testen

Eine sinnvolle Testfolge lautet:

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

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

Beispielhafte Dokumentation

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

21. Ping richtig interpretieren

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

Ein erfolgreicher Ping kann bestätigen:

Ein erfolgreicher Ping bestätigt nicht:

Ein fehlgeschlagener Ping beweist nicht automatisch:

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

22. Pfad mit Traceroute untersuchen

Windows

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

Linux

traceroute <ziel>
tracepath <ziel>

macOS

traceroute <ziel>

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

Grenzen

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:

Windows

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

Linux

resolvectl query <name>
resolvectl status
dig <name>

macOS

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

Gezielte Abfrage eines bestimmten DNS-Servers

dig @<dns-server> <name>

Mögliche Ergebnisse

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

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

24. Port und Dienst statt nur Host testen

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

Windows

Test-NetConnection <ziel> -Port 443

Linux und macOS

nc -vz <ziel> 443

HTTP beziehungsweise HTTPS

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

TLS-Verbindung

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

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

Mögliche Ergebnisse

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

25. Lokale Firewall prüfen

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

Windows

Get-NetFirewallProfile
Get-NetFirewallRule -Enabled True

Linux

Je nach System können unter anderem verwendet werden:

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

macOS

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

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

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

26. Netzwerk-Firewalls und ACLs berücksichtigen

Zwischen Client und Ziel können mehrere Filterinstanzen liegen:

Zu prüfen sind:

Eine scheinbar passende Freigaberegel kann wirkungslos sein, wenn:

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:

Windows

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

Linux und macOS

env | grep -i proxy

macOS zusätzlich

scutil --proxy

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

28. VPN als eigene Fehlerdomäne behandeln

Ein VPN verändert möglicherweise:

Vergleichstests

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

Typische VPN-Probleme

29. MTU- und Fragmentierungsprobleme

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

Mögliche Symptome sind:

Mögliche Ursachen:

Windows – Beispieltest

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

Linux – Beispieltest

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

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

30. Mehrere aktive Netzwerkadapter

Ein Client kann gleichzeitig verbunden sein über:

Dadurch können entstehen:

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:

Beispiel

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

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

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

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

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

32. Paketaufzeichnung gezielt einsetzen

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

Geeignete Werkzeuge sind beispielsweise:

Mögliche Fragestellungen

Beispielhafte Filter

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

Datenschutz und Sicherheit

Paketaufzeichnungen können enthalten:

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

33. Typische TCP-Beobachtungen

Erfolgreicher Verbindungsaufbau

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

Port geschlossen

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

Keine sichtbare Antwort

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

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

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:

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

Zeitbezug

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

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

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

Symptom

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

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

Symptom

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

37. Praxisfall C: Website antwortet nicht, Ping funktioniert

Symptom

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

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

39. Praxisfall E: Interne Systeme funktionieren nur ohne VPN

Symptom

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:

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

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

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

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

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

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

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

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

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

44. Checkliste Client ohne Netzwerkverbindung

45. Schnellreferenz

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

Merksatz

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

Quellen und weiterführende Dokumentation

6. Netzwerk- und Verbindungsfehler

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:

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:

Bei mehreren gleichzeitig betroffenen Clients werden gemeinsame Ursachen wahrscheinlicher:

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:

Eine belastbare Aussage lautet beispielsweise:

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

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

3. Betroffenheitsmatrix erstellen

Eine einfache Matrix hilft, Gemeinsamkeiten zu erkennen.

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

Aus diesem Beispiel ergibt sich:

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:

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:

Zu jeder Änderung gehören:

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:

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:

Eine Statusmeldung sollte enthalten:

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

Beginn:
Etwa 09:17 Uhr.

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

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

Nicht bestätigt werden sollten Aussagen wie:

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:

Beispiel

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

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

9. Gemeinsame Abhängigkeiten abbilden

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

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

Für WLAN kann der Weg abweichen:

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

Für jeden Abschnitt wird geprüft:

10. Ausfallbereich durch funktionierende Grenzen bestimmen

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

Beispiel

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

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

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:

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

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:

Mögliche Hinweise:

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:

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

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

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

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

Zu prüfen sind:

Typische Fehler

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:

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:

Zu prüfen sind:

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.

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

Zu prüfen sind:

Mögliche Symptome:

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

Das Gateway eines VLANs kann physisch oder logisch ausgefallen sein.

Zu prüfen sind:

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:

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:

Zu prüfen sind:

DHCP-Ablauf

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

Mögliche Beobachtungen

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

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

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

Typische Beobachtungen:

Zu prüfen sind:

Windows

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

Linux und macOS

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

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

21. Netzwerkzugangskontrolle und Authentifizierung

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

Mögliche Komponenten:

Mögliche Symptome:

Zu prüfen sind:

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:

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:

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:

Mögliche Beobachtungen

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:

Zu prüfen sind:

Abgrenzung

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

Dies spricht eher für:

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:

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:

Mögliche Fehlerbilder

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:

Mögliche Hinweise:

Die verursachende Quelle sollte anhand von:

eingegrenzt werden.

29. Monitoringdaten auswerten

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

Relevante Messwerte:

Beispielhafte Ereignisfolge

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:

30. Protokolle zeitlich korrelieren

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

Relevante Quellen:

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

Beispiel

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

Diese Kombination ist aussagekräftiger als ein einzelner Clientfehler.

31. Paketaufzeichnung an geeigneten Punkten

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

Mögliche Aufzeichnungspunkte:

Mögliche Fragestellungen:

Beispielhafte Wireshark-Filter

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

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

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

32. Änderungen kontrolliert zurücknehmen

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

Vor dem Rollback sind zu klären:

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:

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

34. Praxisfall A: Gesamte Etage ohne kabelgebundenes Netzwerk

Symptom

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

35. Praxisfall B: Ganzer Standort erreicht zentrale Systeme nicht

Symptom

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

36. Praxisfall C: Neue Clients erhalten kein Netzwerk

Symptom

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

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

Symptom

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

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

Symptom

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

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

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

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

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

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

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

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

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

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

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

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

43. Schnellreferenz

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

Merksatz

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

Quellen und weiterführende Dokumentation

6. Netzwerk- und Verbindungsfehler

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 Aussage „IP geht, Name geht nicht“ grenzt den Fehlerbereich ein. Sie beweist aber noch nicht, dass ausschließlich der DNS-Server defekt ist.

1. Technischer Zusammenhang

Anwendungen verwenden häufig Namen statt IP-Adressen.

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

Beispiel:

intranet.example.test → 192.0.2.40

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

2. Fehlerbild zuerst bestätigen

Die Benutzeraussage muss durch konkrete Tests bestätigt werden.

Zu dokumentieren sind:

Beispiel:

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

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

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

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

Windows

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

Linux und macOS

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

Danach wird derselbe Dienst über den Namen getestet.

Windows

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

Linux und macOS

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

Mögliche Einordnung

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

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

4. Vollständigen Namen verwenden

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

Beispiel:

Kurzname:
fileserver

Vollständiger Name:
fileserver.example.test

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

Windows

ipconfig /all
Get-DnsClientGlobalSetting
Get-DnsClient

Linux

cat /etc/resolv.conf
resolvectl status

macOS

scutil --dns

Zu prüfen sind:

5. Konfigurierte DNS-Server prüfen

Ein Client muss die vorgesehenen DNS-Server verwenden.

Windows

ipconfig /all
Get-DnsClientServerAddress

Linux

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

macOS

scutil --dns
networksetup -getdnsservers <netzwerkdienst>

Zu prüfen sind:

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

6. Jeden DNS-Server einzeln abfragen

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

Windows

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

Alternativ:

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

Linux und macOS

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

Beispielhafte Auswertung

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

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

7. Bedeutung häufiger DNS-Ergebnisse

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

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

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

8. Record-Typ gezielt prüfen

DNS enthält verschiedene Resource Records.

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

Windows

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

Linux und macOS

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

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

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

9. DNS-Transport und Port 53 prüfen

DNS verwendet grundsätzlich:

UDP 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:

Windows

Test-NetConnection <dns-server> -Port 53

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

Linux und macOS

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

Mögliche Beobachtungen

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

10. Lokalen DNS-Cache prüfen

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

Mögliche Symptome:

Windows

ipconfig /displaydns
Clear-DnsClientCache

Alternativ:

ipconfig /flushdns

Linux mit systemd-resolved

resolvectl statistics
sudo resolvectl flush-caches

macOS

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

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

11. Hosts-Datei berücksichtigen

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

Windows

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

Linux und macOS

/etc/hosts

Zu prüfen sind:

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:

Windows-DNS-Server

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

Allgemeine Abfragen

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

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

13. Rekursion und Weiterleitungen prüfen

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

Mögliche Fehlerbilder:

Abgrenzung

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

14. Split-DNS berücksichtigen

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

Beispiel:

intern:
portal.example.test → 192.0.2.50

extern:
portal.example.test → 198.51.100.50

Zu prüfen sind:

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:

Zu prüfen sind:

Windows

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

Linux

ip address
ip route
resolvectl status

macOS

ifconfig
netstat -rn
scutil --dns

16. IPv4 und IPv6 getrennt betrachten

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

Mögliche Fehlerbilder:

Zu prüfen sind:

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

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

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

17. DNSSEC prüfen

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

Mögliche Ursachen:

Linux und macOS mit dig

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

Bei DNSSEC-Problemen sollten geprüft werden:

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:

Zu prüfen sind:

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:

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

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

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

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

20. Reverse DNS getrennt prüfen

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

Beispiel:

192.0.2.40 → fileserver.example.test

Windows

Resolve-DnsName <ip-adresse> -Type PTR

Linux und macOS

dig -x <ip-adresse>

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

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

21. Active Directory und DNS

Active Directory ist stark von DNS abhängig.

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

Benötigt werden unter anderem SRV-Records.

Beispielhafte Prüfung:

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

Zu prüfen sind:

22. Dynamische DNS-Registrierung

Clients und Server können ihre Records dynamisch registrieren.

Mögliche Fehlerbilder:

Windows-Client

ipconfig /registerdns

Vor der Verwendung ist zu prüfen:

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:

Sinnvoll sind wiederholte, zeitgestempelte Abfragen.

PowerShell

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

Bash

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

Zu vergleichen sind:

24. Paketaufzeichnung für DNS

Eine Paketaufzeichnung kann zeigen:

Wireshark-Filter

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

Typische Beobachtungen

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

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

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

Symptom

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

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

Symptom

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

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

Symptom

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

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

Symptom

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

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

Symptom

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

30. Ungeeignete Sofortmaßnahmen

Problematisch sind insbesondere:

Vor Änderungen sind zu sichern beziehungsweise zu dokumentieren:

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

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

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

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

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

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

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

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

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

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

33. Checkliste „Name geht nicht, IP geht“

34. Schnellreferenz

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

Merksatz

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

Quellen und weiterführende Dokumentation

6. Netzwerk- und Verbindungsfehler

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:

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

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

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

1. Fehlerbild exakt erfassen

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

Zu dokumentieren sind:

Beispiel:

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

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

2. Host-Erreichbarkeit und Dienst-Erreichbarkeit unterscheiden

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

Beispiel:

ping appserver.example.test

Ein erfolgreicher Ping kann bestätigen:

Er beweist nicht:

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:

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

4. Zieladresse und Zielport gemeinsam prüfen

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

192.0.2.50:443/TCP

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

Mögliche Fehler:

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

Windows

Resolve-DnsName <zielname>

Linux und macOS

dig <zielname>

5. TCP-Port vom Client aus testen

Windows

Test-NetConnection <zielname> -Port <port>

Kurzform:

tnc <zielname> -Port <port>

Beispiel:

Test-NetConnection appserver.example.test -Port 443

Wichtig ist insbesondere:

TcpTestSucceeded : True

oder:

TcpTestSucceeded : False

PowerShell 7

Test-Connection <zielname> -TcpPort <port>

Linux und macOS

nc -vz <zielname> <port>

Beispiel:

nc -vz appserver.example.test 443

Alternativ kann bei bestimmten Diensten ein protokollspezifischer Test sinnvoller sein:

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

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

6. TCP-Ergebnisse richtig einordnen

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

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

7. TCP-Verbindungsaufbau verstehen

Der normale TCP-Verbindungsaufbau verwendet drei Schritte:

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

Danach kann die Anwendungsübertragung beginnen.

Mögliche Abweichungen:

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

Diese Unterscheidung ist mit einer Paketaufzeichnung möglich.

8. UDP-Dienste getrennt betrachten

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

Beispiel:

nc -vzu <zielname> <port>

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

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

Beispiele:

DNS

dig @<dns-server> <name>

NTP

ntpdate -q <ntp-server>

Je nach System können andere Werkzeuge erforderlich sein.

Mögliche UDP-Ergebnisse:

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

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

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

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

Windows

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

Alternativ:

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

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

Get-Process -Id <prozess-id>

oder:

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

Linux

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

Alternativ:

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

macOS

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

Zu prüfen sind:

10. Bind-Adresse richtig bewerten

Ein Dienst kann auf unterschiedlichen Adressen lauschen.

Beispiele:

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

Typische Bedeutung:

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

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

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

11. Dienststatus und Protokolle prüfen

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

Windows

Get-Service
Get-Service -Name <dienstname>

Linux mit systemd

systemctl status <dienstname>
journalctl -u <dienstname>

macOS

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

Zu prüfen sind:

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

12. Dienst lokal auf dem Server testen

Der lokale Test trennt die Anwendung vom entfernten Netzwerkpfad.

Beispiele:

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

Oder:

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

Sinnvolle Vergleichstests:

  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:

Windows

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

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

Linux mit firewalld

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

Linux mit nftables

sudo nft list ruleset

Linux mit iptables

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

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

14. Client-Firewall und Ausgangsregeln

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

Mögliche Ursachen:

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

15. Netzwerk-Firewalls und ACLs

Zwischen Client und Server können mehrere Kontrollstellen liegen:

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

Zu prüfen sind:

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:

Typisches Symptom:

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

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

17. Routing und Rückweg prüfen

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

Windows

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

Linux

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

macOS

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

Zu prüfen sind:

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

18. NAT und Portweiterleitung

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

Beispiel:

öffentliche Adresse:
198.51.100.20:443

NAT-Ziel:
192.0.2.50:8443

Zu prüfen sind:

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:

Docker

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

Beispiel einer Portzuordnung:

0.0.0.0:8443 → Container:443/TCP

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

20. Reverse Proxy und Load Balancer

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

Client
  ↓
Reverse Proxy oder Load Balancer
  ↓
Backend-Anwendung

Mögliche Fehlerbilder:

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:

curl

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

OpenSSL

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

Dabei können geprüft werden:

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

22. Hostname, SNI und virtuelle Hosts

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

Beispiel:

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

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

Geeigneter Test:

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

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

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

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

23. Anwendung und Abhängigkeiten prüfen

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

Beispiele:

Mögliche Symptome:

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:

Beispiele:

Connection timed out

weist eher auf Transport oder fehlende Antwort hin.

401 Unauthorized

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

25. IPv4 und IPv6 getrennt prüfen

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

Windows

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

Linux und macOS

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

Mögliche Ursachen:

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:

Mögliche Ursachen:

Linux

tracepath <ziel>

Windows

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

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

27. Proxys und anwendungsspezifische Netzwerkwege

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

Mögliche Unterschiede:

Zu prüfen sind:

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:

Windows

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

Linux

ss -s
ss -ant

Wiederholte Tests sollten mit Zeitstempel durchgeführt werden.

PowerShell

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

Bash

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

Zu vergleichen sind:

29. Paketaufzeichnung einsetzen

Eine Paketaufzeichnung kann zeigen:

Wireshark-Filter

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

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

Typische Beobachtungen

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

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

30. Vergleichstests systematisch verwenden

Vergleichstests helfen, die fehlerhafte Grenze einzugrenzen.

Sinnvolle Vergleiche:

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

Dabei sollte jeweils nur eine Variable verändert werden.

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

Symptom

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

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

Symptom

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

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

Symptom

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

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

Symptom

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

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

Symptom

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

36. Ungeeignete Sofortmaßnahmen

Problematisch sind insbesondere:

Vor Änderungen sollten dokumentiert werden:

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

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

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

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

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

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

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

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

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

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

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

39. Checkliste „Host erreichbar, Dienst nicht“

40. Schnellreferenz

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

Merksatz

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

Quellen und weiterführende Dokumentation

6. Netzwerk- und Verbindungsfehler

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

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

Typische Aussagen wie:

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

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

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

2. Langsamkeit exakt beschreiben

Vor jeder technischen Änderung sind folgende Fragen zu beantworten:

Eine geeignete Ausgangsbeschreibung lautet beispielsweise:

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

Diese Beschreibung ist wesentlich aussagekräftiger als:

Das Netzwerk ist langsam.

3. Latenz, Durchsatz und Anwendungsdauer nicht gleichsetzen

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

Beispiele:

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:

Windows

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

Linux

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

macOS

top
vm_stat
iostat -w 1
netstat -ib

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

6. Verbindungstyp und ausgehandelten Link prüfen

Bei Ethernet sind insbesondere zu prüfen:

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

Windows

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

Weitere Eigenschaften:

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

Linux

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

macOS

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

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

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

7. Schnittstellenzähler richtig auswerten

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

Beispiel:

Zeitpunkt A:
CRC-Fehler: 12
Drops:      41

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

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

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

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

8. Latenz zunächst kontrolliert messen

Windows

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

Linux

ping -c 20 <ziel>

macOS

ping -c 20 <ziel>

Sinnvolle Ziele für getrennte Messungen:

  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:

Windows

ping <ziel> -n 100
pathping <ziel>

Linux

ping -c 100 <ziel>
mtr <ziel>

macOS

ping -c 100 <ziel>
traceroute <ziel>

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

Bedeutsamer ist ein Verlust, wenn:

10. Pfad und Richtungsunterschiede untersuchen

Windows

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

Linux

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

macOS

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

Zu prüfen sind:

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

11. Durchsatz mit einer kontrollierten Gegenstelle messen

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

Server starten

iperf3 -s

Clienttest

iperf3 -c <server-ip>

Gegenrichtung testen

iperf3 -c <server-ip> -R

Längerer Test

iperf3 -c <server-ip> -t 30

Mehrere parallele Datenströme

iperf3 -c <server-ip> -P 4

UDP-Test mit kontrollierter Zielrate

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

Dabei sind zu dokumentieren:

Wichtige Einschränkungen:

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:

Sinnvolle Vergleichstests:

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:

Windows

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

Linux

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

macOS

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

Wichtige Vergleichstests:

  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:

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

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

Mögliche Ursachen:

Zu vergleichen sind:

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:

Zu prüfen sind beide Linkpartner:

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

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

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

16. MTU und Fragmentierung prüfen

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

Typische Symptome:

Windows

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

Linux

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

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

Zu prüfen sind:

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:

Wireshark-Filter

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

Mögliche Einordnung:

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

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

18. Paketaufzeichnung an mehreren Punkten

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

Geeignete Punkte:

Zu prüfen sind:

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

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

oder:

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

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

19. IPv4 und IPv6 getrennt vergleichen

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

Windows

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

Linux und macOS

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

Mögliche Ursachen:

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

20. DNS, Proxy, TLS und Anwendungslatenz abgrenzen

DNS-Zeit prüfen

dig <zielname>

Mit curl können einzelne Zeitabschnitte gemessen werden:

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

Bedeutung:

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

Mögliche Einordnung:

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:

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:

Zu prüfen sind:

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:

Typisches Muster:

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

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

24. Virtualisierung und Container

Zusätzliche Ursachen bei virtuellen Systemen:

Die Prüfung sollte folgende Ebenen unterscheiden:

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

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

25. Sporadische Langsamkeit erfassen

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

PowerShell

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

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

Bash

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

Zusätzlich zu erfassen sind:

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

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

27. Praxisfall B: WLAN langsam, Ethernet normal

Symptom

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

28. Praxisfall C: Download schnell, Upload langsam

Symptom

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

29. Praxisfall D: Netzwerk normal, Anwendung langsam

Symptom

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

30. Praxisfall E: Über VPN funktionieren kleine Anfragen, große Übertragungen brechen ein

Symptom

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

31. Ungeeignete Sofortmaßnahmen

Problematisch sind insbesondere:

Vor Änderungen sollten mindestens dokumentiert werden:

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

Ticket: INC-20718
Beginn: 02.08.2026, etwa 09:20 Uhr
Umfang: mehrere WLAN-Clients im VLAN 30
Nicht betroffen: kabelgebundene Clients im VLAN 20
Ziel: interner Dateiserver fileserver.example.test

Symptom:
Dateiübertragungen über WLAN erreichen nur etwa 8 bis 15 Mbit/s.
Kabelgebundene Vergleichsclients erreichen zum selben Server etwa
700 Mbit/s. Kleine Webanfragen und DNS-Auflösungen funktionieren.

Ausgangszustand:
- DNS-Auflösung korrekt
- Server per TCP erreichbar
- Dateiserver für Ethernet-Clients normal
- Serverressourcen unauffällig
- Access-Point-Uplink mit 1 Gbit/s aktiv
- keine steigenden CRC-Fehler am Uplink
- hohe Kanalauslastung im verwendeten Frequenzbereich
- erhöhte WLAN-Wiederholungsrate
- Latenz zum Gateway steigt unter Last deutlich

Hypothese:
Die Funkzelle besitzt zu wenig freie Airtime. Der Datenverkehr wird
wiederholt übertragen und wartet auf den Zugriff auf das Funkmedium.

Prüfung:
- Ethernet und WLAN mit demselben Ziel verglichen
- mehrere WLAN-Clients getestet
- Signalstärke und Kanal erfasst
- Uplink und Server als Engpass ausgeschlossen
- kontrollierter Durchsatztest in beide Richtungen durchgeführt
- Access-Point-Statistiken zum Störungszeitpunkt ausgewertet

Ursache:
Starke Kanalbelegung und überlappende Funkzellen führten zu einer
hohen Wiederholungsrate und geringer nutzbarer Airtime.

Maßnahme:
Die Kanalplanung der betroffenen Funkzellen wurde nach einer
Funkumgebungsanalyse kontrolliert angepasst.

Nachprüfung:
- Latenz zum Gateway unter Last verbessert
- Wiederholungsrate gesunken
- kontrollierter WLAN-Durchsatz deutlich erhöht
- ursprüngliche Dateiübertragung funktioniert
- Ethernet-Clients weiterhin fehlerfrei
- benachbarte Funkzellen kontrolliert

Prävention:
- Kanalauslastung und Wiederholungsrate überwachen
- WLAN-Baseline pro Standort dokumentieren
- Funkumgebung nach größeren Änderungen erneut prüfen

34. Checkliste „Netzwerk ist langsam“

35. Schnellreferenz

Fehlerbild wahrscheinlicher Untersuchungsbereich
nur ein Client langsam Client, Kabel, Adapter, Treiber oder Switchport
alle Clients eines Switches langsam Uplink, Switch, VLAN oder gemeinsame Gegenstelle
nur WLAN langsam Funkumgebung, Airtime, Kanal, AP oder Client
Ethernet und WLAN langsam Gateway, Uplink, Firewall, WAN, Server oder Anwendung
nur ein Server langsam Zielserver, Servernetz, Datenträger oder Anwendung
alle externen Ziele langsam WAN, Provider, Firewall, Proxy oder VPN
nur Upload langsam Upstream, Queue, Policing, Provider oder VPN
nur Download langsam Downstream, Server, TCP, Proxy oder Client
Latenz steigt nur unter Last Queue, Auslastung, Bufferbloat oder Drops
Ping normal, Dateiübertragung langsam Durchsatz, Datenträger, Protokoll oder Anwendung
Durchsatztest normal, Anwendung langsam DNS, TLS, Proxy, Backend, Datenbank oder Server
Link nur mit 100 Mbit/s Kabel, Adapter, Switchport oder Aushandlung
steigende CRC-/FCS-Fehler physischer Link, Kabel, Transceiver oder Port
steigende Drops ohne CRC-Fehler Queue, Überlastung, Policing oder Puffer
viele TCP-Retransmissions Paketverlust, Überlastung oder Datenpfad
TCP Zero Window Empfänger verarbeitet Daten zu langsam
kleine Pakete funktionieren, große nicht MTU, Tunnel oder Fragmentierung
nur über VPN langsam Tunnel, MTU, Gateway, Verschlüsselung oder Route
nur IPv6 langsam IPv6-Pfad, Firewall, Route oder Zieladresse
nur IPv4 langsam IPv4-Pfad, NAT, Firewall oder Route
nur zu bestimmten Zeiten langsam Last, Backup, Scan, Job, Provider oder Funkumgebung
ein TCP-Stream langsam, mehrere schneller Latenz, Fenster, Verlust oder Serverbegrenzung
WLAN-Signal gut, Durchsatz schlecht Kanalauslastung, Airtime, Störung oder Wiederholungen
erstes Byte langsam Anwendung, Proxy, Backend oder Datenbank
erstes Byte schnell, Download langsam Durchsatz, Verlust, Serverausgabe oder Client
lokale Ziele schnell, Internet langsam WAN, Provider, NAT, Firewall oder Proxy
Gateway bereits langsam lokaler Link, WLAN, Client oder erstes Netzsegment

Merksatz

„Langsam“ ist keine eindeutige Fehlerursache. Eine belastbare Analyse trennt Latenz, Paketverlust, Jitter und Durchsatz, vergleicht funktionierende und betroffene Pfade und prüft anschließend Client, Link, WLAN, Switch, Firewall, WAN, Server und Anwendung. Erst reproduzierbare Messwerte vor und nach einer kontrollierten Änderung belegen eine Verbesserung.

Quellen und weiterführende Dokumentation

6. Netzwerk- und Verbindungsfehler

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:

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:

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:

3. Auswirkungen bestimmen

Vor der technischen Untersuchung muss der Umfang eingegrenzt werden.

Zu klären ist:

Eine Beobachtung wie „Das Netzwerk war kurz weg“ ist noch keine ausreichende Fehlerbeschreibung.

4. Fehlerzeitpunkt exakt erfassen

Der wichtigste Ausgangspunkt ist ein möglichst genauer Zeitstempel.

Ungeeignet:

Der Fehler war heute Morgen.

Besser:

02.08.2026 zwischen 09:14:20 und 09:15:05 Uhr

Noch besser:

02.08.2026, 09:14:37 Uhr:
Beim Öffnen von \\fileserver.example.test\projekte erschien nach etwa
30 Sekunden die Meldung „Der Netzwerkname wurde nicht gefunden“.

09:15:05 Uhr:
Ein erneuter Versuch war erfolgreich.

Zusätzlich zu dokumentieren:

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:

Windows

Get-Date
Get-TimeZone
w32tm /query /status
w32tm /query /source
w32tm /query /configuration

Linux

date --iso-8601=seconds
timedatectl status
timedatectl timesync-status

macOS

date
systemsetup -gettimezone
systemsetup -getusingnetworktime
systemsetup -getnetworktimeserver

Ein Zeitunterschied von mehreren Minuten kann dazu führen, dass zusammengehörige Ereignisse in Client-, Server-, Firewall- und Netzwerkprotokollen nicht erkannt werden.

Die Uhrzeit darf nicht unkontrolliert verändert werden. In Domänen, Clustern, Datenbanken und authentifizierten Umgebungen können Zeitsprünge zusätzliche Fehler verursachen.

6. Fehlermeldung vollständig sichern

Zu erfassen sind:

Beispiel:

Ungeeignet:
„VPN ging nicht.“

Geeignet:
„Am 02.08.2026 um 11:42:18 Uhr brach die bestehende VPN-Verbindung
nach ungefähr 27 Minuten Laufzeit ab. Der Client meldete Fehlercode
809. Der lokale Internetzugang funktionierte währenddessen weiter.
Die erneute VPN-Verbindung war um 11:43:02 Uhr erfolgreich.“

Die originale Meldung darf nicht nur sinngemäß wiedergegeben werden.

7. Muster suchen

Sporadische Fehler sollten nach wiederkehrenden Merkmalen untersucht werden.

Muster möglicher Untersuchungsbereich
immer zur gleichen Uhrzeit Backup, Scan, Update, Wartungsjob oder Provider
nach längerer Inaktivität Idle-Timeout, Energiesparmodus oder Sitzung
nach Ablauf einer festen Dauer Lease, Token, Session, NAT, Firewall oder VPN-Rekeying
nur unter Last Ressourcen, Queue, Uplink, Storage oder Connection Pool
nur montags oder nach dem Wochenende Lease, Kennwort, Zertifikat, Patch oder Neustart
nur bei einem Benutzer Benutzerprofil, Berechtigung, Token oder Endgerät
nur bei einem Client Hardware, Treiber, Kabel, WLAN oder lokale Software
nur an einem Standort WAN, WLAN, Switch, Strom oder Provider
nur bei WLAN Interferenz, Roaming, Airtime oder Access Point
nur bei VPN Tunnel, Gateway, MTU, Rekeying oder Route
nach Aufwachen des Clients Treiber, DHCP, DNS, VPN oder Energiesparmodus
nach Konfigurationsänderung fehlerhafte Änderung oder Abhängigkeit
alle 30 oder 60 Minuten geplanter Timer, Lease, Token, Job oder Polling
bei hoher Raumtemperatur Kühlung, Transceiver, Netzteil oder Hardware
bei Regen oder Wind Außenleitung, Funkstrecke, Strom oder Providerpfad

Eine zeitliche Übereinstimmung ist zunächst nur eine Korrelation und noch kein Beweis für die Ursache.

8. Kontinuierliche Erreichbarkeitsmessung unter Windows

Ein einfacher protokollierter Test kann prüfen, ob ein Ziel zum Störungszeitpunkt erreichbar war.

$Target = "<ziel>"
$LogFile = ".\availability.csv"

"Time,Target,Status,LatencyMs" | Set-Content -Path $LogFile

while ($true) {
    $Time = Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK"
    $Result = Test-Connection -TargetName $Target -Count 1 -ErrorAction SilentlyContinue

    if ($Result) {
        "$Time,$Target,Success,$($Result.Latency)" |
            Add-Content -Path $LogFile
    }
    else {
        "$Time,$Target,Failure," |
            Add-Content -Path $LogFile
    }

    Start-Sleep -Seconds 5
}

Vor dem Einsatz ist zu prüfen, welche Eigenschaften Test-Connection in der verwendeten PowerShell-Version zurückgibt.

Beenden:

[CTRL] + [C]

Die Messung zeigt nur die ICMP-Erreichbarkeit des gewählten Ziels. Sie beweist nicht, dass DNS, TCP, TLS oder die Anwendung funktioniert haben.

9. Kontinuierliche Erreichbarkeitsmessung unter Linux und macOS

target="<ziel>"
logfile="./availability.log"

while true; do
    printf '%s ' "$(date '+%Y-%m-%dT%H:%M:%S%z')" >> "$logfile"

    if ping -c 1 -W 2 "$target" >> "$logfile" 2>&1; then
        printf 'STATUS=SUCCESS\n' >> "$logfile"
    else
        printf 'STATUS=FAILURE\n' >> "$logfile"
    fi

    sleep 5
done

Je nach Betriebssystem unterscheiden sich die Optionen und die Einheit des Ping-Timeouts. Der konkrete Befehl muss auf dem Zielsystem geprüft werden.

Beenden:

[CTRL] + [C]

Sinnvolle parallele Ziele:

  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

$Target = "<ziel>"
$Port = <port>
$LogFile = ".\tcp-check.csv"

"Time,Target,Port,Success" | Set-Content -Path $LogFile

while ($true) {
    $Time = Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK"
    $Result = Test-NetConnection -ComputerName $Target -Port $Port `
        -InformationLevel Quiet

    "$Time,$Target,$Port,$Result" |
        Add-Content -Path $LogFile

    Start-Sleep -Seconds 10
}

Linux und macOS

while true; do
    timestamp="$(date '+%Y-%m-%dT%H:%M:%S%z')"

    if nc -z -w 3 <ziel> <port>; then
        printf '%s TARGET=%s PORT=%s STATUS=SUCCESS\n' \
            "$timestamp" "<ziel>" "<port>"
    else
        printf '%s TARGET=%s PORT=%s STATUS=FAILURE\n' \
            "$timestamp" "<ziel>" "<port>"
    fi

    sleep 10
done >> tcp-check.log 2>&1

Ein erfolgreicher TCP-Verbindungsaufbau beweist noch nicht, dass Anmeldung, Datenbank, Backend oder vollständiger Geschäftsprozess funktionieren.

11. DNS kontinuierlich prüfen

Sporadische Namensauflösungsfehler können durch einen einzelnen Ping auf eine IP-Adresse übersehen werden.

Windows

$Name = "<zielname>"
$LogFile = ".\dns-check.log"

while ($true) {
    $Time = Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK"
    "===== $Time =====" | Add-Content -Path $LogFile

    Resolve-DnsName -Name $Name -ErrorAction Continue |
        Out-String |
        Add-Content -Path $LogFile

    Start-Sleep -Seconds 30
}

Linux und macOS

while true; do
    printf '===== %s =====\n' "$(date '+%Y-%m-%dT%H:%M:%S%z')"
    dig <zielname>
    sleep 30
done >> dns-check.log 2>&1

Zu vergleichen sind:

Ein absichtlich wechselnder DNS-Eintrag, beispielsweise bei einem Load Balancer, darf nicht automatisch als Fehler bewertet werden.

12. HTTP- und Anwendungszeiten aufzeichnen

Für HTTP- oder HTTPS-Dienste kann curl einzelne Zeitabschnitte protokollieren.

while true; do
    timestamp="$(date '+%Y-%m-%dT%H:%M:%S%z')"

    result="$(curl -sS -o /dev/null \
      --connect-timeout 10 \
      --max-time 30 \
      -w 'code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}' \
      https://<zielname>/ 2>&1)"

    printf '%s %s\n' "$timestamp" "$result"
    sleep 30
done >> http-check.log

Mögliche Einordnung:

Beobachtung möglicher Bereich
DNS-Zeit erhöht Resolver oder DNS-Pfad
TCP-Aufbau erhöht Netzwerkpfad, Paketverlust oder Ziel
TLS-Zeit erhöht Zertifikatsprüfung, Inspection oder Server
erstes Byte verspätet Anwendung, Proxy, Backend oder Datenbank
Gesamtzeit erhöht Übertragung, Durchsatz, Server oder Client
wechselnde Ziel-IP mit Fehler nur bei einer IP Load Balancer oder einzelner Backend-Pfad
HTTP-Fehlercode Anwendung, Proxy, Authentifizierung oder Backend

Die Abfrage muss auf einen ungefährlichen und autorisierten Endpunkt begrenzt werden.

13. Interfacezustand und Fehlerzähler regelmäßig erfassen

Sporadische Linkfehler sind häufig nur als kurzzeitiger Statuswechsel oder steigender Fehlerzähler sichtbar.

Windows

$LogFile = ".\adapter-statistics.csv"

while ($true) {
    $Time = Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK"

    Get-NetAdapterStatistics |
        Select-Object @{
            Name = "Time"
            Expression = { $Time }
        }, Name, ReceivedBytes, SentBytes,
           ReceivedUnicastPackets, SentUnicastPackets,
           ReceivedDiscardedPackets, OutboundDiscardedPackets,
           ReceivedPacketErrors, OutboundPacketErrors |
        Export-Csv -Path $LogFile -Append -NoTypeInformation

    Start-Sleep -Seconds 30
}

Linux

while true; do
    printf '===== %s =====\n' "$(date '+%Y-%m-%dT%H:%M:%S%z')"
    ip -s link show dev <interface>
    ethtool <interface>
    ethtool -S <interface>
    sleep 30
done >> interface-check.log 2>&1

macOS

while true; do
    printf '===== %s =====\n' "$(date '+%Y-%m-%dT%H:%M:%S%z')"
    ifconfig <interface>
    netstat -ib
    sleep 30
done >> interface-check.log 2>&1

Zu beobachten sind insbesondere:

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:

Die Befehle und Zählerbezeichnungen unterscheiden sich je nach Hersteller und Modell. Ihre genaue Bedeutung muss anhand der jeweiligen Herstellerdokumentation geprüft werden.

15. Ereignisprotokolle unter Windows zeitlich eingrenzen

Beispiel für Systemereignisse eines bestimmten Zeitraums:

$Start = Get-Date "2026-08-02 09:10:00"
$End = Get-Date "2026-08-02 09:20:00"

Get-WinEvent -FilterHashtable @{
    LogName   = "System"
    StartTime = $Start
    EndTime   = $End
} |
    Select-Object TimeCreated, Id, LevelDisplayName,
                  ProviderName, Message |
    Sort-Object TimeCreated

Mehrere Protokolle können getrennt untersucht werden:

$Logs = @(
    "System",
    "Application",
    "Microsoft-Windows-DNS-Client/Operational",
    "Microsoft-Windows-WLAN-AutoConfig/Operational"
)

foreach ($Log in $Logs) {
    Get-WinEvent -FilterHashtable @{
        LogName   = $Log
        StartTime = $Start
        EndTime   = $End
    } -ErrorAction SilentlyContinue |
        Select-Object @{
            Name = "Log"
            Expression = { $Log }
        }, TimeCreated, Id, ProviderName, LevelDisplayName, Message
}

Nicht jedes Protokoll ist auf jedem System vorhanden oder aktiviert. Zusätzliche Protokollierung sollte kontrolliert und mit Blick auf Speicherbedarf, Datenschutz und Systemlast aktiviert werden.

16. Protokolle unter Linux zeitlich eingrenzen

journalctl \
  --since "2026-08-02 09:10:00" \
  --until "2026-08-02 09:20:00"

Nur Meldungen eines Dienstes:

journalctl \
  -u <dienst>.service \
  --since "2026-08-02 09:10:00" \
  --until "2026-08-02 09:20:00"

Kernelmeldungen:

journalctl \
  -k \
  --since "2026-08-02 09:10:00" \
  --until "2026-08-02 09:20:00"

Neue Meldungen fortlaufend beobachten:

journalctl -f

Zu berücksichtigen sind:

Ein fehlender Eintrag beweist nicht automatisch, dass kein Fehler aufgetreten ist. Das Ereignis kann außerhalb der Aufbewahrungszeit liegen, in einem anderen Protokoll stehen oder nicht protokolliert worden sein.

17. Protokolle unter macOS zeitlich eingrenzen

log show \
  --start "2026-08-02 09:10:00" \
  --end "2026-08-02 09:20:00" \
  --style syslog

Nach Prozess filtern:

log show \
  --start "2026-08-02 09:10:00" \
  --end "2026-08-02 09:20:00" \
  --predicate 'process == "<prozess>"' \
  --style syslog

Fortlaufende Beobachtung:

log stream --style syslog

Die genaue Syntax und die verfügbaren Protokolldaten können sich zwischen macOS-Versionen unterscheiden.

18. Ringpuffer-Paketmitschnitt mit Dumpcap

Ein Ringpuffer bewahrt nur die letzten Aufzeichnungsdateien auf. Wenn der Fehler auftritt, muss die Aufzeichnung zeitnah gestoppt werden, bevor die relevanten Daten überschrieben werden.

Interfaces anzeigen:

dumpcap -D

Beispiel:

dumpcap \
  -i <interface> \
  -w intermittent.pcapng \
  -b duration:300 \
  -b files:12

Dieses Beispiel:

Alternative Begrenzung nach Dateigröße:

dumpcap \
  -i <interface> \
  -w intermittent.pcapng \
  -b filesize:100000 \
  -b files:10

Hierbei ist filesize in Kilobyte angegeben.

Optionaler Capture-Filter:

dumpcap \
  -i <interface> \
  -f "host <ziel-ip> and port <port>" \
  -w intermittent.pcapng \
  -b duration:300 \
  -b files:12

Capture-Filter und Wireshark-Anzeigefilter besitzen unterschiedliche Syntax. Ein zu enger Filter kann die für die Ursachenanalyse benötigten Pakete ausschließen.

19. Ringpuffer-Paketmitschnitt mit tcpdump

tcpdump \
  -i <interface> \
  -s 0 \
  -G 300 \
  -W 12 \
  -w 'intermittent-%Y%m%d-%H%M%S.pcap'

Möglicher Filter:

tcpdump \
  -i <interface> \
  -s 0 \
  -G 300 \
  -W 12 \
  -w 'intermittent-%Y%m%d-%H%M%S.pcap' \
  'host <ziel-ip> and port <port>'

Die Kombination und genaue Wirkung der Rotationsoptionen kann von der installierten tcpdump-Version abhängen und muss vor dem produktiven Einsatz mit der lokalen Handbuchseite geprüft werden:

man tcpdump

Paketaufzeichnungen können personenbezogene Daten, Anmeldedaten, Sitzungsinformationen und vertrauliche Inhalte enthalten. Sie dürfen nur mit entsprechender Berechtigung erstellt, geschützt gespeichert und nach Abschluss kontrolliert gelöscht werden.

20. Windows-Paketmitschnitt mit Pktmon

Filter anzeigen:

pktmon filter list

Vorhandene Filter entfernen:

pktmon filter remove

Beispiel für eine begrenzte zirkuläre Aufzeichnung:

pktmon start `
  --capture `
  --comp nics `
  --pkt-size 0 `
  --file-name C:\Temp\intermittent.etl `
  --file-size 512 `
  --log-mode circular

Aufzeichnung stoppen:

pktmon stop

In PCAPNG umwandeln:

pktmon etl2pcap `
  C:\Temp\intermittent.etl `
  --out C:\Temp\intermittent.pcapng

Im zirkulären Modus werden bei Erreichen der festgelegten Größe ältere Ereignisse überschrieben. Die Aufzeichnung muss daher nach Auftreten des Fehlers zeitnah gestoppt werden.

Die verfügbaren Optionen unterscheiden sich zwischen Windows-Versionen. Vor dem Einsatz ist die lokale Hilfe zu prüfen:

pktmon start help
pktmon etl2pcap help

21. Monitoringauflösung passend wählen

Ein Monitoringintervall von fünf Minuten kann einen Fehler übersehen, der nur 20 Sekunden dauert.

Beispiel:

09:10:00 Messung erfolgreich
09:12:15 Fehler beginnt
09:12:40 Fehler endet
09:15:00 Messung erfolgreich

Das Monitoring zeigt keinen Ausfall, obwohl der Dienst 25 Sekunden nicht verfügbar war.

Mögliche Maßnahmen:

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

Switch und Router

Firewall und VPN

Server

WLAN

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:

Beispiel:

Fehlerabstand: ungefähr 60 Minuten
Sitzungs-Timeout: 60 Minuten

Diese Übereinstimmung begründet eine Hypothese, beweist sie aber noch nicht. Der tatsächliche Ablauf und die anschließende Erneuerung müssen in Protokollen oder Paketdaten bestätigt werden.

24. Geplante Jobs und Wartungsarbeiten korrelieren

Zu untersuchen sind:

Windows

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

Letzte und nächste Ausführung:

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

Linux

systemctl list-timers --all

Zusätzlich können je nach System Cron-Konfigurationen und deren Protokolle relevant sein.

Nur autorisierte Konfigurationen dürfen eingesehen werden. Aufgaben sollten nicht allein wegen einer zeitlichen Überschneidung deaktiviert werden.

25. Temperatur, Strom und physische Umgebung berücksichtigen

Kurzzeitige Ausfälle können durch physische Bedingungen verursacht werden.

Zu prüfen sind:

Typisches Muster:

Hohe Last
→ Temperatur steigt
→ Schnittstelle oder Gerät fällt kurzzeitig aus
→ automatische Wiederherstellung
→ Untersuchung erfolgt später bei normaler Temperatur

Ein Neustart kann Temperatur-, Speicher- und Fehlerzustände zurücksetzen und dadurch wichtige Beweise beseitigen.

26. Änderungen und Deployments berücksichtigen

Zu dokumentieren sind:

Mögliche Änderungen:

„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:

Zeitangaben müssen auf dieselbe Zeitzone oder eine eindeutig dokumentierte Referenz umgerechnet werden.

28. Ereignisgesteuerte Datensicherung

Wenn der Benutzer den Fehler bemerkt, sollte ein festgelegtes Verfahren ausgelöst werden.

Beispiel:

1. genaue Uhrzeit notieren;
2. Screenshot erstellen;
3. betroffene Aktion nicht mehrfach unkontrolliert wiederholen;
4. Diagnosemarkierung oder Ticket auslösen;
5. laufenden Ringpuffer zeitnah stoppen;
6. Clientzustand sichern;
7. relevante Server- und Netzwerkprotokolle exportieren;
8. Monitoringdaten für den Zeitraum schützen;
9. Vergleichssystem prüfen;
10. Dateien eindeutig beschriften.

Beispiel für eine Markierungsdatei unter PowerShell:

$Time = Get-Date -Format "yyyy-MM-ddTHH-mm-ss.fffK"
"Fehler durch Benutzer beobachtet: $Time" |
    Set-Content ".\incident-marker-$Time.txt"

Beispiel unter Bash:

timestamp="$(date '+%Y-%m-%dT%H-%M-%S%z')"
printf 'Fehler durch Benutzer beobachtet: %s\n' "$timestamp" \
  > "incident-marker-$timestamp.txt"

Der Marker liefert keine Ursache, erleichtert aber das Auffinden des relevanten Zeitraums.

29. Praxisfall A: Verbindung bricht ungefähr jede Stunde ab

Symptom

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

30. Praxisfall B: Switchport fällt kurzzeitig aus

Symptom

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

31. Praxisfall C: Dienst jeden Morgen kurz langsam

Symptom

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

32. Praxisfall D: WLAN-Unterbrechung nur beim Standortwechsel

Symptom

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

33. Ungeeignete Sofortmaßnahmen

Problematisch sind insbesondere:

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

Ticket: INC-20804
Zeitraum der Untersuchung: 02.08.2026 bis 05.08.2026
Betroffen: Client-WS-17, Ethernet, Switch SW-F2-03, Port 18
Nicht betroffen: weitere Clients desselben VLANs
Ziel: fileserver.example.test, TCP 445

Symptom:
Der Client verliert ein- bis dreimal täglich für ungefähr 5 bis 15 Sekunden
den Zugriff auf den Dateiserver. Anschließend funktioniert der Zugriff ohne
Benutzeraktion wieder.

Erfasste Fehlerzeitpunkte:
- 02.08.2026, 10:17:42 bis 10:17:51 Uhr
- 03.08.2026, 14:32:08 bis 14:32:19 Uhr
- 05.08.2026, 09:06:14 bis 09:06:23 Uhr

Messungen:
- kontinuierlicher Ping zu Gateway und Dateiserver
- TCP-Prüfung auf Port 445
- Interfacezähler des Clients
- Switchportstatus und Fehlerzähler
- Windows-Systemereignisse
- begrenzter Ringpuffer-Paketmitschnitt
- Serverressourcen und SMB-Protokolle

Beobachtung:
Zum jeweiligen Fehlerzeitpunkt meldete der Switch einen kurzen Linkverlust
an Port 18. Gleichzeitig wechselte das Clientinterface in den Zustand
„Disconnected“. Gateway und Server waren für andere Clients erreichbar.
Am Switchport stiegen zusätzlich die physischen Fehlerzähler.

Hypothese:
Die physische Verbindung zwischen Client und Switch ist instabil.

Kontrollierte Änderung:
Das Patchkabel wurde durch ein geprüftes Kabel ersetzt. Client, Switchport,
Treiber und Serverkonfiguration blieben unverändert.

Nachprüfung:
- sieben Tage kontinuierliche Beobachtung
- keine weiteren Link-Flaps
- keine steigenden physischen Fehlerzähler
- Gateway und Dateiserver durchgehend erreichbar
- ursprünglicher Dateizugriff funktioniert
- andere Systeme unverändert fehlerfrei

Ursache:
Beschädigtes Patchkabel mit sporadischer Unterbrechung.

Prävention:
- Switchport-Flaps zentral überwachen
- steigende physische Fehlerzähler alarmieren
- Fehlerzeitpunkte im Ticket immer sekundengenau dokumentieren

36. Checkliste „Fehler tritt nur manchmal auf“

37. Schnellreferenz

Beobachtung wahrscheinlicher Untersuchungsbereich
Fehler immer zur gleichen Uhrzeit Job, Backup, Scan, Update oder Provider
Fehler nach fester Laufzeit Lease, Token, Session, NAT, Firewall oder VPN
Fehler nach Inaktivität Idle-Timeout, Energiesparen oder Sitzung
nur ein Client betroffen Client, Kabel, Treiber, Port oder Benutzerprofil
alle Clients eines Standorts betroffen Uplink, WAN, Firewall, Strom oder Provider
nur WLAN betroffen Funkumgebung, Roaming, Airtime oder Access Point
nur beim Standortwechsel Roaming, Authentifizierung oder Funkabdeckung
nur unter Last CPU, RAM, Storage, Queue, Uplink oder Pool
nur nachts Backup, Snapshot, Wartung, Scan oder Replikation
Linkstatus wechselt kurz Kabel, Port, Netzwerkkarte, Strom oder Treiber
Fehlerzähler steigen physischer Link, Queue, Überlastung oder Hardware
Netzwerk normal, Anwendung hängt Anwendung, Backend, Datenbank oder Storage
nur einzelne Ziel-IP fehlerhaft Load Balancer, Backend oder Zielpfad
nur nach Aufwachen Treiber, DHCP, DNS, VPN oder Energiesparmodus
nur über VPN Tunnel, Rekeying, MTU, Gateway oder Route
Fehler verschwindet nach Neustart Ressourcen, Speicherleck, Zustand oder Dienst
Monitoring zeigt nichts Intervall zu groß, falscher Test oder fehlende Rohdaten
Logs zeigen nichts falsches Protokoll, Rotation, Zeitabweichung oder fehlende Erfassung
Paketmitschnitt enthält Ereignis nicht Filter, falsches Interface oder Überschreibung
zeitlicher Zusammenhang mit Job mögliche Korrelation, Ursache noch zu beweisen
Problem tritt bei Temperaturanstieg auf Kühlung, Netzteil, Transceiver oder Hardware
regelmäßige DNS-Fehler Resolver, TTL, Cache, Netzwerkpfad oder DNS-Server
regelmäßige Abmeldung Token, Sitzung, Cookie, Proxy oder Load Balancer
kurze Ausfälle ohne Linkverlust Dienst, Routing, Firewall, Queue oder Server
andere Clients funktionieren gemeinsamer Server nicht automatisch ausgeschlossen, aber Clientpfad priorisieren

Merksatz

Sporadische Fehler werden selten durch einen einzelnen nachträglichen Test gefunden. Entscheidend sind sekundengenaue Zeitstempel, kontinuierliche Messungen, begrenzte Ringpuffer, ausreichend lange Protokollaufbewahrung und eine gemeinsame Zeitleiste von Client, Netzwerk, Server und Anwendung. Erst wenn Messdaten den Fehler vor, während und nach einer kontrollierten Änderung zeigen, ist die Ursache belastbar nachgewiesen.

Quellen und weiterführende Dokumentation

6. Netzwerk- und Verbindungsfehler

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:

Der Benutzername oder das Kennwort ist falsch.

Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar.

Die Sicherheitsdatenbank auf dem Server enthält kein Computerkonto für diese Arbeitsstationsvertrauensstellung.

Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.

Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden.

Das referenzierte Konto ist momentan gesperrt und kann nicht für die Anmeldung verwendet werden.

Die Anmeldung ist aufgrund einer Kontoeinschränkung nicht möglich.

Die Anmeldemethode, die Sie verwenden möchten, ist nicht zulässig.

Ihr Konto wurde deaktiviert. Wenden Sie sich an den Systemadministrator.

Das Kennwort des Benutzers muss vor der Anmeldung geändert werden.

Wir können Sie mit diesen Anmeldeinformationen nicht anmelden, weil Ihre Domäne nicht verfügbar ist.

Der genaue deutsche Wortlaut kann sich je nach Windows-Version unterscheiden. Deshalb sollten zusätzlich Fehlercode, Ereignis-ID, Uhrzeit und die englische Originalmeldung dokumentiert werden, wenn sie in einem Protokoll vorhanden ist.

2. Auswirkungen

Mögliche Auswirkungen:

3. Sicherheits- und Betriebswarnung

Bei der Untersuchung dürfen Benutzerkonten, Computerkonten, Domain Controller und Vertrauensstellungen nicht unkontrolliert verändert werden.

Insbesondere sollten nicht vorschnell:

Das Entfernen eines Computers aus der Domäne und das anschließende erneute Hinzufügen ist keine Ursachenanalyse. Dadurch können Beweise verloren gehen und zusätzliche Probleme mit Profilen, Zertifikaten, Gruppenrichtlinien, BitLocker, Softwareverteilung oder Verwaltungsdiensten entstehen.

Korrekturmaßnahmen sind nur mit entsprechender Berechtigung und nach Sicherung der Diagnosedaten durchzuführen.

4. Zuerst den Umfang bestimmen

Die wichtigste erste Frage lautet:

Ist nur ein Benutzer, nur ein Client oder ein größerer Teil der Domäne betroffen?

Beobachtung zuerst zu untersuchender Bereich
ein Benutzer kann sich an keinem Client anmelden Benutzerkonto, Kennwort, Sperre, Ablauf, Anmelderechte
ein Benutzer kann sich nur an einem Client nicht anmelden Client, lokales Profil, Anmeldeformat, Richtlinie, gespeicherte Daten
kein Domänenbenutzer kann sich an einem Client anmelden DNS, Netzwerk, Uhrzeit, sicherer Kanal, Computerkonto
mehrere Clients eines Standorts sind betroffen DNS, DHCP, VLAN, Standort-Uplink, Firewall, erreichbarer Domain Controller
alle Benutzer der Domäne sind betroffen Domain Controller, DNS, Replikation, Zeitdienst, zentrale Infrastruktur
Anmeldung funktioniert offline, aber nicht im Firmennetz erreichter Domain Controller, Kontostatus, Kennwort, DNS oder sicherer Kanal
Anmeldung funktioniert im Firmennetz, aber nicht über VPN VPN-Verbindungszeitpunkt, DNS, Routing, Firewall, Gerätezertifikat
alte Anmeldedaten funktionieren offline zwischengespeicherte Domänenanmeldung
neues Kennwort funktioniert nur an manchen Clients Replikation, erreichter Domain Controller, gespeicherte Anmeldedaten
lokale Anmeldung funktioniert, Domänenanmeldung nicht Domänenpfad, Benutzerkonto, DNS, Domain Controller oder Vertrauensstellung
Anmeldung funktioniert mit einem anderen Domänenbenutzer Benutzerkonto oder benutzerspezifische Richtlinie priorisieren
Anmeldung funktioniert nach Neustart gelegentlich wieder Netzwerkstart, DNS, Dienstreihenfolge, sicherer Kanal oder erreichter DC

Ein einzelner erfolgreicher Anmeldeversuch mit einem anderen Benutzer beweist nicht, dass die gesamte Domäneninfrastruktur fehlerfrei ist. Der andere Benutzer könnte zwischengespeicherte Anmeldedaten verwenden oder einen anderen Authentifizierungspfad besitzen.

5. Mindestinformationen erfassen

Vor einer Änderung sollten mindestens dokumentiert werden:

Ticket:
Datum und genaue Uhrzeit:
Zeitzone:
Benutzerkonto:
Clientname:
Client-IP:
Standort:
Verbindung: Ethernet / WLAN / VPN
Domäne:
verwendetes Anmeldeformat:
genauer Meldungstext:
Fehlercode:
Anmeldung lokal oder remote:
erstmalige oder wiederkehrende Anmeldung:
anderer Benutzer am selben Client getestet:
derselbe Benutzer an anderem Client getestet:
lokale Anmeldung möglich:
Netzwerk vor der Anmeldung verfügbar:
zuletzt erfolgreiche Anmeldung:
kürzlich geändertes Kennwort:
zuletzt installierte Updates oder Änderungen:

Kennwörter dürfen nicht in das Ticket oder Diagnoseprotokoll geschrieben werden.

6. Lokales Konto und Domänenkonto unterscheiden

Die Eingabe auf dem Anmeldebildschirm kann unterschiedliche Kontotypen ansprechen.

Domänenkonto als UPN

benutzer@ad.example.test

Domänenkonto im älteren Format

EXAMPLE\benutzer

Lokales Konto

.\benutzer

oder:

CLIENT01\benutzer

.\benutzer bezeichnet ein lokales Konto des aktuellen Computers. Es ist keine Domänenanmeldung.

Eine Anmeldung kann fehlschlagen, weil:

Vor tieferer Diagnose sollte deshalb feststehen, welches Konto Windows tatsächlich authentifizieren soll.

7. Gesicherte Anmeldung und zwischengespeicherte Anmeldedaten

Windows kann erfolgreiche Domänenanmeldungen zwischenspeichern. Dadurch kann sich ein Benutzer möglicherweise an einem Notebook anmelden, obwohl momentan kein Domain Controller erreichbar ist.

Das bedeutet:

Anmeldung erfolgreich
≠
Domain Controller war erreichbar

Bei einer zwischengespeicherten Anmeldung können anschließend trotzdem ausfallen:

Typische Hinweise auf eine zwischengespeicherte Anmeldung:

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:

Nach der Anmeldung kann der aktuelle Zustand geprüft werden:

Get-NetAdapter

Get-NetIPConfiguration

ipconfig /all

Wichtige Angaben:

Eine Adresse aus 169.254.0.0/16 weist bei IPv4 typischerweise darauf hin, dass keine reguläre DHCP-Konfiguration bezogen wurde. Sie beweist jedoch noch nicht, ob DHCP-Server, Relay, VLAN, Port oder Client die Ursache ist.

9. Erreichbarkeit schrittweise prüfen

Nach einer lokalen oder zwischengespeicherten Anmeldung kann der Netzwerkpfad untersucht werden.

Eigene Netzwerkkonfiguration

ipconfig /all

Standardgateway

Test-Connection -TargetName <gateway> -Count 4

Interner DNS-Server

Test-Connection -TargetName <dns-server> -Count 4

Domain Controller

Test-Connection -TargetName <dc-fqdn> -Count 4

Relevante TCP-Verbindungen

Test-NetConnection -ComputerName <dc-fqdn> -Port 53
Test-NetConnection -ComputerName <dc-fqdn> -Port 88
Test-NetConnection -ComputerName <dc-fqdn> -Port 389
Test-NetConnection -ComputerName <dc-fqdn> -Port 445

Ein erfolgreicher Ping beweist nicht, dass DNS, Kerberos, LDAP, SMB, RPC oder die Anmeldung funktioniert. Umgekehrt kann Ping durch eine Firewall blockiert sein, obwohl die benötigten Dienste erreichbar sind.

Active Directory verwendet mehrere Protokolle und dynamische RPC-Ports. Vier erfolgreiche Porttests ersetzen deshalb keine vollständige Prüfung des Domänenpfades.

10. DNS-Konfiguration des Clients prüfen

Active Directory ist in hohem Maß von DNS abhängig. Ein Domänenclient muss die DNS-Server verwenden, welche die Active-Directory-DNS-Zone und die zugehörigen Dienstressourceneinträge auflösen können.

Prüfen:

Get-DnsClientServerAddress

Get-DnsClientGlobalSetting

Get-DnsClient

Alternativ:

ipconfig /all

Verdächtig sind insbesondere:

Öffentliche Resolver können Internetnamen auflösen, kennen aber normalerweise nicht die internen SRV-Einträge der Active-Directory-Domäne.

Eine funktionierende Auflösung von www.example.com beweist daher nicht, dass Active Directory über DNS gefunden werden kann.

11. DNS-Auflösung der Domäne prüfen

Domänenname auflösen

Resolve-DnsName -Name <ad-domain>

Domain-Controller-Dienst suchen

Resolve-DnsName `
  -Name "_ldap._tcp.dc._msdcs.<ad-domain>" `
  -Type SRV

Kerberos-Dienst suchen

Resolve-DnsName `
  -Name "_kerberos._tcp.<ad-domain>" `
  -Type SRV

Global Catalog suchen

Resolve-DnsName `
  -Name "_ldap._tcp.gc._msdcs.<forest-root-domain>" `
  -Type SRV

Mit nslookup:

nslookup -type=SRV _ldap._tcp.dc._msdcs.<ad-domain>

nslookup -type=SRV _kerberos._tcp.<ad-domain>

Erwartet werden SRV-Antworten mit geeigneten Domain Controllern. Anschließend müssen auch deren Hostnamen auflösbar sein:

Resolve-DnsName -Name <dc-fqdn>

Eine vorhandene SRV-Antwort reicht nicht aus, wenn:

12. DNS-Cache kontrolliert untersuchen

Cache anzeigen:

ipconfig /displaydns

PowerShell:

Get-DnsClientCache

Der Cache kann Hinweise auf bereits verwendete Einträge liefern.

Erst nach Sicherung der relevanten Informationen kann für einen kontrollierten Vergleich der Clientcache geleert werden:

ipconfig /flushdns

Das Leeren des DNS-Caches ist eine Zustandsänderung. Wenn der Fehler nur sporadisch auftritt, kann dadurch ein wichtiger Hinweis auf einen falschen oder veralteten Eintrag verloren gehen.

Eine erfolgreiche Anmeldung nach dem Leeren beweist noch nicht, welcher DNS-Eintrag fehlerhaft war. Dafür müssen Antworten vor und nach der Änderung verglichen werden.

13. Domain Controller Locator prüfen

Windows verwendet den Domain Controller Locator, um einen geeigneten Domain Controller zu finden.

Domain Controller suchen

nltest /dsgetdc:<ad-domain>

Erzwungene erneute Suche

nltest /dsgetdc:<ad-domain> /force

Domain Controller eines AD-Standorts suchen

nltest /dsgetdc:<ad-domain> /site:<site-name>

Clientstandort anzeigen

nltest /dsgetsite

Liste der Domain Controller

nltest /dclist:<ad-domain>

Die Ausgabe von nltest /dsgetdc kann unter anderem zeigen:

Fehler wie:

ERROR_NO_SUCH_DOMAIN

oder:

DsGetDcName failed: Status = 1355

weisen darauf hin, dass kein geeigneter Domain Controller gefunden wurde. Die Ursache kann unter anderem bei DNS, Netzwerk, Firewall, AD-Standort, Dienstregistrierung oder Domain Controller liegen.

14. Verwendeten Anmeldeserver feststellen

Nach einer erfolgreichen Domänenanmeldung:

echo %LOGONSERVER%

PowerShell:

$env:LOGONSERVER

Zusätzlich:

whoami

whoami /user

whoami /groups

Der Wert von LOGONSERVER ist hilfreich, darf aber nicht als vollständiger Nachweis für jeden späteren Authentifizierungsvorgang betrachtet werden. Unterschiedliche Dienste können andere Domain Controller oder Kerberos-Dienstpfade verwenden.

Wenn die Anmeldung nur bei einem bestimmten Domain Controller fehlschlägt, sind besonders zu prüfen:

15. Systemzeit und Zeitzone prüfen

Kerberos ist auf ausreichend übereinstimmende Zeit angewiesen. Eine zu große Zeitabweichung kann die Authentifizierung verhindern.

Clientstatus

w32tm /query /status

Konfiguration

w32tm /query /configuration

Zeitquelle

w32tm /query /source

Vergleich mit einem Domain Controller

w32tm /stripchart /computer:<dc-fqdn> /dataonly /samples:10

Windows-Time-Service

Get-Service -Name W32Time

Zusätzlich dokumentieren:

Get-Date

Get-TimeZone

Zu prüfen sind:

Die Uhr darf während der Diagnose nicht unkontrolliert manuell verändert werden. Vor einer Korrektur sollten Status und Abweichung dokumentiert werden.

16. Benutzerkonto prüfen

Mit installiertem Active-Directory-PowerShell-Modul und ausreichender Berechtigung:

Get-ADUser -Identity <benutzer> `
  -Properties Enabled, LockedOut, PasswordExpired,
              PasswordLastSet, AccountExpirationDate,
              UserPrincipalName, SamAccountName,
              LastLogonDate, LogonWorkstations

Gezielt formatieren:

Get-ADUser -Identity <benutzer> `
  -Properties Enabled, LockedOut, PasswordExpired,
              PasswordLastSet, AccountExpirationDate,
              UserPrincipalName, LogonWorkstations |
    Select-Object SamAccountName,
                  UserPrincipalName,
                  Enabled,
                  LockedOut,
                  PasswordExpired,
                  PasswordLastSet,
                  AccountExpirationDate,
                  LogonWorkstations

Zu prüfen sind:

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:

Kontostatus:

Get-ADUser -Identity <benutzer> -Properties LockedOut |
    Select-Object SamAccountName, LockedOut

Sperrereignisse auf einem Domain Controller:

Get-WinEvent -FilterHashtable @{
    LogName = "Security"
    Id      = 4740
} |
    Select-Object TimeCreated, Id, Message

Ereignis-ID 4740 zeigt eine Kontosperre. Das Ereignis kann Informationen über den aufrufenden Computer enthalten.

Nur das Entsperren des Kontos behebt eine wiederkehrende Sperrquelle nicht. Vor dem Entsperren sollten Zeitpunkt, Domain Controller, aufrufender Computer und vorausgehende Authentifizierungsfehler dokumentiert werden.

18. Kennwortänderung und Replikation berücksichtigen

Nach einer Kennwortänderung können Probleme entstehen, wenn:

Zu erfassen:

Zeitpunkt der Kennwortänderung:
System, an dem das Kennwort geändert wurde:
vermutlich beteiligter Domain Controller:
erstes Auftreten des Fehlers:
funktioniert altes Kennwort offline:
funktioniert neues Kennwort online:
funktioniert Anmeldung an anderem Client:
funktioniert Anmeldung an anderem Standort:

Kennwörter dürfen nicht testweise an mehreren Stellen verteilt oder protokolliert werden.

19. Computerkonto prüfen

Ein Domänencomputer besitzt in Active Directory ein eigenes Computerkonto.

Mit dem Active-Directory-PowerShell-Modul:

Get-ADComputer -Identity <computername> `
  -Properties Enabled, PasswordLastSet, LastLogonDate,
              DistinguishedName, DNSHostName

Formatierte Ausgabe:

Get-ADComputer -Identity <computername> `
  -Properties Enabled, PasswordLastSet, LastLogonDate,
              DistinguishedName, DNSHostName |
    Select-Object Name,
                  DNSHostName,
                  Enabled,
                  PasswordLastSet,
                  LastLogonDate,
                  DistinguishedName

Zu prüfen sind:

PasswordLastSet allein beweist nicht, dass der sichere Kanal funktioniert. Es ist nur ein Hinweis innerhalb der Gesamtanalyse.

20. Sicheren Kanal prüfen

Der sichere Kanal verbindet einen Domänenmitgliedscomputer mit der Domäne.

PowerShell auf einem Mitgliedscomputer

Test-ComputerSecureChannel -Verbose

Mit ausdrücklich angegebener Domäne:

Test-ComputerSecureChannel `
  -Server <dc-fqdn> `
  -Verbose

NLTEST

nltest /sc_query:<ad-domain>

Zusätzliche Informationen:

nltest /sc_verify:<ad-domain>

Je nach Systemrolle und verwendetem Werkzeug unterscheiden sich Bedeutung und Verhalten einzelner Prüfungen. Test-ComputerSecureChannel ist für Domänenmitgliedscomputer vorgesehen und sollte nicht als allgemeiner Zustandstest eines Domain Controllers verwendet werden.

Ein fehlerhafter sicherer Kanal kann Meldungen verursachen wie:

Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.

Mögliche Ursachen:

21. Sicheren Kanal nur kontrolliert reparieren

Die folgenden Befehle verändern den Zustand und gehören nicht zur rein lesenden Diagnose.

PowerShell

Test-ComputerSecureChannel `
  -Repair `
  -Credential (Get-Credential) `
  -Verbose

Alternative:

Reset-ComputerMachinePassword `
  -Server <dc-fqdn> `
  -Credential (Get-Credential)

Eine Reparatur sollte nur erfolgen, wenn:

  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:

Das Entfernen und erneute Hinzufügen zur Domäne sollte erst nach nachvollziehbarer Diagnose und gemäß dem betrieblichen Verfahren erfolgen.

22. Kerberos-Tickets prüfen

Aktuelle Tickets des angemeldeten Sicherheitskontexts:

klist

Kerberos-Ticket-Granting-Tickets anzeigen:

klist tgt

Weitere Sitzungsinformationen:

klist sessions

Verfügbarer Domain Controller:

klist query_bind

Je nach Windows-Version und Sicherheitskontext können die verfügbaren Unterbefehle und sichtbaren Tickets variieren. Die lokale Hilfe ist zu prüfen:

klist ?

Zu untersuchen sind:

Tickets kontrolliert entfernen:

klist purge

klist purge verändert den Anmeldezustand der aktuellen Sitzung. Vorher sollten die vorhandenen Tickets dokumentiert werden. Eine erfolgreiche Funktion nach dem Purge beweist ohne Vergleich der vorherigen Tickets nicht automatisch die Ursache.

23. NTLM und Kerberos unterscheiden

Eine Windows-Domäne kann je nach Vorgang Kerberos oder NTLM verwenden.

Vereinfacht:

Bereich typischer Hinweis
Kerberos-Vorauthentifizierung fehlgeschlagen Ereignis 4771
Kerberos-TGT angefordert Ereignis 4768
Kerberos-Dienstticket angefordert Ereignis 4769
NTLM-Anmeldeinformationen geprüft Ereignis 4776
Anmeldung auf Zielsystem fehlgeschlagen Ereignis 4625
Konto gesperrt Ereignis 4740

Ein Ereignis muss immer zusammen mit Zeitpunkt, Benutzer, Clientadresse, Anmeldetyp, Statuscode, Substatus und beteiligtem System bewertet werden.

24. Ereignis 4625 auswerten

Ereignis-ID 4625 bedeutet, dass eine Kontoanmeldung fehlgeschlagen ist. Es entsteht auf dem System, auf dem der Anmeldeversuch verarbeitet wurde.

Zeitlich begrenzte Abfrage:

$Start = Get-Date "2026-08-02 09:10:00"
$End = Get-Date "2026-08-02 09:20:00"

Get-WinEvent -FilterHashtable @{
    LogName   = "Security"
    Id        = 4625
    StartTime = $Start
    EndTime   = $End
} |
    Select-Object TimeCreated, Id, Message

Wichtige Felder können sein:

Häufige Anmeldetypen:

Anmeldetyp Bedeutung
2 interaktive Anmeldung an der Konsole
3 Netzwerkanmeldung
4 Batch, beispielsweise geplante Aufgabe
5 Dienst
7 Entsperren
8 NetworkCleartext
9 NewCredentials
10 RemoteInteractive, beispielsweise RDP
11 CachedInteractive

Anmeldetyp 11 weist auf eine interaktive Anmeldung mit zwischengespeicherten Domäneninformationen hin. Er bedeutet nicht, dass während der Anmeldung ein Domain Controller erreicht wurde.

Status- und Substatuswerte müssen anhand der Microsoft-Dokumentation und des konkreten Ereignisses interpretiert werden.

25. Relevante Authentifizierungsereignisse

Auf Client, Mitgliedsserver und Domain Controllern können unter anderem relevant sein:

Ereignis-ID allgemeine Bedeutung
4624 erfolgreiche Anmeldung
4625 fehlgeschlagene Anmeldung
4648 Anmeldung mit ausdrücklich angegebenen Anmeldeinformationen
4672 besondere Rechte wurden einer neuen Anmeldung zugewiesen
4722 Benutzerkonto aktiviert
4725 Benutzerkonto deaktiviert
4726 Benutzerkonto gelöscht
4738 Benutzerkonto geändert
4740 Benutzerkonto gesperrt
4767 Benutzerkonto entsperrt
4768 Kerberos-TGT angefordert
4769 Kerberos-Dienstticket angefordert
4770 Kerberos-Dienstticket erneuert
4771 Kerberos-Vorauthentifizierung fehlgeschlagen
4776 Anmeldeinformationen wurden über NTLM geprüft
5719 kein Domain Controller für eine sichere Sitzung verfügbar
5722 Authentifizierung der Sitzung beziehungsweise des Computerkontos fehlgeschlagen
5805 Sitzung eines Computers konnte nicht authentifiziert werden

Nicht jedes Ereignis ist standardmäßig aktiviert oder auf jedem System vorhanden. Ereignisse können auf unterschiedlichen beteiligten Computern entstehen.

26. Mehrere Ereignisse zeitlich abfragen

$Start = Get-Date "2026-08-02 09:10:00"
$End = Get-Date "2026-08-02 09:20:00"
$Ids = 4624, 4625, 4648, 4740, 4768, 4769, 4771, 4776

Get-WinEvent -FilterHashtable @{
    LogName   = "Security"
    Id        = $Ids
    StartTime = $Start
    EndTime   = $End
} |
    Select-Object TimeCreated, Id, ProviderName,
                  LevelDisplayName, Message |
    Sort-Object TimeCreated

Systemereignisse:

Get-WinEvent -FilterHashtable @{
    LogName   = "System"
    Id        = 5719, 5722, 5805
    StartTime = $Start
    EndTime   = $End
} |
    Select-Object TimeCreated, Id, ProviderName,
                  LevelDisplayName, Message |
    Sort-Object TimeCreated

Für große Protokolle sollte bereits serverseitig mit FilterHashtable nach Zeitraum und Ereignis-ID gefiltert werden.

27. Ereignisprotokolle auf dem Client prüfen

Relevante Protokolle können sein:

Windows-Protokolle → System
Windows-Protokolle → Sicherheit
Windows-Protokolle → Anwendung
Anwendungs- und Dienstprotokolle → Microsoft → Windows → GroupPolicy → Operational
Anwendungs- und Dienstprotokolle → Microsoft → Windows → User Profile Service → Operational
Anwendungs- und Dienstprotokolle → Microsoft → Windows → DNS Client Events
Anwendungs- und Dienstprotokolle → Microsoft → Windows → WLAN-AutoConfig → Operational

Vorhandene Protokolle auflisten:

Get-WinEvent -ListLog * |
    Where-Object {
        $_.LogName -match "GroupPolicy|User Profile|DNS|WLAN|Kerberos|Netlogon"
    } |
    Select-Object LogName, IsEnabled, RecordCount

Nicht jedes Protokoll ist auf jedem System aktiviert. Zusätzliche Protokollierung darf nur kontrolliert unter Berücksichtigung von Speicherbedarf, Datenschutz und Betriebsrichtlinien aktiviert werden.

28. Netlogon-Diagnose berücksichtigen

Der Netlogon-Dienst ist unter anderem an Domain-Controller-Ermittlung und sicherem Kanal beteiligt.

Dienststatus:

Get-Service -Name Netlogon

Ausführliche Dienstinformationen:

Netlogon kann ein Diagnoseprotokoll unter folgendem Pfad verwenden:

%windir%\debug\netlogon.log

Erweiterte Netlogon-Protokollierung verändert den Diagnosezustand und kann umfangreiche oder sensible Informationen erzeugen. Sie sollte nur gezielt, zeitlich begrenzt und entsprechend der offiziellen Microsoft-Anleitung aktiviert werden.

Nach Abschluss muss eine zusätzlich aktivierte Diagnoseprotokollierung wieder auf den vorgesehenen Zustand zurückgesetzt werden.

29. Gruppenrichtlinien prüfen

Eine Anmeldung kann technisch erfolgreich sein, während Gruppenrichtlinien, Skripte oder Ressourcenverbindungen fehlschlagen.

Aktuelle Richtlinien aktualisieren:

gpupdate /force

Dieser Befehl ist eine aktive Zustandsänderung und sollte erst nach Sicherung der relevanten Ereignisse verwendet werden.

Resultierende Richtlinien anzeigen:

gpresult /r

Ausführlicher HTML-Bericht:

gpresult /h C:\Temp\gpresult.html

Relevante Fragen:

Ein lang laufendes Anmeldeskript kann wie eine fehlgeschlagene Anmeldung erscheinen, obwohl die Authentifizierung bereits abgeschlossen wurde.

30. SYSVOL und NETLOGON prüfen

Freigaben eines Domain Controllers anzeigen:

net view \\<dc-fqdn>

SYSVOL testen:

dir \\<dc-fqdn>\SYSVOL

NETLOGON testen:

dir \\<dc-fqdn>\NETLOGON

Wenn diese Pfade nicht erreichbar sind, sind unter anderem zu prüfen:

Ein erfolgreicher Verzeichniszugriff beweist nicht, dass alle Gruppenrichtlinien oder die AD-Replikation fehlerfrei sind.

31. Benutzerprofilfehler von Authentifizierungsfehlern trennen

Der Benutzer kann erfolgreich authentifiziert worden sein, obwohl Windows das Profil nicht laden kann.

Typische Hinweise:

Die Anmeldung des Dienstes "Benutzerprofildienst" ist fehlgeschlagen.

Das Benutzerprofil kann nicht geladen werden.

Sie wurden mit einem temporären Profil angemeldet.

Dann sind besonders zu prüfen:

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:

Porttest:

Test-NetConnection -ComputerName <zielserver> -Port 3389

Ein erfolgreicher Porttest beweist nur, dass eine TCP-Verbindung hergestellt werden konnte. Er beweist nicht, dass NLA, Authentifizierung, Anmelderechte oder Profilladen funktionieren.

33. Anmeldung über VPN untersuchen

Bei entfernten Clients ist entscheidend, wann das VPN verfügbar wird.

Mögliche Fälle:

  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:

ipconfig /all

Get-DnsClientServerAddress

Get-NetRoute

nltest /dsgetdc:<ad-domain>

w32tm /query /status

Die erfolgreiche Anmeldung am Notebook vor dem VPN beweist nur, dass zwischengespeicherte Anmeldedaten verwendbar waren.

34. Domain Controller diagnostizieren

Auf einem Domain Controller und mit entsprechender Berechtigung:

dcdiag

Ausführliche Ausgabe in eine Datei:

dcdiag /v > C:\Temp\dcdiag.txt

DNS-Prüfung:

dcdiag /test:dns /v

Bestimmten Domain Controller testen:

dcdiag /s:<dc-name> /v

Unternehmensweite Prüfung:

dcdiag /e /v

Die unternehmensweite Prüfung kann umfangreich sein und sollte kontrolliert eingesetzt werden.

Zu untersuchen sind unter anderem:

Nicht jede Warnung in dcdiag erklärt automatisch die konkrete Anmeldestörung. Der Zeitpunkt und der betroffene Authentifizierungspfad müssen weiterhin korreliert werden.

35. Active-Directory-Replikation prüfen

Zusammenfassung:

repadmin /replsummary

Eingehende Replikationspartner:

repadmin /showrepl

Alle Domain Controller detailliert:

repadmin /showrepl * /csv

Replikationswarteschlange:

repadmin /queue

Zu prüfen sind:

Eine erzwungene Replikation ist eine aktive Änderung und sollte nicht als erster Diagnoseschritt verwendet werden.

Wenn ein Benutzer sein Kennwort geändert hat und die Anmeldung abhängig vom erreichten Domain Controller funktioniert, ist eine Replikationsstörung eine mögliche Hypothese. Sie muss durch Replikationsdaten und den tatsächlich verwendeten Domain Controller bestätigt werden.

36. AD-Standorte und Subnetze berücksichtigen

Der Domain Controller Locator berücksichtigt Active-Directory-Standorte.

Clientstandort:

nltest /dsgetsite

Gefundener Domain Controller:

nltest /dsgetdc:<ad-domain>

Mögliche Fehler:

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:

Einzelne typische Ports:

Dienst Protokoll/Port
DNS TCP/UDP 53
Kerberos TCP/UDP 88
RPC Endpoint Mapper TCP 135
NetBIOS Name Service UDP 137
NetBIOS Datagram UDP 138
NetBIOS Session TCP 139
LDAP TCP/UDP 389
SMB TCP 445
Kerberos-Kennwortänderung TCP/UDP 464
LDAPS TCP 636
Global Catalog TCP 3268
Global Catalog über TLS TCP 3269
Windows-Zeitdienst UDP 123
dynamisches RPC versionsabhängiger TCP-Portbereich

Diese Tabelle ist keine vollständige Firewallfreigabe. Die tatsächlich benötigten Verbindungen hängen von Windows-Version, Topologie, Richtung und Funktion ab.

Firewalls dürfen nicht pauschal deaktiviert werden. Stattdessen sind verworfene Verbindungen, Quell- und Zieladressen, Ports, Richtung und Zeitpunkt zu untersuchen.

38. Paketmitschnitt nur gezielt einsetzen

Wenn DNS, DC Locator, Kerberos oder LDAP weiterhin unklar bleiben, kann ein autorisierter Paketmitschnitt helfen.

Mögliche Protokolle:

dns
kerberos
ldap
tcp.port == 445
tcp.port == 135

Möglicher Wireshark-Anzeigefilter:

dns || kerberos || ldap || tcp.port == 445 || tcp.port == 135

Zu beobachten sind:

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

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

40. Praxisfall B: Kein Benutzer kann sich an einem Client anmelden

Symptom

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

41. Praxisfall C: Vertrauensstellung ist fehlgeschlagen

Symptom

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

42. Praxisfall D: Anmeldung funktioniert nur an einem Standort nicht

Symptom

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

43. Praxisfall E: Anmeldung dauert mehrere Minuten

Symptom

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

44. Ungeeignete Sofortmaßnahmen

Problematisch sind insbesondere:

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

Ticket: INC-20831
Zeitraum: 02.08.2026, 08:14 bis 10:42 Uhr
Benutzer: test.user
Client: WS-BER-042
Domäne: ad.example.test
Standort: Berlin
Verbindung: Ethernet

Symptom:
Kein Domänenbenutzer kann sich an WS-BER-042 anmelden. Lokale Anmeldung
ist möglich. Andere Clients desselben Standorts sind nicht betroffen.

Meldung:
„Es sind momentan keine Anmeldeserver zum Verarbeiten der
Anmeldeanforderung verfügbar.“

Vergleich:
- anderer Domänenbenutzer am selben Client: fehlgeschlagen
- betroffener Benutzer an anderem Client: erfolgreich
- lokales Administratorkonto: erfolgreich

Messungen:
- Client besitzt gültige IPv4-Adresse und erreicht das Standardgateway
- interner DNS-Server ist erreichbar
- in der statischen Adapterkonfiguration ist jedoch ein öffentlicher
  DNS-Server eingetragen
- Abfrage von _ldap._tcp.dc._msdcs.ad.example.test schlägt fehl
- nltest /dsgetdc:ad.example.test liefert Fehler 1355
- Clientzeit ist korrekt
- Computerkonto ist vorhanden und aktiviert

Hypothese:
Der Client kann aufgrund der falschen DNS-Konfiguration keine
Active-Directory-Domain-Controller finden.

Kontrollierte Änderung:
Die statische DNS-Konfiguration wurde entsprechend der freigegebenen
Netzwerkdokumentation auf die vorgesehenen internen DNS-Server korrigiert.
Andere Einstellungen blieben unverändert.

Nachprüfung:
- SRV-Abfrage liefert die vorgesehenen Domain Controller
- nltest findet einen Domain Controller des korrekten Standorts
- sicherer Kanal ist intakt
- Domänenanmeldung funktioniert
- Gruppenrichtlinien werden verarbeitet
- SYSVOL und NETLOGON sind erreichbar
- keine neuen Netlogon- oder Anmeldefehler
- Vergleichsbenutzer funktioniert ebenfalls

Ursache:
Falsch statisch eingetragener öffentlicher DNS-Server am Domänenclient.

Prävention:
- DNS-Konfiguration von Domänenclients zentral überwachen
- statische Clientkonfigurationen vermeiden, wenn DHCP vorgesehen ist
- Prüfung der AD-SRV-Auflösung in die Clientdiagnose aufnehmen

47. Checkliste „Anmeldung an der Domäne geht nicht“

48. Schnellreferenz

Beobachtung wahrscheinlicher Untersuchungsbereich
ein Benutzer überall betroffen Konto, Kennwort, Sperre, Ablauf oder Anmelderechte
alle Benutzer an einem Client betroffen DNS, Netzwerk, Uhrzeit, Computerkonto oder sicherer Kanal
mehrere Clients eines Standorts betroffen Standort-DNS, VLAN, Uplink, Firewall oder lokaler DC
lokale Anmeldung funktioniert lokales System grundsätzlich zugänglich; Domänenpfad weiter prüfen
alter Benutzer funktioniert offline wahrscheinlich zwischengespeicherte Anmeldung
neuer Benutzer funktioniert offline nicht keine zwischengespeicherten Anmeldedaten vorhanden
altes Kennwort funktioniert offline Cache; keine Bestätigung des aktuellen Domänenkennworts
öffentliches DNS funktioniert, AD nicht interne AD-DNS-Zone oder SRV-Auflösung
Fehler 1355 bei nltest Domain Controller konnte nicht gefunden werden
Uhrzeit stark abweichend Kerberos und Zeitdienst
Konto gesperrt Sperrquelle über 4740 und vorausgehende Fehler suchen
Sperre kehrt sofort zurück Gerät, Dienst, Aufgabe, VPN oder gespeicherte Daten
Vertrauensstellung fehlgeschlagen Computerkonto oder sicherer Kanal
Fehler nach Snapshot-Rückkehr Maschinenkennwort oder Computerzustand
Anmeldung abhängig vom DC Replikation, DC-Zustand, DNS oder Standort
Anmeldung funktioniert, Profil lädt nicht User Profile Service, Speicher oder Profilpfad
Anmeldung bleibt bei „Willkommen“ hängen Gruppenrichtlinie, Skript, Profil oder Ressource
RDP allein betroffen NLA, RDP-Rechte, Zielsystem oder Anmeldetyp 10
VPN allein betroffen Pre-Logon-Verbindung, DNS, Routing, Zertifikat oder Tunnel
SYSVOL nicht erreichbar DNS, SMB, DC, DFS-Replikation oder Firewall
Test-ComputerSecureChannel negativ sicheren Kanal und Voraussetzungen gezielt untersuchen
Ping erfolgreich, Anmeldung fehlschlägt DNS, Kerberos, LDAP, SMB, RPC, Konto oder Richtlinie
anderes Konto funktioniert benutzerspezifischen Bereich priorisieren
derselbe Benutzer funktioniert an anderem Client Client oder clientspezifische Richtlinie priorisieren
keine Ereignisse gefunden falsches System, falscher Zeitraum, Auditierung oder Rotation
Anmeldung nach DNS-Korrektur möglich DNS-Ursache durch Vorher-Nachher-Daten bestätigen
Anmeldung nach Neustart möglich Zustand geändert; Ursache noch nicht bewiesen

Merksatz

Eine Domänenanmeldung ist kein einzelner Vorgang, sondern eine Kette aus Netzwerk, DNS, Domain Controller Locator, Zeit, Benutzerkonto, Computerkonto, sicherem Kanal und Authentifizierungsprotokoll. Die Diagnose beginnt deshalb mit dem genauen Umfang und dem originalen Fehlerzeitpunkt. Erst danach werden Client, DNS, Domain Controller und Ereignisprotokolle auf einer gemeinsamen Zeitleiste geprüft.

Quellen und weiterführende Dokumentation

7. Schnelle Entscheidungsbäume

7. Schnelle Entscheidungsbäume

7.1 Ein Client hat kein Netzwerk

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

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

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

1. Störungsumfang bestimmen

Zuerst prüfen:

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

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

2. Besteht eine Verbindung zum Netzwerkmedium?

Ethernet

Prüfen:

Adapterstatus anzeigen:

Get-NetAdapter

Nur physische Adapter anzeigen:

Get-NetAdapter -Physical

Ausführliche Adapterinformationen:

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

Entscheidung

WLAN

WLAN-Schnittstelle und Verbindungszustand anzeigen:

netsh wlan show interfaces

Sichtbare WLAN-Netze anzeigen:

netsh wlan show networks

Gespeicherte WLAN-Profile anzeigen:

netsh wlan show profiles

Prüfen:

Entscheidung

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

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

Vollständige Konfiguration erfassen:

ipconfig /all

Alternativ mit PowerShell:

Get-NetIPConfiguration

Zu dokumentieren sind:

Entscheidungsbaum zur IPv4-Adresse

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

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

4. DHCP-Pfad prüfen

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

DHCP-Clientdienst prüfen:

Get-Service -Name Dhcp

Adapterkonfiguration prüfen:

Get-NetIPInterface

Mögliche Ursachen:

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

ipconfig /release

ipconfig /renew

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

Ergebnis bewerten

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

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

5. Lokalen TCP/IP-Stack prüfen

Loopback-Adresse testen:

ping 127.0.0.1

Eigene IPv4-Adresse testen:

ping <eigene-ip-adresse>

Entscheidung

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

6. Standardgateway vorhanden und erreichbar?

Gateway aus der Konfiguration übernehmen:

ipconfig

Routingtabelle anzeigen:

route print

Alternativ:

Get-NetRoute

Gateway testen:

ping <gateway-ip>

Zusätzliche Verbindungsinformationen:

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

Nachbartabelle anzeigen:

arp -a

Oder mit PowerShell:

Get-NetNeighbor

Entscheidungsbaum

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

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

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

7. Ist ein anderes Ziel im lokalen Subnetz erreichbar?

Vergleichsziel im gleichen Subnetz testen:

ping <lokales-vergleichsziel>

Gezielten Dienst prüfen:

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

Entscheidung

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

Ein freigegebenes bekanntes IP-Ziel verwenden:

ping <bekannte-ip-adresse>

Pfad untersuchen:

tracert <bekannte-ip-adresse>

PowerShell-Diagnose:

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

Entscheidung

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

9. Funktioniert die Namensauflösung?

Konfigurierte DNS-Server prüfen:

ipconfig /all

Namensauflösung testen:

nslookup <zielname>

Mit PowerShell:

Resolve-DnsName <zielname>

Erreichbarkeit eines DNS-Servers prüfen:

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

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

Entscheidungsbaum

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

DNS-Cache anzeigen:

ipconfig /displaydns

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

Erst nach der Beweissicherung und wenn dies zur Hypothese passt:

ipconfig /flushdns

10. Funktioniert nur die Anwendung nicht?

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

Porttest:

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

Beispiele:

Test-NetConnection -ComputerName <zielname> -Port 443

Test-NetConnection -ComputerName <zielname> -Port 445

Test-NetConnection -ComputerName <zielname> -Port 3389

Zusätzlich prüfen:

Proxykonfiguration anzeigen:

netsh winhttp show proxy

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

11. Beeinflusst ein VPN oder virtueller Adapter die Verbindung?

Adapter anzeigen:

Get-NetAdapter

IP-Konfiguration anzeigen:

Get-NetIPConfiguration

Routingtabelle prüfen:

route print

DNS-Server je Schnittstelle anzeigen:

Get-DnsClientServerAddress

Zu prüfen sind:

Vergleichstest

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

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

12. Lokale Firewall und Sicherheitssoftware berücksichtigen

Firewallprofile anzeigen:

Get-NetFirewallProfile

Aktive Verbindungen und lauschende Ports:

Get-NetTCPConnection

Zu prüfen sind:

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

13. Vergleichstests durchführen

Geeignete Vergleichstests:

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

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

14. Möglichen IP-Adresskonflikt prüfen

Hinweise auf einen Adresskonflikt:

Nachbartabelle prüfen:

arp -a

Eigene MAC-Adresse erfassen:

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

Prüfen:

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

15. Ereignisprotokolle prüfen

Relevante Protokolle können sich befinden unter:

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

PowerShell-Beispiel für Systemereignisse:

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

Zu korrelieren sind:

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

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

Treiber- oder Hardwareprobleme sind besonders wahrscheinlich, wenn:

Vor Änderungen dokumentieren:

Adapterinformationen:

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

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

17. Paketmitschnitt nur bei weiterhin unklarer Ursache

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

Typische Filter:

arp

dhcp

dns

icmp

Kombinierter Wireshark-Anzeigefilter:

arp || dhcp || dns || icmp

Zu beobachten sind:

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

18. Schneller Hauptentscheidungsbaum

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

19. Beispiel für eine schnelle Diagnose

Symptom

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

Prüfung

Get-NetAdapter

Ergebnis:

Name      Status        LinkSpeed
Ethernet  Up            1 Gbps

IP-Konfiguration:

ipconfig /all

Ergebnis:

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

Bewertung

Vergleichstest

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

Nächster Untersuchungsbereich

Festgestellte Ursache

Der Switchport wurde versehentlich einem nicht vorgesehenen VLAN zugeordnet.

Nachprüfung

20. Ungeeignete Sofortmaßnahmen

Nicht als erste Maßnahme verwenden:

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

21. Vollständige Schnellprüfreihenfolge

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

22. Checkliste „Ein Client hat kein Netzwerk“

23. Schnellreferenz

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

Merksatz

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

Quellen und weiterführende Dokumentation

7. Schnelle Entscheidungsbäume

7.2 Mehrere Clients haben kein Netzwerk

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

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

1. Betroffenen Bereich bestimmen

Zuerst feststellen, welche Gemeinsamkeit die betroffenen Clients besitzen.

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

2. Schneller Hauptentscheidungsbaum

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

3. Störungsumfang mit Vergleichstests eingrenzen

Geeignete Vergleichsclients auswählen:

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

ipconfig /all

ping <gateway-ip>

ping <freigegebene-externe-ip>

nslookup <zielname>

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

Bewertung

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

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

4. Besteht noch eine Verbindung zum Netzwerk?

Auf mehreren betroffenen Clients den Adapterstatus prüfen:

Get-NetAdapter

Vollständige IP-Konfiguration anzeigen:

ipconfig /all

Entscheidung

Bei einem räumlich begrenzten Ausfall prüfen:

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

Entscheidungsbaum

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

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

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

Hinweise auf einen VLAN-Fehler:

Zu prüfen sind:

Entscheidung

7. DHCP-Störung erkennen

Auf mehreren betroffenen Clients prüfen:

ipconfig /all

Typische Hinweise auf einen gemeinsamen DHCP-Fehler:

Schneller DHCP-Entscheidungsbaum

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

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

Get-Service -Name DHCPServer

Get-DhcpServerv4Scope

Get-DhcpServerv4ScopeStatistics

Get-DhcpServerv4Binding

Get-DhcpServerv4Failover

Zu prüfen sind:

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

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

8. Bestehende und neue Clients vergleichen

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

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

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

9. Standardgateway prüfen

Auf mehreren Clients das konfigurierte Gateway feststellen:

ipconfig

Gateway testen:

ping <gateway-ip>

Routingtabelle anzeigen:

route print

Alternativ:

Get-NetRoute

Nachbartabelle prüfen:

Get-NetNeighbor

Entscheidung

Ein fehlgeschlagener Ping allein beweist keinen Ausfall des Gateways.

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

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

ping <freigegebene-externe-ip>

Pfad anzeigen:

tracert <freigegebene-externe-ip>

PowerShell-Test:

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

Entscheidungsbaum

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

Zu prüfen sind:

11. DNS als gemeinsame Ursache erkennen

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

nslookup <zielname>

Resolve-DnsName <zielname>

Konfigurierte DNS-Server anzeigen:

Get-DnsClientServerAddress

DNS-Port prüfen:

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

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

Entscheidung

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

12. WLAN-Ausfall mehrerer Clients

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

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

Zusätzlich prüfen:

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

13. Redundanz- und Hochverfügbarkeitsfehler berücksichtigen

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

Zu prüfen sind:

Mögliche Fehlerbilder:

14. Änderungen und Zeitpunkte korrelieren

Vor Maßnahmen prüfen:

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

15. Beispiel für eine schnelle Diagnose

Symptom

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

Erste Eingrenzung

Clientprüfung

ipconfig /all

Ergebnis auf mehreren Clients:

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

Bewertung

Infrastrukturprüfung

Festgestellte Ursache

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

Kontrollierte Maßnahme

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

Nachprüfung

16. Ungeeignete Sofortmaßnahmen

Nicht als erste Maßnahme verwenden:

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

17. Vollständige Schnellprüfreihenfolge

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

18. Checkliste „Mehrere Clients haben kein Netzwerk“

19. Schnellreferenz

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

Merksatz

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

Quellen und weiterführende Dokumentation

7. Schnelle Entscheidungsbäume

7.3 „Name geht nicht, IP geht“

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

Beispiel:

ping 192.0.2.25

funktioniert, aber:

ping server01.example.local

scheitert.

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

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

1. Zuerst die Ausgangslage bestätigen

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

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

Für einen konkreten Dienst:

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

Danach denselben Test mit dem Namen durchführen:

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

Bewertung

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

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

2. Schneller Hauptentscheidungsbaum

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

3. Den verwendeten Namen genau dokumentieren

Vor weiteren Tests erfassen:

Beispiele:

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

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

server01.example.local

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

4. DNS-Konfiguration des Clients prüfen

Vollständige Netzwerkkonfiguration anzeigen:

ipconfig /all

Gezielt die konfigurierten DNS-Server anzeigen:

Get-DnsClientServerAddress

Nur IPv4-DNS-Server:

Get-DnsClientServerAddress -AddressFamily IPv4

DNS-Clientkonfiguration der Adapter anzeigen:

Get-DnsClient

Globale DNS-Einstellungen und Suffixsuchliste anzeigen:

Get-DnsClientGlobalSetting

Zu prüfen sind:

Typische Fehlerbilder

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

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

5. DNS-Server auf Erreichbarkeit prüfen

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

ping <dns-server-ip>

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

TCP-Port 53 prüfen:

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

Wichtig

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

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

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

6. Den Namen gezielt abfragen

Standardabfrage mit dem aktuell verwendeten DNS-Pfad:

Resolve-DnsName <zielname>

Beispiel:

Resolve-DnsName server01.example.local

Gezielt einen bestimmten DNS-Server abfragen:

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

Alternativ:

nslookup <zielname>

Bestimmten DNS-Server abfragen:

nslookup <zielname> <dns-server-ip>

Zu dokumentieren sind:

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

7. Jeden konfigurierten DNS-Server einzeln testen

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

Beispiel:

Resolve-DnsName server01.example.local -Server 192.0.2.10

Resolve-DnsName server01.example.local -Server 192.0.2.11

Bewertung

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

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

8. FQDN und Kurzname vergleichen

Vollständigen Namen testen:

Resolve-DnsName server01.example.local

Kurznamen testen:

Resolve-DnsName server01

Entscheidung

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

DNS-Clientinformationen anzeigen:

Get-DnsClient

Globale Suffixsuchliste anzeigen:

Get-DnsClientGlobalSetting

In ipconfig /all insbesondere prüfen:

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

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

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

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

IPv4-Eintrag abfragen:

Resolve-DnsName <zielname> -Type A

IPv6-Eintrag abfragen:

Resolve-DnsName <zielname> -Type AAAA

Mit nslookup:

nslookup -type=A <zielname>

nslookup -type=AAAA <zielname>

Bewertung

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

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

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

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

Resolve-DnsName <zielname>

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

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

Zu klären sind:

Wichtig

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

11. DNS-Clientcache untersuchen

Cacheeinträge anzeigen:

ipconfig /displaydns

Alternativ:

Get-DnsClientCache

Gezielt nach einem Namen suchen:

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

Zu prüfen sind:

Vergleich

Resolve-DnsName <zielname>

und anschließend gezielt:

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

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

Cache erst nach der Dokumentation leeren:

Clear-DnsClientCache

Alternativ:

ipconfig /flushdns

Danach denselben Test erneut durchführen:

Resolve-DnsName <zielname>

Negativer Cache

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

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

12. hosts-Datei prüfen

Unter Windows befindet sich die Datei hier:

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

Inhalt mit PowerShell anzeigen:

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

Relevante aktive Zeilen anzeigen:

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

Mögliche Fehler:

Beispiel eines problematischen Eintrags:

192.0.2.40 server01.example.local

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

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

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

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

Get-DnsServerZone

Bestimmte Zone prüfen:

Get-DnsServerZone -Name "<zone>"

Resource Record suchen:

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

A- und AAAA-Records der Zone anzeigen:

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

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

Zu prüfen sind:

Beispiel

Der Client fragt ab:

server01.example.local

Dafür müssen mindestens folgende Bestandteile stimmen:

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

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

14. TTL und veraltete Antworten berücksichtigen

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

TTL mit PowerShell prüfen:

Resolve-DnsName <zielname>

Ausführlich mit nslookup:

nslookup -debug <zielname>

Mögliche Situation:

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

Zu berücksichtigen sind:

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

15. Zonenreplikation prüfen

Bei Active-Directory-integrierten Zonen prüfen:

Zone auf mehreren Servern gezielt vergleichen:

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

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

Hinweise auf ein Replikationsproblem

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

16. Forwarder und Conditional Forwarder prüfen

Forwarder auf einem Windows-DNS-Server anzeigen:

Get-DnsServerForwarder

Conditional Forwarder anzeigen:

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

Details einer Weiterleitungszone prüfen:

Get-DnsServerConditionalForwarderZone -Name "<zone>"

Zu prüfen sind:

Gezielte Prüfung des Zielservers:

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

Entscheidung

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

17. Delegation prüfen

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

Nameserver abfragen:

Resolve-DnsName <untergeordnete-zone> -Type NS

SOA-Eintrag prüfen:

Resolve-DnsName <untergeordnete-zone> -Type SOA

Zu prüfen sind:

Typisches Fehlerbild

host.abteilung.example.local

Die Zone:

abteilung.example.local

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

18. UDP und TCP auf Port 53 unterscheiden

DNS verwendet sowohl UDP als auch TCP.

Typische Gründe für TCP-Nutzung:

Nur TCP testen:

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

Eine tatsächliche DNS-Abfrage ausführen:

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

Abfrage ausdrücklich über TCP erzwingen:

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

Bewertung

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

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

19. Split-DNS berücksichtigen

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

Beispiel:

portal.example.com

Intern:

10.10.20.25

Extern:

198.51.100.25

Vergleichsabfragen:

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

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

Zu prüfen sind:

Typisches Fehlerbild

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

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

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

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

Get-DnsClientServerAddress

Get-DnsClientGlobalSetting

NRPT-Regeln anzeigen:

Get-DnsClientNrptPolicy

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

Get-DnsClientNrptRule

Zu prüfen sind:

Vergleich

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

21. DNS over HTTPS berücksichtigen

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

Windows-Konfiguration unterstützter DoH-Server anzeigen:

Get-DnsClientDohServerAddress

Zu prüfen sind:

Typische Hinweise

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

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

22. DNS-Servercache berücksichtigen

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

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

Show-DnsServerCache

Gezielt sollte geprüft werden:

Beispiel:

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

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

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

23. CNAME-Ketten vollständig prüfen

CNAME-Abfrage:

Resolve-DnsName <zielname> -Type CNAME

Normale Abfrage:

Resolve-DnsName <zielname>

Beispiel:

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

Zu prüfen sind:

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

24. DNS-Antwortcodes richtig bewerten

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

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

25. Anwendungen getrennt vom DNS-System testen

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

Vergleichstests

Resolve-DnsName <zielname>

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

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

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

26. Beispiel für eine schnelle Diagnose

Symptom

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

\\192.0.2.25\Freigabe

Der Zugriff über den Namen scheitert:

\\fileserver.example.local\Freigabe

IP-Prüfung

Test-NetConnection -ComputerName 192.0.2.25 -Port 445

Ergebnis:

TcpTestSucceeded : True

Namensprüfung

Resolve-DnsName fileserver.example.local

Ergebnis:

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

Bewertung

Vergleich der DNS-Server

Resolve-DnsName fileserver.example.local -Server 192.0.2.10

Ergebnis:

IPAddress : 192.0.2.25

Resolve-DnsName fileserver.example.local -Server 192.0.2.11

Ergebnis:

IPAddress : 192.0.2.20

Festgestellte Ursache

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

Kontrollierte Maßnahme

Nachprüfung

Resolve-DnsName fileserver.example.local -Server 192.0.2.10

Resolve-DnsName fileserver.example.local -Server 192.0.2.11

Beide Server liefern:

IPAddress : 192.0.2.25

Zusätzlich:

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

Ergebnis:

TcpTestSucceeded : True

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

27. Ungeeignete Sofortmaßnahmen

Nicht als erste Maßnahme verwenden:

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

28. Vollständige Schnellprüfreihenfolge

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

29. Checkliste „Name geht nicht, IP geht“

30. Schnellreferenz

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

Merksatz

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

Quellen und weiterführende Dokumentation

7. Schnelle Entscheidungsbäume

7.4 VLAN- und Switching-Fehleranalyse

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

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

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

1. Typische Fehlerbilder

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

2. Sollzustand vor der Diagnose feststellen

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

Zu dokumentieren sind:

Beispiel:

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

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

3. Umfang der Störung bestimmen

Zuerst prüfen:

Vergleichstests

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

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

4. Clientkonfiguration prüfen

Unter Windows:

ipconfig /all

Get-NetAdapter

Get-NetIPConfiguration

Get-NetIPAddress

Get-NetRoute -AddressFamily IPv4

Unter Linux:

ip address show

ip route show

Unter macOS:

ifconfig

route -n get default

Zu prüfen sind:

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

5. Physische Verbindung und Portstatus prüfen

Am Client prüfen:

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

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

show interfaces status

Gezielten Port prüfen:

show interfaces GigabitEthernet1/0/12

Kurze Fehlerübersicht:

show interfaces counters errors

Zu prüfen sind:

Typische Bewertungen

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

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

6. Nachbarschaft und tatsächlichen Port ermitteln

Cisco Discovery Protocol:

show cdp neighbors

Details:

show cdp neighbors detail

show lldp neighbors

Details:

show lldp neighbors detail

Zu prüfen sind:

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

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

VLAN-Übersicht:

show vlan brief

Portbezogene Switchportinformationen:

show interfaces GigabitEthernet1/0/12 switchport

Relevante Portkonfiguration:

show running-config interface GigabitEthernet1/0/12

Zu prüfen sind:

Beispiel eines vorgesehenen Access-Ports:

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

Mögliche Fehler

switchport access vlan 10

obwohl der Client VLAN 20 verwenden soll.

Oder der Port arbeitet unerwartet als Trunk:

switchport mode trunk

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

8. Existenz und Status des VLANs prüfen

show vlan brief

Gezielt:

show vlan id 20

Zu prüfen sind:

Wichtig

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

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

9. MAC-Adresse des Clients ermitteln

Unter Windows:

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

Unter Linux:

Unter macOS:

ifconfig

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

Beispiel:

00-11-22-33-44-55

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

0011.2233.4455

10. MAC-Adress-Tabelle prüfen

Gesamte Tabelle:

show mac address-table

Bestimmte MAC-Adresse suchen:

show mac address-table address 0011.2233.4455

MAC-Adressen eines VLANs:

show mac address-table vlan 20

MAC-Adressen eines Ports:

show mac address-table interface GigabitEthernet1/0/12

Zu prüfen sind:

Bewertung

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

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

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

Beispiel:

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

Prüfung auf dem Access-Switch:

show mac address-table address 0011.2233.4455

Erwartung:

VLAN 20 -> GigabitEthernet1/0/12

Prüfung auf dem Distribution-Switch:

show mac address-table address 0011.2233.4455

Erwartung:

VLAN 20 -> GigabitEthernet1/0/48

oder:

VLAN 20 -> Port-channel1

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

12. Trunkstatus prüfen

Trunkübersicht:

show interfaces trunk

Gezielten Port prüfen:

show interfaces GigabitEthernet1/0/48 switchport

Konfiguration anzeigen:

show running-config interface GigabitEthernet1/0/48

Zu prüfen sind:

Beispiel:

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

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

13. Allowed-VLAN-Liste auf jedem Trunk vergleichen

show interfaces trunk

Beispiel eines Fehlers:

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

Distribution-Switch:
Allowed VLANs: 10,30

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

Typische Ursachen

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

14. Native VLAN prüfen

Auf beiden Seiten des Trunks:

show interfaces trunk

show interfaces <trunk-port> switchport

Beispiel eines Mismatch:

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

Mögliche Auswirkungen:

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

15. Access-Port und Trunk nicht verwechseln

Access-Port

Trunk-Port

Typische Fehlkonfigurationen

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

16. Clientseitiges VLAN-Tagging berücksichtigen

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

Zu prüfen sind:

Beispiel eines Fehlers:

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

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

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

Beispiel:

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

Dabei kann gelten:

PC-Daten:       VLAN 20
Telefonverkehr: VLAN 30

Zu prüfen sind:

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

18. ARP beziehungsweise Neighbor Cache prüfen

Unter Windows:

Get-NetNeighbor

arp -a

Unter Linux:

ip neighbor show

Unter macOS:

arp -a

Zu prüfen sind:

Bewertung

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

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

19. Gateway-SVI prüfen

Auf einem Layer-3-Switch beispielsweise:

show ip interface brief

Gezielt:

show interfaces Vlan20

Konfiguration:

show running-config interface Vlan20

ARP-Tabelle:

show ip arp

Zu prüfen sind:

Typisches Fehlerbild

Vlan20 is administratively up, line protocol is down

Mögliche Ursache:

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

20. Kommunikation innerhalb und außerhalb des VLANs trennen

Vom Client aus nacheinander prüfen:

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

Windows:

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

Test-NetConnection -ComputerName <gateway-ip>

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

Bewertung

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

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

21. Spanning-Tree-Zustand prüfen

Übersicht:

show spanning-tree

Bestimmtes VLAN:

show spanning-tree vlan 20

Bestimmten Port:

show spanning-tree interface GigabitEthernet1/0/48 detail

Zu prüfen sind:

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

Problematisch ist beispielsweise:

22. Spanning-Tree-Änderungen und Schleifen untersuchen

show spanning-tree detail

Zusätzlich Systemprotokoll prüfen:

show logging

Hinweise auf mögliche Schleifen:

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

23. MAC-Flapping prüfen

Protokolle untersuchen:

show logging

MAC-Adresse gezielt suchen:

show mac address-table address <mac-adresse>

Wiederholt prüfen, ob der Port wechselt.

Beispiel:

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

Mögliche Ursachen:

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

24. EtherChannel beziehungsweise Port-Channel prüfen

Übersicht:

show etherchannel summary

Port-Channel prüfen:

show interfaces Port-channel1

Trunkstatus:

show interfaces trunk

Konfiguration der Mitglieder vergleichen:

show running-config interface GigabitEthernet1/0/47

show running-config interface GigabitEthernet1/0/48

Zu prüfen sind:

Typische Fehler

25. Port-Security prüfen

Auf Cisco-Switches beispielsweise:

show port-security

Gezielter Port:

show port-security interface GigabitEthernet1/0/12

Portstatus:

show interfaces status err-disabled

Zu prüfen sind:

Typisches Fehlerbild

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

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

26. Weitere Schutzfunktionen berücksichtigen

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

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

show authentication sessions

show dot1x all

show ip dhcp snooping

show ip arp inspection

show interfaces status err-disabled

show logging

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

Typische Fehlerbilder

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

27. err-disabled-Ursache untersuchen

show interfaces status err-disabled

show errdisable recovery

show logging

Je nach Plattform können Ursachen sein:

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

Kontrollierte Wiederaktivierung erst nach Ursachenklärung:

interface <port>
 shutdown
 no shutdown

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

28. Paketmitschnitt für VLAN-Tags verwenden

Ein Paketmitschnitt kann zeigen:

Wireshark-Anzeigefilter für VLAN-Verkehr:

vlan

Bestimmte VLAN-ID:

vlan.id == 20

ARP:

arp

DHCP:

dhcp

LLDP:

lldp

STP:

stp

Wichtig

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

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

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

29. Beispiel für eine systematische Diagnose

Symptom

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

Sollzustand

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

Clientprüfung

ipconfig /all

Ergebnis:

IPv4-Adresse: 192.0.2.45
Gateway:      192.0.2.1

Portprüfung

show interfaces GigabitEthernet1/0/12 switchport

Ergebnis:

Operational Mode: static access
Access Mode VLAN: 20

MAC-Prüfung

show mac address-table address 0011.2233.4455

Ergebnis:

VLAN 20    0011.2233.4455    DYNAMIC    Gi1/0/12

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

Trunkprüfung

show interfaces trunk

Ergebnis am Access-Switch:

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

Ergebnis am Distribution-Switch:

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

Festgestellte Ursache

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

Kontrollierte Maßnahme

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

Nachprüfung

Auf beiden Switches:

show interfaces trunk

Ergebnis:

Allowed VLANs: 10,20,30

MAC-Adresse auf dem Distribution-Switch:

show mac address-table address 0011.2233.4455

Ergebnis:

VLAN 20    0011.2233.4455    DYNAMIC    Gi1/0/48

Clienttest:

Test-NetConnection -ComputerName 192.0.2.1

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

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

Symptom

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

Prüfung der MAC-Adresse

show mac address-table address 0011.2233.4455

Ergebnis:

VLAN 30    0011.2233.4455    DYNAMIC    Gi1/0/18

Festgestellte Ursache

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

Lehre

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

31. Ungeeignete Sofortmaßnahmen

Nicht als erste Maßnahme verwenden:

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

32. Vollständige Schnellprüfreihenfolge

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

33. Checkliste VLAN und Switching

34. Schnellreferenz

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

Merksatz

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

Quellen und weiterführende Dokumentation

7. Schnelle Entscheidungsbäume

7.5 Netzwerk ist langsam

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

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

Kurzbeschreibung

Die Ursache kann auf unterschiedlichen Ebenen liegen:

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

Typische Symptome

Mögliche Auswirkungen

Sicherheits- und Betriebswarnung

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

Vor Veränderungen müssen dokumentiert werden:

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

1. Die Aussage „langsam“ messbar machen

Zuerst muss das genaue Verhalten beschrieben werden.

Zu klären sind:

Ungeeignete Beschreibung

Das Netzwerk ist langsam.

Geeignete Beschreibung

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

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

Erst die zweite Beschreibung ermöglicht eine gezielte Eingrenzung.

2. Umfang der Störung bestimmen

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

Zum Vergleich möglichst denselben Vorgang durchführen:

Dabei darf keine Sicherheitskontrolle umgangen werden.

3. Sollleistung richtig bestimmen

Die angezeigte Verbindungsgeschwindigkeit ist nicht mit dem nutzbaren Anwendungsdurchsatz gleichzusetzen.

Linkgeschwindigkeit ≠ tatsächlicher Datendurchsatz

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

Auch Einheiten müssen unterschieden werden:

1 Byte = 8 Bit

Beispiel:

100 MB/s × 8 = 800 Mbit/s

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

4. Client und verwendeten Netzwerkadapter prüfen

Unter Windows:

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

Ausführliche IP-Konfiguration:

Get-NetIPConfiguration

Aktive IP-Adressen:

Get-NetIPAddress

Unter Linux:

ip address show

Unter macOS:

ifconfig

Zu prüfen sind:

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

Unter Windows:

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

5. Linkgeschwindigkeit und Duplex prüfen

Unter Windows:

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

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

show interfaces status

Gezielter Port:

show interfaces GigabitEthernet1/0/12

Zu prüfen sind:

Typisches Fehlerbild

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

Mögliche Ursachen:

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

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

6. Fehler- und Verwerfungszähler prüfen

Unter Windows:

Get-NetAdapterStatistics

Alle verfügbaren Werte eines Adapters:

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

Unter Linux:

ip -s link show

Alternativ, sofern vorhanden:

ethtool -S <interface>

Auf Cisco-Switches:

show interfaces GigabitEthernet1/0/12

Kurze Fehlerübersicht:

show interfaces counters errors

Zu prüfen sind:

Bewertung

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

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

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

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

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

Der Fehler besteht weiterhin und muss untersucht werden.

7. Latenz, Schwankung und Paketverlust messen

Windows:

ping <ziel-ip> -n 20

Mit festgelegter Paketgröße:

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

Linux:

ping -c 20 <ziel-ip>

macOS:

ping -c 20 <ziel-ip>

Zu dokumentieren sind:

Beispiel

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

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

Wichtig

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

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

8. Stufenweise unterschiedliche Ziele testen

Die Messung sollte vom nahen zum entfernten Ziel erfolgen:

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

Beispiel:

ping <gateway-ip> -n 20

ping <lokaler-server> -n 20

ping <entfernter-server> -n 20

Bewertung

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

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

9. Netzwerkpfad ermitteln

Unter Windows:

tracert -d <ziel-ip>

pathping -n <ziel-ip>

PowerShell:

Test-NetConnection -ComputerName <ziel> -TraceRoute

Unter Linux:

traceroute -n <ziel-ip>

Alternativ, sofern vorhanden:

mtr -n <ziel-ip>

Unter macOS:

traceroute -n <ziel-ip>

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

Zu prüfen sind:

Vorsicht bei der Bewertung

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

10. Tatsächlichen Durchsatz mit iperf3 messen

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

Auf einem autorisierten Testsystem:

iperf3 -s

Auf dem Client:

iperf3 -c <server-ip>

Längere Messung:

iperf3 -c <server-ip> -t 30

Umgekehrte Richtung:

iperf3 -c <server-ip> -R

Mehrere parallele Datenströme:

iperf3 -c <server-ip> -P 4

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

iperf3 -c <server-ip> --bidir

UDP-Test nur mit kontrollierter Bandbreite:

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

Wichtige Werte

Bewertung

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

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

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

11. Messung innerhalb einzelner Segmente durchführen

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

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

Mögliche Vergleichsmessungen:

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

Beispiel

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

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

12. Switchports und Uplinks vergleichen

Auf Cisco-Switches beispielsweise:

show interfaces status

show interfaces counters errors

show interfaces GigabitEthernet1/0/12

show interfaces GigabitEthernet1/0/48

Zu prüfen sind:

Beispiel

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

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

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

13. Auslastung und Warteschlangen prüfen

Ein ausgelasteter Link kann folgende Auswirkungen haben:

Zu prüfen sind:

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

14. Ethernet und WLAN getrennt vergleichen

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

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

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

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

Unter Windows:

netsh wlan show interfaces

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

Zu prüfen sind:

Wichtig

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

16. WLAN-Kanalauslastung und Airtime prüfen

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

Zu prüfen sind:

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

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

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

Zu prüfen sind:

Vergleich

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

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

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

18. VPN-Leistung untersuchen

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

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

19. MTU und Fragmentierung prüfen

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

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

ping <ziel-ip> -f -l 1472

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

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

ping <ziel-ip> -f -l 1400

Linux:

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

Zu prüfen sind:

Wichtig

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

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

20. TCP-Wiederholungen und Empfangsfenster analysieren

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

Wireshark-Anzeigefilter:

tcp.analysis.retransmission

Weitere mögliche Wiederholungen:

tcp.analysis.fast_retransmission

tcp.analysis.spurious_retransmission

Verloren vermutete Segmente:

tcp.analysis.lost_segment

Empfangsfenster vollständig belegt:

tcp.analysis.window_full

Empfänger meldet ein Empfangsfenster von null:

tcp.analysis.zero_window

Alle TCP-Analysehinweise:

tcp.analysis.flags

Zu prüfen sind:

Bewertung

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

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

21. Paketmitschnitt kontrolliert durchführen

Ein Paketmitschnitt kann zeigen:

Beispielhafte Wireshark-Filter:

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

Nur TCP-Verkehr zwischen zwei Systemen:

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

TCP-Analysehinweise:

tcp.analysis.flags

ICMP-Fehlermeldungen:

icmp

DNS:

dns

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

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

22. Netzwerk und Anwendung voneinander trennen

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

Mögliche zusätzliche Verzögerungen:

Vergleich

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

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

23. Serverressourcen prüfen

Unter Windows beispielsweise:

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

Get-Counter '\Memory\Available MBytes'

Netzwerkadapterstatistik:

Get-NetAdapterStatistics

Aktuelle TCP-Verbindungen:

Get-NetTCPConnection

Unter Linux:

top

free -h

vmstat 1

iostat -xz 1

ss -s

Zu prüfen sind:

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

24. Storage-Leistung von Netzwerkleistung unterscheiden

Dateiübertragungen werden mindestens durch folgende Komponenten begrenzt:

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

Der langsamste beteiligte Abschnitt bestimmt die erreichbare Gesamtleistung.

Vergleichsmöglichkeiten

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

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

25. Zeitabhängige Last untersuchen

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

Erforderlich ist eine zeitliche Korrelation:

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

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

26. Baseline und Vergleichswerte verwenden

Eine Baseline beschreibt den normalen Zustand eines Systems.

Sinnvolle Vergleichswerte:

Beispiel

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

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

27. Beispiel für eine systematische Diagnose

Symptom

Mehrere Benutzer melden langsame Zugriffe auf einen Dateiserver.

Sollzustand

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

Clienttest

ping 192.0.2.80 -n 20

Ergebnis:

Durchschnitt: 2 ms
Paketverlust: 0 %

Durchsatztest

iperf3 -c 192.0.2.80 -t 30

Ergebnis:

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

Clientport

show interfaces GigabitEthernet1/0/12

Ergebnis:

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

Uplinkprüfung

show interfaces TenGigabitEthernet1/1/1

Ergebnis:

Auslastung: 99 %
Output Drops steigen

Zeitlicher Vergleich

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

Festgestellte Ursache

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

Kontrollierte Maßnahme

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

Rollback

Falls die Änderung unerwartete Auswirkungen verursacht:

Verifikation

iperf3 -c 192.0.2.80 -t 30

Ergebnis:

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

Zusätzlich:

28. Beispiel „Netzwerk schnell, Server langsam“

Symptom

Der Zugriff auf eine Datenbankanwendung benötigt mehrere Sekunden.

Netzwerkprüfung

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

Serverprüfung

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

Festgestellte Ursache

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

Lehre

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

29. Ungeeignete Sofortmaßnahmen

Nicht als erste Maßnahme verwenden:

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

30. Vollständige Schnellprüfreihenfolge

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

31. Checkliste „Netzwerk ist langsam“

32. Schnellreferenz

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

Merksatz

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

Quellen und weiterführende Dokumentation

7. Schnelle Entscheidungsbäume

7.6 Fehler tritt nur manchmal auf

Sporadische Fehler treten unregelmäßig auf und sind bei einer direkten Prüfung häufig nicht mehr vorhanden. Beispiele sind kurze Verbindungsabbrüche, gelegentliche Anmeldefehler, zeitweise langsame Anwendungen oder Dienste, die sich scheinbar ohne Eingriff wieder stabilisieren.

Die besondere Schwierigkeit besteht darin, dass der Systemzustand während der Störung meistens nicht direkt beobachtet wird. Deshalb müssen Diagnoseinformationen bereits vor dem nächsten Auftreten gesammelt werden.

Sporadischer Fehler
        ↓
genauen Zeitpunkt erfassen
        ↓
Messwerte und Protokolle sichern
        ↓
wiederkehrendes Muster erkennen
        ↓
gemeinsame Ursache eingrenzen

1. Typische Symptome

2. Mögliche Auswirkungen

Ein sporadischer Fehler ist nicht automatisch harmlos. Kurze Unterbrechungen können besonders bei Datenbanken, Transaktionen, Authentifizierungen, Telefonie, VPN-Verbindungen und Schreibvorgängen erhebliche Auswirkungen haben.

3. Sicherheits- und Betriebshinweis

Dauerüberwachung, Protokollierung und Paketmitschnitte dürfen nur autorisiert durchgeführt werden.

Dabei können verarbeitet werden:

Vor einer erweiterten Protokollierung sind deshalb zu klären:

Protokollierung darf nicht unbegrenzt und ohne festgelegten Zweck aktiviert bleiben.

4. Fehler nicht vorschnell als „nicht reproduzierbar“ schließen

Wenn ein Fehler bei der Prüfung nicht mehr vorhanden ist, bedeutet dies nur:

Der Fehler ist im aktuellen Moment nicht sichtbar.

Es bedeutet nicht:

Der Fehler hat nicht stattgefunden.

Ein sporadischer Fehler kann zwischen zwei Prüfungen auftreten und wieder verschwinden. Deshalb müssen folgende Informationen gesammelt werden:

5. Exakten Zeitpunkt erfassen

Die wichtigste Angabe ist ein möglichst genauer Zeitstempel.

Ungeeignet:

Der Fehler war heute Nachmittag.

Besser:

02.08.2026, ungefähr 14:17 Uhr

Optimal:

02.08.2026, 14:17:32 bis 14:17:47 Uhr

Zusätzlich dokumentieren:

Benutzer:       Max Mustermann
Client:         NB-023
IP-Adresse:     192.0.2.45
Anwendung:      ERP-Client
Zielserver:     ERP-SRV-01
Aktion:         Auftrag speichern
Fehlermeldung:  Verbindung zum Server unterbrochen
Beginn:         14:17:32 Uhr
Ende:           14:17:47 Uhr

Je genauer der Zeitpunkt bekannt ist, desto gezielter können Ereignisprotokolle, Monitoringdaten und Paketmitschnitte ausgewertet werden.

6. Zeitsynchronisation prüfen

Protokolle verschiedener Systeme lassen sich nur zuverlässig vergleichen, wenn deren Uhren korrekt synchronisiert sind.

Zu prüfen sind:

Unter Windows:

w32tm /query /status

Konfigurierte Zeitquelle:

w32tm /query /source

Unter Linux:

timedatectl status

Bei chrony, sofern eingesetzt:

chronyc tracking

chronyc sources

Beispiel

Client:      14:17:32 Uhr
Server:      14:15:21 Uhr
Firewall:    12:17:30 UTC

Ohne Berücksichtigung von Zeitabweichung und Zeitzone könnten zusammengehörige Ereignisse fälschlich als getrennte Vorfälle bewertet werden.

Die Systemzeit darf nicht unkontrolliert auf Produktivsystemen geändert werden. Zeitänderungen können Protokolle, Zertifikate, Authentifizierung, Datenbanken und verteilte Systeme beeinflussen.

7. Häufigkeit und Muster bestimmen

Zu klären ist, ob der Fehler:

auftritt.

Beispielhafte Fehlerliste

Datum Uhrzeit Dauer Benutzer System Beobachtung
30.07.2026 14:17 15 s Max Mustermann NB-023 ERP-Verbindung getrennt
31.07.2026 14:16 18 s Max Mustermann NB-023 ERP-Verbindung getrennt
01.08.2026 14:18 12 s mehrere verschiedene Dateiserver kurz nicht erreichbar
02.08.2026 14:17 15 s mehrere verschiedene ERP und Dateiserver betroffen

Das wiederkehrende Zeitfenster deutet auf einen geplanten oder regelmäßig ausgelösten Prozess hin.

8. Umfang des Fehlers bestimmen

Folgende Fragen helfen bei der Eingrenzung:

  1. Ist nur ein Benutzer betroffen?
  2. Sind mehrere Benutzer betroffen?
  3. Sind alle Benutzer eines Standorts betroffen?
  4. Ist nur eine Anwendung betroffen?
  5. Sind mehrere Dienste gleichzeitig betroffen?
  6. Ist nur ein Client betroffen?
  7. Sind alle Geräte an einem Switch betroffen?
  8. Sind ausschließlich WLAN-Clients betroffen?
  9. Sind nur VPN-Verbindungen betroffen?
  10. Ist nur eine Übertragungsrichtung betroffen?
  11. Ist nur ein bestimmter Server betroffen?
  12. Sind interne und externe Ziele betroffen?

Bewertung

Beobachtung Möglicher Prüfbereich
nur ein Benutzer Benutzerprofil, Sitzung oder Berechtigung
nur ein Client Client, Treiber, Kabel, WLAN oder lokale Software
mehrere Clients am gleichen Switch Switch, Uplink oder Stromversorgung
alle WLAN-Clients eines Access Points Access Point, Funkkanal oder AP-Uplink
mehrere Dienste auf einem Server Server, Betriebssystem oder gemeinsame Ressource
mehrere Systeme gleichzeitig Netzwerk, DNS, Authentifizierung, Storage oder Infrastruktur
nur VPN-Benutzer Internetzugang, Tunnel, Gateway, MTU oder Sitzungszeit
alle Standorte gleichzeitig zentrales System, Provider oder übergreifender Dienst

9. Fehler automatisiert erfassen

Ein sporadischer Fehler sollte möglichst durch wiederholte Messungen sichtbar gemacht werden.

Geeignete Messwerte sind beispielsweise:

Die Messung muss einen Zeitstempel enthalten.

Grundprinzip

Zeitstempel + Messwert + Ziel + Ergebnis

Beispiel:

2026-08-02 14:17:30 | ERP-SRV-01 | Ping 1 ms | TCP 443 erreichbar
2026-08-02 14:17:35 | ERP-SRV-01 | Zeitüberschreitung
2026-08-02 14:17:40 | ERP-SRV-01 | Zeitüberschreitung
2026-08-02 14:17:45 | ERP-SRV-01 | Ping 2 ms | TCP 443 erreichbar

10. Kontinuierliche Erreichbarkeit unter Windows prüfen

Ein dauerhafter Ping kann kurzfristige Unterbrechungen sichtbar machen:

ping <ziel-ip> -t

Der Test wird mit Strg + C beendet.

Aussagekräftiger ist eine protokollierte PowerShell-Messung mit Zeitstempel:

while ($true) {
    $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    $result = Test-Connection -ComputerName "<ziel-ip>" -Count 1 -Quiet
    "$timestamp | <ziel-ip> | Erreichbar: $result" |
        Out-File -FilePath ".\erreichbarkeit.log" -Append
    Start-Sleep -Seconds 5
}

TCP-Port wiederholt prüfen:

while ($true) {
    $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    $result = Test-NetConnection -ComputerName "<server>" -Port 443
    "$timestamp | TCP 443: $($result.TcpTestSucceeded)" |
        Out-File -FilePath ".\tcp-443.log" -Append
    Start-Sleep -Seconds 5
}

Wichtig

11. Kontinuierliche Erreichbarkeit unter Linux oder macOS prüfen

Linux:

ping <ziel-ip>

macOS:

ping <ziel-ip>

Mit Zeitstempeln unter Linux, sofern ping diese Option unterstützt:

ping -D <ziel-ip>

Alternativ kann eine kontrollierte Schleife verwendet werden:

while true; do
    timestamp=$(date '+%Y-%m-%d %H:%M:%S')
    if ping -c 1 -W 2 <ziel-ip> >/dev/null 2>&1; then
        echo "$timestamp | <ziel-ip> | erreichbar"
    else
        echo "$timestamp | <ziel-ip> | nicht erreichbar"
    fi
    sleep 5
done

Da sich Optionen von ping zwischen Linux und macOS unterscheiden können, müssen die Parameter des verwendeten Systems geprüft werden:

man ping

12. Mehrere Messpunkte gleichzeitig verwenden

Eine einzelne Zielmessung zeigt nicht, an welcher Stelle der Fehler auftritt. Deshalb sollten mehrere Punkte parallel überwacht werden.

Client
  |
Standardgateway
  |
interner Server
  |
externer Dienst

Beispiel:

14:17:35 | Gateway erreichbar
14:17:35 | interner Server nicht erreichbar
14:17:35 | externer Dienst nicht erreichbar

Mögliche Eingrenzung:

Clientzugang funktioniert.
Die Störung beginnt hinter dem Gateway oder auf einem gemeinsamen Folgepfad.

Anderes Beispiel:

14:17:35 | Gateway nicht erreichbar
14:17:35 | interner Server nicht erreichbar
14:17:35 | externer Dienst nicht erreichbar

Mögliche Eingrenzung:

Client, lokaler Zugang, WLAN, Switchport oder lokales Netzwerk prüfen.

Vergleichstabelle

Gateway Interner Server Externes Ziel Eingrenzung
nicht erreichbar nicht erreichbar nicht erreichbar Client oder lokaler Zugang
erreichbar nicht erreichbar erreichbar interner Pfad oder Server
erreichbar erreichbar nicht erreichbar Internet-, Provider- oder externer Pfad
überall erreichbar Anwendung fehlerhaft Anwendung, Dienst oder Sitzung
mehrere Ziele gleichzeitig langsam gemeinsamer Netzwerkpfad oder Infrastruktur

13. Windows-Ereignisprotokolle zeitlich filtern

Ereignisse eines bestimmten Zeitraums anzeigen:

Get-WinEvent -FilterHashtable @{
    LogName   = "System"
    StartTime = [datetime]"2026-08-02 14:15:00"
    EndTime   = [datetime]"2026-08-02 14:20:00"
} |
    Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message

Anwendungsprotokoll:

Get-WinEvent -FilterHashtable @{
    LogName   = "Application"
    StartTime = [datetime]"2026-08-02 14:15:00"
    EndTime   = [datetime]"2026-08-02 14:20:00"
} |
    Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message

Fehler und Warnungen aus dem Systemprotokoll:

Get-WinEvent -FilterHashtable @{
    LogName   = "System"
    Level     = 2, 3
    StartTime = (Get-Date).AddHours(-4)
} |
    Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message

Zu prüfen sind unter anderem:

Ein zeitgleiches Ereignis ist zunächst eine Korrelation. Erst weitere Messungen zeigen, ob es tatsächlich die Ursache des Fehlers ist.

14. Linux-Protokolle zeitlich filtern

Systemprotokoll eines genauen Zeitfensters:

journalctl \
    --since "2026-08-02 14:15:00" \
    --until "2026-08-02 14:20:00"

Nur Meldungen eines bestimmten Dienstes:

journalctl \
    -u <dienstname> \
    --since "2026-08-02 14:15:00" \
    --until "2026-08-02 14:20:00"

Kernelmeldungen:

journalctl \
    -k \
    --since "2026-08-02 14:15:00" \
    --until "2026-08-02 14:20:00"

Nur Warnungen und schwerwiegendere Meldungen:

journalctl -p warning \
    --since "2026-08-02 14:15:00" \
    --until "2026-08-02 14:20:00"

Live verfolgen:

journalctl -f

Zu prüfen sind:

Ob ältere Meldungen verfügbar sind, hängt von der Konfiguration und Aufbewahrung des Journals ab.

15. Protokolle zentral zusammenführen

Wenn mehrere Systeme beteiligt sind, reichen lokale Protokolle häufig nicht aus.

Mögliche Quellen:

Vorteile einer zentralen Protokollierung:

Dabei müssen Zeitsynchronisation, Zugriffsschutz, Speicherbedarf und Datenschutz berücksichtigt werden.

16. Auflösung des Monitorings erhöhen

Ein Fünf-Minuten-Mittelwert kann einen Fehler von zehn Sekunden vollständig verdecken.

Beispiel

Messintervall: 5 Minuten
Störung:       10 Sekunden
Linklast:      während der Störung 100 %
Mittelwert:    nur 8 %

Der Mittelwert wirkt unauffällig, obwohl kurzzeitig eine vollständige Überlastung bestand.

Zu prüfen sind:

Mögliche Anpassung:

Vorher: Messung alle 5 Minuten
Temporär: Messung alle 10 Sekunden

Eine höhere Auflösung erzeugt mehr Last und benötigt mehr Speicher. Sie sollte kontrolliert, zeitlich begrenzt und auf die erforderlichen Messwerte beschränkt werden.

17. Ringpuffer-Paketmitschnitt verwenden

Wenn ein Netzwerkfehler nur selten auftritt, kann ein begrenzter Ringpuffer-Mitschnitt die Pakete vor und während des Fehlers erhalten.

Verfügbare Schnittstellen anzeigen:

dumpcap -D

Beispiel für einen Ringpuffer:

dumpcap \
    -i 1 \
    -b duration:300 \
    -b files:12 \
    -w sporadischer-fehler.pcapng

Bedeutung:

-i 1              Schnittstelle 1
-b duration:300   alle 300 Sekunden neue Datei
-b files:12       höchstens 12 Ringpufferdateien
-w                Ausgabedatei

Damit werden ungefähr die letzten 60 Minuten vorgehalten:

12 Dateien × 5 Minuten = 60 Minuten

Mitschnitt auf einen bestimmten Host begrenzen:

dumpcap \
    -i 1 \
    -f "host 192.0.2.45" \
    -b duration:300 \
    -b files:12 \
    -w sporadischer-fehler.pcapng

Wichtig

Ein Paketmitschnitt auf dem Client sieht nicht automatisch den gesamten Netzwerkverkehr. Für andere Segmente kann ein autorisierter Mirror- beziehungsweise SPAN-Port erforderlich sein.

18. Interface-Flapping untersuchen

Interface-Flapping bedeutet, dass eine Netzwerkschnittstelle wiederholt zwischen aktiv und inaktiv wechselt.

Typisches Muster:

14:17:31 Interface down
14:17:34 Interface up
14:18:02 Interface down
14:18:05 Interface up

Unter Windows:

Get-NetAdapter |
    Format-Table Name, Status, LinkSpeed, InterfaceDescription

Statistiken:

Get-NetAdapterStatistics

Unter Linux:

ip -s link show

Kernelmeldungen zum Netzwerk:

journalctl -k |
    grep -Ei "link.*(up|down)|carrier|network"

Auf Cisco-IOS-/IOS-XE-Switches beispielsweise:

show logging

show interfaces status

show interfaces <interface>

Zu prüfen sind:

19. Fehlerzähler als Verlauf beobachten

Ein einzelner Zählerstand zeigt nicht, wann ein Fehler entstanden ist. Deshalb müssen Ausgangswert und späterer Wert verglichen werden.

Beispiel ohne aktuelle Zunahme

14:00 Uhr: 25 CRC-Fehler
15:00 Uhr: 25 CRC-Fehler

Der Zähler enthält historische Fehler, steigt im Beobachtungszeitraum jedoch nicht.

Beispiel mit sporadischer Zunahme

14:00 Uhr: 25 CRC-Fehler
14:16 Uhr: 25 CRC-Fehler
14:18 Uhr: 4.260 CRC-Fehler
14:20 Uhr: 4.260 CRC-Fehler

Die Fehler entstehen in einem kurzen Zeitfenster und korrelieren möglicherweise mit der gemeldeten Störung.

Zu beobachten sind:

Fehlerzähler sollten erst nach der Dokumentation und nur nach betrieblicher Freigabe zurückgesetzt werden.

20. DHCP-Lease und Adresskonflikte prüfen

Ein Fehler kann beim Erneuern einer DHCP-Lease oder durch eine doppelt verwendete IP-Adresse auftreten.

Unter Windows:

ipconfig /all

Zu prüfen sind:

Unter Linux, abhängig vom verwendeten Netzwerkdienst:

journalctl |
    grep -Ei "dhcp|lease"

Mögliche Hinweise:

Fehler tritt regelmäßig bei Lease-Erneuerung auf.
Client erhält kurzzeitig keine gültige Adresse.
Zwei Geräte verwenden dieselbe statische IP-Adresse.
DHCP-Server sind nicht einheitlich konfiguriert.

Eine zeitliche Übereinstimmung zwischen Lease-Erneuerung und Fehler ist ein Hinweis, aber noch kein Beweis für die Ursache.

21. DNS-TTL und DNS-Auflösung prüfen

Ein sporadischer Fehler kann auftreten, wenn zwischengespeicherte DNS-Einträge ablaufen und anschließend eine fehlerhafte oder langsame Auflösung erfolgt.

Unter Windows:

Resolve-DnsName <hostname>

DNS-Cache anzeigen:

ipconfig /displaydns

Unter Linux oder macOS, sofern dig vorhanden ist:

dig <hostname>

Wiederholte Abfrage:

dig <hostname> +noall +answer

Zu prüfen sind:

Beispiel

DNS-Antwort 1: 192.0.2.80 – Dienst funktioniert
DNS-Antwort 2: 192.0.2.81 – Dienst nicht erreichbar

In diesem Fall kann der Fehler nur bei Auswahl einer bestimmten Zieladresse auftreten.

DNS-Caches dürfen nicht pauschal gelöscht werden, bevor der aktuelle Zustand dokumentiert wurde. Dadurch könnten wichtige Diagnoseinformationen verloren gehen.

22. Sitzungen, Token und Timeouts berücksichtigen

Viele sporadische Fehler treten nach einer bestimmten Zeitspanne auf.

Mögliche Zeitgrenzen:

Beispiel

Anmeldung:             08:00 Uhr
Fehler:                16:00 Uhr
Zeit bis zum Fehler:   8 Stunden

Tritt der Fehler regelmäßig nach fast derselben Sitzungsdauer auf, sind zeitbasierte Gültigkeiten und Timeouts zu prüfen.

Zu dokumentieren sind:

Ein erneutes Anmelden kann den Fehler vorübergehend beseitigen, beweist aber noch nicht, welche Komponente die Sitzung beendet hat.

23. Zertifikats- und Gültigkeitszeiträume prüfen

Zertifikatsprobleme können nur einzelne Systeme, Dienste oder Verbindungswege betreffen.

Mit OpenSSL, sofern verfügbar:

openssl s_client \
    -connect <server>:443 \
    -servername <hostname>

Nur Zertifikatsdaten ausgeben:

openssl s_client \
    -connect <server>:443 \
    -servername <hostname> \
    </dev/null 2>/dev/null |
    openssl x509 -noout -subject -issuer -dates

Zu prüfen sind:

Beispiel

Load-Balancer-Knoten 1: gültiges Zertifikat
Load-Balancer-Knoten 2: abgelaufenes Zertifikat

Der Fehler erscheint dadurch möglicherweise nur bei Verbindungen, die auf den zweiten Knoten verteilt werden.

24. Geplante Aufgaben und Timer prüfen

Regelmäßig auftretende Fehler können mit zeitgesteuerten Prozessen zusammenhängen.

Unter Windows:

Get-ScheduledTask |
    Select-Object TaskName, TaskPath, State

Weitere Informationen:

Get-ScheduledTask |
    Get-ScheduledTaskInfo |
    Select-Object TaskName, LastRunTime, LastTaskResult, NextRunTime

Unter Linux mit systemd:

systemctl list-timers --all

Cron-Einträge müssen entsprechend der verwendeten Distribution und betrieblichen Berechtigung geprüft werden.

Mögliche zeitgesteuerte Auslöser:

25. Backups, Scans und Updates zeitlich vergleichen

Beispiel

02:00:00 Backup startet
02:00:12 Storage-Latenz steigt
02:00:18 Datenbankantwortzeit steigt
02:00:25 Anwendung meldet Timeout
02:20:00 Backup endet
02:20:15 Storage-Latenz normalisiert sich

Diese Ereignisse bilden eine plausible Kette:

Backup
   ↓
hohe Storage-Last
   ↓
langsame Datenbank
   ↓
Anwendungs-Timeout

Die zeitliche Korrelation ist stark, muss aber durch Messwerte bestätigt werden.

Zu vergleichen sind:

Produktive Sicherungen oder Sicherheitsprüfungen dürfen nicht ohne Freigabe deaktiviert werden. Eine kontrollierte Zeitplanänderung ist häufig sicherer als das vollständige Abschalten.

26. Temperatur und Stromversorgung berücksichtigen

Sporadische Hardwarefehler können durch Umwelt- oder Strombedingungen ausgelöst werden.

Zu prüfen sind:

Typisches Muster:

Temperatur steigt
        ↓
Gerät reduziert Leistung oder schaltet Komponente ab
        ↓
Dienst oder Verbindung fällt kurzzeitig aus
        ↓
Temperatur sinkt
        ↓
System funktioniert wieder

Hardwaregrenzwerte und Diagnosebefehle sind hersteller- und modellspezifisch und müssen anhand der offiziellen Gerätedokumentation geprüft werden.

27. WLAN-Störungen untersuchen

Kurzzeitige WLAN-Probleme können durch wechselnde Funkbedingungen entstehen.

Zu prüfen sind:

Unter Windows:

netsh wlan show interfaces

Bericht zur WLAN-Nutzung:

netsh wlan show wlanreport

Der erzeugte Bericht enthält Informationen zu WLAN-Sitzungen und Verbindungsereignissen. Speicherort und Zugriff müssen auf dem jeweiligen System geprüft werden.

Vergleich

Ethernet WLAN Eingrenzung
stabil sporadische Ausfälle Funkstrecke, Roaming oder Access Point
beide gleichzeitig gestört gemeinsamer Pfad oder Zielsystem
nur ein WLAN-Client betroffen Client, Treiber, Standort oder Frequenzband
alle Clients eines AP betroffen Access Point, Funkkanal, PoE oder Uplink

28. Provider- und WAN-Störungen berücksichtigen

Wenn nur externe oder standortübergreifende Verbindungen betroffen sind, müssen auch WAN- und Providerpfade untersucht werden.

Zu prüfen sind:

Ein einzelner öffentlicher Speedtest reicht nicht aus. Benötigt werden wiederholte und möglichst vergleichbare Messungen zu internen und externen Referenzzielen.

29. Mehrere Systeme auf einer gemeinsamen Zeitleiste korrelieren

Die wichtigste Methode bei sporadischen Fehlern ist eine gemeinsame Ereigniszeitleiste.

Beispiel

Zeit Client Switch Firewall Server Anwendung
14:17:30 normal normal normal normal normal
14:17:32 Verbindung hängt Uplink-Drops steigen Sitzungen normal Anfragen warten Timeout beginnt
14:17:35 Ziel nicht erreichbar Uplink 100 % Paketverluste keine neuen Anfragen Fehlermeldung
14:17:42 Verbindung wieder da Drops sinken normal Anfragen treffen ein Wiederherstellung
14:18:00 normal normal normal normal normal

Die gemeinsame Zeitleiste zeigt, welche Veränderung zuerst auftrat.

Ein Anwendungsfehler am Ende der Kette ist in diesem Beispiel nicht automatisch die ursprüngliche Ursache.

30. Reihenfolge von Ursache und Folge beachten

Gleichzeitig protokollierte Fehler können unterschiedliche Rollen besitzen.

Beispiel

14:17:32 Switchport verliert Link
14:17:33 Client verliert Netzwerk
14:17:34 DNS-Abfrage schlägt fehl
14:17:35 Anwendung meldet Serverfehler

Mögliche Reihenfolge:

Switchportproblem
      ↓
Netzwerkverlust
      ↓
DNS-Fehler
      ↓
Anwendungsfehler

Der DNS-Fehler und der Anwendungsfehler sind hier wahrscheinlich Folgen des vorherigen Linkverlusts.

Deshalb ist zu fragen:

31. Kontrollierte Reproduktion versuchen

Wenn ein Muster erkannt wurde, kann eine kontrollierte Reproduktion möglich sein.

Beispiele:

Dabei gelten folgende Regeln:

  1. nur autorisierte Tests durchführen,
  2. Ausgangszustand dokumentieren,
  3. erwartete Beobachtung festlegen,
  4. nur einen Einflussfaktor verändern,
  5. Messwerte während des Tests erfassen,
  6. Test bei unerwarteten Auswirkungen abbrechen,
  7. ursprünglichen Zustand wiederherstellen,
  8. Ergebnis dokumentieren.

Ein produktiver Fehler darf nicht absichtlich durch riskante Last, Stromunterbrechung, Sicherheitsdeaktivierung oder unkontrollierte Netzwerkänderung provoziert werden.

32. Hypothese messbar formulieren

Ungeeignet:

Vielleicht ist das Netzwerk schuld.

Besser:

Wenn der Fehler auftritt, verliert der Client vermutlich kurzzeitig
die Verbindung zum Standardgateway.

Prüfung:

Client → Gateway kontinuierlich messen
Client → Server kontinuierlich messen
Client- und Switchportprotokolle vergleichen

Noch genauer:

Wenn NB-023 den Fehler erneut zeigt, muss innerhalb desselben
Zeitfensters entweder ein Link-Down-Ereignis am Client oder am
Switchport Gi1/0/12 sichtbar sein.

Eine gute Hypothese enthält:

33. Genau eine kontrollierte Änderung durchführen

Nach ausreichender Eingrenzung wird nur eine Änderung vorgenommen.

Mögliche kontrollierte Änderungen:

Nicht mehrere Änderungen gleichzeitig durchführen.

Ungeeignet:

Kabel, Switchport, Treiber und DNS gleichzeitig ändern

Danach wäre nicht mehr feststellbar, welche Änderung wirksam war.

34. Rollback festlegen

Vor der Änderung dokumentieren:

Beispiel

Änderung:
Backupstart von 14:00 Uhr auf 22:00 Uhr verschieben.

Rollback:
Ursprünglichen Startzeitpunkt 14:00 Uhr wiederherstellen.

Abbruchkriterium:
Sicherung startet nicht oder überschneidet sich mit einem anderen Auftrag.

35. Verifikation über ausreichend lange Zeit durchführen

Bei einem sporadischen Fehler reicht ein einzelner erfolgreicher Test nicht aus.

Beispiel

Fehler trat bisher ungefähr einmal täglich auf.
Nach der Änderung war das System 15 Minuten stabil.

Dieses Ergebnis ist noch kein ausreichender Nachweis.

Besser:

Beobachtungszeitraum vor Änderung: 7 Tage
Fehlerhäufigkeit vorher:           1 bis 3 Ereignisse pro Tag
Beobachtungszeitraum nach Änderung: 7 Tage
Fehlerhäufigkeit nachher:          0 Ereignisse

Zusätzlich prüfen:

36. Beispiel für eine systematische Diagnose

Symptom

Mehrere Benutzer melden an Werktagen gegen 14:17 Uhr kurze Verbindungsabbrüche zu verschiedenen internen Diensten.

Erste Beobachtung

Dauer:              10 bis 20 Sekunden
Betroffene Clients: mehrere
Betroffene Dienste: ERP, Dateiserver und Intranet
Gateway:            während der Störung erreichbar
Interne Server:     während der Störung teilweise nicht erreichbar

Kontinuierliche Messung

14:17:30 Gateway:       1 ms
14:17:30 Dateiserver:   2 ms
14:17:35 Gateway:       1 ms
14:17:35 Dateiserver:   Zeitüberschreitung
14:17:40 Gateway:       1 ms
14:17:40 Dateiserver:   Zeitüberschreitung
14:17:45 Gateway:       1 ms
14:17:45 Dateiserver:   2 ms

Switch-Monitoring

14:17:33 Server-Uplink erreicht 100 % Auslastung
14:17:34 Output Drops steigen
14:17:44 Auslastung sinkt
14:17:45 Output Drops steigen nicht weiter

Zeitgesteuerte Aufgaben

14:17:30 Replikationsauftrag startet
14:17:45 Replikationsauftrag beendet

Hypothese

Der Replikationsauftrag überlastet kurzzeitig den gemeinsamen Server-Uplink. Die entstehenden Warteschlangen und Drops verursachen Paketverlust und Anwendungsabbrüche.

Kontrollierte Maßnahme

Nach betrieblicher Freigabe wird der Replikationsauftrag in ein geeignetes Zeitfenster verschoben und mit der vorgesehenen Bandbreitensteuerung versehen.

Rollback

Ursprünglichen Zeitplan und ursprüngliche Bandbreitenrichtlinie wiederherstellen.

Verifikation

Beobachtungszeitraum: 7 Tage
Unterbrechungen:      keine
Output Drops:         keine neue Zunahme
Anwendungsfehler:     keine
Replikation:          weiterhin erfolgreich

Festgestellte Ursache

Ein regelmäßig gestarteter Replikationsauftrag erzeugte eine kurzzeitige Überlastung des gemeinsamen Uplinks.

37. Beispiel „Fehler nach acht Stunden“

Symptom

Ein Benutzer wird fast täglich am Nachmittag aus einer Anwendung abgemeldet.

Zeitvergleich

Anmeldung:       08:05 Uhr
Fehler:          16:05 Uhr
Sitzungsdauer:   8 Stunden

Weitere Tage:

Anmeldung 07:58 Uhr → Fehler 15:58 Uhr
Anmeldung 08:12 Uhr → Fehler 16:12 Uhr
Anmeldung 08:03 Uhr → Fehler 16:03 Uhr

Das Problem tritt nicht zu einer festen Uhrzeit, sondern nach einer festen Sitzungsdauer auf.

Prüfbereich

Festgestellte Ursache

Die Anwendung erneuerte ein nach acht Stunden ablaufendes Token nicht korrekt.

Lehre

Feste Uhrzeit und feste Laufzeit müssen unterschieden werden.

38. Beispiel „sporadischer Fehler durch einen Serverknoten“

Symptom

Eine Webanwendung funktioniert meistens, zeigt aber gelegentlich einen TLS- oder Serverfehler.

Aufbau

Client
  |
Load Balancer
  |
  +-- Webserver 1
  +-- Webserver 2
  +-- Webserver 3

Beobachtung

Zielknoten Ergebnis
Webserver 1 funktioniert
Webserver 2 funktioniert
Webserver 3 Fehler
Zugriff über Load Balancer nur gelegentlich Fehler

Festgestellte Ursache

Nur Webserver 3 besitzt eine fehlerhafte Konfiguration. Der Fehler tritt deshalb nur auf, wenn der Load Balancer eine Anfrage diesem Knoten zuweist.

Lehre

Bei verteilten Systemen müssen alle Knoten einzeln verglichen werden.

39. Ungeeignete Sofortmaßnahmen

Nicht als erste Maßnahme verwenden:

Solche Maßnahmen können Beweise vernichten, neue Störungen verursachen oder Sicherheits- und Betriebsvorgaben verletzen.

40. Vollständige Prüfreihenfolge

  1. genaue Fehlermeldung und Benutzeraktion erfassen.
  2. exakten Zeitpunkt und Dauer dokumentieren.
  3. betroffenen Benutzer, Client und Standort bestimmen.
  4. betroffene Anwendung und Zielsysteme erfassen.
  5. prüfen, ob ein oder mehrere Benutzer betroffen sind.
  6. feste Uhrzeit von fester Laufzeit unterscheiden.
  7. Häufigkeit und wiederkehrendes Muster bestimmen.
  8. Zeitsynchronisation aller beteiligten Systeme prüfen.
  9. Monitoring- und Protokollaufbewahrung prüfen.
  10. kontinuierliche Messung mit Zeitstempeln einrichten.
  11. Gateway, internes Ziel und externes Ziel vergleichen.
  12. TCP-Port und Anwendungsantwort getrennt prüfen.
  13. Windows- oder Linux-Protokolle zeitlich filtern.
  14. Client-, Netzwerk- und Serverprotokolle vergleichen.
  15. Monitoringauflösung kontrolliert erhöhen.
  16. Schnittstellenstatus und Link-Flaps beobachten.
  17. Fehler- und Verwerfungszähler als Verlauf erfassen.
  18. WLAN-Ereignisse, Roaming und Retry-Rate prüfen.
  19. DHCP-Lease und mögliche Adresskonflikte untersuchen.
  20. DNS-Auflösung, TTL und unterschiedliche Antworten prüfen.
  21. Sitzungslaufzeiten, Token und Timeouts vergleichen.
  22. Zertifikatslaufzeiten und Serverknoten prüfen.
  23. geplante Aufgaben, Timer und Cronjobs untersuchen.
  24. Backups, Scans, Updates und Replikationen vergleichen.
  25. CPU, Arbeitsspeicher, Storage und Netzwerk überwachen.
  26. Temperatur, Stromversorgung und PoE berücksichtigen.
  27. WAN-, Provider- und VPN-Ereignisse prüfen.
  28. bei Bedarf autorisierten Ringpuffer-Mitschnitt einrichten.
  29. alle Ereignisse auf einer gemeinsamen Zeitleiste darstellen.
  30. zuerst auftretendes Ereignis von Folgefehlern unterscheiden.
  31. genau eine messbare Hypothese formulieren.
  32. kontrollierte Reproduktion planen.
  33. Ausgangszustand und Rollback dokumentieren.
  34. genau eine freigegebene Änderung durchführen.
  35. ursprüngliche Messungen wiederholen.
  36. ausreichend langen Beobachtungszeitraum einhalten.
  37. Nebenwirkungen und Sicherheitsfunktionen kontrollieren.
  38. temporäre Diagnosemaßnahmen entfernen.
  39. Ursache, Maßnahme, Rollback und Nachweis dokumentieren.

41. Checkliste „Fehler tritt nur manchmal auf“

42. Schnellreferenz

Beobachtung Nächster Prüfbereich
Fehler immer zur gleichen Uhrzeit geplante Aufgaben, Backups, Scans oder Updates
Fehler immer nach gleicher Laufzeit Sitzung, Token, Lease, Timeout oder Zertifikat
nur ein Client betroffen Client, Treiber, Kabel, WLAN oder lokale Software
mehrere Clients gleichzeitig betroffen gemeinsame Infrastruktur oder zentraler Dienst
Gateway ebenfalls nicht erreichbar Clientzugang, WLAN, Switchport oder lokales Netz
Gateway erreichbar, Server nicht interner Folgepfad, Servernetz oder Server
nur Anwendung fehlerhaft Dienst, Sitzung, Datenbank oder Anwendung
nur ein Serverknoten fehlerhaft Konfiguration dieses Knotens
Link-Up-/Link-Down-Ereignisse Kabel, Port, Transceiver, Treiber oder Stromversorgung
CRC-Fehler steigen kurzzeitig physischer Übertragungsweg
Output Drops steigen kurzzeitig Auslastung oder nachgelagerter Engpass
Fehler während Backup Netzwerk-, CPU- oder Storage-Auslastung vergleichen
Fehler beim DNS-TTL-Ablauf DNS-Server, Cache und Zieladressen vergleichen
Fehler bei DHCP-Erneuerung DHCP-Server, Lease und Adresskonflikte
Fehler nur im WLAN Funkstrecke, Roaming, Kanal, Airtime oder Access Point
Fehler nur über VPN Tunnel, Gateway, Timeout, MTU oder Internetpfad
Fehler bei hoher Temperatur Kühlung, Lüfter oder Hardware
Monitoring zeigt nichts Messintervall und Aggregation prüfen
Neustart beseitigt Fehler vorübergehend Zustand vor dem Neustart vollständig erfassen
Ereignisse verschiedener Systeme passen nicht Uhrzeit, Zeitzone und NTP prüfen
Fehler nicht direkt reproduzierbar kontinuierliche Messung und Ringpuffer einsetzen

Merksatz

Bei einem sporadischen Fehler ist der genaue Zeitpunkt der wichtigste Ausgangspunkt. Messungen und Protokolle müssen bereits vor dem nächsten Auftreten bereitstehen. Erst durch Zeitstempel, wiederkehrende Muster und eine gemeinsame Ereigniszeitleiste lassen sich Ursache und Folge zuverlässig voneinander unterscheiden.

Quellen und weiterführende Dokumentation

7. Schnelle Entscheidungsbäume

7.7 Netzwerk oder Anwendung ist langsam

1. Ziel dieser Seite

Die Meldung „Das Netzwerk ist langsam“ beschreibt zunächst nur die Wahrnehmung des Benutzers. Die tatsächliche Ursache kann unter anderem im Client, im Netzwerk, auf dem Server, im Storage, in der Datenbank oder in der Anwendung liegen.

Diese Seite zeigt, wie ein Leistungsproblem systematisch eingegrenzt wird.

Ziel ist die Unterscheidung zwischen:

2. „Langsam“ messbar beschreiben

Ungeeignet:

Das Netzwerk ist langsam.

Besser:

Das Öffnen einer 20-MB-Datei vom Dateiserver dauert seit 09:30 Uhr
ungefähr 45 Sekunden. Normalerweise dauert es weniger als 5 Sekunden.
Betroffen sind drei Benutzer im zweiten Obergeschoss.
Internetseiten und das Standardgateway reagieren normal.

Zu erfassen sind:

Beispiel

Merkmal Beobachtung
Aktion Öffnen einer Datei vom Dateiserver
Dateigröße 20 MB
Normalzustand 3 bis 5 Sekunden
aktueller Zustand 40 bis 50 Sekunden
Beginn seit ungefähr 09:30 Uhr
Betroffene drei Benutzer
Standort zweites Obergeschoss
Verbindung WLAN
Internet normal
Gateway normal erreichbar
Dateiserver hohe Antwortzeit

Erst durch einen solchen Vergleich wird aus einer subjektiven Meldung ein messbares Problem.

3. Wichtige Leistungsbegriffe unterscheiden

Begriff Bedeutung
Latenz Zeit, die ein Datenpaket oder eine Anfrage bis zur Antwort benötigt
Paketverlust Anteil der Pakete, die ihr Ziel nicht erreichen
Bandbreite theoretisch oder technisch verfügbare Übertragungskapazität
Durchsatz tatsächlich übertragene Datenmenge pro Zeiteinheit
Jitter Schwankung der Laufzeit aufeinanderfolgender Pakete
Antwortzeit gesamte Dauer einer Anfrage aus Benutzersicht
IOPS Anzahl der Ein- und Ausgabeoperationen eines Speichers pro Sekunde
Storage-Latenz Wartezeit einer Speicheroperation
CPU-Auslastung Anteil der aktuell verwendeten Prozessorleistung
Arbeitsspeicherauslastung Belegung des physischen Arbeitsspeichers
Warteschlange Anforderungen, die auf Verarbeitung oder Übertragung warten
Retransmission erneute Übertragung verlorener oder nicht bestätigter TCP-Daten
Applikationslatenz Zeit, welche die Anwendung für die Verarbeitung benötigt

Eine schnelle Netzwerkverbindung garantiert keinen hohen Anwendungsdurchsatz.

Beispiel

Verbindungsgeschwindigkeit: 1 Gbit/s
tatsächlicher Dateidurchsatz: 8 Mbit/s

Die angezeigte Verbindungsgeschwindigkeit beschreibt nur die ausgehandelte Verbindung. Sie beweist nicht, dass die gesamte Strecke oder das Zielsystem diese Datenrate bereitstellen kann.

4. Mögliche Ursachenbereiche

Benutzeraktion
      ↓
Client
      ↓
lokale Verbindung
      ↓
Switch, WLAN oder VPN
      ↓
Routing, Firewall oder WAN
      ↓
Server
      ↓
Anwendung
      ↓
Datenbank oder Storage

Eine Verzögerung kann an jeder Stelle dieser Kette entstehen.

Client

Netzwerk

Server

Anwendung und Datenbank

5. Zuerst den Umfang bestimmen

Zu klären ist:

  1. Ist nur ein Benutzer betroffen?
  2. Sind mehrere Benutzer betroffen?
  3. Ist nur ein Standort betroffen?
  4. Sind nur WLAN-Benutzer betroffen?
  5. Sind auch kabelgebundene Clients betroffen?
  6. Ist nur eine Anwendung langsam?
  7. Sind mehrere Dienste desselben Servers betroffen?
  8. Sind interne und externe Ziele betroffen?
  9. Tritt das Problem zu einer bestimmten Uhrzeit auf?
  10. Tritt es nur bei einer bestimmten Datenmenge auf?

Schnelle Eingrenzung

Beobachtung Wahrscheinlicher Prüfbereich
nur ein Client betroffen Client, Treiber, Kabel, WLAN oder lokale Software
mehrere Clients gleichzeitig betroffen gemeinsame Infrastruktur oder zentraler Dienst
nur ein Standort betroffen Standortanbindung, Switch, WLAN oder WAN
nur WLAN betroffen Funkstrecke, Access Point, Kanal oder Roaming
LAN und WLAN betroffen gemeinsamer Netzwerkpfad, Server oder Anwendung
nur eine Anwendung betroffen Anwendung, Datenbank, API oder Sitzung
mehrere Dienste eines Servers betroffen Server, Betriebssystem, Storage oder Hypervisor
alle internen Dienste langsam Netzwerk, DNS, Firewall oder zentrale Infrastruktur
nur Internet langsam WAN, Provider, Proxy oder externe Ziele
nur große Dateien langsam Durchsatz, Paketverlust, Storage oder Übertragungsweg
kleine Anfragen bereits langsam Latenz, DNS, Anwendung oder Datenbank

6. Vergleich mit einer funktionierenden Referenz

Ein Vergleichssystem sollte möglichst ähnlich sein:

Beispiel

Prüfung betroffener Client Vergleichsclient
Gateway-Latenz 2 ms 2 ms
Server-Latenz 3 ms 3 ms
Dateiübertragung 4 MB/s 85 MB/s
CPU-Auslastung 15 % 20 %
Datenträgerauslastung 100 % 8 %

In diesem Beispiel ist der Netzwerkpfad zunächst unauffällig. Die lokale Datenträgerauslastung des betroffenen Clients ist dagegen auffällig.

7. Baseline festlegen

Ein Messwert ist nur aussagekräftig, wenn bekannt ist, welcher Wert normalerweise erreicht wird.

Beispiel

Normale Antwortzeit:       200 bis 400 ms
Aktuelle Antwortzeit:      4 bis 8 Sekunden
Normale Dateiübertragung:  80 bis 95 MB/s
Aktuelle Übertragung:      5 bis 12 MB/s
Normale Storage-Latenz:    2 bis 8 ms
Aktuelle Storage-Latenz:   80 bis 250 ms

Mögliche Baselines:

Messungen sollten möglichst unter vergleichbaren Bedingungen erfolgen.

8. Lokalen Client prüfen

Unter Windows:

Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 10 Name, CPU, WorkingSet

Netzwerkadapter anzeigen:

Get-NetAdapter |
    Format-Table Name, Status, LinkSpeed, InterfaceDescription

Adapterstatistiken:

Get-NetAdapterStatistics

Aktuelle IP-Konfiguration:

ipconfig /all

Unter Linux:

top

Alternativ, sofern installiert:

htop

Arbeitsspeicher:

free -h

Datenträgerbelegung:

df -h

Netzwerkschnittstellen:

Statistiken:

ip -s link show

Zu prüfen sind:

Ein ausgelasteter Client kann eine langsame Anwendung verursachen, obwohl Netzwerk und Server ordnungsgemäß arbeiten.

9. Latenz und Paketverlust messen

Unter Windows:

ping -t <ziel>

Beispiel:

ping -t 192.0.2.10

Unter Linux oder macOS:

ping <ziel>

Es sollten mehrere Ziele verglichen werden:

Client → Standardgateway
Client → interner Server
Client → externes Referenzziel

Auswertung

Gateway interner Server externes Ziel Mögliche Eingrenzung
langsam langsam langsam Clientzugang oder lokales Netzwerk
normal langsam normal interner Pfad oder Servernetz
normal normal langsam WAN, Provider oder externer Pfad
normal normal normal Anwendung, Port, Serverprozess oder Datenbank
Paketverlust Paketverlust Paketverlust lokale Verbindung oder gemeinsamer Uplink

Ping prüft ICMP-Erreichbarkeit. Eine normale Ping-Antwort beweist nicht, dass die Anwendung schnell arbeitet.

10. Netzwerkpfad untersuchen

Unter Windows:

tracert <ziel>

Unter Linux:

traceroute <ziel>

Unter macOS:

traceroute <ziel>

Falls vorhanden, kann eine fortlaufende Pfadanalyse durchgeführt werden:

mtr <ziel>

Zu prüfen sind:

Ein Router muss ICMP-Antworten nicht mit derselben Priorität wie weitergeleiteten Verkehr behandeln. Ein auffälliger Zwischenknoten allein beweist deshalb noch keinen Fehler. Entscheidend ist, ob die Beeinträchtigung auch an nachfolgenden Zielen sichtbar bleibt.

11. TCP-Port getrennt prüfen

Unter Windows:

Test-NetConnection <server> -Port <port>

Beispiel:

Test-NetConnection fileserver.example.local -Port 445

Weitere Beispiele:

Test-NetConnection webserver.example.local -Port 443

Test-NetConnection dbserver.example.local -Port 1433

Unter Linux oder macOS, sofern Netcat vorhanden ist:

nc -vz <server> <port>

Beispiel:

nc -vz webserver.example.local 443

Damit wird geprüft, ob der TCP-Verbindungsaufbau möglich ist. Die tatsächliche Antwortzeit der Anwendung wird dadurch noch nicht vollständig gemessen.

12. Anwendungsantwort mit curl messen

Gesamte Antwortzeit:

curl \
    -o /dev/null \
    -s \
    -w "DNS: %{time_namelookup}\nTCP: %{time_connect}\nTLS: %{time_appconnect}\nErstes Byte: %{time_starttransfer}\nGesamt: %{time_total}\n" \
    https://example.com/

Beispielausgabe:

DNS:         0.012
TCP:         0.028
TLS:         0.071
Erstes Byte: 3.842
Gesamt:      3.901

Interpretation:

Vergleich

DNS:         0,012 Sekunden
TCP:         0,028 Sekunden
TLS:         0,071 Sekunden
Erstes Byte: 3,842 Sekunden

Das Netzwerk baut die Verbindung schnell auf. Die lange Wartezeit bis zum ersten Byte weist eher auf die Verarbeitung im Zielsystem hin.

13. DNS-Antwortzeit prüfen

Unter Windows:

Measure-Command {
    Resolve-DnsName <hostname>
}

Einzelne DNS-Abfrage:

Resolve-DnsName <hostname>

Unter Linux oder macOS, sofern dig vorhanden ist:

dig <hostname>

Kurze Ausgabe:

dig <hostname> +stats

Zu prüfen sind:

Beispiel

Aufruf über IP-Adresse:  0,4 Sekunden
Aufruf über Hostnamen:   5,2 Sekunden

Dieser Unterschied weist auf die Namensauflösung hin. Er beweist noch nicht, welcher DNS-Server oder welche DNS-Konfiguration die Verzögerung verursacht.

14. Durchsatz messen

Für eine kontrollierte Netzwerkmessung kann iperf3 verwendet werden. Dafür wird auf einem autorisierten Zielsystem ein iperf3-Server benötigt.

Server:

iperf3 -s

Client:

iperf3 -c <server-ip>

Messung in Gegenrichtung:

iperf3 -c <server-ip> -R

Mehrere parallele Verbindungen:

iperf3 -c <server-ip> -P 4

UDP-Tests dürfen nur kontrolliert und mit begrenzter Bandbreite durchgeführt werden:

iperf3 -c <server-ip> -u -b 10M

Zu vergleichen sind:

Wichtig

Ein unkontrollierter Durchsatztest kann produktive Verbindungen beeinträchtigen. Zielsystem, Testdauer und erzeugte Last müssen abgestimmt sein.

15. Dateitransfer richtig bewerten

Ein Dateitransfer misst nicht ausschließlich das Netzwerk.

Beteiligt sind:

Quelldatenträger
      ↓
Quellsystem
      ↓
Netzwerk
      ↓
Zielsystem
      ↓
Zieldatenträger

Mögliche Begrenzungen:

Beispiel

Eine Datei mit 10 GB:          80 MB/s
100.000 sehr kleine Dateien:    8 MB/s

Viele kleine Dateien erzeugen wesentlich mehr Verwaltungs- und Speicheroperationen. Die niedrigere Übertragungsrate beweist deshalb nicht automatisch ein Netzwerkproblem.

16. Interface-Fehler und Drops prüfen

Unter Windows:

Get-NetAdapterStatistics

Unter Linux:

ip -s link show

Auf einem verwalteten Switch müssen die herstellerspezifischen Diagnosebefehle verwendet werden.

Zu beobachten sind:

Zähler müssen als Verlauf betrachtet werden.

Beispiel

09:00 Uhr:  15 CRC-Fehler
09:30 Uhr:  15 CRC-Fehler
10:00 Uhr:  15 CRC-Fehler

Der Zähler steigt nicht. Die Fehler können aus einem früheren Zeitraum stammen.

09:00 Uhr:    15 CRC-Fehler
09:30 Uhr:   280 CRC-Fehler
10:00 Uhr: 4.500 CRC-Fehler

Der Zähler nimmt aktuell zu und weist auf ein Problem des physischen Übertragungswegs hin.

17. Duplex und Verbindungsgeschwindigkeit prüfen

Mögliche Symptome:

Zu prüfen sind:

Geschwindigkeit und Duplex dürfen nicht wahllos fest eingestellt werden. Beide Seiten müssen zusammenpassen und die Änderung muss dokumentiert sowie freigegeben sein.

18. WLAN-Leistung untersuchen

Bei WLAN-Verbindungen sind zusätzlich zu betrachten:

Unter Windows:

netsh wlan show interfaces

WLAN-Bericht:

netsh wlan show wlanreport

Wichtiger Vergleich:

Test LAN WLAN Eingrenzung
Anwendung schnell langsam WLAN oder Access Point
Anwendung langsam langsam gemeinsamer Pfad, Server oder Anwendung
nur ein WLAN-Client langsam – betroffen Client, Treiber, Standort oder Funkband
alle Clients eines AP langsam – betroffen Access Point, Kanal, Uplink oder PoE

Ein hoher angezeigter WLAN-Verbindungswert entspricht nicht automatisch dem tatsächlichen Nutzdurchsatz.

19. VPN-Verbindung untersuchen

Mögliche Ursachen:

Zu vergleichen sind:

ohne VPN → internes Testziel, sofern autorisiert erreichbar
mit VPN  → internes Testziel
mit VPN  → Standardgateway des lokalen Netzes
mit VPN  → VPN-Gateway

Außerdem sollte geprüft werden:

VPN- oder Sicherheitsfunktionen dürfen nicht zur Diagnose umgangen werden.

20. Serverressourcen prüfen

Wichtige Messwerte:

Unter Linux:

uptime

free -h

df -h

top

Falls installiert:

vmstat 1

iostat -xz 1

Unter Windows können Task-Manager, Ressourcenmonitor, Leistungsüberwachung und PowerShell verwendet werden.

Beispiel für Prozesse mit hoher CPU-Zeit:

Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 10 Name, CPU, WorkingSet

Ein einzelner aktueller Messwert reicht bei sporadischen Problemen nicht aus. Die Werte müssen während der tatsächlichen Verzögerung aufgezeichnet werden.

21. CPU-Auslastung richtig interpretieren

Eine hohe CPU-Auslastung kann auf einen Engpass hinweisen, muss aber im Zusammenhang betrachtet werden.

Zu prüfen sind:

Beispiel

Gesamtauslastung: 35 %
Anwendungsprozess: ein Prozesskern dauerhaft bei 100 %

Eine nicht ausreichend parallelisierte Anwendung kann bereits durch einen vollständig ausgelasteten Kern begrenzt werden, obwohl die Gesamtauslastung unauffällig wirkt.

22. Arbeitsspeicher und Paging prüfen

Hohe Speicherbelegung allein beweist keinen Fehler. Betriebssysteme nutzen freien Arbeitsspeicher häufig als Cache.

Wichtiger sind:

Typische Wirkung

Arbeitsspeicher reicht nicht aus
            ↓
Auslagerung auf Datenträger
            ↓
Storage-Latenz steigt
            ↓
Anwendung reagiert langsam

Deshalb müssen Arbeitsspeicher- und Storage-Messwerte gemeinsam betrachtet werden.

23. Storage-Latenz untersuchen

Eine hohe Datenträgerauslastung bedeutet nicht automatisch einen hohen Datendurchsatz. Viele kleine oder zufällige Operationen können einen Datenträger vollständig auslasten.

Zu prüfen sind:

Beispiel

Netzwerkauslastung:  12 %
CPU-Auslastung:      30 %
Storage-Latenz:     180 ms
Anwendungsantwort:    8 s

Die niedrige Netzwerkauslastung spricht gegen einen reinen Bandbreitenengpass. Die hohe Storage-Latenz ist dagegen auffällig.

Hersteller- und betriebssystemspezifische Grenzwerte müssen anhand der jeweiligen Dokumentation und des normalen Betriebszustands bewertet werden.

24. Datenbank als Ursache untersuchen

Mögliche Ursachen:

Zu vergleichen sind:

Beispiel

TCP-Verbindung zum Webserver:      20 ms
Antwort des Webservers:             6 s
Datenbankabfrage:                 5,7 s

Das Netzwerk ist in diesem Beispiel nicht der größte Zeitanteil. Die Datenbankabfrage bestimmt nahezu die gesamte Antwortzeit.

Produktive Abfragen dürfen nicht unkontrolliert wiederholt oder verändert werden. Datenbankdiagnosen müssen mit den vorgesehenen Werkzeugen und Berechtigungen erfolgen.

25. Anwendungs- und API-Abhängigkeiten prüfen

Eine Anwendung kann von mehreren Diensten abhängig sein:

Client
  ↓
Webanwendung
  ↓
Authentifizierungsdienst
  ↓
API
  ↓
Datenbank
  ↓
Storage

Zu prüfen sind:

Beispiel

Anwendung selbst:          100 ms
externe API:             4.800 ms
Gesamtantwort:           5.100 ms

Aus Benutzersicht ist die Anwendung langsam. Die eigentliche Verzögerung entsteht jedoch bei einer externen API.

26. Load Balancer und mehrere Serverknoten prüfen

Bei verteilten Anwendungen kann nur ein einzelner Knoten langsam sein.

Beispiel

Zielknoten Antwortzeit
Webserver 1 250 ms
Webserver 2 230 ms
Webserver 3 8.400 ms
Zugriff über Load Balancer wechselnd zwischen schnell und langsam

Mögliche Ursachen des einzelnen Knotens:

Alle Knoten müssen einzeln verglichen werden. Ein gelegentlich langsamer Zugriff über den Load Balancer kann entstehen, wenn nur ein Teil der Anfragen an den fehlerhaften Knoten gelangt.

27. Zeitgesteuerte Last berücksichtigen

Leistungsprobleme können regelmäßig mit anderen Prozessen zusammenfallen:

Beispiel

02:00:00 Backup startet
02:00:12 Storage-Latenz steigt
02:00:18 Datenbankabfragen werden langsamer
02:00:25 Anwendung überschreitet Zeitlimit
02:20:00 Backup endet
02:20:15 Storage-Latenz normalisiert sich

Eine gemeinsame Zeitleiste zeigt die mögliche Abhängigkeit.

Der zeitliche Zusammenhang ist ein Hinweis. Die Ursache muss durch Messwerte und gegebenenfalls eine kontrollierte Änderung bestätigt werden.

28. Paketmitschnitt gezielt einsetzen

Ein Paketmitschnitt kann unter anderem zeigen:

Beispiel mit dumpcap:

dumpcap \
    -i 1 \
    -f "host 192.0.2.45" \
    -b duration:300 \
    -b files:12 \
    -w langsame-anwendung.pcapng

Dabei gelten folgende Regeln:

Ein Mitschnitt auf dem Client zeigt nicht automatisch alle Pakete anderer Systeme oder Netzwerksegmente.

29. TCP-Retransmissions bewerten

TCP überträgt verlorene Daten erneut. Viele erneute Übertragungen können den Durchsatz erheblich reduzieren.

Mögliche Ursachen:

Vereinfachtes Beispiel

Datenpaket wird gesendet
        ↓
Paket geht verloren
        ↓
Bestätigung bleibt aus
        ↓
TCP wartet
        ↓
Daten werden erneut übertragen

Die Bandbreite kann technisch hoch sein, während der tatsächlich nutzbare Durchsatz durch Paketverlust stark sinkt.

30. Ursache und Wartezeit trennen

Eine langsame Anwendung kann in verschiedene Zeitanteile zerlegt werden.

Beispiel

Verarbeitungsschritt Dauer
DNS-Auflösung 20 ms
TCP-Verbindungsaufbau 25 ms
TLS-Verbindungsaufbau 70 ms
Webserververarbeitung 180 ms
Datenbankabfrage 4.800 ms
Übertragung der Antwort 90 ms
Gesamtdauer 5.185 ms

Die Datenbankabfrage beansprucht den größten Teil der Gesamtdauer.

Dadurch kann die Diagnose auf den Bereich mit dem größten Zeitanteil konzentriert werden.

31. Mehrere Systeme auf einer Zeitleiste vergleichen

Zeit Client Netzwerk Server Storage Anwendung
09:59:50 normal normal normal 4 ms 300 ms
10:00:00 Anfrage startet normal CPU 40 % 8 ms 400 ms
10:00:05 wartet normal CPU 45 % 170 ms 5 s
10:00:10 wartet normal CPU 48 % 240 ms 10 s
10:00:15 Antwort normal CPU 42 % 12 ms normal

In diesem Beispiel steigen die Netzwerklatenz und CPU-Auslastung nicht auffällig. Die Storage-Latenz steigt dagegen zeitgleich mit der langsamen Anwendung.

32. Hypothese messbar formulieren

Ungeeignet:

Der Server ist wahrscheinlich überlastet.

Besser:

Wenn die Anwendung erneut länger als fünf Sekunden benötigt,
steigt vermutlich gleichzeitig die Storage-Latenz des Datenbankservers
auf mehr als 100 ms.

Prüfung:

Anwendungsantwortzeit messen
Storage-Latenz aufzeichnen
Datenbankwartezeiten erfassen
Zeitstempel vergleichen

Eine gute Hypothese enthält:

33. Kontrollierte Änderung durchführen

Erst nach ausreichender Eingrenzung wird genau eine Änderung vorgenommen.

Mögliche Änderungen:

Ungeeignet:

Treiber aktualisieren, Kabel ersetzen, DNS ändern und Server neu starten.

Wenn mehrere Änderungen gleichzeitig durchgeführt werden, kann die wirksame Maßnahme nicht mehr eindeutig bestimmt werden.

34. Rollback festlegen

Vor jeder Änderung dokumentieren:

Beispiel

Änderung:
Fehlerhaften Webserver 3 kontrolliert aus dem Load Balancer nehmen.

Erwartung:
Die wechselnden Antwortzeiten verschwinden.

Rollback:
Webserver 3 mit der ursprünglichen Gewichtung wieder aufnehmen.

Abbruchkriterium:
Verbleibende Knoten überschreiten die zulässige Auslastung.

35. Verifikation

Nach der Änderung müssen dieselben Messungen wie vorher wiederholt werden.

Zu prüfen sind:

Beispiel

Vorher:
Antwortzeit:       6 bis 12 Sekunden
Storage-Latenz:   120 bis 260 ms
Fehlerhäufigkeit:  20 bis 30 Ereignisse pro Stunde

Nachher:
Antwortzeit:       250 bis 400 ms
Storage-Latenz:    3 bis 8 ms
Fehlerhäufigkeit:  0 Ereignisse in 48 Stunden

Ein einzelner erfolgreicher Test reicht nicht aus, wenn das Problem vorher nur gelegentlich auftrat.

36. Beispiel „Netzwerk angeblich langsam“

Symptom

Mehrere Benutzer melden, dass das Öffnen von Kundendatensätzen am Vormittag mehrere Sekunden dauert.

Erste Messungen

Gateway-Latenz:             1 ms
Webserver-Latenz:           2 ms
Paketverlust:               0 %
TCP-Verbindungsaufbau:     20 ms
Zeit bis zum ersten Byte:   7 s

Servermessungen

CPU-Auslastung:            35 %
Arbeitsspeicher:           unauffällig
Netzwerkauslastung:        10 %
Storage-Latenz:             6 ms

Datenbankmessung

Abfragedauer:              6,7 s
Warteursache:              Datenbanksperre

Festgestellte Ursache

Ein zeitgleich laufender Import hielt eine Datenbanksperre. Netzwerk und Webserver waren nicht die Ursache.

Kontrollierte Maßnahme

Der Importprozess wurde nach Prüfung so angepasst, dass die Sperre kürzer gehalten wird.

Verifikation

Antwortzeit:              300 bis 450 ms
Paketverlust:             weiterhin 0 %
Datenbanksperren:         keine auffällige Wartezeit
Import:                   weiterhin erfolgreich

37. Beispiel „Dateiserver ist langsam“

Symptom

Ein Benutzer erreicht beim Kopieren großer Dateien nur ungefähr 8 MB/s.

Vergleich

Messung betroffener Client Referenzclient
Verbindung 1 Gbit/s 1 Gbit/s
Ping zum Server 2 ms 2 ms
iperf3 920 Mbit/s 925 Mbit/s
Dateiübertragung 8 MB/s 90 MB/s
lokale Datenträgerauslastung 100 % 15 %

Festgestellte Ursache

Der lokale Zieldatenträger des betroffenen Clients war der Engpass. Die Netzwerkverbindung erreichte im kontrollierten Durchsatztest einen normalen Wert.

Lehre

Ein langsamer Dateitransfer ist nicht automatisch ein langsames Netzwerk.

38. Beispiel „WLAN ist langsam“

Symptom

Benutzer in einem Besprechungsraum melden am Nachmittag langsame Anwendungen und Videokonferenzen.

Vergleich

LAN:                         normal
WLAN außerhalb des Raums:    normal
WLAN im Besprechungsraum:    langsam

Messwerte

Signalstärke:                ausreichend
Kanalauslastung:             sehr hoch
Retry-Rate:                  stark erhöht
aktive Clients:              42
AP-Uplink:                   unauffällig

Festgestellte Ursache

Der Funkkanal war stark ausgelastet. Viele erneute Übertragungen reduzierten den tatsächlichen Durchsatz.

Kontrollierte Maßnahme

Die Funkplanung wurde anhand der vorgesehenen WLAN-Managementfunktionen angepasst.

Verifikation

Retry-Rate:                  deutlich reduziert
Anwendungsantwortzeit:       normal
Videokonferenzen:            stabil

39. Ungeeignete Sofortmaßnahmen

Nicht als erste Maßnahme verwenden:

Solche Maßnahmen können Beweise vernichten, neue Fehler verursachen oder die eigentliche Ursache verdecken.

40. Vollständige Prüfreihenfolge

  1. genaue Benutzeraktion erfassen.
  2. erwartete und tatsächliche Dauer dokumentieren.
  3. Startzeitpunkt, Häufigkeit und Dauer bestimmen.
  4. betroffene Benutzer, Clients und Standorte erfassen.
  5. LAN, WLAN und VPN unterscheiden.
  6. einzelne Anwendung und allgemeines Systemverhalten vergleichen.
  7. betroffenen Client mit Referenzclient vergleichen.
  8. normalen Leistungsbereich als Baseline bestimmen.
  9. lokale CPU-, Speicher- und Datenträgerauslastung prüfen.
  10. Verbindungsgeschwindigkeit und Adapterstatus prüfen.
  11. Gateway, internes Ziel und externes Ziel messen.
  12. Latenz und Paketverlust getrennt betrachten.
  13. Netzwerkpfad untersuchen.
  14. TCP-Port prüfen.
  15. DNS-Antwortzeit messen.
  16. Anwendungsantwort in einzelne Zeitanteile zerlegen.
  17. kontrollierten Durchsatztest durchführen.
  18. Interface-Fehler, Drops und Retransmissions prüfen.
  19. WLAN-Auslastung und Retry-Rate berücksichtigen.
  20. VPN-Pfad und VPN-Gateway prüfen.
  21. Server-CPU und Arbeitsspeicher überwachen.
  22. Paging, Swapping und Ressourcenlimits prüfen.
  23. Storage-Latenz und Warteschlangen untersuchen.
  24. Datenbankabfragen, Sperren und Verbindungen prüfen.
  25. APIs und externe Abhängigkeiten untersuchen.
  26. alle Serverknoten einzeln vergleichen.
  27. geplante Aufgaben und Hintergrundprozesse prüfen.
  28. Messwerte auf einer gemeinsamen Zeitleiste darstellen.
  29. größten Zeitanteil bestimmen.
  30. Ursache und Folge unterscheiden.
  31. genau eine messbare Hypothese formulieren.
  32. Ausgangszustand und Rollback dokumentieren.
  33. genau eine freigegebene Änderung durchführen.
  34. ursprüngliche Messung wiederholen.
  35. ausreichend lange Verifikation durchführen.
  36. Nebenwirkungen kontrollieren.
  37. temporäre Diagnosemaßnahmen entfernen.
  38. Ursache, Maßnahme und Nachweis dokumentieren.

41. Checkliste „Netzwerk oder Anwendung ist langsam“

42. Schnellreferenz

Beobachtung Nächster Prüfbereich
nur ein Client langsam Client, Treiber, Datenträger oder lokale Software
alle Clients langsam gemeinsame Infrastruktur, Server oder Anwendung
Gateway bereits langsam lokaler Zugang, WLAN, Kabel oder Switch
Gateway normal, Server langsam interner Pfad, Servernetz oder Server
Ping normal, Anwendung langsam Anwendung, Datenbank, API oder Storage
DNS langsam DNS-Server, Weiterleitung oder Namensauflösung
TCP-Aufbau langsam Netzwerkpfad, Firewall oder Zielsystem
erstes Byte langsam Server, Anwendung oder Datenbank
Download nach erstem Byte langsam Durchsatz, Paketverlust oder Datenmenge
iperf3 schnell, Dateiübertragung langsam Datenträger, Dateisystem, Virenscanner oder Protokoll
CRC-/FCS-Fehler steigen Kabel, Stecker, Port oder Transceiver
Output Drops steigen Auslastung oder nachgelagerter Engpass
nur WLAN langsam Funkkanal, Retry-Rate, Roaming oder Access Point
nur VPN langsam Internetpfad, VPN-Gateway, MTU oder Verschlüsselung
nur ein Serverknoten langsam Konfiguration oder Ressource dieses Knotens
CPU dauerhaft hoch Prozess, Last oder unzureichende Rechenleistung
CPU unauffällig, Storage-Latenz hoch Storage, Backup, Snapshot oder Datenträger
Speicherdruck und Paging Arbeitsspeicher, Prozess oder Ressourcenlimit
Anwendung während Backup langsam Storage-, Netzwerk- und CPU-Auslastung vergleichen
Fehler nur bei großen Datenmengen Durchsatz, Paketverlust, Storage oder Zeitlimit
Fehler nur bei vielen kleinen Dateien IOPS, Dateisystem und Virenscanner
Monitoring zeigt nichts Messintervall, Maximum und kurzfristige Spitzen prüfen

Merksatz

„Langsam“ ist zunächst nur ein Symptom. Erst durch den Vergleich von Latenz, Paketverlust, Durchsatz, Anwendungsantwortzeit, Serverressourcen, Storage und Datenbankwartezeiten lässt sich bestimmen, an welcher Stelle die tatsächliche Verzögerung entsteht.

Quellen und weiterführende Dokumentation

7. Schnelle Entscheidungsbäume

7.8 Server ist langsam

Ziel dieser Seite

Diese Seite beschreibt die systematische Fehleranalyse, wenn ein Server oder ein darauf bereitgestellter Dienst ungewöhnlich langsam reagiert.

Dabei muss zwischen verschiedenen Ursachen unterschieden werden:

„Der Server ist langsam“ ist lediglich eine Symptombeschreibung. Erst durch Messwerte lässt sich bestimmen, welche Ressource oder Abhängigkeit den Engpass verursacht.

1. Problem exakt beschreiben

Vor der technischen Analyse müssen Soll- und Istzustand dokumentiert werden.

Angabe Beispiel
betroffener Server SRV-APP01
betroffener Dienst interne Webanwendung
Symptom Seitenaufbau dauert 15 Sekunden
Normalzustand unter 2 Sekunden
Beginn 02.08.2026, etwa 09:15 Uhr
Umfang alle Benutzer
Häufigkeit zeitweise
letzter funktionierender Zustand vor dem nächtlichen Backup
letzte Änderung Anwendungsupdate
Vergleichssystem SRV-APP02 reagiert normal

Zu klären ist:

Die Aussage „der Server ist langsam“ reicht für eine gezielte Fehleranalyse nicht aus.

2. Server-, Anwendungs- und Netzwerkproblem unterscheiden

Ein langsamer Dienst beweist nicht automatisch, dass der Server selbst überlastet ist.

Client
  ↓
DNS
  ↓
Netzwerk
  ↓
Firewall oder Proxy
  ↓
Webserver
  ↓
Anwendung
  ↓
Datenbank
  ↓
Storage

Jede dieser Komponenten kann die beobachtete Verzögerung verursachen.

Beobachtung Wahrscheinlicher Prüfbereich
lokale Bedienung ebenfalls langsam Serverressourcen oder Betriebssystem
nur entfernte Zugriffe langsam Netzwerk, VPN, Firewall oder Proxy
nur eine Anwendung langsam Anwendung, Datenbank oder Abhängigkeit
alle Dienste langsam CPU, RAM, Storage, Hypervisor oder Netzwerk
nur bestimmte Abfragen langsam Datenbank, Sperren oder fehlende Indizes
nur zu festen Uhrzeiten langsam Backup, Scan, Wartung oder geplanter Job
nur eine VM betroffen VM-Konfiguration oder Gastbetriebssystem
mehrere VMs auf demselben Host betroffen Hypervisor oder gemeinsames Storage
Ping normal, Anwendung langsam Dienst, TLS, Authentifizierung oder Backend
Ping langsam oder instabil Netzwerkpfad oder Serverüberlastung
Zugriff per IP schnell, per Name langsam DNS-Auflösung
Anmeldung langsam, Dienste danach normal Authentifizierung, GPO, Profil oder DNS

3. Auswirkungen und Priorität bestimmen

Vor der tieferen Analyse muss die betriebliche Auswirkung bewertet werden.

Zu klären ist:

Beispiel:

Kriterium Bewertung
Auswirkung alle Mitarbeiter können nur verzögert arbeiten
Dringlichkeit hoch
Priorität hoch
Ersatzlösung zweiter Anwendungsserver vorhanden
Datenverlust derzeit nicht erkennbar
Eskalation Anwendungs- und Infrastrukturteam informieren

Eine hohe Auslastung ist nicht automatisch ein kritischer Vorfall. Entscheidend ist, ob der vereinbarte Dienst beeinträchtigt wird.

4. Ausgangszustand sichern

Vor einem Neustart oder einer Konfigurationsänderung sollten flüchtige Informationen gesichert werden:

Ein Neustart kann das Symptom vorübergehend beseitigen, vernichtet aber möglicherweise den für die Ursachenanalyse benötigten Zustand.

Vor einer Maßnahme sollte daher mindestens dokumentiert werden:

Zeitpunkt:
betroffener Dienst:
gemessene Antwortzeit:
CPU:
RAM:
Datenträger:
Netzwerk:
auffälliger Prozess:
auffälliges Ereignis:
laufender Hintergrundjob:
letzte Änderung:

5. Sichere Schnellprüfung

Die erste Prüfung sollte möglichst nur lesend erfolgen.

  1. Zeitpunkt und Umfang der Störung bestimmen.
  2. CPU, RAM, Datenträger und Netzwerk gleichzeitig betrachten.
  3. Prozesse mit ungewöhnlicher Ressourcennutzung ermitteln.
  4. Backups, Virenscans, Snapshots und Wartungsjobs prüfen.
  5. Betriebssystem-, Anwendungs- und Hypervisorlogs zeitlich vergleichen.
  6. Antwortzeit vom Client und direkt auf dem Server messen.
  7. Mit einem funktionierenden Vergleichssystem vergleichen.
  8. Erst danach eine kontrollierte Maßnahme auswählen.

Windows:

Get-Date

Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 10 Name, Id, CPU, WorkingSet64

Linux:

date
uptime
top

Diese Momentaufnahmen reichen noch nicht für eine vollständige Bewertung. Kurze Spitzen oder zeitweise auftretende Fehler können dabei unentdeckt bleiben.

6. CPU-Auslastung untersuchen

Eine hohe CPU-Auslastung kann durch einen einzelnen Prozess, mehrere konkurrierende Prozesse oder eine zu geringe bereitgestellte Rechenleistung verursacht werden.

Zu prüfen sind:

Windows:

Get-Counter '\Processor(_Total)\% Processor Time'

Prozesse nach gesamter CPU-Zeit sortieren:

Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 15 Name, Id, CPU, Threads

Aktuelle Prozessorauslastung über CIM:

Get-CimInstance Win32_Processor |
    Select-Object Name, LoadPercentage

Linux:

top

Mit installiertem Paket sysstat:

pidstat 1

Auslastung pro logischer CPU:

mpstat -P ALL 1
Befund Mögliche Bedeutung
ein Prozess belegt dauerhaft einen Kern Single-Thread-Engpass oder Endlosschleife
alle Kerne dauerhaft stark ausgelastet CPU-Sättigung
hohe Systemzeit Kernel, Treiber, Netzwerk oder I/O prüfen
viele Interrupts Netzwerk- oder Hardwareproblem möglich
CPU im Gast niedrig, Anwendung trotzdem langsam Storage, Netzwerk, Sperren oder Hypervisor prüfen
mehrere VMs gleichzeitig langsam Hostüberlastung oder CPU-Scheduling prüfen
kurze regelmäßige Spitzen geplanter Job, Scan oder Monitoring
Prozess-CPU steigt ständig fehlerhafte Anwendung oder unpassende Last

Eine Gesamtauslastung von beispielsweise 25 Prozent schließt einen CPU-Engpass nicht aus. Auf einem System mit vier logischen Prozessoren kann ein einzelner vollständig ausgelasteter Thread ungefähr 25 Prozent Gesamtauslastung verursachen.

7. Arbeitsspeicher untersuchen

Ein hoher belegter Arbeitsspeicher ist nicht automatisch ein Fehler. Betriebssysteme verwenden verfügbaren Speicher beispielsweise für Caches.

Entscheidend sind:

Windows:

Get-CimInstance Win32_OperatingSystem |
    Select-Object TotalVisibleMemorySize,
                  FreePhysicalMemory

Prozesse nach Arbeitsspeicher sortieren:

Get-Process |
    Sort-Object WorkingSet64 -Descending |
    Select-Object -First 15 Name,
                            Id,
                            WorkingSet64,
                            PagedMemorySize64

Leistungsindikatoren abfragen:

Get-Counter `
    '\Memory\Available MBytes',
    '\Memory\Pages/sec'

Linux:

free -h

Ausführlichere Anzeige:

vmstat 1

Prozesse nach Speichernutzung sortieren:

ps aux --sort=-%mem | head
Befund Mögliche Bedeutung
wenig freier Speicher, aber keine Auslagerung nicht zwingend problematisch
dauerhaft starke Paging- oder Swap-Aktivität Arbeitsspeicherengpass
ein Prozess wächst kontinuierlich mögliches Speicherleck
Anwendung erreicht festgelegtes Limit Container-, VM- oder Prozesslimit prüfen
Server wird nach längerer Laufzeit langsamer Speicherleck oder zunehmender Cache möglich
OOM-Ereignis unter Linux Speicher war erschöpft
hoher Commit-Wert unter Windows zugesicherter virtueller Speicher prüfen

Nur den belegten Arbeitsspeicher zu betrachten, reicht nicht aus. Besonders Paging, Swap und die zeitliche Entwicklung sind entscheidend.

8. Datenträger und Storage untersuchen

Ein langsamer Datenträger kann den gesamten Server ausbremsen, obwohl CPU und Arbeitsspeicher unauffällig erscheinen.

Zu prüfen sind:

Windows-Leistungsindikatoren:

Get-Counter `
    '\PhysicalDisk(_Total)\Avg. Disk sec/Read',
    '\PhysicalDisk(_Total)\Avg. Disk sec/Write',
    '\PhysicalDisk(_Total)\Current Disk Queue Length',
    '\PhysicalDisk(_Total)\Disk Reads/sec',
    '\PhysicalDisk(_Total)\Disk Writes/sec'

Freien Speicherplatz prüfen:

Get-Volume |
    Select-Object DriveLetter,
                  FileSystemLabel,
                  FileSystem,
                  Size,
                  SizeRemaining

Linux:

df -h

Blockgeräte anzeigen:

lsblk

I/O-Auslastung mit installiertem sysstat:

iostat -xz 1

Prozesse mit I/O-Aktivität:

pidstat -d 1
Befund Mögliche Bedeutung
hohe Latenz bei geringer Datenrate langsames oder blockiertes Storage
Warteschlange wächst dauerhaft Datenträger kann Anfragen nicht schnell genug verarbeiten
freier Speicherplatz nahezu erschöpft Dateisystem, Datenbank oder Anwendung beeinträchtigt
mehrere VMs gleichzeitig betroffen gemeinsames Storage prüfen
Problem während eines Backups konkurrierende I/O-Last
hohe I/O-Wartezeit unter Linux Prozesse warten auf Storage
RAID degradiert Leistung und Ausfallsicherheit reduziert
Snapshot wächst stark zusätzliche Storage-Belastung möglich

Allgemeine Grenzwerte dürfen nur als Orientierung verwendet werden. Ob eine Latenz problematisch ist, hängt vom Speichermedium, der Anwendung und den vereinbarten Leistungswerten ab.

9. Netzwerk untersuchen

Ein Netzwerkproblem kann aus Benutzersicht wie ein langsamer Server wirken.

Zu prüfen sind:

Windows:

Test-Connection SRV-APP01 -Count 10

TCP-Port prüfen:

Test-NetConnection SRV-APP01 -Port 443

Netzwerkadapter anzeigen:

Get-NetAdapter |
    Select-Object Name,
                  Status,
                  LinkSpeed,
                  MacAddress

Adapterstatistiken:

Get-NetAdapterStatistics

Aktive TCP-Verbindungen:

Get-NetTCPConnection |
    Group-Object State |
    Sort-Object Count -Descending

Linux:

ping -c 10 srv-app01

Route untersuchen:

traceroute srv-app01

Socketübersicht:

ss -s

Interfaceinformationen:

ip -s link

DNS-Auflösung prüfen:

dig srv-app01.example.local
Befund Mögliche Bedeutung
Paketverlust Überlastung, fehlerhafter Link oder Routingproblem
schwankende Latenz Überlastung oder instabiler Netzwerkpfad
Zugriff per IP schnell, per Name langsam DNS prüfen
nur VPN-Benutzer betroffen VPN-Gateway, Tunnel oder Internetverbindung
Fehlerzähler steigen Kabel, Port, Treiber oder Netzwerkkarte
Anwendung lokal schnell, entfernt langsam Netzwerkpfad, Proxy oder Firewall
nur große Übertragungen problematisch MTU, Bandbreite oder Paketverlust prüfen
viele Verbindungen im Wartezustand Anwendung, Netzwerk oder Porterschöpfung

Ein erfolgreicher Ping beweist nur eingeschränkt die Funktionsfähigkeit. Er prüft nicht automatisch den eigentlichen Anwendungsport oder die Antwortzeit des Dienstes.

10. DNS untersuchen

Langsame oder fehlerhafte Namensauflösung kann viele Serverdienste beeinträchtigen.

Typische Auswirkungen:

Windows:

Resolve-DnsName SRV-DB01

Konfigurierte DNS-Server:

Get-DnsClientServerAddress

DNS-Zwischenspeicher:

Get-DnsClientCache

Linux:

resolvectl status

Namensauflösung messen:

time getent hosts srv-db01.example.local

Mit dig:

dig srv-db01.example.local

Zu prüfen sind:

11. Prozesse und Dienste untersuchen

Nicht jede hohe Ressourcennutzung ist die Ursache. Der auffällige Prozess kann selbst nur auf eine andere Komponente warten.

Windows-Dienste:

Get-Service |
    Where-Object Status -eq 'Running'

Automatisch startende, aber nicht laufende Dienste:

Get-CimInstance Win32_Service |
    Where-Object {
        $_.StartMode -eq 'Auto' -and
        $_.State -ne 'Running'
    } |
    Select-Object Name, DisplayName, State, StartMode

Linux-Dienste:

systemctl --failed

Status eines Dienstes:

systemctl status nginx

Zu prüfen sind:

Ein Dienstneustart sollte erst erfolgen, nachdem relevante Messwerte und Protokolle gesichert wurden.

12. Anwendung untersuchen

Wenn nur eine Anwendung langsam ist, muss deren interner Ablauf betrachtet werden.

Mögliche Ursachen:

Zu prüfen sind:

Beispielhafte Abgrenzung:

Startseite schnell
Suchfunktion langsam
        ↓
Suchfunktion getrennt untersuchen
        ↓
Anwendungslog und Datenbankabfrage vergleichen

Nicht sofort den gesamten Server neu starten, wenn nur ein einzelner Anwendungsbereich betroffen ist.

13. Datenbank untersuchen

Datenbanken können trotz geringer CPU-Auslastung langsam reagieren.

Mögliche Ursachen:

Zu prüfen sind:

Beispielhafte Ursache-Wirkungs-Kette:

lange Datenbankabfrage
        ↓
Anwendungs-Worker wartet
        ↓
Verbindungspool wird belegt
        ↓
weitere Benutzer müssen warten
        ↓
Anwendung erscheint vollständig langsam

Änderungen an Indizes, Abfragen oder Datenbankparametern sollten nur nach Sicherung und Abstimmung mit der verantwortlichen Stelle erfolgen.

14. Hintergrundjobs prüfen

Regelmäßig auftretende Leistungseinbrüche sprechen häufig für geplante Prozesse.

Typische Verursacher:

Windows – geplante Aufgaben:

Get-ScheduledTask |
    Where-Object State -eq 'Running'

Linux – systemd-Timer:

systemctl list-timers

Cron-Konfiguration prüfen:

crontab -l

Zu vergleichen sind:

Eine zeitliche Übereinstimmung ist ein Hinweis, aber noch kein vollständiger Ursachennachweis.

15. Protokolle zeitlich vergleichen

Protokolle müssen mit dem dokumentierten Störungszeitpunkt abgeglichen werden.

Windows-Systemereignisse:

Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    StartTime = (Get-Date).AddHours(-2)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  Message

Windows-Anwendungsereignisse:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Application'
    StartTime = (Get-Date).AddHours(-2)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  Message

Linux:

journalctl --since "2 hours ago"

Fehler mit hoher Priorität:

journalctl -p err --since "2 hours ago"

Kernelmeldungen:

journalctl -k --since "2 hours ago"

Zu suchen sind:

Ein einzelner protokollierter Fehler beweist nicht automatisch die Ursache. Zeitliche Übereinstimmung, technische Wirkung und Reproduzierbarkeit müssen zusammenpassen.

16. Virtuelle Maschinen untersuchen

Bei einer virtuellen Maschine müssen Gast und Hypervisor getrennt betrachtet werden.

Im Gast zu prüfen:

Auf dem Hypervisor zu prüfen:

Typische Konstellation:

VM zeigt geringe CPU-Auslastung
        ↓
Anwendung ist trotzdem langsam
        ↓
Hypervisor prüfen
        ↓
VM erhält CPU-Zeit verzögert

Mehr virtuelle CPUs verbessern die Leistung nicht automatisch. Zu viele vCPUs können das Scheduling erschweren und die Wartezeit erhöhen.

17. Container untersuchen

Bei Containern müssen zusätzlich Limits und der Hostzustand berücksichtigt werden.

Zu prüfen sind:

Docker:

docker stats

Laufende Container:

docker ps

Containerzustand:

docker inspect CONTAINERNAME

Protokollausgabe:

docker logs --since 2h CONTAINERNAME

Ressourcenlimits anzeigen:

docker inspect CONTAINERNAME \
    --format 'Memory={{.HostConfig.Memory}} NanoCPUs={{.HostConfig.NanoCpus}}'

Ein Container kann langsam sein, obwohl der Host noch freie Ressourcen besitzt, wenn für den Container selbst ein niedriges Limit festgelegt wurde.

18. Externe Abhängigkeiten prüfen

Eine Anwendung kann auf andere Systeme warten, obwohl der eigene Server unauffällig ist.

Mögliche Abhängigkeiten:

Zu prüfen sind:

Beispiel:

Webserver reagiert lokal schnell
        ↓
Anmeldung dauert 20 Sekunden
        ↓
Anwendung wartet auf Verzeichnisdienst
        ↓
DNS- oder LDAP-Verbindung untersuchen

19. Hardwarezustand prüfen

Bei physischen Servern müssen auch Hardwareprobleme berücksichtigt werden.

Mögliche Ursachen:

Zu prüfen sind:

Linux – vorhandene Hardwarewarnungen:

dmesg --level=err,warn

SMART-Werte dürfen nur mit passenden Werkzeugen und unter Berücksichtigung des verwendeten Controllers geprüft werden.

20. Letzte Änderungen untersuchen

Leistungsprobleme treten häufig nach einer Veränderung auf.

Mögliche Änderungen:

Zu dokumentieren sind:

Änderung Zeitpunkt Verantwortlich Mögliche Auswirkung
Anwendungsupdate 08:30 Uhr Anwendungsteam neue Abfrage oder Fehler
Backupzeit geändert 09:00 Uhr Betriebsteam höhere Storage-Last
neue VM gestartet 09:10 Uhr Virtualisierungsteam Hostressourcen
GPO geändert Vortag Administration Dienst- oder Sicherheitseinstellung

Die zeitliche Nähe einer Änderung zum Fehler ist ein wichtiges Indiz, aber kein alleiniger Beweis.

21. Baseline und Vergleichswerte verwenden

Ohne Vergleichswerte lässt sich schwer beurteilen, ob ein Messwert ungewöhnlich ist.

Eine Baseline kann enthalten:

Beispiel:

Messwert Normalzustand Störungszeitpunkt
Antwortzeit 1,5 s 15 s
CPU 35 % 42 %
verfügbarer RAM 8 GB 7,5 GB
Storage-Latenz 4 ms 85 ms
aktive Benutzer 120 125

In diesem Beispiel spricht der Vergleich stärker für ein Storage-Problem als für CPU-, RAM- oder Benutzerlast.

22. Korrelation und Ursache unterscheiden

Zwei gleichzeitig auftretende Ereignisse müssen nicht ursächlich zusammenhängen.

Beispiel:

CPU-Auslastung steigt
Anwendung wird langsam

Mögliche Interpretationen:

  1. Die hohe CPU-Auslastung verursacht die Verzögerung.
  2. Die langsame externe Abhängigkeit führt zu zusätzlichen Wiederholungen und erhöht dadurch die CPU-Auslastung.
  3. Ein dritter Prozess verursacht gleichzeitig beide Effekte.
  4. Die CPU-Auslastung ist normal und nicht relevant.

Ein Ursachennachweis wird stärker, wenn:

23. Kontrollierte Maßnahmen durchführen

Nach der Analyse sollte genau eine passende Maßnahme durchgeführt werden.

Mögliche Maßnahmen:

Vor jeder Maßnahme:

Danach:

24. Warum ein Neustart nicht die erste Maßnahme sein sollte

Ein Neustart kann:

Er kann aber auch:

Ein Neustart ist daher keine vollständige Ursachenanalyse.

Falls ein Neustart erforderlich ist, sollten vorher mindestens folgende Informationen gesichert werden:

25. Nachkontrolle

Nach einer Maßnahme muss nicht nur die Ressourcenauslastung, sondern auch die eigentliche Funktion geprüft werden.

Zu kontrollieren sind:

Beispiel:

Vorher:
Antwortzeit 15 Sekunden
Storage-Latenz 85 ms

Maßnahme:
konkurrierenden Backupjob beendet

Nachher:
Antwortzeit 1,7 Sekunden
Storage-Latenz 5 ms

Erst der Vergleich vor und nach der Maßnahme zeigt, ob die vermutete Ursache tatsächlich zum Problem beigetragen hat.

26. Dokumentation

Die Abschlussdokumentation sollte enthalten:

Beispiel:

Symptom:
Webanwendung benötigte statt 1–2 Sekunden etwa 15 Sekunden.

Ursache:
Der gleichzeitig laufende Backupjob verursachte eine hohe
Latenz auf dem gemeinsam genutzten Storage.

Maßnahme:
Backupjob kontrolliert beendet und Zeitplan angepasst.

Ergebnis:
Antwortzeit wieder unter 2 Sekunden.
Storage-Latenz wieder im üblichen Bereich.

Vorbeugung:
Monitoring für Storage-Latenz eingerichtet und Backupfenster geändert.

27. Entscheidungsbaum

Server oder Dienst langsam
        ↓
Ist der gesamte Server betroffen?
        ├── Ja
        │   ↓
        │   CPU, RAM, Storage, Netzwerk und Hypervisor prüfen
        │
        └── Nein
            ↓
        Nur eine Anwendung betroffen?
                ├── Ja
                │   ↓
                │   Anwendung, Datenbank und Abhängigkeiten prüfen
                │
                └── Nein
                    ↓
                Gemeinsame Komponente der betroffenen Dienste suchen

Erweiterte Eingrenzung:

Problem nur aus der Ferne?
        ├── Ja → Netzwerk, DNS, VPN, Firewall oder Proxy
        └── Nein
             ↓
Problem nur zu festen Zeiten?
        ├── Ja → Backup, Scan, Wartung oder geplanter Job
        └── Nein
             ↓
Mehrere VMs auf einem Host betroffen?
        ├── Ja → Hypervisor und gemeinsames Storage
        └── Nein → Gastbetriebssystem und Anwendung

28. Häufige Fehlerbilder

Fehlerbild Wahrscheinlicher Prüfbereich
Server reagiert nach Neustart wieder schnell Speicherleck, blockierter Prozess oder wartende Ressource
Problem kehrt regelmäßig zurück Ursache wurde nicht behoben oder geplanter Job
CPU dauerhaft hoch Prozess, Thread, Malware, Scan oder zu geringe Leistung
CPU niedrig, Server trotzdem langsam Storage, Netzwerk, Locks oder externe Abhängigkeit
RAM nahezu vollständig belegt Paging und Speicherdruck prüfen
Swap-Nutzung steigt dauerhaft Arbeitsspeicherengpass
Datenträger dauerhaft ausgelastet Backup, Datenbank, Scan oder langsames Storage
nur Datenbankfunktionen langsam Abfragen, Locks, Indizes oder Storage
nur Anmeldung langsam DNS, Verzeichnisdienst, GPO oder Benutzerprofil
nur Webzugriff langsam Webserver, TLS, Proxy, Anwendung oder Datenbank
nur bestimmte Uhrzeit betroffen geplanter Job oder Lastspitze
mehrere VMs betroffen Host, Netzwerk oder gemeinsames Storage
nur eine VM betroffen Gastbetriebssystem, Limits oder VM-Konfiguration
Zugriff per IP schnell DNS-Auflösung prüfen
lokal schnell, entfernt langsam Netzwerkpfad prüfen
Anwendung wartet auf Timeout externe Abhängigkeit untersuchen
Leistung nimmt über Tage ab Speicherleck, Datenwachstum oder Warteschlange

29. Typische Prüfungsfragen

Warum ist die Aussage „der Server ist langsam“ für die Fehleranalyse nicht ausreichend?

Antwort anzeigen

Die Aussage beschreibt nur ein allgemeines Symptom. Es fehlen unter anderem der betroffene Dienst, die gemessene Antwortzeit, der Normalzustand, der Zeitpunkt, der Umfang und mögliche Änderungen.

Warum beweist eine hohe CPU-Auslastung noch nicht die Fehlerursache?

Antwort anzeigen

Die Auslastung kann für die vorhandene Arbeitslast normal sein oder erst als Folge eines anderen Problems entstehen. Für einen Ursachennachweis müssen zeitlicher Zusammenhang, technische Wirkung und das Ergebnis einer kontrollierten Maßnahme geprüft werden.

Warum kann ein Server trotz niedriger CPU-Auslastung langsam sein?

Antwort anzeigen

Prozesse können auf Storage, Netzwerk, Datenbanksperren, externe Dienste oder andere Ressourcen warten. Während dieser Wartezeit wird nur wenig CPU-Leistung benötigt.

Warum ist vollständig belegter Arbeitsspeicher nicht automatisch ein Fehler?

Antwort anzeigen

Betriebssysteme verwenden freien Arbeitsspeicher unter anderem für Caches. Entscheidend sind Speicherdruck, Paging beziehungsweise Swapping und die zeitliche Entwicklung.

Warum sollten vor einem Neustart Messwerte gesichert werden?

Antwort anzeigen

Ein Neustart beendet Prozesse, leert Warteschlangen und verändert den Systemzustand. Dadurch können wichtige Hinweise auf die eigentliche Ursache verloren gehen.

Was bedeutet eine hohe Datenträgerlatenz?

Antwort anzeigen

Lese- oder Schreibanforderungen benötigen ungewöhnlich lange. Anwendungen können dadurch warten, obwohl CPU und Arbeitsspeicher unauffällig sind.

Warum reicht ein erfolgreicher Ping nicht als Nachweis für einen funktionierenden Dienst?

Antwort anzeigen

Ping prüft ICMP-Erreichbarkeit. Der eigentliche Anwendungsport, die Authentifizierung, die Verarbeitung im Dienst und dessen Backend werden dadurch nicht geprüft.

Warum müssen bei einer VM auch Hypervisorwerte geprüft werden?

Antwort anzeigen

Der Gast kann nur die ihm bereitgestellten Ressourcen sehen. Wartezeiten, Überbelegung oder Storage-Probleme auf dem Host sind im Gast möglicherweise nicht eindeutig erkennbar.

Warum sollte nach einer Maßnahme erneut gemessen werden?

Antwort anzeigen

Nur der Vergleich von Sollwert, Ausgangswert und neuem Messwert zeigt, ob die Maßnahme das eigentliche Problem behoben hat.

30. Prüfungsfallen

31. Checkliste „Server ist langsam“

32. Schnellreferenz

Beobachtung Nächster Prüfbereich
gesamte Maschine langsam CPU, RAM, Storage, Hypervisor
nur eine Anwendung langsam Anwendung, Datenbank, Abhängigkeiten
CPU dauerhaft hoch Prozess- und Threadauslastung
nur ein Kern ausgelastet Single-Thread-Engpass
CPU niedrig, Antwortzeit hoch Storage, Netzwerk, Locks
starke Paging-Aktivität Arbeitsspeicher
hohe I/O-Wartezeit Datenträger oder Storage
wenig freier Speicherplatz Dateisystem und Datenwachstum
lokale Nutzung schnell Netzwerk, DNS, Proxy oder Firewall
Zugriff per IP schnell DNS
Paketverlust vorhanden Netzwerkpfad
nur bestimmte Uhrzeit betroffen geplante Aufgaben
Problem während Backup Storage- und Netzwerkbelastung
mehrere VMs betroffen Hypervisor und gemeinsames Storage
nur eine VM betroffen Gast, Limits und virtuelle Hardware
Container wird gedrosselt CPU- und Speicherlimit
bestimmte Datenbankabfrage langsam Locks, Indizes und Ausführungsplan
Anmeldung langsam DNS, AD, GPO oder Profil
Anwendung wartet auf Timeout externe Abhängigkeit
nach Neustart vorübergehend schnell Speicherleck, Warteschlange oder blockierter Prozess
Hardwarewarnung vorhanden Herstellerdiagnose und Austauschplanung

Merksatz

Ein langsamer Server wird nicht durch Vermutungen, sondern durch Eingrenzung und Messwerte untersucht. Entscheidend ist, ob CPU, Arbeitsspeicher, Storage, Netzwerk, Anwendung, Datenbank, Hypervisor oder eine externe Abhängigkeit den tatsächlichen Engpass verursacht. Vor einer Änderung wird der Ausgangszustand gesichert, anschließend wird genau eine kontrollierte Maßnahme durchgeführt und ihre Wirkung erneut gemessen.

Quellen und weiterführende Dokumentation

7. Schnelle Entscheidungsbäume

7.9 Ping funktioniert, Anwendung nicht

Ein Server antwortet auf einen Ping, die eigentliche Anwendung ist jedoch nicht erreichbar oder funktioniert nicht vollständig.

Dieses Fehlerbild entsteht häufig, weil ein erfolgreicher Ping fälschlicherweise als Nachweis für die Funktionsfähigkeit des gesamten Dienstes interpretiert wird. Ping prüft jedoch nur einen begrenzten Teil der Kommunikationskette.

7.9.1 Typisches Fehlerbild

Mögliche Meldungen und Beobachtungen:

Die Diagnose muss deshalb über ICMP hinausgehen und den tatsächlichen Anwendungsweg prüfen.

7.9.2 Diagnoseziel

Ziel ist es, eindeutig festzustellen:

Ein möglicher Fehlerbereich darf erst dann als Ursache gelten, wenn er durch ein reproduzierbares Prüfergebnis, ein Protokoll oder einen Paketmitschnitt bestätigt wurde.

7.9.3 Kommunikationskette der Anwendung

Eine typische Anwendungsverbindung kann mehrere voneinander unabhängige Prüfebenen enthalten:

  1. Anwendungskonfiguration
  2. Namensauflösung
  3. Auswahl von IPv4 oder IPv6
  4. lokales Routing
  5. VPN oder Proxy
  6. Clientfirewall
  7. Netzwerkfirewall oder ACL
  8. NAT oder Portweiterleitung
  9. Load Balancer oder Reverse Proxy
  10. TCP- oder UDP-Kommunikation
  11. TLS-Handshake
  12. Anwendungsprotokoll
  13. Authentifizierung
  14. Autorisierung
  15. Backenddienste
  16. vollständiger Benutzerablauf

Ein Fehler auf einer späteren Ebene kann auftreten, obwohl alle vorherigen Ebenen funktionieren.

Beispiele:

7.9.4 Was Ping tatsächlich prüft

Ping verwendet normalerweise ICMP-Echo-Anfragen und ICMP-Echo-Antworten.

Ein erfolgreicher Ping bestätigt für den konkreten Testzeitpunkt grundsätzlich:

Ping kann zusätzlich Hinweise liefern auf:

Das antwortende System muss jedoch nicht zwingend der erwartete Anwendungsserver sein. Bei virtuellen IP-Adressen, Load Balancern, Firewalls oder falsch aufgelösten Namen kann ein anderes System antworten.

7.9.5 Was Ping nicht beweist

Ein erfolgreicher Ping beweist nicht:

Ebenso beweist ein fehlgeschlagener Ping nicht automatisch, dass der Server oder die Anwendung ausgefallen ist. ICMP kann absichtlich blockiert, begrenzt oder niedriger priorisiert werden, während der eigentliche Anwendungsdienst weiterhin erreichbar ist.

7.9.6 Fehlerumfang bestimmen

Vor technischen Änderungen muss der Umfang des Fehlers festgestellt werden.

Zu prüfen sind:

Geeignete Vergleichstests:

Vergleich Mögliche Eingrenzung
gleicher Benutzer an anderem Client clientbezogener Fehler
anderer Benutzer am gleichen Client benutzerbezogener Fehler
gleicher Client in anderem Netz Netzwerkpfad oder standortbezogene Regel
Zugriff mit und ohne VPN VPN-Route, DNS, Proxy, Firewall oder MTU
IPv4 und IPv6 getrennt adressfamilienbezogener Fehler
direkter Anwendungstest und Zugriff über Proxy Proxy- oder Reverse-Proxy-Fehler
lokaler Test auf dem Server und entfernter Test Dienstfehler oder externer Netzwerkpfad
einfacher Endpunkt und vollständiger Benutzerablauf Backend- oder Anwendungsfehler

Kreuztests dürfen nur kontrolliert durchgeführt werden. Produktive Zugangsdaten oder vertrauliche Daten dürfen nicht ungeschützt in Diagnoseausgaben übernommen werden.

7.9.7 Ausgangszustand sichern

Vor einem Neustart oder einer Konfigurationsänderung sollten mindestens folgende Informationen gesichert werden:

Ein vorschneller Neustart kann flüchtige Hinweise beseitigen, beispielsweise:

Änderungen dürfen erst nach Sicherung des Ausgangszustands erfolgen.

7.9.8 Tatsächliches Ziel der Anwendung bestimmen

Vor jedem Port- oder Protokolltest muss geklärt werden, welches Ziel die Anwendung wirklich anspricht.

Zu erfassen sind:

Anwendung:
Benutzerfunktion:
Servername:
Vollständiger DNS-Name:
Verwendete IP-Adresse:
IPv4 oder IPv6:
Transportprotokoll:
Port:
Anwendungsprotokoll:
URL oder Ressourcenpfad:
Proxy:
VPN:
Load Balancer oder Reverse Proxy:
Fehlerzeitpunkt:

Die Anwendungskonfiguration kann vom vermuteten Standard abweichen.

Mögliche Einflussquellen:

Besonders wichtig:

Die im Fehlerzeitpunkt verwendete Zieladresse sollte aus der Anwendung, einem Verbindungsprotokoll oder einem Paketmitschnitt bestätigt werden.

7.9.9 Namensauflösung prüfen

Windows:

Resolve-DnsName -Name <Servername> -Type A
Resolve-DnsName -Name <Servername> -Type AAAA

Linux:

getent ahosts <Servername>
dig <Servername> A
dig <Servername> AAAA

macOS:

dscacheutil -q host -a name <Servername>
dig <Servername> A
dig <Servername> AAAA

Zu vergleichen sind:

Ein erfolgreicher Ping auf einen Namen beweist nur, dass für diesen Ping-Aufruf eine Namensauflösung möglich war. Die Antwort kann aus DNS, einer Hosts-Datei oder einem anderen lokalen Namensauflösungsverfahren stammen.

DNS-Caches sollten nicht als erste Maßnahme gelöscht werden. Zuerst muss dokumentiert werden, welche Adresse aktuell verwendet wird und warum sie falsch sein könnte.

7.9.10 TCP-Port gezielt prüfen

Windows:

Test-NetConnection `
  -ComputerName <Servername> `
  -Port <Port> `
  -InformationLevel Detailed

Wichtige Felder:

ComputerName
RemoteAddress
RemotePort
InterfaceAlias
SourceAddress
TcpTestSucceeded

Linux und macOS:

nc -vz <Servername> <Port>

Ein erfolgreicher TCP-Test beweist:

Er beweist nicht:

7.9.11 TCP-Fehler richtig interpretieren

Ergebnis Bedeutung Nächster Nachweis
TcpTestSucceeded : True TCP-Verbindungsaufbau war möglich Anwendungsprotokoll und TLS prüfen
Connection refused Ziel oder zwischengeschaltetes System hat die Verbindung aktiv abgelehnt Listener, Port und Serverprotokoll prüfen
Verbindungs-Timeout Keine rechtzeitige TCP-Antwort Firewall, Rückweg, Routing, Überlastung oder falsche Adresse untersuchen
Name nicht gefunden Zielname konnte nicht aufgelöst werden Namensauflösung prüfen
Verbindung wird sofort getrennt Dienst lehnt Sitzung ab oder falsches Protokoll wird verwendet Dienst- und Anwendungsprotokoll prüfen
Verbindung beginnt, bleibt dann hängen Anwendung, TLS, Backend, Paketverlust oder Pfad-MTU möglich Protokolle und Paketverlauf untersuchen

Ein Timeout beweist nicht automatisch eine Firewallblockierung. Auch ein falscher Rückweg, ein überlasteter Dienst, ein fehlerhafter Load Balancer oder eine falsche IP-Adresse können zu einem Timeout führen.

7.9.12 Anwendungsprotokoll statt nur Port prüfen

Der Test muss zum tatsächlichen Dienst passen.

Dienst Geeigneter Funktionstest
HTTP oder HTTPS curl -v mit vollständiger URL
SSH ssh -vvv <Benutzer>@<Servername>
DNS Resolve-DnsName oder dig gegen den vorgesehenen DNS-Server
SMB Zugriff auf die konkrete Freigabe testen
RDP kontrollierter Verbindungsversuch mit dem RDP-Client
Datenbank nativen Datenbankclient mit einer sicheren Leseabfrage verwenden
API vorgesehenen Endpunkt, Methode, Header und Authentifizierung prüfen
herstellerspezifischer Dienst Diagnoseclient oder dokumentierten Protokolltest des Herstellers verwenden

Ein erfolgreicher Test auf TCP 3389 beweist beispielsweise nur, dass der Port erreichbar ist. Er beweist noch keine funktionierende RDP-Anmeldung oder Sitzung.

curl ist für HTTP-, HTTPS- und weitere von curl unterstützte Protokolle geeignet. Ein beliebiger TCP-Dienst darf nicht automatisch mit einer HTTP-Anfrage getestet werden.

7.9.13 HTTP und HTTPS prüfen

curl -v --connect-timeout 5 \
  "https://<Servername>:<Port>/<Pfad>"

Die Ausgabe wird schrittweise ausgewertet:

  1. Welche IP-Adresse wird verwendet?
  2. Wird eine TCP-Verbindung aufgebaut?
  3. Beginnt der TLS-Handshake?
  4. Welches Zertifikat wird präsentiert?
  5. Wird die Zertifikatsprüfung erfolgreich abgeschlossen?
  6. Welche HTTP-Anfrage wird gesendet?
  7. Welcher HTTP-Statuscode wird empfangen?
  8. Erfolgt eine Umleitung?
  9. Antwortet ein Reverse Proxy oder der erwartete Anwendungsserver?
  10. Wird eine Anwendungsfehlermeldung zurückgegeben?

Wichtige HTTP-Ergebnisse:

Status Einordnung
2xx Anfrage wurde auf HTTP-Ebene erfolgreich verarbeitet
3xx Umleitung; Ziel im Location-Header prüfen
401 Anwendung erreicht, Authentifizierung erforderlich oder fehlgeschlagen
403 Anwendung erreicht, Zugriff wird verweigert
404 Dienst antwortet, angeforderter Pfad oder virtuelle Zuordnung fehlt
407 Proxy verlangt eine Authentifizierung
5xx Server, Gateway oder Backend meldet einen Fehler

Auch eine gültige HTTP-Fehlerantwort beweist, dass bereits mehrere Prüfebenen erfolgreich durchlaufen wurden. Sie beweist jedoch nicht, dass die benötigte Benutzerfunktion arbeitet.

7.9.14 Bestimmte IP-Adresse mit richtigem Hostnamen testen

Bei HTTPS sollte nicht einfach die IP-Adresse in die URL eingesetzt werden. Dadurch können sich SNI, Host-Header und Zertifikatsprüfung verändern.

Mit curl kann ein Servername kontrolliert einer bestimmten Adresse zugeordnet werden:

curl -v \
  --resolve <Servername>:<Port>:<IP-Adresse> \
  "https://<Servername>:<Port>/<Pfad>"

Damit bleiben der Servername in der URL, der HTTP-Host und die TLS-SNI-Angabe erhalten, während die Verbindung gezielt zur angegebenen IP-Adresse aufgebaut wird.

Dieser Test ist hilfreich bei:

Das Ergebnis gilt nur für die getestete Kombination aus Name, Adresse, Port und Pfad.

7.9.15 TLS kurz prüfen

Für HTTPS oder andere TLS-Dienste:

openssl s_client \
  -connect <Servername>:<Port> \
  -servername <Servername> \
  -verify_hostname <Servername> \
  -verify_return_error

Zu prüfen sind:

Die Vertrauensstellung von OpenSSL kann sich vom Zertifikatsspeicher der eigentlichen Anwendung unterscheiden. Ein erfolgreicher OpenSSL-Test beweist deshalb nicht automatisch, dass jeder Client dem Zertifikat vertraut.

Zertifikatsprüfungen dürfen nicht dauerhaft mit Optionen wie -k oder --insecure umgangen werden. Die ausführliche TLS-Diagnose erfolgt auf Seite 7.14.

7.9.16 Proxy und anwendungsspezifischen Verbindungsweg prüfen

Eine Anwendung kann einen Proxy verwenden, obwohl ein direkter Porttest erfolgreich ist. Umgekehrt kann ein direkter Test scheitern, während der Zugriff ausschließlich über einen Proxy vorgesehen ist.

Windows – WinHTTP-Konfiguration:

netsh winhttp show proxy

Umgebungsvariablen in PowerShell:

Get-ChildItem Env: |
  Where-Object Name -Match '^(HTTP|HTTPS|NO)_PROXY$'

Linux:

env | grep -iE '^(http|https|no)_proxy='

macOS:

scutil --proxy

env | grep -iE '^(http|https|no)_proxy='

Zusätzlich zu prüfen:

netsh winhttp show proxy zeigt nur die WinHTTP-Konfiguration. Daraus darf nicht automatisch auf die Konfiguration jedes Browsers oder jeder Anwendung geschlossen werden.

7.9.17 Listener auf dem Server prüfen

Wenn der TCP-Port von außen nicht erreichbar ist, muss geprüft werden, ob der Dienst auf dem Server tatsächlich lauscht.

Windows:

Get-NetTCPConnection `
  -LocalPort <Port> `
  -State Listen |
  Select-Object LocalAddress, LocalPort, State, OwningProcess

Zugehörigen Prozess prüfen:

Get-Process -Id <PID>

Linux:

sudo ss -lntp

macOS:

sudo lsof -nP \
  -iTCP:<Port> \
  -sTCP:LISTEN

Zu prüfen sind:

Typische Bindungsbefunde:

Bindungsadresse Bedeutung
127.0.0.1 nur lokale IPv4-Verbindungen
::1 nur lokale IPv6-Verbindungen
konkrete Serveradresse nur über diese Adresse beziehungsweise Schnittstelle
0.0.0.0 alle lokalen IPv4-Adressen
[::] alle lokalen IPv6-Adressen; zusätzliches IPv4-Verhalten ist systemabhängig

Ein Dienst, der ausschließlich auf 127.0.0.1 lauscht, kann lokal funktionieren und trotzdem von entfernten Clients nicht erreichbar sein.

7.9.18 Lokalen und entfernten Zugriff vergleichen

Auf dem Server kann zunächst ein lokaler Anwendungstest durchgeführt werden:

curl -v \
  "http://127.0.0.1:<Port>/<Pfad>"

Bei einem namensabhängigen HTTPS-Dienst:

curl -v \
  --resolve <Servername>:<Port>:127.0.0.1 \
  "https://<Servername>:<Port>/<Pfad>"

Der lokale Test muss an die tatsächliche Listeneradresse angepasst werden. Ein Dienst, der nur an eine bestimmte Serveradresse gebunden ist, muss über diese Adresse geprüft werden.

Lokaler Test Entfernter Test Wahrscheinlicher Bereich
schlägt fehl schlägt fehl Dienst, Listener, Konfiguration oder Backend
funktioniert TCP-Port schlägt fehl Listenerbindung, Hostfirewall oder Netzwerkpfad
funktioniert TCP-Port funktioniert, Protokoll schlägt fehl TLS, Reverse Proxy, virtueller Host oder Anwendung
funktioniert curl vom Client funktioniert Problem im eigentlichen Client oder Benutzerkontext
funktioniert nur über Loopback entfernt nicht erreichbar falsche Listenerbindung wahrscheinlich
funktioniert über eine Serveradresse über andere Adresse nicht Schnittstelle, Routing, DNS oder Firewallregel

Ein lokaler Erfolg beweist nicht, dass die vollständige externe Zugriffskette funktioniert.

7.9.19 Firewall, ACL, NAT und Load Balancer prüfen

ICMP und Anwendungsverkehr können durch unterschiedliche Regeln behandelt werden.

Zu prüfen sind:

Mögliche Konstellationen:

Firewalls dürfen nicht pauschal deaktiviert werden. Stattdessen müssen Protokoll, Quelladresse, Zieladresse, Port, Richtung und Treffer der konkreten Regel geprüft werden.

7.9.20 Authentifizierung und Autorisierung abgrenzen

Wenn eine Anwendung eine Anmeldemaske, einen HTTP-Statuscode oder eine konkrete Berechtigungsfehlermeldung zurückgibt, wurde die Anwendungsebene bereits erreicht.

Zu unterscheiden sind:

Geeignete Kreuztests:

Test Erkenntnis
anderer Benutzer am selben Client benutzerbezogener Fehler möglich
gleicher Benutzer an anderem Client clientbezogener Fehler möglich
kontrolliertes Testkonto Konto- oder Rechteproblem eingrenzen
anonymer oder öffentlicher Endpunkt Netzwerk und Anwendung ohne Benutzeranmeldung prüfen
lokales Anwendungskonto Abhängigkeit vom Verzeichnisdienst untersuchen

Kontosperren und produktive Benutzerkonten müssen berücksichtigt werden. Die Domänenanmeldung wird ausführlich auf Seite 7.10 behandelt.

7.9.21 Anwendungsabhängigkeiten untersuchen

Ein erreichbarer Frontend-Port bedeutet nicht, dass alle Backenddienste funktionieren.

Mögliche Abhängigkeiten:

Typische Befunde:

Anwendungs-, Proxy- und Backendprotokolle müssen anhand des gleichen Fehlerzeitpunkts korreliert werden.

Container-Neustartschleifen werden auf Seite 7.12 und volle Datenträger auf Seite 7.13 ausführlich behandelt.

7.9.22 UDP-Dienste korrekt prüfen

UDP besitzt keinen TCP-ähnlichen Verbindungsaufbau. Ein allgemeiner UDP-Porttest kann daher nicht sicher beweisen, dass der Dienst funktioniert.

Für UDP muss eine gültige Anfrage des tatsächlichen Anwendungsprotokolls gesendet und die Antwort geprüft werden.

DNS-Test unter Windows:

Resolve-DnsName `
  -Name <Abzufragender-Name> `
  -Server <DNS-Server>

DNS-Test unter Linux oder macOS:

dig @<DNS-Server> <Abzufragender-Name> A

Ein fehlender UDP-Fehler beweist nicht, dass:

Bei UDP-Diensten sind Anwendungsprotokoll, Serverprotokoll und gegebenenfalls ein kontrollierter Paketmitschnitt besonders wichtig.

7.9.23 IPv4 und IPv6 getrennt prüfen

Ein Name kann gleichzeitig A- und AAAA-Einträge besitzen. Ping und Anwendung können unterschiedliche Adressfamilien auswählen.

Mit curl getrennt testen:

curl -4 -v \
  "https://<Servername>:<Port>/<Pfad>"

curl -6 -v \
  "https://<Servername>:<Port>/<Pfad>"

Zu prüfen sind:

Wenn ausschließlich IPv6 fehlschlägt, muss der IPv6-Pfad oder der AAAA-Eintrag korrigiert werden. IPv6 sollte nicht ohne Ursachenanalyse dauerhaft deaktiviert werden.

7.9.24 Paketgröße und Übertragungsverhalten berücksichtigen

Ein kleiner ICMP-Ping kann funktionieren, während größere Anwendungsdaten hängen bleiben.

Mögliche Ursachen:

Typische Hinweise:

Ein erfolgreicher Standard-Ping darf deshalb nicht als vollständiger Nachweis eines fehlerfreien Datenpfads verwendet werden.

7.9.25 Paketmitschnitt kontrolliert einsetzen

Linux oder macOS:

sudo tcpdump -ni <Interface> \
  host <IP-Adresse> and port <Port>

Alternativ kann Wireshark mit einem passenden Erfassungsfilter verwendet werden.

Typische Beobachtungen:

Beobachtung Einordnung
wiederholte SYN-Pakete ohne Antwort keine TCP-Antwort; Pfad, Regel oder Ziel prüfen
SYN wird mit RST beantwortet Port geschlossen oder Verbindung aktiv abgelehnt
SYN, SYN-ACK und ACK sichtbar TCP-Verbindung wurde aufgebaut
TCP-Verbindung wird danach sofort geschlossen Dienst oder Protokoll lehnt Verbindung ab
TLS ClientHello ohne passende Fortsetzung TLS-Pfad, Server oder Inspektion prüfen
TLS-Alert konkrete TLS-Ursache auswerten
viele Wiederholungen Paketverlust, Überlastung oder fehlerhafter Pfad möglich
Antwort verlässt den Server, erreicht Client aber nicht Rückweg oder zwischengeschaltete Regel prüfen

Ein Paketmitschnitt beweist nur, was an der jeweiligen Erfassungsstelle sichtbar ist. Bei komplexen Pfaden können Mitschnitte auf Client, Server und einem zwischengeschalteten System erforderlich sein.

Paketmitschnitte dürfen nur mit entsprechender Berechtigung erstellt und müssen datenschutzgerecht gespeichert werden.

7.9.26 Systematischer Diagnoseablauf

  1. Fehler aufnehmen
    Anwendung, Benutzer, Client, Zeitpunkt, Meldung und ursprüngliche Benutzerfunktion dokumentieren.

  2. Umfang bestimmen
    Einen Benutzer, einen Client, ein Netz oder alle Benutzer unterscheiden.

  3. Exaktes Ziel bestimmen
    Servername, Adresse, Port, Protokoll, Pfad und Verbindungsweg erfassen.

  4. Namensauflösung prüfen
    A- und AAAA-Antworten sowie tatsächlich verwendete Adresse vergleichen.

  5. Ping korrekt bewerten
    Nur ICMP-Erreichbarkeit als bestätigt betrachten.

  6. Transportprotokoll bestimmen
    TCP und UDP unterscheiden.

  7. TCP-Port oder UDP-Anwendung prüfen
    Einen zum tatsächlichen Protokoll passenden Test verwenden.

  8. Listener kontrollieren
    Port, Prozess und Bindungsadresse auf dem Server prüfen.

  9. Lokalen Anwendungstest durchführen
    Dienst auf dem Server über den vorgesehenen Namen, Port und Pfad testen.

  10. Externen Anwendungstest durchführen
    Denselben Dienst vom betroffenen Client aus prüfen.

  11. TLS untersuchen
    SNI, Zertifikat, Vertrauenskette und Protokollkompatibilität prüfen.

  12. Proxy und VPN berücksichtigen
    Tatsächlichen Verbindungsweg der Anwendung nachvollziehen.

  13. Anwendungsantwort auswerten
    Statuscode, Protokollmeldung, Umleitung oder Authentifizierungsfehler bestimmen.

  14. Abhängigkeiten prüfen
    Datenbank, Identitätsdienst, API, Speicher oder andere Backends untersuchen.

  15. Protokolle korrelieren
    Client-, Server-, Proxy- und Anwendungsprotokolle auf denselben Zeitraum begrenzen.

  16. Bei Bedarf Paketverlauf erfassen
    SYN, RST, TLS-Alert, Wiederholungen und Rückweg untersuchen.

  17. Hypothese formulieren
    Erwartetes Prüfergebnis und möglichen Gegenbeweis festlegen.

  18. Eine kontrollierte Änderung durchführen
    Risiko, Rückweg und Erfolgskriterium dokumentieren.

  19. Vollständige Funktion prüfen
    Nicht nur Ping oder Port, sondern den ursprünglichen Benutzerablauf testen.

  20. Nachkontrolle durchführen
    Protokolle, Überwachung und andere Benutzerfunktionen prüfen.

7.9.27 Befundmatrix

Befund Mögliche Erklärung Nächster Nachweis
Ping auf IP funktioniert, Name nicht Namensauflösungsproblem A-, AAAA-, Hosts- und Resolverdaten prüfen
Ping auf Name verwendet falsche Adresse veralteter oder falscher Namenseintrag autoritative und clientseitige Antwort vergleichen
Ping funktioniert, TCP-Port hat Timeout Portverkehr wird verworfen oder Antwort fehlt Firewall, Routing und Paketverlauf prüfen
Ping funktioniert, TCP-Port wird abgelehnt kein Listener oder aktive Ablehnung Listener und Prozess auf dem Server prüfen
TCP-Port funktioniert, Verbindung wird sofort geschlossen falsches Protokoll oder Dienst lehnt Sitzung ab Dienstprotokoll und Serverlogs prüfen
TCP funktioniert, TLS schlägt fehl Zertifikat, SNI, TLS-Version oder Inspektion curl -v oder openssl s_client auswerten
TLS funktioniert, HTTP 401 Authentifizierung erforderlich oder fehlerhaft Benutzer-, Token- oder Identitätsanbieter prüfen
TLS funktioniert, HTTP 403 fehlende Autorisierung oder Richtlinie Rollen und Zugriffsrichtlinie prüfen
HTTP 404 falscher Pfad oder virtuelle Zuordnung URL, Host-Header und Proxyroute prüfen
HTTP 407 Proxy-Authentifizierung erforderlich Proxyweg und Benutzerkontext prüfen
HTTP 502 Gateway erreicht Backend nicht korrekt Reverse-Proxy- und Backendprotokolle prüfen
HTTP 503 Dienst vorübergehend nicht verfügbar Healthcheck, Kapazität und Abhängigkeiten prüfen
lokal funktioniert, entfernt nicht Bindung, Hostfirewall oder Netzwerkpfad Listeneradresse und Regeln vergleichen
curl funktioniert, Anwendung nicht anwendungsspezifische Konfiguration Proxy, Cache, Zertifikatsspeicher und Benutzerkontext prüfen
nur ein Client betroffen lokaler Clientfehler anderen Client und gleichen Benutzer testen
nur ein Benutzer betroffen Konto, Profil, Rechte oder Sitzung anderes Konto am gleichen Client testen
nur über VPN betroffen Route, DNS, MTU oder VPN-Regel mit und ohne VPN vergleichen
nur IPv6 betroffen AAAA-, IPv6-Routing- oder Firewallfehler curl -4 und curl -6 vergleichen
kleine Anfragen funktionieren MTU, Paketverlust oder Kapazität möglich Paketverlauf und größere Übertragung prüfen
Port erreichbar, Geschäftsprozess scheitert Backend oder Anwendungslogik fehlerhaft vollständigen Ablauf und Abhängigkeiten prüfen

7.9.28 Mögliche Ursachen und erforderliche Nachweise

Mögliche Ursache Erforderlicher Nachweis
falscher Port Anwendungskonfiguration und tatsächlicher Listener zeigen unterschiedliche Ports
Dienst gestoppt kein Listener vorhanden und Dienststatus beziehungsweise Logs bestätigen den Ausfall
falsche Listenerbindung Dienst lauscht nur auf Loopback oder einer anderen Adresse
Hostfirewall blockiert Port konkrete Regel oder Protokoll zeigt den verworfenen Verbindungsversuch
Netzwerkfirewall oder ACL Trefferprotokoll oder beidseitiger Paketmitschnitt bestätigt die Unterbrechung
falscher DNS-Eintrag Anwendung verwendet eine nachweislich falsche oder veraltete Adresse
fehlerhafter IPv6-Pfad IPv6-Test scheitert reproduzierbar, IPv4-Test funktioniert
Proxyfehler Anwendung verwendet einen fehlerhaften Proxyweg, während direkter Test anders reagiert
Reverse-Proxy-Fehler Proxy antwortet, passende Route oder gesundes Backend fehlt
Load-Balancer-Fehler virtuelle Adresse ist erreichbar, aber Healthcheck oder Backendzustand ist fehlerhaft
TLS-Fehler TLS-Ausgabe zeigt Zertifikats-, SNI- oder Protokollproblem
fehlende Authentifizierung Anwendung antwortet mit konkretem Anmelde- oder Tokenfehler
fehlende Autorisierung Anmeldung funktioniert, Ressourcenzugriff wird nachvollziehbar verweigert
ausgefallene Backendabhängigkeit Frontend antwortet, Serverlogs belegen den Fehler der Abhängigkeit
Ressourcenengpass Fehler korreliert mit CPU, Speicher, Worker-, Verbindungs- oder Datenträgerengpass
Path-MTU- oder Paketverlustproblem Verbindung beginnt, größere Übertragung scheitert und Paketverlauf bestätigt Wiederholungen oder Größenproblem
clientseitiger Anwendungsfehler gleicher Benutzer und Dienst funktionieren mit einem anderen Client
benutzerbezogener Fehler anderer Benutzer arbeitet am gleichen Client erfolgreich

7.9.29 Kontrollierte Maßnahmen, Risiko und Rückweg

Maßnahme Risiko Rückweg
falschen Servernamen oder Port korrigieren Verbindung erreicht anderes Ziel ursprüngliche Konfiguration wiederherstellen
gestoppten Dienst kontrolliert starten Dienst kann erneut fehlschlagen oder Last erzeugen Dienstzustand und Starttyp dokumentieren
Listenerbindung korrigieren Dienst wird auf zusätzlichen Netzen erreichbar vorherige Bindung wiederherstellen
minimale Firewallfreigabe ergänzen zusätzliche Erreichbarkeit konkrete Regel entfernen oder deaktivieren
falschen DNS-Eintrag korrigieren Clients wechseln auf neues Ziel vorherigen Wert und TTL dokumentieren
Reverse-Proxy-Route korrigieren andere Anwendungen können betroffen sein vorherige Proxykonfiguration zurückspielen
fehlerhaftes Backend aus dem Load Balancer nehmen geringere Kapazität Backend nach erfolgreicher Prüfung wieder aufnehmen
Proxykonfiguration korrigieren anderer Netzwerkpfad wird verwendet ursprüngliche Proxywerte wiederherstellen
Zertifikatskette korrigieren TLS-Dienst muss eventuell neu geladen werden vorherige Zertifikatskonfiguration sichern
Anwendungscache kontrolliert leeren Sitzungs- oder Anmeldedaten können verloren gehen Benutzer informieren und Ausgangszustand dokumentieren
Backenddienst wiederherstellen abhängige Anwendungen können beeinflusst werden dienstspezifischen Wiederherstellungsplan verwenden
Ressource freigeben oder Kapazität erhöhen Lastverteilung kann sich ändern vorherige Kapazitäts- oder Ressourcenwerte sichern

Pro Maßnahme sollte möglichst nur eine relevante Variable verändert werden.

7.9.30 Verifikation

Nach einer Maßnahme müssen mindestens folgende Prüfungen erfolgen:

Ein erfolgreicher Ping oder Porttest allein ist keine ausreichende Verifikation.

7.9.31 Präventionsmaßnahmen

7.9.32 Typische Fehler bei der Diagnose

7.9.33 Typische Prüfungsfragen

Warum beweist ein erfolgreicher Ping keine funktionierende Anwendung?

Ping prüft ICMP-Echo-Kommunikation. Die Anwendung kann einen anderen Transportweg, einen bestimmten TCP- oder UDP-Port, TLS, Authentifizierung und weitere Backenddienste benötigen.

Welcher Test sollte nach einem erfolgreichen Ping durchgeführt werden?

Zuerst müssen Zielname, Protokoll und Port der Anwendung bestimmt werden. Anschließend wird der konkrete TCP-Port oder das tatsächliche UDP-Anwendungsprotokoll geprüft.

Was bedeutet „Connection refused“?

Die TCP-Verbindung wurde aktiv abgelehnt. Häufig fehlt ein Listener auf dem Zielport oder eine Komponente lehnt die Verbindung gezielt ab. Der genaue Absender der Ablehnung muss bei Bedarf mit Protokollen oder einem Paketmitschnitt bestimmt werden.

Was bedeutet ein TCP-Timeout?

Der Verbindungsaufbau wurde nicht rechtzeitig abgeschlossen. Mögliche Ursachen sind eine verwerfende Firewallregel, ein falscher Netzwerkpfad, ein fehlender Rückweg, Überlastung oder eine falsche Zieladresse.

Warum sollte ein HTTPS-Dienst nicht nur über seine IP-Adresse getestet werden?

Virtuelle Hosts, TLS-SNI und Zertifikatsprüfung verwenden den Servernamen. Ein Aufruf über die IP-Adresse kann deshalb einen anderen Dienst oder ein anderes Zertifikat erreichen.

Was beweist ein erfolgreicher TCP-Porttest?

Er beweist, dass zum Testzeitpunkt eine TCP-Verbindung zur geprüften Adresse und zum geprüften Port aufgebaut werden konnte. Die Funktion des Anwendungsprotokolls ist damit noch nicht bewiesen.

Was bedeutet ein HTTP-Statuscode 401 oder 403 für die Netzwerkdiagnose?

Die Anwendung wurde erreicht und hat auf HTTP-Ebene geantwortet. Der Fehler liegt anschließend wahrscheinlich bei Authentifizierung, Autorisierung oder einer Anwendungsrichtlinie.

Warum ist ein allgemeiner UDP-Porttest nicht eindeutig?

UDP besitzt keinen verbindlichen Verbindungsaufbau. Ohne gültige Anwendungsanfrage und auswertbare Antwort lässt sich die Dienstfunktion nicht sicher bestätigen.

Was bedeutet es, wenn die Anwendung lokal auf dem Server funktioniert, vom Client aber nicht?

Der Dienst selbst arbeitet grundsätzlich. Danach müssen Listenerbindung, Hostfirewall, Netzwerkpfad, Proxy, Load Balancer und externe Namensauflösung geprüft werden.

Warum kann curl funktionieren, obwohl die eigentliche Anwendung fehlschlägt?

Die Anwendung kann einen anderen Proxy, Zertifikatsspeicher, DNS-Cache, Benutzerkontext, Authentifizierungsmechanismus oder zusätzliche Protokollfunktionen verwenden.

Warum reicht ein erfolgreicher Healthcheck nicht immer aus?

Ein Healthcheck kann nur einen einfachen Endpunkt prüfen. Datenbankzugriff, Anmeldung oder der eigentliche Geschäftsprozess können trotzdem fehlschlagen.

7.9.34 Checkliste

7.9.35 Schnellreferenz

Aufgabe Windows Linux macOS
Ping ping <Server> ping -c 4 <Server> ping -c 4 <Server>
Namensauflösung Resolve-DnsName <Server> getent ahosts <Server> dscacheutil -q host -a name <Server>
A-Eintrag Resolve-DnsName <Server> -Type A dig <Server> A dig <Server> A
AAAA-Eintrag Resolve-DnsName <Server> -Type AAAA dig <Server> AAAA dig <Server> AAAA
TCP-Port Test-NetConnection <Server> -Port <Port> nc -vz <Server> <Port> nc -vz <Server> <Port>
HTTP oder HTTPS curl.exe -v <URL> curl -v <URL> curl -v <URL>
IPv4 mit curl curl.exe -4 -v <URL> curl -4 -v <URL> curl -4 -v <URL>
IPv6 mit curl curl.exe -6 -v <URL> curl -6 -v <URL> curl -6 -v <URL>
bestimmte Ziel-IP curl.exe --resolve <Name>:<Port>:<IP> <URL> curl --resolve <Name>:<Port>:<IP> <URL> curl --resolve <Name>:<Port>:<IP> <URL>
Listener Get-NetTCPConnection -State Listen sudo ss -lntp sudo lsof -nP -iTCP -sTCP:LISTEN
WinHTTP-Proxy netsh winhttp show proxy nicht zutreffend nicht zutreffend
Systemproxy Anwendungseinstellungen prüfen Anwendung und Umgebungsvariablen prüfen scutil --proxy
TLS openssl s_client bei installierter OpenSSL-Version openssl s_client openssl s_client
Paketmitschnitt Wireshark oder freigegebenes Windows-Werkzeug tcpdump oder Wireshark tcpdump oder Wireshark

7.9.36 Quellen

Standards und RFCs

Offizielle Hersteller- und Projektdokumentation

Lokale Befehlsreferenzen

Die genaue Syntax kann von Betriebssystem und installierter Version abhängen. Maßgeblich ist die lokale Befehlsreferenz:

man ping
man nc
man curl
man ss
man lsof
man tcpdump
man dscacheutil
man scutil

Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.

7. Schnelle Entscheidungsbäume

7.10 Anmeldung an der Domäne funktioniert nicht

7.10.1 Ausgangssituation

Ein Benutzer kann sich an einem Windows-Computer nicht mit seinem Domänenkonto anmelden.

Mögliche Meldungen sind beispielsweise:

Der Benutzername oder das Kennwort ist falsch.

Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar.

Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.

Wir können Sie mit diesen Anmeldeinformationen nicht anmelden, weil Ihre Domäne nicht verfügbar ist.

Der Sicherheitsdatenbank auf dem Server ist kein Computerkonto für diese Arbeitsstationsvertrauensstellung zugeordnet.

Der Benutzerprofildienst konnte die Anmeldung nicht durchführen.

Diese Meldungen beschreiben unterschiedliche Fehlerbereiche. Eine fehlgeschlagene Domänenanmeldung darf deshalb nicht automatisch auf ein falsches Kennwort reduziert werden.

7.10.2 Ziel der Diagnose

Die Diagnose soll eindeutig bestimmen, ob der Fehler verursacht wird durch:

Erst nach dem Nachweis der Ursache wird eine kontrollierte Maßnahme durchgeführt.

7.10.3 Geltungsbereich und Abgrenzung

Diese Seite behandelt hauptsächlich die Anmeldung eines Domänenbenutzers an einem Computer, der Mitglied einer lokalen Active-Directory-Domäne mit Active Directory Domain Services ist.

Davon zu unterscheiden sind:

Konto- oder Geräteart Kennzeichnung beziehungsweise Beispiel
lokales Konto .\MaxMustermann oder <Computername>\MaxMustermann
Active-Directory-Domänenkonto <NETBIOS-Domäne>\MaxMustermann
Active-Directory-UPN max.mustermann@<DNS-Domäne>
Microsoft-Entra-Konto häufig ebenfalls UPN-Format, aber cloudbasierte Identität
Microsoft-Konto persönliche Microsoft-Identität
Smartcard-Anmeldung zertifikatsbasierte Anmeldung
Windows Hello for Business schlüssel- oder zertifikatsbasierte Anmeldung
Remotedesktop-Anmeldung Anmeldung erfolgt am entfernten Zielsystem
Dienst- oder Aufgabenanmeldung nicht interaktiver Anmeldetyp

Ein Benutzername im Format benutzer@domäne beweist allein nicht, ob ein lokales Active Directory, Microsoft Entra ID oder ein anderer Identitätsanbieter verwendet wird.

Microsoft-Entra-Anmeldefehler, MFA und Conditional Access benötigen teilweise andere Diagnoseverfahren. Sie dürfen nicht mit einer klassischen AD-Domänenanmeldung gleichgesetzt werden.

7.10.4 Technischer Anmeldeweg

Eine normale Online-Domänenanmeldung benötigt mehrere funktionierende Ebenen:

  1. Der Benutzer wählt den richtigen Anmeldeanbieter.
  2. Windows ordnet den eingegebenen Namen dem vorgesehenen Konto zu.
  3. Der Computer besitzt eine geeignete Netzwerkverbindung.
  4. Der Client verwendet die vorgesehenen DNS-Server.
  5. DNS liefert die erforderlichen Domänen- und Dienstinformationen.
  6. DC Locator ermittelt einen geeigneten Domänencontroller.
  7. Die benötigten Netzwerkprotokolle erreichen den Domänencontroller.
  8. Client und Domänencontroller besitzen ausreichend synchronisierte Uhrzeiten.
  9. Der Computer besitzt eine gültige Vertrauensbeziehung zur Domäne.
  10. Kerberos, NTLM oder das vorgesehene zertifikatsbasierte Verfahren beginnt.
  11. Der Domänencontroller prüft das Benutzerkonto und die Anmeldeinformationen.
  12. Kontorichtlinien und Anmelderechte werden ausgewertet.
  13. Windows erzeugt die Anmeldesitzung und das Zugriffstoken.
  14. Benutzerprofil, Gruppenrichtlinien und Anmeldeskripte werden verarbeitet.
  15. Der Desktop beziehungsweise die vorgesehene Sitzung wird bereitgestellt.

Der sichtbare Fehler kann an jeder dieser Ebenen entstehen.

7.10.5 Zuerst die genaue Fehlerphase bestimmen

Fehlerphase Typische Beobachtung Wahrscheinlicher Bereich
vor Eingabe der Anmeldedaten Netzwerk- oder Anmeldeoption fehlt Client, Treiber, VPN oder Anmeldeanbieter
unmittelbar nach Eingabe Kennwort- oder Kontofehler Identität, Kennwort, Sperre oder Kontorichtlinie
längere Wartezeit vor Fehlermeldung kein DC, DNS, Netzwerk oder Timeout Infrastruktur und Erreichbarkeit
Meldung über Vertrauensstellung Computerkonto oder sicherer Kanal Computervertrauen
Anmeldung funktioniert offline, aber nicht online Cache oder unterschiedlicher DC-Zustand DNS, DC, Kennwort oder Replikation
Anmeldung wird akzeptiert, Desktop erscheint nicht Profil, Richtlinie, Skript oder Ressource Phase nach der Authentifizierung
temporäres Profil wird geladen Benutzerprofilproblem Profilpfad, Datenträger oder Profildienst
nur RDP schlägt fehl RDP, NLA, Anmelderecht oder Zielsystem entfernter Computer
PIN schlägt fehl, Kennwort funktioniert Windows Hello oder PIN-Anbieter Hello-Schlüssel, TPM oder Richtlinie
Smartcard schlägt fehl, Kennwort funktioniert Zertifikat oder PKI Smartcard, Zertifikatskette, KDC-Zertifikat oder Sperrprüfung

Eine erfolgreiche Kennwortprüfung bedeutet noch nicht, dass Benutzerprofil, Gruppenrichtlinien und Desktop erfolgreich geladen werden.

7.10.6 Beweise vor Änderungen sichern

Vor einem Neustart, einer Kennwortzurücksetzung, dem Entsperren eines Kontos oder einer Reparatur des sicheren Kanals sollten mindestens folgende Informationen gesichert werden:

Kennwörter, PINs, private Schlüssel, Wiederherstellungsschlüssel und vollständige Anmeldetoken dürfen nicht dokumentiert oder weitergegeben werden.

Wiederholte unkontrollierte Anmeldeversuche müssen vermieden werden, weil dadurch das Konto gesperrt werden kann.

7.10.7 Umfang des Fehlers bestimmen

Geeignete Kreuztests:

Vergleich Erkenntnis
gleicher Benutzer an anderem Domänencomputer benutzer- oder computerbezogenen Fehler unterscheiden
anderer Domänenbenutzer am gleichen Computer Benutzerkonto und Computerzustand unterscheiden
gleiches Konto mit und ohne VPN VPN-, DNS- oder Routingabhängigkeit erkennen
gleiches Konto an Konsole und per RDP lokale und entfernte Anmeldung unterscheiden
Kennwort statt PIN Windows-Hello-Fehler abgrenzen
Kennwort statt Smartcard Zertifikats- oder Smartcardfehler abgrenzen
lokales Administratorkonto Zugriff für die Clientdiagnose ermöglichen
Test gegen anderen Standort oder anderen DC standort- oder DC-bezogenen Fehler erkennen

Auswertung:

Ergebnis Wahrscheinlicher Bereich
nur ein Benutzer betroffen Benutzerkonto, Kennwort, Sperre oder Benutzerprofil
alle Benutzer an einem Computer betroffen Client, DNS, Netzwerk, Zeit oder sicherer Kanal
viele Computer betroffen DNS, DC, Netzwerk, Zeitdienst, Replikation oder zentrale Richtlinie
nur ein Standort betroffen Standortnetz, VPN, DNS, Firewall oder Standortzuordnung
nur ein Domänencontroller betroffen DC-Dienst, DNS-Registrierung, Replikation oder Zeit
nur neue Kennwörter betroffen Kennwortcache, Replikation oder gespeicherte alte Anmeldedaten
Authentifizierung funktioniert, Desktop nicht Profil, Gruppenrichtlinie, Skript oder Ressource

Ein Testkonto darf nur nach den organisatorischen Sicherheitsvorgaben verwendet werden.

7.10.8 Richtige Identität und Anmeldeoption prüfen

Am Anmeldebildschirm muss geprüft werden:

Beispiele:

<NETBIOS-Domäne>\MaxMustermann

max.mustermann@<DNS-Domäne>

.\MaxMustermann

Bedeutung:

NETBIOS-Domänenname und DNS-Domänenname müssen nicht identisch sein.

Ein lokaler Anmeldeerfolg beweist weder eine funktionierende Domänenverbindung noch ein gültiges Domänenkonto.

7.10.9 Bestehende Sitzung und Identität prüfen

Wenn noch eine bestehende Sitzung verfügbar ist:

whoami
whoami /user
whoami /fqdn
whoami /groups

In PowerShell:

$env:USERDOMAIN
$env:USERDNSDOMAIN
$env:LOGONSERVER

Wichtige Einschränkungen:

7.10.10 Domänenmitgliedschaft des Computers prüfen

Mit einem autorisierten lokalen Konto oder einer noch verfügbaren Administrationssitzung:

Get-CimInstance Win32_ComputerSystem |
  Select-Object Name, PartOfDomain, Domain, Workgroup

Erwartet wird:

PartOfDomain : True
Domain       : <DNS-Domäne>

Zusätzlich:

systeminfo

Relevante Felder sind:

Domäne
Anmeldeserver

Zu prüfen sind:

PartOfDomain : True beweist nur die lokale Mitgliedschaftskonfiguration. Es beweist nicht, dass der sichere Kanal aktuell funktioniert.

7.10.11 Online-Anmeldung und zwischengespeicherte Domänenanmeldung unterscheiden

Windows kann Informationen früherer Domänenanmeldungen lokal zwischenspeichern. Dadurch kann sich ein Benutzer unter bestimmten Voraussetzungen anmelden, obwohl kein Domänencontroller erreichbar ist.

Eine zwischengespeicherte Anmeldung beweist nicht:

Wurde das Kennwort an einem anderen Computer geändert, kann ein offline verwendeter Client weiterhin den früher zwischengespeicherten Kennwortnachweis erwarten. Erst eine erfolgreiche Online-Anmeldung kann den lokalen Anmeldecache aktualisieren.

Die Anzahl zwischengespeicherter eindeutiger Benutzer wird durch die Sicherheitsrichtlinie bestimmt:

Computerkonfiguration
└── Windows-Einstellungen
    └── Sicherheitseinstellungen
        └── Lokale Richtlinien
            └── Sicherheitsoptionen
                └── Interaktive Anmeldung:
                   Anzahl zwischenzuspeichernder vorheriger Anmeldungen

Der genaue Wert ist eine Sicherheitsentscheidung der Organisation. Er darf nicht nur zur Fehlerumgehung verändert werden.

Typische Unterscheidung:

Verhalten Einordnung
Anmeldung ohne Netzwerk funktioniert Cache-Anmeldung möglich
Anmeldung mit Netzwerk schlägt fehl Online-Authentifizierung oder anderer DC-Zustand fehlerhaft
altes Kennwort funktioniert offline lokaler Cache kann noch den alten Nachweis enthalten
neues Kennwort funktioniert online DC kennt das neue Kennwort
neues Kennwort funktioniert an einem Gerät, an anderem nicht Cache, DC-Auswahl oder Replikation prüfen
noch nie auf diesem Computer angemeldeter Benutzer kann offline nicht anmelden kein passender lokaler Anmeldecache vorhanden

7.10.12 Netzwerkzustand des Clients prüfen

Get-NetAdapter |
  Select-Object Name, Status, LinkSpeed, MacAddress

Get-NetIPConfiguration

ipconfig /all

Zu dokumentieren sind:

Ein Ping zum Gateway oder zu einem DC ist nur ein Teilnachweis. Die Domänenanmeldung benötigt DNS, DC Locator und mehrere Anwendungsprotokolle.

Bei einer Anmeldung außerhalb des Unternehmensnetzes ist zu prüfen, ob eine Anmeldung vor dem Windows-Desktop überhaupt eine VPN-Verbindung herstellen kann. Ein VPN, das erst nach der Benutzeranmeldung startet, kann keine erstmalige Online-Domänenanmeldung ermöglichen.

7.10.13 DNS-Konfiguration prüfen

Active Directory ist auf DNS-basierte Diensterkennung angewiesen. Der Client sollte die für die AD-Domäne vorgesehenen DNS-Server verwenden.

DNS-Server anzeigen:

Get-DnsClientServerAddress |
  Select-Object InterfaceAlias, AddressFamily, ServerAddresses

Domänenname prüfen:

Resolve-DnsName -Name <DNS-Domäne> -Type A

Domänencontroller-Dienst prüfen:

Resolve-DnsName `
  -Name _ldap._tcp.dc._msdcs.<DNS-Domäne> `
  -Type SRV

Kerberos-Dienst prüfen:

Resolve-DnsName `
  -Name _kerberos._tcp.<DNS-Domäne> `
  -Type SRV

Einen bestimmten DNS-Server verwenden:

Resolve-DnsName `
  -Name _ldap._tcp.dc._msdcs.<DNS-Domäne> `
  -Type SRV `
  -Server <DNS-Server>

Zu prüfen sind:

Öffentliche Resolver kennen die internen Active-Directory-Dienstinformationen normalerweise nicht. Ein zusätzlich eingetragener öffentlicher DNS-Server ist kein zuverlässiger Ersatz für den vorgesehenen AD-DNS-Server.

DNS-Caches sollten nicht sofort gelöscht werden. Zuerst müssen aktuelle Antworten, DNS-Server und die verwendete Zieladresse dokumentiert werden.

7.10.14 Domänencontroller-Ermittlung prüfen

Windows verwendet DC Locator und den Netlogon-Dienst, um über DNS-SRV-Einträge einen geeigneten Domänencontroller zu finden.

nltest /dsgetdc:<DNS-Domäne>

Erneute DNS-basierte Ermittlung ohne den bisherigen DC-Cache:

nltest /dsgetdc:<DNS-Domäne> /force

Nur einen beschreibbaren DC anfordern:

nltest /dsgetdc:<DNS-Domäne> /writable /force

Lokalen AD-Standort anzeigen:

nltest /dsgetsite

Bekannte Domänencontroller auflisten:

nltest /dclist:<DNS-Domäne>

In der Ausgabe von nltest /dsgetdc sind unter anderem wichtig:

DC
Address
Domain Name
Forest Name
Dc Site Name
Our Site Name
Flags

Auswertung:

Ergebnis Bedeutung
geeigneter DC wird gefunden DC Locator war für diesen Versuch erfolgreich
ERROR_NO_SUCH_DOMAIN Domäne oder DC konnte nicht gefunden werden
falscher Standort Subnetz- oder Standortzuordnung prüfen
alter DC wird geliefert DNS-Registrierung und AD-Metadaten prüfen
nur ein entfernter DC wird gefunden lokaler DC, Standort oder DNS möglicherweise fehlerhaft
DC wird gefunden, Anmeldung scheitert trotzdem Erreichbarkeit, Zeit, Konto, sicherer Kanal und Protokoll prüfen

Ein erfolgreiches nltest /dsgetdc beweist nicht, dass alle für die Anmeldung benötigten Protokolle funktionieren.

7.10.15 Erreichbarkeit der benötigten Dienste prüfen

Grundlegende TCP-Tests:

Test-NetConnection -ComputerName <DC-FQDN> -Port 53
Test-NetConnection -ComputerName <DC-FQDN> -Port 88
Test-NetConnection -ComputerName <DC-FQDN> -Port 135
Test-NetConnection -ComputerName <DC-FQDN> -Port 389
Test-NetConnection -ComputerName <DC-FQDN> -Port 445

Je nach Funktion zusätzlich:

Test-NetConnection -ComputerName <DC-FQDN> -Port 464
Test-NetConnection -ComputerName <DC-FQDN> -Port 3268
Test-NetConnection -ComputerName <DC-FQDN> -Port 636
Test-NetConnection -ComputerName <DC-FQDN> -Port 3269

Wichtige AD-Protokolle:

Dienst Protokoll und Port Bedeutung
DNS TCP/UDP 53 Namens- und Dienstauflösung
Kerberos TCP/UDP 88 Kerberos-Authentifizierung
Windows-Zeit UDP 123 Zeitsynchronisation
RPC Endpoint Mapper TCP 135 RPC-Endpunktermittlung
LDAP TCP 389 Verzeichniszugriff
DC Locator UDP 389 DC-Ermittlung
SMB TCP 445 Netlogon, SYSVOL und Gruppenrichtlinien
Kerberos-Kennwortdienst TCP/UDP 464 Kennwortänderungen
Global Catalog TCP 3268 gesamtstrukturweite Abfragen
LDAPS TCP 636 LDAP über TLS, sofern verwendet
Global Catalog über TLS TCP 3269 GC über TLS, sofern verwendet
dynamische RPC-Ports üblicherweise TCP 49152–65535 bei modernen Windows-Versionen ausgehandelte RPC-Verbindungen

Wichtige Einschränkungen:

Firewalls dürfen nicht pauschal deaktiviert werden. Die konkrete Regel muss anhand von Quelle, Ziel, Protokoll, Port, Richtung und Zeitstempel geprüft werden.

7.10.16 Zeit und Zeitsynchronisation prüfen

Kerberos benötigt ausreichend synchronisierte Uhrzeiten. Die standardmäßige maximale Kerberos-Zeitabweichung beträgt in vielen AD-Umgebungen fünf Minuten, kann aber durch Richtlinien verändert werden.

Clientstatus:

w32tm /query /status
w32tm /query /source
w32tm /query /configuration

Zeitabweichung zu einem DC beobachten:

w32tm /stripchart /computer:<DC-FQDN> /dataonly /samples:5

Zusätzlich zu prüfen:

Get-Service W32Time

Zu vergleichen sind:

Eine richtige Bildschirmanzeige allein beweist keine korrekte Zeitkonfiguration. Zeitzone, UTC-Zeit, Zeitquelle und tatsächliche Abweichung müssen getrennt betrachtet werden.

Eine Resynchronisation ist eine Änderung und sollte erst nach Dokumentation der bisherigen Quelle und Abweichung erfolgen:

w32tm /resync /rediscover

Danach müssen Quelle, Status und Abweichung erneut geprüft werden.

7.10.17 Benutzerkonto prüfen

Mit dem ActiveDirectory-PowerShell-Modul und ausreichender Leseberechtigung:

Get-ADUser `
  -Identity "<Benutzername>" `
  -Properties Enabled,
              LockedOut,
              PasswordExpired,
              AccountExpirationDate,
              PasswordLastSet,
              LastBadPasswordAttempt,
              BadLogonCount,
              LogonWorkstations |
  Select-Object SamAccountName,
                UserPrincipalName,
                Enabled,
                LockedOut,
                PasswordExpired,
                AccountExpirationDate,
                PasswordLastSet,
                LastBadPasswordAttempt,
                BadLogonCount,
                LogonWorkstations

Ergebnisbezogene Kennwortrichtlinie prüfen:

Get-ADUserResultantPasswordPolicy `
  -Identity "<Benutzername>"

Gezielte Suchbefehle:

Search-ADAccount -LockedOut -UsersOnly
Search-ADAccount -AccountDisabled -UsersOnly
Search-ADAccount -AccountExpired -UsersOnly
Search-ADAccount -PasswordExpired -UsersOnly

Alternativ mit integrierten Werkzeugen:

net user <Benutzername> /domain

Zu prüfen sind:

BadLogonCount, LastBadPasswordAttempt und ähnliche Werte können DC-abhängig sein. Sie dürfen nicht ohne Berücksichtigung des abgefragten Domänencontrollers und der Replikation interpretiert werden.

Ein Konto sollte nicht vorsorglich entsperrt oder dessen Kennwort zurückgesetzt werden, bevor die Quelle fehlerhafter Anmeldeversuche untersucht wurde. Gespeicherte alte Kennwörter in Diensten, Aufgaben, Mobilgeräten oder Anwendungen können das Konto sofort erneut sperren.

7.10.18 Kennwortfehler systematisch abgrenzen

Mögliche Ursachen trotz scheinbar richtiger Eingabe:

Ein administratives Zurücksetzen des Kennworts kann Auswirkungen auf verschlüsselte benutzerbezogene Daten, gespeicherte Anmeldeinformationen und Zertifikatsschlüssel besitzen. Es muss nach dem vorgesehenen Identitäts- und Wiederherstellungsverfahren erfolgen.

7.10.19 Sicheren Kanal des Computers prüfen

Domänencomputer und Domäne besitzen eine Vertrauensbeziehung auf Grundlage des Computerkontos und eines Computerkennworts. Stimmen der lokale und der in Active Directory gespeicherte Zustand nicht mehr überein, kann der sichere Kanal fehlschlagen.

Typische Meldung:

Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.

Nur prüfen:

powershell

Test-ComputerSecureChannel -Verbose


Erwartetes Ergebnis:

```text
True

Ein bestimmter DC kann für den Test angegeben werden:

Test-ComputerSecureChannel `
  -Server "<DC-FQDN>" `
  -Verbose

Status des zuletzt verwendeten Netlogon-Kanals anzeigen:

nltest /sc_query:<DNS-Domäne>

Wichtige Einschränkungen:

Mögliche Ursachen eines defekten sicheren Kanals:

Ein defekter sicherer Kanal ist ein konkreter Befund. Der Computer sollte nicht vorsorglich aus der Domäne entfernt werden.

7.10.20 Kerberos und NTLM unterscheiden

Windows verwendet häufig das Aushandlungspaket Negotiate. Dieses wählt nach Möglichkeit Kerberos und kann unter bestimmten Bedingungen NTLM verwenden.

Kerberos benötigt unter anderem:

NTLM benötigt ebenfalls einen erreichbaren zuständigen Authentifizierungsserver und darf nicht als automatische oder dauerhafte Lösung für Kerberos-Probleme betrachtet werden.

Ein erfolgreicher NTLM-Versuch beweist nicht, dass Kerberos funktioniert. Ein Fehlschlag bei Kerberos darf nicht ungeprüft durch Lockerung der Sicherheitsrichtlinien oder dauerhafte Aktivierung veralteter Verfahren umgangen werden.

7.10.21 Kerberos-Tickets prüfen

In einer bestehenden Domänensitzung:

klist

TGT anzeigen:

klist tgt

Alle Tickets der aktuellen Sitzung anzeigen:

klist tickets

Zu prüfen sind:

klist purge löscht Kerberos-Tickets der angegebenen Anmeldesitzung und ist daher keine rein lesende Diagnose:

klist purge

Mögliche Auswirkungen:

Tickets sollten deshalb zuerst dokumentiert und nur im Rahmen eines kontrollierten Tests gelöscht werden.

Eine fehlgeschlagene interaktive Anmeldung besitzt möglicherweise noch keine normale Benutzersitzung, in der klist ausgeführt werden kann. In diesem Fall sind die Ereignisse auf dem Domänencontroller besonders wichtig.

7.10.22 Relevante Ereignisprotokolle

Ereignisse müssen anhand des gleichen Benutzer-, Computer- und Fehlerzeitpunkts korreliert werden.

Auf dem betroffenen Client:

Auf dem beteiligten Domänencontroller:

Beispiel für Clientereignisse der letzten zwei Stunden:

Get-WinEvent -FilterHashtable @{
  LogName   = 'System'
  StartTime = (Get-Date).AddHours(-2)
} |
  Where-Object {
    $_.ProviderName -match 'NETLOGON|W32Time|DNS|Lsa'
  } |
  Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message

Fehlgeschlagene Anmeldungen auf einem System:

Get-WinEvent -FilterHashtable @{
  LogName   = 'Security'
  Id        = 4625
  StartTime = (Get-Date).AddHours(-2)
} |
  Select-Object TimeCreated, Id, Message

Relevante Ereignisse:

Ereignis-ID Typische Bedeutung Typischer Ort
4624 erfolgreiche Anmeldung System, auf dem die Anmeldung erfolgte
4625 fehlgeschlagene Anmeldung System, auf dem die Anmeldung versucht wurde
4740 Benutzerkonto wurde gesperrt zuständiges System beziehungsweise DC
4767 Benutzerkonto wurde entsperrt Domänencontroller
4768 Kerberos-TGT wurde angefordert Domänencontroller
4769 Kerberos-Dienstticket wurde angefordert Domänencontroller
4771 Kerberos-Vorauthentifizierung fehlgeschlagen Domänencontroller
4776 NTLM-Anmeldeinformationen wurden geprüft für Domänenkonten auf dem zuständigen DC
3210 Netlogon konnte Computer nicht beim DC authentifizieren Mitgliedscomputer
5719 kein Domänencontroller für sichere Sitzung verfügbar Mitgliedscomputer
1053 oder 1055 Gruppenrichtlinienverarbeitung mit Domänen- oder DC-Problem Mitgliedscomputer

Die Ereignisse erscheinen nur, wenn die entsprechenden Überwachungsrichtlinien und Protokollkanäle aktiviert sind. Das Fehlen eines Ereignisses beweist deshalb nicht, dass kein Versuch stattgefunden hat.

7.10.23 Ereignis 4625 auswerten

Bei Ereignis 4625 sind besonders wichtig:

Account Name
Account Domain
Failure Reason
Status
Sub Status
Logon Type
Logon Process
Authentication Package
Workstation Name
Source Network Address
Caller Process Name

Wichtige Anmeldetypen:

Logon Type Bedeutung
2 interaktive lokale Anmeldung
3 Netzwerkanmeldung
4 Batch beziehungsweise geplante Aufgabe
5 Dienstanmeldung
7 Entsperren
10 Remotedesktop beziehungsweise RemoteInteractive
11 zwischengespeicherte interaktive Anmeldung

Häufige Status- oder Substatuswerte:

Code Bedeutung Nächster Nachweis
0xC000005E keine Anmeldeserver verfügbar DNS, DC Locator, Netzwerk und DC-Zustand prüfen
0xC0000064 Benutzerkonto nicht gefunden Benutzername, Domäne und Kontobestand prüfen
0xC000006A falsches Kennwort Eingabe, Kennwortänderung und gespeicherte Kennwörter prüfen
0xC000006D allgemeiner Fehler bei Benutzername oder Authentifizierungsdaten Status, Substatus und Authentifizierungspaket korrelieren
0xC000006F Anmeldung außerhalb erlaubter Zeiten Anmeldezeiten prüfen
0xC0000070 Anmeldung von nicht erlaubter Arbeitsstation Arbeitsstationsbeschränkung prüfen
0xC0000071 Kennwort abgelaufen Kennwortstatus und Änderungsweg prüfen
0xC0000072 Konto deaktiviert Kontostatus und Änderungshistorie prüfen
0xC000015B erforderlicher Anmeldetyp nicht gewährt Benutzerrechte und Richtlinien prüfen
0xC0000192 Netlogon-Dienst ist nicht gestartet Dienstzustand und Systemereignisse prüfen
0xC0000193 Konto abgelaufen Ablaufdatum des Kontos prüfen
0xC0000234 Konto gesperrt Ereignis 4740 und Quelle der Fehlversuche untersuchen
0xC0000413 Authentifizierungsfirewall verhindert Anmeldung Authentifizierungsrichtlinie und zulässige Systeme prüfen

Status und Substatus müssen gemeinsam ausgewertet werden. Der sichtbare Meldungstext am Anmeldebildschirm kann absichtlich weniger genau sein als das Sicherheitsereignis.

7.10.24 Kerberos-Ereignisse auswerten

Ereignis 4768 zeigt die Anforderung eines Kerberos-TGT. Ereignis 4771 zeigt eine fehlgeschlagene Kerberos-Vorauthentifizierung.

Häufige Kerberos-Fehlercodes:

Code Kerberos-Bezeichnung Einordnung
0x6 KDC_ERR_C_PRINCIPAL_UNKNOWN Benutzerprinzipal nicht in Kerberos-Datenbank gefunden
0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN angeforderter Dienstprinzipal nicht gefunden
0x8 KDC_ERR_PRINCIPAL_NOT_UNIQUE Prinzipal nicht eindeutig
0xC KDC_ERR_POLICY KDC-Richtlinie lehnt Anfrage ab
0xE KDC_ERR_ETYPE_NOSUPP keine gemeinsame unterstützte Verschlüsselungsart
0x10 KDC_ERR_PADATA_TYPE_NOSUPP Vorauthentifizierungstyp nicht unterstützt; bei Smartcard auch Zertifikatsproblem möglich
0x12 KDC_ERR_CLIENT_REVOKED Anmeldeinformationen des Clients wurden widerrufen
0x17 KDC_ERR_KEY_EXPIRED Kennwort abgelaufen
0x18 KDC_ERR_PREAUTH_FAILED Vorauthentifizierung ungültig; häufig falsches Kennwort
0x19 KDC_ERR_PREAUTH_REQUIRED zusätzliche Vorauthentifizierung erforderlich; nicht automatisch ein Fehler
0x1D KDC_ERR_SVC_UNAVAILABLE Kerberos-Dienst nicht verfügbar
0x20 KRB_AP_ERR_TKT_EXPIRED Ticket abgelaufen
0x25 KRB_AP_ERR_SKEW Zeitabweichung zu groß
0x34 KRB_ERR_RESPONSE_TOO_BIG Antwort zu groß für UDP; erneuter Versuch über TCP erforderlich

Ein einzelner Kerberos-Fehlercode muss mit Benutzer, Clientadresse, DC, Zeitstempel und nachfolgendem Erfolg oder Fehlschlag korreliert werden.

Der Code 0x19 kann Teil eines normalen Kerberos-Ablaufs sein und darf nicht allein als Störung gewertet werden.

7.10.25 Kontosperren bis zur Quelle verfolgen

Bei einer Sperre muss nicht nur das Konto entsperrt, sondern die Quelle der wiederholten falschen Kennwörter bestimmt werden.

Zu untersuchen sind:

Eine Kontosperre kann durch einen Hintergrundprozess entstehen, obwohl der Benutzer sein aktuelles Kennwort am Anmeldebildschirm richtig eingibt.

7.10.26 Active-Directory-Replikation prüfen

Wenn Anmeldungen abhängig vom verwendeten Domänencontroller unterschiedlich reagieren, müssen Replikation und DC-Zustand geprüft werden.

Auf einem autorisierten Administrationssystem oder Domänencontroller:

repadmin /replsummary

repadmin /showrepl

Gesamtstrukturweite Übersicht:

repadmin /showrepl * /csv

Grundlegender DC-Test:

dcdiag /v

DNS-Test für einen bestimmten DC:

dcdiag /test:DNS /v /s:<DC-Name>

Zu prüfen sind:

Mögliche Symptome eines Replikationsfehlers:

Eine erzwungene Replikation ist keine erste Diagnosemaßnahme. Zuerst müssen Richtung, Fehlercode, Ursache und Replikationspartner bestimmt werden.

7.10.27 Standort, VPN und RODC berücksichtigen

AD-Standorte beeinflussen die Auswahl eines Domänencontrollers.

Clientstandort anzeigen:

nltest /dsgetsite

Zu prüfen sind:

Ein RODC kann nur solche Anmeldungen lokal verarbeiten, für die die erforderlichen Anmeldeinformationen entsprechend der Kennwortreplikationsrichtlinie verfügbar sind oder ein beschreibbarer DC erreicht werden kann.

7.10.28 RDP- und NLA-Anmeldungen abgrenzen

Bei Remotedesktop erfolgt die Anmeldung am entfernten Computer. Entscheidend sind daher DNS, Netzwerk, Zeit, Domänenverbindung, sicherer Kanal und Anmelderechte des Zielsystems.

Zu prüfen sind:

Ein erfolgreicher Domänenlogin am lokalen Notebook beweist nicht, dass der entfernte Server die Domäne erreichen oder den Benutzer anmelden kann.

NLA sollte nicht dauerhaft deaktiviert werden, nur um einen Authentifizierungsfehler zu umgehen.

7.10.29 Smartcard und Windows Hello for Business abgrenzen

Wenn Kennwortanmeldung funktioniert, aber Smartcard oder Windows Hello fehlschlägt, ist die normale Kennwortprüfung wahrscheinlich nicht die Hauptursache.

Bei Smartcard-Anmeldung zu prüfen:

Bei Windows Hello for Business zu prüfen:

Eine PIN ist nicht das Domänenkennwort. Ein PIN-Fehler beweist deshalb nicht, dass das AD-Kennwort falsch ist.

7.10.30 Authentifizierung, Sitzung und Benutzerprofil unterscheiden

Nach erfolgreicher Authentifizierung können weitere Fehler auftreten:

Typische Unterscheidung:

Beobachtung Einordnung
Ereignis 4624 vorhanden, danach Profilfehler Authentifizierung war wahrscheinlich erfolgreich
Desktop erscheint nach langer Wartezeit Gruppenrichtlinie, Skript oder Ressource prüfen
temporäres Profil Benutzerprofil und Datenträger prüfen
nur ein Benutzerprofil betroffen lokales oder servergespeichertes Profil möglich
Anmeldung anderer Benutzer funktioniert allgemeine DC-Erreichbarkeit wahrscheinlich vorhanden
Anmeldung im abgesicherten Diagnosekontext funktioniert nachgelagerte Erweiterung, Richtlinie oder Dienst möglich

Gruppenrichtlinienstatus in einer bestehenden Sitzung:

gpresult /r

Computerrichtlinien:

gpresult /r /scope computer

Benutzerrichtlinien:

gpresult /r /scope user

gpupdate /force ist keine reine Diagnose. Der Befehl kann neue Richtlinien anwenden und den Ausgangszustand verändern.

7.10.31 Systematischer Diagnoseablauf

  1. Fehlermeldung aufnehmen
    Exakten Wortlaut, Benutzer, Computer, Uhrzeit und Anmeldeart dokumentieren.

  2. Anmeldephase bestimmen
    Identität, Authentifizierung, Sitzung oder Profil unterscheiden.

  3. Umfang bestimmen
    Einen Benutzer, einen Computer, einen Standort oder die gesamte Domäne unterscheiden.

  4. Anmeldeanbieter kontrollieren
    Kennwort, PIN, Smartcard, lokales Konto und Domänenkonto unterscheiden.

  5. Namensformat prüfen
    UPN und DOMÄNE\Benutzer kontrolliert vergleichen.

  6. Domänenmitgliedschaft prüfen
    Lokale Mitgliedschaft und erwartete Domäne bestätigen.

  7. Online- und Cache-Anmeldung unterscheiden
    Feststellen, ob ein DC tatsächlich beteiligt war.

  8. Netzwerkzustand prüfen
    Schnittstelle, Adresse, Gateway, VPN und DNS-Server dokumentieren.

  9. DNS-SRV-Einträge prüfen
    LDAP- und Kerberos-Diensteinträge auflösen.

  10. Domänencontroller ermitteln
    nltest /dsgetdc und Standortinformationen auswerten.

  11. DC-Erreichbarkeit prüfen
    DNS, Kerberos, LDAP, SMB, RPC und benötigte Zusatzdienste untersuchen.

  12. Zeit prüfen
    Zeitquelle, Status und Abweichung zum DC bestimmen.

  13. Benutzerkonto prüfen
    Existenz, UPN, Aktivierung, Sperre, Ablauf und Kennwortstatus auswerten.

  14. Sicheren Kanal prüfen
    Ausschließlich mit lesenden Tests beginnen.

  15. Authentifizierungsverfahren bestimmen
    Kerberos, NTLM, Smartcard oder Windows Hello unterscheiden.

  16. Ereignisse korrelieren
    Client- und DC-Ereignisse auf denselben Versuch begrenzen.

  17. Fehlercode auswerten
    Status, Substatus, Kerberos-Code und Anmeldetyp bestimmen.

  18. Replikation prüfen
    Besonders bei DC- oder Standortabhängigkeit.

  19. Nachgelagerte Anmeldung prüfen
    Profil, Gruppenrichtlinie, Skript und Ressourcen untersuchen.

  20. Hypothese formulieren
    Erwarteten Befund und möglichen Gegenbeweis festlegen.

  21. Eine kontrollierte Maßnahme durchführen
    Risiko, Berechtigung, Rückweg und Erfolgskriterium dokumentieren.

  22. Online-Domänenanmeldung verifizieren
    Nicht nur Cache- oder lokale Anmeldung testen.

  23. Vollständige Benutzerfunktion prüfen
    Desktop, Gruppenrichtlinien und benötigte Ressourcen kontrollieren.

  24. Nachkontrolle durchführen
    Ereignisse, Replikation und weitere Benutzer beziehungsweise Systeme prüfen.

7.10.32 Befundmatrix

Befund Mögliche Erklärung Nächster Nachweis
lokales Konto funktioniert, Domänenkonto nicht Domänenweg oder Domänenkonto fehlerhaft DNS, DC Locator, Konto und sicheren Kanal prüfen
anderer Benutzer funktioniert am gleichen Computer benutzerbezogener Fehler Kontostatus, Kennwort und Profil prüfen
gleicher Benutzer funktioniert an anderem Computer clientbezogener Fehler DNS, Zeit, sicherer Kanal und Profil prüfen
Anmeldung funktioniert nur offline Cache-Anmeldung Onlineweg zum DC prüfen
altes Kennwort funktioniert offline alter lokaler Anmeldecache Onlineanmeldung mit aktuellem Kennwort prüfen
nltest /dsgetdc findet keinen DC DNS, Netzwerk oder Netlogon SRV-Einträge, DNS-Server und Dienst prüfen
DC wird gefunden, Ports schlagen fehl Firewall, Routing oder DC-Dienst Regeln und beidseitige Protokolle prüfen
Ereignis 0xC000005E keine Anmeldeserver verfügbar DNS, DC Locator und Netzwerk prüfen
Ereignis 0xC0000064 Benutzer nicht gefunden Identität und Kontobestand prüfen
Ereignis 0xC000006A falsches Kennwort Kennwort, Cache und gespeicherte Daten prüfen
Ereignis 0xC0000234 Konto gesperrt Ereignis 4740 und Sperrquelle prüfen
Kerberos 0x18 Vorauthentifizierung fehlgeschlagen Kennwort und zugehörigen Versuch prüfen
Kerberos 0x25 Zeitabweichung zu groß Zeitquelle und Abweichung prüfen
sicherer Kanal liefert False Computervertrauen fehlerhaft DNS, Zeit, Computerkonto und Replikation prüfen
Vertrauensfehler nur bei einem Computer Computerkennwort oder Computerkonto sicheren Kanal kontrolliert reparieren
Anmeldung funktioniert abhängig vom DC Replikations- oder DC-Fehler DC-Ereignisse und repadmin auswerten
Kennwort funktioniert, PIN nicht Windows-Hello-Problem Hello-, TPM- und Richtlinienzustand prüfen
Kennwort funktioniert, Smartcard nicht PKI- oder Zertifikatsproblem Zertifikate, KDC und Sperrprüfung untersuchen
Ereignis 4624 vorhanden, Desktop fehlt Authentifizierung erfolgreich, Folgephase fehlerhaft Profil, GPO und Skripte prüfen
nur RDP schlägt fehl RDP-Recht, NLA oder Zielsystem Logon Type 10 und Zielsystem prüfen
Konto wird sofort erneut gesperrt gespeichertes altes Kennwort Quellcomputer und Hintergrundprozesse ermitteln

7.10.33 Ursachen und erforderliche Nachweise

Mögliche Ursache Erforderlicher Nachweis
falsches Namensformat Anmeldung richtet sich nachweislich an falsche Domäne oder lokales Konto
falsches Kennwort Ereigniscode und kontrollierter Identitätsabgleich bestätigen die Ursache
Konto gesperrt AD-Kontostatus und Ereignis gesper 4740 bestätigen die Sperre
Konto deaktiviert Enabled : False oder entsprechendes Änderungsereignis
Konto abgelaufen Ablaufdatum liegt in der Vergangenheit
Kennwort abgelaufen PasswordExpired oder Kerberos-Code 0x17
falscher DNS-Server Client verwendet nicht den vorgesehenen AD-DNS-Server
fehlender SRV-Eintrag autorisierte DNS-Abfrage liefert den benötigten Eintrag nicht
falscher DC-Eintrag SRV- oder A/AAAA-Eintrag verweist auf falschen oder alten DC
DC nicht erreichbar protokollspezifischer Test und Netzwerkprotokoll bestätigen Unterbrechung
falscher AD-Standort nltest /dsgetsite und Subnetzkonfiguration stimmen nicht überein
VPN vor Anmeldung fehlt Onlineweg zum DC ist am Anmeldebildschirm nicht vorhanden
Zeitabweichung w32tm oder Kerberos-Code 0x25 bestätigt die Abweichung
defekter sicherer Kanal Test-ComputerSecureChannel meldet reproduzierbar False
Computerkonto fehlt AD-Abfrage bestätigt fehlendes oder falsches Computerkonto
doppelter Computername zwei Systeme verwenden nachweislich dieselbe Computeridentität
AD-Replikationsfehler repadmin oder DC-Protokolle zeigen fehlgeschlagene Replikation
Kerberos-Verschlüsselungsproblem Kerberos-Code und Kontokonfiguration bestätigen fehlende gemeinsame Verschlüsselungsart
Smartcard-Zertifikatsproblem Zertifikatsprüfung oder PKINIT-Ereignis bestätigt Ursache
fehlendes Anmelderecht Ereignis 0xC000015B und wirksame Richtlinie stimmen überein
Profilfehler erfolgreiche Authentifizierung und Profildienstereignis liegen nacheinander vor
Gruppenrichtlinienfehler GroupPolicy-Protokoll zeigt konkrete fehlgeschlagene Richtlinienverarbeitung
gespeichertes altes Kennwort Ereignisse zeigen wiederholte Fehlversuche von bestimmtem Gerät oder Prozess

7.10.34 Kontrollierte Maßnahmen, Risiko und Rückweg

Maßnahme Risiko Rückweg beziehungsweise Kontrolle
richtigen Benutzer oder richtige Domäne auswählen gering ursprüngliche Eingabe dokumentieren
Tastaturlayout korrigieren Fehleingabe bleibt möglich kontrollierte Testeingabe ohne Kennwortprotokollierung
Netzwerk oder Voranmelde-VPN wiederherstellen anderer Netzwerkweg wird aktiv vorherigen Netzwerkzustand dokumentieren
DNS-Konfiguration korrigieren andere Namensauflösung kann beeinflusst werden bisherige DNS-Werte sichern
falschen SRV- oder Hosteintrag korrigieren viele Clients können betroffen sein bisherigen Wert und TTL dokumentieren
Windows-Zeit kontrolliert synchronisieren Zeitsprung kann Dienste beeinflussen alte Quelle und Abweichung sichern
Konto nach Ursachenprüfung entsperren erneute sofortige Sperre möglich Sperrquelle vorher ermitteln
Kennwort nach Identitätsprüfung zurücksetzen gespeicherte Daten oder Schlüssel können betroffen sein vorgesehenes Identitätsverfahren verwenden
sicheren Kanal reparieren Computervertrauen wird verändert verwendeten DC und Ausgangsbefund dokumentieren
Computerkennwort zurücksetzen Vertrauensbeziehung kann bei Fehler weiter ausfallen lokale Administrationsmöglichkeit sicherstellen
Computer neu in Domäne aufnehmen Neustarts, Profilzuordnung und Verwaltungszustand können betroffen sein nur als letzte Maßnahme mit Wiederaufnahmeplan
AD-Replikationsfehler beheben domänenweite Auswirkungen möglich DC-spezifischen Änderungsplan verwenden
GPO korrigieren viele Benutzer oder Computer betroffen Version, Sicherung und Zielbereich dokumentieren
beschädigtes Profil reparieren Benutzerdaten können verloren gehen Profil und Daten nach Vorgabe sichern
gespeicherte alte Anmeldeinformation aktualisieren Anwendung oder Dienst kann ausfallen betroffene Abhängigkeit vorher bestimmen

Pro Diagnoseversuch sollte möglichst nur eine relevante Variable verändert werden.

7.10.35 Sicheren Kanal kontrolliert reparieren

Eine Reparatur ist nur gerechtfertigt, wenn:

Reparatur mit PowerShell:

$Credential = Get-Credential "<NETBIOS-Domäne>\<Administrationskonto>"

Test-ComputerSecureChannel `
  -Repair `
  -Server "<DC-FQDN>" `
  -Credential $Credential `
  -Verbose

Alternativ kann das lokale Computerkennwort kontrolliert zurückgesetzt werden:

$Credential = Get-Credential "<NETBIOS-Domäne>\<Administrationskonto>"

Reset-ComputerMachinePassword `
  -Server "<DC-FQDN>" `
  -Credential $Credential

Danach:

Test-ComputerSecureChannel `
  -Server "<DC-FQDN>" `
  -Verbose

Anschließend sind je nach Verfahren ein Neustart und eine erneute Online-Domänenanmeldung erforderlich.

Wichtig:

7.10.36 Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Eine erfolgreiche lokale oder zwischengespeicherte Anmeldung ist keine ausreichende Verifikation einer reparierten Domänenanmeldung.

7.10.37 Präventionsmaßnahmen

7.10.38 Typische Fehler bei der Diagnose

7.10.39 Typische Prüfungsfragen

Warum kann eine Domänenanmeldung trotz richtiger Anmeldedaten fehlschlagen?

Die Anmeldung benötigt neben gültigen Anmeldedaten unter anderem Netzwerk, DNS, einen erreichbaren Domänencontroller, ausreichende Zeitsynchronisation, ein gültiges Benutzerkonto und eine funktionierende Computervertrauensstellung.

Warum ist DNS für eine Active-Directory-Anmeldung erforderlich?

Der Client ermittelt Domänencontroller und Kerberos-Dienste über DNS-SRV-Einträge. Eine einfache Auflösung des Domänennamens reicht dafür nicht aus.

Was bedeutet die Meldung, dass keine Anmeldeserver verfügbar sind?

Der Client konnte keinen geeigneten Domänencontroller für die Anmeldeanforderung verwenden. Danach müssen DNS, DC Locator, Netzwerk, benötigte Dienste und der Zustand der Domänencontroller geprüft werden.

Was ist eine zwischengespeicherte Domänenanmeldung?

Windows verwendet lokal gespeicherte Informationen einer früheren erfolgreichen Domänenanmeldung, wenn kein Domänencontroller erreichbar ist. Dabei findet keine vollständige aktuelle Onlineprüfung des Domänenkontos statt.

Was beweist eine erfolgreiche Cache-Anmeldung nicht?

Sie beweist weder die Erreichbarkeit eines Domänencontrollers noch den aktuellen Konto-, Kennwort-, Gruppen- oder Sperrstatus.

Warum kann nach einer Kennwortänderung offline noch das alte Kennwort funktionieren?

Der lokale Computer kann noch den Nachweis der früheren erfolgreichen Domänenanmeldung gespeichert haben. Der Cache wird erst durch eine geeignete erfolgreiche Online-Anmeldung aktualisiert.

Welche Bedeutung besitzt die Uhrzeit bei Kerberos?

Kerberos verwendet Zeitstempel zum Schutz gegen Wiederholungsangriffe. Eine zu große Zeitabweichung zwischen Client und Domänencontroller kann die Authentifizierung verhindern.

Was bedeutet ein Kerberos-Fehler 0x18?

Die Kerberos-Vorauthentifizierungsinformationen waren ungültig. Häufig wurde ein falsches Kennwort verwendet. Der konkrete Versuch muss mit Benutzer, Client und Zeitpunkt korreliert werden.

Was bedeutet Ereignis 4625?

Auf dem protokollierenden System ist eine Anmeldung fehlgeschlagen. Status, Substatus, Anmeldetyp, Konto, Quelladresse und Authentifizierungspaket müssen gemeinsam ausgewertet werden.

Was bedeutet Ereignis 4740?

Ein Benutzerkonto wurde gesperrt. Das Ereignis sollte verwendet werden, um Zeitpunkt und auslösenden Computer beziehungsweise Anmeldeweg zu bestimmen.

Was ist der sichere Kanal eines Domänencomputers?

Es ist die durch das Computerkonto und sein Kennwort abgesicherte Vertrauensbeziehung zwischen Domänenmitglied und Domäne.

Wie wird der sichere Kanal zunächst geprüft?

Auf einem Mitgliedscomputer mit:

Test-ComputerSecureChannel -Verbose

Der Test sollte zuerst ohne -Repair ausgeführt werden.

Warum ist nltest /sc_verify kein rein lesender Test?

Wenn der sichere Kanal nicht funktioniert, kann der Befehl den bestehenden Kanal entfernen und neu aufbauen.

Warum sollte ein Computer nicht sofort aus der Domäne entfernt werden?

DNS-, Netzwerk-, Zeit- oder Replikationsfehler können die eigentliche Ursache sein. Eine erneute Domänenaufnahme verändert den Systemzustand, benötigt Neustarts und kann weitere Verwaltungs- oder Profilprobleme verursachen.

Warum kann die Anmeldung über einen DC funktionieren und über einen anderen fehlschlagen?

Benutzer-, Kennwort- oder Computerkontoänderungen können wegen eines Replikationsfehlers nicht auf allen Domänencontrollern den gleichen Stand besitzen.

Warum kann die Kennwortanmeldung funktionieren, während die PIN fehlschlägt?

Die Windows-Hello-PIN verwendet einen gerätegebundenen Schlüssel und ist nicht identisch mit dem Domänenkennwort.

Warum kann Ereignis 4624 vorhanden sein, obwohl der Benutzer keinen Desktop erhält?

Die Authentifizierung und Sitzungserstellung können erfolgreich gewesen sein, während Benutzerprofil, Gruppenrichtlinie, Anmeldeskript oder eine benötigte Ressource anschließend fehlschlagen.

7.10.40 Checkliste

7.10.41 Schnellreferenz

Aufgabe Befehl
aktuelle Identität whoami
Benutzer-SID whoami /user
vollständige Domänenidentität whoami /fqdn
Gruppen der Sitzung whoami /groups
Domänenmitgliedschaft Get-CimInstance Win32_ComputerSystem
Netzwerkkonfiguration ipconfig /all
DNS-Server Get-DnsClientServerAddress
LDAP-SRV-Eintrag Resolve-DnsName _ldap._tcp.dc._msdcs.<Domäne> -Type SRV
Kerberos-SRV-Eintrag Resolve-DnsName _kerberos._tcp.<Domäne> -Type SRV
DC ermitteln nltest /dsgetdc:<Domäne>
DC neu ermitteln nltest /dsgetdc:<Domäne> /force
AD-Standort nltest /dsgetsite
DC-Liste nltest /dclist:<Domäne>
DNS-TCP-Test Test-NetConnection <DC> -Port 53
Kerberos-TCP-Test Test-NetConnection <DC> -Port 88
LDAP-TCP-Test Test-NetConnection <DC> -Port 389
SMB-TCP-Test Test-NetConnection <DC> -Port 445
RPC Endpoint Mapper Test-NetConnection <DC> -Port 135
Zeitstatus w32tm /query /status
Zeitquelle w32tm /query /source
Zeitvergleich w32tm /stripchart /computer:<DC> /dataonly /samples:5
Benutzerkonto Get-ADUser <Benutzer> -Properties *
gesperrte Konten Search-ADAccount -LockedOut -UsersOnly
sicherer Kanal, nur Test Test-ComputerSecureChannel -Verbose
letzter Netlogon-Kanalstatus nltest /sc_query:<Domäne>
Kerberos-Tickets klist tickets
Kerberos-TGT klist tgt
Anmeldefehler Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625}
DC-Gesundheit dcdiag /v
DC-DNS-Test dcdiag /test:DNS /v
Replikationsübersicht repadmin /replsummary
Replikationsdetails repadmin /showrepl
Gruppenrichtlinienergebnis gpresult /r

Ändernde Befehle, die nicht als erste Diagnose verwendet werden dürfen:

Test-ComputerSecureChannel -Repair
Reset-ComputerMachinePassword
nltest /sc_verify
nltest /sc_reset
nltest /sc_change_pwd
klist purge
w32tm /resync
gpupdate /force

7.10.42 Quellen

Offizielle Microsoft-Dokumentation

Standards

Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.

7. Schnelle Entscheidungsbäume

7.11 DNS-Leistung und fehlerhafte Reverse-Lookups

Kurz erklärt

Eine DNS-Abfrage kann grundsätzlich funktionieren und trotzdem langsam sein. Ebenso beweist ein fehlender Reverse-Lookup nicht automatisch, dass die normale Namensauflösung gestört ist.

Für eine saubere Diagnose müssen Abfragerichtung, verwendeter DNS-Server, Antwortcode, Antwortzeit, Cachezustand, Rekursion, Weiterleitung, Transportweg und Zonenverantwortung getrennt untersucht werden.

7.11.1 Ziel der Diagnose

Bei DNS-Leistungsproblemen müssen folgende Fragen beantwortet werden:

Ziel ist nicht nur eine erfolgreiche Einzelabfrage, sondern eine reproduzierbare und ausreichend schnelle Namensauflösung über den vorgesehenen DNS-Pfad.

7.11.2 Typische Störungsbilder

7.11.3 Vorwärts- und Rückwärtsauflösung unterscheiden

Abfragerichtung Eingabe Gesuchter Datensatz Ergebnis
Vorwärtsauflösung IPv4 Hostname A IPv4-Adresse
Vorwärtsauflösung IPv6 Hostname AAAA IPv6-Adresse
Rückwärtsauflösung IPv4 IPv4-Adresse PTR unter in-addr.arpa Hostname
Rückwärtsauflösung IPv6 IPv6-Adresse PTR unter ip6.arpa Hostname

Beispiel:

host25.example.test → 192.0.2.25

Dies ist eine Vorwärtsauflösung über einen A-Eintrag.

192.0.2.25 → host25.example.test

Dies ist eine Rückwärtsauflösung über einen PTR-Eintrag.

A-, AAAA- und PTR-Einträge sind getrennte DNS-Datensätze in unterschiedlichen Zonen. Ein vorhandener A- oder AAAA-Eintrag erzeugt deshalb nicht automatisch einen PTR-Eintrag, sofern kein entsprechend konfigurierter Aktualisierungsprozess vorhanden ist.

7.11.4 Aufbau einer IPv4-Rückwärtsauflösung

Für IPv4 werden die Oktette der Adresse umgekehrt und mit in-addr.arpa ergänzt.

Beispiel:

192.0.2.25

Daraus entsteht der Abfragename:

25.2.0.192.in-addr.arpa.

Der zugehörige PTR-Eintrag kann auf folgenden Namen zeigen:

host25.example.test.

Für das Netz 192.0.2.0/24 lautet die typische Reverse-Lookup-Zone:

2.0.192.in-addr.arpa

Der Knoten für die Adresse 192.0.2.25 lautet innerhalb dieser Zone:

25

Bei Adressbereichen, die nicht an einer Oktettgrenze delegiert werden, kann eine klassenlose Delegation nach RFC 2317 erforderlich sein. Der Zonenaufbau darf dann nicht allein aus der Subnetzmaske abgeleitet werden, sondern muss mit der tatsächlichen Delegation des Adressbereichs übereinstimmen.

7.11.5 Aufbau einer IPv6-Rückwärtsauflösung

IPv6-Rückwärtsauflösungen verwenden die Zone ip6.arpa.

Dabei wird:

  1. die IPv6-Adresse vollständig ausgeschrieben;
  2. jede Hexadezimalstelle einzeln betrachtet;
  3. die Reihenfolge aller Hexadezimalstellen umgekehrt;
  4. zwischen jeder Stelle ein Punkt eingefügt;
  5. ip6.arpa angehängt.

Die Delegation erfolgt auf Basis einzelner Hexadezimalstellen, sogenannter Nibbles. Eine IPv6-Reverse-Zone muss deshalb anhand des tatsächlich delegierten IPv6-Präfixes erstellt werden.

IPv6-Reverse-Namen dürfen nicht durch einfaches Umkehren der durch Doppelpunkte getrennten Adressblöcke gebildet werden.

7.11.6 Bedeutung eines fehlenden Reverse-Lookups

Ein fehlender PTR-Eintrag bedeutet zunächst nur, dass für die IP-Adresse kein entsprechender Name über Reverse-DNS ermittelt werden konnte.

Das beweist nicht automatisch:

Reverse-Lookups werden unter anderem verwendet von:

Eine Anwendung kann bei einem fehlenden PTR-Eintrag ohne Verzögerung weiterarbeiten. Eine deutliche Verzögerung entsteht eher dann, wenn die Reverse-Abfrage nicht eindeutig negativ beantwortet wird, sondern in Timeouts, fehlerhaften Delegationen oder nicht erreichbaren DNS-Servern endet.

7.11.7 nslookup zeigt den DNS-Server als „Unknown“

Eine typische Ausgabe kann folgendermaßen aussehen:

Server:  UnKnown
Address: 192.0.2.53

Das bedeutet häufig, dass für die IP-Adresse des verwendeten DNS-Servers kein auflösbarer PTR-Eintrag vorhanden ist.

Diese Meldung beweist nicht, dass der DNS-Server keine anderen Anfragen beantworten kann.

Zur Abgrenzung müssen kontrollierte Abfragen durchgeführt werden:

nslookup host25.example.test 192.0.2.53

nslookup 192.0.2.25 192.0.2.53

PTR des DNS-Servers selbst prüfen:

nslookup 192.0.2.53 192.0.2.53

Wenn die erste Abfrage erfolgreich ist, funktioniert die getestete Vorwärtsauflösung trotz der Anzeige Unknown. Der fehlende PTR-Eintrag des DNS-Servers bleibt dennoch ein zu prüfender Konfigurationsbefund.

7.11.8 DNS-Antworten richtig einordnen

Ergebnis Bedeutung Einordnung
NOERROR mit Antwort Abfrage wurde erfolgreich beantwortet Datensatz und Inhalt prüfen
NOERROR ohne gesuchten Datensatz Name kann existieren, der angefragte Datensatztyp fehlt häufig als NODATA bezeichnet
NXDOMAIN abgefragter DNS-Name existiert laut DNS-Antwort nicht Zone, Name und negative Zwischenspeicherung prüfen
SERVFAIL Server konnte keine verwertbare Antwort erzeugen Weiterleitung, Delegation, DNSSEC und Serverprotokolle prüfen
REFUSED Server lehnt die Abfrage aufgrund seiner Konfiguration oder Richtlinie ab Rekursion, ACL, Richtlinie und Abfragequelle prüfen
FORMERR DNS-Nachricht konnte nicht korrekt verarbeitet werden Client, Server, Netzwerkgerät und Paketformat prüfen
Timeout innerhalb der Wartezeit kam keine verwertbare Antwort Netzwerk, Transport, Serverlast und nachgelagerte Server prüfen
Antwort mit TC UDP-Antwort wurde abgeschnitten erneuter Versuch über TCP erforderlich
falsche Adresse oder falscher PTR DNS antwortet, aber mit unerwarteten Daten Zone, Replikation, Cache und Datensatz prüfen

Ein Timeout ist kein DNS-Antwortcode. Er bedeutet, dass der Client innerhalb seiner Wartezeit keine verwendbare DNS-Antwort erhalten hat.

7.11.9 Ausgangszustand dokumentieren

Vor Änderungen sind mindestens folgende Informationen zu erfassen:

DNS-Caches dürfen nicht gelöscht werden, bevor der ursprüngliche Cachezustand und die fehlerhafte Antwort dokumentiert wurden.

7.11.10 Verwendete DNS-Konfiguration prüfen

Windows

ipconfig /all

Get-DnsClientServerAddress

Get-DnsClient

Linux

cat /etc/resolv.conf

Bei Systemen mit systemd-resolved zusätzlich:

resolvectl status

macOS

scutil --dns

Zu prüfen sind:

Die Datei /etc/resolv.conf kann bei dynamisch verwalteten Linux-Systemen nur auf einen lokalen Stub-Resolver verweisen. Bei systemd-resolved muss deshalb zusätzlich dessen tatsächliche Schnittstellenkonfiguration geprüft werden.

7.11.11 Lokale Namensquellen und Resolverpfad berücksichtigen

Eine Anwendung muss nicht zwingend direkt den konfigurierten DNS-Server abfragen. Je nach Betriebssystem und Anwendung können vorher oder zusätzlich verwendet werden:

Hosts-Dateien:

Betriebssystem Pfad
Windows C:\Windows\System32\drivers\etc\hosts
Linux /etc/hosts
macOS /etc/hosts

Eine erfolgreiche Anwendungssuche beweist nicht, dass DNS verwendet wurde. Umgekehrt beweist eine erfolgreiche direkte DNS-Abfrage nicht, dass die Anwendung denselben Resolverpfad benutzt.

7.11.12 Split-DNS, VPN und NRPT prüfen

Bei Split-DNS kann derselbe Name abhängig vom verwendeten Netzwerk oder DNS-Server unterschiedliche Antworten liefern.

Beispiel:

app.example.test → interne IP über Unternehmens-DNS
app.example.test → öffentliche IP über öffentlichen DNS

Unter Windows können VPN-Profile über die Name Resolution Policy Table festlegen, welche Namensräume an bestimmte DNS-Server gesendet werden.

Wirksame NRPT-Richtlinien anzeigen:

Get-DnsClientNrptPolicy

Konfigurierte NRPT-Regeln anzeigen:

Get-DnsClientNrptRule

Zu prüfen sind:

nslookup verwendet für solche Tests nicht zwingend denselben Windows-Resolverpfad wie Anwendungen, die die Windows-DNS-API und NRPT nutzen. Für die Prüfung von NRPT sollte deshalb zusätzlich Resolve-DnsName verwendet werden.

7.11.13 Verschlüsseltes DNS mit DoH und DoT abgrenzen

DNS over HTTPS und DNS over TLS verändern den Transportweg der DNS-Abfrage.

Dadurch können klassische Tests über UDP- oder TCP-Port 53 erfolgreich sein, obwohl der verschlüsselte DNS-Pfad fehlschlägt – oder umgekehrt.

Windows-DNS-Clientzustand anzeigen:

netsh dnsclient show state

Globale Einstellungen anzeigen:

netsh dnsclient show global

Konfigurierte verschlüsselte DNS-Server anzeigen:

netsh dnsclient show encryption

Zu prüfen sind:

Für die DNS-Serverrolle unterstützt Microsoft DoH ab Windows Server 2025 mit dem in der Microsoft-Bereitstellungsdokumentation genannten Sicherheitsupdate KB5094125 vom Juni 2026 oder einem späteren Update.

Serverkonfiguration auf einem unterstützten System anzeigen:

Get-DnsServerEncryptionProtocol

DoH schützt den Transport zwischen DoH-Client und DNS-Server. Nachgelagerte Abfragen an Forwarder oder autoritative DNS-Server, Zonentransfers und dynamische Updates werden dadurch nicht automatisch verschlüsselt.

DoH und DNSSEC erfüllen unterschiedliche Aufgaben:

7.11.14 Vorwärtsauflösung gezielt testen

Windows PowerShell

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

AAAA-Eintrag:

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type AAAA `
  -Server "192.0.2.53" `
  -DnsOnly

Windows Eingabeaufforderung

nslookup host25.example.test 192.0.2.53

Linux und macOS

dig @192.0.2.53 host25.example.test A

dig @192.0.2.53 host25.example.test AAAA

Entscheidend ist, den DNS-Server ausdrücklich anzugeben. Andernfalls können unterschiedliche Resolver, VPN-Regeln oder Cachezustände zu nicht vergleichbaren Ergebnissen führen.

7.11.15 Rückwärtsauflösung gezielt testen

Windows PowerShell

Resolve-DnsName `
  -Name "192.0.2.25" `
  -Type PTR `
  -Server "192.0.2.53" `
  -DnsOnly

Windows Eingabeaufforderung

nslookup 192.0.2.25 192.0.2.53

Linux und macOS

dig @192.0.2.53 -x 192.0.2.25

Kompakte Ausgabe mit Antwort und Statistik:

dig @192.0.2.53 -x 192.0.2.25 +noall +answer +comments +stats

Direkte Abfrage des vollständigen Reverse-Namens:

dig @192.0.2.53 25.2.0.192.in-addr.arpa PTR

Zu dokumentieren sind:

7.11.16 A-, AAAA-, CNAME-, PTR- und SRV-Probleme abgrenzen

Datensatz Aufgabe Typischer Fehler
A Name zu IPv4-Adresse falsche oder veraltete IPv4-Adresse
AAAA Name zu IPv6-Adresse falsche oder nicht erreichbare IPv6-Adresse
CNAME Alias zu anderem DNS-Namen fehlerhaftes Ziel oder lange Alias-Kette
PTR IP-Adresse zu Name fehlender, falscher oder veralteter Reverse-Eintrag
SRV Dienst zu Zielhost und Port falsches Ziel, falscher Port oder fehlender Zielhost

CNAME prüfen:

Resolve-DnsName `
  -Name "alias.example.test" `
  -Type CNAME `
  -Server "192.0.2.53" `
  -DnsOnly

SRV prüfen:

Resolve-DnsName `
  -Name "_service._tcp.example.test" `
  -Type SRV `
  -Server "192.0.2.53" `
  -DnsOnly

Mit dig:

dig @192.0.2.53 alias.example.test CNAME

dig @192.0.2.53 _service._tcp.example.test SRV

Bei CNAME- und SRV-Datensätzen muss zusätzlich geprüft werden, ob der zurückgegebene Zielname über A oder AAAA auflösbar und anschließend über den angegebenen Dienstport erreichbar ist.

Ein erfolgreicher SRV-Lookup beweist nicht, dass der veröffentlichte Dienst erreichbar ist.

7.11.17 Antwortzeit reproduzierbar messen

Ein einzelner Messwert reicht nicht aus. Mindestens folgende Fälle müssen getrennt betrachtet werden:

Linux und macOS

dig zeigt die DNS-Abfragezeit als Query time an:

dig @192.0.2.53 host25.example.test A +stats

TCP erzwingen:

dig @192.0.2.53 host25.example.test A +tcp +stats

Windows PowerShell

Measure-Command {
    Resolve-DnsName `
      -Name "host25.example.test" `
      -Type A `
      -Server "192.0.2.53" `
      -DnsOnly
}

TCP erzwingen:

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly `
  -TcpOnly

Measure-Command misst den gesamten PowerShell-Befehlsablauf und nicht ausschließlich die reine DNS-Übertragungszeit. Die Werte eignen sich deshalb vor allem zum kontrollierten Vergleich unter denselben Bedingungen.

7.11.18 Kalte und zwischengespeicherte Abfragen unterscheiden

Eine erste rekursive Abfrage kann langsamer sein, weil der DNS-Server weitere Server kontaktieren muss. Eine Wiederholung kann aus einem Cache beantwortet werden.

Beobachtung Mögliche Einordnung
erste Abfrage langsam, Wiederholung schnell Server-, Client- oder Anwendungscache wirkt
jede Abfrage langsam Netzwerk, Serverlast, Weiterleitung oder autoritativen Pfad prüfen
nur nicht vorhandene Namen langsam negative Antworten, fehlerhafte Delegation oder Timeoutpfad prüfen
nur externe Namen langsam Rekursion, Forwarder oder Internetpfad prüfen
nur interne Namen langsam interne Zone, Delegation, AD-Replikation oder Standort prüfen
nur Reverse-Lookups langsam Reverse-Zone, Delegation und PTR-Pfad prüfen
autoritativer Server schnell, rekursiver Server langsam Rekursion, Cache oder Forwarder prüfen
UDP langsam oder fehlerhaft, TCP erfolgreich Firewall, Fragmentierung, EDNS oder Netzwerkpfad prüfen

Ein schneller Cachetreffer beweist nicht, dass der vollständige rekursive beziehungsweise autoritative Pfad funktioniert.

7.11.19 Windows-DNS-Clientcache prüfen

Cacheinhalt anzeigen:

ipconfig /displaydns

Alternativ:

Get-DnsClientCache

Zu prüfen sind:

Cache löschen:

Clear-DnsClientCache

Alternativ:

ipconfig /flushdns

Das Löschen des Clientcaches verändert den Ausgangszustand. Es darf erst nach Dokumentation und nur als kontrollierter Vergleich erfolgen.

7.11.20 TTL und negative Zwischenspeicherung berücksichtigen

Die TTL bestimmt, wie lange ein Datensatz zwischengespeichert werden darf.

Eine sehr niedrige TTL kann:

Eine sehr hohe TTL kann:

Auch negative Antworten werden zwischengespeichert. Deshalb kann ein Name nach dem nachträglichen Anlegen des Datensatzes zunächst weiterhin als nicht vorhanden erscheinen.

Zu prüfen sind:

Caches dürfen nicht routinemäßig geleert werden, um eine falsche TTL- oder Zonenplanung dauerhaft zu umgehen.

7.11.21 DNS über UDP und TCP abgrenzen

Klassische DNS-Abfragen verwenden häufig UDP-Port 53. TCP-Port 53 wird unter anderem benötigt:

Windows-TCP-Test:

Test-NetConnection "192.0.2.53" -Port 53

Dieser Befehl prüft ausschließlich TCP. Er beweist nicht, dass UDP-Port 53 funktioniert.

Ein echter UDP-DNS-Test erfolgt durch eine normale DNS-Abfrage:

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

Vergleich über TCP:

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly `
  -TcpOnly

Wenn UDP-Abfragen scheitern und TCP-Abfragen funktionieren, sind unter anderem Firewallregeln, Paketverlust, Fragmentierung, EDNS-Verarbeitung, MTU und zwischengeschaltete Netzwerkgeräte zu prüfen.

7.11.22 EDNS, MTU, Fragmentierung und DNSSEC prüfen

EDNS ermöglicht unter anderem größere DNS-Antworten über UDP. Auf Netzwerkpfaden mit ungeeigneter MTU oder fehlerhafter Fragmentbehandlung können deshalb kleine Abfragen funktionieren, während größere Antworten ausfallen.

Typische Hinweise:

DNSSEC-Daten anfordern:

Resolve-DnsName `
  -Name "example.com" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly `
  -DnssecOk

Mit dig:

dig @192.0.2.53 example.com A +dnssec

Vergleich über TCP:

dig @192.0.2.53 example.com A +dnssec +tcp

EDNS testweise unterdrücken:

dig @192.0.2.53 example.com A +noedns

Zu beachten ist:

7.11.23 Autoritative Antwort, Rekursion und Weiterleitung unterscheiden

Ein DNS-Server kann eine Antwort liefern:

Für eine saubere Diagnose sind mindestens drei Ebenen zu vergleichen:

  1. Abfrage über den vom Client verwendeten DNS-Server;
  2. Abfrage über einen alternativen vorgesehenen DNS-Server;
  3. Abfrage über den autoritativen DNS-Server der betroffenen Zone.

Wenn der autoritative Server schnell und korrekt antwortet, der rekursive Server jedoch langsam ist, liegt die Ursache wahrscheinlich bei Rekursion, Cache, Weiterleitung oder Delegationspfad.

7.11.24 Delegation der Reverse-Zone prüfen

Für eine Rückwärtsauflösung muss die DNS-Hierarchie auf den zuständigen autoritativen Server verweisen.

Linux und macOS

dig -x 192.0.2.25 +trace

Zuständige Nameserver der Reverse-Zone prüfen:

dig 2.0.192.in-addr.arpa NS

Zu prüfen sind:

Eine lokal erstellte Reverse-Zone ersetzt bei öffentlichen Adressen nicht die Delegation durch den Eigentümer beziehungsweise Provider des IP-Adressbereichs.

7.11.25 Private und öffentliche Reverse-Zonen unterscheiden

Private IP-Adressen

Für interne private Netze kann die Organisation die Reverse-Zonen auf ihren internen DNS-Servern verwalten.

Zu prüfen sind:

Öffentliche IP-Adressen

Der PTR-Eintrag einer öffentlichen IP-Adresse wird normalerweise durch den Betreiber verwaltet, dem der entsprechende Adressbereich delegiert wurde.

Ein PTR-Eintrag für eine öffentliche IP-Adresse kann daher nicht allein dadurch veröffentlicht werden, dass in der normalen Forward-Zone der eigenen Domain ein Datensatz angelegt wird.

Zu klären sind:

7.11.26 Vorwärts- und Rückwärtskonsistenz prüfen

Beispiel für einen konsistenten Zustand:

host25.example.test. A 192.0.2.25

25.2.0.192.in-addr.arpa. PTR host25.example.test.

Anschließend wird der PTR-Zielname wieder vorwärts aufgelöst:

host25.example.test. A 192.0.2.25

Prüfschritte:

  1. IP-Adresse rückwärts auflösen.
  2. PTR-Zielnamen dokumentieren.
  3. PTR-Zielnamen über A und AAAA auflösen.
  4. Prüfen, ob die ursprüngliche IP-Adresse in den Ergebnissen enthalten ist.
  5. Alle beteiligten autoritativen DNS-Server vergleichen.

Mögliche Befunde:

Befund Einordnung
kein PTR vorhanden Reverse-Eintrag fehlt oder Zone ist nicht erreichbar
PTR zeigt auf alten Hostnamen veralteter Datensatz
PTR-Zielname existiert nicht unvollständige DNS-Konfiguration
PTR-Zielname zeigt auf andere IP Vorwärts- und Rückwärtsdaten stimmen nicht überein
mehrere PTR-Einträge technisch möglich, kann Anwendungen jedoch unterschiedlich beeinflussen
mehrere A- oder AAAA-Adressen kann bei Clustern, Load Balancing oder Mehrfachanbindung vorgesehen sein
verschiedene DNS-Server liefern verschiedene PTR-Werte Replikation, Zonentransfer oder uneinheitliche Konfiguration prüfen

Eine Vorwärts-Rückwärts-Konsistenz ist nicht für jede DNS-Anwendung zwingend vorgeschrieben. Bestimmte Mail-, Sicherheits- oder Identitätsprüfungen können sie jedoch voraussetzen.

7.11.27 Windows-DNS-Serverdienst und Zonen prüfen

Auf dem DNS-Server:

Get-Service -Name DNS

Zonen anzeigen:

Get-DnsServerZone

Nur Reverse-Lookup-Zonen:

Get-DnsServerZone |
    Where-Object { $_.IsReverseLookupZone }

Zustand einer bestimmten Zone:

Get-DnsServerZone `
  -Name "2.0.192.in-addr.arpa"

Zu prüfen sind:

Ein laufender DNS-Dienst beweist nicht, dass eine bestimmte Zone korrekt geladen oder erreichbar ist.

7.11.28 PTR-Datensätze auf dem Windows-DNS-Server prüfen

Alle PTR-Einträge einer Zone:

Get-DnsServerResourceRecord `
  -ZoneName "2.0.192.in-addr.arpa" `
  -RRType PTR

Bestimmten Eintrag prüfen:

Get-DnsServerResourceRecord `
  -ZoneName "2.0.192.in-addr.arpa" `
  -Name "25" `
  -RRType PTR

Von einem bestimmten DNS-Server lesen:

Get-DnsServerResourceRecord `
  -ComputerName "dns01.example.test" `
  -ZoneName "2.0.192.in-addr.arpa" `
  -Name "25" `
  -RRType PTR

Zu vergleichen sind:

Ein fehlender beziehungsweise als statisch dargestellter Zeitstempel kann auf einen statisch angelegten Datensatz hinweisen. Solche Datensätze werden nicht wie dynamisch gealterte Datensätze behandelt.

7.11.29 Rekursion, Forwarder und Cache des Windows-DNS-Servers prüfen

Allgemeine Forwarder:

Get-DnsServerForwarder

Rekursionseinstellungen:

Get-DnsServerRecursion

Root Hints:

Get-DnsServerRootHint

Cacheeinstellungen:

Get-DnsServerCache

Zu prüfen sind:

Nicht erreichbare Forwarder können Verzögerungen verursachen, bevor ein weiterer Forwarder oder ein alternativer Auflösungspfad verwendet wird.

7.11.30 DNS-Serverstatistiken auswerten

Aggregierte Statistiken:

Get-DnsServerStatistics

Statistiken einer bestimmten Zone:

Get-DnsServerStatistics `
  -ZoneName "2.0.192.in-addr.arpa"

Die genaue Struktur der Ausgabe hängt von der Windows-Server-Version ab. Zu untersuchen sind unter anderem:

Statistiken dürfen nicht ohne vorherige Sicherung des Ausgangswerts zurückgesetzt werden.

Das Cmdlet kann bei zonenbezogener Verwendung mit -Clear Zähler verändern. Diese Option ist deshalb keine rein lesende Diagnosemaßnahme.

7.11.31 Leistungsindikatoren überwachen

Verfügbare DNS-Leistungsindikatoren anzeigen:

Get-Counter -ListSet DNS

Beispiel für empfangene DNS-Abfragen und gesendete Antworten:

Get-Counter `
  '\DNS\Total Query Received/sec',
  '\DNS\Total Response Sent/sec' `
  -SampleInterval 2 `
  -MaxSamples 10

DNS-Prozess überwachen:

Get-Counter `
  '\Process(dns)\% Processor Time',
  '\Process(dns)\Working Set' `
  -SampleInterval 2 `
  -MaxSamples 10

Die Namen der Leistungsindikatoren können auf lokalisierten Windows-Systemen abweichen. Deshalb sollte zuerst Get-Counter -ListSet DNS verwendet werden.

Zu korrelieren sind:

Eine hohe Anzahl von Abfragen ist allein kein Fehler. Entscheidend sind Baseline, Hardware, Abfrageart, Cachetreffer, Rekursion, Fehlerquote und Antwortzeit.

7.11.32 Protokollierung kontrolliert einsetzen

Windows DNS Server stellt unter anderem folgende Ereignisprotokolle bereit:

Applications and Services Logs
└─ Microsoft
   └─ Windows
      └─ DNS-Server
         ├─ Audit
         └─ Analytical

Das Audit-Protokoll erfasst administrative und sicherheitsrelevante DNS-Vorgänge. Das analytische Protokoll kann detaillierte Abfrageinformationen liefern, ist jedoch standardmäßig nicht aktiviert.

Zu beachten ist:

Microsoft weist darauf hin, dass analytische DNS-Protokollierung bei sehr hohen Abfrageraten messbare Leistungseinflüsse verursachen kann. Deshalb muss sie mit den Leistungswerten des Servers korreliert werden.

7.11.33 Netzwerkaufzeichnung gezielt verwenden

Wenn DNS-Abfragen weiterhin unklar bleiben, kann eine zeitlich und inhaltlich begrenzte Netzwerkaufzeichnung erforderlich sein.

Zu prüfen sind:

DNS-Pakete können interne Hostnamen, Dienstnamen und andere schützenswerte Informationen enthalten. Aufzeichnungen müssen deshalb nach Sicherheits- und Datenschutzvorgaben behandelt werden.

7.11.34 Dynamische DNS-Aktualisierung prüfen

Windows-Clients können ihre DNS-Namen dynamisch registrieren:

Register-DnsClient

Alternativ:

ipconfig /registerdns

Diese Befehle lösen eine dynamische Aktualisierung aus und verändern damit möglicherweise den DNS-Zustand. Vorher sind vorhandene Datensätze, Zeitstempel und Ereignisse zu dokumentieren.

Zu prüfen sind:

Das wiederholte Ausführen von Register-DnsClient behebt keine fehlende Reverse-Zone, falsche Berechtigungen oder fehlerhafte DHCP-DNS-Einstellungen.

7.11.35 DHCP und PTR-Registrierung prüfen

Bei dynamisch vergebenen IP-Adressen kann der DHCP-Server DNS-Einträge im Auftrag des Clients aktualisieren.

Zu untersuchen sind:

Mögliche Fehlerbilder:

7.11.36 Aging und Scavenging berücksichtigen

Aging und Scavenging können veraltete dynamische DNS-Datensätze entfernen. Die Funktion beinhaltet Löschvorgänge und muss deshalb kontrolliert geplant werden.

Zu prüfen sind:

Scavenging sollte nicht spontan aktiviert oder manuell erzwungen werden, nur weil einzelne PTR-Einträge veraltet sind. Eine falsche Konfiguration kann gültige DNS-Datensätze löschen.

7.11.37 Active-Directory-integrierte DNS-Zonen prüfen

Bei AD-integrierten Zonen können unterschiedliche Antworten auf Replikationsprobleme hinweisen.

DNS-Test für einen Domänencontroller:

dcdiag /test:DNS /v /s:<DC-Name>

Replikationsübersicht:

repadmin /replsummary

Replikationsdetails:

repadmin /showrepl

Zu prüfen sind:

Eine erzwungene Replikation ist keine erste Diagnosemaßnahme. Zuerst müssen Richtung, Partner, Fehlercode und Ursache bestimmt werden.

7.11.38 Systematischer Diagnoseablauf

  1. Störungsbild dokumentieren
    Client, Anwendung, Name oder IP-Adresse, Uhrzeit und genaue Verzögerung erfassen.

  2. Abfragerichtung bestimmen
    Vorwärtsauflösung, Rückwärtsauflösung oder beide unterscheiden.

  3. Umfang bestimmen
    Einzelner Client, Anwendung, Standort, Zone oder alle Systeme unterscheiden.

  4. Resolverpfad erfassen
    DNS-Server, VPN, Suchsuffixe, Hosts-Datei, NRPT, DoH, DoT und lokale Resolver prüfen.

  5. Abfrage reproduzieren
    Den vorgesehenen DNS-Server ausdrücklich angeben.

  6. Antwortcode dokumentieren
    NOERROR, NXDOMAIN, SERVFAIL, REFUSED oder Timeout unterscheiden.

  7. Antwortzeit messen
    Erste und wiederholte Abfrage getrennt messen.

  8. Vorwärts- und Reverse-Abfrage vergleichen
    A beziehungsweise AAAA und PTR unabhängig testen.

  9. Alternativen DNS-Server testen
    Unterschiedliche Serverantworten dokumentieren.

  10. UDP und TCP vergleichen
    Transportabhängige Fehler abgrenzen.

  11. DoH oder DoT abgrenzen
    Verschlüsselten und klassischen DNS-Pfad getrennt prüfen.

  12. Autoritativen Server bestimmen
    Delegation und zuständige Zone prüfen.

  13. Direkte autoritative Abfrage durchführen
    Rekursion und Forwarder vom Zonenzustand trennen.

  14. PTR-Datensatz prüfen
    Zielname, TTL, Zeitstempel und Eigentümer auswerten.

  15. Vorwärts-Rückwärts-Konsistenz prüfen
    PTR-Zielnamen erneut über A und AAAA auflösen.

  16. Weitere Datensatztypen prüfen
    CNAME- oder SRV-Abhängigkeiten berücksichtigen.

  17. Cachezustand prüfen
    Client-, Server- und Anwendungscache unterscheiden.

  18. Forwarder und Rekursion prüfen
    Besonders bei langsamen externen oder bedingt weitergeleiteten Zonen.

  19. EDNS, MTU und DNSSEC prüfen
    Wenn kleine Antworten funktionieren und größere Antworten ausfallen.

  20. Serverleistung prüfen
    Abfragerate, CPU, Speicher, Fehler und Timeouts korrelieren.

  21. Dynamische Aktualisierung prüfen
    Client, DHCP, Berechtigungen und Zonenrichtlinie untersuchen.

  22. Aging und Scavenging prüfen
    Veraltete oder unerwartet gelöschte Datensätze abgrenzen.

  23. AD-Replikation prüfen
    Wenn DNS-Server unterschiedliche Antworten liefern.

  24. Hypothese formulieren
    Erwarteten Befund und möglichen Gegenbeweis festlegen.

  25. Eine kontrollierte Maßnahme durchführen
    Risiko, Rückweg und Erfolgskriterium dokumentieren.

  26. Erneut unter denselben Bedingungen messen
    Antwort, Code und Zeit mit dem Ausgangswert vergleichen.

  27. Gesamten DNS-Pfad verifizieren
    Client, rekursiven Server, autoritativen Server und Anwendung prüfen.

  28. Präventionsmaßnahme dokumentieren
    Ursache und dauerhafte Verbesserung festhalten.

7.11.39 Befundmatrix

Befund Mögliche Erklärung Nächster Nachweis
nslookup zeigt Unknown, andere Abfragen funktionieren PTR des DNS-Servers fehlt DNS-Server-IP rückwärts abfragen
Vorwärtsauflösung funktioniert, Reverse nicht PTR oder Reverse-Zone fehlt PTR-Abfrage und Zonenprüfung
Reverse-Abfrage endet sofort mit NXDOMAIN Name oder Zone meldet Nichtvorhandensein Autorität und SOA der Antwort prüfen
Reverse-Abfrage läuft in Timeout Server, Delegation oder Netzwerkpfad antwortet nicht autoritative Server und Paketpfad prüfen
PTR zeigt auf alten Hostnamen veralteter statischer oder dynamischer Eintrag Lease, Zeitstempel und Datensatzeigentümer prüfen
PTR-Zielname besitzt keinen A-/AAAA-Eintrag unvollständige DNS-Konfiguration Zielnamen vorwärts auflösen
PTR-Zielname zeigt auf andere IP Vorwärts-Rückwärts-Abweichung vorgesehene Mehrfachadressierung prüfen
erste Abfrage langsam, zweite schnell Cacheeffekt kalte und warme Messung vergleichen
jede externe Abfrage langsam Forwarder oder Rekursion direkte Abfragen gegen Forwarder und Autorität
nur interne Zone langsam interne Delegation oder AD-DNS autoritative interne Server vergleichen
nur ein DNS-Server liefert falsche Antwort lokaler Cache, Zone oder Replikation Server direkt vergleichen
UDP fehlerhaft, TCP erfolgreich Firewall, EDNS, Fragmentierung oder MTU Transportvergleich und Netzwerkaufzeichnung
SERVFAIL nur bei signierter Zone DNSSEC-Validierung oder Delegation Validierungskette und Serverereignisse prüfen
REFUSED Rekursion oder Richtlinie verweigert Abfrage Serverrichtlinie und Quellnetz prüfen
A-Eintrag vorhanden, PTR fehlt Reverse-Zone oder Updatepfad fehlt DHCP-, Client- und Zonenupdate prüfen
PTR wird nach IP-Wechsel nicht entfernt Aging, Scavenging oder DHCP-Bereinigung Leaseablauf, Zeitstempel und Zonenalterung
unterschiedliche Antworten je DC AD-Replikation oder uneinheitliche Zone repadmin, dcdiag und direkte Abfragen
Auflösung über IP schnell, über Namen langsam DNS oder nachgelagerte Namensprüfung direkte DNS-Zeit und Anwendungspfad vergleichen
öffentliche IP besitzt keinen PTR Provider hat keinen Reverse-Eintrag gesetzt Betreiber des IP-Präfixes ermitteln
neuer Datensatz bleibt zunächst unsichtbar positiver oder negativer Cache TTL und Cacheebenen prüfen
nslookup und Anwendung liefern verschiedene Ergebnisse NRPT, DoH oder anwendungseigener Resolver tatsächlichen Resolverpfad bestimmen
nur große Antworten schlagen fehl EDNS-, MTU- oder Fragmentierungsproblem UDP/TCP und Antwortgrößen vergleichen
SRV wird gefunden, Dienst funktioniert nicht Zielhost, Port oder Dienst fehlerhaft SRV-Ziel und Dienstport prüfen
CNAME wird aufgelöst, Zielname jedoch nicht fehlerhaftes Aliasziel CNAME-Kette vollständig prüfen
klassisches DNS funktioniert, DoH nicht Zertifikat, HTTPS-Port oder DoH-Endpunkt DoH-Zustand und TLS-Verbindung prüfen

7.11.40 Ursachen und erforderliche Nachweise

Mögliche Ursache Erforderlicher Nachweis
falscher DNS-Server Clientkonfiguration und direkte Abfragen bestätigen abweichenden Resolver
falsches DNS-Suffix Resolverkonfiguration zeigt unerwartete Suchdomäne
Hosts-Datei überschreibt DNS lokaler Eintrag liefert abweichende Zuordnung
anwendungseigener DNS-Cache Anwendung liefert trotz korrektem Systemtest alten Wert
NRPT-Fehler wirksame Richtlinie leitet den Namensraum an falschen Resolver
fehlerhafter Split-DNS-Pfad interne und externe Resolver liefern unbeabsichtigt verschiedene Antworten
DoH- oder DoT-Fehler verschlüsselter Pfad scheitert bei funktionierendem klassischem DNS
fehlende Reverse-Zone zuständiger DNS-Server besitzt oder erreicht die Zone nicht
fehlender PTR-Eintrag autoritative PTR-Abfrage liefert keinen Datensatz
falscher PTR-Eintrag autoritative Antwort enthält unerwarteten Zielnamen
fehlerhafte Delegation übergeordnete Zone verweist auf falsche oder nicht erreichbare Server
fehlerhafte RFC-2317-Konfiguration CNAME- und Zonendelegation des Teilnetzes sind unvollständig
fehlerhafte IPv6-Reverse-Zone Nibble-Zone stimmt nicht mit dem delegierten Präfix überein
nicht erreichbarer Forwarder direkte Abfrage zum Forwarder scheitert reproduzierbar
langsamer autoritativer Server direkte autoritative Abfrage zeigt erhöhte Antwortzeit
UDP-Blockierung UDP-DNS scheitert, TCP-DNS funktioniert
TCP-Blockierung abgeschnittene UDP-Antwort kann nicht über TCP wiederholt werden
Paketverlust Aufzeichnung zeigt Wiederholungen oder fehlende Antworten
MTU- oder Fragmentierungsproblem große UDP-Antworten scheitern, TCP funktioniert
DNS-Serverüberlastung erhöhte Antwortzeit korreliert mit Abfragerate und Ressourcenlast
ungeeignete TTL Datensatz- und Cachewerte bestätigen zu kurze oder zu lange Speicherung
negativer Cache zuvor negative Antwort bleibt bis zum Ablauf wirksam
falscher CNAME Alias verweist auf fehlenden oder falschen Zielnamen
falscher SRV-Eintrag Dienstziel, Port, Priorität oder Gewicht sind unzutreffend
DHCP aktualisiert PTR nicht DHCP-Ereignis oder Konfiguration bestätigt fehlgeschlagene Aktualisierung
fehlende Updateberechtigung DNS- oder DHCP-Protokoll zeigt Zugriffsfehler
veralteter statischer PTR statischer Datensatz enthält alten Namen
fehlerhaftes Scavenging Konfiguration oder Ereignisse bestätigen unerwartete Löschung
AD-Replikationsproblem DNS-Server liefern unterschiedliche autoritative Daten und repadmin meldet Fehler
DNSSEC-Validierungsfehler SERVFAIL und Validierungsdaten bestätigen fehlerhafte Vertrauenskette
öffentlicher PTR nicht delegiert Provider beziehungsweise Präfixbetreiber bestätigt fehlende Reverse-Konfiguration

7.11.41 Kontrollierte Maßnahmen, Risiko und Rückweg

Maßnahme Risiko Rückweg beziehungsweise Kontrolle
vorgesehenen DNS-Server konfigurieren andere Namensräume können beeinflusst werden bisherige DNS-Werte dokumentieren
falsches DNS-Suffix korrigieren Suchverhalten verändert sich ursprüngliche Suffixliste sichern
fehlerhaften Hosts-Eintrag entfernen Anwendung verliert lokale Sonderzuordnung Datei und ursprünglichen Eintrag sichern
NRPT-Regel korrigieren VPN-Namensauflösung kann ausfallen bisherige Regel und Zielserver sichern
DoH- oder DoT-Konfiguration korrigieren Transport und Fallbackverhalten ändern sich bisherigen Verschlüsselungszustand dokumentieren
fehlende Reverse-Zone anlegen falscher Adressbereich kann überschrieben werden Netz-ID und Zuständigkeit vorher bestätigen
PTR-Eintrag anlegen falscher Name wird veröffentlicht IP, FQDN und Forward-Eintrag vorher prüfen
veralteten PTR korrigieren bestehende Abhängigkeiten können betroffen sein alten Wert und Eigentümer dokumentieren
Forwarder korrigieren externe und interne Auflösung kann beeinflusst werden bisherige Forwarderliste sichern
Delegation korrigieren gesamter Reverse-Bereich kann betroffen sein bisherige NS- und CNAME-Daten sichern
dynamische Updates korrigieren viele Clients können Datensätze verändern Zonenrichtlinie und Berechtigungen dokumentieren
Clientregistrierung auslösen mehrere A- oder PTR-Einträge können entstehen vorhandene Einträge vorher erfassen
Clientcache kontrolliert löschen ursprünglicher Cachebefund geht verloren Cacheinhalt vorher dokumentieren
DNS-Servercache löschen viele Abfragen müssen erneut rekursiv aufgelöst werden nur gezielt und mit Lastkontrolle
TTL ändern Cacheverhalten vieler Resolver ändert sich bisherigen Wert und Änderungszeit sichern
Aging oder Scavenging anpassen gültige Datensätze können gelöscht werden Zonenexport und Änderungsplan vorsehen
AD-Replikationsfehler beheben mehrere DNS- und AD-Daten können betroffen sein DC-spezifischen Wiederherstellungsplan verwenden
analytische Protokollierung aktivieren Leistung und Datenschutz können betroffen sein Zeitfenster, Speicherlimit und Abschaltung festlegen

Pro Diagnoseversuch sollte möglichst nur eine relevante Variable verändert werden.

7.11.42 Beispiel: Reverse-Zone und PTR-Eintrag anlegen

Die folgenden Befehle sind verändernde Administrationsmaßnahmen und dürfen erst nach Prüfung von Netzbereich, Zonenverantwortung, Replikationsbereich und bestehender Konfiguration ausgeführt werden.

AD-integrierte IPv4-Reverse-Zone für das Dokumentationsnetz 192.0.2.0/24:

Add-DnsServerPrimaryZone `
  -NetworkID "192.0.2.0/24" `
  -ReplicationScope "Forest"

PTR-Eintrag für 192.0.2.25:

Add-DnsServerResourceRecordPtr `
  -Name "25" `
  -ZoneName "2.0.192.in-addr.arpa" `
  -PtrDomainName "host25.example.test."

Danach kontrollieren:

Get-DnsServerResourceRecord `
  -ZoneName "2.0.192.in-addr.arpa" `
  -Name "25" `
  -RRType PTR

Resolve-DnsName `
  -Name "192.0.2.25" `
  -Type PTR `
  -Server "192.0.2.53" `
  -DnsOnly

Zusätzlich muss der PTR-Zielname vorwärts geprüft werden:

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

Die Beispieladressen und Namen dienen ausschließlich der Dokumentation und müssen durch die tatsächlich autorisierten Werte ersetzt werden.

7.11.43 Verifikation

Nach einer Maßnahme sind mindestens folgende Punkte zu prüfen:

Eine einzelne erfolgreiche Cacheabfrage ist keine ausreichende Verifikation des vollständigen DNS-Pfads.

7.11.44 Präventionsmaßnahmen

7.11.45 Typische Fehler bei der Diagnose

7.11.46 Checkliste

7.11.47 Schnellreferenz

Aufgabe Befehl
Windows-Netzwerk- und DNS-Konfiguration ipconfig /all
Windows-DNS-Serveradressen Get-DnsClientServerAddress
Windows-DNS-Clientzustand Get-DnsClient
Linux-Resolverzustand resolvectl status
macOS-Resolverzustand scutil --dns
wirksame NRPT-Richtlinie Get-DnsClientNrptPolicy
konfigurierte NRPT-Regeln Get-DnsClientNrptRule
DoH-/DoT-Clientzustand netsh dnsclient show state
verschlüsselte DNS-Server netsh dnsclient show encryption
Vorwärtsauflösung IPv4 Resolve-DnsName <Name> -Type A -Server <DNS-IP> -DnsOnly
Vorwärtsauflösung IPv6 Resolve-DnsName <Name> -Type AAAA -Server <DNS-IP> -DnsOnly
Rückwärtsauflösung Resolve-DnsName <IP> -Type PTR -Server <DNS-IP> -DnsOnly
Rückwärtsauflösung mit dig dig @<DNS-IP> -x <IP>
CNAME prüfen Resolve-DnsName <Name> -Type CNAME -Server <DNS-IP> -DnsOnly
SRV prüfen Resolve-DnsName <SRV-Name> -Type SRV -Server <DNS-IP> -DnsOnly
TCP-DNS-Abfrage Resolve-DnsName <Name> -Server <DNS-IP> -TcpOnly -DnsOnly
TCP-Port 53 prüfen Test-NetConnection <DNS-IP> -Port 53
DNSSEC-Daten anfordern Resolve-DnsName <Name> -Server <DNS-IP> -DnssecOk
Clientcache anzeigen Get-DnsClientCache
Clientcache löschen Clear-DnsClientCache
DNS-Serverdienst Get-Service DNS
DNS-Zonen Get-DnsServerZone
PTR-Einträge Get-DnsServerResourceRecord -ZoneName <Zone> -RRType PTR
Forwarder Get-DnsServerForwarder
Rekursion Get-DnsServerRecursion
Cacheeinstellungen Get-DnsServerCache
Serverstatistiken Get-DnsServerStatistics
Leistungsindikatoren Get-Counter -ListSet DNS
DoH-Serverkonfiguration Get-DnsServerEncryptionProtocol
Clientregistrierung Register-DnsClient
AD-DNS-Test dcdiag /test:DNS /v
AD-Replikation repadmin /replsummary

Ändernde Befehle, die nicht als erste Diagnose verwendet werden dürfen:

Clear-DnsClientCache
Clear-DnsServerCache
Register-DnsClient
ipconfig /flushdns
ipconfig /registerdns
Add-DnsServerPrimaryZone
Add-DnsServerResourceRecordPtr
Set-DnsServerForwarder
Set-DnsServerRecursion
Set-DnsServerCache
Set-DnsServerZoneAging
Start-DnsServerScavenging
Set-DnsServerEncryptionProtocol
Remove-DnsServerResourceRecord

7.11.48 Quellen

Offizielle Microsoft-Dokumentation

Standards

Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.

7. Schnelle Entscheidungsbäume

7.12 Systematischer DNS-Diagnoseablauf

Kurz erklärt

DNS-Störungen dürfen nicht durch wahlloses Leeren von Caches, Ändern von DNS-Servern oder Neuerstellen von Einträgen diagnostiziert werden.

Der sichere Ablauf beginnt beim exakten Fehlerbild und verfolgt die Namensauflösung schrittweise vom Client über den verwendeten Resolver, den Transportweg und rekursive DNS-Server bis zum autoritativen Server und den tatsächlichen Zonendaten.

7.12.1 Ziel des Diagnoseablaufs

Der Diagnoseablauf soll eindeutig bestimmen:

DNS-Diagnose bedeutet nicht nur, irgendeine erfolgreiche Antwort zu erhalten. Die Antwort muss vom vorgesehenen DNS-Pfad stammen, fachlich korrekt sein und innerhalb einer angemessenen Zeit eintreffen.

7.12.2 Grundregeln

  1. Zuerst beobachten und dokumentieren.
  2. Den exakten Namen und Datensatztyp verwenden.
  3. Clientverhalten und direkte DNS-Abfrage unterscheiden.
  4. Den tatsächlich verwendeten DNS-Server bestimmen.
  5. Antwortcode und Antwortinhalt getrennt bewerten.
  6. Positive, negative und ausgebliebene Antworten unterscheiden.
  7. Cache-, rekursive und autoritative Antworten trennen.
  8. UDP, TCP, DoH und DoT nicht gleichsetzen.
  9. Pro Versuch nur eine relevante Variable verändern.
  10. Vor jeder Änderung Risiko und Rückweg dokumentieren.
  11. Nach der Maßnahme denselben Test wiederholen.
  12. Erst nach technischer Verifikation den Vorgang abschließen.

Folgende Maßnahmen sind keine geeigneten ersten Diagnoseschritte:

7.12.3 Fehleraufnahme

Vor dem ersten Test sind mindestens folgende Angaben zu erfassen:

Angabe Beispiel
Zeitpunkt 2026-08-02 14:35:20
Client client25.example.test
Benutzer beziehungsweise Dienst betroffene Sitzung oder Dienstkonto
Anwendung Browser, RDP, Mail, Dateifreigabe, AD-Anmeldung
eingegebener Name app.example.test
erwarteter FQDN app.example.test.
erwarteter Datensatztyp A, AAAA, CNAME, PTR, SRV, MX oder TXT
erwartetes Ergebnis vorgesehene IP-Adresse oder Zielname
tatsächliches Ergebnis Fehlertext oder falsche Antwort
verwendetes Netzwerk LAN, WLAN, VPN oder Mobilfunk
Quell-IP-Adresse aktive Clientadresse
konfigurierte DNS-Server Reihenfolge und Schnittstelle
Fehlerumfang einzelner Client, Standort, Zone oder alle Systeme
letzte Änderung DNS, DHCP, VPN, Firewall, Server, Zertifikat oder Netzwerk

Kennwörter, Zugangsdaten und unnötige personenbezogene Daten dürfen nicht in die Fehlerdokumentation übernommen werden.

7.12.4 Störung einordnen

Fehlerklasse Typisches Symptom
vollständiger Ausfall keine DNS-Abfrage funktioniert
namensbezogener Fehler nur ein bestimmter Name schlägt fehl
zonenbezogener Fehler alle Namen einer Zone schlagen fehl
datensatzbezogener Fehler A funktioniert, SRV oder PTR jedoch nicht
resolverbezogener Fehler nur ein bestimmter DNS-Server liefert Fehler
clientbezogener Fehler derselbe Name funktioniert an anderen Clients
anwendungsbezogener Fehler direkte DNS-Abfrage funktioniert, Anwendung nicht
standortbezogener Fehler Fehler tritt nur in einem Netz oder VPN auf
zeitabhängiger Fehler Fehler tritt nur zeitweise auf
leistungsbezogener Fehler Antwort ist korrekt, aber zu langsam
datenbezogener Fehler DNS liefert eine falsche oder veraltete Antwort
transportbezogener Fehler UDP, TCP, DoH oder DoT verhalten sich unterschiedlich
validierungsbezogener Fehler DNSSEC führt zu SERVFAIL oder Validierungsfehler
reversebezogener Fehler IP-Adresse lässt sich nicht korrekt in einen Namen auflösen

Diese Einordnung bestimmt, welche Vergleichstests aussagekräftig sind.

7.12.5 Geeignete Testdaten festlegen

Für reproduzierbare Tests müssen folgende Werte feststehen:

Ein kurzer Name wie:

server01

ist für eine eindeutige DNS-Diagnose ungeeignet, solange nicht feststeht, welches DNS-Suffix ergänzt wird.

Besser:

server01.example.test.

Der abschließende Punkt kennzeichnet einen vollständig qualifizierten absoluten DNS-Namen. Viele Werkzeuge funktionieren auch ohne diesen Punkt, können dann jedoch abhängig von Suchsuffixen zusätzliche Namen prüfen.

7.12.6 DNS-Auflösung als Kette betrachten

Eine Namensauflösung kann folgende Stationen durchlaufen:

Station Aufgabe
Anwendung fordert eine Namensauflösung an oder verwendet eigenen Resolver
lokale Namensquelle Hosts-Datei oder anwendungseigener Cache
Betriebssystemresolver wertet Cache, Suffixe, Richtlinien und DNS-Server aus
lokaler Stub-Resolver nimmt Anfragen lokal entgegen und leitet sie weiter
VPN-, Container- oder Sicherheitsresolver beeinflusst den Abfrageweg
rekursiver DNS-Server beschafft die vollständige Antwort für den Client
Forwarder übernimmt weitergeleitete Anfragen
DNS-Hierarchie verweist schrittweise auf zuständige Server
autoritativer DNS-Server liefert die maßgeblichen Zonendaten
Cache auf dem Rückweg speichert positive oder negative Antworten

Die Diagnose folgt dieser Kette vom Client in Richtung autoritativer Datenquelle.

7.12.7 Umfang der Störung bestimmen

Kontrollierte Vergleiche:

Vergleich Aussage
gleicher Name, anderer Client clientbezogenen Fehler prüfen
gleicher Client, anderer Name namens- oder zonenbezogenen Fehler prüfen
gleicher Name, anderer DNS-Server resolverbezogenen Fehler prüfen
gleiche Abfrage, direkt gegen autoritativen Server Rekursion und Autorität trennen
gleiche Abfrage mit und ohne VPN VPN-, NRPT- oder Split-DNS-Fehler prüfen
gleiche Abfrage über UDP und TCP Transportfehler prüfen
direkte DNS-Abfrage und Anwendung DNS- und Anwendungsfehler trennen
Vorwärts- und Rückwärtsauflösung A/AAAA und PTR getrennt prüfen
erste und wiederholte Abfrage Cachewirkung prüfen
interner und externer Name interne Zone und Rekursion trennen

Erst nach diesen Vergleichen sollte eine konkrete Ursache angenommen werden.

7.12.8 Clientidentität und Netzwerkzustand prüfen

Windows

Get-NetIPConfiguration

ipconfig /all

Linux

ip address

ip route

macOS

ifconfig

route -n get default

Zu prüfen sind:

Eine vorhandene IP-Adresse beweist nicht, dass der vorgesehene DNS-Server erreichbar ist.

7.12.9 DNS-Server und Resolverkonfiguration ermitteln

Windows

Get-DnsClientServerAddress

Get-DnsClient

Linux

cat /etc/resolv.conf

Bei systemd-resolved:

resolvectl status

macOS

scutil --dns

Zu prüfen sind:

/etc/resolv.conf kann lediglich auf einen lokalen Stub-Resolver verweisen. In diesem Fall müssen die tatsächlichen Upstream-DNS-Server über den zuständigen Resolverdienst ermittelt werden.

7.12.10 Interne Clients und öffentliche DNS-Server

Domänenmitglieder und interne Clients müssen für interne Namensräume die vorgesehenen internen DNS-Server verwenden.

Das Eintragen eines öffentlichen DNS-Servers wie eines Resolverdienstes im Internet kann:

Ein öffentlicher DNS-Server darf deshalb nicht als pauschale Reparatur für einen internen DNS-Fehler eingetragen werden.

7.12.11 Hosts-Datei und lokale Namensquellen prüfen

Hosts-Dateien:

Betriebssystem Pfad
Windows C:\Windows\System32\drivers\etc\hosts
Linux /etc/hosts
macOS /etc/hosts

Zu prüfen sind:

Eine direkte Abfrage mit ausdrücklich angegebenem DNS-Server kann erfolgreich sein, während eine Anwendung wegen eines falschen lokalen Eintrags eine andere Adresse verwendet.

7.12.12 Kurznamen und DNS-Suffixe prüfen

Wenn ein Benutzer nur folgenden Namen verwendet:

server01

kann der Resolver abhängig von seiner Suchliste nacheinander verschiedene Namen bilden:

server01.example.test
server01.branch.example.test
server01.other.example.test

Windows-Konfiguration prüfen:

Get-DnsClient

Linux mit systemd-resolved:

resolvectl status

macOS:

scutil --dns

Mögliche Fehler:

Für die technische Diagnose sollte zuerst der vollständige FQDN verwendet werden.

7.12.13 Tatsächlichen Windows-Resolverpfad bestimmen

Unter Windows können NRPT, VPN-Richtlinien und verschlüsseltes DNS den Abfrageweg verändern.

Wirksame NRPT-Richtlinien:

Get-DnsClientNrptPolicy

Konfigurierte NRPT-Regeln:

Get-DnsClientNrptRule

DNS-Clientzustand:

netsh dnsclient show state

Globale verschlüsselte DNS-Einstellungen:

netsh dnsclient show global

Konfigurierte DoH- oder DoT-Endpunkte:

netsh dnsclient show encryption

Wichtig:

Deshalb müssen Systemauflösung und direkte Serverabfrage getrennt getestet werden.

7.12.14 Anwendung und DNS voneinander abgrenzen

Folgende Ergebnisse sind getrennt zu prüfen:

  1. Kann die Ziel-IP-Adresse direkt erreicht werden?
  2. Liefert eine direkte DNS-Abfrage die erwartete Adresse?
  3. Liefert der normale Betriebssystemresolver dieselbe Adresse?
  4. Verwendet die Anwendung dieselbe Adresse?
  5. Ist der eigentliche Dienst auf der Zieladresse erreichbar?

Beispiel:

Resolve-DnsName "app.example.test"

Direkte Abfrage gegen einen bestimmten DNS-Server:

Resolve-DnsName `
  -Name "app.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

Wenn DNS die richtige IP-Adresse liefert, die Anwendung aber weiterhin fehlschlägt, müssen unter anderem Anwendungscache, Proxy, TLS-Zertifikat, Dienstport und Anwendungsrichtlinien geprüft werden.

Ein erfolgreicher DNS-Test beweist nicht, dass der Zielservice funktioniert.

7.12.15 Direkte DNS-Abfragen durchführen

Windows PowerShell

Resolve-DnsName `
  -Name "app.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

Windows Eingabeaufforderung

nslookup app.example.test 192.0.2.53

Linux und macOS

dig @192.0.2.53 app.example.test A

Bei jedem Test sind zu dokumentieren:

7.12.16 Datensatztypen gezielt prüfen

Aufgabe Datensatz
IPv4-Adresse ermitteln A
IPv6-Adresse ermitteln AAAA
Alias verfolgen CNAME
Mailserver ermitteln MX
Dienst und Port ermitteln SRV
IP-Adresse rückwärts auflösen PTR
Zonenautorität prüfen SOA
autoritative Server ermitteln NS
Richtlinien- oder Verifikationstext prüfen TXT
DNSSEC-Schlüssel prüfen DNSKEY
Delegationssignatur prüfen DS

Beispiele:

Resolve-DnsName "app.example.test" -Type A

Resolve-DnsName "alias.example.test" -Type CNAME

Resolve-DnsName "_service._tcp.example.test" -Type SRV

Resolve-DnsName "example.test" -Type SOA

Resolve-DnsName "example.test" -Type NS

Bei CNAME, MX und SRV muss zusätzlich geprüft werden, ob der zurückgegebene Zielname über A oder AAAA auflösbar ist.

7.12.17 DNS-Antwortcodes auswerten

Ergebnis Bedeutung Nächster Schritt
NOERROR mit Antwort Abfrage erfolgreich Inhalt, TTL und Quelle prüfen
NOERROR ohne gesuchten Datensatz Name kann existieren, Datensatztyp fehlt anderen Datensatztyp und SOA prüfen
NXDOMAIN abgefragter Name existiert laut Antwort nicht Name, Zone, Autorität und negativen Cache prüfen
SERVFAIL Server konnte keine verwertbare Antwort erzeugen Delegation, DNSSEC, Forwarder und Serverprotokolle prüfen
REFUSED Server verweigert die Abfrage ACL, Rekursion, Richtlinie und Quellnetz prüfen
FORMERR DNS-Nachricht wurde als fehlerhaft bewertet Client, Server und Netzwerkgerät prüfen
NOTIMP angeforderte Funktion wird nicht unterstützt Abfragefunktion und Serverfähigkeit prüfen
Timeout keine verwertbare Antwort innerhalb der Wartezeit Netzwerk, Transport und Serververfügbarkeit prüfen
TC gesetzt UDP-Antwort wurde abgeschnitten erneuten Versuch über TCP prüfen

Wichtige Unterscheidungen:

7.12.18 Antwortflags berücksichtigen

Typische DNS-Flags:

Flag Bedeutung
AA Antwort ist für die beantwortete Zone autoritativ
RD Client hat Rekursion angefordert
RA Server bietet Rekursion an
TC Antwort wurde abgeschnitten
AD Resolver kennzeichnet Daten als DNSSEC-validiert
CD Client fordert an, Validierungsfehler nicht als Sperre zu verwenden

Ein gesetztes AD-Flag muss im Zusammenhang mit dem verwendeten validierenden Resolver bewertet werden. Das bloße Anfordern von DNSSEC-Daten beweist keine erfolgreiche Validierung.

7.12.19 Antwortzeit messen

Windows

Measure-Command {
    Resolve-DnsName `
      -Name "app.example.test" `
      -Type A `
      -Server "192.0.2.53" `
      -DnsOnly
}

Linux und macOS

dig @192.0.2.53 app.example.test A +stats

Zu vergleichen sind:

Measure-Command enthält auch den PowerShell-Befehlsaufwand. Es eignet sich deshalb vor allem für Vergleiche unter denselben Bedingungen.

7.12.20 Cachezustand prüfen

Windows-Clientcache

Get-DnsClientCache

Alternativ:

ipconfig /displaydns

Linux mit systemd-resolved

resolvectl statistics

Windows-DNS-Servercacheeinstellungen

Get-DnsServerCache

Get-DnsServerCache zeigt Cacheeinstellungen des Windows-DNS-Servers und nicht einfach eine vollständige Liste aller zwischengespeicherten Antworten.

Zu prüfen sind:

Cachelöschung verändert Beweisdaten und darf erst nach der Dokumentation als kontrollierter Vergleich erfolgen.

7.12.21 Positive und negative Zwischenspeicherung unterscheiden

Positive Antworten können A-, AAAA-, CNAME-, PTR- oder andere Datensätze zwischenspeichern.

Negative Zwischenspeicherung kann unter anderem betreffen:

Mögliche Folge:

  1. Ein Name wird abgefragt und liefert NXDOMAIN.
  2. Der fehlende Datensatz wird anschließend angelegt.
  3. Der Client oder rekursive Resolver liefert zunächst weiterhin die gespeicherte negative Antwort.
  4. Erst nach Ablauf oder kontrollierter Löschung des Cacheeintrags wird der neue Datensatz sichtbar.

Deshalb müssen SOA-Daten, negative TTL und alle beteiligten Cacheebenen berücksichtigt werden.

7.12.22 DNS-Server vergleichen

Eine identische Abfrage muss gezielt an jeden vorgesehenen DNS-Server gesendet werden.

Windows

Resolve-DnsName `
  -Name "app.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

Resolve-DnsName `
  -Name "app.example.test" `
  -Type A `
  -Server "192.0.2.54" `
  -DnsOnly

Linux und macOS

dig @192.0.2.53 app.example.test A

dig @192.0.2.54 app.example.test A

Zu vergleichen sind:

Unterschiedliche Antworten können auf Cache-, Zonen-, Replikations-, Zonentransfer- oder Konfigurationsprobleme hinweisen.

7.12.23 UDP und TCP prüfen

Klassische DNS-Abfragen verwenden häufig UDP-Port 53. TCP-Port 53 wird unter anderem benötigt:

TCP-Erreichbarkeit unter Windows:

Test-NetConnection "192.0.2.53" -Port 53

Dieser Befehl prüft nur TCP.

Normale DNS-Abfrage:

Resolve-DnsName `
  -Name "app.example.test" `
  -Server "192.0.2.53" `
  -DnsOnly

TCP erzwingen:

Resolve-DnsName `
  -Name "app.example.test" `
  -Server "192.0.2.53" `
  -DnsOnly `
  -TcpOnly

Mit dig:

dig @192.0.2.53 app.example.test A

dig @192.0.2.53 app.example.test A +tcp

Wenn UDP fehlschlägt und TCP funktioniert, sind Firewall, Paketverlust, EDNS, MTU und Fragmentierung zu prüfen.

7.12.24 EDNS, MTU und Fragmentierung prüfen

Hinweise auf ein Größen- oder Transportproblem:

Vergleich:

dig @192.0.2.53 example.com A +dnssec

dig @192.0.2.53 example.com A +dnssec +tcp

Test ohne EDNS:

dig @192.0.2.53 example.com A +noedns

Das testweise Unterdrücken von EDNS dient nur der Eingrenzung. EDNS darf nicht dauerhaft deaktiviert werden, um einen fehlerhaften Netzwerkpfad zu verdecken.

7.12.25 Verschlüsseltes DNS prüfen

DNS over HTTPS und DNS over TLS verändern den Transportweg.

Zu prüfen sind:

Windows-Zustand:

netsh dnsclient show state

netsh dnsclient show encryption

Bei verschlüsseltem DNS kann eine klassische Paketaufzeichnung den DNS-Inhalt nicht ohne zusätzliche, autorisierte Entschlüsselungsinformationen anzeigen.

Ein erfolgreicher Test gegen UDP- oder TCP-Port 53 beweist nicht, dass ein DoH- oder DoT-Endpunkt funktioniert.

7.12.26 Rekursiven und autoritativen DNS-Server unterscheiden

Ein rekursiver DNS-Server beschafft die Antwort im Auftrag des Clients.

Ein autoritativer DNS-Server verwaltet die maßgeblichen Daten einer Zone.

Diagnosevergleich:

  1. Client fragt vorgesehenen rekursiven DNS-Server.
  2. Rekursiver Server liefert Fehler oder langsame Antwort.
  3. Autoritativer DNS-Server wird direkt abgefragt.
  4. Ergebnisse werden verglichen.

Wenn der autoritative Server korrekt und schnell antwortet, liegt die Ursache wahrscheinlich bei:

Wenn bereits der autoritative Server falsche Daten liefert, sind Zone, Datensatz, Delegation und Replikation zu prüfen.

7.12.27 SOA-, NS- und Delegationsdaten prüfen

SOA prüfen:

Resolve-DnsName `
  -Name "example.test" `
  -Type SOA `
  -Server "192.0.2.53" `
  -DnsOnly

NS prüfen:

Resolve-DnsName `
  -Name "example.test" `
  -Type NS `
  -Server "192.0.2.53" `
  -DnsOnly

Mit dig:

dig @192.0.2.53 example.test SOA

dig @192.0.2.53 example.test NS

Öffentliche Delegationskette verfolgen:

dig app.example.test A +trace

Zu prüfen sind:

dig +trace folgt der öffentlichen DNS-Hierarchie. Interne Split-DNS-Zonen, bedingte Forwarder und private Namensräume müssen über den internen DNS-Pfad geprüft werden.

7.12.28 Forwarder, bedingte Forwarder und Rekursion prüfen

Auf einem Windows-DNS-Server:

Get-DnsServerForwarder

Get-DnsServerRecursion

Get-DnsServerRootHint

Zonen und bedingte Weiterleitungen:

Get-DnsServerZone

Zu prüfen sind:

Ein nicht erreichbarer erster Forwarder kann Verzögerungen verursachen, bevor ein weiterer Auflösungspfad verwendet wird.

7.12.29 Reverse-Lookups prüfen

Windows

Resolve-DnsName `
  -Name "192.0.2.25" `
  -Type PTR `
  -Server "192.0.2.53" `
  -DnsOnly

Linux und macOS

dig @192.0.2.53 -x 192.0.2.25

Danach muss der PTR-Zielname wieder vorwärts geprüft werden:

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

Zu prüfen sind:

Ein fehlender PTR-Eintrag beweist keinen vollständigen DNS-Ausfall.

7.12.30 DNSSEC systematisch abgrenzen

DNSSEC-Daten anfordern:

Resolve-DnsName `
  -Name "example.com" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly `
  -DnssecOk

Mit dig:

dig @192.0.2.53 example.com A +dnssec

Zu prüfen sind:

-DnssecOk und +dnssec fordern DNSSEC-bezogene Daten an. Diese Optionen beweisen allein keine erfolgreiche Validierung.

nslookup ist nicht für eine vollständige DNSSEC-Diagnose geeignet.

7.12.31 Windows-DNS-Serverzustand prüfen

Dienststatus:

Get-Service -Name DNS

Zonen:

Get-DnsServerZone

Bestimmte Zone:

Get-DnsServerZone `
  -Name "example.test"

Datensätze:

Get-DnsServerResourceRecord `
  -ZoneName "example.test"

Serverstatistiken:

Get-DnsServerStatistics

Verfügbare Leistungsindikatoren:

Get-Counter -ListSet DNS

Zu prüfen sind:

Ein laufender DNS-Dienst beweist nicht, dass eine bestimmte Zone korrekt geladen oder repliziert wurde.

7.12.32 Active-Directory-DNS prüfen

LDAP-SRV-Einträge:

Resolve-DnsName `
  -Name "_ldap._tcp.dc._msdcs.<AD-DNS-Domäne>" `
  -Type SRV

Kerberos-SRV-Einträge:

Resolve-DnsName `
  -Name "_kerberos._tcp.<AD-DNS-Domäne>" `
  -Type SRV

DNS-Test eines Domänencontrollers:

dcdiag /test:DNS /v /s:<DC-Name>

Replikationsübersicht:

repadmin /replsummary

Replikationsdetails:

repadmin /showrepl

Zu prüfen sind:

Eine manuelle Neuerstellung von SRV-Einträgen ist keine erste Maßnahme. Zuerst müssen Registrierung, Netlogon, Zone, Berechtigungen und Replikation geprüft werden.

7.12.33 Dynamische Updates und DHCP prüfen

Vor einer erneuten Registrierung sind vorhandene Datensätze, Zeitstempel und Ereignisse zu dokumentieren.

Verändernde Clientregistrierung:

Register-DnsClient

Alternativ:

ipconfig /registerdns

Zu prüfen sind:

Das wiederholte Registrieren behebt keine fehlende Zone, falsche Berechtigung oder fehlerhafte DHCP-DNS-Konfiguration.

7.12.34 Aging und Scavenging prüfen

Zu prüfen sind:

Scavenging beinhaltet Löschvorgänge und darf nicht spontan aktiviert oder erzwungen werden, um einzelne veraltete Einträge zu beseitigen.

7.12.35 Ereignisse und Protokolle auswerten

Vorhandene DNS-Protokolle unter Windows anzeigen:

Get-WinEvent -ListLog "*DNS*"

Mögliche Bereiche:

Zu korrelieren sind:

Analytische DNS-Protokollierung muss gezielt und zeitlich begrenzt aktiviert werden. Sie kann bei hohen Abfrageraten die Leistung beeinflussen und enthält schützenswerte interne Namensinformationen.

7.12.36 Netzwerkaufzeichnung gezielt einsetzen

Eine Netzwerkaufzeichnung ist sinnvoll, wenn unklar bleibt:

Bei DoH und DoT ist der DNS-Inhalt verschlüsselt. Sichtbar bleiben unter anderem Zieladresse, Port, TLS-Verbindung und Zeitverhalten, nicht jedoch ohne Weiteres der eigentliche DNS-Nachrichteninhalt.

Aufzeichnungen müssen auf die betroffenen Systeme, Namen und Zeiträume begrenzt sowie geschützt gespeichert werden.

7.12.37 Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Der erste konfigurierte DNS-Forwarder ist nicht erreichbar und verursacht die Verzögerung.

Erwarteter Befund:
Direkte Abfragen gegen den ersten Forwarder laufen in einen Timeout.
Direkte Abfragen gegen den zweiten Forwarder funktionieren sofort.

Gegenbeweis:
Der erste Forwarder antwortet unter denselben Bedingungen schnell und korrekt.

Eine belastbare Hypothese enthält:

Erst danach sollte eine Änderung vorgenommen werden.

7.12.38 Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko
DNS-Serveradresse korrigieren falscher Resolver nachgewiesen andere Namensräume können beeinflusst werden
Suffix oder NRPT-Regel korrigieren falscher Abfrageweg nachgewiesen VPN- und Split-DNS-Verhalten ändert sich
DNS-Datensatz korrigieren autoritative Daten sind nachweislich falsch Anwendungen können auf neues Ziel wechseln
PTR-Eintrag korrigieren falscher Reverse-Eintrag bestätigt Protokoll- oder Sicherheitszuordnung ändert sich
Forwarder korrigieren nicht erreichbarer oder falscher Forwarder bestätigt externe oder interne Rekursion betroffen
Delegation korrigieren falsche NS- oder Glue-Daten bestätigt gesamte Zone kann betroffen sein
dynamische Updates korrigieren Updatefehler und Berechtigung nachgewiesen viele Clients können Einträge verändern
Cache kontrolliert löschen falscher Cacheeintrag dokumentiert Beweisdaten gehen verloren
DNSSEC-Konfiguration korrigieren Validierungsfehler nachgewiesen Vertrauenskette und Sicherheit betroffen
Aging oder Scavenging anpassen Fehlkonfiguration nachgewiesen gültige Datensätze können gelöscht werden
Replikationsfehler beheben AD-Replikationsfehler bestätigt mehrere Verzeichnisdaten betroffen

Vor der Maßnahme sind zu dokumentieren:

7.12.39 Vollständiger Diagnoseablauf

  1. Exakte Fehlermeldung aufnehmen
    Wortlaut, Anwendung, Benutzer, Client und Uhrzeit dokumentieren.

  2. Betroffenen Namen bestimmen
    Kurzname, FQDN oder IP-Adresse unterscheiden.

  3. Erwarteten Datensatztyp bestimmen
    A, AAAA, CNAME, PTR, SRV, MX, TXT, NS oder SOA festlegen.

  4. Erwartetes Ergebnis dokumentieren
    Vorgesehene IP-Adresse, Zielname oder Dienstinformation festhalten.

  5. Umfang bestimmen
    Einzelnen Client, Standort, DNS-Server, Namen, Zone oder alle Systeme unterscheiden.

  6. Anwendung und DNS abgrenzen
    Direkte IP-Verbindung, Systemresolver und Anwendung getrennt prüfen.

  7. Netzwerkzustand erfassen
    Schnittstelle, Adresse, Gateway, VPN und Routing dokumentieren.

  8. Konfigurierte DNS-Server erfassen
    DNS-Server pro Schnittstelle und Reihenfolge bestimmen.

  9. Suffixe und lokale Namensquellen prüfen
    Suchliste, Hosts-Datei und Anwendungscache berücksichtigen.

  10. Resolverrichtlinien prüfen
    NRPT, Split-DNS, Container-DNS und Sicherheitsresolver berücksichtigen.

  11. Verschlüsselten DNS-Pfad bestimmen
    Klassisches DNS, DoH und DoT unterscheiden.

  12. Normale Systemauflösung testen
    Prüfen, welches Ergebnis die Anwendung grundsätzlich erhalten kann.

  13. Direkte Abfrage durchführen
    Vorgesehenen DNS-Server und Datensatztyp ausdrücklich angeben.

  14. Antwortcode auswerten
    NOERROR, NXDOMAIN, SERVFAIL, REFUSED oder Timeout unterscheiden.

  15. Antwortinhalt auswerten
    Wert, TTL, CNAME-Kette und Flags prüfen.

  16. Antwortzeit messen
    Erste und wiederholte Abfrage vergleichen.

  17. Alternativen DNS-Server prüfen
    Unterschiede zwischen vorgesehenen Resolvern dokumentieren.

  18. Cachezustand prüfen
    Positive und negative Einträge auf allen relevanten Ebenen berücksichtigen.

  19. UDP und TCP vergleichen
    Transportabhängige Fehler bestimmen.

  20. EDNS, MTU und Fragmentierung prüfen
    Besonders bei großen Antworten oder VPN-Verbindungen.

  21. Rekursiven und autoritativen Server unterscheiden
    Abfrageweg in einzelne Ebenen zerlegen.

  22. SOA, NS und Delegation prüfen
    Zuständigkeit und Zonengrenze bestätigen.

  23. Autoritative Server direkt vergleichen
    Datensatz, TTL, Seriennummer und Antwortcode auswerten.

  24. Forwarder und Rekursion prüfen
    Erreichbarkeit, Richtlinien und Timeoutpfad untersuchen.

  25. DNSSEC prüfen
    Signaturen, DS, DNSKEY, Trust Anchor und Validierungsfehler berücksichtigen.

  26. Reverse-Lookup prüfen
    PTR, Reverse-Zone, Delegation und Vorwärtskonsistenz auswerten.

  27. DNS-Serverzustand prüfen
    Dienst, Zonen, Statistiken, Last und Ereignisse untersuchen.

  28. AD-DNS und Replikation prüfen
    Wenn AD-integrierte Zonen oder SRV-Einträge beteiligt sind.

  29. Dynamische Updates und DHCP prüfen
    Registrierung, Eigentümer, Berechtigungen und Leasezustand auswerten.

  30. Aging und Scavenging prüfen
    Bei veralteten oder unerwartet fehlenden Einträgen.

  31. Protokolle korrelieren
    Client, DNS-Server, DHCP und Anwendung auf denselben Versuch begrenzen.

  32. Bei Bedarf Netzwerkaufzeichnung durchführen
    Nur zeitlich und technisch begrenzt.

  33. Hypothese und Gegenbeweis formulieren
    Ursache vor der Änderung messbar beschreiben.

  34. Eine kontrollierte Maßnahme ausführen
    Risiko, Rückweg und Erfolgskriterium beachten.

  35. Identischen Test wiederholen
    Antwortcode, Wert und Zeit mit dem Ausgangszustand vergleichen.

  36. Alternativen Pfad erneut prüfen
    Weitere Clients, Resolver oder autoritative Server kontrollieren.

  37. Anwendung verifizieren
    Nicht nur das Diagnosewerkzeug testen.

  38. Temporäre Änderungen zurücknehmen
    Logging, Testregeln und Ausnahmen entfernen.

  39. Ursache dokumentieren
    Technischen Nachweis und betroffenen Pfad festhalten.

  40. Prävention festlegen
    Monitoring, Standardisierung oder Konfigurationsverbesserung umsetzen.

7.12.40 Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
IP-Verbindung funktioniert, Name nicht DNS oder lokaler Resolverpfad direkte A-/AAAA-Abfrage
direkter DNS-Test funktioniert, Anwendung nicht Anwendungscache, Proxy oder eigener Resolver Anwendungsresolver und Zieladresse prüfen
nur Kurzname schlägt fehl Suffix- oder Suchlistenproblem FQDN und Suffixkonfiguration vergleichen
nur ein Client betroffen lokale Konfiguration, Cache oder Hosts-Datei anderen Client und direkte Serverabfrage vergleichen
nur ein DNS-Server betroffen Zone, Cache, Dienst oder Replikation DNS-Server direkt vergleichen
ganze Zone liefert NXDOMAIN falscher Resolver oder fehlende Delegation SOA, NS und autoritative Server prüfen
NOERROR, aber keine A-Antwort Name vorhanden, Datensatztyp fehlt CNAME, AAAA und SOA prüfen
SERVFAIL Rekursion, DNSSEC oder Serverfehler autoritative Abfrage und Protokolle
REFUSED Richtlinie, ACL oder deaktivierte Rekursion Serverkonfiguration und Quellnetz prüfen
Timeout fehlende Antwort Transport, Netzwerk und Serverlast prüfen
UDP schlägt fehl, TCP funktioniert Firewall, MTU, Fragmentierung oder EDNS Netzwerkaufzeichnung und große Antwort prüfen
erste Abfrage langsam, zweite schnell Cacheeffekt kalte und warme Abfrage vergleichen
externe Namen langsam Forwarder oder Rekursion Forwarder direkt prüfen
interne Namen langsam interne Delegation, Forwarder oder AD-DNS interne autoritative Server prüfen
mit VPN falsche Antwort NRPT oder Split-DNS Resolver vor und nach VPN vergleichen
Browser und System liefern verschiedene Antworten Browser-DoH oder Anwendungscache Browserresolver und Systemresolver vergleichen
PTR fehlt, A funktioniert Reverse-Zone oder PTR fehlt Reverse-Delegation prüfen
unterschiedliche Antworten je DC AD-Replikation repadmin und direkte DNS-Abfragen
nur große Antworten scheitern EDNS-, MTU- oder Fragmentierungsproblem UDP/TCP-Vergleich
nur signierte Zonen scheitern DNSSEC-Validierungsfehler DS-, DNSKEY- und EDE-Auswertung
neuer Datensatz bleibt unsichtbar positiver oder negativer Cache TTL und Cacheebenen prüfen
SRV vorhanden, Dienst nicht erreichbar Zielhost, Port oder Dienst fehlerhaft SRV-Ziel und Dienstport prüfen

7.12.41 Typische Diagnosefehler

7.12.42 Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Eine einzelne erfolgreiche Cacheabfrage ist keine ausreichende Verifikation.

7.12.43 Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Zeitpunkt:
<Datum und Uhrzeit>

Betroffener Client:
<Hostname und IP-Adresse>

Betroffene Anwendung:
<Anwendung oder Dienst>

Abfragename:
<FQDN oder IP-Adresse>

Datensatztyp:
<A, AAAA, CNAME, PTR, SRV, MX, TXT, NS oder SOA>

Erwartetes Ergebnis:
<Sollwert>

Tatsächliches Ergebnis:
<Istwert, Antwortcode und Antwortzeit>

Verwendeter Resolver:
<DNS-Server und Schnittstelle>

Resolverpfad:
<klassisches DNS, NRPT, VPN, DoH, DoT oder Anwendungsresolver>

Vergleichstests:
<anderer Client, DNS-Server, Transport oder autoritativer Server>

Nachgewiesene Ursache:
<technischer Befund>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

Durchgeführte Maßnahme:
<genau eine kontrollierte Änderung>

Risiko und Rückweg:
<Beschreibung>

Verifikation:
<identischer Test, Anwendungstest und weitere Systeme>

Präventionsmaßnahme:
<Monitoring, Standardisierung oder Konfigurationsänderung>

7.12.44 Checkliste

7.12.45 Schnellreferenz

Aufgabe Befehl
Windows-Netzwerkkonfiguration Get-NetIPConfiguration
vollständige Windows-IP-Konfiguration ipconfig /all
Windows-DNS-Serveradressen Get-DnsClientServerAddress
Windows-DNS-Clientkonfiguration Get-DnsClient
Linux-Resolverzustand resolvectl status
macOS-Resolverzustand scutil --dns
wirksame NRPT-Richtlinie Get-DnsClientNrptPolicy
konfigurierte NRPT-Regeln Get-DnsClientNrptRule
verschlüsselter DNS-Clientzustand netsh dnsclient show state
verschlüsselte DNS-Endpunkte netsh dnsclient show encryption
Systemauflösung unter Windows Resolve-DnsName <Name>
direkte A-Abfrage Resolve-DnsName <Name> -Type A -Server <DNS-IP> -DnsOnly
direkte AAAA-Abfrage Resolve-DnsName <Name> -Type AAAA -Server <DNS-IP> -DnsOnly
CNAME prüfen Resolve-DnsName <Name> -Type CNAME -Server <DNS-IP> -DnsOnly
SRV prüfen Resolve-DnsName <SRV-Name> -Type SRV -Server <DNS-IP> -DnsOnly
PTR prüfen Resolve-DnsName <IP> -Type PTR -Server <DNS-IP> -DnsOnly
SOA prüfen Resolve-DnsName <Zone> -Type SOA -Server <DNS-IP> -DnsOnly
NS prüfen Resolve-DnsName <Zone> -Type NS -Server <DNS-IP> -DnsOnly
direkte Abfrage mit dig dig @<DNS-IP> <Name> <Typ>
Reverse-Abfrage mit dig dig @<DNS-IP> -x <IP>
öffentliche Delegation verfolgen dig <Name> <Typ> +trace
TCP-DNS unter Windows Resolve-DnsName <Name> -Server <DNS-IP> -DnsOnly -TcpOnly
TCP-DNS mit dig dig @<DNS-IP> <Name> <Typ> +tcp
DNSSEC-Daten anfordern dig @<DNS-IP> <Name> <Typ> +dnssec
Windows-Clientcache Get-DnsClientCache
Windows-DNS-Dienst Get-Service DNS
Windows-DNS-Zonen Get-DnsServerZone
Windows-DNS-Datensätze Get-DnsServerResourceRecord -ZoneName <Zone>
Windows-DNS-Forwarder Get-DnsServerForwarder
Windows-DNS-Rekursion Get-DnsServerRecursion
Windows-DNS-Statistiken Get-DnsServerStatistics
DNS-Leistungsindikatoren Get-Counter -ListSet DNS
vorhandene Windows-DNS-Protokolle Get-WinEvent -ListLog "*DNS*"
AD-DNS-Test dcdiag /test:DNS /v /s:<DC-Name>
AD-Replikationsübersicht repadmin /replsummary
AD-Replikationsdetails repadmin /showrepl

Ändernde Befehle, die nicht als erste Diagnose verwendet werden dürfen:

Clear-DnsClientCache
Clear-DnsServerCache
Register-DnsClient
ipconfig /flushdns
ipconfig /registerdns
Set-DnsClientServerAddress
Set-DnsServerForwarder
Set-DnsServerRecursion
Set-DnsServerCache
Set-DnsServerZoneAging
Start-DnsServerScavenging
Add-DnsServerPrimaryZone
Add-DnsServerResourceRecord
Remove-DnsServerResourceRecord
Restart-Service DNS

7.12.46 Quellen

Offizielle Microsoft-Dokumentation

Offizielle Projektdokumentation

Standards

Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.

7. Schnelle Entscheidungsbäume

7.13 Datenträger oder Dateisystem ist voll

7.13.1 Ziel dieser Seite

Diese Seite beschreibt die systematische Diagnose, wenn ein System, Datenträger, Volume, Dateisystem, Speicherpool, Container oder eine Anwendung keinen weiteren Speicherplatz verwenden kann.

Ziele der Diagnose:

Ein gemeldetes „Dateisystem voll“ bedeutet nicht zwangsläufig, dass die physische Festplatte vollständig belegt ist.

7.13.2 Sicherheitskennzeichnungen

Kennzeichnung Bedeutung
LESEND erfasst ausschließlich Zustände und Messwerte
LASTERZEUGEND kann CPU, Arbeitsspeicher oder Datenträger-I/O deutlich belasten
ÄNDERND verändert Konfigurationen oder Systemzustände
LÖSCHEND entfernt Daten und kann Informationen unwiederbringlich zerstören
AUSFALLRISIKO kann Dienste, Dateisysteme oder ganze Systeme unterbrechen

Grundregeln:

7.13.3 Mögliche Fehlerklassen

Fehlerklasse Beschreibung Typischer Nachweis
Datenblöcke voll nutzbare Speicherkapazität ist erschöpft df, Get-Volume, diskutil info
Inodes erschöpft zu viele Dateien, obwohl noch Datenblöcke frei sind df -i
Benutzer- oder Gruppenquota erreicht einzelner Benutzer oder Dienst darf nichts mehr speichern quota, FSRM, Dateisystemquota
Projekt- oder Verzeichnisquota erreicht bestimmter Pfad besitzt ein eigenes Limit XFS-Projektquota, FSRM
Anwendungsquota erreicht Anwendung begrenzt Speicher unabhängig vom Dateisystem Anwendungskonfiguration und Protokolle
Snapshot-Speicher voll Snapshots oder Shadow Copies belegen den freien Bereich VSS-, APFS-, Btrfs- oder ZFS-Auswertung
Thin Pool voll zugrunde liegender Thin-Provisioning-Pool besitzt keinen freien Platz LVM-, SAN- oder Hypervisoranzeige
Thin-Pool-Metadaten voll Verwaltungsbereich des Thin Pools ist erschöpft lvs mit metadata_percent
Container-Layer voll beschreibbare Container-Schicht oder Containerhost ist voll Docker- oder Runtime-Auswertung
Kubernetes-Ephemeralspeicher voll Node oder Pod überschreitet Ephemeral-Storage-Grenzen DiskPressure, Eviction-Ereignisse
Dateisystem schreibgeschützt Dateisystem wurde wegen Fehlern nur lesbar eingebunden Mountoptionen, Kernel- und Systemprotokolle
Physischer Datenträgerfehler Schreibvorgänge scheitern durch Hardware- oder I/O-Fehler SMART, Ereignisse, Kernelmeldungen
Gelöschte Datei noch geöffnet Verzeichniseintrag ist gelöscht, Prozess hält Datei weiterhin geöffnet lsof +L1
Reservierter Speicher freier Bereich steht normalen Benutzern nicht zur Verfügung Dateisystem- und Reservierungsdaten
Versteckte Daten unter Mountpoint Dateien liegen unterhalb eines später darüber eingebundenen Dateisystems Mountstruktur und Wartungsprüfung
Kapazität des Backends voll lokaler Client zeigt nur einen vorgelagerten NAS-, SAN- oder Cloudspeicher Backend-, Pool- und Quotaauswertung

7.13.4 Typische Symptome und Fehlermeldungen

Mögliche Symptome:

Typische Meldungen:

No space left on device
ENOSPC
Disk full
There is not enough space on the disk
Not enough disk space
Quota exceeded
EDQUOT
Read-only file system
EROFS
I/O error
DiskPressure
Evicted
ephemeral-storage
Thin pool is full
Metadata space exhausted

No space left on device kann sowohl auf erschöpfte Datenblöcke als auch auf erschöpfte Inodes oder interne Dateisystemreserven hinweisen.

Quota exceeded betrifft dagegen gewöhnlich ein festgelegtes Speicherlimit und nicht zwingend das gesamte Dateisystem.

7.13.5 Sofortmaßnahmen ohne unkontrolliertes Löschen

  1. Exakte Fehlermeldung und Uhrzeit erfassen.
  2. Betroffenen Host, Dienst, Benutzer, Container und Pfad bestimmen.
  3. Kritikalität und Auswirkung bewerten.
  4. Aktuelle Kapazität, Inodes, Quotas und Speicherpools dokumentieren.
  5. Schreibintensive Prozesse und aktuelle Wachstumsrate identifizieren.
  6. Bei akutem Wachstum eine kontrollierte Drosselung oder Beendigung des verursachenden Dienstes prüfen.
  7. Keine unnötigen Neustarts durchführen.
  8. Keine Protokolle, Datenbanken oder Container-Volumes spontan löschen.
  9. Nur eindeutig entbehrliche und freigegebene Daten kontrolliert entfernen.
  10. Nach jeder Maßnahme denselben Speichertest wiederholen.

Ein Neustart kann die Situation verschärfen, wenn ein Dienst beim Start temporären Speicher benötigt oder eine Datenbank wegen fehlenden Speicherplatzes keine Wiederherstellung durchführen kann.

7.13.6 Speicherpfad vollständig abbilden

Der sichtbare Pfad kann mehrere Speicherebenen durchlaufen:

Anwendung
→ Anwendungspfad
→ Container oder virtuelle Maschine
→ Mountpoint oder Laufwerksbuchstabe
→ Dateisystem
→ Partition oder logisches Volume
→ Thin Pool, RAID oder Storage Pool
→ physischer Datenträger, NAS oder SAN

Jede Ebene kann ein eigenes Limit besitzen.

Beispiel:

Anwendung schreibt nach /var/lib/app
→ Docker-Bind-Mount
→ /srv/containers/app
→ ext4-Dateisystem
→ LVM Logical Volume
→ LVM Thin Pool
→ RAID-Verbund
→ physische SSDs

Freier Speicher auf einer Ebene beweist nicht, dass alle anderen Ebenen ebenfalls freien Speicher besitzen.

7.13.7 Grundfragen der Diagnose

Zu klären sind:

7.13.8 Windows – Volumeauslastung erfassen

LESEND

Get-Volume |
  Select-Object `
    DriveLetter,
    FileSystemLabel,
    FileSystem,
    HealthStatus,
    OperationalStatus,
    @{
      Name = "SizeGiB"
      Expression = {
        [math]::Round($_.Size / 1GB, 2)
      }
    },
    @{
      Name = "FreeGiB"
      Expression = {
        [math]::Round($_.SizeRemaining / 1GB, 2)
      }
    },
    @{
      Name = "FreePercent"
      Expression = {
        if ($_.Size -gt 0) {
          [math]::Round(
            100 * $_.SizeRemaining / $_.Size,
            1
          )
        }
      }
    }

Dateisystemlaufwerke der aktuellen PowerShell-Sitzung:

Get-PSDrive `
  -PSProvider FileSystem

Lokale logische Laufwerke:

Get-CimInstance `
  -ClassName Win32_LogicalDisk `
  -Filter "DriveType=3" |
  Select-Object `
    DeviceID,
    VolumeName,
    FileSystem,
    Size,
    FreeSpace

Get-PSDrive kann auch eingebundene Dateisystemlaufwerke anzeigen. Bei Netzwerkfreigaben können Quotas oder serverseitige Einschränkungen dazu führen, dass die gemeldete Verfügbarkeit nicht der gesamten Backendkapazität entspricht.

7.13.9 Windows – Datenträger, Partition und Volume zuordnen

LESEND

Get-Disk |
  Select-Object `
    Number,
    FriendlyName,
    PartitionStyle,
    OperationalStatus,
    HealthStatus,
    Size

Get-Partition |
  Select-Object `
    DiskNumber,
    PartitionNumber,
    DriveLetter,
    Type,
    Size

Get-Partition |
  Get-Volume |
  Select-Object `
    DriveLetter,
    FileSystemLabel,
    FileSystem,
    Size,
    SizeRemaining

Von Speicherverwaltungsanbietern gemeldete physische Datenträger:

Get-PhysicalDisk |
  Select-Object `
    FriendlyName,
    MediaType,
    OperationalStatus,
    HealthStatus,
    Size

Zu beachten:

7.13.10 Windows – große Verzeichnisse und Dateien eingrenzen

Eine rekursive Suche kann auf großen Dateisystemen erhebliche I/O-Last verursachen. Der Suchpfad muss deshalb möglichst eng begrenzt werden.

LESEND, LASTERZEUGEND

Größe der direkten Unterverzeichnisse eines bekannten Pfades:

$ScanRoot = "C:\Data"

Get-ChildItem `
  -LiteralPath $ScanRoot `
  -Directory `
  -Force `
  -ErrorAction SilentlyContinue |
ForEach-Object {
  $Measurement = Get-ChildItem `
    -LiteralPath $_.FullName `
    -File `
    -Force `
    -Recurse `
    -ErrorAction SilentlyContinue |
  Measure-Object `
    -Property Length `
    -Sum

  [pscustomobject]@{
    Path = $_.FullName
    SizeGiB = [math]::Round(
      $Measurement.Sum / 1GB,
      2
    )
  }
} |
Sort-Object `
  -Property SizeGiB `
  -Descending

Größte Dateien unter einem begrenzten Pfad:

Get-ChildItem `
  -LiteralPath "C:\Data" `
  -File `
  -Force `
  -Recurse `
  -ErrorAction SilentlyContinue |
Sort-Object `
  -Property Length `
  -Descending |
Select-Object `
  -First 20 `
  FullName,
  Length,
  LastWriteTime

Einschränkungen:

7.13.11 Windows – versteckte und reservierte Speicherverbraucher prüfen

VSS und Shadow Copies

LESEND

vssadmin list shadowstorage

vssadmin list shadows

Zu prüfen sind:

Shadow Copies dürfen nicht spontan gelöscht oder verkleinert werden. Sie können für Wiederherstellungen, offene Backups oder andere Dienste benötigt werden.

Windows-Komponentenspeicher analysieren

LESEND, LASTERZEUGEND

Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore

Die im Explorer angezeigte Größe von WinSxS darf nicht durch manuelles Löschen von Dateien korrigiert werden. Hardlinks können die scheinbare Verzeichnisgröße beeinflussen.

Systemdateien und weitere Bereiche

Zu prüfen sind:

Diese Dateien dürfen nicht allein aufgrund ihrer Größe entfernt werden.

7.13.12 Windows – Quotas prüfen

NTFS-Quota

LESEND, administrative Berechtigung erforderlich

fsutil quota query C:

File Server Resource Manager

Get-FsrmQuota |
  Select-Object `
    Path,
    Size,
    Usage,
    SoftLimit,
    Status,
    Template

Das FSRM-Modul ist nur vorhanden, wenn die entsprechende Windows-Server-Rolle beziehungsweise Verwaltungsfunktion installiert ist.

Zu unterscheiden sind:

Wenn nur ein Benutzer oder ein bestimmtes Verzeichnis betroffen ist, muss zuerst die wirksame Quota geprüft werden.

7.13.13 Windows – Storageereignisse auswerten

LESEND

Get-WinEvent `
  -FilterHashtable @{
    LogName = "System"
    StartTime = (Get-Date).AddHours(-6)
  } |
Where-Object {
  $_.ProviderName -in @(
    "disk",
    "Ntfs",
    "ReFS",
    "volsnap",
    "storport"
  )
} |
Select-Object `
  TimeCreated,
  ProviderName,
  Id,
  LevelDisplayName,
  Message

Zu korrelieren sind:

Ein Volume kann gleichzeitig nahezu voll und technisch fehlerhaft sein. Die Freigabe von Speicher behebt dann nicht zwangsläufig die eigentliche Ursache.

7.13.14 Linux – Dateisystembelegung erfassen

LESEND

df -hT

Wichtige Felder:

Feld Bedeutung
Filesystem zugrunde liegendes Gerät oder logischer Speicher
Type Dateisystemtyp
Size Gesamtkapazität
Used belegter Speicher
Avail verfügbarer Speicher
Use% prozentuale Auslastung
Mounted on Mountpoint

Bestimmten Pfad prüfen:

df -hT /var/lib/app

Exakte Blockwerte:

df -B1 /var/lib/app

df wertet das Dateisystem aus, in dem der angegebene Pfad liegt. Das ist zuverlässiger, als den Mountpoint nur anhand einer angenommenen Verzeichnisstruktur zu erraten.

7.13.15 Linux – Inodes prüfen

LESEND

df -i

Bestimmten Pfad prüfen:

df -i /var/lib/app

Eine mögliche Einordnung:

Blockbelegung Inodebelegung Einordnung
hoch normal große Dateien oder große Datenmengen
normal hoch sehr viele kleine Dateien
hoch hoch Kombination aus Datenmenge und Dateianzahl
normal normal Quota, Reservierung, anderer Mountpoint oder anderer Fehler

Bei erschöpften Inodes können keine neuen Dateien angelegt werden, obwohl noch Datenblöcke frei sind.

Typische Verursacher:

7.13.16 Linux – Mounts und Speichergeräte zuordnen

LESEND

findmnt

Gezielte Ausgabe:

findmnt \
  -o TARGET,SOURCE,FSTYPE,OPTIONS

Bestimmten Pfad zuordnen:

findmnt \
  --target /var/lib/app

Blockgeräte:

lsblk \
  -o NAME,TYPE,FSTYPE,SIZE,FSAVAIL,FSUSE%,MOUNTPOINTS

Zu prüfen sind:

Wenn ein vorgesehenes Dateisystem nicht eingebunden ist, kann eine Anwendung unbemerkt in das darunterliegende Root-Dateisystem schreiben.

7.13.17 Linux – große Verzeichnisse und Dateien finden

Die Suche sollte auf das betroffene Dateisystem begrenzt werden.

LESEND, LASTERZEUGEND

Direkte Unterverzeichnisse:

du \
  -x \
  -h \
  --max-depth=1 \
  /var |
sort -h

Zusammenfassung eines bestimmten Pfades:

du \
  -x \
  -s \
  -h \
  /var/lib/app

Größte Dateien mit GNU find:

find \
  /var/lib/app \
  -xdev \
  -type f \
  -printf '%s\t%p\n' |
sort -nr |
head -n 20

Wichtige Optionen:

Option Bedeutung
-x bei du bleibt im selben Dateisystem
-xdev bei find überschreitet keine Dateisystemgrenze
--max-depth=1 wertet nur die direkte Verzeichnisebene aus
-type f beschränkt die Suche auf reguläre Dateien

Die Option -printf ist eine GNU-find-Funktion und steht nicht auf jedem Unix-System zur Verfügung.

7.13.18 Unterschied zwischen df und du untersuchen

df und du messen unterschiedliche Dinge:

Wenn df eine hohe Belegung zeigt, du aber deutlich weniger Daten findet, sind insbesondere zu prüfen:

Sparse Files vergleichen:

du -h /pfad/datei

du \
  -h \
  --apparent-size \
  /pfad/datei

Die scheinbare Dateigröße kann größer als der tatsächlich belegte Speicher sein.

7.13.19 Gelöschte, aber weiterhin geöffnete Dateien prüfen

Unter Unix-ähnlichen Systemen wird der belegte Speicher einer gelöschten Datei erst freigegeben, wenn kein Prozess mehr einen offenen Dateideskriptor auf sie hält.

LESEND

sudo lsof +L1

Zu prüfen sind:

Ein Neustart des gesamten Systems ist nicht die erste Maßnahme. Wenn die Ursache bestätigt ist, sollte der betroffene Dienst kontrolliert neu geladen oder neu gestartet werden. Dabei sind Auswirkung und Wiederanlaufbedingungen zu prüfen.

7.13.20 Linux – Journald und Protokollwachstum prüfen

Aktuelle Journalbelegung:

LESEND

journalctl --disk-usage

Journaldateien und Protokollverzeichnisse:

du \
  -x \
  -h \
  --max-depth=1 \
  /var/log |
sort -h

Logrotate-Konfiguration im Debugmodus prüfen:

sudo logrotate \
  -d \
  /etc/logrotate.conf

logrotate -d führt keine Rotation aus, zeigt aber die geplante Verarbeitung.

Zu prüfen sind:

Das Löschen eines Protokolls behebt nicht den Prozess, der es unkontrolliert erzeugt.

7.13.21 Linux – Benutzer-, Gruppen- und Projektquotas prüfen

Quota des aktuellen Benutzers:

LESEND

quota -s

Quotaübersicht vorhandener quota-fähiger Dateisysteme:

sudo repquota -a

XFS-Quotaauswertung:

sudo xfs_quota \
  -x \
  -c 'report -h' \
  /mountpoint

Zu unterscheiden sind:

Eine noch laufende Grace Period kann erklären, warum Schreiben zunächst möglich war und später ohne sichtbare Änderung der Gesamtkapazität fehlschlägt.

7.13.22 LVM und Thin Provisioning prüfen

LESEND

sudo pvs

sudo vgs

sudo lvs \
  -a \
  -o lv_name,vg_name,lv_size,pool_lv,origin,data_percent,metadata_percent

Besonders kritisch sind:

Ein Thin Pool kann voll sein, obwohl ein Gastbetriebssystem oder Logical Volume scheinbar noch freien logischen Speicher anzeigt.

Das Erweitern eines Speichers muss in der richtigen Reihenfolge erfolgen:

Backend oder physischer Datenträger
→ Partition oder PV
→ Volume Group oder Pool
→ Logical Volume
→ Dateisystem
→ Anwendung

Nicht jede Ebene ist in jeder Architektur vorhanden.

7.13.23 Btrfs und ZFS prüfen

Btrfs

LESEND

sudo btrfs filesystem usage -T /mountpoint

sudo btrfs subvolume list /mountpoint

Zu prüfen sind:

Bei Btrfs können Daten- und Metadatenbereiche unterschiedlich ausgelastet sein. Eine einfache df-Ausgabe reicht deshalb nicht immer für die vollständige Einordnung.

ZFS

zpool list

zfs list -o space

Snapshots:

zfs list \
  -t snapshot \
  -o name,used,refer,creation

Zu prüfen sind:

Snapshots und Copy-on-Write-Daten können Speicher belegen, obwohl aktuelle Dateien bereits gelöscht wurden.

7.13.24 macOS – Speicherzustand prüfen

LESEND

df -h

Bestimmten Pfad prüfen:

df -h /System/Volumes/Data

Datenträger und Partitionen:

diskutil list

Informationen zum Startvolume:

diskutil info /

APFS-Struktur:

diskutil apfs list

APFS-Snapshots:

diskutil apfs listSnapshots /

Lokale Time-Machine-Snapshots:

tmutil listlocalsnapshots /

Große Verzeichnisse unterhalb des Datenvolumes:

LESEND, LASTERZEUGEND

sudo du \
  -x \
  -h \
  -d 1 \
  /System/Volumes/Data \
  2>/dev/null |
sort -h

Gelöschte, noch geöffnete Dateien:

sudo lsof +L1

Bei APFS teilen sich mehrere Volumes den freien Speicher eines gemeinsamen Containers. Daher müssen Volume, Container, Quotas, Reservierungen und Snapshots gemeinsam betrachtet werden.

Die macOS-Anzeige „verfügbar“ kann zusätzlich löschbaren Speicher enthalten. Dieser ist nicht mit unmittelbar freiem Speicher in jeder konkreten Betriebssituation gleichzusetzen.

7.13.25 Docker – Speicherverbrauch prüfen

Docker-Root-Verzeichnis:

LESEND

docker info \
  --format '{{.DockerRootDir}}'

Docker-Speicherübersicht:

docker system df

Detaillierte Übersicht:

docker system df -v

Containergrößen:

docker ps \
  -a \
  --size

Volumes:

docker volume ls

Logpfade der Container:

docker ps -aq |
xargs -r docker inspect \
  --format '{{.Name}} {{.LogPath}}'

Mounts eines bestimmten Containers:

docker inspect \
  --format '{{json .Mounts}}' \
  <Containername>

Zu prüfen sind:

Nicht zulässig als spontane Diagnosemaßnahme:

docker system prune -a --volumes

Dieser Befehl kann gestoppte Container, ungenutzte Images, Netzwerke, Build-Cache und anonyme Volumes entfernen. Vor einer Bereinigung müssen alle betroffenen Objekte einzeln geprüft werden.

Das manuelle Löschen innerhalb von /var/lib/docker kann die Docker-Metadaten und Containerdaten beschädigen.

7.13.26 Kubernetes – Ephemeral Storage und DiskPressure prüfen

Nodezustand:

LESEND

kubectl get nodes

Bestimmten Node untersuchen:

kubectl describe node <Node>

Zu prüfen sind insbesondere:

DiskPressure
NodeHasDiskPressure
ephemeral-storage
imagefs.available
imagefs.inodesFree
nodefs.available
nodefs.inodesFree

Ereignisse:

kubectl get events \
  --all-namespaces \
  --sort-by=.metadata.creationTimestamp

Betroffenen Pod untersuchen:

kubectl describe pod \
  <Pod> \
  -n <Namespace>

Persistente Volumes:

kubectl get pvc \
  --all-namespaces

Die angezeigte PVC-Kapazität ist nicht automatisch der aktuell freie Speicher innerhalb des eingebundenen Dateisystems.

Lokaler Ephemeral Storage kann unter anderem umfassen:

Bei Node-Druck kann der Kubelet Pods beenden, um Ressourcen zurückzugewinnen. Das Löschen einzelner Pods behebt die Ursache nicht, wenn Logs, Images oder Anwendungen sofort erneut denselben Speicherverbrauch erzeugen.

7.13.27 Anwendungen und Dienste als Verursacher prüfen

Häufige Speicherverbraucher:

Bereich Mögliche Ursache
Protokolle fehlende Rotation, Debugmodus, Fehlerschleife
Datenbank Transaktionslog, WAL, Temp-Bereich, Replikationsverzug
Backup fehlende Retention, doppelte Sicherungen, abgebrochene Jobs
Container unbeschränkte Logs, alte Images, beschreibbare Layer
Monitoring hochauflösende Metriken, zu lange Aufbewahrung
Mail Queue, Anhänge, Quarantäne
Druck blockierte Spooldateien
Anwendung Cache, Sitzungen, Uploads, Exporte
Betriebssystem Updates, Dumps, temporäre Dateien
Entwicklung Build-Artefakte, Paketcache, Testdaten
Virtualisierung Snapshots, virtuelle Festplatten, Replikation
Dateidienst Benutzerdateien, Papierkorb, Versionierung
Security EDR-Quarantäne, Scanprotokolle, Forensikdaten

Zu prüfen sind:

7.13.28 Netzwerkfreigaben, NAS und SAN prüfen

Bei SMB, NFS, iSCSI, Fibre Channel oder Cloudspeicher müssen Client und Backend getrennt geprüft werden.

Zu erfassen sind:

Mögliche Sonderfälle:

Herstellerspezifische Lösch-, Snapshot- und Poolbefehle dürfen erst nach Prüfung der jeweiligen Dokumentation verwendet werden.

7.13.29 Schreibgeschütztes Dateisystem und Hardwarefehler abgrenzen

Linux-Mountstatus:

LESEND

findmnt \
  -o TARGET,SOURCE,FSTYPE,OPTIONS

Aktuelle Kernelmeldungen:

sudo dmesg \
  --ctime |
grep -Ei \
  'error|i/o|filesystem|read-only|corrupt|nvme|ata|scsi|ext4|xfs|btrfs'

Systemprotokolle:

journalctl \
  -k \
  --since "-2 hours"

Falls smartctl installiert und für das Gerät geeignet ist:

sudo smartctl \
  -a \
  /dev/<Gerät>

macOS-Verifikation:

diskutil verifyVolume /

Ein Dateisystem kann wegen erkannter Fehler auf read-only wechseln. In diesem Fall ist das Löschen von Dateien weder möglich noch die richtige Erstmaßnahme.

Offline-Dateisystemprüfungen wie fsck dürfen nicht ungeprüft auf einem produktiv eingebundenen Dateisystem ausgeführt werden.

Wenn ein Datenträger einen bevorstehenden Ausfall meldet, haben Datensicherung, kontrollierte Außerbetriebnahme und Austausch Vorrang vor einer reinen Speicherbereinigung.

7.13.30 Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Das Root-Dateisystem ist voll, weil ein Dienst ein
Protokoll ohne funktionierende Rotation erzeugt.

Erwarteter Befund:
df zeigt eine hohe Blockbelegung.
Das Protokollverzeichnis enthält eine stark gewachsene Datei.
Die Änderungszeit und die Dienstmeldungen passen zum Fehlerzeitpunkt.

Gegenbeweis:
Das Protokoll ist klein oder wächst nicht.
Die Belegung bleibt auch nach kontrolliertem Stoppen
des Dienstes unverändert.

Testmethode:
Dateisystembelegung, Verzeichnisgröße, Änderungszeit,
offene Dateien und Dienstprotokolle vergleichen.

Erfolgskriterium:
Der verursachende Schreibpfad ist eindeutig nachgewiesen.

Eine belastbare Hypothese enthält:

7.13.31 Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko
unnötige temporäre Daten entfernen Eigentümer und Entbehrlichkeit bestätigt benötigte Sitzungs- oder Arbeitsdaten können verloren gehen
Protokollrotation korrigieren Logwachstum nachgewiesen laufender Dienst kann Logdatei weiter offen halten
Journald begrenzen Journal als Ursache bestätigt ältere Diagnoseinformationen gehen verloren
Anwendungscache bereinigen Cache ist dokumentiert wiederherstellbar Lastspitze beim Neuaufbau
Backupretention korrigieren abgelaufene Sicherungen eindeutig bestimmt Wiederherstellungspunkte gehen verloren
Containerobjekte bereinigen jedes Objekt auf Nutzung geprüft Daten oder Rollbackimages können fehlen
Quota anpassen Quota als Ursache und Kapazität vorhanden unkontrolliertes weiteres Wachstum
Volume erweitern Backendkapazität und korrekte Ebenen bestätigt Partitions- oder Dateisystemschaden bei Fehlern
Thin Pool erweitern Poolgrenze nachgewiesen falsche Erweiterungsebene bleibt wirkungslos
Snapshot entfernen Abhängigkeiten und Retention geprüft Wiederherstellungspunkt geht verloren
Dienst kontrolliert neu starten gelöschte offene Datei nachgewiesen Dienstunterbrechung
fehlerhaften Schreibprozess stoppen akutes Wachstum bestätigt Anwendungs- oder Datenverlust
Storage austauschen Hardwarefehler bestätigt Betriebsunterbrechung und Migrationsrisiko

Vor der Maßnahme sind zu dokumentieren:

7.13.32 Beispiele für verändernde Bereinigungen

Die folgenden Befehle sind keine Erstdiagnose und dürfen nur nach Prüfung und Freigabe verwendet werden.

Systemd-Journal kontrolliert begrenzen

LÖSCHEND

sudo journalctl \
  --rotate \
  --vacuum-size=<Zielgröße>

Dabei werden archivierte Journaldateien bis zur angegebenen Zielgröße bereinigt. Relevante Protokolle müssen vorher ausgewertet oder gesichert werden.

Windows-Komponentenspeicher bereinigen

ÄNDERND

Dism.exe /Online /Cleanup-Image /StartComponentCleanup

Dieser Befehl darf nur nach der vorherigen Analyse mit /AnalyzeComponentStore und unter Berücksichtigung laufender Wartungs- oder Updatevorgänge verwendet werden.

Docker-Bereinigung

Vor jedem Prune-Befehl müssen mindestens folgende Ausgaben geprüft werden:

docker system df -v

docker ps -a

docker image ls

docker volume ls

Prune-Befehle sind löschend. Insbesondere --volumes darf nicht verwendet werden, ohne jedes betroffene Volume und dessen Datenverantwortung geprüft zu haben.

7.13.33 Maßnahmen, die nicht spontan ausgeführt werden dürfen

rm -rf auf unbekannten Verzeichnissen
Löschen unter /var/lib/docker
docker system prune -a --volumes
Löschen aktiver Datenbankdateien
Löschen von WAL- oder Transaktionslogs
Löschen aller Snapshots
vssadmin delete shadows
unkontrolliertes Verkleinern des VSS-Speichers
manuelles Löschen aus WinSxS
Leeren produktiver Protokolle ohne Sicherung
fsck auf einem schreibend eingebundenen Dateisystem
Ändern reservierter ext4-Blöcke ohne Kapazitätsplanung
Vergrößern einer Partition ohne Backup und Ebenenprüfung
Entfernen von Kubernetes-PVCs
Löschen unbekannter Container-Volumes
Deaktivieren von Quotas ohne Ursachenanalyse
Neustart des gesamten Hosts als erste Maßnahme

Eine Datei mit der Endung .log, .tmp, .bak oder .old ist nicht automatisch entbehrlich.

7.13.34 Vollständiger Diagnoseablauf

  1. Fehlermeldung vollständig aufnehmen
    Wortlaut, Anwendung, Benutzer und Zeitpunkt dokumentieren.

  2. Betroffenen Pfad bestimmen
    Exakten Datei-, Volume-, Mount- oder Containerpfad erfassen.

  3. Auswirkung bestimmen
    Einzelne Anwendung, Benutzer, Host oder Standort unterscheiden.

  4. Schreibtest nicht unkontrolliert wiederholen
    Zusätzliche Schreibvorgänge können die Lage verschärfen.

  5. Speicherebene bestimmen
    Anwendung, Container, Dateisystem, Volume, Pool und Backend zuordnen.

  6. Gesamtkapazität und freien Speicher erfassen
    Werte in Prozent und absoluten Größen dokumentieren.

  7. Inodes prüfen
    Besonders bei vielen kleinen Dateien.

  8. Quotas prüfen
    Benutzer-, Gruppen-, Projekt-, Verzeichnis- und Anwendungsquotas unterscheiden.

  9. Schreibschutz prüfen
    Read-only-Mount oder Dateisystemfehler ausschließen.

  10. Speicherpool prüfen
    RAID, LVM, Thin Pool, Storage Spaces, NAS oder SAN berücksichtigen.

  11. Snapshots prüfen
    VSS, APFS, Btrfs, ZFS, Hypervisor und Storage-Snapshots erfassen.

  12. Wachstumsrate bestimmen
    Aktuelle Werte mit Monitoring oder früheren Messungen vergleichen.

  13. Große Verzeichnisse eingrenzen
    Suche auf das betroffene Dateisystem beschränken.

  14. Große Dateien bestimmen
    Besitzer, Zweck und Änderungszeit dokumentieren.

  15. Viele kleine Dateien berücksichtigen
    Inodeverbrauch und Dateianzahl untersuchen.

  16. Gelöschte offene Dateien prüfen
    Besonders nach manueller Loglöschung.

  17. Protokolle und Rotation prüfen
    Fehlerschleifen, Debugmodus und Retention untersuchen.

  18. Datenbanken prüfen
    Daten-, Transaktions-, WAL- und Temp-Bereiche unterscheiden.

  19. Backupdaten prüfen
    Retention, abgebrochene Jobs und doppelte Sicherungen untersuchen.

  20. Containerdaten prüfen
    Images, Layer, Volumes, Bind-Mounts und Logs unterscheiden.

  21. Kubernetes-Ephemeralspeicher prüfen
    Nodefs, Imagefs, Inodes, Limits und Evictions auswerten.

  22. Betriebssystembereiche prüfen
    Updates, Dumps, Cache, temporäre Dateien und Papierkorb untersuchen.

  23. Hardware- und I/O-Fehler prüfen
    Ereignisse, Kernelmeldungen und Storagezustand korrelieren.

  24. Hypothese und Gegenbeweis formulieren
    Ursache vor jeder Änderung messbar beschreiben.

  25. Akutes Wachstum kontrollieren
    Verursachenden Schreibprozess nur mit Freigabe drosseln oder stoppen.

  26. Minimale sichere Entlastung planen
    Nur bestätigte, entbehrliche Daten auswählen.

  27. Eine Maßnahme durchführen
    Nicht mehrere Variablen gleichzeitig verändern.

  28. Freien Speicher erneut messen
    Absoluten Wert und Prozentwert dokumentieren.

  29. Ursprünglichen Schreibvorgang testen
    Anwendung und nicht nur Diagnosewerkzeug prüfen.

  30. Weitere Ebenen verifizieren
    Pool, Volume, Dateisystem und Anwendung erneut kontrollieren.

  31. Wachstum weiter beobachten
    Prüfen, ob der Speicher sofort wieder abnimmt.

  32. Dauerhafte Ursache beheben
    Rotation, Retention, Quota, Kapazität oder Anwendung korrigieren.

  33. Monitoring verbessern
    Prozentwert, freien Absolutwert, Inodes und Wachstumsrate überwachen.

  34. Vorgang dokumentieren
    Ursache, Maßnahme, Risiko, Ergebnis und Prävention festhalten.

7.13.35 Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
df zeigt 100 %, du ebenfalls sehr hoch sichtbare Dateien belegen das Dateisystem größte Verzeichnisse bestimmen
df zeigt 100 %, du deutlich weniger offene gelöschte Dateien, Snapshots oder Metadaten lsof +L1 und Snapshotprüfung
Blöcke frei, Inodes 100 % zu viele Dateien Verzeichnisse mit vielen kleinen Dateien bestimmen
nur ein Benutzer betroffen Benutzerquota Quota des Benutzers prüfen
nur ein Verzeichnis betroffen FSRM-, Projekt- oder Anwendungsquota wirksames Verzeichnislimit prüfen
Dateisystem ist read-only Dateisystem- oder Storagefehler Kernel- und Ereignisprotokolle
Root-Dateisystem voll Logs, Cache, Container oder fehlender Mount /var, /tmp, Docker und Mounts prüfen
nach Loglöschung keine Freigabe Datei wird noch geöffnet gehalten lsof +L1
Dockerhost voll Images, Layer, Volumes oder Logs docker system df -v
Container meldet voll, Host nicht Container-Layer, Volume oder Quota Mounts und beschreibbaren Layer prüfen
Kubernetes-Node zeigt DiskPressure Nodefs, Imagefs oder Inodes knapp Nodebeschreibung und Ereignisse
PVC vorhanden, Anwendung meldet voll Dateisystem innerhalb des PVC oder Storagequota Volume im Pod und Backend prüfen
Logical Volume hat Platz, Thin Pool ist voll Thin Provisioning erschöpft lvs mit Daten- und Metadatenprozent
Dateien wurden gelöscht, Snapshotgröße steigt Copy-on-Write hält alte Blöcke Snapshotbelegung prüfen
Windows-Volume voll, Verzeichnissumme kleiner VSS, Systemdateien oder unzugängliche Bereiche VSS und Systembereiche prüfen
macOS zeigt widersprüchliche Werte APFS-Container, Snapshots oder löschbarer Speicher APFS-Container und Snapshots prüfen
NAS-Freigabe voll, NAS-Pool hat Platz Share-, Benutzer- oder Volumequota Backendquota prüfen
Speicher wächst sehr schnell Fehlerschleife oder unkontrollierter Job Änderungszeit und aktive Prozesse
nach Bereinigung sofort wieder voll Ursache weiterhin aktiv Wachstumsquelle erneut messen
I/O-Fehler zusätzlich zu wenig Speicher Hardware- oder Pfadfehler Storagezustand und Ereignisse

7.13.36 Typische Diagnosefehler

7.13.37 Verifikation

Nach der Maßnahme müssen mindestens folgende Punkte geprüft werden:

Ein einzelner erfolgreicher Schreibtest reicht nicht aus, wenn der Speicher weiterhin unkontrolliert wächst.

7.13.38 Prävention und Monitoring

Zu überwachen sind:

Ein sinnvoller Alarm berücksichtigt nicht nur einen festen Prozentwert.

Beispiel:

Warnung:
Auslastung über organisationsspezifischem Grenzwert
UND weniger als definierter absoluter Freispeicher

Kritisch:
Kapazität reicht bei aktueller Wachstumsrate
nicht bis zum nächsten geplanten Eingriff

Zusätzliche Präventionsmaßnahmen:

7.13.39 Dokumentationsvorlage

Störung:
<exakte Fehlermeldung>

Zeitpunkt:
<Datum und Uhrzeit>

Betroffenes System:
<Hostname, VM, Container oder Node>

Betroffene Anwendung:
<Dienst oder Anwendung>

Betroffener Pfad:
<Laufwerksbuchstabe, Mountpoint oder Dateipfad>

Speicherebenen:
<Anwendung, Dateisystem, Volume, Pool und Backend>

Dateisystem:
<Typ und Mountoptionen>

Gesamtkapazität:
<Wert>

Freier Speicher vor der Maßnahme:
<Wert und Prozent>

Inodebelegung:
<Wert und Prozent>

Wirksame Quota:
<Typ, Limit und Nutzung>

Snapshotbelegung:
<Wert und Bestand>

Thin-Pool-Auslastung:
<Daten- und Metadatenprozent>

Wachstumsrate:
<Wert pro Stunde oder Tag>

Größte Verbraucher:
<Pfade, Größen und Besitzer>

Gelöschte offene Dateien:
<Befund>

Storage- und Hardwarezustand:
<Befund>

Nachgewiesene Ursache:
<technischer Nachweis>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

Durchgeführte Maßnahme:
<genau beschriebene Änderung>

Risiko und Rückweg:
<Beschreibung>

Freier Speicher nach der Maßnahme:
<Wert und Prozent>

Verifikation:
<Schreibtest, Anwendungstest und Monitoring>

Prävention:
<Rotation, Retention, Quota, Kapazität oder Monitoring>

7.13.40 Checkliste

7.13.41 Schnellreferenz

Aufgabe Befehl
Windows-Volumes Get-Volume
PowerShell-Dateisystemlaufwerke Get-PSDrive -PSProvider FileSystem
Windows-Datenträger Get-Disk
Windows-Partitionen Get-Partition
physische Windows-Speicherobjekte Get-PhysicalDisk
NTFS-Quota fsutil quota query C:
FSRM-Quotas Get-FsrmQuota
VSS-Speicher vssadmin list shadowstorage
Shadow Copies vssadmin list shadows
Windows-Komponentenspeicher Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore
Linux-Dateisystembelegung df -hT
Linux-Pfad prüfen df -hT <Pfad>
Linux-Inodes df -i
Mounts findmnt
Mount eines Pfades findmnt --target <Pfad>
Blockgeräte lsblk -o NAME,TYPE,FSTYPE,SIZE,FSAVAIL,FSUSE%,MOUNTPOINTS
Verzeichnisgrößen du -x -h --max-depth=1 <Pfad>
gelöschte offene Dateien lsof +L1
Journalbelegung journalctl --disk-usage
Benutzerquota quota -s
Quotaübersicht repquota -a
XFS-Quota xfs_quota -x -c 'report -h' <Mountpoint>
LVM Physical Volumes pvs
LVM Volume Groups vgs
LVM und Thin Pools lvs -a -o lv_name,vg_name,lv_size,pool_lv,origin,data_percent,metadata_percent
Btrfs-Auslastung btrfs filesystem usage -T <Mountpoint>
ZFS-Poolauslastung zpool list
ZFS-Datasetbelegung zfs list -o space
macOS-Dateisystembelegung df -h
macOS-Datenträger diskutil list
APFS-Struktur diskutil apfs list
APFS-Snapshots diskutil apfs listSnapshots /
lokale Time-Machine-Snapshots tmutil listlocalsnapshots /
Docker-Speicherübersicht docker system df -v
Docker-Containergrößen docker ps -a --size
Kubernetes-Nodes kubectl get nodes
Kubernetes-Nodezustand kubectl describe node <Node>
Kubernetes-PVCs kubectl get pvc --all-namespaces

7.13.42 Quellen

Offizielle Microsoft-Dokumentation

Offizielle Linux- und Projektdokumentation

Offizielle Docker-Dokumentation

Offizielle Kubernetes-Dokumentation

Offizielle Apple-Dokumentation

Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.

7. Schnelle Entscheidungsbäume

7.14 TLS- oder HTTPS-Verbindung schlägt fehl

7.14.1 Ziel dieser Seite

Diese Seite beschreibt die systematische Diagnose, wenn eine TLS- oder HTTPS-Verbindung nicht aufgebaut werden kann, eine Zertifikatswarnung erscheint oder eine Anwendung erst nach dem TLS-Handshake fehlschlägt.

Ziele der Diagnose:

Eine erfolgreiche TCP-Verbindung zu Port 443 beweist noch nicht, dass TLS oder HTTPS funktioniert.

7.14.2 Sicherheitskennzeichnungen

Kennzeichnung Bedeutung
LESEND erfasst ausschließlich Zustände und Messwerte
NETZAKTIV baut eine Verbindung auf oder ruft externe Ressourcen ab
SENSITIV kann Zertifikate, Header, interne Namen oder Sicherheitsinformationen anzeigen
ÄNDERND verändert Konfigurationen, Truststores oder Dienste
AUSFALLRISIKO kann bestehende TLS-Verbindungen oder Dienste unterbrechen

Grundregeln:

7.14.3 Vollständiger HTTPS-Verbindungspfad

Anwendung
→ Proxykonfiguration
→ DNS-Auflösung
→ IPv4- oder IPv6-Zieladresse
→ Routing und Firewall
→ TCP-Verbindung
→ TLS ClientHello
→ SNI und ALPN
→ TLS ServerHello
→ Serverzertifikat und Zertifikatskette
→ Zertifikatsprüfung
→ optionales Clientzertifikat
→ verschlüsselte HTTP-Anfrage
→ Reverse Proxy oder Load Balancer
→ Backend
→ HTTP-Antwort

Jede Ebene kann einen eigenen Fehler verursachen.

Eine Browsermeldung über HTTPS beweist nicht automatisch, dass das Zertifikat die Ursache ist. Der Fehler kann bereits bei DNS, TCP, Proxy, TLS-Version, SNI oder im Backend entstehen.

7.14.4 Fehlerklassen unterscheiden

Fehlerklasse Typischer Befund
DNS-Fehler Zielname wird nicht oder falsch aufgelöst
Routing- oder Firewallfehler Zieladresse oder Port ist nicht erreichbar
TCP-Fehler Timeout, Verbindungsablehnung oder TCP Reset
Proxyfehler falscher Proxy, Authentifizierung oder blockierter CONNECT-Tunnel
TLS-Protokollfehler Client und Server finden keine gemeinsame TLS-Version
Cipher-Fehler keine gemeinsame Cipher Suite oder Signaturalgorithmus
Zertifikatsnamenfehler FQDN stimmt nicht mit dem SAN überein
Gültigkeitsfehler Zertifikat ist abgelaufen oder noch nicht gültig
Vertrauensfehler Root-CA wird nicht vertraut
Kettenfehler Intermediate-CA fehlt oder Kette kann nicht aufgebaut werden
Sperrprüfungsfehler CRL- oder OCSP-Prüfung schlägt fehl
SNI-Fehler Server liefert das Zertifikat eines falschen virtuellen Hosts
ALPN-Fehler HTTP/1.1, HTTP/2 oder anderes Anwendungsprotokoll wird falsch ausgehandelt
mTLS-Fehler Clientzertifikat fehlt, ist falsch oder wird nicht akzeptiert
TLS-Inspection-Fehler Proxy ersetzt das Serverzertifikat durch ein eigenes Zertifikat
Serverkonfigurationsfehler Zertifikat, Schlüssel, Bindung oder Listener ist fehlerhaft
Reverse-Proxy-Fehler Frontend-TLS funktioniert, Backend-TLS schlägt fehl
HTTP-Fehler TLS funktioniert, Server liefert aber einen HTTP-Fehlercode
Anwendungsfehler Browser funktioniert, bestimmte Anwendung jedoch nicht
Truststore-Abweichung Betriebssystem, Browser, Java oder Container vertraut unterschiedlichen CAs

7.14.5 Typische Symptome und Fehlermeldungen

Mögliche Meldungen:

Certificate verify failed
Unable to get local issuer certificate
Unable to verify the first certificate
Self-signed certificate
Certificate has expired
Certificate is not yet valid
Hostname mismatch
Unknown CA
Bad certificate
Certificate required
Handshake failure
Protocol version
No shared cipher
TLS alert
Connection reset by peer
Connection refused
Operation timed out
ERR_SSL_PROTOCOL_ERROR
ERR_CERT_AUTHORITY_INVALID
ERR_CERT_DATE_INVALID
SEC_ERROR_UNKNOWN_ISSUER
SSL_ERROR_NO_CYPHER_OVERLAP
PKIX path building failed
unable to find valid certification path
The underlying connection was closed
Could not establish trust relationship
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

Die genaue Meldung, Anwendung, Uhrzeit und Clientplattform müssen dokumentiert werden.

7.14.6 Mindestinformationen erfassen

Vor der Diagnose sind festzuhalten:

Private Schlüssel, Passwörter, Sitzungscookies, API-Keys und Zugriffstokens gehören nicht in die Dokumentation.

7.14.7 TCP-, TLS- und HTTP-Fehler trennen

Testebene Erfolgsnachweis
DNS vorgesehene A- oder AAAA-Adresse wird geliefert
Netzwerk Route zum vorgesehenen Ziel besteht
TCP Drei-Wege-Handshake mit Zielport funktioniert
TLS Handshake wird mit gemeinsamer Version und Cipher abgeschlossen
Zertifikatsprüfung Name, Gültigkeit, Kette und Vertrauen sind korrekt
HTTP gültige HTTP-Antwort wird empfangen
Anwendung ursprüngliche Funktion arbeitet vollständig

Mögliche Einordnung:

TCP schlägt fehl
→ noch kein TLS-Problem nachgewiesen

TCP funktioniert, TLS schlägt fehl
→ TLS-Version, Cipher, SNI, Zertifikat oder mTLS prüfen

TLS funktioniert, HTTP 502 erscheint
→ Reverse Proxy oder Backend prüfen

HTTP 200 erscheint, Anwendung funktioniert nicht
→ Anwendungslogik, API, Cookie, Authentifizierung oder Inhalt prüfen

7.14.8 DNS und Zieladresse prüfen

Windows

Resolve-DnsName `
  -Name "app.example.test" `
  -Type A

Resolve-DnsName `
  -Name "app.example.test" `
  -Type AAAA

Linux und macOS

dig app.example.test A

dig app.example.test AAAA

Zu prüfen sind:

Wenn mehrere IP-Adressen vorhanden sind, müssen die tatsächlich verwendete Adresse und das Verhalten der einzelnen Ziele verglichen werden.

7.14.9 IPv4 und IPv6 getrennt testen

NETZAKTIV

curl \
  -4 \
  -v \
  https://app.example.test/

curl \
  -6 \
  -v \
  https://app.example.test/

Möglicher Befund:

Ein scheinbarer TLS-Fehler kann durch einen fehlerhaften IPv6-Pfad oder ein falsch konfiguriertes Zielsystem verursacht werden.

7.14.10 TCP-Port prüfen

Windows

Test-NetConnection `
  -ComputerName "app.example.test" `
  -Port 443

Wichtige Felder:

RemoteAddress
RemotePort
InterfaceAlias
SourceAddress
TcpTestSucceeded

Linux und macOS

nc \
  -vz \
  app.example.test \
  443

Alternativ kann bereits curl -v oder openssl s_client zum Aufbau der TCP-Verbindung verwendet werden.

Mögliche Ergebnisse:

Ergebnis Einordnung
Timeout Firewall, Routing, Proxy oder nicht antwortender Server
Connection refused Ziel erreichbar, aber kein Listener oder aktive Ablehnung
TCP Reset Firewall, Load Balancer oder Dienst beendet Verbindung
TCP erfolgreich erst jetzt TLS-Handshake untersuchen

Ein erfolgreicher Ping beweist keine Erreichbarkeit von TCP-Port 443.

7.14.11 Systemzeit und Zeitzone prüfen

Zertifikate besitzen einen Gültigkeitszeitraum:

Not Before
Not After

Eine falsche Systemzeit kann ein gültiges Zertifikat als abgelaufen oder noch nicht gültig erscheinen lassen.

Windows

Get-Date

w32tm /query /status

w32tm /query /source

Linux

date

date -u

timedatectl status

macOS

date

date -u

systemsetup -gettimezone

Zu prüfen sind:

7.14.12 HTTPS mit curl prüfen

NETZAKTIV, SENSITIV

curl \
  --connect-timeout 10 \
  --max-time 30 \
  -v \
  https://app.example.test/

Die verbose Ausgabe kann zeigen:

Verbose Ausgaben können sensible HTTP-Header enthalten und müssen vor Weitergabe geprüft werden.

Nur die HTTP-Header anzeigen:

curl \
  -sS \
  -D - \
  -o /dev/null \
  https://app.example.test/

Einige Anwendungen unterstützen keine HEAD-Anfrage. Deshalb ist eine normale GET-Anfrage mit verworfener Antwort häufig aussagekräftiger als curl -I.

7.14.13 Zertifikatsprüfung testweise abgrenzen

NUR ZUR DIAGNOSE, NICHT ALS LÖSUNG

curl \
  -v \
  -k \
  https://app.example.test/

Einordnung:

Normaler Test Test mit -k Einordnung
schlägt fehl funktioniert Zertifikatsvalidierung wahrscheinlich betroffen
schlägt fehl schlägt ebenfalls fehl nicht nur Zertifikatsvertrauen betroffen
funktioniert funktioniert kein aktueller Validierungsfehler
funktioniert nur auf einem Client anderer Client schlägt fehl Truststore oder Anwendung unterscheidet sich

-k deaktiviert die Überprüfung des Serverzertifikats. Es behebt weder DNS-, TCP-, TLS-Version-, Cipher-, SNI-, ALPN- noch mTLS-Probleme zuverlässig.

Die Option darf nicht in produktiven Skripten, Anwendungen oder dauerhaften Konfigurationen verbleiben.

7.14.14 Bestimmte IP-Adresse mit richtigem Hostnamen testen

Ein direkter Aufruf über eine IP-Adresse verändert häufig:

Deshalb sollte curl --resolve verwendet werden:

curl \
  -v \
  --resolve \
  app.example.test:443:192.0.2.25 \
  https://app.example.test/

Damit bleiben erhalten:

Nur die Ziel-IP-Adresse wird für den Test festgelegt.

Dies ist besonders nützlich bei:

7.14.15 TLS-Handshake mit OpenSSL prüfen

NETZAKTIV, SENSITIV

openssl s_client \
  -connect app.example.test:443 \
  -servername app.example.test \
  -showcerts \
  -verify_return_error \
  -verify_hostname app.example.test \
  </dev/null

Wichtige Ausgabebereiche:

CONNECTED
Certificate chain
subject
issuer
Server certificate
SSL handshake
Protocol
Cipher
ALPN protocol
Verify return code

Erfolgreiche OpenSSL-Verifikation:

Verify return code: 0 (ok)

Wichtige Optionen:

Option Bedeutung
-connect Zielhost und Port
-servername übermittelt SNI
-showcerts zeigt die vom Server gesendeten Zertifikate
-verify_return_error beendet bei Validierungsfehlern
-verify_hostname prüft den angegebenen Hostnamen
</dev/null beendet die Eingabe nach dem Handshake

Nicht jede ältere OpenSSL-Version unterstützt alle genannten Optionen.

7.14.16 Zertifikat lokal untersuchen

Vorhandene Zertifikatsdatei im PEM-Format:

LESEND

openssl x509 \
  -in server.pem \
  -noout \
  -subject \
  -issuer \
  -serial \
  -dates \
  -fingerprint \
  -sha256

Subject Alternative Names:

openssl x509 \
  -in server.pem \
  -noout \
  -ext subjectAltName

Vollständige Zertifikatsinformationen:

openssl x509 \
  -in server.pem \
  -noout \
  -text

Zu prüfen sind:

Private Schlüssel dürfen mit diesen Ausgaben nicht verwechselt oder weitergegeben werden.

7.14.17 Hostname und Subject Alternative Name prüfen

Für die Identitätsprüfung ist der vorgesehene Dienstname entscheidend.

Beispiel:

Aufgerufener Name:
app.example.test

Erforderlicher SAN:
DNS:app.example.test

Zu prüfen sind:

Beispiele:

*.example.test

kann typischerweise abdecken:

app.example.test
mail.example.test

aber nicht:

example.test
app.intern.example.test

Der CNAME-Zielname muss nicht zwingend im Zertifikat stehen. Entscheidend ist grundsätzlich der Name, unter dem der Client den Dienst aufruft und dessen Identität er prüft.

7.14.18 Zertifikatskette verstehen

Eine typische Kette:

Serverzertifikat
→ Intermediate-CA
→ Root-CA

Aufgaben:

Element Aufgabe
Serverzertifikat identifiziert den Dienst
Intermediate-CA verbindet Serverzertifikat mit vertrauenswürdiger CA
Root-CA bildet den lokalen Vertrauensanker

Der Server sollte gewöhnlich senden:

Serverzertifikat
Intermediate-CA-Zertifikat
weitere erforderliche Intermediate-Zertifikate

Die Root-CA wird gewöhnlich nicht als Teil der Serverkette benötigt, weil sie bereits im Truststore des Clients vorhanden sein muss.

Typische Kettenfehler:

7.14.19 Zertifikatskette lokal verifizieren

Vorhandene Dateien:

server.pem
intermediates.pem
root-ca.pem

LESEND

openssl verify \
  -purpose sslserver \
  -CAfile root-ca.pem \
  -untrusted intermediates.pem \
  server.pem

Erfolgreiches Ergebnis:

server.pem: OK

Dieser Test beweist die Gültigkeit nur gegenüber den ausdrücklich angegebenen CA-Dateien. Er beweist nicht, dass der Truststore der ursprünglichen Anwendung identisch konfiguriert ist.

7.14.20 Gültigkeitszeitraum prüfen

openssl x509 \
  -in server.pem \
  -noout \
  -dates

Mögliche Ausgabe:

notBefore=...
notAfter=...

Zu prüfen sind:

Ein erneuertes Zertifikat auf dem Dateisystem beweist nicht, dass der Listener dieses Zertifikat bereits verwendet.

7.14.21 Sperrprüfung, CRL und OCSP untersuchen

Mögliche Sperrmechanismen:

OCSP-Stapling des Servers anfordern:

NETZAKTIV

openssl s_client \
  -connect app.example.test:443 \
  -servername app.example.test \
  -status \
  </dev/null

Unter Windows kann eine vorhandene Zertifikatsdatei geprüft werden:

NETZAKTIV, kann AIA- und Sperrlistenadressen abrufen

certutil -verify -urlfetch server.cer

Zu prüfen sind:

Ein Fehler bei der Sperrprüfung darf nicht pauschal durch Abschalten der Sperrprüfung gelöst werden.

7.14.22 TLS-Versionen prüfen

Aktuelle TLS-Version aushandeln:

openssl s_client \
  -connect app.example.test:443 \
  -servername app.example.test \
  </dev/null

TLS 1.2 ausdrücklich testen:

openssl s_client \
  -connect app.example.test:443 \
  -servername app.example.test \
  -tls1_2 \
  </dev/null

TLS 1.3 ausdrücklich testen:

openssl s_client \
  -connect app.example.test:443 \
  -servername app.example.test \
  -tls1_3 \
  </dev/null

Zu prüfen sind:

Das Aktivieren veralteter TLS-Versionen ist keine geeignete Dauerlösung. Stattdessen muss die veraltete Gegenstelle aktualisiert oder ersetzt werden.

7.14.23 Cipher Suites und Algorithmen prüfen

Lokal verfügbare OpenSSL-Cipher anzeigen:

openssl ciphers -v

Unter Windows:

Get-TlsCipherSuite |
  Select-Object `
    Name,
    Protocols,
    Cipher,
    Hash,
    Exchange

Zu unterscheiden sind:

Ein RSA-Serverzertifikat, eine ECDSA-Cipher und ein bestimmter Schlüsselaustausch sind unterschiedliche Bestandteile und dürfen nicht gleichgesetzt werden.

TLS 1.3 definiert Cipher Suites anders als frühere TLS-Versionen. Deshalb ist eine reine Cipherliste ohne TLS-Version und Clientkontext unvollständig.

7.14.24 SNI prüfen

SNI übermittelt den gewünschten Servernamen bereits während des TLS-Handshakes.

Mit SNI:

openssl s_client \
  -connect 192.0.2.25:443 \
  -servername app.example.test \
  </dev/null

Ohne ausdrückliches SNI:

openssl s_client \
  -connect 192.0.2.25:443 \
  </dev/null

Wenn unterschiedliche Zertifikate erscheinen, verwendet der Server namensbasierte virtuelle TLS-Hosts.

Zu prüfen sind:

Ein Test ohne SNI kann ein anderes Zertifikat liefern als die reale Anwendung und darf deshalb nicht allein bewertet werden.

7.14.25 ALPN, HTTP/1.1 und HTTP/2 prüfen

ALPN wird während des TLS-Handshakes verwendet, um das Anwendungsprotokoll auszuhandeln.

openssl s_client \
  -connect app.example.test:443 \
  -servername app.example.test \
  -alpn h2,http/1.1 \
  </dev/null

Mit curl:

curl \
  --http1.1 \
  -v \
  https://app.example.test/

Falls die verwendete curl-Version HTTP/2 unterstützt:

curl \
  --http2 \
  -v \
  https://app.example.test/

Zu prüfen sind:

HTTP/3 verwendet QUIC über UDP und muss getrennt von klassischem HTTPS über TCP untersucht werden.

7.14.26 Gegenseitige TLS-Authentifizierung prüfen

Bei normalem TLS authentifiziert sich der Server gegenüber dem Client.

Bei Mutual TLS authentifizieren sich beide Seiten:

Serverzertifikat
+
Clientzertifikat

Test mit autorisiertem Clientzertifikat:

NETZAKTIV, SENSITIV

openssl s_client \
  -connect app.example.test:443 \
  -servername app.example.test \
  -cert client.pem \
  -key client.key \
  -verify_return_error \
  </dev/null

Zu prüfen sind:

Die Datei client.key ist besonders schützenswert. Pfade, Berechtigungen und Diagnoseausgaben müssen entsprechend behandelt werden.

7.14.27 Proxykonfiguration prüfen

Windows-WinHTTP-Proxy

netsh winhttp show proxy

Linux und macOS

env |
grep -i proxy

Mögliche Variablen:

HTTP_PROXY
HTTPS_PROXY
NO_PROXY
http_proxy
https_proxy
no_proxy

Zu prüfen sind:

Ein erfolgreicher Browsertest beweist nicht, dass ein Windows-Dienst, Java-Prozess oder Container dieselbe Proxykonfiguration verwendet.

7.14.28 TLS-Inspection erkennen

Bei TLS-Inspection beendet ein Sicherheitsgerät die TLS-Verbindung und baut anschließend eine neue TLS-Verbindung zum Ziel auf.

Mögliche Hinweise:

Vergleich:

  1. Zertifikat vom betroffenen Client erfassen.
  2. Zertifikat aus einem anderen autorisierten Netzwerk erfassen.
  3. Subject, Issuer, SAN, Seriennummer und Fingerprint vergleichen.
  4. Proxy- und Sicherheitsrichtlinie prüfen.
  5. Truststore der betroffenen Anwendung prüfen.

TLS-Inspection darf nicht ohne Freigabe umgangen werden. Eine notwendige Ausnahme muss über den vorgesehenen Sicherheitsprozess erfolgen.

7.14.29 Windows-Zertifikatsspeicher prüfen

Stores anzeigen:

LESEND

Get-ChildItem `
  -Path Cert:\CurrentUser

Get-ChildItem `
  -Path Cert:\LocalMachine

Persönliche Zertifikate des Computers:

Get-ChildItem `
  -Path Cert:\LocalMachine\My |
Select-Object `
  Subject,
  Issuer,
  Thumbprint,
  NotBefore,
  NotAfter,
  HasPrivateKey

Vertrauenswürdige Root-CAs:

Get-ChildItem `
  -Path Cert:\LocalMachine\Root |
Select-Object `
  Subject,
  Issuer,
  Thumbprint,
  NotAfter

Intermediate-CAs:

Get-ChildItem `
  -Path Cert:\LocalMachine\CA |
Select-Object `
  Subject,
  Issuer,
  Thumbprint,
  NotAfter

Zu unterscheiden sind:

Ein Zertifikat im Benutzerstore steht einem Dienstkonto oder Computersystem nicht automatisch zur Verfügung.

7.14.30 Windows-Schannel-Ereignisse prüfen

LESEND

Get-WinEvent `
  -FilterHashtable @{
    LogName = "System"
    ProviderName = "Schannel"
    StartTime = (Get-Date).AddHours(-6)
  } |
Select-Object `
  TimeCreated,
  Id,
  LevelDisplayName,
  Message

Zu korrelieren sind:

Schannel-Ereignisse allein enthalten nicht immer den vollständigen Fehlerpfad. Sie müssen mit Anwendung, CAPI2, Proxy, Netzwerk und Serverseite korreliert werden.

7.14.31 Windows-CAPI2-Protokoll prüfen

Pfad in der Ereignisanzeige:

Anwendungs- und Dienstprotokolle
→ Microsoft
→ Windows
→ CAPI2
→ Operational

Vorhandene Ereignisse ausgeben:

Get-WinEvent `
  -LogName "Microsoft-Windows-CAPI2/Operational" `
  -MaxEvents 100 |
Select-Object `
  TimeCreated,
  Id,
  LevelDisplayName,
  Message

CAPI2 kann unter anderem Hinweise liefern zu:

Das Protokoll ist möglicherweise nicht aktiviert. Eine Aktivierung ist eine Konfigurationsänderung und muss zeitlich begrenzt sowie dokumentiert werden.

7.14.32 Windows-TLS-Richtlinien erfassen

Verfügbare Cipher Suites:

Get-TlsCipherSuite

Vorhandene Schannel-Protokolleinstellungen:

Get-ChildItem `
  -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols" `
  -Recurse `
  -ErrorAction SilentlyContinue

Zu prüfen sind:

Registrywerte dürfen nicht nach allgemeinen Internetanleitungen verändert werden. Betriebssystemversion, Anwendung und Microsoft-Dokumentation müssen zusammenpassen.

7.14.33 Linux- und macOS-Truststores prüfen

OpenSSL-Version:

openssl version -a

OpenSSL-Konfigurationsverzeichnis:

openssl version -d

Je nach Linux-Distribution können CA-Zertifikate unter anderem verwaltet werden über:

/etc/ssl/certs
/etc/pki/ca-trust
/usr/local/share/ca-certificates

Die tatsächlich verwendeten Pfade hängen von Distribution, TLS-Bibliothek und Anwendung ab.

macOS-Systemschlüsselbund anzeigen:

security find-certificate \
  -a \
  -Z \
  /Library/Keychains/System.keychain

Zu prüfen sind:

Ein erfolgreicher Test mit Apple-Systemvertrauen beweist nicht, dass eine separat installierte OpenSSL- oder Java-Version denselben Truststore verwendet.

7.14.34 Java-Truststore prüfen

Java-Version:

java -version

Java-Pfad und Eigenschaften:

java \
  -XshowSettings:properties \
  -version

Standard-CA-Store anzeigen:

keytool \
  -list \
  -cacerts

Bestimmten Truststore anzeigen:

keytool \
  -list \
  -keystore <Truststore>

Zu prüfen sind:

Ein Import in den Betriebssystem-Truststore behebt keinen Java-Fehler, wenn die Anwendung ausschließlich ihren eigenen Truststore verwendet.

7.14.35 Container separat prüfen

Der Host und ein Container können unterschiedliche besitzen:

Containerkonfiguration:

docker inspect \
  <Containername>

Proxyvariablen:

docker exec \
  <Containername> \
  env

Zeit im Container:

docker exec \
  <Containername> \
  date -u

Falls curl im Image vorhanden ist:

docker exec \
  <Containername> \
  curl \
  -v \
  https://app.example.test/

Vergleich:

Test auf dem Host
gegen
Test im Container

Wenn nur der Container fehlschlägt, sind insbesondere CA-Bundle, Proxy, DNS, Netzwerknamespace und Anwendungslaufzeit zu prüfen.

Produktive Images dürfen nicht spontan durch Installation zusätzlicher Diagnosepakete verändert werden. Falls Werkzeuge fehlen, ist ein freigegebener Diagnosecontainer oder ein reproduzierbares Testimage zu verwenden.

7.14.36 Serverzertifikat und privaten Schlüssel zuordnen

Zertifikat und privater Schlüssel müssen dasselbe Schlüsselpaar bilden.

Öffentlichen Schlüssel des Zertifikats hashen:

LESEND

openssl x509 \
  -in server.pem \
  -pubkey \
  -noout |
openssl pkey \
  -pubin \
  -outform DER |
openssl sha256

Öffentlichen Anteil des privaten Schlüssels hashen:

SENSITIV – Zugriff auf privaten Schlüssel erforderlich

openssl pkey \
  -in server.key \
  -pubout \
  -outform DER |
openssl sha256

Die beiden Hashwerte müssen übereinstimmen.

Dieser Test gibt nicht den privaten Schlüssel aus. Der Zugriff auf die Schlüsseldatei bleibt dennoch sicherheitskritisch.

Zu prüfen sind zusätzlich:

7.14.37 Nginx prüfen

Konfigurationssyntax:

LESEND

sudo nginx -t

Dienststatus:

systemctl \
  status nginx \
  --no-pager

Protokolle:

journalctl \
  -u nginx \
  --since "-2 hours"

Zu prüfen sind:

Bei einer kombinierten Zertifikatsdatei steht gewöhnlich zuerst das Serverzertifikat, gefolgt von den erforderlichen Intermediate-Zertifikaten.

7.14.38 Apache HTTP Server prüfen

Konfigurationssyntax:

LESEND

sudo apachectl configtest

Alternativ, abhängig von der Installation:

sudo httpd -t

Dienststatus:

systemctl \
  status apache2 \
  --no-pager

oder:

systemctl \
  status httpd \
  --no-pager

Zu prüfen sind:

Der genaue Dienstname und die Konfigurationspfade hängen von Distribution und Installation ab und dürfen nicht angenommen werden.

7.14.39 IIS-Bindungen prüfen

Falls das WebAdministration-Modul vorhanden ist:

Import-Module WebAdministration

HTTPS-Bindungen:

Get-WebBinding `
  -Protocol https

SSL-Bindungen:

Get-ChildItem `
  -Path IIS:\SslBindings

Zu prüfen sind:

Ein gültiges Zertifikat im Windows-Zertifikatsspeicher beweist nicht, dass es an die richtige IIS-Site gebunden ist.

7.14.40 Reverse Proxy und Load Balancer getrennt prüfen

Mögliche TLS-Abschnitte:

Client
→ TLS zum Load Balancer
→ TLS zum Reverse Proxy
→ TLS zum Backend

Oder:

Client
→ TLS-Terminierung am Load Balancer
→ unverschlüsseltes HTTP zum Backend

Für jeden Abschnitt getrennt erfassen:

Typische Fehler:

Ein erfolgreicher externer TLS-Test prüft nicht automatisch die Verbindung vom Reverse Proxy zum Backend.

7.14.41 HTTP-Ebene nach erfolgreichem TLS prüfen

Wenn der TLS-Handshake erfolgreich ist, muss der HTTP-Statuscode ausgewertet werden.

Status Mögliche Einordnung
200 Anfrage grundsätzlich erfolgreich
301 oder 302 Redirectziel prüfen
400 fehlerhafte Anfrage oder Hostheader
401 Authentifizierung erforderlich oder fehlgeschlagen
403 Zugriff verweigert
404 Pfad oder virtueller Host falsch
405 HTTP-Methode nicht erlaubt
408 Request Timeout
421 Anfrage beim falschen Ursprung oder falscher Verbindung
429 Rate Limit
500 Anwendungs- oder Serverfehler
502 Proxy erreicht Backend nicht korrekt
503 Dienst oder Backend nicht verfügbar
504 Backend antwortet nicht rechtzeitig

Redirects verfolgen:

curl \
  -v \
  -L \
  https://app.example.test/

Zu prüfen sind:

Ein HTTP-Fehlercode beweist, dass mindestens eine TLS-Verbindung bereits erfolgreich aufgebaut wurde.

7.14.42 Netzwerkaufzeichnung einsetzen

Eine Netzwerkaufzeichnung ist sinnvoll, wenn unklar bleibt:

Bei TLS 1.3 sind größere Teile des Handshakes verschlüsselt als bei älteren Versionen. Mit Encrypted ClientHello kann auch der bisher sichtbare Servername geschützt werden.

Für die Entschlüsselung moderner TLS-Sitzungen werden in der Regel autorisiert erfasste Sitzungsschlüssel benötigt. Ein Server-Private-Key allein reicht insbesondere bei modernen Schlüsselaustauschverfahren nicht zur nachträglichen Entschlüsselung.

TLS-Schlüsselprotokolle und entschlüsselte Aufzeichnungen enthalten hochsensible Daten und müssen besonders geschützt, zeitlich begrenzt und anschließend sicher entfernt werden.

7.14.43 Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Der Reverse Proxy sendet beim Verbindungsaufbau zum Backend
keinen passenden SNI-Namen und erhält deshalb das
Default-Zertifikat eines anderen virtuellen Hosts.

Erwarteter Befund:
Der OpenSSL-Test gegen die Backend-IP liefert ohne SNI
ein anderes Zertifikat als mit dem vorgesehenen SNI-Namen.

Gegenbeweis:
Mit und ohne SNI wird dasselbe korrekte Zertifikat geliefert
und die Backendverbindung funktioniert.

Testmethode:
OpenSSL-Verbindungen mit identischer Ziel-IP und
unterschiedlicher SNI-Übermittlung vergleichen.

Erfolgskriterium:
Das abweichende Zertifikat und der fehlerhafte
Proxy-SNI-Pfad sind reproduzierbar nachgewiesen.

Eine belastbare Hypothese enthält:

7.14.44 Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko
Zertifikat erneuern Ablauf oder falsche Gültigkeit bestätigt falsche Bindung oder unvollständige Verteilung
vollständige Kette konfigurieren fehlendes Intermediate bestätigt falsche Reihenfolge oder falsche CA
Zertifikatsbindung korrigieren falscher Listener oder virtueller Host bestätigt andere Site kann betroffen sein
SNI korrigieren falsche Zertifikatsauswahl nachgewiesen weitere virtuelle Hosts betroffen
Backend-SNI korrigieren Proxy sendet falschen Namen Backendrouting ändert sich
Truststore ergänzen vorgesehene CA eindeutig bestätigt zusätzliche CA erhält Vertrauensstatus
Systemzeit korrigieren Zeitabweichung bestätigt Kerberos, Tokens und Logs betroffen
TLS-Policy korrigieren fehlende gemeinsame sichere Version bestätigt ältere Clients können ausfallen
Cipher-Policy korrigieren fehlende sichere Schnittmenge bestätigt Kompatibilität und Sicherheit betroffen
Clientzertifikat erneuern mTLS-Zertifikat fehlerhaft Identitätszuordnung kann ausfallen
Proxyregel korrigieren falscher Proxyweg bestätigt weitere Anwendungen betroffen
TLS-Inspection-Ausnahme Inspection als Ursache bestätigt und freigegeben Sicherheitskontrolle wird verändert
Reverse-Proxy-Backend korrigieren Backend-TLS-Fehler bestätigt Dienstunterbrechung möglich
Dienst kontrolliert neu laden neue Konfiguration geprüft kurze Unterbrechung oder Ladefehler
Load-Balancer-Nodes synchronisieren abweichende Zertifikate bestätigt mehrere produktive Nodes betroffen

Vor der Maßnahme sind zu dokumentieren:

7.14.45 Nicht zulässige Schnelllösungen

Zertifikatsprüfung dauerhaft deaktivieren
curl -k in produktive Skripte übernehmen
verify=false in Anwendungen eintragen
NODE_TLS_REJECT_UNAUTHORIZED=0 setzen
Java-Hostnameprüfung deaktivieren
beliebige Root-CA importieren
selbst signiertes Zertifikat ungeprüft vertrauen
private Schlüssel weitergeben
private Schlüssel in Containerimages einbauen
alte TLS-Versionen pauschal aktivieren
unsichere Cipher dauerhaft aktivieren
Sperrprüfung ohne Risikoanalyse abschalten
Truststore vollständig ersetzen
alle Zertifikate aus Stores löschen
Schannel-Registrywerte nach ungeprüfter Anleitung ändern
Reverse Proxy ohne Konfigurationstest neu starten
Zertifikat nur auf einem Load-Balancer-Node austauschen
TLS-Inspection heimlich umgehen

Eine funktionierende Verbindung ohne Zertifikatsprüfung ist kein Nachweis einer sicheren oder korrekten Lösung.

7.14.46 Vollständiger Diagnoseablauf

  1. Exakte Fehlermeldung aufnehmen
    Wortlaut, Anwendung, Client und Uhrzeit dokumentieren.

  2. Vollständige URL bestimmen
    Schema, FQDN, Port und Pfad erfassen.

  3. Fehlerumfang bestimmen
    Einzelnen Client, Anwendung, Standort oder alle Benutzer unterscheiden.

  4. Letzte Änderungen erfassen
    Zertifikatswechsel, Update, Proxy-, DNS- oder Firewalländerung prüfen.

  5. Systemzeit prüfen
    Datum, UTC, Zeitzone und Synchronisation bestätigen.

  6. DNS-Auflösung prüfen
    A, AAAA und CNAME auswerten.

  7. Tatsächliche Zieladresse bestimmen
    IPv4, IPv6, Load Balancer oder Proxy identifizieren.

  8. TCP-Port prüfen
    Timeout, Ablehnung und erfolgreichen Handshake unterscheiden.

  9. Proxyweg bestimmen
    Direktverbindung, expliziten Proxy, PAC oder TLS-Inspection unterscheiden.

  10. Normalen HTTPS-Test durchführen
    Zertifikatsprüfung nicht deaktivieren.

  11. TLS und HTTP trennen
    Handshakefehler und HTTP-Statuscode unterscheiden.

  12. OpenSSL-Handshake durchführen
    SNI und Hostnamenprüfung ausdrücklich angeben.

  13. TLS-Version dokumentieren
    Ausgehandelte Version erfassen.

  14. Cipher dokumentieren
    Ausgehandelte Cipher Suite erfassen.

  15. ALPN dokumentieren
    HTTP/1.1, HTTP/2 oder anderes Protokoll bestimmen.

  16. Serverzertifikat dokumentieren
    Subject, Issuer, Seriennummer und Fingerprint erfassen.

  17. SAN prüfen
    Aufgerufenen FQDN mit Zertifikat vergleichen.

  18. Gültigkeitszeitraum prüfen
    Server- und Intermediate-Zertifikate berücksichtigen.

  19. Zertifikatskette prüfen
    Fehlende oder falsche Intermediate-CA bestimmen.

  20. Root-Vertrauen prüfen
    Tatsächlichen Truststore der Anwendung untersuchen.

  21. Sperrprüfung prüfen
    CRL, OCSP, AIA und Netzwerkzugriff berücksichtigen.

  22. SNI prüfen
    Test mit und ohne vorgesehenen Servernamen vergleichen.

  23. Einzelne Zieladressen prüfen
    Load-Balancer-Nodes mit --resolve vergleichen.

  24. IPv4 und IPv6 vergleichen
    Unterschiedliche Pfade und Zertifikate bestimmen.

  25. mTLS prüfen
    Clientzertifikat, Schlüssel, Kette und Serververtrauen untersuchen.

  26. TLS-Inspection prüfen
    Zertifikatsaussteller und Fingerprint zwischen Netzen vergleichen.

  27. Anwendungsspezifischen Truststore prüfen
    Betriebssystem, Browser, Java und Container unterscheiden.

  28. Serverbindung prüfen
    Listener, virtuellen Host, Zertifikat und Schlüssel zuordnen.

  29. Zertifikat und Schlüssel vergleichen
    Öffentliche Schlüssel sicher hashen.

  30. Reverse Proxy und Backend trennen
    Frontend- und Backend-TLS einzeln testen.

  31. Serverprotokolle auswerten
    Handshake, Zertifikat, mTLS und Backendfehler korrelieren.

  32. Bei Bedarf Netzwerkaufzeichnung durchführen
    Nur autorisiert, begrenzt und datenschutzkonform.

  33. Hypothese und Gegenbeweis formulieren
    Ursache vor der Änderung messbar festlegen.

  34. Eine kontrollierte Maßnahme durchführen
    Risiko, Rückweg und Freigabe beachten.

  35. Konfiguration vor Reload prüfen
    Beispielsweise nginx -t oder apachectl configtest.

  36. Identischen TLS-Test wiederholen
    Version, Cipher, Zertifikat und Verify-Ergebnis vergleichen.

  37. HTTP-Antwort prüfen
    Statuscode, Redirect und Header auswerten.

  38. Ursprüngliche Anwendung testen
    Nicht nur curl oder OpenSSL verifizieren.

  39. Weitere Clients und Netze prüfen
    Repräsentative Systeme vergleichen.

  40. Temporäre Diagnoseänderungen zurücknehmen
    Logging, Capture, Testzertifikate und Ausnahmen entfernen.

  41. Ursache dokumentieren
    Fehlerhafte Ebene und technischer Nachweis festhalten.

  42. Prävention festlegen
    Monitoring, automatische Erneuerung und Konfigurationstest verbessern.

7.14.47 Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
DNS schlägt fehl Namensauflösung direkte A- und AAAA-Abfrage
TCP-Port 443 nicht erreichbar Routing, Firewall oder Listener Netzwerkpfad und Serverseite
TCP funktioniert, kein ServerHello TLS-Policy, Proxy oder Server Handshake und Serverlogs
curl -k funktioniert, normaler Test nicht Zertifikatsvalidierung Name, Kette, Zeit und Vertrauen
Hostname mismatch falsches Zertifikat oder falscher Name SAN und SNI prüfen
Zertifikat abgelaufen Erneuerung oder falscher Node alle Zieladressen vergleichen
Zertifikat noch nicht gültig Systemzeit oder falsches Zertifikat Zeit und Gültigkeitsbeginn
unbekannte CA Root fehlt oder TLS-Inspection Issuer und Truststore
lokale CA im Browser vertraut, Java nicht separater Java-Truststore keytool -list
Kette unvollständig Intermediate fehlt -showcerts und openssl verify
nur ein Client betroffen lokaler Truststore, Zeit oder Proxy anderen Client vergleichen
nur ein Load-Balancer-Node betroffen Zertifikatsverteilung unvollständig curl --resolve
ohne SNI falsches Zertifikat namensbasierter virtueller Host Test mit korrektem SNI
mit SNI ebenfalls falsches Zertifikat falsche Bindung oder Serverregel Listenerkonfiguration
TLS 1.2 funktioniert, TLS 1.3 nicht TLS-1.3-Pfad oder Intermediär Proxy und Serverpolicy
TLS 1.3 funktioniert, alter Client nicht veralteter Client Clientbibliothek und TLS-Version
keine gemeinsame Cipher Policy- oder Algorithmuskonflikt Client- und Serverlisten vergleichen
Browser funktioniert, Dienst nicht Proxy, Store oder Systemkonto Dienstkontext prüfen
Host funktioniert, Container nicht CA-Bundle, Proxy oder DNS Test im Container
Frontend-TLS funktioniert, HTTP 502 Backend nicht erreichbar oder Backend-TLS Proxy- und Backendlogs
HTTP 504 Backendtimeout Backendpfad und Antwortzeit
Clientzertifikat erforderlich mTLS Zertifikat und Schlüssel prüfen
unknown ca am Server bei mTLS Server vertraut Client-CA nicht Server-Truststore
nur hinter Security-Proxy fehlerhaft TLS-Inspection Zertifikatsaussteller vergleichen
OCSP- oder CRL-Fehler Sperrprüfungsziel nicht erreichbar AIA/CDP und Proxy prüfen
neuer Fingerprint nur auf manchen Nodes unsynchronisierte Zertifikate alle Nodes einzeln prüfen
HTTP 200, Anwendung fehlerhaft oberhalb von TLS Anwendung, Authentifizierung und Inhalt

7.14.48 Typische Diagnosefehler

7.14.49 Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Ein erfolgreicher Test mit deaktivierter Zertifikatsprüfung ist keine gültige Verifikation.

7.14.50 Prävention und Monitoring

Zu überwachen sind:

Empfohlener Zertifikatsprozess:

Erneuerung anfordern
→ Zertifikat und Kette validieren
→ Zertifikat und Schlüssel zuordnen
→ Testsystem oder einzelnen Node aktualisieren
→ Konfiguration prüfen
→ Dienst kontrolliert neu laden
→ externen TLS-Test durchführen
→ alle Nodes aktualisieren
→ Monitoring und Fingerprint prüfen
→ altes Zertifikat kontrolliert entfernen

Die Erneuerung gilt erst als erfolgreich, wenn der produktive Listener das neue Zertifikat tatsächlich ausliefert.

7.14.51 Dokumentationsvorlage

Störung:
<exakte Fehlermeldung>

Zeitpunkt:
<Datum und Uhrzeit>

Betroffener Client:
<Hostname, IP-Adresse und Betriebssystem>

Betroffene Anwendung:
<Browser, Dienst, Container oder Anwendung>

URL:
<vollständige URL>

FQDN:
<Servername>

Port:
<Port>

Aufgelöste Adressen:
<IPv4 und IPv6>

Verwendete Zieladresse:
<IP-Adresse>

Proxyweg:
<direkt, Proxy, PAC oder TLS-Inspection>

TCP-Ergebnis:
<Ergebnis>

TLS-Version:
<ausgehandelte Version>

Cipher Suite:
<ausgehandelte Cipher>

SNI:
<übermittelter Name>

ALPN:
<ausgehandeltes Protokoll>

Zertifikat-Subject:
<Wert>

Subject Alternative Names:
<Werte>

Issuer:
<Wert>

Seriennummer:
<Wert>

SHA-256-Fingerprint:
<Wert>

Gültigkeit:
<Not Before und Not After>

Zertifikatskette:
<Leaf, Intermediate und Root>

Truststore:
<Betriebssystem, Browser, Java oder Anwendung>

Sperrprüfung:
<CRL- und OCSP-Befund>

mTLS:
<erforderlich, Clientzertifikat und Ergebnis>

Reverse-Proxy-Pfad:
<Frontend und Backend>

HTTP-Ergebnis:
<Statuscode, Redirect und Antwortzeit>

Nachgewiesene Ursache:
<technischer Befund>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

Durchgeführte Maßnahme:
<genaue Änderung>

Risiko und Rückweg:
<Beschreibung>

Verifikation:
<identischer TLS-Test und Anwendungstest>

Prävention:
<Monitoring, Erneuerung oder Standardisierung>

7.14.52 Checkliste

7.14.53 Schnellreferenz

Aufgabe Befehl
Windows-DNS Resolve-DnsName app.example.test
Linux/macOS-DNS dig app.example.test A
Windows-TCP-Test Test-NetConnection app.example.test -Port 443
HTTPS-Diagnose curl -v https://app.example.test/
IPv4-Test curl -4 -v https://app.example.test/
IPv6-Test curl -6 -v https://app.example.test/
bestimmte IP mit richtigem Hostnamen curl -v --resolve app.example.test:443:192.0.2.25 https://app.example.test/
TLS-Handshake openssl s_client -connect app.example.test:443 -servername app.example.test </dev/null
Zertifikatskette anzeigen openssl s_client -connect app.example.test:443 -servername app.example.test -showcerts </dev/null
Hostname verifizieren openssl s_client -connect app.example.test:443 -servername app.example.test -verify_hostname app.example.test </dev/null
TLS 1.2 testen openssl s_client -connect app.example.test:443 -servername app.example.test -tls1_2 </dev/null
TLS 1.3 testen openssl s_client -connect app.example.test:443 -servername app.example.test -tls1_3 </dev/null
ALPN testen openssl s_client -connect app.example.test:443 -servername app.example.test -alpn h2,http/1.1 </dev/null
OCSP-Stapling anfordern openssl s_client -connect app.example.test:443 -servername app.example.test -status </dev/null
Zertifikatsdaten openssl x509 -in server.pem -noout -subject -issuer -serial -dates
SAN anzeigen openssl x509 -in server.pem -noout -ext subjectAltName
Zertifikatskette lokal prüfen openssl verify -purpose sslserver -CAfile root-ca.pem -untrusted intermediates.pem server.pem
Windows-Zertifikatsprüfung certutil -verify -urlfetch server.cer
Windows-Zertifikatsspeicher Get-ChildItem Cert:\LocalMachine
Windows-Cipher Suites Get-TlsCipherSuite
WinHTTP-Proxy netsh winhttp show proxy
Schannel-Ereignisse Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Schannel"}
Java-Truststore keytool -list -cacerts
Docker-Test docker exec <Container> curl -v https://app.example.test/
Nginx-Konfigurationstest nginx -t
Apache-Konfigurationstest apachectl configtest
IIS-HTTPS-Bindungen Get-WebBinding -Protocol https

7.14.54 Quellen

Offizielle Microsoft-Dokumentation

Offizielle OpenSSL-Dokumentation

Offizielle curl-Dokumentation

Offizielle Webserver-Dokumentation

Offizielle Java-Dokumentation

Offizielle Wireshark-Dokumentation

Standards

Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.

7. Schnelle Entscheidungsbäume

7.15 Backupjob ist fehlgeschlagen

7.15.1 Ziel dieser Seite

Diese Seite beschreibt die systematische Diagnose, wenn ein Backupjob:

Ziele der Diagnose:

Ein Backupjob gilt nicht allein deshalb als erfolgreich, weil ein Prozess mit Exit-Code 0 beendet wurde oder eine Sicherungsdatei vorhanden ist.

7.15.2 Sicherheitskennzeichnungen

Kennzeichnung Bedeutung
LESEND erfasst ausschließlich Zustände und Messwerte
NETZAKTIV greift auf Quell- oder Zielsysteme zu
LASTERZEUGEND kann Netzwerk, CPU, Arbeitsspeicher oder Storage stark belasten
ÄNDERND verändert Job-, Repository- oder Sicherungszustände
LÖSCHEND entfernt Recovery Points oder Repositorydaten
SENSITIV kann Zugangsdaten, Schlüssel oder geschützte Daten betreffen
AUSFALLRISIKO kann Sicherungen, Wiederherstellungen oder Produktivdienste unterbrechen

Grundregeln:

7.15.3 Ein Backup ist erst durch Wiederherstellung nachgewiesen

Ein technisch vollständiger Backupablauf besteht aus mehreren Nachweisen:

Job wurde geplant
→ Job wurde tatsächlich gestartet
→ Quelle wurde vollständig erfasst
→ konsistenter Sicherungszeitpunkt wurde erzeugt
→ Daten wurden übertragen
→ Daten wurden im Repository gespeichert
→ Metadaten und Katalog wurden geschrieben
→ Recovery Point wurde registriert
→ Integritätsprüfung war erfolgreich
→ Wiederherstellung wurde getestet
→ wiederhergestellte Anwendung funktioniert

Nicht ausreichend sind allein:

7.15.4 Wichtige Begriffe

Begriff Bedeutung
Vollbackup enthält den vollständigen ausgewählten Datenbestand
inkrementelles Backup enthält Änderungen seit der letzten relevanten Sicherung
differenzielles Backup enthält Änderungen seit dem letzten Vollbackup
synthetisches Vollbackup wird im Repository aus vorhandenen Sicherungsdaten erzeugt
Snapshot zeitpunktbezogener Zustand eines Volumes oder Dateisystems
crash-konsistent entspricht ungefähr dem Zustand nach einem unerwarteten Ausfall
anwendungskonsistent Anwendung und Datenbank wurden für den Sicherungspunkt koordiniert
Recovery Point für die Wiederherstellung registrierter Sicherungsstand
Repository logischer Speicherbereich für Backups und Metadaten
Retention Aufbewahrungsregel für Recovery Points
Immutability zeitlich begrenzter Schutz vor Änderung oder Löschung
Air Gap logische oder physische Trennung der Sicherung vom Produktivsystem
RPO maximal tolerierbarer Datenverlust in Zeit
RTO maximal tolerierbare Wiederherstellungsdauer
Backupfenster vorgesehener Zeitraum für die Sicherung
Restore-Test kontrollierter Nachweis der Wiederherstellbarkeit

Ein Storage-Snapshot auf demselben System ist allein kein vollständiger Schutz vor Ausfall, Fehlbedienung, Diebstahl oder Ransomware.

7.15.5 Phasen eines Backupjobs

Phase Mögliche Fehler
Planung falscher Zeitplan, deaktivierter Job, verpasster Start
Vorbereitung Konfiguration, Lizenz, Agent oder Dienst fehlerhaft
Authentifizierung Kennwort, Token, Zertifikat oder Schlüssel abgelaufen
Quellenprüfung Pfad, Volume, VM, Datenbank oder Container fehlt
Snapshot VSS-, LVM-, CSI-, Hypervisor- oder Storagefehler
Anwendungskonsistenz Writer, Datenbank oder Quiescing schlägt fehl
Lesen Berechtigung, Sperre, I/O-Fehler oder beschädigte Datei
Transport DNS, Routing, VPN, Firewall, TLS oder Timeout
Schreiben Repository voll, Quota, Schreibschutz oder Berechtigung
Deduplizierung Index-, Cache- oder Metadatenfehler
Katalogisierung Recovery Point wird nicht registriert
Verifikation Prüfsumme oder Strukturprüfung schlägt fehl
Retention alte Recovery Points werden nicht korrekt verarbeitet
Replikation sekundäre oder externe Kopie wird nicht erstellt
Abschluss Jobstatus, Benachrichtigung oder Monitoring ist falsch

Der erste sichtbare Fehler ist nicht immer die ursprüngliche Ursache. Ein später Repositoryfehler kann beispielsweise durch einen vorher fehlgeschlagenen Snapshot ausgelöst worden sein.

7.15.6 Fehlerklassen unterscheiden

Fehlerklasse Typischer Befund
Job nicht gestartet kein Lauf, kein Log oder nur Schedulerfehler
Job deaktiviert Zeitplan vorhanden, Ausführung aber abgeschaltet
falscher Dienstkontext manueller Start funktioniert, geplanter Lauf nicht
Agent nicht erreichbar Backupserver erreicht Client oder Proxy nicht
Quellpfad fehlt Volume, Freigabe, Mount oder PVC nicht vorhanden
Zugriff verweigert Dienstkonto darf Quelle oder Ziel nicht lesen beziehungsweise schreiben
Snapshot fehlgeschlagen VSS-, Hypervisor-, CSI- oder Storagefehler
Anwendung nicht konsistent Datenbank-Writer oder Quiescing fehlerhaft
Repository voll zu wenig Speicher, Quota oder Thin Pool voll
Repository nicht erreichbar DNS-, Netzwerk-, TLS- oder Mountfehler
Repository gesperrt paralleler Job oder verwaister Lock
Sicherungskette beschädigt erforderliches Voll- oder Inkrementbackup fehlt
Retention fehlerhaft alte Daten bleiben bestehen oder benötigte Punkte werden entfernt
Verschlüsselung fehlerhaft Schlüssel, Passwort oder KMS nicht verfügbar
Prüfsummenfehler Daten oder Repository beschädigt
Timeout Job überschreitet Backupfenster oder Netzwerkgrenze
Teilbackup einige Quellen oder Dateien wurden übersprungen
Katalogfehler Daten vorhanden, Recovery Point jedoch nicht nutzbar
Replikation fehlgeschlagen Primärbackup vorhanden, Zweitkopie fehlt
Immutability-Konflikt gewünschte Änderung oder Retention wird blockiert
Lizenz- oder Kapazitätslimit geschützte Systeme oder Datenmenge überschreiten Produktlimit
Sicherheitsvorfall Repository, Zugangsdaten oder Backupserver wurden manipuliert

7.15.7 Typische Symptome und Fehlermeldungen

Backup failed
Job failed
Partial success
Completed with warnings
Missed schedule
Access denied
Authentication failed
Permission denied
Repository unavailable
Repository is full
Quota exceeded
No space left on device
Snapshot creation failed
VSS writer failed
VSS_E_WRITERERROR
Unable to create snapshot
Volume not found
Source path not found
Connection timed out
Connection reset
TLS certificate verify failed
Repository locked
Stale lock
Checksum mismatch
Hash mismatch
Corrupt backup
Index damaged
Catalog update failed
Retention failed
Prune failed
Unable to decrypt
Encryption key not found
Object lock prevents deletion
Backup window exceeded
Incremental chain is broken
Recovery point unavailable
Restore validation failed

Die exakte Meldung einschließlich Fehlercode, Jobphase und Uhrzeit muss übernommen werden.

7.15.8 Sofortmaßnahmen

  1. Fehlermeldung vollständig dokumentieren.
  2. Job-ID, Jobname und Sicherungsprodukt erfassen.
  3. Start- und Endzeit bestimmen.
  4. Letzten erfolgreichen Recovery Point feststellen.
  5. Betroffene Quellen und Ziele bestimmen.
  6. RPO-Verletzung berechnen.
  7. Aktuelle Logs und Ereignisse sichern.
  8. Snapshot- oder VSS-Zustand prüfen.
  9. Repository nicht bereinigen oder entsperren.
  10. Prüfen, ob noch ein Job aktiv ist.
  11. Kapazität und Quota erfassen.
  12. Bei Sicherheitsverdacht Backupserver und Repository schützen.
  13. Ursache nachweisen, bevor der Job erneut gestartet wird.
  14. Nach der Korrektur einen kontrollierten neuen Lauf durchführen.
  15. Wiederherstellbarkeit des neuen Recovery Points testen.

Wiederholte Neustarts eines Backupjobs können:

7.15.9 RPO und aktuelle Schutzlücke bestimmen

Beispiel:

Letzter erfolgreicher Recovery Point:
01.08.2026 22:00 Uhr

Aktueller Zeitpunkt:
02.08.2026 10:00 Uhr

Aktuelle Schutzlücke:
12 Stunden

Vorgesehenes RPO:
4 Stunden

Ergebnis:
RPO ist bereits verletzt.

Zu dokumentieren sind:

Ein erfolgreicher Job nach der Störung beseitigt nicht rückwirkend die bereits entstandene RPO-Verletzung.

7.15.10 Job und Scheduler unter Windows prüfen

Geplanten Task anzeigen:

LESEND

Get-ScheduledTask `
  -TaskName "<Taskname>"

Laufzeitinformationen:

Get-ScheduledTask `
  -TaskName "<Taskname>" |
Get-ScheduledTaskInfo

Wichtige Felder:

State
LastRunTime
LastTaskResult
NextRunTime
NumberOfMissedRuns

Detaillierte Abfrage mit schtasks:

schtasks /query /tn "<Taskpfad-und-Name>" /v /fo LIST /hresult

Zu prüfen sind:

Ein gemapptes Netzlaufwerk der interaktiven Benutzersitzung steht einem geplanten Task nicht automatisch zur Verfügung. Für geplante Jobs sollte der tatsächlich erreichbare UNC-Pfad verwendet werden.

7.15.11 Windows-Task-Scheduler-Ereignisse prüfen

Vorhandene Ereignisse:

Get-WinEvent `
  -LogName "Microsoft-Windows-TaskScheduler/Operational" `
  -MaxEvents 100 |
Select-Object `
  TimeCreated,
  Id,
  LevelDisplayName,
  Message

Das Operational-Protokoll kann deaktiviert sein. Eine Aktivierung ist eine Konfigurationsänderung und muss dokumentiert werden.

Zu korrelieren sind:

7.15.12 Systemd-Timer unter Linux prüfen

Timerübersicht:

LESEND

systemctl list-timers --all

Bestimmten Timer prüfen:

systemctl \
  status backup.timer \
  --no-pager

Zugehörigen Dienst prüfen:

systemctl \
  status backup.service \
  --no-pager

Letzten Exit-Code erfassen:

systemctl show \
  backup.service \
  -p Result \
  -p ExecMainCode \
  -p ExecMainStatus \
  -p ActiveEnterTimestamp \
  -p ActiveExitTimestamp

Protokolle:

journalctl \
  -u backup.timer \
  -u backup.service \
  --since "-24 hours"

Zu prüfen sind:

7.15.13 Cronjobs prüfen

Cronjobs des aktuellen Benutzers:

crontab -l

Cronjobs von root:

sudo crontab -l

Systemweite Konfigurationen können abhängig von der Distribution unter anderem liegen in:

/etc/crontab
/etc/cron.d/
/etc/cron.hourly/
/etc/cron.daily/
/etc/cron.weekly/
/etc/cron.monthly/

Zu prüfen sind:

Ein Skript, das in einer interaktiven Shell funktioniert, muss nicht unter Cron funktionieren.

7.15.14 Quelle und Sicherungsumfang prüfen

Zu erfassen sind:

Linux-Mounts:

findmnt

lsblk \
  -o NAME,TYPE,FSTYPE,SIZE,FSAVAIL,FSUSE%,MOUNTPOINTS

Windows-Volumes:

Get-Volume

Datei- oder Verzeichnisexistenz:

Test-Path `
  -LiteralPath "<Quellpfad>"

Mögliche Fehler:

Ein erfolgreicher Job kann trotzdem unvollständig sein, wenn der Sicherungsumfang falsch definiert ist.

7.15.15 Kapazität, Inodes und Quotas prüfen

Windows

Get-Volume |
  Select-Object `
    DriveLetter,
    FileSystemLabel,
    FileSystem,
    Size,
    SizeRemaining,
    HealthStatus

Linux

df -hT

df -i

macOS

df -h

Zu prüfen sind:

Ein Backup kann trotz freiem Repository fehlschlagen, wenn der lokale Snapshot-, Cache-, Katalog- oder Temp-Bereich voll ist.

7.15.16 Windows Server Backup prüfen

Status eines laufenden Backups:

LESEND

wbadmin get status

Vorhandene Backupversionen:

wbadmin get versions

Verfügbare Datenträger:

wbadmin get disks

Vorhandene Windows-Server-Backup-Dienste:

Get-Service `
  -Name wbengine,VSS,swprv `
  -ErrorAction SilentlyContinue

Backup- und VSS-Ereignisse:

Get-WinEvent `
  -FilterHashtable @{
    LogName = "Application"
    StartTime = (Get-Date).AddHours(-12)
  } |
Where-Object {
  $_.ProviderName -in @(
    "Microsoft-Windows-Backup",
    "VSS"
  )
} |
Select-Object `
  TimeCreated,
  ProviderName,
  Id,
  LevelDisplayName,
  Message

Zu prüfen sind:

wbadmin start backup startet einen neuen Sicherungsvorgang und ist kein rein diagnostischer Befehl.

7.15.17 VSS systematisch prüfen

VSS-Writer unmittelbar nach dem Fehler prüfen:

LESEND

vssadmin list writers

VSS-Provider:

vssadmin list providers

Shadow-Copy-Speicher:

vssadmin list shadowstorage

Vorhandene Shadow Copies:

vssadmin list shadows

Ein gesunder Writer zeigt gewöhnlich:

State: Stable
Last error: No error

Zu prüfen sind:

Ein einzelner fehlerhafter Writer kann den gesamten anwendungskonsistenten Backupjob stoppen.

Der pauschale Neustart aller VSS-Dienste ist keine erste Diagnosemaßnahme. Zuerst muss der betroffene Writer dokumentiert und dem zugehörigen Dienst oder Produkt zugeordnet werden.

7.15.18 Snapshot und Anwendungskonsistenz unterscheiden

Mögliche Sicherungsarten:

Sicherungsart Eigenschaften
Dateikopie im laufenden Betrieb kann bei aktiven Datenbanken inkonsistent sein
crash-konsistenter Snapshot entspricht ungefähr einem ungeplanten Ausfall
anwendungskonsistenter Snapshot Anwendung bestätigt konsistenten Zustand
logisches Datenbankbackup exportiert Daten über Datenbankwerkzeuge
physisches Datenbankbackup sichert Datenbankdateien mit vorgesehenem Verfahren
Hypervisor-Snapshot sichert VM-Zustand, ersetzt aber nicht automatisch ein Backup
Storage-Snapshot liegt häufig auf demselben Storage und benötigt zusätzliche Kopie

Zu prüfen sind:

7.15.19 Netzwerkpfad zum Repository prüfen

Zu bestimmen sind:

Windows

Resolve-DnsName `
  -Name "<Repository-FQDN>"

Test-NetConnection `
  -ComputerName "<Repository-FQDN>" `
  -Port <Port>

SMB-Verbindungen:

Get-SmbConnection

Linux und macOS

getent hosts <Repository-FQDN>

findmnt

HTTPS-Endpunkt:

curl \
  -v \
  https://<Repository-FQDN>/

TLS-Test:

openssl s_client \
  -connect <Repository-FQDN>:<Port> \
  -servername <Repository-FQDN> \
  </dev/null

Zu prüfen sind:

7.15.20 Dienstkonto, Zugangsdaten und Secrets prüfen

Zu erfassen sind:

Typische Fehler:

Zugangsdaten dürfen nicht zur Diagnose in Befehlszeilen, Protokolle oder Tickets geschrieben werden.

7.15.21 Repositoryzustand prüfen

Zu prüfen sind:

Ein Repositorylock kann verursacht werden durch:

Ein Lock darf erst entfernt werden, wenn zweifelsfrei feststeht, dass kein zugehöriger Prozess mehr arbeitet.

7.15.22 Sicherungskette prüfen

Beispiel einer inkrementellen Kette:

Vollbackup
→ Inkrement 1
→ Inkrement 2
→ Inkrement 3

Für die Wiederherstellung können alle benötigten Kettenglieder erforderlich sein.

Beispiel einer differenziellen Sicherung:

Vollbackup
→ aktuelles Differenzialbackup

Zu prüfen sind:

Eine vorhandene letzte Inkrementdatei ist ohne die erforderliche Kette möglicherweise nicht wiederherstellbar.

7.15.23 Retention, Pruning und Immutability prüfen

Retention kann unter anderem festlegen:

Zu prüfen sind:

Immutability kann erklären, warum Speicher nicht freigegeben werden kann. Sie darf nicht deaktiviert werden, um einen Kapazitätsfehler kurzfristig zu umgehen.

7.15.24 Integrität und Prüfsummen unterscheiden

Eine Integritätsprüfung kann bestätigen:

Sie bestätigt nicht automatisch:

Deshalb sind sowohl technische Integritätsprüfungen als auch reale Restore-Tests erforderlich.

7.15.25 Restic-Repository prüfen

Die folgenden Befehle verwenden die bereits sicher konfigurierte Repository- und Kennwortbereitstellung. Kennwörter dürfen nicht direkt in den Befehl geschrieben werden.

Snapshots anzeigen:

LESEND

restic snapshots

Repositorystatistik:

restic stats

Locks anzeigen:

restic list locks

Repositorystruktur prüfen:

LESEND, LASTERZEUGEND

restic check

Repositorydaten vollständig lesen:

LESEND, SEHR LASTERZEUGEND

restic check --read-data

Ein --read-data-Lauf kann das gesamte Repository lesen und muss in das Betriebs- und Backupfenster passen.

Retention vorab simulieren:

LESEND

restic forget \
  --dry-run \
  <vorgesehene-Retention-Optionen>

Wichtige Regeln:

7.15.26 Rsync-Job prüfen

Version:

rsync --version

Trockenlauf:

LESEND, NETZAKTIV, möglicherweise LASTERZEUGEND

rsync \
  --dry-run \
  --itemize-changes \
  <Quelle> \
  <Ziel>

Unmittelbar nach dem Job den Exit-Code ausgeben:

printf '%s\n' "$?"

Wichtige Rsync-Exit-Codes:

Exit-Code Bedeutung
0 erfolgreich
1 Syntax- oder Verwendungsfehler
2 Protokollinkompatibilität
3 Fehler bei Auswahl von Ein- oder Ausgabedateien
5 Client-Server-Protokoll konnte nicht gestartet werden
10 Socket-I/O-Fehler
11 Datei-I/O-Fehler
12 Fehler im Rsync-Protokolldatenstrom
23 teilweise Übertragung wegen Fehler
24 teilweise Übertragung, weil Quelldateien verschwanden
30 Timeout bei Datenübertragung
35 Timeout beim Warten auf Daemonverbindung

Zu prüfen sind:

rsync --delete kann Daten am Ziel löschen. Eine Synchronisation mit --delete ist allein kein versioniertes Backup.

7.15.27 macOS und Time Machine prüfen

Time-Machine-Status:

LESEND

tmutil status

Konfigurierte Ziele:

tmutil destinationinfo

Letztes Backup:

tmutil latestbackup

Vorhandene Backups:

tmutil listbackups

Aktuelle Time-Machine-Protokolle:

log show \
  --predicate 'process == "backupd"' \
  --last 6h \
  --style compact

Speicherzustand:

df -h

Backupvolume:

diskutil info "<Backupvolume>"

Zu prüfen sind:

Netzwerkbasierte Time-Machine-Backups können über das Time-Machine-Menü mit gedrückter Wahltaste und „Backups überprüfen“ verifiziert werden.

Das Löschen oder Neuformatieren des Backupziels ist keine erste Diagnosemaßnahme.

7.15.28 Docker-Backups prüfen

Containerübersicht:

docker ps -a

Volumes:

docker volume ls

Bestimmtes Volume:

docker volume inspect \
  <Volumename>

Containermounts:

docker inspect \
  --format '{{json .Mounts}}' \
  <Containername>

Zu unterscheiden sind:

Wichtige Regeln:

Ein erfolgreicher Export des Containers beweist nicht, dass die persistenten Anwendungsdaten enthalten sind.

7.15.29 Kubernetes-Backupjobs prüfen

CronJobs:

kubectl get cronjobs \
  --all-namespaces

Jobs:

kubectl get jobs \
  --all-namespaces

Bestimmten Job untersuchen:

kubectl describe job \
  <Job> \
  -n <Namespace>

Podlogs:

kubectl logs \
  job/<Job> \
  -n <Namespace>

Ereignisse:

kubectl get events \
  --all-namespaces \
  --sort-by=.metadata.creationTimestamp

PVCs:

kubectl get pvc \
  --all-namespaces

VolumeSnapshots:

kubectl get volumesnapshot \
  --all-namespaces

VolumeSnapshotContents:

kubectl get volumesnapshotcontent

Zu prüfen sind:

Ein Kubernetes-Backup muss je nach Wiederherstellungsziel berücksichtigen:

Ein CSI-VolumeSnapshot ist nicht automatisch anwendungskonsistent und nicht automatisch außerhalb des ursprünglichen Storagebackends geschützt.

7.15.30 Datenbanken korrekt sichern

Aktive Datenbanken dürfen nicht wie gewöhnliche statische Dateien behandelt werden.

Zu unterscheiden sind:

Zu prüfen sind:

7.15.31 PostgreSQL-Backups prüfen

PostgreSQL unterstützt unterschiedliche Verfahren:

Basissicherung prüfen:

LESEND, LASTERZEUGEND

pg_verifybackup \
  <Backupverzeichnis>

Zu prüfen sind:

pg_verifybackup prüft die Struktur und Integrität einer geeigneten Basissicherung, ersetzt aber keinen vollständigen Wiederherstellungstest.

7.15.32 NAS-, SAN- und Storage-Snapshots prüfen

Zu erfassen sind:

Mögliche Fehler:

Ein Snapshot auf demselben NAS oder SAN schützt nicht vor dem vollständigen Ausfall oder der Kompromittierung dieses Systems.

7.15.33 Cloud- und Object-Storage-Ziele prüfen

Zu prüfen sind:

Ein Konto kann Schreibrechte besitzen, aber wegen fehlender List-, Read- oder Delete-Rechte bei Verifikation oder Retention scheitern.

7.15.34 Leistung, Backupfenster und Timeouts prüfen

Zu messen sind:

Mögliche Ursachen:

Ein Job, der das Backupfenster überschreitet, kann vom Scheduler oder Produkt beendet werden, obwohl Quelle und Ziel grundsätzlich funktionieren.

7.15.35 Ransomware- und Manipulationsverdacht

Warnsignale:

Bei begründetem Verdacht:

  1. Incident-Response-Prozess aktivieren.
  2. Beweise sichern.
  3. Repository vor weiteren Veränderungen schützen.
  4. Immutability und Offlinekopien prüfen.
  5. Backupzugangsdaten als möglicherweise kompromittiert behandeln.
  6. Keine normalen Retention- oder Pruningvorgänge starten.
  7. Wiederherstellungspunkt vor dem vermuteten Vorfall bestimmen.
  8. Restore ausschließlich in isolierter Umgebung testen.
  9. Produktivwiederherstellung erst nach Freigabe durchführen.

7.15.36 Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Der geplante Backupjob verwendet ein Dienstkonto,
dessen Kennwort geändert wurde. Deshalb kann der Task
nicht im unbeaufsichtigten Kontext starten.

Erwarteter Befund:
Der Task Scheduler zeigt einen Anmelde- oder
Authentifizierungsfehler.
Der manuelle Start unter einem anderen Konto funktioniert.
Es existiert kein neues Backuplog des eigentlichen Jobs.

Gegenbeweis:
Der Task startet nachweislich unter dem vorgesehenen Konto
und erreicht die erste Phase des Backupjobs.

Testmethode:
Taskstatus, Task-Scheduler-Ereignisse, ausführendes Konto
und Zeitpunkt des letzten Kennwortwechsels vergleichen.

Erfolgskriterium:
Schedulerfehler und Dienstkontoänderung sind zeitlich
und technisch eindeutig zugeordnet.

Eine belastbare Hypothese enthält:

7.15.37 Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko
Zeitplan korrigieren falscher oder deaktivierter Trigger bestätigt doppelter oder unerwarteter Lauf
Dienstkonto korrigieren Konto- oder Anmeldefehler bestätigt Zugriff auf Quelle und Ziel verändert sich
Zugangsdaten erneuern abgelaufenes Secret bestätigt falsches Secret unterbricht weitere Jobs
Quellpfad korrigieren falscher Pfad bestätigt falsche Daten könnten gesichert werden
Ausschlussregel korrigieren fehlende Daten nachgewiesen Backupmenge steigt
VSS-Writer-Ursache beheben fehlerhafter Writer dokumentiert Anwendungsdienst kann unterbrochen werden
Snapshotbereich erweitern Kapazitätsfehler bestätigt Storagebelegung steigt
Repositorykapazität erweitern Repository voll bestätigt falsche Ebene bleibt wirkungslos
Netzwerkregel korrigieren blockierter Pfad bestätigt Sicherheitsgrenze verändert sich
TLS-Zertifikat erneuern Zertifikatsfehler bestätigt falsche Kette oder Bindung
verwaisten Lock entfernen kein aktiver Prozess zweifelsfrei bestätigt Repositorybeschädigung bei Fehlentscheidung
Retention korrigieren fehlerhafte Richtlinie bestätigt Recovery Points können verloren gehen
Pruning ausführen Retention geprüft und Wartungsfenster vorhanden hohe Last und Repositorylock
beschädigte Kette neu aufbauen Kettenschaden bestätigt zusätzlicher Speicher und längeres Fenster
Vollbackup starten inkrementelle Basis unbrauchbar hohe Last und lange Laufzeit
Agent aktualisieren Kompatibilitätsfehler bestätigt Neustart oder Versionskonflikt
Anwendungshook korrigieren Konsistenzfehler bestätigt Anwendung kann beeinflusst werden
Backup erneut starten Ursache behoben und Kapazität vorhanden erneute Last und Snapshotbildung

Vor jeder Maßnahme sind zu dokumentieren:

7.15.38 Maßnahmen, die nicht spontan ausgeführt werden dürfen

Recovery Points manuell aus dem Repository löschen
Repositoryverzeichnisse umbenennen
Repositorylock ungeprüft entfernen
Retention pauschal verkürzen
Immutability deaktivieren
Object Lock umgehen
Pruning während eines aktiven Backups starten
alle Snapshots löschen
VSS-Dienste vor der Beweissicherung neu starten
Datenbankdateien im laufenden Betrieb kopieren
inkrementelle Kettenglieder einzeln löschen
Backupkatalog ohne Herstellervorgabe neu erstellen
Repositorydaten manuell verändern
Verschlüsselungsschlüssel ersetzen
verlorenes Repositorykennwort „zurücksetzen“
Backupziel neu formatieren
Docker-Volume ungeprüft als einfache Dateikopie sichern
Kubernetes-PVC löschen und neu erstellen
Restore direkt über Produktivdaten ausführen
beschädigtes Backup als einzigen Recovery Point behalten

7.15.39 Vollständiger Diagnoseablauf

  1. Fehlermeldung vollständig aufnehmen
    Wortlaut, Fehlercode, Job-ID und Zeitpunkt dokumentieren.

  2. Job und Sicherungsprodukt bestimmen
    Plan, Richtlinie, Agent und Server erfassen.

  3. Auswirkung bestimmen
    Einzelne Quelle, Jobgruppe, Repository oder gesamte Umgebung unterscheiden.

  4. Letzten erfolgreichen Recovery Point bestimmen
    Nicht nur letzten erfolgreichen Prozesslauf prüfen.

  5. RPO-Verletzung berechnen
    Aktuelle Schutzlücke mit Sollwert vergleichen.

  6. Jobphase bestimmen
    Planung, Snapshot, Lesen, Transport, Schreiben oder Abschluss unterscheiden.

  7. Scheduler prüfen
    Trigger, Konto, letzte Ausführung und Exit-Code erfassen.

  8. Backupdienste und Agenten prüfen
    Status und Version dokumentieren.

  9. Logs sichern
    Job-, Betriebssystem-, Anwendungs- und Repositorylogs korrelieren.

  10. Quelle vollständig bestimmen
    Pfade, Volumes, VMs, Container und Datenbanken erfassen.

  11. Ausschlüsse prüfen
    Neue oder versehentlich ausgeschlossene Daten erkennen.

  12. Quellberechtigungen prüfen
    Tatsächlichen Dienstkontext verwenden.

  13. Quellkapazität prüfen
    Freien Speicher, Inodes und Temp-Bereich untersuchen.

  14. Snapshotzustand prüfen
    VSS, Hypervisor, CSI oder Storage-Snapshot unterscheiden.

  15. Anwendungskonsistenz prüfen
    Writer, Hook oder Datenbankverfahren auswerten.

  16. Ziel und Repository bestimmen
    Host, Pfad, Port, Protokoll und Backend erfassen.

  17. Netzwerkpfad prüfen
    DNS, Routing, Firewall, VPN, Proxy und TLS untersuchen.

  18. Zielberechtigungen prüfen
    Schreiben, Lesen, Listen und gegebenenfalls Löschen unterscheiden.

  19. Repositorykapazität prüfen
    Speicher, Quota, Thin Pool, Katalog und Cache berücksichtigen.

  20. Repositorylock prüfen
    Aktive und verwaiste Locks unterscheiden.

  21. Parallele Jobs prüfen
    Backup, Restore, Replication, Retention und Pruning erfassen.

  22. Sicherungskette prüfen
    Vollbackup und erforderliche Folgebackups zuordnen.

  23. Retention und Immutability prüfen
    Aufbewahrung, Object Lock und Legal Hold berücksichtigen.

  24. Verschlüsselung prüfen
    Schlüssel, Kennwort, KMS und Zertifikate erfassen.

  25. Integrität prüfen
    Herstellervorgesehene Repositoryprüfung verwenden.

  26. Performance prüfen
    Dauer, Durchsatz, Latenz, Last und Backupfenster vergleichen.

  27. Sicherheitsverdacht bewerten
    Manipulation, ungewöhnliche Änderungen und fehlende Recovery Points prüfen.

  28. Hypothese und Gegenbeweis formulieren
    Ursache vor der Änderung messbar festlegen.

  29. Eine kontrollierte Maßnahme durchführen
    Risiko, Rückweg und Freigabe beachten.

  30. Job kontrolliert neu starten
    Doppelstarts und parallele Wartung ausschließen.

  31. Jobphasen überwachen
    Snapshot, Übertragung und Abschluss beobachten.

  32. Exit-Code und Warnungen auswerten
    Teilerfolg nicht als Vollerfolg behandeln.

  33. Neuen Recovery Point bestätigen
    Zeit, Umfang und Repository registrieren.

  34. Integritätsprüfung durchführen
    Katalog und Datenblöcke prüfen.

  35. Isolierten Restore-Test durchführen
    Repräsentative Daten oder Anwendung wiederherstellen.

  36. Wiederhergestellte Daten validieren
    Inhalt, Metadaten, Rechte und Anwendung prüfen.

  37. RPO und RTO bewerten
    Tatsächliche Werte dokumentieren.

  38. Sekundärkopie prüfen
    Offsite-, Offline- oder immutable Kopie bestätigen.

  39. Temporäre Änderungen zurücknehmen
    Debuglogging, Testfreigaben und Ausnahmen entfernen.

  40. Ursache dokumentieren
    Technischen Nachweis festhalten.

  41. Prävention festlegen
    Monitoring, Kapazität, Retention oder Jobdesign verbessern.

7.15.40 Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
kein Joblog vorhanden Scheduler oder Prozessstart fehlerhaft Scheduler-Ereignisse
Job startet manuell, geplant aber nicht Dienstkonto, Umgebung oder Rechte Ausführungskontext vergleichen
Task meldet Erfolg, kein Recovery Point Skript wertet Exit-Code falsch aus Unterprozess und Repository prüfen
Quelle fehlt Mount, Volume oder Pfad nicht verfügbar Mount- und Volumezustand
nur neue Verzeichnisse fehlen Ausschluss oder Berechtigung Jobumfang und ACLs
VSS-Writer fehlgeschlagen Anwendungskonsistenz fehlerhaft vssadmin list writers
Snapshot erstellt, Job scheitert später Transport, Repository oder Katalog nächste Jobphase
Repository voll Kapazität, Quota oder Retention Belegung aller Repositoryebenen
Repository hat Platz, Cache ist voll lokaler Stagingbereich erschöpft Quellhost und Proxy prüfen
nur geplanter Netzwerkjob scheitert gemapptes Laufwerk fehlt UNC-Pfad und Dienstkonto
Zugriff verweigert Berechtigung oder geändertes Konto Quell- und Zielrechte
Authentifizierung fehlgeschlagen Kennwort, Token oder Zertifikat Ablauf und Dienstkontext
Repository locked aktiver oder verwaister Prozess Prozesse und Jobhistorie
Inkrementbackup fehlt Kette unterbrochen Vollbackup und Folgepunkte
Retention schlägt fehl Immutability oder fehlendes Löschrecht Richtlinie und Object Lock
Pruning läuft sehr lange Repositorygröße oder Wartungsüberschneidung Prozess und I/O-Last
Rsync Exit-Code 23 teilweise Übertragung vollständige Fehlerausgabe
Rsync Exit-Code 24 Quelldateien verschwanden aktive Anwendung und Dateityp
Dockerexport erfolgreich, Daten fehlen Volume nicht enthalten Mounts und Volumes
Kubernetes-Snapshot nicht readyToUse CSI- oder Storagefehler Snapshotereignisse
Datenbankbackup vorhanden, Restore scheitert Inkonsistenz oder fehlende Logs Datenbankverifikation
Backup erfolgreich, Replikation fehlgeschlagen Zweitkopie fehlt Replikationsjob und Ziel
Backupdauer plötzlich erhöht Datenwachstum, Last oder Netzwerk Baselinevergleich
viele Dateien wurden neu gesichert Verschlüsselung, Zeitstempel oder Anwendung Änderungsursache
Prüfsummenfehler Repository- oder Storagebeschädigung Integritätsprüfung und Hardware
ältere Recovery Points fehlen unerwartet Retentionfehler oder Manipulation Audit- und Repositorylogs
Restore funktioniert, Anwendung nicht Abhängigkeiten oder Konsistenz fehlen vollständiger Anwendungstest

7.15.41 Typische Diagnosefehler

7.15.42 Verifikation und Restore-Test

Nach der Maßnahme müssen mindestens folgende Punkte geprüft werden:

Ein Restore-Test sollte nicht die produktiven Originaldaten überschreiben.

7.15.43 Stufen eines Restore-Tests

Stufe Nachweis
Katalogtest Recovery Point wird angezeigt
Lesetest Sicherungsdaten können gelesen werden
Integritätstest Prüfsummen und Repositorystruktur stimmen
Datei-Restore ausgewählte Dateien werden isoliert wiederhergestellt
Metadatenprüfung Rechte, Eigentümer und Zeitstempel stimmen
Datenbank-Restore Datenbank wird konsistent wiederhergestellt
Anwendungs-Restore Anwendung startet und arbeitet
System-Restore VM, Host oder Dienst wird vollständig wiederhergestellt
DR-Test definierte Notfallumgebung wird innerhalb des RTO aufgebaut

Je kritischer das System ist, desto höher muss die regelmäßig getestete Restore-Stufe sein.

7.15.44 Prävention und Monitoring

Zu überwachen sind:

Ein geeignetes Monitoring alarmiert nicht nur bei Failed, sondern auch bei:

7.15.45 Empfohlene Schutzstruktur

Eine robuste Sicherungsstrategie berücksichtigt mehrere Fehlerdomänen:

Produktivdaten
→ primäres Backuprepository
→ getrennte Zweitkopie
→ unveränderbare oder offline Kopie
→ regelmäßig getestete Wiederherstellung

Zu vermeiden ist:

Produktivdaten
und
einzige Sicherung
auf demselben Host,
demselben Storage Pool
oder mit denselben kompromittierbaren Zugangsdaten

Backups sollten entsprechend Schutzbedarf:

7.15.46 Dokumentationsvorlage

Störung:
<exakte Fehlermeldung>

Zeitpunkt:
<Datum und Uhrzeit>

Sicherungsprodukt:
<Produkt und Version>

Jobname:
<Name>

Job-ID:
<ID>

Betroffene Quelle:
<System, Volume, Pfad, VM, Container oder Datenbank>

Sicherungsziel:
<Repository, Freigabe, Bucket oder Storage>

Geplanter Start:
<Zeitpunkt>

Tatsächlicher Start:
<Zeitpunkt oder nicht gestartet>

Endzeit:
<Zeitpunkt>

Jobphase:
<Planung, Snapshot, Lesen, Transport, Schreiben,
Katalog, Retention oder Replikation>

Exit-Code:
<Wert>

Letzter erfolgreicher Recovery Point:
<Datum und Uhrzeit>

Letzter verifizierter Recovery Point:
<Datum und Uhrzeit>

Aktuelle Schutzlücke:
<Zeit>

Vorgesehenes RPO:
<Zeit>

Vorgesehenes RTO:
<Zeit>

Schedulerzustand:
<Befund>

Dienstkonto:
<Konto ohne Kennwort>

Quellzustand:
<Pfad, Volume, Mount und Berechtigungen>

Snapshotzustand:
<VSS, Hypervisor, CSI oder Storage>

Anwendungskonsistenz:
<Befund>

Netzwerkpfad:
<DNS, Ziel-IP, Port und Protokoll>

Repositoryzustand:
<Kapazität, Quota, Lock und Integrität>

Sicherungskette:
<Vollbackup und Abhängigkeiten>

Retention und Immutability:
<Befund>

Verschlüsselung:
<Verfahren und Schlüsselverfügbarkeit>

Nachgewiesene Ursache:
<technischer Befund>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

Durchgeführte Maßnahme:
<genaue Änderung>

Risiko und Rückweg:
<Beschreibung>

Neuer Recovery Point:
<Datum, Uhrzeit und ID>

Integritätsprüfung:
<Ergebnis>

Restore-Test:
<Ziel, Umfang und Ergebnis>

Tatsächliches RPO:
<Wert>

Tatsächliches RTO:
<Wert>

Prävention:
<Monitoring, Kapazität, Retention oder Prozessänderung>

7.15.47 Checkliste

7.15.48 Schnellreferenz

Aufgabe Befehl
Windows-Task Get-ScheduledTask -TaskName "<Taskname>"
Windows-Task-Laufzeit Get-ScheduledTask -TaskName "<Taskname>" | Get-ScheduledTaskInfo
detaillierte Taskabfrage schtasks /query /tn "<Task>" /v /fo LIST /hresult
Windows-Backupstatus wbadmin get status
Windows-Backupversionen wbadmin get versions
Windows-Backupdatenträger wbadmin get disks
VSS-Writer vssadmin list writers
VSS-Provider vssadmin list providers
VSS-Speicher vssadmin list shadowstorage
Windows-Volumes Get-Volume
Systemd-Timer systemctl list-timers --all
Backup-Service systemctl status backup.service
Backup-Service-Logs journalctl -u backup.service --since "-24 hours"
Benutzer-Cronjobs crontab -l
Root-Cronjobs sudo crontab -l
Linux-Speicher df -hT
Linux-Inodes df -i
Linux-Mounts findmnt
Rsync-Trockenlauf rsync --dry-run --itemize-changes <Quelle> <Ziel>
Restic-Snapshots restic snapshots
Restic-Statistik restic stats
Restic-Locks restic list locks
Restic-Prüfung restic check
Time-Machine-Status tmutil status
Time-Machine-Ziel tmutil destinationinfo
letztes Time-Machine-Backup tmutil latestbackup
Docker-Volumes docker volume ls
Docker-Volume untersuchen docker volume inspect <Volume>
Kubernetes-CronJobs kubectl get cronjobs --all-namespaces
Kubernetes-Jobs kubectl get jobs --all-namespaces
Kubernetes-PVCs kubectl get pvc --all-namespaces
Kubernetes-Snapshots kubectl get volumesnapshot --all-namespaces
PostgreSQL-Basissicherung prüfen pg_verifybackup <Backupverzeichnis>

7.15.49 Quellen

Offizielle Microsoft-Dokumentation

Offizielle Linux- und Projektdokumentation

Offizielle Docker-Dokumentation

Offizielle Kubernetes-Dokumentation

Offizielle PostgreSQL-Dokumentation

Offizielle Apple-Dokumentation

Offizielle Sicherheitsempfehlungen

Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.

8. Betriebssystem- und Serveranalyse

8. Betriebssystem- und Serveranalyse

8.1 Windows-Prozesse und Dienste gezielt untersuchen

Kurzbeschreibung

Wenn ein Windows-System langsam reagiert, eine Anwendung nicht startet, ein Dienst ausfällt oder ein Prozess ungewöhnliche Ressourcen verbraucht, muss der verursachende Prozess einschließlich seiner Abhängigkeiten untersucht werden.

Windows-Bordmittel und die Microsoft-Sysinternals-Werkzeuge ermöglichen unter anderem die Analyse von:

Ein auffälliger Prozess ist nicht automatisch die eigentliche Ursache. Er kann selbst auf eine Datei, eine Sperre, einen Treiber, eine Datenbank, das Netzwerk oder einen anderen Dienst warten.

1. Typische Symptome

2. Mögliche Auswirkungen

3. Sicherheits- und Betriebswarnung

Sysinternals-Werkzeuge können tiefgehende Informationen über Prozesse, Benutzer, Dateien und Netzwerkverbindungen anzeigen. Diagnoseergebnisse können enthalten:

Besondere Vorsicht gilt bei:

Ein vollständiges Speicherabbild kann sensible Daten wie Kennwörter, Tokens, Schlüssel oder Anwendungsdaten enthalten. Dump-, ETL- und PML-Dateien müssen deshalb geschützt gespeichert und nach Abschluss der Analyse kontrolliert gelöscht werden.

Werkzeuge sollten nur aus der offiziellen Microsoft-Quelle bezogen werden. Vor dem Einsatz auf einem Produktivsystem sind Auswirkung, benötigter Speicherplatz und mögliche Leistungseinflüsse zu prüfen.

4. Werkzeugauswahl

Fragestellung Geeignetes Werkzeug
Welcher Prozess benötigt CPU oder RAM? Task-Manager, Ressourcenmonitor, PowerShell, Process Explorer
Welcher Dienst gehört zu einem Prozess? Task-Manager, tasklist /svc, Process Explorer
Welcher Prozess hat eine Datei geöffnet? Ressourcenmonitor, Handle, Process Explorer
Welche DLLs hat ein Prozess geladen? Process Explorer, ListDLLs
Warum erhält eine Anwendung „Zugriff verweigert“? Process Monitor, AccessChk
Welcher Prozess stellt eine Netzwerkverbindung her? TCPView, Get-NetTCPConnection
Was wird beim Systemstart automatisch geladen? Autoruns
Warum stürzt eine Anwendung ab? Ereignisanzeige, Zuverlässigkeitsverlauf, ProcDump, WinDbg
Warum reagiert ein Prozess nicht mehr? Process Explorer, ProcDump, Wait-Chain-Analyse
Welcher Prozess erzeugt Registry- oder Dateisystemzugriffe? Process Monitor
Warum ist das System zeitweise langsam? Leistungsüberwachung, WPR und WPA
Wie hängen Prozesse zusammen? Process Explorer
Welche Prozesse sind signiert? Process Explorer, Sigcheck
Welche Berechtigung besitzt ein Benutzer oder Dienst? AccessChk, whoami

5. Benötigte Informationen

Vor der Diagnose sollten mindestens folgende Informationen vorliegen:

Computer:
Betriebssystem und Build:
betroffene Anwendung:
betroffener Dienst:
Prozessname:
Prozess-ID:
Benutzerkonto des Prozesses:
Beginn des Problems:
exakte Fehlermeldung:
Fehlercode oder Event-ID:
reproduzierbar:
letzter funktionierender Zeitpunkt:
letzte Änderung:
betroffene Benutzer:
Auswirkung:
bereits durchgeführte Maßnahmen:

Zusätzlich hilfreich:

6. Ausgangszustand sichern

Vor einem Neustart oder dem Beenden eines Prozesses sollten flüchtige Informationen dokumentiert werden.

Get-Date

Get-ComputerInfo |
    Select-Object WindowsProductName,
                  WindowsVersion,
                  OsBuildNumber,
                  OsLastBootUpTime

Laufende Prozesse sichern:

Get-Process |
    Sort-Object ProcessName |
    Select-Object ProcessName,
                  Id,
                  CPU,
                  WorkingSet64,
                  Handles,
                  Threads

Laufende Dienste sichern:

Get-Service |
    Where-Object Status -eq 'Running' |
    Sort-Object Name

Aktive TCP-Verbindungen sichern:

Get-NetTCPConnection |
    Select-Object LocalAddress,
                  LocalPort,
                  RemoteAddress,
                  RemotePort,
                  State,
                  OwningProcess

Ereignisse der letzten zwei Stunden:

Get-WinEvent -FilterHashtable @{
    LogName   = 'System', 'Application'
    StartTime = (Get-Date).AddHours(-2)
} |
    Select-Object TimeCreated,
                  LogName,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  Message

Die Ausgabe kann bei Bedarf kontrolliert in Dateien exportiert werden. Dabei sind Datenschutz und Speicherort zu beachten.

7. Sichere Schnellprüfung

  1. Exakte Fehlermeldung und Uhrzeit dokumentieren.
  2. Prozess- und Dienststatus prüfen.
  3. CPU, Arbeitsspeicher, Handles und Threads vergleichen.
  4. System- und Anwendungsereignisse zum Fehlerzeitpunkt untersuchen.
  5. Mit Process Explorer Prozessbaum und Eigenschaften prüfen.
  6. Mit Process Monitor nur den betroffenen Prozess aufzeichnen.
  7. Netzwerkverbindungen mit TCPView oder PowerShell prüfen.
  8. Erst nach gesicherter Diagnose eine kontrollierte Maßnahme durchführen.

8. Prozesse mit PowerShell untersuchen

Alle Prozesse anzeigen:

Get-Process

Prozesse nach CPU-Gesamtzeit sortieren:

Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 15 ProcessName,
                            Id,
                            CPU,
                            WorkingSet64,
                            Handles,
                            Threads

Prozesse nach Arbeitsspeicher sortieren:

Get-Process |
    Sort-Object WorkingSet64 -Descending |
    Select-Object -First 15 ProcessName,
                            Id,
                            WorkingSet64,
                            PagedMemorySize64,
                            VirtualMemorySize64

Prozesse mit vielen Handles:

Get-Process |
    Sort-Object Handles -Descending |
    Select-Object -First 15 ProcessName,
                            Id,
                            Handles

Bestimmten Prozess untersuchen:

Get-Process -Id <PID> |
    Format-List *

Prozess mit CIM einschließlich Befehlszeile und Elternprozess:

Get-CimInstance Win32_Process |
    Where-Object ProcessId -eq <PID> |
    Select-Object Name,
                  ProcessId,
                  ParentProcessId,
                  ExecutablePath,
                  CommandLine,
                  CreationDate

Der Wert CPU bei Get-Process ist die seit dem Prozessstart verbrauchte Prozessorzeit und keine momentane prozentuale CPU-Auslastung.

9. Prozess-ID und Dienst zuordnen

Eine Prozess-ID kann sich nach jedem Neustart des Prozesses ändern. Bei der Dokumentation müssen deshalb PID, Zeitpunkt und Prozessstart zusammen betrachtet werden.

Windows-Befehl:

tasklist /svc

Bestimmte PID suchen:

tasklist /svc /fi "PID eq <PID>"

Dienste einschließlich Prozess-ID:

Get-CimInstance Win32_Service |
    Select-Object Name,
                  DisplayName,
                  State,
                  StartMode,
                  ProcessId,
                  StartName

Dienst zu einer PID suchen:

Get-CimInstance Win32_Service |
    Where-Object ProcessId -eq <PID> |
    Select-Object Name,
                  DisplayName,
                  State,
                  StartMode,
                  StartName

Mehrere Windows-Dienste können innerhalb desselben svchost.exe-Prozesses ausgeführt werden. Der Prozessname allein reicht deshalb nicht zur eindeutigen Zuordnung.

10. Dienste untersuchen

Alle Dienste:

Get-Service |
    Sort-Object Status, Name

Automatisch startende, aber nicht laufende Dienste:

Get-CimInstance Win32_Service |
    Where-Object {
        $_.StartMode -eq 'Auto' -and
        $_.State -ne 'Running'
    } |
    Select-Object Name,
                  DisplayName,
                  State,
                  StartMode,
                  StartName,
                  ExitCode

Bestimmten Dienst prüfen:

Get-Service -Name <Dienstname>

Ausführliche Dienstkonfiguration:

sc.exe qc <Dienstname>

Aktuellen Dienststatus:

sc.exe queryex <Dienstname>

Abhängigkeiten anzeigen:

Get-Service -Name <Dienstname> -DependentServices
Get-Service -Name <Dienstname> -RequiredServices

Zu prüfen sind:

Ein Dienst darf nicht allein deshalb gestartet werden, weil sein Starttyp auf „Automatisch“ steht. Verzögert gestartete Dienste, Triggerstart, Clustersteuerung oder bewusst deaktivierte Komponenten müssen berücksichtigt werden.

11. Ereignisanzeige untersuchen

Wichtige Protokollbereiche:

Fehler und Warnungen der letzten zwei Stunden:

Get-WinEvent -FilterHashtable @{
    LogName   = 'System', 'Application'
    Level     = 2, 3
    StartTime = (Get-Date).AddHours(-2)
} |
    Select-Object TimeCreated,
                  LogName,
                  Id,
                  ProviderName,
                  LevelDisplayName,
                  Message

Ereignisse eines bestimmten Anbieters:

Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = '<Provider>'
    StartTime    = (Get-Date).AddHours(-2)
}

Ereignisse eines bestimmten Zeitraums:

$Start = Get-Date '2026-08-02 09:00:00'
$Ende  = Get-Date '2026-08-02 10:00:00'

Get-WinEvent -FilterHashtable @{
    LogName   = 'System', 'Application'
    StartTime = $Start
    EndTime   = $Ende
}

Wichtige Grundregel:

Zuerst nach Zeitpunkt, betroffener Komponente und technischer Wirkung filtern. Nicht jeder Fehler oder jede Warnung in der Ereignisanzeige gehört zur untersuchten Störung.

12. Dienstfehler im Systemprotokoll

Der Service Control Manager protokolliert Start-, Stopp- und Dienstfehler im Systemprotokoll.

Beispielhafte Abfrage:

Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Service Control Manager'
    StartTime    = (Get-Date).AddHours(-4)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  Message

Häufig relevante Ereignisarten betreffen:

Event-IDs dürfen nicht ohne Prüfung von Provider, Windows-Version und vollständigem Ereignistext interpretiert werden.

13. Process Explorer verwenden

Process Explorer zeigt Prozesse hierarchisch in einem Prozessbaum an.

Wichtige Informationen:

Empfohlene Vorgehensweise:

  1. Process Explorer als Administrator starten, wenn erhöhte Prozesse untersucht werden müssen.
  2. View → Show Process Tree verwenden.
  3. Unter View → Select Columns benötigte Spalten aktivieren.
  4. Betroffenen Prozess markieren.
  5. Eigenschaften des Prozesses öffnen.
  6. Image, Performance, Threads, TCP/IP und Security prüfen.
  7. Prozesspfad und digitale Signatur kontrollieren.
  8. Eltern- und Kindprozesse dokumentieren.
  9. Auffällige Threads oder Handles untersuchen.
  10. Prozess erst nach Sicherung der Ergebnisse verändern.

Hilfreiche Markierungen im Prozessbaum können auf unterschiedliche Prozessarten oder Lebenszyklen hinweisen. Die Farbdarstellung ist konfigurierbar und darf nicht ohne Prüfung der eingestellten Farblegende interpretiert werden.

14. Threads untersuchen

Ein Prozess kann insgesamt unauffällig erscheinen, obwohl ein einzelner Thread dauerhaft einen CPU-Kern beansprucht.

In Process Explorer:

  1. Prozess öffnen.
  2. Registerkarte Threads auswählen.
  3. Threads nach CPU-Auslastung sortieren.
  4. Thread-ID und Startadresse dokumentieren.
  5. bei verfügbaren Symbolen den Stack untersuchen.
  6. geladenes Modul oder zugehörige DLL bestimmen.

Mögliche Befunde:

Befund Mögliche Bedeutung
ein Thread dauerhaft stark ausgelastet Endlosschleife oder Single-Thread-Engpass
viele Threads entstehen fortlaufend Thread-Leak oder fehlerhafte Parallelisierung
Thread wartet lange Datei, Netzwerk, Lock oder externe Komponente
Startadresse gehört zu Drittanbieter-DLL Anwendung oder Erweiterung untersuchen
Startadresse gehört zu Sicherheitssoftware Scan oder Filtertreiber als mögliche Beteiligung prüfen
Prozess hat ungewöhnlich viele Threads Worker-Konfiguration, Deadlock oder fehlerhafte Anwendung

Das Beenden eines einzelnen Threads kann den Prozess beschädigen und ist keine sichere Standardmaßnahme.

15. Nicht reagierende Anwendungen und Wait Chains

Eine Anwendung kann als „Keine Rückmeldung“ erscheinen, wenn ihr Oberflächenthread nicht rechtzeitig auf Windows-Nachrichten reagiert.

Mögliche Ursachen:

Im Ressourcenmonitor kann über die CPU-Ansicht bei einem Prozess die Warteschlange beziehungsweise Wait Chain analysiert werden.

Ein möglicher Deadlock liegt vor, wenn mehrere Threads oder Prozesse gegenseitig auf Ressourcen warten. Die Wait-Chain-Analyse liefert einen Hinweis, aber nicht immer einen vollständigen Ursachennachweis.

Vor dem Beenden eines wartenden Prozesses sollten Dump, Ereignisse und Anwendungslogs gesichert werden.

16. Geöffnete Dateien und Handles untersuchen

Eine Datei kann nicht gelöscht oder umbenannt werden, wenn ein Prozess ein passendes Handle geöffnet hält.

Process Explorer:

  1. Find → Find Handle or DLL öffnen.
  2. Teil des Datei- oder Verzeichnisnamens eingeben.
  3. gefundenen Prozess und Handle-Typ prüfen.
  4. Anwendung möglichst regulär schließen.
  5. erst danach einen kontrollierten Prozess- oder Dienstneustart erwägen.

Handle als Kommandozeilenwerkzeug:

handle.exe "<Dateiname-oder-Pfad>"

Nach PID filtern:

handle.exe -p <PID>

Das direkte Schließen eines Handles kann:

Ein Handle sollte deshalb nicht als erste Maßnahme erzwungen geschlossen werden.

17. Geladene DLLs untersuchen

Process Explorer kann im unteren Fensterbereich Handles oder geladene DLLs anzeigen.

Umschalten:

View → Lower Pane View → DLLs

Zu prüfen sind:

ListDLLs:

listdlls.exe <Prozessname>

Nach einer bestimmten DLL suchen:

listdlls.exe -d <DLL-Name>

Eine unbekannte oder nicht signierte DLL ist nicht automatisch Schadsoftware. Sie muss anhand von Pfad, Hersteller, Signatur, Hash, Installationszusammenhang und Sicherheitsprüfung bewertet werden.

18. Process Monitor verwenden

Process Monitor zeichnet in Echtzeit unter anderem folgende Ereignisse auf:

Da sehr viele Ereignisse entstehen können, muss die Aufzeichnung gefiltert und zeitlich begrenzt werden.

Empfohlener Ablauf:

  1. Process Monitor starten.
  2. Aufzeichnung zunächst anhalten.
  3. vorhandene Ereignisse leeren.
  4. Filter für den betroffenen Prozess setzen.
  5. nur benötigte Ereignisklassen aktivieren.
  6. Aufzeichnung starten.
  7. Fehler genau einmal reproduzieren.
  8. Aufzeichnung sofort anhalten.
  9. Ereignisse rund um den Fehlerzeitpunkt untersuchen.
  10. Aufzeichnung geschützt speichern oder nach Abschluss löschen.

Beispielhafte Filter:

Process Name is <Anwendung.exe> then Include

oder:

PID is <PID> then Include

Zusätzliche Filter können beispielsweise betreffen:

Result is ACCESS DENIED
Result is NAME NOT FOUND
Result is PATH NOT FOUND
Operation is CreateFile
Operation is RegOpenKey

19. Process-Monitor-Ergebnisse bewerten

Häufige Ergebnisse:

Ergebnis Bedeutung
SUCCESS Operation wurde erfolgreich ausgeführt
NAME NOT FOUND Objekt mit diesem Namen wurde nicht gefunden
PATH NOT FOUND Teil des Pfades wurde nicht gefunden
ACCESS DENIED Zugriff wurde durch Berechtigung oder Sicherheitsmechanismus verweigert
SHARING VIOLATION Objekt wird in nicht kompatibler Weise verwendet
BUFFER OVERFLOW häufig normaler Teil einer Größenabfrage
NO MORE FILES Verzeichnisaufzählung ist beendet
REPARSE Pfad wurde über einen Reparse Point weitergeleitet

Nicht jeder rote oder fehlgeschlagene Eintrag ist ein Fehler. Anwendungen prüfen häufig mehrere mögliche Pfade, Registry-Schlüssel oder Dateinamen, bevor sie den tatsächlich vorhandenen Eintrag verwenden.

Ein relevanter Befund entsteht erst, wenn:

20. „Zugriff verweigert“ untersuchen

Mögliche Ursachen:

Aktuelle Identität:

whoami

Gruppen und Sicherheitskennungen:

whoami /groups

Privilegien:

whoami /priv

Effektive NTFS-Berechtigungen sollten mit den Windows-Sicherheitseinstellungen oder einem kontrollierten Werkzeug geprüft werden.

AccessChk-Beispiel:

accesschk.exe -nobanner -v "<Benutzer>" "<Pfad>"

Die genaue Syntax ist vor dem produktiven Einsatz anhand der aktuellen Microsoft-Dokumentation zu prüfen.

Die dauerhafte Ausführung einer Anwendung als Administrator ist keine fachgerechte Standardlösung. Stattdessen muss die konkret fehlende Berechtigung identifiziert und nach dem Minimalprinzip vergeben werden.

21. Netzwerkverbindungen einem Prozess zuordnen

PowerShell:

Get-NetTCPConnection |
    Sort-Object State, RemoteAddress |
    Select-Object LocalAddress,
                  LocalPort,
                  RemoteAddress,
                  RemotePort,
                  State,
                  OwningProcess

Verbindungen eines bestimmten Prozesses:

Get-NetTCPConnection |
    Where-Object OwningProcess -eq <PID>

Prozess zuordnen:

Get-Process -Id <PID>

TCPView zeigt:

Zu prüfen sind:

Eine unbekannte Verbindung ist nicht automatisch bösartig. DNS, CDN, Update-, Telemetrie-, Lizenz- und Cloud-Dienste können externe Ziele verwenden. Der Zusammenhang muss geprüft werden.

22. Listener und Portkonflikte untersuchen

Lauschende TCP-Ports:

Get-NetTCPConnection -State Listen |
    Sort-Object LocalPort |
    Select-Object LocalAddress,
                  LocalPort,
                  OwningProcess

Prozess zu einem Port suchen:

Get-NetTCPConnection -LocalPort <Port> |
    Select-Object LocalAddress,
                  LocalPort,
                  State,
                  OwningProcess

Mit klassischem Windows-Befehl:

netstat -ano

Mögliche Befunde:

Befund Mögliche Bedeutung
erwarteter Port fehlt Dienst läuft nicht oder bindet nicht
Port nur an 127.0.0.1 gebunden nur lokaler Zugriff möglich
Port an unerwartete Adresse gebunden Konfiguration prüfen
andere PID verwendet den Port Portkonflikt
viele Verbindungen in SYN_SENT Ziel oder Netzwerk antwortet nicht
viele Verbindungen in TIME_WAIT hohe Verbindungsrate oder fehlendes Connection-Reuse
viele Verbindungen in CLOSE_WAIT Anwendung schließt empfangene Verbindungen nicht korrekt
Listener vorhanden, Zugriff scheitert Firewall, TLS, Anwendung oder Rückweg prüfen

23. Autostarts mit Autoruns untersuchen

Autoruns zeigt deutlich mehr Autostartorte als der Task-Manager.

Zu den möglichen Kategorien gehören:

Empfohlene Vorgehensweise:

  1. Autoruns als Administrator starten.
  2. vollständige Erfassung abwarten.
  3. Microsoft-Einträge bei Bedarf ausblenden, ohne sie zu löschen.
  4. nach nicht vorhandenen Dateien suchen.
  5. Publisher und Signatur prüfen.
  6. Eintrag, Pfad und Kategorie dokumentieren.
  7. verdächtigen Eintrag zunächst deaktivieren statt löschen.
  8. Neustart- oder Anmeldetest kontrolliert durchführen.
  9. bei ausbleibender Wirkung Eintrag wieder aktivieren.

Ein nicht signierter Autostarteintrag ist nicht automatisch Schadsoftware. Herkunft, Pfad, Hash, Installationszeitpunkt und Sicherheitsmeldungen müssen gemeinsam bewertet werden.

24. Digitale Signaturen mit Sigcheck prüfen

Beispiel:

sigcheck.exe -nobanner -a -h "<Pfad-zur-Datei>"

Mögliche Prüfpunkte:

Eine gültige Signatur beweist, dass die Datei seit der Signierung nicht unbemerkt verändert wurde und zu welchem Zertifikat sie gehört. Sie beweist nicht automatisch, dass die Software erwünscht, fehlerfrei oder für den konkreten Einsatzzweck sicher ist.

Online-Prüfungen oder Uploads zu externen Diensten dürfen nur unter Beachtung von Datenschutz, Geheimhaltung und Unternehmensrichtlinien durchgeführt werden.

25. Abstürze und Hänger mit ProcDump erfassen

ProcDump kann Speicherabbilder unter bestimmten Bedingungen erzeugen, beispielsweise bei:

Manuelles vollständiges Speicherabbild:

procdump.exe -accepteula -ma <PID> "<Zielverzeichnis>"

Dump bei unbehandelter Ausnahme:

procdump.exe -accepteula -e -ma <Prozessname.exe> "<Zielverzeichnis>"

Dump bei nicht reagierendem Fenster:

procdump.exe -accepteula -h -ma <Prozessname.exe> "<Zielverzeichnis>"

Vor dem Einsatz muss geprüft werden:

Ein Dump ist noch keine Fehlerdiagnose. Er muss mit Symbolen und geeigneten Debugwerkzeugen analysiert werden.

26. Windows Performance Recorder und Analyzer

Für komplexe oder nur zeitweise auftretende Leistungsprobleme können Windows Performance Recorder und Windows Performance Analyzer eingesetzt werden.

WPR erfasst ETW-Ereignisse. WPA stellt die erfassten Daten als Tabellen und Diagramme dar.

Typische Analysebereiche:

Grundsätzlicher Ablauf:

  1. geeignetes WPR-Profil auswählen.
  2. Speicherplatz und Aufzeichnungsmodus prüfen.
  3. Aufzeichnung starten.
  4. Problem reproduzieren.
  5. Aufzeichnung unmittelbar danach stoppen.
  6. ETL-Datei geschützt speichern.
  7. Datei mit WPA öffnen.
  8. Zeitraum des Fehlers markieren.
  9. Prozess, Thread und Ressource korrelieren.
  10. Aufzeichnung nach Abschluss kontrolliert archivieren oder löschen.

Eine ETW-Aufzeichnung kann groß werden und das System zusätzlich belasten. Profil, Dauer und Detailgrad müssen deshalb begrenzt werden.

27. Prozesse sicher beenden oder neu starten

Ein Prozess darf erst beendet werden, wenn geklärt wurde:

Kontrolliertes Beenden ohne Erzwingen:

Stop-Process -Id <PID> -WhatIf

-WhatIf zeigt nur die geplante Aktion.

Erst nach Prüfung:

Stop-Process -Id <PID>

Erzwungenes Beenden:

Stop-Process -Id <PID> -Force

-Force erhöht das Risiko von Datenverlust oder inkonsistenten Zuständen und sollte nur bei begründetem Bedarf verwendet werden.

Bei Diensten ist ein kontrollierter Dienstneustart in der Regel besser als das direkte Beenden des zugehörigen Prozesses:

Restart-Service -Name <Dienstname> -WhatIf

Danach:

Restart-Service -Name <Dienstname>

28. Befundmatrix

Befund Bedeutung Nächster Test
Prozess beansprucht dauerhaft einen Kern einzelner Thread möglicherweise ausgelastet Threads und Stack in Process Explorer prüfen
Working Set hoch, aber stabil möglicherweise normaler Cache Private Bytes und zeitliche Entwicklung prüfen
Private Bytes wachsen dauerhaft mögliches Speicherleck Verlauf erfassen und Dump erstellen
Handle-Anzahl wächst dauerhaft mögliches Handle-Leak Handle-Typen und geöffnete Objekte prüfen
Thread-Anzahl wächst dauerhaft mögliches Thread-Leak Threaderzeugung und Anwendung untersuchen
viele ACCESS DENIED unmittelbar vor Fehler Berechtigungsproblem möglich Identität und effektive Rechte prüfen
NAME NOT FOUND, danach SUCCESS normale Suchlogik möglich erfolgreichen Zielpfad bestimmen
PATH NOT FOUND ohne erfolgreichen Ersatz fehlender Pfad oder fehlerhafte Konfiguration Anwendungskonfiguration prüfen
Datei ist gesperrt Prozess hält Handle offen Handle-Suche durchführen
Dienst beendet sich wiederholt Anwendung, Abhängigkeit oder Dienstkonto Ereignisse und Anwendungslog prüfen
Dienst bleibt bei „Wird gestartet“ Initialisierung oder Abhängigkeit hängt Wait Chain, Netzwerk und Logs prüfen
Port wird von anderer PID verwendet Portkonflikt Prozess und Konfiguration identifizieren
viele Verbindungen in CLOSE_WAIT Anwendung schließt Verbindungen nicht Anwendung und Verbindungspool prüfen
unbekannte DLL geladen Erweiterung oder mögliche Manipulation Pfad, Signatur, Hash und Herkunft prüfen
Fehler nur nach Anmeldung Autostart oder Benutzerkonfiguration Autoruns und Benutzerprofil prüfen
Fehler nur nach Update Versions- oder Kompatibilitätsproblem Änderungsverlauf und Herstellerhinweise
Prozess stürzt ohne sichtbare Meldung ab Ausnahme oder externe Beendigung Ereignisse, WER und ProcDump
Problem nur unter Dienstkonto Berechtigung oder Benutzerumgebung Identität, Rechte und Pfade vergleichen
Anwendung funktioniert nur erhöht fehlende Berechtigung oder falscher Speicherort Process Monitor und AccessChk
mehrere Prozesse gleichzeitig auffällig gemeinsame Abhängigkeit Storage, Netzwerk, Sicherheitssoftware
nach Neustart vorübergehend behoben Zustand zurückgesetzt, Ursache unbekannt Langzeitmessung und Dump-Trigger

29. Typische Ursachen und passende Maßnahmen

Ursache: fehlerhafter oder blockierter Prozess

Nachweis:

Mögliche Maßnahme:

Rollback:

Verifikation:

Ursache: fehlende Berechtigung

Nachweis:

Mögliche Maßnahme:

Rollback:

Verifikation:

Ursache: fehlende Datei oder fehlerhafter Pfad

Nachweis:

Mögliche Maßnahme:

Rollback:

Verifikation:

Ursache: fehlerhafte Erweiterung oder DLL

Nachweis:

Mögliche Maßnahme:

Rollback:

Verifikation:

Ursache: fehlerhafter Autostarteintrag

Nachweis:

Mögliche Maßnahme:

Rollback:

Verifikation:

Ursache: Portkonflikt

Nachweis:

Mögliche Maßnahme:

Rollback:

Verifikation:

Ursache: Ressourcen- oder Handle-Leak

Nachweis:

Mögliche Maßnahme:

Rollback:

Verifikation:

30. Nachkontrolle

Nach einer Maßnahme sind dieselben Kriterien erneut zu prüfen:

31. Dokumentation

Beispiel:

Symptom:
Der Dienst „Beispieldienst“ wurde nach dem Start innerhalb
weniger Sekunden wieder beendet.

Zeitpunkt:
02.08.2026, 09:42 Uhr MESZ

Nachweis:
Das Anwendungsprotokoll zeigte den Fehler zum gleichen Zeitpunkt.
Process Monitor zeigte unmittelbar davor einen relevanten Zugriff
auf C:\ProgramData\Beispiel\config.json mit ACCESS DENIED.

Ursache:
Das verwendete Dienstkonto besaß nach einer Änderung keine
Leseberechtigung mehr für die Konfigurationsdatei.

Maßnahme:
Die erforderliche Leseberechtigung wurde ausschließlich für
das vorgesehene Dienstkonto wiederhergestellt.

Rollback:
Dokumentierte Berechtigungsänderung kann entfernt werden.

Verifikation:
Dienst startet erfolgreich.
Anwendungsport ist erreichbar.
Keine neuen Fehler im Ereignisprotokoll.
Funktionstest erfolgreich.

Prävention:
Berechtigungen des Anwendungsverzeichnisses werden künftig
vor und nach Änderungen automatisiert verglichen.

32. Entscheidungsbaum

Windows-Anwendung oder Dienst funktioniert nicht
        ↓
Läuft der erwartete Prozess?
        ├── Nein
        │   ↓
        │   Dienststatus, Ereignisse, Autostart,
        │   Datei, Dienstkonto und Abhängigkeiten prüfen
        │
        └── Ja
            ↓
Reagiert der Prozess?
        ├── Nein
        │   ↓
        │   Wait Chain, Threads, Dump und Abhängigkeiten prüfen
        │
        └── Ja
            ↓
Sind Ressourcen auffällig?
        ├── Ja
        │   ↓
        │   CPU, RAM, Handles, Threads und I/O untersuchen
        │
        └── Nein
            ↓
Fehler bei Datei oder Registry?
        ├── Ja
        │   ↓
        │   Process Monitor, Pfade und Berechtigungen prüfen
        │
        └── Nein
            ↓
Netzwerk oder externer Dienst beteiligt?
        ├── Ja
        │   ↓
        │   TCPView, Port, DNS und Zielsystem prüfen
        │
        └── Nein
            ↓
Anwendungslog, Erweiterungen, DLLs und Dump untersuchen

33. Typische Prüfungsfragen

Warum ist ein Prozess mit hoher CPU-Auslastung nicht automatisch die Fehlerursache?

Antwort anzeigen

Die CPU-Auslastung kann für die ausgeführte Aufgabe normal sein oder als Folge eines anderen Problems entstehen. Zeitpunkt, Threadaktivität, Anwendungssymptom und weitere Abhängigkeiten müssen gemeinsam untersucht werden.

Worin unterscheiden sich Task-Manager und Process Explorer?

Antwort anzeigen

Der Task-Manager bietet eine grundlegende Übersicht über Prozesse, Leistung, Benutzer und Autostarts. Process Explorer zeigt zusätzlich unter anderem Prozesshierarchie, Befehlszeilen, Signaturen, Handles, DLLs, Threads, Sicherheitsinformationen und detaillierte Prozesseigenschaften.

Wofür wird Process Monitor verwendet?

Antwort anzeigen

Process Monitor zeichnet Datei-, Registry-, Prozess-, Thread- und DLL-Aktivitäten auf. Damit können beispielsweise fehlende Dateien, fehlerhafte Pfade und verweigerte Zugriffe untersucht werden.

Warum ist NAME NOT FOUND in Process Monitor nicht automatisch ein Fehler?

Antwort anzeigen

Anwendungen prüfen häufig mehrere mögliche Namen oder Pfade. Wenn anschließend ein alternativer Zugriff erfolgreich ist, kann der fehlgeschlagene Versuch zum normalen Programmablauf gehören.

Warum sollte ein blockierendes Handle nicht sofort geschlossen werden?

Antwort anzeigen

Das erzwungene Schließen kann Datenverlust, Programmabstürze oder inkonsistente Anwendungszustände verursachen. Zuerst muss die zugehörige Anwendung identifiziert und möglichst regulär beendet werden.

Warum kann ein vollständiges Speicherabbild sicherheitsrelevant sein?

Antwort anzeigen

Der Prozessspeicher kann Kennwörter, Tokens, Schlüssel, personenbezogene Daten und vertrauliche Anwendungsinhalte enthalten. Dumps müssen daher wie sensible Daten behandelt werden.

Warum darf ein Programm nicht dauerhaft nur als Administrator ausgeführt werden, um „Zugriff verweigert“ zu umgehen?

Antwort anzeigen

Dadurch erhält das Programm weitreichendere Rechte als erforderlich. Stattdessen muss die konkret fehlende Berechtigung identifiziert und nach dem Minimalprinzip vergeben werden.

Wofür wird Autoruns eingesetzt?

Antwort anzeigen

Autoruns zeigt zahlreiche automatische Startpunkte von Windows, beispielsweise Anmeldeeinträge, Dienste, Treiber, geplante Aufgaben und Erweiterungen. Es hilft bei Problemen, die nach dem Start oder der Anmeldung auftreten.

Was ist der Unterschied zwischen WPR und WPA?

Antwort anzeigen

Windows Performance Recorder zeichnet ETW-Ereignisse auf. Windows Performance Analyzer öffnet und analysiert die erzeugten ETL-Dateien mithilfe von Tabellen und Diagrammen.

Warum sollte vor dem Neustart eines Prozesses ein Dump erstellt werden?

Antwort anzeigen

Der Neustart beseitigt den aktuellen Prozesszustand. Ein Dump kann Informationen über Threads, Aufrufstapel, Speicher und Sperren erhalten, die für die Ursachenanalyse benötigt werden.

34. Prüfungsfallen

35. Checkliste

36. Schnellreferenz

Beobachtung Nächstes Werkzeug
Prozess verbraucht viel CPU Process Explorer, Leistungsüberwachung
nur ein Kern ausgelastet Process Explorer → Threads
Arbeitsspeicher wächst PowerShell, Process Explorer, ProcDump
Handles wachsen Process Explorer, Handle
Datei ist gesperrt Process Explorer oder Handle
DLL-Konflikt vermutet Process Explorer oder ListDLLs
Zugriff verweigert Process Monitor, AccessChk
Datei oder Pfad fehlt Process Monitor
Dienst startet nicht Ereignisanzeige, sc.exe, PowerShell
Dienst hängt beim Start Ereignisanzeige, Wait Chain, ProcDump
Prozess reagiert nicht Ressourcenmonitor, Process Explorer, ProcDump
Anwendung stürzt ab Ereignisanzeige, WER, ProcDump
unbekannte Netzwerkverbindung TCPView
erwarteter Port fehlt Get-NetTCPConnection, TCPView
Port ist bereits belegt Get-NetTCPConnection, netstat -ano
Fehler nach Anmeldung Autoruns
langsamer Systemstart Autoruns, WPR und WPA
unbekannte Datei Sigcheck
zeitweises Leistungsproblem WPR und WPA
Problem nur unter Dienstkonto whoami, AccessChk, Process Monitor
Anwendung funktioniert nur erhöht Process Monitor und Berechtigungsprüfung

Merksatz

Windows-Prozesse und Dienste werden nicht allein anhand ihres Namens oder eines einzelnen Messwerts bewertet. Entscheidend sind Prozesshierarchie, Benutzerkonto, Threads, Speicher, Handles, Dateien, Registry-Zugriffe, Netzwerkverbindungen, Ereignisse und externe Abhängigkeiten. Vor dem Beenden oder Neustarten wird der flüchtige Zustand gesichert. Anschließend wird genau eine kontrollierte Maßnahme durchgeführt und ihre Wirkung erneut geprüft.

Quellen und weiterführende Dokumentation

Offizielle Microsoft-Dokumentation

8. Betriebssystem- und Serveranalyse

8.2 Active Directory, Gruppenrichtlinien und Kerberos analysieren

Active Directory Domain Services bilden in vielen Windows-Netzwerken die Grundlage für:

Eine scheinbar einfache Meldung wie „Anmeldung nicht möglich“, „Zugriff verweigert“ oder „Gruppenrichtlinie wird nicht angewendet“ kann deshalb unterschiedliche Ursachen haben:

Die Komponenten müssen gemeinsam und in einer festen Reihenfolge untersucht werden.

1. Lernziele

Nach dieser Seite kannst du:

2. Vereinfachte Abhängigkeitskette

Benutzer oder Computer
        ↓
IP-Konnektivität
        ↓
DNS-Auflösung und SRV-Einträge
        ↓
Erreichbarer Domänencontroller
        ↓
Zeitsynchronisation
        ↓
Secure Channel und Computerkonto
        ↓
Kerberos oder NTLM
        ↓
Active-Directory-Replikation
        ↓
Gruppenmitgliedschaften und Berechtigungen
        ↓
Gruppenrichtlinien und Anwendungszugriff

Ein Fehler weiter oben kann zahlreiche Folgefehler auslösen.

Beispiele:

3. Sicherheits- und Betriebsregeln

Vor Änderungen müssen mindestens folgende Informationen gesichert werden:

Nicht als erste Maßnahme durchführen:

Solche Maßnahmen verändern oder vernichten den Zustand, der für die Ursachenanalyse benötigt wird.

4. Fehlerbild exakt erfassen

Wichtige Fragen:

Ein Client, ein Benutzer und eine konkrete Zielressource sollten als kontrollierter Testfall verwendet werden.

5. Grundinformationen auf dem Client erfassen

Identität:

whoami

Benutzer-Domäne:

echo %USERDOMAIN%

Anmeldeserver:

echo %LOGONSERVER%

Vollständige Benutzerinformationen:

whoami /all

Computername:

hostname

Domänenzugehörigkeit:

Get-CimInstance Win32_ComputerSystem |
    Select-Object Name,
                  Domain,
                  PartOfDomain,
                  UserName

IP-Konfiguration:

ipconfig /all

Dabei sind besonders zu prüfen:

Domänenmitglieder sollten grundsätzlich die für die AD-Domäne zuständigen internen DNS-Server verwenden. Ein öffentlicher DNS-Server kennt die internen AD-SRV-Einträge normalerweise nicht.

6. Verwendeten Domänencontroller bestimmen

Anmeldeserver:

echo %LOGONSERVER%

Domänencontroller für die Domäne suchen:

nltest /dsgetdc:<Domänenname>

Beispiel:

nltest /dsgetdc:ad.example.local

Domänencontroller auflisten:

nltest /dclist:<Domänenname>

Aktuellen DC über PowerShell bestimmen:

Get-ADDomainController -Discover

Alle bekannten Domänencontroller:

Get-ADDomainController -Filter * |
    Select-Object HostName,
                  Site,
                  IPv4Address,
                  IsGlobalCatalog,
                  OperationMasterRoles

Die PowerShell-Befehle des Active-Directory-Moduls erfordern die entsprechenden RSAT-Komponenten oder die Ausführung auf einem geeigneten Verwaltungsserver.

Zu dokumentieren sind:

7. DNS als erste technische Abhängigkeit prüfen

Hostauflösung:

nslookup <Domänencontroller>

Vollqualifizierten Namen prüfen:

nslookup <DC-Name>.<DNS-Domäne>

Domänencontroller über LDAP-SRV-Einträge suchen:

nslookup -type=SRV _ldap._tcp.dc._msdcs.<DNS-Domäne>

Kerberos-Dienste suchen:

nslookup -type=SRV _kerberos._tcp.<DNS-Domäne>

Global Catalog suchen:

nslookup -type=SRV _gc._tcp.<DNS-Gesamtstruktur>

Standortspezifische Domänencontroller:

nslookup -type=SRV _ldap._tcp.<Standort>._sites.dc._msdcs.<DNS-Domäne>

PowerShell:

Resolve-DnsName -Type SRV `
    _ldap._tcp.dc._msdcs.<DNS-Domäne>

Zu prüfen sind:

Ein erfolgreicher Ping auf eine IP-Adresse beweist keine funktionierende AD-DNS-Struktur.

8. Erreichbarkeit benötigter Dienste prüfen

Grundlegende Verbindung:

Test-NetConnection <Domänencontroller>

DNS:

Test-NetConnection <Domänencontroller> -Port 53

Kerberos:

Test-NetConnection <Domänencontroller> -Port 88

LDAP:

Test-NetConnection <Domänencontroller> -Port 389

SMB für SYSVOL und NETLOGON:

Test-NetConnection <Domänencontroller> -Port 445

RPC Endpoint Mapper:

Test-NetConnection <Domänencontroller> -Port 135

Global Catalog:

Test-NetConnection <Domänencontroller> -Port 3268

LDAPS, sofern verwendet:

Test-NetConnection <Domänencontroller> -Port 636

Global Catalog über TLS, sofern verwendet:

Test-NetConnection <Domänencontroller> -Port 3269

Wichtige Dienste und Ports können unter anderem sein:

Funktion Typischer Port
DNS TCP/UDP 53
Kerberos TCP/UDP 88
RPC Endpoint Mapper TCP 135
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
dynamisches RPC konfigurationsabhängiger TCP-Portbereich

Ein erfolgreich getesteter TCP-Port beweist nur, dass eine Verbindung zu diesem Port hergestellt werden konnte. Er beweist nicht, dass Authentifizierung, LDAP-Abfrage, Replikation oder Gruppenrichtlinienverarbeitung funktionieren.

9. SYSVOL und NETLOGON prüfen

Freigaben des Domänencontrollers:

net view \\<Domänencontroller>

SYSVOL öffnen:

dir \\<Domänencontroller>\SYSVOL

NETLOGON öffnen:

dir \\<Domänencontroller>\NETLOGON

Direkter Domänenpfad:

dir \\<DNS-Domäne>\SYSVOL

Zu prüfen sind:

Eine GPO besteht aus zwei zusammengehörigen Teilen:

Bestandteil Speicherort
Group Policy Container Active Directory
Group Policy Template SYSVOL

Sind die beiden Teile oder ihre Versionsstände nicht konsistent, kann die Gruppenrichtlinienverarbeitung fehlschlagen.

10. Zeitsynchronisation prüfen

Aktueller Status:

w32tm /query /status

Zeitquelle:

w32tm /query /source

Konfiguration:

w32tm /query /configuration

Domänenhierarchie überwachen:

w32tm /monitor

Vergleich mit einem bestimmten Domänencontroller:

w32tm /stripchart /computer:<Domänencontroller> /samples:10 /dataonly

Windows-Zeitdienst:

Get-Service W32Time

Zu prüfen sind:

Kerberos reagiert empfindlich auf Zeitabweichungen. Der konkrete Fehler muss jedoch anhand von Ereignissen, Ticketstatus und Zeitmessung nachgewiesen werden.

Eine manuelle Änderung der Uhrzeit beseitigt nicht automatisch die Ursache einer falschen Zeitquelle.

11. Secure Channel des Computers prüfen

Der Secure Channel ist die geschützte Beziehung zwischen einem Domänenmitglied und der Domäne.

Prüfung mit PowerShell:

Test-ComputerSecureChannel -Verbose

Prüfung mit NLTEST:

nltest /sc_verify:<DNS-Domäne>

Verwendeten sicheren Kanal anzeigen:

nltest /sc_query:<DNS-Domäne>

Mögliche Symptome eines gestörten Secure Channels:

Mögliche Ursachen:

Eine Reparatur des Secure Channels ist eine Änderung und darf erst nach Sicherung der Diagnoseergebnisse erfolgen.

Mögliche kontrollierte Reparatur auf einem Domänenmitglied:

Test-ComputerSecureChannel -Repair `
    -Credential <Domäne>\<Administratorkonto>

Vorher müssen geprüft werden:

Test-ComputerSecureChannel ist vor allem für Domänenmitglieder vorgesehen. Bei Domänencontrollern müssen DC-spezifische Diagnose- und Reparaturverfahren verwendet werden.

12. Benutzer- und Computerkonto prüfen

Benutzerkonto:

Get-ADUser -Identity <Benutzername> -Properties * |
    Select-Object SamAccountName,
                  UserPrincipalName,
                  Enabled,
                  LockedOut,
                  PasswordExpired,
                  PasswordLastSet,
                  LastBadPasswordAttempt,
                  BadLogonCount,
                  AccountExpirationDate

Computerkonto:

Get-ADComputer -Identity <Computername> -Properties * |
    Select-Object Name,
                  Enabled,
                  DNSHostName,
                  PasswordLastSet,
                  LastLogonDate,
                  DistinguishedName

Gruppenmitgliedschaften:

Get-ADPrincipalGroupMembership <Benutzername> |
    Select-Object Name,
                  GroupScope,
                  GroupCategory

Aktuelles Benutzer-Token:

whoami /groups

Zu unterscheiden sind:

Eine neu hinzugefügte Gruppenmitgliedschaft ist nicht automatisch im bereits bestehenden Benutzer-Token enthalten. Ab- und erneute Anmeldung kann erforderlich sein. Bei bestimmten Dienstkonten kann ein Dienstneustart notwendig sein.

13. Kontosperrung untersuchen

Zu prüfen sind:

Benutzerstatus:

Get-ADUser <Benutzername> `
    -Properties LockedOut,
                LastBadPasswordAttempt,
                BadLogonCount,
                PasswordLastSet

Gesperrte Konten suchen:

Search-ADAccount -LockedOut -UsersOnly

Relevante Sicherheitsereignisse können unter anderem betreffen:

Ein Konto lediglich wiederholt zu entsperren beseitigt die Quelle der falschen Anmeldedaten nicht.

14. Domänencontroller grundsätzlich prüfen

Ausführliche Diagnose:

dcdiag /v

Ausgabe in Datei:

dcdiag /v /c /d /e > C:\Temp\dcdiag.txt

DNS-Test:

dcdiag /test:dns /v

Replikationstest:

dcdiag /test:replications /v

SYSVOL-Test:

dcdiag /test:sysvolcheck /v

Werbungsstatus des Domänencontrollers:

dcdiag /test:advertising /v

NETLOGON-Freigabe:

Zu prüfen sind:

Nicht jede Warnung in einer umfangreichen dcdiag-Ausgabe erklärt das untersuchte Symptom. Der Befund muss zeitlich und technisch zum Fehler passen.

15. AD-Replikation prüfen

Gesamtübersicht:

repadmin /replsummary

Eingehende Replikation eines DCs:

repadmin /showrepl <Domänencontroller>

Gesamtstrukturweite Anzeige:

repadmin /showrepl * /csv

PowerShell-Auswertung:

repadmin /showrepl * /csv |
    ConvertFrom-Csv |
    Out-GridView

Replikationsfehler über PowerShell:

Get-ADReplicationFailure `
    -Target * `
    -Scope Forest

Status der Replikationspartner:

Get-ADReplicationPartnerMetadata `
    -Target * `
    -Scope Forest |
    Select-Object Server,
                  Partner,
                  Partition,
                  LastReplicationAttempt,
                  LastReplicationSuccess,
                  LastReplicationResult

Replikationswarteschlange:

repadmin /queue

Zu dokumentieren sind:

16. Replikationsfehler richtig bewerten

AD-Replikation hängt unter anderem ab von:

Befund Mögliche Ursache
Fehler 1722 RPC-Server nicht verfügbar, DNS, Firewall oder Dienstproblem
Fehler 5 Zugriff verweigert, Authentifizierung oder Berechtigung
Zielprinzipalname ist falsch Kerberos-, SPN- oder Computerkonto-Problem
letzter Erfolg lange her dauerhafte oder standortbezogene Störung
nur eine Partition betroffen partitions- oder DNS-bezogenes Problem
nur ein Partner betroffen Verbindung, DNS oder Zustand dieses Partners
Änderungen fehlen nur auf einem DC eingehende Replikation dieses DCs prüfen
verschiedene Kennwörter funktionieren je nach DC Kennwortreplikation oder allgemeine Replikation prüfen
GPO fehlt nur auf einem DC AD- und SYSVOL-Replikation gemeinsam prüfen

Eine erzwungene Synchronisation ist keine erste Diagnosemaßnahme. Sie kann zusätzliche Last erzeugen und verdeckt möglicherweise die Richtung oder den ursprünglichen Zustand des Fehlers.

17. FSMO-Rollen prüfen

netdom query fsmo

PowerShell:

Get-ADForest |
    Select-Object SchemaMaster,
                  DomainNamingMaster

Get-ADDomain |
    Select-Object PDCEmulator,
                  RIDMaster,
                  InfrastructureMaster

Die Rollen sind:

Rolle Ebene Wichtige Funktion
Schema-Master Gesamtstruktur Schemaänderungen
Domänennamen-Master Gesamtstruktur Domänen und Partitionen
RID-Master Domäne RID-Pools für Sicherheitskennungen
PDC-Emulator Domäne Zeit, Kennwortpriorität und weitere Funktionen
Infrastruktur-Master Domäne domänenübergreifende Objektbezüge

Der Ausfall eines FSMO-Rolleninhabers erklärt nicht automatisch jede Anmeldestörung. Die betroffene Funktion und die Ausfalldauer müssen berücksichtigt werden.

18. Gruppenrichtlinien-Grundlagen

Die normale Verarbeitungsreihenfolge lautet:

Lokal → Site → Domäne → OU → untergeordnete OU

Diese Reihenfolge wird häufig mit LSDOU bezeichnet.

Grundsätzlich gilt:

Mögliche Ursachen für eine nicht angewendete GPO:

19. Gruppenrichtlinienergebnis erfassen

Kurzübersicht:

gpresult /r

Computerrichtlinien mit erhöhten Rechten:

gpresult /scope computer /r

Benutzerrichtlinien:

gpresult /scope user /r

Ausführlicher HTML-Bericht:

gpresult /h C:\Temp\gpresult.html

Bericht für einen bestimmten Benutzer:

gpresult /user <Domäne>\<Benutzer> /h C:\Temp\gpresult-benutzer.html

Ausführliche Textausgabe:

gpresult /z

Resultant Set of Policy:

rsop.msc

Im Bericht sind besonders zu prüfen:

gpresult muss im passenden Benutzer- und Berechtigungskontext ausgeführt werden. Ein Bericht aus einem anderen Konto kann ein anderes Ergebnis zeigen.

20. Gruppenrichtlinien kontrolliert aktualisieren

Standardaktualisierung:

gpupdate

Erneute Verarbeitung aller Einstellungen:

gpupdate /force

Nur Computerrichtlinien:

gpupdate /target:computer /force

Nur Benutzerrichtlinien:

gpupdate /target:user /force

Eine erzwungene Aktualisierung kann:

gpupdate /force ist ein Test beziehungsweise Auslöser, aber noch keine Ursachenanalyse. Danach müssen Ergebnisbericht und Ereignisprotokolle geprüft werden.

21. Gruppenrichtlinien-Ereignisse prüfen

Wichtiger Protokollpfad:

Ereignisanzeige
→ Anwendungs- und Dienstprotokolle
→ Microsoft
→ Windows
→ GroupPolicy
→ Operational

PowerShell:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-GroupPolicy/Operational'
    StartTime = (Get-Date).AddHours(-2)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  Message

Zusätzlich prüfen:

Nicht nur die Event-ID verwenden. Provider, vollständiger Text, Zeitpunkt, Benutzer, Computer und Verarbeitungsschritt müssen gemeinsam bewertet werden.

22. GPO-Verknüpfung und Filterung prüfen

In der Gruppenrichtlinienverwaltung sind zu kontrollieren:

Sicherheitsfilterung benötigt grundsätzlich die passenden Berechtigungen zum Lesen und Anwenden der Gruppenrichtlinie.

Typische Fehlinterpretation:

Ein Benutzer ist Mitglied einer Gruppe, die „Gruppenrichtlinie übernehmen“ besitzt. Im aktuellen Anmeldetoken fehlt diese neue Gruppenmitgliedschaft jedoch noch.

Deshalb müssen AD-Mitgliedschaft und aktuelles Token getrennt geprüft werden.

23. Loopbackverarbeitung verstehen

Loopbackverarbeitung wird für Computer verwendet, bei denen die Benutzerumgebung vom verwendeten Computer abhängen soll, beispielsweise:

Modi:

Modus Wirkung
Zusammenführen Benutzerrichtlinien des Benutzerobjekts werden verarbeitet, danach kommen die für den Computer ermittelten Benutzerrichtlinien hinzu
Ersetzen Benutzerrichtlinien des Benutzerobjekts werden durch die für den Computer ermittelten Benutzerrichtlinien ersetzt

Wenn Benutzereinstellungen nur auf bestimmten Computern unerwartet sind, muss Loopback geprüft werden.

24. Kerberos-Grundprinzip

Vereinfacht:

Benutzeranmeldung
        ↓
Authentication Service Request
        ↓
Ticket Granting Ticket
        ↓
Ticket Granting Service Request
        ↓
Dienstticket für einen SPN
        ↓
Zugriff auf den Zieldienst

Wichtige Begriffe:

Begriff Bedeutung
KDC Key Distribution Center auf einem Domänencontroller
TGT Ticket Granting Ticket
Dienstticket Ticket für einen konkreten Dienst
SPN eindeutiger Dienstbezeichner eines Kontos
Realm Kerberos-Sicherheitsbereich, in AD meist zur Domäne zugeordnet
PAC enthält unter anderem Autorisierungsinformationen
Delegierung Weitergabe von Anmeldeinformationen unter definierten Bedingungen

Kerberos benötigt insbesondere:

25. Kerberos-Tickets prüfen

Tickets des aktuellen Anmeldekontexts:

klist

TGT anzeigen:

klist tgt

Zwischengespeicherte Tickets auflisten:

klist tickets

KDCs anzeigen:

klist query_bind

Zu prüfen sind:

Das Löschen des Ticketcaches verändert den Diagnosezustand:

klist purge

klist purge sollte erst eingesetzt werden, wenn:

Nach dem Löschen kann ein erneuter Zugriff auf die Zielressource ein neues Ticket auslösen.

26. Service Principal Names prüfen

SPNs eines Kontos anzeigen:

setspn -L <Kontoname>

Bestimmten SPN suchen:

setspn -Q <Dienst>/<Hostname>

Beispiel:

setspn -Q HTTP\webserver.ad.example.local

Doppelte SPNs domänen- beziehungsweise gesamtstrukturweit suchen:

setspn -X

Mögliche SPN-Probleme:

SPNs dürfen nicht ohne vorherige Suche, Dokumentation und Prüfung verändert werden. Ein falsches Entfernen kann andere Dienste oder Benutzer beeinträchtigen.

27. Kerberos und NTLM unterscheiden

Anmeldesitzungen:

klist sessions

Tickets:

klist

Für bestimmte Verbindungen können zusätzlich Ereignisprotokolle, Dienstprotokolle oder geeignete Netzwerkaufzeichnungen erforderlich sein.

Mögliche Hinweise auf NTLM statt Kerberos:

Ein funktionierender Zugriff beweist deshalb nicht automatisch, dass Kerberos verwendet wurde.

28. Zugriff über IP-Adresse und Hostname vergleichen

Beispiel:

\\192.0.2.10\Freigabe
\\server01\Freigabe
\\server01.ad.example.local\Freigabe

Unterschiedliche Ergebnisse können auf Folgendes hinweisen:

Der Zugriff per IP-Adresse ist kein allgemeiner Ersatz für korrekte Namensauflösung. Bei Kerberos ist der verwendete Zielname für die SPN-Zuordnung entscheidend.

29. Kerberos-Ereignisse untersuchen

Relevante Protokolle können sein:

PowerShell-Beispiel für aktuelle Sicherheitsereignisse:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    StartTime = (Get-Date).AddHours(-2)
} |
    Where-Object {
        $_.Id -in 4768, 4769, 4771, 4776
    } |
    Select-Object TimeCreated,
                  Id,
                  Message

Typische Ereigniskategorien:

Kategorie Mögliche Bedeutung
TGT wurde angefordert Benutzer- oder Computerauthentifizierung
Dienstticket wurde angefordert Zugriff auf einen bestimmten SPN
Kerberos-Vorauthentifizierung fehlgeschlagen Kennwort, Zeit, Kontostatus oder anderer Authentifizierungsfehler
Anmeldeinformationen wurden validiert häufig NTLM-bezogene Prüfung
Kontosperrung wiederholte fehlerhafte Authentifizierung

Event-IDs müssen mit dem vollständigen Ereignistext und dem jeweiligen System ausgewertet werden.

30. Typische Fehlerbilder

Symptom Mögliche Ursache Nächster Test
Domäne kann nicht gefunden werden DNS oder DC-Erreichbarkeit ipconfig /all, SRV-Abfrage, nltest /dsgetdc
Anmeldung funktioniert offline, aber nicht im Firmennetz DC-, DNS-, Zeit- oder Secure-Channel-Problem DC-Suche, Zeit und Secure Channel
Vertrauensstellung fehlgeschlagen Computerkennwort oder Computerkonto inkonsistent Test-ComputerSecureChannel, Replikation
neues Kennwort funktioniert nur manchmal unterschiedliche DC-Daten verwendeten DC und Replikation prüfen
Benutzer bleibt trotz Entsperrung gesperrt gespeicherte alte Anmeldedaten Sperrquelle und Sicherheitsereignisse
GPO wird nicht angezeigt falsche OU, Filterung oder Link gpresult, GPMC
GPO wird angezeigt, Einstellung fehlt Überschreibung oder Erweiterungsfehler Detailbericht und GroupPolicy-Protokoll
Computerrichtlinie fehlt Computerobjekt, Neustart oder Computerbereich gpresult /scope computer
Benutzerrichtlinie fehlt Benutzerobjekt, Token oder Benutzerbereich gpresult /scope user
GPO funktioniert nur an einem Standort nicht Site, DC, Replikation oder Netzwerk DC-Zuordnung und Replikation
SYSVOL nicht erreichbar DNS, SMB, DC oder DFSR Port 445, Freigabe und DC-Protokolle
Kerberos-Ticket fehlt SPN, DNS, KDC oder Anwendung klist, setspn -Q
Kerberos scheitert nur über Alias fehlender SPN für Alias verwendeten Namen und SPN prüfen
Zugriff funktioniert per IP, nicht per Name DNS, SPN oder Zertifikat Namen einzeln prüfen
Zugriff funktioniert per Name, nicht per IP Kerberos- oder Anwendungsanforderung Ticket und Zielkonfiguration
Dienst funktioniert nur mit NTLM SPN oder Delegierung Dienstkonto und SPNs
Replikation meldet RPC-Fehler DNS, Firewall, RPC oder Partner offline Namensauflösung und Ports
Benutzer hat neue Gruppe, aber keinen Zugriff altes Anmeldetoken whoami /groups, erneute Anmeldung
Fehler nur auf einem Client lokaler DNS-, Cache-, Konto- oder Profilfehler Vergleichsclient und lokale Konfiguration
Fehler auf vielen Clients zentrale AD-, DNS-, GPO- oder Netzwerkstörung DCs, Replikation und Änderungen
Fehler nach VM-Snapshot Secure Channel oder Zeit zurückgesetzt Zeit, Computerkonto und Secure Channel

31. Vorgehensweise bei einer nicht angewendeten GPO

  1. Betroffenen Benutzer und Computer bestimmen.
  2. Prüfen, ob Benutzer- und Computerobjekt in den erwarteten OUs liegen.
  3. Verwendeten Domänencontroller dokumentieren.
  4. DNS- und DC-Erreichbarkeit prüfen.
  5. SYSVOL-Zugriff prüfen.
  6. gpresult als HTML-Bericht erstellen.
  7. angewendete und abgelehnte GPOs prüfen.
  8. Sicherheitsfilterung und WMI-Filter prüfen.
  9. Verknüpfung, Reihenfolge und Vererbung prüfen.
  10. Loopbackverarbeitung berücksichtigen.
  11. GroupPolicy-Operational-Protokoll auswerten.
  12. AD- und SYSVOL-Replikation prüfen.
  13. genau eine kontrollierte Korrektur durchführen.
  14. Richtlinien erneut verarbeiten.
  15. Ergebnisbericht und Benutzerfunktion erneut prüfen.

32. Vorgehensweise bei einer fehlgeschlagenen Anmeldung

  1. Exakte Meldung und Zeitpunkt erfassen.
  2. Lokale und Domänenanmeldung unterscheiden.
  3. Netzwerkverbindung prüfen.
  4. DNS-Server und DNS-Suffix prüfen.
  5. Domänencontroller über SRV-Einträge suchen.
  6. verwendeten DC bestimmen.
  7. Zeit und Zeitquelle prüfen.
  8. Benutzerkonto auf Sperre, Ablauf und Deaktivierung prüfen.
  9. Secure Channel des Clients prüfen.
  10. Replikationsstatus der DCs prüfen.
  11. Sicherheits- und Kerberos-Ereignisse auswerten.
  12. gespeicherte Anmeldedaten, Dienste und Aufgaben berücksichtigen.
  13. genau eine Maßnahme durchführen.
  14. Anmeldung und Ressourcenabruf erneut testen.

33. Vorgehensweise bei Kerberos-Problemen

  1. verwendeten Zielnamen dokumentieren.
  2. DNS-Auflösung dieses Namens prüfen.
  3. Zeit von Client, Server und DC vergleichen.
  4. KDC beziehungsweise DC-Erreichbarkeit prüfen.
  5. vorhandene Tickets mit klist dokumentieren.
  6. nach passendem Dienstticket suchen.
  7. erwarteten SPN bestimmen.
  8. SPN mit setspn -Q suchen.
  9. Dienstkonto und tatsächlichen Dienstprozess vergleichen.
  10. doppelte SPNs prüfen.
  11. Sicherheits- und Kerberos-Ereignisse korrelieren.
  12. Vertrauensstellung und Delegierung berücksichtigen.
  13. Ticketcache nur kontrolliert leeren.
  14. Zugriff erneut auslösen.
  15. neues Ticket und Funktion prüfen.

34. Maßnahmen und Rückwege

Ursache: falscher DNS-Server am Client

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: fehlerhafter Secure Channel

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: GPO durch Sicherheitsfilterung ausgeschlossen

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: doppelter SPN

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: AD-Replikationsfehler

Nachweis:

Maßnahme:

Rollback:

Verifikation:

35. Nachkontrolle

Nach jeder Maßnahme sind mindestens folgende Punkte erneut zu prüfen:

36. Dokumentationsbeispiel

Symptom:
Die Laufwerkszuordnung aus der Gruppenrichtlinie wurde auf einem
Client nicht erstellt.

Zeitpunkt:
02.08.2026, 10:18 Uhr MESZ

Betroffener Benutzer:
max.mustermann

Betroffener Computer:
CLIENT-17

Verwendeter Domänencontroller:
DC02.ad.example.local

Nachweis:
DNS-Auflösung, Zeit und SYSVOL-Zugriff waren erfolgreich.
Der gpresult-Bericht zeigte die GPO als abgelehnt.
Als Ablehnungsgrund wurde die Sicherheitsfilterung angegeben.
Die erforderliche Benutzergruppe war im Active Directory eingetragen,
fehlte aber im aktuellen Anmeldetoken.

Ursache:
Die Gruppenmitgliedschaft wurde erst nach Beginn der bestehenden
Benutzersitzung hinzugefügt.

Maßnahme:
Der Benutzer meldete sich kontrolliert ab und erneut an.
An der GPO und ihren Berechtigungen wurde nichts verändert.

Rollback:
Nicht erforderlich, da keine Konfiguration geändert wurde.

Verifikation:
whoami /groups zeigt die vorgesehene Gruppe.
gpresult zeigt die angewendete GPO.
Das Laufwerk wurde verbunden.
Keine neuen Fehler im GroupPolicy-Protokoll.

Prävention:
Bei Änderungen an Gruppenmitgliedschaften wird künftig berücksichtigt,
dass bestehende Anmeldetoken nicht automatisch vollständig erneuert werden.

37. Entscheidungsbaum

Domänenanmeldung, GPO oder Ressourcenzugriff gestört
        ↓
Stimmen IP-Konfiguration und interne DNS-Server?
        ├── Nein
        │   ↓
        │   Netzwerk- und DNS-Konfiguration korrigieren
        │
        └── Ja
            ↓
Werden AD-SRV-Einträge und DCs gefunden?
        ├── Nein
        │   ↓
        │   DNS-Zone, SRV-Einträge und DC-Dienste prüfen
        │
        └── Ja
            ↓
Sind DC und benötigte Ports erreichbar?
        ├── Nein
        │   ↓
        │   Routing, Firewall, Standort und Dienste prüfen
        │
        └── Ja
            ↓
Stimmen Zeit und Secure Channel?
        ├── Nein
        │   ↓
        │   Zeitquelle oder Vertrauensbeziehung untersuchen
        │
        └── Ja
            ↓
Ist die AD-Replikation fehlerfrei?
        ├── Nein
        │   ↓
        │   Replikationsfehler nach Code und Richtung analysieren
        │
        └── Ja
            ↓
Betrifft der Fehler Gruppenrichtlinien?
        ├── Ja
        │   ↓
        │   gpresult, SYSVOL, Filter, OU und Ereignisse prüfen
        │
        └── Nein
            ↓
Betrifft der Fehler Kerberos oder einen Dienst?
        ├── Ja
        │   ↓
        │   Tickets, SPNs, Zielname und Dienstkonto prüfen
        │
        └── Nein
            ↓
Konto, Gruppen, Berechtigungen und Anwendung untersuchen

38. Typische Prüfungsfragen

Warum ist DNS für Active Directory besonders wichtig?

Antwort anzeigen

Active Directory verwendet DNS und insbesondere SRV-Einträge, damit Clients Domänencontroller, Kerberos-Dienste und Global Catalogs finden. Eine reine Auflösung externer Internetnamen reicht für eine funktionierende Domänenumgebung nicht aus.

Warum kann ein neues Kennwort an einem Client funktionieren und an einem anderen nicht?

Antwort anzeigen

Die Clients können unterschiedliche Domänencontroller verwenden. Bei einer Replikationsstörung ist das neue Kennwort möglicherweise noch nicht auf allen benötigten Domänencontrollern verfügbar.

Wozu dient gpresult?

Antwort anzeigen

gpresult zeigt die resultierenden Gruppenrichtlinien für einen Benutzer oder Computer. Es kann angewendete und abgelehnte GPOs, Sicherheitsgruppen, Filter und weitere Verarbeitungsinformationen darstellen.

Warum ist gpupdate /force noch keine Fehlerbehebung?

Antwort anzeigen

Der Befehl löst eine erneute Verarbeitung der Gruppenrichtlinien aus. Er erklärt jedoch nicht, warum eine GPO zuvor nicht angewendet wurde. Dafür müssen Ergebnisbericht, Ereignisse, Filterung, Verknüpfung und Abhängigkeiten geprüft werden.

Warum kann eine neue Gruppenmitgliedschaft trotz korrektem AD-Eintrag noch wirkungslos sein?

Antwort anzeigen

Das aktuelle Anmeldetoken wurde möglicherweise vor der Gruppenänderung erzeugt. Die neue Mitgliedschaft ist dann noch nicht im Token enthalten und wird häufig erst nach erneuter Anmeldung wirksam.

Welche drei grundlegenden Abhängigkeiten benötigt Kerberos besonders?

Antwort anzeigen

Kerberos benötigt insbesondere funktionierende DNS-Auflösung, ausreichend genaue Zeitsynchronisation und korrekte beziehungsweise eindeutige Dienstidentitäten in Form von SPNs.

Was ist ein SPN?

Antwort anzeigen

Ein Service Principal Name identifiziert eine konkrete Dienstinstanz und ist einem Active-Directory-Konto zugeordnet. Der KDC verwendet ihn, um ein Dienstticket für den richtigen Dienst auszustellen.

Warum kann ein doppelter SPN die Kerberos-Authentifizierung verhindern?

Antwort anzeigen

Der KDC kann den Dienst nicht eindeutig einem Konto zuordnen. Dadurch kann kein korrektes Dienstticket für die erwartete Dienstidentität ausgestellt werden.

Warum sollte ein Computer nicht sofort aus der Domäne entfernt werden?

Antwort anzeigen

Dadurch wird der für die Diagnose wichtige Zustand verändert. Außerdem kann die Maßnahme zusätzliche Probleme mit Computerkonto, Profilen, Berechtigungen, Zertifikaten und verwalteter Konfiguration erzeugen.

Worin unterscheiden sich AD- und SYSVOL-Replikation bei einer GPO?

Antwort anzeigen

Der Group Policy Container mit den Verzeichnisinformationen liegt im Active Directory. Das Group Policy Template mit den dateibasierten Richtlinieninhalten liegt in SYSVOL. Beide Bestandteile müssen verfügbar und konsistent sein.

39. Prüfungsfallen

40. Checkliste

41. Schnellreferenz

Beobachtung Nächstes Werkzeug
Domäne wird nicht gefunden ipconfig /all, nslookup, nltest /dsgetdc
falscher DNS-Server Adapter-, DHCP- und DNS-Konfiguration
DC wird nicht gefunden SRV-Abfragen und nltest
Anmeldung nur offline möglich DC-Erreichbarkeit, Zeit, Secure Channel
Vertrauensstellung fehlgeschlagen Test-ComputerSecureChannel, nltest
neues Kennwort funktioniert nicht überall repadmin, verwendeten DC bestimmen
Replikationsfehler repadmin /replsummary, repadmin /showrepl
DC-Zustand unklar dcdiag /v
DNS auf DC fehlerhaft dcdiag /test:dns /v
GPO fehlt gpresult, GPMC
GPO abgelehnt gpresult /h, Sicherheitsfilterung
GPO-Einstellung fehlt Detailbericht und GroupPolicy-Protokoll
SYSVOL nicht erreichbar DNS, SMB-Port und Freigaben
Gruppenänderung wirkt nicht whoami /groups, erneute Anmeldung
Konto wird wiederholt gesperrt Sicherheitsprotokoll und gespeicherte Anmeldedaten
Kerberos-Ticket fehlt klist, DNS, Zeit
Dienstticket fehlt klist, setspn -Q
doppelter SPN vermutet setspn -X
Fehler nur über Alias DNS- und SPN-Zuordnung
Zugriff nur über IP möglich DNS, Zielname, SPN und Kerberos
Fehler nur an einem Standort AD-Site, DC-Auswahl und Replikation
Fehler nur auf einem Client lokale DNS-, Konto-, Token- oder Profilprüfung

Merksatz

Active-Directory-Fehler werden von unten nach oben analysiert: Netzwerk, DNS, Domänencontroller, Zeit, Secure Channel, Replikation, Konten, Gruppenrichtlinien und Kerberos. Erst wenn die Abhängigkeiten nachweislich funktionieren, wird die betroffene Richtlinie, Berechtigung oder Anwendung verändert. Jede Änderung benötigt einen Rückweg und eine erneute Funktionsprüfung.

Quellen und weiterführende Dokumentation

Offizielle Microsoft-Dokumentation

8. Betriebssystem- und Serveranalyse

8.3 Datei-, Freigabe-, Rechte- und Druckdienste analysieren

Datei- und Druckdienstfehler entstehen häufig nicht durch eine einzelne Komponente. Namensauflösung, Netzwerk, Authentifizierung, Freigabeberechtigungen, Dateisystemrechte, Gruppenmitgliedschaften, SMB-Einstellungen, DFS, Speicherplatz und Druckwarteschlangen wirken zusammen.

Grundregel:

Zuerst feststellen, ob bereits die Verbindung, die Authentifizierung, die Freigabe, die Datei oder erst die konkrete Aktion fehlschlägt.

1. Diagnosekette bei Dateizugriffen

Client
  ↓
DNS-Auflösung
  ↓
Netzwerk und TCP 445
  ↓
SMB-Dienst
  ↓
Authentifizierung
  ↓
Freigabeberechtigung
  ↓
NTFS-Berechtigung
  ↓
Datei, Ordner, Sperre oder Anwendung
  ↓
Datenträger und Backend

Jede Stufe muss getrennt geprüft werden.

Prüfschritt Typische Frage
Namensauflösung Zeigt der Servername auf die richtige IP-Adresse?
Netzwerk Ist der Server über den vorgesehenen Pfad erreichbar?
SMB-Port Ist TCP 445 erreichbar?
SMB-Dienst Nimmt der Server SMB-Verbindungen an?
Authentifizierung Mit welchem Konto erfolgt der Zugriff?
Freigaberecht Darf das Konto die Freigabe verwenden?
NTFS-Recht Darf das Konto den Ordner oder die Datei verwenden?
Objektzustand Existiert die Datei und ist sie verfügbar?
Sperre Wird die Datei von einem Prozess blockiert?
Speicher Sind Datenträger, Quota und Backend funktionsfähig?

2. Fehler exakt aufnehmen

Zu dokumentieren sind:

Beispiele für unterschiedliche Aktionen:

Ein Benutzer kann einen Ordner möglicherweise öffnen, aber keine Datei erstellen oder löschen. Deshalb genügt die Aussage „Zugriff funktioniert nicht“ nicht.

3. UNC-Pfad und Ziel bestimmen

Typischer UNC-Pfad:

\\fileserver01\Daten

Mit FQDN:

\\fileserver01.ad.example.local\Daten

Über DFS:

\\ad.example.local\Daten\Abteilung

Zu unterscheiden sind:

Ein Netzlaufwerk wie H: verdeckt den tatsächlichen UNC-Pfad. Dieser kann beispielsweise mit folgendem Befehl geprüft werden:

net use

PowerShell:

Get-SmbMapping

4. DNS-Auflösung prüfen

Resolve-DnsName fileserver01

Resolve-DnsName fileserver01.ad.example.local

nslookup fileserver01

Zusätzlich prüfen:

ping fileserver01

Der Ping dient hier hauptsächlich dazu, den aufgelösten Namen und die Zieladresse zu sehen. Er beweist nicht, dass SMB funktioniert.

Zu vergleichen sind:

Unterschiedliche Ergebnisse können auf Folgendes hinweisen:

5. SMB-Port prüfen

Windows:

Test-NetConnection fileserver01 -Port 445

Ausführlicher:

Test-NetConnection fileserver01 `
    -Port 445 `
    -InformationLevel Detailed

Linux:

nc -vz fileserver01 445

Ein erfolgreicher Test auf TCP 445 zeigt:

Er beweist noch nicht:

6. SMB-Clientverbindungen prüfen

Aktuelle SMB-Verbindungen:

Get-SmbConnection

Ausgewählte Informationen:

Get-SmbConnection |
    Select-Object ServerName,
                  ShareName,
                  UserName,
                  Credential,
                  Dialect,
                  NumOpens

SMB-Zuordnungen:

Get-SmbMapping

Klassische Anzeige:

net use

Dabei sind besonders zu prüfen:

7. Konflikt durch unterschiedliche Anmeldedaten

Windows verwendet für Verbindungen zu einem Server nicht beliebig viele verschiedene Anmeldeinformationen innerhalb desselben Benutzerkontexts.

Typisches Fehlerbild:

Mehrfache Verbindungen zu einem Server oder einer freigegebenen Ressource
von demselben Benutzer unter Verwendung mehrerer Benutzernamen sind nicht zulässig.

Bestehende Verbindungen anzeigen:

net use

Gespeicherte Anmeldeinformationen anzeigen:

cmdkey /list

Mögliche Ursachen:

Verbindungen dürfen nicht pauschal gelöscht werden, ohne ihre Verwendung zu prüfen. Ein Trennen kann geöffnete Dateien oder Anwendungen unterbrechen.

Gezieltes Trennen einer Zuordnung:

net use Z: /delete

Gezieltes Trennen eines UNC-Ziels:

net use \\fileserver01\Daten /delete

8. Freigaben auf dem Server prüfen

Vorhandene SMB-Freigaben:

Get-SmbShare

Bestimmte Freigabe:

Get-SmbShare -Name Daten

Wichtige Eigenschaften:

Get-SmbShare -Name Daten |
    Select-Object Name,
                  Path,
                  Description,
                  ScopeName,
                  FolderEnumerationMode,
                  EncryptData,
                  ConcurrentUserLimit

Klassische Anzeige:

net share

Zu prüfen sind:

Administrative Freigaben wie C$ benötigen normalerweise administrative Berechtigungen und sind kein geeigneter allgemeiner Funktionstest für normale Benutzer.

9. Freigabeberechtigungen prüfen

Get-SmbShareAccess -Name Daten

Beispielausgabe:

Name   AccountName                AccessControlType   AccessRight
----   -----------                -----------------   -----------
Daten  AD\GG-Dateidienst-Lesen    Allow               Read
Daten  AD\GG-Dateidienst-Ändern   Allow               Change

Wichtige Freigaberechte:

Freigaberecht Grundsätzliche Wirkung
Lesen Inhalte anzeigen und Dateien lesen
Ändern zusätzlich erstellen, ändern und löschen
Vollzugriff zusätzlich Freigabeberechtigungen verwalten

Die genaue wirksame Berechtigung ergibt sich nicht allein aus dieser Tabelle. Verweigerungen, Gruppenmitgliedschaften und NTFS-Berechtigungen müssen zusätzlich berücksichtigt werden.

10. NTFS-Berechtigungen prüfen

PowerShell:

Get-Acl 'D:\Freigaben\Daten' |
    Format-List

Einzelne Zugriffsregeln:

(Get-Acl 'D:\Freigaben\Daten').Access |
    Select-Object IdentityReference,
                  FileSystemRights,
                  AccessControlType,
                  IsInherited,
                  InheritanceFlags,
                  PropagationFlags

Kommandozeile:

icacls D:\Freigaben\Daten

Rekursives Auslesen kann bei großen Verzeichnisstrukturen sehr umfangreich und belastend sein. Es sollte nur gezielt eingesetzt werden.

Zu prüfen sind:

11. Freigabe- und NTFS-Rechte gemeinsam bewerten

Bei einem SMB-Zugriff wirken grundsätzlich beide Ebenen:

wirksames Freigaberecht
        +
wirksames NTFS-Recht
        ↓
restriktivere wirksame Kombination

Beispiele:

Freigabe NTFS Ergebnis über SMB
Lesen Ändern Lesen
Ändern Lesen Lesen
Vollzugriff Ändern Ändern
Vollzugriff Vollzugriff Vollzugriff
Ändern keine Berechtigung kein Zugriff

Beim lokalen Zugriff auf den Serverpfad gelten die Freigabeberechtigungen nicht. Dort werden nur die Dateisystemberechtigungen ausgewertet.

Deshalb kann ein lokaler Test auf dem Server funktionieren, während der Zugriff über SMB fehlschlägt.

12. Lesen, Ändern und Vollzugriff unterscheiden

Typische NTFS-Rechte:

Recht Bedeutung
Ordnerinhalt anzeigen Ordner durchsuchen und Inhalte auflisten
Lesen Inhalte und Eigenschaften lesen
Schreiben Dateien oder Daten erstellen beziehungsweise schreiben
Lesen und Ausführen Dateien lesen und ausführbare Dateien starten
Ändern lesen, schreiben, ausführen und löschen
Vollzugriff zusätzlich Berechtigungen und Eigentum verwalten

Für normale gemeinsame Datenordner reicht häufig Ändern. Vollzugriff sollte nicht ohne fachlichen Grund vergeben werden.

13. Löschen benötigt besondere Beachtung

Zum Löschen eines Objekts kann abhängig von der ACL eines der folgenden Rechte entscheidend sein:

Dadurch können scheinbar widersprüchliche Situationen entstehen:

Die Berechtigungen müssen deshalb auf dem betroffenen Objekt und dem übergeordneten Ordner geprüft werden.

14. Vererbung kontrollieren

(Get-Acl 'D:\Freigaben\Daten\Abteilung').AreAccessRulesProtected

Mögliche Zustände:

Typische Fehler:

Berechtigungen sollten nicht rekursiv ersetzt werden, bevor Umfang, Vererbung und Rückweg vollständig geklärt sind.

15. Gruppenmitgliedschaften prüfen

AD-Mitgliedschaften eines Benutzers:

Get-ADPrincipalGroupMembership max.mustermann |
    Select-Object Name

Aktuelle Gruppen im Anmeldetoken:

whoami /groups

Aktuelles Konto:

whoami

Benutzer-SID:

whoami /user

Berechtigungen des aktuellen Tokens:

whoami /priv

Wichtige Unterscheidung:

Mitgliedschaft im Active Directory
              ≠
Mitgliedschaft im bereits erzeugten Anmeldetoken

Wurde ein Benutzer gerade einer Gruppe hinzugefügt, kann eine erneute Anmeldung erforderlich sein. Eine bloße Sperrung und Entsperrung des Bildschirms erzeugt normalerweise kein vollständig neues interaktives Anmeldetoken.

16. Effektive Berechtigungen bewerten

Die grafische Registerkarte befindet sich üblicherweise unter:

Eigenschaften
→ Sicherheit
→ Erweitert
→ Effektiver Zugriff

Dabei muss der richtige Benutzer beziehungsweise Sicherheitsprinzipal ausgewählt werden.

Zu berücksichtigen sind:

Die Anzeige der effektiven NTFS-Rechte ersetzt nicht die Prüfung der Freigabeberechtigungen.

17. Zulassen und Verweigern

Eine explizite Verweigerung kann ein ansonsten gewährtes Recht blockieren. Trotzdem darf nicht vereinfacht angenommen werden, dass jede sichtbare Verweigerung immer sämtliche Zulassungen überschreibt.

Die Auswertung hängt unter anderem ab von:

Verweigerungen sollten sparsam verwendet werden. Eine saubere Gruppen- und Ordnerstruktur ist häufig leichter zu analysieren.

18. Access-Based Enumeration

Access-Based Enumeration kann Ordner vor Benutzern ausblenden, die darauf keine Berechtigung besitzen.

Einstellung anzeigen:

Get-SmbShare -Name Daten |
    Select-Object FolderEnumerationMode

Mögliche Folge:

Ein ausgeblendeter Ordner wurde daher nicht zwangsläufig gelöscht oder nicht repliziert.

19. Geöffnete Dateien und SMB-Sitzungen prüfen

Auf dem Dateiserver:

Get-SmbSession

Geöffnete Dateien:

Get-SmbOpenFile

Gefiltert nach Pfad:

Get-SmbOpenFile |
    Where-Object {
        $_.Path -like '*\Daten\*'
    }

Wichtige Informationen:

Eine Sitzung oder Datei darf nicht ungeprüft geschlossen werden. Nicht gespeicherte Daten können verloren gehen.

20. Dateisperren untersuchen

Typische Meldungen:

Mögliche Ursachen:

Werkzeuge:

Nicht jede Meldung über eine „gesperrte Datei“ beweist eine technische SMB-Sperre. Anwendungen können eigene Sperrmechanismen verwenden.

21. SMB-Serverkonfiguration prüfen

Get-SmbServerConfiguration

Ausgewählte Werte:

Get-SmbServerConfiguration |
    Select-Object EnableSMB1Protocol,
                  EnableSMB2Protocol,
                  RequireSecuritySignature,
                  EncryptData,
                  EnableLeasing,
                  EnableOplocks,
                  AuditSmb1Access

Clientkonfiguration:

Get-SmbClientConfiguration

Zu prüfen sind:

SMB 1 darf nicht pauschal als Problemlösung aktiviert werden. Das Protokoll ist veraltet und besitzt erhebliche Sicherheitsnachteile. Bei Altgeräten ist eine Aktualisierung, Segmentierung oder Ablösung zu prüfen.

22. Verwendeten SMB-Dialekt bestimmen

Get-SmbConnection |
    Select-Object ServerName,
                  ShareName,
                  Dialect,
                  Signed,
                  Encrypted

Mögliche Beobachtungen:

Die tatsächlich verwendete Verbindung muss geprüft werden. Eine allgemeine Servereinstellung beweist noch nicht, welcher Dialekt in einer bestimmten Sitzung ausgehandelt wurde.

23. Kerberos und NTLM bei SMB

Tickets prüfen:

klist

Für SMB ist typischerweise ein Dienstticket für einen SPN nach folgendem Muster relevant:

cifs/fileserver01

SPN suchen:

setspn -Q cifs/fileserver01

Mit FQDN:

setspn -Q cifs/fileserver01.ad.example.local

Mögliche Ursachen für NTLM statt Kerberos:

Ein erfolgreicher SMB-Zugriff beweist nicht automatisch, dass Kerberos verwendet wurde.

24. Zugriff über Alias prüfen

Beispiel:

\\fileserver01\Daten
\\datenserver\Daten

Beide Namen können auf dieselbe IP-Adresse zeigen, aber für Kerberos unterschiedliche Dienstidentitäten darstellen.

Zu prüfen sind:

Ein zusätzlicher DNS-CNAME allein stellt noch nicht sicher, dass Kerberos über den Alias funktioniert.

25. DFS-Namespace untersuchen

Ein DFS-Pfad kann Benutzer auf einen oder mehrere tatsächliche Zielserver verweisen:

\\ad.example.local\Daten\Abteilung

DFS-Namespace-Informationen:

Get-DfsnRoot

Ordner und Ziele:

Get-DfsnFolder

Get-DfsnFolderTarget

Clientseitige DFS-Informationen:

dfsutil /pktinfo

DFS-Cache anzeigen:

dfsutil /pktinfo

Zu prüfen sind:

26. DFS-Namespace und DFS-Replikation unterscheiden

Funktion Aufgabe
DFS Namespace stellt einen einheitlichen logischen Pfad bereit
DFS Replication repliziert Ordnerinhalte zwischen Servern

Ein funktionierender Namespace beweist nicht, dass die Daten repliziert wurden. Umgekehrt kann die Replikation funktionieren, während ein Namespace-Ziel falsch konfiguriert oder nicht erreichbar ist.

Typisches Fehlerbild:

27. DFS-Replikation prüfen

Relevanter Ereignisprotokollpfad:

Ereignisanzeige
→ Anwendungs- und Dienstprotokolle
→ DFS Replication

PowerShell:

Get-WinEvent -FilterHashtable @{
    LogName   = 'DFS Replication'
    StartTime = (Get-Date).AddHours(-4)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  Message

Replikationsgruppen:

Get-DfsReplicationGroup

Mitgliedschaften:

Get-DfsrMembership

Verbindungen:

Get-DfsrConnection

Zu dokumentieren sind:

Eine manuell erzwungene Synchronisation ist keine erste Diagnosemaßnahme.

28. Offline Files und Clientcache

Windows kann Netzwerkdateien lokal zwischenspeichern. Dadurch können Benutzer zeitweise mit einer lokalen Kopie arbeiten.

Mögliche Fehlerbilder:

Zu prüfen sind:

Der Offlinecache darf nicht ungeprüft zurückgesetzt werden. Nicht synchronisierte Benutzerdaten könnten verloren gehen.

29. Quotas und freier Speicherplatz

Freien Speicherplatz prüfen:

Get-Volume

Dateisystemlaufwerke:

Get-PSDrive -PSProvider FileSystem

FSRM-Quotas:

Get-FsrmQuota

Mögliche Symptome:

Zu unterscheiden sind:

30. Lange Pfade und Dateinamen

Mögliche Ursachen:

Typische reservierte Namen unter Windows sind beispielsweise:

CON
PRN
AUX
NUL
COM1
LPT1

Die Unterstützung langer Pfade hängt nicht nur vom Betriebssystem ab. Auch Anwendung, API und Konfiguration müssen sie unterstützen.

31. Eigentümer und ACL-Zustand

Eigentümer anzeigen:

(Get-Acl 'D:\Freigaben\Daten').Owner

Mögliche Probleme:

Nicht auflösbare SIDs beweisen allein keinen Fehler. Sie können noch wirksame Sicherheitskennungen ehemaliger oder nicht erreichbarer Domänenkonten darstellen und müssen vor einer Entfernung zugeordnet werden.

32. Ereignisprotokolle für SMB prüfen

Wichtige Protokollpfade können sein:

Microsoft
→ Windows
→ SMBClient
→ Connectivity

Microsoft
→ Windows
→ SMBClient
→ Security

Microsoft
→ Windows
→ SMBServer
→ Operational

Microsoft
→ Windows
→ SMBServer
→ Security

PowerShell-Beispiel:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-SMBClient/Connectivity'
    StartTime = (Get-Date).AddHours(-2)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  Message

Zusätzlich können relevant sein:

Event-ID, Provider, Zeitpunkt, Server, Client und vollständiger Ereignistext müssen gemeinsam bewertet werden.

33. SMB-Netzwerkverkehr untersuchen

Bei unklarem Netzwerk- oder Protokollfehler kann ein Paketmitschnitt erforderlich sein.

Typische Filter:

tcp.port == 445

smb2

ip.addr == 192.0.2.20 && tcp.port == 445

Zu untersuchen sind:

Ein Paketmitschnitt kann Datei- und Benutzernamen sowie weitere vertrauliche Informationen enthalten und muss geschützt gespeichert werden.

34. Druckpfad verstehen

Anwendung
   ↓
Druckertreiber
   ↓
Windows-Druckwarteschlange
   ↓
Spooler
   ↓
Druckserver oder direkter TCP/IP-Port
   ↓
Netzwerk
   ↓
Drucker
   ↓
Druckwerk, Papier und Verbrauchsmaterial

Die Meldung „Drucker druckt nicht“ kann daher verursacht werden durch:

35. Druckerfehler exakt eingrenzen

Zu dokumentieren sind:

Diese Tests trennen Anwendung, Benutzer, Client, Treiber, Queue, Server und Gerät voneinander.

36. Drucker und Warteschlangen anzeigen

PowerShell:

Get-Printer

Ausgewählte Eigenschaften:

Get-Printer |
    Select-Object Name,
                  ComputerName,
                  DriverName,
                  PortName,
                  Shared,
                  ShareName,
                  PrinterStatus,
                  JobCount

Bestimmter Drucker:

Get-Printer -Name 'Drucker-01'

Druckaufträge:

Get-PrintJob -PrinterName 'Drucker-01'

Druckerkonfiguration:

Get-PrintConfiguration -PrinterName 'Drucker-01'

37. Print Spooler prüfen

Get-Service Spooler

Ausführlicher:

Get-CimInstance Win32_Service `
    -Filter "Name='Spooler'" |
    Select-Object Name,
                  State,
                  StartMode,
                  StartName,
                  ProcessId

Abhängigkeiten:

Get-Service Spooler -DependentServices

Ein Neustart des Spoolers:

Restart-Service Spooler

verändert den Zustand und kann alle lokalen beziehungsweise serverseitigen Druckaufträge beeinflussen. Vorher sind zu prüfen:

38. Druckaufträge kontrollieren

Get-PrintJob -PrinterName 'Drucker-01' |
    Select-Object ID,
                  DocumentName,
                  UserName,
                  SubmittedTime,
                  JobStatus,
                  Size

Einzelnen Auftrag entfernen:

Remove-PrintJob `
    -PrinterName 'Drucker-01' `
    -ID 17

Vor dem Entfernen prüfen:

Nicht sofort die gesamte Warteschlange leeren, wenn ein einzelner Auftrag die Ursache sein könnte.

39. Druckerport prüfen

Get-PrinterPort

Bestimmter Port:

Get-PrinterPort -Name 'IP_192.0.2.50'

Zu prüfen sind:

Porttest für RAW Printing:

Test-NetConnection 192.0.2.50 -Port 9100

Mögliche weitere Protokolle hängen vom Drucksystem ab, beispielsweise IPP, IPPS, LPR oder SMB.

40. SNMP-Statusfehler

Ein Drucker kann erreichbar und druckfähig sein, aber in Windows als offline erscheinen, wenn die SNMP-Statusabfrage fehlschlägt.

Mögliche Ursachen:

Das Deaktivieren des SNMP-Status kann als kontrollierter Diagnosetest dienen. Es ist jedoch keine allgemeine Lösung, weil dadurch echte Gerätestatusinformationen verloren gehen können.

41. Druckertreiber untersuchen

Installierte Treiber:

Get-PrinterDriver

Mögliche Treiberprobleme:

Treiber dürfen nicht ungeprüft auf einem produktiven Druckserver ersetzt werden. Dadurch können mehrere Warteschlangen und Benutzer betroffen sein.

42. Windows-Testseite verwenden

Eine Testseite trennt die Anwendung teilweise vom restlichen Druckpfad.

PowerShell über WMI/CIM:

Invoke-CimMethod `
    -ClassName Win32_Printer `
    -MethodName PrintTestPage `
    -Arguments @{} `
    -Filter "Name='Drucker-01'"

Bewertung:

Ergebnis Wahrscheinlicher Bereich
Testseite funktioniert, Anwendung nicht Anwendung, Dokument, Format oder anwendungsspezifische Einstellungen
Testseite bleibt in Queue Spooler, Treiber, Port oder Druckserver
Auftrag verlässt Queue, Drucker reagiert nicht Port, Netzwerk, Protokoll oder Gerät
Auftrag wird gedruckt, Ausgabe fehlerhaft Treiber, Druckersprache, Gerätekonfiguration oder Hardware
alle Drucker betroffen Spooler, Server, Richtlinie oder gemeinsamer Dienst
nur ein Drucker betroffen Queue, Port, Treiber oder Gerät

43. Druckereignisse prüfen

Wichtiger Protokollpfad:

Ereignisanzeige
→ Anwendungs- und Dienstprotokolle
→ Microsoft
→ Windows
→ PrintService
→ Operational

Das Operational-Protokoll muss je nach System zunächst aktiviert werden.

PowerShell:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-PrintService/Operational'
    StartTime = (Get-Date).AddHours(-2)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  Message

Zusätzlich prüfen:

44. CUPS unter Linux und macOS prüfen

Druckerstatus:

lpstat -t

Standarddrucker:

lpstat -d

Warteschlange:

lpq

Druckaufträge:

lpstat -o

Auftrag abbrechen:

cancel <Auftrags-ID>

Alle Aufträge eines Druckers abbrechen:

cancel -a <Druckername>

CUPS-Dienst unter systemd:

systemctl status cups

Protokoll:

journalctl -u cups

Je nach System können die CUPS-Protokolle zusätzlich unter folgendem Pfad liegen:

/var/log/cups/

Zu prüfen sind:

45. Typische Fehlerbilder

Symptom Mögliche Ursache Nächster Test
Servername nicht erreichbar DNS oder Netzwerk Resolve-DnsName, Test-NetConnection
IP funktioniert, Name nicht DNS, Alias oder SPN Kurzname, FQDN und DNS-Einträge vergleichen
TCP 445 nicht erreichbar Firewall, Routing oder SMB-Dienst Porttest und Serverstatus
Freigabe nicht gefunden falscher Name oder Freigabe fehlt Get-SmbShare, net share
Freigabe öffnet sich, Unterordner nicht NTFS-Rechte oder ABE ACL und effektiven Zugriff prüfen
Datei lesbar, aber nicht änderbar fehlendes Schreib- oder Änderungsrecht Share- und NTFS-Rechte
Datei änderbar, aber nicht löschbar Löschrecht oder Eltern-ACL Datei- und Ordner-ACL prüfen
Zugriff lokal möglich, über SMB nicht Freigaberecht oder SMB-Pfad Get-SmbShareAccess
neuer Gruppeneintrag wirkt nicht altes Anmeldetoken whoami /groups, erneute Anmeldung
Zugriff verweigert trotz Gruppenmitgliedschaft Verweigerung, falsches Token oder NTFS-Recht effektiven Zugriff prüfen
Datei angeblich in Verwendung offenes Handle oder Anwendungssperre Get-SmbOpenFile
Zugriff über Alias schlägt fehl SPN oder Kerberos klist, setspn -Q
DFS-Pfad zeigt alte Daten falsches Ziel oder DFS-R-Störung dfsutil /pktinfo, DFS-R-Ereignisse
Dateien unterscheiden sich je nach Client unterschiedliche DFS-Ziele Zielserver und Replikation vergleichen
Speichern schlägt ab bestimmter Größe fehl Quota oder freier Speicher Volume und FSRM prüfen
Drucker für alle Benutzer offline Netzwerk, Port oder Gerät Porttest und Druckerstatus
nur ein Benutzer kann nicht drucken Berechtigung oder Benutzerprofil Druckerrechte und Vergleichsbenutzer
nur eine Anwendung druckt nicht Anwendung oder Dokument Windows-Testseite
alle Drucker eines Servers betroffen Spooler oder Druckserver Dienst und Ereignisse
nur eine Queue betroffen Auftrag, Treiber oder Port Queue, Treiber und Port
Auftrag bleibt in Warteschlange Spooler, Treiber oder Port PrintService-Protokoll
Auftrag verschwindet, kein Ausdruck Protokoll, Gerät oder Druckersprache Druckerprotokoll und Port
Drucker fälschlich offline SNMP-Statusabfrage SNMP-Konfiguration prüfen
Spooler stürzt wiederholt ab Treiber oder Print Processor Ereignisse und Treiberzuordnung

46. Vorgehensweise bei „Zugriff verweigert“

  1. vollständigen UNC-Pfad dokumentieren.
  2. Benutzer und Client bestimmen.
  3. konkrete fehlgeschlagene Aktion erfassen.
  4. verwendetes Konto mit whoami prüfen.
  5. aktuelle Gruppen mit whoami /groups prüfen.
  6. Servername und Zieladresse prüfen.
  7. SMB-Verbindung und verwendete Anmeldedaten prüfen.
  8. Freigabeberechtigungen auslesen.
  9. NTFS-Berechtigungen des betroffenen Objekts prüfen.
  10. Vererbung und Eigentümer berücksichtigen.
  11. Berechtigungen des übergeordneten Ordners prüfen.
  12. explizite Verweigerungen untersuchen.
  13. Test mit einem funktionierenden Benutzer durchführen.
  14. genau eine kontrollierte Korrektur umsetzen.
  15. Zugriff mit der ursprünglichen Aktion erneut testen.
  16. Rechte nach dem Minimalprinzip dokumentieren.

47. Vorgehensweise bei „Datei ist gesperrt“

  1. Dateiname und vollständigen Pfad erfassen.
  2. Benutzer, Client und Anwendung bestimmen.
  3. prüfen, ob Lesen oder nur Bearbeiten fehlschlägt.
  4. Get-SmbOpenFile auf dem Dateiserver auswerten.
  5. Anwendungssperrdateien berücksichtigen.
  6. Serverprozesse mit Handle oder Process Explorer prüfen.
  7. Virenscanner, Backup und Synchronisation berücksichtigen.
  8. Rechte zum Ändern und Löschen prüfen.
  9. Benutzer kontaktieren, der die Datei geöffnet hält.
  10. ungespeicherte Daten ausschließen.
  11. erst danach gezielt das Handle oder die Sitzung schließen.
  12. Datei erneut öffnen, ändern und speichern.
  13. Ursache und Auswirkung dokumentieren.

48. Vorgehensweise bei DFS-Problemen

  1. logischen DFS-Pfad dokumentieren.
  2. Client und Benutzer bestimmen.
  3. DFS-Referral des Clients prüfen.
  4. tatsächlichen Zielserver dokumentieren.
  5. Zielserver per DNS und TCP 445 prüfen.
  6. direkten UNC-Pfad zum Zielserver testen.
  7. Namespace-Ordner und Ziele prüfen.
  8. AD-Site und Zielpriorität berücksichtigen.
  9. Rechte auf allen Zielen vergleichen.
  10. Dateistände und Zeitstempel vergleichen.
  11. DFS-R-Ereignisse prüfen.
  12. Replikationsrichtung und Backlog untersuchen.
  13. nur die nachgewiesene Ursache korrigieren.
  14. Clientzugriff und Replikation erneut prüfen.

49. Vorgehensweise bei Druckproblemen

  1. Drucker, Queue, Server und Port dokumentieren.
  2. genaue Meldung und Zeitpunkt erfassen.
  3. Umfang bestimmen: ein Benutzer, Client, Drucker oder alle.
  4. Warteschlange und Auftragsstatus prüfen.
  5. Windows-Testseite auslösen.
  6. Spoolerstatus prüfen.
  7. PrintService-Ereignisse auswerten.
  8. Druckername und IP-Adresse prüfen.
  9. tatsächlichen Druckerport testen.
  10. SNMP-Status kontrollieren.
  11. Treibername und Version prüfen.
  12. Berechtigungen der Queue prüfen.
  13. Gerätestatus und Verbrauchsmaterial prüfen.
  14. genau eine kontrollierte Maßnahme durchführen.
  15. Testseite und ursprüngliches Dokument erneut drucken.
  16. Ereignisse und Queue nachkontrollieren.

50. Maßnahmen und Rückwege

Ursache: falsche Freigabeberechtigung

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: fehlende NTFS-Berechtigung

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: altes Anmeldetoken

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: falsches DFS-Ziel

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: fehlerhafter Druckerport

Nachweis:

Maßnahme:

Rollback:

Verifikation:

51. Nachkontrolle

Nach einer Maßnahme sind mindestens folgende Punkte zu prüfen:

52. Dokumentationsbeispiel

Symptom:
Der Benutzer konnte Dateien in der Freigabe lesen, aber keine neue Datei
im Unterordner „Projekte“ erstellen.

Zeitpunkt:
02.08.2026, 11:26 Uhr MESZ

Benutzer:
max.mustermann

Client:
CLIENT-17

Pfad:
\\fileserver01.ad.example.local\Daten\Projekte

Nachweis:
DNS-Auflösung und TCP 445 waren erfolgreich.
Die SMB-Verbindung verwendete das vorgesehene Domänenkonto.
Die Freigabeberechtigung gewährte der zuständigen Gruppe „Ändern“.
Die NTFS-Auswertung zeigte jedoch nur Leserechte auf dem Unterordner.
Die Vererbung war an diesem Unterordner deaktiviert worden.

Ursache:
Bei einer früheren manuellen ACL-Änderung wurde die Vererbung auf dem
Unterordner unterbrochen. Dadurch fehlte der vorgesehenen Gruppe das
Änderungsrecht.

Maßnahme:
Nach Sicherung der bestehenden ACL wurde die freigegebene
Berechtigungsstruktur des übergeordneten Ordners wiederhergestellt.

Rollback:
Die zuvor exportierte ACL kann wieder eingespielt werden.

Verifikation:
Der Benutzer kann Dateien lesen, erstellen, ändern und löschen.
Er kann keine Berechtigungen verändern.
Andere Abteilungsordner bleiben weiterhin unzugänglich.
Es wurden keine zusätzlichen administrativen Rechte vergeben.

Prävention:
Berechtigungsänderungen erfolgen künftig ausschließlich über dokumentierte
Sicherheitsgruppen und werden durch einen Test des effektiven Zugriffs geprüft.

53. Entscheidungsbaum

Datei- oder Freigabezugriff gestört
        ↓
Wird der richtige Servername aufgelöst?
        ├── Nein
        │   ↓
        │   DNS, Alias und DFS-Namen prüfen
        │
        └── Ja
            ↓
Ist TCP 445 erreichbar?
        ├── Nein
        │   ↓
        │   Routing, Firewall und SMB-Dienst prüfen
        │
        └── Ja
            ↓
Existiert die Freigabe und zeigt sie auf den richtigen Pfad?
        ├── Nein
        │   ↓
        │   Freigabe- und Serverkonfiguration prüfen
        │
        └── Ja
            ↓
Wird das vorgesehene Benutzerkonto verwendet?
        ├── Nein
        │   ↓
        │   bestehende Verbindungen und Anmeldedaten prüfen
        │
        └── Ja
            ↓
Sind Freigabeberechtigungen ausreichend?
        ├── Nein
        │   ↓
        │   Freigabe-ACL kontrolliert korrigieren
        │
        └── Ja
            ↓
Sind NTFS-Berechtigungen ausreichend?
        ├── Nein
        │   ↓
        │   ACL, Vererbung, Gruppen und Token prüfen
        │
        └── Ja
            ↓
Ist nur eine Datei oder Aktion betroffen?
        ├── Ja
        │   ↓
        │   Sperre, Einzel-ACL, Pfad, Quota und Anwendung prüfen
        │
        └── Nein
            ↓
DFS, Storage, Serverzustand und zentrale Abhängigkeiten prüfen

54. Typische Prüfungsfragen

Warum reicht ein erfolgreicher Ping zum Dateiserver nicht als Funktionsnachweis?

Antwort anzeigen

Ein Ping prüft eine bestimmte ICMP-Kommunikation. Er beweist weder die Erreichbarkeit von TCP 445 noch eine erfolgreiche SMB-Authentifizierung oder ausreichende Freigabe- und NTFS-Berechtigungen.

Welche Berechtigungen wirken bei einem SMB-Zugriff auf einen NTFS-Ordner?

Antwort anzeigen

Es wirken sowohl die Freigabe- als auch die NTFS-Berechtigungen. Für den Zugriff über das Netzwerk ergibt sich die wirksame Berechtigung aus der restriktiveren Kombination beider Ebenen.

Warum kann der lokale Zugriff auf einen Serverordner funktionieren, während der SMB-Zugriff fehlschlägt?

Antwort anzeigen

Beim lokalen Zugriff werden keine SMB-Freigabeberechtigungen ausgewertet. Über das Netzwerk wirken zusätzlich zu den NTFS-Rechten auch die Freigabeberechtigungen und die SMB-Authentifizierung.

Warum kann eine neue Gruppenmitgliedschaft noch nicht wirksam sein?

Antwort anzeigen

Die Gruppe kann bereits im Active Directory eingetragen sein, aber im aktuellen Anmeldetoken fehlen. Häufig ist eine erneute Benutzeranmeldung erforderlich, damit ein neues Token erzeugt wird.

Worin unterscheiden sich DFS Namespace und DFS Replication?

Antwort anzeigen

DFS Namespace stellt einen einheitlichen logischen Zugriffspfad bereit. DFS Replication synchronisiert Ordnerinhalte zwischen mehreren Servern. Beide Funktionen können unabhängig voneinander gestört sein.

Warum sollte eine geöffnete SMB-Datei nicht sofort zwangsweise geschlossen werden?

Antwort anzeigen

Die zugehörige Anwendung kann noch nicht gespeicherte Änderungen besitzen. Ein erzwungenes Schließen kann Datenverlust oder beschädigte Anwendungszustände verursachen.

Warum beweist ein erfolgreicher Zugriff über einen Alias nicht automatisch die Verwendung von Kerberos?

Antwort anzeigen

Fehlt ein passender CIFS-SPN für den Alias, kann der Zugriff abhängig von der Umgebung über NTLM erfolgen. Tickets und SPN-Zuordnung müssen gesondert geprüft werden.

Welche Funktion besitzt der Print Spooler?

Antwort anzeigen

Der Print Spooler nimmt Druckaufträge entgegen, verarbeitet beziehungsweise zwischenspeichert sie und übergibt sie über die konfigurierte Warteschlange und den Druckerport an das Ziel.

Warum kann ein Drucker fälschlich als offline angezeigt werden?

Antwort anzeigen

Die eigentliche Druckverbindung kann funktionieren, während die SNMP-Statusabfrage fehlschlägt. Ursachen können eine falsche Community, blockiertes UDP 161 oder eine fehlerhafte SNMP-Konfiguration sein.

55. Prüfungsfallen

56. Checkliste

57. Schnellreferenz

Beobachtung Nächstes Werkzeug
Servername zeigt auf falsche IP Resolve-DnsName, nslookup
SMB-Port nicht erreichbar Test-NetConnection -Port 445
bestehende Netzlaufwerke unklar net use, Get-SmbMapping
verwendetes SMB-Konto unklar Get-SmbConnection
Freigabe fehlt Get-SmbShare, net share
Freigaberecht unklar Get-SmbShareAccess
NTFS-Recht unklar Get-Acl, icacls
aktuelle Gruppen unklar whoami /groups
Datei gesperrt Get-SmbOpenFile, Handle
SMB-Sitzung unklar Get-SmbSession
SMB-Version unklar Get-SmbConnection
Alias funktioniert nicht klist, setspn -Q
DFS-Ziel unklar dfsutil /pktinfo
DFS-Konfiguration unklar Get-DfsnFolderTarget
DFS-R-Störung DFS-Replication-Protokoll
Speicherplatz unklar Get-Volume, Get-PSDrive
Quota vermutet Get-FsrmQuota
Druckerstatus unklar Get-Printer
Druckaufträge hängen Get-PrintJob
Spoolerstatus unklar Get-Service Spooler
Druckerport unklar Get-PrinterPort
Treiber unklar Get-PrinterDriver
Druckereignis gesucht PrintService/Operational
CUPS-Status unklar lpstat -t, journalctl -u cups

Merksatz

Bei Datei- und Freigabefehlern wird vom Namen über TCP 445, SMB-Sitzung und Authentifizierung bis zu Freigabe- und NTFS-Rechten geprüft. Bei Druckfehlern wird der Weg von Anwendung und Treiber über Queue, Spooler und Port bis zum physischen Drucker verfolgt. Rechte, Sitzungen, Dateien und Druckaufträge werden erst verändert, wenn Ursache, Auswirkung und Rückweg geklärt sind.

Quellen und weiterführende Dokumentation

Offizielle Microsoft-Dokumentation

Offizielle CUPS-Dokumentation

8. Betriebssystem- und Serveranalyse

8.4 Linux-Server – Dienste, Prozesse, Protokolle, Ressourcen und Speicher

1. Ziel dieser Seite

Diese Seite beschreibt die strukturierte Fehleranalyse auf Linux-Servern.

Typische Störungen betreffen:

Das Ziel ist nicht, einen Dienst möglichst schnell neu zu starten. Zuerst werden Fehlerzustand, Ursache, Auswirkungen und Rückweg dokumentiert.

2. Diagnosegrundsatz

Symptom erfassen
        ↓
Umfang bestimmen
        ↓
Systemzustand und Zeitpunkt prüfen
        ↓
Dienst, Prozess und Port untersuchen
        ↓
Protokolle auswerten
        ↓
Abhängigkeiten prüfen
        ↓
Konfiguration und Berechtigungen prüfen
        ↓
Ressourcen und Storage prüfen
        ↓
Ursache nachweisen
        ↓
Eine kontrollierte Maßnahme durchführen
        ↓
Funktion und Nebenwirkungen kontrollieren

Ein erfolgreicher Prozessstart beweist noch keine funktionierende Anwendung. Ebenso beweist ein offener Port nicht, dass die Anwendung korrekte Antworten liefert.

3. Fehlerbild exakt erfassen

Zu dokumentieren sind:

Wichtige Abgrenzungsfragen:

4. System identifizieren

Hostname:

hostnamectl

Kurzer Hostname:

hostname

Betriebssysteminformationen:

cat /etc/os-release

Kernelversion und Architektur:

uname -a

Nur Kernelversion:

uname -r

Architektur:

uname -m

Systemlaufzeit und Last:

uptime

Letzter Systemstart:

who -b

Aktuelle Zeit und Zeitzone:

timedatectl

Diese Informationen sind wichtig, weil Befehle, Dateipfade, Paketmanager, Sicherheitsmodule und Protokollierung je nach Distribution und Version unterschiedlich sein können.

5. Letzte Änderungen bestimmen

Mögliche Ursachen kurz vor Beginn einer Störung:

Anmeldehistorie:

last

Fehlgeschlagene Anmeldungen, sofern unterstützt und berechtigt:

lastb

Letzte Neustarts:

last reboot

Zeitstempel einer Datei:

stat /etc/example/application.conf

RPM-basierte Systeme:

dnf history

Debian- und Ubuntu-Systeme:

grep -E ' install | upgrade | remove ' /var/log/dpkg.log

Rotierte Protokolle müssen gegebenenfalls zusätzlich geprüft werden.

6. systemd-Gesamtzustand prüfen

Fehlgeschlagene Units:

systemctl --failed

Systemzustand:

systemctl is-system-running

Alle geladenen Dienste:

systemctl list-units --type=service --all

Installierte Unit-Dateien:

systemctl list-unit-files --type=service

Abweichende oder lokal angepasste Units:

systemd-delta

Ein System kann als degraded angezeigt werden, obwohl die vom Benutzer benötigte Anwendung funktioniert. Deshalb müssen die fehlgeschlagenen Units einzeln bewertet werden.

7. Dienststatus untersuchen

Beispieldienst:

systemctl status example.service

Aktivitätsstatus:

systemctl is-active example.service

Autostartstatus:

systemctl is-enabled example.service

Fehlerzustand:

systemctl is-failed example.service

Ausgewählte Eigenschaften:

systemctl show example.service \
    -p ActiveState \
    -p SubState \
    -p Result \
    -p ExecMainCode \
    -p ExecMainStatus \
    -p MainPID \
    -p User \
    -p Group \
    -p FragmentPath

Zu unterscheiden sind:

enabled bedeutet nicht, dass der Dienst gerade läuft. active bedeutet nicht automatisch, dass er beim nächsten Systemstart wieder gestartet wird.

8. Dienstprotokoll mit journalctl prüfen

Aktuelles Dienstprotokoll:

journalctl -u example.service

Nur aktueller Systemstart:

journalctl -u example.service -b

Vorheriger Systemstart:

journalctl -u example.service -b -1

Letzte 100 Einträge:

journalctl -u example.service -n 100

Fortlaufende Anzeige:

journalctl -u example.service -f

Bestimmter Zeitraum:

journalctl -u example.service \
    --since "2026-08-02 10:00:00" \
    --until "2026-08-02 11:00:00"

Warnungen und schwerere Meldungen des aktuellen Starts:

journalctl -b -p warning

Kernelmeldungen des aktuellen Starts:

journalctl -k -b

Ausführliche Ausgabe:

journalctl -u example.service -o verbose

Zu dokumentieren sind:

Die letzte Fehlermeldung muss nicht die eigentliche Ursache sein. Häufig steht die erste relevante Meldung weiter oben.

9. Klassische Protokolldateien

Je nach Distribution und Dienst können zusätzlich relevant sein:

/var/log/syslog
/var/log/messages
/var/log/auth.log
/var/log/secure
/var/log/kern.log
/var/log/audit/audit.log
/var/log/dmesg
/var/log/cron
/var/log/maillog

Anwendungsprotokolle befinden sich häufig unter:

/var/log/<Anwendung>/

Letzte Zeilen anzeigen:

tail -n 100 /var/log/syslog

Fortlaufend beobachten:

tail -f /var/log/example/application.log

Komprimierte rotierte Protokolle durchsuchen:

zgrep -i 'error' /var/log/example/application.log*.gz

Nicht jede Distribution verwendet alle genannten Dateien. Auf ausschließlich journalbasierten Systemen können einzelne klassische Protokolldateien fehlen.

10. Unit-Datei und Überschreibungen prüfen

Wirksame Unit einschließlich Drop-ins anzeigen:

systemctl cat example.service

Pfad und Drop-ins:

systemctl show example.service \
    -p FragmentPath \
    -p DropInPaths

Abhängigkeiten:

systemctl list-dependencies example.service

Umgekehrte Abhängigkeiten:

systemctl list-dependencies --reverse example.service

Startreihenfolge und Abhängigkeiten können beeinflusst werden durch:

After= legt eine Reihenfolge fest, erzeugt allein aber keine Startabhängigkeit.

11. systemd-Konfiguration verifizieren

Unit-Dateien prüfen:

systemd-analyze verify example.service

Nach einer Änderung an Unit-Dateien:

systemctl daemon-reload

daemon-reload lädt die systemd-Konfiguration neu. Es startet den betroffenen Dienst nicht automatisch neu.

Vor einem Neustart des Dienstes sind zu prüfen:

12. Anwendungsidentität prüfen

Der Dienst kann unter einem anderen Benutzer laufen als erwartet.

systemd-Konfiguration:

systemctl show example.service \
    -p User \
    -p Group \
    -p SupplementaryGroups \
    -p DynamicUser

Prozessbenutzer:

ps -eo user,group,pid,ppid,stat,lstart,cmd

Bestimmter Prozess:

ps -o user,group,pid,ppid,stat,lstart,cmd -p <PID>

Benutzerinformationen:

id exampleuser

Gruppen eines Benutzers:

id -nG exampleuser

Kontoeintrag:

getent passwd exampleuser

Gruppeneintrag:

getent group examplegroup

getent berücksichtigt die konfigurierte Namensdienstauflösung und ist deshalb bei LDAP-, Active-Directory- oder SSSD-Umgebungen häufig aussagekräftiger als das alleinige Lesen von /etc/passwd.

13. Prozesse untersuchen

Alle Prozesse:

ps aux

Hierarchische Darstellung:

ps -ef --forest

Prozesse eines Benutzers:

ps -u exampleuser -f

Prozess anhand des Namens suchen:

pgrep -a example

Prozessbaum:

pstree -ap

Dynamische Anzeige:

top

Falls installiert:

htop

Zu prüfen sind:

14. Prozesszustände bewerten

Wichtige Zustände in ps:

Zustand Bedeutung
R läuft oder ist ausführbar
S unterbrechbarer Schlafzustand
D nicht unterbrechbarer Schlafzustand, häufig I/O-bezogen
T angehalten oder verfolgt
Z Zombieprozess
I inaktiver Kernelthread

Ein Prozess im Zustand D kann häufig nicht sofort beendet werden, weil er auf eine Kernel- oder I/O-Operation wartet.

Ein Zombie verbraucht normalerweise kaum Ressourcen. Er zeigt jedoch, dass der Elternprozess den Beendigungsstatus des Kindprozesses noch nicht abgeholt hat.

15. Signale und Prozessbeendigung

Normale Beendigungsanforderung:

kill -TERM <PID>

Standardsignal von kill:

kill <PID>

Erzwungene Beendigung:

kill -KILL <PID>

Signale anzeigen:

kill -l

SIGTERM erlaubt einem Prozess eine kontrollierte Beendigung. SIGKILL kann nicht abgefangen werden und verhindert eine geordnete Bereinigung.

Vor einer Prozessbeendigung prüfen:

Ein von systemd verwalteter Prozess sollte normalerweise über die zuständige Unit und nicht ausschließlich über seine PID gesteuert werden.

16. Offene Dateien und Arbeitsverzeichnisse prüfen

Offene Dateien eines Prozesses:

lsof -p <PID>

Prozesse mit Zugriff auf eine Datei:

lsof /var/lib/example/data.db

Alternativ:

fuser -v /var/lib/example/data.db

Prozesse auf einem Mountpoint:

fuser -vm /mnt/data

Gelöschte, aber weiterhin geöffnete Dateien:

lsof +L1

Eine gelöschte Datei kann weiterhin Speicherplatz belegen, solange ein Prozess sie geöffnet hält. Der Speicher wird normalerweise erst nach dem Schließen des Deskriptors freigegeben.

17. Ausführbare Datei und Bibliotheken prüfen

Verwendete Binärdatei:

readlink -f /proc/<PID>/exe

Arbeitsverzeichnis:

readlink -f /proc/<PID>/cwd

Kommandozeile:

tr '\0' ' ' < /proc/<PID>/cmdline

Umgebungsvariablen, nur mit erforderlicher Berechtigung:

tr '\0' '\n' < /proc/<PID>/environ

Bibliotheksabhängigkeiten:

ldd /usr/local/bin/example

ldd sollte nicht ungeprüft auf nicht vertrauenswürdige ausführbare Dateien angewendet werden. Je nach Datei und Implementierung kann dabei ein Sicherheitsrisiko entstehen.

18. Anwendungskonfiguration prüfen

Zu prüfen sind:

Datei anzeigen:

sed -n '1,200p' /etc/example/application.conf

Dateieigenschaften:

stat /etc/example/application.conf

Viele Dienste besitzen einen eigenen Syntaxprüfer. Beispiele:

sshd -t

nginx -t

apachectl configtest

Der passende Prüfbefehl muss zur tatsächlich installierten Anwendung und Version passen.

19. Dateirechte prüfen

Lange Darstellung:

ls -la /var/lib/example

Numerische IDs:

ls -lan /var/lib/example

Alle Bestandteile eines Pfades prüfen:

namei -l /var/lib/example/data/file.db

Dateistatus:

stat /var/lib/example/data/file.db

ACL anzeigen:

getfacl /var/lib/example/data/file.db

Zu prüfen sind:

Für das Betreten eines Verzeichnisses wird das Ausführungsrecht benötigt. Ausreichende Rechte auf der Datei allein genügen nicht, wenn ein übergeordnetes Verzeichnis nicht durchlaufen werden darf.

20. Zugriff als Dienstbenutzer testen

Kontrollierter Lesetest:

sudo -u exampleuser -- test -r /var/lib/example/data/file.db

Schreibbarkeit eines Verzeichnisses:

sudo -u exampleuser -- test -w /var/lib/example/data

Pfadzugriff:

sudo -u exampleuser -- namei -l /var/lib/example/data/file.db

Ein Test sollte möglichst dieselbe Identität, denselben Pfad und dieselbe Aktion wie die Anwendung verwenden.

Keine produktiven Dateien ungeprüft verändern oder überschreiben. Für Schreibtests ist eine dafür vorgesehene Testdatei zu verwenden.

21. SELinux prüfen

Status:

getenforce

Ausführlicher Status:

sestatus

Dateikontext:

ls -lZ /var/lib/example

Prozesskontext:

ps -eZ

Aktuelle AVC-Meldungen:

ausearch \
    -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR \
    -ts recent

Auswertung, sofern setroubleshoot installiert ist:

sealert -a /var/log/audit/audit.log

Sollkontext eines Pfades prüfen:

matchpathcon /var/lib/example/data

Kontext anhand der Richtlinie wiederherstellen:

restorecon -Rv /var/lib/example

SELinux darf nicht pauschal deaktiviert werden, nur um eine Anwendung zum Laufen zu bringen. Eine Ablehnung weist häufig auf einen falschen Pfad, falsches Label, eine unpassende Dienstkonfiguration oder eine fehlende gezielte Richtlinie hin.

Ein Wechsel in den permissiven Modus verändert den Sicherheitszustand des gesamten Systems und ist keine harmlose Standarddiagnose.

22. AppArmor prüfen

Status:

aa-status

Kernel- und Auditmeldungen:

journalctl -k | grep -i apparmor

Je nach System:

grep -i apparmor /var/log/syslog

Mögliche Ursachen:

Ein Profil sollte nicht ungeprüft deaktiviert werden. Zuerst sind Ablehnung, betroffener Pfad und notwendige Mindestberechtigung zu bestimmen.

23. Port und Socket prüfen

Lauschende TCP- und UDP-Sockets:

ss -tulpn

Nur lauschende TCP-Sockets:

ss -ltnp

Bestimmter Port:

ss -ltnp 'sport = :443'

Bestehende TCP-Verbindungen:

ss -tanp

Unix-Sockets:

ss -lxnp

Zu unterscheiden sind:

24. Portkonflikt untersuchen

Belegung eines Ports:

ss -ltnp 'sport = :8080'

Alternativ:

lsof -nP -iTCP:8080 -sTCP:LISTEN

Mögliche Ursachen:

Ein Prozess darf nicht allein deshalb beendet werden, weil er den gewünschten Port belegt. Zuerst muss seine Funktion und Zuständigkeit geklärt werden.

25. Lokale Anwendungsfunktion prüfen

TCP-Verbindung:

nc -vz 127.0.0.1 8080

HTTP-Abfrage:

curl -v http://127.0.0.1:8080/

HTTPS einschließlich Zertifikatsprüfung:

curl -v https://server.example.local/

TLS-Verbindung untersuchen:

openssl s_client \
    -connect server.example.local:443 \
    -servername server.example.local

Bewertung:

Ergebnis Wahrscheinlicher Bereich
lokal kein Listener Dienst, Konfiguration oder Startfehler
lokal erreichbar, remote nicht Firewall, Routing, Bind-Adresse oder Netzwerk
TCP funktioniert, HTTP fehlerhaft Anwendung, Reverse Proxy oder Backend
HTTP über IP funktioniert, Name nicht DNS, Virtual Host, SNI oder Zertifikat
TLS schlägt fehl Zertifikat, Schlüssel, Protokoll oder Cipher
Antwort langsam Anwendung, Backend, DNS, Storage oder Ressourcen

26. Netzwerkkonfiguration prüfen

Adressen:

ip address show

Kurzform:

ip -br address

Links:

ip -br link

Routingtabelle:

ip route show

IPv6-Routen:

ip -6 route show

Route zu einem konkreten Ziel:

ip route get 192.0.2.20

Nachbarn:

ip neigh show

Netzwerkstatistik:

ip -s link show

Zu prüfen sind:

27. Namensauflösung prüfen

Resolverkonfiguration:

cat /etc/resolv.conf

Auf systemd-resolved-Systemen:

resolvectl status

Namensauflösung über NSS:

getent hosts server.example.local

DNS-Abfrage:

dig server.example.local

Bestimmten DNS-Server abfragen:

dig @192.0.2.53 server.example.local

Reverse Lookup:

dig -x 192.0.2.20

Zu unterscheiden sind:

28. Firewall prüfen

Je nach System können unterschiedliche Werkzeuge verwendet werden.

firewalld:

firewall-cmd --get-active-zones

firewall-cmd --list-all

nftables:

nft list ruleset

iptables-Kompatibilitätsansicht:

iptables -S

Zu prüfen sind:

Ein geöffneter Port in der Hostfirewall beweist nicht, dass vorgelagerte Firewalls, Routing oder die Anwendung funktionieren.

29. Paketmitschnitt

Beispiel für TCP-Port 443:

tcpdump -ni any tcp port 443

Bestimmter Host und Port:

tcpdump -ni any \
    host 192.0.2.20 and tcp port 443

In Datei schreiben:

tcpdump -ni any \
    -s 0 \
    -w /tmp/example-443.pcap \
    tcp port 443

Zu untersuchen sind:

Paketmitschnitte können vertrauliche IP-Adressen, Hostnamen, Nutzdaten, Tokens und Anmeldeinformationen enthalten und müssen geschützt gespeichert sowie kontrolliert gelöscht werden.

30. CPU und Load prüfen

Überblick:

uptime

Dynamische Prozessansicht:

top

Logische Prozessoren:

nproc

CPU-Informationen:

lscpu

Falls sysstat installiert ist:

mpstat -P ALL 1 5

Prozessbezogene Statistik:

pidstat 1 5

Load Average beschreibt nicht ausschließlich CPU-Auslastung. Je nach Linux-Zustand können auch Tasks in nicht unterbrechbarem Zustand zur Last beitragen.

Zu unterscheiden sind:

31. Arbeitsspeicher prüfen

Speicherübersicht:

free -h

Detaillierte Kernelwerte:

cat /proc/meminfo

Prozesse nach Speicherverbrauch:

ps aux --sort=-%mem | head

Falls verfügbar:

vmstat 1 5

Wichtige Unterscheidungen:

32. OOM Killer untersuchen

Kernelmeldungen:

journalctl -k -b | grep -Ei 'out of memory|oom|killed process'

Systemweites Journal:

journalctl -b | grep -Ei 'out of memory|oom|killed process'

Mögliche Ursachen:

Zu dokumentieren sind:

Ein automatischer Dienstneustart kann den OOM-Kill verdecken. Der Dienst erscheint anschließend wieder aktiv, obwohl die Ursache weiter besteht.

33. Swap prüfen

Aktive Swap-Bereiche:

swapon --show

Speicherübersicht:

free -h

Aktivität:

vmstat 1 10

Bei vmstat sind insbesondere zu beachten:

Swap darf nicht ungeprüft mit swapoff deaktiviert werden. Der Inhalt muss in den Arbeitsspeicher übernommen werden können; andernfalls drohen starke Last oder Fehler.

34. Speicherplatz prüfen

Dateisysteme:

df -hT

Bestimmter Pfad:

df -hT /var/lib/example

Verzeichnisgrößen:

du -xhd1 /var

Größte Unterverzeichnisse:

du -xhd1 /var |
    sort -h

Zu unterscheiden sind:

df und du können unterschiedliche Werte zeigen, beispielsweise wegen gelöschter, aber geöffneter Dateien oder wegen Mounts innerhalb des untersuchten Verzeichnisbaums.

35. Inodes prüfen

Inode-Nutzung:

df -ih

Ein Dateisystem kann freien Speicherplatz besitzen und trotzdem keine neuen Dateien mehr aufnehmen, wenn keine freien Inodes vorhanden sind.

Typische Ursachen:

Anzahl der Einträge in einem kontrollierten Verzeichnisbaum:

find /var/tmp/example -xdev -type f |
    wc -l

Bei sehr großen Verzeichnisbäumen kann bereits das Zählen erhebliche I/O-Last verursachen.

36. Mounts prüfen

Aktuelle Mounts:

findmnt

Bestimmter Pfad:

findmnt -T /var/lib/example

Blockgeräte und Dateisysteme:

lsblk -f

Persistente Konfiguration:

cat /etc/fstab

fstab-Konfiguration ohne tatsächliches Mounten prüfen:

findmnt --verify

systemd-Mount-Units:

systemctl list-units --type=mount --all

Zu prüfen sind:

Eine Anwendung kann scheinbar korrekt in einen lokalen Ordner schreiben, obwohl das vorgesehene Netzwerk- oder Datenvolume nicht eingehängt ist.

37. Schreibgeschütztes Dateisystem

Mountoptionen:

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS

Kernelmeldungen:

journalctl -k -b |
    grep -Ei 'read-only|I/O error|filesystem|ext4|xfs'

Mögliche Ursachen:

Ein ungeprüftes Remount als rw kann eine bestehende Storage- oder Dateisystemstörung verschärfen. Zuerst müssen Kernelmeldungen und Datenträgerzustand bewertet werden.

38. Datenträger- und I/O-Fehler prüfen

Blockgeräte:

lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL

Kernelmeldungen:

journalctl -k -b |
    grep -Ei 'I/O error|blk_update|reset|timeout|nvme|ata|scsi|ext4|xfs'

Falls sysstat installiert ist:

iostat -xz 1 5

S.M.A.R.T.-Informationen, sofern unterstützt:

smartctl -a /dev/sda

NVMe-Informationen, sofern das Werkzeug installiert ist:

nvme smart-log /dev/nvme0

Zu prüfen sind:

S.M.A.R.T.-Tests und Reparaturwerkzeuge können Last oder Zustandsänderungen verursachen. Sie sind nicht ungeprüft auf produktivem Storage auszuführen.

39. Dateisystemprüfung sicher planen

Dateisystemtyp feststellen:

findmnt -no FSTYPE,SOURCE,TARGET /var/lib/example

Ein klassisches fsck darf normalerweise nicht auf einem schreibend eingehängten Dateisystem ausgeführt werden.

Vor einer Reparatur sind zu klären:

Bei XFS, ext4, Btrfs und anderen Dateisystemen unterscheiden sich Diagnose- und Reparaturwerkzeuge erheblich.

40. LVM prüfen

Übersicht:

pvs

vgs

lvs

Ausführlicher:

lvs -a -o +devices

Zu prüfen sind:

Ein vergrößertes Logical Volume bedeutet nicht automatisch, dass auch das darin enthaltene Dateisystem vergrößert wurde.

41. Software-RAID prüfen

Status:

cat /proc/mdstat

Detailinformationen:

mdadm --detail /dev/md0

Zu prüfen sind:

Ein Rebuild erhöht die I/O-Last und ersetzt kein Backup. Ein zweiter Fehler während der Wiederherstellung kann je nach RAID-Level zum Datenverlust führen.

42. Netzwerk-Mounts prüfen

NFS-Mounts:

findmnt -t nfs,nfs4

SMB-/CIFS-Mounts:

findmnt -t cifs

RPC-Dienste eines NFS-Servers:

rpcinfo -p <Server>

NFS-Exporte, sofern erreichbar:

showmount -e <Server>

Zu prüfen sind:

Ein hängender Netzwerk-Mount kann Befehle wie df, du, ls oder Anwendungen blockieren.

43. Paketverwaltung prüfen

Debian- und Ubuntu-Systeme:

apt update

Installierten Paketstatus prüfen:

dpkg -l

Unterbrochene Paketkonfiguration:

dpkg --audit

RPM-basierte Systeme:

dnf check

Installiertes Paket bestimmen:

rpm -q <Paketname>

Datei einem Paket zuordnen:

rpm -qf /usr/bin/example

Debian-Paket zuordnen:

dpkg -S /usr/bin/example

Mögliche Ursachen:

Paketdatenbanken und Lockdateien dürfen nicht ungeprüft gelöscht werden. Zuerst ist zu bestimmen, ob ein legitimer Paketprozess aktiv ist.

44. Paketdateien verifizieren

RPM-Paket:

rpm -V <Paketname>

Debian- und Ubuntu-Systeme, falls debsums installiert ist:

debsums <Paketname>

Abweichungen können entstehen durch:

Eine Abweichung beweist allein weder einen Defekt noch eine Manipulation. Dateityp und erwartete lokale Anpassung müssen berücksichtigt werden.

45. Cronjobs prüfen

Systemweite Crontab:

cat /etc/crontab

Systemverzeichnisse:

ls -la /etc/cron.d/

Benutzer-Crontab:

crontab -l

Crontab eines anderen Benutzers:

sudo crontab -u exampleuser -l

Cron-Dienst:

systemctl status cron

Je nach Distribution:

systemctl status crond

Cron-Protokoll:

journalctl -u cron

Oder:

journalctl -u crond

Typische Ursachen:

Ein erfolgreicher manueller Skriptstart beweist nicht, dass der Cronjob mit seiner reduzierten Umgebung funktioniert.

46. systemd-Timer prüfen

Timer anzeigen:

systemctl list-timers --all

Bestimmten Timer:

systemctl status example.timer

Zugehörigen Dienst:

systemctl status example.service

Protokolle:

journalctl -u example.timer -u example.service

Konfiguration:

systemctl cat example.timer

Zu prüfen sind:

Der Timer kann erfolgreich ausgelöst haben, obwohl die zugehörige Service-Unit fehlgeschlagen ist.

47. Zeit und Zeitsynchronisation prüfen

Systemzeit:

date --iso-8601=seconds

Status:

timedatectl

Bei chrony:

chronyc tracking

chronyc sources -v

Bei systemd-timesyncd:

timedatectl timesync-status

Mögliche Auswirkungen falscher Zeit:

Die Zeit darf auf produktiven Datenbank-, Cluster- oder Authentifizierungssystemen nicht ungeprüft sprunghaft verändert werden.

48. Zertifikate prüfen

Zertifikatsdatei:

openssl x509 \
    -in /etc/example/server.crt \
    -noout \
    -subject \
    -issuer \
    -dates \
    -fingerprint

Private-Key-Dateirechte:

stat /etc/example/server.key

Zertifikat und Schlüssel vergleichen, beispielhaft für RSA:

openssl x509 \
    -noout \
    -modulus \
    -in /etc/example/server.crt |
    openssl sha256

openssl rsa \
    -noout \
    -modulus \
    -in /etc/example/server.key |
    openssl sha256

Zu prüfen sind:

Private Schlüssel dürfen nicht in Diagnoseprotokolle oder Tickets kopiert werden.

49. Kernelmeldungen prüfen

Aktueller Systemstart:

journalctl -k -b

Warnungen und Fehler:

journalctl -k -b -p warning

Klassische Anzeige:

dmesg --level=emerg,alert,crit,err,warn

Mögliche relevante Meldungen:

Der dmesg-Puffer kann ältere Meldungen überschreiben. Das persistente Journal oder ein zentraler Logserver kann deshalb zusätzliche Informationen liefern.

50. Kernelmodule und Hardware prüfen

Geladene Module:

lsmod

Modulinformationen:

modinfo <Modulname>

PCI-Geräte und Treiber:

lspci -k

USB-Geräte:

lsusb

Hardwareübersicht:

lscpu

lsblk

Mögliche Ursachen:

Kernelmodule dürfen nicht ungeprüft entladen werden. Ein Modul kann von Netzwerk-, Storage- oder anderen produktiven Geräten verwendet werden.

51. Bootfehler untersuchen

Bootzeit analysieren:

systemd-analyze

Langsame Units:

systemd-analyze blame

Kritische Kette:

systemd-analyze critical-chain

Fehlgeschlagene Units:

systemctl --failed

Protokoll des aktuellen Starts:

journalctl -b

Protokoll des vorherigen Starts:

journalctl -b -1

Verfügbare Starts:

journalctl --list-boots

Zu prüfen sind:

52. Unerwarteten Neustart oder Absturz prüfen

Letzte Neustarts:

last reboot

Vorheriger Boot:

journalctl -b -1 -e

Kernelmeldungen des vorherigen Boots:

journalctl -k -b -1

Mögliche Ursachen:

Fehlende Abschlussmeldungen im Journal können auf einen abrupten Ausfall hinweisen, beweisen aber keine bestimmte Ursache.

53. Hängendes System und Hung Tasks

Nach Meldungen suchen:

journalctl -k |
    grep -Ei 'blocked for more than|hung task|soft lockup|hard lockup'

Mögliche Ursachen:

Magic SysRq kann in schweren Störungsfällen Diagnose- oder Notfallfunktionen auslösen. Die verfügbaren Funktionen hängen von Kernelkonfiguration und Systemwerten ab.

Status:

cat /proc/sys/kernel/sysrq

SysRq-Aktionen können erhebliche Auswirkungen bis hin zu Prozessbeendigung oder Neustart besitzen. Sie dürfen nur nach einem dafür vorgesehenen Notfallverfahren verwendet werden.

54. Strace als gezielte Tiefenanalyse

Systemaufrufe eines gestarteten Programms:

strace -f -o /tmp/example.strace <Befehl>

An laufenden Prozess anhängen:

strace -f -p <PID>

Nach Dateioperationen filtern:

strace -f -e trace=file <Befehl>

Nach Netzwerkoperationen filtern:

strace -f -e trace=network <Befehl>

Zu erkennen sind beispielsweise:

strace kann Leistung und Zeitverhalten beeinflussen sowie vertrauliche Dateinamen, Argumente und Daten sichtbar machen.

55. Typische Fehlerbilder

Symptom Mögliche Ursache Nächster Test
Dienst startet nicht Syntax, Rechte, Abhängigkeit oder fehlende Datei systemctl status, journalctl -u
Dienst beendet sich sofort Anwendung meldet Fehler oder Prozess forkt anders als erwartet Journal und ExecMainStatus
Dienst ist active, Anwendung funktioniert nicht interner Fehler, falscher Port oder Backend gestört ss, curl, Anwendungslog
Dienst ist failed, Prozess läuft Prozess wurde außerhalb von systemd gestartet ps, systemctl show
Dienst startet nach Reboot nicht nicht aktiviert oder Boot-Abhängigkeit fehlerhaft is-enabled, Bootjournal
Dienst läuft als falscher Benutzer Unit oder Drop-in geändert systemctl cat, systemctl show
Konfigurationsänderung wirkt nicht falsche Datei oder kein Reload/Restart Prozessargumente und Unit prüfen
Port ist nicht geöffnet Dienststart oder Bind-Konfiguration ss -ltnp
Port ist nur lokal erreichbar Bind-Adresse oder Firewall ss, Firewall, Remote-Test
Port bereits belegt zweite Instanz oder anderer Dienst ss, lsof
Zugriff verweigert Unix-Rechte, ACL, SELinux oder AppArmor namei, getfacl, Auditlog
Datei nicht gefunden, obwohl sie existiert falscher Namespace, Mount oder Pfadbestandteil namei, findmnt, Prozessumgebung
Schreiben schlägt fehl Rechte, ro, Speicher oder Inodes test -w, findmnt, df -h, df -i
df zeigt voll, du nicht gelöschte offene Datei oder reservierter Bereich lsof +L1
du hängt Netzwerk-Mount oder Storageproblem findmnt, Prozesszustand, Kerneljournal
hohe Load bei geringer CPU I/O-Wait oder Tasks im Zustand D vmstat, iostat, ps
Prozess wurde unerwartet beendet OOM, Signal oder Crash Kernel- und Dienstjournal
Server nutzt Swap stark früherer oder aktueller Speicherdruck vmstat, free, Prozessspeicher
keine neuen Dateien trotz freiem Speicher Inodes erschöpft df -ih
Mount fehlt nach Neustart fstab, Abhängigkeit oder Gerät fehlt findmnt --verify, Bootjournal
Dateisystem plötzlich read-only I/O- oder Dateisystemfehler Kerneljournal
Cronjob läuft manuell, aber nicht automatisch Umgebung, Benutzer, Pfad oder Shell Cronlog und kontrollierter Umgebungstest
systemd-Timer löst aus, Aufgabe scheitert zugehörige Service-Unit fehlerhaft Journal beider Units
TLS-Zertifikat angeblich abgelaufen falsche Zeit oder altes geladenes Zertifikat timedatectl, openssl s_client
Paketupdate schlägt fehl Repository, DNS, Signatur oder Lock Paketmanager- und Prozessstatus
Server startet langsam Mount-, Netzwerk- oder Unit-Timeout systemd-analyze critical-chain
Netzwerk funktioniert nach IP, nicht nach Name DNS oder NSS getent hosts, dig

56. Vorgehensweise bei „Dienst startet nicht“

  1. Host, Dienstname und Zeitpunkt dokumentieren.
  2. systemctl status auswerten.
  3. systemctl show auf Ergebnis und Exit-Status prüfen.
  4. Dienstjournal seit dem letzten Startversuch lesen.
  5. erste relevante Fehlermeldung bestimmen.
  6. tatsächlich verwendete Unit und Drop-ins anzeigen.
  7. Startbenutzer und Gruppen prüfen.
  8. Anwendungskonfiguration mit dem vorgesehenen Syntaxprüfer testen.
  9. benötigte Dateien und Pfade prüfen.
  10. Unix-Rechte, ACL und alle Pfadbestandteile prüfen.
  11. SELinux- oder AppArmor-Ablehnungen prüfen.
  12. Portkonflikte prüfen.
  13. Mounts und externe Abhängigkeiten prüfen.
  14. Speicherplatz, Inodes, RAM und Limits kontrollieren.
  15. genau eine nachgewiesene Ursache korrigieren.
  16. Dienst kontrolliert starten.
  17. Journal, Prozess, Port und Anwendungsfunktion nachkontrollieren.
  18. Ursache, Maßnahme und Rückweg dokumentieren.

57. Vorgehensweise bei „Server ist langsam“

  1. Zeitraum und konkrete langsame Funktion erfassen.
  2. Vergleichswert oder normalen Zustand bestimmen.
  3. Load, CPU, RAM und Swap prüfen.
  4. Prozesse nach CPU- und Speicherverbrauch sortieren.
  5. Prozesszustände und blockierte Tasks prüfen.
  6. vmstat auswerten.
  7. I/O-Latenz und Datenträgerauslastung prüfen.
  8. Kernelmeldungen auf Storage- oder Treiberfehler untersuchen.
  9. Netzwerkfehler, Drops und Retransmissions berücksichtigen.
  10. DNS-Antwortzeiten prüfen.
  11. Anwendung und Backend getrennt testen.
  12. cgroup-, Container- oder Unit-Limits prüfen.
  13. geplante Jobs, Backups und Updates berücksichtigen.
  14. Engpass anhand von Messwerten nachweisen.
  15. eine kontrollierte Maßnahme durchführen.
  16. dieselbe Funktion mit denselben Messwerten erneut testen.

58. Vorgehensweise bei „Kein Speicherplatz“

  1. betroffenen Pfad dokumentieren.
  2. zugehöriges Dateisystem mit findmnt -T bestimmen.
  3. Speicherplatz mit df -hT prüfen.
  4. Inodes mit df -ih prüfen.
  5. Quotas und Storage-Limits berücksichtigen.
  6. Verzeichnisgrößen innerhalb desselben Dateisystems untersuchen.
  7. gelöschte offene Dateien mit lsof +L1 prüfen.
  8. Logs, Caches, temporäre Dateien und Containerdaten unterscheiden.
  9. LVM-Thin-Pool oder Snapshotbereich prüfen.
  10. Ursache des Wachstums bestimmen.
  11. Aufbewahrungs- und Löschregeln prüfen.
  12. keine unbekannten Dateien pauschal löschen.
  13. eine kontrollierte Bereinigung oder Erweiterung durchführen.
  14. Anwendung und Speicherzustand erneut prüfen.
  15. Präventionsmaßnahme wie Rotation, Monitoring oder Quota dokumentieren.

59. Vorgehensweise bei „Dateisystem oder Mount nicht verfügbar“

  1. betroffenen Mountpoint dokumentieren.
  2. findmnt und lsblk -f auswerten.
  3. Blockgerät, UUID und Dateisystemtyp bestimmen.
  4. /etc/fstab prüfen.
  5. findmnt --verify ausführen.
  6. systemd-Mount-Unit und Journal prüfen.
  7. Kernelmeldungen auf I/O-Fehler untersuchen.
  8. bei Netzwerk-Mounts DNS, Route, Port und Server prüfen.
  9. offene Prozesse und Abhängigkeiten berücksichtigen.
  10. Storage-, RAID-, LVM- oder Multipath-Zustand prüfen.
  11. Backup und Wartungsfenster klären.
  12. nur die nachgewiesene Ursache korrigieren.
  13. Mount kontrolliert herstellen.
  14. Lese- und Schreibfunktion entsprechend dem Sollzustand testen.
  15. Neustartverhalten gesondert verifizieren.

60. Maßnahmen und Rückwege

Ursache: Syntaxfehler in der Dienstkonfiguration

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: falsche Dateiberechtigung

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: falscher SELinux-Kontext

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: Portkonflikt

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: gelöschte offene Logdatei belegt Speicher

Nachweis:

Maßnahme:

Rollback:

Verifikation:

61. Nachkontrolle

Nach einer Maßnahme sind mindestens folgende Punkte zu prüfen:

62. Dokumentationsbeispiel

Symptom:
Der Dienst example-api ließ sich nach einem Konfigurationsupdate nicht mehr
starten. Clients erhielten „Connection refused“ auf TCP-Port 8443.

Zeitpunkt:
02.08.2026, 11:42 Uhr MESZ

Server:
linux-app-01.example.local

Dienst:
example-api.service

Nachweis:
systemctl status zeigte den Zustand „failed“.
Im Journal war unmittelbar nach dem Startversuch ein Berechtigungsfehler für
/etc/example-api/server.key dokumentiert.
Der Dienst lief als Benutzer example-api.
Ein kontrollierter Lesetest als example-api schlug fehl.
Die übergeordneten Verzeichnisse waren zugänglich.
Es gab keine passende SELinux- oder AppArmor-Ablehnung.
Die Schlüsseldatei war nach dem Austausch irrtümlich root:root mit Modus 0600
zugeordnet worden.

Ursache:
Die neue private Schlüsseldatei besaß nicht den vorgesehenen Gruppeneigentümer.
Der Dienstbenutzer konnte sie deshalb nicht lesen.

Maßnahme:
Nach Dokumentation des Ausgangszustands wurde die Datei der vorgesehenen
Dienstgruppe zugeordnet. Der Modus blieb auf das erforderliche Minimum
beschränkt.

Rollback:
Der ursprüngliche Eigentümer und die ursprüngliche Gruppe wurden dokumentiert
und können wiederhergestellt werden.

Verifikation:
Der Konfigurationstest war erfolgreich.
Der Dienst startete ohne neue Fehlermeldung.
TCP-Port 8443 wurde durch den vorgesehenen Prozess geöffnet.
Die lokale und externe HTTPS-Prüfung waren erfolgreich.
Der private Schlüssel ist weiterhin nicht für andere Benutzer lesbar.

Prävention:
Der Zertifikatsaustausch wird künftig durch einen dokumentierten Ablauf mit
Kontrolle von Eigentümer, Gruppe, Modus, Sicherheitskontext und anschließendem
Konfigurationstest durchgeführt.

63. Entscheidungsbaum

Linux-Dienst oder Anwendung gestört
        ↓
Ist das System erreichbar und die Zeit plausibel?
        ├── Nein
        │   ↓
        │   Boot, Netzwerk, Routing, DNS und Zeit prüfen
        │
        └── Ja
            ↓
Ist die Unit aktiv?
        ├── Nein
        │   ↓
        │   Status, Exit-Code und Dienstjournal prüfen
        │
        └── Ja
            ↓
Läuft der erwartete Prozess unter der richtigen Identität?
        ├── Nein
        │   ↓
        │   Unit, Drop-ins, Benutzer und Startmethode prüfen
        │
        └── Ja
            ↓
Lauscht die Anwendung auf der vorgesehenen Adresse und dem Port?
        ├── Nein
        │   ↓
        │   Konfiguration, Portkonflikt und Socket-Aktivierung prüfen
        │
        └── Ja
            ↓
Funktioniert die Anwendung lokal?
        ├── Nein
        │   ↓
        │   Anwendung, Backend, Rechte, Mounts und Ressourcen prüfen
        │
        └── Ja
            ↓
Funktioniert der Zugriff über das Netzwerk?
        ├── Nein
        │   ↓
        │   Bind-Adresse, Firewall, Route, DNS und Paketfluss prüfen
        │
        └── Ja
            ↓
Benutzerfunktion, Lastverhalten und abhängige Systeme prüfen

64. Typische Prüfungsfragen

Warum reicht der Zustand active eines systemd-Dienstes nicht als vollständiger Funktionsnachweis?

Antwort anzeigen

Der Zustand zeigt, dass systemd die Unit als aktiv betrachtet. Er beweist nicht, dass die Anwendung auf dem richtigen Port lauscht, ihre Backends erreicht oder korrekte Antworten auf Benutzeranfragen liefert.

Worin unterscheiden sich enabled und active?

Antwort anzeigen

enabled beschreibt die Einbindung für einen automatischen Start. active beschreibt den aktuellen Laufzeitzustand. Ein Dienst kann aktiv und gleichzeitig nicht aktiviert sein oder aktiviert, aber aktuell fehlgeschlagen sein.

Warum sollte zuerst SIGTERM und nicht sofort SIGKILL verwendet werden?

Antwort anzeigen

SIGTERM ermöglicht dem Prozess eine kontrollierte Beendigung, beispielsweise das Schreiben von Daten und Schließen von Dateien. SIGKILL kann nicht behandelt werden und verhindert eine geordnete Bereinigung.

Warum können df und du unterschiedliche Speicherbelegungen anzeigen?

Antwort anzeigen

Eine häufige Ursache sind gelöschte Dateien, die von einem laufenden Prozess weiterhin geöffnet gehalten werden. du findet sie nicht mehr im Verzeichnisbaum, während das Dateisystem den belegten Speicher weiterhin berücksichtigt.

Warum kann ein Dateisystem trotz freiem Speicherplatz keine neue Datei aufnehmen?

Antwort anzeigen

Die verfügbaren Inodes können erschöpft sein. In diesem Fall ist noch Datenkapazität frei, aber es können keine weiteren Dateisystemobjekte angelegt werden.

Warum beweist ein erfolgreicher manueller Skriptstart nicht, dass ein Cronjob funktioniert?

Antwort anzeigen

Cron verwendet häufig eine reduzierte Umgebung, einen anderen Benutzer, ein anderes Arbeitsverzeichnis und eine eingeschränkte PATH-Variable. Das Skript kann deshalb manuell funktionieren und automatisch scheitern.

Warum sollte SELinux nicht pauschal deaktiviert werden?

Antwort anzeigen

Dadurch wird eine wichtige Sicherheitsschicht für das gesamte System entfernt, ohne die eigentliche Ursache zu beheben. Stattdessen müssen Ablehnung, Pfad, Dateikontext und notwendige Mindestberechtigung untersucht werden.

Was bedeutet ein Prozess im Zustand D?

Antwort anzeigen

Der Prozess befindet sich in einem nicht unterbrechbaren Schlafzustand und wartet häufig auf eine I/O- oder Kerneloperation. Die zugrunde liegende Storage-, Mount- oder Treiberstörung muss untersucht werden.

Warum kann ein fehlender Mount zu Daten am falschen Ort führen?

Antwort anzeigen

Wenn der vorgesehene Mount fehlt, bleibt das lokale Mountpoint-Verzeichnis sichtbar. Eine Anwendung kann dann unbemerkt in das lokale Root-Dateisystem statt auf das vorgesehene Volume schreiben.

65. Prüfungsfallen

66. Checkliste

67. Schnellreferenz

Beobachtung Nächstes Werkzeug
Betriebssystemversion unklar cat /etc/os-release
Kernelversion unklar uname -r
Systemzustand unklar systemctl is-system-running
fehlgeschlagene Units gesucht systemctl --failed
Dienststatus unklar systemctl status
Exit-Code unklar systemctl show
Dienstprotokoll gesucht journalctl -u
vorheriger Boot relevant journalctl -b -1
tatsächliche Unit unklar systemctl cat
Drop-ins vermutet systemctl show -p DropInPaths
Unit-Syntax unklar systemd-analyze verify
Prozess gesucht pgrep -a, ps
Prozessbaum benötigt pstree -ap
offene Datei unklar lsof, fuser
gelöschte Datei belegt Speicher lsof +L1
Dienstbenutzer unklar systemctl show -p User -p Group
Benutzergruppen unklar id, getent
Pfadberechtigung unklar namei -l, stat
ACL unklar getfacl
SELinux-Status unklar getenforce, sestatus
SELinux-Ablehnung vermutet ausearch
AppArmor-Ablehnung vermutet aa-status, Kerneljournal
Listener unklar ss -ltnp
Portkonflikt vermutet ss, lsof
lokale HTTP-Funktion unklar curl -v
TLS-Fehler openssl s_client
IP-Konfiguration unklar ip -br address
Route unklar ip route get
DNS-Auflösung unklar getent hosts, dig
Firewallzustand unklar firewall-cmd, nft
Paketfluss unklar tcpdump
CPU-Last unklar top, mpstat, pidstat
RAM unklar free -h, vmstat
OOM vermutet journalctl -k
Swap unklar swapon --show, vmstat
Speicherplatz unklar df -hT
Verzeichnisgröße unklar du -xhd1
Inodes unklar df -ih
Mount unklar findmnt
Blockgerät unklar lsblk -f
fstab fehlerhaft vermutet findmnt --verify
I/O-Fehler vermutet Kerneljournal, iostat
LVM-Zustand unklar pvs, vgs, lvs
Software-RAID unklar /proc/mdstat, mdadm --detail
Paketdatei verändert rpm -V, debsums
Cronjob unklar Crontab und Cronjournal
systemd-Timer unklar systemctl list-timers --all
Zeitsynchronisation unklar timedatectl, chronyc
Boot langsam systemd-analyze critical-chain
Systemaufruf scheitert strace

Merksatz

Auf einem Linux-Server wird vom objektiven Symptom über Unit, Prozess, Protokoll, Identität, Port und Abhängigkeiten bis zu Berechtigungen, Sicherheitsrichtlinien, Ressourcen, Mounts und Kernel geprüft. Ein Dienst wird erst verändert oder neu gestartet, wenn der Fehlerzustand gesichert, die Auswirkung bewertet und ein Rückweg festgelegt wurde. active, ein offener Port und ein erfolgreicher lokaler Test sind jeweils nur Teilnachweise – entscheidend ist die ursprüngliche Benutzerfunktion.

Quellen und weiterführende Dokumentation

Offizielle systemd-Dokumentation

Offizielle Linux-Kernel-Dokumentation

Offizielle Red-Hat-Dokumentation

Offizielle Ubuntu-Dokumentation

Linux-Handbuchseiten

8. Betriebssystem- und Serveranalyse

8.5 macOS – Prozesse, Dienste, Protokolle, Ressourcen und Speicher analysieren

Diese Seite beschreibt die systematische Fehleranalyse auf macOS. Im Mittelpunkt stehen Prozesse, launchd-Dienste, Protokolle, CPU, Arbeitsspeicher, APFS-Datenträger, Dateiberechtigungen, Datenschutzfreigaben und Startprobleme.

8.5.1 Ziel und Abgrenzung

Nach dieser Seite soll beurteilt werden können:

Eine laufende App, ein vorhandener Prozess oder ein registrierter Dienst beweist noch nicht, dass die ursprüngliche Benutzerfunktion funktioniert.

8.5.2 Besonderheiten der macOS-Systemarchitektur

Für die Fehleranalyse sind insbesondere folgende Komponenten wichtig:

Komponente Aufgabe Bedeutung für die Diagnose
Kernel Verwaltet Hardware, Speicher, Prozesse und Systemressourcen Kernel-Panics, Treiber- oder Hardwareprobleme können das gesamte System betreffen
launchd Startet und verwaltet Dienste, Agents und XPC-Dienste Ein Dienst kann dauerhaft oder nur bei Bedarf gestartet werden
LaunchDaemon Systemweiter Hintergrunddienst Wird gewöhnlich im system-Bereich verwaltet
LaunchAgent Benutzerbezogener Hintergrunddienst Wird gewöhnlich im gui/<UID>-Bereich verwaltet
Unified Logging Zentrales Protokollsystem von macOS Wird über „Konsole“ oder den Befehl log ausgewertet
APFS Standarddateisystem moderner macOS-Systeme Container, Volumes, Snapshots und gemeinsam genutzter Speicher müssen unterschieden werden
TCC Datenschutz- und Zugriffssteuerung Kann Zugriffe trotz korrekter Unix-Berechtigungen verhindern
Systemerweiterungen Erweiterungen für Netzwerk, Sicherheit, Treiber und andere Funktionen Fehlerhafte Erweiterungen können systemweite Auswirkungen verursachen
Aktivitätsanzeige Grafische Prozess- und Ressourcenanalyse Zeigt CPU, Speicher, Energie, Datenträger und Netzwerkaktivität

launchd-Dienste können bedarfsgesteuert arbeiten. Ein registrierter Dienst ohne aktuelle PID ist deshalb nicht automatisch fehlerhaft.

8.5.3 Typische Symptome

8.5.4 Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[LESEND] Liest Informationen aus und verändert normalerweise keine Konfiguration
[LIVE] Beobachtet laufende Ereignisse bis zum Abbruch
[PRIVILEGIERT] Benötigt möglicherweise sudo oder Administratorrechte
[BELASTEND] Kann CPU, Datenträger oder Protokollsystem zusätzlich belasten
[VERÄNDERND] Verändert einen Prozess, Dienst oder eine Systemeinstellung
[NEUSTART] Unterbricht laufende Sitzungen oder Funktionen

Vor verändernden Maßnahmen müssen Befund, Konfiguration und Rückweg dokumentiert werden.

8.5.5 Sicherheits- und Betriebswarnungen

Beispiel:

man launchctl
man log
man diskutil

8.5.6 Benötigte Informationen

Vor der Diagnose sollten mindestens folgende Angaben erfasst werden:

8.5.7 Systemzustand und Basisdaten sichern

Die folgenden Befehle sind lesend. Systeminformationen können Seriennummern und andere vertrauliche Daten enthalten und müssen vor einer Weitergabe geprüft werden.

date
sw_vers
uname -a
uname -m
uptime
who
last reboot | head -n 10
system_profiler SPHardwareDataType SPSoftwareDataType

Wichtige Fragen:

Die Installationshistorie kann ergänzend geprüft werden:

system_profiler SPInstallHistoryDataType

Die zeitliche Übereinstimmung zwischen einer Installation und dem Beginn der Störung ist ein Hinweis, aber noch kein Ursachenbeweis.

8.5.8 Ungefährliche Schnellprüfung

df -h
df -ih
diskutil list
vm_stat
sysctl vm.swapusage
ps -axo pid,ppid,user,state,%cpu,%mem,etime,command | head -n 30
log show --last 15m --style compact \
  --predicate 'messageType == error OR messageType == fault'

Zusätzlich in der grafischen Oberfläche prüfen:

  1. „Aktivitätsanzeige“ öffnen.
  2. CPU, Speicher, Energie, Festplatte und Netzwerk kontrollieren.
  3. Nach ungewöhnlich belastenden oder nicht reagierenden Prozessen suchen.
  4. „Konsole“ öffnen und den Fehlerzeitraum untersuchen.
  5. Unter „Systemeinstellungen → Allgemein → Speicher“ den verfügbaren Speicher prüfen.
  6. Unter „Systemeinstellungen → Allgemein → Anmeldeobjekte & Erweiterungen“ auffällige Hintergrundobjekte erfassen.
  7. Unter „Datenschutz & Sicherheit“ prüfen, ob die betroffene App die tatsächlich benötigten Freigaben besitzt.

Noch keine Prozesse beenden, Dienste neu starten oder Dateien löschen.

8.5.9 Prozesse systematisch untersuchen

Prozesse können über die Aktivitätsanzeige oder das Terminal untersucht werden.

Alle Prozesse anzeigen:

ps -axo pid,ppid,user,state,%cpu,%mem,etime,command

Mehrere Messungen der aktiven Prozesse durchführen:

top -l 3 -s 2 -o cpu \
  -stats pid,command,cpu,mem,threads,state,time

Nach einem Prozess suchen:

pgrep -fl "BeispielApp"

Einen bestimmten Prozess untersuchen, wobei 1234 durch die tatsächliche PID ersetzt wird:

ps -p 1234 \
  -o pid,ppid,user,state,%cpu,%mem,etime,command

Geöffnete Dateien und Verbindungen des Prozesses anzeigen:

lsof -nP -p 1234 | head -n 100

Einen Prozess für zehn Sekunden analysieren:

sample 1234 10 -file "$HOME/Desktop/BeispielApp-sample.txt"

Alternativ kann in der Aktivitätsanzeige ein Prozess ausgewählt und über „Mehr → Prozess analysieren“ untersucht werden.

Zu prüfen sind:

Ein hoher Messwert während eines kurzen Startvorgangs kann normal sein. Aussagekräftiger ist eine wiederholte oder dauerhaft hohe Auslastung im Fehlerzeitraum.

8.5.10 Prozesse kontrolliert beenden

Zuerst sollte die App regulär beendet werden. Reagiert sie nicht, kann die Aktivitätsanzeige verwendet werden.

Ein Prozess kann im Terminal zunächst mit SIGTERM zum geordneten Beenden aufgefordert werden:

kill -TERM 1234

Kennzeichnung: [VERÄNDERND]

Risiken:

SIGKILL beziehungsweise kill -9 beendet einen Prozess ohne geordnetes Aufräumen und ist nur die letzte Eskalationsstufe:

kill -KILL 1234

Kennzeichnung: [VERÄNDERND] [HOHES RISIKO]

Vorher müssen PID, Prozessname, Benutzer und Auswirkungen eindeutig geprüft werden.

8.5.11 Dienste und Agents mit launchd analysieren

Systemweite Dienste und benutzerbezogene Agents liegen in unterschiedlichen launchd-Bereichen.

Bereich Typische Verwendung
system Systemweite Daemons
user/<UID> Benutzerbereich ohne zwingenden Bezug zur grafischen Anmeldung
gui/<UID> Grafische Anmeldesitzung eines Benutzers

Systembereich anzeigen:

launchctl print system

Bereich des aktuell angemeldeten Benutzers anzeigen:

launchctl print gui/$(id -u)

Einen konkreten systemweiten Dienst prüfen:

launchctl print system/com.example.service

Einen konkreten Benutzer-Agent prüfen:

launchctl print gui/$(id -u)/com.example.agent

Deaktivierungszustände anzeigen:

launchctl print-disabled system
launchctl print-disabled gui/$(id -u)

Typische Speicherorte:

~/Library/LaunchAgents
/Library/LaunchAgents
/Library/LaunchDaemons
/System/Library/LaunchAgents
/System/Library/LaunchDaemons

Eine Drittanbieter-Property-List syntaktisch prüfen:

plutil -lint "/Library/LaunchDaemons/com.example.service.plist"

Zu untersuchen sind:

Ein nicht laufender On-Demand-Dienst kann sich im Normalzustand befinden. Entscheidend ist, ob der vorgesehene Auslöser den Dienst startet und die Benutzerfunktion anschließend funktioniert.

8.5.12 Dienst kontrolliert neu starten

Ein eindeutig identifizierter Drittanbieterdienst kann zu Diagnosezwecken neu gestartet werden.

Systemweiter Dienst:

sudo launchctl kickstart -k system/com.example.service

Benutzer-Agent:

launchctl kickstart -k gui/$(id -u)/com.example.agent

Kennzeichnung: [VERÄNDERND]

Vorher dokumentieren:

Ein erfolgreicher Neustart beweist nur, dass der Dienst erneut gestartet werden konnte. Danach muss die ursprüngliche Funktion getestet werden.

8.5.13 Unified Logging und Konsole

Die App „Konsole“ und der Befehl log greifen auf das zentrale macOS-Protokollsystem zu.

Fehler und Fault-Meldungen der letzten 30 Minuten:

log show --last 30m --style compact \
  --predicate 'messageType == error OR messageType == fault'

Meldungen eines bestimmten Prozesses:

log show --last 30m --style compact \
  --predicate 'process == "BeispielApp"'

Bestimmten Zeitraum untersuchen:

log show \
  --start "2026-08-02 13:00:00" \
  --end "2026-08-02 13:30:00" \
  --style compact

Protokollmeldungen live verfolgen:

log stream --style compact --level info \
  --predicate 'process == "BeispielApp"'

Kennzeichnung: [LIVE]

Die Live-Ausgabe wird mit Ctrl-C beendet.

Ein Protokollarchiv der letzten 30 Minuten erstellen:

sudo log collect --last 30m \
  --output "$HOME/Desktop/macOS-30m.logarchive"

Kennzeichnung: [PRIVILEGIERT] [DATENSCHUTZRELEVANT]

Bei der Auswertung beachten:

8.5.14 Absturz-, Spin- und Diagnoseberichte

Die App „Konsole“ zeigt unter anderem:

Benutzerbezogene Diagnoseberichte können zusätzlich in folgendem Verzeichnis liegen:

ls -lt "$HOME/Library/Logs/DiagnosticReports" | head -n 20

Systemweite Diagnoseberichte:

sudo ls -lt "/Library/Logs/DiagnosticReports" | head -n 20

Wichtige Inhalte eines Absturzberichts:

Ein einzelner Absturzbericht beweist nicht automatisch einen dauerhaften Defekt. Entscheidend sind Reproduzierbarkeit, Häufigkeit und Übereinstimmung mit der beobachteten Störung.

8.5.15 CPU-Auslastung analysieren

Grafisch:

  1. Aktivitätsanzeige öffnen.
  2. Bereich „CPU“ auswählen.
  3. Nach % CPU sortieren.
  4. Messung während der Störung beobachten.
  5. Prozess analysieren oder Spindump erstellen.

Im Terminal:

top -l 5 -s 2 -o cpu \
  -stats pid,command,cpu,mem,threads,state,time

Mögliche Befunde:

Befund Mögliche Bedeutung
Ein Prozess dauerhaft stark ausgelastet Endlosschleife, fehlerhafte Verarbeitung oder außergewöhnliche Arbeitslast
Viele Prozesse gleichzeitig ausgelastet Systemweite Last, Indizierung, Update oder konkurrierende Aufgaben
Hohe CPU mit normaler Benutzerfunktion Möglicherweise erwartete Verarbeitung
Niedrige CPU bei langsamer App Warten auf Datenträger, Netzwerk, Sperre oder externen Dienst
App reagiert nicht und CPU ist nahezu null Blockierter Thread oder Warten auf eine Ressource
Wiederkehrende kurze Lastspitzen Regelmäßiger Agent, Synchronisation oder geplanter Hintergrundprozess

Die CPU-Auslastung muss immer zusammen mit Prozesszustand, Benutzerfunktion, Protokollen und I/O-Aktivität bewertet werden.

8.5.16 Arbeitsspeicher analysieren

Apple empfiehlt, den Speicherdruck und nicht nur den freien Arbeitsspeicher zu bewerten.

Grafisch:

  1. Aktivitätsanzeige öffnen.
  2. Bereich „Speicher“ auswählen.
  3. Speicherdruck beobachten.
  4. Speicher, komprimierten Speicher und Swap-Nutzung prüfen.
  5. Nach Speicherverbrauch sortieren.

Terminalprüfung:

vm_stat
sysctl vm.swapusage

Mehrere Messungen im Abstand von zwei Sekunden:

vm_stat -c 5 2

Wichtige Werte:

Interpretation:

Befund Bewertung
Speicherdruck Grün Speicherverwaltung arbeitet derzeit ausreichend
Speicherdruck Gelb Ressourcen werden knapp; Verlauf und verursachende Prozesse prüfen
Speicherdruck Rot Akuter Speicherengpass wahrscheinlich
Hohe Komprimierung ohne Störung Kann normal sein
Wachsende Swap-Nutzung und Leistungseinbruch Speicherengpass oder übermäßiger Prozessverbrauch möglich
Einzelner Prozess wächst kontinuierlich Mögliches Speicherleck
Hohe historische Swap-Zahl ohne aktuelle Änderung Kein ausreichender Ursachenbeweis

Ein einmaliger Gesamtwert ist weniger aussagekräftig als die Veränderung während des reproduzierten Fehlers.

8.5.17 Datenträger, APFS und Speicherplatz analysieren

Dateisystembelegung:

df -h
df -h /System/Volumes/Data
df -ih

Datenträgerstruktur:

diskutil list
diskutil info /
diskutil apfs list

Lokale Time-Machine-Snapshots anzeigen:

tmutil listlocalsnapshots /

Speicherbelegung im Benutzerordner untersuchen:

du -x -h -d 1 "$HOME" 2>/dev/null | sort -h

Datenträgeraktivität beobachten:

iostat -w 2 -c 5

Dateisystem oder Datenträger-I/O für 15 Sekunden verfolgen:

sudo fs_usage -w -f diskio -t 15

Kennzeichnung: [PRIVILEGIERT] [LIVE] [BELASTEND] [DATENSCHUTZRELEVANT]

Ein Volume prüfen:

diskutil verifyVolume /

Kennzeichnung: [PRÜFEND] [POTENZIELL BELASTEND]

Bei APFS beachten:

Für Reparaturen sollte das Festplattendienstprogramm verwendet werden. Apple empfiehlt, „Erste Hilfe“ zuerst für die Volumes, anschließend für die Container und zuletzt für das physische Speichergerät auszuführen. Bei Problemen mit dem Startvolume kann die macOS-Wiederherstellung erforderlich sein.

8.5.18 Dateiberechtigungen, ACLs und erweiterte Attribute

Identität des aktuellen Benutzers prüfen:

id
groups

Datei oder Ordner untersuchen:

ls -ldeO@ "/Pfad/zum/Ordner"
stat -x "/Pfad/zum/Ordner"

Dabei werden unter anderem sichtbar:

Zu prüfen ist der gesamte benötigte Pfad. Schreibrechte auf eine Datei reichen beispielsweise nicht aus, wenn ein übergeordneter Ordner nicht betreten oder verändert werden darf.

Berechtigungen dürfen nicht pauschal mit chmod -R 777 geöffnet werden. Dadurch entstehen Sicherheitsprobleme, und bestehende ACLs oder Eigentümerfehler werden nicht zuverlässig behoben.

8.5.19 Datenschutzfreigaben und TCC

macOS schützt bestimmte Daten und Geräte zusätzlich zu den Unix-Berechtigungen.

Mögliche Freigaben sind unter anderem:

Ein Zugriff kann deshalb fehlschlagen, obwohl ls -l korrekte Unix-Berechtigungen anzeigt.

Prüfung:

  1. „Systemeinstellungen → Datenschutz & Sicherheit“ öffnen.
  2. Nur die für die App tatsächlich benötigte Kategorie auswählen.
  3. Prüfen, ob die richtige App oder das richtige Terminalprogramm eingetragen ist.
  4. Nach einer Änderung die betroffene App gegebenenfalls vollständig beenden und neu starten.
  5. Funktion erneut testen.

Festplattenvollzugriff sollte nicht pauschal vergeben werden. Die kleinste benötigte Freigabe ist vorzuziehen.

8.5.20 App-Signatur, Gatekeeper und Quarantäne prüfen

Eine App kann wegen einer beschädigten Signatur, einer nicht vertrauenswürdigen Herkunft oder einer unvollständigen Installation nicht starten.

Signatur einer Beispiel-App prüfen:

codesign --verify --deep --strict --verbose=2 \
  "/Applications/Beispiel.app"

Gatekeeper-Bewertung prüfen:

spctl --assess --type execute --verbose=4 \
  "/Applications/Beispiel.app"

Erweiterte Attribute anzeigen:

xattr -l "/Applications/Beispiel.app"

Diese Befehle sind lesend.

Ein negatives Ergebnis sollte durch eine unveränderte, signierte Installationsdatei des Herstellers behoben werden. Das Entfernen von Quarantäneattributen, das Ad-hoc-Signieren oder das Deaktivieren von Gatekeeper ist keine allgemeine Fehlerlösung.

8.5.21 Anmeldeobjekte, Hintergrunddienste und Erweiterungen

Grafische Prüfung:

  1. „Systemeinstellungen → Allgemein → Anmeldeobjekte & Erweiterungen“ öffnen.
  2. „Bei der Anmeldung öffnen“ erfassen.
  3. „Im Hintergrund erlauben“ erfassen.
  4. installierte Erweiterungen prüfen.
  5. unbekannte oder zeitlich zur Störung passende Drittanbieterkomponenten dokumentieren.

Systemerweiterungen anzeigen:

systemextensionsctl list

MDM-Registrierungsstatus prüfen:

profiles status -type enrollment

Sicherheitszustände können ergänzend gelesen werden:

fdesetup status
csrutil status
spctl --status

Diese Zustände dürfen nicht ohne begründete Anforderung verändert werden.

Wenn Anmeldeobjekte als Ursache vermutet werden:

  1. vollständige Liste sichern;
  2. verdächtige Drittanbieterobjekte kontrolliert deaktivieren;
  3. ab- und wieder anmelden oder neu starten;
  4. ursprüngliche Funktion testen;
  5. Objekte einzeln wieder aktivieren;
  6. den tatsächlich verursachenden Eintrag bestätigen.

8.5.22 Netzwerkabhängigkeiten kurz prüfen

Wenn eine App langsam ist oder einen Dienst nicht erreicht, muss zwischen lokalem Prozessproblem und externer Abhängigkeit unterschieden werden.

scutil --dns
route -n get default
netstat -rn
lsof -nP -iTCP -sTCP:LISTEN

Fragen:

Die ausführliche Netzwerkdiagnose erfolgt nach den Abläufen aus Kapitel 3.

8.5.23 Fehler auf Benutzer, System oder Hardware eingrenzen

Test Erkenntnis
Nur eine App betroffen App-Konfiguration, App-Daten oder Abhängigkeit wahrscheinlich
Mehrere Apps eines Benutzers betroffen Benutzerprofil, TCC, LaunchAgent oder Anmeldeobjekt möglich
Alle Benutzer betroffen Systemdienst, systemweite Konfiguration, Datenträger oder Hardware möglich
Fehler nur mit einem externen Gerät Gerät, Kabel, Adapter, Stromversorgung oder Treiber untersuchen
Fehler verschwindet nach App-Neustart Prozesszustand wahrscheinlich, Ursache aber noch nicht bewiesen
Fehler verschwindet nach Abmeldung Benutzerbezogener Agent oder Sitzungszustand möglich
Fehler verschwindet im sicheren Modus Drittanbietererweiterung, Anmeldeobjekt oder zusätzlich geladene Komponente möglich
Fehler bleibt im sicheren Modus bestehen Grundsystem, Benutzerdateien, Hardware oder weiterhin aktive Abhängigkeit untersuchen
Fehler tritt auch in der Wiederherstellung auf Hardware oder Datenträger wird wahrscheinlicher
Apple Diagnose meldet Referenzcode Hardwarebefund dokumentieren und nach Apple-Vorgabe weiterbearbeiten

8.5.24 Sicherer Modus

Der sichere Modus hilft zu prüfen, ob beim normalen Start zusätzlich geladene Software beteiligt ist.

Mac mit Apple-Chip:

  1. Mac vollständig ausschalten.
  2. Ein-/Ausschalter gedrückt halten, bis die Startoptionen erscheinen.
  3. Startvolume auswählen.
  4. Umschalttaste gedrückt halten.
  5. „Im gesicherten Modus fortfahren“ auswählen.

Intel-Mac:

  1. Mac einschalten oder neu starten.
  2. Sofort die Umschalttaste gedrückt halten.
  3. Taste loslassen, wenn das Anmeldefenster erscheint.

Der sichere Modus ist ein Kreuztest. Wenn der Fehler dort nicht auftritt, ist damit noch keine einzelne Ursache bewiesen. Anschließend müssen Anmeldeobjekte, Agents, Erweiterungen und Drittanbietersoftware einzeln geprüft werden.

Ein normaler Neustart beendet den sicheren Modus.

8.5.25 Apple Diagnose und Wiederherstellung

Apple Diagnose prüft Hardwarekomponenten.

Mac mit Apple-Chip:

  1. Mac ausschalten.
  2. Nicht benötigte externe Geräte trennen.
  3. Ein-/Ausschalter gedrückt halten, bis die Startoptionen erscheinen.
  4. Befehlstaste und D gedrückt halten, bis der Mac neu startet.
  5. Diagnoseanweisungen befolgen.
  6. angezeigte Referenzcodes dokumentieren.

Intel-Mac:

  1. Mac einschalten.
  2. Sofort D gedrückt halten.
  3. Falls erforderlich, beim Start Option-D verwenden.
  4. Diagnoseanweisungen befolgen.
  5. Referenzcodes dokumentieren.

Die macOS-Wiederherstellung wird benötigt, wenn beispielsweise das Startvolume nicht im laufenden System repariert werden kann.

Eine erfolgreiche Apple Diagnose schließt nicht jede denkbare Hardwarestörung aus. Sporadische Fehler, Kabelprobleme oder externe Geräte müssen weiterhin durch Kreuztests untersucht werden.

8.5.26 Systematischer Diagnoseablauf

  1. Störung aufnehmen
    Benutzer, App, Funktion, Zeitpunkt, Häufigkeit und genaue Meldung erfassen.

  2. Umfang bestimmen
    Eine App, ein Benutzer, alle Benutzer oder der gesamte Mac?

  3. Basiszustand sichern
    macOS-Version, Build, Architektur, Laufzeit, Installationshistorie und Speicherplatz dokumentieren.

  4. Fehler reproduzieren
    Zeitpunkt notieren und nur den erforderlichen Ablauf ausführen.

  5. Prozess prüfen
    Existenz, Benutzer, Elternprozess, Zustand, CPU, Speicher und offene Dateien untersuchen.

  6. Dienstzuordnung prüfen
    Richtiges launchd-Label und richtigen Bereich bestimmen.

  7. Protokolle korrelieren
    Meldungen unmittelbar vor, während und nach dem Fehler auswerten.

  8. Ressourcen untersuchen
    CPU, Speicherdruck, Swap, Datenträgerbelegung und I/O messen.

  9. Zugriff prüfen
    Unix-Berechtigungen, ACLs, TCC-Freigaben und App-Signatur unterscheiden.

  10. Abhängigkeiten prüfen
    Netzwerk, DNS, Server, API, Freigabe, Cloud-Dienst oder externes Gerät kontrollieren.

  11. Fehlerdomäne isolieren
    Anderer Benutzer, sicherer Modus, getrennte Peripherie oder Wiederherstellung verwenden.

  12. Hypothese formulieren
    Erwartetes Prüfergebnis und Gegenbeweis festlegen.

  13. Eine kontrollierte Maßnahme durchführen
    Risiko, Rückweg und Messkriterium dokumentieren.

  14. Ursprüngliche Funktion verifizieren
    Nicht nur den Prozessstatus, sondern den realen Benutzerablauf testen.

  15. Nachkontrolle durchführen
    Protokolle und Ressourcen erneut prüfen sowie Rückfall ausschließen.

8.5.27 Befundmatrix

Befund Mögliche Erklärung Nächster Nachweis
App-Prozess fehlt App wurde nicht gestartet oder beendet sich sofort Absturzbericht und zeitlich passende Logs prüfen
Prozess läuft, App reagiert nicht Thread blockiert oder wartet auf Ressource Prozessanalyse oder Spindump erstellen
Dienstlabel im system-Bereich nicht gefunden Falsches Label, falscher Bereich oder Dienst nicht geladen Property-List und tatsächliches Label prüfen
Agent fehlt im gui/<UID>-Bereich Falscher Benutzer oder keine grafische Sitzung UID und Anmeldesitzung prüfen
Dienst besitzt keine PID On-Demand-Zustand oder Startfehler Auslöser betätigen und Logs beobachten
Hohe CPU bei einem Prozess Schleife, hohe Last oder fehlerhafte Verarbeitung Mehrfach messen und Prozess analysieren
Niedrige CPU, App trotzdem langsam Warten auf I/O, Netzwerk oder Sperre fs_usage, Netzwerk und Prozessanalyse
Speicherdruck Gelb oder Rot Speicherengpass Speicherverbrauch und zeitliche Entwicklung prüfen
Swap wächst während der Störung Arbeitsspeicher reicht für aktuelle Last nicht aus verursachende Prozesse bestimmen
Startvolume fast voll Apps, Updates, Logs und Swap beeinträchtigt große Verzeichnisse und Snapshots prüfen
Viele lokale Snapshots Speicher wird durch Snapshots mitbelegt Time-Machine-Zustand und Richtlinie prüfen
Unix-Rechte korrekt, Zugriff trotzdem verweigert TCC- oder Sandbox-Einschränkung Datenschutzfreigabe der richtigen App prüfen
Signaturprüfung schlägt fehl App beschädigt oder verändert Originaldatei des Herstellers vergleichen
Nur ein Benutzer betroffen Benutzerprofil, LaunchAgent oder TCC anderes Benutzerkonto als Kreuztest
Fehler verschwindet im sicheren Modus zusätzliche Software beteiligt Drittanbieterkomponenten einzeln prüfen
Kernel-Panics treten wiederholt auf Treiber-, Erweiterungs- oder Hardwareproblem Panic-Berichte, Peripherietest und Apple Diagnose
Prozess und Port sind vorhanden, Funktion scheitert Abhängigkeit oder Anwendungsebene fehlerhaft vollständigen Benutzerpfad Ende zu Ende prüfen

8.5.28 Mögliche Ursachen und erforderliche Nachweise

Mögliche Ursache Erforderlicher Nachweis
Fehlerhafte App-Konfiguration Fehler ist mit gesicherter Standardkonfiguration reproduzierbar beziehungsweise verschwindet kontrolliert ohne diese Konfiguration
Beschädigte App-Installation Signatur- oder Integritätsprüfung schlägt fehl und eine unveränderte Herstellerinstallation funktioniert
Fehlerhafter LaunchAgent Fehler tritt nur im zugehörigen Benutzerkontext auf und verschwindet nach kontrollierter Deaktivierung
Fehlerhafter LaunchDaemon Systemweiter Fehler korreliert mit Dienststatus, Logs und reproduzierbarem Neustartverhalten
CPU-Engpass CPU ist während der Störung dauerhaft ausgelastet und der verursachende Prozess ist bestimmt
Speicherengpass Speicherdruck und Swap wachsen während der reproduzierten Störung
Voller Datenträger Freier Speicher ist kritisch niedrig und die Funktion arbeitet nach kontrollierter Freigabe wieder
APFS- oder Dateisystemfehler diskutil, Erste Hilfe oder Systemprotokolle melden konkrete Fehler
Berechtigungsfehler Zugriff scheitert mit konkretem Berechtigungsbefund und funktioniert nach minimaler Korrektur
TCC-Verweigerung Benötigte Datenschutzfreigabe fehlt und die Funktion arbeitet nach gezielter Freigabe
Netzwerkabhängigkeit Lokaler Prozess arbeitet, aber DNS, Verbindung oder Zielsystem scheitert reproduzierbar
Drittanbietererweiterung Fehler verschwindet im sicheren Modus und kehrt mit der einzeln aktivierten Erweiterung zurück
Hardwarefehler Apple Diagnose, wiederkehrende Panic-Berichte oder unabhängige Kreuztests belegen den Fehler

8.5.29 Kontrollierte Maßnahmen, Risiko und Rückweg

Maßnahme Risiko Rückweg
App regulär beenden und neu öffnen Nicht gespeicherte Daten App erneut starten und gesicherte Daten öffnen
Prozess mit SIGTERM beenden Funktionsunterbrechung App oder Dienst kontrolliert neu starten
Drittanbieterdienst mit kickstart neu starten Kurzzeitiger Dienstausfall dokumentierten Ausgangszustand und Konfiguration wiederherstellen
Anmeldeobjekt vorübergehend deaktivieren Funktion steht nach Anmeldung nicht bereit Eintrag anhand der gesicherten Liste wieder aktivieren
TCC-Freigabe gezielt erteilen zusätzlicher Datenzugriff Freigabe nach Test wieder entziehen
Drittanbieter-App aktualisieren neue Version kann Konfiguration verändern Installationsdatei und Konfiguration der vorherigen Version sichern
App aus Originalquelle neu installieren lokale App-Bestandteile werden ersetzt Konfiguration und Benutzerdaten vorher sichern
Nicht benötigte Benutzerdaten verschieben Datei steht am alten Ort nicht mehr bereit Datei aus dem Sicherungsort zurückverschieben
Sicherer Modus eingeschränkte Funktionen normal neu starten
Erste Hilfe ausführen zusätzliche Datenträgerbelastung aktuelles Backup bereithalten; bei Fehler abbrechen und Befund sichern
Peripheriegerät trennen zugehörige Funktion steht nicht bereit Gerät nach Test wieder anschließen

Pro Maßnahme darf möglichst nur eine relevante Variable verändert werden.

8.5.30 Verifikation

Nach einer Maßnahme müssen mindestens folgende Prüfungen erfolgen:

8.5.31 Präventionsmaßnahmen

8.5.32 Typische Fehler bei der Diagnose

8.5.33 Typische Prüfungsfragen

Warum beweist ein laufender Prozess noch keine funktionierende Anwendung?

Der Prozess kann blockiert sein, auf eine Ressource warten oder eine benötigte Abhängigkeit nicht erreichen. Entscheidend ist die vollständige Benutzerfunktion.

Was ist der Unterschied zwischen einem LaunchDaemon und einem LaunchAgent?

Ein LaunchDaemon arbeitet systemweit. Ein LaunchAgent arbeitet im Kontext eines Benutzers beziehungsweise einer Benutzeranmeldung.

Warum kann ein registrierter launchd-Dienst keine PID besitzen, ohne fehlerhaft zu sein?

Bedarfsgesteuerte Dienste werden möglicherweise erst gestartet, wenn ein definierter Auslöser eintritt.

Warum ist der Speicherdruck aussagekräftiger als nur der freie Arbeitsspeicher?

macOS nutzt freien Speicher unter anderem für Caches und Komprimierung. Der Speicherdruck zeigt besser, ob die Speicherverwaltung die aktuelle Last noch ausreichend bewältigt.

Warum sollte kill -9 nicht als erste Maßnahme verwendet werden?

Der Prozess erhält keine Möglichkeit, Dateien zu schließen, Daten zu speichern oder seinen Zustand geordnet zu bereinigen.

Warum können korrekte Unix-Berechtigungen trotzdem zu einer Zugriffsverweigerung führen?

Zusätzliche macOS-Schutzmechanismen wie TCC können den Zugriff auf Dateien, Geräte oder geschützte Daten verhindern.

Was bedeutet es, wenn ein Fehler im sicheren Modus nicht auftritt?

Zusätzlich geladene Software, Anmeldeobjekte oder Erweiterungen werden wahrscheinlicher. Eine konkrete Ursache ist dadurch noch nicht bewiesen.

Warum müssen Protokolle zeitlich mit der Störung korreliert werden?

Ein System erzeugt auch im Normalbetrieb Warnungen und Fehler. Erst die zeitliche und funktionale Übereinstimmung macht eine Meldung für den konkreten Vorfall relevant.

Warum ersetzt eine erfolgreiche Erste-Hilfe-Prüfung kein Backup?

Die Prüfung schützt nicht vor späterem Hardwareausfall, versehentlichem Löschen oder bereits beschädigten beziehungsweise fehlenden Benutzerdaten.

8.5.34 Checkliste

8.5.35 Schnellreferenz

Aufgabe Befehl oder Werkzeug
macOS-Version sw_vers
Prozessorarchitektur uname -m
Systemlaufzeit uptime
Hardware- und Softwarebericht system_profiler SPHardwareDataType SPSoftwareDataType
Prozesse ps -axo pid,ppid,user,state,%cpu,%mem,etime,command
Live-Ressourcen top oder Aktivitätsanzeige
Prozess suchen pgrep -fl "Prozessname"
offene Dateien eines Prozesses lsof -nP -p 1234
Prozess analysieren sample 1234 10 -file Bericht.txt
Systemweite launchd-Dienste launchctl print system
Benutzer-Agents launchctl print gui/$(id -u)
Property-List prüfen plutil -lint Datei.plist
letzte Protokolle log show --last 30m
Protokolle live log stream
Arbeitsspeicher vm_stat
Swap sysctl vm.swapusage
Speicherbelegung df -h
Datenträgerstruktur diskutil list
APFS-Struktur diskutil apfs list
lokale Snapshots tmutil listlocalsnapshots /
Datenträger-I/O iostat -w 2 -c 5
Dateiaktivität sudo fs_usage
Berechtigungen und ACLs ls -ldeO@ Pfad
Systemerweiterungen systemextensionsctl list
MDM-Status profiles status -type enrollment
App-Signatur codesign --verify
Gatekeeper-Bewertung spctl --assess
grafische Protokolle Konsole
CPU, Speicher und I/O Aktivitätsanzeige
Dateisystemprüfung Festplattendienstprogramm
Hardwareprüfung Apple Diagnose

8.5.36 Quellen

Offizielle Apple-Dokumentation

Befehlsreferenzen

Die maßgebliche Befehlsreferenz ist die jeweilige lokale macOS-Manpage:

man launchd
man launchctl
man log
man vm_stat
man diskutil
man fs_usage
man system_profiler

Der folgende Spiegel stellt aus Xcode extrahierte Manpages bereit, ist jedoch keine offizielle Apple-Supportseite. Bei Abweichungen gilt die lokale Manpage der installierten macOS-Version:

9. TCP, UDP, Ports, Firewall, NAT und Proxy

9. TCP, UDP, Ports, Firewall, NAT und Proxy

9.1 Ports, Sockets, Listener und gebundene Adressen

Ziel dieser Seite

Diese Seite beschreibt die systematische Diagnose von Ports, Sockets, Listenern und gebundenen IP-Adressen unter Windows, Linux, macOS sowie in Container- und Kubernetes-Umgebungen.

Nach der Bearbeitung muss nachvollziehbar geprüft werden können:

Ein sichtbarer Listener beweist nur, dass im untersuchten Netzwerk-Namespace ein Socket gebunden wurde. Er beweist nicht, dass der Dienst von einem entfernten Client erreichbar ist oder auf Anwendungsebene korrekt funktioniert.

Sicherheits- und Wirkungsklassen

Kennzeichnung Bedeutung
LESEND Erfasst ausschließlich vorhandene Zustände.
NETZAKTIV Erzeugt Netzwerkverkehr zum geprüften Ziel.
SENSITIV Kann interne Adressen, Prozesse, Verbindungen oder Nutzdaten sichtbar machen.
ÄNDERND Verändert Konfiguration oder Laufzeitzustand.
AUSFALLRISIKO Kann bestehende Verbindungen oder Dienste beeinträchtigen.

Socket- und Prozesslisten können interne Dienstnamen, Benutzerkonten, Zieladressen und aktive Kommunikationsbeziehungen enthalten. Ausgaben und Netzwerkaufzeichnungen müssen entsprechend geschützt werden.

Grundbegriffe

Begriff Bedeutung
Port Numerische Kennzeichnung eines Dienstendpunkts innerhalb eines Transportprotokolls.
Socket Vom Betriebssystem verwalteter Kommunikationsendpunkt.
Listener TCP-Socket, der auf neue eingehende Verbindungen wartet.
Bind Zuordnung eines Sockets zu einer lokalen IP-Adresse und einem lokalen Port.
Local Address Lokale IP-Adresse, an die der Socket gebunden ist.
Local Port Lokaler TCP- oder UDP-Port des Sockets.
Remote Address Adresse der Gegenstelle einer bestehenden Verbindung.
Remote Port Port der Gegenstelle einer bestehenden Verbindung.
Wildcard-Bindung Bindung an alle geeigneten lokalen Adressen, beispielsweise 0.0.0.0.
Loopback-Bindung Bindung ausschließlich an die lokale Rückschleifenschnittstelle.
Netzwerk-Namespace Isolierte Netzwerksicht eines Systems oder Containers mit eigenen Schnittstellen, Routen und Sockets.

Ein Port ist nicht unabhängig vom Transportprotokoll zu betrachten. TCP-Port 53 und UDP-Port 53 sind unterschiedliche Endpunkte und können von unterschiedlichen Sockets verwendet werden.

Portnummern und Portbereiche

TCP- und UDP-Portnummern besitzen einen Wertebereich von 0 bis 65535.

Bereich IANA-Bezeichnung Typische Verwendung
0–1023 System Ports Standardisierte oder systemnahe Dienste
1024–49151 User Ports Registrierte Anwendungsdienste
49152–65535 Dynamic and/or Private Ports Dynamische Clientports und private Verwendung

Port 0 besitzt eine besondere Bedeutung und wird nicht wie ein normaler Dienstport verwendet. Eine Anwendung kann beim Binden an Port 0 das Betriebssystem einen freien lokalen Port auswählen lassen.

Auf Unix-artigen Systemen erfordert das Binden niedriger Ports häufig erhöhte Berechtigungen oder eine Fähigkeit wie CAP_NET_BIND_SERVICE. Das genaue Verhalten ist jedoch vom Betriebssystem und dessen Konfiguration abhängig.

Eine Eintragung im IANA-Verzeichnis bedeutet nicht, dass ein Port ausschließlich von dem dort genannten Dienst verwendet werden darf. Für die Diagnose ist die tatsächlich wirksame Konfiguration entscheidend.

Socket- und Verbindungsmodell

Ein TCP-Listener wird im Wesentlichen durch folgende Angaben beschrieben:

Transportprotokoll + lokale IP-Adresse + lokaler Port

Beispiel:

TCP 192.0.2.25:443

Eine aufgebaute TCP-Verbindung wird durch beide Endpunkte unterschieden:

Transportprotokoll
lokale IP-Adresse
lokaler Port
entfernte IP-Adresse
entfernter Port

Beispiel:

TCP
lokal:   192.0.2.25:443
remote:  198.51.100.40:53124

Ein einzelner TCP-Listener auf Port 443 kann deshalb viele gleichzeitige Verbindungen bedienen. Die einzelnen Verbindungen unterscheiden sich mindestens durch die entfernte Adresse oder den entfernten Port.

UDP besitzt keinen TCP-Verbindungsaufbau und keinen TCP-Zustand LISTEN. Ein UDP-Endpunkt kann dennoch an eine lokale Adresse und einen lokalen Port gebunden sein und Datagramme empfangen.

Gebundene Adressen richtig interpretieren

Bindung Bedeutung
127.0.0.1:8080 Nur über IPv4-Loopback des eigenen Systems erreichbar
192.0.2.25:8080 Nur über diese konkrete IPv4-Adresse erreichbar
0.0.0.0:8080 IPv4-Wildcard; Bindung an alle geeigneten lokalen IPv4-Adressen
[::1]:8080 Nur über IPv6-Loopback erreichbar
[::]:8080 IPv6-Wildcard; Bindung an alle geeigneten lokalen IPv6-Adressen
<Container-IP>:8080 Innerhalb des betreffenden Container-Netzwerks gebunden
<Pod-IP>:8080 Innerhalb des Kubernetes-Pod-Netzwerks gebunden

Eine Bindung an 0.0.0.0 bedeutet nicht, dass ein Client die Zieladresse 0.0.0.0 verwenden soll. Der Client verwendet eine konkrete erreichbare Adresse des Servers.

Bei einer Bindung an [::] darf nicht ungeprüft angenommen werden, dass derselbe Socket auch IPv4-Verbindungen akzeptiert. Das Verhalten hängt unter anderem vom Betriebssystem, der Socketoption IPV6_V6ONLY und der Anwendung ab. IPv4 und IPv6 müssen getrennt geprüft werden.

Loopback-, Wildcard- und spezifische Bindung

Loopback-Bindung

127.0.0.1:8080
[::1]:8080

Der Dienst ist grundsätzlich nur vom eigenen Netzwerk-Namespace erreichbar. Das ist beispielsweise für lokale Backends hinter einem Reverse Proxy sinnvoll.

Ein entfernter Client kann diesen Listener nicht direkt erreichen.

Wildcard-Bindung

0.0.0.0:8080
[::]:8080

Der Dienst lauscht grundsätzlich auf allen dafür geeigneten Adressen der entsprechenden Protokollfamilie. Dazu können gehören:

Ob der Dienst tatsächlich von jedem Netz erreichbar ist, wird zusätzlich durch Routing, Firewall, NAT, Sicherheitsgruppen und vorgelagerte Systeme bestimmt.

Bindung an eine konkrete Adresse

192.0.2.25:8080

Der Dienst nimmt Verbindungen nur über diese lokale Adresse an.

Die Bindung kann beim Dienststart fehlschlagen, wenn:

TCP-Zustände

Zustand Einordnung
LISTEN Lokaler Socket wartet auf neue TCP-Verbindungen.
SYN-SENT Verbindungsaufbau wurde begonnen; Antwort steht noch aus.
SYN-RECEIVED Ein SYN wurde empfangen und der Aufbau ist noch nicht abgeschlossen.
ESTABLISHED TCP-Verbindung ist aufgebaut.
FIN-WAIT-1 Lokale Seite hat das Schließen begonnen.
FIN-WAIT-2 Lokale Seite wartet nach eigenem FIN auf das FIN der Gegenstelle.
CLOSE-WAIT Gegenstelle hat geschlossen; lokale Anwendung muss noch schließen.
LAST-ACK Lokale Seite wartet auf die Bestätigung ihres abschließenden FIN.
TIME-WAIT Geschlossene Verbindung wird vorübergehend zur sicheren Protokollabwicklung vorgehalten.
CLOSED Keine aktive TCP-Verbindung.

Viele Einträge in TIME-WAIT sind nicht automatisch ein Fehler. Sie können bei kurzlebigen Verbindungen normal sein.

Dauerhaft viele CLOSE-WAIT-Sockets können darauf hindeuten, dass die lokale Anwendung geschlossene Verbindungen nicht ordnungsgemäß freigibt. Dieser Befund muss über Zeitverlauf, Prozesszustand und Anwendungstelemetrie bestätigt werden.

Was ein Listener beweist – und was nicht

Ein Listener beweist:

Ein Listener beweist nicht:

Erwarteten Endpunkt festlegen

Vor der Diagnose müssen mindestens folgende Sollangaben dokumentiert werden:

Dienst:
<Anwendung oder Dienstname>

Transportprotokoll:
<TCP oder UDP>

Erwartete lokale Adresse:
<Loopback, konkrete Adresse oder Wildcard>

Erwarteter lokaler Port:
<Portnummer>

Erwarteter Netzwerk-Namespace:
<Host, Container, Pod oder anderer Namespace>

Erwartete Erreichbarkeit:
<nur lokal, internes Netz, VPN oder öffentlich>

Vorgelagerte Komponenten:
<Firewall, NAT, Reverse Proxy, Load Balancer oder Service>

Ohne diese Sollangaben kann ein sichtbarer Socket nicht zuverlässig als richtig oder falsch bewertet werden.

Windows: TCP-Listener erfassen

LESEND

Alle TCP-Verbindungen und Listener:

Get-NetTCPConnection

Nur TCP-Listener:

Get-NetTCPConnection `
  -State Listen |
  Sort-Object LocalPort, LocalAddress

Bestimmten lokalen Port prüfen:

Get-NetTCPConnection `
  -State Listen `
  -LocalPort 443

Ausgabe auf wesentliche Felder begrenzen:

Get-NetTCPConnection `
  -State Listen |
  Select-Object `
    LocalAddress,
    LocalPort,
    State,
    OwningProcess |
  Sort-Object LocalPort, LocalAddress

Zu prüfen sind:

Windows: Prozess eines TCP-Listeners bestimmen

LESEND

Beispiel für Port 443:

Get-NetTCPConnection `
  -State Listen `
  -LocalPort 443 |
  ForEach-Object {
    $connection = $_
    $process = Get-Process `
      -Id $connection.OwningProcess `
      -ErrorAction SilentlyContinue

    [pscustomobject]@{
      LocalAddress = $connection.LocalAddress
      LocalPort    = $connection.LocalPort
      ProcessId    = $connection.OwningProcess
      ProcessName  = $process.ProcessName
      ProcessPath  = $process.Path
    }
  }

Einen bekannten Prozess prüfen:

Get-Process `
  -Id 1234

Die ausführbare Datei kann abhängig von Prozessschutz und Berechtigungen nicht immer angezeigt werden.

Windows: Prozess einem Dienst zuordnen

LESEND

$processId = 1234

Get-CimInstance `
  -ClassName Win32_Service `
  -Filter "ProcessId = $processId" |
  Select-Object `
    Name,
    DisplayName,
    State,
    StartMode,
    ProcessId,
    PathName

Wenn kein Dienst zurückgegeben wird, kann der Prozess beispielsweise:

Windows: UDP-Endpunkte erfassen

LESEND

Alle UDP-Endpunkte:

Get-NetUDPEndpoint |
  Sort-Object LocalPort, LocalAddress

Bestimmten UDP-Port prüfen:

Get-NetUDPEndpoint `
  -LocalPort 53

UDP-Endpunkt mit Prozessinformationen anzeigen:

Get-NetUDPEndpoint `
  -LocalPort 53 |
  ForEach-Object {
    $endpoint = $_
    $process = Get-Process `
      -Id $endpoint.OwningProcess `
      -ErrorAction SilentlyContinue

    [pscustomobject]@{
      LocalAddress = $endpoint.LocalAddress
      LocalPort    = $endpoint.LocalPort
      ProcessId    = $endpoint.OwningProcess
      ProcessName  = $process.ProcessName
    }
  }

Das Vorhandensein eines UDP-Endpunkts beweist noch nicht, dass eine gesendete Anfrage verarbeitet oder beantwortet wird.

Windows: netstat als ergänzende Sicht

LESEND

netstat -ano

Nur TCP-Listener:

netstat -ano -p tcp

UDP-Endpunkte:

netstat -ano -p udp

Wiederholte Aktualisierung alle fünf Sekunden:

netstat -ano 5

Beenden mit Strg+C.

Wichtige Optionen:

Option Bedeutung
-a Zeigt aktive Verbindungen und Listener.
-n Zeigt numerische Adressen und Ports.
-o Zeigt die zugehörige Prozess-ID.
-p tcp Begrenzt die Anzeige auf TCP.
-p udp Begrenzt die Anzeige auf UDP.

Namensauflösung sollte für die erste Diagnose mit -n vermieden werden. Anderenfalls können DNS-Verzögerungen die Ausgabe verlangsamen oder Adressen durch Namen verdecken.

Windows: lokale IP-Adressen bestätigen

LESEND

Get-NetIPConfiguration

Alle verwendbaren IP-Adressen:

Get-NetIPAddress |
  Where-Object AddressState -eq "Preferred" |
  Sort-Object InterfaceIndex, AddressFamily

Eine Bindung an eine konkrete Adresse ist nur sinnvoll, wenn diese Adresse tatsächlich im richtigen Netzwerk-Compartment und auf der vorgesehenen Schnittstelle vorhanden ist.

Windows: Kernel- und HTTP.sys-Zuordnungen prüfen

Ein Port kann durch einen Kernelbestandteil oder eine gemeinsame HTTP-Infrastruktur verwaltet werden. Der sichtbare Besitzer muss daher nicht unmittelbar der erwartete Anwendungsprozess sein.

Bei HTTP- oder HTTPS-Diensten unter Windows:

LESEND

netsh http show servicestate

Registrierte URL-Zuordnungen:

netsh http show urlacl

Registrierte TLS-Zertifikatbindungen:

netsh http show sslcert

Portproxy-Konfiguration:

netsh interface portproxy show all

Zu prüfen sind:

Eine URL-Reservierung allein beweist keinen aktiven Listener.

Linux: TCP- und UDP-Sockets mit ss prüfen

ss ist unter Linux das bevorzugte Werkzeug zur Anzeige von Socketinformationen.

LESEND

TCP-Listener:

ss -lnt

TCP-Listener einschließlich Prozessinformationen:

sudo ss -lntp

UDP-Endpunkte:

sudo ss -lnup

TCP- und UDP-Endpunkte gemeinsam:

sudo ss -lntup

Bestimmten TCP-Port prüfen:

sudo ss -lntp 'sport = :443'

Bestimmten UDP-Port prüfen:

sudo ss -lnup 'sport = :53'

Alle TCP-Verbindungen und Zustände:

ss -tan

Zusammenfassung:

ss -s

Wichtige Optionen:

Option Bedeutung
-l Nur lauschende beziehungsweise unverbundene Endpunkte
-n Numerische Adressen und Ports
-t TCP
-u UDP
-p Prozessinformationen
-a Alle Sockets
-x Unix-Domain-Sockets

Prozessinformationen können erhöhte Berechtigungen erfordern.

Linux: Prozess mit lsof bestimmen

LESEND

Alle lauschenden TCP-Sockets:

sudo lsof -nP -iTCP -sTCP:LISTEN

Bestimmten TCP-Port prüfen:

sudo lsof -nP -iTCP:443 -sTCP:LISTEN

Bestimmten UDP-Port prüfen:

sudo lsof -nP -iUDP:53

Wichtige Optionen:

Option Bedeutung
-n Keine Namensauflösung der IP-Adressen
-P Keine Umwandlung von Ports in Dienstnamen
-iTCP TCP-Sockets
-iUDP UDP-Sockets
-sTCP:LISTEN Nur TCP-Listener

Danach können Prozess und Dienst untersucht werden:

ps -fp <PID>

Bei einem systemd-Dienst:

systemctl status <Dienstname>

Prozessbaum:

pstree -p <PID>

Falls pstree nicht installiert ist:

ps -ef --forest

Linux: Netzwerkadressen und Namespace prüfen

LESEND

ip address show

Kompakte Ansicht:

ip -brief address

Netzwerk-Namespaces anzeigen:

ip netns list

Socketansicht eines bekannten Prozess-Namespace:

sudo nsenter \
  -t <PID> \
  -n \
  ss -lntup

Dieser Test ist besonders wichtig, wenn ein Prozess in einem Container oder separaten Netzwerk-Namespace läuft.

Ein Listener innerhalb eines Container-Namespace muss nicht als normaler Listener in der Sockettabelle des Hosts erscheinen.

macOS: TCP- und UDP-Sockets prüfen

Linux-ss ist unter macOS standardmäßig nicht verfügbar. Für die Prozesszuordnung ist lsof besonders geeignet.

LESEND

Alle TCP-Listener:

sudo lsof -nP -iTCP -sTCP:LISTEN

Bestimmten TCP-Port prüfen:

sudo lsof -nP -iTCP:443 -sTCP:LISTEN

UDP-Endpunkte:

sudo lsof -nP -iUDP

Bestimmten UDP-Port prüfen:

sudo lsof -nP -iUDP:53

TCP-Socketzustände mit netstat:

netstat -anv -p tcp

UDP-Sockets:

netstat -anv -p udp

Lokale Netzwerkschnittstellen:

ifconfig

Routing- und Schnittstelleninformationen:

route -n get default

Für die Zuordnung eines Ports zu einem Prozess sollte unter macOS nicht allein auf netstat vertraut werden. lsof liefert dafür normalerweise die geeignetere Sicht.

Unix-Domain-Sockets und andere lokale IPC-Endpunkte

Nicht jede lokale Dienstkommunikation verwendet einen TCP- oder UDP-Port.

Typische Alternativen sind:

Linux:

sudo ss -lxnp

Linux und macOS:

sudo lsof -U

Ein Reverse Proxy kann beispielsweise über einen Unix-Domain-Socket mit seinem Backend kommunizieren. In diesem Fall ist für die Backendverbindung kein TCP-Listener sichtbar.

Die Diagnose muss dann zusätzlich prüfen:

Portkonflikte erkennen

Typische Meldungen eines Bindungsfehlers sind:

Address already in use
EADDRINUSE
WSAEADDRINUSE
Only one usage of each socket address is normally permitted

Mögliche Ursachen:

Windows:

Get-NetTCPConnection `
  -State Listen `
  -LocalPort 8080

Get-NetUDPEndpoint `
  -LocalPort 8080

Linux:

sudo ss -lntup 'sport = :8080'

macOS:

sudo lsof -nP -iTCP:8080 -sTCP:LISTEN

Ein Port kann unter bestimmten Bedingungen absichtlich durch mehrere Prozesse oder Sockets gemeinsam verwendet werden. Beispiele sind Socketaktivierung, SO_REUSEPORT, gemeinsam verwaltete Kernel-Listener oder Clustermechanismen. Deshalb darf ein ungewöhnlicher Mehrfachbefund nicht ohne Prüfung als Fehler bewertet werden.

Weitere typische Bindungsfehler

Meldung oder Fehler Mögliche Einordnung
Address already in use Endpunkt wird bereits verwendet.
Permission denied Fehlende Berechtigung, Sicherheitsrichtlinie oder geschützter Port.
EACCES Zugriff auf Adresse oder Port verweigert.
Cannot assign requested address Konfigurierte lokale Adresse ist nicht vorhanden.
EADDRNOTAVAIL Lokale Bindungsadresse steht nicht zur Verfügung.
Connection refused Zielsystem lehnt aktiv ab; häufig kein passender Listener.
Timeout Keine verwertbare Antwort; Paketverlust, Filterung, Routing oder Überlastung möglich.
Verbindung erfolgreich, Protokollfehler Transport funktioniert; Anwendung oder Protokollkonfiguration fehlerhaft.

Die Zuordnung ist eine erste Einordnung und kein alleiniger Ursachennachweis.

Lokalen TCP-Endpunkt testen

Ein lokaler Test muss zur tatsächlichen Bindung passen.

Windows:

NETZAKTIV

Test-NetConnection `
  -ComputerName "127.0.0.1" `
  -Port 8080 `
  -InformationLevel Detailed

Test gegen die konkrete Schnittstellenadresse:

Test-NetConnection `
  -ComputerName "192.0.2.25" `
  -Port 8080 `
  -InformationLevel Detailed

Linux und macOS:

nc -vz 127.0.0.1 8080

nc -vz 192.0.2.25 8080

Ein erfolgreicher TCP-Test beweist nur, dass der TCP-Verbindungsaufbau funktioniert hat. Er beweist nicht, dass die Anwendung ein gültiges Ergebnis liefert.

Test-NetConnection -Port prüft TCP. Es ist kein allgemeiner UDP-Test.

Loopback und Schnittstellenadresse getrennt testen

Die folgenden Befunde müssen unterschieden werden:

Loopback-Test Test gegen Serveradresse Mögliche Einordnung
erfolgreich erfolgreich Listener ist lokal über beide Pfade erreichbar
erfolgreich fehlgeschlagen falsche Bindung, lokale Firewall oder Adressproblem
fehlgeschlagen erfolgreich Dienst lauscht nur auf konkreter Adresse
fehlgeschlagen fehlgeschlagen kein Listener, falscher Port, falsches Protokoll oder Dienstfehler

Ein Test gegen localhost kann je nach Namensauflösung zuerst ::1 oder 127.0.0.1 verwenden. Für eine eindeutige Diagnose müssen IPv4- und IPv6-Adressen ausdrücklich getestet werden.

Windows:

Test-NetConnection `
  -ComputerName "127.0.0.1" `
  -Port 8080

Test-NetConnection `
  -ComputerName "::1" `
  -Port 8080

Linux und macOS:

nc -4 -vz 127.0.0.1 8080

nc -6 -vz ::1 8080

Test von einem entfernten Client

Der Test muss von einem System erfolgen, das den realen Zugriffspfad möglichst genau abbildet.

Windows:

NETZAKTIV

Test-NetConnection `
  -ComputerName "app.example.test" `
  -Port 443 `
  -InformationLevel Detailed

Linux und macOS:

nc -vz app.example.test 443

Getrennte Prüfung einer bekannten IP-Adresse:

nc -vz 192.0.2.25 443

Zu dokumentieren sind:

Nur autorisierte Ziele und Ports dürfen geprüft werden. Breite Portscans sind für die Diagnose eines bekannten Dienstendpunkts normalerweise nicht erforderlich.

Anwendungsprotokoll statt nur Port prüfen

Nach erfolgreichem TCP-Verbindungsaufbau muss das erwartete Anwendungsprotokoll getestet werden.

HTTP:

curl -v http://127.0.0.1:8080/

HTTPS mit korrektem Hostnamen und festgelegter Zieladresse:

curl -v \
  --resolve app.example.test:443:192.0.2.25 \
  https://app.example.test/

TLS mit Server Name Indication:

openssl s_client \
  -connect 192.0.2.25:443 \
  -servername app.example.test

DNS über UDP:

dig @192.0.2.53 example.test A

DNS über TCP:

dig @192.0.2.53 example.test A +tcp

Ein erfolgreicher TCP-Test auf Port 443 beweist beispielsweise nicht:

UDP richtig prüfen

UDP besitzt keinen TCP-Handshake. Deshalb kann ein allgemeiner UDP-Porttest kein gleichwertiges Ergebnis wie ein erfolgreicher TCP-Verbindungsaufbau liefern.

Zu prüfen sind:

Ein Aufruf wie:

nc -vzu 192.0.2.53 53

kann Datagramme erzeugen, liefert aber ohne geeignete Anwendungsantwort keinen belastbaren Nachweis für einen funktionsfähigen UDP-Dienst.

Für UDP ist ein protokollspezifischer Test vorzuziehen, beispielsweise:

Firewall und Listener getrennt betrachten

Die Diagnoseebenen sind voneinander zu trennen:

Anwendungsprozess
→ lokaler Socket
→ lokale Firewall
→ Routing und Netzwerk
→ externe Firewall oder NAT
→ Client

Mögliche Befunde:

Ein laufender Dienststatus beweist keinen Listener. Ein Listener beweist keine Firewallfreigabe.

Windows-Firewallbezug lesend prüfen

Aktive eingehende Regeln anzeigen:

LESEND

Get-NetFirewallRule `
  -Enabled True `
  -Direction Inbound |
  Select-Object `
    DisplayName,
    Action,
    Profile,
    Direction

Portfilter zu einer bekannten Regel:

Get-NetFirewallRule `
  -DisplayName "<Regelname>" |
  Get-NetFirewallPortFilter

Adressfilter:

Get-NetFirewallRule `
  -DisplayName "<Regelname>" |
  Get-NetFirewallAddressFilter

Anwendungsfilter:

Get-NetFirewallRule `
  -DisplayName "<Regelname>" |
  Get-NetFirewallApplicationFilter

Zu prüfen sind:

Die Firewall darf nicht vorsorglich vollständig deaktiviert werden. Eine Änderung muss auf den nachgewiesenen Dienst, Port, Pfad und Zeitraum begrenzt werden.

Reverse Proxy und Backendlistener

Ein typischer Aufbau ist:

Client
→ Reverse Proxy auf 0.0.0.0:443
→ Backend auf 127.0.0.1:8080

In diesem Fall müssen zwei getrennte Endpunkte geprüft werden:

Mögliche Fehler:

Ein erfolgreicher externer TCP-Verbindungsaufbau beweist nicht, dass das Backend erreichbar ist.

Container und Netzwerk-Namespaces

Container besitzen häufig eine eigene Netzwerksicht. Dabei sind mindestens drei Endpunkte zu unterscheiden:

Anwendungsport im Container
veröffentlichter Port auf dem Host
Port des zugreifenden Clients

Beispiel:

Container: 172.18.0.5:80
Host:      192.0.2.25:8080
Client:    verbindet zu 192.0.2.25:8080

Ein Dienst, der innerhalb des Containers nur an 127.0.0.1:80 gebunden ist, ist über eine normale Portveröffentlichung häufig nicht erreichbar. Für den Zugriff über das Container-Netz muss er üblicherweise an der Containeradresse oder an einer geeigneten Wildcard-Adresse lauschen.

Docker: Portzuordnung prüfen

LESEND

Laufende Container und veröffentlichte Ports:

docker ps \
  --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

Portzuordnungen eines Containers:

docker port <Containername>

Ausführliche Portkonfiguration:

docker inspect \
  <Containername> \
  --format '{{json .NetworkSettings.Ports}}'

Netzwerkmodus:

docker inspect \
  <Containername> \
  --format '{{.HostConfig.NetworkMode}}'

Containeradresse:

docker inspect \
  <Containername> \
  --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'

Listener innerhalb des Containers, falls ss vorhanden ist:

docker exec \
  <Containername> \
  ss -lntup

Alternativ, falls lsof vorhanden ist:

docker exec \
  <Containername> \
  lsof -nP -i

Fehlende Diagnosewerkzeuge im Container sind kein Nachweis für einen fehlenden Listener. Minimal gehaltene Images enthalten häufig weder ss noch lsof.

Docker-Portveröffentlichung interpretieren

Beispiele für Veröffentlichungen:

127.0.0.1:8080:80

Bedeutung:

Host 127.0.0.1:8080
→ Containerport 80

Dieser Hostport soll nur lokal erreichbar sein.

8080:80

Bedeutung:

Hostport 8080
→ Containerport 80

Ohne ausdrücklich angegebene Hostadresse veröffentlicht Docker den Port standardmäßig auf den Hostadressen. Die genaue Erreichbarkeit hängt zusätzlich von Docker-, Firewall- und IPv4-/IPv6-Konfiguration ab.

Wichtige Unterscheidungen:

Ein veröffentlichter Docker-Port muss nicht immer als gewöhnlicher Benutzerprozess-Listener in der erwarteten Host-Socketliste erscheinen. Weiterleitung kann abhängig von Plattform und Konfiguration über Firewall-, NAT- oder Proxymechanismen erfolgen.

Kubernetes: Portebenen unterscheiden

Bei Kubernetes sind mehrere Portangaben auseinanderzuhalten:

Feld Bedeutung
containerPort Deklarative Portangabe am Container; erzwingt keinen Listener.
targetPort Port, zu dem ein Service im ausgewählten Pod weiterleitet.
port Port des Kubernetes-Service.
nodePort Optionaler Port auf den Clusterknoten.
Pod-Port Tatsächlicher Socket des Prozesses im Pod.
Ingress-/Gateway-Port Extern bereitgestellter Listener eines Proxys oder Gateways.

Beispiel:

ports:
  - name: https
    port: 443
    targetPort: 8443

Der Service nimmt Verkehr auf Port 443 an und leitet ihn zum Zielport 8443 weiter.

Wenn targetPort nicht angegeben wird, entspricht er standardmäßig dem Wert von port.

Ein eingetragener containerPort erzeugt keinen Socket und startet keinen Dienst.

Kubernetes-Service und Endpunkte prüfen

LESEND

Services:

kubectl get service \
  --all-namespaces

Bestimmten Service beschreiben:

kubectl describe service \
  <Servicename> \
  -n <Namespace>

Service als YAML anzeigen:

kubectl get service \
  <Servicename> \
  -n <Namespace> \
  -o yaml

EndpointSlices anzeigen:

kubectl get endpointslice \
  -n <Namespace> \
  -l kubernetes.io/service-name=<Servicename> \
  -o wide

Pods und Pod-Adressen:

kubectl get pods \
  -n <Namespace> \
  -o wide

Pod beschreiben:

kubectl describe pod \
  <Podname> \
  -n <Namespace>

Listener im Pod, falls das Werkzeug vorhanden ist:

kubectl exec \
  -n <Namespace> \
  <Podname> \
  -- ss -lntup

Bei mehreren Containern im Pod:

kubectl exec \
  -n <Namespace> \
  <Podname> \
  -c <Containername> \
  -- ss -lntup

Zu prüfen sind:

Ein Service ohne passende Endpunkte kann existieren, obwohl kein Backend erreichbar ist.

Besonderheiten von NodePort, Service und Ingress

Ein Kubernetes-NodePort oder ein durch Regeln weitergeleiteter Service-Port muss nicht als klassischer Anwendungsprozess im Zustand LISTEN erscheinen. Je nach Plattform wird der Verkehr beispielsweise durch:

weitergeleitet.

Deshalb sind für Kubernetes mehrere Ebenen zu prüfen:

externer Listener oder Load Balancer
→ NodePort beziehungsweise Service
→ EndpointSlice
→ Pod-IP und targetPort
→ Prozess im Pod

Die alleinige Suche nach einem Hostprozess mit dem externen Port kann zu einer falschen Schlussfolgerung führen.

IPv4 und IPv6 getrennt prüfen

Zu prüfen sind:

Windows:

Get-NetTCPConnection `
  -State Listen `
  -LocalPort 443 |
  Select-Object LocalAddress, LocalPort, OwningProcess

Linux:

sudo ss -lntp 'sport = :443'

Gezielter IPv4-Test:

curl -4 -v https://app.example.test/

Gezielter IPv6-Test:

curl -6 -v https://app.example.test/

Wenn IPv6 fehlschlägt und IPv4 funktioniert, darf der Fehler nicht durch dauerhaftes Abschalten von IPv6 verdeckt werden. Bindung, Routing, DNS und Firewall müssen getrennt untersucht werden.

Temporäre und dynamische Clientports

Beim Aufbau einer ausgehenden Verbindung verwendet der Client normalerweise einen lokalen Quellport aus einem dynamischen Bereich.

Beispiel:

Client: 192.0.2.100:53124
Server: 192.0.2.25:443

Der Serverdienst lauscht auf Port 443. Der Clientport 53124 wurde für diese Verbindung lokal ausgewählt.

Typische Diagnosefehler:

Die ausführliche Diagnose dynamischer Ports und Porterschöpfung erfolgt in der dafür vorgesehenen Folgeseite.

Dienststatus und Socketstatus vergleichen

Dienststatus Socketstatus Einordnung
läuft Listener vorhanden Dienst hat mindestens einen erwarteten Socket angelegt
läuft Listener fehlt Start teilweise fehlgeschlagen, falsche Konfiguration oder falscher Namespace
beendet Listener vorhanden anderer Prozess, Kernelkomponente oder alte Instanz besitzt den Port
startet wiederholt Listener erscheint kurz Absturz, Health-Check-Fehler oder Portkonflikt möglich
läuft falsche Adresse Bindung oder Schnittstellenkonfiguration fehlerhaft
läuft falscher Port Konfigurationsquelle oder Startparameter prüfen

Ein grüner Dienststatus ist kein ausreichender Funktionsnachweis.

Konfigurationsquelle des Listeners bestimmen

Mögliche Quellen der Bindung:

Zu dokumentieren sind:

wirksamer Port:
<Port>

wirksame Bindungsadresse:
<Adresse>

Quelle:
<Datei, Parameter, Variable oder zentrale Richtlinie>

geladene Version:
<Version oder Prüfsumme>

Zeitpunkt der letzten Änderung:
<Zeitpunkt>

Neustart erforderlich:
<ja oder nein>

Die Änderung einer nicht wirksamen Konfigurationsdatei führt zu keinem belastbaren Ergebnis. Zuerst muss bestimmt werden, welche Konfiguration der laufende Prozess tatsächlich verwendet.

Netzwerkaufzeichnung gezielt einsetzen

Eine Netzwerkaufzeichnung ist sinnvoll, wenn unklar bleibt:

Linux:

SENSITIV · LESEND

sudo tcpdump \
  -ni any \
  'tcp port 443' \
  -c 100

Auf eine Gegenstelle begrenzen:

sudo tcpdump \
  -ni any \
  'host 198.51.100.40 and tcp port 443' \
  -c 100

UDP-Beispiel:

sudo tcpdump \
  -ni any \
  'udp port 53' \
  -c 100

macOS mit konkreter Schnittstelle:

sudo tcpdump \
  -ni en0 \
  'tcp port 443' \
  -c 100

Lokalen macOS-Verkehr auf Loopback:

sudo tcpdump \
  -ni lo0 \
  'tcp port 8080' \
  -c 100

Aufzeichnungen müssen auf den benötigten Port, Host und Zeitraum begrenzt werden. Sie können sensible Adressen und Nutzdaten enthalten.

TCP-Paketbefunde einordnen

Beobachtung Mögliche Einordnung
SYN verlässt Client, erreicht Server nicht Routing, Firewall, NAT oder falsche Zieladresse
SYN erreicht Server, keine Antwort Filterung, Überlastung oder falscher Netzwerk-Namespace
SYN erreicht Server, RST folgt häufig kein passender Listener oder aktive Ablehnung
SYN, SYN/ACK, ACK sichtbar TCP-Verbindungsaufbau erfolgreich
Aufbau erfolgreich, sofortiges FIN Anwendung beendet Verbindung kontrolliert
Aufbau erfolgreich, sofortiges RST Anwendung, Proxy oder Protokollfehler möglich
Server antwortet, Antwort erreicht Client nicht Rückweg, Firewall, asymmetrisches Routing
wiederholte SYN-Pakete Client erhält keine verwertbare Antwort

Die Paketaufzeichnung muss möglichst auf beiden Seiten oder an einem geeigneten Zwischenpunkt korreliert werden. Eine Aufzeichnung nur am Client zeigt nicht sicher, ob das Paket den Server erreicht hat.

Systematischer Diagnoseablauf

  1. Exakte Fehlermeldung, Zeitpunkt und betroffene Anwendung dokumentieren.
  2. Erwartetes Transportprotokoll bestimmen.
  3. Erwarteten lokalen und entfernten Port bestimmen.
  4. Erwartete Bindungsadresse festlegen.
  5. Erforderliche Erreichbarkeit bestimmen: lokal, LAN, VPN oder öffentlich.
  6. Host, Container, Pod und Netzwerk-Namespace unterscheiden.
  7. Tatsächliche IP-Adressen des Systems erfassen.
  8. DNS-Auflösung des Zielnamens dokumentieren.
  9. TCP-Listener oder UDP-Endpunkt erfassen.
  10. IPv4- und IPv6-Bindung getrennt auswerten.
  11. Besitzenden Prozess bestimmen.
  12. Prozess einem Dienst, Container oder Pod zuordnen.
  13. Wirksame Konfigurationsquelle bestimmen.
  14. Dienstprotokolle zum Startzeitpunkt prüfen.
  15. Auf Portkonflikte oder Bindungsfehler prüfen.
  16. Loopback-Endpunkt testen.
  17. Konkrete lokale Schnittstellenadresse testen.
  18. Test von einem repräsentativen entfernten Client durchführen.
  19. Firewall, NAT und Portweiterleitung prüfen.
  20. Reverse Proxy, Load Balancer oder Kubernetes-Service berücksichtigen.
  21. Nach erfolgreichem Transport das Anwendungsprotokoll testen.
  22. Bei Bedarf eine begrenzte Netzwerkaufzeichnung durchführen.
  23. Hypothese, erwarteten Befund und Gegenbeweis formulieren.
  24. Genau eine kontrollierte Maßnahme durchführen.
  25. Identische Tests wiederholen.
  26. Anwendung und weitere repräsentative Clients verifizieren.
  27. Temporäre Diagnoseänderungen zurücknehmen.
  28. Ursache und Prävention dokumentieren.

Hypothese und Gegenbeweis

Beispiel:

Hypothese:
Der Webdienst ist ausschließlich an 127.0.0.1:8080 gebunden und deshalb
von entfernten Clients nicht direkt erreichbar.

Erwarteter Befund:
Der lokale Test gegen 127.0.0.1:8080 funktioniert.
Die Socketliste zeigt keinen Listener auf 192.0.2.25:8080 oder
0.0.0.0:8080.
Der Test eines entfernten Clients schlägt fehl.

Gegenbeweis:
Die Socketliste zeigt einen Listener auf 0.0.0.0:8080 und eine
Netzwerkaufzeichnung bestätigt, dass der Server eingehende SYN-Pakete
mit SYN/ACK beantwortet.

Testmethode:
Socketliste, lokaler Test, entfernter Test und begrenzte Aufzeichnung.

Risiko:
Die lesenden Socketprüfungen sind risikoarm. Aktive Tests erzeugen
Netzwerkverkehr, verändern aber nicht die Dienstkonfiguration.

Eine Änderung darf erst erfolgen, wenn die vermutete Ursache einen messbaren Befund besitzt.

Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko
Bindungsadresse korrigieren falsche Adresse nachgewiesen Dienst kann auf weiteren Netzen erreichbar werden
Port korrigieren Soll- und Ist-Port unterscheiden sich nachweislich Clients oder Überwachung verwenden eventuell alten Port
kollidierenden Prozess beenden falscher Prozessbesitz eindeutig bestätigt Prozess oder abhängiger Dienst fällt aus
Dienst geordnet neu starten Konfigurationsänderung erfordert Neustart bestehende Verbindungen werden unterbrochen
Firewallregel anpassen Listener funktioniert lokal und Filterung ist bestätigt unbeabsichtigte Freigabe
Docker-Portzuordnung korrigieren falscher Host- oder Containerport bestätigt Container muss eventuell neu erstellt werden
Kubernetes-targetPort korrigieren Service und Pod-Listener stimmen nicht überein laufender Dienstverkehr wird umgeleitet
Reverse-Proxy-Ziel korrigieren falscher Backendendpunkt nachgewiesen alle über den Proxy laufenden Anfragen betroffen
IPv4-/IPv6-Bindung korrigieren Protokollfamilienfehler bestätigt zusätzliche Angriffsfläche oder geänderte Erreichbarkeit
Socketdateiberechtigung korrigieren Unix-Socket und Zugriffsfehler bestätigt weitere lokale Prozesse können Zugriff erhalten

Vor der Maßnahme sind zu dokumentieren:

Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
Dienst läuft, Port fehlt Bindung fehlgeschlagen oder falsche Konfiguration Startprotokoll und wirksame Konfiguration
Port vorhanden, falscher Prozess Portkonflikt oder unerwarteter Dienst Prozesspfad und Dienstzuordnung
Listener nur auf 127.0.0.1 nur lokale Erreichbarkeit vorgesehen oder Fehlkonfiguration Sollbindung und Proxyaufbau prüfen
Listener auf 0.0.0.0 alle geeigneten IPv4-Adressen Firewall und tatsächliche Erreichbarkeit prüfen
Listener nur auf [::] IPv6-Wildcard IPv4 und IPv6 ausdrücklich getrennt testen
lokaler Test funktioniert, remote nicht Firewall, Routing, NAT oder Bindungsumfang entfernte Aufzeichnung und Firewallzustand
TCP-Verbindung funktioniert, Anwendung nicht Anwendungs- oder Protokollfehler HTTP-, TLS- oder Diensttest
Connection refused häufig kein passender Listener Server-Socketliste und Paketaufzeichnung
Timeout keine verwertbare Antwort Routing, Filterung und Aufzeichnung
UDP-Endpunkt sichtbar, keine Antwort Anwendung, Firewall oder Rückweg protokollspezifischer Test und Aufzeichnung
Port erscheint kurz und verschwindet Prozess beendet sich oder startet neu Prozess- und Dienstprotokolle
Bindung meldet Address already in use Endpunkt bereits belegt Besitzer des vorhandenen Sockets bestimmen
Bindung meldet Address not available konfigurierte lokale IP fehlt Schnittstellen und Startreihenfolge
Docker-Port veröffentlicht, Anwendung nicht erreichbar falscher Containerport oder Loopback-Bindung im Container Listener innerhalb des Containers
Kubernetes-Service ohne Endpunkte Selektor oder Readiness fehlerhaft Pods und EndpointSlices
Service-Port stimmt, targetPort falsch Weiterleitung auf falschen Pod-Port Service-YAML und Pod-Listener
Host zeigt keinen Listener, NodePort funktioniert regelbasierte Weiterleitung Kubernetes- und Host-Netzwerkregeln
nur localhost schlägt fehl IPv4-/IPv6-Auswahl oder Hosts-Auflösung 127.0.0.1 und ::1 einzeln testen
nur einige Clients scheitern Netzpfad, Adressfamilie oder Richtlinie erfolgreiche und fehlerhafte Pfade vergleichen

Typische Diagnosefehler

Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Eine einzelne erfolgreiche lokale TCP-Verbindung ist keine ausreichende Gesamtverifikation.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Zeitpunkt:
<Datum und Uhrzeit>

Betroffener Dienst:
<Dienst oder Anwendung>

Betroffener Host:
<Hostname und IP-Adresse>

Netzwerk-Namespace:
<Host, Container, Pod oder anderer Namespace>

Transportprotokoll:
<TCP oder UDP>

Erwartete Bindung:
<Adresse und Port>

Tatsächliche Bindung:
<Adresse und Port>

Prozess:
<Name, PID und Pfad>

Dienstzuordnung:
<Service, Container oder Pod>

Konfigurationsquelle:
<Datei, Startparameter, Variable oder Manifest>

Lokaler Test:
<Zieladresse, Port und Ergebnis>

Entfernter Test:
<Client, Zieladresse, Port und Ergebnis>

Anwendungsprotokolltest:
<Test und Ergebnis>

Firewall-, NAT- oder Proxyweg:
<Befund>

IPv4-Befund:
<Ergebnis>

IPv6-Befund:
<Ergebnis>

Nachgewiesene Ursache:
<technischer Befund>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

Durchgeführte Maßnahme:
<genau beschriebene Änderung>

Risiko und Rückweg:
<Beschreibung>

Verifikation:
<identische Tests und Anwendungstest>

Prävention:
<Monitoring oder Konfigurationsverbesserung>

Checkliste

Schnellreferenz

Aufgabe Befehl
Windows-TCP-Verbindungen Get-NetTCPConnection
Windows-TCP-Listener Get-NetTCPConnection -State Listen
Windows-Port prüfen Get-NetTCPConnection -State Listen -LocalPort <Port>
Windows-UDP-Endpunkte Get-NetUDPEndpoint
Windows-UDP-Port prüfen Get-NetUDPEndpoint -LocalPort <Port>
Windows-Prozess prüfen Get-Process -Id <PID>
Windows-Dienst zu PID Get-CimInstance Win32_Service -Filter "ProcessId = <PID>"
Windows-netstat netstat -ano
Windows-IP-Adressen Get-NetIPAddress
Windows-TCP-Test Test-NetConnection -ComputerName <Ziel> -Port <Port>
Windows-HTTP.sys-Zustand netsh http show servicestate
Windows-URL-Reservierungen netsh http show urlacl
Windows-Portproxy netsh interface portproxy show all
Linux-TCP-Listener sudo ss -lntp
Linux-UDP-Endpunkte sudo ss -lnup
Linux-TCP-Port prüfen sudo ss -lntp 'sport = :<Port>'
Linux-Socketübersicht ss -s
Linux-Prozess zu TCP-Port sudo lsof -nP -iTCP:<Port> -sTCP:LISTEN
Linux-Prozess zu UDP-Port sudo lsof -nP -iUDP:<Port>
Linux-IP-Adressen ip -brief address
Linux-Netzwerk-Namespaces ip netns list
macOS-TCP-Listener sudo lsof -nP -iTCP -sTCP:LISTEN
macOS-UDP-Endpunkte sudo lsof -nP -iUDP
macOS-TCP-Sockets netstat -anv -p tcp
Unix-Domain-Sockets Linux sudo ss -lxnp
Unix-Domain-Sockets mit lsof sudo lsof -U
TCP-Test Linux/macOS nc -vz <Ziel> <Port>
HTTP-Test curl -v http://<Ziel>:<Port>/
HTTPS-Test mit Zieladresse curl -v --resolve <Name>:<Port>:<IP> https://<Name>/
TLS-Test mit SNI openssl s_client -connect <IP>:<Port> -servername <Name>
Docker-Portübersicht docker ps --format 'table {{.Names}}\t{{.Ports}}'
Docker-Portzuordnung docker port <Container>
Docker-Netzwerkmodus docker inspect <Container> --format '{{.HostConfig.NetworkMode}}'
Listener im Container docker exec <Container> ss -lntup
Kubernetes-Services kubectl get service --all-namespaces
Kubernetes-Service prüfen kubectl describe service <Service> -n <Namespace>
Kubernetes-EndpointSlices kubectl get endpointslice -n <Namespace> -l kubernetes.io/service-name=<Service>
Listener im Pod kubectl exec -n <Namespace> <Pod> -- ss -lntup
begrenzte Linux-Aufzeichnung sudo tcpdump -ni any 'tcp port <Port>' -c 100

Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen

Stop-Process
taskkill
Stop-Service
Restart-Service
Set-NetFirewallRule
New-NetFirewallRule
Remove-NetFirewallRule
netsh advfirewall set allprofiles state off
kill
kill -9
systemctl stop
systemctl restart
iptables
nft
ufw disable
firewall-cmd --permanent
docker stop
docker restart
docker rm
kubectl delete
kubectl rollout restart
Änderung einer Wildcard- oder öffentlichen Bindung
Entfernen einer Portweiterleitung
vollständiges Deaktivieren einer Hostfirewall

Das Beenden eines Prozesses oder Neustarten eines Dienstes kann den aktuellen Portbesitz zwar verändern, vernichtet aber möglicherweise den für die Ursachenanalyse wichtigen Ausgangszustand.

Quellen

Offizielle Microsoft-Dokumentation

Offizielle Linux- und Unix-Dokumentation

Offizielle Docker-Dokumentation

Offizielle Kubernetes-Dokumentation

Standards und Register

Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet.

9. TCP, UDP, Ports, Firewall, NAT und Proxy

9.2 TCP-Handshake, Timeouts und TCP Reset

Ziel dieser Seite

Diese Seite beschreibt den vollständigen Lebenszyklus einer TCP-Verbindung:

Nach der Bearbeitung muss unterschieden werden können:

Ein TCP-Fehler darf nicht allein anhand einer Anwendungsmeldung wie „Timeout“ oder „Connection reset“ eingeordnet werden. Er muss mit Socketzuständen, Zeitpunkten, Protokollen und bei Bedarf einer begrenzten Paketaufzeichnung korreliert werden.

Sicherheits- und Wirkungsklassen

Kennzeichnung Bedeutung
LESEND Erfasst ausschließlich vorhandene Zustände.
NETZAKTIV Erzeugt Netzwerkverkehr zum geprüften Ziel.
SENSITIV Kann interne Adressen, Verbindungen oder Nutzdaten sichtbar machen.
ÄNDERND Verändert Konfiguration oder Laufzeitzustand.
AUSFALLRISIKO Kann Verbindungen, Prozesse oder Dienste beeinträchtigen.

Paketaufzeichnungen können enthalten:

Aufzeichnungen müssen technisch und zeitlich begrenzt, geschützt gespeichert und nach Abschluss der Diagnose kontrolliert entfernt werden.

Grundlegende Eigenschaften von TCP

TCP stellt Anwendungen einen zuverlässigen, geordneten und bidirektionalen Bytestrom zur Verfügung.

TCP bietet unter anderem:

TCP stellt keine Anwendungsnachrichten bereit. Eine Anwendung übergibt einen Bytestrom. Die Aufteilung in einzelne TCP-Segmente kann sich während der Übertragung ändern.

Folgende Annahmen sind deshalb falsch:

Eine TCP-Verbindung entspricht einer Anfrage.
Ein TCP-Segment entspricht einer Anwendungsnachricht.
Ein ACK bedeutet, dass die Anwendung die Daten verarbeitet hat.
Ein erfolgreicher Handshake bedeutet, dass HTTP, TLS oder die Anwendung funktioniert.

Ein TCP-ACK bestätigt grundsätzlich, dass die TCP-Implementierung der Gegenstelle die entsprechenden Bytes angenommen hat. Es beweist nicht, dass:

TCP-Verbindung eindeutig bestimmen

Eine TCP-Verbindung wird durch ihre Endpunkte unterschieden:

Transportprotokoll
lokale IP-Adresse
lokaler Port
entfernte IP-Adresse
entfernter Port

Beispiel:

Client: 192.0.2.100:53124
Server: 192.0.2.25:443

Die Verbindung kann kompakt dargestellt werden als:

192.0.2.100:53124 → 192.0.2.25:443

Auf der Serverseite ist dieselbe Verbindung aus umgekehrter Perspektive sichtbar:

lokal:   192.0.2.25:443
remote:  192.0.2.100:53124

Bei NAT, Load Balancern oder Proxys können sich Adressen und Ports entlang des Pfads verändern. Paketaufzeichnungen auf verschiedenen Seiten müssen deshalb anhand von:

korreliert werden.

Wichtige TCP-Flags

Flag Bedeutung
SYN Synchronisiert Sequenznummern und beginnt normalerweise den Verbindungsaufbau.
ACK Das Bestätigungsfeld ist gültig.
FIN Der Sender hat keine weiteren Daten mehr zu senden.
RST Verbindung zurücksetzen oder ungültige Verbindung ablehnen.
PSH Kennzeichnet Daten für eine zeitnahe Weitergabe innerhalb des TCP-Datenstroms.
URG Das Urgent-Pointer-Feld ist relevant.
ECE Wird im Zusammenhang mit Explicit Congestion Notification verwendet.
CWR Signalisiert eine reduzierte Congestion Window nach ECN.

PSH definiert keine Anwendungsnachricht und garantiert keine bestimmte Paketgröße oder sofortige Verarbeitung durch die Anwendung.

Verbindungsaufbau zwischen Client und Server

Der reguläre TCP-Verbindungsaufbau wird als Three-Way Handshake bezeichnet.

Client                                      Server

CLOSED                                      LISTEN
   |                                           |
   |  SYN, Seq=x                               |
   |------------------------------------------>|
   |                                           |
   |  SYN, ACK, Seq=y, Ack=x+1                 |
   |<------------------------------------------|
   |                                           |
   |  ACK, Ack=y+1                             |
   |------------------------------------------>|
   |                                           |
ESTABLISHED                                ESTABLISHED

Die drei logischen Schritte sind:

  1. Der Client sendet ein Segment mit SYN.
  2. Der Server bestätigt das Client-SYN und sendet sein eigenes SYN mit SYN, ACK.
  3. Der Client bestätigt das Server-SYN mit ACK.

Das dritte Segment kann abhängig von Anwendung und TCP-Erweiterungen bereits Daten enthalten. Für die grundlegende Diagnose wird es dennoch als dritter Handshake-Schritt betrachtet.

Sequenznummern beim Handshake

Beispiel:

Client → Server:
SYN
Seq = 1000

Server → Client:
SYN, ACK
Seq = 7000
Ack = 1001

Client → Server:
ACK
Seq = 1001
Ack = 7001

Ein SYN verbraucht eine Sequenznummer. Deshalb bestätigt der Server:

1000 + 1 = 1001

Auch das SYN des Servers verbraucht eine Sequenznummer. Der Client bestätigt:

7000 + 1 = 7001

Die tatsächlich verwendeten Initial Sequence Numbers werden von den TCP-Implementierungen bestimmt und sind nicht als einfache fortlaufende Werte vorhersehbar.

TCP-Zustände während des Verbindungsaufbaus

Zustand Bedeutung
CLOSED Es besteht keine TCP-Verbindung.
LISTEN Der Server wartet auf neue Verbindungsanfragen.
SYN-SENT Ein SYN wurde gesendet; eine passende Antwort steht aus.
SYN-RECEIVED SYN wurde empfangen und mit SYN/ACK beantwortet; abschließendes ACK steht aus.
ESTABLISHED Der Handshake ist abgeschlossen.

Eine große Zahl von Verbindungen in SYN-SENT kann bedeuten:

Viele Einträge in SYN-RECEIVED können bedeuten:

Ein einzelner kurz sichtbarer Zustand SYN-SENT oder SYN-RECEIVED ist normal. Entscheidend sind Häufigkeit, Dauer und Vergleich mit einer Baseline.

TCP-Optionen während des Handshakes

Wichtige Optionen werden typischerweise in SYN-Segmenten angeboten oder ausgehandelt.

Option Zweck
MSS Maximale TCP-Nutzdatenmenge, die die jeweilige Seite in einem Segment empfangen möchte.
Window Scale Erweitert die darstellbare TCP-Empfangsfenstergröße.
SACK Permitted Erlaubt Selective Acknowledgment.
Timestamps Unterstützt unter anderem RTT-Messungen und Schutzmechanismen gegen alte Segmente.
ECN Ermöglicht Überlastsignalisierung ohne zwingenden Paketverlust, sofern der Pfad sie unterstützt.

Bei der Diagnose müssen die SYN- und SYN/ACK-Optionen verglichen werden.

Zu prüfen sind:

Ein Handshake kann trotz unterschiedlicher angebotener Optionen erfolgreich sein. Die Optionen können jedoch das spätere Übertragungsverhalten beeinflussen.

Erfolgreicher TCP-Handshake

Eine normale Paketfolge ist:

Client → Server  SYN
Server → Client  SYN, ACK
Client → Server  ACK

Dieser Befund beweist:

Dieser Befund beweist nicht:

SYN ohne Antwort

Typischer Paketbefund:

Client → Server  SYN
Client → Server  SYN erneut
Client → Server  SYN erneut
...
Timeout

Mögliche Ursachen:

Aus einer alleinigen Clientaufzeichnung kann nicht sicher geschlossen werden, ob das SYN den Server erreicht hat. Dafür wird eine korrelierte Aufzeichnung am Server oder an einem geeigneten Zwischenpunkt benötigt.

SYN wird mit Reset beantwortet

Typischer Paketbefund:

Client → Server  SYN
Server → Client  RST, ACK

Typische Einordnung:

Eine Anwendung meldet in diesem Fall häufig:

Connection refused
Verbindung abgelehnt
No connection could be made because the target machine actively refused it

Die Meldung beweist nicht, dass der eigentliche Zielserver selbst den Reset erzeugt hat. Firewalls, Proxys und Load Balancer können ebenfalls TCP-Reset-Segmente erzeugen.

Server sendet SYN/ACK, erhält aber kein ACK

Typischer Befund am Server:

Client → Server  SYN
Server → Client  SYN, ACK
Server → Client  SYN, ACK erneut
Server → Client  SYN, ACK erneut
...

Mögliche Ursachen:

Zur Eingrenzung werden Aufzeichnungen auf Client- und Serverseite benötigt.

Handshake funktioniert nur teilweise

Paketbefund Einordnung
kein SYN sichtbar Anwendung startet keinen TCP-Aufbau oder Aufzeichnungspunkt ist falsch
SYN sichtbar, keine Antwort Filterung, Routing, Verlust oder fehlender Rückweg
SYN gefolgt von RST aktive Ablehnung
SYN/ACK wird wiederholt abschließendes ACK fehlt
Handshake vollständig, danach keine Daten Anwendung wartet, Protokollmissverständnis oder falsche Rolle
Handshake vollständig, danach RST Anwendung, Betriebssystem oder Zwischenkomponente bricht ab
Handshake vollständig, danach FIN kontrollierte Beendigung
Handshake vollständig, TLS beginnt und stoppt TLS- oder Anwendungsproblem, nicht TCP-Verbindungsaufbau

Die kontrollierte Datenübertragung bei TCP

Nach dem Handshake können beide Seiten Daten senden.

TCP arbeitet als bidirektionaler Bytestrom:

Client ⇄ Server

Jede Richtung besitzt eigene:

Ein Client kann gleichzeitig Daten senden und Daten des Servers empfangen.

Sequenznummern bei der Datenübertragung

Beispiel:

Client sendet:
Seq = 1001
TCP-Nutzdatenlänge = 500 Bytes

Der Server bestätigt als nächste erwartete Sequenznummer:

Ack = 1501

Berechnung:

1001 + 500 = 1501

Die Bestätigungsnummer bezeichnet das nächste Byte, das die empfangende Seite erwartet.

Wenn der Server Ack = 1501 sendet, bestätigt er kumulativ alle Bytes bis einschließlich Sequenznummer 1500.

Kumulative Bestätigungen

TCP-ACKs sind grundsätzlich kumulativ.

Beispiel:

Segment 1: Seq 1001, Länge 500
Segment 2: Seq 1501, Länge 500
Segment 3: Seq 2001, Länge 500

Wenn der Empfänger anschließend sendet:

Ack = 2501

sind damit alle zusammenhängend empfangenen Bytes bis 2500 bestätigt.

Ein fehlendes Segment kann dazu führen, dass der Empfänger weiterhin dieselbe nächste erwartete Sequenznummer bestätigt.

Selective Acknowledgment

Wenn SACK während des Handshakes erlaubt wurde, kann der Empfänger zusätzlich mitteilen, welche späteren Datenblöcke bereits angekommen sind.

Beispiel:

Segment 1 angekommen
Segment 2 fehlt
Segment 3 angekommen
Segment 4 angekommen

Der kumulative ACK verweist weiterhin auf Segment 2. SACK-Informationen können jedoch anzeigen, dass Segment 3 und Segment 4 bereits vorhanden sind.

Dadurch muss der Sender nicht zwingend alle späteren Daten erneut übertragen.

Verzögerte ACKs

TCP-Implementierungen können Bestätigungen kurz verzögern, um:

Ein nicht sofort sichtbares ACK ist deshalb nicht automatisch ein Fehler.

Entscheidend sind:

Flusskontrolle

Der Empfänger teilt über das TCP-Empfangsfenster mit, wie viele weitere Bytes er aufnehmen kann.

Vereinfacht:

Sender darf nur so viele unbestätigte Daten senden,
wie das angekündigte Empfangsfenster zulässt.

Ein kleiner werdendes Empfangsfenster kann darauf hindeuten, dass die empfangende Anwendung Daten nicht schnell genug aus dem Socket liest.

Ein Empfangsfenster von null bedeutet, dass momentan kein weiterer Empfangspuffer verfügbar ist. Die ausführliche Diagnose von Zero Window und Übertragungsstillständen erfolgt auf der dafür vorgesehenen Seite zu Retransmissions, Zero Window und MTU-Problemen.

Überlastkontrolle

Zusätzlich zur Flusskontrolle begrenzt TCP die Sendemenge anhand des vermuteten Netzzustands.

Wichtige Begriffe:

Begriff Bedeutung
cwnd Congestion Window des Senders
rwnd vom Empfänger angekündigtes Receive Window
RTT gemessene Round Trip Time
RTO berechneter Retransmission Timeout
Slow Start vorsichtige Erhöhung der Sendemenge zu Beginn oder nach bestimmten Verlusten
Congestion Avoidance kontrollierte Anpassung der Sendemenge
Fast Retransmit schnelle Wiederholung bei Verlusthinweisen
Fast Recovery Wiederherstellung nach bestimmten Verlustereignissen

Die tatsächlich sendbare unbestätigte Datenmenge wird unter anderem durch Empfangsfenster und Congestion Window begrenzt.

Retransmission Timeout

Ein Sender startet für noch nicht bestätigte Daten einen Wiederholungstimer.

Der RTO wird aus gemessenen Laufzeiten und deren Schwankungen berechnet. Er ist kein fester universeller Wert.

Wenn eine Bestätigung nicht rechtzeitig eintrifft:

Die genaue Anzahl der Versuche und die Gesamtdauer sind abhängig von:

Es darf kein universeller TCP-Timeoutwert angenommen werden.

Fast Retransmit

Beim klassischen Fast-Retransmit-Verfahren können mehrere Duplicate ACKs den Sender darauf hinweisen, dass ein früheres Segment fehlt, während spätere Segmente angekommen sind.

Der Sender kann das fehlende Segment wiederholen, bevor der normale RTO abläuft.

Moderne TCP-Implementierungen können zusätzlich oder alternativ weitere Verlustalgorithmen und SACK-Informationen verwenden. Deshalb darf nicht jeder Fast-Retransmit ausschließlich anhand einer festen Zahl von Duplicate ACKs erklärt werden.

Duplicate ACKs richtig einordnen

Duplicate ACKs können entstehen durch:

Ein Duplicate ACK ist ein Hinweis und kein alleiniger Beweis für Paketverlust.

TCP-Retransmissions richtig einordnen

Eine als Retransmission markierte Übertragung kann bedeuten:

Wireshark-Analysefelder wie tcp.analysis.retransmission sind Analyseergebnisse und keine im TCP-Paket übertragenen Flags.

TCP Checksum Offloading berücksichtigen

Bei einer Aufzeichnung auf dem sendenden Host kann eine TCP-Prüfsumme als fehlerhaft erscheinen, obwohl das Netzwerkpaket später korrekt übertragen wird.

Mögliche Ursache:

Deshalb gilt:

Eine lokal als fehlerhaft angezeigte TCP-Prüfsumme
beweist ohne weitere Prüfung keinen Netzwerkfehler.

Zu vergleichen sind:

TCP besitzt keine Anwendungs-Lebendigkeitsprüfung

Eine bestehende TCP-Verbindung kann im Zustand ESTABLISHED verbleiben, obwohl:

Solange keine Daten übertragen oder Prüfmechanismen ausgelöst werden, erkennt TCP einen solchen Zustand nicht zwingend sofort.

Mögliche zusätzliche Mechanismen sind:

Ein TCP-Keepalive beweist nur eine Reaktion des TCP-Endpunkts. Es beweist nicht automatisch, dass die Anwendung fachlich gesund ist.

Timeout ist nicht gleich Timeout

Die Meldung „Timeout“ kann aus verschiedenen Ebenen stammen.

Timeoutart Phase Typischer Befund
DNS-Timeout vor TCP kein SYN zum eigentlichen Server
TCP-Connect-Timeout Handshake SYN bleibt unbeantwortet
TCP-Retransmission-Timeout Datenübertragung unbestätigte Segmente werden wiederholt
TLS-Handshake-Timeout nach TCP-Aufbau TCP steht, TLS wird nicht abgeschlossen
Application-Read-Timeout nach Anfrage TCP steht, erwartete Antwort fehlt
Application-Write-Timeout Datenversand Anwendung kann nicht rechtzeitig schreiben
Proxy-Connect-Timeout Proxy zum Backend Client erreicht Proxy, Proxy nicht das Backend
Proxy-Read-Timeout Proxy wartet auf Backend Backendverbindung besteht, Antwort dauert zu lange
Firewall-Idle-Timeout längere Inaktivität Sitzungszustand der Firewall wird entfernt
NAT-Idle-Timeout längere Inaktivität NAT-Zuordnung läuft ab
Load-Balancer-Idle-Timeout längere Inaktivität Load Balancer verwirft inaktive Sitzung
TCP-Keepalive-Timeout Prüfmechanismus Gegenstelle reagiert nicht auf Keepalive-Probes
Anwendungsdeadline beliebige Phase Anwendung bricht nach eigener Gesamtfrist ab

Vor einer Änderung muss festgestellt werden, welcher Zeitgeber tatsächlich abgelaufen ist.

Connect-Timeout erkennen

Typischer Ablauf:

Anwendung startet Verbindung
Client sendet SYN
keine verwertbare Antwort
SYN wird wiederholt
Anwendung meldet Timeout

Zu prüfen sind:

Bei mehreren DNS-Adressen kann die Anwendung nacheinander oder parallel unterschiedliche Ziele versuchen. Die sichtbare Gesamtdauer muss daher nicht dem Timeout eines einzelnen TCP-Versuchs entsprechen.

Anwendungs-Timeout nach erfolgreichem Handshake

Typischer Ablauf:

SYN
SYN, ACK
ACK
Anwendungsanfrage
keine oder verspätete Anwendungsantwort
Anwendung meldet Timeout

TCP ist in diesem Fall grundsätzlich aufgebaut.

Mögliche Ursachen:

Die Diagnose darf nicht bei einem erfolgreichen Porttest enden.

Idle-Timeout erkennen

Typischer Ablauf:

TCP-Verbindung wird erfolgreich aufgebaut
Datenübertragung funktioniert
Verbindung bleibt längere Zeit inaktiv
erste neue Übertragung schlägt fehl
eine neue TCP-Verbindung funktioniert wieder

Mögliche Ursachen:

Benötigter Nachweis:

TCP Reset

Ein TCP-Reset wird durch das Flag RST signalisiert.

Ein Reset bedeutet grundsätzlich:

Diese TCP-Verbindung soll sofort zurückgesetzt werden
oder der angesprochene TCP-Zustand ist nicht gültig.

Im Unterschied zu einem geordneten Abbau mit FIN ist ein Reset ein abrupter Abbruch.

Mögliche Anwendungsmeldungen:

Connection reset by peer
ECONNRESET
An existing connection was forcibly closed by the remote host
Die Verbindung wurde vom Kommunikationspartner zurückgesetzt
SocketException: Connection reset

Die Formulierung „by peer“ bedeutet nicht zwingend, dass der eigentliche Anwendungsprozess der Gegenstelle den Reset absichtlich erzeugt hat. Der Reset kann stammen von:

Typische Ursachen eines TCP Reset

Nicht jede Prozessbeendigung erzeugt zwingend einen Reset. Abhängig vom Socketzustand und Betriebssystem kann auch ein kontrollierter FIN-Abbau erfolgen.

Reset während des Handshakes

Paketfolge:

Client → Server  SYN
Server → Client  RST, ACK

Mögliche Einordnung:

Nächster Nachweis:

Reset unmittelbar nach erfolgreichem Handshake

Paketfolge:

SYN
SYN, ACK
ACK
RST

Mögliche Ursachen:

Zu prüfen sind:

Reset nach Übertragung einer Anfrage

Paketfolge:

Handshake erfolgreich
Client sendet Anfrage
Server oder Zwischenkomponente sendet RST

Mögliche Ursachen:

Der Inhalt unmittelbar vor dem Reset ist für die Ursachenbestimmung besonders wichtig.

Reset nach längerer Inaktivität

Typischer Ablauf:

Verbindung ist ESTABLISHED
keine Übertragung über längere Zeit
Client sendet neue Daten
RST wird empfangen

Mögliche Ursache:

Zu vergleichen sind:

Reset nach Wiederholungen

Möglicher Ablauf:

Daten werden gesendet
Bestätigung fehlt
Daten werden wiederholt
weitere Wiederholungen
RST oder lokaler Verbindungsabbruch

Ein Reset nach Wiederholungen kann bedeuten:

Die zeitliche Reihenfolge muss genau ausgewertet werden. Der Reset kann Folge und nicht Ursache des ursprünglichen Problems sein.

Reset-Absender bestimmen

In der Clientaufzeichnung ist zunächst die Quelladresse des Reset-Segments sichtbar. Sie ist jedoch nicht immer ein eindeutiger Beweis für den tatsächlichen Erzeuger.

Zwischenkomponenten können:

Belastbarer Nachweis:

  1. Aufzeichnung am Client.
  2. Aufzeichnung am Server.
  3. Zeitliche Synchronisation beider Systeme.
  4. Vergleich derselben TCP-Verbindung.
  5. Prüfung, ob der Reset den Server verlässt.
  6. Prüfung, ob der Server den Reset überhaupt empfängt.
  7. Protokolle von Firewall, Proxy und Load Balancer korrelieren.

Beispiel:

Client sieht einen RST.
Serveraufzeichnung zeigt keinen ausgehenden RST.
Firewallprotokoll zeigt eine aktive Sitzungsbeendigung.

Einordnung:
Der Reset wurde wahrscheinlich von der Firewall erzeugt.

Dies ist eine Schlussfolgerung aus mehreren Befunden und nicht allein aus der IP-Quelladresse.

FIN, RST und Timeout unterscheiden

Befund Bedeutung
FIN Sender beendet seine Senderichtung geordnet.
RST Verbindung wird abrupt zurückgesetzt.
Timeout Innerhalb der erwarteten Frist kam keine verwertbare Reaktion.
ICMP-Fehler IP- oder Netzwerkebene meldet ein Problem.
Anwendungsfehler TCP kann funktionieren, während das höhere Protokoll fehlschlägt.

Ein FIN bedeutet nicht zwingend, dass die gesamte Verbindung sofort beendet ist. TCP unterstützt einen geordneten Abbau je Richtung.

Verbindungsabbau zwischen Client und Server

Ein regulärer TCP-Abbau besteht logisch aus:

Teilnehmer A                                 Teilnehmer B

ESTABLISHED                                 ESTABLISHED
     |                                           |
     |  FIN, ACK                                 |
     |------------------------------------------>|
     |                                           |
FIN-WAIT-1                                  CLOSE-WAIT
     |                                           |
     |  ACK                                      |
     |<------------------------------------------|
     |                                           |
FIN-WAIT-2                                  CLOSE-WAIT
     |                                           |
     |  FIN, ACK                                 |
     |<------------------------------------------|
     |                                           |
TIME-WAIT                                   LAST-ACK
     |                                           |
     |  ACK                                      |
     |------------------------------------------>|
     |                                           |
TIME-WAIT                                     CLOSED
     |
     | nach Ablauf der Wartezeit
     |
  CLOSED

Dies wird häufig als Four-Way Termination bezeichnet.

In einer echten Aufzeichnung müssen nicht immer vier getrennte Pakete sichtbar sein. ACK und FIN können kombiniert werden.

FIN verbraucht eine Sequenznummer

Wie SYN verbraucht auch FIN eine Sequenznummer.

Beispiel:

Teilnehmer A sendet:
FIN, Seq = 5000

Teilnehmer B bestätigt:
ACK = 5001

Das FIN signalisiert:

Ich werde in dieser Richtung keine weiteren Daten mehr senden.

Die Gegenrichtung kann abhängig vom Anwendungs- und Socketzustand noch Daten übertragen.

Half-Close

Bei einem Half-Close wurde nur eine Senderichtung geordnet geschlossen.

Beispiel:

Client sendet FIN.
Server bestätigt FIN.
Server sendet weiterhin verbleibende Antwortdaten.
Server sendet später sein eigenes FIN.

Half-Close ist nicht dasselbe wie eine Half-Open Connection.

Begriff Bedeutung
Half-Close Eine Richtung wurde geordnet mit FIN beendet.
Half-Open Beide Endpunkte besitzen unterschiedliche Vorstellungen darüber, ob die Verbindung noch existiert.

Eine Half-Open Connection kann beispielsweise entstehen, wenn ein System neu startet und den früheren TCP-Zustand verliert, während die Gegenstelle die Verbindung weiterhin als vorhanden betrachtet.

TCP-Zustände beim Verbindungsabbau

Zustand Bedeutung
FIN-WAIT-1 Lokales FIN wurde gesendet; Bestätigung oder FIN der Gegenstelle steht aus.
FIN-WAIT-2 Lokales FIN wurde bestätigt; FIN der Gegenstelle steht aus.
CLOSE-WAIT FIN der Gegenstelle wurde empfangen; lokale Anwendung hat noch nicht geschlossen.
CLOSING Beide Seiten haben nahezu gleichzeitig FIN gesendet.
LAST-ACK Lokales FIN wurde nach empfangenem FIN gesendet; abschließendes ACK steht aus.
TIME-WAIT Endpunkt wartet, damit verspätete Segmente einer alten Verbindung nicht falsch zugeordnet werden.
CLOSED Verbindung ist vollständig beendet.

CLOSE-WAIT richtig interpretieren

CLOSE-WAIT bedeutet:

Die Gegenstelle hat ihre Senderichtung geschlossen.
Das lokale Betriebssystem wartet darauf,
dass die lokale Anwendung ihren Socket schließt.

Viele dauerhaft vorhandene CLOSE-WAIT-Sockets können hinweisen auf:

CLOSE-WAIT wird nicht durch das bloße Ändern eines TCP-Timers behoben. Zuerst müssen Prozess und Anwendungscode beziehungsweise Herstellerprotokolle geprüft werden.

FIN-WAIT-2 richtig interpretieren

FIN-WAIT-2 bedeutet:

Die lokale Seite hat ihre Senderichtung geschlossen.
Die Gegenstelle hat dies bestätigt,
aber noch kein eigenes FIN gesendet.

Mögliche Ursachen bei ungewöhnlich langen Beständen:

Ein kurzfristiger FIN-WAIT-2-Zustand ist nicht automatisch fehlerhaft.

TIME-WAIT richtig interpretieren

TIME-WAIT schützt unter anderem davor, dass verspätete Segmente einer alten Verbindung einer späteren Verbindung mit denselben Endpunkten zugeordnet werden.

Viele TIME-WAIT-Einträge können bei folgenden Arbeitslasten normal sein:

Zu prüfen sind:

TIME-WAIT darf nicht vorsorglich durch aggressive Timeränderungen beseitigt werden.

Windows: TCP-Zustände prüfen

LESEND

Alle TCP-Verbindungen:

Get-NetTCPConnection |
  Sort-Object State, LocalPort

Verbindungen im Zustand SYN-SENT:

Get-NetTCPConnection `
  -State SynSent

Verbindungen im Zustand SYN-RECEIVED:

Get-NetTCPConnection `
  -State SynReceived

Aufgebaute Verbindungen:

Get-NetTCPConnection `
  -State Established

CLOSE-WAIT:

Get-NetTCPConnection `
  -State CloseWait

TIME-WAIT:

Get-NetTCPConnection `
  -State TimeWait

Bestimmten entfernten Port prüfen:

Get-NetTCPConnection `
  -RemotePort 443 |
  Select-Object `
    LocalAddress,
    LocalPort,
    RemoteAddress,
    RemotePort,
    State,
    OwningProcess

Serververbindungen eines lokalen Ports:

Get-NetTCPConnection `
  -LocalPort 443 |
  Select-Object `
    LocalAddress,
    LocalPort,
    RemoteAddress,
    RemotePort,
    State,
    OwningProcess

Kurzlebige Zustände können zwischen zwei Abfragen verschwinden. Eine Paketaufzeichnung ist für die vollständige zeitliche Reihenfolge zuverlässiger.

Windows: Prozess zuordnen

LESEND

Get-NetTCPConnection `
  -RemotePort 443 |
  ForEach-Object {
    $connection = $_
    $process = Get-Process `
      -Id $connection.OwningProcess `
      -ErrorAction SilentlyContinue

    [pscustomobject]@{
      LocalAddress  = $connection.LocalAddress
      LocalPort     = $connection.LocalPort
      RemoteAddress = $connection.RemoteAddress
      RemotePort    = $connection.RemotePort
      State         = $connection.State
      ProcessId     = $connection.OwningProcess
      ProcessName   = $process.ProcessName
    }
  }

Ein Prozess kann zwischen Socketabfrage und Prozessabfrage bereits beendet sein. Fehlende Prozessinformationen müssen deshalb mit Zeitpunkt und Ereignisprotokollen korreliert werden.

Windows: TCP-Verbindung aktiv testen

NETZAKTIV

Test-NetConnection `
  -ComputerName "app.example.test" `
  -Port 443 `
  -InformationLevel Detailed

Wichtige Felder:

TcpTestSucceeded = True bestätigt einen erfolgreichen TCP-Verbindungsaufbau für diesen Versuch. Es bestätigt nicht die Funktion von TLS, HTTP oder der eigentlichen Anwendung.

Getrennte Prüfung einer konkreten Adresse:

Test-NetConnection `
  -ComputerName "192.0.2.25" `
  -Port 443 `
  -InformationLevel Detailed

Windows: TCP-Statistiken prüfen

LESEND

netstat -s -p tcp

IPv6-TCP-Statistiken:

netstat -s -p tcpv6

Verfügbare Leistungsindikatoren suchen:

Get-Counter `
  -ListSet "*TCP*"

Die Namen der Leistungsindikatoren können von Sprache und Windows-Version abhängen.

Zähler müssen über einen definierten Zeitraum als Differenz oder Rate ausgewertet werden. Ein hoher kumulierter Wert seit dem Systemstart beweist keine aktuelle Störung.

Windows: Paketaufzeichnung mit pktmon

pktmon verändert den Aufzeichnungszustand und erstellt Dateien.

SENSITIV · ÄNDERND

Vorhandene Aufzeichnung stoppen:

pktmon stop

Vorhandene Filter entfernen:

pktmon filter remove

Filter für TCP-Port 443 anlegen:

pktmon filter add TCP443 -t TCP -p 443

Aufzeichnung starten:

pktmon start --capture --pkt-size 0 --file-name C:\Temp\tcp443.etl

Nach reproduziertem Fehler stoppen:

pktmon stop

In PCAPNG konvertieren:

pktmon etl2pcap C:\Temp\tcp443.etl --out C:\Temp\tcp443.pcapng

Temporären Filter entfernen:

pktmon filter remove

Voraussetzungen:

Linux: TCP-Zustände mit ss prüfen

LESEND

Alle TCP-Sockets:

ss -tan

TCP-Sockets mit Prozessinformationen:

sudo ss -tanp

SYN-SENT:

ss -tan state syn-sent

SYN-RECEIVED:

ss -tan state syn-recv

Aufgebaute Verbindungen:

ss -tan state established

CLOSE-WAIT:

ss -tan state close-wait

TIME-WAIT:

ss -tan state time-wait

Erweiterte TCP-Informationen für Zielport 443:

sudo ss -tin \
  'dport = :443'

Erweiterte Informationen für einen lokalen Serverport:

sudo ss -tin \
  'sport = :443'

Je nach Zustand und Kernel können erweiterte Angaben enthalten sein:

Die konkrete Ausgabe hängt von Kernel und TCP-Zustand ab.

Linux: TCP-Zähler prüfen

LESEND

nstat -az

Bestimmte Zähler:

nstat -az TcpRetransSegs

nstat -az TcpAttemptFails

nstat -az TcpEstabResets

Zusätzliche klassische Statistik:

netstat -s

Zu beachten:

macOS: TCP-Zustände prüfen

LESEND

netstat -anv -p tcp

TCP-Verbindungen mit Prozesszuordnung:

sudo lsof -nP -iTCP

Aufgebaute TCP-Verbindungen:

sudo lsof \
  -nP \
  -iTCP \
  -sTCP:ESTABLISHED

Interaktive TCP-Ansicht:

nettop -m tcp

TCP-Statistiken:

netstat -s -p tcp

Kurzlebige Handshakezustände können auch unter macOS leichter mit einer Paketaufzeichnung als mit wiederholten Socketabfragen erfasst werden.

Aktive Tests unter Linux und macOS

TCP-Porttest:

NETZAKTIV

nc -vz app.example.test 443

Linux mit begrenzter Wartezeit, abhängig von der installierten nc-Variante:

nc -vz -w 5 app.example.test 443

macOS mit TCP-Verbindungsfrist:

nc -vz -G 5 app.example.test 443

HTTP- oder HTTPS-Test mit getrennten Fristen:

curl \
  --connect-timeout 5 \
  --max-time 15 \
  -v \
  https://app.example.test/

Bedeutung:

Ein Fehler nach erfolgreicher Connected-Meldung ist kein reiner TCP-Connect-Fehler mehr.

Paketaufzeichnung unter Linux

SENSITIV · LESEND

Auf Port 443 begrenzen:

sudo tcpdump \
  -ni any \
  'tcp port 443' \
  -c 200

Auf einen Host und Port begrenzen:

sudo tcpdump \
  -ni any \
  'host 192.0.2.25 and tcp port 443' \
  -c 200

Mit ausführlicheren TCP-Informationen in Datei schreiben:

sudo tcpdump \
  -ni any \
  -s 0 \
  -w /tmp/tcp443.pcap \
  'host 192.0.2.25 and tcp port 443'

Nach reproduziertem Fehler mit Strg+C beenden.

Die Datei enthält möglicherweise sensible Daten und muss anschließend geschützt ausgewertet und kontrolliert entfernt werden.

Paketaufzeichnung unter macOS

Verwendbare Schnittstellen anzeigen:

tcpdump -D

Auf einer konkreten Schnittstelle:

sudo tcpdump \
  -ni en0 \
  'host 192.0.2.25 and tcp port 443' \
  -c 200

Lokale Loopback-Verbindung:

sudo tcpdump \
  -ni lo0 \
  'tcp port 8080' \
  -c 200

In Datei schreiben:

sudo tcpdump \
  -ni en0 \
  -s 0 \
  -w /tmp/tcp443.pcap \
  'host 192.0.2.25 and tcp port 443'

Wireshark-Filter für TCP

Bestimmter Port:

tcp.port == 443

Bestimmte IP-Adresse und Port:

ip.addr == 192.0.2.25 && tcp.port == 443

Nur initiale SYN-Segmente:

tcp.flags.syn == 1 && tcp.flags.ack == 0

SYN/ACK:

tcp.flags.syn == 1 && tcp.flags.ack == 1

Reset:

tcp.flags.reset == 1

FIN:

tcp.flags.fin == 1

Vermutete Wiederholungen:

tcp.analysis.retransmission

Vermuteter Fast Retransmit:

tcp.analysis.fast_retransmission

Duplicate ACKs:

tcp.analysis.duplicate_ack

Zero Window:

tcp.analysis.zero_window

Ein bestimmter TCP-Datenstrom:

tcp.stream == 7

Die Nummer des TCP-Streams wird von Wireshark innerhalb der geöffneten Aufzeichnung vergeben und ist keine übertragene Protokollnummer.

Aufzeichnung richtig planen

Vor Beginn sind festzulegen:

Client:
<Hostname und IP-Adresse>

Server:
<Hostname und IP-Adresse>

Port:
<TCP-Port>

Zeitfenster:
<Start und Ende>

Testhandlung:
<genau ein reproduzierbarer Versuch>

Aufzeichnungspunkte:
<Client, Server und gegebenenfalls Zwischenkomponente>

Erwartete Paketfolge:
<SYN, SYN/ACK, ACK und Anwendungsdaten>

Fehlerkriterium:
<Timeout, RST, FIN oder fehlende Antwort>

Die Systemzeiten der beteiligten Geräte müssen ausreichend synchron sein. Anderenfalls können Client-, Server-, Firewall- und Proxyprotokolle nicht zuverlässig korreliert werden.

Aufzeichnung am Client und Server vergleichen

Clientaufzeichnung Serveraufzeichnung Mögliche Einordnung
SYN sichtbar SYN nicht sichtbar Fehler vor dem Server
SYN sichtbar SYN sichtbar Hinweg funktioniert
kein SYN/ACK am Client SYN/ACK verlässt Server Rückweg oder Filterung
RST am Client RST verlässt Server Server oder Serveranwendung wahrscheinlich beteiligt
RST am Client kein RST am Server Zwischenkomponente wahrscheinlich beteiligt
Daten am Client gesendet Daten erreichen Server Hinweg der Daten funktioniert
ACK fehlt am Client ACK verlässt Server Rückwegproblem
Server erhält ACK nicht Client sendet ACK Filterung oder asymmetrischer Pfad
FIN auf beiden Seiten FIN verlässt ursprünglichen Sender kontrollierter Abbau
unterschiedliche Paketfolgen Übersetzung oder Verlust NAT, Proxy, Capturepunkt oder Netzwerkpfad prüfen

NAT, Firewall, Proxy und Load Balancer berücksichtigen

Eine Ende-zu-Ende-Verbindung kann tatsächlich aus mehreren getrennten TCP-Verbindungen bestehen.

Beispiel mit Reverse Proxy:

Client
→ TCP-Verbindung 1
→ Reverse Proxy
→ TCP-Verbindung 2
→ Backend

Ein Reset zwischen Proxy und Backend muss nicht als Reset zwischen Proxy und Client weitergegeben werden. Der Proxy kann stattdessen eine HTTP-Fehlerantwort erzeugen.

Beispiel mit NAT:

Client intern:        192.0.2.100:53124
NAT extern:           203.0.113.10:62000
Server:               198.51.100.25:443

Zu prüfen sind:

Container und Kubernetes berücksichtigen

Eine TCP-Verbindung kann durch mehrere Netzwerk-Namespaces laufen:

Client
→ Hostport
→ Container-Netzwerk
→ Containersocket

oder:

Client
→ Load Balancer
→ Kubernetes-Service
→ Pod-IP
→ Anwendungscontainer

Zu prüfen sind:

Ein erfolgreicher Handshake zum Load Balancer beweist keinen erfolgreichen Handshake zum Backend.

Typische Fehlermeldungen einordnen

Meldung Mögliche TCP-Einordnung
Connection refused häufig Reset als Antwort auf SYN
Connection timed out Handshake oder Datenübertragung ohne rechtzeitige Antwort
Connection reset by peer gültiger Reset wurde empfangen
Broken pipe Schreiben auf bereits geschlossene Verbindung
EOF Gegenstelle hat den Datenstrom beendet
Operation timed out Frist der Anwendung oder Bibliothek abgelaufen
No route to host Routing- oder lokal gemeldeter Erreichbarkeitsfehler
Network is unreachable keine verwendbare Route
TLS handshake timeout TCP möglicherweise erfolgreich, TLS nicht abgeschlossen
Read timed out Verbindung steht, erwartete Daten fehlen
Write timed out Daten konnten nicht innerhalb der Frist geschrieben werden

Der genaue Wortlaut hängt von Betriebssystem, Programmiersprache, Bibliothek und Anwendung ab.

Hypothese und Gegenbeweis

Beispiel für einen Connect-Timeout:

Hypothese:
Eine Netzwerkfirewall verwirft die SYN-Pakete zum TCP-Port 443.

Erwarteter Befund:
Der Client sendet wiederholt SYN-Pakete.
Der Server empfängt diese SYN-Pakete nicht.
Es wird weder SYN/ACK noch RST empfangen.

Gegenbeweis:
Die Serveraufzeichnung zeigt das eingehende SYN und ein ausgehendes SYN/ACK.

Testmethode:
Zeitgleich begrenzte Paketaufzeichnung auf Client und Server.

Erfolgskriterium:
Der genaue Punkt des Paketverlusts ist eingegrenzt.

Risiko:
Die Aufzeichnung enthält interne Verbindungsdaten und muss geschützt werden.

Beispiel für einen Reset:

Hypothese:
Der Reverse Proxy erzeugt den Reset, weil kein Backend verfügbar ist.

Erwarteter Befund:
Der Client-Handschlag mit dem Proxy ist erfolgreich.
Der Proxy kann keine Verbindung zum Backend aufbauen.
Der Client empfängt anschließend einen Reset.
Das Backend empfängt keinen Verbindungsversuch oder lehnt ihn ab.

Gegenbeweis:
Der Backend-Handschlag ist erfolgreich und der Reset verlässt nachweislich
das Backend.

Testmethode:
Aufzeichnungen und Protokolle an Client, Proxy und Backend korrelieren.

Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko
Listener starten oder Bindung korrigieren Reset wegen fehlendem Listener bestätigt geänderte Erreichbarkeit
Firewallregel korrigieren Paketverlust an der Firewall nachgewiesen unbeabsichtigte Freigabe
Rückweg korrigieren asymmetrischer oder fehlender Rückweg bestätigt weitere Netze können betroffen sein
NAT-Zuordnung korrigieren falsche Übersetzung bestätigt bestehende Sitzungen werden beeinflusst
Proxy-Backend korrigieren fehlerhafter Backendpfad nachgewiesen produktiver Datenverkehr wird umgeleitet
Idle-Timeout abstimmen Sitzungsablauf nach Inaktivität bestätigt mehr Sitzungszustand und Ressourcenverbrauch
Connection-Pool-Lebensdauer anpassen Wiederverwendung veralteter Verbindungen bestätigt mehr neue Verbindungen
Anwendungs-Timeout anpassen Verarbeitung dauert legitim länger und Ursache ist bekannt Fehler werden eventuell später erkannt
TCP-Keepalive gezielt konfigurieren verwaiste Idle-Verbindungen bestätigt zusätzlicher Netzwerkverkehr
Anwendung korrigieren CLOSE-WAIT, abortives Schließen oder Absturz bestätigt Dienstneustart oder Deployment erforderlich
Backendkapazität erhöhen Ressourcenengpass nachgewiesen Kosten und Betriebsänderung
Protokoll oder Zielport korrigieren falsches Protokoll beziehungsweise falscher Port bestätigt Clientkonfiguration ändert sich

Timeouts dürfen nicht pauschal verlängert werden, um Paketverlust, Deadlocks oder überlastete Backends zu verdecken.

Systematischer Diagnoseablauf

  1. Exakte Anwendungsmeldung aufnehmen.
  2. Datum, Uhrzeit und Zeitzone dokumentieren.
  3. Client, Server, Zielname und Zielport bestimmen.
  4. Verwendete IP-Adresse und Adressfamilie erfassen.
  5. Transportprotokoll bestätigen.
  6. Erwarteten Listener auf dem Server prüfen.
  7. Besitzenden Prozess bestimmen.
  8. Lokalen TCP-Test am Server durchführen.
  9. TCP-Test vom betroffenen Client durchführen.
  10. Socketzustand während des Versuchs beobachten.
  11. Prüfen, ob ein SYN erzeugt wird.
  12. Prüfen, ob der Server das SYN empfängt.
  13. Prüfen, ob SYN/ACK oder RST zurückgesendet wird.
  14. Prüfen, ob das abschließende ACK ankommt.
  15. Bei erfolgreichem Handshake Anwendungsdaten prüfen.
  16. Connect- und Anwendungs-Timeout unterscheiden.
  17. FIN und RST unterscheiden.
  18. Reset-Richtung und Reset-Zeitpunkt bestimmen.
  19. Client-, Server- und Zwischenprotokolle korrelieren.
  20. Retransmissions und Duplicate ACKs auswerten.
  21. Captureverlust und Offloading berücksichtigen.
  22. NAT-, Firewall- und Proxyzustand prüfen.
  23. Load Balancer und Backendverbindung getrennt prüfen.
  24. Container- und Netzwerk-Namespace berücksichtigen.
  25. Idle-Phase und Timeoutwerte dokumentieren.
  26. Frische und wiederverwendete Verbindung vergleichen.
  27. Hypothese und Gegenbeweis formulieren.
  28. Genau eine kontrollierte Maßnahme durchführen.
  29. Identischen Verbindungsversuch wiederholen.
  30. Anwendungsprotokoll vollständig verifizieren.
  31. Weitere repräsentative Clients prüfen.
  32. Temporäre Filter und Aufzeichnungen entfernen.
  33. Ursache, Maßnahme und Prävention dokumentieren.

Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
kein SYN sichtbar Anwendung, DNS oder lokaler Socketaufruf Anwendungstrace und Zieladresse
SYN wiederholt, keine Antwort Drop, Routing oder Rückweg serverseitige Aufzeichnung
SYN erreicht Server nicht Netzpfad vor dem Server Zwischenpunkte und Firewalllogs
SYN erreicht Server, kein SYN/ACK lokaler Filter, kein Listener oder Überlastung Socketliste und Servertrace
SYN wird mit RST beantwortet aktive Ablehnung Reset-Erzeuger und Listener prüfen
SYN/ACK verlässt Server, erreicht Client nicht Rückweg oder Filterung Client- und Firewallaufzeichnung
SYN/ACK wird wiederholt abschließendes ACK fehlt Clientaufzeichnung
Handshake vollständig TCP-Connect funktioniert Anwendungsprotokoll prüfen
Handshake vollständig, keine Nutzdaten Anwendung wartet oder startet Anfrage nicht Anwendungstrace
Anfrage gesendet, keine Antwort Backend oder Anwendung langsam Server- und Backendprotokolle
RST direkt nach Handshake Anwendung oder Zwischenkomponente lehnt ab Reset-Sender und Logs
RST nach Anfrage Protokoll-, Anwendungs- oder Sicherheitsfehler Daten vor dem Reset auswerten
RST nach langer Inaktivität Idle-Timeout oder veralteter Socket Timeoutwerte und frische Verbindung
FIN nach Anfrage kontrollierte Schließung Anwendungsergebnis prüfen
viele CLOSE-WAIT lokale Anwendung schließt nicht Prozess- und Threadanalyse
viele TIME-WAIT viele kurzlebige Verbindungen Verbindungsrate und Pooling
viele SYN-SENT Ziele antworten nicht Ziel- und Pfadvergleich
viele SYN-RECEIVED Handshake bleibt unvollständig Serverwarteschlange und Clientpfad
Retransmissions nur in einer Capturedatei Captureverlust oder Offloading möglich zweiter Aufzeichnungspunkt
frische Verbindung funktioniert alte Verbindung fehlerhaft Idle- und Poolingverhalten
Porttest funktioniert, TLS scheitert TCP funktioniert, TLS fehlerhaft TLS-Handshake analysieren
nur große Übertragung stockt Verlust, Window oder MTU möglich Folgeseite zu Retransmissions und MTU
nur ein Backend erzeugt Resets Backend- oder Pfadproblem direkte Backendtests
Reset am Client, nicht am Server Zwischenkomponente wahrscheinlich Firewall-, Proxy- und LB-Protokolle

Typische Diagnosefehler

Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Ein einzelner erfolgreicher Three-Way Handshake ist keine vollständige Verifikation der Anwendung.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Zeitpunkt:
<Datum, Uhrzeit und Zeitzone>

Client:
<Hostname und IP-Adresse>

Server:
<Hostname und IP-Adresse>

Zielname:
<FQDN>

Zielport:
<TCP-Port>

Adressfamilie:
<IPv4 oder IPv6>

Anwendung:
<Client- und Serveranwendung>

Exakte Fehlermeldung:
<Wortlaut>

Verwendete Quelladresse:
<Adresse und Port>

Verwendete Zieladresse:
<Adresse und Port>

Listener:
<Adresse, Port, Prozess und PID>

Handshake-Befund:
<SYN, SYN/ACK, ACK, RST oder fehlende Antwort>

Socketzustände:
<SYN-SENT, SYN-RECEIVED, ESTABLISHED und weitere>

Anwendungsdaten:
<gesendet, empfangen oder nicht sichtbar>

Timeoutart:
<DNS, Connect, TCP, TLS, Anwendung, Proxy oder Idle>

Timeoutdauer:
<gemessene Dauer>

Reset-Absender:
<nachgewiesener oder vermuteter Erzeuger>

Nachweis des Reset-Absenders:
<Client-, Server- und Zwischenaufzeichnung>

Retransmissions:
<Anzahl und Richtung>

FIN-Befund:
<kontrollierter Abbau oder fehlendes FIN>

Zwischenkomponenten:
<Firewall, NAT, Proxy, Load Balancer oder Service Mesh>

Nachgewiesene Ursache:
<technischer Befund>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

Durchgeführte Maßnahme:
<genau eine kontrollierte Änderung>

Risiko und Rückweg:
<Beschreibung>

Verifikation:
<Handshake, Anwendungstest und weitere Systeme>

Prävention:
<Monitoring oder Konfigurationsverbesserung>

Checkliste

Schnellreferenz

Aufgabe Befehl oder Filter
Windows-TCP-Verbindungen Get-NetTCPConnection
Windows SYN-SENT Get-NetTCPConnection -State SynSent
Windows SYN-RECEIVED Get-NetTCPConnection -State SynReceived
Windows ESTABLISHED Get-NetTCPConnection -State Established
Windows CLOSE-WAIT Get-NetTCPConnection -State CloseWait
Windows TIME-WAIT Get-NetTCPConnection -State TimeWait
Windows-TCP-Test Test-NetConnection -ComputerName <Ziel> -Port <Port> -InformationLevel Detailed
Windows-TCP-Statistik netstat -s -p tcp
Windows-Paketmonitor pktmon
Linux-TCP-Sockets ss -tan
Linux-TCP-Details sudo ss -tin
Linux SYN-SENT ss -tan state syn-sent
Linux SYN-RECEIVED ss -tan state syn-recv
Linux ESTABLISHED ss -tan state established
Linux CLOSE-WAIT ss -tan state close-wait
Linux TIME-WAIT ss -tan state time-wait
Linux-TCP-Zähler nstat -az
macOS-TCP-Sockets netstat -anv -p tcp
macOS-Prozesszuordnung sudo lsof -nP -iTCP
macOS-Liveansicht nettop -m tcp
TCP-Porttest nc -vz <Ziel> <Port>
HTTP-/HTTPS-Test curl --connect-timeout 5 --max-time 15 -v <URL>
Linux-Aufzeichnung sudo tcpdump -ni any 'tcp port <Port>' -c 200
macOS-Aufzeichnung sudo tcpdump -ni <Schnittstelle> 'tcp port <Port>' -c 200
Wireshark: Port tcp.port == <Port>
Wireshark: initiales SYN tcp.flags.syn == 1 && tcp.flags.ack == 0
Wireshark: SYN/ACK tcp.flags.syn == 1 && tcp.flags.ack == 1
Wireshark: Reset tcp.flags.reset == 1
Wireshark: FIN tcp.flags.fin == 1
Wireshark: Retransmission tcp.analysis.retransmission
Wireshark: Fast Retransmit tcp.analysis.fast_retransmission
Wireshark: Duplicate ACK tcp.analysis.duplicate_ack
Wireshark: TCP-Stream tcp.stream == <Nummer>

Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen

Stop-Process
taskkill
Stop-Service
Restart-Service
netsh int ip reset
netsh winsock reset
Set-NetFirewallRule
New-NetFirewallRule
Deaktivieren der Windows-Firewall
kill
kill -9
systemctl stop
systemctl restart
sysctl -w
iptables
nft
ufw disable
firewall-cmd --permanent
docker restart
docker stop
kubectl delete
kubectl rollout restart
pauschales Erhöhen aller Timeouts
aggressives Verkürzen von TIME-WAIT
unkontrolliertes Aktivieren oder Ändern von TCP Keepalive
Deaktivieren von TCP-Offloading ohne Vergleichstest
Neustart von Firewall, Proxy oder Load Balancer

Ein Neustart kann TCP-Zustände, Sessiontabellen und den für die Diagnose wichtigen Ausgangszustand zerstören.

Quellen

Standards

Offizielle Microsoft-Dokumentation

Offizielle Linux-Dokumentation

Offizielle Wireshark-Dokumentation

Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet.

9. TCP, UDP, Ports, Firewall, NAT und Proxy

9.3 UDP-Diagnose und ICMP-Fehlermeldungen

Ziel dieser Seite

Diese Seite beschreibt die systematische Diagnose von UDP-Kommunikation und zugehörigen ICMP- beziehungsweise ICMPv6-Fehlermeldungen.

Nach der Bearbeitung muss unterschieden werden können:

UDP besitzt keinen Handshake und keine integrierte Empfangsbestätigung. Ein erfolgreich abgesendetes Datagramm beweist deshalb nicht, dass es den Zielhost oder die Zielanwendung erreicht hat.

Sicherheits- und Wirkungsklassen

Kennzeichnung Bedeutung
LESEND Erfasst ausschließlich vorhandene Zustände.
NETZAKTIV Erzeugt Netzwerkverkehr zum geprüften Ziel.
SENSITIV Kann interne Adressen, Verbindungen oder Nutzdaten sichtbar machen.
ÄNDERND Verändert Konfiguration oder Laufzeitzustand.
AUSFALLRISIKO Kann Verbindungen, Dienste oder Netzwerkkomponenten beeinträchtigen.

UDP-Dienste dürfen nur mit gültigen, erwarteten und autorisierten Anfragen getestet werden. Unkontrollierte oder sehr schnelle UDP-Anfragen können:

Grundlegende Eigenschaften von UDP

UDP ist ein minimales, nachrichtenorientiertes Transportprotokoll.

UDP bietet:

UDP bietet selbst nicht:

Eine Anwendung oder ein über UDP betriebenes Protokoll kann solche Funktionen selbst implementieren. Beispiele sind:

TCP und UDP vergleichen

Merkmal TCP UDP
Verbindungsaufbau Three-Way Handshake kein Handshake
Datenmodell Bytestrom einzelne Datagramme
Bestätigung TCP-ACK nicht in UDP enthalten
Reihenfolge durch TCP sichergestellt nicht sichergestellt
Wiederholung durch TCP nur durch Anwendung
Flusskontrolle vorhanden nicht vorhanden
Überlastkontrolle vorhanden nicht in UDP selbst
Verbindungszustände unter anderem LISTEN, ESTABLISHED keine entsprechenden TCP-Zustände
Reaktion bei geschlossenem Port normalerweise TCP Reset möglicherweise ICMP Port Unreachable
Porttest TCP-Handshake liefert klares Ergebnis ohne Protokollantwort häufig mehrdeutig

Ein Test von TCP-Port 53 beweist nicht, dass UDP-Port 53 funktioniert. Umgekehrt beweist eine erfolgreiche UDP-DNS-Abfrage nicht automatisch, dass DNS über TCP funktioniert.

UDP-Header

Der UDP-Header besitzt vier Felder:

Quellport
Zielport
Länge
Prüfsumme

Die Mindestlänge eines UDP-Datagramms beträgt acht Byte, weil der UDP-Header selbst acht Byte groß ist.

Feld Größe Bedeutung
Source Port 16 Bit Port des Senders
Destination Port 16 Bit Port des Empfängers
Length 16 Bit Gesamtlänge von UDP-Header und UDP-Nutzdaten
Checksum 16 Bit Prüfsumme über relevante IP-, UDP- und Nutzdatenfelder

UDP enthält keine Felder für:

Bei IPv4 kann eine UDP-Prüfsumme gemäß der ursprünglichen UDP-Spezifikation als nicht verwendet gekennzeichnet sein. Bei IPv6 ist eine gültige UDP-Prüfsumme grundsätzlich erforderlich; nur eng definierte Sonderfälle besitzen Ausnahmen.

UDP-Kommunikation eindeutig bestimmen

Ein UDP-Datagramm wird durch folgende Angaben eingeordnet:

Quell-IP-Adresse
Quellport
Ziel-IP-Adresse
Zielport
Transportprotokoll UDP

Beispiel:

Client: 192.0.2.100:53124
Server: 192.0.2.53:53

Anfrage:

192.0.2.100:53124 → 192.0.2.53:53 UDP

Antwort:

192.0.2.53:53 → 192.0.2.100:53124 UDP

Eine Stateful Firewall oder NAT-Instanz kann diese Angaben verwenden, um einen zeitlich begrenzten Pseudo-Sitzungszustand zu verwalten. UDP selbst erzeugt diesen Zustand nicht.

UDP besitzt keinen Listenerzustand wie TCP

Werkzeuge sprechen bei UDP teilweise trotzdem von „Listening“, weil ein Prozess einen UDP-Endpunkt gebunden hat.

Technisch bedeutet der Befund:

Ein UDP-Socket ist an eine lokale Adresse und einen lokalen Port gebunden.

Der Befund beweist nicht:

Verbundener UDP-Socket

Eine Anwendung kann einen UDP-Socket mit einer Gegenstelle „verbinden“.

Dieser Vorgang führt nicht zu einem Netzwerk-Handshake. Das Betriebssystem kann dadurch lediglich:

Ein als verbunden dargestellter UDP-Socket beweist deshalb keine erreichbare Gegenstelle.

Was ein erfolgreicher send-Aufruf beweist

Wenn eine Anwendung ein UDP-Datagramm erfolgreich an das Betriebssystem übergibt, bedeutet das zunächst:

Der lokale Netzwerkstack hat das Datagramm zur Übertragung angenommen.

Es beweist nicht:

Für einen belastbaren Nachweis sind Protokollantwort, Serverprotokoll oder korrelierte Paketaufzeichnung notwendig.

Erwarteten UDP-Ablauf festlegen

Vor der Diagnose müssen mindestens folgende Angaben dokumentiert werden:

Anwendung:
<Dienst oder Protokoll>

Quellhost:
<Hostname und IP-Adresse>

Zielhost:
<Hostname und IP-Adresse>

Quellport:
<fest oder dynamisch>

Zielport:
<UDP-Port>

Adressfamilie:
<IPv4 oder IPv6>

Anfrage:
<erwartete gültige Protokollnachricht>

Erwartete Antwort:
<Antworttyp oder bewusst keine Antwort>

Timeout:
<Anwendungsfrist>

Kommunikationsart:
<Unicast, Broadcast oder Multicast>

Zwischenkomponenten:
<Firewall, NAT, Load Balancer, Proxy oder Tunnel>

Bei einem Protokoll ohne Antwort muss der Nachweis auf der Empfängerseite erfolgen.

UDP-Diagnose benötigt ein protokollspezifisches Werkzeug

Ein allgemeiner UDP-Test kann häufig nur ein Datagramm senden. Er kann nicht sicher bestimmen, ob ein beliebiger UDP-Dienst korrekt arbeitet.

Geeignete Tests sind beispielsweise:

Protokoll Geeigneter Nachweis
DNS gültige DNS-Abfrage mit Resolve-DnsName oder dig
NTP gültige Zeitabfrage mit vorgesehenem NTP-Werkzeug
SNMP gültige, autorisierte SNMP-Abfrage
TFTP kontrollierter TFTP-Protokolltest
Syslog Empfang im vorgesehenen Logziel bestätigen
RADIUS autorisierter Test mit passendem RADIUS-Werkzeug
QUIC/HTTP/3 HTTP/3-fähiger Client und Serverprotokolle
anwendungsspezifisches UDP Herstellerclient, Testfunktion oder definierte Testnachricht

Ein zufälliges oder leeres Datagramm kann von einem korrekt funktionierenden Dienst absichtlich ignoriert werden.

DNS als UDP-Diagnosebeispiel

Windows:

NETZAKTIV

Resolve-DnsName `
  -Name "example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

Linux und macOS:

dig \
  @192.0.2.53 \
  example.test \
  A

Vergleich über TCP:

dig \
  @192.0.2.53 \
  example.test \
  A \
  +tcp

Auswertung:

UDP TCP Mögliche Einordnung
funktioniert funktioniert beide Transportwege grundsätzlich nutzbar
fehlerhaft funktioniert UDP-Filterung, Fragmentierung, EDNS oder MTU möglich
funktioniert fehlerhaft TCP-Port, Firewall oder TCP-Listener prüfen
beide fehlerhaft beide Pfade oder DNS-Dienst betroffen Server, Zone, Routing und Firewall prüfen

Der Vergleich ist protokollspezifisch. Er darf nicht auf beliebige UDP-Dienste übertragen werden.

Allgemeine UDP-Porttests richtig bewerten

Ein Aufruf wie:

nc -vzu 192.0.2.53 53

liefert bei UDP keinen gleichwertigen Nachweis wie ein erfolgreicher TCP-Handshake.

Mögliche Ergebnisse ohne Antwort:

nc -u darf deshalb nur zum gezielten Erzeugen eines autorisierten Datagramms verwendet werden. Für die Funktionsprüfung ist ein protokollspezifischer Test erforderlich.

Windows: UDP-Endpunkte erfassen

LESEND

Alle UDP-Endpunkte:

Get-NetUDPEndpoint |
  Sort-Object LocalPort, LocalAddress

Bestimmten UDP-Port prüfen:

Get-NetUDPEndpoint `
  -LocalPort 53

Wesentliche Felder anzeigen:

Get-NetUDPEndpoint |
  Select-Object `
    LocalAddress,
    LocalPort,
    OwningProcess |
  Sort-Object LocalPort, LocalAddress

Zu prüfen sind:

Windows: Prozess eines UDP-Endpunkts bestimmen

LESEND

Get-NetUDPEndpoint `
  -LocalPort 53 |
  ForEach-Object {
    $endpoint = $_
    $process = Get-Process `
      -Id $endpoint.OwningProcess `
      -ErrorAction SilentlyContinue

    [pscustomobject]@{
      LocalAddress = $endpoint.LocalAddress
      LocalPort    = $endpoint.LocalPort
      ProcessId    = $endpoint.OwningProcess
      ProcessName  = $process.ProcessName
      ProcessPath  = $process.Path
    }
  }

Einen bekannten Prozess prüfen:

Get-Process `
  -Id 1234

Einem Windows-Dienst zuordnen:

$processId = 1234

Get-CimInstance `
  -ClassName Win32_Service `
  -Filter "ProcessId = $processId" |
  Select-Object `
    Name,
    DisplayName,
    State,
    StartMode,
    ProcessId,
    PathName

Windows: UDP mit netstat prüfen

LESEND

netstat -ano -p udp

Die Ausgabe zeigt unter anderem:

UDP besitzt dabei keinen TCP-Zustand wie LISTENING oder ESTABLISHED.

Numerische Darstellung ist für die erste Diagnose vorzuziehen, damit keine Namensauflösung die Ausgabe verändert oder verzögert.

Windows: UDP-Statistiken prüfen

LESEND

IPv4:

netstat -s -p udp

IPv6:

netstat -s -p udpv6

Verfügbare Leistungsindikatoren:

Get-Counter `
  -ListSet "*UDP*"

Die Namen der Leistungsindikatoren können abhängig von Systemsprache und Windows-Version abweichen.

Kumulative Zähler müssen über ein definiertes Zeitfenster verglichen werden. Ein hoher Gesamtwert seit dem Systemstart beweist keine aktuelle Störung.

Windows: Test-NetConnection ist kein UDP-Porttest

Dieser Befehl:

Test-NetConnection `
  -ComputerName "192.0.2.53" `
  -Port 53

prüft TCP-Port 53.

Er prüft nicht UDP-Port 53.

Folgende Schlussfolgerung ist daher unzulässig:

TcpTestSucceeded = True
also funktioniert UDP-Port 53.

Für UDP muss ein passendes Anwendungsprotokoll verwendet oder der Datenweg mit einer Paketaufzeichnung nachgewiesen werden.

Windows: UDP-Test mit PortQry

PortQry ist ein separat bereitzustellendes Microsoft-Diagnosewerkzeug und nicht auf jedem Windows-System vorinstalliert.

NETZAKTIV

portqry.exe -n 192.0.2.53 -p UDP -e 53

Mögliche Einordnung:

PortQry-Ergebnis Bedeutung
LISTENING PortQry hat eine verwertbare Protokollantwort erhalten.
NOT LISTENING PortQry hat typischerweise ICMP Port Unreachable erhalten.
LISTENING OR FILTERED Es kam keine eindeutige Antwort; geöffnet und still oder gefiltert sind nicht unterscheidbar.

Für einige bekannte Protokolle sendet PortQry speziell formatierte Anfragen. Bei beliebigen UDP-Diensten bleibt ein fehlendes Ergebnis mehrdeutig.

PortQry darf nur gegen autorisierte Zielsysteme eingesetzt werden.

Linux: UDP-Endpunkte mit ss prüfen

LESEND

Gebundene UDP-Endpunkte:

sudo ss -lunp

Alle UDP-Sockets:

sudo ss -uanp

Bestimmten lokalen Port prüfen:

sudo ss -lunp \
  'sport = :53'

Ausgabe ohne Prozessinformationen:

ss -lun

Wichtige Felder:

Prozessinformationen können erhöhte Berechtigungen erfordern.

Linux: Prozess mit lsof bestimmen

LESEND

Alle UDP-Sockets:

sudo lsof \
  -nP \
  -iUDP

Bestimmten UDP-Port prüfen:

sudo lsof \
  -nP \
  -iUDP:53

Prozess prüfen:

ps -fp <PID>

Bei systemd:

systemctl status <Dienstname>

Ein laufender Dienst beweist nicht, dass er den erwarteten UDP-Port im richtigen Netzwerk-Namespace gebunden hat.

Linux: UDP-Zähler prüfen

LESEND

Alle Netzwerkstatistiken:

nstat -az

Ausgewählte UDP-Zähler:

nstat -az UdpInDatagrams

nstat -az UdpNoPorts

nstat -az UdpInErrors

nstat -az UdpRcvbufErrors

nstat -az UdpSndbufErrors

Klassische Übersicht:

netstat -su

Schnittstellenzähler:

ip -s link

Mögliche Hinweise:

Zähler Mögliche Einordnung
UdpInDatagrams empfangene und zugestellte UDP-Datagramme
UdpNoPorts Datagramme für nicht belegte UDP-Ports
UdpInErrors allgemeine UDP-Empfangsfehler
UdpRcvbufErrors Empfangspuffer konnte Datagramme nicht aufnehmen
UdpSndbufErrors Sendepufferfehler
Schnittstellen-Drops Verlust an oder nahe der Netzwerkschnittstelle

Die genaue Zählerverfügbarkeit hängt von Kernel und Werkzeugversion ab.

macOS: UDP-Endpunkte prüfen

LESEND

sudo lsof \
  -nP \
  -iUDP

Bestimmten UDP-Port prüfen:

sudo lsof \
  -nP \
  -iUDP:53

Socketübersicht:

netstat -anv -p udp

UDP-Statistiken:

netstat -s -p udp

Netzwerkschnittstellen:

ifconfig

Interaktive Netzwerkansicht:

nettop

lsof ist unter macOS für die Zuordnung eines UDP-Ports zu einem Prozess normalerweise geeigneter als netstat.

Empfangswarteschlange und Anwendungsgeschwindigkeit

Ein Datagramm kann den Host erreichen, aber verloren gehen, bevor die Anwendung es verarbeitet.

Mögliche Ursachen:

Benötigte Nachweise:

Wenn ein Datagramm in der Paketaufzeichnung des Servers sichtbar ist, beweist das noch nicht, dass die Anwendung es aus dem Socket gelesen hat.

ICMP ist nicht nur Ping

ICMP dient zur Übertragung von Kontroll- und Fehlermeldungen für IP.

Ping verwendet:

ICMP umfasst jedoch zusätzlich Meldungen wie:

ICMPv4 und ICMPv6 sind nicht identisch. Sie verwenden unterschiedliche Typen, Codes und Protokollmechanismen.

Das vollständige Blockieren von ICMP kann Fehlerdiagnose und Path MTU Discovery beeinträchtigen. Bei IPv6 besitzt ICMPv6 darüber hinaus grundlegende Bedeutung für mehrere IPv6-Funktionen.

ICMP-Fehler einer UDP-Anfrage zuordnen

Eine ICMP-Fehlermeldung enthält Teile des Pakets, das den Fehler ausgelöst hat.

Dadurch können Betriebssystem, Firewall oder Analysewerkzeug die Meldung beispielsweise folgender Kommunikation zuordnen:

192.0.2.100:53124
→ 192.0.2.53:53 UDP

Zu prüfen sind im eingebetteten ursprünglichen Paket:

Bei NAT muss auch die ICMP-Fehlermeldung korrekt zur ursprünglichen internen Kommunikation zurückübersetzt werden.

Häufige ICMPv4-Typen

Typ Bezeichnung Typische Bedeutung
0 Echo Reply Antwort auf Echo Request
3 Destination Unreachable Ziel, Protokoll oder Port nicht erreichbar
5 Redirect Hinweis auf einen anderen nächsten Router
8 Echo Request Ping-Anfrage
11 Time Exceeded TTL abgelaufen oder Fragmentwiederherstellung zu langsam
12 Parameter Problem Fehler in einem IP-Headerfeld

ICMP Source Quench ist veraltet und darf nicht als moderner Überlastkontrollmechanismus verwendet werden.

ICMPv4 Destination Unreachable

ICMPv4 verwendet für Destination Unreachable den Typ 3.

Code Bedeutung
0 Network Unreachable
1 Host Unreachable
2 Protocol Unreachable
3 Port Unreachable
4 Fragmentation Needed and DF Set
5 Source Route Failed
9 Network Administratively Prohibited
10 Host Administratively Prohibited
13 Communication Administratively Prohibited

Nicht jedes Gerät verwendet alle Codes. Firewalls können Fehler außerdem still verwerfen oder andere Meldungen erzeugen.

ICMPv4 Port Unreachable

Typischer Ablauf:

Client → Server:
UDP-Datagramm an Port 9999

Server → Client:
ICMP Destination Unreachable
Type 3, Code 3
Port Unreachable

Mögliche Einordnung:

Der genaue Erzeuger muss anhand von Aufzeichnungen und Protokollen bestimmt werden.

ICMPv4 Fragmentation Needed

Typischer Befund:

ICMP Type 3, Code 4
Fragmentation Needed and DF Set

Bedeutung:

Wenn diese ICMP-Meldung gefiltert wird, kann ein Path-MTU-Black-Hole entstehen:

kleine Datagramme funktionieren
große Datagramme schlagen fehl
keine verwertbare Fehlermeldung erreicht den Sender

ICMPv4 Time Exceeded

ICMPv4 verwendet Typ 11.

Code Bedeutung
0 TTL während der Weiterleitung abgelaufen
1 Zeit für Fragmentwiederherstellung abgelaufen

TTL-Ablauf wird unter anderem von Traceroute verwendet, um Zwischenrouter sichtbar zu machen.

Ein Stern in einer Traceroute-Ausgabe beweist nicht, dass der betreffende Router ausgefallen ist. Er kann ICMP-Antworten filtern oder begrenzen und trotzdem normalen Datenverkehr weiterleiten.

Häufige ICMPv6-Typen

Typ Bezeichnung
1 Destination Unreachable
2 Packet Too Big
3 Time Exceeded
4 Parameter Problem
128 Echo Request
129 Echo Reply

ICMPv6 enthält außerdem wichtige Mechanismen für IPv6. Es darf nicht pauschal wie optionaler Ping-Verkehr behandelt werden.

ICMPv6 Destination Unreachable

ICMPv6 verwendet Typ 1.

Code Bedeutung
0 No Route to Destination
1 Communication Administratively Prohibited
2 Beyond Scope of Source Address
3 Address Unreachable
4 Port Unreachable
5 Source Address Failed Ingress/Egress Policy
6 Reject Route to Destination

Port Unreachable bei IPv6:

ICMPv6 Type 1, Code 4

ICMPv6 Packet Too Big

ICMPv6 verwendet:

Type 2, Code 0

Die Meldung enthält die MTU des nächsten Links.

IPv6-Router fragmentieren weitergeleitete Pakete nicht. Wenn ein Paket zu groß ist, muss der sendende Endpunkt seine Paketgröße anpassen oder selbst geeignete Fragmentierung verwenden.

Das Blockieren von ICMPv6 Packet Too Big kann dazu führen, dass:

ICMPv6 Time Exceeded

ICMPv6 verwendet Typ 3.

Code Bedeutung
0 Hop Limit während der Weiterleitung abgelaufen
1 Fragment Reassembly Time Exceeded

Das IPv6 Hop Limit entspricht funktional dem IPv4-TTL-Konzept.

ICMPv6 Parameter Problem

ICMPv6 verwendet Typ 4.

Code Bedeutung
0 fehlerhaftes Headerfeld
1 unbekannter Next-Header-Typ
2 unbekannte IPv6-Option

Die Meldung kann auf das fehlerhafte Feld innerhalb des ursprünglichen Pakets verweisen.

Keine ICMP-Antwort ist mehrdeutig

Wenn auf ein UDP-Datagramm weder eine Anwendungsantwort noch eine ICMP-Fehlermeldung folgt, sind unter anderem möglich:

Das Ergebnis darf nicht ohne weiteren Nachweis als „Port offen“ oder „Port geschlossen“ dokumentiert werden.

ICMP Rate Limiting berücksichtigen

Hosts und Router können ICMP-Fehlermeldungen begrenzen.

Folgen:

Diagnosetests müssen mit geringer, kontrollierter Rate durchgeführt werden.

ICMP-Fehler müssen nicht die Anwendung erreichen

Ob eine Anwendung einen ICMP-Fehler wahrnimmt, hängt ab von:

Eine Anwendung kann deshalb einen Timeout melden, obwohl in einer Paketaufzeichnung eine ICMP-Fehlermeldung sichtbar ist.

Umgekehrt kann das Betriebssystem einen Socketfehler melden, obwohl die Anwendung selbst keine ICMP-Pakete auswertet.

UDP, MTU und Fragmentierung

Ein UDP-Datagramm bleibt für die Anwendung eine einzelne Nachricht. Auf IP-Ebene kann das zugehörige Paket jedoch fragmentiert werden.

Probleme großer UDP-Datagramme:

Typischer Befund:

kleine Anfrage funktioniert
kleine Antwort funktioniert
große Antwort schlägt fehl
über VPN tritt der Fehler häufiger auf
Paketaufzeichnung zeigt Fragmente oder ICMP Packet Too Big

IP-Fragmentierung sollte nicht vorsorglich erzwungen werden. Die Anwendung muss geeignete Nachrichtengrößen und Path-MTU-Verfahren verwenden.

UDP und Checksummen diagnostizieren

Eine ungültige UDP-Prüfsumme kann dazu führen, dass ein Datagramm ohne Anwendungsantwort verworfen wird.

Zu prüfen sind:

Wie bei TCP kann eine lokal vor der Netzwerkkarte aufgenommene Prüfsumme scheinbar fehlerhaft sein, obwohl sie später durch die Hardware korrekt berechnet wird.

Eine einzelne lokale Anzeige Bad Checksum ist deshalb kein ausreichender Fehlernachweis.

Unicast, Broadcast und Multicast unterscheiden

Kommunikationsart Ziel
Unicast genau ein IP-Endpunkt
Broadcast alle geeigneten IPv4-Teilnehmer eines Broadcastbereichs
Multicast Mitglieder einer Multicastgruppe

Bei Broadcast und Multicast sind zusätzlich zu prüfen:

Ein Dienst kann auf Unicast funktionieren und auf Broadcast oder Multicast dennoch fehlschlagen.

IPv6 verwendet keinen Broadcast. Vergleichbare Aufgaben werden dort durch Multicastmechanismen umgesetzt.

Stateful Firewall und UDP

Eine Stateful Firewall kann für UDP einen temporären Zustand anhand des Datenflusses anlegen.

Beispiel:

Client 192.0.2.100:53124
→ Server 192.0.2.53:53

erwartete Antwort:
Server 192.0.2.53:53
→ Client 192.0.2.100:53124

Zu prüfen sind:

Wenn die Antwort erst nach Ablauf des Firewallzustands eintrifft, kann sie verworfen werden.

NAT und UDP

NAT kann eine interne Kommunikation wie folgt übersetzen:

intern:
192.0.2.100:53124

extern:
203.0.113.10:62000

Ziel:
198.51.100.53:53

Die Antwort muss an die übersetzte Adresse und den übersetzten Port zurückkehren:

198.51.100.53:53
→ 203.0.113.10:62000

Mögliche Fehler:

TCP- und UDP-Portweiterleitungen müssen getrennt konfiguriert werden.

Load Balancer und UDP

Ein UDP-Load-Balancer kann Datagramme anhand des Flows einem Backend zuordnen.

Zu prüfen sind:

Wenn ein Client bei jedem Datagramm einen anderen Quellport verwendet, kann ein Load Balancer unterschiedliche Backends auswählen.

Ein erfolgreicher Health Check beweist nicht automatisch, dass der produktive UDP-Pfad funktioniert.

Docker: UDP-Veröffentlichung prüfen

Docker-Portveröffentlichungen müssen das Transportprotokoll berücksichtigen.

Beispiel:

53:53/udp

Ohne /udp wird eine Veröffentlichung typischerweise als TCP-Veröffentlichung behandelt.

Laufende Container und Ports:

LESEND

docker ps \
  --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

Portzuordnung:

docker port <Containername>

Ausführliche Konfiguration:

docker inspect \
  <Containername> \
  --format '{{json .NetworkSettings.Ports}}'

UDP-Endpunkt im Container:

docker exec \
  <Containername> \
  ss -lunp

Compose-Beispiel:

ports:
  - "53:53/udp"

Zu prüfen sind:

EXPOSE 53/udp im Image veröffentlicht den Port nicht automatisch auf dem Host.

Kubernetes: UDP-Service prüfen

Wenn protocol nicht angegeben wird, verwendet ein Kubernetes-Service standardmäßig TCP. Für UDP muss das Protokoll ausdrücklich passen.

Beispiel:

ports:
  - name: dns-udp
    protocol: UDP
    port: 53
    targetPort: 53

Service anzeigen:

kubectl get service \
  <Servicename> \
  -n <Namespace> \
  -o yaml

Service beschreiben:

kubectl describe service \
  <Servicename> \
  -n <Namespace>

EndpointSlices:

kubectl get endpointslice \
  -n <Namespace> \
  -l kubernetes.io/service-name=<Servicename> \
  -o wide

UDP-Endpunkt im Pod:

kubectl exec \
  -n <Namespace> \
  <Podname> \
  -- ss -lunp

Bei mehreren Containern:

kubectl exec \
  -n <Namespace> \
  <Podname> \
  -c <Containername> \
  -- ss -lunp

Zu prüfen sind:

Ein eingetragener containerPort erzeugt keinen UDP-Endpunkt.

Windows-Paketaufzeichnung mit pktmon

pktmon verändert den Aufzeichnungszustand und erstellt Dateien.

SENSITIV · ÄNDERND

Vorhandene Aufzeichnung stoppen:

pktmon stop

Vorhandene Filter entfernen:

pktmon filter remove

UDP-Port 53 erfassen:

pktmon filter add UDP53 -t UDP -p 53

ICMPv4 ergänzen:

pktmon filter add ICMPv4 -t ICMP

ICMPv6 ergänzen:

pktmon filter add ICMPv6 -t ICMPV6

Aufzeichnung starten:

pktmon start --capture --pkt-size 0 --file-name C:\Temp\udp53.etl

Nach reproduziertem Fehler stoppen:

pktmon stop

In PCAPNG konvertieren:

pktmon etl2pcap C:\Temp\udp53.etl --out C:\Temp\udp53.pcapng

Filter zurücknehmen:

pktmon filter remove

Das Zielverzeichnis muss vorhanden sein. Aufzeichnung, Filter und erzeugte Dateien müssen nach der Diagnose kontrolliert behandelt werden.

Paketaufzeichnung unter Linux

UDP und ICMP gemeinsam:

SENSITIV · LESEND

sudo tcpdump \
  -ni any \
  '(udp port 53) or icmp or icmp6' \
  -c 200

Auf bestimmte Gegenstelle begrenzen:

sudo tcpdump \
  -ni any \
  'host 192.0.2.53 and ((udp port 53) or icmp or icmp6)' \
  -c 200

In Datei schreiben:

sudo tcpdump \
  -ni any \
  -s 0 \
  -w /tmp/udp53.pcap \
  'host 192.0.2.53 and ((udp port 53) or icmp or icmp6)'

Nach reproduziertem Fehler mit Strg+C beenden.

Paketaufzeichnung unter macOS

Verfügbare Schnittstellen:

tcpdump -D

Auf konkreter Schnittstelle:

sudo tcpdump \
  -ni en0 \
  'host 192.0.2.53 and ((udp port 53) or icmp or icmp6)' \
  -c 200

In Datei schreiben:

sudo tcpdump \
  -ni en0 \
  -s 0 \
  -w /tmp/udp53.pcap \
  'host 192.0.2.53 and ((udp port 53) or icmp or icmp6)'

Bei lokalem Verkehr muss gegebenenfalls lo0 statt der physischen Schnittstelle verwendet werden.

Wireshark-Filter für UDP und ICMP

Alle UDP-Pakete:

udp

Bestimmter UDP-Port:

udp.port == 53

Bestimmte Adresse und Port:

ip.addr == 192.0.2.53 && udp.port == 53

ICMPv4:

icmp

ICMPv6:

icmpv6

ICMPv4 Destination Unreachable:

icmp.type == 3

ICMPv4 Port Unreachable:

icmp.type == 3 && icmp.code == 3

ICMPv4 Fragmentation Needed:

icmp.type == 3 && icmp.code == 4

ICMPv4 Time Exceeded:

icmp.type == 11

ICMPv6 Port Unreachable:

icmpv6.type == 1 && icmpv6.code == 4

ICMPv6 Packet Too Big:

icmpv6.type == 2

ICMPv6 Time Exceeded:

icmpv6.type == 3

UDP und beide ICMP-Versionen:

udp || icmp || icmpv6

Eine ICMP-Meldung muss zusammen mit dem darin eingebetteten ursprünglichen Paket ausgewertet werden.

Client- und Serveraufzeichnung vergleichen

Clientaufzeichnung Serveraufzeichnung Mögliche Einordnung
UDP-Anfrage sichtbar Anfrage nicht sichtbar Verlust oder Filterung vor dem Server
Anfrage sichtbar Anfrage sichtbar Hinweg bis zum Aufzeichnungspunkt funktioniert
keine Antwort Anwendung protokolliert Anfrage nicht Socket, lokaler Filter oder Anwendungsverarbeitung
keine Antwort Anwendung protokolliert Anfrage Anwendung erzeugt keine oder verspätete Antwort
Antwort verlässt Server Antwort erreicht Client nicht Rückweg, NAT oder Firewall
ICMP Port Unreachable am Client Server erzeugt ICMP Zielport wahrscheinlich nicht gebunden
ICMP nur am Client sichtbar Server zeigt keine Meldung Zwischenkomponente als Erzeuger möglich
ICMP verlässt Server Client erhält es nicht Rückweg oder ICMP-Filterung
kleine Datagramme funktionieren große erreichen Server nicht MTU, Fragmentierung oder Filterung
Anfrage und Antwort sichtbar Anwendung meldet Timeout Socketzuordnung, Frist oder Anwendungslogik

Typische UDP-Paketfolgen

Erfolgreiche Anfrage mit Antwort

Client → Server  UDP-Anfrage
Server → Client  UDP-Antwort

Geschlossener UDP-Port

Client → Server  UDP-Anfrage
Server → Client  ICMP Port Unreachable

Stilles Verwerfen

Client → Server  UDP-Anfrage
keine Antwort
keine ICMP-Meldung

Server verarbeitet Anfrage nicht

Client → Server  UDP-Anfrage
Anfrage erreicht Serverschnittstelle
keine Anwendungsantwort

Rückwegfehler

Client → Server  UDP-Anfrage
Server → Client  UDP-Antwort
Antwort erreicht Client nicht

Path-MTU-Problem

kleine UDP-Datagramme funktionieren
großes UDP-Datagramm wird verworfen
ICMP Fragmentation Needed oder Packet Too Big

Traceroute und ICMP Time Exceeded

Traceroute nutzt schrittweise erhöhte TTL- beziehungsweise Hop-Limit-Werte. Zwischenrouter können darauf mit ICMP Time Exceeded antworten.

Linux mit UDP-Probes:

NETZAKTIV

traceroute \
  -U \
  -p 33434 \
  192.0.2.53

IPv6:

traceroute \
  -6 \
  2001:db8::53

Die genaue Standardmethode von Traceroute hängt von Betriebssystem und Implementierung ab.

Ein unvollständiger Traceroute beweist keinen vollständigen Pfadausfall. Router können:

Hypothese und Gegenbeweis

Beispiel für einen geschlossenen UDP-Port:

Hypothese:
Auf dem Server ist kein UDP-Endpunkt an Port 9999 gebunden.

Erwarteter Befund:
Die lokale Socketliste zeigt keinen UDP-Endpunkt auf Port 9999.
Die Serveraufzeichnung zeigt die eingehende UDP-Anfrage.
Der Server sendet ICMP Port Unreachable zurück.

Gegenbeweis:
Ein Prozess besitzt UDP-Port 9999 und protokolliert die eingehende Anfrage.

Testmethode:
Socketliste, Prozesszuordnung und korrelierte Paketaufzeichnung.

Risiko:
Die Anfrage erzeugt Netzwerkverkehr und muss dem erwarteten Protokoll entsprechen.

Beispiel für einen Rückwegfehler:

Hypothese:
Die UDP-Antwort verlässt den Server, wird aber durch eine Firewall
auf dem Rückweg verworfen.

Erwarteter Befund:
Die Serveraufzeichnung zeigt die ausgehende Antwort.
Die Clientaufzeichnung zeigt diese Antwort nicht.
Die Firewall protokolliert einen Drop für den Antwortflow.

Gegenbeweis:
Die Clientaufzeichnung zeigt die Antwort vollständig.

Testmethode:
Zeitgleiche Aufzeichnung auf Client und Server sowie Firewallprotokoll.

Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko
UDP-Endpunkt starten oder Bindung korrigieren fehlender Endpunkt bestätigt geänderte Erreichbarkeit
Firewallregel für UDP korrigieren UDP-Drop nachgewiesen unbeabsichtigte Freigabe
ICMP-Regel korrigieren benötigte Fehlermeldung wird nachweislich blockiert zusätzliche Kontrollmeldungen werden zugelassen
NAT-Regel um UDP ergänzen nur TCP oder falsches Protokoll bestätigt öffentliche Erreichbarkeit ändert sich
UDP-Idle-Timeout abstimmen ablaufender Sitzungszustand bestätigt mehr Zustands- und Speicherverbrauch
Antwortquelladresse korrigieren falsche Quelladresse bestätigt Routing und Dienstbindung ändern sich
Datagrammgröße reduzieren MTU- oder Fragmentierungsproblem bestätigt Protokollverhalten oder Leistung ändert sich
Receive Buffer anpassen Pufferüberlauf nachgewiesen höherer Speicherverbrauch
Anwendungsgeschwindigkeit verbessern Empfangsverlust durch Verarbeitung bestätigt Anwendungsänderung erforderlich
Docker-Publish auf /udp korrigieren fehlende UDP-Veröffentlichung bestätigt Container muss eventuell neu erstellt werden
Kubernetes-Service auf UDP korrigieren falsches Serviceprotokoll bestätigt produktiver Servicepfad ändert sich
Multicastmitgliedschaft korrigieren fehlende Gruppenmitgliedschaft bestätigt zusätzlicher Multicastempfang
Rate Limit anpassen legitimer Verkehr wird nachweislich begrenzt Überlastungs- und Missbrauchsrisiko

Vor jeder Änderung sind Ausgangszustand, Risiko, Rückweg und Erfolgskriterium zu dokumentieren.

Systematischer Diagnoseablauf

  1. Exakte Fehlermeldung und Zeitpunkt aufnehmen.
  2. Anwendung und Protokoll bestimmen.
  3. Bestätigen, dass tatsächlich UDP verwendet wird.
  4. Quell- und Zieladresse dokumentieren.
  5. Quell- und Zielport dokumentieren.
  6. IPv4 und IPv6 unterscheiden.
  7. Unicast, Broadcast oder Multicast bestimmen.
  8. Erwartete Anfrage und Antwort beschreiben.
  9. Lokalen UDP-Endpunkt auf dem Server prüfen.
  10. Besitzenden Prozess bestimmen.
  11. Richtige Bindungsadresse prüfen.
  12. Host-, Container- und Pod-Namespace unterscheiden.
  13. Anwendungsprotokolle auf dem Server prüfen.
  14. Protokollspezifischen Test vom Client durchführen.
  15. UDP-Anfrage auf dem Client erfassen.
  16. Prüfen, ob die Anfrage den Server erreicht.
  17. Prüfen, ob die Anwendung die Anfrage verarbeitet.
  18. Prüfen, ob eine Antwort erzeugt wird.
  19. Prüfen, ob die Antwort den Client erreicht.
  20. Quelladresse und Quellport der Antwort prüfen.
  21. ICMPv4- und ICMPv6-Meldungen auswerten.
  22. ICMP-Erzeuger und eingebettetes Originalpaket prüfen.
  23. Stateful Firewall und UDP-Zustand prüfen.
  24. NAT-Übersetzung und Rückweg prüfen.
  25. Idle-Timeouts berücksichtigen.
  26. UDP- und Schnittstellenzähler vergleichen.
  27. Empfangspuffer und Anwendungsleistung prüfen.
  28. Kleine und große gültige Datagramme vergleichen.
  29. MTU, Fragmentierung und Tunnel berücksichtigen.
  30. Bei Multicast Gruppenmitgliedschaft und Switch prüfen.
  31. Hypothese und Gegenbeweis formulieren.
  32. Genau eine kontrollierte Maßnahme durchführen.
  33. Identischen Test wiederholen.
  34. Anwendung und mehrere Versuche verifizieren.
  35. Temporäre Aufzeichnung und Filter zurücknehmen.
  36. Ursache und Prävention dokumentieren.

Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
kein lokaler UDP-Endpunkt Dienst fehlt oder falscher Namespace Prozess und Dienststart prüfen
Endpunkt nur auf Loopback nur lokale Erreichbarkeit Sollbindung prüfen
Endpunkt vorhanden, Anfrage erreicht Server nicht Netzwerk oder Firewall Client- und Zwischenaufzeichnung
Anfrage erreicht Server, Anwendung sieht sie nicht Socket, Firewall oder Puffer Prozesslog und UDP-Zähler
Anwendung sieht Anfrage, antwortet nicht Protokoll oder Anwendung Anwendungslogik prüfen
Antwort verlässt Server, erreicht Client nicht Rückweg, NAT oder Firewall Client- und Firewallaufzeichnung
ICMP Port Unreachable Zielport nicht gebunden oder aktive Ablehnung lokale Socketliste
ICMP Administratively Prohibited Richtlinie blockiert Firewall- oder Routerkonfiguration
keine Antwort und kein ICMP geöffnet/still oder gefiltert serverseitige Aufzeichnung
kleine Datagramme funktionieren Basispfad funktioniert größere gültige Nachricht testen
große Datagramme scheitern MTU, Fragmentierung oder Puffer ICMP und Fragmente erfassen
ICMP Fragmentation Needed IPv4-Paket zu groß und DF gesetzt Path MTU prüfen
ICMPv6 Packet Too Big IPv6-Paket überschreitet Path MTU gemeldete MTU auswerten
UdpNoPorts steigt Datagramme erreichen ungebundene Ports Zielport und Dienst prüfen
UdpRcvbufErrors steigt Empfangspuffer überlastet Datenrate und Anwendung prüfen
nur nach Inaktivität fehlerhaft UDP-Zustand abgelaufen Firewall-/NAT-Timeout
neue Anfrage funktioniert sofort alter Pseudo-Sitzungszustand fehlerhaft Flow und Quellport vergleichen
Docker zeigt nur TCP-Publish UDP nicht veröffentlicht Portkonfiguration prüfen
Kubernetes-Service nutzt TCP falsches Serviceprotokoll Manifest korrigieren
Service hat keine Endpunkte Selektor oder Readiness Pods und EndpointSlices
Multicast nur auf einem Host fehlerhaft Gruppenmitgliedschaft oder Schnittstelle IGMP/MLD und Socket prüfen
Wireshark zeigt Bad Checksum nur lokal Checksum Offloading möglich externe Aufzeichnung
PortQry meldet LISTENING OR FILTERED Ergebnis nicht eindeutig gültiger Protokolltest und Servertrace

Typische Diagnosefehler

Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Eine einzelne sichtbare UDP-Antwort ist keine ausreichende Verifikation für alle Clients, Paketgrößen und Netzwerkpfade.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Zeitpunkt:
<Datum, Uhrzeit und Zeitzone>

Anwendung:
<Dienst oder Protokoll>

Client:
<Hostname und IP-Adresse>

Server:
<Hostname und IP-Adresse>

Adressfamilie:
<IPv4 oder IPv6>

Kommunikationsart:
<Unicast, Broadcast oder Multicast>

Quellport:
<Port>

Zielport:
<Port>

Erwartete Anfrage:
<Protokollnachricht>

Erwartete Antwort:
<Antwort oder keine Antwort vorgesehen>

UDP-Endpunkt:
<Adresse, Port, Prozess und PID>

Clientaufzeichnung:
<Anfrage gesendet, Antwort oder ICMP>

Serveraufzeichnung:
<Anfrage empfangen und Antwort gesendet>

ICMP-Befund:
<Typ, Code, Absender und eingebettetes Paket>

Paketgröße:
<UDP- und IP-Größe>

Fragmentierung:
<ja, nein oder unbekannt>

Firewallzustand:
<Befund>

NAT-Zuordnung:
<interne und externe Adressen und Ports>

Timeout:
<gemessene Dauer und verantwortliche Komponente>

UDP-Zähler:
<relevante Differenzen>

Nachgewiesene Ursache:
<technischer Befund>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

Durchgeführte Maßnahme:
<genau eine kontrollierte Änderung>

Risiko und Rückweg:
<Beschreibung>

Verifikation:
<identischer Test, Anwendung und weitere Clients>

Prävention:
<Monitoring oder Konfigurationsverbesserung>

Checkliste

Schnellreferenz

Aufgabe Befehl oder Filter
Windows-UDP-Endpunkte Get-NetUDPEndpoint
Windows-UDP-Port Get-NetUDPEndpoint -LocalPort <Port>
Windows-UDP-netstat netstat -ano -p udp
Windows-UDP-Statistik netstat -s -p udp
Windows-UDP-PortQry portqry.exe -n <Ziel> -p UDP -e <Port>
Windows-Paketmonitor pktmon
Windows-DNS-UDP-Test Resolve-DnsName -Name <Name> -Server <DNS-IP> -DnsOnly
Linux-UDP-Endpunkte sudo ss -lunp
Linux-alle UDP-Sockets sudo ss -uanp
Linux-UDP-Port sudo ss -lunp 'sport = :<Port>'
Linux-Prozess zu UDP-Port sudo lsof -nP -iUDP:<Port>
Linux-UDP-Zähler nstat -az
Linux-Schnittstellenzähler ip -s link
macOS-UDP-Sockets sudo lsof -nP -iUDP
macOS-UDP-netstat netstat -anv -p udp
macOS-UDP-Statistik netstat -s -p udp
DNS-UDP-Test dig @<DNS-IP> <Name> <Typ>
DNS-TCP-Vergleich dig @<DNS-IP> <Name> <Typ> +tcp
Linux-Aufzeichnung sudo tcpdump -ni any '(udp port <Port>) or icmp or icmp6' -c 200
macOS-Aufzeichnung sudo tcpdump -ni <Interface> '(udp port <Port>) or icmp or icmp6' -c 200
Wireshark UDP-Port udp.port == <Port>
Wireshark ICMPv4 icmp
Wireshark ICMPv6 icmpv6
ICMPv4 Port Unreachable icmp.type == 3 && icmp.code == 3
ICMPv4 Fragmentation Needed icmp.type == 3 && icmp.code == 4
ICMPv4 Time Exceeded icmp.type == 11
ICMPv6 Port Unreachable icmpv6.type == 1 && icmpv6.code == 4
ICMPv6 Packet Too Big icmpv6.type == 2
ICMPv6 Time Exceeded icmpv6.type == 3

Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen

Stop-Process
taskkill
Stop-Service
Restart-Service
Set-NetFirewallRule
New-NetFirewallRule
Deaktivieren der Windows-Firewall
netsh int ip reset
netsh winsock reset
kill
kill -9
systemctl stop
systemctl restart
sysctl -w
iptables
nft
ufw disable
firewall-cmd --permanent
docker restart
docker stop
kubectl delete
kubectl rollout restart
unkontrollierte UDP-Portscans
UDP-Lasttests ohne Freigabe
ungefilterte Broadcasts
ungefilterte Multicasttests
pauschales Zulassen aller ICMP-Typen
vollständiges Blockieren von ICMP oder ICMPv6
willkürliche Erhöhung von Socketpuffern
unkontrollierte Änderung von UDP-Idle-Timeouts

Ein Neustart kann Socketzustände, Zähler, NAT-Zuordnungen und den für die Diagnose wichtigen Ausgangszustand zerstören.

Quellen

Standards

Offizielle Microsoft-Dokumentation

Offizielle Linux- und Projektdokumentation

Offizielle Wireshark-Dokumentation

Offizielle Containerdokumentation

Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet.

9. TCP, UDP, Ports, Firewall, NAT und Proxy

9.4 Lokale Host-Firewall prüfen

Ziel dieser Seite

Diese Seite beschreibt die systematische Diagnose einer lokalen Host-Firewall unter Windows, Linux und macOS sowie ihre Abgrenzung von:

Nach der Bearbeitung muss nachvollziehbar geprüft werden können:

Eine Host-Firewall darf nicht vorsorglich vollständig deaktiviert werden. Zuerst müssen der betroffene Datenfluss und die tatsächlich wirksame Regel nachgewiesen werden.

Sicherheits- und Wirkungsklassen

Kennzeichnung Bedeutung
LESEND Erfasst ausschließlich vorhandene Zustände.
NETZAKTIV Erzeugt Netzwerkverkehr zum geprüften Ziel.
SENSITIV Kann interne Regeln, Adressen, Programme oder Kommunikationsbeziehungen sichtbar machen.
ÄNDERND Verändert Firewallkonfiguration oder Protokollierung.
AUSFALLRISIKO Kann bestehende Verbindungen, Verwaltung oder Dienste beeinträchtigen.

Firewallregeln und Protokolle können sicherheitsrelevante Informationen enthalten:

Diese Informationen müssen geschützt gespeichert und weitergegeben werden.

Aufgabe einer lokalen Host-Firewall

Eine lokale Host-Firewall filtert Netzwerkverkehr direkt auf einem Endgerät oder Server.

Abhängig vom Betriebssystem kann sie prüfen:

Eine Host-Firewall ersetzt keine Netzwerkfirewall. Beide Ebenen können gleichzeitig filtern.

Datenpfad vereinfachen

Eingehender Datenverkehr:

Client
→ Netzwerkfirewall
→ Servernetzwerkschnittstelle
→ lokale Host-Firewall
→ lokaler Socket
→ Anwendung

Ausgehender Datenverkehr:

Anwendung
→ lokaler Socket
→ lokale Host-Firewall
→ Servernetzwerkschnittstelle
→ Netzwerkfirewall
→ Ziel

Container- oder VM-Verkehr kann zusätzlich einen Weiterleitungspfad verwenden:

Client
→ Hostnetzwerkschnittstelle
→ Host-Firewall oder NAT
→ virtuelle Bridge
→ Container- oder VM-Firewall
→ Anwendung

Jede Ebene muss getrennt nachgewiesen werden.

Host-Firewall, Listener und Anwendung unterscheiden

Befund Aussage
Dienst läuft Prozessstatus ist vorhanden
Listener vorhanden Socket wurde gebunden
lokale Verbindung funktioniert lokaler Netzwerkpfad funktioniert
entfernte Verbindung funktioniert der getestete Ende-zu-Ende-Pfad funktioniert
Firewallregel vorhanden eine konfigurierte Regel existiert
Firewallregel wirksam Regel gilt für den konkreten Datenfluss
Paket wird geloggt Paket wurde an einem bestimmten Filterpunkt erfasst
Anwendung antwortet Transport und Anwendung funktionieren für den Test

Eine vorhandene Allow-Regel beweist nicht, dass:

Prüfdaten des betroffenen Flows

Vor der Regelsuche muss der Datenfluss exakt dokumentiert werden.

Richtung:
<eingehend oder ausgehend>

Transportprotokoll:
<TCP, UDP, ICMPv4, ICMPv6 oder anderes>

Quelladresse:
<IP-Adresse oder Netz>

Quellport:
<Port oder dynamischer Bereich>

Zieladresse:
<IP-Adresse>

Zielport:
<Port>

Lokales Programm:
<vollständiger Pfad>

Lokaler Dienst:
<Dienstname>

Schnittstelle:
<Ethernet, WLAN, VPN, Loopback oder virtuell>

Netzwerkprofil oder Zone:
<Domain, Private, Public oder Linux-Zone>

Zeitpunkt:
<Datum, Uhrzeit und Zeitzone>

Ohne diese Angaben kann nicht sicher entschieden werden, ob eine Firewallregel zum Fehler passt.

Eingehend, ausgehend und weitergeleitet

Richtung Bedeutung
eingehend Verkehr ist an den lokalen Host adressiert
ausgehend Verkehr wird durch einen lokalen Prozess erzeugt
weitergeleitet Verkehr durchquert den Host zu einem anderen Endpunkt

Unter Linux entsprechen diese Pfade häufig den Netfilter-Hooks beziehungsweise Basischains:

input
output
forward

Ein Paket für einen Container oder eine virtuelle Maschine kann den Hostpfad forward verwenden, obwohl der Client den Hostport anspricht.

Eine Regel im lokalen input-Pfad muss deshalb nicht für weitergeleiteten Containerverkehr gelten.

Loopback ist kein vollständiger Firewalltest

Ein Test gegen:

127.0.0.1
::1
localhost

prüft den Loopbackpfad.

Dieser Test bildet nicht zwingend ab:

Auch ein Test gegen die eigene LAN-Adresse vom selben Host kann lokal geroutet werden und muss nicht denselben Pfad wie ein entfernter Client verwenden.

Für eine vollständige Prüfung ist ein repräsentativer externer Client erforderlich.

Firewallzustände richtig interpretieren

Aktion Typisches Verhalten
Allow oder Accept passender Verkehr darf den Filterpunkt passieren
Drop Paket wird ohne aktive Fehlermeldung verworfen
Reject Paket wird verworfen und es kann eine Ablehnung zurückgesendet werden
Log Ereignis wird protokolliert; allein keine Allow- oder Blockaktion
Default Deny nicht ausdrücklich erlaubter Verkehr wird blockiert
Default Allow nicht ausdrücklich blockierter Verkehr wird erlaubt

Ein TCP-Reset kann entstehen durch:

Ein Timeout kann durch stilles Drop-Verhalten entstehen, beweist aber nicht automatisch eine Firewallblockierung.

Wirksame Richtlinie statt nur Konfigurationsdatei prüfen

Firewallregeln können stammen aus:

Entscheidend ist die tatsächlich aktive Richtlinie.

Eine Konfigurationsdatei oder GUI kann vom wirksamen Kernelzustand abweichen, wenn:

Windows-Firewallprofile

Windows verwendet drei Firewallprofile:

Profil Typische Verwendung
Domain Netzwerk mit erkannter und authentifizierter Active-Directory-Domäne
Private als vertrauenswürdig eingestuftes privates Netzwerk
Public nicht vertrauenswürdiges oder öffentliches Netzwerk

Regeln können für ein oder mehrere Profile gelten.

Ein häufiger Fehler ist:

Allow-Regel gilt nur für Domain oder Private.
Die aktive Schnittstelle verwendet jedoch Public.

Windows kann unterschiedliche Profile gleichzeitig für unterschiedliche Schnittstellen verwenden.

Windows: aktive Netzwerkprofile prüfen

LESEND

Get-NetConnectionProfile |
  Select-Object `
    InterfaceAlias,
    InterfaceIndex,
    Name,
    NetworkCategory,
    IPv4Connectivity,
    IPv6Connectivity

Zu prüfen sind:

Das Domainprofil darf nicht manuell als Ersatz für eine fehlerhafte Domänenerkennung erzwungen werden. Zuerst müssen DNS, Erreichbarkeit, Authentifizierung und Netzwerkidentifikation geprüft werden.

Windows: Firewallprofile prüfen

LESEND

Get-NetFirewallProfile |
  Select-Object `
    Name,
    Enabled,
    DefaultInboundAction,
    DefaultOutboundAction,
    AllowInboundRules,
    AllowLocalFirewallRules,
    AllowLocalIPsecRules,
    NotifyOnListen,
    LogFileName,
    LogMaxSizeKilobytes,
    LogAllowed,
    LogBlocked

Wirksame Profile aus dem aktiven Richtlinienspeicher:

Get-NetFirewallProfile `
  -PolicyStore ActiveStore |
  Format-List *

Zu dokumentieren sind:

Die Standardaktionen dürfen nicht ungeprüft als Block beziehungsweise Allow angenommen werden.

Windows: aktive Regeln erfassen

LESEND

Alle wirksamen Regeln:

Get-NetFirewallRule `
  -PolicyStore ActiveStore

Aktivierte Regeln:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Enabled True

Aktivierte eingehende Allow-Regeln:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Enabled True `
  -Direction Inbound `
  -Action Allow

Aktivierte eingehende Blockregeln:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Enabled True `
  -Direction Inbound `
  -Action Block

Aktivierte ausgehende Blockregeln:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Enabled True `
  -Direction Outbound `
  -Action Block

Herkunft der Regeln:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Enabled True |
  Select-Object `
    Name,
    DisplayName,
    Direction,
    Action,
    Profile,
    PolicyStoreSourceType,
    PolicyStoreSource

ActiveStore stellt die zusammengeführte aktive Richtlinie der auf das System wirkenden Policy Stores dar. Eine Abfrage ohne -PolicyStore ActiveStore kann eine andere Sicht liefern.

Windows: vollständige Regeldarstellung

LESEND

Show-NetFirewallRule `
  -PolicyStore ActiveStore

Für eine bekannte Regel:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Name "<Regelname>" |
  Format-List *

Die eigentlichen Port-, Adress-, Programm- und Dienstbedingungen werden in zugeordneten Filterobjekten verwaltet.

Windows: Portfilter prüfen

LESEND

Alle Portfilter:

Get-NetFirewallPortFilter `
  -PolicyStore ActiveStore

Regeln für lokalen Port 443 suchen:

Get-NetFirewallPortFilter `
  -PolicyStore ActiveStore |
  Where-Object LocalPort -eq "443" |
  Get-NetFirewallRule |
  Select-Object `
    Name,
    DisplayName,
    Enabled,
    Direction,
    Action,
    Profile,
    PolicyStoreSourceType,
    PolicyStoreSource

Regeln für entfernten Port 443:

Get-NetFirewallPortFilter `
  -PolicyStore ActiveStore |
  Where-Object RemotePort -eq "443" |
  Get-NetFirewallRule |
  Select-Object `
    Name,
    DisplayName,
    Enabled,
    Direction,
    Action,
    Profile

Danach muss der vollständige Portfilter der gefundenen Regel geprüft werden:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Name "<Regelname>" |
  Get-NetFirewallPortFilter |
  Format-List *

Zu prüfen sind:

Windows: Adressfilter prüfen

LESEND

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Name "<Regelname>" |
  Get-NetFirewallAddressFilter |
  Format-List *

Zu prüfen sind:

Eine Allow-Regel für:

RemoteAddress = 192.0.2.0/24

gilt nicht für einen Client aus:

198.51.100.0/24

Windows: Programmfilter prüfen

LESEND

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Name "<Regelname>" |
  Get-NetFirewallApplicationFilter |
  Format-List *

Zu prüfen sind:

Eine Regel für einen alten Anwendungspfad gilt nicht automatisch für eine neue Programmdatei.

Windows: Dienstfilter prüfen

LESEND

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Name "<Regelname>" |
  Get-NetFirewallServiceFilter |
  Format-List *

Zu prüfen sind:

Eine Regel kann für einen Dienst gelten, obwohl mehrere Dienste denselben Prozess wie svchost.exe verwenden.

Windows: Schnittstellenfilter prüfen

LESEND

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Name "<Regelname>" |
  Get-NetFirewallInterfaceFilter |
  Format-List *

Zu prüfen sind:

Eine Regel für LAN muss nicht für einen VPN- oder WLAN-Pfad gelten.

Windows: Regelbedingungen vollständig dokumentieren

Für eine gefundene Regel müssen mindestens folgende Informationen zusammengeführt werden:

Name:
<Regelname>

Status:
<aktiviert oder deaktiviert>

Richtung:
<eingehend oder ausgehend>

Aktion:
<Allow oder Block>

Profile:
<Domain, Private, Public>

Protokoll:
<TCP, UDP, ICMPv4 oder ICMPv6>

Lokaler Port:
<Port>

Entfernter Port:
<Port>

Lokale Adresse:
<Adresse oder Netz>

Entfernte Adresse:
<Adresse oder Netz>

Programm:
<Pfad>

Dienst:
<Dienstname>

Schnittstelle:
<Filter>

Richtlinienquelle:
<Local, Group Policy, MDM oder andere>

Erst der Vergleich aller Bedingungen mit dem konkreten Datenfluss zeigt, ob die Regel tatsächlich passt.

Windows-Regelvorrang

Für Windows-Firewallregeln gilt unter anderem:

Windows-Firewallregeln dürfen nicht wie eine einfache von oben nach unten abgearbeitete ACL-Liste interpretiert werden.

Windows: Gruppenrichtlinienbezug prüfen

LESEND

Zusammenfassung der angewendeten Computerrichtlinien:

gpresult /scope computer /r

Wirksame Firewallregeln enthalten zusätzlich:

PolicyStoreSourceType
PolicyStoreSource

Zu prüfen sind:

Eine zentral verwaltete Regel darf nicht durch eine lokale Parallelregel umgangen werden.

Windows: Firewallprotokoll prüfen

Der Protokollpfad kann je Profil abweichen und muss über Get-NetFirewallProfile bestimmt werden.

Typischer Standardpfad:

%SystemRoot%\System32\LogFiles\Firewall\pfirewall.log

Letzte Einträge:

LESEND · SENSITIV

Get-Content `
  "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log" `
  -Tail 100

Nach Adresse oder Port suchen:

Get-Content `
  "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log" `
  -Tail 1000 |
  Select-String "192.0.2.100|443"

Zu korrelieren sind:

Fehlende Einträge beweisen nicht, dass die Firewall nicht beteiligt ist. Protokollierung kann deaktiviert, begrenzt oder an einem anderen Pfad konfiguriert sein.

Windows: temporäre Protokollierung

Vor einer Änderung müssen die vorhandenen Profilwerte dokumentiert werden.

Aktuellen Zustand sichern:

Get-NetFirewallProfile |
  Select-Object `
    Name,
    LogFileName,
    LogMaxSizeKilobytes,
    LogAllowed,
    LogBlocked

Blockprotokollierung für ein bestimmtes Profil aktivieren:

ÄNDERND · SENSITIV

Set-NetFirewallProfile `
  -Profile Domain `
  -LogBlocked True

Die Änderung muss:

Das Aktivieren der Protokollierung für erlaubte Verbindungen kann sehr große Datenmengen erzeugen.

Windows Filtering Platform prüfen

Windows Filtering Platform, kurz WFP, bildet die Filterplattform für Windows-Firewall, IPsec und weitere Filterkomponenten.

Relevante Security-Ereignisse können sein:

Ereignis-ID Bedeutung
5152 WFP hat ein Paket blockiert.
5154 Anwendung oder Dienst durfte auf eingehende Verbindungen lauschen.
5155 Anwendung oder Dienst wurde am Lauschen gehindert.
5156 WFP hat eine Verbindung erlaubt.
5157 WFP hat eine Verbindung blockiert.
5158 Bindung an einen lokalen Port wurde erlaubt.
5159 Bindung an einen lokalen Port wurde blockiert.

Blockereignisse lesen:

LESEND · SENSITIV

Get-WinEvent `
  -FilterHashtable @{
    LogName = "Security"
    Id      = 5152, 5155, 5157, 5159
  } `
  -MaxEvents 100

Diese Ereignisse stehen nur zur Verfügung, wenn die entsprechenden Überwachungsrichtlinien aktiv waren.

Zu prüfen sind:

Sehr umfangreiche WFP-Überwachung kann viele Ereignisse erzeugen und muss gezielt eingesetzt werden.

Windows: netsh als ergänzende Sicht

LESEND

Profile:

netsh advfirewall show allprofiles

Regeln:

netsh advfirewall firewall show rule name=all verbose

Überwachungszustand:

netsh advfirewall monitor show firewall

Der ältere Kontext:

netsh firewall

sollte nicht mehr für die aktuelle Verwaltung verwendet werden. Für moderne Systeme sind PowerShell-NetSecurity-Cmdlets und netsh advfirewall vorgesehen.

Windows: Drittanbieterfilter berücksichtigen

Verkehr kann blockiert werden, obwohl keine passende Windows-Firewall-Blockregel sichtbar ist.

Mögliche zusätzliche Filter:

Hinweise:

Sicherheitssoftware darf nicht ohne Freigabe beendet oder deinstalliert werden.

Windows: Hyper-V, WSL und Container

Verkehr zu einer VM, WSL-Instanz oder einem Container kann zusätzliche Filterebenen durchlaufen.

Zu unterscheiden sind:

Verfügbare Hyper-V-Firewall-Cmdlets prüfen:

Get-Command `
  -Name "*NetFirewallHyperV*" `
  -ErrorAction SilentlyContinue

Wenn entsprechende Cmdlets vorhanden sind, müssen Hyper-V-Profile und Regeln zusätzlich geprüft werden.

Eine Allow-Regel im normalen Hostprofil beweist nicht automatisch, dass Verkehr zu einer VM oder WSL-Instanz erlaubt wird.

Linux: verwendetes Firewall-Backend bestimmen

Auf Linux-Systemen können mehrere Werkzeuge vorhanden sein:

Zuerst muss bestimmt werden, welches System die aktive Richtlinie verwaltet.

Versionen prüfen:

LESEND

nft --version

iptables --version

Eine iptables-Ausgabe kann auf ein Backend hinweisen:

iptables vX.Y.Z (nf_tables)

oder:

iptables vX.Y.Z (legacy)

Aktive Manager:

systemctl is-active firewalld

systemctl is-active ufw

Die Installation oder Aktivität eines Managers beweist nicht, dass keine weiteren Regeln existieren.

Linux: nftables-Regelsatz prüfen

LESEND · SENSITIV

sudo nft list ruleset

Mit Regel-Handles:

sudo nft -a list ruleset

Zu prüfen sind:

Wichtige Tabellenfamilien:

Familie Bedeutung
inet gemeinsame Verarbeitung von IPv4 und IPv6
ip IPv4
ip6 IPv6
bridge Bridgeverkehr
arp ARP
netdev früher Paketpfad an Netzgeräten

Eine Regel in inet kann sowohl IPv4 als auch IPv6 betreffen. Separate ip- und ip6-Regeln müssen getrennt geprüft werden.

Linux: nftables-Hooks prüfen

Typische Hooks:

Hook Datenpfad
input Verkehr zum lokalen Host
output lokal erzeugter Verkehr
forward weitergeleiteter Verkehr
prerouting vor der Routingentscheidung
postrouting nach der Routingentscheidung
ingress früher Eingangspfad

Der Name einer Chain muss nicht ihrem Hook entsprechen. Entscheidend ist die tatsächliche Chain-Definition.

Beispiel:

chain host_in {
    type filter hook input priority filter;
    policy drop;
}

Eine frei benannte Chain ohne Hook wirkt nur, wenn eine andere Regel in sie springt.

Linux: nftables-Counter auswerten

Regeln können Zähler für Pakete und Bytes enthalten.

Beispielausgabe:

counter packets 42 bytes 3360 drop

Für einen kontrollierten Test:

  1. aktuellen Zählerstand dokumentieren;
  2. genau einen Test ausführen;
  3. Regelsatz erneut lesen;
  4. Zählerdifferenz prüfen;
  5. Quelladresse, Zielport und Protokoll abgleichen.

Ein unveränderter Zähler beweist nicht automatisch, dass die Regel nicht betroffen ist:

Zähler dürfen nicht vorsorglich zurückgesetzt werden, weil dadurch Beweisdaten verloren gehen.

Linux: iptables-Regeln prüfen

LESEND · SENSITIV

IPv4:

sudo iptables \
  -L \
  -n \
  -v \
  --line-numbers

IPv6:

sudo ip6tables \
  -L \
  -n \
  -v \
  --line-numbers

Vollständiger IPv4-Regelsatz mit Countern:

sudo iptables-save \
  -c

Vollständiger IPv6-Regelsatz:

sudo ip6tables-save \
  -c

Wichtige Optionen:

Option Bedeutung
-L Chains und Regeln anzeigen
-n numerische Adressen und Ports
-v ausführliche Anzeige und Counter
--line-numbers Regelpositionen anzeigen
-c bei iptables-save Counter mit ausgeben

iptables -L allein bildet nicht immer alle Tabellen und benutzerdefinierten Zusammenhänge ausreichend ab. iptables-save liefert eine vollständigere Regelsatzdarstellung.

Linux: INPUT, OUTPUT und FORWARD unterscheiden

Typische Bedeutung:

INPUT:
Paket ist an den Linux-Host selbst adressiert.

OUTPUT:
Paket wurde auf dem Linux-Host erzeugt.

FORWARD:
Paket wird durch den Linux-Host weitergeleitet.

Containerverkehr kann beispielsweise durchlaufen:

PREROUTING
→ FORWARD
→ POSTROUTING

Eine Allow-Regel in INPUT hilft in diesem Fall nicht zwingend.

Linux: firewalld-Zustand prüfen

LESEND

Dienstzustand:

firewall-cmd --state

Aktive Zonen und Zuordnungen:

firewall-cmd --get-active-zones

Standardzone:

firewall-cmd --get-default-zone

Alle Zonen:

firewall-cmd --list-all-zones

Bestimmte aktive Zone:

firewall-cmd \
  --zone=<Zone> \
  --list-all

Rich Rules:

firewall-cmd \
  --zone=<Zone> \
  --list-rich-rules

Richtlinienobjekte:

firewall-cmd --get-policies

firewall-cmd --list-all-policies

Zu prüfen sind:

Die Standardzone ist nicht automatisch die tatsächlich für jede Schnittstelle wirksame Zone.

Linux: firewalld-Laufzeit und permanente Konfiguration

firewalld unterscheidet:

Konfiguration Wirkung
Runtime aktuell aktiv, geht ohne Übernahme bei Reload oder Neustart verloren
Permanent gespeichert, wird bei Reload oder Start zur Runtime-Konfiguration

Runtime-Konfiguration einer Zone:

firewall-cmd \
  --zone=<Zone> \
  --list-all

Permanente Konfiguration:

firewall-cmd \
  --permanent \
  --zone=<Zone> \
  --list-all

Beide Ausgaben müssen verglichen werden.

Mögliche Fehler:

Ein firewall-cmd --reload ist eine Änderung und darf nicht als erster Diagnoseschritt verwendet werden.

Linux: bestimmten firewalld-Port prüfen

Runtime:

firewall-cmd \
  --zone=<Zone> \
  --query-port=443/tcp

Service:

firewall-cmd \
  --zone=<Zone> \
  --query-service=https

Permanent:

firewall-cmd \
  --permanent \
  --zone=<Zone> \
  --query-port=443/tcp

Ein positives Ergebnis beweist nur, dass Port oder Service in dieser Zone konfiguriert ist. Es beweist nicht:

Linux: UFW prüfen

LESEND

Status und Standardrichtlinien:

sudo ufw status verbose

Nummerierte Regeln:

sudo ufw status numbered

Von UFW verwaltete hinzugefügte Regeln:

sudo ufw show added

Vollständigere Netfilter-Sicht:

sudo ufw show raw

Zu prüfen sind:

ufw status zeigt nicht zwingend alle Regeln, die außerhalb von UFW erzeugt wurden. Ein Status inactive beweist deshalb nicht, dass im Kernel keine anderen Netfilterregeln aktiv sind.

Linux: vorhandene Firewallprotokolle prüfen

Kernelmeldungen im betroffenen Zeitraum:

LESEND · SENSITIV

journalctl \
  -k \
  --since "15 minutes ago"

firewalld-Dienstmeldungen:

journalctl \
  -u firewalld \
  --since "15 minutes ago"

UFW-Dienstmeldungen:

journalctl \
  -u ufw \
  --since "15 minutes ago"

Zu beachten:

Neue Logregeln dürfen nur gezielt, rate-limitiert und zeitlich begrenzt erstellt werden.

Linux: eBPF-, XDP- und tc-Filter berücksichtigen

Pakete können vor oder außerhalb der erwarteten nftables- oder iptables-Regel verworfen werden.

Schnittstellendetails:

ip \
  -details \
  link show \
  dev <Schnittstelle>

tc-Ingressfilter:

sudo tc \
  filter show \
  dev <Schnittstelle> \
  ingress

tc-Egressfilter:

sudo tc \
  filter show \
  dev <Schnittstelle> \
  egress

Falls bpftool vorhanden ist:

sudo bpftool net

Mögliche Verursacher:

Diese Filter dürfen nicht ohne Kenntnis ihres Besitzers entfernt werden.

macOS: zwei Firewallbereiche unterscheiden

Unter macOS müssen mindestens zwei unterschiedliche Mechanismen getrennt betrachtet werden:

Mechanismus Aufgabe
Application Layer Firewall steuert eingehende Verbindungen anhand von Apps und Diensten
Packet Filter pf paket- und regelbasierte Filterung auf Netzwerkebene

Zusätzlich können vorhanden sein:

Die macOS Application Firewall wird nicht primär als frei konfigurierbare Portfirewall verwaltet. Apple beschreibt sie als anwendungsbezogene Firewall.

macOS: Application Firewall in der Oberfläche prüfen

Aktueller Pfad:

Apple-Menü
→ Systemeinstellungen
→ Netzwerk
→ Firewall

Zu prüfen sind:

Die genaue Darstellung kann je nach macOS-Version und Geräteverwaltung abweichen.

macOS: Application Firewall im Terminal prüfen

LESEND

Gesamtstatus:

sudo /usr/libexec/ApplicationFirewall/socketfilterfw \
  --getglobalstate

Block-All-Zustand:

sudo /usr/libexec/ApplicationFirewall/socketfilterfw \
  --getblockall

Tarnmodus:

sudo /usr/libexec/ApplicationFirewall/socketfilterfw \
  --getstealthmode

Anwendungsliste:

sudo /usr/libexec/ApplicationFirewall/socketfilterfw \
  --listapps

Lokale Hilfe und verfügbare Optionen:

/usr/libexec/ApplicationFirewall/socketfilterfw \
  --help

Zusammenfassung über System Profiler:

system_profiler SPFirewallDataType

Zu prüfen sind:

macOS: pf-Zustand prüfen

LESEND · SENSITIV

Status:

sudo pfctl -s info

Filterregeln:

sudo pfctl -sr

NAT-Regeln:

sudo pfctl -sn

Zustandstabelle:

sudo pfctl -ss

Gesamtübersicht:

sudo pfctl -sa

Zu prüfen sind:

Apple weist darauf hin, dass Packet Filter keine unterstützte API für die Integration eigener Softwareprodukte ist. Systembestandteile können die Regeln verwalten und verändern. Die Diagnose vorhandener Zustände ist deshalb von einer dauerhaften eigenen Produktintegration zu unterscheiden.

macOS: Network Extensions und Sicherheitsfilter

Installierte System Extensions:

LESEND

systemextensionsctl list

Mögliche Filterkomponenten:

Eine deaktivierte Application Firewall beweist nicht, dass keine Network Extension den Verkehr filtert.

Sicherheits- oder VPN-Erweiterungen dürfen nicht ohne Freigabe entfernt oder deaktiviert werden.

Docker und Host-Firewall

Docker kann auf dem Host eigene iptables- oder nftables-Regeln erzeugen, um:

Zu prüfen sind:

docker info

docker network ls

docker ps \
  --format 'table {{.Names}}\t{{.Ports}}'

docker inspect \
  <Containername> \
  --format '{{json .NetworkSettings.Ports}}'

Wichtige Punkte:

Ein freigegebener Hostport beweist nicht, dass die Anwendung im Container lauscht.

Kubernetes und lokale Host-Firewall

Auf einem Kubernetes-Knoten können zusätzlich wirken:

NetworkPolicy ist nicht dasselbe wie die allgemeine Host-Firewall.

Zu prüfen sind:

kubectl get networkpolicy \
  --all-namespaces

kubectl get service \
  --all-namespaces

kubectl get pods \
  --all-namespaces \
  -o wide

kubectl get endpointslice \
  --all-namespaces

Bei hostnahen Problemen müssen zusätzlich CNI- und Knotenkonfiguration berücksichtigt werden.

TCP-Fehlerbilder einer lokalen Firewall

Paketbefund Mögliche Einordnung
SYN erreicht Host nicht vorgelagerter Pfad oder falsche Zieladresse
SYN erreicht Host, Firewall loggt Drop lokale Host-Firewall bestätigt
SYN erreicht Host, kein Listener Betriebssystem kann RST senden
SYN erreicht Host, Listener vorhanden, keine Antwort lokale Filterung, Prozess oder Überlastung
Host sendet SYN/ACK, Client erhält es nicht ausgehender Filter oder Rückweg
Verbindung wird sofort zurückgesetzt Reject, fehlender Listener oder Anwendung
lokaler Test funktioniert, externer nicht Bindung, Profil, Host-Firewall oder Netzwerkpfad
nur ein Quellnetz fehlerhaft RemoteAddress- oder Zonenregel
nur IPv6 fehlerhaft fehlende IPv6-Regel oder ICMPv6-Problem
nur nach VPN-Verbindung fehlerhaft Profil-, Schnittstellen- oder VPN-Filter

UDP-Fehlerbilder einer lokalen Firewall

Paketbefund Mögliche Einordnung
UDP-Anfrage erreicht Host nicht vorgelagerter Pfad
Anfrage erreicht Host, Drop wird geloggt lokale Host-Firewall
Anfrage erreicht Host und Prozess nicht Hostfilter, Namespace oder Puffer
Anwendung antwortet, Antwort verlässt Host nicht ausgehende Hostfilterung
keine Antwort und kein ICMP geöffnet/still oder Drop
ICMP Port Unreachable kein passender UDP-Endpunkt oder aktive Ablehnung
nur große Datagramme scheitern Fragment-, MTU- oder ICMP-Filterung
Broadcast oder Multicast scheitert Schnittstellen-, Zonen- oder Gruppenregel

Ein allgemeiner TCP-Porttest ist kein Nachweis für UDP.

ICMP und ICMPv6 prüfen

Firewallregeln müssen ICMPv4 und ICMPv6 getrennt betrachten.

Zu prüfen sind:

Das Blockieren von Ping beweist nicht, dass TCP oder UDP blockiert wird.

Umgekehrt kann Ping funktionieren, während ein TCP- oder UDP-Port blockiert ist.

Das vollständige Blockieren von ICMP oder ICMPv6 kann Path MTU Discovery und Diagnose beeinträchtigen.

Paketaufzeichnung und Firewallprotokoll kombinieren

Eine Paketaufzeichnung allein zeigt nicht immer, ob ein Paket alle lokalen Filterstufen passiert hat. Der Aufzeichnungspunkt kann vor oder nach bestimmten Filtern liegen.

Belastbarer Nachweis:

  1. Testzeitpunkt genau dokumentieren.
  2. Paketaufzeichnung auf dem Host starten.
  3. Firewallcounter oder Protokoll erfassen.
  4. Genau einen Test ausführen.
  5. Listener und Prozesszustand erfassen.
  6. Firewallprotokoll mit dem Flow abgleichen.
  7. Paketaufzeichnung und Regelcounter vergleichen.
  8. Test vom repräsentativen Client wiederholen.

Windows-Paketaufzeichnung mit pktmon

pktmon kann Paketerfassung und Drop-Erkennung innerhalb des Windows-Netzwerkstacks unterstützen.

Filter zurücksetzen:

SENSITIV · ÄNDERND

pktmon stop

pktmon filter remove

Filter für TCP-Port 443:

pktmon filter add TCP443 -t TCP -p 443

Aufzeichnung starten:

pktmon start --capture --pkt-size 0 --file-name C:\Temp\firewall443.etl

Nach reproduziertem Fehler stoppen:

pktmon stop

Konvertieren:

pktmon etl2pcap C:\Temp\firewall443.etl --out C:\Temp\firewall443.pcapng

Filter entfernen:

pktmon filter remove

Das Zielverzeichnis muss vorhanden sein. Aufzeichnung und Filter müssen anschließend zurückgenommen werden.

Linux-Paketaufzeichnung

LESEND · SENSITIV

TCP-Port 443:

sudo tcpdump \
  -ni any \
  'tcp port 443' \
  -c 200

UDP-Port 53 und ICMP:

sudo tcpdump \
  -ni any \
  '(udp port 53) or icmp or icmp6' \
  -c 200

Bestimmte Schnittstelle und Gegenstelle:

sudo tcpdump \
  -ni <Schnittstelle> \
  'host 192.0.2.100 and tcp port 443' \
  -c 200

Eine sichtbare eingehende Anfrage beweist, dass sie den Capturepunkt erreicht hat. Ob sie die Anwendung erreicht, muss zusätzlich mit Firewallcounter, Socket- und Anwendungsbefund geprüft werden.

macOS-Paketaufzeichnung

Verfügbare Schnittstellen:

tcpdump -D

Bestimmte Schnittstelle:

sudo tcpdump \
  -ni en0 \
  'host 192.0.2.100 and tcp port 443' \
  -c 200

Loopback:

sudo tcpdump \
  -ni lo0 \
  'tcp port 8080' \
  -c 200

Application Firewall, pf, Network Extension und Anwendung müssen getrennt ausgewertet werden.

Lokalen und entfernten Test vergleichen

Windows:

NETZAKTIV

Test-NetConnection `
  -ComputerName "127.0.0.1" `
  -Port 443

Test-NetConnection `
  -ComputerName "192.0.2.25" `
  -Port 443

Von einem entfernten Client:

Test-NetConnection `
  -ComputerName "app.example.test" `
  -Port 443 `
  -InformationLevel Detailed

Linux und macOS:

nc -vz 127.0.0.1 443

nc -vz 192.0.2.25 443

Von einem entfernten Client:

nc -vz app.example.test 443

Auswertung:

lokaler Test entfernter Test Mögliche Einordnung
erfolgreich erfolgreich getesteter TCP-Pfad funktioniert
erfolgreich fehlerhaft Bindung, Host-Firewall oder Netzwerkpfad
fehlerhaft fehlerhaft Listener, Dienst, Port oder lokale Filterung
Loopback erfolgreich, LAN-IP fehlerhaft Bindung oder schnittstellenbezogene Regel
IPv4 erfolgreich, IPv6 fehlerhaft IPv6-Bindung oder IPv6-Firewall
ohne VPN erfolgreich, mit VPN fehlerhaft Profil-, Schnittstellen- oder VPN-Regel

Host-Firewall von Netzwerkfirewall abgrenzen

Nachweis Einordnung
Paket erreicht Serverschnittstelle nicht Problem vor dem Server
Paket erreicht Host und Host-Firewall loggt Drop lokale Host-Firewall bestätigt
Paket erreicht Host, kein Drop, kein Listener Dienst- oder Bindungsproblem
Paket erreicht Host, Listener vorhanden, Anwendung loggt nichts lokaler Filter, Endpoint Security oder Anwendung
Antwort verlässt Serverschnittstelle lokaler ausgehender Pfad wahrscheinlich passiert
Antwort verlässt Host nicht und Outbound-Drop wird geloggt lokale ausgehende Firewall
Client- und Serveraufzeichnung unterscheiden sich Verlust oder Filterung im Zwischenpfad
anderer Server im selben Netz funktioniert hostspezifische Konfiguration wahrscheinlich

Eine Paketaufzeichnung an nur einem Punkt reicht häufig nicht zur eindeutigen Abgrenzung.

Hypothese und Gegenbeweis

Beispiel:

Hypothese:
Die aktive Windows-Firewall blockiert eingehende TCP-Verbindungen auf
Port 443, weil die Allow-Regel nur für das Domainprofil gilt, die
aktive Schnittstelle aber dem Public-Profil zugeordnet ist.

Erwarteter Befund:
Get-NetConnectionProfile zeigt Public.
Die Regel gilt nur für Domain.
Der lokale Listener auf Port 443 ist vorhanden.
Der lokale Test funktioniert.
Der entfernte Test schlägt fehl.
Das Firewallprotokoll zeigt einen Drop für den Testflow.

Gegenbeweis:
Die Schnittstelle verwendet Domain und eine wirksame Allow-Regel
passt vollständig zu Protokoll, Port, Quelladresse und Programm.

Testmethode:
Profil-, Regel-, Listener-, Protokoll- und Paketprüfung.

Risiko:
Die lesenden Prüfungen verändern den Firewallzustand nicht.

Linux-Beispiel:

Hypothese:
Die Netzwerkschnittstelle befindet sich in der firewalld-Zone public,
aber die Freigabe wurde in der Zone internal angelegt.

Erwarteter Befund:
firewall-cmd --get-active-zones ordnet die Schnittstelle public zu.
Port 443 ist in public nicht erlaubt, in internal jedoch vorhanden.
Der Listener existiert und ein externer Test schlägt fehl.

Gegenbeweis:
Die Schnittstelle ist internal zugeordnet oder eine andere wirksame
Regel erlaubt den konkreten Flow.

Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko
vorhandene passende Regel aktivieren Regel ist geprüft und nur deaktiviert Dienst wird erreichbar
Profilzuordnung korrigieren falsche Netzwerkkategorie nachgewiesen Vertrauensniveau des Netzwerks ändert sich
gezielte Allow-Regel erstellen konkreter legitimer Flow bestätigt zusätzliche Angriffsfläche
zu breite Regel einschränken unnötiger Geltungsbereich bestätigt legitime Clients können ausfallen
falsche Blockregel korrigieren Blockregel als Ursache nachgewiesen Schutzwirkung kann reduziert werden
Programmpfad aktualisieren Anwendungspfad hat sich nachweislich geändert falsches Programm könnte freigegeben werden
RemoteAddress-Bereich korrigieren Quellnetz stimmt nachweislich nicht weitere Quellen können Zugriff erhalten
TCP-/UDP-Protokoll korrigieren Protokollverwechslung bestätigt zusätzlicher Transportweg wird geöffnet
IPv6-Regel ergänzen Dienst soll IPv6 nutzen und Block ist bestätigt zusätzliche IPv6-Erreichbarkeit
firewalld-Runtime und Permanent angleichen Abweichung bestätigt Wirkung über Neustart hinaus
Container-Weiterleitungsregel korrigieren Forward-Pfad bestätigt mehrere Container können betroffen sein
Endpoint-Security-Ausnahme beantragen Produktfilter als Ursache bestätigt zentrale Sicherheitswirkung
Logging zeitlich begrenzt aktivieren vorhandene Daten reichen nicht Speicher- und Datenschutzrisiko

Vor jeder Änderung müssen dokumentiert werden:

Systematischer Diagnoseablauf

  1. Exakte Fehlermeldung aufnehmen.
  2. Zeitpunkt und Zeitzone dokumentieren.
  3. Client, Server und Anwendung bestimmen.
  4. TCP, UDP, ICMPv4 oder ICMPv6 bestimmen.
  5. Quell- und Zieladressen dokumentieren.
  6. Quell- und Zielports dokumentieren.
  7. Listener und Bindungsadresse prüfen.
  8. Besitzenden Prozess bestimmen.
  9. lokalen Loopbacktest durchführen.
  10. konkrete lokale Schnittstellenadresse testen.
  11. Test von einem repräsentativen entfernten Client durchführen.
  12. Paketfluss eingehend, ausgehend oder weitergeleitet bestimmen.
  13. aktive Firewalltechnik bestimmen.
  14. aktives Profil, aktive Zone oder Schnittstelle bestimmen.
  15. Standardaktionen prüfen.
  16. wirksame Regeln erfassen.
  17. Allow- und Blockregeln prüfen.
  18. Protokoll- und Portfilter vergleichen.
  19. Adressbereiche vergleichen.
  20. Programm- und Dienstfilter vergleichen.
  21. Schnittstellenfilter vergleichen.
  22. Richtlinienquelle bestimmen.
  23. zentrale Richtlinien und lokale Zusammenführung prüfen.
  24. Firewallcounter und vorhandene Protokolle auswerten.
  25. bei Bedarf zeitlich begrenzte Protokollierung aktivieren.
  26. Paketaufzeichnung am Host durchführen.
  27. Paketaufzeichnung mit einem zweiten Punkt vergleichen.
  28. Container-, VM- und Namespacepfade berücksichtigen.
  29. Endpoint Security, VPN und zusätzliche Filter berücksichtigen.
  30. Hypothese und Gegenbeweis formulieren.
  31. Genau eine kontrollierte Änderung durchführen.
  32. identischen Test wiederholen.
  33. Anwendung statt nur Porttest verifizieren.
  34. weitere repräsentative Clients prüfen.
  35. temporäre Protokollierung und Filter zurücknehmen.
  36. Ursache, Maßnahme und Prävention dokumentieren.

Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
kein Listener kein Firewallproblem nachgewiesen Dienst und Bindung prüfen
lokaler Test funktioniert, remote nicht Firewall, Bindung oder Netzwerkpfad Serveraufzeichnung
Paket erreicht Server nicht vorgelagerter Pfad Netzwerkfirewall und Routing
Paket erreicht Server, Drop wird geloggt lokale Host-Firewall passende Regel bestimmen
Paket erreicht Server, kein Drop, kein App-Log Endpoint Filter oder Anwendung Prozess- und WFP/eBPF-Befund
Allow-Regel vorhanden, falsches Profil Regel nicht wirksam aktive Profilzuordnung
Allow-Regel vorhanden, falsche Zone Regel nicht wirksam firewalld-Zuordnung
Allow-Regel vorhanden, falsches Protokoll TCP-/UDP-Verwechslung Portfilter
Allow-Regel vorhanden, falsche Quelladresse Scope passt nicht Adressfilter
Allow-Regel vorhanden, alter Programmpfad App-Filter passt nicht Prozesspfad
Blockregel und Allow-Regel treffen zu Blockregel kann Vorrang besitzen vollständige Regelbedingungen
lokale Regel verschwindet zentrale Verwaltung PolicyStoreSource oder MDM
UFW inaktiv, Verkehr blockiert andere Netfilterregeln nft list ruleset
firewalld-Port permanent, nicht runtime noch nicht wirksam Runtime vergleichen
firewalld-Port runtime, nicht permanent verschwindet bei Reload Permanent vergleichen
nft-Counter steigt an Drop-Regel Regel trifft den Flow Zeit und 5-Tupel prüfen
iptables-Counter bleibt unverändert anderer Pfad oder Backend nftables und Namespace prüfen
Application Firewall erlaubt App, trotzdem blockiert pf, Network Extension oder VPN weitere Filter prüfen
Docker-Port veröffentlicht, Hostzugriff scheitert Forward-/Docker-Regel oder Container Docker-Regeln und Listener
Hostdienst funktioniert, Container nicht Namespace oder Forward-Pfad Container-Socket und NAT
nur IPv6 blockiert fehlende IPv6-Regel ip6, inet oder ICMPv6
nur VPN betroffen Schnittstellen-, Profil- oder VPN-Filter Zustand mit und ohne VPN
Antwort verlässt Host, Client sieht sie nicht Problem nach dem Host Rückweg und Netzwerkfirewall

Typische Diagnosefehler

Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Eine vollständig deaktivierte Firewall ist keine gültige Verifikation einer sicheren Lösung.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Zeitpunkt:
<Datum, Uhrzeit und Zeitzone>

Client:
<Hostname und IP-Adresse>

Server:
<Hostname und IP-Adresse>

Anwendung:
<Dienst und Prozess>

Richtung:
<eingehend, ausgehend oder weitergeleitet>

Transportprotokoll:
<TCP, UDP, ICMPv4 oder ICMPv6>

Quelladresse und Port:
<Adresse und Port>

Zieladresse und Port:
<Adresse und Port>

Listener:
<Adresse, Port, Prozess und PID>

Schnittstelle:
<Name und Typ>

Firewalltechnik:
<Windows Firewall, nftables, firewalld, UFW, pf oder andere>

Aktives Profil oder Zone:
<Wert>

Standardaktion:
<eingehend und ausgehend>

Wirksame Regel:
<Name, Aktion und Bedingungen>

Richtlinienquelle:
<lokal, GPO, MDM oder anderes>

Portfilter:
<Befund>

Adressfilter:
<Befund>

Programm- oder Dienstfilter:
<Befund>

Firewallprotokoll:
<Zeitpunkt und Aktion>

Paketaufzeichnung:
<eingehender und ausgehender Befund>

Zusätzliche Filter:
<Endpoint Security, VPN, Container oder Hypervisor>

Nachgewiesene Ursache:
<technischer Befund>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

Durchgeführte Maßnahme:
<genau eine kontrollierte Änderung>

Sicherheitsauswirkung:
<Beschreibung>

Risiko und Rückweg:
<Beschreibung>

Verifikation:
<identischer Test, Anwendung und weitere Systeme>

Prävention:
<Monitoring oder Konfigurationsverbesserung>

Checkliste

Schnellreferenz

Aufgabe Befehl
Windows-Netzwerkprofil Get-NetConnectionProfile
Windows-Firewallprofile Get-NetFirewallProfile
wirksame Windows-Regeln Get-NetFirewallRule -PolicyStore ActiveStore
aktivierte Windows-Regeln Get-NetFirewallRule -PolicyStore ActiveStore -Enabled True
Windows-Blockregeln Get-NetFirewallRule -PolicyStore ActiveStore -Enabled True -Action Block
Windows-Portfilter Get-NetFirewallPortFilter -PolicyStore ActiveStore
Windows-Adressfilter Get-NetFirewallAddressFilter -PolicyStore ActiveStore
Windows-Programmfilter Get-NetFirewallApplicationFilter -PolicyStore ActiveStore
Windows-Dienstfilter Get-NetFirewallServiceFilter -PolicyStore ActiveStore
vollständige Windows-Regeln Show-NetFirewallRule -PolicyStore ActiveStore
Windows-Firewallprotokoll Get-Content "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log" -Tail 100
Windows-WFP-Blockereignisse Get-WinEvent -FilterHashtable @{LogName="Security"; Id=5152,5155,5157,5159}
Windows-netsh-Profile netsh advfirewall show allprofiles
Windows-netsh-Regeln netsh advfirewall firewall show rule name=all verbose
nftables-Regelsatz sudo nft list ruleset
nftables mit Handles sudo nft -a list ruleset
iptables-Regeln sudo iptables -L -n -v --line-numbers
IPv6-iptables sudo ip6tables -L -n -v --line-numbers
iptables-Gesamtsicht sudo iptables-save -c
firewalld-Zustand firewall-cmd --state
aktive firewalld-Zonen firewall-cmd --get-active-zones
firewalld-Zone firewall-cmd --zone=<Zone> --list-all
permanente firewalld-Zone firewall-cmd --permanent --zone=<Zone> --list-all
firewalld-Port prüfen firewall-cmd --zone=<Zone> --query-port=<Port>/<Protokoll>
UFW-Status sudo ufw status verbose
nummerierte UFW-Regeln sudo ufw status numbered
vollständige UFW-Sicht sudo ufw show raw
Kernelprotokoll journalctl -k --since "15 minutes ago"
macOS-Firewallstatus sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
macOS-App-Liste sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps
macOS-Firewallübersicht system_profiler SPFirewallDataType
macOS-pf-Status sudo pfctl -s info
macOS-pf-Regeln sudo pfctl -sr
macOS-pf-States sudo pfctl -ss
macOS-System-Extensions systemextensionsctl list
Windows-TCP-Test Test-NetConnection -ComputerName <Ziel> -Port <Port>
Linux/macOS-TCP-Test nc -vz <Ziel> <Port>
Linux-Aufzeichnung sudo tcpdump -ni any 'tcp port <Port>' -c 200

Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen

Set-NetFirewallProfile -Enabled False
netsh advfirewall set allprofiles state off
Disable-NetFirewallRule ohne exakte Regelbegrenzung
Enable-NetFirewallRule ohne exakte Regelbegrenzung
Remove-NetFirewallRule
New-NetFirewallRule ohne dokumentierten Scope
netsh int ip reset
netsh winsock reset
nft flush ruleset
iptables -F
iptables -X
ip6tables -F
ufw disable
ufw reset
firewall-cmd --reload
firewall-cmd --complete-reload
systemctl stop firewalld
systemctl restart firewalld
pfctl -d
pfctl -F all
Änderung oder Entfernen von Docker-Regeln
Deaktivieren der Docker-Firewallverwaltung
Entfernen von Kubernetes- oder CNI-Regeln
Deaktivieren eines VPN-Filters
Beenden oder Deinstallieren von Endpoint Security
dauerhafte ungefilterte Paketprotokollierung

Ein vollständiges Deaktivieren der Firewall verändert den Sicherheitszustand, kann Richtlinien verletzen und liefert keinen präzisen Nachweis darüber, welche Regel den ursprünglichen Fehler verursacht hat.

Quellen

Offizielle Microsoft-Dokumentation

Offizielle Netfilter- und Linux-Dokumentation

Offizielle firewalld- und Ubuntu-Dokumentation

Offizielle Apple-Dokumentation

Offizielle Containerdokumentation

Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet.

9. TCP, UDP, Ports, Firewall, NAT und Proxy

9.5 Netzwerkfirewall, ACL-Reihenfolge und Stateful Inspection

Eine Netzwerkfirewall kontrolliert den Datenverkehr zwischen Netzen, Sicherheitszonen, Standorten, Cloud-Umgebungen oder einzelnen Netzsegmenten. Eine vorhandene Freigaberegel beweist jedoch noch nicht, dass der Datenverkehr tatsächlich erlaubt wird. Entscheidend sind unter anderem:

Diese Seite behandelt Netzwerkfirewalls und zentrale Netzwerk-ACLs. Die lokale Firewall eines Endgeräts oder Servers wurde bereits unter 9.4 Lokale Host-Firewall prüfen behandelt.

Ziele

Nach der Bearbeitung dieser Seite soll nachvollziehbar geprüft werden können:

Sicherheits- und Änderungsgrundsätze

Eine Netzwerkfirewall ist häufig ein zentraler Sicherheits- und Verfügbarkeitsbestandteil. Unkontrollierte Änderungen können viele Systeme gleichzeitig betreffen.

Vor jeder Änderung sind mindestens festzuhalten:

Nicht als erste Diagnosemaßnahme geeignet sind:

Eine kurzfristige Testregel muss genauso präzise wie eine dauerhafte Regel begrenzt werden. Sie benötigt:

Netzwerkfirewall und Host-Firewall unterscheiden

Merkmal Netzwerkfirewall Host-Firewall
Standort zwischen Netzen oder Sicherheitszonen direkt auf dem Endgerät oder Server
Sichtbarer Datenverkehr nur Verkehr, der die Firewall tatsächlich durchläuft ein- und ausgehender Verkehr des lokalen Systems
Typische Regeln Zonen, Netze, Adressen, Dienste, Anwendungen Programme, Dienste, Profile, lokale Ports, Benutzer
Zustandsverwaltung zentrale Sitzungstabelle lokale Verbindungstabelle
Protokollierung zentrale Firewall- und Sicherheitsprotokolle lokales Betriebssystemprotokoll
Häufige Fehlerquelle falsche Zone, Regelreihenfolge, NAT, Route, Sitzung falsches Profil, Dienstregel, Programmpfad
Umgehungsmöglichkeit lokales Routing oder direkter Pfad zwischen Systemen normalerweise nicht für lokalen Netzwerkverkehr

Eine Netzwerkfirewall kann nur Datenverkehr prüfen, der tatsächlich über sie geleitet wird. Befinden sich Quelle und Ziel beispielsweise im selben VLAN, kann der Verkehr die zentrale Firewall vollständig umgehen.

Vereinfachter Datenfluss

Ein typischer Datenfluss kann folgende Verarbeitungsschritte enthalten:

  1. Paket trifft auf einer Eingangsschnittstelle ein.
  2. Eingangszone oder Sicherheitskontext wird bestimmt.
  3. Vorhandene Sitzung wird gesucht.
  4. NAT- und Routingregeln werden ausgewertet.
  5. Ausgangsschnittstelle und Ausgangszone werden bestimmt.
  6. Sicherheitsregel wird ermittelt.
  7. Zusätzliche Prüfungen werden ausgeführt.
  8. Paket wird weitergeleitet oder verworfen.
  9. Eine neue Sitzung wird angelegt oder eine vorhandene aktualisiert.
  10. Rückverkehr wird einer Sitzung zugeordnet.
  11. Ereignisse, Zähler und Sitzungsdaten werden protokolliert.

Die genaue Reihenfolge von NAT, Routing, Sicherheitsrichtlinie, Anwendungserkennung und Inhaltsprüfung ist produktspezifisch. Sie muss für das eingesetzte Firewallprodukt und die verwendete Softwareversion geprüft werden.

Einen Datenfluss eindeutig beschreiben

Vor der Regelprüfung muss der betroffene Datenfluss vollständig beschrieben werden.

Beispiel:

Zeitpunkt:
2026-08-02 10:15:32 Europe/Berlin

Quelle:
192.0.2.100

Quellzone:
CLIENTS

Quellport:
53124

Ziel:
198.51.100.25

Zielzone:
SERVER

Zielport:
443

Protokoll:
TCP

Anwendung:
HTTPS-Zugriff auf app.example.test

Erwarteter Pfad:
CLIENTS -> FW-CLUSTER-01 -> SERVER

Erwartete Regel:
ALLOW-CLIENTS-APP-HTTPS

Erwartete NAT-Verarbeitung:
keine

Bei TCP und UDP wird ein Datenfluss typischerweise über das Fünf-Tupel beschrieben:

Quelladresse
Quellport
Zieladresse
Zielport
IP-Protokoll

Für die Firewalldiagnose kommen weitere Merkmale hinzu:

Quellport und Zielport nicht verwechseln

Bei einer üblichen Clientverbindung verwendet der Client einen dynamischen Quellport und der Server einen bekannten Zielport.

Beispiel:

192.0.2.100:53124 -> 198.51.100.25:443/TCP

Dabei gilt:

Feld Bedeutung
192.0.2.100 Clientadresse
53124 dynamischer Quellport des Clients
198.51.100.25 Serveradresse
443 Zielport des HTTPS-Dienstes

Eine Freigabe, die irrtümlich den Quellport 443 statt des Zielports 443 prüft, passt normalerweise nicht auf diesen Verbindungsaufbau.

Der Rückverkehr besitzt vertauschte Adressen und Ports:

198.51.100.25:443 -> 192.0.2.100:53124/TCP

Bei einer zustandsbehafteten Firewall wird dieser Rückverkehr üblicherweise über den bestehenden Sitzungszustand erlaubt. Bei einer zustandslosen ACL muss der Rückverkehr ausdrücklich berücksichtigt werden.

Eingehend und ausgehend richtig einordnen

Inbound, ingress, outbound und egress beziehen sich auf eine bestimmte Schnittstelle, Zone oder Ressource. Die Begriffe dürfen nicht ohne diesen Bezug verwendet werden.

Beispiel:

Clientnetz -> Firewall -> Servernetz

Aus Sicht der Firewall:

Bei Cloud-ACLs kann sich inbound oder outbound auf ein Subnetz, eine Netzwerkschnittstelle oder eine virtuelle Maschine beziehen. Deshalb müssen Ressource und Richtung immer gemeinsam dokumentiert werden.

Arten der Filterung

Verfahren Auswertung Sitzungszustand Typische Eigenschaft
zustandslose ACL jedes Paket einzeln nein Rückverkehr benötigt eigene passende Regel
Stateful Inspection Paket und bestehende Sitzung ja Rückverkehr bestehender Sitzungen wird zugeordnet
Proxy-Firewall beendet und vermittelt die Verbindung ja Client und Ziel kommunizieren nicht direkt miteinander
Application Firewall Anwendung oder Protokollinhalt ja Entscheidung kann von erkannter Anwendung abhängen
Next-Generation Firewall Netzwerk-, Sitzungs-, Benutzer- und Anwendungsdaten ja zusätzliche URL-, Malware-, IPS- oder TLS-Prüfung
Cloud Security Group ressourcenbezogene Regeln häufig ja Verhalten unterscheidet sich von Subnetz-ACLs
Cloud Network ACL subnetzbezogene Paketfilterung häufig nein Priorität und Rückregeln sind besonders wichtig

Die Produktbezeichnung allein reicht nicht zur Bewertung. Es muss geprüft werden, welche Regelkomponente den betroffenen Datenfluss tatsächlich verarbeitet.

ACL-Reihenfolge

Viele Netzwerkfirewalls und Router prüfen Regeln in einer definierten Reihenfolge. Häufig gilt:

  1. Regeln werden von oben nach unten oder nach Priorität geprüft.
  2. Die erste vollständig passende Regel bestimmt die Aktion.
  3. Nach einem Treffer werden nachfolgende Regeln nicht mehr geprüft.
  4. Trifft keine Regel zu, greift häufig eine implizite Standardaktion.

Dieses Verhalten ist verbreitet, aber nicht für jedes Produkt und jede Regelart identisch. Zu prüfen sind:

Beispiel für eine sinnvolle Reihenfolge

Anforderung:

Vereinfachte Regelreihenfolge:

10 deny   tcp 192.0.2.66/32  -> 198.51.100.25/32 port 443 log
20 permit tcp 192.0.2.0/24   -> 198.51.100.25/32 port 443 log
90 deny   ip  any            -> any                    log

Die spezifische Sperre steht vor der allgemeineren Freigabe.

Fehlerhafte Reihenfolge:

10 permit tcp 192.0.2.0/24   -> 198.51.100.25/32 port 443 log
20 deny   tcp 192.0.2.66/32  -> 198.51.100.25/32 port 443 log
90 deny   ip  any            -> any                    log

Wenn das Produkt nach dem ersten Treffer beendet, wird Host 192.0.2.66 bereits durch Regel 10 erlaubt. Regel 20 ist für diesen Datenfluss nicht erreichbar.

Überschattete, redundante und widersprüchliche Regeln

Regelproblem Beschreibung Auswirkung
überschattete Regel frühere allgemeinere Regel deckt alle Treffer der späteren Regel ab spätere Regel wird nie verwendet
teilweise überschattete Regel frühere Regel deckt einen Teil des späteren Bereichs ab Regel wirkt nur für den verbleibenden Teil
redundante Regel Regel erlaubt oder verbietet bereits identisch behandelten Verkehr unnötige Komplexität
widersprüchliche Regel gleiche oder überlappende Kriterien besitzen andere Aktion Ergebnis hängt von Reihenfolge ab
veraltete Regel zugehöriger Dienst oder Eigentümer existiert nicht mehr unnötige Angriffsfläche
ungebundene ACL ACL ist definiert, aber keiner Schnittstelle oder Zone zugeordnet keine Wirkung
falscher Kontext Regel liegt in anderem Mandanten oder virtuellen System keine Wirkung auf den betroffenen Verkehr
falsche Richtung Regel ist für Gegenrichtung angelegt erwarteter Verbindungsaufbau bleibt blockiert
falsche Adressphase Regel verwendet falsche NAT-Adresse kein Treffer
falsche Regelart Netzwerkregel statt Anwendungsregel oder umgekehrt unerwartete Verarbeitung

Regelanalysen des Herstellers können bei der Erkennung helfen. Das Ergebnis muss trotzdem mit realen Trefferzählern, Protokollen und einem kontrollierten Verbindungstest bestätigt werden.

Implizite Standardaktion

Viele ACL- und Firewallregelwerke besitzen am Ende eine implizite Verweigerung. Diese Regel ist möglicherweise nicht als normale Konfigurationszeile sichtbar.

Vereinfachtes Modell:

permit <ausdrücklich erlaubter Verkehr>
deny   <ausdrücklich gesperrter Verkehr>
deny   any any <implizit>

Ein explizites abschließendes Verbot mit Protokollierung kann die Diagnose erleichtern:

deny any any log

Ob eine solche Regel sinnvoll und zulässig ist, hängt vom Produkt und der Protokollierungsleistung ab. Eine stark ausgelastete abschließende Protokollregel kann sehr viele Ereignisse erzeugen.

Zu prüfen sind:

Ein fehlender sichtbarer deny-Eintrag beweist nicht, dass nicht passender Verkehr erlaubt wird.

Regelkriterien vollständig prüfen

Eine moderne Firewall kann deutlich mehr als nur IP-Adresse und Port auswerten.

Kriterium Zu prüfender Punkt
Quellzone stimmt die Zone der tatsächlichen Eingangsschnittstelle?
Zielzone entspricht sie der durch Routing bestimmten Ausgangszone?
Quelladresse Originaladresse, NAT-Adresse oder Adressobjekt?
Zieladresse Originalziel oder übersetztes Ziel?
Quellport dynamischer Port oder fest definierter Dienstport?
Zielport tatsächlich verwendeter Dienstport?
Protokoll TCP, UDP, ICMP, ESP, GRE oder anderes IP-Protokoll?
Anwendung bereits erkannt, noch unbekannt oder verschlüsselt?
Dienst fest definierter Port oder anwendungsabhängiger Standardport?
Benutzer konnte die Firewall die Identität ermitteln?
Gerät passt die Geräte- oder Endpunktklassifizierung?
Zeitplan ist die Regel zum Fehlerzeitpunkt aktiv?
URL-Kategorie wird das Ziel einer anderen Kategorie zugeordnet?
FQDN-Objekt auf welche Adressen wurde der Name aufgelöst?
Sicherheitsprofil Malware-, IPS-, Datei- oder URL-Prüfung aktiv?
Mandant richtiger virtueller Router oder Firewallkontext?
VPN gilt eine zusätzliche VPN- oder Tunnelregel?

Eine Regel kann auf Netzwerkebene allow ergeben und anschließend trotzdem durch ein Sicherheitsprofil blockiert werden.

Adress- und Dienstobjekte prüfen

Regeln verwenden häufig Objekte statt direkt eingetragener IP-Adressen und Ports.

Zu prüfen sind:

Beispiel für eine häufige Netzmaskenverwechslung:

192.0.2.0/24

umfasst:

192.0.2.0 bis 192.0.2.255

Dagegen umfasst:

192.0.2.100/32

nur die einzelne Adresse:

192.0.2.100

Bei Produkten mit Wildcard-Masken ist die Schreibweise nicht mit einer normalen Subnetzmaske gleichzusetzen.

FQDN- und dynamische Objekte

Ein FQDN-Objekt kann von der Firewall regelmäßig in eine oder mehrere IP-Adressen aufgelöst werden.

Zu prüfen sind:

Ein Client und eine Firewall können denselben FQDN zu unterschiedlichen Zieladressen auflösen. Dann kann eine scheinbar passende FQDN-Regel den tatsächlichen Clientverkehr verfehlen.

Stateful Inspection

Eine zustandsbehaftete Firewall bewertet nicht jedes Paket vollständig unabhängig. Sie führt eine Sitzungstabelle und ordnet weitere Pakete einem bekannten Datenfluss zu.

Vereinfachter TCP-Ablauf:

  1. Client sendet SYN.
  2. Firewall findet keine vorhandene Sitzung.
  3. Firewall prüft Route, Zone, NAT und Richtlinie.
  4. Bei Erlaubnis wird ein Sitzungseintrag angelegt.
  5. Server sendet SYN, ACK.
  6. Firewall ordnet das Paket der bestehenden Sitzung zu.
  7. Client sendet ACK.
  8. Sitzung wechselt in den etablierten Zustand.
  9. Weitere Pakete werden anhand der Sitzung verarbeitet.
  10. FIN, RST oder Timeout beendet die Sitzung.

Eine zustandsbehaftete Firewall kann Pakete verwerfen, wenn diese nicht zum erwarteten Zustand passen, beispielsweise:

Typische Daten eines Sitzungseintrags

Ein Sitzungseintrag kann unter anderem enthalten:

Sitzungs-ID
Protokoll
Quellzone
Zielzone
Eingangsschnittstelle
Ausgangsschnittstelle
Original-Quelladresse
Original-Quellport
Original-Zieladresse
Original-Zielport
übersetzte Quelladresse
übersetzter Quellport
übersetzte Zieladresse
übersetzter Zielport
passende Regel
Anwendung
TCP-Zustand
Startzeit
letzte Aktivität
Timeout
gesendete Pakete
empfangene Pakete
gesendete Bytes
empfangene Bytes
Sitzungsendgrund
Clusterbesitzer

Die Sitzungstabelle ist ein wichtiger Nachweis, ersetzt aber nicht die Prüfung der tatsächlichen Anwendung.

Eine vorhandene Sitzung beweist nur, dass die Firewall einen Zustand führt. Sie beweist nicht automatisch:

Zustandslos und zustandsbehaftet vergleichen

Prüfpunkt Zustandslose ACL Stateful Firewall
Verarbeitung jedes Paket einzeln Paket plus Sitzungszustand
Rückverkehr benötigt passende Gegenregel bestehender Sitzung zugeordnet
TCP-Zustand normalerweise nicht vollständig verfolgt Handshake und Status werden verfolgt
UDP jedes Datagramm nach Regel häufig zeitlich begrenzte Pseudositzung
ICMP eigene Regeln pro Richtung erforderlich kann Anfrage und Antwort zuordnen
Asymmetrischer Pfad Regel kann trotzdem passen häufig Sitzungsproblem
Ressourcenverbrauch geringer Sitzungstabelle benötigt Speicher
Timeoutwirkung keine Sitzung Rückverkehr kann nach Ablauf verworfen werden
Regeländerung wirkt auf folgende Pakete bestehende Sitzungen können abweichend behandelt werden

Das Verhalten bei Regeländerungen und bestehenden Sitzungen ist produktspezifisch. Einige Systeme prüfen bestehende Sitzungen nicht sofort erneut, andere beenden betroffene Sitzungen oder bewerten bestimmte Eigenschaften erneut.

TCP-Verkehr prüfen

Bei TCP sind mindestens folgende Punkte zu unterscheiden:

Befundbeispiele:

Paketfolge Mögliche Einordnung
wiederholte SYN, keine Antwort Paketverlust, Firewall-Drop, falsche Route oder Server antwortet nicht
SYN, danach sofortiges RST Ziel lehnt aktiv ab oder Zwischenkomponente erzeugt Reset
SYN, SYN-ACK, anschließend kein ACK Rückweg zum Client oder Clientseite prüfen
vollständiger Handshake, danach sofortiger RST Anwendung, Proxy, Sicherheitsprofil oder Protokollproblem
Daten nur in eine Richtung Rückweg, asymmetrischer Pfad oder Sicherheitsprüfung
Sitzung in Firewall vorhanden, keine Serverantwort Zielsystem, nachgelagerte Firewall oder Route prüfen

UDP-Verkehr prüfen

UDP besitzt keinen TCP-Handshake. Stateful Firewalls führen deshalb häufig eine zeitlich begrenzte Pseudositzung.

Beispiel:

192.0.2.100:54000 -> 198.51.100.53:53/UDP

Die Firewall kann anschließend eine passende Antwort erlauben:

198.51.100.53:53 -> 192.0.2.100:54000/UDP

Zu prüfen sind:

Ein vorhandener UDP-Sitzungseintrag beweist keine erfolgreiche Anwendungskommunikation.

ICMP und ICMPv6 prüfen

ICMP transportiert nicht nur Echo-Anfrage und Echo-Antwort, sondern auch wichtige Fehlermeldungen.

Beispiele:

Zu prüfen sind:

Das pauschale Blockieren von ICMP kann Diagnose, Path-MTU-Discovery und besonders IPv6-Funktionen beeinträchtigen.

Sitzungstimeouts

Stateful Firewalls entfernen inaktive Sitzungen nach definierten Zeiträumen.

Zu prüfen sind:

Typische Symptome eines Timeoutproblems:

Ein Timeout sollte nur geändert werden, wenn der zeitliche Zusammenhang nachgewiesen wurde. Eine pauschale Erhöhung kann den Speicherverbrauch und die Anzahl gleichzeitig geführter Sitzungen vergrößern.

Bestehende Sitzungen bei Regeländerungen

Nach einer Regeländerung sind neue und bestehende Verbindungen getrennt zu prüfen.

Mögliche produktabhängige Verhaltensweisen:

Deshalb muss ein Test dokumentieren:

Test A:
bereits vor der Änderung bestehende Verbindung

Test B:
nach der Änderung vollständig neu aufgebaute Verbindung

Wenn ein neuer Test erforderlich ist, sollte nur die einzelne betroffene Anwendungssitzung kontrolliert beendet werden. Das vollständige Löschen der Sitzungstabelle ist unverhältnismäßig und kann viele produktive Verbindungen unterbrechen.

Routing und Zielzone

Die Zielzone wird bei vielen Firewalls anhand der Ausgangsschnittstelle oder Routingentscheidung bestimmt.

Zu prüfen sind:

Eine Sicherheitsregel kann inhaltlich korrekt aussehen, aber nicht passen, wenn die Firewall aufgrund einer falschen Route eine andere Zielzone bestimmt.

Beispiel:

Erwartet:
CLIENTS -> SERVER

Tatsächlich:
CLIENTS -> WAN

In diesem Fall ist nicht zuerst die Regel CLIENTS -> SERVER zu verändern. Zunächst muss geklärt werden, warum die Route zur falschen Ausgangszone führt.

NAT und Sicherheitsrichtlinie

NAT kann Adressen und Ports verändern.

Beispiel einer Zielübersetzung:

Original:
203.0.113.40:55000 -> 198.51.100.10:443

Nach DNAT:
203.0.113.40:55000 -> 10.20.30.40:8443

Beispiel einer Quellübersetzung:

Original:
10.10.20.25:53124 -> 203.0.113.80:443

Nach SNAT:
198.51.100.5:61001 -> 203.0.113.80:443

Für die Diagnose sind beide Ansichten zu dokumentieren:

Merkmal Vor NAT Nach NAT
Quelladresse ursprünglicher Absender übersetzte Quelladresse
Quellport ursprünglicher Quellport übersetzter Quellport
Zieladresse aufgerufene Zieladresse internes oder übersetztes Ziel
Zielport aufgerufener Zielport übersetzter Zielport

Je nach Hersteller, Regelart und Richtung kann die Sicherheitsrichtlinie vor oder nach einer bestimmten NAT-Verarbeitung ausgewertet werden. Es darf nicht angenommen werden, dass eine Firewallregel immer die öffentliche oder immer die private Adresse verwenden muss.

Zu prüfen sind:

Eine passende Sicherheitsregel kann durch eine falsche NAT-Regel wirkungslos bleiben.

Zonen und virtuelle Kontexte

Viele Firewalls besitzen:

Zu prüfen sind:

Eine Regel in einem anderen virtuellen Kontext kann denselben Namen besitzen, aber für den betroffenen Datenverkehr vollständig wirkungslos sein.

Zusätzliche Sicherheitsprüfungen

Eine Regel mit der Aktion allow bedeutet bei modernen Firewalls häufig nur, dass der Datenfluss weiter geprüft werden darf.

Weitere mögliche Prüfungen:

Deshalb sind mindestens zwei Entscheidungen zu unterscheiden:

Netzwerkregel:
allow

Sicherheitsprofil:
block

Im Protokoll können dafür mehrere Einträge entstehen. Ein allow-Ereignis darf nicht isoliert als Nachweis einer erfolgreichen Verbindung bewertet werden.

Application-Awareness

Eine anwendungsbasierte Firewall kann eine Sitzung zunächst anhand des Ports behandeln und später die erkannte Anwendung berücksichtigen.

Zu prüfen sind:

Beispiel:

TCP-Port:
443

Erkannte Anwendung:
quic

Erwartete Anwendung:
ssl/web-browsing

Eine reine Portfreigabe sagt nicht aus, welche Anwendung tatsächlich transportiert wird.

Regelbindung prüfen

Eine definierte ACL oder Policy wirkt nur, wenn sie an der richtigen Stelle eingebunden ist.

Zu prüfen sind:

Beispielbefund:

ACL:
WEB-IN

Konfiguriert:
ja

Gebunden an:
DMZ-Schnittstelle eingehend

Tatsächlicher Verkehr:
tritt an WAN-Schnittstelle ein

Ergebnis:
ACL WEB-IN verarbeitet diesen Datenfluss nicht

Aktive und gespeicherte Konfiguration unterscheiden

Je nach Produkt können unterschiedliche Konfigurationsstände existieren:

Zu prüfen sind:

Eine im Managementsystem sichtbare Regel beweist nicht, dass sie bereits auf der Datenebene aktiv ist.

Hochverfügbarkeit und Cluster

Bei einem Firewallcluster sind zusätzlich zu prüfen:

Typischer Fehler:

Hinverkehr:
FW-A

Rückverkehr:
FW-B

Sitzungssynchronisation:
fehlerhaft

FW-B kennt die durch FW-A aufgebaute Sitzung möglicherweise nicht und verwirft den Rückverkehr als ungültig.

Asymmetrische Pfade und Connection Tracking werden in 9.6 Asymmetrische Pfade, Sessiontabellen und Connection Tracking weiter vertieft.

Cloud-Firewalls und Cloud-ACLs

Cloud-Plattformen können mehrere Filterebenen kombinieren:

Diese Ebenen müssen einzeln geprüft werden.

AWS Security Groups und Network ACLs

Merkmal AWS Security Group AWS Network ACL
Zuordnung Netzwerkschnittstelle oder Ressource Subnetz
Zustand stateful stateless
Regeln Freigaberegeln Erlauben und Verweigern
Rückverkehr für verfolgte Verbindung automatisch berücksichtigt muss durch Gegenregel erlaubt werden
Reihenfolge keine klassische First-Match-Reihenfolge der Freigaberegeln nach Regelnummer
Diagnosefokus tatsächlich zugeordnete Gruppen tatsächlich zugeordnete Subnetz-ACL
Ephemeral Ports Rückverkehr durch Zustand ausdrücklich berücksichtigen

Bei einer AWS Network ACL muss beispielsweise für eine eingehend erlaubte TCP-Verbindung auch der ausgehende Rückverkehr zum dynamischen Clientport erlaubt sein.

Vereinfachtes Beispiel:

Inbound:
TCP von 192.0.2.0/24 zu Zielport 443 erlauben

Outbound:
TCP zu 192.0.2.0/24 und benötigtem dynamischem Clientportbereich erlauben

Der tatsächlich verwendete Portbereich hängt vom Clientbetriebssystem, der Anwendung und gegebenenfalls weiteren NAT-Komponenten ab.

Azure Network Security Groups

Azure Network Security Groups arbeiten zustandsbehaftet und verwenden Regeln mit Prioritätswerten.

Grundprinzip:

kleinere Prioritätszahl = höhere Priorität

Beispiel:

Priorität 100:
Deny TCP 192.0.2.66 -> 10.20.30.40:443

Priorität 200:
Allow TCP 192.0.2.0/24 -> 10.20.30.40:443

Zu prüfen sind:

Bei eingehendem Verkehr verarbeitet eine Azure NSG die Regeln nach der Übersetzung einer öffentlichen in eine private IP-Adresse. Bei ausgehendem Verkehr erfolgt die NSG-Verarbeitung vor der Übersetzung einer privaten in eine öffentliche Adresse.

Netzwerkregel und Anwendungsfirewall unterscheiden

Eine Netzwerkfirewall prüft typischerweise IP-Adressen, Ports, Protokolle, Sitzungen und gegebenenfalls Anwendungen.

Eine Web Application Firewall prüft dagegen HTTP- oder HTTPS-Anfragen auf Anwendungsebene.

Beispiel:

Netzwerkfirewall:
TCP 443 erlaubt

Web Application Firewall:
HTTP-Anfrage wegen Regelverletzung blockiert

Ein erfolgreicher TCP-Handshake bis zum Reverse Proxy beweist daher nicht, dass die Webanwendung die Anfrage akzeptiert.

Ausgangszustand erfassen

Vor Veränderungen sind folgende Informationen zu sichern:

Datum und Uhrzeit
Zeitzone
Clientname und Clientadresse
Servername und Serveradresse
Quellport
Zielport
Protokoll
Anwendung
exakte Fehlermeldung
betroffener Benutzer
Eingangs- und Ausgangszone
erwarteter Firewallpfad
aktiver Firewallknoten
Regelname und Regel-ID
NAT-Regel
Sitzungs-ID
Policy-Version
Logeinträge
Trefferzähler
Paketaufzeichnungen

Die Uhren von Client, Server, Firewall und zentralem Protokollsystem müssen ausreichend synchronisiert sein. Andernfalls können zusammengehörige Ereignisse falsch zugeordnet werden.

Fehlerumfang bestimmen

Zu klären ist:

Ein präzise begrenzter Fehlerumfang verhindert unnötig weitreichende Regeländerungen.

Firewallpfad nachweisen

Der vorgesehene Firewallpfad darf nicht nur aus dem Netzplan abgeleitet werden.

Mögliche Nachweise:

Zu beachten ist, dass Traceroute nicht jede Firewall sichtbar macht. Eine transparente Firewall oder ein Gerät, das TTL-Abläufe nicht beantwortet, kann im Traceroute fehlen.

Regelwerk zunächst nur lesend prüfen

Zu erfassen sind:

Ein Screenshot allein ist kein idealer technischer Nachweis. Wenn möglich, sollten zusätzlich exportierbare Text- oder Konfigurationsdaten mit Zeitstempel gesichert werden. Dabei sind Zugangsdaten, Schlüssel und andere schützenswerte Informationen zu entfernen.

Trefferzähler richtig auswerten

Ein Trefferzähler kann zeigen, dass Verkehr eine Regel erreicht hat. Er muss jedoch vorsichtig interpretiert werden.

Zu beachten sind:

Belastbarer Ablauf:

  1. aktuellen Zählerstand mit Uhrzeit dokumentieren;
  2. genau einen kontrollierten Test ausführen;
  3. Zähler erneut ablesen;
  4. Differenz bewerten;
  5. gleichzeitig Firewallprotokoll und Anwendungsergebnis prüfen.

Zähler dürfen erst nach der Beweissicherung und nur mit Freigabe zurückgesetzt werden.

Firewallprotokolle auswerten

Ein brauchbarer Protokolleintrag enthält möglichst:

Nach exakt diesen Merkmalen sollte gefiltert werden:

source = 192.0.2.100
destination = 198.51.100.25
destination_port = 443
protocol = TCP
time = 2026-08-02 10:15:00 bis 10:16:00

Ein fehlender Logeintrag beweist nicht automatisch, dass die Firewall den Datenfluss nicht gesehen hat. Mögliche Gründe:

Erlaubt-, Verworfen- und Sitzungsendgründe unterscheiden

Mögliche Aktionen und Endgründe:

Befund Mögliche Bedeutung
allow Netzwerkregel hat den Datenfluss zugelassen
deny Sicherheitsregel hat den Datenfluss verworfen
drop Paket wurde ohne aktive Ablehnungsantwort verworfen
reject Firewall sendet eine aktive Ablehnungsantwort
reset-client Firewall sendet TCP-RST zum Client
reset-server Firewall sendet TCP-RST zum Server
aged-out Sitzung ist durch Timeout abgelaufen
tcp-rst-from-client Client hat die Sitzung beendet
tcp-rst-from-server Server hat die Sitzung beendet
policy-deny Richtlinie hat den Aufbau blockiert
threat oder ips-drop Sicherheitsprofil hat blockiert
decrypt-error TLS-Entschlüsselung ist fehlgeschlagen
resources-unavailable Kapazitäts- oder Ressourcengrenze
invalid-state Paket passt nicht zum erwarteten Sitzungszustand
no-route keine verwendbare Route
nat-failure NAT-Verarbeitung ist fehlgeschlagen

Die genaue Benennung ist herstellerspezifisch.

Policy-Match- und Packet-Tracer-Werkzeuge

Viele Hersteller bieten Werkzeuge an, die einen hypothetischen Datenfluss gegen die aktuelle Konfiguration prüfen.

Benötigte Eingaben:

Eingangsschnittstelle
Quellzone
Quelladresse
Quellport
Zieladresse
Zielport
Protokoll
Benutzer oder Anwendung, sofern erforderlich

Solche Werkzeuge können unter anderem zeigen:

Ein Simulationsergebnis beweist nicht:

Die Simulation muss mit einem realen Test, Protokollen und gegebenenfalls Paketaufzeichnungen kombiniert werden.

Cisco IOS ACLs lesend prüfen

Beispielbefehle:

show ip access-lists

show ip access-lists <ACL-Name-oder-Nummer>

show running-config | section access-list

show running-config | include ip access-group

show ip interface

Zu prüfen sind:

Die genaue Syntax hängt von Plattform und Softwareversion ab.

Cisco Secure Firewall ASA lesend prüfen

ACLs und Bindungen:

show access-list

show access-group

Verbindungen und NAT:

show conn

show conn address 192.0.2.100

show xlate

Routing:

show route

Simulation eines TCP-Pakets:

packet-tracer input inside tcp 192.0.2.100 53124 198.51.100.25 443 detailed

Drop-Zähler:

show asp drop

show asp drop liefert interne Drop-Zähler und ist für gezielte Fehleranalysen vorgesehen. Die Ausgabe ist umfangreich und muss zeitlich mit einem kontrollierten Test korreliert werden.

Bei Cisco ASA verwenden normale Zugriffsregeln für NAT-Verkehr die reale Adresse des Ziels. Dieses Verhalten darf nicht ungeprüft auf andere Firewallprodukte übertragen werden.

Juniper SRX lesend prüfen

Beispielbefehle:

show security policies

show security policies hit-count

show security flow session

show security flow session source-prefix 192.0.2.100

show security flow session destination-prefix 198.51.100.25

show route 198.51.100.25

Für eine Richtlinienzuordnung kann abhängig von Junos-Version und Konfiguration show security match-policies verwendet werden. Die vollständige lokale Syntax ist mit der CLI-Hilfe zu prüfen.

Juniper-Sicherheitsrichtlinien werden innerhalb des zutreffenden Zonenkontexts in Reihenfolge ausgewertet. Die erste passende Richtlinie bestimmt die Aktion.

Palo Alto Networks lesend prüfen

Sitzungssuche:

show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443

Routingprüfung:

test routing fib-lookup virtual-router <Routername> ip 198.51.100.25

Policy-Match-Tests und genaue Filteroptionen sind versionsabhängig. Vor der Ausführung ist die lokale CLI-Hilfe zu verwenden:

test security-policy-match ?

show session all filter ?

Bei der Auswertung sind unter anderem zu prüfen:

Palo-Alto-Sicherheitsregeln werden innerhalb der Regelbasis von oben nach unten ausgewertet. Die erste passende Regel wird angewendet. Spezifische Regeln müssen daher vor allgemeineren Regeln stehen.

Linux als Netzwerkfirewall lesend prüfen

Wenn ein Linux-System als Router oder Firewall eingesetzt wird, können abhängig von der Konfiguration folgende Prüfungen relevant sein.

Aktives nftables-Regelwerk:

sudo nft list ruleset

Regelwerk mit Handles:

sudo nft -a list ruleset

Routing:

ip route show

ip -6 route show

Weiterleitungseinstellung:

sysctl net.ipv4.ip_forward

sysctl net.ipv6.conf.all.forwarding

Connection Tracking, sofern das Werkzeug vorhanden ist:

sudo conntrack -L

Gezielte Suche:

sudo conntrack -L \
  -s 192.0.2.100 \
  -d 198.51.100.25 \
  -p tcp

Zu beachten sind:

Das Löschen von Conntrack-Einträgen ist eine verändernde Maßnahme und darf nicht als erster Diagnoseschritt erfolgen.

Paketaufzeichnung an der Firewall

Eine Paketaufzeichnung ist sinnvoll, wenn nicht eindeutig ist:

Idealer Vergleich:

Aufzeichnung A:
Eingangsschnittstelle

Aufzeichnung B:
Ausgangsschnittstelle

Befundbeispiele:

Eingang Ausgang Einordnung
Paket nicht sichtbar Paket nicht sichtbar Pfad vor der Firewall prüfen
Paket sichtbar Paket nicht sichtbar Firewallverarbeitung, Regel, NAT oder Route prüfen
Paket mit übersetztem Ziel sichtbar Paket erreicht Server Firewall hat Hinverkehr weitergeleitet
Serverantwort am Ausgangsnetz sichtbar Antwort nicht zum Clientnetz Firewallzustand, NAT oder Rückroute prüfen
vollständiger Verkehr auf beiden Seiten Client meldet trotzdem Fehler Host, Anwendung, Proxy oder TLS prüfen

Bei Hardware-Offloading kann eine allgemeine Paketaufzeichnung möglicherweise nicht alle weitergeleiteten Pakete zeigen. Dann sind herstellerspezifische Capture-Funktionen, Dataplane-Diagnosen oder ein externer SPAN/TAP erforderlich.

Aufzeichnungen müssen:

werden.

Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Die allgemeine Freigaberegel mit Priorität 100 erlaubt das gesamte
Clientnetz und überschattet die nachfolgende Sperrregel für
192.0.2.66.

Erwarteter Befund:
Ein Policy-Match-Test für 192.0.2.66 -> 198.51.100.25:443 nennt
die allgemeine Freigaberegel. Der Trefferzähler der Sperrregel
ändert sich beim Test nicht.

Gegenbeweis:
Der reale Datenfluss trifft nachweislich die Sperrregel und wird
durch diese verworfen.

Testmethode:
Policy-Match, kontrollierter Verbindungsversuch, Regelzähler und
Firewallprotokoll zeitlich korrelieren.

Risiko:
Nur lesende Diagnose; keine Auswirkung auf Produktivverkehr.

Erfolgskriterium:
Tatsächlich angewendete Regel ist mit Regel-ID und Logeintrag
eindeutig nachgewiesen.

Weitere mögliche Hypothesen:

Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko Rückweg
Regelreihenfolge korrigieren Überschattung nachgewiesen andere Datenflüsse können anders behandelt werden vorherige Reihenfolge wiederherstellen
spezifische Freigabe ergänzen fehlende Freigabe bestätigt zusätzliche Angriffsfläche neue Regel deaktivieren oder entfernen
Adressobjekt korrigieren Objektinhalt nachweislich falsch alle Regeln mit diesem Objekt betroffen vorherigen Objektstand wiederherstellen
Dienstobjekt korrigieren Port oder Protokoll falsch weitere Anwendungen können betroffen sein vorherige Definition wiederherstellen
Zonenbezug korrigieren tatsächlicher Pfad nachgewiesen Segmentierungswirkung ändert sich vorherige Zonenregel wiederherstellen
NAT-Regel korrigieren Übersetzungsfehler bestätigt Erreichbarkeit und Rückweg ändern sich vorherige NAT-Regel aktivieren
Route korrigieren falsche Ausgangszone oder falscher Next Hop viele Ziele können betroffen sein vorherige Route wiederherstellen
Logging aktivieren fehlende Beweisdaten zusätzliche Last und Datenmenge Logging zurücknehmen
einzelne Sitzung beenden alte Sitzung beeinflusst Test eine produktive Verbindung wird unterbrochen Anwendung baut neue Sitzung auf
Timeout anpassen zeitabhängiger Sitzungsabbruch nachgewiesen höhere Sitzungsanzahl und Ressourcennutzung alten Timeoutwert wiederherstellen
Sicherheitsprofil korrigieren Fehlklassifizierung nachgewiesen Schutzwirkung kann sinken vorheriges Profil wiederherstellen
Cluster-Synchronisation reparieren Zustandsabweichung nachgewiesen Failover- und Sitzungsrisiko herstellerspezifischer Rückfallplan

Eine allgemeine Testfreigabe ist kein geeigneter Ersatz für eine präzise Ursachenanalyse.

Vollständiger Diagnoseablauf

  1. Exakte Fehlermeldung, Anwendung, Client, Benutzer und Uhrzeit dokumentieren.
  2. Quelladresse und tatsächlichen Quellport bestimmen.
  3. Zieladresse, Zielport und Protokoll bestimmen.
  4. IPv4 und IPv6 unterscheiden.
  5. Erwarteten Datenfluss und Sollzustand dokumentieren.
  6. Umfang der Störung bestimmen.
  7. Host-Firewalls als eigene Filterebenen berücksichtigen.
  8. Direkte Erreichbarkeit und Dienstzustand prüfen.
  9. Erwarteten Netzwerkpfad dokumentieren.
  10. Tatsächlichen Firewallpfad nachweisen.
  11. Aktiven Firewall- oder Clusterknoten bestimmen.
  12. Richtigen Mandanten und virtuellen Kontext bestimmen.
  13. Eingangs- und Ausgangsschnittstelle bestimmen.
  14. Quell- und Zielzone bestimmen.
  15. Route zur Zieladresse prüfen.
  16. Policy-Based Routing, VRF und Tunnel berücksichtigen.
  17. Originaladressen und Originalports dokumentieren.
  18. NAT-Adressen und NAT-Ports dokumentieren.
  19. Aktive NAT-Regel bestimmen.
  20. Aktive Sicherheitsrichtlinie bestimmen.
  21. Regelreihenfolge und Prioritäten prüfen.
  22. Globale, geerbte und lokale Regeln berücksichtigen.
  23. Implizite Standardaktion bestimmen.
  24. Adress-, Dienst- und FQDN-Objekte auflösen.
  25. Zeitpläne und Identitätskriterien prüfen.
  26. Anwendungs- und Sicherheitsprofile prüfen.
  27. Policy-Match- oder Packet-Tracer-Test durchführen.
  28. Ergebnis nicht mit realem Durchsatz gleichsetzen.
  29. Regelzähler mit Ausgangswert dokumentieren.
  30. Genau einen kontrollierten Verbindungstest ausführen.
  31. Zähleränderung und Protokolle auswerten.
  32. Sitzungstabelle prüfen.
  33. TCP-, UDP- oder ICMP-Zustand auswerten.
  34. Pakete und Bytes je Richtung vergleichen.
  35. Sitzungsendgrund auswerten.
  36. Bestehende und neue Sitzung unterscheiden.
  37. Bei Bedarf Eingangs- und Ausgangsaufzeichnung durchführen.
  38. Hin- und Rückverkehr vergleichen.
  39. Cluster- und Zustandssynchronisation prüfen.
  40. Weitere Cloud- oder Subnetz-ACLs prüfen.
  41. Hypothese, erwarteten Befund und Gegenbeweis formulieren.
  42. Genau eine kontrollierte Maßnahme vorbereiten.
  43. Risiko, Rückweg und Erfolgskriterium dokumentieren.
  44. Maßnahme freigeben und umsetzen.
  45. Neue Verbindung mit identischen Parametern testen.
  46. Regel, Sitzung, Pakete, Bytes und Anwendungsergebnis verifizieren.
  47. Repräsentative weitere Datenflüsse auf Nebenwirkungen prüfen.
  48. Temporäre Logging- und Testregeln zurücknehmen.
  49. Ursache, Maßnahme und Prävention dokumentieren.

Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
kein Firewalllog falscher Pfad, Logging deaktiviert oder früher Drop Route, Capture und Regelprotokollierung prüfen
deny durch erwartete Regel Freigabe fehlt oder Regelinhalt falsch Regelkriterien und Sollzustand vergleichen
deny durch andere Regel Überschattung oder falscher Kontext Reihenfolge und Priorität prüfen
implizites deny keine ausdrückliche Regel passt Zonen, Adressen, Protokoll und Ports prüfen
Allow-Regel hat Zähler null Verkehr trifft Regel nicht Pfad, Bindung, Kontext und Objekte prüfen
Allow-Regel zählt, Anwendung scheitert späterer Filter, Rückweg oder Anwendung Sitzungsende, Sicherheitsprofil und Capture
nur Hinpakete gezählt Rückweg oder Serverantwort fehlt Serverseite und Rückroute prüfen
Pakete in beide Richtungen, null Nutzdaten Handshake- oder Anwendungsproblem TCP-Flags, TLS und Anwendung prüfen
Sitzung aged-out keine Antwort oder Idle-Timeout Paketfluss und Timeoutdauer prüfen
Sitzung endet mit Server-RST Server oder Zwischenkomponente lehnt ab servernahe Aufzeichnung und Dienstprotokoll
Sitzung endet mit Client-RST Client oder Anwendung beendet Clientaufzeichnung und Anwendungsprotokoll
Policy-Test erlaubt, reales Paket fehlt Firewall wird nicht erreicht vorgelagertes Routing und Filter prüfen
Policy-Test erlaubt, reales Paket wird verworfen zusätzliche Prüfung oder Zustand Drop-Grund und Sicherheitsprofil
Zielzone unerwartet Route oder VRF falsch Routingentscheidung prüfen
NAT-Ziel unerwartet falsche oder frühere NAT-Regel NAT-Reihenfolge und Übersetzungstabelle
neue Verbindung scheitert, alte funktioniert neue Richtlinie oder NAT-Entscheidung alte und neue Sitzung vergleichen
alte Verbindung scheitert, neue funktioniert veralteter Sitzungszustand gezielt einzelne Sitzung untersuchen
nur UDP-Rückverkehr fehlt stateless ACL oder Timeout Gegenrichtung und UDP-Sitzung prüfen
nur große Pakete scheitern MTU, Fragmentierung oder ICMP-Block Paketgröße und ICMP-Fehler prüfen
nur IPv6 scheitert fehlende IPv6-Regel oder Route IPv6-Regelwerk und ip -6 route
nur ein Clusterknoten betroffen Konfigurations- oder Zustandsabweichung Knoten direkt vergleichen
AWS Security Group erlaubt, Verkehr scheitert NACL, Route, Hostfilter oder Dienst alle Filterebenen prüfen
AWS NACL erlaubt Hinweg, Rückweg fehlt zustandslose Rückregel fehlt dynamischen Rückportbereich prüfen
Azure NSG-Regel vorhanden, trifft nicht Priorität oder andere NSG effektive Regeln an NIC und Subnetz
allow, danach Threat-Drop Sicherheitsprofil blockiert Bedrohungs- oder IPS-Protokoll
FQDN-Regel trifft nicht andere DNS-Auflösung Firewall- und Clientauflösung vergleichen
nur bestimmte Uhrzeit betroffen Regelzeitplan oder automatisches Deployment Zeitplan und Änderungsprotokoll
nur nach Failover betroffen Sitzungs- oder NAT-Synchronisation HA-Status und neue Sitzung prüfen

Typische Diagnosefehler

Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Eine erfolgreiche Policy-Simulation oder ein einzelner steigender Regelzähler ist keine ausreichende Gesamtverifikation.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Datum und Uhrzeit:
<Zeitpunkt mit Zeitzone>

Betroffene Anwendung:
<Anwendung oder Dienst>

Quelle:
<Hostname, IP-Adresse und Quellport>

Ziel:
<Hostname, IP-Adresse und Zielport>

Protokoll:
<TCP, UDP, ICMP oder anderes IP-Protokoll>

Erwarteter Pfad:
<Zonen, Router, Firewall und Zielnetz>

Tatsächlicher Pfad:
<nachgewiesener Pfad>

Firewall:
<Gerät, Cluster und aktiver Knoten>

Virtueller Kontext:
<Mandant, VSYS, VRF oder Security Context>

Eingang:
<Schnittstelle und Quellzone>

Ausgang:
<Schnittstelle und Zielzone>

Originaldatenfluss:
<Quell-IP:Port -> Ziel-IP:Port>

Übersetzter Datenfluss:
<NAT-Quell-IP:Port -> NAT-Ziel-IP:Port>

Routingentscheidung:
<Ausgangsschnittstelle und nächster Hop>

Erwartete Regel:
<Name und ID>

Tatsächlich passende Regel:
<Name, ID, Position und Aktion>

Sicherheitsprofile:
<IPS, URL, Malware, TLS oder andere Profile>

Sitzungs-ID:
<ID und Zustand>

Pakete und Bytes:
<je Richtung>

Sitzungsendgrund:
<Grund>

Protokollbefund:
<Logeintrag und Zeitstempel>

Paketaufzeichnung:
<Eingangs- und Ausgangsbefund>

Hypothese:
<vermutete Ursache>

Erwarteter Nachweis:
<messbarer Befund>

Gegenbeweis:
<Befund, der die Hypothese widerlegt>

Nachgewiesene Ursache:
<technischer Nachweis>

Durchgeführte Maßnahme:
<genau beschriebene Änderung>

Risiko:
<mögliche Nebenwirkung>

Rückweg:
<Rollback>

Verifikation:
<identischer Test und Anwendungstest>

Prävention:
<Monitoring, Bereinigung oder Prozessverbesserung>

Checkliste

Schnellreferenz

Aufgabe Beispiel
Datenfluss dokumentieren 192.0.2.100:53124 -> 198.51.100.25:443/TCP
Cisco IOS ACLs anzeigen show ip access-lists
Cisco IOS ACL-Bindung prüfen show ip interface
ASA ACLs anzeigen show access-list
ASA ACL-Bindung anzeigen show access-group
ASA Sitzungen anzeigen show conn
ASA Sitzung nach Adresse filtern show conn address 192.0.2.100
ASA NAT-Zustand anzeigen show xlate
ASA Route anzeigen show route
ASA Datenfluss simulieren packet-tracer input inside tcp 192.0.2.100 53124 198.51.100.25 443 detailed
ASA Drop-Zähler anzeigen show asp drop
Juniper Policies anzeigen show security policies
Juniper Policy-Treffer anzeigen show security policies hit-count
Juniper Sitzungen anzeigen show security flow session
Juniper Route prüfen show route 198.51.100.25
Palo Alto Sitzung suchen show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443
Palo Alto Route prüfen test routing fib-lookup virtual-router <Routername> ip 198.51.100.25
Linux nftables anzeigen sudo nft list ruleset
Linux nftables mit Handles sudo nft -a list ruleset
Linux Routing anzeigen ip route show
Linux IPv6-Routing anzeigen ip -6 route show
Linux Conntrack anzeigen sudo conntrack -L

Befehle, die nicht als erste Diagnosemaßnahme verwendet werden dürfen:

clear conn
clear xlate
clear access-list counters
clear security flow session
clear session all
conntrack -F
nft flush ruleset
iptables -F
policy commit ohne geprüften Änderungsplan
Firewall deaktivieren
Cluster-Failover erzwingen
Firewalldienst neu starten
allgemeine any-any-Freigabe erstellen
Sicherheitsprofile global deaktivieren

Quellen

Grundlagen und Standards

Cisco

Juniper Networks

Palo Alto Networks

Amazon Web Services

Microsoft Azure

Für diese Seite wurden keine Community-Beiträge oder Hersteller-Social-Media-Aussagen als fachlicher Nachweis verwendet.

9. TCP, UDP, Ports, Firewall, NAT und Proxy

9.6 Asymmetrische Pfade, Sessiontabellen und Connection Tracking

Bei asymmetrischem Routing verwenden Hin- und Rückverkehr einer Kommunikation unterschiedliche Netzwerkpfade. Für gewöhnliche Router ist das nicht grundsätzlich fehlerhaft: Jeder Router entscheidet für jedes Paket anhand seiner eigenen Routingtabelle. Zustandsbehaftete Firewalls, NAT-Gateways, Load Balancer und andere Stateful-Systeme müssen jedoch zusammengehörige Pakete einer gespeicherten Sitzung zuordnen können.

Erreicht der Verbindungsaufbau eine Firewall, der Rückverkehr aber eine andere Firewall ohne synchronisierten Sitzungszustand, kann das Antwortpaket als unbekannt oder ungültig verworfen werden. Eine vorhandene Freigaberegel löst dieses Problem nicht, weil nicht die Regel, sondern der fehlende Sitzungszustand die Ursache ist.

Ziele

Nach der Bearbeitung dieser Seite soll nachvollziehbar geprüft werden können:

Sicherheits- und Änderungsgrundsätze

Sessiontabellen und Connection Tracking enthalten den aktuellen Zustand produktiver Verbindungen. Unkontrollierte Eingriffe können gleichzeitig unterbrechen:

Nicht als erste Diagnosemaßnahme geeignet sind:

Vor einer Änderung sind mindestens zu dokumentieren:

Symmetrischen und asymmetrischen Pfad unterscheiden

Symmetrischer Pfad:

Hinweg:
Client -> Router A -> Firewall A -> Router B -> Server

Rückweg:
Server -> Router B -> Firewall A -> Router A -> Client

Asymmetrischer Pfad:

Hinweg:
Client -> Router A -> Firewall A -> Router B -> Server

Rückweg:
Server -> Router C -> Firewall B -> Router D -> Client

Entscheidend ist nicht, ob jeder einzelne Router identisch ist. Entscheidend ist, ob zustandsabhängige Komponenten in beiden Richtungen den benötigten Sitzungszustand besitzen.

Situation Mögliche Wirkung
Hin- und Rückweg nutzen dieselbe Stateful Firewall Sitzung kann normalerweise korrekt zugeordnet werden
unterschiedliche Router, aber dieselbe Firewall kann funktionieren
unterschiedliche Clusterknoten mit funktionierender State-Synchronisation kann funktionieren
unterschiedliche nicht synchronisierte Firewalls Rückverkehr kann verworfen werden
rein zustandslose ACLs in beiden Richtungen kann mit passenden Gegenregeln funktionieren
NAT nur auf dem Hinweggerät Rückverkehr kann falsches Ziel oder falschen Pfad verwenden
asymmetrischer Pfad durch Sicherheitsprofil vollständige Inhaltsprüfung kann unmöglich sein
Rückweg umgeht die Firewall vollständig Firewall sieht nur eine Richtung und Protokolle bleiben unvollständig

Asymmetrie ist nicht automatisch ein Routingfehler

IP-Routing verlangt nicht grundsätzlich, dass Hin- und Rückweg identisch sind. Asymmetrie wird problematisch, wenn eine beteiligte Komponente Informationen aus beiden Richtungen benötigt.

Typische zustandsabhängige Komponenten:

Die Diagnosefrage lautet deshalb nicht nur:

Existiert ein Rückweg?

Sondern:

Verwendet der Rückweg alle zustandsabhängigen Komponenten,
die den Hinweg verarbeitet haben?

Einen Datenfluss eindeutig identifizieren

Für TCP und UDP wird ein Datenfluss üblicherweise über das Fünf-Tupel beschrieben:

Quelladresse
Quellport
Zieladresse
Zielport
IP-Protokoll

Beispiel:

Originalrichtung:
192.0.2.100:53124 -> 198.51.100.25:443/TCP

Antwortrichtung:
198.51.100.25:443 -> 192.0.2.100:53124/TCP

Zusätzlich zu dokumentieren sind:

Nur die Zieladresse und den Zielport zu dokumentieren reicht nicht. Mehrere gleichzeitige Sitzungen können dasselbe Ziel verwenden und sich nur durch Quelladresse oder Quellport unterscheiden.

Sessiontabelle und Connection Tracking

Eine Sessiontabelle speichert Informationen über aktuell bekannte Datenflüsse. Linux Netfilter bezeichnet diese Funktion als Connection Tracking oder kurz Conntrack.

Ein Eintrag kann unter anderem enthalten:

IP-Protokoll
Original-Quelladresse
Original-Quellport
Original-Zieladresse
Original-Zielport
Antwort-Quelladresse
Antwort-Quellport
Antwort-Zieladresse
Antwort-Zielport
TCP-Zustand
NAT-Status
Sitzungsmarkierung
Timeout
Pakete je Richtung
Bytes je Richtung
erkannte Anwendung
passende Richtlinie
Eingangs- und Ausgangsschnittstelle
Clusterbesitzer

Die Sessiontabelle ermöglicht unter anderem:

Conntrack-Zustände

Bei Netfilter und vergleichbaren Systemen werden häufig folgende generische Zustände unterschieden:

Zustand Bedeutung
NEW gültiger Beginn oder frühes Paket eines noch nicht in beide Richtungen bestätigten Datenflusses
ESTABLISHED gültige Pakete wurden in beiden Richtungen gesehen
RELATED neuer Datenfluss steht in erwarteter Beziehung zu einer vorhandenen Verbindung
INVALID Paket kann keiner gültigen Verbindung zugeordnet werden oder verletzt Erwartungen
UNTRACKED Paket wurde ausdrücklich von Connection Tracking ausgenommen

Die Zustände sind nicht mit dem gleichnamigen TCP-Zustand ESTABLISHED gleichzusetzen. Ein Firewall- oder Conntrack-Zustand beschreibt die Sicht des Tracking-Systems.

Beispiel eines üblichen nftables-Prinzips:

ct state established,related accept
ct state invalid drop

Das ist nur ein vereinfachtes Beispiel. Das vollständige Regelwerk, die Richtung und der Sicherheitsbedarf müssen separat geprüft werden.

TCP-Zustände innerhalb der Sitzung

TCP besitzt zusätzlich protokollspezifische Zustände.

Zustand Einordnung
SYN_SENT Verbindungsanfrage wurde in Originalrichtung gesehen
SYN_RECV passende Antwort mit SYN und ACK wurde gesehen
ESTABLISHED TCP-Verbindungsaufbau wurde bestätigt
FIN_WAIT eine Seite hat die reguläre Beendigung begonnen
CLOSE_WAIT Gegenstelle hat die Beendigung begonnen
LAST_ACK letztes Bestätigungspaket für Verbindungsabbau wird erwartet
TIME_WAIT Schutzphase nach regulärem Verbindungsende
CLOSE Verbindung gilt als geschlossen
RETRANS oder vergleichbarer Zustand Wiederholungen oder fehlende Bestätigungen wurden erkannt
UNACK Daten oder Steuerinformationen wurden noch nicht bestätigt

Die genaue Benennung und Zustandslogik hängen vom verwendeten Produkt ab.

Typischen Conntrack-Eintrag lesen

Beispiel:

tcp 6 431982 ESTABLISHED
src=192.0.2.100 dst=198.51.100.25 sport=53124 dport=443
src=198.51.100.25 dst=192.0.2.100 sport=443 dport=53124
packets=169 bytes=14322
packets=113 bytes=34787
[ASSURED]

Einordnung:

Feld Bedeutung
tcp Transportprotokoll
6 IP-Protokollnummer für TCP
431982 verbleibender Timeout in Sekunden
ESTABLISHED protokollspezifischer Tracking-Zustand
erster Adressblock Originalrichtung
zweiter Adressblock Antwortrichtung
packets gezählte Pakete der jeweiligen Richtung
bytes gezählte Bytes der jeweiligen Richtung
[ASSURED] Antwortverkehr und ausreichend bestätigter Zustand wurden erkannt

Die genaue Darstellung hängt von Kernel-, Conntrack- und Distributionsversion ab.

Wichtige Conntrack-Markierungen

Markierung Bedeutung
[UNREPLIED] bisher wurde keine passende Antwortrichtung gesehen
[ASSURED] der Datenfluss wurde in beiden Richtungen ausreichend bestätigt
src-nat Quellübersetzung ist beteiligt
dst-nat Zielübersetzung ist beteiligt
expected Datenfluss wurde durch eine Erwartung einer anderen Verbindung angekündigt
seen-reply Antwortverkehr wurde erkannt
offload Sitzung wurde in einen beschleunigten Datenpfad ausgelagert
hw-offload Verarbeitung erfolgt zumindest teilweise in Hardware

[UNREPLIED] bedeutet nicht automatisch, dass der Server nicht geantwortet hat. Die Antwort könnte:

Einige Protokolle verwenden zusätzliche Datenverbindungen, die zu einer bestehenden Steuerverbindung gehören.

Mögliche Beispiele:

Ein Connection-Tracking-Helper kann für den zusätzlichen Datenfluss eine Erwartung anlegen. Dieser Datenfluss kann anschließend als RELATED eingeordnet werden.

Zu prüfen sind:

Helpers dürfen nicht pauschal aktiviert werden. Sie greifen in die Protokollverarbeitung ein und können zusätzliche Sicherheits- und Kompatibilitätsauswirkungen besitzen.

Warum asymmetrischer Rückverkehr verworfen wird

Beispiel:

  1. Client sendet ein TCP-SYN.
  2. Firewall A prüft die Sicherheitsregel.
  3. Firewall A legt eine Sitzung an.
  4. Server sendet SYN, ACK.
  5. Routing leitet die Antwort über Firewall B.
  6. Firewall B besitzt keine passende Sitzung.
  7. Firewall B sieht ein Antwortpaket ohne bekannten Verbindungsaufbau.
  8. Firewall B verwirft es als unbekannt oder ungültig.

Vereinfachte Sicht:

Firewall A:
SYN gesehen
Sitzung vorhanden
SYN-ACK nicht gesehen

Firewall B:
SYN nicht gesehen
Sitzung nicht vorhanden
SYN-ACK gesehen

Mögliche Symptome:

Asymmetrie innerhalb derselben Firewall

Auch wenn beide Richtungen dieselbe physische Firewall verwenden, können unterschiedliche Kontexte die Zuordnung verhindern:

Deshalb muss nicht nur der Gerätename, sondern auch der vollständige Verarbeitungskontext übereinstimmen.

Häufige Ursachen asymmetrischer Pfade

Längstes Präfix und Routenauswahl

Router bevorzugen grundsätzlich die spezifischste passende Route.

Beispiel:

10.0.0.0/8      über Firewall A
10.20.30.0/24   über Firewall B

Für das Ziel:

10.20.30.40

wird die spezifischere Route /24 verwendet.

Eine allgemeine Standardroute über die erwartete Firewall garantiert deshalb nicht, dass ein bestimmtes Ziel tatsächlich diese Firewall verwendet.

Zu prüfen sind:

ECMP

Equal-Cost Multi-Path ermöglicht die Nutzung mehrerer gleichwertiger Routen.

Mögliche Verteilungsverfahren:

Per-Flow-ECMP hält normalerweise alle Pakete eines Datenflusses auf demselben Hinweg. Es garantiert jedoch nicht automatisch, dass die Gegenstelle für den Rückweg denselben Firewallknoten auswählt.

Zu prüfen sind:

Ein Problem, das nur bei einem Teil der Verbindungen auftritt, kann auf ECMP oder eine fehlerhafte Teilstrecke hinweisen.

Policy-Based Routing

Policy-Based Routing kann die normale Zielroutenauswahl überschreiben.

Mögliche Kriterien:

Zu prüfen sind:

Typischer Fehler:

Hinweg:
PBR erzwingt Firewall A

Rückweg:
normale Route verwendet Firewall B

Die korrekte Sicherheitsregel auf beiden Firewalls löst den fehlenden gemeinsamen Sitzungszustand nicht.

Dynamisches Routing

Bei OSPF, IS-IS, BGP oder anderen dynamischen Routingprotokollen können sich Hin- und Rückwege unabhängig ändern.

Zu prüfen sind:

Ein Pfad kann im stabilen Zustand symmetrisch und während einer Routingkonvergenz vorübergehend asymmetrisch sein.

Mehrere Netzwerkkarten am Server

Ein Server mit mehreren Netzwerkkarten kann den Rückverkehr über eine andere Schnittstelle senden.

Zu prüfen sind:

Beispiel:

Anfrage erreicht:
eth1 / 10.20.30.40

Serverantwort verlässt:
eth0 / Standardgateway über anderes Netz

Der Serverdienst kann korrekt antworten, während die Antwort einen unzulässigen oder nicht zustandsbehafteten Rückweg verwendet.

Reverse Path Filtering

Reverse Path Filtering prüft, ob die Quelladresse eines eingehenden Pakets aus Sicht der Routingtabelle über einen plausiblen Pfad erreichbar ist.

Unter Linux sind typischerweise folgende Betriebsarten relevant:

Lesende Prüfung:

sysctl net.ipv4.conf.all.rp_filter

sysctl net.ipv4.conf.default.rp_filter

Schnittstellenspezifisch:

sysctl net.ipv4.conf.eth0.rp_filter

Eine strikte Prüfung kann legitimen asymmetrischen Verkehr verwerfen. Sie darf jedoch nicht ohne Sicherheitsbewertung deaktiviert werden. Zuerst sind Route, Quelladresse und tatsächlicher Datenpfad nachzuweisen.

NAT und asymmetrische Pfade

NAT benötigt normalerweise einen konsistenten Zustand für Original- und Antwortrichtung.

Beispiel mit Source NAT:

Originalrichtung:
10.10.20.25:53124 -> 203.0.113.80:443

Nach SNAT:
198.51.100.5:61001 -> 203.0.113.80:443

Der Server antwortet an:

203.0.113.80:443 -> 198.51.100.5:61001

Nur die NAT-Komponente mit der passenden Übersetzung weiß, dass die Antwort zurückübersetzt werden muss zu:

203.0.113.80:443 -> 10.10.20.25:53124

Erreicht die Antwort ein anderes NAT-Gateway ohne synchronisierten Zustand, fehlt die Zuordnung.

Zu prüfen sind:

Source NAT kann bewusst verwendet werden, um den Rückverkehr zu einer bestimmten Komponente zurückzuführen. Diese Maßnahme verändert jedoch Quelladressen und kann Protokollierung, Zugriffskontrolle und Nachvollziehbarkeit beeinflussen.

Load Balancer und Direct Server Return

Bei einem normalen Proxy- oder Full-NAT-Load-Balancer verlaufen Hin- und Rückverkehr häufig über den Load Balancer.

Bei Direct Server Return kann der Server direkt zum Client antworten, ohne den Load Balancer erneut zu durchlaufen.

Das kann beabsichtigt sein, erfordert aber ein passendes Design.

Zu prüfen sind:

Eine Firewall darf nicht fälschlich erwarten, beide Richtungen zu sehen, wenn das freigegebene Architekturdesign bewusst Direct Server Return verwendet.

Firewallcluster und State-Synchronisation

Ein HA-Cluster kann unter anderem synchronisieren:

Nicht jede Sitzungsart und nicht jede Funktion wird zwangsläufig synchronisiert.

Zu prüfen sind:

Eine erfolgreiche Konfigurationssynchronisation beweist keine erfolgreiche Sitzungssynchronisation.

Active/Passive

Bei Active/Passive verarbeitet normalerweise nur der aktive Knoten den produktiven Verkehr. Der passive Knoten erhält je nach Produkt Sitzungsinformationen.

Nach einem Failover sind folgende Ergebnisse möglich:

Zu prüfen sind:

Active/Active

Bei Active/Active können mehrere Knoten gleichzeitig produktiven Verkehr verarbeiten.

Das erfordert je nach Architektur:

Besonders kritisch ist:

SYN:
Knoten A

SYN-ACK:
Knoten B

Folgepakete:
abwechselnd A und B

Wenn die Plattform diesen Datenpfad nicht ausdrücklich unterstützt, können Sitzungen verworfen oder Sicherheitsprüfungen umgangen werden.

Synchronisationsverzögerung

State-Synchronisation erfolgt nicht immer vollständig synchron vor der Paketweiterleitung. Bei kurzen Datenflüssen oder einem schnellen Pfadwechsel kann das Antwortpaket den zweiten Knoten erreichen, bevor der Zustand übertragen wurde.

Mögliche Symptome:

Die Lösung ist nicht automatisch ein längerer Timeout. Zu prüfen sind Synchronisationslink, unterstützte Betriebsart, Flow-Pinning und Routingdesign.

Connection-Tracking-Kapazität

Eine Sessiontabelle besitzt eine begrenzte Kapazität.

Bei Linux sind insbesondere relevant:

nf_conntrack_count
nf_conntrack_max
nf_conntrack_buckets

Lesende Prüfung:

sysctl net.netfilter.nf_conntrack_count

sysctl net.netfilter.nf_conntrack_max

sysctl net.netfilter.nf_conntrack_buckets

Alternative direkte Anzeige:

cat /proc/sys/net/netfilter/nf_conntrack_count

cat /proc/sys/net/netfilter/nf_conntrack_max

Auslastung berechnen:

Auslastung in Prozent =
nf_conntrack_count / nf_conntrack_max × 100

Beispiel:

nf_conntrack_count = 245760
nf_conntrack_max   = 262144

Auslastung =
245760 / 262144 × 100
= 93,75 %

Ein hoher Tabellenfüllstand kann zu folgenden Symptomen führen:

Eine Vergrößerung von nf_conntrack_max benötigt eine Speicher- und Lastbewertung. Sie beseitigt keine Ursache wie Portscan, DDoS, fehlerhafte Anwendung oder ungeeignete Timeouts.

Conntrack-Statistiken

Sofern conntrack-tools installiert ist:

sudo conntrack -S

Mögliche Statistikfelder sind:

Ein einzelner Gesamtzähler ohne Zeitbezug ist wenig aussagekräftig.

Belastbarer Ablauf:

  1. Zähler und Uhrzeit erfassen.
  2. definierten Testzeitraum starten.
  3. genau einen reproduzierbaren Test durchführen.
  4. Zähler erneut erfassen.
  5. Differenz mit Paketaufzeichnung und Protokollen korrelieren.

Timeouts

Sessiontabellen entfernen inaktive Einträge nach protokoll- und zustandsabhängigen Zeiträumen.

Unter Linux können unter anderem relevant sein:

sysctl net.netfilter.nf_conntrack_tcp_timeout_syn_sent

sysctl net.netfilter.nf_conntrack_tcp_timeout_syn_recv

sysctl net.netfilter.nf_conntrack_tcp_timeout_established

sysctl net.netfilter.nf_conntrack_tcp_timeout_time_wait

sysctl net.netfilter.nf_conntrack_udp_timeout

sysctl net.netfilter.nf_conntrack_udp_timeout_stream

sysctl net.netfilter.nf_conntrack_icmp_timeout

Die konkreten Werte sind Systemzustand und Konfiguration und dürfen nicht aus einer allgemeinen Dokumentation als garantierte lokale Werte übernommen werden.

Typische Timeoutbefunde:

Befund Mögliche Einordnung
Verbindung bricht nach fester Leerlaufzeit ab Idle-Timeout
neue Verbindung funktioniert sofort vorherige Sitzung ist abgelaufen oder wurde verworfen
UDP-Antwort kommt verspätet und wird verworfen UDP-Tracking-Eintrag bereits entfernt
Langzeitverbindungen scheitern unter Last vorzeitiges Aging oder Tabellenknappheit
nach Failover fehlen nur ältere Sitzungen unvollständige Zustandssynchronisation

Offloading berücksichtigen

Firewalls und Linux-Netfilter können etablierte Datenflüsse in einen beschleunigten Pfad oder in Hardware auslagern.

Mögliche Auswirkungen:

Zu prüfen sind:

Offloading darf nicht pauschal deaktiviert werden, da dies die Leistungsfähigkeit der Firewall erheblich beeinflussen kann.

Hin- und Rückweg getrennt prüfen

Eine Traceroute nur vom Client zum Server zeigt nicht den Rückweg.

Erforderlich sind nach Möglichkeit:

Test A:
Client -> Server

Test B:
Server -> Client

Windows:

tracert 198.51.100.25

Test-NetConnection `
  -ComputerName "198.51.100.25" `
  -Port 443 `
  -InformationLevel Detailed

Linux:

traceroute 198.51.100.25

tracepath 198.51.100.25

macOS:

traceroute 198.51.100.25

Traceroute-Ergebnisse sind nur ein Teilnachweis. Firewalls können:

Für anwendungsnahes Tracing kann abhängig von Plattform und Freigabe ein TCP-basierter Traceroute zum tatsächlichen Zielport verwendet werden.

Lokale Routingentscheidung prüfen

Windows:

Get-NetRoute `
  -AddressFamily IPv4 |
  Sort-Object DestinationPrefix, RouteMetric

Bestimmte Zielroute:

Find-NetRoute `
  -RemoteIPAddress "198.51.100.25"

Klassische Anzeige:

route print

Linux:

ip route get 198.51.100.25

Mit angenommener Quelladresse:

ip route get 198.51.100.25 from 192.0.2.100

Policy-Regeln:

ip rule show

Alle Routingtabellen:

ip route show table all

IPv6:

ip -6 route get 2001:db8::25

macOS:

route -n get 198.51.100.25

Die lokale Routenausgabe zeigt nur die Entscheidung des untersuchten Systems. Sie beweist nicht den vollständigen End-to-End-Pfad.

Linux-Conntrack lesend prüfen

Alle Einträge anzeigen:

sudo conntrack -L

Nur TCP:

sudo conntrack -L -p tcp

Nach Originalquelle und Originalziel filtern:

sudo conntrack -L \
  -p tcp \
  -s 192.0.2.100 \
  -d 198.51.100.25 \
  --dport 443

Nach UDP filtern:

sudo conntrack -L \
  -p udp \
  -s 192.0.2.100 \
  -d 198.51.100.53 \
  --dport 53

Anzahl anzeigen:

sudo conntrack -C

Statistiken anzeigen:

sudo conntrack -S

Conntrack-Ereignisse beobachten:

sudo conntrack -E

Gezielt TCP-Ereignisse beobachten:

sudo conntrack -E -p tcp

Mögliche Ereignisse:

[NEW]
[UPDATE]
[DESTROY]

Die Ereignisbeobachtung sollte auf einen kurzen Testzeitraum begrenzt werden. Auf stark ausgelasteten Systemen kann eine ungefilterte Ausgabe sehr groß werden und interne Kommunikationsdaten enthalten.

Direkte Kernelansicht

Falls conntrack nicht installiert ist, kann abhängig vom System eine Kernelansicht existieren:

sudo cat /proc/net/nf_conntrack

Gezielte Textfilterung:

sudo grep 'dst=198.51.100.25' /proc/net/nf_conntrack

Diese Schnittstelle kann fehlen oder durch Namespace- und Berechtigungseinstellungen eingeschränkt sein. Das conntrack-Werkzeug bietet normalerweise bessere Filter- und Ereignisfunktionen.

Netzwerk-Namespaces und Container

Container, Kubernetes und Linux-Netzwerk-Namespaces können eigene Routing-, Firewall- und Conntrack-Kontexte besitzen.

Zu prüfen sind:

Namespaces anzeigen:

ip netns list

Routing in einem Namespace:

sudo ip netns exec <Namespace> ip route show

Schnittstellen:

sudo ip netns exec <Namespace> ip address show

Ein Conntrack-Eintrag auf dem Host muss anhand der vor und nach NAT sichtbaren Adressen geprüft werden. Die Anwendung kann innerhalb des Containers andere Adressen sehen als die Host-Firewall.

Cisco Secure Firewall ASA prüfen

Verbindungen anzeigen:

show conn

Nach Adresse filtern:

show conn address 192.0.2.100

Anzahl und Kapazität:

show conn count

NAT-Zustände:

show xlate

HA-Zustand:

show failover

Routing:

show route

Drop-Zähler:

show asp drop

Datenfluss simulieren:

packet-tracer input inside tcp 192.0.2.100 53124 198.51.100.25 443 detailed

Zu vergleichen sind:

Cisco ASA bietet für bestimmte ausdrücklich geplante asymmetrische Szenarien einen TCP State Bypass. Dieser deaktiviert jedoch wesentliche zustandsabhängige Prüfungen und unterstützt nicht alle Funktionen. Er ist keine allgemeine Reparaturmaßnahme für fehlerhaftes Routing.

Juniper SRX prüfen

Aktive Sitzungen:

show security flow session

Nach Quelle:

show security flow session source-prefix 192.0.2.100

Nach Ziel:

show security flow session destination-prefix 198.51.100.25

Route:

show route 198.51.100.25

Flow-Statistiken:

show security flow statistics

Clusterzustand:

show chassis cluster status

Zu prüfen sind:

Die verfügbaren Filter unterscheiden sich nach Junos-Version und Plattform. Die lokale CLI-Hilfe ist deshalb zusätzlich zu verwenden.

Palo Alto Networks prüfen

Sitzung nach Datenfluss suchen:

show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443

Filtermöglichkeiten prüfen:

show session all filter ?

Routingentscheidung:

test routing fib-lookup virtual-router <Routername> ip 198.51.100.25

HA-Zustand:

show high-availability state

Zu prüfen sind:

Die genaue Syntax und Feldbezeichnung hängt von PAN-OS-Version, Plattform und Betriebsart ab.

AWS Network Firewall

AWS Network Firewall benötigt für zustandsbehaftete Verarbeitung, dass Anfrage und Antwort denselben Firewallendpunkt durchlaufen.

Zu prüfen sind:

AWS Network Firewall unterstützt keine asymmetrische Weiterleitung zu unterschiedlichen Firewallendpunkten. Anfrage und Antwort müssen demselben Endpunkt zugeführt werden.

Ein Reachability-Analyzer-Ergebnis kann die modellierte Erreichbarkeit prüfen, ersetzt aber nicht die Auswertung realer Flow- und Alert-Logs.

AWS Security Group Connection Tracking

AWS Security Groups sind zustandsbehaftet und verfolgen Verbindungen. Zu prüfen sind:

Asymmetrisches Routing über verschiedene Netzwerkschnittstellen kann bei verfolgten Datenflüssen die erreichbare Leistung beeinträchtigen. AWS empfiehlt nach Möglichkeit symmetrische Topologien.

Azure Firewall und Network Virtual Appliances

Bei Azure sind unter anderem zu prüfen:

Effektive Routen per PowerShell:

Get-AzEffectiveRouteTable `
  -NetworkInterfaceName "<NIC-Name>" `
  -ResourceGroupName "<Ressourcengruppe>"

Ein öffentlicher Load Balancer und eine private Firewallroute können einen asymmetrischen Pfad erzeugen, wenn der Hinverkehr über die öffentliche Load-Balancer-Adresse eintrifft und der Rückverkehr über die private Firewalladresse geführt wird.

Bei Active/Active-NVAs muss geprüft werden, ob:

Paketaufzeichnung systematisch planen

Für einen vollständigen Pfadvergleich sind möglichst vier Beobachtungspunkte hilfreich:

Punkt Beobachtung
A Paket verlässt den Client
B Paket erreicht und verlässt die zustandsbehaftete Komponente
C Paket erreicht den Server und Antwort verlässt ihn
D Antwort erreicht oder verfehlt die zustandsbehaftete Komponente

Empfohlener Filter:

host 192.0.2.100 and host 198.51.100.25 and tcp port 443

Mit tcpdump:

sudo tcpdump \
  -ni any \
  'host 192.0.2.100 and host 198.51.100.25 and tcp port 443'

Nur TCP-Flags und Zeitverhalten prüfen:

sudo tcpdump \
  -ni any \
  -tttt \
  'host 192.0.2.100 and host 198.51.100.25 and tcp port 443'

Für NAT müssen gegebenenfalls zwei Filter verwendet werden:

vor NAT:
10.10.20.25:53124 -> 203.0.113.80:443

nach NAT:
198.51.100.5:61001 -> 203.0.113.80:443

Paketaufzeichnungen dürfen nur autorisiert, zielgerichtet und zeitlich begrenzt durchgeführt werden.

Zeitstempel korrelieren

Alle beteiligten Systeme sollten eine ausreichend genaue Zeitbasis verwenden:

Zu dokumentieren sind:

Datum
Uhrzeit
Zeitzone
Zeitquelle
ungefähre Zeitabweichung

Schon wenige Sekunden Unterschied können bei kurzen Verbindungsversuchen zu einer falschen Zuordnung führen.

Pakete und Bytes je Richtung auswerten

Befund Mögliche Einordnung
nur Originalpakete, keine Antwortpakete Serverantwort fehlt oder verwendet anderen Rückweg
Antwortpakete am Server, nicht an Firewall Route zwischen Server und Firewall prüfen
Antwortpakete an anderer Firewall asymmetrischer Rückweg
beide Richtungen in Sitzung, Client empfängt nichts nachgelagerter Pfad zum Client prüfen
wenige Pakete, Sitzung bleibt SYN_SENT SYN-ACK fehlt
Pakete in beide Richtungen, aber kaum Bytes Handshake ohne Anwendungsdaten
hohe Bytes nur in einer Richtung Anwendung, ACK-Pfad oder Filterproblem
Sitzung verschwindet sofort RST, Policy-Drop, Timeout oder Tabellenproblem
Sitzung bleibt lange [UNREPLIED] keine zugeordnete Antwort

Zähler müssen während genau eines reproduzierbaren Tests verglichen werden.

NetFlow, IPFIX und Flow Logs

Flow-Daten können Hinweise liefern auf:

Einschränkungen:

Flow-Daten sind besonders hilfreich, wenn Hin- und Rückrichtung auf unterschiedlichen Geräten sichtbar werden.

Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Der TCP-Verbindungsaufbau läuft über Firewall A, der Rückverkehr
aufgrund einer spezifischeren Serverroute jedoch über Firewall B.
Firewall B besitzt keinen synchronisierten Sitzungszustand und
verwirft das SYN-ACK.

Erwarteter Befund:
Firewall A zeigt eine Sitzung im Zustand SYN_SENT oder UNREPLIED.
Firewall B zeigt keinen passenden Sitzungseintrag, aber einen
Invalid-State-Drop für das SYN-ACK.
Eine serverseitige Paketaufzeichnung zeigt, dass das SYN-ACK den
Server verlässt.

Gegenbeweis:
Hin- und Rückverkehr durchlaufen nachweislich Firewall A, und
Firewall A sieht das SYN-ACK in derselben Sitzung.

Testmethode:
Routingtabellen, Sessiontabellen und zeitgleiche Paketaufzeichnungen
auf Client-, Server- und Firewallseite vergleichen.

Risiko:
Nur lesende Diagnose und begrenzte Paketaufzeichnung.

Erfolgskriterium:
Abweichender Rückweg und verwerfendes Gerät sind mit Zeitstempel,
Sitzungsdaten und Routingentscheidung eindeutig belegt.

Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko Rückweg
spezifische Rückroute korrigieren falscher Rückweg nachgewiesen weitere Ziele können betroffen sein alte Route wiederherstellen
Routingmetrik korrigieren falsche Pfadauswahl bestätigt Konvergenz und Lastverteilung ändern sich alte Metrik wiederherstellen
PBR-Regel korrigieren asymmetrische PBR-Entscheidung bestätigt andere markierte Flows betroffen vorherige PBR-Regel aktivieren
ECMP-Hash oder Flow-Pinning korrigieren Verteilung auf unterschiedliche Stateful-Knoten bestätigt Lastverteilung verändert sich vorherige Einstellung wiederherstellen
Cluster-State-Synchronisation reparieren fehlende Synchronisation nachgewiesen HA-Verhalten betroffen herstellerspezifischer Rückfallplan
SNAT gezielt einsetzen Rückweg muss technisch gebunden werden Originalquelle wird verdeckt SNAT-Regel entfernen
NAT-Regel korrigieren falscher NAT-Besitzer oder falsche Übersetzung bestätigt Erreichbarkeit vieler Verbindungen alte NAT-Regel wiederherstellen
einzelne Sitzung löschen veralteter Eintrag nachgewiesen genau diese Verbindung wird unterbrochen Anwendung baut Sitzung neu auf
Timeout korrigieren nachweislicher Timeoutkonflikt höhere Tabellenbelegung alten Wert wiederherstellen
Conntrack-Kapazität erhöhen Tabellenlimit und ausreichender Speicher nachgewiesen höherer Speicherbedarf alten Grenzwert wiederherstellen
fehlerhafte Quelle begrenzen ungewöhnlich viele Sessions einer Quelle bestätigt legitime Kommunikation kann betroffen sein Begrenzung entfernen
Active/Active-Design anpassen Plattform unterstützt Asymmetrie nicht Verfügbarkeit und Verteilung ändern sich vorheriges Routingdesign wiederherstellen

Eine Änderung an Routing, NAT oder HA muss als zusammenhängende Ende-zu-Ende-Änderung bewertet werden.

Vollständiger Diagnoseablauf

  1. Exakte Fehlermeldung dokumentieren.
  2. Datum, Uhrzeit und Zeitzone erfassen.
  3. Betroffene Anwendung bestimmen.
  4. Quell- und Zielsystem bestimmen.
  5. Quelladresse und Quellport erfassen.
  6. Zieladresse und Zielport erfassen.
  7. Protokoll bestimmen.
  8. IPv4 und IPv6 unterscheiden.
  9. Originalrichtung dokumentieren.
  10. Antwortrichtung dokumentieren.
  11. NAT vor und nach Übersetzung dokumentieren.
  12. Fehlerumfang bestimmen.
  13. Erwarteten Hinweg dokumentieren.
  14. Erwarteten Rückweg dokumentieren.
  15. Lokale Clientroute prüfen.
  16. Lokale Serverroute prüfen.
  17. Policy Routing auf beiden Endsystemen prüfen.
  18. Routinginstanzen und VRFs berücksichtigen.
  19. Tatsächlichen Hinweg nachweisen.
  20. Tatsächlichen Rückweg unabhängig nachweisen.
  21. Alle zustandsbehafteten Komponenten erfassen.
  22. Aktive Firewall- und Clusterknoten bestimmen.
  23. Sessiontabellen auf allen möglichen Knoten prüfen.
  24. Sitzungs-ID dokumentieren.
  25. Original- und Antwort-Tupel vergleichen.
  26. TCP-, UDP- oder ICMP-Zustand auswerten.
  27. [UNREPLIED], [ASSURED] oder vergleichbare Markierung prüfen.
  28. Pakete und Bytes je Richtung vergleichen.
  29. NAT-Sitzung und NAT-Besitzer prüfen.
  30. Regel- und Drop-Protokolle korrelieren.
  31. Cluster- und State-Synchronisation prüfen.
  32. Zeitpunkt des letzten Failovers prüfen.
  33. ECMP und Hash-Verfahren prüfen.
  34. PBR und Source Routing prüfen.
  35. dynamische Routen und spezifischere Präfixe prüfen.
  36. Load Balancer und Direct Server Return berücksichtigen.
  37. Cloud-Routingtabellen und Firewallendpunkte prüfen.
  38. Conntrack-Auslastung erfassen.
  39. Conntrack-Fehlerzähler erfassen.
  40. Timeouts dokumentieren.
  41. Hardware-Offloading berücksichtigen.
  42. kontrollierten Verbindungstest durchführen.
  43. bei Bedarf Conntrack-Ereignisse beobachten.
  44. bei Bedarf Paketaufzeichnung an mehreren Punkten durchführen.
  45. Hypothese und Gegenbeweis formulieren.
  46. genau eine kontrollierte Maßnahme vorbereiten.
  47. Risiko, Rückweg und Erfolgskriterium dokumentieren.
  48. Maßnahme freigeben und umsetzen.
  49. vollständig neue Sitzung aufbauen.
  50. Hin- und Rückweg erneut prüfen.
  51. Session- und NAT-Zustand erneut prüfen.
  52. ursprüngliche Anwendung verifizieren.
  53. weitere repräsentative Datenflüsse prüfen.
  54. temporäre Aufzeichnungen und Diagnoseregeln zurücknehmen.
  55. Ursache, Maßnahme und Prävention dokumentieren.

Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
Sitzung nur auf Firewall A Firewall B besitzt keinen Zustand Rückweg und State-Synchronisation prüfen
Firewall A zeigt [UNREPLIED] keine zugeordnete Antwort serverseitige Aufzeichnung und Rückroute
Server sendet SYN-ACK, Client empfängt nichts Rückweg wird verworfen Firewalls des Rückwegs erfassen
Firewall B meldet INVALID unbekannter oder fehlerhafter Zustand ursprünglichen SYN-Pfad bestimmen
Verbindung funktioniert nur manchmal ECMP oder einzelner fehlerhafter Pfad mehrere Tests mit Quellports vergleichen
Verbindung funktioniert nach Wiederholung Synchronisationsverzögerung oder Routingkonvergenz Cluster- und Routingzeitpunkte prüfen
nur neue Verbindungen scheitern Conntrack-Tabelle voll oder neue Policy Kapazität und Insert-Failed-Zähler
bestehende Verbindungen funktionieren Zustand vorhanden, neue Einträge scheitern Sessionlimit und Ressourcenauslastung
nach Failover brechen Sitzungen ab State- oder NAT-Synchronisation unvollständig HA-Protokoll und Tabellen vergleichen
nur lange Leerlaufverbindungen brechen ab Idle-Timeout Timeout und Keepalive vergleichen
UDP bleibt [UNREPLIED] Antwort fehlt oder anderer Rückweg Antwortaufzeichnung und UDP-Timeout
unterschiedliche NAT-Abbildung je Knoten NAT-Synchronisation fehlerhaft Übersetzungstabellen vergleichen
gleicher Firewallname, Sitzung fehlt anderer VSYS, VRF oder Kontext vollständigen Verarbeitungskontext prüfen
Hinweg über VPN, Rückweg über Internet Präfixankündigung oder PBR Routen auf Server- und Gatewayseite
nur ein Zielpräfix betroffen spezifischere Route Longest-Prefix-Match prüfen
nur ein Teil der Clients betroffen Quellrouting, Hash oder PBR Quellen und Quellports vergleichen
Conntrack-Auslastung nahe Grenzwert Tabellenknappheit Neu-, Drop- und Early-Drop-Rate
insert_failed steigt neue Einträge können nicht angelegt werden Tabellenlimit und Speicher prüfen
viele UNREPLIED-Einträge Scans, nicht erreichbare Ziele oder Rückwegproblem Quellen, Ziele und Rate analysieren
Flow ist hardware-offloaded Softwarecapture eventuell unvollständig Hardwarezähler oder externen TAP verwenden
AWS Firewall sieht nur eine Richtung unterschiedliche Firewallendpunkte Routingtabellen je Availability Zone
Azure NVA-Instanzen sehen je eine Richtung Active/Active ohne Flow-Symmetrie ECMP und Session Sharing prüfen
Traceroute wirkt symmetrisch, Sitzung fehlt Traceroute nutzt anderen Datenfluss Capture mit echtem Protokoll und Port
Sitzung vorhanden, keine Anwendung Netzwerkpfad möglicherweise korrekt TLS, Protokoll und Serverdienst prüfen

Typische Diagnosefehler

Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Eine einzelne erfolgreiche Verbindung nach einer Routingänderung ist keine ausreichende Verifikation. Bei ECMP- oder Clusterproblemen müssen mehrere neue Verbindungen mit unterschiedlichen Quellports geprüft werden.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Datum und Uhrzeit:
<Zeitpunkt mit Zeitzone>

Betroffene Anwendung:
<Anwendung oder Dienst>

Originalrichtung:
<Quell-IP:Port -> Ziel-IP:Port/Protokoll>

Antwortrichtung:
<Ziel-IP:Port -> Quell-IP:Port/Protokoll>

NAT vor Übersetzung:
<Adressen und Ports>

NAT nach Übersetzung:
<Adressen und Ports>

Erwarteter Hinweg:
<Netzwerkpfad>

Tatsächlicher Hinweg:
<nachgewiesener Netzwerkpfad>

Erwarteter Rückweg:
<Netzwerkpfad>

Tatsächlicher Rückweg:
<nachgewiesener Netzwerkpfad>

Zustandsbehaftete Komponenten:
<Firewalls, NAT, Load Balancer und Gateways>

Firewall- oder Clusterknoten:
<Name und Rolle>

Virtueller Kontext:
<VSYS, VRF, Mandant oder Routinginstanz>

Sitzungs-ID:
<ID>

Sitzungszustand:
<NEW, ESTABLISHED, UNREPLIED oder produktspezifischer Zustand>

Session Owner:
<Knoten oder Instanz>

Pakete und Bytes:
<je Richtung>

Timeout:
<aktueller Wert und Restzeit>

NAT-Sitzung:
<Übersetzung und Besitzer>

Conntrack-Auslastung:
<Count, Max und Prozent>

Fehlerzähler:
<Drop, Early Drop, Insert Failed oder produktspezifischer Zähler>

Cluster-Synchronisation:
<Status und Befund>

Paketaufzeichnung:
<Befund je Beobachtungspunkt>

Hypothese:
<vermutete Ursache>

Erwarteter Nachweis:
<messbarer Befund>

Gegenbeweis:
<widerlegender Befund>

Nachgewiesene Ursache:
<technischer Nachweis>

Durchgeführte Maßnahme:
<genau eine kontrollierte Änderung>

Risiko:
<mögliche Nebenwirkungen>

Rückweg:
<Rollback>

Verifikation:
<neue Sitzung, Pfad, Zustand und Anwendung>

Prävention:
<Monitoring, Routingdesign oder Prozessverbesserung>

Checkliste

Schnellreferenz

Aufgabe Befehl
Windows-Routingtabelle route print
Windows-Routen Get-NetRoute
Windows-Zielroute Find-NetRoute -RemoteIPAddress "198.51.100.25"
Windows-Traceroute tracert 198.51.100.25
Linux-Zielroute ip route get 198.51.100.25
Linux-Zielroute mit Quelle ip route get 198.51.100.25 from 192.0.2.100
Linux-Policy-Routing ip rule show
Linux-alle Routingtabellen ip route show table all
Linux-IPv6-Route ip -6 route get 2001:db8::25
Linux-Traceroute traceroute 198.51.100.25
Linux-Path-MTU/Pfad tracepath 198.51.100.25
macOS-Zielroute route -n get 198.51.100.25
macOS-Traceroute traceroute 198.51.100.25
Conntrack-Einträge sudo conntrack -L
Conntrack-Anzahl sudo conntrack -C
Conntrack-Statistiken sudo conntrack -S
Conntrack-Ereignisse sudo conntrack -E
aktueller Conntrack-Füllstand sysctl net.netfilter.nf_conntrack_count
maximales Conntrack-Limit sysctl net.netfilter.nf_conntrack_max
Conntrack-Hash-Buckets sysctl net.netfilter.nf_conntrack_buckets
Reverse Path Filtering sysctl net.ipv4.conf.all.rp_filter
Cisco ASA Sitzungen show conn
Cisco ASA Sitzungsanzahl show conn count
Cisco ASA NAT show xlate
Cisco ASA HA show failover
Cisco ASA Drops show asp drop
Juniper Sitzungen show security flow session
Juniper Flow-Statistik show security flow statistics
Juniper Cluster show chassis cluster status
Palo Alto Sitzungssuche show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443
Palo Alto HA show high-availability state

Verändernde Befehle und Maßnahmen, die nicht als erste Diagnose verwendet werden dürfen:

conntrack -F
conntrack -D
clear conn
clear xlate
clear session all
clear security flow session
Firewall-State-Bypass aktivieren
TCP State Bypass aktivieren
Stateful Inspection deaktivieren
Conntrack-Limit ungeprüft erhöhen
Sessiontimeout ungeprüft erhöhen
Routingprotokoll neu starten
Cluster-Failover erzwingen
Firewallcluster neu starten
ECMP global deaktivieren
produktive Route ungeprüft entfernen
SNAT pauschal aktivieren
Hardware-Offloading global deaktivieren

Quellen

Standards und Grundlagen

Linux Kernel und Netfilter

Cisco

Juniper Networks

Amazon Web Services

Microsoft Azure

Für diese Seite wurden keine Community-Beiträge oder Hersteller-Social-Media-Aussagen als fachlicher Nachweis verwendet.

9. TCP, UDP, Ports, Firewall, NAT und Proxy

9.7 Ephemeral Ports und Verbindungsgrenzen

Beim Aufbau einer ausgehenden TCP- oder UDP-Kommunikation benötigt das initiierende System normalerweise einen freien lokalen Quellport. Dieser kurzzeitig verwendete Port wird als dynamischer, temporärer oder ephemerer Port bezeichnet.

Beispiel:

Client:
192.0.2.100:53124

Server:
198.51.100.25:443

Datenfluss:
192.0.2.100:53124 -> 198.51.100.25:443/TCP

Der Server verwendet den bekannten Zielport 443. Der Client verwendet den dynamisch ausgewählten Quellport 53124.

Wenn kein geeigneter Quellport, Socket, Dateideskriptor, NAT-Eintrag oder Verbindungseintrag mehr verfügbar ist, können neue Verbindungen fehlschlagen, obwohl:

Ziele

Nach der Bearbeitung dieser Seite soll nachvollziehbar geprüft werden können:

Sicherheits- und Änderungsgrundsätze

Port- und Verbindungsgrenzen dürfen nicht ohne Ursachenanalyse verändert werden. Eine größere Grenze kann das Symptom verschieben, während die eigentliche Ursache bestehen bleibt.

Mögliche Ursachen sind:

Nicht als erste Diagnosemaßnahme geeignet sind:

Vor jeder Änderung sind zu dokumentieren:

Portnummernbereiche

IANA unterscheidet folgende Bereiche:

Bereich Bezeichnung Typische Verwendung
0–1023 System Ports bekannte und besonders geschützte Dienste
1024–49151 User Ports registrierte Anwendungsdienste
49152–65535 Dynamic/Private Ports dynamische oder private Verwendung

Der IANA-Bereich 49152–65535 ist eine allgemeine Einteilung. Er beweist nicht, dass ein Betriebssystem lokal genau diesen Bereich verwendet.

Der tatsächlich verwendete Bereich kann abhängen von:

Deshalb muss der aktuelle Bereich auf dem betroffenen System ausgelesen werden.

Ephemeren Quellport und Serverport unterscheiden

Normale Clientverbindung:

192.0.2.100:53124 -> 198.51.100.25:443/TCP
Port Rolle
53124 dynamischer Quellport des Clients
443 Zielport des Serverdienstes

Rückverkehr:

198.51.100.25:443 -> 192.0.2.100:53124/TCP

Der Server benötigt nicht für jeden eingehenden Client einen neuen lokalen Listenerport. Alle HTTPS-Verbindungen können lokal den Serverport 443 verwenden, weil die vollständigen Verbindungen durch unterschiedliche Adressen und Ports unterscheidbar bleiben.

Das Verbindungstupel

Eine TCP- oder UDP-Kommunikation wird typischerweise über folgende Merkmale unterschieden:

Quelladresse
Quellport
Zieladresse
Zielport
Protokoll

Beispiel:

192.0.2.100:53124 -> 198.51.100.25:443/TCP

Eine gleichzeitig bestehende Verbindung kann denselben lokalen Port möglicherweise gegenüber einem anderen Ziel verwenden:

192.0.2.100:53124 -> 203.0.113.80:443/TCP

Ob und wie ein Betriebssystem lokale Ports zwischen verschiedenen Zielen wiederverwendet, hängt von Implementierung, Bindungsart und Socketoptionen ab.

Deshalb gilt nicht allgemein:

Anzahl dynamischer Ports =
maximale Gesamtzahl aller ausgehenden Verbindungen

Die Grenze muss immer im Zusammenhang mit Quelladresse, Zieladresse, Zielport, Protokoll, NAT und Verbindungszustand bewertet werden.

Anzahl eines Portbereichs berechnen

Allgemeine Berechnung:

Anzahl =
Endport - Startport + 1

Beispiel:

Startport:
49152

Endport:
65535

Anzahl:
65535 - 49152 + 1
= 16384 Ports

Davon können abzuziehen sein:

Die theoretische Anzahl ist deshalb keine garantierte Verbindungskapazität.

TCP und UDP getrennt betrachten

TCP und UDP besitzen getrennte Protokollräume. Derselbe numerische Port kann gleichzeitig für TCP und UDP verwendet werden.

Beispiel:

TCP 53124
UDP 53124

Das sind zwei unterschiedliche Transportendpunkte.

Zu prüfen sind daher getrennt:

Eine funktionierende UDP-Verbindung beweist nicht, dass noch TCP-Ports verfügbar sind.

IPv4 und IPv6 getrennt prüfen

Betriebssysteme und Plattformen können Portbereiche oder Zustände für IPv4 und IPv6 getrennt verwalten.

Zu prüfen sind:

Eine Anwendung kann bei einem Namensaufruf mehrere IPv6- und IPv4-Verbindungen starten. Dadurch kann die Zahl der Verbindungsversuche höher sein als die Zahl sichtbarer Benutzeranfragen.

Lokale und übersetzte Ports unterscheiden

Ein NAT- oder SNAT-Gerät kann den lokalen Quellport verändern.

Beispiel:

Vor SNAT:
10.10.20.25:53124 -> 203.0.113.80:443

Nach SNAT:
198.51.100.5:61001 -> 203.0.113.80:443

Dabei existieren zwei unterschiedliche Portbetrachtungen:

Ebene Port
lokaler Clientport 53124
externer SNAT-Port 61001

Der Client kann lokal noch Ports besitzen, während der SNAT-Portpool des Gateways erschöpft ist. Umgekehrt kann das NAT-Gateway noch Kapazität besitzen, während das lokale Betriebssystem keinen geeigneten Quellport mehr findet.

Lokale Porterschöpfung

Lokale Porterschöpfung liegt vor, wenn ein System für eine neue ausgehende Kommunikation keinen geeigneten lokalen Port beziehungsweise kein verwendbares lokales Verbindungstupel mehr zuweisen kann.

Typische Symptome:

Mögliche Fehlermeldungen sind abhängig von Betriebssystem und Anwendung:

Cannot assign requested address
Address already in use
No buffer space available
Too many open files
Only one usage of each socket address is normally permitted
Connection timed out
Connection failed

Diese Meldungen sind nicht gleichbedeutend. Beispielsweise kann Address already in use auch auf eine einzelne explizite Portkollision hinweisen.

SNAT-Porterschöpfung

Bei SNAT teilen sich mehrere interne Systeme eine oder mehrere externe IP-Adressen.

Beispiel:

10.10.20.11 -> 198.51.100.5
10.10.20.12 -> 198.51.100.5
10.10.20.13 -> 198.51.100.5

Das NAT-Gateway muss die Verbindungen über externe Quellports eindeutig zuordnen.

Eine hohe Konzentration auf dasselbe Ziel kann besonders kritisch sein:

viele interne Systeme
        ->
eine öffentliche NAT-Adresse
        ->
eine Zieladresse
        ->
ein Zielport

Beispiel:

1000 interne Anwendungsinstanzen
        ->
198.51.100.5
        ->
203.0.113.80:443

Mögliche Symptome:

Porterschöpfung pro Ziel einordnen

Der kritische Grenzfall ist häufig nicht die Gesamtzahl aller Ziele, sondern eine hohe Zahl gleichzeitiger oder schnell wiederholter Verbindungen zu genau derselben Kombination aus:

Ziel-IP-Adresse
Zielport
Protokoll

Beispiel:

203.0.113.80:443/TCP

Ein API-Gateway, Datenbankserver, Proxy oder zentrales Authentifizierungssystem kann dadurch einen besonders konzentrierten Portbedarf erzeugen.

Zu prüfen sind:

TIME_WAIT

Nach dem regulären Ende einer TCP-Verbindung kann das System das Verbindungstupel für eine bestimmte Zeit im Zustand TIME_WAIT halten.

Zweck ist unter anderem:

Viele TIME_WAIT-Einträge sind nicht automatisch ein Fehler. Sie zeigen jedoch eine hohe Rate kurzlebiger TCP-Verbindungen.

Kritisch wird die Situation, wenn gleichzeitig:

Ein hoher TIME_WAIT-Bestand ohne Verbindungsfehler beweist keine aktuelle Porterschöpfung.

CLOSE_WAIT

CLOSE_WAIT bedeutet vereinfacht:

  1. Die Gegenstelle hat das Ende der Verbindung angekündigt.
  2. Das lokale Betriebssystem hat dies an die Anwendung gemeldet.
  3. Die lokale Anwendung hat ihren Socket noch nicht vollständig geschlossen.

Viele dauerhaft bestehende CLOSE_WAIT-Einträge können auf eine Anwendung hinweisen, die Verbindungen nicht korrekt schließt.

Zu prüfen sind:

CLOSE_WAIT beweist nicht automatisch eine erschöpfte dynamische Portmenge. Es kann jedoch gleichzeitig Sockets, Dateideskriptoren, Speicher und lokale Verbindungstupel binden.

SYN_SENT

Viele Verbindungen im Zustand SYN_SENT bedeuten, dass das lokale System Verbindungsanfragen gesendet hat, aber der TCP-Handshake noch nicht abgeschlossen wurde.

Mögliche Ursachen:

Viele lang anhaltende SYN_SENT-Verbindungen können Ports und Sockets binden, obwohl keine erfolgreiche Anwendungskommunikation entsteht.

ESTABLISHED

Viele ESTABLISHED-Verbindungen können beabsichtigt sein, beispielsweise bei:

Zu prüfen sind:

Eine hohe Zahl etablierter Verbindungen ist nicht automatisch Porterschöpfung. Sie kann jedoch andere Grenzwerte erreichen.

FIN_WAIT und LAST_ACK

Viele Verbindungen in Zuständen des Verbindungsabbaus können auf Probleme beim sauberen Beenden hinweisen.

Zu prüfen sind:

Die genaue Bedeutung ist anhand der TCP-Zustandsfolge und einer Paketaufzeichnung zu prüfen.

UDP und QUIC

UDP besitzt keinen TCP-Verbindungsabbau und keinen TCP-TIME_WAIT-Zustand. Trotzdem können UDP-Sockets, NAT-Zuordnungen und Connection-Tracking-Einträge Ports belegen.

Betroffene Anwendungen können sein:

Zu prüfen sind:

Eine Analyse ausschließlich der TCP-Verbindungen übersieht UDP- oder QUIC-bedingte Engpässe.

RPC-Dynamik nicht mit Clientports verwechseln

Windows RPC kann nach dem Kontakt zum RPC Endpoint Mapper auf TCP-Port 135 einen dynamischen Serverport verwenden.

Vereinfachter Ablauf:

  1. Client kontaktiert Ziel auf TCP 135.
  2. Endpoint Mapper nennt den dynamischen Serverport.
  3. Client verbindet sich mit diesem Zielport.
  4. Der Client verwendet dafür zusätzlich einen eigenen dynamischen Quellport.

Beispiel:

Client:
192.0.2.100:53124

RPC-Server:
198.51.100.25:52044

Verbindung:
192.0.2.100:53124 -> 198.51.100.25:52044/TCP

Dabei sind beide Ports dynamisch, aber mit unterschiedlichen Rollen:

Port Rolle
53124 dynamischer Clientquellport
52044 dynamisch zugewiesener RPC-Serverzielport

Firewallregeln müssen diese Rollen korrekt berücksichtigen.

Porterschöpfung und andere Verbindungsgrenzen unterscheiden

Grenze Typischer Befund
dynamischer lokaler Portbereich kein geeigneter Quellport für neue Verbindung
SNAT-Portpool NAT-Gerät kann keine neue Übersetzung anlegen
Socketgrenze Anwendung oder Kernel kann keinen weiteren Socket anlegen
Dateideskriptorgrenze Prozess erhält beispielsweise Too many open files
Prozesshandlegrenze Betriebssystem oder Prozess erreicht Handlegrenze
Conntrack-Tabelle Firewall oder Router kann keinen neuen Zustand anlegen
Firewall-Sessionlimit neue Sitzungen werden verworfen
NAT-Sessionlimit neue NAT-Zuordnungen schlagen fehl
TCP-SYN-Backlog neue Handshakes warten oder werden verworfen
Accept-Backlog vollständig aufgebaute Verbindungen werden nicht schnell genug angenommen
Anwendungslimit Dienst erlaubt nur definierte Zahl paralleler Verbindungen
Connection-Pool-Limit Anwendung wartet auf freien Poolplatz
Thread- oder Workerlimit Verbindungen werden nicht rechtzeitig verarbeitet
Datenbanklimit maximale Datenbanksitzungen erreicht
Load-Balancer-Limit Flow-, Port- oder Zielgrenze erreicht
Cloudquote plattformspezifische Obergrenze erreicht
Zielsystemlimit Gegenstelle begrenzt Quellen oder Verbindungsrate
API-Rate-Limit Anwendung lehnt Anfragen trotz funktionierender TCP-Verbindung ab

Ein erfolgreicher TCP-Porttest beweist nicht, dass die Anwendung noch einen Datenbankpoolplatz oder Worker besitzt.

Windows: dynamischen Portbereich anzeigen

IPv4 TCP:

netsh int ipv4 show dynamicport tcp

IPv4 UDP:

netsh int ipv4 show dynamicport udp

IPv6 TCP:

netsh int ipv6 show dynamicport tcp

IPv6 UDP:

netsh int ipv6 show dynamicport udp

Bei aktuellen unterstützten Windows-Versionen ist der Standardbereich normalerweise:

Startport:
49152

Endport:
65535

Anzahl:
16384

Der tatsächliche Systemwert ist trotzdem mit netsh zu prüfen. TCP, UDP, IPv4 und IPv6 werden getrennt angezeigt.

Windows: TCP-Verbindungen anzeigen

Alle TCP-Verbindungen:

Get-NetTCPConnection

Etablierte Verbindungen:

Get-NetTCPConnection `
  -State Established

TIME_WAIT:

Get-NetTCPConnection `
  -State TimeWait

CLOSE_WAIT:

Get-NetTCPConnection `
  -State CloseWait

Ausgehende Verbindungsversuche:

Get-NetTCPConnection `
  -State SynSent

Nach Ziel filtern:

Get-NetTCPConnection `
  -RemoteAddress "198.51.100.25" `
  -RemotePort 443

Nach Prozess-ID filtern:

Get-NetTCPConnection `
  -OwningProcess <PID>

Prozess bestimmen:

Get-Process `
  -Id <PID>

Windows: Zustände zählen

Get-NetTCPConnection |
  Group-Object State |
  Sort-Object Count -Descending |
  Select-Object Count, Name

Mögliche Ausgabe:

Count Name
----- ----
 8200 TimeWait
 1450 Established
  200 CloseWait
   35 SynSent

Die Werte müssen mit einer Baseline und dem aktuellen Fehlerzeitpunkt verglichen werden.

Windows: Verbindungen je Prozess zählen

Get-NetTCPConnection |
  Group-Object OwningProcess |
  Sort-Object Count -Descending |
  Select-Object -First 20 Count, Name

Die Spalte Name enthält in diesem Fall die Prozess-ID.

Einzelne Prozess-IDs auflösen:

Get-Process `
  -Id <PID>

Ausführlicher Zusammenhang:

Get-NetTCPConnection |
  ForEach-Object {
    $process = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue

    [PSCustomObject]@{
      State         = $_.State
      LocalAddress  = $_.LocalAddress
      LocalPort     = $_.LocalPort
      RemoteAddress = $_.RemoteAddress
      RemotePort    = $_.RemotePort
      PID           = $_.OwningProcess
      Process       = $process.ProcessName
    }
  } |
  Sort-Object Process, State

Auf stark belasteten Systemen kann diese Auswertung umfangreich sein. Sie sollte gezielt und während des Fehlerzeitraums durchgeführt werden.

Windows: häufigste Ziele ermitteln

Get-NetTCPConnection |
  Where-Object State -ne Listen |
  Group-Object RemoteAddress, RemotePort |
  Sort-Object Count -Descending |
  Select-Object -First 20 Count, Name

Damit kann festgestellt werden, ob sich sehr viele Verbindungen auf ein einzelnes Ziel konzentrieren.

Windows: klassische Netstat-Auswertung

Verbindungen, Ports und Prozess-IDs:

netstat -ano

Mit ausführbarer Datei, administrative Eingabeaufforderung erforderlich:

netstat -anob

Gebundene Ports einschließlich bestimmter nicht aktiver TCP-Bindungen:

netstat -anoq

TIME_WAIT zählen:

netstat -ano | find /c "TIME_WAIT"

CLOSE_WAIT zählen:

netstat -ano | find /c "CLOSE_WAIT"

SYN_SENT zählen:

netstat -ano | find /c "SYN_SENT"

Ein einfacher Textzähler ist nur ein Indikator. Für die Zuordnung zu Prozess, Ziel, Zeit und Portbereich ist die vollständige Ausgabe erforderlich.

Windows: Ereignisse prüfen

Windows kann bei Porterschöpfung unter anderem TCP/IP-Ereignisse 4227 und 4231 protokollieren.

Gezielte Suche:

Get-WinEvent `
  -FilterHashtable @{
    LogName   = "System"
    Id        = 4227, 4231
    StartTime = (Get-Date).AddHours(-24)
  } |
  Select-Object TimeCreated, Id, ProviderName, Message

Die Ereignisse müssen zeitlich mit den tatsächlichen Verbindungsfehlern korreliert werden.

Ein hoher TIME_WAIT-Bestand allein bestätigt keine Porterschöpfung. Microsoft empfiehlt zusätzlich, reale ausgehende Verbindungsfehler und passende Ereignisse nachzuweisen.

Windows: Portbereich eines Tests berücksichtigen

Wenn der ausgelesene TCP-Bereich beispielsweise 49152–65535 lautet:

$startPort = 49152
$endPort   = 65535

Get-NetTCPConnection |
  Where-Object {
    $_.LocalPort -ge $startPort -and
    $_.LocalPort -le $endPort
  } |
  Group-Object State |
  Sort-Object Count -Descending |
  Select-Object Count, Name

Die Werte müssen an den tatsächlich mit netsh ermittelten Bereich angepasst werden.

Linux: lokalen Portbereich anzeigen

sysctl net.ipv4.ip_local_port_range

Alternative:

cat /proc/sys/net/ipv4/ip_local_port_range

Beispielausgabe:

32768 60999

Das ist nur ein Beispiel. Die lokale Ausgabe ist maßgeblich.

Reservierte lokale Ports:

sysctl net.ipv4.ip_local_reserved_ports

Alternative:

cat /proc/sys/net/ipv4/ip_local_reserved_ports

ip_local_port_range und ip_local_reserved_ports sind getrennte Einstellungen. Beide beeinflussen, welche Ports für automatische Zuweisungen zur Verfügung stehen.

Linux: Socketübersicht

ss -s

Mögliche Bereiche der Zusammenfassung:

Die genaue Darstellung hängt von der installierten iproute2-Version ab.

Linux: TCP-Verbindungen anzeigen

Alle TCP-Sockets:

ss -tan

Mit Prozessinformationen:

sudo ss -tanp

Etablierte Verbindungen:

ss -tan state established

TIME_WAIT:

ss -tan state time-wait

CLOSE_WAIT:

ss -tan state close-wait

SYN_SENT:

ss -tan state syn-sent

Listener:

ss -lntp

Nach Ziel filtern:

ss -tanp \
  dst 198.51.100.25:443

Linux: Zustände zählen

ss -Htan |
  awk '{print $1}' |
  sort |
  uniq -c |
  sort -nr

Nur TIME_WAIT zählen:

ss -Htan state time-wait |
  wc -l

Nur CLOSE_WAIT zählen:

ss -Htan state close-wait |
  wc -l

Nur SYN_SENT zählen:

ss -Htan state syn-sent |
  wc -l

Linux: Kernel-Socketstatistik

IPv4 und allgemeine Socketstatistik:

cat /proc/net/sockstat

IPv6:

cat /proc/net/sockstat6

Mögliche Felder sind unter anderem:

Die Werte sind Momentaufnahmen und müssen mit einer Baseline verglichen werden.

Linux: Dateideskriptorgrenzen

Grenze der aktuellen Shell:

ulimit -n

Grenzen eines laufenden Prozesses:

cat /proc/<PID>/limits

Offene Dateideskriptoren eines Prozesses zählen:

ls -1 /proc/<PID>/fd |
  wc -l

Systemweite Dateideskriptorinformationen:

cat /proc/sys/fs/file-nr

Systemweite Obergrenze:

sysctl fs.file-max

Sockets werden unter Unix-ähnlichen Betriebssystemen über Dateideskriptoren angesprochen. Ein Prozess kann deshalb die Dateideskriptorgrenze erreichen, obwohl im dynamischen Portbereich noch Ports frei sind.

Linux: Listener- und Backloggrenzen

Aktuelle Listener:

ss -lnt

Globale Obergrenze des Listen-Backlogs:

sysctl net.core.somaxconn

TCP-SYN-Backlog:

sysctl net.ipv4.tcp_max_syn_backlog

Bei einem Listening Socket zeigt ss abhängig von Version und Kontext unter anderem aktuelle und maximale Warteschlangenwerte an.

Ein Backlogproblem betrifft eingehende Verbindungen und ist nicht mit ausgehender Porterschöpfung gleichzusetzen.

Linux: Conntrack zusätzlich prüfen

Anzahl aktuell verfolgter Verbindungen:

sysctl net.netfilter.nf_conntrack_count

Maximalwert:

sysctl net.netfilter.nf_conntrack_max

Statistiken, sofern conntrack-tools installiert ist:

sudo conntrack -S

Eine volle Conntrack-Tabelle kann neue Verbindungen verhindern, obwohl das lokale Betriebssystem noch Quellports besitzt.

macOS: Portbereich prüfen

Verfügbare Portbereichsparameter anzeigen:

sysctl -a |
  awk '/net\.inet\.ip\.portrange/'

Je nach macOS-Version können unter anderem folgende Werte verfügbar sein:

sysctl net.inet.ip.portrange.first

sysctl net.inet.ip.portrange.last

sysctl net.inet.ip.portrange.hifirst

sysctl net.inet.ip.portrange.hilast

Die tatsächlich vorhandenen Parameter und Werte sind auf dem betroffenen Mac zu prüfen.

macOS: Verbindungen und Prozesse prüfen

TCP-Verbindungen:

netstat -anv -p tcp

TCP-Sockets mit Prozessen:

sudo lsof -nP -iTCP

Nur etablierte TCP-Verbindungen:

sudo lsof -nP -iTCP -sTCP:ESTABLISHED

Nur Listener:

sudo lsof -nP -iTCP -sTCP:LISTEN

TCP-Statistik:

netstat -s -p tcp

Interaktive Netzwerksicht:

nettop -m tcp

Die genaue Ausgabe unterscheidet sich je nach macOS-Version.

Prozess statt nur Portbereich untersuchen

Die wichtigste Frage lautet häufig:

Welcher Prozess erzeugt die Verbindungen?

Zu dokumentieren sind:

Ein Portbereich sollte nicht erweitert werden, bevor der verursachende Prozess und sein Verbindungsverhalten bekannt sind.

Verbindungsrate und gleichzeitige Verbindungen unterscheiden

Metrik Bedeutung
gleichzeitige Verbindungen aktuell parallel bestehende Datenflüsse
neue Verbindungen pro Sekunde Geschwindigkeit des Verbindungsaufbaus
geschlossene Verbindungen pro Sekunde Geschwindigkeit des Abbaus
TIME_WAIT-Bestand noch nicht vollständig wiederverwendbare TCP-Zustände
durchschnittliche Lebensdauer Zeit bis zum Verbindungsende
Retryrate zusätzliche Versuche nach Fehler oder Timeout
Wiederverwendungsquote Anfragen pro bestehender Verbindung

Eine Anwendung mit nur wenigen gleichzeitig aktiven Anfragen kann trotzdem sehr viele Ports verbrauchen, wenn sie für jede Anfrage eine neue Verbindung erstellt.

Planungsnäherung für kurzlebige Verbindungen

Vereinfachte Abschätzung:

dauerhaft mögliche neue Verbindungen pro Sekunde
≈
verfügbare Portkombinationen / Belegungsdauer

Beispiel:

verfügbare Ports:
16384

angenommene Belegungsdauer:
240 Sekunden

Näherung:
16384 / 240
≈ 68 neue Verbindungen pro Sekunde

Diese Rechnung ist nur ein vereinfachtes Planungsmodell für eine konzentrierte Zielkombination. Das reale Verhalten hängt unter anderem ab von:

Die Näherung darf nicht als garantierter Grenzwert verwendet werden.

Connection Pooling

Connection Pooling hält eine begrenzte Menge bestehender Verbindungen bereit und verwendet sie für mehrere Vorgänge erneut.

Mögliche Vorteile:

Zu prüfen sind:

Ein unbegrenzt großer Pool beseitigt keine Kapazitätsgrenzen und kann das Zielsystem überlasten.

HTTP-Verbindungen wiederverwenden

Für HTTP-basierte Anwendungen sind relevant:

Ein häufiges Fehlmuster ist die Erstellung eines neuen HTTP-Clients und einer neuen TCP-/TLS-Verbindung für jede einzelne Anfrage.

Besser ist eine kontrollierte Wiederverwendung mit:

Die konkrete Implementierung hängt von Programmiersprache, Framework und Bibliothek ab.

Retries kontrollieren

Ein langsames oder ausgefallenes Ziel kann einen Retry-Sturm auslösen.

Beispiel:

100 Anfragen
× 5 sofortige Wiederholungen
= 500 Verbindungsversuche

Bei mehreren Anwendungsinstanzen:

500 Versuche
× 20 Instanzen
= 10000 Verbindungsversuche

Zu prüfen sind:

Sofortige und unbegrenzte Retries können eine kleine Störung zu Port-, Socket- und Zielüberlastung verstärken.

AWS NAT Gateway

AWS dokumentiert für ein NAT Gateway pro zugeordneter IPv4-Adresse bis zu 55.000 gleichzeitige Verbindungen zu jedem eindeutigen Ziel.

Ein eindeutiges Ziel wird dabei bestimmt durch:

Ziel-IP-Adresse
Zielport
Protokoll

Zu prüfen sind:

Mögliche relevante CloudWatch-Metriken sind abhängig vom Ressourcentyp unter anderem:

Zusätzliche NAT-IP-Adressen können die Kapazität erhöhen. Vorher muss jedoch geprüft werden, ob die Anwendung unnötig viele neue Verbindungen erstellt.

Azure NAT Gateway

Azure NAT Gateway stellt pro öffentlicher IPv4-Adresse 64.512 SNAT-Ports bereit. Ein NAT Gateway kann mehrere öffentliche IP-Adressen verwenden.

Microsoft dokumentiert außerdem eine Grenze gleichzeitiger Verbindungen je eindeutigem Zielendpunkt. Die jeweils aktuelle Plattformdokumentation ist für die eingesetzte Ressource zu prüfen.

Zu prüfen sind:

TCP und UDP besitzen beim Azure NAT Gateway getrennte SNAT-Portinventare.

Azure Load Balancer

Ein Azure Load Balancer kann ausgehende SNAT-Ports nach konfigurierten Outbound Rules und Backendanzahl zuteilen.

Zu prüfen sind:

Eine ungleichmäßige Verbindungsverteilung kann dazu führen, dass eine einzelne Backendinstanz ihre Portzuteilung erreicht, obwohl andere Instanzen noch Kapazität besitzen.

Google Cloud NAT

Google Cloud NAT kann Ports statisch oder dynamisch auf VMs verteilen.

Zu prüfen sind:

Bei dynamischer Portzuweisung kann eine schnelle Laststeigerung vorübergehend Pakete verlieren, während die Portzuweisung erweitert wird. Lasttests sollten deshalb auch den Anstieg der Verbindungsrate berücksichtigen.

Container und Kubernetes

Mehrere Container oder Pods können sich einen Host-, Node- oder NAT-Portpool teilen.

Zu prüfen sind:

Beispiel:

50 Pods
× 200 ausgehende Poolverbindungen
= 10000 Verbindungen

Ein Scale-out kann den Gesamtportbedarf erhöhen, obwohl jede einzelne Instanz unverändert arbeitet.

Proxies und Gateways

Forward Proxies, Reverse Proxies, API Gateways und Service-Mesh-Sidecars initiieren eigene ausgehende Verbindungen.

Dadurch existieren getrennte Verbindungsabschnitte:

Client -> Proxy
Proxy  -> Ziel

Zu prüfen sind für jeden Abschnitt:

Der Client kann ausreichend Ports besitzen, während der Proxy seinen ausgehenden Portpool erschöpft.

Firewalls und Connection Tracking

Zusätzlich zum Quellport muss eine Stateful Firewall oder ein NAT-Router häufig einen Sitzungseintrag anlegen.

Zu prüfen sind:

Eine Portbereichserweiterung am Client kann die Firewall stärker belasten und dort die nächste Grenze erreichen.

Serverseitige Verbindungsgrenzen

Wenn eingehende Verbindungen scheitern, sind zusätzlich zu prüfen:

Typische Unterscheidung:

Befund Mögliche Einordnung
SYN erhält keine Antwort Netzwerk, Firewall, Backlog oder Überlastung
SYN erhält RST kein Listener oder aktive Ablehnung
TCP-Handshake erfolgreich, Anwendung wartet Worker-, Pool- oder Backendproblem
bestehende Clients funktionieren, neue nicht Backlog, Verbindungslimit oder Ressourcenerschöpfung
nur ausgehende Serveraufrufe scheitern lokale Ports, NAT, Pool oder Zielproblem

Baseline erfassen

Eine Port- und Verbindungsdiagnose benötigt Vergleichswerte.

Sinnvolle Baseline:

dynamischer Portbereich
TCP-Verbindungen gesamt
UDP-Sockets gesamt
ESTABLISHED
TIME_WAIT
CLOSE_WAIT
SYN_SENT
LISTEN
Verbindungen je Prozess
Verbindungen je Ziel
neue Verbindungen pro Sekunde
Dateideskriptoren je Prozess
Conntrack-Auslastung
NAT-Sitzungen
SNAT-Portnutzung
Fehlerzähler
CPU und Speicher

Messpunkte:

Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Der Anwendungsdienst erstellt für jeden API-Aufruf eine neue
HTTPS-Verbindung zum Ziel 203.0.113.80:443. Die Verbindungen
verbleiben anschließend in TIME_WAIT, bis der dynamische
TCP-Portbereich erschöpft ist.

Erwarteter Befund:
Während der Störung schlagen neue ausgehende Verbindungen fehl.
Windows protokolliert Ereignis 4227 oder 4231.
Die Anzahl der TIME_WAIT-Verbindungen zum Ziel
203.0.113.80:443 ist sehr hoch und gehört überwiegend zum
gleichen Prozess.

Gegenbeweis:
Der dynamische Portbereich besitzt während der Störung ausreichend
freie Kapazität, es existieren keine passenden TCP/IP-Ereignisse,
und der Verbindungsfehler tritt bereits vor der lokalen Portzuweisung
oder ausschließlich am Zielsystem auf.

Testmethode:
Portbereich, Get-NetTCPConnection, Prozesszuordnung,
Systemereignisse und eine kontrollierte Testverbindung zeitlich
korrelieren.

Risiko:
Nur lesende Diagnose.

Erfolgskriterium:
Portbelegung, verursachender Prozess, Zielkonzentration und
Verbindungsfehler sind für denselben Zeitpunkt nachgewiesen.

Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko Rückweg
Connection Pooling aktivieren hohe Rate kurzlebiger Verbindungen bestätigt fehlerhafte Altverbindungen können wiederverwendet werden vorherige Clientkonfiguration
HTTP-Verbindungen wiederverwenden neue Verbindung pro Anfrage nachgewiesen DNS- und Lebensdauerverhalten beachten vorheriges Clientverhalten
Poolgröße begrenzen unkontrolliert großer Pool bestätigt Wartezeiten bei Last vorherige Poolgröße
Retries begrenzen Retry-Sturm nachgewiesen einzelne Anfrage schlägt früher fehl vorherige Retrykonfiguration
Backoff und Jitter ergänzen gleichzeitige Wiederholungen vieler Instanzen längere Wiederherstellungszeit alte Retryrichtlinie
Anwendung korrigieren nicht geschlossene Sockets bestätigt Deploymentrisiko vorherige Anwendungsversion
Portbereich erweitern tatsächliche lokale Porterschöpfung bestätigt Überschneidungen und höhere Folgelast vorherigen Bereich wiederherstellen
zusätzliche Quell-IP verwenden Kapazitätsbedarf und Architektur bestätigt Routing, Firewall und Freigaben ändern sich alte IP-Zuordnung
zusätzliche NAT-IP verwenden SNAT-Erschöpfung bestätigt Kosten und Ziel-Allowlisting zusätzliche IP entfernen
NAT-Gateway skalieren Plattformmetrik bestätigt Engpass Kosten und Architekturänderung vorherige Ressourcengröße
Timeouts anpassen ungeeigneter Timeout nachgewiesen veraltete Zustände oder höhere Last alten Timeoutwert wiederherstellen
Dateideskriptorgrenze erhöhen FD-Limit nachgewiesen und Speicher ausreichend höherer Ressourcenverbrauch alten Grenzwert wiederherstellen
Conntrack-Kapazität erhöhen Tabellenlimit nachgewiesen höherer Speicherverbrauch alten Wert wiederherstellen
Serverpool skalieren Zielkapazität nachgewiesen zusätzliche Verbindungen und Kosten Skalierung zurücknehmen

Die Ursachenbehebung in der Anwendung ist einer dauerhaften rein infrastrukturellen Vergrößerung vorzuziehen, wenn die Anwendung unnötig viele Verbindungen erzeugt.

Vollständiger Diagnoseablauf

  1. Exakte Fehlermeldung erfassen.
  2. Datum, Uhrzeit und Zeitzone dokumentieren.
  3. Betroffene Anwendung bestimmen.
  4. Ausgehende und eingehende Verbindungen unterscheiden.
  5. Quell- und Zielsystem bestimmen.
  6. Quelladresse und Zieladresse erfassen.
  7. Quellport und Zielport erfassen.
  8. TCP, UDP und QUIC unterscheiden.
  9. IPv4 und IPv6 unterscheiden.
  10. Umfang der Störung bestimmen.
  11. Prüfen, ob bestehende Verbindungen weiter funktionieren.
  12. Prüfen, ob nur neue Verbindungen scheitern.
  13. Dynamischen Portbereich auslesen.
  14. Reservierte und ausdrücklich gebundene Ports berücksichtigen.
  15. Anzahl aktueller TCP-Verbindungen erfassen.
  16. UDP-Sockets erfassen.
  17. TCP-Zustände gruppieren.
  18. TIME_WAIT auswerten.
  19. CLOSE_WAIT auswerten.
  20. SYN_SENT auswerten.
  21. Verbindungen nach Prozess gruppieren.
  22. Verbindungen nach Ziel gruppieren.
  23. Verbindungsrate messen.
  24. Retryrate bestimmen.
  25. Connection-Pool-Konfiguration prüfen.
  26. Dateideskriptoren und Handles prüfen.
  27. Listener- und Backloggrenzen prüfen.
  28. Anwendungs- und Workerlimits prüfen.
  29. Conntrack-Auslastung prüfen.
  30. Firewall- und NAT-Sitzungsgrenzen prüfen.
  31. Vor-NAT- und Nach-NAT-Ports dokumentieren.
  32. SNAT-Portnutzung prüfen.
  33. Cloudmetriken und Port Allocation Errors prüfen.
  34. Container-, Node- und Podkontext berücksichtigen.
  35. Proxy- und Sidecar-Verbindungen getrennt prüfen.
  36. Anwendungsprotokolle auswerten.
  37. Betriebssystemereignisse auswerten.
  38. kontrollierte Testverbindung durchführen.
  39. bei Bedarf Paketaufzeichnung durchführen.
  40. Hypothese und Gegenbeweis formulieren.
  41. genau eine kontrollierte Maßnahme vorbereiten.
  42. Risiko, Rückweg und Erfolgskriterium dokumentieren.
  43. Maßnahme freigeben und umsetzen.
  44. neue Verbindungen unter gleicher Last testen.
  45. Portbelegung und Zustände erneut messen.
  46. SNAT-, Conntrack- und Fehlerzähler erneut prüfen.
  47. ursprüngliche Anwendung verifizieren.
  48. Nebenwirkungen auf andere Dienste prüfen.
  49. temporäre Diagnosemaßnahmen zurücknehmen.
  50. Ursache, Maßnahme und Prävention dokumentieren.

Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
bestehende Verbindungen funktionieren, neue nicht Port-, NAT-, Conntrack- oder Backloggrenze jeweilige Auslastungszähler prüfen
viele TIME_WAIT hohe Rate kurzlebiger TCP-Verbindungen Prozess, Ziel und Verbindungsrate
viele CLOSE_WAIT Anwendung schließt Sockets nicht Prozess und Anwendungscode prüfen
viele SYN_SENT Ziel antwortet nicht oder Rückweg fehlt Paketaufzeichnung und Route
viele ESTABLISHED Pool oder Langzeitverbindungen Aktivität, Poolgrenze und Alter
Windows-Ereignis 4227 lokaler Endpunkt kann nicht sicher wiederverwendet werden Portbestand und Prozesszuordnung
Windows-Ereignis 4231 Zuweisung eines ephemeren Ports fehlgeschlagen dynamischen Bereich und Belegung prüfen
Cannot assign requested address kein verwendbarer lokaler Endpunkt oder falsche Bindung Ports, lokale IP und Anwendung
Too many open files Dateideskriptorgrenze Prozesslimits und offene FDs
lokale Ports frei, Cloudfehler bleibt SNAT- oder Plattformgrenze Cloudmetrik und NAT-Gateway
nur ein Ziel betroffen Verbindungen pro Zielkombination erschöpft Ziel-IP, Port und Protokoll gruppieren
andere Ziele funktionieren zielbezogene NAT- oder Gegenstellenbegrenzung Zielkonzentration und Plattformlimit
Neustart hilft nur vorübergehend Zustände werden geleert, Ursache bleibt Wachstum über die Zeit erfassen
zusätzliche NAT-IP hilft SNAT-Kapazität wahrscheinlich betroffen Port Allocation Error vor und nach Änderung
mehr Pods verschlechtern Fehler Gesamtpool und Verbindungsrate steigen Poolgröße × Podanzahl berechnen
nur Lastspitzen betroffen Portzuweisung oder Rate überschritten Verbindungen pro Sekunde messen
TCP funktioniert, UDP nicht getrennte UDP-Port- oder NAT-Grenze UDP-Sockets und NAT-Timeout
HTTP/1.1 problematisch, HTTP/2 besser Multiplexing reduziert Verbindungen Verbindungsrate vergleichen
Firewall-Sessions voll Connection Tracking oder Sessionlimit Firewallstatistik und Drops
Serverhandshake gelingt, Anfrage wartet Worker-, Pool- oder Backendgrenze Anwendungsmetriken
Listener-Queue wächst Anwendung akzeptiert zu langsam CPU, Worker und Backlog
Pool erschöpft, Ports frei Anwendungslimit statt Portlimit Poolwartezeit und Poolbelegung
viele Retries Fehler verstärkt Verbindungslast Backoff- und Retrykonfiguration
Portbereich angepasst, Fehler wandert zur Firewall nachgelagerte Grenze erreicht Firewall- und Conntrack-Kapazität

Typische Diagnosefehler

Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Eine erfolgreiche Einzelverbindung direkt nach einem Neustart ist keine ausreichende Verifikation. Porterschöpfung muss unter repräsentativer Last und über einen ausreichend langen Zeitraum ausgeschlossen werden.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Datum und Uhrzeit:
<Zeitpunkt mit Zeitzone>

Betroffene Anwendung:
<Anwendung oder Dienst>

Betroffenes System:
<Hostname und IP-Adresse>

Datenfluss:
<Quell-IP:Port -> Ziel-IP:Port/Protokoll>

Adressfamilie:
<IPv4 oder IPv6>

Dynamischer Portbereich:
<Startport bis Endport>

Reservierte Ports:
<Portliste oder keine>

Verbindungen gesamt:
<Anzahl>

ESTABLISHED:
<Anzahl>

TIME_WAIT:
<Anzahl>

CLOSE_WAIT:
<Anzahl>

SYN_SENT:
<Anzahl>

UDP-Sockets:
<Anzahl>

Hauptverursachender Prozess:
<Name und PID>

Häufigstes Ziel:
<IP-Adresse und Port>

Verbindungsrate:
<neue Verbindungen pro Sekunde>

Connection Pool:
<Min, Max, Nutzung und Wiederverwendung>

Retryverhalten:
<Anzahl, Backoff und Jitter>

Dateideskriptoren:
<verwendet und Limit>

Conntrack:
<Count, Max und Fehler>

Firewall-Sitzungen:
<verwendet und Limit>

NAT vor Übersetzung:
<Quell-IP:Port>

NAT nach Übersetzung:
<öffentliche IP und SNAT-Port>

SNAT-Portnutzung:
<Metrik und Auslastung>

Plattformlimit:
<Ressource und dokumentierte Grenze>

Hypothese:
<vermutete Ursache>

Erwarteter Nachweis:
<messbarer Befund>

Gegenbeweis:
<widerlegender Befund>

Nachgewiesene Ursache:
<technischer Nachweis>

Durchgeführte Maßnahme:
<genau eine kontrollierte Änderung>

Risiko:
<mögliche Nebenwirkungen>

Rückweg:
<Rollback>

Verifikation:
<Lasttest, Portnutzung und Anwendungstest>

Prävention:
<Monitoring, Pooling oder Kapazitätsplanung>

Checkliste

Schnellreferenz

Aufgabe Befehl
Windows IPv4-TCP-Portbereich netsh int ipv4 show dynamicport tcp
Windows IPv4-UDP-Portbereich netsh int ipv4 show dynamicport udp
Windows IPv6-TCP-Portbereich netsh int ipv6 show dynamicport tcp
Windows IPv6-UDP-Portbereich netsh int ipv6 show dynamicport udp
Windows TCP-Verbindungen Get-NetTCPConnection
Windows etablierte Verbindungen Get-NetTCPConnection -State Established
Windows TIME_WAIT Get-NetTCPConnection -State TimeWait
Windows CLOSE_WAIT Get-NetTCPConnection -State CloseWait
Windows SYN_SENT Get-NetTCPConnection -State SynSent
Windows Netstat netstat -ano
Windows gebundene Ports netstat -anoq
Windows relevante Ereignisse Get-WinEvent -FilterHashtable @{LogName="System"; Id=4227,4231}
Linux-Portbereich sysctl net.ipv4.ip_local_port_range
Linux-reservierte Ports sysctl net.ipv4.ip_local_reserved_ports
Linux-Socketübersicht ss -s
Linux-TCP-Sockets ss -tan
Linux-TCP mit Prozessen sudo ss -tanp
Linux TIME_WAIT ss -tan state time-wait
Linux CLOSE_WAIT ss -tan state close-wait
Linux SYN_SENT ss -tan state syn-sent
Linux-Listener ss -lntp
Linux-Socketstatistik cat /proc/net/sockstat
Linux-FD-Limit der Shell ulimit -n
Linux-Prozesslimits cat /proc/<PID>/limits
Linux-systemweites FD-Limit sysctl fs.file-max
Linux-Listen-Backlog sysctl net.core.somaxconn
Linux-SYN-Backlog sysctl net.ipv4.tcp_max_syn_backlog
Linux-Conntrack-Anzahl sysctl net.netfilter.nf_conntrack_count
Linux-Conntrack-Maximum sysctl net.netfilter.nf_conntrack_max
macOS-Portparameter sysctl -a | awk '/net\.inet\.ip\.portrange/'
macOS-TCP-Verbindungen netstat -anv -p tcp
macOS-TCP-Prozesse sudo lsof -nP -iTCP
macOS-Netzwerkübersicht nettop -m tcp

Verändernde Befehle und Maßnahmen, die nicht als erste Diagnose verwendet werden dürfen:

netsh int ipv4 set dynamicport ...
netsh int ipv6 set dynamicport ...
sysctl -w net.ipv4.ip_local_port_range=...
sysctl -w net.ipv4.tcp_fin_timeout=...
TcpTimedWaitDelay ungeprüft verändern
MaxUserPort ungeprüft verändern
ulimit pauschal maximal erhöhen
LimitNOFILE ungeprüft erhöhen
fs.file-max ungeprüft erhöhen
net.core.somaxconn ungeprüft erhöhen
net.ipv4.tcp_max_syn_backlog ungeprüft erhöhen
nf_conntrack_max ungeprüft erhöhen
conntrack -F
Firewall-Sitzungen vollständig löschen
NAT-Sitzungen vollständig löschen
Server vorsorglich neu starten
NAT-Gateway vorsorglich neu erstellen
öffentliche IP-Adressen ohne Kapazitätsplanung ergänzen
Connection Pool unbegrenzt vergrößern
Timeouts pauschal verkürzen
Sicherheitsbegrenzungen deaktivieren

Quellen

Standards und Portregistrierung

Microsoft Windows

Linux Kernel und Manpages

Amazon Web Services

Microsoft Azure

Google Cloud

Für diese Seite wurden keine Community-Beiträge oder Hersteller-Social-Media-Aussagen als fachlicher Nachweis verwendet.

9. TCP, UDP, Ports, Firewall, NAT und Proxy

9.8 NAT, Portweiterleitung und Hairpin NAT im Datenpfad

Network Address Translation verändert IP-Adressen und gegebenenfalls Transportports innerhalb eines Datenflusses. Eine Verbindung kann deshalb an verschiedenen Stellen des Netzwerkpfads mit unterschiedlichen Adressen und Ports sichtbar sein.

Beispiel einer eingehenden Portweiterleitung:

Externer Client:
198.51.100.40:53124

Öffentliche Adresse:
203.0.113.10:8443

Interner Server:
192.0.2.25:443

Vor der Zielübersetzung:

198.51.100.40:53124 -> 203.0.113.10:8443/TCP

Nach der Zielübersetzung:

198.51.100.40:53124 -> 192.0.2.25:443/TCP

Eine scheinbar richtige Firewallregel kann wirkungslos bleiben, wenn sie die falsche Adressphase, das falsche Protokoll, die falsche Schnittstelle oder den falschen Übersetzungsport verwendet.

Ziele

Nach der Bearbeitung dieser Seite soll nachvollziehbar geprüft werden können:

Sicherheits- und Änderungsgrundsätze

Eine Portweiterleitung veröffentlicht einen internen Dienst über einen zusätzlichen Netzwerkpfad. Vor der Einrichtung sind mindestens zu prüfen:

Besonders schützenswerte Verwaltungs- und Dateidienste sollten nicht ohne zusätzliche Schutzarchitektur direkt aus dem Internet veröffentlicht werden.

Dazu gehören beispielsweise:

Geeignetere Zugriffsmöglichkeiten können sein:

Nicht als erste Diagnosemaßnahme geeignet sind:

NAT ist keine Firewall

NAT verändert Adressen oder Ports. Eine Firewall entscheidet anhand einer Sicherheitsrichtlinie, ob Datenverkehr erlaubt oder verworfen wird.

Beide Funktionen können sich im selben Gerät befinden, bleiben aber logisch getrennt.

Beispiel:

NAT-Regel:
203.0.113.10:8443 -> 192.0.2.25:443

Firewallregel:
TCP von 198.51.100.0/24 zu 192.0.2.25:443 erlauben

Mögliche Kombinationen:

NAT Firewall Ergebnis
vorhanden erlaubt Verbindung kann weiterverarbeitet werden
vorhanden blockiert Übersetzung kann passen, Verkehr wird trotzdem verworfen
fehlt erlaubt Freigabe besitzt möglicherweise kein erreichbares Ziel
falsch erlaubt Verkehr erreicht falsches System oder falschen Port
vorhanden falsche Richtung Verbindungsaufbau bleibt blockiert
automatisch erstellt unbekannt Sicherheitswirkung muss ausdrücklich geprüft werden

Einige Router erzeugen zusammen mit einer Portweiterleitung automatisch eine Firewallfreigabe. Andere Produkte verlangen eine getrennte Regel. Dieses Verhalten ist hersteller- und versionsabhängig.

NAT-Begriffe

Begriff Bedeutung
NAT Oberbegriff für die Übersetzung von Netzwerkadressen
SNAT Änderung der Quelladresse
DNAT Änderung der Zieladresse
PAT Übersetzung von Transportports, häufig zusammen mit Adressübersetzung
NAPT Übersetzung von Netzwerkadresse und Transportport
Masquerading SNAT auf die aktuelle Adresse einer Ausgangsschnittstelle
statisches NAT fest definierte Zuordnung
dynamisches NAT Zuordnung aus einem Adresspool
Portweiterleitung statische eingehende Zieladress- und/oder Portübersetzung
1:1-NAT feste Zuordnung einer internen zu einer externen Adresse
Twice NAT Quelle und Ziel werden abhängig voneinander in einer Regel verarbeitet
NAT Exemption bestimmter Datenverkehr wird ausdrücklich nicht übersetzt
Hairpin NAT interner Client erreicht internes Ziel über dessen externe NAT-Adresse
NAT Loopback gebräuchliche Bezeichnung für Hairpin NAT
NAT Reflection herstellerabhängige Bezeichnung für Hairpin-Verarbeitung
U-Turn NAT weitere gebräuchliche Bezeichnung für Hairpin NAT
CGNAT NAT im Netz des Internetzugangsanbieters
NAT64 Übersetzung zwischen IPv6 und IPv4
NPTv6 zustandslose Übersetzung von IPv6-Präfixen

Die Begriffe werden von Herstellern nicht immer einheitlich verwendet.

Source NAT

Source NAT verändert die Quelladresse eines ausgehenden Datenflusses.

Vor SNAT:

192.0.2.100:53124 -> 198.51.100.25:443

Nach SNAT:

203.0.113.10:61001 -> 198.51.100.25:443

Das Zielsystem sieht als Quelle:

203.0.113.10:61001

und normalerweise nicht:

192.0.2.100:53124

Typische Anwendungsfälle:

Auswirkungen:

Destination NAT

Destination NAT verändert die Zieladresse eines eingehenden Datenflusses.

Vor DNAT:

198.51.100.40:53124 -> 203.0.113.10:8443

Nach DNAT:

198.51.100.40:53124 -> 192.0.2.25:443

Typische Anwendungsfälle:

Zu prüfen sind:

Port Address Translation

PAT ermöglicht die Unterscheidung vieler Datenflüsse über dieselbe externe IP-Adresse.

Beispiel:

192.0.2.100:53124
    ->
203.0.113.10:61001

192.0.2.101:53124
    ->
203.0.113.10:61002

Beide Clients können dasselbe Ziel verwenden:

198.51.100.25:443

Das NAT-Gerät hält dafür getrennte Zuordnungen:

203.0.113.10:61001 -> 192.0.2.100:53124
203.0.113.10:61002 -> 192.0.2.101:53124

PAT benötigt:

1:1-NAT

Bei 1:1-NAT wird eine interne Adresse fest einer externen Adresse zugeordnet.

Beispiel:

Öffentlich:
203.0.113.25

Intern:
192.0.2.25

Mögliche Übersetzung:

203.0.113.25 <-> 192.0.2.25

1:1-NAT bedeutet nicht automatisch, dass alle Ports erlaubt sind. Die Firewallrichtlinie muss weiterhin festlegen:

Portweiterleitung

Eine Portweiterleitung ordnet eine externe Kombination einer internen Kombination zu.

Beispiel:

Externe Adresse:
203.0.113.10

Externer Port:
8443

Protokoll:
TCP

Internes Ziel:
192.0.2.25

Interner Port:
443

Vereinfachte Regel:

TCP 203.0.113.10:8443
    ->
TCP 192.0.2.25:443

Eine vollständige Portweiterleitung benötigt mindestens:

Externen und internen Port unterscheiden

Die Portnummern müssen nicht identisch sein.

Beispiel:

Extern:
TCP 8443

Intern:
TCP 443

Mögliche Diagnosefehler:

TCP und UDP getrennt weiterleiten

Eine Portnummer bezeichnet ohne Transportprotokoll keinen vollständigen Dienstendpunkt.

Diese beiden Regeln sind verschieden:

TCP 203.0.113.10:8443 -> 192.0.2.25:443

UDP 203.0.113.10:8443 -> 192.0.2.25:443

Zu prüfen sind:

Ein erfolgreicher TCP-Test beweist keine funktionierende UDP-Weiterleitung.

Eingangsschnittstelle und Zieladresse

Eine NAT-Regel kann an eine bestimmte Eingangsschnittstelle oder öffentliche Zieladresse gebunden sein.

Beispiele:

Typischer Fehler:

NAT-Regel:
gilt nur für WAN1

Tatsächlicher Datenverkehr:
trifft über WAN2 ein

Die Regel ist vorhanden, verarbeitet diesen Datenfluss aber nicht.

Vollständiger eingehender Datenpfad

Ein eingehender Zugriff kann folgende Ebenen durchlaufen:

  1. öffentlicher DNS-Eintrag;
  2. Internetzugangsanbieter;
  3. vorgeschaltetes Provider-NAT;
  4. Modem oder Router;
  5. Edge-Firewall;
  6. öffentliche IP-Adresse;
  7. DNAT- oder Portweiterleitungsregel;
  8. Sicherheitsregel;
  9. interne Route;
  10. VLAN- oder Segmentfirewall;
  11. Load Balancer;
  12. Reverse Proxy;
  13. Containerhost;
  14. veröffentlichter Hostport;
  15. Containerport;
  16. lokale Host-Firewall;
  17. Serverprozess;
  18. Anwendung.

Jede Ebene muss mit ihrer vor und nach der Verarbeitung sichtbaren Adresse geprüft werden.

Vollständiger Rückweg

Der Rückverkehr einer eingehenden Verbindung muss die zustandsbehaftete NAT-Komponente wieder erreichen.

Beispiel:

Hinweg:
198.51.100.40
    ->
203.0.113.10
    ->
192.0.2.25

Rückweg:
192.0.2.25
    ->
203.0.113.10
    ->
198.51.100.40

Wenn der Server über ein anderes Gateway antwortet:

192.0.2.25
    ->
anderer Router
    ->
198.51.100.40

fehlt dort möglicherweise die Rückübersetzung.

Mögliche Folgen:

NAT-Reihenfolge ist produktspezifisch

Die Verarbeitung kann unter anderem umfassen:

Die genaue Reihenfolge unterscheidet sich zwischen:

Es darf nicht pauschal angenommen werden, dass eine Firewallregel immer:

verwenden muss.

Maßgeblich ist die Dokumentation des eingesetzten Produkts und der Softwareversion.

NAT-Regelreihenfolge

NAT-Regeln können priorisiert oder der Reihe nach ausgewertet werden.

Mögliche Probleme:

Zu dokumentieren sind:

Statische interne Zieladresse

Das Ziel einer Portweiterleitung muss dauerhaft erreichbar bleiben.

Geeignete Möglichkeiten:

Typischer Fehler:

Portweiterleitung:
192.0.2.25

Aktuelle Serveradresse:
192.0.2.37

Die NAT-Regel ist syntaktisch korrekt, zeigt aber auf ein nicht mehr verwendetes Ziel.

Zu prüfen sind:

Öffentliche Erreichbarkeit prüfen

Eine eingehende Portweiterleitung benötigt eine von außen erreichbare Zieladresse.

Zu prüfen sind:

Eine private Adresse auf der WAN-Schnittstelle ist nicht direkt aus dem öffentlichen Internet erreichbar.

Private IPv4-Bereiche

RFC 1918 definiert:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

Das bedeutet:

10.0.0.0 bis 10.255.255.255
172.16.0.0 bis 172.31.255.255
192.168.0.0 bis 192.168.255.255

Befindet sich die WAN-Adresse des eigenen Routers in einem dieser Bereiche, existiert mindestens ein weiteres vorgeschaltetes Routing- oder NAT-System.

Shared Address Space und CGNAT

RFC 6598 reserviert für Provider-NAT:

100.64.0.0/10

Das umfasst:

100.64.0.0 bis 100.127.255.255

Dieser Bereich ist kein RFC-1918-Privatnetz, wird aber für Shared Address Space und häufig für Carrier-Grade NAT verwendet.

Hinweise auf vorgeschaltetes NAT:

Eine Abweichung der Adressen ist ein Hinweis und muss unter Berücksichtigung von VPN, Proxy, mehreren Leitungen und Providerarchitektur bewertet werden.

Doppeltes NAT

Beispiel:

Internet
    ->
Providerrouter 192.168.0.1
    ->
eigener Router 192.168.0.2
    ->
Server 192.0.2.25

Für eine eingehende Verbindung können zwei Weiterleitungen erforderlich sein:

Providerrouter:
203.0.113.10:8443
    ->
192.168.0.2:8443

Eigener Router:
192.168.0.2:8443
    ->
192.0.2.25:443

Zusätzlich müssen beide Firewalls und beide Rückwege passen.

Besser kann je nach freigegebener Architektur sein:

Ein Exposed Host ist keine geeignete Standardlösung, weil dadurch möglicherweise sehr viele Ports weitergeleitet werden.

Carrier-Grade NAT und Portweiterleitung

Befindet sich die öffentliche IPv4-Adresse auf einem Provider-NAT, kann der eigene Router keine beliebige eingehende Abbildung auf diesem Providergerät erstellen.

Mögliche Lösungen hängen vom Anbieter ab:

Die technische und sicherheitstechnische Eignung muss für den konkreten Dienst bewertet werden.

Hairpin NAT

Hairpin NAT ermöglicht einem internen Client den Zugriff auf einen internen Server über dessen externe NAT-Adresse.

Beispiel:

Interner Client:
192.0.2.100

Öffentliche Dienstadresse:
203.0.113.10:443

Interner Server:
192.0.2.25:443

Der Client verwendet:

192.0.2.100:53124 -> 203.0.113.10:443

Das NAT-Gerät übersetzt das Ziel:

192.0.2.100:53124 -> 192.0.2.25:443

Abhängig von Topologie und Produkt muss zusätzlich die Quelle übersetzt werden, damit der Server über dasselbe NAT-Gerät antwortet.

Hairpin NAT mit Quellübersetzung

Mögliche Verarbeitung:

Ursprünglich:
192.0.2.100:53124 -> 203.0.113.10:443

Nach Hairpin DNAT und SNAT:
192.0.2.1:61001 -> 192.0.2.25:443

Dabei ist:

192.0.2.1

eine Adresse des NAT-Gateways.

Der Server antwortet an das Gateway:

192.0.2.25:443 -> 192.0.2.1:61001

Das Gateway stellt für den Client wieder die erwartete Ansicht her:

203.0.113.10:443 -> 192.0.2.100:53124

Vorteil:

Nachteil:

Direkter Rückweg als Hairpin-Problem

Client und Server befinden sich im selben internen Subnetz:

Client:
192.0.2.100

Server:
192.0.2.25

Wenn nur das Ziel übersetzt wird, kann der Server direkt antworten:

192.0.2.25:443 -> 192.0.2.100:53124

Der Client hat die Verbindung jedoch zu folgender Adresse aufgebaut:

203.0.113.10:443

Eine direkte Antwort von:

192.0.2.25:443

passt nicht zur erwarteten Gegenstelle.

Mögliche Symptome:

Hairpin NAT ist nicht überall verfügbar

Mögliche Produktbezeichnungen:

Zu prüfen sind:

Das Verhalten darf nicht von einem anderen Routermodell oder Hersteller übertragen werden.

Split DNS als Alternative

Statt Hairpin NAT kann internes DNS den Dienstnamen direkt auf die interne Adresse auflösen.

Extern:

app.example.test
    ->
203.0.113.10

Intern:

app.example.test
    ->
192.0.2.25

Vorteile:

Zu prüfen sind:

Split DNS ist nicht automatisch besser, wenn intern derselbe Reverse Proxy, dieselbe Web Application Firewall oder dieselben Sicherheitsprüfungen benötigt werden.

Internen und externen Test unterscheiden

Mindestens drei Tests sind getrennt zu dokumentieren:

Test A:
interner Client -> interne Serveradresse

Test B:
interner Client -> öffentliche Dienstadresse

Test C:
externer Client -> öffentliche Dienstadresse

Einordnung:

Test A Test B Test C Mögliche Einordnung
erfolgreich erfolgreich erfolgreich grundlegender Pfad funktioniert
erfolgreich fehlerhaft erfolgreich Hairpin NAT oder internes DNS
erfolgreich erfolgreich fehlerhaft externe Weiterleitung, Provider, WAN oder Firewall
fehlerhaft fehlerhaft fehlerhaft Serverdienst, Host-Firewall oder interne Route
fehlerhaft erfolgreich erfolgreich unterschiedliche interne Adresse oder Sicherheitsregel
erfolgreich fehlerhaft fehlerhaft DNAT-Regel oder öffentliche Adresszuordnung
fehlerhaft fehlerhaft erfolgreich externer Proxy oder anderer Backendpfad

Test C muss tatsächlich aus einem externen Netz erfolgen. Ein Mobilgerät im WLAN ist kein externer Test. Auch ein VPN kann den Datenpfad zurück ins interne Netz führen.

DNS und NAT gemeinsam prüfen

Ein FQDN kann liefern:

Windows:

Resolve-DnsName `
  -Name "app.example.test" `
  -Type A

Resolve-DnsName `
  -Name "app.example.test" `
  -Type AAAA

Linux und macOS:

dig app.example.test A

dig app.example.test AAAA

Zu prüfen sind:

Eine korrekte IPv4-Portweiterleitung hilft nicht, wenn der Client aufgrund eines AAAA-Eintrags direkt IPv6 verwendet.

IPv6 und NAT

IPv6 benötigt für normale öffentliche Erreichbarkeit nicht dieselbe Form von IPv4-Portübersetzung. Ein global adressierter IPv6-Server ist trotzdem nicht automatisch erreichbar.

Zu prüfen sind:

NAT darf nicht als Ersatz für eine IPv6-Firewall betrachtet werden.

NPTv6 übersetzt IPv6-Präfixe zustandslos und besitzt ein anderes Verhalten als klassische IPv4-Portübersetzung.

Automatische Portabbildungen

Anwendungen können je nach Umgebung automatische Portabbildungen anfordern, beispielsweise über:

Zu prüfen sind:

Automatische Portabbildungen können die vorgesehene Sicherheitskontrolle umgehen. Sie dürfen nicht nur zur schnellen Fehlerbehebung aktiviert werden.

Application Level Gateways

Ein NAT-Gerät kann Protokollinhalte analysieren und Adressen oder Ports innerhalb der Nutzdaten verändern.

Mögliche Protokolle:

Zu prüfen sind:

Ein ALG kann helfen, aber auch Verbindungen beschädigen. Es darf nur nach nachgewiesenem Zusammenhang verändert werden.

NAT und TLS

NAT verändert normalerweise nicht den TLS-Hostnamen oder das Zertifikat.

Beispiel:

FQDN:
app.example.test

Öffentliche Adresse:
203.0.113.10

Interner Server:
192.0.2.25

Das Zertifikat muss zum verwendeten Namen passen:

app.example.test

und nicht zwangsläufig zur öffentlichen oder privaten IP-Adresse.

NAT kann jedoch indirekt TLS-Probleme verursachen, wenn:

Reverse Proxy und Portweiterleitung

Häufig zeigt eine Portweiterleitung nicht direkt auf den Anwendungsserver, sondern auf einen Reverse Proxy.

Beispiel:

Internet:
203.0.113.10:443

DNAT:
192.0.2.20:443

Reverse Proxy:
app.example.test -> 192.0.2.25:8080

Zu prüfen sind zwei getrennte Verbindungen:

Client -> Reverse Proxy
Reverse Proxy -> Backend

Mögliche Fehlerstellen:

Ein erfolgreicher externer TCP-Handshake bis zum Reverse Proxy beweist nicht, dass das Backend erreichbar ist.

Docker-Portveröffentlichung

Ein Docker-Container in einem Bridge-Netz ist normalerweise nicht allein durch EXPOSE von außen erreichbar. Der Port muss veröffentlicht oder über einen anderen Proxy bereitgestellt werden.

Beispiel:

docker run \
  -p 8080:80 \
  nginx

Bedeutung:

Hostport 8080
    ->
Containerport 80

Ohne ausdrücklich angegebene Hostadresse kann ein veröffentlichter Port auf allen geeigneten Hostadressen gebunden werden.

Sicherer auf den lokalen Host begrenzt:

docker run \
  -p 127.0.0.1:8080:80 \
  nginx

Damit ist der Port für einen lokalen Reverse Proxy erreichbar, aber nicht automatisch über jede externe Hostschnittstelle.

Docker-Portzuordnung prüfen

Laufende Container und veröffentlichte Ports:

docker ps \
  --format 'table {{.Names}}\t{{.Ports}}'

Portzuordnung eines Containers:

docker port <Containername>

Vollständige Netzwerkinformation:

docker inspect <Containername>

Hostlistener:

ss -lntp

Containerlistener:

docker exec <Containername> \
  ss -lntp

Falls ss im Container nicht installiert ist, sind Anwendungsprotokolle, Health Checks oder die im Image verfügbaren Diagnosewerkzeuge zu verwenden.

Zu unterscheiden sind:

Routerport
Hostport
Containerport
Anwendungsport

Beispiel:

203.0.113.10:8443
    ->
192.0.2.20:6875
    ->
Container:80

Docker-Netzwerkmodus berücksichtigen

Netzwerkmodus NAT- oder Portverhalten
Bridge Portveröffentlichung und NAT üblich
Host Container verwendet den Netzwerkstack des Hosts; -p wird nicht angewendet
Macvlan Container kann eigene Adresse im Netz besitzen
Ipvlan direkte adressbasierte Anbindung je nach Betriebsart
Overlay zusätzlicher Overlay- und Orchestrierungspfad
None keine normale externe Netzwerkanbindung

Bei host-Netzwerkmodus besitzt der Container keinen getrennten Host-zu-Container-Portpfad. Eine konfigurierte -p-Option wird nicht als normale Portweiterleitung verwendet.

Docker und Firewallregeln

Docker kann für Bridge-Netze eigene Firewall- und NAT-Regeln erzeugen.

Zu prüfen sind:

Eigene Regeln dürfen nicht ungeprüft vor, nach oder innerhalb von Docker-verwalteten Regelketten eingefügt werden.

Kubernetes-Datenpfad

Mögliche Ebenen:

öffentliche Adresse
    ->
Cloud Load Balancer
    ->
Ingress Controller
    ->
Kubernetes Service
    ->
Pod

Oder:

Node-IP:NodePort
    ->
Service
    ->
Pod

Lesende Prüfungen:

kubectl get services \
  --all-namespaces \
  -o wide

kubectl get ingress \
  --all-namespaces

kubectl get endpointslices \
  --all-namespaces

kubectl describe service \
  <Servicename> \
  --namespace <Namespace>

Zu prüfen sind:

Windows WinNAT lesend prüfen

NAT-Objekte:

Get-NetNat

Statische Abbildungen:

Get-NetNatStaticMapping

Aktive NAT-Sitzungen:

Get-NetNatSession

Netzwerkschnittstellen:

Get-NetIPConfiguration

Routing:

Get-NetRoute

Listener:

Get-NetTCPConnection `
  -State Listen

WinNAT wird unter anderem für Hyper-V- und Windows-Container-Netze verwendet. Die Cmdlets zeigen keine NAT-Konfiguration eines getrennten physischen Routers.

Linux nftables lesend prüfen

Vollständiges Regelwerk:

sudo nft list ruleset

Tabellen:

sudo nft list tables

Eine bekannte NAT-Tabelle anzeigen:

sudo nft list table ip nat

Die Tabelle muss nicht ip nat heißen. Maßgeblich ist die Ausgabe von:

sudo nft list tables

Regelwerk mit Handles:

sudo nft -a list ruleset

Zu suchen sind unter anderem:

dnat
snat
masquerade
redirect
prerouting
postrouting
output
input

Bei nftables sind:

Die tatsächliche Chain, Priorität und Familie sind zu prüfen.

Vereinfachtes nftables-DNAT-Beispiel

table ip nat {
    chain prerouting {
        type nat hook prerouting priority dstnat;

        iifname "wan0" \
        ip daddr 203.0.113.10 \
        tcp dport 8443 \
        dnat to 192.0.2.25:443
    }
}

Dieses Beispiel enthält nur die Zielübersetzung. Zusätzlich erforderlich sein können:

Es darf nicht ungeprüft in ein produktives Regelwerk übernommen werden.

Vereinfachtes nftables-Hairpin-Prinzip

table ip nat {
    chain prerouting {
        type nat hook prerouting priority dstnat;

        ip saddr 192.0.2.0/24 \
        ip daddr 203.0.113.10 \
        tcp dport 443 \
        dnat to 192.0.2.25:443
    }

    chain postrouting {
        type nat hook postrouting priority srcnat;

        ip saddr 192.0.2.0/24 \
        ip daddr 192.0.2.25 \
        tcp dport 443 \
        masquerade
    }
}

Dieses vereinfachte Prinzip erzwingt, dass der Rückverkehr wieder über das NAT-Gateway läuft. Adressen, Schnittstellen, Sicherheitsregeln und Regelprioritäten müssen an die tatsächliche Umgebung angepasst und freigegeben werden.

Linux iptables lesend prüfen

NAT-Regeln:

sudo iptables \
  -t nat \
  -L \
  -n \
  -v \
  --line-numbers

Regeln in speicherbarer Syntax:

sudo iptables \
  -t nat \
  -S

IPv6-Regeln, sofern verwendet:

sudo ip6tables \
  -t nat \
  -S

Filter- und Forwardingregeln:

sudo iptables \
  -L FORWARD \
  -n \
  -v \
  --line-numbers

Aktive Weiterleitung:

sysctl net.ipv4.ip_forward

IPv6-Weiterleitung:

sysctl net.ipv6.conf.all.forwarding

Linux Connection Tracking

Aktive NAT- und Verbindungseinträge:

sudo conntrack -L

TCP-Einträge zu einem internen Server:

sudo conntrack -L \
  -p tcp \
  -d 192.0.2.25 \
  --dport 443

Ereignisse während eines kontrollierten Tests:

sudo conntrack -E

Zu prüfen sind:

Das vollständige Leeren der Conntrack-Tabelle ist keine erste Diagnosemaßnahme.

Cisco Secure Firewall ASA prüfen

NAT-Regeln:

show nat

Details und Treffer:

show nat detail

Übersetzungen:

show xlate

Verbindungen:

show conn

Nach Adresse filtern:

show conn address 192.0.2.25

Routing:

show route

Simulation:

packet-tracer input outside tcp 198.51.100.40 53124 203.0.113.10 8443 detailed

Zu prüfen sind:

Bei aktuellen Cisco-ASA-Regelwerken werden Zugriffsregeln im NAT-Kontext anhand realer Adressen ausgewertet. Dieses Verhalten darf nicht auf andere Produkte übertragen werden.

Cloud-NAT und eingehende Verbindungen

Ein Cloud-NAT-Gateway dient häufig ausschließlich der ausgehenden Kommunikation privater Ressourcen.

Wichtig:

Outbound NAT
ist nicht automatisch
Inbound Port Forwarding

Für eingehende Veröffentlichung können stattdessen erforderlich sein:

AWS NAT Gateway

AWS NAT Gateway erlaubt privaten Ressourcen ausgehende Verbindungen. Es nimmt keine unaufgeforderten eingehenden Internetverbindungen für diese Ressourcen an.

Zu prüfen sind:

Eine Portweiterleitung auf ein AWS NAT Gateway ist nicht der vorgesehene Weg zur Veröffentlichung eines privaten Servers.

Mögliche Alternativen:

Azure NAT Gateway

Azure NAT Gateway stellt ausgehende Internetkonnektivität für ein Subnetz bereit. Unaufgeforderte eingehende Internetverbindungen werden nicht bereitgestellt. DNAT wird nur für Antwortpakete einer zuvor ausgehend aufgebauten Kommunikation angewendet.

Für eingehende Veröffentlichung können je nach Anforderung verwendet werden:

Zu prüfen sind:

Paketaufzeichnung entlang des NAT-Pfads

Für einen NAT-Nachweis sind mehrere Beobachtungspunkte erforderlich.

Beispiel:

Beobachtungspunkt Erwarteter Datenfluss
vor Edge-Firewall 198.51.100.40:53124 -> 203.0.113.10:8443
nach DNAT 198.51.100.40:53124 -> 192.0.2.25:443
am Server 198.51.100.40:53124 -> 192.0.2.25:443
Serverantwort 192.0.2.25:443 -> 198.51.100.40:53124
nach Rückübersetzung 203.0.113.10:8443 -> 198.51.100.40:53124

Mit tcpdump auf dem externen Abschnitt:

sudo tcpdump \
  -ni <WAN-Schnittstelle> \
  'host 198.51.100.40 and host 203.0.113.10 and tcp port 8443'

Auf dem internen Abschnitt:

sudo tcpdump \
  -ni <LAN-Schnittstelle> \
  'host 198.51.100.40 and host 192.0.2.25 and tcp port 443'

Am Server:

sudo tcpdump \
  -ni any \
  'host 198.51.100.40 and tcp port 443'

Die Platzhalter müssen durch autorisierte reale Werte ersetzt werden.

Befund aus Paketaufzeichnungen

WAN-Eingang LAN-Ausgang Serverantwort Einordnung
nein nein nein Problem vor dem NAT-Gerät
ja nein nein NAT-, Firewall- oder Routingproblem
ja ja nein Server, Host-Firewall oder Dienst prüfen
ja ja ja, aber nicht am NAT falscher Rückweg
ja ja ja und Rückübersetzung Clientpfad oder Anwendung prüfen
Hairpin am LAN sichtbar kein Hairpin-Ausgang Hairpin NAT fehlt oder passt nicht
DNAT korrekt falscher interner Port NAT-Regel korrigieren
Paket erreicht falschen Server falsches Zielobjekt oder alte Regel Regel und Objekt prüfen

Hardware-Offloading kann verhindern, dass eine allgemeine Softwareaufzeichnung alle Pakete zeigt. Dann sind herstellerspezifische Captures, SPAN oder TAP erforderlich.

Porttest richtig ausführen

Windows:

Test-NetConnection `
  -ComputerName "203.0.113.10" `
  -Port 8443 `
  -InformationLevel Detailed

Linux und macOS:

nc -vz 203.0.113.10 8443

HTTPS mit FQDN:

curl \
  -v \
  https://app.example.test:8443/

Ein TCP-Porttest beweist nur den TCP-Aufbau bis zu der Komponente, die antwortet. Er beweist nicht:

Ein UDP-Test benötigt eine anwendungsspezifische Antwort, Protokollauswertung oder Paketaufzeichnung.

Externer Test

Ein externer Test muss aus einem tatsächlich unabhängigen Netz erfolgen.

Mögliche Testsysteme:

Zu dokumentieren sind:

Öffentliche Portscan-Webseiten sollten nicht unkontrolliert für interne oder sensible Dienste verwendet werden.

NAT-Protokollierung

Ein geeigneter NAT- oder Firewalllogeintrag enthält möglichst:

Ein fehlender NAT-Logeintrag kann bedeuten:

Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Die Portweiterleitung 203.0.113.10:8443 zeigt korrekt auf
192.0.2.25:443. Interne Clients können die öffentliche Adresse
jedoch nicht verwenden, weil die Firewall kein Hairpin NAT für
dieselbe interne Zone ausführt.

Erwarteter Befund:
Der interne Direktzugriff auf 192.0.2.25:443 funktioniert.
Ein externer Zugriff auf 203.0.113.10:8443 funktioniert.
Beim internen Zugriff auf 203.0.113.10:8443 steigt der Trefferzähler
der normalen WAN-DNAT-Regel nicht oder der Rückverkehr umgeht die
NAT-Sitzung.

Gegenbeweis:
Der Hairpin-Datenfluss wird nachweislich übersetzt, Hin- und
Rückverkehr durchlaufen dieselbe NAT-Sitzung und die Antwort erreicht
den Client mit der erwarteten öffentlichen Quelladresse.

Testmethode:
Drei getrennte Zugriffe über interne Adresse, öffentliche Adresse
von intern und öffentliche Adresse von extern durchführen.
NAT-Zähler, Sitzungstabelle und Paketaufzeichnung korrelieren.

Risiko:
Nur lesende Diagnose und kontrollierte Verbindungstests.

Erfolgskriterium:
Fehler ist eindeutig auf Hairpin-Verarbeitung, Rückweg oder eine
nachgelagerte Anwendungsebene begrenzt.

Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko Rückweg
DNAT-Ziel korrigieren falsche interne Adresse nachgewiesen anderes System wird veröffentlicht alte Zieladresse wiederherstellen
externen Port korrigieren falscher Port bestätigt Clients müssen neuen Port verwenden alten Port wiederherstellen
internen Port korrigieren tatsächlicher Listener nachgewiesen falscher Dienst kann erreicht werden alten Zielport wiederherstellen
Protokoll korrigieren TCP-/UDP-Abweichung bestätigt zusätzliche Erreichbarkeit alte Protokollregel
Quellbereich einschränken zulässige Quellen bekannt legitime Quellen können fehlen vorherigen Bereich wiederherstellen
Rückroute korrigieren asymmetrischer Rückweg bestätigt weitere Ziele betroffen alte Route wiederherstellen
Hairpin DNAT ergänzen interner öffentlicher Zugriff erforderlich zusätzlicher interner Pfad Regel entfernen
Hairpin SNAT ergänzen direkter Rückweg verhindert Sitzung ursprüngliche Client-IP geht verloren SNAT-Regel entfernen
Split DNS einrichten interner Direktpfad freigegeben interner Pfad unterscheidet sich extern vorherige DNS-Antwort
Host-Firewall korrigieren Serverdrop bestätigt zusätzliche Angriffsfläche alte Regel
Containerport korrigieren Host-/Containerabweichung bestätigt Dienst wird anders veröffentlicht alte Portzuordnung
Reverse-Proxy-Ziel korrigieren falsches Backend bestätigt Anwendungspfad verändert sich alte Proxykonfiguration
öffentliche IPv4 bereitstellen CGNAT bestätigt und fachlich erforderlich Kosten und größere Angriffsfläche Vertrag oder Zuweisung zurücknehmen
NAT-Regelreihenfolge korrigieren Überschattung nachgewiesen andere Datenflüsse betroffen alte Reihenfolge

Vollständiger Diagnoseablauf

  1. Exakte Fehlermeldung erfassen.
  2. Datum, Uhrzeit und Zeitzone dokumentieren.
  3. Betroffene Anwendung bestimmen.
  4. FQDN dokumentieren.
  5. DNS-A- und AAAA-Antworten prüfen.
  6. tatsächlich verwendete Zieladresse bestimmen.
  7. TCP, UDP oder anderes Protokoll bestimmen.
  8. externen Zielport bestimmen.
  9. internen Zielport bestimmen.
  10. externe Quelladresse dokumentieren.
  11. öffentliche Zieladresse dokumentieren.
  12. internes Ziel dokumentieren.
  13. Vor-NAT-Tupel dokumentieren.
  14. Nach-NAT-Tupel dokumentieren.
  15. Umfang der Störung bestimmen.
  16. interne Direktverbindung testen.
  17. internen Zugriff über öffentliche Adresse testen.
  18. tatsächlich externen Zugriff testen.
  19. WAN-Adresse des Edge-Geräts prüfen.
  20. vorgeschaltetes NAT oder CGNAT prüfen.
  21. doppeltes NAT berücksichtigen.
  22. richtige Eingangsschnittstelle bestimmen.
  23. richtige öffentliche Zieladresse bestimmen.
  24. aktive NAT-Konfiguration prüfen.
  25. NAT-Regelreihenfolge prüfen.
  26. NAT-Regeltreffer dokumentieren.
  27. Firewallregel getrennt prüfen.
  28. Routing zum internen Ziel prüfen.
  29. Host-Firewall prüfen.
  30. Listener des Serverdienstes prüfen.
  31. Serverantwort und Rückroute prüfen.
  32. NAT-Sitzung oder Translation Table prüfen.
  33. Hin- und Rückverkehr vergleichen.
  34. Hairpin-Unterstützung prüfen.
  35. Hairpin-DNAT und gegebenenfalls SNAT prüfen.
  36. Split-DNS-Verhalten berücksichtigen.
  37. Reverse Proxy oder Load Balancer prüfen.
  38. Container-Hostport und Containerport prüfen.
  39. Kubernetes-Servicepfad berücksichtigen.
  40. automatische Portabbildungen prüfen.
  41. ALG oder NAT-Helper berücksichtigen.
  42. IPv4 und IPv6 getrennt prüfen.
  43. Cloud-NAT und Inbound-Komponente unterscheiden.
  44. bei Bedarf Paketaufzeichnung vor und nach NAT durchführen.
  45. Hypothese und Gegenbeweis formulieren.
  46. genau eine kontrollierte Maßnahme vorbereiten.
  47. Risiko, Rückweg und Erfolgskriterium dokumentieren.
  48. Maßnahme freigeben und umsetzen.
  49. neue Sitzung aufbauen.
  50. internen, Hairpin- und externen Test wiederholen.
  51. NAT-, Firewall- und Anwendungslogs verifizieren.
  52. weitere repräsentative Quellen testen.
  53. temporäre Regeln und Captures zurücknehmen.
  54. Ursache, Maßnahme und Prävention dokumentieren.

Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
interne Adresse funktioniert, öffentliche intern nicht Hairpin NAT oder Split DNS Hairpin-Sitzung und Rückweg prüfen
öffentliche Adresse extern funktioniert DNAT und externer Pfad grundsätzlich aktiv internen Hairpin-Pfad getrennt prüfen
öffentliche Adresse extern nicht erreichbar Provider, CGNAT, WAN, DNAT oder Firewall WAN-IP und NAT-Regeltreffer
NAT-Regelzähler bleibt null falsche IP, Schnittstelle, Port oder Pfad Capture vor dem NAT-Gerät
NAT-Regel trifft, Firewall blockiert getrennte Sicherheitsrichtlinie Firewalllog und Adressphase
NAT und Firewall erlauben, Server antwortet nicht Host-Firewall, Listener oder Dienst serverseitiges Capture
Server antwortet, NAT sieht Antwort nicht falsche Rückroute Serverroute und Gateway
Rückantwort besitzt private Quelladresse fehlende Rückübersetzung oder Hairpin-Asymmetrie NAT-Sitzung und Pfad
WAN-Adresse ist privat vorgeschaltetes NAT Upstreamgerät prüfen
WAN-Adresse liegt in 100.64.0.0/10 CGNAT wahrscheinlich Provider und externe Adresse
Router-WAN-IP weicht von externer IP ab vorgeschaltetes NAT, VPN oder Proxy vollständigen Ausgangspfad prüfen
TCP funktioniert, UDP nicht Protokollregel oder UDP-State UDP-Capture und NAT-Timeout
IPv4 funktioniert, FQDN nicht AAAA-Pfad oder DNS A-/AAAA-Antwort vergleichen
externer Port offen, falsche Anwendung falsches DNAT-Ziel oder Reverse Proxy Backend und Hostheader prüfen
Docker-Hostport lauscht nicht Port nicht veröffentlicht oder Container gestoppt docker ps und docker port
Hostport lauscht, Container antwortet nicht Containerdienst oder Zielport Containerlistener und Logs
Container direkt erreichbar, öffentlich nicht Router-, Host- oder DNAT-Pfad schrittweise Porttests
Zugriff nach Routerneustart kurz möglich Zustand, dynamische Adresse oder Konflikt Translation Table und WAN-IP
nur manche Quellen funktionieren Quellfilter oder NAT-Filterverhalten Regeln und Quelladressen vergleichen
Zugriff über IP, nicht über Namen DNS, SNI oder Zertifikat FQDN und TLS-Prüfung
intern anderer Server als extern Split DNS oder Proxyunterschied DNS-Antworten und Backend
AWS NAT Gateway sendet ausgehend, kein Inbound erwartetes Produktverhalten Load Balancer oder andere Inbound-Komponente
Azure NAT Gateway sendet ausgehend, kein Inbound erwartetes Produktverhalten Azure Firewall DNAT oder Load Balancer
nach Regeländerung alte Sitzung bleibt bestehender Translation State vollständig neue Sitzung testen
extern klappt nur über einen WAN-Anschluss NAT-Regel nur an einer Schnittstelle WAN-Bindung und Routing

Typische Diagnosefehler

Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Eine erfolgreiche Verbindung aus dem internen Netz reicht nicht als Verifikation einer Internet-Portweiterleitung.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Datum und Uhrzeit:
<Zeitpunkt mit Zeitzone>

Betroffene Anwendung:
<Anwendung oder Dienst>

FQDN:
<Name>

DNS-Antworten:
<A- und AAAA-Einträge>

Externe Quelle:
<IP-Adresse und Quellport>

Öffentliches Ziel:
<IP-Adresse und Zielport>

Protokoll:
<TCP, UDP oder anderes Protokoll>

Internes Ziel:
<IP-Adresse und Zielport>

Vor-NAT-Tupel:
<Quelle:Port -> Ziel:Port>

Nach-NAT-Tupel:
<Quelle:Port -> Ziel:Port>

NAT-Gerät:
<Name, Clusterknoten und Kontext>

Eingangsschnittstelle:
<Name>

Ausgangsschnittstelle:
<Name>

NAT-Regel:
<Name, ID und Position>

Firewallregel:
<Name und ID>

NAT-Sitzung:
<Original- und Antwortdaten>

WAN-Adresse:
<Adresse>

Extern beobachtete Adresse:
<Adresse>

Vorgeschaltetes NAT:
<ja, nein oder ungeklärt>

CGNAT:
<ja, nein oder ungeklärt>

Rückroute:
<Gateway und Pfad>

Serverlistener:
<Adresse und Port>

Host-Firewall:
<Befund>

Containerzuordnung:
<Routerport -> Hostport -> Containerport>

Reverse Proxy:
<Frontend und Backend>

Interner Direktzugriff:
<Ergebnis>

Interner Zugriff über öffentliche Adresse:
<Ergebnis>

Externer Zugriff:
<Ergebnis>

Paketaufzeichnung:
<Befund vor und nach NAT>

Hypothese:
<vermutete Ursache>

Erwarteter Nachweis:
<messbarer Befund>

Gegenbeweis:
<widerlegender Befund>

Nachgewiesene Ursache:
<technischer Nachweis>

Durchgeführte Maßnahme:
<genau eine kontrollierte Änderung>

Risiko:
<mögliche Nebenwirkungen>

Rückweg:
<Rollback>

Verifikation:
<interner, Hairpin- und externer Test>

Prävention:
<Monitoring, Dokumentation oder Architekturverbesserung>

Checkliste

Schnellreferenz

Aufgabe Befehl
Windows-NAT-Objekte Get-NetNat
Windows-statische NAT-Abbildungen Get-NetNatStaticMapping
Windows-NAT-Sitzungen Get-NetNatSession
Windows-Routing Get-NetRoute
Windows-Listener Get-NetTCPConnection -State Listen
Windows-DNS A Resolve-DnsName -Name "app.example.test" -Type A
Windows-DNS AAAA Resolve-DnsName -Name "app.example.test" -Type AAAA
Windows-TCP-Porttest Test-NetConnection -ComputerName "203.0.113.10" -Port 8443
Linux-nftables-Regelwerk sudo nft list ruleset
Linux-nftables-Tabellen sudo nft list tables
Linux-nftables mit Handles sudo nft -a list ruleset
Linux-iptables-NAT sudo iptables -t nat -L -n -v --line-numbers
Linux-iptables-NAT-Regeln sudo iptables -t nat -S
Linux-Forwardingregeln sudo iptables -L FORWARD -n -v --line-numbers
Linux-IPv4-Forwarding sysctl net.ipv4.ip_forward
Linux-Conntrack sudo conntrack -L
Linux-Conntrack-Ereignisse sudo conntrack -E
Linux-Listener ss -lntp
Linux/macOS-DNS A dig app.example.test A
Linux/macOS-DNS AAAA dig app.example.test AAAA
Linux/macOS-TCP-Porttest nc -vz 203.0.113.10 8443
HTTPS-Test curl -v https://app.example.test:8443/
Docker-Ports docker ps --format 'table {{.Names}}\t{{.Ports}}'
Docker-Portzuordnung docker port <Containername>
Docker-Details docker inspect <Containername>
Kubernetes-Services kubectl get services --all-namespaces -o wide
Kubernetes-Ingress kubectl get ingress --all-namespaces
Kubernetes-Endpunkte kubectl get endpointslices --all-namespaces
Cisco-ASA-NAT show nat
Cisco-ASA-NAT-Details show nat detail
Cisco-ASA-Übersetzungen show xlate
Cisco-ASA-Verbindungen show conn
Cisco-ASA-Routing show route

Verändernde Befehle und Maßnahmen, die nicht als erste Diagnose verwendet werden dürfen:

New-NetNat
Add-NetNatStaticMapping
Remove-NetNat
Remove-NetNatStaticMapping
nft add rule ... dnat ...
nft add rule ... snat ...
nft flush ruleset
iptables -t nat -F
conntrack -F
clear xlate
clear conn
Firewall deaktivieren
Exposed Host aktivieren
DMZ Host aktivieren
alle Ports weiterleiten
UPnP pauschal aktivieren
NAT-PMP pauschal aktivieren
PCP pauschal aktivieren
ALG ungeprüft deaktivieren
ALG ungeprüft aktivieren
Router vorsorglich neu starten
Firewall vorsorglich neu starten
öffentliche Verwaltungsports testweise freigeben
allgemeine any-any-Regel erstellen

Quellen

Standards

Microsoft Windows

Linux Netfilter

Docker und Kubernetes

Cisco

Amazon Web Services

Microsoft Azure

Für diese Seite wurden keine Community-Beiträge oder Hersteller-Social-Media-Aussagen als fachlicher Nachweis verwendet.