Christoph Emsenhuber
d5b3ce37ff
Auslöser (User 2026-08-31): beim Core-Neustart war crs326-branch nicht mehr erreichbar, weil sein Management ausschliesslich ueber den Core laeuft. Live nachgemessen: auf dem Branch ist vlan99 tagged=ether1,ether24,bridge mit untagged="" - es gibt also keinen Weg zu 10.40.99.2, der nicht durch den Core fuehrt. Wer den Core zerkonfiguriert, verliert den Branch gleich mit und damit die Moeglichkeit, es vom Branch aus zu reparieren. Zweiter, unangenehmerer Befund: crs326-branch hat GAR KEINE input-Regeln (Kette leer). Sein gesamter Schutz besteht heute darin, dass VLAN99 nur ueber den Core erreichbar ist und dessen forward-Kette deny-by-default faehrt - die Erreichbarkeitsbeschraenkung IST die Zugangskontrolle. Damit ist ein untagged MGMT-Port ein physischer Generalschluessel, und das TP traegt eine explizite Auflage: Port disabled im Normalbetrieb ODER input-Regeln auf beiden Switches ODER physische Sicherung. Empfehlung im Abschnitt: die input-Regeln, weil sie eine Luecke schliessen, die unabhaengig von diesem TP besteht. Kandidat ether23 - auf core und branch beide running=false, also frei, und auf beiden Geraeten dieselbe Nummer. Abnahme im Abschnitt so formuliert, dass sie den Zweck prueft: Laptop an branch ether23, Core-Trunk gezogen, 10.40.99.2 muss antworten. Alles andere misst nur den Normalfall. Quick-Index (nach TP36 einsortiert), TP-Abschnitt und Ist-Stand mitgezogen; Handover 20260831 auf den angelegten TP umgestellt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bf-infra
BF-Netzwerk-Infrastruktur (Caddy, AGH, MikroTik-Konfig, Dokumentation, MCPs).
Aktiver Fork von bf-network-r6 (Claude-Code-Architektur, 2025-2026), ab August 2026
unter OpenCode und anderem LLM weitergepflegt.
Master-Struktur
| Repo | Rolle | Stand |
|---|---|---|
~/dev/bf-infra/ + admin/bf-infra (Gitea) |
Aktiver Master | Remote seit 2026-08-30, main synchron — Backup-Lücke geschlossen |
admin/bf-network-r6 (Gitea) |
Archiv, historischer Master | read-only-Header, letzte aktive Commits 2026-08-25 |
admin/bf-golden-config (Gitea) |
Bot-Master (Nautobot 2×/Tag) | intended/ + backups/, nicht manuell |
admin/blaueblueten-n8n (Gitea) |
Master für terpene-Repo | aktiv, lokal synchron |
Was hier lebt
docs/teilprojekte.md— kanonische Steuerung (Ist-Stand, offene TPs, kritischer Pffad)docs/teilprojekte-archiv.md— abgeschlossene TPs (Volltext)docs/handoff-*.md— Session-Übergabencaddy/Caddyfile— Reverse-Proxy BF (siehe TP34 für Migration zu Nautobot/GC)nautobot/— Skripte + Jinja-Template für Golden Configmcp/— MCP-Server-Inventar (SSoT gegen „1000 MCP-Leichen")inventory/— entfernt 2026-08-27 (Pipeline seit 2025-06 stale; Live-Daten via MikroMCP/CF/Portainer)
Status (2026-08-27)
- L3 + WAN-Edge =
crs326-core, alle 4 MikroTik auf RouterOS 7.24 (TP27) - Firewall deny-by-default seit 2026-08-18 (TP5)
- WLAN via CAPsMAN auf dem Core seit 2026-08-17 (TP28)
- Compliance 104/104 grün, 0 Drifts (Golden Config, TP22)
- AdGuard-Paar
agh-bf1/agh-bf2aufgebaut, DHCP noch nicht umgestellt (TP23 Stufe 2 / TP31 Schritt 4) - Caddyfile Reverse-Proxy seit 2026-08-25 (TP31), 16 Sites BF-intern
- terpene.teilzeitladen.xyz: Worker läuft auf Mac mini (10.40.20.167:8890), kein Caddy-Block, kein CF-Tunnel — Backfill via DB-Migration blockiert (Handoff 2026-08-27)
Übergangspfad von bf-network-r6 → bf-infra
- README + Strukturen aktualisiert (dieses File)
- bf-network-r6 im Gitea auf read-only, Header mit Verweis (deine Aktion)
- Inventar-Pipeline gelöscht (XLSX stale, MikroMCP/CF/Portainer liefern Live)
- Caddyfile-Master wandert zu Nautobot/GC (TP34, siehe Handoff 2026-08-27)
- bf-infra bekommt Gitea-Remote (offen, „später")
Werkzeuge (Stand 2026-08-27)
- MikroMCP (RouterOS, 4 Geräte) —
~/.claude.json+opencode.jsonc - pve-mcp (Proxmox, 10.40.20.173) —
opencode.jsonc - home-assistant (HA, 10.40.20.105) —
opencode.jsonc - cloudflare (CF-API, OAuth) —
opencode.jsonc - gitea-mcp (FQDN) —
opencode.jsonc - komodo-mcp (geplant, Migration von Portainer) —
~/dev/bf-infra/mcp/komodo/ - shelly-mcp (Client-lokal Interim, 127.0.0.1:3030) — vor Migration auf zentralen Container