Zum Hauptinhalt springen

PPSK UniFi: Vergleich von Funktionen und Bereitstellungsmodellen

Dieser Leitfaden behandelt die Bereitstellung von PPSK (Private Pre-Shared Key) auf Ubiquiti UniFi-Infrastrukturen für Multi-Tenant-Umgebungen, einschließlich Build to Rent, Studentenwohnheimen und dem Gastgewerbe. Er vergleicht PPSK mit 802.1X und Standard-PSK, beschreibt zwei Bereitstellungsmodelle – natives UniFi und Cloud-RADIUS-Overlay – und erklärt, wie Purple die Verwaltung von Anmeldedaten im großen Maßstab automatisiert. Immobilienentwickler, Vermieter und BTR-Betreiber finden hier praxisnahe Architekturanleitungen, reale Fallstudien und ein klares wirtschaftliches Argument dafür, WiFi als verwaltete Zusatzleistung zu behandeln.

📖 8 Min. Lesezeit📝 1,923 Wörter🔧 2 ausgearbeitete Beispiele4 Übungsfragen📚 9 Schlüsseldefinitionen

Diesen Leitfaden anhören

Podcast-Transkript ansehen
TEIL 1: Willkommen zu diesem technischen Briefing von Purple. Heute befassen wir uns mit PPSK auf UniFi-Infrastrukturen – was es ist, wann man es einsetzt und wie man es in Multi-Tenant-Umgebungen richtig bereitstellt. Wenn Sie Immobilienentwickler, Vermieter oder BTR-Betreiber sind und herausfinden möchten, wie Sie Bewohnern ein heimeliges WiFi-Erlebnis ohne das Chaos einzelner Router bieten können, ist dies genau der richtige Ausgangspunkt. Beginnen wir mit dem Kernproblem. Sie haben ein Gebäude. Es kann 50 Einheiten haben, es können auch 500 sein. Sie möchten WiFi als Zusatzleistung anbieten. Der naive Ansatz besteht darin, in jede Wohnung einen Router zu stellen. Das führt in die Katastrophe. Am Ende senden Hunderte von SSIDs auf denselben Kanälen, was zu Interferenzen führt und die Leistung für alle beeinträchtigt. Die Funkumgebung wird zum Chaos. Der logische nächste Schritt ist also die Zentralisierung. Sie stellen Access Points der Enterprise-Klasse bereit – zum Beispiel die UniFi U6- oder U7-Serie – und betreiben ein einziges Netzwerk im gesamten Gebäude. Jetzt haben Sie eine saubere Funkumgebung. Aber Sie haben ein neues Problem: Wie halten Sie die Bewohner voneinander isoliert? Sie können nicht zulassen, dass Bewohner A die Geräte von Bewohner B durchsucht. Und Sie können kein einziges gemeinsames Passwort verwenden, denn wenn jemand auszieht, müssen Sie das Passwort für das gesamte Gebäude ändern. Hier kommt PPSK ins Spiel. PPSK steht für Private Pre-Shared Key. Das Konzept ist einfach. Sie senden eine einzige SSID aus – einen Netzwerknamen. Aber statt eines Passworts für alle vergeben Sie ein eindeutiges Passwort an jeden Bewohner. Wenn sich das Gerät mit diesem Passwort verbindet, ordnet das Netzwerk es einem dedizierten VLAN zu. Ein VLAN ist ein Virtual Local Area Network – im Wesentlichen ein separates logisches Netzwerk, das auf derselben physischen Infrastruktur läuft. Das Ergebnis ist das, was wir eine WiFi-Blase nennen. Jedes Gerät, das Bewohner A mit seinem Passwort verbindet, landet in seinem VLAN. Sein Smartphone, sein Laptop, sein Smart-TV, sein Chromecast – sie alle sehen sich gegenseitig und können kommunizieren. Aber sie sind für Bewohner B, der sich in einem anderen VLAN mit einem anderen Passwort befindet, völlig unsichtbar. Derselbe Access Point. Dieselbe SSID. Völlig isolierter Datenverkehr. Nun fragen Sie sich vielleicht, warum Sie nicht einfach 802.1X verwenden – den Authentifizierungsstandard für Unternehmen. Das ist eine berechtigte Frage. 802.1X eignet sich hervorragend für Unternehmensumgebungen. Es verwendet einen RADIUS-Server, um Benutzer über eindeutige Anmeldedaten oder Zertifikate zu authentifizieren, und weist VLANs dynamisch zu. Sehr sicher. Aber hier ist das Problem für die Wohnnutzung: 802.1X erfordert, dass das verbindende Gerät über einen sogenannten Supplicant verfügt – eine Software, die den Authentifizierungs-Handshake aushandeln kann. Die meisten IoT-Geräte für Endverbraucher haben dies nicht. Smart-TVs, Spielekonsolen, kabellose Drucker, Smart Speaker – keines dieser Geräte unterstützt 802.1X. Sie akzeptieren nur ein einfaches Passwort. Wenn Sie also 802.1X vorschreiben, schließen Sie sofort einen erheblichen Teil der Geräte aus, die Ihre Bewohner verbinden möchten. PPSK löst dieses Problem. Es verwendet die WPA2-Verschlüsselung – die jedes Gerät unterstützt –, bietet aber die Isolation pro Benutzer, die zuvor nur mit 802.1X möglich war. Sprechen wir speziell über UniFi. Ubiquiti hat vor relativ kurzer Zeit native PPSK-Unterstützung zur UniFi Network-Anwendung hinzugefügt. Die Konfiguration ist einfach: Sie erstellen Ihre VLANs im Controller, erstellen ein drahtloses Netzwerk, aktivieren die Option „Private Pre-Shared Keys“ und weisen dann jedem VLAN manuell ein eindeutiges Passwort zu. Für eine kleine Bereitstellung – sagen wir einen Coworking-Space mit zehn Einheiten oder einen Boutique-Apartmentblock – funktioniert das gut. Es gibt jedoch eine kritische Einschränkung, die Sie kennen müssen. Das native PPSK von UniFi funktioniert nur mit WPA2. Es unterstützt kein WPA3. Dies ist kein UniFi-spezifischer Fehler – es ist eine grundlegende Protokolleinschränkung. WPA3 verwendet einen Handshake-Mechanismus namens Simultaneous Authentication of Equals (SAE). SAE erfordert, dass der Access Point den Pre-Shared Key kennt, bevor der Authentifizierungsprozess beginnt. Bei PPSK geht es gerade darum, dass der Access Point während der Authentifizierung bestimmt, welcher Schlüssel verwendet wird. Diese beiden Anforderungen schließen sich gegenseitig aus. Wenn Sie also PPSK auf UniFi bereitstellen, nutzen Sie WPA2 und können das 6-GHz-Band nicht verwenden. TEIL 2: Bei Bereitstellungen im Unternehmensmaßstab stößt das native UniFi-PPSK auf eine weitere Hürde: die manuelle Verwaltung. Stellen Sie sich vor, Sie müssten 500 eindeutige Passwörter bereitstellen, jedes einem VLAN zuordnen und sie dann einzeln sperren, wenn Bewohner ausziehen. Das ist keine Netzwerkarchitektur. Das ist ein Vollzeitjob. Hier wird ein Cloud-RADIUS-Overlay wie Purple unverzichtbar. Purple integriert sich über RADIUS direkt in Ihre UniFi-Access-Points. Wenn ein neuer Bewohner einzieht, generiert Purple automatisch ein eindeutiges PPSK und stellt sein VLAN bereit. Der Bewohner erhält seine Anmeldedaten über die Purple-App. Er verbindet seine Geräte. Wenn er auszieht, sperrt Purple den Schlüssel sofort. Der Rest des Gebäudes ist nicht betroffen. Purple läuft an 80.000 Standorten weltweit und hat allein im Jahr 2024 über 440 million Logins verarbeitet. Die Cloud-RADIUS-Infrastruktur ist nach ISO 27001 zertifiziert und hält eine Betriebszeit von 99,999 % aufrecht. Sie ist hardwareunabhängig und funktioniert gleichermaßen gut auf Access Points von Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, UniFi, Cambium, Extreme und Fortinet. Lassen Sie mich Ihnen zwei reale Szenarien nennen, um dies zu verdeutlichen. Erstens: Ein BTR-Objekt mit 250 Einheiten in Manchester. Der Entwickler möchte individuelle Breitband-Router durch ein zentralisiertes UniFi-Netzwerk ersetzen. Der IT-Leiter benötigt eine sichere Isolation zwischen den Bewohnern, Unterstützung für Smart-Home-Geräte und ein automatisiertes Offboarding. Die Lösung: UniFi U6-Enterprise-Access-Points in den Fluren, Purple Cloud-RADIUS-Overlay, eine einzige SSID mit PPSK. Purple lässt sich in das Immobilienverwaltungssystem integrieren. Der Einzug löst die automatische Schlüsselbereitstellung aus. Der Auszug löst die automatische Sperrung aus. Der Bewohner verbindet sein Smartphone, seinen Laptop und seinen Smart-TV mit einem Passwort. Seine Geräte erkennen sich gegenseitig. Seine Nachbarn bleiben unsichtbar. Zweitens: Ein Hotel mit 150 Zimmern, das derzeit ein offenes Netzwerk mit einem Captive Portal nutzt. Gäste beschweren sich, dass Apple TVs und Spielekonsolen nicht funktionieren – was zu erwarten ist, da diese Geräte kein Captive Portal nutzen können. Die Lösung: Migration zu einer PPSK-gesicherten SSID. Das Immobilienverwaltungssystem des Hotels veranlasst Purple, einen eindeutigen Schlüssel pro Zimmer und Aufenthalt zu generieren. Der Gast erhält das Passwort beim Check-in. Er verbindet alle seine Geräte. Der Schlüssel läuft beim Check-out automatisch ab. Nun zu einigen Implementierungsfehlern, die es zu vermeiden gilt. Das häufigste Support-Ticket im Multi-Tenant-WiFi ist das Chromecast-Problem. Ein Bewohner kann nicht von seinem Smartphone auf seinen Fernseher streamen. Dies bedeutet fast immer, dass sich die beiden Geräte in unterschiedlichen Subnetzen befinden oder dass der mDNS-Traffic an der VLAN-Grenze verworfen wird. Überprüfen Sie, ob beide Geräte exakt dasselbe PPSK verwenden. Bestätigen Sie, dass die VLAN-Zuweisung korrekt ist. Und stellen Sie sicher, dass Ihre Netzwerkkonfiguration die mDNS-Weiterleitung (reflection) innerhalb des VLANs eines Bewohners zulässt, während sie das Überschreiten in andere VLANs blockiert. Der zweite Fehler ist die Dimensionierung des DHCP-Bereichs. Planen Sie 15 bis 25 Geräte pro Haushalt ein. Ein Gebäude mit 200 Einheiten kann problemlos 4.000 gleichzeitige Geräte haben. Ein Slash-24-Subnetz pro Bewohner bietet Ihnen 254 nutzbare IP-Adressen – mehr als genug pro Einheit. Stellen Sie jedoch sicher, dass Ihre Core-Routing-Infrastruktur Hunderte von Subnetzen gleichzeitig bewältigen kann. Drittens: Senden Sie nicht zu viele SSIDs aus. Jede zusätzliche SSID verbraucht Sendezeit (Airtime) durch Management-Frames. Der eigentliche Zweck von PPSK besteht darin, sich auf eine oder zwei SSIDs zu konsolidieren. Die wirtschaftlichen Argumente für BTR-Betreiber liegen auf der Hand. WiFi als Zusatzleistung erzielt durchweg einen Mietaufschlag von fünfzehn bis dreißig Pfund pro Einheit und Monat. Sofort einsatzbereites WiFi verkürzt Leerstandszeiten um fünf bis zehn Tage. Und die Bereitstellung eines Software-Overlays auf eigener Hardware senkt die Kosten pro Wohneinheit um dreißig bis fünfzig Prozent im Vergleich zu gebündelten Breitbandverträgen. Drei schnelle Fragen zum Abschluss. Kann ich PPSK mit WPA3 verwenden? Nein. PPSK erfordert WPA2. Dies ist eine Protokolleinschränkung, keine Einschränkung des Herstellers. Funktioniert PPSK mit 6-GHz-Bändern? Nein. 6 GHz erfordert WPA3 oder den WPA3-Transition-Modus. Da PPSK nur WPA2 unterstützt, ist es auf 2,4 GHz und 5 GHz beschränkt. Was passiert wenn ein Bewohner sein Passwort vergisst? Er wendet sich an den Immobilienverwalter, der sein PPSK über das Purple-Dashboard abrufen oder neu generieren kann. Der neue Schlüssel wird an den Bewohner ausgegeben. Seine bestehenden verbundenen Geräte müssen neu verbunden werden, aber kein anderer Bewohner ist davon betroffen. Zusammenfassend lässt sich sagen: PPSK auf UniFi bietet Ihnen eine einzige SSID, eindeutige Passwörter pro Bewohner und eine automatische VLAN-Isolation. Es löst das Problem mit IoT-Geräten, das 802.1X für die Wohnnutzung unpraktisch macht. Natives UniFi-PPSK eignet sich für kleine Bereitstellungen. Das Cloud-RADIUS-Overlay von Purple bewältigt den Unternehmensmaßstab mit automatisierter Bereitstellung und Sperrung. Wenn Sie sehen möchten, wie das in der Praxis funktioniert, besuchen Sie purple.ai und sprechen Sie mit einem unserer Netzwerkarchitekten. Wir haben diese Architektur in Tausenden von Wohnungen bereitgestellt und können Sie durch die Konfiguration für Ihre spezifische Hardware und Ihren Immobilientyp führen. Vielen Dank fürs Zuhören.

header_image.png

Executive Summary

Für Immobilienentwickler und IT-Manager, die Multi-Tenant-Gebäude betreiben, lautet die zentrale WiFi-Herausforderung: Bewohner erwarten ein Heimnetzwerk-Erlebnis – Geräte, die sich gegenseitig erkennen, Smart-TVs, die streamen, Konsolen, die sich verbinden –, aber auf einer gemeinsam genutzten Infrastruktur, die jeden Haushalt von den anderen isolieren muss. Standard-PSK scheitert an der Isolation. 802.1X scheitert an der Kompatibilität mit IoT-Geräten. PPSK (Private Pre-Shared Key) löst beides.

PPSK sendet eine einzige SSID im gesamten Gebäude aus und vergibt gleichzeitig ein eindeutiges Passwort an jeden Bewohner. Das Netzwerk nutzt dieses Passwort, um jedes verbundene Gerät einem dedizierten VLAN zuzuweisen, wodurch ein isoliertes Mikronetzwerk pro Haushalt entsteht. Geräte innerhalb desselben Bewohner-VLANs kommunizieren frei miteinander; Geräte in unterschiedlichen VLANs bleiben füreinander unsichtbar.

Auf Ubiquiti UniFi-Hardware ist PPSK nativ für kleine Bereitstellungen und über das Cloud-RADIUS-Overlay von Purple für den Unternehmenseinsatz verfügbar. Dieser Leitfaden behandelt beide Modelle, die Protokolleinschränkungen, die Sie kennen müssen, und die wirtschaftlichen Argumente für die Bereitstellung von verwaltetem WiFi als umsatzgenerierende Zusatzleistung.

Technischer Deep-Dive: PPSK vs. 802.1X vs. PSK

Um zu verstehen, wo PPSK hineinpasst, ist ein direkter Vergleich mit den beiden dominierenden Authentifizierungsstandards für Unternehmen erforderlich.

Standard-PSK

WPA2/WPA3-Personal verwendet ein einziges Passwort für alle Clients auf einer SSID. Jedes Gerät teilt sich dieselbe Broadcast-Domäne. In einem Multi-Tenant-Gebäude bedeutet dies, dass Bewohner A die Geräte von Bewohner B sehen kann. Sie können die Client-Isolation auf dem Access Point aktivieren, um eine direkte Kommunikation von Gerät zu Gerät zu verhindern. Dies unterbricht jedoch die lokale Netzwerkfunktionalität vollständig – Smart Speaker können keine intelligenten Lampen steuern, Smartphones können nicht auf Fernseher streamen und Spielekonsolen können keine lokalen Dienste finden. Standard-PSK ist für die Nutzung in Multi-Tenant-Wohngebäuden nicht geeignet.

802.1X (WPA-Enterprise)

802.1X authentifiziert Benutzer über einen RADIUS-Server mit eindeutigen Anmeldedaten (Benutzername und Passwort) oder Zertifikaten, wobei EAP-TLS oder PEAP die gängigen Authentifizierungsmethoden sind. Es bietet starke Sicherheit und unterstützt die dynamische VLAN-Zuweisung über RADIUS-Attribute (insbesondere Tunnel-Private-Group-ID). 802.1X erfordert jedoch, dass auf dem verbindenden Gerät ein Supplicant ausgeführt wird – eine Software, die den Authentifizierungs-Handshake aushandelt. Die meisten IoT-Geräte für Endverbraucher, Smart-TVs und Spielekonsolen enthalten keinen Supplicant. Sie akzeptieren nur ein einfaches Passwort. Die Vorschreibung von 802.1X in einer Wohnumgebung schließt sofort einen erheblichen Teil der Geräte aus, die Bewohner verbinden möchten.

PPSK (Private Pre-Shared Key)

PPSK – von Cisco Meraki und Purple auch iPSK (Identity Pre-Shared Key) und von einigen Anbietern Personal Private Network genannt – schließt diese Lücke. Es verwendet die WPA2-Verschlüsselung, die jedes Gerät unterstützt, ordnet jedoch jedes eindeutige Passwort einem bestimmten VLAN zu. Der Access Point (or ein externer RADIUS-Server) führt diese Zuordnung zum Zeitpunkt der Zuordnung durch. Das Ergebnis ist eine Isolation pro Bewohner, ohne dass eine spezielle Client-Software erforderlich ist.

comparison_chart.png

Dimension Standard-PSK 802.1X (WPA-Enterprise) PPSK
Sicherheitsmodell Gemeinsamer Schlüssel, keine Isolation Anmeldedaten pro Benutzer, stark Schlüssel pro Benutzer, stark
Unterstützung für IoT-Geräte Ja Nein (erfordert Supplicant) Ja
VLAN-Zuweisung Statisch, einzelnes VLAN Dynamisch über RADIUS Dynamisch über Schlüsselzuordnung
WPA3-kompatibel Ja Ja Nein (nur WPA2)
Unterstützung für 6-GHz-Band Ja Ja Nein
Verwaltungsaufwand Gering (ein Schlüssel) Hoch (RADIUS-Infrastruktur erforderlich) Mittel (Schlüssel pro Benutzer)
Skalierbarkeit Gering (gemeinsamer Schlüssel) Hoch Hoch (mit Cloud-RADIUS)

Die WPA3-Einschränkung. PPSK ist grundlegend inkompatibel mit WPA3. WPA3 verwendet die Simultaneous Authentication of Equals (SAE), die erfordert, dass der Access Point den Pre-Shared Key kennt, bevor der Authentifizierungs-Handshake beginnt. PPSK bestimmt während der Authentifizierung, welcher Schlüssel verwendet wird. Diese Anforderungen schließen sich gegenseitig aus. Wenn Sie PPSK auf UniFi bereitstellen, nutzen Sie WPA2 und können keine 6-GHz-Bänder verwenden.

Implementierungsleitfaden: 2 Bereitstellungsmodelle

Modell 1: Natives UniFi PPSK (kleine Bereitstellungen)

Ubiquiti hat in neueren Firmware-Releases native PPSK-Unterstützung zur UniFi Network-Anwendung hinzugefügt. Dieses Modell eignet sich für kleine Coworking-Spaces, Boutique-MDU-Gebäude oder Pilotprojekte.

Schritt 1: VLAN-Konfiguration. Navigieren Sie im UniFi-Controller zu Einstellungen > Netzwerke und erstellen Sie ein dediziertes VLAN für jeden Mieter. Weisen Sie jedem VLAN eine eindeutige ID zu (z. B. VLAN 101 für Wohneinheit 1, VLAN 102 für Wohneinheit 2).

Schritt 2: Netzwerkerstellung. Navigieren Sie zu Einstellungen > WiFi und fügen Sie ein neues drahtloses Netzwerk hinzu. Stellen Sie das Sicherheitsprotokoll auf WPA2 Personal ein.

Schritt 3: PPSK aktivieren. Aktivieren Sie in den WiFi-Einstellungen die Option „Private Pre-Shared Keys“. Der Controller fordert Sie auf, individuelle Passwörter zu erstellen.

Schritt 4: Schlüssel-zu-VLAN-Zuordnung. Weisen Sie jedes erstellte Passwort dem entsprechenden VLAN zu. Der Access Point verwendet das Passwort, um beim Verbindungsaufbau die VLAN-Zuweisung zu bestimmen.

Schritt 5: mDNS-Konfiguration. Stellen Sie sicher, dass Ihr UniFi-Gateway oder USG so konfiguriert ist, dass mDNS-Reflection innerhalb jedes VLANs zugelassen, aber VLAN-übergreifender Multicast blockiert wird. Dies ist für die Geräteerkennung (Chromecast, Apple TV, Sonos) unerlässlich.

Einschränkungen von nativem PPSK. Die manuelle Schlüsselverwaltung ist ab einigen Dutzend Einheiten betrieblich nicht mehr praktikabel. Es gibt keine automatisierte Bereitstellung oder Sperrung. Wenn ein Mieter auszieht, müssen Sie seinen Schlüssel manuell aus dem Controller löschen. Es gibt keine Integration mit Immobilienverwaltungssystemen.

Modell 2: Cloud-RADIUS-Overlay mit Purple (Unternehmensmaßstab)

architecture_overview.png

Für große BTR- oder Studentenwohnheim-Objekte bietet Purple ein hardwareunabhängiges Software-Overlay, das sich über RADIUS in UniFi-Access-Points integrieren lässt. Dieses Modell automatisiert den gesamten Lebenszyklus der Anmeldedaten.

Schritt 1: RADIUS-Profilkonfiguration. Navigieren Sie im UniFi-Controller zu Einstellungen > Profile > RADIUS und erstellen Sie ein neues Profil. Geben Sie die Cloud-RADIUS-Serveradressen von Purple und das während des Purple-Onboardings bereitgestellte Shared Secret ein.

Schritt 2: SSID-Konfiguration. Erstellen Sie ein drahtloses Netzwerk mit WPA2-Enterprise. Wählen Sie das in Schritt 1 erstellte RADIUS-Profil aus. Der RADIUS-Server von Purple übernimmt die Authentifizierung und gibt die VLAN-Zuweisung über das Attribut Tunnel-Private-Group-ID zurück.

Schritt 3: Integration der Immobilienverwaltung. Verbinden Sie Purple über eine API oder einen Webhook mit Ihrem Immobilienverwaltungssystem (PMS). Wenn ein neues Mietverhältnis im PMS angelegt wird, generiert Purple automatisch ein eindeutiges PPSK und stellt das entsprechende VLAN bereit.

Schritt 4: Onboarding der Bewohner. Der Bewohner erhält seine Anmeldedaten über die Purple-App oder eine Willkommens-E-Mail. Er verwendet dieses einzige Passwort für alle seine Geräte – Smartphones, Laptops, Smart-TVs, Konsolen und IoT-Sensoren.

Schritt 5: Automatisiertes Offboarding. Wenn das Mietverhältnis endet, veranlasst das PMS Purple, den Schlüssel zu sperren. Der Zugriff wird sofort beendet. Kein anderer Bewohner ist davon betroffen.

Dieses Modell läuft auf der Cloud-RADIUS-Infrastruktur von Purple, die über 80.000 Standorte unterstützt und im Jahr 2024 eine Betriebszeit von 99,999 % aufwies (interne Daten von Purple). Es ist kompatibel mit Access Points von Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet.

Für verwandte Netzwerkdesign-Strategien siehe Drei SSIDs, sie alle zu beherrschen: Gäste-, Passpoint- und IoT-WiFi und unseren umfassenden Leitfaden iPSK: Ein umfassender Leitfaden für Unternehmen .

Best Practices für das Multi-Tenant-WiFi-Design

Auf Dichte auslegen. Planen Sie mit 15–25 Geräten pro Haushalt (interne Daten von Purple aus über 80.000 Standorten). Ein BTR-Objekt mit 200 Einheiten wird 3.000–5.000 gleichzeitige Geräte verzeichnen. Wählen Sie UniFi-Access-Points – wie U6-Enterprise oder U7-Pro – mit ausreichend CPU und Arbeitsspeicher für hohe Client-Zahlen. Platzieren Sie APs in Fluren statt in den Wohneinheiten, um die Anzahl der benötigten APs zu reduzieren und gleichzeitig die Abdeckung aufrechtzuerhalten.

mDNS sorgfältig verwalten. Multicast-DNS ist für die Geräteerkennung (Apple Bonjour, Google Cast, Sonos) unerlässlich. Konfigurieren Sie Ihr Netzwerk so, dass mDNS-Traffic innerhalb des VLANs jedes Bewohners weitergeleitet (reflected) wird, während er die VLAN-Grenzen strengstens nicht überschreiten darf. Die mDNS-Repeater-Funktion von UniFi übernimmt dies bei korrekter Konfiguration.

DHCP-Bereiche richtig dimensionieren. Ein /24-Subnetz (254 nutzbare IPs) pro Bewohner ist für die meisten Haushalte ausreichend. Stellen Sie sicher, dass Ihre Core-Routing-Infrastruktur – typischerweise eine UniFi Dream Machine Pro oder UDM-SE – Hunderte von gleichzeitigen Subnetzen ohne Leistungseinbußen bewältigen kann.

SSID-Anzahl minimieren. Jede zusätzliche SSID, die Sie aussenden, verbraucht Sendezeit (Airtime) durch Management-Frames, was die verfügbare Bandbreite für den Datenverkehr verringert. PPSK ermöglicht Ihnen die Konsolidierung auf eine einzige Bewohner-SSID. Fügen Sie eine separate Gäste-WiFi -SSID für Besucher in Gemeinschaftsbereichen und eine Mitarbeiter-WiFi-SSID für die Gebäudeverwaltung hinzu. Drei SSIDs sind für die meisten Bereitstellungen das praktische Maximum.

Client-Isolation zwischen VLANs auf Routing-Ebene implementieren. Verlassen Sie sich nicht ausschließlich auf VLAN-Tagging. Konfigurieren Sie explizite ACLs auf Ihrem Core-Router, um Inter-VLAN-Routing zwischen den Bewohnernetzwerken zu verhindern. Lassen Sie Routing nur zum und vom Internet-Gateway zu.

Fehlerbehebung und Risikominderung

Das Chromecast-Problem

Das häufigste Support-Ticket in Multi-Tenant-Umgebungen ist das Fehlschlagen des Streamings auf Geräte. Das Smartphone eines Bewohners kann seinen Chromecast oder sein Apple TV nicht finden. Dies geschieht, wenn sich das sendende Gerät und der Empfänger in unterschiedlichen Subnetzen befinden oder wenn mDNS-Traffic an der VLAN-Grenze verworfen wird.

Diagnose: Bestätigen Sie, dass beide Geräte dasselbe PPSK verwenden. Überprüfen Sie im UniFi-Controller die Client-Liste und stellen Sie sicher, dass beide Geräte demselben VLAN zugewiesen sind. Wenn sie sich in unterschiedlichen VLANs befinden, ist die PPSK-Zuordnung fehlerhaft.

Lösung: Korrigieren Sie die PPSK-zu-VLAN-Zuordnung im Controller oder im Purple-Dashboard. Stellen Sie sicher, dass der UniFi-mDNS-Repeater aktiviert und für die richtigen VLANs konfiguriert ist.

Chaos bei der Passwortrotation

Bei Standard-PSK-Bereitstellungen muss beim Auszug eines Bewohners das gebäudeweite Passwort geändert werden, was alle anderen Bewohner dazu zwingt, all ihre Geräte zu aktualisieren. Dies ist im großen Maßstab betrieblich katastrophal.

Lösung: PPSK eliminiert dieses Risiko vollständig. Das Sperren des Schlüssels eines Bewohners betrifft nur diesen Bewohner. Purple automatisiert die Sperrung über die PMS-Integration, sodass kein manuelles Eingreifen erforderlich ist.

DHCP-Erschöpfung

In Gebäuden mit hoher Dichte können DHCP-Pools erschöpft sein, wenn sie zu klein dimensioniert sind. Ein /24-Subnetz bietet 254 IPs. Bei mehr als 20 Geräten pro Haushalt ist dies für einzelne Einheiten ausreichend. Stellen Sie jedoch sicher, dass Ihre DHCP-Lease-Zeiten angemessen eingestellt sind (vier bis acht Stunden für Wohnzwecke), um Adressen von getrennten Geräten wieder freizugeben.

WPA3-Migrationsplanung

Da WPA3 auf neuen Geräten zum Standard wird, wird die WPA2-Einschränkung von PPSK immer relevanter. Planen Sie jetzt Ihren Migrationspfad. Für Objekte, bei denen WPA3 Priorität hat, sollten Sie 802.1X mit einem Cloud-RADIUS-Overlay evaluieren, das das Onboarding von IoT-Geräten separat über MAC-based Authentication oder eine dedizierte IoT-SSID abwickelt.

ROI und geschäftliche Auswirkungen

Die Behandlung von WiFi als verwaltete Zusatzleistung liefert messbare kommerzielle Erträge für BTR-Betreiber. Immobilien, die leistungsstarkes, sofort einsatzbereites WiFi bieten, erzielen einen Mietaufschlag von 15–30 £ pro Einheit und Monat, basierend auf Branchen-Benchmarks der British Property Federation. Sofort einsatzbereites WiFi verkürzt Leerstandszeiten um fünf bis zehn Tage. Die Bereitstellung des Software-Overlays von Purple auf eigener UniFi-Hardware senkt die Kosten pro Wohneinheit um 30–50 % im Vergleich zur Aushandlung einzelner Breitbandverträge mit herkömmlichen ISPs (interne Modellierung von Purple).

Für ein BTR-Objekt mit 200 Einheiten ist die Rechnung einfach. Ein Aufschlag von 20 £ pro Einheit und Monat generiert zusätzliche jährliche Einnahmen von 48.000 £. Gegenüber den Kosten für ein Software-Overlay, das pro Einheit skaliert, liegt die Amortisationszeit in der Regel bei unter 12 Monaten.

Für Betreiber im Gastgewerbe ist der Nutzen anders, aber ebenso messbar. Das Ersetzen eines offenen Netzwerks durch eine PPSK-gesicherte SSID eliminiert Beeinträchtigungen des Gästeerlebnisses, die durch Captive Portals entstehen, welche IoT-Geräte blockieren, reduziert Support-Anrufe an der Rezeption und ermöglicht WiFi Analytics , die First-Party-Daten für Treue- und Marketingprogramme generieren.

Für Betreiber im Einzelhandel und Transportwesen ermöglicht PPSK eine sichere Segmentierung des Mitarbeiternetzwerks auf derselben Infrastruktur wie das Gäste-WiFi, was die Hardwarekosten senkt und das Netzwerkmanagement vereinfacht.

Für Umgebungen im Gesundheitswesen bietet PPSK die Patienten- und Besucherisolation, die gemäß den Netzwerk-Sicherheitsstandards von GDPR und NHS erforderlich ist.

Purple hat diese Architektur an über 80.000 Standorten weltweit bereitgestellt, darunter Premier Inn, Whitbread und Manchester Airports Group (MAG). Die Plattform hat im Jahr 2024 440 Millionen Logins verarbeitet und verfügt über Zertifizierungen nach ISO 27001, GDPR, CCPA und Cyber Essentials.

Weitere Informationen zur iPSK-Architektur und -Bereitstellung finden Sie unter Nama ff keren iPSK: Ein umfassender Leitfaden für Unternehmen und Drei SSIDs, sie alle zu beherrschen: Das WiFi-Design für Gäste, Mitarbeiter und IoT .

Schlüsseldefinitionen

PPSK (Private Pre-Shared Key)

Eine Methode zur drahtlosen Sicherheit, die es ermöglicht, mehrere eindeutige Passwörter auf einer einzigen SSID zu betreiben, wobei jedes Passwort das verbindende Gerät einem bestimmten VLAN zuordnet. Von Cisco Meraki und Purple auch als iPSK (Identity Pre-Shared Key) bezeichnet.

Wird in Multi-Tenant-Umgebungen verwendet, um sichere, isolierte Netzwerke pro Bewohner bereitzustellen, ohne die Komplexität von 802.1X oder den Funk-Overhead mehrerer SSIDs.

iPSK (Identity Pre-Shared Key)

Der herstellerneutrale Begriff für PPSK, der von Purple und Cisco Meraki verwendet wird. Die Technologie und das Ergebnis sind identisch mit PPSK. Ubiquiti verwendet den Begriff PPSK; HPE Aruba verwendet denselben Begriff.

Sie werden iPSK in der Dokumentation von Purple und in Konfigurationen von Cisco Meraki finden. Es bezieht sich auf denselben Mechanismus zur Zuordnung von Schlüsseln zu VLANs pro Benutzer.

VLAN (Virtual Local Area Network)

Ein logisches Subnetz, das Geräte aus verschiedenen physischen Netzwerksegmenten gruppiert. VLANs isolieren Broadcast-Domänen und verhindern in Kombination mit Routing-ACLs den netzwerkübergreifenden Datenverkehr.

Beim Multi-Tenant-WiFi wird jedem Bewohner ein dediziertes VLAN zugewiesen. Seine Geräte kommunizieren innerhalb des VLANs frei miteinander, können aber keine Geräte in den VLANs anderer Bewohner erreichen.

RADIUS (Remote Authentication Dial-In User Service)

Ein Netzwerkprotokoll, das eine zentrale Authentifizierung, Autorisierung und Abrechnung (AAA) für den Netzwerkzugriff bereitstellt. Bei PPSK-Bereitstellungen ordnet der RADIUS-Server Anmeldedaten über das Attribut Tunnel-Private-Group-ID den VLAN-Zuweisungen zu.

Purple fungiert als Cloud-RADIUS-Server. UniFi-Access-Points senden Authentifizierungsanfragen an die RADIUS-Server von Purple, die die korrekte VLAN-Zuweisung für jedes eindeutige PPSK zurückgeben.

mDNS (Multicast DNS)

Ein Protokoll, das Hostnamen in lokalen Netzwerken ohne zentralen DNS-Server in IP-Adressen auflöst. Wird von Apple Bonjour, Google Cast, Sonos und ähnlichen Geräteerkennungsprotokollen verwendet.

Die Verwaltung von mDNS is in Multi-Tenant-Netzwerken von entscheidender Bedeutung. Es muss innerhalb des VLANs jedes Bewohners weitergeleitet (reflected) werden, um die Geräteerkennung zu ermöglichen, darf jedoch die VLAN-Grenzen zu anderen Bewohnern nicht überschreiten.

SAE (Simultaneous Authentication of Equals)

Der WPA3-Handshake-Mechanismus, der den WPA2-Vier-Wege-Handshake ersetzt. SAE erfordert, dass beide Parteien den Pre-Shared Key kennen, bevor der Handshake beginnt, was es inkompatibel mit PPSK macht.

Dies ist der technische Grund, warum PPSK nicht auf WPA3- oder 6-GHz-Bändern betrieben werden kann. Das Verständnis von SAE erklärt, warum die WPA2-Einschränkung eine Protokollbeschränkung und keine Entscheidung des Herstellers ist.

BTR (Build to Rent)

Zweckgebundene Wohnimmobilien, die speziell für den Mietmarkt und nicht für den Verkauf konzipiert sind. Ein primärer Bereitstellungssektor für Multi-Tenant-WiFi, bei dem hochwertiges Internet zu den fünf wichtigsten Zusatzleistungen gehört.

BTR-Betreiber sind die Hauptzielgruppe für PPSK-basiertes verwaltetes WiFi. Die Kombination aus hoher Gerädetichte, IoT-Anforderungen und häufigem Mieterwechsel macht PPSK zur richtigen Architektur.

Headless device

Ein mit dem Netzwerk verbundenes Gerät, das über keinen herkömmlichen Bildschirm oder keine Tastaturschnittstelle verfügt, wie z. B. eine intelligente Steckdose, ein kabelloser Lautsprecher, ein Umgebungssensor oder eine Spielekonsole. Diese Geräte können weder Captive Portals nutzen noch eine 802.1X-Authentifizierung aushandeln.

Die Verbreitung von Headless-Geräten in Wohnumgebungen – durchschnittlich 15–25 pro Haushalt – ist der Hauptgrund, warum 802.1X für BTR- und Studentenwohnheim-Bereitstellungen unpraktisch ist.

Cloud RADIUS overlay

Eine Software-as-a-service-Architektur, bei der ein in der Cloud gehosteter RADIUS-Server die Authentifizierung und VLAN-Zuweisung für Access Points vor Ort übernimmt. Die Access Points benötigen keine lokale RADIUS-Infrastruktur.

Das Cloud-RADIUS-Overlay von Purple ist der Mechanismus, der eine PPSK-Verwaltung im Unternehmensmaßstab auf UniFi-Hardware ohne Server vor Ort ermöglicht. Es lässt sich für eine automatisierte Bereitstellung in Immobilienverwaltungssysteme integrieren.

Ausgearbeitete Beispiele

Ein BTR-Objekt mit 250 Einheiten in Manchester ersetzt individuelle Breitband-Router durch ein zentralisiertes UniFi-Netzwerk. Der IT-Leiter muss sicheres WiFi für die Bewohner bereitstellen und sicherstellen, dass Smart-Home-Geräte in den Wohnungen funktionieren, während gleichzeitig verhindert wird, dass Bewohner auf die Netzwerke der anderen zugreifen. Zudem muss die Zugriffssperrung bei Ende des Mietverhältnisses automatisiert und in das bestehende Immobilienverwaltungssystem integriert werden.

Stellen Sie UniFi U6-Enterprise-Access-Points in den Fluren bereit, um die Abdeckung in den Wohnungen zu gewährleisten. Konfigurieren Sie eine einzige Bewohner-SSID unter Verwendung von WPA2 mit dem Cloud-RADIUS-Overlay von Purple. Integrieren Sie Purple über eine API in das Immobilienverwaltungssystem. Wenn ein Bewohner einzieht, generiert Purple automatisch ein eindeutiges PPSK und weist ein dediziertes VLAN zu (z. B. VLAN 101 für Wohneinheit 1, VLAN 102 für Wohneinheit 2). Der Bewohner verbindet sein Smartphone, seinen Laptop und seinen Smart-TV mit seinem eindeutigen Schlüssel. Alle seine Geräte landen in seinem spezifischen VLAN. mDNS-Reflection wird innerhalb jedes VLANs aktiviert, damit Chromecast und Smart Speaker korrekt funktionieren. Wenn der Bewohner auszieht, benachrichtigt das PMS Purple, das den Schlüssel sofort sperrt, ohne die anderen 249 Einheiten zu beeinträchtigen.

Kommentar des Prüfers: Dieser Ansatz eliminiert die Funkinterferenzen, die durch 250 einzelne Router verursacht werden, die separate SSIDs aussenden. Durch die Nutzung des Cloud-RADIUS von Purple vermeidet der IT-Leiter die manuelle Konfiguration von 250 VLANs und Passwörtern im UniFi-Controller. Die PMS-Integration sorgt für ein Zero-Touch-Provisioning und ein sicheres Offboarding. Die entscheidende Architekturentscheidung ist die Verwendung von WPA2-Enterprise mit RADIUS anstelle von nativem UniFi-PPSK, was bei dieser Größenordnung eine manuelle Verwaltung erfordern würde.

Ein Hotel mit 150 Zimmern nutzt derzeit ein offenes Netzwerk mit einem Captive Portal für das Gäste-WiFi. Gäste beschweren sich, dass Apple TVs und Spielekonsolen in den Zimmern keine Verbindung herstellen können. Der IT-Manager des Hotels möchte ein sicheres, heimeliges WiFi-Erlebnis bieten und gleichzeitig die Möglichkeit behalten, den Zugriff beim Check-out ablaufen zu lassen. Das Hotel nutzt ein Standard-PMS.

Migrieren Sie vom offenen Captive-Portal-Netzwerk zu einer PPSK-gesicherten SSID. Integrieren Sie das UniFi-Netzwerk mit Purple und dem PMS des Hotels. Beim Check-in veranlasst das PMS Purple, ein eindeutiges PPSK zu generieren, das an die Zimmernummer und das Abreisedatum des Gasts gebunden ist. Der Gast erhält das Passwort auf seiner Schlüsselkartenhülle oder über die Purple-App. Er verwendet dieses Passwort, um sein Smartphone, seinen Laptop und sein Apple TV zu verbinden. Alle Geräte landen in einem sicheren Mikrosegment. Apple TV und Spielekonsolen verbinden sich über das einfache Passwort – eine Navigation durch ein Captive Portal ist nicht erforderlich. Beim Check-out läuft der Schlüssel automatisch ab. Das Hotel behält eine separate offene SSID mit Captive Portal für den Gästezugang in der Lobby und den Gemeinschaftsbereichen bei.

Kommentar des Prüfers: Die entscheidende Erkenntnis hierbei ist, dass Captive Portals grundlegend inkompatibel mit bildschirmlosen Geräten (headless devices) sind. Apple TVs und Spielekonsolen können keinen Browser öffnen, um Nutzungsbedingungen zu akzeptieren. PPSK löst dies, indem es WPA2-Sicherheit mit einem einfachen Passwort bietet, das jedes Gerät verwenden kann. Der automatische Ablauf über die PMS-Integration verhindert unbefugten Zugriff nach dem Check-out, ohne dass ein manuelles Eingreifen der Rezeption oder des IT-Teams erforderlich ist.

Übungsfragen

Q1. Sie stellen WiFi in einem Studentenwohnheim mit 500 Betten bereit. Der Kunde möchte 802.1X verwenden, um Sicherheit auf Unternehmensniveau zu gewährleisten. Die Studenten werden jedoch Spielekonsolen, Smart-TVs und kabellose Drucker mitbringen. Was ist der empfohlene Architekturansatz und was sind die wichtigsten Kompromisse?

Hinweis: Berücksichtigen Sie die Fähigkeiten von IoT-Geräten für Endverbraucher im Hinblick auf Authentifizierungsprotokolle für Unternehmen und ob ein hybrider Ansatz praktikabel ist.

Musterlösung anzeigen

Raten Sie von der Verwendung von 802.1X als einziger Authentifizierungsmethode ab. Endverbrauchergeräten wie Spielekonsolen und Smart-TVs fehlt der für die Authentifizierung erforderliche 802.1X-Supplicant. Empfehlen Sie eine PPSK-Architektur unter Verwendung des Cloud-RADIUS von Purple. Dies bietet WPA2-Sicherheit mit einer VLAN-Isolation pro Student, während sich Headless-Geräte über ein einfaches, eindeutiges Passwort verbinden können. Wenn der Kunde auf 802.1X für Laptops und Smartphones besteht, implementieren Sie eine Hybridlösung: 802.1X für verwaltete Geräte und eine separate PPSK-SSID für IoT-Geräte, wobei beide demselben VLAN pro Student zugeordnet werden. Dies erhöht die Anzahl der SSIDs, behält aber das vom Kunden geforderte Sicherheitsniveau bei.

Q2. Der Manager eines Coworking-Space berichtet, dass Mitglieder keine Präsentationen von ihren Laptops auf die Smart-TVs in den Besprechungsräumen streamen können. Sie nutzen derzeit ein einziges Standard-PSK-Netzwerk mit aktivierter Client-Isolation, um die Privatsphäre der Mitglieder zu schützen. Wie lösen Sie dies, ohne die Privatsphäre der Mitglieder zu gefährden?

Hinweis: Die Client-Isolation verhindert jegliche Kommunikation von Gerät zu Gerät auf dem AP, auch innerhalb der Geräte desselben Unternehmens.

Musterlösung anzeigen

Das aktuelle Setup unterbricht mDNS, das für das Streaming erforderlich ist. Migrieren Sie das Netzwerk auf ein PPSK-Modell. Vergeben Sie ein eindeutiges Passwort an jedes Mitgliedsunternehmen und ordnen Sie jedes einem dedizierten VLAN zu. Deaktivieren Sie die Client-Isolation auf AP-Ebene – diese wird nicht mehr benötigt, da die VLAN-Grenzen die Isolation übernehmen. Konfigurieren Sie Routing-ACLs, um Inter-VLAN-Traffic zu verhindern. Aktivieren Sie mDNS-Reflection innerhalb jedes VLANs. Die Laptops jedes Unternehmens können nun die Fernseher in ihrem VLAN erkennen und darauf streamen, während sie von anderen Unternehmen isoliert bleiben. Wenn Fernseher von mehreren Unternehmen gemeinsam genutzt werden müssen, platzieren Sie sie in einem gemeinsam genutzten VLAN und konfigurieren Sie entsprechende mDNS-Proxy-Regeln.

Q3. Sie konfigurieren natives UniFi-PPSK für ein kleines Apartmentgebäude mit 10 Einheiten. Sie wählen WPA3 für das drahtlose Netzwerk, um die stärkste verfügbare Sicherheit zu bieten. Die Konfiguration kann nicht angewendet werden. Warum passiert das und was ist der richtige Ansatz?

Hinweis: Überprüfen Sie die Protokollanforderungen für den SAE-Handshake von WPA3 und wie diese mit dem Authentifizierungsmechanismus von PPSK interagieren.

Musterlösung anzeigen

PPSK is inkompatibel mit WPA3. WPA3 verwendet die Simultaneous Authentication of Equals (SAE), die erfordert, dass der Access Point den Pre-Shared Key kennt, bevor der Authentifizierungsprozess beginnt. Bei PPSK bestimmt der Access Point während der Authentifizierung, welcher Schlüssel verwendet wird – diese Anforderungen schließen sich gegenseitig aus. Der richtige Ansatz besteht darin, das Netzwerk mit WPA2 Personal und aktiviertem PPSK zu konfigurieren. Wenn die WPA3-Sicherheit für das Objekt Priorität hat, sollten Sie 802.1X mit einem Cloud-RADIUS-Overlay für Laptops und Smartphones und eine separate WPA2-PPSK-SSID für IoT-Geräte in Betracht ziehen. Dokumentieren Sie diese Einschränkung für den Kunden klar, damit er den Sicherheitskompromiss versteht.

Q4. Ein BTR-Objekt mit 300 Einheiten verzeichnet häufige Support-Anrufe von Bewohnern, die berichten, dass ihre Chromecast-Geräte nicht funktionieren. Das Netzwerk verwendet PPSK mit dem Cloud-RADIUS-Overlay von Purple auf UniFi-Hardware. Was sind die drei wahrscheinlichsten Ursachen und wie diagnostizieren Sie diese jeweils?

Hinweis: Chromecast erfordert, dass sich das sendende Gerät und der Empfänger im selben logischen Netzwerk befinden und mDNS-Traffic austauschen können.

Musterlösung anzeigen

Die drei wahrscheinlichsten Ursachen sind: Erstens eine fehlerhafte PPSK-zu-VLAN-Zuordnung – das Smartphone des Bewohners und der Chromecast verwenden möglicherweise unterschiedliche Passwörter und landen in unterschiedlichen VLANs. Diagnostizieren Sie dies, indem Sie die Client-Liste im UniFi-Controller überprüfen und bestätigen, dass sich beide Geräte im selben VLAN befinden. Zweitens wird mDNS innerhalb des VLANs nicht weitergeleitet (reflected) – selbst wenn sich beide Geräte im selben VLAN befinden, wird der mDNS-Traffic möglicherweise verworfen. Diagnostizieren Sie dies, indem Sie die Konfiguration des UniFi-mDNS-Repeaters überprüfen und sicherstellen, dass er für die Bewohner-VLANs konfiguriert ist. Drittens versehentlich aktiviertes Inter-VLAN-Routing – wenn Routing-ACLs falsch konfiguriert sind, können Geräte in unterschiedlichen VLANs teilweise kommunizieren, was zu inkonsistentem Verhalten führt. Diagnostizieren Sie dies, indem Sie die Konnektivität zwischen zwei Geräten in unterschiedlichen VLANs testen und bestätigen, dass sie sich nicht erreichen können.