Files

Christoph Emsenhuber 963e3c5f9a TP10 🔐 Cutover-Ready: ap1-Apply-Skript + WAN-Input-Seal + FB-Klickanleitungen

ap1-Seite gestaged in routeros/tp10-cutover-apply.rsc (idempotent, am Bridge-Tag
anwenden): WG-Peers säubern (Transfernetz-/32 raus) + enable, peer1/FM bidirektional
(Endpoint abxhutfgsid9snmy.myfritz.net:52476, kein CGNAT), peer2/DW Dial-in; Spoke-
Routen → wg-hub; Input-Chain WAN-Seal (schließt Mgmt-Dienste + offenen Resolver,
sobald ether1 die Public-IP hält); ether1 use-peer-dns=no.

FB-Seite (kein MCP → Klickanleitung): neue fritzbox-bf-bridge-cutover-klickanleitung.md
(Passthrough + alte FM/DW-WG-Teardown + Rollback); fritzbox-wg-lanlan-klickanleitung.md
mit Schnellpfad (FM nur Peer-Endpoint auf bf4 umbiegen) + IPsec-Korrektur.

Doku: tp10-vpn-migration.md Status → CUTOVER-READY, Live-Stand verifiziert; FM=FB-WG
(IPsec längst gekillt) korrigiert. wan-cutover-runbook.md als permanenter Cutover markiert.

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

2026-06-25 12:07:46 +02:00

2.5 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 heute 192.168.178.0/24 GW .1, künftig 10.95.10.0/24. FB-WG-Address = 192.168.178.1/24, 10.95.10.1/24 (dual, renumber-fest). Keepalive 25.
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.5 KiB Raw Blame History Unescape Escape

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

2.5 KiB

Raw Blame History