96 lines
4.5 KiB
Markdown
96 lines
4.5 KiB
Markdown
# 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)
|