TP15: WG-Hub Key-Restore + AP-Reset Handoff (ap1 resettet, ap2 pending)

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

docs/tp15-ap-reset-handoff-20260808.md

@@ -0,0 +1,97 @@
+# TP15 — AP-Reset Handoff 2026-08-08
+
+> **Status:** `crs326-core` L3 + WG-Hub läuft. `ap1` wurde factory-resettet und ist L2-erreichbar. `ap2` bleibt vorerst unangetastet.  
+> **Nächste Session:** `ap1` als reiner AP provisionieren (Mgmt `.99.11`, Uplink `ether1` PoE, VLAN-Trunk, 5 SSIDs, kein CAPsMAN).
+
+---
+
+## ✅ Heute erledigt (vor Reset)
+
+### WG-Hub auf `crs326-core` repariert
+- Ursache: `crs326-core` hatte einen **neu generierten** WG-Privkey → Spokes erkannten den Hub nicht.
+- Beide Spokes (FM + DW/Geli) waren noch auf den **alten ap1-Hub-Public-Key** konfiguriert (SSoT: `routeros/ap1-wg-hub.privkey`).
+- Fix: Auf `crs326-core` den **alten ap1-Privkey** aus `routeros/ap1-wg-hub.privkey` in `/interface/wireguard set wg-hub key=...` eingesetzt.
+- Ergebnis:
+  - **fm**: `last-handshake=1s`, rx/tx aktiv ✅
+  - **dw**: `last-handshake=3s`, rx/tx aktiv ✅
+
+### Backups
+| Gerät | Backup-Name | Status |
+|---|---|---|
+| `crs326-core` | `tp15-core-pre-ap-reset.backup` (74.2 KiB) | ✅ auf Gerät |
+| `crs326-core` | `tp15-core-pre-wg-key-restore.backup` | ✅ auf Gerät |
+| `crs326-branch` | `tp15-branch-pre-ap-reset.backup` | ✅ via REST auf VLAN10-IP `.10.2` |
+| `ap1` | **kein frisches Remote-Backup möglich** (REST 401 / SSH Timeout) | ⚠️ |
+
+- Für `ap1` existieren aber die lokalen Pre-Cutover-Backups:
+  - `routeros/ap1-pre-core-cutover-20260806-041627.backup` + `.rsc`
+  - `routeros/ap1-pre-core-cutover-20260806-073616.backup` + `.rsc`
+
+### ap1-Reset
+- `ap1` wurde factory-resettet.
+- **Default-Admin-Passwort nach Reset:** in `~/.secrets/credentials.env` unter `ROUTER_AP1_PASS` hinterlegen (User setzt es via Winbox).
+- **Uplink gepatcht auf `ether1` (PoE-Port)**. Kein `ether0` auf hAP ax² — die Ports heißen `ether1`…`ether5`.
+- `ap1` ist am `crs326-core` Port `ether15` L2-sichtbar:
+  - MAC `D0:EA:11:4D:40:E0` auf `ether15` in der bridge-host-Tabelle.
+  - `192.168.88.1` pingt vom core aus (Werks-IP nach Reset).
+- **ap2 bleibt unangetastet.**
+
+---
+
+## 📋 Offen / Nächste Session
+
+### 1. ap1 als reiner AP provisionieren
+Ziel-Parameter:
+- **Mgmt-IP:** `10.40.99.11/24` auf `vlan99` (Vorgabe User)
+- **Uplink:** `ether1` (PoE) als VLAN-Trunk in `bridge`
+- **VLAN-Config:**
+  - `bridge` mit `vlan-filtering=yes`
+  - VLAN1 untagged (nur für Mgmt/Transition, später ggf. entfernen)
+  - VLANs 10/20/30/40/50/90/99 tagged auf `ether1` + `wifi1`/`wifi2`
+- **WLAN:** 5 SSIDs, kein CAPsMAN mehr:
+  - `dirtyvader-main` → VLAN10
+  - `dirtyvader-infra` → VLAN20
+  - `dirtyvader-iot` → VLAN30 (nur 2,4 GHz)
+  - `dirtyvader-media` → VLAN40
+  - `dirtyvader-untrusted` → VLAN50
+  - optional `dirtyvader-guest` → VLAN90
+- **Admin-Passwort:** vom User via Winbox gesetzt; in `~/.secrets/credentials.env` hinterlegen.
+- **Keine** Router/DHCP/DNS/NAT/WG-Funktion mehr auf ap1.
+
+### 2. VLAN99 am core auf Uplink-Ports verteilen
+- Aktuell ist VLAN99 auf `crs326-core` nur auf `bridge`, **nicht** auf `ether8` (Trunk zu branch) und `ether15` (Trunk zu ap1) tagged.
+- Damit ap1 mit `.99.11` vom core erreichbar ist, muss VLAN99 tagged auf `ether15` (und `ether8` für branch) konfiguriert werden.
+- **Achtung Lockout:** branch-Mgmt `.99.2` ist aktuell nicht vom core `.99.1` pingbar (VLAN99 fehlt auf ether8). Dies ebenfalls nachholen.
+
+### 3. ap2-Migration
+- ap2 hängt an `crs326-branch` `ether24` und hat aktuell nur VLAN40-IP `.40.2` (falsche Mgmt).
+- Nachdem branch VLAN99 sauber tagged bekommt: ap2 Mgmt-IP auf `.99.2` setzen und als reinen AP provisionieren.
+
+### 4. Passwort-Konsolidierung
+- AP-Admin-Passwort in `~/.secrets/credentials.env` + `~/.claude.json` synchronisieren.
+- Switch-Passwörter ebenfalls abgleichen.
+
+### 5. Nautobot / Golden Config
+- Nautobot war zuvor down (HTTP 500), aber `/health/` zeigt jetzt working.
+- Für die AP-Provisionierung kann Nautobot Golden Config verwendet werden, sobald Device-Daten + Template für reine APs bereitstehen.
+- Governance-Ausnahme: falls Nautobot noch nicht bereit, direkte MikroMCP/REST-Config am ap1 erneut erforderlich.
+
+---
+
+## ⚠️ Wichtige Gotchas für die nächste Session
+
+- **ap1-Uplink = `ether1`, nicht `ether2`.** Der alte Trunk war auf `ether2`; nach dem PoE-Patch muss die neue Config `ether1` verwenden.
+- **hAP ax² hat kein `ether0`.**
+- **ap1 `device-mode=home` ist nach Reset wieder aktiv** → Scheduler/Fetch blockiert. Provisionierung muss idempotent ohne Scheduler auskommen.
+- **VLAN99-Trunk am core fehlt** → ap1 `.99.11` ist erst erreichbar, wenn core `ether15` VLAN99 tagged trägt.
+- **WG-Hub läuft bereits auf core** — ap1 darf keinen WG-Hub mehr anlegen.
+- **Backup-Dateien auf Geräten** sollten nach erfolgreicher Provisionierung heruntergeladen/gesichert werden.
+
+---
+
+## Assets / Referenzen
+- `routeros/ap1-pre-core-cutover-20260806-041627.rsc` — letzte ap1-Vorkonfiguration (inkl. WLAN/SSID-Muster)
+- `routeros/tp3.1-ap2-vlan.rsc` — VLAN-Trunk-Muster für hAP ax²
+- `routeros/ap1-wg-hub.privkey` — alter WG-Hub-Privkey (nur für Historie; WG ist auf core)
+- `docs/tp15-session-summary-20260808.md` — voriger Session-Stand
+- `docs/tp15-core-swap-session-handover.md` — ursprüngliches Core-Cutover-Handoff