TP10 ✅ Kern durch: beide WG live auf ap1-Hub, FB-Bridge entblockt

DW/Geli on-site abgeschlossen (2026-06-27): Geli auf 10.95.10.0/24
renumbert, FB-WG single 10.95.10.1/24, alter FB↔FB-WG geswappt.
End-to-End verifiziert (macmini/Linz → Gelis 24/7-APs .246/.247,
echte LAN-IPs, kein 10.255.255.x-NAT-Leak). FM+DW live im Double-NAT.

Doku/Status von "🅿️ vertagt/geparkt" auf Ist-Stand gezogen, Bridge-Gate
an allen Stellen aufgelöst, stale 192.168.178-Referenzen bereinigt.

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

docs/tp10-vpn-migration.md

@@ -3,6 +3,18 @@
 > **Single Source of Truth** für TP10. Research: `docs/research/vpn-comparison.md` · IPv6: Memory `project-ipv6-state`.
 > Plan-Scratch (historisch, teils überholt): `~/.claude/plans/pure-wibbling-graham.md`.
 
+## ✅ STATUS 2026-06-27: KERN DURCH — beide WG live auf ap1-Hub, Bridge entblockt
+**TP10-Kern erreicht:** beide AVM-Tunnel auf **2× WireGuard mit Hub auf ap1** migriert, noch im Double-NAT über die
+BF-FB-Portfreigabe (51821 → ap1). Live verifiziert: `peer fm` (`10.101.0.0/24`, bidirektional) **und** `peer dw`
+(`10.95.10.0/24`, CGNAT-Dial-in) mit frischem Handshake + Traffic; **keine Stale-Route** mehr (`192.168.178` raus).
+- **DW/Geli on-site abgeschlossen (2026-06-27):** Geli auf `10.95.10.0/24` renumbert, FB-WG **single `10.95.10.1/24`**,
+  Keepalive 25, Endpoint `bf4…:51821`; alter Geli↔BF-FB-WG sauber geswappt (nur noch der neue Tunnel in Gelis VPN-Liste).
+  **End-to-End verifiziert:** macmini/Linz → Gelis 24/7-APs **`10.95.10.246/.247`** (fixe IP) sauber erreichbar,
+  echte LAN-IPs, **kein `10.255.255.x`**-NAT-Leak. FM-IPsec gekillt.
+- **→ FB-Bridge entblockt:** die FB terminiert keine Tunnel mehr. **Rest:** WAN-Input-Seal (Block C aus
+  `routeros/tp10-cutover-apply.rsc`) + **Liwest-Anruf** → ether1 = Public Edge, Double-NAT weg; danach BF-FB-eigenen
+  WG-Server 51820 abräumen; DDNS-Auto-Updater für `bf4` auf NAS/pve.
+
 ## 🟢 STATUS 2026-06-25: CUTOVER-READY — Apply-Skript gestaged, wartet auf Bridge-Tag
 ap1-Live-Stand verifiziert; alle ap1-Änderungen in **`routeros/tp10-cutover-apply.rsc`** gebündelt (idempotent):
 WG-Peers säubern+enable, Spoke-Routen, **Input-Chain WAN-Seal** (🔴 ap1 bekommt Public-IP → Management/Resolver dicht),
@@ -16,8 +28,8 @@ Modus: **stagen → am Bridge-Tag 1× Apply + ether1 umstecken** (Runbook unten)
 - **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).
+- **✅ Erledigt (2026-06-27):** Geli auf `10.95.10.0/24` renumbert, WG-`Address`=`10.95.10.1/24` (single) → BF↔Geli-Hosts
+  end-to-end verifiziert (s. Status-Block oben). Nächster Schritt = 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**
@@ -50,9 +62,9 @@ echte LAN-IPs, LAN-LAN sauber. (Gleiche Ursache wie der alte „NetBIOS routet n
 ## ✅ ap1-Seite — gestaged in `routeros/tp10-cutover-apply.rsc` (am Bridge-Tag anwenden)
 Das Skript erledigt idempotent (Live-Stand 2026-06-25 verifiziert):
 - **peer1 (FM)** allowed-address `10.101.0.0/24` (Transfernetz-/32 raus), enable. Key `dzRY0lnn…fyiVE=`.
-- **peer2 (DW)** allowed-address `192.168.178.0/24,10.95.10.0/24` (Transfernetz-/32 raus, künftiges Netz rein), enable.
-  Key `FqYZLztQ…PbzUw=` (falls Gelis FB **eigene** Keys erzeugt → deren Public-Key eintragen).
-- Routen `10.101.0.0/24`, `192.168.178.0/24`, `10.95.10.0/24` → `wg-hub`.
+- **peer2 (DW)** allowed-address `10.95.10.0/24` (single — Gelis FB sourct daraus; Dual-Address war ein Fehler), enable.
+  Key `FqYZLztQ…PbzUw=`. **✅ live + verifiziert.**
+- Routen `10.101.0.0/24`, `10.95.10.0/24` → `wg-hub`.
 - **Input-WAN-Seal** (est/rel · drop invalid · WG51821 · dhcp68 · icmp · LAN · **drop WAN**) — schließt
   telnet/ftp/ssh/api/winbox/www + offenen Resolver/53 gegenüber dem Internet, sobald ether1 die Public-IP hat.
 - ether1-DHCP `use-peer-dns=no` (DoH bleibt einzige DNS-Quelle).
@@ -65,8 +77,8 @@ Hinweis: **NAT, Forward-FW (wg-hub), Default-Fallback-Route, masquerade-ether1 s
 - **2 WG zum selben Zielnetz**: Gelis FB lehnt zwei WG-Verbindungen mit überlappenden AllowedIPs (`10.40.0.0/16`) ab
   → **direkter Swap** (alten Geli↔BF-FB-WG entfernen, neuen Geli↔ap1 anlegen), kein Parallelbetrieb. On-site oder via
   temporärem Admin-Tunnel zu anderem Zielnetz.
-- **Fernzugang zu Gelis FB**: MyFRITZ-v4 tot (CGNAT). Sobald Geli↔ap1 steht → FB unter `192.168.178.1` über den Tunnel
-  erreichbar (Endpoint später proaktiv pflegen, solange Tunnel läuft).
+- **Fernzugang zu Gelis FB**: MyFRITZ-v4 tot (CGNAT). Tunnel steht (2026-06-27) → FB unter **`10.95.10.1`** über den
+  Tunnel erreichbar (nach Renumber; Endpoint proaktiv pflegen, solange Tunnel läuft).
 
 ## 💡 DW-Variante: v6-direkt statt CGNAT-Spoke (für später)
 Gelis CGNAT ist **nur v4**; ihre FB hat **öffentliches natives IPv6** (`2a0e:7a02:31c:3000::/56`, rotiert ~30h → MyFRITZ),