admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
919f8623c9c614b2ba73b886823e74af1e031280
bf-infra/CLAUDE.md
Christoph Emsenhuber 3e59383317 AP4.1 📋 Cutover-Tutorial + Session-Doku — FB-Bridge gegated auf TP10-VPN 
Schärft das Runbook zum vollständigen Solo-Tutorial (Verkabelungs-Diagramm,
WiFi/VLAN-Matrix, Schritt-für-Schritt mit Zurückbau) und schreibt den
Session-Stand für die Fortsetzung fort.

Kernpunkt: FB-Bridge ist nur ein REVERSIBLER TEST. Die BF-FritzBox terminiert
aktuell 2 produktive Site-to-Site-Tunnel (AVM LAN-LAN: 1× IPsec + 1× WG),
Ziel 2× WG auf ap1 = TP10. Voller Bridge-Mode killt diese Tunnel → permanenter
Umstieg ist auf TP10 gegated (FB bleibt bis dahin Router + VPN + Telefon).

- wan-cutover-runbook.md: TEST-Banner, Verkabelung (ether2=Uplink nie ziehen,
  ether1=WAN), Console = FritzBox-WiFi → 10.40.41.1, install-SSIDs für DHCP-Test,
  wantest-run erklärt, Zurückbau-Schritt.
- docs/teilprojekte.md: Ist-Stand + TP4 (AP4.1 Public-IP bewiesen, Testmechanismus,
  DNS-Upstream jetzt CF-DoH) + TP10 (FB hält 2 Tunnel, gated permanenten Bridge).
- CLAUDE.md: WAN-Testmechanismus, device-mode-Gotchas (scheduler/fetch blockiert,
  [/ping]=nil → :resolve), VPN-Gate, REST-Fallback.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 11:45:41 +02:00

70 lines
5.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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 | (FB-Transfer) | zur FritzBox |
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 | Web-UI HTTPS · Creds `omada/.secrets` · **Adoption pending** |
| 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 | 10.40.41.175 | `https://10.40.41.175:8043` (macvlan auf DS923) |
| omada-mcp | 10.40.41.176 | StreamableHTTP `http://10.40.41.176:3000/mcp` · MCP in Claude Code ✓ (pve-LXC) |
| pve-mcp | 10.40.41.173 | SSE `http://10.40.41.173:3000/sse` · MCP in Claude Code ✓ |
| Proxmox (pve) | 10.40.41.100 | kein SSH-Key konfiguriert |
| Docker-LXC (auf pve) | 10.40.41.126 | Portainer CE 2.40.0 (`https://10.40.41.126:9443`) |
| Mac mini | 10.40.41.167 | `ssh macmini` |
| FritzBox 6660 | 10.40.41.254 | Web-UI (Telefon bleibt dort) |
---
## 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:** Controller `https://10.40.41.175:8043` (TP2 ✅). Adoption ✅. Port-Config: manuell im Browser.
omada-mcp live auf pve-LXC (.176, StreamableHTTP /mcp, MCP in Claude Code ✓).
- **Docker-Management:** Portainer API `https://10.40.41.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.
- **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).
- 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. NAT masquerade out=bridge → FB (Double-NAT bis FB-Bridge-Mode). 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.
- **AP4.1 FB-Bridge = nur TEST/reversibel.** Public-IP `86.56.201.104` per ether1 bewiesen (kein Liwest-MAC-Lock, FB CM-MAC `0C:72:74:36:90:99`). Offline-Testmechanismus live auf ap1: `routeros/wan-cutover-{test,macclone-test}.rsc` + `wan-cutover-runbook.md`, Scripts `wantest-probe/-run`, `wanmac-clone/-revert`, Disk-Log `wan-test.0.txt`. **Console-Pfad während Cutover = FritzBox-WiFi → 10.40.41.1** (via ether2, unabhängig von ether1/LAN4). **⚠️ Permanenter Bridge-Mode gegated auf TP10** (FB hält 2 VPN-Tunnel: 1× IPsec + 1× WG → Ziel 2× WG/ap1) + Telefon.
- **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`).
Reference in New Issue View Git Blame Copy Permalink