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>

docs/cf-tunnel-mapping.md

@@ -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.

docs/teilprojekte.md

@@ -368,7 +368,15 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - **CF-Access-Strang (verzahnt, s. TP11 Track-B):** `hass`-**400 in der HA-iPhone-App = CF-Access davor** (Companion-App kann Access-Login nicht) → Fix **ohne Passthrough**: iPhone in **WARP** enrollen (Device-Identity erfüllt Access; „Warp Login App" existiert bereits `allow:christoph`). ⚠️ **`vw` = aktuell `bypass` (öffentlich!)** → von bypass auf geschützt heben. „Passthrough-Hosts sind die kritischen" (User).
 - **Umsetzungs-Reihenfolge (für die eigene Session):** (1) **Reachability-Matrix je Host** (pve/NAS/macmini → jede Origin, read-only) BEVOR gruppiert wird; (2) **Interim-Sofortfix:** bf-Tunnel auf **pve-only** (pve erreicht alles außer gateway-dw) → 0×1033, reversibel; (3) reziprokes 3-Tunnel-HA bauen (CNAMEs re-pointen, 6 Connectoren, Token je Tunnel; NAS/macmini-Alt-Token entfernen); (4) tote Origins bereinigen; (5) Access-Strang (WARP + vw); (6) Loop-Gegentest.
 - 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) ▸ 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. Nebenbefund: User hat selbst die WARP-Private-Network-Route (`10.40.0.0/16`) gelöscht+neu angelegt (11:36 UTC, Audit-Log bestätigt) → zeigt jetzt auf `bf-pve` statt vorher `bf-nas`. **Entscheidung (User): `bf-pve` bleibt so — pve ist USV-gepuffert, NAS/macmini nicht.** §11 der Mapping-Doc damit überholt. Details: `docs/cf-tunnel-mapping.md §13`.
+- ✅ **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`
+- **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.
+- 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`
 - ✅ **GO durchgezogen 2026-07-13 (16 Shellys VLAN1→VLAN30, 0 Fehler):** Pilot s26 + Welle A (s4–s9) + Welle B (s10/11/13/15/17/19/20/21/25) → alle auf `dirtyvader-iot`/`10.40.30.<octet>` verifiziert (SSID+IP+rssi). Mit den 6 Vorab-Migrierten (s14/16/18/22/23/24) = **22/26 auf VLAN30**; VLAN1-Sweep `.180-250` = **0 Shellys**. Offen nur 4 saisonal ausgesteckte (s1/s2/s3/s12 → beim Einstecken).

docs/tp16.1-warp-mesh-native-ap1.md

@@ -0,0 +1,123 @@
+# TP16.1 — Private Access via native Cloudflare Mesh (WARP Connector) auf ap1
+
+> **Status: Konzept + Runbook fertig (2026-07-16), 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`.
+
+## 1. Warum überhaupt / Root Cause
+
+**Incident 2026-07-16 (unterwegs):** keine BF-IPs über WARP. Diagnose:
+- **TCP über den CF-WARP-Pfad funktioniert** (SSH, alle Web-UIs, MCP-Endpoints erreichbar) —
+- **ICMP ist strukturell kaputt.** Dreiländer-Ping-Befund: fm **36 % Loss** (ICMP-Proxy über QUIC-Connector,
+  funktioniert aber mies), bf **100 %** (macmini-Connector läuft seit dem http2-Fix von heute = QUIC-los →
+  ICMP-unfähig; zusätzlich cloudflared-Container ohne Ping-Sockets), dw **100 %** (192.168.0.0/16 steht in der
+  WARP-Split-Tunnel-Exclude → Pings betreten den Tunnel gar nicht).
+
+**Kernursache:** cloudflared ist **kein** WireGuard, sondern ein QUIC/HTTP2-L7/L4-Proxy. ICMP darüber ist
+Zusatz-Gefrickel (Account-ICMP-Flag + QUIC-Transport + `ping_group_range`-sysctl je Host) und war nie
+zuverlässig eingerichtet. **Der WARP-Client selbst spricht WireGuard** — die passende Gegenstelle für einen
+*sauberen* privaten L3-Zugang ist deshalb **Cloudflare Mesh (WARP Connector)**, ebenfalls WireGuard.
+
+## 2. Entscheidungsweg (was verworfen wurde und warum)
+
+- **WG-Roadwarrior (eigene WG-Peers je Gerät):** ❌ verworfen — User will KEINE Extra-App/kein Profil pro Gerät.
+  „Ein Client = WARP für alles" bleibt Anforderung.
+- **Alle ZT-Anbieter mit Helper-Host** (CF WARP Connector als Daemon-Host, Tailscale, NetBird, Twingate):
+  brauchen dauerhaft einen Linux-Host → verletzt „Router = einziger SPOF, keine Abhängigkeit zu anderen Rechnern".
+- **Connector als RouterOS-Container:** ❌ nicht möglich — RouterOS-7-Container haben **kein `/dev/net/tun`-
+  Passthrough**; der WARP-Connector-Daemon braucht ein TUN-Device. Gilt auf **jeder** Router-HW (hAP ax²/ax³/CRS/RB5009).
+  → **hAP ax³ löst das NICHT** (und ist zudem Wi-Fi 6, nicht 7 — kein WLAN-Gewinn ggü. ax²). HW-Kauf ist vom
+  Tunnel-Fix **entkoppelt** (separat unter TP15 zu bewerten, falls 2,5G/USB/CPU gewünscht).
+- **✅ Gewählt: Cloudflare Mesh als NATIVES WireGuard-Interface auf ap1.** Cloudflare Mesh spricht WireGuard,
+  RouterOS kann natives WireGuard (der TP10-Hub *ist* schon einer). Ein Mesh-Node wird als WG-Peer zu einem
+  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".
+Ehrliche Einschränkung: **von uns noch nicht gebaut** — starker, technisch schlüssiger Lead; echter Beweis = bauen+pingen.
+
+## 3. Ist-Stand Account (gemessen 2026-07-16, read-only)
+
+- Team-Domain: **`emsenhuber.cloudflareaccess.com`** → Mesh-Node-Identität = `warp_connector@emsenhuber.cloudflareaccess.com`
+- **Noch KEIN** `warp_connector`-Tunnel im Account (`GET /accounts/…/warp_connector` = []).
+- Device-Settings: **`use_zt_virtual_ip: false`** (Unique-Device-IP AUS — muss für Mesh AN).
+- Split-Tunnel-Modus = **Exclude**; Exclude-Liste enthält u.a. **`100.64.0.0/10`** (schluckt die Mesh-Overlay-Range
+  `100.96.0.0/12` → Mesh-Traffic würde aktuell NICHT durch WARP gehen). Enthält NICHT `10.0.0.0/8` → deshalb geht
+  `10.40.0.0/16` schon heute über WARP (= warum TCP funktioniert).
+- vnet-Route `10.40.0.0/16` (vnet `1480b545…`, Route-ID **`5546dcb6-5901-4da6-8d91-b17f94703f71`**) zeigt aktuell
+  auf **cfd_tunnel `bf-pve`** (`f7fdf3a6…`). Das bleibt der **Fallback**, bis Mesh bewiesen ist — nichts vorher löschen.
+- ap1-WireGuard IST-Stand: 1 Interface `wg-hub` (listen 51821, MTU 1412), Peers `fm` (10.101.0.0/24) + `dw` (10.95.10.0/24).
+  Das neue Mesh-Interface ist **separat** (outbound zum CF-PoP, kein Listen-Port) → keine Kollision.
+
+## 4. Runbook (nächste Session — Reihenfolge)
+
+### 4.0 Plan-Probe (billig, reversibel) — ZUERST
+`POST /accounts/{account_id}/warp_connector {name:"bf-ap1-mesh"}` via `CF_API_TOKEN` (curl/Bearer — der `cloudflare`-
+MCP ist read-only, s. §11 der Mapping-Doc). Erfolgt der Create → Mesh ist im Free-ZT-Plan erlaubt. Scheitert er mit
+Plan-/Auth-Fehler → **Stopp, Fallback = LXC-auf-pve-WARP-Connector** (alter Plan, ebenfalls dokumentiert).
+Token danach: `GET /accounts/…/warp_connector/{tunnel_id}/token` → das ist das `eyJhIjoi…In0=`-Register-Token.
+
+### 4.1 CF-Prerequisites setzen (⚠️ account-weit, trifft LIVE-Geräte → 1× kurzer WARP-Reconnect einplanen)
+1. **Unique Device IP AN:** `PATCH /accounts/…/devices/settings {use_zt_virtual_ip:true}` (Dashboard: Team & Resources →
+   Devices → Management → „Assign a unique IP address to each device").
+2. **„Allow all Cloudflare One traffic to reach enrolled devices" AN** (gleiche Seite).
+3. **Device-Profile „Cloudflare Mesh"** anlegen: Match `identity.email == warp_connector@emsenhuber.cloudflareaccess.com`,
+   Tunnel-Protokoll = **WireGuard** (`POST /accounts/…/devices/policy`).
+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).
+
+### 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 <REGISTER_TOKEN>
+```
+→ erzeugt `wgcf-connector-<id>.conf` mit: **PrivateKey**, **Address** (`100.96.x.y/32`), 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).
+
+### 4.3 ap1 nativ konfigurieren (MikroMCP: `plan_changes` dryRun → `apply_plan`)
+```
+/interface wireguard add name=cf-mesh mtu=1420 private-key="<PrivateKey aus .conf>"
+/interface wireguard peers add interface=cf-mesh name=cf-pop \
+    public-key="bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" \
+    endpoint-address=162.159.193.1 endpoint-port=2408 \
+    allowed-address=0.0.0.0/0,::/0 persistent-keepalive=25s
+/ip address add address=<100.96.x.y>/32 interface=cf-mesh
+/ip route add dst-address=100.96.0.0/12 gateway=cf-mesh
+```
+- Endpoint: falls die Config `162.159.192.x` liefert → `162.159.193.x` nehmen (Latenz-Tuning laut Guide).
+- MTU 1420 aus dem Guide; gegen unsere Hub-MTU 1412 gegenprüfen (ggf. angleichen bei Path-MTU-Problemen).
+- **Kein** Extra-Static-Route für den Rückweg nötig (anders als der LXC-Plan): ap1 IST der L3-Router aller VLANs.
+- Firewall: forward ist aktuell permissiv (TP5-Deny offen) → kein neues Loch nötig; falls doch ein Drop greift,
+  gezielte Accept `100.96.0.0/12 ↔ 10.40.0.0/16` dokumentiert ergänzen.
+- ⚠️ **Governance:** „Config nur via Nautobot" (TP21) → diese ap1-Zeilen entweder über Nautobot GC abwickeln
+  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: <warp_connector_id>}`.
+- **Rollback jederzeit:** PATCH zurück auf `f7fdf3a6…` (bf-pve) — cloudflared/bf-pve bleibt die ganze Zeit bestehen.
+
+### 4.5 Verifikation (Abnahme)
+- MacBook, WARP **connected**: `ping 10.40.20.105`, `ping 10.40.10.1`, `ping 10.40.99.12` → **verlustfrei**
+  (Regressions-Gegenprobe zu heute: fm 36 % / bf 100 %).
+- TCP-Gegenprobe inkl. NAS-macvlan-IP direkt: `ssh 10.40.20.167`, `https://10.40.20.100:8006`, `10.40.20.157:3000`
+  (gitea) mehrfach → Beweis „keine Blindheit".
+- FQDN-Smoke (Stichprobe gitea/hass/pve über `*.emsenhuber.net`) → der cloudflared-Public-Teil (3-Tunnel-HA) blieb unberührt.
+
+## 5. Danach (Cleanup, teils ins „vertagt"-Gespräch)
+- Nach Mesh-Beweis: `warp-routing` auf bf-nas/bf-pve/bf-mm ggf. auf `false` (Hygiene — Public-Tunnel bedienen keine
+  privaten Netze mehr). CF-vnet-Route-Historie bereinigen.
+- **Vertagt (User „müssen wir noch reden, hat Zeit"):** 4 tote Tunnel (TeilzeitCharlie/coolify/johnny2/openclaw),
+  Ghost-Connector-Session bf-pve (arm64-Leiche vom 12.07.), `gateway-dw`-CNAME.
+
+## 6. Risiken / Fallbacks
+- Einziger Eingriff mit Nutzer-Impact = vnet-Route-Umzug → Rollback = 1 PATCH zurück auf bf-pve.
+- CF-Prerequisites sind account-weit (Unique-IP-ReIP, Split-Tunnel) → 1× kurzer WARP-Reconnect; alle reversibel.
+- Plan-Gate: wenn `warp_connector`-Create scheitert → LXC-auf-pve-WARP-Connector als Fallback (TUN-Passthrough
+  `c 10:200 rwm`, `warp-cli connector new`, ap1-Static-Route `100.96.0.0/12`→LXC).
+- ax³/ZeroTier/Tailscale = separate Eval-Fußnoten, nicht Teil dieses Fixes.