From a36c1609031f6d049df6822e40296d30db73d957 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Wed, 17 Jun 2026 18:23:27 +0200 Subject: [PATCH] =?UTF-8?q?TP10=20=F0=9F=92=A1=20v6-Variante:=20WARP?= =?UTF-8?q?=E2=86=92Gelis=20=C3=B6ffentl.=20v6-FB=20als=20CGNAT-freie=20Fe?= =?UTF-8?q?rnwartung?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 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 --- docs/teilprojekte.md | 17 +++++++++++++---- docs/tp10-vpn-migration.md | 31 +++++++++++++++++++++++-------- 2 files changed, 36 insertions(+), 12 deletions(-) diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 103efce..036023c 100644 --- a/docs/teilprojekte.md +++ b/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)**. diff --git a/docs/tp10-vpn-migration.md b/docs/tp10-vpn-migration.md index 0e11657..f693c69 100644 --- a/docs/tp10-vpn-migration.md +++ b/docs/tp10-vpn-migration.md @@ -4,14 +4,29 @@ > gated: permanenter FB-Bridge-Mode (AP4.1) hängt an diesem TP. > **Reihenfolge fix: VPNs migrieren → Liwest-Anruf (Bridge) → FB wird Modem.** -> ## ⏸ STATUS 2026-06-16: PAUSIERT — FM auf IPsec, ROOT CAUSE gefunden (Ansatz machbar) -> Phase-A-Hub auf ap1 steht (s.u.). **Phase-B FM gescheitert → revertiert; Ursache jetzt klar:** -> Echt-Host-Test (Ping realer `10.101.0.10`) → Antwort aus `10.255.255.2` ⇒ **FB masqueradet den Tunnel.** -> **Grund:** `.conf` hatte eine **Transfernetz-Adresse** (`10.255.255.2/32`) → FRITZ!OS = Einzelgerät-Modus = NAT. -> **AVM nutzt Proxy-ARP statt 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`. -> Configs `routeros/.secrets/wg-{fm,dw}.conf` korrigiert. FM auf **IPsec** (Sicherheitsnetz), ap1-Hub inert. -> **Wiederaufnahme:** `routeros/fritzbox-wg-lanlan-klickanleitung.md` (FB-LAN-LAN mit LAN-IP, Verify gegen `10.101.0.10`). +> ## 🅿️ 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`). + +## 💡 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. ## Zielbild - **ap1 (hAP ax², 7.23.1) = WireGuard-Hub** (nativ). FM & DW = FritzBox-Spokes (hub-&-spoke, keine Zusatz-HW).