Homelab-Umbau Teil 7: Eine SSID, und das Netz entscheidet

Worum es geht Link zu Überschrift

In Teil 1 stand die Feststellung, dass eine eigene SSID pro VLAN nicht funktioniert — jede SSID kostet Luftzeit, und bei fünf oder sechs verliert man spürbar Durchsatz.

Die Alternative ist die, die in Firmen läuft: eine einzige SSID, und das Netz entscheidet pro Gerät. Das Gerät meldet sich mit eigenen Zugangsdaten an, ein RADIUS-Server prüft sie und schickt die VLAN-Zuordnung gleich mit.

Das ist der Teil, auf den der ganze Umbau hinausläuft. Und es ist der Teil, der mich mit Abstand am meisten Zeit gekostet hat.

Vorher: die VLAN-Struktur festlegen Link zu Überschrift

Bevor irgendwas zugewiesen werden kann, muss klar sein, wohin.

Meine Nummerierung folgt der Vertrauensstufe, nicht dem Gerätetyp. Der Vorteil: Man sieht der Adresse an, wo sie hingehört.

Die Handys stehen bewusst in der 40er-Reihe. Sie sind mehr wert als der Drucker und weniger als der Arbeitsrechner — ein Handy ist ständig in fremden Netzen unterwegs, und es enthält Apps, deren Verhalten ich nicht kontrolliere.

Der Trick beim Umbau Link zu Überschrift

Ursprünglich lag alles in einem einzigen VLAN. Naheliegend wäre gewesen, die Server in ein neues Segment umzuziehen. Das hätte aber bedeutet, sämtliche Verweise nachzuziehen: ACME-Adressen, Backup-Ziele, DNS-Einträge, Reservierungen.

Also andersherum: die Clients wegziehen und die Server stehen lassen. Aus dem alten Sammel-VLAN wird das Server-Segment durch Abwanderung. Kein einziger Verweis musste angepasst werden.

Der eigentliche Gewinn ist dabei ein anderer, und der war mir wichtiger als die saubere Nummerierung: Das native VLAN ist am Ende leer. Wer ein unbekanntes Gerät irgendwo einsteckt, landet nicht mehr bei meinen Servern.

Wie die Zuweisung funktioniert Link zu Überschrift

Jedes Gerät bekommt eigene Zugangsdaten, nicht einen gemeinsamen Schlüssel. Auf dem RADIUS-Server steht pro Gerät ein Eintrag mit drei Attributen, die zusammen die VLAN-Zuweisung ausmachen:

htpc-coreelec Cleartext-Password := "..."
    Tunnel-Type = "VLAN",
    Tunnel-Medium-Type = "IEEE-802",
    Tunnel-Private-Group-Id = "42"

Der praktische Nutzen: Ändert sich die Richtlinie, ändere ich einen Eintrag auf dem Server. Nicht zwölf Geräte. Und wenn ein Gerät weg soll, lösche ich seinen Eintrag — der Rest bleibt unberührt.

Was schiefging Link zu Überschrift

Vier Probleme, und keins davon steht in den Anleitungen, die ich vorher gelesen hatte.

Die Datei, die nie gelesen wird Link zu Überschrift

Das hier hat mich am längsten aufgehalten, und im Nachhinein ist es ärgerlich einfach.

Ich hatte meine Geräteeinträge in /etc/freeradius/3.0/users gepflegt. So steht es in praktisch jeder Anleitung im Netz. Der Server fand die Einträge auch — im Debug-Log stand sauber Matched entry htpc-coreelec at line 47.

Nur lieferte er hartnäckig die falsche VLAN-Nummer aus. Ich habe den Dienst zehnmal neu gestartet, die Datei mehrfach kontrolliert, nach doppelten Einträgen gesucht.

Bei FreeRADIUS 3 wird users gar nicht gelesen. Die Datei ist ein Überbleibsel aus Version 2, das die Distributionspakete aus Kompatibilitätsgründen noch mitliefern. Gelesen wird /etc/freeradius/3.0/mods-config/files/authorize.

Nachprüfen lässt sich das in einer Zeile:

grep filename /etc/freeradius/3.0/mods-enabled/files

Dort steht filename = ${moddir}/authorize — und moddir zeigt nach mods-config/files/.

Weil beide Dateien identisch gross waren und der Server die Einträge scheinbar fand, sah alles richtig aus. Ich habe die tote Datei inzwischen umbenannt, damit ich nicht wieder danebengreife.

Attribute, die im Tunnel steckenbleiben Link zu Überschrift

Der zweite Fall war subtiler. Im Debug-Log lieferte der innere PEAP-Tunnel die VLAN-Attribute korrekt — im finalen Access-Accept an den Access Point fehlten sie.

PEAP hat zwei Ebenen: einen äusseren, anonymen Teil und einen inneren, verschlüsselten, in dem die eigentliche Anmeldung stattfindet. Attribute aus dem inneren Tunnel werden nicht automatisch nach aussen durchgereicht. Der Access Point sieht nur die äussere Antwort — und die war leer.

Der Schalter dafür steht in der EAP-Modulkonfiguration, im peap-Block:

use_tunneled_reply = yes

Danach standen die drei Attribute im finalen Access-Accept, und der Access Point wusste zum ersten Mal, wohin mit dem Gerät.

Zwei Modelle, die nicht zusammenpassen Link zu Überschrift

Jetzt lieferte der Server korrekt, der Access Point verstand es — und die Geräte landeten trotzdem im falschen Netz.

Der Grund ist ein Architekturkonflikt, den man erst sieht, wenn man beide Seiten kennt.

hostapd baut pro VLAN eine eigene Bridge. Das ist das klassische Modell aus einer Zeit, als Bridges keine VLANs kannten. Für jedes zugewiesene VLAN legt es ein Interface an, erzeugt eine Bridge und hängt einen getaggten Uplink dazu.

Aktuelles OpenWrt macht es andersherum: eine einzige Bridge mit VLAN-Filterung und einer Tabelle, welcher Port welche VLANs führt.

Beide Modelle beschreiben dasselbe Ziel und sind trotzdem unvereinbar. Im Log sah das so aus:

VLAN: vlan_add: ADD_VLAN_CMD failed for br-lan: File exists
VLAN: br_addif: ... failed for br_name=br-lan.41: Symbolic link loop

hostapd wollte ein Interface anlegen, das die Bridge schon führte, und sich anschliessend selbst in sich hineinhängen.

Die Brücke zwischen beiden Welten ist ein kleines Hotplug-Skript. Es greift, wenn hostapd ein VLAN-Interface erzeugt, hängt es in die richtige Bridge und trägt die passende VLAN-Zuordnung ein:

[ "$ACTION" = "add" ] || exit 0
case "$DEVICENAME" in
  *-ap*.*)
    VID="${DEVICENAME##*.}"
    [ "$VID" -gt 1 ] 2>/dev/null || exit 0
    ip link set "$DEVICENAME" master br-lan
    bridge vlan add dev "$DEVICENAME" vid "$VID" pvid untagged
    bridge vlan del dev "$DEVICENAME" vid 1
    ip link set "$DEVICENAME" up
    ;;
esac

Das Schöne daran: Es ist generisch. Jedes künftige VLAN funktioniert ohne weiteres Zutun.

Der Fehler, der wie ein Client-Problem aussieht Link zu Überschrift

Und dann noch einer, der mich einen ausgebauten Mediaplayer gekostet hat.

Nach mehreren Runden Konfigurieren kam mein HTPC in kein WLAN mehr — auch nicht ins alte. Keine Passwortabfrage, nur eine Fehlermeldung. Ich habe das Gerät ausgebaut, die Speicherkarte an den Rechner gehängt und Konfigurationsdateien gelöscht.

Der Fehler lag am Access Point:

STA ... IEEE 802.11: authenticated
STA ... IEEE 802.11: Could not set STA to kernel driver

Der WLAN-Treiber hatte sich nach mehreren Neustarts des Funkdienstes verhakt. Ein Neustart des Access Points hat es behoben — ein wifi down; wifi up reichte nicht, weil der Treiber selbst betroffen war.

Die Lehre: Wenn ein Client nicht mehr verbindet, zuerst ins Log des Access Points schauen, nicht ins Gerät. Hätte ich das früher gemacht, wäre mir die Schrauberei erspart geblieben.

Was Geräte können und was nicht Link zu Überschrift

Am Ende zerfallen die Geräte in drei Gruppen.

Es funktioniert einfach. Handy und Laptop. Zugangsdaten eintragen, verbinden, fertig. Beim Handy sollte man zusätzlich eine anonyme Identität setzen, sonst steht der Benutzername unverschlüsselt im Klartextteil der Anmeldung.

Es funktioniert mit Aufwand. Mein Mediaplayer läuft mit CoreELEC und verwaltet sein Netzwerk über connman. Der bietet keine Oberfläche für 802.1X — aber er liest Konfigurationsdateien:

[service_olient]
Type = wifi
Name = mein-ssid
EAP = peap
Phase2 = MSCHAPV2
Identity = htpc-coreelec
AnonymousIdentity = anonymous
Passphrase = ...

Das funktioniert, ist aber unangenehm zu handhaben. Jede Änderung trennt die Verbindung, über die man gerade arbeitet. Wer sowas per SSH macht, sollte vorher einen Timer anlegen, der die Konfiguration nach ein paar Minuten zurücksetzt und das Gerät ins alte Netz zurückholt — dasselbe Prinzip wie das Failsafe-Muster aus Teil 3.

Es funktioniert gar nicht. Mein Lichtcontroller läuft mit WLED. Die Release Notes zur aktuellen Version führen 802.1X-Unterstützung als neues Feature auf. In der Oberfläche gibt es dafür aber keine Felder.

Die Erklärung fand sich im zugehörigen Pull Request: Die Funktion wurde umgesetzt und zusammengeführt — und dann bewusst hinter einen Compile-Schalter gelegt, weil sie über 100 KB Flash kostet. Sie ist in keiner veröffentlichten Binärdatei aktiviert.

Das ist kein Fehler der Software, sondern eine nachvollziehbare Abwägung. Aber es steht so in keinen Release Notes, und ich habe zwei Stunden gesucht, bevor ich im Pull Request nachgelesen habe.

Die Lehre für alle drei Gruppen: Vor dem Umbau prüfen, welche Geräte 802.1X überhaupt können. Und für die, die es nicht können, eine zweite SSID mit klassischem Schlüssel einplanen, die fest in einem Untrusted-VLAN endet.

Wo ich jetzt stehe Link zu Überschrift

Eine SSID, mehrere Geräte, jedes mit eigenen Zugangsdaten, jedes im passenden Netz. Handy und Mediaplayer sind vollständig getrennt, obwohl sie sich denselben Access Point und dieselbe SSID teilen.

Was offen bleibt: Die Firewall-Regeln in den neuen VLANs stehen noch auf Durchlass. Sie zu verengen ist der nächste Schritt — und erst dann wird aus der Trennung auch eine Sicherheitsgrenze.

Nächster Schritt Link zu Überschrift

Bevor es an die Regeln geht, kommt noch ein Baustein, der das Leben angenehmer macht: eine eigene Zertifizierungsstelle. Damit interne Dienste HTTPS können, ohne dass der Browser bei jedem Aufruf meckert.

Teil einer Serie über den Umbau meines Heimnetzes. Stand: August 2026. Fragen, Korrekturen und eigene Erfahrungen gerne in die Kommentare.