Das OSI-Modell als Werkzeug zur Fehlersuche
Das OSI-Modell teilt Netzwerkkommunikation in sieben Schichten. Beim Troubleshooting hilft es, einen Fehler räumlich einzugrenzen: Ist das Kabel kaputt? Fehlt eine IP-Adresse? Funktioniert DNS nicht? Oder ist nur der Webserver gestört?
Merksatz: Je weiter unten der Fehler liegt, desto mehr darüberliegende Funktionen fallen meistens ebenfalls aus.
Bottom-up
Von Schicht 1 nach oben prüfen. Ideal, wenn unklar ist, ob überhaupt eine Verbindung besteht.
Standardmethode für viele Netzwerkfehler.
Top-down
Bei der Anwendung beginnen und nach unten arbeiten. Sinnvoll, wenn die Verbindung grundsätzlich funktioniert, aber ein bestimmter Dienst nicht.
Divide & Conquer
In der Mitte beginnen, z. B. mit einem Ping auf Schicht 3. Abhängig vom Ergebnis nach oben oder unten weiterarbeiten.
Die wichtigste Denkkette
Die 7 OSI-Schichten
Anwendung – Application
Aufgabe: Netzwerkdienste für Programme und Benutzer.
Beispiele: HTTP/HTTPS, DNS, SMTP, FTP, SSH.
Fehler: Website lädt nicht, DNS-Auflösung schlägt fehl, Login/Dienst funktioniert nicht.
Prüfen: Browser, nslookup, curl, Dienststatus.
Darstellung – Presentation
Aufgabe: Datenformate, Kodierung, Kompression, Verschlüsselung.
Beispiele: TLS/SSL, UTF-8, JPEG, JSON/XML-Darstellung.
Fehler: Zertifikatsfehler, falsche Kodierung, inkompatibles Format.
Prüfen: Zertifikat, TLS-Version, Encoding, Format.
Sitzung – Session
Aufgabe: Sitzungen aufbauen, verwalten und beenden.
Beispiele: Sitzungsverwaltung, Authentifizierungskontext, RPC-Sitzungen.
Fehler: Session bricht ab, erneute Anmeldung nötig, Timeout.
Prüfen: Session-Timeouts, Logs, Authentifizierung.
Transport – Transport
Aufgabe: Ende-zu-Ende-Transport, Ports, Zuverlässigkeit.
Protokolle: TCP, UDP.
Fehler: Port blockiert, TCP-Verbindung kommt nicht zustande, Paketverlust.
Prüfen: netstat, Test-NetConnection, Firewall, Wireshark.
Vermittlung – Network
Aufgabe: IP-Adressierung und Routing zwischen Netzen.
Protokolle: IPv4/IPv6, ICMP, Routingprotokolle.
Fehler: falsche IP, Subnetzmaske oder Gateway; Route fehlt.
Prüfen: ipconfig/ip, ping, tracert/traceroute.
Sicherung – Data Link
Aufgabe: Kommunikation im lokalen Netz über Frames und MAC-Adressen.
Beispiele: Ethernet, WLAN-MAC, VLAN, ARP als Grenzthema L2/L3.
Fehler: falsches VLAN, MAC-/Switch-Port-Probleme, WLAN-Zuordnung.
Prüfen: Switch-Port, VLAN, MAC-Tabelle, arp -a.
Bitübertragung – Physical
Aufgabe: Bits als elektrische, optische oder Funk-Signale übertragen.
Beispiele: Kabel, Stecker, Glasfaser, Funk, NIC, Switch-Port.
Fehler: Kabel defekt, kein Link, schlechte Funkverbindung, Port deaktiviert.
Prüfen: LEDs, Kabel tauschen, Port testen, Signalstärke.
Systematisches Troubleshooting: Bottom-up
Schicht 1 – Physik
Ist das Kabel eingesteckt? Leuchtet die Link-LED? Ist WLAN aktiv? Ist der Adapter aktiviert?
Wenn nein: Erst diesen Fehler beheben. Höhere Schichten können dann nicht funktionieren.
Schicht 2 – Lokales Netz
Ist der Client im richtigen VLAN? Erkennt der Switch die MAC-Adresse? Besteht die WLAN-Verbindung zum richtigen Netz?
Schicht 3 – IP & Routing
ipconfig /all bzw. ip addr prüfen. Dann stufenweise pingen: 127.0.0.1 → eigene IP → Gateway → entfernte IP.
Schicht 4 – Ports
Ist der benötigte TCP-/UDP-Port erreichbar? Beispiel HTTPS: TCP 443. Unter Windows z. B. Test-NetConnection server -Port 443.
Schicht 5–7 – Dienst & Anwendung
DNS-Auflösung, TLS-Zertifikat, Anmeldung, Serverdienst, Browser-/Clientkonfiguration und Anwendungslogs prüfen.
Ping-Logik, die du dir merken solltest
| Test | Wenn erfolgreich | Wenn fehlgeschlagen |
|---|---|---|
ping 127.0.0.1 | TCP/IP-Stack lokal grundsätzlich aktiv | Lokales Betriebssystem / TCP-IP-Stack prüfen |
ping eigene_IP | IP-Konfiguration/NIC lokal reagiert | Adapter/IP-Konfiguration prüfen |
ping Gateway | Lokales Netz bis Router erreichbar | L1–L3 lokal prüfen: Kabel/WLAN, VLAN, IP, Maske, Gateway |
ping 8.8.8.8 | Routing ins Internet grundsätzlich möglich | Gateway, Routing, Provider oder Firewall prüfen |
ping example.com | IP-Konnektivität + Namensauflösung funktionieren wahrscheinlich | Wenn IP-Ping geht: DNS besonders verdächtig |
Praxisfälle
Fall 1: „Kein Internet“
1. Link/WLAN prüfen → Schicht 1/2.
2. ipconfig /all: Hat der Rechner eine gültige IP? Eine Adresse wie 169.254.x.x deutet häufig darauf hin, dass keine DHCP-Adresse bezogen wurde.
3. Gateway pingen.
4. Externe IP pingen.
5. Domainnamen testen. Funktioniert die IP, aber nicht der Name, liegt der Verdacht bei DNS.
Fall 2: Website nicht erreichbar, Ping funktioniert
Schicht 3 funktioniert zumindest teilweise. Jetzt Schicht 4–7 prüfen:
Test-NetConnection webserver -Port 443 → Port erreichbar?
Danach DNS, TLS-Zertifikat, Webserverdienst, Proxy und Anwendung prüfen.
Fall 3: Ein PC erreicht den Server, ein anderer nicht
Da der Server grundsätzlich erreichbar ist, zuerst die Unterschiede der Clients vergleichen: IP, Subnetzmaske, Gateway, DNS, VLAN, lokale Firewall, Proxy und Netzwerkkarte.
Fall 4: Server ist per IP erreichbar, aber nicht per Name
Wahrscheinlich: DNS-Problem auf Schicht 7.
Prüfen mit nslookup servername oder Resolve-DnsName servername.
Fall 5: Nur ein bestimmter Dienst funktioniert nicht
Wenn andere Dienste auf demselben Server funktionieren, sind Schicht 1–3 wahrscheinlich in Ordnung. Prüfe Port, Firewall und Anwendung: z. B. TCP 443 für HTTPS oder TCP 22 für SSH.
Werkzeugkasten
| Befehl / Tool | Wofür? | OSI-Schwerpunkt |
|---|---|---|
ipconfig /all | IP, Maske, Gateway, DNS, DHCP unter Windows | 3 / 7 |
ip addr | IP-Adressen unter Linux | 3 |
ping | Erreichbarkeit / ICMP-Test | 3 |
tracert / traceroute | Pfad über Router sichtbar machen | 3 |
arp -a | Zuordnung IP ↔ MAC im lokalen Netz ansehen | 2/3 |
nslookup | DNS-Auflösung prüfen | 7 |
Resolve-DnsName | DNS-Abfrage mit PowerShell | 7 |
netstat -ano | Verbindungen, Ports und Prozesse anzeigen | 4 |
Test-NetConnection HOST -Port 443 | TCP-Port testen | 4 |
curl | HTTP/HTTPS-Anwendung direkt testen | 7 |
| Wireshark | Pakete/Frames analysieren | 2–7 |
Prüfungsmerksatz
MAC = Schicht 2 · IP = Schicht 3 · TCP/UDP + Ports = Schicht 4 · HTTP/DNS/SMTP = Schicht 7.