TP10 Doku konsolidiert: kanonischer Runbook + kompakter Kontext-Digest

- tp10-vpn-migration.md zur Single Source of Truth umgeschrieben: widerspruechliche alte Transfernetz-Tabelle/MyFRITZ-Endpoint entfernt, aktueller Stand (Proxy-ARP LAN-IP, DDNS bf4.emsenhuber.net, dual-range DW, geparkter ap1-Hub, vertagt+ gebuendelt mit Bridge-Cutover, v6-Variante) konsolidiert. - teilprojekte.md TP10-Eintrag von verbose Saga auf kompakten Status + Verweis gekuerzt. - tp10-context-digest.md neu: ultrakompakter Handoff (lokal via Ollama nemotron-3-nano:4b destilliert, fakten-gegengeprueft) fuer kleines Kontextfenster. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-24 14:08:01 +02:00
parent 03f328f043
commit dd4c6ad77c
3 changed files with 85 additions and 110 deletions
--- a/docs/teilprojekte.md
+++ b/docs/teilprojekte.md
@@ -137,37 +137,17 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co
 - Abh.: TP4. (Research erledigt, s. TP-R + Config-Skizze im Report.)

 ### 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
-  `P/bztIk13cAmLHbN6oHGGnWAKLZsqR5TXAbFP+NGGBk=`, Endpoint `xvbeo64jqlqd9gfo.myfritz.net:51821`.
-  Spoke-Configs in `routeros/.secrets/wg-{fm,dw}.conf` (Private-Keys, nicht im Git). FB-Portfreigabe 51821→ap1 gesetzt.
- **⛔→💡 Phase-B-Versuch FM gescheitert, ROOT CAUSE gefunden (2026-06-16):** `.conf` importiert, IPsec voreilig
-  aus → FM weg, revertiert. **Echt-Host-Test (WG reaktiviert):** Ping realer Host `10.101.0.10` → Antwort aus
-  `10.255.255.2` → **FB-NAT bestätigt.** **Ursache:** unsere `.conf` nutzte eine **Transfernetz-Adresse**
-  (`10.255.255.2/32`) → FRITZ!OS behandelt das als Einzelgerät → masqueradet. **AVM nutzt Proxy-ARP, KEIN
-  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 = 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)**.
- WG-Gotchas: keine IP aufs WG-IF (MikroTik), AllowedIPs=Tunnel+LAN-CIDRs, MTU 1412, Keepalive 25. ap1 hat noch KEIN WG (Neuaufbau).
- **IST-Zustand (User 2026-06-16):** Die BF-FritzBox terminiert AKTUELL **2 produktive Site-to-Site-Tunnel** (AVM LAN-LAN: **1× IPsec + 1× WireGuard**). Migrationsziel: **2× WireGuard** mit Hub auf ap1, FB-Standorte als Spokes.
- ⚠️ **TP10 ist Voraussetzung für den permanenten FB-Bridge-Mode (AP4.1/TP4).** Solange die FB die 2 Tunnel terminiert, muss sie Router bleiben → FB-Bridge nur reversibel testbar, nicht dauerhaft.
- Abh.: WAN-Check; Hub sinnvoll nach TP4 (Router-Cutover). **Blockiert:** permanenten FB-Bridge-Mode.
+> **Details/Cutover/Gotchas/Eckdaten → `docs/tp10-vpn-migration.md` (Single Source of Truth).** Research: `docs/research/vpn-comparison.md`.
+- **🅿️ VERTAGT, gebündelt mit Bridge-Cutover (2026-06-17):** VPN-auf-FB ⊕ FB-Bridge schließen sich aus → Migration am
+  Bridge-Tag (dann ap1 = Edge mit Public-IP, **kein Port-Forward-Umweg**). Beide VPN vorerst über die FB: **FM=IPsec, DW=FB-WG**.
+- **💡 Root Cause (FM-PoC bewiesen):** FB masqueradet WG, wenn die Interface-`Address` eine **Transfernetz-IP** ist →
+  muss die **FB-LAN-IP** sein (AVM Proxy-ARP). Damit ist der WG-Spoke-Ansatz machbar.
+- **Stand:** Hub `wg-hub` (UDP 51821, Key `P/bzt…`, MTU 1412) auf ap1 **geparkt** (Peers disabled, Routen entfernt,
+  Firewall = TP5-Vorarbeit bleibt). Endpoint = DDNS **`bf4.emsenhuber.net:51821`** (Cloudflare, DNS-only → 86.56.201.104).
+  **DW-Config bei Geli vor Ort gestaged** (2026-06-17; dual-range `192.168.178.0/24` + künftig `10.95.10.0/24`).
+  v6-direkt-Variante (Gelis natives v6) als spätere Option vermerkt.
+- **Offen:** ap1-Seite aktivieren (peer2 + Routen für beide DW-Ranges), sobald BF erreichbar.
+- ⚠️ **Blockiert** den permanenten FB-Bridge-Mode (AP4.1/TP4) bis zur Migration.

 ### TP11 — Monitoring & Mgmt-Control-Plane ▸ research-gated
 - MikroMCP + omada-mcp + **SNMP/icinga-mikrotik**, RoMON, NTP, **E-Mail-Alerts**, Netwatch. → Teil von `docs/research/routeros-capabilities.md`.
--- a/docs/tp10-context-digest.md
+++ b/docs/tp10-context-digest.md
@@ -0,0 +1,18 @@
+# TP10 — Kontext-Digest (kompakt, für kleines Kontextfenster)
+
+> 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.
+- **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:**
+  - Hub `wg-hub` ap1: UDP **51821**, MTU 1412, keine IF-IP, Public-Key `P/bztIk13cAmLHbN6oHGGnWAKLZsqR5TXAbFP+NGGBk=`
+  - Endpoint Spokes: **`bf4.emsenhuber.net:51821`** (Cloudflare DDNS, proxied=false → `86.56.201.104`). Nicht MyFRITZ (stirbt im Bridge).
+  - BF-AllowedIPs: **`10.40.0.0/16`**
+  - 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.
+- **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.
--- a/docs/tp10-vpn-migration.md
+++ b/docs/tp10-vpn-migration.md
@@ -1,91 +1,68 @@
-# TP10 — Multi-Site-VPN-Migration (2× AVM-S2S → 2× WireGuard, Hub auf ap1)
+# TP10 — Multi-Site-VPN (2× AVM-S2S → 2× WireGuard, Hub auf ap1)

-> Stand 2026-06-16 · Research: `docs/research/vpn-comparison.md` · Plan: `~/.claude/plans/pure-wibbling-graham.md`
-> gated: permanenter FB-Bridge-Mode (AP4.1) hängt an diesem TP.
-> **Reihenfolge fix: VPNs migrieren → Liwest-Anruf (Bridge) → FB wird Modem.**
+> **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-17: VERTAGT — gebündelt mit dem FB-Bridge-Cutover
-> **Entscheidung:** TP10 nicht mehr als Parallel-Migration vorab, sondern **zusammen mit dem permanenten Bridge-
-> Cutover** (VPN-auf-FB ⊕ FB-Bridge schließen sich aus). Am Bridge-Tag hat ap1 die echte Public-IP → **kein
-> FB-Port-Forward-Umweg** mehr; Spokes zeigen direkt auf ap1 (DDNS). **FM-PoC ✅** hat den Fix bewiesen (Root Cause:
-> FB masqueradet, wenn die WG-Interface-`Address` eine **Transfernetz-IP** statt der **FB-LAN-IP** ist — AVM Proxy-ARP).
-> **Park-Zustand ap1:** Peers `disabled`, WG-Routen entfernt (FM/DW wieder über die FB), `wg-hub` bleibt (Key erhalten),
-> Firewall bleibt (TP5-Vorarbeit). Beide VPN vorerst über die FB: **FM = IPsec, DW = FB-WG.**
-> **Resume:** `routeros/fritzbox-wg-lanlan-klickanleitung.md` (FB-LAN-IP als Interface-Adresse, Verify gegen `10.101.0.10`).
+## 🅿️ 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).
+- **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").

-## 💡 Variante DW/Geli — v6-direkt statt CGNAT-Spoke (Idee 2026-06-17, für später)
-Gelis CGNAT ist **nur v4**; ihre FritzBox hat **öffentliches natives v6** (`2a0e:7a02:31c:3000::/56`, rotiert ~30h →
-MyFRITZ-DDNS) → ihre FB ist **über v6 von außen erreichbar**. Der **v6-Inbound-Port auf Gelis FB ist bereits offen.**
- **Sofort/PoC (ad-hoc Fernwartung, da Geli kein Zero Trust hat):** Christophs **WARP** (schon im Einsatz) gibt ihm
-  outbound-v6 trotz Liwest-v4-only → `Christoph(WARP-v6) → CF-Edge → Gelis v6-FB`. CGNAT-immun, reversibel.
-  Nur Fernwartung — **nicht** für Telefonie (Calls = Messenger-Relays).
- **Daueform (sauberer):** echtes v6 auf BF-Seite via **HE-6in4** (Liwest gibt voraussichtlich **auch mit Fiber kein v6**)
-  → **direktes WireGuard ap1↔Geli-FB über v6**, kein Cloudflare im Datenpfad, kein Tunnel-in-Tunnel (WARP ist selbst WG),
-  **umgeht die ganze Hub-&-Spoke-CGNAT-Gymnastik** unten (Geli müsste nicht mehr outbound zum Hub initiieren — v6↔v6 ist
-  symmetrisch erreichbar). Siehe Memory `project-ipv6-state`.
- **Endgeräte bleiben v6-agnostisch:** v6 ist **nur der äußere Transport** zwischen FB-WAN und Christophs Endpunkt; im
-  Tunnel läuft Gelis LAN weiter **rein IPv4** (192.168.178.0/24). Ihre Geräte (Galaxy Note 10, Cudy-APs als Bridge, NAS …)
-  müssen **kein v6 können** — sie sehen nie ein v6-Paket. v6-Eigenfähigkeit eines Backend-Geräts wäre nur nötig, wollte man
-  es **direkt ohne Tunnel** über v6 erreichen (klobig: Freigabe pro Gerät + rotierendes Prefix) — macht man nicht.
+## Root Cause des FM-PoC (bewiesen) — der zentrale Lerneffekt
+FM-WG-Versuch schlug fehl: Ping auf realen FM-Host `10.101.0.10` kam aus `10.255.255.2` zurück ⇒ **die FB masqueradet
+den Tunnel.** **Ursache:** WG-Interface-`Address` war eine **Transfernetz-IP** → FRITZ!OS = Einzelgerät-Modus = NAT.
+**AVM nutzt Proxy-ARP statt Transfernetz** → die FB-WG-`Address` **muss die eigene LAN-IP sein**. Damit: kein NAT,
+echte LAN-IPs, LAN-LAN sauber. (Gleiche Ursache wie der alte „NetBIOS routet nicht"-Fehlschlag.)

-## Zielbild
- **ap1 (hAP ax², 7.23.1) = WireGuard-Hub** (nativ). FM & DW = FritzBox-Spokes (hub-&-spoke, keine Zusatz-HW).
- Ablösung der **2 produktiven AVM-LAN-LAN-Tunnel** auf der BF-FB → **2× WireGuard auf ap1**:
-  - **FM** `10.101.0.0/24` (GW .254) — war **IPsec**.
-  - **DW/Geli** `192.168.178.0/24` (GW .1, **CGNAT**, Antennengemeinschaft Geroldsgrün) — war **WireGuard**.
-
-## ✅ As-built auf ap1 (Phase A erledigt, 2026-06-16)
+## Eckdaten
 | Objekt | Wert |
 |---|---|
-| Interface `wg-hub` | Listen **UDP 51821**, MTU 1412, **keine IF-IP**, running |
-| Hub-Public-Key | `P/bztIk13cAmLHbN6oHGGnWAKLZsqR5TXAbFP+NGGBk=` |
-| Endpoint (für Spokes) | **`xvbeo64jqlqd9gfo.myfritz.net:51821`** (MyFRITZ-FQDN) |
-| Peer FM (`peer1`) | pub `dzRY0lnnUygijChWe5wXZmXPeNcbdALpqBptA3fyiVE=`, allowed `10.255.255.2/32,10.101.0.0/24`, Endpoint leer |
-| Peer DW (`peer2`) | pub `FqYZLztQ/qME5VDie5QLGH++5299WJiE1dPpQnPbzUw=`, allowed `10.255.255.3/32,192.168.178.0/24`, Endpoint leer |
-| Route | `10.101.0.0/24` → wg-hub · `192.168.178.0/24` → wg-hub (beide active) |
-| Firewall | input accept udp/51821 · forward accept in/out wg-hub (TP5-Vorarbeit) |
-| NAT | **keine Änderung nötig** — masquerade ist out-interface bridge/ether1; Tunnel-Egress = wg-hub → nie NATed |
+| 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!) |
+| 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) |

-**Port 51821 (statt 51820):** Die BF-FB hält ihren eigenen WG-Server auf 51820 für den **noch laufenden DW-Tunnel**.
-51821 für den Hub vermeidet die Kollision während der Parallelphase.
+**Spoke-Configs (Private-Keys, gitignored):** `routeros/.secrets/wg-fm.conf`, `routeros/.secrets/wg-dw.conf`.
+**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).

-**Spoke-Configs (Private-Keys, NICHT im Git):** `routeros/.secrets/wg-fm.conf`, `routeros/.secrets/wg-dw.conf`.
+## ⏳ 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.

-## ✅ Vorbedingung (User erledigt)
- **FB-Portfreigabe** UDP **51821** → `10.40.41.1` (ap1) gesetzt.
+## DW-Gotchas
+- **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).

-## Phase B — Cutover (pro Spoke, Parallelphase) — OFFEN
-> Pro Standort: neuen WG-Tunnel hochziehen, **verifizieren**, erst dann den alten AVM-Tunnel abschalten.
+## 💡 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),
+**v6-Inbound-Port offen** → von außen über v6 erreichbar.
+- **PoC/Fernwartung jetzt:** Christophs **WARP** gibt outbound-v6 (Liwest v4-only) → `Christoph(WARP-v6) → CF-Edge →
+  Gelis v6-FB`. CGNAT-immun, reversibel. Nur Fernwartung (Calls laufen eh über Messenger-Relays).
+- **Daueform:** echtes v6 auf BF via **HE-6in4** → **direktes WG ap1↔Geli-FB über v6**, kein CF im Datenpfad, **umgeht die
+  ganze Hub-&-Spoke-CGNAT-Gymnastik** (v6↔v6 symmetrisch erreichbar). Inner-Tunnel bleibt IPv4 (Gelis Geräte v6-agnostisch).

-### B1 — FM zuerst (alter IPsec-Tunnel bleibt parallel an)
-1. `routeros/.secrets/wg-fm.conf` in die **FM-FritzBox** importieren:
-   `Internet → Freigaben → VPN (WireGuard) → Verbindung hinzufügen → eigene Konfiguration importieren`.
-   - ⚠️ Falls FRITZ!OS keinen Import mit vorgegebenem Key erlaubt: FB-WG-Verbindung manuell anlegen, FB-**Public-Key**
-     ablesen und melden → wird in `peer1` auf ap1 eingetragen (`manage_wireguard_peer` set public-key).
-2. **Handshake prüfen:** `list_wireguard_peers` → `peer1` last-handshake aktuell, rx/tx > 0.
-3. **L3-Verify (NetBIOS-Lehre, s.u.):** Ping ap1 → ein Host in `10.101.0.0/24`; Gegenrichtung FM → BF-Host (NAS);
-   **SMB per IP (TCP 445)** testen, **nicht** Netzwerkumgebung/Broadcast.
-4. Grün → **IPsec-Tunnel** für FM auf der BF-FB deaktivieren → erneut prüfen.
+## Cutover-Sequenz (am Bridge-Tag, ein Rutsch)
+1. ap1-Seite live (peers/routes, s.o.), Spoke-Configs an FM+DW (FM-`.conf` neu mit LAN-IP-Address).
+2. Verify je Spoke (echte LAN-IP-Quelle, SMB/445 per IP).
+3. Alte AVM-Tunnel abbauen (FM-IPsec; DW-FB-WG/Server 51820).
+4. **Liwest-Anruf** → FB Bridge/Modem, ap1 = Edge mit Public-IP (DDNS zeigt weiter dorthin) → Portfreigabe entfällt.
+5. TP5-Firewall auf ap1 finalisieren (WG-Regeln behalten).
+6. Entblockt: NAS/Controller-IP-Migration (IP-Plan Phase 3), Double-NAT weg.
+**Follow-up:** DDNS-Auto-Updater für `bf4` auf NAS/pve (statt manuell bei IP-Wechsel).

-### B2 — DW/Geli danach (alter FB-WG-Tunnel auf 51820 bleibt parallel an)
-5. `routeros/.secrets/wg-dw.conf` in die **DW-FritzBox** importieren (CGNAT → wählt ausgehend, Keepalive 25).
-6. Handshake + L3-Verify (Ping/SMB per IP in `192.168.178.0/24` ↔ BF).
-7. Grün → alten **DW-WG-Server/Tunnel** auf der BF-FB abbauen.
-
-## NetBIOS / Namensauflösung (FM — bekannter Stolperstein)
-Früherer FM-WG-Versuch scheiterte an „NetBIOS nicht geroutet". NetBIOS-Namensauflösung läuft über **Broadcasts
-(UDP 137/138)**, die über einen *gerouteten* Tunnel grundsätzlich nicht traversieren — kein Routing-Bug.
-→ **L3 zuerst per IP beweisen** (Ping + SMB/445); Namensauflösung per **IP oder DNS** lösen (statische Einträge),
-nicht über Broadcast-Browsing. Unser Design führt beide Richtungen in AllowedIPs/Routes → unicast muss laufen.
-
-## Phase C — Abschluss (nach beidseitig grün, ≥1 Tag stabil)
-8. TP5-Firewall auf ap1 finalisieren (WG-Regeln behalten).
-9. **DDNS-Übergabe:** MyFRITZ läuft über die FB, entfällt evtl. im Bridge-Mode → ap1 braucht eigenes DDNS
-   (`/ip cloud` mynetname / DynDNS); Spoke-Endpoints dann auf ap1-FQDN umstellen.
-   ⚠️ Prüfen, ob `/ip cloud` trotz device-mode=home läuft (scheduler/fetch geblockt).
-10. **Liwest-Anruf** für FB-Bridge-Mode → FB wird Modem, ether1 = WAN, Portfreigabe entfällt.
-11. Entblockt: NAS/Controller-IP-Migration (IP-Plan Phase 3) + Wegfall Double-NAT.
-
-## Rückbau (falls nötig)
- ap1-Seite vollständig reversibel: Peers/Routen/Firewall via `manage_*` `action=remove`, `wg-hub` löschen.
- Alte AVM-Tunnel erst nach Verifikation abschalten → jederzeit reaktivierbar.
+## Reversibilität
+ap1-Seite vollständig per `manage_*`/`action=remove` rückbaubar. Alte AVM-Tunnel erst nach Verify abschalten →
+jederzeit reaktivierbar. FB-Bridge bis Liwest-Anruf reversibel (`routeros/wan-cutover-runbook.md`).