Files
bf-infra/docs/tp10-context-digest.md

19 lines
2.8 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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.