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/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
-> **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.
-- **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).
-- **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 (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.
-- **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").
-- 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`.
+### 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 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 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.
+- **✅ 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.
+- **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**.
+- **Ziel-Design (HA): reziproke Per-Host-Tunnel** — jeder Host-Dienst wird von den Connectoren der ANDEREN Hosts bedient (nie vom eigenen):
+
+  | 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).