Fehlerbehebung bei öffentlichem WiFi: Behebung von "Verbunden, kein Internet" und Fehlern bei der Weiterleitung zur Splash Page

Willkommen zu diesem technischen Briefing von Purple. Heute befassen wir uns mit einem der hartnäckigsten und am häufigsten missverstandenen Probleme in drahtlosen Netzwerken für Unternehmen: das Captive Portal für Gäste-WiFi, das einfach nicht geladen werden will. Sie kennen das. Ein Gast kommt in Ihr Hotel, Ihr Ladengeschäft, Ihr Stadion oder Ihr Konferenzzentrum. Er verbindet sich mit dem WiFi-Netzwerk. Nichts passiert. Keine Anmeldeseite. Kein Internet. Nur ein sich drehendes Symbol und wachsende Frustration. Für Betriebsleiter und IT-Manager ist dieser Moment nicht nur eine kleine Unannehmlichkeit. Er stellt ein direktes Versagen Ihres Gästeerlebnisses, einen Anstieg der Support-Anrufe an der Rezeption und eine verpasste Gelegenheit zur Erfassung von First-Party-Daten dar, die Ihre Investitionen in die Wireless-Infrastruktur rechtfertigen. In diesem Briefing blicken wir hinter die Kulissen. Wir erklären genau, wie die Erkennung von Captive Portals auf Betriebssystemebene funktioniert, identifizieren die sechs Hauptursachen, die für die überwiegende Mehrheit der Verbindungsfehler verantwortlich sind, und an die Hand geben Ihnen ein praktisches, direkt umsetzbares Framework zur Fehlerbehebung, das Sie noch heute an Ihr IT-Team weitergeben können. Beginnen wir mit der Funktionsweise. Die meisten Menschen betrachten ein Captive Portal einfach als eine Anmeldeseite. In Wahrheit handelt es sich um einen Mechanismus zum Abfangen von Datenverkehr auf Netzwerkesebene, und dieser Unterschied ist von enormer Bedeutung, wenn Probleme auftreten. Der Ablauf ist wie folgt: Das Gerät eines Gasts verbindet sich mit Ihrer Gäste-SSID und erhält eine IP-Adresse über DHCP. Zu diesem Zeitpunkt wartet das Betriebssystem nicht darauf, dass der Benutzer einen Browser öffnet. Im Hintergrund sendet ein Systemdienst sofort eine unverschlüsselte HTTP-GET-Anfrage an eine vom Hersteller kontrollierte Probe-URL. Apple-Geräte fragen captive.apple.com ab. Android-Geräte fragen connectivitycheck.gstatic.com ab. Windows-Geräte fragen msftconnecttest.com ab. Firefox hat einen eigenen Test unter detectportal.firefox.com. Wenn das Netzwerk über einen freien Internetzugang verfügt, liefern diese Tests die erwarteten Antworten und das Betriebssystem zieht den Schluss, dass alles in Ordnung ist. In einem Gästenetzwerk fängt Ihr Wireless-Gateway oder -Controller diese HTTP-Probe jedoch ab, bevor sie das Internet erreicht. Anstelle der erwarteten Antwort gibt das Gateway eine HTTP 307-Weiterleitung zurück, die auf die Splash-Page Ihres Captive Portals verweist. Das Betriebssystem erkennt die unerwartete Weiterleitung, stellt fest, dass es sich hinter einem Captive Portal befindet, und öffnet ein Sandbox-Browserfenster - oft als Captive Network Assistant bezeichnet - um die Anmeldeseite anzuzeigen. Das ist der Idealfall. Kommen wir nun zu den sechs Gründen, warum dieser Prozess scheitern kann. Hauptursache Nummer eins: Erschöpfung des DHCP-Pools. Dies ist der stille Killer bei Veranstaltungen mit hoher Dichte. Wenn Sie eine Konferenz mit zweitausend Teilnehmern in einem Standard-Slash-24-Subnetz durchführen, stehen Ihnen 254 nutzbare IP-Adressen zur Verfügung. Wenn Ihre DHCP-Lease-Zeit auf den Standardwert von 24 Stunden eingestellt ist, ist dieser Pool innerhalb von Minuten nach Türöffnung erschöpft. Jeder nachfolgende Verbindungsversuch schlägt fehl, noch bevor die Captive Portal - Sequenz überhaupt beginnt. Die Lösung ist einfach: Stellen Sie die DHCP-Lease-Zeiten für Gäste in Umgebungen mit hoher Fluktuation auf 15 bis 30 Minuten ein und dimensionieren Sie Ihre Subnetze angemessen für die maximale Anzahl gleichzeitiger Benutzer, nicht nur für die Gesamtzahl der Teilnehmer. Hauptursache Nummer zwei: DNS-Abfangfehler. Die Captive Portal - Weiterleitung hängt davon ab, dass das Gateway den HTTP-Probe abfängt. Der Probe erfordert jedoch zuerst eine DNS-Abfrage. Wenn Ihre DNS-Konfiguration es nicht authentifizierten Clients nicht erlaubt, externe Domainnamen aufzulösen, wird der Probe nie ausgelöst. Stellen Sie sicher, dass Ihre Firewall-Richtlinie DNS-Abfragen von nicht authentifizierten Clients explizit zulässt, und überprüfen Sie, ob Ihr DNS-Abfangen funktioniert, indem Sie eine Paketerfassung an einem Testgerät durchführen. Hauptursache Nummer drei: Unvollständiger Walled Garden. Der Walled Garden - auch bekannt als Pre-Authentication Access Control List - definiert, welche externen Domains nicht authentifizierte Gäste erreichen können. Wenn Ihre Portal-Startseite Assets von einem CDN lädt, das sich nicht im Walled Garden befindet, wird die Seite als leerer Bildschirm gerendert. Wenn Sie Social Login über Google, Apple oder Facebook anbieten, muss jede OAuth-Domain, die diese Anbieter verwenden, auf die Whitelist gesetzt werden. Und hier ist der entscheidende Punkt: Social-Identity-Anbieter aktualisieren ihre CDN-IP-Bereiche und Authentifizierungsdomains regelmäßig. Ein Walled Garden, der vor sechs Monaten noch perfekt funktionierte, kann heute stillschweigend fehlerhaft sein. Planen Sie vierteljährliche Walled Garden - Audits und nutzen Sie Wildcard-Domain-Snooping, sofern Ihre Hardware dies unterstützt. Auf Cisco Meraki, HPE Aruba, Ruckus und Juniper Mist ist dies nativ verfügbar. Hauptursache Nummer vier: HSTS blockiert die Weiterleitung. HTTP Strict Transport Security, oder HSTS, ist eine Sicherheitsrichtlinie für Browser, die Verbindungen zu bestimmten Domains ausschließlich über HTTPS erzwingt. Wenn das Gerät eines Gastes versucht, eine vorab in HSTS geladene Domain zu kontaktieren - und das umfasst praktisch jede größere Website - und Ihr Gateway versucht, diese HTTPS-Anfrage abzufangen, um zum Portal weiterzuleiten, erkennt der Browser eine Zertifikatsabweichung. Er zeigt eine nicht umgehbare Sicherheitswarnung an und blockiert die Weiterleitung vollständig. Die richtige Lösung besteht darin, niemals zu versuchen, HTTPS abzufangen. Ihr Gateway sollte nur die unverschlüsselten HTTP-Canary-Probes weiterleiten. Die langfristige, auf Standards basierende Lösung ist RFC 8910, der die DHCP-Option 114 definiert. Diese Option ermöglicht es Ihrem DHCP-Server, die Captive Portal - URL direkt an das Client-Gerät zu übermitteln, wodurch die Notwendigkeit einer HTTP-Weiterleitung vollständig entfällt. iOS 14 und Android 11 und höher unterstützen dies nativ. Ursache Nummer fünf: Ein aktives VPN auf dem Endgerät des Gastes. Ein VPN verschlüsselt den gesamten Datenverkehr des Geräts und leitet ihn über einen externen Tunnel um, bevor er Ihr Gateway erreicht. Ihr Gateway sieht die HTTP-Anfrage gar nicht. Die Erkennungssequenz für das Captive Portal wird nie ausgelöst. Der Gast sieht keine Anmeldeseite und hat kein Internet. Die Lösung für den Gast ist einfach: VPN deaktivieren, mit dem Portal verbinden, dann das VPN wieder aktivieren. Für Ihr Servicepersonal sollte dies die erste Frage sein, wenn ein Gast ein Verbindungsproblem meldet. Ursache Nummer sechs: Die Randomisierung von MAC-Adressen unterbricht die Sitzungspersistenz. Moderne iOS- und Android-Geräte verwenden standardmäßig randomisierte MAC-Adressen als Datenschutzfunktion. Jedes Mal, wenn sich ein Gerät mit einem Netzwerk verbindet, präsentiert es möglicherweise eine andere MAC-Adresse. Da der Sitzungsstatus des Captive Portals anhand der MAC-Adresse verfolgt wird, kann einem Gast, der sich vor einer Stunde authentifiziert hat, nach der Rotation der MAC-Adresse seines Geräts erneut die Anmeldeseite angezeigt werden. Die Lösung auf Gästeseite besteht darin, die private Adresse für Ihre spezifische SSID in den Netzwerkeinstellungen zu deaktivieren. Die betreiberseitige Lösung ist die Implementierung einer profilbasierten Authentifizierung - wie OpenRoaming über Passpoint und 802.1X - die auf Layer 2 unter Verwendung von Anmeldedaten anstelle von MAC-Adressen authentifiziert, wodurch die Randomisierung irrelevant wird. Lassen Sie uns nun über die Implementierung sprechen. Wie sieht eine gut konfigurierte Captive Portal-Bereitstellung in der Praxis tatsächlich aus? Beginnen Sie mit Ihrer DHCP-Architektur. Für jeden Veranstaltungsort, der mehr als 200 gleichzeitige Geräte erwartet, sollten Sie von einem einzelnen Slash-24-Subnetz absehen. Verwenden Sie ein Slash-22 oder größer und legen Sie die Lease-Zeiten so fest, dass sie dem Verweildauerprofil Ihres Standorts entsprechen. Ein Hotel setzt Leases auf 8 Stunden. Ein Stadion setzt Leases auf 3 Stunden. Ein Einkaufszentrum setzt Leases auf 90 Minuten. Ein Konferenzzentrum setzt Leases auf 30 Minuten. Überprüfen Sie als Nächstes Ihren Walled Garden vor jeder größeren Veranstaltung. Die erforderlichen Mindesteinträge sind: der vollqualifizierte Domänenname Ihres Portals und alle zugehörigen CDN-Domänen, die Captive Portal-Erkennungs-URLs für Apple, Google, Windows und Firefox sowie die OAuth-Domänen für jeden von Ihnen unterstützten Social-Login-Anbieter. Auf der Plattform von Purple pflegen und aktualisieren wir diese Walled-Garden-Einträge automatisch als Teil unseres Cloud-Managed-Service, was Ihrem Team den manuellen Wartungsaufwand abnimmt. Verwenden Sie für Ihr Portal-Zertifikat ein öffentlich vertrauenswürdiges TLS-Zertifikat einer anerkannten Zertifizierungsstelle. Selbstsignierte Zertifikate führen auf jedem Gerät zu Browserwarnungen. Erneuern Sie Zertifikate vor dem Ablauf - ein abgelaufenes Zertifikat ist eine der häufigsten Ursachen für plötzliche, standortweite Ausfälle des Portals. Eine Falle, in die viele IT-Teams tappen: das Testen des Portals mit einem Gerät, das zuvor bereits authentifiziert wurde. Die Sitzung Ihres Geräts ist noch aktiv, sodass Sie das Portal vollständig umgehen und den Schluss ziehen, dass alles funktioniert. Testen Sie immer mit einem Gerät in einem frischen, nicht authentifizierten Zustand - entweder mit einem neuen Gerät oder mit einem, bei dem Sie das Netzwerk ignoriert und das WiFi-Profil gelöscht haben. Lassen Sie mich Ihnen zwei praxisnahe Szenarien nennen, die diese Prinzipien veranschaulichen. Szenario eins: Ein Hotel mit 350 Zimmern im Londoner Stadtzentrum. Die Unterkunft betrieb ein einziges /24-Subnetz für das Gäste WiFi. Während einer großen Konferenz trafen 400 Delegierte gleichzeitig ein. Innerhalb von 20 Minuten war der DHCP-Pool erschöpft. Gäste meldeten, dass sie zwar verbunden waren, aber das Captive Portal oder das Internet nicht erreichen konnten. Die sofortige Lösung bestand darin, das Subnetz auf /22 zu erweitern, was 1.022 nutzbare Adressen bereitstellte, und die Lease-Zeit von 24 Stunden auf 8 Stunden zu verkürzen. Die langfristige Lösung war die Implementierung des cloudbasierten Captive Portal von Purple, das die Auslastung des DHCP-Pools in Echtzeit überwacht und das Netzwerkteam warnt, bevor eine Erschöpfung eintritt. Die Ausfallrate des Portals sank innerhalb von 48 Stunden nach der Änderung auf fast Null. Szenario zwei: Eine große Einzelhandelskette mit 200 Filialen. Die Kette nutzte Social Login über Google und Facebook auf ihrem Gästeportal. Nachdem Google seine OAuth-Infrastruktur aktualisiert hatte, befanden sich die neuen Authentifizierungsdomänen nicht im Walled Garden. Gäste konnten die Portalseite erreichen, aber die Social-Login-Buttons zeigten nur leere Bildschirme an. Das IT-Team der Kette verbrachte zwei Tage mit der Diagnose des Problems, bevor es die Lücke im Walled Garden identifizierte. Nach der Identifizierung dauerte die Behebung 10 Minuten. Die Lektion: Codieren Sie niemals IP-Adressen in Ihrem Walled Garden für cloudbasierte OAuth-Anbieter fest ein. Verwenden Sie Wildcard-Domain-Einträge und überprüfen Sie diese vierteljährlich. Nun zu einigen schnellen Fragen, die wir regelmäßig von IT-Teams in Veranstaltungsorten hören. Warum funktioniert das Portal auf iPhones, aber nicht auf Android-Geräten? Android verwendet connectivitycheck.gstatic.com als Probe-URL. Wenn diese Domain von Ihrer Firewall blockiert wird oder sich nicht in Ihrem Walled Garden befindet, lösen Android-Geräte das Portal niemals aus. Fügen Sie sie explizit hinzu. Ein Gast sagt, das Portal wurde geladen, aber er kann nach dem Login nicht online gehen. Dies ist fast immer ein RADIUS-Autorisierungsfehler. Überprüfen Sie, ob Ihr RADIUS-Server vom Wireless-Controller aus erreichbar ist, verifizieren Sie, dass das Shared Secret auf beiden Seiten übereinstimmt, und überprüfen Sie die RADIUS-Protokolle auf Access-Reject-Meldungen. Wie gehen wir mit Gästen um, die nach wenigen Minuten immer wieder abgemeldet werden? Überprüfen Sie Ihre Idle-Timeout-Einstellung. Viele Controller sind standardmäßig auf ein Idle-Timeout von 5 Minuten eingestellt, was für Mobilgeräte, die zwischen Interaktionen in den Ruhezustand wechseln, viel zu aggressiv ist. Stellen Sie das Idle-Timeout für Hotellerie- und Einzelhandelsumgebungen auf mindestens 30 Minuten ein. Zusammenfassend die wichtigsten Punkte des heutigen Briefings: Ausfälle von Gäste WiFi Captive Portals fallen in sechs Kategorien: DHCP-Pool-Erschöpfung, DNS-Interception-Fehler, unvollständiger Walled Garden, Blockierung durch HSTS-Weiterleitung, aktives VPN auf dem Client-Gerät und MAC-Adress-Randomisierung. Jedes Problem hat eine spezifische, testbare Lösung. Die sofortigen Maßnahmen für Ihr IT-Team sind: Überprüfen Sie Ihre DHCP-Lease-Zeiten und Subnetz-Größen, validieren Sie Ihren Walled Garden mit den aktuellen OAuth-Domains Ihrer Social-Login-Anbieter und testen Sie Ihr Portal nach jeder Konfigurationsänderung von einem neuen, nicht authentifizierten Gerät aus.Bewerten Sie für Ihre längerfristige Roadmap OpenRoaming als Nachfolger der Captive Portal-Reauthentifizierung für wiederkehrende Besucher. Die Technologie ist ausgereift, die Standards sind unter IEEE 802.1X und WPA3-Enterprise etabliert, und Purple stellt sie ohne zusätzliche Softwarekosten im Connect-Tarif zur Verfügung. Purple ist an über 80.000 Standorten im Einsatz und hat allein im Jahr 2024 bereits 440 Millionen Logins verarbeitet. Wir haben jedes in diesem Briefing beschriebene Fehlerszenario erlebt - und die Tools entwickelt, um sie zu verhindern. Wenn Sie erfahren möchten, wie sich das Cloud-Overlay von Purple in Ihre bestehende Infrastruktur von Cisco Meraki, HPE Aruba, Ruckus oder Juniper Mist integrieren lässt, besuchen Sie purple.ai oder sprechen Sie mit Ihrem Account Manager. Vielen Dank für Ihre Aufmerksamkeit.