Aufgaben Troubleshooting

IHK-Aufgaben Troubleshooting

In der IHK-Abschlussprüfung kommen Troubleshooting-Aufgaben in vier wiederkehrenden Mustern vor: Tool zu Szenario, Output interpretieren, Fehlerbild aus Symptomen ableiten, Handlungsempfehlung formulieren. Diese Lektion zeigt dir alle vier Aufgabentypen mit echten Beispielen – und liefert dir die typische Argumentationsstruktur, mit der du in der Prüfung auch unbekannte Aufgaben sicher lösen kannst.

Die Analogie zur Prüfungsvorbereitung: ein Klavierschüler, der nur Stücke übt, wird steif. Wer Tonleitern, Akkorde und Kadenzen separat trainiert, kann am Konzertabend jedes Stück. Genauso bei der IHK: Wer die Aufgabentypen kennt – nicht nur die Inhalte –, erkennt am Erscheinungsbild der Aufgabe sofort, welches mentale Schema er anwenden muss. Das spart in der Prüfung kostbare Minuten.

1) Aufgabentyp A – Welches Tool für welches Szenario?

Klassiker im Multiple-Choice-Teil: Eine Situation ist beschrieben, du sollst das passende Werkzeug benennen. Hier hilft das mentale Schema „Welche OSI-Schicht behandelt das Problem?" – dann ist das Tool meist klar:

Werkzeug-Zuordnung – wann benutze ich was?

Szenario

Ist die Gegenseite überhaupt erreichbar?

Wo im Pfad bleibt das Paket hängen?

Wird der Hostname korrekt aufgelöst?

Welche Ports lauschen auf dem Server?

Was geht tatsächlich über die Leitung?

Welches Programm hält Port 8080 besetzt?

Server ohne GUI mitschneiden

Sporadische Verluste auf einem Hop

Tool

ping

traceroute / tracert

nslookup / dig

netstat / ss

Wireshark

netstat -ano + tasklist

tcpdump

mtr

Eselsbrücke für die Prüfung: Erreichbarkeit → ping, Weg → traceroute, Name → nslookup/dig, Port/Verbindung → netstat/ss, Inhalt → Wireshark/tcpdump.

2) Aufgabentyp B – Output interpretieren

In der schriftlichen Prüfung wird oft ein Tool-Output gezeigt mit der Frage „Was bedeutet das?" oder „Welcher Fehler liegt vor?". Hier zählt das Lesen-Können der Ausgabe – nicht das Auswendiglernen der Befehle. Versuche jeweils, dir die Antwort zu überlegen, bevor du klickst:

Aufgabe 1 — ipconfig /all

Ein Client hat folgenden Output. Was ist die Diagnose?

Ethernet-Adapter Ethernet:
   Physikalische Adresse . . . . . : 00-1B-44-11-3A-B7
   DHCP aktiviert . . . . . . . . : Ja
   Autokonfiguration aktiviert . . : Ja
   IPv4-Adresse . . . . . . . . . : 169.254.142.83(Bevorzugt)
   Subnetzmaske . . . . . . . . . : 255.255.0.0
   Standardgateway . . . . . . . . :
   DNS-Server . . . . . . . . . . :

Lösung & ArgumentationAdressen aus 169.254.0.0/16 (Subnetzmaske 255.255.0.0) sind APIPA – „Automatic Private IP Addressing". Windows vergibt diese automatisch, wenn kein DHCP-Server antwortet. Erkennbar zusätzlich am fehlenden Gateway und fehlenden DNS-Server. Diagnose: DHCP-Server prüfen (läuft? Pool nicht erschöpft? Relay-Konfiguration korrekt?), DHCP-Verkehr mit tcpdump auf UDP 67/68 beobachten.

Aufgabe 2 — ping-Ausgabe

Welche Schlussfolgerung ist am ehesten richtig?

C:\> ping www.firma-intern.de

Ping-Anforderung konnte den Host „www.firma-intern.de" nicht finden.
Überprüfen Sie den Namen, und versuchen Sie es erneut.

C:\> ping 192.168.10.50
Antwort von 192.168.10.50: Bytes=32 Zeit=1ms TTL=128
Antwort von 192.168.10.50: Bytes=32 Zeit=1ms TTL=128

Lösung & ArgumentationPing auf die IP funktioniert (Schicht 3 ok), Ping auf den Namen scheitert mit „Host nicht gefunden". Das ist die klassische Signatur eines DNS-Problems: Schicht 3 funktioniert, die Namensauflösung nicht. Nächste Schritte: nslookup www.firma-intern.de, ggf. mit anderem DNS-Server (nslookup www.firma-intern.de 8.8.8.8) gegenprüfen, DNS-Cache leeren mit ipconfig /flushdns.

Aufgabe 3 — tracert

Wo liegt der Fehler — und wo nicht?

1    1 ms    1 ms    1 ms  192.168.1.1
2   14 ms   15 ms   15 ms  10.50.0.1
3    *     *     *   Anforderung hat das Zeitlimit überschritten.
4   18 ms   17 ms   18 ms  80.81.x.x
5   19 ms   19 ms   20 ms  8.8.8.8

Lösung & ArgumentationSterne in der Mitte eines Pfads bedeuten nicht „Fehler" – viele Core-Router antworten aus Sicherheitsgründen nicht auf ICMP. Solange Hop 4 und das Ziel (Hop 5) wieder antworten und die Route insgesamt durchläuft, ist alles in Ordnung. Echtes Problem nur, wenn ab einem Hop alle folgenden Hops Sterne zeigen.

Aufgabe 4 — netstat / ss

Welche Aussage trifft auf den lokalen sshd zu?

$ sudo ss -tlnp
State  Local Address:Port  Peer Address:Port  Process
LISTEN 127.0.0.1:22      0.0.0.0:*         ("sshd",pid=820)
LISTEN 0.0.0.0:80        0.0.0.0:*         ("nginx",pid=901)

Lösung & ArgumentationDie Bind-Adresse 127.0.0.1:22 ist die Loopback-Adresse – das bedeutet, sshd lauscht nur lokal und akzeptiert keine Verbindungen von außen. Im Gegensatz dazu lauscht nginx auf 0.0.0.0:80 – das heißt „alle Interfaces, alle IPs". Fix: in /etc/ssh/sshd_config die Direktive ListenAddress 0.0.0.0 setzen (oder ListenAddress-Zeile entfernen) und sshd neu starten.

3) Aufgabentyp C – Fehlerbild diagnostizieren

Die anspruchsvollste Aufgabenform: Es wird ein Szenario in Prosa beschrieben, du musst aus den Symptomen die Ursache ableiten. Die Argumentationsstruktur in der Prüfung sollte immer drei Teile enthalten: 1. Wahrscheinlichste Ursache, 2. Begründung aus den Symptomen, 3. Diagnose-Schritt zur Verifikation.

Aufgabe 5 — Fehleranalyse

In einem 50-PC-Büro fallen am Montagmorgen 8 PCs gleichzeitig aus dem Netz. Die betroffenen PCs zeigen eine APIPA-Adresse (169.254.x.x). Die anderen 42 PCs funktionieren normal. Welche Ursache ist die wahrscheinlichste?

Lösung & Argumentation1. Ursache: DHCP-Pool wahrscheinlich ausgeschöpft. 2. Begründung: APIPA = DHCP-Server hat nicht geantwortet. Wenn 42 PCs funktionieren und 8 nicht, ist der DHCP-Server prinzipiell erreichbar – nur die letzten Anfragen bekamen keine Lease. Das passt zu „Pool voll". Bei totalem DHCP-Ausfall wären alle Boot-Vorgänge betroffen. 3. Verifikation: Am DHCP-Server Pool-Auslastung prüfen, Lease-Dauer und Pool-Größe gegen Geräte-Anzahl gegenrechnen.

Aufgabe 6 — Komplexszenario

Ein Benutzer ruft an: „Ich kann meine Mails abrufen, aber nicht im Web surfen." Beide Anwendungen nutzen TCP, beide gehen ins Internet. Welche Erklärung ist plausibel?

Lösung & Argumentation1. Ursache: Wahrscheinlichste Erklärung ist eine Firewall- oder Proxy-Regel, die selektiv HTTP (Port 80) und HTTPS (Port 443) blockiert oder einen falschen Proxy erzwingt. 2. Begründung: Mail (IMAP/SMTP) und Web nutzen unterschiedliche Ports – wenn DNS tot wäre, würde auch Mail nicht funktionieren. Default-Gateway fehlt → gar nichts geht. 3. Verifikation: Browser-Proxy-Konfig prüfen, telnet www.google.de 443 – kommt überhaupt ein TCP-Handshake zustande?

4) Aufgabentyp D – Handlungsempfehlung

Im offenen Antwortteil wird typischerweise nicht nur die Diagnose gefragt, sondern auch das konkrete Vorgehen. Die Erwartung der Prüfer: eine strukturierte Schritt-für-Schritt-Liste, die nachvollziehbar ist und mit dem geringsten Aufwand beginnt:

Musterantwort-Struktur für offene Fragen

Frage: „Ein Benutzer kann keine Websites mehr aufrufen. Beschreiben Sie Ihr systematisches Vorgehen zur Fehlersuche."

Musterantwort:
1. Symptome präzisieren: Welche Webseiten genau? Alle oder nur einige? Seit wann? Andere Anwendungen betroffen?
2. Schicht 1/2 prüfen: Sichtprüfung Kabel, Link-LED, Konnektivität zum Switch.
3. Schicht 3 prüfen: ipconfig /all auf IP, Gateway, DNS. Ping auf Gateway.
4. DNS prüfen: nslookup www.google.de. Wenn fehlerhaft: Cache leeren mit ipconfig /flushdns, mit alternativem DNS gegenprüfen.
5. Erreichbarkeit prüfen: Ping auf 8.8.8.8 (umgeht DNS). Wenn ok: Problem ist DNS, nicht Internet.
6. Schicht 7 prüfen: Anderen Browser testen, Proxy-Konfiguration prüfen.
7. Eskalation: Wenn 1–6 ohne Befund: Ticket mit allen Ergebnissen ans 2nd-Level, Workaround anbieten.
8. Dokumentation: Befund & Lösung in Known Error Database.

Diese 8-Punkte-Struktur funktioniert für jede beliebige Troubleshooting-Aufgabe. In der Prüfung Punkte aus dem konkreten Szenario streichen und ergänzen – aber das Schema bleibt: Symptome → schichtweise Tests → Eskalation → Dokumentation.

5) Selbsttest – Quiz mit Mix aus allen Typen

Acht Aufgaben quer durch die Typen. Tipp: erst überlegen, dann klicken – wie in der echten Prüfung:

Aufgabe 7 — Quick-Check

Welcher Befehl zeigt, welcher Prozess unter Linux Port 443 belegt?

Lösungss mit Flags -t (TCP), -l (Listening), -n (numerisch), -p (Process) zeigt alle TCP-Listen-Sockets mit Prozess-Info. sudo, weil Prozess-Anzeige Root-Rechte braucht.

Aufgabe 8 — Quick-Check

Eine Verbindung zum Webserver scheitert. Welche Aussage über den TCP-Handshake im Wireshark-Trace ist kein Hinweis auf ein Firewall-Problem?

LösungEin vollständiger Drei-Wege-Handshake (SYN, SYN+ACK, ACK) bedeutet, dass die TCP-Verbindung aufgebaut wurde. Das ist kein Firewall-Problem auf Transport-Ebene. Die anderen drei Befunde deuten klar auf Firewall (A: Drop, B: Reject mit RST, D: explizite ICMP-Ablehnung) hin.

Aufgabe 9 — Methodenwahl

Eine Endbenutzerin sagt: „Outlook startet, aber neue Mails kommen nicht rein." Welcher Troubleshooting-Ansatz ist am effizientesten?

LösungDas Symptom ist sehr spezifisch („Outlook läuft, kein Mailempfang") – also Top-Down: erst Mail-Server-Erreichbarkeit prüfen, dann Authentifizierung, dann IMAP/POP3-Konfig, dann Ports und erst zuletzt das tiefere Netz. Bottom-Up wäre Zeitverschwendung, weil die unteren Schichten offensichtlich funktionieren (Outlook startet ja).

Aufgabe 10 — Abschlussfrage

In welcher Reihenfolge sind die Schritte für ein systematisches Vorgehen am sinnvollsten?

LösungDie Standard-Reihenfolge ist: Symptome → Reproduzieren → Was hat sich geändert → Hypothese → Methode → Tests → Verifikation → Umsetzung → Dokumentation. Ohne erfasste Symptome lassen sich keine Hypothesen bilden, ohne Hypothese keine sinnvollen Tests planen.

0/10

Punkte erreicht

Zusammenfassung

IHK-Troubleshooting-Aufgaben folgen vier Mustern: Tool-Zuordnung (welches Werkzeug?), Output-Interpretation (was zeigt diese Ausgabe?), Fehlerbild-Diagnose (welche Ursache passt zu welchem Symptom?), Handlungsempfehlung (was tun?). Die universelle Argumentationsstruktur für offene Fragen: 1. Symptome präzisieren, 2. Schichtweise prüfen, 3. Bei Bedarf eskalieren, 4. Dokumentieren. Eselsbrücken fürs Tool: Erreichbarkeit → ping, Weg → traceroute, Name → nslookup/dig, Port → netstat/ss, Inhalt → Wireshark/tcpdump. Wer das Schema kennt, kann auch unbekannte Aufgaben strukturiert beantworten.