docs 📄 TP16: bf-nas als eigener Tunnel nachgezogen (Legacy-Monolith gelöscht) + hass-400 präzisiert

- bf-nas neu = 220c9958 (frisch, config_src=cloudflare); Ingress 1:1, 8 CNAMEs
  umgebogen, 2 Connectoren (pve host-net / macmini bridge).
- WARP-Route 10.40.0.0/16 via PATCH teamnet/routes tunnel_id umgezogen
  (sonst DELETE-Block 1023 "private network routes").
- Legacy 70d6a4cf/bf.emsenhuber.net GELÖSCHT; .env CF_BF_TUNNEL_ID aktualisiert.
- Writes nur via CF_API_TOKEN (CF-MCP OAuth = read-only).
- hass-400 = rein Origin-Layer (hass/vw/gitea sind bypass): HA trusted_proxies
  fehlt .20.10/.20.167 → use_x_forwarded_for + IPs + Restart (user-gated, kein SSH).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/cf-tunnel-mapping.md

@@ -240,7 +240,7 @@ Einzige Blindheit im System: **NAS-Connector (host-net) ↔ NAS-Docker-macvlan**
 ### 10.2 Die 3 Tunnel (config_src=cloudflare, token-managed Ingress)
 | Tunnel | ID | Dienste | Connectoren (2/Tunnel) |
 |---|---|---|---|
-| **bf-nas** (=alter bf-Tunnel, wiederverwendet) | `70d6a4cf-…-91fab4fa7270` | gitea, grafana, pve-mcp, omada, vw, ds-bf, 3k23uow7 (+gateway-dw→404) | **pve + macmini** |
+| **bf-nas** ⚠️ *ID überholt, s. §11* | ~~`70d6a4cf`~~ → **`220c9958-401b-4111-9451-f3db09bba2d5`** (2026-07-12 frisch) | gitea, grafana, pve-mcp, omada, vw, ds-bf, 3k23uow7 (+gateway-dw→404) | **pve + macmini** |
 | **bf-pve** (neu) | `f7fdf3a6-…-b0f273794d09` | pve, j44d6tua, ccu, iobroker, z2m25, portainer, hass, ha-mcp | **NAS + macmini** |
 | **bf-mm** (neu) | `7a322261-…-8ebce99f5ed1` | n8n, n8n-mcp, gitea-mcp, 82unkpb5 | **pve + NAS** |
 
@@ -273,3 +273,16 @@ Tokens: nur im Container-Env + jederzeit via `GET /accounts/…/cfd_tunnel/<id>/
 - **Origin-Layer:** `hass.emsenhuber.net` gibt **vom Heim-Netz** (Access passt via bf4-IP) trotzdem **400** (CF `server:cloudflare`, aber Origin-verursacht) = **HA lehnt den Request ab** — HA-`http:`-Config (`use_x_forwarded_for` + `trusted_proxies` inkl. cloudflared-Range, ggf. Host-Allowlist). **Separates HA-Thema, NICHT Tunnel/Access** — offen.
 
 **gateway-dw** (192.168.178.1, nur via WG) = CNAME→bf-nas = 404 (kein BF-Connector hat WG-Route). Offen: Route bauen oder CNAME entfernen.
+
+---
+
+## 11. Nachtrag 2026-07-12 — bf-nas als EIGENER Tunnel nachgezogen ✅
+§10 hatte bf-nas noch als **wiederverwendeten Legacy-Monolith** `70d6a4cf` (Name „bf.emsenhuber.net") gefahren. Jetzt sauber getrennt:
+- **Neuer Tunnel `bf-nas` = `220c9958-401b-4111-9451-f3db09bba2d5`** (config_src=cloudflare, Ingress 1:1 kopiert). 2 Connectoren neu: pve `cloudflared-bfnas` (host-net), macmini `cloudflared-bfnas` (`cloudflared_default` bridge).
+- **8 CNAMEs** (gitea/grafana/pve-mcp/omada/vw/ds-bf/3k23uow7/gateway-dw) auf den neuen Tunnel umgebogen.
+- **WARP-Route `10.40.0.0/16`** (vnet `1480b545-…`) via `PATCH /accounts/…/teamnet/routes/{id}` `{tunnel_id}` umgezogen — **sonst Block:** DELETE-Tunnel scheitert mit `1023 „private network routes"`.
+- **Legacy-Tunnel `70d6a4cf`/`bf.emsenhuber.net` GELÖSCHT.** `mcp/cloudflare/.env CF_BF_TUNNEL_ID` = neue ID.
+- Zero-downtime: neue Connectoren parallel hoch → CNAMEs → alte Container/Tunnel weg. Verifiziert: gitea/omada/vw/ds-bf 200, grafana 302, pve-mcp 400 (MCP-Bare-GET), bf-nas 2 Connectoren healthy.
+- **Writes gehen NUR über `CF_API_TOKEN` (curl/Bearer)** — der `cloudflare`-MCP (OAuth) ist read-only (Create-Tunnel → `10000 Authentication error`).
+
+**hass-400 (2026-07-12 präzisiert):** `hass`/`vw`/`gitea` sind aktuell wieder auf **`bypass`** (App „hass, vw, gitea") → der 400 ist **rein** der Origin-Layer, **nicht Access**. HA-Log: „Received X-Forwarded-For header from an untrusted proxy **10.40.20.10**". Die reziproken bf-pve-Connectoren (macmini `.20.167`, NAS `.20.10`) fehlen in HAs `http.trusted_proxies`. **Fix** = beide IPs + `use_x_forwarded_for: true` + Core-Restart. **Kein SSH-Key auf HA `.20.105` → user-gated** (oder Zugang geben). Access-Härtung (bypass→WARP) bleibt der zweite, device-gated Schritt.