149 lines
9.4 KiB
Markdown
149 lines
9.4 KiB
Markdown
# VLAN1-Leak-Härtung (TP3.1) + VLAN1-Retirement/cudy-Teardown (TP19) — Runbook
|
||
|
||
**Stand: 2026-07-15.** Zwei verschiedene TPs, ein gemeinsamer Session-Ablauf (Phase A wird logisch zuerst
|
||
gemacht, blockiert aber Phase B nicht). Steuerung/Scope: `docs/teilprojekte.md` → **TP3.1** (Phase A) und
|
||
**TP19** (Phase B). Verwandt: `project_vlan1_dhcp_incident` (Root-Cause-Erstdiagnose), `routeros/tp3.1-ap2-vlan.rsc`
|
||
(Interim-Härtungsmuster, dort erstmals auf ap2 angewendet). Für eine frische Session gedacht — kein Vorwissen
|
||
aus Vorgänger-Sessions vorausgesetzt.
|
||
|
||
---
|
||
|
||
## TL;DR
|
||
**Akuter Bug, nicht nur Cleanup:** Clients auf `dirtyvader-main` (VLAN10) bekommen zeitweise
|
||
`10.40.41.x`-IPs (VLAN1) statt `10.40.10.x` — der bereits einmal diagnostizierte
|
||
**Dual-DHCP-Race** (gleiche MAC hält gleichzeitig eine `defconf`/VLAN1- und eine `dhcp-v10`-Lease).
|
||
|
||
- **Phase A — TP3.1-Scope (~30–60 Min):** akutes Leck auf ap1 stopfen, gleiche Härtung wie 2026-07-06
|
||
auf ap2 (dort schon TP3.1-Interim-Härtung). Symptom weg, VLAN1 existiert danach noch.
|
||
- **Phase B — TP19-Scope (~2–3h):** VLAN1 + cudy komplett abbauen. Ursache weg, kein Leck mehr möglich,
|
||
Phase-A-Härtung wird dabei redundant (muss nicht zurückgebaut werden, verschwindet mit VLAN1 selbst).
|
||
|
||
Phase A blockiert Phase B nicht (unabhängig ausführbar), aber Phase B macht Phase A überflüssig.
|
||
|
||
---
|
||
|
||
## Kontext / Root Cause
|
||
|
||
VLAN1 ist historisch das Flachnetz der alten FritzBox-Ära und trägt bis heute:
|
||
1. Das **cudy-Alt-WLAN** (`elektrosmog.c` o.ä., cudy1/cudy2, `10.40.41.246`/`.247`) — bridged Clients
|
||
untagged in VLAN1.
|
||
2. Eine aktive **DHCP-Client-Rolle** auf ap1 (`defconf`/pool-v1) — vergibt weiterhin `10.40.41.x`-Leases.
|
||
3. Switch-/AP-Management (sw1 `.11`, sw2 `.12`, ap2-Mgmt `.2`) — **das bleibt** bis zum separaten
|
||
MGMT-VLAN99-Cutover, ist NICHT Teil dieses Teardowns.
|
||
|
||
**Bereits einmal aufgetreten und diagnostiziert** (`project_vlan1_dhcp_incident`, 2026-07-05/06):
|
||
dieselben Main-SSID-MACs hielten gleichzeitig eine korrekte `dhcp-v10`-Lease **und** eine
|
||
`defconf`/VLAN1-Lease → Race, sichtbar als „offering ... without success" + minütliches Flapping.
|
||
**Fix damals (TP3.1, 2026-07-06):** auf **ap2** wurden die Master-Radio-Bridge-Ports `wifi1`/`wifi2`
|
||
von `frame-types=admit-all` auf **`admit-only-vlan-tagged`** umgestellt — untagged Main-Frames werden
|
||
seither auf ap2 verworfen statt in VLAN1 gedumpt. **Diese Härtung wurde nur auf ap2 gemacht.** Der
|
||
aktuell gemeldete Leck auf `dirtyvader-main` deutet stark darauf hin, dass **ap1 die gleiche Lücke
|
||
noch offen hat** (lokale Main-Radios dort vermutlich noch `admit-all`).
|
||
|
||
---
|
||
|
||
## Phase A (TP3.1) — Akutmitigation (Leck auf ap1 stopfen)
|
||
|
||
**Ziel:** `dirtyvader-main`-Clients bekommen zuverlässig nur noch `dhcp-v10`-Leases, keine `defconf`
|
||
mehr. VLAN1 selbst bleibt vorerst bestehen (das ist Phase B).
|
||
|
||
### A1 — Live-Diagnose (Race bestätigen)
|
||
1. `mikromcp list_wifi_clients` / Registration-Table auf ap1, gefiltert auf `dirtyvader-main`-Interface
|
||
→ betroffene MACs sammeln.
|
||
2. `mikromcp list_dhcp_leases` auf **beiden** Servern (`defconf` = VLAN1-Pool, `dhcp-v10` = VLAN10-Pool)
|
||
→ nach denselben MACs suchen. **Beweis des Race:** dieselbe MAC taucht in beiden Leases auf.
|
||
3. Prüfen, ob die betroffenen Clients über **ap1** (lokal) oder **ap2** (remote-CAP) verbunden sind —
|
||
falls ap2, ist die TP3.1-Härtung dort vermutlich schon aktiv und das Leck sitzt tatsächlich auf ap1
|
||
(bestätigt die Hypothese) oder wo anders (cudy selbst, s. A4).
|
||
|
||
### A2 — Fix: ap1 Main-Radio-Härtung (Playbook = TP3.1)
|
||
1. Auf ap1: welche Bridge-Ports tragen die **lokalen Master-Radios** für `dirtyvader-main` (wifi1/wifi2,
|
||
analog zur ap2-Struktur aus TP3.1)? Aktuellen `frame-types`-Wert prüfen.
|
||
2. Falls `admit-all`: auf **`admit-only-vlan-tagged`** umstellen — **exakt das gleiche Muster wie
|
||
TP3.1 auf ap2**, siehe `routeros/tp3.1-ap2-vlan.rsc` als Referenz.
|
||
3. ⚠️ **NICHT anfassen: `ether2`** (WAN-Trunk/Mgmt-Pfad von ap1 — VLAN1 muss dort laut TP3.1/TP4
|
||
weiterhin `untagged=bridge,ether2` bleiben, sonst Lockout-Risiko für Switch-/AP-Mgmt). Nur die
|
||
WLAN-Radio-Bridge-Ports ändern, kein anderer Port.
|
||
4. `dryRun:true` zuerst, Diff prüfen, dann `apply_plan`.
|
||
|
||
### A3 — Verifikation
|
||
1. Betroffene Clients (aus A1) neu verbinden lassen (WiFi aus/an) oder auf DHCP-Renew warten.
|
||
2. Neue Lease muss **ausschließlich** `dhcp-v10` sein — `defconf`-Lease für diese MAC darf nicht
|
||
erneuert werden (alte Lease läuft aus/wird nicht erneuert = ok).
|
||
3. 10–15 Min beobachten (mehrere Renew-Zyklen), kein erneutes Flapping.
|
||
|
||
### A4 — Falls A2 nicht ausreicht
|
||
Falls nach dem ap1-Fix das Symptom weiter auftritt: Leck sitzt evtl. nicht an den Main-Radios, sondern
|
||
am **cudy selbst** (bridged evtl. irgendwo denselben L2-Broadcast-Domain-Ast) oder an einem noch nicht
|
||
identifizierten Pfad. In dem Fall: Phase B (kompletter cudy-Abbau) vorziehen/beschleunigen — das
|
||
Symptom verschwindet spätestens dann garantiert, weil die VLAN1-Quelle physisch weg ist.
|
||
|
||
---
|
||
|
||
## Phase B (TP19) — Vollständiger Teardown (VLAN1 + cudy weg)
|
||
|
||
### B0 — Ziel-Abgrenzung
|
||
Weg: cudy-WLAN komplett, VLAN1 als **Client**-Netz (`defconf`/pool-v1). Bleibt (by design, bis
|
||
separater MGMT-VLAN99-Cutover): sw1 `.11`, sw2 `.12`, ap2-Mgmt `.2` — statisch, kein DHCP nötig.
|
||
|
||
### B1 — Prereqs: restliche VLAN1-Clients umziehen (SONST verwaisen sie beim cudy-Tod)
|
||
Live-Stand ap1-ARP zuletzt geprüft 2026-07-13 — zu Sessionbeginn neu sweepen, Stand kann sich geändert
|
||
haben:
|
||
|
||
1. **Christophs Endgeräte → VLAN10** (`dirtyvader-main`): MacBook-Air `.41.182`
|
||
(`c0:c7:db:de:71:be` — **= Claude-Sandbox-Client!** Als Erstes umhängen, sonst verliert die laufende
|
||
Session ggf. die Verbindung), iPhone `.41.186`.
|
||
2. **2 unidentifizierte VLAN1-Geräte:** `.41.133` (`02:11:32:22:1e:25`, randomisierte/lokal-admin.
|
||
MAC — evtl. Phone-Privacy-MAC oder VM) + `.41.198` (`34:2b:6e:6f:1f:ef`) → **vor Teardown verorten**
|
||
(größter Zeit-Unsicherheitsfaktor laut Schätzung). Falls nicht auflösbar in angemessener Zeit:
|
||
Risiko abwägen — Gerät verwaist beim Teardown, taucht dann als "kein DHCP mehr" auf und lässt sich
|
||
danach über den Symptom-Report re-identifizieren.
|
||
3. **Media → VLAN40 verifizieren:** Apple TV 4K + Philips TV 50PUS7304 (beide zuletzt **aus**) —
|
||
einschalten, ap1-ARP prüfen ob `dirtyvader-media`/VLAN40 oder noch cudy/VLAN1. ⚠️ **Apple TV =
|
||
vermutlich Thread-Border-Router** der 22-Matter-Geräte-Flotte (TP17.1) — nicht sorglos stromlos
|
||
lassen, nur kurz für den Check.
|
||
4. **Saisonale Shellys** s1/s2/s3/s12 (aus, Weihnachtsdeko/Diele-Steckdose): **Empfehlung** kurz vor
|
||
dem Teardown einstecken + `mcp/shelly/migrate.py`, sonst müssen sie später per physischem
|
||
AP-Mode-Reset nachgezogen werden. **Nicht blockierend** — kann übersprungen werden, wenn der
|
||
spätere Reset-Aufwand akzeptiert wird.
|
||
5. **pve-Interim-IP `.41.100`** (bewusster Fallback) beim Teardown mit abräumen.
|
||
|
||
### B2 — Teardown-Sequenz
|
||
1. **VLAN1-Client-Sweep = leer verifizieren** (nur Mgmt-IPs sw1/sw2/ap2 übrig).
|
||
2. **cudy1/cudy2 stromlos/Reset/ausbauen** (`.41.246`/`.247`).
|
||
3. **SwitchBot floor-lamp** (`.41.184`, `b8:f8:62:09:f2:04`) via App/BLE auf `dirtyvader-iot`/VLAN30
|
||
provisionieren (Reservierung `.30.227` liegt bereits) — **laut User erst jetzt (nach cudy-Tod)
|
||
zuverlässig möglich**, davor nicht versuchen.
|
||
4. **ap1 `defconf`/pool-v1-Client-DHCP zurückziehen** — Mgmt-Reachability für sw1/sw2/ap2 (VLAN1
|
||
statisch) dabei erhalten, nicht die ganze VLAN1-Interface-Config killen.
|
||
5. **Interim-Krücken aufräumen:**
|
||
- ap2 `frame-types=admit-only-vlan-tagged` (TP3.1) — verschwindet automatisch mit VLAN1, kein
|
||
Rückbau nötig (bleibt im Zielbild korrekt).
|
||
- ap1-Härtung aus Phase A — dito, wird mit VLAN1-Tod redundant, kann bleiben.
|
||
- `st-main rrm/wnm` (802.11k/v Roaming-Provisorium) neu bewerten, ob nach Migration noch nötig.
|
||
6. **Nachziehen:** `inventory/bf.csv`, `docs/ip-plan.md`, ap1 `bf.lan`-DNS, `docs/teilprojekte.md`
|
||
TP19 auf ✅.
|
||
|
||
---
|
||
|
||
## Risiken & Rollback
|
||
|
||
- **Lockout-Risiko (wie bei jedem VLAN1-Touch):** VLAN muss existieren + der Port/Radio muss es tragen,
|
||
**in einem Schritt** ändern. Vor dem Zurückziehen von `defconf`/pool-v1 sicherstellen, dass sw1/sw2/
|
||
ap2-Mgmt-IPs weiterhin **statisch** erreichbar sind (kein DHCP-Abhängigkeit für die Mgmt-Pfade).
|
||
- **MacBook = Sandbox-Client:** Reihenfolge einhalten (B1.1 zuerst) — sonst reißt beim cudy-Abbau die
|
||
eigene Session-Verbindung ab, bevor der Umzug bestätigt ist.
|
||
- **Verwaiste Geräte:** falls B1.2 (unidentifizierte Geräte) nicht rechtzeitig auflösbar ist und der
|
||
Teardown trotzdem durchgezogen wird → Gerät fällt aus dem Netz, ist aber nicht zerstört (physischer
|
||
Zugriff/Re-Provisionierung später möglich, kein Datenverlust-Risiko).
|
||
- **Rollback Phase A:** `frame-types` auf ap1 zurück auf `admit-all` (macht das Leck wieder auf, aber
|
||
reversibel).
|
||
- **Rollback Phase B:** cudy-Hardware ist nach Ausbau nicht mehr im Netz — Rollback würde Wiedereinbau
|
||
+ Reset auf alte Config bedeuten (nicht vorgesehen, Teardown ist bewusst final).
|
||
|
||
## Verifikation (Gesamt)
|
||
- `dirtyvader-main`-Clients bekommen ausschließlich `.10.x`-Leases (Phase-A- und Phase-B-Beweis).
|
||
- VLAN1-ARP/DHCP-Sweep auf ap1: nur noch sw1/sw2/ap2-Mgmt-IPs sichtbar, keine Client-Leases mehr.
|
||
- cudy-SSID nicht mehr sichtbar in WLAN-Scans.
|
||
- Alle in B1 gelisteten Geräte auf ihrem Ziel-VLAN erreichbar (HA-Cross-Check wie im TP17-Runbook-Muster).
|