Ein Gast kommt in einem Hotel an, wählt das WiFi des Hauses aus, wartet auf ein Captive Portal, akzeptiert die Bedingungen, gibt eine E-Mail-Adresse ein - und wiederholt den gesamten Vorgang im Konferenzzentrum nebenan. In einem Krankenhaus wechseln das verwaltete iPad und das VoWiFi-Mobilteil einer Pflegekraft mit unterschiedlichen Profilen zwischen verschiedenen Access Points. In einem Stadion konkurrieren Tausende von Geräten um Sendezeit, während die Anmeldeseite zu einer weiteren Fehlerquelle wird.
Die Einrichtung von Passpoint WiFi beseitigt diese Reibungspunkte, indem Zugriffsentscheidungen in die Identitätsebene verlagert werden. Kompatible Geräte erkennen das Netzwerk, werten die angebotenen Anmeldedaten und Roaming-Informationen aus und authentifizieren sich dann über Enterprise WiFi-Sicherheitsstandards, anstatt sich auf ein gemeinsam genutztes Passwort oder eine Landingpage zu verlassen. Das Ergebnis ist ein automatisches Onboarding und Roaming über mehrere Standorte hinweg, die demselben Identitätsanbieter vertrauen.
Dieses Ergebnis wird nicht einfach durch das Aktivieren eines Hotspot 2.0-Kontrollkästchens erreicht. Es hängt von der AP-Firmware, den 802.11u- und ANQP-Ankündigungen, EAP-Methoden, Zertifikaten, NAI-Realms, der RADIUS-Kapazität, der Gerätekompatibilität und dem Fallback-Design ab. Der praxisnahe Ansatz besteht darin, die Infrastruktur zu überprüfen, ein kontrolliertes Pilotprojekt durchzuführen, Fehlerquellen zu erfassen und den Rollout erst dann auszuweiten, wenn die Daten dies rechtfertigen.
Warum die Passpoint WiFi Einrichtung für Unternehmensnetzwerke wichtig ist
Hotels, Krankenhäuser und Stadien offenbaren schnell die Schwachstellen herkömmlicher Gast-WiFi-Lösungen. Ein Hotel muss unter Umständen Hunderte von verschiedenen Geräten bei wiederholten Besuchen unterstützen, während ein Krankenhaus gemeinsam genutzte klinische Geräte, Mobilgeräte des Personals und Besucher mit unterschiedlichen Identitätsanbietern vereint. Ein Stadion wiederum verzeichnet eine dichte, unvorhersehbare Nachfrage und toleriert kaum Anmeldevorgänge, die fehlschlagen, wenn sich Benutzer durch die Eingänge bewegen oder den Sitzbereich wechseln.
Captive Portals sind nützlich, wenn ein Betreiber eine Einwilligung oder Marketingdaten benötigt, aber sie bedeuten auch eine zusätzliche betriebliche Belastung. Pro Standort eingerichtete SSIDs zwingen Benutzer zur manuellen Netzwerkauswahl, gemeinsam genutzte Passwörter verbreiten sich über den vorgesehenen Empfängerkreis hinaus, und Portal-Weiterleitungen können aufgrund von Browserverhalten, Zertifikatswarnungen oder schlechten Funkbedingungen fehlschlagen. Die erneute Authentifizierung erweist sich als besonders störend, wenn ein Benutzer von einem Controller oder Gebäude zum nächsten wechselt.
Was eine funktionierende Bereitstellung ersetzt
Passpoint nutzt die 802.11u-Erkennung, ANQP-Netzwerkinformationen und eine EAP-basierte Authentifizierung, damit ein Gerät vor der Zuordnung feststellen kann, ob es über ein gültiges Profil verfügt. Mit den richtigen Anmeldedaten kann sich das Gerät ohne erneute Passworteingabe verbinden. WPA2 oder WPA3 Enterprise bietet dann das Sicherheitsmodell, das für den identitätsbasierten Zugriff erwartet wird.
Die betrieblichen Vorteile sind eher praktischer als kosmetischer Natur:
- Weniger Zugangsdaten-Verwaltung: Das Personal muss nicht jedes Mal ein gemeinsames Gäste-Passwort zurücksetzen, wenn es öffentlich bekannt wird.
- Weniger Portal-Abhängigkeiten: Ein unterstütztes Gerät muss keine Splash Page laden, bevor es Netzwerkzugriff erhält.
- Bessere Kontinuität an mehreren Standorten: Ein Profil kann vertrauenswürdige Netzwerke erkennen, die derselben Domain oder Roaming-Beziehung zugeordnet sind.
- Präzisere Zugriffskontrolle: RADIUS-Richtlinien können Benutzer, Geräte und Identitätsanbieter unterscheiden, anstatt jeden Client als anonymes Mitglied einer einzigen SSID zu behandeln.
Großbritannien verfügt bereits über ein relevantes Benchmark-Projekt im öffentlichen Sektor. Der offizielle GovWifi-Dienst bietet einen einzigen Benutzernamen und ein einziges Passwort für Mitarbeiter und Besucher im gesamten öffentlichen Sektor. Laut der Government Property Agency werden damit mehr als 850.000 Menschen in ganz Großbritannien bedient. GovWifi verbindet Benutzer zudem automatisch in Tausenden von Gebäuden, die diesen Service anbieten. Es handelt sich zwar nicht um dieselbe Implementierung wie bei Passpoint, aber es zeigt, dass zentralisierte Authentifizierung und standortübergreifender Zugriff bewährte Betriebspraktiken und keine bloßen Laborideen sind.
Betrachten Sie das Projekt als Identity Engineering
Die erste Designentscheidung ist, ob Passpoint für verwaltete Mitarbeitergeräte, den öffentlichen Gastzugang, das Mobilfunk-Offloading oder eine Föderation wie OpenRoaming dienen soll. Jeder Anwendungsfall ändert die Anmeldeinformationsquelle, die EAP-Methode, das Richtlinienmodell und das Fallback-Verhalten.
Der Bericht der Wireless Broadband Alliance, über den Comms Business berichtete, ergab, dass 81 % der Befragten OpenRoaming Implementierungen planten. Die Motive dafür waren unter anderem WiFi- und Mobilfunkzugang, verbesserte Sicherheit, reibungsloser Zugriff und Kontinuität über Netzwerke hinweg. Diese Zahlen ersparen jedoch nicht die technische Arbeit. Sie zeigen, warum Betreiber darin investieren, während die Implementierung immer noch von der genauen Identitäts- und Vertrauenskonfiguration abhängt.
Das Passpoint-Framework verstehen
Passpoint ist ein System auf der Identitätsebene, kein einfaches Häkchen auf dem Wireless-Controller. Die Fehlerbehebung wird erheblich beschleunigt, wenn jede Ebene eine klar definierte Aufgabe hat. Der Access Point sendet genügend Informationen, damit ein Gerät entscheiden kann, ob das Netzwerk mit einem installierten Profil übereinstimmt. Das Gerät wählt die passenden Zugangsdaten aus und startet die Enterprise-Authentifizierung. RADIUS trifft die Autorisierungsentscheidung, während Zertifikate und Realms bestimmen, ob Client und Server einander vertrauen.
Auf der Funk- und Erkennungsebene ermöglicht IEEE 802.11u die Netzwerkerkennung vor der normalen Assoziierung. Der Access Point nutzt GAS zur Übertragung von ANQP-Abfragen und -Antworten. ANQP kann den Zugriffstyp des Netzwerks, Domainnamen, NAI-Realms, Roaming-Identifikatoren, Standortinformationen, mobilfunkbezogene Daten und WAN-Metriken bereitstellen. Der Client vergleicht diese Werte mit den bereits auf dem Gerät installierten Profilen.
Der praktische Weg ist:
- Beacon- und 802.11u-Signalisierung: Der AP signalisiert, dass Hotspot 2.0-Informationen verfügbar sind.
- GAS- und ANQP-Austausch: Der Client fragt ab, welche Identitäten, Realms, Roaming-Partner und Dienste das Netzwerk unterstützt.
- Profilabgleich: Das Gerät vergleicht die angekündigten Werte mit seinem Passpoint-Profil.
- EAP-Authentifizierung: Das Gerät authentifiziert sich über 802.1X, in der Regel unter Verwendung von EAP-TLS, EAP-TTLS, EAP-SIM oder EAP-AKA, je nach Bereitstellung.
- RADIUS-Autorisierung: Der AP oder Controller leitet die Anfrage weiter und wendet die zurückgegebene Richtlinie an.
- Verschlüsselte Zuordnung: Der Client verbindet sich über WPA2-Enterprise oder WPA3-Enterprise, ohne auf ein Captive Portal angewiesen zu sein.
Die WiFi Alliance deployment guidance nennt die HS2.0-Indikation im AP-Beacon als Grundvoraussetzung. Wenn ein Client diese Indikation nicht erkennen kann, startet er die Passpoint-Erkennung nicht, unabhängig davon, wie sorgfältig RADIUS konfiguriert wurde.
EAP-TLS verwendet Client-Zertifikate und eignet sich im Allgemeinen für verwaltete Geräteflotten, da das Unternehmen die Geräte-Anmeldedaten ausstellen, rotieren und widerrufen kann. EAP-TTLS unterstützt Workflows mit Benutzernamen und Passwörtern, jedoch erfordern die innere Identität und das Serverzertifikat weiterhin sorgfältigen Schutz. SIM-basierte EAP-Methoden eignen sich für Mobilfunkbetreiber- oder Föderations-Bereitstellungen, bei denen das Mobilfunkabonnement die Anmeldedaten bereitstellt.
Der NAI-Bereich identifiziert die für eine Anfrage verantwortliche Identitätsdomäne. RCOIs identifizieren Roaming-Konsortien und helfen Clients bei der Entscheidung, ob ein Netzwerk zu einer vertrauenswürdigen Servicebeziehung gehört. Ein OSU-Server kann Anmeldedaten für unterstützte Registrierungsabläufe bereitstellen, während ein Richtlinienserver den Standort mit einem Verbund verbinden und Partnerregeln anwenden kann.
Die Releases von Passpoint gehen über die reine Erkennung hinaus. Hotspot 2.0 Release 2 und Release 3 unterstützen die Online-Registrierung und die Bereitstellung von Richtlinien, aber jede hinzugefügte Funktion schafft einen weiteren Konfigurationspunkt. Ein fehlerhafter OSU URI, eine unvollständige Zertifikatskette oder ein Realm, der sich nur um ein einziges Zeichen unterscheidet, kann die Zuordnung verhindern. Die Einstellungen für das Captive Portal können zudem mit einem Identitäts-Flow kollidieren, der einen verschlüsselten Enterprise-Zugriff erwartet.
Engineering-Regel: Zeichnen Sie den Pfad vom Beacon zu ANQP, Profil, EAP, RADIUS und der Richtlinienentscheidung auf, bevor Sie die Produktions-SSID konfigurieren. Wenn eine Übergabe unklar ist, führen Sie den Pilotbetrieb zuerst dort durch.
Pre-Flight-Checks, bevor Sie den Controller anfassen
Ein Passpoint Pilotprojekt kann scheitern, noch bevor jemand den Controller öffnet. Beginnen Sie mit der Abhängigkeitskette: AP-Firmware, Controller-Release, Identitätsdienste, Zertifikate, Client-Profile und Betriebskapazität. Bestätigen Sie, dass das genaue AP-Modell und der Software-Zweig Hotspot 2.0, ANQP, den ausgewählten WPA-Modus und jedes erforderliche Passpoint Feld unterstützen. Die Kompatibilität der Produktfamilie reicht nicht aus.
Erstellen Sie ein kurzes schriftliches Konzept, anstatt Einstellungen einfach zwischen Standorten zu kopieren. Bestätigen Sie, dass die AAA-Plattform die gewählten EAP-Methoden, Passpoint-Attribute, Accounting- und Richtlinienantworten unterstützt. Testen Sie die Erreichbarkeit von jedem AP oder Controller, der am Pilotprojekt teilnimmt. Dimensionieren Sie RADIUS für Spitzen bei Authentifizierung und Accounting, nicht nur für den durchschnittlichen Datenverkehr. Ein falsch konfigurierter Realm führt auch auf einer überdimensionierten Plattform zu Fehlern, während ein unterdimensionierter Dienst eine ansonsten korrekte Konfiguration verschleiern kann.
Der Zertifikatsplan erfordert die gleiche Sorgfalt. Erfassen Sie die ausstellende CA, Vertrauensanker, den Verantwortlichen für die Erneuerung und den Sperrpfad. Stellen Sie sicher, dass das Serverzertifikat von jedem Testgerät akzeptiert wird. Wenn das Unternehmen die Gerätezertifikate kontrolliert und einen passwortlosen Zugang wünscht, ist EAP-TLS in der Regel die richtige Wahl. EAP-TTLS eignet sich für einen kontrollierten Benutzername- und Passwort-Prozess. EAP-SIM oder EAP-AKA gehören in betreiber- oder SIM-gestützte Föderationskonzepte und sind kein Ersatz für eine Zertifikatsstrategie im Unternehmen.
Verwenden Sie einen bekannten, funktionierenden Client-Pool, der den Standort repräsentiert, einschließlich Betriebssystemen, Geräteherstellern und verwalteten Profilen. Fügen Sie nicht verwaltete oder nicht unterstützte Geräte hinzu, um zu prüfen, was Benutzern angezeigt wird, wenn die automatische Authentifizierung nicht verfügbar ist. Das Verhalten des Captive Portal gehört in diesen Test, da eine Portal-Richtlinie einen Identitäts-Flow stören kann, der für die Nutzung von verschlüsseltem Enterprise-Zugriff vorgesehen ist.
Sichern Sie die Identitätswerte vor der Konfiguration. Schreiben Sie den NAI-Bereich exakt so auf, wie es der Identitätsanbieter erwartet, einschließlich Groß- und Kleinschreibung, Satzzeichen und Suffixen. Erfassen Sie die OSU-Server-Entscheidung, die Verbundbeziehung, die RCOI-Anforderungen, den Zertifikatsinhaber und die Fallback-SSID in einer einzigen Checkliste. Diese Werte sollten nicht nur in den Notizen eines Ingenieurs existieren.
Planen Sie die Funkumgebung basierend auf dem tatsächlichen Veranstaltungsort und validieren Sie die Anzahl der APs sowie das Design mit einem access point calculator. Die Kapazitätsplanung deckt ein überlastetes Design vor der Inbetriebnahme auf, kann jedoch einen falschen Realm oder ein ungültiges Zertifikat nicht korrigieren.
Deaktivieren Sie WEP und TKIP. Belassen Sie das Passpoint-Design auf WPA2-Enterprise oder WPA3-Enterprise und schließen Sie veraltete Sicherheitsmodi aus.
Herstellerspezifische Einrichtung für Meraki, Aruba, Ruckus, Mist und UniFi
Die Standards sind dieselben, die administrative Benutzererfahrung ist es jedoch nicht. Hersteller stellen dieselben Primitiven in unterschiedlichen Profilen dar, und einige Plattformen verstecken die Validierung hinter generischen WLAN-Einstellungen. Betrachten Sie die folgende Konfiguration als Orientierungshilfe und prüfen Sie jedes Feld anhand der genauen Dokumentation der verwendeten Version.
| Hersteller | Native Passpoint Unterstützung | Speicherort für Zertifikats-Upload | OSU / Onboarding | Häufige Stolperfalle |
|---|---|---|---|---|
| Meraki | Hotspot 2.0 Einstellungen auf der SSID | Netzwerkweiter Zertifikatsbereich | OSU-Anbieterfelder im SSID-Profil | Ein Profil kann vollständig erscheinen, während Realm- oder Zugangsnetzwerk-Werte inkonsistent bleiben |
| Aruba | Hotspot 2.0 Profil an eine 802.1X SSID angehängt | Controller- oder Mobility-Zertifikatsspeicher | Profil- und AAA-Integration | Vom AAA abgeleitete Realm-Werte müssen überprüft und dürfen nicht einfach angenommen werden |
| Ruckus | Passpoint Einstellungen im WLAN | SmartZone Zertifikatskonfiguration | Veranstaltungsort- und OSU-Felder in den WLAN-Einstellungen | Ältere AP-Firmware kann ANQP-Elemente stillschweigend weglassen |
| Juniper Mist | Passpoint über WLAN-Vorlagen | Identitäts- und Zertifikatskonfiguration der Organisation | Identitätsanbieter und Vorlagen-Workflow | Eine fehlerhafte OSU-URI kann ANQP-Anomalien verursachen |
| UniFi | Eingeschränkte native Objektunterstützung | Externer RADIUS und plattformspezifische Zertifikatsbehandlung | Meist extern oder improvisiert | Benutzerdefinierte Workarounds sind als produktive Föderation nur schwer zu verwalten |
Wo sich Implementierungen unterscheiden
Meraki ist für ein Cloud-verwaltetes Deployment vergleichsweise unkompliziert. Aktivieren Sie Hotspot 2.0 auf der SSID, stellen Sie den Netzwerkzugriffstyp, die Domain, den Realm und die EAP-Methode ein und tragen Sie dann bei Bedarf die Informationen des OSU-Anbieters ein. Laden Sie das Zertifikat über den Netzwerk-Zertifikats-Workflow hoch und überprüfen Sie das resultierende ANQP-Advertisement, anstatt sich auf die Dashboard-Zusammenfassung zu verlassen. Unternehmen, die sich auf Meraki standardisieren, sollten auch die Cisco Meraki Access Point-Produktreihe mit den geplanten Firmware- und Client-Profilanforderungen abgleichen.
Aruba beginnt normalerweise mit einem 802.1X WLAN, einem Hotspot 2.0-Profil und einer importierten CA-Kette. Die wichtigste Überprüfung ist die Beziehung zwischen dem vom AAA-Server abgeleiteten Bereich und dem über das Profil angekündigten Bereich. Mobility Conductors und verteilte Controller stellen eine weitere Fehlerquelle bei der Vererbung von Konfigurationen dar.
Ruckus SmartZone erfordert eine genaue Abstimmung zwischen WLAN- und AP-Firmware. Fügen Sie das Passpoint-Profil, das signierte Zertifikat und die Details zum Veranstaltungsort hinzu und erfassen Sie dann die ANQP-Antworten eines aktuellen APs. Ein Dashboard, das aktivierte Einstellungen anzeigt, beweist nicht, dass ein älterer AP auch dieselben Elemente überträgt.
Juniper Mist verlagert die Arbeit in WLAN-Vorlagen und die Identitätskonfiguration auf Organisationsebene. Das System läuft reibungslos, wenn der Identitätsanbieter und die OSU-Werte gültig sind, aber fehlerhafte Registrierungs-URIs äußern sich meist als Erkennungsanomalien und nicht als eindeutiger Konfigurationsfehler.
UniFi ist der schwierige Fall. Ohne ein vollständiges natives Passpoint-Objekt greifen Teams oft auf externen RADIUS, benutzerdefinierte Hostnamen und unvollständige Richtlinien-Workarounds zurück. Dies mag für Experimente akzeptabel sein, schafft jedoch zu viele Zuständigkeitsgrenzen für ein reguliertes Krankenhaus, eine große Hotelgruppe oder einen Roaming-Verbund.
Hersteller-Realität: Ein grüner Konfigurationsstatus bedeutet nur, dass das Objekt vom Controller akzeptiert wurde. Es beweist nicht, dass ein Client dieses erkennen, ihm vertrauen, sich authentifizieren und darüber roamen kann.
Konfiguration von Zertifikaten, RADIUS und der Identitätsschicht
Ein Passpoint Rollout kann zwar erfolgreich zugeordnet werden, aber auf der Identitätsebene fehlschlagen. Beginnen Sie mit der Serveridentität, die von den Client-Geräten validiert wird. Erstellen Sie einen CSR mit den erforderlichen Subject Alternative Names für die Service-Domain und den Identitäts-Namensraum. Verwenden Sie eine öffentliche Zertifizierungsstelle (CA), der die Geräte bereits vertrauen, oder verteilen Sie eine private Vertrauenskette über Tools für verwaltete Geräte.
Importieren Sie das Zertifikat und die Zwischenkette in der vom Controller geforderten Reihenfolge. Eine fehlende Zwischenkette wird dem Benutzer häufig als falsches Passwort angezeigt. Testen Sie nach jeder Zertifikatsänderung von einem echten Client-Gerät aus, überprüfen Sie die angezeigte Kette und korrelieren Sie das Ergebnis mit den Authentifizierungsprotokollen des Controllers. Eine Überprüfung im Laborbrowser reicht nicht aus.
Den RADIUS-Pfad aufbauen
RADIUS ist der Richtlinien-Entscheidungspunkt für die Passpoint-Identität, nicht nur ein Passwort-Prüfer. FreeRADIUS, Cisco ISE, ClearPass und Microsoft NPS unterscheiden sich in der EAP-Unterstützung und der Richtliniensyntax. Protokollieren Sie die gewählte Methode, die Zertifikatsprüfungen, die Realm-Verarbeitung und das Attribut-Mapping vor der Implementierung.
- EAP-TLS: Ordnen Sie das Client-Zertifikatssubjekt oder die SAN dem Geräte- oder Datensatz zu, erzwingen Sie das Vertrauen des Ausstellers und definieren Sie die Behandlung von Sperrungen.
- EAP-TTLS: Schützen Sie den äußeren Austausch mit dem Serverzertifikat und ordnen Sie dann die innere Identität dem richtigen Bereich und der richtigen Richtlinie zu.
- SIM-gestütztes EAP: Bestätigen Sie, dass der Mobilfunkanbieter oder die Föderation die Teilnehmer-Validierung bereitstellt und dass die RADIUS-Ebene diese verarbeiten kann.
- Realm-Richtlinie: Stellen Sie sicher, dass ein Wert wie
@corp.example.comden vorgesehenen Identitätsanbieter ohne Abweichungen bei der Groß-/Kleinschreibung oder Formatierung erreicht.
Die RADIUS-Kapazität erfordert eine gesonderte Überprüfung. Zertifikatsauthentifizierung und Accounting erzeugen andere Abfragemuster als herkömmliches 802.1X. Spitzenzeiten beim Onboarding und beim erneuten Verbinden können Latenz-, Warteschlangen- und Timeout-Probleme offenlegen, insbesondere in einem Hotel, Krankenhaus oder Stadion. Verwenden Sie redundante Server, messen Sie die Antwortlatenz und testen Sie das Ausfallverhalten, anstatt davon auszugehen, dass das bestehende Mitarbeiter-WLAN-Segment über freie Kapazitäten verfügt.
Ein verwaltetes RADIUS-as-a-Service Modell kann den betrieblichen Aufwand reduzieren. Überprüfen Sie jedoch vor der Auswahl die Unterstützung für die erforderlichen EAP-Methoden, Richtlinienkontrollen, Protokollierung und den Zertifikatslebenszyklus.
Föderationsdetails gezielt hinzufügen
OpenRoaming erfordert, dass der Standort, die Identität des Dienstanbieters und die Föderationskennungen über das Profil, das Richtliniensystem und die Roaming-Beziehung hinweg übereinstimmen. Die Richtlinien für Passpoint Bereitstellung und Implementierung decken NAI-Realms, Zertifikatsbereitstellung und RCOI-Registrierung als Aufgaben auf der Identitätsebene ab. Zu den gängigen Roaming-Kennungen gehören das abrechnungsfreie RCOI 5A-03-BA und das ältere Cisco RCOI 00-40-96, falls eine breitere Kompatibilität erforderlich ist.
Laden Sie nach dem Hochladen des Profils die relevanten Controller-Komponenten neu und überprüfen Sie die Live-Beacon- und ANQP-Antworten. Bestätigen Sie, dass der angekündigte Realm, die Standortinformationen (Venue Information), RCOI und OSU NAI korrekt sind. Suchen Sie auch nach einem Captive Portal, das an denselben Dienstpfad gebunden ist, da es die Registrierung abfangen oder mit einem Profil kollidieren kann, das eine direkte Authentifizierung erwartet.
Die Konfigurationsdatei ist nur die Eingabe. Das über die Luft übertragene Paket ist die endgültige Überprüfung.
Pilotbetrieb, Validierung und Schwellenwerte für den Live-Gang
Führen Sie das Pilotprojekt als Messübung durch. Wählen Sie eine Etage, eine Abteilung oder eine Halle aus, halten Sie einen alten 802.1X-Pfad bereit und nutzen Sie eine feste Gruppe von Geräten, deren Besitzer und Betriebssystemversionen bekannt sind. Berücksichtigen Sie sowohl durch Zertifikate verwaltete Clients als auch die Besuchergeräte, bei denen am ehesten Profil- und Fallback-Probleme auftreten.
Definieren Sie vor dem Aktivieren der SSID die Abnahmekriterien schriftlich:
- Erkennung: Jeder Test-AP muss die HS2.0-Ankündigung und die erforderlichen ANQP-Elemente übertragen.
- Assoziierung: Zwischengespeicherte Anmeldedaten sollten sich während des kontrollierten Tests in weniger als drei Sekunden verbinden.
- Authentifizierung: Die RADIUS-Ebene sollte bei der erwarteten Spitzennachfrage keine Timeouts aufweisen.
- Fallback: Geräte ohne kompatibles Profil sollten eine dokumentierte Alternative erhalten, anstatt in einer Endlosschleife durch ein fehlerhaftes Portal geführt zu werden.
- Roaming: Testen Sie den Wechsel von AP zu AP in regelmäßigen Abständen und wiederholen Sie dies über Controller hinweg mit konfiguriertem Mobility-Domain-Bereich.
Erfassen Sie Nachweise an drei Punkten. Verwenden Sie einen AP im Monitor-Modus oder eine entsprechende Paketerfassung, um den Beacon-, GAS- und ANQP-Datenverkehr zu überprüfen. Exportieren Sie RADIUS-Protokolle mit Anforderungs-IDs und Antwortattributen. Sammeln Sie Betriebssystemprotokolle von jedem Testgerät, insbesondere dort, wo ein Smartphone-Hersteller erfolgreich ist und ein anderer dasselbe Profil ablehnt.
Die Leitlinien der WiFi Alliance unterstützen die Überprüfung von AP- und Controller-Funktionen, RADIUS-Bereitschaft und EAP-Kompatibilität vor der Bereitstellung. Ein praxisnahes Experten-Playbook empfiehlt einen Pilotbetrieb auf 10 % bis 20 % der APs mit einer Verbindungsfolgsquote von über 98 % und einer Authentifizierungslatenz von unter 300 Millisekunden als Go-or-No-Go-Indikatoren. Diese Schwellenwerte sollten an der eigenen Risikotoleranz des Unternehmens gemessen werden, bieten jedoch eine konkrete Disziplin für die Skalierung.
Erweitern Sie das Projekt nicht nur, weil der erste Morgen erfolgreich war. Lassen Sie das Pilotprojekt auch in normalen Spitzenzeiten laufen, überprüfen Sie Roaming- und Fehlerprotokolle und übertragen Sie die dokumentierten Fehlerbehebungen auf den nächsten Standort.
Fehlerbehebung und Probleme auf der letzten Meile
Die schwierigsten Fehler treten auf, wenn die Konfiguration scheinbar abgeschlossen ist. Passpoint hängt davon ab, dass Client, AP, Profil, Vertrauenskette und RADIUS-Richtlinie im selben Moment übereinstimmen. Ein Captive Portal kann einen fehlgeschlagenen Passpoint-Austausch nicht reparieren, da Passpoint-fähige SSIDs keine Portal-Weiterleitungen als Authentifizierungsmechanismus unterstützen.
| Fehlermodus | Symptom | Diagnosesignal | Behebung |
|---|---|---|---|
| Realm-Abweichung | Der Client ignoriert das Netzwerk oder weicht auf eine andere SSID aus | Vergleichen Sie den angekündigten NAI-Realm in ANQP mit dem Realm in der RADIUS-Anfrage | Normalisieren Sie Realm-Strings und Profilwerte, einschließlich Groß-/Kleinschreibung und Suffixen |
| Fehlerhafte Zertifikatskette | EAP-TLS schlägt trotz eines gültigen Client-Zertifikats fehl | RADIUS EAP-Protokolle zeigen Vertrauens- oder Kettenvalidierungsfehler | Bauen Sie die bereitgestellte Kette neu auf, bestätigen Sie Zwischenzertifikate und testen Sie sie über das Client-Betriebssystem |
| Fehlende ANQP-Elemente | Geräte erkennen die SSID nicht als geeignetes Passpoint-Netzwerk | Paketerfassung zeigt fehlenden HS2.0-Hinweis oder unvollständige ANQP-Antwort | Überprüfen Sie die AP-Firmware, die Controller-Vererbung und den Live-Beacon |
| RADIUS-Sättigung | Die Authentifizierung verlangsamt sich oder schlägt bei Onboarding-Spitzen fehl | Steigende Anfragelatenz, Neuübertragungen oder Warteschlangentiefe in RADIUS-Protokollen | Fügen Sie Kapazität und Redundanz hinzu, und testen Sie anschließend die Zertifikats- und Accounting-Last erneut |
| Captive Portal-Konflikt | Unterstützte Clients verbinden sich unregelmäßig oder schließen den Zugriff nie ab | Controller-Debug zeigt eine Portal-Richtlinie, die an die Passpoint-SSID gebunden ist | Trennen Sie Passpoint- und Portal-Richtlinien mit einer expliziten Legacy-SSID |
| Geräteabweichung | Eine Gerätefamilie nutzt Roaming, während eine andere verbunden bleibt oder die Verbindung verweigert | Vergleichen Sie Betriebssystem-Protokolle, Profilunterstützung und RCOI-Handhabung nach Gerätetyp | Pflegen Sie eine Matrix getesteter Geräte und veröffentlichen Sie Ausweichanweisungen |
Überprüfen Sie zuerst die Live-Funkaussendung, dann das Client-Profil, das Zertifikatsvertrauen, die RADIUS-Anfrage und die Richtlinienantwort. Diese Reihenfolge verhindert, dass Sie stundenlang Serverregeln ändern, obwohl der AP die erforderliche HS2.0-Ankündigung nie gesendet hat.
Gemischte Geräteflotten erfordern einen bewussten Übergang. Halten Sie den älteren WPA2-Enterprise- oder EAP-TTLS-Zugang für Geräte bereit, die das Passpoint Profil nicht verarbeiten können, aber platzieren Sie keine Captive Portal Logik auf der Passpoint SSID. Die DSIT-Umfrage zum öffentlichen Engagement für 2025 bis 2026 zeigt, dass 31 % der Erwachsenen mobile Daten oder einen Hotspot zu Hause nutzen, während 3 % sich darauf als primäre Methode für den Heimzugang verlassen. Dies deutet darauf hin, dass die Nutzer mit mobilfunkgestützter Konnektivität vertraut sind, aber Betreiber von Veranstaltungsorten benötigen dennoch eine einfache Alternative für Clients, deren Mobiltelefon, Mobilfunkbetreiber-Kennung oder Betriebssystem das vorgesehene Profil nicht konsistent unterstützt.
Apple- und Android-Geräte können Roaming-Hinweise auch unterschiedlich interpretieren. Testen Sie jede unterstützte Familie und leiten Sie die Kompatibilität nicht allein aus dem Vorhandensein einer Passpoint-Einstellung ab. Wenn eine zuvor funktionierende Bereitstellung ausfällt, vergleichen Sie die letzten Änderungen an Zertifikaten, Profilen, Firmware, Realms und RADIUS-Richtlinien, bevor Sie das WLAN neu aufbauen.
Purple bietet Passpoint WiFi über seine SecurePass Plattform an und nutzt eine profil- und zertifikatsbasierte Registrierung für die automatische Authentifizierung in allen unterstützten Netzwerken. Wenn Sie diesen Ansatz auf Identitätsebene zusammen mit Ihrem bestehenden AP- und RADIUS-Design evaluieren möchten, besuchen Sie Purple und besprechen Sie den Pilotierungsumfang, den Gerätemix und die Fallback-Anforderungen mit dem Team.
