So nutzt du das OSI-Modell zur Diagnose von „Kein Internet“

Die Meldung „Kein Internet“ ist einer der häufigsten Gründe für Support-Anfragen – und gleichzeitig einer der unspezifischsten. Denn „kein Internet“ kann alles bedeuten: Das WLAN ist weg, das Gerät hat keine IP-Adresse, das Gateway ist nicht erreichbar, DNS funktioniert nicht, eine Firewall blockiert Ports oder nur eine einzelne Website ist gestört. Genau deshalb ist So nutzt du das OSI-Modell zur Diagnose von „Kein Internet“ ein so wirksamer Ansatz: Das OSI-Modell zerlegt Kommunikation in sieben Schichten und gibt Ihnen eine klare, reproduzierbare Prüfreihenfolge. Sie beginnen bei der physischen Grundlage (Kabel, Funk, Signalqualität), prüfen dann die lokale Verbindung (Frames, VLAN, Access Point), anschließend IP und Routing (Gateway, Paketwege), danach Ports und Transport (TCP/UDP), und erst ganz oben die Dienste und Anwendungen (DNS, HTTP/HTTPS, Login, Proxy). Der große Vorteil: Sie arbeiten vom Sicheren zum Unsicheren und vermeiden klassische Fehlannahmen – etwa „DNS ist kaputt“, obwohl das Gerät nur im falschen WLAN hängt. In diesem Artikel erhalten Sie eine praxisnahe Schritt-für-Schritt-Anleitung, die sowohl für Einsteiger verständlich als auch für fortgeschrittene Anwender effizient ist.

Was bedeutet „Kein Internet“ wirklich? Symptome sauber trennen

Bevor Sie in die Schichten gehen, lohnt sich eine schnelle Einordnung. Viele Probleme sehen gleich aus, sind aber technisch verschieden. Wenn Sie das Symptom präzisieren, sparen Sie Zeit.

• Komplettausfall: Keine Website, keine Apps, keine Updates – alles tot.
• Teilweise Störung: Manche Seiten gehen, andere nicht; Streaming geht, Meetings nicht.
• Nur ein Gerät betroffen: Smartphone ohne Internet, Laptop funktioniert.
• Nur ein Dienst betroffen: Web geht, aber E-Mail nicht; oder umgekehrt.
• „WLAN verbunden, aber kein Internet“: Verbindung zum Access Point existiert, aber kein Weg ins Internet.

Diese Einordnung entscheidet, ob Sie „unten“ beginnen müssen oder ob ein Top-down-Check (z. B. DNS/Proxy) schneller ist. In den meisten Fällen ist bei „kein Internet“ Bottom-up die sicherste Strategie.

Die OSI-Checkliste als Diagnosepfad

Merken Sie sich eine einfache Regel: Ohne stabile Basis (Schicht 1/2) lohnen sich Tests oben kaum. Deshalb folgt die Diagnose idealerweise diesem Ablauf:

• Schicht 1: Gibt es eine physische Verbindung/Signalqualität?
• Schicht 2: Bin ich wirklich korrekt verbunden (SSID/VLAN/Link)?
• Schicht 3: Habe ich eine gültige IP-Konfiguration und ein erreichbares Gateway?
• Schicht 4: Sind wichtige Ports/Transporte erreichbar (z. B. 443/HTTPS)?
• Schicht 5–7: Funktionieren DNS, HTTPS, Proxy, Captive Portal, Anwendungen?

Als Faustregel gilt: Timeouts deuten oft auf Schicht 1–4 hin, während Fehlermeldungen mit Codes häufiger Schicht 6–7 betreffen (z. B. HTTP-Statuscodes, TLS-Warnungen).

Schritt 1: Schicht 1 prüfen – Physical Layer

Auf Schicht 1 geht es um das Medium selbst: Funk (WLAN), Kupferkabel (Ethernet) oder Glasfaser/Modem-Strecke. Viele „Kein Internet“-Fälle sind in Wahrheit instabile oder fehlende physische Übertragung.

• LAN: Kabel sitzt fest, Port-Link am Gerät oder Switch leuchtet, kein offensichtlicher Kabelbruch.
• WLAN: Signalstärke nicht nur „Balken“, sondern stabil; Abstand zum Router/Access Point; keine extremen Störungen.
• Router/Modem: hat Strom, zeigt keine offensichtliche Störung (z. B. rote Warn-LED).
• Typische Symptome: Verbindungen brechen sporadisch ab, alles lädt extrem langsam, Ping hat hohe Paketverluste.

Wenn Sie eine allgemeine Referenz zu Ethernet benötigen: IEEE 802.3 (Ethernet) Überblick. Bei WLAN hilft IEEE 802.11 (WLAN) Überblick als grobe Orientierung.

Schritt 2: Schicht 2 prüfen – Data-Link-Layer

Schicht 2 ist die lokale Verbindung im Netzsegment. Hier entscheiden Frames, MAC-Adressen, Switches, Access Points und in vielen Umgebungen VLANs. Besonders häufig: Das Gerät ist „verbunden“, aber im falschen Netz oder mit eingeschränktem Zugriff.

• Richtiges WLAN? Nicht versehentlich im Gastnetz, in einem alten Netzwerkprofil oder an einem Repeater mit Captive Portal.
• Captive Portal/Hotspot? Manche Netze erlauben erst Internet, nachdem Sie sich im Browser angemeldet haben.
• VLAN/Port-Profil (Unternehmen): falsches VLAN kann Internetzugang blockieren, während lokale Verbindung besteht.
• Symptome: „Verbunden ohne Internet“, interne Geräte teils erreichbar, aber extern nichts.

Ein wichtiges Bindeglied zwischen Schicht 2 und 3 ist ARP (bei IPv4), weil Ihr Gerät die MAC-Adresse des Gateways kennen muss. Wenn ARP scheitert, kann IP nicht starten. Technische Referenz: RFC 826 (ARP).

Schritt 3: Schicht 3 prüfen – Network Layer

Wenn Link und lokale Verbindung grundsätzlich stehen, kommt Schicht 3: IP-Konfiguration und Routing. Hier steckt ein Großteil der „Kein Internet“-Ursachen, insbesondere im Heimnetz und nach Routerwechseln.

• Hat das Gerät eine gültige IP-Adresse? Passt sie zum Netzwerk (nicht „falsch“ oder automatisch/unerwartet)?
• Ist das Default Gateway gesetzt? Ohne Gateway kein Weg ins Internet.
• Ist das Gateway erreichbar? Wenn nicht, ist es meist Schicht 1/2 oder Gateway selbst.
• IPv4/IPv6: Manchmal funktioniert nur eines davon; Symptome können „halb kaputt“ wirken.

Die Grundlagen sind in den Standards definiert: RFC 791 (IPv4) und RFC 8200 (IPv6). Für Diagnosemeldungen ist ICMP relevant: RFC 792 (ICMP).

DNS richtig einsortieren: Häufige Ursache, aber nicht der erste Schritt

DNS ist technisch ein Anwendungsdienst, wirkt aber wie „Internet an/aus“, weil ohne DNS viele Nutzerseiten nicht mehr funktionieren. Wichtig ist die Reihenfolge: Wenn das Gateway nicht erreichbar ist, bringt DNS-Testen nichts. Wenn IP zum Internet grundsätzlich geht, aber Domains nicht auflösen, ist DNS sehr wahrscheinlich.

Eine leicht verständliche Erklärung liefert Cloudflare: Was ist DNS?.

Schritt 4: Schicht 4 prüfen – Transport Layer

Wenn IP-Routing grundsätzlich klappt, aber „Internet“ trotzdem nicht nutzbar ist, ist Schicht 4 der nächste Fokus. Viele Netze erlauben ICMP (Ping) oder einzelne Ziele, blockieren aber Webports oder bestimmte Protokolle. Das sieht dann so aus: „Ping geht, aber Browser nicht.“

• HTTPS-Port erreichbar? Für Web ist Port 443 entscheidend.
• TCP-Handshake möglich? Timeouts deuten auf Blockaden oder Pfadprobleme, „Connection refused“ auf fehlenden Dienst.
• UDP-Anwendungen: manche Dienste (z. B. moderne Echtzeitkommunikation) sind UDP-sensitiv.

TCP und UDP sind die Basis: RFC 793 (TCP) und RFC 768 (UDP).

Schritt 5: Schicht 5 prüfen – Session Layer

Schicht 5 wird bei „kein Internet“ oft erst relevant, wenn die Verbindung grundsätzlich funktioniert, aber Dienste „aus dem Login fliegen“ oder sich nicht stabil halten – etwa bei VPNs, Captive Portals oder Unternehmensproxies. In solchen Fällen ist Internet nicht komplett weg, sondern „bricht im Kontext“.

• Symptome: Anmeldung klappt kurz, danach wieder weg; wiederkehrende Captive-Portal-Umleitungen.
• Ursachen: Session-Timeouts, Token-Probleme, NAT-Timeouts, Proxy-Sitzungen.
• Praxismerkmal: Fehler tritt oft nach einer reproduzierbaren Zeitspanne auf.

Schritt 6: Schicht 6 prüfen – Presentation Layer

Auf Schicht 6 landen Probleme rund um TLS/HTTPS, Zertifikate und Datenrepräsentation. Das ist besonders dann relevant, wenn Webseiten „nicht sicher“ melden oder Verbindungen trotz erreichbarem Port scheitern.

• TLS-Handshake scheitert: kann wie „kein Internet“ wirken, obwohl TCP/Port erreichbar ist.
• Zertifikatswarnungen: Uhrzeit falsch, Zertifikat abgelaufen, MITM-Proxy im Unternehmensnetz.
• Symptome: Browser zeigt Sicherheitswarnungen, Apps melden „secure connection failed“.

Für TLS-Grundlagen eignet sich MDN zu Transport Layer Security. Für HTTP/HTTPS-Kontext hilft MDN zu HTTP.

Schritt 7: Schicht 7 prüfen – Application Layer

Wenn alle unteren Schichten funktionieren, liegt das Problem sehr wahrscheinlich in der Anwendungsschicht: DNS-Auflösung, Proxy-Konfiguration, Browser-Cache, Sicherheitssoftware, Unternehmensrichtlinien oder serverseitige Störungen einzelner Dienste.

• DNS-Probleme: Domains lösen nicht auf, aber IP-Zugriffe funktionieren (z. B. direkte IP im Browser).
• Proxy/Firewall: Internet nur über Proxy erlaubt, Proxy falsch konfiguriert oder nicht erreichbar.
• HTTP-Fehler: 403/429/5xx sind keine „Leitungsfehler“, sondern anwendungsbezogene Antworten.
• Captive Portal: Internetzugang wird erst nach Login freigeschaltet, sonst werden Requests umgeleitet.

Praktische Diagnosepfade für die häufigsten „Kein Internet“-Varianten

Die folgende Zuordnung hilft, nicht bei jedem Problem alle Schichten komplett durchzugehen. Sie wählen den Pfad passend zum Symptom.

Variante A: „WLAN verbunden, aber kein Internet“

• Start bei Schicht 2: richtiges WLAN, kein Gastnetz, Captive Portal prüfen.
• Dann Schicht 3: IP-Adresse und Gateway plausibel und erreichbar?
• Dann DNS/Schicht 7: Namensauflösung ok? Falls nicht, DNS-Server/Resolver prüfen.

Variante B: „Kein Gerät im Haushalt hat Internet“

• Start bei Schicht 1: Router/Modem online? Kabel zur Dose/ONT korrekt? LED-Status plausibel?
• Dann Schicht 3: hat der Router eine WAN-Verbindung (IP) und ein Default Gateway vom Provider?
• Dann Schicht 4/7: werden DNS/HTTPS geblockt oder liegt eine Providerstörung vor?

Variante C: „Internet geht, aber bestimmte Seiten nicht“

• Start bei Schicht 7: HTTP-Statuscodes, Redirects, Region/Policy, Browser-Cache.
• Dann Schicht 6: TLS-Zertifikate, Unternehmensproxy, Uhrzeit/Datum.
• Dann Schicht 3: Routing zu bestimmten Netzen gestört (Peering/Transit), DNS liefert andere Ziele.

Variante D: „Ping geht, aber Browser lädt nicht“

• Start bei Schicht 4: Port 443 erreichbar? Firewall/Filter prüfen.
• Dann Schicht 6: TLS-Handshake/Zertifikate.
• Dann Schicht 7: Proxy-/DNS-Konfiguration, HTTP-Fehlercodes.

Messwerte richtig lesen: Latenz, Verlust, Durchsatz

Auch bei „kein Internet“ lohnt ein Blick auf Stabilität. Manchmal ist Internet nicht vollständig weg, sondern so instabil, dass es wie ein Ausfall wirkt. Zwei Größen sind besonders aussagekräftig: Paketverlust und stark schwankende Latenz. Als einfaches Denkmodell gilt: Je höher die Verlustquote, desto geringer die effektive Nutzbarkeit – weil Wiederholungen, Timeouts und Retransmissions zunehmen.

$\mathrm{Effektive Nutzbarkeit}\approx \mathrm{Verbindung}\times (1-\mathrm{Verlustquote})$

Diese Näherung ist bewusst vereinfacht, aber praktisch hilfreich: Eine Verbindung mit hoher Bandbreite, aber 5–10 % Verlust fühlt sich oft schlechter an als eine langsamere, dafür stabile Verbindung.

Dokumentation: So halten Sie Diagnoseergebnisse sauber fest

Wenn Sie den Fehler nicht sofort lösen können, ist eine klare Dokumentation entscheidend – für Provider, IT-Abteilungen oder spätere Nacharbeit. OSI-basiert dokumentieren bedeutet: Sie notieren, welche Schichten Sie ausgeschlossen haben und wo das Problem wahrscheinlich liegt.

• Schichtstatus: Welche Ebenen sind nachweislich ok (z. B. Link aktiv, Gateway erreichbar)?
• Symptomtyp: Timeout vs. Fehlermeldung mit Code.
• Betroffene Ziele: alle Ziele oder nur bestimmte Domains/Netze?
• Zeit und Kontext: seit wann, nach welcher Änderung, sporadisch oder dauerhaft?

Für Grundlagen zu HTTP-Fehlern und deren Bedeutung ist MDN zu HTTP-Statuscodes eine hilfreiche Referenz, weil sie klar zwischen Netzwerkproblemen und Server-/Anwendungsantworten unterscheidet.

Merksätze für die Praxis: Damit „Kein Internet“ schnell eingegrenzt wird

• „WLAN verbunden“ ist nur Schicht 2: Internetzugang beginnt erst mit Schicht 3 (Gateway/Routing) und darüber.
• Wenn das Gateway nicht erreichbar ist: prüfen Sie zuerst Schicht 1 und 2, nicht DNS.
• Wenn IP geht, aber Namen nicht: DNS ist der nächste Verdächtige.
• Ping ist kein Webtest: ICMP (Schicht 3) sagt nichts über Port 443, TLS oder HTTP aus.
• Fehlermeldungen sind oft besser als Stille: Codes und Hinweise deuten eher auf Schicht 6–7, Timeouts eher auf Schicht 1–4.

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.