48754f446d
TP10 🔧 WG live: Key-Mixup + stale bf4 + DW-Dual-Address behoben, DW→10.95.10.0/24
...
Live-Debug-Session (Double-NAT): WG-Hub ist jetzt aktiv, FM+DW-Tunnel UP.
- Root Causes behoben: (1) beide ap1-Peers trugen faelschlich ap1s EIGENEN Public-Key
P/bzt... statt der FB-Keys dzRY.../FqYZ... (2) bf4.emsenhuber.net war stale -> DW-Dial-in
(CGNAT) lief erst danach. (3) DW-Dual-Address 192.168.178.1/24,10.95.10.1/24 -> FRITZ!OS
macht 10.95.10.1 primaer u. koppelt das LAN nicht -> Single-Address-Regel.
- DW standardisiert auf 10.95.10.0/24 (Geli renumbert vor Cutoff): wg-dw.conf single,
ap1 peer dw allowed-address=10.95.10.0/24, Route 10.95.10.0/24 -> wg-hub. Routing verifiziert (0% Loss).
- Klickanleitung: DW-Renumber + Single-Address-Lehre; Doku/Digest auf Live-Stand.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com >
2026-06-25 21:00:07 +02:00
963e3c5f9a
TP10 🔐 Cutover-Ready: ap1-Apply-Skript + WAN-Input-Seal + FB-Klickanleitungen
...
ap1-Seite gestaged in routeros/tp10-cutover-apply.rsc (idempotent, am Bridge-Tag
anwenden): WG-Peers säubern (Transfernetz-/32 raus) + enable, peer1/FM bidirektional
(Endpoint abxhutfgsid9snmy.myfritz.net:52476, kein CGNAT), peer2/DW Dial-in; Spoke-
Routen → wg-hub; Input-Chain WAN-Seal (schließt Mgmt-Dienste + offenen Resolver,
sobald ether1 die Public-IP hält); ether1 use-peer-dns=no.
FB-Seite (kein MCP → Klickanleitung): neue fritzbox-bf-bridge-cutover-klickanleitung.md
(Passthrough + alte FM/DW-WG-Teardown + Rollback); fritzbox-wg-lanlan-klickanleitung.md
mit Schnellpfad (FM nur Peer-Endpoint auf bf4 umbiegen) + IPsec-Korrektur.
Doku: tp10-vpn-migration.md Status → CUTOVER-READY, Live-Stand verifiziert; FM=FB-WG
(IPsec längst gekillt) korrigiert. wan-cutover-runbook.md als permanenter Cutover markiert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com >
2026-06-25 12:07:46 +02:00
919f8623c9
TP10 🎯 Root Cause FM-NAT gefunden: FB braucht LAN-IP als WG-Address (Proxy-ARP)
...
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 >
2026-06-17 00:15:32 +02:00
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
