From 97e2d9c354268fded3fc554b907298442267c5db Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Fri, 17 Jul 2026 06:07:13 +0200 Subject: [PATCH] =?UTF-8?q?docs=20=F0=9F=94=8E=20TP16.1:=20Recherche=20ver?= =?UTF-8?q?ifiziert=20+=20Runbook=20geh=C3=A4rtet=20(Mesh-Rebranding,=20IC?= =?UTF-8?q?MP-Proxy-Prereq,=20vnet-Gotcha,=20v4-only)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Primärquellen (animmouse Mesh-on-MikroTik + wgcf-connector) und offizielle CF-Docs/OpenAPI-Spec gegengelesen — Lead bestätigt, 6 Härtungen eingearbeitet: - Produkt seit 2026-04-14 offiziell 'Cloudflare Mesh' (API bleibt /warp_connector, im Spec bestätigt inkl. Token- und HA-Endpoints; Node-Limit 50/Account) - NEU: ICMP-Proxy-Prerequisite — Dashboard-only (nicht im API-Spec), 1 Klick Traffic settings→Proxy→ICMP, sonst bleibt das Abnahmekriterium Ping tot - Split-Tunnel-Exclude auf BEIDEN Device-Profilen (Default + Mesh) - vnet-Gotcha beim Route-Umzug ('virtual networks only for cloudflared') → Weg A PATCH / Weg B DELETE+POST; CF-API-Writes sind WARP-unabhängig (Rollback safe) - v4-only-Entscheid (Mesh-IPv6-site-to-site laut Guide broken, kein NAT66) - keepalive 1m ok, .conf-Inhalte präzisiert (IPv6+DNS ignorieren) Runbook ausführungsreif für die Delegations-Session. Co-Authored-By: Claude Opus 4.8 --- docs/teilprojekte.md | 3 +- docs/tp16.1-warp-mesh-native-ap1.md | 52 ++++++++++++++++++++++++----- 2 files changed, 46 insertions(+), 9 deletions(-) diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 85cad5f..8dec14f 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -370,12 +370,13 @@ 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 ap1 ▸ 📋 Konzept+Runbook fertig (2026-07-16), Scharfschalten = eigene Session — `docs/tp16.1-warp-mesh-native-ap1.md` +### TP16.1 — Private Access via native Cloudflare Mesh (WireGuard) auf ap1 ▸ 📋 Konzept+Runbook fertig (2026-07-16), **Recherche verifiziert + Runbook gehärtet (2026-07-17)**, Scharfschalten = eigene Session — `docs/tp16.1-warp-mesh-native-ap1.md` - **Trennung:** Public FQDNs bleiben auf cloudflared-3-Tunnel-HA (TP16); **Private Access** (unterwegs → `10.40.0.0/16` per IP inkl. ICMP) wandert vom cloudflared-QUIC-Proxy auf einen **nativen WireGuard-Mesh-Node auf ap1**. - **Warum ap1-nativ:** Cloudflare Mesh spricht WireGuard, RouterOS kann natives WireGuard (TP10-Hub *ist* einer) → Mesh-Node = WG-Peer zu CF-PoP, **kein Container/TUN/LXC/neue HW**. Erfüllt „ap1 = einziger SPOF", keine macvlan-Blindheit, ICMP nativ. RouterOS-Container-Weg tot (kein `/dev/net/tun`-Passthrough auf JEDER Router-HW) → **hAP ax³ löst das nicht** (zudem Wi-Fi 6, nicht 7) → HW-Kauf vom Tunnel-Fix entkoppelt (ggf. TP15). - **Verworfen:** WG-Roadwarrior (User will keine Extra-App/Profil je Gerät), alle Helper-Host-ZT-Anbieter (SPOF-Verletzung). - **Warum heute nur Konzept:** TCP-Pfad funktioniert (nur ICMP-Komfort fehlt), und die CF-Prerequisites sind **account-weit** (Unique-Device-IP, Split-Tunnel-Exclude, Device-Profile) → treffen Live-WARP-Geräte (1× kurzer Reconnect) → nicht unter Zeitdruck. - **Nächste Session:** Plan-Probe `POST warp_connector` (Free-Plan-Gate; sonst LXC-Fallback) → account-weite Prereqs → `wgcf-connector`-Token→WG-Config → 4 WG-Zeilen auf ap1 → Subnetz-Route + vnet-Route `5546dcb6…` von bf-pve umhängen (Rollback trivial) → Verifikation (Ping verlustfrei). Team-Domain `emsenhuber.cloudflareaccess.com`. ⚠️ Governance „Config nur via Nautobot" → ap1-Zeilen via GC oder genehmigte Ausnahme. +- ✅ **Recherche-Härtung 2026-07-17 (Primärquellen animmouse + offizielle CF-Docs + OpenAPI-Spec, alles verifiziert):** (1) Produkt heißt seit 2026-04-14 offiziell **Cloudflare Mesh** (API-Pfade bleiben `warp_connector`, im Spec bestätigt inkl. Token- und sogar HA-Endpoints); (2) **Neu: ICMP-Proxy-Prerequisite** — TCP/UDP-Proxy an, ICMP fehlt und ist **Dashboard-only** (nicht im API-Spec) → 1 Klick Traffic settings→Proxy→ICMP, ohne den bleibt das Abnahmekriterium Ping tot; (3) Split-Tunnel-Exclude auf **beiden** Device-Profilen (Default + Mesh); (4) **vnet-Gotcha** beim Route-Umzug („virtual networks only for cloudflared") → Weg A PATCH, Weg B DELETE+POST dokumentiert; (5) **v4-only-Entscheid** (Mesh-IPv6-site-to-site laut Guide broken, NAT66-Gefrickel nicht nötig); (6) keepalive 1m statt 25s ok. Alles in `docs/tp16.1-warp-mesh-native-ap1.md` §2/§4 eingearbeitet — **Runbook ist jetzt ausführungsreif für die Delegations-Session.** - Abh.: TP16 ✅ (Public-Teil), TP10 ✅ (WG-Grundmuster auf ap1). SSoT: `docs/tp16.1-warp-mesh-native-ap1.md`, `docs/cf-tunnel-mapping.md §14`. ### TP17 — Shelly-Übersiedelung VLAN1 → VLAN30 (IOT) + `shelly-mcp` ▸ ✅ WLAN+IP DURCH (22/26, 2026-07-13); Geräte-PW + cudy-Teardown offen — `mcp/shelly/`, Runbook `docs/tp17-shelly-go-runbook.md` diff --git a/docs/tp16.1-warp-mesh-native-ap1.md b/docs/tp16.1-warp-mesh-native-ap1.md index 29587be..6f781b2 100644 --- a/docs/tp16.1-warp-mesh-native-ap1.md +++ b/docs/tp16.1-warp-mesh-native-ap1.md @@ -1,8 +1,10 @@ # TP16.1 — Private Access via native Cloudflare Mesh (WARP Connector) auf ap1 -> **Status: Konzept + Runbook fertig (2026-07-16), Scharfschalten = eigene Session.** +> **Status: Konzept + Runbook fertig (2026-07-16), Recherche verifiziert + Runbook gehärtet (2026-07-17), Scharfschalten = eigene Session.** > Selbst-tragend: eine frische Session kann das mit diesem Doc + `docs/cf-tunnel-mapping.md` straight bauen. > SSoT-Kontext: `docs/cf-tunnel-mapping.md` §13/§14, Memory `project_cf_tunnel_1033`. +> Härtungs-Delta 2026-07-17: ICMP-Proxy-Prerequisite (§4.1.5, Dashboard-only!), Split-Tunnel auf BEIDEN Profilen (§4.1.4), +> vnet-Gotcha + Weg B beim Route-Umzug (§4.4), v4-only-Entscheid (IPv6-site-to-site laut Guide broken), Quellen verifiziert (§2). ## 1. Warum überhaupt / Root Cause @@ -33,9 +35,28 @@ zuverlässig eingerichtet. **Der WARP-Client selbst spricht WireGuard** — die CF-PoP registriert — **kein Container, kein TUN, kein LXC, keine neue HW.** Erfüllt „ap1 = einziger SPOF" am besten, keine macvlan-Blindheit (ap1 routet alle VLANs nativ L3), ICMP/TCP/UDP nativ. -Quelle/Vorlage: animmouse „Setup Cloudflare WARP Connector on MikroTik" + „Setup Cloudflare Mesh using WireGuard". +Quelle/Vorlage: animmouse „Setup Cloudflare Mesh on MikroTik" + „Setup Cloudflare Mesh using WireGuard". Ehrliche Einschränkung: **von uns noch nicht gebaut** — starker, technisch schlüssiger Lead; echter Beweis = bauen+pingen. +**✅ Recherche verifiziert (2026-07-17, Primärquellen gelesen + offizielle CF-Docs + OpenAPI-Spec):** +- **Produkt-Status:** „WARP Connector" heißt seit **2026-04-14 offiziell „Cloudflare Mesh"** (Rebranding, kein Migrationszwang); + Node-Limit **50/Account**; neues Dashboard unter **Networking → Mesh** (interaktive Map, Route-Config, Setup-Wizard). + Die API-Pfade heißen weiterhin `/accounts/{id}/warp_connector` — im OpenAPI-Spec bestätigt: POST (create), + GET `…/{tunnel_id}/token` (Register-Token), dazu sogar **HA-Endpoints** (`…/configurations` active-passive-Replicas, + `…/failover`) — für uns nicht nötig (ap1 = bewusster SPOF), aber gut zu wissen. +- **CIDR-Routes für Mesh-Nodes** laufen über dieselbe `teamnet/routes`-API wie cloudflared (`POST {network, tunnel_id: }`, + Token-Scope `Cloudflare One Networks Write` oder `Cloudflare Tunnel Write`) — unser `CF_API_TOKEN`-Pfad passt. +- **animmouse-MikroTik-Rezept bestätigt** (alle Kommandos gegengelesen, s. §4.3): CF-Wellknown-PublicKey, Endpoint-Substitution + `162.159.192.x → 162.159.193.x` (Latenz), MTU 1420, `100.96.0.0/12 → cf-mesh`-Route. Guide nutzt `persistent-keepalive=1m` + (unser Entwurf sagte 25s — beides ok, 25s konservativer hinter NAT; wir sind Public-Edge → 1m reicht). +- **IPv6-Befund (animmouse):** Mesh-site-to-site-IPv6 war beim Guide-Test **broken** (NAT66-Workaround nötig) → **wir bauen bewusst v4-only** + (kein v6 auf `cf-mesh`, kein NAT66 — BF nutzt intern eh kein v6, s. Memory `project_ipv6_state`). +- **Sources:** [Setup Cloudflare Mesh on MikroTik](https://www.animmouse.com/p/setup-cloudflare-mesh-on-mikrotik/) · + [Setup Cloudflare Mesh using WireGuard](https://www.animmouse.com/p/setup-cloudflare-warp-connector-using-wireguard/) · + [wgcf-connector (GitHub)](https://github.com/AnimMouse/wgcf-connector) · + [CF-Changelog „Introducing Cloudflare Mesh"](https://developers.cloudflare.com/changelog/post/2026-04-14-cloudflare-mesh/) · + [CF-Docs Mesh Routes](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-mesh/routes/) + ## 3. Ist-Stand Account (gemessen 2026-07-16, read-only) - Team-Domain: **`emsenhuber.cloudflareaccess.com`** → Mesh-Node-Identität = `warp_connector@emsenhuber.cloudflareaccess.com` @@ -66,13 +87,21 @@ Token danach: `GET /accounts/…/warp_connector/{tunnel_id}/token` → das ist d 4. **Split-Tunnel-Exclude anpassen** (`PUT /accounts/…/devices/policy/exclude` — ⚠️ ersetzt die GANZE Liste, erst GET, dann editiert zurückschreiben): `100.64.0.0/10` **raus**, dafür `100.64.0.0/11` + `100.112.0.0/12` **rein** (= 100.64/10 minus 100.96/12 → Mesh-Overlay `100.96.0.0/12` läuft nun durch WARP statt als „local" behandelt zu werden). + ⚠️ **Auf BEIDEN Profilen** (Default **und** dem neuen „Cloudflare Mesh"-Profil aus Schritt 3 — per-Profile-Endpoint + `…/devices/policy/{policy_id}/exclude`); animmouse macht das explizit auf beiden. +5. **ICMP-Proxy einschalten** (Neu-Fund aus den offiziellen Mesh-Docs — Prerequisite „Gateway proxy with TCP, UDP, ICMP"): + TCP+UDP sind bei uns schon an (`gateway_proxy_enabled`/`gateway_udp_proxy_enabled` = true), **ICMP fehlt**. + ⚠️ Das ICMP-Flag ist **nicht im public OpenAPI-Spec** (weder `devices/settings` noch `gateway/configuration` haben es, + 2026-07-17 geprüft) → **Dashboard-Klick nötig:** Traffic policies → Traffic settings → „Proxy" → **ICMP** anhaken. + Ohne das bleibt Ping durchs Gateway tot — und Ping ist genau unser Abnahmekriterium (§4.5). ### 4.2 WireGuard-Config extrahieren (einmalig, ephemer) Auf macmini oder pve (Docker vorhanden): ``` docker run --rm -v $(pwd):/app/output ghcr.io/animmouse/wgcf-connector ``` -→ erzeugt `wgcf-connector-.conf` mit: **PrivateKey**, **Address** (`100.96.x.y/32`), Peer-**PublicKey** +→ erzeugt `wgcf-connector-.conf` mit: **PrivateKey**, **Address** (`100.96.x.y/32` **+ eine IPv6** — +ignorieren, wir bauen v4-only), **DNS** (CF-Resolver — ignorieren, ap1 hat eigenes DNS), **MTU 1420**, Peer-**PublicKey** (= CF-Wellknown `bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=`), **Endpoint** (`162.159.193.x:2408`). Registriert den Node via CF-API (macht Netz-Call), läuft danach nie wieder. **PrivateKey nach `mcp/cloudflare/.env` o. `~/.secrets`** (nicht committen). @@ -96,11 +125,18 @@ o. `~/.secrets`** (nicht committen). oder als vom User genehmigte Ausnahme dokumentieren (Nachtrag in GC als Follow-up). ### 4.4 Subnetz-Route + vnet-Route umziehen -- Im Mesh-Node **`10.40.0.0/16` als CIDR-Route** announcen (Dashboard Networks → Routes: Node = neuer Mesh-Tunnel, - oder API). -- vnet-Route `5546dcb6…` von `bf-pve` auf den **neuen `warp_connector`-Tunnel** umhängen: - `PATCH /accounts/…/teamnet/routes/5546dcb6… {tunnel_id: }`. -- **Rollback jederzeit:** PATCH zurück auf `f7fdf3a6…` (bf-pve) — cloudflared/bf-pve bleibt die ganze Zeit bestehen. +- Ziel: die CIDR-Route `10.40.0.0/16` zeigt auf den **neuen Mesh-Node** statt auf `bf-pve`. +- **Weg A (zuerst versuchen):** `PATCH /accounts/…/teamnet/routes/5546dcb6… {tunnel_id: }` — + gleiche `teamnet/routes`-API wie cloudflared, per CF-Docs auch für Mesh-Nodes gültig. +- ⚠️ **Neu-Fund vnet-Gotcha:** CF-Docs sagen „**Virtual networks are only supported for cloudflared tunnels**" — + unsere Route hängt am vnet `1480b545…` (`vnetemsenhuber`, ist aber das **default**-vnet des Accounts). Möglich, + dass der PATCH auf einen `warp_connector`-Tunnel deshalb mit 4xx abgelehnt wird. + **Weg B (Fallback):** `DELETE` der alten Route `5546dcb6…` + `POST /teamnet/routes {network:"10.40.0.0/16", + tunnel_id:}` **ohne** vnet-Angabe (landet im default). Kurze Lücke (Sekunden) dazwischen ist ok — + Reihenfolge DELETE→POST zwingend (CIDR-Kollision verhindert POST-vor-DELETE). +- **Rollback jederzeit:** PATCH (bzw. DELETE+POST) zurück auf `f7fdf3a6…` (bf-pve) — cloudflared/bf-pve bleibt die + ganze Zeit bestehen. **Wichtig fürs Remote-Arbeiten:** alle CF-API-Writes laufen über die öffentliche API + (api.cloudflare.com), NICHT über WARP → Rollback funktioniert auch, wenn der private Pfad gerade tot ist. ### 4.5 Verifikation (Abnahme) - MacBook, WARP **connected**: `ping 10.40.20.105`, `ping 10.40.10.1`, `ping 10.40.99.12` → **verlustfrei**