Zum Inhalt

RFC-004: VLAN-Segmentierung des Heimnetzes

Feld Wert
Status draft
Datum 2026-03-23
Betrifft homeserver, homelab-external, claude-pi, homelab-documentation
Tracking-Issues noch keine
Verwandt RFC-002 (VPN-Redesign), RFC-003 (Authelia/LDAP)

Problem

Das gesamte Heimnetz laeuft in einem einzigen flachen Subnetz (10.10.10.0/24). Alle Geraete — Server, IoT, persoenliche Geraete, Gaeste — befinden sich im selben Broadcast-Domaene und koennen uneingeschraenkt miteinander kommunizieren.

Konkrete Probleme:

  1. Keine Isolation: Ein kompromittiertes IoT-Geraet kann auf den NUC, das NAS und alle anderen Geraete zugreifen
  2. Kein Gaeste-Netz: Gaeste haben vollen Zugriff auf das lokale Netz
  3. Kein VPN-Tracking: VPN-Traffic kommt im selben Subnetz an wie lokaler Traffic, nicht separat messbar
  4. mDNS-Broadcast-Flut: Alle mDNS-Announcements erreichen alle Geraete
  5. Kein Least Privilege: Jedes Geraet kann jedes andere auf jedem Port erreichen
  6. VPN-ACLs unvollstaendig: RFC-002 definiert ACLs pro Subnetz, aber es gibt nur ein Subnetz — keine granulare Steuerung moeglich

Vorschlag

Segmentierung des Heimnetzes in 9 VLANs ueber die bestehende UniFi-Infrastruktur. VLAN-IDs entsprechen dem 3. Oktett der Subnetze fuer einfache Zuordnung. Migration als Big-Bang-Umstellung an einem Wochenende, mit dem bestehenden 10.10.10.0/24 als Legacy-VLAN fuer noch nicht migrierte Geraete.

Explizit nicht in Scope

  • Firewall-Regeln im Detail — Dieser RFC definiert die VLAN-Struktur und Kommunikationsmatrix. Konkrete UDM-Pro-Firewall-Regeln werden bei der Implementierung ausgearbeitet.
  • Tailscale-ACL-Details — Die VPN-ACL-Anpassungen sind in RFC-002 beschrieben. Dieser RFC stellt sicher, dass das VLAN-Design mit dem VPN kompatibel ist.

Ist-Zustand

Netzwerk

Parameter Wert
Subnetz 10.10.10.0/24 (einziges)
Gateway UDM Pro
VLANs Keine (ausser Draytek VLAN 99)
DNS Pi-hole (10.10.10.3)
DHCP UDM Pro
WLAN-SSIDs Speednet, Speednet IoT, Gaeste (hidden)

Hardware

Geraet Modell Funktion
Gateway UDM Pro Router, Firewall, DHCP, VLAN-Routing
Switch 1 USW-24-PoE Haupt-Switch (Server, APs)
Switch 2 USW Flex Nebenstandort
Switch 3 USW Lite 8 PoE Nebenstandort
AP 1 + AP 2 2x U6-LR WLAN (alle SSIDs)
NAS UNAS Pro Netzwerk-Speicher

Aktuelle Geraete im Netz

Geraet IP (aktuell) Ziel-VLAN
NUC (Homeserver) 10.10.10.3 Server (20)
UNAS Pro (NAS) 10.10.10.150 Server (20)
Claude-Pi 10.10.10.2 Server (20)
Exit-Node-Server (neu) — VPN (70)
UDM Pro 10.10.10.1 Management (100)
Switches, APs DHCP Management (100)
Laptops, Phones DHCP Trusted Clients (30)
ESPHome, Zigbee DHCP/statisch IoT Trusted (40)
Cloud-IoT-Geraete DHCP IoT Untrusted (50)
Draytek 10.10.99.1 Draytek WAN (99)

Soll-Zustand

VLAN-Struktur

VLAN ID Subnetz Gateway DHCP Zweck
Legacy 1 10.10.10.0/24 10.10.10.1 Ja Nicht-migrierte Geraete
Server 20 10.10.20.0/24 10.10.20.1 Ja¹ NUC, NAS, Claude-Pi
Trusted Clients 30 10.10.30.0/24 10.10.30.1 Ja Laptops, Phones, Tablets
IoT Trusted 40 10.10.40.0/24 10.10.40.1 Ja ESPHome, Zigbee/Z2M
IoT Untrusted 50 10.10.50.0/24 10.10.50.1 Ja Cloud-IoT
Gaeste 60 10.10.60.0/24 10.10.60.1 Ja Gaeste-WLAN
VPN 70 10.10.70.0/24 10.10.70.1 Ja¹ Tailscale Router + Exit Node
Draytek WAN 99 10.10.99.0/24 10.10.99.1 Nein Draytek Modem/Bridge
Management 100 10.10.100.0/24 10.10.100.1 Ja UDM Pro, Switches, APs

¹ Server und VPN-VLANs nutzen primaer statische IPs, DHCP als Fallback.

Design-Entscheidung: VLAN-ID = 3. Oktett. Einfache mentale Zuordnung: VLAN 20 = 10.10.20.0/24. Ausnahme: Legacy (VLAN 1 = 10.10.10.0/24, historisch).

WLAN-SSIDs

SSID VLAN Sicherheit Sichtbar
Speednet Trusted Clients (30) WPA3 Ja
Speednet IoT IoT Trusted (40) WPA2 (Kompatibilitaet) Ja
Speednet Untrust IoT Untrusted (50) WPA2 Ja
Gaeste Gaeste (60) WPA2, Client-Isolation Nein (QR-Code)

Server (20), VPN (70), Draytek (99) und Management (100) haben kein WLAN — ausschliesslich kabelgebunden.

Switch-Port-Zuordnung

Switch Trunk-Ports Access-Ports
USW-24-PoE Uplink zu UDM Pro (alle VLANs), NUC (Server + IoT Trusted) Server-Geraete (VLAN 20), APs (alle VLANs via Trunk)
USW Flex Uplink (Trunk) Nach Bedarf
USW Lite 8 PoE Uplink (Trunk) Nach Bedarf

NUC als Trunk-Port: Der NUC bekommt einen Trunk-Port mit VLAN 20 (Server, Native/untagged) und VLAN 40 (IoT Trusted, tagged). Auf dem NUC wird ein VLAN-Sub-Interface (eth0.40) fuer das IoT-VLAN eingerichtet. Home Assistant (network_mode: host) sieht beide Interfaces und kann direkt mit IoT-Geraeten kommunizieren (mDNS auf eth0.40, Bluetooth ueber USB-Dongle/VLAN-unabhaengig). Ohne Trunk waere ein mDNS-Relay (Avahi) noetig — der Trunk ist die einfachere Loesung.

Docker und VLAN-Interfaces

Container mit network_mode: host (Home Assistant, ESPHome, Tailscale, Cloudflared) sehen alle Netzwerk-Interfaces des Hosts, einschliesslich VLAN-Sub-Interfaces. Container in Docker-Bridge-Netzwerken sind davon nicht betroffen — sie kommunizieren nur ueber ihre zugewiesenen Bridge-Netzwerke.

Casting/mDNS zwischen Trusted Clients und IoT: Chromecast, AirPlay und aehnliche Casting-Protokolle benoetigen mDNS-Discovery in beide Richtungen. Da der NUC-Trunk nur VLAN 20+40 verbindet, brauchen Casting-Geraete in VLAN 40 einen mDNS-Reflector (Avahi) auf dem UDM Pro, um mDNS zwischen VLAN 30 (Trusted Clients) und VLAN 40 (IoT Trusted) zu bridgen. Alternativ bleiben Casting-Geraete (Smart-TVs, Chromecast) im Trusted-Clients-VLAN (30).

Rollenabgrenzung NUC vs. Exit-Node-Server:

  • NUC (Server-VLAN 20, Trunk zu IoT 40): Bleibt Subnet Router fuer die lokalen VLANs (RFC-002, Redundanz). Der NUC-Tailscale-Client advertisiert die erreichbaren Subnetze. Da er Trunk-Zugang zu VLAN 20+40 hat, kann er diese Netze routen.
  • Exit-Node-Server (VPN-VLAN 70, Trunk zu 20+30+40): Primaerer Subnet Router + Exit Node. Sitzt im VPN-VLAN mit Trunk-Zugang zu allen VLANs die ueber VPN erreichbar sein sollen. Die Headscale-ACLs (RFC-002) steuern, wer wohin darf.

Inter-VLAN-Firewall (Kommunikationsmatrix)

Grundprinzip: Default Deny — nur explizit erlaubte Verbindungen.

Quelle Ziel Erlaubt Zweck
Server (20) Alle Ja DNS, NTP, Updates, Monitoring
Management (100) Alle Ja Netzwerk-Management
Trusted Clients (30) Server (20) Ja Web-UIs, SSH, Services
Trusted Clients (30) IoT Trusted (40) Ja Smart-Home-Steuerung, Casting
Trusted Clients (30) Management (100) Ja (nur UI-Ports) UniFi-Controller-UI (443)
Trusted Clients (30) Internet Ja Normaler Internetzugang
IoT Trusted (40) Server (20) Ja (Ports einschraenken) HA, MQTT, Z2M
IoT Trusted (40) Internet Eingeschraenkt Firmware-Updates, NTP
IoT Untrusted (50) Internet Ja Cloud-Dienste
IoT Untrusted (50) Lokal Nein Kein lokaler Zugriff
Gaeste (60) Internet Ja Nur Internet
Gaeste (60) Lokal Nein Kein lokaler Zugriff
VPN (70) Per ACL Per Headscale-ACL RFC-002 steuert Zugriff
Legacy (1) Server (20) Ja Uebergangsphase
Legacy (1) Internet Ja Uebergangsphase

IoT Trusted → Server (Ports): Nur die Ports die IoT-Geraete brauchen:

  • MQTT: 1883 (Mosquitto)
  • HTTP: 8123 (Home Assistant), 8080 (Z2M)
  • mDNS: 5353 (via Trunk, nicht ueber Firewall)

IoT Untrusted und Gaeste: Komplett isoliert. Kein Zugriff auf lokale Netze, kein Inter-Client-Traffic. Nur DNS (UDM Pro) und Internet.

DNS-Konfiguration

Pi-hole (aktuell 10.10.10.3) zieht ins Server-VLAN (10.10.20.x). Alle VLANs muessen Pi-hole als DNS-Server erreichen koennen:

  • Option A (empfohlen): UDM Pro als DNS-Forwarder in jedem VLAN-DHCP. UDM Pro leitet DNS-Anfragen an Pi-hole (10.10.20.x) weiter.
  • Option B: Pi-hole direkt als DNS in jedem VLAN-DHCP. Erfordert Firewall-Regeln von jedem VLAN zu Pi-hole auf Port 53.

Option A ist einfacher und erfordert weniger Firewall-Regeln.

Trade-off Option A

UDM Pro cached DNS-Anfragen (dnsmasq). Pi-hole sieht alle Anfragen als von der UDM-Pro-IP kommend — Client-basierte Statistiken gehen verloren. Falls Client-Zuordnung wichtig ist, Option B verwenden (mehr Firewall-Regeln).

VPN-Integration (RFC-002)

Headscale-ACL-Anpassungen nach VLAN-Migration:

Die ACLs aus RFC-002 muessen von 10.10.10.0/24 (flaches Netz) auf die neuen Subnetze aktualisiert werden:

// Vorher (RFC-002):
"autoApprovers": {
  "routes": {
    "10.10.10.0/24": ["tag:gateway"]
  }
}

// Nachher:
"autoApprovers": {
  "routes": {
    "10.10.20.0/24": ["tag:gateway"],  // Server
    "10.10.30.0/24": ["tag:gateway"],  // Trusted Clients
    "10.10.40.0/24": ["tag:gateway"],  // IoT Trusted
    "10.10.70.0/24": ["tag:gateway"],  // VPN
    "0.0.0.0/0":     ["tag:exit-node"],
    "::/0":           ["tag:exit-node"]
  }
}

Per-VLAN-Zugriff ueber VPN-ACLs:

// Robin: Zugriff auf Server, Trusted Clients und IoT Trusted
{ "src": ["robin"], "dst": ["10.10.20.0/24:*", "10.10.30.0/24:*", "10.10.40.0/24:*"] }

// Thies: Kein Zugriff auf Robins Heim-VLANs (wie in RFC-002)

// Monitoring: Nur Server-VLAN (Health-Checks + DNS)
{ "src": ["tag:hetzner"], "dst": ["10.10.20.0/24:53,80,443"] }

Subnet Router im VPN-VLAN: Der Tailscale-Node im VPN-VLAN (70) benoetigt einen Trunk-Port mit Zugang zu allen VLANs, die ueber VPN erreichbar sein sollen (20, 30, 40). Der UDM Pro routet Traffic zwischen VPN-VLAN und den Ziel-VLANs; die Headscale-ACLs bestimmen, welche Subnetze ein VPN-User erreichen darf.

Authelia-Integration (RFC-003)

Die VLAN-Segmentierung hat keinen direkten Einfluss auf Authelia/lldap (beide laufen auf dem Hetzner-Server, nicht im lokalen Netz). Relevant ist:

  • Authelia OIDC fuer Homelab-Services (Phase 3c in RFC-003): Grafana und andere Services im Server-VLAN (20) erreichen Authelia ueber den VPN-Tunnel. Der Tailscale-Client auf dem NUC stellt die Verbindung her — unabhaengig vom VLAN-Setup.
  • Trusted Clients brauchen Zugang zu Authelia fuer Browser-basierte OIDC-Flows. Da Authelia auf dem Hetzner-Server laeuft (oeffentlich via HTTPS erreichbar), funktioniert das ueber normalen Internetzugang — kein VPN noetig.

Betroffene Repos

Repo Aenderung
homeserver IP-Adressen aller Services aktualisieren, Tailscale Subnet-Config anpassen, Docker-Networks ggf. anpassen
homelab-external Headscale-ACLs auf neue Subnetze aktualisieren
claude-pi Netzwerk-Config auf neue IP im Server-VLAN (20) anpassen
homelab-documentation Netzwerk-Dokumentation, LikeC4-Modell, IP-Tabellen aktualisieren

Umsetzungsphasen

Vorbereitung (vor dem Migrations-Wochenende)

  1. Geraete-Inventar erstellen: Alle Geraete mit aktueller IP und Ziel-VLAN
  2. Statische IP-Reservierungen fuer Server-Geraete planen (NUC, NAS, Pi)
  3. UniFi-VLANs in der UDM-Pro-UI konfigurieren (noch keine Ports zuweisen)
  4. WLAN-SSIDs den neuen VLANs zuordnen (noch nicht aktivieren)
  5. Inter-VLAN-Firewall-Regeln vorbereiten (noch nicht aktivieren)
  6. DNS-Forwarding auf UDM Pro konfigurieren
  7. Headscale-ACLs fuer neue Subnetze vorbereiten (noch nicht deployen)
  8. Backup: Aktuelle UDM-Pro-Config exportieren, Docker-Compose-Files sichern

Migration (Wochenende)

  1. Switch-Ports zuweisen: Trunk-Ports fuer NUC und Uplinks, Access-Ports fuer Server-Geraete auf VLAN 20 setzen
  2. Server migrieren: NUC, NAS, Claude-Pi auf neue IPs im Server-VLAN (20)
  3. Docker-Services aktualisieren: Pi-hole, Tailscale und alle Services mit hartkodierten IPs auf neue Adressen anpassen
  4. Pi-hole-DNS testen: Alle VLANs koennen DNS aufloesen
  5. WLAN umstellen: SSIDs den neuen VLANs zuordnen
  6. IoT-Geraete migrieren: NUC-Trunk muss VLAN 40 bereits aktiv haben, damit ESPHome-OTA-Updates funktionieren. ESPHome/Zigbee ins IoT-Trusted-VLAN (40), Cloud-IoT ins Untrusted-VLAN (50)
  7. Gaeste-WLAN aktivieren: VLAN 60, Client-Isolation, QR-Code
  8. VPN-VLAN einrichten: Exit-Node-Server ins VPN-VLAN (70)
  9. Firewall-Regeln aktivieren: Inter-VLAN-Firewall scharf schalten
  10. Headscale-ACLs deployen: Neue Subnetze in ACL-Policy
  11. Testen: Alle Services erreichbar, IoT funktioniert, VPN funktioniert, Gaeste-Netz isoliert, Monitoring laeuft

Nachbereitung

  1. Legacy-VLAN (10.10.10.0/24) ueberwachen: Sind noch Geraete drin?
  2. Vergessene Geraete einzeln migrieren
  3. Dokumentation aktualisieren (Netzwerk-Seite, LikeC4-Modell, Service-Docs)
  4. Legacy-VLAN entfernen sobald leer

Offene Aktionspunkte

  • Vollstaendiges Geraete-Inventar mit MAC-Adressen erstellen
  • Statische IP-Vergabe fuer Server-VLAN planen
  • UDM-Pro-Firewall-Regeln im Detail ausarbeiten
  • Pi-hole-DNS-Forwarding testen (UDM Pro als Forwarder)
  • ESPHome-Geraete: Neue WLAN-SSID (Speednet IoT) und IP-Range konfigurieren
  • Home-Assistant-Integrationen auf neue IP-Adressen pruefen
  • Docker-Compose-Files: Hartkodierte IPs identifizieren und anpassen
  • Tailscale Subnet-Router-Config auf neue VLANs erweitern
  • NUC: VLAN-Sub-Interface (eth0.40) einrichten und testen
  • mDNS-Reflector fuer Casting zwischen VLAN 30 und 40 evaluieren (Avahi auf UDM Pro oder Casting-Geraete in VLAN 30 belassen)
  • RFC-002 VLAN-Kompatibilitaets-Beispiele nach Annahme dieses RFC aktualisieren

Risiken

Risiko Mitigation
Gesamter Netzwerkausfall bei Fehlkonfiguration UDM-Pro-Config-Backup vor Migration, Rollback-Plan: alle Ports zurueck auf Default-VLAN
Docker-Services mit hartkodierten IPs brechen Vorab alle Docker-Compose-Files auf hartkodierte IPs pruefen, .env-Dateien anpassen
IoT-Geraete verbinden sich nicht mit neuem WLAN ESPHome-Geraete vorher OTA auf neue SSID/IP umflashen, Zigbee-Geraete sind unabhaengig (Z2M-Stick)
mDNS funktioniert nicht ueber VLAN-Grenzen NUC hat Trunk-Port (Server + IoT), kein mDNS-Relay noetig fuer HA. Falls doch: Avahi-Reflector als Fallback.
Pi-hole-DNS nicht erreichbar nach Migration DNS-Forwarding ueber UDM Pro testen BEVOR Switch-Ports umgestellt werden
VPN-Tunnel bricht bei IP-Aenderung Tailscale-Client auf NUC anpassen, neue Subnetze advertisieren, Headscale-ACLs aktualisieren
Gaeste-WLAN zu restriktiv (Captive Portal fehlt) UDM Pro hat Gaeste-Portal-Funktion, bei Bedarf aktivieren

Zukunftsaussichten

  • 802.1X (RADIUS): Port-basierte Netzwerkzugangs-Kontrolle. Geraete authentifizieren sich am Switch und werden automatisch dem richtigen VLAN zugewiesen. Setzt einen RADIUS-Server voraus (z.B. FreeRADIUS oder Authelia mit RADIUS-Plugin).
  • Network Access Control: Integration mit Authelia/lldap fuer identitaetsbasierte VLAN-Zuweisung.
  • Monitoring pro VLAN: UniFi-Controller exportiert bereits VLAN-basierte Metriken an UnPoller → Prometheus → Grafana. Nach Migration sind Traffic-Muster pro VLAN sichtbar.
  • Legacy-VLAN entfernen: Sobald alle Geraete migriert sind, wird VLAN 1 (10.10.10.0/24) deaktiviert.