Files
bf-infra/docs/teilprojekte.md
Christoph Emsenhuber e688b37b60 Teilprojekte + MikroMCP + WLAN-Vorarbeit: Steuerungsdok, Research, MCP-Setup, CAPsMAN-Asbuilt, AP-Trunk-Guides + Port-Map
- docs/teilprojekte.md: kanonisches Projektsteuerungsdokument (TP1–TP13 + TP-R)
- docs/research/: RouterOS-Capabilities-Sweep (TP-R) + VPN-Vergleich (TP10)
- mcp/: MikroMCP + Portainer-MCP Docker-Compose, routers.yaml, READMEs, .gitignore
- routeros/: ap1-manager.rsc, ap2-cap.rsc, CAPsMAN-Flat-Asbuilt, WLAN-Handover
- switch/cli/03-trunk-ap-ports.cli + switch/ui-guides/01-trunk-ap-ports.md: AP-Trunk-Konfiguration
- docs/allnet-ge8-trunk-klickanleitung.md: GE8 Hybrid→Trunk Schritt-für-Schritt
- inventory/bf-core-ports: gi1/gi2 als TRUNK zu ap1/ap2 eingetragen (gesetzt 2026-06-09)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-15 08:42:03 +02:00

8.7 KiB
Raw Blame History

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.
⚠️ Switch-VLAN-DB trägt noch 40=UNTRUSTED (alt) und kein 50 → beim Switch-Schritt umbenennen + vlan50 anlegen.

Ist-Stand (Kurz)

ALLNET-Core .11 (FW2.2.1, VLANs 10/20/30/40/90/99/100 benannt; GE8→Trunk in Arbeit). Omada-Switch .12 (Standalone, Creds omada/.secrets). 2× hAP ax² (7.23.1): ap1 .1 (Core P1), ap2 .2 (Core P2 — bleibt vorerst). FB6660 = Router/Telefon (.254). Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen (inline) · Omada → Controller (TP2).

⚠️ 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, Technitium, Omada-Controller) laufen auf NAS/pve, nicht am hAP.


Teilprojekte

TP1 — ALLNET Core-Switch finalisieren ▸ läuft

  • GE8 Hybrid→Trunk (Omada-Uplink): native vlan1 + tagged 10,20,30,40,90,99,100 → Klickanleitung, User klickt. Danach: vlan40 umbenennen MEDIA, vlan50 (UNTRUSTED) anlegen, GE8 um 50 ergänzen.
  • Abh.: keine. Ergebnis: Core trägt alle VLANs an P1/P2/P8.

TP2 — Omada Access-Switch + Controller ▸ als Nächstes

  • Omada Software Controller als Container auf DS923 (BF) → Switch .12 adoptieren → Uplink/ap2-Port=Trunk(all), lokale=Access. Dann omada-mcp (realtydev) an Controller.
  • Abh.: TP1 (GE8 Trunk). research: omada-mcp-Setup.

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=Technitium, NAT, FB→Bridge-Mode/Exposed-Host.
  • 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ß).