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

Passwort-Konsolidierung
- AP-Admin-Passwörter klären oder APs factory-resetten.
- Switch-Passwörter in ~/.secrets abgleichen.
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).
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).
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)

4.5 KiB Raw Blame History