153 lines
8.6 KiB
Markdown
153 lines
8.6 KiB
Markdown
# TP21-Plan — Nautobot Golden Config + AP-Neuprovisionierung
|
||
|
||
> **Stand:** 2026-08-08. Der CRS326-Core-Cutover (TP15) ist **vollzogen** (`crs326-core` ist produktiver L3-Router). TP21 muss die Control-Plane (Nautobot) wieder flott bekommen, die 4 MikroTik-Geräte sauber in Nautobot/GC erfassen und die APs als reine Access-Points neu aufsetzen.
|
||
>
|
||
> **Caveats aus dem aktuellen Zustand (`docs/tp15-session-summary-20260808.md`):**
|
||
> - `bf4.emsenhuber.net` zeigt auf `90.146.33.177` — das ist die aktuelle Public-IP des core-WAN (`vlan100`). ✅ passt.
|
||
> - Der WireGuard-Hub läuft bereits auf `crs326-core`; **FM-Spoke ist connected**, **DW/Geli-Spoke ist down**, weil deren Peer noch das alte ap1-Hub-Public-Key hat.
|
||
> - **Nautobot ist down** (`10.40.20.30:8080` → HTTP 500). Gestern liefen 2 Nautobot-Container auf der DS923 in eine Restart-Schleife; du hast sie gestoppt.
|
||
> - **AP-Zugang blockiert:** ap1 REST antwortet mit 401 (Passwort-Mismatch); ap2 ist unter `.41.2` nicht mehr erreichbar (erwartete Mgmt-IP `.99.2` noch nicht konfiguriert).
|
||
> - **Passwort-Konsolidierung nötig:** Die für meine Tools verwendeten Credentials scheinen nicht die zu sein, die du für UI/SSH erwartest.
|
||
> - **WG-Privkey-Entscheidung:** Wir verwenden den **bestehenden ap1-Private-Key weiter**, damit DW/Geli keine Reconfig brauchen. FM hat offenbar bereits den neuen core-Key akzeptiert — das muss geprüft/korrigiert werden.
|
||
|
||
---
|
||
|
||
## Ziele dieser TP21-Session
|
||
|
||
1. **Credentials sauber konsolidieren** — RouterOS-Admin-Passwörter für ap1/ap2/core/branch auf einen bekannten Satz bringen (SSoT `~/.secrets/credentials.env` + Nautobot `SecretsGroup`, nie in Git).
|
||
2. **Nautobot wieder hochfahren und heilen** — Ursache für die Restart-Schleife finden, Stack/Healthcheck fixen, auf aktuellen Ist-Stand bringen.
|
||
3. **Alle 4 MikroTik-Geräte sauber in Nautobot modellieren** — Datenmodell + Plattform + Secrets + Golden-Config-fähig. Live-Config der Switches wird **heute nicht via GC geändert**, aber das Setup muss für späteres Provisioning stehen.
|
||
4. **Endgültige MikroTik-Mgmt-IPs vergeben:**
|
||
- `crs326-core`: `10.40.99.1` (ist gleichzeitig VLAN99-Gateway)
|
||
- `crs326-branch`: `10.40.99.2` (renumber von `.99.13`)
|
||
- `ap1`: `10.40.99.11`
|
||
- `ap2`: `10.40.99.12`
|
||
5. **ap1 + ap2 als identische, standalone APs neu aufsetzen** — keine L3-Leichen, CAPsMAN abbauen, VLAN-Trunk, VLAN99-Mgmt, SSIDs. WiFi-PSKs werden **lokal auf den APs** von dir hinterlegt, nicht im Nautobot-Template.
|
||
6. **WG-Hub auf den alten ap1-Private-Key zurückdrehen** — damit FM/DW ohne Reconfig weiterlaufen.
|
||
7. **Dokumentation + SSoT aktualisieren** — `docs/teilprojekte.md`, `CLAUDE.md`, `docs/ip-plan.md`, Nautobot-Models, Memory.
|
||
|
||
---
|
||
|
||
## Reihenfolge
|
||
|
||
### Phase 1 — Vorbereitung & Credentials (15–30 Min, kein Netz-Eingriff)
|
||
|
||
1. **Backups ziehen**
|
||
- `crs326-core`, `crs326-branch`, ap1: jeweils `/export` + `/system backup`.
|
||
- ap2: sobald erreichbar.
|
||
|
||
2. **Passwort-Konsolidierung**
|
||
- **Option A (empfohlen und vorgesehen):** Einheitliches neues Admin-Passwort für alle 4 MikroTik-Geräte; ich setze es via meiner Tool-Session durch.
|
||
- SSoT: `~/.secrets/credentials.env` + Nautobot `SecretsGroup`.
|
||
- Keine Credentials in Git.
|
||
|
||
3. **MikroMCP/REST-Zugänge prüfen**
|
||
- `crs326-core` und `crs326-branch` testen.
|
||
- ap1: aktuell 401 → Passwort-Konsolidierung löst das.
|
||
- ap2: aktuell `.41.2` nicht erreichbar → temporär VLAN1-Zugang via `crs326-branch` ether24 prüfen; alternativ Factory-Reset.
|
||
|
||
### Phase 2 — Nautobot heilen (15–45 Min)
|
||
|
||
4. **Container-Diagnose auf DS923**
|
||
- Portainer ep14 Logs für `nautobot`, `nautobot-worker`, `nautobot-scheduler`, `nautobot-redis` prüfen.
|
||
- Fokus: Warum liefen 2 Container in Restart-Schleife? (Memory-Druck, DB-Connect, Healthcheck-Timeout?)
|
||
- NAS-Ressourcen prüfen.
|
||
|
||
5. **Stack reparieren**
|
||
- `docs/nas-vlan20/stacks/210-nautobot.yml` anpassen: Restart-Policy, Memory-Limits, Healthcheck-Timeouts, `depends_on`.
|
||
- Falls DB-Problem: `nautobot-server post_upgrade` oder DB prüfen.
|
||
|
||
6. **Nautobot auf aktuellen Stand bringen**
|
||
- `nautobot/ingest-crs326-core-l3.py` erneut laufen lassen (`Planned` → `Active`).
|
||
- `crs326-core`, `crs326-branch`, ap1, ap2 sauber als GC-fähige Devices modellieren.
|
||
- `crs326-branch` Mgmt-IP auf `.99.2` renumbern.
|
||
- ap1/ap2: Rolle `Wireless AP`, Mgmt-IP `.99.11`/`.99.12`, VLAN-Trunk.
|
||
|
||
### Phase 3 — Golden Config Proof-of-Life (15–30 Min)
|
||
|
||
7. **GC Backup-Job auf core/branch testen**
|
||
- Beweist, dass Nautobot → RouterOS-API funktioniert.
|
||
- Falls Backup scheitert: RouterOS-Dispatcher/SecretsGroup/Platform fixen.
|
||
|
||
8. **GC Setup für alle 4 MikroTik-Geräte vervollständigen**
|
||
- Golden-Config-Regeln, Features, SoT-Aggregation Query für RouterOS definieren.
|
||
- Template `nautobot/mikrotik_routeros.j2` für reine APs erweitern (Identity, VLAN-Trunk, Mgmt-VLAN99, SSIDs, keine DHCP/DNS/NAT/L3).
|
||
- **WiFi-PSKs kommen nicht ins Template** — du hinterlegst sie lokal auf den APs.
|
||
|
||
### Phase 4 — WG-Hub auf alten Key zurückdrehen (10–15 Min)
|
||
|
||
9. **ap1-Original-Privkey aus Backup holen**
|
||
- `routeros/ap1-pre-core-cutover-20260806-073616.rsc` enthält `/interface/wireguard` mit altem Private-Key.
|
||
- Oder: `routeros/ap1-wg-hub.privkey` prüfen (war das der alte Key?).
|
||
|
||
10. **Core-Hub auf alten Privkey umstellen**
|
||
- `wg-hub` auf `crs326-core` neu anlegen mit altem Private-Key.
|
||
- Dadurch ändert sich der Public-Key auf den alten ap1-Wert → FM/DW brauchen keine Reconfig.
|
||
- FM-Verbindung prüfen (sollte weiterhin funktionieren oder nach kurzem Reconnect funktionieren).
|
||
- DW/Geli-Verbindung prüfen (sollte wieder kommen).
|
||
|
||
### Phase 5 — AP-Neuprovisionierung (30–90 Min, WLAN-Ausfall-Fenster)
|
||
|
||
11. **ap1 als reiner AP neu aufsetzen**
|
||
- **Kein Zurückbau** — frische Config einspielen.
|
||
- Identity `ap1`, Mgmt-IP `10.40.99.11/24` auf `vlan99`.
|
||
- Uplink-Port `ether1` (PoE), `poe-out=off`.
|
||
- VLAN-Trunk auf Uplink: native VLAN1 interim + VLAN99 tagged + Client-VLANs 10/20/30/40/50/90 tagged.
|
||
- SSIDs: `dirtyvader-main`(10), `-infra`(20), `-iot`(30), `-media`(40), `-untrusted`(50), `-guest`(90).
|
||
- WiFi-PSKs von dir lokal auf dem AP hinterlegt.
|
||
- DHCP-Server, DNS, NAT, WAN-Client, WG-Hub, VLAN-GW-IPs entfernen/nicht anlegen.
|
||
|
||
12. **ap2 identisch neu aufsetzen**
|
||
- Falls unter `.41.2` nicht erreichbar: temporär VLAN1-Zugang via `crs326-branch` ether24 (VLAN1 untagged) oder Factory-Reset.
|
||
- Identity `ap2`, Mgmt-IP `10.40.99.12/24` auf `vlan99`.
|
||
- Gleiche Config wie ap1 (bis auf Identity/Mgmt-IP).
|
||
|
||
13. **WLAN-Verifikation**
|
||
- `dirtyvader-main`/`iot`/`media`/... je VLAN und AP testen.
|
||
- IOT-Geräte (Shellys etc.) reconnecten.
|
||
|
||
### Phase 6 — Aufräumen & Dokumentation (15–30 Min)
|
||
|
||
14. **VLAN1-Temp-IPs endgültig entfernen**
|
||
- core `.41.211`, branch `.41.213`.
|
||
- ⚠️ Nur nachdem VLAN99-Mgmt sicher funktioniert.
|
||
|
||
15. **Nautobot + Doku aktualisieren**
|
||
- `docs/teilprojekte.md`: TP15 ✅, TP21 Status.
|
||
- `CLAUDE.md`: core produktiv, ap1/ap2 = reine APs, finale Mgmt-IPs.
|
||
- `docs/ip-plan.md`: core `.99.1`, branch `.99.2`, ap1 `.99.11`, ap2 `.99.12`.
|
||
- Memory-Eintrag `project_tp21_ap_provisioning` anlegen.
|
||
|
||
16. **Commit + Push** (deutsch, Bullet, Co-Authored-By).
|
||
|
||
---
|
||
|
||
## Offene Entscheidungen (vor Go zu klären)
|
||
|
||
| # | Entscheidung | Gewählt |
|
||
|---|--------------|---------|
|
||
| 1 | RouterOS-Admin-Passwort | Einheitliches neues Passwort für alle 4 Geräte |
|
||
| 2 | ap2-Erreichbarkeit | Erst temporären VLAN1-Zugang via `crs326-branch` prüfen; falls nicht: Factory-Reset |
|
||
| 3 | WG-Hub-Privkey | **ap1-Original-Private-Key weiterverwenden**, damit FM/DW keine Reconfig brauchen |
|
||
| 4 | WiFi-PSKs | Du hinterlegst sie **lokal auf den APs**, nicht im Nautobot-Template |
|
||
| 5 | VLAN1-Temp-IPs | Endgültig entfernen, sobald VLAN99-Mgmt stabil ist |
|
||
|
||
---
|
||
|
||
## Risiken & Rollback
|
||
|
||
- **ap1-Provisioning:** Vor dem L3-Abbau am ap1 frisches Backup haben. Rollback = Backup laden → ap1 ist wieder L3-Router, Kabel zurück auf sw1 (falls sw1 noch verkabelt ist).
|
||
- **ap2-Factory-Reset:** Physischer Zugang zum Gerät nötig. Recovery = Power-Cycle, falls Config fehlerhaft.
|
||
- **WG-Key-Wechsel:** Wenn FM bereits auf den neuen core-Key umgestellt ist, bricht FM kurz, bis es den alten Key wieder sieht. Sollte aber funktionieren.
|
||
- **VLAN1-Temp-IP-Entfernung:** Nur nachdem VLAN99-Mgmt sicher funktioniert. Sonst Lockout.
|
||
- **Nautobot-Down:** Falls Nautobot nicht schnell heilbar, APs direkt konfigurieren (Governance-Ausnahme, da Nautobot die Control-Plane sein soll).
|
||
|
||
---
|
||
|
||
## Erste Schritte sofort nach Go
|
||
|
||
1. Task-Liste anlegen.
|
||
2. Passwort-Setzen auf core/branch/ap1/ap2 (einheitlich).
|
||
3. Backups ziehen.
|
||
4. Nautobot-Logs prüfen.
|