TP10 🔧 WG live: Key-Mixup + stale bf4 + DW-Dual-Address behoben, DW→10.95.10.0/24

Live-Debug-Session (Double-NAT): WG-Hub ist jetzt aktiv, FM+DW-Tunnel UP.
- Root Causes behoben: (1) beide ap1-Peers trugen faelschlich ap1s EIGENEN Public-Key
  P/bzt... statt der FB-Keys dzRY.../FqYZ... (2) bf4.emsenhuber.net war stale -> DW-Dial-in
  (CGNAT) lief erst danach. (3) DW-Dual-Address 192.168.178.1/24,10.95.10.1/24 -> FRITZ!OS
  macht 10.95.10.1 primaer u. koppelt das LAN nicht -> Single-Address-Regel.
- DW standardisiert auf 10.95.10.0/24 (Geli renumbert vor Cutoff): wg-dw.conf single,
  ap1 peer dw allowed-address=10.95.10.0/24, Route 10.95.10.0/24 -> wg-hub. Routing verifiziert (0% Loss).
- Klickanleitung: DW-Renumber + Single-Address-Lehre; Doku/Digest auf Live-Stand.

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

docs/tp10-vpn-migration.md

@@ -10,6 +10,15 @@ ether1 `use-peer-dns=no`. FM-`.conf`-Endpoint auf **`bf4…`** umgestellt. Klick
 `routeros/fritzbox-wg-lanlan-klickanleitung.md` (FM-FB) + `routeros/fritzbox-bf-bridge-cutover-klickanleitung.md` (BF-FB).
 Modus: **stagen → am Bridge-Tag 1× Apply + ether1 umstecken** (Runbook unten). FritzBox = kein MCP (UI/Klick).
 
+**🟢 Live-Stand 2026-06-25 (WG-Hub ist bereits AKTIV im Double-NAT, nicht mehr geparkt):**
+- **FM-Tunnel UP** (`peer fm`, bidirektional, kam per ap1-Initiation hoch; FM-FB hat unseren `.conf`-Key übernommen).
+- **DW-Tunnel UP** (`peer dw`, CGNAT-Dial-in via `bf4`; rx>13 MiB). DW-Routing zu `10.95.10.x` von ap1 verifiziert (0% Loss).
+- **Behobene Fehler dieser Session:** (1) beide ap1-Peers trugen fälschlich ap1s **eigenen** Public-Key `P/bzt…` → auf
+  die FB-Keys (`dzRY…`/`FqYZ…`) korrigiert. (2) **`bf4` war stale** (falsche IP) → gefixt, danach DW-Dial-in ok.
+  (3) **DW-Dual-Address** brach die LAN-Kopplung → ap1+Config auf **Single `10.95.10.0/24`** vereinheitlicht.
+- **Offen:** Geli renumbert ihr LAN auf `10.95.10.0/24` + WG-`Address`=`10.95.10.1/24` (single) → dann BF↔Geli-Hosts
+  end-to-end. Danach Bridge-Cutover (löst Inbound-Forward-Abhängigkeit ganz auf).
+
 ## 🅿️ STATUS 2026-06-17: VERTAGT — gebündelt mit dem FB-Bridge-Cutover
 TP10 wird **nicht** mehr als Parallel-Migration vorab gemacht, sondern **zusammen mit dem permanenten FB-Bridge-Cutover**
 — denn **VPN-auf-FB und FB-Bridge schließen sich aus** (Bridge = Modem = keine VPN-Terminierung). Bonus: am Bridge-Tag
@@ -31,7 +40,7 @@ echte LAN-IPs, LAN-LAN sauber. (Gleiche Ursache wie der alte „NetBIOS routet n
 | **Endpoint (Spokes)** | **`bf4.emsenhuber.net:51821`** — DDNS via Cloudflare (Zone `emsenhuber.net`, **proxied=false**, TTL 120) → `86.56.201.104`. Überlebt IP-Wechsel **und** FB-Bridge. NICHT MyFRITZ (stirbt im Bridge). |
 | BF-Seite (AllowedIPs der Spokes) | `10.40.0.0/16` |
 | FM | LAN `10.101.0.0/24` (GW .254). **IPsec gekillt → bereits FB-WG** (peert heute mit BF-FB; FM-FB horcht auf `abxhutfgsid9snmy.myfritz.net:52476`, erreichbar/kein CGNAT). FB-WG-`Address` = **`10.101.0.254/24`** (LAN-IP!). Migration = Peer-Endpoint auf `bf4…:51821` umbiegen. ap1-peer1 bekommt FM-Endpoint → **bidirektional** |
-| DW/Geli | LAN heute `192.168.178.0/24` (GW .1), **CGNAT v4**, Antennengem. Geroldsgrün. Künftig **`10.95.10.0/24`**. FB-WG-`Address` = **`192.168.178.1/24, 10.95.10.1/24`** (Dual, renumber-fest) |
+| DW/Geli | **CGNAT v4**, Antennengem. Geroldsgrün. LAN **auf `10.95.10.0/24` renumbered** (vor Cutoff). FB-WG-`Address` = **`10.95.10.1/24` (SINGLE!)**. ⚠️ **Dual-Address `192.168.178.1/24, 10.95.10.1/24` war ein Fehler** — FRITZ!OS macht 10.95.10.1 primär u. koppelt das LAN nicht → Single-Address-Regel. ap1 `peer dw` = allowed-address `10.95.10.0/24` |
 | Keepalive | Spoke-Seite `PersistentKeepalive=25` (CGNAT-Dial-out) |
 
 **Spoke-Configs (Private-Keys, gitignored):** `routeros/.secrets/wg-fm.conf`, `routeros/.secrets/wg-dw.conf`.