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>

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`.