TP10 ✅ Kern durch: beide WG live auf ap1-Hub, FB-Bridge entblockt

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 <noreply@anthropic.com>
2026-06-27 16:44:15 +02:00
parent 48754f446d
commit 1f8e6b06c2
4 changed files with 41 additions and 25 deletions
--- 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ß).
--- 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.
--- 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),