TP21.1: Core-Cutover-Recovery — crs326-core als L3-Router live

crs326-core ist jetzt der produktive L3-Router (ersetzt ap1, das
plattgemacht + getrennt wurde). Nach dem Cutover fehlten DHCP, WAN,
WG-Hub und DNS-Upstream -> aus dem letzten ap1-Backup
(ap1-pre-core-cutover-20260806-073616) wiederhergestellt.

- DHCP: 7 Server (dhcp-v10..v99) + 8 Networks + 54 Leases
  (routeros/tp21-core-dhcp-from-ap1.rsc; VLAN1-Legacy + omada-inform weg)
- WAN: dhcp-client vlan100 -> Liwest 90.146.33.177, NAT-Masquerade
  (nur WAN-Variante; disabled bridge/ether1-Regeln bewusst nicht),
  Blackhole-Selbst-Default-Route entfernt
- WG-Hub (TP10): Interface + fm/dw-Peers + Routen; Privkey aus
  gitignored ap1-wg-hub.privkey -> Hub-Pubkey unveraendert, beide
  Spokes handshaken (routeros/tp21-core-wan-wg-restore.rsc, Privkey redacted)
- DNS: allow-remote-requests=yes + plain 1.1.1.1 (core hat certs=0 ->
  DoH-Cloudflare-Gateway ist TODO); entsperrte auch FM (Hub-DNS)
- Identity ap1 -> crs326-core; routers.yaml auf Zielschema
  core .99.1 / branch .99.2 / ap1 .99.11 / ap2 .99.12
- disabled/invalid-Fallen bereinigt: WG-Forward-Regeln mit stale *1D
  Interface-ID -> wg-hub; tote gateway=""-WG-Routen entfernt

Doku: teilprojekte.md TP21.1 + CLAUDE.md HW-Tabelle nachgezogen.
Offene TODOs: DoH-Restore, Nautobot-Write-back, branch-88er-Check,
core ether4, ap1/ap2-Reprovisionierung (WLAN-Rebuild).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/teilprojekte.md

@@ -548,13 +548,23 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - **Offen:** ap1/ap2/crs326-Adoption + Compliance-Push (RouterOS-API); RouterOS-Nornir-Dispatcher falls nötig; Branch-Renumber `.13→.12` und AP-Mgmt-IP-Fix in Datenmodell beim Cutover; Secret-Handling für WG-Privkey in Nautobot/Nornir klären (aktuell lokale Injektion).
 - Abh.: **TP20** (Postgres muss stehen), Gitea ✅, RouterOS-Router (ap1/ap2, dauerhaft).
 
-### TP21.1 — CRS326-Branch Recovery nach Lockout ▸ 🔴 OFFEN (2026-08-08)
-- **Auslöser:** während TP21-Passwort-Umstellung ist `crs326-branch` (10.40.99.13 / geplant .99.2) management-unerreichbar geworden. Ping und MAC-Winbox-Connect (MNDP/Winbox Layer2) schlagen fehl. Der Switch leitet aber weiterhin Traffic weiter (NAS VLAN20 erreichbar).
-- **Hypothese:** nach einem Reboot sind alle Ports wieder `disabled=yes` (bekanntes Muster aus dem Branch-Bring-up 2026-07-23 — Disable-Regex erfasste die gewünschten Ports nicht korrekt) **oder** die Management-IP/VLAN-Konfiguration wurde überschrieben.
-- **Rettungspfad:** physischer Reset auf Werkseinstellungen (`192.168.88.1/24`) über Reset-Taster, dann Bring-up von Hand wiederholen. Dabei ist der Branch-Bring-up-Stand aus `docs/tp15-crs326-session-handoff-prompt.md`/`nautobot/ingest-crs326-ports.py` maßgeblich.
-- **Kritikalität:** HOCH — am Branch hängen NAS, Sonos (Media), Drucker, Dock, Mac mini, ap2. Während des Recoveries kein VLAN20/30/40/50/90/99-Zugang über diesen Pfad.
-- **Abhängigkeit:** User muss physisch am Gerät sein (Console/Winbox-MAC/Reset). TP21-Weiterarbeit an MikroTik-Geräten blockiert bis der Branch wieder management-erreichbar ist.
-- **Nächster Schritt (Session-Neustart):** Reset → Grundkonfiguration Bridge+VLAN-Filtering+Uplink-Trunk → Mgmt-IP `.99.13` wiederherstellen → Portbelegung 1:1 aus TP15-Bring-up nachziehen → dann erst weiter mit TP21-Passwort-Rotation + AP-Reprovisionierung.
+### TP21.1 — Core-Cutover-Recovery (ap1 → crs326-core als L3-Router) ▸ ✅ NETZ WIEDER LIVE (2026-08-08); Aufräum-Todos offen
+> **Kern-Erkenntnis (wichtig gegen Doku-Verwirrung):** **`crs326-core` IST jetzt der produktive L3-Router.** Der Core-Cutover (TP15) wurde faktisch vollzogen — ap1 wurde plattgemacht/getrennt, core hat Routing/DHCP/DNS/NAT/WG-Hub übernommen. core-Mgmt = **`10.40.99.1`** (vlan99-SVI) bzw. same-subnet-Fallback **`10.40.10.1`** (RouterOS-Version 7.19.5 identifiziert das Gerät zweifelsfrei als CRS326, nicht als hAP/ap1). Die CLAUDE.md-Zeile „core grundkonfiguriert, NICHT produktiv" ist damit **überholt**.
+- **Verlauf:** Ausgangssymptom war ein L3-Ausfall-Eindruck (kein DHCP, „kein Routing nach .20.x"). Ursache = **unvollständiger Cutover**: core hatte L3-SVIs + Firewall, aber es fehlten DHCP-Server, WAN-Egress, WG-Hub und der DNS-Resolver-Upstream. ap1 (bisher alleiniges L3-Gerät) war bereits Werksreset + getrennt.
+- ✅ **DHCP wiederhergestellt** aus letztem ap1-Backup (`routeros/ap1-pre-core-cutover-20260806-073616.rsc`): 7 Server (`dhcp-v10…v99`) + 8 Networks + **54 statische Reservierungen** + Option `dns 1.1.1.1`. Reproduzierbar in `routeros/tp21-core-dhcp-from-ap1.rsc`. Legacy VLAN1 (pool-v1/defconf) + tote omada-inform-Option bewusst weggelassen.
+- ✅ **WAN/Internet:** dhcp-client auf `vlan100` → Liwest-Public-IP `90.146.33.177` gebunden (Arris hängt physisch an core.vlan100), NAT-Masquerade `out-interface-list=WAN`, Default-Route korrekt; die self-pointing Blackhole-Route `0.0.0.0/0 via 10.40.99.1` entfernt. **disabled-Falle beachtet:** die ap1-Masquerade-Regeln `out-interface=bridge`/`=ether1` sind `disabled=yes` und wurden NICHT übernommen.
+- ✅ **WG-Hub (TP10)** neu aufgebaut: `wg-hub` (listen 51821, Privkey aus `routeros/ap1-wg-hub.privkey`, Hub-Pubkey unverändert) + Peers `fm`/`dw` + Routen. **Beide Tunnel handshaken** (dw + fm live). Reproduzierbar (Privkey redacted) in `routeros/tp21-core-wan-wg-restore.rsc`.
+- ✅ **DNS gefixt:** core hatte `allow-remote-requests=no` + leeren Upstream → Client-DNS tot UND Hub konnte myfritz (FM-Endpoint) nicht auflösen. Fix = `allow-remote-requests=yes` + `servers=1.1.1.1` (**plain**, weil core `certs=0` → `verify-doh-cert` unmöglich). Das entsperrte auch FM.
+- ✅ **Identity** auf `crs326-core` gesetzt (war fälschlich „ap1" — genau diese Altlast stiftete Verwirrung). `mcp/mikromcp/config/routers.yaml` auf Zielschema: core `.99.1`, branch `.99.2`, ap1 `.99.11`, ap2 `.99.12` (wirkt nach MCP-Neustart; danach core via routerId `crs326-core`).
+- ✅ **disabled/invalid-Falle bereinigt (User-Hinweis „keine disabled-Falle?"):** (a) die 2 TP10-WG-Forward-Regeln (`allow from/to WG spokes`) waren `I`=invalid, weil aus dem ap1-Backup mit der **stale Interface-ID `*1D`** übernommen → auf `in/out-interface=wg-hub` (per Name) korrigiert; (b) 2 **inaktive WG-Route-Leichen** (`gateway=""`, aus einem früheren Cutover-Versuch vor Existenz von wg-hub) entfernt, nur die aktiven `gateway=wg-hub` bleiben. **Finaler Sweep sauber:** filter-invalid=0, nat-invalid=0, routes-inactive=0, if-disabled=2 (nur ungenutzte `sfp-sfpplus1/2`, gewollt).
+- ✅ **Backups:** `core-pre-dhcp-restore-20260808.backup` (vor Eingriff) + `core-post-tp21-recovery-20260808.backup` (nach allen Fixes neu gezogen) auf dem Gerät.
+- ℹ️ **branch** ist gesund (L2, forwardet), Mgmt `10.40.99.2` (+ temp `10.40.10.2`) — via core-MNDP bestätigt. Das in Winbox-MAC gesehene „0.0.0.0" ist der bekannte Discovery-Artefakt (Gerät hat auf dem Discovery-VLAN keine IP), kein echtes Problem.
+- 🔜 **TODO (Aufräum-Liste, spätere Session — danach WLAN-Neuprovisionierung):**
+  1. **DoH-Cloudflare-Gateway auf core wiederherstellen** (aktuell nur plain 1.1.1.1, keine Filterung/Account-Bindung): CA-Bundle importieren → `use-doh-server=https://px35ynlol3.cloudflare-gateway.com/dns-query verify-doh-cert=yes` (Referenz-Config liegt auf **ap1**).
+  2. **Intended config nach Nautobot zurückschreiben** (die Direkt-Writes liefen unter der CRS326-Cutover-Governance-Ausnahme).
+  3. **branch `192.168.88.1`-Rest verifizieren** (Bootstrap Rev 4 entfernt es in Zeile 70; via MCP noch nicht gegengeprüft, weil Registry-Umstellung MCP-Neustart braucht).
+  4. **core `ether4`** prüfen/geraderücken — laut User evtl. sein NIC (Dock/Monitor), steht aber als tagged Trunk in der Bridge-VLAN-Tabelle.
+  5. **`ap1`/`ap2` Neuprovisionierung** (WLAN-Rebuild, eigene Session) — ap1 ist Werksreset; danach greifen die `.99.11`/`.99.12`-Registry-Einträge.
 
 ### TP-R — Router-Capabilities-Sweep ▸ FERTIG (`docs/research/routeros-capabilities.md`)
 - **Leitsatz: nativ vor Container, NAS vor Router** (128MB-Flash-Limit).