diff --git a/PLAN.md b/PLAN.md index 5d4227e..905dde5 100644 --- a/PLAN.md +++ b/PLAN.md @@ -1,81 +1,152 @@ -# TP15/TP21 Kritischer Pfad — Plan (Stand 2026-08-05, aktualisiert) +# TP21-Plan — Nautobot Golden Config + AP-Neuprovisionierung -> **User-Entscheidung:** Cutover morgen (2026-08-06). Heuteiger Fokus = **Nautobot-Datenmodell für `crs326-core` ausbauen**, damit der Cutover über Nautobot Golden Config geplant/gesteuert werden kann. Governance-Ausnahme #3 damit obsolet für den Config-Teil; die physischen Cutover-Schritte bleiben ein geplantes Wartungsfenster. +> **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. -## Aktueller Stand (Read-only Checks) +--- -| Komponente | Befund | -|---|---| -| **ap1** | Noch aktiver L3-Router, 53 DHCP-Reservierungen, Public-IP `90.146.35.38`, WG-Hub live. RouterOS 7.23.2. | -| **crs326-core** | Erreichbar nur über VLAN1-Temp `10.40.41.211`. **Keine L3-Config** auf dem Gerät. `10.40.99.11` tot, weil sw1 #12 kein VLAN99 tagged trägt. | -| **crs326-branch** | Produktiv auf `10.40.99.13`, läuft. | -| **Nautobot** | App live (`10.40.20.30:8080`), Golden-Config-App installiert, Git-Repo zu Gitea verbunden. **Aber:** `crs326-core` nur rudimentär modelliert (7 Interfaces, keine VLAN-SVIs, keine SecretsGroup), GC-Templates/Regeln nur PoC-Niveau, Scheduler+Worker unhealthy. | -| **MikroMCP** | In dieser Session **nicht** für core/branch geladen — Env-Variablen-Mismatch (`~/.secrets` exportiert `CRS326_*`, `routers.yaml` erwartet `ROUTER_CRS326_*`). | -| **Portainer ep14** | API-Token stale/ungültig → Docker-Management auf NAS gestört. | -| **Postgres / pve-mcp / Gitea / CF-Token** | Grün. | +## Ziele dieser TP21-Session -## Heutiges Ziel (2026-08-05) +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. -**Nautobot-Datenmodell für `crs326-core` so weit vervollständigen, dass morgen ein Config-Render für den L3-Router möglich ist.** +--- -Konkrete Arbeitspakete: -1. MikroMCP reparieren & neu starten (core/branch schreibbar für Tests). -2. Portainer-Token rotieren (damit Nautobot-Container-Logs/Health prüfbar sind). -3. Nautobot worker/scheduler healen. -4. `crs326-core` Device-Modell in Nautobot vervollständigen: - - Interfaces `ether6`–`ether24`, `sfp-sfpplus1`, `sfp-sfpplus2`. - - VLAN-SVIs (`vlan10`–`vlan100`) + IP-Adressen (GW `.1` je VLAN). - - Access/Trunk-Ports mit korrekten untagged/tagged VLANs gemäß Ziel-Layout. - - `SecretsGroup` mit RouterOS-Credentials. - - `Platform` = RouterOS. - - Status = `Planned` (morgen nach Cutover `Active`). -5. DHCP-Scopes, statische DNS-Einträge, Firewall-Zonen/-Regeln, NAT, WireGuard-Peers, CAKE-Parameter im Datenmodell abbilden (Custom Fields oder native Modelle, je nach Nautobot-Möglichkeit). -6. Golden-Config SoT-Aggregation Query erweitern. -7. RouterOS-Jinja-Template für L3-Core vervollständigen (ggf. anhand von `routeros/tp15-core-l3-staged.rsc`). -8. GC Compliance-Features/Regeln für kritische Bereiche definieren. -9. Backup/Intended-Job auf `crs326-branch` testen (Proof-of-Concept für MikroTik-Switch). -10. ap1-Reservierungen + WG-Privkey maschinell exportieren (Input für Datenmodell + Template). +## Reihenfolge -## Morgiges Ziel (2026-08-06) — Cutover +### Phase 1 — Vorbereitung & Credentials (15–30 Min, kein Netz-Eingriff) -Voraussetzungen vor dem Fenster: -- `crs326-core` in Nautobot vollständig modelliert. -- Golden Config kann ein `intended`-Config für core rendern. -- MikroMCP schreibbar, dryRun auf core erfolgreich. -- ap1-Voll-Backup frisch gezogen. -- Port-Umzugsplan final: core #4=ap1, #8=branch, #16=Arris/WAN; sw1-Rest stilllegen. -- iPhone-Hotspot als Rettungspfad parat. -- Wartungsfenster mit Hausmitteilung (ca. 60 Min). +1. **Backups ziehen** + - `crs326-core`, `crs326-branch`, ap1: jeweils `/export` + `/system backup`. + - ap2: sobald erreichbar. -Cutover-Ablauf: -1. Nautobot `intended` Config für core rendern/exportieren. -2. ap1 als Router stilllegen (DHCP/DNS/NAT/GW-IPs/WAN-Client/WG-Hub disable). -3. ap1-Uplink `ether2` → `ether1` (PoE), `poe-out=off`. -4. Kabel von sw1 auf core umstecken. -5. core-L3-Config aktivieren (Nautobot-Deploy oder REST/MikroMCP-Apply). -6. Abnahme je VLAN, branch, WG-Handshake, CF/WARP, Public-IP. -7. Rollback-Test (optional, aber empfohlen). +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. -## Nach dem Cutover +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. -- Mgmt-Renumber (branch `.99.13` → `.99.12`, core `.99.11` konsolidieren). -- VLAN1-Temp-IPs entfernen. -- Nautobot: core `Planned` → `Active`. -- Doku aktualisieren (`teilprojekte.md`, `CLAUDE.md`, `ip-plan.md`). -- WLAN-Neuprovisionierung (CAPsMAN-Abbau) als eigene Session. -- TP5/TP6 danach. +### Phase 2 — Nautobot heilen (15–45 Min) -## Rollback (während Cutover) +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. -1. core-L3 deaktivieren / Config zurückziehen. -2. Kabel zurück auf sw1. -3. ap1 DHCP/DNS/NAT/GW-IPs/WAN-Client/WG-Hub wieder aktivieren. -4. Netz wieder im heutigen Zustand. +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. -## Erste Schritte jetzt +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. MikroMCP envPrefix/Secrets fixen + Neustart. -3. Portainer-Token rotieren. -4. Nautobot worker/scheduler healen. -5. Dann in das `crs326-core`-Datenmodell einsteigen. +2. Passwort-Setzen auf core/branch/ap1/ap2 (einheitlich). +3. Backups ziehen. +4. Nautobot-Logs prüfen.