Podcast-Transkript ansehen
Willkommen bei den technischen Briefings von Purple. Ich bin Ihr Moderator, und heute befassen wir uns mit einem Thema, das bei fast jedem Enterprise-Gäste-WiFi-Projekt zur Sprache kommt: der Konfiguration eines Captive Portals auf Cisco Meraki MR Access Points und insbesondere der Integration mit der Cloud-Plattform von Purple mittels RADIUS-Authentifizierung. Ganz gleich, ob Sie als MSP einen neuen Kunden im Gastgewerbe anbinden oder als interner Netzwerkarchitekt bei einer Einzelhandelskette arbeiten - diese Episode vermittelt Ihnen die präzisen Konfigurationsschritte und die Hintergründe zu jedem einzelnen Schritt.
Lassen Sie uns das Szenario umreißen. Sie haben einen Standort - ein Hotel, ein Konferenzzentrum, ein Stadion oder ein Fachmarktzentrum -, an dem Cisco Meraki MR Access Points betrieben werden, die über das Meraki Dashboard verwaltet werden. Die Aufgabe besteht darin, ein gebrandetes Gäste-WiFi-Erlebnis bereitzustellen, das First-Party-Daten erfasst, die Zustimmung zu den Nutzungsbedingungen einfordert und Analysedaten in eine Marketing-Plattform einspeist. Genau dafür ist Purple entwickelt worden, und Meraki ist weltweit eine unserer am häufigsten genutzten Hardware-Implementierungen.
Der wichtigste architektonische Punkt, den Sie verstehen müssen, bevor Sie eine einzige Einstellung ändern, ist folgender: Bei Cisco Meraki wird die RADIUS-Authentifizierung für eine Splash Page nicht lokal vom Access Point verarbeitet. Der RADIUS-Access-Request stammt aus der Meraki-Cloud - also aus der Dashboard-Infrastruktur - und nicht vom AP in Ihrem LAN. Dies ist ein entscheidender Unterschied, der vielen Technikern bei ihrer ersten Meraki-Bereitstellung entgeht. Das bedeutet, dass Ihr RADIUS-Server, in diesem Fall der Cloud-RADIUS-Endpunkt von Purple, über das Internet erreichbar sein muss und Ihre Firewall-Regeln den Datenverkehr aus den IP-Bereichen des Meraki Dashboards zulassen müssen, nicht nur aus Ihrem lokalen AP-Subnetz. Die aktuellen Dashboard-IP-Bereiche finden Sie in Ihrem Meraki Dashboard unter "Help" und dann "Firewall Info".
Kommen wir nun zur Konfiguration. Ich werde Sie in der Reihenfolge durch die Schritte führen, in der Sie sie auch bei einer Live-Bereitstellung durchführen würden.
Schritt eins: SSID-Konfiguration. Navigieren Sie im Meraki Dashboard zu "Wireless", dann "Configure" und schließlich "SSIDs". Wählen Sie den SSID-Steckplatz aus, den Sie für den Gästezugang nutzen möchten. Geben Sie ihm einen eindeutigen Namen - etwa "GuestWiFi" oder "Standortname_Guest". Stellen Sie unter "Association requirements" die Sicherheit auf "Open, no encryption". Das ist korrekt und so gewollt - die Sicherheitsebene für Gäste wird durch das Captive Portal und die RADIUS-Authentifizierung geregelt, nicht durch eine WPA-Verschlüsselung. Wenn Sie in einer PCI-DSS-Umgebung arbeiten, sollten Sie sicherstellen, dass der Gästedatenverkehr in einem eigenen VLAN isoliert ist, worauf wir gleich noch eingehen werden.
Schritt zwei: Splash-Page und Authentifizierung. Scrollen Sie auf der Seite „Access Control“ für Ihre SSID nach unten zum Bereich „Splash page“. Stellen Sie diesen auf „Sign-on with“ ein und wählen Sie aus dem Dropdown-Menü „my RADIUS server“ aus. Dies ist die entscheidende Einstellung, die Meraki anweist, Benutzer vor dem Gewähren des Netzwerkzugriffs an einem externen RADIUS-Server zu authentifizieren. Darunter sehen Sie die Option „Captive portal strength“. Stellen Sie diese auf „Block all access until sign-on is complete“ ein. Dadurch wird der Walled Garden erzwungen - ohne diese Einstellung könnten Gäste das Portal komplett umgehen.
Schritt drei: RADIUS-Server-Konfiguration. Klicken Sie im Bereich „RADIUS“ auf „Add server“. Sie benötigen drei Informationen aus Ihrem Purple-Konto: die RADIUS-Server-IP-Adresse oder den FQDN, den Authentifizierungs-Port (UDP 1812) und das Shared Secret. Purple stellt diese im Bereich für die Standortkonfiguration des Portals bereit. Für Ausfallsicherheit in produktiven Umgebungen sollten Sie einen sekundären RADIUS-Server hinzufügen - Purple stellt dafür einen Failover-Endpunkt bereit. Stellen Sie den Accounting-Port auf UDP 1813 ein, wenn Sie möchten, dass Sitzungsdaten in die Analyse-Engine von Purple zurückfließen, was ich für jeden Standort, an dem Verweildauer und Sitzungsdauer wichtige Kennzahlen sind, dringend empfehlen würde.
Ein kurzer Hinweis zu RADIUS-Attributen. Meraki berücksichtigt das in der RADIUS-Access-Accept-Antwort zurückgegebene „Session-Timeout“-Attribut. Purple nutzt dies, um zu steuern, wie lange eine Gästesitzung dauert, bevor eine erneute Authentifizierung erforderlich ist. Für ein Hotel könnten Sie dies auf 86.400 Sekunden festlegen - das entspricht 24 Stunden. Für ein Café ist ein Wert wie 3.600 Sekunden (eine Stunde) angemessener. Das „Idle-Timeout“-Attribut wird ebenfalls berücksichtigt, jedoch nur, wenn das RADIUS-Accounting aktiviert ist. Dies trennt inaktive Sitzungen, was für das Kapazitätsmanagement in Umgebungen mit hoher Dichte wichtig ist.
Schritt vier: Splash-Page-URL. Navigieren Sie zu „Wireless“, dann „Configure“ und schließlich „Splash page“. Wählen Sie Ihre Gäste-SSID aus dem Dropdown-Menü aus. Setzen Sie die „Custom splash URL“ auf die Purple-Portal-URL für Ihren Standort. Dies ist die URL, an die Meraki nicht authentifizierte Clients weiterleitet. Meraki hängt Abfrageparameter an diese URL an - einschließlich eines „login_url“-Parameters -, die Purple verwendet, um den Authentifizierungs-Handshake abzuschließen. Modifizieren oder entfernen Sie diese Parameter nicht.
Schritt fünf: Der Walled Garden. Hier treten bei den meisten Bereitstellungen Probleme auf. Der Walled Garden ist die Liste von Domänen und IP-Bereichen, die ein Gästegerät erreichen kann, bevor es authentifiziert ist. Ohne die korrekten Einträge wird die Captive Portal-Seite selbst nicht geladen, da der Browser daran gehindert wird, das Purple CDN und die Social-Login-Anbieter zu erreichen.
Navigieren Sie zurück zu Access Control für Ihre Gäste-SSID. Stellen Sie Walled Garden auf Walled garden is enabled ein. Im Feld Walled garden ranges müssen Sie Folgendes hinzufügen. Erstens die Domains der Purple Plattform: star dot purple dot ai und star dot venuewifi dot com. Zweitens die CDN-Domains, die Purple zur Bereitstellung von Portal-Assets verwendet: star dot cloudfront dot net und star dot akamaihd dot net. Drittens die Meraki-Weiterleitungsinfrastruktur: star dot network-auth dot com. Viertens, wenn Sie Social-Login-Optionen anbieten, benötigen Sie die entsprechenden OAuth-Domains. Für Google: accounts dot google dot com, star dot googleapis dot com, star dot gstatic dot com. Für Facebook: star dot facebook dot com, star dot fbcdn dot net und connect dot facebook dot net. Für Twitter oder X: star dot twitter dot com und star dot twimg dot com.
Ein wichtiger Hinweis dazu, wie Meraki mit Wildcard-Domains im Walled Garden umgeht. Meraki unterstützt Wildcard-Einträge mit dem Sternchen-Präfix, zum Beispiel star dot cloudfront dot net. Dies ist jedoch ein DNS-basierter Abgleich - Meraki löst die Domain auf und lässt die resultierenden IP-Adressen zu. Dies bedeutet, dass Sie für CDN-Anbieter wie CloudFront oder Akamai, bei denen sich die aufgelösten IPs häufig ändern können, die Domain-Wildcard anstelle von statischen IP-Bereichen verwenden sollten. Statische IP-Einträge sind für die RADIUS-Endpunkte von Purple, die stabil sind, völlig in Ordnung, nicht jedoch für den CDN-Traffic.
Lassen Sie uns nun über zwei Praxisszenarien sprechen, an denen ich direkt gearbeitet habe.
Das erste ist ein Hotel mit 350 Zimmern in Großbritannien. Der Kunde betrieb Meraki MR46 Access Points in drei Gebäuden mit etwa 400 gleichzeitigen Gästegeräten zu Spitzenzeiten. Die ursprüngliche Bereitstellung nutzte eine Click-Through-Begrüßungsseite - kein RADIUS, nur die Akzeptanz der Nutzungsbedingungen. Das Problem war, dass sie keinerlei Einblick darin hatten, wer sich verband, keine E-Mail-Erfassung stattfand und es keine Möglichkeit gab, Marketingkampagnen nach dem Aufenthalt durchzuführen. Wir haben sie auf Purple mit RADIUS-basierter Anmeldung migriert. Die Konfiguration war unkompliziert, aber der Haken war, dass ihre vorgeschaltete Firewall ausgehendes UDP auf Port 1812 zu allem außerhalb des lokalen Subnetzes blockierte. Sobald wir die IP-Bereiche des Meraki Dashboards zur Allow-List der Firewall hinzugefügt hatten, funktionierte die Authentifizierung sofort. Nach der Bereitstellung erfasste das Hotel im ersten Monat E-Mail-Adressen von etwa 68 Prozent der sich verbindenden Gäste, und das Marketingteam führte eine Reaktivierungskampagne durch, die zu einer messbaren Steigerung der Direktbuchungen führte.
Das zweite Szenario ist eine Einzelhandelskette mit 45 Filialen, in denen jeweils Meraki MR33 Access Points betrieben werden. Die Herausforderung hierbei waren Skalierbarkeit und Konsistenz. Die manuelle Konfiguration von 45 SSIDs mit den korrekten RADIUS-Einstellungen und Walled-Garden-Listen wäre fehleranfällig und zeitaufwendig gewesen. Die Lösung bestand darin, die vorlagenbasierte Konfiguration von Meraki zu nutzen. Wir haben eine einzige Netzwerkvorlage mit den korrekten SSID-, RADIUS- und Walled-Garden-Einstellungen erstellt und dann alle 45 Filialnetzwerke mit dieser Vorlage verknüpft. Jede Änderung - wie beispielsweise das Hinzufügen eines neuen Social-Login-Anbieters zum Walled Garden - wird einmal in der Vorlage vorgenommen und automatisch auf alle Filialen übertragen. Die Analysen von Purple aggregierten dann die Besucherzahlen und Verweildaten über alle Filialen hinweg und boten dem Retail-Operations-Team ein einziges Dashboard mit einer Übersicht des Gästeverhaltens nach Filiale, Region und Tageszeit.
Hier sind drei Faustregeln, die Ihnen bei jeder Bereitstellung eines Meraki Captive Portals Zeit sparen werden.
Regel eins: Überprüfen Sie immer die IP-Bereiche des Meraki Dashboards, bevor Sie RADIUS konfigurieren. Die Bereiche ändern sich gelegentlich. Wenn Ihre Firewall sie blockiert, schlägt die Authentifizierung aus Sicht des Benutzers geräuschlos fehl - die Portalseite bleibt einfach hängen. Nutzen Sie das integrierte RADIUS-Testtool im Dashboard unter „Access Control“, um die Konnektivität vor dem Live-Gang zu überprüfen.
Regel zwei: Verwenden Sie Domain-Wildcards im Walled Garden und keine IP-Bereiche für alle über CDNs gehosteten Inhalte. Die IP-Bereiche von CDNs sind groß und ändern sich häufig. Ein Wildcard-Domain-Eintrag ist wartungsfreundlicher und zuverlässiger.
Regel drei: Aktivieren Sie das RADIUS-Accounting auf Port 1813, selbst wenn Sie glauben, dass Sie es noch nicht benötigen. Sitzungsdaten sind wertvoll für die Behebung von Verbindungsproblemen und für die Bereitstellung präziser Verweildaten in Ihrer Analyseplattform. Die Aktivierung kostet nichts und ist im Nachhinein nur sehr schwer nachzurüsten.
Nun noch ein paar schnelle Fragen, die mir regelmäßig gestellt werden.
Kann ich die integrierte Splash-Page von Meraki anstelle von Purple nutzen? Ja, aber Sie verlieren die Datenerfassung, die Analysen, die Marketing-Automatisierung und das GDPR-konforme Einwilligungsmanagement. Die integrierte Splash-Page ist für ein einfaches Click-Through in Ordnung, aber sie ist keine Guest-Intelligence-Plattform.
Funktioniert diese Konfiguration sowohl auf Meraki MX-Firewalls als auch auf MR-Access-Points? Die RADIUS-Splash-Page-Konfiguration wird auf MR-Access-Points unterstützt. MX-Appliances handhaben die Client-VPN-Authentifizierung anders. Speziell für das Gäste-WiFi konfigurieren Sie die MR-SSIDs.
Wie sieht es mit WPA3 aus? Meraki MR-Access-Points unterstützen WPA3 auf Enterprise-SSIDs. Bei Bereitstellungen von Captive Portals für Gäste ist die SSID in der Regel Open, sodass WPA3 nicht direkt anwendbar ist. Wenn Sie jedoch eine Passpoint- oder OpenRoaming-SSID parallel zu Ihrer Captive-Portal-SSID bereitstellen - was von Purple unterstützt wird -, verwendet diese SSID WPA3-Enterprise mit 802.1X, und genau dort wird WPA3 relevant.
Zusammenfassend lässt sich sagen: Die Integration von Cisco Meraki und Purple ist bewährt und zuverlässig, erfordert jedoch Aufmerksamkeit in drei Bereichen: RADIUS-Quell-IP-Routing, Vollständigkeit des Walled Garden und Konfiguration des Session-Timeouts. Wenn Sie diese drei Punkte richtig umsetzen, verläuft die Bereitstellung reibungslos. Der Business Case ist klar - Standorte, die eine ordnungsgemäß konfigurierte Gäste-WiFi-Plattform mit Datenerfassung einsetzen, verzeichnen durchweg messbare Erfolge beim Marketing-Engagement und bei den operativen Erkenntnissen.
Wenn Sie tiefer einsteigen möchten, lesen Sie den Leitfaden von Purple zur Implementierung der 802.1X-Authentifizierung mit Cloud-RADIUS sowie unseren Leitfaden zur Bereitstellung von Cisco Wireless APs auf dem Purple-Blog. Beide sind in den Shownotes verlinkt.
Vielen Dank fürs Zuhören. Wenn Sie ein bestimmtes Bereitstellungsszenario haben, das wir behandeln sollen, wenden Sie sich an das technische Team von Purple. Wir sehen uns in der nächsten Folge.
