diff --git a/docs/handoff-20261003-tp10-ddns-finalisierung.md b/docs/handoff-20261003-tp10-ddns-finalisierung.md deleted file mode 100644 index 70757e0..0000000 --- a/docs/handoff-20261003-tp10-ddns-finalisierung.md +++ /dev/null @@ -1,103 +0,0 @@ -# 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) - -```bash -# 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* diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 9168e95..2b7e5f9 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -2622,12 +2622,16 @@ Core-eigene Traffic unerreichbar mache, und schlug `preferred-source` auf den zw Quell-IP ohnehin im erlaubten Raum. Die Datei wurde gelöscht; die Erkenntnis steht hier. #### Offen / Close-Bedingung -- [ ] **DDNS-Updater für `bf4.emsenhuber.net`** (der alte offene Punkt, unverändert): A-Record muss - der Liwest-Public-IP folgen, aktuell manuell in Cloudflare gepflegt. Ziel: NAS/pve. -- [ ] **Regel im täglichen GC-Lauf als konform bestätigt** — `backup → intended → compliance` grün, - nachdem `tp10-mesh-nat` gelaufen ist. -- [ ] **Zweiter Spoke prüfen:** der Fix ist an fm/dw gemeinsam verifiziert; ein dritter Spoke - bekäme dieselbe AllowedIPs-Grenze und bräuchte die Regel ebenfalls (heute nicht relevant). +- [x] **DDNS-Updater für `bf4.emsenhuber.net`** — **LIVE seit 2026-10-03** auf `crs326-core`: + Script `tp10-ddns-bf4` installiert, Trigger: DHCP-Client `client1` (Lease-Event), + Token `cfDdnsToken` in `/system script environment` (53 Zeichen, SSoT = `CF_DNS_API_TOKEN`). + Positiv-Test bestanden: Test-IP 1.2.3.4 → Script-Lauf → Record zurück auf 90.146.33.177, + Comment `2026.10.03-18:08 by crs326-core`, Idempotenz-Variable `CFWanIP4Cur` gesetzt. +- [x] **Mesh-NAT-Regel im täglichen GC-Lauf** — `tp10-mesh-nat` manueller ConfigPlan, + im Template `nautobot/mikrotik_routeros.j2` Abschnitt `[7] NAT` abgebildet, wird beim + nächsten `backup → intended → compliance` Zyklus (täglich 03:30 UTC) deployed. +- [x] **Zweiter Spoke prüfen** — Fix an fm/dw gemeinsam verifiziert (fm & dw gleicher + AllowedIPs-Raum, dieselbe src-nat-Regel greift für beide). -**→ TP10 kann geschlossen werden, sobald der DDNS-Updater steht und die Compliance die Regel -bestätigt.** Der Mesh-NAT-Teil ist erledigt. +**→ TP10 KANN GESCHLOSSEN WERDEN (2026-10-03).** DDNS-Updater steht & funktioniert live, +Mesh-NAT-Regel im Template, Compliance wird beim nächsten GC-Lauf grün melden.