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>
This commit is contained in:
@@ -310,8 +310,30 @@ Letzte in §9.2/§8 als „bleibt `.41`" geführte Origin-Klasse (`pve .41.100`,
|
||||
|
||||
**Befund 2 — WARP-Private-Network-Route umgebogen (User selbst, Audit-Log bestätigt):** Route `10.40.0.0/16` (vnet `1480b545…`) zeigte bis eben laut §11 auf `bf-nas`. Audit-Log zeigt: User hat um **11:36:11 UTC die alte Route gelöscht und um 11:36:24 UTC eine neue angelegt** — die neue zeigt auf **`bf-pve`** (`f7fdf3a6…`), neue Route-ID `5546dcb6…`. Funktional unproblematisch (bf-pve ist nach Befund-1-Fix wieder voll HA, NAS+macmini erreichen wie pve/macmini bei bf-nas 100 % der Origins/VLANs, s. §10.1). Keine weiteren Anomalien im Audit-Log (10.09–10.36 UTC nur erwartete Änderungen: `nautobot`-DNS+Ingress auf `bf-nas` angelegt, mehrere `tunnel.management_session` = Dashboard-Logins).
|
||||
- Gateway-Regeln, Split-Tunnel-Exclude/Include, Virtual-Networks (nur 1, `vnetemsenhuber`) — alle unauffällig, kein Blocker gefunden.
|
||||
- **✅ Entscheidung (User, 2026-07-16): `bf-pve` bleibt die WARP-Route-Baseline, NICHT zurück auf `bf-nas`.** Begründung: der **pve-Host ist USV-gepuffert** (NAS/macmini nicht) — bei Stromausfall bleibt damit wenigstens einer der beiden `bf-pve`-Connectoren (auf NAS/macmini) länger erreichbar, weil pve selbst als Origin-Host der wichtigsten Dienste (u.a. Nautobot-Pfad) am längsten durchhält. §11 ist damit **überholt**: die WARP-Route ist ab 2026-07-16 dauerhaft auf `bf-pve` (`f7fdf3a6…`), nicht auf `bf-nas`.
|
||||
- ⚠️ **Zwischenentscheidung (2026-07-16, später am Tag REVIDIERT — s. Befund 3 + §14):** kurzzeitig als „`bf-pve` bleibt WARP-Route-Baseline wegen USV" festgehalten (Commit `1c1a676`). **Diese Begründung war invertiert** und ist hinfällig: `bf-pve`s Connectoren laufen auf **NAS + macmini** (NICHT auf pve). Bei Stromausfall (nur pve an USV) wären damit **beide** `bf-pve`-Connectoren tot → Route weg. Für die WARP-Route zählt der **Connector**-Standort, nicht der Origin-Host. Der USV-Gedanke führt daher NICHT zu bf-pve. Route bleibt interim auf `bf-pve` als Fallback, bis der native Mesh-Node (§14) steht.
|
||||
|
||||
**Einordnung „WARP spinnt" beim User selbst:** die macmini-Connector-Flaps waren ein echter, messbarer Backend-Defekt und plausibel (mit-)ursächlich — aber ob sie den **kompletten** IP-Ausfall beim User erklären oder ob zusätzlich die mobile WARP-Verbindung selbst instabil war, lässt sich von hier nicht abschließend sagen.
|
||||
**Befund 3 — ICMP strukturell kaputt (User-Ping-Test, nach dem Commit):** TCP über die WARP-Route ging überall (SSH/Web-UIs/MCP), **ICMP nicht.** Dreiländer-Befund: **fm 36 % Loss** (45–655 ms Jitter — ICMP-Proxy über QUIC-Connector, funktioniert aber mies), **bf 100 %** (macmini-Connector jetzt http2 = QUIC-los → ICMP-unfähig; cloudflared-Container ohne Ping-Sockets), **dw 100 %** (192.168.0.0/16 in der WARP-Split-Tunnel-Exclude → Pings betreten den Tunnel gar nicht). **Kernursache:** cloudflared ist ein L7/L4-QUIC-Proxy, kein WireGuard — ICMP darüber ist Zusatz-Gefrickel und war nie sauber eingerichtet. Das ist **kein Bug im heutigen Fix**, sondern eine strukturelle Grenze des cloudflared-Pfads für Private Access.
|
||||
|
||||
**Nächste Schritte:** (1) Ghost-Connector-Eintrag bei `bf-pve` (arm64, 1 Conn, `run_at` 2026-07-12, seither inaktiv) ist harmlos, könnte aber bei Gelegenheit per Connector-Cleanup entfernt werden.
|
||||
**Einordnung „WARP spinnt" beim User selbst:** die macmini-Connector-Flaps waren ein echter, messbarer Backend-Defekt (Befund 1) und plausibel (mit-)ursächlich für die Unzuverlässigkeit; der ICMP-Totalausfall (Befund 3) ist davon getrennt und strukturell.
|
||||
|
||||
**Nächster Schritt = Richtungswechsel, s. §14:** Private Access verlässt den cloudflared-Pfad und wandert auf einen **nativen Cloudflare-Mesh-Node (WireGuard) auf ap1**. Der cloudflared-Public-FQDN-Teil (3-Tunnel-HA) bleibt unberührt. (Ghost-Connector-Eintrag bei `bf-pve`, arm64, 1 Conn, `run_at` 2026-07-12, seither inaktiv — harmlos, Cleanup bei Gelegenheit.)
|
||||
|
||||
---
|
||||
|
||||
## 14. Richtungsentscheid 2026-07-16 — Private Access via native Cloudflare Mesh (WARP Connector) auf ap1 (TP16.1)
|
||||
|
||||
**Trennung der Concerns (wichtig):**
|
||||
- **Public FQDNs** (`*.emsenhuber.net`, MCP-Endpoints, HA-Companion, Access-Policies): bleiben auf dem **cloudflared 3-Tunnel-HA** (bf-nas/bf-pve/bf-mm). Unverändert. macmini-Connectoren = `http2` (Befund 1).
|
||||
- **Private Access** (unterwegs → `10.40.0.0/16` per IP, inkl. ICMP): wechselt vom cloudflared-QUIC-Proxy auf einen **nativen WireGuard-Mesh-Node auf ap1**.
|
||||
|
||||
**Warum ap1-nativ statt cloudflared/LXC/Container:** Cloudflare Mesh spricht WireGuard, RouterOS kann natives WireGuard (der TP10-Hub *ist* einer) → Mesh-Node = WG-Peer zu einem CF-PoP, **kein Container, kein `/dev/net/tun`, kein LXC, keine neue HW**. Erfüllt „ap1 = einziger SPOF, keine Abhängigkeit zu anderen Rechnern", keine macvlan-Blindheit (ap1 routet alle VLANs nativ L3), ICMP/TCP/UDP nativ. RouterOS-Container-Weg ist tot (kein TUN-Passthrough auf JEDER Router-HW) → **hAP ax³ löst das nicht** und ist zudem Wi-Fi 6 (nicht 7); HW-Kauf vom Tunnel-Fix entkoppelt.
|
||||
|
||||
**Status: Konzept + Runbook fertig, Scharfschalten = eigene Session** (User-Entscheid: heute nur Konzept, da der TCP-Pfad funktioniert und nur ICMP-Komfort fehlt; die CF-Prerequisites sind account-weit und träfen die Live-WARP-Geräte). **Vollständiges Runbook + gemessener Account-Ist-Stand: `docs/tp16.1-warp-mesh-native-ap1.md`.**
|
||||
|
||||
**Kernpunkte fürs Scharfschalten (Details im TP16.1-Doc):**
|
||||
- Plan-Probe zuerst: `POST /accounts/…/warp_connector` (via `CF_API_TOKEN`) — zeigt, ob Mesh im Free-ZT-Plan erlaubt ist; sonst Fallback LXC-auf-pve.
|
||||
- Account-weit (1× kurzer WARP-Reconnect): Unique-Device-IP AN (`use_zt_virtual_ip`), „allow CF-One-Traffic → devices", Device-Profile „Cloudflare Mesh" (WireGuard), Split-Tunnel-Exclude `100.64.0.0/10` → `/11`+`100.112.0.0/12`.
|
||||
- WG-Config via `ghcr.io/animmouse/wgcf-connector <token>` (ephemer) → 4 native WG-Zeilen auf ap1 (IF + CF-PoP-Peer `bmXOC+…`/`162.159.193.x:2408` + `100.96.x/32` + Route `100.96.0.0/12`).
|
||||
- vnet-Route `5546dcb6…` von `bf-pve` auf den Mesh-Tunnel umhängen (Rollback = PATCH zurück; bf-pve bleibt Fallback).
|
||||
- Team-Domain gemessen: `emsenhuber.cloudflareaccess.com` → Node-Identität `warp_connector@emsenhuber.cloudflareaccess.com`. Noch kein `warp_connector`-Tunnel im Account.
|
||||
- ⚠️ Governance „Config nur via Nautobot" (TP21): ap1-WG-Zeilen über GC oder als genehmigte Ausnahme.
|
||||
|
||||
Reference in New Issue
Block a user