Christoph Emsenhuber 3113218212 TP16.2: vw bleibt bypass (harter Constraint) — Haertung ohne Client-Bruch
User-Constraint 2026-08-14: vw wird NICHT WARP-/Access-geschuetzt, dauerhaft.
Begruendung ist technisch, nicht Bequemlichkeit — die Bitwarden-Clients koennen
den interaktiven Access-Login nicht (dasselbe Muster wie der 400er der
HA-Companion-App). Ein Passwortmanager hinter einem Client, den man im Notfall
nicht installieren kann, ist ein Aussperr-Risiko gegen den eigenen Schluesselbund.
Die TP16-Schritt-5-Absicht "vw von bypass auf geschuetzt heben" ist gestrichen.

Neu: TP16.2 — Haertung aller bypass-Dienste (vw, hass, gitea) in Schichten:
- Schicht 0 (vorhanden): keine offenen Ports, alles ueber CF-Tunnel.
- Schicht 1: Access nur auf /admin* als eigene, spezifischere Application —
  CF wertet die spezifischste App zuerst. Das Admin-Panel wird nur per Browser
  bedient, die Client-Pfade (/api, /identity) bleiben bypass. Kein Client bricht.
- Schicht 2: App-eigene Limits (Vaultwarden LOGIN_RATELIMIT_* sind default an),
  Signups aus, 2FA erzwingen; HA ip_ban_enabled.
- Schicht 3: CF WAF/Rate-Limiting gezielt auf die Login-Endpunkte.
- Schicht 4: CrowdSec/fail2ban mit CF-Bouncer — Bans an der Edge, alle Dienste.

Knackpunkt und Schritt 1: hinter dem Tunnel sieht die App nur die IP des
cloudflared-Containers. Jede IP-Sperre bannt sonst den Tunnel statt den
Angreifer = Selbstaussperrung. Genau dieser Defekt ist schon offen (HA
trusted_proxies fehlen .20.10/.20.167) — X-Forwarded-For/CF-Connecting-IP
sauber durchreichen ist Voraussetzung fuer Schicht 2-4.

Nebeneffekt: TP23s Managed-Networks-Weg ist entlastet — vw verlangt nie
Device-Identity, "WARP zuhause aus" kollidiert nicht mehr mit dem Access-Strang.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-14 16:32:42 +02:00
2026-06-15 19:00:40 +02:00

bf-network-r6

BF-Netzwerk-Migration (Variante R6+C2). 2× MikroTik hAP ax² + Core ALL-SG8316M.

SSOT & Übergabe: HANDOVER.md — kompletter Status, Architektur + Begründungen, Phasen, Gotchas, Zugänge.

Plan-Origin: ~/.claude/plans/welche-kosteng-nstigen-alternativen-zu-memoized-sparkle.md

Struktur:

  • docs/vlan-plan.md — VLAN-/Adressplan (final)
  • docs/core-switch-prep.md — Core-Switch Status & Phasen
  • docs/firmware-flash-runbook.md — FW-Flash Historie
  • switch/cli/CLI-REFERENCE.md — bestätigte CLI-Syntax
  • switch/cli/*.cli / *.exp — reproduzierbare Konfig-Scripts
  • inventory/bf.csv / bf.md — IP-Doku (aus IPs.xlsx gespiegelt)
  • inventory/bf-core-ports.csv / .md — Switch-Port-Map

Aktueller Stand (2026-06-09):

  • Phase A (VLAN-Vorbereitung) ✅ abgeschlossen
  • Phase B (hAP-Cutover) ⏳ wartet auf MikroTik-Lieferung
  • Phase C (Firewall) + Phase D (Adress-Migration) ausstehend
Description
BF-Infrastruktur (Fork von bf-network-r6): MikroTik, Caddy, AGH, Nautobot/GC, MCPs. Master seit 2026-08-27.
Readme 21 MiB
Languages
Python 57.9%
RouterOS Script 33.8%
Jinja 6.6%
Shell 1.7%