TP10 reopened: Mesh-Quell-NAT dokumentiert, widerlegte Handoff-Diagnose entfernt

Der Fix aus 1fddf5d ist live und verifiziert. Dieser Commit traegt die Doku nach und
raeumt eine falsche Diagnose weg, die eine Folge-Session in die Irre gefuehrt haette.

- TP10 (#49) reopened (status:wip), Prosa-Volltext zurueck aus dem Archiv nach
  teilprojekte.md; im Archiv bleibt der Zeiger.
- Neuer Befund dokumentiert: WARP-Clients kommen via cf-mesh mit 100.96.0.0/12 an,
  ausserhalb der Spoke-AllowedIPs (10.40.0.0/16) -> FritzBox verwirft. Beweis-Tabelle
  und Abnahme-Werte im Abschnitt.
- Close-Bedingung ins Issue geschrieben: DDNS-Updater bf4.emsenhuber.net + taeglicher
  GC-Lauf konform. Der Mesh-NAT-Teil ist erledigt.
- docs/handoff-20260928-core-wghub-ping-fix.md GELOESCHT: er behauptete, die fehlende
  Interface-IP von wg-hub sei ein Defekt, und schlug preferred-source vor. Beides
  widerlegt — die fehlende IF-IP ist beabsichtigt (im Archiv dokumentiert), und der
  Core-eigene Ping ist kein Betriebsproblem. Die Erkenntnis steht jetzt in TP10.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

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.
+
+<a id="tp10"></a>
+### 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.