Christoph Emsenhuber
dd4c6ad77c
- 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>
69 lines
5.4 KiB
Markdown
69 lines
5.4 KiB
Markdown
# 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)
|
||
1. ap1-Seite live (peers/routes, s.o.), Spoke-Configs an FM+DW (FM-`.conf` neu mit LAN-IP-Address).
|
||
2. Verify je Spoke (echte LAN-IP-Quelle, SMB/445 per IP).
|
||
3. Alte AVM-Tunnel abbauen (FM-IPsec; DW-FB-WG/Server 51820).
|
||
4. **Liwest-Anruf** → FB Bridge/Modem, ap1 = Edge mit Public-IP (DDNS zeigt weiter dorthin) → Portfreigabe entfällt.
|
||
5. TP5-Firewall auf ap1 finalisieren (WG-Regeln behalten).
|
||
6. 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`).
|