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/teilprojekte.md

@@ -330,8 +330,8 @@ 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: 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.**
+### TP16 — CF-Tunnel: Round-Robin killen + reziprokes HA ▸ ✅ KERN UMGESETZT (2026-07-10) — `docs/cf-tunnel-mapping.md §10`, #1033
+> **✅ Umgesetzt (2026-07-10, eigene Session):** reziprokes **3-Tunnel-HA** live (bf-nas `70d6a4cf` / bf-pve `f7fdf3a6` / bf-mm `7a322261`), 6 Connectoren (2/Host, je Fremdhost), 19 FQDNs Loop-Smoke **0×530**, HA per Host-Ausfall-Sim bewiesen. Round-Robin-#1033 **strukturell weg**. As-Built = `docs/cf-tunnel-mapping.md §10`. **Offen: Schritt 5 Access-Strang (`vw` bypass→geschützt via WARP, `hass`/`ha-mcp` 400/403 → iPhone-WARP-Enrollment) = user-gated; `gateway-dw` (WG→404) klären.**
 - **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**.
@@ -360,7 +360,7 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 ---
 
 ## Reihenfolge / Abhängigkeiten
-> 🔴 **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`.
+> ✅ **TP16 (CF-Tunnel Round-Robin/macvlan-Host-Isolation → reziprokes 3-Tunnel-HA)** KERN UMGESETZT 2026-07-10 (#1033 strukturell weg). Offen nur Access-Strang (WARP/`vw`) = user-gated. As-Built `docs/cf-tunnel-mapping.md §10`.
 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).