TP10 💡 v6-Variante: WARP→Gelis öffentl. v6-FB als CGNAT-freie Fernwartung

- Gelis CGNAT ist nur v4 → ihre FB über natives v6 erreichbar (Port offen).
  WARP (schon im Einsatz) liefert Christoph outbound-v6 trotz Liwest-v4-only.
- PoC = ad-hoc Fernwartung; Daueform = direktes WG ap1↔Geli-FB über echtes
  v6 (HE-6in4, da Liwest auch mit Fiber kein v6) statt Hub-Spoke-Gymnastik.
- Endgeräte (Note10, Cudy) bleiben v6-agnostisch: v6 nur äußerer Transport,
  LAN bleibt IPv4. Nicht für Telefonie.
- teilprojekte.md: TP10 von ⏸ PAUSIERT auf 🅿️ VERTAGT (Bridge-Cutover-Bündelung).

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

docs/teilprojekte.md

@@ -117,7 +117,14 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co
   **Empfehlung:** VRRP nur für **MAIN/INFRA**, sonst ap2 als **Kalt-Ersatz** + Backup. DHCP/DNS schon redundant (Split + 2 Resolver).
 - Abh.: TP4. (Research erledigt, s. TP-R + Config-Skizze im Report.)
 
-### TP10 — Multi-Site VPN ▸ ⏸ PAUSIERT (FM auf IPsec zurück), Klickanleitung steht (`docs/tp10-vpn-migration.md`)
+### TP10 — Multi-Site VPN ▸ 🅿️ VERTAGT — gebündelt mit Bridge-Cutover (`docs/tp10-vpn-migration.md`)
+- **🅿️ ENTSCHEIDUNG 2026-06-17:** TP10 **vertagt** und **mit dem permanenten FB-Bridge-Cutover gebündelt** (statt
+  Parallelbetrieb vorher). Begründung: VPN-auf-FB und FB-Bridge schließen sich aus (Bridge = Modem = keine VPN-
+  Terminierung) → die Migration MUSS am Bridge-Tag passieren, nicht davor. Macht man beides in einem Cutover, hat ap1
+  dann die echte Public-IP → **kein FB-Port-Forward-Umweg nötig** (Spokes zeigen direkt auf ap1/DDNS). **FM-PoC ✅**
+  hat den WG-Spoke-Fix bewiesen → Migration de-risked. **Park-Zustand ap1:** Peers `disabled`, WG-Routen entfernt
+  (FM/DW laufen wieder über die FB), `wg-hub` bleibt (Key erhalten), Firewall-Regeln bleiben (TP5-Vorarbeit).
+  Beide VPN **vorerst über die FB** (`10.40.41.254`): FM = IPsec, DW = FB-WG.
 - **✅ Phase A (2026-06-16):** ap1-WG-**Hub** `wg-hub` live (UDP **51821**, MTU 1412, keine IF-IP). 2 Peers
   vorkonfiguriert: **FM** `10.101.0.0/24` (war IPsec) = `peer1` · **DW/Geli** `192.168.178.0/24` CGNAT (war WG) = `peer2`.
   Routen + Firewall (input/forward) gesetzt; NAT braucht nichts (Egress wg-hub ≠ masq-Interface). Hub-Pub
@@ -130,9 +137,11 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co
   Transfernetz** → FB-WG-Interface-`Address` muss die **FB-LAN-IP** sein (FM `10.101.0.254/24`, DW `192.168.178.1/24`),
   Transfernetz streichen, AllowedIPs `10.40.0.0/16`. **→ Ansatz machbar.** Configs `routeros/.secrets/wg-{fm,dw}.conf`
   korrigiert. FM aktuell auf **IPsec** (Sicherheitsnetz); ap1-WG-Hub bleibt (inert).
-- **⏳ Resume:** Klickanleitung `routeros/fritzbox-wg-lanlan-klickanleitung.md` — FB-WG als **LAN-LAN mit FB-LAN-IP als
-  Interface-Adresse** neu anlegen, Echt-Host-Test gegen `10.101.0.10`, IPsec erst nach grünem Verify abschalten.
-  **Port 51821** hält FB-51820-WG (DW) intakt.
+- **⏳ Resume = Bridge-Tag (ein Cutover):** Liwest-Anruf → FB wird Modem, ap1 = Edge mit Public-IP. Dann WG-Hub auf
+  ap1-Endpoint (DDNS) aktivieren, Spokes neu anlegen via Klickanleitung `routeros/fritzbox-wg-lanlan-klickanleitung.md`
+  (**FB-LAN-IP als Interface-Adresse!**), Echt-Host-Test gegen `10.101.0.10`. **DW:** kein Parallelbetrieb möglich
+  (Geli-FB lehnt 2 WG zum selben Zielnetz ab) → direkter Swap via temporärem Admin-Tunnel (anderes Zielnetz, da
+  CGNAT-Fernzugang/MyFRITZ fehlt). Spoke-Keys/-Configs bleiben in `routeros/.secrets/wg-{fm,dw}.conf`.
 - **Empfehlung:** **Hybrid** — **WireGuard Site-to-Site-Backbone** (BF/hAP = WG-**Hub**, FM/DW = FritzBox-**Spokes**, hub&spoke, **KEINE Zusatz-HW**) **+ WARP für Remote-User** (ergänzt, ersetzt nicht).
 - **WARP kann FBs NICHT direkt** ansprechen → bräuchte Connector-Host hinter der FB (an reinen-FB-Standorten FM/DW unattraktiv).
 - **Vorab-Check (User, entscheidend):** WAN je Standort — **public/dynamisch (OK: DynDNS/MyFRITZ) vs. CGNAT/DS-Lite am BF-Hub (= K.O. → dann CF/WARP-Pfad, CGNAT-immun)**.