From 9072b18113d10622ff0de470aef0912aee86fed0 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Sat, 8 Aug 2026 15:15:43 +0200 Subject: [PATCH] TP15: WG-Hub Key-Restore + AP-Reset Handoff (ap1 resettet, ap2 pending) Co-Authored-By: Claude --- docs/tp15-ap-reset-handoff-20260808.md | 97 ++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 docs/tp15-ap-reset-handoff-20260808.md diff --git a/docs/tp15-ap-reset-handoff-20260808.md b/docs/tp15-ap-reset-handoff-20260808.md new file mode 100644 index 0000000..ef543ec --- /dev/null +++ b/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