Site icon bintorosoft.com

„No Internet“ mit dem OSI-Modell troubleshooten (vollständige Checkliste)

Data center with server racks in a corridor room. 3D render of digital data and cloud technology

No Internet“ ist eine der häufigsten und zugleich unspezifischsten Störungsmeldungen – im Büro, im Homeoffice oder im NOC. Genau deshalb lohnt sich ein strukturiertes Vorgehen: Wenn Sie „No Internet“ mit dem OSI-Modell troubleshooten, zerlegen Sie das Problem in überprüfbare Teilfragen, statt im Kreis zu testen. Häufig steckt nicht „das Internet“ dahinter, sondern eine lokale Ursache: ein instabiler Link, ein falsches VLAN, ein fehlendes Default Gateway, ein DNS-Problem oder eine Firewall-Regel. Diese Checkliste führt Sie Schicht für Schicht durch ein vollständiges Troubleshooting – so, dass Sie nach jedem Schritt wissen, ob Sie tiefer (Layer 1–2), logisch weiter (Layer 3–4) oder anwendungsnah (Layer 5–7) suchen müssen. Sie erhalten konkrete Prüfungen, typische Fehlerbilder, schnelle Gegenproben und Dokumentationspunkte, mit denen sich ein „No Internet“-Ticket sauber lösen oder belastbar eskalieren lässt. Das Ziel ist nicht, jeden Spezialfall abzudecken, sondern in der Praxis schnell von Symptomen zu Fakten zu kommen – ohne blinden Aktionismus und ohne unnötige Wiederholungen.

Vorbereitung: Scope, Symptome und zwei Minuten, die später Stunden sparen

Bevor Sie in die OSI-Schichten springen, klären Sie drei Dinge. Erstens: Wer ist betroffen (ein Gerät, eine Nutzergruppe, ein Standort, alle)? Zweitens: Was genau bedeutet „No Internet“ (keine WLAN-Verbindung, kein Link am Kabel, keine IP-Adresse, keine Webseiten, nur bestimmte Dienste)? Drittens: Seit wann besteht das Problem und gab es Änderungen (Firmware-Update, neue Firewall-Regel, Provider-Störung, Umbau im Patchfeld)? Diese Vorarbeit verhindert, dass Sie auf dem falschen Layer suchen.

Quick-Triage: Drei Tests, die die Richtung vorgeben

Diese drei Checks entscheiden meist, ob Sie mit Layer 1–2 oder Layer 3–7 starten. Führen Sie sie möglichst auf dem betroffenen Gerät aus:

Wenn keine IP vorhanden ist, sind Layer 2/3 (DHCP, VLAN, WLAN) sehr wahrscheinlich. Wenn Gateway nicht erreichbar ist, suchen Sie primär in Layer 1–2 (Link/VLAN) oder Layer 3 (Gateway-Interface down, falsches Subnetz). Wenn IP-Ping funktioniert, aber Namen nicht, ist DNS (Layer 7) vorn.

Layer 1: Physische Verbindung – Link, Signal, Strom

Beim „No Internet“-Fehlerbild ist Layer 1 überraschend häufig die Ursache: wackelige RJ45-Stecker, defekte Patchkabel, falsch gesteckte Ports, beschädigte LWL-Optiken, schwache WLAN-Signalqualität oder Strom-/PoE-Probleme. Layer 1 ist der schnellste Ausschluss, weil Sie ihn direkt messen können.

Checkliste Layer 1 (Kabel/LWL/WLAN)

Typische Layer-1-Symptome bei „No Internet“

Layer 2: Data Link – VLAN, SSID-Zuordnung, MAC und Switching

Wenn der physische Link stabil ist, liegt „No Internet“ oft an Layer 2: falsches VLAN am Access-Port, Trunk lässt VLAN nicht durch, WLAN-SSID ist auf falsches VLAN gemappt, STP blockt, Port-Security sperrt oder ein Loop verursacht Broadcast-Stürme. In Unternehmensnetzen ist Layer 2 der klassische Bereich nach Changes.

Checkliste Layer 2 (Switching/WLAN-Bridge)

Schnelle Gegenproben auf Layer 2

Für Paketanalysen und Filter, die Ihnen bei DHCP, ARP oder STP helfen, ist der Einstieg über den Anchor-Text Wireshark-Dokumentation sinnvoll.

Layer 3: Network – IP-Adressierung, Gateway, Routing, NAT

Layer 3 beantwortet die Kernfrage: Kann der Client sein Netz verlassen? „No Internet“ entsteht hier durch fehlendes oder falsches Default Gateway, falsche Subnetzmaske/Prefix, IP-Konflikte, fehlerhafte statische Routen, VRF-Missmatch oder Down-States am Gateway-Interface. In vielen Umgebungen kommt NAT hinzu: Der Client hat zwar intern Connectivity, aber nach außen scheitert die Übersetzung oder die Default Route.

Checkliste Layer 3 (Client-seitig)

Checkliste Layer 3 (Netzwerk-seitig)

Traceroute richtig nutzen, ohne falsche Schlüsse

Traceroute zeigt Ihnen die Stelle, an der Antworten ausbleiben. Das ist nicht automatisch „dort ist es kaputt“, aber es ist ein belastbarer Hinweis. Nutzen Sie je nach Umgebung auch TCP-basierte Traceroutes (Port 443), wenn ICMP/UDP gefiltert wird. Für Hintergrundwissen zu Internet-Standards und Routing-Konzepten ist der Anchor-Text RFC-Editor (Netzwerkstandards) eine verlässliche Quelle.

Layer 4: Transport – Ports, Firewalls, Session-States

Wenn IP-Routing grundsätzlich funktioniert, bleibt „No Internet“ häufig als Layer-4-Problem übrig: Ports werden gefiltert, Stateful Firewalls verwerfen Rückverkehr, NAT-States laufen aus, oder es gibt asymmetrisches Routing. Aus Anwendersicht fühlt sich das wie „Internet tot“ an, obwohl Ping zu externen IPs funktionieren kann.

Checkliste Layer 4 (TCP/UDP)

Typische Layer-4-Fehlerbilder bei „No Internet“

Layer 5–6: Session und Darstellung – TLS, Proxies, Loadbalancer, Inspection

In der Praxis äußert sich ein Layer-5/6-Problem oft so: „Ich bin verbunden, aber nichts geht.“ Der TCP-Port ist offen, doch der TLS-Handshake schlägt fehl, ein Proxy verlangt Authentifizierung, oder SSL-Inspection verursacht Zertifikatsfehler. Auch falsche Systemzeit kann hier überraschend häufig „No Internet“-Symptome auslösen, weil Zertifikate als ungültig gelten.

Checkliste für TLS/Proxy/Inspection

Wenn Sie Zeitprobleme ausschließen möchten, ist der Anchor-Text NTP-Dokumentation hilfreich, um typische Ursachen und Prüfpfade zu verstehen.

Layer 7: Anwendung – DNS, HTTP, Captive Portals und „Internet geht nicht“ trotz Connectivity

Layer 7 ist der Bereich, in dem „No Internet“ häufig als Sammelbegriff auftaucht: DNS-Resolver antwortet nicht, Captive Portal blockiert bis zum Login, ein CDN liefert regional falsche Antworten, oder eine Sicherheitslösung blockt Kategorien. Entscheidend ist, dass Sie auf Layer 7 immer zuerst DNS vs. IP trennen und dann messbare Anwendungsindikatoren erheben (Statuscodes, Response-Zeiten, Fehlermeldungen).

Checkliste DNS (häufigster Layer-7-Auslöser)

Checkliste HTTP/HTTPS (Web als Indikator, nicht als Beweis)

Für unabhängige Messungen aus vielen Netzen (z. B. DNS- und Reachability-Checks) ist der Anchor-Text RIPE Atlas Messplattform nützlich.

Vollständige OSI-Checkliste für „No Internet“ (zum Abhaken im Ticket)

Diese Liste ist so aufgebaut, dass jeder Punkt eine Entscheidung erzwingt: bestätigt, ausgeschlossen oder weiterer Test nötig. Sie können sie direkt als internes Runbook übernehmen.

Layer 1 – Physisch

Layer 2 – Switching/Bridging

Layer 3 – IP/Routing/NAT

Layer 4 – Ports/Firewalls/Sessions

Layer 5–6 – TLS/Proxy/Inspection

Layer 7 – DNS/HTTP/Captive Portal

Messwerte und Belege: So dokumentieren Sie „No Internet“ professionell

Gerade bei Eskalationen zählt, dass Sie nicht nur „geht nicht“ melden, sondern einen reproduzierbaren Nachweis liefern. Notieren Sie immer Zeitpunkt, betroffene IP/MAC, VLAN/SSID, Gateway, Testergebnis und die exakte Fehlermeldung (z. B. TLS-Alert, DNS-Response). Das spart Rückfragen und beschleunigt die Zuordnung.

Häufige „No Internet“-Ursachen nach Umgebung (damit Sie schneller priorisieren)

Je nach Kontext sind bestimmte Ursachen wahrscheinlicher. Das ist kein Ersatz fürs OSI-Modell, aber eine gute Priorisierungshilfe.

Homeoffice und kleine Büros

Unternehmensnetz und NOC

Wenn Sie rechnen müssen: Paketverlust sauber ausdrücken (optional für Tickets)

Wenn Nutzer „Internet bricht ständig ab“ melden, ist Paketverlust ein häufiger Indikator. Für ein Ticket ist es hilfreich, eine Loss-Rate nachvollziehbar zu dokumentieren, statt nur „viel Loss“ zu schreiben.

LossRate = verlorenePakete gesendetePakete × 100 %

Wichtig für die Interpretation: Ein Test mit ICMP kann Loss anzeigen, obwohl Anwendungsdaten stabil laufen, wenn ICMP unterwegs niedriger priorisiert wird. Deshalb sollten Sie Loss idealerweise mit mindestens zwei Perspektiven prüfen (z. B. ICMP und ein TCP-basierter Test auf Port 443) und die Ergebnisse dem passenden OSI-Layer zuordnen.

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:

Lieferumfang:

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.

 

Exit mobile version