TP10 🔐 Cutover-Ready: ap1-Apply-Skript + WAN-Input-Seal + FB-Klickanleitungen

ap1-Seite gestaged in routeros/tp10-cutover-apply.rsc (idempotent, am Bridge-Tag
anwenden): WG-Peers säubern (Transfernetz-/32 raus) + enable, peer1/FM bidirektional
(Endpoint abxhutfgsid9snmy.myfritz.net:52476, kein CGNAT), peer2/DW Dial-in; Spoke-
Routen → wg-hub; Input-Chain WAN-Seal (schließt Mgmt-Dienste + offenen Resolver,
sobald ether1 die Public-IP hält); ether1 use-peer-dns=no.

FB-Seite (kein MCP → Klickanleitung): neue fritzbox-bf-bridge-cutover-klickanleitung.md
(Passthrough + alte FM/DW-WG-Teardown + Rollback); fritzbox-wg-lanlan-klickanleitung.md
mit Schnellpfad (FM nur Peer-Endpoint auf bf4 umbiegen) + IPsec-Korrektur.

Doku: tp10-vpn-migration.md Status → CUTOVER-READY, Live-Stand verifiziert; FM=FB-WG
(IPsec längst gekillt) korrigiert. wan-cutover-runbook.md als permanenter Cutover markiert.

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

docs/tp10-context-digest.md

@@ -3,7 +3,7 @@
 > Verdichteter Handoff-Stand. Vollständig: `docs/tp10-vpn-migration.md`. (Erstellt lokal via Ollama
 > `nemotron-3-nano:4b`, fakten-gegengeprüft.)
 
-- **TP10** = 2 AVM-Tunnel (FM=IPsec, DW/Geli=FB-WireGuard) → **2× WireGuard mit Hub auf ap1** (MikroTik hAP). Gated: permanenter FB-Bridge.
+- **TP10** = 2 AVM-Tunnel (FM **= FB-WG**, IPsec längst gekillt; DW/Geli = FB-WireGuard) → **2× WireGuard mit Hub auf ap1** (MikroTik hAP). Gated: permanenter FB-Bridge.
 - **Entscheidung 2026-06-17:** TP10 **vertagt, gebündelt mit FB-Bridge-Cutover** (VPN-auf-FB ⊕ Bridge schließen sich aus). Am Bridge-Tag hat ap1 die Public-IP → kein Port-Forward. Vorerst beide VPN über die BF-FritzBox: **FM=IPsec, DW=FB-WG**.
 - **Root Cause (FM-PoC bewiesen):** FB masqueradet den WG-Tunnel, wenn die WG-Interface-`Address` eine **Transfernetz-IP** ist. AVM = Proxy-ARP → **FB-WG-`Address` MUSS die LAN-IP sein**. Beweis: Ping `10.101.0.10` kam aus `10.255.255.2` (NAT).
 - **Eckdaten:**
@@ -13,6 +13,6 @@
   - FM LAN **`10.101.0.0/24`** GW .254, FB-WG-`Address` = **`10.101.0.254/24`**
   - DW/Geli CGNAT v4, LAN heute **`192.168.178.0/24`** GW .1, künftig **`10.95.10.0/24`**. FB-WG-`Address` = **`192.168.178.1/24, 10.95.10.1/24`** (dual, renumber-fest). Keepalive 25.
 - **Zustand:** ap1-Hub geparkt (Peers disabled, WG-Routen entfernt, Firewall bleibt). DW-Config bei Geli vor Ort gestaged 2026-06-17.
-- **Offen (sobald BF erreichbar):** `peer2` enable, allowed-address **`192.168.178.0/24,10.95.10.0/24`** (Key `FqYZLztQ/qME5VDie5QLGH++5299WJiE1dPpQnPbzUw=` oder Gelis FB-eigener Key), Routen `192.168.178.0/24` + `10.95.10.0/24` → wg-hub. `peer1`/FM bleibt disabled.
+- **Gestaged (`routeros/tp10-cutover-apply.rsc`, am Bridge-Tag anwenden):** `peer1`/FM enable, allowed-address `10.101.0.0/24`, **Endpoint `abxhutfgsid9snmy.myfritz.net:52476`** (bidirektional, FM kein CGNAT). `peer2`/DW enable, allowed-address **`192.168.178.0/24,10.95.10.0/24`** (Key `FqYZLztQ…PbzUw=` oder Gelis FB-eigener Key), Endpoint leer (CGNAT-Dial-in). Routen `10.101.0.0/24` + `192.168.178.0/24` + `10.95.10.0/24` → wg-hub. Plus Input-WAN-Seal + ether1 `use-peer-dns=no`.
 - **Gotchas:** (1) FB-WG-`Address` = LAN-IP, kein Transfernetz. (2) NetBIOS routet nicht über Tunnel → per IP/DNS testen (SMB 445), kein Broadcast. (3) Gelis FB lehnt 2 WG zum selben Zielnetz ab → direkter Swap. (4) Verify: Antwort-Quelle muss echte LAN-IP sein, nicht `10.255.255.x`.
 - **v6-Variante (später):** Gelis FB hat natives öffentliches IPv6 `2a0e:7a02:31c:3000::/56` (rotiert ~30h via MyFRITZ), v6-Inbound offen → direktes WG ap1↔Geli über v6 umgeht CGNAT; Inner-Tunnel bleibt IPv4.