From 7388cc8388969f58150631f803f2f57e2c2bc000 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Mon, 17 Aug 2026 11:58:51 +0200 Subject: [PATCH] TP16.1 4.0 DURCH: Mesh-Node bf-core-mesh angelegt, Free-Plan-Gate offen POST /warp_connector erfolgreich -> d1da7c8a-... Der LXC-Fallback ist vom Tisch. Blocker war der Token, nicht der Plan: alter User-Token hatte 2 fehlende Permissions, ersetzt durch account-owned Token (gueltig bis 2027-01-09). Zwei Fallen dokumentiert: account-owned Tokens verifizieren an /accounts/{id}/tokens/verify (am /user-Pfad melden sie faelschlich 'Invalid API Token'), und Zone-Permissions brauchen eine eigene Policy-Zeile ('Account tag in access policy must match tag in request uri'). Verifiziertes Permission-Set inkl. IDs in 4.0. Am Geraet weiterhin nichts angefasst. Co-Authored-By: Claude Opus 5 --- docs/teilprojekte.md | 8 ++--- docs/tp16.1-warp-mesh-native-crs326.md | 46 ++++++++++++++++++++++---- 2 files changed, 43 insertions(+), 11 deletions(-) diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 910deee..c8cf178 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -478,10 +478,10 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". - 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`. - ✅ **Incident 2026-07-16 (User unterwegs, WARP „spinnt", keine BF-IPs mehr) ▸ Public-FQDN-Teil gefixt:** macmini-Connectoren (`cloudflared-bfnas`/`-bfpve`) flappten live unter QUIC/UDP (Docker-Desktop-Bridge-NAT) → `bf-nas`/`bf-pve` von 2 auf 1 Connector degradiert (HA faktisch weg, nicht down). Fix: beide auf `TUNNEL_TRANSPORT_PROTOCOL=http2` umgestellt (rollend, 0 Downtime), wieder voll HA. Konvention: macmini-Connectoren künftig immer `http2`. **ICMP-Befund (getrennt, strukturell):** TCP über die WARP-Route ging überall, ICMP nicht (fm 36 %/bf 100 %/dw 100 % Loss) — cloudflared ist QUIC-Proxy, kein WireGuard. **Kurz als „bf-pve-Route wegen USV" notiert (Commit `1c1a676`) → REVIDIERT** (Begründung invertiert: bf-pve-Connectoren laufen auf NAS+macmini, nicht pve). Details: `docs/cf-tunnel-mapping.md §13`. **→ Richtungswechsel für Private Access = TP16.1.** -### TP16.1 — Private Access via native Cloudflare Mesh (WireGuard) auf `crs326-core` ▸ 🔴 **BLOCKIERT auf §4.0 (Token-Scope), user-gated (2026-08-16)** — `docs/tp16.1-warp-mesh-native-crs326.md` -- 🔴 **Scharfschalt-Versuch 2026-08-16 — Plan-Probe ausgeführt, reproduzierbar gescheitert.** `POST /warp_connector` → `10000`/HTTP 403, identisch zum 2026-07-17. **Am Gerät wurde nichts angefasst** (kein `/system backup`, kein `cf-mesh`-Interface, keine Route) — der Blocker sitzt vor dem ersten Geräte-Eingriff, Ausnahme #4 wurde also gar nicht erst gezogen. -- 🆕 **Die Probe hat den Blocker vollständig vermessen — es fehlen ZWEI Permissions, nicht eine.** Bisher stand nur §4.0 im Runbook; die Gegenproben zeigen, dass `devices/settings` für den Token schon **lesend** `403` ist → **auch §4.1 (Unique Device IP, Device-Profil, Split-Tunnel) wäre gescheitert**. Ohne diesen Fund hätte die Session den Token zweimal nachziehen müssen. **In EINEM Dashboard-Edit ergänzen:** „Cloudflare One Connector: WARP" → Edit · „Zero Trust" → Edit · „Cloudflare One Networks" → Edit. Klickpfad + Beleg-Tabelle in `docs/tp16.1-…md` §4.0. -- 🧭 **Free-Plan-Frage weiterhin OFFEN, nicht beantwortet.** Dass der `cloudflare`-MCP (OAuth, read-only) dieselben Endpoints sauber liest, beweist nur: der **Account** kann es, der **Token** darf nicht. Ob der Free-ZT-Plan das `POST` erlaubt, zeigt erst der Retry — ein dann *immer noch* scheiternder POST wäre das echte Plan-Gate und löst den LXC-Fallback aus. +### TP16.1 — Private Access via native Cloudflare Mesh (WireGuard) auf `crs326-core` ▸ 🟡 **§4.0 DURCH, läuft — §4.1 user-gated (2026-08-17)** — `docs/tp16.1-warp-mesh-native-crs326.md` +- ✅ **§4.0 erledigt 2026-08-17: Mesh-Node angelegt.** `bf-core-mesh` = **`d1da7c8a-2736-4cbb-8af1-32db5393fb9c`**, Register-Token in `mcp/cloudflare/.env` (`CF_MESH_REGISTER_TOKEN`, gitignored). ➡️ **Die seit 2026-07-17 offene Free-Plan-Frage ist beantwortet: der Free-ZT-Plan erlaubt Cloudflare Mesh — der LXC-Fallback ist vom Tisch.** +- 🔑 **Der Weg dahin war ein Token-Problem, kein Plan-Problem (kostete 2 Anläufe).** Der alte User-Token hatte **zwei** fehlende Permissions (§4.0 *und* §4.1 — `devices/settings` war schon lesend `403`). Ersetzt durch einen **account-owned** Token (`9984078812bc…`, ⏰ **gültig bis 2027-01-09**). Zwei Fallen, beide sehen aus wie „Token kaputt": (1) Account-Tokens verifizieren an `/accounts/{id}/tokens/verify` — am alten `/user/tokens/verify` melden sie `1000 "Invalid API Token"`, **während alle echten Endpoints 200 liefern**; (2) Dashboard-Fehler `"Account tag in access policy must match tag in request uri"` = eine **Zone**-Permission (`DNS`) steckt in der Policy-Zeile mit **Account**-Ressourcen → braucht eine eigene Zeile. Verifiziertes Soll-Set + Permission-IDs in `docs/tp16.1-…md` §4.0. **Merke: Dashboard sagt „Edit", API sagt „Write".** +- ⏭️ **Als Nächstes §4.1** (Unique Device IP, Device-Profil „Cloudflare Mesh", Split-Tunnel `100.64.0.0/10` → `100.64.0.0/11` + `100.112.0.0/12`). Account-weit → **1× kurzer WARP-Reconnect auf allen eingebuchten Geräten**, daher user-gated. **Am `crs326-core` ist bis hierher nichts angefasst** — Ausnahme #4 noch nicht gezogen. - ✅ **Gate erfüllt (2026-08-16):** die Bedingung „gated bis TP21 den CRS326 abdeckt" ist eingelöst — `crs326-core` ist seit 2026-08-08 der produktive L3-Router und seit 2026-08-13 in Nautobot adoptiert (68/68 compliant). Runbook §3 neu gemessen, §4.3 von Platzhalter auf **echte Werte** gezogen. - 🧭 **Erwartung geraderücken (wichtig, weil leicht zu verwechseln): das Mesh ersetzt die CF-Tunnel NICHT.** TP16.1 löst ausschließlich den **privaten** Zugang (unterwegs → `10.40.0.0/16` per IP, **inklusive ICMP**) und tauscht dort den cloudflared-QUIC-Proxy gegen natives WireGuard auf dem Core. Die **öffentlichen FQDNs bleiben** auf dem 3-Tunnel-HA aus TP16. Beide Stränge laufen nebeneinander — die HA-Degradierung aus TP16 (2026-08-16) wird davon **nicht** geheilt und bleibt ein eigener offener Punkt. - 📌 **Live-Befunde 2026-08-16 (read-only erhoben, kein Eingriff):** diff --git a/docs/tp16.1-warp-mesh-native-crs326.md b/docs/tp16.1-warp-mesh-native-crs326.md index 677eaaa..96557cf 100644 --- a/docs/tp16.1-warp-mesh-native-crs326.md +++ b/docs/tp16.1-warp-mesh-native-crs326.md @@ -1,13 +1,14 @@ # TP16.1 — Private Access via native Cloudflare Mesh (WARP Connector) auf dem CRS326 Core-Switch -> **🔴 Status 2026-08-16 (Scharfschalt-Versuch): BLOCKIERT auf §4.0 — Token-Scope, user-gated.** Die Plan-Probe -> wurde ausgeführt und scheiterte reproduzierbar (`10000`/403). Die Probe hat den Blocker aber **vollständig -> vermessen**: es fehlen **zwei** Permissions, nicht eine (§4.0 *und* §4.1) — Details + Klickpfad in §4.0. -> Alles ab §4.1 hängt daran; **am Gerät wurde nichts angefasst** (kein Backup, kein WG-Interface, keine Route). -> Nach dem Token-Edit ist die Session ohne weiteren Vorlauf fortsetzbar. **Ob der Free-ZT-Plan Mesh überhaupt -> erlaubt, ist weiterhin offen** — das entscheidet erst der Retry des POST. +> **✅ Status 2026-08-17: §4.0 DURCH — Plan-Gate offen, Mesh-Node existiert.** `POST /warp_connector` erfolgreich: +> **`bf-core-mesh` = `d1da7c8a-2736-4cbb-8af1-32db5393fb9c`**, Register-Token in `mcp/cloudflare/.env` +> (`CF_MESH_REGISTER_TOKEN`, gitignored, `chmod 600`). ➡️ **Die seit 2026-07-17 offene Free-Plan-Frage ist damit +> beantwortet: der Free-ZT-Plan erlaubt Cloudflare Mesh. Der LXC-Fallback (§6) ist vom Tisch.** +> **Am Gerät ist weiterhin nichts angefasst** (kein Backup, kein `cf-mesh`, keine Route) — nächster Schritt ist +> §4.1, und der ist wegen des account-weiten WARP-Reconnects **user-gated**. > -> *Vorheriger Stand — inhaltlich unverändert gültig:* **🟢 GATE OFFEN, ausführungsreif.** `crs326-core` ist seit 2026-08-08 der produktive L3-Router und seit 2026-08-13 in Nautobot adoptiert (68/68 compliant) — die Bedingung „gated bis TP21 den CRS326 abdeckt" ist **erfüllt**. §3 am 2026-08-16 neu gemessen, §4.3 von Platzhalter auf **ausführungsreif** gezogen, **Governance-Ausnahme #4 erteilt** (WG-Zeilen direkt, weil ein Privkey über Golden Config strukturell nicht deploybar ist). Scharfschalten bleibt eine **eigene Session** — es fasst account-weite WARP-Einstellungen an. +> *Historie dieses Anlaufs: 2026-08-16 blockiert auf Token-Scope (zwei fehlende Permissions, s. §4.0) → +> 2026-08-17 Token neu aufgesetzt, jetzt account-owned.* `crs326-core` ist seit 2026-08-08 der produktive L3-Router und seit 2026-08-13 in Nautobot adoptiert (68/68 compliant) — die Bedingung „gated bis TP21 den CRS326 abdeckt" ist **erfüllt**. §3 am 2026-08-16 neu gemessen, §4.3 von Platzhalter auf **ausführungsreif** gezogen, **Governance-Ausnahme #4 erteilt** (WG-Zeilen direkt, weil ein Privkey über Golden Config strukturell nicht deploybar ist). Scharfschalten bleibt eine **eigene Session** — es fasst account-weite WARP-Einstellungen an. > *Historie: Konzept + Runbook 2026-07-16 · Recherche verifiziert + gehärtet 2026-07-17 · Ziel-Device von ap1 auf CRS326 retargeted 2026-07-22.* > ⚠️ **Retarget-Hinweis (2026-07-22, Stand 2026-08-16 aufgelöst):** Alles unten war ursprünglich für **ap1** geschrieben und wurde auf den **CRS326 Core-Switch** ummünzt. ~~Der CRS326 ist aktuell noch Werkszustand — Management-IP/Interface-Zuordnung TBD, §4.3 ist ein Platzhalter.~~ → **überholt:** `crs326-core` ist produktiver L3-Router mit Mgmt `10.40.99.1`, §4.3 trägt jetzt echte Werte. Grund für den Retarget: TP15-Endstand (kein RB5009, Router bleibt ap1/ap2 rein für L3/WLAN) + TP21s Modell "ganzer Kabel-Fabric via RouterOS" — der CRS326 wird ohnehin Nautobot-verwaltet, ap1 bleibt Public-Edge/WLAN-Anker. > Selbst-tragend: eine frische Session kann das mit diesem Doc + `docs/cf-tunnel-mapping.md` straight bauen — vorausgesetzt der CRS326-Bring-up (TP15) und die Nautobot-Adoption (TP21) stehen. @@ -140,6 +141,36 @@ also — nur der Token darf nicht. ➡️ **Die Free-Plan-Frage aus §4.0 bleibt beantwortet sich erst beim Retry des `POST` mit korrekt gescoptem Token. Erst ein dann *immer noch* fehlschlagender POST wäre das Plan-Gate und würde den LXC-Fallback (§6) auslösen. +**✅ AUFGELÖST 2026-08-17 — Token neu aufgesetzt, alle Proben 200.** Der Weg dahin hatte zwei Stolpersteine, die +man kennen muss, weil beide *aussehen* wie „Token kaputt", es aber nicht sind: + +1. **Der neue Token ist ACCOUNT-OWNED** (id `9984078812bc18d4ebb6a64b570144f2`, gültig bis **2027-01-09** ⏰). + Account-Tokens verifizieren an einem **anderen** Endpoint: `GET /accounts/{account_id}/tokens/verify`. + ⚠️ Am alten `GET /user/tokens/verify` antwortet ein gültiger Account-Token mit **`1000 "Invalid API Token"`/401** — + zeitgleich liefern *alle* echten Endpoints 200. **Nicht als abgelaufen fehldeuten.** +2. **Dashboard-Fehler `"Account tag in access policy must match tag in request uri"`** (real erlebt, mehrfach): + tritt auf, wenn eine **Zone**-Permission (hier `DNS`) in dieselbe Policy-Zeile gepackt wird, die **Account**- + Ressourcen trägt. Zone-Permissions brauchen eine **eigene Policy-Zeile** mit Zone-Ressourcen. Halb richtig + gesetzt = Permission sichtbar, aber jede Zone `403`, weil keine Zone eingeschlossen ist. + +**Verifiziertes Soll-Set (alle am 2026-08-17 mit 200 gegengeprüft) — Dashboard sagt „Edit", die API sagt „Write":** + +| Dashboard | API-Name | Permission-ID | braucht | +|---|---|---|---| +| Cloudflare One Connector: WARP → Edit | `Cloudflare One Connector: WARP Write` | `5b5c774a5d174ca88d046c8889648b3f` | §4.0 | +| Zero Trust → Edit | `Zero Trust Write` | `b33f02c6f7284e05a6f20741c0bb0567` | §4.1 | +| Cloudflare One Networks → Edit | `Cloudflare One Networks Write` | `e2980d9241cf4939bbbd74fdc43b9651` | §4.4 | +| Cloudflare Tunnel → Edit | `Cloudflare Tunnel Write` | `c07321b023e944ff818fec44d8203567` | TP16 | +| Access: Apps and Policies → Edit | `Access: Apps and Policies Write` | — | Bestand | +| Access: Organizations, IdP, and Groups → Edit | `… Write` | — | Bestand | +| **Zone** DNS → Edit (`emsenhuber.net`) | `DNS Write` | — | Tunnel-CNAMEs | + +⚠️ **Namensfalle:** `Cloudflare One Connectors Write` (Plural, Sammelgruppe) ist **nicht** die Mesh-Permission. +Ebenso heißt „Cloudflare Tunnel" in neueren Listen zusätzlich „Cloudflare One Connector: cloudflared" — beide +Gruppen existieren parallel. Vollständige Liste (396 Gruppen) via MCP: `GET /user/tokens/permission_groups`. + +
Historischer Klickpfad (2026-08-16, vor der Auflösung) + **➡️ Was zu tun ist (Dashboard, nur der User — Token-Bearbeitung ist keine Agent-Aktion):** `dash.cloudflare.com` → My Profile → API Tokens → Token `455e4f8e…` → Edit → **Account**-Permissions ergänzen: 1. **„Cloudflare One Connector: WARP" → Edit** (§4.0: `POST /warp_connector` + `/token`) @@ -147,6 +178,7 @@ POST wäre das Plan-Gate und würde den LXC-Fallback (§6) auslösen. 3. **„Cloudflare One Networks" → Edit** (§4.4 Routes/vnets — GET geht heute, Edit war 2026-07-17 ok; sicherheitshalber mitnehmen) Danach neuen Wert nach `mcp/cloudflare/.env` **und** `~/.secrets/credentials.env` (beide tragen `CF_API_TOKEN`). +
**⚠️ Token-Permission-Gotcha (2026-07-17, real erlebt — Ursachenanalyse, weiterhin gültig):** `POST /warp_connector` schlug mit `code 10000 "Authentication error"` (HTTP 403) fehl, obwohl der `CF_API_TOKEN` gültig ist und `teamnet/routes` PATCHen kann.