TP2 🔍 Profile-Analyse + TP4 vorgezogen

Analyse via Omada Controller v2-API (2026-06-15):
- Access-Profile haben PVID=1 statt 10/20 (Constraint: fixe IPs in 10.40.41.x)
- Access-MAIN hat untagNetworkIds=[VLAN1,VLAN10,VLAN20] — bekannter Fehler, Fix nach TP4
- P4 (dock/monitor) → Access-MAIN (Lifeline-Port, nicht anfassen)
- P3/P5/P6 sicher zum Testen, P7/P8 eingefroren
- Network-IDs + v2-API-Pfade dokumentiert (Ctrl-API: Csrf-Token, /switches/{MAC}/ports)
- TP4 vorgezogen: blockiert Profile-Fix + echte VLAN-Segmentierung

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

docs/teilprojekte.md

@@ -18,10 +18,11 @@
 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).
-Omada-Controller **`.175`** (DS923/macvlan, mbentley 6.2, 🟢 live). omada-mcp **`.176`** (pve-LXC, StreamableHTTP, 🟢 live, 84 read-Tools).
+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 TP4 — siehe TP2).
+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), ap2 `.2` (Omada P2 — Trunk). FB6660 = Router/Telefon (`.254`).
 Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Controller + omada-mcp 🟢.
+**Nächster Schritt: TP4 (Router-Cutover) wird vorgezogen** — blockiert Profile-Fix und alle weiteren VLANs.
 > ⚠️ **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.
 
@@ -45,19 +46,30 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co
   - omadac_id=`adbef8fa…`, site_id=`6a2fe68e…`.
 - ✅ **VLANs im Controller:** 1/10/20/30/40/50/90/99/100 — alle angelegt, Switch adopted (switchConsistent=true).
 - ✅ **Port-Plan (ES208G, alle 8 Ports konfiguriert):**
-  | Port | Name | Profil | Gerät |
-  |------|------|--------|-------|
-  | 1 | uplink | Trunk-ALL | → ALLNET GE8 |
-  | 2 | ap2 | Trunk-ALL | hAP ax² #2 |
-  | 3 | Port3 | Access-MAIN | — |
-  | 4 | dock/monitor | Access-INFRA | Docking-Station |
-  | 5 | drucker | Access-MAIN | Drucker |
-  | 6 | Port6 | Access-MAIN | — |
-  | 7 | macmini | Access-INFRA | Mac mini |
-  | 8 | ds923+ | Access-MAIN | NAS (2. Port) |
+  | Port | Name | Profil | Gerät | Status |
+  |------|------|--------|-------|--------|
+  | 1 | uplink | Trunk-ALL | → ALLNET GE8 | ✅ korrekt |
+  | 2 | ap2 | Trunk-ALL | hAP ax² #2 | ✅ korrekt |
+  | 3 | Port3 | Access-MAIN | — (frei) | ⚠️ PVID=1 |
+  | 4 | dock/monitor | **Access-MAIN** | Docking-Station | ⚠️ PVID=1 · **Lifeline-Port, nicht anfassen** |
+  | 5 | drucker | Access-MAIN | Drucker | ⚠️ PVID=1 |
+  | 6 | Port6 | Access-MAIN | — (frei) | ⚠️ PVID=1 |
+  | 7 | macmini | Access-INFRA | Mac mini | ⚠️ PVID=1 · **fixe IP 10.40.41.x, nicht anfassen** |
+  | 8 | ds923+ | Access-MAIN | NAS (2. Port) | ⚠️ PVID=1 · **nicht anfassen** |
+- ⚠️ **Profile-PVID-Constraint (bis TP4 offen):** NAS, Mac mini und andere Geräte haben fixe IPs im
+  Bereich `10.40.41.x` (VLAN-1-Subnetz der FritzBox). Solange diese nicht auf VLAN-10/20-Subnetze migriert
+  sind, muss `nativeNetworkId=Default(VLAN 1)` in allen Access-Profilen bleiben — sonst kein DHCP, kein
+  Internet für diese Geräte. Fix nach TP4.
+- ⚠️ **Bekannter Fehler `untagNetworkIds` (Analyse 2026-06-15 via Controller-API v2):**
+  Access-MAIN hat `untagNetworkIds=[VLAN1, VLAN20, VLAN10]` (3 untagged!) statt `[VLAN10]`.
+  Access-INFRA hat `untagNetworkIds=[VLAN20, VLAN1]` statt `[VLAN20]`. Geräte erhalten Frames
+  aus mehreren VLANs ungetaggt → Inter-VLAN-Tests verfälscht. Fix erst sinnvoll nach TP4 zusammen
+  mit PVID-Korrektur.
+- **Sichere Testports (kein kritisches Gerät):** P3, P5, P6.
 - ✅ Portainer-Ablösung: **Komodo** empfohlen (einzige Option mit nativem MCP `mcp-server-komodo`). Eigener Task.
 - Abh. erfüllt: TP1 (GE8 Trunk ✅).
-- **Hinweis TP4:** Alle VLANs im Controller definiert (status=false = kein Management-IP, normal). Traffic läuft noch auf VLAN 1 bis TP4 (Router-Cutover) die L3-Interfaces aktiviert.
+- **→ TP4 wird vorgezogen:** Alle VLANs im Controller definiert (status=false = kein Management-IP, normal).
+  Traffic läuft noch auf VLAN 1 bis TP4 die L3-Interfaces + DHCP-Server je VLAN aktiviert.
 
 ### TP3 — WLAN / CAPsMAN ▸ teilweise blockiert
 - **`bound`-Problem** sauber lösen (MikroMCP, doku-gegründet) → Test-WLAN „BF-Main" → SSID→VLAN-Datapaths.
@@ -66,11 +78,14 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co
 - **Mesh = NEIN** (beide APs wired-trunk → Loop-Risiko via Router/LAN; Mesh nur sinnvoll ohne wired backhaul). Research bestätigt in TP-R.
 - Abh.: TP8 (für 802.1X). research: CAPsMAN-bound, mesh.
 
-### TP4 — Router-Cutover (hAP#1 = Router) ▸ disruptiv, geplant
+### TP4 — Router-Cutover (hAP#1 = Router) ▸ ⚡ VORGEZOGEN — nächstes TP
 - Per-VLAN L3-Interface `.1`, **DHCP** (RouterOS), **DNS = RouterOS-nativ + nur statische Records**, **NAT**, FB→**Bridge-Mode/Exposed-Host**.
 - **DNS-Entscheidung** (Technitium **und** externer BIND verworfen — Vorgabe: kein Container außer am Router, keine NAS/pve-Abhängigkeit; hAP kann praktikabel keinen DNS-Container hosten): RouterOS-DNS als Resolver, **keine DHCP→DNS-Auto-Registrierung**. Infra-Hosts (haben eh DHCP-Reservierungen) 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. Begründung/parkierte Variante A: `docs/research/dns-registration-options.md`.
 - **FB-Bridge testen** (LAN4-Native-Bridge-Hack) → kein Double-NAT; sonst Exposed-Host-Fallback.
-- Abh.: TP1, TP3. Ziel: VLAN-SSILs nutzbar + Telefonie-Fix aktiv.
+- Abh.: TP1 ✅. TP3-Abhängigkeit **entfällt** (TP4 vor TP3 ziehen; WLAN läuft weiterhin über FB bis TP3).
+- **Ermöglicht nach TP4:** PVID-Fix in Omada-Profilen (MAIN→10, INFRA→20), untagNetworkIds-Bereinigung,
+  DHCP-Reservierungen für NAS/macmini/pve auf neue VLAN-Subnetze migrieren.
+- Ziel: VLAN-Traffic vollständig segmentiert + Internet aller VLANs via NAT auf ap1.
 
 ### 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.
@@ -124,7 +139,9 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co
 ---
 
 ## Reihenfolge / Abhängigkeiten
-1. **Jetzt:** TP1 (GE8) → TP2 (Omada Controller). Parallel: Research (TP-R, TP10) laufen.
-2. **Dann:** TP3 (WLAN-bound + DoH) — 802.1X-Teil wartet auf TP8/Research.
-3. **Cutover-Block:** TP4 (Router) → TP5 (Firewall) → TP6 (QoS) → TP7 (mDNS). Disruptiv, geplant.
-4. **Nachgelagert/Research-getrieben:** TP8 (Access), TP9 (HA), TP10 (VPN), TP11 (Monitoring), TP12 (IPv6), TP13 (Spaß).
+1. ~~**Jetzt:** TP1 (GE8) → TP2 (Omada Controller).~~ ✅ erledigt 2026-06-15.
+2. **Jetzt: TP4 (Router-Cutover)** — vorgezogen, weil Profile-Fix + VLAN-Segmentierung darauf warten.
+   TP3-Voraussetzung entfällt (WLAN bleibt vorerst an FB hängen).
+3. **Nach TP4:** Omada-Profile finalisieren (PVID 10/20, untagNetworkIds bereinigen) + IP-Migration NAS/macmini/pve.
+4. **Dann:** TP5 (Firewall) → TP6 (QoS) → TP7 (mDNS) → TP3 (WLAN/CAPsMAN). Disruptiv, aber TP4 macht den Weg frei.
+5. **Nachgelagert/Research-getrieben:** TP8 (Access), TP9 (HA), TP10 (VPN), TP11 (Monitoring), TP12 (IPv6), TP13 (Spaß).