Homelab-Umbau Teil 1: Die Ausgangslage

Worum es geht Link zu Überschrift

Mein Heimnetz ist gewachsen wie die meisten: Gerät dazu, läuft, fertig gedacht. Am Ende hing alles an einer Kiste und in einem Subnetz.

Das geht erstaunlich lange gut. Irgendwann wollte ich aber Sachen machen, für die in dem Aufbau schlicht kein Platz war — Geräte voneinander trennen, WLAN-Clients automatisch dahin schicken, wo sie hingehören, eigene Zertifikate ausstellen. Dafür braucht es eine andere Grundlage.

Diese Serie ist das Protokoll vom Umbau. Kein Hochglanz-Tutorial, sondern das, was es war: Entscheidungen, Sackgassen und ein paar Momente, in denen ich mich selbst ausgesperrt habe. Ich schreib das auf, weil ich beim Bauen genau sowas gesucht und selten gefunden habe.

Eins vorweg, weil es gern falsch verstanden wird: Was hier entsteht, ist kein Bastelnetz mit Bastelmethoden. Das sind dieselben Bausteine, die in Firmennetzen stehen — dedizierte Firewall, VLANs, 802.1X mit RADIUS, eigene PKI, Virtualisierung, Infrastructure as Code. Dazu unten mehr.

Wie es angefangen hat Link zu Überschrift

Am Anfang stand genau ein Gerät: ein Banana Pi BPI-R4 mit OpenWrt. Router, Switch und Access Point in einem. Dahinter ein Netz, 192.168.1.0/24, Gateway 192.168.1.1. Kein Server, keine Virtualisierung, keine Trennung.

Internet kommt über Init7 per Glasfaser. Das wird später wichtig, weil deren IPTV-Angebot TV7 über Multicast läuft — ein Detail, das mich beim Umbau einen ganzen Abend gekostet hat.

Was da alles drin hing Link zu Überschrift

Arbeit und Speicher

• Workstation (Desktop, per Kabel)
• Lenovo-Laptop
• Synology NAS
• Brother-Netzwerkdrucker

Mobile Geräte

• OnePlus 11
• OnePlus 3T
• iPhone X
• Nintendo Switch

Medien und Telefonie

• Marantz Cinema 50 (AV-Receiver)
• HTPC mit CoreELEC
• WLED-Controller auf ESP32 (QuinLED Dig-Uno)
• Yealink W70B (DECT-Basis)

Alles im selben Subnetz. Der Drucker kam ans NAS. Der ESP32 mit selbstgebauter Firmware kam an die Workstation. Die DECT-Basis kam an alles.

Was mich daran gestört hat Link zu Überschrift

Naheliegend wäre jetzt das Sicherheitsargument, aber ich will das nicht grösser machen, als es ist. Mir ist nichts passiert, und ich wohne allein — hier gibt es keine Mitbewohner mit Geräten, die ich nicht kenne. Das eigentliche Problem ist ein anderes:

Ich hätte gar nichts mitbekommen. In einem flachen Netz gibt es keine Stelle, an der Verkehr zwischen zwei Geräten vorbeikommt. Zwei Geräte im selben Subnetz reden direkt über den Switch — der Router sieht davon nichts. Wenn sich also ein Gerät merkwürdig verhält, erfahre ich es nicht.

Und “ich kenne meine Geräte” ist schwächer, als es klingt. Ich kenne die Hardware. Ich kenne nicht jede Firmware drauf, und schon gar nicht, was die nach Hause funkt.

Dazu die praktischen Nervereien:

• Der ESP32 ist ein Bastelding. Da landen regelmässig Entwicklungsstände drauf. Ein Gerät, dessen Firmware ich selbst zusammenbaue, hat neben meinen Backups nichts verloren.
• Gäste. Es gab keine Möglichkeit, jemandem WLAN zu geben, ohne ihm gleich das ganze Netz zu geben.
• Kein Puffer beim Basteln. Wenn der R4 alles ist, ist jede Änderung am R4 eine Änderung an allem. Ein Tippfehler nimmt nicht nur das WLAN mit, sondern Routing, DHCP und DNS gleich dazu.
• DECT-Basis ohne Telefonanlage. Das W70B hing als Insel im Netz. Ich wollte eigentlich eine richtige Anlage mit mehreren Trunks — dafür brauchte es erstmal einen Ort, wo sowas laufen kann.

Der naheliegende Fix, der keiner ist Link zu Überschrift

Bevor ich zur Architektur komme: ein Irrweg, den viele zuerst gehen. Für jede Gerätegruppe eine eigene SSID. Ein WLAN “Trusted”, eins “IoT”, eins “Gast”, jedes fest an ein VLAN geklebt. Klingt einfach, sieht erstmal aus, als würde es klappen — und skaliert überhaupt nicht.

Der Grund ist physikalisch, nicht logisch. Jede SSID ist für die Funkzelle ein eigener virtueller Access Point. Jede sendet ihre eigenen Beacons, ungefähr zehnmal pro Sekunde, und zwar auf der niedrigsten Basisrate — also so langsam wie möglich und damit besonders lange auf dem Kanal. Jede beantwortet ausserdem Probe-Requests von allem, was vorbeikommt.

Luftzeit ist aber ein festes Budget, das sich alle teilen. Was die Beacons fressen, steht für Nutzdaten nicht mehr zur Verfügung. Bei zwei SSIDs merkst du davon nichts. Bei fünf oder sechs verlierst du spürbar Durchsatz, und auf einem vollen 2,4-GHz-Kanal wird es richtig eklig. Die Faustregel aus der Praxis: höchstens drei SSIDs pro Funkband.

Dazu der Aufwand im Betrieb. Jede SSID braucht eigene Zugangsdaten, jedes Gerät muss beim Wechsel neu konfiguriert werden, und wer ein Passwort weitergibt, verschiebt gleich die ganze Vertrauensgrenze mit.

Firmen machen es andersrum: eine einzige SSID, und das Netz entscheidet pro Client. Das Gerät meldet sich per 802.1X am RADIUS-Server an, und der antwortet nicht nur mit ja oder nein, sondern schickt die VLAN-Zuordnung gleich mit. Handy landet in VLAN 20, Lichtcontroller in VLAN 41 — gleiche SSID, gleicher Access Point, das Gerät kriegt davon nichts mit. Ändert sich die Regel, änderst du einen Eintrag am RADIUS-Server, nicht zwölf Geräte.

Genau das bau ich hier nach.

Wo ich hinwill Link zu Überschrift

In einem Satz: Jedes Gerät soll genau so viel Netz sehen, wie es für seinen Job braucht — und keinen Meter mehr.

Konkret:

1. Routing und Switching trennen. Eine dedizierte Firewall macht Routing, DHCP, DNS und Regeln. Der R4 wird reiner VLAN-Switch und Access Point. Ein Gerät, eine Aufgabe.

2. Nach Vertrauen segmentieren, nicht nach Gerätetyp. Kein Sammel-VLAN “IoT”, in das am Ende alles reinwandert. Stattdessen ein VLAN pro Vertrauens-Situation: Was sich gegenseitig sehen muss, kommt zusammen, alles andere nicht. Mein Lichtcontroller und der HTPC müssen reden, weil die Ambientebeleuchtung dem Bild folgt. Also teilen die sich ein VLAN. Der Drucker hat da nichts zu suchen.

3. Automatisch statt von Hand. Eine SSID, 802.1X, dynamische VLAN-Zuweisung über RADIUS. Siehe oben.

4. Eigene Zertifikate. Interne Dienste sollen HTTPS ohne Browser-Warnung können. Also eine eigene CA, die per ACME automatisch ausstellt — dasselbe Protokoll wie bei Let’s Encrypt, nur nach innen.

5. Alles reproduzierbar. Am Ende soll die Konfiguration in Code stehen und nicht in meinem Kopf.

Das Zielbild Link zu Überschrift

Grob skizziert:

• Eine OPNsense auf eigener Hardware als Router und zentrale Regelinstanz
• Der BPI-R4 dahinter als VLAN-Switch und Access Point
• Ein Proxmox-Host für alles, was als VM oder Container läuft
• VLAN 20 für vertrauenswürdige Geräte
• VLAN 30 für Telefonie
• Eine 40er-Serie für alles Untrusted, ein VLAN pro Vertrauens-Situation
• FreeRADIUS für 802.1X mit dynamischer VLAN-Zuweisung
• step-ca als interne CA mit ACME
• WireGuard für unterwegs, damit ich fremdem WLAN nicht trauen muss
• Zentrale Identität über Samba AD beziehungsweise UCS/Nubus, statt in jedem Dienst eigene Benutzer zu pflegen
• Mobile Device Management, damit Konfiguration und Zertifikate nicht von Hand auf jedes Gerät wandern
• Sichtbarkeit in beide Richtungen: was passiert im eigenen Netz, und was klopft von aussen an

Warum das dieselbe Architektur ist wie in Firmen Link zu Überschrift

Sieht nach viel aus für eine Wohnung. Ist aber kein Selbstzweck und auch keine Homelab-Marotte — das ist der Standardaufbau eines Firmennetzes, nur klein:

Die Konzepte sind dieselben, nur die Herstellernamen andere. Wer 802.1X mit dynamischer VLAN-Zuweisung einmal zu Hause sauber zum Laufen gebracht hat — samt der Geräte, die sich querstellen — kennt genau die Stolpersteine, die im Firmennetz mit dreihundert Endgeräten auch auftauchen. Da hängt nur mehr dran.

Deshalb schreib ich das auch so ausführlich auf: Wenn du beruflich vor einem dieser Themen stehst, weisst du danach ziemlich genau, wie ich arbeite. Wie du mich erreichst, steht auf der Über-Seite.

Wie ich vorgehe Link zu Überschrift

Ich bau das nicht in einem Rutsch um. Die Reihenfolge ist so gewählt, dass nach jedem Schritt ein funktionierendes Netz dasteht.

Die vorderen Teile sind durchgeplant, die hinteren sind erstmal Absichten. Womit ich MDM mache, welche Engine die Verkehrsanalyse übernimmt, ob es bei Samba AD bleibt oder UCS wird — das leg ich fest, wenn ich da bin und die Randbedingungen kenne. Werkzeuge auf Verdacht aussuchen und sie dann in eine Architektur pressen, die sich inzwischen weitergedreht hat, bringt nichts.

Was ich zusage: Sobald es konkret wird, schreib ich nicht nur auf, was ich genommen habe, sondern auch, was ich verworfen habe und warum. Die Gründe dagegen sind beim Nachbauen oft nützlicher als die Entscheidung selbst.

Zwei Prinzipien, die sich früh herausgestellt haben und die sich durch die ganze Serie ziehen:

Immer einen Rückweg lassen. Ich hab an einem einzigen Tag zweimal die SD-Karte vom R4 neu geflasht, weil ich mich ausgesperrt hatte. Seitdem läuft vor jeder Netzwerkänderung ein Timer, der die alte Konfiguration nach 90 Sekunden zurückspielt, wenn ich ihn nicht vorher abbreche. Details in Teil 2.

Immer nur eine Sache gleichzeitig ändern. Wenn drei Dinge neu sind und es geht nicht, weisst du nichts. Wenn eine Sache neu ist, weisst du alles.

Weiter geht es Link zu Überschrift

Im nächsten Teil geht es um die Hardware für die OPNsense und um die Frage, wie man ein laufendes Netz umbaut, ohne es dabei zu zerlegen.

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