6.8 KiB
WAN-Cutover Runbook + Tutorial (ap1 / Liwest FB-Passthrough)
🟢 UPDATE 2026-06-25: jetzt der PERMANENTE Cutover (TP10 gekoppelt)
Die Tunnel-Sperre ist gelöst: TP10 ist cutover-ready. Der permanente Ablauf (FM-FB → ap1-Apply → Passthrough → DDNS → Verify → alte Tunnel abbauen) steht in
docs/tp10-vpn-migration.md+ den Klick-Anleitungenrouteros/fritzbox-bf-bridge-cutover-klickanleitung.md(BF-FB) undrouteros/fritzbox-wg-lanlan-klickanleitung.md(FM-FB). ap1-Apply =routeros/tp10-cutover-apply.rsc. Das Folgende bleibt als Test-/Diagnose- und Rollback-Referenz gültig (Verkabelung, Konsolenpfad,wantest-*/wanmac-*, Sicherheitsnetze — alles weiterhin korrekt).
⚠️ Ursprünglich: REVERSIBLER TEST — die Reversibilität gilt weiter bis zum Tunnel-Teardown
Die FritzBox bleibt produktiver Router + VPN-Endpunkt + Telefon. Wir testen nur, ob der Bridge/Passthrough-Mode sauber funktioniert, sammeln Diagnose-Daten und bauen danach zurück. Grund: Die BF-FritzBox terminiert aktuell 2 Site-to-Site-Tunnel (AVM LAN-LAN: 1× IPsec + 1× WireGuard). Voller Bridge-Mode macht die FB zum reinen Modem → die Tunnel sterben. Permanenter Umstieg erst, wenn TP10 diese Tunnel auf ap1 migriert hat (Ziel: 2× WireGuard, Hub auf ap1).
Was ist wantest-run?
Ein blockierendes Loop-Script auf ap1, das 24×@15s (~6 min) die schichtweise WAN-Probe wiederholt
und persistent nach wan-test.0.txt loggt. Es ist der autonome Mitschnitt, der weiterläuft, während
Claude/MikroMCP während des Cutovers offline ist (kein Scheduler — device-mode blockt den; siehe unten).
Jede Probe misst: ether1-IP/Status, Default-Gateway, WAN-Erreichbarkeit (:resolve@1.1.1.1 = Routing+NAT
ohne DNS-Abhängigkeit) und DoH-Auflösung (= was die Clients als DNS nutzen).
Verkabelung — was wohin (ap1 hAP ax²)
┌─────────────────────── ap1 (hAP ax²) ───────────────────────┐
Liwest ─ FritzBox ──────┤ ether1 = WAN ◀── HIER umstecken (an FB-Passthrough-Port) │
(Kabel) .254 │ ether2 = LAN-Trunk ◀── Uplink zu ALLNET — NIEMALS ZIEHEN! │
│ │ ether3/4/5 = frei │
│ └──────────────────────────────────────────────────────────────┘
│ (FB bleibt Router/DHCP/VPN/Telefon — flaches 10.40.41.0/24)
└─ FB-WiFi ─ dein Laptop ◀── Console-Pfad: erreicht ap1 auf 10.40.41.1
- ether2 (LAN-Trunk → ALLNET): der Management-/Uplink-Pfad. Läuft NICHT über ether1/FB-LAN4 → übersteht den Cutover. Auf keinen Fall ziehen (sonst sind ap1 UND du vom Netz).
- ether1 (WAN → FB): der einzige Port, der in diesem Test umgesteckt wird.
WiFi / Netz — welches wofür
| Zweck | Verbinde mit | Du landest in | ap1 erreichst du auf |
|---|---|---|---|
| Console während Cutover | FritzBox-eigenes WiFi | flach 10.40.41.0/24 | 10.40.41.1 (WebFig → New Terminal) |
| DHCP-Funktionstest | install-10 … install-99 (ap1-Radios, PW jgp4ap3cwcnz) |
VLAN = SSID-Nummer, z.B. install-10 → 10.40.10.x |
Gateway 10.40.<vlan>.1, Lease .100–.200 |
Die FB-WiFi-Console (10.40.41.1 via ether2) ist bewusst der Steuer-Pfad: unabhängig von ether1/LAN4, bleibt also stehen, egal was am WAN passiert.
Schritt-für-Schritt
0 — Vorbereitung
- FB-WAN-MAC notiert:
0C:72:74:36:90:99(CM-MAC, schon als Default im Clone-Script hinterlegt). - Mit FritzBox-WiFi verbinden → WebFig
http://10.40.41.1→ New Terminal. - Scripts sind installiert:
wantest-probe,wantest-run,wanmac-clone,wanmac-revert.
1 — Auto-Capture starten (Terminal auf 10.40.41.1)
:global WTN 40 # optional: 40 Proben (~10 min). Ohne = Default 24 (~6 min)
/system script run wantest-run
→ läuft im Hintergrund weiter, auch wenn die Session abreißt. (Das Terminal blockiert während des Laufs — einfach ein zweites WebFig-Fenster für den Log öffnen.)
2 — FritzBox umstellen + ether1 umstecken
- FB-UI → LAN4 auf Passthrough/IP-Client (FB-Klickanleitung aus dem Chat /
docs/). - ether1 von ap1 an den FB-Passthrough-Port. ether2 bleibt stecken!
3 — Live mitlesen (zweites WebFig-Fenster)
/log print where message~"WANTEST"
Interpretation:
ether1 ... addr=86.x.x.x→ externe Liwest-IP gezogen ✓ (Bridge greift)wan-reach via-1.1.1.1 ok ...→ Routing+NAT ok (ohne DNS).FAIL→ WAN-Routing kaputt.dns-doh ok ...→ DoH-Auflösung ok.FAIL→ DNS/DoH kaputt = „nach .1 nichts" per Name.
4 — (optional) MAC-Clone testen, ~90 s, selbst-revertierend
/system script run wanmac-clone
→ setzt CM-MAC, release/renew, 4 Proben, dann garantierter Auto-Revert auf Werks-MAC.
Not-Revert sofort: /system script run wanmac-revert.
5 — ZURÜCKBAUEN (Pflicht — Test-Ende)
- FB-LAN4 wieder auf normal (Passthrough aus) → FB ist wieder voller Router.
- ether1 zurück an den ursprünglichen FB-LAN-Port (Double-NAT-Zustand wie vorher).
- Damit laufen FB-VPN-Tunnel + Telefon ungestört weiter.
wantest-runendet von selbst („WANTEST run done"). Früher stoppen:/system script job print→/system script job remove [find script=wantest-run].
6 — Auswerten
Claude wieder online holen → liest wan-test.0.txt → bestimmt Root-Cause für „nach .1 ging nichts mehr"
(Arbeitshypothese: DoH-Bootstrap, weil im Passthrough die FB als dynamic-servers wegfällt).
Sicherheitsnetze (eingebaut)
- Fallback-Route: statische Default-Route via bridge (distance=2) bleibt — fällt ether1 aus, geht Internet automatisch wieder über die FB (Double-NAT). Kein Totalausfall.
- MAC-Auto-Revert: im Clone-Lauf fest eingebaut (~90 s), läuft im Hintergrund garantiert zu Ende.
- Console bleibt: FB-WiFi → 10.40.41.1 via ether2 ist vom Cutover unabhängig.
Notfall
- ether1 zieht keine externe IP / kein Internet:
/system script run wanmac-revert, dann FB-LAN4 zurück auf normal — Fallback-Route hält das LAN online. - ap1 nicht erreichbar: ether2-Kabel prüfen (Uplink zu ALLNET), NICHT ether1.
- Hängendes Script killen:
/system script job print→/system script job remove <id>.
Hintergrund-Gotchas (ap1, RouterOS 7.23, device-mode=home)
- scheduler + fetch blockiert → Mechanismus ist bewusst scheduler-frei (Loop-Script).
[/ping]gibt nil zurück und ICMP ist hier geblockt → Reachability via:resolve, nie ping.- Quelle der Scripts:
routeros/wan-cutover-test.rsc,routeros/wan-macclone-test.rsc.