Initial import from bf-network-r6.opencode — opencode migration
This commit is contained in:
18
docs/tp10-context-digest.md
Normal file
18
docs/tp10-context-digest.md
Normal file
@@ -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 ✅ 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=`
|
||||
- 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 **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 **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.
|
||||
Reference in New Issue
Block a user