31132182128693d7bce1155d6fd380b6c127f013
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>
docs 🧭 Governance „Config nur via Nautobot" + TP19.1-Stand (ap1-DNS ✅, ap2 vertagt), sw2-IP-Korrektur .41.181, VLAN99-Cutover-Guides sw1/sw2, TP15-Lieferung 17.07., TP20 an Komodo gebunden
docs 🧭 Governance „Config nur via Nautobot" + TP19.1-Stand (ap1-DNS ✅, ap2 vertagt), sw2-IP-Korrektur .41.181, VLAN99-Cutover-Guides sw1/sw2, TP15-Lieferung 17.07., TP20 an Komodo gebunden
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 & Phasendocs/firmware-flash-runbook.md— FW-Flash Historieswitch/cli/CLI-REFERENCE.md— bestätigte CLI-Syntaxswitch/cli/*.cli/*.exp— reproduzierbare Konfig-Scriptsinventory/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.
Languages
Python
57.9%
RouterOS Script
33.8%
Jinja
6.6%
Shell
1.7%