From 17c8fd0d24633d565685e588cc151ec296e32911 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Sun, 12 Jul 2026 20:36:37 +0200 Subject: [PATCH] =?UTF-8?q?docs=20=F0=9F=93=84=20TP16:=20bf-nas=20als=20ei?= =?UTF-8?q?gener=20Tunnel=20nachgezogen=20(Legacy-Monolith=20gel=C3=B6scht?= =?UTF-8?q?)=20+=20hass-400=20pr=C3=A4zisiert?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 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 --- docs/cf-tunnel-mapping.md | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/docs/cf-tunnel-mapping.md b/docs/cf-tunnel-mapping.md index e548a54..e66c7db 100644 --- a/docs/cf-tunnel-mapping.md +++ b/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// - **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.