docs 📄 TP16 turnkey: CF-Tunnel Round-Robin=macvlan-Host-Isolation → reziprokes HA (Umsetzung eigene Session)

Root-Cause endgültig (User-Diagnose bestätigt): ein cloudflared ist blind NUR
für macvlan/ipvlan-Container auf seinem EIGENEN Host → mehrere Connectoren auf
1 Tunnel + Round-Robin = 1/N garantierte 1033 ("jeden 3. Schuss eine Niete").
Kein Route→Connector-Pinning innerhalb eines Tunnels → HA nur über getrennte
Tunnel: reziprokes Per-Host-Design (jeder Dienst von den anderen Hosts bedient,
3 Tunnel/2 cloudflared je Host = voll HA gegen Single-Host-Ausfall).

- cf-tunnel-mapping.md §9: Invariante + Live-Inventory v119 (Access-Modi,
  DOWN-Origins pbs/nginx-bf/hermes×2) + Ziel-Design + Umsetzungsreihenfolge;
  Abschnitte 1-8 als Historie markiert.
- teilprojekte.md TP16 umgeschrieben: Root-Cause, reziprokes HA, Access-Strang
  (hass-400=CF-Access→WARP, vw=bypass→schützen), Status "dokumentiert,
  Umsetzung = eigene Session".
- Reine Doku, keine Tunnel-/DNS-/Container-Änderung.

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

docs/cf-tunnel-mapping.md

@@ -1,7 +1,8 @@
 # Cloudflare-Tunnel — Mapping & #1033-Diagnose (Single Source of Truth)
 
-> **Stand:** 2026-06-30 · erstellt via `cloudflare`-MCP (live) + Portainer-API + macmini-Probe.
+> **Aktueller Stand: → §9 (2026-07-10, TP16).** Abschnitte 1–8 sind Historie (Track A, 2026-06-30);
-> Track A aus `docs/handoff-cf-tunnel-1033.md`. **Diagnose abgeschlossen — Fixes noch NICHT angewendet** (warten auf Freigabe).
+> 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.**
 
 ## 1. Alle Tunnel im Account (`393c…66c36`)
 | Tunnel | ID | Status | Conns | Verwendung |
@@ -166,3 +167,59 @@ mehrere Connectors aktiv: macmini (`.20.167`, VLAN20) erreicht NAS-Macvlan, sche
 pve-lokalen Origins/pbs/gateway-dw; NAS-eigener host-net-Connector taugt nicht (Host↔eigene-Macvlan-
 Isolation). Zielbild = **ein** Connector, der alles erreicht — löst sich weitgehend von selbst, sobald
 pve (+ Connector) mit dem PVID1-Cutoff in VLAN20 wandert (dann sind Origins+Connector im selben L2).
+
+---
+
+## 9. Ist-Inventory & Endanalyse 2026-07-10 (TP16) — SSoT-Stand
+> ⚠️ Die „3 Connectors sind gut/Zielbild"-Framings der Abschnitte 2/6/8 oben sind **überholt** — maßgeblich
+> ist dieser Abschnitt. **Analyse turnkey; Umsetzung = eigene Session** (User-Entscheidung).
+
+### 9.1 Invariante (die Regel, an der alles hängt)
+- **Ein cloudflared-Connector ist blind NUR für macvlan/ipvlan-Container auf seinem EIGENEN Host**
+  (Linux-Kernel: Host ↔ eigene macvlan/ipvlan-Children isoliert). Fremdhost-L2 + co-lokierte *Bridge*-Container
+  erreicht er sehr wohl.
+- **Mehrere Connectoren auf EINEM Tunnel = geteilter Ingress + CF-Round-Robin.** Jede Origin, die auf dem Host
+  *eines* Connectors als macvlan/ipvlan liegt, fällt bei ~**1/N** der Requests aus (#1033, „jeden 3. Schuss eine Niete").
+  **Strukturell** — nicht durch „Origins fixen" heilbar, solange ein Connector Origins seines eigenen Hosts bedient.
+- **Kein Route→Connector-Pinning INNERHALB eines Tunnels.** „Ausgewählte Routen für ausgewählte Connectoren" gibt
+  es nur über **getrennte Tunnel** (CNAME → jeweiliger Tunnel; pro Tunnel eigene Connectoren).
+
+### 9.2 Live-Inventory (gemessen 2026-07-10, Ingress **v119**, 24 Hostnames + catch-all, 2 live Connectoren `b797ee1b`/`f480dc69`)
+CF-Access: **`vw` = `bypass` (ÖFFENTLICH!)** ⚠️ · `hass` & Rest geschützt via Wildcard `*.emsenhuber.net`
+(`allow:christoph` / `non_identity:bf4` / `allow:claude-mcp`).
+
+| Hostname | Origin | Live | Host/Netz (zu verifizieren) |
+|---|---|---|---|
+| pve / j44d6tua(ssh) | `.41.100:8006` / `:22` | UP | Proxmox-Host (VLAN1) |
+| hass / ha-mcp | `.20.105:8123` / `:9583` | UP | HA-Host .105 |
+| pbs | `.20.135:8007` | **DOWN** | Proxmox Backup Server |
+| n8n / hermes / hermes-geli / gitea-mcp / n8n-mcp / 82unkpb5(ssh) | `.20.167:*` | n8n/mcp UP · **hermes+hermes-geli DOWN** | macmini |
+| portainer | `.20.126:9443` | UP | pve-LXC (host-net) |
+| nginx-bf | `.41.123:81` | **DOWN** | **noch VLAN1!** |
+| ds-bf / 3k23uow7(ssh) | `.20.10:8080` / `:22` | UP | NAS-Host |
+| gitea / grafana / pve-mcp | `.20.157` / `.20.109` / `.20.173` | UP | **NAS-macvlan** (NAS-Connector-blind) |
+| omada | `.20.175:8043` | UP | **NAS-macvlan** (NAS-Connector-blind) |
+| ccu / vw / iobroker / z2m25 | `.20.232` / `.20.127` / `.20.107:8081` / `.20.106:8080` | UP | **Host/Netz unklar → messen** |
+| gateway-dw | `192.168.178.1` | — | **nur via WG** (kein BF-Connector hat Route) |
+
+### 9.3 Ziel-Design: reziproke Per-Host-Tunnel (HA)
+Jeder Host-Dienst wird von den Connectoren der **anderen** Hosts bedient (nie vom eigenen), gegenseitig:
+
+| Tunnel (= Dienste eines Hosts) | Connectoren auf | HA |
+|---|---|---|
+| pve-Dienste | NAS + macmini | 1 abdrehbar |
+| NAS-Dienste (omada/pve-mcp/gitea/grafana/…) | pve + macmini | 1 abdrehbar |
+| macmini-Dienste (`.20.167`) | pve + NAS | 1 abdrehbar |
+
+3 Tunnel, jeder Host fährt **2 cloudflared** (für die 2 anderen Tunnel) → Host-Ausfall ⇒ jeder Tunnel ≥1 Connector = **voll HA**.
+Der macmini ist vollwertiger dritter Knoten (nicht „vergessen").
+
+### 9.4 Umsetzungs-Reihenfolge (eigene Session)
+1. **Reachability-Matrix je Host** (pve/NAS/macmini → jede der 24 Origins, read-only) — klärt v.a. `vw`/`ccu`/`iobroker`/`z2m25`
+   (Bridge nur-eigener-Host? macvlan? ipvlan-auf-pve → dann pve-blind!). Ergebnis bestimmt die Tunnel-Gruppierung.
+2. **Interim-Sofortfix:** bf-Tunnel auf **pve-only** (pve erreicht alles außer gateway-dw) → 0×1033. Reversibel.
+3. **Reziprokes 3-Tunnel-HA bauen:** 3 Tunnel anlegen, ~24 CNAMEs re-pointen, 6 Connectoren (2/Host, je eigenes Token),
+   Alt-Token aus NAS/macmini-cloudflared entfernen. `vw`/`ccu` ggf. auf VLAN20-macvlan heben (dann L2-erreichbar).
+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.

docs/teilprojekte.md

@@ -330,13 +330,24 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - **Nächster Schritt:** Entscheidungen treffen, dann Konfiguration + Bestellung.
 - Abh.: TP14 (IP-Migration VLAN1→VLAN20 sollte abgeschlossen sein, damit Ziel-IPs feststehen).
 
-### TP16 — CF-Tunnel-Erreichbarkeit / FQDN-Auflösung härten ▸ 🔴 HOCHDRINGLICH (2026-07-10) — `docs/cf-tunnel-mapping.md`, #1033
+### TP16 — CF-Tunnel: Round-Robin killen + reziprokes HA ▸ 🔴 HOCHDRINGLICH, dokumentiert — **Umsetzung = eigene Session** (2026-07-10) — `docs/cf-tunnel-mapping.md §9`, #1033
-> **Eigenes, hochdringliches Paket** (User-Auftrag 2026-07-10). Setzt #1033 fort: Track A war 2026-06-30 „komplett", aber die Round-Robin-Asymmetrie ist **zurück**, weil (a) alle 3 Connectoren wieder laufen und (b) NAS/pve seither weiter nach VLAN20 gewandert sind (TP14.1/14.2) → Ingress-Origins evtl. erneut asymmetrisch.
+> **Eigenes, hochdringliches Paket** (User 2026-07-10). Der erste Report „FQDNs via Cloudflare sehr unsicher" + diese Vertiefung (Root-Cause, HA, Access) sind **EIN Paket = TP16**. Setzt #1033 fort. **Analyse fertig & turnkey dokumentiert; das Umsetzen macht bewusst eine eigene Session.**
-- **Symptom (User):** FQDNs über Cloudflare werden **sporadisch / „sehr unsicher"** aufgelöst → #1033-Muster kehrt zurück. „Tunnelerreichbarkeit ggf. neu machen." User hat **alle 3 cloudflared-Images + Container aktualisiert und neu gestartet** (für Diagnose bereit).
+- **Symptom (User):** FQDNs über CF werden **sporadisch / „sehr unsicher"** aufgelöst = #1033-Muster zurück („jeden 3. Schuss eine Niete"). User hat alle 3 cloudflared-Images + Container aktualisiert/neu gestartet.
-- **Live-Snapshot (2026-07-10 ~16:18, cf-MCP):** Tunnel `bf.emsenhuber.net` (`70d6a4cf-…-91fab4fa7270`) = healthy, **8 conns = nur 2 *distinct* Connectoren** (`b797ee1b`, `f480dc69`), cloudflared **`2026.7.1`** (frisch), alle Origins egress via **BF-Public-IP `90.146.35.38`** (= alle Connectoren jetzt BF-/VLAN20-seitig). ⚠️ **User startete 3, CF sieht nur 2** → ein Connector registriert sich NICHT am bf-Tunnel (welcher Host? pve-LXC/NAS/macmini-Logs prüfen). Connector-IDs sind neu — die im Mapping-Doc (`1856dfc3/db713b30/d7454e68`) sind **stale** (Recreate mintet neue).
+- **✅ Root-Cause endgültig (User-Diagnose bestätigt): macvlan/ipvlan-Host-Isolation.** Ein cloudflared-Connector ist **blind für macvlan/ipvlan-Container auf seinem EIGENEN Host** (Linux-Kernel-Regel), erreicht aber Fremdhost-L2 + co-lokierte Bridge-Container. Mehrere Connectoren auf EINEM Tunnel = geteilter Ingress + CF-**Round-Robin** → jede Origin, die auf dem Host *eines* Connectors liegt, fällt bei ~**1/N** aus. **Strukturell**, nicht durch „Origins fixen" heilbar. Bsp: `omada .20.175`/`pve-mcp .20.173`/`gitea .20.157`/`grafana .20.109` = NAS-macvlan → vom NAS-Connector NICHT erreichbar.
-- **Root-Cause (unverändert #1033):** 3 Connectoren = selber Token → CF round-robined → **jeder Origin muss von ALLEN Connectoren erreichbar sein**, sonst sporadisch 1033. Token-managed Ingress (CF-Dashboard) kann noch `.41`/pve-lokale/stale Origins enthalten, die nur ein Connector erreicht.
+- **Invariante:** innerhalb EINES Tunnels ist **kein Route→Connector-Pinning** möglich (alle Connectoren teilen Ingress, CF round-robined). „Ausgewählte Routen für ausgewählte Connectoren" = **getrennte Tunnel**.
-- **Next (Reihenfolge):** (1) fehlenden 3. Connector finden (Container-Logs je Host); (2) **Ingress-Origins auditieren** — jeder Hostname → VLAN20-IP, die ALLE Connectoren erreichen (kein `.41`/pve-local/stale); (3) Origins/DNS gegen `docs/cf-tunnel-mapping.md` abgleichen + nachziehen (scoped API-Token `mcp/cloudflare/.env`, OAuth-MCP evtl. read-only); (4) tote Tunnel/Orphan-CNAMEs aufräumen; (5) FQDN-Auflösung im **Loop gegentesten**. **Alternative erwägen:** auf **1 symmetrischen Connector** reduzieren statt 3 asymmetrische (robuster, wenn Symmetrie schwer herstellbar — vgl. #1033 „Stufe 1 pve-only").
+- **Ziel-Design (HA): reziproke Per-Host-Tunnel** — jeder Host-Dienst wird von den Connectoren der ANDEREN Hosts bedient (nie vom eigenen):
-- Abh.: TP14.1/14.2 ✅ (Origins in VLAN20). Verwandt: **TP11** (CF-Tunnel-Track-B/C), #1033. SSoT: `docs/cf-tunnel-mapping.md`. Memory `project_cf_tunnel_1033`.
+
+  | Tunnel (= Dienste eines Hosts) | Connectoren auf | HA |
+  |---|---|---|
+  | pve-Dienste | NAS + macmini | 1 abdrehbar |
+  | NAS-Dienste (omada/pve-mcp/gitea/grafana/…) | pve + macmini | 1 abdrehbar |
+  | macmini-Dienste (`.20.167`) | pve + NAS | 1 abdrehbar |
+
+  3 Tunnel, jeder Host fährt 2 cloudflared → Host-Ausfall ⇒ jeder Tunnel ≥1 Connector = **voll HA**. Voraussetzung: jede Origin L2-erreichbar.
+- **Ist-Inventory (live 2026-07-10, s. `cf-tunnel-mapping.md §9`):** Ingress v119, 24 Hostnames, 2 live Connectoren. **DOWN/stale:** `pbs .20.135`, `nginx-bf .41.123` (noch VLAN1!), `hermes`+`hermes-geli .20.167`. **Zu klären (Host/Netz):** `vw .20.127`/`ccu .20.232`/`iobroker .20.107`/`z2m25 .20.106` — ggf. `vw`/`ccu` auf VLAN20-macvlan heben. `gateway-dw` (192.168.178.1) = WG-Sonderfall.
+- **CF-Access-Strang (verzahnt, s. TP11 Track-B):** `hass`-**400 in der HA-iPhone-App = CF-Access davor** (Companion-App kann Access-Login nicht) → Fix **ohne Passthrough**: iPhone in **WARP** enrollen (Device-Identity erfüllt Access; „Warp Login App" existiert bereits `allow:christoph`). ⚠️ **`vw` = aktuell `bypass` (öffentlich!)** → von bypass auf geschützt heben. „Passthrough-Hosts sind die kritischen" (User).
+- **Umsetzungs-Reihenfolge (für die eigene Session):** (1) **Reachability-Matrix je Host** (pve/NAS/macmini → jede Origin, read-only) BEVOR gruppiert wird; (2) **Interim-Sofortfix:** bf-Tunnel auf **pve-only** (pve erreicht alles außer gateway-dw) → 0×1033, reversibel; (3) reziprokes 3-Tunnel-HA bauen (CNAMEs re-pointen, 6 Connectoren, Token je Tunnel; NAS/macmini-Alt-Token entfernen); (4) tote Origins bereinigen; (5) Access-Strang (WARP + vw); (6) Loop-Gegentest.
+- Abh.: TP14.1/14.2 ✅. Verwandt: **TP11** (CF-Tunnel-Track-B/C + Access), #1033. SSoT: `docs/cf-tunnel-mapping.md`. Memory `project_cf_tunnel_1033`.
 
 ### TP-R — Router-Capabilities-Sweep ▸ FERTIG (`docs/research/routeros-capabilities.md`)
 - **Leitsatz: nativ vor Container, NAS vor Router** (128MB-Flash-Limit).
@@ -349,7 +360,7 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 ---
 
 ## Reihenfolge / Abhängigkeiten
-> 🔴 **QUER & HOCHDRINGLICH: TP16 (CF-Tunnel-Erreichbarkeit / FQDN „sehr unsicher")** — vom User als eigenes, vorrangiges Paket eingekippt (2026-07-10). Läuft neben der VLAN20-Migration; Origins sind jetzt VLAN20-seitig, also anwendbar. Details oben bei TP16.
+> 🔴 **QUER & HOCHDRINGLICH: TP16 (CF-Tunnel Round-Robin/macvlan-Host-Isolation → reziprokes HA + Access/hass)** — eigenes Paket (2026-07-10), **Analyse turnkey dokumentiert, Umsetzung = eigene Session**. Root-Cause + Ziel-Design + Ist-Inventory bei TP16 / `docs/cf-tunnel-mapping.md §9`.
 1. ~~**TP1 (GE8) → TP2 (Omada Controller).**~~ ✅ erledigt 2026-06-15.
 2. ~~**TP4 (Router-Cutover L3-Infra + WAN-Edge).**~~ ✅ erledigt 2026-06-15 (L3) + 2026-07-01 (Edge-Cutover, FB physisch weg).
 3. **Jetzt: Omada-PVID-Fix** — Omada Access-Profile korrigieren (PVID 10/20, untagNetworkIds bereinigen, sicher P3/P5/P6 zuerst), dann IP-Migration NAS/macmini/pve auf VLAN-Subnetze + DNS-Einträge updaten. **IP-Migration NAS/pve = TP14** (NAS ✅ 2026-07-10, pve 🔜 Session B).