Christoph Emsenhuber
8665902de7
- Governance-Callout (teilprojekte.md): Christoph erteilt Ausnahme von 'Config nur via Nautobot' für alle (Vor)Arbeiten am zentralen CF-Tunnel-Zugang AUF AP1 (TP16/16.1, native WG-Mesh-Zeilen). Scope-Grenze: nur ap1 — CRS326 (TP15) fällt vorerst NICHT darunter, bleibt Nautobot-GC-pflichtig. Follow-up: ap1-Zeilen später in GC nachtragen. - Neu: docs/tp16.1-session-handoff-prompt.md — kopierfertiger Auftrag für die Delegations-Session (Sonnet), Governance-Gate jetzt als 'erteilt' statt 'erst fragen'. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
88 lines
5.1 KiB
Markdown
88 lines
5.1 KiB
Markdown
# TP16.1 — Handoff-Prompt für die Delegations-Session (Sonnet)
|
||
|
||
> **Zweck:** Dieses File ist der kopierfertige Auftrag für eine frische Session, die TP16.1
|
||
> (Private Access via native Cloudflare Mesh/WireGuard auf ap1) 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.md` und 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).
|
||
|
||
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.
|
||
- CF-Writes NUR via CF_API_TOKEN (curl/Bearer) — der cloudflare-MCP ist read-only.
|
||
Token/IDs in mcp/cloudflare/.env. Alle CF-API-Calls laufen über api.cloudflare.com,
|
||
also WARP-unabhängig (Rollback geht auch wenn der private Pfad tot ist).
|
||
- 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 warp_connector → 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.
|
||
|
||
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.
|