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
parent 51054938ac
commit 3e59383317
3 changed files with 93 additions and 47 deletions
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -64,4 +64,6 @@ GW je VLAN = `.1` · APs: ap1=`.1`, ap2=`.2` · Switches: ALLNET=`.11`, Omada=`.
 - **Mesh = NEIN** (beide APs haben wired Trunk-Uplink → Loop-Risiko).
 - mgmt-VLAN-Wechsel am Switch = Lockout-Risiko: VLAN muss existieren + Port muss es tragen, in einem Schritt.
 - **Omada ES208G = Easy Managed** → Controller-adoptierbar (ab 6.1.x), nur Basis-VLAN/QoS im Controller (kein ACL/Policy-Routing).
- **TP4 ✅: ap1 ist L3-Router.** Bridge mit vlan-filtering=yes; VLAN1 untagged (Mgmt/Transition); vlan10-99 Subinterfaces mit DHCP+DNS. NAT masquerade out=bridge → FB (Double-NAT bis FB-Bridge-Mode). DNS: 13 statische A-Records bf.lan, Upstream FB. Omada-PVID-Fix (→ .10/.20-Subnetze) ist nächster Schritt.
+- **TP4 ✅: ap1 ist L3-Router.** Bridge mit vlan-filtering=yes; VLAN1 untagged (Mgmt/Transition); vlan10-99 Subinterfaces mit DHCP+DNS. NAT masquerade out=bridge → FB (Double-NAT bis FB-Bridge-Mode). DNS: 13 statische A-Records bf.lan, **Upstream seit 2026-06-16 = DoH Cloudflare Gateway** (servers=1.1.1.1 Bootstrap). Omada-PVID-Fix (→ .10/.20-Subnetze) ist nächster Schritt.
+- **AP4.1 FB-Bridge = nur TEST/reversibel.** Public-IP `86.56.201.104` per ether1 bewiesen (kein Liwest-MAC-Lock, FB CM-MAC `0C:72:74:36:90:99`). Offline-Testmechanismus live auf ap1: `routeros/wan-cutover-{test,macclone-test}.rsc` + `wan-cutover-runbook.md`, Scripts `wantest-probe/-run`, `wanmac-clone/-revert`, Disk-Log `wan-test.0.txt`. **Console-Pfad während Cutover = FritzBox-WiFi → 10.40.41.1** (via ether2, unabhängig von ether1/LAN4). **⚠️ Permanenter Bridge-Mode gegated auf TP10** (FB hält 2 VPN-Tunnel: 1× IPsec + 1× WG → Ziel 2× WG/ap1) + Telefon.
+- **ap1 RouterOS-Scripting (device-mode=home):** **scheduler + fetch blockiert** (`not allowed by device-mode`) → keine Scheduler in Scripts, Autonomie via Loop-Script. **`[/ping]` gibt nil in 7.23**, ICMP geblockt → Reachability via `:resolve` (server=1.1.1.1 = Routing-Test, ohne server = DoH). MikroMCP-Tools können droppen → Fallback REST `http://10.40.41.1/rest` (Creds = ROUTER_AP1 in `~/.claude.json`).
--- a/docs/teilprojekte.md
+++ b/docs/teilprojekte.md
@@ -20,7 +20,8 @@ IP-Blöcke: `.1–10` Router/APs (ap1=.1, ap2=.2) · `.11–20` Switches (ALLNET
 ## Ist-Stand (Kurz)
 ALLNET-Core `.11` (FW2.2.1, VLANs 10/20/30/40/50/90/99/100; GE1/GE2/GE8 Trunk; **TP1 ✅ 2026-06-15**). Omada-Switch `.12` (adopted, **TP2 ✅ 2026-06-15**; Trunk-ALL auf P1+P2, Access-Profile auf P3-P8; Profile noch PVID=1 bis Omada-PVID-Fix).
 Omada-Controller **`.175`** (DS923/macvlan, mbentley 6.2, 🟢 live). omada-mcp **`.176`** (pve-LXC, StreamableHTTP, 🟢 live, 84 read-Tools; Controller-API v2 intern via christoph@emsenhuber.com).
-2× hAP ax² (7.23.1): ap1 `.1` (ALLNET P1) — **TP4 ✅ 2026-06-15: L3-Router aktiv** (VLAN-Subinterfaces, DHCP, DNS, NAT). ap2 `.2` (Omada P2 — Trunk). FB6660 = Double-NAT-Upstream bis FB-Bridge-Mode (ausstehend, physisch).
+2× hAP ax² (7.23.1): ap1 `.1` (ALLNET P1) — **TP4 ✅ 2026-06-15: L3-Router aktiv** (VLAN-Subinterfaces, DHCP, DNS, NAT). ap2 `.2` (Omada P2 — Trunk). FB6660 = Double-NAT-Upstream bis FB-Bridge-Mode.
+**AP4.1 (FB-Bridge, 2026-06-16):** Public-IP `86.56.201.104` per ether1 bewiesen (kein Liwest-MAC-Lock). Offline-Testmechanismus live auf ap1 (`routeros/wan-cutover-*.rsc` + Runbook; scheduler-frei, Disk-Log `wan-test.0.txt`). ⚠️ **FB-Bridge bleibt vorerst nur TEST (reversibel)** — die FB hält 2 produktive VPN-Tunnel (AVM LAN-LAN: 1× IPsec + 1× WG) → **permanenter Bridge-Mode gegated auf TP10** (VPN-Migration auf 2× WG/ap1).
 Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Controller + omada-mcp 🟢.
 **Nächster Schritt: Omada-PVID-Fix** (MAIN→PVID10, INFRA→PVID20, untagNetworkIds bereinigen) + IP-Migration Geräte.
 > ⚠️ **HW-Constraint hAP ax²:** 1 GB RAM, aber nur **128 MB Flash + KEIN USB** → **Container auf dem Router NICHT praktikabel**.
@@ -82,11 +83,11 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co
 - ✅ **Bridge VLAN-Filtering aktiviert** (`vlan-filtering=yes`); VLAN-Tabelle: VLAN1 untagged bridge+ether2, VLANs 10/20/30/40/50/90/99/100 tagged bridge+ether2.
 - ✅ **VLAN-Subinterfaces:** vlan10/20/30/40/50/90/99 auf bridge; je GW `.1` (10.40.10.1 … 10.40.99.1).
 - ✅ **DHCP:** dhcp-v10…dhcp-v99 je auf eigenem VLAN-Interface, pools .100-.200, GW+DNS = VLAN-GW.
- ✅ **DNS:** RouterOS-nativ, allow-remote-requests=yes, Upstream 10.40.41.254 (FB, interim). Statische Einträge für alle Infra-Hosts unter `bf.lan` (13 Einträge, Transition-IPs bis PVID-Fix).
+- ✅ **DNS:** RouterOS-nativ, allow-remote-requests=yes. **Upstream seit 2026-06-16: DoH Cloudflare Gateway** (`use-doh-server=https://px35ynlol3.cloudflare-gateway.com/dns-query`, verify-doh-cert, `servers=1.1.1.1` als Bootstrap; FB-Upstream abgelöst). Statische Einträge für alle Infra-Hosts unter `bf.lan` (13 Einträge, Transition-IPs bis PVID-Fix).
  - ⚠️ Auto-Suffix `.lan` (RouterOS-Einschränkung, kann nicht auf leer gesetzt werden) — TP5-Cleanup.
 - ✅ **NAT:** srcnat masquerade out-interface=bridge (ap1 → FB → Internet, Double-NAT Interim-Lösung).
 - ✅ **Routing-Tabelle:** 0.0.0.0/0 via 10.40.41.254%bridge; alle 7 VLAN-Subnetze als Connected-Routes aktiv.
- ⏳ **FB-Bridge-Mode** (LAN4-Native-Bridge-Hack) ausstehend — physisch: Kabel FB LAN4 → ap1 ether1, dann ether1 als WAN konfigurieren. Bis dahin: Double-NAT via bridge (funktioniert).
+- ⏳ **FB-Bridge-Mode (AP4.1)** — ether1 als WAN ist vorkonfiguriert (DHCP-Client, NAT out=ether1, Fallback-Route bridge distance=2). **Test 2026-06-16:** Public-IP `86.56.201.104` per ether1 bewiesen (kein Liwest-MAC-Lock). Offline-Testmechanismus live (`routeros/wan-cutover-test.rsc`/`-macclone-test.rsc` + `wan-cutover-runbook.md`; scheduler-frei wg. device-mode, Disk-Log `wan-test.0.txt`). User-Befund „nach Gateway .1 ging nichts mehr" → Root-Cause offen (Hypothese DoH-Bootstrap). ⚠️ **Bridge bleibt nur TEST/reversibel; permanenter Umstieg gegated auf TP10** (FB hält bis dahin 2 VPN-Tunnel + Telefon). Bis dahin: Double-NAT via bridge (funktioniert).
 - **DNS-Entscheidung** (Technitium **und** externer BIND verworfen): RouterOS-DNS als Resolver, keine DHCP→DNS-Auto-Registrierung (soweit möglich). Infra-Hosts als statische `/ip dns static`-Einträge unter `bf.lan`; dynamische Clients bewusst ohne Namen. Filtering/DNSSEC via DoH-Upstream (TP3). HA: 2. Resolver auf ap2, statische Einträge beidseitig pflegen.
 - Abh.: TP1 ✅. TP3-Abhängigkeit entfällt (WLAN läuft weiterhin über FB bis TP3).
 - **Ermöglicht jetzt:** PVID-Fix in Omada-Profilen (MAIN→PVID10, INFRA→PVID20), untagNetworkIds-Bereinigung, DHCP-Reservierungen für NAS/macmini/pve auf neue VLAN-Subnetze migrieren.
@@ -121,7 +122,9 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co
 - **WARP kann FBs NICHT direkt** ansprechen → bräuchte Connector-Host hinter der FB (an reinen-FB-Standorten FM/DW unattraktiv).
 - **Vorab-Check (User, entscheidend):** WAN je Standort — **public/dynamisch (OK: DynDNS/MyFRITZ) vs. CGNAT/DS-Lite am BF-Hub (= K.O. → dann CF/WARP-Pfad, CGNAT-immun)**.
 - WG-Gotchas: keine IP aufs WG-IF (MikroTik), AllowedIPs=Tunnel+LAN-CIDRs, MTU 1412, Keepalive 25. ap1 hat noch KEIN WG (Neuaufbau).
- Abh.: WAN-Check; Hub sinnvoll nach TP4 (Router-Cutover).
+- **IST-Zustand (User 2026-06-16):** Die BF-FritzBox terminiert AKTUELL **2 produktive Site-to-Site-Tunnel** (AVM LAN-LAN: **1× IPsec + 1× WireGuard**). Migrationsziel: **2× WireGuard** mit Hub auf ap1, FB-Standorte als Spokes.
+- ⚠️ **TP10 ist Voraussetzung für den permanenten FB-Bridge-Mode (AP4.1/TP4).** Solange die FB die 2 Tunnel terminiert, muss sie Router bleiben → FB-Bridge nur reversibel testbar, nicht dauerhaft.
+- Abh.: WAN-Check; Hub sinnvoll nach TP4 (Router-Cutover). **Blockiert:** permanenten FB-Bridge-Mode.

 ### TP11 — Monitoring & Mgmt-Control-Plane ▸ research-gated
 - MikroMCP + omada-mcp + **SNMP/icinga-mikrotik**, RoMON, NTP, **E-Mail-Alerts**, Netwatch. → Teil von `docs/research/routeros-capabilities.md`.
--- a/routeros/wan-cutover-runbook.md
+++ b/routeros/wan-cutover-runbook.md
@@ -1,71 +1,112 @@
-# WAN-Cutover Runbook (Solo, ohne Claude live)
+# WAN-Cutover Runbook + Tutorial (ap1 / Liwest FB-Passthrough)

-Ziel: FB-LAN4 auf Passthrough/Bridge umstellen, sodass **ap1 ether1** die echte Liwest-Public-IP
-zieht (Single-NAT statt Double-NAT). Der Testmechanismus läuft **autonom auf ap1** und loggt persistent
-— du brauchst Claude während des Cutovers nicht.
-
-**Dein Console-Pfad:** altes WiFi → `10.40.41.1` (WebFig → New Terminal). Läuft über ap1 **ether2**
-(ALLNET-Uplink) und übersteht den Cutover an ether1/FB-LAN4.
-
-> ⚠️ **device-mode=home** blockiert auf ap1 Scheduler *und* `/tool fetch`. Deshalb arbeitet der
-> Mechanismus **ohne Scheduler**: `wantest-run` ist ein blockierendes Loop-Script, das im Hintergrund
-> weiterläuft (auch wenn deine Session abreißt). Der MAC-Auto-Revert ist fest in den Clone-Lauf eingebaut.
+> ## ⚠️ DAS IST EIN REVERSIBLER TEST — KEIN PERMANENTER UMSTIEG
+> 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).

 ---

-## Schritt 0 — Vorbereitung (mit Claude online schon erledigt)
- Scripts auf ap1 installiert: `wantest-probe`, `wantest-run`, `wanmac-clone`, `wanmac-revert`.
- Disk-Logging aktiv → Ergebnisse in `wan-test.0.txt` **und** live im `/log`.
- FB-WAN-MAC für den Clone-Lauf: **`0C:72:74:36:90:99`** (CM-MAC, als Default hinterlegt).
+## 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²)

-## Schritt 1 — Auto-Capture starten
-WebFig-Terminal auf `10.40.41.1`:
 ```
-:global WTN 40                      # optional: 40 Proben (~10 min). Default ohne = 24 (~6 min)
+                          ┌─────────────────────── 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
 ```
-→ probt alle 15 s und loggt jede Schicht. Läuft im Hintergrund. (Terminal blockiert während des Laufs;
+→ 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.)

-## Schritt 2 — FritzBox umstellen + Kabel
- FB-UI → LAN4 auf Passthrough/IP-Client (Klickanleitung im Chat / `docs/`).
- ether1 von ap1 an den FB-Passthrough-Port. **ether2 (Uplink) bleibt stecken!**
+### 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!**

-## Schritt 3 — Live mitlesen
+### 3 — Live mitlesen (zweites WebFig-Fenster)
 ```
 /log print where message~"WANTEST"
 ```
-Schichten interpretieren:
- `ether1 ... addr=86.x.x.x` → externe IP gezogen ✓ (Bridge greift)
- `wan-reach via-1.1.1.1 ok ...` → **Routing+NAT zur Public-IP ok** (ohne DNS-Abhängigkeit)
- `wan-reach ... FAIL` → Routing/NAT kaputt → „nach .1 nichts" = WAN-seitig
- `dns-doh ok ...` → DoH-Namensauflösung ok (das, was Clients als DNS nutzen)
- `dns-doh FAIL` → DoH/Bootstrap kaputt → „nach .1 nichts" = **DNS** (Client erreicht .1, aber nichts per Name)
+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.

-## Schritt 4 — MAC-Clone testen (optional, ~90 s, selbst-revertierend)
-Erst wenn Baseline extern steht:
+### 4 — (optional) MAC-Clone testen, ~90 s, selbst-revertierend
 ```
 /system script run wanmac-clone
 ```
-→ setzt CM-MAC `0C:72:74:36:90:99`, release/renew, 4 Proben, dann **garantierter Auto-Revert** auf
-Werks-MAC (alles in einem Lauf). Vergleiche im Log IP/Schichten mit FB-MAC vs. Baseline.
+→ setzt CM-MAC, release/renew, 4 Proben, dann **garantierter Auto-Revert** auf Werks-MAC.
 Not-Revert sofort: `/system script run wanmac-revert`.

-## Schritt 5 — Abschluss
- `wantest-run` endet von selbst nach WTN Proben (Log: „WANTEST run done").
- Früher stoppen: `/system script job print` → `/system script job remove [find script=wantest-run]`.
- Dann Claude wieder online holen → Claude liest `wan-test.0.txt` und bestimmt die Root-Cause.
+### 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.
+- **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:** `10.40.41.1` via ether2/altes WiFi ist vom Cutover unabhängig erreichbar.
+- **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.
+- 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`.