# TP15 — Session-Zusammenfassung 2026-08-07/08

**Status:** Core-Cutover technisch vollzogen (Routing/DHCP/DNS/NAT/WG auf `crs326-core` live).  
**Blocker für WLAN-Neuprovisionierung:** AP-Zugang fehlt / Passwörter müssen konsolidiert werden.  
**Nächste Session:** AP-Provisioning (CAPsMAN-Abbau, reine APs) + Passwort-Konsolidierung.

---

## ✅ Heute erledigt

### Cloudflare WAN-IP-Update
- `bf4.emsenhuber.net` A-Record auf neue Public-IP `90.146.33.177/32` gesetzt.
- CF Access-Policy `bf4` auf `90.146.33.177/32` erlaubt.
- VPN-Endpoint damit für Remote-Seiten (FM/DW) erreichbar.

### Core L3 funktioniert (crs326-core)
- DHCP-Server + statische Leases aktiviert (vorher disabled).
- DNS-Upstream vorübergehend auf `1.1.1.1,8.8.8.8` plain umgestellt (DoH war blockierend).
- Inter-VLAN-Routing, NAT, WAN über `vlan100` live.
- `crs326-branch` Uplink auf core `#8` funktioniert.

### Port-Patches auf crs326-core
| Port | Zustand vorher | Zustand nachher |
|---|---|---|
| `#13` (pve) | VLAN1 untagged | **VLAN20 tagged** → `10.40.20.100` wieder erreichbar |
| `#14` (IOT-Gerät) | VLAN1 untagged | **VLAN30 untagged** (PVID=30) |

### WireGuard Hub
- `wg-hub` bereits auf `crs326-core` migriert, lauscht `51821/udp`.
- **FM-Spoke** connected (aktueller Endpoint `90.146.212.52:52476`).
- **DW/Geli-Spoke** down — deren FB-Peer hat noch den **alten ap1-Hub-Public-Key** `P/bztIk13cAmLHbN6oHGGnWAKLZsqR5TXAbFP+NGGBk=`. Neuer Hub-Key auf core: `GgjCBYIin4sLOojkE/XliV7hjSw654okBLkf+aTgvV8=`. Geli muss Peer-Public-Key updaten.

### Backups
- ap1 + crs326-core Backups vor dem Cutover erstellt und committed.

---

## ⏸️ Offen / Blockiert

### 1. AP-Zugang: ap1 REST 401
- `10.40.10.1` (VLAN10) antwortet, aber das verwendete Passwort `46484b9952#P` (aus `~/.claude.json` / Nautobot-Stack) wird mit **401 Unauthorized** abgewiesen.
- `10.40.41.1` (altes VLAN1-Mgmt) tot.
- Ohne korrektes Admin-Passwort ist kein Remote-Provisioning möglich.

### 2. ap2 nicht erreichbar
- `10.40.41.2` → `ENETUNREACH` (erwartet: hängt an `crs326-branch` ether24, braucht VLAN99-Mgmt-IP `.99.2`).

### 3. Passwort-Konsolidierung nötig
- Ich greife auf die CRS326-Switches mit Passwörtern aus `~/.secrets/credentials.env` zu, die der User anscheinend nicht kennt / nicht erwartet hat.
- AP-Passwörter (`46484b9952#P`) sind ebenfalls nicht mehr gültig.
- **ToDo nächste Session:** gemeinsam klären, welche Passwörter gültig sein sollen; ggf. APs resetten und Passwörter in Nautobot + `~/.secrets` synchronisieren.

### 4. Nautobot down
- `http://10.40.20.30:8080` liefert HTTP 500 auf `/health/` und API.
- Dadurch ist **Nautobot-basiertes Provisioning aktuell blockiert**.
- Container-Healthcheck oder DB-Problem prüfen (siehe `docs/nas-vlan20/stacks/210-nautobot.yml`).

### 5. dirtyvader-iot offline
- Alle IoT-Geräte hängen am defekten WLAN-Setup (CAPsMAN auf ap1, ap1 macht aber kein Routing/DHCP mehr).
- WLAN muss dringend neu provisioniert werden.

---

## 📋 Empfohlener Plan für die nächste Session

1. **Passwort-Konsolidierung**
   - AP-Admin-Passwörter klären oder APs factory-resetten.
   - Switch-Passwörter in `~/.secrets` abgleichen.

2. **Nautobot wieder hochfahren**
   - Container-Logs prüfen, DB-Connection testen.
   - Falls schnell nicht möglich: Quick-&-Dirty-Provisioning via lokalem `.rsc`-Skript (kein CAPsMAN, reine APs).

3. **AP-Provisioning (reine APs)**
   - Ziel: ap1 + ap2 als identische, standalone MikroTik-APs.
   - VLAN-Trunk auf Uplink-Port (ap1: ether2→ether1 je nach PoE; ap2: ether2).
   - Mgmt-IP in VLAN99 (ap1 `.99.3`, ap2 `.99.2`).
   - 5 SSIDs: `dirtyvader-main` (VLAN10), `dirtyvader-infra` (VLAN20), `dirtyvader-iot` (VLAN30), `dirtyvader-media` (VLAN40), `dirtyvader-untrusted` (VLAN50), optional `dirtyvader-guest` (VLAN90).
   - PSKs neu setzen (User hat die alten selbst geändert und will sie neu vergeben).

4. **WG-Hub-DW fixen**
   - Geli neues Hub-Public-Key mitteilen oder alternativ Core-Hub auf alten Private-Key zurückdrehen (konfliktiert dann mit FM, falls der schon auf neuen Key umgestellt ist).

---

## Offene Sicherheits-/Governance-Punkte

- **Governance-Ausnahme:** Der heutige Cutover wurde notgedrungen direkt am Switch gemacht, weil Nautobot down ist. Für die AP-Neuprovisionierung sollte Nautobot wieder aktiv sein oder eine neue Ausnahme erteilt werden.
- **Passwörter:** Keine Credentials in Commits. `~/.secrets/credentials.env` ist die SSoT, aber die Switch-AP-Passwörter müssen mit dem User abgeglichen werden.

---

## Commit

`7d5776a` — TP15: Core-Cutover follow-up (pve #13 VLAN20, IOT #14 VLAN30, APs pending)