From 84103acdb7c07b04a524c8d59dfe74ebc725e46c Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Fri, 17 Jul 2026 07:47:26 +0200 Subject: [PATCH] =?UTF-8?q?docs=20=F0=9F=A9=B9=20TP16.1:=20ICMP-Proxy-Korr?= =?UTF-8?q?ektur=20(war=20schon=20AN,=20fm-Ping=2010.101.0.0/24=20beweist?= =?UTF-8?q?=20es)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fehlschluss revidiert: ICMP-Häkchen ist Dashboard-only (nicht im API-Spec), aber aktiv — belegt durch funktionierenden Ping ins FM-Netz. Kein To-Do. bf-Ping-Verlust im Incident lag an QUIC-losen macmini-Connectoren (post-http2), nicht am Flag. Re-Check trotzdem nach Scharfschalten (§4.5). Co-Authored-By: Claude Opus 4.8 --- docs/teilprojekte.md | 2 +- docs/tp16.1-warp-mesh-native-ap1.md | 18 +++++++++++------- 2 files changed, 12 insertions(+), 8 deletions(-) diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 8dec14f..37bba30 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -376,7 +376,7 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". - **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.** +- ✅ **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) ICMP-Proxy ist **bereits AN** (User-Korrektur: fm-Ping `10.101.0.0/24` beweist es — kein To-Do; mein „fehlt" war ein Fehlschluss aus dem API-Spec, das Flag ist Dashboard-only); (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 6f781b2..05b881a 100644 --- a/docs/tp16.1-warp-mesh-native-ap1.md +++ b/docs/tp16.1-warp-mesh-native-ap1.md @@ -3,8 +3,9 @@ > **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). +> Härtungs-Delta 2026-07-17: 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). **Korrektur:** ICMP-Proxy ist bereits AN +> (fm-Ping `10.101.0.0/24` beweist es) — kein To-Do, s. §4.1.5. ## 1. Warum überhaupt / Root Cause @@ -89,11 +90,14 @@ Token danach: `GET /accounts/…/warp_connector/{tunnel_id}/token` → das ist d (= 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). +5. **ICMP-Proxy — ✅ bereits AN, KEIN To-Do** (Korrektur 2026-07-17, User): Die offiziellen Mesh-Docs listen „Gateway proxy + mit TCP, UDP, ICMP" als Prerequisite. TCP+UDP sind an (`gateway_proxy_enabled`/`gateway_udp_proxy_enabled`=true); + **ICMP ist ebenfalls schon angehakt** — **Beweis: `ping` ins FM-Netz `10.101.0.0/24` funktioniert** (über den fm-QUIC-Connector). + Das ICMP-Flag ist nur nicht im public OpenAPI-Spec sichtbar (Dashboard-only), daher hatte ich es fälschlich als „fehlt" geführt. + → **Nichts zu klicken.** Dass bf-Ping im Incident 100 % verlor lag NICHT am Flag, sondern daran, dass die macmini-Connectoren + nach dem http2-Fix QUIC-los sind (cloudflared-ICMP-Proxy braucht QUIC). Mit dem nativen WG-Mesh-Node ist ICMP ohnehin + nativ (kein Gateway-ICMP-Proxy im Pfad). **Trotzdem: nach dem Scharfschalten Ping gegengeprüft** (§4.5) — falls wider + Erwarten doch tot, hier zuerst schauen. ### 4.2 WireGuard-Config extrahieren (einmalig, ephemer) Auf macmini oder pve (Docker vorhanden):