Cisco Meraki Splashpage funktioniert nicht: Ein Ablaufdiagramm zur Fehlerbehebung

Cisco Meraki Splash-Pages werden nicht mehr angezeigt, wenn ein Client noch autorisiert ist, die HTTP-Anforderung, die die Weiterleitung auslöst, nicht senden kann, eine zulässige Splash-Abhängigkeit nicht erreichen kann oder die RADIUS-Authentifizierung nicht abschließen kann. Beginnen Sie mit einem betroffenen Client, filtern Sie die Authentifizierungs-, DHCP- und RADIUS-Protokolle nach dessen MAC-Adresse und testen Sie dann den entsprechenden Zweig unten. 1 [2] [3] [5]

Was muss funktionieren, damit eine Meraki Splash-Page angezeigt wird?

Betrachten Sie ein Captive Portal als eine kurze Kette, nicht als eine einzelne Webseite. Ein Gerät muss sich mit der richtigen SSID verbinden, eine gültige Adressierung erhalten, als nicht autorisiert eingestuft werden, Datenverkehr senden, der den Splash-Fluss initiieren kann, den erforderlichen gehosteten Dienst erreichen und anschließend die Autorisierung erhalten. Cisco Meraki beschreibt den Auslöser als einen HTTP-GET von einem nicht autorisierten Client. Der AP fängt diese Anforderung ab und gibt eine HTTP-307-Weiterleitung an die Splash-URL zurück. 1

Dies erklärt einen häufigen Support-Anruf: Ein Gast kann sich mit Ihrem Guest WiFi verbinden, berichtet jedoch, dass die Splash-Page nicht geladen wird. Der Access Point funktioniert möglicherweise wie vorgesehen. Wenn das Gerät zuerst ein reines HTTPS-Ziel öffnet, kann die verschlüsselte Anforderung nicht weitergeleitet werden. Cisco Meraki identifiziert dies ausdrücklich als Browser-Timeout-Szenario. Testen Sie den gesteuerten HTTP-Zweig, bevor Sie die SSID, das Seitendesign oder den RADIUS-Server ändern. [2]

Dieselbe Disziplin vermeidet einen zweiten häufigen Fehler: Jede wiederholte Aufforderung als Seitenfehler zu behandeln. Die Splash-Häufigkeit ist eine Autorisierungsrichtlinie. Cisco Meraki speichert den Splash-Status auf dem Gateway-Access-Point und dem Cloud-Controller, während der Browser ein Session-Cookie behält. Ein Client mit einer gültigen Autorisierungsdauer sieht die Seite nach einer Verkürzung der konfigurierten Häufigkeit möglicherweise nicht wieder. Umgekehrt kann ein Client mit deaktivierten oder gelöschten Cookies so erscheinen, als würde er zu oft aufgefordert. [2]

Was sollten Sie erfassen, bevor Sie etwas ändern?

Beginnen Sie mit einem reproduzierbaren Bericht. Erfassen Sie die MAC-Adresse des Clients, die SSID, den Gateway Access Point oder MX, den Gerätetyp, die lokale Uhrzeit, den Browser und ob das Gerät zuvor die Splash-Authentifizierung abgeschlossen hatte. Bitten Sie den Melder, das Gerät verbunden zu lassen, während Sie es überprüfen. Dies gibt Ihnen eine Eingrenzung des Vorfalls und verhindert, dass ein geschäftiges Hotel, ein Einzelhandelsgeschäft oder ein Veranstaltungsort eine allgemeine Beschwerde in blinde Konfigurationsänderungen verwandelt.

Öffnen Sie die Client-Details und prüfen Sie, ob dieser autorisiert ist. Cisco Meraki identifiziert einen nicht autorisierten Client als Splash: Not authorized; ein autorisierter Client zeigt seine verbleibende Autorisierungszeit an. Verwenden Sie keinen gespeicherten Browser-Tab für Ihren Test. Dies kann eine vergangene Sitzung mit dem aktuellen Funk- und DHCP-Status vermischen. 1

Filtern Sie dann das Dashboard-Ereignisprotokoll nach der MAC-Adresse des Clients und der Uhrzeit des Vorfalls. Für MR Access Points steht der Ereignistyp Auth für die Splash-Page-Authentifizierung. 802.11 zeigt die Assoziierung und Disassoziierung, DHCP enthält ereignisbezogene Lease-Daten und RADIUS identifiziert RADIUS- oder MAC-Authentication-Bypass-Aktivitäten. Derselbe Auth-Filter ist für die MX-Splash-Authentifizierung verfügbar. Cisco Meraki weist darauf hin, dass Geräte gespeicherte Ereignisse nach der Rückkehr ins Internet hochladen, während die ursprünglichen Zeitstempel beibehalten werden. Richten Sie daher die Zeitzone aus, bevor Sie entscheiden, was zuerst geschah. [5]

Verwenden Sie das folgende geordnete Protokoll. Es grenzt den Fehlerbereich ein, ohne dass geraten werden muss.

Wie führen Sie das Ablaufdiagramm zur Fehlerbehebung aus?

Verwenden Sie das Flussdiagramm einmal für einen sauberen Test-Client und einmal für einen bekanntermaßen betroffenen Client. Der Unterschied ist aufschlussreich. Wenn ein sauberer Client die Landingpage erreicht und das bekannte Gerät nicht, deutet dies auf Probleme mit der Autorisierung, dem Browser-Status oder einer client-spezifischen Richtlinie hin und nicht auf einen standortweiten Ausfall.

1. Verbindung und Adressierung bestätigen. Wenn das Ereignisprotokoll nicht anzeigt, dass sich der Client mit der gewünschten SSID verbindet, beheben Sie keine Fehler auf der Landingpage. Wenn er sich verbindet, aber die DHCP-Protokolle einen Fehler anzeigen, korrigieren Sie zuerst die Adressierung oder den VLAN-Pfad. Cisco Meraki identifiziert VLAN-Tagging an der SSID oder dem vorgeschalteten Switch-Port als häufige Ursache für DHCP-Fehler. [6]

2. Bestätigen, dass der Client nicht autorisiert ist. Ein zuvor autorisiertes Gerät benötigt möglicherweise noch keine erneute Landingpage. Cisco Meraki dokumentiert eine Funktion zum Widerrufen der Client-Autorisierung für kontrollierte erneute Tests. Verwenden Sie diese auf dem ausgewählten Gerät, anstatt die Häufigkeit der Landingpage für alle Standortbenutzer zu ändern. [2] [3]

3. Den Trigger mit HTTP testen. Löschen Sie den Browser-Cache nur dort, wo es zu Ihrem Testverfahren passt, stellen Sie sicher, dass Cookies aktiviert sind, und öffnen Sie dann ein HTTP-Ziel. Cisco Meraki weist darauf hin, dass eine HTTPS-Anfrage nicht umgeleitet werden kann, da der Datenverkehr verschlüsselt ist. Wenn der HTTP-Test funktioniert, dokumentieren Sie das Client-Verhalten als Ursache. Das Netzwerk hat seine Landingpage-Umleitung nicht verloren. 1 [2]

4. Erreichbarkeit der Seite und den Walled Garden testen. Ein Walled Garden erlaubt bestimmte IP-Adressen, Bereiche oder Hostnamen vor der Landingpage-Authentifizierung, einschließlich Wildcard-Domains. Wenn Sie eine benutzerdefinierte Landingpage-URL verwenden, muss laut Cisco Meraki die IP-Adresse und/oder URL der benutzerdefinierten Seite im Walled Garden enthalten sein. Wenn die Seite auf separate Asset-, Identitäts- oder Dienst-Endpunkte angewiesen ist, überprüfen Sie jedes erforderliche Ziel mit dem Dienstanbieter. Raten Sie keine IP-Adressen und fügen Sie keinen breiten Internetzugang als Abkürzung hinzu. [3]

Purple Seiten machen den Unterschied deutlich. Eine Offline-Landingpage wird vor dem Login angezeigt und kann keine externen Links oder Ressourcen enthalten, da sich der Besucher im Walled Garden befindet. Eine Online-Seite wird nach erfolgreichem Login angezeigt und kann externe Medien oder Links enthalten. Wenn eine Offline-HTML-Seite von Purple nach einer Änderung ein Bild, ein Stylesheet, ein Skript oder ein Drittanbieter-Identitätselement verloren hat, vergleichen Sie diese Abhängigkeiten mit den zulässigen Vor-Authentifizierungseinträgen, bevor Sie das Design ändern. [7] [8]

1. Sign-On RADIUS erst testen, nachdem die Seite geladen wurde. RADIUS, das hier für zentrale Authentifizierungsanfragen verwendete Protokoll, ist nicht der erste Verdächtige, wenn keine Landingpage angezeigt wird. Es wird relevant, wenn das Anmeldeformular geladen wird, aber die Authentifizierung fehlschlägt oder das Zeitlimit überschreitet. Bei diesem Cisco Meraki-Fluss initiiert die Dashboard-Cloud die RADIUS-Zugriffsanfrage, nicht der lokale AP oder MX. Der Server benötigt eine öffentliche Erreichbarkeit aus den dokumentierten Dashboard-Quellbereichen, ein passendes Shared Secret und Unterstützung für PAP. Cisco Meraki gibt an, dass RADSec für die Landingpage-Authentifizierung nicht unterstützt wird. [4]6. Führen Sie die unterstützte RADIUS-Prüfung durch und untersuchen Sie den Servereintrag. Cisco Meraki bietet einen Dashboard-RADIUS-Test für die dokumentierte Wireless-Konfiguration, obwohl die Testschaltfläche für MX- oder Z-Serien-Netzwerke nicht existiert. Ein Timeout bedeutet, dass Sie die aktuellen Dashboard-Firewall-Informationen, RADIUS-Client-Einträge, die Erreichbarkeit des öffentlichen Hosts, die Übereinstimmung des Shared Secret und das Richtlinienverhalten überprüfen sollten. Die Zustandsprüfung von Cisco Meraki sendet regelmäßige Zugriffsanfragen und stuft den Server nach sechs unbeantworteten Versuchen im Abstand von jeweils 20 Sekunden als nicht erreichbar ein. [4]

Wie isolieren Sie die häufigsten Fehlerquellen?

Die Splash-Häufigkeit scheint falsch zu sein

Wenn die Splash-Seite seltener erscheint, als es die Richtlinie vorsieht, prüfen Sie, ob der Client bereits autorisiert war, als sich die Häufigkeit geändert hat. Cisco Meraki gibt an, dass der bestehende Autorisierungszeitraum in Kraft bleibt. Der Entzug der Autorisierung des ausgewählten Clients ermöglicht einen validen Test der aktualisierten Einstellung. Wenn die Seite häufiger erscheint, überprüfen Sie die Cookie-Annahme des Browsers, das Löschen des Caches und die Kontinuität des Gateway-Access-Points. Ein Gateway-Neustart kann eine erneute Authentifizierung erfordern, es sei denn, der Browser kann sein Cookie präsentieren. [2]

Dies ist im Gastgewerbe von großer Bedeutung. Ein beispielhaftes Hotel mit 200 Zimmern sollte nach einer Änderung Tests mit einem kontrollierten Mobilgerät durchführen und das Ergebnis anhand von drei einfachen Kriterien messen: Der Client wechselt in den Zustand "Autorisiert", er erhält die erwartete Ablaufzeit und die nächste neue HTTP-Anfrage verhält sich wie beabsichtigt. Das ist ein besseres Freigabekriterium, als die Rezeption zu fragen, ob die Beschwerden aufgehört haben.

Das Gäste-WiFi leitet nicht weiter

Behaupten Sie nicht einfach, dass HTTPS Captive Portale "beschädigt" hat. Das dokumentierte Verhalten von Cisco Meraki ist spezifischer: Der Umleitungsmechanismus funktioniert bei einem nicht autorisierten HTTP-GET, während eine HTTPS-First-Anfrage nicht umgeleitet werden kann. Moderne Geräte starten bei der Zuordnung möglicherweise ihren Betriebssystem-Erkennungsfluss für Captive Portale. Wenn diese Aufforderung nicht erscheint, nutzen Sie den HTTP-Test, um festzustellen, ob das Netzwerksegment funktioniert. 1 [2]

Bei einem beispielhaften Rollout im Einzelhandel kann das IT-Team einer Filiale die Beschwerde mit einem Testgerät für Mitarbeiter auf der SSID der Verkaufsfläche reproduzieren. Der Nachweis für die erfolgreiche Behebung ist keine vage Aussage über das Laden der Seite. Erfassen Sie das Zuordnungsprotokoll, die gültige Adresse, den nicht autorisierten Zustand, das Auth-Ereignis nach dem HTTP-Test und den daraus resultierenden Autorisierungsstatus. Dieses Protokoll kann zwischen Filialen verglichen werden, ohne Besucherdaten offenzulegen.

Der Walled Garden ist unvollständig

Ein Walled Garden ist ein bewusst eingeschränkter Zugriff vor der Autorisierung. Er sollte nicht zu einer Bypass-Liste werden. Überprüfen Sie zuerst den Splash-Host und dann die Abhängigkeiten, die Ihre Pre-Authentifizierungsseite tatsächlich benötigt. Cisco Meraki erlaubt IP-Adressen, IP-Bereiche und Hostnamen mit Wildcard-Domains. Cisco erfordert außerdem eine benutzerdefinierte Splash-Seiten-URL oder IP-Adresse im Walled Garden, wenn diese Funktion aktiviert ist. [3]

Eine Purple-Offline-Seite ist die am stärksten eingeschränkte Phase. Purple weist darauf hin, dass keine externen Links oder Ressourcen verwendet werden können, während sich der Besucher im Walled Garden befindet. Der HTML-Editor ermöglicht es Ihrem Team, Assets in das Portal hochzuladen und eine Vorschau der aktuellen Seite anzuzeigen, was unnötige Remote-Abhängigkeiten reduzieren kann. Befolgen Sie die von Purple veröffentlichten Schritte, bevor Sie eine bearbeitete Vorlage veröffentlichen. [7] [8]

Timeout bei der Anmeldung oder Zurückweisung von Anmeldedaten

Trennen Sie eine Zurückweisung von einem Timeout. Eine Zurückweisung ist das Ergebnis einer Authentifizierung oder einer Richtlinie. Ein Timeout oder eine Meldung über "Verbindungsschwierigkeiten" deutet in erster Linie auf die Erreichbarkeit zwischen dem Dashboard und dem konfigurierten RADIUS-Server hin. Cisco Meraki dokumentiert, dass Anfragen für die Anmeldung über die Splash-Page in der Dashboard-Cloud initiiert werden und keine private LAN-Adresse für den RADIUS-Server verwenden können. [4]

Bestätigen Sie, dass der Server PAP für diesen Splash-Modus erwartet, die dokumentierten Quellbereiche des Dashboards zulässig sind, alle relevanten Quell-IPs als RADIUS-Clients konfiguriert sind und das Shared Secret auf beiden Seiten übereinstimmt. Cisco Meraki gibt außerdem an, dass die externe Splash-Integration die bereitgestellte login_url ohne Änderungen verwenden muss und das Filtern deren variierenden Hostnamen zulassen muss, anstatt eines festen Musters. [4]

Was bedeuten Meraki-Splash-Ereignisse im Ereignisprotokoll?

Lesen Sie das Protokoll wie eine Zeitachse. 802.11 association bedeutet, dass der Client eine Verbindung zu einem AP hergestellt hat. Dies bedeutet nicht, dass der Client eine Adresse hat, die Splash-Page erreicht hat oder Internetzugang erhalten hat. Ein Auth-Ereignis ist die Ereigniskategorie für die Authentifizierung auf der Splash-Page. Ein zeitnahes DHCP-Ereignis kann die Untersuchung auf die Adressierung verlagern. Ein RADIUS-Ereignis ist für einen RADIUS-gestützten Anmeldeflow wichtig, aber kein Beweis dafür, dass der Browser die Seite erreicht hat. [5] [6]

Vermeiden Sie es, 802.1X mit einer Anmelde-Splash-Page zu verwechseln. Cisco Meraki identifiziert 802.1X- und RADIUS-Meldungen für WPA2-Enterprise-SSIDs. Die separate RADIUS-Dokumentation für die Anmelde-Splash-Page beschreibt PAP zwischen der Dashboard-Cloud und Ihrem RADIUS-Server. Nutzen Sie in diesem Leitfaden die Kategorien Association, Auth, DHCP und RADIUS, um die fehlerhafte Phase zu lokalisieren. Schließen Sie nicht aus einer einzelnen Protokollzeile auf eine exakte Ursache. [4] [6]

Wie verhindert man, dass eine reparierte Splash-Page erneut ausfällt?

Führen Sie ein kurzes Betriebshandbuch für Ihren Guest WiFi Service-Owner. Das Betriebshandbuch sollte die Test-SSID, das Testgerät, das Verfahren zum Entzug der Autorisierung, den erwarteten Host der Seite, Abhängigkeiten vor der Authentifizierung, die RADIUS-Zuständigkeit und den Eskalationskontakt enthalten. Es sollte auch das Verhalten des Controllers bei einer Verbindungsunterbrechung beschreiben. Cisco Meraki dokumentiert offenes, eingeschränktes und standardmäßiges Verhalten, wenn der Cloud-Controller nicht verfügbar ist. [3]

Für Standorte, die ein Captive Portal für Einwilligungen, Branding und Zugriffsrichtlinien nutzen, sollten Sie die Offline-Seite als kontrollierte Anwendungskomponente behandeln. Purple bietet Seitentypen für den Offline-, Online- und Außer-Haus-Betrieb. Nutzen Sie den veröffentlichten Leitfaden zu Splash Pages für Änderungen am Zugriffspfad und die Anleitung zum HTML editor für hochgeladene Assets und die Vorschau. Trennen Sie die laufende Diagnose von der Erstkonfiguration. [7] [8]

Wenn dies zu einem wiederkehrenden Problem vor Ort wird, zentralisieren Sie die Beweise, anstatt Vermutungen anzustellen. Setzen Sie den Zeitpunkt des Vorfalls, die Client-MAC, den AP oder MX, die SSID, den Autorisierungsstatus, die Ereignisprotokollkategorien und die Antwort des RADIUS-Servers miteinander in Beziehung. Dieser Ansatz eignet sich für Standorte in den Bereichen Hospitality , Retail und Transport , in denen lokale Teams eine klare Grenze für Eskalationen benötigen und das Netzwerkteam reproduzierbare Beweise braucht. Weitere Informationen zur allgemeinen Servicegestaltung finden Sie unter Guest WiFi Management: Smart Authentication & Segmentation .

Häufig gestellte Fragen

Funktioniert Purple mit vorhandenen Cisco Meraki Access Points?

Ja. Purple unterstützt Guest WiFi-Implementierungen, die auf einer vorhandenen Infrastruktur, einschließlich Cisco Meraki, aufsetzen. Diese Anleitung befasst sich mit der Diagnose von Fehlern bei Meraki-Splash-Pages im laufenden Betrieb. Sie ersetzt nicht die Design- und Onboarding-Arbeiten, die für ein neues Captive Portal erforderlich sind. Nutzen Sie die veröffentlichte Dokumentation zu Purple-Splash-Pages für unterstützte Seitentypen und Änderungen beim Access-Ablauf. [7]

Wie viel Aufwand ist für die Migration einer Meraki-Splash-Page zu Purple erforderlich?

Der Aufwand hängt vom bestehenden Authentifizierungs-Flow, den Abhängigkeiten vor der Authentifizierung und dem Seitendesign ab. Beginnen Sie mit der Erfassung des aktuellen Seiten-Hosts, der Walled-Garden-Einträge, der Anmeldemethode und des Ziels nach dem Login. Purple unterstützt Standard- und HTML-Splash-Page-Vorlagen, einschließlich hochgeladener Assets und Live-Vorschau. Planen Sie die Migration als kontrollierten Change und nicht als Ad-hoc-Fehlerbehebung. [7] [8]

Kann eine Cisco Meraki-Splash-Page eine reine HTTPS-Anfrage weiterleiten?

Nein. Cisco Meraki dokumentiert, dass die Splash-Weiterleitung beginnt, wenn ein nicht autorisierter Client ein HTTP-GET sendet. Reiner HTTPS-Traffic ist verschlüsselt und kann durch diesen Mechanismus nicht weitergeleitet werden. Testen Sie mit einem HTTP-Ziel, um das Verhalten des Client-Browsers von einem netzwerkweiten Ausfall der Splash-Page zu unterscheiden. 1 [2]

Welche Walled-Garden-Einträge benötigt eine benutzerdefinierte Meraki-Splash-Page?

Der Walled Garden muss die IP-Adresse und/oder URL der benutzerdefinierten Splash-Page zulassen, wenn diese aktiviert ist. Erlauben Sie anschließend nur die zusätzlichen Endpunkte vor der Authentifizierung, die die Seite tatsächlich benötigt. Cisco Meraki unterstützt IP-Adressen, Adressbereiche und Hostnamen, einschließlich Wildcard-Domains. Ersetzen Sie diese Überprüfung nicht durch uneingeschränkten Internetzugang. [3]

Warum kommt es bei einer Meraki-Anmelde-Splash-Page mit RADIUS zu einem Timeout?

Ein Timeout bedeutet häufig, dass die Cisco Meraki Dashboard-Cloud keine Antwort vom konfigurierten RADIUS-Server erhalten kann. Überprüfen Sie die öffentliche Erreichbarkeit, die aktuellen Dashboard-Quellbereiche, die übereinstimmenden Shared Secrets der RADIUS-Clients und die PAP-Unterstützung. Der lokale AP oder MX ist nicht die Quelle von Splash-RADIUS-Anfragen. [4]

Wie überwachen wir Fehler bei der Splash-Anmeldung an mehreren Standorten?

Verwenden Sie das Meraki-Ereignisprotokoll, um den betroffenen Client und das Zeitfenster zu filtern, und korrelieren Sie dann die Kategorien Auth, DHCP und RADIUS. Die API für Splash-Anmeldeversuche von Cisco kann die Anmeldezeit, die SSID, das Gateway-Gerät, die Client-Kennung und den Autorisierungsstatus zurückgeben. Dies schafft eine konsistente Datenbasis für einen standortübergreifenden Support-Desk. [5] [9]

Referenzen

[2]: https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Troubleshooting_and_Support/Troubleshooting/Troubleshooting_Splash_Page_Appearance_Frequency "Cisco Meraki: Troubleshooting Splash Page Appearance Frequency"[3]: https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Design_and_Configure/Configuration_Guides/Splash_Page_Configuration/Splash_Page_Overview "Cisco Meraki: Splash-Page-Übersicht" [4]: https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Design_and_Configure/Configuration_Guides/Splash_Page_Configuration/Configuring_RADIUS_Authentication_with_a_Sign-on_Splash_Page "Cisco Meraki: Konfigurieren der RADIUS-Authentifizierung mit einer Sign-On-Splash-Page" [5]: https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Operate_and_Maintain/Monitoring_and_Reporting/Meraki_Event_Log "Cisco Meraki: So verwenden Sie das Meraki-Ereignisprotokoll" [6]: https://documentation.meraki.com/Wireless/Troubleshooting_and_Support/Troubleshooting/Common_Wireless_Event_Log_Messages_and_Issues "Cisco Meraki: Häufige Meldungen und Probleme im Wireless-Ereignisprotokoll" [7]: https://support.purple.ai/hc/en-gb/articles/7330834125085-Splash-Pages "Purple: Splash Pages" [8]: https://support.purple.ai/hc/en-gb/articles/7330855745949-Splash-Page-Editor-HTML "Purple: Splash-Page-Editor - HTML" [9]: https://developer.cisco.com/meraki/api-v1/get-network-splash-login-attempts/ "Cisco Meraki Dashboard API: Anmeldeversuche für Network Splash abrufen"