Files

Christoph Emsenhuber 48754f446d TP10 🔧 WG live: Key-Mixup + stale bf4 + DW-Dual-Address behoben, DW→10.95.10.0/24

Live-Debug-Session (Double-NAT): WG-Hub ist jetzt aktiv, FM+DW-Tunnel UP.
- Root Causes behoben: (1) beide ap1-Peers trugen faelschlich ap1s EIGENEN Public-Key
  P/bzt... statt der FB-Keys dzRY.../FqYZ... (2) bf4.emsenhuber.net war stale -> DW-Dial-in
  (CGNAT) lief erst danach. (3) DW-Dual-Address 192.168.178.1/24,10.95.10.1/24 -> FRITZ!OS
  macht 10.95.10.1 primaer u. koppelt das LAN nicht -> Single-Address-Regel.
- DW standardisiert auf 10.95.10.0/24 (Geli renumbert vor Cutoff): wg-dw.conf single,
  ap1 peer dw allowed-address=10.95.10.0/24, Route 10.95.10.0/24 -> wg-hub. Routing verifiziert (0% Loss).
- Klickanleitung: DW-Renumber + Single-Address-Lehre; Doku/Digest auf Live-Stand.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-25 21:00:07 +02:00

2.6 KiB

Raw Blame History

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 = 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.
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 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.
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.

2.6 KiB Raw Blame History Unescape Escape

TP10 — Kontext-Digest (kompakt, für kleines Kontextfenster)

2.6 KiB

Raw Blame History