admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
218 Commits 5 Branches 0 Tags
0e0de74cb229b13547cba86e10630e4dc1d7e7f7
Commit Graph

3 Commits

Author SHA1 Message Date
Christoph Emsenhuber
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
Christoph Emsenhuber
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
Christoph Emsenhuber
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