Files

Christoph Emsenhuber a36c160903 TP10 💡 v6-Variante: WARP→Gelis öffentl. v6-FB als CGNAT-freie Fernwartung

- Gelis CGNAT ist nur v4 → ihre FB über natives v6 erreichbar (Port offen).
  WARP (schon im Einsatz) liefert Christoph outbound-v6 trotz Liwest-v4-only.
- PoC = ad-hoc Fernwartung; Daueform = direktes WG ap1↔Geli-FB über echtes
  v6 (HE-6in4, da Liwest auch mit Fiber kein v6) statt Hub-Spoke-Gymnastik.
- Endgeräte (Note10, Cudy) bleiben v6-agnostisch: v6 nur äußerer Transport,
  LAN bleibt IPv4. Nicht für Telefonie.
- teilprojekte.md: TP10 von ⏸ PAUSIERT auf 🅿️ VERTAGT (Bridge-Cutover-Bündelung).

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

2026-06-17 18:23:27 +02:00

7.0 KiB

Raw Blame History

TP10 — Multi-Site-VPN-Migration (2× AVM-S2S → 2× WireGuard, Hub auf ap1)

Stand 2026-06-16 · Research: docs/research/vpn-comparison.md · Plan: ~/.claude/plans/pure-wibbling-graham.md gated: permanenter FB-Bridge-Mode (AP4.1) hängt an diesem TP. Reihenfolge fix: VPNs migrieren → Liwest-Anruf (Bridge) → FB wird Modem.

🅿️ STATUS 2026-06-17: VERTAGT — gebündelt mit dem FB-Bridge-Cutover

Entscheidung: TP10 nicht mehr als Parallel-Migration vorab, sondern zusammen mit dem permanenten Bridge- Cutover (VPN-auf-FB ⊕ FB-Bridge schließen sich aus). Am Bridge-Tag hat ap1 die echte Public-IP → kein FB-Port-Forward-Umweg mehr; Spokes zeigen direkt auf ap1 (DDNS). FM-PoC ✅ hat den Fix bewiesen (Root Cause: FB masqueradet, wenn die WG-Interface-Address eine Transfernetz-IP statt der FB-LAN-IP ist — AVM Proxy-ARP). Park-Zustand ap1: Peers disabled, WG-Routen entfernt (FM/DW wieder über die FB), wg-hub bleibt (Key erhalten), Firewall bleibt (TP5-Vorarbeit). Beide VPN vorerst über die FB: FM = IPsec, DW = FB-WG. Resume: routeros/fritzbox-wg-lanlan-klickanleitung.md (FB-LAN-IP als Interface-Adresse, Verify gegen 10.101.0.10).

💡 Variante DW/Geli — v6-direkt statt CGNAT-Spoke (Idee 2026-06-17, für später)

Gelis CGNAT ist nur v4; ihre FritzBox hat öffentliches natives v6 (2a0e:7a02:31c:3000::/56, rotiert ~30h → MyFRITZ-DDNS) → ihre FB ist über v6 von außen erreichbar. Der v6-Inbound-Port auf Gelis FB ist bereits offen.

Sofort/PoC (ad-hoc Fernwartung, da Geli kein Zero Trust hat): Christophs WARP (schon im Einsatz) gibt ihm outbound-v6 trotz Liwest-v4-only → Christoph(WARP-v6) → CF-Edge → Gelis v6-FB. CGNAT-immun, reversibel. Nur Fernwartung — nicht für Telefonie (Calls = Messenger-Relays).
Daueform (sauberer): echtes v6 auf BF-Seite via HE-6in4 (Liwest gibt voraussichtlich auch mit Fiber kein v6) → direktes WireGuard ap1↔Geli-FB über v6, kein Cloudflare im Datenpfad, kein Tunnel-in-Tunnel (WARP ist selbst WG), umgeht die ganze Hub-&-Spoke-CGNAT-Gymnastik unten (Geli müsste nicht mehr outbound zum Hub initiieren — v6↔v6 ist symmetrisch erreichbar). Siehe Memory project-ipv6-state.
Endgeräte bleiben v6-agnostisch: v6 ist nur der äußere Transport zwischen FB-WAN und Christophs Endpunkt; im Tunnel läuft Gelis LAN weiter rein IPv4 (192.168.178.0/24). Ihre Geräte (Galaxy Note 10, Cudy-APs als Bridge, NAS …) müssen kein v6 können — sie sehen nie ein v6-Paket. v6-Eigenfähigkeit eines Backend-Geräts wäre nur nötig, wollte man es direkt ohne Tunnel über v6 erreichen (klobig: Freigabe pro Gerät + rotierendes Prefix) — macht man nicht.

Zielbild

ap1 (hAP ax², 7.23.1) = WireGuard-Hub (nativ). FM & DW = FritzBox-Spokes (hub-&-spoke, keine Zusatz-HW).
Ablösung der 2 produktiven AVM-LAN-LAN-Tunnel auf der BF-FB → 2× WireGuard auf ap1:
- FM 10.101.0.0/24 (GW .254) — war IPsec.
- DW/Geli 192.168.178.0/24 (GW .1, CGNAT, Antennengemeinschaft Geroldsgrün) — war WireGuard.

✅ As-built auf ap1 (Phase A erledigt, 2026-06-16)

Objekt	Wert
Interface `wg-hub`	Listen UDP 51821, MTU 1412, keine IF-IP, running
Hub-Public-Key	`P/bztIk13cAmLHbN6oHGGnWAKLZsqR5TXAbFP+NGGBk=`
Endpoint (für Spokes)	`xvbeo64jqlqd9gfo.myfritz.net:51821` (MyFRITZ-FQDN)
Peer FM (`peer1`)	pub `dzRY0lnnUygijChWe5wXZmXPeNcbdALpqBptA3fyiVE=`, allowed `10.255.255.2/32,10.101.0.0/24`, Endpoint leer
Peer DW (`peer2`)	pub `FqYZLztQ/qME5VDie5QLGH++5299WJiE1dPpQnPbzUw=`, allowed `10.255.255.3/32,192.168.178.0/24`, Endpoint leer
Route	`10.101.0.0/24` → wg-hub · `192.168.178.0/24` → wg-hub (beide active)
Firewall	input accept udp/51821 · forward accept in/out wg-hub (TP5-Vorarbeit)
NAT	keine Änderung nötig — masquerade ist out-interface bridge/ether1; Tunnel-Egress = wg-hub → nie NATed

Port 51821 (statt 51820): Die BF-FB hält ihren eigenen WG-Server auf 51820 für den noch laufenden DW-Tunnel. 51821 für den Hub vermeidet die Kollision während der Parallelphase.

Spoke-Configs (Private-Keys, NICHT im Git): routeros/.secrets/wg-fm.conf, routeros/.secrets/wg-dw.conf.

✅ Vorbedingung (User erledigt)

FB-Portfreigabe UDP 51821 → 10.40.41.1 (ap1) gesetzt.

Phase B — Cutover (pro Spoke, Parallelphase) — OFFEN

Pro Standort: neuen WG-Tunnel hochziehen, verifizieren, erst dann den alten AVM-Tunnel abschalten.

B1 — FM zuerst (alter IPsec-Tunnel bleibt parallel an)

routeros/.secrets/wg-fm.conf in die FM-FritzBox importieren: Internet → Freigaben → VPN (WireGuard) → Verbindung hinzufügen → eigene Konfiguration importieren.
- ⚠️ Falls FRITZ!OS keinen Import mit vorgegebenem Key erlaubt: FB-WG-Verbindung manuell anlegen, FB-Public-Key ablesen und melden → wird in peer1 auf ap1 eingetragen (manage_wireguard_peer set public-key).
Handshake prüfen: list_wireguard_peers → peer1 last-handshake aktuell, rx/tx > 0.
L3-Verify (NetBIOS-Lehre, s.u.): Ping ap1 → ein Host in 10.101.0.0/24; Gegenrichtung FM → BF-Host (NAS); SMB per IP (TCP 445) testen, nicht Netzwerkumgebung/Broadcast.
Grün → IPsec-Tunnel für FM auf der BF-FB deaktivieren → erneut prüfen.

B2 — DW/Geli danach (alter FB-WG-Tunnel auf 51820 bleibt parallel an)

routeros/.secrets/wg-dw.conf in die DW-FritzBox importieren (CGNAT → wählt ausgehend, Keepalive 25).
Handshake + L3-Verify (Ping/SMB per IP in 192.168.178.0/24 ↔ BF).
Grün → alten DW-WG-Server/Tunnel auf der BF-FB abbauen.

NetBIOS / Namensauflösung (FM — bekannter Stolperstein)

Früherer FM-WG-Versuch scheiterte an „NetBIOS nicht geroutet". NetBIOS-Namensauflösung läuft über Broadcasts (UDP 137/138), die über einen gerouteten Tunnel grundsätzlich nicht traversieren — kein Routing-Bug. → L3 zuerst per IP beweisen (Ping + SMB/445); Namensauflösung per IP oder DNS lösen (statische Einträge), nicht über Broadcast-Browsing. Unser Design führt beide Richtungen in AllowedIPs/Routes → unicast muss laufen.

Phase C — Abschluss (nach beidseitig grün, ≥1 Tag stabil)

TP5-Firewall auf ap1 finalisieren (WG-Regeln behalten).
DDNS-Übergabe: MyFRITZ läuft über die FB, entfällt evtl. im Bridge-Mode → ap1 braucht eigenes DDNS (/ip cloud mynetname / DynDNS); Spoke-Endpoints dann auf ap1-FQDN umstellen. ⚠️ Prüfen, ob /ip cloud trotz device-mode=home läuft (scheduler/fetch geblockt).
Liwest-Anruf für FB-Bridge-Mode → FB wird Modem, ether1 = WAN, Portfreigabe entfällt.
Entblockt: NAS/Controller-IP-Migration (IP-Plan Phase 3) + Wegfall Double-NAT.

Rückbau (falls nötig)

ap1-Seite vollständig reversibel: Peers/Routen/Firewall via manage_* action=remove, wg-hub löschen.
Alte AVM-Tunnel erst nach Verifikation abschalten → jederzeit reaktivierbar.

7.0 KiB Raw Blame History Unescape Escape