Commit Graph

4 Commits

Author SHA1 Message Date
9daedf710c docs 🔑 TP16.1: Token-Permission-Gotcha — Mesh braucht "Cloudflare One Connector: WARP" (nicht Tunnel Write)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-22 17:22:03 +02:00
84103acdb7 docs 🩹 TP16.1: ICMP-Proxy-Korrektur (war schon AN, fm-Ping 10.101.0.0/24 beweist es)
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>
2026-07-17 07:47:26 +02:00
97e2d9c354 docs 🔎 TP16.1: Recherche verifiziert + Runbook gehärtet (Mesh-Rebranding, ICMP-Proxy-Prereq, vnet-Gotcha, v4-only)
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 <noreply@anthropic.com>
2026-07-17 06:07:13 +02:00
d52cf16e0b docs 📋 TP16.1: Konzept+Runbook Private Access via native Cloudflare Mesh (WireGuard) auf ap1
Incident-Nachgang 2026-07-16: ICMP über den cloudflared-WARP-Pfad ist strukturell
kaputt (TCP ok überall, Ping fm 36%/bf 100%/dw 100% Loss) — cloudflared ist ein
QUIC-L7-Proxy, kein WireGuard. Richtungsentscheid: Private Access (unterwegs ->
10.40.0.0/16 inkl. ICMP) wandert vom cloudflared-Proxy auf einen nativen
Cloudflare-Mesh-Node (WireGuard) auf ap1 -- kein Container/TUN/LXC/neue HW
(RouterOS-Container haben kein /dev/net/tun -> hAP ax3 löst es nicht, zudem WiFi6).
Public-FQDNs bleiben unverändert auf dem cloudflared-3-Tunnel-HA.

- Neu: docs/tp16.1-warp-mesh-native-ap1.md (Konzept + vollständiges Runbook +
  gemessener Account-Ist-Stand, Team emsenhuber.cloudflareaccess.com)
- cf-tunnel-mapping.md §13: ICMP-Dreiländer-Befund; "bf-pve wegen USV" REVIDIERT
  (Begründung invertiert -- bf-pve-Connectoren laufen auf NAS+macmini, nicht pve)
- cf-tunnel-mapping.md §14 + teilprojekte.md TP16.1: Richtungsentscheid dokumentiert

Scharfschalten = eigene Session (CF-Prereqs sind account-weit, treffen Live-WARP).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 22:10:00 +02:00