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

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.