Commit Graph

9 Commits

Author SHA1 Message Date
2a2338fe82 TP10 🔐 WG-Hub-Apply self-healing: Peers fm/dw mit Keys + Allowed-IPs gefixt
- peer1/peer2 → fm/dw umbenannt, public-keys explizit gesetzt (idempotent)
- dw allowed-address auf 10.95.10.0/24 reduziert (192.168.178.0/24 raus →
  Dual-Address auf Gelis FB verhindert LAN-Kopplung)
- zugehörige 192.168.178.0/24-Route entfernt, DW-Routenkommentar bereinigt

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-25 20:55:28 +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
03f328f043 TP3 📶 ✅ As-built finalisiert: 5 dirtyvader-SSIDs live, Kanal-Plan + Sonos-Diagnose
- ft=no auf sec-media (802.11r bricht Sonos), ft-over-ds=no
- Kanal-Plan non-DFS/überlappungsfrei: ap1 ch36+ch1, ap2 ch149+ch11
  (Auto-Channel hatte beide APs auf 5500-DFS/2437 = Co-Channel gelegt)
- tp3-capsman.rsc: Channel-Frequenzen, ap1-Interface-Override, Verifikation 2026-06-18
- obsolete capsman-flat-asbuilt/ap1-manager/ap2-cap entfernt (von tp3-capsman.rsc ersetzt)
- teilprojekte.md TP3 → ✅; Sonos-Split-Diagnose in tp7-mdns.md + sonos-inventar.md
  (7 WLAN-Sonos noch auf FB-WLAN/VLAN1 → "selektiv je Netz", kein mDNS-Defekt)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-18 01:11:41 +02:00
6bcef5862f TP3 📶 As-built: CAPsMAN dirtyvader-SSIDs (5 sichtbar, je SSID→VLAN)
routeros/tp3-capsman.rsc: ap1=Manager+AP (Radios lokal), ap2=CAP (Provisioning).
5 SSIDs über beide APs/Bänder mit wifi-datapath vlan-id: main(10), iot(30, nur 2,4 GHz),
media(40), untrusted(50), guest(90); infra(20)/mgmt(99) vertagt. WPA3/WPA2+3, FT auf
main+media. Passphrase als Platzhalter __TEMP_PSK__ (echter Temp-Wert in gitignored
routeros/.secrets/tp3-capsman.psk). Ersetzt capsman-flat-asbuilt/ap1-manager/ap2-cap.rsc.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-18 00:34:47 +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
3e59383317 AP4.1 📋 Cutover-Tutorial + Session-Doku — FB-Bridge gegated auf TP10-VPN
Schärft das Runbook zum vollständigen Solo-Tutorial (Verkabelungs-Diagramm,
WiFi/VLAN-Matrix, Schritt-für-Schritt mit Zurückbau) und schreibt den
Session-Stand für die Fortsetzung fort.

Kernpunkt: FB-Bridge ist nur ein REVERSIBLER TEST. Die BF-FritzBox terminiert
aktuell 2 produktive Site-to-Site-Tunnel (AVM LAN-LAN: 1× IPsec + 1× WG),
Ziel 2× WG auf ap1 = TP10. Voller Bridge-Mode killt diese Tunnel → permanenter
Umstieg ist auf TP10 gegated (FB bleibt bis dahin Router + VPN + Telefon).

- wan-cutover-runbook.md: TEST-Banner, Verkabelung (ether2=Uplink nie ziehen,
  ether1=WAN), Console = FritzBox-WiFi → 10.40.41.1, install-SSIDs für DHCP-Test,
  wantest-run erklärt, Zurückbau-Schritt.
- docs/teilprojekte.md: Ist-Stand + TP4 (AP4.1 Public-IP bewiesen, Testmechanismus,
  DNS-Upstream jetzt CF-DoH) + TP10 (FB hält 2 Tunnel, gated permanenten Bridge).
- CLAUDE.md: WAN-Testmechanismus, device-mode-Gotchas (scheduler/fetch blockiert,
  [/ping]=nil → :resolve), VPN-Gate, REST-Fallback.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 11:45:41 +02:00
51054938ac AP4.1 🧪 Offline-WAN-Cutover-Test für ap1 — scheduler-frei, Disk-Log
Toolkit, um den FB-Bridge/Passthrough-Cutover (Liwest) autonom auf ap1 zu
testen, während Claude/MikroMCP offline ist (Test-Client auf install-wifi,
LAN4-Umstecken kappt den Live-Pfad).

- wan-cutover-test.rsc: wantest-probe (schichtweise Diagnose: ether1-IP,
  default-gw, WAN-Reach via :resolve@1.1.1.1, DoH end-to-end) + wantest-run
  (blockierender Loop, Hintergrund-fähig). Persistentes Disk-Logging nach
  wan-test.0.txt.
- wan-macclone-test.rsc: CM-MAC-Clone (0C:72:74:36:90:99) mit eingebautem
  Auto-Revert (~90s), scheduler-frei.
- wan-cutover-runbook.md: Solo-Runbook für den User (Console altes WiFi →
  10.40.41.1).

Scheduler-frei, weil device-mode=home auf ap1 /system scheduler und /tool
fetch blockiert. Reachability via :resolve statt ping ([/ping] gibt in
7.23 nil; ICMP hier geblockt). Public-IP 86.56.201.104 bereits bewiesen
(kein Liwest-MAC-Lock).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 00:57:05 +02:00
Christoph Emsenhuber
e688b37b60 Teilprojekte + MikroMCP + WLAN-Vorarbeit: Steuerungsdok, Research, MCP-Setup, CAPsMAN-Asbuilt, AP-Trunk-Guides + Port-Map
- docs/teilprojekte.md: kanonisches Projektsteuerungsdokument (TP1–TP13 + TP-R)
- docs/research/: RouterOS-Capabilities-Sweep (TP-R) + VPN-Vergleich (TP10)
- mcp/: MikroMCP + Portainer-MCP Docker-Compose, routers.yaml, READMEs, .gitignore
- routeros/: ap1-manager.rsc, ap2-cap.rsc, CAPsMAN-Flat-Asbuilt, WLAN-Handover
- switch/cli/03-trunk-ap-ports.cli + switch/ui-guides/01-trunk-ap-ports.md: AP-Trunk-Konfiguration
- docs/allnet-ge8-trunk-klickanleitung.md: GE8 Hybrid→Trunk Schritt-für-Schritt
- inventory/bf-core-ports: gi1/gi2 als TRUNK zu ap1/ap2 eingetragen (gesetzt 2026-06-09)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-15 08:42:03 +02:00