diff --git a/docs/cf-tunnel-mapping.md b/docs/cf-tunnel-mapping.md index 9bb98be..c7dc726 100644 --- a/docs/cf-tunnel-mapping.md +++ b/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//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=` + `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. diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index d4d10f9..325e025 100644 --- a/docs/teilprojekte.md +++ b/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).