bf-infra/docs/teilprojekte.md

BF-Netzwerk — Teilprojekte (kanonische Steuerung, Stand 2026-06-10)

Zweck: Das große Netz-Projekt in einzeln durchziehbare Teilprojekte (TP) zerlegt — jedes mit klarem Scope, aktuellen Entscheidungen, Abhängigkeiten und Status. Jedes TP ist so geschnitten, dass es eine frische Session mit sauberem Kontext straight abarbeiten kann. Architektur/Historie: ~/.claude/plans/ich-will-das-delegieren-atomic-sunrise.md.

Kanonisches VLAN-Modell (gültig — überschreibt ältere Tabellen)

VLAN	Name	Subnetz (Ziel)	Zweck
10	MAIN	10.40.10.0/24	Trusted (Handy/Laptop/Apple Watch)
20	INFRA	10.40.20.0/24	NAS/VMs/Docker/HA
30	IOT	10.40.30.0/24	Smart-Home (HA-managed), Waage, Fitness-Tracker
40	MEDIA	10.40.40.0/24	Sonos, AppleTV, TV, VuPlus, Cast-Ziele (getauscht ggü. früher)
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
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 (Standalone→adopted erwartet, TP2 ✅ 2026-06-15). Omada-Controller .175 (DS923/macvlan, mbentley 6.2, 🟢 live). omada-mcp .174 (staged, wartet auf Wizard-Passwort). 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 (inline) · Omada → Controller + omada-mcp (nach Wizard).

⚠️ 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.

---

Teilprojekte

TP1 — ALLNET Core-Switch finalisieren ▸ ✅ FERTIG (2026-06-15)

• ✅ GE8 Trunk (native vlan1, tagged 10/20/30/40/50/90/99/100) — war bereits aktiv.
• ✅ VLAN 40 umbenannt: UNTRUSTED → MEDIA (switch/cli/04-vlan50-media-untrusted.cli).
• ✅ VLAN 50 angelegt + benannt: UNTRUSTED.
• ✅ GE1/GE2 (AP-Trunks) um VLAN 50 ergänzt; GE8 auto-includiert (Trunk).
• Ergebnis: Core trägt alle VLANs (10/20/30/40/50/90/99/100) an P1/P2/P8.

TP2 — Omada Access-Switch + Controller ▸ 🔄 IN ARBEIT (2026-06-15)

• ✅ Omada Controller 6.2.10.17 auf DS923 (macvlan .175): omada/docker-compose.yml, Stack via Portainer endpointId=14. Wizard abgeschlossen (configured=true), Creds in mcp/omada/.env.
• ✅ pve-mcp (samik081) in Claude Code eingetragen (~/.claude/settings.json, SSE .173:3000).
• ✅ omada-mcp live auf pve-LXC (.126, endpointId=2), ipvlan-IP .176, Stack Id=200, in ~/.claude/settings.json.
  • Transport: StreamableHTTP http://10.40.41.176:3000/mcp (Health /health → 200, MCP-Handshake verifiziert).
  • Auth: Omada Open API Client-Credentials (NICHT User/PW). Env: MCP_SERVER_USE_HTTP/MCP_HTTP_* + OMADA_BASE_URL/OMADAC_ID/SITE_ID/CLIENT_ID/CLIENT_SECRET/STRICT_SSL. Creds in mcp/omada/.env.
  • ⚠️ Open-API-App wurde im Controller-UI angelegt (User); omadac_id=adbef8fa…, site_id=6a2fe68e…. Noch offen:
  1. Claude Code reload → omada-mcp Tools (84 Tools, read-categories) verfügbar
  2. VLANs 10/20/30/40/50/90/99/100 anlegen → .12 adoptieren → Port 2 (ap2) + Uplink → Trunk-All, Rest → Access VLAN10 (Hinweis: geladene Tool-Categories sind aktuell read-only — für VLAN/Port-Writes ggf. OMADA_TOOL_CATEGORIES um write-Scopes erweitern.)
• ✅ Port-Plan: Omada-Switch Port 2 = ap2 (Trunk all), Uplink-Port (→ ALLNET GE8) = Trunk all.
• ✅ Portainer-Ablösung: Komodo empfohlen (einzige Option mit nativem MCP mcp-server-komodo). Eigener Task.
• Abh. erfüllt: TP1 (GE8 Trunk ✅).

TP3 — WLAN / CAPsMAN ▸ teilweise blockiert

• bound-Problem sauber lösen (MikroMCP, doku-gegründet) → Test-WLAN „BF-Main" → SSID→VLAN-Datapaths.
• DoH-Upstream auf APs = Cloudflare (/ip dns use-doh-server=https://cloudflare-dns.com/dns-query verify-doh-cert=yes). Rest der AP-Config noch ~default.
• SSID-Strategie (Entscheid): NICHT naiv 1 SSID je VLAN + MAC-Filter. Besser: eine 802.1X-SSID mit dynamischer VLAN-Zuweisung (RADIUS, → TP8) für fähige Geräte; PSK-SSIDs für IoT/Guest/Media (Geräte ohne 802.1X). Einheitliche Nomenklatur BF-…. Hidden ≠ Sicherheit (nur Obscurity); MAC-Filter = schwaches Minimum, EAP-TLS/Zert deutlich besser (TP8).
• 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

• 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.

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.
• 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.

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

• Built-in mDNS-Repeater (7.16+) MAIN↔MEDIA; Cast/SSDP optional via <10MB-Container. Firewall-Holes (TP5).
• Abh.: TP4, TP5.

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.
• Abh.: TP3. (Research erledigt, s. TP-R.)

TP9 — Gateway-/Router-HA ▸ research-gated

• „Was, wenn ap1 ausfällt?" → VRRP löst Gateway-Failover je VLAN ~gratis (kreuzweise Master/Backup). ⚠️ Haken (nicht Last): DHCP/Firewall/NAT/DNS müssen auf BEIDEN APs identisch gepflegt sein, sonst „Gateway up, Internet tot". Empfehlung: VRRP nur für MAIN/INFRA, sonst ap2 als Kalt-Ersatz + Backup. DHCP/DNS schon redundant (Split + 2 Resolver).
• Abh.: TP4. (Research erledigt, s. TP-R + Config-Skizze im Report.)

TP10 — Multi-Site VPN ▸ Research fertig (docs/research/vpn-comparison.md)

• Empfehlung: Hybrid — WireGuard Site-to-Site-Backbone (BF/hAP = WG-Hub, FM/DW = FritzBox-Spokes, hub&spoke, KEINE Zusatz-HW) + WARP für Remote-User (ergänzt, ersetzt nicht).
• WARP kann FBs NICHT direkt ansprechen → bräuchte Connector-Host hinter der FB (an reinen-FB-Standorten FM/DW unattraktiv).
• Vorab-Check (User, entscheidend): WAN je Standort — public/dynamisch (OK: DynDNS/MyFRITZ) vs. CGNAT/DS-Lite am BF-Hub (= K.O. → dann CF/WARP-Pfad, CGNAT-immun).
• WG-Gotchas: keine IP aufs WG-IF (MikroTik), AllowedIPs=Tunnel+LAN-CIDRs, MTU 1412, Keepalive 25. ap1 hat noch KEIN WG (Neuaufbau).
• Abh.: WAN-Check; Hub sinnvoll nach TP4 (Router-Cutover).

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.

TP12 — IPv6 (intern + extern, 3 Standorte) ▸ research-gated

• Konzept für FM/BF/DW. → TP-R.

TP13 — „Botschafts-WLANs" ▸ fun, low-prio

• Nutzlose SSIDs mit Botschaft („Kanal 500 bitte nicht nutzen"), offenes WLAN mit Captive-Portal das auf statische Info-HTML zeigt (Nachbarschafts-WLAN-Tuning, Auto-Kanalwechsel). Idee: wer's sieht, kann auch stören → Infoseite = beste Adresse. ⚠️ Recht prüfen (Impressum/TMG, Störerhaftung bei offenem WLAN — User privat). RouterOS-Hotspot/Captive-Portal kann das.

TP-R — Router-Capabilities-Sweep ▸ FERTIG (docs/research/routeros-capabilities.md)

• Leitsatz: nativ vor Container, NAS vor Router (128MB-Flash-Limit).
• Sofort nativ (~0 RAM): RoMON · Netwatch · Scheduler + Auto-Backup/Mail · SNMP→externes Monitoring · mDNS-Repeater · spectral-scan · CAPsMAN + 802.11r/k/v (Fast-Roaming statt Mesh) · Back-to-Home/WireGuard.
• Auf NAS: FreeRADIUS(+LDAP) · NPM · icinga/Grafana · CF-Tunnel.
• Weglassen: LoRa (keine HW) · OpenFlow · CALEA · ZeroTier (CPU-Fresser bis ~60 % → WireGuard) · lokales dude.
• ✏️ Korrektur Reverse-Proxy: RouterOS 7.22+ HAT einen nativen (/ip/reverse-proxy, ACME/SNI) — aber ersetzt NPM NICHT (kein WebSocket/gRPC/Sticky, nur IPv4-Backends, TLS frisst Router-CPU) → NPM bleibt auf NAS.
• Speist TP8/9/11/12.

---

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