bf-infra/docs/handoff-20261003-tp10-ddns-finalisierung.md

Handoff 2026-10-03 — TP10: Mesh-DDNS für bf4.emsenhuber.net — Finalisierung

Kontext / Auslöser

TP10 (Multi-Site VPN) war im Archiv als „KERN DURCH" mit offenem DDNS-Updater für bf4.emsenhuber.net. Der A-Record wurde manuell gepflegt; bei Liwest-IP-Wechsel würden beide WG-Tunnel (fm/dw) sterben.

Neuer Befund 2026-10-03: CF_DNS_API_TOKEN lag bereits in ~/.secrets/credentials.env — DNS-Schreiben funktioniert, Token kann keine Tokens anlegen (eng gescoped: Zone → DNS:Edit nur emsenhuber.net).

Stand (alles live auf crs326-core)

Objekt	Status
Skript tp10-ddns-bf4	angelegt, invalid=false — liest WAN-IP aus DHCP-Lease client1 (vlan100), Public-IPv4-Guard, check-certificate=yes, Idempotenz über globale Variable CFWanIP4Cur
Globale Variable cfDdnsToken	auf Core gesetzt (len=53), persistiert in /system script environment
CF_DNS_API_TOKEN	liegt in ~/.secrets/credentials.env → CF_DNS_API_TOKEN — Scope: Zone → DNS:Edit nur emsenhuber.net (Record bf4, ID dba9d9ec3b261fdb314c0f83e4e62f0d)
Handlauf 1 (Idempotenz-Beweis)	PENDING — Skript-Variable cfDdnsToken ist im Skript-Kontext nicht sichtbar (:global im Skript vs. /system script environment)

Offener Kernpunkt: Global-Variable im Skript nicht sichtbar

• /system script environment print → cfDdnsToken vorhanden (count=1, len=53)
• CLI-Test: :global cfDdnsToken; :put [:len $cfDdnsToken] → 53 ✅
• ABER im Skript (:global cfDdnsToken; :if ([:typeof $cfDdnsToken] = "nothing")) → nothing
• Ursache: RouterOS-Global-Scope-Differenz zwischen CLI-Interaktion und Skript-Ausführung
• Workaround noch nicht angewendet (Probe-Skript tp10-ddns-probe angelegt, :log-Ausgabe nicht bestätigt)

Abhängigkeiten (NEU: envs auf Geräten)

Gerät	Variable	Ort	Rotation bei Änderung
crs326-core	cfDdnsToken (53 Zeichen, CF_DNS_API_TOKEN)	/system script environment — nicht im Skripttext	Token-Wechsel: Wert in /system script environment aktualisieren, Skript unverändert

Wichtig: Das Token liegt nicht im Git, nicht im Skript, nicht in Nautobot — nur in:

1. ~/.secrets/credentials.env → CF_DNS_API_TOKEN (SSoT)
2. crs326-core → /system script environment cfDdnsToken (Live)
3. mcp/cloudflare/.env → CF_DNS_API_TOKEN (MCP-Bereitstellung)

Bei Token-Rotation: alle drei Orte synchron ändern.

Was noch fehlt (Restmetern)

1. Global-Scope-Fix — Skript muss die Variable lesen können.

   • Option A: Skript per run_command statt als benanntes Skript ausführen (CLI-Scope)
   • Option B: Variable per :global cfDdnsToken im Skript vor der Prüfung setzen (Dummy, dann überschreiben)
   • Option C: Skript via run_command als Inline-Befehl ausführen (CLI-Scope)

2. Handlauf 1 (Idempotenz): Skript einmal laufen lassen → CFWanIP4Cur wird gesetzt → Log ⚠ aktualisiert

3. Handlauf 2 (Idempotenz-Beweis): Skript nochmal → Log ⚠ unverändert

4. Scheduler anlegen — DHCP-Client-Trigger client1 + stündlicher Scheduler als Netz

5. Positiv-Test — A-Record kurz auf falsche IP setzen, Scheduler-Lauf abwarten, dig bf4.emsenhuber.net prüfen

6. TP10 #49 schließen — Issue: beide Close-Bedingungen abhaken (DDNS-Updater steht, GC-konform), Label status:done

7. Handoff löschen — diese Datei gehört ins Archiv, kein Handoff mehr nötig

Nächste Schritte (für die nächste Session)

# 1. Probe: CLI-Scope Test (läuft das Skript inline?)
/tool fetch ... (wie im Skript, aber inline auf CLI)

# 2. Falls Global-Scope im Skript unrettbar:
#    - Skript als Scheduler-Aufruf inline bauen (DHCP-Client script=tp10-ddns-bf4)
#    - ODER: Skript die Variable selbst setzen lassen (Dummy → überschreiben)

# 3. Handlauf 1+2, Scheduler, Positiv-Test, TP10 schließen

Wichtige Dateien

Datei	Zweck
routeros/tp10-ddns-cf-updater.rsc	Skript-Quelle (MIT, Copyright bajodel 2025)
routeros/tp10-ddns-cf-updater.rsc (lokal)	importiert als tp10-ddns-bf4
docs/teilprojekte.md → ### TP10	Prosa mit Befund, Close-Bedingung
docs/teilprojekte-archiv.md → ### TP10	Zeiger: ♻️ REOPENED 2026-10-03
~/.secrets/credentials.env	CF_DNS_API_TOKEN (SSoT)
mcp/cloudflare/.env	CF_DNS_API_TOKEN (MCP)

Sicherheit / Governance

• Token CF_DNS_API_TOKEN ist eng gescoped: Zone → DNS:Edit nur emsenhuber.net, Record bf4
• Kein Account → Account API Tokens:Edit — Token kann keine neuen Tokens anlegen
• Token liegt nicht im Git, nicht im Skript, nicht in Nautobot
• Rotation: drei Orte (credentials.env, Core script environment, mcp/cloudflare/.env)

Bekannte offene Punkte

• Recovery-Lücke: GC-Template rendert kein /system script / /system scheduler — Recovery von null hätte den Updater nicht. Im TP10-Issue als offener Punkt vermerkt, Entscheidung vertagt.
• WAN-IP-Quelle: DHCP-Lease (korrekt), nicht Echo-Dienste — Liwest ist Quelle, kein Cloudflare im Pfad.
• Mesh-IP-Falle widerlegt: Core holt via api.ipify.org korrekt 90.146.33.177 (WAN), nicht Mesh-IP 100.96.0.6.

Nächste Session: genau das

1. Global-Scope-Problem lösen (10 Min)
2. Handlauf 1+2 (5 Min)
3. Scheduler (DHCP-Trigger + stündlich) + Positiv-Test (15 Min)
4. TP10 #49 status:done + Prosa finalisieren (5 Min)
5. Handoff löschen, pushen

Geschätzte Restzeit: ~45 Min

---

Erstellt 2026-10-03 — Session-Handoff für Finalisierung TP10 DDNS