Christoph Emsenhuber
c25f7ea512
TP2.1 (sw2-Standalone-Recovery) von Christoph solo abgeschlossen. TP19-Live-Sweep auf ap1 zeigt VLAN1 schon viel weiter zurückgebaut als dokumentiert (defconf-DHCP bereits disabled, cudy1→VLAN10 umgenutzt, cudy2 tot) → neuer Unterpunkt TP19.1 für den VLAN99-MGMT-Cutover. TP14.1-Rest obsolet (kein Omada-Re-Adopt mehr), TP14.3 DNS-Sweep fertig (nas/docker-Records auf ap1 korrigiert, omada/omada-mcp/fritzbox- Records entfernt, da Controller von Christoph komplett gelöscht wurde). RouterOS- Config-Backups (enthalten Live-WiFi-Passphrasen) neu gitignored. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
72 lines
8.3 KiB
Markdown
72 lines
8.3 KiB
Markdown
# BF-Netzwerk — Projekt-Kontext (auto-read)
|
||
|
||
**Standort BF:** VLAN-segmentiertes Heimnetz auf MikroTik/RouterOS. Ziel: CAKE/QoS gegen Bufferbloat,
|
||
DNS/DHCP-Ablösung, WLAN via CAPsMAN, Firewall Least-Privilege, Multi-Site VPN.
|
||
|
||
**Für jede TP-Session: zuerst `docs/teilprojekte.md` lesen** — enthält kanonischen Stand, Scope, Abhängigkeiten
|
||
und Reihenfolge aller Teilprojekte. Kein anderer Kontext nötig.
|
||
|
||
---
|
||
|
||
## VLAN-Modell (kanonisch)
|
||
| VLAN | Name | Subnetz | Zweck |
|
||
|---|---|---|---|
|
||
| 10 | MAIN | 10.40.10.0/24 | Trusted (Handy/Laptop) |
|
||
| 20 | INFRA | 10.40.20.0/24 | NAS/VMs/Docker/HA |
|
||
| 30 | IOT | 10.40.30.0/24 | Smart-Home |
|
||
| 40 | MEDIA | 10.40.40.0/24 | Sonos/AppleTV/TV/Cast |
|
||
| 50 | UNTRUSTED | 10.40.50.0/24 | Konsole/Low-Trust |
|
||
| 90 | GUEST | 10.40.90.0/24 | nur Internet |
|
||
| 99 | MGMT | 10.40.99.0/24 | Switch/AP/Hypervisor-Mgmt |
|
||
| 100 | WAN | (Arris-Transfer) | zum Arris-Kabelmodem (Liwest, Public-IP) |
|
||
|
||
GW je VLAN = `.1` · APs: ap1=`.1`, ap2=`.2` · Switches: ALLNET=`.11`, Omada=`.12`
|
||
|
||
---
|
||
|
||
## Hardware & Zugang
|
||
| Gerät | IP | Zugang |
|
||
|---|---|---|
|
||
| ALLNET Core-Switch (sw1) | 10.40.41.11 (interim, VLAN1) | `telnet 10.40.41.11` · User: `claudecode` · PW: `switch/.secrets` |
|
||
| Omada Access-Switch (sw2) | 10.40.41.12 (zuletzt bekannt, nicht neu verifiziert) | Web-UI HTTPS, **standalone ohne Controller** (TP2.1 ✅ 2026-07-16, User hat Recovery nach Werks-Reset komplett selbst gemacht) · Creds `omada/.secrets` (ggf. neu nach Reset, ungeprüft) |
|
||
| hAP ax² #1 (ap1) | 10.40.41.1 (bridge/VLAN1 Mgmt) | MikroMCP (live) · **TP4 ✅: L3-Router, GW je VLAN = .1** |
|
||
| hAP ax² #2 (ap2) | 10.40.41.2 | MikroMCP (live) · **Port 2 am Omada-Switch** |
|
||
| NAS (nas-bf, DS923) | 10.40.41.10 | SSH · Docker (Portainer endpointId=14) |
|
||
| ~~Omada-Controller~~ | — | ❌ **entfernt 2026-07-16** (User hat den Container gelöscht — overkill für 1 Switch auf der Abschussliste, s. TP2.1/TP15) |
|
||
| ~~omada-mcp~~ | — | ❌ **entfernt 2026-07-16** — mit dem Controller gelöscht. MCP-Eintrag in Claude-Settings/`~/.claude.json` ist verwaist (Server wird nie mehr connecten), Aufräumen dort noch offen |
|
||
| pve-mcp | 10.40.20.173 | **StreamableHTTP `http://10.40.20.173:3000/` (Root-Pfad, NICHT /sse)** · NAS-Stack ep14 (=nas-bf `.20.10`, NICHT LXC .126!) id 202 (vlan20-only, TP14.1 2026-07-10) · **mcp-pve v0.6.1 (Upgrade 2026-07-10: Single-Session-Bug 0.4.8 „Server already initialized" gefixt, TP14.2a)** · `~/.claude.json` ✓ |
|
||
| Proxmox (pve) | 10.40.20.100 | `ssh root@10.40.20.100` (SSH-Key ✓) · **TP14 2026-07-13: Host-Mgmt VLAN1→VLAN20** (vmbr0.20 + Default-GW-Flip); `.41.100` bleibt interim ohne Route |
|
||
| Docker-LXC (auf pve) | 10.40.20.126 | Portainer CE 2.40.0 (`https://10.40.20.126:9443`) · **TP14.2 2026-07-10: LXC 400 net0 tag=20/.20.126 (iface heißt jetzt `veth20`, NICHT eth0); Docker-Netz `vlan20`=ipvlan parent `veth20`; adguard_bf1 .20.16, adguard_fm2 .20.17** |
|
||
| Mac mini | 10.40.41.167 | `ssh macmini` |
|
||
| Arris-Kabelmodem | (Bridge-Mode, keine Mgmt-IP im BF-LAN) | Liwest-Edge, physisch an sw1 gi16 · **FritzBox 6660 seit 2026-07-01 komplett ausgebaut** (Liwest-Tausch, kein Zurück); Telefonie war auf der FB und wird nicht weitergeführt |
|
||
|
||
---
|
||
|
||
## Tooling
|
||
- **MikroTik (hAP ax²):** MikroMCP-Server live verbunden → `mcp__mikromcp__*`-Tools verwenden.
|
||
Reads immer safe; Writes mit `dryRun:true` previwen, dann `apply_plan`.
|
||
- **ALLNET-Switch:** kein MCP — nur Telnet-CLI (IOS-artig, FW 2.2.1). Runner:
|
||
`cd ~/dev/bf-network-r6/switch && . ./.secrets && expect cli/run-cli.exp cli/<datei>.cli`
|
||
Klickanleitungen in `switch/ui-guides/` für manuelle Schritte.
|
||
- **Omada-Switch (sw2):** seit TP2.1 (2026-07-16) **standalone ohne Controller**, direkt über eigenes Web-UI konfiguriert. Der Controller ist mittlerweile **komplett gelöscht** (User 2026-07-16, overkill für 1 Switch auf der Abschussliste) — Omada-Ecosystem hat generell keine Rolle mehr im Netz (TP15-Korrektur). **omada-mcp ebenfalls gelöscht**, MCP-Registrierung in Claude-Settings ist verwaist.
|
||
- **Docker-Management:** Portainer API `https://10.40.20.126:9443`, Key in `mcp/portainer/.env`.
|
||
Ablösung durch Komodo (native MCP) geplant.
|
||
|
||
---
|
||
|
||
## Kritische Gotchas
|
||
- **ALLNET: nur 1 Telnet-VTY** — stale Sessions blockieren ~15 min. Sauber ausloggen (`exit exit`), nie hammern.
|
||
- **`save` nicht vergessen** nach ALLNET-Änderungen (sonst nach Reboot weg).
|
||
- **hAP ax² hat 128 MB Flash, kein USB** → Container NICHT auf dem Router; Container laufen auf NAS/pve.
|
||
- **VLAN20-Docker-Hosts: Host-DNS nach dem Umzug prüfen (2026-07-10, TP14.2a):** NAS + pve-LXC zeigten `/etc/resolv.conf` noch auf totes `.41.254` → `docker pull` ghcr scheitert (`EAI_AGAIN`, aber Egress ok!). Fix = `.20.1`: LXC `pct set 400 --nameserver 10.40.20.1`; **Synology-Falle: DSM-„Allgemein"-DNS ≠ was `dockerd` liest** — Interface zieht DNS per DHCP → Fix an der *Netzwerkschnittstelle* „DNS manuell". Laufende Container frieren den `127.0.0.11`-Upstream zum Erstellzeitpunkt ein (Recreate nötig). Merkregel: `docker-pull-hängt` + `dns.lookup EAI_AGAIN` aber `TCP zu ghcr-IP:443 ok` = toter Resolver, nicht Egress.
|
||
- **ALLNET VLAN-DB final (TP1 ✅):** 40=MEDIA, 50=UNTRUSTED; GE1/GE2/GE8 alle als Trunk mit 10/20/30/40/50/90/99/100.
|
||
- **Omada-Switch Port 2 = ap2** (Trunk all VLANs), Uplink-Port → ALLNET GE8 (Trunk all), Restports = Access.
|
||
- **Mesh = NEIN** (beide APs haben wired Trunk-Uplink → Loop-Risiko).
|
||
- **ap2 (CAP) braucht `vlan-filtering=yes` mit ether2-Trunk (TP3.1 ✅ 2026-07-01):** local forwarding → `datapath.vlan-id` wird nur bei vlan-filtering auf die Leitung geschrieben. Ohne → ALLE ap2-WLAN-Clients ungetaggt in VLAN1 (defconf/10.40.41.x). Nur Master-Radios wifi1/wifi2 sind Bridge-Ports (Slave-VAPs forwarden darüber) → wifi1/wifi2 müssen manuell tagged-Member je Client-VLAN sein (CAPsMAN legt das auf dem CAP NICHT an). As-built `routeros/tp3.1-ap2-vlan.rsc`. VLAN1 MUSS untagged=bridge,ether2 bleiben (Mgmt/MCP-Pfad 10.40.41.2, kein Scheduler → Recovery = Power-Cycle OG). Widerlegt „ein CAP hält keine Config" (galt nur für Manager-Forwarding).
|
||
- mgmt-VLAN-Wechsel am Switch = Lockout-Risiko: VLAN muss existieren + Port muss es tragen, in einem Schritt.
|
||
- **Omada ES208G = Easy Managed** → Controller-adoptierbar (ab 6.1.x), nur Basis-VLAN/QoS im Controller (kein ACL/Policy-Routing).
|
||
- **TP4 ✅: ap1 ist L3-Router.** Bridge mit vlan-filtering=yes; VLAN1 untagged (Mgmt/Transition); vlan10-99 Subinterfaces mit DHCP+DNS. DNS: 13 statische A-Records bf.lan, **Upstream seit 2026-06-16 = DoH Cloudflare Gateway** (servers=1.1.1.1 Bootstrap). Omada-PVID-Fix (→ .10/.20-Subnetze) ist nächster Schritt.
|
||
- **✅✅ Edge-Cutover vollzogen (2026-07-01): FritzBox komplett ausgebaut, Arris-Kabelmodem im Bridge-Mode.** Liwest hat die FB6660 dauerhaft gegen ein Arris-Kabelmodem getauscht (physisch weg, kein Zurück). WAN läuft über den Core-Switch (Arris→sw1 gi16 Access VLAN100→gi15 Trunk→ap1 ether2→`vlan100` auf bridge), NICHT über ether1. ap1 zieht öffentliche Liwest-IP direkt → Double-NAT weg, ap1 = Public-Edge. Vorarbeit dazu: TP10 (beide VPN FM/DW von FB auf ap1-WG-Hub migriert, 2026-06-27) hat den Bridge-Mode entblockt. Telefonie war auf der FB und wird **nicht weitergeführt** (User-Bestätigung 2026-07-02). Details/Runbooks: `routeros/wan-cutover-runbook.md`.
|
||
- **ap1 RouterOS-Scripting (device-mode=home):** **scheduler + fetch blockiert** (`not allowed by device-mode`) → keine Scheduler in Scripts, Autonomie via Loop-Script. **`[/ping]` gibt nil in 7.23**, ICMP geblockt → Reachability via `:resolve` (server=1.1.1.1 = Routing-Test, ohne server = DoH). MikroMCP-Tools können droppen → Fallback REST `http://10.40.41.1/rest` (Creds = ROUTER_AP1 in `~/.claude.json`).
|
||
- **WLAN dozende Legacy-Clients nur auf ap1 erreichbar, NICHT via CAP ap2 (2026-07-02, P750W-Fall):** L3-GW liegt auf ap1 → ARP-Broadcast an schlafenden Client wird nur am co-located AP zuverlässig zugestellt; Remote-CAP ap2 puffert Broadcast-ARP unzuverlässig. Fix = geordneter wifi-access-list-Pin auf ap1 (`0 accept interface=w2-iot` → `1 reject` ohne Interface = überlebt ap2-Re-Provision). **Merkregel: DHCP-geht-aber-Ping-nicht = ARP/Power-Save, NICHT Routing/L2/MTU/Switch.** Coverage-Kanten/Terrasse grenzwertig (−76..−89 dBm, 4-Radio-Ping-Pong); TX schon am AT-Max (18/15 dBm, kein Hebel); Steering `neighbor-group=bf-main` gesetzt; echter Fix = Platzierung (offen, Tageslicht). SSoT `docs/wifi-p750w-coverage-and-map.md`.
|