Christoph Emsenhuber
ae4d1e5fcd
- Research-Doc: DHCP→DNS-Registrierung standardnah, PowerDNS-vs-BIND9-Vergleich - teilprojekte TP4 auf BIND9 + RFC2136 umgestellt + Verweis; HW-Notiz angepasst Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
109 lines
9.0 KiB
Markdown
109 lines
9.0 KiB
Markdown
# 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, BIND9-DNS, 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 = autoritatives BIND9 auf NAS/pve**, **NAT**, FB→**Bridge-Mode/Exposed-Host**.
|
||
- **DNS-Registrierung = Variante A** (Technitium verworfen): RouterOS-DHCP bleibt am Gateway, pusht Leases per **RFC 2136** (`/tool dns-update`, hmac-md5-TSIG) an BIND. Lease-Script + Scheduler-Reconcile; Infra-Hosts als statische Records. Detail/Begründung/PowerDNS-Vergleich: `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ß).
|