admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity

docs 🩹 TP16.1: ICMP-Proxy-Korrektur (war schon AN, fm-Ping 10.101.0.0/24 beweist es)

Browse Source 
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 <noreply@anthropic.com>
This commit is contained in:
Christoph Emsenhuber
2026-07-17 07:47:26 +02:00
parent 97e2d9c354
commit 84103acdb7
2 changed files with 12 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/tp16.1-warp-mesh-native-ap1.md
View File

@@ -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):