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:

gesicherte Fakten von Vermutungen getrennt sein,

mehrere technisch plausible Ursachen vorliegen,

widersprechende Beobachtungen berücksichtigt sein,

für jede wichtige Hypothese ein geeigneter Test definiert sein,

erwartete Testergebnisse vorher festgelegt sein,

ungefährliche und aussagekräftige Tests priorisiert sein,

Testergebnisse nachvollziehbar dokumentiert werden.

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:

blockierter Prozess wurde beendet,

Speicherleck wurde vorübergehend beseitigt,

Netzwerkverbindung wurde neu aufgebaut,

temporärer Cache wurde geleert,

Konfiguration wurde beim Start neu geladen,

abhängiger Dienst wurde in anderer Reihenfolge gestartet.

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:

betroffene Funktion,

betroffene Benutzer oder Geräte,

nicht betroffene Benutzer oder Geräte,

Quellnetz oder Standort,

Zielsystem,

Protokoll und Port,

Beginn der Störung,

letzte bekannte Funktion,

Fehlermeldung,

bereits bestätigte Fakten,

letzte relevante Änderungen.

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

passive Zustandsabfrage,

Vergleich mit funktionierendem System,

gezielte Netzwerk- oder Anwendungstests,

Test in isolierter Umgebung,

reversible Änderung,

Dienstneustart oder Failover,

Konfigurationsrollback,

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:

welche Hypothese geprüft wird,

welcher Befehl oder Ablauf verwendet wird,

welches Ergebnis die Hypothese unterstützt,

welches Ergebnis sie widerlegt,

welche Ergebnisse uneindeutig wären,

ob der Test Veränderungen oder Risiken verursacht,

wie der Ausgangszustand wiederhergestellt wird.

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:

Hostname: server.example

Port: 443

Protokoll: HTTPS

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:

RemoteAddress

RemotePort

InterfaceAlias

SourceAddress

TcpTestSucceeded

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:

aufgelöste IP-Adresse,

TCP-Verbindungsaufbau,

TLS-Aushandlung,

Zertifikatsprüfung,

gesendete HTTP-Anfrage,

empfangenen HTTP-Status.

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:

Zertifikatsinhaber,

Subject Alternative Names,

Aussteller,

Gültigkeitszeitraum,

Zertifikatskette,

verwendete TLS-Version,

verwendete Cipher Suite,

abschließendes Verifikationsergebnis.

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

Nicht jeder Router beantwortet Traceroute-Anfragen.

Sternchen bedeuten nicht automatisch einen Fehler an diesem Gerät.

Der Hin- und Rückweg kann unterschiedlich sein.

Firewalls können Traceroute blockieren.

Der letzte erreichbare Hop ist nicht automatisch die Fehlerursache.

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

Dienst läuft nicht,

Dienst startet wiederholt neu,

Abhängigkeit ist ausgefallen,

Port kann nicht gebunden werden,

Konfigurationsdatei enthält Fehler,

Dienstkonto kann sich nicht anmelden,

Zertifikat kann nicht geladen werden,

Datenträger ist voll,

Datei oder Datenbank ist gesperrt,

Arbeitsspeicher reicht nicht aus.

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

Softwareversion,

Konfigurationsdatei,

DNS-Server,

Proxy,

Standardgateway,

Zertifikat,

Gruppenmitgliedschaft,

Dateiberechtigung,

Dienstkonto,

Firewallprofil,

Umgebungsvariablen,

installierte Updates,

Richtlinien,

Feature Flags.

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:

lokale Firewall,

zentrale Firewall,

fehlende Route,

falsches Gateway,

Zielsystem ausgeschaltet,

Dienst überlastet,

asymmetrisches Routing,

falsche IP-Adresse,

Sicherheitsfilter verwirft Pakete,

Providerproblem.

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

Geeignete Folgeprüfungen

Test von anderem Client,

Test aus anderem VLAN,

Test direkt auf dem Server,

Listener auf dem Server prüfen,

Firewall-Logging prüfen,

Paketaufzeichnung auf Client oder Server,

Routingtabellen vergleichen,

Monitoring und zentrale Protokolle prüfen.

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:

VLAN 30: TcpTestSucceeded: False

VLAN 40: TcpTestSucceeded: True

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

Zweite Prüfung

Standardgateway in VLAN 30 ist korrekt.

Andere Ziele über dasselbe Gateway funktionieren.

Firewall protokolliert einen verworfenen Verbindungsversuch von VLAN 30 zu TCP 443.

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:

sie erklärt das gesamte Fehlerbild,

sie erklärt den betroffenen Umfang,

sie passt zum zeitlichen Verlauf,

passende technische Belege sind vorhanden,

alternative Hypothesen wurden widerlegt,

der Fehler kann reproduziert werden,

eine Gegenprobe verändert das Ergebnis wie erwartet,

die Korrektur beseitigt den ursprünglichen Fehler,

die Korrektur verursacht keine neuen Störungen.

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

Möglichst nur eine Variable verändern.

Vorher und nachher denselben Test verwenden.

Erwartetes Ergebnis vorher festlegen.

Funktionierendes Vergleichssystem verwenden.

Quell- und Zielsystem dokumentieren.

Uhrzeit und Zeitzone dokumentieren.

Exakten Befehl dokumentieren.

Vollständige Ausgabe sichern.

Fehlercode nicht nur sinngemäß wiedergeben.

Test möglichst mehrfach reproduzieren.

Belastung und Nebenwirkungen berücksichtigen.

Nach negativer Prüfung Hypothese herabstufen.

Bei unklarem Ergebnis einen trennschärferen Test wählen.

Keine produktionsweite Änderung als ersten Test verwenden.

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