Home Assistant: Container auf dem vorhandenen Server — und kein IoT-VLAN

Worum es ging: Bevor ich Home Assistant überhaupt anfasse, standen zwei Vorentscheidungen an, die sich nachträglich nur teuer ändern lassen. Wo läuft es — als eigenes Betriebssystem auf eigener Hardware, als virtuelle Maschine oder als Container? Und braucht es vorher ein getrenntes Netz für die Smart-Home-Geräte?

Die Vorgeschichte, warum es überhaupt Home Assistant wird und nicht etwas Selbstgebautes, steht in Home Assistant oder alles selbst bauen?.

Entschieden: Container auf dem vorhandenen Server #

Dafür: Kein neuer Technologie-Stack. Eine Virtualisierungsschicht gäbe es bei mir sonst nirgends — die nur für diesen einen Dienst einzuführen, wäre ein dauerhafter Wartungsposten. Als Container passt es dagegen in genau das Muster, in dem bei mir alles andere auch läuft, und wird vom vorhandenen Monitoring automatisch mit erfasst. Ressourcen sind reichlich da.

Bewusst in Kauf genommen:

Kein Add-on-Ökosystem. Das gibt es nur mit dem vollen Home Assistant OS. Für meinen ersten Testlauf reichen die eingebauten Integrationen.
Kein eingebauter Backup-Manager.
Schicksalskopplung: Wenn ich auf dem Server eine ganz andere Anwendung aktualisiere und dabei etwas schiefgeht, ist die Haussteuerung mit weg.

Der Revisionspunkt — und das ist mir wichtiger als die Entscheidung selbst: Sobald Funkhardware für Zigbee, Thread oder Matter dazukommt, oder sobald Heizung und Anwesenheitserkennung wirklich daran hängen, wechsle ich auf eigene Hardware mit Home Assistant OS. Nicht auf eine VM. Kritische Haustechnik soll nicht neu starten, weil auf einem Anwendungsserver eine App aktualisiert wird. Der Ausstieg bleibt offen, weil sich ein Backup aus der Container-Variante in Home Assistant OS einspielen lässt.

Entschieden: kein IoT-VLAN, vorerst #

Die Lehrbuchantwort lautet: Smart-Home-Geräte gehören in ein eigenes, abgetrenntes Netz. Ich mache das trotzdem nicht — jedenfalls jetzt noch nicht.

Der Grund ist keine Faulheit, sondern Hardware. Ein getrenntes WLAN für IoT-Geräte ist im Heimnetz keine reine Konfigurationsfrage. Man braucht einen Access Point, der mehrere WLAN-Namen auf getrennte VLANs legen kann, und einen Switch, der die VLANs weiterreicht. Fehlt eines von beidem, gibt es kein getrenntes WLAN — egal wie gut die Firewall konfiguriert ist. Bei mir fehlt beides, und ich wollte den Testlauf nicht an einer Bestellung aufhängen.

Stattdessen geplant: Feste Adressreservierungen für die betreffenden Geräte plus eine Firewall-Regel, die genau dieser Gruppe den Weg ins Internet sperrt. Das nimmt den größten Teil des Risikos — Geräte dieser Art brauchen für die lokale Steuerung kein Internet — kostet nichts und ist jederzeit reversibel. Umgesetzt ist beides zum Zeitpunkt dieses Eintrags noch nicht; solange ist der Verzicht auf ein getrenntes Netz nicht abgefedert, sondern nur aufgeschoben.

Die ehrliche Grenze: Geräte untereinander bleiben im flachen Netz ungefiltert. Dieser Verkehr passiert den Router nie und kann dort auch nicht gefiltert werden. Wer das braucht, kommt an getrennten Netzen nicht vorbei. Wie weit man mit einer FritzBox in Richtung VLAN überhaupt kommt, steht im Guide VLAN trotz FritzBox.

Revisionspunkt: wachsende Gerätezahl — oder ein managed Switch, der ohnehin ansteht.

Was ich dabei korrigiert habe #

Ich hatte vorher notiert: „Netzsegmentierung unbedingt vor dem Onboarding entscheiden." Das gilt für viele Geräte, nicht für eine Handvoll. Ein nachträglicher Umzug ins andere Netz kostet ein Neuverbinden pro WLAN-Gerät. Bei kleiner Stückzahl ist das vertretbar, und deshalb blockiert es den Testlauf nicht mehr.

Offener Blocker, den ich nicht wegdiskutiere: Für den Server, auf dem das Ganze läuft, existiert bei mir noch kein dokumentiertes Backup-Konzept. Das muss geklärt sein, bevor Home Assistant produktiv Haustechnik trägt — nicht erst danach. Wie so ein Konzept aussieht, steht in Backup-Strategie zuhause.