Behebung des Fehlers "Verbunden, kein Internet" im Gäste-WiFi

Der Fehler "Verbunden, kein Internet" im Gäste-WiFi tritt auf, wenn Konnektivitätsprüfungen fehlschlagen, bevor das Captive Portal lädt. In stark frequentierten Bereichen kommt es bei UDP-Port-53-DNS-Abfragen (RFC 1035) während Überlastungen zu Zeitüberschreitungen. Zur Behebung müssen die DHCP-Bereiche für Gäste auf einen cachenden DNS-Filter verwiesen, Walled-Garden-Domains über Controller wie Cisco Meraki hinweg vervollständigt und Traffic-Shaping-Regeln überprüft werden.

Wie äußert sich "Verbunden, kein Internet" im Gäste-WiFi?

Der Gast sieht volle Empfangsbalken und ein verbundenes Netzwerk, aber es lädt nichts. Die Anmeldeseite erscheint nie, sodass keine Nutzungsbedingungen akzeptiert oder Anmeldungen durchgeführt werden können. Die Gäste wenden sich daraufhin an die Rezeption, den Helpdesk oder den Service-Counter.

Jedes Betriebssystem formuliert die Warnung anders. Ihr Support-Team sollte alle Varianten kennen:

• Windows zeigt "Kein Internet" unter dem Netzwerknamen an.
• Android zeigt "Verbunden ohne Internet" oder "Internet eventuell nicht verfügbar" an.
• iPhone und iPad zeigen "Keine Internetverbindung" unter dem Netzwerknamen an.

Alle drei Meldungen beruhen auf demselben Mechanismus. Nach dem Verbindungsaufbau fordert das Gerät eine bekannte Webadresse an, um die Verbindung zu testen. Liefert dieser Test die erwartete Seite zurück, stuft das Gerät die Verbindung als funktionierend ein. Wird eine Anmeldeseite zurückgegeben, öffnet das Gerät das Captive Portal. Erhält es gar keine Antwort, meldet das Gerät "kein Internet".

Bevor das Gerät eine dieser Seiten anfordern kann, muss es den Hostnamen über DNS auflösen. Diese Auflösung ist der Auslöser für die meisten Ausfälle in Umgebungen mit hoher Gerätedichte.

Was verursacht üblicherweise den Fehler "Verbunden, kein Internet" im Gäste-WiFi?

DNS-Zeitüberschreitungen in einem überlasteten Netzwerk

DNS (Domain Name System) wandelt einen Hostnamen in eine IP-Adresse um. Die meisten DNS-Abfragen laufen über UDP-Port 53, wie in RFC 1035 definiert. UDP verfügt über keine integrierte Übertragungswiederholung, sodass eine verworfene Abfrage einfach auf den geräteeigenen Zeitgeber für erneute Versuche wartet.

Netzwerküberlastungen treten stoßweise auf - zum Beispiel in der Halbzeitpause im Stadion, beim Check-out im Hotel am Morgen oder wenn ein Zug im Bahnhof einfährt. Hunderte von Geräten verbinden sich innerhalb von Sekunden, und jedes sendet gleichzeitig eine Auflösungsanfrage. Wenn der Resolver mehrere Hops entfernt über eine ausgelastete WAN-Verbindung erreichbar ist, werden Abfragen verzögert oder verworfen. Das Gerät bricht ab, das Portal öffnet sich nicht und der Gast sieht die Meldung "kein Internet".

Weitere häufige Ursachen

DNS ist in belebten Umgebungen die häufigste Ursache, aber nicht die einzige. Folgende Punkte sollten ebenfalls ausgeschlossen werden:

• Fehlende Walled-Garden-Einträge. Der Walled Garden ist die Liste der Domains, die ein Gerät vor der Anmeldung erreichen darf. Wenn Ihr Portal oder dessen Assets fehlen, kann die Seite nicht geladen werden.
• Erschöpfung des DHCP-Pools. Wenn der Adresspool aufgebraucht ist, weisen sich die Geräte selbst eine 169.254.x.x-Adresse zu und können nichts mehr erreichen.
• Ratenbegrenzungen oder QoS-Drosselung für UDP-Port 53. Ein zu eng gewähltes Limit pro Client oder SSID kann dem DNS-Dienst bei Spitzenlasten Ressourcen entziehen.
• Verschlüsseltes DNS. DNS over HTTPS (DoH, RFC 8484) und DNS over TLS (DoT, RFC 7858) senden Anfragen an externe Resolver. Ein Walled Garden, der diese Resolver blockiert, stoppt die Abfrage noch vor der Anmeldung.
• Ein Upstream-Ausfall. Wenn die WAN-Verbindung selbst ausfällt, schlagen alle Geräte und auch alle kabelgebundenen Ports fehl.

Wie finden Sie heraus, welche Ursache vorliegt?

Beginnen Sie mit dem Muster, nicht mit der Hardware. Nutzen Sie diese Matrix, um die Ursache einzugrenzen, bevor Sie Änderungen vornehmen.

Drei Prüfungen für Ihr Support-Team

1. IP-Adresse des Geräts prüfen. Eine 169.254.x.x-Adresse deutet auf DHCP hin, nicht auf DNS. Eine normale Adresse aus dem Gastbereich bedeutet, dass sich das Gerät ordnungsgemäß verbunden hat.
2. Abfragedauer von einem Testgerät messen. Führen Sie nslookup captive.apple.com von einem Laptop im Gastnetzwerk aus. Eine langsame oder fehlgeschlagene Antwort während einer Stoßzeit bestätigt einen DNS-Engpass.
3. Pakete im Gast-VLAN erfassen. Ein VLAN (Virtual LAN) trennt Gast-Traffic von Ihren anderen Netzwerken. Filtern Sie die Erfassung nach udp port 53 und suchen Sie nach Anfragen ohne passende Antwort.

Prüfen Sie anschließend, wann die Fehler auftreten. Vergleichen Sie unter WiFi Analytics das Verbindungs- und Anmeldevolumen mit den Zeiten, in denen Gäste Probleme melden. Ausfälle, die exakt mit Ihren Stoßzeiten korrelieren, weisen eindeutig auf Überlastung hin.

Wie behebt ein Enterprise-DNS-Filter den Engpass?

Ein Enterprise-DNS-Filter ist ein von Ihnen gesteuerter Resolver, der nah am Gastnetzwerk platziert ist. Er ersetzt den entfernten ISP- oder öffentlichen Resolver, den das DHCP aktuell zuweist. Er erledigt drei Aufgaben, die Zeitüberschreitungen beseitigen.

Er antwortet aus dem Cache. Hostnamen für Konnektivitätsprüfungen werden in gut besuchten Objekten tausende Male pro Stunde abgefragt. Ein nahegelegener Filter beantwortet wiederholte Abfragen aus seinem Cache, sodass sie die überlastete WAN-Verbindung gar nicht erst belasten.

Er verwirft unerwünschten Traffic frühzeitig. Anfragen für schädliche oder blockierte Kategorien werden direkt am Filter abgelehnt. Das gibt WAN-Kapazitäten für relevante Abfragen frei.

Es protokolliert jede Anfrage. Sie erhalten einen Nachweis darüber, welche Domains wann und wie oft fehlgeschlagen sind. Das verwandelt Vermutungen in handfeste Beweise, wenn das nächste Mal ein Manager ein Problem meldet.

Wo es platziert werden sollte

Für eine verteilte Infrastruktur, wie eine Einzelhandelskette mit hunderten kleiner Standorte, ist ein cloudbasierter Filter mit nahegelegenen Edge-Standorten in der Regel die praktische Wahl. Für einen einzelnen großen Standort, wie ein Stadion oder ein Konferenzzentrum, hält ein vor Ort gehosteter Resolver die Abfragen vollständig vom WAN fern. Weisen Sie in beiden Fällen zwei Resolver-Adressen über DHCP zu, damit ein einzelner Ausfall nicht das gesamte Netzwerk lahmlegt.

Zwei Einstellungen, die über den Erfolg entscheiden

Erstens: Erlauben Sie Ihre Captive Portal Domains im Filter. Ein Filter, der das Portal blockiert oder verzögert, erzeugt genau den Fehler neu, den Sie eigentlich beheben wollten. Zweitens: Halten Sie das Gäste-DNS vom Unternehmens-DNS getrennt. PCI-DSS betrachtet die Netzwerksegmentierung als Methode, um ein Gästenetzwerk aus dem Geltungsbereich Ihrer Karteninhaber-Datenumgebung herauszuhalten.

Wie beheben Sie das Problem auf den einzelnen Herstellern und Betriebssystemen?

Auf Ihren Access Points und Ihrem Controller

Purple ist hardwareunabhängig und läuft als Cloud-Overlay auf Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks und Fortinet. Die Behebung folgt bei jedem dieser Anbieter denselben drei Schritten:

1. Aktualisieren Sie die DNS-Server im Gäste-DHCP-Bereich auf Ihren Enterprise-DNS-Filter.
2. Vervollständigen Sie den Walled Garden. Cisco Meraki, HPE Aruba und Ruckus verwenden alle den Begriff "Walled Garden". Befolgen Sie den Purple-Einrichtungsartikel für Ihren Hersteller, in dem die genau zu erlaubenden Domains aufgeführt sind.
3. Überprüfen Sie das Traffic Shaping für Gäste, damit die Limits pro Client den UDP-Port 53 bei einer Auslastungsspitze nicht drosseln.

Kopieren Sie keine Einstellungen zwischen verschiedenen Herstellern. Menünamen und Standardwerte unterscheiden sich. Verwenden Sie daher die Dokumentation des jeweiligen Herstellers zusammen mit dem Purple-Einrichtungsartikel.

Auf dem Gerät des Gastes

Wenn nur ein einzelner Gast betroffen ist und bei allen anderen alles funktioniert, kann Ihr Support-Team folgende Schritte versuchen:

• Netzwerk ignorieren und erneut verbinden, um eine frische Konnektivitätsprüfung auszulösen.
• Eine einfache http://-Adresse im Browser öffnen, um das Erscheinen des Portals zu erzwingen.
• Auf Android das private DNS auf Automatisch stellen. Ein fester privater DNS-Anbieter kann die Abfrage vor der Anmeldung blockieren.
• Jegliche VPN-App pausieren, bis der Gast sich angemeldet hat.

Praxisszenarien

Die folgenden Zahlen dienen der Veranschaulichung und stammen nicht aus einer namentlich genannten Bereitstellung. Nutzen Sie sie als Modell dafür, was Sie an Ihrem eigenen Standort messen sollten.

Ein Hotel mit 200 Zimmern beim Frühstück

Situation. Beschwerden an der Rezeption über "kein Internet" häufen sich zwischen 7:00 und 9:00 Uhr, wenn Gäste vor dem Auschecken ihre E-Mails abrufen. Die Access Points zeigen ein gutes Signal und freie Sendezeit. Das Gäste-DHCP verteilt den Resolver des ISP über mehrere Hops hinweg über eine ausgelastete Leitung.

Was getan wurde. Der IT-Manager führte während der Spitzenzeit nslookup aus und stellte fest, dass Abfragen direkt fehlschlugen. Das Team stellte das Gäste-DHCP auf einen Cloud-DNS-Filter um, fügte die Portal-Domains zum Walled Garden hinzu und hielt das Gäste-DNS vom Netz des Hotelmanagementsystems getrennt.

Ergebnis. Gemessen in der WiFi Analytics und im Empfangsprotokoll stiegen die Portal-Abschlüsse in Spitzenzeiten von 81% auf 97%. WiFi-Beschwerden an der Rezeption sanken von etwa 15 pro Morgen auf zwei. Weitere Informationen zu Netzwerken für Hotels finden Sie auf unseren Branchenseiten für das Gastgewerbe.

Ein Stadion mit 30.000 Plätzen in der Halbzeitpause

Situation. Fans meldeten in jeder Halbzeitpause "verbunden ohne Internet", während die ersten zehn Minuten jeder Halbzeit reibungslos verliefen. Paketanalysen im Gäste-VLAN zeigten während des Ansturms DNS-Abfragen ohne Antwort.

Was getan wurde. Der Netzwerkarchitekt installierte einen lokalen Resolver mit Cloud-Fallback. Das Team entfernte ein Ratenlimit pro Client, das den UDP-Port 53 drosselte, und verschob den DHCP-Bereich auf den neuen Resolver.

Ergebnis. Unbeantwortete DNS-Abfragen in der Halbzeitpause fielen in den folgenden Analysen von 12% auf unter 1%. Die Anmeldungen der Fans während der Pause stiegen im Vergleich zum vorherigen Spiel um 40%.

Wie verhindern Sie, dass Fehler wie "verbunden kein Internet" erneut auftreten?

• Verlassen Sie sich niemals allein auf einen entfernten öffentlichen Resolver. Öffentliches DNS bietet generell eine gute Leistung, aber ein Resolver, der mehrere Hops entfernt ist, verursacht während eines Ansturms Verzögerungen, die Sie nicht kontrollieren können.
• Erstellen Sie Alarme für unbeantwortete DNS-Abfragen. Konfigurieren Sie Ihre Firewall oder Ihren Core-Switch so, dass steigende Verwerfungen auf UDP-Port 53 im Gästenetzwerk gemeldet werden. Dies deutet auf Timeouts hin, bevor Gäste es bemerken.
• Überprüfen Sie jeden Monat die Sperrlisten der DNS-Filter. Zu aggressive Kategorien beeinträchtigen legitime Apps und erzeugen neue Support-Tickets.
• Legen Sie eine Speicherfrist für Protokolle fest. DNS-Protokolle verknüpfen IP-Adressen mit den besuchten Domains. Behandeln Sie diese daher als personenbezogene Daten gemäß GDPR.
• Nutzen Sie RFC 8910, sofern Ihre Hardware dies unterstützt. Damit kann DHCP dem Gerät mitteilen, wo sich das Captive Portal befindet, sodass sich das Gerät weniger auf eine Verbindungsprüfungs-Abfrage verlassen muss.
• Erwägen Sie Passpoint für wiederkehrende Besucher. Passpoint (auch Hotspot 2.0 genannt) und OpenRoaming ermöglichen Geräten die sichere Verbindung ohne Captive Portal, wodurch dieser Fehler für diese Geräte vollständig entfällt.

Purple betreibt Guest WiFi an über 80.000 Standorten in mehr als 90 Ländern mit 500 Millionen Nutzern und Anmeldungen pro Jahr. Von Warteräumen im Gesundheitswesen bis hin zu Zügen bleibt das Muster gleich: Beheben Sie DNS-Probleme, bevor Sie neue Bandbreite kaufen.

Häufig gestellte Fragen

Benötigen wir neue Access Points, um den Fehler "verbunden kein Internet" zu beheben?

Nein, in den meisten Fällen ist das nicht erforderlich. Wenn der Fehler in Spitzenzeiten auftritt, ist die Ursache in der Regel die DNS-Auflösung und nicht die Access-Point-Hardware. Die Lösung ist eine Konfigurationsänderung: Richten Sie das Gäste-DHCP auf einen nahegelegenen Enterprise-DNS-Filter aus, vervollständigen Sie das Walled Garden und überprüfen Sie die Regeln zur Datenverkehrssteuerung. Ersetzen Sie Hardware erst, wenn Paketanalysen zeigen, dass die Access Points selbst den Datenverkehr bei normaler Auslastung verwerfen, und nachdem Sie DHCP und DNS als Ursache ausgeschlossen haben.

Funktioniert Purple mit der Hardware, die wir bereits besitzen?

Ja, Purple läuft auf Ihren bestehenden Access Points. Purple ist hardwareunabhängig und wird als Cloud-Overlay auf Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet bereitgestellt. Ein kompletter Austausch der Hardware ist nicht erforderlich. Purple veröffentlicht für jeden Anbieter einen Konfigurationsartikel, in dem die Walled-Garden-Domains aufgeführt sind, die Ihr Controller benötigt, damit das Captive Portal vor der Anmeldung der Gäste geladen wird.

Verlangsamt ein Enterprise-DNS-Filter unser Gäste-WiFi?

Nein, ein gut platzierter DNS-Filter beschleunigt Abfragen in der Regel. Er befindet sich näher am Gästenetzwerk als ein ISP oder ein öffentlicher Resolver und beantwortet wiederholte Abfragen aus seinem Cache. Das Risiko liegt in der Platzierung und Konfiguration, nicht in der Filterung selbst. Weisen Sie zur Redundanz zwei Resolver-Adressen zu und geben Sie Ihre Captive-Portal-Domains frei, damit der Filter die Anmeldeseite niemals verzögert.

Warum geben wir den Gästen nicht einfach einen öffentlichen Resolver wie 8.8.8.8?

Das können Sie tun, allerdings behebt dies keine Timeouts durch Netzwerküberlastung. Ein öffentlicher Resolver befindet sich weiterhin auf der anderen Seite Ihrer WAN-Verbindung, sodass jede Abfrage mit der Datenverkehrsspitze konkurriert, die den Fehler verursacht. Zudem bietet er weder Filterung noch Abfrage-Logs zur Fehlerbehebung. Ein lokaler Enterprise-Filter antwortet aus dem Cache, lehnt unerwünschte Kategorien ab und zeichnet jede fehlgeschlagene Abfrage auf - was öffentliches DNS nicht für Sie leisten kann.

Wie gehen wir mit DNS-Abfrage-Logs unter der GDPR um?

Behandeln Sie DNS-Logs als personenbezogene Daten, da sie IP-Adressen mit den von einem Gerät besuchten Domains verknüpfen. Legen Sie eine definierte Aufbewahrungsfrist fest, beschränken Sie den Zugriff auf Ihr Netzwerk- und Sicherheitsteam und halten Sie den Zweck in Ihrer Datenschutzerklärung fest. Purple ist nach ISO 27001 zertifiziert und GDPR-konform. Auch Ihr Anbieter von DNS-Filtern sollte eine entsprechende Zertifizierung nachweisen, bevor Sie Gäste-Traffic darüber leiten.

Wie viel Aufwand erfordert die Bereitstellung?

Die Anpassung selbst ist gering; das Testen nimmt den größten Teil des Aufwands in Anspruch. Sie aktualisieren die DNS-Server im DHCP-Bereich für Gäste, fügen Portal-Domains zur Allowlist des Filters hinzu und überprüfen den Walled Garden. Planen Sie die Tests während einer tatsächlichen Spitzenzeit ein, wie z. B. beim Frühstücksfeiertag oder in der Halbzeitpause, da ein ruhiger Nachmittag die Überlastung, die den Fehler verursacht hat, nicht reproduzieren kann.

Werdens Passpoint oder OpenRoaming den Fehler beheben?

Ja, für Geräte, die diese Technologien nutzen. Mit Passpoint und OpenRoaming können sich Geräte sicher verbinden, ohne dass ein Captive Portal erforderlich ist - somit gibt es kein Portal, das fehlschlagen könnte. Erstbesucher und Geräte ohne ein Passpoint-Profil nutzen weiterhin das Captive Portal, weshalb Sie nach wie vor ein schnelles DNS und einen vollständigen Walled Garden benötigen. Nutzen Sie beides parallel: Passpoint für wiederkehrende Besucher und ein optimiertes Portal für alle anderen.