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>
This commit is contained in:
2026-06-15 19:00:40 +02:00
parent 751845a119
commit f0c08263dd
2 changed files with 85 additions and 43 deletions

View File

@@ -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ß).

View File

@@ -1,43 +1,68 @@
---
name: project-tp2-topology
description: TP2 Omada Switch + Controller — finale IPs, Portplan, API-Gotchas, offene TP3-Abhängigkeiten
description: TP2 Omada Switch + Controller — IPs, Portplan, API-Zugang, Profile-Constraint, TP4 vorgezogen
metadata:
type: project
---
TP2 ✅ abgeschlossen 2026-06-15. Omada ES208G (sw2) adopted, VLANs + Port-Profiles aktiv.
TP2 ✅ abgeschlossen 2026-06-15. Omada ES208G (sw2) adopted, VLANs + Port-Profile aktiv.
Profile haben bekannten Fehler (PVID=1, untagNetworkIds-Chaos) — Fix nach TP4.
**Finale IPs:**
- omada-controller: 10.40.41.175 (DS923/macvlan, mbentley 6.2.10.17)
- omada-mcp: 10.40.41.176 (pve-LXC endpointId=2, ipvlan, Stack 200)
- pve-mcp: 10.40.41.173 (SSE)
- sw2 (ES208G): 10.40.41.12 (adopted, FW 1.0.2 Build 20260329)
- sw2 (ES208G): 10.40.41.12 (adopted, FW 1.0.2 Build 20260329, MAC A8-29-48-EE-B9-04)
**Omada Open API Gotcha:**
- Token-Request: POST /openapi/authorize/token?grant_type=client_credentials (query param!), JSON body: {client_id, client_secret, omadacId}
- Auth-Header: `Authorization: AccessToken=<token>` (NICHT `Bearer`)
- URL-Format: `{base}/openapi/v1/{omadacId}/sites/{siteId}/...`
- omada-mcp Settings-Bug war: doppelter "omada-mcp"-Eintrag in ~/.claude/settings.json (zweiter überschreibt ersten — fixed)
**Controller-API (intern, v2) — für Writes:**
- Login: POST `/{omadacId}/api/v2/login` mit JSON `{username, password}` → token
- Requests: Header `Csrf-Token: <token>` (Cookie-Session wird mitgeführt)
- Switches: GET `/sites/{siteId}/switches/{MAC}/ports` → alle 8 Ports inkl. VLAN-Config
- Networks: GET `/sites/{siteId}/setting/lan/networks?currentPage=1&currentPageSize=20`
- Creds: christoph@emsenhuber.com / in omada/.secrets NICHT gespeichert (nur Switch-Creds dort)
**Omada Open API Gotcha (für MCP/Read):**
- Token: POST /openapi/authorize/token?grant_type=client_credentials, JSON body: {client_id, client_secret, omadacId}
- Auth-Header: `Authorization: AccessToken=<token>` (NICHT Bearer)
- URL: `{base}/openapi/v1/{omadacId}/sites/{siteId}/...`
- Port-Profile NICHT in Open API — nur in v2-intern oder Controller-UI
**Omada-MCP Tools:**
- 84 read-only Tools, OMADA_TOOL_CATEGORIES=all
- Write (VLAN/Ports) NICHT im MCP implementiert — direkte Open API oder Controller-UI nötig
- ES-Switch-Pfad: /sites/{siteId}/switches/es/{mac} (nicht /esSwitches/)
- Write NICHT im MCP — direkte v2-API oder Controller-UI .175:8043
**Port-Plan ES208G (final):**
- Port 1 (uplink) → Trunk-ALL → ALLNET GE8
- Port 2 (ap2) → Trunk-ALL → hAP ax² #2
- Port 3 → Access-MAIN
- Port 4 (dock/monitor) → Access-INFRA
- Port 5 (drucker) → Access-MAIN
- Port 6 → Access-MAIN
- Port 7 (macmini) → Access-INFRA
- Port 8 (ds923+) → Access-MAIN (2. NAS-Port, absichtlich MAIN)
**Network-IDs (VLAN-Mapping):**
- `6a2fe68fa33b9c62b13680f0` → Default (VLAN 1)
- `6a300883a33b9c62b136950d` → MAIN (VLAN 10)
- `6a3008a3a33b9c62b1369511` → INFRA (VLAN 20)
- `6a3008c2a33b9c62b1369515` → IOT (VLAN 30)
- `6a3008e1a33b9c62b1369519` → MEDIA (VLAN 40)
- `6a300903a33b9c62b1369521` → UNTRUSTED (VLAN 50)
- `6a30091ea33b9c62b1369525` → GUEST (VLAN 90)
- `6a300939a33b9c62b136952b` → MGMT (VLAN 99)
- `6a30097fa33b9c62b1369534` → WAN (VLAN 100)
**VLANs im Controller:**
VLAN 1 (Default, status=true/mgmt), 10 MAIN, 20 INFRA, 30 IOT, 40 MEDIA, 50 UNTRUSTED, 90 GUEST, 99 MGMT, 100 WAN
Alle status=false (kein Mgmt-IP konfiguriert) → normal, L3 kommt in TP4.
**Port-Plan ES208G (Stand 2026-06-15):**
- P1 (uplink) → Trunk-ALL (6a300b5b…) → ALLNET GE8 ✅
- P2 (ap2) → Trunk-ALL → hAP ax² #2 ✅
- P3 (Port3) → Access-MAIN (6a300ba6…) — PVID=1 ⚠️, sicher zum Testen
- P4 (dock/monitor) → Access-MAIN — PVID=1 ⚠️, **LIFELINE-PORT, nicht ändern**
- P5 (drucker) → Access-MAIN — PVID=1 ⚠️, sicher zum Testen
- P6 (Port6) → Access-MAIN — PVID=1 ⚠️, sicher zum Testen
- P7 (macmini) → Access-INFRA (6a3015e6…) — PVID=1 ⚠️, **fixe IP, nicht ändern**
- P8 (ds923+) → Access-MAIN — PVID=1 ⚠️, **NAS, nicht ändern**
**Why:** Traffic noch auf VLAN 1, weil TP4 (Router-Cutover, L3-Interfaces auf hAP) aussteht.
**Bekannte Fehler in Profilen (Analyse via v2-API):**
- Access-MAIN: nativeNetworkId=VLAN1 (sollte 10), untagNetworkIds=[VLAN1, VLAN20, VLAN10] (sollte [VLAN10])
- Access-INFRA: nativeNetworkId=VLAN1 (sollte 20), untagNetworkIds=[VLAN20, VLAN1] (sollte [VLAN20])
- Folge: Geräte senden ungetaggt → VLAN 1, aber empfangen Traffic aus mehreren VLANs ungetaggt
**How to apply:** Bei TP3/TP4 Arbeiten: omada-mcp read-only für Status; Writes via Open API (curl mit AccessToken= Header) oder Controller-UI .175:8043.
**PVID-Constraint (Kern-Blocker für Profile-Fix):**
NAS, Mac mini, pve etc. haben fixe IPs in 10.40.41.x (VLAN-1-Range der FritzBox).
Umbau auf PVID=10/20 bricht Konnektivität bis DHCP-Server auf diesen VLANs existiert (TP4).
Fix: nach TP4 gemeinsam mit IP-Migration aller Infra-Geräte auf 10.40.10.x/10.40.20.x.
**Why:** TP4 (Router-Cutover) ist vorgezogen — Blocker für Profiles und echte VLAN-Segmentierung.
**How to apply:** Bei TP4: L3-Interfaces + DHCP-Server auf ap1 anlegen, DANN Omada-Profile korrigieren.
Port-IDs für v2-API-Writes: /sites/6a2fe68e…/switches/A8-29-48-EE-B9-04/ports/{portId}