[FFS] Ubiquiti: Allgemeine Fragen zum Controller - Konfigurationstipps aus dem Maillepark

Thomas Rother t.rother at netzwissen.de
Fr Aug 31 23:19:30 CEST 2018


Hallo zusammen,

Patrick hat nach meinen Argumenten *gegen* den Betrieb eines Unifi
Controllers innerhalb des Freifunk Netzes für das Freifunk Esslingen
Projekt gefragt:

Üblicherweise werden WLAN Controller und APs im gleichen Layer 3
(kleines, privates Netz mit "trusted clients") oder Layer 2 (gross) Netz
betrieben, also dort, wo die Latenzen und das Risiko der Netztrennung
geringer sind. Ggf. verbindet man sie über Routen oder VLANs. Das ist
der vom Hersteller empfohlene Weg
(https://dl.ubnt.com/guides/UniFi/UniFi_Controller_V4_UG.pdf).

Der Betrieb des Controllers "off-site" ist prinzipiell möglich, aber
eher nicht die erste Wahl - speziell im Freifunk Fall ("kann man machen,
ist dann halt k... ;-)   ). Ein Controller als steuernde Instanz einer
WLAN Infrastruktur sollte schon aus Sicherheitsgründen netz-technisch
getrennt von dem Netz sein, in dem die Endanwender arbeiten. Bei Unifi
wird der Traffic der WLAN SSIDs auf Wunsch separat vom lokalen
Betriebsnetz transportiert (z.B. per tagged VLAN oder - in Verbindung
mit einer USG - über ein eigenes VPN). Dass man Standort-APs in einem
lokalen (privaten) Netz hat, aber der sie steuernde Controller in einem
öffentlichen Netz (Freifunk) steht, ist technisch möglich (wenn man alle
nötigen Firewall und Routing Regeln zusammen hat). Es ist aber weder
"best practice" noch sicherheitsmässig ideal. Ich finde es ungeeignet
für den Betrieb durch Ehrenamtliche, die nur selten "Netz-Experten" sind
(>> "keep it simple").

Der UCK (Ubiquity Cloud Key) ist dagegen eine Lösung für ca. 80 €, die
"out of the box" funktioniert und leicht skalierbar ist. Hängt man den
Ubuntu-basierten Controller ins gleiche Layer 2/3 Netz wie die APs,
funktioniert die Adoption der APs problemlos und ohne irgendwelche
Freischaltungen und Spezialrouten. Falls der Uplink - warum auch immer-
ausfällt, arbeiten Controller und APs weiter (Ausfallsicherheit). Über
die "wireless uplink" Funktion kann man Ketten mehrerer Unifi APs am
gleichen Controller/Uplink bilden, ohne daß jeder davon eine LAN Leitung
braucht (Strom braucht man, per PoE oder Injektor). Dieses Meshing nutzt
dynamisch alle 5 GHz Kanäle, nicht nur den (störanfälligen) Kanal 1/2,4
GHz, wie beim FF Meshing. "Wireless uplinks" funktionieren bei mir an
zwei Standorten schon recht stabil, obwohl es von Seiten Ubiquity noch
als "beta" gekennzeichnet ist (das gesamte IPv6 Routing ist übrigens
noch im "alpha" Stadium).

Hybrid Cloud Ansatz: verschiedene lokale Unifi Controller können bei
Ubiquity über ein gemeinsames Administrationskonto auf
https://account.ubnt.com aus der Ferne verwaltet werden. Die Verbindung
zwischen dem UBNT Konto und dem lokalen Controller läuft über
WebRTC/STUN und ist auch aus geNATteten Netzen heraus hinreichend
sicher. Ich benutze sowohl zuhause als auch in der Villa Nagel  UCK
Instanzen, de über ein UBNT Konto gemeinsam aus der Ferne steuerbar
sind. Im Gegensatz zum Login am UCK oder virtualisierten Controller wird
auf dem UBNT Konto (der account.ubnt.com Service läuft in einer AWS
Cloud) zur Authentifizierung zusätzlich 2FA angeboten. Zur Zeit nur über
Google Authenticator, andere Wege wie U2F mit Yubikey usw. sind in
Vorbereitung.

Das ist der Weg, den ich für jene FFES Standorte empfehlen würde, die
einerseits "Betriebs-kritisch" sind und die andererseits für den Betrieb
von mehreren Unifi APs in Frage kommen (in Esslingen potentiell z.B.
Musikschule, Tiefbauamt, Lux, evtl. Carpe Diem mit Provinzbuch als
weiterem Standort per Wireless Uplink). Für VLAN braucht man ggf. einen
passenden Switch, aber das ist heute auch schon ab 30 € zu haben.

Ein UCK mit der von Holger empfohlenen und in der Maille getesteten
Konfig läuft in meiner Testumgebung zusammen mit einem adoptierten UAP.
Noch nicht fertig ist die VLAN Anbindung auf der LAN-Seite des FF
Routers (>> Switch Konfiguration nach
https://wiki.openwrt.org/doc/uci/network/switch). Sobald das erledigt
ist, werden sowohl die private wie auch die Freifunk SSID über dieselbe
Infrastruktur in 2,4 und 5 GHz ausgesendet (inkl. Roaming, DFS/TPC und
anderen Controller-typischen Funktionen), aber trotzdem auf der
Uplink-Seite getrennt geroutet.

Gruss, Thommie


Am 18.08.18 um 17:39 schrieb Holger Adams:

> Hallo Zusammen,
>
> On 18.08.2018 16:28, Alexander Bourgett wrote:
>> Danke für die Unterstützung. So ein Controller würde uns echt helfen.
>>
>> Können wir aus Esslingen irgendwas unterstützen beim Aufsetzen des
>> Controllers bzw. was brauchst Du von uns oder den bereits ausgerollten
>> Ubiquity APs?
>>
>> Gruß,
>> ALex.
>>
>>
>
> Im Anhang die Konfiguration der Maillepark APs (diese sind privat
> gesponsort und bleiben auf meinem Controller), mit welcher wir seit
> einigen Monaten sehr gute Erfahrung (Reichweite vs. Kapazität) gemacht
> haben. Anstürme von ~200 Client gingen mit 2 APs gut durch, haben aber
> einiges an Konfguration gebraucht. Wäre klasse, wenn wir ein halbwegs
> einheitliches Setup hätten und ihr auf unserem aufbauen könntet.
>
> Grundsätzliche Hinweise:
>  - Alle APs sollten eine aktuelle Firmware haben. Diese hatten früher
> DFS/TPS Probleme (Sprung auf interne Kanäle)
>  - mit VHT40/VHT80 sollte man bei den UAP-AC-M aufpassen. Die
> Warscheinlichkeit, in eine DFS/TPS Detection reinzurutschen steigt
> katastrophal an. Ausgelöst von halb kaputten Smartphones. VHT20 ist
> 100% stabil.
>  - Nutzt alle, nicht-überschneidente Kanäle die uns die EU bietet (1,
> 5, 9, 13). Kanal 13 tut mittlerweile fast überall.
>
> Konfiguration
>
> Radios
>  - 2.4 GHz Channel Bandwidth: VHT20
>  - Transmit Power: 20 dBm
>  - Antenna Gain: Standard Included (damit halten wir in Summe
> automatisch das Gesetz ein)
>
>  - 5 GHz Channel Bandwidth: VHT20
>  - Transmit Power: 20 dBm
>  - Antenna Gain: Standard Included (damit halten wir in Summe
> automatisch das Gesetz ein)
>
> Bandsteering
>  - Off
>
> /(Eingeschaltetes Bandsteering führt bei Android zu sehr merkwürdigem
> Verhalten und schlechtem User Experience! Man denkt, das Smartphone
> verbindet sich nicht! Siehe auch unten: mit eingestellten
> Mindestdatenraten kann man die Smartphones viel besser "zwingen" zu
> wechseln)//
> /
> Airtime Fairness
>  - Off
>
> /(Airtime Fairness funktioniert nur bei sehr wenigen Clients
> akzeptabel, danach bricht es schlagartig ein. Unbedingt abgeschalten
> lassen)/
>
> /Auf //*keinen Fall*//irgendwelche Minimum RSSI Geschichten setzen!
> Anhand der zentral einstellbaren, erlaubten Transferraten lässt sich
> die Reichweite sehr viel besser limitieren.//
> /
> Zentrale Controller Optionen
>
> Advanced Options
>  - Enable Unscheduled Automatic Power Save Delivery: Aktiv
>  - Enable Multicast enhancement (IGMPv3): Aktiv
>
> 802.11 Rate and Beacon Controls
>
> 2G Data Rate Control:
>  - Enable Minium data rate control: Aktiv
>     * Mindestrate: 9 Mbps
>     *  Disable CCK rates (1/2/5.5/11Mbps): Aktiv
>     *  Also require clients to use rates at or above spec. value: Aktiv
>     *  Send beacons at 1 Mbps: Off *(GANZ WICHTIG!)*
>
> 5G Data Rate Control
>  - Braucht man nicht aktivieren, da hier sowieso mehr Kapazität und
> die Mindestrate 6Mbps hat)
>
> /(Damit zwingt man die 2.4 GHz Client quasi "freundlich" anhand der
> aktuellen Funkqualität ins 5 GHz Netz.. ganz ohne "Force 5G" und "Min
> RSSI"/
>
>
> Grüße,
> Holger

-- 

-----------------------------------------------------------------
*        Thomas Rother -- D-73728 Esslingen, Germany, EU        *
*       Mail: t.rother at netzwissen.de - Threema: XDA7SKFP        *
*      PGP: 4FE2 9E90 B395 A4D3 8BA3 4A3B 1A09 9D9C 857D 9907   *
*   Owncloud Federation: thommie3 at www.netzwissen.de/owncloud    *
-----------------------------------------------------------------




Mehr Informationen über die Mailingliste Misc