From cd804b9766fd6a555dbda06c03149f7d58133df2 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Thu, 2 Jul 2026 20:03:56 +0200 Subject: [PATCH] =?UTF-8?q?docs=20=F0=9F=93=84=20teilprojekte.md:=20Edge-C?= =?UTF-8?q?utover=20/=20Sonos-Migration=20/=20TP5-teil-live=20nachgezogen?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Doc-Nachzug gegen den Router-Ist-Stand 2026-07-02: - Edge-Cutover 2026-07-01 (FB physisch weg, Arris-Bridge, ap1 = Public-Edge) in Ist-Stand, TP4-Titel/NAT/FB-Bridge-Block, TP10-Public-Edge-Zeile. - TP3/TP7/Reihenfolge: Sonos-Migration ✅ (10/10 auf VLAN 40), mDNS-Repeater ✅ (vlan10/20/40/30), macOS-Desktop-SSDP-Gotcha dokumentiert. - TP5 auf "teil-live" umgeschrieben: forward MAIN/INFRA↔MEDIA + input 5353 + WAN-Seal als bereits gebaut markiert; Deny-by-default bleibt offen. - TP11: CF-Tunnel #1033 Track A als Sub-Note. - VLAN 100 in kanonischer Tabelle: FB-Transfer → Arris-Transfer. Co-Authored-By: Claude Sonnet 5 --- docs/teilprojekte.md | 87 ++++++++++++++++++++++++++------------------ 1 file changed, 51 insertions(+), 36 deletions(-) diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index b0e16ad..1634f99 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -14,16 +14,16 @@ | **50** | **UNTRUSTED** | 10.40.50.0/24 | **Spielekonsole, eBook-Reader, Low-Trust-Internet** | | 90 | GUEST | 10.40.90.0/24 | nur Internet | | 99 | MGMT | 10.40.99.0/24 | Switch/AP/Hypervisor-Mgmt | -| 100 | WAN | (FB-Transfer) | zur FritzBox | +| 100 | WAN | (Arris-Transfer) | zum Arris-Kabelmodem (Liwest, Bridge-Mode, Public-IP an ap1) | IP-Blöcke: `.1–10` Router/APs (ap1=.1, ap2=.2) · `.11–20` Switches (ALLNET=.11, Omada=.12). GW je VLAN = `.1`. ## Ist-Stand (Kurz) ALLNET-Core `.11` (FW2.2.1, VLANs 10/20/30/40/50/90/99/100; GE1/GE2/GE8 Trunk; **TP1 ✅ 2026-06-15**). Omada-Switch `.12` (adopted, **TP2 ✅ 2026-06-15**; Trunk-ALL auf P1+P2, Access-Profile auf P3-P8; Profile noch PVID=1 bis Omada-PVID-Fix). Omada-Controller **`.175`** (DS923/macvlan, mbentley 6.2, 🟢 live). omada-mcp **`.176`** (pve-LXC, StreamableHTTP, 🟢 live, 84 read-Tools; Controller-API v2 intern via christoph@emsenhuber.com). -2× hAP ax² (7.23.1): ap1 `.1` (ALLNET P1) — **TP4 ✅ 2026-06-15: L3-Router aktiv** (VLAN-Subinterfaces, DHCP, DNS, NAT). ap2 `.2` (Omada P2 — Trunk). FB6660 = Double-NAT-Upstream bis FB-Bridge-Mode. -**AP4.1 (FB-Bridge, 2026-06-16):** Public-IP `86.56.201.104` per ether1 bewiesen (kein Liwest-MAC-Lock). Offline-Testmechanismus live auf ap1 (`routeros/wan-cutover-*.rsc` + Runbook; scheduler-frei, Disk-Log `wan-test.0.txt`). ✅ **Bridge-Gate aufgelöst (2026-06-27):** TP10-Kern durch (beide VPN von der FB auf ap1-WG migriert) → die FB terminiert keine Tunnel mehr → **permanenter Bridge-Mode ist jetzt entblockt** (offen = WAN-Seal + Liwest-Anruf). +2× hAP ax² (7.23.1): ap1 `.1` (ALLNET P1) — **TP4 ✅ 2026-07-01: Router + WAN-Edge** (VLAN-Subinterfaces, DHCP, DNS, NAT, Public-Edge). ap2 `.2` (Omada P2 — Trunk). +**Edge-Cutover ✅ 2026-07-01:** FB6660 physisch entfernt (Liwest-Kabelmodemtausch, kein Zurück), Arris-Kabelmodem im Bridge-Mode; WAN = `sw1 gi16 Access VLAN100 → gi15 Trunk → ap1 ether2 → vlan100 auf bridge` (**NICHT** ether1); ap1 hält Public-IP direkt (Liwest, kein CGNAT), Double-NAT weg. Telefonie war auf der FB und wird nicht weitergeführt. Vorarbeit: TP10-Kern durch (2026-06-27, WG-Hub live) → Bridge-Gate vorher gelöst. Runbook: `routeros/wan-cutover-runbook.md`. Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Controller + omada-mcp 🟢. -**Nächster Schritt: Omada-PVID-Fix** (MAIN→PVID10, INFRA→PVID20, untagNetworkIds bereinigen) + IP-Migration Geräte. +**Nächster Schritt: Omada-PVID-Fix** (MAIN→PVID10, INFRA→PVID20, untagNetworkIds bereinigen) + IP-Migration Geräte + TP5 Deny-by-default fertigziehen (Sonos-/HA-/mDNS-Holes und WAN-Input-Seal stehen bereits). > ⚠️ **HW-Constraint hAP ax²:** 1 GB RAM, aber nur **128 MB Flash + KEIN USB** → **Container auf dem Router NICHT praktikabel**. > Folge: **native RouterOS-Features bevorzugen** (z.B. Built-in-mDNS statt Container); Container (mDNS-Reflector, BIND9-DNS, Omada-Controller) laufen auf **NAS/pve**, nicht am hAP. @@ -82,8 +82,9 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co - ✅ **Kanal-Plan (non-DFS, überlappungsfrei):** ap1 ch36/5180 + ch1/2412 · ap2 ch149/5745 + ch11/2462. (Auto-Channel hatte beide APs auf 5500-DFS/2437 gelegt = Co-Channel → fix gepinnt. ap2-Kanaländerung braucht `remote-cap provision`-Push.) `bound`-Problem damit obsolet/sauber gelöst. -- ⏳ **Sonos-Anschluss (TP7):** 7 WLAN-Sonos hängen noch am FB-WLAN (VLAN1) → Household gespalten, daher - „Sonos selektiv je Netz". Fix = Sonos auf `dirtyvader-media`(VLAN40) migrieren (User-seitig, Re-Onboarding). +- ✅ **Sonos-Migration abgeschlossen (2026-07-02):** alle 10 Sonos auf `dirtyvader-media`/VLAN 40 mit MAC-fest + reservierten DHCP-Leases in `dhcp-v40`. Household geschlossen, iOS-App findet alle Geräte (mDNS via Repeater). + Inventar/IPs = SSoT `docs/sonos-inventar.md` (IPs haben sich verschoben — Arc jetzt `.199`, Arbeitszimmer-Paar auf `.191/.192`). - **Vertagt:** hidden `dirtyvader-infra`(20)+`-mgmt`(99) (Mgmt verkabelt). **TP8:** eine 802.1X-SSID (`dirtyvader-secure`) mit FreeRADIUS-Dynamic-VLAN → dann PSK-`main`/`infra` einstampfen (Konsolidierung). - **SSID-Strategie-Entscheid (Begründung):** unterschiedl. WPA-Typ/Band erzwingen separate SSIDs; „alles in 1 SSID @@ -108,39 +109,47 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co sein (nicht `defconf`/`10.40.41.x`). Falls kein DHCP: Omada-Port-2-Trunk (tagged 10/30/40/50/90) prüfen. - Abh.: TP3 ✅, TP4 ✅ (Bridge-VLAN-Muster gespiegelt). Config ap2-lokal (nicht CAPsMAN-verwaltet). -### TP4 — Router-Cutover (hAP#1 = Router) ▸ ✅ L3-Infra FERTIG (2026-06-15) — FB-Bridge ausstehend +### TP4 — Router-Cutover (hAP#1 = Router + WAN-Edge) ▸ ✅ FERTIG (2026-07-01) - ✅ **Bridge VLAN-Filtering aktiviert** (`vlan-filtering=yes`); VLAN-Tabelle: VLAN1 untagged bridge+ether2, VLANs 10/20/30/40/50/90/99/100 tagged bridge+ether2. - ✅ **VLAN-Subinterfaces:** vlan10/20/30/40/50/90/99 auf bridge; je GW `.1` (10.40.10.1 … 10.40.99.1). - ✅ **DHCP:** dhcp-v10…dhcp-v99 je auf eigenem VLAN-Interface, pools .100-.200, GW+DNS = VLAN-GW. - ✅ **DNS:** RouterOS-nativ, allow-remote-requests=yes. **Upstream seit 2026-06-16: DoH Cloudflare Gateway** (`use-doh-server=https://px35ynlol3.cloudflare-gateway.com/dns-query`, verify-doh-cert, `servers=1.1.1.1` als Bootstrap; FB-Upstream abgelöst). Statische Einträge für alle Infra-Hosts unter `bf.lan` (13 Einträge, Transition-IPs bis PVID-Fix). - ⚠️ Auto-Suffix `.lan` (RouterOS-Einschränkung, kann nicht auf leer gesetzt werden) — TP5-Cleanup. -- ✅ **NAT:** srcnat masquerade out-interface=bridge (ap1 → FB → Internet, Double-NAT Interim-Lösung). -- ✅ **Routing-Tabelle:** 0.0.0.0/0 via 10.40.41.254%bridge; alle 7 VLAN-Subnetze als Connected-Routes aktiv. -- ⏳ **FB-Bridge-Mode (AP4.1) — jetzt entblockt (TP10-Kern durch 2026-06-27)** — ether1 als WAN ist vorkonfiguriert (DHCP-Client, NAT out=ether1, Fallback-Route bridge distance=2). **Test 2026-06-16:** Public-IP `86.56.201.104` per ether1 bewiesen (kein Liwest-MAC-Lock). Offline-Testmechanismus live (`routeros/wan-cutover-test.rsc`/`-macclone-test.rsc` + `wan-cutover-runbook.md`; scheduler-frei wg. device-mode, Disk-Log `wan-test.0.txt`). User-Befund „nach Gateway .1 ging nichts mehr" → Root-Cause offen (Hypothese DoH-Bootstrap). ✅ **VPN-Gate weg** (beide Tunnel auf ap1-WG migriert); offen = WAN-Input-Seal (Block C aus `tp10-cutover-apply.rsc`) + **Liwest-Anruf** → ether1 = Public Edge, Double-NAT weg. Telefon bleibt an der FB. Bis dahin: Double-NAT via bridge (funktioniert). +- ✅ **NAT:** srcnat masquerade out-interface=vlan100 (ap1 = Public-Edge; kein Double-NAT mehr). Fallback-Konfig für ether1 bleibt reversibel dokumentiert (`routeros/wan-cutover-runbook.md`). +- ✅ **Routing-Tabelle:** 0.0.0.0/0 via Liwest-Gateway auf vlan100; alle 7 VLAN-Subnetze als Connected-Routes aktiv. +- ✅ **Edge-Cutover vollzogen (2026-07-01):** FritzBox 6660 physisch weg (Liwest hat gegen ein Arris-Kabelmodem im Bridge-Mode getauscht — kein Zurück). WAN = `Arris → sw1 gi16 Access VLAN100 → gi15 Trunk → ap1 ether2 → vlan100 auf bridge` (**NICHT** ether1). ap1 hält Public-IP direkt (Liwest, kein CGNAT). **WAN-Input-Seal live** (TP10-seal-Regeln: est/inv/dhcp/icmp/lan/wandrop im `input`-Chain, `list_firewall_rules` 2026-07-02 verifiziert). Telefonie war auf der FB und wird nicht weitergeführt (User-Bestätigung 2026-07-02). - **DNS-Entscheidung** (Technitium **und** externer BIND verworfen): RouterOS-DNS als Resolver, keine DHCP→DNS-Auto-Registrierung (soweit möglich). Infra-Hosts als statische `/ip dns static`-Einträge unter `bf.lan`; dynamische Clients bewusst ohne Namen. Filtering/DNSSEC via DoH-Upstream (TP3). HA: 2. Resolver auf ap2, statische Einträge beidseitig pflegen. - Abh.: TP1 ✅. TP3-Abhängigkeit entfällt (WLAN läuft weiterhin über FB bis TP3). - **Ermöglicht jetzt:** PVID-Fix in Omada-Profilen (MAIN→PVID10, INFRA→PVID20), untagNetworkIds-Bereinigung, DHCP-Reservierungen für NAS/macmini/pve auf neue VLAN-Subnetze migrieren. -### TP5 — Firewall & Inter-VLAN-Policy -- **Deny-by-default + least-privilege.** MAIN→INFRA nur Whitelist-Dienste; MAIN↔MEDIA allow (+mDNS); UNTRUSTED/GUEST nur Internet; MGMT isoliert; Router-input gehärtet. +### TP5 — Firewall & Inter-VLAN-Policy ▸ ⏳ TEIL-LIVE (Sonos/HA-Holes + WAN-Seal gebaut, Deny-by-default steht aus) +- **Deny-by-default + least-privilege** (Ziel). MAIN→INFRA nur Whitelist-Dienste; MAIN↔MEDIA allow (+mDNS); UNTRUSTED/GUEST nur Internet; MGMT isoliert; Router-input gehärtet. +- ✅ **Bereits live** (verifiziert `list_firewall_rules` 2026-07-02): + - `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) + - **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. -- Abh.: TP4. +- Abh.: TP4 ✅. ### TP6 — QoS/CAKE + Call-Quality-A/B-Test ▸ DAS Ziel - **CAKE am WAN-Upload** (~85–95 % Linerate) → Bufferbloat weg. Verifikation waveform.com → A/A+. - ⚠️ **Vor „Erfolg":** A/B-Test, denn Kollegen-Befund sagt DE-Calls = **internat. Pfad AT↔DE**, nicht Heimnetz → ggf. **WARP** statt/zusätzlich CAKE. Nicht am einen Telefonat festmachen. - Abh.: TP4. -### TP7 — Media-Discovery (mDNS) für VLAN 40 ▸ ✅ Kern FERTIG (2026-06-17) — `docs/tp7-mdns.md` -- ✅ **Built-in mDNS-Repeater** aktiv: `/ip/dns set mdns-repeat-ifaces=vlan10,vlan40` (RouterOS 7.23.1). MAIN↔MEDIA. - Reversibel (Feld leeren). Realbestand: MAIN=MacBook, MEDIA=2× SonosZP `.199/.200`. -- 💡 **TP5-Abhängigkeit entschärft:** Repeater re-originiert mDNS vom Router (input→output), **kein** Client-`forward` - → Deny-by-default blockt die Discovery nicht. TP5 muss nur (a) MAIN↔MEDIA-Nutzdaten-`forward` erlauben (ohnehin - geplant) und (b) beim Input-Härten **UDP 5353 von vlan10/vlan40 an den Router offenlassen**. -- ⏳ **Funktionaler Test ausstehend:** Sonos-App/AirPlay auf MAIN-Client → Sonos müssen erscheinen. -- **SSDP/Cast** (UDP 1900) deferred: nur mDNS nativ; SSDP bräuchte Reflector-Container auf NAS/pve (nicht am hAP). - Für Sonos/AirPlay (mDNS) nicht nötig. **IOT** bewusst nicht im Repeater (Scope=MAIN↔MEDIA). -- Abh.: TP4 ✅. TP5 = Folge-Anschluss (Firewall-Holes), nicht blockierend für den Kern. +### 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). + 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. +- ✅ **TP5-Anschluss live:** `forward accept vlan10↔vlan40` + `forward accept vlan20↔vlan40` + `input accept udp/5353` + auf vlan10/20/30/40 sind gebaut (mit „TP5:"-Kommentar), damit Discovery + Steuerung + Streaming ohne Umwege gehen. +- ⚠️ **SSDP/Cast (UDP 1900) bewusst NICHT gebaut** (bräuchte Reflector-Container auf NAS/pve; hAP hat kein USB/Flash). + Konsequenz: **macOS-Desktop-Sonos-App nutzt SSDP → quert die VLAN-Grenze NICHT** und findet die Sonos nicht. + iOS-App (mDNS) und HA-Integration decken den Nutzungsbedarf ab; Spotify Connect läuft über Cloud. +- Abh.: TP4 ✅, TP5 (Sonos-Holes) ✅ live. ### TP8 — Identity & Access-Control ▸ research-gated - **RADIUS = FreeRADIUS auf der NAS** (✏️ User-Manager v5 kann **KEIN LDAP** → openldap nur via FreeRADIUS anbindbar). @@ -155,22 +164,28 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co ### TP10 — Multi-Site VPN ▸ ✅ KERN DURCH (2026-06-27) — beide WG live auf ap1-Hub (`docs/tp10-vpn-migration.md`) > **Details/Cutover/Gotchas/Eckdaten → `docs/tp10-vpn-migration.md` (Single Source of Truth).** Research: `docs/research/vpn-comparison.md`. -- **✅ KERN DURCH (2026-06-27):** beide AVM-Tunnel → **2× WireGuard mit Hub auf ap1** migriert. Live: `peer fm` +- **✅ KERN DURCH (2026-06-27) + EDGE-CUTOVER (2026-07-01):** beide AVM-Tunnel → **2× WireGuard mit Hub auf ap1** migriert. Live: `peer fm` (`10.101.0.0/24`, bidirektional, myfritz-Endpoint) **und** `peer dw` (`10.95.10.0/24`, CGNAT-Dial-in) mit frischem - Handshake + Traffic. Noch im **Double-NAT** über die BF-FB-Portfreigabe (51821 → ap1). FM-IPsec gekillt, Gelis - alter FB↔FB-WG sauber geswappt. **→ entblockt den permanenten FB-Bridge-Mode.** + Handshake + Traffic. **Public-Edge direkt** — ap1 hört UDP/51821 auf `vlan100` (Edge-Cutover 2026-07-01), keine + FB-Portfreigabe mehr, kein Double-NAT. FM-IPsec gekillt, Gelis alter FB↔FB-WG sauber geswappt. - **✅ DW/Geli on-site verifiziert (2026-06-27):** Geli auf `10.95.10.0/24` renumbert, FB-WG single `10.95.10.1/24`, Keepalive 25, Endpoint `bf4…:51821`. End-to-End von macmini/Linz → Gelis 24/7-APs `10.95.10.246/.247` sauber (echte LAN-IPs, **kein `10.255.255.x`**-NAT-Leak). - **💡 Root Cause (FM-PoC bewiesen):** FB masqueradet WG, wenn die Interface-`Address` eine **Transfernetz-IP** ist → muss die **FB-LAN-IP** sein (AVM Proxy-ARP). War der Schlüssel zum sauberen LAN-LAN. - **Hub:** `wg-hub` (UDP 51821, Key `P/bzt…`, MTU 1412, keine IF-IP). Endpoint = DDNS **`bf4.emsenhuber.net:51821`** - (Cloudflare, DNS-only → 86.56.201.104, überlebt Bridge). Apply gebündelt in `routeros/tp10-cutover-apply.rsc`. -- **Offen (entblockt):** permanenter FB-Bridge-Cutover (WAN-Seal Block C + **Liwest-Anruf** → ether1 = Public Edge, - Double-NAT weg); BF-FB-eigenen WG-Server 51820 abräumen; DDNS-Auto-Updater für `bf4` auf NAS/pve. + (Cloudflare, DNS-only → Public-IP). Apply gebündelt in `routeros/tp10-cutover-apply.rsc`. +- ✅ **Permanenter Edge-Cutover durch (2026-07-01)** — Details in TP4 (WAN via sw1 vlan100, ap1 = Public-Edge, + WAN-Input-Seal live). BF-FB-eigenen WG-Server 51820 entfällt (FB physisch weg). +- **Offen:** DDNS-Auto-Updater für `bf4.emsenhuber.net` auf NAS/pve, damit der A-Record der Public-IP folgt + (falls Liwest sie tauscht). Aktuell manuell in Cloudflare gepflegt. ### TP11 — Monitoring & Mgmt-Control-Plane ▸ research-gated - MikroMCP + omada-mcp + **SNMP/icinga-mikrotik**, RoMON, NTP, **E-Mail-Alerts**, Netwatch. → Teil von `docs/research/routeros-capabilities.md`. +- **CF-Tunnel #1033 Track A ✅ live (2026-06-30):** Round-Robin-1033er über 3 asymmetrische Connectors behoben + durch Reduktion auf pve-only Connector (NAS + macmini scheiterten an pve-lokalen/stalen Origins). SSoT: + `docs/cf-tunnel-mapping.md`. Track B/C (HA-Connector-Pair pve+NAS in VLAN 20, Origins-Repoints) wartet auf + CF-MCP-Write-Reauth und wird mit der IP-Migration (nach Omada-PVID-Fix) gebündelt. ### TP12 — IPv6 (intern + extern, 3 Standorte) ▸ research-gated - Konzept für FM/BF/DW. → TP-R. @@ -189,11 +204,11 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co --- ## Reihenfolge / Abhängigkeiten -1. ~~**Jetzt:** TP1 (GE8) → TP2 (Omada Controller).~~ ✅ erledigt 2026-06-15. -2. ~~**TP4 (Router-Cutover L3-Infra).**~~ ✅ erledigt 2026-06-15. FB-Bridge-Mode noch offen (physisch). +1. ~~**TP1 (GE8) → TP2 (Omada Controller).**~~ ✅ erledigt 2026-06-15. +2. ~~**TP4 (Router-Cutover L3-Infra + WAN-Edge).**~~ ✅ erledigt 2026-06-15 (L3) + 2026-07-01 (Edge-Cutover, FB physisch weg). 3. **Jetzt: Omada-PVID-Fix** — Omada Access-Profile korrigieren (PVID 10/20, untagNetworkIds bereinigen, sicher P3/P5/P6 zuerst), dann IP-Migration NAS/macmini/pve auf VLAN-Subnetze + DNS-Einträge updaten. -4. **Dann:** TP5 (Firewall/Deny-by-default) → TP6 (QoS/CAKE). ~~TP7 (mDNS)~~ ✅ 2026-06-17, ~~TP3 (WLAN/CAPsMAN)~~ ✅ 2026-06-18. - ⚠️ TP5 muss die TP7-Firewall-Holes mitnehmen (s. TP7: MAIN↔MEDIA-forward + UDP 5353 input). - ⏳ Sonos-WLAN-Migration (7 Geräte FB-WLAN→VLAN40) als Anschluss an TP3/TP7 (User-seitig, schließt den Household). -5. **TP10 (VPN) ✅ Kern durch (2026-06-27)** — Rest = FB-Bridge-Cutover (WAN-Seal + Liwest-Anruf), entblockt. -6. **Nachgelagert/Research-getrieben:** TP8 (Access), TP9 (HA), TP11 (Monitoring), TP12 (IPv6), TP13 (Spaß). +4. **Dann:** TP5 (Deny-by-default fertigziehen — Sonos-/HA-/mDNS-Holes + WAN-Input-Seal stehen bereits) → TP6 (QoS/CAKE). + ~~TP7 (mDNS)~~ ✅ 2026-07-02 (inkl. HA/vlan20), ~~TP3 (WLAN/CAPsMAN)~~ ✅ 2026-06-18, ~~TP3.1 (ap2-VLAN-Trunk)~~ ✅ 2026-07-01, + ~~Sonos-Migration~~ ✅ 2026-07-02 (alle 10 auf VLAN 40). +5. ~~**TP10 (VPN)**~~ ✅ Kern durch (2026-06-27) + Edge-Cutover (2026-07-01) → DURCH. Offen nur: DDNS-Auto-Updater. +6. **Nachgelagert/Research-getrieben:** TP8 (Access), TP9 (HA), TP11 (Monitoring + CF-Tunnel-Track-B/C), TP12 (IPv6), TP13 (Spaß).