February 14, 2026

OSI-Modell und Wireshark: Pakete pro Schicht lesen

Mit OSI-Modell und Wireshark lassen sich Netzwerkprobleme deutlich schneller verstehen und beheben, weil Sie Datenverkehr nicht „gefühlt“, sondern strukturiert analysieren. Wireshark zeigt Ihnen Pakete in einer Detailtiefe, die sonst oft nur in Protokollspezifikationen sichtbar ist: MAC-Adressen, IP-Header, TCP-Flags, DNS-Records, HTTP-Header, TLS-Handshakes und vieles mehr. Das OSI-Modell liefert dazu den roten Faden: Welche Informationen gehören zu welcher Schicht, warum erscheinen sie genau dort, und welche Felder sind bei der Fehlersuche wirklich relevant? In der Praxis ist wichtig zu wissen, dass Wireshark Protokolle nicht streng nach OSI sortiert, sondern nach dem tatsächlichen Stack (meist TCP/IP). Dennoch können Sie die sieben OSI-Schichten sehr gut als „Brille“ nutzen, um jedes Paket Schritt für Schritt zu lesen: von Bits und Frames bis zu Anwendungen wie DNS oder HTTP. Dieser Leitfaden zeigt Ihnen, wie Sie in Wireshark Pakete pro Schicht interpretieren, sinnvolle Filter setzen und typische Muster erkennen – sowohl für Einsteiger als auch für Fortgeschrittene, die ihr Troubleshooting systematisieren möchten.

Table of Contents

Wireshark-Grundlagen: So „sehen“ Sie die Schichten im Tool

Bevor Sie einzelne OSI-Schichten lesen, sollten Sie die drei zentralen Bereiche von Wireshark sicher beherrschen. Sie bilden die Grundlage für jede Analyse:

Packet List (oben): Liste aller erfassten Frames/Pakete, inklusive Zeitstempel, Quelle/Ziel, Protokoll und Info-Spalte.
Packet Details (mittig): Dekodierte Protokollbäume (z. B. Ethernet, IPv4/IPv6, TCP, TLS, HTTP, DNS).
Packet Bytes (unten): Rohdaten in Hex/ASCII; hilfreich, wenn Sie Byte-Offsets nachvollziehen oder Payloads verifizieren möchten.

Die „Schichten“ erscheinen in Wireshark im Detailbereich als verschachtelte Protokollblöcke. Ein typisches Web-Paket kann dort etwa so wirken: Ethernet (Schicht 2) → IP (Schicht 3) → TCP (Schicht 4) → TLS (Schicht 6-nah) → HTTP (Schicht 7). Je nach Verkehr sehen Sie statt TLS auch „HTTP“, statt TCP manchmal „UDP“, und bei lokalen Vorgängen häufig „ARP“ oder „ICMP“.

Capture sauber starten: Damit Ihre Analyse belastbar ist

Die beste Paketinterpretation hilft wenig, wenn der Capture unvollständig oder verzerrt ist. Achten Sie deshalb auf diese Best Practices, bevor Sie „Start“ klicken:

Richtiges Interface wählen: WLAN, Ethernet, VPN-Tunnel oder virtuelle Adapter – der falsche Adapter führt zu „leeren“ Captures.
Promiscuous Mode bewusst einsetzen: In Switch-Netzen sehen Sie sonst oft nur Ihren eigenen Traffic; in vielen Szenarien ist das ausreichend.
Capture Filter vs. Display Filter unterscheiden: Capture Filter reduzieren bereits beim Mitschnitt (effizient, aber riskant). Display Filter filtern nachträglich (flexibler).
Zeitbasis beachten: Für Troubleshooting ist eine korrekte Systemzeit (NTP) hilfreich, besonders beim Vergleich mit Server-Logs.

Offizielle Einstiegsdokumentation finden Sie im Wireshark User’s Guide. Für Filter ist das Display-Filter-Referenzdokument besonders nützlich.

OSI-Schicht 1: Physical Layer in Wireshark richtig einordnen

Die Physical Layer (Bits, Signale, Kabel) wird in Wireshark nicht „direkt“ sichtbar, weil Wireshark typischerweise oberhalb der reinen Signalerfassung arbeitet. Dennoch gibt es Hinweise, die auf physische Probleme hindeuten können – insbesondere, wenn Sie Captures an der richtigen Stelle erstellen (z. B. am betroffenen Client oder am Switch-Port-Mirror).

Indirekte Symptome: Viele Retransmissions, CRC-/FCS-Probleme (wenn sichtbar), Link-Flaps (meist eher in System-/Switch-Logs).
Timing-Anomalien: Extrem schwankende Inter-Packet-Gaps können auf Störungen oder Überlastung hindeuten.
Praktischer Tipp: Wenn Sie Verdacht auf Layer-1-Probleme haben, kombinieren Sie Wireshark mit Interface-Statistiken (Errors, Drops, Speed/Duplex).

Merke: Schicht 1 prüfen Sie selten „im Paket“, sondern über die Auswirkungen in höheren Schichten und über Geräte- und Link-Statistiken.

OSI-Schicht 2: Data Link Layer lesen – Ethernet, MAC und VLAN

Schicht 2 ist in Wireshark sehr greifbar, weil Ethernet-Frames und MAC-Adressen in fast jedem lokalen Capture auftauchen. Öffnen Sie im Packet-Details-Baum den Block Ethernet II. Dort finden Sie unter anderem:

Source/Destination MAC: Wer spricht lokal mit wem?
EtherType: Welche Nutzlast folgt (z. B. IPv4, IPv6, ARP)?
VLAN-Tag (802.1Q), falls vorhanden: Zugehöriges VLAN und Priorisierung (PCP).

ARP als Layer-2-nahes Schlüsselprotokoll

ARP (Address Resolution Protocol) wirkt wie eine Brücke zwischen Layer 2 und Layer 3: Es löst IP-Adressen in MAC-Adressen auf, damit Frames im lokalen Netz zugestellt werden können. In Wireshark erkennen Sie ARP schnell über den Display Filter arp. Typische Analysefragen:

Gibt es ARP Requests ohne Replies? Das kann auf falsche IPs, VLAN-Trennung oder Offline-Geräte hinweisen.
Sehen Sie Gratuitous ARP? Das kann normal sein (IP-Announcement), aber auch bei Konflikten relevant werden.

Broadcasting verstehen

Broadcasts sind auf Layer 2 normal, aber zu viele Broadcasts können Netze belasten. In Wireshark sehen Sie Broadcast-MACs typischerweise als ff:ff:ff:ff:ff:ff. Wenn Ihre Capture-Liste von Broadcasts dominiert wird, lohnt sich ein Blick auf VLAN-Design und Geräteverhalten.

OSI-Schicht 3: Network Layer lesen – IPv4/IPv6, Routing und ICMP

Auf Schicht 3 geht es um IP-Adressen, TTL/Hop Limit, Fragmentierung und grundlegende Zustellung zwischen Netzen. Im Packet-Details-Baum öffnen Sie Internet Protocol Version 4 oder Internet Protocol Version 6. Wichtige Felder für die Praxis:

Source/Destination IP: Endpunkte der Kommunikation (logische Adressen).
TTL (IPv4) / Hop Limit (IPv6): Nützlich bei Routingproblemen oder Loop-Verdacht.
DSCP/Traffic Class: QoS-Markierungen, relevant bei Sprach-/Video-Problemen.
Fragmentierung: IPv4-Flags/Offset; bei MTU-Problemen besonders wichtig.

ICMP richtig einordnen

ICMP ist ein Kontrollprotokoll auf Network-Layer-Ebene, das Sie oft bei „Ping“, „Destination Unreachable“ oder „Time Exceeded“ sehen. Filter: icmp (für IPv4) oder icmpv6. Typische Erkenntnisse:

Destination Unreachable: Hinweis auf fehlende Route, Firewall, Port nicht erreichbar oder MTU/Fragmentierungsprobleme.
Time Exceeded: Kann auf Routing-Loops hinweisen (klassisch bei Traceroute).

OSI-Schicht 4: Transport Layer lesen – TCP, UDP und Ports

Schicht 4 ist für Troubleshooting besonders ergiebig, weil hier Verbindungen, Ports und Zustandslogik sichtbar werden. In Wireshark öffnen Sie den TCP– oder UDP-Block. Achten Sie bei TCP vor allem auf:

Ports: z. B. 443 (HTTPS), 80 (HTTP), 22 (SSH), 53 (DNS über UDP/TCP).
Flags: SYN, ACK, FIN, RST – sie erklären Verbindungsaufbau, Abbau und Abbrüche.
Sequence/Acknowledgment Numbers: Grundlage für Zuverlässigkeit und Ordnung.
Window Size / Window Scaling: Hinweise auf Durchsatz und Flow-Control.
Retransmissions und Dup ACKs: wichtige Signale bei Paketverlust und Performanceproblemen.

TCP-Handshake in Wireshark erkennen

Ein normaler TCP-Verbindungsaufbau besteht aus SYN → SYN/ACK → ACK. In der Packet-Liste sehen Sie das oft in der Info-Spalte. Praktische Filter:

tcp.flags.syn == 1 and tcp.flags.ack == 0 (SYN-Pakete)
tcp.flags.reset == 1 (Verbindungsabbrüche per RST)
tcp.analysis.retransmission (Wiederholungen)

Wenn Sie viele SYNs ohne SYN/ACK sehen, deutet das häufig auf Blockierung (Firewall), falsche Zieladresse, Routing oder Server-Down hin. Sehen Sie SYN/ACK, aber kein abschließendes ACK, liegt die Ursache eher auf dem Rückweg oder beim Client.

UDP richtig lesen

UDP ist verbindungslos: kein Handshake, keine ACKs. Das macht UDP „leicht“, aber bei Verlusten schwerer zu beurteilen. In Wireshark analysieren Sie UDP typischerweise über Anwendungssignale (z. B. DNS-Response fehlt, VoIP-Jitter, Streaming-Aussetzer).

OSI-Schicht 5: Session Layer in der Wireshark-Praxis

Die Session-Schicht ist in realen Stacks selten als eigener Block sichtbar. Dennoch können Sie sessionartige Mechanismen erkennen – je nach Protokoll und Anwendung. Beispiele sind Sitzungs-IDs, Keep-Alives oder Wiederaufnahmeverfahren.

HTTP-Sessions: Cookies, Tokens und Session-IDs erscheinen in Headern (Anwendungsbereich), repräsentieren aber Sitzungslogik.
TLS-Session Resumption: Wiederaufnahme kann Handshakes verkürzen und wirkt wie „Session-Management“.
Keep-Alive-Verhalten: TCP Keepalive oder Applikations-Keepalives helfen, Verbindungszustände zu erhalten.

In Wireshark ist es oft sinnvoll, Schicht 5 als „Verbindungs- und Sitzungslogik über Schicht 4/7“ zu verstehen, statt eine separate Protokollliste zu erwarten.

OSI-Schicht 6: Presentation Layer – Encoding, Kompression und TLS lesen

Auf Schicht 6 geht es um Darstellung, Kodierung und Verschlüsselung. In modernen Netzen ist TLS hier der wichtigste Baustein: Die Inhalte sind geschützt, aber Metadaten (z. B. SNI, Zertifikate, Cipher Suites) sind weiterhin analysierbar. In Wireshark sehen Sie dafür typischerweise den Block TLS (oder bei älteren Captures SSL/TLS).

ClientHello/ServerHello: Beginn des Handshakes, Aushandlung von Version und Cipher Suites.
SNI (Server Name Indication): Welcher Hostname wird angefragt? Das hilft bei Multi-Host-Servern und CDN.
Zertifikate: Aussteller, Gültigkeit, Subject/Subject Alternative Names.
ALPN: Aushandlung von HTTP/2 oder HTTP/1.1 (häufig sichtbar).

Für TLS-Hintergrund lohnt sich die Spezifikation TLS 1.3 (RFC 8446). Wenn Sie TLS-Payload entschlüsseln möchten (z. B. im Testlab), nutzen Sie Verfahren wie (Pre)-Master-Secret-Logging oder Schlüsselmaterial aus Browsern, stets im Rahmen Ihrer Berechtigung und Datenschutzvorgaben; Details finden sich in der Wireshark-Dokumentation.

OSI-Schicht 7: Application Layer – DNS, HTTP, SMTP und mehr in Wireshark

Auf der Application Layer wird Wireshark für die meisten Anwender „richtig lesbar“, weil hier bekannte Protokolle auftauchen. Je nach Umgebung sehen Sie DNS, HTTP, SMTP, SSH, DHCP, NTP und viele weitere. Entscheidend ist: Schicht 7 erklärt oft warum etwas scheitert (z. B. falscher DNS-Record, HTTP-Statuscode, fehlender Header), während Schicht 3/4 erklärt, ob die Verbindung überhaupt zustande kommt.

DNS Schritt für Schritt lesen

DNS ist ein idealer Startpunkt, weil es häufig „vor“ dem eigentlichen Webzugriff passiert. Filter: dns. In den Details achten Sie auf:

Query Name: welcher Hostname wird aufgelöst?
Query Type: A, AAAA, CNAME, MX, TXT usw.
Response Code: NOERROR, NXDOMAIN, SERVFAIL.
Answers: welche IPs werden geliefert, gibt es CNAME-Ketten?
Timing: wie lange dauert Query → Response?

Wenn Webseiten nicht öffnen, aber Ping auf IP klappt, ist DNS oft der Engpass: NXDOMAIN, Zeitüberschreitungen oder falsche Antworten sind in Wireshark schnell sichtbar.

HTTP lesen: Requests, Statuscodes, Header

Unverschlüsseltes HTTP (Port 80) können Sie direkt lesen: Filter http. Achten Sie auf:

Methoden: GET, POST, PUT, DELETE.
Statuscodes: 200, 301/302, 401/403, 404, 500.
Host und Pfad: Zielressource und virtueller Host.
Header: User-Agent, Accept, Content-Type, Cache-Control.

Bei HTTPS sehen Sie HTTP erst nach Entschlüsselung; ohne Entschlüsselung bleibt die Analyse auf TLS-Metadaten, Server-IP, SNI, Zertifikat und Timing beschränkt.

Pakete pro Schicht „lesen“: Ein praktisches Vorgehensmodell

Um OSI-Modell und Wireshark effektiv zu kombinieren, hat sich ein schrittweises Vorgehen bewährt. Statt sofort „oben“ (Anwendung) zu starten, prüfen Sie schichtenweise, wo die Kette bricht.

Schicht 2: Sehen Sie überhaupt Frames? Stimmt VLAN? Funktioniert ARP (Requests/Replies)?
Schicht 3: Gibt es IP-Pakete zum Ziel? Kommen Antworten zurück? Gibt es ICMP-Fehler?
Schicht 4: Kommt ein TCP-Handshake zustande? Gibt es RSTs, Retransmissions, Timeouts?
Schicht 6: Scheitert TLS am Handshake, Zertifikat oder Version/Cipher?
Schicht 7: Gibt es DNS-Antworten? Welche HTTP-Statuscodes? Welche App-Fehler?

Dieses Muster verhindert, dass Sie bei einem Layer-3-Problem Zeit in HTTP-Headern verlieren oder bei einem DNS-Problem fälschlich an Firewalls drehen.

Filter- und Analyse-Shortcuts für OSI-orientiertes Arbeiten

Wireshark wird erst richtig schnell, wenn Sie Display Filter gezielt einsetzen. Die folgenden Filter sind besonders OSI-tauglich, weil sie klar bestimmte Ebenen adressieren:

Schicht 2: arp, eth.addr == aa:bb:cc:dd:ee:ff, vlan
Schicht 3: ip.addr == 192.0.2.10, ipv6.addr == 2001:db8::1, icmp, icmpv6
Schicht 4: tcp.port == 443, udp.port == 53, tcp.flags.reset == 1, tcp.analysis.retransmission
Schicht 7: dns, http, smtp, dhcp (oft als bootp sichtbar)

Zusätzlich helfen Wireshark-Funktionen wie „Follow TCP Stream“ (bei unverschlüsseltem Traffic), „Statistics → Conversations“ (wer spricht wie viel mit wem) und „Statistics → I/O Graphs“ (Verlauf von Traffic/Events über Zeit). Details dazu finden Sie im Wireshark User’s Guide.

Timing und Performance verstehen: Latenz sichtbar machen

Gerade bei „langsam“ ist das Timing entscheidend. Wireshark arbeitet mit Zeitstempeln pro Frame. Häufig möchten Sie eine Zeitdifferenz in Millisekunden interpretieren, etwa zwischen Request und Response. Um Sekunden in Millisekunden umzurechnen, gilt:

$t (ms) = t (s) \times 1000$

Praktisch bedeutet das: Wenn Wireshark in der „Time“-Spalte oder in Delta-Angaben 0,250 s zeigt, entspricht das 250 ms. Für TCP können Sie außerdem RTT-nahe Hinweise über ACK-Delays und Retransmissions erkennen. Bei DNS lohnt sich die reine Query-Response-Differenz als schnelle Heuristik.

Typische Stolpersteine: Warum Wireshark nicht „die Wahrheit“ ist

Wireshark zeigt, was am Capture-Punkt ankommt. Das ist nicht immer identisch mit dem, was im Netz insgesamt passiert. Deshalb sollten Sie diese Grenzen kennen:

Capture-Ort entscheidet: Am Client sehen Sie Client-Perspektive, am Server Server-Perspektive; beides kann sich unterscheiden.
Switching ist unsichtbar ohne Mirror/TAP: Auf einem Client sehen Sie nicht automatisch den Verkehr anderer Geräte.
Offloading-Effekte: NIC-Offloading kann Darstellung beeinflussen (z. B. Checksums), ohne dass real ein Fehler vorliegt.
Verschlüsselung begrenzt Einblick: Ohne Schlüsselmaterial sehen Sie bei TLS primär Metadaten und Timing.

Wenn Sie diese Punkte berücksichtigen, bleibt Wireshark ein äußerst zuverlässiges Werkzeug, besonders in Kombination mit OSI-Denken.

Weiterführende Quellen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Netzwerkdesign & Topologie-Planung
Router- & Switch-Konfiguration (Cisco IOS)
VLAN, Inter-VLAN Routing
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
NAT, ACL, DHCP, DNS-Konfiguration
Troubleshooting & Netzwerkoptimierung
Packet Tracer Projektentwicklung & Dokumentation
CCNA Lern- & Praxisunterstützung

Lieferumfang:

Konfigurationsdateien
Packet-Tracer-Dateien (.pkt)
Netzwerkdokumentation
Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.