Lösung des Fehlers „Verbunden, aber kein Internet“ im Guest WiFi

Behebung des Fehlers „Verbunden, aber kein Internet“ im Gäste-WiFi — Ein technisches Briefing von Purple [EINFÜHRUNG & KONTEXT — ca. 1 Minute] Willkommen zur Purple Technical Briefing-Serie. Ich bin Ihr Gastgeber, und heute befassen wir uns mit einem der hartnäckigsten und frustrierendsten Probleme im Bereich der Netzwerke für Unternehmensstandorte: dem Fehler „verbunden, kein Internet“ im Gäste-WiFi. Wenn Sie die WiFi-Infrastruktur in einem Hotel, einer Einzelhandelskette, einem Stadion oder einem Konferenzzentrum verwalten, haben Sie das sicher schon erlebt. Das Gerät eines Gastes zeigt vollen Signalempfang, ist mit Ihrem Access Point verbunden und hat eine IP-Adresse zugewiesen bekommen – und dennoch lädt der Browser nichts. Das Captive Portal wird nie geladen. Der Gast ruft an der Rezeption an. Ihr Support-Team führt einen Ping-Test durch, auf dem Papier sieht alles bestens aus, und dennoch tritt das Problem immer wieder auf. Der Punkt ist folgender: In der überwiegenden Mehrheit der Fälle, die mir bei Implementierungen in Unternehmen begegnen, handelt es sich weder um einen Hardwarefehler noch um eine Fehlkonfiguration der Firewall und auch nicht um ein Bandbreitenproblem im herkömmlichen Sinne. Es handelt sich um ein DNS-Timing-Problem – und dieses wird fast immer durch eine Netzwerküberlastung verursacht. Heute möchte ich Ihnen genau erklären, warum das passiert, wie Sie es zuverlässig diagnostizieren und wie der Einsatz eines DNS-Filters für Unternehmen diesen Engpass dauerhaft beseitigt. [TECHNISCHER DEEP-DIVE — ca. 5 Minuten] Beginnen wir mit den Grundlagen. Wenn sich das Gerät eines Gastes mit Ihrem WiFi-Netzwerk verbindet, muss es als allererstes – noch bevor es eine einzige Webseite laden kann, bevor Ihr Captive Portal es umleiten kann, bevor eine Authentifizierung stattfinden kann – einen Domainnamen über DNS in eine IP-Adresse auflösen. Das Domain Name System ist das Telefonbuch des Internets. Ohne dieses weiß Ihr Gerät nicht, wohin es den Datenverkehr senden soll. Und hier beginnt das Problem. Die meisten Endgeräte – iPhones, Android-Handys, Windows-Laptops – verfügen über einen integrierten Mechanismus, den sogenannten Captive Portal Detection Probe. Unter iOS sendet das Gerät beispielsweise eine HTTP-Anfrage an einen bekannten Apple-Endpunkt wie captive.apple.com. Unter Android steuert es connectivitycheck.gstatic.com an. Unter Windows prüft es msftconnecttest.com. Diese Abfragen dienen dazu, zu erkennen, ob das Netzwerk eine Anmeldeseite erfordert, bevor der Internetzugang gewährt wird. Der entscheidende Punkt ist: Diese Abfragen sind DNS-abhängig. Das Gerät muss zuerst den Domainnamen des Abfrage-Endpunkts auflösen, bevor es die HTTP-Anfrage senden kann. Und diese DNS-Abfrage hat ein Zeitlimit (Timeout) – je nach Betriebssystem liegt dieses normalerweise zwischen einer und fünf Sekunden. Wenn der DNS-Resolver in Ihrem Netzwerk nicht innerhalb dieses Zeitfensters antwortet, kommt das Gerät zu dem Schluss, dass das Netzwerk keine Internetverbindung hat, obwohl es vollständig verbunden ist und über eine gültige IP-Adresse verfügt. Das ist der Fehler "Verbunden, kein Internet". Es handelt sich dabei nicht um einen Verbindungsfehler – es ist ein Fehler bei der DNS-Antwort. Warum also versagt DNS in einem überlasteten Netzwerk? Das ist der Punkt, an dem viele Teams scheitern. DNS-Anfragen werden standardmäßig über UDP auf Port 53 gesendet. UDP ist ein verbindungsloses Protokoll – es gibt keinen Handshake, keine Bestätigung und keine erneute Übertragung auf der Transportschicht. Wenn ein DNS-Paket aufgrund von Netzwerküberlastung verworfen wird, wartet der Client einfach, bis das Timeout abläuft, und versucht es dann erneut oder gibt auf. In einem Gäste-WiFi-Netzwerk mit Hunderten oder Tausenden von gleichzeitigen Geräten – man denke an ein Stadion während eines Spiels, ein voll belegtes Hotel oder ein Konferenzzentrum während einer Keynote – können der Upstream-Link und der DNS-Resolver sehr schnell überlastet sein. Das Problem wird dadurch verschlimmert, dass sich Gäste-Netzwerke in der Regel einen einzigen Upstream-DNS-Resolver teilen, oft den Standard-Resolver des ISPs oder einen öffentlichen Resolver wie 8.8.8.8. Wenn jedes Gerät im Netzwerk gleichzeitig nach der Captive Portal-Erkennung sucht, Hintergrund-App-Updates ausführt und DNS-Anfragen für soziale Medien und Streaming-Dienste stellt, wird dieser einzelne Resolver zum Nadelöhr. Die Antwortzeiten für Anfragen steigen vom normalen Bereich unter 50 Millisekunden auf Hunderte oder sogar Tausende von Millisekunden. Es kommt zu Timeouts. Die Fehlermeldungen „Verbunden, kein Internet“ häufen sich. Es gibt noch einen zweiten Mechanismus, den man verstehen sollte: die TTL-Erschöpfung. DNS-Antworten enthalten einen „Time To Live“-Wert, der dem empfangenden Gerät mitteilt, wie lange die aufgelöste IP-Adresse zwischengespeichert werden soll. In einem überlasteten Netzwerk, in dem sich Geräte ständig an- und abmelden – was in Umgebungen mit hoher Dichte üblich ist –, laufen die zwischengespeicherten Einträge ab und müssen häufig neu aufgelöst werden. Dies erhöht die DNS-Anfragelast auf dem Resolver genau dann, wenn das Netzwerk am stärksten belastet ist. Die traditionelle Reaktion auf dieses Problem besteht nun darin, Bandbreite bereitzustellen – den Upstream-Link aufzurüsten, mehr Access Points hinzuzufügen und QoS-Richtlinien zu implementieren. Dies sind alles sinnvolle Maßnahmen, aber sie beheben nicht die Ursache. Die Ursache liegt darin, dass Ihr DNS-Auflösungspfad für Gästeumgebungen mit hoher Dichte nicht optimiert ist. Und genau das löst ein Enterprise-DNS-Filter. Ein Enterprise-DNS-Filter – wie die DNS-Filterfunktion innerhalb der Gäste-WiFi-Plattform von Purple – fungiert als lokaler, leistungsstarker DNS-Resolver, der zwischen Ihren Gästegeräten und dem Upstream-Internet sitzt. Anstatt jede Anfrage an einen entfernten öffentlichen Resolver weiterzuleiten, hält er einen lokalen Cache häufig aufgelöster Domains vor, verarbeitet Erkennungsanfragen für das Captive Portal nativ und wendet richtlinienbasierte Filterung an, um schädliche oder nicht konforme Domains zu blockieren, bevor sie überhaupt den Upstream-Resolver erreichen. Das Ergebnis ist eine drastisch reduzierte DNS-Anfragelatenz – in der Regel von Timeouts von zwei bis drei Sekunden auf Antworten unter 200 Millisekunden –, was bedeutet, dass Erkennungsanfragen für das Captive Portal beim ersten Versuch erfolgreich sind, der Fehler „Verbunden, kein Internet“ verschwindet und die Onboarding-Zeit für Gäste erheblich sinkt. Aus Sicht der Standards entspricht diese Architektur den Empfehlungen von IEEE 802.11 für High-Density-Bereitstellungen und unterstützt die Einhaltung der DSGVO-Datenschutzanforderungen (GDPR), indem DNS-Abfragen protokolliert und überprüft werden können – was besonders relevant ist, wenn Sie unter einer Lizenz für den öffentlichen Sektor oder das Gastgewerbe arbeiten. Zudem werden die Netzwerksegmentierungsanforderungen nach PCI DSS unterstützt, da sichergestellt wird, dass der Gast-DNS-Verkehr von Ihrer internen Resolver-Infrastruktur isoliert bleibt. [IMPLEMENTIERUNGSEMPFEHLUNGEN & PHÄNOMENE — ca. 2 Minuten] Lassen Sie mich Ihnen praktische Richtlinien für die Bereitstellung an die Hand geben. Wenn Sie einen Enterprise-DNS-Filter in einem Gast-WiFi-Netzwerk einführen, entscheiden drei Konfigurationsentscheidungen über Erfolg oder Misserfolg. Erstens: Die Platzierung des Resolvers. Ihr DNS-Filter muss so nah wie möglich am Gästenetzwerk platziert werden – idealerweise im selben VLAN oder Subnetz wie Ihre Gast-Access-Points. Jeder Hop zwischen dem Gastgerät und dem Resolver erhöht die Latenz. Wenn sich Ihr DNS-Filter in einem entfernten Rechenzentrum befindet und Ihr Gästenetzwerk in einem Hotel in Manchester ist, erhöht dies die Roundtrip-Zeit, was den Zweck hinfällig macht. Nutzen Sie eine lokale Appliance oder einen Cloud-basierten DNS-Filter mit einem regionalen Point of Presence. Zweitens: DNS-Passthrough für das Captive Portal. Dies ist die häufigste Fehlkonfiguration, die mir begegnet. Wenn Sie einen DNS-Filter einrichten, müssen Sie sicherstellen, dass die eigene Domain des Captive Portals – die URL, auf die Gäste zur Authentifizierung weitergeleitet werden – im Filter auf der Whitelist steht. Wenn der Filter die Auflösung Ihrer Captive Portal-Domain blockiert oder verzögert, erzeugen Sie genau das Problem, das Sie eigentlich lösen wollten. Testen Sie die Auflösung des Captive Portals nach dem Einrichten jeder DNS-Filterrichtlinie immer explizit. Drittens: TTL-Tuning. Konfigurieren Sie Ihren lokalen DNS-Resolver so, dass er kurze TTLs für die Probe-Domains zur Erkennung von Captive Portals (Apple, Google, Microsoft) bereitstellt. Dadurch fragen die Geräte häufiger an und erhalten immer eine schnelle lokale Antwort, anstatt auf das Ablaufen eines zwischengespeicherten Eintrags zu warten und dann auf einen überlasteten Upstream-Resolver zuzugreifen. Eine TTL von 30 bis 60 Sekunden für diese spezifischen Domains ist ein sinnvoller Ausgangspunkt. Die zu vermeidende Falle ist das Überfiltern. Einige Teams setzen aggressive DNS-Blocklisten ein, die unbeabsichtigt Domains blockieren, die von legitimen Gastanwendungen genutzt werden – Streaming-Dienste, VPN-Endpunkte von Unternehmen, Cloud-Speicher. Dies erzeugt eine andere Art von Support-Ticket, schadet der Gasterfahrung jedoch gleichermaßen. Beginnen Sie mit einer konservativen Richtlinie, überwachen Sie die DNS-Abfrageprotokolle auf blockierte Domains und verfeinern Sie diese über einen Zeitraum von zwei Wochen, bevor Sie die Konfiguration endgültig sperren. [SCHNELLE FRAGEN & ANTWORTEN — ca. 1 Minute] Lassen Sie mich die Fragen durchgehen, die mir zu diesem Thema am häufigsten gestellt werden. "Kann ich nicht einfach 8.8.8.8 als meinen Gast-DNS-Resolver verwenden?" Das können Sie, aber unter Last wird es zu Timeouts kommen. Ein lokaler oder regionaler Resolver wird auf einem überlasteten Netzwerk immer eine bessere Leistung erbringen als ein öffentlicher Resolver. "Betrifft dies WPA3-Bereitstellungen?" Nein – WPA3 verbessert die Authentifizierungssicherheit, ändert jedoch nichts am DNS-Auflösungspfad. Das gleiche DNS-Timeout-Problem tritt unabhängig vom verwendeten Verschlüsselungsstandard auf. "Wie finde ich heraus, ob DNS die tatsächliche Ursache für meine Fehler \"verbunden, kein Internet\" ist?" Führen Sie während der Spitzenlast eine Paketaufzeichnung auf dem Gast-VLAN durch. Filtern Sie nach Datenverkehr auf UDP-Port 53. Wenn Sie DNS-Abfragen ohne entsprechende Antwort innerhalb von zwei Sekunden sehen, ist das DNS-Timeout die Ursache. "Hilft ein Enterprise-DNS-Filter bei der Compliance?" Ja – die Protokollierung von DNS-Abfragen bietet einen Audit-Trail, der die GDPR-Rechenschaftspflichten unterstützt und bei der Reaktion auf Vorfälle helfen kann. Die Plattform von Purple enthält diese Protokollierung nativ. [ZUSAMMENFASSUNG & NÄCHSTE SCHRITTE — ca. 1 Minute] Zusammenfassend lässt sich sagen: Der Fehler \"verbunden, kein Internet\" bei Gast-WiFi ist in den allermeisten Fällen ein DNS-Timing-Problem, das durch Netzwerküberlastung verursacht wird, die einen nicht optimierten Resolver-Pfad überfordert. Die Lösung ist nicht mehr Bandbreite – es ist ein lokaler, leistungsstarker Enterprise-DNS-Filter, der Captive Portal-Erkennungstests schnell auflöst, einen lokalen Cache pflegt und richtlinienbasierte Filterung anwendet, um die Last der Upstream-Abfragen zu reduzieren. Die drei wichtigsten Aufgaben für diese Woche: Führen Sie während der Spitzenlast eine DNS-Paketaufzeichnung durch, um die Diagnose zu bestätigen; überprüfen Sie die Platzierung Ihres aktuellen DNS-Resolvers und stellen Sie fest, ob dieser lokal oder remote ist; und evaluieren Sie die Bereitstellung eines Enterprise-DNS-Filters in Ihrem Gast-VLAN. Wenn Sie tiefer in dieses Thema einsteigen möchten, beschreibt die Dokumentation der Purple-Plattform die DNS-Filterkonfiguration im Detail, und die Leitfäden zur Gast-WiFi-Optimierung auf purple.ai sind neben diesem Briefing ebenfalls einen Blick wert. Vielen Dank fürs Zuhören – bis zum nächsten Mal. [ENDE DER EPISODE]