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>

routeros/fritzbox-wg-lanlan-klickanleitung.md

@@ -1,8 +1,13 @@
 # FritzBox WireGuard als LAN-LAN-Kopplung (FM/DW-Spoke → ap1-Hub) — Klick-Anleitung
 
-> **Methode:** Claude erklärt Absicht + Klickpfad, **du klickst** an der FritzBox. Beispiel FM-Standort
-> (`10.101.0.0/24`, GW `10.101.0.254`), aktuell produktiv über **IPsec**. Hub = ap1 (BF).
-> ⚠️ FRITZ!OS-Labels sind versionsabhängig — wo unsicher, zählt die **Absicht**.
+> **Methode:** Claude erklärt Absicht + Klickpfad, **du klickst** an der FritzBox. FM-Standort
+> (`10.101.0.0/24`, GW `10.101.0.254`). **IPsec ist längst gekillt** → FM läuft bereits über **FB-WireGuard**
+> (peert aktuell mit der **BF-FB** auf `xvbeo64…myfritz:51821`; FM-FB horcht selbst auf
+> `abxhutfgsid9snmy.myfritz.net:52476`). Hub = ap1 (BF). ⚠️ FRITZ!OS-Labels sind versionsabhängig — Absicht zählt.
+>
+> 🔗 **Teil des permanenten Cutovers** (`docs/tp10-vpn-migration.md` + `routeros/wan-cutover-runbook.md`).
+> Der Hub-Endpoint ist jetzt **`bf4.emsenhuber.net:51821`** (DDNS), **nicht** mehr MyFRITZ — denn die BF-FB
+> geht in den Bridge-Mode und verliert MyFRITZ + Portfreigabe. `bf4` zeigt direkt auf ap1-ether1 (Public-IP).
 
 ## 🎯 ROOT CAUSE (bestätigt 2026-06-16) + der Fix
 **Messung:** Ping auf realen FM-Host `10.101.0.10` über WG → Antwort kam aus **`10.255.255.2`** (Tunnel-IP) → **die FB
@@ -20,18 +25,27 @@ FB **muss ihre eigene LAN-IP** sein → dann routet die FB ihr LAN **ohne NAT**,
 |---|---|---|
 | **WG-Interface-Address (FB)** | **`10.101.0.254/24`** (LAN-IP!) | **`192.168.178.1/24`** (LAN-IP!) |
 | Erreichbare Netze / AllowedIPs (→Hub) | `10.40.0.0/16` | `10.40.0.0/16` |
-| Hub-Endpoint | `xvbeo64jqlqd9gfo.myfritz.net:51821` | dito (DW: CGNAT → wählt ausgehend) |
+| Hub-Endpoint | **`bf4.emsenhuber.net:51821`** | dito (DW: CGNAT → wählt ausgehend) |
 | Hub-Public-Key | `P/bztIk13cAmLHbN6oHGGnWAKLZsqR5TXAbFP+NGGBk=` | dito |
 | MTU / Keepalive | `1412` / `25` | `1412` / `25` |
 | Vorbereitete `.conf` | `routeros/.secrets/wg-fm.conf` | `routeros/.secrets/wg-dw.conf` |
 
 ## ⚠️ Sicherheit (FM ist produktiv!)
-- **IPsec bleibt an** = Sicherheitsnetz. Erst abschalten, wenn der Echt-Host-Test grün ist.
-- WG läuft parallel zu IPsec (kein Konflikt). ap1-Seite ist fertig — dort nichts ändern.
+- Die **bestehende FM↔BF-FB-WG bleibt an** = Sicherheitsnetz, bis der Echt-Host-Test über ap1 grün ist.
+- ap1-Seite kommt per `routeros/tp10-cutover-apply.rsc` (Hub scharf, peer1 mit FM-Endpoint) — dort nichts klicken.
 
 ---
 
-## Teil 1 — Bestehende (falsche) FM-WG-Verbindung entfernen
+## ⚡ Schnellpfad (wahrscheinlich ausreichend)
+FM ist **schon** auf WG mit korrektem LAN-IP-Modell (`Address=10.101.0.254/24`) — sonst liefe es nicht sauber.
+Dann ist die ganze Migration **ein Feld**: in der bestehenden FM-WG-Verbindung den **Peer-Endpoint** von
+`xvbeo64…myfritz.net:51821` (BF-FB) auf **`bf4.emsenhuber.net:51821`** (ap1) umbiegen — fertig.
+Erlaubt FRITZ!OS kein Bearbeiten des Endpoints → Verbindung **löschen + via `wg-fm.conf` neu importieren**
+(gleicher Key/Address, nur neuer Endpoint). **Nur wenn FM noch die alte Transfernetz-Adresse hat**, brauchst du
+Teil 1+2 unten.
+
+## Teil 1 — Bestehende (falsche, transfernetz-basierte) FM-WG-Verbindung entfernen
+*(Nur falls FM noch NICHT auf dem LAN-IP-Modell ist.)*
 `Internet → Freigaben → Reiter „VPN (WireGuard)"` → die FM-Verbindung **löschen** (sie hat die falsche
 Transfernetz-Adresse → NAT).
 
@@ -52,13 +66,15 @@ Transfernetz-Adresse → NAT).
 - peer1 allowed-address bleibt `10.101.0.0/24` (Transfernetz-/32 ist obsolet, schadet aber nicht).
 > Sag Bescheid — nicht-disruptiv per MikroMCP.
 
-## Teil 4 — Verifizieren, dann erst IPsec abschalten
-1. WG aktiv (IPsec an lassen). Ich pinge von ap1 sourced `10.40.20.1` → **`10.101.0.10`** + `torch wg-hub`:
-   - **Quelle = `10.101.0.10`** → ✅ kein NAT mehr, echtes LAN-LAN → weiter.
-   - Quelle = `10.255.255.2` → noch NAT → Adresse/Modus in Teil 2 nochmal prüfen.
+## Teil 4 — Verifizieren, dann erst die alte FM↔BF-FB-WG abbauen
+1. Neuer Tunnel aktiv (alte FM↔BF-FB-WG noch an lassen). Ich pinge von ap1 sourced `10.40.20.1` → **`10.101.0.10`**
+   + `torch wg-hub`:
+   - **Quelle = `10.101.0.10`** → ✅ kein NAT, echtes LAN-LAN → weiter.
+   - Quelle = `10.255.255.x` → noch NAT → Adresse/Modus prüfen (Teil 2).
 2. Gegenrichtung: FM-Host → BF-Host (NAS) per IP; **SMB/445 per IP** (NetBIOS-Lehre: per IP/DNS, kein Broadcast).
-3. Beide Richtungen grün → **IPsec für FM auf der BF-FB deaktivieren** → erneut testen.
-4. Stabil → FM migriert. **DW** danach gleich (Address `192.168.178.1/24`, CGNAT → ausgehend/Keepalive).
+3. Beide Richtungen grün → **alte FM↔BF-FB-WG auf der BF-FB deaktivieren** → erneut testen.
+4. Stabil → FM migriert. **DW** läuft analog (Address `192.168.178.1/24`, CGNAT → ausgehend/Keepalive).
 
 ## Rollback
-- WG an der FM-FB deaktivieren + IPsec aktivieren → Ausgangszustand. ap1-Seite unverändert lassen (inert).
+- Auf der FM-FB den Peer-Endpoint zurück auf `xvbeo64…myfritz:51821` (BF-FB) biegen bzw. die alte Verbindung
+  wieder aktivieren → Ausgangszustand. ap1-Seite ist inert, kann bleiben.