# 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-Anleitungen
> `routeros/fritzbox-bf-bridge-cutover-klickanleitung.md` (BF-FB) und `routeros/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-run` endet 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`.