admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity

TP10 — Multi-Site VPN #49

New Issue
Closed
opened 2026-09-07 11:26:56 +02:00 by admin · 2 comments
admin commented 2026-09-07 11:26:56 +02:00
Owner
Copy Link

Steuerungs-SSoT: Index/Status hier in Gitea; Prosa/Detail im Repo unter docs/teilprojekte-archiv.md (Abschnitt TP10).

  • Status: ✅ (status:done)
Steuerungs-SSoT: Index/Status hier in Gitea; **Prosa/Detail** im Repo unter `docs/teilprojekte-archiv.md` (Abschnitt `TP10`). - Status: ✅ (status:done)
admin added the status:done label 2026-09-07 11:26:56 +02:00
admin closed this issue 2026-09-07 11:26:56 +02:00
admin reopened this issue 2026-10-03 16:01:52 +02:00
admin commented 2026-10-03 16:01:53 +02:00
Author
Owner
Copy Link

♻️ Reopened 2026-10-03 — Mesh-Quell-NAT für die FM/DW-Spokes

Befund (live bewiesen): WARP-Clients erreichen die Spoke-Netze über cf-mesh (TP16.1) mit
Quell-IP 100.96.0.0/12. Die Spoke-FritzBoxen führen am WG-Peer nur 10.40.0.0/16 als AllowedIPs
→ sie verwerfen den Verkehr.

Quelle → Spoke Ergebnis
src=100.96.0.6 (cf-mesh) fm/dw ❌ 100 % Loss — der Fehler
src=10.40.20.1 (BF-IP) fm/dw ✅ 0 % Loss

Fix (live, Commit 1fddf5d): src-nat auf dem wg-hub-Egress legt die Quelle in den
AllowedIPs-Raum:

/ip firewall nat add action=src-nat chain=srcnat \
  comment="TP10: NAT mesh source to WG spokes (AllowedIPs)" \
  out-interface=wg-hub src-address=100.96.0.0/12 to-addresses=10.40.10.1

Soll im GC-Template (mikrotik_routeros.j2 [7] NAT), Deploy idempotent über Job tp10-mesh-nat
(manueller Plan, nie full-intended). src-nat statt masquerade, weil wg-hub keine
Interface-IP hat — masquerade hätte keine Quelle.

Abnahme (live 2026-10-03): Zähler steigt (6 Pakete/456 Bytes bei der ersten Prüfung),
Core → 10.95.10.246 ✅ 0 % Loss (vorher 100 %), Mac/WARP → 10.95.10.1 ✅.

⚠️ Verworfene Diagnose — bitte nicht wieder aufgreifen

Der Handoff vom 2026-09-28 behauptete, die fehlende Interface-IP von wg-hub sei ein Defekt,
der Core-eigenen Traffic unerreichbar mache, und schlug preferred-source auf den zwei TP10-Routen
vor. Beides ist widerlegt: die fehlende IF-IP ist beabsichtigt (im Archiv dokumentiert), und der
Core-eigene Ping ist kein Betriebsproblem — normaler Client-Traffic liegt mit seiner Quell-IP ohnehin
im erlaubten Raum. Die Handoff-Datei wurde gelöscht; die Erkenntnis steht in teilprojekte.md#tp10.

Close-Bedingung

  • DDNS-Updater für bf4.emsenhuber.net (der alte offene Punkt): A-Record muss der
    Liwest-Public-IP folgen, aktuell manuell in Cloudflare gepflegt. Ziel: NAS/pve.
  • Regel im täglichen GC-Lauf konform — backup → intended → compliance grün.

→ Der Mesh-NAT-Teil ist erledigt. Schließbar, sobald der DDNS-Updater steht und die Compliance
die Regel bestätigt.

Prosa: docs/teilprojekte.md → ### TP10 (Volltext aus dem Archiv zurückgeholt).

## ♻️ Reopened 2026-10-03 — Mesh-Quell-NAT für die FM/DW-Spokes **Befund (live bewiesen):** WARP-Clients erreichen die Spoke-Netze über `cf-mesh` (TP16.1) mit Quell-IP `100.96.0.0/12`. Die Spoke-FritzBoxen führen am WG-Peer nur `10.40.0.0/16` als AllowedIPs → sie verwerfen den Verkehr. | Quelle | → Spoke | Ergebnis | |---|---|---| | `src=100.96.0.6` (cf-mesh) | fm/dw | ❌ 100 % Loss — **der Fehler** | | `src=10.40.20.1` (BF-IP) | fm/dw | ✅ 0 % Loss | **Fix (live, Commit `1fddf5d`):** `src-nat` auf dem `wg-hub`-Egress legt die Quelle in den AllowedIPs-Raum: ``` /ip firewall nat add action=src-nat chain=srcnat \ comment="TP10: NAT mesh source to WG spokes (AllowedIPs)" \ out-interface=wg-hub src-address=100.96.0.0/12 to-addresses=10.40.10.1 ``` Soll im GC-Template (`mikrotik_routeros.j2` `[7] NAT`), Deploy idempotent über Job **`tp10-mesh-nat`** (manueller Plan, nie full-intended). **`src-nat` statt `masquerade`**, weil `wg-hub` keine Interface-IP hat — masquerade hätte keine Quelle. **Abnahme (live 2026-10-03):** Zähler steigt (6 Pakete/456 Bytes bei der ersten Prüfung), Core → `10.95.10.246` ✅ 0 % Loss (vorher 100 %), Mac/WARP → `10.95.10.1` ✅. ### ⚠️ Verworfene Diagnose — bitte nicht wieder aufgreifen Der Handoff vom 2026-09-28 behauptete, die fehlende Interface-IP von `wg-hub` sei ein **Defekt**, der Core-eigenen Traffic unerreichbar mache, und schlug `preferred-source` auf den zwei TP10-Routen vor. **Beides ist widerlegt:** die fehlende IF-IP ist beabsichtigt (im Archiv dokumentiert), und der Core-eigene Ping ist kein Betriebsproblem — normaler Client-Traffic liegt mit seiner Quell-IP ohnehin im erlaubten Raum. Die Handoff-Datei wurde gelöscht; die Erkenntnis steht in `teilprojekte.md#tp10`. ### Close-Bedingung - [ ] **DDNS-Updater für `bf4.emsenhuber.net`** (der alte offene Punkt): A-Record muss der Liwest-Public-IP folgen, aktuell manuell in Cloudflare gepflegt. Ziel: NAS/pve. - [ ] **Regel im täglichen GC-Lauf konform** — `backup → intended → compliance` grün. **→ Der Mesh-NAT-Teil ist erledigt.** Schließbar, sobald der DDNS-Updater steht und die Compliance die Regel bestätigt. Prosa: `docs/teilprojekte.md` → `### TP10` (Volltext aus dem Archiv zurückgeholt).
admin added status:wip and removed status:done labels 2026-10-03 16:01:59 +02:00
admin added the status:done label 2026-10-05 18:55:22 +02:00
admin commented 2026-10-05 18:55:32 +02:00
Author
Owner
Copy Link

✅ Abgeschlossen 2026-10-05 — beide Close-Bedingungen erfüllt

1. DDNS-Updater für bf4.emsenhuber.net — LIVE auf crs326-core

Script tp10-ddns-bf4 installiert, Trigger = DHCP-Client client1 (Lease-Event, kein stündlicher Scheduler nötig — Entscheid Christoph). Token cfDdnsToken liegt in /system script environment (53 Zeichen).

Positiv-Test bestanden:

Schritt Ergebnis
A-Record manuell auf Test-IP 1.2.3.4 gesetzt
/system script run tp10-ddns-bf4 lief fehlerfrei
A-Record danach 90.146.33.177 (korrekte Liwest-WAN-IP)
Comment am Record 2026.10.03-18:08 by crs326-core ← vom Script geschrieben
Idempotenz-Variable CFWanIP4Cur auf 90.146.33.177 gesetzt

2. Mesh-NAT-Regel im täglichen GC-Lauf konform — ✅

  • nautobot_golden_config: ip-firewall-nat = true für crs326-core
  • Die Regel steht in der Intended Config (Zeile 425), nicht nur im Backup:
    /ip firewall nat add action=src-nat chain=srcnat comment="TP10: NAT mesh source to WG spokes (AllowedIPs)" out-interface=wg-hub src-address=100.96.0.0/12 to-addresses=10.40.10.1
  • Zwei tägliche AllDevicesGoldenConfig-Läufe nach dem Fix grün (2026-10-04, 2026-10-05) — kein Zufallstreffer aus einem alten Backup.

Nachtrag zum Global-Scope-Fix (Commit 6e2a7cf): :global cfDdnsToken liest im Skript-Kontext nothing, obwohl /system script environment gesetzt ist — RouterOS 7.24 trennt CLI- und Skript-Scope. Lösung: /system script environment find/get ist scope-unabhängig.

Commits: 6e2a7cf (Global-Scope-Fix) + 75bd43d (Abschluss/Doku) → gepusht nach main.

Doku: Handoff-Datei gelöscht, TP10-Prosa in docs/teilprojekte.md auf abgeschlossen gesetzt, Volltext bleibt im Archiv als eingefrorene Historie.

⚠️ Offener Restpunkt (bewusst, nicht Teil dieses TP)

Die Recovery-Lücke bleibt: das GC-Template rendert kein /system script / /system scheduler. Ein Recovery von null hätte den DDNS-Updater nicht. Im Abschnitt „Offene Punkte" von teilprojekte.md#tp10 vermerkt; Entscheidung vertagt (Ablösung durch Komodo geplant).

## ✅ Abgeschlossen 2026-10-05 — beide Close-Bedingungen erfüllt **1. DDNS-Updater für `bf4.emsenhuber.net`** — LIVE auf `crs326-core` Script `tp10-ddns-bf4` installiert, Trigger = **DHCP-Client `client1`** (Lease-Event, kein stündlicher Scheduler nötig — Entscheid Christoph). Token `cfDdnsToken` liegt in `/system script environment` (53 Zeichen). Positiv-Test bestanden: | Schritt | Ergebnis | |---|---| | A-Record manuell auf Test-IP `1.2.3.4` | gesetzt | | `/system script run tp10-ddns-bf4` | lief fehlerfrei | | A-Record danach | **`90.146.33.177`** (korrekte Liwest-WAN-IP) | | Comment am Record | `2026.10.03-18:08 by crs326-core` ← vom Script geschrieben | | Idempotenz-Variable `CFWanIP4Cur` | auf `90.146.33.177` gesetzt | **2. Mesh-NAT-Regel im täglichen GC-Lauf konform** — ✅ - `nautobot_golden_config`: **`ip-firewall-nat` = true** für `crs326-core` - Die Regel steht in der **Intended Config** (Zeile 425), nicht nur im Backup: `/ip firewall nat add action=src-nat chain=srcnat comment="TP10: NAT mesh source to WG spokes (AllowedIPs)" out-interface=wg-hub src-address=100.96.0.0/12 to-addresses=10.40.10.1` - **Zwei tägliche `AllDevicesGoldenConfig`-Läufe nach dem Fix grün** (2026-10-04, 2026-10-05) — kein Zufallstreffer aus einem alten Backup. **Nachtrag zum Global-Scope-Fix (Commit `6e2a7cf`):** `:global cfDdnsToken` liest im Skript-Kontext `nothing`, obwohl `/system script environment` gesetzt ist — RouterOS 7.24 trennt CLI- und Skript-Scope. Lösung: `/system script environment find/get` ist scope-unabhängig. **Commits:** `6e2a7cf` (Global-Scope-Fix) + `75bd43d` (Abschluss/Doku) → gepusht nach `main`. **Doku:** Handoff-Datei gelöscht, TP10-Prosa in `docs/teilprojekte.md` auf abgeschlossen gesetzt, Volltext bleibt im Archiv als eingefrorene Historie. ### ⚠️ Offener Restpunkt (bewusst, nicht Teil dieses TP) Die **Recovery-Lücke** bleibt: das GC-Template rendert **kein `/system script` / `/system scheduler`**. Ein Recovery von null hätte den DDNS-Updater nicht. Im Abschnitt „Offene Punkte" von `teilprojekte.md#tp10` vermerkt; Entscheidung vertagt (Ablösung durch Komodo geplant).
admin removed the status:wip label 2026-10-05 18:55:35 +02:00
admin closed this issue 2026-10-05 18:55:39 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
status:concept
status:done
status:dropped
status:idea
status:paused
status:todo
status:wip
thema:backlog
thema:cloudflare-proxy
thema:firewall-dns
thema:identity
thema:infra
thema:ipv6-matter
thema:nautobot-doku
thema:wlan
No Label status:done
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
admin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: admin/bf-infra#49
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?