docs 📄 TP7.2: HA↔Sonos static-host binding + VLAN1/GUEST-Discovery

HA-Sonos waren unavailable: HA hängt auf VLAN1 (10.40.41.105), nicht VLAN20,
und die Sonos-Integration ist SSDP-abhängig (quert VLAN nicht) — frühere
"HA nutzt mDNS/self-healing"-Notiz war falsch.

Fix: static hosts: + advertise_addr in configuration.yaml (discovery-unabhängig,
advertise_addr fixt UPnP-Callbacks trotz Multi-Homing). Zusätzlich VLAN1/GUEST-
Erreichbarkeit: mdns-repeat-ifaces +vlan90,bridge; forward vlan90↔vlan40 (ganzes
MEDIA) + input 5353 vlan90. Flacher-Repeater-Leak bewusst.

- teilprojekte.md: neues TP7.2, TP5/TP7-Regeln nachgezogen
- sonos-inventar.md: HA-Abschnitt korrigiert (SSDP + static hosts)
- tp7-mdns.md: superseding Update-Block (neue Repeater-Ifaces, GUEST-Forward)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
2026-07-03 08:05:18 +02:00
parent 5fbce5f798
commit 82ca6e282c
3 changed files with 47 additions and 7 deletions

View File

@@ -41,12 +41,19 @@ Erhoben zero-dep über die Sonos-HTTP-API (`:1400`) mit `mcp/sonos/sonos-inv.py
> HA-Zuordnung (Beispiel): der Arc meldet sich als
> `RINCON_48A6B80B631001400@Wohnzimmer._sonos._tcp.local.` (RINCON = MAC ohne Trenner + `01400`).
## Home Assistant
- HA (INFRA/VLAN 20) entdeckt Sonos per **zeroconf/mDNS** (`_sonos._tcp.local.`), **nicht** SSDP →
seit der Repeater-vlan20-Erweiterung (2026-07-02) findet HA die Boxen wieder selbst und zieht die
aktuellen `10.40.40.x`-IPs nach (self-healing, keine manuellen Hosts nötig).
## Home Assistant (TP7.2, korrigiert 2026-07-03)
- **⚠️ Korrektur früherer Notiz:** HA sitzt **nicht** auf VLAN 20, sondern noch auf `10.40.41.105`
(VLAN-1-Transfernetz, IP-Migration steht aus). Die HA-Sonos-Integration ist **SSDP-abhängig**
(`manifest dependencies:[ssdp]`, soco 0.31.1) → quert die VLAN-Grenze **nicht**. Deshalb waren alle
Sonos in HA `unavailable`, obwohl die iOS-App (mDNS) sie fand. Die alte „HA nutzt zeroconf/mDNS,
self-healing"-Aussage war falsch.
- ✅ **Fix (discovery-unabhängig):** `sonos: media_player:` in `configuration.yaml` mit **statischer `hosts:`-Liste**
(alle 11 IPs oben) + **`advertise_addr: 10.40.41.105`** (fixt UPnP-Event-Callbacks trotz HA-Multi-Homing
`.105`/`172.16.0.18`/docker). Nach Core-Restart alle 6 Online-Zonen `idle/playing`, Wohnzimmer-Push verifiziert.
- ✅ **Zusätzlich** hat der Repeater seit TP7.2 `bridge`(=VLAN 1) im Scope → HA bekommt jetzt auch die zeroconf-
Advertisements und meldet „automatic discovery is working". Die static `hosts:` bleiben als Redundanz.
- Steuern + **Gruppieren** läuft über die native **Sonos-Integration** (SOAP auf Port 1400), *nicht* AirPlay.
- Falls IPs mal hart hinterlegt werden sollen: obige Tabelle ist die SSoT; IPs sind DHCP-reserviert = stabil.
- IPs sind DHCP-reserviert = stabil; obige Tabelle ist die SSoT.
## Home-Theater-Bond „Wohnzimmer"
Arc (`.199`, Coordinator) + Amp (`.200`, Surrounds) + Sub (`.201`) sind aneinander gebunden —

View File

@@ -162,6 +162,7 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
- `forward accept vlan10↔vlan40` — TP5: MAIN↔MEDIA (AirPlay/Sonos)
- `forward accept vlan20↔vlan40` — TP5: INFRA↔MEDIA (HA↔Sonos)
- `input accept udp/5353 vlan10/vlan20/vlan30/vlan40` — mDNS-Repeater (TP7-Anschluss)
- `forward accept vlan90↔vlan40` + `input accept udp/5353 vlan90` — **GUEST→MEDIA (Sonos/Cast), permanent** (TP7.2, 2026-07-03)
- **WAN-Input-Seal komplett** (TP10-seal-est/inv/dhcp/icmp/lan/wandrop + WG-Hub UDP/51821 accept)
- ⏳ **Offen:** Deny-by-default am Ende von `forward` (aktuell noch permissiv nach fasttrack); UNTRUSTED/GUEST auf Internet-only pinnen; MGMT isolieren; IoT→INFRA-Whitelist bauen.
- **IoT→INFRA-Rückmeldung (deine Frage):** IoT darf **aktiv** zu INFRA-Diensten initiieren — Firewall-Allow IoT→INFRA NUR auf **MQTT (1883/8883), HA-API, InfluxDB (8086)** o.ä.; Antworten via established/related; IoT→MAIN bleibt deny. So pusht ein Sensor Daten an HA/MQTT/Influx, ohne dass IoT „frei" ist.
@@ -173,8 +174,8 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
- Abh.: TP4.
### TP7 — Media-Discovery (mDNS) für VLAN 40 ▸ ✅ FERTIG (2026-07-02) — `docs/tp7-mdns.md`
- ✅ **Built-in mDNS-Repeater** aktiv: `/ip/dns set mdns-repeat-ifaces=vlan10,vlan20,vlan40,vlan30` (RouterOS 7.23.1).
MAIN↔MEDIA + INFRA↔MEDIA (für HA) + IOT dazugenommen. Reversibel (Feld leeren).
- ✅ **Built-in mDNS-Repeater** aktiv: `/ip/dns set mdns-repeat-ifaces=vlan10,vlan20,vlan40,vlan30,vlan90,bridge`
(RouterOS 7.23.1; `vlan90`+`bridge`=VLAN-1 seit TP7.2 2026-07-03). MAIN/INFRA/IOT/GUEST/VLAN1 ↔ MEDIA. Reversibel (Feld leeren).
Realbestand: MAIN=iOS-Client + MacBook, INFRA=Home Assistant, MEDIA=10× Sonos (siehe `docs/sonos-inventar.md`).
- ✅ **Funktional durchgetestet (2026-07-02):** iOS-Sonos-App (vlan10) **und** Home Assistant (vlan20) finden die
9 online-Sonos per `_sonos._tcp.local.` (Bonjour) automatisch. Household nicht mehr gesplittet.
@@ -197,6 +198,27 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
- **Alternative (verworfen):** macOS-Client temporär in VLAN 40 hängen (unpraktikabel für Alltagsnutzung).
- Abh.: TP7 ✅. Kein Blocker für TP5-Deny-by-default.
### TP7.2 — HA↔Sonos static-host binding + VLAN1/GUEST-Discovery ▸ ✅ FERTIG (2026-07-03) — `docs/sonos-inventar.md`
- **Root Cause (widerlegt frühere Doku):** HA-`media_player.*`-Sonos alle `unavailable`. HA sitzt **nicht** auf
VLAN 20, sondern noch auf `10.40.41.105` (VLAN-1-Transfernetz, IP-Migration steht aus). Der mDNS-Repeater
deckte VLAN 1 **nicht** ab, und die HA-Sonos-Integration ist **SSDP-abhängig** (`manifest dependencies:[ssdp]`,
soco 0.31.1) → quert die VLAN-Grenze nicht. Die alten „HA nutzt mDNS/zeroconf, fixed 2026-07-02"-Notizen waren falsch.
- ✅ **HA-Fix (discovery-unabhängig):** `sonos: media_player: hosts:` mit allen 11 Sonos-IPs + `advertise_addr: 10.40.41.105`
in `configuration.yaml` (Backup `.bak-sonos-20260703`). `advertise_addr` fixt die UPnP-Event-Callbacks trotz
HA-Multi-Homing (`.105`/`172.16.0.18`/docker). Core-Restart → alle 6 Online-Zonen `idle/playing` (Wohnzimmer-Push
verifiziert = Callbacks OK). Terrasse `.198` offline = kein Entity (kommt beim Einschalten). Kurzes Flapping direkt
nach Restart = Settling, danach stabil.
- ✅ **Nebeneffekt:** mit `bridge` im Repeater (s.u.) meldet HA jetzt „Automatic discovery is working, hosts not needed"
— die statischen Hosts sind also Redundanz (Gürtel+Hosenträger), bleiben aber als Absicherung.
- ✅ **VLAN 1 (temp) + GUEST (perm) Discovery/Reach (User-Wunsch 2026-07-03):**
- mDNS-Repeater erweitert → `mdns-repeat-ifaces=vlan10,vlan20,vlan40,vlan30,vlan90,bridge` (VLAN-1-untagged=`bridge`).
- Firewall: `input accept udp/5353 vlan90` + `forward accept vlan90↔vlan40` (ganzes MEDIA, beide Richtungen; User-Wahl).
VLAN 1/`bridge` brauchte nichts (schon via `TP10-seal-lan` + permissiver Forward).
- **Bewusst in Kauf:** flacher Repeater → Guests sehen auch MAIN/INFRA/IOT-mDNS-Announcements (Discovery-Leak;
echte Verbindungen regelt TP5-Deny-by-default).
- **Offen/später:** HA→VLAN 20 (IP-Migration nach Omada-PVID-Fix) → dann nur `advertise_addr` auf neue IP; macOS-Desktop-App
weiter via SSDP-Reflector TP7.1. Abh.: TP7 ✅, TP5-Holes ✅.
### TP8 — Identity & Access-Control ▸ research-gated
- **RADIUS = FreeRADIUS auf der NAS** (✏️ User-Manager v5 kann **KEIN LDAP** → openldap nur via FreeRADIUS anbindbar).
- **EAP-TLS (Zert) je Gerät + dynamische VLAN-Zuweisung** (RADIUS-Attribut `Tunnel-Private-Group-ID`). **Einfachste Heim-Alternative:** pro VLAN eine SSID mit **WPA3-PSK** (kein RADIUS) — Abwägung Komfort vs. Admin-Aufwand.

View File

@@ -1,5 +1,16 @@
# TP7 — Media-Discovery (mDNS) für VLAN 40 (As-built, 2026-06-17)
> **⚠️ Update 2026-07-03 (TP7.2) — supersedes Teile dieses As-builts:**
> - **Aktuelle Repeater-Config:** `mdns-repeat-ifaces=vlan10,vlan20,vlan40,vlan30,vlan90,bridge`
> (nicht mehr `vlan10,vlan40`). Erweitert um vlan20 (HA-Discovery, 2026-07-02), vlan30 (IOT/P750W),
> **vlan90 (GUEST, permanent) und `bridge` (=VLAN-1-untagged, temporär) am 2026-07-03**.
> - **Damit obsolet:** die Aussage unten „VLAN 1 bewusst NICHT in den Repeater aufnehmen". VLAN 1 (`bridge`)
> ist jetzt drin, weil HA noch auf `10.40.41.105` (VLAN 1) hängt und die Sonos entdecken können muss.
> - **GUEST-Firewall (permanent):** `input accept udp/5353 vlan90` + `forward accept vlan90↔vlan40` (ganzes MEDIA).
> - **Trade-off bewusst:** flacher Repeater → GUEST sieht auch MAIN/INFRA/IOT-mDNS-Announcements (Discovery-Leak).
> - **HA-Sonos:** primär via static `hosts:` + `advertise_addr` (SSDP-abhängige Integration, s. `sonos-inventar.md`);
> der `bridge`-Repeater ist zusätzliche Redundanz. Details → TP7.2 in `teilprojekte.md`.
**Ziel:** Clients auf **MAIN (VLAN 10)** sollen Mediageräte auf **MEDIA (VLAN 40)**
finden (AirPlay/Bonjour, Sonos) — über VLAN-Grenzen hinweg, ohne beide VLANs zu mischen.