docs 📄 TP16 ✅ CF-Tunnel reziprokes 3-Tunnel-HA umgesetzt (#1033 strukturell weg)

bf-nas/bf-pve/bf-mm (je Dienst nur von Fremdhost-Connectoren), 6 Connectoren
2/Host. Loop-Smoke 19 FQDNs 0×530, HA per Host-Ausfall-Sim bewiesen.
As-Built = cf-tunnel-mapping.md §10. Offen: Access-Strang (WARP + vw) = user-gated.

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

docs/cf-tunnel-mapping.md

@@ -1,8 +1,8 @@
 # Cloudflare-Tunnel — Mapping & #1033-Diagnose (Single Source of Truth)
 
-> **Aktueller Stand: → §9 (2026-07-10, TP16).** Abschnitte 1–8 sind Historie (Track A, 2026-06-30);
-> die „3 Connectors gut/Zielbild"-Aussagen dort sind durch §9 **überholt** (Round-Robin = macvlan-Host-Isolation → 1/N-Ausfälle).
-> Track A aus `docs/handoff-cf-tunnel-1033.md`. **TP16 = Analyse turnkey, Umsetzung eigene Session.**
+> **Aktueller Stand: → §10 (2026-07-10, TP16 UMGESETZT ✅).** §9 = Analyse/Zielbild, §10 = As-Built.
+> Abschnitte 1–8 sind Historie (Track A, 2026-06-30); die „3 Connectors gut/Zielbild"-Aussagen dort sind
+> durch §9/§10 **überholt** (Round-Robin = macvlan-Host-Isolation → 1/N-Ausfälle). Track A aus `docs/handoff-cf-tunnel-1033.md`.
 
 ## 1. Alle Tunnel im Account (`393c…66c36`)
 | Tunnel | ID | Status | Conns | Verwendung |
@@ -223,3 +223,46 @@ Der macmini ist vollwertiger dritter Knoten (nicht „vergessen").
 4. **Tote Origins bereinigen:** `pbs`, `nginx-bf` (noch .41!), `hermes`, `hermes-geli`.
 5. **Access-Strang (Track B):** `hass`-400 ohne Passthrough → iPhone in **WARP** enrollen; **`vw` von bypass → geschützt**.
 6. **Loop-Gegentest** aller FQDNs (0×1033), `gateway-dw` als WG-Sonderfall klären/entfernen.
+
+---
+
+## 10. AS-BUILT 2026-07-10 (TP16 umgesetzt) — reziprokes 3-Tunnel-HA ✅
+> Gebaut & verifiziert in eigener Session. Round-Robin-#1033 **strukturell weg** (Loop-Gegentest 0×530 über alle 19 Live-FQDNs, HA per Host-Ausfall-Sim bewiesen). Schritte 1–4+HA durch; **Schritt 5 (Access/WARP + `vw`) offen** (user-gated).
+
+### 10.1 Reachability-Matrix (die Basis, read-only gemessen)
+Einzige Blindheit im System: **NAS-Connector (host-net) ↔ NAS-Docker-macvlan** (Kernel-Isolation). Alles andere cross-host-L2 / inter-VLAN-geroutet erreichbar.
+- **NAS-`vlan20` = macvlan** (parent `ovs_eth0`): gitea `.157`, grafana `.109`, pve-mcp `.173`, omada `.175`, vw `.127`, drawio `.139`, prometheus `.151`, iob_slave `.33` → **NAS-Connector blind**.
+- **pve-LXC-400-`vlan20` = ipvlan** (parent `veth20`): adguard `.16/.17`, omada-mcp `.176` → pve-Connector blind, aber **keine davon ist Tunnel-Origin** → irrelevant.
+- **macmini** = alles Docker-**bridge + Port-Publish** auf `.20.167` → keine Blindheit.
+- `ccu .232`=RaspberryMatic(qemu/330), `iobroker .107`=iob-exposed(lxc/150), `z2m25 .106`=lxc/112, `hass/ha-mcp .105`=haos(qemu/100) = **pve-Gäste auf vmbr/VLAN20** → von allen erreichbar (keine Docker-macvlan-Kinder).
+- **Ergebnis:** pve **und** macmini erreichen je 100 % der Live-Origins; NUR NAS ist für seine 5 eigenen macvlan-Dienste blind. Darum: NAS darf nie bf-nas fahren.
+
+### 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-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** |
+
+Prinzip: **jeder Host-Dienst wird von den Connectoren der ANDEREN Hosts bedient** → Host-Ausfall lässt jeden Tunnel ≥1 Connector = voll HA. Innerhalb eines Tunnels kein Route-Pinning (CF round-robined) — aber beide Connectoren erreichen 100 % → Round-Robin schadet nicht.
+
+### 10.3 Connector-Roster (6 = 2/Host, Docker `cloudflare/cloudflared:latest`, `restart=unless-stopped`)
+| Host (Portainer ep) | Container | Tunnel | Netz |
+|---|---|---|---|
+| pve-LXC (ep2) | `cloudflared-bfnas` (c80a7db) · `cloudflared-bfmm` (faa0960) | bf-nas · bf-mm | host |
+| NAS (ep14) | `cloudflared-bfpve` (97312b5) · `cloudflared-bfmm` (963217983) | bf-pve · bf-mm | host |
+| macmini (ep20) | `cloudflared-bfnas` (5c5b3ba) · `cloudflared-bfpve` (3339f86) | bf-nas · bf-pve | bridge |
+
+Tokens: nur im Container-Env + jederzeit via `GET /accounts/…/cfd_tunnel/<id>/token` (Bearer `CF_API_TOKEN`). Tunnel-IDs in `mcp/cloudflare/.env` (`CF_BF/PVE/MM_TUNNEL_ID`). **Nicht** als Compose-Stacks angelegt (raw Portainer-API-Container) → bei Neuaufbau: Container mit `TUNNEL_TOKEN=<token>` + `tunnel --no-autoupdate run`.
+
+### 10.4 As-built Verifikation
+- Loop-Smoke 19 FQDNs ×5: **0×530**. gitea/omada/vw/ds-bf/pve/portainer/ccu/iobroker/z2m25/n8n/n8n-mcp/82unkpb5 = 200; grafana 302 (Access); pve-mcp 400 (MCP-Handshake); hass 400 / ha-mcp 403 (Access davor, s. Schritt 5); gitea-mcp 404 (App-Pfad).
+- HA-Sim: macmini-Host down → bf-nas via pve (4 conns), bf-pve via NAS (4 conns), bf-mm unberührt (8) — alle Dienste weiter 200. Restore → alle 3 Tunnel 8 conns.
+
+### 10.5 Cleanup gemacht
+- Tote CNAMEs gelöscht: `pbs`, `nginx-bf`, `hermes`, `hermes-geli`. NAS-cloudflared-Leichen `oc-tzcharlie`/`oc-johnny2` entfernt.
+- `gateway-dw` (192.168.178.1, nur via WG) bleibt CNAME→bf-nas = **404** (kein BF-Connector hat die WG-Route). **Offen: klären/entfernen.**
+
+### 10.6 OFFEN — Schritt 5 Access-Strang (user-gated, s. TP16)
+- **`vw` = aktuell `bypass` (öffentlich!)** ⚠️ Sicherheitsleck. „Geschützt heben" bricht aber Vaultwarden-Clients (Bitwarden-App/Extension können kein interaktives Access-Login) → Fix = **WARP-Device-Identity** (Gerät enrollen, dann Access via Device-Posture statt Login) statt Passthrough. Entscheidung/Trade-off mit User.
+- **`hass` 400 / `ha-mcp` 403** = CF-Access davor, HA-Companion-App kann kein Access-Login → gleicher Fix: iPhone in **WARP** enrollen (`Warp Login App`-Policy `allow:christoph` existiert). Client-seitig, braucht User am Gerät.