From 1f8e6b06c212e1d028c8b6ceb73ec9e765748c09 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Sat, 27 Jun 2026 16:44:15 +0200 Subject: [PATCH] =?UTF-8?q?TP10=20=E2=9C=85=20Kern=20durch:=20beide=20WG?= =?UTF-8?q?=20live=20auf=20ap1-Hub,=20FB-Bridge=20entblockt?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit DW/Geli on-site abgeschlossen (2026-06-27): Geli auf 10.95.10.0/24 renumbert, FB-WG single 10.95.10.1/24, alter FB↔FB-WG geswappt. End-to-End verifiziert (macmini/Linz → Gelis 24/7-APs .246/.247, echte LAN-IPs, kein 10.255.255.x-NAT-Leak). FM+DW live im Double-NAT. Doku/Status von "🅿️ vertagt/geparkt" auf Ist-Stand gezogen, Bridge-Gate an allen Stellen aufgelöst, stale 192.168.178-Referenzen bereinigt. Co-Authored-By: Claude Opus 4.8 --- CLAUDE.md | 2 +- docs/teilprojekte.md | 30 +++++++++++++++++------------- docs/tp10-context-digest.md | 8 ++++---- docs/tp10-vpn-migration.md | 26 +++++++++++++++++++------- 4 files changed, 41 insertions(+), 25 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index e5a8f18..b09b4f4 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -65,5 +65,5 @@ GW je VLAN = `.1` · APs: ap1=`.1`, ap2=`.2` · Switches: ALLNET=`.11`, Omada=`. - mgmt-VLAN-Wechsel am Switch = Lockout-Risiko: VLAN muss existieren + Port muss es tragen, in einem Schritt. - **Omada ES208G = Easy Managed** → Controller-adoptierbar (ab 6.1.x), nur Basis-VLAN/QoS im Controller (kein ACL/Policy-Routing). - **TP4 ✅: ap1 ist L3-Router.** Bridge mit vlan-filtering=yes; VLAN1 untagged (Mgmt/Transition); vlan10-99 Subinterfaces mit DHCP+DNS. NAT masquerade out=bridge → FB (Double-NAT bis FB-Bridge-Mode). DNS: 13 statische A-Records bf.lan, **Upstream seit 2026-06-16 = DoH Cloudflare Gateway** (servers=1.1.1.1 Bootstrap). Omada-PVID-Fix (→ .10/.20-Subnetze) ist nächster Schritt. -- **AP4.1 FB-Bridge = nur TEST/reversibel.** Public-IP `86.56.201.104` per ether1 bewiesen (kein Liwest-MAC-Lock, FB CM-MAC `0C:72:74:36:90:99`). Offline-Testmechanismus live auf ap1: `routeros/wan-cutover-{test,macclone-test}.rsc` + `wan-cutover-runbook.md`, Scripts `wantest-probe/-run`, `wanmac-clone/-revert`, Disk-Log `wan-test.0.txt`. **Console-Pfad während Cutover = FritzBox-WiFi → 10.40.41.1** (via ether2, unabhängig von ether1/LAN4). **⚠️ Permanenter Bridge-Mode gegated auf TP10** (FB hält 2 VPN-Tunnel: 1× IPsec + 1× WG → Ziel 2× WG/ap1) + Telefon. +- **AP4.1 FB-Bridge = nur TEST/reversibel.** Public-IP `86.56.201.104` per ether1 bewiesen (kein Liwest-MAC-Lock, FB CM-MAC `0C:72:74:36:90:99`). Offline-Testmechanismus live auf ap1: `routeros/wan-cutover-{test,macclone-test}.rsc` + `wan-cutover-runbook.md`, Scripts `wantest-probe/-run`, `wanmac-clone/-revert`, Disk-Log `wan-test.0.txt`. **Console-Pfad während Cutover = FritzBox-WiFi → 10.40.41.1** (via ether2, unabhängig von ether1/LAN4). **✅ Bridge-Gate aufgelöst (2026-06-27):** TP10-Kern durch — beide VPN von der FB auf ap1-WG migriert (FM+DW live auf `wg-hub`, Double-NAT). FB terminiert keine Tunnel mehr → **permanenter Bridge-Mode entblockt**; offen = WAN-Input-Seal (Block C `routeros/tp10-cutover-apply.rsc`) + **Liwest-Anruf**. Telefon bleibt an der FB. - **ap1 RouterOS-Scripting (device-mode=home):** **scheduler + fetch blockiert** (`not allowed by device-mode`) → keine Scheduler in Scripts, Autonomie via Loop-Script. **`[/ping]` gibt nil in 7.23**, ICMP geblockt → Reachability via `:resolve` (server=1.1.1.1 = Routing-Test, ohne server = DoH). MikroMCP-Tools können droppen → Fallback REST `http://10.40.41.1/rest` (Creds = ROUTER_AP1 in `~/.claude.json`). diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 23d6c21..08a1e64 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -21,7 +21,7 @@ IP-Blöcke: `.1–10` Router/APs (ap1=.1, ap2=.2) · `.11–20` Switches (ALLNET ALLNET-Core `.11` (FW2.2.1, VLANs 10/20/30/40/50/90/99/100; GE1/GE2/GE8 Trunk; **TP1 ✅ 2026-06-15**). Omada-Switch `.12` (adopted, **TP2 ✅ 2026-06-15**; Trunk-ALL auf P1+P2, Access-Profile auf P3-P8; Profile noch PVID=1 bis Omada-PVID-Fix). Omada-Controller **`.175`** (DS923/macvlan, mbentley 6.2, 🟢 live). omada-mcp **`.176`** (pve-LXC, StreamableHTTP, 🟢 live, 84 read-Tools; Controller-API v2 intern via christoph@emsenhuber.com). 2× hAP ax² (7.23.1): ap1 `.1` (ALLNET P1) — **TP4 ✅ 2026-06-15: L3-Router aktiv** (VLAN-Subinterfaces, DHCP, DNS, NAT). ap2 `.2` (Omada P2 — Trunk). FB6660 = Double-NAT-Upstream bis FB-Bridge-Mode. -**AP4.1 (FB-Bridge, 2026-06-16):** Public-IP `86.56.201.104` per ether1 bewiesen (kein Liwest-MAC-Lock). Offline-Testmechanismus live auf ap1 (`routeros/wan-cutover-*.rsc` + Runbook; scheduler-frei, Disk-Log `wan-test.0.txt`). ⚠️ **FB-Bridge bleibt vorerst nur TEST (reversibel)** — die FB hält 2 produktive VPN-Tunnel (AVM LAN-LAN: 1× IPsec + 1× WG) → **permanenter Bridge-Mode gegated auf TP10** (VPN-Migration auf 2× WG/ap1). +**AP4.1 (FB-Bridge, 2026-06-16):** Public-IP `86.56.201.104` per ether1 bewiesen (kein Liwest-MAC-Lock). Offline-Testmechanismus live auf ap1 (`routeros/wan-cutover-*.rsc` + Runbook; scheduler-frei, Disk-Log `wan-test.0.txt`). ✅ **Bridge-Gate aufgelöst (2026-06-27):** TP10-Kern durch (beide VPN von der FB auf ap1-WG migriert) → die FB terminiert keine Tunnel mehr → **permanenter Bridge-Mode ist jetzt entblockt** (offen = WAN-Seal + Liwest-Anruf). Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Controller + omada-mcp 🟢. **Nächster Schritt: Omada-PVID-Fix** (MAIN→PVID10, INFRA→PVID20, untagNetworkIds bereinigen) + IP-Migration Geräte. > ⚠️ **HW-Constraint hAP ax²:** 1 GB RAM, aber nur **128 MB Flash + KEIN USB** → **Container auf dem Router NICHT praktikabel**. @@ -99,7 +99,7 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co - ⚠️ Auto-Suffix `.lan` (RouterOS-Einschränkung, kann nicht auf leer gesetzt werden) — TP5-Cleanup. - ✅ **NAT:** srcnat masquerade out-interface=bridge (ap1 → FB → Internet, Double-NAT Interim-Lösung). - ✅ **Routing-Tabelle:** 0.0.0.0/0 via 10.40.41.254%bridge; alle 7 VLAN-Subnetze als Connected-Routes aktiv. -- ⏳ **FB-Bridge-Mode (AP4.1)** — ether1 als WAN ist vorkonfiguriert (DHCP-Client, NAT out=ether1, Fallback-Route bridge distance=2). **Test 2026-06-16:** Public-IP `86.56.201.104` per ether1 bewiesen (kein Liwest-MAC-Lock). Offline-Testmechanismus live (`routeros/wan-cutover-test.rsc`/`-macclone-test.rsc` + `wan-cutover-runbook.md`; scheduler-frei wg. device-mode, Disk-Log `wan-test.0.txt`). User-Befund „nach Gateway .1 ging nichts mehr" → Root-Cause offen (Hypothese DoH-Bootstrap). ⚠️ **Bridge bleibt nur TEST/reversibel; permanenter Umstieg gegated auf TP10** (FB hält bis dahin 2 VPN-Tunnel + Telefon). Bis dahin: Double-NAT via bridge (funktioniert). +- ⏳ **FB-Bridge-Mode (AP4.1) — jetzt entblockt (TP10-Kern durch 2026-06-27)** — ether1 als WAN ist vorkonfiguriert (DHCP-Client, NAT out=ether1, Fallback-Route bridge distance=2). **Test 2026-06-16:** Public-IP `86.56.201.104` per ether1 bewiesen (kein Liwest-MAC-Lock). Offline-Testmechanismus live (`routeros/wan-cutover-test.rsc`/`-macclone-test.rsc` + `wan-cutover-runbook.md`; scheduler-frei wg. device-mode, Disk-Log `wan-test.0.txt`). User-Befund „nach Gateway .1 ging nichts mehr" → Root-Cause offen (Hypothese DoH-Bootstrap). ✅ **VPN-Gate weg** (beide Tunnel auf ap1-WG migriert); offen = WAN-Input-Seal (Block C aus `tp10-cutover-apply.rsc`) + **Liwest-Anruf** → ether1 = Public Edge, Double-NAT weg. Telefon bleibt an der FB. Bis dahin: Double-NAT via bridge (funktioniert). - **DNS-Entscheidung** (Technitium **und** externer BIND verworfen): RouterOS-DNS als Resolver, keine DHCP→DNS-Auto-Registrierung (soweit möglich). Infra-Hosts als statische `/ip dns static`-Einträge unter `bf.lan`; dynamische Clients bewusst ohne Namen. Filtering/DNSSEC via DoH-Upstream (TP3). HA: 2. Resolver auf ap2, statische Einträge beidseitig pflegen. - Abh.: TP1 ✅. TP3-Abhängigkeit entfällt (WLAN läuft weiterhin über FB bis TP3). - **Ermöglicht jetzt:** PVID-Fix in Omada-Profilen (MAIN→PVID10, INFRA→PVID20), untagNetworkIds-Bereinigung, DHCP-Reservierungen für NAS/macmini/pve auf neue VLAN-Subnetze migrieren. @@ -136,18 +136,21 @@ 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 ▸ 🅿️ VERTAGT — gebündelt mit Bridge-Cutover (`docs/tp10-vpn-migration.md`) +### TP10 — Multi-Site VPN ▸ ✅ KERN DURCH (2026-06-27) — beide WG live auf ap1-Hub (`docs/tp10-vpn-migration.md`) > **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**. +- **✅ KERN DURCH (2026-06-27):** beide AVM-Tunnel → **2× WireGuard mit Hub auf ap1** migriert. Live: `peer fm` + (`10.101.0.0/24`, bidirektional, myfritz-Endpoint) **und** `peer dw` (`10.95.10.0/24`, CGNAT-Dial-in) mit frischem + Handshake + Traffic. Noch im **Double-NAT** über die BF-FB-Portfreigabe (51821 → ap1). FM-IPsec gekillt, Gelis + alter FB↔FB-WG sauber geswappt. **→ entblockt den permanenten FB-Bridge-Mode.** +- **✅ DW/Geli on-site verifiziert (2026-06-27):** Geli auf `10.95.10.0/24` renumbert, FB-WG single `10.95.10.1/24`, + Keepalive 25, Endpoint `bf4…:51821`. End-to-End von macmini/Linz → Gelis 24/7-APs `10.95.10.246/.247` sauber + (echte LAN-IPs, **kein `10.255.255.x`**-NAT-Leak). - **💡 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. + muss die **FB-LAN-IP** sein (AVM Proxy-ARP). War der Schlüssel zum sauberen LAN-LAN. +- **Hub:** `wg-hub` (UDP 51821, Key `P/bzt…`, MTU 1412, keine IF-IP). Endpoint = DDNS **`bf4.emsenhuber.net:51821`** + (Cloudflare, DNS-only → 86.56.201.104, überlebt Bridge). Apply gebündelt in `routeros/tp10-cutover-apply.rsc`. +- **Offen (entblockt):** permanenter FB-Bridge-Cutover (WAN-Seal Block C + **Liwest-Anruf** → ether1 = Public Edge, + Double-NAT weg); BF-FB-eigenen WG-Server 51820 abräumen; DDNS-Auto-Updater für `bf4` auf NAS/pve. ### 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`. @@ -175,4 +178,5 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co 4. **Dann:** TP5 (Firewall/Deny-by-default) → TP6 (QoS/CAKE). ~~TP7 (mDNS)~~ ✅ 2026-06-17, ~~TP3 (WLAN/CAPsMAN)~~ ✅ 2026-06-18. ⚠️ TP5 muss die TP7-Firewall-Holes mitnehmen (s. TP7: MAIN↔MEDIA-forward + UDP 5353 input). ⏳ Sonos-WLAN-Migration (7 Geräte FB-WLAN→VLAN40) als Anschluss an TP3/TP7 (User-seitig, schließt den Household). -5. **Nachgelagert/Research-getrieben:** TP8 (Access), TP9 (HA), TP10 (VPN), TP11 (Monitoring), TP12 (IPv6), TP13 (Spaß). +5. **TP10 (VPN) ✅ Kern durch (2026-06-27)** — Rest = FB-Bridge-Cutover (WAN-Seal + Liwest-Anruf), entblockt. +6. **Nachgelagert/Research-getrieben:** TP8 (Access), TP9 (HA), TP11 (Monitoring), TP12 (IPv6), TP13 (Spaß). diff --git a/docs/tp10-context-digest.md b/docs/tp10-context-digest.md index a582994..a09f772 100644 --- a/docs/tp10-context-digest.md +++ b/docs/tp10-context-digest.md @@ -3,8 +3,8 @@ > 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 **= FB-WG**, IPsec längst gekillt; 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**. +- **TP10 ✅ KERN DURCH (2026-06-27):** beide AVM-Tunnel → **2× WireGuard mit Hub auf ap1** migriert (FM `10.101.0.0/24` bidirektional; DW/Geli `10.95.10.0/24` CGNAT-Dial-in), live mit Handshake + Traffic, noch im Double-NAT über die BF-FB-Portfreigabe (51821 → ap1). FM-IPsec gekillt, Gelis alter FB↔FB-WG geswappt. **→ FB-Bridge entblockt** (FB terminiert keine Tunnel mehr). Rest = WAN-Seal + Liwest-Anruf. +- **DW/Geli on-site verifiziert (2026-06-27):** Geli auf `10.95.10.0/24`, FB-WG single `10.95.10.1/24`, Keepalive 25, Endpoint `bf4…:51821`. macmini/Linz → Gelis 24/7-APs `10.95.10.246/.247` sauber (echte LAN-IPs, kein `10.255.255.x`). - **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=` @@ -12,7 +12,7 @@ - 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 **auf `10.95.10.0/24` renumbered**. FB-WG-`Address` = **`10.95.10.1/24` (SINGLE)**. ⚠️ Dual-Address war Fehler (FRITZ!OS macht 10.95.10.1 primär, koppelt LAN nicht → BF→Host ging nicht). Keepalive 25. ap1 `peer dw` allowed-address = `10.95.10.0/24`. -- **Zustand:** ap1-Hub geparkt (Peers disabled, WG-Routen entfernt, Firewall bleibt). DW-Config bei Geli vor Ort gestaged 2026-06-17. -- **Gestaged (`routeros/tp10-cutover-apply.rsc`, am Bridge-Tag anwenden):** `peer1`/FM enable, allowed-address `10.101.0.0/24`, **Endpoint `abxhutfgsid9snmy.myfritz.net:52476`** (bidirektional, FM kein CGNAT). `peer2`/DW enable, allowed-address **`192.168.178.0/24,10.95.10.0/24`** (Key `FqYZLztQ…PbzUw=` oder Gelis FB-eigener Key), Endpoint leer (CGNAT-Dial-in). Routen `10.101.0.0/24` + `192.168.178.0/24` + `10.95.10.0/24` → wg-hub. Plus Input-WAN-Seal + ether1 `use-peer-dns=no`. +- **Zustand:** ap1-Hub **scharf** — beide Peers enabled + live, Routen `10.101.0.0/24` + `10.95.10.0/24` → wg-hub aktiv, keine `192.168.178`-Reste. +- **Apply-Skript (`routeros/tp10-cutover-apply.rsc`, idempotent, bereits angewandt für A+B):** `peer1`/FM allowed-address `10.101.0.0/24`, **Endpoint `abxhutfgsid9snmy.myfritz.net:52476`** (bidirektional, FM kein CGNAT). `peer2`/DW allowed-address **`10.95.10.0/24` (single)**, Key `FqYZLztQ…PbzUw=`, Endpoint leer (CGNAT-Dial-in). **Block C (Input-WAN-Seal) + ether1 `use-peer-dns=no` = erst am Bridge-Tag.** - **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. diff --git a/docs/tp10-vpn-migration.md b/docs/tp10-vpn-migration.md index a310a6b..f58ef5d 100644 --- a/docs/tp10-vpn-migration.md +++ b/docs/tp10-vpn-migration.md @@ -3,6 +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-27: KERN DURCH — beide WG live auf ap1-Hub, Bridge entblockt +**TP10-Kern erreicht:** beide AVM-Tunnel auf **2× WireGuard mit Hub auf ap1** migriert, noch im Double-NAT über die +BF-FB-Portfreigabe (51821 → ap1). Live verifiziert: `peer fm` (`10.101.0.0/24`, bidirektional) **und** `peer dw` +(`10.95.10.0/24`, CGNAT-Dial-in) mit frischem Handshake + Traffic; **keine Stale-Route** mehr (`192.168.178` raus). +- **DW/Geli on-site abgeschlossen (2026-06-27):** Geli auf `10.95.10.0/24` renumbert, FB-WG **single `10.95.10.1/24`**, + Keepalive 25, Endpoint `bf4…:51821`; alter Geli↔BF-FB-WG sauber geswappt (nur noch der neue Tunnel in Gelis VPN-Liste). + **End-to-End verifiziert:** macmini/Linz → Gelis 24/7-APs **`10.95.10.246/.247`** (fixe IP) sauber erreichbar, + echte LAN-IPs, **kein `10.255.255.x`**-NAT-Leak. FM-IPsec gekillt. +- **→ FB-Bridge entblockt:** die FB terminiert keine Tunnel mehr. **Rest:** WAN-Input-Seal (Block C aus + `routeros/tp10-cutover-apply.rsc`) + **Liwest-Anruf** → ether1 = Public Edge, Double-NAT weg; danach BF-FB-eigenen + WG-Server 51820 abräumen; DDNS-Auto-Updater für `bf4` auf NAS/pve. + ## 🟢 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), @@ -16,8 +28,8 @@ Modus: **stagen → am Bridge-Tag 1× Apply + ether1 umstecken** (Runbook unten) - **Behobene Fehler dieser Session:** (1) beide ap1-Peers trugen fälschlich ap1s **eigenen** Public-Key `P/bzt…` → auf die FB-Keys (`dzRY…`/`FqYZ…`) korrigiert. (2) **`bf4` war stale** (falsche IP) → gefixt, danach DW-Dial-in ok. (3) **DW-Dual-Address** brach die LAN-Kopplung → ap1+Config auf **Single `10.95.10.0/24`** vereinheitlicht. -- **Offen:** Geli renumbert ihr LAN auf `10.95.10.0/24` + WG-`Address`=`10.95.10.1/24` (single) → dann BF↔Geli-Hosts - end-to-end. Danach Bridge-Cutover (löst Inbound-Forward-Abhängigkeit ganz auf). +- **✅ Erledigt (2026-06-27):** Geli auf `10.95.10.0/24` renumbert, WG-`Address`=`10.95.10.1/24` (single) → BF↔Geli-Hosts + end-to-end verifiziert (s. Status-Block oben). Nächster Schritt = Bridge-Cutover (löst Inbound-Forward-Abhängigkeit ganz auf). ## 🅿️ 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** @@ -50,9 +62,9 @@ echte LAN-IPs, LAN-LAN sauber. (Gleiche Ursache wie der alte „NetBIOS routet n ## ✅ 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`. +- **peer2 (DW)** allowed-address `10.95.10.0/24` (single — Gelis FB sourct daraus; Dual-Address war ein Fehler), enable. + Key `FqYZLztQ…PbzUw=`. **✅ live + verifiziert.** +- Routen `10.101.0.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). @@ -65,8 +77,8 @@ Hinweis: **NAT, Forward-FW (wg-hub), Default-Fallback-Route, masquerade-ether1 s - **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). +- **Fernzugang zu Gelis FB**: MyFRITZ-v4 tot (CGNAT). Tunnel steht (2026-06-27) → FB unter **`10.95.10.1`** über den + Tunnel erreichbar (nach Renumber; Endpoint proaktiv pflegen, solange Tunnel läuft). ## 💡 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),