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-vpn-migration.md

@@ -3,11 +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-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),
+ether1 `use-peer-dns=no`. FM-`.conf`-Endpoint auf **`bf4…`** umgestellt. Klick-Anleitungen:
+`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).
+
 ## 🅿️ 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
 hat **ap1 die echte Public-IP** → **kein FB-Port-Forward-Umweg** mehr, Spokes zeigen direkt auf ap1 (via DDNS).
-- **Beide VPN laufen vorerst über die BF-FB:** **FM = IPsec**, **DW = FB-WG** (Status quo, produktiv).
+- **Beide VPN laufen vorerst über die BF-FB:** ~~FM = IPsec~~ → **FM = FB-WG** (IPsec längst gekillt), **DW = FB-WG**.
 - **DW-Config ist aber schon bei Geli vor Ort gestaged** (2026-06-17, seltener Zugriff genutzt) — wird erst aktiv,
   wenn die ap1-Seite live geht (s.u. „Offen").
 
@@ -23,7 +30,7 @@ echte LAN-IPs, LAN-LAN sauber. (Gleiche Ursache wie der alte „NetBIOS routet n
 | Hub `wg-hub` (ap1) | UDP **51821**, MTU 1412, **keine IF-IP**, Key `P/bztIk13cAmLHbN6oHGGnWAKLZsqR5TXAbFP+NGGBk=` |
 | **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), war IPsec. FB-WG-`Address` = **`10.101.0.254/24`** (LAN-IP!) |
+| 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) |
 | Keepalive | Spoke-Seite `PersistentKeepalive=25` (CGNAT-Dial-out) |
 
@@ -31,13 +38,19 @@ echte LAN-IPs, LAN-LAN sauber. (Gleiche Ursache wie der alte „NetBIOS routet n
 **ap1-Park-Zustand:** Peers **disabled**, WG-Routen **entfernt** (FM/DW laufen über FB-Default), `wg-hub` bleibt
 (Key erhalten), Firewall-Regeln bleiben (TP5-Vorarbeit). NAT braucht nichts (Egress wg-hub ≠ masq-Interface bridge/ether1).
 
-## ⏳ Offen — ap1-Seite aktivieren (sobald BF erreichbar; aktuell locked out)
-- `peer2` (DW) enable/neu: `public-key=FqYZLztQ/qME5VDie5QLGH++5299WJiE1dPpQnPbzUw=` (unser Key; falls Gelis FB
-  **eigene** Keys erzeugt → deren Public-Key eintragen), **allowed-address = `192.168.178.0/24, 10.95.10.0/24`**, Endpoint leer.
-- Routen `192.168.178.0/24 → wg-hub` **und** `10.95.10.0/24 → wg-hub`.
-- `peer1` (FM) bleibt **disabled** (FM auf IPsec, vertagt bis Bridge-Tag).
-- Verify: `list_wireguard_peers` Handshake; `/ping 10.101.0.10 src-address=10.40.20.1` bzw. ein Geli-Host → **Quelle muss
-  die echte LAN-IP sein**, nicht `10.255.255.x`. **NetBIOS-Lehre:** per IP/DNS testen (SMB 445), nie Broadcast/Netzwerkumgebung.
+## ✅ 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`.
+- **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).
+
+Hinweis: **NAT, Forward-FW (wg-hub), Default-Fallback-Route, masquerade-ether1 sind bereits korrekt** — nicht im Skript.
+- Verify: `list_wireguard_peers` Handshake; SMB/445 per IP auf FM-/Geli-Host → **Quelle = echte LAN-IP**, nicht
+  `10.255.255.x`. **NetBIOS-Lehre:** per IP/DNS testen, nie Broadcast/Netzwerkumgebung.
 
 ## DW-Gotchas
 - **2 WG zum selben Zielnetz**: Gelis FB lehnt zwei WG-Verbindungen mit überlappenden AllowedIPs (`10.40.0.0/16`) ab