7.5 KiB
7.5 KiB
TP16.1 — Handoff-Prompt für die Delegations-Session (Sonnet)
⚠️ Veraltet seit 2026-07-22 — Ziel-Device jetzt CRS326 Core-Switch statt ap1 (s. TP16.1 in
teilprojekte.mdunddocs/tp16.1-warp-mesh-native-crs326.md). Dieser Prompt richtet sich noch komplett an ap1 (Text + literale RouterOS-Befehle) und ist zusätzlich gated, bis der CRS326-Bring-up (TP15) + die Nautobot-Adoption (TP21) stehen. Vor Nutzung überarbeiten — nicht ungeprüft an eine neue Session weitergeben.
Zweck: Dieses File ist der kopierfertige Auftrag für eine frische Session, die TP16.1 (Private Access via native Cloudflare Mesh/WireGuard, ursprünglich auf ap1 geplant) scharfschaltet. Empfohlenes Modell: Sonnet (Christoph zuhause = physischer ap1-Zugriff, alles reversibel, Runbook ausführungsreif). Bei Bedarf Opus, falls die account-weiten Prereqs/eine Überraschungs- Diagnose mehr Urteilsvermögen brauchen.
So übergibst du es: Neue Session öffnen und als ersten Prompt schicken: „Lies
docs/tp16.1-session-handoff-prompt.mdund arbeite den Auftrag darin ab." (Alternativ den Block unter „--- PROMPT ---" direkt reinkopieren.)
--- PROMPT ---
TP16.1 — Private Access via native Cloudflare Mesh (WireGuard) auf ap1 scharfschalten.
KONTEXT ZUERST LESEN (in dieser Reihenfolge):
1. docs/tp16.1-warp-mesh-native-ap1.md — dein vollständiges, ausführungsreifes Runbook.
2. docs/cf-tunnel-mapping.md §13/§14 — Incident-Historie + aktueller Tunnel-Stand.
3. docs/teilprojekte.md TP16/TP16.1 + Governance-Callout oben.
4. CLAUDE.md (Projekt) — Hardware/Zugänge/Gotchas, v.a. ap1-Scripting-Gotchas.
ZIEL: Unterwegs per WARP-Client wieder auf 10.40.0.0/16 durchkommen — inkl. ICMP/Ping,
nicht nur TCP. Der Public-FQDN-Teil (cloudflared-3-Tunnel-HA, TP16) bleibt UNBERÜHRT.
Weg: nativer WireGuard-Mesh-Node auf ap1 (kein Container/LXC/neue HW), vnet-Route
10.40.0.0/16 (Route-ID 5546dcb6-5901-4da6-8d91-b17f94703f71) von bf-pve auf den
Mesh-Node umhängen. Rollback = 1 PATCH zurück auf f7fdf3a6 (bf-pve).
‼️ CLOUDFLARE-KOMMUNIKATION — ZUERST LESEN, SONST LÄUFST DU GEGEN DIE WAND ‼️
Es gibt ZWEI getrennte CF-Zugänge. Verwechseln = die "fehlende Permissions"-Falle:
A) Der `cloudflare`-MCP (Tools mcp__cloudflare__docs/search/execute), registriert in
~/.claude.json als https://mcp.cloudflare.com/mcp. Der ist OAuth-basiert und STRIKT
READ-ONLY. Reads/Spec-Suche/Batch-Lesen: super. JEDER Write (POST/PUT/PATCH/DELETE)
scheitert mit "10000: Authentication error". Das ist ERWARTET, KEIN echtes Rechte-
problem und KEIN Grund aufzugeben oder Christoph nach Permissions zu fragen.
⚠️ .claude.json enthält NUR die MCP-URL, KEINEN Verweis auf den Token — der Token
lebt komplett getrennt (siehe B). Ein frischer Agent weiß das NICHT von selbst.
B) Der scoped API-Token CF_API_TOKEN in mcp/cloudflare/.env — DAS ist der Write-Pfad.
Damit wurde das gesamte TP16-3-Tunnel-HA (Tunnel erstellt/geändert/gelöscht) gebaut.
Verifiziert 2026-07-17: MCP-PATCH → 10000-Fehler, identischer curl-PATCH → success:True.
REGEL: Reads gern via MCP (schnell, batchbar). ALLE Writes via curl+CF_API_TOKEN, so:
cd ~/dev/bf-network-r6/mcp/cloudflare && set -a; . ./.env; set +a
curl -s -X POST -H "Authorization: Bearer $CF_API_TOKEN" -H "Content-Type: application/json" \
--data '{...}' "https://api.cloudflare.com/client/v4/accounts/$CF_ACCOUNT_ID/<pfad>"
Verfügbare Env-Keys (Namen, keine Werte): CF_API_TOKEN, CF_ACCOUNT_ID, CF_ZONE_ID,
CF_BF_TUNNEL_ID, CF_PVE_TUNNEL_ID, CF_MM_TUNNEL_ID.
Neuen Mesh-Node-Token holen: GET /accounts/$CF_ACCOUNT_ID/warp_connector/<id>/token via curl+Token.
Alle CF-API-Calls gehen über api.cloudflare.com → WARP-UNABHÄNGIG (Rollback klappt auch,
wenn der private Pfad gerade tot ist). SSoT-Detail: cf-tunnel-mapping.md §11.
RAHMENBEDINGUNGEN:
- Christoph ist ZUHAUSE (physischer ap1-Zugriff → Recovery via Power-Cycle möglich).
- ap1 = einziger Edge/SPOF; MikroMCP live (mcp__mikromcp__*). Writes IMMER erst
plan_changes/dryRun, dann apply_plan. ap1 device-mode=home → kein Scheduler/fetch.
- wgcf-connector läuft als Docker-Einmal-Call auf macmini oder pve (ssh macmini / pve-mcp).
- PrivateKey aus der .conf → ~/.secrets bzw. mcp/cloudflare/.env, NICHT committen.
GOVERNANCE — AUSNAHME BEREITS ERTEILT (Christoph, 2026-07-17):
Die Regel "Config nur via Nautobot" gilt account-weit, ABER für den zentralen CF-Tunnel-
Zugang auf ap1 (TP16/TP16.1) hat Christoph eine Ausnahme erteilt: alle dafür nötigen
(Vor-)Arbeiten auf ap1 dürfen direkt via MikroMCP/CF-API gemacht werden — die nativen
WireGuard-Mesh-Zeilen inklusive. Du musst NICHT vor jedem ap1-Write neu fragen.
SCOPE-GRENZE: gilt nur für ap1. Wenn der zentrale Zugang später auf die CRS326 wandert
(TP15), gilt die Ausnahme dafür NICHT — das wäre dann wieder Nautobot-GC-Pflicht.
Follow-up: die ap1-Ausnahmezeilen später in die Nautobot-GC nachtragen, sobald sie steht.
USER-GATES (weiterhin ansagen/mit Christoph zusammen — NICHT allein durchziehen):
1. Account-weite CF-Prerequisites (§4.1): Unique-Device-IP AN + Split-Tunnel-Exclude
ändern → triggert 1× kurzen WARP-Reconnect auf ALLEN enrollten Geräten. Vorher ansagen.
2. Device-Profil "Cloudflare Mesh" (WireGuard-Protokoll, Match auf
warp_connector@emsenhuber.cloudflareaccess.com) = Dashboard-Klick durch Christoph.
(Die ap1-WG-Config selbst ist durch die Governance-Ausnahme oben freigegeben.)
SCHON GEKLÄRT (nicht nochmal aufrollen):
- ICMP-Proxy ist bereits AN (fm-Ping 10.101.0.0/24 funktioniert = Beweis). Kein To-Do.
Nur nach dem Scharfschalten Ping gegenprüfen (§4.5).
- IPv6 bewusst NICHT (v4-only; Mesh-site-to-site-v6 laut Guide broken).
ABLAUF: Plan-Gate zuerst — POST /accounts/$CF_ACCOUNT_ID/warp_connector {"name":"bf-ap1-mesh"}
via curl+CF_API_TOKEN (NICHT via MCP — der kann nicht schreiben!). Wenn Free-Plan das ablehnt:
STOPP, LXC-auf-pve-Fallback, §6. Dann §4.1→§4.5 des Runbooks. Bei jedem Schritt reversibel
halten; die 2 User-Gates oben mit Christoph koordinieren.
⚠️ Falls du irgendwo "10000: Authentication error" siehst: du hast versehentlich den MCP zum
Schreiben benutzt. Kein Rechteproblem — auf curl+CF_API_TOKEN wechseln (siehe CF-KOMMUNIKATION oben).
ROUTE-UMZUG (§4.4) — Weg A zuerst, Weg B als Fallback:
- Weg A: PATCH /accounts/…/teamnet/routes/5546dcb6… {tunnel_id: <mesh_node_id>}
- Weg B (falls A am vnet scheitert, "virtual networks only for cloudflared"):
DELETE alte Route + POST neue ohne vnet-Angabe. Reihenfolge DELETE→POST zwingend.
ABNAHME (§4.5): MacBook mit WARP connected → ping 10.40.20.105, 10.40.10.1,
10.40.99.12 verlustfrei; TCP-Gegenprobe inkl. NAS-macvlan-IP direkt (ssh 10.40.20.167,
gitea 10.40.20.157:3000); FQDN-Stichprobe (gitea/hass über *.emsenhuber.net) = Public-Teil
unberührt.
DOKU (Pflicht am Ende): As-Built-Abschnitt in docs/tp16.1-warp-mesh-native-ap1.md ergänzen
(gemessene Mesh-Node-ID, ap1-WG-IP 100.96.x.y, was tatsächlich lief/nicht lief) +
teilprojekte.md TP16.1-Status fortschreiben + cf-tunnel-mapping.md wenn sich die Route-
Zuordnung ändert. Danach committen + pushen (Commit-Msg-Konvention siehe git log).
Governance-Nachtrag-ToDo (ap1-Zeilen → Nautobot-GC) als offenen Punkt vermerken.
--- ENDE PROMPT ---
Was Christoph zur Session parat haben sollte
- Am MacBook mit WARP connected sein (für die Abnahme §4.5).
- Für die 2 User-Gates verfügbar: Dashboard-Klick (Device-Profil) + Ansage vor dem account-weiten WARP-Reconnect.