Freie Funker

von Markus Stubbig

WLAN-Controller – sei es als Hardware, VM oder Clouddienst – gibt es von jedem Anbieter. Leider ist es damit nicht möglich, Komponenten verschiedener Netzausrüster zu mischen. Dieser Artikel beleuchtet Open-Source-Controller, die mit WLAN-Basen unterschiedlicher Hersteller zusammenspielen, und zeigt deren Vorteile und Schwächen auf. Im Einzelnen schauen wir uns Cardinal, OpenWISP und OpenWiFi an.

Wer eine größere Anzahl von Access Points (AP) verwaltet, greift früher oder später zu einer Controller-Lösung eines namhaften Herstellers. Der Controller kommt als Hardware-Appliance, als virtuelle Maschine oder als Clouddienst. Er hat Zugriff auf alle APs und versorgt sie mit Firmware und Konfiguration. Als Gehirn kennt der Controller alle APs und Clients, kann die Kanalwahl übernehmen und wird so zum zentralen Punkt für Administration und Fehlersuche.

Aber: Der Controller von Hersteller A unterstützt nur Access Points von Hersteller A. Diverse IEEE-Standards regeln zwar die drahtlose Kommunikation, aber das gilt lediglich für die Luft zwischen Access Point und WLAN-Client. Im Backbone kann jeder Hersteller seine eigenen Protokolle basteln und seine APs damit steuern.

Für eine drahtlose Infrastruktur ohne Vendor-Lock-in gibt es in der Open-Source-Kiste nur wenige Alternativen. Dieser Artikel stellt drei Ansätze vor, die sich in ihrer Komplexität und den Möglichkeiten stark unterscheiden – siehe auch die Vergleichstabelle in diesem Artikel.

Wer hier keinen passenden Kandidaten für sich findet, kann sich bei den bekannten Automatisierungswerkzeugen wie Ansible oder Chef umsehen, die auch Plug-ins für diverse Hersteller von Access Points anbieten.

Cardinal

Der erste im Bunde ist zwar Open Source, hat aber die Access Points von Cisco im Auge. Cardinal [1] bietet eine Webseite, über die der Admin seine APs anlernen, SSIDs hinterlegen und schließlich APs über Gruppen mit SSIDs verknüpfen kann. Abgesehen vom einmaligen Hinzufügen aller Access Points ist die Webansicht einfach zu bedienen, da sie deutlich weniger Features mitbringt als die ausgewachsene Controller-Software desselben Herstellers.

Für das Deployment führt Cardinal vordefinierte Befehle im Betriebssystem der Access Points aus. Aus diesem Grund sind nicht alle APs von Cisco offiziell unterstützt, sondern nur diejenigen, die die Cardinal-Entwickler positiv getestet haben – und das sind nicht viele. Allerdings spricht nichts gegen weitere Geräte, solange sich die Schreibweise auf der Kommandozeile nicht verändert hat.

Cardinal kommt als klassische Webanwendung mit HTTP-Server und Datenbank – wahlweise nativ oder als Docker-Image. Im Hintergrund nutzt Cardinal das SSH-Protokoll, um sich mit den APs zu verbinden und seine Befehle abzusetzen. Bei diesem Push-Verfahren muss der Controller alle APs erreichen können. Befinden sich die teilnehmenden Geräte hinter einem DSL-Anschluss, benötigt das Setup einen NAT-Eintrag (keine gute Idee) oder einen VPN-Tunnel zum Controller-Standort.

Der Einsatzort von Cardinal sind Umgebungen mit Cisco-APs, die keinen Controller besitzen, aber ein zentrales Management wünschen (Bild 1). Cardinal eignet sich auch für die Betreuung von APs, die Cisco offiziell aus dem Programm geworfen hat. Denn viele Geräte fühlen sich nach dem End-of-Life-Datum noch technisch fit oder sind an Positionen verbaut, deren Austausch nur mit fiesen Kosten verbunden ist.

Achtung: Aktuell liegt das Cardinal-Projekt auf Eis und der Entwickler sucht einen Nachfolger. In dieser passiven Phase bleiben GitHub-Issues ungelöst. Wer dennoch zu Cardinal tendiert, sollte mit Python, Nginx und MySQL vertraut sein, um sich im Notfall selbst helfen zu können.

Insgesamt ermöglicht Cardinal eine schlichte webbasierte Verwaltung für ausgewählte Cisco-APs. Es verteilt SSIDs an die APs und sammelt statistische Informationen von den Geräten. Die Konfigurationsmöglichkeiten sind begrenzt, aber immer noch bequemer als pure IOS-Kommandos auf der SSH-Konsole. Im Gegensatz zur Controller-Software von Cisco übernimmt Cardinal keine Echtzeitaufgaben wie Roaming oder Kanalwahl. Wer Erfahrung mit einem Automatisierungssystem wie Ansible hat, für den bringt Cardinal kaum einen Mehrwert.

OpenWISP

OpenWISP [2] ist ein System zur Verwaltung von Netzwerkgeräten mit Schwerpunkt auf WLAN und VPN. Die Einschränkung liegt diesmal nicht beim Gerätehersteller, sondern beim verwendeten Betriebssystem: OpenWrt. Die Software ist kostenlos und richtet sich an Betreiber großer, OpenWrt-basierter Infrastrukturen. Ursprünglich war OpenWISP ein Verwaltungswerkzeug für WLAN-Umgebungen, daher der Name: Wireless Internet Service Provider (WISP).

Im Gegensatz zu Cardinal melden sich die OpenWrt-Geräte beim zentralen OpenWISP-Controller und erfragen ihre Konfiguration. Daher ist es prinzipiell kein Problem, die APs hinter NAT-Gateways und Firewalls zu betreiben. Lediglich für das Monitoring benötigt der Controller Zugriff auf seine WLAN-Schäfchen.

Die Bedienung der Webseite ist komplexer als bei Cardinal, da OpenWISP die angemeldeten Geräte in Organisationen unterteilt. Die gewünschte Konfiguration kommt über Templates auf die Geräte (Bild 2). Änderungen am Template bewirken eine Änderung der Konfiguration auf allen OpenWrt-Routern, die diesem Template folgen.

Ein neues Gerät meldet sich beim Controller mit einem Preshared-Key an. Anhand dieses Schlüssels erkennt der Controller die zugehörige Organisation und versorgt den Neuling mit den aktuellen Templates. Nach wenigen Minuten ist das Deployment abgeschlossen und der neue OpenWrt-Router ist ein vollwertiges Mitglied.

Der OpenWISP-Controller verteilt über die Templates auch die WLAN-Settings und sammelt Messwerte von den OpenWrt-Geräten ein. Die Werte kommen in eine Zeitserien-Datenbank und dienen im Webinterface als Charts für Paketverluste, Round-Trip-Time und CPU-/Speicherauslastung. Im Webmenü "Monitoring / Metrics" kann der Admin auf Metriken zugreifen und diese mit Alerts verknüpfen oder daraus ein Chart erstellen. Im einfachsten Fall erkennt der Controller den Gesundheitszustand und kann den Admin per E-Mail alarmieren.

Durch Plug-ins ist OpenWISP ausbaufähig. Der Hersteller bietet Erweiterungen für ein IP-Addressmanagement (IPAM) und wirkt damit dem Adresschaos in großen Umgebungen entgegen.

Das Firmware-Plug-in widmet sich Betriebssystem-Updates, was in einem bunten Hardwarezoo zur Herausforderung mutieren kann. Denn OpenWrt (und damit auch OpenWISP) unterstützt rund tausend verschiedene Modelle.

OpenWISP ist ein Konfigurationsmanager für OpenWrt mit Fokus auf WLAN. Unterstützt werden grundsätzlich alle Geräte mit WLAN-Antenne, die OpenWrt ausführen können. Ein laufendes OpenWrt lässt sich mit wenig Aufwand an den OpenWISP-Controller anlernen. Die Konfiguration liegt in Templates und wandert auf alle OpenWrt-Geräte, die dem Template folgen. Obendrein gibt es Plug-ins für Visualisierung, Monitoring und Zertifikatsverwaltung. Für die Fehlersuche bietet OpenWISP wenig, sodass sich der Admin mit den einzelnen WLAN-Geräten herumschlagen muss.

OpenWiFi

Das Telecom Infra Project hat sich zum Ziel gesetzt, mit OpenWiFi [3] eine Blaupause für eine WLAN-Infrastruktur zu entwerfen und mit Partnern umzusetzen. Das Konzept unterscheidet zwischen der Hardware für die Access Points und der dazugehörigen Software.

Damit folgt OpenWiFi der Netzwerk-Disaggregation, die bei Switches bereits Einzug gehalten hat und bei Servern schon länger existiert: Hersteller liefern Whitebox-APs ohne Betriebssystem, und OpenWiFi steuert ein Netzwerk-OS bei. Über gemeinsame Spezifikationen passen beide Komponenten zusammen und bilden die WLAN-Landschaft.

Zentrale Komponente ist der Cloud-Controller, der trotz seines Namens im eigenen Rechenzentrum schnurren darf. Er unterteilt seine Aufgaben in einzelne Prozesse, die über APIs kommunizieren. Einige Prozesse stellen Webinterfaces für die Konfiguration zur Verfügung. Hier sieht der Admin später seine APs, legt WLANs an und aktualisiert die Firmware aller Geräte.

Das erwähnte Betriebssystem für die APs ist ein modifiziertes OpenWrt. Das bedeutet nicht, dass jeder OpenWrt-Router bei OpenWiFi mitspielen darf. Nur wenn ein Hersteller mit seinen Geräten die Anforderungen erfüllt, kann er sein Produkt mit dem OpenWiFi-Aufkleber verkaufen. Zugegeben: Der Quellcode lässt sich auch an andere APs anpassen, kompilieren und aufspielen. Doch wenn im Tagesgeschäft Probleme auftauchen, gibt es keine Hilfe.

OpenWiFi existiert erst seit 2021 und die Liste der verfügbaren Geräte wächst. Leider bieten Hersteller wie Wallys nur ein Mainboard und keinen vollwertigen Access Point. Anbieter wie Indio Networks sind zwar zertifiziert, aber nicht auf dem europäischen Markt verfügbar oder verkaufen nicht an Endkunden.

Von den bekannteren Herstellern steuern Linksys, GL-iNet und Edge-Core zertifizierte Hardware bei, Letzterer bietet sogar den Controller as-a-Service an.

Installation als Docker-Container

Der Cloud-Controller kommt als Docker-Container ins Haus. Durch die Aufgabenteilung besteht das Setup aus insgesamt zehn Containern. Beispielsweise übernimmt ein Container die Weboberfläche, ein anderer die Kommunikation mit den APs und ein weiterer kümmert sich um die Firmware. OpenWiFi stellt passende compose.yml-Dateien bereit, die alle benötigten Images laden, die Container starten und dem Admin ein fertiges Setup übergeben:

Die Authentifizierung zwischen Access Point und Controller sowie zwischen den Containern erfolgt über Zertifikate. Dieser Ansatz verzichtet zwar auf Passwörter, erfordert aber eine ausgewachsene PKI, die alle Komponenten mit Zertifikaten ausstattet.

Die Demoinstallation per "compose.yml" kommt mit Zertifikaten, die das Telecom Infra Project ausgestellt hat. Ein offizieller OpenWiFi-AP besitzt ein passendes Clientzertifikat und kann sich dem Controller anschließen. Aber mit eigenen APs oder einem selbst kompilierten OpenWrt funktioniert das nicht, da das Zertifikat fehlt. Wer die Infrastruktur in Eigenregie aufziehen will, kommt um die eigene PKI nicht herum. Als Starthilfe gibt es unter [4] ein inoffizielles Bash-Skript, das die Container und einen AP mit dem nötigen Kryptomaterial versorgt.

Auf der Seite der Access Points ist das Deployment übersichtlich: modifiziertes OpenWrt aufspielen, Zertifikat nachschieben, IP-Adresse oder Name des Controllers eintragen, fertig. Das OpenWiFi-Projekt stellt fertige OpenWrt-Images zur Verfügung [5], allerdings nur für unterstützte Geräte. Für alle anderen muss der Compiler ran.

Sobald das Image auf der Hardware läuft, erfährt der AP über die folgenden Befehle von seinem Controller:

Der Name des Controllers muss auflösbar sein; entweder per DNS oder über die lokale /etc/hosts-Datei. Eine Registrierung wird noch nicht erfolgreich sein, da der AP kein Zertifikat für die Anmeldung besitzt. Der letzte uci-Befehl gibt die Seriennummer aus, die im Zertifikat enthalten sein muss, beispielsweise e89f80fd9eca. Dies ist auch die MAC-Adresse des ersten Netzadapters.

Das für den AP ausgestellte Zertifikat und der private Schlüssel müssen "cert.pem" und "key.pem" heißen und im Dateisystem unter "/etc/ucentral" liegen. Die Zertifikate der Root-CA und Intermediate-CA kommen in die Datei "cas.pem". Damit hat der Access Point alle Informationen und kann sich nach einem Neustart beim Controller vorstellen.

Hierarchischer Konfigurationsbaum

Die Weboberfläche des Controllers ist unter "https://openwifi.wlan.local/" erreichbar. Die erste Anmeldung erfolgt mit dem Benutzer "tip@ucentral.com" und dem Kennwort "openwifi". Im besten Fall wartet der neue Access Point bereits im Menü "Devices". Dort zeigen sich auch Informationen über das Modell, die CPU- und Speicherauslastung sowie die Version (Bild 3).

Die WLAN-Konfiguration verbirgt sich hinter der Webseite "https://openwifi. wlan.local:8443", die intern den Provisioning-Container erreicht. Im Abschnitt "Entities" entsteht ein hierarchischer Konfigurationsbaum, der von der Top-Entity über beliebig viele Untereinträge verschachtelt ist. Dabei gilt: Der untere Eintrag erbt die Einstellungen der oberen Einträge entlang bis zur Spitze. Die Access Points sind Mitglieder einer Entity und erhalten ihre finale Konfiguration durch Verschachtelung und Vererbung (Bild 4). Das Ganze funktioniert ähnlich wie die Gruppenrichtlinien im Microsoft Active Directory.

Die Entity-Landschaft ist zunächst leer. Nun gilt es, die eigene WLAN-Infrastruktur so in Entities abzubilden, dass am Ende die perfekte Konfiguration für jeden AP entsteht. Wenn alle Access Points identisch sind, reicht eine einzelne Entity für alle. Aber vielleicht gibt es im Eingangsbereich ein Gäste-WLAN, in den Verkaufsräumen ein Funknetz für Barcodescanner und im Produktionsbereich ein WLAN für Industrie 4.0.

Die daraus resultierenden Einstellungen für einen AP verrät dieser im Bereich "Inventory" unter "Computed Configuration". Und selbst hier lässt sich unter "Device-Specific Configuration" noch nachbessern, bis die finale Konfiguration passt.

OpenWiFi ist wie ein Pizza-Kit: Es kommt mit einer Grundlage plus Anleitung, aber der Ausbau und die Gestaltung sind Eigenleistungen. Der Pizza-Admin erhält einen WLAN-Controller und eine Auswahl an zertifizierten Access Points. Leider sind erst wenige Anbieter auf den Zug aufgesprungen, sodass die Auswahl an Hardware überschaubar ist. Wer eine größere WLAN-Infrastruktur plant und sich Open Source zutraut, sollte OpenWiFi ernsthaft in Erwägung ziehen.

Vergleich zu Profi-Controllern

OpenWiFi und OpenWISP sind keine schlüsselfertigen Lösungen und setzen eine gewisse Bereitschaft zum Tüfteln und Ausprobieren voraus. Demgegenüber stehen die professionellen Controller namhafter Netzausrüster. Doch was macht den hohen Anschaffungspreis aus? Zunächst einmal gibt es bei Cisco, HPE und Co. zu allen Produkten eine ausführliche Dokumentation, Schulung und Support.

Die kommerziellen Anbieter lassen ihre Kunden nicht im Regen stehen und helfen bei kniffligen Situationen mit Konfiguration und notfalls auch mit einem Hotfix.

Apropos Dokumentation: Hier ist meist klar geregelt, wie viele Access Points ein Controller unterstützt und wie viele Clients sich maximal an einem Access Point tummeln können. Beispielsweise akzeptiert ein Cisco 5508 WLC genau 500 Access Points und keinen mehr. Das sind keine böswilligen Begrenzungen des Herstellers, sondern klare Angaben zur Skalierung, mit denen der Kunde rechnen und seine WLAN-Landschaft planen kann.

Beim Rollout von vielen WLAN-Geräten spart das Zero-Touch-Provisioning (ZTP) viel Zeit, denn am Access Point ist tatsächlich keine händische Änderung nötig: auspacken, Netzwerkkabel rein, warten, fertig. Im Hintergrund fragt der AP per DNS nach seinem Controller, meldet sich dort und erhält Firmware plus Konfiguration. Bei OpenWiFi ist ZTP möglich, sobald das Gerät mit passender Firmware und Zertifikaten ausgestattet ist.

Neben Support und Deployment punkten die kommerziellen Controller mit einem ausgeklügelten Radio Resource Management (RRM). Dabei nutzt der Controller seine zentrale Position: Da sich die Access Points gegenseitig "sehen", weiß der Controller, welche Geräte benachbart sind. Er weist die APs an, auf welchem Kanal und mit welcher Sendeleistung sie funken sollen, um den Campus bestmöglich auszuleuchten und mit minimalen Überlappungen auszukommen.

Die kommerziellen Anbieter nehmen ihren Kunden Arbeit ab und bieten Unterstützung und Zuversicht bei der Wahl ihrer Produkte. Im Gegenzug erwarten sie einen hohen Anteil des Budgets mit laufenden Kosten für Support und Softwareupdates. Ob Open Source oder eine schlüsselfertige Lösung die bessere Wahl ist, hängt letztlich auch davon ab, wie geschäftskritisch das WLAN ist, wie viel Zeit das IT-Team aufbringen kann und wie hoch die Investition sein darf.

Fazit

Viele WLAN-Router verwenden das kostenlose und quelloffene Linux. Doch beim WLAN-Controller hört der Spaß auf. Hier greifen die Anbieter zwar auch auf Linux zurück, aber der Quellcode bleibt als Firmengeheimnis unter Verschluss.

Dem wollen Cardinal, OpenWISP und OpenWiFi entgegenwirken und stellen ihre Managementsoftware für WLAN-APs als Open Source zur Verfügung. Cardinal ist auf Cisco-Geräte spezialisiert und OpenWISP steuert alles, was unter OpenWrt läuft. OpenWiFi ist bei der Hardware wählerisch und liefert dafür viele Features aus der Profiklasse.

	Cardinal	OpenWISP	OpenWiFi
Untersuchte Version	2.1	1.0.3	3.0.0
Verfügbar seit	2017	2017	2021
Konfiguration via	Web	Web/API	Web
Komplexität bei der Einrichtung	niedrig	mittel	hoch
Access Points	Cisco	OpenWrt	2)
Open Source	MIT	GPLv3	BSD-3
Native / Docker	✓/✓	✓/✓ 1)	✓/✓
IPv6	—	✓	✓
Kommerzieller Support	—	✓	—
Firmware Update	—	✓	✓
Zero-Touch-Provisioning	—	—	✓
Statistik/Charts	—	✓	✓
1) Das Docker-Image ist experimentell. 2) Ausgewählte Modelle von Anbietern, die sich am OpenWiFi-Projekt beteiligen

Quelloffene WLAN-Controller