Christoph Emsenhuber
919f8623c9
Echt-Host-Test (Ping realer 10.101.0.10 über WG) -> Antwort aus 10.255.255.2
=> FB masqueradet den Tunnel, bestätigt. Ursache: .conf nutzte Transfernetz-
Adresse (10.255.255.2/32) -> FRITZ!OS = Einzelgerät-Modus = NAT. AVM nutzt
Proxy-ARP statt Transfernetz -> FB-WG-Interface-Address muss die FB-LAN-IP sein
(FM 10.101.0.254/24, DW 192.168.178.1/24), Transfernetz streichen, AllowedIPs
10.40.0.0/16. -> WG-Spoke-Ansatz damit machbar.
- fritzbox-wg-lanlan-klickanleitung.md: Root Cause + One-Field-Fix (LAN-IP als
Address), LAN-LAN-Wizard, Verify gegen 10.101.0.10.
- teilprojekte.md / tp10-vpn-migration.md: Status "Root Cause gefunden, machbar".
Korrigierte Spoke-Configs in routeros/.secrets/wg-{fm,dw}.conf (gitignored).
FM bleibt auf IPsec (Sicherheitsnetz); ap1-WG-Hub inert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
77 lines
5.4 KiB
Markdown
77 lines
5.4 KiB
Markdown
# 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-16: PAUSIERT — FM auf IPsec, ROOT CAUSE gefunden (Ansatz machbar)
|
||
> Phase-A-Hub auf ap1 steht (s.u.). **Phase-B FM gescheitert → revertiert; Ursache jetzt klar:**
|
||
> Echt-Host-Test (Ping realer `10.101.0.10`) → Antwort aus `10.255.255.2` ⇒ **FB masqueradet den Tunnel.**
|
||
> **Grund:** `.conf` hatte eine **Transfernetz-Adresse** (`10.255.255.2/32`) → FRITZ!OS = Einzelgerät-Modus = NAT.
|
||
> **AVM nutzt Proxy-ARP statt Transfernetz** → FB-WG-Interface-`Address` muss die **FB-LAN-IP** sein
|
||
> (FM `10.101.0.254/24`, DW `192.168.178.1/24`), Transfernetz streichen, AllowedIPs `10.40.0.0/16`.
|
||
> Configs `routeros/.secrets/wg-{fm,dw}.conf` korrigiert. FM auf **IPsec** (Sicherheitsnetz), ap1-Hub inert.
|
||
> **Wiederaufnahme:** `routeros/fritzbox-wg-lanlan-klickanleitung.md` (FB-LAN-LAN mit LAN-IP, Verify gegen `10.101.0.10`).
|
||
|
||
## 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)
|
||
1. `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).
|
||
2. **Handshake prüfen:** `list_wireguard_peers` → `peer1` last-handshake aktuell, rx/tx > 0.
|
||
3. **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.
|
||
4. 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)
|
||
5. `routeros/.secrets/wg-dw.conf` in die **DW-FritzBox** importieren (CGNAT → wählt ausgehend, Keepalive 25).
|
||
6. Handshake + L3-Verify (Ping/SMB per IP in `192.168.178.0/24` ↔ BF).
|
||
7. 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)
|
||
8. TP5-Firewall auf ap1 finalisieren (WG-Regeln behalten).
|
||
9. **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).
|
||
10. **Liwest-Anruf** für FB-Bridge-Mode → FB wird Modem, ether1 = WAN, Portfreigabe entfällt.
|
||
11. 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.
|