Files
bf-infra/docs/tp10-vpn-migration.md
Christoph Emsenhuber e54e6eb7cb TP10 ⏸ pausiert: FM-Cutover revertiert (IPsec), FB-WG-LAN-LAN-Klickanleitung
FM-Cutover-Versuch gescheitert: .conf importiert, Handshake grün, IPsec voreilig
deaktiviert -> FM unerreichbar. Diagnose-Fehler: nur FB-eigene .254 gepingt (FB
antwortet aus Tunnel-IP 10.255.255.2 -> OS verwirft); echte FM-LAN-Hosts nie
getestet -> NAT-These unbewiesen. Research (Bouni) bestätigt FB<->MikroTik
LAN-LAN ohne NAT ist machbar. FM auf IPsec zurückgestellt; ap1-WG-Hub bleibt inert.

- routeros/fritzbox-wg-lanlan-klickanleitung.md: Diagnose->Fix->Verify, Echt-Host-
  Test ZUERST (10.101.0.10, nicht .254), IPsec bleibt Sicherheitsnetz.
- teilprojekte.md / tp10-vpn-migration.md: Status ⏸ + Incident dokumentiert.

Spoke-.conf mit Private-Keys bleiben gitignored in routeros/.secrets/ (die
ungetrackten Duplikate in routeros/ Root sind bewusst NICHT committet).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 21:36:02 +02:00

76 lines
5.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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 zurück
> Phase-A-Hub auf ap1 steht (s.u.). **Phase-B-Versuch FM gescheitert + revertiert:** `.conf` importiert,
> Handshake grün, IPsec voreilig aus → FM nicht erreichbar. **Diagnose-Fehler:** nur FB-eigene `.254` gepingt
> (antwortet aus Tunnel-IP `10.255.255.2` → OS verwirft); **echte FM-LAN-Hosts nie getestet** → NAT-These unbewiesen.
> Research (Bouni) sagt: FB↔MikroTik-LAN-LAN **ohne NAT geht**. User hat **FM auf IPsec zurückgestellt** (FB-WG aus),
> ap1-WG-Hub bleibt (inert). **Wiederaufnahme via Klickanleitung `routeros/fritzbox-wg-lanlan-klickanleitung.md`**
> (Echt-Host-Test ZUERST, dann FB-LAN-LAN-Check, IPsec bleibt Sicherheitsnetz).
## 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.