Files

Christoph Emsenhuber dd4c6ad77c TP10 Doku konsolidiert: kanonischer Runbook + kompakter Kontext-Digest

- tp10-vpn-migration.md zur Single Source of Truth umgeschrieben: widerspruechliche
  alte Transfernetz-Tabelle/MyFRITZ-Endpoint entfernt, aktueller Stand (Proxy-ARP
  LAN-IP, DDNS bf4.emsenhuber.net, dual-range DW, geparkter ap1-Hub, vertagt+
  gebuendelt mit Bridge-Cutover, v6-Variante) konsolidiert.
- teilprojekte.md TP10-Eintrag von verbose Saga auf kompakten Status + Verweis gekuerzt.
- tp10-context-digest.md neu: ultrakompakter Handoff (lokal via Ollama nemotron-3-nano:4b
  destilliert, fakten-gegengeprueft) fuer kleines Kontextfenster.

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

2026-06-24 14:08:01 +02:00

5.4 KiB

Raw Blame History

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

Single Source of Truth für TP10. Research: docs/research/vpn-comparison.md · IPv6: Memory project-ipv6-state. Plan-Scratch (historisch, teils überholt): ~/.claude/plans/pure-wibbling-graham.md.

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

TP10 wird nicht mehr als Parallel-Migration vorab gemacht, sondern zusammen mit dem permanenten FB-Bridge-Cutover — denn VPN-auf-FB und FB-Bridge schließen sich aus (Bridge = Modem = keine VPN-Terminierung). Bonus: am Bridge-Tag hat ap1 die echte Public-IP → kein FB-Port-Forward-Umweg mehr, Spokes zeigen direkt auf ap1 (via DDNS).

Beide VPN laufen vorerst über die BF-FB: FM = IPsec, DW = FB-WG (Status quo, produktiv).
DW-Config ist aber schon bei Geli vor Ort gestaged (2026-06-17, seltener Zugriff genutzt) — wird erst aktiv, wenn die ap1-Seite live geht (s.u. „Offen").

Root Cause des FM-PoC (bewiesen) — der zentrale Lerneffekt

FM-WG-Versuch schlug fehl: Ping auf realen FM-Host 10.101.0.10 kam aus 10.255.255.2 zurück ⇒ die FB masqueradet den Tunnel. Ursache: WG-Interface-Address war eine Transfernetz-IP → FRITZ!OS = Einzelgerät-Modus = NAT. AVM nutzt Proxy-ARP statt Transfernetz → die FB-WG-Address muss die eigene LAN-IP sein. Damit: kein NAT, echte LAN-IPs, LAN-LAN sauber. (Gleiche Ursache wie der alte „NetBIOS routet nicht"-Fehlschlag.)

Eckdaten

Objekt	Wert
Hub `wg-hub` (ap1)	UDP 51821, MTU 1412, keine IF-IP, Key `P/bztIk13cAmLHbN6oHGGnWAKLZsqR5TXAbFP+NGGBk=`
Endpoint (Spokes)	`bf4.emsenhuber.net:51821` — DDNS via Cloudflare (Zone `emsenhuber.net`, proxied=false, TTL 120) → `86.56.201.104`. Überlebt IP-Wechsel und FB-Bridge. NICHT MyFRITZ (stirbt im Bridge).
BF-Seite (AllowedIPs der Spokes)	`10.40.0.0/16`
FM	LAN `10.101.0.0/24` (GW .254), war IPsec. FB-WG-`Address` = `10.101.0.254/24` (LAN-IP!)
DW/Geli	LAN heute `192.168.178.0/24` (GW .1), CGNAT v4, Antennengem. Geroldsgrün. Künftig `10.95.10.0/24`. FB-WG-`Address` = `192.168.178.1/24, 10.95.10.1/24` (Dual, renumber-fest)
Keepalive	Spoke-Seite `PersistentKeepalive=25` (CGNAT-Dial-out)

Spoke-Configs (Private-Keys, gitignored): routeros/.secrets/wg-fm.conf, routeros/.secrets/wg-dw.conf. ap1-Park-Zustand: Peers disabled, WG-Routen entfernt (FM/DW laufen über FB-Default), wg-hub bleibt (Key erhalten), Firewall-Regeln bleiben (TP5-Vorarbeit). NAT braucht nichts (Egress wg-hub ≠ masq-Interface bridge/ether1).

⏳ Offen — ap1-Seite aktivieren (sobald BF erreichbar; aktuell locked out)

peer2 (DW) enable/neu: public-key=FqYZLztQ/qME5VDie5QLGH++5299WJiE1dPpQnPbzUw= (unser Key; falls Gelis FB eigene Keys erzeugt → deren Public-Key eintragen), allowed-address = 192.168.178.0/24, 10.95.10.0/24, Endpoint leer.
Routen 192.168.178.0/24 → wg-hub und 10.95.10.0/24 → wg-hub.
peer1 (FM) bleibt disabled (FM auf IPsec, vertagt bis Bridge-Tag).
Verify: list_wireguard_peers Handshake; /ping 10.101.0.10 src-address=10.40.20.1 bzw. ein Geli-Host → Quelle muss die echte LAN-IP sein, nicht 10.255.255.x. NetBIOS-Lehre: per IP/DNS testen (SMB 445), nie Broadcast/Netzwerkumgebung.

DW-Gotchas

2 WG zum selben Zielnetz: Gelis FB lehnt zwei WG-Verbindungen mit überlappenden AllowedIPs (10.40.0.0/16) ab → direkter Swap (alten Geli↔BF-FB-WG entfernen, neuen Geli↔ap1 anlegen), kein Parallelbetrieb. On-site oder via temporärem Admin-Tunnel zu anderem Zielnetz.
Fernzugang zu Gelis FB: MyFRITZ-v4 tot (CGNAT). Sobald Geli↔ap1 steht → FB unter 192.168.178.1 über den Tunnel erreichbar (Endpoint später proaktiv pflegen, solange Tunnel läuft).

💡 DW-Variante: v6-direkt statt CGNAT-Spoke (für später)

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

PoC/Fernwartung jetzt: Christophs WARP gibt outbound-v6 (Liwest v4-only) → Christoph(WARP-v6) → CF-Edge → Gelis v6-FB. CGNAT-immun, reversibel. Nur Fernwartung (Calls laufen eh über Messenger-Relays).
Daueform: echtes v6 auf BF via HE-6in4 → direktes WG ap1↔Geli-FB über v6, kein CF im Datenpfad, umgeht die ganze Hub-&-Spoke-CGNAT-Gymnastik (v6↔v6 symmetrisch erreichbar). Inner-Tunnel bleibt IPv4 (Gelis Geräte v6-agnostisch).

Cutover-Sequenz (am Bridge-Tag, ein Rutsch)

ap1-Seite live (peers/routes, s.o.), Spoke-Configs an FM+DW (FM-.conf neu mit LAN-IP-Address).
Verify je Spoke (echte LAN-IP-Quelle, SMB/445 per IP).
Alte AVM-Tunnel abbauen (FM-IPsec; DW-FB-WG/Server 51820).
Liwest-Anruf → FB Bridge/Modem, ap1 = Edge mit Public-IP (DDNS zeigt weiter dorthin) → Portfreigabe entfällt.
TP5-Firewall auf ap1 finalisieren (WG-Regeln behalten).
Entblockt: NAS/Controller-IP-Migration (IP-Plan Phase 3), Double-NAT weg. Follow-up: DDNS-Auto-Updater für bf4 auf NAS/pve (statt manuell bei IP-Wechsel).

Reversibilität

ap1-Seite vollständig per manage_*/action=remove rückbaubar. Alte AVM-Tunnel erst nach Verify abschalten → jederzeit reaktivierbar. FB-Bridge bis Liwest-Anruf reversibel (routeros/wan-cutover-runbook.md).

5.4 KiB Raw Blame History Unescape Escape