„No Internet“-Playbook: Effektivste Check-Reihenfolge

Ein belastbares „No Internet“-Playbook: Effektivste Check-Reihenfolge ist im IT-Alltag kein Luxus, sondern ein zentraler Hebel für schnelle Entstörung, klare Kommunikation und geringe Ausfallkosten. Wenn Nutzer „kein Internet“ melden, kann die Ursache praktisch überall liegen: am Endgerät, im WLAN, im Access-Switch, im DHCP/DNS, am Default Gateway, an der Firewall, beim ISP oder an Upstream-Diensten. Ohne strukturierte Reihenfolge verlieren Teams Zeit mit Sprüngen zwischen Tools und Verantwortlichkeiten. Genau deshalb braucht es ein standardisiertes Vorgehen, das von Einsteigern sicher angewendet werden kann und für Profis trotzdem tief genug ist. Dieses Playbook priorisiert Checks nach Wahrscheinlichkeit, Wirkung und Diagnosegeschwindigkeit. Der Fokus liegt auf reproduzierbaren Prüfschritten, sauberer Evidenz und einer Eskalationslogik, die unnötige Schleifen verhindert. So wird aus der unscharfen Meldung „Internet geht nicht“ ein präziser technischer Befund mit klarer Ownership – unabhängig davon, ob es um Homeoffice, Standortnetz, Hybrid-Cloud oder verteilte Filialinfrastruktur geht.

Warum eine feste Check-Reihenfolge schneller zum Ziel führt

Der größte Zeitverlust in Incidents entsteht selten durch fehlendes Fachwissen, sondern durch unstrukturierte Reihenfolgen. Wer zuerst komplexe Kernnetzthemen prüft, obwohl am Client nur der Flugmodus aktiv ist, verbrennt Minuten. Wer direkt den ISP kontaktiert, obwohl das DHCP-Lease abgelaufen ist, erzeugt unnötige Eskalationen. Eine effektive Reihenfolge arbeitet deshalb mit drei Prinzipien:

• Von lokal nach global: Erst Endgerät, dann LAN/WLAN, dann Standortdienste, dann WAN/Internet.
• Von simpel nach komplex: Sichtprüfung und Basiszustand vor tiefen Paketanalysen.
• Von hoher Trefferquote zu Spezialfällen: Häufige Ursachen zuerst, Randfälle später.

Diese Logik reduziert die mittlere Entstörzeit (MTTR), verbessert die Übergabe zwischen 1st-/2nd-/3rd-Level und sorgt dafür, dass dieselben Symptome im Team gleich interpretiert werden.

Das Kernmodell: 7 Ebenen im „No Internet“-Playbook

Für den Betrieb ist es hilfreich, „kein Internet“ in sieben prüfbare Ebenen zu zerlegen. Jede Ebene liefert ein Ja/Nein-Signal, das den nächsten Schritt eindeutig bestimmt.

• Ebene 1 – Endgerät-Status: Link, WLAN-Association, IP-Konfiguration.
• Ebene 2 – Lokales Netz: Erreichbarkeit des Gateways, VLAN, Access-Port, SSID.
• Ebene 3 – Basisdienste: DHCP, DNS, NTP.
• Ebene 4 – Standort-Edge: NAT, Firewall-Policy, Uplink-Status.
• Ebene 5 – ISP/WAN: Carrier-Link, Routing nach außen, Paketverlust.
• Ebene 6 – Zielabhängigkeit: Ist „Internet“ wirklich global gestört oder nur bestimmte Dienste?
• Ebene 7 – Sicherheit/Compliance: ZTNA, Proxy, Zertifikate, Captive Portals, Richtlinien.

Die Ebenen sind bewusst praxisnah und tool-neutral gehalten, damit sie in jeder Infrastruktur umgesetzt werden können.

Effektivste Check-Reihenfolge in der Praxis

Schritt 1: Scope in 60 Sekunden klären

Bevor technische Checks starten, muss die Reichweite eindeutig sein. Fragen Sie strukturiert:

• Ein einzelner Nutzer, ein Team, ein Gebäude oder mehrere Standorte?
• Nur WLAN, nur LAN oder beides?
• Seit wann tritt der Fehler auf, dauerhaft oder intermittierend?
• Alle Webseiten betroffen oder nur einzelne Anwendungen?

Diese Einordnung entscheidet, ob Sie clientnah starten oder sofort standortweite Komponenten prüfen.

Schritt 2: Endgerät und Verbindung prüfen

• Flugmodus, deaktivierter Adapter, Energiesparzustand ausschließen.
• WLAN verbunden mit korrekter SSID? LAN-Kabel physisch stabil?
• Hat das Gerät eine gültige IP, Subnetzmaske, Gateway und DNS-Server?
• Gibt es APIPA/Link-Local-Adressen statt DHCP-Lease?

Hier liegen überdurchschnittlich viele Störungen, besonders nach Updates, Sleep/Wake-Wechseln oder Standortwechseln.

Schritt 3: Gateway-Test als Trennlinie

Der Ping zum Default Gateway ist ein entscheidender Weichensteller:

• Gateway nicht erreichbar: Problem lokal/L2/L3 am Access-Segment wahrscheinlich.
• Gateway erreichbar: Fokus auf DNS, Firewall, NAT, WAN oder Upstream.

Zusätzlich helfen ARP-Checks und ein kurzer Blick auf Interface-Fehlerzähler (CRC, Drops, Flaps).

Schritt 4: DNS vor „Internet defekt“ verifizieren

Viele „No Internet“-Meldungen sind reine Namensauflösungsprobleme. Prüfen Sie:

• Funktioniert DNS-Auflösung für mehrere bekannte Domains?
• Liefern unterschiedliche Resolver unterschiedliche Ergebnisse?
• Sind interne DNS-Forwarder erreichbar und gesund?

Ein klassischer Schnelltest: Erreichbarkeit einer bekannten IP prüfen und mit einem FQDN-Test vergleichen. Wenn IP geht, Name nicht, liegt der Schwerpunkt auf DNS.

Schritt 5: Port- und Protokolltests durchführen

Auch bei funktionierendem DNS kann Internetzugang durch Richtlinien selektiv blockiert sein:

• HTTPS (443) testen, optional HTTP (80) je nach Umgebung.
• Proxy- oder ZTNA-Vorgaben gegen realen Clientstatus prüfen.
• TLS-Handshake und Zertifikatskette kontrollieren.

So trennen Sie generelle Erreichbarkeit von policy-bedingten Einschränkungen.

Schritt 6: Edge, NAT und Firewall-Policy prüfen

• Hat der Standort-Uplink stabile Link- und Routing-Parameter?
• Werden Sessions aufgebaut oder sofort verworfen?
• Ist NAT funktionsfähig (Translationen vorhanden, Pools nicht erschöpft)?
• Gab es kürzliche Regeländerungen oder automatische Policy-Deployments?

In vielen Umgebungen entstehen Ausfälle durch gut gemeinte Security-Änderungen ohne ausreichend gestaffelte Freigabeprüfung.

Schritt 7: ISP/WAN und externe Reichweite belegen

• Traceroute zu mehreren unabhängigen Zielen durchführen.
• Paketverlust und Latenz über definierte Zeitfenster messen.
• BGP-/Provider-Status am Edge bewerten.

Erst wenn lokale und standortnahe Ursachen ausgeschlossen sind, sollte die Eskalation zum Carrier erfolgen – dann jedoch mit belastbaren Messwerten.

Entscheidungsbaum für schnelle Zuordnung

Ein kompakter Entscheidungsbaum reduziert Denkfehler:

• Keine IP-Konfiguration: DHCP/Access-Ebene.
• IP vorhanden, Gateway nicht erreichbar: L2/L3 lokal.
• Gateway erreichbar, DNS fehlerhaft: DNS/Resolver/Forwarder.
• DNS ok, 443 blockiert: Firewall/Proxy/Policy.
• Alles lokal ok, extern instabil: WAN/ISP/Upstream-Routing.
• Nur einzelne Dienste betroffen: App-/Provider-spezifische Störung statt „Internet down“.

Diese Logik verhindert pauschale Aussagen und lenkt jede Beobachtung in den passenden Verantwortungsbereich.

Die häufigsten Ursachen nach Umgebung

Büro- und Campus-Netze

• Fehlerhafte VLAN-Zuordnung am Access-Port
• Abgelaufene 802.1X-Sessions
• DHCP-Scope erschöpft
• WLAN-Roaming-Probleme mit alten Treibern

Homeoffice und Remote-Arbeit

• Instabile CPE-Router/ONTs
• DNS-Probleme durch lokale Routerkonfiguration
• Split-Tunnel-Fehlkonfiguration in VPN-Clients
• MTU/PMTUD-Probleme bei bestimmten Providern

Hybrid-Cloud und verteilte Standorte

• Asymmetrisches Routing zwischen On-Prem und Cloud
• Uneinheitliche Sicherheitsrichtlinien über Regionen
• Private DNS-Zonen inkonsistent
• NAT-Gateway-Engpässe unter Last

Messbare Priorisierung statt Bauchgefühl

Wenn mehrere Hypothesen gleichzeitig plausibel sind, hilft ein einfaches Priorisierungsmodell. Bewerten Sie je Hypothese:

• Impact (Auswirkung auf Geschäft/Nutzer) von 1 bis 5
• Likelihood (Eintrittswahrscheinlichkeit) von 1 bis 5
• Speed-to-Verify (Prüfaufwand) von 1 bis 5, wobei 5 = sehr schnell prüfbar

Dann priorisieren Sie nach:

$\mathrm{Prioritätswert}=\frac{\mathrm{Impact}\times \mathrm{Likelihood}\times \mathrm{Speed-to-Verify}}{5}$

So beginnen Sie mit den Ursachen, die hohe Wirkung haben und gleichzeitig schnell belegbar sind.

Toolset für schnelle, reproduzierbare Checks

Ein solides Playbook braucht kein überladenes Arsenal, sondern verlässliche Standardwerkzeuge:

• Client: IP-Status, Route, DNS-Lookup, Basis-Ping/Traceroute
• Netzwerk: Interface-Status, ARP/MAC, VLAN, ACL/Policy, NAT-Sessions
• Sicherheit: Proxy-/ZTNA-Status, Zertifikatsprüfung, TLS-Diagnose
• Observability: Zeitkorrelierte Logs, Metriken, synthetische Checks

Entscheidend ist die Standardisierung: Jeder Check sollte im Team gleich benannt, gleich ausgeführt und gleich dokumentiert werden.

Dokumentationsstandard für Incident-Tickets

Damit Eskalationen nicht ins Leere laufen, sollten Tickets strukturiert sein:

• Betroffener Scope (Nutzer, Standort, Netzsegment)
• Beginnzeit und Verlauf (dauerhaft/intermittierend)
• Ergebnis pro Check-Schritt (inkl. Zeitstempel)
• Konkrete Evidenz (Fehlercode, Trace, Session-Status)
• Nächster Owner mit klarer Fragestellung

Ein guter Eintrag lautet nicht „Internet kaputt“, sondern etwa: „Gateway erreichbar, DNS-Resolver antwortet nicht auf UDP/TCP 53 im VLAN 20 seit 09:12 Uhr.“

Runbook-Qualität erhöhen: Betriebsroutinen für Teams

• Wöchentliche Mini-Reviews: Welche Check-Schritte waren in echten Incidents am wirksamsten?
• Known-Issue-Katalog: Wiederkehrende Muster mit präzisen Gegenmaßnahmen.
• Änderungsfenster absichern: Nach Policy-Deployments automatische Konnektivitäts-Tests.
• Schulungen für 1st-Level: Fokus auf Scope, Gateway, DNS, Porttest, saubere Eskalation.

So entwickelt sich das Playbook von einer statischen Liste zu einem lernenden Betriebsinstrument.

Outbound-Ressourcen für belastbare Praxisstandards

• RFC Editor der IETF für Netzwerk- und Internetprotokolle
• Wireshark-Dokumentation für Paketanalysen im Incident-Fall
• ICANN-Überblick zu DNS als kritischer Basisdienst
• OpenTelemetry-Dokumentation für Metriken, Logs und Traces
• Netzwerkgrundlagen mit OSI-Bezug in der Cisco Networking Academy

Kompakte Checkliste für den täglichen Einsatz

• Scope klären: Wer ist betroffen und seit wann?
• Endgerät prüfen: Adapter, SSID/LAN, IP/Gateway/DNS.
• Gateway testen: erreichbar oder nicht?
• DNS validieren: Name vs. IP vergleichen.
• Port/TLS testen: 443, Proxy, Zertifikate.
• Edge prüfen: NAT, Firewall, Uplink.
• WAN/ISP belegen: Traces, Loss, Latenz.
• Ergebnisse dokumentieren und gezielt eskalieren.

Mit dieser Reihenfolge wird aus „No Internet“ ein klar eingrenzbarer Vorgang mit hoher Erstlösungsquote, weniger Fehleskalationen und stabileren Serviceprozessen im Tagesbetrieb.

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.