diff --git a/docs/handoff-20260928-core-wghub-ping-fix.md b/docs/handoff-20260928-core-wghub-ping-fix.md deleted file mode 100644 index fff425f..0000000 --- a/docs/handoff-20260928-core-wghub-ping-fix.md +++ /dev/null @@ -1,52 +0,0 @@ -# Handoff 2026-09-28 — Core erreicht FM/DW-Spoke-Netze nicht aus eigener Kraft - -## Kontext / Auslöser -Christoph konnte von Notebook + macmini immer `10.101.0.254` (FM-Standort-GW) pingen, eine -überforderte Vorgänger-Session hatte behauptet, der Core „komme dort nicht hin". Befund -sollte jetzt geprüft und ausgeräumt werden. - -## Befund (alles live verifiziert 2026-09-28, crs326-core) -| Quelle | → 10.101.0.254 (FM-GW) | → 10.101.0.10 (FM-Host) | -|---|---|---| -| macmini (VLAN20, gw 10.40.20.1) | ✅ 0 % Loss | ✅ 0 % Loss | -| Notebook (VLAN10, gw 10.40.10.1) | ✅ 0 % Loss | ✅ 0 % Loss | -| **Core default** (`/ping` ohne src) | ❌ **100 % Loss** | ❌ **100 % Loss** | -| **Core mit `src-address=10.40.10.1`** | ✅ **0 % Loss** (ttl 64) | ✅ **0 % Loss** (ttl 63) | - -## Root Cause -`wg-hub` (TP10 Multi-Site VPN Hub) hat **keine IP-Adresse** — weder live -(`/ip address print where interface="wg-hub"` → leer) noch im GC-Template -(`mikrotik_routeros.j2:379`, nur listen-port/mtu/name/private-key). - -FM-seitig erlaubt die FritzBox als AllowedIPs Richtung Hub `10.40.0.0/16` -(`routeros/fritzbox-wg-lanlan-klickanleitung.md`). Weitergeleiteter Client-Traffic -(Quell-IP 10.40.x) liegt in diesem Raum → läuft. **Core-eigener** Traffic ohne -explizite Quell-IP: RouterOS wählt mangels IP auf wg-hub eine Quell-IP **außerhalb** -von 10.40.0.0/16 (vermutlich WAN `90.146.33.177`) → FM routet die Antwort nicht zurück -→ Timeout. Der Tunnel selbst ist up (FM-Peer last-handshake ~1m45s, rx 140.8 GiB). - -## SSoT / Governance -Die Core-Config liegt im GC-Template `nautobot/mikrotik_routeros.j2`. Dort existieren: -- `:375` `/ip route add ... dst-address=10.101.0.0/24 gateway=wg-hub comment="TP10: FM spoke"` -- `:376` `/ip route add ... dst-address=10.95.10.0/24 gateway=wg-hub comment="TP10: DW spoke"` -- `:379-381` wg-hub Interface + fm/dw Peers (Privkey redacted) - -Ein Fix gehört **ins Template**, nicht als Direkt-Write aufs Gerät (GC-Compliance-Regel). -Deploy via `nautobot/gc-configplan.py` / GC-Job „Backup → Intended → Compliance". - -## Fix-Optionen (noch nicht entschieden) -1. **`preferred-source` auf die zwei TP10-Routen** (Zeile 375/376, z. B. `10.40.10.1`). - Kein FM-Eingriff nötig (FM erlaubt 10.40.0.0/16 bereits). Minimal-invasiv. **Empfohlen.** -2. wg-hub eine IP geben (z. B. dedizierte Adresse aus 10.40.0.0/16) — mehr Risiko, IP-Raum- - Eingriff, FM-Abgleich nötig. -3. FM-seitig AllowedIPs um die Core-WAN-IP erweitern — FritzBox-WG-Config eingeschränkt, nicht sauber. - -## Offene Entscheidungen -- Welche `preferred-source`-IP? (10.40.10.1 = MAIN-SVI ist naheliegend.) -- TP10 ist im Archiv „KERN DURCH, offen nur DDNS-Updater". Neuer Befund → TP10-Issue - `reopen` + Prosa zurück nach `teilprojekte.md`, oder als eigenes kleines TP? (Christoph-Entscheid.) -- Fix jetzt ausführen oder nur dokumentieren? - -## Aufwandsschätzung (Core-Ping-Fix) -Klein. 2 Zeilen Template-Edit + ein GC-Deploy-Zyklus (~30–60 min inkl. Backup/Intended/Compliance) -+ Ping-Verifikation. Kein Hardware-/FM-Eingriff bei Option 1. diff --git a/docs/teilprojekte-archiv.md b/docs/teilprojekte-archiv.md index 078a086..9c15940 100644 --- a/docs/teilprojekte-archiv.md +++ b/docs/teilprojekte-archiv.md @@ -692,6 +692,7 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". ### TP10 · Gitea #49 — Multi-Site VPN — beide WG live auf ap1-Hub (`docs/tp10-vpn-migration.md`) +> ♻️ **REOPENED 2026-10-03 → Volltext zurück in [`teilprojekte.md`](teilprojekte.md#tp10)** (neuer Befund: Mesh-Quell-NAT `100.96.0.0/12` → `10.40.10.1`). Dies ist die eingefrorene Historie. > **Details/Cutover/Gotchas/Eckdaten → `docs/tp10-vpn-migration.md` (Single Source of Truth).** Research: `docs/research/vpn-comparison.md`. - **✅ KERN DURCH (2026-06-27) + EDGE-CUTOVER (2026-07-01):** beide AVM-Tunnel → **2× WireGuard mit Hub auf ap1** migriert. Live: `peer fm` (`10.101.0.0/24`, bidirektional, myfritz-Endpoint) **und** `peer dw` (`10.95.10.0/24`, CGNAT-Dial-in) mit frischem diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index af8324a..a85bbcc 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -2784,3 +2784,61 @@ uns verfranzen. Geli kommt rein, das zählt."* — Diese Prämisse fiel weg: `42 public CF-Worker hinter CF Access (löst auf CF-Anycast), kein BF-Origin ⇒ dafür braucht es kein Split-Horizon; Zugang via TP41-**WARP** gelöst (Geli 2026-09-10 via Android). Der Override-Bedarf für **interne** Namen blieb dabei übersehen — deshalb reopened, s.o. + + +### TP10 · Gitea #49 — Multi-Site VPN (WG-Hub FM/DW) — **REOPENED 2026-10-03** (Mesh-Quell-NAT) + +> **Details/Cutover/Gotchas/Eckdaten → `docs/tp10-vpn-migration.md` (Single Source of Truth).** +> Research: `docs/research/vpn-comparison.md`. Prosa-Historie: `teilprojekte-archiv.md#tp10`. +> **Rückgeholt aus dem Archiv am 2026-10-03** — neuer Befund an derselben Baustelle +> (Konvention: geschlossenes Ticket, kein versiegeltes → reopen statt Zwillings-TP). + +**Bestand (aus dem Archiv, unverändert gültig):** beide WG-Tunnel (fm `10.101.0.0/24`, dw +`10.95.10.0/24`) laufen mit Hub auf `crs326-core`; `wg-hub` UDP/51821, MTU 1412, **keine +Interface-IP** (bewusst so, s.u.). Public-Edge direkt, kein Double-NAT. + +#### 🔴 Neuer Befund (2026-10-03) — Mesh-Quelle außerhalb der Spoke-AllowedIPs +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 aber nur **`10.40.0.0/16`** als AllowedIPs → sie **verwerfen** +den Verkehr. Live bewiesen am Core: + +| Quelle | → Spoke | Ergebnis | +|---|---|---| +| `src=100.96.0.6` (cf-mesh) | fm/dw | ❌ 100 % Loss — **das ist der Fehler** | +| `src=10.40.20.1` (BF-IP) | fm/dw | ✅ 0 % Loss | + +**Fix (live seit 2026-10-03, Commit `1fddf5d`):** eine `src-nat`-Regel 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 (`nautobot/mikrotik_routeros.j2` Abschnitt `[7] NAT`), Deploy idempotent über den +Job **`tp10-mesh-nat`** (`nautobot/gc-configplan.py`, manueller Plan, **nie** full-intended). + +**Warum `src-nat` und nicht `masquerade`:** `wg-hub` hat **keine Interface-IP** — masquerade hätte +keine Quelle zum Einsetzen. Die feste IP `10.40.10.1` hält zudem das Connection-Tracking: die Antwort +an `10.40.10.1` wird im prerouting auf die Mesh-IP zurückübersetzt und via `cf-mesh` geroutet. + +**Abnahme (live 2026-10-03):** Regel-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` ✅. + +#### ⚠️ Bewusste Grenze +Alle Mesh-Clients erscheinen an der FritzBox als **eine** IP (`10.40.10.1`) — unterscheidbar nur +über Connection-Tracking am Core. Christoph-Entscheid 2026-10-03: **bewusst so**, Erreichbarkeit war +das Ziel. Eine Unterscheidbarkeit pro Client ist **nicht** Teil dieses TP. + +#### ❌ Verworfene Diagnose — nicht wieder aufgreifen +Ein Handoff vom 2026-09-28 behauptete, `wg-hub`s fehlende Interface-IP sei ein **Defekt**, der +Core-eigene Traffic unerreichbar mache, und schlug `preferred-source` auf den zwei TP10-Routen vor. +**Beides ist falsch:** (a) die fehlende IF-IP ist **beabsichtigt** und im Archiv dokumentiert; +(b) der Core-eigene Ping ist **kein** Betriebsproblem — normaler Client-Traffic liegt mit seiner +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). + +**→ TP10 kann geschlossen werden, sobald der DDNS-Updater steht und die Compliance die Regel +bestätigt.** Der Mesh-NAT-Teil ist erledigt.